Andy Wingo <wi...@pobox.com> writes: > Hi, > > I wanted to bootstrap the guildhall stuff, so last week I started poking > at Andreas' excellent dorodango (http://www.nongnu.org/dorodango/). I > forked his repo on gitorious, removed a bunch of compat stuff for other > implementations, imported dependencies into the archive, replaced the > http stuff with Guile's (web) foo, and wired up a standard build system. > > The result is here: > > https://gitorious.org/~wingo/dorodango/guildhall > > You can: > > git clone git://gitorious.org/~wingo/dorodango/guildhall.git > > Then ./configure && make && make check. > > You will only be able to succeed there if you have (web client), which I > have pushed to Guile's stable-2.0 branch. > > Wherever you see "doro" in the docs, replace it with "guild hall". > Perhaps in the future we should drop the "hall", so "guild hall update" > -> "guild update" or something. Anyway, a thought for another time. > > So, the status: > > 1) Builds. > 2) Passes make check. > 3) Can update the available list. > 4) Everything else is untested :-) > Cool!
> Next up: > > 1) Check status of dorodango functionality. > 2) Fix things that don't work. > 3) Profit? > 4) Start thinking about hosting and accounts and UX and stuff. > > I will see if I can get work to sponsor a server that we can use, and > see if we can get it aliased to guildhall.gnu.org -- unless someone else > would like to provide the server. It would be nice to have root on that > server, FWIW. It could be a VM. > > As far as relation with dorodango goes, we should do our best to keep > the guildhall compatible with dorodango archives on the net. We should > also try hard to share code, but that is secondary. Farther along I > would like to rename (dorodango ...) in our source to (guildhall ...) or > something so that we don't conflict with upstream. I would also like to > reduce the number of bundled dependencies, and for the ones that are > left, include them under the (guildhall ...) namespace, making them > effectively private. > +1; dorodango's dependencies are quite stable, so duplicating them in the guidhall version should not be much of an issue. As for reducing their number, I've posted a mail with some ideas about how this could be started off a while ago [0]. The thing that would be provide the most benefit IMHO would be an interface to libzip, using Guile's dynamic FFI; that would allow guildhall to get rid of industria as a dependency, and speed up package installation quite a bit. Also, this code could eventually be folded back into dorodango, once spells' FFI is working on Guile. I'm in principle interested in working on a libzip interface, but I'd rather get spells' FFI finished on Guile first. > That way you can also install dorodango on your > machine, if you wish, and also install the wak- packages, industria, > ocelotl, etc. > > I would really love for someone to take up this project. I can help > getting it to the minimally functional state. Please let me know if you > are interested. > Yeah, it would be cool if someone took care of this. I can help with any dorodango-related issues. Regards, Rotty -- Andreas Rottmann -- <http://rotty.yi.org/>