reimplement process using native

[gavinking]

We have done system, operatingSystem, and now runtime. I need a volunteer to do process.

[quintesse]

Can we at the same time add {String*} propertyNames() and {String*} environmentVariableNames()?
Although perhaps I'd even prefer: {String->String*} properties() and {String->String*} environmentVariables() because that makes quickly printing out all the values very convenient.

[gavinking]

Well I guess, if you know how to implement those sensibly for JavaScript. But please don't make them methods.

[gavinking]

Assigning to you, @quintesse, because I think you already started work on it.

[quintesse]

No way we can do this now. And who knows if ever, because it would entail removing all of the model loaders from the backend compilers and put them somewhere central (ceylon-model?) so each compiler can load the "binaries" of each of the other backends just so it can check which packages it contains.

[quintesse]

Completely finished code for process can be found here: https://github.com/ceylon/ceylon.language/tree/nativeprocess in case we can ever solve this.

[gavinking]

@quintesse see on gitter where I just proposed an extremely simple solution to the problem.

[FroMage]

Well no, gitter is not the right place to document what should be done in issues. So I'll sum it up here:

Why doesn't the exact same problem happen for native("js") module imports when compiling on the JVM? I'm pretty sure we have the same problem reversed.

We "just" have to have a minimal "module/model loader" that knows how to extract 1/ module imports (we already have that in the CMR) and 2/ packages from modules for other backends then by scanning module imports of other backends (native("jvm") from the js compiler for example), we can see if the package belongs there for the JVM that's pretty trivial to scan the jar I bet it's easy for the JS archives too and yes we can cache that, I expect the problem to only come up in rare cases, and only pay there.

So for instance if we find that we have a missing package, check if we have native module imports for other backends, and then load them to check if the package doesn't come from there. That's the real issue we're trying to fix, right?

The CMR already knows how to load module imports for any backend: JS/JVM/POM/OSGi/JBossModules. All it needs is to be augmented to also load the package lists.

[quintesse]

I'm pretty sure we have the same problem reversed.

No, because there is no thing as a "legacy JS module", if you want to use existing JS code you use dynamic and you don't have to import anything.
If on the other hand you import a native("js") module it's packages is always have a name that starts with the name of the module itself so they get matched.

Edit: but that is obviously a hack, so having the possibility to get the real list would definitely improve the situation!

All it needs is to be augmented to also load the package lists.

And it would need to be factored out of the CMR and be generally available, otherwise this wouldn't work when dealing with a flat classpath (AFAIK at least).

[FroMage]

If on the other hand you import a native("js") module it's packages is always have a name that starts with the name of the module itself so they get matched.

OK that's true. Although, can't we also import node.js modules?

And it would need to be factored out of the CMR and be generally available, otherwise this wouldn't work when dealing with a flat classpath

No, even the flat classpath stuff uses the CMR for module info loading.

[FroMage]

As I said on IRC, this would be a lot more expensive than annotating the package import, and would not scale well to other backends as loading all module imports for native("!js") may require loading more than just the JVM. It would also require that the compiler at hand knows how to load native modules, and we can expect a JS compiler written in Ceylon running on nodejs to not be able to load the JDK modules just to verify what packages they have.

Now, @gavinking said that we'd need package imports to be given a type in the metamodel since that's how annotations are constrained, but I think that's fine since that can just be an empty interface with no runtime instance, as module imports are not reified at runtime.

[quintesse]

Although, can't we also import node.js modules?

I don't know, can we? That would be cool but I've never seen any code doing that.

[thradec]

I think we can, at least I'm doing it in testjs, see
https://github.com/ceylon/ceylon-sdk/blob/master/source/com/redhat/ceylon/testjs/tool.ceylon#L68

2015-10-07 16:28 GMT+02:00 Tako Schotanus notifications@github.com:

Although, can't we also import node.js modules?

I don't know, can we? That would be cool but I've never seen any code
doing that.

—
Reply to this email directly or view it on GitHub
#754 (comment)
.

[quintesse]

@thradec well yes, but that's runtime, the compiler doesn't know anything about that :)

Edit: meaning you don't import it in the module descriptor, nor do you add any import statements in the code. But it's nice to see how easy it is to load Node.js modules!

[gavinking]

We can interop with node or common JS modules, but that is always using dynamic.