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. > Also, would you think I could put 'select.cc' (general wrapper around > Unix select) into main/general instead of keeping it in my package, > where I need to call it? (What I attached in the first mail of this > thread did not use texinfo for helptexts, this has changed now.) > OK. Where's select.cc located? > There is also an _exit() function which I would also like to put into > main/general. > A wrapper around _exit(), I suppose. I very much agree; this is actually something that was needed for parcellfun (because you don't want a regular exit from a forked octave process) and I cheated it round by instead calling exec. > Actually the functions for advisory locking also do not really belong > into the package, but more into main/general, but they are probably > not general enough, allowing only write-locking a whole file and using > raw file descriptors. I think octave_stream allows you to get the descriptor. If you can make them accept octave's file numbers, then I don't see a reason why they should not be included. cheers -- 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
