This post is to announce the release of Mudballs, a collection of Common Lisp code for managing systems. It is currently in an early stage of development and still has a long way to go but is currently able to compile, load, document, download and install systems across Windows, Linux and Mac OSX. Mudballs supports the following implementations
- Lispworks on Mac OSX, Linux and Windows.
- SBCL on Mac OSX and Linux.
- CMUCL on Mac OSX and Linux.
- CLISP on Linux and Windows (Mac OSX as well provided you have FFI).
- ClozureCL/OpenMCL on Mac OSX, Linux and Windows.
- AllegroCL on Mac OSX, Linux and Windows.
As it currently stands it is not ASDF compatible (not ideal, I know) but ASDF support is planned for the future. It is available from http://mudballs.com which contains enough information to get the intrepid lisper on his or her way.
As a small taste, the following is now possible from a freshly installed Lisp with Mudballs loaded.
> (mb:install :hunchentoot)
> (hunchentoot:start-server :port 8080)
P.S. Prizes for anyone that can come up with a logo which doesn't look like a pile of excrement.
21 comments:
Wonderful! We really need a more modern take on package management.
This is excellent. I've been contemplating doing something like this ever since I saw the OCaml batteries included project, but didn't have the time to invest in kickstarting it. Glad to see you do :)
What's involved in supporting other implementations? I'd be very interested in supporting ECL.
Wow - very impressive. Best of luck for the future!
[Forgive me if you end up with multiple copies of the comment. The OpenID auth doesn't seem to be working properly.--me]
So in testing the hunchentoot example on ccl I rean into two problems: first, mudballs choked on trying to install gzip-stream. I nuked mudballs and started again from scratch, and it succeeded n gzip-stream, then choked on acl-compat, which it seems to know nothing about. The hunchentoot system definition :needs :acl-compat on lisps for which :openmcl is on *features*, but :acl-compat isn't in the starting set of packages and mb:search can't find it. Perhaps you intended it to be provided indirectly by hunchentoot or by some susbsystem that ends up installing portable aserve, but that doesn't seem to have happened.
I ran into a second issue when trying out the definition of my own (very simple) system. Using the example of the test system provided, I built a very simple system that consisted of two source files and no external dependencies. After I figured out how to get mudballs to update the system definitions from its config file without restarting the lisp (a process which took some time), I search for my test system So far, so good; it found my test system. mb:load appeared to load my system, but in fact loaded only the first file: the components were defined as
(:components "package" "util")
"package.lisp" was loaded; "util.lisp" was not.
Naturally, I tried evaluating the load form again. On the second load mudballs complained that the system was not installed and asked if I wanted to install it.
Cool idea, but some roadblocks in the way, at least on a build of today's ccl sources.
Hit a condition on SBCL-1.0.18 (Linux/x86-32): http://paste.lisp.org/display/71481
@Mhaggag: The code is pretty portable, adding a new implementation is primarily getting the call to cl:directory to behave and some MOP specifics (like custom method combinations)
@mikel_evans: Thanks for the report, acl-compat is not available yet (an oversight to be sure).
As for complaints that a system is not installed (when it actually is) check that the components are all present. This error message could definitely be improved.
@Mikael_Jansson: Yes, unfortunately I created a tarball on my Macbook which, for some reason, feels the need to include various '._' files. I've uploaded a tarball created on a linux box which no longer has these issues.
Documentation seems to say nothing about how to specify inter-component dependencies, or how they are treated.
@Nikodemus. No it doesn't, at least not yet. It is one of the more glaring omissions at the moment.
Love the idea, love the simple interface.
I note that the cl-fad mudball is at version 0.6.0 while weitz.de has it at 0.6.2. Presumably keeping mudballs regularly in sync with upstream is non trivial?
Rather than just point this out, I volunteer to help if I can since I am so pleased to see someone working on this. Let me know: mudballs at gtod dot net.
@gtod: Relatively simple. It is just a matter of adding the new system definition to the mudballs definition file and uploading a new tarball.
Really excellent.
Its simple.
The search option is really awesome.
Congrats!
I loved how much docs you had up to begin with but I did end up missing a few things too. May I suggest a (media)wiki?
I tried to sign up for the mailing list but that doesn't seem to have gone through. Do you have closed membership right now?
Logo ideas: In Japan there is an art of making shiny balls out of mud http://web-japan.org/trends01/article/011005sci_r.html That isn't really a logo in itself, but might provide someone an idea.
@Nathan: Thanks for the link to the mud balls, very interesting. Currently the list is not closed so I'm surprised that you had trouble joining it, I will take a look.
Sean Ross said:
Thanks for the report, acl-compat is not available yet (an oversight to be sure).
Especially since the getting-started example depends on it.
Sean Ross said:
As for complaints that a system is not installed (when it actually is) check that the components are all present. This error message could definitely be improved.
Well, the component that supposedly wasn't installed was the test system itself. If it's not "installed" then "installed" must have some definition in this context that is not obvious.
That's not the whole problem, though. Additionally, as I reported before, mudballs loaded the first of the two files in the defined system, but not the second (entities defined in the first file were present in the lisp image after the load, but entities defined in the second were not). There was no indication from mudballs that any failure to load occurred. Reloading simply caused it to display the complaint about the test sytem not being "installed" (whatever that might turn out to mean).
The concept is great. The software is not yet usable.
@Evins: Why don't you email me your system definition and we can get it working.
>@Evins: Why don't you email me your system
> definition and we can get it working.
I would, but a cursory look around doesn't urn up your email address. But it's nice and short:
(define-system :guild-util ()
(:author "mikel evins")
(:version 0 0 1)
(:licence "MIT Style license")
(:documentation "General Utilities")
(:components "package" "util"))
Great work! It worked pretty much out of the box.
I had been using clbuild but I'd prefer to have finer control over the versions I'm getting. Which is something I can't seem to easily do at the REPL with any package system I've found yet.
Post a Comment