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
<teepee> hmm, sounds like disabling the check for now and getting things automated might be a good step forward
<teepee> giving protection against the stuff already down so it does not regress
<teepee> s/down/done/
teepee_ has joined #openscad
epony has quit [Ping timeout: 268 seconds]
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
qeed has quit [Quit: qeed]
aiyion2 is now known as aiyion
epony has joined #openscad
<kintel> peepsalot: In those cases, perhaps an improvement would be to rewrite the code to dynamic_cast first, instead of checking the typeid?
<peepsalot> teepee: what would you recommend in terms of CI? I could add another entry to the github actions linux/Ubuntu matrix?
<peepsalot> the CircleCI builds are also pretty fast, not sure if that's just a consequence of MXE for some reason
<peepsalot> the checks can take quite a bit resources. i hit swap on 32GB ram if I run max 24 threads of this computer. so, say... maybe 1.5GB needed per thread
<kintel> I believe GitHub allows for integrating this so it can actually generate a review with suggested changes which can be applied directly in the UI.
<peepsalot> kintel: ok. are you looking at this one? https://github.com/marketplace/actions/clang-tidy-review
<kintel> yeah, that's the one I noticed. Haven't tried it myself though
<kintel> ..and that's really just a possible future state, but one which may sway whether to use GitHub vs. CircleCI for the check
<peepsalot> yeah, this sounds good: "Clang-Tidy Review only runs on the changes in the pull request. This makes it nice and speedy"
<peepsalot> running on the whole build is a lot
<gbruno> [github] kintel pushed 1 modifications 1 removals (Remove redundant cruft from FindGLIB2) https://github.com/openscad/openscad/commit/27496f3b88a0fac88a4c8a9d886e398bd24a8ebe
<gbruno> [github] kintel opened pull request #4476 (Remove redundant cruft from FindGLIB2) https://github.com/openscad/openscad/pull/4476
<peepsalot> kintel: regarding dynamic_cast, i guess I'm working under the assumption that comparing typeid is faster than trial and error of many dynamic_casts. though I don't know for sure if that's actually true
<kintel> well, we do trial and error on many typeid checks, so I expect it to be equivalent :)
<peepsalot> which i suppose only matters in performance critical sections, where I think Expression.cc would be the only one that qualifies
<peepsalot> because that is tail recursion code iirc
<kintel> actually, today's implementation is likely faster as there is only a single dynamic typeid()
<kintel> As long as nobody tries to subtype e.g. Echo and expect it to work that's fine
<peepsalot> well, i'm headed to a local robot group meetup for a bit, be back later tonight
<JordanBrown[m]> It seems mildly wrong that { for (i=[1,2]) !cube(i); } is legal, but { !cube(1); !cube(2); } isn't. I get that you can only appoint one pseudo-root node, but there are two nodes appointed in both cases.
<sinned6915> i need help with order of operations-
<sinned6915> i am trying make a polar array
<JordanBrown[m]> yes?
<sinned6915> but what its doing is moving the array to the point that i want as the radius, then making the array
<JordanBrown[m]> you want to make a bunch of cubes in a circle?
<teepee> peepsalot: CircleCI is fast because it's just the builds, no test runs
<JordanBrown[m]> what you are telling it to do is to translate a rotated cube.
<sinned6915> i want a number of cubes aranged about a center point
<teepee> peepsalot: I guess adding the clang-tidy checks directly to the builds is better, a full list of extra builds seems excessive
<JordanBrown[m]> You want to translate the cube, and then rotate the translated cube.
<JordanBrown[m]> hence rotate(...) translate(...) cube(...)
<sinned6915> yes, i am not understanding which comes first
<JordanBrown[m]> Work your way from the inside out.
<JordanBrown[m]> you want to swap the translate and the rotate.
<teepee> sinned6915: you can also have a look at File->Examples->Advanced->children
<teepee> this has a make_ring_of()
<JordanBrown[m]> In a more conventional language, what you have said is sort of akin to translate(rotate(cube)), where what you want is rotate(translate(cube))
<JordanBrown[m]> teepee yeah, but let's get past the fundamentals...
<teepee> yep, nothing wrong with that
<JordanBrown[m]> sinned6915: does that make sense?
<sinned6915> sort of
<sinned6915> i am trying to 'read' it like openscad would be reading it
<teepee> then imagine the operations you give are a tree
<JordanBrown[m]> translate(...) rotate(...) cube(...) reads like "translate a rotated cube".
<sinned6915> rotate(translate(cube)) makes sense
<teepee> cube() is the leaf and operations are working upwards
<JordanBrown[m]> and that's rotate(...) translate(...) cube(...), which reads as "rotate a translated cube".
<sinned6915> ok
<JordanBrown[m]> and remember that all rotations are around the origin, so rotating a translated cube moves it around a circle.
<sinned6915> right
<JordanBrown[m]> it looks like you're now getting what you wanted, more or less.
<sinned6915> i am still fumbling, but yes
<sinned6915> so how do the individual axis array variables ger read?
<JordanBrown[m]> It seems like you have a +1/-1 problem with the number of cubes; I would have expected n=5 to produce 5 cubes, but since you're counting 0,1,2,3,4,5 you get six.
<sinned6915> ([x,y,z])
<JordanBrown[m]> I don't quite understand what you mean by "how do they get read".
<sinned6915> 5 vs 6 has to do with the angles and 360
<sinned6915> right now i am only dealing with 1 varible change, the radius
<JordanBrown[m]> a translate moves the origin of the child object to the specified point.
<sinned6915> if i wanted the cube to be 45 degree inclined in X and Y
<JordanBrown[m]> a rotate rotates the child object by the specified amount, first around the X axis, then the Y axis, then the Z axis.
<sinned6915> i should probalby do at center, not face
<JordanBrown[m]> indeed, rotating a centered cube is more obvious than rotating a not-centered cube.
<JordanBrown[m]> multi-axis rotates can be difficult to visualize.
<sinned6915> teepee: i think i am going to stick with this for now
<sinned6915> the child thing confuses me right now
<sinned6915> i blame inPhase :p
<JordanBrown[m]> this is a cube rotated 45 degrees in X
<JordanBrown[m]> this is a cube rotated 45 degrees in Y
<JordanBrown[m]> and this is a cube rotated 45 degrees in X, then 45 degrees in Y
<sinned6915> JordanBrown[m] yes, doing it about center is easier than by the face
<sinned6915> i guess i was thinking that the rotations would be sensitive to order
<JordanBrown[m]> they are
<JordanBrown[m]> rotating in X, Y, Z is very different from rotating in Z, Y, X (or any other combination).
<sinned6915> translate ([X,0,0]) translate ([0,Y,0]) translate ([0,0,Z])
<sinned6915> yes, i am seeing this now
<JordanBrown[m]> translates are straightforward
<JordanBrown[m]> but rotates are not
<teepee> literally :)
<JordanBrown[m]> You can achieve any rotation with a single [x,y,z] triple, but it is not always obvious what that triple is.
<sinned6915> yes, exactly that!
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<JordanBrown[m]> That is, if the easiest way to think of what you want to do is a rotation in Z, then a rotation in Y, it may be better to say rotate([0,ry,0]) rotate([0,0,rz]) myobject(); than to try to figure out the single rotate equivalent.
<sinned6915> where i am going with this is the screwhole function of inPhase's thread libary
<sinned6915> ScrewHole(diameter, height, position=position, rotation=rotation,
<sinned6915> pitch=pitch, tolerance=tolerance)
<sinned6915> children();
<JordanBrown[m]> I'm afraid that I'm not familiar with his library.
<sinned6915> i am tired of hand coding a bolt pattern layout
<sinned6915> i was trying to either rotate(translate(Screwhole))
<JordanBrown[m]> Sounds plausible.
<sinned6915> but since I see the position and rotation definitions in there, apply the translation and rotate
<JordanBrown[m]> I'm being called to help with dinner... if you need more then I am sure that teepee can help you.
<teepee> I don't think that works with the library
<teepee> it works like ScrewHole() cube();
<sinned6915> JordanBrown[m] thank you for your time. enjoy your dinner
<sinned6915> thank you teepee
LordOfBikes has quit [Ping timeout: 255 seconds]
LordOfBikes has joined #openscad
Guest51 has joined #openscad
Guest51 has quit [Client Quit]
<InPhase> sinned6915: The idea of that module is you're supposed to pass the rotation and position of the hole in as parameters.
<InPhase> sinned6915: Oh, I see the thing. You wanted to loop it, but we don't have objects.
<InPhase> sinned6915: I think that was actually supported when I wrote the library, but peepsalot broke it when he fixed the processing of difference with empty children. (Although in peepsalot's defense I endorsed the change, because the old way of handling empty children was conceptually broken.)
<InPhase> The right way is for us to have objects to solve this issue, rather than this overreliance on syntactic children.
J23165 has joined #openscad
J231 has quit [Ping timeout: 260 seconds]
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
othx has quit [Ping timeout: 272 seconds]
othx has joined #openscad
kintel has joined #openscad
kintel has quit [Client Quit]
<sinned6915> InPhase: ok, so I did remember it right! I see the change now
<sinned6915> btw: what is the 'safest' dev release? I am on 2022.5.15. I am thinking i might want to see if there is something more stable
<JordanBrown[m]> I don't think anybody keeps track of stability of the dev snapshots.
<JordanBrown[m]> They are not, after all, intended to be supported in the long term.
<sinned6915> yes, agreed.
<sinned6915> but some are 'better' than others
<JordanBrown[m]> I think they are all decently stable.
<JordanBrown[m]> I'm sure some are better than others. But I don't think anybody tries to figure out which those are.
<JordanBrown[m]> But are you using any of the unreleased features? If not, you might want to stay with 2021.01.
<InPhase> sinned6915: I just stick with latest. Any bugs recently added that we're aware of are among the easiest things to fix.
<gbruno> [github] kintel pushed 1 modifications (libzip: Make build more robust; don't pick up unused packages from the system) https://github.com/openscad/openscad/commit/ddef09f4f359a84636a5fe7b7029d74de23651a4
<gbruno> [github] kintel opened pull request #4477 (macOS: libzip: Make build more robust ) https://github.com/openscad/openscad/pull/4477
<gbruno> [github] kintel closed pull request #4476 (Remove redundant cruft from FindGLIB2) https://github.com/openscad/openscad/pull/4476
kintel has joined #openscad
<gbruno> [github] kintel pushed 1 modifications 1 removals (Remove redundant cruft from FindGLIB2 (#4476)) https://github.com/openscad/openscad/commit/a75477d90c8fb5ff9c17a94cf08b7ed56d5998d5
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
L29Ah has quit [Read error: Connection reset by peer]
<sinned6915> how can i multiple lines to honor the for..i loop?
<JordanBrown[m]> You can have multiple lines in a for(), or in any construct, using braces
<JordanBrown[m]> for (i=[1:10) {
<JordanBrown[m]> ...
<JordanBrown[m]> }
<sinned6915> all these lines are 1 ... nbush/2
<sinned6915> so everything between the braces will refer back to the for-i loop
<JordanBrown[m]> yep
<JordanBrown[m]> I wouldn't say "refer back to". The stuff in the braces are the children of the for loop.
<JordanBrown[m]> Same for if(), union(), translate(), ... anything.
<JordanBrown[m]> The two forms for a for loop are
<JordanBrown[m]> for (...) one_statement;
<JordanBrown[m]> for (...) {
<JordanBrown[m]> ... zero or more statements ...
<JordanBrown[m]> }
<sinned6915> ok
<sinned6915> renders are taking forever
lostapathy has quit [Ping timeout: 264 seconds]
<JordanBrown[m]> $fn=196 is a very large number.
<sinned6915> i backed it of to 128
<sinned6915> then 96
<sinned6915> still forever
<JordanBrown[m]> I would not normally use $fn at all; instead, I would set $fa=1 and $fs=0.5.
<JordanBrown[m]> Without looking in detail, I suspect that you are asking it to make screw-hole-sized objects with 96 sides.
<JordanBrown[m]> So you have an object with a circumference of, what, maybe 10mm divided into 96 sections 0.1mm each.
<JordanBrown[m]> That's probably at the mechanical resolution of your printer, and significantly smaller than the accuracy that you can actually get out of the plastic.
lostapathy has joined #openscad
L29Ah has joined #openscad
TheAssassin has quit [Ping timeout: 255 seconds]
TheAssassin has joined #openscad
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
ActionDave has quit [Remote host closed the connection]
ActionDave has joined #openscad
<gbruno> [github] MichaelAtOz edited issue #822 (CGAL assertion violation) https://github.com/openscad/openscad/issues/822
wed has quit [Ping timeout: 246 seconds]
wed has joined #openscad
<J23165> if someone told me 5yr ago you can do this with openSCAD  at least i wouldn't know how
califax has quit [Remote host closed the connection]
califax has joined #openscad
<buZz> nice, how many hull() ?
tachoknight has joined #openscad
<J23165> no hulls were harmed for this
<J23165> the fillets around are probably still hull chains
<buZz> did you post the code?
<buZz> s/did/could/
<buZz> :)
<InPhase> That model is a challenging topology category to do smoothly. I see residuals of the iterative geometric pieces that made it work, but it is relatively quite seamless for that sort of solution.
<InPhase> However, beautiful as it might be, that has got to be one of the world's worst teapot designs ever.
<J23165> that hull part is within  the module "Abzweig()" in my lib
<J23165> to get the angle there is a mix of skew and scale involved
<J23165> InPhase what is strange is that https://imgur.com/a/InRuga5  these steps/rings are caused by  +- offset operations
<J23165> https://imgur.com/a/3MX1vxB   ..  should not happen
<J23165> maybe these are also the reason why roof with offsets get problems .. because the offset is creating  bad geometry
J23165 is now known as J23
tachoknight has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
KimK has quit [Ping timeout: 252 seconds]
KimK has joined #openscad
tachoknight has joined #openscad
<InPhase> J23: I've never seen offset do something like in that 3MX url. Do you have a small testcase that does this?
<J23> to round something  you have 4 offset operations .. and  i use 2 sets  with different radii ..   if i remove one set  the error is gone, also when selecting different values for the radii..
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
Sauvin has quit [Ping timeout: 246 seconds]
Sauvin has joined #openscad
<J23> InPhase ..  tried to create a testcase ..  https://bpa.st/YVE72
<J23> it seems the order of  the ir and or  offsets  changes the issue .. so  ir first or second doesn't produce the error (at least in this example)
Sauvin has quit [Quit: Leaving]
Sauvin has joined #openscad
<J23> error can be seen at [ 5.26, 17.15, 0.00 ]
<J23> https://imgur.com/a/JsGoAXd  it assume some floatingpoint  rounding causes this  so the points are not aligned and then following operation causing the gap
<Kalov> i was wondering the other day, what's a good practice about integers and floats
<J23> InPhase here a simpler testcase https://bpa.st/CPRL6
<Kalov> should I try to only use integers or using floats is also acceptable
<J23> Kalov floats always causing problems .. but when calculating points you will always have them
<Kalov> thanks J23
<Kalov> what about freedom units and SI
<Kalov> is there a good practice when mixing both?
<J23> the units in scad are mm  (at least if you export them to stl/3mf)
<teepee> yes, it's the export that's using fixed units
<teepee> openscad itself has none
<teepee> at some point there is hopefully a dialog that would also allow different units for 3mf or svg
<J23> International System of Units (SI)    .. this is like OTAN  ..  the french again
<teepee> I think the bot also has some idea about units :)
<teepee> mush!
<J23> teepee have you seen my last paste?
<Kalov> i think a good practice could be, working pieces apart and then just scaling them
<teepee> yeah, I guess mixing is best avoided as much as possible, some Ariane rocket can attest to that ;-)
<teepee> J23: which one? the fancy tube thing?
<teepee> that's very impressive stuff
neur0 has joined #openscad
<J23> thanks .. no i meant the latest  https://bpa.st/CPRL6
<J23> the step error that should not be there
<J23> (fun fact the imperial units are also based on the meter)
<teepee> the error could be due to the floating point -> fixpoint conversation
<J23> yes that is what i feared ..  with more operations that step converts to a gap and a void /intersection
<J23> an probably the reason for the issues with  roof
<J23> https://imgur.com/a/3MX1vxB   had this on my surface .. and  couldn't understand why
<teepee> could be, yes
<teepee> I wonder if clipper2 helps here as it has a floating point interface. maybe the internal conversion is working better
* J23 crosses fingers thrice
<InPhase> Kalov: Here's a scad file I wrote for working with imperial units. Feel free to take what you need from it: https://bpa.st/M3WJC
<Kalov> thanks InPhase!
<InPhase> Kalov: It keeps mm as the "number" unit, but then you specify inches with in(5) or feet with ft(6). Or you can use mils, or fractions of an inch.
<Kalov> did you set an expiration date in the paste?
<InPhase> 1 month
<Kalov> k, i better download it then
<InPhase> I could post this on github, just I hadn't seen a lot of interest in it, so it lives only in my files for now. :)
<J23> InPhase .. where is the fathom?
<InPhase> I see you mocking our national units.
<InPhase> Which... is totally understandable. ;)
<InPhase> mm are so much better to work with, but it's nice to take the cognitive load out for matching things up with external parts.
<InPhase> That ImpStr function for canonically printing out an imperial equivalent to a mm size is a handy convenience function as well.
<InPhase> I wrote that mostly as an exercise though. I've never used it in practice, but, I can see it being handy.
<J23> https://www.ngs.noaa.gov/web/news/us-survey-foot.shtml  one foot further into the future ..
epony has quit [Ping timeout: 268 seconds]
<InPhase> J23: Interesting. I wonder if that redefinition made my property 2 millionths smaller in each direction? :)
<J23> you always get less and pay more .. else it is not binding
califax has quit [Ping timeout: 255 seconds]
califax has joined #openscad
aiyion has quit [Ping timeout: 255 seconds]
aiyion has joined #openscad
kintel has joined #openscad
<gbruno> [github] kintel pushed 1 modifications (libzip: Make build more robust; don't pick up unused packages from the system (#4477)) https://github.com/openscad/openscad/commit/8f7dd26fcb00d937aa529e33d163eb16c89c2772
<gbruno> [github] kintel closed pull request #4477 (macOS: libzip: Make build more robust ) https://github.com/openscad/openscad/pull/4477
epony has joined #openscad
fling has joined #openscad
fling has quit [Remote host closed the connection]
Guest20 has joined #openscad
Guest20 has quit [Quit: Client closed]
<JordanBrown[m]> I have to wonder how many of the "floating point" errors are really introduced by snapping to the grid.
<JordanBrown[m]> One of these days I need to build an experimental where I can control the grid behavior, so that I can see for myself how it behaves.
<teepee> just use fast-csg
<JordanBrown[m]> fast-csg doesn't use the grid?
<teepee> as far as I remember the discussion with ochafik, it's not used
<teepee> also I don't think it's relevant for any 2d stuff
<teepee> there's no point in just disabling it without any replacement
<JordanBrown[m]> I'd be interested to see for myself what misbehaves if you disable it.
<JordanBrown[m]> I would say that floating point errors are microscopic, but that "micro" prefix is many orders of magnitude too large.
<InPhase> teepee: I think it gets used still with those polyset conversions, but I'm not clear on where those are happening.
<JordanBrown[m]> I could believe them introducing problems, but I would expect the problems to be down in the 10^-14 range.
<InPhase> teepee: So it comes down to the fact that not everything in fast-csg is done the fast-csg way.
<teepee> yes, if it goes through NEF it would apply again
<InPhase> JordanBrown[m]: I have in fact removed some model problems by dropping the grid resolution to 1024 times smaller.
<InPhase> JordanBrown[m]: I raised this as a possible codebase change many years ago, but kintel was opposed to it believing it would slow too much down. I did not notice a performance decline in the things I was attempting, however.
<JordanBrown[m]> I've wondered about that too. If the problems are down in the 10^-14 range, putting the grid at 10^-12 might be enough.
<InPhase> I think we should probably remeasure in the current codebase, the current CGAL, and current processors, because the conclusions from almost a decade ago might no longer be true.
<JordanBrown[m]> Or maybe not, since there's always the possibility that something will snap the wrong way, and the smaller the grid is the more likely that is.
<InPhase> JordanBrown[m]: Well I don't think it was done for correctness, but for speed.
<teepee> it still destroys geometry
<teepee> in my view a much better use of time would be trying out the Manifold library
<InPhase> JordanBrown[m]: So it might also be possible to eliminate the grid snapping altogether. The only reason I did a factor of 1024 was because this allowed me to test it with a minimal code change. (Altering the constant.)
<teepee> I wish I had time looking into that
<JordanBrown[m]> I don't know the internal discussions; I thought I'd heard that the grid was there so that two points that were intended to be the same, but that were epsilon apart because of floating point error, would be snapped to the same value.
<InPhase> JordanBrown[m]: But we'd need to define a set of appropriate models to benchmark, ideally of various different types of construction, and then compare performance with current, with a much smaller grid, and with no grid snapping. And probably we need to test this with and without fast-csg. But I suspect we actually have the opportunity to remove it altogether now.
<teepee> yes, I think that's one of the main issues, also preventing complexity explosion in CGAL
<JordanBrown[m]> Yes.
<teepee> fast-csg intends to replace via remeshing solving the complexity problem differently and geometry aware
<InPhase> I don't think any "epsilon apart" problems are actually solved.
<kintel> I was talking to Emmett about Manifold a month or so back. He've very excited about it and strongly believes it's robust enough.
<JordanBrown[m]> :e#
<JordanBrown[m]> oops
<kintel> He may not have time to contribute to OpenSCAD, but I think he'd take bug reports :)
<InPhase> It's super easy to make designs where "epsilon apart" ambiguities cause render issues. I made one for the wiki docs, and I didn't even think very hard to do it.
<teepee> ochafik did also do a quick comparison and fast-csg is not *that* bad performance wise
<InPhase> So if grid snapping is to be fixing that, it's failing I think. :) But, I do believe it at one point made some performance differences.
<teepee> but it still has some issue where it gets stuck due to complexity explosions
<teepee> also maybe at some point manifold gets some usable GPU support. I don't think the nvidia stuff is usable in general builds
<InPhase> If we could remove 90% of design failures that e.g. JordanBrown[m] faces, but make some rare designs take a little longer, while making no performance difference on most designs, that would be an improvement to my perspective.
<teepee> but as it has that support, it's basically ready to work this way
<InPhase> But we'd need to see some data to really reassess this.
<teepee> well, everyone make a new-year wish that ochafik comes back :)
<InPhase> :)
<JordanBrown[m]> I run into problems like this only very rarely, if ever, because I do almost everything with primitives, not with polyhedra.
<InPhase> Making the grid finer, that's a trivial change that takes like 2 minutes. If anyone wants tips on that I can provide.
<JordanBrown[m]> And only very rarely with imported STLs.
<JordanBrown[m]> Like I said, I want to look at it sometime. But not today. Today is objects :-0
<JordanBrown[m]> :-)
<InPhase> Removing the grid would be a little more effort, but I think really not that much. The grid is used very few places in the code.
<InPhase> The bulk of such a project is testing to figure out what is actually the right decision.
<kintel> I once spent a lot of time doing large-scale performance measurements to detect regressions like this: https://github.com/openscad/statistics-scripts
<kintel> ..basically by pulling a lot of stuff off Thingiverse, to avoid relying on too perfect test cases
<kintel> ^ this was mainly used to justify implementing the clipper-based 2D pipeline
<InPhase> Woah, that's a kintel.
<InPhase> I didn't even notice you responded above. :) Hi.
<teepee> indeed, and we probably should ask if kintel wants to have an openscad cloak :)
<InPhase> I do suspect he has earned it.
<kintel> I wouldn't mind a cloak :)
<InPhase> teepee: ... Do you even remember how we got those? I might have to check the old logs...
<teepee> there's a special room where we should have a standing invitation as group contactws
<teepee> aha #libera-communities
<InPhase> Yep, I'll request one for kintel.
<InPhase> Just found that in the old logs.
kintel has quit [Changing host]
kintel has joined #openscad
<InPhase> Excellent. kintel, you are now ordained with a cloak.
kintel has quit [Quit: Textual IRC Client: www.textualapp.com]
kintel has joined #openscad
<kintel> thx, works!
<InPhase> :)
<InPhase> Actually, we should probably have a broader policy for cloaks. Perhaps anyone who is set as a member on github?
<InPhase> I guess we hadn't really thought about cloaks in a while, but they're nice.
<JordanBrown[m]> I can't see any difference, but maybe that is because I am looking through a Matrix-colored lens.
<teepee> I would not restrict to github, but I suppose pretty much all people I'm aware of who are not doing coding at least have a github account
<InPhase> So any github member of the project, plus anyone else teepee says, "Hey that person should have a cloak"? ;)
<teepee> as there's no separation like other groups have with /developer /supporter and such, I suppose anyone contributing in any way might be eligible?
<InPhase> There's a representation aspect as well, so we want well-behaved people.
<InPhase> But I'm not aware of any social misbehaviors of anybody on the list.
<JordanBrown[m]> We don't talk about Fight Club.
<InPhase> Naturally.
<kintel> <rant>Meson - because the world desperately needed another build system</rant>
<JordanBrown[m]> I haven't looked at Meson, but so far I'm not happy with any build system that I've seen.
<InPhase> I would appreciate a cleaner build system. I haven't looked at Meson, so I don't know if that is it...
<kintel> glib uses it, and I need to convince it to build macOS binaries - fun stuff
<teepee> yes, it also caused some headaches for WASM
<InPhase> I would certainly appreciate a build system with a lot less platform customization, but that can be asking a lot.
<InPhase> That is, after all, the one job.
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<JordanBrown[m]> I should have a very-much-draft PR for the objects work today.
<JordanBrown[m]> Objects, geometry as data, module references.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<teepee> nice!
<teepee> would that also replace the revar object() PR? or would that still make sense in addition?
othx has quit [Ping timeout: 268 seconds]
othx has joined #openscad
neur0 has quit [Quit: ZNC 1.8.2 - https://znc.in]
neur0 has joined #openscad
<JordanBrown[m]> My wad includes his.
<JordanBrown[m]> I think it’s valuable, but one of the things that I want to do is to get this out so that people can play with it.
<JordanBrown[m]> And see which variations resonate, and what features seem needed.
<teepee> yeah, so we need to merge this as experimental feature (as much as possible)
buZz has quit [Ping timeout: 268 seconds]
neur0 has quit [Quit: ZNC 1.8.2 - https://znc.in]
buZz has joined #openscad
buZz is now known as Guest3267
<JordanBrown[m]> I was thinking that some people (notably you and InPhase) would look at it in PR form.
<JordanBrown[m]> s/thinking/hoping/
<JordanBrown[m]> What I have now is definitely not final. In particular, it has two different variations on the syntax for an object literal - one more JavaScript-y, and the other more OpenSCAD-y, one where geometry literals are a separate construct, and the other where a single syntax does both.
<teepee> that we can do, but even slightly wider audience is hard to get other than pushing it out as dev snapshot
<JordanBrown[m]> Yes.
<JordanBrown[m]> But it would be good to get opinions from at least the three of us before merging.
L29Ah has quit [Ping timeout: 265 seconds]
<JordanBrown[m]> There's also questions around the exact syntax allowed for module references, and the exact syntax allowed for bringing a geometry value into the model. For that matter, there's the question of whether we support module references *at all*, given that with geometry values a function is almost equivalent.
<JordanBrown[m]> There's some internal cleanup that ought to be done, but I figure that it is best done after we've figured out the answers to some of these questions - there's not much point to polishing the internals of something that we decide to throw away.
kintel has joined #openscad
Guest3784 has joined #openscad
Guest3784 has quit [Client Quit]
<gbruno> [github] kwikius synchronize pull request #4367 (ModuleLiterals: making openSCAD modules first class.) https://github.com/openscad/openscad/pull/4367
castaway has quit [Ping timeout: 260 seconds]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<InPhase> JordanBrown[m]: It's good timing. I should have time to look into it from the 29th through 31st.
<InPhase> It is one thing to theorize about usage, and another to try using it.
<JordanBrown[m]> Yes, exactly.
<InPhase> JordanBrown[m]: Also, I think you're on that eligible-for-a-cloak list, if you want a nice cloak that you can't see. ;)
<JordanBrown[m]> I don't know what a cloak is...
<JordanBrown[m]> (In this context, that is.)
<InPhase> -!- kintel [~kintel@bras-base-toroon0964w-grc-25-184-148-114-68.dsl.bell.ca] has quit [Changing host]
<InPhase> Not cloaked.
<InPhase> -!- kintel [~kintel@openscad/kintel] has joined #openscad
<InPhase> cloaked
<JordanBrown[m]> What do I look like, coming in from Matrix?
<JordanBrown[m]> I should be sort of a green sepia tone :-)
<InPhase> -!- JordanBrown[m] [~jordanbro@2001:470:69fc:105::2:8434] has joined #openscad
<JordanBrown[m]> Ooh, all fancy and IPv6-y.
<InPhase> Oh, but you have not authenticated your account via Matrix, so you cannot get a cloak on that unless you setup sasl or whatever via matrix.
e2k has quit [Ping timeout: 260 seconds]
castaway has joined #openscad
<JordanBrown[m]> I have no idea how that interaction works. I'm authenticated to Matrix, but here we're talking about how Matrix proxies me over to IRC.
tachoknight has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
milza has joined #openscad
Guest8040 has joined #openscad
Guest8040 has quit [Client Quit]
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
othx has quit [Ping timeout: 252 seconds]
aiyion1 has joined #openscad
aiyion has quit [Remote host closed the connection]
othx has joined #openscad