If you read this, you may be interested in the related feed
It seems there are still people out there that are coming to my site (or even my mailbox :)) due to my Dokuwiki plugin for BibTeX entries. While I'm always happy to help, I recognise the current situation (with the code living as a zipfile here) is not very practical. Moreover, since I'm no longer in Academia, my involvement with this plugin is totally minimal. Actually I just verify it still works each time I upgrade my Dokuwiki install, which I just did.
So… I just put the code, mostly as-is, in a new GitHub project. This way, if somebody is interested in taking over, or simply in providing patches, they're welcome to do so !
No doubt there's much to rework/cleanup there…
In this post, I'd like to discuss some of my thoughts about the current state of Emacs packages development, and in particular those related to proper building/testing.
Historically, Emacs packages have had a self-centered, optimistic view of the world : not only did many packages reinvent the same wheel again and again to avoid depending on other non-official packages (just because there was no good user story for installing them), but most of them didn't have formal tests, let alone automated ones.
I think that's vowed to change somewhat, with the recent introduction of the package management facility (package.el in Emacs 24) and the associated infrastructure (GNU Elpa, Marmalade, Melpa). This opens the door to actually useful libraries outside of Emacs core. Not that everything is perfect there (in particular, the complete lack of proper namespaces is a still big obstacle), but we're slowly going there.
Anyway, with packages being (hopefully) less and less self-contained comes a big concern about reliability/reproducibility, the central question being “how do I make sure my package works”. This is partially adressed by the (also quite recent) introduction of an official test framework in Emacs core. But now, it's pretty clear that we need some better way of running tests under various conditions.
To take an example, as a maintainer of Magit, I'd like to make sure that the code runs as expected with:
Ideally, all combinations should be tested, but I'd be quite happy already to have a good subset. Now of course, having systems covering all this is just not realistic for me. I can afford running a couple of VMs from time to time, covering some of the possibilities, but maintaining the whole thing is much more work that I'm willing to do (not even considering the price).
Also, quite frankly, the activity of the vast majority of Emacs packages development doesn't justify such a continuous integration infrastructure. It's nice to have tests run automatically when code changes, but having test slaves sitting there the whole day waiting for a commit is not.
We have 2 separate problems with (in my opinion) a common solution:
This calls for mutualization.
It's pretty clear there is an Emacs community (arguably several of them :)), with people caring about the overall quality of the packages they're using. Structures like Marmalade, or even the EmacsWiki would not have taken off otherwise.
It's also very clear that some members wouldn't mind donating some CPU cycles to run tests, as long as they don't have to think about it too much (hey, we're lazy persons, right? :)). The only thing that's not clear is how many would volunteer, and the level of involvement they'd accept. That's what I'd like to discover :)
Now the good thing is that in this community, the main requirements are fulfilled in each and every machine: have an OS, have Emacs installed (and generally several versions of it). So basically, my point is that we have a large pool of potential build/test slaves waiting to be used. Again, this is Emacs… most of the packages are built and tested in a matter of seconds, with very few resources consumed in the process.
As an example, my main computer, running Ubuntu Oneiric 64 bits is running on average 10-12 hours a day. I also have a OSX Lion virtual machine that's running about 6 hours a day. Both have development versions of Emacs 24 installed, and the Ubuntu one also has Emacs 23.3.1. I can definitely run 50 build jobs per day (and probably much more) on each machine without even noticing. Actually I'm using them right now as test slaves in my current implementation, and can't tell when jobs are triggered. It'd would also be very easy for me to setup some LXC containers to serve multiple OS versions, or maybe even to leverage virtualenv to compose environments with the proper application versions. One can go quite far with few resources.
So… my idea is to put in relation those projects needing resources, and those resources waiting to be used. To accomplish that, we need several things:
Note that in that scenario, it's very important to not require build slaves to be available all the time. That would raise a lot the entry barrier, and is not compatible with a communitary approach. Instead, I'd prefer to rely on many slaves being sporadically available to cover the “continuous” aspects of continuous integration.
I have implemented something just like this on top of Buildbot (for no particular reason, except that it sounded fun). Before I go into details, you might want to have a quick look there to see how it looks for Magit: http://dev.hodique.info/buildbot/waterfall?category=magit
My current implementation relies on:
The idea here is that contrary to regular buildbot instances, the jobs to run and the slaves on which to run them are administered completely separately:
For now, each time something is modified on either side, buildbot tries to reconfigure itself, by recomputing which combinations can be accomodated for each project, and the list of available slaves for each combination.
Here is a very simple project definition, for one of my pet projects:
https://github.com/sigma/emacs-ci/blob/master/emacs/projects/mocker.py . The
_project_combinations member defines what features a slave should expose to be
of interest. If ever we decide that testing with Emacs 23 would be a good idea,
we can just add a new element there, and appropriate slaves will be picked
automatically, if they exist at all.
At the other end of the spectrum, a slave definition looks like this:
$ cat slave.yaml password: sdoifio1pofsd features: os: osx-lion arch: x64 emacs: GNU Emacs 188.8.131.52 binaries: emacs: /usr/local/Cellar/emacs/HEAD/Emacs.app/Contents/MacOS/Emacs
This is a simple YAML file that exposes a set of features, and optionally where to find them (the emacs binary part). This way, the build steps can be written in such a way that they adapt to the exact slave they're running on. Of course, the buildbot slave itself still has to be created, but it's a one-time job :)
Note that even the password to connect to the master is under the slave admin's responsibility (and the slave name is just the repository name). This potentially allows slaves to be created without any intervention from the master admin. For example, were we to enable some gitolite wildcard repositories, we could have some people create slaves entirely by themselves.
Wow… that was a long post. Thanks for reading this far :)
Again, this is a pretty prospective topic. I'm not saying any of this is the only true way of dealing with the issue, I'm just saying that this issue needs to be adressed somehow.
I'd love to hear from people who might be interested in taking part in the discussion, so feel free to contact me if you have any idea of how you would like to see things evolve. In addition to mail, I'm generally available on IRC (channel #emacs, nickname Sigma)
I generally like the Monaco font, that I use for both Emacs and my rxvt-unicode terminals in GNU/Linux. In order to achieve this, I had the following in my
emacs*font: Monaco:pixelsize=13 urxvt*font: xft:Monaco:pixelsize=13
Although it works perfectly fine for “normal text”, it does a disastrous job for fancier characters such as greek symbols. I don't know much about fonts lookup, but I guess there's a fallback mechanism to elect another font when the selected one does not contain the required symbols.
Anyway, as you can see in the following capture of my rxvt-unicode setup, it's not exactly pretty (bottom left for the display before fixing). It gets mucc better after modifying my
~/.Xdefaults to contain:
Similarly for Emacs, the default display was not great (although at least readable). Putting something like the following in my
~/.emacs solved the issue for me.
(set-fontset-font "fontset-default" 'greek '("dejavu sans mono". "unicode-bmp"))
And now my Lisp lambdas can finally look good :)
As I'm currently trying to introduce some unit tests for Magit (see the unit-test branch) I realize I really need some mocking capabilities. For some reason, even though we now have a testing framework released with Emacs (ERT), no mocking library found its way to the core (yet?).
In its manual, ERT refers to the 3rd party el-mock.el, but I don't like the DSL approach too much (feels un-lispy to me) and it has definitions I strongly disagree with (“Mocks are temporary functions which accept specified arguments and return constant value.”) that make my life harder as a test writer. In my opinion, mocks are supposed to work in a record/replay way, which implies to be able to record different outputs for different (or even same) inputs. Returning a constant value is more of a stub thing. Actually I don't care too much about the naming, but I need the feature anyway :p
So, even though it is really nice for basic mocking (and achieves very low verbosity), el-mock.el is just not flexible enough for my purpose.
Here comes mocker.el, my attempt at achieving greater mocking flexibility. Admittedly, this is much more verbose, but for some twisted reason I like it better this way :) Note that the architecture is meant to be flexible, so in theory it would even be possible to define a way to express mocking expressions in a DSL similar to el-mock.el's.
2 quick examples taken from the documentation:
(mocker-let ((foo (x y z) ((:input '(1 2 3) :output 4) (:input '(4 5 6) :output 10))) (bar (x) ((:input '(42) :output 4)))) (+ (foo 1 2 3) (foo 4 5 6) (bar 42))) ;;; make `foo' generate the fibonacci suite, no matter how it's called (mocker-let ((foo (x) ((:input-matcher (lambda (x) t) :output-generator (lexical-let ((x 0) (y 1)) (lambda (any) (let ((z (+ x y))) (setq x y y z)))) :max-occur nil)))) (* (foo 1) (foo 0) (foo 42)))
For more details, please refer to the page of the project. Bottom line,
mocker-let is just a macro around
flet that specializes in recording expected behaviors, then consuming them.
For what matters, I'd like it a lot if a proper mocking solution (whatever it may be) made its way to Emacs (as part of ERT or not). Maybe if there are enough people interested in this we can come up with something together :)