CLC v7

Feb. 1st, 2010 09:24 pm
pvaneynd: (Default)
With a lot of help from Faré and James Y Knight we have now the incredible disappearing common-lisp-controller v7. We went from 617 to 267 lines which in fact are only 193 lines excluding comments and empty lines...

Using the new features of cl-asdf version 1.500 and higher the implementation of CLC is now merely setting a few variables and putting a few files into place. As an added bonus I added clbuild integration, so now people can download and update libraries with ease.

Still todo:
  • there is an bug (#567912) that the first call to (clc:clc-require :<foo>) will fail with clisp due to a loop where there is no looping...
  • We still need to find a way to precompile libraries
  • Because asdf is now taking care of placing the fasl file in the correct place, we cannot remove fasls for a specific implementation or library, so we nuke them all. Not optimal.

Still a nice improvement, I hope to find some time at fosdem to work on the other issues...
pvaneynd: (Default)
Following the announcement of the source+throw away binaries route for uploading packages I've had a brief discussion with our FTP team.

The implications of the new method would be that if you upload a package it will automatically be recompiled from source by using the packages already in the system.

For cmucl which needs cmucl to recompile itself it means that we can only use the previous version of cmucl in the archive, not the one we are just uploading. This won't work as the compiling cmucl needs to be hand-patched to be more 'like' the new version, otherwise you cannot rebuild it.

The conclusion of this discussion is that systems like cmucl are no longer possible under this new system.

The FTP team suggested to change cmucl to be able to do this. Needless to say we already have this, after several years of hard effort by multiple people, it's just called sbcl.

So in the end the 'everybody uses C' camp won and cmucl on Debian will die a quiet death. It's a sad end for a system hand-patched from PDP10's to modern CPU's over the coarse of almost 30 years...
pvaneynd: (Default)
This weekend I finally did what I've been planning to do for some time and wrote a iPhoto exporter. See the alioth project oipe or "Offline iPhoto Exporter".

At home I backup my iMac to the debian server, but the iPhoto folder was just a mess and [ profile] zoutke complained she could never find anything.

This is because the iPhoto folder itself is just a dump of your 'rolls' when you imported the picture. When you cleanup and classify nothing happens to the real data (which is good). So I needed something to take an iPhoto folder and turn it into something that other people can use...

The exporter is written for sbcl for now and use cl-sqlite to extract the folder structure of iPhoto and the pictures in those folders to generate both a link-farm with hard links to those images and a (really bad) set of webpages showing the thumbnails and linking to those pictures.

The advantages are that it is really fast (less then a minute for > 7000 pictures) and doesn't take up much more space.

Future plans include nicer web-pages, also having a 'Faces' and 'Location' hierarchy and adding the tags back to the pictures.
pvaneynd: (Default)
Actually clbuild seems to do the right thing almost all the time.

I've been trying it as a workaround to suggest to users after I remove most of the Common Lisp libraries from Debian. Honestly it is pretty good: you download it, you ask it to install libraries an it will download them from their git/cvs/darcs/whatever repositories. You can ask it to upgrade the libraries or to compile and start slime with the libraries 'known' to asdf.

All in all quite good, even if there is a conflict between the slime in clbuild and the slime from the Debian package.

I think I can suggest this to Debian users without reservations...

Now: why didn't I see more of this on planet.lisp ?
pvaneynd: (Default)
After some consideration I must conclude that the state of the Common Lisp packages in Debian is becoming unreasonable. One of the goals of forming the pkg-common-lisp team was that I would not be a bottleneck, as RL is inflicting more and more damage to my 'Debian playtime'.

Now that Luca left I'm basically the only 'active' (for very small values of active) DD/DM left. (no hard feeling towards anybody, just loads of thanks for the work they did)

I see two alternatives:

  • other people get involved, investigating bugs and sending git/darcs/whatever format patches.

  • we go low impact and remove common-lisp-controller and all Common Lisp libraries, and I/we only package the lisp implementations (clisp, ecl, sbcl, cmucl and perhaps ccl) without any special changes

I don't expect the first alternative to be realistic, so unless proven wrong I'll RFA/RM all the libraries/clc on the 5th of September.
pvaneynd: (Default)
In the last few weeks I needed to write a short utility at $WORK. I decided to use my trusted Common Lisp. Turned out that my old utility still would be ok, but 'upstream' had changed from CSV files to 'json' files.

A short google query, downloading the two libraries that exists to parse these files and within a few minutes I could read and parse the new fileformat.

Don't tell me CL doesn't have libraries...

ObDebian: yes I still need to update cl-irc and package said jason library... it's somewhere in my long todo list.


pvaneynd: (Default)

March 2017

12131415 161718
26272829 3031 


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 21st, 2017 01:08 am
Powered by Dreamwidth Studios