Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes

2014-01-10 Thread Alexander Bothe

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 
filename unknown:0
  at MonoDevelop.Debugger.Gdb.GdbSession.CheckBreakpoint (Int32 
handle) [0x0] in filename unknown:0
  at MonoDevelop.Debugger.Gdb.GdbSession.HandleEvent 
(MonoDevelop.Debugger.Gdb.GdbEvent ev) [0x0] in filename 
unknown:0
  at 
MonoDevelop.Debugger.Gdb.GdbSession+ProcessOutputc__AnonStorey3.m__3 
(System.Object ) [0x0] in filename unknown: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

2014-01-10 Thread Daniel Kozák
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 
  filename unknown:0
at MonoDevelop.Debugger.Gdb.GdbSession.CheckBreakpoint (Int32 
  handle) [0x0] in filename unknown:0
at MonoDevelop.Debugger.Gdb.GdbSession.HandleEvent 
  (MonoDevelop.Debugger.Gdb.GdbEvent ev) [0x0] in filename 
  unknown:0
at 
  MonoDevelop.Debugger.Gdb.GdbSession+ProcessOutputc__AnonStorey3.m__3 
  (System.Object ) [0x0] in filename unknown: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

2014-01-10 Thread Alexander Bothe

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

2014-01-10 Thread Jameson Ernst

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

2014-01-09 Thread Jameson Ernst
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

2014-01-09 Thread Alexander Bothe

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

2014-01-09 Thread Daniel Kozak
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

2014-01-09 Thread Alexander Bothe

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

2014-01-09 Thread Dicebot
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

2014-01-09 Thread Daniel Kozak
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

2014-01-09 Thread Jameson Ernst

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

2014-01-09 Thread Daniel Kozak
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

2014-01-09 Thread Alexander Bothe

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

2014-01-09 Thread Jameson Ernst
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

2014-01-09 Thread Alexander Bothe

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

2014-01-09 Thread Jameson Ernst
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

2014-01-09 Thread Jameson Ernst

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

2014-01-09 Thread Alexander Bothe

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

2014-01-09 Thread Jameson Ernst

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 
filename unknown:0
  at MonoDevelop.Debugger.Gdb.GdbSession.CheckBreakpoint (Int32 
handle) [0x0] in filename unknown:0
  at MonoDevelop.Debugger.Gdb.GdbSession.HandleEvent 
(MonoDevelop.Debugger.Gdb.GdbEvent ev) [0x0] in filename 
unknown:0
  at 
MonoDevelop.Debugger.Gdb.GdbSession+ProcessOutputc__AnonStorey3.m__3 
(System.Object ) [0x0] in filename unknown: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

2014-01-08 Thread Alexander Bothe

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

2014-01-08 Thread Daniel Kozak
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

2014-01-08 Thread Daniel Kozak
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

2014-01-07 Thread Alexander Bothe

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 rundebug 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) Downloadinguntar'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

2014-01-07 Thread Daniel Kozak

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 rundebug 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) Downloadinguntar'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

2014-01-06 Thread Alexander Bothe

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 rundebug programs?


Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes

2014-01-02 Thread Daniel Kozak

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

2013-12-28 Thread Paolo Invernizzi
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

2013-12-28 Thread Alexander Bothe
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

2013-12-28 Thread Alexander Bothe
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

2013-12-28 Thread Alexander Bothe
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

2013-12-28 Thread Casper Færgemand
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

2013-12-28 Thread Alexander Bothe
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

2013-12-27 Thread Kelet

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


Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes

2013-12-27 Thread ilya-stromberg
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

2013-12-27 Thread Alexander Bothe

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 bugsissues 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

2013-12-27 Thread ilya-stromberg

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 bugsissues 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

2013-12-27 Thread Kelet

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

2013-12-27 Thread Casper Færgemand
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

2013-12-27 Thread Casper Færgemand
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

2013-12-27 Thread Alexander Bothe

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 bugsissues 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

2013-12-27 Thread Alexander Bothe
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

2013-12-27 Thread ilya-stromberg

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

2013-12-27 Thread Alexander Bothe

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

2013-12-27 Thread Casper Færgemand
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

2013-12-27 Thread Casper Færgemand
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

2013-12-27 Thread ilya-stromberg
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.