Good to know. I guess I should re-try using the jdee package. I tried it long ago and found it unsatisfactory. But it sounds like it has improved since then? I guess way back when, my major complaint was that it was really hard to find all the dependencies and make sure I had all the right emacs &c. libraries installed. Perhaps that is better now too?
What emacs are you using? I use Aquamacs because it comes bundled with all the packages that I want. And finally, a warning: Your main project will surely intersect with the LZO compiler, since LZO's are trying to do something very similar: write out enough schema that the schema compiler can restore its state to where it would have been if the original source were being compiled, when you do go to link. So we will need to be very sure that we don't cause a regression in LZO compiling. Henry has built up (and I keep adding to) a nice set of regression tests at test/lztest/. Look for things with the workd `lzo`. They could use some documenting, to describe better what each test is trying to verify, but they are at least a baseline that we can't stray from. On 2011-01-28, at 08:52, Donald Anderson wrote: > 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 > > > > >
