I just gave it a try, and I'm not seeing global either. It appears that
"var global" is not defined in the typedefs. I guess we'll need to add it
to the missing.js for Node.

- Josh

On Thu, Jul 13, 2017 at 10:09 AM, Harbs <harbs.li...@gmail.com> wrote:

> Adding node.swc makes things like require be recognized, but global is
> still not. Odd. I thought I saw it in the typedefs.
>
> > On Jul 13, 2017, at 8:04 PM, 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
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >
>
>

Reply via email to