Older blog entries for monkeyiq (starting at number 61)

OCaml

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 () ;

end

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

Release

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).

An interesting experament, I have 65 freshmeat subscribers to the libferris project. Assuming that half of them are starving students on peasent level one income and that I'm subscribed to the project aswell this allows 32 folks who could possibly make a $10-$20 donation to the libferris project.

Now surely that money is not much and is laughable in comparison to what an experienced C++ coder with similar qualifications to myself could earn commercially on closed source but relatively speaking the potential $500/yr that a small donation from half my subscriber base would make to my current situation would be great. It also gives some warn fuzzyness that folks are getting what libferris is about.

A little quote from a mail message that was highlighed to me

Particularly since building it into the OS or file system gets more end-programmers 
and end-users to use it (unlike libferris 
http://witme.sourceforge.net/libferris.web/index.html).
which can be found at: The reiserfs mailinglist msg link

I find it amusing that Alexander G. M. Smith doesn't consider LD_PRELOAD, NFS/CODA servers or indeed microkernel designs. Its not like libferris is by any means a statically cast code block that will never change.

Updated the papers section on the libferris site. More will surely apper there over time ;-)

Uploaded my old (as in a few months) SoGtk Coin3d widget port for GTK+2 to witme.sf.net download section. Will really like to merge this into the main Coin3d stuff so that Qt/GTK2 are sitting at the same level of support right out of the box, plus then Fedora guys can take it and Coin and make it available as default... grr, must have OpenGL support in more distros!

Yay, enabled donations for libferris website / my personal sf.net account. Be rather interesting to see if anything actually happens there. Like flying a kite in the eye of a cyclone.

/me pats shiney new kernel.

Took the low latency premempt kernel from

http://www-ccrma.stanford.edu/planetccrma/software/

Which itself contains many other nice patchies...

patched out the 2.4.22 user->root attack, added in device-mapper, evms-2.2.0 and XFS and created the killer kernel from hell.

Nice to have a kernel with capabilities support now too. Might get around to hacking up a sidepanel for 'ego' to edit capability assignments. The panel will itself require capabilities to assign and remove capabilties to other stuff of course :)

Now if only I can get rivatv and this crusty old 5900 to shake hands.

This thing is really cool. 3d Lattice exploration. Very much along the lines of my plans for search/nav interface for libferris.

http://www.iro.umontreal.ca/~galicia/demo.html

52 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!