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:
On Thu, Feb 27, 2014 at 2:46 PM, Dave Cooper david.coo...@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.
On Thu, Feb 27, 2014 at 9:37 PM, Faré fah...@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
On Tue, Feb 25, 2014 at 9:20 PM, Dave Cooper david.coo...@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
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
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-test.text
https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.73/sbcl-test.text
Also running both these
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-test.text
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
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
On Tue, Feb 25, 2014 at 11:26 AM, Dave Cooper david.coo...@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-test.text
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,
On Tue, Feb 25, 2014 at 4:40 PM, Felix Lange f...@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
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
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
Robert P. Goldman rpgold...@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
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
Robert P. Goldman rpgold...@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
Zach Beane wrote:
Robert P. Goldman rpgold...@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
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
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
If the answer is (1 1), you have second granularity.
If it's either (0 60) or (60 0), you have minute granularity.
Answer is (1 1), so apparently it does have second granularity.
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
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).
23 matches
Mail list logo
