Mono-D v2.5 - dub buildTypes
Hi everyone, just gave the second drop down box in Xamarin Studio a use: Selection of build types for dub projects. Furthermore, please don't rage silently somewhere - tell me about issues with Mono-D on github or in #d.mono-d on freenode! http://wiki.dlang.org/Mono-D https://github.com/aBothe/Mono-D/issues Cheers thanks to everyone, Alex
Re: Mono-D v2.4.9 - Parser fixes
On Thursday, 25 September 2014 at 22:02:14 UTC, Piotrek wrote: I was shocked how smoothly Mono-D works compared to DDT. Well maybe, but there's a lot of performance improvement required -- just open std.traits and see what lags there are due to its attempts to highlight usages of the currently selected symbol identifier :/ On linux it wasn't one click install though. I had to compile Monodevelop myself to get the plugin working. And to be fair I didn't check DDT for some time now. Instructions and a precompiled distro-independent bundle are given this time, though! In short, Mono-D FTW! Alexander, thanks for your great contribution. Piotrek Thanks - and don't forget to file issue reports on github instead of raging silently, please! :-D
Mono-D v2.4.9 - Parser fixes
Hi everyone, just wanted to announce a further small version bump of Mono-D. And yeah, despite my 2 week-break, development still continues! Cheers, Alex
Re: Mono-D v2.4.9 - Parser fixes
On Tuesday, 23 September 2014 at 14:02:47 UTC, Alexander Bothe wrote: Hi everyone, just wanted to announce a further small version bump of Mono-D. And yeah, despite my 2 week-break, development still continues! Cheers, Alex Durr, forgot to put in links: Release notes: http://wiki.dlang.org/Mono-D_Release_Notes Wiki: http://wiki.dlang.org/Mono-D Github: https://github.com/aBothe/D_Parser / https://github.com/aBothe/Mono-D
Re: Mono-D v2.4.9 - Parser fixes
Already read it on Twitter - nice to hear this! :) On Tuesday, 23 September 2014 at 16:53:23 UTC, Andrei Alexandrescu wrote: Awesome! I'm using it on OSX, works nice. -- Andrei
Re: Mono-D 2.0 - XamarinStudio 5.0 support, completion improvements
On Saturday, 3 May 2014 at 08:12:50 UTC, Jack Applegame wrote: At first, thank you. There is an issue with Diet templates highlighting. It's very poor. Just compare Mono-D 2.0.1/Xamarian Studio 5.0 - http://a-rei.ru/eNhp Sublime Text 3 - http://a-rei.ru/vuoY Hmm, normally, this stuff should've been highlighted as well. See http://mono-d.alexanderbothe.com/diet-template-syntax-highlighting/ :) But thanks for noticing that regression.
Re: Mono-D 2.0 - XamarinStudio 5.0 support, completion improvements
On Saturday, 3 May 2014 at 11:28:25 UTC, Alexander Bothe wrote: But thanks for noticing that regression. No, it actually is working. Your file has to end with '.dt' to have proper highlighting. A screenshot I just took: http://i.imgur.com/KaWAKgW.png
Re: Mono-D 2.0 - XamarinStudio 5.0 support, completion improvements
On Saturday, 3 May 2014 at 13:21:24 UTC, Jack Applegame wrote: Strange. What is wrong? editor - http://a-rei.ru/meJf about - http://a-rei.ru/RAuW add-in manager - http://a-rei.ru/jIrf Nothing is wrong with that - except that in the current release, the inline-D syntax highlighting only triggers after a - or # (double space + minus/hash), not after a \t- (tab + minus) I've corrected this now :-) https://github.com/aBothe/Mono-D/commit/52eaa924385fb55685e2e11d1500dedf053c9c18
Re: Mono-D 2.0 - XamarinStudio 5.0 support, completion improvements
On Saturday, 3 May 2014 at 17:09:41 UTC, Paolo Invernizzi wrote: I'm not seeing any more the icons in the document outline pad: is it expected? must be a regression as well. Gonna check it.
Re: Mono-D 2.0 - XamarinStudio 5.0 support, completion improvements
On Saturday, 3 May 2014 at 17:09:41 UTC, Paolo Invernizzi wrote: I'm not seeing any more the icons in the document outline pad: is it expected? Fixed it in v2.0.2
Mono-D 2.0 - XamarinStudio 5.0 support, completion improvements
Hi everyone, there's a new XamarinStudio version upcoming. And just as usual, I've just downloaded the bleeding-edge release candidate and made Mono-D run on it :P For the next couple of days, you'll only be able to get Mono-D from the repo I've mentioned in the release note, as XamarinStudio's online addin system isn't ready for the new major version yet. Furthermore, there have been some smaller changes improvements to the completion functionality again. There's also upcoming dustmite support where you'll be able to invoke dustmite from within Mono-D. http://mono-d.alexanderbothe.com/mono-d-2-0-for-xamarinstudio-5-0/ Hopefully, I can release the new XamarinStudio/MonoDevelop version on Linux as well. Someone mentioned an API freeze for the next couple of XS/MD versions, so chances are good that there's no hassle with broken Mono-D's for the next months. Enjoy!
Re: Mono-D 1.9 - opIndex/opSlice overload recognition + completion
On Friday, 4 April 2014 at 19:20:18 UTC, Adam Wilson wrote: If that's not possible then it's still nice to know that I am working with a type and not an identifier. I furthermore fixed some reference finding + highlighting bugs, some NREs, an SO regression and some further bugs, they're all part of v1.9.2
Mono-D 1.9 - opIndex/opSlice overload recognition + completion
On Monday, 31 March 2014 at 21:41:26 UTC, Théo Bueno wrote: Mono-D seems pretty complete to me now, I was wondering if you are thinking about new major features ? http://mono-d.alexanderbothe.com/mono-d-v1-9-opindexopslice-overload-recognition-completion/ :-)
Re: Mono-D 1.9 - opIndex/opSlice overload recognition + completion
On Friday, 4 April 2014 at 17:32:52 UTC, Adam Wilson wrote: I think I have a syntax highlighting regression. The following code from module core.sys.windows.windows used to be highlighted when used in my own modules in 1.7.3 but is now regular black text: alias LONG HRESULT; Well, since your previous version was 1.7.3, I think that I've made this change knowingly. Anyway I surely can get aliases highlighted again.
Re: Mono-D 1.9 - opIndex/opSlice overload recognition + completion
On Friday, 4 April 2014 at 19:20:18 UTC, Adam Wilson wrote: If possible it would be nice for aliases to be highlighted per their underlying type, so struct aliases highlight differently than primitive aliases? It would be an interesting way to provide semantic information to the user about what the underlying type actually is... Probably would take too much time to resolve deduce each alias' base type. If that's not possible then it's still nice to know that I am working with a type and not an identifier. Sure.
Re: Mono-D 1.8 - Conditional code highlighting
On Tuesday, 1 April 2014 at 13:13:12 UTC, Tofu Ninja wrote: Am i the only one who has never been able to get your website to load, i haven't been able to for months. I can do - and several others, too. http://www.downforeveryoneorjustme.com/mono-d.alexanderbothe.com *cough* Try a proxy like hidemyass or openthis.eu :P
Re: Mono-D 1.8 - Conditional code highlighting
On Wednesday, 2 April 2014 at 05:06:31 UTC, #Coder wrote: I am getting following error when debugging a simple program and try to see a variable value in watch or immediate or locals window (OpenSuse Linux latest, latest MonoDevelop and latest Mono-D plug-in) System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. --- System.MissingMethodException: Method not found: k I've fixed it in v0.2.7
Re: Mono-D 1.8 - Conditional code highlighting
Just couldn't let these primary issues pass by that easily.. http://mono-d.alexanderbothe.com/improved-conditional-highlighting-completion-v1-8-1/ Cheers everyone
Re: Mono-D 1.8 - Conditional code highlighting
On Monday, 31 March 2014 at 21:41:26 UTC, Théo Bueno wrote: As usual, thank you for bringing more awesomeness to D :) Mono-D seems pretty complete to me now, I was wondering if you are thinking about new major features ? Thanks :) Well, atm there are too many smaller bugs to fix and little things to improve. Perhaps some more refactorings or better semantic highlighting, perhaps some better way to cache completion results to make everything even faster..dunno, for now.
Mono-D 1.8 - Conditional code highlighting
Hi everyone, just messed around with the MonoDevelop APIs and got some nice editing-related feature working. http://mono-d.alexanderbothe.com/conditional-highlighting-v1-8/ Hopefully it won't crash immediately or obstruct the displayed code in any other wise..but let's see. :-P Cheers, Alex
Re: Experimental win32 OMF linker written in D now on github
On Sunday, 23 March 2014 at 20:33:15 UTC, Daniel Murphy wrote: So a couple of years ago I had too much free time and wrote a linker. It's now on github: https://github.com/yebblies/ylink Pros: - Written in D - Not written in assembly - Not written before I was born - Boost license - Usually produces working executables Cons: - No debug information (yet) - Slower than optlink - Uses more memory than optlink (cannot run with 64k of ram) - Cannot produce DLLs (yet) - Not really tested It still needs a lot of work, but it's functional. Potential uses: - Replace optlink - Replace microsoft linker (we could ship this with dmd) - Call from dmd to do in-memory linking - Experiment with linker optimizations Enjoy! If the debug info emitting thing is going to work properly, I'll love to switch to ylink! Finally x64 builds without having to use the ms linker -- awesome! :-)
Re: Mono-D v1.7.2 - Again internal refactorings, less completion bugs
On Tuesday, 18 March 2014 at 10:04:27 UTC, Sönke Ludwig wrote: I've given Mono-D the first serious try recently (I'm using a simple Sublime Text setup usually) and it was a really pleasant experience. Apart from the code completion and the DUB integration, which is of course awesome to have, some features like the integrated compare/blame/merge views are also nice productivity boosters. Good to see progress on the auto completion, as that was the only thing that still was a little annoying - annoying just because it usually works so well that you quickly come to rely on it and thus also immediately notice when it fails. There is probably some kind of uncanny valley there, where it either has to be perfect, or very sketchy (based on text buffers) to be comfortable to use. This is basically a very situation-dependent thing, as it sometimes is just not able to deduce the currrently initialized type, although I've already built-in recognition pass-throughs if template parameters couldn't be satisfied. I've also made hard-coded Tuple completion available - and although this might not be the best idea, it's actually a big leap forward even without having to spend too much time on deducing each template (or handling CTFE - this is still a thing I don't want to touch atm).
Re: Mono-D v1.7.2 - Again internal refactorings, less completion bugs
On Tuesday, 18 March 2014 at 13:16:45 UTC, Suliman wrote: Could you please port your add-in to SharpDevelop? No, because it's Windows-only, because there's XS and VisualD for Windows already, because I'm not paid for doing this ;-)
Mono-D v1.7.2 - Again internal refactorings, less completion bugs
...and a way less annoying completion behaviour, as there's a completion request time out now that just cancels any too long attempt to get completion info. http://mono-d.alexanderbothe.com/again-internal-refactorings-less-completion-bugs-v1-7-2/ Cheers mates, Alex
Mono-D v1.7 - Struct init member completion parser refactorings
Hi everyone, just wanted to drop a small sign of life of Mono-D. http://mono-d.alexanderbothe.com/mono-d-v1-7-struct-init-member-completion-massive-parse-improvements/ Cheers, Alex
Re: Mono-D v1.5.2 - Completion improvements, dub support fixes
On Sunday, 16 February 2014 at 11:49:08 UTC, Rene Zwanenburg wrote: 5) Could you pastebin me your last log file(s) please? (You can open the folder via 'Help' menu - Open Log directory) Parts of the log file is Dutch (OS language), Xamarin Studio language is set to English but most of the interface and even the log files are unaffected. I guess I'll have to take that up with the Mono Develop devs. http://pastebin.com/tBn5hGxd What I really wonder is why the last exception is occurring - In theory there can't be such exception in that case.. Which version of Mono-D do you've got installed? Anyway it might hangs in a deadlock or so while scanning all the folders - but I can't imagine that this is happening that oftenly. 6) Try to put the include paths into the project settings and try to get phobos symbol completion afterwards. I can't seem to find where to add include paths in the project settings.. You could reference them in the dub package definition temporarily.
Re: Mono-D v1.5.2 - Completion improvements, dub support fixes
On Saturday, 15 February 2014 at 14:31:15 UTC, Rene Zwanenburg wrote: I'm trying Mono-D for the first time and I must say I'm really enjoying the autocomplete. It's not giving suggestions for Phobos though. Includes in D Compiler Toolchains have been set correctly. Any idea what's wrong? 1) On which OS are you working? 2) What are your include paths? 3) Are those paths put into the 'default' compiler config (aka DMD2 should be the default) 4) Have you opened up a dub project or did you create one directly in Mono-D? 5) Could you pastebin me your last log file(s) please? (You can open the folder via 'Help' menu - Open Log directory) 6) Try to put the include paths into the project settings and try to get phobos symbol completion afterwards.
Re: Mono-D v1.6 - method override completion
Okay, just implemented a completion mode for method overrides. I won't explain this over here, as there are screenshots depicting everything properly already :-) http://mono-d.alexanderbothe.com/method-override-completion-v1-6/
Re: Mono-D v1.5.2 - Completion improvements, dub support fixes
For those who don't know what Mono-D is: It's a plug-in for XamarinStudio to give it D editing/building/debugging/project management support which features a large amount of features like semantic highlighting, code completion (now there even is a bit CTFE available for better mixin pre-compile time analysis available), standard code navigation stuff like goto declaration or looking up variable/symbol references in the currently edited file - or well, just take a look at some of the screenshots uploaded to the blog.
[Mono-D] Debugger also available on Windows
Hi everyone, There's debugging functionality in Mono-D on Windows (again - after ~2 years of not having maintained it) now. The blog post (+ screenshot): http://mono-d.alexanderbothe.com/revived-debugging-on-windows/ Further thanks go out to Orvid who has spent some efforts in improving the overall performance of the D parser: std.datetime takes 602ms for being parsed now on Linux while not skipping function bodies, 200ms with skipping them (which is done normally for RamStartup time savings). Now I gotta see how it's performing on Windows..
Re: [Mono-D] Debugger also available on Windows
Now I gotta see how it's performing on Windows.. 539ms without skipping function bodies 150ms with skipping them. Quite nice imho.
Re: New debugger for D!!!
On Monday, 27 January 2014 at 16:42:14 UTC, Sarath Kodali wrote: I'm planning to release a new debugger for D sometime during end of February. This is a heads up for all those who are eagerly looking for a good debugger for D. Which OSs are supported? Which compilers are supported, which debug info base is used? Is the info directly extracted from the executable aka Dwarf/CV4/PDB support? The sample debug session looks cool, so I'd really like to know this to estimate whether it's worth to integrate it into Mono-D or other IDEs :-)
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Tuesday, 14 January 2014 at 08:50:09 UTC, evilrat wrote: On Tuesday, 14 January 2014 at 08:07:57 UTC, Jacob Carlborg wrote: On 2014-01-14 05:10, evilrat wrote: running gdb --interpreter=mi2 launches it without any warnings and errors. (my gdb version is 7.6) I have GNU gdb 6.3.50-20050815 (Apple version gdb-1824). And when I launch it with --interpreter=mi2 I get some extra symbols in the output, like this: ~GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb 6 22:51:23 UTC 2013)\n i have that too, plus additional info and license info k, released an update. Please tell me whether it works or if another exception is getting thrown!
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Tuesday, 14 January 2014 at 13:06:05 UTC, evilrat wrote: gdb plugin version 0.2.5 still gives the same error. Ah, sorry, I should've mentioned it: There's an option panel called Gdb.D now where you can put in a custom gdb command.
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Tuesday, 14 January 2014 at 13:55:10 UTC, evilrat wrote: On Tuesday, 14 January 2014 at 13:16:12 UTC, Alexander Bothe wrote: On Tuesday, 14 January 2014 at 13:06:05 UTC, evilrat wrote: gdb plugin version 0.2.5 still gives the same error. Ah, sorry, I should've mentioned it: There's an option panel called Gdb.D now where you can put in a custom gdb command. it now starts, but in terminal started by xamarin studio it prints: warning: GDB: Failed to set controlling terminal: Operation not permitted\n Known issue, is probably unfixable. Hello World! --- in output panel: Couldn't inject exception handler breakpoint - no finddata symbol found! Could you locate the binary libphobos file, open it e.g. with SciTE and look for some mangled string that contains 'finddata', such as _D2rt15deh_win64_posix13__eh_finddataFPvZPyS2rt15deh_win64_posix9FuncTable - something like this is required to have proper exception hooking :) and after clicking step through it adds: Single stepping until exit from function _Dmain,\nwhich has no line number information. Okay, this means dmd won't generate file/offset associations and/or thus can't be loaded in gdb. If you tried running your D programw with gdb, made a breakpoint at _Dmain and stepped through the method's code - could you tell me whether it's actually possible to step through the lines? Or is it just telling the same? If so, we can forget about having the gdb addin on OSX as the most essential parts of debugging aren't supported (again, just as on Windows) due to mysterious reasons..
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Tuesday, 14 January 2014 at 14:25:31 UTC, evilrat wrote: On Tuesday, 14 January 2014 at 14:12:54 UTC, Alexander Bothe wrote: If you tried running your D programw with gdb, made a breakpoint at _Dmain and stepped through the method's code ... gdb test run (idk why i run with mi2 :( ) No need for having the weird mi2 interface :D http://pastebin.com/U7UTNfxM Okay, so it actually is working - but only partwise. As I just executed that program, I was able to jump into stdin.readln(); as well. Dunno what reason this could have. Could try to extend the sample application to see whether it's skipping everything else either? Btw, could we meet in the irc #d or #d.mono-d ? I'm alex|D-Guy over there, it would be nice to see you there and have little more direct conversation than 'chatting' via the NG/Forum lldb just to compare =0 http://pastebin.com/AxLUTuwy Okay.
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Monday, 13 January 2014 at 05:25:31 UTC, evilrat wrote: after about half year i tried it again on OS X, and Mono-D is quite good for writing the code, but... the debug!!11 can we haz some GDB or LLDB(or both :)) support please? it shouldn't be that hard porting linux code to OS X. it may already doing something useful but it simply doesn't start... I've got no OSX but erm, what tool is required to have lldb information generated? ldc2? On the other side, which tool is then required to get gdb debug info? p.s. also, why at first launch it can't just fetch default phobos location for DMD? it's quite annoying adding this paths in settings and it may revolve unaware users from using it(like it was for me about year ago). Despite it's clearly explained in the set up guide it sounds quite reasonable to do this automatically, you're right.
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Monday, 13 January 2014 at 11:49:57 UTC, evilrat wrote: On Monday, 13 January 2014 at 11:03:45 UTC, Alexander Bothe wrote: On Monday, 13 January 2014 at 05:25:31 UTC, evilrat wrote: after about half year i tried it again on OS X, and Mono-D is quite good for writing the code, but... the debug!!11 can we haz some GDB or LLDB(or both :)) support please? it shouldn't be that hard porting linux code to OS X. it may already doing something useful but it simply doesn't start... I've got no OSX but erm, what tool is required to have lldb information generated? ldc2? On the other side, which tool is then required to get gdb debug info? i don't know about other tools, so basically i just build with dmd files.d -gc and debug using console lldb, of course it was mangled but it is better than nothing. Fortunately I implemented demangling already, so that's not a real problem. So according to Jacob's comment it's actually possible to get gdb on OSX - but probably just with a wrong build configuration, i.e. the mi2 interface for gdb is not available - or is it? Just try executing gdb --interpreter=mi2 to see whether Mono-D is able to handle its output properly.
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Monday, 13 January 2014 at 05:25:31 UTC, evilrat wrote: p.s. also, why at first launch it can't just fetch default phobos location for DMD? it's quite annoying adding this paths in settings and it may revolve unaware users from using it(like it was for me about year ago). Okay, implemented it in v1.3
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Tuesday, 14 January 2014 at 04:15:50 UTC, evilrat wrote: ApplicationName='gdb', CommandLine=-quiet -fullname -i=mi2', CurrentDirectory=, NativeError= Cannot find the specified file Okay, I think I'm gonna make a separate option panel then for setting up the path to gdb.
Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
Hi everyone, Just wrote annotated v1.2.7 of Mono-D: http://mono-d.alexanderbothe.com/completion-ldc2-compatibility-dub-fix-v1-2-7 I'm too lazy to mention every part of it again over here - if there are questions: Here, in #d.mono-d, on the blog, on github - you know the usual places where to find me :) Cheers mates, Alex
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 10 January 2014 at 03:48:35 UTC, Jameson Ernst wrote: On Friday, 10 January 2014 at 03:29:06 UTC, Alexander Bothe wrote: On Friday, 10 January 2014 at 02:33:05 UTC, Jameson Ernst wrote: On a hunch that maybe it has to do with some strange assembly version or mono version mismatch, I used monodis/ilasm to roundtrip the assembly, reassembling it against the dependencies provided in the git repo. It still exhibits the same breakpoint issue, so something is the code itself must be different. I've managed to bypass the addin building system now in v0.2.4.6 - just try to install it and hopefully see the difference :D Still no luck; same behavior when installed via the addin repo. However, I have identified this exception in the logs, that I can confirm occurs only when using the dll from the addin repo, and NOT when using a working built-from-source dll, so the odds that it is related are very high: ERROR [2014-01-09 19:42:34Z]: Error while processing gdb output MonoDevelop.Debugger.Gdb.GdbException: -data-evaluate-expression: Usage: -data-evaluate-expression expression at MonoDevelop.Debugger.Gdb.GdbSession.RunCommand (System.String command, System.String[] args) [0x0] in 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
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
On Thursday, 9 January 2014 at 08:28:21 UTC, Jameson Ernst wrote: Is there a way to configure the plugin to add that option? It doesn't appear to be configurable, at least not from within the IDE. It's done by default already. I've had this same issue, and found that the D debugging plugin doesn't work when using monodevelop later than 4.2.2. I haven't bisected the exact commit where it stops working, but it's definitely somewhere between 4.2.2 and 4.2.3. I've built MD 4.2.3 on my own 3 days ago, there everything works (except debug value tooltips - gotta fix those). I've got gdb 7.6.2 from the AUR as well and quite everything works for me. Other than that though, mono-d is fantastic, and probably the single reason I'm giving D another try after a few years. The auto-completion is REALLY good now, and the semantic highlighting is great. It's hard to give that stuff up coming from C#, but now I don't have to! Thanks! :-)
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Thursday, 9 January 2014 at 18:03:06 UTC, Daniel Kozak wrote: With 4.2.2 everything is OK,but with 4.2.3 it does not work properly. Why do you have gdb from AUR? Where should I get gdb else from? :-P I already noticed some different debugging issues with 4.2.3 - but those were occurring in c# projects. Anyway I just rebuilt MD again to the latest bleeding edge version available (master) and it's still able to run gdb, set breakpoints and evaluate variable values at runtime. Could you check the log for some more info please?
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Thursday, 9 January 2014 at 22:50:09 UTC, Daniel Kozak wrote:
On Thursday, 9 January 2014 at 21:47:40 UTC, Alexander Bothe
wrote:
So btw, could you please define 'does not work'? Is there an
exception, is there just a silent quit, is there a mysterious
return value -1 when executing the program with the debugger?
http://youtu.be/HRJgyFi6Zes
Have you tried other code samples?
Have you tried stepping through code?
Have you tried examing locals via the 'Locals' pad?
Just try to put in a thing like throw new Exception(); to see
whether it's about breakpoints.
Or try to hack in a breakpoint via asm { int 0xcc; } (dunno the
x64 equivalent though :-/) or asm { int3; }
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 10 January 2014 at 00:04:41 UTC, Jameson Ernst wrote:
On Thursday, 9 January 2014 at 23:15:12 UTC, Alexander Bothe
wrote:
On Thursday, 9 January 2014 at 22:50:09 UTC, Daniel Kozak
wrote:
On Thursday, 9 January 2014 at 21:47:40 UTC, Alexander Bothe
wrote:
So btw, could you please define 'does not work'? Is there an
exception, is there just a silent quit, is there a
mysterious return value -1 when executing the program with
the debugger?
http://youtu.be/HRJgyFi6Zes
Have you tried other code samples?
Have you tried stepping through code?
Have you tried examing locals via the 'Locals' pad?
Just try to put in a thing like throw new Exception(); to see
whether it's about breakpoints.
Or try to hack in a breakpoint via asm { int 0xcc; } (dunno
the x64 equivalent though :-/) or asm { int3; }
Ok, I tried cloning the repo for the debugger plugin and
building it from source, and it DOES work now. Strange.
Something about the one in the addin repository must be subtly
different. The video Daniel posted is exactly what happens when
using the one from the addin repo. Program execution WILL stop
on a breakpoint, but the IDE remains unaware of that fact and
acts as if the program is still executing. Throwing an
exception manually DOES cause it to stop though, at which point
I can examine locals as normal. So the problem seems to relate
specifically to breakpoints.
Got to test in my VM. If it's not working there either, I'll just
put the pre-built dll up in my
https://github.com/aBothe/mono-d-bin rage-repo (just to bypass
this ugly addins.md.com building system crap :-D )
Anyway, you can set logGdb
(https://github.com/llucenic/MonoDevelop.Debugger.Gdb.D/blob/master/Gdb/GdbSession.cs#L84)
to be true to let it dump every interaction between Mono-D and
gdb - might be good to know what's wrong with the
breakpoints..I'd be happy if it was MonoDevelop-related, but
well, gotta check it, too.
Thanks for testing it so far :)
At any rate, building the plugin from source seems to be the
ticket. If you want me to test out anything else, I'd be happy
to, since I think it's important this should work out of box
for as many people as possible. It is worth noting that I had
the same symptoms when using mono-d debugging on a Linux Mint
15 install, so it's nothing specific to Arch.
kk :-)
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 10 January 2014 at 02:33:05 UTC, Jameson Ernst wrote: On a hunch that maybe it has to do with some strange assembly version or mono version mismatch, I used monodis/ilasm to roundtrip the assembly, reassembling it against the dependencies provided in the git repo. It still exhibits the same breakpoint issue, so something is the code itself must be different. I've managed to bypass the addin building system now in v0.2.4.6 - just try to install it and hopefully see the difference :D
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On 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: Non-anonymous mixin template fix [v1.0.1]
On Wednesday, 8 January 2014 at 14:24:07 UTC, extrawurst wrote: thanks for implementing the label stuff ;) And another daily :) http://mono-d.alexanderbothe.com/ddoc-params-sections-v1-2/
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Tuesday, 7 January 2014 at 06:18:44 UTC, ilya-stromberg wrote: On Monday, 6 January 2014 at 23:58:46 UTC, Alexander Bothe wrote: On Thursday, 2 January 2014 at 20:13:33 UTC, Daniel Kozak wrote: I must admit, that you do lots of awsome work on this IDE (plugin). But still it is quiet bad. After clean install I am not able to run even basic hello world. Ok I can uninstall gnome-terminal and install xterm. After that I can run basic terminal apps, but not debug them :(. Maybe it would be better to stop adding new features and try to make it more stable. Are you using Ubuntu? Perhaps installing libgnome-ui might solve the problem. Anyway, issues like these are mostly caused by MonoDevelop which can't be run on such a huge variety of Linux setups without further efforts - so how does this relate to stability when I actually am able to 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: Non-anonymous mixin template fix [v1.0.1]
On Tuesday, 7 January 2014 at 00:21:49 UTC, Alexander Bothe wrote: Cheers, Alex
Re: Non-anonymous mixin template fix [v1.0.1]
On Tuesday, 7 January 2014 at 00:21:49 UTC, Alexander Bothe wrote: Cheers, Alex Sry for accidently pressing Tab and Return while typing..anyway: A new 'daily' release: http://mono-d.alexanderbothe.com/completion-stuff-v1-1-1-1-1/
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Thursday, 2 January 2014 at 20:13:33 UTC, Daniel Kozak wrote: I must admit, that you do lots of awsome work on this IDE (plugin). But still it is quiet bad. After clean install I am not able to run even basic hello world. Ok I can uninstall gnome-terminal and install xterm. After that I can run basic terminal apps, but not debug them :(. Maybe it would be better to stop adding new features and try to make it more stable. Are you using Ubuntu? Perhaps installing libgnome-ui might solve the problem. Anyway, issues like these are mostly caused by MonoDevelop which can't be run on such a huge variety of Linux setups without further efforts - so how does this relate to stability when I actually am able to rundebug programs?
Non-anonymous mixin template fix [v1.0.1]
Hi everyone, Just a small bug fix release, nothing special: http://mono-d.alexanderbothe.com/named-mixin-completion-fix-v1-0-1 As you might have noticed, Mono-D has the version 1.x now - as an indicator of modified requirements regarding MonoDevelop/XamarinStudio: It's just required to have at least version 4.2 of it now, nothing else. Thanks for the precious recommendation to use semantic versioning (http://semver.org/)! :-) Anyway, if there's anyone with a good idea to have a more stable Mono-D/MonoDevelop environment, please tell me. I personally don't think that I can manage to have two separate releases out there - simply because everything was totally mixed up if there (surely will) appear cross-versioned bugs/issues which would consider the (so far) stable release as unstable, obviously. If it's about MonoDevelop in general and your system's setup is too different from mine and it's simply impossible to 'have it there via one extract execute', I could try to write manuals for each OS and distro that needs further assistance - if you told me how you've managed to get it working entirely. Furthermore, in case of completion issues: https://github.com/aBothe/D_Parser/issues and for all the other Mono-D aspects: https://github.com/aBothe/Mono-D/issues Cheers, Alex
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Saturday, 28 December 2013 at 03:13:10 UTC, Casper Færgemand wrote: On Saturday, 28 December 2013 at 02:02:44 UTC, Alexander Bothe wrote: May I have some code samples? Writing 'SysTime' may happen everywhere - as well as 'a similar null-pointer' .. I have no magic glass bowl to look in, you know. ;-) I can't reproduce it in a new file. I can, however, go to any line in my existing project, press a key on the keyboard, and the code completion window crashes with a null pointer. Not sure what you want aside from that. I don't see why it would have anything to do with what code I've written. My only import outside Phobos is Pegged. D_Parser.Dom.DefaultDepthFirstVisitor.Visit(ArrayLiteralExpression x) Okay, I think that I've fixed it now although I still can't reproduce this exception in any wise - neither in my trivial test programs nor in std.datetime (just noticed that halfway fluid editing with all code completion and stuff is possible there either - despite 35k LOC) How am I supposed to test things I've never seen before?
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Saturday, 28 December 2013 at 06:55:21 UTC, ilya-stromberg wrote: When I used `ppa:keks9n/monodevelop-latest` repro, the MonoDevelop updated every day. So, it was alpha version. BTW, I had a lot of problems with it, new `ppa:ermshiperete/monodevelop` looks much better. Although I'm rather interested in providing a good platform for everyone I can't keep an eye for everything. As I've also left Ubuntu I honestly don't care about this apt-get magic anymore. I'm providing my own MD distro which is working with most setups and that's it. If someone's willed to use other versions, I can't care about each platform's specific release strategies. I repeat, please write supported MonoDevelop version at the download page. You have too many opportunities for Ubuntu: we have 3 different repros and nobody knows the correct one. BTW, `ppa:ermshiperete/monodevelop` contains pre-installed Mono-D, so it looks like the maintainer wants to support correct MonoDevelop version for Mono-D. If I write 4.2.2 somewhere at the bottom, it can be the case that there are different releases called 4.2.2 - featuring broken API and other things. I've been following that 'development' over the last couple of years - and it was deadly annoying to have broken API and nonsense exceptions after each rebuild. Yes, this might be the issue with Mono-D as well, but as soon as I'm introducing new features it's very often the case that internals change - and therewith new regressions/throw-cases rise. I'm also no test engineer who is willed to build GUI test infrastructures - perhaps I just could code more carefully, but well, even then unexpected situations will(!, I've had these situations often enough now) occur. Additional request: please use more intuitive version number, see http://semver.org/ because current version scheme doesn't provide any additional information. Please use: 1) 1-st digit if you need to upgrade the MonoDevelop version with incompatible API changes 2) 2-nd digit if you have new features, code refactoring or any other big code change 3) 3-d digit if you have only bug fixes It can help a lot. For example, 2 last Mono-D versions should have 0.5.6.0 and 0.5.6.1 numbers. Same stuff here: I'm using these numbers just to indicate an update for MD's update manager. If I could, I wouldn't even use those - as with all the continous integration there can be API changes everytime - either via Refactoring or via new feature introduction or even via bug fixing. I probably would have released Mono-D v456 now if I followed these strict rules. Or you have a second setup which is just dedicated for some final user verification. Or you just come back in a year and check it out again - if Mono-D still exists then, who knows.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Saturday, 28 December 2013 at 06:55:21 UTC, ilya-stromberg wrote: Additional request: please use more intuitive version number, see http://semver.org/ because current version scheme doesn't provide any additional information. Please use: 1) 1-st digit if you need to upgrade the MonoDevelop version with incompatible API changes 2) 2-nd digit if you have new features, code refactoring or any other big code change 3) 3-d digit if you have only bug fixes It can help a lot. For example, 2 last Mono-D versions should have 0.5.6.0 and 0.5.6.1 numbers. Anyway, thank you for the hint. I think I'll push a new major version as soon as there's a new MD version that features breaking API - although it must feel strange to have so ridiculously high version numbers (see Chrome/FF and others). Numbers greater than 9 should be okay as well - so I'll have versions like 22.30.4 then :-) Cheers, Alex
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Saturday, 28 December 2013 at 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! :-)
Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
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
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 27 December 2013 at 17:52:22 UTC, ilya-stromberg wrote: I have only one request: can you focus at the Mono-D stability? I saw a few errors last time (I'm not shure if it was Mono Develop errors or Mono-D errors). Then please tell me as soon as they appear! Assuming that you've got a longer programming experience, you should know well that silent/destructive raging won't help anybody! :) So, can you use only stable Mono Develop versions and print current required Mono Develop version? That's one thing I did for the last bunch of years. I hated it, brought even more confusion and I had doubled circumstances to manage everything. Atm I'm very happy that I can even release Mono-D for all 3 major OS platforms exclusively via addins.monodevelop.com which is the built-in distribution platform of MD. Also, can you create betta/rc versions of Mono-D and, maybe, create separate repro for it? I'd rather recommend to downgrade if something is not working at all - or just skip versions (like the usual main release followed by several bug fix releases - It's always your choice not to update!) I know this implies some efforts (head to http://addins.monodevelop.com/Project/Index/27 and select an older release :-)) but ensures that quite everyone is using the very latest version. Only then I can locate 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
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
On Friday, 27 December 2013 at 20:23:51 UTC, Casper Færgemand
wrote:
I'll take it back. When writing a module specification, it kept
interrupting me with this error. Due to an annoying error in
Mono-Develop, I cannot change the language in the program
without changing it in my OS, which I don't bother this moment.
I have translated the first line, it's in {}. ved means at.
{ System.NullReferenceException: The objekt reference is not
configured to an occurence of an object. }
System.NullReferenceException: Objektreferencen er ikke
indstillet til en forekomst af et objekt.
ved
D_Parser.Dom.DefaultDepthFirstVisitor.Visit(ArrayLiteralExpression
x)
Makes me smile :-D
That's the usual stuff I'm talking about - those classical places
of null-ref exceptions where I simply couldn't imagine they could
occur at exactly that location.
Module specification - like module ABC; ? You'll laugh: It works
for me, no exception when trying to write such statement.
Furthermore I had to wonder why it's throwing at visiting
ArrayLiterals..anyway, thanks for the quick report.
Looking at the code, there's not even the possibility to have an
NRE occuring over there. Something weird happened again.
Cheers,
Alex
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 27 December 2013 at 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.
Mono-D v0.5.4.8 - DMD 2.064 Compatibility + Completion fixes
Hi everyone, I just released a new version of Mono-D which features quite all the new D magic that appeared in dmd 2.064 http://mono-d.alexanderbothe.com/dmd-2-064-compatibility-completion-fixes-v0-5-4-8/ Completion issues: https://github.com/aBothe/D_Parser/issues General/Other issues: https://github.com/aBothe/Mono-D/issues Gonna get some sleep now :) Cheers, Alex
Re: Visual D 0.3.37 released
On Tuesday, 5 November 2013 at 05:09:58 UTC, Manu wrote: Note: I saw Alexander Bothe released an update to the parser one day after your release... ;) Sure, there have been a couple of critical regression bugs in the parser engine. Furthermore, I re-enabled the ufcs completion. Rainer, I somehow really recommend to provide a more frequent way to update the D_Parser.dll - just to provide a way to fix e.g. completion issues without having to recompile/package/upload the entire VisualD setup. An automated build system which simply calls git pull and xbuild DParser2/DParser2.csproj already suffices. I could insert a push hook into the repo which is executed then in order to inform the build system to do a rebuild. It also was possible to execute Unittests first, so in the case that there are some regression bugs (as it happened just recently), it simply won't be distributed. Finally, a small webserver providing the built dll (or a zip of it) and a check whether there's an update available will passively distribute the dll to all clients. Not to forget some security things like hash check or encryption etc. Also, the D_Parser.dll could be put into the AppData/Roaming folder, so no admin rights are needed for a parser update. What do you think about this?
Re: Visual D 0.3.37 released
On Wednesday, 6 November 2013 at 14:43:35 UTC, Dicebot wrote: Regarding project files - I like Mono-D attempt to support dub package.json as project description file. Regarding semantical analysis - both Mono-D and VisualD should just merged efforts with DCD, problem solved :) I dunno, there's probably just a small read method required in order to read .visualdproj files..gonna have a look at it.
Re: Visual D 0.3.37 released
On Wednesday, 6 November 2013 at 17:49:57 UTC, Dicebot wrote: Picking common standard for all possible IDE's scales better than cloning approach of a single one (especially if this one is closed and known of forcing closed ecosystems) Essentially, dub. I'm okay with that decision :-P
Re: Visual D 0.3.37 released
On Thursday, 7 November 2013 at 05:45:34 UTC, Rainer Schuetze wrote: On 06.11.2013 09:25, Alexander Bothe wrote: On Tuesday, 5 November 2013 at 05:09:58 UTC, Manu wrote: Note: I saw Alexander Bothe released an update to the parser one day after your release... ;) Sure, there have been a couple of critical regression bugs in the parser engine. Furthermore, I re-enabled the ufcs completion. Rainer, I somehow really recommend to provide a more frequent way to update the D_Parser.dll - just to provide a way to fix e.g. completion issues without having to recompile/package/upload the entire VisualD setup. An automated build system which simply calls git pull and xbuild DParser2/DParser2.csproj already suffices. I could insert a push hook into the repo which is executed then in order to inform the build system to do a rebuild. It also was possible to execute Unittests first, so in the case that there are some regression bugs (as it happened just recently), it simply won't be distributed. Finally, a small webserver providing the built dll (or a zip of it) and a check whether there's an update available will passively distribute the dll to all clients. Not to forget some security things like hash check or encryption etc. Yeah, being able to get releases out more often, and having bug fixes being tested in the field would be nice. But I think we should not over-engineer things here. Do you have a web-server that could do the compilation? No - I just have got a normal dedicated web-server thingy for phpmysql ^_^ But well, just a very small infrastructure that allows us to update software more often - a couple of hours ago I implemented this new eponymous template syntax..and now you had to release another VisualD to have it in there, right? Also, the D_Parser.dll could be put into the AppData/Roaming folder, so no admin rights are needed for a parser update. The component being used by Visual D is a local COM server, I'm not sure if it is good to have that in a user folder. Okay, it's probably safer to let the user decide when to update only.
Mono-D v0.5.4.7 - Refactoring issue fixes completion fixes
Hi everyone, not a big release, just a small bump for Mono-D and D_Parser :-) http://mono-d.alexanderbothe.com/internal-refactoring-feature-cleanup-completion-fixes-v0-5-4-7/ Completion issues: https://github.com/aBothe/D_Parser/issues Other issues: https://github.com/aBothe/Mono-D/issues Cheers, Alex
Re: DUB 0.9.19 has been released
On Friday, 18 October 2013 at 15:58:04 UTC, Sönke Ludwig wrote: Major changes since 0.9.18 - Added support for dub build package name and dub run package name to build/run a specific package instead of the root package in the current directory. This works for any installed packages, as well as for sub packages. Perfect. Now I can make Mono-D be able to build/run specific sub packages! :)
Mono-D v0.5.4.5 - More dub support
Hi everyone, Just sat down the last couple of days and tried to adapt further MonoDevelop project architecture and other related functionality to dub. Seems to work (for me™) for some basic dub configurations so far. Debugging dub projects (by using the right addin for it *cough*) has become available as well! I guess there's no need to manually export the dub config to a dedicated Mono-D project file anymore from now on :) I've written some documentation about changes, can's and cannot's in the mono-d blog: http://mono-d.alexanderbothe.com/v0-5-4-5-more-dub-support/ The raw changelog: https://github.com/aBothe/Mono-D/commits/master Issues/Bugs etc: https://github.com/aBothe/Mono-D/issues Have fun testing the new features (and filing issue reports)!
Re: Mono-D 0.5.4.1 - Build, completion other fixes + Unittests via rdmd
On Tuesday, 8 October 2013 at 13:21:17 UTC, Dicebot wrote: This time, the addin should be compatible to older beta versions of MonoDevelop (like 4.0.12) as well – so feel free to simply try it out. _very_ glad to hear that. Thanks for your work! Can't guarantee anything! I've just work-arounded that IReferenceContext-missing exception, but as this was like the only change in the near past I hope it'll be runnable again.
Re: Mono-D 0.5.4.1 - Build, completion other fixes + Unittests via rdmd
On Tuesday, 8 October 2013 at 18:03:25 UTC, Johannes Pfau wrote: BTW: MonoDevelop is broken on Gnome 3.10 now. They changed something in gnome-terminal and now MonoDevelop can't open the terminal anymore :-( Disabling the external console should work but MonoDevelop seems to ignore that option. Workaround: https://github.com/mono/monodevelop/pull/414 Okay, nice, I'll put a new build on http://simendsjo.me/files/abothe/ as soon as it's been taken into master.
News from D-IDE
Hey everyone, D-IDE 1.0.4.0 released...just check it out and give me your exception reports ;-) http://d-ide.sourceforge.net
