Tucker and Henry, I think I've been a step behind you guys figuring out what was happening, but I've been learning as I go. FWIW, there are a couple tools I've been using that may be useful in the future:
- the JDEE (emacs package) puts a reasonable veneer above the jdb debugger. Not unlike using gdb in emacs. Setting breakpoints seems to be trickier than it should be (I found I had to use jdb commands to do it), but now that I know how, it's not that tough. Anyway, was able to run the Compiler, single step, traceback, up/down stack, inspect objects. - Running the compiler with -SS (save state) creates a cadre of text files useful in debugging the script compiler. Gives the set of script input text, the AST trees before and after transformations. - Don On Jan 28, 2011, at 6:49 AM, P T Withington wrote: > I'm working on a fix by completing the implementation of sc/Transformer which > will re-order script classes to emit them in dependency order. I have to be > careful because the LFC can't be reordered (at least not simply, because it > is carefully ordered by hand to bootstrap the runtime compiler and debugger > support). > > On 2011-01-27, at 21:15, Henry Minsky wrote: > >> I found that if I (manually) move the <mixin> and <interface> declarations >> in the lzo file to >> come before the <script> element, that the compiled app then runs because >> the script output has the Mixin.make emitted before the Class.make's. >> >> So in compiler/MixinCompiler#compile method I guess it calls >> ClassCompiler#compile, which calls classModel.compile(), and that emits the >> Mixin.make to script >> >> >> On Thu, Jan 27, 2011 at 11:14 AM, P T Withington <[email protected]> wrote: >> >>> I have a change that is very close to solving the LZO problem, but is still >>> failing the lzo regression test in `ant lztest`. I could use some help, >>> because I have banged my head against this for 2 days with no progress. >>> >>> The symptom is: >>> >>>> [exec] js: "test/lztest/lztest-lzo-main.js", line 547: uncaught >>> JavaScript runtime exception: ReferenceError: "$lzc$class_lzomixin" is not >>> defined. >>> >>> There is an interstitial class being created that implements the `lzomixin` >>> class. I've put in print statements and can see that the compiler is >>> compiling the `lzomixin` class before the interstitial class, yet in the >>> resulting .js file, it is textually later!?!?! and as a result, bombs >>> because it is not defined before used. >>> >>> I'm pulling my hair out trying to figure out how the stuff could end up in >>> the output file in a different order than how the Schema compiler writes it. >>> I fooled myself thinking that the script compiler re-ordered classes when >>> it wrote them, but I can't find any such code anywhere. >>> >>> Any chance you guys could take a look at this change and see if you can >>> track it down? >>> >>> Change ptw-20110127-5Th by [email protected] on 2011-01-27 11:03:43 EST >>> in /Users/ptw/OpenLaszlo/trunk-3 >>> for http://svn.openlaszlo.org/openlaszlo/trunk >>> >>> Summary: Only emit mixins as interfaces when linking >>> >>> Bugs Fixed: LPP-9691 Child nodes not created for instance classes when >>> created in LZO >>> >>> Technical Reviewer: [email protected] (pending) >>> QA Reviewer: [email protected] (pending) >>> >>> Details: >>> >>> Mixins eventually have to be written out as 'interfaces' so that >>> all the interstitials that implement them can refer to them in >>> their 'implements' clause, but we can't have more than one copy, >>> so we can't write them into an LZO. Instead, we have to notice >>> when we are linking and write them out then. >>> >>> Tests: >>> ant lztest >>> >>> Files: >>> M WEB-INF/lps/server/src/org/openlaszlo/compiler/ClassModel.java >>> >>> Changeset: >>> http://svn.openlaszlo.org/openlaszlo/patches/ptw-20110127-5Th.tar >>> >> >> >> >> -- >> Henry Minsky >> Software Architect >> [email protected] > -- Don Anderson Java/C/C++, Berkeley DB, systems consultant voice: 617-306-2057 email: [email protected] www: http://www.ddanderson.com blog: http://libdb.wordpress.com
