[Laszlo-dev] new trunk and runtime-target SWF
Donald Anderson
dda at ddanderson.com
Tue Sep 25 04:55:42 PDT 2007
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 <dda at ddanderson.com> 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 <ptw at openlaszlo.org> 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"
>>>>>>>>>> <henry.minsky at gmail.com> 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 <dda at ddanderson.com> 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: dda at ddanderson.com
>>>>>>>>>>>> WWW: http://www.ddanderson.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Henry Minsky
>>>>>>>>>>> Software Architect
>>>>>>>>>>> hminsky at laszlosystems.com
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Don Anderson
>>>>>>>> Java/C/C++, Berkeley DB, systems consultant
>>>>>>>>
>>>>>>>> Voice: 617-547-7881
>>>>>>>> Email: dda at ddanderson.com
>>>>>>>> WWW: http://www.ddanderson.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Don Anderson
>>>>>> Java/C/C++, Berkeley DB, systems consultant
>>>>>>
>>>>>> Voice: 617-547-7881
>>>>>> Email: dda at ddanderson.com
>>>>>> WWW: http://www.ddanderson.com
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Henry Minsky
>>>> Software Architect
>>>> hminsky at laszlosystems.com
>>>
>>>
>>> --
>>>
>>> Don Anderson
>>> Java/C/C++, Berkeley DB, systems consultant
>>>
>>> Voice: 617-547-7881
>>> Email: dda at ddanderson.com
>>> WWW: http://www.ddanderson.com
>>>
>>>
>>
>>
>> --
>> Henry Minsky
>> Software Architect
>> hminsky at laszlosystems.com
>>
>
--
Don Anderson
Java/C/C++, Berkeley DB, systems consultant
Voice: 617-547-7881
Email: dda at ddanderson.com
WWW: http://www.ddanderson.com
More information about the Laszlo-dev
mailing list