Eclipse... now it runs ok, but...

Yes, with heaps of RAM and a ulimit higher than 90% of the apps I execute, eclipse runs up... Don't get me wrong, it can have 2gb of RAM if it wants, if it works well...

The emacs bindings will leave you in despair. Some bindings that an emacs user expects to exist at a fundamental level are C-x C-b which almost happens. But you are left with a dropdown of buffer names and the most recent non active buffer is not highlighted by default.

Cap SenSitive search and replace seems to be coming in 2008. And although you can start an incremental search with C-s without a dialog hitting C-s C-w C-w will not grab a nice chunk of identifier to isearch-forward with. The s-and-w key being so close one quickly gets into the habit of that for isearching. The search and replace bug makes me wonder how folks actually use eclipse to edit code, though I guess you don't miss what you didn't have.

So ye olde emacs will likely live on for another 2-5 years as my C++ editor of choice. Either that or somebody will drop enough cash to actually get eclipse-emacs working to some retro level that can be somewhat tolerated. I guess emacs users are not in the target demographic of eclipse anyway.

Keeping up with the joneseses

After noticing that the boost::serialization binary format is platform dependent recently some folks told me that I should maybe just use the text format for b::serial. The claims of relative efficiently being hard to tell came up of course. So this time I actually benchmarked with valgrind.

For text archive, 223,879,650 instructions and 2.97% overall runtime but using binary archive 2.1% relative runtime and 140,057,074 instructions. The relative runtime is for a short app interaction, not just application startup.

Since the b::ser is only used for loading data that is changed very infrequently but is loaded all the time I might end up having the text version as a fallback just in case you change architectures libferris can try to load the binary version, fail and then try to load the text version and force a resave right at that point. This means loading after an architecture switch will be about 5-6 times slower, but only the first time you run any libferris app after the arch change.

Fun to look ahead to the maemo / moko invasion of the ferris.

I added a few little optimizations here and there to libferris for the next release too. Many of these make the filemanager more responsive in some use cases I have... YMMV.