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 log0 View Post
    From what I see, there is not a single line mentioning GDB in all these links.
    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.

    Comment


    • #32
      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


      • #33
        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


        • #34
          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


          • #35
            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:

            https://sourceware.org/gdb/wiki/GDB%20Front%20Ends

            Comment


            • #36
              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


              • #37
                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:
                http://www.drdobbs.com/testing/13-li...ewed/240156817
                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


                • #38
                  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


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

                    Comment


                    • #40
                      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


                      • #41
                        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


                        • #42
                          Sorry, these sources are useless. All of them describe how Valve is working on LLDB, in the first blog post you linked the author himself even admitted that he quite likes gdb as a standalone program, but that its programming interface is lacking. The only other minuscule "lead" that I was able to find was Valve's statement of how "other game companies often tell them to build a debugger". Hm, I wonder who these "developers" are. Very likely Windows game devs, don't you agree? And what are Windows developers used to? Doing everything from a GUI, ie. integrated debugger in their IDEs. Nowhere did anybody say "GDB sucks, please create a replacement". No, they said "please create a debugger" as if it didn't even exist, leading me to believe that what they're really asking Valve is to build a good graphical debugger. And guess what's very convenient for that? A debugger with a good programming interface. And this is exactly where LLDB shines, because unlike GDB it is very new, based on a modular architecture and thus makes the programming interface part a much easier experience. That is all, nobody is saying "GDB as a standalone debugger is crap".

                          Comment


                          • #43
                            Personally, I've had various problems with different versions of GDB, including seg faults and some strange behaviour from time to time, specially in multithreaded programs. Despire this I've managed to get the job done, but have ocasionally looked for alternatives; reliability is not an option when it comes to system tools.

                            Comment


                            • #44
                              Originally posted by Ancurio View Post
                              Got any sources for that lovely bit of FUD there, Michael?
                              That’s about what I wanted to ask - given that it is also completely misrepresenting the dev (Josh Klint). The full quote is:

                              In the meantime, the limitations of GDB are annoying, but I can deal with it.
                              This does not sound like crap, but rather like small annoyances - which as others in this thread showed are mostly a matter of learning a different style.

                              Comment


                              • #45
                                Originally posted by mrugiero View Post
                                ¿?

                                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.
                                They may however want to include a modified version for potential engine customers (complete with toolchain) and that is where licensing can become hairy if they do not want to have those improvements/changes made open.

                                Comment

                                Working...
                                X