Yeah I think that was historical; I am trying to remember what the issue there was.
I think maybe this was because at one point we wanted to make sure that a .swf file would be written when you fetched an app for SOLO deployment. I think that the SOLO deploy wizard expects to compile an app to a .swf file that way, by fetching the URL and seeing that this file is written as a side effect. Can you check that if you fetch a file in the browser with lzproxied=false, that a .lzx.swf file is still written out? On Mon, Sep 19, 2011 at 12:05 PM, Donald Anderson <[email protected]>wrote: > Henry, > > From what I can tell the foo.lzx.swf10.swf file is identical to the output > file normally generated with the --output out.swf . > So does this mean I can just remove the code block (in Compiler.java) that > begins: > > // If the app is serverless, write out a .lzx.swf file when > compiling > if (canvas != null && !canvas.isProxied() && > env.getProperty("nodeploy") == null) { > > // Create a foo.lzx.[js|swf] serverless deployment file for > sourcefile foo.lzx > .... > > Can I assume that code just ended up there for historical reasons? > > Thanks! > > - Don > > > On Aug 30, 2011, at 12:11 PM, Henry Minsky wrote: > > That's a bug, should have been fixed a long time ago but nobody got around > to it! > Maybe you could file a bug report, someone may get to it. > > > On Tue, Aug 30, 2011 at 10:17 AM, Rami Ojares / AMG <[email protected] > > wrote: > >> One strange thing I have noticed is that when I compile some lzx file >> say: /a/b/c.lzx and define as >> --dir /x/y --output z.swf >> I do get /x/y/z.swf but in addition to that I also get >> /a/b/c.lzx.swf10.swf >> >> And that messes my source code. >> Why is that generated? >> Isn't the temp folder enough? >> >> - rami >> > > > > -- > Henry Minsky > > > > > > -- > > Don Anderson > Java/C/C++, Berkeley DB, systems consultant > > voice: 617-306-2057 > email: [email protected] > www: http://www.ddanderson.com > blog: http://libdb.wordpress.com > > > > > > -- Henry Minsky
