Hello,
Diff between ABCL 1.3.1 and the current dev version (svn revision 14755): https://common-lisp.net/project/cl-test-grid/abcl/abcl-diff25.html
Unfortunately there are only regressions.
(The green results for cffi-libffi are due to installed libffi-dev on the testing machine, not because of ABCL improvement)
Best regards, - Anton
Hi Anton,
Thanks for running the tests! Bummer that the change causes regressions and no improvements. It's completely against my expectations, but with that data in hand, I should be able to figure out what went wrong.
Thanks!
Regards,
Erik.
On Tue, Apr 7, 2015 at 12:02 AM, Anton Vodonosov avodonosov@yandex.ru wrote:
Hello,
Diff between ABCL 1.3.1 and the current dev version (svn revision 14755): https://common-lisp.net/project/cl-test-grid/abcl/abcl-diff25.html
Unfortunately there are only regressions.
(The green results for cffi-libffi are due to installed libffi-dev on the testing machine, not because of ABCL improvement)
Best regards,
- Anton
07.04.2015, 01:07, "Erik Huelsmann" ehuels@gmail.com:
Bummer that the change causes regressions and no improvements.
Note, we don't know exactly what of the changes between release 1.3.1 and the current dev version causes the regressions, it's not necessary the last commit.
On 04/07/15 00:12, Anton Vodonosov wrote:
07.04.2015, 01:07, "Erik Huelsmann" ehuels@gmail.com:
Bummer that the change causes regressions and no improvements.
Note, we don't know exactly what of the changes between release 1.3.1 and the current dev version causes the regressions, it's not necessary the last commit.
I've checked the regressions for my own libraries, hyperluminal-mem and stmx.
The failed test in hyperluminal-mem simply due to an old version of stmx - I will update it on github.
The failed test in stmx looks more serious. I have reduced it to the following code, which prints ; Evaluation aborted on NIL. instead of returning the expected hash-table object:
(let ((h1 (make-hash-table :test 'equalp)) (h2 (make-hash-table :test 'equalp)) (h (make-hash-table :test 'equalp))) (setf (gethash 1 h1) 2 (gethash 2 h2) 1 (gethash h1 h) h2 (gethash h2 h) h1) h)
Regards,
Massimiliano Ghilardi
Hi Masimiliano,
On Tue, Apr 7, 2015 at 8:14 PM, Massimiliano Ghilardi < massimiliano.ghilardi@gmail.com> wrote:
On 04/07/15 00:12, Anton Vodonosov wrote:
07.04.2015, 01:07, "Erik Huelsmann" ehuels@gmail.com:
Bummer that the change causes regressions and no improvements.
Note, we don't know exactly what of the changes between release 1.3.1 and the current dev version causes the regressions, it's not necessary the last commit.
I've checked the regressions for my own libraries, hyperluminal-mem and stmx.
The failed test in hyperluminal-mem simply due to an old version of stmx - I will update it on github.
The failed test in stmx looks more serious. I have reduced it to the following code, which prints ; Evaluation aborted on NIL. instead of returning the expected hash-table object:
(let ((h1 (make-hash-table :test 'equalp)) (h2 (make-hash-table :test 'equalp)) (h (make-hash-table :test 'equalp))) (setf (gethash 1 h1) 2 (gethash 2 h2) 1 (gethash h1 h) h2 (gethash h2 h) h1) h)
Thanks for the easy reproduction recipe. I've built ABCL pre and post my labels-dead-code-elimination change. And fortunately for me, the code fails both before and after. So, it's unrelated. Needless to say that it's still a regression and should probably be fixed.
I've filed http://abcl.org/trac/ticket/388 to track the issue. Thanks for reporting!
On Wed, Apr 8, 2015 at 11:17 AM, Erik Huelsmann ehuels@gmail.com wrote:
Hi Masimiliano, Thanks for the easy reproduction recipe. I've built ABCL pre and post my labels-dead-code-elimination change. And fortunately for me, the code fails both before and after. So, it's unrelated. Needless to say that it's still a regression and should probably be fixed.
I've filed http://abcl.org/trac/ticket/388 to track the issue. Thanks for reporting!
-- Bye,
Erik.
Hello Erik,
from the stack trace you helpfully added to http://abcl.org/trac/ticket/388 it turns out it's my fault, specifically my patch to fix EQUALP caused this regression. The solution is trivial, I will post it from home...
Only I am surprised that LispObjects can be null: is it allowed, and when can it happen?
Max
On 04/08/15 14:35, Massimiliano Ghilardi wrote:
On Wed, Apr 8, 2015 at 11:17 AM, Erik Huelsmann ehuels@gmail.com wrote:
Hi Masimiliano, Thanks for the easy reproduction recipe. I've built ABCL pre and post my labels-dead-code-elimination change. And fortunately for me, the code fails both before and after. So, it's unrelated. Needless to say that it's still a regression and should probably be fixed.
I've filed http://abcl.org/trac/ticket/388 to track the issue. Thanks for reporting!
-- Bye,
Erik.
Hello Erik,
from the stack trace you helpfully added to http://abcl.org/trac/ticket/388 it turns out it's my fault, specifically my patch to fix EQUALP caused this regression. The solution is trivial, I will post it from home...
Only I am surprised that LispObjects can be null: is it allowed, and when can it happen?
Max
In attachment a patch that should fix issue 388.
Before accepting it, please check whether ABCL is really supposed to pass null LispObjects to the Java implementation of primitive types: the NullPointerException was due to a call to Fixnum.equalp(LispObject obj) with obj == null
Regards,
Max
On 2015/4/8 20:13, Massimiliano Ghilardi wrote: […]
Only I am surprised that LispObjects can be null: is it allowed, and when can it happen?
As far as I can determine, LispObject references should never be null when being passed as an argument to a Java function, but the code base is inconsistent (buggy) on this point.
Max
In attachment a patch that should fix issue 388.
Before accepting it, please check whether ABCL is really supposed to pass null LispObjects to the Java implementation of primitive types: the NullPointerException was due to a call to Fixnum.equalp(LispObject obj) with obj == null
Regards,
Max
Your patch has been applied as [r14757][].
As for your question on "whether ABCL is really supposed to pass null LispObject references to the Java implementation of primitive types", I think the answer is negative, as a Java primitive type by definition cannot hold a null reference. This disjunction from java.lang.Object is what "makes" it a primitive type. Our codebase is riddled with the assumption that accessing a LispObject won't return a null, as in the location your [test case failed][1]:
if (!value.equalp(ht.get(key))) { return false; }
Here, ht.get() should not return a null reference to be chained into the value.equalp() call no matter what the value of 'key' turns out to be. In lieu of something like a comprehensive audit, we are unfortunately left fixing these problems on a case by case basis.
But perhaps I have misunderstood your question somewhat: is there something more specific you were referring to?
[r14757]: http://abcl.org/trac/changeset/14757 [1]: http://abcl.org/trac/browser/trunk/abcl/src/org/armedbear/lisp/HashTable.jav...
On 04/11/15 09:59, Mark Evenson wrote:
On 2015/4/8 20:13, Massimiliano Ghilardi wrote: […]
Only I am surprised that LispObjects can be null: is it allowed, and when can it happen?
As far as I can determine, LispObject references should never be null when being passed as an argument to a Java function, but the code base is inconsistent (buggy) on this point.
Understood.
As for your question on "whether ABCL is really supposed to pass null LispObject references to the Java implementation of primitive types", I think the answer is negative, as a Java primitive type by definition cannot hold a null reference. This disjunction from java.lang.Object is what "makes" it a primitive type. Our codebase is riddled with the assumption that accessing a LispObject won't return a null, as in the location your [test case failed][1]:
if (!value.equalp(ht.get(key))) { return false; }Here, ht.get() should not return a null reference to be chained into the value.equalp() call no matter what the value of 'key' turns out to be. In lieu of something like a comprehensive audit, we are unfortunately left fixing these problems on a case by case basis.
From what I saw, ht.get(key) returns Java null if key is not present in the hash-table. I agree this is a case of "the code base is inconsistent (buggy) on this point".
On the other hand, let me change my mind and tell this: I find it non-obviously useful, although contorted. Since Java null is not a valid LispObjects, it can represent "failure", as in the case "key not present in hash-table", without having to use multiple values.
For example, for a EQUALP hash-table, "value.equalp(ht.get(key))" exactly means "hash-table ht contains the pair key/value"
If ht.get(key) is modified to return a valid LispObject (for example NIL) to mean "key not found", the code "value.equalp(ht.get(key))" will become bugged for value == NIL. Fixing it requires ht.get(key) to return multiple values. The code "value.equalp(ht.get(key))" would become more complicated, probably something like:
LispObject v = ht.get(key); LispThread.currentThread().getValues()[1] != NIL && value.equalp(v);
But perhaps I have misunderstood your question somewhat: is there something more specific you were referring to?
I was asking the same question you already answered above.
Just I realize "primitive types" is misleading, as I meant "types defined by the Common Lisp standard and implemented in Java by ABCL", not "Java primitive types".
Regards,
Max
Hi Anton,
On Tue, Apr 7, 2015 at 12:12 AM, Anton Vodonosov avodonosov@yandex.ru wrote:
07.04.2015, 01:07, "Erik Huelsmann" ehuels@gmail.com:
Bummer that the change causes regressions and no improvements.
Note, we don't know exactly what of the changes between release 1.3.1 and the current dev version causes the regressions, it's not necessary the last commit.
Sure. That's no problem. However, I'm not understanding something: I tested the cl-cont LABELS-2 and -3 failures. On my own system they didn't fail. Is there something in the tester environment that could make it fail? Did the cl-cont tests run in their own ABCL instance? Or did they run after lots of other test in the same instance?
Regards,
Reproduce it like this:
(ql:quickload :cl-cont-test) (let ((rtest::*compile-tests* t)) (rtest:do-tests))
The RT test framework has two modes, rtest::*compile-tests* == t and nil. cl-test-grid runs both modes.
Did the cl-cont tests run in their own ABCL instance?
Yes, separate ABCL process.
Best regards, - Anton
09.04.2015, 21:55, "Erik Huelsmann" ehuels@gmail.com:
Hi Anton,
On Tue, Apr 7, 2015 at 12:12 AM, Anton Vodonosov avodonosov@yandex.ru wrote:
07.04.2015, 01:07, "Erik Huelsmann" ehuels@gmail.com:
Bummer that the change causes regressions and no improvements.
Note, we don't know exactly what of the changes between release 1.3.1 and the current dev version causes the regressions, it's not necessary the last commit.
Sure. That's no problem. However, I'm not understanding something: I tested the cl-cont LABELS-2 and -3 failures. On my own system they didn't fail. Is there something in the tester environment that could make it fail? Did the cl-cont tests run in their own ABCL instance? Or did they run after lots of other test in the same instance?
Regards,
-- Bye,
Erik.
http://efficito.com%C2%A0-- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
Ah. This is probably the compiled version which fails. The interpreted version is the one I ran.
On Thu, Apr 9, 2015 at 9:09 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
Reproduce it like this:
(ql:quickload :cl-cont-test) (let ((rtest::*compile-tests* t)) (rtest:do-tests))
The RT test framework has two modes, rtest::*compile-tests* == t and nil. cl-test-grid runs both modes.
Did the cl-cont tests run in their own ABCL instance?
Yes, separate ABCL process.
Best regards,
- Anton
09.04.2015, 21:55, "Erik Huelsmann" ehuels@gmail.com:
Hi Anton,
On Tue, Apr 7, 2015 at 12:12 AM, Anton Vodonosov avodonosov@yandex.ru
wrote:
07.04.2015, 01:07, "Erik Huelsmann" ehuels@gmail.com:
Bummer that the change causes regressions and no improvements.
Note, we don't know exactly what of the changes between release 1.3.1
and the current dev version
causes the regressions, it's not necessary the last commit.
Sure. That's no problem. However, I'm not understanding something: I
tested the cl-cont LABELS-2 and -3 failures. On my own system they didn't fail. Is there something in the tester environment that could make it fail? Did the cl-cont tests run in their own ABCL instance? Or did they run after lots of other test in the same instance?
Regards,
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
Ok. I understand the problem now. This is indeed caused by my commit, however, the old code had a similar problem -- not with LABELS, but with FLET, which apparently nobody ever ran into yet: There's a problem in the order of macro-expansion versus binding the local functions to shadow macros in the lexical environment.
Working on a fix now.
On Thu, Apr 9, 2015 at 9:10 PM, Erik Huelsmann ehuels@gmail.com wrote:
Ah. This is probably the compiled version which fails. The interpreted version is the one I ran.
On Thu, Apr 9, 2015 at 9:09 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
Reproduce it like this:
(ql:quickload :cl-cont-test) (let ((rtest::*compile-tests* t)) (rtest:do-tests))
The RT test framework has two modes, rtest::*compile-tests* == t and nil. cl-test-grid runs both modes.
Did the cl-cont tests run in their own ABCL instance?
Yes, separate ABCL process.
Best regards,
- Anton
09.04.2015, 21:55, "Erik Huelsmann" ehuels@gmail.com:
Hi Anton,
On Tue, Apr 7, 2015 at 12:12 AM, Anton Vodonosov avodonosov@yandex.ru
wrote:
07.04.2015, 01:07, "Erik Huelsmann" ehuels@gmail.com:
Bummer that the change causes regressions and no improvements.
Note, we don't know exactly what of the changes between release 1.3.1
and the current dev version
causes the regressions, it's not necessary the last commit.
Sure. That's no problem. However, I'm not understanding something: I
tested the cl-cont LABELS-2 and -3 failures. On my own system they didn't fail. Is there something in the tester environment that could make it fail? Did the cl-cont tests run in their own ABCL instance? Or did they run after lots of other test in the same instance?
Regards,
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
http://abcl.org/trac/changeset/14756 fixes the cl-cont problems. After providing enough PermGen memory, I got the other failures to complete correctly (including stmx, btw) now too.
Could you run the tests again to see if *now* there are new successes? (I'm still expecting new successes, but I can't remember which systems were failing that were reporting eliminated dead code in LABELS.)
Regards,
Erik.
On Thu, Apr 9, 2015 at 10:08 PM, Erik Huelsmann ehuels@gmail.com wrote:
Ok. I understand the problem now. This is indeed caused by my commit, however, the old code had a similar problem -- not with LABELS, but with FLET, which apparently nobody ever ran into yet: There's a problem in the order of macro-expansion versus binding the local functions to shadow macros in the lexical environment.
Working on a fix now.
On Thu, Apr 9, 2015 at 9:10 PM, Erik Huelsmann ehuels@gmail.com wrote:
Ah. This is probably the compiled version which fails. The interpreted version is the one I ran.
On Thu, Apr 9, 2015 at 9:09 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
Reproduce it like this:
(ql:quickload :cl-cont-test) (let ((rtest::*compile-tests* t)) (rtest:do-tests))
The RT test framework has two modes, rtest::*compile-tests* == t and nil. cl-test-grid runs both modes.
Did the cl-cont tests run in their own ABCL instance?
Yes, separate ABCL process.
Best regards,
- Anton
09.04.2015, 21:55, "Erik Huelsmann" ehuels@gmail.com:
Hi Anton,
On Tue, Apr 7, 2015 at 12:12 AM, Anton Vodonosov avodonosov@yandex.ru
wrote:
07.04.2015, 01:07, "Erik Huelsmann" ehuels@gmail.com:
Bummer that the change causes regressions and no improvements.
Note, we don't know exactly what of the changes between release 1.3.1
and the current dev version
causes the regressions, it's not necessary the last commit.
Sure. That's no problem. However, I'm not understanding something: I
tested the cl-cont LABELS-2 and -3 failures. On my own system they didn't fail. Is there something in the tester environment that could make it fail? Did the cl-cont tests run in their own ABCL instance? Or did they run after lots of other test in the same instance?
Regards,
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
OK
09.04.2015, 23:50, "Erik Huelsmann" ehuels@gmail.com:
http://abcl.org/trac/changeset/14756 fixes the cl-cont problems. After providing enough PermGen memory, I got the other failures to complete correctly (including stmx, btw) now too.
Could you run the tests again to see if *now* there are new successes? (I'm still expecting new successes, but I can't remember which systems were failing that were reporting eliminated dead code in LABELS.)
Regards,
Erik.
09.04.2015, 23:50, "Erik Huelsmann" ehuels@gmail.com:
http://abcl.org/trac/changeset/14756 fixes the cl-cont problems. After providing enough PermGen memory, I got the other failures to complete correctly (including stmx, btw) now too.
Could you run the tests again to see if *now* there are new successes? (I'm still expecting new successes, but I can't remember which systems were failing that were reporting eliminated dead code in LABELS.)
Regards,
Erik.
Hello,
Here is the report: https://common-lisp.net/project/cl-test-grid/abcl/abcl-diff26.html (BTW, the it was run on new quicklisp 2015-04-07)
The only remaining regression is stmx - I suppose caused by http://abcl.org/trac/ticket/388 as Massimiliano reports. Erik, this error happens even with large PermGen space - it happens during tests, not during ql:quickload. You may reproduce with (asdf:test-op :stmx).
The situation with iolib-tests is an improvement. Previous ABCL 1.3.1 catches raw java error:
#<THREAD "interpreter" {1F10B9C}>: Debugger invoked on condition of type ERROR Caught java.nio.charset.UnsupportedCharsetException: LATIN-1. Restarts: 0: TOP-LEVEL Return to top level.
while new ABCL wraps the java error into a lisp condition:
Error loading /home/testgrid/.cache/common-lisp/abcl-1.4.0-dev-svn-14756-fasl42-linux-x86/home/testgrid/quicklisp/dists/quicklisp/software/iolib-20150302-git/tests/sockets.abcl at line 9 (offset 542) #<THREAD "interpreter" {C5B62D}>: Debugger invoked on condition of type SIMPLE-ERROR Undefined encoding: LATIN-1 Restarts: 0: TRY-RECOMPILING Recompile sockets and try loading it again 1: RETRY Retry loading FASL for #<ASDF/LISP-ACTION:CL-SOURCE-FILE "iolib/tests" "sockets">. 2: ACCEPT Continue, treating loading FASL for #<ASDF/LISP-ACTION:CL-SOURCE-FILE "iolib/tests" "sockets"> as having been successful. 3: RETRY Retry ASDF operation. 4: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration. 5: ABORT Give up on "iolib-tests" 6: TOP-LEVEL Return to top level.
Erik, probably the iolib-tests and hyperluminal-mem improvements are not what you expected from the dead code elimination fix.
Let me know if any new tests are necessary.
Best regards, - Anton
armedbear-devel@common-lisp.net
-
Anton Vodonosov -
Erik Huelsmann -
Mark Evenson -
Massimiliano Ghilardi