00:01 <joseph_> Sounds good, I'd be happy to discuss it further

00:15 <joseph_> kintel: Hello, I don't believe we've messaged before. I'm Joseph/jbinvnt, last year's Summer of Code contributor. My previous project to support custom shaders (draft PR #4330) delved into the renderer classes. I'm thinking about doing another GSoC project this year, and I wanted to hear your thoughts about me possibly helping with OpenGL refactoring. As a full-time university student I often won't see every IRC conversation that

00:15 <joseph_> scrolls through. But if you mention my username then a bot pings my phone, which I will see.

00:46 <kintel> joseph_ Hi, I hadn't paid attention to last year's gsoc, but I'll have a look at your draft and see how that fits my current work

00:47 <kintel> It might be a bit hard to map out an independent project framed around "helping with refactoring" : /

00:47 <kintel> ..but the goal of my refactoring is to declutter things and make it easier to build new things on top of it

00:48 <kintel> My initial goal is to refactor all of the OpenGL context handling to allow us to ask for OpenGL 3 or GLES2 contexts, and use that as a starting point for removing all legacy (immediate mode) OpenGL usage.

00:53 <kintel> One task of unknown size would be to refactor OpenCSG to use only modern OpenGL/GLES2, and remove its GLEW dependency and perhaps kill the qmake build system. That may or may not equate to adopting the project though : /

00:54 <kintel> ..and if you follow that trajectory: Preview rendering as part of the wasm build

00:57 <gbruno> [github] kintel closed pull request #4575 (Green refactoring: Move duplicated FBO handling out of platform-specific context code) https://github.com/openscad/openscad/pull/4575

00:57 <gbruno> [github] kintel pushed 8 modifications (Green refactoring: Move duplicated FBO handling out of platform-specific context code (#4575)) https://github.com/openscad/openscad/commit/1295101a019b55fd12c642813dc6290cc4a8e112

00:57 <kintel> In terms of GSoC, my main challenge is that I'm pretty much offline from mid-June to mid-August : /

00:58 <teepee> if we can get the topics sorted, we can take care of it

00:58 <teepee> assuming we get the registration sorted

01:45 <gbruno> [github] kintel pushed 2 modifications (Build fix) https://github.com/openscad/openscad/commit/17970a1fcdc7e3a79668069c248690eaf82c9146

01:45 <gbruno> [github] kintel synchronize pull request #4549 (Add support for GLAD) https://github.com/openscad/openscad/pull/4549

02:18 <joseph_> kintel: Thank you for the helpful information. I would be open to consider working on a different GSoC idea, in the event that the reasons you mentioned make it infeasible to choose an OpenGL improvement project. That said, if there is a way to sufficiently spec it out beforehand then I think there could be benefit to focusing on the area I've already gotten experience with.

02:25 <joseph_> One thing that you might notice when looking at last year's PR is that I implemented structures allowing information about cut faces to be sent to the shader. Depending on your changes since then, that approach might be either helpful towards the goal of removing legacy OpenGL, or no longer necessary. Whether or not it happens during the next GSoC, before 4330 is to be merged I'd likely need to bring in the new changes from

02:25 <joseph_> master.

02:44 <kintel> joseph_ I haven't touched any actual rendering code yet; so far I'm only messing with context creation, FBO and related cleanup

02:46 <kintel> Btw., another topic which crossed my mind: How do deal with GLSL versions when supporting different OpenGL/GLES versions

04:12 <gbruno> [github] kintel pushed 3 modifications (Test PR with GLAD on GitHub CI) https://github.com/openscad/openscad/commit/6dfc88f6dd978215ab3b5e3ede858b93bc16146e

04:12 <gbruno> [github] kintel synchronize pull request #4549 (Add support for GLAD) https://github.com/openscad/openscad/pull/4549

05:53 <Guest62> Hy! My name is Aqeel Ashraf. I am from pakistan. I applied in GSoc 2023. I am a C++ developer. I selected your organization because your organization works on c++ ,which maches my interest So I I want to contribute in your organization.I shall be very thankful to you if you make my chat with my mentor so it helped me in my project to make it

05:53 <Guest62> effective so my chances of acceptance in GSoC 2023 becomes high. Again I shall be very thankful to you if you give me a chance to contribute.

10:32 <buZz> i wonder why 'you use c++' would be highest motivation for someone joining the gsoc :P

10:38 <Scopeuk> buZz I guess cv building "C++ code as part of Gsoc" with the hope that counts in your favor

13:47 <J23851> haha https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/

14:20 <teepee> ouch, but good action and expanation of what happened

21:00 <guso78[m]> When openscad.exe Crashes, closes and does Not leave any Message, IS there a was to get a reason, or do i really have to deaktivate Code until IT works again?

21:01 <teepee> message where? on console is impossible as it's a GUI app, an installed debugger should be able to catch it, otherwise it should end up in the event log

21:15 <kintel> I seem to remember openscad.com being able to output to a console. But I've never really understood Windows :/

21:16 <teepee> yes, it's a console app so it's able to catch stdout/err, but I'm not sure it can correctly forward crashes

21:16 <teepee> also I would not claim to understand Windows either :)

21:17 <peeps[work]> guso78[m]: if you have code which reproduces a crash on the latest build then please open a new issue

21:18 <peeps[work]> but yes generally you would run a build with debug symbols and a debugger such as gdb or lldb

21:19 <guso78> peeps[work], thank you for the suggestion.

21:20 <guso78> Unfortunately i built openscad myself  from my own code. the question  is rather: whats the best debugging technique to debug "Remote"  errors which only happen in windows worls

21:20 <guso78> world

21:21 <teepee> remote meaning in a VM?

21:22 <teepee> regardless, the best option is probably the combination of what was just said: 1) make sure to have a debug build 2) have a debugger that can read that info

21:22 <guso78> teepee, my flow right now is: build with MXE, then copy installer to windows  machine, install it, test openscad

21:23 <gbruno> [github] kintel pushed 1 additions 2 modifications (GLX) https://github.com/openscad/openscad/commit/68d0921d7401b99cf11fe5b1642f4eb8b98d6648

21:23 <teepee> which can be a bit tricky with those cross build stuff, but in general the mingw builds are compatible with native windows debug I think, e.g. WinDbg (if that still exists)

21:23 <kintel> guso78: Try msys2, that's a huge step forward from MXE since you're on Windows

21:23 <teepee> yeah that ^

21:23 <teepee> cutting out the remote part might help quite a bit

21:23 <kintel> Difference is really if your main machine is Linux or Windows

21:23 <teepee> and msys2 ships qtcreator for example

21:24 <guso78> if there happens a "segfault" e.g. in an exe file. normal behaviour is the  window closes without message, right ?

21:24 <kintel> If you're _on_ Linux and want to test on a remote Windows box, I've managed to set up VS Code to remote into the Windows machine and build using the VS Code terminal

21:24 <kintel> ^ Windows 11, I have no idea how to do it for other variants ;)

21:29 <kintel> related note: VS Code is actually quite good! The editor isn't great coming from Emacs, but the rest really works. Never thought I'd praise Microsoft for anything; the world is changing :)

21:32 <gbruno> [github] kintel opened pull request #4576 (Refactor offscreen context management) https://github.com/openscad/openscad/pull/4576

21:34 <gbruno> [github] kintel edited pull request #4576 (WIP: Refactor offscreen context management) https://github.com/openscad/openscad/pull/4576

21:35 <gbruno> [github] kintel edited pull request #4576 (WIP: Refactor offscreen context management) https://github.com/openscad/openscad/pull/4576

22:03 <gbruno> [github] kintel pushed 1 modifications (Include windows.h before glad) https://github.com/openscad/openscad/commit/ad31e15118a3e1599fefe1e82e24e31496b9abb8

22:03 <gbruno> [github] kintel synchronize pull request #4549 (Add support for GLAD) https://github.com/openscad/openscad/pull/4549

22:06 <kintel> guso78 In terms of segfault handling: I believe the default behavior on both Windows and Linux is to kill the process, and let the system display an appropriate message about what signal was sent.

22:07 <guso78> kintel.  thanks for the info. i  did not notice any info while the window was closed.

22:07 <kintel> It is, however, possible to manually catch the segfault to provide some message to users, but it's probably very limited what you can safely do in a segfault handler. I don't think we do any of that in Openscad

22:08 <kintel> As mentioned above, getting a debugger so you can inspect the stack trace is a valuable investment in your own development environment :)

22:21 <guso78>  // renderer_shader.data.csg_rendering.tex1 = glGetUniformLocation(edgeshader_prog, "tex1"); //4

22:21 <guso78>  // renderer_shader.data.csg_rendering.texturefactor = glGetUniformLocation(edgeshader_prog, "textureFactor"); // 5

22:21 <guso78>   renderer_shader.data.csg_rendering.barycentric = glGetAttribLocation(edgeshader_prog, "barycentric"); // 6

22:21 <guso78>  // glUniform1f(renderer_shader.data.csg_rendering.texturefactor , 0.0);

22:21 <guso78>  // glUniform1i(renderer_shader.data.csg_rendering.tex1 , 0);

22:21 <guso78> i just found out,  that one of the 4 commented lines cause the crash  :)

22:25 <guso78> last one...