<linext_>
and all of them can be merged into 3dcustomizer.net to be rendered in real-time on the user's PC
<linext_>
and beyond
<teepee>
decentralize all the things :)
epony has quit [Ping timeout: 252 seconds]
epony has joined #openscad
<teepee>
well, that and making things dumber again :/
<teepee>
I now have a desk lamp that can't be switched off when running on the new multi-port usb adapter
<TIBL>
sounds like something you chose :P
<teepee>
not really, with only one power outlet slot left
snaked has quit [Remote host closed the connection]
snaked has joined #openscad
<teepee>
but yes, there's options still.
<TIBL>
I mean there are tons of lamps which don't have anything fancy, just a physical switch (except that the light bulb now will always have electronics but at least it is not connecting to the internet in a cheap bulb....yet)
<TIBL>
yet.
<TIBL>
soon, every $3 bulb will require you to download an app and make an account to activate it
<TIBL>
:)
<InPhase>
teepee: The GSoC site seems to malfunction every year around submission times.
<teepee>
InPhase: they seem to have build either a new one again or did some extensive changes
<InPhase>
teepee: Most likely because Google doesn't own enough servers.
<teepee>
it's really annoying when filling out a form it jumps to the top saying it was not refreshed for a couple of minutes
<teepee>
at least it did not forget what I did type before, I hope
<teepee>
> "It has been 10 minutes since your last data fetch. The data you are currently viewing maybe out of date."
<teepee>
well, no, it's not, *I* am typing that data in, still, because there's a lot of text fields to fill :)
<InPhase>
TIBL: What's the external library I'm missing?
<TIBL>
no idea
<InPhase>
TIBL: A whole lot of include files are not present.
<TIBL>
no doubt I screwed something up
<TIBL>
let me try checking it out
<InPhase>
microswitch.scad etc
<TIBL>
oh maybe that is some of the stuff I copypastad from mendel90 but didn't use
<InPhase>
All coming in from vitamins.scad
<TIBL>
yeah
<TIBL>
that is the mendel90 stuff, weird that I don't see that error
<TIBL>
let me check out fresh
<TIBL>
sure enough
<teepee>
InPhase: so advent calendar, did we decide on a theme yet?
<TIBL>
I think it may not have an impact on rendering the printer since I don't use those things
<teepee>
looking at the date I'm not sure to finish at least one of multip-part the designs I'd like to do
<InPhase>
teepee: Probably "what we get" as usual. :)
<teepee>
I suppose that's the best plan :)
<InPhase>
teepee: Although I think it will be interesting to try that "pass the design around" game for a design or two or three and see how it goes.
<teepee>
I'm not really convinced yet that's a good fit for a day by day opening calendar
<TIBL>
yeah InPhase, the printer renders fine if you ignore those warnings
<InPhase>
teepee: Yeah, maybe not.
<InPhase>
I have one design packed up and ready to go, and Jordan has a really cool one that I won't spoil for him.
<teepee>
otherwise it's maybe a cool thing to try, maybe on the mailing list or as web posts or something
<InPhase>
TIBL: Can I comment them out?
<teepee>
we do have a repo with a number of J1A8430 desings
<teepee>
and designs too
<TIBL>
the only thing I am actually using from that library is the e3d hotend and it appears to render correctly with the checkout so most likely yes
<InPhase>
TIBL: I do see it after 3 minutes and 11 seconds. Longer than I'm used to waiting on previews.
J1A8430 has quit [Ping timeout: 244 seconds]
<TIBL>
DO_RENDER = true in config.scad sets whether render() is called on each part
<TIBL>
compared to the old days, 3 minutes is positively lightning fast :)
<TIBL>
every imported stl is decimated, every part I could find I switched to a very low fn
<TIBL>
but no doubt there are stragglers
<InPhase>
TIBL: Is there a single part I can focus in on that is under performing?
<InPhase>
If so, what file do I use for that?
<InPhase>
It is a truly massive design otherwise. :)
<TIBL>
nah. honestly performance is not a huge issue now with caching of render(). but if fast_csg is to become standard then I need to know why it is half the speed
<InPhase>
Is there a subpart that exhibits that half speed problem?
<TIBL>
don't know, I only tried fast_csg just now
<TIBL>
you can uncomment the HIDE_xxx stuff in config.scad to hide parts
<TIBL>
I am trying some now
<TIBL>
I am trying Y visible only first
<TIBL>
just a hunch
<TIBL>
wow, less than 10 seconds to render
<TIBL>
okay, Y only takes 8 seconds with fast_csg off and 20 seconds with fast_csg on
<TIBL>
(uncomment everything but hide_y)
<TIBL>
the Y carriage is found in xyh_sidecarriage.scad, in my parlance "assembly" means the printed parts and nonprinted parts all rendered together, then the main printed part in this case is sidecarriage_double()
<TIBL>
"assembly" is where I apply colors and render()
<TIBL>
(from my custom color schemes, that's how you know I spend way too much time on this)
<TIBL>
I should put the color schemes in config.scad. right now they are just commented out at the bottom of helpers.scad
<TIBL>
but, you kinda get an idea of the complexity nightmare here.
<TIBL>
btw there are many more modules which I did not actually include in the git dump, heh, several printheads and stuff which are not used on this printer
<TIBL>
ancient z-axis designs
<InPhase>
Well it's throwing up warnings about bad meshes.
<InPhase>
Oh. Well that could be why you're not seeing the errors.
<TIBL>
the times I am talking about are the time it takes to generate the preview upon restarting the program
<TIBL>
I honestly don't give a single crap how long render-to-print takes
<InPhase>
I think render() might still be eating those CGAL errors in preview mode. There was an issue opened about that.
<TIBL>
I would never render the entire printer, that is silly, I would lose my colors :)
<TIBL>
of course rendering stuff is slow as crap with fn=200, I totally expect that, though I'm sure fast_csg is also slowing that down it is okay because I can just set it off and go make some tea
<TIBL>
I do see a bunch of those warnings now that I tried to render it. there needs to be a different term for render() vs render
ali12341 has joined #openscad
ali1234 has quit [Remote host closed the connection]
<TIBL>
also just because the plastic bead is 400 microns wide, doesn't mean the accuracy of the outer wall is 400 microns. It is much, much, much better than that :)
<InPhase>
peepsalot: I have some regrets about endorsing your plan to add support for trailing commas...
<TIBL>
because when it comes to extrusion and such, we're talking about repeatability, the repeatable part can be calibrated
<TIBL>
heh
<TIBL>
comma at the end of everything!
<InPhase>
peepsalot: I don't mind the trailing commas, but now so often I have to remove trailing commas to get code written under the nightlies to work in the last release. ;)
<peepsalot>
heh, just gotta rush out another release
<JordanBrown[m]>
Allowing trailing commas in array initialization was one of the subtle brilliant things about C.
<InPhase>
peepsalot: I guess that will fix it. :)
<InPhase>
JordanBrown[m]: That's a language that used to allow you to omit the return type and just assumed you really meant int. So probably not "brilliant", just par for the course. ;)
<TIBL>
still not as bad as javascript
<JordanBrown[m]>
I didn't say that everything in C is brilliant. But trailing commas is.
<TIBL>
okay, I search/replaced $preview with true in xyh_sidecarriage.scad, only rendered Y, and when I render now I get "WARNING: mesh is not closed!"
<TIBL>
but not the other warning
<TIBL>
so I take it somewhere, in a giant intractable mess, there is a hidden mine which destroys fast_csg
<InPhase>
TIBL: You really spared no expense with these trailing commas...
<InPhase>
min(a,b,)
<TIBL>
when each item is written on its own line, putting a comma after each item very much improves the ability to do things like copy/paste or comment out a line.
<TIBL>
I love trailing commas.
<TIBL>
because of that I just got in the habit of adding one every time always
<InPhase>
TIBL: Also, it's a questionable design to have all of these files included all the time, and switch only inside of each file as to whether or not it should display itself. This probably kills performance on subparts.
<TIBL>
I am still basically using global variables for everything because it is that or functions
<TIBL>
but it's not like I can if/then an include
<InPhase>
I'm noticing the pain of it while removing commas from all sorts of files I'm not using, just trying to get this to appear in the release version so I can test the one I have setup without fast-csg.
<TIBL>
why don't you just turn off the fast-csg option?
<InPhase>
Well I thought this would be faster.
<TIBL>
HAH
<TIBL>
unlikely :)
<InPhase>
But it's like translate([x, y, 0, ])
<InPhase>
Saving space for that 4th dimension. ;)
<JordanBrown[m]>
Putting a positive number there makes the object appear after a delay.
<InPhase>
Naturally.
<TIBL>
it makes sense if you go back to how I figure things out from the video. one axis at a time means I am often commenting out different lines
<JordanBrown[m]>
Putting a negative number makes it appear before you press F5.
<InPhase>
JordanBrown[m]: Which could explain the performance issues!
<TIBL>
honestly I am quite happy with it now that I discovered render() (without fast-csg)
<TIBL>
I love openscad......enough to force it to do things it should never be made to do, probably :)
<InPhase>
TIBL: Well that was a waste of time! It doesn't work in release anyway: https://bpa.st/U5PA
<InPhase>
No idea why.
<InPhase>
I don't think I'm even using the files in question.
<TIBL>
uh
<TIBL>
yeah probably don't bother, I haven't used "release" openscad since that like 5 year period where there were no releases
<TIBL>
I am not in anyway targeting release
<TIBL>
any way*
<TIBL>
it might have to do with including something that has already been included? endstop definitions get included multiple times
<InPhase>
Okay, yeah, definitely slower with fast-csg, but I'm sure it must have something to do with that error that's only appearing under render of this part.
<InPhase>
There's a bad mesh somewhere, and the CGAL corefinement routines can't handle it well.
<TIBL>
probably many bad meshes
<InPhase>
And this one part file for it is 800 lines.
<TIBL>
only?
<InPhase>
Well, xyh_sidecarriage.
<InPhase>
It has dependencies.
<TIBL>
clearly refactoring is needed everywhere
<TIBL>
I would certainly never dispute that
<TIBL>
in fact, I have described it as "a huge mess" :)
<TIBL>
but what I have really been getting at is that if something dies inside openscad because I did something wrong, it needs to be easy to find out where
<TIBL>
rather than it just being like, "you can't do x, good luck"
<TIBL>
and in this case it doesn't even tell us x, it just says, "you made a mistake. somewhere. good luck"
<TIBL>
that is extremely harsh for the user
<TIBL>
even gcc warnings aren't that bad! ;)
<InPhase>
Yeah, usually I spot the issue pretty quick in other people's code. But this is a beastly pile of code and I cannot separate out the pieces.
<InPhase>
I wouldn't even be able to figure out what part anything is without the "#" trick. :)
<TIBL>
see :P
<TIBL>
when designing this stuff, I considered meshes not broken if export generated a file which was manifold, and I then continued work, adding more layers over years
<TIBL>
and no obvious zfighting in the preview window
<TIBL>
most people use openscad for trivial stuff I guess. but mendel90 is not trivial either.
<TIBL>
maybe you see now why I wished for module pointers and objects with named variables on them though. Man, I wish.
<TIBL>
openscad is like C without struct
<TIBL>
just an array which is clumsy to use
<TIBL>
and no function pointers.
epony has quit [Ping timeout: 252 seconds]
epony has joined #openscad
epony has quit [Ping timeout: 252 seconds]
<JordanBrown[m]>
Fingers crossed that we'll make some progress on some of that.
<peepsalot>
very strange that Polygon2d-CGAL.cc doesn't need to include Polygon2d-CGAL.h
<peepsalot>
i'm going through and removing a bunch of unused include btw
<JordanBrown[m]>
I'm doing something similar, trying to get rid of cases where changes to the core execution engine force rebuilds of the GUI and the import/export modules.
<InPhase>
TIBL: Yeah, we're working on designs for objects now. I think it will get there.
<InPhase>
peepsalot: That's weird.
<peepsalot>
JordanBrown[m]: did you get clangd or IWYU working? or are you just manually refactoring things?
<InPhase>
peepsalot: lol, well where is toNefPolyhedron even defined?
<peepsalot>
it isn't :)
<InPhase>
peepsalot: Is that inside of CGAL?
<JordanBrown[m]>
Mostly manual. I threw together a relatively simple Python program to find #includes and recursively walk them.
<InPhase>
peepsalot: Follow-up, how does anything use Polygon2d-CGAL without a header file?
<InPhase>
Are its declarations misplaced?
<peepsalot>
idk, but linker complains if I remove the .cc from CMakeLists
* InPhase
scratches his head.
<JordanBrown[m]>
I'm making changes in that area, so I'd notice that (for instance) touching UserModule.h causes all of src/geometry/cgal to be rebuilt, so I would ask my program "how does cgalutil-mesh.cc include UserModule.h" and go find the most obvious place to break that chain.
<JordanBrown[m]>
touching Value.h rebuilt just over half of the files :-(
<peepsalot>
well, core files are core for a reason :P
<JordanBrown[m]>
Value.h more than the rest. I think Expression.h can be gotten from its stock 52 files (of 247) to around 20.
<peepsalot>
JordanBrown[m]: sorry, didn't realize you were already going at it, hope its not much duplicated effort
<JordanBrown[m]>
Right now I'm pulling those changes away from my primary work.
<JordanBrown[m]>
No worries.
<JordanBrown[m]>
To a certain extent it's just to make my builds faster, since I'm working in that area.
<peepsalot>
JordanBrown[m]: in case you're still up ^ I finished going through all the src files with clangd.
<peepsalot>
now we just need something to find dead code. call it Delete What You Don't Include (DWYDI)
<JordanBrown[m]>
Looks like I should wait for your change to merge and see if it subsumes mine. It's certainly far more extensive.
<JordanBrown[m]>
But I did take a particular build, when you touch UserModule.h, from 23m33s to 1m28s, from 93 files to 6.
<peepsalot>
JordanBrown[m]: nice. I just mostly mindlessly removed whichever lines clangd marked (and then fixed compile when it broke some weird include chain), sounds like you maybe did a bit more in-depth restructuring.
<peepsalot>
of course I broke something on every other platform
<J1A84>
break it so you can fix it Ü
peeps[zen] has joined #openscad
peepsalot has quit [Ping timeout: 252 seconds]
KimK_ has joined #openscad
KimK has quit [Ping timeout: 252 seconds]
califax has quit [Ping timeout: 258 seconds]
califax has joined #openscad
wed has quit [Ping timeout: 252 seconds]
zauberfisch has quit [Ping timeout: 252 seconds]
zauberfisch has joined #openscad
wed has joined #openscad
ubitux has quit [Ping timeout: 252 seconds]
fardog has quit [Ping timeout: 252 seconds]
ubitux has joined #openscad
fardog has joined #openscad
epony has quit [Ping timeout: 252 seconds]
epony has joined #openscad
guerd87 has quit [Read error: Connection reset by peer]
guerd87 has joined #openscad
little_blossom has quit [Quit: little_blossom]
little_blossom has joined #openscad
wed has quit [Ping timeout: 252 seconds]
wed has joined #openscad
ubitux has quit [Ping timeout: 252 seconds]
stevieh has joined #openscad
ubitux has joined #openscad
epony has quit [Ping timeout: 252 seconds]
epony has joined #openscad
guerd871 has joined #openscad
guerd87 has quit [Read error: Connection reset by peer]
castaway has joined #openscad
paddymahoney has joined #openscad
stevieh has quit [Ping timeout: 252 seconds]
stevieh has joined #openscad
ubitux has quit [Ping timeout: 252 seconds]
ubitux has joined #openscad
guerdy has joined #openscad
epony has quit [Ping timeout: 252 seconds]
epony has joined #openscad
guerd871 has quit [Ping timeout: 252 seconds]
castaway has quit [Ping timeout: 252 seconds]
castaway has joined #openscad
epony has quit [Remote host closed the connection]
epony has joined #openscad
paddymahoney has quit [Ping timeout: 252 seconds]
paddymahoney has joined #openscad
stevieh has quit [Quit: Leaving.]
stevieh1 has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 258 seconds]
teepee_ is now known as teepee
epony has quit [Ping timeout: 252 seconds]
epony has joined #openscad
<JordanBrown[m]>
It wasn't very in-depth. I just looked for wrong-looking lists of files being rebuilt and looked at why. For UserModule.h I think the key thing was that ScopeContext.h was including it, but all it really needed was a forward declaration for class UserModule, and then ScopeContext.cc needed the include.
marcus has quit [Remote host closed the connection]
castaway has quit [Ping timeout: 252 seconds]
<JordanBrown[m]>
Similar stories for Expression.h and Value.h.
marcus has joined #openscad
<JordanBrown[m]>
Expression.h 9m23s and 52 files -> 2m58s and 22 files.
<JordanBrown[m]>
Value.h 29m6s and 133 files -> 23m43s and 113 files.
castaway has joined #openscad
<JordanBrown[m]>
I suspect that "only needs forward declaration" is not something that the automated tools check.
J1A8461 has joined #openscad
J1A84 has quit [Ping timeout: 244 seconds]
fling has quit [Remote host closed the connection]
fling has joined #openscad
epony has quit [Ping timeout: 252 seconds]
epony has joined #openscad
lastrodamo has joined #openscad
<stevieh1>
I really love openscad. Without it I would never succeed in doing 3d printing stuff...
<ndnihil>
eh, you would, you just might not enjoy it as much
<stevieh1>
maybe, but I am not sure... all this mouse moving drawing with low reproduction chances..
<ndnihil>
people who like openscad tend to love it, and people who don't are noobs who haven't seen the light
<ndnihil>
GUI driven CAD has its place
<ndnihil>
and some of them are even quite good
<ndnihil>
there used to be a software called graphite one
<ndnihil>
it was fantastic
<ndnihil>
I practically begged the dude to open source it after they shut down
<ndnihil>
offered to take over as maintainer
<ndnihil>
it was my favorite cad
<InPhase>
The key place for GUI driven CAD is far away from me.
<ndnihil>
but openscad didn't even exist at the time
<stevieh1>
I am right now working on a full parametic word clock... no chance without openscad
<ndnihil>
and it ran native on linux
<ndnihil>
I still have the packages around here somewhere
<ndnihil>
the last version to ever exist
<InPhase>
ndnihil: Did you get the source for it?
<ndnihil>
looks like the website has since been acquired by some web marketing fuckwits
<ndnihil>
InPhase: no... dude would not let go of it
<InPhase>
ndnihil: Maybe he would now. People often have illusions when a company fold that their assets are going to be worth something in an acquisition. But those illusions can fade with time when it clearly does not happen.
<InPhase>
Although maybe that source isn't valuable now as an open source starting point, since it has been a while.
<ndnihil>
it would need a serious shitload of updating to be valid on even semi-modern systems
<stevieh1>
doing UX Design is not a fun for most of the people
<ndnihil>
looks like 2009 was the last time its website semi-existed
<peeps[zen]>
teepee: if the builds all pass, I'm thinking to just merge the header include PR ^^. Any objections, or do you want to give it a look before that?
<peeps[zen]>
the thing I am least sure about is if some platform specific input driver code might have been broken in the process. do the CI servers cover all those? (I don't have QGamepad, spacenav, HIDAPI, I think that's all of them)
fling has quit [Remote host closed the connection]
fling has joined #openscad
ur5us has joined #openscad
<peeps[zen]>
any emacs users in here?
epony has quit [Ping timeout: 252 seconds]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 258 seconds]
teepee_ is now known as teepee
<teepee>
peeps[zen]: if it did trigger the circle-ci builds, it should be fine, the selection is done in cmake so changing headers should not change the feature selection
<teepee>
or so I believe :)
<peeps[zen]>
i mean, for example JordanBrown[m]'s suggested changes (here https://github.com/openscad/openscad/pull/4402#issuecomment-1296272158 ) ended up breaking JoystickInputDriver.cc for me. he didn't touch that file directly in his changes, but some files which are in its #include tree
<peeps[zen]>
teepee: i just wasn't sure if the builds that PR's trigger include at least one with each possible input driver enabled
<InPhase>
ndnihil: Oh. He never could have open sourced GraphiteOne, because its core is a proprietary CAD library.
<teepee>
the test cases may not touch everything, but circle-ci does the official snapshot builds at least for windows and linux, so I would expect those to fail with the "normal" selection of feature if there's an issue
<teepee>
now there could be some cases we don't catch, e.g. macos snapshot build and all those builds on OBS
<teepee>
but that should be fixable without too much trouble, so I'd say go and see what happens :)
<peeps[zen]>
JordanBrown[m]: so I realized that IWYU actually does try to replace includes with forward declarations.
<peeps[zen]>
JordanBrown[m]: from their homepage "The main goal of include-what-you-use is to remove superfluous #includes. It does this both by figuring out what #includes are not actually needed for this file (for both .cc and .h files), and replacing #includes with forward-declares when possible."
<peeps[zen]>
it seems that clangd's implementation is far more limited
<peeps[zen]>
it reported a ton of changes to be made, but actually didn't complete 100% of the build, i think again because of the include cycles it can't deal with
<peeps[zen]>
mostly **additions** of #includes actually
<JordanBrown[m]>
Presumably taking them out of header files and moving them into individual C++ files.
<peeps[zen]>
yeah particularly direct include of every little CGAL header for those files. its like it flattens out the include dependencies entirely
<linext_>
do you think a web app which lets the user submit openscad code in order to generate STLs as tests is a good idea?
<linext_>
the STL could be checked to see if it's exactly the same
<linext_>
kind of like automated programming tests
<linext_>
such as what is found on hackerrank.com
<JordanBrown[m]>
linext_ what are you trying to test?
<JordanBrown[m]>
OpenSCAD does come with a set of tests.
<JordanBrown[m]>
(In the source tree, that is.)
<peeps[zen]>
teepee, InPhase, JordanBrown[m] so I committed the "light" version of #include refactoring based on clangd in that PR. the suggested changes from IWYU would be much larger
<JordanBrown[m]>
The biggest problem is that it would be a fair amount of work, with no immediate and obvious payoff. Some of the changes will likely improve incremental build times, but most won't (and there's probably no way to identify which is which).
<teepee>
well, the payoff would be the possibility to run it from time to time without too much manual work, but if that's worth the initial effort, I don't know
<JordanBrown[m]>
Right.
<peeps[zen]>
maybe just focus on the files that suggest added forward declarations
<JordanBrown[m]>
I mean, I'm a good-hygiene fan, and if I had such a tool from day one maybe I'd put it in the routine build process, but adding on later is work.
<peeps[zen]>
yeah, idk. it feels kinda excessive, for example in the last file listed: cgalutils-applyops.cc (see line 7137 of paste)
<peeps[zen]>
it would add 77 includes to that file
<peeps[zen]>
just figured i'd raise a little discussion about it. i'm not hellbent on going forward with it
<peeps[zen]>
I mean, i see some value in e.g. linalg.h or cgal.h for not repeating the same includes dozens of times, even if it is sometimes wasteful
<peeps[zen]>
although, is it even "wasteful" in terms of compile time when those CGAL or Eigen headers are never edited by us?
<JordanBrown[m]>
Processing lines of source does take time. But in general I'm more concerned about the number of files unnecessarily built for any particular change, and there files that we never change are unimportant.
castaway has quit [Ping timeout: 248 seconds]
<peeps[zen]>
I guess my main question is: Is it really "better" to include every dependency of a file directly?
<peeps[zen]>
if A includes B which includes C which includes D... and A happens to use something from D, should A be required to include D, etc?
<JordanBrown[m]>
It is certainly a simple rule. What if C changes so that it no longer includes D?
<linext_>
the instructions could be, make a 20mm cube with a 10mm cylinder hole from top to bottom
<peeps[zen]>
yeah i mean, then you'd just have to fix A when that time comes. its just that the simple rule leads to 77 extra includes in some files like the example above.
<linext_>
like challenges that require code as an answer
<JordanBrown[m]>
linext_ so testing the programmer, not the software.
<linext_>
yes
<teepee>
ah, like those tutorials with "real" questions
<linext_>
learning exercises that get verified by checking the SQL
<linext_>
STL*
<linext_>
another challenge could be, create a pyramid using only two triangles
<linext_>
four triangles*
<JordanBrown[m]>
Is there value to having automated checking of the results, or do you get enough of the learning value from the user inspecting the results on their own?
<linext_>
students can submit their code and let it run against test cases
<linext_>
ideally, all test cases would pass if the code is equivalent
<JordanBrown[m]>
If you want to turn it into a sort of game, then you need automatic testing, but if the goal is only to work through a tutorial the student can just look at the results.
<teepee>
peeps[zen]: OBS indeed has some issue with SpaceNavInputDriver.cc but it's probably something trivial to fix, I'll wait for all the builds to go through which may take some time
<teepee>
true, but some green "go next" is a nice feature too
<peeps[zen]>
JordanBrown[m]: after a little more thought about it. I feel like if B is a "system file": include <B> as opposed to include "B". then maybe don't require A to include all the nitty gritty includes down the chain
<teepee>
ah PRINTDB and STR missing
<JordanBrown[m]>
I'd say that you should expect including B to get you D's stuff only if B is documented to get you D's stuff.
<teepee>
as just noticed lately on the mailing list, there's a number of people asking how "children()" works who were surprised there's an example shipped with openscad :)
<teepee>
so making that more discoverable via the website would be a nice start into that direction
<JordanBrown[m]>
The problem is that children() is one of those things you usually only find yourself wanting once you've gotten well past the beginner stage, and by then you've probably stopped reading the tutorial. I know I generally stop reading tutorials when I understand well enough to know how to do what I want, and well enough to guess other things that might be available and search for them.
<JordanBrown[m]>
... Which does mean that I might miss stuff late in the tutorial that I never thought to ask for.
<JordanBrown[m]>
But maybe, for instance, https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Transformations should have a brief piece at the end on creating your own transformations using modules and children, with a cross-reference to a more general discussion of children.
<teepee>
14 error mails so far, I think it's 40 builds in total or so :D
<teepee>
hmm, which is actually a bit strange, I thought on fedora/opensuse there's no spacenav enabled
<teepee>
it now suggests to import the constant "e" from boost
<JordanBrown[m]>
But perhaps gamifying it - giving them a list of goals to achieve, and "points" or "awards" for achieving the goals, may help to push them through all of the materials.
<JordanBrown[m]>
teepee yes, that's amusing.
<JordanBrown[m]>
I often think that I want my compiler to just fail after the first error, because so often everything after that is garbage.
<JordanBrown[m]>
I have noticed this particularly with stream << foo, when there is no in-scope definition for the particular foo, because the compiler will then say "maybe you wanted ..." for each of the hundred or so *other* definitions of stream << xxx.
<InPhase>
peeps[zen]: First thing I'd recommend is making a copy, applying all its recommendations, and benchmarking the build as a test.
<InPhase>
peeps[zen]: I assume there's some diff provided to make this easy? In that case, this is an easy first step.
<InPhase>
If that benchmark fails to produce results, then the only thing that needs to be done is focus on its correctness recommendations.
<InPhase>
If the benchmark succeeds in a meaningful enough improvement, then it's worth filtering them for the larger set of the things we will accept changing.
<peeps[zen]>
teepee: oh, yeah Polygon2d-CGAL.cc was the one where its own header was unused. so Polygon2d-CGAL.h can technically be deleted.
<JordanBrown[m]>
Random language trivia: scoping rules can let you redefine builtins while still using those builtins for the implementation.
<peeps[zen]>
teepee: Seems like it needs #include <CGAL/exceptions.h> , which would have come from Polygon2d-CGAL.h -> CGAL_Nef_polyhedron.h -> cgal.h -> CGAL/Exceptions.h
<JordanBrown[m]>
Note that inside module x there is an enhanced version of cube() that uses the real cube() to do its work.
<teepee>
more deletions good :)
<JordanBrown[m]>
But better would be if we had a builtin _cube() so that you could define your own cube() in terms of it.
<JordanBrown[m]>
... though I am not convinced that redefining builtins is a good idea.
<peeps[zen]>
teepee: InPhase and I were a bit perplexed about how the .cc file is used without a header
<JordanBrown[m]>
But I was up late last night and early this morning, and went hiking, and now I need a nap.