Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 15/07/2014 02:59, Manu via Digitalmars-d-announce wrote: I have had problems with the linker when trying to link GDC and MSC objects together. You lose the debug info for one or the other world. You can't have dwarf and cv8/pdb together. And to be useful, there would need to be some visual studio integration for dwarf debugging :/ Linking problems aside, if GDC on Windows produces proper DWARF debug info, you can debug the GDC compiled code with GDB and a graphical frontend such as DDT+CDT, you don't need Visual Studio. But, like you said, the Windows/MingW port of GDC is not maintained so it's all just theoretical as things stand. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
Am Tue, 15 Jul 2014 11:59:42 +1000 schrieb Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: On 15 July 2014 00:32, Johannes Pfau via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Am Tue, 15 Jul 2014 00:15:01 +1000 schrieb Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: 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. Can you provide some more details about this? MinGW uses the standard PE object format, afaik. GCC-4.9 also supports SEH exceptions (on 64 bit, not sure about 32). The mingw 'runtime' is a small layer on top of the microsoft runtime, to provide C99 functions and similar stuff. I don't think that should be a problem. http://clang.llvm.org/docs/MSVCCompatibility.html They emit line numbers so far apparently. But I understand the intent is to properly populate the object with cv8 debug data. The linker takes care of generating the pdb file. So, are you saying that GDC binaries will link successfully against the mscrt suite? I've used it in the past, and it never wanted to link against the ms libs. In addition, when I did try and link C and D code together, I got loads of CRT conflicts when trying to link glibc and mscrt together. There's no glibc on windows, mingw links to msvcrt.dll. I think MS toolchains link to msvcr110.dll, but it's also possible to make mingw link against msvcr110.dll. I didn't try to link mingw/msvc object files yet, but according to some mingw discussions it should work. C DLLs should always work. (That's only for C, C++ mingw/msvc are not compatible). I believe the goal for LLVM is to target the same runtime as MSC does, otherwise you're just asking for link trouble. The pdb debug format is not supported, AFAIK. But that format is not documented and I don't think you could add D extensions anyway. So does LLVM really support PDB? The linker outputs the pdb file, the objects are populated with cv8. Can GCC write cv8 output? No it can't. cv2pdb claims to support converting from dwarf-pdb but I never tried that. MinGW can use dwarf debug info on windows and I guess you get all benefits of Iain's gdb work on windows. It is annoying if you get crashes in the microsoft C runtime or any other library compiled with microsoft tools though, as there's no dwarf debug info for these. I have had problems with the linker when trying to link GDC and MSC objects together. You lose the debug info for one or the other world. You can't have dwarf and cv8/pdb together. And to be useful, there would need to be some visual studio integration for dwarf debugging :/ So overall I don't see why mingw should work fine on windows. Of course there's less incentive for GCC devs to support windows, but I doubt that's different for LLVM. I think there would be plenty of incentive if it worked. I haven't tried it out for a while. I'll give it a whirl and see what's changed, but while the dwarf/cv8 conflict remains, I can't see it being a practical solution. I guess getting dwarf and cv8 to work together is almost impossible. There's also nobody working actively on the MinGW gdc port right now, afaik. We don't even know the test suite results for mingw. So if you want to contribute... This has indeed been my biggest issue with GDC in the past.
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 15.07.2014 04:02, Manu via Digitalmars-d-announce wrote: On 15 July 2014 04:27, Rainer Schuetze via Digitalmars-d-announce digitalmars-d-announce@puremagic.com mailto:digitalmars-d-announce@puremagic.com wrote: On 14.07.2014 08:22, Manu via Digitalmars-d-announce wrote: There are alternative tools available for windows too, but I think the key for Windows developers remains proper integration into Visual Studio, and PDB support. I guess the biggest hurdle there is integrating D concepts info into MS's proprietary PDB format. Expressing debug info like C really won't get us the full mile. Rainer bundles Mago with VisualD. I wonder what that's doing lately... Aldo has put a lot of work in extending mago to 64-bit. I guess the next version of Visual D will come with it. Mago had D expression evaluation from the start, showing associative array elements was added a bit later. Have you tried it out? How does it deal with some of the cases Iain brought up; enum's, globals/statics, tls, etc. It works, but not to the extend as described by Iain. Some of the issues need compiler support, like name symbol lookup through imports. IIRC unqualified globals/statics only work within the scope of their declaration (e.g. function statics), TLS should be ok.
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 15.07.2014 04:35, Manu via Digitalmars-d-announce wrote: On 15 July 2014 04:27, Rainer Schuetze via Digitalmars-d-announce digitalmars-d-announce@puremagic.com mailto:digitalmars-d-announce@puremagic.com wrote: On 14.07.2014 08:22, Manu via Digitalmars-d-announce wrote: There are alternative tools available for windows too, but I think the key for Windows developers remains proper integration into Visual Studio, and PDB support. I guess the biggest hurdle there is integrating D concepts info into MS's proprietary PDB format. Expressing debug info like C really won't get us the full mile. Rainer bundles Mago with VisualD. I wonder what that's doing lately... Aldo has put a lot of work in extending mago to 64-bit. I guess the next version of Visual D will come with it. Does that mean it's working? Yes, it might have a few quirks left, though. It's very hard to tell from the project website. TBH, I actually thought Mago was a dead project for years because the last activity on the website looks like 2012. If you check the mago64 branch, it shows activity about 2 months ago. He should consider moving to github, then we can have some visibility. Mago had D expression evaluation from the start, showing associative array elements was added a bit later.
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 11.07.2014 20:15, Iain Buclaw via Digitalmars-d-announce wrote: On 11 July 2014 16:48, Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Upvote!! http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/ https://www.facebook.com/dlang.org/posts/882826745064341 https://twitter.com/D_Programming/status/487623887187083264 Andrei Thanks for spelling my name right this year. :) Very impressive work, Iain. One comment about Visual D and MinGW: Visual D uses cv2pdb to convert both CodeView4 and DWARF debug info to PDB, so you can debug programs built with the MinGW tool chain and GDC inside Visual D. TBH I have not used it that much, Manu will probably have more experience with it.
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 14 July 2014 15:58, Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 06:19, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com 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? What would a 'D debugger' have to offer when the debug backend understands D internally, and can even handle D expression evaluation? There are alternative tools available for windows too, but I think the key for Windows developers remains proper integration into Visual Studio, and PDB support. I guess the biggest hurdle there is integrating D concepts info into MS's proprietary PDB format. Expressing debug info like C really won't get us the full mile. Rainer bundles Mago with VisualD. I wonder what that's doing lately...
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 14 July 2014 07:22, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 15:58, Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 06:19, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com 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. 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. ;-) Iain.
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 14 July 2014 21:14, Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 07:22, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 15:58, Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 06:19, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com 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. ;-) 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?
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 14 July 2014 15:15, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 21:14, Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 07:22, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 15:58, Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 06:19, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com 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.
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
Am Tue, 15 Jul 2014 00:15:01 +1000 schrieb Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: 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. Can you provide some more details about this? MinGW uses the standard PE object format, afaik. GCC-4.9 also supports SEH exceptions (on 64 bit, not sure about 32). The mingw 'runtime' is a small layer on top of the microsoft runtime, to provide C99 functions and similar stuff. I don't think that should be a problem. The pdb debug format is not supported, AFAIK. But that format is not documented and I don't think you could add D extensions anyway. So does LLVM really support PDB? MinGW can use dwarf debug info on windows and I guess you get all benefits of Iain's gdb work on windows. It is annoying if you get crashes in the microsoft C runtime or any other library compiled with microsoft tools though, as there's no dwarf debug info for these. So overall I don't see why mingw should work fine on windows. Of course there's less incentive for GCC devs to support windows, but I doubt that's different for LLVM. There's also nobody working actively on the MinGW gdc port right now, afaik. We don't even know the test suite results for mingw. So if you want to contribute...
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 14.07.2014 08:22, Manu via Digitalmars-d-announce wrote: There are alternative tools available for windows too, but I think the key for Windows developers remains proper integration into Visual Studio, and PDB support. I guess the biggest hurdle there is integrating D concepts info into MS's proprietary PDB format. Expressing debug info like C really won't get us the full mile. Rainer bundles Mago with VisualD. I wonder what that's doing lately... Aldo has put a lot of work in extending mago to 64-bit. I guess the next version of Visual D will come with it. Mago had D expression evaluation from the start, showing associative array elements was added a bit later.
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
The pdb debug format is not supported, AFAIK. But that format is not documented and I don't think you could add D extensions anyway. So does LLVM really support PDB? As long as they rely on the MS linker they only need to emit proper debug info into the object files. But that's still TODO: http://clang.llvm.org/docs/MSVCCompatibility.html#abi-features
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 15 July 2014 00:32, Johannes Pfau via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Am Tue, 15 Jul 2014 00:15:01 +1000 schrieb Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: 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. Can you provide some more details about this? MinGW uses the standard PE object format, afaik. GCC-4.9 also supports SEH exceptions (on 64 bit, not sure about 32). The mingw 'runtime' is a small layer on top of the microsoft runtime, to provide C99 functions and similar stuff. I don't think that should be a problem. http://clang.llvm.org/docs/MSVCCompatibility.html They emit line numbers so far apparently. But I understand the intent is to properly populate the object with cv8 debug data. The linker takes care of generating the pdb file. So, are you saying that GDC binaries will link successfully against the mscrt suite? I've used it in the past, and it never wanted to link against the ms libs. In addition, when I did try and link C and D code together, I got loads of CRT conflicts when trying to link glibc and mscrt together. I believe the goal for LLVM is to target the same runtime as MSC does, otherwise you're just asking for link trouble. The pdb debug format is not supported, AFAIK. But that format is not documented and I don't think you could add D extensions anyway. So does LLVM really support PDB? The linker outputs the pdb file, the objects are populated with cv8. Can GCC write cv8 output? I'm sure it's possible to creatively coax the cv8 data blocks to store non-MS data without being stripped or crashing the linker... That said, I don't know anything about cv8/pdb, and if it's able to sufficiently express D concepts as is. MS supports quite a few languages, so it must be reasonably competent as it is...? MinGW can use dwarf debug info on windows and I guess you get all benefits of Iain's gdb work on windows. It is annoying if you get crashes in the microsoft C runtime or any other library compiled with microsoft tools though, as there's no dwarf debug info for these. I have had problems with the linker when trying to link GDC and MSC objects together. You lose the debug info for one or the other world. You can't have dwarf and cv8/pdb together. And to be useful, there would need to be some visual studio integration for dwarf debugging :/ So overall I don't see why mingw should work fine on windows. Of course there's less incentive for GCC devs to support windows, but I doubt that's different for LLVM. I think there would be plenty of incentive if it worked. I haven't tried it out for a while. I'll give it a whirl and see what's changed, but while the dwarf/cv8 conflict remains, I can't see it being a practical solution. There's also nobody working actively on the MinGW gdc port right now, afaik. We don't even know the test suite results for mingw. So if you want to contribute... This has indeed been my biggest issue with GDC in the past.
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 15 July 2014 04:27, Rainer Schuetze via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14.07.2014 08:22, Manu via Digitalmars-d-announce wrote: There are alternative tools available for windows too, but I think the key for Windows developers remains proper integration into Visual Studio, and PDB support. I guess the biggest hurdle there is integrating D concepts info into MS's proprietary PDB format. Expressing debug info like C really won't get us the full mile. Rainer bundles Mago with VisualD. I wonder what that's doing lately... Aldo has put a lot of work in extending mago to 64-bit. I guess the next version of Visual D will come with it. Mago had D expression evaluation from the start, showing associative array elements was added a bit later. Have you tried it out? How does it deal with some of the cases Iain brought up; enum's, globals/statics, tls, etc.
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 15 July 2014 04:27, Rainer Schuetze via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14.07.2014 08:22, Manu via Digitalmars-d-announce wrote: There are alternative tools available for windows too, but I think the key for Windows developers remains proper integration into Visual Studio, and PDB support. I guess the biggest hurdle there is integrating D concepts info into MS's proprietary PDB format. Expressing debug info like C really won't get us the full mile. Rainer bundles Mago with VisualD. I wonder what that's doing lately... Aldo has put a lot of work in extending mago to 64-bit. I guess the next version of Visual D will come with it. Does that mean it's working? It's very hard to tell from the project website. TBH, I actually thought Mago was a dead project for years because the last activity on the website looks like 2012. He should consider moving to github, then we can have some visibility. Mago had D expression evaluation from the start, showing associative array elements was added a bit later.
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
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. 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? On 12 July 2014 04:15, Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 11 July 2014 16:48, Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Upvote!! http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/ https://www.facebook.com/dlang.org/posts/882826745064341 https://twitter.com/D_Programming/status/487623887187083264 Andrei Thanks for spelling my name right this year. :)
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 14 July 2014 06:19, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com 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. ;) 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!) Regards Iain.
DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
Upvote!! http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/ https://www.facebook.com/dlang.org/posts/882826745064341 https://twitter.com/D_Programming/status/487623887187083264 Andrei
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 07/11/2014 05:48 PM, Andrei Alexandrescu wrote: Upvote!! http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/ https://www.facebook.com/dlang.org/posts/882826745064341 https://twitter.com/D_Programming/status/487623887187083264 Andrei Not on HN?
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On Friday, 11 July 2014 at 15:48:13 UTC, Andrei Alexandrescu wrote: Upvote!! http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/ https://www.facebook.com/dlang.org/posts/882826745064341 https://twitter.com/D_Programming/status/487623887187083264 Andrei Words are not even enough to express how grateful I am to Iain for doing this. Most stuff works with D1 builds too and I have completely switched to git build of gdb at work after trying it for a moment - huge productivity gain!
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 11 July 2014 16:48, Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Upvote!! http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/ https://www.facebook.com/dlang.org/posts/882826745064341 https://twitter.com/D_Programming/status/487623887187083264 Andrei Thanks for spelling my name right this year. :)
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
http://youtu.be/n9RNxUQ0Cyk