03:30 <Lagopus> is there a way to multiply cell values in arrays with identical dimensions, eg [2,3].*[5,7] = [10,21]

03:38 <InPhase> Lagopus: 2014 rejected this as a feature in favor of deferring to function support. A working version is in this bottom post: https://github.com/openscad/openscad/issues/821#issuecomment-647706082

03:43 <InPhase> Lagopus: Oh well look at that. I found another version in my files from some time ago: https://bpa.st/PL75W

03:43 <InPhase> Fairly similar in structure. Nuanced differences in the handling of bogus input.

03:54 <peepsalot> https://en.wikipedia.org/wiki/Hadamard_product_(matrices)

04:39 <Lagopus> Hadamard. Thank you. I could not tell you why I have never heard the term before. Thanks for the implementations and wiki. I now feel like there was a large part of linalg that I slept through.

08:47 <gbruno> [github] gsohler synchronize pull request #4465 (New function evalstring) https://github.com/openscad/openscad/pull/4465

09:08 <J2387> i also did that vector multiplication https://bpa.st/H5ZTY    i find it funny that so many libraries have the same tools but often solved differently

09:16 <J2387> i have now  added InPhase s superior recursion methode

16:03 <tcurdt> sweeping/extruding a 2d shape along a path ... there no way of doing that yet, is there?

16:14 <Scopeuk> tcurdt I don't believe so

16:14 <Scopeuk> unless that path happens to be a sub section of a circle

16:27 <tcurdt> it's a shame there is no way to turn a 2d shape into vector of points

16:29 <teepee> there is in the recent PR, if that's going to be the final version is still open but it's there for review

16:42 <tcurdt> hm .. can't find which you mean ... but as it's not applied yet it does not help anyway for now :)

16:49 <teepee> it's not going to be for a while, only more feedback has some chance of speeding things up

16:50 <teepee> https://github.com/openscad/openscad/pull/4478

16:52 <InPhase> tcurdt: This is my solution to the problem-space. https://github.com/rcolyer/closepoints

16:52 <InPhase> tcurdt: Which I created because there is no good way to do it for a 2D geometry that is already in geometry form.

16:53 <InPhase> Although the solutions extracting points from existing geometries will certainly bridge the gaps between libraries like that and existing geometries.

16:55 <InPhase> tcurdt: I'm comfortable with it staying as external libraries until we figure out how to handle all the edge cases. Once it's integrated, it should be an "always manifold result" operation. The library however is manifold in its result if and only if you satisfy the criteria for the points specified in the instructions.

16:57 <tcurdt> interesting progress

16:57 <InPhase> I wrote the library in part to solve the problem for my own designs, and in part to help us think about and experiment with those cases that don't go well, and to get some hands-on experience with the scenarios where they might fail. Although in practice I find the constraints pretty easy to meet for most shapes I want to make.

16:57 <gbruno> [github] t-paul edited pull request #4478 (Objects, geometry as data, module references) https://github.com/openscad/openscad/pull/4478

17:01 <InPhase> tcurdt: That demo_3D_art.scad is one where the constraints were hard to meet. I failed to achieve a proper manifold design many times with early iterations of that, with parts inside out. It required care to get them all right-side out.

17:04 <InPhase> The simplicity of the resulting scad file kind of obscures that there was a learning curve to getting it right. :)

17:06 <tcurdt> naaa ... often it's the final seal of sophistication :)

17:53 <J2387> tcurdt if it is convex you can do a chained hull

19:49 <gbruno> [github] thehans synchronize pull request #4384 (Decimal round trip fixes) https://github.com/openscad/openscad/pull/4384

19:53 <peepsalot> agh, all the ubuntu repos exploded or something

19:58 <teepee> meh, again?

19:59 <teepee> whops, azure down?

20:00 <teepee> nope, infrastructure claims all green

20:00 <teepee> and I can access the server, so maybe they had some fail-over we just managed to hit

20:00 <teepee> I've retriggered the builds

20:01 <peepsalot> hmm, guess i'm just unlucky

20:06 <teepee> good thing azure is working, I really would not want to get any phone calls :)

20:06 <teepee> running stuff in the cloud has it's annoying sides

20:15 <InPhase> peepsalot: The Software Center has a "select a mirror" tab in its settings, which you can use to shift around your primary source, when the main one goes down.

20:15 <InPhase> peepsalot: It also has a feature for you to test for the one that will give you the fastest downloads and pick that one.

20:15 <teepee> it was the github builds failing

20:16 <peepsalot> i meant on the CI

20:16 <InPhase> Oh, well, then you're just unlucky.

21:48 <peepsalot> i'm still looking into using libfmt aka {fmt}, to replace double-conversion. if I implement this is there any chance it would be ok to do as a submodule? or is that still frowned on by debian pkging

21:49 <peepsalot> it looks like 18.04 has the library, but at version 4.0, while latest is 9.1. i'm not sure what API differences there would be between the two but seems like a large jump

21:50 <peepsalot> also i feel like submodule would simplify MXE build. otherwise we'd need to create our own package on that i think?

22:04 <teepee> yes, very much frowned upon as far as I know, and basically by all distros that are not rolling/soure-build

22:04 <teepee> however, I think if we can make it so that cmake can be told to use an installed version that is probably all good

22:14 <peepsalot> teepee: and support range from 4.0.0 to 9.1? or you mean something like package it separately on OBS like you do with cgal?

22:17 <peepsalot> oh, are you saying do it as submodule as long as it's optional vs using cmake's find_package() ?

22:20 <peepsalot> https://fmt.dev/latest/usage.html#usage-with-cmake their docs show both ways basically, so that should be pretty simple to add a config option between them

22:59 <teepee> peepsalot: yes, OBS can clone recursively and our other builds we can totally do what we want

23:00 <teepee> so giving a way of disabling the included libfmt would be a nice nod to the maintainers, otherwise they might be required to rip it out via patches

23:09 <teepee> as for version support, I'd say ideally what last debian and/or ubuntu release has

23:09 <teepee> but if that's annoying, that's not a huge deal either, then we just go with latest via submodule

23:10 <teepee> the old distro support is mostly for AppImage and OBS so we can provide nightlies for the older distros

23:10 <teepee> actual distro packaging is essentially never happening as backport

23:10 <teepee> well, at least not that I''m aware of :)