Older blog entries for monkeyiq (starting at number 67)

Novell's VFS

At Edd's blog there is mention of Novell open sourcing their VFS and the possibility to integrate it into GNOME. Very interesting, I should add support for mounting Simias to libferris hopefully sometime shortly after they release it. I suspect it might be somewhat hard to install Simias at first though (maybe they want to beat libferris for difficulty to install ;)

Does make me wonder a little about the whole 'sharing VFS' thing that comes up from time to time (search freedesktop.org's mailing lists). As to, at the level of an Extended Attribute extractor (like something that extracts EXIF data from exif/jfif images) whether there can be code sharing. I think this is the most realistic level where the VFS systems can interoperate as there is an EA interface and a binary chunk that data is extraced from. Though even at this 'grass roots' level libferris differs from C based VFS systems in that data is accessed through the C++ IOStreams interface... though bolting a obj->read( offset, count ) to that should be trivial.

On the flipside, I've been adding support for Adobe's XMP metadata embedding to libferris. This should make for a reasonably kickass /usr/local/doc search engine with the new EA from pdf files and the fulltext indexing of HTML and PDF etc that ferris already does. I think I've managed to sniff out most of the embedded RDF standards now, after XMP there is the jpeg COMMENT1 block RDF standard that I've yet to code support for.

I might have to make mod_ferris for apache soon so that a web interface to the EA/indexes can be created... maybe.

Dude, where's my filesystem

Trying to use evolution-data-server in little clients, not going all that gleefully as yet... must mount evolution... must mount ...

Have now returned from icFCA04, the international conference on Formal Concept Analysis which was in Sydney this year. Interesting mix of computer sci folks and raw maths guys there. I suspect that next year I'll make my talk involve much more pictures and math descriptions of what I am thinking rather than near on code level talks that I tend to be attracted to.

Went along to the SLUG while I was there too. Some very interesting chats seem to always be waiting at that user group... Chatted with jdub for a while over dinner about gnome and explained some of the crack that I've sprinkled over libferris and showed some lattices from FCA that I plan to make into the future of n-dimensional filesystem browsing (though not in those terms ;). From what I've herd there are some very interesting plans for the future of gnome-vfs... Be interesting to chat with some of the dudes planning to extend g-vfs as I think that the open source community needs to be moving fairly quickly to create an opposing system to WinFS. Parts of WinFS seem really cool and we definately want that coolness too (though hopefully we can improve some parts of WinFS that are not so cool).

Top of the reading heap

Computer Graphics: Principles and Practice in C, 2/E
ISBN: 0-201-84840-6
Publisher: Addison Wesley Professional
Copyright: 1996
Format: Cloth; 1200 pp
US: $79.99
<already read parts, very good stuff, well worth having>

Principles of Data Mining Written by David J. Hand , Heikki Mannila , Padhraic Smyth Published by MIT Press (01 August, 2001) ISBN: 026208290X USPrice $58.0 <read first 150pp. very interesting>

Hmm, should really try to get more sites to publish information about libferris. Seems that /. is loving stories about similar tools with their past posting on Gnome-Storage and now this mentioning some of the WinFS stuff.

I've been meaning to brew up a public document comparing libferris and plans with the WinFS stuff on MSDN-TV, though given a limited time budget...

ACE logging @ osnews.com

Here is the link.

From the first page

"However, an important factor in the logging facility's design is the ability to effectively "no-op" the logging statements at compile time."

Note that a stream based compile time on/off method works easily

// in header
#ifdef NDEBUG
  #define MY_DEBUG if( 0 ) cerr
  #define MY_DEBUG if( should_runtime_show() ) \
    get_real_stream_reference(); \
  else \

// in program MY_DEBUG << "foo" << endl;


The next release of ferris will have OCaml language support. I now have a little code snippet working using SWIG for the binding. I'm not entirely happy with the syntax of the OCaml interface though. Also I've got to check if there are mono argument functions which are setup for composition or not, I suspect not. The latter might not be a drama, but the syntax is a annoying issue.

There are some OCaml side tricks that help the syntax but its still obviously non-native. It does do away with the nast C_list construction being everywhere. I might end up making a little shallow object wrapper that uses the SWIG interface but presents a native OCaml object interface to the rest of the ocaml world.

The little snip I have at current for testing is

(* This example was mostly lifted from the guile example directory *)

open Libferrisocaml (* open Example *)

let foo = _getTime ( C_list [] )

let _ = begin print_string "Current time in UNIX epoch seconds..." ; print_int (get_int foo); print_newline () ;

print_string "Current time in human terms..." ; print_string (get_string (_toTimeString( C_list[ foo ] ))); print_newline () ;


let c = _Resolve( C_list[ C_string "/tmp/play/signtest.gpg" ] ) let _ = begin print_string "Context::test " ; print_newline () ;

let earl = (invoke c) "getURL" (C_list [] ) in begin print_string "URL:"; print_string (get_string earl); print_newline () ; print_int (get_int c); print_newline () ;

let md5 = _getStrAttr( C_list [ c; C_string "md5"; C_string "" ] ) in begin print_string "MD5:"; print_string (get_string md5); print_newline () ; end end end


Made another release yesterday, mainly fixing a fix little regressions that I found when writing an article about libferris.

Also converted a few things in configure.in to try to be a little more friendly for systems that are not 100% setup properly for ferris, the nerve of some folks not having a ferris friendly setup :)

New release of libferris and ego today. Finally made the EXIF tag stuff public.

Its a shame that I think almost everyone will not be enjoying the little things I've added to the branches:// filesystem, aka branch filesystem. The joy of leaving behind many cleanly layered trees (ie. raw, filtered, sorted) and now allowing arbitrary branching at any level. So much to add for this new idea but it will be core to the lattice presentations of the future I suspect.

dbXML award

Won this a while ago but I think my blog should mention it for the interested readers :)

Sleepycat DBXML Innovation Awards.

And I have my dbxml shirt to really geek it up in style at conferences ;) thanks sleeycat.

jpeg/jfif vs. jpeg/exif

Read up a fair bit on the differences between exif and jfif about a week ago. The most interesting find for me was that exif allows a little jpeg to be embedded into the main exif metadata marker. This sort of solves the thumbnail issue for directories of images fairly cleanly.

In light of the new discoveries I've added exif support to libferris for both the exif metadata like what camera was used and all the other stuff and for embedded thumbnails. You can also touch an extended attribute to update the thumbnail for a file. This uses young rasterman's epeg library to generate the new thumbnail fast. Just to quote from raster's page epeg can thumb at about 25 times the speed of nautilus. So now ego can thumb at that rate ;)

As the last paragraph let out of the bag, ego and the properties widget in libferrisui have support for the exif thumbnailing.

I've yet to hack in support for XMP and rdfpic which basically allow one to embed RDF into a optional marker in the jpeg/jfif or jpeg/exif file. Markers in jpeg are just little chunks of data which have a size after an ID for the marker. So you can skip the exif marker in jpegs so that feh and other viewers are happy to view jpeg.exif. There is a little change in the main jpeg identifier for exif files but most things are happy to work with exif.

Glad to get the 25th's post off the top of my diary, it would get depressing to see it there very long. (as an aside the experiment failed as expected).

58 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!