02:44 <joseph_> teepee InPhase: It turns out that as a result of some bugs in VS Code (and its C++ extension), displaying stdout/stderr during debugging required an unobvious workaround. That consumed most of my day so far. Having now located the OpenGL error, I'm working on it and will update you soon with questions/progress

02:44 <joseph_> In the meantime, I'm bewildered about a GDB problem. I've `set print symbol-loading off`, but the output is still cluttered with many messages like "Loaded '/usr/lib/x86_64-linux-gnu/libOpenGL.so.0'. Symbols loaded." Is this a common problem, or am I using the wrong option? Fortunately this is just mildly annoying but I thought I'd ask anyway

02:53 <InPhase> joseph_: I've never seen anything like that in the Qt Creator debugger (which is free, ignore their attempts to pretend it's not free and grab the free download), if you want to try a different tool.

02:56 <InPhase> joseph_: Although as a programming tip, with some training on doing so, I think it is highly beneficial to minimize time spent in a debugger, and adopt a good system of print debugging where you dump out to console (either stdout, or for something like OpenSCAD you can temporarily print to the console in program) information that you want to see the values of. This lets you see a longer flow of program

02:56 <InPhase> state rather than snapshots of time like you might see in a debugger, and it can be a more descriptive pile of information that you can scroll up and down in with a text editor, or things like that.

02:56 <InPhase> joseph_: The only follow-up rule is then to just be mindful to monitor git diffs and don't commit print debugging lines. :)

02:59 <InPhase> joseph_: In some cases, on complicated items, you can add things as debugging outputs that stay in as long as you wrap them up properly so that they are only enabled with debug prints. The corefinement work was an excellent example of using extensive print debugging to the internal console to track the complexities of what was going on, and then they were removed from display in the end. But, you

02:59 <InPhase> should always feel free to liberally add lots of print debug statements on a temporary basis, and then purge them right after, to get as much visibility into the flow of the program or the state and progression of things going wrong as needed.

03:02 <InPhase> joseph_: The reason this is superior is that the time spent typing out a single line of print code pays back multiples because you leave a set of lines in as you go up the code flow and add in more lines, and then when you're done you see the whole path and you don't have to keep jumping around between breakpoints to wrap your head around the data flow. You just see it all at once, and you instantly

03:02 <InPhase> see it change and fix itself as it's fixed, or go into intermediate almost fixed states.

03:02 <InPhase> Then deleting them is a trivial time expense.

03:55 <ali1234> tbh breakpoints leave a similar trail

08:22 <Scopeuk> breakpoints don't let you rewind from the problem in quite the same way (I know visual studio can step backwards with the right options). both have their place. for crash bugs and out of bounds memory etc debuggers are invaluable particularly memory breakpoints, but a lot of the time they just slow things down, particularly if you are interacting

08:22 <Scopeuk> with a gui thread with a breakpoint in a draw call

08:23 <Scopeuk> they are complimentary tools not hard equivilents

08:28 <teepee> gcc has backward execution too, but I've never used that so far

08:29 <Scopeuk> I think I once started setting it up with visual studio and gave up about 12 settings in. conceptually it sounds like it would be a nice shortcut compared to running again with an earlier breakpoint. in practice *shrug*

08:29 <Scopeuk> I suppose potentially great to wind back from a crash at an unknown location

08:29 <Scopeuk> what happened, how did I get here

08:36 <teepee> yeah, I've seen an example with CLion and it looked quite impressive. Now I'm hoping updated C++ support finally makes it into NetBeans sometime in the next 20 years ;-)

18:00 <lf94> guys what do you call this shape https://upload.jeaye.com/tmp/c.png

18:00 <lf94> the last one

18:01 <lf94> is there something more specific than "lattice"?

18:23 <InPhase> "laser eyes"

18:25 <InPhase> For the second last part just left of it... Maybe 3D grid?

18:39 <Scopeuk> intersection of extruded # with its own rotation, probably also "oww, whats that doing on the floor"

18:39 <J1A846495> cube lattice

18:39 <Friithian> insanity

18:41 <J1A846495> https://en.wikipedia.org/wiki/Bravais_lattice

18:42 <J1A846495> primitiv cubic https://en.wikipedia.org/wiki/Cubic_crystal_system