the 3.1.7 release candidate now passes all tests on Mac and Linux, for me at least.
The tests are not all passing for me on Windows, but I believe that this is not a problem with ASDF as such. Instead, it seems that when I run the make file from inside cygwin, the running lisp gets cygwin-style pathnames (e.g., /cygdrive/f/asdf/) instead of native-ish pathnames (f:/asdf/).
I will have to modify the running environment to set an environment variable to indicate CYGWIN, and then decode the pathnames appropriately.
Unfortunately, it seems that if we run cygwin and then use UIOP run-program inside it, we get cmd.exe, rather than cygwin bash, which makes it tricky for me to run cygpath to translate the pathnames.
UIOP does not seem able to detect cygwin -- it has code that looks like uiop:os-unix-p should return t when cygwin is running, but that code seems not to work. It looks for a :CYGWIN feature which is not present, at least not under SBCL. I can see that uname -o returns "Cygwin", but can't run that from inside SBCL -- catch 22.
Right now, I'm stumped by this. Going back to Real Work (tm) for the rest of the day.
On 11:46 Mon 29 Feb , Robert Goldman wrote:
the 3.1.7 release candidate now passes all tests on Mac and Linux, for me at least.
UIOP does not seem able to detect cygwin -- it has code that looks like uiop:os-unix-p should return t when cygwin is running, but that code seems not to work. It looks for a :CYGWIN feature which is not present, at least not under SBCL. I can see that uname -o returns "Cygwin", but can't run that from inside SBCL -- catch 22.
I believe that code only detects if the lisp host was linked with cygwin, which makes sense because then the lisp host will think that it is running on a posix system. If the lisp host is linked as a native windows executable, then using windows style pathnames is correct
On Mon, Feb 29, 2016 at 8:32 PM, Jason Miller jason@milr.com wrote:
On 11:46 Mon 29 Feb , Robert Goldman wrote:
the 3.1.7 release candidate now passes all tests on Mac and Linux, for me at least.
UIOP does not seem able to detect cygwin -- it has code that looks like uiop:os-unix-p should return t when cygwin is running, but that code seems not to work. It looks for a :CYGWIN feature which is not present, at least not under SBCL. I can see that uname -o returns "Cygwin", but can't run that from inside SBCL -- catch 22.
I believe that code only detects if the lisp host was linked with cygwin, which makes sense because then the lisp host will think that it is running on a posix system. If the lisp host is linked as a native windows executable, then using windows style pathnames is correct
Note that the lisp script for driving tests also runs with Windows pathname style (on whatever style is native to the lisp implementation that was used to compile asdf-tools, by default ccl, sbcl or allegro all of which use Windows pathname style).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If it's not worth doing, it's not worth doing well — Donald Hebb
On 2/29/16 Feb 29 -1:44 PM, Faré wrote:
On Mon, Feb 29, 2016 at 8:32 PM, Jason Miller jason@milr.com wrote:
On 11:46 Mon 29 Feb , Robert Goldman wrote:
the 3.1.7 release candidate now passes all tests on Mac and Linux, for me at least.
UIOP does not seem able to detect cygwin -- it has code that looks like uiop:os-unix-p should return t when cygwin is running, but that code seems not to work. It looks for a :CYGWIN feature which is not present, at least not under SBCL. I can see that uname -o returns "Cygwin", but can't run that from inside SBCL -- catch 22.
I believe that code only detects if the lisp host was linked with cygwin, which makes sense because then the lisp host will think that it is running on a posix system. If the lisp host is linked as a native windows executable, then using windows style pathnames is correct
Note that the lisp script for driving tests also runs with Windows pathname style (on whatever style is native to the lisp implementation that was used to compile asdf-tools, by default ccl, sbcl or allegro all of which use Windows pathname style).
Right, but I'm not using the lisp script any more. The last time I tried, it blew up being unable to build the lisp scripting executable. I believe that you added code that was intended to build the scripting engine as a standalone executable, rather than simply loading and running, but I'm not really sure.
I'm sure that this bug is fixable, but it's the straw that broke this camel's back.
cheers, r
On 2/29/16 Feb 29 -1:32 PM, Jason Miller wrote:
On 11:46 Mon 29 Feb , Robert Goldman wrote:
the 3.1.7 release candidate now passes all tests on Mac and Linux, for me at least.
UIOP does not seem able to detect cygwin -- it has code that looks like uiop:os-unix-p should return t when cygwin is running, but that code seems not to work. It looks for a :CYGWIN feature which is not present, at least not under SBCL. I can see that uname -o returns "Cygwin", but can't run that from inside SBCL -- catch 22.
I believe that code only detects if the lisp host was linked with cygwin, which makes sense because then the lisp host will think that it is running on a posix system. If the lisp host is linked as a native windows executable, then using windows style pathnames is correct
I agree that it's *correct* -- it's just that windows-style pathnames is not what you get if you invoke the lisp from a bash script in Cygwin. The bash script uses standard facilities to find itself, so it grabs up cygwin pathnames.
To detect cygwin, I probably simply must set a CYGWIN environment variable from the bash script (where it's easy to detect) and use that to figure out when CYGWIN pathnames might be around.
Then I need to figure out exactly how the cygwin pathnames are creeping into the lisp, and either nip them in the bud or translate them. Unfortunately, I don't know how to do the translation. To do it, I must invoke CYGPATH from inside a lisp running on Windows, and there I'm lost.
-
Faré -
Jason Miller -
Robert Goldman