<gbruno>
[github] thehans edited issue #4039 (ERROR: The given mesh is not closed! Unable to convert to CGAL_Nef_Polyhedron associated with linear_extrude) https://github.com/openscad/openscad/issues/4039
<JordanBrown_>
So there is the main OpenSCAD git repo at openscad/openscad. I have my fork at jordanbrown0/openscad. I want to create a new local repo that has upstream pointing at the main repo, origin pointing at my repo, in a new branch, so that a subsequent push will push that new branch to my repo.
fling has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
pca006132 has quit [Remote host closed the connection]
pca006132 has joined #openscad
<JordanBrown_>
I have been trying all kinds of variations, and it either tells me that the origin repo doesn't have my new branch (duh), or that the origin branch doesn't have the same name as the local branch.
fling has joined #openscad
<teepee>
clone your repo
<teepee>
git add remote upstream <url>
<JordanBrown_>
Yeah, did that.
<JordanBrown_>
so far so good.
<teepee>
new pushes default to origin
<JordanBrown_>
it is when I want to create a branch and push that new branch to my repo that I get into trouble.
<JordanBrown_>
(actually, I cloned openscad/openscad, and then reset the upstream and origin remotes to point to openscad/openscad and jordanbrown0/openscad respectively.)
<JordanBrown_>
it's the branch stuff that is giving me trouble.
<teepee>
not sure if that leaves some extra defaults
<teepee>
check .git/config maybe?
<JordanBrown_>
I think I understand what I am missing.
<JordanBrown_>
I think git uses "upstream" to mean both the immediate parent (my repo) and the grandparent (main OpenSCAD).
<JordanBrown_>
and my immediate reaction is "I don't want to set upstream to that; upstream is openscad/openscad"
J23k has joined #openscad
fling has quit [Remote host closed the connection]
<JordanBrown_>
but I think it really means "set the parent to ...".
<peeps[zen]>
i didn't think upstream had any special meaning to git
<teepee>
set the "default push to"
snaked has quit [Ping timeout: 256 seconds]
<teepee>
yes, those 2 names upstream have no relation
<JordanBrown_>
I suspect that "upstream" as a remote name does not have any special meaning, that it is only convention that it refers to the repo that you forked from.
<teepee>
one is just a random name, you could name it "the-openscad-repo"
<teepee>
the other one is the repo+branch the local branch pushes to
<JordanBrown_>
Which is confusing because "upstream" also means "the repo that you push/pull from by default".
<teepee>
yes
fling has joined #openscad
<JordanBrown_>
Now I want to figure out whether I can set that parent branch *without* pushing, so that the next push will create it. I want to have my "osclone" script set all of this stuff up, but I don't want to pollute my repo with dead-end branches that I never actually want to push.
<JordanBrown_>
Maybe push.autoSetupRemote.
<teepee>
that will just do directly what the command says
drfff has joined #openscad
drkow has quit [Ping timeout: 276 seconds]
LordOfBikes has quit [Ping timeout: 256 seconds]
J23k has quit [Quit: Client closed]
J23k has joined #openscad
bozo16 has quit [Ping timeout: 255 seconds]
LordOfBikes has joined #openscad
<JordanBrown_>
Random and probably ignorant question: why do we use CGAL from the build system instead of pulling it in as a submodule?
<peeps[zen]>
because distros frown upon doing dependency management outside of their package manager
<JordanBrown_>
Hmm. Yeah, OK, sort of, but means that you need N build systems if you want to build N different versions of your package. CGAL seems special because if I understand correctly it is headers only; it doesn't use any libraries from the runtime system.
<peeps[zen]>
it wasn't header only until a couple years ago
<peeps[zen]>
iirc
<JordanBrown_>
And maybe that's really not important because you have dependencies on harfbuzz, freetype, et cetera. If you want to time travel and rebuild 2021.01 from sources, you have to time travel a whole lot of dependencies.
<JordanBrown_>
Including things that don't keep their sources on github, and things that require distro-specific tweaks on top of their primary sources, and the distro-specific stuff isn't on github.
<JordanBrown_>
In case anybody is interested, the osclone that I ended up with is at https://bpa.st/PS7Q
<JordanBrown_>
Typically clones a mainline bleeding-edge openscad into a new directory, hooks it up to my fork, and sets up a new branch.
<JordanBrown_>
(and I could set push.autoSetupRemote in my global config, but this makes it so I don't have to do that on each system.)
<JordanBrown_>
I knew you would be excited.
snaked has joined #openscad
greenbigfrog has quit [Ping timeout: 256 seconds]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
JordanBrown has joined #openscad
<JordanBrown>
That osclone seems to be OK for creating new branches, but not for cloning an existing branch from my fork. More thought required.
dalias has joined #openscad
greenbigfrog has joined #openscad
J23k93 has joined #openscad
J23k has quit [Ping timeout: 250 seconds]
<JordanBrown>
scary warning from build of bleeding edge (with freshly updated MSYS2):
<JordanBrown>
warning: 'void
<JordanBrown>
__builtin_memmove(void*, const void*, long long unsigned int)' writing between 9 and 9223372036854775807 bytes into a region of size 8 overflows the destination [-Wstringop-overflow=]
<JordanBrown>
Full, and extremely long, error message at https://bpa.st/JDAQ
<JordanBrown>
kintel some of the symbols mentioned in that error look like they might be related to the geometry fixup stuff you guys
<JordanBrown>
have been working on.
dalias has quit [Ping timeout: 256 seconds]
mmu_man has quit [Ping timeout: 255 seconds]
pca006132 has quit [Remote host closed the connection]
pca006132 has joined #openscad
<pca006132>
iirc we encountered similar warnings with manifold previously
<pca006132>
and we have no idea where the warning is from
<pca006132>
we only suppressed the warning by some assertion to tell GCC that the range is fine
<pca006132>
it seems to me that the warnings is due to some internals of repair_polygon_soup, which is probably an issue with CGAL...
<pca006132>
re. build system: if you want to time travel, you probably want a reproducible build system, e.g. nix
<pca006132>
system-wide installation is not a great way to do reproducible build...
<InPhase>
JordanBrown: gcc has one through some bugs on that -Wstringop-overflow to such an extent that I turned it off for several things.
<InPhase>
JordanBrown: So, it might be a real problem, but I've meticulously validated some things as correct where that warning is blaring ridiculous things like that.
<InPhase>
Although I do not recall seeing it trigger yet for OpenSCAD.
<JordanBrown>
I don't have any experience with gcc's warning for that.
<JordanBrown>
Our internal tool (Parfait) has similar warnings, and indeed
<JordanBrown>
sometimes it's just wrong.
<InPhase>
That was supposed to read "gcc has gone through"
<pca006132_>
just curious: are there real-world models that can preview significantly faster than render with manifold enabled? because iirc the slowest thing now are minkowski and complex script evaluation, but both are not faster with preview
<guso78k>
please let me know how I can contribute with the cleanup of the PolySet. I can address some of the issues but not all of them. is it viable that many people work on the SAME PR ?
<pca006132_>
it is hard to coordinate
<pca006132_>
the typical approach would be to split the task into many subtasks that are separated
<pca006132_>
so you will not get tons of conflicts
pca006132_ has quit [Quit: Client closed]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kintel has joined #openscad
pca006132 has quit [Remote host closed the connection]
pca006132 has joined #openscad
<kintel>
guso78 Same PR is hard, same issue is easier, just communicate what you intend to do
<kintel>
One way of working on a PR is to let someone own the PR and open pull requests against it
<kintel>
..and perhaps ask that they don't rebase/force push while collaborating
dalias has joined #openscad
<kintel>
Btw., I will try to get my smart pointer PR going next as it will help a lot. Sorry in advance for all the breakages it may cause :)
<guso78k>
yeah PR against a local branch is a good idea! maybe openscad repo can make a polyset_cleanup branch ?
<kintel>
Instead of a bit branch, we can probably clean up PolySet through a series of small PRs
<kintel>
*big
<guso78k>
kintel I am sorry about the conflicts which draft PR's will receive ... my PR's also endangered, but I can best cope with it because i know whats changed :')
<guso78k>
But yes, I appreciate more smart pointers. now, without knowing the exact data flow in openscad you never have to worry anymore, if your "own" an allocated memory or not :)
bozo16 has joined #openscad
dalias has quit [Ping timeout: 260 seconds]
mmu_man has quit [Ping timeout: 268 seconds]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mmu_man has joined #openscad
J23k93 has quit [Quit: Client closed]
J23k93 has joined #openscad
fling has quit [Remote host closed the connection]
<pca006132>
I am thinking if we should open an issue similar to #3640 and pin it, to track the list of issues we are most concerned about now that will probably make into the next release
<pca006132>
and maybe attract some contribution to these big issues
pca006132 has quit [Remote host closed the connection]