After a software update, VS2022 stopped working correctly. When I hit a break point, I don't get any local variables and their values, instead I get a "wait..." label that looks like a button, and also VS is growing in memory size until it crashes my Windows, or I either stop the debugging or VS itself....
Last night, I received a task to investigate a massive #performance regression in certain parts of the game.
So today I began investigating and ran the latest build on my 4 testing machines. And indeed, the machines that had an #Intel#GPU only achieved ~10% of the FPS they usually had. "Oh no!" I thought, and spent all day profiling and disabling various engine features, but no matter what I did, the performance didn't improve much.
And then I found it. Those Intel machines still had #Mesa DLLs in their build directories from the last time I was investigating a graphics driver issue. Which means they have been using a #software implementation of #OpenGL all this time! :drgn_stare:
I removed the DLLs and the performance returned to normal.
And now I'm back to square one, unable to reproduce the performance issue. :drgn_weary_sob:
So, hands up who else does this: adding custom debuggers to your interfaces for testing them out?
It’s a little habit I picked up decades ago during the Flash days and it’s as useful now. (Found and fixed at least two bugs after implementing this simple one today.)
I wonder what #ardour is doing different to #bitwig in terms of their #flatpak builds. I noticed that some #plugins run just fine in Ardour while Bitwig Studio reports problems with reading metadata or glibc version conflicts. 🙄️ #sandboxing#debugging#daw#linuxdaw
The best #debugging advice @Cyzaine ever game me was to put print statements everywhere. Some times I get lucky and the 1st one shows me the issue. Today it was 3rd times the charm!
Today I spent a few hours trying to track down a problem deep in a helper module of a complex production application written in #Haskell. Among other things, it involves threads, a monad transformer stack (3 or 4 levels deep, I think?), an SQL database, and HTTP calls to an external service.
In the end, I managed to boil one issue in the code down to the following crucial lines:
forever_mpl :: Monad m => m a -> m b<br></br>forever_mpl m = fix (m >>)<br></br><br></br>forever_mpf :: Monad m => m a -> m b<br></br>forever_mpf m = fix (self -> m >> self)<br></br>
In theory, both of these should be equivalent to forever from the base library. However ...
In one place in the code, using forever_mpl (the first definition) works correctly: It repeats an action forever. But switching to forever_mpf (the second definition) makes the code hang instead (at 0% CPU). Why?!
I know the answer now, so here's a #debugging challenge: Can you think of a reason why these two definitions should behave differently? Can you implement a Monad instance with a >> that distinguishes between them somehow?
Attempting to calibrate my printer using SuperSlicer’s calibration models and the retraction calibration tower is just stringy all the way up. Is there some other factor I should be playing with here? (Each step is +.5 retraction length. At the top it’s 7!)
Nice, spent the last two hours #debugging an upstream #dependency issue, only for the issue to be “yanked” upstream. Thankful, but dang does my head hurt!
I initially wanted to work on some photos this afternoon, but I instead spent some time #debugging a bug that appeared in #darktable 4.4.1.
By the way overlay filesystems are a nice way to test a dev version on #linux without accidentally messing things up or having to manually copy tons of data!
Dynamic and interactive programming environments like those of Lisp and Smalltalk make it easy to fix programs while they're running. How cool is that?
To demosntrate fixing a bug in an executing Lisp function from the debugger of Medley Interlisp, I recorded this screencast:
I don't know if anyone actually does #webdevelopment testing with #GNOME#Web (Epiphany) on #Linux, but if you've found the web inspector to be infuriatingly clunky everytime you open it, these fresh tickets are for you:
I'm looking for a debugger for Windows after the Visual Studio one no longer works for me
After a software update, VS2022 stopped working correctly. When I hit a break point, I don't get any local variables and their values, instead I get a "wait..." label that looks like a button, and also VS is growing in memory size until it crashes my Windows, or I either stop the debugging or VS itself....