Lisp libraries
in [Lisp]
|
From: Nicolas Neuss on 18 Feb 2010 10:05 Hello, I use a combination of Hunchentoot, CLSQL and other Lisp software on several computers running Ubuntu and Debian. I also use several implementations: mostly SBCL, but from time to time also others (CCL, CMUCL, Lispworks,...) I recently have updated my to Hunchentoot 1.0 for two of my computers (two other computers that are running my web applications still work with Hunchentoot 0.15). However, I have run into several problems because I have now a strange mixture of libraries: 1. Some packages from Debian/Ubuntu 2. Some installed by asdf-install in .sbcl 3. Some installed by asdf-install in .asdf-install-dir 4. Some installed using asdf from a ~/CL-HOME directory I am now thinking about making a large restart by relying mostly on one of those methods, something like A. Try to use the bleeding edge of Debian and hope that libraries and CL implementations are sufficiently up-to-date Problems: integrating commercial Lisp implementations, relying on the Debian maintainer B. Download everything with asdf-install in .asdf-install-dir (for having it available with several CLs Problems: How to keep it up-to-date? C. Download everything needed in ~/CL-HOME without asdf-install (and -if possible- with CVS/SVN). Problems: more work, keeping it up-to-date and working with each other? D. ? I would be interested in how people reading this newsgroup and having similar needs have solved this problem. Thank you very much, Nicolas
From: Thomas M. Hermann on 18 Feb 2010 11:41 On Feb 18, 9:05 am, Nicolas Neuss <firstname.lastn...(a)kit.edu> wrote: > Hello, > > I use a combination of Hunchentoot, CLSQL and other Lisp software on > several computers running Ubuntu and Debian. I also use several > implementations: mostly SBCL, but from time to time also others (CCL, > CMUCL, Lispworks,...) > > I recently have updated my to Hunchentoot 1.0 for two of my computers > (two other computers that are running my web applications still work > with Hunchentoot 0.15). However, I have run into several problems > because I have now a strange mixture of libraries: > > 1. Some packages from Debian/Ubuntu > 2. Some installed by asdf-install in .sbcl > 3. Some installed by asdf-install in .asdf-install-dir > 4. Some installed using asdf from a ~/CL-HOME directory > > I am now thinking about making a large restart by relying mostly on one > of those methods, something like > > A. Try to use the bleeding edge of Debian and hope that libraries and CL > implementations are sufficiently up-to-date > > Problems: integrating commercial Lisp implementations, relying on the > Debian maintainer > > B. Download everything with asdf-install in .asdf-install-dir (for > having it available with several CLs > > Problems: How to keep it up-to-date? > > C. Download everything needed in ~/CL-HOME without asdf-install (and > -if possible- with CVS/SVN). > > Problems: more work, keeping it up-to-date and working with each > other? > > D. ? > > I would be interested in how people reading this newsgroup and having > similar needs have solved this problem. > > Thank you very much, > Nicolas I use method C exclusively, this could be an artifact of my background with FreeBSD ports. I haven't found keeping the repositories up-to- date to be a problem because I generally don't update them unless there is an explicit reason to. When you do update a repository, compatibility problems may arise, but I've not experienced that in general, except for slime. The only alternative that I would recommend is CLBUILD -> http://common-lisp.net/project/clbuild/ I've not tried it, but it has potential. Good luck, ~ Tom
From: Captain Obvious on 18 Feb 2010 15:07 NN> I would be interested in how people reading this newsgroup and having NN> similar needs have solved this problem. Something like your C. There is a script update-systems.sh which finds all asd files and links them into a certain directory which is mentioned in asdf:*central-registry*. So installation process is very quick -- wget, unpack, run update-systems.sh, and that's all. If you want to temporarily try some different version, push its dir into asdf:*central-registry* NN> Problems: more work, keeping it up-to-date and working with each other? I'm afraid it is inevitable problem, no matter what you use, it won't be 100% tested and won't necesarily have features you want. I think it is better to do it manually instead of relying on somebody other to do it. On a positive side, you can just copy this directory to other location, synchronize it with rsync or whatever.
From: Nicolas Neuss on 18 Feb 2010 16:11 "Thomas M. Hermann" <tmh.public(a)gmail.com> writes: > I use method C exclusively, this could be an artifact of my background > with FreeBSD ports. I haven't found keeping the repositories up-to- > date to be a problem because I generally don't update them unless > there is an explicit reason to. When you do update a repository, > compatibility problems may arise, but I've not experienced that in > general, except for slime. Yes, I have a feeling that in the end I'll be doing this. > The only alternative that I would recommend is CLBUILD -> > http://common-lisp.net/project/clbuild/ > I've not tried it, but it has potential. Indeed, it looks interesting. I think I'll give it a try as well. Could someone having experience with clbuild maybe comment on: - How well does it work with other CL implementations than SBCL? - How current are the libraries and how are they kept current? Thank you, Nicolas
From: Nicolas Neuss on 18 Feb 2010 17:04 Nicolas Neuss <firstname.lastname(a)kit.edu> writes: > "Thomas M. Hermann" <tmh.public(a)gmail.com> writes: > >> I use method C exclusively, this could be an artifact of my background >> with FreeBSD ports. I haven't found keeping the repositories up-to- >> date to be a problem because I generally don't update them unless >> there is an explicit reason to. When you do update a repository, >> compatibility problems may arise, but I've not experienced that in >> general, except for slime. > > Yes, I have a feeling that in the end I'll be doing this. > >> The only alternative that I would recommend is CLBUILD -> >> http://common-lisp.net/project/clbuild/ >> I've not tried it, but it has potential. > > Indeed, it looks interesting. I think I'll give it a try as well. > Could someone having experience with clbuild maybe comment on: Having tried it a little bit I can give some first expressions (partially answering my own questions below): To be clear: IMO, clbuild is really a very good project and largely what I has hoped for. But there remain things to be done: > - How well does it work with other CL implementations than SBCL? clbuild --long-help answers: ... "Please note that only sbcl is fully supported at this time!" (However, what this means precisely would be interesting.) > - How current are the libraries and how are they kept current? First, I installed hunchentoot. There the trivial-backtrace dependency was not in the projects but in the wnpp-projects which could be easily handled, but shows that dependency tests are not complete. Next, I installed clsql which gave later an error when requiring clsql-postgresql. So, dependency and probably other tests are lacking. Nicolas
|
Next
|
Last
Pages: 1 2 Prev: RosettaCode Next: can a make-instance method return a different class? |