On 14 July 2014 15:15, Manu via Digitalmars-d-announce <[email protected]> wrote: > On 14 July 2014 21:14, Iain Buclaw via Digitalmars-d-announce > <[email protected]> wrote: >> >> On 14 July 2014 07:22, Manu via Digitalmars-d-announce >> <[email protected]> wrote: >> > On 14 July 2014 15:58, Iain Buclaw via Digitalmars-d-announce >> > <[email protected]> wrote: >> >> >> >> On 14 July 2014 06:19, Manu via Digitalmars-d-announce >> >> <[email protected]> wrote: >> >> > I finally watched it (I failed to survive the long over-nighters >> >> > until >> >> > 10am >> >> > to watch this one live >_<). >> >> > >> >> > I want to offer congratulation and thanks to Iain for this work! >> >> > For me, this is perhaps the single most important work in the D >> >> > ecosystem >> >> > yet this year, and for me, I think the debugging environment remains >> >> > the >> >> > single most significant hurdle to confident and practical adoption of >> >> > D >> >> > in >> >> > industry. >> >> > >> >> >> >> Thanks Manu. I guess I'll be having trouble finding the next most >> >> important work in the D ecosystem next year. ;) >> > >> > >> > I think you've probably earned a break ;) >> > >> > >> >> > It brings me to the interesting realisation (which I already knew, I >> >> > have >> >> > just been denying), that for D to proceed on Windows, MSVC will have >> >> > to >> >> > go... and I don't know how to go about this :/ >> >> > MS's debugger will presumably never support these features, but the >> >> > de >> >> > facto >> >> > Windows toolchain emit's PDB for use with the MS tools. I wonder if >> >> > there >> >> > are competing debuggers that support PDB which could support >> >> > unofficial >> >> > extensions to PDB which may express D better? >> >> > >> >> >> >> Zerobugs was aimed at D users back when it was a commercial product. >> >> It has since been released under a boost licensed for a couple years >> >> now, but has into gone into obscurity (I think?). >> >> >> >> Link: http://zerobugs.codeplex.com >> >> Couple of clones on github too: https://github.com/search?q=zerobugs >> >> >> >> Being written against GTK, it's UI should be cross-platform to >> >> Windows, so it *could* be a good base project to start from, then >> >> build Windows debugging support into it. Someone else will need to do >> >> initial reviewing and triaging of this stuff (we need a new >> >> Lieutenant!) >> > >> > >> > On the back of your work, what advantage would that debugger have over >> > established and more refined tools? >> >> I've never used zerobugs, but it looked interesting a few years back, >> but didn't think it worth the money (actually, I seldom purchase >> software) in comparison to FOSS. >> >> >> > What would a 'D debugger' have to offer when the debug backend >> > understands D >> > internally, and can even handle D expression evaluation? >> > >> >> I think the experience is simply more natural to the end user. You >> code in D, you debug in D. I do it all the time for C++ when I'm >> probing for a problem in gdc. Copying a line of code and pasting it >> into the command prompt, checking the result. It's one of these >> features that I never noticed until I started doing this work in gdb. >> *Then* I realised that I would have to implement a ground-up >> interpreter for D. > > > Okay, so I'm confused. You said you're working on an expression parser for D > right? Assuming that is present, why would a D-specific debugger have any > advantage over an existing debugger with your GDC? > Or is the point that zerobugs already rolls its own debugger which has an > expression parser? > >> Luckily GDB has awesome support for many language concepts, both in >> functional and procedural languages. So most of the work was just >> extending existing opcodes to behave in a D-like manor. ;-) >
Zerobugs rolls its own debugger, its only strength vs GDB is that being separate from the GNU toolchain, it may be more friendly to getting in PDB/MSVC support, for instance. > Right. > Do you know about LLDB? I presume it'll be equally competent? > I don't see that GDC/GDB will ever be useful in the Windows environment due > to incompatible object and debug formats, but LLVM are making the push for > full MSVC compatibility. With that, you should be able to (finally!) use > Clang(/LDC) in place of MSVC, so then we're left with the debug > environment... If LLVM are making a commitment to producing Microsoft object > and debug output, it stands to reason that LLDB will support them too? I haven't looked at LLDB I'm afraid, so I can't comment.
