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]

Reply via email to