precompiler work (was Re: Mucking around with compilation)

Alan Ruttenberg alanruttenberg at gmail.com
Thu Nov 17 16:30:33 UTC 2016


I updated the pull request and the trac ticket to address the issues Mark
found.

Alan

On Thu, Nov 17, 2016 at 9:06 AM, Alan Ruttenberg <alanruttenberg at gmail.com>
wrote:

> Yup, compile time error. Unintended - thanks for catching that! I've fixed
> that in my source. Now if it can't find the class at compile time it will
> defer class lookup to runtime and not warn. I'll  look into the test
> failure issues.
> Best,
> Alan
>
> On Thu, Nov 17, 2016 at 6:13 AM, Alessio Stalla <alessiostalla at gmail.com>
> wrote:
>
>> Hi, by 1) won't compile you mean that compilation fails? The compiler
>> macro could simply revert to the unoptimized behavior in that case instead.
>>
>> On 17 November 2016 at 12:00, Mark Evenson <evenson at panix.com> wrote:
>>
>>>
>>>
>>> On 2016/11/4 05:39, Alan Ruttenberg wrote:
>>> > So I made a pass at doing this cleanly. Please check out the changes at
>>> >
>>> > https://github.com/alanruttenberg/abcl/commit/4e824ddd8f054e
>>> ee4d943d0fdbbfcd83c17b26d7
>>> >  (precompiler.lisp, optimize-java-call.lisp)
>>> > https://github.com/alanruttenberg/abcl/commit/b46c704b1460cc
>>> d75035c3f590cdc52fff29886e
>>> > (test-optimize-java-call.lisp)
>>> >
>>> > (second one has commit message with documentation)
>>> >
>>> > It would be good to get one of the folks who have worked on the
>>> compiler to
>>> > see if I've done anything wrong. ABCL builds fine with this and I
>>> didn't
>>> > see any changes in the abcl.lisp tests.
>>>
>>> Look into a mirror:  there's one of the folks "who have worked on the
>>> compiler".  Seriously, we don't really have such experience at the
>>> moment.  Alessio and Erik are probably the most knowledgeable.
>>>
>>> Unfortunately there are two problems with the current state Alan's work:
>>>
>>> 1) With *INHIBIT-JSS-OPTIMIZATION* as nil, JSS won't compile any
>>> reference to a Java class that it not present in the classpath at
>>> compile time. Previously this wasn't the behavior.
>>>
>>> 2) There are a slew of additional failures in the ANSI-TEST LAMBDA
>>> section, which indicates that we need to work through some wrinkles in
>>> the behavior of the patch.
>>>
>>> LAMBDA.1, LAMBDA.2, LAMBDA.3, LAMBDA.4, LAMBDA.5, LAMBDA.6, LAMBDA.7,
>>> LAMBDA.8, LAMBDA.9, LAMBDA.10, LAMBDA.21, LAMBDA.22, LAMBDA.54,
>>> LAMBDA.57, LAMBDA.63, LAMBDA.64
>>>
>>> Obviously we at least need to analyze/fix the problems with the LAMBDA
>>> form revealed by the ANSI-TEST suite, and I would really like to somehow
>>> have the previous behavior of JSS to somehow lazily reference Java
>>> callsites, but that is probably incompatible with optimization.
>>>
>>> I am tracking this issue as [420][]
>>> [420]: http://abcl.org/trac/ticket/420
>>>
>>> The [patch that I tested with][1] contains to small changes to Alan's
>>> work:
>>>
>>> 1. Export JSS:*INHIBIT-JSS-OPTIMIZATION*; have it default to T
>>> 2. Revbump the JSS ASDF definition.
>>>
>>> [1]: http://abcl.org/trac/attachment/ticket/420/beta-reduce-20161
>>> 117a.diff
>>>
>>>
>>> --
>>> "A screaming comes across the sky.  It has happened before, but there
>>> is nothing to compare to it now."
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20161117/09f2a775/attachment.html>


More information about the armedbear-devel mailing list