TheCoffeMaker has quit [Ping timeout: 265 seconds]
TheCoffeMaker has joined #openscad
TheCoffeMaker has quit [Ping timeout: 265 seconds]
TheCoffeMaker has joined #openscad
LordOfBikes has quit [Ping timeout: 246 seconds]
lastrodamo has quit [Quit: Leaving]
LordOfBikes has joined #openscad
califax- has joined #openscad
califax has quit [Ping timeout: 276 seconds]
califax- is now known as califax
snakedGT has joined #openscad
snaked has quit [Ping timeout: 252 seconds]
arebil has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
califax has quit [Remote host closed the connection]
califax has joined #openscad
snakedGT has quit [Ping timeout: 252 seconds]
snakedGT has joined #openscad
ferdna has quit [Quit: Leaving]
arebil has joined #openscad
<InPhase>
teepee: Looks like we have code support in place for looking up special variable module literals. :) They don't exist, but if they did, you could look them up in the context stack.
<InPhase>
Well. Didn't find it yet... I don't see the recomputing in the obvious places I think one would intentionally put it, nor in the top few places I would think it could accidentally arise. But my understanding of this section is growing.
<InPhase>
More another day.
<InPhase>
I suppose I can violate my principles later and track this with a carefully constructed example and a breakpoint stack trace.
Junxter has joined #openscad
ur5us_ has joined #openscad
ur5us has quit [Ping timeout: 264 seconds]
ur5us_ has quit [Ping timeout: 268 seconds]
lastrodamo has joined #openscad
mhroncok has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
teepee has quit [Ping timeout: 276 seconds]
teepee has joined #openscad
snakedLX has joined #openscad
_xxoxx has joined #openscad
snakedGT has quit [Ping timeout: 265 seconds]
Junxter has quit [Ping timeout: 246 seconds]
RichardPotthoff has quit [Ping timeout: 252 seconds]
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
RichardPotthoff has joined #openscad
amahl has joined #openscad
gunnbr__ has quit [Read error: Connection reset by peer]
arebil has joined #openscad
linext has quit [Remote host closed the connection]
linext has joined #openscad
drew has quit [Quit: Quit]
RichardPotthoff has quit [Read error: Connection reset by peer]
RichardP_ has joined #openscad
Cadair has quit [Read error: Connection reset by peer]
NoGare[m] has quit [Write error: Connection reset by peer]
ali1234[m] has quit [Read error: Connection reset by peer]
t-paul[m] has quit [Remote host closed the connection]
ali1234[m] has joined #openscad
<teepee>
InPhase: uh, "looking up special variable module literals" sounds scary ;-)
t-paul[m] has joined #openscad
Cadair has joined #openscad
NoGare[m] has joined #openscad
<InPhase>
teepee: Yes, a bit. :) But also we could do some pretty cool things with that.
<InPhase>
teepee: $Smoother = MySmoother;
<InPhase>
The dynamics are all about giving the caller sweeping control of behavior deep inside, without needing to wedge the passing into all the intermediate logic. There are some designs where that might be very nice.
<teepee>
I guess in the end that's the plan anyway
<teepee>
with modules becoming first class objects, they would be assignable to both normal and dynamic variables just like functions now
<teepee>
what I'm not clear about is the difference between what Doug proposed and module literals
<teepee>
maybe it would not be a problem to have module literals and something else, maybe even called object literals
<InPhase>
teepee: It requires thought, because you can't make a module closure or module returning a module like you can with functions.
<InPhase>
Although I guess you can make a function return a module then.
<teepee>
well, the module thing that is assigned to a variable, not the geometry the module would produce
<teepee>
and that's the thing I'm still a bit fuzzy about
<InPhase>
Yeah. I tried a few times earlier to mentally merge them. But the edge cases get confusing.
mhroncok has quit [Quit: Leaving.]
<InPhase>
It might be that we just need module literals and object literals separate to keep it clear.
<InPhase>
Then if you really want to combine things, you make a function that returns an object literal that contains a module literal, for which that module literal is then naturally able to access the object literal's lexical scope, and you get all the flexibility you need of constructing an object with data that creates geometries using its internal data.
<InPhase>
If that was a pile of incomprehensible words, I could probably write an example later. :)
<teepee>
the neat thing with Dougs proposal is that it treats the object literals as written o = { ... }; inline the same as importing an external file o = import("script.scad");
<teepee>
bringing at least some sort of namespaces automatically
<InPhase>
Yeah. That import call seems easy enough to add in.
<InPhase>
Once the inline is in place.
<teepee>
a partial version (data only) is already in a PR as JSON import :)
<teepee>
of course the geometry is the much more interesting thing
snakedLX is now known as snaked
califax has quit [Remote host closed the connection]
califax has joined #openscad
snakedGT has joined #openscad
snaked has quit [Ping timeout: 265 seconds]
mhroncok has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Remote host closed the connection]
<InPhase>
If we do json import, it should come after object literals so it can come in as an object literal.
<teepee>
it does
<InPhase>
Ok.
<teepee>
and we have objects already as result from textmetrics :)
<InPhase>
Oh, is that why that PR got so noisy?
<teepee>
but not possible to declare in the language yet
<InPhase>
I noticed about 70-100 posts on that in my email that I didn't read.
<InPhase>
Seemed like a whole lot of chatter for text metrics.
<teepee>
partially maybe, but there was also other discussions like the fix for scaling and alignment stuff
califax has joined #openscad
<InPhase>
Does echo(obj) work?
<teepee>
yes
<InPhase>
Ah, I see it there 1/3rd down.
<InPhase>
Excellent.
<InPhase>
Well that's excellent.
<teepee>
and the for (key = obj) obj[key]
<InPhase>
Very nice.
<InPhase>
So they are dictionaries then.
<teepee>
I suppose we still need to keep an eye on that but it seems good so far
<teepee>
yeah, at this point mostly dictionary features
<InPhase>
Oh, I see my name in there. "Talked to @rcolyer about this. His big concern is the form of the return value, since that's hard to change once it's introduced. The plan is for me to look at the Objects project" That was right when I stopped paying attention. But solid progress happened on this going way past text.
<InPhase>
I will poke at these new features later.
<teepee>
awesome
<teepee>
I'm currently still tossing the plan down the road to write a post for the website, but I suppose it should happen soon-ish with all the new stuff
<teepee>
textmetrics, objects, roof, probably more I already forgot
<InPhase>
It's probably worth mentioning that function literals are stable and production ready now.
<teepee>
wrl-export
<teepee>
technically they are, but yeah, the from outside tiny looking fixes are pretty nice
<InPhase>
I just think they might have been a little undersold in the past announcements, since we knew they were a little broken. But I think this is a good feature to be using more.
<InPhase>
Like I did not update my function plotting to use them after the last release, because it wouldn't be stable.
<ran>
I've been working on this for the last month or so
<ran>
it's an enclosure for 3d printers and it's entirely opensource
<ran>
basically all one has to do is download the repo, run openclosure-2040.scad, enter some numbers into the customizer and export dxfs
<ran>
I ordered panels for it last week but I'm still waiting for them to come in shipping
<ran>
I may set up shop and start selling kits for this too but I'm not sure yet
<ran>
the SCAD code is set up such that the user enters the length, width and depth of the enclosure they want to build and it does all the calculations and and stuff to export DXFs for the building it to those dimensions
<ran>
I haven't written an assembly manual yet and the BOM isn't totally complete but there you go
<ran>
feel free to poke around
<InPhase>
ran: For the bill of materials, you should include an example enclosure total price for at least one printer model.
<InPhase>
ran: That was the first thing I looked for, but it looks a little tricky to estimate.
<ran>
thanks for the advice
<ran>
the printer I'm building with this is on the larger side, it's an ender 5 plus
<ran>
i don't have anything smaller to test with
ferdna has joined #openscad
<InPhase>
ran: Maybe do that, and grab dimensions for something popular and tiny like the monoprice mini. Most people are in the middle then. :)
<InPhase>
Book-ending the problem.
<ran>
will do :)
<ran>
I'll look into what a good size for a resin printer would be
<InPhase>
ran: Are you doing ABS with it?
<ran>
yes
<ran>
though I plan on doing a lot of other filaments too