<ccox>
Crap. I need another 4X raspberry PIs for a vision project. The prices on them have jumped from $30 to $100, each. Even Aliexpress has increased their prices.
<teepee>
I guess the question is, do you want to get 10 and sell next year for $250 :)
<teepee>
> "Mouser is providing an estimated ship date for a Raspberry Pi 4B model with 4GB RAM of January 25, 2023. Digi-Key is also indicating that it will ship the same model now only in 2023."
<teepee>
that year is not a typo, I think
<teepee>
it may not end up *that* bad, but who knows
<ccox>
Sigh. I wonder if my old model 2s can be used for some of the motion control...
<ccox>
Or do I risk some Chinese clones?
<teepee>
depends on what you need, the hardware of most of the systems is probably quite ok, but the software/distros are a different matter
<ccox>
yeah, it's drivers I'm worried about.
<ccox>
Motor drivers are probably easier to adapt than the camera drivers.
<ccox>
...and syntax coloring gets a big upgrade (some of which will need further tuning based on user feedback)
LordOfBikes has joined #openscad
Colt has quit [Remote host closed the connection]
Colt has joined #openscad
kaph has quit [Ping timeout: 260 seconds]
<teepee>
yeah, not misusing the c++ lexer is much better
<ccox>
BTW - the "high contrast dark" scheme, rocks when you need to project code for a presentation.
<teepee>
I can imagine, normal dark schemes are horrible for that
<teepee>
I don't use dark schemes anyway, but that seems to make me part of the 5% light scheme users ;-)
<ccox>
yeah, good color schemes for editing are not the same as good colorschemes for presentation.
<ccox>
I typically don't use dark schemes, either. But after a friend's C++ presentations, I saw that dark and highly colored worked better for rapid comprehension.
<ccox>
(plus the one insane millenial coder that always works in day-glo dark colorschemes)
<ccox>
At some point we should make the preferences UI more similar for 3D View and the Editor.
<teepee>
yeah both are pretty separate, I'm using the Tomorrow schemes which are nicely matched :)
<teepee>
I wonder if Ben still remembers when that "integrate lextertl" project started
<teepee>
xypron: that is not any official site, please don't use it
<xypron>
teepee: the webpage should be updated
<teepee>
it's an ancient prototype
<teepee>
well, no, it should be shut down
<xypron>
teepee: google finds it first whenlooking for 'OpenSCAD IRC'
<teepee>
once someone gets access to it anyway
<xypron>
I get "Warning: GeometryEvaluator: Node didn't fit into cache." Strange for a machine with 16 GiB memory and loading an STL file of only 432 MiB. Is there a way to set the cache size?
arebil has joined #openscad
rvt_ has quit [Quit: rvt_]
<xypron>
There seems to be a setting in Preferences for caches. But shouldn't the cache sizes adjust automatically?
<teepee>
right now it's just that configuration
<teepee>
loading a 400mb STL, there's probably not much point anyway, I doubt there's any reasonable operation that will work with that huge file
<peeps[zen]>
cache sizes are adjusted as needed, but the *upper limit* is not
<peeps[zen]>
ie you can set to 8 or 16 GB on each cache if you want, its not going to reserve that full amount of memory, only the amount needed for the geometry involved
<peeps[zen]>
without an upper limit, you run risk of the OS killing the process for OOM
<peeps[zen]>
xypron: or hitting swap and everything slowing down by an order of magnitude or 2
<teepee>
peeps[zen]: what do you think about the swizzling stuff
<teepee>
I'm not convinced the "it's so obscure nobody will understand" is a good point, the alternative of people implementing yx0() functions seems not better
<peeps[zen]>
right. i like the concept, and tried to lay out my thoughts in the comments already. i haven't done a detailed review of the code yet, but the change seems good overall
<teepee>
the code change is pretty minimal and the .x feature is there already, so I'm not seeing much of a problem extending it
<teepee>
but the point with zero values and homogenous coordinates is good, that probably would extend usefulness even ore
<teepee>
*more
<peeps[zen]>
ah, didn't see the conversation continued recently till just now. yeah 0 and 1 would be nice too. eg so projection to 2D would be p.xy0 instead of [each p.xy, 0] or concat(p.xy,0)
<teepee>
GLSL solves that via their constructors which we don't have, so doing it without is awkward and verbose
<teepee>
allowing 0 and maybe 1 (in last pos only?) adds a big number of use cases I can find by a quick grep through libraries
<peeps[zen]>
i could see 0 or 1 in the first position being problematic since its nonstandard to have leading digits in a sort of "identifier"
<teepee>
true, that said, 0b is a valid variable name :)
<teepee>
but maybe there's a different indicator too, e.g. _ ?
<peeps[zen]>
there's also the consideration of conflicts if we have some record type in the future, probably most relevant for [rgba] where you might name something x.bar, x.rag, or x.bag
<peeps[zen]>
"bra", "grab", etc.
<teepee>
it works only on vectors, objects have their own lookup
<peeps[zen]>
would it be a possible lexer issue though? also i'm surprised that leading digits is already valid identifier, lol
<teepee>
I don't think so, due to that "we allow numbers as first char in identifiers" there's not much of an issue there
<teepee>
it happily accepts it as ID
<teepee>
not sure we could ever fix that
<teepee>
the only conflict would be "e"
<teepee>
00x1 = "test"; echo(00x1);
<peeps[zen]>
luckily "1e2 = 1e3;" gives a syntax error :)
<teepee>
yes, that lexes to a number
<InPhase>
But 0xff = 128; echo(0xff); prints 128. :(
<teepee>
I think 'e' is the only exception
<teepee>
well, 'e' and 'E'
<InPhase>
If someday we add hex support, anybody using numerical variables starting with 0x does not get my backwards compatibility sympathy.
<teepee>
essentially we can't add the 0x prefix due to that
<teepee>
or we would need to fix the issue first by deprecating for a century ;-)
<InPhase>
Or deprecate for 2 days and tweet out about how dumb of an idea it was to use it in your code. ;)
<teepee>
well, not quite, it would be possible to teach the lexer the 0x special case but that's not ideal
<teepee>
or not do releases and say we may fix in the next release
<teepee>
just for extra fun: $1E1 = 4; echo($1E1);
rvt_ has joined #openscad
<InPhase>
While that saddens me I suppose it will probably never collide. :)
<teepee>
so question is if we want to go in fully by allowing the vector swizzle with 0 at the beginning
<teepee>
no issue with the 1 as I guess there always has to be a letter somewhere before
<InPhase>
Well the swizzle syntax should always follow a vector name, so how would it cause a syntax issue?
<teepee>
v.01
<teepee>
but as that's not using anything from v it's a bit pointless too :)
<InPhase>
But how else would you interpret v.01?
<teepee>
otherwise the swizzle value needs to be a valid ID whic 01 is not
<teepee>
it's a number
<teepee>
same with objects that have . notation with valid IDs only
<teepee>
reading a json file with a "a-b" entry can't be accessed by j.a-b
<teepee>
only j["a-b"]
<teepee>
but x_y works with j.x_y
<InPhase>
Isn't the checking for validity only happening at the lexer though, where it's following the v.?
<InPhase>
If there's no other way to access a swizzle like 01 how does the interpretive conflict arise?
<teepee>
the lexer already compresses that to ID
<teepee>
and the parser expects <lookup> ID
<InPhase>
They're not IDs though. It's an encoding sugar.
<InPhase>
If you can do v.xyz and v.xzy and v.zyx, surely these are not all separately accessible vectors to be looked up.
<teepee>
from lexer perspective they are
<InPhase>
Maybe we shouldn't do that?
<teepee>
there's only one generic parser rule for: call '.' TOK_ID
<teepee>
then they would need to be keywords which seems even more strange
<teepee>
it's not possible to decide statically
<InPhase>
SWIZ_ID
<teepee>
e.g. function_call().xyz
<InPhase>
Hmm.
<InPhase>
That's a fair point.
<InPhase>
Are i or I used for any of the swizzling semantics intending to be supported?
<teepee>
not at this point
<teepee>
rgba and xyzw
<InPhase>
Because _ could be zero, and I could mean sample from the identity matrix.
<InPhase>
"I"
<InPhase>
Identity vector, I guess.
<InPhase>
Or, something.
<InPhase>
Just meaning, give a 1 there.
<teepee>
I think the 1 is safe as it's always after a letter, that will always be a valid ID
<InPhase>
func().xy_ would be [x,y,0], func().xyI would be [x,y,1]
rvt_ has quit [Quit: rvt_]
<teepee>
the only exception would be things like 00x1
<InPhase>
Then all swizzles are letters or non-numeric characters, and we implement slicing for the other stuff.
<teepee>
slicing for other stuff?
<InPhase>
Well I want slicing someday. And maybe indexed lookup.
<InPhase>
I think if we use uppercase I for 1, then it doesn't block any theoretical use of lowercase i if someone really wants it for something.
<teepee>
but that's very likely in brackets, I mean to trim down the existing PR to get the simple case going at some point
<InPhase>
func().___ would also be unambiguous, although silly.
<InPhase>
func().Ie_ would mean 1, some hypothetical swizzle parameter e, and 0, and still parse.
<teepee>
yes, the only concern would be the leading 0
<teepee>
even the 1 is not any issue
<teepee>
_1 is fine too
<teepee>
and I think it might be ok to even limit the 1 or I to places 3 and 4 ?
gunnbr has joined #openscad
<teepee>
or at least not the first one
<InPhase>
Well if it's I there are no conceivable restrictions and it's easier to explain.
<teepee>
true
<teepee>
but is there any mathematical sense in adding the 1 at the beginning?
<teepee>
I guess there's probably cases where it works for general CAD
<InPhase>
When you want to normalize the x dimension?
<teepee>
so [].IIII :)
<teepee>
hmm, so I don't mind using _ and I
<teepee>
it's probably safer if we ever want to get rid of that leading 0 nonsense
<InPhase>
[].IIII could be really handy for code golf!
<teepee>
on the plus side, the check would be still easy
<teepee>
pff, I thought code golf was finally solved by meta languages?
<InPhase>
peeps[zen]: Your thoughts on the "_" and "I" idea? Random syntax ideas are easy, but you've thought more about actually using this.
<peeps[zen]>
well, they solve the leading digit issue(if we consider that an issue), but also bolsters jordanbrown's argument that its obscure and hard to understand
<InPhase>
I assume 90% of usages are going to be .x, .y, .z, .xy, and .xy_
<InPhase>
So it's obscure and opaque in possibility, like a lot of language features, but will probably be used sensibly in most cases.
<teepee>
well, if the argument is that people usually ask "how is that done in python", that's a bad starting point for understanding OpenSCAD aswell ;-)
<InPhase>
[for (p=pts2D) p.xy_] // Example usage I imagine.
<teepee>
so, how's that proposal
<InPhase>
I'm not sure if .r .g and .b will actually get much use either, because mostly one wants to construct a color and not deconstruct it, given the immutable nature of values.
<InPhase>
But it's fine to keep support for those.
<teepee>
I actually tend towards merging the current state as it's still an often requested feature, with some useful stuff missing
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<teepee>
and we just add the extension stuff once we are clear on that via a new ticket
<teepee>
e.g. if we add the _ I stuff, I do want to see a warning for unknown lookups and out of bounds lookups
<InPhase>
Well _ and I are never out of bounds because they grab from the sea of constants.
<teepee>
true
<InPhase>
Like how p.xy_ works on a 2D p, to upgrade it.
<teepee>
that was more about dev process, not the _ I behavior :)
<InPhase>
Warnings for out of bounds on the rest of them are definitely important though.
<InPhase>
.z should fail (warn) if less than 3 elements.
<teepee>
yes, and unknown values just give undef right now too
<teepee>
but I think that makes not much sense without a warning
<InPhase>
Agreed.
<InPhase>
It should behave as an index does.
<teepee>
if you mistyped it, then it will always just give undef, so just write that :)
<InPhase>
We could add U for undef! But I hate that idea.
othx has quit [Remote host closed the connection]
<InPhase>
Maybe someone else would hate it less. Mostly I try to avoid undef everywhere other than function parameters.
<ccox>
JakeSays: in this case I need compatibility with the hardware and software of another group, which is raspi based.
<ccox>
deprecate, change the keyword pattern to match the background color, and they'll fix it quickly enough ;-)
arebil has joined #openscad
<teepee>
ccox: for the benchmark stuff, I suppose the first topic would be how the infrastructure would look like
<teepee>
unfortunately we just lost the build server, but that's not a huge deal for getting things started I hope
<teepee>
it may just need a bit of time to get things organized, gettin a new server
<ccox>
teepee: it could be a simple script, or something like the ctest scripting, but add timing on the output.
<ccox>
ouch.
<teepee>
it would be nice to have a setup which is a bit more stable, e.g. for running different versions
<ccox>
yeah, benchmarking can be written and tested on a few systems
<teepee>
installing everything manually scales badly when the infrastructure can change unexpectedly
<ccox>
yeah, and to get reproducible results.
<teepee>
one option would be to have openscad builds for maybe version 2019.05, 2021.01 and snapshot in a container
<ccox>
First, focus on getting something that can work and get reproducible results locally -- that can help developers looking for performance degridations, or improvements.
rvt_ has joined #openscad
<ccox>
but what host is your container going to run on? Cloud services are infamous for running on very different hosts, with very different loads.
<teepee>
nothing fixed yet, I've looked at netcup.de which we use for some of our company stuff and they do have kvm hosting with dedicated cpu/memory
<ccox>
For online benchmarking, we need something VERY stable and reproducible -- ie: a single system with a relatively stable OS.
<ccox>
And your better option is having several different hosts (CPU, GPU, and OS) for comparison (just in case some feature triggers OS specific behavior). But that takes time, some cash, and maintenance.
<teepee>
I don't see that happening anytime soon
<ccox>
But, start small, get it working, then work toward something bigger and better.
othx has quit [Ping timeout: 256 seconds]
gunnbr has quit [Ping timeout: 240 seconds]
ABUNDA_LA_CACA has quit [Remote host closed the connection]
lastrodamo has quit [Quit: Leaving]
ur5us_ has joined #openscad
<JakeSays>
ccox: what do you think of prusaslicer's UI?
<ccox>
haven't used it that much
<JakeSays>
it sure is fast
<JakeSays>
slic3r is interesting.
<ccox>
well, I've crashed it twice in the last minute, in two different places.
<ccox>
so, not very impressed with their stability or testing.
<ccox>
and their download page is apparently a few versions behind the current release (doh!)
<JakeSays>
ccox: lol i haven't had it crash yet
GNUmoon has quit [Ping timeout: 276 seconds]
<JakeSays>
ccox: what os are you running it on?
<ccox>
MacOS 12.0.1
<JakeSays>
ah
<JakeSays>
their latest release was two days ago
rvt_ has quit [Quit: rvt_]
<JakeSays>
ccox: try the release page on github
<ccox>
I already pulled the latest, trying it now.
<ccox>
oh, good lord, they resurrected clippy...
<JakeSays>
what?
<JakeSays>
where?
<ccox>
they sometimes pop up a UI suggestion in the bottom right corner - and it's clippy wearing a gray beret.
<JakeSays>
LOL i saw the popup but didn't pay attention to it
rvt_ has joined #openscad
<ccox>
No, stupid software, a pen rest is not a sign and should not change color automatically...
<ccox>
and no, shapeway's color previews are not correct - way desaturated compared to the prints.
<ccox>
you can see the actual cube prints on my thingiverse background.
<ccox>
Hmm, looks like Prussa still shares the slicing code with Cura - a lot of the same problems/bugs.
<JakeSays>
my eyesight isn't good enough to know the difference. lol
<JakeSays>
ccox: it uses a different slicer entirely
<teepee>
it's based on Slic3r
<ccox>
ok, that's going backwards, the code has WAY more bugs than Cura.
<InPhase>
Ah, the egg resonance model is up.
<ccox>
(and I thought it was long dead)
<JakeSays>
ccox: well, i'm more interested in the UI design than the slicer
<InPhase>
I guess that explains Jack2133's earlier animated link.
<JakeSays>
ccox: do you make/sell those color cubes?
<ccox>
Jake - they're for sale on Shapeways. But shapeways hasn't enabled the better color printers for public use yet (Mimaki and Stratasys J750). So they're still only in the ZCorp "colored plaster" material.
<JakeSays>
but they're yours?
<ccox>
The Mimaki prints look GREAT, but are a bit pricy (still cheaper than Stratasys, though).
<ccox>
yeah, they're mine.
<JakeSays>
do you make much off of them?
<ccox>
A couple of companies have bought them to use as show pieces at trade shows. And the LAB versions are for color scientists.
<ccox>
Nope, don't make much from prints.
<JakeSays>
i think it'd be awesome to sell a design
<ccox>
ouch, prusa still has the old Slic3r floating point errors ((a+b)-a)!=b in FP
<ccox>
You can always put stuff up for sale on the big sites, just no guarantee that it will sell...
<JakeSays>
right
<ccox>
I put those up on Shapways years ago to see what the experience and workflow was like. (and because I needed copies of those cubes, as people keep playing with my prints)
<JakeSays>
i'm thinking of trying to sell debug rigs for various MCU boards.
<ccox>
But I put my most useful designs up on Thingiverse for free -- assuming that other people might find them useful. I've already heard from several grad students/post docs using my lab designs. plus lots of people using the keyboard feet and motor mounts.
<JakeSays>
i'm going to put my ws2812 mount system up there
<JakeSays>
heh. i'd love to have one of those HP 3d printers
<Jack2133>
Inphase: Kare-san-sui ‼ not eggs - Ü
rvt_ has quit [Quit: rvt_]
<JakeSays>
oh wow - seeed has little dopler radar boards
<ccox>
The HPs are great, especially if you need nylon/TPU and color -but they are expensive and need heavy duty power.
<ccox>
The mimaki are nice if you just need color, and they're not much worse than a large format inkjet printer (ie: can actually go in your garage).
<ccox>
But HP could be doing much more, except their 3D printers have all the usual HP bad management and distributed teams.
<JakeSays>
yeah
GNUmoon has joined #openscad
<ccox>
Prusaslicer does have some interesting glitches, where the preview updates incorrectly (showing partly sliced, but not fully sliced) until you change views and back.
<ccox>
I don't like the dumbed down design -I'd rather have my controls more visible like Cura.
gunnbr has joined #openscad
othx has joined #openscad
<ccox>
Ok, that's enough time wasted with Prusaslicer for today.
rvt_ has joined #openscad
<JakeSays>
ccox: the full set of controls are provided in additional tabs
<JakeSays>
which is a bit odd
othx has quit [Ping timeout: 256 seconds]
othx has joined #openscad
gunnbr_ has joined #openscad
gunnbr has quit [Ping timeout: 240 seconds]
othx has quit [Ping timeout: 256 seconds]
othx has joined #openscad
Guest3 has joined #openscad
<Guest3>
Hello. Really great tool! .. I mean OpenSCAD
<teepee>
hi Guest3! nice to hear :)
<Guest3>
short question: is there a way to use OpenSCAD variables as a text content? (to put it inside the model)
<Guest3>
Example: dB = TW / tan(30);
<teepee>
yes, you can convert to string via str(3)
<Guest3>
text("dB", size = 10);
<teepee>
text(str(dB));
<Guest3>
thanks a lot teepeeI will try
<teepee>
there's no simple formatting at this point, but rounding the number might help a bit
<teepee>
or looking for a library that does formatting :)
<Guest3>
I see, thanks a lot. I am new to OpenSCAD
<Guest3>
exactly, I have to format it like f:6.2
<teepee>
then str(round(100 * dB)/100) should help I think
<Guest3>
wow, thank you. I will try
<teepee>
this will not fill with trailing 0 though
<Guest3>
That is fine. Great it works as a charm
<ccox>
sounds like a need for an sprintf function
<Guest3>
ccox would be not bad ..
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<teepee>
yes, there was discussion of having a format() function