GPSL and the weekly seminars

Few years ago in my University, a small group of students started getting organized and created the GPSL, Grupo Pró Software Livre, which translates to Free Software Supporting Group. They did lots of nice things, like helping some (non-computer related) departments use Free Software. But since the time the group got in a cycle: first people have lots of plans and ideas, make some of them happen, after that a good deal of inactivity. Being a member since almost the beginning, I was sad to see that every time we needed to build interest all over again. Since last year a few students and I have been working hard to make the group escape that vicious cycle. First we tried a (unsuccessful) big thing, creating our GPSL version of Summer of Code, no prizes included. It didn't work. So we came up with the idea of having Weekly Seminars about Free Software, programming and such topics. Since the beginning of the semester we had six talks, a five-part series about the internals of Linux kernel, given by glommer++ and one double-talk about Pugs and Perl 6, using audreyt++ slides (hopefully one or two more commitbits will be delivered because of this talk... :-). It seems to me that this is working, we have about five new talks schedule for the next weeks and the feedback until now is very positive. Next talk is about anonimity networks, and a specific implementation called Kurupira.

Intermission

After SoC ended I left this blog on complete void. Now I'll probably change that next weeks. Because I needed an address to test OpenID and don't want my latest entry to be 2006 ;-)... Ok, truth is, I wanted to write more, not just random blog entries but also write more code, and talk about them here. Let's see if it will work this time.

Sold Arrays, Delivered Maps

The first idea was use Judy to backend implementation of arrays in Haskell. But, as became clear after a little thought and discussion (and specially pointed by Bulat++ in haskell-cafe), Judy library focus on good performance in dynamic arrays, but this wouldn't beat an memory region and data stored one next to another. The natural way to go was implementing a Map-like type. For this purpose was created a MapM type class to serve as interface for all possible Maps created (also tip by Bulat++)

Judy.IntMap is based on JudyL and allows as key-type any type that could be transformed into a word size representation. Judy.StrMap allows as key-type anything that could be stringable into a CString ending with a \0 character. Both Maps have a ordered traversal into its contents. Then Judy.Hash is based on JudyHS which allows as keys strings containing the \0 character in its strings (it stores the length of string instead of having an end identifier), but doesn't have ordered traversal.

To allow any Haskell type to be used as value for these Maps, was created an interface on top of StablePtrs that would create and deallocate them as needed. This can be modified for specific cases, e.g. Int types doesn't use StablePtrs since they fit in the Word reserved for values in Judy C library.

Saying that, all the tests I proposed in my application do benefit from Maps: Pugs project (as I already described), RBR (which was bounded by its use of Data.Map) and K-Nucleotide naive adaptation (in tests/k-judy.hs).