jscl-project
Implementing more stream functionalities
When going through stream.lisp, I have the feeling that the current approach might be a dead end after all. How would we support the type hierarchy the standard specifies?
Implementing streams using CLOS might be appealing. However our CLOS implementation might not be particularly fast at this moment (nor does def!struct, but it's probably better).
Thoughts?
Phew, I successfully reimplemented the stream system (with almost full functionality specified in ANSI CL) using gray streams and CLOS on my local branch, and it works!... except for that tests runs 4 times slower...
I don't know how to go about this. The gray stream implementation is IMO quite elegant. Should we wait for our CLOS to get really fast first, then I'll incorporate my gray stream implementation?
The original plan is to get stream functions more complete so that I can incorporate my CMUCL format port (yes, I have a working port!). The specific problem is CMUCL format doesn't buffer into a string and output at once, but write to output stream piece by piece (as it should be). This mostly works fines except for resulting in ugly output when running tests.js, because it's run with *standard-output* doing console.log for every call, resulting in many spurious new lines... Maybe I should just add a hack to address this for now.
I don't know how to go about this. The gray stream implementation is IMO quite elegant. Should we wait for our CLOS to get really fast first, then I'll incorporate my gray stream implementation?
Can we find what is the bottleneck?
Can we define a specific stream for common use cases that is still fast?
If not, I would rather have a slow implementation than not implementation. I would guess no one is relying on performant stream work with JSCL.
This mostly works fines except for resulting in ugly output when running tests.js, because it's run with standard-output doing console.log for every call, resulting in many spurious new lines...
For Node.JS, we could replace it with process.stdout.write() ? For the browser, maybe we use something else than console.log() that does the line buffering.
If not, I would rather have a slow implementation than not implementation. I would guess no one is relying on performant stream work with JSCL.
The compiler use it extensively, so slow stream slow down the whole system. This does remind me I just need to get string-output-stream fast. Thanks for the idea!
For Node.JS, we could replace it with process.stdout.write() ? For the browser, maybe we use something else than console.log() that does the line buffering.
Both browser and node REPL replace this simple definition with a version that does not generate extraneous new line. Currently it's only used in tests.js (which does not load the REPLs) and probably user applications.
I already changed the simple definition to do line buffering. Although now it only outputs when sees a new line. There could be a case that user writes lots of output without a newline and wonder where their output goes. Implementing finish-output would shift the blame. SLIME use an auto flush thread that writes output periodically but I don't think this is possible/a good idea for JavaScript.
String/sequence functions (like subseq) in JSCL are very slow, may be this is the root of the slowness. The JSCL reader is slow because of them, for example.
