Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 10 January 2014 at 18:17:17 UTC, Alexander Bothe wrote: On Friday, 10 January 2014 at 18:14:04 UTC, Daniel Kozák wrote: Now it works :), thanks a lot Finally! :) Confirmed working for me as well! Thanks for working with us to iron this out. I think this will help a lot of people new to D to have a smooth first impression.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 10 January 2014 at 18:14:04 UTC, Daniel Kozák wrote: Now it works :), thanks a lot Finally! :)
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
Alexander Bothe píše v Pá 10. 01. 2014 v 12:11 +: > On Friday, 10 January 2014 at 03:48:35 UTC, Jameson Ernst wrote: > > On Friday, 10 January 2014 at 03:29:06 UTC, Alexander Bothe > > wrote: > >> On Friday, 10 January 2014 at 02:33:05 UTC, Jameson Ernst > >> wrote: > >>> On a hunch that maybe it has to do with some strange assembly > >>> version or mono version mismatch, I used monodis/ilasm to > >>> roundtrip the assembly, reassembling it against the > >>> dependencies provided in the git repo. It still exhibits the > >>> same breakpoint issue, so something is the code itself must > >>> be different. > >> > >> I've managed to bypass the addin building system now in > >> v0.2.4.6 - just try to install it and hopefully see the > >> difference :D > > > > Still no luck; same behavior when installed via the addin repo. > > > > However, I have identified this exception in the logs, that I > > can confirm occurs only when using the dll from the addin repo, > > and NOT when using a working built-from-source dll, so the odds > > that it is related are very high: > > > > ERROR [2014-01-09 19:42:34Z]: Error while processing gdb output > > MonoDevelop.Debugger.Gdb.GdbException: > > -data-evaluate-expression: Usage: -data-evaluate-expression > > expression > > at MonoDevelop.Debugger.Gdb.GdbSession.RunCommand > > (System.String command, System.String[] args) [0x0] in > > :0 > > at MonoDevelop.Debugger.Gdb.GdbSession.CheckBreakpoint (Int32 > > handle) [0x0] in :0 > > at MonoDevelop.Debugger.Gdb.GdbSession.HandleEvent > > (MonoDevelop.Debugger.Gdb.GdbEvent ev) [0x0] in > unknown>:0 > > at > > MonoDevelop.Debugger.Gdb.GdbSession+c__AnonStorey3.<>m__3 > > (System.Object ) [0x0] in :0 > > > > It's not much to go on since there's no mdb with the > > distributed dll, but it's something. > > Alright, I noticed that I made a mistake with publishing the > right version - now I've uploaded it again, uninstalled it, > removed the > ~/.local/share/MonoDevelop-4.0/LocalInstall/Addins/MonoDevelop.D.Debugging.Gdb.0.2.4.6 > > folder, installed it again, restarted MonoDevelop and tried it > out - only then it worked again. The .dll inside this folder must > be about 72,2kB large, no 69kB! For some reasons it did not > overwrite that older dll, thus I removed it. Now it works :), thanks a lot
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 10 January 2014 at 03:48:35 UTC, Jameson Ernst wrote: On Friday, 10 January 2014 at 03:29:06 UTC, Alexander Bothe wrote: On Friday, 10 January 2014 at 02:33:05 UTC, Jameson Ernst wrote: On a hunch that maybe it has to do with some strange assembly version or mono version mismatch, I used monodis/ilasm to roundtrip the assembly, reassembling it against the dependencies provided in the git repo. It still exhibits the same breakpoint issue, so something is the code itself must be different. I've managed to bypass the addin building system now in v0.2.4.6 - just try to install it and hopefully see the difference :D Still no luck; same behavior when installed via the addin repo. However, I have identified this exception in the logs, that I can confirm occurs only when using the dll from the addin repo, and NOT when using a working built-from-source dll, so the odds that it is related are very high: ERROR [2014-01-09 19:42:34Z]: Error while processing gdb output MonoDevelop.Debugger.Gdb.GdbException: -data-evaluate-expression: Usage: -data-evaluate-expression expression at MonoDevelop.Debugger.Gdb.GdbSession.RunCommand (System.String command, System.String[] args) [0x0] in :0 at MonoDevelop.Debugger.Gdb.GdbSession.CheckBreakpoint (Int32 handle) [0x0] in :0 at MonoDevelop.Debugger.Gdb.GdbSession.HandleEvent (MonoDevelop.Debugger.Gdb.GdbEvent ev) [0x0] in unknown>:0 at MonoDevelop.Debugger.Gdb.GdbSession+c__AnonStorey3.<>m__3 (System.Object ) [0x0] in :0 It's not much to go on since there's no mdb with the distributed dll, but it's something. Alright, I noticed that I made a mistake with publishing the right version - now I've uploaded it again, uninstalled it, removed the ~/.local/share/MonoDevelop-4.0/LocalInstall/Addins/MonoDevelop.D.Debugging.Gdb.0.2.4.6 folder, installed it again, restarted MonoDevelop and tried it out - only then it worked again. The .dll inside this folder must be about 72,2kB large, no 69kB! For some reasons it did not overwrite that older dll, thus I removed it.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 10 January 2014 at 03:29:06 UTC, Alexander Bothe wrote: On Friday, 10 January 2014 at 02:33:05 UTC, Jameson Ernst wrote: On a hunch that maybe it has to do with some strange assembly version or mono version mismatch, I used monodis/ilasm to roundtrip the assembly, reassembling it against the dependencies provided in the git repo. It still exhibits the same breakpoint issue, so something is the code itself must be different. I've managed to bypass the addin building system now in v0.2.4.6 - just try to install it and hopefully see the difference :D Still no luck; same behavior when installed via the addin repo. However, I have identified this exception in the logs, that I can confirm occurs only when using the dll from the addin repo, and NOT when using a working built-from-source dll, so the odds that it is related are very high: ERROR [2014-01-09 19:42:34Z]: Error while processing gdb output MonoDevelop.Debugger.Gdb.GdbException: -data-evaluate-expression: Usage: -data-evaluate-expression expression at MonoDevelop.Debugger.Gdb.GdbSession.RunCommand (System.String command, System.String[] args) [0x0] in :0 at MonoDevelop.Debugger.Gdb.GdbSession.CheckBreakpoint (Int32 handle) [0x0] in :0 at MonoDevelop.Debugger.Gdb.GdbSession.HandleEvent (MonoDevelop.Debugger.Gdb.GdbEvent ev) [0x0] in unknown>:0 at MonoDevelop.Debugger.Gdb.GdbSession+c__AnonStorey3.<>m__3 (System.Object ) [0x0] in :0 It's not much to go on since there's no mdb with the distributed dll, but it's something.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 10 January 2014 at 02:33:05 UTC, Jameson Ernst wrote: On a hunch that maybe it has to do with some strange assembly version or mono version mismatch, I used monodis/ilasm to roundtrip the assembly, reassembling it against the dependencies provided in the git repo. It still exhibits the same breakpoint issue, so something is the code itself must be different. I've managed to bypass the addin building system now in v0.2.4.6 - just try to install it and hopefully see the difference :D
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 10 January 2014 at 02:33:05 UTC, Jameson Ernst wrote: Since recompiling from source fixes the problem, this is difficult to test. However, since I've successfully roundtripped the broken dll, I can try to find and set that value in the IL itself. My IL knowledge is a bit rusty, but I did a LOT of work with it years ago, so hopefully this won't be too hard. Woops, I wrote that before reading the source file and didn't realize it was an env var. Doing more testing...
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On a hunch that maybe it has to do with some strange assembly version or mono version mismatch, I used monodis/ilasm to roundtrip the assembly, reassembling it against the dependencies provided in the git repo. It still exhibits the same breakpoint issue, so something is the code itself must be different. On Friday, 10 January 2014 at 00:39:36 UTC, Alexander Bothe wrote: Anyway, you can set logGdb (https://github.com/llucenic/MonoDevelop.Debugger.Gdb.D/blob/master/Gdb/GdbSession.cs#L84) to be true to let it dump every interaction between Mono-D and gdb - might be good to know what's wrong with the breakpoints..I'd be happy if it was MonoDevelop-related, but well, gotta check it, too. Since recompiling from source fixes the problem, this is difficult to test. However, since I've successfully roundtripped the broken dll, I can try to find and set that value in the IL itself. My IL knowledge is a bit rusty, but I did a LOT of work with it years ago, so hopefully this won't be too hard.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 10 January 2014 at 00:04:41 UTC, Jameson Ernst wrote: On Thursday, 9 January 2014 at 23:15:12 UTC, Alexander Bothe wrote: On Thursday, 9 January 2014 at 22:50:09 UTC, Daniel Kozak wrote: On Thursday, 9 January 2014 at 21:47:40 UTC, Alexander Bothe wrote: So btw, could you please define 'does not work'? Is there an exception, is there just a silent quit, is there a mysterious return value -1 when executing the program with the debugger? http://youtu.be/HRJgyFi6Zes Have you tried other code samples? Have you tried stepping through code? Have you tried examing locals via the 'Locals' pad? Just try to put in a thing like throw new Exception(); to see whether it's about breakpoints. Or try to hack in a breakpoint via asm { int 0xcc; } (dunno the x64 equivalent though :-/) or asm { int3; } Ok, I tried cloning the repo for the debugger plugin and building it from source, and it DOES work now. Strange. Something about the one in the addin repository must be subtly different. The video Daniel posted is exactly what happens when using the one from the addin repo. Program execution WILL stop on a breakpoint, but the IDE remains unaware of that fact and acts as if the program is still executing. Throwing an exception manually DOES cause it to stop though, at which point I can examine locals as normal. So the problem seems to relate specifically to breakpoints. Got to test in my VM. If it's not working there either, I'll just put the pre-built dll up in my https://github.com/aBothe/mono-d-bin rage-repo (just to bypass this ugly addins.md.com building system crap :-D ) Anyway, you can set logGdb (https://github.com/llucenic/MonoDevelop.Debugger.Gdb.D/blob/master/Gdb/GdbSession.cs#L84) to be true to let it dump every interaction between Mono-D and gdb - might be good to know what's wrong with the breakpoints..I'd be happy if it was MonoDevelop-related, but well, gotta check it, too. Thanks for testing it so far :) At any rate, building the plugin from source seems to be the ticket. If you want me to test out anything else, I'd be happy to, since I think it's important this should work out of box for as many people as possible. It is worth noting that I had the same symptoms when using mono-d debugging on a Linux Mint 15 install, so it's nothing specific to Arch. kk :-)
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Thursday, 9 January 2014 at 23:15:12 UTC, Alexander Bothe wrote: On Thursday, 9 January 2014 at 22:50:09 UTC, Daniel Kozak wrote: On Thursday, 9 January 2014 at 21:47:40 UTC, Alexander Bothe wrote: So btw, could you please define 'does not work'? Is there an exception, is there just a silent quit, is there a mysterious return value -1 when executing the program with the debugger? http://youtu.be/HRJgyFi6Zes Have you tried other code samples? Have you tried stepping through code? Have you tried examing locals via the 'Locals' pad? Just try to put in a thing like throw new Exception(); to see whether it's about breakpoints. Or try to hack in a breakpoint via asm { int 0xcc; } (dunno the x64 equivalent though :-/) or asm { int3; } Ok, I tried cloning the repo for the debugger plugin and building it from source, and it DOES work now. Strange. Something about the one in the addin repository must be subtly different. The video Daniel posted is exactly what happens when using the one from the addin repo. Program execution WILL stop on a breakpoint, but the IDE remains unaware of that fact and acts as if the program is still executing. Throwing an exception manually DOES cause it to stop though, at which point I can examine locals as normal. So the problem seems to relate specifically to breakpoints. At any rate, building the plugin from source seems to be the ticket. If you want me to test out anything else, I'd be happy to, since I think it's important this should work out of box for as many people as possible. It is worth noting that I had the same symptoms when using mono-d debugging on a Linux Mint 15 install, so it's nothing specific to Arch.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Thursday, 9 January 2014 at 22:50:09 UTC, Daniel Kozak wrote: On Thursday, 9 January 2014 at 21:47:40 UTC, Alexander Bothe wrote: So btw, could you please define 'does not work'? Is there an exception, is there just a silent quit, is there a mysterious return value -1 when executing the program with the debugger? http://youtu.be/HRJgyFi6Zes Have you tried other code samples? Have you tried stepping through code? Have you tried examing locals via the 'Locals' pad? Just try to put in a thing like throw new Exception(); to see whether it's about breakpoints. Or try to hack in a breakpoint via asm { int 0xcc; } (dunno the x64 equivalent though :-/) or asm { int3; }
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Thursday, 9 January 2014 at 21:47:40 UTC, Alexander Bothe wrote: So btw, could you please define 'does not work'? Is there an exception, is there just a silent quit, is there a mysterious return value -1 when executing the program with the debugger? http://youtu.be/HRJgyFi6Zes
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Thursday, 9 January 2014 at 21:26:41 UTC, Jameson Ernst wrote: On Thursday, 9 January 2014 at 19:20:35 UTC, Daniel Kozak wrote: So I really do not know, what is wrong with my monodevelop. Anyway with patched gdb (https://github.com/ibuclaw/gdb) and normal GDB plugin I can debbug my application quiet well. Just set this up, and the regular GDB plugin with patched GDB is working for me as well on monodevelop HEAD. Hopefully the D patches for GDB get mainlined, then it might not even be necessary to have a special D debugger plugin anymore. What is the D-extended gdb doing? I looked at d-lang.c and only found some demangling stuff as well as rewriting D-specific native types. I'd be more than happy to let gdb examine every variable's properties etc, especially when it comes to debugging templated/mixed-in stuff and interfaces - but well, I've got my very C#-like toString() examination as 'ultimate' bonus feature..it was awesome to have this feature integrated into gdb by default, too though! So btw, could you please define 'does not work'? Is there an exception, is there just a silent quit, is there a mysterious return value -1 when executing the program with the debugger? Jameson, as you've already built MonoDevelop on your own, could you please try cloning & building https://github.com/llucenic/MonoDevelop.Debugger.Gdb.D.git, putting the built dll in MonoDevelop's Addin directory (my best practice: Make a symlink from /Addins to your /bin/Debug folder - this way MD won't miss any recently rebuilt addin :-) )
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Thursday, 9 January 2014 at 19:20:35 UTC, Daniel Kozak wrote: So I really do not know, what is wrong with my monodevelop. Anyway with patched gdb (https://github.com/ibuclaw/gdb) and normal GDB plugin I can debbug my application quiet well. Just set this up, and the regular GDB plugin with patched GDB is working for me as well on monodevelop HEAD. Hopefully the D patches for GDB get mainlined, then it might not even be necessary to have a special D debugger plugin anymore.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Thursday, 9 January 2014 at 18:54:12 UTC, Alexander Bothe wrote: On Thursday, 9 January 2014 at 18:03:06 UTC, Daniel Kozak wrote: With 4.2.2 everything is OK,but with 4.2.3 it does not work properly. Why do you have gdb from AUR? Where should I get gdb else from? :-P I already noticed some different debugging issues with 4.2.3 - but those were occurring in c# projects. Anyway I just rebuilt MD again to the latest bleeding edge version available (master) and it's still able to run gdb, set breakpoints and evaluate variable values at runtime. Could you check the log for some more info please? So I really do not know, what is wrong with my monodevelop. Anyway with patched gdb (https://github.com/ibuclaw/gdb) and normal GDB plugin I can debbug my application quiet well.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Thursday, 9 January 2014 at 19:02:15 UTC, Dicebot wrote: On Thursday, 9 January 2014 at 18:54:12 UTC, Alexander Bothe wrote: On Thursday, 9 January 2014 at 18:03:06 UTC, Daniel Kozak wrote: With 4.2.2 everything is OK,but with 4.2.3 it does not work properly. Why do you have gdb from AUR? Where should I get gdb else from? :-P From main repos? :) pacman -Sy gdb Oh f*cking wow :-D Yeah, forgot that there was a difference between those and the AUR..well anyway, you all should know what I mean :P
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Thursday, 9 January 2014 at 18:54:12 UTC, Alexander Bothe wrote: On Thursday, 9 January 2014 at 18:03:06 UTC, Daniel Kozak wrote: With 4.2.2 everything is OK,but with 4.2.3 it does not work properly. Why do you have gdb from AUR? Where should I get gdb else from? :-P From main repos? :) pacman -Sy gdb
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Thursday, 9 January 2014 at 18:03:06 UTC, Daniel Kozak wrote: With 4.2.2 everything is OK,but with 4.2.3 it does not work properly. Why do you have gdb from AUR? Where should I get gdb else from? :-P I already noticed some different debugging issues with 4.2.3 - but those were occurring in c# projects. Anyway I just rebuilt MD again to the latest bleeding edge version available (master) and it's still able to run gdb, set breakpoints and evaluate variable values at runtime. Could you check the log for some more info please?
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Thursday, 9 January 2014 at 16:49:53 UTC, Alexander Bothe wrote: On Thursday, 9 January 2014 at 08:28:21 UTC, Jameson Ernst wrote: Is there a way to configure the plugin to add that option? It doesn't appear to be configurable, at least not from within the IDE. It's done by default already. I've had this same issue, and found that the D debugging plugin doesn't work when using monodevelop later than 4.2.2. I haven't bisected the exact commit where it stops working, but it's definitely somewhere between 4.2.2 and 4.2.3. I've built MD 4.2.3 on my own 3 days ago, there everything works (except debug value tooltips - gotta fix those). I've got gdb 7.6.2 from the AUR as well and quite everything works for me. Other than that though, mono-d is fantastic, and probably the single reason I'm giving D another try after a few years. The auto-completion is REALLY good now, and the semantic highlighting is great. It's hard to give that stuff up coming from C#, but now I don't have to! Thanks! :-) With 4.2.2 everything is OK,but with 4.2.3 it does not work properly. Why do you have gdb from AUR?
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Thursday, 9 January 2014 at 08:28:21 UTC, Jameson Ernst wrote: Is there a way to configure the plugin to add that option? It doesn't appear to be configurable, at least not from within the IDE. It's done by default already. I've had this same issue, and found that the D debugging plugin doesn't work when using monodevelop later than 4.2.2. I haven't bisected the exact commit where it stops working, but it's definitely somewhere between 4.2.2 and 4.2.3. I've built MD 4.2.3 on my own 3 days ago, there everything works (except debug value tooltips - gotta fix those). I've got gdb 7.6.2 from the AUR as well and quite everything works for me. Other than that though, mono-d is fantastic, and probably the single reason I'm giving D another try after a few years. The auto-completion is REALLY good now, and the semantic highlighting is great. It's hard to give that stuff up coming from C#, but now I don't have to! Thanks! :-)
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Wednesday, 8 January 2014 at 14:30:50 UTC, Alexander Bothe wrote: On Wednesday, 8 January 2014 at 12:35:47 UTC, Daniel Kozak wrote: I do not think so because it runs gdb, and it stops on break point, but it does not show it properly on monodevelop editor (red marker is not mark as current stopping point (arrow is not here)) and I can not do things like next step and so on (just pause and stop button are active). Perhaps it's some gdb user interface which is missing: mi2 is used there for a better machine2machine interfacing between mono-d and gdb. Maybe, but I dont know how to test this Just try to use -i:mi2 as an argument for gdb - then it'll use the mi2 interface Is there a way to configure the plugin to add that option? It doesn't appear to be configurable, at least not from within the IDE. I've had this same issue, and found that the D debugging plugin doesn't work when using monodevelop later than 4.2.2. I haven't bisected the exact commit where it stops working, but it's definitely somewhere between 4.2.2 and 4.2.3. Since I build from source anyway (the Arch package for monodevelop is out of date) it wasn't a big deal to just roll back to 4.2.2 for now. Other than that though, mono-d is fantastic, and probably the single reason I'm giving D another try after a few years. The auto-completion is REALLY good now, and the semantic highlighting is great. It's hard to give that stuff up coming from C#, but now I don't have to!
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Wednesday, 8 January 2014 at 14:30:50 UTC, Alexander Bothe wrote: On Wednesday, 8 January 2014 at 12:35:47 UTC, Daniel Kozak wrote: I do not think so because it runs gdb, and it stops on break point, but it does not show it properly on monodevelop editor (red marker is not mark as current stopping point (arrow is not here)) and I can not do things like next step and so on (just pause and stop button are active). Perhaps it's some gdb user interface which is missing: mi2 is used there for a better machine2machine interfacing between mono-d and gdb. Maybe, but I dont know how to test this Just try to use -i:mi2 as an argument for gdb - then it'll use the mi2 interface Ok I found out, that I can debug with GNU Debugger (GDB) plugin but not with GNU Debugger (GDB) with support for D Language plugin
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Wednesday, 8 January 2014 at 12:35:47 UTC, Daniel Kozak wrote: I do not think so because it runs gdb, and it stops on break point, but it does not show it properly on monodevelop editor (red marker is not mark as current stopping point (arrow is not here)) and I can not do things like next step and so on (just pause and stop button are active). Perhaps it's some gdb user interface which is missing: mi2 is used there for a better machine2machine interfacing between mono-d and gdb. Maybe, but I dont know how to test this Just try to use -i:mi2 as an argument for gdb - then it'll use the mi2 interface
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Wednesday, 8 January 2014 at 11:19:14 UTC, Alexander Bothe wrote: On Wednesday, 8 January 2014 at 07:50:38 UTC, Daniel Kozak wrote: Still debugging does not work :(. But for others (C#,...) it works well. Maybe it is something with dmd. I have clean installation of Archlinux x64 Can't be related to dmd as it's mainly using gdb for debugging. So, are you able to debug dmd-built programs with gdb then? with other frontends(kdbg) it is ok. Perhaps it's an issue with insufficient $PATH entries, i.e. it can't find the gdb executable because of some mysteriously overwritten path env vars - in this case I'd just try to have a symlink to /usr/bin/gdb called gdb inside your project's or bin folder - just to ensure it actually *can* find it. I do not think so because it runs gdb, and it stops on break point, but it does not show it properly on monodevelop editor (red marker is not mark as current stopping point (arrow is not here)) and I can not do things like next step and so on (just pause and stop button are active). Perhaps it's some gdb user interface which is missing: mi2 is used there for a better machine2machine interfacing between mono-d and gdb. Maybe, but I dont know how to test this
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Wednesday, 8 January 2014 at 07:50:38 UTC, Daniel Kozak wrote: Still debugging does not work :(. But for others (C#,...) it works well. Maybe it is something with dmd. I have clean installation of Archlinux x64 Can't be related to dmd as it's mainly using gdb for debugging. So, are you able to debug dmd-built programs with gdb then? If not, you may have a 'wrong' build of gdb with an unfitting build configuration. Perhaps it's an issue with insufficient $PATH entries, i.e. it can't find the gdb executable because of some mysteriously overwritten path env vars - in this case I'd just try to have a symlink to /usr/bin/gdb called gdb inside your project's or bin folder - just to ensure it actually *can* find it. Perhaps it's some gdb user interface which is missing: mi2 is used there for a better machine2machine interfacing between mono-d and gdb.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Tuesday, 7 January 2014 at 12:57:15 UTC, Alexander Bothe wrote: On Tuesday, 7 January 2014 at 06:18:44 UTC, ilya-stromberg wrote: On Monday, 6 January 2014 at 23:58:46 UTC, Alexander Bothe wrote: On Thursday, 2 January 2014 at 20:13:33 UTC, Daniel Kozak wrote: I must admit, that you do lots of awsome work on this IDE (plugin). But still it is quiet bad. After clean install I am not able to run even basic hello world. Ok I can uninstall gnome-terminal and install xterm. After that I can run basic terminal apps, but not debug them :(. Maybe it would be better to stop adding new features and try to make it more stable. Are you using Ubuntu? Perhaps installing libgnome-ui might solve the problem. Anyway, issues like these are mostly caused by MonoDevelop which can't be run on such a huge variety of Linux setups without further efforts - so how does this relate to stability when I actually am able to run&debug programs? Probably, we can add additional notice for Ubuntu users. I use Ubuntu KDE and can debug programs, but your installation instructions talk nothing about Ubuntu gnome. BTW, it's also stability question. Assume that new D member wants to install Mono-D. What he should think if it fails for the most popular Linux OS? I understand that it's MonoDevelop issue, but new D member doesn't know it. Okay, I've tested everything successfully under Ubuntu 13.XX now: 1) Downloading&untar'ing my MD distro 2) Installing libgnomeui-0 due to that GnomePlatform error at launching MD (okay, that was indeed a main problem until now..but well, I'm off Ubuntu for..2 years now?) 3) Installing dmd from the d/l page 4) Installing Mono-D & the Gdb debugging addin 5) Add the dmd include path to Mono-D's settings 6) Making a test D project 7) Compile & Debug it Now where's the actual problem with this 'routine'? Which point except 2) wasn't written on my installation page already? Still debugging does not work :(. But for others (C#,...) it works well. Maybe it is something with dmd. I have clean installation of Archlinux x64
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Tuesday, 7 January 2014 at 06:18:44 UTC, ilya-stromberg wrote: On Monday, 6 January 2014 at 23:58:46 UTC, Alexander Bothe wrote: On Thursday, 2 January 2014 at 20:13:33 UTC, Daniel Kozak wrote: I must admit, that you do lots of awsome work on this IDE (plugin). But still it is quiet bad. After clean install I am not able to run even basic hello world. Ok I can uninstall gnome-terminal and install xterm. After that I can run basic terminal apps, but not debug them :(. Maybe it would be better to stop adding new features and try to make it more stable. Are you using Ubuntu? Perhaps installing libgnome-ui might solve the problem. Anyway, issues like these are mostly caused by MonoDevelop which can't be run on such a huge variety of Linux setups without further efforts - so how does this relate to stability when I actually am able to run&debug programs? Probably, we can add additional notice for Ubuntu users. I use Ubuntu KDE and can debug programs, but your installation instructions talk nothing about Ubuntu gnome. BTW, it's also stability question. Assume that new D member wants to install Mono-D. What he should think if it fails for the most popular Linux OS? I understand that it's MonoDevelop issue, but new D member doesn't know it. Okay, I've tested everything successfully under Ubuntu 13.XX now: 1) Downloading&untar'ing my MD distro 2) Installing libgnomeui-0 due to that GnomePlatform error at launching MD (okay, that was indeed a main problem until now..but well, I'm off Ubuntu for..2 years now?) 3) Installing dmd from the d/l page 4) Installing Mono-D & the Gdb debugging addin 5) Add the dmd include path to Mono-D's settings 6) Making a test D project 7) Compile & Debug it Now where's the actual problem with this 'routine'? Which point except 2) wasn't written on my installation page already?
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Monday, 6 January 2014 at 23:58:46 UTC, Alexander Bothe wrote: On Thursday, 2 January 2014 at 20:13:33 UTC, Daniel Kozak wrote: I must admit, that you do lots of awsome work on this IDE (plugin). But still it is quiet bad. After clean install I am not able to run even basic hello world. Ok I can uninstall gnome-terminal and install xterm. After that I can run basic terminal apps, but not debug them :(. Maybe it would be better to stop adding new features and try to make it more stable. Are you using Ubuntu? Perhaps installing libgnome-ui might solve the problem. Anyway, issues like these are mostly caused by MonoDevelop which can't be run on such a huge variety of Linux setups without further efforts - so how does this relate to stability when I actually am able to run&debug programs? Probably, we can add additional notice for Ubuntu users. I use Ubuntu KDE and can debug programs, but your installation instructions talk nothing about Ubuntu gnome. BTW, it's also stability question. Assume that new D member wants to install Mono-D. What he should think if it fails for the most popular Linux OS? I understand that it's MonoDevelop issue, but new D member doesn't know it.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Thursday, 2 January 2014 at 20:13:33 UTC, Daniel Kozak wrote: I must admit, that you do lots of awsome work on this IDE (plugin). But still it is quiet bad. After clean install I am not able to run even basic hello world. Ok I can uninstall gnome-terminal and install xterm. After that I can run basic terminal apps, but not debug them :(. Maybe it would be better to stop adding new features and try to make it more stable. Are you using Ubuntu? Perhaps installing libgnome-ui might solve the problem. Anyway, issues like these are mostly caused by MonoDevelop which can't be run on such a huge variety of Linux setups without further efforts - so how does this relate to stability when I actually am able to run&debug programs?
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 27 December 2013 at 16:40:57 UTC, Alexander Bothe wrote: Hi everyone, Despite I released the big completion engine refactoring half a week ago I'd still like to announce it over here as well. There's been a complete completion engine overhaul (i.e. the part that matches the currently selected code part against the abstract symbol node in the AST and furthermore prepares the resolution of that node) and several performance improvements concerning parsing code & code completion. The full release note: http://mono-d.alexanderbothe.com/huge-completion-engine-refactoring-less-internal-clutter-v0-5-5-5/ Completion bugs/issues/requests: https://github.com/aBothe/D_Parser/issues Non-completion related stuff: https://github.com/aBothe/Mono-D/issues Cheers, Alex I must admit, that you do lots of awsome work on this IDE (plugin). But still it is quiet bad. After clean install I am not able to run even basic hello world. Ok I can uninstall gnome-terminal and install xterm. After that I can run basic terminal apps, but not debug them :(. Maybe it would be better to stop adding new features and try to make it more stable.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Saturday, 28 December 2013 at 17:16:29 UTC, Casper Færgemand wrote: I updated the language bindings from 0.5.5.6 to 0.5.5.7. While past experience tells me anything I say will only serve to make a fool of myself, I shall accept my fate and say that so far I have not been able to reproduce the null pointer exception. And by that I mean I am able to hit the keyboard more than once without having to hit the escape key to close the informative popup. Great. Well then, time for refactoring tooltips and probably get some code highlighting into them + try to examine DDoc info! :-)
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
I updated the language bindings from 0.5.5.6 to 0.5.5.7. While past experience tells me anything I say will only serve to make a fool of myself, I shall accept my fate and say that so far I have not been able to reproduce the null pointer exception. And by that I mean I am able to hit the keyboard more than once without having to hit the escape key to close the informative popup.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Saturday, 28 December 2013 at 13:29:11 UTC, Alexander Bothe wrote: Numbers greater than 9 should be okay as well - so I'll have versions like 22.30.4 then :-) Now that I've read through the specs: "Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable." Ha! :-P
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Saturday, 28 December 2013 at 06:55:21 UTC, ilya-stromberg wrote: Additional request: please use more intuitive version number, see http://semver.org/ because current version scheme doesn't provide any additional information. Please use: 1) 1-st digit if you need to upgrade the MonoDevelop version with incompatible API changes 2) 2-nd digit if you have new features, code refactoring or any other big code change 3) 3-d digit if you have only bug fixes It can help a lot. For example, 2 last Mono-D versions should have 0.5.6.0 and 0.5.6.1 numbers. Anyway, thank you for the hint. I think I'll push a new major version as soon as there's a new MD version that features breaking API - although it must feel strange to have so ridiculously high version numbers (see Chrome/FF and others). Numbers greater than 9 should be okay as well - so I'll have versions like 22.30.4 then :-) Cheers, Alex
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Saturday, 28 December 2013 at 06:55:21 UTC, ilya-stromberg wrote: When I used `ppa:keks9n/monodevelop-latest` repro, the MonoDevelop updated every day. So, it was alpha version. BTW, I had a lot of problems with it, new `ppa:ermshiperete/monodevelop` looks much better. Although I'm rather interested in providing a good platform for everyone I can't keep an eye for everything. As I've also left Ubuntu I honestly don't care about this apt-get magic anymore. I'm providing my own MD distro which is working with most setups and that's it. If someone's willed to use other versions, I can't care about each platform's specific release strategies. I repeat, please write supported MonoDevelop version at the download page. You have too many opportunities for Ubuntu: we have 3 different repros and nobody knows the correct one. BTW, `ppa:ermshiperete/monodevelop` contains pre-installed Mono-D, so it looks like the maintainer wants to support correct MonoDevelop version for Mono-D. If I write 4.2.2 somewhere at the bottom, it can be the case that there are different releases called 4.2.2 - featuring broken API and other things. I've been following that 'development' over the last couple of years - and it was deadly annoying to have broken API and nonsense exceptions after each rebuild. Yes, this might be the issue with Mono-D as well, but as soon as I'm introducing new features it's very often the case that internals change - and therewith new regressions/throw-cases rise. I'm also no test engineer who is willed to build GUI test infrastructures - perhaps I just could code more carefully, but well, even then unexpected situations will(!, I've had these situations often enough now) occur. Additional request: please use more intuitive version number, see http://semver.org/ because current version scheme doesn't provide any additional information. Please use: 1) 1-st digit if you need to upgrade the MonoDevelop version with incompatible API changes 2) 2-nd digit if you have new features, code refactoring or any other big code change 3) 3-d digit if you have only bug fixes It can help a lot. For example, 2 last Mono-D versions should have 0.5.6.0 and 0.5.6.1 numbers. Same stuff here: I'm using these numbers just to indicate an update for MD's update manager. If I could, I wouldn't even use those - as with all the continous integration there can be API changes everytime - either via Refactoring or via new feature introduction or even via bug fixing. I probably would have released Mono-D v456 now if I followed these strict rules. Or you have a second setup which is just dedicated for some final user verification. Or you just come back in a year and check it out again - if Mono-D still exists then, who knows.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Saturday, 28 December 2013 at 03:13:10 UTC, Casper Færgemand wrote: On Saturday, 28 December 2013 at 02:02:44 UTC, Alexander Bothe wrote: May I have some code samples? Writing 'SysTime' may happen everywhere - as well as 'a similar null-pointer' .. I have no magic glass bowl to look in, you know. ;-) I can't reproduce it in a new file. I can, however, go to any line in my existing project, press a key on the keyboard, and the code completion window crashes with a null pointer. Not sure what you want aside from that. I don't see why it would have anything to do with what code I've written. My only import outside Phobos is Pegged. D_Parser.Dom.DefaultDepthFirstVisitor.Visit(ArrayLiteralExpression x) Okay, I think that I've fixed it now although I still can't reproduce this exception in any wise - neither in my trivial test programs nor in std.datetime (just noticed that halfway fluid editing with all code completion and stuff is possible there either - despite 35k LOC) How am I supposed to test things I've never seen before?
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Saturday, 28 December 2013 at 03:13:10 UTC, Casper Færgemand wrote: On Saturday, 28 December 2013 at 02:02:44 UTC, Alexander Bothe wrote: May I have some code samples? Writing 'SysTime' may happen everywhere - as well as 'a similar null-pointer' .. I have no magic glass bowl to look in, you know. ;-) I can't reproduce it in a new file. I can, however, go to any line in my existing project, press a key on the keyboard, and the code completion window crashes with a null pointer. Not sure what you want aside from that. I don't see why it would have anything to do with what code I've written. My only import outside Phobos is Pegged. D_Parser.Dom.DefaultDepthFirstVisitor.Visit(ArrayLiteralExpression x) Just another hint: I have the same issue, on 4.2.2 under OSX with 0.5.5.6/0.5.5.5. Reverted to 0.5.5.4 and the issue is still present, BUT only in the log (--no-redirect) and without the modal error dialog. I agree with Casper, it happens practically in every module you wrote, when you write incomplete code. I think you already know this, Alex, but I agree with ilya and Casper: MonoD is by far the best environment to code with under OSX/linux, but we definitely need more stability. Right now, I'm scouting for my colleague every new combination of Xamarin and Mono-D updates ("ok, update to 4.2.2, it works", "hold on with 0.5.5.6, it's broken!", and so on..) /Paolo
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 27 December 2013 at 21:59:12 UTC, Alexander Bothe wrote: On Friday, 27 December 2013 at 20:53:26 UTC, ilya-stromberg wrote: Great! In that case can you just print your MonoDevelop version to the download page. Now you have: Head to http://monodevelop.com/Download and install the latest release (it may even be an ‘Alpha’ version) of MonoDevelop It's exactly that I don't want to have (‘Alpha’ version). This is the MonoDevelop magic (yes, next to the D magic there is some in MonoDevelop as well :-)) I had to understand in before either: There is no alpha, beta or stable version even if it's called that way. The only way those versions differ between each other are API changes and bug fixes/regressions. Currently, both stable and master-built (from the git master repo) versions feature the very similar API what makes Mono-D (currently!) running on all 4.2 releases. This might change again - but atm, it works. When I used `ppa:keks9n/monodevelop-latest` repro, the MonoDevelop updated every day. So, it was alpha version. BTW, I had a lot of problems with it, new `ppa:ermshiperete/monodevelop` looks much better. I repeat, please write supported MonoDevelop version at the download page. You have too many opportunities for Ubuntu: we have 3 different repros and nobody knows the correct one. BTW, `ppa:ermshiperete/monodevelop` contains pre-installed Mono-D, so it looks like the maintainer wants to support correct MonoDevelop version for Mono-D. Additional request: please use more intuitive version number, see http://semver.org/ because current version scheme doesn't provide any additional information. Please use: 1) 1-st digit if you need to upgrade the MonoDevelop version with incompatible API changes 2) 2-nd digit if you have new features, code refactoring or any other big code change 3) 3-d digit if you have only bug fixes It can help a lot. For example, 2 last Mono-D versions should have 0.5.6.0 and 0.5.6.1 numbers.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Saturday, 28 December 2013 at 02:02:44 UTC, Alexander Bothe wrote: May I have some code samples? Writing 'SysTime' may happen everywhere - as well as 'a similar null-pointer' .. I have no magic glass bowl to look in, you know. ;-) I can't reproduce it in a new file. I can, however, go to any line in my existing project, press a key on the keyboard, and the code completion window crashes with a null pointer. Not sure what you want aside from that. I don't see why it would have anything to do with what code I've written. My only import outside Phobos is Pegged. D_Parser.Dom.DefaultDepthFirstVisitor.Visit(ArrayLiteralExpression x)
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 27 December 2013 at 22:58:23 UTC, Casper Færgemand wrote: On Friday, 27 December 2013 at 20:47:07 UTC, Alexander Bothe wrote: snip Cheers, Alex Hmm, it's not just modules, I think I know what's wrong. I just wrote SysTime and stopped, realizing I wanted it in a function instead. As I started writing the new function, I was continuously interrupted with a similar null-pointer until I removed the original line just containing SysTime. It looks to me like it happens whenever there's incomplete code, so I'd think it related to the syntax checking or whatever magic. I can avoid it by just not leaving incomplete code, though my brain is going to complain =/. Perhaps it's a quirk of Mono-Develop rather than the plugin. Given the inability to change language, such a bug would not surprise me. :P May I have some code samples? Writing 'SysTime' may happen everywhere - as well as 'a similar null-pointer' .. I have no magic glass bowl to look in, you know. ;-) Cheers, Alex
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 27 December 2013 at 20:47:07 UTC, Alexander Bothe wrote: snip Cheers, Alex Hmm, it's not just modules, I think I know what's wrong. I just wrote SysTime and stopped, realizing I wanted it in a function instead. As I started writing the new function, I was continuously interrupted with a similar null-pointer until I removed the original line just containing SysTime. It looks to me like it happens whenever there's incomplete code, so I'd think it related to the syntax checking or whatever magic. I can avoid it by just not leaving incomplete code, though my brain is going to complain =/. Perhaps it's a quirk of Mono-Develop rather than the plugin. Given the inability to change language, such a bug would not surprise me. :P
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 27 December 2013 at 20:53:26 UTC, ilya-stromberg wrote: Great! In that case can you just print your MonoDevelop version to the download page. Now you have: Head to http://monodevelop.com/Download and install the latest release (it may even be an ‘Alpha’ version) of MonoDevelop It's exactly that I don't want to have (‘Alpha’ version). This is the MonoDevelop magic (yes, next to the D magic there is some in MonoDevelop as well :-)) I had to understand in before either: There is no alpha, beta or stable version even if it's called that way. The only way those versions differ between each other are API changes and bug fixes/regressions. Currently, both stable and master-built (from the git master repo) versions feature the very similar API what makes Mono-D (currently!) running on all 4.2 releases. This might change again - but atm, it works. OK. Can you add instruction how to do downgrade? See Kelet's instructions. Can you add the instructions to the your site? I think it can help to many people if they'll see an errors. Sure.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 27 December 2013 at 20:37:23 UTC, Alexander Bothe wrote: On Friday, 27 December 2013 at 19:45:09 UTC, ilya-stromberg wrote: I don't talk that you must support different Mono Develop versions for different OS. Current stable Mono Develop is 4.2.2, can you use it for all supported OS and specify recomended Mono Develop version ad the `http://mono-d.alexanderbothe.com/download/` page? I just want to say: "please, don't use Alpha/Betta Release of Mono Develop". I have a lot of problems with Betta Release of Mono Develop at Ubuntu ~2 years ago. This is why I decided to distribute my very own Linux x86/x64 version of MonoDevelop on simendsjo's server @ http://simendsjo.me/files/abothe in order to prevent exactly these kinds of circumstances - since that version is the version I'm using the most time on my machine. Great! In that case can you just print your MonoDevelop version to the download page. Now you have: Head to http://monodevelop.com/Download and install the latest release (it may even be an ‘Alpha’ version) of MonoDevelop It's exactly that I don't want to have (‘Alpha’ version). OK. Can you add instruction how to do downgrade? See Kelet's instructions. Can you add the instructions to the your site? I think it can help to many people if they'll see an errors.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 27 December 2013 at 20:23:51 UTC, Casper Færgemand wrote: I'll take it back. When writing a module specification, it kept interrupting me with this error. Due to an annoying error in Mono-Develop, I cannot change the language in the program without changing it in my OS, which I don't bother this moment. I have translated the first line, it's in {}. "ved" means "at". { System.NullReferenceException: The objekt reference is not configured to an occurence of an object. } System.NullReferenceException: Objektreferencen er ikke indstillet til en forekomst af et objekt. ved D_Parser.Dom.DefaultDepthFirstVisitor.Visit(ArrayLiteralExpression x) Makes me smile :-D That's the usual stuff I'm talking about - those classical places of null-ref exceptions where I simply couldn't imagine they could occur at exactly that location. Module specification - like module ABC; ? You'll laugh: It works for me, no exception when trying to write such statement. Furthermore I had to wonder why it's throwing at visiting ArrayLiterals..anyway, thanks for the quick report. Looking at the code, there's not even the possibility to have an NRE occuring over there. Something weird happened again. Cheers, Alex
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 27 December 2013 at 19:45:09 UTC, ilya-stromberg wrote: It was non-critical errors and thay appeared randomly. At least I can't reproduse it now. But OK, I'll try to send bug reports. Please! Bug trackers, mails, blog comments, IRC, G+ - even via facebook :O There are so many ways to communicate! :-) I don't talk that you must support different Mono Develop versions for different OS. Current stable Mono Develop is 4.2.2, can you use it for all supported OS and specify recomended Mono Develop version ad the `http://mono-d.alexanderbothe.com/download/` page? I just want to say: "please, don't use Alpha/Betta Release of Mono Develop". I have a lot of problems with Betta Release of Mono Develop at Ubuntu ~2 years ago. This is why I decided to distribute my very own Linux x86/x64 version of MonoDevelop on simendsjo's server @ http://simendsjo.me/files/abothe in order to prevent exactly these kinds of circumstances - since that version is the version I'm using the most time on my machine. Not exactly. Actually, I decided do not to update, but one day I had to create a new MonoD installation after OS re-install, and it was complitly broken. I couldn't even open the project. It was terrible. After that I decided to use Eclipse/DDT, even it has less features. Sure, and then you'll have the chance to 'return' two years afterwards :) I know this implies some efforts (head to http://addins.monodevelop.com/Project/Index/27 and select an older release :-)) but ensures that quite everyone is using the very latest version. Only then I can locate bugs&issues most efficiently. OK. Can you add instruction how to do downgrade? See Kelet's instructions.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
I'll take it back. When writing a module specification, it kept interrupting me with this error. Due to an annoying error in Mono-Develop, I cannot change the language in the program without changing it in my OS, which I don't bother this moment. I have translated the first line, it's in {}. "ved" means "at". { System.NullReferenceException: The objekt reference is not configured to an occurence of an object. } System.NullReferenceException: Objektreferencen er ikke indstillet til en forekomst af et objekt. ved D_Parser.Dom.DefaultDepthFirstVisitor.Visit(ArrayLiteralExpression x) ved D_Parser.Dom.Expressions.ArrayLiteralExpression.Accept(ExpressionVisitor vis) ved D_Parser.Completion.CompletionProviderVisitor.Visit(DVariable n) ved D_Parser.Dom.DVariable.Accept(NodeVisitor vis) ved D_Parser.Dom.DefaultDepthFirstVisitor.VisitChildren(IBlockNode block) ved D_Parser.Completion.CompletionProviderVisitor.VisitChildren(IBlockNode block) ved D_Parser.Dom.DefaultDepthFirstVisitor.VisitBlock(DBlockNode block) ved D_Parser.Dom.DefaultDepthFirstVisitor.Visit(DModule n) ved D_Parser.Dom.DModule.Accept(NodeVisitor vis) ved D_Parser.Completion.CodeCompletion.GenerateCompletionData(IEditorData editor, ICompletionDataGenerator completionDataGen, Char triggerChar, Boolean alreadyCheckedCompletionContext) ved MonoDevelop.D.Completion.DCodeCompletionSupport.BuildCompletionData(Document EditorDocument, DModule SyntaxTree, CodeCompletionContext ctx, CompletionDataList l, Char triggerChar) ved MonoDevelop.D.DEditorCompletionExtension.HandleCodeCompletion(CodeCompletionContext completionContext, Char triggerChar, Int32& triggerWordLength) ved MonoDevelop.Ide.Gui.Content.CompletionTextEditorExtension.KeyPress(Key key, Char keyChar, ModifierType modifier) ved MonoDevelop.D.DEditorCompletionExtension.KeyPress(Key key, Char keyChar, ModifierType modifier) ved MonoDevelop.Ide.Gui.Content.TextEditorExtension.KeyPress(Key key, Char keyChar, ModifierType modifier) ved MonoDevelop.D.Formatting.Indentation.DTextEditorIndentation.KeyPress(Key key, Char keyChar, ModifierType modifier) ved MonoDevelop.Ide.Gui.Content.TextEditorExtension.KeyPress(Key key, Char keyChar, ModifierType modifier) ved MonoDevelop.Ide.Gui.Content.TextEditorExtension.KeyPress(Key key, Char keyChar, ModifierType modifier) ved MonoDevelop.Ide.Gui.Content.TextEditorExtension.KeyPress(Key key, Char keyChar, ModifierType modifier) ved MonoDevelop.Ide.Gui.Content.TextEditorExtension.KeyPress(Key key, Char keyChar, ModifierType modifier) ved MonoDevelop.Ide.Gui.Content.TextEditorExtension.KeyPress(Key key, Char keyChar, ModifierType modifier) ved MonoDevelop.Debugger.ExceptionCaughtTextEditorExtension.KeyPress(Key key, Char keyChar, ModifierType modifier) ved MonoDevelop.SourceEditor.ExtensibleTextEditor.ExtensionKeyPress(Key key, UInt32 ch, ModifierType state)
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
Awesome. It seems to work fine so far. Since I started using dub I had to say goodbye to what working IDEs I had running, and when I tried Mono I was unlucky enough to do so right after an update that killed everything (mono crashed, plugins didn't work, couldn't find compiler, couldn't recognize d files, kept wanting to downgrade plugins once installed). It looks good now though. Integration with dub could be explained a tad better (hint: open the package.json file and done), but it's really easy. I realize this doesn't say much about Mono-D, but an IDE that hasn't crashed yet is better than no IDE. :P
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 27 December 2013 at 19:45:09 UTC, ilya-stromberg wrote: OK. Can you add instruction how to do downgrade? I believe the process is like this: 1. Close any D Language solutions you may have open. 2. Open the add-in manager (under tools menu), go to the "Gallery" tab, and under "Language bindings", uninstall the "D Language Binding". 3. Restart MonoDevelop/Xamarin Studio (you will be prompted to). 4. Download the version that you'd like to use from the aforementioned website. 5. Open the add-in manager, and on the bottom left there is "Install from file" - select the file you downloaded from the website. Regards, Kelet
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 27 December 2013 at 19:09:28 UTC, Alexander Bothe wrote: On Friday, 27 December 2013 at 17:52:22 UTC, ilya-stromberg wrote: I have only one request: can you focus at the Mono-D stability? I saw a few errors last time (I'm not shure if it was Mono Develop errors or Mono-D errors). Then please tell me as soon as they appear! Assuming that you've got a longer programming experience, you should know well that silent/destructive raging won't help anybody! :) It was non-critical errors and thay appeared randomly. At least I can't reproduse it now. But OK, I'll try to send bug reports. So, can you use only stable Mono Develop versions and print current required Mono Develop version? That's one thing I did for the last bunch of years. I hated it, brought even more confusion and I had doubled circumstances to manage everything. Atm I'm very happy that I can even release Mono-D for all 3 major OS platforms exclusively via addins.monodevelop.com which is the built-in distribution platform of MD. I don't talk that you must support different Mono Develop versions for different OS. Current stable Mono Develop is 4.2.2, can you use it for all supported OS and specify recomended Mono Develop version ad the `http://mono-d.alexanderbothe.com/download/` page? I just want to say: "please, don't use Alpha/Betta Release of Mono Develop". I have a lot of problems with Betta Release of Mono Develop at Ubuntu ~2 years ago. Also, can you create betta/rc versions of Mono-D and, maybe, create separate repro for it? I'd rather recommend to downgrade if something is not working at all - or just skip versions (like the usual main release followed by several bug fix releases - It's always your choice not to update!) Not exactly. Actually, I decided do not to update, but one day I had to create a new MonoD installation after OS re-install, and it was complitly broken. I couldn't even open the project. It was terrible. After that I decided to use Eclipse/DDT, even it has less features. I know this implies some efforts (head to http://addins.monodevelop.com/Project/Index/27 and select an older release :-)) but ensures that quite everyone is using the very latest version. Only then I can locate bugs&issues most efficiently. OK. Can you add instruction how to do downgrade? In past I had very bad experience of work with Mono-D because any Mono Develop and/or Mono-D upgrade could break the IDE. So, it will be really great to see stable Mono-D. Lastly, please define 'stable'. I think you mean 'not crashing at every key stroke' - well, that can indeed happen from time to time. Yes, exactly. But I agree that Mono-D looks much better than before. But still, it's continous partly test-driven rolling-released integration - what do you expect? :-D Furthermore, the guys from MonoDevelop seem to have taken a break from changing the APIs on every release plus if you use the dub architecture, Mono-D is a fully opt-in solution to develop your project. If it's just crashing, keep on developing with other tools and may return if it's working again. Or just keep filing issue reports, or try to fix it on your own - it's FOSS! :-) Unfortunately, dub didn't exist at that days. But yes, today it's possible.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 27 December 2013 at 17:52:22 UTC, ilya-stromberg wrote: I have only one request: can you focus at the Mono-D stability? I saw a few errors last time (I'm not shure if it was Mono Develop errors or Mono-D errors). Then please tell me as soon as they appear! Assuming that you've got a longer programming experience, you should know well that silent/destructive raging won't help anybody! :) So, can you use only stable Mono Develop versions and print current required Mono Develop version? That's one thing I did for the last bunch of years. I hated it, brought even more confusion and I had doubled circumstances to manage everything. Atm I'm very happy that I can even release Mono-D for all 3 major OS platforms exclusively via addins.monodevelop.com which is the built-in distribution platform of MD. Also, can you create betta/rc versions of Mono-D and, maybe, create separate repro for it? I'd rather recommend to downgrade if something is not working at all - or just skip versions (like the usual main release followed by several bug fix releases - It's always your choice not to update!) I know this implies some efforts (head to http://addins.monodevelop.com/Project/Index/27 and select an older release :-)) but ensures that quite everyone is using the very latest version. Only then I can locate bugs&issues most efficiently. In past I had very bad experience of work with Mono-D because any Mono Develop and/or Mono-D upgrade could break the IDE. So, it will be really great to see stable Mono-D. Lastly, please define 'stable'. I think you mean 'not crashing at every key stroke' - well, that can indeed happen from time to time. But still, it's continous partly test-driven rolling-released integration - what do you expect? :-D Furthermore, the guys from MonoDevelop seem to have taken a break from changing the APIs on every release plus if you use the dub architecture, Mono-D is a fully opt-in solution to develop your project. If it's just crashing, keep on developing with other tools and may return if it's working again. Or just keep filing issue reports, or try to fix it on your own - it's FOSS! :-)
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 27 December 2013 at 16:40:57 UTC, Alexander Bothe wrote: There's been a complete completion engine overhaul (i.e. the part that matches the currently selected code part against the abstract symbol node in the AST and furthermore prepares the resolution of that node) and several performance improvements concerning parsing code & code completion. Thank you. I tried Mono Develop 4.2 and Mono-D 0.5.5.4, it was great. I have only one request: can you focus at the Mono-D stability? I saw a few errors last time (I'm not shure if it was Mono Develop errors or Mono-D errors). So, can you use only stable Mono Develop versions and print current required Mono Develop version? Also, can you create betta/rc versions of Mono-D and, maybe, create separate repro for it? In past I had very bad experience of work with Mono-D because any Mono Develop and/or Mono-D upgrade could break the IDE. So, it will be really great to see stable Mono-D.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 27 December 2013 at 16:40:57 UTC, Alexander Bothe wrote: Hi everyone, Despite I released the big completion engine refactoring half a week ago I'd still like to announce it over here as well. There's been a complete completion engine overhaul (i.e. the part that matches the currently selected code part against the abstract symbol node in the AST and furthermore prepares the resolution of that node) and several performance improvements concerning parsing code & code completion. The full release note: http://mono-d.alexanderbothe.com/huge-completion-engine-refactoring-less-internal-clutter-v0-5-5-5/ Completion bugs/issues/requests: https://github.com/aBothe/D_Parser/issues Non-completion related stuff: https://github.com/aBothe/Mono-D/issues Cheers, Alex Excellent! Alex has been fixing a lot of bugs regarding DUB package support that I've reported recently. It's nice having an IDE that knows how to read and set up a project based on a package.json file. Regards, Kelet