[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MPI and private methods in octave::load_save_system
From: |
John W. Eaton |
Subject: |
Re: MPI and private methods in octave::load_save_system |
Date: |
Fri, 15 Feb 2019 17:29:26 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 |
On 2/14/19 11:15 AM, address@hidden wrote:
On 13 Feb 2019, at 19:09, address@hidden wrote:
No, that version of the package is not maintained anymore, the code in there is
not compatible with Octave 4.4 or later [1].
Current development goes on in github [2] (actually I just now moved it from
bitbucket ...)
The relevant code is here:
https://github.com/carlodefalco/octave-mpi/blob/master/src/MPI_Send.cc#L65
https://github.com/carlodefalco/octave-mpi/blob/master/src/MPI_Send.cc#L67
https://github.com/carlodefalco/octave-mpi/blob/master/src/MPI_Recv.cc#L83
https://github.com/carlodefalco/octave-mpi/blob/master/src/MPI_Recv.cc#L90
BTW, if this change were to be made, would it be on some stable or default?
I'd be willing to make minor changes on stable (moving a declaration
from private to public, for example) if necessary. As we discussed on
IRC, I was considering making more extensive changes to avoid making
some messy interfaces public again, but I'm not sure that we should do
that. We were talking about providing functions like
octave_value load_save_system::read_value (std::istream& is,
std::string& name, bool& global);
and
void load_save_system::write_value (std::ostream& os, const
octave_value& val, const std::string& name, bool global, const
load_save_format& fmt, bool save_as_floats);
but when I started looking at what would be required to extract the the
read_value function from the load_vars function it was not as simple as
I assumed. Some of the functions that ultimately write the data require
extra info that wouldn't be in the above interface. We should probably
clean all of that up and use consistent interfaces. But I think the
changes are too much to make just before the release.
Also on IRC, you said the functions that are required are
write_header
save_binary_data
read_binary_file_header
read_binary_data
The save_binary_data and read_binary_data functions are public and
declared in ls-oct-binary.h. If you know that the data on the stream is
Octave binary data using a particular float format, do you really need
to read and write the header, or can you omit that? If you can omit it,
then I don't think we need to change anything before the release. If
you do need it, what is it used for? If it really is necessary, then I
would consider making those functions public for this release.
Longer term, however, I think it would be good to come up with better
and more consistent interfaces.
jwe