[asdf-devel] One failure on ASDF 3.1.0.70 on Allegro/Windows
Sorry to be late to the party again with Windows testing... So far I'm seeing a consistent failure for every Allegro variant on Windows for test-sysdef-asdf. Here is the error: These two expressions fail comparison with equal: (asdf-test::system-lisp-files :uiop) evaluates to ("uiop\\package.lisp" "uiop\\common-lisp.lisp" "uiop\\utility.lisp" "uiop\\os.lisp" "uiop\\pathname.lisp" "uiop\\filesystem.lisp" "uiop\\stream.lisp" "uiop\\image.lisp" "uiop\\run-program.lisp" "uiop\\lisp-build.lisp" "uiop\\configuration.lisp" "uiop\\backward-driver.lisp" "uiop\\driver.lisp") (asdf-test::makefile-lisp-files "driver-files") evaluates to ("uiop/package.lisp" "uiop/common-lisp.lisp" "uiop/utility.lisp" "uiop/os.lisp" "uiop/pathname.lisp" "uiop/filesystem.lisp" "uiop/stream.lisp" "uiop/image.lisp" "uiop/run-program.lisp" "uiop/lisp-build.lisp" "uiop/configuration.lisp" "uiop/backward-driver.lisp" "uiop/driver.lisp") Script failed -- My Best, Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699
Hi, Dave. Thanks a lot for the testing! The test-sysdef-asdf failure was me assuming Unix pathname syntax. Fixed. The test-touch-system-1.script I'm not sure I understand. Is it a case where your filesystem doesn't have second-granularity timestamps but only minute-granularity timestamp? Further clisp bugs look like they are failures to explicitly call CMD.EXE while doing redirections. Call you add #+clisp (trace ext:shell ext:run-program uiop/run-program:%system) to test-run-program.script and run it again? Weird that this is a new error. Is it working with 3.0.3? If not, 3.0.2? 3.0.1? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Death is only a milestone — albeit one that is dropped on you from a very great height — Terry Pratchett.
The test-touch-system-1.script I'm not sure I understand. Is it a case where your filesystem doesn't have second-granularity timestamps but only minute-granularity timestamp?
What is a good way to test that?
Further clisp bugs look like they are failures to explicitly call CMD.EXE while doing redirections. Call you add #+clisp (trace ext:shell ext:run-program uiop/run-program:%system) to test-run-program.script and run it again?
here is the output for clisp with the above trace directive in place: https://dl.dropboxusercontent.com/u/19667598/clisp-test-3.1.0.70.text
Dear Dave,
The test-touch-system-1.script I'm not sure I understand. Is it a case where your filesystem doesn't have second-granularity timestamps but only minute-granularity timestamp?
What is a good way to test that?
Can you run this code? make load l=clisp (in-package :uiop) (nest (with-temporary-file (:pathname p)) (flet ((foo () (delete-file-if-exists p) (with-output-file (s p) (println "Hello" s)) (prog1 (file-write-date p) (delete-file-if-exists p))))) (let ((first-date (foo))) (sleep 1)) (let ((second-date (foo))) (sleep 1)) (let ((third-date (foo)))) (list (- third-date second-date) (- second-date first-date))) If the answer is (1 1), you have second granularity. If it's either (0 60) or (60 0), you have minute granularity.
Further clisp bugs look like they are failures to explicitly call CMD.EXE while doing redirections. Call you add #+clisp (trace ext:shell ext:run-program uiop/run-program:%system) to test-run-program.script and run it again?
here is the output for clisp with the above trace directive in place:
https://dl.dropboxusercontent.com/u/19667598/clisp-test-3.1.0.70.text
No, you ran this test today, but it uses 3.1.0.35, and the test doesn't trace the requested functions. You might have run it from a different directory than you extracted the asdf code. Please try again with the latest ASDF (3.1.0.72 or whatever). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Soccer riots kill at most tens. Intellectuals' ideological riots sometimes kill millions.— John McCarthy
No, you ran this test today, but it uses 3.1.0.35, and the test doesn't trace the requested functions. You might have run it from a different directory than you extracted the asdf code. Please try again with the latest ASDF (3.1.0.72 or whatever).
Completely and extremely my bad. Please see here for the results with 3.1.0.72 (errors for clisp and one for sbcl -- Allegros are passing now thanks to your fix): https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.72/clisp-te... https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.72/sbcl-tes...
Please see here for the results with 3.1.0.72 (errors for clisp and one for sbcl -- Allegros are passing now thanks to your fix):
https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.72/clisp-te...
The asdf-pathname-test failure looks like the same "probe directory fails on the virtualized disk" issue as discussed before. I assume the same test works when run from a local disk. The test-run-program failure is my failing to specify uiop::%system instead of uiop:%system in the list of functions to trace. Can you try again? After fixing the trace directive, try: make t l=clisp t=test-run-program.script The test-sysdef-asdf error is me being stupid in my Feb 22 commit on run-program. Reverted with a comment why things are working. Or maybe I should use a few ensure-absolute-pathname in with-temporary-file to make things more robust when directory is changed? Please test again.
https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.72/sbcl-tes... This is a case of Users vs users. I used equalp to avoid a failure.
TEST ABORTED: These two expressions yield paths that are not pathname-equal the first expression *TEST-DIRECTORY* yields this: #P"C:/Users/dcooper8/genworks/cl/tests/asdf/asdf-windows/test/" (:HOST #<SB-IMPL::WIN32-HOST {22472481}> :DEVICE "C" :DIRECTORY (:ABSOLUTE "Users" "dcooper8" "genworks" "cl" "tests" "asdf" "asdf-windows" "test") :NAME NIL :TYPE NIL :VERSION NIL) the other expression (GETCWD) yields that: #P"C:/users/dcooper8/genworks/cl/tests/asdf/asdf-windows/test/" (:HOST #<SB-IMPL::WIN32-HOST {22472481}> :DEVICE "C" :DIRECTORY (:ABSOLUTE "users" "dcooper8" "genworks" "cl" "tests" "asdf" "asdf-windows" "test") :NAME NIL :TYPE NIL :VERSION NIL) Please test again with the latest ASDF and tracing uiop/run-program::%system with two colons. Thanks a lot for your support! —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org When a man says money can do anything, that settles it: he hasn't got any. — Edgar Watson Howe
Please test again with the latest ASDF and tracing uiop/run-program::%system with two colons.
https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.73/clisp-te... https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.73/sbcl-tes... Also running both these again now from local Windows filesystem.
Dave Cooper wrote:
Please test again with the latest ASDF and tracing uiop/run-program::%system with two colons.
https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.73/clisp-te...
https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.73/sbcl-tes...
Also running both these again now from local Windows filesystem.
The SBCL test doesn't show any signs of Faré fixing this so that the directory components on windows are treated as case-INsensitive (test-utilities.script failed). Hmmmm.... I don't see any change to uiop/pathname.lisp. Faré, what's the right choice here? Should we be changing the definition of =? in PATHNAME-EQUAL to use EQUALP instead of EQUAL on Windows? This seems heuristically right, but absolutely wrong. In the absolute case, we should somehow interrogate the filesystem to ask it whether filenames are case-sensitive or not. Suggetion: we could hook this by calling a new function CASE-SENSITIVE-FILESYSTEM-P and using EQUAL or EQUALP according to the return value. For now we butcher a check for windows into CASE-SENSITIVE-FILESYSTEM-P and leave it at that. Later we try to do better. What say?
The SBCL test doesn't show any signs of Faré fixing this so that the directory components on windows are treated as case-INsensitive (test-utilities.script failed).
Oops, reading the CLHS, I see that EQUALP specifically does NOT descend into pathnames, unlike other structures, and just calls EQUAL on them. I just committed f9105317 that uses EQUALP on the namestrings instead. Sigh.
Hmmmm.... I don't see any change to uiop/pathname.lisp. Faré, what's the right choice here? Should we be changing the definition of =? in PATHNAME-EQUAL to use EQUALP instead of EQUAL on Windows?
I think we shouldn't, but there could be an explicit PATHNAME-EQUALP, and/or a &key argument to PATHNAME-EQUAL.
This seems heuristically right, but absolutely wrong. In the absolute case, we should somehow interrogate the filesystem to ask it whether filenames are case-sensitive or not.
Suggetion: we could hook this by calling a new function CASE-SENSITIVE-FILESYSTEM-P and using EQUAL or EQUALP according to the return value. For now we butcher a check for windows into CASE-SENSITIVE-FILESYSTEM-P and leave it at that. Later we try to do better.
What say?
Problem, with mount points, etc., how do you identify whether a filesystem is case-sensitive or not? First, how do you identify the "current mount point"? Or do you just try to write in a given directory? What if you have no write access? Do you look at inodes (does Windows give out inode information?) and try to open a file with case switched? What if there's a symlink with the case switched? There are so many corner cases and potential race conditions that any heuristic is going to lose at some point, in addition to the Right Thing requiring system calls that are not available without CFFI. I recommend we just let the user choose between PATHNAME-EQUAL and PATHNAME-EQUALP, or some such. (For the matter, why does SBCL return lower case for Users? Where does it (or the system call it uses) normalize to lowercase?) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A great civilization is not conquered from without until it destroys itself from within. — Will Durant
Faré wrote:
I recommend we just let the user choose between PATHNAME-EQUAL and PATHNAME-EQUALP, or some such.
The only question about this would be whether this is visible to the user or not? Looking into ASDF we find the following calls to PATHNAME-EQUAL: * BINARY-OP calls PATHNAME-EQUAL to see if it will inadvertently overwrite the system .asd file * Under ECL and MKCL, when building a bundle, we use pushnew with PATHNAME-EQUAL; if this is wrong, and PATHNAME-EQUALP is right, then we could get duplicates in the bundle * FIND-SYSTEM calls PATHNAME-EQUAL to see if the system definition source file has been changed. A false positive here will cause unnecessary reloads. * SAME-PACKAGE-SYSTEM-P uses PATHNAME-EQUAL to check and see if two package-systems are the same. I don't see how these problems can be resolved by punting to the user: the user doesn't have access to this level of control. While I agree that a heuristic for deciding whether pathnames are case-sensitive is not ideal, I don't see an alternative to supplying one. But perhaps there's a different way out? At any rate, we'd have to figure out how to handle the above cases. cheers, r
On Tue, Feb 25, 2014 at 1:19 PM, Robert P. Goldman <rpgoldman@sift.info> wrote:
Faré wrote:
I recommend we just let the user choose between PATHNAME-EQUAL and PATHNAME-EQUALP, or some such.
The only question about this would be whether this is visible to the user or not?
I'd rather the user be in control.
Looking into ASDF we find the following calls to PATHNAME-EQUAL:
* BINARY-OP calls PATHNAME-EQUAL to see if it will inadvertently overwrite the system .asd file * Under ECL and MKCL, when building a bundle, we use pushnew with PATHNAME-EQUAL; if this is wrong, and PATHNAME-EQUALP is right, then we could get duplicates in the bundle * FIND-SYSTEM calls PATHNAME-EQUAL to see if the system definition source file has been changed. A false positive here will cause unnecessary reloads. * SAME-PACKAGE-SYSTEM-P uses PATHNAME-EQUAL to check and see if two package-systems are the same.
I don't see how these problems can be resolved by punting to the user: the user doesn't have access to this level of control.
For FIND-SYSTEM and SAME-PACKAGE-SYSTEM-P, remember that these happen within the context of a same configuration. foo.asd will be searched for system "foo", and "Foo.asd" for system "Foo". To ASDF, these are different systems (NB: symbols are downcased), so it's OK for PATHNAME-EQUAL to distinguish them. Then, if the directories are case-sensitive unequal, but case-sensitive equal, that means that you found one file in the first one in configuration order, and the other file in the second one in configuration order, which is proof enough that they are different files. And if configuration changed and case with it, that's also a good reason to reload. Remains the bundle issues. The first one is avoiding to overwrite a .asd file; the second is trying to avoid having the uiop library twice in the archive. Both would require quite some custom asdf methods to have the asd file (respectively uiop library) as output-files of some user system yet with a case-tweaked pathname. Yes, it's possible to do it wrong, but the user has to try hard for it, at which point I think it's OK to concede defeat.
While I agree that a heuristic for deciding whether pathnames are case-sensitive is not ideal, I don't see an alternative to supplying one.
I suspect that committing myself to a mental institution might be a sane alternative to trying to supply a heuristic for case-sensitivity of a filesystem without using CFFI.
But perhaps there's a different way out? At any rate, we'd have to figure out how to handle the above cases.
You're right of course that handling those cases right is important, but I believe they are already handled as right as can be. Trying to double-guess the user based on a flaky case-sensitive heuristic is only the recipe for debugging madness either for you or for the poor user who'll be double-guessed wrong. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If you could ask a unique question to a computer during a Turing test, what would you ask? — Douglas Hofstadter, Metamagical Themas
Sorry for hijacking this discussion. Why are system names case sensitive at all? Wouldn't it be more sane to just make them case-insensitive? It is more complicated to perform case-insensitive file search on a case-sensitive filesystem, of course. On 25 Feb 2014, at 19:40, Faré wrote:
On Tue, Feb 25, 2014 at 1:19 PM, Robert P. Goldman <rpgoldman@sift.info> wrote:
Faré wrote:
I recommend we just let the user choose between PATHNAME-EQUAL and PATHNAME-EQUALP, or some such.
The only question about this would be whether this is visible to the user or not?
I'd rather the user be in control.
Looking into ASDF we find the following calls to PATHNAME-EQUAL:
* BINARY-OP calls PATHNAME-EQUAL to see if it will inadvertently overwrite the system .asd file * Under ECL and MKCL, when building a bundle, we use pushnew with PATHNAME-EQUAL; if this is wrong, and PATHNAME-EQUALP is right, then we could get duplicates in the bundle * FIND-SYSTEM calls PATHNAME-EQUAL to see if the system definition source file has been changed. A false positive here will cause unnecessary reloads. * SAME-PACKAGE-SYSTEM-P uses PATHNAME-EQUAL to check and see if two package-systems are the same.
I don't see how these problems can be resolved by punting to the user: the user doesn't have access to this level of control.
For FIND-SYSTEM and SAME-PACKAGE-SYSTEM-P, remember that these happen within the context of a same configuration. foo.asd will be searched for system "foo", and "Foo.asd" for system "Foo". To ASDF, these are different systems (NB: symbols are downcased), so it's OK for PATHNAME-EQUAL to distinguish them. Then, if the directories are case-sensitive unequal, but case-sensitive equal, that means that you found one file in the first one in configuration order, and the other file in the second one in configuration order, which is proof enough that they are different files. And if configuration changed and case with it, that's also a good reason to reload.
Remains the bundle issues. The first one is avoiding to overwrite a .asd file; the second is trying to avoid having the uiop library twice in the archive. Both would require quite some custom asdf methods to have the asd file (respectively uiop library) as output-files of some user system yet with a case-tweaked pathname. Yes, it's possible to do it wrong, but the user has to try hard for it, at which point I think it's OK to concede defeat.
While I agree that a heuristic for deciding whether pathnames are case-sensitive is not ideal, I don't see an alternative to supplying one.
I suspect that committing myself to a mental institution might be a sane alternative to trying to supply a heuristic for case-sensitivity of a filesystem without using CFFI.
But perhaps there's a different way out? At any rate, we'd have to figure out how to handle the above cases.
You're right of course that handling those cases right is important, but I believe they are already handled as right as can be. Trying to double-guess the user based on a flaky case-sensitive heuristic is only the recipe for debugging madness either for you or for the poor user who'll be double-guessed wrong.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If you could ask a unique question to a computer during a Turing test, what would you ask? — Douglas Hofstadter, Metamagical Themas
On Tue, Feb 25, 2014 at 4:40 PM, Felix Lange <fjl@twurst.com> wrote:
Sorry for hijacking this discussion.
No problem. There are no stupid questions (but see the famous "cluelessness" demotivational poster).
Why are system names case sensitive at all? Wouldn't it be more sane to just make them case-insensitive?
It is more complicated to perform case-insensitive file search on a case-sensitive filesystem, of course.
Well, in practice, people either use symbols, that are downcased, or strings, with a lowercase convention. Therefore, system names are case sensitive, but there is a strong case-converting bias towards lowercase. This both makes it hard to involuntarily stray from the common practical case, yet possible to those who really care to. Should non-lowercase strings be either forbidden or case-converted? That's a backward incompatible change that would need to be tested with cl-test-grid before it's committed — and even then might affect unpublished or proprietary code by other users. So far, this legacy system (inherited from Dan Barlow's ASDF) has worked fine, and I don't see what is to be gained with this incompatible change. I'm not the maintainer anymore, though, so it's not my decision to make. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A student who changes the course of history is probably taking an exam.
Faré wrote:
Should non-lowercase strings be either forbidden or case-converted? That's a backward incompatible change that would need to be tested with cl-test-grid before it's committed — and even then might affect unpublished or proprietary code by other users.
I think there's a strong incentive to make such a backward-incompatible change right now: such systems are *already* broken in at least one sense -- they cannot be used correctly with logical pathnames, nor can they be referred to by symbols. They are, at best, second class citizens. And we can do this semi-backwards compatibly by coercing the symbols, and handling the case where we fail to find the system definition with some recovery actions that come with a warning. This is much more orthogonal than saying "you can use strings or symbols to name systems, and they mostly work the same, except when they don't." I'll think on this some more. Cheers, r
"Robert P. Goldman" <rpgoldman@sift.info> writes:
Faré wrote:
Should non-lowercase strings be either forbidden or case-converted? That's a backward incompatible change that would need to be tested with cl-test-grid before it's committed — and even then might affect unpublished or proprietary code by other users.
I think there's a strong incentive to make such a backward-incompatible change right now:
It would break Quicklisp.
such systems are *already* broken in at least one sense -- they cannot be used correctly with logical pathnames,
Not true. A logical pathname can map to any physical pathname.
nor can they be referred to by symbols.
They are already referred to by symbols whenever someone does (asdf:load-system :foo). Zach
Zach, when ASDF reads a system name from a symbol, it takes the symbol name and down cases it. So loading :foo is the same as loading "foo". So I don't think this should break anything for you, unless quicklisp has some systems with camel-cased names. Also, according to the hyperspec, a logical pathname can only contain upper case letters, so it can't distinguish files whose names differ by case alone. (Cf.19.3.1). For these reasons, it makes sense to treat ASDF system names as case-insensitive. If you have case-sensitive names they may work for some users, and not for others. Best, R On February 25, 2014 5:43:10 PM CST, Zach Beane <xach@xach.com> wrote:
"Robert P. Goldman" <rpgoldman@sift.info> writes:
Faré wrote:
Should non-lowercase strings be either forbidden or case-converted? That's a backward incompatible change that would need to be tested with cl-test-grid before it's committed — and even then might affect unpublished or proprietary code by other users.
I think there's a strong incentive to make such a backward-incompatible change right now:
It would break Quicklisp.
such systems are *already* broken in at least one sense -- they cannot be used correctly with logical pathnames,
Not true. A logical pathname can map to any physical pathname.
nor can they be referred to by symbols.
They are already referred to by symbols whenever someone does (asdf:load-system :foo).
Zach
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
"Robert P. Goldman" <rpgoldman@sift.net> writes:
Zach, when ASDF reads a system name from a symbol, it takes the symbol name and down cases it. So loading :foo is the same as loading "foo".
So I don't think this should break anything for you, unless quicklisp has some systems with camel-cased names.
My mistake, I read the situation backwards. Quicklisp currently coerces system names to downcase before loading.
Also, according to the hyperspec, a logical pathname can only contain upper case letters, so it can't distinguish files whose names differ by case alone. (Cf.19.3.1).
Sure, one logical pathname cannot map to multiple physical pathnames, but any single logical pathname can map to *any* single physical pathname. Zach
Zach Beane wrote:
"Robert P. Goldman" <rpgoldman@sift.net> writes:
Zach, when ASDF reads a system name from a symbol, it takes the symbol name and down cases it. So loading :foo is the same as loading "foo".
So I don't think this should break anything for you, unless quicklisp has some systems with camel-cased names.
My mistake, I read the situation backwards. Quicklisp currently coerces system names to downcase before loading.
Also, according to the hyperspec, a logical pathname can only contain upper case letters, so it can't distinguish files whose names differ by case alone. (Cf.19.3.1).
Sure, one logical pathname cannot map to multiple physical pathnames, but any single logical pathname can map to *any* single physical pathname.
Zach
Right, but the concern is the case (unlikely, but not impossible), where we have systems "fOo" and "foo" which must map to the same file.... I don't see any huge win from permitting this that makes up for the downsides of name collision, and treating strings and symbols non-orthogonally in a hard-to-understand way. I'm certainly willing to entertain counter-arguments if anyone has them. Cheers, r
Felix Lange wrote:
Sorry for hijacking this discussion.
Why are system names case sensitive at all? Wouldn't it be more sane to just make them case-insensitive?
It is more complicated to perform case-insensitive file search on a case-sensitive filesystem, of course.
System names are downcased. They are not case-sensitive (not compatible with logical pathnames and other limited filesystems). The issue here is that a number of internal functions are returning partially downcased directory pathnames, causing mismatches in our tests. Cheers, r
On Tue, Feb 25, 2014 at 11:26 AM, Dave Cooper <david.cooper@genworks.com> wrote:
Please test again with the latest ASDF and tracing uiop/run-program::%system with two colons.
https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.73/clisp-te... https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.73/sbcl-tes...
Also running both these again now from local Windows filesystem.
I (hopefully) fixed the SBCL failure now (see my reply to rpgoldman). The clisp failures: the pathname one is the "usual" probe-files* fails on directories on Windows. The code is ugly enough in uiop/filesystem.lisp. I suppose the right thing to do is to identify what's failing (maybe the file-stat function fails?) and ask the clisp team for help. Can you create a directory with pathname "c:/foo/" and call from CLISP (lisp-implementation-version) (ext:probe-pathname* "c:/foo/") (POSIX:file-stat "c:/foo/" nil) If you need to require something before to be able to use the POSIX package, e.g. (require "posix") or (require "POSIX"), that's a good datapoint, too. Are you using the latest CLISP? Where did you get it when? Sigh. The other two failures are the run-program issue we've been trying to debug for some time, and unhappily this attempt to trace ext:shell failed because or a package lock. Can you try to (ext:without-package-lock ...) or something around the (trace ...) or (eval '(trace ...)) to make it work? You can run a single test with: make t l=clisp t=test-run-program.script Thanks! —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The ancients stole all our ideas from us. — Mark Twain
Thank you for your patience with my zombielike testing.
I (hopefully) fixed the SBCL failure now (see my reply to rpgoldman).
sbcl: 51 tests passing and 0 failing.
Can you create a directory with pathname "c:/foo/" and call from CLISP (lisp-implementation-version) (ext:probe-pathname* "c:/foo/") (POSIX:file-stat "c:/foo/" nil)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; dcooper8@seven ~/genworks/cl-engines/windows/clisp/clisp-2.49 $ ./clisp.exe i i i i i i i ooooo o ooooooo ooooo ooooo I I I I I I I 8 8 8 8 8 o 8 8 I \ `+' / I 8 8 8 8 8 8 \ `-+-' / 8 8 8 ooooo 8oooo `-__|__-' 8 8 8 8 8 | 8 o 8 8 o 8 8 ------+------ ooooo 8oooooo ooo8ooo ooooo 8 Welcome to GNU CLISP 2.49 (2010-07-07) <http://clisp.cons.org/> Copyright (c) Bruno Haible, Michael Stoll 1992, 1993 Copyright (c) Bruno Haible, Marcus Daniels 1994-1997 Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998 Copyright (c) Bruno Haible, Sam Steingold 1999-2000 Copyright (c) Sam Steingold, Bruno Haible 2001-2010 Type :h and hit Enter for context help. [1]> (lisp-implementation-version) "2.49 (2010-07-07) (built on STSst063.jenty.by [150.0.0.63])" [2]> (ext:probe-pathname "c:/foo/") #P"C:\\foo\\" ; #P"C:\\foo\\" ; 3602368770 ; 0 [3]> (POSIX:file-stat "c:/foo/" nil) *** - Win32 error 2 (ERROR_FILE_NOT_FOUND): The system cannot find the file spec ified. The following restarts are available: ABORT :R1 Abort main loop Break 1 [4]> :r1 [5]> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
If you need to require something before to be able to use the POSIX package, e.g. (require "posix") or (require "POSIX"), that's a good datapoint, too.
Did not need to require anything.
Are you using the latest CLISP? Where did you get it when? Sigh.
2.49. I believe I got it from Sourceforge but not 100% sure anymore.
The other two failures are the run-program issue we've been trying to debug for some time, and unhappily this attempt to trace ext:shell failed because or a package lock. Can you try to (ext:without-package-lock ...) or something around the (trace ...) or (eval '(trace ...)) to make it work? You can run a single test with: make t l=clisp t=test-run-program.script
See here: https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.73/clisp-te... -- My Best, Dave
On Tue, Feb 25, 2014 at 9:20 PM, Dave Cooper <david.cooper@genworks.com> wrote:
Thank you for your patience with my zombielike testing. No, thank you for being my zombie in this proxy testing.
I (hopefully) fixed the SBCL failure now (see my reply to rpgoldman). sbcl: 51 tests passing and 0 failing.
One down, one to go.
[3]> (POSIX:file-stat "c:/foo/" nil) *** - Win32 error 2 (ERROR_FILE_NOT_FOUND): The system cannot find the file specified. I've sent a bug report for that to clisp, but we'll avoid file-stat on Windows.
https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.73/clisp-te... Can you try again with the latest ASDF (should be the same you have) plus the attached patch? Please reset any local changes before applying (git reset --hard).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Two possibilities exist: Either we are alone in the Universe or we are not. Both are equally terrifying. — Arthur C. Clarke
Can you try again with the latest ASDF (should be the same you have) plus the attached patch? Please reset any local changes before applying (git reset --hard).
Here is clisp output from 3.1.0.77 with the wclisp.diff patch applied: https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.77-patched/...
On Thu, Feb 27, 2014 at 2:46 PM, Dave Cooper <david.cooper@genworks.com> wrote:
Here is clisp output from 3.1.0.77 with the wclisp.diff patch applied: The patch should fail to apply, because it's already been applied.
https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.77-patched/... Getting there! I disabled a few tests that are OK not to work on Windows: It's really OK for clisp to normalize /foo to c:\foo and we shouldn't reject it.
Hopefully, with latest unmodified commit bdda2e5 clisp windows should be all clear. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Man usually avoids attributing cleverness to somebody else — unless it is an enemy. — Albert Einstein
On Thu, Feb 27, 2014 at 9:37 PM, Faré <fahree@gmail.com> wrote: Hopefully, with latest unmodified commit bdda2e5 clisp windows should
be all clear.
#------------------------------------------------ Using f:/cl-engines/windows/clisp/clisp-2.49/clisp.exe Ran 51 tests: 51 tests passing and 0 failing. All tests apparently successful #------------------------------------------------
Dave Cooper wrote:
No, you ran this test today, but it uses 3.1.0.35, and the test doesn't trace the requested functions. You might have run it from a different directory than you extracted the asdf code. Please try again with the latest ASDF (3.1.0.72 or whatever).
Completely and extremely my bad.
Please see here for the results with 3.1.0.72 (errors for clisp and one for sbcl -- Allegros are passing now thanks to your fix):
https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.72/sbcl-tes...
This looks like a bug in SBCL. Here's the test failure: These two expressions yield paths that are not pathname-equal the first expression ASDF-TEST:*TEST-DIRECTORY* yields this: #P"C:/Users/dcooper8/genworks/cl/tests/asdf/asdf-windows/test/" (:HOST #<SB-IMPL::WIN32-HOST {22472481}> :DEVICE "C" :DIRECTORY (:ABSOLUTE "Users" "dcooper8" "genworks" "cl" "tests" "asdf" "asdf-windows" "test") :NAME NIL :TYPE NIL :VERSION NIL) the other expression (UIOP/OS:GETCWD) yields that: #P"C:/users/dcooper8/genworks/cl/tests/asdf/asdf-windows/test/" (:HOST #<SB-IMPL::WIN32-HOST {22472481}> :DEVICE "C" :DIRECTORY (:ABSOLUTE "users" "dcooper8" "genworks" "cl" "tests" "asdf" "asdf-windows" "test") :NAME NIL :TYPE NIL :VERSION NIL) Script failed Should we be treating Windows filenames as case-insensitive? According to Stack Overflow, NTFS can be configured to be case-sensitive, but typically isn't. Maybe PATHNAME-EQUAL should case-flatten (string-equal) on Windows? -- Robert P. Goldman Staff Scientist Smart Information Flow Technologies (d/b/a SIFT, LLC) 211 N. First St., Suite 300 Minneapolis, MN 55401 Voice: (612) 326-3934 Email: rpgoldman@SIFT.net
Should we be treating Windows filenames as case-insensitive?
According to Stack Overflow, NTFS can be configured to be case-sensitive, but typically isn't.
Maybe PATHNAME-EQUAL should case-flatten (string-equal) on Windows?
It's a tough call, since some filesystems (e.g. remote NFS) are case-sensitive indeed. Same thing on Mac, where the (still?) default HFS+ filesystem is case-insensitive, but other filesystems may be case-sensitive. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org What we Are is God's gift to us. What we Become is our gift to God.
participants (7)
-
Dave Cooper -
Faré -
Felix Lange -
Robert Goldman -
Robert P. Goldman -
Robert P. Goldman
-
Zach Beane