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
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>
