<guso78k>
kintel, the Polyhedron Node and the PolySet Class arr actually very similar and I often find myself translating between these classes. Do you think, its a good idea to skip the PolyHedron class and inherit PolySet from AbstractNode in addition ?
Smeef has quit [Quit: (╯°□°）╯︵ ┻━━┻]
Smeef has joined #openscad
L29Ah has joined #openscad
Guest49 has joined #openscad
Guest49 has quit [Client Quit]
mmu_man has joined #openscad
PaulWay has joined #openscad
guso78k has quit [Quit: Client closed]
PaulWay has quit [Ping timeout: 248 seconds]
kintel has joined #openscad
<kintel>
guso78k They are similar, but different. Inheritance is probably the wrong approach. Aggregation may work, but PolyhedronNode is a small subset of PolySet, and is user-facing, so the contents go through less validation. If you can come up with a good design, it might be doable.
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
kintel has joined #openscad
<kintel>
The best I can think of, as a start, would be to split out the concept of an indexed mesh into a shared struct. Perhaps also do the same for PolygonNode/Polygon2d. Not sure if that would help tremendously, but playing around with it might uncover some refactoring opportunities
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<church_>
what is reasoning to not allow hull and alikes to work on 3d and 2d at same time (or 2d at different Z height)? it's not that hard to 3d-fy with linear_extrude(.001) all 2d objects, but whenever i have to do it, i question of what gain/rationale to not allow for those transformations to be usable without resorting of extra steps to workaround limitation?
<church_>
using minimum height cylinders/cubes/spheres/linear extrusions can work .. but not getting why it needs to be :/
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
krushia has quit [Quit: Konversation germinated!]
J25k83 has quit [Quit: Client closed]
J25k83 has joined #openscad
Guest49 has joined #openscad
Guest49 has quit [Quit: Client closed]
guso78k has joined #openscad
ccox has joined #openscad
Guest82 has joined #openscad
Guest82 has quit [Client Quit]
stealth_ has joined #openscad
Guest33 has joined #openscad
<Guest33>
zxvcZV
<Guest33>
ddfgf
<Guest33>
fgh
<Guest33>
fgh
Guest33 has quit [Client Quit]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 264 seconds]
teepee_ is now known as teepee
<Scopeuk>
church_ I'm not super familiar with the 3d subsystem but I believe at the minute this is a limitation that 2d is explicitly 2d, there was some talk of implementing "2.5d" operations a while back to allow this sort of thing but I'm not sure where it went
guso78k has quit [Quit: Client closed]
guso78k has joined #openscad
<guso78k>
exactly that is what the skin() PR delivers. its basically a hull of a sequence of arbritaty placed 2.5D shapes in space. scrameta rebases it every week.
Guest17 has joined #openscad
Guest17 has quit [Client Quit]
guso78k has quit [Quit: Client closed]
guso78k has joined #openscad
guso78k has quit [Client Quit]
UltimateCodeWarr has joined #openscad
<UltimateCodeWarr>
Hi All, I downloaded the latest version of OpenScad and didn't see the option to enable manifold, is that baked in right now?
<UltimateCodeWarr>
So I started back with openscad after about 6 months, and with the new version it deprecated a lot of variable names starting with digits
<UltimateCodeWarr>
First of all, why would they do this. And why not provide an automatic migration tool, upgrader?
<UltimateCodeWarr>
teepee --So there was confusion in the parser that it couldn't ascertain if a variable was a hex constant because of it's naming convention so they opted to ruin countless libraries and tutorials on line by deprecating how variables can be named?
<teepee>
if you want to argue for taking it back by giving specific reasons, that's appeciated
<teepee>
making a fuzz is not
<teepee>
and "they" are some of the people here, so talk to "them"
<teepee>
and I'd include myself too even though I did not look too closely into that specific topic
<teepee>
so what libraries?
<InPhase>
I did not make the change, but vouched years back when it first was planned as a thing that should be done. Allowing variable names starting with digits was a strategical error that makes support for a wide assortment of features very difficult. This is why almost no language out there supports this. This is also why usage of variables starting with digits is fairly rare, because it is not permitted
<InPhase>
in other languages. I did see a case of an understandable usage that was raised, 2D and 3D being assignable booleans. But there are alternate solutions that are easy to enact with variable renames.
<InPhase>
Find and replace all are widely supported features, including in the built-in editor.
<teepee>
it does get cumbetsome if it's in libraries that are not updated
<teepee>
for the main file it's probably not a huge thing in most cases
<InPhase>
Yeah. Fortunately there are not that many multi-file libraries in prominent usage. So far none of them complained about this. :)
<InPhase>
UB.scad is the biggest library that had the issue, but can be fixed within a single editor window.
<teepee>
haha, nophead sure has, he *always* uses *all* the features, regardless how hidden or accidental
<InPhase>
lol
<InPhase>
I did just stumble into his post the other day about how he relies heavily on undefined values for out of bounds array accesses, and deeply opposes warnings for this. :)
<InPhase>
There are just some things where most people might pause and think, "Maaaybe in the future this won't be a good idea to consider a feature."
<teepee>
yeah, that is problematic as it makes debugging harder for everyone else
<InPhase>
Yep.
<teepee>
but the identifiers start with numbers is unusual, but so is all of openscad
<teepee>
meaning taking that away seems a much much weaker argument (even though I think it would be nice to have that change)
<teepee>
I wonder if that's the first case to actually adding some sort of language level
<InPhase>
UltimateCodeWarr: In summary the costs for those digit-starting variable supports were hex, octal, and binary support, along with disrupting support of complex values. That's a heavy cumulative price.
<InPhase>
UltimateCodeWarr: Float support was also made awkward, but had been special-cased.
<InPhase>
UltimateCodeWarr: By the time you have 5 special cases to consider, then you're in the scenario where it's clear why all the other languages block it.
<InPhase>
Like, it can start with a digit unless it contains an e, E, x, o, b, or i, but only if those characters are in certain positional configurations.
<InPhase>
It'd take 2 pages just to explain the rules for what sort of digit starting variable names are allowed, at the moment, but with possible future ones being deprecated if I didn't think of the complete list there.
<InPhase>
Somebody might want j too someday, as that's common.
<InPhase>
k might be included as well if a clever person recognizes the strong merit of supporting quaternions in a 3D modeling program.
<InPhase>
Or maybe while supporting i for imaginary, a person will choose alternates like a, b, c for quaternions, so better exclude those just in case.
<InPhase>
So, I hope that clarifies that it was important for feature development, and not whimsical or capricious. And it was discussed and thought about, with more than a year between the start of that discussion and making it happen.
<teepee>
full feedback only happens after it's enabled though
UltimateCodeWarr has quit [Quit: Client closed]
snaked has quit [Remote host closed the connection]