<pca006132>
btw, are you guys aware of any IRC client that can integrate with the log? it is a bit annoying that I have to check the log website to read the history...
<pca006132>
or is it allowed to parse the log in the logger?
<JordanBrown>
pca006132, peeps[zen]: When the Matrix bridge was working, it maintained state - you could start your Matrix client from anywhere and see all history.
<JordanBrown>
I don't know how attached people are to IRC as a protocol and set of clients, but based on what little I know I'd be entirely in favor of moving over to a native Matrix room.
drkow has joined #openscad
kow__ has quit [Ping timeout: 256 seconds]
JordanBrown1 has joined #openscad
JordanBrown2 has joined #openscad
JordanBrown1 has quit [Ping timeout: 268 seconds]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pca006132 has joined #openscad
<pca006132>
I am open to switching to matrix/discord. I only come to irc because I found that most dev discussions are here...
<guso78k>
it would be nice to understand now, it openscad is out of memory or if the tool rather wanted to allocate 10 TB of memory
h-erectus has joined #openscad
erectus has quit [Ping timeout: 240 seconds]
cart_ has joined #openscad
misterfish has quit [Ping timeout: 255 seconds]
h-erectus has quit [Ping timeout: 240 seconds]
erectus has joined #openscad
misterfish has joined #openscad
drkow has joined #openscad
guso78k has quit [Quit: Client closed]
kow__ has quit [Ping timeout: 268 seconds]
kow__ has joined #openscad
cart_ has quit [Quit: Konversation terminated!]
drkow has quit [Ping timeout: 268 seconds]
pca006132 has joined #openscad
J23k17 has quit [Quit: Client closed]
J23k17 has joined #openscad
<pca006132>
J23k17: if you get OOM after some time and the code you use is not especially memory hungry, openscad may be leaking memory...
<pca006132>
no idea how openscad manages memory, but this kind of stuff happens pretty frequently especially when it is not using smart pointers
erectus has quit [Remote host closed the connection]
<J23k17>
i can only assume this was while a recursion wasn't terminated else this render in 0.5sec with just 200MB memory ..
erectus has joined #openscad
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
L29Ah has joined #openscad
guso78k has joined #openscad
<guso78k>
pcsa0000 recently meanioned that render needs 1KB for each vertex ...
<pca006132>
no, that is a bug with mesa on windows
<guso78k>
pca, thanks for clarifying :)
<guso78k>
still the memory is inadvertenly taken ...
mmu_man has joined #openscad
<guso78k>
finally my bleeding-edge python branch is on sync again with indexed_PR. this was big effort '=D '=D
J23k17 has quit [Quit: Client closed]
J23k17 has joined #openscad
<pca006132>
I think we should look into how to merge that...
<pca006132>
as there are a lot more refactoring work ahead
<pca006132>
ideally we should also use github project to coordinate our effort
<pca006132>
need organization owner to make a public project though, I don't have the permission to do that
bozo16 has joined #openscad
<guso78k>
pca006132, this pr3 is just pure python integration and none of the extra functions but suppose this is what we want at 1st. last week i have fixed a weakness in the integration, which actually allows to use things like build123d(interpreter is not restarted between the runs but is kept alive for the program run time)
snaked has quit [Quit: Leaving]
<teepee>
soo, what's the view on advent-calendar-2023?
<teepee>
shall we give it a try?
zauberfisch has quit [Quit: No Ping reply in 180 seconds.]
zauberfisch has joined #openscad
<J23k17>
what is the worst .. that we finish with 10 doors? .. we could have doors every second day
<teepee>
true, nothing that will end the world :)
<teepee>
it just would look sad
<J23k17>
having none would be sad too .. we really need to start a contest in November for that
<teepee>
yeah, and hopefully we don't have another businiess chaos next year, very annoying stuff taking too much time filling out forms for the gov
<teepee>
oh, I love the stringy one. I think we start with that :)
<teepee>
question for my lamp thing is - how many days to use
<teepee>
I guess minimum is 3
auctus has quit [Ping timeout: 255 seconds]
auctus has joined #openscad
<teepee>
updated my filenames to match
<J23k17>
we could make every panel a day .. i started with "snowflakes" for one side
<J23k17>
upd readme to match
<teepee>
nice idea, but maybe lets use those separate :)
<teepee>
meanwhile I've collect almost 3 different set of SVGs from openclipart so people could decide on a theme (or just do all 3)
<guso78k>
J23 great thing, have not seen this before
<J23k17>
iirc i got to level 60 something
<JordanBrown>
J23k17 I have been getting that std::bad_alloc popup recently from 2021.01... when it is sitting completely idle.
<JordanBrown>
It is a perfect example of why I think catching unexpected exceptions is bad.
pca006132 has joined #openscad
<guso78k>
hmm, intersting. are tthere any background processes running when openscad is idle ?(apart from redrawing mouse pointer in new position) ?
<pca006132>
also wonder if this may be platform specific
<JordanBrown>
I am not aware of any background processing when idle, but I have far from complete knowledge.
<pca006132>
e.g. some OpenGL resources not being freed properly
<JordanBrown>
Given that I'm seeing it on 2021.01, and only recently, I suspect that it is platform specific, that something has changed in Windows that is triggering it.
<pca006132>
teepee: btw any chance we can update https://github.com/openscad/openscad/projects/8 and put it in the readme? to coordinate the efforts and let people know what the devs are working on right now
<pca006132>
e.g. PolySet, manifoldness, vbo rendering, python pr
<pca006132>
I saw people complaining about not knowing about the development progress etc.
<JordanBrown>
I think that complainer has an ... incorrect ... level of understanding of the coordination and planning being done.
<pca006132>
true but it does feel better if we have some sort of a roadmap or something
<pca006132>
considering there are so many (long standing) issues...
<JordanBrown>
Roadmaps only work if you have people who are assigned to work them.
<JordanBrown>
They don't work so well when people work on what interests them at the moment.
<pca006132>
at least for the issues I mentioned I think there are active work right now
<JordanBrown>
Sure. But for, say, the PolySet stuff, could anybody have forecast two months ago that that work was going to be done?
<pca006132>
true
<guso78k>
suppose that everybody here has his intent what shall be established with openscad
<JordanBrown>
I do think that we need a governance mechanism, a way to poll a ruling cabal and answer questions like "is this design ready to be merged?", "are we ready to cut a release?", "do we want something like this proposal at all?". Right now a lot of that effectively falls on teepee, and that's putting a
<JordanBrown>
lot on him.
<pca006132>
I think the goal of a roadmap is for us to agree upon the important stuff...
<guso78k>
jordan you have your #4478
<pca006132>
e.g. the PolySet thing was ignored for several months, until I mention that it is very important for the purpose of manifoldness and guso78k rebased his pr
<JordanBrown>
I do have #4478. And we don't have a formal way, other than one of the people with merge authority making a decision and pushing a button, to decide that the design is acceptable.
<pca006132>
I feel that #4478 and #4841 are similar, need to triage what requires attention etc.
<pca006132>
> Right now a lot of that effectively falls on teepee, and that's putting a lot on him.
<pca006132>
agreed
teepee_ has joined #openscad
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
<guso78k>
pca006132 yes, correct they are comparable whereas @4478 is the moderate way and @4881 the progressive one - more risk->more fun
<JordanBrown>
Did you mean 4841?
<pca006132>
(was trying to find 4881)
<JordanBrown>
Given that the most recent issue/pull was 4866, 15 hours ago...
<pca006132>
will attempt to spam PRs this weekend for the polyset stuff
<JordanBrown>
I would say that 4478 and the Python work are only dimly related. Unless we assert that we're retiring the OpenSCAD language and everybody should move over to Python, the fact that Python has a particular feature isn't a reason not to implement it in the OpenSCAD language.
<JordanBrown>
I would be delighted to move to a general-purpose programming language, but I think that the sandbox problem is a killer, and that what I call the "boilerplate" problem is tough.
<guso78k>
one of the "advantages"of python is that pip repository is way bigger than the openscad library size
<pca006132>
I actually think the python pr is the least aggressive one, essentially you are adding something orthogonal to existing stuff, so from my point of view it can be merged as soon as some comprehensive tests show that existing behavior is not affected and the contributor will be around to fix things in the near future...
<guso78k>
pca006132 once the polyset issue has settled, i believe that the measurement pr is a really low hanging fruit with much benefit.
<pca006132>
I think sandbox problem is a solvable one (not for python though), the boilerplate problem is not (at least if you need the implicit top-level union)
<JordanBrown>
(The "boilerplate" problem is that the minimum-complexity program in OpenSCAD is "cube();" and all other proposed language bindings are at least a bit more verbose / complex.)
<guso78k>
pca006132 you are wrong: i was able to cerate an easy adaption of python. with that, shortest code is code()
<guso78k>
cube()
<guso78k>
even shorter than cube();
<pca006132>
what if you need two cubes
<guso78k>
cube(), then cube().translate([1,1,1])
<pca006132>
but does it perform the implicit union in python?
<guso78k>
the modified python picks up all openscad expression which are calculated and stay orphan
<pca006132>
or do you need to do `cube() + cube().translate([1, 1, 1])`?
<JordanBrown>
I will have to look at how you did that; I have not been able to reconcile the desire to have cube() add a cube to the model but have x=cube() put a cube into a variable.
<pca006132>
interesting
<guso78k>
implicit union is done in my pyopenscad.cc ... ..
<pca006132>
are you doing something cursed like inspecting the callstack? :P
<JordanBrown>
But if you modified core python to catch top-level orphans and apply implicit unions at function calls...
<guso78k>
pca006132 yes, i had to add another python "token" for its stack operations, but it was an easy one
<pca006132>
interesting, not much experience with non-trivial python stuff
<guso78k>
yeahh, it will never establish, because python dev team will neever merge my addition :')
<guso78k>
found the solution in half a day ....
<JordanBrown>
I looked briefly at modifying core Python, but that doesn't seem very supportable.
<pca006132>
anyway, back to the main topic, I propose the following regarding governance
<pca006132>
1. Have a main roadmap that list the stuff that should make into the next release.
<pca006132>
2. Make it clear what is needed to merge a PR. E.g. bug fix requires a unit test update and zero test failure, test the interaction of new feature with old features (e.g. python calling openscad code) and show that existing behavior will not change if the new feature is not used.
<pca006132>
I think having a smaller list of important stuff to pick and improving the merge process will encourage people contributing...
<JordanBrown>
The hardest problem with new features is not testing. The hardest problem is future-proofing. If we do <whatever> today, will we regret it tomorrow? Will it conflict with future improvements? Will it be difficult to support? Is it the simplest possible design, so that we won't want to make
<pca006132>
I feel that if you guard the things behind experimental flags, and make sure that it will not break the current stuff, it should be fine to have frequent changes to them
<pca006132>
which is why certain things are experimental...
<JordanBrown>
Indeed, experimental flags are good, though you still need to have a way to decide to un-experimental-ize things.
<JordanBrown>
changes tomorrow to make it simpler?
<pca006132>
yeah, un-experimental-ize things is still an issue
<pca006132>
will need some rough procedure for that, I don't have much thoughts about it
<JordanBrown>
For instance, the first version of my textmetrics stuff returned the information in structured arrays - the first element was the ascent, the second the descent, et cetera. It worked and was compatible. But it was ugly, and the long-proposed object mechanism would make it a lot less ugly, so I
<JordanBrown>
implemented what I perceived to be (and apparently no
<JordanBrown>
body disagreed) the internals that would allow enough of the object stuff to work.
<pca006132>
and I think the main point is to merge those features upstream even when they are not perfect, so contributors won't have to chase the upstream changes
<JordanBrown>
You've got to be really careful about merging things that aren't as perfect as you can get them, because people (rightfully) get bent out of shape when things change incompatibly.
<JordanBrown>
Anyhow, time for me to pretend to do real work.
<pca006132>
the way I see this is that, the implementation/UI can be imperfect, but base language changes should be really careful
<pca006132>
anyway, I just wanted to bring attention to this development procedure/governance issue, so development can go smoother
noonien85 has quit [Quit: Ping timeout (120 seconds)]
noonien85 has joined #openscad
pca006132 has quit [Quit: Client closed]
<guso78k>
pca006132 even if you do not have any additional rights ... i appreciate your effort to coordinate things
mmu_man has quit [Ping timeout: 252 seconds]
Guest5 has joined #openscad
Guest5 has quit [Client Quit]
guso78k has quit [Ping timeout: 250 seconds]
cart_ has joined #openscad
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
mmu_man has joined #openscad
LordOfBikes has quit [Remote host closed the connection]
<JordanBrown>
Yes, agree, it is the language that requires care.
<JordanBrown>
pca006132^
<JordanBrown>
Which does not include, for instance, the *concept* of Python integration... but does include exactly how it works, what the functions and methods look like.
LordOfBikes has joined #openscad
guso78k has joined #openscad
<JordanBrown>
(Driving by every once in a while between doing real work...) Going back to governance for a moment, how should we decide that the object and geometry stuff in #4478 is a good enough design to merge? Does one person have to make that decision? Is there a vote? By whom? Similarly, #4833
<JordanBrown>
introduces a small incompatibility - currently, 0x7f is a
<JordanBrown>
valid variable/function/module name, and #4833 parses it as a hex constant. Is that incompatibility acceptable? How would we decide?
<JordanBrown>
(BTW, I am *not* bidding to be on the steering committee myself, though I'd serve if asked. I just want there to be a process by which a decision can be made, without putting it all on one person.)
mmu_man has quit [Ping timeout: 252 seconds]
mmu_man has joined #openscad
<peeps[zen]>
<J23k17> teepee maybe snowman and snowflake cliparts - generated snowflakes could also make another day
<peeps[zen]>
this is why i ran out of ideas 4 yrs ago
guso78k has quit [Quit: Client closed]
L29Ah has quit [Ping timeout: 268 seconds]
mmu_man has quit [Ping timeout: 256 seconds]
mmu_man has joined #openscad
<JordanBrown>
The basic scheme that I used for Santa last year - take line art and 2.5D it - can more or less easily be applied to any line art. One such piece is probably appropriate, but more than one would repetitive.
<JordanBrown>
I have an animated model railroad that I was hoping to include this year, but it relies on #4478 object mechanisms, and relying on not-yet-merged features doesn't seem acceptable.
<J23k17>
oh i already used circles to make this .. no we never can use circles anymore. Even if you do the same but with a different approach it is absolutely worth it. So yeah layered svg was shown - so maybe make a flat multicolor print from an SVG by adding the cut outs with offsets and outlines as these are normally not present in svg logos.
guso78k has joined #openscad
mmu_man has quit [Ping timeout: 256 seconds]
<JordanBrown>
I don't have any qualms about using the exact same techniques I used for Santa last year, but with different line art this year. I just wouldn't want to have two such pieces in one year.
<JordanBrown>
Sorry, I wasn't clear that one such piece *this year* is probably appropriate, but two would be repetitive.
cart_ has quit [Ping timeout: 264 seconds]
<J23k17>
especially for experimental stuff one (per year) and feature is fine.
guso78k54 has joined #openscad
mmu_man has joined #openscad
guso78k54 has quit [Quit: Client closed]
guso78k has quit [Quit: Client closed]
guso78k has joined #openscad
J23k17 has quit [Quit: Client closed]
J23k17 has joined #openscad
Guest61 has joined #openscad
<Guest61>
Hello
<guso78k>
Hi Guest61
<Guest61>
Any experts around ? I'm trying to figure out why subtracting two trees is not giving the result I'm expecting
<guso78k>
can you share your code ?
<Guest61>
If I display the two trees independently, everything looks fine. But then I subtract one from another and there is stuff missing (not subtracted)
<Guest61>
sure... it's a bit complex but I'll do my best to explain the issue
<guso78k>
Does it display correct with F6 (Render) ?
<Guest61>
no
<guso78k>
can you past your code with www.bpa.st ?
<Guest61>
and looking under the part being subtracted I can see the rotor I wanted subtracted: https://imgbb.com/
<Guest61>
however for whatever reason I dont understand, the final part (after subtraction) doesnt have the rotor hole??§§
<guso78k>
can you try to simplify your model to contain only few lines while the problem still is present ?
<Guest61>
what do you think is the issue? any clues what I should be looking after ? cause correct me if I'm wrong, the part I'm subtracing from is all enclosed in a union(), so there is no reason for openscad to be ignoring stuff, right ?
<Guest61>
or does things like coplanarity still mater ?
<kintel>
pca006132 Looks like GitHub changed projects quite a bit. I'll create a new one, then we can populate it
<kintel>
Even if we don't advertise the project, it can be a good internal tool to help decide and discuss what is a blocker vs. other priorities for the next release.
<Guest61>
guso78k my god, found the issue. line 359 and 360 have the add/remove units swapped. it was supposed to be purposely creating overlap between parts but it was doing the contrary. therefore when subtracting it, the gap was occluding the hole
<Guest61>
thanks for the help in any case, reminding me to comment stuff to make it simpler was a good tip
SamantazFox has quit [Quit: Bye]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
SamantazFox has joined #openscad
<guso78k>
such errors are difficult to find. glad that you made it.
bozo16 has joined #openscad
guso78k49 has joined #openscad
snaked has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
L29Ah has joined #openscad
guso78k has quit [Ping timeout: 250 seconds]
pca006132 has joined #openscad
<pca006132>
kintel: yeah, that is the idea
<pca006132>
btw what do you think about a better documented process for deciding when to merge PRs?
<pca006132>
and the project is currently private, you need to set it to public so others not in the organization can see it