<InPhase>
I too have had multiple models break because of bug fixes of weird behavior that I accidentally depended on. A few rare cases of that are not an issue. This problem has never been zero, and zero isn't an optimal goal for it. What we're looking for is what problems are substantial enough that it's an issue. Right now I know of no current active code in the wild broken by that issue.
<kintel>
(we really need to get back to having a test case per verified bug, IMO, as tracking this takes high mental load)
<InPhase>
kintel: I would close that under "stale issue".
<InPhase>
It's one of those issues that has stopped making sense as presented in the current code context, which makes it the wrong way to track any outstanding issues.
<InPhase>
Is it fixed or not fixed? Not well defined, which makes it a candidate for closing.
<InPhase>
One can do this politely with a template including something like, "If there are any current unresolved issues similar to this, please open a new issue explaining them in the context of the current code."
<InPhase>
i.e. making it clear that it's not so much "won't fix" as "can't proceed with this description of the underlying need/problem".
<InPhase>
I think it's healthy to do some mass purging of stale issues that have gotten like this once in a while, to clear up focus. It just requires someone with the confidence and audacity to make a large number of such judgments. :)
_whitelogger_ has quit [Ping timeout: 268 seconds]
<InPhase>
kintel: Do we have anything resembling download stats? I'm curious how often people download each platform of the releases, and each platform of the nightly.
<InPhase>
kintel: Totals for releases would be awesome, and average rates per unit time for nightlies would be reasonable as a stat. I just wish I had more visibility into the breakdown of what types of users we have for each thing up there.
<InPhase>
Obviously then this would be missing distro repository downloads as well, but it'd be a start.
<kintel>
InPhase I think we may have slightly nerfed the DL stats due to all the new regulations, but it might still be possible to run numbers
<kintel>
Last I ran numbers (probably 6 years ago) we were pretty stable at binary downloads from 30K unique IP addresses per month
<kintel>
I think 50-30-20 or so for win-mac-linux, but I don't recall snapshots vs. release. I believe release was vastly dominant
greenbigfrog has quit [Ping timeout: 260 seconds]
greenbigfrog has joined #openscad
<InPhase>
kintel: No rush on trying to dig them out. I'm just curious what things look like now in proportions. And maybe curious if nightly usage has been creeping upward since we waited a bit and have so many potent features in the nightly. But, maybe people don't know about this. :)
<InPhase>
I'd kind of expect a lower mac proportion now just because we have fewer mac developers showing up in proportion.
dalias has quit [Ping timeout: 252 seconds]
J23k2 has joined #openscad
J23k26 has quit [Ping timeout: 250 seconds]
bozo16 has quit [Quit: Leaving]
dalias has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dalias has quit [Ping timeout: 264 seconds]
dalias has joined #openscad
misterfish has joined #openscad
TheAssassin has quit [Ping timeout: 240 seconds]
fling has quit [Read error: Connection reset by peer]
aiyion1 has quit [Ping timeout: 240 seconds]
fling_ has joined #openscad
aiyion1 has joined #openscad
aiyion1 has quit [Remote host closed the connection]
<teepee>
guso78k: yes, I saw the notification mail yesterday, interesting stuff
guso78k78 has quit [Quit: Client closed]
<guso78k>
your ability to work on the size of the openscad community ... BTW as we can talk python, I started to try to get the OCP kernel working(build123d) , so we can build geometry using the cadquery style in addition ...
<Scopeuk>
polyhedron is not my strong point, I tend to just swap points until it is all white in thrown together
<quiliro>
good idea!
<Scopeuk>
also worht knowing putting ! in front of a line makes that the only thing visible so if you do "!polyhedron(puntos,caras);" it will show only the polyhedron whilst you refine it
GNUmoon has quit [Ping timeout: 240 seconds]
pca006132_ has joined #openscad
<pca006132_>
points should be CCW when viewed from the outside
GNUmoon has joined #openscad
<quiliro>
but on example 1, the top face is CCW and the bottom is CW ...when both are viewed from the outside, pca006132
<Scopeuk>
shinking the cub very slightly makes it work
<Scopeuk>
this might be a zero thickness issue
<Scopeuk>
addding a little nudge make it work difference(){
<Scopeuk>
polyhedron(puntos,caras);
<Scopeuk>
}
<Scopeuk>
translate([0,0,0.01]) cube([4,4,1]);
mmu_man has quit [Ping timeout: 256 seconds]
<J23k2>
quiliro your polyhedron is not manifold - this crashes manifold engine when rendering pca006132 *stubs*
<J23k2>
scad 11.23 closes without warning
mmu_man has joined #openscad
<J23k2>
quiliro your center fold reaches to the bottom of your polyhedron making the edge part of top and bottom at the same time ↦ non manifold - this object can't exist in the real world
<Scopeuk>
yeh, crashing manifold on the nightly definitely falls into the bucket of bug
<Scopeuk>
even if the shape is not valid it should be an error/warning not a crash
* Scopeuk
needs to check on latest nightly
<Scopeuk>
think I'm pre maifold update
<quiliro>
ok...so I should make the polyhedron not reach the bottom?
<J23k2>
lift point 1 z just .001 and this can work .. you still have no overlap with the cube which is why you see the proper result only after rendering
<quiliro>
ok
guso78k71 has joined #openscad
<Scopeuk>
hmm latest nightly with manifold just rendered up, this surprises me
<InPhase>
I would probably do this with a white cane, and then overlap a very slightly larger red pattern in that shape.
<InPhase>
Designing the pattern, however, is left as an exercise.
<InPhase>
It's really only the once it would need to be implemented, however. The 3 thin lines are each basically the thick line with some parametric tweaks on thickness and starting rotation.
<J23k2>
preview is only 2D that looks 3D and you removing something without overlap - meaning the sides are in the same location so they are still there .. make the cube just a tine bit smaller 3.999 instead of 4
<peepsalot>
its recommended to make negative objects extend past the surface of the thing they are cutting, to avoid such artifacts
<quiliro>
oh...I thought the first object had to be the bigger one
<J23k2>
quiliro your top surface was inverted .. then if the cube is not centered the front will not change position but you need it smaller on all sides .. here this https://bpa.st/4LMA
<quiliro>
nice, J23k2
<quiliro>
I get this error: WARNING: Object may not be a valid 2-manifold and may need repair!
<J23k2>
try this translate([.005,0.005,-.001])cube([3.99,3.99,0.99]);
<J23k2>
the crest is cutting at 0 and the cube ends at 0 so there is no overlap.
misterfish has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
pca006132 has quit [Remote host closed the connection]