Hi,

I have just released a new beta version of Visual D, see

https://github.com/dlang/visuald/releases/tag/v0.51.0-beta1

The most important new feature: a semantic engine based on the DMD frontend. You can enable it with the respective option on the global TextEditor->D->"Intellisense" options page.

I think it already works quite well for browsing source code, but I haven't yet worked too much on code completion.

Some known issues:

- dmdserver.exe eats a lot of memory, you might want to kill the process from time to time.

- support for templates is incomplete, semantic info is taken from the first instantiation

- quirks regarding source code locations that need to be tweaked in dmd

It's probably too early reporting bugs as I see a lot of quirks myself, but I thought it's already useful as a preview. There are also a number of other issues implemented/fixed that I wanted to make public, see the changes as listed at the link above.

Happy coding,
Rainer

On Sunday, 17 November 2019 at 18:11:29 UTC, Rainer Schuetze wrote:
> Hi,
>
> I have just released a new beta version of Visual D, see
>
> https://github.com/dlang/visuald/releases/tag/v0.51.0-beta1
>
> The most important new feature: a semantic engine based on the DMD frontend. You can enable it with the respective option on the global TextEditor->D->"Intellisense" options page.
>
> I think it already works quite well for browsing source code, but I haven't yet worked too much on code completion.
>
> Some known issues:
>
> - dmdserver.exe eats a lot of memory, you might want to kill the process from time to time.
>

Why not monitor the amount it is using and how much to the total and kill it automatically? or could it be killed for every compilation just in case to prevent out of memory errors if the free memory is not significant. Not sure if there is some good option here but it should be automatable for the most part.

On 28/11/2019 16:51, AlphaPurned wrote:
> On Sunday, 17 November 2019 at 18:11:29 UTC, Rainer Schuetze wrote:
>> Hi,
>>
>> I have just released a new beta version of Visual D, see
>>
>> https://github.com/dlang/visuald/releases/tag/v0.51.0-beta1
>>
>> The most important new feature: a semantic engine based on the DMD frontend. You can enable it with the respective option on the global TextEditor->D->"Intellisense" options page.
>>
>> I think it already works quite well for browsing source code, but I haven't yet worked too much on code completion.
>>
>> Some known issues:
>>
>> - dmdserver.exe eats a lot of memory, you might want to kill the process from time to time.
>>
> 
> Why not monitor the amount it is using and how much to the total and kill it automatically? or could it be killed for every compilation just in case to prevent out of memory errors if the free memory is not significant. Not sure if there is some good option here but it should be automatable for the most part.
> 

That could be a strategy but the actual goal is to find out why the frontend holds on to so much memory.

The server process is using the precise GC in a 64-bit process (but with limited type information as the way memory is allocated throws away some of that info), so false pointers shouldn't occur too often. I have found a number of stale pointers already, but there seem to be more.

On Saturday, 30 November 2019 at 08:59:09 UTC, Rainer Schuetze wrote:
>
>
> On 28/11/2019 16:51, AlphaPurned wrote:
>> On Sunday, 17 November 2019 at 18:11:29 UTC, Rainer Schuetze wrote:
>>> Hi,
>>>
>>> I have just released a new beta version of Visual D, see
>>>
>>> https://github.com/dlang/visuald/releases/tag/v0.51.0-beta1
>>>
>>> The most important new feature: a semantic engine based on the DMD frontend. You can enable it with the respective option on the global TextEditor->D->"Intellisense" options page.
>>>
>>> I think it already works quite well for browsing source code, but I haven't yet worked too much on code completion.
>>>
>>> Some known issues:
>>>
>>> - dmdserver.exe eats a lot of memory, you might want to kill the process from time to time.
>>>
>> 
>> Why not monitor the amount it is using and how much to the total and kill it automatically? or could it be killed for every compilation just in case to prevent out of memory errors if the free memory is not significant. Not sure if there is some good option here but it should be automatable for the most part.
>> 
>
> That could be a strategy but the actual goal is to find out why the frontend holds on to so much memory.
>
> The server process is using the precise GC in a 64-bit process (but with limited type information as the way memory is allocated throws away some of that info), so false pointers shouldn't occur too often. I have found a number of stale pointers already, but there seem to be more.

There should still be some fall back so that one can compile a program without getting an out of memory error. I don't know the specifics though. Just seems like if it is taking up a significant amount of memory it might need to be killed automatically rather than ruining a compilation.