aiyion has quit [Remote host closed the connection]
bitbasher has quit [Ping timeout: 252 seconds]
mmu_man has quit [Ping timeout: 252 seconds]
aiyion has joined #openscad
mmu_man has joined #openscad
<gbruno>
[github] Gregor-Gregor opened issue #6039 (OpenSCAD-2025.07.11: color-schemes/editor doesn't seem to recognize some categories in a scheme, applies different colors than in version 2021.01) https://github.com/openscad/openscad/issues/6039
<gbruno>
[github] Gregor-Gregor edited issue #6039 (In v2025.07.11 color-schemes/editor doesn't seem to recognize some categories in a scheme, applies different colors than in version 2021.01) https://github.com/openscad/openscad/issues/6039
<gbruno>
[github] Gregor-Gregor edited issue #6039 (In v2025.07.11 color-schemes/editor don't seem to recognize some categories in a scheme, they apply different coloring than the same scheme in version 2021.01) https://github.com/openscad/openscad/issues/6039
<gbruno>
[github] Gregor-Gregor edited issue #6039 (In v2025.07.11 color-schemes/editor don't seem to recognize some categories in a scheme, they apply different coloring than the same scheme in version 2021.01) https://github.com/openscad/openscad/issues/6039
<gbruno>
[github] Gregor-Gregor edited issue #6039 (In v2025.07.11 color-schemes/editor don't seem to recognize some categories in a scheme, they apply different coloring than the same scheme in version 2021.01) https://github.com/openscad/openscad/issues/6039
<gbruno>
[github] Gregor-Gregor closed issue #6039 (In v2025.07.11 color-schemes/editor don't seem to recognize some categories in a scheme, they apply different coloring than the same scheme in version 2021.01) https://github.com/openscad/openscad/issues/6039
mmu_man has quit [Ping timeout: 240 seconds]
mmu_man has joined #openscad
sculptor has joined #openscad
bitbasher has joined #openscad
Guest10 has joined #openscad
Guest10 has quit [Client Quit]
mmu_man has quit [Ping timeout: 244 seconds]
mmu_man has joined #openscad
<gbruno>
[github] Gregor-Gregor opened issue #6040 (2025.07.11 (git ef88e36a8): use<> ignores special $variables defined in the specified library - missing backward compatibility with 2021.01) https://github.com/openscad/openscad/issues/6040
mmu_man has quit [Ping timeout: 240 seconds]
mmu_man has joined #openscad
bitbasher has quit [Ping timeout: 240 seconds]
kasesag has joined #openscad
stealth_ has joined #openscad
kasesag has quit [Client Quit]
kasesag has joined #openscad
<stealth_>
render gets stuck at 994/1000
<stealth_>
OpenSCAD version 2025.07.20.ai26208 (git 721d8bc0e)
<stealth_>
works: "Normalized tree has 2610 elements!", does not work(stuck): "Normalized tree has 4653 elements!"
mmu_man has quit [Ping timeout: 240 seconds]
<InPhase>
stealth_: You forgot to turn on Manifold?
<stealth_>
InPhase, "Rendering Polygon Mesh using Manifold...
<stealth_>
"
<stealth_>
the cpu keeps being used and it stays like that for a long time. seems like a bug to me.
<teepee>
normalized tree and polygon mesh rendering is very different processes
<stealth_>
preview works though
<stealth_>
maybe the objects are being overlapped and thats the cause of issue?
<InPhase>
stealth_: Is the RAM growing slowly while it's doing this? That can be an indicator that it's just an overly intricate design.
<InPhase>
stealth_: Manifold will still sometimes seem to take forever on designs that end up having ridiculous numbers of faces.
<gbruno>
[github] t-paul closed issue #6040 (2025.07.11 (git ef88e36a8): use<> ignores special $variables defined in the specified library - missing backward compatibility with 2021.01) https://github.com/openscad/openscad/issues/6040
<stealth_>
InPhase, not that i can notice, i have like 32GB of ram so lots of free memory for it to use
<InPhase>
stealth_: Yeah. That's the sort of thing that can make it take a while instead of crash outright.
<InPhase>
stealth_: Manifold is more memory efficient than CGAL, so it actually takes a VERY long time to use up that much RAM, and it takes a VERY large number of facets.
<InPhase>
But I've spotted a few designs that could do it. Usually from some truly ridiculous element. And I remember it sometimes getting worse when that structure has very non-localized facets, like tons of long thin pieces.
<stealth_>
ran again, ram usage was 6.6GB and now its rendering and ram has gone up to 8.2GB but it doesn't seem to change and cpu around 23%
<stealth_>
"24 × AMD Ryzen 9 9900X 12-Core Processor" shouldn't have any issues with cpu
<teepee>
unless manifold has support for fine-grained feedback
<InPhase>
teepee: I once tried to linearize the progress bar, and wrote code for that. It was a bad idea, and also didn't work. :) Some designs would then freeze out at like 1%
<teepee>
yeah, the progress bar tracks steps in the csg tree
<teepee>
there's no general way of deciding where it will take the time, it's just most commont to be the last combining step
<InPhase>
What I tried to do was rescale it by estimating how much it had to compute yet, by brutally counting facets.
<teepee>
and I'm not sure manifold can easily do it too
<InPhase>
With Manifold I think even the facet count doesn't make sense, because it's better optimized.
<teepee>
so I don't think that feature request has any chance of getting implemented even though I agree it would be nice
<InPhase>
teepee: That one back again. I guess it's another case of having stumbled into something that worked and then building around it.
mmu_man has quit [Ping timeout: 240 seconds]
<InPhase>
The last comment there labeling different scoping rules for differently scoped variables being strange logic. But I think we have that documented well enough now.
<teepee>
there's an even strange version in https://github.com/openscad/openscad/issues/5924 - I'm not sure why people thought "that makes sense, lets rely on that" but *NOW* once it's fixed create an issue
<InPhase>
Yeah... I can't even think of how one would document that. Or why one would put it in documentation. The prior behavior is so absurd that I would have surely filed that as a bug if I had seen it.
<InPhase>
I'm not even sure how the old implementation managed to make that happen.
<gbruno>
[github] t-paul closed issue #5854 (Search field insertion point jumps to end after clicking earlier in field text and pressing any key) https://github.com/openscad/openscad/issues/5854
<teepee>
I think by not having a stack call context created for children() so the assignment from the lower level leaks into the upper level
<teepee>
or something like that
mmu_man has joined #openscad
gunnbr has quit [Read error: Connection reset by peer]
gunnbr has joined #openscad
J25k59 has quit [Quit: Client closed]
J25k59 has joined #openscad
<InPhase>
teepee: Except it's actually the child's assignment getting clobbered and not happening.
<InPhase>
But it is a leaky thing. In 2021 it leaks back if that first assignment is commented out, whereas in 2025 one gets a more reasonable undef and warning.
guso78k has quit [Quit: Client closed]
<bitbasher>
well that is a thread i am not able to follow but never mind .. can i get a review of a FAQ item rewrite to see if i am anywhere close .. this started as "why doesn't a=a+1" work
<InPhase>
bitbasher: "In a functional language a script is list of instructions (statements) are compiled" grammatical error here
<InPhase>
bitbasher: "selected makes it" --> "selected make it"
<InPhase>
bitbasher: This is a much better answer. The only thing that might make it better is if it ends with a separate paragraph that addresses why the user really had that question. i.e., what should they be doing instead?
<bitbasher>
oh .. i forgot to point out that the following FAQ is the rest of the post by tepee reformed as a .. well, as a FAQ, although i am pretty sure that the frequence on this one is abysmally low
<InPhase>
Many users go through a "this is stupid!" phase because they know only one way to solve problems in code. :)
<bitbasher>
good suggestion .. i can bring in some things i learned back when i was trying build a string parser for numbers
<InPhase>
bitbasher: Solution paths actually depend on the problem, but most often it looks like: 1. Precalculate values with list comprehension tools. 2. Use looping constructs and create a new value of the variable for each step in the loop. 3. Use module or function recursion as a method of doing iterative processing of values.
<InPhase>
I think that's roughly in order of commonality that this is the best solution for a new user problem where they tried to do an increment.
<InPhase>
The majority of them are solvable by just generating a list of values.
<InPhase>
Unfortunately one cannot say exactly how to do that without seeing each specific problem. But I've encountered enough users struggling with this question by now that I have statistics in my head on it. :)
<InPhase>
#3 is the only one that ACTUALLY does true iteration. But it's required far less often than one might up front think.
<bitbasher>
there is also the clever use of using an exotic list comp to be able to hack the loop variables into doing evil things to poor defenseless for loops
<InPhase>
Often users are really just trying to do some basic math, and iteration was their first go-to method because they were used to thinking imperatively.
<InPhase>
Yeah...
<bitbasher>
yeah .. myself i love recursion so i moved to it pretty fast .. and reading some complex examples put some strong new spins on the old solution .. then i moved back to using funky looping things to replace the need for recursion
<InPhase>
bitbasher: But I do not use it in practice.
<InPhase>
bitbasher: Basically, one dumps function literals into the three positions, and then they mutate a state that gets passed around.
<bitbasher>
what exactly is that doing ? map filter and fold labdas .. hummm
<InPhase>
The init() creates a state vector, update() mutates the state vector, and cond() decides whether or not to continue based on the state vector.
<InPhase>
It's just a way to manage an arbitrary pile of data iteratively in one call.
<InPhase>
Let me add, please don't link to that in the FAQ...
<InPhase>
I meant that only to show you. It's not a good suggestion for a confused user.
<bitbasher>
ah ha .. neat .. i found these babies in the relativity library .. took me a minit to get my head around them .. i evertually found them as part of javascript
<InPhase>
More of an advanced proof of concept notion.
<bitbasher>
function _coalesce_true( test, trueaction, falseaction ) = test ? trueaction : falseaction ;
<InPhase>
lol.
<InPhase>
Weird to spell those out as words.
<bitbasher>
using those in a recursion makes some things workable .. and readable, sort of
<InPhase>
I guess somebody was uncomfortable with the ?: syntax.
<bitbasher>
lol .. no really, they solve some problems by returning vector elements in a way that a ?: statement cannot do
<bitbasher>
oh heh .. BTW .. when i first saw your ID in here my first thought, guy has to be a twin
<bitbasher>
and his brother is OutOfPhase .. and has a sister invertedPhase and .. heh heh heh
<bitbasher>
yeah .. sorry a bit .. my brain works that way
<bitbasher>
inny .. you said : 22:40 InPhase: The init() creates a state vector, update() mutates the state vector, and cond() decides whether or not to continue based on the state vector.
<bitbasher>
to use the forf function you need an init() lambda .. what sort of function would work there?
<bitbasher>
and what is _= () ? etc : etc doing ?? is the under score a variable name?
<bitbasher>
if i call your abomination a "state machine" am i anywhere close?
teepee_ has joined #openscad
teepee has quit [Ping timeout: 244 seconds]
teepee_ is now known as teepee
othx has quit [Read error: Connection reset by peer]
othx has joined #openscad
stealth_ has quit [Quit: Leaving]
snaked has joined #openscad
<gbruno>
[github] t-paul locked issue #6040 (2025.07.11 (git ef88e36a8): use<> ignores special $variables defined in the specified library - missing backward compatibility with 2021.01) https://github.com/openscad/openscad/issues/6040
<teepee>
we need a variation of the "there's someone wrong on the internet" xkcd
<InPhase>
bitbasher: Imagine a function with a for loop where you want to do a whole bunch of calculations on variables a, b, c, d, and e based on the state of those variables in the previous iteration through the loop. forf is that, but where you take those variable names and put them in a list as elements.
<InPhase>
bitbasher: So it's just an abstraction to help with thinking about iterative looping logic for calculations. One was always able to do exactly the same with the built in list comprehension for loops, or with recursive functions.
<bitbasher>
nice .. thx Inny, i am taking a look at funcutils now
<teepee>
oh, I got an idea for the name. how about whack-a-mole-commenters?
<bitbasher>
humm .. are the moles the poeple or the issues they are talking about ?
<teepee>
no, you've seen that whack-a-mole game? where the moles pop up everwhere and you have to get them back into their holes?
<teepee>
with the commenters there's some people that pop up in every f* issue even just vaguely related to their pet peeve and comment always the same thing
<bitbasher>
yep .. that is me
<teepee>
like in #reprap there's some people you can just mention openscad and there will be a reply "oh, have you checked out cadquery?"
<sculptor>
staying faithful to openascad even if we go down together
<teepee>
or on the mailing list there was the person writing a similar application called angelcad and he always neede to comment anything to bring in his app
<teepee>
same thing on github, or probably any other place, just different people and different topics
<InPhase>
I'm sure there are things people get tired of me mentioning in various spots. :)
<teepee>
I don't mind pointing people to other stuff if it makes sense, like if people ask to generate STEP files, I do that myself
<InPhase>
"Can I talk to you about our savior, Linux?"
<teepee>
hehe, yes, if it's just without context, that would count too :)
<InPhase>
Usually the context is "Had a problem with Windows". ;)
<teepee>
it does obviously also depend on the place and the general discussion
<teepee>
like on our project bug-tracker on github it's way more intrusive than in a general discussion on reddit or somewhere
<teepee>
do we even have the link?
<teepee>
wrong?
<teepee>
duty?
<teepee>
pff
<InPhase>
I'm not sure I get cadquery though. Some people do seem to like it, but is it just because they want it to be python based? The language structure for part design feels absurd to me. It's all based on these string markers for edge designs and such. And they insist the code is super short, but it always looks like 3 times longer than it would take me in OpenSCAD.
<teepee>
I never used it for anything real, but the selection (query) plus the occ backend does give it some powerful base
<teepee>
I think it's very unreadable but I suppose that may get better if you use it more
<teepee>
what bothers me the most is they (the commenters, not the cadquery people) push it on people who probably can't handle the python setup and dev part
<teepee>
running openscad is literally easy for interested kids
<teepee>
and honestly both are probably not really perfect for huge projects, even though there are crazy huge ones in openscad
<InPhase>
Oh. I see "Installing CadQuery" starts with "Install the Conda Package Manager". That's not for mortals.
<InPhase>
I of course use it regularly. But this is not something I would encourage for non-programmers.
<teepee>
yep, exactly my point. and the casual user of 3d printing stuff in #reprap is not necessarily also a software developer doing stuff like that all the time
<InPhase>
I saw a gui so I thought they had a normal installer.
<InPhase>
I guess that's a byproduct of the devs coming from the python world. Whenever I enter the python community, I actually find it really hard to get a lot of people to understand what "distributable" needs to look like in different circumstances from whatever they are used to doing with their code.
<InPhase>
It's a different sort of problem/solution space in that world.
<teepee>
ah, yes, the python stuff I do for $work is packaged as rpm via Jenkins, that's pretty convenient :)
<teepee>
not sure calling it "fake" sounds very appealing
<bitbasher>
LOL suggestion for a more appropriate title?
<bitbasher>
and .. on the Tips and Tricks page .. can i just delete the ones that are too obvious? .. like the first one
<teepee>
no, why?
<teepee>
there's people who have not used openscad before, so having some trivial stuff can't hurt
<bitbasher>
sigh .. the rest of the tips are pretty good .. i could delete my added section in the FAQ in favour of linking to the tips page
<bitbasher>
actually we should have links to the relevant sections of the docs .. there are some good examplese in the Tips page .. some better than what is in the docs