octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "save" to and "load" from file descriptor


From: John W. Eaton
Subject: Re: "save" to and "load" from file descriptor
Date: Wed, 13 Jun 2007 19:10:53 -0400

On 13-Jun-2007, Olaf Till wrote:

| work. I cannot enforce binary mode since pipes have only "w" or "r".)

I think pipes are by definition binary.

| There is shurely no reason to pass variable names, or even to pass
| more than a single variable in one call. Since both sides of the pipe
| are usually programmed by the same person, if he/she likes, multiple
| variables and variable names can be put into a cell array or a
| structure before.
| 
| So I would accept only a single variable to pass, and pass its value
| itself, and in loading return the value, not install the named
| variable into memory. The name used with save_binary_data() would be
| an arbitrary one than.

If the values are not named in some way, then how does the receiving
end know what values it is receiving?  It seems that somehow that
information would need to be transferred.  It doesn't seem like a very
flexible solution if the data that you are transferring has a fixed
order that must be agreed by the programs before they start.  So it
seems that you need more than just the abilitly to hook up the save
and load functions to a pipe, and that you need to define a protocol
or some sort to define what data is being sent, in addition to sending
the data.

| ...
| psend (pid{2}, var1);
| psend (pid{2}, var2);
| ...
| pclose (pid{2});
| 
| would be allowed than, and the corresponding prcv (pid{1}) would have
| to be called several times in this case.

You will still need a way to send the header information, or you will
have to restrict yourself to a particular format, byte order, etc.

| Since e.g.
| 
| psend (pid{2}, var1);
| fprintf (pid{2}, "something", ...);
| ...
| pclose (pid{2})
| 
| should also be possible, and the other side has to parse the stream
| "manually" in this case, there should also be a pendant to "prcv()"
| that reads from a string.

I think that would just be an error.  If you allow arbitrary data
between blocks of data that are supposed to contain Octave values,
then I think it would probably not be reliable.

jwe


reply via email to

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