[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/

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

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 ;)

"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

Attachment: pgpToDlHsf_Ue.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]