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 <[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
