[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: temporary files not deleted after exit
From: |
Olaf Till |
Subject: |
Re: temporary files not deleted after exit |
Date: |
Thu, 26 Aug 2010 10:00:14 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Wed, Aug 25, 2010 at 04:16:06PM -0400, John W. Eaton wrote:
> On 25-Aug-2010, Judd Storrs wrote:
>
> | On Wed, Aug 25, 2010 at 3:06 PM, Muhali <address@hidden> wrote:
> |
> | in that case I would not use a temporary name. If none of these files
> are
> | temporary, what then is a 'temporary' file?
> |
> | Files opened with mkstemp() and tmpfile(), but I don't see anyway to use
> those
> | with save().
>
> Should we have fsave and fload functions that accept file IDs instead of
> names?
An old thread touched this but came to no solution for Octave:
http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2007-June/003206.html
This lack led to specialized solutions for some Octave-Forge packages
(general, parallel). An Octave solution would be quite suitable IMO.
The main need I see is not for writing/reading plain files, but
into/from octave-streams connected with pipes or sockets (as in the
mentioned packages).
It should be considered that sockets, and even (indirectly) pipes if
they connect to a program like ssh (as in the "bw" part of package
parallel), may lead to a transfer of data between different machines
(architectures).
The actual problem was, and is, to agree how load/save with stream ids
should behave. Some thoughts:
- The connection may need to remain open after load (id, ...) or save
(id, ...) have done their work.
- A common need seems to be to transfer just one variable, without an
associated name, and to get it returned by the reading function on
the other end.
- But one could imagine that a more "load" like installing of many
variables into memory is also useful --- so (much of) the whole
current "environment" of variables (and function handles --- if this
should get implemented) could be transfered to the other process,
ideally leading to identical conditions for interpreted code in both
processes.
Olaf