Announcement

Collapse
No announcement yet.

Leadwerks: GDB Is Annoying; Editor Using GTK

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by deanjo View Post
    When they ask for something "better" it means to have something more desirable, satisfactory, or effective then the current offering. GDB would be one such debugger offered in linux. I also highly doubt Valve would go through the trouble of improving and developing a debugger if they found the current offering good enough.
    Maybe it is a idiotic question but what do gdb lack?

    Comment


    • #32
      Originally posted by 0xDEADBEEF View Post
      - knowing about Linux is different of knowing about the many GUI for GDB (which happens to be a GNU Project not a Linux foundation one)
      This doesn't change things a bit. If the point is porting to a "Linux foundation project", I wish them luck developing a display server for that, because AFAIK none of the graphic infrastructures we use within GNU/Linux are Linux foundation's projects.

      - GDB (CLI version and the basic GUI versions that come in IDEs like codeblocks) _is_ limited when compared to VS10+ or the Intel debugger
      This doesn't change the fact he should read the manual. He IS changing IDEs, and he knows it.

      Instead of saying things that can make those guys abandon ship, support them by giving them tips on how to improve their productivity
      First, he didn't ask for support, clearly, he just assumed things won't work the way he wants. Second, he's already bound by his word and by the money he has been given for it. If he has any honor, he will continue until he's got something run-able. He is not some guy who took the work out of friendliness. Those ones, as I already said, I accept that they might sometimes skip reading the manual and I'll probably give them directions in any way I can. I will tell them they should also be reading the manual, but I won't expect it beforehand, because they are most likely not professionals (or if they are, they might actually lack time and want to squeeze every second to actually work on the code in their free time). Also, if you think we are being harmful (I do think that some criticize in a very aggressive way, but I'm not against criticism itself), then put in the place of GDB developers, who are being told they didn't do their job by someone who just 'forgot' developers should read the manual for their tools. One thing is saying it is not intuitive or that it lacks a friendly interface, but a really different thing is stating you can not inspect variables. That's a completely false statement, and one that could be considered FUD.

      Originally posted by curaga View Post
      Eh, I too find GDB to be better than VS's debugger. But I agree it's unintuitive and not too discoverable.
      For the basics I find it pretty intuitive. I forget from time to time how to check variables and I get them by trial and error. I should be reading the manual, though. But I'm too lazy and I'm not getting paid for it. Also, I'm the kind of half-assed programmer that believes if you don't see it fail, it works (well, not so much, but I do a few tests and I usually figure out what's wrong without the debugger, as I mainly worked in small projects; for bigger projects I will probably need to read the manual and do proper debugging), so I put more time in valgrind runs to check for leaks than on GDB to check for errors.

      Originally posted by deanjo View Post
      I also highly doubt Valve would go through the trouble of improving and developing a debugger if they found the current offering good enough.
      I don't. For Valve it is not the main issue what THEY find good enough, but what other developers find good enough. If they find it good enough but all of the other companies and independent developers find it too hard, Valve needs a new debugger because Steam will not be successful if the only supported games are Valve's. If 99% of developers lack the skills to read a manual, then Valve needs a dummy-proof debugger, even if their developers might find whatever is around usable enough. Of course, I don't know what their current opinion is. My point is that for Valve, it could be either.

      Comment


      • #33
        Also, his problems with drivers are mostly due to the fact Catalyst messes things up, you can't blame Linux for that. That's why I stopped using it. Kernel update and poof, Catalyst doesn't work. I uninstall it from the CLI and still not working. I don't remember how I solved it, and I don't want to, I'll stick to Radeon.

        I really don't understand what happened with his dual boot. The one time I had problems to dual boot, it was SecureBoot. Also, I feel seriously annoyed by his use of the word "driver" instead of "drive".


        On the other hand, while a lot of his criticisms are wrong, he is respectful in the way he expresses them. Some, of course, are also right.

        Comment


        • #34
          Originally posted by Akka View Post
          I'm pretty sure code::blocks use a deprecated annotation mechanism in gdb. He should really update to a modern IDE or use a standalone gdb frontend. Eclipse, Kdevelop, qtcreator or emacs is using the better modern mecanism.
          True:

          Comment


          • #35
            Originally posted by deanjo View Post
            I also highly doubt Valve would go through the trouble of improving and developing a debugger if they found the current offering good enough.
            Well, that is why I am asking. So they (want to) work on a (own?) debugger because? If they have problems with gdb, why not communicate them (to maybe even make gdb better)? I am using gdb on Linux and Windows. I'd love to hear about this problems.

            Comment


            • #36
              Seeing this bashing of GDB makes me sad. As far as I know GDB has always been superior to any other debugger in functionality. Looking up gdb at wikipedia leads to this link:
              Most time in debuggers is spent doing the same few things: setting breakpoints, stepping through code, looking at variables. Which products make those features supremely accessible and useful? We compare 13 debuggers and find out.

              it only takes a minute to realise that code:blocks has a poor implementation. Personally I like the gdb integration in kdevelop and fail to see that it is inferior to VS in any way. Note, the reviewer in the link above seems to miss the stepping toolbar in kdevelop, even though it is basically the only button toolbar visible on his screenshot. Hence, it seems to me that the only issue with gdb is lack of knowledge or willingness to learn among the developers.

              On a general note I have had a number of graduates on internships, and a number of programmers from vendors on contracts. I frequently have trouble with the crowd coming from a visual studio background. They are close to useless the first week or two, needing to be spoon-fed things they should be able to easily sort out themselves. We are talking about professional C++ programmer here, so this is something that has really puzzled me. Their fear of the command line or anything not from Microsoft is scary, and their reluctance to learn is bad enough for me to filter them away from positions these days. Hence, I expect the foolishness raised in this article to continue. The only thing that would silence this class of developers seems to be reimplementing VS down to the last detail.

              Comment


              • #37
                Originally posted by AnonymousCoward View Post

                and game developers have found this GNU debugger to be crap'

                this doesn't rhyme with this tough
                Michael is the one who stated that 'gdb is crap', meanwhile he wouldn't know a debugger from a hex editor, heck probably not even a text editor.

                The reason Michael chose to call it 'crap' is because it comes from FSF under the GNU umbrella and he has a long time vendetta against FSF, so whenever there's anything remotely negative he can spin against them or any of the software linked to them, he will do his best to blow it out of proportion.

                And just to highlight the level of bullshit from Michael, he tries very hard to portray Valve's choice of writing their own debugger as a result of gdb being 'crap', so let's hear what the developer of Valve's debugger (Michael Sartain) writes as the reason to use LLDB over gdb:

                -"I actually like (most of) gdb and use it all the time. However LLDB has a well designed multithreaded C++ interface, and I think that makes more sense to build a GUI on top of."

                And from this Micheal starts to put on his 'gdb is crap' spin, he is so far gone in his agenda driven reporting that he is downright lying (I recently caught him changing makefile optimizations to favour Clang/LLVM in the compiler comparison).

                And as for this very article, the developer in this case didn't call it crap, he said it was 'annoying' after which he then lists a couple of problems which only show that he hasn't even bothered to read the documentation when switching to a new debugger.

                Bottom line is, if you expect any sort of objective reporting on anything coming from the FSF/GNU camp, Phoronix is the wrong place. Michael has never waved from his eagerness to attack and misrepresent them or software coming from them, and I don't think he ever will.


                As for Valve's debugger ventures, they now have to cater for what is likely a long list of potential SteamOS developers coming from a Windows and as such most likely Visual Studio background.

                And if the developer in this article is anything to go by, they sure as hell aren't willing to learn a new debugger when they switch platform, so for Valve this means that they want to offer something as similar to the debugger they already use as possible in order to make the transition smooth for developers as Valve really wants them to target their SteamOS.

                Comment


                • #38
                  @XorEaxEax:
                  this was by far the best statement in this thread. thank you.

                  Comment


                  • #39
                    Originally posted by log0 View Post
                    Well, that is why I am asking. So they (want to) work on a (own?) debugger because? If they have problems with gdb, why not communicate them (to maybe even make gdb better)? I am using gdb on Linux and Windows. I'd love to hear about this problems.
                    I imagine a big factor is that they want a debugger that they can use anywhere (windows, OS X, linux, etc) without potential licensing issues like many other commercial contributors to LLVM projects.

                    Comment


                    • #40
                      Originally posted by deanjo View Post
                      I imagine a big factor is that they want a debugger that they can use anywhere (windows, OS X, linux, etc) without potential licensing issues like many other commercial contributors to LLVM projects.
                      ??

                      Just so you know, running the software doesn't lead you to *any* licensing problems, and as Valve seems willing to release their changes to LLDB, they aren't the ones wanting to close anything up. The expected users are *game* developers, so discard any modifications to GDB or LLDB coming from them, aside from Valve's work. Actually, this article leads me to think you should discard any knowledge on use of the debugger, let alone modifying it.

                      Comment

                      Working...
                      X