Re: [armedbear-devel] [armedbear-cvs] r12620 - trunk/abcl/src/org/armedbear/lisp
Hi Mark, On Fri, Apr 16, 2010 at 3:41 PM, Mark Evenson <mevenson@common-lisp.net> wrote:
Author: mevenson Date: Fri Apr 16 09:41:21 2010 New Revision: 12620
Log: Use interpreted form in a FASL if compliation fails.
Although I think this is a great fallback, it seems to be automatically selected right now. I'm affraid of the negative side effects of that scenario: people will not notice that their code wasn't compiled, but is now interpreted instead. The ultimate side effect could be that we don't get any reports anymore regarding brokenness of our compiler. In my eyes, there are 2 ways forward with this: 1) We undo this option; this leaves users at a loss when compilation fails; they'll need to use the entire file uncompiled. 2) We make the fallback a selectable restart; this way, compilation gets interrupted, the user is aware and we're much more likely to receive our feedback. But the user isn't restricted to using a fully interpreted file anymore. Quite possibly, you can read my preference through the lines already: I think option (2) is *really* nice. What's your opinion on the matter? Bye, Erik.
Erik Huelsmann <ehuels@gmail.com> writes:
Hi Mark,
On Fri, Apr 16, 2010 at 3:41 PM, Mark Evenson <mevenson@common-lisp.net> wrote:
Author: mevenson Date: Fri Apr 16 09:41:21 2010 New Revision: 12620
Log: Use interpreted form in a FASL if compliation fails.
Although I think this is a great fallback, it seems to be automatically selected right now. I'm affraid of the negative side effects of that scenario: people will not notice that their code wasn't compiled, but is now interpreted instead. The ultimate side effect could be that we don't get any reports anymore regarding brokenness of our compiler.
In my eyes, there are 2 ways forward with this: 1) We undo this option; this leaves users at a loss when compilation fails; they'll need to use the entire file uncompiled. 2) We make the fallback a selectable restart; this way, compilation gets interrupted, the user is aware and we're much more likely to receive our feedback. But the user isn't restricted to using a fully interpreted file anymore.
Quite possibly, you can read my preference through the lines already: I think option (2) is *really* nice.
What's your opinion on the matter?
For a semi-outsider: When does compilation fail where interpretation would succeed? -T.
Hi Tobias, On Fri, Apr 30, 2010 at 3:20 PM, Tobias C. Rittweiler <tcr@freebits.de> wrote:
In my eyes, there are 2 ways forward with this: 1) We undo this option; this leaves users at a loss when compilation fails; they'll need to use the entire file uncompiled. 2) We make the fallback a selectable restart; this way, compilation gets interrupted, the user is aware and we're much more likely to receive our feedback. But the user isn't restricted to using a fully interpreted file anymore.
Quite possibly, you can read my preference through the lines already: I think option (2) is *really* nice.
What's your opinion on the matter?
For a semi-outsider: When does compilation fail where interpretation would succeed?
In case of compiler bugs. It's relatively difficult to generate correct Java byte code: in the ticket #89 example: a statement left a value on the stack which wasn't going to be used ever after. The code would have run correctly in all cases, however, the byte code verifier found that another code path left fewer arguments on the stack before jumping to a common follow-up path. The excess value on the stack would have been cleared upon function-return. The same code would be interpreted without problems. I hope that answers your question. If not, don't hesitate to ask! Bye, Erik.
Erik Huelsmann <ehuels@gmail.com> writes:
For a semi-outsider: When does compilation fail where interpretation would succeed?
In case of compiler bugs. It's relatively difficult to generate correct Java byte code: in the ticket #89 example: a statement left a value on the stack which wasn't going to be used ever after. The code would have run correctly in all cases, however, the byte code verifier found that another code path left fewer arguments on the stack before jumping to a common follow-up path. The excess value on the stack would have been cleared upon function-return.
The same code would be interpreted without problems.
I hope that answers your question. If not, don't hesitate to ask!
I think some kind of random code generator is / was part of ansi-tests. At least, P.F.Dietz wrote one. It was used to shake out compiler bugs in an early stage of SBCL. Have you tried that? -T.
On 4/30/10 2:48 PM, Erik Huelsmann wrote:
On Fri, Apr 16, 2010 at 3:41 PM, Mark Evenson<mevenson@common-lisp.net> wrote:
Author: mevenson Date: Fri Apr 16 09:41:21 2010 New Revision: 12620
Log: Use interpreted form in a FASL if compliation fails.
Although I think this is a great fallback, it seems to be automatically selected right now. I'm affraid of the negative side effects of that scenario: people will not notice that their code wasn't compiled, but is now interpreted instead. The ultimate side effect could be that we don't get any reports anymore regarding brokenness of our compiler.
In my eyes, there are 2 ways forward with this: 1) We undo this option; this leaves users at a loss when compilation fails; they'll need to use the entire file uncompiled. 2) We make the fallback a selectable restart; this way, compilation gets interrupted, the user is aware and we're much more likely to receive our feedback. But the user isn't restricted to using a fully interpreted file anymore.
Quite possibly, you can read my preference through the lines already: I think option (2) is *really* nice.
Certainly the restart seems the very much Lispy way to go, as it informs the user while fixing the problem. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
participants (3)
-
Erik Huelsmann -
Mark Evenson -
Tobias C. Rittweiler