Ok Gordon,
I think I understand what you are saying, you want include files that
completely configure the target without the compc task so it can be
loaded from other clients.
This is to be commited when changed in the develop branch.
I will ask more questions if needed tomorrow as it sounds like that is
your Apache work day.
Thanks for all your answers today it has been appreciated.
Mike
Quoting Gordon Smith <gosm...@adobe.com>:
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:apa...@teotigraphix.com]
Sent: Thursday, October 18, 2012 3:49 PM
To: flex-dev@incubator.apache.org
Subject: RE: ASC 2.0 and Falcon
Quoting Gordon Smith <gosm...@adobe.com>:
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:apa...@teotigraphix.com]
Sent: Thursday, October 18, 2012 3:25 PM
To: flex-dev@incubator.apache.org
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 <gosm...@adobe.com>:
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:timb...@adobe.com]
Sent: Thursday, October 18, 2012 3:16 PM
To: flex-dev@incubator.apache.org
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" <bigosma...@gmail.com> 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
<apa...@teotigraphix.com>wrote:
Quoting Thibault Imbert <timb...@adobe.com>:
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, "labri...@digitalprimates.net"
<labri...@digitalprimates.net> 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
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
