<UltimateCodeWarr>
If I wanted to upsize the font to say a 4" high, 102 mm, how would I make this cube thing work?
<InPhase>
Try it without the intersection and cube.
<InPhase>
intersection just selects the volumes in common.
<InPhase>
You can also scale or resize the roof output to change angles.
<InPhase>
And you can also put the roof on top of a linear_extrude of the same text.
<UltimateCodeWarr>
The roof will work, but it's very chissled at the peaks/center of each letter
<InPhase>
Well that's what the intersection and cube is for.
<InPhase>
It flattens the top.
J25k70 has quit [Quit: Client closed]
<UltimateCodeWarr>
Got it, looks great!
J25k70 has joined #openscad
UltimateCodeWarr has quit [Quit: Client closed]
JordanBrown has joined #openscad
<JordanBrown>
kintel details...
kintel has joined #openscad
<kintel>
I read logs first, as my laptop tends to auto-disconnect on sleep, but here now :)
<JordanBrown>
Yeah, I was doing OK on keeping up when the Matrix/Element bridge worked, because the tools would keep track of where I was.
<JordanBrown>
Having to go look at the logs and figure out where I left off is something I haven't internalized.
<kintel>
heh, I figured I'll just commit to reading everything :)
<JordanBrown>
Do note that I sent you a reply to your last message.
<JordanBrown>
Reading everything is one thing. Having to re-find where I stopped reading is another level.
<kintel>
On the topic of deletion of object entries
<JordanBrown>
Sure.
<kintel>
The current proposal/PR has a syntax for creating objects from entries arrays
<kintel>
object[ [key, value], ... ])
<JordanBrown>
Yes.
<kintel>
which is nice because you can use list functions to manage the entries and create objects in the end, effectively bridging the gap between lists and objects
<kintel>
just curious about whether you had anything in mind for that for an object()-less implementation
<JordanBrown>
Object comprehensions.
<JordanBrown>
That aspect of object() is equivalent to
<kintel>
{ for (kv = entries) {kv[0]: kv[1]} } ?
<JordanBrown>
o = { for (e = list) (e[0]) : e[1]
<JordanBrown>
You typed faster than I did.
<JordanBrown>
Yes.
<kintel>
gotcha
<kintel>
I kind of like the dual nature of having comprehensions _and_ functional building blocks
<JordanBrown>
I *think* that anything that you can do with object() you can also do with object comprehension, and vice versa.
<kintel>
..like Python without the "pythonic" language wars
<JordanBrown>
Of course many of the object() cases rely on list comprehensions.
<JordanBrown>
Yes... for instance, note that concat() is just a specialization of list comprehension.
<kintel>
yeah, because we didn't add map() and filter() :)
<JordanBrown>
Does that mean we shouldn't have had it?
<kintel>
I think functions leans itself to a slightly different style, and having both gives people options, as long as we don't introduce weirdness
<kintel>
Anyway, we'll have some time to gather people's feedback before committing 100% :)
<JordanBrown>
I don't object to having both.
<kintel>
Someone will build utility libraries to extend this anyway
<JordanBrown>
BTW, something that I've thought about but not written down is direct-ish support for sets.
<kintel>
like underscore for OpenSCAD
<JordanBrown>
Where a set is an object with elements that are true if present.
<JordanBrown>
so { a: true, b: true } is a set of {a,b}
<JordanBrown>
You can do that with the existing object() or object literal syntax, but
<JordanBrown>
it occurs to me that it might be possible to directly support them, so that that set would be { a, b } or object("a", "b").
<kintel>
..like just syntactic sugar for bool-valued objects?
<JordanBrown>
yes.
<kintel>
..but with not support for false values?
<JordanBrown>
Or maybe the object syntax would be object(["a", "b"])
<JordanBrown>
Depending on what you do with them, you don't directly need support for false values.
<JordanBrown>
sets don't have falseness; they only have not-present-ness.
<kintel>
I mean, the result is just an object where by convention all values have to be true?
<kintel>
..or rather the values are ignored because we'll only ever query for key presence?
<JordanBrown>
This is not a fully fleshed-out concept, but mostly I'm thinking that it's syntactic sugar for creating true-valued entries, and by convention if what you want to build is a set, you don't put anything *else* into it.
<kintel>
so we need a contains() or key in object syntax?
<kintel>
which would be nice in any case
<JordanBrown>
Revar already added (in 4337) and I copied in 4478 and pkriens copied in 6012, a function has_key(obj, key).
<JordanBrown>
I'm pretty sure that I thought about it when I did the textmetrics work, but didn't really need it so kicked it down the road.
<JordanBrown>
With the textmetrics stuff, referring to a not-present entry yields undef, and that's *almost* the same thing.
<JordanBrown>
Doesn't detect existing values that are set to undef.
<JordanBrown>
(But you can detect those using object iteration, if you really want to.)
<kintel>
oh, that wasn't mentioned in 8a1
<JordanBrown>
I'm happy to have the concept, but the name has_key() doesn't give me warm fuzzy feelings.
<JordanBrown>
Oops.
<kintel>
heh, naming is hard. Coming from C++ I'd say contains() :)
<kintel>
anyway, details..
<JordanBrown>
I like contains() better, especially if it is in some sense polymorphic.
<JordanBrown>
There are two things that are hard in computer programming:
<JordanBrown>
* Naming things
<JordanBrown>
* Cache invalidation
<JordanBrown>
* Off-by-one errors
<kintel>
hehe, classic
<kintel>
In terms of sets, I kind of feel like it should be either its own type, or a set of functions managing the set concept
<JordanBrown>
It's important to be versed in the classics.
<JordanBrown>
Maybe. Right now I haven't even prototyped the set stuff.
<JordanBrown>
But it seems most useful if it can be really, really terse.
<kintel>
It's good to keep the door open though.
<JordanBrown>
Right.
<JordanBrown>
At least some of the people asking for bitwise operators were asking for them for bit flags, and sets seem like a better answer.
<kintel>
There are a few more sugar syntaxes that would be nice, but can be hammered out later
<JordanBrown>
But that will be an easier sell if a set is { a, b, d } and checking it is "if (s.c) ..."
<JordanBrown>
than if it's set("a", "b") and present(s, "c").
<kintel>
e.g. shorthand for creating objects from variables; let(a=1, b=2) ... object(a,b)
<kintel>
similar to JS obj = {a, b}
<JordanBrown>
Using object(), I'd say no, because object() is just a function.
<kintel>
right, it would break function syntax
<JordanBrown>
The only thing unusual about it is that it's varargs, but otherwise it doesn't process its arguments in any magic way.
<JordanBrown>
But theoretically object literal syntax could allow { a, b }.
<JordanBrown>
I didn't know you could do that with JS.
<JordanBrown>
Added has_key to 8a1.
<kintel>
modern JS added some nifty things
<JordanBrown>
Need to backfill it into 8a and 8.
J25k50 has joined #openscad
<JordanBrown>
My JS usage is stuck in about 2006.
<JordanBrown>
because that's when we froze one of the JS implementations that we use at work.
<kintel>
e.g. obj1 = { ... }, obj2 = {a: 1, ...obj1} - not sure that made it to your object literal syntax
<JordanBrown>
No spread syntax yet.
<kintel>
we could use each for that if we wanted
<JordanBrown>
Yes.
<JordanBrown>
The two cases where you really want it are to support varargs functions/modules, and to support constructing argument lists to pass down.
<JordanBrown>
Where you really want spread syntax, that is.
<JordanBrown>
I was kind of thinking of a Python-like syntax, *args to accept or expand positional arguments as a list, **kwargs to accept or expand keyword arguments as an object,
<kintel>
varargs for functions and modules would indeed be nice
J25k70 has quit [Ping timeout: 272 seconds]
<JordanBrown>
and adding ***listargs to accept or expand [[key, val], [key, val], ...] style arrays.
<JordanBrown>
But it would be good to see what JS has done in that area.
<JordanBrown>
Except that JS doesn't have keyword-based argument lists.
<kintel>
js doesn't have named function arguments though
<JordanBrown>
Right.
<JordanBrown>
If you want them, pass an object instead.
<JordanBrown>
... which is pretty low overhead, just have to add the { } around the object.
<kintel>
JS has function myFunc(...args)
<kintel>
..or function myFunc(a, b, ...restArgs)
<kintel>
..plus some crazy destructuring syntax
<JordanBrown>
But how would keyword args fit into that, and how would echo-style args that are named with non-unique names, and are order-sensitive?
<JordanBrown>
Or maybe we just say "echo is weird and can't be duplicated".
<kintel>
ouch, order sensitive ..
<kintel>
Perhaps rewrite echo at some point and deprecate the weirdness? :)
<JordanBrown>
Eh, shrug. It's not like echo()'s behavior is difficult to understand.
<JordanBrown>
And the [[key, val], [key, val], ...] representation can represent it.
<kintel>
something for another month..
<JordanBrown>
Yes.
<JordanBrown>
I am happy enough to observe that these things seem *possible*.
sculptor has quit [Remote host closed the connection]
<kintel>
another minor thing:
<kintel>
Should echo() yield the same syntax as the proposed object literal?
<JordanBrown>
I've added has_key() to 8 and 8a.
<JordanBrown>
Eventually, echo() and str() should duplicate the native syntax.
<JordanBrown>
Until we add object literals, we don't *have* a native syntax.
<kintel>
..and import JSON: Should we proactively merge the two features?
<JordanBrown>
What do you mean by "merge" them?
<kintel>
make it a single feature, essentially saying we'll make them both non-experimental together?
<kintel>
..or do you think JSON import can be fast-forwarded?
<JordanBrown>
Until we have object literals, I don't care whether we use the {a=1; b=2;} syntax that I was originally thinking of, or the {a: 1, b: 2} syntax that is the current plan.
<JordanBrown>
Once we do object(), we'll have three related features:
<JordanBrown>
* object()
<JordanBrown>
* import(json)
<JordanBrown>
* textmetrics()/fontmetrics()
<kintel>
Basically, I'm trying to figure out what is possible to land in the same official release, and aim for that
<kintel>
But the real question is rather: What can land in the next official release? :)
<JordanBrown>
Except for the fact that we need to bring down the slicer, and whenever you bring down the slicer there's always stuff that's "almost" ready, I'm comfortable with including all three in the next release.
<JordanBrown>
No strong opinion on whether they should be marked experimental there.
<JordanBrown>
Did 2021.01 have *anything* marked experimental?
<kintel>
experimental features don't make it into the release builds
<JordanBrown>
I was just wondering whether that was the rule.
<JordanBrown>
That would make sense.
<kintel>
It is - the flag is turned off to avoid people depending too much on a moving target
<JordanBrown>
Yes, though unfortunately it's been so long since 2021.01 that people have started to depend on the bleeding edge, experimental or no.
<JordanBrown>
I believe, for instance, that BOSL2 has support for textmetrics() based stuff.
<kintel>
yeah, we need to draw a line and get it out the door, which is why I'm a bit hesitant about objects. ..but it would be a very nice thing to add
<kintel>
But experimental first, then we can solicit feedback and start littering GitHub with tickets related to this topic and see where that leads
<JordanBrown>
The three I listed above - object(), import(json), and textmetrics() - are relatively safe in that they don't change syntax.
<JordanBrown>
Well, sort of. The object access stuff does, a bit.
<JordanBrown>
(Hmm. Maybe not; I should check.)
<JordanBrown>
But if they have problems, you can just not use them and they won't break you.
<JordanBrown>
And I think the semantics are solid enough that I'm not worried about them.
<JordanBrown>
Object literal syntax is more risky. Geometry values and module references riskier still.
<JordanBrown>
I am not aware of any tickets that have come out of import(json) or textmetrics().
<JordanBrown>
BTW, one minor fix/enhancement that would be nice is to make lookup() work when the values are lists.
<JordanBrown>
The semantics are pretty obvious, and I think somebody had a basically-working PR but got stalled on testing.
Guest13 has joined #openscad
Guest13 has quit [Client Quit]
<kintel>
I fear lookup() - it's such a messy function : /
<JordanBrown>
Are you sure you aren't thinking of search()?
<JordanBrown>
lookup is pretty straightforward.
<JordanBrown>
search() is ... interesting.
<kintel>
how do you linearly interpolate a list?
<JordanBrown>
Same way you linearly interpolate a number.
<JordanBrown>
Subtract and multiply by the fraction.
<kintel>
oh, each list being same length and only containing numbers?
<JordanBrown>
The goal is to be able to linearly interpolate between two vec2s or vec3s.
<JordanBrown>
Yes.
<JordanBrown>
Though right at the moment I'm writing a function that linearly interpolates strings and bools too :-)
<kintel>
gotcha.
<JordanBrown>
I have a vec3 interpolation function. It builds temporary lists for x, y, and z, and then calls lookup on each of them. But that shouldn't be necessary.
<kintel>
otoh, it feels like lookup() should really have been implemented in user space
<kintel>
but that's a different type of discussion.
<JordanBrown>
It could be, but it also feels like it's something that you want to be blindingly fast.
<kintel>
yeah, modulo performance..
<JordanBrown>
And yes, the "what should we really do in user space" debate is an interesting one.
<kintel>
anyway, bedtime here, thx, for writeups, discussion and reviews. Let's try to get that PR merged soon!
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<JordanBrown>
I gave pkriens a bunch of review comments. Most were minor style questions.
<JordanBrown>
I did have one C++ question around making it so that ContextMemoryManager could directly iterate over either a map or a vector, because that would make things significantly simpler.
<JordanBrown>
We'll see what he has to say. You might want to take a look and see if I misrepresented any OpenSCAD internal conventions.
snaked has quit [Remote host closed the connection]
J25k50 has quit [Ping timeout: 272 seconds]
snaked has joined #openscad
hyperair has quit [Remote host closed the connection]
germ_ has quit [Read error: Connection reset by peer]
germ_ has joined #openscad
ccox_ has joined #openscad
ccox has quit [Ping timeout: 276 seconds]
hyperair has joined #openscad
J25k55 has quit [Quit: Client closed]
J25k55 has joined #openscad
mmu_man has joined #openscad
J25k55 has quit [Quit: Client closed]
J25k55 has joined #openscad
J25k55 has quit [Quit: Client closed]
J25k55 has joined #openscad
Guest71 has joined #openscad
Guest71 has quit [Quit: Client closed]
bitbasher has joined #openscad
guso78k has joined #openscad
<guso78k>
Hi again, it appears that i am not able to get the test 1466 - throwntogether-cgal_issue267-normalization-crash clean even in the original latest master
<guso78k>
my resulting image is blank leading to a fail. I have even tired to use exact same compilation issues as in .circleci/config.yml or .gitub/workflows/linux-build-matrix.yml, but with no success until yet.
<guso78k>
is this test known to require special magic/care ?
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
Guest21 has joined #openscad
J25k55 has quit [Quit: Client closed]
J25k55 has joined #openscad
Guest21 has quit [Quit: Client closed]
GNUmoon has quit [Ping timeout: 244 seconds]
GNUmoon has joined #openscad
guso78k has quit [Quit: Client closed]
kintel has joined #openscad
<kintel>
guso78 do the other variants of issue267 work? i.e. is this issue isolated to throwntogether?
<kintel>
..and specifically throwntogether in CGAL mode?
<kintel>
Also, which OS, which GPU and which drivers?
<kintel>
JordanBrown Once you've hammered out the first review iteration, I can take a look at the C++ pieces, as it seems both of you are self-identifying as not-C++-experts :)
<guso78k>
Until now I did not inspect the test and its challange myself. i just watch from outside.
<kintel>
thx, I think the best approach would be to look into the details of the failure, as this doesn't fail anywhere else. i.e. look for error/warning output, make modifications and try to isolate the issue.
<kintel>
Performance looks reasonable though
sculptor has joined #openscad
J25k55 has quit [Quit: Client closed]
J25k55 has joined #openscad
c0d3x has joined #openscad
dingodoppelt has left #openscad [#openscad]
sculptor has quit [Read error: Connection reset by peer]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
sculptor has quit [Ping timeout: 245 seconds]
sculptor_ has quit [Changing host]
sculptor_ has joined #openscad
J25k55 has quit [Quit: Client closed]
J25k55 has joined #openscad
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mmu_man has quit [Ping timeout: 265 seconds]
snaked has quit [Read error: Connection reset by peer]
mmu_man has joined #openscad
snaked has joined #openscad
bitbasher has quit [Ping timeout: 244 seconds]
guso78k has joined #openscad
c0d3x has quit [Quit: WeeChat 4.7.0-dev]
mmu_man has quit [Ping timeout: 272 seconds]
Guest16 has joined #openscad
Guest16 has quit [Client Quit]
J25k55 has quit [Quit: Client closed]
J25k55 has joined #openscad
mmu_man has joined #openscad
j45 has quit [Ping timeout: 260 seconds]
bitbasher has joined #openscad
Guest26 has joined #openscad
sculptor_ is now known as sculptor
guso78k has quit [Quit: Client closed]
xarvh has joined #openscad
mwette has joined #openscad
<xarvh>
The rendering is getting stuck at 999/1000 on "Rendering Polygon Mesh using CGAL...", I tried both v2021 and v2025. Scad file is here: https://k00.fr/dnj3cy3m I don't think it's very complicated. Any suggestion?
<JordanBrown>
In a 2025 build, turn on Manifold, Edit/Preferences/Advanced/3D Rendering/Backend.
<JordanBrown>
xarvh^
<JordanBrown>
Though for that model CGAL shouldn't be too bad.
<JordanBrown>
kintel I haven't gone through pkriens' responses, but I think basically everything was coding style or C++isms.
<xarvh>
Worked like a charm, thank you! =D
teepee_ has joined #openscad
<JordanBrown>
You're welcome.
teepee has quit [Ping timeout: 244 seconds]
teepee_ is now known as teepee
j45 has joined #openscad
<Guest26>
I tried it as well. It was stopping at 999/1000 as well. Commented a few things out and tried again. When I commented out the text (the digits on the ruler) it worked. But I have no clue why
<Guest26>
But you problem is already solved, so it doesn't matter
<xarvh>
I tried random commenting here and there, including removing the text, but same. =(
<InPhase>
Rendered in 0.3 seconds for me with Manifold.
<InPhase>
The performance ratios for some designs are insane.
<InPhase>
I often just summarize it as 50X, but 1000X and more happens.
<xarvh>
Yeah, it was impressively fast. O_O
<InPhase>
xarvh: That's a pretty nice looking model. But I have to objections. :) The two holes should be arranged to be between 0 and 1 and between 21 and 22. And the whole model should be left-shifted so that the 0cm line is exactly centered at the origin, so we can see the alignment with the axis, just because that would be cool.
<InPhase>
s/have to/have two/
xarvh has quit [Ping timeout: 272 seconds]
<JordanBrown>
Indeed, something about that model drives CGAL nuts. I misestimated its complexity - I didn't catch the loop from zero to 240 creating text.
<JordanBrown>
xarvh you might want to fix that; you're generating negative text and negative tick marks all the way out to x=2400.
<InPhase>
That looks like it might actually be printable. Although a little hard to use unless one does the stop-print strategy to cross-color the layers.
<InPhase>
And it probably needs 4 layers total to come out with a good quality.
<InPhase>
Minimum.
j45 has joined #openscad
<mwette>
beveled text extrude: It seems like having a function to extrude 2D text by extruding to nothing towards the inside of each character contour would be very handy: text could be placed on bottom and sides. Has anyone tried to do this sort of thing? I assume needs to be mod to openscad C++ code itself.
<mwette>
warning: I've only been using openscad/3Dprint for a month.
<InPhase>
mwette: That's called "roof()" and exists in the nightly snapshots.
<InPhase>
mwette: I just put this example of it in channel about 3 days ago: intersection() { roof() text("PRIVATE ROAD", font = "Impact", size=15); cube([200, 40, 1]); }
<JordanBrown>
Caution: I've never used it personally, but my understanding is that roof() has problems and that there's not really anybody working on it.
<JordanBrown>
I've done this by overlapping linear extrudes of various heights, of offsets of various amounts. The result is pretty good.
ali1234 has quit [Remote host closed the connection]
ali1234 has joined #openscad
<InPhase>
JordanBrown: I don't use it on my own work, but I've done tons of toy examples, and haven't spotted any issues yet.
<InPhase>
I think the issues we had were just about trying to figure out if it's general enough to lock-in as-is. But it does solve a significant outstanding problem.
<InPhase>
Yeah, the set of issues mwette highlights are why it's not sure what the right language design is for this functionality.
<InPhase>
I felt a little guilty because I raised the prospect of a bunch of other options when roof came out, so we never un-experimentaled it. But there are so many other things raised as possible operational modes now with issues that it's not my fault anymore. :)
<InPhase>
We could have alternatively just pushed it out as integrated and dealt with the redundancy. And maybe we could still try that strategy.
j45_ has joined #openscad
j45 has quit [Ping timeout: 260 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #openscad
Guest26 has quit [Ping timeout: 272 seconds]
<mwette>
will try later: my snap version is 2025.06.05 which does not have roof
<bitbasher>
mwette you need to enable roof in preferences to make it available .. umm advanced tab?
<mwette>
lemme check
bitbasher has quit [Ping timeout: 272 seconds]
<mwette>
bitbasher: it's under [Edit]->[Preferences]->[Features]
<InPhase>
Yeah, roof is optional, but has been around for years.