<JordanBrown[m]>
Lagopus: if your client uses “use” to pull in the library, module invocations at the top level will not be run. The effect is similar to the Python effect you describe.
<JordanBrown[m]>
However: with “use” the top level assignments are executed on every call into the library. That can be a feature, or it can be a performance drag.
kintel has joined #openscad
<teepee>
I'd call it a bug
<kintel>
That reminds me: I've long wanted to introduce UseNode and IncludeNode as AST constructs, which would be a small step towards making it cleaner and easier to reason about parsed OpenSCAD code
<JordanBrown[m]>
Remember that *Node are CSG nodes, not AST nodes.
<JordanBrown[m]>
And yes, I'm a little surprised that "use" doesn't show up in the AST.
<JordanBrown[m]>
I don't think "include" *can* show up in the AST. It happens at too low a level.
<JordanBrown[m]>
Consider a.scad:
<JordanBrown[m]>
echo
<JordanBrown[m]>
include <b.scad>
<JordanBrown[m]>
;
<JordanBrown[m]>
and b.scad:
<JordanBrown[m]>
("hello world")
<JordanBrown[m]>
and you can do far uglier things.
<teepee>
yes, include is already handled in the lexer currently
<JordanBrown[m]>
That was my guess, without taking the time to look.
<JordanBrown[m]>
teepee: Yes, I'd probably consider it a bug too, but as you might recall we have found real-world programs that depend on behaviors in that area.
<JordanBrown[m]>
(But we broke them, so maybe breaking them more is OK.
<kintel>
JordanBrown[m] Yes, I'm fully aware that IncludeNode would break certain behavior
<kintel>
The big question is if it's worth breaking it; depends on what we gain from it.
<kintel>
One of my earlier goals was to try to package the OpenSCAD -> AST parser as a separate library, which other tools could use for interoperability
<kintel>
..and allow stuff like .scad -> AST -> .scad
peepsalot has joined #openscad
srk has quit [Remote host closed the connection]
srk has joined #openscad
fedorafan has joined #openscad
<Lagopus>
JordanBrown[m]: thanks for the answer. I'll try that out
fedorafan has quit [Ping timeout: 246 seconds]
fedorafan has joined #openscad
snaked has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
greenbigfrog has quit [Ping timeout: 248 seconds]
greenbigfrog has joined #openscad
Lagopus has quit [Ping timeout: 240 seconds]
Lagopus has joined #openscad
castaway has joined #openscad
guso78 has joined #openscad
<guso78>
did some trials with ViewSCAD in jupyter notebook.
<guso78>
i get the error: Model class 'RendererModel' from module 'jupyter-threejs' is loaded but can not be instantiated
<guso78>
does anybody know, whats happening ?
califax has quit [Remote host closed the connection]
califax has joined #openscad
guso78 has quit [Quit: Client closed]
guso78 has joined #openscad
Kanan has joined #openscad
<Kanan>
so I have a 30 unit cylinder hole in openscad and assumed 1 unit = 1mm.
<Kanan>
But when I compared it to a 30mm cylinder in Prusaslicer because the size looked a bit sussy the hole was way smaller than 30mm, why's that?
<Kanan>
`cylinder(3, 15+tolerance2, 15+tolerance2);` where tolerance2 = 0.2 should give me a cylinder hole with diameter 30.4mm right? (this is a difference modifier on a rectangle)
J237 has quit [Quit: Client closed]
J237 has joined #openscad
Kanan has quit [Quit: Client closed]
fling has quit [Remote host closed the connection]
L29Ah has quit [Read error: Connection reset by peer]
fedorafan has quit [Ping timeout: 248 seconds]
noonien7 is now known as noonien
guso78 has quit [Quit: Client closed]
<JordanBrown[m]>
Yes, though I would used named parameters. Then you only need to say cylinder(h=3, r=15+tolerance2).
<JordanBrown[m]>
But note that cylinders are really polygonal, so depending on the size that can affect the tolerances.
<JordanBrown[m]>
By default a cylinder with radius 15.2 is a 30-gon.
<JordanBrown[m]>
The radius is measured to the vertices, so the centers of the faces are somewhat closer in.
guso78 has joined #openscad
<JordanBrown[m]>
So in this particular case the radius to the center of the edge is about 15.1.
<guso78>
testmsg, please diregard
<JordanBrown[m]>
Kanan: ^
<guso78>
jordan, does it meaan that for an d=30 cylinder the distance from center to toe end of an edge is even bigger than 15.1 ?
<JordanBrown[m]>
His cylinder has d=30.4.
<JordanBrown[m]>
r=15.2
<guso78>
sorry, got it now . i thought his was exactly d=30
<JordanBrown[m]>
Circular things have their radius measured to the vertices, so the radius measured to the center of the face (what you might call the inside radius) is a little smaller.
pah is now known as pa
<guso78>
so the intended circle is always the perimeter of the generated polygon
<JordanBrown[m]>
Here, for a 30-gon, the difference is about ½%, but for a smaller cylinder where you only have maybe 8 sides it can be as high as 8% or so.
<JordanBrown[m]>
No, the perimeter will be something else entirely and I would have to do the math.
<JordanBrown[m]>
One way that you might look at it is that the polygon generated will be the largest one that will fit inside the specified circle.
<lf94>
iirc 1 unit does = 1 mm
<guso78>
can you quickly expand IIRC for me ?
<juri_>
if i recall correctly
<guso78>
Thx!
<guso78>
Does anybody here regularily use viewscad in jupyter ?
<JordanBrown[m]>
lf94: One OpenSCAD unit is the same as one STL unit. Neither is specified in terms of physical units. Slicers typically default to one unit per mm, but can switch to one unit per inch - or can scale arbitrarily.
guso78 has quit [Ping timeout: 260 seconds]
<lf94>
Ah that's how it works
<JordanBrown[m]>
So, net, for most practical purposes you can say that one unit is one mm, but if you need to you could have a unit be a mile and you wouldn't be wrong.
<JordanBrown[m]>
And remember also that an OpenSCAD unit isn't absolute - cube(1) makes a one-unit cube, but scale(0.5) cube(1) takes that one-unit cube and turns it into a half-unit cube.
<JordanBrown[m]>
It's always relative to the local coordinate system.
peeps[work] has joined #openscad
fedorafansuper has quit [Ping timeout: 260 seconds]
fedorafan has joined #openscad
<InPhase>
guso78[m]: Somebody put OpenSCAD into Jupyter?
<InPhase>
Sounds challenging, given that we have no exposed interface for a repl.
<teepee>
I've seen various solutions, none of them ideal but sort-of functional
<teepee>
a well integrated kernel would be so much nicer
<InPhase>
Yeah. I think a separable OpenSCAD library that could be called stepwise would be a reasonable eventual goal.
<InPhase>
We're not super far from that, but it would be a project.
<InPhase>
Not sure if a GSoC sized project or not.
<InPhase>
There could be some heavy unknowns of accidental coupling.
<teepee>
lots of time to think about it :)
abff has quit [Ping timeout: 255 seconds]
germ has quit [Ping timeout: 276 seconds]
germ has joined #openscad
abff has joined #openscad
kintel has joined #openscad
<lf94>
InPhase: I think they're trying to put their Python-OpenSCAD fork into it. :)
rvt_ has quit [Ping timeout: 255 seconds]
rvt has joined #openscad
L29Ah has joined #openscad
<Scopeuk>
I think most of the openscad inside <X> project just use the commandline interface to render an STL for display
<buZz>
like kicad?
muesli has quit [Quit: NO CARRIER]
muesli has joined #openscad
J237 has quit [Ping timeout: 260 seconds]
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
J23 has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<JordanBrown[m]>
And would they generally be happier with a mechanism where they supply OpenSCAD text, or a mechanism where they call CSG functions, or a mechanism where they supply some (textual?) data representation of CSG?
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
guso78 has joined #openscad
<Scopeuk>
I suspect most people would like a library where they can push scad script into library and return a model or draw int oa gl window for preview
ur5us has joined #openscad
<juri_>
i did that with implicitcad. it seems to be useful.
<guso78>
i am asking for help, because i see a strange error which i dont understand
pa has quit [Ping timeout: 260 seconds]
pah has joined #openscad
guso78100 has joined #openscad
<guso78100>
ACcually it was ChatGPT which reminded me about SolidPython again then then learned about ViewSCAD which can display openscad models in Jupyter and I like the idea!
<teepee>
I like the idea too, but the solutions so far are not very good unfortunately
<guso78100>
I know jupyter from my work and I favor such a compute history of jupyter, just with openscad models as variables
<guso78100>
But very honestly: I feel that openscad in jupyter with a kernel, which does not lose state needs a programatic syntax rather than a descriptive syntax.
<dTal>
what's the difference
<guso78100>
my first task is to get it running at all. which is not the case unfortunately
<teepee>
this has nothing to do with programmatic syntax at all
<guso78100>
You can use it with SolidPython and its not bound to.
<teepee>
there's nothing in openscad that prevent a repl to be implemented
<teepee>
the only thing needed is a persistent context storing the previous results
<guso78100>
In a language which has a descriptive syntax the order of execution does not matter whereas in a programatic syntax the oder is very important
<InPhase>
JordanBrown[m]: Well if we stick to a C++ API, even though that's a little harder to work with than a C API, it would at least permit using any of those mechanisms.
<teepee>
true, but a repl forces a linear execution of lines entered
<guso78100>
teepee, if you favor a persisive context in openscad, how can it be helpful if openscad cannot overwrite variables, once they are set ?
<teepee>
then don't overwrite them
<guso78100>
glad you understood me , because i had the feeling, i expressed myself very bad
<teepee>
talking repl, it might even be ok to allow overwriting the repl context variables
<guso78100>
:)
<InPhase>
Well, in repl mode it would simply be inconsistent with non-repl mode when overwrites occur.
<teepee>
I would not even call it inconsistent
<InPhase>
For something like JupyterLab, each cell is its own two passes.
<teepee>
it's still consistent that "every unit of evaluation does not allow overwriting of variables"
<InPhase>
But then you just preserve the context.
<InPhase>
So the result could differ from if you copied all the cells out and ran them in one scad file.
<InPhase>
But... I think that's okay.
<teepee>
having an external context handling the results of different evaluations is really a separate thing that can have a different behavior
<guso78100>
teepee, so if you dont plan to overwrite variables in openscad_for_jupyter, for every new exrpression you will need a new variable name. moreover you would not be able to re-evaluate a cell, once its evaluated ?
<InPhase>
Yeah, overwriting needs to be allowed for this.
<guso78100>
you will soon run out variables names your mind can generate unless you use a counter which runs to infinity
<InPhase>
Re-evaluating is a very good example of why.
<teepee>
as I said, I don't see any problem allowing overwriting on that top level external context
<InPhase>
Especially if you make changes to a cell and then re-evaluate.
<InPhase>
We would just need to document that it's a slightly different behavior in that it's sequential between chunks.
<guso78100>
right now openscad has many structures implemented in many places which dont allow overwriting variables. simplest place is NodeDumper.cc e.g.
<teepee>
see it as animation
<InPhase>
teepee: But with preserved state. :)
<teepee>
which automatically reevaluates with different $t
<InPhase>
Although... I would honestly love to have some preserved state in animation.
<InPhase>
Actually, is there any reason NOT to preserve state between animation? We could optimize so much stuff.
<guso78100>
yes, but each slide of the animation starts with a reset state and does not base on the previous time ...
<InPhase>
Most designs would have zero impact if we just kept the context alive during animation.
<teepee>
mostly reset
<teepee>
$t is not reset
<InPhase>
But then you could use an if_undef check to avoid recalculating initial states, and we could do much more efficient versions of things like that Game of Life.
<teepee>
$t is a single special external context right now
<guso78100>
haha, now you told us the very secrets of openscad haha
<teepee>
nothing secret at all
<InPhase>
As my brain spins on it, I'm really liking it. Context preservation for animation. :)
<InPhase>
This would be a simple PR, right?
<teepee>
not sure about simple, there might be some traps
<InPhase>
None are coming to mind.
<teepee>
but it's probably similar to the repl
<guso78100>
Inphase where would you see an beneficial example of animation with context preservation ?
<InPhase>
guso78100: Imagine an animated creature that walks around randomly.
<InPhase>
guso78100: Easy to do if you can save "last position".
L29Ah has quit [Ping timeout: 276 seconds]
<InPhase>
guso78100: Otherwise you need to do a random seed vector and sum $t fraction of it to find the current position.
<teepee>
a part of that would be solved by a single increasing time value, like shadertoy and friends use
<InPhase>
guso78100: Or the snowfall example I did for the calendar, where I did random seed trickery again to make it look like the snowflakes had persistence from one frame to the next. Instead the flakes could be truly random and it just keeps track of where they were.
<guso78100>
yes but you could also start with the same state of your pseudo-random-function(cant recall the exact technical word)
<guso78100>
seed :)
<guso78100>
ok, now i understand :)
<InPhase>
guso78100: When JordanBrown[m] did Game of Life, the computational part was actually N^2 because it had to rerun from the beginning for each update.
<guso78100>
i m\\\
<teepee>
that is probably an example where the global time would not help
<InPhase>
It was light enough that this didn't prevent it. But we could also make a looping Game of Life that ignores $t and just tracks its own state indefinitely.
<guso78100>
i am temped to look into how a kernel for jupyter works, but i got big respect jupyter. i hope the interface is well documented
<teepee>
there's sample kernels for various languages
<InPhase>
$t ignoring animations could be a whole genre.
<guso78100>
hmm, sounds interesting. but you know, that i would not focus on the SCAD language :)
<InPhase>
The most important side-effect of this would be that the calendars could improve. ;)
<teepee>
there's probably not much point for a non scad language openscad kernel
<guso78100>
i'll definitely look out for these mentioned language kernel template codes...
<guso78100>
first i need to miggrate to my new computer, where i set up linux yesterday
<teepee>
I would assume if that's integrated in the normal evaluation path, it could support the same as openscad does, which would include the python stuff at some point
<teepee>
anything else seems not acceptable for openscad, having multiple frontends and/or backends is fine and might be very cool thing
<teepee>
having lots of special path fragmenting the internal logic is not a good idea
<guso78100>
will we have to offer openscad-jupyter in windows ? is there a jupyter in windows ?
<teepee>
no idea how that is setup, but I would assume it can run on windows and then it would need to be in the windows executable
<teepee>
I wonder what the state of the c++ kernel is now, that article is 5 years old
<guso78100>
i am wondering how c++ works at all in jupter. does int compile each input of line before executing it ? how does this compiled code link to the persistent state of "C++ kernel" ?
<teepee>
xeus is a communication library, not a kernel itself
<teepee>
it basically needs to connect to some sort of repl as far as I understand
<teepee>
the c++ interpreter is clint or so which is part of the clang project