Author Topic: Showing vector elements in debugger  (Read 2314 times)

Offline stahta01

  • Lives here!
  • ****
  • Posts: 5899
    • My Best Post
Re: Showing vector elements in debugger
« Reply #30 on: June 24, 2017, 03:00:32 pm »
One should hope, that in the next release of c:b debugging will work.
As in the actual one (16.01) in the packaged mingw the gdb was not python enabled, but in the actual tdm package it is, with everything included that is in need.
So hopefully the devolopers of c:b will have a look that this chain will work, without having to install this and that, patching here and there.
Does this message reach them?

I see two clear solutions to nji "Problem".
1. One his proposed solution to have the next release have an gdb python enabled with what is needed to debug.
2. Stop releasing the mingw version of the CB windows installer.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Testing, compiling CB Trunk against wxWidgets 3.0.2.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline nji

  • Multiple posting newcomer
  • *
  • Posts: 24
Re: Showing vector elements in debugger
« Reply #31 on: June 24, 2017, 03:38:11 pm »
While I don't see why your option (2.) helps.

As it shifts the responsiblity for a basic working system to the user (= make it even more unconvenient).
Especially (as the experience in this thread shows) as debug-enabling is not simply done by replacing the binaries.
Even higher hurdles for potential migrants from M$/ beginners.

As the actual tdm package (with python enabled gdb) is used in the nightlys: Are there any experiences?

You set "Problem" in paranthesis.
How shall I take that?
No "Problem" for professional like you?  ;)

Offline stahta01

  • Lives here!
  • ****
  • Posts: 5899
    • My Best Post
Re: Showing vector elements in debugger
« Reply #32 on: June 24, 2017, 03:41:24 pm »
While I don't see why your option (2.) helps.

As it shifts the responsiblity for a basic working system to the user (= make it even more unconvenient).
Especially (as the experience in this thread shows) as debug-enabling is not simply done by replacing the binaries.
Even higher hurdles for potential migrants from M$/ beginners.

As the actual tdm package (with python enabled gdb) is used in the nightlys: Are there any experiences?

You set "Problem" in paranthesis.
How shall I take that?
No "Problem" for professional like you?  ;)

I do NOT use the debugger very much; so, it is no problem for me.
Maybe I should have put your name in quotes; because I meant to imply it was NOT a CB IDE problem.
But, is instead a CB MinGW packaging problem.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Testing, compiling CB Trunk against wxWidgets 3.0.2.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline nji

  • Multiple posting newcomer
  • *
  • Posts: 24
Re: Showing vector elements in debugger
« Reply #33 on: June 24, 2017, 04:16:38 pm »
As I'm quite a newbie to c:b, mingw etc. (a "M$ migrant"  ;)) I don't know how the development is organized here.
But - see the experience in the thread - to me it seems not so much a packaging problem, but a kind of configuration problem (as just replacing the debugger from the c:b 16.01package to an actual one does not work, although python enabled and included).

I do not use the debugger very much too - only in the (very very few  ;)) cases when something doesn't work as I meant it.


Offline stahta01

  • Lives here!
  • ****
  • Posts: 5899
    • My Best Post
Re: Showing vector elements in debugger
« Reply #34 on: June 24, 2017, 04:19:22 pm »
As I'm quite a newbie to c:b, mingw etc. (a "M$ migrant"  ;)) I don't know how the development is organized here.
But - see the experience in the thread - to me it seems not so much a packaging problem, but a kind of configuration problem (as just replacing the debugger from the c:b 16.01package to an actual one does not work, although python enabled and included).

I do not use the debugger very much too - only in the (very very few  ;)) cases when something doesn't work as I meant it.

Please read the CB Faqs.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Testing, compiling CB Trunk against wxWidgets 3.0.2.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline nji

  • Multiple posting newcomer
  • *
  • Posts: 24
Re: Showing vector elements in debugger
« Reply #35 on: June 24, 2017, 04:22:53 pm »
As soons as I've finished "The Three Towers".

Offline stahta01

  • Lives here!
  • ****
  • Posts: 5899
    • My Best Post
Re: Showing vector elements in debugger
« Reply #36 on: June 24, 2017, 04:36:03 pm »
As soons as I've finished "The Three Towers".

I am going to ignore you from now on as a waste of time.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Testing, compiling CB Trunk against wxWidgets 3.0.2.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline nji

  • Multiple posting newcomer
  • *
  • Posts: 24
Re: Showing vector elements in debugger
« Reply #37 on: June 24, 2017, 05:11:01 pm »
What a pity for you.  :)

So you will never understand why to point blanket to the FAQ isn't very sensible after I explained in detail.

But maybe you're right ... it looks to be a "waste of time" with you.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 5899
    • My Best Post
Re: Showing vector elements in debugger
« Reply #38 on: June 24, 2017, 06:22:06 pm »
What a pity for you.  :)

So you will never understand why to point blanket to the FAQ isn't very sensible after I explained in detail.

But maybe you're right ... it looks to be a "waste of time" with you.

Please read the rules before you are banned!
http://forums.codeblocks.org/index.php/topic,9996.0.html
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Testing, compiling CB Trunk against wxWidgets 3.0.2.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline nji

  • Multiple posting newcomer
  • *
  • Posts: 24
Re: Showing vector elements in debugger
« Reply #39 on: June 24, 2017, 06:39:05 pm »
Banned?  :-\

Will you come with me?



Usually I don't explain my points ...
But for you I will do an exception:
Yes, I will take you for serious ...
... as soon as you do mature.
I always tried to explain/ to give reason for what I wrote above.
I can't imagine of anything more revealing weakness than the threat of a bann.
Oh man ...
« Last Edit: June 24, 2017, 06:53:58 pm by nji »

Offline sodev

  • Multiple posting newcomer
  • *
  • Posts: 95
Re: Showing vector elements in debugger
« Reply #40 on: June 24, 2017, 07:23:00 pm »
CodeBlocks is not a compiler, its "just" an IDE, not like Visual Studio that is both. And its not the only one like that, take a look at Eclipse, Netbeans, i dont think they even have packages that include a compiler.

Personally i never downloaded a CodeBlocks package including a compiler, i havent downloaded a CodeBlocks since years actually because i compile it myself from svn. So i dont mind if they drop these packages at all if it helps to stop codecompletion from stopping to work as soon as i type auto.

But im not a cool kid from school anymore, im not coding in cool languages that dont need uncool shit like a compiler, so i might be a little outdated how cool coding works today. Do i still need a keyboard?

Offline nji

  • Multiple posting newcomer
  • *
  • Posts: 24
Re: Showing vector elements in debugger
« Reply #41 on: June 24, 2017, 07:37:48 pm »
I fear I'm spoiled by all my M$ years.

Maybe I too should try to get used to do what I called the amish way.
(Which wasn't meant derogative for the Amish at all. Just the opposite.)

But, as I pointed out quite often in this thread, if non-commercial development will have a chance it has to become convenient to use.
The long-year insiders don't seem to understand that.

Offline BlueHazzard

  • Lives here!
  • ****
  • Posts: 1466
Re: Showing vector elements in debugger
« Reply #42 on: June 25, 2017, 12:44:15 am »
I honestly don't want to discuss this any future...
Just to make some points clear: I to have the opinion that codeblocks should ship as a full functional build environment with enabled debugger ecc. But this will not happen soon...

@nji
You have to understand, that codeblocks is just a IDE. Codeblocks can be used with gdb as debugger or with cdb as debugger
Codeblocks can be used with gcc compiler or with visual studio compiler or with borland compiler ecc...
Codeblocks can be used on windows, mac or linux

Codeblocks can not provide a distribution for any possible combination. Some user uses a older gdb someone uses a newer gdb, someone with c++ someone with fortran ecc.

The philosophy is not to provide a full development environment (like visual studio), but a pretty good text editor with the possibility to integrate other tools (like gdb and gcc), not provide support or help for this tools (but provide support for the integration). GDB and GCC are separate projects. And they need also other separate projects like python. Everyone does what they can and relate to the other project for support. M$ does not use this philosophy because they have everything in house (visual studio ide, visual studio compiler, M$ basic as scripting ecc.), but they are a $$$$M Dollar cooperation and not 5 developer that do this in their free time.
 Python makes a good scripting engine so gdb decides to use it in his project. Now gdb has a dependency to python, but has not the responsibility to provide a binary. On linux the resolving of this dependencys is no problem, because it uses a packet manager that resolves this problems for you. On windows you have to do this by your hand (don't blame codeblocks for this, because it is not the responsibility of codeblocks to resolve installation dependencys).

You try to use a feature that is not present in this release of CB.
I think i provided you with enough support to integrate it on your system (and i am willing to help you even more, until we have all steps together to make a nice tutorial for other people, this is the way how open source work, all cooperate and help to resolve problems). If you are not willing to resolve the dependency i feel a bit fooled for all the time i invested to help you, but this is ok, it was my decision...

Even more OT: All in all this work in resolving problems and using a old stylish IDE looks uncool for young people (i am <<30, so i count me as young). Young people use cool things like electron and java script. But the result of this cool things is bullshit. A telephony application (i look at you discord) that needs 170MB Installation, 146MB RAM and constantly 0.4% cpu on idle versus a uncool old in c and c++ written qTOX that uses 50MB RAM 0% cpu and 60MB installation, and if you use a even more uncool TOX you only need 5MB of RAM and all this uncool tools can better telephone then discord...

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5012
Re: Showing vector elements in debugger
« Reply #43 on: June 25, 2017, 09:42:01 am »
    Dear all.

    please keep  calm and continue debugging ;-)

    You know, everyone here is right with fair remarks, but we are all wrong too.

    Most important, we develop CB, aka an IDE, that means, not the compiler, not the debugger. BUT ... ( I will come to the but shortly). For
convenience on windows we ship the MinGw package (which is a port of gcc, but it brings also problems), as mentioned we could switch too TDM. However it seems TDM John" is unreachable (which probably means he is busy with other things) and the TDM package is also getting outdated (it is at gcc 5.1.0), so it seems we might loose this option too (note that this is the compiler we use to build the nightly builds).

Let me first explain how I use CB, I always build it from svn, and I use it on linux (I boot up windows for 2 things, installing a game (and with some luck even play that game), and building nightlies). As such on linux I have to install the compiler, debugger myself, which is very easy to do (upgrading a compiler however is not).
I also sometimes get lost with the "enable scripts" versus do not enable the scripts but have a gdb-python pair.
And yes me too, I hardly need a debugger.
It is a pity indeed that gdb does not have such things build in (I myself can get angry on that, but I will spare you my rant).

FIRST CONCLUSION : many people have asked about this, so I think it deserves a link on our homepage to an up to date dedicated page on our wiki. Where everything is clearly explained on how to do it (with example of code snippets/programs, so the reader can verify he gets similar results).

SECOND CONCLUSION : we need to start deciding what "convenience" package to ship in the next release.

Now let me address the BUT. The customer is always right! As good as our CB is, what counts is the user experience, no discussion about that, period. We can point to windows, gdb, python whatsoever. We need to at least propose a "recipe" to get to a good user experience (and we can do such thing a little bit with our convenience package. The user use the IDE for 2 things at minimum:
  • write code
  • debug code

The fact that the user used to have an expensive MS Visual Studio is a non argument. It is not the MSVS user experience that counts in this discussion it is OUR CB experience that matters.
It is the total user experience that counts, and will make a happy user, or aan user which decides to drop CB and look further.
Imagine you have a nice app on your phone, but the backend it talks too really sucks, no matter how nice and shiny and performant that app might be (even assume it is bug free), the experience will be crap due to that backend, and the user will drop it and look for other alternatives.

I have been evangelizing CB a lot in the past, I still do, but I an giving fair information, because if I do not from the start, in the end I end up like a fool, and let me tell you why, again it is all about user experience, and these areas where I have to say upfront the state  of the functionality (or lack of current state) are in order of what I have see from people complaining or in the end not willing to use CB (despite of all the other great features it has):

  • code completion      <== we loose big time here wrt competition
  • refactoring
  • debugger

As long as the first 2 are in the current state, I noticed it is nearly impossible to convince for example an Eclipse user to even consider CB :-(
And yes I could try to improve it myself, but our current completion engine is dead, it can not solve the problems anymore, we need a different approach, and we have someone kindly working on an alternative one, and I am thinking of having a nightly (separate) build with it, so we can have more feedback, but even then it is 1 person at this moment so his time is also limited.
So yes the more people who can help out, test, provide patches, would be very nice. That's the good thing about open source, but it is also the downside, if nearly nobody steps up to help out things start to go slower and slower. And I have to pleed guilty myself, I still get up to the project management part of CB, the nightly builds but my commits have also been very low the last 2 years, because my spare time is a scarce resource.

So to all, please be constructive, though your statements might all be 100% correct, we need to aim for a good user experience, and try to bring that, not by saying we are only this, or that is not our problem. We need to look at the bigger picture.

PROPOSAL:
- this thread consists out of many suggestions, let's try them out
- use a nightly build and install TDM-GCC 5.1.0 package
- install python
- verify if it works
- let's discuss the problems in a positive way
- so we can end up with hopefully a working solution
- document the solution and give it a clear spot on our homepage
- in case we end up with a good result, as far as I am concerned (but I can't decide on just by myself) this could be the trigger for a new release (based upon whatever convenience package we end up with)
So I would like to kindly ask our OP to help out (I think you did not want to install python, in that case I am afraid there will be no solution, so please reconsider, pretty please), so some of the burden will be on your shoulders, but if it works out, I can tell you, you will feel happy and proud and that open source feeling.
And I promise that I will boot up my windows machine and try the same code snippets out myself, so we can share our findings, our frustrations, but we will turn them into something positive.

Please , let's work together, we are all right, but NOW LET'S IMPROVE THE USER EXPERIENCE.
Sorry for shouting ;-)

PS : let's not start a code completion discussion here, let's focus on getting e better debugging experience by bundling all the good things we have.[/list]
« Last Edit: June 25, 2017, 04:59:03 pm by killerbot »

Offline nji

  • Multiple posting newcomer
  • *
  • Posts: 24
Re: Showing vector elements in debugger
« Reply #44 on: June 25, 2017, 11:36:54 am »
First of all:
It was not my intend to offend anyone.
As a matter of fact I am grateful to those who are the reason that there exists
this fine independent alternative to $$.
Thank you for that indeed.  :)
Being a M$-migrant all I can contribute so far is the experience "one" does
if one comes from that way. Deterrent, pleasant, ...
I didn't "give way" because I wanted to contribute just that.
Again: I didn't want to annoy anyone.

I'm sorry to have to disappoint you (asked to please reconsider) to install python.
I really have a reluctance to install more scripting ability to my system.
A potiential gate for anything ... that I don't need at all.
(Maybe I should mention that first thing I did after installation of Win7 was
to turn off every unwanted services, deinstall certain windows components,
closed all holes etc.).

But this way debugging works (more or less):
If one substitutes the gdb binaries (and probably nescessary sub folders etc.)
with the newer tdm gcc 7.9.1. (http://sourceforge.net/projects/tdm-gcc/files/GDB/gdb32-7.9.1-tdm-1.zip/download),
along with activating the scripts in cb's debugger config (see description above)
then it works ... nearly. (You can see the vector and the unfolding of its members,
but you can't watch a special index directly - test[42]).
So there is something wrong somewhere.

If with next release of cb it comes to the decision to drop mingw support
and to leave it for the windows user too to install compiler (and to manage
the adaption) I probably will stay with c:b (As there are reasons why I did't
decide for the other free options).
But probably cb will put off potential windows migrants and leave them in the arms
of the convenient $$-octopus.

[Edit:

Even more OT: ... that needs 170MB Installation, 146MB RAM and constantly 0.4% cpu on idle versus a uncool old in c and c++ written qTOX that uses 50MB RAM 0% cpu and 60MB installation...
100% agree.
But to my experience (as M$-migrant, did I mention?) also in "here":
Using wxWidgets produces a minimal size of several MB, while a typical
(not too simple) application of mine using MFC are only few 100kB.
"Nobody sane cares about that" was the answer I got in a forum.
Or - maybe a more subtle example - as I wanted to change from MFC
containers to modern standard lib ones, and discovered what kind of
absurd pull ups you have to do if you want to avoid unnecessary initialization.]

« Last Edit: June 25, 2017, 12:49:27 pm by nji »