Hi again,
Le 03/03/2020 à 11:55, Drew Parsons a écrit :
>> Actually, it may be wise to choose names that
>>
>> a) are clearly private, so people know they should not start using
>> explicitly h5py_serial or h5py_mpi;
>>
>> b) will not clash with anything upstream may adopt in the future, a
>>
On 2020-03-03 18:40, Thibaut Paumard wrote:
Hi Drew,
Le 02/03/2020 à 17:33, Drew Parsons a écrit :
Like you, I would keep h5py_serial and h5py_mpi separate rather than
submodules of h5py. Mostly because the h5py folks could in the future
want to use those two names and do it in an incompatible
Hi Drew,
Le 02/03/2020 à 17:33, Drew Parsons a écrit :
>> Like you, I would keep h5py_serial and h5py_mpi separate rather than
>> submodules of h5py. Mostly because the h5py folks could in the future
>> want to use those two names and do it in an incompatible manner.
>
> Fair enough, I'll keep th
On 2020-03-02 23:58, Thibaut Paumard wrote:
Hi Drew,
I see, so you effectively copy all symbols from _h5py except those that
look like __foo__ which is Python internal stuff, *and* you give them
an
entry under h5py in sys.modules. Nice, that should be pretty stable.
Thanks for reviewing, Thi
Hi Drew,
I see, so you effectively copy all symbols from _h5py except those that
look like __foo__ which is Python internal stuff, *and* you give them an
entry under h5py in sys.modules. Nice, that should be pretty stable.
Actually, you don't treat public_api differently from weak_privates, and
y
On 2020-03-02 18:21, Thibaut Paumard wrote:
Le 01/03/2020 à 20:26, Drew Parsons a écrit :
your h5py suggestion of [...]
works up to a point.
Hi Drew,
Do I read correctly in your other mail that you have found a
workaround?
That's right, I've been building up my python-fu.
My first take w
Le 01/03/2020 à 20:26, Drew Parsons a écrit :
> your h5py suggestion of [...]
> works up to a point.
Hi Drew,
Do I read correctly in your other mail that you have found a workaround?
My first take would have been to apply my initial suggestion to each
individual sub-module but that depends on th
Source: h5py
Followup-For: Bug #944769
Combination of setattr and resetting entries in sys.modules to the
h5py namespace seems to get the job done.
Source: h5py
Followup-For: Bug #944769
Hi Thibaut,
your h5py suggestion of
if MPI_ACTIVE:
from h5py_mpi import *
else:
from h5py_serial import *
works up to a point.
But it's not a full and simple solution because of the way Python
handles submodules.
Some of the internal files, li
severity 944769 serious
thanks
Bumping this back up to serious since it hasn't been addressed yet.
It's just not acceptable that this package is not usable when the host
is offline. Hopefully we can see this addressed soon. Thanks.
jamie.
servo:~ 0$ python3 -c 'import h5py'
--
Hi Drew,
Le 27/01/2020 à 05:40, Drew Parsons a écrit :
> from os import getenv as os_getenv
> OPENMPI_MULTIPROC = os_getenv('OMPI_COMM_WORLD_SIZE') and
> int(os_getenv('OMPI_COMM_WORLD_SIZE')) > 1
> MPICH_MULTIPROC = os_getenv('MPI_LOCALNRANKS') and
> int(os_getenv('MPI_LOCALNRANKS'))>1
>
Source: h5py
Followup-For: Bug #944769
It might not be so simple. Some of the code is cython, so the obvious
runtime tests don't work, not via os.getenv at least.
For instance, the instance of "if MPI:" in api_types_ext.pxd can be
patched to
from os import getenv as os_getenv
OPENMPI_MULTIP
Source: h5py
Followup-For: Bug #944769
Thanks for your analysis, Thibaut. Testing OMPI_COMM_WORLD_SIZE and
MPI_LOCALNRANKS is a decent idea. Fair enough that non-MPI users
shouldn't have to worry about MPI settings (the MPI capability should
be transparent if not explicitly invoked).
Drew
Le 15/11/2019 à 11:21, Thibaut Paumard a écrit :
> There are ways to detect whether a job is running under MPI (at least as
> far as OpenMPI is concerned, I did not find the equivalent for MPICH).
>
> What I do in my own code is checking for the environment variable
> OMPI_COMM_WORLD_SIZE. If it e
Dear Jamie,
Le 15/11/2019 à 09:48, Jameson Graef Rollins a écrit :
>
> I'm sorry, but I strongly disagree. This situation is not artificial in
> any way. This bug was triggered by the default configuration on my
> laptop when my primary network interface was down, a very common
> situation.
On Fri, 15 Nov 2019 15:36:23 +0800 Drew Parsons wrote:
> Package: python3-h5py
> Version: 2.10.0-2
> Followup-For: Bug #944769
> Control: severity -1 important
>
> I don't think this issue warrants severity Serious.
>
> The failure is not triggered simply by having no network connection.
> It is
Package: python3-h5py
Version: 2.10.0-2
Followup-For: Bug #944769
Control: severity -1 important
I don't think this issue warrants severity Serious.
The failure is not triggered simply by having no network connection.
It is only triggered if there is no network interface at all. The only
way ther
Package: python3-h5py
Version: 2.10.0-2
Severity: serious
The latest version of h5py compiled against MPI completely fails to
import if there is no network connection:
servo:~ 0$ python3 -c 'import h5py; print("foo")'
--
No n
18 matches
Mail list logo
