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.