Skip to content

Conversation

@h-mayorquin
Copy link
Collaborator

To track if everything works.

@h-mayorquin h-mayorquin added testing Related to test routines continuous integration Related to CI packaging Related to packaging/style labels Oct 15, 2024
@h-mayorquin h-mayorquin self-assigned this Oct 15, 2024
@h-mayorquin
Copy link
Collaborator Author

As @chrishalcrow mentioned, numba is at the moment the problem in all the architectures:

numba/numba#9413

So even more reasons for #3480

@zm711
Copy link
Member

zm711 commented Oct 15, 2024

And windows failing due to the NumPy issue:

Windows fatal exception: access violation

@h-mayorquin h-mayorquin mentioned this pull request Jan 7, 2025
@h-mayorquin
Copy link
Collaborator Author

Updated neo, getting failures with waveforms though.

@alejoe91
Copy link
Member

Updated neo, getting failures with waveforms though.

very weird failure though. Seems like an f-string is badly fomratted

@zm711
Copy link
Member

zm711 commented Jan 20, 2025

src/spikeinterface/core/tests/test_waveform_tools.py:110: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
src/spikeinterface/core/waveform_tools.py:102: in extract_waveforms_to_buffers
    distribute_waveforms_to_buffers(
src/spikeinterface/core/waveform_tools.py:288: in distribute_waveforms_to_buffers
    processor.run()
src/spikeinterface/core/job_tools.py:409: in run
    res = self.func(segment_index, frame_start, frame_stop, worker_ctx)
src/spikeinterface/core/waveform_tools.py:389: in _worker_distribute_buffers
    wfs = np.load(str(filename), mmap_mode="r+")
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/numpy/lib/_npyio_impl.py:481: in load
    return format.open_memmap(file, mode=mmap_mode,
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/numpy/lib/format.py:955: in open_memmap
    shape, fortran_order, dtype = _read_array_header(
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/numpy/lib/format.py:644: in _read_array_header
    d = ast.literal_eval(header)
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ast.py:105: in literal_eval
    return _convert(node_or_string)
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ast.py:94: in _convert
    return dict(zip(map(_convert, node.keys),
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ast.py:83: in _convert
    return tuple(map(_convert, node.elts))
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ast.py:104: in _convert
    return _convert_signed_num(node)
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ast.py:78: in _convert_signed_num
    return _convert_num(node)
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ast.py:69: in _convert_num
    _raise_malformed_node(node)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

node = <ast.Call object at 0x1078af0a0>

    def _raise_malformed_node(node):
>       raise ValueError(f'malformed node or string: {node!r}')
E       ValueError: malformed node or string: <ast.Call object at 0x1078af0a0>

/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ast.py:66: ValueError

Sorry I just need to be able to see the trace easily. Isn't this saying that in numpy >2.0 the way the multiprocessing is being done isn't working quite right? We might need to see if there are problems in those libraries no?

@alejoe91
Copy link
Member

src/spikeinterface/core/tests/test_waveform_tools.py:110: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
src/spikeinterface/core/waveform_tools.py:102: in extract_waveforms_to_buffers
    distribute_waveforms_to_buffers(
src/spikeinterface/core/waveform_tools.py:288: in distribute_waveforms_to_buffers
    processor.run()
src/spikeinterface/core/job_tools.py:409: in run
    res = self.func(segment_index, frame_start, frame_stop, worker_ctx)
src/spikeinterface/core/waveform_tools.py:389: in _worker_distribute_buffers
    wfs = np.load(str(filename), mmap_mode="r+")
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/numpy/lib/_npyio_impl.py:481: in load
    return format.open_memmap(file, mode=mmap_mode,
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/numpy/lib/format.py:955: in open_memmap
    shape, fortran_order, dtype = _read_array_header(
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/numpy/lib/format.py:644: in _read_array_header
    d = ast.literal_eval(header)
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ast.py:105: in literal_eval
    return _convert(node_or_string)
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ast.py:94: in _convert
    return dict(zip(map(_convert, node.keys),
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ast.py:83: in _convert
    return tuple(map(_convert, node.elts))
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ast.py:104: in _convert
    return _convert_signed_num(node)
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ast.py:78: in _convert_signed_num
    return _convert_num(node)
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ast.py:69: in _convert_num
    _raise_malformed_node(node)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

node = <ast.Call object at 0x1078af0a0>

    def _raise_malformed_node(node):
>       raise ValueError(f'malformed node or string: {node!r}')
E       ValueError: malformed node or string: <ast.Call object at 0x1078af0a0>

/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ast.py:66: ValueError

Sorry I just need to be able to see the trace easily. Isn't this saying that in numpy >2.0 the way the multiprocessing is being done isn't working quite right? We might need to see if there are problems in those libraries no?

I think I read it very wrong :P

@alejoe91 alejoe91 mentioned this pull request Jan 24, 2025
@alejoe91 alejoe91 merged commit fadc9b7 into SpikeInterface:main Jan 24, 2025
12 of 15 checks passed
@h-mayorquin h-mayorquin deleted the support_python_3.13 branch January 24, 2025 20:35
@h-mayorquin h-mayorquin restored the support_python_3.13 branch January 24, 2025 20:35
@h-mayorquin h-mayorquin deleted the support_python_3.13 branch January 24, 2025 20:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

continuous integration Related to CI packaging Related to packaging/style testing Related to test routines

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants