Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - rrq

#21
I have difficulty in closing stdin for a sub process using (process ..).

The code snippet is:
; Spawn a reader for emptying sub process stdout as my stdout
(setq buffer nil)
(map set '(myin subout) (pipe))
(fork (begin (close subout) (while (read myin buffer 1000) (print buffer))))
(close myin)

(map set '(subin myout) (pipe))
(process "./myscript.zsh " subin subout)
(close subin)(close subout)
...
(close myout)

I would like that last "close" to close the stdin for the myscript.zsh sub process, but this doesn't seem to happen.



Possibly the issue is that the process spawned by the "process" function actually has inherited a writing end of the pipe (it's "dup" of "myout"), and that remains open. If so, how do I close it? Or have I missed something?
#22
I just ran into the following quirk. Basically, I wanted to include stack and memory limits in a script and therefore thought I could do it in the script header line, as:
!#/usr/bin/newlisp -s 4096 -m 100
but then I discovered that only the first of these options come into play.



Eventually  I learnt that the "optional arguments" for the script interpreter are actually passed in as a single first command line argument of the whole rest of line (this is on Linux), and newlisp happily and silently(!) takes an argument of '-s 4096 -m 100' to be the same as '-s4096'. Also, it appears that the handling and delivery of optional arguments may vary across platforms, so maybe one shouldn't use them at all.



But then, how do I make the script set its limits (and other options)? Do I have to have a separate wrapper shell script for its invocation?
#23
Is there a possibility of a function that lets me pivot the execution, in the way of saving the current environment (i.e., stacks etc) into a pdl of such, then pop and continue with a saved environment?

Thus, I imagine a function, say (pivot store), that firstly makes a blob (copy) of the current exection state, then pushes that onto the given "store" (list of blobs) or, if nil, onto an internal store, then pops a blob from the internal store, before restoring this as execution state, which thus continues. (Of course, the continuation should be as an immediate return from that other call of "pivot", rather than pushing the blob again)

That kind of primitive would open the gate for cooperative multi-tasking, and allow programs with thousands of light-weight "virutally concurrent" pursuits, such as large scale simulations, as well as other domains where "parallel pursuits" design is desired.

I've started with the coding, but I'm not fully on top of the extent of things to include in the execution state blob, and wanted to check here for pointers and thoughts first.
#24
Very recently I stumbled onto the newlisp site and got amazed by the excellent  practical sense in the approach; just the right things included for scripting, and yet a proper Lisp system. Hats off for the authors!



.. I had a question, but found answers by forum search, so removed it. Now this is just praise and no question :-)