On Friday, 21 February 2020 at 05:37:53 UTC, rikki cattermole wrote:
> On 21/02/2020 6:21 PM, Basile B. wrote:
>> If you drop dparse and dsymbol then DCD is an empty shell that only handles the requests and their serialization. Why keeping this ? That are other ways of implementing an IPC than sockets, that were never done in DCD (shared memory, standard IO).
>
> Lets not break existing tooling just because we can.
>
> New IO methods can be added later.

Let's say but the most important point I would say then is to stop using dsymbol.
That was the principal idea raised by my first answer. for DCD both dparse and dsymbol must be droped, otherwise it'll end up with the same limitation as the actual ones.

On Friday, 21 February 2020 at 07:34:39 UTC, rikki cattermole wrote:
> For the more used IDE's the community from what I have observed use the dedicated plugins for the IDE's to integrate into external resources like DCD.
>
> I was not commenting on if an IDE supports it, but instead on what the priority is.
>
> Keeping in mind that this is in context on rewriting DLS which depends on these very same resources.

My mistake, I misinterpreted what you said indeed.

On Friday, 21 February 2020 at 02:27:37 UTC, Basile B. wrote:
> On Thursday, 20 February 2020 at 18:58:12 UTC, Cristian Creteanu wrote:
>> [...]
>
> I'll only comment this parapgraph since I don't use DLS:
>
>> The cleanest way to solve this would be to replace libdparse with dmd in dcd and dscanner, as well. Would this be a good idea? Should I approach this differently?
>
> You should rather start new tools. dsymbol (so the library used by dcd) has a lot of problems related to import and out-of-order declarations, templates or even expressions are not handled at all (BTW dparse doesn't decompose unaries at all !).
>
> Replacing dparse by DMD-FE in the tools, from my POV, would be like puting a Rolls-Royce turbo reactor in an old Renault 4L car. The way the tools are made is too bent to dparse.

First, let me give you some context on this project. Cristi is a bachelor student that is doing his thesis with me and Edi.

The primary objective of the project is twofold: make DLs use dmd as library but at the same time improve the library interface and do the necessary compiler modifications so that dmd-fe becomes usable. Actually, integrating with DLS is just a dry run to see what kind of interface does the dmd-fe need to be usable in a real life project.

However, seeing how DLS uses all the other tools that rely on libdparse we thought that maybe it would be a better strategy to try and update those other tools.

Any suggestions are welcome.

On Friday, 21 February 2020 at 07:57:48 UTC, RazvanN wrote:
> On Friday, 21 February 2020 at 02:27:37 UTC, Basile B. wrote:
>> [...]
>
> First, let me give you some context on this project. Cristi is a bachelor student that is doing his thesis with me and Edi.
>
> The primary objective of the project is twofold: make DLs use dmd as library but at the same time improve the library interface and do the necessary compiler modifications so that dmd-fe becomes usable. Actually, integrating with DLS is just a dry run to see what kind of interface does the dmd-fe need to be usable in a real life project.
>
> However, seeing how DLS uses all the other tools that rely on libdparse we thought that maybe it would be a better strategy to try and update those other tools.
>
> Any suggestions are welcome.

Yes so I've clarified what I said a few minutes ago, see https://forum.dlang.org/post/bnmhguoawnljqkduwmcq@forum.dlang.org. It's not only about dparse, it's also about dsymbol (the library, not the dmd module).

On Friday, 21 February 2020 at 07:24:10 UTC, Laurent Tréguier wrote:
> On Friday, 21 February 2020 at 03:42:37 UTC, rikki cattermole wrote:
>> ignore DLS most IDE's don't use it
>
> I'll chime in a bit to disagree on that. I don't know where you're getting this idea from, but DLS can be used with VSCode, Visual Studio, Sublime text, Atom, Vim/Neovim, Emacs, and Intellij IDEA. It's certainly not as popular as code-d and VisualD, but it's certainly usable with a whole range of editors and IDE's

+1

I use it with VSCode and I'm very satisfied about it.

 Some period ago, it was the only VSCode plugin with a "just work" approach, while vs-code was plagued by instability, also if right now it works pretty well also. I especially love the idea of glueing all the different tools together.

On 2/21/20 10:34 AM, rikki cattermole wrote:
> For the more used IDE's the community from what I have observed use the dedicated plugins for the IDE's to integrate into external resources like DCD.
> 
> I was not commenting on if an IDE supports it, but instead on what the priority is.
> 
> Keeping in mind that this is in context on rewriting DLS which depends on these very same resources.

Well, for example me prefer DLS over code-d for long time

On 2020-02-20 21:53, Laurent Tréguier wrote:

>  From what I recall, the necessary changes to DMD would be:
> - Removing any remaining global state. I don't know what the status of global state in DMD is nowadays. Although this might not be "necessary", it's always good to know that we can safely repeat calls to some APIs and always get the same output, without interference from some internal variables.

Still an issue. There are some APIs to reset the state to it's original state of the globals but they're not complete.

> - Being able to fully control the standard input and output. When I tried to use DMD, there were some places where it was impossible to prevent DMD from using stdout IIRC. This is really critical, as standard input/output is the way language servers are used 99% of the time, and thus they need 110% control over stdin/stdout.

Still an issue. There are other issue like it's not possible to configure the compiler to read everything from memory, for example. Regular imports and import expressions will be read from disk.

-- 
/Jacob Carlborg

On 2020-02-21 08:57, RazvanN wrote:

> First, let me give you some context on this project. Cristi is a bachelor student that is doing his thesis with me and Edi.
> 
> The primary objective of the project is twofold: make DLs use dmd as library but at the same time improve the library interface and do the necessary compiler modifications so that dmd-fe becomes usable. Actually, integrating with DLS is just a dry run to see what kind of interface does the dmd-fe need to be usable in a real life project.
> 
> However, seeing how DLS uses all the other tools that rely on libdparse we thought that maybe it would be a better strategy to try and update those other tools.
> 
> Any suggestions are welcome.

I would start at the bottom, not the top. That is, start by working on one of the tools, the one(s) at the lowest level, that DLS depends on.

I would probably start with the simplest one, that might be dfmt. But for, I think, that DMD needs to support end locations for tokens and possibly AST nodes as well.

-- 
/Jacob Carlborg

On 2020-02-21 13:53, Jacob Carlborg wrote:

> I would probably start with the simplest one, that might be dfmt. But for, I think, that DMD needs to support end locations for tokens and possibly AST nodes as well.

Oh, there are some AST nodes that don't contain any location at all.

-- 
/Jacob Carlborg

On 22/02/2020 1:53 AM, Jacob Carlborg wrote:
> On 2020-02-21 08:57, RazvanN wrote:
> 
>> First, let me give you some context on this project. Cristi is a bachelor student that is doing his thesis with me and Edi.
>>
>> The primary objective of the project is twofold: make DLs use dmd as library but at the same time improve the library interface and do the necessary compiler modifications so that dmd-fe becomes usable. Actually, integrating with DLS is just a dry run to see what kind of interface does the dmd-fe need to be usable in a real life project.
>>
>> However, seeing how DLS uses all the other tools that rely on libdparse we thought that maybe it would be a better strategy to try and update those other tools.
>>
>> Any suggestions are welcome.
> 
> I would start at the bottom, not the top. That is, start by working on one of the tools, the one(s) at the lowest level, that DLS depends on.
> 
> I would probably start with the simplest one, that might be dfmt. But for, I think, that DMD needs to support end locations for tokens and possibly AST nodes as well.

Dfix is < 1k LOC, easier to get into but may not teach as much (hence I suggest DCD as a starting point).

https://github.com/dlang-community/dfix/blob/master/src/dfix.d