<peepsalot>
teepee: i think i've mostly got it, but that change of additional input buttons seems like its messing up translation update which does fuzzy matching. e.g. "Button 17" -> "按鈕 1"
<peepsalot>
looking at it closer, a lot of these fuzzy matches are obviously wrong. seems not very effective
<teepee>
yeah, the fuzzy stuff is pretty bad, but it's not active normally
<teepee>
but why would it even change? if it picks up all the files, it should not change much except for the comments
<teepee>
button 17 is probably just new, so that's unrelated to the file move
<peepsalot>
what do you mean why would it change? I'm running translation-update.sh, which updates the .po files.
<peepsalot>
teepee: how can you tell if fuzzy is "active"? so do the "fuzzy" sections in .po files get ignored anyways?
<teepee>
I think they are ignored in the application, they are only used as hint in the editor to easily activate / fix
<teepee>
I mean moving files around should not impact any translation, only the comment in the po file showing where the text is coming from
<peepsalot>
ah, yeah it just hadn't been updated since those button changes though
<teepee>
yep
<teepee>
concern would only be lots of completely commented out translations
<teepee>
those would mean it did not pick up the files having those texts anymore
<peepsalot>
progress! less than 300 files in flat /src now :P
<peepsalot>
if we move "*cgal*" into its own subdir, we can get below 250
<peepsalot>
just thinking how else we could organize the file structure... like putting all (im|ex)port.* into an "io" dir might be nice, then maybe a (render|graphics|gl) subdir for all graphical things
<peepsalot>
not sure what else could/should be done beyond that. i think organizing scad language files in some way would be helpful, like putting all AbstractNode related files in one place
<InPhase>
Well what do we have... gui, command line, language/parsing, computation, geometry processing.
<InPhase>
IO
<InPhase>
I guess a lot of the command line logic is just in the main file, and then calling things processed elsewhere, so that might not be suitable for a directory.
<InPhase>
Geometry processing has a big cgal chunk, but is not all cgal, but only some of that has good file division.
<peeps[win]>
InPhase, yeah, the thing is most of those are already pretty muddied command line functionality is everything that's not gui. parsing/computation are practically the same step.
<InPhase>
Really shouldn't be. ;) But yeah.
<InPhase>
It is hard to arrange into divisions that aren't really there.
<InPhase>
Ideally we'd have a libscad that the command line and the gui both utilize.
<peeps[win]>
i'm also hoping that, as the file/dir structure gets more organized, it will help show pain points where files should arguably be split up or refactored in some way
<InPhase>
There are maybe some utils, like degree_trig.h, version.h, ... others maybe
<InPhase>
memory.h is a utils
<InPhase>
I feel like function.*, value.*, module.* should share a home, perhaps with some things that make heavy use of them.
<InPhase>
Or well... If module.* goes all the node stuff goes too? Not sure.
<InPhase>
Maybe not. I guess that's output from instantiate in modules, so separable.
<InPhase>
So function.*, value.*, module.*, exceptions.*, localscope.* ...
<InPhase>
expression.h and expr.cc which should be co-named go with that.
<InPhase>
I would be okay with "compute" as a subdirectory name for that set. It might have a few other members I missed.
noonien has joined #openscad
<InPhase>
I think the more you can pick off some to subdirectories, even if incomplete, the clearer the rest will become to see.
<InPhase>
Absolutely make an "export" subdirectory. In it, put export_* :)
<InPhase>
and export.h
<InPhase>
We have 13 files with csg in the filename, 36 files with cgal in the filename, before we even think about contents of the rest.
<peeps[win]>
InPhase: what, if anything, do you think is appropriate to stay in top level src ? openscad.cc ?
<InPhase>
builtincontext.*, context.*, contextframe.*, evaluationsession.*, modcontext.*, parameters.*, and primitives.* also belong with that "compute" set I identified.
<InPhase>
peeps[win]: I would say we start with "what's left"...
<InPhase>
peeps[win]: openscad.cc obviously, although there should be MUCH less in that file at some point.
<InPhase>
But realistically I see the future here. There will be some mixed up intermediate files that just don't fit into categories. Those stay top level until a smarter organization is apparent or possible.
<InPhase>
In fact there will probably be a lot of them.
<InPhase>
But it would be great if it were... dozens or less.
<peeps[win]>
i have no idea why there's so many [xxx].cc but the header is [xxx]node.h
<InPhase>
lol, yeah. Mismatched .cc and .h files is a mess in this project. I don't think I've ever seen quite so much of it before. :)
fling has quit [Ping timeout: 256 seconds]
<InPhase>
Okay. Want an example of that node thing going really wrong? import_* and import.h belong in an "import" subdirectory. importnode.h does not. import.cc is an implementation of importnode.h and not import.h
<peeps[win]>
yeah, not good
<InPhase>
The subdirectory agenda helps identify that. I never spotted it before, and I've looked at many of those imports.
<InPhase>
A rename is also a fair choice.
<peeps[win]>
also confusing: render.cc rendernode.h
<InPhase>
I see that some of these .cc files have more they implement than just in the node.h file, namely the things like builtin_render. But this is still too messy. I'd rather have separate .cc files for the separate parts than have mismatched files.
<InPhase>
The only header files without name-matched cpp files should be header-only components.
<InPhase>
peeps[win]: Maybe if you agree with the general suggestions already discussed, try some relocating and pastebin the output of running "tree".
<InPhase>
peeps[win]: That will make the evolved state of things clearer.
<peepsalot>
InPhase: what do you think about things that legitimately belong in two categories at once? CGALRenderer.cc seems like it could go in a src/render but also src/cgal. should there be a top level src/render (for lots of Offscreen.* and other gl things) but also a src/cgal/render ??
<InPhase>
So a cluster analysis should depend on how separable they are I guess. First-order check with where the headers are used says that these should be fine in separate render/ and cgal/ subdirectories.
<InPhase>
Or if anything maybe render/cgal
<InPhase>
I suppose cgal is properly a subset of rendering, even if it's used for a non-render step.
<InPhase>
You can theoretically also overly divide things with overly aggressive hierarchies.
<InPhase>
So I'm somewhat indifferent I guess to exactly how those end up. But I'd say cgal stuff could be off by itself.
<peepsalot>
btw i'm referring to a "render" subdir for graphical render on GPU, OpenGL, to png. but not as in render to STL
<InPhase>
Oh... Maybe a different name for that.
<InPhase>
I missed that distinction.
<InPhase>
Yes, I see it now when I actually look at the file contents. :)
<InPhase>
GLrender maybe, or something that distinguishes it. "render" is a reserved keyword. :)
<InPhase>
imagerender
<InPhase>
Anything that direction
<peepsalot>
maybe a whole "glview" dir, even though GLView is also a class
<InPhase>
That could work.
<peepsalot>
or just "display" ?
<InPhase>
I appreciate glview I guess. This is probably used for some non-gui processes, right?
<InPhase>
Like image output by command line?
<InPhase>
Whereas "display" might be misinterpreted as more of the gui than just the image portion.
<peepsalot>
yeah, command line, so all the offscreencontext stuff will be going in there too
<peepsalot>
i'll go with glview then
J2228 has joined #openscad
J22 has quit [Ping timeout: 256 seconds]
KimK has joined #openscad
epony has quit [Read error: Connection reset by peer]
epony has joined #openscad
epony has quit [Remote host closed the connection]
arebil has joined #openscad
epony has joined #openscad
<peepsalot>
InPhase, teepee: here's what I came up with as a first draft proposed file layout: https://bpa.st/5HZQ
<peepsalot>
src/ext is unchanged, src/gui is same as my PR above. the few things remaining in top level src either seemed appropriate there or I couldn't figure out a place
<peepsalot>
most of the language processing stuff ended up in "core"
<peepsalot>
i left all the filenames the same so they can be more easily compared with existing tree. but would still want to fix all the core/*node.h to have matching .cc files, etc.
<peepsalot>
a few other things I wasn't sure about like src/glview/preview/csgnode.* and src/glview/preview/CSGTreeEvaluator.* are maybe more "core" and not preview/OpenCSG specific. I don't know, its hard to say since the code flow kind of mixes it all together
<peepsalot>
"geometry" holds files related to the data structures AND computation of output geometry
<peepsalot>
should i copy all this into a github issue for discussion?
<InPhase>
Well, that structure looks like a good upgrade.
<peepsalot>
rewriting all the include paths will be a chore
ur5us has joined #openscad
epony has quit [Ping timeout: 240 seconds]
ferdna has quit [Quit: Leaving]
epony has joined #openscad
lastrodamo has joined #openscad
fling has joined #openscad
ur5us has quit [Ping timeout: 240 seconds]
<buZz>
whats a easy way to make a 'reprap teardrop' ?
<buZz>
the , eh, round at the bottom. point at top, like the reprap logo
<J2228>
square and a circle ?
<J2228>
square(5);
<J2228>
circle(5,$fn=36);
<J2228>
buZz
<buZz>
ah, just flat you mean, or rotate the square?
<buZz>
hmm
<buZz>
i guess i could just do a 0.1 square and hull() ;)
<J2228>
you need that in 3D .. just cut and rotate extrude
<buZz>
i guess nopscadlib has it ;)
<J2228>
$fn=36;
<J2228>
rotate_extrude()
<J2228>
intersection(){
<J2228>
rotate(45)
<J2228>
union(){
<J2228>
square(5);
<J2228>
circle(5);
<J2228>
}
<J2228>
translate([0,-50])square(100);
<J2228>
}
<J2228>
if you need them for holes .. i have them with flat top
<buZz>
just want to make it a bit more carefree before i share it ;)
<J2228>
the Tdrop() in my lib auto calc the flat and angle from nozzle and layer
<J2228>
you also could just scale the arc a bit
<buZz>
only real motivation was just saving material, so maybe i could just make rectangular without losing too much strength
<buZz>
+it
<J2228>
bridging works better .. or do a 60° angle
<J2228>
(or use supports) Ü
<buZz>
nooo
<buZz>
:P
<J2228>
you could do some tree/ voronoi but in the end this will use more material
<buZz>
https://imgur.com/a/I5JTAZU <- getting that top to print -at all- required me to fix the print while printing with a ruler :P
<J2228>
keep in mind that 3D prints are hollow so all that weight saving by using holes doesn't apply here as it is not solid and you increase surface ⇒ hence walls
<buZz>
this print was 100% filled :) most often my prints are
<J2228>
well the Tdrop exist for that reason
<J2228>
a bridge is also not looking perfect
<J2228>
printing flat with a hinge
<buZz>
hmhm
<buZz>
well i want it to survive the abuse thats my backpack plus random throwing around, just a solid stand for the 3ds (but works for a lot of others)
<J2228>
with a hinge it would store flat .. so less volume and less force
<J2228>
but a hexagon for the opening looks also nice and print clean
<peepsalot>
teepee: any thoughts on the source tree organization? would you rather the gui relocation be merged separately from the rest or just do all the changes in one PR?
Matt100 has joined #openscad
myosotis has joined #openscad
<teepee>
peepsalot: gui separately would probably help by not conflicting with all the open cgal changes
<teepee>
in most cases git catches simple file moves, but there's quite some stuff open right now
<teepee>
if it's not too messy or too big a change it would be nice to find a separate place for libsvg with it's own CMakeLists.txt
<InPhase>
peepsalot: Rather than rewrite the include paths, the other directories can just be bundled into CMakeLists as include paths. That centralizes it, and facilitates later reorganizations.
<teepee>
not hugely critical, but it originally was intended to be a "separate" library and has different license
<peeps[win]>
teepee, ok, sounds good.
<peeps[win]>
for libsvg, are you looking at the pastebin? i put libsvg under io there. that is original code from our org though right?
<peeps[win]>
what about as another git submodule, with its own repo?
J2228 is now known as J22
<teepee>
yes, that's mostly written by me
<teepee>
hmm, submodule, not sure. I guess we started that already :-)
myosotis has quit [Quit: myosotis]
<teepee>
but then we don't know if anyone would ever be interested in using it separately
<peeps[win]>
what is the reasoning for being "separate" library? i guess it helps have a more clearly defined interface? would you want to keep it statically linked?
<teepee>
yeah, fully separate parsing code, and also the more relaxed license
<teepee>
kintel always considered making openscad itself MIT or something, but I guess that ship has sailed some time ago
<teepee>
so we discussed having some of the bigger spearate parts maybe as MIT where we have the control
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<teepee>
yeah, not sure I've seen that in action
<teepee>
I vaguely remember having some code that does 3d isometric export to SVG
<teepee>
but I think that was different code
<teepee>
this is 10 years old code from Don
<peepsalot>
sounds like dead code, I'll try removing it from #include's and CMakeLists and see if there's any build complaints
<peepsalot>
teepee: if libsvg is given its own CMakeLists, where would you place it ideally?
<peepsalot>
it seems like it should go outside of /src in some other top level dir. I'm thinking either /libsvg (similar to /winconsole), or something like /libraries/libsvg (except libraries has MCAD so i've always interpreted as scad libraries)
<teepee>
libraries is pretty much gone for scad libraries I guess, even though I don't expect we want to add more
<teepee>
I would not mind /libsvg or we find a good name to move both libsvg and winconsole to
linext_ has joined #openscad
<peepsalot>
ok, i'll probably try /libsvg then, when i get to that. for now I'm just trying to get a build working after all these other moves
linext has quit [Ping timeout: 260 seconds]
little_blossom has quit [Remote host closed the connection]
little_blossom has joined #openscad
<peepsalot>
question about how we prefer to handle #include paths. I guess the simplest thing would be to just add any new paths to the compiler's include dirs "-I", but that kinda seems like bad practice / error-prone
<peepsalot>
so for example, some files in src/gui/input would include headers from src/gui. I did some search and replace like: #include "foo.h" #include
<peepsalot>
but this sort of unnecessarily changed some files in src/gui which include other src/gui headers. they could have kept relative path since in same dir
<InPhase>
The risks are basically just from using the same filename twice. Of course we haven't done that since they all came out of the same directory very recently.
<peepsalot>
InPhase: ok, so you would vote for minimal #include edits in source, and just add all paths to compiler include dirs?
<peepsalot>
another question, is it ever acceptable to include relative parent dir: "../foo.h"
<InPhase>
peepsalot: I do endorse it that way. On relative directories, I try not to do that outside of testing code. It feels fragile.
<InPhase>
I think there is, indeed, a small theoretical risk to putting a bunch of includes. But it should be fairly easy to recognize from the compiler errors when it happens.
<InPhase>
s/of includes/of include directories/
linext_ has quit [Ping timeout: 245 seconds]
<InPhase>
But on the pro-side, the maintenance and flexibility to move things around goes up substantially.
<InPhase>
I'm not sure if there's any agreement on a standard best practice out there for this, but those are my thoughts, and I think the conclusion holds true for this size scale of program up through at least a bit larger. It might stop holding true if it were extremely large.
<InPhase>
Putting the locations in CMakeLists seems to me to be about reducing interdependency between the files, which is usually a plus.
linext_ has joined #openscad
<peepsalot>
well... time to go undo all my gui source edits :P just putting all paths as include dirs definitely makes maintenance easier. it just felt kinda wrong to me
<peepsalot>
gui pr fixed up, much less edits of renamed files now.
<peepsalot>
i can basically comment those out and then it builds fine without svg.cc and svg.h. seems like another candidate to move into dev-support repo?
GNUmoon has quit [Ping timeout: 240 seconds]
<peepsalot>
InPhase: are there any particular cases where you DO prefer to explicitly #include a subdir? #include "subdir/file.h" as opposed to having "subdir" in the compiler incdirs
<peepsalot>
just curious... btw, i got the compile to finish locally after all those moves, with just a few added include dirs in CMakeLists. so my ignore comment from before of how it would be such a "chore" ;)
myosotis has joined #openscad
lastrodamo has quit [Quit: Leaving]
myosotis has quit [Quit: myosotis]
<InPhase>
peepsalot: Well for external libraries I like the subdirectories approach from the base directory. But I think there's a logic to this, in that you do not control the filenames of external libraries.
<InPhase>
peepsalot: Dropping a whole lot of externally managed subdirectories is likely to give you a surprise "namespace" collision even when nothing internal has changed.
<InPhase>
It depends on the library of course, but some libraries have a ton of files with a lot of common names.
<InPhase>
time.h, utils.h, standard sorts of hazards. :)
<InPhase>
It's easier to not shoot yourself in the foot, than to avoid getting shot in the foot by a bunch of monkies firing randomly.
<teepee>
peeps[win]: I'd tend to keep the svg.cc for now. I'm not sure what it does and if it's work keeping, might be something for a later cleanup
<teepee>
yeah, that's all debug stuff copied from the old class I think
<InPhase>
Ah, copy/paste?
<teepee>
most likely, I have not checked :)
<teepee>
well, the commented out part is from CGAL_Nef_polyhedron.cc
<InPhase>
Ah, I see there was a working unused dump_svg in CGAL_Nef_polyhedron previously.
<InPhase>
So yeah, it looks like testing code.
<teepee>
lets call it compiled, no idea about degree of working ;-)
<InPhase>
Fair. :)
<teepee>
it probably produces something, question is who knows what it means
<peeps[win]>
teepee, ok, i can save it for a later change. does the gui organize PR look ok to you? https://github.com/openscad/openscad/pull/4159 once I merge that, I can open new PR with the rest of the file moves
<teepee>
uff, 166 files :)
<teepee>
give me a minute :)
<teepee>
but it's probably fine, compiling and green tests should be pretty much the guards needed
<peepsalot>
oh yeah, forgot about libsvg, its still under src/io/libsvg for now
<peepsalot>
btw here is "tree --dirsfirst" output for latest revision in case anyone cares: https://bpa.st/BIEQ
<peepsalot>
I moved a few files around, but mostly the same
<peepsalot>
another 3 cgalutils files to move
<teepee>
hmm? CsgInfo is used in export_png
<teepee>
strange
<peepsalot>
i just noticed my latest local build (Release build type) resulted in a 20MB openscad executable on linux. wonder how its getting so bloated. seems like it was <10MB not too long ago
<teepee>
hmm, stripping my debug build gives 15mb
<peepsalot>
what's the command to strip symbols?
<teepee>
for stripping everything, just "strip openscad"
<teepee>
for just the debug stuff --strip-debug
<teepee>
but that probably only makes a difference for libs or so, not sure
<peepsalot>
hmm, my release build went from 20655056 to 16474832 bytes from just "strip openscad"
<peepsalot>
i didn't realize strip was its own command thought there was some binutils objdump or something
<peepsalot>
what is it stripping if its already a release build?
<teepee>
no idea if it can detect some unused stuff or if there's other non-debug sections even in release mode
ur5us has quit [Ping timeout: 256 seconds]
snaked has quit [Ping timeout: 240 seconds]
ur5us has joined #openscad
<peepsalot>
teepee: if i --strip-debug it only reduces size by about 6K
<peepsalot>
i don't even understand what symbols are, if not for debugging
<teepee>
shared libs have some stuff that breaks with full strip, IIRC
<peepsalot>
well, i ran "nm openscad > nm.dump" and got a 4MB file of symbols, fwiw