If you need access to global in Core, then yes, you should add node.swc.
The value of -targets does not determine which SWCs are included. It only
determines how the compiler generates the JavaScript. You should probably
continue to use JSFlex, but you should manually add node.swc to the
project's external-library-path. node.swc is only automatically included
when using the js/bin/asnodec compiler, which sets +configname=node and
that causes the compiler to load node-config.xml instead of the default
flex-config.xml.
Note that I'm not saying that you should try to use node-config.xml. I'm
just filling in some details on why changing -targets to JSNode didn't
work. You should add node.swc to the -external-library-path in the
project's compiler options.
- Josh
On Thu, Jul 13, 2017 at 10:04 AM, Harbs <harbs.li...@gmail.com> wrote:
> Are you saying we should add node.swc to Core?
>
> FWIW, I just tried setting targets to JSNode and global is still not
> recognized. node.swc does not seem to be used even when that’s the target.
> That does not seem right either.
>
> > On Jul 13, 2017, at 7:42 PM, Josh Tynjala <joshtynj...@gmail.com> wrote:
> >
> > I think the correct solution is to add node.swc to the
> > -external-library-path when you need access to global. You need js.swc on
> > the -external-library-path when you want to access window. You can't use
> > window in a SWF-only project, for instance.
> >
> > - Josh
> >
> > On Thu, Jul 13, 2017 at 9:29 AM, Harbs <harbs.li...@gmail.com> wrote:
> >
> >> There is a mention of window in the NativeJSType enums. Not sure why
> it’s
> >> needed there.
> >>
> >> global should already be in node.js (I think). I’m pretty sure it’s
> >> defined in the node typedefs
> >>
> >> I don’t really care how it’s achieved, but by default (without doing any
> >> special imports) global should be recognized. (just like window is)
> >>
> >> Right now, typing global into a FlexJS project targeting “JSFlex” or any
> >> one of the framework projects results in a compiler error. How do we fix
> >> that?
> >>
> >>> On Jul 13, 2017, at 7:17 PM, Alex Harui <aha...@adobe.com.INVALID>
> >> wrote:
> >>>
> >>> IIRC, the compiler doesn't special case handling of that code.
> "window"
> >>> is defined in missing.js so the js.swc knows there is such an entity.
> Is
> >>> there any reason not to add a "global" to node.swc?
> >>>
> >>> -Alex
> >>>
> >>> On 7/13/17, 12:29 AM, "Harbs" <harbs.li...@gmail.com> wrote:
> >>>
> >>>> Right now, if you have code that looks like this, the compiler will
> >>>> report and error and it will fail:
> >>>>
> >>>> global[“foo”];
> >>>>
> >>>> I would like for that to be legal code in a COMPILE::JS block and it
> >>>> should compile to:
> >>>>
> >>>> global[“foo”];
> >>>>
> >>>> Exactly the same as window:
> >>>>
> >>>> If you write:
> >>>> window[“foo”];
> >>>>
> >>>> It’s legal code and will compile to:
> >>>> window[“foo”];
> >>>>
> >>>> That’s it.
> >>>>
> >>>>> On Jul 13, 2017, at 10:18 AM, Alex Harui <aha...@adobe.com.INVALID>
> >>>>> wrote:
> >>>>>
> >>>>> I'm still not clear what changes are needed.
> >>>>>
> >>>>> Are you trying to access APIs that are global but not defined in
> JS.SWC
> >>>>> or
> >>>>> Node.SWC? Otherwise, the APIs on window/global should be defined in
> >>>>> those
> >>>>> SWCs.
> >>>>>
> >>>>> I'm not sure what the test case is supposed to look like.
> >>>>>
> >>>>> Thanks,
> >>>>> -Alex
> >>>>>
> >>>>> On 7/13/17, 12:11 AM, "Harbs" <harbs.li...@gmail.com> wrote:
> >>>>>
> >>>>>> Electron has both window and global. Node has global and no window.
> I
> >>>>>> think CEF has window and no global. Browsers have window but not
> >>>>>> global.
> >>>>>> Depending on which environment you are writing for, you’re going to
> >>>>>> need
> >>>>>> either window or global for accessing global variables.
> >>>>>>
> >>>>>> I’m more concerned with general global access in Node than my
> specific
> >>>>>> use case. If general global access works, then that gives a solution
> >>>>>> for
> >>>>>> my specific case as well as an other arbitrary one where you’d use
> >>>>>> window
> >>>>>> in the browser.
> >>>>>>
> >>>>>> I think it’s fine to cross compile global[“foo”] to the exact same
> >>>>>> global[“foo”] in JS. In other words, the compiler should accept
> global
> >>>>>> with bracket notation and pass it through unchanged.
> >>>>>>
> >>>>>>> On Jul 13, 2017, at 9:33 AM, Alex Harui <aha...@adobe.com.INVALID>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> I think the only thing the compiler does with "window" is allow you
> >> to
> >>>>>>> use
> >>>>>>> "window" to disambiguate between a "global" API and another API in
> a
> >>>>>>> package with the same name.
> >>>>>>>
> >>>>>>> And then the JS.SWC typedefs specify certain APIs.
> >>>>>>>
> >>>>>>> AIUI, Electron is another runtime that has a window variable and
> you
> >>>>>>> want
> >>>>>>> to detect the difference between Browser, Node and Electron? Or
> are
> >>>>>>> you
> >>>>>>> willing to just try to check for features instead?
> >>>>>>>
> >>>>>>> If you can show what JS code you'd want to end up with we can look
> >>>>>>> into
> >>>>>>> changing the compiler so you can write AS to generate that JS.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> -Alex
> >>>>>>>
> >>>>>>> On 7/12/17, 9:03 PM, "Harbs" <harbs.li...@gmail.com> wrote:
> >>>>>>>
> >>>>>>>> What do we currently do with window?
> >>>>>>>>
> >>>>>>>> global in Node is the same as window in the browser. All global
> >>>>>>>> variables
> >>>>>>>> are attached to the global object.
> >>>>>>>>
> >>>>>>>> global[“foo”] could compile to global[“foo”], global.foo, or just
> >>>>>>>> plain
> >>>>>>>> foo, and it all means the same thing.
> >>>>>>>>
> >>>>>>>>> On Jul 13, 2017, at 2:14 AM, Alex Harui <aha...@adobe.com.INVALID
> >
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> What AS do you want to write and what JS do you want as output?
> >>>>>>>>>
> >>>>>>>>> -Alex
> >>>>>>>>>
> >>>>>>>>> On 7/9/17, 12:53 AM, "Harbs" <harbs.li...@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> Checking for window will work for Node, but it will not work for
> >>>>>>>>>> Electron.
> >>>>>>>>>>
> >>>>>>>>>> I tried adding global to Falcon, but I was obviously going about
> >> it
> >>>>>>>>>> wrong, because what I tried did not work.
> >>>>>>>>>>
> >>>>>>>>>> This is not really high priority for me right now, so I’m moving
> >> on
> >>>>>>>>>> to
> >>>>>>>>>> something else…
> >>>>>>>>>>
> >>>>>>>>>>> On Jul 6, 2017, at 3:05 AM, Alex Harui
> <aha...@adobe.com.INVALID
> >>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> I've noticed lots of advice on the internet to use feature
> >>>>>>>>>>> detection
> >>>>>>>>>>> instead of browser/runtime detection. Did you rule out doing
> >>>>>>>>>>> that?
> >>>>>>>>>>> Browsers may implement new features over time.
> >>>>>>>>>>>
> >>>>>>>>>>> But otherwise, I see some clever tests that check for "window"
> >>>>>>>>>>> and a
> >>>>>>>>>>> few
> >>>>>>>>>>> other things.
> >>>>>>>>>>>
> >>>>>>>>>>> HTH,
> >>>>>>>>>>> -Alex
> >>>>>>>>>>>
> >>>>>>>>>>> On 7/5/17, 1:54 PM, "Harbs" <harbs.li...@gmail.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> No. I was trying to use process to check whether it’s running
> in
> >>>>>>>>>>>> a
> >>>>>>>>>>>> Node
> >>>>>>>>>>>> runtime (such as Node or Electron). window does not have
> >> process.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I’m trying to add a class that lets the client know what
> >>>>>>>>>>>> environment
> >>>>>>>>>>>> it’s
> >>>>>>>>>>>> running in.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Adding global sounds like a good idea. Between window and
> >>>>>>>>>>>> global, I
> >>>>>>>>>>>> think
> >>>>>>>>>>>> that would offer a solution everywhere.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Jul 5, 2017, at 7:48 PM, Alex Harui
> >>>>>>>>>>>>> <aha...@adobe.com.INVALID>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Sure, I know it wouldn't work at runtime, but it sounded like
> >>>>>>>>>>>>> Harbs
> >>>>>>>>>>>>> couldn't even get the compiler to accept window["process"]
> >> which
> >>>>>>>>>>>>> it
> >>>>>>>>>>>>> should.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So, it should be ok to write:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> if(typeof window !== "undefined")
> >>>>>>>>>>>>> {
> >>>>>>>>>>>>> theProcess = window["process"];
> >>>>>>>>>>>>> }
> >>>>>>>>>>>>> else
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> theProcess = global.process
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> But is there really a process property in the browser?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> We could create or own single variable if we want. How often
> >> do
> >>>>>>>>>>>>> libraries
> >>>>>>>>>>>>> need stuff in window/global? Classes that need it should be
> >>>>>>>>>>>>> able
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>> use
> >>>>>>>>>>>>> inject_html and run some JS that maps window to global or the
> >>>>>>>>>>>>> other
> >>>>>>>>>>>>> way
> >>>>>>>>>>>>> around.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> HTH,
> >>>>>>>>>>>>> -Alex
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 7/5/17, 6:43 AM, "Josh Tynjala" <joshtynj...@gmail.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Node.js doesn't have a window variable, so window["process"]
> >>>>>>>>>>>>>> won't
> >>>>>>>>>>>>>> work.
> >>>>>>>>>>>>>> They have a global variable instead.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I remember reading that there is a proposal for ECMAScript
> to
> >>>>>>>>>>>>>> standardize
> >>>>>>>>>>>>>> a
> >>>>>>>>>>>>>> single variable that refers to window in the browser and
> >> global
> >>>>>>>>>>>>>> in
> >>>>>>>>>>>>>> Node.js,
> >>>>>>>>>>>>>> but that doesn't exist yet.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> - Josh
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Tue, Jul 4, 2017 at 11:35 PM, Alex Harui
> >>>>>>>>>>>>>> <aha...@adobe.com.invalid>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> What class in Core needs this dependency? I think one
> >>>>>>>>>>>>>>> drawback
> >>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>> users of that class will need to add node.swc to their
> >> project
> >>>>>>>>>>>>>>> dependencies. But I don't think every consumer of Core
> will
> >>>>>>>>>>>>>>> need
> >>>>>>>>>>>>>>> node.swc.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But first, why didn't window["process"] work? In theory
> >>>>>>>>>>>>>>> Falcon
> >>>>>>>>>>>>>>> will
> >>>>>>>>>>>>>>> let
> >>>>>>>>>>>>>>> you access anything off of window. We could also add
> global
> >>>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>> want.
> >>>>>>>>>>>>>>> Or maybe we should only allow global and have some
> bootstrap
> >>>>>>>>>>>>>>> code
> >>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>> maps global to window?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -Alex
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 7/4/17, 2:09 PM, "Harbs" <harbs.li...@gmail.com> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Actually, I see that the Node typedefs has all the process
> >>>>>>>>>>>>>>>> declarations
> >>>>>>>>>>>>>>>> in global.js.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Is there an issue with adding a dependency in CoreJS to
> >>>>>>>>>>>>>>>> node.swc?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Should a class that has this dependency go somewhere else?
> >> (I
> >>>>>>>>>>>>>>>> don’t
> >>>>>>>>>>>>>>>> really see an issue with adding the dependency, but I’m
> >>>>>>>>>>>>>>>> throwing
> >>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>> out
> >>>>>>>>>>>>>>>> in case I’m missing something.)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Harbs
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Jul 5, 2017, at 12:00 AM, Harbs <
> harbs.li...@gmail.com>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Looks like it.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I see this in missing.js:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> /**
> >>>>>>>>>>>>>>>>> * @export
> >>>>>>>>>>>>>>>>> * This gets mapped to org.apache.flex.utils.
> >> Language.trace()
> >>>>>>>>>>>>>>>>> by
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> compiler
> >>>>>>>>>>>>>>>>> * @param {...} rest
> >>>>>>>>>>>>>>>>> */
> >>>>>>>>>>>>>>>>> function trace(rest) {}
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> /**
> >>>>>>>>>>>>>>>>> * @type {!Console}
> >>>>>>>>>>>>>>>>> * @const
> >>>>>>>>>>>>>>>>> */
> >>>>>>>>>>>>>>>>> var console;
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I guess I can add another one like so:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> /**
> >>>>>>>>>>>>>>>>> * @type {!Process}
> >>>>>>>>>>>>>>>>> * @const
> >>>>>>>>>>>>>>>>> */
> >>>>>>>>>>>>>>>>> var process;
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> However, it seems like a drag to have to add a typedef
> >> every
> >>>>>>>>>>>>>>>>> time
> >>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>> developer needs to check for the existence of a global
> that
> >>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>> did
> >>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>> think of.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Jul 4, 2017, at 9:13 PM, Harbs <
> harbs.li...@gmail.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thanks. Here’s what I see:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> if(typeof window !== "undefined")
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> theConsole = window.console;
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>> else if(typeof console !== "undefined")
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> theConsole = console;
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Did you define console in a typedef maybe?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I’m thinking that Falcon should really allow undefined
> >>>>>>>>>>>>>>>>>> variables
> >>>>>>>>>>>>>>> when
> >>>>>>>>>>>>>>>>>> used with “typeof”.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Truth be told, I really need to do something like one of
> >>>>>>>>>>>>>>>>>> these:
> >>>>>>>>>>>>>>>>>> if(typeof (process) != 'undefined' &&
> >>>>>>>>>>>>>>>>>> {}.toString.call(process)
> >>>>>>>>>>>>>>>>>> ==
> >>>>>>>>>>>>>>>>>> '[object process]’)
> >>>>>>>>>>>>>>>>>> or:
> >>>>>>>>>>>>>>>>>> if(typeof process != 'undefined' && process &&
> >>>>>>>>>>>>>>>>>> process.constructor.name == "process”)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Of course every reference to process causes a compiler
> >>>>>>>>>>>>>>>>>> error. I
> >>>>>>>>>>>>>>> wonder
> >>>>>>>>>>>>>>>>>> if there’s some way to tell the compiler to accept it
> >>>>>>>>>>>>>>>>>> without
> >>>>>>>>>>>>>>>>>> complaining…
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Jul 4, 2017, at 8:54 PM, Josh Tynjala
> >>>>>>>>>>>>>>>>>>> <joshtynj...@gmail.com>
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I don't remember exactly what I did, but in order to
> get
> >>>>>>>>>>>>>>>>>>> trace()
> >>>>>>>>>>>>>>>>>>> working in
> >>>>>>>>>>>>>>>>>>> Node.js, I had to figure out how to find the console
> >>>>>>>>>>>>>>>>>>> object
> >>>>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>> window
> >>>>>>>>>>>>>>>>>>> versus global. I feel like I remember using typeof, but
> >>>>>>>>>>>>>>>>>>> maybe
> >>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>> was
> >>>>>>>>>>>>>>>>>>> something else. Take a look at the implementation of
> >>>>>>>>>>>>>>> Language.trace()
> >>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> see what I did.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> - Josh
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Jul 4, 2017 5:26 AM, "Harbs" <harbs.li...@gmail.com
> >
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I’m trying to figure out how to solve this dilemma:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Browsers attach global variables to window.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Node.js attaches globals to global.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I’m trying to check for the existence of a global
> called
> >>>>>>>>>>>>>>>>>>>> process.
> >>>>>>>>>>>>>>> In
> >>>>>>>>>>>>>>>>>>>> JS,
> >>>>>>>>>>>>>>>>>>>> you’d generally do that by checking typeof process ==
> >>>>>>>>>>>>>>>>>>>> ‘undefined’.
> >>>>>>>>>>>>>>>>>>>> Falcon
> >>>>>>>>>>>>>>>>>>>> does not allow you to do that and complains that
> process
> >>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>> undefined
> >>>>>>>>>>>>>>>>>>>> property. In the browser you can use window[“process”]
> >> ==
> >>>>>>>>>>>>>>> undefined
> >>>>>>>>>>>>>>>>>>>> and in
> >>>>>>>>>>>>>>>>>>>> node you can (theoretically) use global[“process”] ==
> >>>>>>>>>>>>>>>>>>>> undefined.
> >>>>>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>> can’t
> >>>>>>>>>>>>>>>>>>>> think of a generic way to do this though.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Thoughts?
> >>>>>>>>>>>>>>>>>>>> Harbs
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
>
>
