From marcoxa at cs.nyu.edu  Mon Dec  2 09:58:06 2019
From: marcoxa at cs.nyu.edu (Marco Antoniotti)
Date: Mon, 2 Dec 2019 10:58:06 +0100
Subject: On preparations to turn the Bear past 11
In-Reply-To: <A4CE7B68-6ACB-4476-AEAD-E0813A10E041@panix.com>
References: <A4CE7B68-6ACB-4476-AEAD-E0813A10E041@panix.com>
Message-ID: <FD54B14B-98C0-4A72-94AF-DFE7756DD3E3@cs.nyu.edu>

Dear Mark, dear all

I salute (belatedly) your achievements!

Well done!

Marco






> On Nov 22, 2019, at 24:15 , Mark Evenson <evenson at panix.com> wrote:
> 
> Dear long-suffering fans of the Bear,
> 
> Rejoice! for preparations for the release of abcl-1.6.0 to support
> openjdk{6,7,8,11} and beyond near completion.
> 
> We have managed to get a [Continuous Integration (CI)][travis-builds]
> build mostly working via Travis CI integration with the Github
> repository.  Anyone who forks us on Github with suitable monkeying
> around can get automated build and test results for their commits to
> their fork.  The [current version of the tests][.travis.yml] attempt
> to run in environments that are the cross product of macOS/Linux with
> openjdk8/openjdk11.  This isn't quite completely working yet as I
> haven't apparently figured out how to use jenv in Travis to specify
> the correct openjdk to invoke, but I'm close.  For now, we at least
> getting test coverage for openjdk11 under Linux, and I hope to iron
> out the remaining kinks real soon now.  It should be theoretically
> possible to [add Windows builds][windows-builds] as well, but I am
> planning on to tackling that in the near future.
> 
> The CI tests have given me the confidence to next attempt to release
> abcl-1.6.0 via existing release engineering process in spite of the
> following problems:
> 
> 1. While they seemingly pass in the CI, the CFFI linkages to CL+SSL
>   libraries often fail in a spectacularly segmentation fault in
>   practical use.  With judicious refinement, I think we can figure
>   out what is going but for now we should just accept this.
> 
> 2. [A major regression from abcl-1.5.0][pathname-problems] concerning
>   the use of CL:PATHNAME to refer to objects within a jar/zip archive
>   has been discovered, but curiously it is seemingly not fatal to
>   anything other than the execution of ABCL test suite.  In analyzing
>   the problems, I realized that we can considerably clean up our
>   abstraction for a CL:PATHNAME which denotes an entry in an archive
>   by allowing nested archives using the CL:PATHNAME-DEVICE component.
>   To do this in a reasonably clean manner means a fair amount of
>   modification on the Java side of our implementation by reflecting
>   the various types of a CL:PATHNAME in that Java hierarchy as Erik
>   Hülsmann suggested many years ago.  While I have some promising
>   preliminary patches towards this, due to the amount of outstanding
>   effort, I feel we should get abcl-1.6.0 out first.
> 
> Please holler loudly real soon if anyone has problems with releasing
> as things currently stand.
> 
> I intend follow up with abcl-1.6.1 within a month to hopefully address
> the two major blockers in addition to any errata.
> 
> [travis-builds]: https://travis-ci.org/armedbear/abcl/builds
> [.travis.yml]: https://github.com/armedbear/abcl/blob/master/.travis.yml
> [windows-builds]: https://twitter.com/ArmedBear/status/1197538417678192645
> [cl+ssl-problems]: https://abcl.org/trac/ticket/464
> [pathname-problems]: https://github.com/armedbear/abcl/commit/e962be5e0dd86335cc66415a0a417f9e4bb3040b
> 
> yers,
> Mark <evenson at panix.com>
> 
> -- 
> "A screaming comes across the sky.  It has happened before but there is nothing 
> to compare to it now."
> 
> 
> 
> 
> 

--
Marco Antoniotti




From evenson at panix.com  Wed Dec  4 20:37:00 2019
From: evenson at panix.com (Mark Evenson)
Date: Wed, 4 Dec 2019 21:37:00 +0100
Subject: coerce a number to a short
In-Reply-To: <IvR8eNE_kxi7OuC0wbt3LMxOLsaCtix10E0xfxPibRXOk_muaKxlPBnr9FEakxjzXAB8Xw6zTRmeU1C6GHcXSNCIKLSMR7i7TYz70ZYQk4Q=@protonmail.com>
References: <1086359376.367093.1574789889915.ref@mail.yahoo.com>
 <1086359376.367093.1574789889915@mail.yahoo.com>
 <CCB1E64C-02BD-4CC3-9138-C4161F658647@panix.com>
 <1917470483.579830.1574821701707@mail.yahoo.com>
 <IvR8eNE_kxi7OuC0wbt3LMxOLsaCtix10E0xfxPibRXOk_muaKxlPBnr9FEakxjzXAB8Xw6zTRmeU1C6GHcXSNCIKLSMR7i7TYz70ZYQk4Q=@protonmail.com>
Message-ID: <2D771F14-6B28-44C1-A448-FD84F3B94D0E@panix.com>



> On Nov 27, 2019, at 05:53, somewhat-functional-programmer <somewhat-functional-programmer at protonmail.com> wrote:
> 
> Here's a workaround in the meantime (though it's more verbose)... using java.lang.Short.reverseBytes(short s) as the test case[1]:
> 
> ;; no such method failure
> (jstatic "reverseBytes" "java.lang.Short" #x7f)


[Tests via ABCL-PROVE added.][ABCL-PROVE]

[ABCL-PROVE]: https://github.com/armedbear/abcl/pull/131

-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."







From didier at lrde.epita.fr  Fri Dec  6 11:59:49 2019
From: didier at lrde.epita.fr (Didier Verna)
Date: Fri, 06 Dec 2019 12:59:49 +0100
Subject: [CfP] ELS 2020, 13th European Lisp Symposium, April 27-28, Zurich
Message-ID: <m2y2vpu0ju.fsf@lrde.epita.fr>


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

		     13th European Lisp Symposium
		      Special Focus on Compilers

			   Call for papers

		      April 27 - April 28, 2020
			     GZ Riesbach
			 Zürich, Switzerland

	     http://www.european-lisp-symposium.org/2020

		      Sponsored by EPITA, Igalia S.L.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Invited Speakers
~~~~~~~~~~~~~~~~
Andrew W. Keep (Cisco Systems, Inc.), on the Nanopass Framework.
Daniel Kochmański (Turtleware), on ECL, the Embeddable Common Lisp.


Important Dates
~~~~~~~~~~~~~~~
- Submission deadline: February 13, 2020
- Author notification: March 16, 2020
- Final papers due:    April 6, 2020
- Symposium:           April 27 - 28, 2020


Scope
~~~~~
The purpose of the European Lisp Symposium is to provide a forum for
the discussion and dissemination of all aspects of design,
implementation and application of any of the Lisp dialects, including
Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp,
ISLISP, Dylan, ECMAScript, SKILL and so on. We encourage everyone
interested in Lisp to participate.

The European Lisp Symposium 2020 invites high quality papers about
novel research results, insights and lessons learned from practical
applications, and educational perspectives. We also encourage
submissions about known ideas as long as they are presented in a new
setting and/or in a highly elegant way.

This year's focus will be directed towards "Compilers".

We especially invite submissions in the following areas:

- Compiler techniques
- Compiler passes
- Compiler compilers
- Showcasing of industrial or experimental compilers
- Code generation
- Compiler verification
- Compiler optimizations
- JIT compilers

Contributions are also welcome in other areas, including but not
limited to:

- Context-, aspect-, domain-oriented and generative programming
- Macro-, reflective-, meta- and/or rule-based development approaches
- Language design and implementation
- Language integration, inter-operation and deployment
- Development methodologies, support and environments
- Educational approaches and perspectives
- Experience reports and case studies


Technical Program
~~~~~~~~~~~~~~~~~
We invite submissions in the following forms:

* Papers: Technical papers of up to 15 pages that describe original
  results or explain known ideas in new and elegant ways.

* Demonstrations: Abstracts of up to 4 pages for demonstrations of
  tools, libraries, and applications.

* Tutorials: Abstracts of up to 4 pages for in-depth presentations
  about topics of special interest for at least 90 minutes and up to
  180 minutes.

All submissions should be formatted following the ACM SIGS guidelines
and include ACM Computing Classification System 2012 concepts and
terms. Submissions should be uploaded to Easy Chair, at the following
http://www.easychair.org/conferences/?conf=els2020

Note: to help us with the review process please indicate the type of
submission by entering either "paper", "demo", or "tutorial" in the
Keywords field.


Programme Chair
~~~~~~~~~~~~~~~
Ioanna M. Dimitriou H. - Igalia, Spain/Germany

Local Chair
~~~~~~~~~~~
Nicolas Hafner - Shinmera, Switzerland

Programme Committee
~~~~~~~~~~~~~~~~~~~
Andy Wingo - Igalia, Spain/France
Asumu Takikawa - Igalia, Spain/USA
Charlotte Herzeel - IMEC, Intel Exascience Lab, Belgium
Christophe Rhodes - Google, UK
Iréne Durand - Université Bordeaux 1, France
Jim Newton - EPITA Research Lab, France
Kent Pitman - HyperMeta, USA
Leonie Dreschler-Fischer - University of Hamburg, Germany
Marco Heisig - FAU Erlangen-Nürnberg, Germany
Mark Evenson - not.org, Austria
Max Rottenkolber - Interstellar Ventures, Germany
Paulo Matos - Igalia, Spain/Germany
Robert Goldman - SIFT, USA
Robert Strandh - Université Bordeaux 1, France

(more PC members to be announced)

-- 
Resistance is futile. You will be jazzimilated.

Lisp, Jazz, Aïkido: http://www.didierverna.info


From somewhat-functional-programmer at protonmail.com  Fri Dec 13 19:14:13 2019
From: somewhat-functional-programmer at protonmail.com (somewhat-functional-programmer)
Date: Fri, 13 Dec 2019 19:14:13 +0000
Subject: coerce a number to a short
In-Reply-To: <2D771F14-6B28-44C1-A448-FD84F3B94D0E@panix.com>
References: <1086359376.367093.1574789889915.ref@mail.yahoo.com>
 <1086359376.367093.1574789889915@mail.yahoo.com>
 <CCB1E64C-02BD-4CC3-9138-C4161F658647@panix.com>
 <1917470483.579830.1574821701707@mail.yahoo.com>
 <IvR8eNE_kxi7OuC0wbt3LMxOLsaCtix10E0xfxPibRXOk_muaKxlPBnr9FEakxjzXAB8Xw6zTRmeU1C6GHcXSNCIKLSMR7i7TYz70ZYQk4Q=@protonmail.com>
 <2D771F14-6B28-44C1-A448-FD84F3B94D0E@panix.com>
Message-ID: <npXLLHcj4FwG0NetEROSTio9ejHTT9TQ9pewSH9sab5QgVN4TA3SsN-ywKLYoMtdLAS8rdxfOKxPK_j7R15BcG-8lB8glwTFr7viPFQ09qc=@protonmail.com>

I've looked into this issue at length now and I think I have something worth
discussing and potentially trying[0] . The root issue here lies in how ABCL
converts its CL representation of integers to Java, as well as its conversion
of Java primitives to other Java primitives.

ABCL's common superclass for all objects (LispObject) includes two methods to
convert the lisp object to a Java representation: LispObject.javaInstance() and
LispObject.javaInstance(Class). LispObject.javaInstance(Class) presumably tries
to convert the internal representation to the type represented by the Class
passed in. In practice, this seems to be primarily used for Java primitive
types. The current implementation of these methods in ABCL's internal Bignum,
DoubleFloat, SingleFloat, Fixnum, LispCharacter, and JavaObject, do not seem to
have all the required permutations necessary to support all of the possible Java
primitive converting operations.

Even for instances where a conversion /is/ implemented (such as
Fixnum.javaInstance(Short) where a Short would be returned), the method lookup
strategy in Java.findMethod (which boils down to what Java.isAssignable does)
doesn't find the method with the Short parameter. Instead it uses normal rules
in the Java Language spec and only looks for methods that potentially /widen/
primitives, and disallows any narrowing without an explicit narrowing cast (and
in Brad's example, the literal 16 or 32 is represented by Fixnum, which converts
to java.lang.Integer). I think the original intention is to have such methods be
called using jcoerce, such as:

(jcoerce 32 (jclass "short"))
or
(jcoerce 32 (jclass "java.lang.Short"))

This fails in the current implementation, I believe due to a bug in
JavaObject(Object, Class) constructor. This only does one type of conversion, to
java.lang.Byte, if the intended class is Byte and the Object implements Number.

For jcoerce to work with all primitives, all possible primitive operations need
to be covered in JavaObject(Object, Class).

I have attached a patch that adds these conversions to JavaObject(Object,
Class). However, I've also changed other places where these primitive
conversions are done for consistency. My rule of thumb has been that the Java
Language Specification rules[1] should be followed, and the /only/ time a
/narrowing/ conversion is allowed where information can potentially be lost, is
through the JavaObject(Object, Class) constructor (in Lisp land, called using
the (java:jcoerce) function).

As such, the patch also changes the implementation classes Bignum, DoubleFloat,
SingleFloat, Fixnum, Character, and JavaObject, to support all possible
primitive /widening/ conversions. Their implementations of
LispObject.javaInstance(Class) continue to signal type errors for conversions
that cannot be performend, but also now for all narrowing operations. Previously
/some/ of these classes allowed /some/ narrowing conversions to happen. I think
a case could be made for each of these LispObject implementations to allow any
primitve conversion. The disadvantage is not knowing an information reducing
operation potentially occurred (and is counter to the behavior of not finding
narrowing methods such as Brad's original example) -- at the very least if all
primitive narrowing operations /were/ allowed from Fixnum.javaInstance(Class)
for example, a compiler warning should be emitted (though I'm not sure how that
would be implemented).

The following patch may break code that relies on the one conversion that has
worked in the past (to byte, in the JavaObject(Object, Class) constructor. In
fact, this patch breaks swank. To fix your swank, modify your swank's abcl.lisp
to include the now required jcoerce call (in the octets-to-jbytes function): the
jstatic call should now look like:
... (around line 191)
          do (java:jstatic (java:jmethod "java.lang.reflect.Array"  "setByte"
                            "java.lang.Object" "int" "byte")
                           "java.lang.reflect.Array"
                           bytes i (java:jcoerce byte "byte")))

What are your thoughts? I dislike backwards incompatible changes like this, but
I think the impact is probably low due to the fact that method resolution used
rules to only find widening conversions, and the fact that short and byte are
not as commonly used in method calls.

Previously, (jfield) and (jproperty) uses would also not signal a type error
unless LispObject.javaInstance(Class) did not support the conversion (and like
mentioned previously, some classes did some primitive narrowing operations).
Uses of these fields will now (consistently) with method calls, error on
narrowing conversions unless coerced.

Try the patch (but make sure to modify your swank!)...

Now my old example works like the following:
(jstatic "reverseBytes" "java.lang.Short" (jcoerce #x7f "short"))

Note also that the patch didn't break any new tests.  I ran tests via:
(require 'asdf)
(load "~/quicklisp/setup.lisp")
(asdf:initialize-source-registry
  `(:source-registry (:directory ,*default-pathname-defaults*) :inherit-configuration))
(asdf:test-system :abcl)


-Mark

[0] See patch attached (against latest master of https://github.com/armedbear/abcl)
    (3a54c91f3a0cbb71ae8d161acadecf118a65404c)

[1] Widening Primitve Conversion
    https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2




‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, December 4, 2019 8:37 PM, Mark Evenson <evenson at panix.com> wrote:

> > On Nov 27, 2019, at 05:53, somewhat-functional-programmer somewhat-functional-programmer at protonmail.com wrote:
> > Here's a workaround in the meantime (though it's more verbose)... using java.lang.Short.reverseBytes(short s) as the test case[1]:
> > ;; no such method failure
> > (jstatic "reverseBytes" "java.lang.Short" #x7f)
>
> [Tests via ABCL-PROVE added.][ABCL-PROVE]
>
> [ABCL-PROVE]: https://github.com/armedbear/abcl/pull/131
>
> ------------------------------------------------------------------------------------------------------
>
> "A screaming comes across the sky. It has happened before but there is nothing
> to compare to it now."


-------------- next part --------------
A non-text attachment was scrubbed...
Name: primitive-narrowing-jcoerce-fix.patch
Type: text/x-patch
Size: 11693 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20191213/3fd00a2c/attachment.bin>

From eric.marsden at free.fr  Sat Dec 14 09:43:58 2019
From: eric.marsden at free.fr (Eric Marsden)
Date: Sat, 14 Dec 2019 10:43:58 +0100
Subject: java.lang.VerifyError with PROGN
Message-ID: <fc5e598e-b35a-da8f-4993-5f56319152b2@free.fr>

Hi,

Compiling the loading the code below (a simplified extract of SBCL's
codebase, found attempting to crossbuild SBCL with ABCL) results in a
VerifyError, possibly related to the implementation of PROGN. Using
1.6.1-dev-svn-15217.

java.lang.VerifyError: (class: org/armedbear/lisp/foo_1, method: execute signature: (Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Expecting to find object/array on stack
	at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
	at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3137)
	at java.base/java.lang.Class.getConstructor0(Class.java:3342)
	at java.base/java.lang.Class.newInstance(Class.java:556)
	at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130)
	at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:832)
	at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582)
	at org.armedbear.lisp.Lisp.eval(Lisp.java:540)
	at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577)
	at org.armedbear.lisp.Lisp.eval(Lisp.java:540)
	at org.armedbear.lisp.Lisp.progn(Lisp.java:709)
	at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:273)
	at org.armedbear.lisp.Lisp.eval(Lisp.java:530)
	at org.armedbear.lisp.Load.faslLoadStream(Load.java:667)
	at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457)


---
(in-package :cl-user)

(progn
   (defvar*sxhash-crosscheck*  nil)
   (defun sxhash (x)
     (let ((answer (if (string= x "NIL") (ash 1343225879 (- 1)))))
       (push (cons x answer)*sxhash-crosscheck*)
       answer)))


-- Eric Marsden https://risk-engineering.org/



From evenson at panix.com  Sun Dec 15 07:15:58 2019
From: evenson at panix.com (Mark Evenson)
Date: Sun, 15 Dec 2019 08:15:58 +0100
Subject: coerce a number to a short
In-Reply-To: <npXLLHcj4FwG0NetEROSTio9ejHTT9TQ9pewSH9sab5QgVN4TA3SsN-ywKLYoMtdLAS8rdxfOKxPK_j7R15BcG-8lB8glwTFr7viPFQ09qc=@protonmail.com>
References: <1086359376.367093.1574789889915.ref@mail.yahoo.com>
 <1086359376.367093.1574789889915@mail.yahoo.com>
 <CCB1E64C-02BD-4CC3-9138-C4161F658647@panix.com>
 <1917470483.579830.1574821701707@mail.yahoo.com>
 <IvR8eNE_kxi7OuC0wbt3LMxOLsaCtix10E0xfxPibRXOk_muaKxlPBnr9FEakxjzXAB8Xw6zTRmeU1C6GHcXSNCIKLSMR7i7TYz70ZYQk4Q=@protonmail.com>
 <2D771F14-6B28-44C1-A448-FD84F3B94D0E@panix.com>
 <npXLLHcj4FwG0NetEROSTio9ejHTT9TQ9pewSH9sab5QgVN4TA3SsN-ywKLYoMtdLAS8rdxfOKxPK_j7R15BcG-8lB8glwTFr7viPFQ09qc=@protonmail.com>
Message-ID: <16667360-9D41-4D9A-AF1A-1B31F621A196@panix.com>



> On Dec 13, 2019, at 20:14, somewhat-functional-programmer <somewhat-functional-programmer at protonmail.com> wrote:
> 
> I've looked into this issue at length now and I think I have something worth
> discussing and potentially trying[0] . The root issue here lies in how ABCL
> converts its CL representation of integers to Java, as well as its conversion
> of Java primitives to other Java primitives.

[…]

Thanks for the needed extensive re-working here; working [through my review][1] as I find time.

[1]: https://github.com/easye/abcl/tree/somewhat-functional/primitive-narrowing



-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."







From evenson at panix.com  Sun Dec 15 07:49:27 2019
From: evenson at panix.com (Mark Evenson)
Date: Sun, 15 Dec 2019 08:49:27 +0100
Subject: Hosting SBCL builds with ABCL (was Re: java.lang.VerifyError with
 PROGN)
In-Reply-To: <fc5e598e-b35a-da8f-4993-5f56319152b2@free.fr>
References: <fc5e598e-b35a-da8f-4993-5f56319152b2@free.fr>
Message-ID: <DBEA4646-571F-4FDB-B6AC-966D3B62038B@panix.com>



> On Dec 14, 2019, at 10:43, Eric Marsden <eric.marsden at free.fr> wrote:
> 
> Hi,
> 
> Compiling the loading the code below (a simplified extract of SBCL's
> codebase, found attempting to crossbuild SBCL with ABCL) results in a
> VerifyError, possibly related to the implementation of PROGN. Using
> 1.6.1-dev-svn-15217.
> 

Thanks for the report.  I agree that it looks like a problem with ABCL.

Way back in 2009 while working towards releasing ABCL-1.0.0 as the first ANSI
conformant release of the Bear, fixing ABCL to host a build of SBCL was quite
helpful in shaking out errors in ABCL.  And it also was helpful in finding
problems with SBCL as sometimes the fault lay in their stars.

In attending [the SBCL workshop last week][sbcl20], I intended to see what the
Bear’s current status was in hosting a contemporary SBCL build.

[sbcl20]: http://www.sbcl.org/sbcl20/

(Un)fortunately, I spent most of my time at SBCL20 learning about what others
were doing in Common Lisp, especially taking advantage of the proximity of Zach
(Quicklisp), Luis (SLIME), and Christophe (SBCL) to frame larger questions of
the open CL implementation that ABCL finds itself within as we go into 2020.

Consequently, I never got beyond the new (to me) SBCL `make.sh` facade failing
to create a configuration.

I’m stuck at trying to host SBCL with ABCL via

   bash -x make.sh --xc-host="$HOME/work/abcl/abcl —batch”

ends in the lack of SBCL features being generated:

   gmake: Entering directory '/usr/home/mevenson/work/sbcl/src/runtime'                 
   GNUmakefile:42: genesis/Makefile.features: No such file or directory                 
   gmake: *** No rule to make target 'genesis/Makefile.features'.  Stop.                
   gmake: Leaving directory '/usr/home/mevenson/work/sbcl/src/runtime’         

I’ve started to poke around in the build system by manually invoking each step,
but haven’t found out why an ABCL-hosted compile is not generating the default
SBCL features.  Mebbe the interwebs can help a Bear our here, or I’ll
eventually figure it out for myself.

-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."







From stassats at gmail.com  Sun Dec 15 11:52:33 2019
From: stassats at gmail.com (Stas Boukarev)
Date: Sun, 15 Dec 2019 14:52:33 +0300
Subject: Hosting SBCL builds with ABCL (was Re: java.lang.VerifyError with
 PROGN)
In-Reply-To: <DBEA4646-571F-4FDB-B6AC-966D3B62038B@panix.com>
References: <fc5e598e-b35a-da8f-4993-5f56319152b2@free.fr>
 <DBEA4646-571F-4FDB-B6AC-966D3B62038B@panix.com>
Message-ID: <CAF63=13iNsrOpg=JdH2-BPdSUzNSLscj7yjenowBskOdmPriTA@mail.gmail.com>

On Sun, Dec 15, 2019 at 10:49 AM Mark Evenson <evenson at panix.com> wrote:
>  Mebbe the interwebs can help a Bear our here, or I’ll
> eventually figure it out for myself.
Well, Eric already did help, identifying the offending form.


From somewhat-functional-programmer at protonmail.com  Sun Dec 15 18:12:33 2019
From: somewhat-functional-programmer at protonmail.com (somewhat-functional-programmer)
Date: Sun, 15 Dec 2019 18:12:33 +0000
Subject: java.lang.VerifyError with PROGN
In-Reply-To: <fc5e598e-b35a-da8f-4993-5f56319152b2@free.fr>
References: <fc5e598e-b35a-da8f-4993-5f56319152b2@free.fr>
Message-ID: <s1S3Ow4aRfmNgjJyRrt3_Jqs52FF2tM4MVrNXcFgaPMeWDgo4N7WW_nLCWhocPEXwxEJhCjNHD-T0xVSsvXQICaAx8iae9i9C9tEhBi-J08=@protonmail.com>

Thank you for sending in this form -- I apologize - I am certain that this was introduced by my patch earlier this year to fix a couple of stack inconsistency bugs[0] -- a result of my modification to the p2-ash function.

An minimal form that reproduces this bug:
(let ((fn
        (compile
         nil
         '(lambda ()
           (ash 1343225879 (- 1))))))
  (funcall fn))

In this particular case, (ash 1343225879 (- 1)) should compile to a constant, but doesn't, and the particular Java verification error stems from trying to load and store the -1 constant using aload/astore* instead of iload*.  I have a local fix for this, and am also generating test cases with different types specified to exercise all possible code paths in p2-ash (such as):
(the fixnum (ash (the fixnum x) 2))

Sorry for the trouble!  And again, thanks for sending this in, especially something so small and reproducible.

I hope to be able to contribute more to ABCL this year if it makes sense, but at the very least can help fix this problem I introduced, I should be able to send out a patch tonight or at least very soon,

-Mark


[0] https://mailman.common-lisp.net/pipermail/armedbear-devel/2019-May/003977.html

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, December 14, 2019 9:43 AM, Eric Marsden <eric.marsden at free.fr> wrote:

> Hi,
>
> Compiling the loading the code below (a simplified extract of SBCL's
> codebase, found attempting to crossbuild SBCL with ABCL) results in a
> VerifyError, possibly related to the implementation of PROGN. Using
> 1.6.1-dev-svn-15217.
>
> java.lang.VerifyError: (class: org/armedbear/lisp/foo_1, method: execute signature: (Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Expecting to find object/array on stack
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3137)
> at java.base/java.lang.Class.getConstructor0(Class.java:3342)
> at java.base/java.lang.Class.newInstance(Class.java:556)
> at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130)
> at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165)
> at org.armedbear.lisp.LispThread.execute(LispThread.java:832)
> at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582)
> at org.armedbear.lisp.Lisp.eval(Lisp.java:540)
> at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577)
> at org.armedbear.lisp.Lisp.eval(Lisp.java:540)
> at org.armedbear.lisp.Lisp.progn(Lisp.java:709)
> at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:273)
> at org.armedbear.lisp.Lisp.eval(Lisp.java:530)
> at org.armedbear.lisp.Load.faslLoadStream(Load.java:667)
> at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457)
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> (in-package :cl-user)
>
> (progn
> (defvarsxhash-crosscheck nil)
> (defun sxhash (x)
> (let ((answer (if (string= x "NIL") (ash 1343225879 (- 1)))))
> (push (cons x answer)sxhash-crosscheck)
> answer)))
>
> -- Eric Marsden https://risk-engineering.org/




From evenson at panix.com  Mon Dec 16 10:02:53 2019
From: evenson at panix.com (Mark Evenson)
Date: Mon, 16 Dec 2019 11:02:53 +0100
Subject: Hosting SBCL builds with ABCL (was Re: java.lang.VerifyError with
 PROGN)
In-Reply-To: <CAF63=13iNsrOpg=JdH2-BPdSUzNSLscj7yjenowBskOdmPriTA@mail.gmail.com>
References: <fc5e598e-b35a-da8f-4993-5f56319152b2@free.fr>
 <DBEA4646-571F-4FDB-B6AC-966D3B62038B@panix.com>
 <CAF63=13iNsrOpg=JdH2-BPdSUzNSLscj7yjenowBskOdmPriTA@mail.gmail.com>
Message-ID: <CFAD9820-56F6-4DB3-9E8E-54AFBFA6E5B0@panix.com>



> On Dec 15, 2019, at 12:52, Stas Boukarev <stassats at gmail.com> wrote:
> 
> On Sun, Dec 15, 2019 at 10:49 AM Mark Evenson <evenson at panix.com> wrote:
>> Mebbe the interwebs can help a Bear our here, or I’ll
>> eventually figure it out for myself.
> Well, Eric already did help, identifying the offending form.

Agreed.  

I was pointing out my inability to figure out how to undertake an ABCL-hosted SBCL build, but again this is entirely within my ability when I find the time.





-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."







From avodonosov at yandex.ru  Tue Dec 17 15:28:20 2019
From: avodonosov at yandex.ru (Anton Vodonosov)
Date: Tue, 17 Dec 2019 18:28:20 +0300
Subject: Hosting SBCL builds with ABCL (was Re: java.lang.VerifyError with
 PROGN)
In-Reply-To: <CFAD9820-56F6-4DB3-9E8E-54AFBFA6E5B0@panix.com>
References: <fc5e598e-b35a-da8f-4993-5f56319152b2@free.fr>
 <DBEA4646-571F-4FDB-B6AC-966D3B62038B@panix.com>
 <CAF63=13iNsrOpg=JdH2-BPdSUzNSLscj7yjenowBskOdmPriTA@mail.gmail.com>
 <CFAD9820-56F6-4DB3-9E8E-54AFBFA6E5B0@panix.com>
Message-ID: <26304621576596500@iva1-582e889cf4a9.qloud-c.yandex.net>

BTW, this error also prevents hyperluminal-mem library from loading:
https://common-lisp.net/project/cl-test-grid/abcl/abcl-diff30.html

16.12.2019, 13:03, "Mark Evenson" <evenson at panix.com>:
>>  On Dec 15, 2019, at 12:52, Stas Boukarev <stassats at gmail.com> wrote:
>>
>>  On Sun, Dec 15, 2019 at 10:49 AM Mark Evenson <evenson at panix.com> wrote:
>>>  Mebbe the interwebs can help a Bear our here, or I’ll
>>>  eventually figure it out for myself.
>>  Well, Eric already did help, identifying the offending form.
>
> Agreed.
>
> I was pointing out my inability to figure out how to undertake an ABCL-hosted SBCL build, but again this is entirely within my ability when I find the time.
>
> --
> "A screaming comes across the sky. It has happened before but there is nothing
> to compare to it now."


From somewhat-functional-programmer at protonmail.com  Wed Dec 18 01:17:30 2019
From: somewhat-functional-programmer at protonmail.com (somewhat-functional-programmer)
Date: Wed, 18 Dec 2019 01:17:30 +0000
Subject: java.lang.VerifyError with PROGN
In-Reply-To: <s1S3Ow4aRfmNgjJyRrt3_Jqs52FF2tM4MVrNXcFgaPMeWDgo4N7WW_nLCWhocPEXwxEJhCjNHD-T0xVSsvXQICaAx8iae9i9C9tEhBi-J08=@protonmail.com>
References: <fc5e598e-b35a-da8f-4993-5f56319152b2@free.fr>
 <s1S3Ow4aRfmNgjJyRrt3_Jqs52FF2tM4MVrNXcFgaPMeWDgo4N7WW_nLCWhocPEXwxEJhCjNHD-T0xVSsvXQICaAx8iae9i9C9tEhBi-J08=@protonmail.com>
Message-ID: <Xsi9CoKNke0GSyjofVY0zpaqYutp6PPsilglleefty33g9Hlq2Vc3W-Bu5dAbo_Y_T04v6UWSDfIkvDdMM2anRxj4MfUwZmNzgFaFG31sqM=@protonmail.com>

Patch attached that should fix this issue.  Root cause: when I added the with-operand-accumulation forms for opstack safety (to fix the stack inconsistency bug reported in #69 [0]), I had incorrect types specified in some of the p2-ash code paths.  The form (ash 1343225879 (- 1)) also was not being compiled as a constant, and took a code path to actually calculate the shift based on the -1 constant.  In the patch attached I:

  - Added a constant folding case if arg2 was detected as a constant (but wasn't a literal integer, such as (- 1) )
  - Fixed all with-operand-accumulation forms to have the correct types
  - Added test cases that exercise all code paths of p2-ash

Patch is applied againt: https://github.com/armedbear/abcl
Latest master (3a54c91f3a0cbb71ae8d161acadecf118a65404c).

Please let me know if there is any more troubles,

-Mark

[0] https://github.com/armedbear/abcl/issues/69

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, December 15, 2019 6:12 PM, somewhat-functional-programmer <somewhat-functional-programmer at protonmail.com> wrote:

> Thank you for sending in this form -- I apologize - I am certain that this was introduced by my patch earlier this year to fix a couple of stack inconsistency bugs[0] -- a result of my modification to the p2-ash function.
>
> An minimal form that reproduces this bug:
> (let ((fn
> (compile
> nil
> '(lambda ()
> (ash 1343225879 (- 1))))))
> (funcall fn))
>
> In this particular case, (ash 1343225879 (- 1)) should compile to a constant, but doesn't, and the particular Java verification error stems from trying to load and store the -1 constant using aload/astore* instead of iload*. I have a local fix for this, and am also generating test cases with different types specified to exercise all possible code paths in p2-ash (such as):
> (the fixnum (ash (the fixnum x) 2))
>
> Sorry for the trouble! And again, thanks for sending this in, especially something so small and reproducible.
>
> I hope to be able to contribute more to ABCL this year if it makes sense, but at the very least can help fix this problem I introduced, I should be able to send out a patch tonight or at least very soon,
>
> -Mark
>
> [0] https://mailman.common-lisp.net/pipermail/armedbear-devel/2019-May/003977.html
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Saturday, December 14, 2019 9:43 AM, Eric Marsden eric.marsden at free.fr wrote:
>
> > Hi,
> > Compiling the loading the code below (a simplified extract of SBCL's
> > codebase, found attempting to crossbuild SBCL with ABCL) results in a
> > VerifyError, possibly related to the implementation of PROGN. Using
> > 1.6.1-dev-svn-15217.
> > java.lang.VerifyError: (class: org/armedbear/lisp/foo_1, method: execute signature: (Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Expecting to find object/array on stack
> > at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> > at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3137)
> > at java.base/java.lang.Class.getConstructor0(Class.java:3342)
> > at java.base/java.lang.Class.newInstance(Class.java:556)
> > at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130)
> > at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165)
> > at org.armedbear.lisp.LispThread.execute(LispThread.java:832)
> > at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582)
> > at org.armedbear.lisp.Lisp.eval(Lisp.java:540)
> > at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577)
> > at org.armedbear.lisp.Lisp.eval(Lisp.java:540)
> > at org.armedbear.lisp.Lisp.progn(Lisp.java:709)
> > at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:273)
> > at org.armedbear.lisp.Lisp.eval(Lisp.java:530)
> > at org.armedbear.lisp.Load.faslLoadStream(Load.java:667)
> > at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457)
> >
> > (in-package :cl-user)
> > (progn
> > (defvarsxhash-crosscheck nil)
> > (defun sxhash (x)
> > (let ((answer (if (string= x "NIL") (ash 1343225879 (- 1)))))
> > (push (cons x answer)sxhash-crosscheck)
> > answer)))
> > -- Eric Marsden https://risk-engineering.org/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-ash-and-compile-constant.patch
Type: text/x-patch
Size: 12641 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20191218/b429fb0d/attachment.bin>

From eric.marsden at free.fr  Wed Dec 18 14:00:30 2019
From: eric.marsden at free.fr (Eric Marsden)
Date: Wed, 18 Dec 2019 15:00:30 +0100
Subject: java.lang.VerifyError with PROGN
In-Reply-To: <Xsi9CoKNke0GSyjofVY0zpaqYutp6PPsilglleefty33g9Hlq2Vc3W-Bu5dAbo_Y_T04v6UWSDfIkvDdMM2anRxj4MfUwZmNzgFaFG31sqM=@protonmail.com>
References: <fc5e598e-b35a-da8f-4993-5f56319152b2@free.fr>
 <s1S3Ow4aRfmNgjJyRrt3_Jqs52FF2tM4MVrNXcFgaPMeWDgo4N7WW_nLCWhocPEXwxEJhCjNHD-T0xVSsvXQICaAx8iae9i9C9tEhBi-J08=@protonmail.com>
 <Xsi9CoKNke0GSyjofVY0zpaqYutp6PPsilglleefty33g9Hlq2Vc3W-Bu5dAbo_Y_T04v6UWSDfIkvDdMM2anRxj4MfUwZmNzgFaFG31sqM=@protonmail.com>
Message-ID: <f5ea99c5-0917-0166-744a-34a846b3feed@free.fr>

On 18/12/2019 02:17, somewhat-functional-programmer wrote:
> Patch attached that should fix this issue.  Root cause: when I added the with-operand-accumulation forms for opstack safety (to fix the stack inconsistency bug reported in #69 [0]), I had incorrect types specified in some of the p2-ash code paths.  The form (ash 1343225879 (- 1)) also was not being compiled as a constant, and took a code path to actually calculate the shift based on the -1 constant.
Thanks, I can confirm that this fixes the problem, and in fact with this 
patch ABCL can build current SBCL (tested on Linux/AMD64).

Eric




From somewhat-functional-programmer at protonmail.com  Wed Dec 18 23:29:33 2019
From: somewhat-functional-programmer at protonmail.com (somewhat-functional-programmer)
Date: Wed, 18 Dec 2019 23:29:33 +0000
Subject: java.lang.VerifyError with PROGN
In-Reply-To: <f5ea99c5-0917-0166-744a-34a846b3feed@free.fr>
References: <fc5e598e-b35a-da8f-4993-5f56319152b2@free.fr>
 <s1S3Ow4aRfmNgjJyRrt3_Jqs52FF2tM4MVrNXcFgaPMeWDgo4N7WW_nLCWhocPEXwxEJhCjNHD-T0xVSsvXQICaAx8iae9i9C9tEhBi-J08=@protonmail.com>
 <Xsi9CoKNke0GSyjofVY0zpaqYutp6PPsilglleefty33g9Hlq2Vc3W-Bu5dAbo_Y_T04v6UWSDfIkvDdMM2anRxj4MfUwZmNzgFaFG31sqM=@protonmail.com>
 <f5ea99c5-0917-0166-744a-34a846b3feed@free.fr>
Message-ID: <nzVU7InNOgKUJ1O_9EO8SFr9xbwySV4W_-TXoFfRWsNsm0SvVpbjxRvvLsoKBM1xp-TgsNHsVQBtIZBLliIHMMadSaCRhUKQOm1TaThwXJY=@protonmail.com>

Glad to hear it, I appreciate you trying it again.  I'll try to go through the building of SBCL myself too -- it's really a blessing to have these types of existing resources already available to help test (the ansi-test suite is also fantastic).

Again, sorry for the trouble,

-Mark

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, December 18, 2019 2:00 PM, Eric Marsden <eric.marsden at free.fr> wrote:

> On 18/12/2019 02:17, somewhat-functional-programmer wrote:
>
> > Patch attached that should fix this issue. Root cause: when I added the with-operand-accumulation forms for opstack safety (to fix the stack inconsistency bug reported in #69 [0]), I had incorrect types specified in some of the p2-ash code paths. The form (ash 1343225879 (- 1)) also was not being compiled as a constant, and took a code path to actually calculate the shift based on the -1 constant.
>
> Thanks, I can confirm that this fixes the problem, and in fact with this
> patch ABCL can build current SBCL (tested on Linux/AMD64).
>
> Eric




From evenson at panix.com  Thu Dec 19 11:19:59 2019
From: evenson at panix.com (Mark Evenson)
Date: Thu, 19 Dec 2019 12:19:59 +0100
Subject: java.lang.VerifyError with PROGN
In-Reply-To: <nzVU7InNOgKUJ1O_9EO8SFr9xbwySV4W_-TXoFfRWsNsm0SvVpbjxRvvLsoKBM1xp-TgsNHsVQBtIZBLliIHMMadSaCRhUKQOm1TaThwXJY=@protonmail.com>
References: <fc5e598e-b35a-da8f-4993-5f56319152b2@free.fr>
 <s1S3Ow4aRfmNgjJyRrt3_Jqs52FF2tM4MVrNXcFgaPMeWDgo4N7WW_nLCWhocPEXwxEJhCjNHD-T0xVSsvXQICaAx8iae9i9C9tEhBi-J08=@protonmail.com>
 <Xsi9CoKNke0GSyjofVY0zpaqYutp6PPsilglleefty33g9Hlq2Vc3W-Bu5dAbo_Y_T04v6UWSDfIkvDdMM2anRxj4MfUwZmNzgFaFG31sqM=@protonmail.com>
 <f5ea99c5-0917-0166-744a-34a846b3feed@free.fr>
 <nzVU7InNOgKUJ1O_9EO8SFr9xbwySV4W_-TXoFfRWsNsm0SvVpbjxRvvLsoKBM1xp-TgsNHsVQBtIZBLliIHMMadSaCRhUKQOm1TaThwXJY=@protonmail.com>
Message-ID: <8B7FD89E-769B-4643-8EDF-31A7FDEADB34@panix.com>



> On Dec 19, 2019, at 00:29, somewhat-functional-programmer <somewhat-functional-programmer at protonmail.com> wrote:
> 
> Glad to hear it, I appreciate you trying it again.  I'll try to go through the building of SBCL myself too -- it's really a blessing to have these types of existing resources already available to help test (the ansi-test suite is also fantastic).

Somehow, I missed receiving Mark’s patch for yesterday for reasons that I can’t explain.  

Fortunately, I did receive Eric’s confirmation that Mark’s patch works for him and was able to retrieve the patch from the mailing list archives.  

[I have now applied the patch to ABCL][1].  

This will be part of abcl-1.6.1, which I intend to release over the holidays.

Eric:  Thanks again for the concise test case from hosting the SBCL compilation via ABCL.

Mark:  Thank you for the fix, and especially the use of PROVE tests.

[1]: https://github.com/armedbear/abcl/commit/bffb8433987453b9574519b80a7fa66090a1eece

From somewhat-functional-programmer at protonmail.com  Thu Dec 19 22:21:25 2019
From: somewhat-functional-programmer at protonmail.com (somewhat-functional-programmer)
Date: Thu, 19 Dec 2019 22:21:25 +0000
Subject: java.lang.VerifyError with PROGN
In-Reply-To: <8B7FD89E-769B-4643-8EDF-31A7FDEADB34@panix.com>
References: <fc5e598e-b35a-da8f-4993-5f56319152b2@free.fr>
 <s1S3Ow4aRfmNgjJyRrt3_Jqs52FF2tM4MVrNXcFgaPMeWDgo4N7WW_nLCWhocPEXwxEJhCjNHD-T0xVSsvXQICaAx8iae9i9C9tEhBi-J08=@protonmail.com>
 <Xsi9CoKNke0GSyjofVY0zpaqYutp6PPsilglleefty33g9Hlq2Vc3W-Bu5dAbo_Y_T04v6UWSDfIkvDdMM2anRxj4MfUwZmNzgFaFG31sqM=@protonmail.com>
 <f5ea99c5-0917-0166-744a-34a846b3feed@free.fr>
 <nzVU7InNOgKUJ1O_9EO8SFr9xbwySV4W_-TXoFfRWsNsm0SvVpbjxRvvLsoKBM1xp-TgsNHsVQBtIZBLliIHMMadSaCRhUKQOm1TaThwXJY=@protonmail.com>
 <8B7FD89E-769B-4643-8EDF-31A7FDEADB34@panix.com>
Message-ID: <dEYlHbr7tmsnopmg5nxn-6QUAiW4f9JBK025mMnJ6jttsUwfI9Aey-V5LWUGN1RHJZdXWBUUr0ugjvj6GXn3Bk9jBHhH4SBZtwB-dzCKX-0=@protonmail.com>

Thanks!  BTW I built SBCL (latest github master) today too using the following command (Linux,X86_64, sbcl clone directory):

sh make.sh --xc-host='<path-to-abcl>/abcl --noinit'

-Mark

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, December 19, 2019 11:19 AM, Mark Evenson <evenson at panix.com> wrote:

> > On Dec 19, 2019, at 00:29, somewhat-functional-programmer somewhat-functional-programmer at protonmail.com wrote:
> > Glad to hear it, I appreciate you trying it again. I'll try to go through the building of SBCL myself too -- it's really a blessing to have these types of existing resources already available to help test (the ansi-test suite is also fantastic).
>
> Somehow, I missed receiving Mark’s patch for yesterday for reasons that I can’t explain.
>
> Fortunately, I did receive Eric’s confirmation that Mark’s patch works for him and was able to retrieve the patch from the mailing list archives.
>
> [I have now applied the patch to ABCL][1].
>
> This will be part of abcl-1.6.1, which I intend to release over the holidays.
>
> Eric: Thanks again for the concise test case from hosting the SBCL compilation via ABCL.
>
> Mark: Thank you for the fix, and especially the use of PROVE tests.
>
> [1]: https://github.com/armedbear/abcl/commit/bffb8433987453b9574519b80a7fa66090a1eece