www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - [Mono-D] v2.1.18 Parser/Completion/General fixes&improvements

reply "Alex" <info alexanderbothe.com> writes:
Hey everyone,

it's been quite some while ago that I posted a Mono-D release 
announcement on to D.announce :)

You should've noticed that the installation instruction stuff has 
been moved to
the D wiki - http://wiki.dlang.org/Mono-D

There have been several fixes and smaller improvements since the 
last bunch of bug fix releases.
Detailed release notes can be taken from the wiki entry.



Cheers,
Alex
Aug 13 2014
next sibling parent reply =?UTF-8?B?IlRow6lv?= Bueno" <munrek gmx.com> writes:
On Wednesday, 13 August 2014 at 14:16:18 UTC, Alex wrote:
 Hey everyone,

 it's been quite some while ago that I posted a Mono-D release 
 announcement on to D.announce :)

 You should've noticed that the installation instruction stuff 
 has been moved to
 the D wiki - http://wiki.dlang.org/Mono-D

 There have been several fixes and smaller improvements since 
 the last bunch of bug fix releases.
 Detailed release notes can be taken from the wiki entry.



 Cheers,
 Alex
We definetely should promote Mono-D along with Visual D, and move your documentation stuff from the wiki to the website. Again, thank you for your awesome work :)
Aug 13 2014
parent "Alex" <info alexanderbothe.com> writes:
On Wednesday, 13 August 2014 at 14:23:47 UTC, Théo Bueno wrote:
 On Wednesday, 13 August 2014 at 14:16:18 UTC, Alex wrote:
 Hey everyone,

 it's been quite some while ago that I posted a Mono-D release 
 announcement on to D.announce :)

 You should've noticed that the installation instruction stuff 
 has been moved to
 the D wiki - http://wiki.dlang.org/Mono-D

 There have been several fixes and smaller improvements since 
 the last bunch of bug fix releases.
 Detailed release notes can be taken from the wiki entry.



 Cheers,
 Alex
We definetely should promote Mono-D along with Visual D, and move your documentation stuff from the wiki to the website. Again, thank you for your awesome work :)
Only if I have wiki-like online editing available then :P -- I don't want to mess with hardcore html anymore :-/
Aug 13 2014
prev sibling next sibling parent reply simendsjo <simendsjo gmail.com> writes:
On 08/13/2014 04:16 PM, Alex wrote:
(...)
 You should've noticed that the installation instruction stuff has been
 moved to
 the D wiki - http://wiki.dlang.org/Mono-D
(...) Is it just me, or is there something very strange going on with the wiki? Seems a lot of CSS isn't applied on that page and the front page - No logo, login, edit etc etc (navigation at the bottom). Other pages looks fine though. Just my browser, or is anyone else experiencing the same issue?
Aug 13 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 13 August 2014 at 18:13:22 UTC, simendsjo wrote:
 On 08/13/2014 04:16 PM, Alex wrote:
 (...)
 You should've noticed that the installation instruction stuff 
 has been
 moved to
 the D wiki - http://wiki.dlang.org/Mono-D
(...) Is it just me, or is there something very strange going on with the wiki? Seems a lot of CSS isn't applied on that page and the front page - No logo, login, edit etc etc (navigation at the bottom). Other pages looks fine though. Just my browser, or is anyone else experiencing the same issue?
Can confirm. It was OK just a few hours ago though
Aug 13 2014
parent reply Orvid King <blah38621 gmail.com> writes:
On 8/13/2014 1:32 PM, Dicebot wrote:
 On Wednesday, 13 August 2014 at 18:13:22 UTC, simendsjo wrote:
 On 08/13/2014 04:16 PM, Alex wrote:
 (...)
 You should've noticed that the installation instruction stuff has been
 moved to
 the D wiki - http://wiki.dlang.org/Mono-D
(...) Is it just me, or is there something very strange going on with the wiki? Seems a lot of CSS isn't applied on that page and the front page - No logo, login, edit etc etc (navigation at the bottom). Other pages looks fine though. Just my browser, or is anyone else experiencing the same issue?
Can confirm. It was OK just a few hours ago though
It's working fine for me using Opera, although the CSS may very well be cached for me...
Aug 13 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 13 August 2014 at 20:27:42 UTC, Orvid King wrote:
 Can confirm. It was OK just a few hours ago though
It's working fine for me using Opera, although the CSS may very well be cached for me...
It has recovered ;)
Aug 13 2014
parent reply simendsjo <simendsjo gmail.com> writes:
On 08/13/2014 10:45 PM, Dicebot wrote:
 On Wednesday, 13 August 2014 at 20:27:42 UTC, Orvid King wrote:
 Can confirm. It was OK just a few hours ago though
It's working fine for me using Opera, although the CSS may very well be cached for me...
It has recovered ;)
Not for me. Doesn't work in firefox either (and I'm pretty sure I haven't visited the wiki ever with firefox).
Aug 13 2014
parent "Alex" <info alexanderbothe.com> writes:
On Wednesday, 13 August 2014 at 20:47:41 UTC, simendsjo wrote:
 Not for me. Doesn't work in firefox either (and I'm pretty sure 
 I
 haven't visited the wiki ever with firefox).
/me leans back and enjoys the OT Still not working for me either. But no problem, it's the text and the images that count :-P
Aug 13 2014
prev sibling parent reply "Damian Day" <damianroyday gmail.com> writes:
On Wednesday, 13 August 2014 at 14:16:18 UTC, Alex wrote:
 Hey everyone,

 it's been quite some while ago that I posted a Mono-D release 
 announcement on to D.announce :)

 You should've noticed that the installation instruction stuff 
 has been moved to
 the D wiki - http://wiki.dlang.org/Mono-D

 There have been several fixes and smaller improvements since 
 the last bunch of bug fix releases.
 Detailed release notes can be taken from the wiki entry.



 Cheers,
 Alex
Have you considered integrating some of Brian Schotts work? Perhaps an option to pick an engine DCD or DParser. I'm particularly interested in dscanner integration myself :)
Aug 13 2014
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Wednesday, 13 August 2014 at 21:29:01 UTC, Damian Day wrote:
 On Wednesday, 13 August 2014 at 14:16:18 UTC, Alex wrote:
 Hey everyone,

 it's been quite some while ago that I posted a Mono-D release 
 announcement on to D.announce :)

 You should've noticed that the installation instruction stuff 
 has been moved to
 the D wiki - http://wiki.dlang.org/Mono-D

 There have been several fixes and smaller improvements since 
 the last bunch of bug fix releases.
 Detailed release notes can be taken from the wiki entry.



 Cheers,
 Alex
Have you considered integrating some of Brian Schotts work? Perhaps an option to pick an engine DCD or DParser.
I'm not sure you'd want to do that. The DParser completion engine has a few features that DCD doesn't have. (I'm not sure if this is true the other way around)
 I'm particularly interested in dscanner integration myself :)
Are you talking about displaying static analysis hints in the editor window, or something else?
Aug 13 2014
next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Wednesday, 13 August 2014 at 21:35:26 UTC, Brian Schott wrote:
 I'm not sure you'd want to do that. The DParser completion 
 engine has a few features that DCD doesn't have. (I'm not sure 
 if this is true the other way around)

 I'm particularly interested in dscanner integration myself :)
Are you talking about displaying static analysis hints in the editor window, or something else?
It would be nice if we could have one unified auto complete engine instead of several different engines of varying quality and feature sets. But it is only a dream.
Aug 13 2014
parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Wednesday, 13 August 2014 at 21:48:57 UTC, Tofu Ninja wrote:
 It would be nice if we could have one unified auto complete 
 engine instead of several different engines of varying quality 
 and feature sets. But it is only a dream.
For that matter... it would be nice to have just one unified parser.....
Aug 13 2014
prev sibling parent reply "Damian Day" <damianroyday gmail.com> writes:
On Wednesday, 13 August 2014 at 21:35:26 UTC, Brian Schott wrote:
 On Wednesday, 13 August 2014 at 21:29:01 UTC, Damian Day wrote:
 On Wednesday, 13 August 2014 at 14:16:18 UTC, Alex wrote:
 Hey everyone,

 it's been quite some while ago that I posted a Mono-D release 
 announcement on to D.announce :)

 You should've noticed that the installation instruction stuff 
 has been moved to
 the D wiki - http://wiki.dlang.org/Mono-D

 There have been several fixes and smaller improvements since 
 the last bunch of bug fix releases.
 Detailed release notes can be taken from the wiki entry.



 Cheers,
 Alex
Have you considered integrating some of Brian Schotts work? Perhaps an option to pick an engine DCD or DParser.
I'm not sure you'd want to do that. The DParser completion engine has a few features that DCD doesn't have. (I'm not sure if this is true the other way around)
That's true, but duplicated work and all that.. It would be a nice way to battle test DCD and the lexer.
 I'm particularly interested in dscanner integration myself :)
Are you talking about displaying static analysis hints in the editor window, or something else?
Yes precisely.
Aug 13 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 14 August 2014 at 00:43:38 UTC, Damian Day wrote:
 I'm not sure you'd want to do that. The DParser completion 
 engine has a few features that DCD doesn't have. (I'm not sure 
 if this is true the other way around)
That's true, but duplicated work and all that.. It would be a nice way to battle test DCD and the lexer.
Keep in mind that integrating a lexer/parser written in C# into an IDE written in C# is much easier than integrating libdparse would be. The same argument applies to Eclipse and Visual Studio.
 I'm particularly interested in dscanner integration myself :)
Are you talking about displaying static analysis hints in the editor window, or something else?
Yes precisely.
This should be easy. I have Textadept set up to do this and the implementation is only a few lines long. https://github.com/Hackerpilot/TextadeptModules/blob/master/modules/dmd/init.lua#L29-54
Aug 13 2014
next sibling parent reply "Alex" <info alexanderbothe.com> writes:
On Thursday, 14 August 2014 at 00:54:07 UTC, Brian Schott wrote:
 On Thursday, 14 August 2014 at 00:43:38 UTC, Damian Day wrote:
 I'm not sure you'd want to do that. The DParser completion 
 engine has a few features that DCD doesn't have. (I'm not 
 sure if this is true the other way around)
That's true, but duplicated work and all that.. It would be a nice way to battle test DCD and the lexer.
Keep in mind that integrating a lexer/parser written in C# into an IDE written in C# is much easier than integrating libdparse would be. The same argument applies to Eclipse and Visual Studio.
Invoking stuff is easy. I'd rather reimplement the communication to the dcd server instead to not get such a bottleneck if you're on windows or typing really fast. Executing an entire program for each keystroke is a real unsustainable solution, imho.
 I'm particularly interested in dscanner integration myself :)
Are you talking about displaying static analysis hints in the editor window, or something else?
Yes precisely.
This should be easy. I have Textadept set up to do this and the implementation is only a few lines long. https://github.com/Hackerpilot/TextadeptModules/blob/master/modules/dmd/init.lua#L29-54
This seems rather easy to implement.
Aug 14 2014
parent reply "Alex" <info alexanderbothe.com> writes:
On Thursday, 14 August 2014 at 07:07:59 UTC, Alex wrote:
 Invoking stuff is easy. I'd rather reimplement the 
 communication to the dcd server instead to not get such a 
 bottleneck if you're on windows or typing really fast. 
 Executing an entire program for each keystroke is a real 
 unsustainable solution, imho.
https://github.com/Hackerpilot/DCD/blob/master/client.d#L72 Alright. :-)
Aug 14 2014
parent reply "dlangophile" <dlangophile foo.bar> writes:
On Thursday, 14 August 2014 at 07:51:11 UTC, Alex wrote:
 On Thursday, 14 August 2014 at 07:07:59 UTC, Alex wrote:
 Invoking stuff is easy. I'd rather reimplement the 
 communication to the dcd server instead to not get such a 
 bottleneck if you're on windows or typing really fast. 
 Executing an entire program for each keystroke is a real 
 unsustainable solution, imho.
https://github.com/Hackerpilot/DCD/blob/master/client.d#L72 Alright. :-)
Actually, someone has turned on the _"Enable Mixin & Template Mixin Analysis"_ options? Major drawbacks? Someone has turned _off_ the _"Only indent code lines instead of rearrange code parts"_? Major drawbacks? Bye, dlangophile
Aug 23 2014
parent "Alex" <info alexanderbothe.com> writes:
On Saturday, 23 August 2014 at 13:19:18 UTC, dlangophile wrote:
 On Thursday, 14 August 2014 at 07:51:11 UTC, Alex wrote:
 On Thursday, 14 August 2014 at 07:07:59 UTC, Alex wrote:
 Invoking stuff is easy. I'd rather reimplement the 
 communication to the dcd server instead to not get such a 
 bottleneck if you're on windows or typing really fast. 
 Executing an entire program for each keystroke is a real 
 unsustainable solution, imho.
https://github.com/Hackerpilot/DCD/blob/master/client.d#L72 Alright. :-)
Actually, someone has turned on the _"Enable Mixin & Template Mixin Analysis"_ options? Major drawbacks?
I did - basic stuff which was tested works :-P https://github.com/aBothe/D_Parser/blob/master/Tests/ResolutionTests.cs#L3151-L3380
 Someone has turned _off_ the _"Only indent code lines instead of
 rearrange code parts"_?
 Major drawbacks?
I haven't implemented any new formatting features since indenting is totally satisfying for me. :-)
Aug 26 2014
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 14/08/2014 01:54, Brian Schott wrote:
 On Thursday, 14 August 2014 at 00:43:38 UTC, Damian Day wrote:
 I'm not sure you'd want to do that. The DParser completion engine has
 a few features that DCD doesn't have. (I'm not sure if this is true
 the other way around)
That's true, but duplicated work and all that.. It would be a nice way to battle test DCD and the lexer.
Keep in mind that integrating a lexer/parser written in C# into an IDE written in C# is much easier than integrating libdparse would be. The same argument applies to Eclipse and Visual Studio.
True, but I'm now convinced that most likely, an IDE/editor architecture where most (if not all) of semantic analysis and operations are performed by an external tool, is the way forward. (Steve Teale made a case for this in a post quite some time ago, I wasn't that convinced then, but I am now) The market of IDEs/editors for new languages is extremely saturated. Even for older, consolidated languages, the market has become more diverse. It used be that Eclipse-JDT was king for Java, or Visual Studio for C# (and C++ to a degree). But now a lot of people swear by IntelliJ IDEA and Netbeans (for Java), and there's MonoDevelop too, for C#. This means its increasingly harder for each IDE/editor to develop their own, full semantic engine, since there is more competition. Especially for upcoming languages where most tooling is being develop by volunteers. With this realization I have started to move DDT to this architecture, it's something that I have been working for the past few months.
 I'm particularly interested in dscanner integration myself :)
Are you talking about displaying static analysis hints in the editor window, or something else?
Yes precisely.
BTW, what is the relation of dscanner to DCD? Or more precisely, why are they separate tools?.. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Sep 04 2014
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 4 September 2014 at 22:05:35 UTC, Bruno Medeiros 
wrote:
 BTW, what is the relation of dscanner to DCD? Or more 
 precisely, why are they separate tools?..
Originally there was just dscanner. One of the things that it did was autocomplete. It wasn't very good at this for a variety of reasons. One of them was that being a plain command-line tool, it had to re-parse EVERYTHING every time you asked for autocomplete. Over time I split the project three ways: The parser/lexer/ast is now libdparse, the autocomplete functionality is in DCD, and static analysis and other stuff is in dscanner.
Sep 04 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 05/09/2014 00:23, Brian Schott wrote:
 On Thursday, 4 September 2014 at 22:05:35 UTC, Bruno Medeiros wrote:
 BTW, what is the relation of dscanner to DCD? Or more precisely, why
 are they separate tools?..
Originally there was just dscanner. One of the things that it did was autocomplete. It wasn't very good at this for a variety of reasons. One of them was that being a plain command-line tool, it had to re-parse EVERYTHING every time you asked for autocomplete. Over time I split the project three ways: The parser/lexer/ast is now libdparse, the autocomplete functionality is in DCD, and static analysis and other stuff is in dscanner.
The reason I ask is because there seems to be some functionality only present in dscanner that would be useful for IDEs too, such as "dscanner --declaration" -- Bruno Medeiros https://twitter.com/brunodomedeiros
Sep 09 2014
parent "Brian Schott" <briancschott gmail.com> writes:
On Tuesday, 9 September 2014 at 13:46:06 UTC, Bruno Medeiros 
wrote:
 The reason I ask is because there seems to be some 
 functionality only present in dscanner that would be useful for 
 IDEs too, such as "dscanner --declaration"
I added that feature because I wanted something usable from the command line that was more accurate than grep or ack. There's an enhancement request for adding something similar to DCD: https://github.com/Hackerpilot/DCD/issues/162.
Sep 10 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 05/09/14 00:05, Bruno Medeiros wrote:

 True, but I'm now convinced that most likely, an IDE/editor architecture
 where most (if not all) of semantic analysis and operations are
 performed by an external tool, is the way forward. (Steve Teale made a
 case for this in a post quite some time ago, I wasn't that convinced
 then, but I am now)
Perhaps I'm nitpicking but an external tools doesn't sound like a good idea. A completely separate library that can be shared among tools and be integrated into an IDE, absolutely yes. But not a tool. -- /Jacob Carlborg
Sep 04 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 05/09/2014 07:32, Jacob Carlborg wrote:
 Perhaps I'm nitpicking but an external tools doesn't sound like a good
 idea. A completely separate library that can be shared among tools and
 be integrated into an IDE, absolutely yes. But not a tool.
It's like it was said earlier, a library is easier to integrate, but only if across the same language (for the code the library is written in, and the code the IDE extensions are written in). -- Bruno Medeiros https://twitter.com/brunodomedeiros
Sep 05 2014
parent reply "Alex" <info alexanderbothe.com> writes:
On Friday, 5 September 2014 at 12:15:09 UTC, Bruno Medeiros wrote:
 On 05/09/2014 07:32, Jacob Carlborg wrote:
 Perhaps I'm nitpicking but an external tools doesn't sound 
 like a good
 idea. A completely separate library that can be shared among 
 tools and
 be integrated into an IDE, absolutely yes. But not a tool.
It's like it was said earlier, a library is easier to integrate, but only if across the same language (for the code the library is written in, and the code the IDE extensions are written in).
Well, I spent a (very little though) time getting informed on how everything could be done using dcd-server running in the background. 1) the communication between dcd-server and dcd-client happens via tcp ipc. So extremely easy to implement 2) The currently edited module's text can be piped through that IPC channel to not have to query the hardware IO all the time. 3) My completion 'model' allows having individual import paths for each edited file, project, super-project aka solution. DCD seems not to support this atm(?). 4) D_Parser is heavily woven with all kinds of Mono-D features, so just ripping out the completion component and replacing it with dcd won't bring anything sustainable, since I'd still had to have raw access to all ASTs out there in order to e.g. display a 'breadcrumb' path bar on the editor's top, the doc outline, refactoring features etc. -- An entirely separate Mono-D is needed imho which probably only features basic projecting/build support as well as dcd bindings. Did you, Bruno, discarded your customly written completion framework in favor of dcd?
Sep 05 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-09-05 18:40, Alex wrote:

 4) D_Parser is heavily woven with all kinds of Mono-D features, so just
 ripping out the completion component and replacing it with dcd won't
 bring anything sustainable, since I'd still had to have raw access to
 all ASTs out there in order to e.g. display a 'breadcrumb' path bar on
 the editor's top, the doc outline, refactoring features etc. -- An
 entirely separate Mono-D is needed imho which probably only features
 basic projecting/build support as well as dcd bindings.
There are still all the other components that dcd is made of like libdparse for example. -- /Jacob Carlborg
Sep 05 2014
prev sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 05/09/2014 17:40, Alex wrote:
 On Friday, 5 September 2014 at 12:15:09 UTC, Bruno Medeiros wrote:
 On 05/09/2014 07:32, Jacob Carlborg wrote:
 Perhaps I'm nitpicking but an external tools doesn't sound like a good
 idea. A completely separate library that can be shared among tools and
 be integrated into an IDE, absolutely yes. But not a tool.
It's like it was said earlier, a library is easier to integrate, but only if across the same language (for the code the library is written in, and the code the IDE extensions are written in).
Well, I spent a (very little though) time getting informed on how everything could be done using dcd-server running in the background. 1) the communication between dcd-server and dcd-client happens via tcp ipc. So extremely easy to implement 2) The currently edited module's text can be piped through that IPC channel to not have to query the hardware IO all the time. 3) My completion 'model' allows having individual import paths for each edited file, project, super-project aka solution. DCD seems not to support this atm(?). 4) D_Parser is heavily woven with all kinds of Mono-D features, so just ripping out the completion component and replacing it with dcd won't bring anything sustainable, since I'd still had to have raw access to all ASTs out there in order to e.g. display a 'breadcrumb' path bar on the editor's top, the doc outline, refactoring features etc. -- An entirely separate Mono-D is needed imho which probably only features basic projecting/build support as well as dcd bindings. Did you, Bruno, discarded your customly written completion framework in favor of dcd?
I didn't discard my completion engine, since from what I saw in DCD (at least at the time), DCD didn't seem better than mine (only Mono-D has that honor at the moment ;) ) So I'm keeping it, also because there are a lot of improvements I can make to DDT's completion engine with relative low effort (I just had my time caught up in other features to go into that). Also, there were several limitations with the DCD protocol and/or options. First was lack of DUB support. Then, limited information on the resolved symbols (for example function symbols don't have the full function signature). Then there was also the inability to perform completion with in-memory files. (At least using DCD-client. Are you saying what if the we communicate directly to DCD-server, that is possible? I haven't looked into that, only the README documentation of DCD) I fixed most of these by rolling my own semantic daemon (note, it's not finished yet). Although, to be honest, even though I made an API that supports semantic operations in multiple in-memory files, after I saw Atila Neves lightning talk about fly-check in Vim, I'm fairly convinced just automatically writing all files to the disk would have been good enough, if not even better (I'm thinking the OS would cache the files, so I/O would not be an issue... but that premise would have to be tested) The only significant issue is the same as you mentioned in 4) . I could shift all my semantic features to the daemon at this point, but I would still need a D parser as part of DDT for all the syntax features - the editor outline, code folding, the "breadcrumb", etc.. This functionality would have to be moved to the daemon so that the IDE could be completely free of any D parser or D engine. While that is certainly feasible, I wonder if there could be a significant performance hit: The semantic features (code complete, open definition) are only invoked sporadically, but parsing/syntax features require parsing on more or less every keystroke - so that info would have to be retrieved from the daemon nearly constantly, and would add some overhead... It's something to consider. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Sep 09 2014
prev sibling parent reply "Alex" <info alexanderbothe.com> writes:
On Wednesday, 13 August 2014 at 21:29:01 UTC, Damian Day wrote:
 On Wednesday, 13 August 2014 at 14:16:18 UTC, Alex wrote:
 Hey everyone,

 it's been quite some while ago that I posted a Mono-D release 
 announcement on to D.announce :)

 You should've noticed that the installation instruction stuff 
 has been moved to
 the D wiki - http://wiki.dlang.org/Mono-D

 There have been several fixes and smaller improvements since 
 the last bunch of bug fix releases.
 Detailed release notes can be taken from the wiki entry.



 Cheers,
 Alex
Have you considered integrating some of Brian Schotts work? Perhaps an option to pick an engine DCD or DParser. I'm particularly interested in dscanner integration myself :)
In theory, it should be possible if the IPC between the dcd client&server is not too tricky to handle (or is it indeed just a command call? -- But then I had to save a file first to be able to get completion for nearly each keystroke..ugh).
Aug 14 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 14/08/2014 08:05, Alex wrote:
 On Wednesday, 13 August 2014 at 21:29:01 UTC, Damian Day wrote:
 On Wednesday, 13 August 2014 at 14:16:18 UTC, Alex wrote:
 Hey everyone,

 it's been quite some while ago that I posted a Mono-D release
 announcement on to D.announce :)

 You should've noticed that the installation instruction stuff has
 been moved to
 the D wiki - http://wiki.dlang.org/Mono-D

 There have been several fixes and smaller improvements since the last
 bunch of bug fix releases.
 Detailed release notes can be taken from the wiki entry.



 Cheers,
 Alex
Have you considered integrating some of Brian Schotts work? Perhaps an option to pick an engine DCD or DParser. I'm particularly interested in dscanner integration myself :)
In theory, it should be possible if the IPC between the dcd client&server is not too tricky to handle (or is it indeed just a command call? -- But then I had to save a file first to be able to get completion for nearly each keystroke..ugh).
Why is that ugh? You don't have to save the file on each keystroke, just when completion is invoked, right? Even taking the issue of code completion out of the picture, I've recently come to realize that implicit save of IDE files might be good thing on its own, from a UI paradigm perspective (see this comment http://forum.dlang.org/post/lrvna6$2btb$1 digitalmars.com). I saw this first hand when I tried IntelliJ for the first time a few months ago. It actually struck me as a really nice paradigm, especially so for IDEs, which usually keep a modification history of files already. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Sep 04 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 04/09/14 23:41, Bruno Medeiros wrote:

 Why is that ugh? You don't have to save the file on each keystroke, just
 when completion is invoked, right?
In MonoDevelop/Visual Studio the completion is basically invoked as soon as you start to type something. Not as in Eclipse when it's invoked manually or only when typing a dot. -- /Jacob Carlborg
Sep 04 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 05/09/2014 07:30, Jacob Carlborg wrote:
 On 04/09/14 23:41, Bruno Medeiros wrote:

 Why is that ugh? You don't have to save the file on each keystroke, just
 when completion is invoked, right?
In MonoDevelop/Visual Studio the completion is basically invoked as soon as you start to type something. Not as in Eclipse when it's invoked manually or only when typing a dot.
Oh I see. Do people like this behavior BTW? Eclipse could also be configured to work like this, but I'm not sure I would like it, (even if there are no problems such as slow autocompletion.). But maybe it just cause I'm used to it. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Sep 09 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-09-09 15:06, Bruno Medeiros wrote:

 Oh I see. Do people like this behavior BTW? Eclipse could also be
 configured to work like this, but I'm not sure I would like it, (even if
 there are no problems such as slow autocompletion.). But maybe it just
 cause I'm used to it.
I wouldn't mind having an option for it. -- /Jacob Carlborg
Sep 09 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 09/09/2014 20:16, Jacob Carlborg wrote:
 On 2014-09-09 15:06, Bruno Medeiros wrote:

 Oh I see. Do people like this behavior BTW? Eclipse could also be
 configured to work like this, but I'm not sure I would like it, (even if
 there are no problems such as slow autocompletion.). But maybe it just
 cause I'm used to it.
I wouldn't mind having an option for it.
It's already possible to do it (although not obvious at all). Just go to Preferences/DDT/Editor/Content Assist and put the ".abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" string in the Auto activation trigger characters field. (It works for JDT too) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Sep 10 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-09-10 16:37, Bruno Medeiros wrote:

 It's already possible to do it (although not obvious at all). Just go to
 Preferences/DDT/Editor/Content Assist and put the
 ".abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" string in the
 Auto activation trigger characters field.

 (It works for JDT too)
It does? Haha, cool, I'll give it a try. -- /Jacob Carlborg
Sep 10 2014