2010/6/2 Alessio Stalla alessiostalla@gmail.com:
2010/6/2 Alessio Stalla alessiostalla@gmail.com:
2010/6/2 Mark Evenson evenson@panix.com:
On 6/1/10 9:50 PM, Knut Olav Bøhmer wrote:
Is there any workaround for this?
You got a patch for my wrist? ;}
But seriously, I think disabling the JAR output translation by removing the reference(s) in ASDF:*OUTPUT-TRASLATIONS* with something like
(setf asdf:*output-translations (list (remove #P"/___jar___file___root___/**/*.*" (first *output-translations*) :key #'car :test #'equal))
would work.
Alessio: snow-0.3 fails to compile with 'sys:variable-information' not being found in 'snow.lisp', so I can't reproduce your error. Maybe you need a new release from Snow trunk?
You're right: Snow 0.3 was still supposed to build with a patched abcl, while trunk is not. However, I found out that the asdf problem is only in the binary release of ABCL downloaded from the site, while if I compile 0.20 myself it works, so r12666 is not the culprit. Since you cited a Windows pathname, and I think Erik built those binaries on Windows, is it possible that ASDF builds differently depending on the OS, so that the resulting binary only works on that OS?
Answering to myself, it appears indeed that the 0.20 binary contains a reference to Windows pathnames:
CL-USER(1): *features* (:JAVA-1.6 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :UNIX :LINUX :CDR6)
CL-USER(2): (require :asdf) ("CLOS" "PRINT-OBJECT" "FORMAT" "ASDF")
CL-USER(3): (asdf::wrapping-output-translations) (:OUTPUT-TRANSLATIONS :INHERIT-CONFIGURATION (#P"\___jar___file___root___\**\*.*" (:USER-CACHE #P"**\*.*")) (#P"jar:file:\**\*.jar!/**/*.*" (:FUNCTION ASDF::TRANSLATE-JAR-PATHNAME)) :ENABLE-USER-CACHE)
This is presumably because pathnames are serialized to FASLs using their namestring, which is not necessarily the same string that was passed in with #P"...". Storing the user-provided string in the pathname and using that as a namestring if the pathname has not been destructively modified could solve this issue, if it's doable. Sigh, I'll have to reboot to Windows... ;)
I was able to fix the problem by moving the setting of the namestring during the initialization of a pathname close to the beginning of the init method, before / characters are replaced by \ on Windows. I verified that on Windows I can load files regularly and that the binary built on Windows works on Linux as well, but since pathnames are foreign territory for me, I haven't committed the fix yet in case someone points out some obvious mistake. Attached is a patch with my fix.
Bye, Alessio