[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] Possible stack problem with fork
From: |
Peter Bex |
Subject: |
Re: [Chicken-users] Possible stack problem with fork |
Date: |
Thu, 03 Feb 2005 19:03:22 +0100 |
User-agent: |
Mutt/1.4.2.1i |
On Thu, Feb 03, 2005 at 07:56:16AM -0800, felix winkelmann wrote:
> - you didn't pass the length indicator to read-string (the first argument)
> - read-string only works for ports, not file-descriptors, use file-read
> instead.
> - process-wait returns multiple values, this triggers the error, since
> it is not called in a multiple values context [1]
Hrm, I don't know what it is with me this week, I keep making mistakes
like this. Perhaps I should get some more sleep.
But, there's currently no convenient way to quickly read out an entire
file into a string? Hrm, maybe I could use open-input-file* and use
read-all.
There's now the question whether read-string should just kill the
stack like this, or if it should do more argument checking.
Anyway, thanks for the tips!
> I will add a second optional parameter to `process' that can be
> used to specify a list of arguments and which will invoke the program
> directly (not via the shell) - `process' is much easier to use than
> doing everything by hand (I would check this in, but I'm currently
> behind a firewall).
Excellent idea. Thanks a lot!
I would LOVE to see all functions that currently accept a CMDLINE argument
have a `execv' variant. Calling programs by going through the shell like
this is a very bad idea and should be discouraged anyway. (IMHO, anyway)
> [1] this is R5RS compliant, but at the same time sometimes a bit
> inconvenient - I'm thinking about relaxing this a little (allowing
> returning multiple values in a single value context). It could be
> implemented by returning only the first value (or void, if zero
> values are returned).
IMHO that is a Bad Thing(TM), it makes it much easier to accidentally write
code that breaks on other systems (as I did without knowing it). IMHO it's
a much better idea to simply make a form that works like (discard expr)
or (discard-values expr), that just returns (void). It could be implemented
in terms of a (receive) that simply discards its values, but maybe it could
also be implemented more efficiently.
Of course, I could've just used (receive) right away, if I had thought of the
values of process-wait...
Just tossing up some ideas ;)
Regards,
Peter
--
http://www.student.kun.nl/peter.bex
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
pgpToDlHsf_Ue.pgp
Description: PGP signature