[Laszlo-dev] new trunk and runtime-target SWF
Donald Anderson
dda at ddanderson.com
Mon Sep 24 16:24:34 PDT 2007
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...
Hmm, interesting idea.
I was first thinking this may simply be a case where I messed up
the walk of the AST.
Here's the code that should be emitted:
push 'name', '$base$2Fbasefocusview$2Elzx_303_67_x_always'
setMember
dup
push 'dependencies', '_root'
getVariable
with
function2 () (r:1='this', r:2='_root')
push r:this
with
push 'offset', 'classroot'
getVariable
push 'width', r:this, 'width', 'parent'
getVariable
push 6
initArray
return
end
end // of function
dup
push 'name', '$base$2Fbasefocusview
$2Elzx_303_67_x_always_dependencies'
setMember
end
and what's being emitted is:
push 'name', '$base$2Fbasefocusview$2Elzx_303_67_x_always'
setMember
dup
push 'dependencies', '_root'
getVariable
with
function2 () (r:1='this')
push r:this
with
push 0
initArray
return
end
end // of function
dup
push 'name', '$base$2Fbasefocusview
$2Elzx_303_67_x_always_dependencies'
setMember
end
The only place that emits initArray is visitArrayLiteral, so that and
its descendent callees
are where I was looking.
But I see what you mean, things in our dev environment (java version,
or ....) are stirring the soup
differently and and exposing different behavior.
- Don
>
> 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
More information about the Laszlo-dev
mailing list