<InPhase>
HimeHaieto: Well, I think Firefox is really good at wasting RAM, probably in large part being the fault of various site designs, and occasionally the fault of memory leaks. But OpenSCAD seems to be really good at actually making use of RAM for things that kind of make sense when used at scale.
<InPhase>
I'll be fair and note we DID have that one memory leak, from that nefarious function literals issue. But we fixed it.
<InPhase>
And that leak was rarely significant in real designs and usage. I constructed a kind of silly testcase to highlight that issue.
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<HimeHaieto>
I find myself more concerned with accuracy/correctness issues when working with openscad than memory consumption or render time
<HimeHaieto>
I actually earlier came across my first critical precision error - for "spacing = length / 4", length - spacing was deemed to be larger than length * 3 / 4 and thus caused an object in a loop to get skipped
<HimeHaieto>
also I've seen a number of cases where the rendered mesh had clear issues with cutouts not showing cleanly (instead getting weird chaotic garbledy-goop in the hole that scrambles around almost like an old tv without reception when moving the camera around)
<HimeHaieto>
most recently encountered with two cutouts in the same translation block of a for loop..."fixed" by...making an exact copy of the translation for each cutout instead of sharing the same statement line...because that makes sense...
<HimeHaieto>
I think much of the precision related stuff may potentially be more in the realm of cgal though, but iono
<HimeHaieto>
and yes, firefox is indeed really good about wasting ram, and it doesn't help that they've almost sort of prided themselves on it in actual statements/commentary on the matter - apparently in their mindset unused memory is what's really wasted memory/potential, and they clearly don't like to think of their software as being anything other than the primary or even sole software/focus when running
<HimeHaieto>
concepts like multitasking, shared resources/contention, system-level memory management, or just in general the notion that anything else may exist on the system (or need to run concurrently with firefox) that could need or make better use of memory than their precious application
<HimeHaieto>
just a classical single-user, mostly-single-application kind of mindset
<teepee>
wait, *other* aplication than a webbrowser? ;-)
<HimeHaieto>
I still clearly remember the days when by necessity we had to close most or all other software before launching a new one (particularly for bigger things), but while those days ought to have long since passed by now, I'm not convinced a number of firefox developers ever truly left that era or grew beyond that
<HimeHaieto>
sorry, have a bit of a history/beef with firefox devs...
* teepee
assumes they will progress to invent all the things the operating system is doing
<HimeHaieto>
and my point exactly, teepee :p
<teepee>
so at some point we just drop the kernel and call it gnu/firefox :)
<HimeHaieto>
gotta prepare for web 7.0, when your browser is expected to handle all aspects of the system from bootstrapping onward, and you'll be fiiine, because no way a web site might break your usb devices or virtualisation with some bad or even nefarious javascript
<HimeHaieto>
teepee: well, there was that whole "firefox os" thing...
<teepee>
I remember the name, but no details at all... must... resist... clicking... the... link...
<HimeHaieto>
"the applications use open standards and approaches such as JavaScript and HTML5...and open web APIs that can communicate directly with hardware"
<HimeHaieto>
see, the "jokes" I made weren't necessarily even as far-fetched as you might like to think, should firefox devs get their run of things
<HimeHaieto>
sometimes they seriously do seem to think they own or ought to own the place
<InPhase>
HimeHaieto: That "accuracy / correctness" issue sounds like standard floating point comparison issues. It's worth doing such things as integers and then applying a scaling factor to get the actual dimensions, to avoid these. That's common to all programming languages.
<InPhase>
As for cutouts not showing properly, this requires following "the overlap rule" that you will see under "Note:" in the manual for union and difference.
<InPhase>
This is again a fundamental issue about floating points.
<InPhase>
(And not a bug.)
<InPhase>
HimeHaieto: This has always been an issue, but I wrote out those "Note:" sections of the manual myself to try to make it extra clear, because nearly all initiates to the language seem to make this mistake and then want it to be fixed. But it's not broken, it's just a requirement of following the overlap rule to make the math involved valid.
<HimeHaieto>
again, for the cutout part, it was like: "translate([1, 2, 3]) {foo(); bar;}", which didn't work right, versus "translate([1, 2, 3]) foo(); translate([1, 2, 3]) bar();", which did...that doesn't seem like it has anything to do with overlap to me
<InPhase>
It can be.
<InPhase>
There's an example showing why in the manual. :)
<InPhase>
It can trigger if foo and bar have additional non-integer offsets inside.
<JordanBrown[m]>
I understand the math problems, but practically it seems like, especially if we have a grid snap concept, we could snap anything thinner than 10^-10 to being nonexistent.
<JordanBrown[m]>
Of course, I am totally handwaving away the difficulty of *implementing* such a thing.
<InPhase>
JordanBrown[m]: It's certainly a lot trickier when it's in the middle of a geometry calculation.
<HimeHaieto>
inphase: foo was a cylinder, bar was a square, and they both used the same value for diameter/length...it was so incredibly straightforward it didn't seem like there should ever be a problem with it
<JordanBrown[m]>
Yeah, but do you need to do it in the middle, or do you only need to do it when displaying the result or exporting?
<HimeHaieto>
also, it was the cylinder specifically that got the problem, which also happened to be the first child of the combined translation
<InPhase>
JordanBrown[m]: In the middle, because you can get CGAL exceptions from invalid geometries mid-calculation from this problem, and the whole rendered piece disappears.
<InPhase>
HimeHaieto: I'd have to see a complete testcase to know specifically what the issue was.
<InPhase>
HimeHaieto: But I can certainly note that many of the failure cases are unintuitive.
<JordanBrown[m]>
Ah, I was thinking only of z-fighting.
<InPhase>
JordanBrown[m]: Yeah. That's the best-case outcome. :)
<HimeHaieto>
inphase: my file is like 1k lines long, not sure if you'd want to see it lol
<InPhase>
JordanBrown[m]: And maybe the worst teacher, because it makes people think it's just a display problem.
<JordanBrown[m]>
I keep wondering how much of this is caused by grid snap, and whether we'd be better off with either no grid snap or a much finer grid. I need to find the implementation and build an experimental with a much finer grid and see whether I start running into other problems.
<InPhase>
JordanBrown[m]: "grep -r GRID". It's pretty easy to do a finer grid.
<teepee>
the remeshing stuff from fast-csg is likely a better option
<teepee>
or who knows, maybe not even needed at all with Manifold
<teepee>
question is if anyone will ever find enough time to find out :)
<InPhase>
JordanBrown[m]: It's GRID_COARSE and GRID_FINE in Grid.h. I have confirmed there are some fine structure issues that sometimes go away with a finer grid, when doing very small features. So I'd love to be rid of it. But I don't think it solves the fundamentals of the overlap rule.
<JordanBrown[m]>
I expect that it's easy. It just hasn't percolated to the top of my stack.
<InPhase>
HimeHaieto: I'm not afraid of a large file if you can point to a relative point in it to focus on.
<InPhase>
HimeHaieto: Although I note that is uncommonly long for a scad file. :) My longest one appears to be 632 lines.
<InPhase>
Of scad files I've downloaded and saved, only 7% are longer than this, and less than 1% are over 1000 lines.
Av8r has joined #openscad
<InPhase>
I like to break things apart if they get too big. Libraries are good.
<InPhase>
Why solve one problem when you can solve an entire set of them?
<HimeHaieto>
haven't regenerated it in a bit, but zoomed out as far as that it wouldn't look all that different now from how it did then
<HimeHaieto>
either way, I think that gives a good visual idea of what I'm working on
<InPhase>
I see the visual relics of the outdated release. :) I think we cleaned up that green there between 2019 and 2021.
<teepee>
hi Av8r - was that you working on the PDF stuff? (sorry if not, my brain is overloaded with spaghetti C code ;-)
<Av8r>
(Yes, Export PDF dialog, with some new features). I'm wrapping up coding/testing an ExportPdf Dialog box. All the new features test out okay, but there are two odd observations. First, when I run the new Openscad build from the command line (but with GUI, to test the code), messages show up for "no matching signal for
<Av8r>
on_okButton()_clicked" and for "...on_cancelButton()_clicked". The buttons work as expected in the new dialog box, and the signals are mapped (accept() to accepted()) in the ui header file for my new code. Is this a spurious message, or am I missing something? The dialog box is executed with exec().
<InPhase>
Av8r: Is there a pdf up for it?
<InPhase>
I mean.
<teepee>
sounds like some auto-connect fails, if you additionally attach the signals in code it would work
<Av8r>
Other observation: LOG messages no longer are showing up in the Error console, instead are showing up in stderr when I run from the command line. The app also shows the current date in the status bar. I know the LOG messages used to be display in the window.
<Av8r>
No PR yet. I want to sort out these issues.
<teepee>
right no PR, but lots of details in the issue ^
<Av8r>
Also, selection persistence is only within the app (during a single run), default values on start-up. Seems like I should integrate it with Preferences/Settings, at least for the paper size.
<InPhase>
Av8r: Ok. I was going to glance at the connect code and see if anything jumped out at me. There are a few gotchas in that system.
<teepee>
I think if you call it on_<name>_clicked it tries to auto-connect that
<Av8r>
I also might play a little bit more with the opacity/line width of the grid feature to improved discernability of the geometry on-screen in the PDF.
<teepee>
not sure where the () in that message come from, those might be the reason for the warning
<Av8r>
Okay, so if I rename the signals it might remove that message.
<InPhase>
Av8r: See src/gui/PrintInitDialog.h and .cc maybe
<teepee>
worth a try, I have not touched Qt code for maybe a year or so, so I might start to misremember things
<Av8r>
Probably need to update my notes in 4143. I went back to embedding the options (indirectly) in the exportInfo structure. Added a pointer, which points to the options structure, rather than passing a separate reference. Cleaner since it passes through several intermediary methods on the way to the ExportPdf code.
<Av8r>
Yes, I used PrintInitDialog as my guide.
<Av8r>
Thx,
<InPhase>
Ok.
<Av8r>
I've not yet pushed the code to my github fork. Since it seems to be functional, I guess I could do that and others could throw darts at it.
<teepee>
please! it does look very cool from both description and screenshots already
<Av8r>
I think it touches three existing files (mainwindow.cc, export.h, exportPdf.cc), and adds three (the exportPdfDialog.h, .cc, and .ui).
<Av8r>
I will put it on githhub. It's been several years since I've done so, so it may take me a few minutes... :)
<teepee>
no rush, already past midnight here and I'm fighting with a > 3400 lines of code C file which includes inline Oracle SQL
<teepee>
so assuming I win, I'd love to have a look :)
<Av8r>
There is still some cruft commented out in the exportPdfDialog files. I first tried to use maps to manage the interface between the dialog and the main code, but I could not get them to compile. So I reverted to switch statements and one set of if/elseifs.
<teepee>
as for the logging code, that needs fixing. it currently uses some static pointers to switch where the output goes, which is horrible
<teepee>
so either you ignore the problem to be fixed along with the other places
<teepee>
or you need to call some "log-to-console-now" before running the dialog