| 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 |
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.
Wed, 26 Sep 2007
java-gnome 4.0.4 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.4 (26 Sep 2007)
Coverage increasing!
Most of our work continues to be on infrastructure and architecture, improving the code generator that outputs the translation Java layer and JNI C layer which allow bindings hackers to reach the underlying native libraries. Nevertheless, there have been a number of publicly visible improvements across the board, so we wanted to push out a release highlighting these contributions!
Documentation improvements
Continuing our effort to have extensive developer friendly tutorial style documentation, there have been major additions to a number of existing classes. Of particular note is the Window class, containing the various utility methods used to ask the window manager to do things for you (we’ve also started exposing some of the deeper parts of the GTK toolkit, though only a few things that were immediately related to window management).
While the topic of thread safety was discussed at considerable length in the last release, we have added some of the more relevant information to the code documentation to reinforce its importance.
New coverage
Numerous people have been hard at work developing new coverage. The standards
for accepting patches which expose public API are high, so it’s awesome to see
bundles accepted for being merged to mainline from new contributors Thomas
Schmitz, Wouter Bolsterlee, and Nat Pryce.
The infrastructure for a number of areas important to supporting applications including Menus, Toolbars, and Actions has been put in place.
A number of Container related Widgets have been added, though coverage is preliminary. There have, of course, also been a number of minor improvements in other existing classes, miscellaneous constants and wrappers around the stock item identifiers.
Internals
Vreixo Formoso carried out an important refactoring to the type database and Generator family of classes in the code generator, with the result that more of the array passing and out-parameter cases are now being handled correctly. This kind of work is usually thankless and taken for granted, but it’s hugely appreciated!
The real gains are in internal quality. A number of serious bugs and
limitations have been overcome (Glade is working again, for example). The
generated code now guards against improper use (you can’t pass a null pointer
unless it’s allowed by the underlying library). Related to this is handling of
“GError” — Java side, bindings hackers will get GlibException which they
can then re-throw as an appropriate Java Exception, say FileNotFoundException
in the case of not being able to open a file.
This all goes along with numerous build system fixes by Srichand Pendyala to make for an increasingly robust project. Thanks guys!
Looking ahead
As mentioned above, we have mostly been focused on areas other than public API, but it is expanding steadily. The hard work on infrastructure, however, is starting to pay off, and the next release should include coverage of TreeView, GTK’s powerful but complex list Widget.
You can download java-gnome from ftp.gnome.org or easily checkout a branch from mainline using Bazaar:
$ bzr branch bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome
Note switch to bzr:// protocol.
AfC
Bazaar 0.91 released!
Congratulations to the Bazaar team on the release of 0.91!
Stop using dumb protocols
Probably long overdue, but we set a bzr serve daemon running on our R&D site.
Hackers who had write access to create their own branches there used the bzr server automatically since they `bzr push bzr+ssh://... and can also use it for branching and pulling. Most other people, however, were doing an initial checkout via http:// because that’s the URL we published. Which wasn’t very nice of us: initial checkout time for java-gnome from using the dumb http:// protocol used to be 20 minutes (serious round-trip penalty when from Australia to Europe. Ouch).
Switching to bzr:// dropped the time to clone a branch to 1 minute 46 seconds… Sweet! And that’s even before the monster revision streaming and repository format performance improvements that are likely to land in the 0.92 - 0.93 time frame! Excuse me while I rush off to update our README and HACKING files :).
Yes, dumb protocol time was abysmal — But http is a convenience for when all else fails, and has the nice side effect of allowing people to surf your public branch’s code. The problem is that people don’t necessarily get around to putting the server in place (most people could if they tried).
AfC
Thu, 20 Sep 2007
Incremental performance improvement
In passing in #bzr this afternoon, Robert Collins mentioned that he had dropped commit time for the example case he’s working on from 29.5 seconds to 18.8 seconds. Nice!
I asked him if this was towards improving the time taken to import new (large) projects into Bazaar? He said yes, but pointed out that some of this particular bit of optimization also impacts normal incremental commits and merges elsewhere.
It’s nice to see smart people working on things that benefit in not just one but many places. I wondered, though, how to quantify the sort of improvement that Robert is working on. The obvious target is the time taken to do the task being optimized. The broader question of knock on effects would rely on a broader performance measurement suite. It’s not a simple matter of “just make it run faster” — you have to be concerned that fixing one thing doesn’t make other important cases perform poorly as a result.
That reminded me that this is one of the things that db4objects is really good at. They continuously use their “PolePosition” benchmark system to evaluate the impact of changes and [hoped for] optimizations across a wide range of scenarios (read performance, write performance, writing in highly contended environments, etc) as evidenced by Carl Rosenberger’s recent work on improving transactional performance when db4o is being used in an embedded (single VM) environment.
Obviously, the cost of premature optimization is lost developer time spent working on things that don’t matter (if you’re lucky) and this risk of wrong architectural choices (which have much greater consequence). But design choices are unavoidable; you face them every day and then have to live with the consequences.
This isn’t “bad”; you make such decisions for good reasons. Some of the projects we’re doing for clients at the moment involves assessing the complexity of different architectural options and what impact those choices have on developer effectiveness, future maintainability, present performance and how hard improving it will be down the road. It’s interesting work.
This is one of the things I really respect about the team of people hacking on bzr. They took the time to map out a really sound architecture, and have worked hard on developing really robust algorithms capable of dealing with the complex corner cases that arise when doing merges and working with repositories with wildly different performance characteristics (branching locally versus branching from a repository half way around the world; are you using the dumb http:// protocol, or are you streaming at wire speed using the bzr:// protocol, etc). They took some heat early on because the consequence of their focus on architecture and robustness meant that some operations were rather slow, but they have been improving by leaps and bounds as they turn their attention from internals to performance. It works, it works correctly, and increasingly, it works fast.
AfC
Thu, 13 Sep 2007
Git depends on RCS
Somehow, that says it all.
Apparently Git depended on the RCS package to get at certain merge functions. This is ironic, because RCS is a primitive 1st generation version control tool (sort of) that predates CVS.
AfC
Update:
- Dave O’Neill just pointed out to me that this dependency was actually removed in January ‘06. I looked around further and discovered that it’s the Debian “etch” package of Git 1.4.x that depends on RCS. This has been superceeded in “lenny” which presents 1.5.x.
Tue, 11 Sep 2007
6 years on
And they shall not grow old.
Mary Lou Hague, d. 11 Sep 2001, age 26.
Miss you, still.
AfC
Sat, 01 Sep 2007
That pesky security
Former Australian Prime Minister Paul Keating commenting on Sydney residents who are complaining about the inconvenience some will suffer as a result of Australia hosting this year’s APEC summit:
Grow up. Count yourselves lucky. Here you have leaders representing 60 per cent of the world GDP, a massive power grouping, coming to your city to discuss world affairs, and we think it’s a bother?
What’s really smart is that they made Friday a stat holiday for everyone who works in the city in order to alleviate the bulk of the inconvenience that would have otherwise been caused to people dealing with disruption to their commutes that day. Sweet! What more could you ask for?
AfC
Category Specific Feeds.
Use these links for an RSS or ATOM feed limited to this category and its descendants.
Technorati Profile
