On Thu, Mar 26, 2009 at 3:00 PM, Jaroslav Hajek <[email protected]> wrote: > 2009/3/26 Olaf Till <[email protected]>: >> On Thu, Mar 26, 2009 at 09:21:38AM +0100, Olaf Till wrote: >>> >>> ... >>> >>> Looking at the parcellfun stuff, I noticed that there are still more >>> functions for sending and receiving Octave variables in octave-forge: >>> fsave and fload. Some time ago there was a discussion in the >>> octave-maintainers list on save'ing and load'ing over streams. After >>> getting some hints, I posted psend and prcv, which can install/read >>> Octave variables to/from memory as well as directly returning/taking >>> their contents, and which read/write a binary header also (to care for >>> endian'ness, as I understood), and which distinguish eof at start of >>> reading from eof later. The discussion dried out, probably the >>> solution was not general enough and not obviously the right one for >>> Octave. For the now contributed code, the functionality of fsave and >>> fload would probably be sufficient, if only endian'ness was cared for >>> by writing/reading a header (varibles are sent between different >>> machines now). If this would be done, I could rewrite my code, and >>> then there is probably no reason to keep psend and prcv in the >>> package. >> >> Jaroslav, >> >> would you accept the attached small patches for fsave.cc and fload.cc, >> to make them robust for usage between different machines? >> > > I actually didn't intend fsave and fload to work across machines > (parcellfun uses them just for pipes). But I'm not against it. I want, > however, to avoid the overhead of sending the binary header with each > variable. > > I see several options: > 1. use explicit arch specs (like fwrite, fread) > 2. use explicit option to control whether headers are used (but then > you can as well use different functions) > 3. cache the stream pointer in both fload/fsave and only write the > header on first save / attempt to read it on first load. This is > possible because octave_stream has reference counting, ensuring a > cached object remains valid. > The price to pay is one dangling closed file (but no memory leaks), > which is easily acceptable. >
Umm, I just realized this is not really that easy if you simultaneously use more streams. So the question is still open. I don't see any reasonably simple way to achieve it, other than maintaining a map of open stream numbers which already received the header. Specifying architecture explicitly is another option - or just leaving everything in the present state. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz ------------------------------------------------------------------------------ _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
