On 2013-06-13 21:39, Peter Alexander wrote:

> The debugger is the #1 feature I'd miss from my day job if I didn't use
> Visual Studio. Feature wise, I'm sure gdb has most if not all VS has,
> but in VS everything is just there in front of you, easily usable (you
> don't need to consult the manual, or remember archaic commands). Using
> gdb vs. Visual Studio feels like trying to do web browsing via the
> command line.

LLDB uses a far more consistent and logical structured commands than GDB. Although it doesn't support D.

-- 
/Jacob Carlborg

On 2013-06-14 07:48, Johannes Pfau wrote:

> Can the visual studio debugger show the contents of registers? I found
> this quite useful when debugging unit test failures related to floating
> point code in gdc. info float shows the contents of the floating point
> stack, status register and control register.
>
> I know gdb is scriptable with python but I never used that.
> Batch execution of commands is especially nice when used with dustmite
> (https://github.com/CyberShadow/DustMite/wiki/Detecting-a-specific-segfault).

LLDB is pretty advanced as well. The biggest benefit there is the integration with the compiler. I've watched some of the WWDC videos and you can do pretty cool stuff.

-- 
/Jacob Carlborg

On 2013-06-13 16:44, Leandro Lucarella wrote:

> I've always use VIM without any problems. Is not what you typically call
> an IDE though. I think now some of "our guys" are using Geany moderately
> successfully, for sure much better than Ecplise and Mono plugins. IIRC,
> the main problem with those huge IDEs were memory usage and death-files
> (files that made the IDE crash consistently).
>
> I think there a lot of working advanced editors for D, but IDEs are
> quite behind (at least in Linux).

I agree. But he said at the end of the talk that he didn't want codecompletion refactoring or anything like that. Now he said he just wants something better than Notepad that is stable. If that's your requirements then you don't need an IDE, just an editor with syntax highlighting for D.

-- 
/Jacob Carlborg

On Thursday, 13 June 2013 at 22:30:25 UTC, Peter Alexander wrote:
> On Thursday, 13 June 2013 at 20:19:06 UTC, Jonathan M Davis wrote:
>> The differences between a graphical debugger and gdb are fairly interesting in
>> that all the basic stuff is just way easier and more pleasant in a graphical
>> debugger, but gdb has all kinds of advanced stuff that tends to blow graphical
>> debuggers out of the water in terms of power.
>
> What can gdb do in particular that Visual Studio can't?
>
> Not trying to troll, I'm genuinely curious. I googled for advanced gdb tricks to try and find some of the more advanced stuff, but it was all simple things that Visual Studio does (printing variables, disassembling, casting memory to arbitrary types, pretty printing STL containers, conditional/data breakpoints, running commands on hit breakpoints etc.)

The only thing that GDB can do that Visual Studio does not offer is a REPL like environment for C and C++ code. Visual Studio immediate window only supports managed languages properly.

Everything else, VS wins hands down, specially when debugging data structures (thanks to visualizers) or multithreading/parallel code.

--
Paulo

On Friday, 14 June 2013 at 06:49:08 UTC, Jacob Carlborg wrote:
> On 2013-06-13 16:44, Leandro Lucarella wrote:
>
>> I've always use VIM without any problems. Is not what you typically call
>> an IDE though. I think now some of "our guys" are using Geany moderately
>> successfully, for sure much better than Ecplise and Mono plugins. IIRC,
>> the main problem with those huge IDEs were memory usage and death-files
>> (files that made the IDE crash consistently).
>>
>> I think there a lot of working advanced editors for D, but IDEs are
>> quite behind (at least in Linux).
>
> I agree. But he said at the end of the talk that he didn't want codecompletion refactoring or anything like that. Now he said he just wants something better than Notepad that is stable.

I don't know what's going on here, somehow people are consistently misunderstanding me.

The question in the talk was along the lines of "what's wrong with D's IDEs". And people expected the problem was that they don't have good refactoring support or something. But the problem is much more severe:
 Mono-D is not as good as Notepad.
 EclipseD is not as good as Notepad.
Because they are unstable.

On Thursday, 13 June 2013 at 22:30:25 UTC, Peter Alexander wrote:
> What can gdb do in particular that Visual Studio can't?
>
> Not trying to troll, I'm genuinely curious. I googled for advanced gdb tricks to try and find some of the more advanced stuff, but it was all simple things that Visual Studio does (printing variables, disassembling, casting memory to arbitrary types, pretty printing STL containers, conditional/data breakpoints, running commands on hit breakpoints etc.)

Does Visual Studio debugger have some sort of scripts/macros? When I was in a small kernel dev related team, we had a lot of own utility macros for gdb to help debug kernel core dumps, especially for messy cases like stack corruption.

Have finally watched it. Great talk and good jokes! :)

One topic I'd like to hear more about is memory management techniques. It was told that only very small amount of garbage is generated and managed by GC, most code avoids heap allocations at all. Is this somehow enforced (tooling, code review, etc.) or simply judged by a common sense? Is keeping such restriction easier in D1 than in D2?

On Friday, 14 June 2013 at 05:48:17 UTC, Johannes Pfau wrote:
> Am Fri, 14 Jun 2013 00:30:24 +0200
> schrieb "Peter Alexander" <peter.alexander.au@gmail.com>:
>> What can gdb do in particular that Visual Studio can't?
>
> Can the visual studio debugger show the contents of registers?

Yes, Debug->Windows->Registers. A window with all the register values in it.

On Friday, 14 June 2013 at 07:40:55 UTC, Dicebot wrote:
> Does Visual Studio debugger have some sort of scripts/macros? When I was in a small kernel dev related team, we had a lot of own utility macros for gdb to help debug kernel core dumps, especially for messy cases like stack corruption.

Yeah, you can script VS, although I haven't used it.

On 6/13/2013 11:40 PM, Jacob Carlborg wrote:
> On 2013-06-13 22:42, Walter Bright wrote:
>
>> May I present MicroEmacs:
>>
>> https://github.com/DigitalMars/med
>
> Only Linux and Windows support?

Others are trivially added if anyone cares.