<kintel>
JordanBrown teepee: I did (admittedly somewhat aggressively) merge that formatting PR. Some notes in that regard:
<kintel>
The intent is that auto-formatting should be done locally, prior to pushing PRs. That way, conflicts should never really happen. Trying to hand-adjust formatting doesn't sound like a great workflow
<kintel>
We can change things. The current formatting was an initial suggestion. Changing setting now give us the opportunity to play around with and observe how such settings in isolation affects our codebase. That includes the 105 char line length. I believe that was just a starting point as well
<teepee>
for people who dont's know about that, we should make the action post that info on the issue if it fails
<teepee>
I have not check, but does the action also just validate the changed files?
<kintel>
yeah, good idea. Down the road we could even add some action to auto-format on PR, but it's tricky to get right.
<teepee>
yeah, fully automatic change is not something I'd like
<kintel>
A review bot could show this inline as a diff, but that's also more work to aset up
<teepee>
like posting a PR with the changes, like the depandabot does where you can review and click on merge
<teepee>
although I'm not sure that works from the technical perspective if the PR is not from an internal branch
<kintel>
It's doable; do can request a PR against the PR author's branch. But not sure if any bots out there can be configured accordingly : /
<teepee>
an initial comment with a note referencing the docs is probably more important as a start
<kintel>
yup.
<kintel>
Perhaps also document how to set up beautify or clang-format in common editors. Just checked VS Code and its clangd extension does this automatically
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
kintel has joined #openscad
<teepee>
default manifold \o/
kintel has quit [Client Quit]
<teepee>
hopefully a new version gets released too, so we can get back the Debian 11 builds
<teepee>
with Trixie released it's not super critical, but still nice to have
crazy_imp has quit [Server closed connection]
crazy_imp has joined #openscad
Guest19 has joined #openscad
Guest19 has quit [Client Quit]
VanBernaert has joined #openscad
<VanBernaert>
to start with .. openscad is awesome
<InPhase>
Good start.
<teepee>
:)
<teepee>
now lets hear the "but" :D
<VanBernaert>
no but, just here to see what's the small talk about this
<VanBernaert>
i still have the feeling 3D creators with openscad arent yet widepread
<teepee>
whatever people care about in the moment, usually loosely related to openscad
<InPhase>
Ah. :) Well, welcome. There's a lot here, but with gaps between discussions, so pull up an idle chair and wait with us. (While doing other things, or while staring desperately at the screen if that's your lifestyle choice.)
<teepee>
well, maybe not a huge amount, but considering there's a good number of books written over the last years, it's not just 100 or so (I believe)
<teepee>
you can always browse the logs, link is listed in the channel topic
<VanBernaert>
ha great, that's a nice hint
<teepee>
oh, wait, is that a goo.gl link
* teepee
tries if the links still work
<VanBernaert>
so far I made letter to hang on walls (led lights) with this app, to autonate letter creation base and cover
<teepee>
nice.
* teepee
loves LED stuff :)
<InPhase>
VanBernaert: It's by leaps and bounds the highest utilization programmatic solution to 3D model creation for 3D printing. I think there will always be a slightly larger segment choosing a gui-first approach, and not wanting to mentally invest in the gains of a programmatic approach. So it's not a reasonable goal to attempt to overtake it. The goal is to provide high utility to the people who resonate
<InPhase>
and are able to utilize the gains of programmatic design. And this is going very well so far. The second goal is to continue to explain the merits of programmatic design so that people poised to find these descriptions can benefit from the notion.
<VanBernaert>
i do GUI too, but I love it to create 3D that has more programmable logic than putting energy in GUI creating ... mostly for serialization and batch customised per print
<VanBernaert>
or combining GUI and openscad ... importing an object that needs a separate text/print
<buZz>
VanBernaert: its getting a lot of traction in the hackerspace scene
<buZz>
i mean, most ppl that are willing to teach others use openscad, the ones that use 'whatever clicky software' usually arent willing to help people get going ;)
mmu_man has quit [Ping timeout: 252 seconds]
<buZz>
'just find some yt tutorials that you like'
mmu_man has joined #openscad
kintel has joined #openscad
<buZz>
so, in theory, its just a matter of time until openscad will be the one and only, obviously ;)
<kintel>
teepee Yeah, I'm proposing to make it default now. The remaining issues still need sorting, but I think getting more users is more valuable right now
<teepee>
kintel: yep, I certainly agree. it's probably more stable than old cgal by now even with the remaining issues
<buZz>
i still like to voice adding ctrl-pgup/ctrl-pgdn for switching tabs ;) but i think shortcuts will become configurable soon anyway?
VanBernaert has quit [Quit: Client closed]
<teepee>
yes
<teepee>
for openscad style soon though
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<teepee>
kintel: going to steal your screenshot from the mailing list for posting on mastodon/bluesky
<VanBernaert>
openscad on bluesky?
<teepee>
well, for those people who don't go with mastodon :)
<teepee>
I refuse to post on the blue bird thing, the account is still there, but I'm not going to touch it any time soon.
<teepee>
sometime I might forget to also post on bluesky though
<teepee>
uh, 2 characters left :)
bozo16 has quit [Quit: Leaving]
mmu_man has quit [Ping timeout: 252 seconds]
snaked has joined #openscad
mmu_man has joined #openscad
bozo16 has joined #openscad
sculptor has joined #openscad
jbd has joined #openscad
kintel has joined #openscad
<kintel>
One new topic I'd like to discuss for next official release (I'm just throwing this out here, but I'm a bit offline this week-end, so we can async-discuss it for now if anyone has opinions):
<kintel>
If we can commit to not making big changes to the repo, we can continue to release patch-level updates to the next official release. We did that once in the past, and the main challenge was maintaining a separate branch.
<kintel>
If we can also pin down all the necessary language-level changes first, it could be feasible to fast-forward the actual release and work on bugfixes as a continuous process for the subsequent N months to properly stabilize the release
<teepee>
totally my suggestion :)
<kintel>
The long tail of geometry and GUI issues is hard to get sorted, and we need more users to surface real usability issues I feel
<J25K95>
if there is a RC the "new issue" menu could get an extra RC tag to track those.
<kintel>
I think if we define a "blackout" period of e.g. 6 months where we agree to be nice on the refactoring and large changes, and focus on bugs, I think it's a realistic way forward. ..modulo stuff that can be easily ifdef'ed out.
<kintel>
Yeah. RC first, that makes sense just to motivate people to help out :)
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
splud has quit [Quit: Leaving]
<teepee>
oh, ffs, oneTBB is using Bazel as build system?
<teepee>
is it *that* hot at intel hq?
<teepee>
wait, there's cmakelists.txt
VanBernaert has quit [Ping timeout: 250 seconds]
<InPhase>
kintel: I won't be shocked if there's a bit of bug discovery after this release in excess of prior ones. Although honestly I think the real goal should be a short release cycle. There were some big changes that happened here, but another way of looking at it is that there were so many big high value changes that our snapshot became our real release for a while. And that's indicative of a cycle
<InPhase>
that's longer than users benefit from. :)
<InPhase>
By the time the snapshot has become what everyone who knows about it is using, it hints that the benefits of our progress are of more value than a bit of a bug risk. With a short release cycle people can still opt to use an older version if something is a breaking change for them temporarily.
kintel has joined #openscad
<kintel>
teepee haha, first time I've heard of bazel usage outside of Google ;)
<InPhase>
Also before the 2021 release I put forward an argument that a shorter release cycle will pull in much more dev activity. We did in fact get absolutely swamped with dev activity. Probably in part by lingering Covid world effects, and in part by rapidly increasing 3D printing activity in general, but I still think the short releases help for this.
<InPhase>
Short and "imperfect is okay" can be a benefit. And this I think helps with the goal of keeping the delta smaller and making point releases more viable in between if there's a crisis bug.
<kintel>
InPhase: What tends to happen is also that we merge unfinished features which need time to sort out. If we were better at tagging new things as experimental, we could theoretically maintain a faster release cycle
<InPhase>
I concur with that principle. Do you have examples of ones where this was missed?
<kintel>
In the end, the only thing we really want is compatibility of created designs
<kintel>
No concrete examples; the repo just ends up in an unreleasable state : /
<InPhase>
kintel: Well... Except that so many people are using the snapshot that this might not be true...
<InPhase>
The users are voting. :)
<InPhase>
And I think they're saying that a good job was already done.
<InPhase>
We just want to avoid too much that, like you raised, creates a long term code compatibility issue. Once in a while there will be the hiccups with spacebar heating, so "zero" isn't the goal. But reasonably minimized.
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
kintel has joined #openscad
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<kintel>
teepee Yeah, let's consider the extension + be more strict about mixing sets of swizzle operators.
<kintel>
If someone wants to take this on, please raise your hand. I'm mostly trying to establish what are actual blockers for the new release proposal - a lot of that might end up being taking stuff the last 10% of the way
<teepee>
that might be small enough for me :)
<teepee>
the more important first step is to decide what to implement though
<teepee>
with leading numbers now deprecated, using 0/1 is pretty much out
<teepee>
I guess unicode trickery is also out
<kintel>
at least leading 0/1 - and special cases are annoying to manage
<teepee>
yeah, parser wise it's just a ID I think
<teepee>
even getting this into a special case is almost impossible as the parser does not have the context to decide this
<kintel>
technically, they don't have to be valid identifiers I think
<kintel>
..but it would require rewiring the parser a bit
<kintel>
..considering object keys are allowed to be any string IIUC
<teepee>
key can be anything, but if it's not an ID you have to use the o["string"] indexing