<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
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>
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)
<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
<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]>
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.
<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>
"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.
<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]
<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?