Re: [asdf-devel] [armedbear-devel] Patches for ABCL against asdf-1.641

2010-03-28 Thread Faré
Dear Mark, > Fare's suggestion that I use an output translation based on the jar > pathname doesn't quite work, because in our current implementation, > the pathname of the jar is stored in DEVICE, separate from the rest > of the jar pathname. I extended PATHNAME-MATCH-P to match jars > correctly,

Re: [asdf-devel] Error loading closure-html

2010-03-28 Thread Faré
There is no portable way to distinguish between the many filesystem errors, anyway. Is there a good reason to not let LOAD report whatever error it wants? Otherwise, we could use this function: (defun file-readable-p (path) (with-open-file (s path :direction :input :if-do

Re: [asdf-devel] Error loading closure-html

2010-03-28 Thread Samium Gromoff
On Sat, 27 Mar 2010 12:44:08 -0400, Faré wrote: > Samium, > > you're the one who seemingly introduced this with-open-file in > 2ca05589. Why do we need such a fancy and not-that-portable way of > testing the file is there? PROBE-FILE fails to catch dead symlinks, and I need a meaningful conditio

Re: [asdf-devel] [armedbear-devel] Patches for ABCL against asdf-1.641

2010-03-28 Thread Erik Huelsmann
Hi Alan, On Wed, Mar 24, 2010 at 3:36 PM, Alan Ruttenberg wrote: > Is ASDF2 what gets loaded when you require 'asdf in trunk, or some > other action required to use it? > -Alan I think we will need to update our ASDF now that the new ASDF2 is available. What you get when you use REQUIRE is a ver

Re: [asdf-devel] ABCL testing issue

2010-03-28 Thread Mark Evenson
On 3/17/10 4:15 PM, james anderson wrote: […] >> >> The specific bug you are encountering involves abcl-0.18.1 not being >> able to handle the renaming of a FASL, as ASDF2 compiles to >> "asdf-tmp.XXX" and then renames to "asdf-.XXX". >> Rather embaressing for us, really, so [we fixed it fast][1] >