On Thursday, 30 May 2013 at 22:39:28 UTC, Flamaros wrote:
> On Thursday, 30 May 2013 at 12:55:29 UTC, Rainer Schuetze wrote:
>>
>>
>> On 17.05.2013 19:43, Rainer Schuetze wrote:
>>>
>>>
>>> On 12.05.2013 20:48, Walter Bright wrote:
>>>> On 5/11/2013 3:39 AM, Rainer Schuetze wrote:
>>>>> a new version of Visual D is long overdue, so finally it is released. In
>>>>> addition to the usual fixes of bugs and regressions, the major
>>>>> highlights of
>>>>> this version are
>>>>
>>>> This deserves a much higher profile. Few people know about it.
>>>>
>>>> Can you write a brief article about Visual D? Then we can link to it,
>>>> and post it on Reddit.
>>>
>>> I'm lagging behind on documentation anyway, so if I find the time, I'll
>>> try to do it as an article.
>>
>> Probably a bit late, but here is a short article about the new version with some bias towards "Unittesting and code coverage analysis with Visual D": http://www.dsource.org/projects/visuald/wiki/News36
>
> I missed that, it's a good remainder, thank you.
>
> It certainly help a lot the community.

I followed indications, lst files are correctly generated for the code coverage, but I don't have the coloration in the editor. Can be because my application crash when exiting?

On 01.06.2013 12:45, Flamaros wrote:
> On Thursday, 30 May 2013 at 22:39:28 UTC, Flamaros wrote:

> I followed indications, lst files are correctly generated for the code
> coverage, but I don't have the coloration in the editor. Can be because
> my application crash when exiting?

If your application crashed, the lst file might be from a previous run and is considered out of sync. Please check whether it is newer than the source file.
Also, it has to be in the same folder with the same base name as the source. I've recently noticed that the lst files generation seem to replace '/' with '-' in path names making it pretty unpredictable were to look for files when all you know the source file name. I'll have to add a workaround for that.

On Saturday, 1 June 2013 at 10:55:36 UTC, Rainer Schuetze wrote:
>
>
> On 01.06.2013 12:45, Flamaros wrote:
>> On Thursday, 30 May 2013 at 22:39:28 UTC, Flamaros wrote:
>
>> I followed indications, lst files are correctly generated for the code
>> coverage, but I don't have the coloration in the editor. Can be because
>> my application crash when exiting?
>
> If your application crashed, the lst file might be from a previous run and is considered out of sync. Please check whether it is newer than the source file.
> Also, it has to be in the same folder with the same base name as the source. I've recently noticed that the lst files generation seem to replace '/' with '-' in path names making it pretty unpredictable were to look for files when all you know the source file name. I'll have to add a workaround for that.

When I check last modification of lst files it seems good.

Effectively files name contains '-' characters (ex : "..-src-dquick-item-mouseAreaItem.lst")
Source file naming prevent '-' characters, so if everybody follow this rule replacing '-' by '/' will allow you to get right paths.

On 01.06.2013 16:59, Flamaros wrote:
> On Saturday, 1 June 2013 at 10:55:36 UTC, Rainer Schuetze wrote:
>>
>>
>> On 01.06.2013 12:45, Flamaros wrote:
>>> On Thursday, 30 May 2013 at 22:39:28 UTC, Flamaros wrote:
>>
>>> I followed indications, lst files are correctly generated for the code
>>> coverage, but I don't have the coloration in the editor. Can be because
>>> my application crash when exiting?
>>
>> If your application crashed, the lst file might be from a previous run
>> and is considered out of sync. Please check whether it is newer than
>> the source file.
>> Also, it has to be in the same folder with the same base name as the
>> source. I've recently noticed that the lst files generation seem to
>> replace '/' with '-' in path names making it pretty unpredictable were
>> to look for files when all you know the source file name. I'll have to
>> add a workaround for that.
>
> When I check last modification of lst files it seems good.
>
> Effectively files name contains '-' characters (ex :
> "..-src-dquick-item-mouseAreaItem.lst")
> Source file naming prevent '-' characters, so if everybody follow this
> rule replacing '-' by '/' will allow you to get right paths.

I guess Visual D will have to remember the last directory where it invoked the "Compile and Run" command and try to match lst files in that directory to the current source file.

Does anybody know why the lst file is not written side-by-side with the source file?

I'd say this is a good thing. Please don't pollute the source tree with
junk placed next to the source files. This is very un-visual-studio. They
should be in the intermediate folder next to the obj files.
On 2 Jun 2013 01:15, "Rainer Schuetze" <r.sagitario@gmx.de> wrote:

>
>
> On 01.06.2013 16:59, Flamaros wrote:
>
>> On Saturday, 1 June 2013 at 10:55:36 UTC, Rainer Schuetze wrote:
>>
>>>
>>>
>>> On 01.06.2013 12:45, Flamaros wrote:
>>>
>>>> On Thursday, 30 May 2013 at 22:39:28 UTC, Flamaros wrote:
>>>>
>>>
>>>  I followed indications, lst files are correctly generated for the code
>>>> coverage, but I don't have the coloration in the editor. Can be because my application crash when exiting?
>>>>
>>>
>>> If your application crashed, the lst file might be from a previous run
>>> and is considered out of sync. Please check whether it is newer than
>>> the source file.
>>> Also, it has to be in the same folder with the same base name as the
>>> source. I've recently noticed that the lst files generation seem to
>>> replace '/' with '-' in path names making it pretty unpredictable were
>>> to look for files when all you know the source file name. I'll have to
>>> add a workaround for that.
>>>
>>
>> When I check last modification of lst files it seems good.
>>
>> Effectively files name contains '-' characters (ex :
>> "..-src-dquick-item-**mouseAreaItem.lst")
>> Source file naming prevent '-' characters, so if everybody follow this
>> rule replacing '-' by '/' will allow you to get right paths.
>>
>
> I guess Visual D will have to remember the last directory where it invoked the "Compile and Run" command and try to match lst files in that directory to the current source file.
>
> Does anybody know why the lst file is not written side-by-side with the source file?
>