Where sassy women wear jaunty hats.
Shameless Self PromotionPosted by pookzilla on May 27, 2005
Just a reminder to any Eclipse keeners to get out there and vote in this years JDJ Readers’ Choice Awards. If you don’t vote for Eclipse I’ll kill a puppy.
Ok, I wont kill a puppy.
I might hug one.
Don’t make me do it.
Attention Mac HeadsPosted by pookzilla on May 25, 2005
The end of 3.1 is seeing a lot of effort directed to fixing certain polish issues. One such issue is that we’d like to ship the OS X build such that the eclipse folder has a custom icon. This is described in bug 95353. This is proving problematic, however. The OS X build is built on a non-OS X platform and we’re having a real problem trying to package a folder such that the OS X resource forks are maintained. Anyone have any ideas how we might accomplish this?
Wakka Wakka Wakka!Posted by pookzilla on May 23, 2005
So the 3.1 release is rapidly approaching. As important milestone and candidate dates are approached, developers can become frayed. Sometimes we’re short-tempered, sometimes we’re blunt, and sometimes we’re just jerks. We all know it, and we all generally recognize it when it happens. We each have our own way of handling it in general. One way I cope is by getting goofy in bugzilla. I try not to let it get in the way of work, but when I see an opportunity for a laugh I generally go for it. Given that I handle the bug triage for the Platform-UI team I get plenty of opportunities. In addition to participating directly, I also like to keep tabs on funny bugs owned by other people. Some choice favorites of mine are 59425, 68545, 76759, 100918, and 112631.
Does anyone else have any humorous Eclipse bug reports or even humorous comments on otherwise serious bugs?
Supporting Dynamic Bundle Loading In Your Plug-In (Part 2)Posted by pookzilla on May 8, 2005
Previously I discussed methods that plug-in developers could use to ensure that their model of the Eclipse extension registry stayed up to date. While this was the main thrust of the work we did in platform-ui towards utilizing the improvements in the core plug-in registry it was not the only motive. Memory footprint was also a concern for 3.1 and while we were refactoring the registries for dynamic support we kept this in mind. Previous to 3.1 the pattern in the UI was to read our extension points and fully realize any descriptors that they may represent. In 3.1 we tried to take the lazy approach to this. For instance, in 3.0 we would read the view extension point and create heavyweight descriptors for each view defined. We would pull out all strings from configuration elements and hold onto them for later use . In 3.1, the core registry has the ability to punt unused configuration elements to disk instead of holding onto them in memory. For this to be useful we had to ensure that we (UI) weren’t holding onto the String objects that they (Core) were smart enough to discard. Now instead of ripping out and holding onto all Strings we instead only extract those that are used often enough (or in particular patterns) such that it’s beneficial to do so. In the view descriptor example, we no longer read out the Strings for label, description, path, etc – only the identifier String is read. When any of the other Strings are required we delegate back to the originating IConfigurationElement (which itself is a lightweight handle) for the content.
While the above pattern doesn’t particularly help your plug-in act in a dynamic way, it does help to make it a good Eclipse citizen.
Next… cleaning up after yourself.
Hi! My name is Kimberly Horne and I have absolutely nothing interesting to say. Unfortunately for you I DO have an overpowering need to tinker with technology which is explains the presence of this blog thing. I mostly talk about games (video and tabletop), technology, tattoos, and my pets.
If you're an Eclipse user you may find my Eclipse category more interesting.
