Different output SWFs, from identical inputs

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Different output SWFs, from identical inputs

Bill Moorier
We just hit a fairly big roadblock with our use of haXe here at justin.tv.

I released our new live video player yesterday, and we are very happy
with it in general.  HaXe has allowed us a ton of flexibility over our
old AS3-based player, which we were compiling with CS3.

The problem we've run into though, is that we're getting different
output SWFs for the same inputs (the inputs being a SWF that our
designer makes, plus a bunch of hx files).

This is bad for us because of the way our deploy works.  We have a ton
of application servers, and a bunch of caching servers, load-balancers
and such, and we like to push source-code to them and have all
compilation and packaging tasks done on each node (that's how we do it
with all our other assets, like javascript, css, and the core web
application).

We also name files like blah-N.ext, where N is the sha1 of the
underlying file.  This naming convention has saved us many times in
the past, for various reasons.

You can probably see where we're running into problems now:  Each user
will hit many different servers to construct a single web page.
Things will only work right if the SWFs match on every server that
we've deployed the same source to.

Right now we're having to work around this by manually copying files
around, rather than using our existing deploy infrastructure.  Is
there any way haXe could be changed to output identical SWFs for the
same input?  I'd be happy with this being on a command-line switch if
other people need the existing functionality of course.

Cheers,
Bill.
--
Bill Moorier: http://abstractnonsense.com
VP Software Development, http://www.justin.tv

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Different output SWFs, from identical inputs

Nicolas Cannasse
Bill Moorier a écrit :
> We just hit a fairly big roadblock with our use of haXe here at justin.tv.
>
> I released our new live video player yesterday, and we are very happy
> with it in general.  HaXe has allowed us a ton of flexibility over our
> old AS3-based player, which we were compiling with CS3.
>
> The problem we've run into though, is that we're getting different
> output SWFs for the same inputs (the inputs being a SWF that our
> designer makes, plus a bunch of hx files).
[...]

Please note that this only occurs for Flash9. The problem being that
loading another SWF in the same application domain "override" common
classes such as flash.Boot and flash.Lib.

This is partially fixed by using a flash.BootXXXX class, where XXXX is a
random identifier, but it's not a very good way of doing, so I guess
I'll have to find another way.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Different output SWFs, from identical inputs

Bill Moorier
On Thu, Oct 30, 2008 at 1:27 PM, Nicolas Cannasse
<[hidden email]> wrote:

> Bill Moorier a écrit :
>>
>> We just hit a fairly big roadblock with our use of haXe here at justin.tv.
>>
>> I released our new live video player yesterday, and we are very happy
>> with it in general.  HaXe has allowed us a ton of flexibility over our
>> old AS3-based player, which we were compiling with CS3.
>>
>> The problem we've run into though, is that we're getting different
>> output SWFs for the same inputs (the inputs being a SWF that our
>> designer makes, plus a bunch of hx files).
>
> [...]
>
> Please note that this only occurs for Flash9. The problem being that loading
> another SWF in the same application domain "override" common classes such as
> flash.Boot and flash.Lib.
>
> This is partially fixed by using a flash.BootXXXX class, where XXXX is a
> random identifier, but it's not a very good way of doing, so I guess I'll
> have to find another way.
>
> Nicolas

I see, thanks very much for the explanation Nicolas.

If I understand correctly the problem, maybe the class could be named
something like flash.Boot_name1_name2_..._nameN, where those names are
taken from the filenames of all the inputs to the compilation?  Would
that be reasonably safe?

Thanks again,
Bill.
--
Bill Moorier: http://abstractnonsense.com
VP Software Development, http://www.justin.tv

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Different output SWFs, from identical inputs

Bill Moorier
In case you're interested, we're currently using this embarrassingly
clumsy patch I wrote to work around this issue.  It's the first piece
of ocaml I've ever written - shield your eyes ;-)

bills-laptop:~/haxe/haxe wjb$ diff -u genswf9.ml genswf9.ml.new
--- genswf9.ml  2008-11-03 17:10:29.000000000 -0800
+++ genswf9.ml.new      2008-11-03 17:01:15.000000000 -0800
@@ -1875,7 +1875,7 @@
       let ctx = {
               com = com;
               debugger = Common.defined com "fdb";
-               boot = "Boot_" ^ Printf.sprintf "%X" (Random.int 0xFFFFFF);
+               boot = "Boot_" ^ (String.sub (Sys.getcwd ()) (1 +
(String.rindex (Sys.getcwd ()) '/')) ((String.length (Sys.getcwd ()))
- (1 + (String.rindex (Sys.getcwd ()) '/'))));
               code = DynArray.create();
               locals = PMap.empty;
               infos = default_infos();

I'm sure you can easily come up with something much better!

Cheers,
Bill.


On Thu, Oct 30, 2008 at 2:36 PM, Bill Moorier <[hidden email]> wrote:

> On Thu, Oct 30, 2008 at 1:27 PM, Nicolas Cannasse
> <[hidden email]> wrote:
>> Bill Moorier a écrit :
>>>
>>> We just hit a fairly big roadblock with our use of haXe here at justin.tv.
>>>
>>> I released our new live video player yesterday, and we are very happy
>>> with it in general.  HaXe has allowed us a ton of flexibility over our
>>> old AS3-based player, which we were compiling with CS3.
>>>
>>> The problem we've run into though, is that we're getting different
>>> output SWFs for the same inputs (the inputs being a SWF that our
>>> designer makes, plus a bunch of hx files).
>>
>> [...]
>>
>> Please note that this only occurs for Flash9. The problem being that loading
>> another SWF in the same application domain "override" common classes such as
>> flash.Boot and flash.Lib.
>>
>> This is partially fixed by using a flash.BootXXXX class, where XXXX is a
>> random identifier, but it's not a very good way of doing, so I guess I'll
>> have to find another way.
>>
>> Nicolas
>
> I see, thanks very much for the explanation Nicolas.
>
> If I understand correctly the problem, maybe the class could be named
> something like flash.Boot_name1_name2_..._nameN, where those names are
> taken from the filenames of all the inputs to the compilation?  Would
> that be reasonably safe?
>
> Thanks again,
> Bill.
> --
> Bill Moorier: http://abstractnonsense.com
> VP Software Development, http://www.justin.tv
>



--
Bill Moorier: http://abstractnonsense.com
VP Software Development, http://www.justin.tv

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Different output SWFs, from identical inputs

Nicolas Cannasse
In reply to this post by Bill Moorier
Bill Moorier a écrit :
> We just hit a fairly big roadblock with our use of haXe here at justin.tv.
>
> I released our new live video player yesterday, and we are very happy
> with it in general.  HaXe has allowed us a ton of flexibility over our
> old AS3-based player, which we were compiling with CS3.
>
> The problem we've run into though, is that we're getting different
> output SWFs for the same inputs (the inputs being a SWF that our
> designer makes, plus a bunch of hx files).

The unique ID is now generated based on the full path of the SWF target
file and is not random anymore.

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Different output SWFs, from identical inputs

Franco Ponticelli
The unique ID is now generated based on the full path of the SWF target file and is not random anymore.

Nice one ;-) 

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Different output SWFs, from identical inputs

Bill Moorier
In reply to this post by Nicolas Cannasse
On Sun, Nov 23, 2008 at 5:08 AM, Nicolas Cannasse
<[hidden email]> wrote:

> Bill Moorier a écrit :
>>
>> We just hit a fairly big roadblock with our use of haXe here at justin.tv.
>>
>> I released our new live video player yesterday, and we are very happy
>> with it in general.  HaXe has allowed us a ton of flexibility over our
>> old AS3-based player, which we were compiling with CS3.
>>
>> The problem we've run into though, is that we're getting different
>> output SWFs for the same inputs (the inputs being a SWF that our
>> designer makes, plus a bunch of hx files).
>
> The unique ID is now generated based on the full path of the SWF target file
> and is not random anymore.

Fantastic, thanks!

Cheers,
Bill.
--
Bill Moorier: http://abstractnonsense.com
VP Software Development, http://www.justin.tv

--
haXe - an open source web programming language
http://haxe.org