For future reference, there's a couple of tests that we ought to be doing before checkins, at a minimum
test/smoke/smokecheck.lzx and also ant lztest (although this only runs tests in rhino, it is easy to run, and a good sanity check) + I also usually run the Amazon demo (demos/amazon/amazon.lzx) and demos/lzpix/app.lzx, if I think I have done something which might affect the view system. If I have touched the components, I try to run examples/components/style_example.lzx and some others in that directory + If I have touched the data system, I run test/lfc/data/alldata.lzx On 9/25/07, Donald Anderson <[EMAIL PROTECTED]> wrote: > Yes, trunk is still broken, I am still working it, although this > looks like a different error. > Would it be helpful for everyone if I revert the trunk back to the > previous version > in the meantime? If so, I assume there's nothing fancy available in > svn, just > commit the old copy? > > I'm really sorry this has been so intrusive. > > - Don > > On Sep 25, 2007, at 4:06 AM, J Crowley wrote: > > > In case it's at all helpful: This is still broken for me as of the > > latest revision (updated one trunk and pulled down a fresh one), in > > OS X, for whatever it's worth. The build error I'm getting is: > > > > lzl: > > [echo] Compiling /Users/jcrowley/src/svn/openlaszlo/trunk-c/ > > lps/includes/lfc/LFCdhtml.js > > [java] Exception in thread "main" java.lang.AssertionError: > > unknown runtime dhtml > > [java] at org.openlaszlo.sc.CommonGenerator.setOptions > > (CommonGenerator.java:106) > > [java] at org.openlaszlo.sc.Compiler.compile(Compiler.java: > > 339) > > [java] at org.openlaszlo.sc.lzsc.compile(lzsc.java:110) > > [java] at org.openlaszlo.sc.lzsc.compile(lzsc.java:322) > > [java] at org.openlaszlo.sc.Main.main(Main.java:10) > > > > BUILD FAILED > > /Users/jcrowley/src/svn/openlaszlo/trunk-c/build.xml:506: The > > following error occurred while executing this line: > > /Users/jcrowley/src/svn/openlaszlo/trunk-c/WEB-INF/lps/lfc/ > > build.xml:122: The following error occurred while executing this line: > > /Users/jcrowley/src/svn/openlaszlo/trunk-c/WEB-INF/lps/lfc/ > > build.xml:79: Java returned: 1 > > > > On Sep 24, 2007, at 8:15 PM, Henry Minsky wrote: > > > >> The LZX preprocessor is supposed to keep track of <include>'ed > >> libraries and only include them once. Not impossible that it's > >> broken, > >> but I bet if you remove duplicated line that you won't see any > >> different output. > >> > >> On 9/24/07, Donald Anderson <[EMAIL PROTECTED]> wrote: > >>> I have no idea if this is relevant, but since I'm looking at > >>> names with 'basefocusview', I see that base/style.lzx has > >>> a repeated include line: > >>> > >>> <library> > >>> <include href="base/colors.lzx"/> > >>> <include href="base/basefocusview.lzx"/> > >>> <include href="base/basefocusview.lzx"/> > >>> <include href="base/componentmanager.lzx"/> > >>> > >>> > >>> On Sep 24, 2007, at 6:42 PM, Henry Minsky wrote: > >>> > >>>> I'm wondering if a unique id identifier for a constraint > >>>> function is > >>>> getting re-used, thus > >>>> bashing some constraint function with another one... > >>>> > >>>> On 9/24/07, P T Withington <[EMAIL PROTECTED]> wrote: > >>>>> Well Henry is right, that looks like a constraint dependency > >>>>> computation that is getting messed up. This is done at the end of > >>>>> translateFunctionInternal, you'll see that it visits the > >>>>> statements > >>>>> in the function to compute the dependencies. > >>>>> > >>>>> Don't yet see how your changes could affect that though... > >>>>> > >>>>> On 2007-09-24, at 17:22 EDT, Donald Anderson wrote: > >>>>> > >>>>>> Thanks Tucker - Finally, I'm seeing a difference, > >>>>>> > >>>>>> 118011c118011 > >>>>>> < function2 () (r:1='this', r:2='_root') > >>>>>> --- > >>>>>>> function2 () (r:1='this') > >>>>>> 118014,118018c118014 > >>>>>> < push 'offset', 'classroot' > >>>>>> < getVariable > >>>>>> < push 'width', r:this, 'width', 'parent' > >>>>>> < getVariable > >>>>>> < push 6 > >>>>>> --- > >>>>>>> push 0 > >>>>>> > >>>>>> I'm on it.... > >>>>>> > >>>>>> - Don > >>>>>> > >>>>>> On Sep 24, 2007, at 3:38 PM, P T Withington wrote: > >>>>>> > >>>>>>> Don, if you have access to Windows and Mac, you should try > >>>>>>> fetching the test app with wget as follows: > >>>>>>> > >>>>>>> wget 'http://127.0.0.1:8080/trunk/.../whatever.lzx? > >>>>>>> lzt=swf&debug=true&lzr=swf7&lzbacktrace=false' > >>>>>>> > >>>>>>> lzt=swf will cause the actual swf file to be delivered. > >>>>>>> lzr=swf7 > >>>>>>> means compile for swf7 (so you can change that to swf8 if > >>>>>>> that is > >>>>>>> where the bug is), debug=true, backtrace=false should be self- > >>>>>>> explanatory. Note you have to quote the URL to escape the &'s > >>>>>>> from the shell. > >>>>>>> > >>>>>>> If you can fetch the file from your Mac server and from your > >>>>>>> Windows server, you should be able to compare the resulting swfs > >>>>>>> to see if they are the same or not. > >>>>>>> > >>>>>>> On 2007-09-24, at 15:02 EDT, Donald Anderson wrote: > >>>>>>> > >>>>>>>> Benjamin, > >>>>>>>> > >>>>>>>> On my OSX setup (which does not exhibit the error), I have: > >>>>>>>> > >>>>>>>> [echo] Ant project:lps on Mac OS X 10.4.10 ppc > >>>>>>>> [echo] ant.home: /usr/local/src/ant/apache-ant-1.6.5 > >>>>>>>> [echo] JRE: 1.4.2_12 (Apple Computer, Inc.) > >>>>>>>> [echo] JAVA_HOME: /System/Library/Frameworks/ > >>>>>>>> JavaVM.framework/Versions/1.4.2/home/ > >>>>>>>> [echo] LPS Version: 4.1.x Latest > >>>>>>>> [echo] LPS_HOME: /Users/clients/laszlo/src/svn/ > >>>>>>>> openlaszlo/trunk > >>>>>>>> [echo] LZ_VENDOR_ROOT: /Users/clients/laszlo/src/svn/ > >>>>>>>> vendor > >>>>>>>> [echo] LZ_TOOLS_ROOT: /Users/clients/laszlo/src/svn/ > >>>>>>>> tools/trunk > >>>>>>>> [echo] LZ_INSTALLS_ROOT: /Users/dda/laszlo/lib > >>>>>>>> [echo] server.home: /Users/dda/laszlo/lib/jakarta- > >>>>>>>> tomcat-5.0.30 > >>>>>>>> [echo] lps.branch: trunk > >>>>>>>> [echo] platform: is macosx > >>>>>>>> [echo] Skipping prefetch is true > >>>>>>>> [echo] Skipping wrappertest is ${skip.wrappertest} > >>>>>>>> [echo] Skipping doc is ${skip.doc} > >>>>>>>> > >>>>>>>> I'm looking into comparing the output binaries now (since I > >>>>>>>> have > >>>>>>>> a Windows box that does > >>>>>>>> have the error) -- the ones I've looked at so far in lfc > >>>>>>>> appear to be the same (modulo UUID variable names, which I'm > >>>>>>>> dealing with now). > >>>>>>>> > >>>>>>>> - Don > >>>>>>>> > >>>>>>>> On Sep 24, 2007, at 2:24 PM, Benjamin Shine wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> keywords: "supposed to be". > >>>>>>>>> > >>>>>>>>> Different versions of java have different versions of standard > >>>>>>>>> libraries, so we can see different behaviors in binaries built > >>>>>>>>> on different machines (with different java versions) and > >>>>>>>>> binaries executing on different machines (with different java > >>>>>>>>> versions), because we use some libraries at platform-compile- > >>>>>>>>> time and other libraries at app-compile-time. > >>>>>>>>> > >>>>>>>>> Don's new to the party, so he might have a slightly different > >>>>>>>>> setup that we haven't figured out yet. > >>>>>>>>> > >>>>>>>>> Don, when you start a compile, what does the init task echo? > >>>>>>>>> Something like: > >>>>>>>>> slim:~/src/svn/openlaszlo/trunk ben$ ant build > >>>>>>>>> Buildfile: build.xml > >>>>>>>>> > >>>>>>>>> build-opt: > >>>>>>>>> > >>>>>>>>> init: > >>>>>>>>> [echo] Ant project:lps on Mac OS X 10.4.10 i386 > >>>>>>>>> [echo] ant.home: /Users/ben/lib/apache-ant-1.6.5 > >>>>>>>>> [echo] JRE: 1.5.0_07 (Apple Computer, Inc.) > >>>>>>>>> [echo] JAVA_HOME: /Library/Java/Home > >>>>>>>>> [echo] LPS Version: 4.1.x Latest > >>>>>>>>> [echo] LPS_HOME: /Users/ben/src/svn/openlaszlo/trunk > >>>>>>>>> [echo] LZ_VENDOR_ROOT: /Users/ben/src/svn/vendor > >>>>>>>>> [echo] LZ_TOOLS_ROOT: /Users/ben/src/svn/tools/trunk > >>>>>>>>> [echo] LZ_INSTALLS_ROOT: /Users/ben/lib > >>>>>>>>> [echo] server.home: /Users/ben/lib/jakarta- > >>>>>>>>> tomcat-5.0.30 > >>>>>>>>> [echo] lps.branch: trunk > >>>>>>>>> [echo] platform: is macosx > >>>>>>>>> [echo] Skipping prefetch is true > >>>>>>>>> [echo] Skipping wrappertest is ${skip.wrappertest} > >>>>>>>>> [echo] Skipping doc is ${skip.doc} > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Sep 24, 2007, at 9:53 AM, P T Withington wrote: > >>>>>>>>> > >>>>>>>>>> This is strange. I think I would start by wget-ing the > >>>>>>>>>> SWF on > >>>>>>>>>> each platform and use flash to compare the binaries. I can't > >>>>>>>>>> guess how the compiler could work differently on the two > >>>>>>>>>> platforms -- Java is supposed to be portable, right? > >>>>>>>>>> > >>>>>>>>>> On Sep 24, 2007, at 11:22 AM, "Henry Minsky" > >>>>>>>>>> <[EMAIL PROTECTED]> wrote: > >>>>>>>>>> > >>>>>>>>>>> The bug looks a little to me like constraint functions are > >>>>>>>>>>> broken; the debugger > >>>>>>>>>>> window relies on lots of constraints to size the various > >>>>>>>>>>> views > >>>>>>>>>>> to their > >>>>>>>>>>> parent's width and height, so if those are broken, I think > >>>>>>>>>>> that is the > >>>>>>>>>>> effect you might see. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On 9/24/07, Donald Anderson <[EMAIL PROTECTED]> wrote: > >>>>>>>>>>>> I finally got a Windows environment going, and can see the > >>>>>>>>>>>> problem. > >>>>>>>>>>>> I have confirmed it shows up in #6548 and that it does > >>>>>>>>>>>> not in > >>>>>>>>>>>> #6547. > >>>>>>>>>>>> I built in two different fresh directories to avoid any > >>>>>>>>>>>> cache > >>>>>>>>>>>> problems. > >>>>>>>>>>>> For me it is Windows only, doesn't show if the server is > >>>>>>>>>>>> OSX. > >>>>>>>>>>>> > >>>>>>>>>>>> Back in my (broken) trunk on Windows, I replaced the source > >>>>>>>>>>>> files > >>>>>>>>>>>> that I had changed with > >>>>>>>>>>>> the old (6547) versions, and I still see the problem > >>>>>>>>>>>> (after a > >>>>>>>>>>>> clean > >>>>>>>>>>>> build). I guess I have > >>>>>>>>>>>> to create a new trunk directory for each test to reliably > >>>>>>>>>>>> avoid cache > >>>>>>>>>>>> issues...? > >>>>>>>>>>>> This may be some hard slogging today to get this. > >>>>>>>>>>>> > >>>>>>>>>>>> - Don > >>>>>>>>>>>> > >>>>>>>>>>>> On Sep 24, 2007, at 9:42 AM, André Bargull wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> I got that error when I compiled the first time to the new > >>>>>>>>>>>>> trunk. > >>>>>>>>>>>>> So I don't see how Windows could be involved into this > >>>>>>>>>>>>> issue. > >>>>>>>>>>>>> In addition to that, trunk works for me in rev. #6539, > >>>>>>>>>>>>> therefore > >>>>>>>>>>>>> this is most likely linked to rev. #6548. > >>>>>>>>>>>>> > >>>>>>>>>>>>> This is my current trunk history: > >>>>>>>>>>>>> > >>>>>>>>>>>>> 1. #6548 or #6550 => first time I've checked out, must > >>>>>>>>>>>>> have > >>>>>>>>>>>>> been > >>>>>>>>>>>>> either 6548 or 6550; trunk was erroneous for me > >>>>>>>>>>>>> 2. #6529 => switched to first changeset of Don, recompiled > >>>>>>>>>>>>> everything => no errors > >>>>>>>>>>>>> 3. #6548 => switched to the second changeset of Don, > >>>>>>>>>>>>> recompiled > >>>>>>>>>>>>> everything => got theses errors > >>>>>>>>>>>>> 4. #6539 => switched back to the previous revision => no > >>>>>>>>>>>>> errors > >>>>>>>>>>>>> > >>>>>>>>>>>>> I can switch to #6548 or later, compile a simple > >>>>>>>>>>>>> application, and > >>>>>>>>>>>>> send it to you. So we can check if this is related to > >>>>>>>>>>>>> Windows, > >>>>>>>>>>>>> FlashPlayer or whatever... > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> André > >>>>>>>>>>>>> > >>>>>>>>>>>>> P T Withington wrote: > >>>>>>>>>>>>>> Is it possible that this is related to Windows' > >>>>>>>>>>>>>> penchant for > >>>>>>>>>>>>>> hanging on to old files? Did you stop/start your tomcat, > >>>>>>>>>>>>>> clear > >>>>>>>>>>>>>> your caches and all that mumbo when you updated? I don't > >>>>>>>>>>>>>> see the > >>>>>>>>>>>>>> error either.... > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 2007-09-23, at 13:01 EDT, Philip Romanik wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi Don, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I just tried this on XP (FF1.5 browser) and I see the > >>>>>>>>>>>>>>> same > >>>>>>>>>>>>>>> behavior that Andre reported. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Phil > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hi Andre, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I'm running on Mac OSX, and I've tried Safari and > >>>>>>>>>>>>>>>> Firefox > >>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>> they work for me. > >>>>>>>>>>>>>>>> That is, I get a full debugger window, and can type in > >>>>>>>>>>>>>>>> Debug.versionInfo() and get results. > >>>>>>>>>>>>>>>> (I'm new to the laszlo environment, so that's about > >>>>>>>>>>>>>>>> all I > >>>>>>>>>>>>>>>> know > >>>>>>>>>>>>>>>> how to do in the framework). > >>>>>>>>>>>>>>>> I ran an IE6 browser on WinXP against my server > >>>>>>>>>>>>>>>> (still on > >>>>>>>>>>>>>>>> Mac) > >>>>>>>>>>>>>>>> and still no problem. > >>>>>>>>>>>>>>>> Attached is a screen shot of that, in case I'm not > >>>>>>>>>>>>>>>> doing > >>>>>>>>>>>>>>>> something obvious to you. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> This is troubling, I'd expect a compiler issue would > >>>>>>>>>>>>>>>> give > >>>>>>>>>>>>>>>> a more > >>>>>>>>>>>>>>>> consistent disaster. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Phil -- you run on WinXP, can you try a fresh trunk and > >>>>>>>>>>>>>>>> see if > >>>>>>>>>>>>>>>> you get the same problem that Andre has? Thanks. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> - Don > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> > >>>>>>>>>>>> Don Anderson > >>>>>>>>>>>> Java/C/C++, Berkeley DB, systems consultant > >>>>>>>>>>>> > >>>>>>>>>>>> Voice: 617-547-7881 > >>>>>>>>>>>> Email: [EMAIL PROTECTED] > >>>>>>>>>>>> WWW: http://www.ddanderson.com > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> Henry Minsky > >>>>>>>>>>> Software Architect > >>>>>>>>>>> [EMAIL PROTECTED] > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> > >>>>>>>> Don Anderson > >>>>>>>> Java/C/C++, Berkeley DB, systems consultant > >>>>>>>> > >>>>>>>> Voice: 617-547-7881 > >>>>>>>> Email: [EMAIL PROTECTED] > >>>>>>>> WWW: http://www.ddanderson.com > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> Don Anderson > >>>>>> Java/C/C++, Berkeley DB, systems consultant > >>>>>> > >>>>>> Voice: 617-547-7881 > >>>>>> Email: [EMAIL PROTECTED] > >>>>>> WWW: http://www.ddanderson.com > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> Henry Minsky > >>>> Software Architect > >>>> [EMAIL PROTECTED] > >>> > >>> > >>> -- > >>> > >>> Don Anderson > >>> Java/C/C++, Berkeley DB, systems consultant > >>> > >>> Voice: 617-547-7881 > >>> Email: [EMAIL PROTECTED] > >>> WWW: http://www.ddanderson.com > >>> > >>> > >> > >> > >> -- > >> Henry Minsky > >> Software Architect > >> [EMAIL PROTECTED] > >> > > > > > -- > > Don Anderson > Java/C/C++, Berkeley DB, systems consultant > > Voice: 617-547-7881 > Email: [EMAIL PROTECTED] > WWW: http://www.ddanderson.com > > -- Henry Minsky Software Architect [EMAIL PROTECTED]
