royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabe Harbs <harbs.li...@gmail.com>
Subject Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)
Date Tue, 06 Feb 2018 17:13:04 GMT
What kind of utility do you have in mind?


> On Feb 6, 2018, at 7:09 PM, Alex Harui <aharui@adobe.com.INVALID> wrote:
> 
> Don't bother making VO's by hand for ASDoc.  Let's write a utility to
> generate it.  It will save everyone time.  If you want to see
> bin/js-release, change the build to not use ADVANCED_OPTIMIZATIONS for now.
> 
> There are lots of reasons to avoid using plain Object in a Royale app
> other than as a hash map.  IMO, most C and Java apps don't use generic
> untyped dynamic bags of properties.  If I add a warning about Object use,
> there will be a directive to suppress it.  Objects are prone to error, and
> there is some indication that runtimes work better with type information.
> The JS runtimes wouldn't bother type inferencing otherwise.  WASM hints
> that it wants types.
> 
> My 2 cents,
> -Alex
> 
> On 2/6/18, 8:45 AM, "Gabe Harbs" <harbs.lists@gmail.com> wrote:
> 
>> Huh?
>> 
>> I don’t see how it’s possible to avoid Object completely. Even using VOs
>> require constructing them from Objects when coming from outside sources.
>> 
>> Again: I’m not arguing against using VOs when possible/practical. I’m
>> just arguing that use of dot notation on Objects shouldn’t blow up your
>> app.
>> 
>> Right now, I’m creating VOs for the ASDoc app. It’s kind of tedious work…
>> 
>> Harbs
>> 
>>> On Feb 6, 2018, at 6:40 PM, Alex Harui <aharui@adobe.com.INVALID> wrote:
>>> 
>>> Good catch. I fixed that.
>>> 
>>> Actually, you are arguing in favor of ValueObjects.  The error was there
>>> because commitObj was a plain Object so the compiler couldn't understand
>>> more about it.  We want to not have any plain objects in a Royale app.
>>> They only create potential problems.  In fact, maybe it is time for me
>>> to
>>> figure out how to generate warnings on every use of plain Object.
>>> Eventually we will have typedefs for the GitHub value objects and then
>>> there wouldn't be an issue like this.
>>> 
>>> Thanks for proving my point.
>>> 
>>> -Alex
>>> 
>>> On 2/6/18, 2:59 AM, "Gabe Harbs" <harbs.lists@gmail.com> wrote:
>>> 
>>>> To illustrate that the VO solution is also error prone, I’m pretty sure
>>>> that this page has a mistake:
>>>> 
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachero
>>>> ya
>>>> 
>>>> leci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flast
>>>> Su
>>>> 
>>>> ccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-t
>>>> ut
>>>> 
>>>> orial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e4
>>>> 9b
>>>> 
>>>> b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653
>>>> 51
>>>> 
>>>> 16172815360&sdata=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D&reser
>>>> ve
>>>> d=0 
>>>> 
>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacher
>>>> oy
>>>> 
>>>> aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flas
>>>> tS
>>>> 
>>>> uccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-
>>>> tu
>>>> 
>>>> torial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e
>>>> 49
>>>> 
>>>> bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365
>>>> 35
>>>> 
>>>> 116172825365&sdata=3m3kTW910JYWV8MaM4%2F%2B3v82l5EvxIqgRjqAtIC7N%2BU%3D&
>>>> re
>>>> served=0>
>>>> 
>>>> Unless I’m missing something, the following line can be renamed:
>>>>          data.message = commitObj.message;
>>>> 
>>>> I think it should have been:
>>>>          data.message = commitObj[“message”];
>>>> 
>>>> Harbs
>>>> 
>>>>> On Feb 6, 2018, at 12:48 PM, Gabe Harbs <harbs.lists@gmail.com>
wrote:
>>>>> 
>>>>> Related:
>>>>> 
>>>>> On this page: 
>>>>> 
>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacher
>>>>> oy
>>>>> 
>>>>> aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Fla
>>>>> st
>>>>> 
>>>>> SuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicatio
>>>>> n-
>>>>> 
>>>>> tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb44
>>>>> 3d
>>>>> 
>>>>> dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535116
>>>>> 17
>>>>> 
>>>>> 2825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&re
>>>>> se
>>>>> rved=0 
>>>>> 
>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache
>>>>> ro
>>>>> 
>>>>> yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Fl
>>>>> as
>>>>> 
>>>>> tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicati
>>>>> on
>>>>> 
>>>>> -tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb4
>>>>> 43
>>>>> 
>>>>> ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653511
>>>>> 61
>>>>> 
>>>>> 72825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&r
>>>>> es
>>>>> erved=0>
>>>>> 
>>>>> Shouldn’t the following code have trouble with minification?
>>>>> 
>>>>> {
>>>>> repos = configurator.json.repos;
>>>>> projectName = configurator.json.projectName;
>>>>> }
>>>>> 
>>>>> What’s preventing json.repos and json.projectName from being renamed?
>>>>> 
>>>>>> On Feb 5, 2018, at 11:34 PM, Alex Harui <aharui@adobe.com.INVALID
>>>>>> <mailto:aharui@adobe.com.INVALID>> wrote:
>>>>>> 
>>>>>> Maybe I'm missing something.  I don't think Royale has any extra
>>>>>> problems
>>>>>> with JSON objects than other JS Frameworks have.  If you want to
>>>>>> minify,
>>>>>> you have to use brackets and strings.  If you don't want to minify,
>>>>>> then
>>>>>> you don't need to worry about that.  Am I wrong about that?
>>>>>> 
>>>>>> 
>>>>>> JSON has something like a "reviver".  Has anyone played with that
to
>>>>>> see
>>>>>> if it can be used to convert straight to VO's?
>>>>>> 
>>>>>> Thanks,
>>>>>> -Alex 
>>>>>> 
>>>>>> On 2/5/18, 1:08 PM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>> <mailto:harbs.lists@gmail.com>> wrote:
>>>>>> 
>>>>>>> An additional point:
>>>>>>> 
>>>>>>> How do you propose handling json that’s multiple levels deep?
Walk
>>>>>>> the
>>>>>>> json and construct VOs on each level? That seems to me just as
bad
>>>>>>> as
>>>>>>> the
>>>>>>> problem. Imagine you just want foo.baz.thingy.uid? You’d need
to
>>>>>>> create a
>>>>>>> VO of foo, baz and thingy or be forced to use
>>>>>>> foo[“baz”][“thingy”][“uid”]. Of course the average
user is not going
>>>>>>> to
>>>>>>> remember to do that until their release build doesn’t work…
>>>>>>> 
>>>>>>> Creating VOs means you can’t simply use JSON.parse(). You’d
need
>>>>>>> your
>>>>>>> own
>>>>>>> parser for each type of json you’re consuming. OK. Maybe not
full
>>>>>>> parsing, but the constructors for these VOs will get pretty messy
—
>>>>>>> especially if the structure is a bit fluid.
>>>>>>> 
>>>>>>> Harbs
>>>>>>> 
>>>>>>> 
>>>>>>>> On Feb 5, 2018, at 10:36 PM, Gabe Harbs <harbs.lists@gmail.com
>>>>>>>> <mailto:harbs.lists@gmail.com>> wrote:
>>>>>>>> 
>>>>>>>> In theory, everything you say is true. It might even be good
>>>>>>>> practice.
>>>>>>>> 
>>>>>>>> I’m telling you that this was a pain point when migrating
my app.
>>>>>>>> Simply declaring types as VOs didn't solve the problem for
me. The
>>>>>>>> way
>>>>>>>> I’ve found that’s needed to solve the problem was passing
the
>>>>>>>> object
>>>>>>>> literal into a VO constructor and declaring the variables
using
>>>>>>>> bracketed access. I was likely going about it wrong, but
it was
>>>>>>>> easier
>>>>>>>> to just go with the bracketed literals.
>>>>>>>> 
>>>>>>>> Again: Suggesting using VOs (if we can figure out easy instructions
>>>>>>>> to
>>>>>>>> do so) is probably a good idea and better recommended practice,
but
>>>>>>>> people live on the edge using other JS frameworks, and I’d
rather
>>>>>>>> not
>>>>>>>> make it harder than it needs to be if they do want to use
untyped
>>>>>>>> object
>>>>>>>> literals.
>>>>>>>> 
>>>>>>>> Harbs
>>>>>>>> 
>>>>>>>>> On Feb 5, 2018, at 8:01 PM, Alex Harui <aharui@adobe.com.INVALID
>>>>>>>>> <mailto:aharui@adobe.com.INVALID>>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> It was great to skip type-checking in Flash at times,
but the
>>>>>>>>> runtime
>>>>>>>>> was
>>>>>>>>> also strongly typed.  Also, JS was not a practical language
for
>>>>>>>>> Flash.
>>>>>>>>> It
>>>>>>>>> is more risky to do skip type-checking in Royale for
JS.  These
>>>>>>>>> new
>>>>>>>>> cars
>>>>>>>>> with lane warnings are a rough analogy.  They only let
you be less
>>>>>>>>> attentive on nice new painted highways.  Flash's runtime
wouldn't
>>>>>>>>> let
>>>>>>>>> you
>>>>>>>>> make type mismatches so it effectively had lane lines.
 JS is a
>>>>>>>>> road
>>>>>>>>> without lane lines.  A ValueObject keeps your eyes on
the road.
>>>>>>>>> An
>>>>>>>>> ounce
>>>>>>>>> of prevention is better than a pound of cure.
>>>>>>>>> 
>>>>>>>>> IMO, you might be better off writing a bead that you
can pass a
>>>>>>>>> JSON
>>>>>>>>> object and it will generate the AS class for you to copy
from the
>>>>>>>>> clipboard and paste into a file.  Then you could guess
at the
>>>>>>>>> types.
>>>>>>>>> That
>>>>>>>>> wouldn't require compiler changes and would encourage
early
>>>>>>>>> prevention.
>>>>>>>>> 
>>>>>>>>> Just an idea,
>>>>>>>>> -Alex
>>>>>>>>> 
>>>>>>>>> On 2/5/18, 9:39 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>> <mailto:harbs.lists@gmail.com>> wrote:
>>>>>>>>> 
>>>>>>>>>> Yeah. That’s what you’ve argued in the past,
and in a pure world
>>>>>>>>>> you’d be
>>>>>>>>>> right.
>>>>>>>>>> 
>>>>>>>>>> However, I’d prefer the option to be practical
when dealing with
>>>>>>>>>> more
>>>>>>>>>> data types. Being forced to fiddle with properly
typed objects
>>>>>>>>>> *always*
>>>>>>>>>> is too confining IMO. What I personally ended up
doing when
>>>>>>>>>> dealing
>>>>>>>>>> with
>>>>>>>>>> APIs and the like was the make sure to quote everything
in my app
>>>>>>>>>> rather
>>>>>>>>>> than declare VOs even though finding all the instances
were a
>>>>>>>>>> pain.
>>>>>>>>>> 
>>>>>>>>>> I think it’s pretty common for folks to use untyped
objects
>>>>>>>>>> *especially*
>>>>>>>>>> when dealing with APIs in classic Flex apps. It seem
overly
>>>>>>>>>> draconian
>>>>>>>>>> to
>>>>>>>>>> make that a requirement for Royale.
>>>>>>>>>> 
>>>>>>>>>> Part of the attraction of ActionScript has been that
it’s
>>>>>>>>>> *optionally*
>>>>>>>>>> typed. Minification in JS makes the optional typing
pretty weak.
>>>>>>>>>> 
>>>>>>>>>>> If you don't care about SWF support, you can
quickly make
>>>>>>>>>>> ValueObjects
>>>>>>>>>>> just for the compiler.
>>>>>>>>>> 
>>>>>>>>>> Quickly? I’m not sure how.
>>>>>>>>>> 
>>>>>>>>>> My $0.02.
>>>>>>>>>> Harbs
>>>>>>>>>> 
>>>>>>>>>>> On Feb 5, 2018, at 7:28 PM, Alex Harui <aharui@adobe.com.INVALID
>>>>>>>>>>> <mailto:aharui@adobe.com.INVALID>>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> IMO, your proposal sort of defeats the purpose
of ActionScript
>>>>>>>>>>> and
>>>>>>>>>>> Royale,
>>>>>>>>>>> which is to provide a type system at compile
time.  Not only
>>>>>>>>>>> should
>>>>>>>>>>> you
>>>>>>>>>>> want to address your JSON fields, but you should
want to have
>>>>>>>>>>> them
>>>>>>>>>>> type-checked, and that you spelled the field
name correctly.
>>>>>>>>>>> Otherwise,
>>>>>>>>>>> the compiler is going to also allow you to mistype:
>>>>>>>>>>> 
>>>>>>>>>>> var name = myProps["nme"];
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> And there will be no errors.  And similarly:
>>>>>>>>>>> 
>>>>>>>>>>> var myObj:Object = {
>>>>>>>>>>> nme: "foo",
>>>>>>>>>>> age : 30.1415
>>>>>>>>>>> }
>>>>>>>>>>> 
>>>>>>>>>>> Will be allowed when it probably shouldn't. 
And also, you could
>>>>>>>>>>> then
>>>>>>>>>>> use
>>>>>>>>>>> myObj when you intended to use myOtherObj and
nobody will know
>>>>>>>>>>> until
>>>>>>>>>>> you
>>>>>>>>>>> try to debug in JS.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> If you don't care about SWF support, you can
quickly make
>>>>>>>>>>> ValueObjects
>>>>>>>>>>> just for the compiler.  In ASDoc, the ValueObject
is never
>>>>>>>>>>> instantiated.
>>>>>>>>>>> It is just like a typedef for the compiler.
>>>>>>>>>>> 
>>>>>>>>>>> HTH,
>>>>>>>>>>> -Alex
>>>>>>>>>>> 
>>>>>>>>>>> On 2/5/18, 8:43 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>> <mailto:harbs.lists@gmail.com>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>>> JSON Objects are not destroyed.
>>>>>>>>>>>> 
>>>>>>>>>>>> Yeah. I know, but untyped js literals are
pretty much useless
>>>>>>>>>>>> in
>>>>>>>>>>>> minified
>>>>>>>>>>>> Royale apps.
>>>>>>>>>>>> 
>>>>>>>>>>>>> Propose a way to determine that a data
structure
>>>>>>>>>>>>> is external and what the compiler should
generate and
>>>>>>>>>>>>> implement
>>>>>>>>>>>>> it.
>>>>>>>>>>>>> IMO,
>>>>>>>>>>>>> the answer is to create ValueObjects.
 That is essentially
>>>>>>>>>>>>> typedefs
>>>>>>>>>>>>> and
>>>>>>>>>>>>> AFAIK, there is no way to automate typedef
generation.
>>>>>>>>>>>> 
>>>>>>>>>>>> I already made a suggestion once:
>>>>>>>>>>>> 
>>>>>>>>>>>> For untyped Objects, the compiler could convert
dot notation to
>>>>>>>>>>>> bracket
>>>>>>>>>>>> notation.
>>>>>>>>>>>> 
>>>>>>>>>>>> The other half of that would be to convert
all object literals
>>>>>>>>>>>> to
>>>>>>>>>>>> “quoted” literals automatically.
>>>>>>>>>>>> 
>>>>>>>>>>>> So if I have a function:
>>>>>>>>>>>> 
>>>>>>>>>>>> function parseMyJson(json:String):Object{
>>>>>>>>>>>> 	return JSON.parse(json);
>>>>>>>>>>>> }
>>>>>>>>>>>> 
>>>>>>>>>>>> var myProps:Object = parseMyJson(json);
>>>>>>>>>>>> 
>>>>>>>>>>>> var name:string = myProps.name;
>>>>>>>>>>>> 
>>>>>>>>>>>> Would become:
>>>>>>>>>>>> 
>>>>>>>>>>>> function parseMyJson(json){
>>>>>>>>>>>> 	return JSON.parse(json);
>>>>>>>>>>>> }
>>>>>>>>>>>> 
>>>>>>>>>>>> var myProps = parseMyJson(json);
>>>>>>>>>>>> 
>>>>>>>>>>>> var name = myProps["name"];
>>>>>>>>>>>> 
>>>>>>>>>>>> And this:
>>>>>>>>>>>> var myObj:Object = {
>>>>>>>>>>>> 	name: "foo",
>>>>>>>>>>>> 	age : 30
>>>>>>>>>>>> }
>>>>>>>>>>>> 
>>>>>>>>>>>> Would become:
>>>>>>>>>>>> var myObj = {
>>>>>>>>>>>> 	"name": "foo",
>>>>>>>>>>>> 	"age" : 30
>>>>>>>>>>>> }
>>>>>>>>>>>> 
>>>>>>>>>>>> These two features would have solved almost
all minification
>>>>>>>>>>>> issues
>>>>>>>>>>>> I’ve
>>>>>>>>>>>> run into.
>>>>>>>>>>>> 
>>>>>>>>>>>> I’d love to work on this myself, but I’m
still not up to making
>>>>>>>>>>>> any
>>>>>>>>>>>> major
>>>>>>>>>>>> changes to the compiler… :-(
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Feb 5, 2018, at 6:13 PM, Alex Harui
>>>>>>>>>>>>> <aharui@adobe.com.INVALID <mailto:aharui@adobe.com.INVALID>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>>>> <mailto:harbs.lists@gmail.com>>
wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I’ll try to work on this. It’s
pretty slow loading the debug
>>>>>>>>>>>>>> build.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I still maintain there should be
a compiler setting or
>>>>>>>>>>>>>> language
>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>> to prevent objects produced from
JSON being destroyed on
>>>>>>>>>>>>>> minification.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> JSON Objects are not destroyed.  The
code referencing their
>>>>>>>>>>>>> fields
>>>>>>>>>>>>> by
>>>>>>>>>>>>> name
>>>>>>>>>>>>> has those names changed.  Propose a way
to determine that a
>>>>>>>>>>>>> data
>>>>>>>>>>>>> structure
>>>>>>>>>>>>> is external and what the compiler should
generate and
>>>>>>>>>>>>> implement
>>>>>>>>>>>>> it.
>>>>>>>>>>>>> IMO,
>>>>>>>>>>>>> the answer is to create ValueObjects.
 That is essentially
>>>>>>>>>>>>> typedefs
>>>>>>>>>>>>> and
>>>>>>>>>>>>> AFAIK, there is no way to automate typedef
generation.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Also, you can turn off minification for
the app as a whole.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Other ideas welcome,
>>>>>>>>>>>>> -Alex
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> This remains a pain point for developing
apps and having to
>>>>>>>>>>>>>> create
>>>>>>>>>>>>>> VOs
>>>>>>>>>>>>>> for every API is a drag.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Feb 5, 2018, at 10:21 AM,
Alex Harui
>>>>>>>>>>>>>>> <aharui@adobe.com.INVALID
<mailto:aharui@adobe.com.INVALID>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs"
<harbs.lists@gmail.com
>>>>>>>>>>>>>>> <mailto:harbs.lists@gmail.com>>
wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Typo. I meant js-reease.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Yeah, at some later point in
time someone should build Value
>>>>>>>>>>>>>>> Objects
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> the JSON and get js-release working.
 Maybe after this
>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>> trying to make the ASDoc useful.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I'm going to add Events to the
class detail page and anchor
>>>>>>>>>>>>>>> links
>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> lists to the details and maybe
a simple search-for-class
>>>>>>>>>>>>>>> feature,
>>>>>>>>>>>>>>> then I
>>>>>>>>>>>>>>> think it will be time for a release.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> -Alex
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Feb 4, 2018, at 8:08
AM, Alex Harui
>>>>>>>>>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>>>>>>>> <mailto:aharui@adobe.com.INVALID>>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 1. Why is bin-release
not working?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Mime
View raw message