<InPhase>
I was sold on that being a performance computer right up until the last line in the table. ;)
<linext>
anything i need to do on linux can be in a VM
<InPhase>
Oh, but please take this experience-based advice seriously... You would really benefit swapping out that Samsung M2 for a WD.
<InPhase>
I've had 2 of 2 Samsung M2's die on me, and zero WD M2's die on me.
<InPhase>
I don't know what they're doing to those, but across multiple generations they seem to have some serious quality control issues.
<InPhase>
Straight up data-loss hardware deaths.
<linext>
hmmm...
<linext>
i've been running several samsung m.2 over the years and have had no problems
<linext>
same with the samsung 2.5" drives
<linext>
also, i chose an older model so it's likely they fixed whatever bugs occurred
<InPhase>
Personally I've sworn off further Samsung M.2 drives. I don't even care what the price difference is, it's not worth buying the stupid drive twice and going through all the pain of setting everything up against.
<InPhase>
s/against/again/
<InPhase>
I think the longest one lasted 18 months, which is way under my expectations.
<linext>
did you keep putting the same m.2 into the same motherboard?
<InPhase>
Nope, completely separate computers.
<InPhase>
Both times I swapped out with a WD afterward, and had no further issues.
<InPhase>
I figured it was a fluke until it happened exactly the same way a second time.
<InPhase>
No unusual disk abuse or anything was happening.
<InPhase>
The thermals were a little bad on the first system, but the WD handled them fine. The thermals were fine on the second system, so it wasn't attributable to that.
<linext>
i have a heatsink and fan on mine
<InPhase>
Yeah, I had 100% health until the day it died both times. :)
<InPhase>
I had a daily health monitor running, and the last date of my backups it still recorded perfect health.
<InPhase>
I think it was a controller level issue, rather than what they monitor in the health report.
<InPhase>
They weren't even the same lines. A 1TB and a 2TB.
<linext>
maybe the same controller?
<InPhase>
Possible. A 960EVO and a 970EVO.
<InPhase>
But, just my advice if it's not too late to change the order. Your ultimate experience may vary. Or you might kick yourself. One of those will happen. :)
leptonix has quit [Ping timeout: 252 seconds]
<InPhase>
That aside, the processor and RAM look really nice. OpenSCAD build times should be pretty sweet.
<InPhase>
I'm going to bet 1m52s.
J232527 has joined #openscad
J2325 has quit [Ping timeout: 260 seconds]
<linext>
i bought the RAM, CPU, and motherboard as a bundle from microcenter
<linext>
all together $800
<L29Ah>
i compile gentoo daily for years on my 970 EVO Plus
<L29Ah>
<3 it
leptonix has joined #openscad
<L29Ah>
will buy samsung m.2 when it finally breaks (expected in 30 years according to the current wear rate)
<L29Ah>
02:28:15]<InPhase> I think the longest one lasted 18 months, which is way under my expectations.
<L29Ah>
how was the warranty?
<linext>
yea, warranty is 5 year
epony has joined #openscad
<InPhase>
L29Ah: It doesn't matter. There's no way to wipe an M.2 with a defective controller, so you cannot send it back for repair unless you want to hand over all of your data to the only people equipped to replace the bad controller.
<InPhase>
Old magnetic drives could be wiped, but these nvme ones cannot be.
<InPhase>
And anyway, the time lost recovering from a lost hard drive costs me the same or sometimes more than a drive. That's the real price.
<InPhase>
And there's a risk of losing up to multiple days worth of work, depending what I'm working on and when my last backup was. I got very lucky both times that I was able to recover and piece back together almost everything without any significant gaps. And neither time was right before a major deadline, which could be even more costly.
<L29Ah>
03:51:40]<InPhase> L29Ah: It doesn't matter. There's no way to wipe an M.2 with a defective controller, so you cannot send it back for repair unless you want to hand over all of your data to the only people equipped to replace the bad controller.
<L29Ah>
no probs, i have full disk encryption anyway
<L29Ah>
i recommend automatic daily backups with borgbackup
<L29Ah>
non-RAID data storage, and, in particular, TLC NAND aren't renowned for their reliability after all
<InPhase>
I have too much data for reasonably priced online backups, and require too much performance for full disk encryption.
<InPhase>
Also NAND storage in general is much more reliable than magnetic drives, despite the undeserved reputation. It is multiples harder to lose data. I in fact did not lose data, I just didn't have the resources to identify and swap out the broken controller module. Overall, 5 year disk loss from magnetic drives is somewhere around 4 times higher than modern ssd drives.
<InPhase>
That is why losing 2 of the same brand was remarkable to me. It should never happen like that without defective manufacturing.
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<peepsalot>
so i split out much of Value.h, but it seems not practical to split out nested classes of VectorType,EmbeddedVectorType and ObjectType, since they are all recursively dependent
<InPhase>
Did you resolve the questions you were asking the other night? I just remembered you had asked something and I read it in too sleepy of a state to reply.
<peepsalot>
InPhase: well I was trying to decide if i could/should split those remaining recursive classes into separate headers + sources
<peepsalot>
and i came to the conclusion that its not worth doing
<kintel>
peepsalot In case you're still wishing you could split out VectorType, you might find some patterns in https://github.com/nlohmann/json, which is another recursive data structure. They use a union rather than a variant as storage though, but the code is pretty modern
<kintel>
I can take a look at your PR this week-end, unless InPhase beats me to it :)
<peepsalot>
nice, thanks. rebooting brb
peepsalot has quit [Quit: Connection reset by peep]
Guest25 has joined #openscad
Guest25 has quit [Client Quit]
peepsalot has joined #openscad
guerd871 has quit [Read error: Connection reset by peer]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
guerd87 has joined #openscad
Teslamax has quit [Read error: Connection reset by peer]
Teslamax has joined #openscad
Guest89 has joined #openscad
Guest89 has quit [Client Quit]
epony has quit [Ping timeout: 268 seconds]
use-value has quit [Remote host closed the connection]
use-value has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
castaway has joined #openscad
Guest27 has joined #openscad
guso7878 has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
Guest27 has quit [Quit: Client closed]
teepee has joined #openscad
milza has joined #openscad
<guso7878>
which are all the requirements that python interpreter can merge into the development branch ? (apart from having a good security concept in place) ?
pie_ has quit []
pie_ has joined #openscad
clemens3 has quit [Ping timeout: 272 seconds]
hrberg has joined #openscad
qeed has quit [Read error: Connection reset by peer]
epony has joined #openscad
qeed has joined #openscad
snaked has quit [Quit: Leaving]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<guso7878>
did anybody design a sketch for the new python code-checking forms ?
<InPhase>
Code-checking form?
<guso7878>
to make sure, that any newly intrroduced python snipped is safe ...
<teepee>
I don't know what that means either, for the time beeing my point of view is that the python part would be not safe and that it (or exactly the same safety as running any other python script)
<teepee>
as for merging, my list is not changed much
<teepee>
1) compile option to disable all python integration code statically with default = OFF
<teepee>
2) runtime-option to enable the python handling with default = OFF - needs to be in addition to the experimental flag (I'm not even sure we need the experimental flag it's a bit duplicate)
<teepee>
3) some sort of warning when running python code, maybe a bit more annoying than needed first, that's likely going to need lots of tweaking when going for a release
<teepee>
end-of-list
<teepee>
well, there's a basically implied 4) -> needs to compile and package on at least one platform, likely that's going to be Linux
<teepee>
it would be great if Linux AppImage would work, but that could also give some extra trouble so I would not see that as blocker
<guso7878>
clear message. thanks again tee-pee
<teepee>
with kintel back in action we need to cross-check with him as long-term maintainer, but I assume I can reason this scope :)
<teepee>
what did you mean with code-checking forms?
<kintel>
guso7878 I don't have any extra requirements for the python stuff. If we can statically exclude it and wrap it in a Feature, that's safe enough for now.
<teepee>
cool, my thinking is also that giving it into the hands of people, even if it's only on Linux for a start, could bring someone in who could help with dev / packaging / documentation / whatever else is needed
<teepee>
in other news, there's a small chance, I might get an older macbook as we just bought a collegue a brand new fully featured one for a company anniversary ;-)
<InPhase>
Runtime processing will need both a gui feature setting and a command line setting.
<InPhase>
Although I strongly urge that it should remain experimental until we get some sort of active confirmation guard in place.
<teepee>
nothing wrong with leaving that in, as it's already there
<guso7878>
will follow up later to implement my tasks
<teepee>
requiring a dedicated --enable-python reduces the strict need a bit, but having both will not hurt either
<InPhase>
It's going to be problematic if we release something that people who don't understand the implications can be instructed to turn on which then opens them up to new security risks without their awareness.
<InPhase>
People enable things all the time and then forget they have done so, particularly with the sticky gui settings.
<InPhase>
No confirmations are required for the command line settings, as that's already an assertive declaration of intent.
<teepee>
agreed, but we still have to actively switch the compile time switch for the release whenever that will happen
<InPhase>
guso7878: I can type up a description on github of what I think the structure of the confirmation system should look like. But where would you like such a description to be?
<kintel>
Also, the current implementation is GUI-only, which safeguard from the copy&paste cmd-line attack vector
<InPhase>
kintel: The hazard I'm concerned about primarily appears as soon as python can be included via libraries.
<InPhase>
Loading a python file directly in the gui is a non-zero hazard, but that's a lot more modest of a risk, and a lot more obvious.
<InPhase>
Nested stuff though, that's where this gets serious.
<kintel>
yeah, eventually finding a good solution is important, but shouldn't necessarily block merging.
<teepee>
collecting this in a dedicated issue is probably best
<teepee>
to separate from merging
<kintel>
..but a valid questions is, of course, whether this should be part of the regular snapshots or a separate download.
<InPhase>
guso7878: Will include and use currently process .py with your PR?
<teepee>
I'll create a python tag
Pablo71 has joined #openscad
<InPhase>
I just realized that's unclear from the PR description.
<kintel>
I agree with teepee that getting more brains involved in testing and discussing this could help surface both problems and solutions in this domain, so it's worth trying to get that attention
Pablo71 has quit [Quit: Client closed]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<JordanBrown[m]>
InPhase: I'm not 100% sure, but based on what's been said and skimming the changes, I don't believe this PR includes any interoperability between Python and the OpenSCAD language. I believe it is purely an alternative language running in the same UI, atop the same geometry engine.
<peepsalot>
are the tests suddenly much faster for anyone else? i can run the whole default suite in <20s now (Ryzen 3900X), when I run ctest -j32. i think i was previously seeing at least 50s or so
<peepsalot>
i wonder if something got fixed internally to ctest. i have complained in the past that it wouldn't fully utilize parallel jobs after the initial set of -jXX jobs
<teepee>
possible, the python compare is not merged yet
guso7847 has joined #openscad
<guso7847>
Jordan, you are right. Its Just another additional language and No Interoperabilität. Lets See If the Test exactly yield this result.
<peepsalot>
also i remember testing the upper limits of parallel jobs before, and beyond 100 or so i would start seeing many tests randomly failing. now i can bump it up to around -j1000 (1024 fails though)
<peepsalot>
not that those actually go any faster, but just a kinda interesting metric
<peepsalot>
12C/24T hardware FWIW
Lagopus has quit [Remote host closed the connection]
Lagopus has joined #openscad
<peepsalot>
InPhase: i was slightly concerned before about the added load of python image compare, but now it seems it may be even more significant (i think you said 200ms or so for each compare?)
<peepsalot>
time ctest -j24 ==> real 0m22.256s user 4m28.445s sys 1m14.377s 268.445 user seconds / 1549 = 173ms avg per test
guso7847 has quit [Quit: Client closed]
<peepsalot>
or with no parallelism: time ctest ==> real 4m0.624s user 3m10.115s sys 0m54.023s
<InPhase>
peepsalot: Are those times with or without my changes?
<peepsalot>
master branch, without
<InPhase>
peepsalot: The exact amount is going to vary by system. And it does boost the ctest time a bit, but not enough that it concerned me greatly.
<teepee>
for some reason it looks like github does not have any built-in debug stuff like CircleCI
<InPhase>
I considered several options to speed it up. One was to make a python process that you feed images to but it stays loaded, which ctest supports, but that sounded like an undesired cross-platform complication. The other is that the routine is actually simple enough (now that it's prototyped) that it could be plunked into a C++ program, with the hardest part being using all the right libraries for image
<InPhase>
loading.
<InPhase>
But the second one I thought might be a reduced utility because it prevents people from easily customizing and adjusting tests. I think Python is a friendlier custom test framework even if a bit slower.
<InPhase>
I however don't have any custom tests in mind, but I speculated it might be useful.
<peepsalot>
InPhase: have you looked at diffpng source at all?
<InPhase>
No.
<InPhase>
Okay, I've scrolled through it. 1300 lines for the code, 10k for png processing.
Lagopus has quit [Ping timeout: 252 seconds]
<InPhase>
The center algorithm seems a good bit more involved.
<InPhase>
But also less strict I think.
<InPhase>
teepee: I'm missing information. What exactly is this supposed to permit one to do? Also, it says it supports Windows (the only one with an issue), but all the examples say ubuntu?
<InPhase>
Also, it doesn't specify where those examples are supposed to go.
<teepee>
this gives a web ssh endpoint
<teepee>
.github/workflows/windows.yml
<teepee>
probably right before the "Upload Test Results"
<teepee>
hmm, actually, maybe it needs to go to the beginning to open the session early
<InPhase>
And will it then shut down after it finishes running?
RichardP_ has quit [Ping timeout: 268 seconds]
<InPhase>
Thus I would have some sort of narrow window to quick connect and do... some sort of diagnostic?
<teepee>
I'm not sure when it closes, it might keep the session until the timeout
<teepee>
if that's default github it would be 6h
<teepee>
the action seems to have it's own timeout too
<teepee>
ahh "Continue a workflow"
<teepee>
so it should go in the sequence where debug makes sense, after the build
<teepee>
and it would block the action from exiting until github times out or the marker file is created
<InPhase>
Ok. I see how to set it up, I think.
<InPhase>
I suppose the next question is do I need the default at the top or one of the other 20 examples. :)
<teepee>
for now I'd say the simple inline action
<teepee>
for a more permanent setup, we can figure out later how to set that up
<teepee>
with github logging it needs to spam the output as the full log is only available at the end
<JordanBrown[m]>
I don't know what a "submodule" really is. Do we have any control over mimalloc? Can we do anything about all of the warning messages?
<InPhase>
teepee: :( The command I'm using is shown again at the bottom of the paste.
<InPhase>
Because, you know, why not arbitrarily change directory names between platforms, just for fun.
<InPhase>
python.exe is, notably, not a script.
<teepee>
yeah, keep those developers on their toes :)
<teepee>
also upper case Scripts sounds so much better and probably is even Skripte on German windows ;-)
<InPhase>
I see the utility of the tmate feature. It sure is a lot better to actually be able to connect and see what's happening like a proper server.
<InPhase>
Well. I think that might have upgraded to an extra line in the error message clarifying that there is no pip module.
<InPhase>
pip however was definitely installed.
<teepee>
oh my, anyone we can ask to just drop Windows and macOS world wide and be done with that nonsense?
RichardPotthoff has joined #openscad
<JordanBrown[m]>
I suppose that I should try a modern Linux. I used Solaris as my primary work desktop for many years, but it was very much an improvement to move to an environment where things like copy and paste of things other than plain text could be expected to work.
<InPhase>
I did a proper "FindPackage" and everything to grab the right python.
<JordanBrown[m]>
Is there any chance that somebody will look at the objects stuff?
<InPhase>
JordanBrown[m]: I still intend to. And, apologize for the lag. :)
<teepee>
I want to, but there's no way this happening before end of next week unfortunately
<InPhase>
Probably would have been a better use of my time than trying to setup this updated image comparison. I got nerd-sniped by the elegant image comparison algorithm, and now I'm invested in fixing the stupid build process.
<JordanBrown[m]>
:-)
<JordanBrown[m]>
My biggest quandary is in the style of object / geometry literals, whether they are two separate things or one hybrid.
<InPhase>
I have an existing strong feeling on that, but I will set it aside for a bit when I go to actually test it, to see if that gives new insight.
<JordanBrown[m]>
I like the two-separate-things scheme better; it seems cleaner. But the hybrid scheme hints at being able to say something like o = import("foo.scad") and get the contents of the file as an object, which would be awesome for managing library namespace.
<teepee>
while I like the separate version a bit better, I think the hybrid one allowing the treatment of a script as objects is much more aligned with openscad as it is
<teepee>
:)
<InPhase>
Alignment with the language is my core pre-existing goal for this feature, because I think it will open up more options for blending things.
<InPhase>
Alright. I think I found a workaround within the tmate session.
<InPhase>
Apparently the bundled version with msys2 cannot create a venv unless you do it --without-pip, but then you can run -m ensurepip inside the newly created environment, and add pip in.
<InPhase>
It's unclear why this ends up different other than it just being weirdly broken, but it does.
<InPhase>
I went ahead and set that for all platforms, because maybe it's more robust for some reason.
<InPhase>
Now to confirm it didn't break the other platforms...
<teepee>
that indeed does sound broken
<teepee>
but if that workaround or whatever it is works everywhere, that how the real messy world of computers goes :)
<InPhase>
And if that passes, all that's left is to upgrade the failing test images so it passes again.
<JordanBrown[m]>
When thinking about o = import("foo.scad"), I have two things that I'm unhappy about. One is that (extrapolating from what I've got now), functions and modules wouldn't be exported. You could still export equivalents as variables containing function and module references. The other is that there's no way to have global variables that you do *not* want exported. One possible answer to that latter would be to take a page from
<JordanBrown[m]>
JavaScript and have an explicit "export" statement that specifies an object to return; that object could then contain whatever you wanted to export.
<InPhase>
A working theory... When you run python inside the environment, it front-loads loading libraries and such from its own directories. Maybe because this msys2 python is separate from the system python, when you install pip outside of the venv it picks up the wrong dll for something.
<InPhase>
The error code is reported as relating to a bad dll.
<InPhase>
But it doesn't do the courtesy of telling you which one.
<InPhase>
JordanBrown[m]: I think generally I'd prefer to export everything. But maybe you could look for a clean way to hide items.
<InPhase>
JordanBrown[m]: Default to export will make transition easier, because we can namespace clump all the existing library code out there, and immediately gain the benefits.
<InPhase>
JordanBrown[m]: Otherwise we will be unable to use anything existing with the new feature until someone edits in support for export.
<InPhase>
Which for most stuff, means never.
<JordanBrown[m]>
Good point.
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
<JordanBrown[m]>
We *could* automatically convert functions and modules into variables with references, but that only works if the library doesn't use the same names for any combination of the three. BOSL2, for instance, has function and module equivalents of most of its operations.
<JordanBrown[m]>
One might hope that we could lay the "when are globals evaluated" question totally to rest with this new scheme. (And that would be "at import time".)
<peepsalot>
JordanBrown[m]: a git submodule is like a symbolic link to another git repo, which has to be checked out separately. MCAD and mimalloc are the two submodules openscad currently depends on
<peepsalot>
JordanBrown[m]: what issues are you having with mimalloc?
<peepsalot>
fmt will likely be an additional submodule in the near future
<peepsalot>
with a cmake option to alternatively use a system package
<InPhase>
JordanBrown[m]: Well that doesn't look great.
<JordanBrown[m]>
Seems to work.
<peepsalot>
in terms of what control we have over mimalloc, as a submodule that entails choosing which commit (usually a release tag) to associate with openscad. as a 3rd party project on github, you can submit an issue or PR
<InPhase>
That looks like those sorts of annoying warnings you get when some structure was not parsed elegantly, and then it just refuses to understand what it's looking at, and yells at you.
<JordanBrown[m]>
The key thing is that it's not a copy, so we can't just fix it.
<InPhase>
JordanBrown[m]: Perhaps upstream report it, with a lot of details of your platform.
<peepsalot>
JordanBrown[m]: additionally you can customize the mimalloc specific build options in submodules/CMakeLists.txt
<InPhase>
Do we have anyone else mingw compiling locally?
<InPhase>
The CI seems to be using visual studio.
<JordanBrown[m]>
I haven't looked at them, because I suspected that I couldn't just fix them. As long as the make completed and the program runs, i just closed my eyes and said "I see nothing".
<InPhase>
Or, was that what I saw?
<InPhase>
Something. I'll check again when it finishes preparing the output.
<peepsalot>
InPhase: i have done the mxe cross compile not too long ago. or do you mean the msys2?
<JordanBrown[m]>
you mean in my paste? no, it's gcc AFAIK.
<InPhase>
nope, that was mingw.
<peepsalot>
both msys2 and mxe use mingw libaries AFAIK
<InPhase>
JordanBrown[m]: So the take-home message is that we're not getting warnings on the CI build for Windows, so it is something different between your system and that system.
<JordanBrown[m]>
Is CI an MXE build or an MSYS2 build?
<InPhase>
teepee: Excellent. All platforms setting up the environment, and failing on the same bad images. I think I'll take a little break, and worry about image replacement later.
<InPhase>
teepee: Thanks for the tmate suggestion.
<teepee>
nice!
<teepee>
dropping those different ways for comparison is great
<peepsalot>
JordanBrown[m]: there are both: circleCI does mxe builds, and i think a github action does msys2
<guso78>
sometimes my cmake compile take 2 mins and sometimes 10 mins. this is really strange
<peepsalot>
although I saw around Jan 15th that we ran out of circleCI credits for the month i guess
<InPhase>
guso78: Laptop?
<peepsalot>
do you have ccache installed?
<InPhase>
guso78: Also, to be clear, are you comparing clean builds both times?
<guso78>
yes, its a Linux VM in my laptop
<InPhase>
guso78: This script makes my life more convenient: https://bpa.st/UPLBS
<InPhase>
Guarantees a consistently setup clean build each time.
<guso78>
no, not clean builds. 1st build is quite fast, but when i jsut type make later, it realizes, that CMakelists is changed and subsequently takes much longer then.
<guso78>
i believe i will clean the build dir each time now to be fast
<InPhase>
guso78: The reason I asked if it was a laptop, because you can get serious build time decreases from throttling. If it's also warming up and fan-spinning at high speed, you might need to open it up and clean the dust out of the fan vents. :)
<guso78>
interesting script :)
<InPhase>
guso78: If you use it, adjust the 8 in -j8 to match your processor core count.
<InPhase>
Max performance is when these match.
<InPhase>
Unless you're throttling from heat, and then set it lower...
<guso78>
ok the compile time option is done. looking into the command line option
<InPhase>
Those are thankfully fairly easy to add. Just note they only impact command line runs, and do not impact gui settings.
<JordanBrown[m]>
I would turn -j up until you're running at 100% cpu, or until you see the minimum build time. Theoretically at least the optimum might be higher than the number of cores, if there's non-trivial I/O.
<teepee>
*if* you have plenty of memory
<JordanBrown[m]>
Well, yeah.
<JordanBrown[m]>
But if you don't have plenty of memory, get more :-)
<JordanBrown[m]>
Still, increase until you see minimum build time is never wrong.
<JordanBrown[m]>
I think I run 3 on my desktop, 2 on my slow laptop (with the 17" screen), and 4 on my fast laptop (with the 14" screen).
ur5us has quit [Ping timeout: 252 seconds]
<JordanBrown[m]>
My "build" script reads the right number from $HOME/.make.jobs.
<JordanBrown[m]>
Changing the topic to animation...
<JordanBrown[m]>
Having $t always vary from 0 to 1 is elegant, but often seems awkward. I want to be able to externally control how long the animation runs - not how many frames to generate, not how fast to display them, but how many iterations of the algorithm get executed. If I'm animating a wheel turning, I want to control how many times it turns. For the animation I'm looking at right now, my model train animation, I want to externally control
<JordanBrown[m]>
how far the train goes.
<JordanBrown[m]>
Of course I could use the customizer, but it seems like this is a parameter of the animation process, not of the model per se.
<JordanBrown[m]>
Also, once I like the frame rate, I want to be able to say "that, but longer".
<JordanBrown[m]>
Without having to do math :-)
<JordanBrown[m]>
Partly this might be addressed by exporting the current frame number and frame rate, or exporting the time in theoretical seconds.
<JordanBrown[m]>
"run forever" is also of interest, but with those values maybe that's just a matter of making the total number of frames really large.
<guso78>
In Phase you meant to specify kind of "Warning text" along with the PR.
<peepsalot>
as a nuclear option you could turn off all warnings for the submodule by setting CMAKE_C_FLAGS="-w" and/or CMAKE_CXX_FLAGS="-w" within that submodules/CMakeLists.txt (before the `include_subdirectory` call )
<peepsalot>
JordanBrown[m]: ^
<guso78>
c) run --enable-python command line argument
<guso78>
d) current code needs to have suffix .py
<guso78>
Not-D : my feature can still of course evaluate basic openscad code
<guso78>
if everything goes fine, all my checks will pass because they do not even smell the "python"
<JordanBrown[m]>
peepsalot yeah, but That Would Be Wrong.
<guso78>
i had to export some declarations to new header files and made some include files more relative, but that should be totally transparent, lets check
<teepee>
there's a couple of test result changes, where are those coming from?
<teepee>
are those from importing master into the PR?
<guso78>
hi teepee, i dont understand your message. but i understand the text in the PR log.
<guso78>
will create a new commit with the changes and commit
<guso78>
teepee, the changes in MainWindow.cc are used to provide the original openscad parser with some valid input in python case. i cant estimate on the effect NOT to run the orginal parse() function, so i provide a simple cube. will change it to "no input"