2. Registration and configuration runs very slooooooow.
Before I had just enough time to drink my coffee.
Now, I can execute the following procedure:
run to the local store-buy coffee-run back-drink it
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: email@example.com > To: firstname.lastname@example.org > CC: email@example.com > > On Mon, May 18, 2009 at 10:13 AM, Alessio Stalla > <firstname.lastname@example.org> wrote: > > On Mon, May 18, 2009 at 9:12 AM, Alessio Stalla <email@example.com> wrote: > >> On Mon, May 18, 2009 at 7:15 AM, Peter Tsenter <firstname.lastname@example.org> 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. Check it out.