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
