[OT] Grumble...

[Vladimir Jovic]

Please, PLEASE point me to a well working GUI debugger for ubuntu lucid.

When I went home, I checked which debuggers are there on lucid, and here
is the list of debuggers I found :
http://projects.gnome.org/nemiver/
http://www.kdbg.org/
kdevelop debugger
I didn't put ddd, as I see you do not like it

 

[Vladimir Jovic]

Rolando Pereira a écrit :

That's even MORE typing since you have to add and delete those displays
at each time. You arfe normally not interested in "foo_variable" ALWAYS.
Just when its getting assigned or appears in the expression being executed!

Normal debuggers FIGURE OUT THEMSELVES the variables that are
inetersting.

The mere fact that you do not figure out this shows how hopeless
outdated your "debugger experience" is.

Neat. I have to download windows from somewhere and install just to see
how it reads my mind which variable I want to show

I must admit that I do not run debugger often (once per month), and I am
using only ddd, therefore my "debugger experience" is outdated.

 

[Vladimir Jovic]

And yes, I stick to C. And what my age is concerned... I hope that
doesn't ever happen to you.

Yes, it doesn't matter. An old fool is still a fool (seeing your
comment, specially next)

 

[jacob navia]

Vladimir Jovic a écrit :

Neat. I have to download windows from somewhere and install just to see
how it reads my mind which variable I want to show

I must admit that I do not run debugger often (once per month), and I am
using only ddd, therefore my "debugger experience" is outdated.

The debugger I wrote uses a simple algorithm:

Extract all the identifiers from the current expression.
You get the current expression from the line number, that is part
of the debug information and even gdb knows it.

Then, show all those identifiers in the "Autos" window together with
their values.

This is a VERY simple algorithm that will work in 90% of the cases.
If the identifier has no debug info, drop it, since it is probably
a macro.

As you can see, this is a general and simple algorithm, very easy to
implement. The fact that you suppose that "windows reads your mind"
shows that you are just not trying to do any effort at this problem,
as most gdb users, unable to understand anything more advanced

 

[jacob navia]

Vladimir Jovic a écrit :

Yes, it doesn't matter. An old fool is still a fool (seeing your
comment, specially next)

Yet another GNU fan. As "joe", you just present insults
("old man" "stupid" "fool", etc) when somebody dares
criticize the gdb crap.

 

[Jorgen Grahn]

Maybe in general, does not apply to me, as I started programming well before
windows gor widespread, got used to all kinds of tools on DOS, embedded
systems, etc. (Btw Borland's Turbo debugger showed that you can create a
handy debugger for the text screen that is about the workflow...)

That in itself doesn't exclude you from his mindset theory. Lots of
people have switched from various older environments to Windows or
modern Unixes, and gotten used to whatever they chose.

LOL. So typing annoys you for that corner situation. Now imagine how I
feel using gdb, when I need to do typing and typing ant more redundant
typing and typing again for everything, everytime?

That shows the different mindset I think. Like Miles, I'd be horrified
to type names and hex numbers -- not because I mind typing, but
because I'm used to having TAB expansion, various other expansions and
the command-line history (with incremental search) to help me.

/Jorgen

 

[Jorgen Grahn]

* James Kanze, on 04.08.2010 16:19:

On 08/ 4/10 06:41 AM, Balog Pal wrote:

[...]
My other pain is debugger -- is the world really stuck with gdb?

Most Linux devs are happy with it.

I never cared much for it, but now that I have to use Visual
Studios... The Microsoft debugger has to be the worst I've seen
to date.

How so? It's about the best there is. Until recently gdb couldn't even
trace into constructors, and it's generally erratic, while MS' debugger
is dependable.

I think our usage patterns set our expectations of a debugger.

And the debugger we have shapes our usage patterns ;-) Which is one
reason these discussions are so difficult.

Many
years ago when I was hunting around for a developer environment, my
priorities were data visualisation, the ability to follow forks into
child processes remaining attached to the parent and good support for
threading. A bonus was the ability to check memory access and leaks.

At the time only one tool offered the full set (dbx) so I went down that
path and have stuck with it. I don't use a debugger as much these days,
but I when I do I prefer to use it from with some form of GUI.
Debugging is probably the most visual of all the tasks we perform, so
being able to see multiple concurrent views of the code is a big help.

I use gdb almost only for analyzing core dumps, i.e. the program is
stopped and I just wander around checking call frames, variables and
memory areas. But that's also the easiest part of the user interface, so
I cannot say for sure I wouldn't use watches and breakpoints if there
was a really useful interface to those features.

(But what I do the most is try to avoid making mistakes that lead to
run-time errors ;-)

/Jorgen

 

[Balog Pal]

That shows the different mindset I think. Like Miles, I'd be horrified
to type names and hex numbers -- not because I mind typing, but
because I'm used to having TAB expansion, various other expansions and
the command-line history (with incremental search) to help me.

How is that a different mindset? I don't mind typing at all, as long as I
type in *new* stuff, something that is in my head and the computer can't
know.

I do mind typing REDUNDANCY. TAB expansion is an okay tool: you start the
stuff, ask in the rest of it. gdb certainly has TAB expansion *in theory*
and to add insults to injury, as it certainly does NOT work 99% of the time,
for reasons unknown. And it fails to recognize symbols on a whim, so you
must go back to look up filename and line number. It certainly suggests to
use TAB. It has history, but the most insane manner imaginable. The old 1k
doskey.com did better, by not storing an entry that was already in the
history, just move it to top. you step 20 times, then cant fetch tha last
other command with just UP. Only by using your memory or brute force.

And as others mentioned, other debuggers jsut show most of the expressions
that are relevant to the work as "auto" -- those in the current expression,
locals in the frame, data members of the instance if you're in a member
functions. Even a single letter of typing to get those is redundant.

 

[jacob navia]

Balog Pal a écrit :

And as others mentioned, other debuggers jsut show most of the
expressions that are relevant to the work as "auto" -- those in the
current expression, locals in the frame, data members of the instance if
you're in a member functions. Even a single letter of typing to get
those is redundant.

I think adding that functionality to gdb is a matter of
3 to 4 days development at most, including testing. In my
debugger I just extract 3 lines around the current line, ignore comments
and then extract all identifiers from them. I do not even analyze the
current expression. And that isuseful 99% of the cases, I rarely have
to type anything to get some value.

Why isn't this done?

I do not know. But inany case this attitude towards easy of use is
widespread in the GNU people. Look even the reaction in this group to
some mild criticisms: "Old man" "fool", "go back to C", etc.

I contributed a patch to gdb that was completely ignored, then I
stopped. They didn't even bother to ACKNOWLEDGE that they received the
patch. And the bug is still there. They dodn't reject my patch because
they had another solution. They just did not care at all.

I only use gnu if I have to. As windows.

 

[Öö Tiib]

But inany case this attitude towards easy of use is
widespread in the GNU people. Look even the reaction in this group to
some mild criticisms: "Old man" "fool", "go back to C", etc.

Such reactions may be always ignored. These insult the users more than
targets. You should avoid taking anyone saying such direct insults
seriously. If you have tendency to get offended then just killfile
them.

 

[Jorgen Grahn]

No Unix-ish scripting language I know of (Perl, Python, AWK, etc.) is
standardized either.

But noone is going to pull them away from under us; we'll still have
them in 5 years. I suppose he meant to say he didn't trust MS to keep
the powershell around and reasonably compatible with itself.

Besides, I don't see why that matters. C++ for example wasn't
standardized until 1998, yet its most thriving time was probably
before that.

I must say that I'm happy that we can talk about *standard* C++ here,
not my Gnu C++ versus your Microsoft C++ versus ...

/Jorgen

 

[Öö Tiib]

But noone is going to pull them away from under us; we'll still have
them in 5 years.  I suppose he meant to say he didn't trust MS to keep
the powershell around and reasonably compatible with itself.

For classical C++ development (pure C++ or symbiosis with one script
language) there is too low gain if any. That leaves only pointless
risk. Risk is a risk however low someone judges it to be.

Maybe if majority of product is written in .NET, or target involves
Windows network administration or MS SQL Servers or other MS native
products like that then added productivity of automating some
management of it makes it a good bargain.

I must say that I'm happy that we can talk about *standard* C++ here,
not my Gnu C++ versus your Microsoft C++ versus ...

Yes. Standard is set of universal rules what is conforming and what is
deviating. When someone does not see how even that matters to
something then how to reason?

 

[James Kanze]

On Aug 7, 11:33 pm, Öö Tiib <[email protected]> wrote:

[...]

No Unix-ish scripting language I know of (Perl, Python, AWK, etc.) is
standardized either.

The Korn shell, AWK, sed and all are standardized (ISO 9945, aka
IEEE 1003).

Besides, I don't see why that matters. C++ for example wasn't
standardized until 1998, yet its most thriving time was probably
before that.

But the standardization effort started around 1990, and it was
recognized that it would be standardized.

 

[joe]

joe a écrit :

What should that mean Mr?

Literally, what do you mean with "What should that mean?"? Surely I meant
something at the time, but now, pfft, water. You are perhaps bored? Ah,
don't answer that, this is a technical forum (not to be misunderstood as
the hijaaked usage of the term 'forum' which is every web "developer's"

It hurts when somebody criticizes GNU?

I have no comment on G anything. I am definitely R-rated! (At least so I
pose. Sometimes.)

Well, that was the intent. To show how crappy GNU tools can be.

Then I was "butting in", for "I do Windows, not Unix". Not that there's
anything wrong with that!

And yes, I stick to C.

That's apparently "a lie", now, huh. Who says "you can't teach an old dog
new tricks"? (rhetorical).

 

[joe]

Vladimir Jovic a écrit :

Yet another GNU fan. As "joe", you just present insults
("old man" "stupid" "fool", etc) when somebody dares
criticize the gdb crap.

Abre Los Ojos.

 

[joe]

Vladimir Jovic a écrit :

The debugger I wrote uses a simple algorithm:

I can use that skill. "Send me your resume". Joke is: it's a joke!
"Inside joke" is, it's a joke!

Extract all the identifiers from the current expression.
You get the current expression from the line number, that is part
of the debug information and even gdb knows it.

Then, show all those identifiers in the "Autos" window together with
their values.

That is quite detailed a description. (Tends to bore me, not meaning to

This is a VERY simple algorithm that will work in 90% of the cases.
If the identifier has no debug info, drop it, since it is probably
a macro.

I'm sure it is important, but I'm only buying, so I don't believe you.
(rhetorical).

As you can see,

Uh oh, I sense reason to question now... you are telling him what he can
see?? Nuff said. Drop the spiel dude. It's 2020 and no one falls for it
anymore.

 

[joe]

Why indeed some stupid parrots

My point exactly! Why do some stupid "patriots"... err, nevermind, I
mistyped. Err(!), misread. Don't you parrot me!

 

[joe]

[...]
No Unix-ish scripting language I know of (Perl, Python, AWK, etc.) is
standardized either.

The Korn shell, AWK, sed and all are standardized (ISO 9945, aka
IEEE 1003).

Besides, I don't see why that matters. C++ for example wasn't
standardized until 1998, yet its most thriving time was probably
before that.

But the standardization effort started around 1990, and it was
recognized that it would be standardized.

Have you considered becoming a "historian". A curator? You would excel at
it because you already are one(?). (Read: I wouldn't know, I'm only
turning FORTY this year).

 

[joe]

Balog Pal a écrit :

I think

All evidence to the contrary!

 

[joe]

All evidence to the contrary!

I was just razzin ya, I hope you know. I have an absurd sense of humor.
If you are new to C++ and coming from C, there's a lot to like, as C just
doesn't have enough constructs and abstraction mechanisms and is then
quite stifling. Not to start the flamewar that is "You can do OOP in C!".
When C++ is an option, I think it's the way to go rather than the limited
C, the latter which is like 4 of the crayon colors missing out of the 8
pack.