www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes

reply "Alexander Bothe" <info alexanderbothe.com> writes:
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
Dec 27 2013
next sibling parent "Kelet" <kelethunter gmail.com> writes:
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
Dec 27 2013
prev sibling next sibling parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
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.
Dec 27 2013
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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! :-)
Dec 27 2013
parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
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.
Dec 27 2013
next sibling parent "Kelet" <kelethunter gmail.com> writes:
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
Dec 27 2013
prev sibling parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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.
Dec 27 2013
parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
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.
Dec 27 2013
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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.
Dec 27 2013
parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
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.
Dec 27 2013
next sibling parent "Alexander Bothe" <info alexanderbothe.com> writes:
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.
Dec 28 2013
prev sibling parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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
Dec 28 2013
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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
Dec 28 2013
parent reply "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail hotmail.com> writes:
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.
Dec 28 2013
parent "Alexander Bothe" <info alexanderbothe.com> writes:
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! :-)
Dec 28 2013
prev sibling next sibling parent reply "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail hotmail.com> writes:
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
Dec 27 2013
parent reply "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail hotmail.com> writes:
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(C
deCompletionContext 
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)
Dec 27 2013
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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
Dec 27 2013
parent reply "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail hotmail.com> writes:
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
Dec 27 2013
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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
Dec 27 2013
parent reply "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail hotmail.com> writes:
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)
Dec 27 2013
next sibling parent "Paolo Invernizzi" <paolo.invernizzi gmail.com> writes:
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
Dec 28 2013
prev sibling parent "Alexander Bothe" <info alexanderbothe.com> writes:
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?
Dec 28 2013
prev sibling parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
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.
Jan 02 2014
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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?
Jan 06 2014
parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
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.
Jan 06 2014
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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?
Jan 07 2014
parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
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
Jan 07 2014
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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.
Jan 08 2014
parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
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
Jan 08 2014
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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
Jan 08 2014
next sibling parent "Daniel Kozak" <kozzi11 gmail.com> writes:
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
Jan 08 2014
prev sibling parent reply "Jameson Ernst" <jameson example.com> writes:
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!
Jan 09 2014
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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! :-)
Jan 09 2014
parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
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?
Jan 09 2014
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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?
Jan 09 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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
Jan 09 2014
parent "Alexander Bothe" <info alexanderbothe.com> writes:
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
Jan 09 2014
prev sibling parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
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.
Jan 09 2014
parent reply "Jameson Ernst" <jameson example.com> writes:
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.
Jan 09 2014
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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 :-) )
Jan 09 2014
parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
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
Jan 09 2014
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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; }
Jan 09 2014
parent reply "Jameson Ernst" <jameson example.com> writes:
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.
Jan 09 2014
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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 :-)
Jan 09 2014
parent reply "Jameson Ernst" <jameson example.com> writes:
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.
Jan 09 2014
next sibling parent "Jameson Ernst" <jameson example.com> writes:
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...
Jan 09 2014
prev sibling parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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
Jan 09 2014
parent reply "Jameson Ernst" <jameson example.com> writes:
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) [0x00000] in <filename unknown>:0 at MonoDevelop.Debugger.Gdb.GdbSession.CheckBreakpoint (Int32 handle) [0x00000] in <filename unknown>:0 at MonoDevelop.Debugger.Gdb.GdbSession.HandleEvent (MonoDevelop.Debugger.Gdb.GdbEvent ev) [0x00000] in <filename unknown>:0 at MonoDevelop.Debugger.Gdb.GdbSession+<ProcessOutput>c__AnonStorey3.<>m__3 (System.Object ) [0x00000] in <filename unknown>:0 It's not much to go on since there's no mdb with the distributed dll, but it's something.
Jan 09 2014
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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) [0x00000] in <filename unknown>:0 at MonoDevelop.Debugger.Gdb.GdbSession.CheckBreakpoint (Int32 handle) [0x00000] in <filename unknown>:0 at MonoDevelop.Debugger.Gdb.GdbSession.HandleEvent (MonoDevelop.Debugger.Gdb.GdbEvent ev) [0x00000] in <filename unknown>:0 at MonoDevelop.Debugger.Gdb.GdbSession+<ProcessOutput>c__AnonStorey3.<>m__3 (System.Object ) [0x00000] 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.D bugging.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.
Jan 10 2014
parent reply Daniel =?ISO-8859-1?Q?Koz=E1k?= <kozzi11 gmail.com> writes:
Alexander Bothe píše v Pá 10. 01. 2014 v 12:11 +0000:
 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) [0x00000] in <filename unknown>:0 at MonoDevelop.Debugger.Gdb.GdbSession.CheckBreakpoint (Int32 handle) [0x00000] in <filename unknown>:0 at MonoDevelop.Debugger.Gdb.GdbSession.HandleEvent (MonoDevelop.Debugger.Gdb.GdbEvent ev) [0x00000] in <filename unknown>:0 at MonoDevelop.Debugger.Gdb.GdbSession+<ProcessOutput>c__AnonStorey3.<>m__3 (System.Object ) [0x00000] 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.D bugging.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
Jan 10 2014
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
On Friday, 10 January 2014 at 18:14:04 UTC, Daniel Kozák wrote:
 Now it works :), thanks a lot
Finally! :)
Jan 10 2014
parent "Jameson Ernst" <jameson example.com> writes:
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.
Jan 10 2014