<kintel>
The one at work I try to stay away from. cmake has more value in the "real world" :)
<JordanBrown2>
Conceptually, I'm not really a fan of the "make preprocessor" model for build systems.
<JordanBrown2>
It tends to mean that if you ever have to look at details, you're looking at much more complexity.
<kintel>
heh, fair. Flip side is that if you give the build system wider powers, people will start exploiting that by building immensely complex things on top. One of the reasons I try to not become an expert at our corporate one :)
<JordanBrown2>
I've never really worked out what it would mean, but I think that what's *really* needed is a build system that natively understands things like file and configuration hierarchies.
<JordanBrown2>
instead of trying to take "make", which is really sort of flat, and make it hierarchy-friendly through recursive make or other tricks.
<JordanBrown2>
but that's really neither here nor there.
<kintel>
The way it's going it seems that every piece of software big enough is creating a new build system to be able to build itself.
<kintel>
..which co-incidentally was how cmake was started : /
<JordanBrown2>
Right, but it seems like almost nobody tries to do it from first principles. They almost all try to build something on top of make.
<JordanBrown2>
I was hopeful when I heard about Ant, years ago, but it (at least at the time) was truly pathetic.
<kintel>
guso78 Q about your python PR. Has been briefly discussed earlier: Since we now pull in the python C library, we make the python native header files part of our include path. However, Python doesn't scope their header files, and have very commonly used filenames. As a result we resorted to some hacks, e.g. use "io/import.h" for OpenSCAD's import.h and just "import.h" for Python
<JordanBrown2>
the basic logic seems good (though it should be double checked by somebody who understands the camera); my biggest questions have to do with source structure.
<kintel>
guso78 I wonder if it would be nicer, since the Python headers are only consumed by a few files, to package those files as an internal library and only expose python headers to that library.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<guso78>
Kintel yes we can do that. Just wondering how to begin with this. Is it a cmake Feature ?
pca006132 has joined #openscad
<pca006132>
yes, it is leaked from manifold
<pca006132>
will open a PR to fix that upstream
<pca006132>
guso78: you can have a subdirectory
<pca006132>
with different build flags comparing to other parts of the build, and use the header file as an interface
<pca006132>
ah, weird, the -Werror should be something private to manifold but is somehow exposed... need to dig deeper into the cmake stuff
<pca006132>
in the compile_commands.json I got, -Werror is not leaked, so I am not sure why it is leaked on other systems. JordanBrown2 can you add `-DCMAKE_EXPORT_COMPILE_COMMANDS=ON` to cmake, and give me the generated `compile_commands.json`?
<pca006132>
guso78: maybe I can help you on the cmake stuff
<JordanBrown2>
pca006132 compile_commands.json is over a megabyte; how would you like me to get it to you?
<pca006132>
from what I can see there is no -Werror applied to sources outside manifold?
<pca006132>
which file is treating warning as error and failed the compilation?
<JordanBrown2>
didn't fail the compilation
<JordanBrown2>
just a scary warning.
<pca006132>
then there is nothing related to -Werror
<pca006132>
kintel just let me know when you can reproduce the -Werror leakage
<JordanBrown2>
yeah, sorry, also not a routine gcc user so I didn't recognize that -Werror referred to "fail on warning"
<pca006132>
yeah, this kind of flags are a bit cryptic
<JordanBrown2>
not really, just not thinking in the right direction.
<JordanBrown2>
and where I was concerned with a warning, you were concerned with a failure, and neither of us realized the disconnect.
<JordanBrown2>
I thought you were talking about a -W option that inappropriately enabled this warning.
<pca006132>
yeah
pca006132 has quit [Quit: Client closed]
foul_owl has quit [Ping timeout: 260 seconds]
arebil has quit [Quit: Bye]
pca006132 has joined #openscad
<pca006132>
kintel: I keep getting the following warning "src/glview/OffscreenView.cc:60:18: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Wstring-compare]"
<pca006132>
provider == "egl"
<pca006132>
similarly for src/gui/ScintillaEditor.cc:966:28
<pca006132>
I think they are legit, just small bugs
foul_owl has joined #openscad
To_Aru_Shiroi_Ne has joined #openscad
ToAruShiroiNeko has quit [Ping timeout: 252 seconds]
To_Aru_Shiroi_Ne is now known as ToAruShiroiNeko
<JordanBrown2>
pca006132 I don't find anything like a comparison to a constant string anywhere near ScintillaEditor.cc line 966. What version are you looking at?
<guso78k>
pca006132 with latest push table should not segfault anymore
<teepee>
J23k72: actually redesigning the small corner panels might not be that big a thing
<J23k72>
the panels look very smooth .. can't see the lines on that image
<pca006132>
ironing?
<pca006132>
guso78k: will test later
<J23k72>
normally ironing will went around the black shapes and leave marks .. but as the image artifacts are visible i assume some detail just got lost in resolution
<kintel>
pca006132 Cool you saw the project. I didn't really populate it, just started a mostly empty structure. We can modify as we see fit
<kintel>
One missing piece is to find a way of scoping the blockers so we have a good sense of how far we need to take it.
<kintel>
I also dropped the "in progress" column, as everything ends up being in progress at some point
<kintel>
Another thing that we tend to lose track over: Just merging a PR doesn't necessarily make the feature "release ready". There may be documentation, tests and other things needed to finish it. sometimes we forget tracking that using issues
_whitelogger has joined #openscad
<kintel>
pca006132 Yeah, ideally we should update our changelog as we merge features, to make the archeology work easier :)
<pca006132>
I think #4867 is in good shape now and is pretty simple, kintel maybe you can have a look at it and see if we can merge it.
<pca006132>
the remaining stuff I want to fix quickly are tessellation and extrudePolygon, those will be more intricate and not as simple...
<pca006132>
and I'm thinking about using the triangulator in manifold (when it is available) directly for polysets that are manifold but not triangular, so we don't need to deduplicate the vertices before passing into CGAL's tessellator
<pca006132>
but seems hard to come up with test cases for this
<pca006132>
ah maybe another thing I can look into is 3MF import, let me mark that down before sleep
<kintel>
pca006132 Re #4866 - yes, I put the release calls there as a stop-gap measure. The smart pointer PR simply removes the release calls. I found it easier to do the refactoring first
<pca006132>
ignoring the shared_pointer thing, it is mostly just formatting and naming changes which looks fine
mmu_man has quit [Ping timeout: 256 seconds]
<kintel>
pca006132 Cool, I'll merge yours, then mine, then rebase the smart pointer PR. The smart pointer thing might become massive, so I'll look for a reasonable cutoff, or do it in multiple PRs
<pca006132>
nice
<kintel>
..but all of the memory stuff is pretty coupled, so the first PR might have to be big, unless I litter the code with too many release() calls...
<kintel>
pca006132 I'll let you sleep now - will merge your PR once it goes green
<pca006132>
I'm thinking if it would be better to try to merge #4841 before the big smart pointer PR
<pca006132>
I already fixed the python dependency stuff
<pca006132>
the smart pointer PR will probably create a large conflict with the python PR, and a lot of stuff have to be fixed
<kintel>
True, I'm not really plugged into the python work though. Does anyone want to make the call for when it's ready to merge?
<kintel>
..or if it's not ready, can we merge, but hide some of it behind a compile-time macro until we're confident?
<pca006132>
I think most of the code are already hidden behind an experimental option
<pca006132>
I am now trying to fix the compilation errors on CI
<pca006132>
I am probably too tired to try it for now
<pca006132>
see you tmr
pca006132 has quit [Remote host closed the connection]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
mmu_man has joined #openscad
<teepee>
kintel: it should be hidden behind both compile *and* runtime switch
<teepee>
I need to take care of more advent calender stuff so we are not running out of designs, but I hope I can have a look
<kintel>
teepee Yeah, that's what I was wondering. Until ready for experimental, make it a default-off compile-time switch. ..or make the activation of the feature a compile-time switch to allow us to build as much of the code as possible regularly
<teepee>
I did page through some time ago but I'm not sure about the state of the hash stuff, as we had trouble with cryptopp, trying to switch to nettle instead
<kintel>
humm, if it's too much work we may have to swallow some conflicts again. guso78 what do you think?
<teepee>
I would hope python and meadurement are not too bad
<teepee>
or is that about the smart pointer changes? I have not looked at those yet
<kintel>
If python branch takes too long, we'll need to merge smart pointers first, which may cause a bunch of conflicts for guso78
kintel has quit [Ping timeout: 256 seconds]
<guso78>
Kintel smart pointers can go First. I am Not worrier about smart pointer conflicts i think
Guest76 has joined #openscad
Guest76 has quit [Client Quit]
guso78k has joined #openscad
<guso78k>
kintel if you think its easier for practical reasons to merge the python_pr first, its also fine for me.
<guso78k>
the conflicts which i expect with smart pointers first can be solved with easy pattern replacing in the python code, i think ...
<Scopeuk>
I think kintel dropped before those messages, I believe kintel reads logs though
<JordanBrown>
I know they are little things, but I'd like some opinions on the $vpr-from-command-line PR #4863 and the bitwise operators PR #4833... for the latter, if only to give a thumbs-down.
<kintel>
JordanBrown Reviewed. Minor suggestions, but the largest one is missing tests
<J23k28>
kintel what do you think about lowering the default $fs and $fa values. This has been often discussed and everybody said this is good but it is never done - i know that the tests will fail as a circle() will look more round when this PR is made - but i think at least after or with manifold this should be done.
<kintel>
J23k28 Tempting, I wonder how many people rely on the exact geometry of default settings.
<J23k28>
I know that beginner are disappointed that it looks like the 80s retro low poly - and then (mostly) everybody learn to set lower values (or higher $fn)
<J23k28>
( and that hack to limit $fa to 72 is also quite strange from a mathematical point)
lastrodamo has quit [Quit: Leaving]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cart_ has quit [Ping timeout: 276 seconds]
teepee has quit [Ping timeout: 240 seconds]
teepee has joined #openscad
<JordanBrown>
kintel: thanks, will look in detail in a few hours.
<JordanBrown>
Lowering $fa and $fs sounds like a good idea. Yes, there might be some people who are accidentally or on purpose relying on the defaults, but that seems like a bad thing to do. And anything that we can do to discourage people from using $fn to control circles (vs regular polygons) is good.
<JordanBrown>
kintel: #4833 bitwise operators?
<JordanBrown>
Note that there's some design review and commentary in the connected issue #3345.
kintel has joined #openscad
kintel has quit [Client Quit]
<InPhase>
Oh please yes let us lower $fa and $fs. $fa=1; $fs=0.4;
<InPhase>
Computers are so much faster now.
<InPhase>
Make everything beautiful and print ready by default.
<InPhase>
Raising it should be a performance optimization for heavy models.
<InPhase>
I also object in advance to any middle ground that doesn't go that far. ;) Those are the settings for a standard FDM printer that makes up the bulk of the userbase's target.
<kintel>
I still wonder what it would take to establish a reference to a representative collection of external body of work, to be able to do occasional tests to find regressions whenever we make a wide-reaching change
<teepee>
I'd say we can declare a couple of more days of the calendar covered ;-) - https://imgur.com/a/YK0L6A6
<kintel>
Woot! nice motivational calendar btw
<teepee>
that motivation is needed, if we stretch the lamp over 6 days, it's still half way full at this point
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]