On Jan 28, 2011, at 10:47 AM, P T Withington wrote: > 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?
Yeah, I think I've tried a couple times before and been turned back too. > What emacs are you using? I use Aquamacs because it comes bundled with all > the packages that I want. I'm using this one http://emacsformacosx.com/ . With that, I needed to add jdee and cedet (which jdee needs). To run jdb, I give it a huge command line: jdb -Xmx1000000000 -DLPS_HOME=/Users/clients/laszlo/src/svn/openlaszlo/trunk-c -classpath .......(that's the really big part)...... -sourcepath/Users/clients/laszlo/src/svn/openlaszlo/trunk-c/WEB-INF/lps/server/src/ org.openlaszlo.compiler.Main --runtime=dhtml /Users/clients/laszlo/src/svn/openlaszlo/trunk-c/test/lztest/lztest-lzo-main.lzx And some trial/error with breakpoints, revealed these ways to do it, at the jdb prompt: stop in org.openlaszlo.compiler.Main.main stop at org.openlaszlo.compiler.ClassModel:959 (setting a breakpoint by pushing the breakpoint button doesn't seem reliable). So it's not perfect, which I think means I didn't configure something right. But it's great to see the source code pop up when it stops at a breakpoint, or after next. > 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. Yes, a cool feature. Nice to have tests for it. Once I have some basic functionality working, I'll add some tests for the lzo/with-this intersection and look at documenting what's there. - Don > > 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 >> >> >> >> >> > -- 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
