headers
Alejandro Forero Cuervo | 1 Mar 2005 04:39
Picon
Favicon

with-pipe in POSIX


Hi.

I have noticed with-input-from-pipe and with-output-to-pipe.  Is there
a more generic function that allows my procedure to communicate with
the command through both its input and output file descriptors?

For example, I need my process to run a ssh command and then talk with
it in both directions: write information to the command and read
information from the command.

Is this possible?  I haven't found a function to do this.

Would a general with-pipe function be feasible?

Currently I'm using the following code:

; -- start --

(declare (foreign-declare
#<<EOF
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <stdlib.h>
EOF
))

(define fork-run-real
  (foreign-lambda*
(Continue reading)

Permalink | Reply | 1 comment |
headers
felix winkelmann | 1 Mar 2005 07:14
Picon

Re: profile: collecting stats for multiple runs

On Mon, 28 Feb 2005 18:31:08 -0500, Alejandro Forero Cuervo
<bachue <at> bachue.com> wrote:
> 
> Would you be willing to accept a patch to modify this?  I think it is
> far more useful to have the profiler add new information to the
> existing file (instead of overwriting it).
> 
> I decided to take some time and create a patch implementing this.  See
> the file attached.  Basically, I do the following:
> 
> - Open the PROFILE file in append mode (so I won't overwrite previous
>   info).
> 
> - Modify chicken-profile.scm to be smart enough to merge information
>   from multiple runs, using a hash table.
> 
> If a user wants the previous semantics, all he needs to do is rm
> PROFILE before running his program (another option would be to add a
> --profile-overwrite paramter to Chicken?  I would vote against is, at
> it adds complexity to Chicken's interface without being too useful).
> What do you think?

Very good. I'll apply your patches ASAP. But I'm not sure whether it is 
perhaps a bit surprising, if a user has an old PROFILE lying around, and
several runs produce different output (for example when continuously
recompiling a benchmark).
What about an alternative to the -profile option, something like
"-accumulate-profile"?

>
(Continue reading)

Permalink | Reply | 0 comments |
headers
felix winkelmann | 1 Mar 2005 07:19
Picon

Re: with-pipe in POSIX

On Mon, 28 Feb 2005 22:39:36 -0500, Alejandro Forero Cuervo
<bachue <at> bachue.com> wrote:
> 
> Shouldn't a with-pipe function be included (specially since
> with-input-from-pipe and with-output-to-pipe are) in the POSIX unix?
> 

There is `create-pipe', which is just a low-level procedure that
directly maps to the POSIX `pipe' call.

But what you probably want is `process' (also in the posix unit):

#;1> (define-values (i o pid) (process "wish"))
#;2> (write-line "puts abc" o)
#;3> (read-line i)
"abc"

(close both ports to terminate the connection and wait for
the subprocess to terminate)

cheers,
felix
Permalink | Reply | 0 comments |
headers
felix winkelmann | 2 Mar 2005 08:16
Picon

Re: profile: collecting stats for multiple runs

On Mon, 28 Feb 2005 18:31:08 -0500, Alejandro Forero Cuervo
<bachue <at> bachue.com> wrote:
> 
> Would you be willing to accept a patch to modify this?  I think it is
> far more useful to have the profiler add new information to the
> existing file (instead of overwriting it).
> 

Hi!

The current darcs version now has a new compiler option

"-accumulate-profile"

This is the same as "-profile", but profile data is appended to any
existing PROFILE, and chicken-profile handles this properly (
using Alejandros patch). 

cheers,
felix
Permalink | Reply | 4 comments |
headers
Alejandro Forero Cuervo | 2 Mar 2005 22:42
Picon
Favicon

Re: profile: collecting stats for multiple runs


> The current darcs version now has a new compiler option
> 
> "-accumulate-profile"
> 
> This is the same as "-profile", but profile data is appended to any
> existing PROFILE, and chicken-profile handles this properly (
> using Alejandros patch). 

This sounds excelent!  Thank you, Felix!

BTW, another request... could you consider making -:r send the trace
output to stderr rather than stdout (or, at least, making a compile
time option to specify where, whether to stdout or to stderr, the
trace output should go)?

Having -:r send everything to stdout makes it impossible to keep the
trace separated from the normal output.  Sending it to stderr makes it
impossible to keep it separated from the error output, but stderr is,
in my experience, less important/used than stdout.

This has already been a problem for me, as I want to see the trace of
a command as it communicates (via stdin/stdout) with its father
process.  I suppose this situation, where you need to make sure the
program continues to send its stdout without noise, is much more
common than requiring the error output to be clean.

Thank you!

Alejo.
(Continue reading)

Permalink | Reply | 3 comments |
headers
felix winkelmann | 3 Mar 2005 07:09
Picon

Re: profile: collecting stats for multiple runs

On Wed, 2 Mar 2005 17:42:48 -0400, Alejandro Forero Cuervo
<bachue <at> bachue.com> wrote:
> 
> BTW, another request... could you consider making -:r send the trace
> output to stderr rather than stdout (or, at least, making a compile
> time option to specify where, whether to stdout or to stderr, the
> trace output should go)?
> 

No problem.

cheers,
felix
Permalink | Reply | 2 comments |
headers
felix winkelmann | 3 Mar 2005 20:51
Picon

Re: profile: collecting stats for multiple runs

On Thu, 3 Mar 2005 07:09:41 +0100, felix winkelmann <bunny351 <at> gmail.com> wrote:
> On Wed, 2 Mar 2005 17:42:48 -0400, Alejandro Forero Cuervo
> <bachue <at> bachue.com> wrote:
> >
> > BTW, another request... could you consider making -:r send the trace
> > output to stderr rather than stdout (or, at least, making a compile
> > time option to specify where, whether to stdout or to stderr, the
> > trace output should go)?
> >
> 

Here is the patch for runtime.c, BTW:

3082c3082
<   if(show_trace) puts(name);
---
>   if(show_trace) fputs(name, stderr);

cheers,
felix
Permalink | Reply | 1 comment |
headers
felix winkelmann | 3 Mar 2005 20:58
Picon

Re: profile: collecting stats for multiple runs

> 
> 3082c3082
> <   if(show_trace) puts(name);
> ---
> >   if(show_trace) fputs(name, stderr);
> 

Umm... Add a `fputc('\n', stderr)', there, of course...

cheers,
felix
Permalink | Reply | 0 comments |
headers
Julian Morrison | 4 Mar 2005 16:35
Picon
Picon

Is it possible to emulate a port in chicken?

By emulating a port, I mean: creating a "fake" port object which hands 
off reads and writes to callback functions. That would allow new sorts 
of ports to be defined in libraries eg: TLS port. At the moment I can't 
see any way to do this. Is there one? I assume worst case I could use 
FFI to muck about with chicken's internal port representation.

Also, suggestion: add a library call that reverses the posix library's 
(port->fileno) to allow a FD to be wrapped in a port. This is useful eg: 
in circumstances where a FD is inherited from the parent process, such 
as in programs called by inetd.
Permalink | Reply | 1 comment |
headers
felix winkelmann | 5 Mar 2005 12:05
Picon

Re: Is it possible to emulate a port in chicken?

On Fri, 04 Mar 2005 15:35:23 +0000, Julian Morrison
<julian <at> extropy.demon.co.uk> wrote:
> By emulating a port, I mean: creating a "fake" port object which hands
> off reads and writes to callback functions. That would allow new sorts
> of ports to be defined in libraries eg: TLS port. At the moment I can't
> see any way to do this. Is there one? I assume worst case I could use
> FFI to muck about with chicken's internal port representation.
> 
> Also, suggestion: add a library call that reverses the posix library's
> (port->fileno) to allow a FD to be wrapped in a port. This is useful eg:
> in circumstances where a FD is inherited from the parent process, such
> as in programs called by inetd.

The `extras' unit has `make-input-port' and `make-output-port'.
See: 

http://www.call-with-current-continuation.org/manual/Input_002fOutput-extensions.html#Input_002fOutput-extensions

cheers,
felix
Permalink | Reply | 0 comments |

Gmane