Add node builtin modules

[iefserge]

No description provided.

[piranna]

Is this related with the Node.js compatibility layer? :-P

If so, I think it would be better to name tbe folder 'node_modules' to make it more similar, specially since on NodeOS qe talked about the posibility to add an option to move all built-ins on external files...

[iefserge]

@piranna do you mean modules directory? can't name it node_modules, because node_modules is managed by npm. Yeah, it's basically Node.js compatibility layer:)

[piranna]

Yeah, it's basically Node.js compatibility layer:)

Wiiii! :-)

@piranna do you mean modules directory? can't name it node_modules, because node_modules is managed by npm

Well, not exactly... node_modules folder is of Node.js, npm only makes use of it. Also it's possible to have bundleDependencies, in fact I'm doing it this way on NodeOS, the diferent system layers are organized as modules inside repository node_modules folder... :-)

[iefserge]

Ah, I see. I like to do rm -rf node_modules sometimes, wouldn't want this remove any files:)

[piranna]

Ah, I see. I like to do rm -rf node_modules sometimes, wouldn't want this remove any files:)

Me too ;-) Seems to be the "official" way to clean-up the dependencies but I find it an ugly hack, since it should be done with npm uninstall, but at least with npm 2 this doesn't work :-(

[facekapow]

I was able to make a basic dns.js for this (by basic I mean it only supports A records, so far), should I commit?

[iefserge]

@facekapow nice, just create a new branch from this one, then we can merge one PR into another.. or, actually, I'll just merge this. Wanted to add a few more builtin modules here, but I'll add them separately.

[facekapow]

Ok, I'm going to read up more on DNS packets and implement the different records Node uses into component/dns-client/dns-packet.js.

[iefserge]

👍
I'll see what other builtin modules can be added

[piranna]

Is there a list of the current ones? I could look for the ones needed by
NodeOS to be able to focus on that...
El 20/1/2016 20:41, "Serge" notifications@github.com escribió:

[image: 👍]
I'll see what other builtin modules can be added

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

[iefserge]

@piranna yeah,

runtime/js/__loader.js

Line 252 in 562b7f4

assert: 'assert',

[piranna]

Is there no support for child_process? :-(
El 20/1/2016 9:19 PM, "Serge" notifications@github.com escribió:

@piranna https://github.com/piranna yeah,

runtime/js/__loader.js

Line 252 in 562b7f4

assert: 'assert',

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

[iefserge]

@piranna nope, not yet at least, child_process is probably the hardest to support. Well, there are no processes in runtime.js:) The idea is to use web workers for multitasking instead.
We can try to emulate processes though, again maybe using web workers.

[piranna]

Yeah, probably it will be the most difficult :-) but this and native modules are heavily used by NodeOS, so seems there's still a long path until there... :-( There's also filesystems mounting specially FUSE and OverlayFS, but this could be later somewhat easy to emulate (polyfill :-P) on Javascript.

WebWorkers would be an option to emulate (Javascript only?) processes, since internally they would use their own isolate objects so we don't need to implement process isolation. I don't know if this should/could be implement outside runtime.js core, though.

[iefserge]

Non-javascript code would need to be compiled to WASM, should work in WebWorkers too. Pretty much the same way as in the browser.

[piranna]

Yeah, but the main problem of compiled modules is when they access to low-level OS resources like the syscalls... I don't think WASM would be able to manage this :-(

On the other hand, maybe it would only be a matter of create a C stdlib that correctly access to runtime.js features, or instead better tuneup nan macros to use runtime.js APIs instead of stdlib... :-)

[iefserge]

Pretty much the only thing that lives in C++ land is V8, everything else is in JavaScript. So native modules wouldn't be able to do much in that case, and it would be a security issue with user code running in the kernel space.

[piranna]

Yeah, in fact I found more complicated loading modules from several apps at the same time... :-/ Two options here, process isolation as Chrome does with the plugins, or see if it's possible to offer an API or syscalls that WASM can make use of.

[facekapow]

How would you kill a WebWorker? I've been thinking about how to implement Ctrl+C in the terminal, and I realized that functions can't be killed. Could you kill a WebWorker?

[iefserge]

WASM should be able to just call into javascript directly, I think it's the way it's going to work in the browser. So same API would work for both JS and WASM.

[iefserge]

@facekapow yeah, take a look at this

myWorker.terminate();

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers

[facekapow]

I know about that, I mean, how would you implement WebWorkers? If you do it by threading, how would you implement the threading? If you do it by running them as functions, you can't kill them, can you?

[piranna]

I know about that, I mean, how would you implement WebWorkers? If you do it by threading, how would you implement the threading? If you do it by running them as functions, you can't kill them, can you?

Node.js is using threading for WebWorkers (although the patch don't finish to land...), so we could use here any of the threading libraries there are. If you want to implement them by using functions, then they are coroutines or greenlets, that AFAIK they can't be killed since they are running on the same thread. I think we want to have here real pre-emtive processes/threads...

[iefserge]

@facekapow yeah kinda like threads, using separate isolates, each worker can have its own event loop/queue. The simplest implementation is cooperative multitasking, scheduler would pick events each time from the different queue.

[facekapow]

Should console log to the stdio or use __SYSCALL.log?

[piranna]

It should use stdio.
El 23/1/2016 0:27, "facekapow" notifications@github.com escribió:

Should console log to the stdio or use __SYSCALL.log?

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

[iefserge]

@facekapow I think stdio, because it can be redirected somewhere. __SYSCALL.log is more low level API that always writes to the qemu log.