jscl
jscl copied to clipboard
jscl-project
to implement load function
@davazp Hi, David.
I'm raising some budget at the Bountysource account t-cool, and I'll spend some of the budget on developing JSCL.
I asked cxxxr to implement load function on JSCL. He'll implement it in a week or so. Could you tell me how to implement load function if you have the specific way? If you don't, I'll ask him to implement it as he wants.
By the way, I started developing jscl-playground as an experiment to make a frontend app using JSCL. At first, I implemented LOGO turtle to play on it.
https://t-cool.github.io/jscl-playground
Regards.
- Noguchi
Nice playground!
load requires file system right? So I propose to implement it only on node.js for now. The implementation can be easy in there, some FFI magic to read the file content little by little and calling the compiler on each toplevel form.
The concerns here are, load is synchronous, it will wait until the file is totally loaded. If we want to have that, then it should use fs.readFileSync. But of course that will block the event loop.
The alternative would be for load to return asynchronously, but then it would not be compatible with the CL spec.
I think 2) is not acceptable, but I get this async/sync mixed feeling all the time and it is a big limitation of JSCL right now. It would be nice to have a better solution without going full CPS.
Anyway, I hope it helps, and thanks!
load accepts a stream or a pathname designator.
HTML5 sort of has a file system. <input type=file> creates a button which opens dialog on the client and returns a list of File objects. You can then use FileReader or FileReaderSync
if load accepted a stream, you could use with-input-from-string and FileReader.readAsText()
load is still not implemented in node.js. fs.readFileSync should be used in my opinion. It may block the event loop, but the return value could be needed (success or error for example), plus, even if it blocks the event loop, then load is most of the time called on initialization.
Good point @hlolli. I'm reopening the ticket. load on nodejs should be relatively simple.
A url based load was added in #337. I would like to rename that to load-url and use sync node version for load.
Maybe add another key to the load? something like :sync?
(load "./app.lisp" :sync t) ; sync/ from local fs
(load "https://dark.net/pro/app.lisp") ; async/ from www or local fs
The file reader here will be simple. and the compilation function is already there. Work here for a couple of hours.
I would find strange that the :sync t version doesn't work with URLs. If it is an key, I would expect the file/url argument to behave the same regardless the sync value. But if we can make that, then sure! Although sync should default to t probably for CL compatibility.
In my opinion, the main thing here is that the compilation of a large number of expressions, completely blocks all other processes. This is both in synchronous reading and asynchronous.
I'll see what can be done and offer a new version.
If there are other implementations, that's good. We will have a choice.