Development plans

[PaulFreund]

First, thanks for all your development tools for D, it's a pleasure working with them.

I know this is not really an issue, but I think this place fits my question best. I really like to use Monodevelop on Windows to develop D applications and I also like having a visual debugger. This add-in works, but it has it's quirks.

As the last commit was 7 months ago I'd like to ask if you plan to pickup work on this or if you want to got a different route or drop visual debugging on windows completely.

I can't promise anything but I could probably invest some time improving/working on this, especially on things I come across while working with it.

[aBothe]

atm its development has been suspended due to VisualD's debugging abilities - so two debugging environments aren't really necessary imho. Furthermore I'm not developing on Windows primarily anymore aand don't have so much time for developing all my projects so intensively anymore :)

If you want to go on with development, feel free to do so - I even could grant you push rights if you plan to work on it way more frequently.

[PaulFreund]

Sounds very reasonable. My main reason for MonoDevelop on Windows is the idea to build a development sdk which should work on all platforms (and VisualD can't provide that).

Im curious if you or somebody else tried to port the gdb based linux debugger to windows. I don't think that should be that much of a problem especially with tools like cygwin, but I also know there can be a lot of issues that are not visible on the first glance.

I just started working with D and at the moment the debugger works with a few exceptions ( for example exception catching and displaying). How many/which features would you consider missing/incomplete at this point? ( if you remember)

[michaelc37]

I also prefer to use monodevelop on windows instead of visual studio (imo it feels more responsive, and easy to use).
I still use it today for simple debugging, then switch over to visual studio for more complicated stuff.
Last time i was working on this, i was trying to integrate an assembly dump into the ide (via https://github.com/aBothe/MagoWrapper) but i came across some roadblocks that i couldn't overcome (my debugging internals knowledge is quite limited).

It would be great if you can help improve this plugin and or the MagoWrapper plugin.
I started to loose motivation to improve it as i thought i was the only one using it (especially since visual studio is so popular, and now has free editions).

[aBothe]

There already is a released gdb.d addin for linux & probably mac :) - https://github.com/llucenic/MonoDevelop.Debugger.Gdb.D
I've built the base architecture for this addin but got tired of improving it recently.

Putting in exception catches shouldn't be that hard because I found out which function (offset) gets called when there's no catch block available..it's also built into the gdb addin for windows xD -- but yeah, you somehow can't use the gdb debugger on windows :(

[PaulFreund]

I don't really know but it seems to me that a lot of people on linux rely on MonoDevelop.Debugger.Gdb.D. Probably there could be a way to make it run on windows (probably with the help of mingw).

This would have the benefit that all platforms rely on one codebase and there is less fragmentation. I think before thinking about improving monodevelop-win32-debugger I'll look into this matter.

[aBothe]

Well, I actually did try this on windows a couple of..months/years?..ago, but iirc some people mentioned that it was not possible to debug dmd-built executables with gdb - So before touching anything I'd rather ask if it's still impossible or whether there are some ways of getting this done now.

[PaulFreund]

Very good pointer, I didn't even think of this... I'll ask/try around a little bit. Thanks for your help!

[PaulFreund]

You were right, it seems it's still not possible (or I overlooked something) and it might introduce more problems than it solves. I hoped for a consistant experience across all platforms but I doubt that will be possible in the near future (without a lot of work). Not sure how I will continue now, but I'll let you know if there are any updates.

[aBothe]

What could be done atm is to just give the addin an update regarding the obviously outdated API and perhaps locals resolution - and stack examination, and exception handling..especially the latter can be done way more easy than under Linux due to the Win32 EH architecture WHEREAS dmd64 also has gotten its own EH now - featuring custom handler tables etc.
I've managed to inject a breakpoint at the end of __eh_finddata though, so in the case there's an uncatched exception thrown, that breakpoint will be caught - and the user is then given a chance to examine the stack and locals' contents.
See https://github.com/llucenic/MonoDevelop.Debugger.Gdb.D/blob/master/Gdb.D/Deh2.cs for the actual implementation