This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
RE: BRL with kawa 1.8.91
The main reason we went to kawa 1.8.91, was we thought less work would
be needed to make brl work, and that was the first version which would
compile a packrat parser for json. There were only a few minor changes
to our servlet needed with 1.8.91.
I am willing to try to use the newest version of kawa, do you have the
web.xml file used to run my example using tomcat?
I have also isolated my current problem to what I think is the
following:
This is the code generated by the brl page containing [(symbol->string
'b)] .
Look at the code line 11. At that point the function return value has
been returned by symbol->string, on the stack. Why the pop ?
Shouldn't the string returned from symbol->string be left on the stack
for the display?
5: getstatic #12; //Field Lit0:Ljava/lang/String;
8: invokestatic #18; //Method
kawa/lib/misc.symbol$To$String:(Ljava/lang/String;)Lgnu/lists/FString;
11: pop
12: getstatic #22; //Field Lit1:Lgnu/lists/UnescapedData;
15: getstatic #28; //Field
kawa/standard/Scheme.applyToArgs:Lgnu/kawa/
functions/ApplyToArgs;
18: getstatic #34; //Field
atInteractiveLevel$3.gnu$brl$progfun$instan
ce:Lgnu/brl/progfun;
21: getfield #40; //Field
gnu/brl/progfun.brl$Mncontext$Mnoutport:Lgn
u/mapping/Location;
24: invokevirtual #46; //Method
gnu/mapping/Location.get:()Ljava/lang/Obje
ct;
27: aload_0
28: invokevirtual #52; //Method
gnu/mapping/Procedure.apply2:(Ljava/lang/O
bject;Ljava/lang/Object;)Ljava/lang/Object;
31: invokestatic #58; //Method
kawa/lib/ports.display:(Ljava/lang/Object;
Ljava/lang/Object;)V
34: getstatic #62; //Field Lit2:Lgnu/lists/FString;
Dan Stanger
Eaton Vance Management
Two International Place
Boston, MA 02110
Mobile: 617 646 9682
Office: 617 672 8261
-----Original Message-----
From: Per Bothner [mailto:per@bothner.com]
Sent: Tuesday, May 12, 2009 1:14 PM
To: Dan Stanger
Cc: kawa@sources.redhat.com
Subject: Re: BRL with kawa 1.8.91
On 05/12/2009 07:53 AM, Dan Stanger wrote:
> My brl page now contains [(symbol->string 'b)] .
> Here is a partial backtrace after the call to atEvalLevel.lambda1$X
> (x.brl .
> [1] atEvalLevel.lambda1$X (x.brl:1)
> [2] atEvalLevel.apply (null)
> [3] gnu.mapping.CallContext.runUntilDone (CallContext.java:251)
> [4] gnu.mapping.CallContext.runUntilValue (CallContext.java:315)
> [5] gnu.expr.ModuleWithContext.applyN (ModuleWithContext.java:209)
>
> After 2 step up commands I am at:
> Step completed: "thread=main",
gnu.mapping.CallContext.runUntilValue(),
> line=31
> bci=30
>
> main[1] print vst
> vst = "[0, ]"
>
> Shouldn't vst contain [1,"b"] or something like that?
I don't know, since I don't know what is happening. Setting:
Compilation.debugPrintExpr = true;
and/or
Compilation.debugPrintFinalExpr = true;
will print (to the error port) the parsed expressions.
Setting:
ModuleExp.dumpZipPrefix = "kawa-zip-dump-";
will generate .zip files of the generated classes.
But this looks like the old "eval-based" implementation of BRL.
That implementation will be harder to debug, because it makes
a lot of eval calls. The BRL re-implemention that ships with
Kawa handles your example just fine, both as a standalone file:
kawa --brl -f x.brl
and in Tomcat.
I really and most strongly recommend that you spend as little
time as possible on the old eval-based implementation. Instead,
concentrate on bringing the new integrated implementation (the
one that is part of the Kawa code-base) up to your needs. That
will be easier in the long run - and possibly in the short run,
as I can help more easily. Having BRL be part of the Kawa
distribution (except perhaps for some optional add-on libraries)
will avoid the kind of incompatibilities we're seeing.
Or have you tried and given up on that? Perhaps you're concerned
about hard-to-fix incompatibilities between the old implementation
and the Kawa implementation? If so, I'd like to understand the
issues.
--
--Per Bothner
per@bothner.com http://per.bothner.com/