<teepee>
only explanation I have is that there's just some merge conflict that's not technically a conflict by overlapping changes but a change in those message classes that were done after the PR branched out
<JordanBrown[m]>
Didn't all of the boost bind global placeholders warnings get fixed? I don't remember seeing any warnings in my MSYS2 build, but I'm seeing a couple of them in an Ubuntu build.
foul_owl has quit [Ping timeout: 268 seconds]
J23 has joined #openscad
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
<JordanBrown[m]>
If I wanted to add a compile option, what file would I add it to (and where?)
<JordanBrown[m]>
Turns out that you can't build a Debug build on MSYS2; it apparently runs out of string table space. The workaround is to turn on -O1 or -O2.
<peepsalot>
JordanBrown[m]: you can add flags on command line during cmake configure step: cmake -DCMAKE_CXX_FLAGS="..." although, i'm not sure if that will go before or after the default -O flag
<peepsalot>
also, you can try -Og
<peepsalot>
... or use -DCMAKE_BUILD_TYPE=RelWithDebInfo
<peepsalot>
when multiple -Ox flags are given, the compiler will use whichever comes last on the build command line
<peepsalot>
you can check the build command lines with: VERBOSE=1 make
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
L29Ah has left #openscad [#openscad]
LordOfBikes has quit [Ping timeout: 260 seconds]
<InPhase>
gbruno?
<InPhase>
Thought maybe I could poke it into revealing where its source code lives. :)
<peepsalot>
i'm wondering if this "extern template" tip would help with build times, particularly with all the crazy cgal templates https://www.youtube.com/watch?v=pyiKhRmvMF4
<othx>
peepsalot linked to YouTube video "C++ Weekly - Ep 330 - Faster Builds with `extern template` (And How It Relates to LTO)" => 1 IRC mentions
califax has quit [Remote host closed the connection]
califax has joined #openscad
ubitux has joined #openscad
califax has quit [Remote host closed the connection]
aiyion has quit [Read error: Connection reset by peer]
califax has joined #openscad
aiyion has joined #openscad
SamantazFox has joined #openscad
SamantazFox_ has quit [Ping timeout: 265 seconds]
ur5us has joined #openscad
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
<JordanBrown[m]>
It would be nice to get more feedback on the object-geometry work.
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
qeed has joined #openscad
<teepee>
JordanBrown[m]: I've started with the model I want to do using the new features
<JordanBrown[m]>
Excellent!
<teepee>
we could try asking around, but that may need some setup, e.g. with links to the builds and such
<teepee>
unfortunately this sometimes still produces not much feedback
<teepee>
what's the "Also as import(geometry)" bullet point?
<teepee>
shortcut for render() import() ?
<J2379>
great i have a design that worked fine when making it .. but after reloadin (cache flush) it totally hang up the system (20GB memory without render)
<teepee>
well, g = render() import() ?
<teepee>
J2379: disable fast-csg?
<J2379>
yes maybe .. i tried with render() but every bit (moving view) and the system is stuck for 20min
<J2379>
ah yes it was a difference with multiple roofs .. probably one of these intersection fup
<JordanBrown[m]>
teepee there are two ways implemented to add a geometry object to the model.
<JordanBrown[m]>
The more likely one is syntactic - given a variable g that contains a geometry value, you can just say "g;". Similarly, given an expression that yields a geometry value, you can just say "(ge);". And some other variations.
<J2379>
only i haven't used any intersection
<teepee>
I know
GNUmoon has quit [Remote host closed the connection]
<J2379>
oh now oscad just closed by itself
<teepee>
I'm just not sure what that bullet point in section "geometry literals / geometry as data" means
GNUmoon has joined #openscad
<JordanBrown[m]>
The other, the first one I implemented, is to use a module for the purpose, that accepts a geometry value as an argument and adds it to the model. For discussion purposes, I hooked that behavior onto "import", so that if you say "import(g);" or "import(geometryexpr);" it works.
<JordanBrown[m]>
Does that answer your question?
<teepee>
not really, what is g in that context?
<JordanBrown[m]>
A geometry value.
<teepee>
if it's a geometry value and g; works, why use import(g)
<JordanBrown[m]>
g = {{ cube(); }};
<JordanBrown[m]>
Do we want the syntactic answer, or a module-based answer?
<J2379>
teepee no fast-CSG was not the culprit it stuck also without it
<JordanBrown[m]>
We should end up with only one of the two, but (especially since I'd already implemented the module-based variant) I wanted both variants available for discussion.
<teepee>
just from useer perspective
<JordanBrown[m]>
just from user perspective... what?
<teepee>
from user perspective, when writing a script, why/when would I write import(g); instead of just g;
<JordanBrown[m]>
They are equivalent. The reason they are both included is so that we can figure out which variant we like better, which one should be included in the final implementation.
<teepee>
hmm, ok
<teepee>
one of the interesting OpenSCAD2 ideas was that obj = import("file.scad"); would return something that (I think) matches the hybrid objects
<JordanBrown[m]>
The advantage to "g;" is that it's terser and more "built-in". However, it comes with syntactic restrictions. You'd like to allow an arbitrary expression that evaluates to a geometry value, but you can't - f(x) looks like a module invocation.
<teepee>
well, that's the technical part, I think we should care about that last
<teepee>
the function literals also needed a serious rewrite to allow the syntax without conflicts
SamantazFox has quit [Killed (NickServ (GHOST command used by SamantazFox_))]
SamantazFox_ has joined #openscad
<teepee>
not something that's ideal as it does increase the risk of breaking some existing syntax
<JordanBrown[m]>
A deeper problem is that f(a)(b) could be either a function f with argument a that returns a function that takes argument b and returns a geometry value, or a module invocation f(a) with child geometry value (b).
<teepee>
but I think we should first try to find the syntax we would like to have and compromise last - using some random special syntax in the meantime to understand the feature is fine of course
<JordanBrown[m]>
import(g) on the other hand requires zero new syntax, and "g" is a completely general expression that evaluates to a geometry value. It's less terse and less built-in, but in some ways cleaner and simpler.
<JordanBrown[m]>
All of that is independent of whether we have the separate associative-array type and geometry type, or if they are combined into a single hybrid type.
<teepee>
I'm not sure I would call it cleaner from the user perspective
<teepee>
import() currently targets external files
<JordanBrown[m]>
Indeed, the name isn't a perfect match.
<JordanBrown[m]>
But the name could be changed to anything.
<JordanBrown[m]>
It could be something new like add(g), or it could overload something else instead.
<JordanBrown[m]>
Syntactically what's important is that it's a module invocation.
<JordanBrown[m]>
We talked briefly about overloading render(), but I'm pretty sure that you want to be able to add a geometry value *without* requiring a CGAL render, and having render(g) *not* do a CGAL render seems wrong.
<teepee>
yeah, maybe slightly better name but not really matching for other reasons :)
<teepee>
right, names are not the thing we need to finally define just now
<teepee>
so I wonder if we have any feature for that "import library file and overwrite some defaults" scenario
<JordanBrown[m]>
I'm not sure exactly what scenario you mean.
<teepee>
the OpenSCAD2 solution always made my head spin a bit, I'm not even sure I always understood how it's supposed to work
<teepee>
trivial example, have a box that can have a cutout for a display or not
<JordanBrown[m]>
One feature that would be nice would be a way to import a .SCAD file into an object, so that you might say
<JordanBrown[m]>
bosl2 = import("bosl2.scad")
<JordanBrown[m]>
and then say bosl2.somefunc() to access one of its functions.
<teepee>
hmm, no bad example
<teepee>
better example is maybe something like a tolerance = 0.2; value
<teepee>
which is global to the library and ideally not passed through all modules
<teepee>
but it still has a default in the library
<teepee>
yes, it would neatly give namespaces I think
<teepee>
well, or something to that effect at least
<JordanBrown[m]>
Importing a file into an object, either through the hybrid syntax or the two separate syntaxes, would do that. The hybrid syntax could do it directly (and in fact could do it today, when combined with "include"); the two-separate-syntax scheme would require a bit more magic, probably something like a special module that you would call or variable that you would set to specify the object to be returned.
<JordanBrown[m]>
As for overriding the value, I'd tend to say that if you felt the need to then you'd want to rethink how you'd designed your library, but could be done with
<teepee>
I think there are more examples somewhere
<JordanBrown[m]>
Hmm. I'm wrong, the hybrid scheme couldn't quite do it yet, because the value that the library's functions and modules would see is the one captured from the scope rather than the one that ended up in the object. "$this", as described in my methods issue, would let you access the values from the object.
<JordanBrown[m]>
That example seems (without having read deeply) to go back to the question of whether objects and geometry values are executable. My model is that they are *not* executable, that once they are created, they're immutable.
<JordanBrown[m]>
Modules are executable; objects and geometry values are not.
<teepee>
and ideally we can keep that while still providing that feature for libraries
<JordanBrown[m]>
I'm not clear on what "that feature" is.
<teepee>
as I said, the reason why Doug did that is because people are actually doing it
<teepee>
have "tolerance = 0.3;" in the library file
<teepee>
include <lib.scad>
<teepee>
tolerance = 0.4;
<teepee>
overwrites that value using the last assignment wins logic
<teepee>
which is why some libararies don't work with use<> or at least have some config file for include<>
<JordanBrown[m]>
My immediate reaction is that $ variables are the right answer there.
<teepee>
plus some try doing that with $tolerance which is very annoying as the old behavior was broken and the new one can't support that
<teepee>
nope, it's not
<JordanBrown[m]>
But you do have to be very careful about search order so that the right things happen.
<teepee>
it was possible, but only because for some reason $variables in library files got one place where they statically injected themselves into the scope stack
<JordanBrown[m]>
and unfortunately they injected themselves at the cross-file call, rather than at use time.
<JordanBrown[m]>
making cross-file calls very expensive.
<teepee>
yes, that's not happening anymore, the expensive part is still there though
<teepee>
and for extra fun, nophead opposes all suggested solutions of fixing that in his library
<JordanBrown[m]>
If the library-supplied values were logically at the bottom of the stack, then caller-supplied values at the top of the stack could win.
<JordanBrown[m]>
BUT there's a more serious problem, which is namespace.
<JordanBrown[m]>
How would you handle two libraries that both use $tolerance?
<JordanBrown[m]>
Other than having to specify it on each call, that is.
<teepee>
that's the point, the only sensible way is the current solution
<teepee>
they don't
<teepee>
they can use it of course, but it has to be set in the normal dynamic scope
<teepee>
which means there's no way to set a default in the library script itself
<teepee>
other than using a function which delays evaluation
<JordanBrown[m]>
other than is_undef().
<teepee>
well, yes, or have it evaluated on every use
<JordanBrown[m]>
which... sucks.
<teepee>
but at the 3rd time everyone would hopefully think a tolerance() function doing the is_undef() would be much neater
<JordanBrown[m]>
I mean, if you need stuff evaluated on every call that's fine, but then it should be inside the module/function, not implicit at the top level of the library file.
SamantazFox_ is now known as SamantazFox
<JordanBrown[m]>
The top level of the library file should be set statically at "use" time.
<teepee>
yes, and that happens now at least partially
<JordanBrown[m]>
Though... one of the things that would be good would be for all cases that "use" a particular library to share one parsed-and-evaluated copy of that library. (Which in turn has implications for the context in which the top level of the library is evaluated.)
<JordanBrown[m]>
Anyhow, must run now. Thanks for looking at it!
<kintel>
I haven't really followed the whole object discussion, but on the topic of use and include, I once started to move that logic into the AST instead of the weird way of doing it today