Oh I forgot to add, when you run the "fdb" command line debugger, it pauses after loading the app, to let you set breakpoints, so you need to to type "c" to your shell to make it continue and start up the app in the browser.
On Fri, Jul 24, 2009 at 9:40 AM, Henry Minsky <[email protected]>wrote: > The Laszlo compiler tries to parse out any flex compiler errors that it > gets, but sometimes it fails to do this for some reasons. > > In that case, here is what I recommend. You can compile your .lzx app from > the command line, using "lzc", and there is some more info printed out that > you can use. The lzc command will print out the actual shell command it > would use to compile the intermediate .as files, and includes the pathname > of the temp directory it is using. > > So, for example, if you type > > lzc --runtime=swf9 hello.lzx > > It prints to your shell: > > Compiling: hello.lzx to hello.swf9.swf > Executing compiler: (cd /tmp/lzswf9/./build/hello; > /Users/hqm/openlaszlo/trunk-clean/WEB-INF/bin/mxmlc > -load-config=/Users/hqm/openlaszlo/trunk-clean/WEB-INF/frameworks/flex-config.xml > -compiler.show-actionscript-warnings=false > -compiler.source-path+=/tmp/lzswf9/./build/hello > -compiler.headless-server=true -compiler.fonts.advanced-anti-aliasing=true > -output /tmp/lzswf9/./build/hello/app.swf -default-size 500 400 > -compiler.library-path+=/Users/hqm/openlaszlo/trunk-clean/lps/includes/lfc/LFC9.swc > -compiler.library-path+=/Users/hqm/openlaszlo/trunk-clean/WEB-INF/flexlib > -includes \$debug \$profile \$backtrace \$runtime \$swf7 \$swf8 \$as2 \$swf9 > \$swf10 \$as3 \$dhtml \$j2me \$svg \$js1 -target-player=9.0.0 -frame two > LzSpriteApplication -file-specs=/tmp/lzswf9/./build/hello/LzPreloader.as) > compiler output is Loading configuration file > /Users/hqm/openlaszlo/trunk-clean/WEB-INF/frameworks/flex-config.xml > /private/tmp/lzswf9/build/hello/app.swf (111708 bytes) > > compiler output: > Loading configuration file > /Users/hqm/openlaszlo/trunk-clean/WEB-INF/frameworks/flex-config.xml > /private/tmp/lzswf9/build/hello/app.swf (111708 bytes) > > Done executing compiler > > If it failed to capture and print a useful error from the flex compiler, > you can manually run the command it displayed, and that might show you some > information that the lzc compiler failed to extract from the flex errors. > > Of course, as you pointed out, the errors will be relative to these > intermediate .as files, but they have source locator comments in them at > frequent intervals, so you can usually figure out what lzx source file they > came from, although it is inconvenient to do this manually. > > > For runtime errors, as Raju mentioned, the Flex fdb debugger can be used to > get extra information. You can run a laszlo app by doing something like > this > > fdb "http://127.0.0.1:8080/trunk-clean/test/hello.lzx?lzr=swf9&debug=true"; > > (you should have the Flash debug player installed) > > > > On Fri, Jul 24, 2009 at 7:28 AM, Sebastian Wagner > <[email protected]>wrote: > >> hi, >> >> actually you run into a lot of compilation issues when you run a previous >> application into SWF9. >> I followed the SWF9 Migration Guide of course, the code has zero problems >> to be compiled to SWF8. >> I guess in most cases its something very tiny tricky in the code that >> needs to be changed but actually you don't get anything except >> *org.openlaszlo.sc.CompilerError: Errors from compiler, output file not >> created* >> The console does also only pring: >> FAIL: compiler returned 1 ... or another number >> >> So how do you get those Compile Errors? >> I guess they are not really that handy as they will show you only errors >> in the resulting ActionScript that is going to be compiled by the Flex >> compiler. >> So you will not see which LZX-Codeline has the error. >> But without any notice at which code-block to look at its almost >> impossible to migrate more then a bunch of code lines with every >> compilation. >> >> I've seen that there are some properties in the configuration: >> compiler.swf9.warnings=false >> compiler.swf9.execflex=true >> # Tell compiler to catch errors in debug mode >> compiler.catcherrors=true >> >> changing them does seem to have an effect. >> >> Is there a clue that is hidden somewhere or how do you judge what needs to >> be done when you run into this? >> >> thanks, >> sebastian >> >> -- >> Sebastian Wagner >> http://www.webbase-design.de >> http://openmeetings.googlecode.com >> http://www.laszlo-forum.de >> [email protected] >> > > > > -- > Henry Minsky > Software Architect > [email protected] > > > -- Henry Minsky Software Architect [email protected]
