I'm getting what look like spurious failures on tests of "allegro" in test-program.script.
I *believe* that what's going wrong here is that lisp-invocation is getting confused about how to find the right ACL runtime.
If you look at run-tests.sh, you will see that "ALLEGRO" is initially bound using the funky logic at the top of the file, but then is REBOUND on windows to use buildi instead of alisp on that platform....
I *suspect* this is breaking things, because I suspect that the logic for reasoning about the ALLEGRO installation directories is getting run more than once, causing INVOKE-LISP to fail. But INVOKE-LISP doesn't provide any useful information about how it's invoking lisp.
I'll investigate somewhat further, but if an explanation jumps out at you, please LMK.
I believe that this conjecture is supported by the fact that it is only the "allegro" tests that fail -- not allegro64, none of the modern variants, etc.
Cheers, r
On Tue, Sep 29, 2015 at 2:46 PM, Robert Goldman rpgoldman@sift.net wrote:
I'm getting what look like spurious failures on tests of "allegro" in test-program.script.
I *believe* that what's going wrong here is that lisp-invocation is getting confused about how to find the right ACL runtime.
If you look at run-tests.sh, you will see that "ALLEGRO" is initially bound using the funky logic at the top of the file, but then is REBOUND on windows to use buildi instead of alisp on that platform....
From the mention of buildi, I assume this is on Windows.
Yes, something weird happens due to to the environment variable ALLEGRO taking precedence with buildi.
From what I remember of last I tried, it was all working in the
minimakefile branch if alisp was in your $PATH
Many small things are similarly fixed in the minimakefile branch that fail in master. I refuse to look at run-tests.sh anymore.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You can discover what your enemy fears most by observing the means he uses to frighten you. — Eric Hoffer
OK, somehow, although all of the ALLEGRO variants specify that we should be using buildi.exe or build.exe, when we actually get to test-program, it's using alisp.exe, which seems to cause breakage.
I am looking at the output of ALL-ALLEGRO-VARIANTS.
So what is crushing the allegro executable and invoking something else?
Looks like it's (LISP-IMPLEMENTATION-ENVIRONMENT-VARIABLE implementation), which crushes the use of LISP-IMPLEMENTATION-IDENTIFIERS.
If I simply crush the lines in run-tests.sh that re-exports ALLEGRO, that fixes the tests on allegro.
I have pushed that fix.
Need to retest....
Faré wrote:
On Tue, Sep 29, 2015 at 2:46 PM, Robert Goldman rpgoldman@sift.net wrote:
I'm getting what look like spurious failures on tests of "allegro" in test-program.script.
I *believe* that what's going wrong here is that lisp-invocation is getting confused about how to find the right ACL runtime.
If you look at run-tests.sh, you will see that "ALLEGRO" is initially bound using the funky logic at the top of the file, but then is REBOUND on windows to use buildi instead of alisp on that platform....
From the mention of buildi, I assume this is on Windows. Yes, something weird happens due to to the environment variable ALLEGRO taking precedence with buildi. From what I remember of last I tried, it was all working in the minimakefile branch if alisp was in your $PATH
Btw, I meant to mention this before, but the build.exe and buildi.exe really shouldn't be used. They have issues with multiprocessing.
alisp.exe has +s (Windows only) and -L (load) and -e (eval) arguments. You can also use dribble to capture output, in case that's why buildi.exe was being used.
Kevin
Btw, I meant to mention this before, but the build.exe and buildi.exe really shouldn't be used. They have issues with multiprocessing.
alisp.exe has +s (Windows only) and -L (load) and -e (eval) arguments. You can also use dribble to capture output, in case that's why buildi.exe was being used.
These tests don't do multiprocessing, but do test the ability to capture output indeed. Is there a way with alisp.exe to redirect dribble output to the stdout console?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Everytime you're crying and being hysterical because you're told a hard truth, you're actually saying "please lie to me and hide the truth".
Faré wrote:
Btw, I meant to mention this before, but the build.exe and buildi.exe really shouldn't be used. They have issues with multiprocessing.
alisp.exe has +s (Windows only) and -L (load) and -e (eval) arguments. You can also use dribble to capture output, in case that's why buildi.exe was being used.
These tests don't do multiprocessing, but do test the ability to capture output indeed. Is there a way with alisp.exe to redirect dribble output to the stdout console?
No, but I have never personally seen a situation I couldn't work around this issue. (alisp is a Windows program and they can't have bindings to stdout/stderr/stdin.) alisp.exe using dribble => temp file => use temp file in chain of pipes => remove temp file.
These tests don't do multiprocessing, but do test the ability to capture output indeed. Is there a way with alisp.exe to redirect dribble output to the stdout console?
No, but I have never personally seen a situation I couldn't work around this issue. (alisp is a Windows program and they can't have bindings to stdout/stderr/stdin.) alisp.exe using dribble => temp file => use temp file in chain of pipes => remove temp file.
In this case, we're specifically relying on the console interface to run tests against various implementations and report results on the console. Certainly, we could provide a wrapper for Allegro only, but that would be a stretch. So far as I can tell, Allegro is the only implementation solving this issue that way in Windows.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There are just two rules of governance in a free society: Mind your own business. Keep your hands to yourself. — P. J. O'Rourke
Faré wrote:
In this case, we're specifically relying on the console interface to run tests against various implementations and report results on the console. Certainly, we could provide a wrapper for Allegro only, but that would be a stretch. So far as I can tell, Allegro is the only implementation solving this issue that way in Windows.
I'm curious, how do other Windows implementations solve this? Do they have a Windows exe and an console exe?
In this case, we're specifically relying on the console interface to run tests against various implementations and report results on the console. Certainly, we could provide a wrapper for Allegro only, but that would be a stretch. So far as I can tell, Allegro is the only implementation solving this issue that way in Windows.
I'm curious, how do other Windows implementations solve this? Do they have a Windows exe and an console exe?
LispWorks has only a windows exe, but lets you dump a console exe. abcl, ccl, clisp, ecl, mkcl, sbcl seem to have console exe's only. I don't know the status of the recently resurrected cormanlisp; I believe it has a windows-only exe.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Die Mathematiker sind eine Art Franzosen: redet man zu ihnen, so übersetzen sie es in ihre Sprache, und dann ist es alsobald ganz etwas anderes. [Les mathématiciens sont comme les Français: quoiqu'on leur dise, ils le traduisent dans leur propre langue, et cela devient alors quelque chose de complètement différent.] — Johann Wolfgang von Goethe
Faré wrote:
In this case, we're specifically relying on the console interface to run tests against various implementations and report results on the console. Certainly, we could provide a wrapper for Allegro only, but that would be a stretch. So far as I can tell, Allegro is the only implementation solving this issue that way in Windows.
I'm curious, how do other Windows implementations solve this? Do they have a Windows exe and an console exe?
LispWorks has only a windows exe, but lets you dump a console exe. abcl, ccl, clisp, ecl, mkcl, sbcl seem to have console exe's only. I don't know the status of the recently resurrected cormanlisp; I believe it has a windows-only exe.
Thanks for the info.
LispWorks has only a windows exe, but lets you dump a console exe. abcl, ccl, clisp, ecl, mkcl, sbcl seem to have console exe's only. I don't know the status of the recently resurrected cormanlisp; I believe it has a windows-only exe.
Thanks for the info.
I'll add that my current personal use-case for Common Lisp is for scripting, for which I don't care as much for multithreading, but a lot about stdin/stdout integration.
Goodbye, shell, perl, python and ruby. I'm glad you're dead to me.
I admit I don't use Windows (or I'd have tracked and fixed the bug with sbcl and run-program), but if I did, I would be disappointed that allegro doesn't make console programming easy.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Verbal constructs of above-average phonemic quantity implement the qualitative actualization of cognitive disenlightenment. (Big words obscure meaning.)
I'm not sure what the upshot of this is.
Currently, the tests test images and other bundles by starting up a subsidiary lisp, and then checking its console output.
Writing a dribble file wrapper around that will be pretty painful.
For now I propose to continue to use build.exe and buildi.exe for Windows, pending a re-think of how the lisp-invocation library (which we use for testing) should handle console output on windows.
As Faré points out, our tests are single-threaded, so this seems adequate for now.
If I'm missing something, please LMK.
Otherwise, I will probably press on to release 3.1.6.
P.S. I don't have time to do a whole lot of debugging of the SBCL + run-program issue right now, although I have been able to replicate it.
P.S. I don't have time to do a whole lot of debugging of the SBCL + run-program issue right now, although I have been able to replicate it.
Can you replicate while you (trace "UIOP/RUN-PROGRAM" sb-ext:run-program sb-ext:process-input sb-ext:process-output sb-ext:process-error sb-ext:process-pid sb-ext:process-wait sb-ext:process-exit-code)
and then run the same test with ASDF 3.1.3 and the same trace'ing?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Natural laws have no pity. — Robert Heinlein, "Time Enough For Love"
On 9/30/15 Sep 30 -4:35 PM, Faré wrote:
P.S. I don't have time to do a whole lot of debugging of the SBCL + run-program issue right now, although I have been able to replicate it.
Can you replicate while you (trace "UIOP/RUN-PROGRAM" sb-ext:run-program sb-ext:process-input sb-ext:process-output sb-ext:process-error sb-ext:process-pid sb-ext:process-wait sb-ext:process-exit-code)
and then run the same test with ASDF 3.1.3 and the same trace'ing?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Natural laws have no pity. — Robert Heinlein, "Time Enough For Love"
Result of running with new ASDF is on the ticket.
I'll have to do the other later -- rolling back and such is a slow process combining host and VM operations. :-/
But maybe something will leap out at you looking at the new trace output. cheers, r
-
Faré -
Kevin Layer -
Robert Goldman