Our lab uses numpy-stl as part of our regression testing framework and we've (so far) left numpy-stl unpinned. The 2.15 update broke one of our test cases and it seems to be related to ASCII file parsing. For now we will pin to 2.14.2 so a hotfix isn't urgent, but I think it's a legitimate bug.
I developed a Docker container which illustrates the issue and can be pulled from Dockerhub as benjaminbrelje/numpystlbug. It's basically a vanilla ubuntu image with python3, pip3, git, and numpy-stl installed along with the stl file in question (bwb.stl). It also fails across a variety of Ubuntu and Centos 7 setups in our build matrix.
The following Python console action should work (and does work in 2.14.2) but errors out as of 2.15.
From the host:
$ docker run -it benjaminbrelje/numpystlbug
In the container:
root@52e18fd1544c:/# cd ~
root@52e18fd1544c:~# dir
bwb.stl
root@52e18fd1544c:~# python3
Python 3.8.5 (default, Jul 28 2020, 12:59:40)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from stl import mesh
>>> a = mesh.Mesh.from_file('bwb.stl')
Traceback (most recent call last):
File "/usr/local/lib/python3.8/dist-packages/stl/stl.py", line 218, in _ascii_reader
assert get().lower() == b('endloop')
AssertionError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.8/dist-packages/stl/stl.py", line 71, in load
name, data = cls._load_ascii(
File "/usr/local/lib/python3.8/dist-packages/stl/stl.py", line 241, in _load_ascii
return name, numpy.fromiter(iterator, dtype=cls.dtype)
File "/usr/local/lib/python3.8/dist-packages/stl/stl.py", line 223, in _ascii_reader
raise RuntimeError(recoverable[0], e)
RuntimeError: (False, AssertionError())
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.8/dist-packages/stl/stl.py", line 378, in from_file
name, data = cls.load(
File "/usr/local/lib/python3.8/dist-packages/stl/stl.py", line 90, in load
name, data = cls._load_binary(fh, header,
File "/usr/local/lib/python3.8/dist-packages/stl/stl.py", line 110, in _load_binary
assert count < MAX_COUNT, ('File too large, got %d triangles which '
AssertionError: File too large, got 1970216992 triangles which exceeds the maximum of 100000000
>>>
Our lab uses numpy-stl as part of our regression testing framework and we've (so far) left numpy-stl unpinned. The 2.15 update broke one of our test cases and it seems to be related to ASCII file parsing. For now we will pin to 2.14.2 so a hotfix isn't urgent, but I think it's a legitimate bug.
I developed a Docker container which illustrates the issue and can be pulled from Dockerhub as benjaminbrelje/numpystlbug. It's basically a vanilla ubuntu image with python3, pip3, git, and numpy-stl installed along with the stl file in question (bwb.stl). It also fails across a variety of Ubuntu and Centos 7 setups in our build matrix.
The following Python console action should work (and does work in 2.14.2) but errors out as of 2.15. From the host:
$ docker run -it benjaminbrelje/numpystlbug
In the container:Downgrading to 2.14.2 fixes the problem:
The stl file in question is located here: https://github.com/mdolab/pygeo/blob/master/tests/inputFiles/bwb.stl
Thank you for providing this useful package!