circular references can't resolve correctly if exports is overwritten:

in module A:

exports = foo

then later in module A:

doSomeFunction()

that results in an import of module A.

expected: module A is partially defined with foo
actual: jsio doesn't pull the new exports out of the module until after the import returns, so we don't have access to foo.

.emit() is supposed to return whether or not the event was handled. In our implementation, it just checks for this.listeners(type).length > 0. This fails when the only listener was subscribed with .once().

In v0.1.29 of node.js, promise.wait was removed. The jsio import system depends on synchronous file I/O (require() is the only exception it seems).

Looks like we might have to fall back to expose the node.js require syntax to the browser instead... :(

I detest $ as a catch all for functions, but especially since jQuery is so entrenched and the js.io $ doesn't have the same API. Let's rename it to std.HTML at some point to mirror our other data libraries?

When using the ImageView.doOnLoad, the closure is leaked due to Callback not clearing the closures on it's "to run when fired list" after being fired.

diff --git a/packages/lib/Callback.js b/packages/lib/Callback.js
index 7a610c9..b476f20 100644
--- a/packages/lib/Callback.js
+++ b/packages/lib/Callback.js
@@ -67,6 +67,8 @@ exports = Class(function() {
                for(var i = 0, len = cbs.length; i < len; ++i) {
                        if (cbs[i]) { cbs[i].apply(this, arguments); }
                }
+               // Clear listeners to prevent leakage:
+               cbs.length = 0;
        };

        this.chain = function(id) {

A js.io web Client in fin can generate multiple frames per second under normal usage patterns, and a fin server Connection as well. When multiple frames get generated during a configurable time period they should be sent together in a single xhr request.

it seems that the root code wasn't actually compiled into the build. I've got a patch that should fix it.

...but I'd rather split them into a compat.js. Is there a proper way for base.js to be including an external js.io file?

what is the reason for this loop https://github.com/gameclosure/js.io/, is this loop optional?

Namely, console.log will give you a nice summary of an object when log it, while logger.log will just print [Object object];

It would be nice to support that like Node does. Could also add preprocessor support (didn't @CarlQLange do something related?).

Thoughts?

I am using js.io included with Hookbox. While it works great in all the browser's I've tested it on, it fails completely in Adobe AIR. Worked a bit with mcarter tonight and we think we have the problem narrowed down to Adobe's sandbox restrictions which prevent using eval() after onLoad has fired. Would there be any way to offer a sort of .compile() function or something similar which will allow this to work around that restriction?

in all webkit based browsers [safari, chrome, ipad/iphone browsers], the default usage of js.io causes the 'loading' and spinning to go on for ever, and waiting for xx.com ....

js.io uses node's process.compile, which gives a deprecation warning. This might also be related to another bug in which js.io import errors are uncatchable, since process.compile exits the node process on syntax errors.

bonnie@bonnie-Inspiron-3543:~/WorkStation/js.io$ ./jsio <- executing jsio gives the following error
/home/bonnie/WorkStation/js.io/jsio:9
jsio('import util.optparse');
^

ReferenceError: jsio is not defined
at Object. (/home/bonnie/WorkStation/js.io/jsio:9:1)
at Module._compile (module.js:425:26)
at Object.Module._extensions..js (module.js:432:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:311:12)
at Function.Module.runMain (module.js:457:10)
at startup (node.js:136:18)
at node.js:972:3

If a tilde (~) is encoded in CSP there is an error when base64 decoding.

http:://js.io redirects to -> http://labs.gameclosure.com/js.io/ which displays a 404 error.

diff --git a/packages/jsio.js b/packages/jsio.js
index ef904d6..6105dd0 100644
--- a/packages/jsio.js
+++ b/packages/jsio.js
@@ -45,7 +45,7 @@
                if(!jsio.path.__default__) { jsio.setPath(ENV.getPath()); }
        }

-       if (typeof node !== 'undefined' && typeof process !== 'undefined' && process.version) {
+       if (typeof process !== 'undefined' && process.version) {
                jsio.setEnv('node');
        } else if (typeof XMLHttpRequest != 'undefined' || typeof ActiveXObject != 'undefined') {
                jsio.setEnv('browser');

Regards,
Jérémy.

something.subscribe(function () {
    this === GLOBAL;
});

I'd expect this to be something. Seems very broken currently.

js.io should use a different name for the overridden constructor. It is a relatively common singleton pattern to have the function that initializes the singleton called "init".

When compiling in release mode and compressing JavaScript files, the build scripts do not recognize if the compressor exits with an error code, and caches an empty value instead of the compressed script.

https://github.com/gameclosure/js.io/blob/master/packages/preprocessors/compiler.js#L236-L246

expose the longpoll duration (du csp variable) to a higher-level api, specifically net.connect

inorder to detect disconnected clients, this duration can be used.
mcarter: the timeout is sort of tied up in the long poll duration (the shorter the longpoll duration the (potentially) more bandwidth you'll use on empty request/responses)

See packages/package.json and https://npmjs.org/package/js.io.

In my opinion, we should update the existing node package (with the name "js.io" instead of "jsio").

And then an XD transport using XHR in an iframe for all browsers without native XD-XHRs. This will avoid spinning issues with jsonp (e.g. possibly opera).

WARN .csp.server Unexpected Error: invalid utf-8 bytes

The unencoded JSON blob has unicode characters in it. Will follow up shortly.

Adding a comment to an import statement causes a compilation error. For example:

import lib.MyClass as MyClass; //some comment

Perhaps a problem with the regex.