00:10 <dTal> wow awesome, I've got a scissor grid with a expanded/contracted ratio of 4 to 1

14:40 <guso78k51> openscad's cmake can very well detect if flex or bison is missing as they are essential for parser generation. however cmake does not stop on missing gettext which is used for the final translations.maybe we can check it at cmake stage already ?

14:53 <teepee> what exactly? the library is needed for building, but the tools are supposed to be optional

14:57 <guso78k51> i tried to build openscad in my raspberry pi400 totally from scratch. it just came with a bare ubuntu.

14:57 <guso78k51> after installing quite some packages like harfbuzz, qt, openscg, many more cmake was happy and make did start

14:58 <guso78k51> however after openscad got linked, some other commands similar *MSGFMT* did execute but they failed. after installing gettext the problem was solved and make did finish wish error code 0

14:59 <teepee> so ideally we may want to find a way to detect missing gettext tools and skip the translation stuff

15:00 <teepee> I think it should then just pick up the latest version that is checked in

15:00 <guso78k51> i have seen some gettext cmake Module script, but this was to complicated for an inline-edit-pr

15:01 <teepee> sounds like a separate script in cmake/Modules or whatever that folder is called

15:02 <guso78k51> yes it would go next  to findCryptoPP.cmake script

15:02 <teepee> looking into the repo, it only has the *.po files, so that might mean english only when missing gettext utils. but it would be ok with a warning instead of a build error

17:17 <version-curious> This is for all the OpenSCAD developers - First, and foremost, THANK YOU!  While it's far from perfect, I'm really quite grateful for all that it is capable of!  Second, The latest published version is 2021.01, but there's clear activity on the GitHub repo.  Is there a target for a more updated version?  Is there a roadmap published somewhere?

17:18 <teepee> hi version-curious

17:19 <teepee> there is no roadmap

17:20 <version-curious> teepee - Thank you for the quick and clear response.  =D (y)

17:22 <teepee> I'd say there's not just activity, there's even very exciting stuff going on :)

17:23 <version-curious> "very exciting stuff going on" - Now I'm excited and even more eager for a new version to drop!

17:25 <teepee> unless you need to explicitely target sharing code working for other people with the release version, you can easily have a peek on the latest features

17:25 <teepee> well, if you have one of the more common operating systems running :)

17:27 <version-curious> Under both tags and releases, I'm still only seeing 2021.01 (https://github.com/openscad/openscad/releases), I assume that means that I'll need to build the latest?

17:28 <Scopeuk> should be a nightyly section on the website

17:28 <teepee> what OS / Distribution do you hve?

17:28 <teepee> *have

17:28 <version-curious> macOS Catalina 10.15.7

17:29 <version-curious> (I've got some other software that prevents me from upgrading macOS =L )

17:29 <teepee> yep, then https://openscad.org/downloads.html#snapshots has a very fresh version from yesterday

17:30 <version-curious> AWESOME!!!  Thank you so much!!!

17:30 <teepee> it *should* be fine, the build target is 10.14, so crossing fingers

17:30 <teepee> sometimes Apple works in mysterious ways unfortunately

17:30 <teepee> and the macOS wizard is on vacation ;-)

17:31 <teepee> most notably, check the Preferences->Features page (which does not appear in the releases)

17:32 <teepee> the "Enable Manifold" is probably the biggest change as it gives huge performance boost

17:33 <teepee> there's still a couple of minor issues, but the upstream developers of that are impressive in squashing bugs now that this quite young engine is out in the world

22:11 <joseph_> teepee: After assessing the current state of my work and research, I think a 4-week extension to GSoC would be appropriate. This will give a buffer zone for documenting results of my experiments in the codebase and solidifying tweaks. My project proposal intentionally left room for dynamically scoping the extent of what my ultimate changes will be.

22:12 <joseph_> The main goal that got concretely specified was that I should produce some sort of controls for disabling legacy calls. Kintel's previous suggestion was to de-scope modernization of preview rendering if time gets tight. So I'm now trying to get a core profile build working with OpenCSG disabled, and using a macro to turn off any other legacy calls that produce errors elsewhere

22:14 <teepee> joseph_: sounds good, if you want to take care of that topic, that's great. so shall we check if the change is still possible (I believe it is)

22:16 <teepee> I guess a macro is a reasonable way, as it's supposed to be removed at some point anyway. So it probably does not make too much sense trying to find a neat solution. It's more useful to mark the places and find a path to core-only context

22:17 <joseph_> teepee: A message I received earlier from Google said, "...the Org Admin can edit the final submission date for you. This has to happen before the start of your final submission period." So yes it seems like an extension is possible before August 20th

22:18 <teepee> yep, that was my understanding too. so let me send a mail to Sean

22:25 <teepee> joseph_: ok, sent to our mentor group list

22:29 <joseph_> Thanks. For now I have been calling the macro ENABLE_FIXEDFUNCTION_GL. Also I am configuring the builds with GLAD and setting the GL profile to core 4.6. If necessary I could lower it to Core 3.x but I'm not sure yet if that would then cause any *forward* compatibility errors. Because #4549 uses a OpenGL 4.6 Compatibility profile

22:31 <teepee> probably not, but that seems a good approach, I think 4.6 is even supported by the Mesa3d software renderer

22:32 <teepee> it would be great if that would even fix the windows VM issues I'm seeing, but that's certainly not the biggest concern

22:32 <teepee> but useful :)

22:40 <teepee> ah, certified 4.5 but some support for 4.6