| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
This section:
Blog postings by Operational Dynamics partners and staff
Use the links at top left for a consolidated feed of all the posts made on this
site.
Please note the disclaimer at the bottom of this page.
Thu, 15 May 2008
A Bazaar branch of GTK
Converting a project from one version control system to another is always painful. Doing so is a rather momentous change to contemplate. With organizational & community inertia being what it is, not something easily rushed into. Worse is when you attempt to use a modern tool as a better front end for an old one.
One of the neat things about the 3rd generation distributed version control system projects (ie Bazaar, Git, or Mercurial) is their plugins which allow you to continue to work with a Subversion upstream project but use the modern tool as a front end locally. For those of us who have been very productively using DVCS for some time, this is a godsend.
Using one of these plugins to thence evaluate the usability or performance of one of a DVCS is not really the best approach one could take; none of them were built with using Subversion as a peer in mind, and lord knows Subversion is not built to store revisions with such complex relationships. Thus the idea has turned out to be a very challenging problem space for everyone but most have had their tools mature to the point where Subversion is the bottleneck. And despite my misgiving that starting out your experience with a 3rd generation DVCS by first using it to access some legacy project will not show your new shiny tool in its best light, the reality remains that most people need to get on with being productive, and doing a full blown conversion (or starting use with a brand new projects) are less likely to be your circumstance.
Having been using Bazaar (known best by the abbreviation bzr) for well over 18 months and overall being very happy with the experience, I would like to encourage other GNOME hackers to try it; likewise I have some patches I’d like to contribute to GTK so I thought I’d start by using bzr-svn to get a branch of GTK as a starting point (and to likewise give Bazaar’s Subversion interface a workout). So I created Bazaar branch of GTK.
Initial import was very slow
The first step was to create a Bazaar branch that represents the foreign Subversion repository. This was painful.
I originally attempted to do this while I was at the GTK Hackfest we had in Berlin; that turned out to be a disaster because (as one does at a conference or meeting) we were moving around every few hours connecting and disconnecting from the ‘net, and I was busy trying to do this from my laptop rather than a server somewhere. (Unfortunately bzr-svn relies on a memory fix that is not yet in the released version of Subversion, and not every distro has their Subversion patched with it). So that fell flat on its face.
I was able to restart the process a week or two later and leave it running overnight. Along the way I’d learned a technique for doing a few hundred revisions at a time (do bzr pull -r $i in a loop and increment the variable by a hundred or whatever each cycle) and so was able to cope with the need to disconnect periodically. Which is well, because it took 2 days to do the import.
While I was at first appalled by this, I really can’t blame Bazaar. The GTK codebase is, of course, rather large. First preserved commits were in 1997; there are over 15,000 revisions; a working tree (excluding VCS metadata) is 83 MB in size. The bigger problem however, is that Subversion is not fast at accessing historical data (the time taken to process revisions started at over 32 minutes per 100 but eventually dropped to about 9 minutes per 100 as it got to the most recent history; interesting).
Clearly, I could have picked an easier example for my experiments with bzr-svn, but it’s done now.
Usage is fine once branch created
I wasn’t entirely sure whether the DVCS property that branches are all peers would apply to one that had started life backed by a Subversion repository would hold, but things work just as they are supposed to. Creating a new branch to work on a feature with bzr branch, or use the technique of using a bzr checkout along with bzr switch to do change-in-place, both worked fine. So I’m all set.
The real point, though, was to encourage more GNOME hackers to give Bazaar a try. If everyone had to put up with a endless import process like mentioned above then no one would touch it. But now that the branch is created (and up to date as of yesterday or so), anyone can use it.
With Olav’s concurrence, I put my branch on in my GNOME directory, so you can branch from it as follows:
$ bzr init-repo --rich-root-pack gtk+ $ cd gtk+/ $ bzr branch http://www.gnome.org/~afcowie/bzr/gtk+/trunk/
You do the first step so that you can create a “shared repository” (in Bazaar parlance) which will allow that various branches under that directory will share all the revision data for the project. I need to warn you, though. Modern DVCS tools give you the full history of the project, but for a large project that can be pretty big. If you grab the above branch you’ll be downloading about 180 MB and it takes about 5 minutes. Yes 5 minutes is a long time, but no there’s no way around it* and in any case 180 MB is not unreasonable for such a mature project. Don’t be too worried if it seems like it is taking a bit to do the transfer. You only need to do it once, and look on the bright side. It took me 2 days. Just let it run.
Workin’
Personally, I always do my work in a working branch separate from my mirror of upstream, allowing me to easily compare against the last update of upstream that I have done. So:
$ bzr branch trunk working $ cd working/ $ ./autogen.sh $ make
and away we go. Branching takes like 3 seconds. Nice and fast, no problem.
I haven’t got a script running religiously updating my GTK branch; I do a bzr pull locally once every few days in my copy of 'trunk' and have been pushing that up to http://www.gnome.org/~afcowie/gtk+/trunk/. But now that you’ve got the branch, you don’t have to rely on me anymore; this whole distributed thing kicks in and you can do it yourself. Assuming you have a svn.gnome.org account, then you can update with:
$ cd ../trunk/ $ bzr pull --remember svn+ssh://username@svn.gnome.org/svn/gtk+/trunk
(use the --remember argument the first time to change where it updates from by default so you’re not relying on my branch anymore) and push with:
$ bzr push svn+ssh://username@svn.gnome.org/svn/gtk+/trunk
The very first time you update from Subversion bzr-svn will have to build some caches and whatnot locally, but it’ll be pretty fast from there on.
I’m ignoring the pushing and pulling of revisions between your mirror of ‘trunk’ and your local 'working' (or whatever) branch; I’m sure you can figure that part out yourself: but here’s a hint: do your work, test it, and commit it, all in 'working'; repeat; then use, say:
$ bzr diff -r ancestor:../trunk/
to consider what your current patch looks like, then shuttle it to 'trunk' with bzr pull or bzr merge (assuming you run it from 'trunk’ and whether you need to merge or not) and then bzr push to svn.gnome.org. Hope it works for you.
If you need help, poke your head into #bzr on FreeNode or write to their mailing list, or ping me and I’ll try and lend a hand. Make sure you’re using the latest releases; I doubt it will work otherwise and so recommend that you use bzr >= 1.4.0 and bzr-svn >= 0.4.10. Older versions do not contain critical bug fixes. I also encourage you to grab bzr-gtk >= 0.93.0 as the visualize command it adds:
$ bzr viz
is really amazing.
Good luck!
AfC
Update:
You need to have PycURL installed (it’s an optional dependency; used at runtime if detected). There is a bug that will prevent you doing the branch from me if you don’t. Debian and Ubuntu package python-pycurl; Gentoo USE=curl pulls in package dev-python/pycurl; Fedora package is also python-pycurl.
This very moment as the GNOME systems administration team is presently working through the consequences of the Debian SSH key vulnerability; they have for the moment very properly locked down all access to the services provided to GNOME hackers, and that knocks out access to the Subversion server meaning people can’t work with their source code properly. If there was ever a clearer demonstration on the inadequacy of old 1st generation centralized version control systems, I cannot think of it.
Mon, 05 May 2008
java-gnome 4.0.7 released!
This blog post is an extract of the release note from the NEWS file which you can read online … or in the
sources,
of course!
java-gnome 4.0.7 (30 Apr 2008)
Draw some.
In addition to the usual improvements to our coverage of the GNOME libraries, this release introduces preliminary coverage of the Cairo Graphics drawing library, along with the infrastructure to make it work within a GTK program.
Drawing with Cairo
The trusty Cairo context, traditionally declared as a variable named cr in
code, is mapped as class
Context. Various Cairo types
such as different surfaces and patterns are mapped as an abstract base class
(Surface, Pattern) along with various concrete subclasses (ImageSurface,
XlibSurface, and SolidPattern, RadialPattern, etc). Error checking is
implicit: the library status is checked internally after each operation and an
Exception thrown if there is a failure.
Thanks in particular to Carl Worth for having reviewed our API and having helped test our implementation.
New coverage and continuing improvement
The single option choice buttons in GTK are called RadioButtons and have now
been exposed. When using them you need to indicate the other buttons they are
sharing a mutually exclusive relationship with, and this is expressed by
adding them to a RadioButtonGroup.
The usual steady refinements to our coverage of the GtkTreeView API continue.
There’s a new DataColumn type for Stock icons, and TreeModelSort is now
implemented, along with minor changes to various other miscellaneous classes.
Considerable internal optimizations have been done, especially relating to
ensuring proper memory management, with notable refinements to make use of
“caller owns return” information available in the .defs data. This fixes a
number of bugs. Thanks to Vreixo Formoso for having driven these improvements.
Error handling has been improved for GLib based libraries as well. If an
ERROR or CRITICAL is emitted, our internals will trap this and throw an
exception instead, allowing the developer to see a Java stack trace leading
them to the point in their code where they caused the problem.
Internationalization support
java-gnome now has full support for the GNOME translation and localization
infrastructure, including the standard _("Hello") idiom for marking strings
for extraction and translation, but combined with some of the powerful support for positional parameters available from Java’s MessageFormat as well. There’s a fairly detailed explanation in the
Internationalization
utility class.
Build changes
Note that as was advertised as forthcoming some time ago, Java 1.5 is now the minimum language level required of your tool chain and Java virtual machine in order to build and use the java-gnome library.
Thanks to Colin Walters, Manu Mahajan, Thomas Girard, Rob Taylor, and Serkan Kaba for contributing improvements allowing the library to build in more environments and for their work on packages for their distributions.
The download page has updated instructions for getting either binary packages or checking out the source code.
Documentation, examples, and testing
Refinements to the API documentation continue across the board, notably improving consistency. A large number of javadoc warnings have also been cleaned up.
While not a full blown tutorial, the number of fully explained examples is
growing. There are examples for box packing and signal connection, presenting
tabular data, and basic drawing, among others. See the description page in the
doc/examples/ section.
This code, together with the not inconsiderable number of unit tests and the
code for generating snapshots of Widgets and Windows means that a large
portion of the public API is tested within the library itself. The number of
non-trivial applications making use of java-gnome is starting to grow, which
are likewise providing for ongoing validation of the codebase.
Summary
You can see the full changes accompanying a release by grabbing a copy of the sources and running:
$ bzr diff -r tag:v4.0.6..tag:v4.0.7
Looking ahead
It’s probably unwise to predict what will be in future releases. The challenge for anyone contributing is that they need to understand what something does, when to use it (and more to the point, when not to!), and be able to explain it to others. This needs neither prior experience developing with GNOME or guru level Java knowledge, but a certain willingness to dig into details is necessary.
That said, I imagine we’ll likely see further Cairo improvements as people start to use it in anger. It shouldn’t take too long until the bulk of the functionality needed for most uses is present in java-gnome. In particular, forthcoming coverage of the Pango text drawing library will round things out nicely.
There are a number of other major feature improvements we’d like to see in java-gnome. Conceptual and design work is ongoing on for bindings of GConf, GStreamer, and even support for applets. Within GTK, there have been a number of requests made for various things to be exposed, for example, the powerful GtkTextView / GtkTextBuffer text display and editing capability. Some of these have preliminary implementations; whether or not any given piece of work is acceptable in time for any particular future release will remain to be seen and depends on the willingness of clients to fund us to review and test such work.
In the mean time, people are happily using the library to develop rich user
interfaces, which is, of course, the whole point. We’re always pleased to
welcome new faces to the community around the project. If you want to learn
more, stop by #java-gnome and say hello!
You can download java-gnome from ftp.gnome.org or easily checkout a branch from ‘mainline’ using Bazaar:
$ bzr clone bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome
AfC
Wed, 30 Apr 2008
No crisis for me
I was chatting with Atul earlier today when he expressed his dismay that Slashdot was off the air and asked me if I could get there? No. Meanwhile, I realized I couldn’t get to SourceForge. This was proving problematic as I had just done a release of an Open Source project I’m the maintainer of, and was trying to update the project website. Guess announcing the release will have to wait a bit :(.
Oh well. “The internet must be broken somewhere”.
We then recalled that these are both services of OSDN. I recall a few years back talking with the system administrators there about crisis management in IT environments and using procedures to manage change. They said they didn’t need any help with their operations. “We’re all set”. Uh huh. People always say that when things aren’t going wrong.
—
Of course, it is now 3am in California. It actually doesn’t matter where your servers are — it’s always 3am when things like this go wrong. Personally, I take it as conclusive proof about the underlying nature of the universe that this sort of thing only happens when it is the middle of the night. You can’t possibly find a less pleasant time to force sysadmins to get out of bed and to go try and fix things. Frankly, I think that’s just Someone trying to tell sysadmins that they made a poor career choice, but you know, He (or She, or It, or They, take your pick) needs to have a good laugh too.
AfC
Thu, 10 Apr 2008
Sun’s secret web server
For a while now I’d been looking for something to just run up an HTTP server to answer simple queries.
The Java Servlet APIs are comprehensive, and there are a number of very good implementations (we use Resin in highly loaded environments and it scales like a dream; we recommend it heartily to our clients). Nevertheless, sometimes you’re working on something small or ad-hoc, and you just want a simple web server that doesn’t involve application descriptors, XML, configuring an entire service instance, and everything else. Somewhat to everyone’s long standing annoyance (not to mention the derision of people who work in other languages), there is nothing in the Java standard library to just get on with this.
In their release of Java 1.6, however, Sun quietly included such a server. Apparently it had been around for some time powering internals of various other projects, but in 1.6 they exposed it as a public library, in package com.sun.net.httpserver, and it ships alongside the rest of their Java VM and standard library.
It’s got a rather nice API. You fire up a server and add one or more handlers:
addr = new InetSocketAddress("localhost", 8000);
server = HttpServer.create(addr, 10);
server.createContext("/eg", new ExampleHandler());
server.start();
the “contexts” are paths from root that are handled by different HttpHandler instances; implementing that interface is simply:
public void handle(HttpExchange t) throws IOException {
...
}
Once there, you’ve got a number of really straight forward methods on HttpHandler to get done what needs doing:
t.getProtocol();
t.getRequestMethod();
t.getRequestURI();
t.getRequestHeaders();
t.sendResponseHeaders(code, length);
for the metadata, and an InputStream and an OutputStream from:
t.getRequestBody();
t.getResponseBody();
respectively. You write the response to the later. Too easy. I did up a modified version of the example they have in the package description file as something that echos back the HTTP request as the response and it was quite straight forward. Java programmers can glance at EchoServer.java if they’re interested.
The catch
Nothing is ever simple. The bytecode for the com.sun.net.httpserver package is bundled in with the rt.jar that comprises the bulk of the standard library, but for whatever reason they didn’t include the JavaDoc for these classes in the same tree as the rest of the API documentation.¹ This is a huge pain, because once you’ve told Eclipse where to look for the docs for a given blob (in this case, for rt.jar) you can’t then tell it to look somewhere else for a sub part. And if you’re trying to develop something in a beautiful IDE like Eclipse, the idea of not having inline popup documentation and completion working properly is just a non-starter.
You can point Eclipse at either a JavaDoc tree, or at the raw sources and it’ll just extract the documentation on the fly. But since the src.zip shipping with Sun’s proprietary Java 1.6 didn’t include the classes for this web server code, that didn’t work either.
So that would have been the writing on the wall for Sun’s httpserver.
Open Java to the rescue
After chatting with some people in #gentoo-java and #classpath, we suddenly realized that the solution was at hand. Source code to Open Java is available.² And even though it’s still not yet a fully Libre replacement for Sun’s proprietary Java 1.6 (the size of the binary proprietary plugs you have to drop into it to make it work is staggering), it does contain most of the sources to the Java standard library. So we grabbed a copy of the openjdk 1.6 b08 code drop, and just pointed Eclipse at it as the sources for rt.jar for cases where it couldn’t find the JavaDoc when it was looking something up. And ta-da!
So, amidst considerable astonishment but great pleasure, here was an example of something someone had Open Sourced working in a synergistic way but in a way that they hadn’t quite expected. This wouldn’t have worked if Sun hadn’t Open Sourced (most of) Java; but because they have we were able to use those sources to solve a problem. Thanks to the heroes at Sun Microsystems who made this possible!
Eclipse users will have to adjust their filters so that com.sun.* isn’t excluded from Type completions and what not; While we’ve all loved our com.sun.* excludes, it blots out com.sun.net.httpserver. If you plan on using it, then I suggest switching to excluding com.sun.org.* and com.sun.xml.*, etc. A pain, but that’s what we get for Sun not having put this into the standard library.
Speaking of which, I doubt we’ll ever see this as a part of the “Java” (wouldn’t java.net.httpserver just do the trick?) because the marketing side of Sun has a fairly strong fixation on “Servlets are what you use for everything”. Oh well. It would be a really pleasant surprise, though. Here’s hoping.
But not really
We would never use this in something we were distributing to anyone outside; after all, they might be using some other VM and com.sun.net.httpserver isn’t available as a standalone library. And that’s not to mention scalability; if you need something bulletproof then use the Resin servlet runner. But if you need a quick-and-dirty but easy-to-use HTTP server and you happen to have Sun Java or the future tense Open Java available, then this should do the trick for you. And if you’re feeling like whipping up something of your own, this really does have a nice API (somewhat a rarity in the Java landscape) and so this might be a good starting point for you. Either way, have a look.
AfC
¹ As mentioned, the API docs for com.net.sun.httpserver are not in the usual location at docs/api/ along with the rest of the standard library but at docs/jre/api/net/httpserver/spec/ of all places. Who knows what they were smoking that day.
² I am very tired of apologizing to people who have just installed “Java” on their Linux boxes that they have to download something else. I’ve given up trying to explain the difference between a JRE and a JDK to people; even after I do people respond with “who cares; I just want a working Java that I can use to build your software.” Sun having attempted to brand their Libre implementation of Java as “Open JDK” just perpetuates this nonsense. Not including the compiler classes in something that is already 18 MB big is stupid, and it’s not like the desktop VM is what you use on a resource limited embedded device. Open Java works just fine as a name, thank you very much, and it is (almost) a Free Java. Almost.
Sat, 05 Apr 2008
Cairo drawing from java-gnome
We’ve added support for the amazing Cairo Graphics library to the Java bindings for GTK and GNOME.
Adding Cairo is a feature we’ve been working on for about 6 months now, and so I’m pretty pleased that during the 4.0.7 development cycle we’ve been able to land it. Cairo is a huge library, of course, but we’ve put enough coverage in place to ensure that things are working.
Cairo has lots of convenience functions and tons of obscure uses; no surprise (and no apology) that there’s still lots that will need doing. If you want to help make sure it has what you need, then
grab ‘mainline’ and see org.freedesktop.cairo.Context and ExampleCairoDrawingInExposeEvent.
Huge thanks go out to Behdad Esfahbod and Carl Worth; Behdad was really critical in explaining some basic Cairo concepts to get me started when we were working together at the GNOME Summit back in October in Boston, and at the GTK hackfest in Berlin in March, Carl Worth checked our preliminary APIs and helped sort me out as we were working our way through to create some examples. Awesome!
java-gnome 4.0.7 should be out in the next week or two, depending on how long it takes to finish up testing, QA, and to do the release engineering.
AfC
Fri, 04 Apr 2008
Upgraded!
|
|
|
| #gnome-hackers | #gentoo-desktop |
The upgrade to GNOME 2.22 went really smoothly. Well done to the Gentoo Linux desktop team for their heroic efforts bumping so many .ebuilds, and congratulations to all the GNOME hackers, testers and translators around the world on what continues to be superb software!
AfC
Tue, 04 Mar 2008
Passing through
I’m in London for a few days; I have a few meetings set up for while I’m here, but we’re always on the lookout for people with new and interesting problems. If anyone reading this is battling to get their IT operations into shape, or perhaps has a major enterprise system critical to their business that is not living up to expectations, then by all means get in touch. We also have long experience with clients who run large Java systems on Linux, and problem solving in those environments continues to be the focus of much of our work.
If you’re facing issues in any of these areas and need to do something about them, I’d be more than pleased to meet with you while I’m here. You can leave a message for me on 0207 101 9201 or call my mobile +61 4 1079 6725; my email address is andrew@operationaldynamics.com.
Given the Java on Linux preoccupation, it’s no surprise that a few years ago I became the maintainer Java bindings for the GNOME Desktop (a project which allows people to use GTK and the other GNOME libraries from to create powerful Linux applications while leveraging their existing expertise with Java). That’s the reason I’m on the road this particular trip; the GNOME Foundation has organized a GTK hackfest in Berlin next week and I was kindly invited.
I’ll be in Toronto the week after, so again, if someone would like to meet, please don’t hesitate to call; 647 477 5603.
Actually, this whole blog post is a bit of a misnomer. It doesn’t matter where you are located, nor where I or any of my staff happen to be any given week. If you have systems that are critical to your business, need to prevent crisis from occurring, trying to manage change better, or looking to review your architecture so you can optimize your use of technology and ensure scalability, then don’t hesitate to contact us, anytime.
AfC
--Andrew Frederick Cowie Managing Director | |||
 | |||
| Sydney | New York | Toronto | London |
| +61 2 9977 6866 | +1 646 472 5054 | +1 647 477 5603 | +44 207 101 9201 |
Mon, 25 Feb 2008
Get Some
The other day I was wading through Ulrich Drepper’s paper about how memory works these days and what programmers should do as a result.
My wife asked me what I was reading. I showed her the title and when she saw it concerned computer memory, she looked at me with a totally straight face and summed up the 114 page paper by answering “Yes, you should get some”.
Like most of Ulrich’s writing, this paper is immense: long on detail and well presented. I must admit that I agreed with many others that after having read the work I was left wondering what action, in practical terms, I should be taking as a result. Clearly most of this knowledge is very important for Kernel hackers and for those doing low level systems programming, but since I do higher level work (ie advising people with large enterprise systems), it is hard to asses the choices I might be making in the terms of what Ulrich describes. I can only hope that the people who work on the parts of the low level libraries that run next to the metal (such as drivers, GLib, and especially the VMs like the Java and Python runtimes) are aware of these issues and making design choices based on these insights.
AfC
Tue, 12 Feb 2008
java-gnome 4.0.6 released!
This blog post is the release note from the NEWS file which you can read
online … or in the
sources,
of course!
java-gnome 4.0.6 (12 Feb 2008)
Finding the missing methods.
Most of our effort recently has simply been fleshing out areas of the public API. The focus for this work as been getting the coverage needed to allow us to port some of our in-house applications to java-gnome 4.0. It’s not especially glamorous — if anything it has been tedious as hell — but the result has been a large body of improvements to java-gnome as a whole which we’re pleased to release as java-gnome 4.0.6
The bulk of this development took place on the ‘missing’ branch, so named
because that’s where I was working on what was missing :).
Continuing Improvement
Notable public changes include coverage additions to enable key stroke and mouse button handling
Rather than exposing the int keyvals that bubble up out of the X server, we
have wrapped these as constants of type
Keyval (thereby being consistent with the
rest of java-gnome in our working to the strengths of Java as a strongly-typed
language; MouseButton was created for the same reason, helping developers
understand just what on earth mouse button
“1” is, anyway). Along with
ModifierType, this gives enough to
deal with the KEY_PRESS_EVENT and KEY_RELEASE_EVENT signals when the
developer wishes to deal with key strokes.
We’ve finally gotten around to providing proper coverage of the box packing
model which underlies every aspect of how GTK presents user interfaces. To
understand the size-request/size-allocation process, you might start with
Widget’s
setSizeRequest().
We’ve also added coverage for SizeGroup, which, when used in concert with nested VBoxes and HBoxes, can work wonderful magic and is often far better than messing around with Table when doing complex layouts.
After dithering for several releases, we’ve settled on how we’re going to deal with ComboBox and family. The underlying GtkComboBox presents something of a nightmare as it is really two classes in one with more-or-less incompatible APIs. So, not surprisingly, we’ve presented it as two sets of classes, with the text-only convenience API spliced out of ComboBox and ComboBoxEntry into TextComboBox and TextComboBoxEntry respectively.
We’ve added a few new features in our coverage of GTK’s TreeView / TreeModel API, and many other classes involved have also seen improvements. The persistent reference to a row provided by TreeRowReference is now available as is model type TreeModelFilter.
Support for the actual filtering in TreeModelFilter is notable for having been quite tricky. The underlying C library use a function pointers rather than a GObject signal emission, and we don’t have any mechanism to handle that. We do, however, have a fantastic capability to marshal signals, so we dealt with the problem by creating a custom signal and then passing a function which emits it when the TreeModelFilter wants to ask the developer whether to include a row or not.
The new classes include support for TreeModel columns storing long data as
well as setting properties of that type.
It should also be noted that most of the methods taking a TreeViewColumn have been converted to taking an argument of type CellLayout (an interface implemented by TreeViewColumn). This has no change to how you use our TreeView API, but was necessary to support ComboBox properly.
Finally lots and lots of minor additions to both public APIs and internals deeper down in the GDK part of the toolkit.
As ever, you can see the full changes accompanying a release by grabbing a copy of the sources and running:
$ bzr diff -r tag:v4.0.5..tag:v4.0.6
Documentation
We’ve always had HTML JavaDoc for the current stable release at
doc/api/ on the java-gnome website.
We’re going to change that a bit, though. As fixes to the explanatory
documentation happen quite frequently to classes and methods all over the
place, we’ve decided to generate the JavaDoc from ‘mainline’ periodically and
upload that instead. This means that there will, of course, be descriptions of
some methods which aren’t yet available in a released version of the library,
but they will clearly identifiable by virtue of having a @since tag showing
a version number greater than the most recent release. We’ll revert back to
more traditional behaviour once we hit 4.2.0, but in the mean time we can give
people access to the best information we can online.
The idea of having up-to-date illustrations of the various Widgets has proved popular, and we’ve continued to update the suite of snapshots. Doing that is also tedious, but it does provide a good opportunity to test APIs we are exposing especially where unit tests are less suitable.
Looking ahead
Almost as complex as the TreeView / TreeModel API are GTK’s powerful TextView / TextModel classes, collectively a Widget used to display and edit large text documents. Working out the java-gnome coverage for TextView will take a fair bit of consideration, but TreeView provides a road map, and, as with the coverage in 4.0.5 and 4.0.6 (which was driven largely by existing applications we were porting), we have some significant uses of GtkTextView which will guide us on our way.
The next release will also feature significant work outside of GTK; we should
be in a position to merge our coverage of the excellent Cairo drawing library
soon, and likewise we have tentative work in place letting people store
configuration and settings data in GConf. Both the ‘cairo’ and ‘gconf’
branches need more QA and documentation work, but they’re looking good and will
definitely be featured in java-gnome 4.0.7.
You can download java-gnome from ftp.gnome.org or easily checkout a branch from ‘mainline’ using Bazaar:
$ bzr clone bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome
Well, now that I have this out of the way, I can finally stop worrying about having so much unreleased code and get back to the business of doing what I do for a living.
On a personal note, I mentioned that much of this coverage was driven by one of our legacy apps. About half way though this cycle, however, we decided we would be abandoning that program. Needless to say, it was more than slightly depressing to be putting so much work into writing new coverage for java-gnome in order to port such a large codebase in the certain knowledge that the application was not going to be resurrected after all, especially as we have not yet managed to raise any revenue to offset our costs in taking on the Java bindings for GNOME.
Cognitive Dissonance.
Nevertheless, I kept at it largely because getting that app to run again represented a good test of the quality and comprehensiveness of the Java bindings. It needed doing, and that has ultimately been the motivation behind all our work re-engineering java-gnome. I gotta say it was wonderful seeing that program come back to life bit by bit as the errors slowly fell away as missing classes and methods were added to the library. That monster running again after almost two years represents the 4.0 version of java-gnome having surpassed the level of coverage that we used from the old 2.x version, and that’s something to be very positive about indeed.
Of course, now all I have to do is to continue to resist the temptation to go back to working on that beast. :) No, better things to be about.
AfC
Fri, 25 Jan 2008
The arcane secrets of hash-bang
I’ve been working for a while now prototyping various different domain specific approaches to modelling software configuration information. Most of these involve putting the configuration data in the body of an executable script. To that end, I’ve been digging in to how interpreted scripts actually work on Linux and other Unix-like operating systems work.
#! interpreter
Anyone who has ever written a Shell script, Perl program, or Python program is familiar with #! lines:
#! /bin/sh
#
# A program to do something very special.
#
echo "Hello World"
and
#! /usr/bin/perl
#
# Another program to do something very special.
#
while (<>) {
print "Hello World\n";
}
etc. The program mentioned after the magic #! characters is the program that will interpret the script. There are many gotchas with that (notably portability concerns owing to the fact that some idiotic flavours of Unix don’t put Perl in /usr/bin, that sort of thing)
I always figured that the script file got piped by the OS into the interpreter on stdin. A reasonable guess given the way that most of the tools we use work, but it turns out it is nothing of the sort. Every time I tried to write an interpreter (in C) I got stuck.
What threw me off was that cat works as an “interpreter”:
#! /bin/cat
This is the script body
which will happily be sent
to stdout
If you put that in a file called script and run that from your terminal, then sure enough,
$ ./script
#! /bin/cat
This is the script body
which will happily be sent
to stdout
$
which of course is exactly what would happen if you did:
$ cat < script
#! /bin/cat
This is the script body
which will happily be sent
to stdout
$
and that’s what totally had me on the wrong track. I figured that the interpreter on the #! line was being fed the body of the executing file on stdin. Nope.
Seek and ye shall find, sort of
I thought that I might be able to find out what was going on by reading the code of an interpreter program. I started by looking at the sources for /sbin/runscript (which is on the #! line for all of Gentoo Linux’s RC scripts), expecting that to be quite simple. It was simple. Too simple. All it does is some environment filtering and then fires off bash to run /sbin/runscript.sh (in other words, it’s largely a workaround for the fact that you can’t actually make a shell script itself an interpreter). Nothing at all in there about reading stdin. So then I looked at the source code for Perl (Whoa, there’s a beast). Nothing obvious there either. Lots of stuff about reading from stdin but nothing about that being the origin of the script to be executed. A lot of messing around with argument signatures though.
#! is not exactly the easiest term to put into a search engine. I did, however, happen to know that one of the ways #! is pronounced is “hash bang” (being two common names for the respective characters, though lots of old suspender-snapping sandal-wearing bearded Unix freaks would, I’m sure, tell you with great passion that it has to be pronounced some other way). Searching on “hash bang” brought up lots of arcana, including something that lead me to an obscure article by one Andries Brouwer on the parameter signature at invocation wherein I discovered that there is a calling convention for how arguments are passed to the interpreter program being invoked.
It’s a bit complicated, since you can have command line arguments for both the interpreter and for the script being run. It goes something like this. Let’s say you have an script that begins with the following:
#! /path/to/program -v -d
(with -v perhaps meaning “verbose” and -d perhaps meaning “debug”) and you have it in a file called ./script, then running it will actually cause program to execute. The trick is, with what arguments? Check this out. If you do:
$ ./script -p -r
(with -r and -p, for the sake of illustration, perhaps having the same meanings as cp, that is “preserve” and “recursive” respectively) then when our interpreter program is executed, it will be invoked with the following arguments:
/path/to/program -v -d ./script -p -r
the mapping is a bit obscure. It’s actually:
| argv0 | argi | argn | args… | |
argv[0] | argv[1] | argv[2] | argv[3] | argv[4] |
/path/to/program | -v -d | ./script | -p | -r |
(to use the terminology in the above link). This all shed a little light on what I’d seen in runscript.c and perl.c, but still not a single mention of the script being fed in on stdin. So I pondered that for a while longer, until finally the light bulb went off.
Eureaka & Company
The reason I couldn’t find any mention of ./script being fed in on stdin is because is is not fed in on stdin. You don’t need it to be: you’ve got the name of the script file fed to you in your interpreter’s argument list (from the above example, it’s in argv[2], one happy looking string containing “./script”). So read it already!
FILE* body;
body = fopen(argv[2], "r");
...
and ta da, that’s where you get your script’s program body from. Now you can at last get on with parsing your script, and running it.
Most big programs spend lots of time munging the argument list, dealing with the fact that argv[1] could be full of all sorts of stuff jammed into, or nothing, etc. The whole thing goes from elegant to clumsy when you discover that if there are no arguments to the interpreter on the #! line then the script file will be in argv[1], and it goes to nightmare level when you look at the list of variations in behaviour across different operating systems, compiled by one Sven Mascheck. Nonetheless, the interpreter is your program, and presumably you can recognize, parse, and skip over zero, one or more arguments to yourself before deciding you’ve reached the name of the script. Judicious use of argv++; argc--; is your friend here, apparently.
Anyway, this all explains why my cat example was working but my own efforts were not. cat is not reading data being fed to it on stdin (which is cat’s behaviour if you run it without any arguments), it’s being executed with an argument, namely ./script as argv[1], ie exactly the same as:
$ cat ./script
#! /bin/cat
This is the script body
which will happily be sent
to stdout
$
But now that I know what’s going on, I can write my own interpreter.c:
#include <stdio.h>
#define LEN 128
int main(int argc, char** argv) {
char buf[LEN];
FILE* body;
body = fopen(argv[1], "r");
while (fgets(buf, LEN, body) != NULL) {
printf("%s", buf);
}
fclose(body);
return 0;
}
and if I compile that to interpreter, then I can write a domain specific language that is interpreted by this program, say:
#! ./interpreter
This is a test of the Emergency Broadcast System
in a file called script, then, at last,
$ ./script
This is a test of the Emergency Broadcast System
$
Yeay!
Ok, so that’s cat, but cat is the Hello World of input/output. :) The real point is that running script caused interpreter to be executed, and interpreter got at the body of the script that was “run”, and was able to do something with it. Onwards at last.
AfC
Comments
Julio Merino Vidal wrote in suggesting:
Take a look at NetBSD’s
script(7)manual page for some more details
about how that is supposed to work and some things you must consider
for portability (such as being able to feed a single argument to the
interpreter through the#!line, or the maximum length of it).
Updates
Quite by accident, I just came across the related information for Linux; see the execve(2) man page for
a succinct treatment of both exec()‘ing in general, and the topic of interpreting scripts.
Thu, 24 Jan 2008
Free Range Software
Jon Hall writes of his experience in a restaurant talking with its owner about “Free Range Eggs”:
“… but we have to charge money for our eggs. People who don’t acknowledge that just do not want to understand the term ‘Free Range’ for what it really means … better eggs, and changing the term will not help that.”
The fact that the discussion started because of maddog’s suggestion that maybe they should be called “open range eggs” to eliminate the confusion is not the point (“that’s silly” the owner said, “everyone calls them free range eggs”). The term we use, Free Software, has a bigger problem. Consider the difference between:
- Free Range Eggs
- Free Eggs
Clearly, the term is “Free Range”, and applies as an adjective to “Eggs”, whereas the latter really does mean “free eggs”. Now consider this:
- Free Software
There’s something missing, and so the term free gets connotated as having to do with price.
No, I’m not about to say that we should call it Free Range Software [and while “let it run free!” is a lovely metaphor, I don’t quite think we want to be associating our work with chicken farming :)]. Perhaps someone will come up with an intermediate word that will do the trick. To be honest, though I’ve pretty much given up on the term Free Software; I write Open Source software, and the cause I advocate is Software Freedom.
And when people still stare at you blankly, you can say “you know, like Linux” and watch as comprehension dawns. To be sure, they probably still don’t get it, but chances are you’ve got more important things to talk about, and getting on with it is going to do you — and logiciel libre — a lot more good than getting lost because of the insufficiencies of the English language.
AfC
Thanks to Atul Chitnis for having passed on the link.
Wed, 16 Jan 2008
Reusing Experience
I came across an interesting comment yesterday:
The documentation doesn’t help you much though. First, it is not sufficient and second (and important) you do not learn much from the documentation.
Thankfully, you have the source code and I really appreciate the source code of Eclipse is open. That’s because only from source you can learn as much as necessary. And this fact leads me to think more and more that open source is not about “reusing software” (commercial companies do that as well) but about “reusing experience” which is hidden inside the source.
I have the strong belief that people who write the software are more important than the software itself and by looking to the source code you can gain at least part of experience of people who wrote it. That’s the power of open source, that’s “reusing experience” concept at work!
This observation was written a few years ago by one Alexander Dymo who was expressing his amazement at the whole Software Freedom thing, especially the hands-on side of it. And as for his “people are more important than software”, well, hey; I couldn’t agree more. Enlightened organizations that want to preserve their strategic advantage understand that the people who are capable of working with such code are their competitive advantage. They are the ones who can reuse experience and leverage the power of the most wide reaching and enabling social phenomenon we have ever seen: the global openness movement.
Towards a technical definition of Open Source
I’m on a bit of a kick at the moment working to elucidate a practical technical definition of Open Source (ie, complementary to the necessary legal foundation which enables Free Software and the requisite social interaction which is at the heart of global Open Source communities). Comments like the one above are helping refine my thoughts on the topic: yes the interaction of licence and copyright law gives us structure, and yes communication between people distributed the world over is the genesis of the sense of community, belonging, and accomplishment which is the rich social fabric within which our software development takes place, but there is also a pragmatic aspect: can you actually work with the source code, get right into it, experiment with it, break it, and do crazy things with it?
That the four GNU freedoms stipulate that this must be “permitted” doesn’t really change the fact that there are practical prerequisites. Can you easily get the sources under development? Do those sources actually build? Is there a clear mechanism for contributing source back to the project and are they actively facilitating such contributions?
The source tarball as primary release artifact
The biggest give-away is whether the primary release artifact is source or an opaque binary.¹ Especially in the Java world but elsewhere as well, there is a surprising amount of activity for which, despite the fact that it may legally be Free Software and its loud proclamations to being Open Source, it remains clear that they just don’t get it: there are a huge number of projects and products which only do their releases in binary form. Bad sign when you start calling it a “product”, I think. In a frustratingly large number of cases, if you try to actually work with their code you will discover that it doesn’t actually compile! In extreme, there are statements like:
We distribute source but never claimed that you can build it out of the box. We don’t have time for such things.
I didn’t believe it when I saw it, but one of the hackers of a supposedly Open Source project actually said that in response to a bug report. Astonishing.
Being able to duplicate the result is a rigour that goes far beyond software; indeed it has been the bedrock of science — and human progress — since the dawn of the age of reason. Back to the present day, it has suddenly become obvious to me that the fundamental technical difference between proprietary Unix from the commercial vendors (not to mention proprietary operating systems from Microsoft and Apple) and Linux is that in our world (taken to mean the entire continuum of FOSS communities) the primary release artifact for all upstream projects is a source release (these days it’s typically in a .tar.bz2, but whether it is that or .zip or whatever else isn’t terribly relevant) that you can build. Not a tarball full of already built .class files and .jar files. Not a “source .zip” for Eclipse. Not a self-extractable full of .exes and .dlls. No. A source release is source code that someone else can build, right out of the tarball. THAT, ladies and gentlemen, is the technical definition of Open Source.
I’ve started to realize that this area is a big stumbling block. People I collaborate with in (upstream) global projects like GNOME, Free Java, Bazaar and elsewhere take the efficacy and primacy of source releases entirely for granted. But a number of clients that my firm is working with to enable Open Source often just don’t get why they should be doing source releases — and resist it.
Whether you buy into Software Freedom or not is a different topic (and your decision, not mine to impose on you), but if you’ve got a software project for which you’ve decided to free the source, you want it to be successful, right? Success is a project that which inspires user enthusiasm, which the major distributions can package and ship without hassle, and around which a vibrant community of developers grows, ultimately fostering new contributions. There are a lot of steps along the way, but a buildable source release is, in our view, the technical bar you’ve got to reach. Otherwise you’re not making releases of the software, you’re abandoning it. And your users.
AfC
¹Note that this is different from a Linux or Unix distro shipping binary packages — no matter if it was Fedora, Debian, Gentoo, FreeBSD, OpenSolaris or anyone else, they should still have been able to build their package from source. It matters little whether that compilation took place in a build farm somewhere or on the user’s desktop (which is what happens in the “binary” distros when someone wants to work on the package or the project itself) — the key point remains that we can build the software if we want to, and are not forced into relying on someone else’s proprietary (and more to the point, unavailable) tooling. If you can’t build it, it’s not Open Source.
Fri, 11 Jan 2008
Fascinating thread: FOSS Quality Control
A long-time critic of things Open Source showed up on the Classpath project’s mailing list and asked some rather provoking questions in a thread titled “Quality control and FOSS rant”. He at least ended with: “I suppose this is more of a troll than a criticism, sorry about that.”
Despite the flame bait, the thread contained some surprisingly insightful replies. It’s always great to hear some of the top software developers in the world noting their motivations and why they believe what they do works.
From Roman Kennke:
Both approaches (closed and open) apparently tend to produce relatively high quality code (or really crappy code, happens in both camps), where with the closed approach the developers (or vendors) have to take over 100% responsibility (because the end user has no way to interact with the development), which usually makes things very formal and slow, where the open approach relies very much on the end users reporting problems. In most active projects these are fixed really quickly, giving both the developers and the end users a warm fuzzy feeling ;-)
From Andrew John Hughes
There’s a lot to be said for feedback and interaction with your users that’s often overlooked. All the ideas of complicated quality control processes in the world is not going to make a user feel as loved as seeing someone responding quickly to their bug and fixing it in a short space of time.
From Mark Wielaard, a remark on the complex administrative process used by the project to review contributed code:
We do have a flow chart that people have to follow when contributing… It is all very formal really: http://gnu.wildebeest.org/~mark/patch.png
and from Archie Cobbs, a reminder about the track record of a certain formerly proprietary process on solving bug desperately desired by their user community:
The number #1 voted bug in their bug database has been unfixed for over 5 YEARS!
The comments on that bug make for hilarious reading, but the bigger point is this: the identity of the people making the decisions about the relevance of the issue are hidden. That sort of thing doesn’t inspire much hope for people on the outside. It’s not like we’re talking about national security or the future of western democracy; it’s a bug report that turned into a feature request for a piece of software that many, many people depend on! No one likes to be fed the line that their problem is so Top Secret that they won’t be told when (or even if) the problem will be addressed. The cloak of anonymity strikes again.
Fascinating thread.
AfC
Don’t feed the locals
Spend a few weeks hiking in Tasmania over New Year’s…
Hazzard beach, looking south to Mt Freycinet and Mt Graham in Freycinet National Park, Tasmania, Australia.
No water here, or (anywhere else in the park for that matter). It’s only 600m up, but it’s a fairly steep climb. Lucky to have had gorgeous weather, but whoa was it hot. Packed in 10L of water. Heavy. Still ran low; should have brought even more. I used to think those pocket desalinaters were gimmicks, but I’m having second thoughts now.
The view east from Mt Graham, Freycinet National Park, Tasmania, Australia.
I like cooking pancakes when I’m trekking and make sure to bring maple syrup along, of course. Apparently, the wallabies at Wineglass Bay also like pancakes. The pot lid kept this one out of the batter, but didn’t prevent it from feeling free to lick the spoon.
Breakfast at Wineglass Bay in Freycinet National Park, Tasmania, Australia. Photo by Katrina Ross
There are some astoundingly beautiful National Parks in Tasmania, although you have to drive for ever to get to any of them — forget about public transit; you’re renting a car so you can park it for a week when you get there. Great.
Worth it for the views, though. You get to missing mountains, sometimes.
Looking southwest from Mt Rufus in Lake St Clair National Park, Tasmania, Australia.
You can also forget about seeing any old growth forest; while the National Parks in the state cover an impressive amount of ground, the formation of these reserves appears to have come long after the bulk of the big timber was removed, and logging continues to happen in protected areas. From high up on the mountains you can plainly see the clear-cut areas, which is a shame, because properly managed forests can be a renewable resource. The trouble, however, it takes on the order of 70 years before a plot is ready for harvesting. Most people aren’t really that patient, and clear cutting is often “easier”.
What really gets me, though are the “state forests” which are marked as “multi-use”. Funny how there aren’t many trees left. Same thing happens all over - Canada’s “National Parks” are “multi-use”; take a drive through the Rockies from Calgary to Vancouver and you’ll keep coming to National Parks that are “temporarily closed for logging, no camping” and clear-cut. Then there is the activity of the American federal “Forestry Service” (which is in the business of building roads so that it easier for logging companies to mow down said forests). Australia, it seems, is no different.
And this from a guy who is otherwise pro-logging. Lumber is an essential construction material, and paper will remain the essence of recording and disseminating information for a long time to come. An immense number of jobs come from their production. But if we want to have those jobs in the future, and if we want the forests to continue to be viable and not have all the soil wash away in the next hurricane, the forest industry must be incented to contribute to the sustainment of the land. It’s pretty simple: no soil, no new growth of any kind, period. The only thing I can think of is something like a reverse carbon tax: for every large tree of a certain diameter, etc they can prove they didn’t cut down, they’d get a tax credit. Somehow, though, I’m guessing that all that would result in is plenty more bureaucracy but not a whole lot more in the way of sensible land management.
Anyway, I digress. The things you think about when you’re walking.
Approaching Russell Falls in Mt Field National Park, Tasmania, Australia.
Beautiful.
AfC
Fri, 21 Dec 2007
Innovative uses of bobcats
Ordinarily Rail car movers (aka HiRail trucks) are either enormous ugly yellow painted beasts (which are inevitably maintenance nightmares) or are glorified pickup trucks (which, while great for zooming around to fix a remote signal, that haven’t much hope of actually moving anything). This week, though, I came across an unusual approach to dealing with moving small numbers of cars in an private industrial rail yard that might do the trick. A Canadian company called Brandt Equipment markets a vehicle called the “Rail Yard Boss” which is nothing but a John Deere front loader adapted with rail wheels and a coupler. Photos from their website (I don’t live where there is so much grain, you know?):
The interesting part is that it uses its hoist to transfer some of the weight from the car its pushing to itself, thereby increasing the friction between its wheels and the track, improving its traction as a result. That’s smart.
The advantage over a real switcher, of course, is that it can just up the steel wheels, pivot, and drive out of the way.
On the other hand, given that this thing can only push a max of 5 loaded cars, you’ll probably end up needing a real switcher sooner or later anyway (and what yard doesn’t have a spur as a switching lead to get things out of the way?). Still though, pretty neat.
AfC
Longevity
Her Majesty Elizabeth the Second, by the Grace of God of the United Kingdom, Canada, Australia, and her other Realms and Territories Queen, Head of the Commonwealth, Defender of the Faith, etc has now become the longest-lived monarch since the union, having today surpassed¹ her great-great-grandmother Queen Victoria, who lived to 81 years 7 months and 29 days. Congratulations, Ma’am!
Given the legendary determination of our Sovereign, I would imagine the real goal she is aspiring to reach is 10 September 2015. Should she still be alive then the length of her reign will have exceeded those of both King George III and Queen Victoria.
It’s always a bit weird to commend someone for having gotten older. “Congratulations, you’re not dead yet. Well done, there.” seems a bit odd, really, seeing as how there are so many things that just aren’t in our control. Celebrating birthdays remains fun mostly because it’s an opportunity to exchange presents, get sloshed, etc. But birthdays aren’t the only milestones of longevity, and this particular mark is a bit more exclusive than most!
AfC
¹This according to an article at Wikipedia listing British Monarchs by longevity. Hard to know who has time to dig up and collate this sort of data, but hey.
Tue, 18 Dec 2007
On Bridges
Doing some background research for a client I came across a surprisingly comprehensive introductory page about the basics of bridge design. This isn’t Civ Eng stuff by any means, but it’s a great overview of the taxonomy of bridges, with some excellent illustrations:
along with admirably concise descriptions.
The source website is an exhaustive survey of bridges in and around Pittsburgh, Pennsylvania, USA, maintained by one Bruce Cridlebaugh. Though I am sometimes moved to wonder what drives people to such exhaustive efforts, it’s not like people I hang around with aren’t equally obsessed over obscure interests. :)
As websites go, it’s actually surprisingly well laid out. The intro page has a graphic explaining to visitors how to use their site:
“…To choose from a comprehensive listing of structures, (1) go to List by Location, (2) choose a map area, then (3) select from the list for structures in that area…”
Granted, enthusiasm to use this technique oneself is tempered by the obvious hassle of having to create such a graphic in the first place (not to mention that screenshots have a bad habit of getting out of date the moment you alter your stylesheets), but it is nonetheless impressive information density.
AfC
Fri, 14 Dec 2007
Darth Claus
The town I live in held a family evening of Christmas carols at the local cricket oval last night. At first it had promise of being more than the usual amateurish affair that seems to be the lot of small communities, with a large choir and a proper orchestra.
But as the second half opened, instead of playing carols, they played the theme to Star Wars. Star Wars?!? And then Santa Claus appeared. At first I was a bit annoyed at the lack of musical taste, but then a broader truth became apparent:
Santa Claus is a Sith Lord
Suddenly, everything that drives you nuts about the excesses of the Christmas season makes sense. The endless shopping, tacky decorations, and worst of all the fact that the stores start playing Christmas music in October — it’s all an evil plot. Not to mention the whole flying through the air and visiting several million people an hour thing. Only a master of the Dark Side could manage these feats. Darth Claus, Lord of the Sith.
Image from a blog post a few years ago by Nikolai Ormazablev writing a review (in Spanish) of Revenge of the Sith. How did he know?
:)
AfC
Fri, 07 Dec 2007
Talking about getting involved
I’m giving a talk at foss.in tomorrow, Saturday, at 10am:
I realize that this is only of interest to people in Bangalore this week and reading planet.foss.in, but here’s my abstract:
The essence of open source is not USING free software, but CREATING it. The purpose of this talk is to teach you how to contribute to open source projects.
Admittedly, getting involved isn’t as easy as it could be, but that’s often because you haven’t had an opportunity to learn how to go about participating in a project’s development.
This talk is aimed at people who probably already know something about Linux, already know how to program, and already believe how important free software is… but haven’t yet made the jump to being contributors themselves. And that’s LOTS of people. So, it’s time to become and open source hacker.
It’s easy to talk about “interacting with the community” and “filing bugs” and “submitting a patch”, but until you know how to do this, it can all be a bit daunting. So we are going to be do all these things, TOGETHER, on stage, LIVE. We’re going to file real bugs about real problems in real open source projects, and then we’re going to fix ‘em, right there on the screens in front of you.
How do you contribute? You have to check out source code, learn how to build open source software, run it, test it, and debug it… but it doesn’t stop there! Then comes creating and sending patches, receiving feedback from the upstream project, dealing with rejection, but finally when you’re successful exalting your success.
For the beginners in the audience we’ll be demonstrating what you do to submit to upstream, but we’re also going to show what the upstream people do when you make that contribution. So we’ll see the whole open source process, beginning to end.
Take joy in your work, do your work in the open, and open it to the world. Do that, and you ARE an open source contributor.
Actually, it’s not just me — my good friend Shreyas Srinivasan and I will be doing the demos jointly. So the best part will be watching the two of us making fools of ourselves on stage.
I hope you can make it!
AfC
P.S. 10 am means Ten O’Clock in the morning. People who are late don’t get any free chocolate chip cookies.
Tue, 04 Dec 2007
GNOME Mascot?
It’s the GNOME Project Day at foss.in!
Máirín Duffy talking about getting involved in art, marketing and branding in GNOME … question from the audience: we have the GNOME foot logo, but why doesn’t GNOME have a mascot?
I asked quickly in #gnome-hackers and James Henstridge suggested that the mascot was:
“whatever made the footprint”
It’s a giant invisible beast! :)
AfC
Category Specific Feeds.
Use these links for an RSS or ATOM feed limited to this category and its descendants.
Technorati Profile
