Performed tests with ABCL and ACL (express edition, and on Windows, as my linux system turns out to be too old to run ACL 9.0 and the ACL 8.0 Express license has expired).
http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-20.html
ACL shows new problem with portableaserve and via it with all genworks-gdl systems. The error: No defined method for ASDF/ACTION:PERFORM oncompiling #<ORIGINAL-ASERVE "aserve" "dummy">
Aside from that all the failures are (upstream) library errors we saw already on other lisps. All the CRASH results are to be ignored. They are caused by heap size limitation of the ACL Express edition.
ABCL shows no new problems. All the failures are upstream library errors we saw already on other lisps and com.informatimago.common-lisp TIMEOUT due to http://trac.common-lisp.net/armedbear/ticket/274.
Best regards, - Anton
ACL shows new problem with portableaserve and via it with all genworks-gdl systems. The error: No defined method for ASDF/ACTION:PERFORM oncompiling #<ORIGINAL-ASERVE "aserve" "dummy">
This is a hack in aserve.asd to allow
(asdf:load-system :aserve)
to bring in the original aserve (via require) in the case of #+allegro.
There are some defclass'es and defmethod'd in the middle of the .asd file to enable this. Maybe this doesn't work so well with ASDF3? Or maybe they just need some (eval-when (...) ...) around them (at the risk of mental health issues)? Here is what the stuff looks like:
#+allegro (defclass original-aserve (asdf:component) ((loaded :initform nil :accessor loaded)))
#+allegro (defmethod asdf:source-file-type ((c original-aserve) (s module)) "dummy")
#+allegro (defmethod asdf:perform ((op asdf:load-op) (c original-aserve)) #+common-lisp-controller (c-l-c:original-require 'aserve) #-common-lisp-controller (require 'aserve) (setf (loaded c) t))
#+allegro (defmethod asdf:operation-done-p ((op asdf:load-op) (c original-aserve)) (loaded c))
#+allegro (defmethod asdf:operation-done-p ((op asdf:compile-op) (c original-aserve)) t)
#+allegro (defsystem aserve :components ((:original-aserve "dummy")))
On Thu, Feb 28, 2013 at 8:46 PM, Dave Cooper david.cooper@genworks.comwrote:
ACL shows new problem with portableaserve and via it with all genworks-gdl
systems. The error: No defined method for ASDF/ACTION:PERFORM oncompiling #<ORIGINAL-ASERVE "aserve" "dummy">
By the way, what is this "oncompiling" operation you speak of?
I'm not seeing a literal "oncompiling" anywhere in ASDF 2.31.4 ...
This is a hack in aserve.asd to allow
(asdf:load-system :aserve)
to bring in the original aserve (via require) in the case of #+allegro.
There are some defclass'es and defmethod'd in the middle of the .asd file to enable this. Maybe this doesn't work so well with ASDF3? Or maybe they just need some (eval-when (...) ...) around them (at the risk of mental health issues)? Here is what the stuff looks like:
#+allegro (defclass original-aserve (asdf:component) ((loaded :initform nil :accessor loaded)))
#+allegro (defmethod asdf:source-file-type ((c original-aserve) (s module)) "dummy")
#+allegro (defmethod asdf:perform ((op asdf:load-op) (c original-aserve)) #+common-lisp-controller (c-l-c:original-require 'aserve) #-common-lisp-controller (require 'aserve) (setf (loaded c) t))
#+allegro (defmethod asdf:operation-done-p ((op asdf:load-op) (c original-aserve)) (loaded c))
#+allegro (defmethod asdf:operation-done-p ((op asdf:compile-op) (c original-aserve)) t)
#+allegro (defsystem aserve :components ((:original-aserve "dummy")))
-- 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
01.03.2013, 05:57, "Dave Cooper" david.cooper@genworks.com:
On Thu, Feb 28, 2013 at 8:46 PM, Dave Cooper david.cooper@genworks.com wrote:
ACL shows new problem with portableaserve and via it with all genworks-gdl systems. The error: No defined method for ASDF/ACTION:PERFORM oncompiling #<ORIGINAL-ASERVE "aserve" "dummy">
By the way, what is this "oncompiling" operation you speak of?
I'm not seeing a literal "oncompiling" anywhere in ASDF 2.31.4 ...
Sorry, it is a copy/paste error. Actually it is "on compiling"
By the way how can I replicate this myself for testing?
For testing of specific systems, just temporarily replace the asdf in my implementation with ASDF 2.31.4, then proceed with quicklisp as usual?
For trying cl-test-grid with a cutting edge ASDF what is the recommended approach?
On Thu, Feb 28, 2013 at 8:46 PM, Dave Cooper david.cooper@genworks.comwrote:
ACL shows new problem with portableaserve and via it with all genworks-gdl
systems. The error: No defined method for ASDF/ACTION:PERFORM oncompiling #<ORIGINAL-ASERVE "aserve" "dummy">
This is a hack in aserve.asd to allow
(asdf:load-system :aserve)
to bring in the original aserve (via require) in the case of #+allegro.
There are some defclass'es and defmethod'd in the middle of the .asd file to enable this. Maybe this doesn't work so well with ASDF3? Or maybe they just need some (eval-when (...) ...) around them (at the risk of mental health issues)? Here is what the stuff looks like:
#+allegro (defclass original-aserve (asdf:component) ((loaded :initform nil :accessor loaded)))
#+allegro (defmethod asdf:source-file-type ((c original-aserve) (s module)) "dummy")
#+allegro (defmethod asdf:perform ((op asdf:load-op) (c original-aserve)) #+common-lisp-controller (c-l-c:original-require 'aserve) #-common-lisp-controller (require 'aserve) (setf (loaded c) t))
#+allegro (defmethod asdf:operation-done-p ((op asdf:load-op) (c original-aserve)) (loaded c))
#+allegro (defmethod asdf:operation-done-p ((op asdf:compile-op) (c original-aserve)) t)
#+allegro (defsystem aserve :components ((:original-aserve "dummy")))
-- 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
I patch quicklisp.
I have a directory quicklisp-patched for this purpose. Copy new asdf.lisp to quicklisp-patched/asdf.lisp and edit quicklisp-patched/setup.lisp to change (defvar *required-asdf-version* "2.26") to (defvar *required-asdf-version* "2.31.4")
If you just want to test aserve, you can run a command like
alisp -qq -ee '(load "quicklisp-patched/setup.lisp") -ee '(ql:quickload :aserver)' (haven't run this, but you see the idea)
If you want to run all the cl-test-grid tests, then in the cl-test-grid/run-agent.lisp I comment out (test-grid-agent:main *agent*)
and to the following instead:
(setf (test-grid-agent:lisps *agent*) (list *ccl-1.8-x86* *acl*) ; lisp implementations I want to test (test-grid-agent::result-storage-name *agent*) "asdf" ; name of the online storage where the results should be sotred )
(test-grid-agent::test-patched-quicklisp *agent* #p"/home/testgrid/quicklisp-patched/" ; the directory where patched quicklisp is located "quicklisp 2013-01-28 + asdf.2.31.4-enc-dflt-no-warn + asdf-sys-conn-fix" ; the name I want to give to that patched quicklisp )
If you just want to test aserve, you can run 01.03.2013, 06:54, "Dave Cooper" david.cooper@genworks.com:
By the way how can I replicate this myself for testing?
For testing of specific systems, just temporarily replace the asdf in my implementation with ASDF 2.31.4, then proceed with quicklisp as usual?
For trying cl-test-grid with a cutting edge ASDF what is the recommended approach?
On Thu, Feb 28, 2013 at 8:46 PM, Dave Cooper david.cooper@genworks.com wrote:
ACL shows new problem with portableaserve and via it with all genworks-gdl systems. The error: No defined method for ASDF/ACTION:PERFORM oncompiling #<ORIGINAL-ASERVE "aserve" "dummy">
This is a hack in aserve.asd to allow
(asdf:load-system :aserve)
to bring in the original aserve (via require) in the case of #+allegro.
There are some defclass'es and defmethod'd in the middle of the .asd file to enable this. Maybe this doesn't work so well with ASDF3? Or maybe they just need some (eval-when (...) ...) around them (at the risk of mental health issues)? Here is what the stuff looks like:
#+allegro (defclass original-aserve (asdf:component) ((loaded :initform nil :accessor loaded)))
#+allegro (defmethod asdf:source-file-type ((c original-aserve) (s module)) "dummy")
#+allegro (defmethod asdf:perform ((op asdf:load-op) (c original-aserve)) #+common-lisp-controller (c-l-c:original-require 'aserve) #-common-lisp-controller (require 'aserve) (setf (loaded c) t))
#+allegro (defmethod asdf:operation-done-p ((op asdf:load-op) (c original-aserve)) (loaded c))
#+allegro (defmethod asdf:operation-done-p ((op asdf:compile-op) (c original-aserve)) t)
#+allegro (defsystem aserve :components ((:original-aserve "dummy")))
--
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
-- 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
01.03.2013, 07:37, "Anton Vodonosov" avodonosov@yandex.ru:
I patch quicklisp.
I have a directory quicklisp-patched for this purpose. Copy new asdf.lisp to quicklisp-patched/asdf.lisp and edit quicklisp-patched/setup.lisp to change (defvar *required-asdf-version* "2.26") to (defvar *required-asdf-version* "2.31.4")
If it's also necessary to include patched versions of some libraries into testing, they are places/symlinked to quicklisp-patched/local-projects
On Thu, Feb 28, 2013 at 8:29 PM, Anton Vodonosov avodonosov@yandex.ruwrote:
http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-20.html
ACL shows new problem with portableaserve and via it with all genworks-gdl systems. The error: No defined method for ASDF/ACTION:PERFORM oncompiling #<ORIGINAL-ASERVE "aserve" "dummy">
This is fixed by adding an empty method as follows to aserve.asd:
;;; #+allegro (defmethod asdf:perform ((op asdf:compile-op) (c original-aserve))) ;;;
I will get a patch to Rudi Schlatte for updating of the portableaserve on sourceforge (this is the one used by Quicklisp).
OK, so the results are massively positive, and the failures all known and most of them already fixed upstream. I'll ping keithj again — he fixed cl-sam already, but still hasn't fixed deoxybytes-systems. Apart from that, the only system that looks like it loses and doesn't have a fix yet is buildapp, but I'm confident Xach will fix it sooner than later.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Suicidal terrorists may have short shelf lives. — John McCarthy
On Sun, Mar 3, 2013 at 8:10 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
As there were some fixes, running tests again.
ASDF version 2.31.8 Quicklisp version is shifted to 2013-02-17.
SBCL results arrived already: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21.html
Other will follow.
asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
04.03.2013, 05:49, "Faré" fare@tunes.org:
OK, so the results are massively positive, and the failures all known and most of them already fixed upstream. I'll ping keithj again — he fixed cl-sam already, but still hasn't fixed deoxybytes-systems. Apart from that, the only system that looks like it loses and doesn't have a fix yet is buildapp, but I'm confident Xach will fix it sooner than later.
Positive changes are mostly due to utf-8. Yes, buildapp is the only new regression we haven't seen before.
Meantime, the table is updated with CCL results: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21.html
Nothing new on CCL, we saw all these failures previously.
On Sun, Mar 3, 2013 at 9:39 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
04.03.2013, 05:49, "Faré" fare@tunes.org:
OK, so the results are massively positive, and the failures all known and most of them already fixed upstream. I'll ping keithj again — he fixed cl-sam already, but still hasn't fixed deoxybytes-systems. Apart from that, the only system that looks like it loses and doesn't have a fix yet is buildapp, but I'm confident Xach will fix it sooner than later.
Positive changes are mostly due to utf-8. Yes, buildapp is the only new regression we haven't seen before.
Oh, we have seen it before. It's just that Xach is still in "wait and see" mode regarding ASDF, and not moving on that one, yet.
Meantime, the table is updated with CCL results: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21.html
Nothing new on CCL, we saw all these failures previously.
OK. I'll run some tests from work tomorrow, and release an ASDF 2.32.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org First they ignore you. Then they laugh at you. Then they fight you. Then you win. — Gandhi
04.03.2013, 06:42, "Faré" fare@tunes.org:
On Sun, Mar 3, 2013 at 9:39 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
Yes, buildapp is the only new regression we haven't seen before.
Oh, we have seen it before.
Yes, I have found it in previous results.
Meantime, the table is updated with CCL results: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21.html
Nothing new on CCL, we saw all these failures previously.
OK. I'll run some tests from work tomorrow, and release an ASDF 2.32.
Tomorrow there will also be results from CLISP, ECL and CMUCL. ABCL will take longer.
http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21.html CLISP and ECL results are ready - nothing new.
CMUCL results are also ready, but we can't compare them with nonpatched quicklisp, as current quicklisp doesn't support CMUCL out of box. I have compared them with the last quicklisp supported CMUCL, but due to cl-fad issue in the last quicklisp (https://github.com/edicl/cl-fad/issues/6) the table contains many unrelated failures: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21-cmucl.html
To have a better comparison base I think to run CMUCL tests on quicklisp 2012-02-17 fixed so that it works with its own ASDF. Will do so after ABCL tests are finished.
http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21.html ABCL results also have no new failures.
But CMUCL still has problem: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21-cmucl.html
Here we compare with quicklisp 2012-02-17 patched so that it doesn't (require 'asdf) before loading it's own ASDF, and so overcoming the ASDF upgrade issue present in the current quicklisp.
I.e. the same codebase is tested 1) with ASDF 2.26 without upgrade 2) with to ASDF 2.31.8 loaded after the (require 'asdf).
Most of the failures are due to the same error: -330 is not of type (OR (MOD 536870911) NULL)
I am not sure what it is, probably some kind of utf-8 related bug.
But CMUCL still has problem: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21-cmucl.html
Most of the failures are due to the same error: -330 is not of type (OR (MOD 536870911) NULL)
I am not sure what it is, probably some kind of utf-8 related bug.
We've had that failure in the past, on an old version of CMUCL, then it disappeared with a more recent one.
Which version are you using?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org What one person receives without working for, another person must work for without receiving. — Adrian Rogers
Is anyone running the tests on ACL any more?
thanks, r
I'm intending to do routine cl-test-grid testing with ACL (Linux and WIndows) but I still have to get a proper automated testbed set up. I have been working with the latest ASDF but have not been doing rigorous cl-test-grid testing with it yet.
On Tue, Mar 5, 2013 at 11:53 AM, Robert Goldman rpgoldman@sift.info wrote:
Is anyone running the tests on ACL any more?
thanks, r
asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
On Tue, Mar 12, 2013 at 8:18 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
- test CMUCL 2013-03 snapshot where the bug is fixed.
http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-22-cmucl.html
Here we have 3 regressions, all caused by utf8. Either this is another utf8 bug in CMUCL or the source files really contain broken encoding.
Yes, lispbuilder-regex and cl-bibtex are both known for having latin1 characters. I warned the maintainers a year ago, and they did nothing and didn't reply. We can assume the packages are unhappily unmaintained. There is another fork of regex that was maintained and fixed last year, but this year the maintainer did not respond regarding warnings.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Only presidents, editors, and people with tapeworms have the right to use the editorial "we." — Mark Twain
"Anton" == Anton Vodonosov avodonosov@yandex.ru writes:
Anton> 2. test CMUCL 2013-03 snapshot where the bug is fixed. Anton> http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-22-cmucl.html Anton> Anton> Here we have 3 regressions, all caused by utf8. Either this is another Anton> utf8 bug in CMUCL or the source files really contain broken encoding.
Unfortunately, another serious error got in to 2013-03. Please try 2013-03-a instead.
or let me know what the 3 regressions are and I can try them myself.
Ray
13.03.2013, 04:55, "Raymond Toy" toy.raymond@gmail.com:
"Anton" == Anton Vodonosov avodonosov@yandex.ru writes:
Anton> 2. test CMUCL 2013-03 snapshot where the bug is fixed. Anton> http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-22-cmucl.html Anton> Anton> Here we have 3 regressions, all caused by utf8. Either this is another Anton> utf8 bug in CMUCL or the source files really contain broken encoding.
Unfortunately, another serious error got in to 2013-03. Please try 2013-03-a instead.
According to Faré these libraries indeed have latin1 characters.
or let me know what the 3 regressions are and I can try them myself.
See the link. In the table, column "quicklisp 2013-02-17 + asdf.2.32" contains test results of this qucklisp patched to use ASDF 2.32.
(LOAD bibtex FAIL) means that (ql:quickload :bibtex :verbose t) fails. Other two are (LOAD lispbuilder-lexer FAIL) and (LOAD lispbuilder-regex FAIL).
- Anton
"Anton" == Anton Vodonosov avodonosov@yandex.ru writes:
Anton> 13.03.2013, 04:55, "Raymond Toy" toy.raymond@gmail.com: >>>>>>> "Anton" == Anton Vodonosov avodonosov@yandex.ru writes: >> >> Anton> 2. test CMUCL 2013-03 snapshot where the bug is fixed. >> Anton> http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-22-cmucl.html >> Anton> >> Anton> Here we have 3 regressions, all caused by utf8. Either this is another >> Anton> utf8 bug in CMUCL or the source files really contain broken encoding. >> >> Unfortunately, another serious error got in to 2013-03. Please try >> 2013-03-a instead.
Anton> According to Faré these libraries indeed have latin1 characters.
Ah, yes, I see now. I do get utf-8 decoding errors on those three libraries.
Thanks for testing this though. Much appreciated.
Ray
"Anton" == Anton Vodonosov avodonosov@yandex.ru writes:
Anton> http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21.html Anton> ABCL results also have no new failures.
Anton> But CMUCL still has problem: Anton> http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21-cmucl.html
Anton> Here we compare with quicklisp 2012-02-17 patched so that it doesn't Anton> (require 'asdf) before loading it's own ASDF, and so overcoming Anton> the ASDF upgrade issue present in the current quicklisp.
Anton> I.e. the same codebase is tested 1) with ASDF 2.26 without upgrade Anton> 2) with to ASDF 2.31.8 loaded after the (require 'asdf).
Anton> Most of the failures are due to the same error: Anton> -330 is not of type (OR (MOD 536870911) NULL)
Anton> I am not sure what it is, probably some kind of utf-8 related bug.
I only checked a few of the failed tests so far. They do look like some shortcomings in unicode support but others do not.
I also see that it looks like you're using cmucl 20c. That's pretty old. The utf-8 bug that you reported recently has been fixed and is now available in the 2013-03 snapshot from trac.common-lisp.net/cmucl.
Ray
-
Anton Vodonosov -
Dave Cooper -
Faré -
Faré -
Raymond Toy -
Robert Goldman