Rudeness and frustrations aside, in the light of desiring an
html/javascript flex SDK and taking into respect the timeline for a flex
(cross?)-compiler there really is only three options on the table:
1) Wait for falcon, projected stable release late 2012, early 2013. It is
both hopeful and debata
On Feb 19, 2012, at 6:39 PM, Greg Reddin wrote:
>
>
> Sent from my mobile device.
>
> On Feb 19, 2012, at 5:20 PM, David Arno wrote:
>
>> Otherwise he can go boil
>> his head for all I care.
>
> That kind of talk has no place here and it needs to stop immediately.
I was looking to say sim
On 2/19/12 2:09 PM, "David Arno" wrote:
> The first rule of Apache is that if it doesn't happen here, it doesn't
> happen. Therefore either you are working on ideas that could help us
> better compile MXML code, which you are about to share with us
> imminently, or what you are working on is o
On 2/19/12 2:08 PM, "Michael A. Labriola"
wrote:
>> Alex, one question. Will Falcon still generate a function per tag? So far,
>> this was the most... controversial... feature of MXMLC... well, "most" is
>> subjective :)
>
> My personal hope is that it is encoded to a data structure and we on
I've been maintaining this site, http://www.actionscripterrors.com, for a
few years now and I think with a community growing here I'd like to donate
it (or add editor accounts to members on here). At one point I had worked
with a few developers to add all the runtime and design time errors and
warn
Thanks. I haven't seen that before. It looks sharp.
On Sun, Feb 19, 2012 at 10:48 AM, Roland Zwaga wrote:
> >
> > What I've been thinking if it isn't obvious is creating an open source
> > project(s). There's would be two parts to this.
> >
> > 1. An abstract eclipse like integrated environment (
Sent from my mobile device.
On Feb 19, 2012, at 5:20 PM, David Arno wrote:
> Otherwise he can go boil
> his head for all I care.
That kind of talk has no place here and it needs to stop immediately.
David, if your objective is to annoy him so much that he rushes to finish the
code so he no longer has to deal with ridiculousness like yours, well done. No
other explanation justifies that sort of response.
Alex, I'm sure the decisions that Adobe has made recently have affected you as
much if
On Mon, 2012-02-20 at 01:35 +0200, Left Right wrote:
> David, I used Metaas, and I know that grammar file... it's well, it's
> wrong, and it doesn't reflect many things that happened since FP10 (Metaas
> project was abandoned before FP10 was released, so, no handling for
> vectors, for example, but
C++ has a sore taste of many completely different people trying to cook one
dish, so one thought it was soup, another thought it was a pancake, yet
another one thought it was meant to poison the dictator of her country...
Oh, some times it's good to look into the Wiki before you post stuff, yeah,
2012/2/20 Left Right
> Following the series of successful personal insults...
> I kind of like your reaction to the language choice... sort of Homer
> Simpson answer, sorry :)
> There is no correspondence between the time the language was invented, and
> how wisely it was designed. COBOL and Java
>David's language is harsh, perhaps not well suited for email discussions (or
>any discussion for that matter) and not productive in building community.
>But his point is well taken. Hinting at solutions to problems, but not
>actually revealing them to the group, feels like delaying progress, fee
>> Seriously?
>Yes, really seriously.
David's language is harsh, perhaps not well suited for email discussions (or
any discussion for that matter) and not productive in building community.
But his point is well taken. Hinting at solutions to problems, but not actually
revealing them to the gro
David, I used Metaas, and I know that grammar file... it's well, it's
wrong, and it doesn't reflect many things that happened since FP10 (Metaas
project was abandoned before FP10 was released, so, no handling for
vectors, for example, but not only that, it really is an oversimplification
of AS3 syn
On Sun, 2012-02-19 at 23:03 +, Michael A. Labriola wrote:
> >Dear Alex,
> >
> >The first rule of Apache is that if it doesn't happen here, it doesn't
> >happen. Therefore either you are working on ideas that could help us better
> >compile MXML code, which you are about to share with us immi
>>Dear Alex,
>>
>>The first rule of Apache is that if it doesn't happen here, it doesn't
>>happen. Therefore either you are working on ideas that could help us better
>>compile MXML code, which you are about to share with us imminently, >or what
>>you are working on is of no interest to the Apac
On Sun, Feb 19, 2012 at 11:27 PM, David Arno wrote:
> When I looked into the idea of us simply porting Flex to haXe to solve
> the JavaScript-target issues, what you describe was one of the killer
> issues that made haXe a no-go.
>
> haXe doesn't do anything clever to target the DOM and
> JavaScr
>Dear Alex,
>
>The first rule of Apache is that if it doesn't happen here, it doesn't happen.
>Therefore either you are working on ideas that could help us better compile
>MXML code, which you are about to share with us imminently, >or what you are
>working on is of no interest to the Apache Fl
Svg rendering is probably used for vector drawing.
19-02-2012 23:35 użytkownik "Justin Mclean"
napisał:
> Hi,
>
> > Therefore I think with Flex our only choice is to do the complete
> > opposite of haXe and to write JavaScript-specific renderers to replace
> > all the skin classes in Flex. That i
Hi,
> Therefore I think with Flex our only choice is to do the complete
> opposite of haXe and to write JavaScript-specific renderers to replace
> all the skin classes in Flex. That is the only way we can hope to get
> good performance.
Does anyone know what approach FalconJS is taking? Would be u
On Sun, 2012-02-19 at 23:19 +0100, Niel Drummond wrote:
> I don't recommend the approach of writing a separate javascript layer -
> haxe has the concept of "untyped" code blocks, and a special Dynamic type,
> which is extremely useful at getting around browser incompatibilities (I
> think GWT has s
On Fri, 2012-02-17 at 10:25 +0100, Roland Zwaga wrote:
> By the way,
>
> here is the Java port of the goldparser engine:
>
> https://github.com/ridencww/goldengine
>
> it might be an idea to try out both ANTLR and goldparser
> and compare the results, I'd say the fastest one we'd take ;)
How abo
On Sun, Feb 19, 2012 at 10:46 PM, David Arno wrote:
> We can't use something like LLVM though as we are not simply creating a
> language compiler: we are creating a framework compiler. We can't just
> compiler AS3 code to JavaScript, for we need to handle rendering in a
> language-specific fashio
On Sun, 2012-02-19 at 11:50 -0800, Alex Harui wrote:
> Yes, we agree on that point. The Spark code was much faster than the MXML
> descriptor tree, but I have a new proposed "descriptor" that is testing out
> to be just as fast as the Spark code so I think we'll go with something like
> that when
>Alex, one question. Will Falcon still generate a function per tag? So far,
>this was the most... controversial... feature of MXMLC... well, "most" is
>subjective :)
My personal hope is that it is encoded to a data structure and we only see a
single function as a hook to retrieve that structure
On Sun, 2012-02-19 at 14:03 +0200, Left Right wrote:
> Languages: I thought I argued my case, but I'll try to explain again, the
> plugins and the "mothership" compiler need not to run inside the same
> runtime - there is a traditional way to make programs cooperate - pipes,
> stream, well, you kno
On Sat, 2012-02-18 at 21:48 +0200, Left Right wrote:
> First of all. Why Java (JVM)?
The JVM gives us many advantages:
1. Java - which whilst long in the tooth is well known and well
supported and - a point that is difficult to overstate - its the
language that Flash Builder and FDT and IntelliJ ar
Alex, one question. Will Falcon still generate a function per tag? So far,
this was the most... controversial... feature of MXMLC... well, "most" is
subjective :)
Martin, yup, Oleg, but wvxvw has been used for a long while :)
On 2/19/12 11:46 AM, "Michael A. Labriola"
wrote:
> Sure, that is fine. My larger point is that I do not believe MXML should
> directly translate into object instantiation and configuration so much as
> description of the declared objects. Descriptions can be modified,
> instantiations are muc
>Well, even the descriptors have to be described in bytecode, and Falcon goes
>straight to the equivalent bytecode instead of an intermediate step of
>generated AS.
>I implemented a new descriptor system for both MX and Spark components in
>Falcon, but it needs vetting and testing.
Sure, that i
On 2/19/12 9:39 AM, "Michael A. Labriola"
wrote:
>> I believe Gordon Smith said in one of the email threads that the new compiler
>> is no longer generating ActionScript 3 from the MXML files but converting
>> directly to bytecode. I would imagine this is the preferred >approach, no? I
>> have
>I believe Gordon Smith said in one of the email threads that the new compiler
>is no longer generating ActionScript 3 from the MXML files but converting
>directly to bytecode. I would imagine this is the preferred >approach, no? I
>haven't done any compiler dev myself, yet... but I'm eager to l
On Sun, Feb 19, 2012 at 9:20 AM, Michael A. Labriola <
labri...@digitalprimates.net> wrote:
> >I am starting to understand what he is pointing out as the shortcomings
> of mxml as implemented, I remember noticing these when first starting out
> but forgot as I focused on using what was available.
>I am starting to understand what he is pointing out as the shortcomings of
>mxml as implemented, I remember noticing these when first starting out but
>forgot as I focused on using what was available.
Personally, I don't have a problem with MXML. I have a problem with what the
compiler does wi
I like this mysterious person. :)
I am starting to understand what he is pointing out as the shortcomings of mxml
as implemented, I remember noticing these when first starting out but forgot as
I focused on using what was available.
And i agree about language choice, using the best language for
>
> What I've been thinking if it isn't obvious is creating an open source
> project(s). There's would be two parts to this.
>
> 1. An abstract eclipse like integrated environment (project)
> 2. A designer / developer workflow (project)
>
> The first would be built to support the second.
>
> The se
What I've been thinking if it isn't obvious is creating an open source
project(s). There's would be two parts to this.
1. An abstract eclipse like integrated environment (project)
2. A designer / developer workflow (project)
The first would be built to support the second.
The second would be cre
Hello Oleg (?),
Emotion aside. I think the results count: Scala is fast and works well.
In some ways faster than Java. [1]
From my short research I agree that Groovy is out of the game - in
terms of performance.
But again: It doesn't really matter what language you use: Fast
applications are w
Martin,
My personal problem with languages like Scala or Groovy is that a lot is
lost in translation. They, pretty much like HaXe had chosen JVM because it
is popular, no other particular reason. But, if you write in them, you
create a dependency on dependency to dependency, and that just feels wr
Roland:
At the time I did some poking around MXML parser and code generation, I
can't claim myself to be an expert on the issue, but I know some. So,
here's my view of the situation: you say it works in Intellij, I say it's
pretty much broken. Here's why: possibly, you only used the features you
en
First: Your discussion is about a different topic, so please change the
subject if the discussion changes.
On 19/02/2012 19:22, almansour belleh blanco wrote:
So basically, we are going to choose extensibility over performance?
I think its a little shortsighted to do even this simplification.
>
> So basically, we are going to choose extensibility over performance?
>
We'd have to investigate how much performance difference there is, if its a
matter of seconds then yes,
I think its a good balance between performance and usability. If
And as I pointed out, it might be an option to write c
2012/2/19 Roland Zwaga :
>>
>> First of all. Why Java (JVM)? Why use this piece of corporative neo-COBOL
>> invented for the sole purpose of allowing cheap labor force to further
>> bloat the bloatware? For once you have the full carte blanche to start
>> anew, and you choose nearest to worst optio
>
> First of all. Why Java (JVM)? Why use this piece of corporative neo-COBOL
> invented for the sole purpose of allowing cheap labor force to further
> bloat the bloatware? For once you have the full carte blanche to start
> anew, and you choose nearest to worst option? Compiler is unlikely to dri
>
> >Can we just make the build script download the required compilers, etc?
> The issue is basically hosting in our repo and redistributing if the
> license is not compatible so that should solve our problem right?
>
> With Spoon, we basically had people downloading the Adobe SDK, overlaying
> our
I like mxml, don't mind copying datagridcolumn in exchange for the readability,
and thought fxg was a brilliant concept.
Why _do_ we need to use java? Will other languages be as easy to integrate into
IDEs?
I sort of agree on the JavaScript thing. Outputting to an intermediate language
seems l
46 matches
Mail list logo
