octave-maintainers
[Top][All Lists]
Advanced

[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


reply via email to

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