Hi Neil, It looks like the bug you're seeing from that stacktrace is somewhere inside of a <script> block (based on it being in the middle of instantiating an LzScript node). Stuff inside of <script> blocks is a little more delicate in swf9 than it was in swf8, given what the code inside of a <script> block actually compiles to (swf9 is a somewhat less dynamic of a runtime environment, and there are issues with how the code inside of a <script> block gets compiled into a closure to defer it's execution).
Just a couple of notes about the intermediate .as files that the LZX compiler produces: As you noticed, the app is compiled down to some intermediate .as files for flex, and those are written to a tmp directory. The app is linked with the LFC swf9 (or swf10) library, which is in flex .swc library file format (e.g., lps/includes/lfc/LFC9.swc or LFC9-debug.swc) You can run an application under the control of the flex command line debugger. This can sometimes let you catch some errors right where they happen that it's hard for the Laszlo debugger to catch (although this usually is needed when debugging the 'kernel' , i.e., the swf9-specific code in the LFC library). The fdb debugger can be invoked like this to run the app inside of the browser and then connect to it: fdb "http://127.0.0.1:8080/lps4/myapp.lzx?lzr=swf9"; or in your case if it's a solo app that you compiled to a swf file from the command line , I think you could say fdb "http://127.0.0.1:8080/lps4/myapp.swf9.swf"; That will launch the app in the browser and then the fdb command line debugger will wait for you to set a breakpoint if you want to. Just type 'c' to continue and it will execute. The flex debugger will print out a pathname of where it is, but that will be the name of the tmp file that was generated. Unfortunately, sometimes you may just need to open that file in an editor and see what line of code it's referring to, there will be comments in the file that point back to the source code location in the original LZX file. [Note there's currently a bug with the OpenLaszlo debugger when running an app like this which has a '.swf' suffix instead of a '.lzx' suffix, if you try to eval anything but a simple foo.bar.baz type of expression, it won't be able to handle it because it sends the expression to be evaluated to the wrong URL on the LPS server] On Wed, Oct 28, 2009 at 6:14 PM, Neil Mix <n...@pandora.com> wrote: > Hi folks, > > I'm attempting to port a very oooold Laszlo project to 4.6.1, swf9 runtime. > The project is compiling successfully, but when I run the app it fails > early on during startup. No errors are showing up in the debug window, but > the handy debug Flash is logging the following stack trace: > > TypeError: Error #1006: value is not a function. > at > <anonymous>()[/private/var/folders/Af/AfhEQDevFwaKcP77YUvST++++TI/-Tmp-/lzswf9/Users/nmix/sbwork/neil-8.9-flash-upgrade/SavageBeast/Engineering/projects/radio/src/flash/TMP_ANT/pandora/build/tuner/LzApplication.as:16907] > at > <anonymous>()[/private/var/folders/Af/AfhEQDevFwaKcP77YUvST++++TI/-Tmp-/lzswf9/Users/nmix/sbwork/neil-8.9-flash-upgrade/SavageBeast/Engineering/projects/radio/src/flash/TMP_ANT/pandora/build/tuner/LzApplication.as:17223] > at > <anonymous>()[/private/var/folders/Af/AfhEQDevFwaKcP77YUvST++++TI/-Tmp-/lzswf9/Users/nmix/sbwork/neil-8.9-flash-upgrade/SavageBeast/Engineering/projects/radio/src/flash/TMP_ANT/pandora/build/tuner/LzApplication.as:17324] > at LzScript()[/tmp/lzswf9/lzgen24517/LzScript.as:8] > at LzNode/makeChild()[/tmp/lzswf9/lzgen24517/LzNode.as:866] > at > LzInstantiatorService/makeSomeViews()[/tmp/lzswf9/lzgen24517/LzInstantiatorService.as:221] > at > LzInstantiatorService/checkQ()[/tmp/lzswf9/lzgen24517/LzInstantiatorService.as:171] > at > Function/http://adobe.com/AS3/2006/builtin::call()<http://adobe.com/AS3/2006/builtin::call%28%29> > at LzEvent/sendEvent()[/tmp/lzswf9/lzgen24517/LzEvent.as:89] > at > LzIdleKernel$/__update()[/tmp/lzswf9/lzgen24517/LzIdleKernel.as:19] > > Now I recognize that Flex is the compiler underneath and this is an > intermediate auto-generated file. Finding the file and the source of the > bug is not very hard. But this is almost certainly the first of many such > errors I need to fix. It would be great if I could automatically tie this > back to the original source file/line. Is it normal for errors like this > not to show up in the Debug window? Is there anything I'm doing wrong that > prevents me from seeing the original source file/line? > > A couple facts about my setup that could influence things: > - I'm compiling from the command-line > - As you can probably see, the app is pretty dang big > > Thanks for any advice, > -Neil > -- Henry Minsky Software Architect hmin...@laszlosystems.com
