On Wed, Mar 25, 2009 at 09:13:42AM +0100, Søren Hauberg wrote:
> tir, 24 03 2009 kl. 12:37 +0100, skrev Olaf Till:
> > I have just finished a package intended for use in our institution,
> > and would like to make it publicely available at the same time, so I
> > request an octave-forge account.
>
> I've given you developer access. Before you commit the package I think
> we should consider if your code should be in a separate package or if it
> should be joined with some of the other parallel stuff we already have.
> Since I don't use Octave for parallel processing I don't really have
> strong opinions, but it might be better to only have one package for
> this kind of usage.
>
> Opinions?
>
> Søren
>
Since as yet there were no comments, maybe I can make some myself:
Only two packages seem related:
- parallel (in main),
- multicore (in extra).
Also, there is "parcellfun" in main/general/.
(Jaroslav: please take a look at the last paragraph, regarding "fsave"
and "fload")
Although multicore seems similar at first glance (evaluates a function
with different arguments in different processes, only at the same
machine), I would not suggest to combine it with the new code. Reason:
multicore was originally intended for Matlab and does not fork, but
slave processes must be started by hand. Data exchange is done over
files. There would be more efficient ways in Octave. "parcellfun" by
Jaroslav Hajek in main/general/ is probably already a better choice.
The now contributed code could be included into the parallel
package. The new functions remain separate in their purpose and in
their implementation. As I understand, the original parallel package
uses sockets and allows execution of arbitrary Octave commands on
manually chosen remote machines. The new functions use SSH and are
more high-level and specialized, scheduling evaluation of a user
functions with different arguments on different machines. Common
functionalities are the functions for sending and recieving Octave
variables over the connection. While in the original parallel package
variables are sent only by package code (which considers the type of
the variable), the new functions do not care for the type of the
variable, but use linked functions of Octave itself for the
transfer. I thought of suggesting to make the original functions
("send", "recv") wrappers to the new functions ("psend", "prcv"), but
while the new functions use Octaves stream numbers, the others use raw
file descriptors with no associated Octave stream. So there will be
nothing common in implementation.
Could there be problems in combining independent functions of
different maintainers into one package? If one group of functions does
not compile with a future version of Octave, pkg will not install any
function of the package.
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.
Olaf
------------------------------------------------------------------------------
_______________________________________________
Octave-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/octave-dev
