I've re-tested and happy to report that everything works.
But I'd like to make a few points.
1. Explicit (manual) registration of AbclScriptEngineFactory requires one more statement:
2. Registration and configuration runs very slooooooow.
Before I had just enough time to drink my coffee.
OK, it took 94236 msec. For comparison, 42 interpretation - 875, compilation - 2485, evaluation - 31 and 0.
> Date: Mon, 18 May 2009 21:41:34 +0200
> Subject: Re: [j-devel] JSR223Example.java got broken
> From:
[hidden email]> To:
[hidden email]> CC:
[hidden email]>
> On Mon, May 18, 2009 at 10:13 AM, Alessio Stalla
> <
[hidden email]> wrote:
> > On Mon, May 18, 2009 at 9:12 AM, Alessio Stalla <
[hidden email]> wrote:
> >> On Mon, May 18, 2009 at 7:15 AM, Peter Tsenter <
[hidden email]> wrote:
> >>> Statement
> >>>
> >>> ((Invocable) lispEngine).invokeFunction("hello", "world");
> >>>
> >>> invokes abcl interactive debugger with a message
> >>>
> >>>
> >>> Debugger invoked on condition of type UNBOUND-VARIABLE:
> >>> The variable ABCL-SCRIPT-USER::SOMEVARIABLE is unbound.
> >>>
> >>> I don't rememeber how far back it used to work.
> >>
> >> Thanks for the report, I'll investigate it this evening. I haven't run
> >> the example in a while, and even if I have some simple unit tests to
> >> check the AbclScriptEngine, these tests are far from complete and the
> >> example might do something which is not covered by them.
> >>
> >
> > I've given a quick look at the AbclScriptEngine on Trac (I don't have
> > my local working copy available now) and I've understood the problem.
> >
> > With my last commit I changed how the Lisp code is executed in a
> > JSR-223 context. Before it went like this:
> >
> > The code string was parsed with read-from-string (with *package* bound
> > to :abcl-script-user), the resulting Lisp code was enclosed in a (let
> > ...) form with all the bindings passed through the ScriptContext, and
> > finally eval'ed.
> >
> > This worked fine with snippets of code like those in the example and
> > in my unit tests, but hadn't the correct behavior when loading a Lisp
> > file, since the built-in load function behaves differently - it reads
> > and evaluates a form at a time, so that e.g. in-package forms are
> > allowed to change the current package and affect the reading of
> > subsequent forms.
> >
> > So now I changed it to use a modified version of load that returns the
> > value of the last form loaded. This solves the problem above. However,
> > the let-form trick for establishing a set of bindings does not work
> > anymore, since load always runs in a null lexical environment. So I
> > also made bindings declared with ScriptContext special, so they can be
> > seen by load. However, I forgot to change how function invocation
> > works - it should now re-establish bindings, since those are now
> > special and thus are not resolved at function declaration time but at
> > function call time. It's not a hard thing to do, I should be able to
> > fix it before tomorrow.
>
> Ok, I have hopefully fixed it. For details, here's the commit comment:
>
> "
> Fixed function evaluation using invokeFunction. It was broken since last
> commit on JSR-223. Now invokeFunction uses the same "eval-in-script-context"
> macro that is used to evaluate interpreted and compiled code in the right
> environment, including special variables from the ScriptContext.
> In passing, the invokeFunction() method has also been fixed so that
> javaInstance() is called on its return value, like it happens in all other
> kinds of Lisp calls from Java.
> "
>
> I add that the javaInstance() thing means that
> scriptEngine.evalFunction("random", 10) will return an Integer and not
> a Fixnum like it did before, which is conforming to how the rest of
> ABCL works in the general case.
>
> Cheers,
> Ale
Hotmail® has a new way to see what's up with your friends.
for externally facing server and web deployment.
