<kintel>
I guess it's still possible to try py2exe or smth. to see if it gets significantly faster, but it doesn't sounds like it's worth the extra complexity
<InPhase>
I tested pyinstaller, and that slows it down a notch.
<InPhase>
The viable solutions are an image comparison python server, and converting it to C++. I could theoretically do the latter, but I think it's a bad idea simply because it will strongly discourage future changes to it.
<kintel>
Agreed :)
<InPhase>
And I think that there might be future comparison types we'd want for different image types, or maybe even an additional different type of comparison as an augment. An example of what this would miss: 2 pixel wide vertical stripes going completely down the whole image. It will report it's the same.
<InPhase>
Now I wasn't worried about that as a likely issue when designing it, but it could happen.
<kintel>
Btw. did you try to run all the Heavy tests as well?
<kintel>
I was thinking we should set up the CI to run those occasionally
<InPhase>
A closer example to what would fail that does matter: z-axis fighting. Most z-axis fighting will fail to be detected as an image difference, as a lot of it shows up as thin stripes. This is probably an asset for most of what the tests are testing. But maybe we want to actually defeat z-axis fighting in images someday, and test against it.
<InPhase>
I did not. What's the magic spelling to run heavy tests?
<InPhase>
I'm about to head out but I can set that running.
teepee has joined #openscad
<InPhase>
Ah, I see it in the docs.
<InPhase>
Oh, that's it?
<InPhase>
Only 8 seconds. All passed.
<InPhase>
(26 of them)
<InPhase>
I'm not sure these count as heavy enough to need to be separate. :)
<kintel>
huh
<kintel>
I think the initial qualifier for initially tagging tests as heavy was > 10s runtime on my 2010 laptop or smth.
califax has quit [Remote host closed the connection]
califax has joined #openscad
<peeps[zen]>
InPhase: what is the venv used for that existing python scripts aren't doing? is it just for setting env variables?
<peeps[zen]>
oh, *reading some venv documentation* ... so packages can be installed per venv
guerd87 has quit [Read error: Connection reset by peer]
<peeps[zen]>
and looks like it installs packages anew for any build/tests dir (with downloads cached)
<kintel>
Yeah, until now we were very careful not to incur any dependencies in python scripts
<peeps[zen]>
InPhase: sorry, i haven't messed with python venv before. i'm wondering though, you mentioned overhead of another python process; could test_cmdline_tool.py conditionally import image_compare.py and just call functions instead of subprocess?
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<InPhase>
peeps[zen]: Yes, certainly.
<peeps[zen]>
InPhase: do you think that would speed up testing overall?
<InPhase>
peeps[zen]: Although the venv must be done at the time of launching python, so that means cmdline_tool.py needs to be launched with that tests/venv/bin/python
<peeps[zen]>
yeah
<InPhase>
peeps[zen]: I think test_cmdline_tool.py is called once per test, right?
<InPhase>
The benefit only comes if we have something that is called like once per run, or once per large group.
<peeps[zen]>
i think except maybe in some oddball tests
<InPhase>
peeps[zen]: And yeah, the caching provides a nice benefit if you're local at least. It should rarely redownload those packages, but it will reinstall them if you keep deleting the build directory.
<InPhase>
Personally, I have been obsessively deleting the build directory because I grow weary of chasing my tail over build inconsistencies. So I script deleting it on clean builds to be really clean.
<InPhase>
But watching it live that venv setup is as fast as any other similarly sized step in that cmake sweep, so I think it blends in well.
<InPhase>
If we added a massive pile of libraries, it would grow, but we could easily add a few more helpful ones with no additional burden.
<InPhase>
I could imagine scipy for its stats module, for example, as potentially useful for an image comparison.
<peeps[zen]>
cd .. && rm -rf build && mkdir build && cd build
<peeps[zen]>
i call that all the time, heh. usually ctrl-r 'cd .. ' and hit enter
<InPhase>
Oh, one other really good package: cairosvg would let us feed svg files straight into PIL, so we could test svg images directly.
<InPhase>
The regression folder currently contains no svg files and no pdf files.
<InPhase>
There's a numpy-stl package, which would need an entirely different script, but the same environment could be reused.
<InPhase>
Also there's a python ezdxf package.
<InPhase>
So we have things we could test that we've just been kind of ignoring because of a lack of infrastructure.
<InPhase>
If it grew to a set, we could break the list out of that cmake file into a standard requirement file, and pip install from that.
<peeps[zen]>
yeah i've actually used ezdxf before, for some lasercutting files
<InPhase>
Those requirement files let you list out version constraints and such in an orderly manner.
kintel has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<gbruno>
[github] rcolyer pushed 1 additions 18 modifications (Switch to new image_compare.py for testing (#4506) * Switch to new image_compare.py for testing * Update testing documentation for image_compare * Add python pip to msys2 build * Update outdated expected results for tests * Disable issue3158 test for macos) https://github.com/openscad/openscad/commit/4b7ff1569a9cc92bc194e5fb6d67d0c9c9b07f2e
TheCoffeMaker has quit [Ping timeout: 246 seconds]
TheCoffeMaker has joined #openscad
<InPhase>
guerd87: Generally resources like a python engine should have a central object in charge of managing them, and tasks for it should dispatch through the object in charge of managing the resource so that it can manage thread synchronization and resource availability.
<InPhase>
guerd87: This also makes maintainability easier by centralizing where you would make changes to upgrade or swap out the backing for a component, because the rest of the code is following a well-defined internal API.
guso78 has joined #openscad
<guso78>
Applications of linear_extrude with dynamic profile appear infinite ...
<guso78>
InPhase, you are correct by having a central python resource. But its strongly reccomended to reset its state right in the beginninning, else the curent code might work with variables set in the previous version ,
<guso78>
then the code works , but if reopened again it appears not work work anymore for no reason ...
guso789 has joined #openscad
aiyion has quit [Ping timeout: 255 seconds]
aiyion has joined #openscad
nbr0wn has joined #openscad
RichardPotthoff has joined #openscad
RichardP_ has quit [Read error: Connection reset by peer]
RichardP_ has joined #openscad
Richar___ has joined #openscad
RichardPotthoff has quit [Ping timeout: 246 seconds]
RichardP_ has quit [Ping timeout: 246 seconds]
guso78 has quit [Quit: Client closed]
aiyion has quit [Ping timeout: 255 seconds]
aiyion has joined #openscad
epony has quit [Remote host closed the connection]
epony has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
Guest24 has joined #openscad
Guest24 has quit [Client Quit]
teepee has quit [Quit: bye...]
<InPhase>
guso789: Certainly, a reset will be critical. It should actually probably be cleared out as soon as it finishes running, otherwise the python process will hold onto potentially huge amounts of memory.
<InPhase>
guso789: Lessons from a person overseeing a bunch of analysts: Never underestimate how much RAM people can find a way to eat in their code. ;)
teepee has joined #openscad
<InPhase>
One of my weekend late night work activities is sometimes clearing out processes from people holding 100GB worth of data in RAM in python on the work server and just leaving it there when they go home.
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
califax has quit [Ping timeout: 255 seconds]
guso78 has joined #openscad
califax has joined #openscad
aiyion has quit [Remote host closed the connection]
califax has quit [Remote host closed the connection]
califax has joined #openscad
guso789 has quit [Ping timeout: 260 seconds]
<peepsalot>
iirc ~95% of leaks are Qt related
<peepsalot>
because it handles lifetime management like a black box
use-value has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
<JordanBrown[m]>
guso789: InPhase at least in my MSYS2 build, your Python support does not appear to compile in a Python engine. Rather, it uses a shared object from elsewhere in the system. One of the key problems that I see with my build is that at build time it finds the Python DLL, but at run time it does not.
<JordanBrown[m]>
It's not using an external Python process, but it does appear to use the engine from an external Python installation.
<InPhase>
JordanBrown[m]: Correct. Having python is a requirement of the testing paradigm.
<InPhase>
A pre-existing requirement.
<InPhase>
JordanBrown[m]: However the build should still proceed without this in place.
<InPhase>
JordanBrown[m]: I'm not sure what you mean about the Python DLL though. Can you show the portion of the cmake output where it does the venv setup? It calls the exact same python script in the same manner with the venv python during the cmake run as would happen later in the testing run, so there should be no good opportunity for differences here.
<InPhase>
It would require some externally created difference in environment to break that.
<InPhase>
JordanBrown[m]: Oh, I suppose one difference. It has working directory ${CCSD} instead of ${CCBD}. Do you have some sort of setup with a dll that is on sourceroot/tests but then you run testing from build/tests?
<InPhase>
That might require you to do an additional copy step if you have such a dependency. But I'm not sure if that should count as something that should be additionally handled automatically. The formal pre-existing testing requirement is that python be executable.
<InPhase>
JordanBrown[m]: I've learned that scripts/msys2-install-dependencies.sh is used by the CI, and that particular setup approach does seem to work reliably.
Guest7 has joined #openscad
Richar___ has quit [Read error: Connection reset by peer]
RichardPotthoff has joined #openscad
<JordanBrown[m]>
InPhase the context was the Python-capable OpenSCAD program, not your Python-based testing.
<JordanBrown[m]>
that (at least in my build of your work) it is depending on an externally-supplied Python engine, in shared-object form.
<guso78>
ahh i see. the comment about the dll now.
<guso78>
I believe 1st test is to put the DLL in the same directory as the exe file and see if it runs, then.
<JordanBrown[m]>
I haven't gotten that far - I got it running by supplying a $PYTHONPATH that pointed at it.
guso78 has quit [Ping timeout: 260 seconds]
guso78 has joined #openscad
<guso78>
i have another branch, called python-win, which does some more windows-friendly stuff
<guso78>
issue is, that i cannot check in stuff in msys2
<guso78>
the special githib authenticvation setup is not done there.
<guso78>
but of course: i *can* and *do* set some environment shell variables from within the openscad
<guso78>
2 options: a) i am able to check in in msys2
<guso78>
or * a can send screenshots of my diffs
califax has quit [Remote host closed the connection]
califax has joined #openscad
guso78 has quit [Ping timeout: 260 seconds]
guso78 has joined #openscad
<guso78>
bad connection today
<guso78>
char *evaluatePython(const char *code)
<guso78>
{
<guso78>
putenv("PYTHONHOME=/mingw64");
<guso78>
.. and i flatten myself, that this CMakelists.txt would become useful sometime ...
califax has quit [Remote host closed the connection]
<guso78>
set(CMAKE_FIND_LIBRARY_SUFFIXES .a)
guso7886 has joined #openscad
guso78 has quit [Ping timeout: 260 seconds]
guso7886 has quit [Ping timeout: 260 seconds]
ur5us has joined #openscad
califax has joined #openscad
guso78 has joined #openscad
<JordanBrown[m]>
I am not 100% sure, but I don't think that MSYS2 ships with a Python in .a form. There's a libpython3.10.dll.a, but that appears to be stubs used somehow to link to the .dll.
califax has quit [Remote host closed the connection]
califax has joined #openscad
guso78 has quit [Ping timeout: 260 seconds]
califax has quit [Remote host closed the connection]
<JordanBrown[m]>
guso78 I said $PYTHONPATH above, but I meant $LD_LIBRARY_PATH.
guso78 has joined #openscad
<guso78>
Jordan, check the size of the .a file. if its about same size then the dll, then you are fine.
califax has joined #openscad
<JordanBrown[m]>
It's 1/3 the size.
<JordanBrown[m]>
$ ls -lh /mingw64/*/libpython*
<JordanBrown[m]>
-rw-r--r-- 1 Jordan Jordan 1.1M Dec 10 01:13 /mingw64/lib/libpython3.10.dll.a
<JordanBrown[m]>
-rwxr-xr-x 1 Jordan Jordan 3.3M Dec 10 01:13 /mingw64/bin/libpython3.10.dll
<guso78>
hmm, i cant say. the .a file is definitely bigger than just stubs
<guso78>
Jordan, i was able to launch the openscad from msys2 environment WITH Python. 1st run, the program started and stopped with a Python error(some python configs are not found)
<guso78>
when tweeking with the PYTHON_HOME i got finally working in my place, but is was probably just luck in my side.
<guso78>
hmm i believe that most size of the archive is made of archieve overhead haha
<JordanBrown[m]>
Right.
<JordanBrown[m]>
I should probably tear down and recreate my MSYS2 environment. However, I'll try it on a different computer first.
guso785 has joined #openscad
guso78 has quit [Quit: Ping timeout (120 seconds)]
guso785 has quit [Ping timeout: 260 seconds]
guso78 has joined #openscad
dalias has quit [*.net *.split]
niyawe has quit [*.net *.split]
BZK[m] has quit [*.net *.split]
zingos has quit [*.net *.split]
siege has quit [*.net *.split]
dalias_ has joined #openscad
siege has joined #openscad
zingos5 has joined #openscad
niyawe has joined #openscad
<LinuxHackerman>
Jordan Brown: teepee: InPhase: thanks for the stuff you said to my caching question the other day -- I missed it for some reason but the animate approach is the best kind of cursed hahaha
<othx>
guso78 linked to YouTube video "Cuboctaeder gears" => 1 IRC mentions
<guso78>
just need to change to ratio in the gear motor to look more impressive, haha
<guso78>
ahh, othx is another bot
<JordanBrown[m]>
othx?
<othx>
othx is a bot run by gunnbr. othx supports factoids, seen, and tell. Email gunnbr@gthx.net if there are any problems.
<guso78>
jordon did you also see these bot messages or are they private to me ...
<JordanBrown[m]>
AFAIK they are public. It said "guso78 linked to ..." when you mentioned the YouTube video,and it described itself when I said its name as a question.
guso7876 has joined #openscad
<linext>
anyone want to join a team to try to win instructables contests?
guso7884 has joined #openscad
<InPhase>
LinuxHackerman: I suppose with a name like Hackerman you are undetered by the monstrosity of using animate for this. :)
<LinuxHackerman>
InPhase: it's actually just a slight corruption of my legal name, but these things definitely _entertain_ me though I'll usually think twice about using them ^^
<InPhase>
guso7884: Did your branch add .py script tests to the testing suite? Working on adding that if not there yet will really help with cross-platform validation, because then at least we'll know that it works on one setup of each of the target platforms.
<InPhase>
guso7884: doc/testing.txt for info on that
<guso7884>
InPhase, no tests yet, but i realize we need to have them
<guso7884>
is it possible to have a template with only one skeleton test and i would add as many i as i can think of ?
<guso7884>
intially i dont want to see 1586 tests run + mine extra 1 python test ...
<guso7884>
i will have a look into the texting.txt, though
<InPhase>
guso7884: Having one would be a huge benefit for making sure it even runs. :)
<InPhase>
guso7884: So certainly start with 1, and then add more in later.
<InPhase>
guso7884: Often they're clumped to related concepts in a file. Like, there's a comparisons test which does echo of the results of a whole bunch of < > == != comparisons of different types.
guso7876 has quit [Quit: Ping timeout (120 seconds)]
guso7884 has quit [Ping timeout: 260 seconds]
guso78 has quit [Ping timeout: 260 seconds]
guso78 has joined #openscad
califax has quit [Remote host closed the connection]
<retrosenator>
my computer is too slow for openscad??
<retrosenator>
is it possible to somehow use distributed computing?
<retrosenator>
and i can get remote services to render my script
<JordanBrown[m]>
I use a ~10 year old laptop and ~10 year old desktop, both nearly bottom-of-the-line when bought, and they work OK.
<JordanBrown[m]>
The most common reason that people think that OpenSCAD is slow on their computer is that they have set $fn to something unreasonably large.
teepee_ has joined #openscad
snaked has quit [Ping timeout: 256 seconds]
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<JordanBrown[m]>
retrosenator: What are your computer's specs? Can you post a copy of the script that you are finding is too slow at https://bpa.st/ and then give a link here?
<Scopeuk>
Or used minkowski recursively
<JordanBrown[m]>
Or used minkowski at all :-(
<guso7894>
the tests documention is too short for me, i am totally new to testing
<guso7894>
a) dont need a new "app" because python stuff is there already, right ?
<guso7894>
or is it a new "app" because python was previously used for another "purpose" ?
<guso7894>
i have created a primitives.py file. will it automatically be found and test comparison picture created when i run with the "create test option" ?
<JordanBrown[m]>
My bet is that you have to add an add_cmdline_test to tests/CMakeLists.txt, a matching *.py script, and hand-inspected "correct" images.
<JordanBrown[m]>
actually, no, make that experimental_tests.
<JordanBrown[m]>
I suspect that the reason that I was having dynamic link trouble is that CMake found my Windows install of Python instead of finding my MSYS2 install. I have uninstalled the Windows copy and we'll see how it goes.