News, progress, and other positive things…

Posted on January 28, 2015 by Alex Sassmannshausen

Wow how time flies, right? So, lot’s has changed since my last update. A lot of these changes, in turn, operate deep inside Glean’s belly, and so should not be immediately apparent for now. I am fairly certain I will cover a few of these changes at a later date. For now: drum-rolls please for the low-down on the latest stuff.

Glean is dead, long live GNU Glean!

Glean was accepted as a GNU software project! So it’s official name has changed to GNU Glean, and the next release will officially happen under the GNU banner. I’ve made a start on migrating to the GNU infrastructure. This once again should be completed when I release 0.2 (still optimistically scheduled for February-ish).


So a notion I’ve been toying with for a while: when a content creator needs to refer to other disciplines, or sub-sets in their discipline, they should be able to do so conveniently and quickly. The method of accessing these different Glean sets should work before installing the sets in the store, afterwards and any time. This issue can be quite complicated (since 0.1 I’ve been deeply pondering notions of identity and equality of things). Suffice to say I think I’m approaching an elegant solution: the humble LEXP (short for Library-Expression).

LEXPs are a fusion of xpath and Guile’s module system: they take the form of:

   (git init)

where each word in the list is the next step in the set hierarchy. In the example above we would be referring to the “init” set that is part of the “git” discipline.

The nice thing here is that the content creator should be able to refer to other parts of the discipline (and in future, parts of other disciplines entirely), without needing to worry about versioning, hashes etc.


Glean has thus far been using some haphazardly chosen hashes to track discipline identity. The primary concern is to find a way to maintain up-to-date representations of disciplines stored in a library, in the lounge (so that the lounge can calculate which challenge should be set next). Of course this also implies the need for a mechanism by which these lounge representations could be seamlessly updated as and when new version of disciplines are installed in the library.

I’ve also been wanting to implement a “read-only” store, library-side, which I believe, should make creating and testing content, and administering a library a lot easier (nay, dare I say it, fun!). In order for this to work nicely, a discipline should be installed in the store under a unique name for each revision (even if the version number was not bumped!). You’ll find more detail on this below, but the long and short of this is that we needed a different kind, namely more strict, hash than for the first use-case.

We now use 3 new types of hash, with clearly defined use-cases instead of the old set of 2 hashes. You can check out the code in the (glean library hash) module.

For now, Glean is in a transitional stage: it still uses the old hashes as well as the new ones. We will have fully migrated by 0.2 release.

Read-only store!

All the rage amongst package managers (see for instance the awesome Guix), and probably people of the lambda persuasion in general, Glean was not to miss out.

Disciplines can now be installed and removed from the library using the friendly new ‘glean librarian’ commands. This might also give you a hint of the underlying layers used in implementing the read only store. In essence it goes like this:

“glean librarian” allows you to query the catalogues (–-show option), install new disciplines (–-install, this creates new catalogues) & remove disciplines (–-remove, this actually only creates a new catalogue without the discipline to be removed — it will still be in the store).

There are some rough edges (it’s not possible to delete content from the store yet, or to switch back and forth between different catalogues), but I think the basis is there.


Glean also continues to be a study project in itself, and Monads continue to be an object of study. I’ve continued experimenting with them, but I still think they’re not being used quite right.

I still believe I want to use them for:

Definitely still WIP.

What’s next?

Well, the big thing is to convert to the new hash system (both library and lounge side), to implement some new upgrade related requests for the lounge, and to test. A lot.

My, perhaps naive, hope is that this major revision in the underlying architecture should allow us dramatically expand and change the content-creation DSL, and thus disciplines, and the way they are interpreted by the library, lounge and client, without having to break the API over and over again.

Ideally we also might be able to avoid breaking backward compatibility — though it has to be said that this is not yet a priority: Glean is alpha software, and the infrastructure will keep changing until at least version 0.5.

After this I intend to provide Glean.el emacs interface with feature parity to the current REPL client, which should bring us to 0.2.

Happy Hacking!

Creative Commons Licence
This work by Alex Sassmannshausen is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License .