> Could you quickly elaborate on the "convert the <compc> tags" part for me?
Each project in sdk/trunk/frameworks/projects builds a SWC. For example, look
at the build.xml file inside sdk/trunk/frameworks/projects/framework, which
builds framework.swc. Its "compile" target has the <compc> task
<compc fork="true"
output="${FLEX_HOME}/frameworks/libs/framework.swc"
resource-bundle-list="${basedir}/bundles.properties">
<jvmarg line="${compc.jvm.args}"/>
<target-player>11.1</target-player>
<namespace uri="library://ns.adobe.com/flex/mx"
manifest="${basedir}/manifest.xml"/>
<namespace uri="http://www.adobe.com/2006/mxml";
manifest="${basedir}/manifest.xml"/>
<include-namespaces
uri="library://ns.adobe.com/flex/mx"/>
<include-classes>FrameworkClasses</include-classes>
<source-path path-element="${basedir}/src"/>
<library-path/>
<external-library-path dir="${FLEX_HOME}/frameworks/libs">
<include name="textLayout.swc"/>
</external-library-path>
<external-library-path dir="${env.PLAYERGLOBAL_HOME}">
<include name="${playerglobal.version}/playerglobal.swc"/>
</external-library-path>
<load-config filename="${FLEX_HOME}/frameworks/flex-config.xml"/>
<load-config filename="framework-config.xml"/>
<include-file name="defaults.css"
path="${basedir}/defaults.css"/>
<include-file name="defaults-3.0.0.css"
path="${basedir}/defaults-3.0.0.css"/>
<include-file name="Assets.swf"
path="${basedir}/assets/Assets.swf"/>
<include-file name="assets/CalendarIcon.png"
path="${basedir}/assets/CalendarIcon.png"/>
<locale/>
<accessible>true</accessible>
<keep-as3-metadata name="Bindable"/>
<keep-as3-metadata name="Managed"/>
<keep-as3-metadata name="ChangeEvent"/>
<keep-as3-metadata name="NonCommittingChangeEvent"/>
<keep-as3-metadata name="Transient"/>
</compc>
I want it to look instead like
<compc fork="true" load-config="framework-config.xml"/>
where you write the framework-config.xml file using the syntax in files like
flex-config.xml.
The difficulty is that the syntax for the XML you put inside the
framework-config.xml file is different in various ways from the XML tags inside
the <compc> tag (for one thing, XML config files don't use attributes) so the
conversion isn't always obvious.
I want the "compile" target for every project in the projects directory to use
a config file for its compilation options.
Then you or I can write JUnit tests that use Falcon to compile each SWC by
invoking Falcon with this config file.
- Gordon
-----Original Message-----
From: Michael Schmalle [mailto:[email protected]]
Sent: Thursday, October 18, 2012 3:49 PM
To: [email protected]
Subject: RE: ASC 2.0 and Falcon
Quoting Gordon Smith <[email protected]>:
>> Gordon I can help with MXML once I get my feet wet in understanding
>> exactly "What" needs to be implemented.
>
> Tomorrow I'll be working on eliminating the falcon/sdk directory,
> since this violates Apache rules.
>
> Next week I'll check in the first few MXML parser tests for simple
> tags like <Boolean> and <int>. At that point the pattern to follow for
> MXML parser tests will be clear.
>
I can help with further tests after this.
>
> - Gordon
Ok, I understand and replied in my previous email that I realize MXML is #1
priority. I will be working on this sooner than later as I see what you do.
> In the meantime, you could learn XML config file syntax and convert
> the <compc> tags.
I experimented with the config when I was porting my asdoc program that
extended mxmlc.
Could you quickly elaborate on the "convert the <compc> tags" part for me?
Mike
>
> -----Original Message-----
> From: Michael Schmalle [mailto:[email protected]]
> Sent: Thursday, October 18, 2012 3:25 PM
> To: [email protected]
> Subject: RE: ASC 2.0 and Falcon
>
> So in essence you are saying;
>
> 1. Gordon needs help implementing MXML.
> 2. Flex is incompatible with the new VM that is stage3D based and a
> new architecture for components needs to be created based on Stage3D.
> 3. The ASC compiler of Falcon is going to need to be implemented to
> produce bytecode that is compatible with the new AVM.
>
>
> Correct?
>
>
> Gordon I can help with MXML once I get my feet wet in understanding
> exactly "What" needs to be implemented.
>
>
> Mike
>
> Quoting Gordon Smith <[email protected]>:
>
>> Furthermore, the new runtime uses new bytecode that the Falcon
>> compiler does not produce, and the new compiler that does produce it
>> doesn't compile MXML.
>>
>> - Gordon
>>
>> -----Original Message-----
>> From: Thibault Imbert [mailto:[email protected]]
>> Sent: Thursday, October 18, 2012 3:16 PM
>> To: [email protected]
>> Subject: Re: ASC 2.0 and Falcon
>>
>> Hi Om,
>>
>> The rendering architecture of the new runtime is Stage3D only. So
>> essentially, there is not "native" DisplayObject.
>> So your framework needs to leverage Stage3D, just like iOS is
>> leveraging OpenGL for their components UI.
>>
>> That's why we have been funding Starling to help people transition to
>> a full Stage3D model. Recently, the community has created a drawing
>> API extension for Starling: http://www.bytearray.org/?p=4832 and a few
>> weeks back a skeleton bones extension was also created to create
>> complex animations on top of Starling:
>> https://github.com/DragonBones/SkeletonAnimationFramework. All of that
>> is open source, you can fork it, create extensions, etc.
>>
>> Feathers is the right model and approach, lightweight UI framework on
>> top of Starling (which does all the Stage3D work behind the scenes).
>>
>> Keep in mind Feathers "vision" is not to replace Flex, it is a
>> lightweight UI framework for Uis in games, developed by a Flex
>> developer who wanted to have some of the power of Flex (skinning,
>> productivity) without reproducing the same mistakes as Flex (lots of
>> dependencies and display list based).
>>
>> Thibault Imbert | sr. product manager gaming (Graphics, Language, VM,
>> Compiler) | Monocle | adobe systems
>> gaming.adobe.com <http://gaming.adobe.com/> | bytearray.org
>> <http://bytearray.org/> | @thibault_imbert
>>
>>
>>
>>
>>
>>
>> On 10/18/12 3:01 PM, "Om" <[email protected]> wrote:
>>
>>>>
>>>> Just a heads up, given the architecture changes of the next-gen
>>>> runtime, Flex will not be able to run in it. I would "highly"
>>>> recommend you guys having a look at Feathers (work from Josh
>>>> Tynjala
>>>> - feathersui.com) on top of Starling, which will run beautifully in
>>>> our next runtime.
>>>
>>>
>>> Could you please give us some technical details as to why Flex wont
>>> be able to run in the new runtime? This would help us figure out
>>> what we can/need to do given where we are currently.
>>>
>>> Of course, any other information you can provide to help us move Flex
>>> towards Stage3D/Starling would be beneficial.
>>>
>>> Thanks,
>>> Om
>>>
>>>
>>> On Thu, Oct 18, 2012 at 2:55 PM, Michael Schmalle
>>> <[email protected]>wrote:
>>>
>>>> Quoting Thibault Imbert <[email protected]>:
>>>>
>>>> Hi Mike,
>>>>>
>>>>> This is true, but ASC is already moving to ASNext targeting the
>>>>> next generation runtime which is targeting game developers. So our
>>>>> resources are assigned to that and the time we have to take ASC
>>>>> 2.0 changes to Falcon, are limited. Gordon will bring
>>>>> key/showstopper bugs fixed in ASC
>>>>> 2.0 to Falcon, we cannot commit to anything more.
>>>>>
>>>>> Just a heads up, given the architecture changes of the next-gen
>>>>> runtime, Flex will not be able to run in it. I would "highly"
>>>>> recommend you guys having a look at Feathers (work from Josh
>>>>> Tynjala
>>>>> - feathersui.com) on top of Starling, which will run beautifully
>>>>> in our next runtime.
>>>>>
>>>>
>>>> I have just started working with Josh and this component
>>>> architecture, it is very nice. I spoke of feathers earlier today
>>>> and was talking with Josh about MXML support.
>>>>
>>>> So your saying there needs to be a component framework developed
>>>> that will run in the new architecture to be cross compatible? I
>>>> don't quite understand what you are saying.
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>>
>>>> Some videos:
>>>>>
>>>>> https://vimeo.com/51010861
>>>>>
>>>>> http://www.youtube.com/watch?**v=DGRy7H17MkA&feature=youtu.**be&hd=
>>>>> 1< htt
>>>>> p://www.youtube.com/watch?v=DGRy7H17MkA&feature=youtu.be&hd=1>
>>>>>
>>>>>
>>>>> Thibault Imbert | sr. product manager gaming (Graphics, Language,
>>>>> VM,
>>>>> Compiler) | Monocle | adobe systems gaming.adobe.com
>>>>> <http://gaming.adobe.com/> | bytearray.org <http://bytearray.org/>
>>>>> | @thibault_imbert
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 10/18/12 11:36 AM, "[email protected]"
>>>>> <[email protected]> wrote:
>>>>>
>>>>> We have no plans keeping ASC 2.0 (and above) in sync with Falcon,
>>>>> as I
>>>>>>> said previously, today the compilers are different projects and
>>>>>>> targeting two different audiences.
>>>>>>>
>>>>>>
>>>>>> Yeh, we totally get why parsing the AS language and generating
>>>>>> bytecode will be very different for the game market. I can't
>>>>>> imagine the amount of time you guys are spending on the
>>>>>> differences in for loops alone....
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>> --
>>>> Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com
>>>> http://blog.teotigraphix.com
>>>>
>>>>
>>
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
