Here:
http://apache-flex-development.247.n4.nabble.com/Node-js-support-td50414.html
Or here: http://mail-archives.apache.org/mod_mbox/flex-dev/201512.mbox/browser
The Flex website has links to the archives here:
http://flex.apache.org/community-mailinglists.html
On Dec 3, 2015, at 11:02 AM
This mailing list is mirrored as a Nabble user forum. Sometimes folks post
from the Nabble forum directly, which comes with a link in the footer.
To access the forum, simply go to this url: s.apache.org/flex-dev-forum
You should see all the recent threads there.
Thanks,
Om
P.S. The users@ for
Sorry to interject but how do I get a link to this thread? I've seen them
in footers before but not this one.
On Wed, Dec 2, 2015 at 3:29 PM, Josh Tynjala wrote:
> Got it. So if I were trying to hide a require() call, @flexjsignorecoercion
> could be used in my code without requiring users to do
Got it. So if I were trying to hide a require() call, @flexjsignorecoercion
could be used in my code without requiring users to do anything. I think I
may be able to work with that. I'll play around with it, when I have a
moment.
- Josh
On Wed, Dec 2, 2015 at 3:10 PM, Alex Harui wrote:
> Curren
Currently it works at the method's ASDoc, not at the class level.
Here's an excerpt:
/**
* @flexjsignorecoercion org.apache.flex.core.WrappedHTMLElement
* @flexjsignorecoercion HTMLBodyElement
*/
COMPILE::JS
override public function star
Interesting... I didn't know about that. How would @flexjsignorecoercion be
used? In the asdocs for a class, like this?
/**
* @flexjsignorecoercion
*/
public class MyClass {}
If I'm understanding your correctly, when using this tag, the JS output
would not pass the value to Language.as()?
//as
On 12/2/15, 2:37 PM, "Josh Tynjala" wrote:
>Oh, I see. I didn't realize that you were thinking that users would import
>something and also manually call require(). In that case, yes, you could
>still potentially have proper type checking.
>
>I like the idea of using some kind of wrapper class t
Oh, I see. I didn't realize that you were thinking that users would import
something and also manually call require(). In that case, yes, you could
still potentially have proper type checking.
I like the idea of using some kind of wrapper class to hide the require()
call. It's kind of messy to bot
On 12/2/15, 12:12 PM, "Josh Tynjala" wrote:
>You'd lose out on compiler checks and IDE code hinting if you had to call
>require() directly in AS.
I probably don't know enough about Node and require to understand that.
Let's try looking at source code patterns first. My quick read of require
is
You'd lose out on compiler checks and IDE code hinting if you had to call
require() directly in AS.
Wrapping the generated JS for a class in an IIFE, like I talked about in an
earlier thread, could keep the requires confined to a single class.
(function()
{
var fs = require("fs");
//the f
I read up a bit on Node's require system. It seems that because import
statements in AS are generally at the package level, it wouldn't be a good
equivalent for Node's require. I think Node's require system is an
explicit class/package loader like Java's and allows you to defer the
loading of cod
Node.js has its own require system. It's called CommonJS.
I was thinking that it could also be based on imported classes. It can be a
little tricky, though. A module is pretty flexible with what it exports.
Most simply, a module could export a single class. In this case, the
translation is pretty
On 12/2/15, 9:59 AM, "Josh Tynjala" wrote:
>The require() call for a Node.js module should probably be generated in
>the
>PackageHeaderEmitter, where the goog.require() calls are generated.
OK, but based on what kind of source code lines? The goog.requires are
generated from import statements
The require() call for a Node.js module should probably be generated in the
PackageHeaderEmitter, where the goog.require() calls are generated.
- Josh
On Tue, Dec 1, 2015 at 5:47 PM, Alex Harui wrote:
>
>
> On 12/1/15, 5:06 PM, "Josh Tynjala" wrote:
> >
> >I thought you meant that you were wor
I think this is a must, since is the way devs out there work with JS...all
is "npm"-able ;)
So, thanks Om to start the work with this, this should be a great addition
:)
2015-12-02 1:29 GMT+01:00 OmPrakash Muppirala :
> My first goal is to mimic the Installer to get all the required
> dependencie
I’m really interested in seeing Node.js transpiling as well. ActionScript on
the server with support for the whole Node.js eco-system would be a real win
and open lots of doors.
On Dec 2, 2015, at 3:06 AM, Josh Tynjala wrote:
> Oh, I see! I was confused. I now recall seeing that you were worki
On 12/1/15, 5:06 PM, "Josh Tynjala" wrote:
>
>I thought you meant that you were working on the compiler to add support
>for Node.js modules. Getting the compiler to output good code for running
>on Node.js is something that I hope to work on soon.
>
>For those not familiar, Node.js modules are r
Oh boy, I wish I had started the FlexJS NPM module after you finished your
Node.js support via AS3 :-D
Thanks for the tips. I had it in my TODOs to look at your npm dts2as
utility. I will ping you when I get to the actual compilation of AS3 files
via node part, hopefully soon.
I might need some
Oh, I see! I was confused. I now recall seeing that you were working on
getting FlexJS into NPM.
I thought you meant that you were working on the compiler to add support
for Node.js modules. Getting the compiler to output good code for running
on Node.js is something that I hope to work on soon.
My first goal is to mimic the Installer to get all the required
dependencies (AIR, FlashPlayerGlobal.swc, Falcon, Google Closure etc.) The
problem here is that except for Google Closure, nothing else is available
as a require dependency from npm. And Adobe AIR and Adobe
FlashPlayerGlobal.swc need
20 matches
Mail list logo
