About Flibble

[Mr Flibble]

I am a Generation X white male aphantasiac with self-diagnosed Asperger's.
Bite me.

Message ends.

/Flibble

[Alf P. Steinbach]

On 2 Jan 2023 02:22, Mr Flibble wrote:
> I am a Generation X white male aphantasiac with self-diagnosed Asperger's.

TIL: (Wikipedia) "Aphantasia is the inability to visualize. Otherwise
known as image-free thinking. People with aphantasia don't create any
pictures of familiar objects, people, or places in their mind's eye. Not
for thoughts, memories, or images of the future. We lack this
quasi-perceptual “picture-it” system completely."

Oh. Developing a graphical user interface framework with focus on visual
effects and color support while lacking the ability to visualize. That's
impressive! :-o

- Alf

[Mr Flibble]

I have to think in terms of abstractions instead; luckily being a
programmer mathematics helps out as it is used to abstract many real world
concepts.

/Flibble

[Chris M. Thomasson]

On 1/1/2023 5:22 PM, Mr Flibble wrote:
> I am a Generation X white male aphantasiac with self-diagnosed Asperger's.
> Bite me.

[...]

Why does it sure seem as if a lot of people with engineers diease are
very smart?

[Chris M. Thomasson]

Heck, look up Temple Grandin! A very smart person, indeed!

[Chris M. Thomasson]

https://www.templegrandin.com

[Chris M. Thomasson]

On 1/1/2023 5:22 PM, Mr Flibble wrote:

[...]

I got a little taste of the msvc debugger today...

[Chris M. Thomasson]

On 1/1/2023 5:22 PM, Mr Flibble wrote:

The god damn MSVC debugger is messed up pretty bad! Got another taste of it!

[Stuart Redmann]

Care to elaborate? I think that the Visual Studios debugging capabilities
are outstanding because of the ability to add custom debug visualization.
This is possible using a rather rich extension interface (badly documented,
though). It enables us to export our data (2D geometries like polygons,
line strings, etc.) into an external viewer with a simple mouse click. It
can‘t get more convenient than that.

Regards,
Stuart

[Mut...@dastardlyhq.com]

The sort of people who write extensions to editors and debuggers obviously
don't have enough real work to do.

[Manu Raju]

On 13/01/2023 06:19, Stuart Redmann wrote:
> Care to elaborate? I think that the Visual Studios debugging capabilities
> are outstanding because of the ability to add custom debug visualization.
> This is possible using a rather rich extension interface (badly documented,
> though). It enables us to export our data (2D geometries like polygons,
> line strings, etc.) into an external viewer with a simple mouse click. It
> can‘t get more convenient than that.
>
>

I think he was sarcastic about Flibble's health issues but I won't say
more because I could be wrong.

[Chris M. Thomasson]

A line of code would push_back an element into a std::vector. The damn
debugger would show that the vector contained no elements, however, one
was there. Then there are other oddities.

I have never had this problem with MSVC before.

[Mut...@dastardlyhq.com]

On Fri, 13 Jan 2023 13:43:06 -0800

I don't know about VS, but if you use heavy optimisation with gcc then gdb
will often lose the plot when stepping and examining variables. Perhaps that
was the issue you had?

[Mr Flibble]

Are you using VS2022? I found it to be unusable: internal compiler errors
and a broken debugger; I had to revert to VS2019.

/Flibble

[Mr Flibble]

VS2022 is shoddy product: not sufficiently tested.

/Flibble

[Chris M. Thomasson]

I am using the following version:

https://i.ibb.co/VYxHtLH/image.png

[Chris M. Thomasson]

In debug mode.

[David Brown]

Are you debugging optimised code here? Remember that when
single-stepping or using breakpoints, a debugger is working primarily
with the generated object code. And when looking at variables, it is
mainly using the data in memory or registers. But there is often a
disconnect between the lines of the source code and the generated object
code - a line you step over might /logically/ put an element into a
vector, but the actual change to the data structure could be done far
latter in the code.

MSVC has traditionally had quite a simplistic handling for a lot of code
generation - it has done little in the way of re-arranging code. But I
have heard (I don't use the tool myself) that is does more manipulation
these days.

When using gcc and a debugger, it is quite normal for single-stepping to
jump around the code, for things to happen long before or long after you
might think from the "current" source line, for variables to be
"optimised out", etc. Debugging optimised code is something of an art.

[David Brown]

"Debug mode" is mostly a meaningless concept.

Many IDE's set up two different build configurations - one they call
"Debug" with low optimisation and lots of debugger information, and one
they call "Release" with high optimisation and little debugger
information. But there is not really such a thing as "optimised" code
and "unoptimised" code - compilers can enable or disable different
passes and different kinds of optimisations. Some "optimisations" are
done even when compilers are set to "no optimisation", and some
optimisation passes that are possible are not done even on "highest
optimisation" flags. (And some "optimisations" can make code slower in
practice.)

At best, "debug mode" reduces the risk of seeing such disconnects
between the source code and the effect of the object code, but it will
not eliminate it.

[Mut...@dastardlyhq.com]

On Mon, 16 Jan 2023 11:32:34 +0100
David Brown <david...@hesbynett.no> wrote:
>When using gcc and a debugger, it is quite normal for single-stepping to
>jump around the code, for things to happen long before or long after you
>might think from the "current" source line, for variables to be
>"optimised out", etc. Debugging optimised code is something of an art.

And debugging optimised multithreaded code will end up with you gibbering in
a corner shouting "Deadlock!" or "Race!" at any nearby pigeons.

[Chris M. Thomasson]

I have a lot of experience with MSVC. Optimization is disabled in Debug
mode by default. I have not artificially altered the optimization
settings. I have never had these problems with the MSVC debugger before.
Your comment just made me check, and it's disabled in Debug mode. Mr.
Flibble is right. The debugger is not up to par. Damn.

[Chris M. Thomasson]

No. You made me double check the settings for debug mode. They are
disabled. I have never had this problem before in MSVC.

> Remember that when
> single-stepping or using breakpoints, a debugger is working primarily
> with the generated object code.  And when looking at variables, it is
> mainly using the data in memory or registers.  But there is often a
> disconnect between the lines of the source code and the generated object
> code - a line you step over might /logically/ put an element into a
> vector, but the actual change to the data structure could be done far
> latter in the code.
>
> MSVC has traditionally had quite a simplistic handling for a lot of code
> generation - it has done little in the way of re-arranging code.  But I
> have heard (I don't use the tool myself) that is does more manipulation
> these days.
>
> When using gcc and a debugger, it is quite normal for single-stepping to
> jump around the code, for things to happen long before or long after you
> might think from the "current" source line, for variables to be
> "optimised out", etc.  Debugging optimised code is something of an art.
>
>

The MSVC has always worked really damn good, up until the recent
version... Damn!

[Chris M. Thomasson]

MSVC's debugger was always pretty damn good. I have used it to debug
nightmare multi-threaded code created by somebody else, where I had to
pause threads at a specific line, in order to reproduce a certain bug
that would only trip once in a blue moon. Found it during artificially
stress and load testing. This was a long time ago. Actually, I think I
wrote about it here some years ago on this group.

Optimization is turned off in Debug mode. Wrt to the IDE:

https://i.ibb.co/SV3dMQ7/image.png

Never had this problem before.

[Chris M. Thomasson]

On 1/16/2023 2:37 AM, David Brown wrote:

https://i.ibb.co/SV3dMQ7/image.png

[Chris M. Thomasson]

I wonder if frame pointers has something to do with it. The thing is
that MSVC always just worked. I have never experienced anything like
this in it before. ;^o

[Mr Flibble]

As your codebase doesn't look as involved as mine do you think you are in
a position to create a test case and create a MSVC defect report? In the
meantime I recommend downgrading to VS2019.

/Flibble

[Mut...@dastardlyhq.com]

On Mon, 16 Jan 2023 11:51:56 -0800

"Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:

>On 1/16/2023 3:31 AM, Mut...@dastardlyhq.com wrote:
>> On Mon, 16 Jan 2023 11:32:34 +0100
>> David Brown <david...@hesbynett.no> wrote:
>>> When using gcc and a debugger, it is quite normal for single-stepping to
>>> jump around the code, for things to happen long before or long after you
>>> might think from the "current" source line, for variables to be
>>> "optimised out", etc. Debugging optimised code is something of an art.
>>
>> And debugging optimised multithreaded code will end up with you gibbering in
>> a corner shouting "Deadlock!" or "Race!" at any nearby pigeons.
>>
>>
>
>MSVC's debugger was always pretty damn good. I have used it to debug
>nightmare multi-threaded code created by somebody else, where I had to
>pause threads at a specific line, in order to reproduce a certain bug

Thats fine if you know where the line is but usually with threading issues
(and to be fair non threaded code too) a bug/crash occurs due to an earlier
bug or design error which in itself goes unnoticed.

[Chris M. Thomasson]

Touche. Well, if there is a bug in my OpenGL code, I have not found it
yet. Humm... So far, everything works and renders perfectly. My
debugging issue with MSVC had to do with push_back's on a vector, then
the debugger showed that it had no items. I said, shit... So, I iterated
the vector and sure enough, it was not empty and all of my vector data
(vertex, color, texture vertex, normals, ect...) was all there and
filled in with the correct data. Strange. I was thinking if the debugger
says the vector is empty, then how did all of the data get successfully
uploaded to the GPU! Argh!

Fwiw, here is an crude example scene of my current project:

https://youtu.be/n13GHyYEfLA

[Chris M. Thomasson]

Perhaps... I am working hard on a bone system, to make any model dance.
I am learning about geometry shaders... MSVC let me down.

[Chris M. Thomasson]

Trying to stick figure the model in a sense with a fractal shape. Use it
as bones. The model of the girl is made up of 103 separate meshes, with
their own indices. Just experimenting along... ;^)

[Mut...@dastardlyhq.com]

On Tue, 17 Jan 2023 12:36:06 -0800

"Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:
>On 1/17/2023 1:34 AM, Mut...@dastardlyhq.com wrote:
>> On Mon, 16 Jan 2023 11:51:56 -0800
>> "Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:
>>> On 1/16/2023 3:31 AM, Mut...@dastardlyhq.com wrote:
>>>> On Mon, 16 Jan 2023 11:32:34 +0100
>>>> David Brown <david...@hesbynett.no> wrote:
>>>>> When using gcc and a debugger, it is quite normal for single-stepping to
>>>>> jump around the code, for things to happen long before or long after you
>>>>> might think from the "current" source line, for variables to be
>>>>> "optimised out", etc. Debugging optimised code is something of an art.
>>>>
>>>> And debugging optimised multithreaded code will end up with you gibbering
>in
>>>> a corner shouting "Deadlock!" or "Race!" at any nearby pigeons.
>>>>
>>>>
>>>
>>> MSVC's debugger was always pretty damn good. I have used it to debug
>>> nightmare multi-threaded code created by somebody else, where I had to
>>> pause threads at a specific line, in order to reproduce a certain bug
>>
>> Thats fine if you know where the line is but usually with threading issues
>> (and to be fair non threaded code too) a bug/crash occurs due to an earlier
>> bug or design error which in itself goes unnoticed.
>>
>
>Touche. Well, if there is a bug in my OpenGL code, I have not found it
>yet. Humm... So far, everything works and renders perfectly. My

The sort of bugs we're discussing here arn't the obvious "Oh, that result isn't
correct" type. They're the "Oh, why has is suddenly hung/crashed when its run
fine for 2 months" type.

[Christian Gollwitzer]

Am 18.01.23 um 10:27 schrieb Mut...@dastardlyhq.com:

Yes, and here are my 2cents to debug these: valgrind, helgrind and
address sanititzer (million times more worth than 2 cents)

Christian

[Chris M. Thomasson]

Usually, those type of bugs are with race-conditions. My code is not
using multiple threads yet.

[Scott Lurndal]

Or using uninitialized variables, particularly in
functions. Could work for weeks, then the program
takes a different path and the stack contains a
value that causes a crash.

[Chris M. Thomasson]

True. Well, so far, I don't think I have a problem. MSVC is pretty good
at flagging uninitialized variables, and I have a habit of always
initializing them.

int x = 0;

instead of:

int x;

Well, if I do have a bug, its a good thing that my program is in
pre-alpha experimental stage!

[David Brown]

That's a /really/ bad idea (unless you actually /want/ x to be 0, of
course). It is bad precisely because it stops the compiler from warning
you when you have forgotten to put a real value in the variable.

Get in the habit of declaring local variables only when you have
something useful to put in them, and initialising them at that point.
But if you must declare a variable before you have an initial value, do
not artificially initialise it - you are just making it harder for the
tools to find your bugs.

[Chris M. Thomasson]

Yes. I have been told this, damn near, exact same warning before David
on a couple of jobs.

[Chris M. Thomasson]

On 1/18/2023 12:17 PM, David Brown wrote:

Fwiw, I am going to start fresh in a couple of days. Basically refactor
my experimental pre-alpha code base into a fresh project on a
part-by-part basis. I need to do it. Basically, clean house!

[Keith Thompson]

Or initialize it with some recognizably invalid value, if there is such
a value for the type.

Leaving it uninitialized helps the compiler diagnose errors.
Initializing it with recognizable garbage helps with run-time debugging.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

[David Brown]

That can certainly be better than using a plausible value (and 0 is
often plausible). But it is still better to leave it uninitialised
where possible - if it is not spotted by static error checking, it can
be spotted by a sanitizer at run-time.

Recognizably invalid or implausible values are particularly good if you
have an array and will use some of it, but perhaps not all of it. Such
cases are very hard for static analysis.

[David Brown]

That should give you a clue that it is a good idea!

[Mut...@dastardlyhq.com]

There's no excuse for uninitialised variables these days as any decent C++
compiler will output warnings about them.

[David Brown]

There are plenty of developers who don't know how to use their tools
very well - I have seen many people use compilers without warning flags,
optimisations, or other flags.

[Scott Lurndal]

And I've seen various versions of GCC not detect uninitialized variables
in certain cases, up through gcc11. Suprising when it happens.

[Chris M. Thomasson]

0xDEADBEEF is a fun one. :^)

[Chris M. Thomasson]

Nodding. So far, I have found a bug in my code yet. During a refactor.

[Chris M. Thomasson]

God damn it! I have NOT found a bug yet. f'ing typos!

Shit.