September 04, 2014
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
September 04, 2014
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
September 04, 2014
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.
September 05, 2014
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
September 05, 2014
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
September 05, 2014
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
September 05, 2014
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?
September 05, 2014
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
September 09, 2014
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
September 09, 2014
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