01:38 <JordanBrown> teepee it's even worse than just the libraries, because every single contributor has GPL-licensed their contribution.

02:05 <gbruno> [github] kintel pushed 8 modifications (Hooked up new dialog, still needs some cleanup) https://github.com/openscad/openscad/commit/8548ef978cad785e32fac97b7b72adc44b3f7cb6

02:05 <gbruno> [github] kintel edited pull request #5357 (Add support for multiple 3D print services) https://github.com/openscad/openscad/pull/5357

02:05 <gbruno> [github] kintel synchronize pull request #5357 (Add support for multiple 3D print services) https://github.com/openscad/openscad/pull/5357

02:23 <pca006133> kintel wonder if we can crowd source it by sending a msg to the mailing list, asking for projects

02:23 <pca006133> it should be easier than pulling every

02:23 <pca006133> thing on thingiverse and other services

02:29 <kintel> pca006133 yeah, crowdsourcing works, but still significant effort to track it all, keep the files updated when needed, tracking broken links. But one has to start somewhere : /

02:30 <kintel> ..or start a .scad file sharing service and wait for the uploads :)

02:39 <kintel> Does anyone know if the list of supported Octoprint file formats is still accurate? https://github.com/openscad/openscad/blob/ef6c55e069901244b92c788e391dd2a29930b065/src/gui/Settings.cc#L126

02:39 <kintel> (STL, OFF, AMF, 3MF)

02:40 <teepee> that was with the old cura plugin, not sure what the current state is, there is no default slicer plugin anymore AFAIK

02:41 <kintel> ok, so they just accept whatever the active slicer toolchain can ingest?

02:41 <kintel> I guess that's hard to signal back to OpenSCAD

02:41 <gbruno> [github] kintel pushed 5 modifications (Populate supported file formats in print-service.json) https://github.com/openscad/openscad/commit/f5b931f68c89b82200addb64a07f0c91012d5ffb

02:41 <gbruno> [github] kintel synchronize pull request #5357 (Add support for multiple 3D print services) https://github.com/openscad/openscad/pull/5357

02:42 <teepee> the other selections are available via api, I don't think that list was included

02:49 <kintel> Thx, I check the rest api, not file format query available from the slicer api

04:33 <pca006133> kintel: so should we just send an email to ask for submissions first? I guess the submitted designs will be easier to compile, e.g. no need to guess what libraries they are using, hopefully...

06:24 <InPhase> pca006132: How many projects do you think is a good target number?

06:25 <InPhase> pca006132: I figure it wouldn't take too many really as long as you are careful to accumulate very different types of projects. Like you don't want multiples from one person, unless that person used very different approaches in them.

06:27 <InPhase> By not too many I mean a 3 digit number of projects could conceivably represent the entire field's usages pretty well, as long as they are sampled in some really diverse manner.

06:30 <pca006132> I don't really have some target number in mind, if we can get some 3-digit number of projects running without issues it will be great

06:31 <pca006132> but I am expecting someone using some pretty extreme floating point values, which will trigger issues even when manifold uses double precision now :)

06:45 <InPhase> Some of my designs have had some crazy small features by virtue of using functions to define things.

06:46 <InPhase> I hit a lot of issues with CGAL paths by that. Although I often would then tweak the functions to get rid of the smallest stuff, since I had so many issues.

06:47 <InPhase> So most of my surviving finalized designs have had those extremes hammered out of them by failure. ;)

06:49 <InPhase> This is also why I was convinced CGAL's rational number engine was never doing us any good. I couldn't reliably make successful designs with that dynamic range anyway with CGAL.

06:51 <InPhase> pca006132: If you can come up with some descriptions of the sorts of mathematical scenarios you are worried might break or risk being fragile, I can be pretty good at doing pathological things, and could help with some stress tests.

06:52 <InPhase> This is a different aim than representing the field of designs, of course.

10:13 <Scopeuk> I guess in concept it's the distinction between a validation test set and user acceptance or pass off tests. Both have merit and value but there is a lot of cross over

10:14 <Scopeuk> The current test set leans more to validation, one feature per test etc which makes tracing easier but perhaps doesn't capture the kitchen sink feature combos some users acceptance test put through

10:55 <pca006132> InPhase: when the magnitude differs by too much (e.g. more than 1e10 times), models having slight self-intersection which passes the epsilon-valid requirement but are then projected into 2D (may break clipper)

10:56 <pca006132> the thing here is that we know it will be bad, just not sure how bad, e.g. if it will crash or something

14:29 <InPhase> pca006132: That epsilon for epsilon valid. It's an absolute or a relative value?

15:46 <InPhase> pca006132: A fun little stress test: https://bpa.st/7CFH6

15:47 <InPhase> pca006132: Two manifold failure types are induced by the one scale parameter. Honestly I'd file that under "could be worse".

15:48 <InPhase> pca006132: What I expected, but could not induce, was horrendous deformation like preview shows in the marked spot. Manifold either works, removes a feature, or displaces the object. But I couldn't sort out a way to make mutant shapes, nor trigger and runtime error problems.

15:48 <InPhase> s/and runtime/any runtime/

15:55 <InPhase> Maybe something like that should go into tests to monitor for the edge of the edge effects moving around. The test wouldn't have to be RIGHT at the edge like I have it, but just to monitor for scale shifts in handling edge cases.

15:58 <InPhase> The point of those stretched spheres was simply to induce deformations in mishandling the irrational numbers like happens to preview. And maybe that is worth monitoring for. But manifold seems to have been written cleverly enough to not have the issue.

20:14 <gbruno> [github] jordanbrown0 opened issue #5386 (Always start a new scope with {}) https://github.com/openscad/openscad/issues/5386