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 wrote:
> Adding node.swc makes things like require be recognized, but glob
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
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 wrote:
>
> Are you saying we should add node.swc to Core?
>
> FWIW, I just tried setting targets to JSNode and global is still not
>
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 wrote:
>
> I think the co
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 wrot
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 re
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" wrote:
>Right now, if you have code that looks like this, th
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 co
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,
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
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
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 Ha
What AS do you want to write and what JS do you want as output?
-Alex
On 7/9/17, 12:53 AM, "Harbs" 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.
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
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:5
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 thi
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 the
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
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 any
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 i
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 {!Proce
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 wi
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
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
24 matches
Mail list logo
