Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On 22/10/2013 16:59, Manu wrote: ...okay. Ignore me! You said "GCC _is able_ to emit COFF object code", which didn't make it sound like it did, or at least not by default. Which seemed to match my experience (from years ago). I recall a conversation with Daniel Green about making a special COFF-outputting toolchain for me. So what debuginfo is in there then? MS link.exe seemed to ignore it. So, you are saying that GDC does output COFF by default? And is debuggable by gdb? I'm thoroughly confused now, this seems to contradict past experiences. Apparently I've been smoking a lot of crack... See my OP. It seems by default GDC outputs COFF object file format, but with DWARF debug info. But whatever format it is, GDB understands it quite well, that is for sure. GDC+GDB was the main configuration I tested when I was updating the Debuggers wiki page and see what kind of support there was. -- Bruno Medeiros - Software Engineer
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On 22/10/2013 14:48, Iain Buclaw wrote: If you are using GCC, you'll be using the GCC toolchain. If you are using MSVC, you'll be using the MSVC toolchain. It's as black and white as that. I know. The point, for me at least, was not weather I could use GCC + MS debuggers or MS compilers + GDB. It was: if you use DMD (64 bit ATM) what debuggers can you use? Can you sucessfully use GDB? If not, could DMD be modified to supported whatever format GDB uses? > Also, it's not likely DWARF debug information that it emits, as the > COFF object format defines its own intrinsic symbolic debug format. > GDB can't read CV8/PDB. I think it's DWARF debug information, even for COFF and PE file format. If I run "info source" on a GDC compiled program, I get: -- (gdb) info source Current source file is ../../../gcc-4.6.1/libphobos/rt/dmain.d Compilation directory is C:\crossdev\gdc\v2\build\i686-pc-mingw32\libphobos Source language is d. Compiled with DWARF 2 debugging format. Does not include preprocessor macro info. -- I suspect that what is happening is that by default GCC toolchain stores debug information in the COFF (and PE) file format in a non-standard way - it doesn't use the COFF debug standard but uses DWARF data format instead (DWARF "is independent of object file formats"). And that's why MS tools don't understand that symbolic info, I guess. -- Bruno Medeiros - Software Engineer
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On 22 October 2013 16:59, Manu wrote: > On 23 October 2013 01:02, Iain Buclaw wrote: >> >> On 22 October 2013 15:58, David Nadlinger wrote: >> > On Tuesday, 22 October 2013 at 14:39:55 UTC, Manu wrote: >> >> >> >> Well whatever object format it is, it seems it's not COFF by default, >> >> [...] >> > >> > >> > --- >> > $ gcc --version && gcc -c test.c && file test.o >> > gcc.exe (rubenvb-4.8.0) 4.8.0 >> > Copyright (C) 2013 Free Software Foundation, Inc. >> > This is free software; see the source for copying conditions. There is >> > NO >> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> > PURPOSE. >> > >> > test.o: MS Windows COFF Intel 80386 object file >> > --- >> > >> >> Thanks for having faith in my words... :o) > > > ...okay. Ignore me! > You said "GCC _is able_ to emit COFF object code", which didn't make it > sound like it did, or at least not by default. Which seemed to match my > experience (from years ago). > I recall a conversation with Daniel Green about making a special > COFF-outputting toolchain for me. > So what debuginfo is in there then? MS link.exe seemed to ignore it. > > So, you are saying that GDC does output COFF by default? And is debuggable > by gdb? > I'm thoroughly confused now, this seems to contradict past experiences. > Apparently I've been smoking a lot of crack... Or eating the wrong mushrooms. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On 23 October 2013 01:02, Iain Buclaw wrote: > On 22 October 2013 15:58, David Nadlinger wrote: > > On Tuesday, 22 October 2013 at 14:39:55 UTC, Manu wrote: > >> > >> Well whatever object format it is, it seems it's not COFF by default, > >> [...] > > > > > > --- > > $ gcc --version && gcc -c test.c && file test.o > > gcc.exe (rubenvb-4.8.0) 4.8.0 > > Copyright (C) 2013 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There is > NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > > > > test.o: MS Windows COFF Intel 80386 object file > > --- > > > > Thanks for having faith in my words... :o) > ...okay. Ignore me! You said "GCC _is able_ to emit COFF object code", which didn't make it sound like it did, or at least not by default. Which seemed to match my experience (from years ago). I recall a conversation with Daniel Green about making a special COFF-outputting toolchain for me. So what debuginfo is in there then? MS link.exe seemed to ignore it. So, you are saying that GDC does output COFF by default? And is debuggable by gdb? I'm thoroughly confused now, this seems to contradict past experiences. Apparently I've been smoking a lot of crack... What are the object+debuginfo formats supported by LDC?
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On 22 October 2013 15:58, David Nadlinger wrote: > On Tuesday, 22 October 2013 at 14:39:55 UTC, Manu wrote: >> >> Well whatever object format it is, it seems it's not COFF by default, >> [...] > > > --- > $ gcc --version && gcc -c test.c && file test.o > gcc.exe (rubenvb-4.8.0) 4.8.0 > Copyright (C) 2013 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > test.o: MS Windows COFF Intel 80386 object file > --- > Thanks for having faith in my words... :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On Tuesday, 22 October 2013 at 14:39:55 UTC, Manu wrote: Well whatever object format it is, it seems it's not COFF by default, [...] --- $ gcc --version && gcc -c test.c && file test.o gcc.exe (rubenvb-4.8.0) 4.8.0 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. test.o: MS Windows COFF Intel 80386 object file --- David
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On 22 October 2013 23:48, Iain Buclaw wrote: > On 22 October 2013 13:29, Manu wrote: > > On 18 October 2013 21:58, Iain Buclaw wrote: > >> > >> On 18 October 2013 12:43, Bruno Medeiros > > >> wrote: > >> > On 16/10/2013 22:21, Andrei Alexandrescu wrote: > >> >> > >> >> On 10/16/13 5:38 AM, Bruno Medeiros wrote: > >> >>> > >> >>> On 08/10/2013 14:18, Alexander Bothe wrote: > >> > >> Are there any plans/tricks/hacks on how to get programs built > >> with dmd debuggable with gdb? Then we also could release the > >> addin for Windows as well! > >> (Afaik I asked the same question some time ago, but well, perhaps > >> something did change over the time :-)) > >> >>> > >> >>> > >> >>> I was wondering the same as well... But from the lack of answers I > >> >>> think > >> >>> not much can be done? :/ > >> >> > >> >> > >> >> What are the matters involved? I did get basic debugging sessions > >> >> working, but I forgot whether it was dmd or gdc. > >> >> > >> >> Andrei > >> >> > >> > > >> > If that was under Windows, it must have been GDC then. The debug > format > >> > that > >> > DMD emits on Windows (OMF for x32 and COFF for x64, if I'm correct) is > >> > not > >> > understood by GDB, which I guess only understands DWARF. > >> > > >> > > >> > >> GCC is able to emit COFF object code - and GDB can read COFF debug > >> code - though admitedly COFF is a woeful excuse of an object/debug > >> file format. :o) > > > > > > DMD for Win64 uses COFF so it's compatible with the windows ecosystem at > > large (and ideally Win32 will move that way too in the future). Almost > all > > dev tools/environments/libraries are distributed as MS-COFF libs. > > > > GCC COFF output isn't very useful in the windows context. I tried it. It > > tried to link, but GCC produces countless intrinsic calls to the gnu > runtime > > libs, and they are quite incompatible with the MS CRT. It also seems to > > populate the COFF objects with DWARF debug info instead of CV8 that > > VisualC's linker extracts and writes into a PDB file, so you can't debug > > GDC's COFF output with standard tools. > > > > Incompatibility with MS CRT has nothing to do with COFF. :o) > I didn't say that it did. It's a practical problem. it makes GCC COFF output kinda pointless. Also, it's not likely DWARF debug information that it emits, as the > COFF object format defines its own intrinsic symbolic debug format. > GDB can't read CV8/PDB. > Well I can say from experience that GDC built to output COFF was able to link using the MS linker (although there are loads of problems due to CRT conflicts), but it didn't see the debug information at all. So whatever it writes is apparently not recognised by link.exe (mustn't be VC8?)... I'm aware GDB can't read CV8/PDB, I'm not sure what your point is? I was just adding detail to your post about the state of COFF support in Windows. If you are using GCC, you'll be using the GCC toolchain. If you are > using MSVC, you'll be using the MSVC toolchain. It's as black and > white as that. > Yes, that's basically the point I was making... and it influences your choice of D compilers, and tooling, hence Mono-D has a place in Windows even though it may not support DMD for debugging. > So if you're not interacting with the MS ecosystem (the de facto standard > on > > windows), then you might as well just use elf + dwarf from GCC. > > > > Except that GCC does not emit ELF on windows. ;-) > Really? What is it? Well whatever object format it is, it seems it's not COFF by default, and appears it does support DWARF since I've debugged GCC code with GDB before.
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On 22 October 2013 13:29, Manu wrote: > On 18 October 2013 21:58, Iain Buclaw wrote: >> >> On 18 October 2013 12:43, Bruno Medeiros >> wrote: >> > On 16/10/2013 22:21, Andrei Alexandrescu wrote: >> >> >> >> On 10/16/13 5:38 AM, Bruno Medeiros wrote: >> >>> >> >>> On 08/10/2013 14:18, Alexander Bothe wrote: >> >> Are there any plans/tricks/hacks on how to get programs built >> with dmd debuggable with gdb? Then we also could release the >> addin for Windows as well! >> (Afaik I asked the same question some time ago, but well, perhaps >> something did change over the time :-)) >> >>> >> >>> >> >>> I was wondering the same as well... But from the lack of answers I >> >>> think >> >>> not much can be done? :/ >> >> >> >> >> >> What are the matters involved? I did get basic debugging sessions >> >> working, but I forgot whether it was dmd or gdc. >> >> >> >> Andrei >> >> >> > >> > If that was under Windows, it must have been GDC then. The debug format >> > that >> > DMD emits on Windows (OMF for x32 and COFF for x64, if I'm correct) is >> > not >> > understood by GDB, which I guess only understands DWARF. >> > >> > >> >> GCC is able to emit COFF object code - and GDB can read COFF debug >> code - though admitedly COFF is a woeful excuse of an object/debug >> file format. :o) > > > DMD for Win64 uses COFF so it's compatible with the windows ecosystem at > large (and ideally Win32 will move that way too in the future). Almost all > dev tools/environments/libraries are distributed as MS-COFF libs. > > GCC COFF output isn't very useful in the windows context. I tried it. It > tried to link, but GCC produces countless intrinsic calls to the gnu runtime > libs, and they are quite incompatible with the MS CRT. It also seems to > populate the COFF objects with DWARF debug info instead of CV8 that > VisualC's linker extracts and writes into a PDB file, so you can't debug > GDC's COFF output with standard tools. > Incompatibility with MS CRT has nothing to do with COFF. :o) Also, it's not likely DWARF debug information that it emits, as the COFF object format defines its own intrinsic symbolic debug format. GDB can't read CV8/PDB. If you are using GCC, you'll be using the GCC toolchain. If you are using MSVC, you'll be using the MSVC toolchain. It's as black and white as that. > So if you're not interacting with the MS ecosystem (the de facto standard on > windows), then you might as well just use elf + dwarf from GCC. > Except that GCC does not emit ELF on windows. ;-) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On 18 October 2013 21:58, Iain Buclaw wrote: > On 18 October 2013 12:43, Bruno Medeiros > wrote: > > On 16/10/2013 22:21, Andrei Alexandrescu wrote: > >> > >> On 10/16/13 5:38 AM, Bruno Medeiros wrote: > >>> > >>> On 08/10/2013 14:18, Alexander Bothe wrote: > > Are there any plans/tricks/hacks on how to get programs built > with dmd debuggable with gdb? Then we also could release the > addin for Windows as well! > (Afaik I asked the same question some time ago, but well, perhaps > something did change over the time :-)) > >>> > >>> > >>> I was wondering the same as well... But from the lack of answers I > think > >>> not much can be done? :/ > >> > >> > >> What are the matters involved? I did get basic debugging sessions > >> working, but I forgot whether it was dmd or gdc. > >> > >> Andrei > >> > > > > If that was under Windows, it must have been GDC then. The debug format > that > > DMD emits on Windows (OMF for x32 and COFF for x64, if I'm correct) is > not > > understood by GDB, which I guess only understands DWARF. > > > > > > GCC is able to emit COFF object code - and GDB can read COFF debug > code - though admitedly COFF is a woeful excuse of an object/debug > file format. :o) > DMD for Win64 uses COFF so it's compatible with the windows ecosystem at large (and ideally Win32 will move that way too in the future). Almost all dev tools/environments/libraries are distributed as MS-COFF libs. GCC COFF output isn't very useful in the windows context. I tried it. It tried to link, but GCC produces countless intrinsic calls to the gnu runtime libs, and they are quite incompatible with the MS CRT. It also seems to populate the COFF objects with DWARF debug info instead of CV8 that VisualC's linker extracts and writes into a PDB file, so you can't debug GDC's COFF output with standard tools. So if you're not interacting with the MS ecosystem (the de facto standard on windows), then you might as well just use elf + dwarf from GCC. I guess the usefulness of Mono-D in windows is an environment that DOES support building+linking+debugging elf+dwarf based projects. This does exclude DMD, since it primarily tries to work in conjunction with the OS standards, but there's plenty of reasons to want to work with GDC in windows, and Mono-D would be the go-to environment for that. Ideally I'd like a command-line choice of object+debug format from all compilers so they can work in either of windows's fragmented ecosystems... but due to the intrinsic calls to glibc thing, GDC doesn't seem like it will ever be a good match for developing windows code. LDC seems promising that it may support either ecosystem, and DMD could theoretically write ELF+DWARF on a command line switch (it obviously has code to write those formats), but I haven't seen much demand for it.
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On 18/10/2013 12:58, Iain Buclaw wrote: On 18 October 2013 12:43, Bruno Medeiros wrote: On 16/10/2013 22:21, Andrei Alexandrescu wrote: On 10/16/13 5:38 AM, Bruno Medeiros wrote: On 08/10/2013 14:18, Alexander Bothe wrote: Are there any plans/tricks/hacks on how to get programs built with dmd debuggable with gdb? Then we also could release the addin for Windows as well! (Afaik I asked the same question some time ago, but well, perhaps something did change over the time :-)) I was wondering the same as well... But from the lack of answers I think not much can be done? :/ What are the matters involved? I did get basic debugging sessions working, but I forgot whether it was dmd or gdc. Andrei If that was under Windows, it must have been GDC then. The debug format that DMD emits on Windows (OMF for x32 and COFF for x64, if I'm correct) is not understood by GDB, which I guess only understands DWARF. GCC is able to emit COFF object code - and GDB can read COFF debug code - though admitedly COFF is a woeful excuse of an object/debug file format. :o) Regards Thanks for the clarification, I didn't know GDB could read COFF as well. My main dev machine is 32 bit (old yeah) so I haven't had yet the chance to try DMD-64 on Windows. Will probably try it at some point on my desktop. -- Bruno Medeiros - Software Engineer
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On 18 October 2013 12:43, Bruno Medeiros wrote: > On 16/10/2013 22:21, Andrei Alexandrescu wrote: >> >> On 10/16/13 5:38 AM, Bruno Medeiros wrote: >>> >>> On 08/10/2013 14:18, Alexander Bothe wrote: Are there any plans/tricks/hacks on how to get programs built with dmd debuggable with gdb? Then we also could release the addin for Windows as well! (Afaik I asked the same question some time ago, but well, perhaps something did change over the time :-)) >>> >>> >>> I was wondering the same as well... But from the lack of answers I think >>> not much can be done? :/ >> >> >> What are the matters involved? I did get basic debugging sessions >> working, but I forgot whether it was dmd or gdc. >> >> Andrei >> > > If that was under Windows, it must have been GDC then. The debug format that > DMD emits on Windows (OMF for x32 and COFF for x64, if I'm correct) is not > understood by GDB, which I guess only understands DWARF. > > GCC is able to emit COFF object code - and GDB can read COFF debug code - though admitedly COFF is a woeful excuse of an object/debug file format. :o) Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On 16/10/2013 13:42, Dicebot wrote: On Wednesday, 16 October 2013 at 12:38:40 UTC, Bruno Medeiros wrote: On 08/10/2013 14:18, Alexander Bothe wrote: Are there any plans/tricks/hacks on how to get programs built with dmd debuggable with gdb? Then we also could release the addin for Windows as well! (Afaik I asked the same question some time ago, but well, perhaps something did change over the time :-)) I was wondering the same as well... But from the lack of answers I think not much can be done? :/ Well I do debug `dmd -gc` programs with gdb relatively frequently. What exactly is of interest? We are talking about DMD+GDB on Windows. -- Bruno Medeiros - Software Engineer
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On 16/10/2013 22:21, Andrei Alexandrescu wrote: On 10/16/13 5:38 AM, Bruno Medeiros wrote: On 08/10/2013 14:18, Alexander Bothe wrote: Are there any plans/tricks/hacks on how to get programs built with dmd debuggable with gdb? Then we also could release the addin for Windows as well! (Afaik I asked the same question some time ago, but well, perhaps something did change over the time :-)) I was wondering the same as well... But from the lack of answers I think not much can be done? :/ What are the matters involved? I did get basic debugging sessions working, but I forgot whether it was dmd or gdc. Andrei If that was under Windows, it must have been GDC then. The debug format that DMD emits on Windows (OMF for x32 and COFF for x64, if I'm correct) is not understood by GDB, which I guess only understands DWARF. -- Bruno Medeiros - Software Engineer
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On 2013-10-17 09:42, Timothee Cour wrote: on OSX, lldb has better support than gdb. Not for D. Break points doesn't work in LLDB but they do work in GDB. The backtrace seem to be slightly incorrect as well. The line number for frame 0 is off by one. Printing a variable doesn't seem to work. -- /Jacob Carlborg
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On Wed, Oct 16, 2013 at 2:21 PM, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote: > On 10/16/13 5:38 AM, Bruno Medeiros wrote: > >> On 08/10/2013 14:18, Alexander Bothe wrote: >> >>> Are there any plans/tricks/hacks on how to get programs built >>> with dmd debuggable with gdb? Then we also could release the >>> addin for Windows as well! >>> (Afaik I asked the same question some time ago, but well, perhaps >>> something did change over the time :-)) >>> >> >> I was wondering the same as well... But from the lack of answers I think >> not much can be done? :/ >> > > What are the matters involved? I did get basic debugging sessions working, > but I forgot whether it was dmd or gdc. > > Andrei > > on OSX, lldb has better support than gdb.
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On 10/16/13 5:38 AM, Bruno Medeiros wrote: On 08/10/2013 14:18, Alexander Bothe wrote: Are there any plans/tricks/hacks on how to get programs built with dmd debuggable with gdb? Then we also could release the addin for Windows as well! (Afaik I asked the same question some time ago, but well, perhaps something did change over the time :-)) I was wondering the same as well... But from the lack of answers I think not much can be done? :/ What are the matters involved? I did get basic debugging sessions working, but I forgot whether it was dmd or gdc. Andrei
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On Wednesday, 16 October 2013 at 12:38:40 UTC, Bruno Medeiros wrote: On 08/10/2013 14:18, Alexander Bothe wrote: Are there any plans/tricks/hacks on how to get programs built with dmd debuggable with gdb? Then we also could release the addin for Windows as well! (Afaik I asked the same question some time ago, but well, perhaps something did change over the time :-)) I was wondering the same as well... But from the lack of answers I think not much can be done? :/ Well I do debug `dmd -gc` programs with gdb relatively frequently. What exactly is of interest?
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On 08/10/2013 14:18, Alexander Bothe wrote: Are there any plans/tricks/hacks on how to get programs built with dmd debuggable with gdb? Then we also could release the addin for Windows as well! (Afaik I asked the same question some time ago, but well, perhaps something did change over the time :-)) I was wondering the same as well... But from the lack of answers I think not much can be done? :/ -- Bruno Medeiros - Software Engineer
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On Tuesday, 8 October 2013 at 18:03:25 UTC, Johannes Pfau wrote: BTW: MonoDevelop is broken on Gnome 3.10 now. They changed something in gnome-terminal and now MonoDevelop can't open the terminal anymore :-( Disabling the external console should work but MonoDevelop seems to ignore that option. Workaround: https://github.com/mono/monodevelop/pull/414 Okay, nice, I'll put a new build on http://simendsjo.me/files/abothe/ as soon as it's been taken into master.
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
Am Tue, 08 Oct 2013 18:43:59 +0200 schrieb "Alex" : > On Tuesday, 8 October 2013 at 13:21:17 UTC, Dicebot wrote: > >> This time, the addin should be compatible to older beta > >> versions of > >> MonoDevelop (like 4.0.12) as well – so feel free to simply try > >> it out. > > > > _very_ glad to hear that. Thanks for your work! > > Tried it with 4.0.12 - it failed to open even a D file, but I > already patched it, so it hopefully works with 4.0.12 "stable" > (Arch/Ubuntu), 4.0.13 (Windows/Mac) and 4.0.17 (git master) now. > Let's pray that they won't experiment with their API another > time.. BTW: MonoDevelop is broken on Gnome 3.10 now. They changed something in gnome-terminal and now MonoDevelop can't open the terminal anymore :-( Disabling the external console should work but MonoDevelop seems to ignore that option. Workaround: https://github.com/mono/monodevelop/pull/414
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On Tuesday, 8 October 2013 at 13:21:17 UTC, Dicebot wrote: This time, the addin should be compatible to older beta versions of MonoDevelop (like 4.0.12) as well – so feel free to simply try it out. _very_ glad to hear that. Thanks for your work! Tried it with 4.0.12 - it failed to open even a D file, but I already patched it, so it hopefully works with 4.0.12 "stable" (Arch/Ubuntu), 4.0.13 (Windows/Mac) and 4.0.17 (git master) now. Let's pray that they won't experiment with their API another time..
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
On Tuesday, 8 October 2013 at 13:21:17 UTC, Dicebot wrote: This time, the addin should be compatible to older beta versions of MonoDevelop (like 4.0.12) as well – so feel free to simply try it out. _very_ glad to hear that. Thanks for your work! Can't guarantee anything! I've just work-arounded that IReferenceContext-missing exception, but as this was like the only change in the near past I hope it'll be runnable again.
Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd
This time, the addin should be compatible to older beta versions of MonoDevelop (like 4.0.12) as well – so feel free to simply try it out. _very_ glad to hear that. Thanks for your work!
