00:58 <kintel> teepee Which platform did it fail on?

00:58 <teepee> linux

00:59 <teepee> -- The C compiler identification is Clang 16.0.6

01:00 <kintel> thx, I should have tested more against the glew path..

01:00 <kintel> Hopefully it will be in the past soon :)

01:02 <teepee> with the wide range of compilers and systems, it's probably impossible to always cover everything

01:02 <teepee> I also have to do a deeper dive on OBS, it's quite red currently

01:03 <teepee> I mainly was wondering if there's maybe a better way than just casting

01:04 <teepee> but then, for screen width/height it would be pretty surprising to have a bad effect :)

01:04 <gbruno> [github] kintel pushed 1 modifications (EGL fix: static_cast when needed) https://github.com/openscad/openscad/commit/ad047b3cb1563090b18ec021ae3d078609789721

01:04 <gbruno> [github] kintel opened pull request #4765 (EGL fix: static_cast when needed) https://github.com/openscad/openscad/pull/4765

01:05 <kintel> I'm casting in the new EGL component too, so this just keeps things consistent

01:05 <kintel> In OpenGL code there is so much casting going on anyway..

01:07 <kintel> I was thinking we could just set up the N most common (or uncommon) distros and round-robin build one of them every day, using uni-get-dependencies

01:09 <kintel> In terms of GLAD, yes, we default to using whatever OpenCSG uses, but we can force OpenSCAD to always use GLAD with -DUSE_GLAD=ON

01:10 <teepee> for the local build I forced opencsg-1.6.0 and EGL works nicely in a ssh session

01:10 <kintel> I expect us to be able to default to GLAD soon, but I'd like to see the new OpenCSG spread a bit first in case something breaks

01:11 <kintel> Yeah, -DUSE_BUILTIN_OPENCSG=1 is a good way of testing it

01:28 <gbruno> [github] kintel pushed 2 modifications (EGL fix: static_cast when needed) https://github.com/openscad/openscad/commit/d4e7431c39360bf0bbb24c9adc538c88bd8e3eb7

01:28 <gbruno> [github] kintel synchronize pull request #4765 (EGL fix: static_cast when needed) https://github.com/openscad/openscad/pull/4765

03:11 <gbruno> [github] kintel pushed 1 modifications (EGL fix: static_cast when needed) https://github.com/openscad/openscad/commit/e0bbf49307b92414b04a13c86eacc27ddc825bca

03:11 <gbruno> [github] kintel synchronize pull request #4765 (EGL fix: static_cast when needed) https://github.com/openscad/openscad/pull/4765

04:24 <gbruno> [github] kintel pushed 1 modifications (EGL fix: static_cast when needed (#4765)) https://github.com/openscad/openscad/commit/f41aefc37c7e1232ef0d0aea17022771b18be49b

04:24 <gbruno> [github] kintel closed pull request #4765 (EGL fix: static_cast when needed) https://github.com/openscad/openscad/pull/4765

10:19 <J23k53> did anyone know if using Pythagoras is more efficient than solving something with sin and atan? .. so are sqrt and ^2 faster or the sin / cos / tan

13:57 <peepsalot> J23k88: i mostly wouldn't worry much about micro-optimizations like that. but from some profiling I've done, openscad function calls in general are relatively expensive with the way things are currently written (the act of searching for the context of the function definition, which may be overridden at any scope level)

14:00 <peepsalot> so whichever one gets away with fewer function calls might be somewhat faster if you're doing a ton of them. best to just measure the difference yourself, but I would guess that its mostly in the noise except for the most strenuous(and likely contrived) circumstances

14:02 <J23k88> ok thanks.   so  using sqrt(3)/2 or  sin(60)  shouldn't matter.

14:03 <J23k88> or is this  2 to 1 funct. call ?

14:04 <peepsalot> operators are not functions

14:06 <peepsalot> some of that function lookup cost could be mitigated with some clever caching or such deep in the openscad source. i've had some ideas for improving that for a while now, but hadn't gotten around to it

14:10 <peepsalot> but if you are doing a ton of the same calculation of a constant like that, i would suggest caching the result in a variable

14:10 <J23k88> but isn't   2^2  the same as pow(2,2) ?   (the first should be an operator the second a function or? )

14:12 <peepsalot> same result, different mechanism of lookup (there is no "lookup" of operator, it is instant as soon as it is parsed, because they can't be overridden by user code)

14:14 <J23k88> then ((s/2)^2+h^2)/(2*h); should be better than s/(2*sin(atan( s/2/h )*2 ) )  .. thanks a lot!

14:16 <peepsalot> J23k88: do you have specific code that is actually in need of optimization (is noticeably slow)?

14:18 <J23k88> no, i just try to use the best way in case that is used to calculate thousand points for a polyhedron

14:19 <J23k88> i found that calculating polyhedra is much slower than using a polygon and linear_extrusion (or rotate_extrusion)

14:22 <peepsalot> "best way" is to write understandable code rather than clever code. a year from now you may want to look back at some code you wrote and not have to wonder or struggle to remember what you were thinking

14:24 <J23k88> yes  very important lesson .. and i am still learning to write more comments to not only what i have done, but more about the why.

14:25 <J23k88> but it is not easy to know what information one will be missing some month later.

14:36 <peepsalot> Also see: Kernighan's Law - Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

14:46 <J23k88> I'll try to remember that.   I just had someone sending in a PR and first i thought "yes that makes sense" but then i found out that i used a 2nd module to do something more that wasn't obvious (and not documented).