teepee changed the topic of #openscad to: OpenSCAD - The Programmers Solid 3D CAD Modeller | This channel is logged! | Website: http://www.openscad.org/ | FAQ: https://goo.gl/pcT7y3 | Request features / report bugs: https://goo.gl/lj0JRI | Tutorial: https://bit.ly/37P6z0B | Books: https://bit.ly/3xlLcQq | FOSDEM 2020: https://bit.ly/35xZGy6 | Logs: https://bit.ly/32MfbH5
ur5us has quit [Ping timeout: 255 seconds]
snaked has joined #openscad
<gbruno> [github] thehans synchronize pull request #4409 (Helplessly flailing in the general direction of Windows CI) https://github.com/openscad/openscad/pull/4409
<peepsalot> well, the RelWithDebInfo build actually succeeded, but I don't see any new info in the logs
<peepsalot> opened an issue with msys2. hopefully i don't get flamed too hard for not providing enough info https://github.com/msys2/MINGW-packages/issues/13927
<teepee> it lives https://imgur.com/a/z9WQvHL \o/
<peepsalot> cool, gj
<teepee> lets home they have some ideas, not having the windows tests would be bad
teepee has quit [Ping timeout: 255 seconds]
teepee has joined #openscad
J1A8413 has joined #openscad
J1A84 has quit [Ping timeout: 260 seconds]
<peepsalot> teepee: do you know about that copying of opengl32.dll ? does it not get installed on the path that is searched for shared libs?
<peepsalot> i wonder if there is some other dll which opengl32.dll newly depends on, and we aren't copying it?
<teepee> current dir (or better same as exe dir) is always in the dll search path I think
<teepee> but yes it's possible the dependencies changed, but didn't Scopeuk say grabbing all dependencies did not work?
<teepee> it would have to be some special lazy loaded dll too, normal dependencies are linked at application start as far as I've seen
<peepsalot> well Scopeuk also mentioned using a snapshot exe, which would be a MXE build anyways right? not sure I would expect msys libs to work on that either
<teepee> they do, or at least did in the past
<teepee> as that mesa lib is basically replacing the "official" crippled opengl.dll driver
<peepsalot> ohhhh, so the reason it is copied is to be sure it loads the msys version and not some window's builtin dll of the same name? because current dir takes prio over system dirs?
<teepee> yes
<teepee> system dll only has windows opengl 1.3 which is pretty useless
<teepee> even for ancient openscad :)
<peepsalot> oh wow, crazy
<peepsalot> i downloaded the two msys mesa package versions and compared directories in meld, there's a lot of new files and folders in the latest one
<peepsalot> suspiciously there is a new lib/gallium-pipe directory, but nothing in it...
<peepsalot> oh, meld had a bunch of filters on file types including binaries. thought I was goin crazy
<gbruno> [github] thehans synchronize pull request #4409 (Helplessly flailing in the general direction of Windows CI) https://github.com/openscad/openscad/pull/4409
hisacro has quit [Ping timeout: 276 seconds]
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
hisacro has joined #openscad
TheAssassin has quit [Ping timeout: 255 seconds]
TheAssassin has joined #openscad
<gbruno> [github] thehans synchronize pull request #4409 (Helplessly flailing in the general direction of Windows CI) https://github.com/openscad/openscad/pull/4409
hisacro has quit [Ping timeout: 260 seconds]
Fleck has quit [Ping timeout: 272 seconds]
hisacro has joined #openscad
Fleck has joined #openscad
drfff has joined #openscad
kow__ has quit [Ping timeout: 246 seconds]
drkow has joined #openscad
drfff has quit [Ping timeout: 260 seconds]
drkow has quit [Read error: Connection reset by peer]
drfff has joined #openscad
drfff has quit [Read error: Connection reset by peer]
drfff has joined #openscad
drkow has joined #openscad
drfff has quit [Ping timeout: 260 seconds]
kow__ has joined #openscad
drkow has quit [Ping timeout: 260 seconds]
kow__ has quit [Ping timeout: 260 seconds]
drfff has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
castaway has joined #openscad
<Scopeuk> It is possible we could try skipping msys Mesa and pull the pal1000 zip and extract the folder of doll's, it looks like Mesa have asked them to take a look at peepsalot's bug report as the msys package is based off his work
<Scopeuk> teepee was it the git hub actions or the circle cimstuff where you could add a command 5o the ci config to get it to leave the VM up and let you remote desktop in?
<Scopeuk> The mxs Vs other platforms thing for what I tried should be mute, the entry point is via a dll with abi compatibility to the windows integrated dll. There is system wide Mesa install for Windows but I have no idea how we would go about doing it on the ci host
<Scopeuk> Any it was appveyor that allowed that, doesn't look like there is anything similar for github
<Scopeuk> What we Re seeing does look like https://github.com/pal1000/mesa-dist-win/issues/118 but that was patched in 22.2.2-1 which we are running
<Scopeuk> That's a system wide install of the Mesa package (replace windows dll in system) which would do it instead. If we can't get msys fixed that might be a valid workaround (should be the same Mesa package but who knows what is introduced under us)
hrberg has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
hrberg has joined #openscad
drkow has joined #openscad
drfff has quit [Ping timeout: 248 seconds]
kow__ has joined #openscad
drkow has quit [Ping timeout: 260 seconds]
fling has quit [Ping timeout: 255 seconds]
fling has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
drkow has joined #openscad
kow__ has quit [Ping timeout: 272 seconds]
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
feuerrot has quit [Read error: Connection reset by peer]
snaked has quit [Quit: Leaving]
<linext_> anyone tried this browser 3d model editor: https://www.womp.com/
teepee has quit [Ping timeout: 255 seconds]
teepee has joined #openscad
<J1A8413> meh requires login .. but the preview looks nice
<othx> J1A8413 linked to YouTube video "How to use Curves - Tutorial | Womp 3D" => 1 IRC mentions
<teepee> yeah that lamp looks nice even with the print looking a bit messy
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<J1A8413> i want "goop union" in scad
<J1A8413> teepee that is a 5mm led  so this is just 25mm .. and not cleaned .. the walls are .6 so the  loop clipping is not working to reduce strings
<teepee> oh, tiny
<J1A8413> 2h print for 0.5m filament Ü
<teepee> very cool. I'd love to try that a little bit bigger. that's yours? is it on printables?
<teepee> the not fragmented one also looks lovely and not having the stringing problem
<J1A8413> you find a version for E14  socket
<J1A8413> or just use the lib free  script ..  .oO (could use it for the SCADvent)
<teepee> aaaaaaahhhhh, it's already nov 5th
<J1A8413> 25 days till we need to cancel SCADvent22
<teepee> haha, with all your preparation, 35 :)
<teepee> should i optimistically rename the repo to 2022?
<teepee> good idea
<teepee> done, I'll try to get the website part prepared this weekend
<teepee> if you have a clone you may need to update the URL in .git/config
<InPhase> teepee: Advent Calendar? :)
<InPhase> teepee: Also, Happy Weekend to you.
<teepee> yes, to huge surprise it's almost end of the year, no idea how that happened
<InPhase> I really don't know... Time stopped having normal meaning some undeterminable time ago.
<InPhase> Probably a particle collider experiment gone wrong or something.
<teepee> it certainly feels that way
<teepee> uh, oh, "Initial Support for RP2040 platform"
<teepee> so esphome needs to be renamed to esp-and-rp2040-home, but that's cool :)
dtsd has joined #openscad
<dtsd> Hello
<dtsd> is it a good place to ask questions regarding libraries, bosl2 in particular?
<teepee> in general, yes. specific for bosl2 the mailing list is slightly "better" as 2 of the people involved with the library are reading there
<dtsd> ok I try then
<dtsd> I want to make something that's very easy to do in freecad :)
<dtsd> sweep profile along path and mirror it along the end
<teepee> yeah, bosl2 can do that, but if it's easy in freecad, why select openscad then?
<teepee> freecad has an openscad workbench, so you could combine both tools even
<dtsd> i like openscad better :) because i can use it without mouse
<dtsd> my problem is i dont understand how to "get" last face to construct mirror
<dtsd> i want straight segment and start of the arc near axis center to construct fasteners there
<dtsd> so end of the arc is "somewhere" and inclined by some angle. its hard to construct vector to make mirror on the end of the arc
<teepee> so it's supposed to make a mirrored arch?
<teepee> not sure if that's the shape it's supposed to make, but depending on the angles and thickness you might get away to just combine 2 parts like so
<teepee> module s() path_sweep(rect([20, 5], rounding = [4, 4, 0, 0], anchor = FRONT, spin = 90), a); s(); translate([0,270,0]) mirror([0, 1, 0]) s();
dtsd has quit [Quit: Client closed]
<J1A8413> that is what i thought too - else you may need to reverse the path
dtsd has joined #openscad
<J1A8413> and mirror it
fling has quit [Ping timeout: 255 seconds]
califax has quit [Remote host closed the connection]
<teepee> path mirror could potentially create bad intersections at the sharp corner, but might work too
TheAssassin has quit [Remote host closed the connection]
aiyion has quit [Remote host closed the connection]
teepee has quit [Remote host closed the connection]
fling has joined #openscad
fling has quit [Read error: Connection reset by peer]
<J1A8413> i thought when concatenate the paths  but you are right if the end is not 90° this cause problems .. so better make two objects and join them
aiyion has joined #openscad
<J1A8413> (i have no idea what it should look)
<dtsd> problem with mirror is that mirror vector have arbitrary angle
<dtsd> that depends on the arc
<dtsd> teepee use mirror([0,1,0]) and it produces macdonalds like m
califax has joined #openscad
<J1A8413> you can add translate to move the mirror plane
<dtsd> but there should be no vertex, arc and mirrored arc should produce one arc but two times longer
<J1A8413> scale?
<dtsd> yep i can calculate coords, translate then rotate mirror plane
fling has joined #openscad
<dtsd> but it seems too hard. isn't there some function to get normal to last point of arc, then construct plane based on normal and them mirror
<dtsd> almost got it :)
<dtsd> mirror plane angle is bad
dtsd has quit [Quit: Client closed]
dtsd has joined #openscad
<dtsd> another question
<dtsd> how to "decompose" point?
<dtsd> say I have a = [a, b, c]; how to get [-a, -b, -c] by x?
<dtsd> a = [x, y, z]; how to get [-x, -y, -z] by a;
<J1A8413> *-1
<dtsd> thanks!
dtsd has quit [Ping timeout: 260 seconds]
<linext_> if anyone wants to try out womp
<linext_> username: womp@maildrop.cc and password: qQKU863yEx9iWAc
dtsd has joined #openscad
dtsd has quit [Ping timeout: 260 seconds]
rawgreaze has quit [Read error: Connection reset by peer]
rawgreaze has joined #openscad
rawgreaze has quit [Read error: Connection reset by peer]
rawgreaze has joined #openscad
rawgreaze has quit [Read error: Connection reset by peer]
rawgreaze has joined #openscad
ur5us has joined #openscad
rawgreaze has quit [Read error: Connection reset by peer]
rawgreaze has joined #openscad
<Scopeuk> That complains about account verification email
rawgreaze has quit [Read error: Connection reset by peer]
rawgreaze has joined #openscad
<J1A8413> https://maildrop.cc/inbox/womp   no mail here
rawgreaze has quit [Read error: Connection reset by peer]
rawgreaze has joined #openscad
<JordanBrown[m]> dtsd: J1A8413 you don't need a multiplication per se; you can just negate the vector. -[1,2,3] is [-1,-2,-3].
Trieste has quit [Ping timeout: 276 seconds]
<gbruno> [github] thehans synchronize pull request #4409 (Helplessly flailing in the general direction of Windows CI) https://github.com/openscad/openscad/pull/4409
ur5us has quit [Ping timeout: 255 seconds]
<gbruno> [github] thehans synchronize pull request #4409 (Testing mesa setup via GitHub Actions for Windows CI) https://github.com/openscad/openscad/pull/4409
<gbruno> [github] thehans edited pull request #4409 (Testing mesa setup via GitHub Actions for Windows CI) https://github.com/openscad/openscad/pull/4409
rawgreaze has quit [Read error: Connection reset by peer]
rawgreaze has joined #openscad
rawgreaze has quit [Read error: Connection reset by peer]
rawgreaze has joined #openscad
<JordanBrown[m]> So I thought I would share something I have been playing with.
<JordanBrown[m]> o = { a: 1, b: 2 };
<JordanBrown[m]> echo(o);
<JordanBrown[m]> ECHO: { b : 2, a : 1}
<JordanBrown[m]> (I need to make it be order-preserving.)
<JordanBrown[m]> o = {{ cube(10); }};
<JordanBrown[m]> echo(o);
<JordanBrown[m]> ECHO: literal() {
<JordanBrown[m]> cube(size = [10, 10, 10], center = false);
<JordanBrown[m]> }
<JordanBrown[m]> and then on that latter:
<JordanBrown[m]> import(o);
<JordanBrown[m]> puts it into the model.
<JordanBrown[m]> and of course both of those work with each other and with, e.g., functions:
<JordanBrown[m]> b = box(10);
<JordanBrown[m]> function box(size) = { size: size, geometry: {{ cube(size); }} };
<JordanBrown[m]> echo(b);
<JordanBrown[m]> import(b.geometry);
<JordanBrown[m]> echoes this:
<JordanBrown[m]> ECHO: { geometry : literal() {
<JordanBrown[m]> cube(size = [10, 10, 10], center = false);
<JordanBrown[m]> , size : 10}
<JordanBrown[m]> }
<JordanBrown[m]> and puts a cube in the model.
<JordanBrown[m]> Note that {{ ... }} is *not* a module. It's a geometry literal. It is fully evaluated into a CSG tree when executed; the various values above (o, box(10).geometry) are CSG trees.
<InPhase> JordanBrown[m]: You've blocked the ability to parameterize keys.
<JordanBrown[m]> you mean dynamic-value keys?
<InPhase> Yes.
<JordanBrown[m]> right now my answer to that is object().
<JordanBrown[m]> which doesn't happen to be incorporated into this build, but would slide in trivially.
<InPhase> Wasn't the idea of this variant you are trying to have a single unified approach though?
<JordanBrown[m]> I actively dislike Python style expr:expr object notation, because for the common case where the keys are constant and identifier-safe, you have to put quotes around them.
<InPhase> They do not make particularly good dictionaries if you cannot use values for the keys.
<JordanBrown[m]> object() lets you use arbitrary values.
<JordanBrown[m]> and do other interesting construction tasks.
<InPhase> Yes, but why do I want two syntax forms for one thing?
<JordanBrown[m]> But much of that is just a syntactic question of what you put on top of the types and operations.
<JordanBrown[m]> Why do we have concat() and []?
<InPhase> "each" was a later addition to improve over concat.
<JordanBrown[m]> "each" and list comprehensions are certainly flexible and powerful, but I would always use concat() in cases where it works.
<InPhase> concat is disrecommended, but not deprecated.
<JordanBrown[m]> I wouldn't disrecommend it. I'd say it's much clearer for the tasks for which it is suited.
<InPhase> I find it easier to lose track of the end result with concat.
<InPhase> "each" has a nice in-place representation like expansion with * in Python.
<JordanBrown[m]> The only thing that bugs me about it is that concat([1,2,3],b) yields [1,2,3,4] if b is 4, but also if b is [4].
<JordanBrown[m]> and so I can't remember if it'll yield [1,2,3,[4]].
<InPhase> Yeah, an unfortunate baked in flaw.
<JordanBrown[m]> Its actual behavior is generally more useful, but the asymmetry between scalar behavior and array behavior is an opportunity for confusion.
<JordanBrown[m]> Anyhow, I wanted to play with this syntax.
<JordanBrown[m]> The syntax was the easy part; it was getting the underlying operations to work that was harder.
<JordanBrown[m]> For both the {...} object/dictionary construction syntax and the {{...}} geometry syntax I think I got the syntax working on almost the first try, probably less than an hour. Getting the underlying semantics to work was much more.
<JordanBrown[m]> If we decided we wanted my "hybrid" approach, I think I could rework into that without too much trouble.
<InPhase> I guess that means it's now a sandbox in which the syntax can be played with, if that was the easier part.
<JordanBrown[m]> Exactly.
<InPhase> We will need to poke at them for the awkward bits.
<JordanBrown[m]> I was trying to figure out a way to support both in the same build, or at least with conditional compilation, but that would require a different kind of braces for one of them, and I don't know how to do conditional compilation in bison - I don't think it runs the preprocessor before running bison.
<JordanBrown[m]> That build also has module literals and module references, but they're orthogonal as long as we don't try to bring geometry values into the "top level" of the syntax.
<JordanBrown[m]> That is, as long as we don't try to make "g;" add a geometry value to the model.
<JordanBrown[m]> The one piece of underlying semantics that I'm missing from hitting (I think) all of the desired *functionality* points is a render() function that takes a CSG object and returns triangle soup.
<JordanBrown[m]> And then something (right now, import()) should be able to consume that triangle soup and put it into the model.
<InPhase> Well the render function is already in another PR, just we had talked about tweaking the syntax of it.
<JordanBrown[m]> Right, I just haven't gone to look at how it works.
<InPhase> So the functionality of that is available.
<JordanBrown[m]> Oh, and I still want to figure out how to make o = import("foo.scad") give you an object that contains the assignments, modules, and functions from foo, to replace "use".
<InPhase> So then what is x when done as: x = import("foo.stl");
<InPhase> The moment you use the word import somebody is going to ask for this. :)
<JordanBrown[m]> Eventually, one might hope that it would yield triangle soup.
<JordanBrown[m]> Eh, we already have import("foo.json").
<Friithian> oh hey #4409 just passed the windows check
<InPhase> So a geometry?
<JordanBrown[m]> But yes, it would be good if import("foo.stl") and import("foo.svg") yielded rendered geometry.
<InPhase> Ok.
<JordanBrown[m]> Yes, my going-in thought would be that they would yield the same sort of thing that comes out of render() of equivalent OpenSCAD constructs.
<InPhase> Well that's not a geometry.
<JordanBrown[m]> There are, I think, two kinds of geometry values that are of interest.
<InPhase> render(obj) is going to give an object of data.
<JordanBrown[m]> There's CSG trees, which is what you get from this prototype {{ ... }}.
<JordanBrown[m]> There's triangle soup / mesh objects, which would come out of render(csg), and would be object-type so that you can look into them.
<JordanBrown[m]> Both of those can fairly be described as geometry, and we'd need to figure out terminology to use to keep them distinct.
<InPhase> Hmm. So you're thinking of the render(csg) result as either, 1, an object with a special form that can be directly instantiated as a part of the model, or 2, a special internal type that has an object view?
<JordanBrown[m]> (1).
<JordanBrown[m]> an existing object-type value, with a specified schema.
<InPhase> So does this mean we can construct objects fitting the schema and instantiate them, skipping polygon and polyhedron calls?
<JordanBrown[m]> I would expect so.
<JordanBrown[m]> I think that's a feature, though I'm not 100% sure.
<InPhase> Sounds like a side-effect at least.
<InPhase> But it's not a terrible side-effect.
<InPhase> It does however mean that we need to get that schema right.
<JordanBrown[m]> One of the reasons to want to be able to do that is so that you can take render(something), apply some transformation to its points, and add it into the model.
<InPhase> Because it becomes a fixed API if it's bidirectional.
<JordanBrown[m]> It becomes a fixed API once it exists at all.
<InPhase> If it's one directional, we can add extra carrier information, but if it's bidirectional, we cannot add required content.
<JordanBrown[m]> Sure.
<JordanBrown[m]> We can add more *optional* content.
<InPhase> I'm thinking specifically ahead to rendered color.
<InPhase> And/or material type information.
<JordanBrown[m]> And if it's one-directional, we can't *change* anything that v1.0 includes.
<JordanBrown[m]> Yes, any design should consider those.
<JordanBrown[m]> (You'll see my comment to that effect on the render() PR.
<JordanBrown[m]> )
<JordanBrown[m]> https://xkcd.com/859/
<JordanBrown[m]> But I don't *think* that's hard.
<JordanBrown[m]> I think the base schema is an array of objects, where each object has a "points" member and a "faces" member, just like polyhedron. And in the future, the objects might have "color" or "material" members.
<JordanBrown[m]> It's an array, so that you can have one object have color=red, material=PLA and another object can have color=blue and material=TPU.
<InPhase> And a 2D version, with some clear differentiation.
<JordanBrown[m]> Indeed, so maybe that top level is an object, with one of its components being that array.
<JordanBrown[m]> We just need to remember all of these issues at the same time :-)
<InPhase> lol
<InPhase> Yes.
<JordanBrown[m]> actually, no, the 2D vs 3D thing is probably better in that lower-level object.
<JordanBrown[m]> so that you can have a top-level object that has 2D and 3D components.
<JordanBrown[m]> We can't handle that right now, but that seems like a weakness rather than good design.
<InPhase> Potentially.
<JordanBrown[m]> except preferably with dimensions spelled correctly.
<JordanBrown[m]> I hate when I see typos half a second after I hit Enter.
<JordanBrown[m]> While I'm fantasizing, I'd also be interested in something equivalent to JavaScript's spread syntax, so that you could say something like
<JordanBrown[m]> o = { h: 20, d: 5 };
<JordanBrown[m]> cylinder(...o);
<InPhase> cylinder(each o);
<JordanBrown[m]> Maybe, yes.
<JordanBrown[m]> v = [ 10, true ];
<JordanBrown[m]> cube(each v);
<InPhase> And cylinder(each v) for unnamed arguments.
<InPhase> Yeah. :)
<JordanBrown[m]> But not today.
othx has quit [Remote host closed the connection]
<gbruno> [github] thehans synchronize pull request #4409 (Testing mesa setup via GitHub Actions for Windows CI) https://github.com/openscad/openscad/pull/4409
othx has joined #openscad
<JordanBrown[m]> But I don't know what
<JordanBrown[m]> o = { ... };
<JordanBrown[m]> v = [ each o ];
<JordanBrown[m]> means.
<InPhase> "Warning: Cannot expand object into list."
<JordanBrown[m]> yeah, maybe.
<InPhase> Classic OpenSCAD. Warn the user, and proceed ahead as if everything is not hopelessly broken.
<JordanBrown[m]> Yep.
<JordanBrown[m]> While I'm thinking about possibilities, I notice that {...} is a very restricted syntax, which suggests that there could be variations with additional semantics.
<JordanBrown[m]> For instance, [key_expr, val_expr] could make an element.
<JordanBrown[m]> that is
<JordanBrown[m]> o = { ["a", 1], ["b",2] };
<InPhase> Or, o = { r = 2; sphere(r); }; :)
<JordanBrown[m]> same idea as object(), but in syntax.
<JordanBrown[m]> similarly
<JordanBrown[m]> Indeed.
<JordanBrown[m]> I know that was my idea originally (though maybe somebody else thought of it independently earlier), but I've become a bit less enamored of it more recently.
<JordanBrown[m]> (a) having variables be visible outside the braces that enclose them is odd.
<JordanBrown[m]> (b) where do you put the geometry?
<InPhase> Now, if you embraced { a : 2 } as meaning the key is the value of a, and not the symbol of a, then we'd have: o = { r = 2; var : value; };
<JordanBrown[m]> (c) it's like neither JS nor Python. (But it is somewhat more like OpenSCAD.)
<JordanBrown[m]> hmmmm.
<JordanBrown[m]> Does that mean you could say
<JordanBrown[m]> var : value;
<JordanBrown[m]> at the top level?
<InPhase> Potentially, although without a clear way to access it.
<InPhase> But if import is going to bring things in...
<JordanBrown[m]> depends on whether var is identifier-safe.
<InPhase> Right.
<JordanBrown[m]> none of the import() variants that I've mentioned would bring variables into the main namespace.
<JordanBrown[m]> The import(g) in the prototype brings geometry into the model.
<JordanBrown[m]> mylib = import("mylib.scad")
<InPhase> And mylib["foo"]
<JordanBrown[m]> creates an object mylib with contents from the file.
<InPhase> Or, mylib[5]
<JordanBrown[m]> if foo.scad had foo=123; then both mylib.foo and mylib["foo"] would be 123.
<InPhase> If mylib.scad contains: i = 5; i : "confuse everyone";
<JordanBrown[m]> yes.
<JordanBrown[m]> That is both what it would mean to the program, and what it would do to the people.
<JordanBrown[m]> Right now I think that o[k] string-ifies k, which it needs to stop doing so that keys can be non-strings.
<InPhase> I guess this is sort of why I liked the notion of compartmentalizing dictionaries as a more specialized type.
<InPhase> Then we don't have to ask these questions.
<JordanBrown[m]> Eh, have to ask very similar questions no matter what.
<JordanBrown[m]> oops, SIGMOM.
<JordanBrown[m]> Must handle tech support :-)
<InPhase> struct sigaction noop; noop.sa_handler = [](){}; sigaction(SIGTECHSUPPORT, &noop, NULL);
<InPhase> That code requires tech support as the lambda does not take an int, but tech support has been disabled so this is not an issue.
snaked has joined #openscad
<JordanBrown[m]> Sorry, my mother is 93 and almost blind, so needs help with many things having to do with computers. Thankfully I can take over her computer remotely and do stuff for her. But now my wife wants to be fed...
<Friithian> oh maybe I should design that part I was going to design yesterday but got sidetracked with bleeding edge bugs
<Friithian> oh no inb4 I switch radius and diameter
<J1A8413> don't do that
<Friithian> design the part of switch radius and diameter?
<J1A8413> don't switch them .. but you could write a function that uses   r and d  as input and check if you switched them Ü
<Friithian> wait no I measured ID and OD
<Friithian> … I think I know which one to use
<J1A8413> i just made a button cell holder .. and  a CR2025  is 20mm and 2.5 thick ..  works for all ..  except the 2430 / 2450 /2470
<J1A8413> they are 24.5 in diameter
<Friithian> do I care enough to round edges?
<Friithian> maybe add screw holes? eeeh
<J1A8413> just print a block and use a deburring tool and a drill  .. postprocessing
<tcurdt> I have scad file that uses some "%" to show some parts. Now when I include them via "use" I would love for them to not be shown ... using a parameter for this smells
<tcurdt> Is there another way?
<Friithian> I hate switching units constantly, I can never remember scale for mm when switching
<JordanBrown[m]> tcurdt: so you have a file a.scad that says "use <b.scad>", and b.scad says "%cube();"?
<JordanBrown[m]> The cube should not be shown.
<JordanBrown[m]> That is, when you run a.scad, the cube from b.scad should not be shown.
<tcurdt> JordanBrown[m] it is shown when it's inside a module
<Friithian> and I can't remember scale for inches either 1 and 1/2 inches thick is fuckin massive
<JordanBrown[m]> Yes, it is.
<JordanBrown[m]> And... that seems right to me.
<tcurdt> It totally doesn't to me :)
<JordanBrown[m]> So I shouldn't be able to have a library routine that creates a %-style ruler that won't be included in the final model?
<JordanBrown[m]> The rules are pretty simple and orthogonal: use<> gets you access to the modules and functions, and executes the assignments (in preparation for use by the modules and functions), but does not execute top-level module invocations.
<JordanBrown[m]> % shows in preview but not in render.
<JordanBrown[m]> % is not related to whether or not the object is coming from a use<> file, in any sense.
castaway has quit [Ping timeout: 272 seconds]
<tcurdt> I personally don't see a good use case for the % object in a use<> scenario. But it is what it is. I guess I am wondering if there is any better workaround but a parameter.
<tcurdt> ...or a way for a module to know whether it's been used through a "use<>"
<tcurdt> I currently don't see any other option but to use parameter for this
<JordanBrown[m]> You might be able to use a $ variable, but be very careful - the behavior of $ variables defined in use<> files has changed in the past; I don't remember what it currently is but I wouldn't assume that it's stable.
<tcurdt> The ones I know wouldn't help. Do you have a suggestion which? JordanBrown[m]
<JordanBrown[m]> Oh, I meant defining your own.
<tcurdt> ah ... can I?
<JordanBrown[m]> sure
<JordanBrown[m]> In particular, you could have the main file say... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/6e2e87b8f389b8e5d3bba492995e529cea665c9c>)
<tcurdt> it would be kinda need to have a $use or something that tells me where the source of the module execution is coming from
<tcurdt> good idea
<JordanBrown[m]> Unfortunately, like I said, you probably shouldn't depend on the behavior of $ variables set in the used file, so assuming that you *do* want the % stuff when you run the used file directly, if would have to be the main program saying "don't".
<JordanBrown[m]> But what's the real scenario? You have some module that has a component that's %-ed, and you want the %-ed stuff when the used file is run directly, but not when it's run from another file?
<JordanBrown[m]> Seems like the obvious thing would be... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/b36390d6621b453600ab9de6c5227dae69df960d>)
<JordanBrown[m]> in file B
<tcurdt> When I work on a part I show a mating part with % ... but when I use that part somewhere else I don't want the mating part
<JordanBrown[m]> When you call it from file B you say mymod(include_percent_stuff=true) and when you call it from file A you just say mymod().
<tcurdt> that sounds quite abstract - did that make sense?
<JordanBrown[m]> it made sense.
<JordanBrown[m]> But I wouldn't draw the distinction based on where it's called from, but rather on what the caller needs.
<tcurdt> yes, a parameter would be another choice
<JordanBrown[m]> and you can take advantage of defaulting and pass-by-name so that the "production" callers don't have to set it.
<tcurdt> maybe cleaner that to rely on some global $ state
<JordanBrown[m]> yes
<J1A8413> % is usefull to display objects  like a servo or screws that are not  printed
<JordanBrown[m]> Sure.
<tcurdt> exactly
<JordanBrown[m]> I use it for rulers.
<tcurdt> rulers? like how?
<tcurdt> not sure I can imagine that
<JordanBrown[m]> cube([100,1,1]) is a 100-unit ruler :-)
<tcurdt> for alignment between parts?
<J1A8413> or to show rotation axis
<JordanBrown[m]> alignment, measurement, et cetera.
<J1A8413> center points
<JordanBrown[m]> My usual ruler module creates a cylinder with darker markings at regular intervals.
<JordanBrown[m]> I've seen others that produce more conventional ruler.s
<J1A8413> and if you difference some module with % parts .. they will be unaffected
<tcurdt> care to share an example screenshot? JordanBrown[m] ... just curious to see that in action
<JordanBrown[m]> Hold a moment.
<J1A8413> color("skyblue")cylinder(100,d=4);color("chartreuse")for(i=0:5:99)translate([0,0,i]) cylinder(1,d=5);
<J1A8413> color("skyblue")cylinder(100,d=4.5);color("chartreuse")for(i=[0:5:99])translate([0,0,i]) cylinder(1,d=5);
<JordanBrown[m]> I'll have to find the cylinder one. Here's one that looks more like a conventional ruler.
<JordanBrown[m]> use <ruler.scad>
<JordanBrown[m]> translate([100,100,100]) ruler(100);
<JordanBrown[m]> translate([100,100,100]) cube(32);
<Friithian> chartreuse? fancy
<tcurdt> J1A8413 what do you use that for?
<tcurdt> JordanBrown[m] ah! ok
<JordanBrown[m]> Hmm. That screen shot does not show the % text very well.
<tcurdt> but I got it
<tcurdt> thx!
<J1A8413> i don't .. it is what Jordan described .. i have a module that is a caliper which are markings with a given distance to measure things
<tcurdt> measuring ... that's one feature that would be nice to have native support for :-/