www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - Visual D 0.50.0-beta1 released

reply Rainer Schuetze <r.sagitario gmx.de> writes:
Hi,

for the adventurous: I have just released a preliminary version of
Visual D with some new major changes:

- there is now another installer available that includes DMD and LDC, so
no additional setup steps necessary to get you going

- now checks for updates for Visual D, DMD and LDC and assists with
downloading and installing

- experimental: highlight references to the same symbol as the one at
the caret (to be enabled in the editor options)

- mago debugger extension: better dynamic type handling of classes and
interfaces, show exception message

Grab it here:
https://github.com/dlang/visuald/releases/tag/v0.50.0-beta1

Cheers,
Rainer
May 31 2019
next sibling parent reply Amex <Amex gmail.com> writes:
On Friday, 31 May 2019 at 16:30:02 UTC, Rainer Schuetze wrote:

 Hi,

 for the adventurous: I have just released a preliminary version 
 of Visual D with some new major changes:

 - there is now another installer available that includes DMD 
 and LDC, so no additional setup steps necessary to get you going

 - now checks for updates for Visual D, DMD and LDC and assists 
 with downloading and installing

 - experimental: highlight references to the same symbol as the 
 one at the caret (to be enabled in the editor options)

 - mago debugger extension: better dynamic type handling of 
 classes and interfaces, show exception message

 Grab it here: 
 https://github.com/dlang/visuald/releases/tag/v0.50.0-beta1

 Cheers,
 Rainer


Awesome! It's like Christmas all over again! Like the update 
feature!


One problem still: Dragging a variable from the debug to the 
memory still drags all the junk for v2019.


Also,

What about installing gdc like ldc and such?

Also, can we get a monthly check and having the previous install 
renamed if there is a collision so that we have the backup of the 
compiler in case anything breaks.



I haven't put it through the test but interfaces is working now! 
That is a big deal for me! I've enabled all the experimental 
features and things are a bit different(colorized and such).




 - mago debugger extension: better dynamic type handling of 
 classes and interfaces, show exception message


One thing I've always been confused on is the mago debugger vs 
visual studio(and the mixed mode).

Is there any place that shows the difference? I'm not sure which 
to use. I want to use the best obviously. There are also several 
places that have a debugger selector and I have no idea what they 
are all about.


Thanks!!!!!!!!!!!!!!!!!!!
May 31 2019
next sibling parent reply Amex <Amex gmail.com> writes:
I'm wondering if it would be possible to be able to have the 
debug watches/autos/locals to link to source files for objects?

e.g., if I'm viewing a class instance I could somehow click on 
the object and it will jump to the source file of the class?
May 31 2019
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 01/06/2019 02:32, Amex wrote:

 I'm wondering if it would be possible to be able to have the debug
 watches/autos/locals to link to source files for objects?
 
 e.g., if I'm viewing a class instance I could somehow click on the
 object and it will jump to the source file of the class?
 


Interesting idea, but I don't think the debugger supports that. Maybe it
is possible to extend the context menu in locals/watch windows.
Jun 01 2019
prev sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 01/06/2019 00:29, Amex wrote:

 On Friday, 31 May 2019 at 16:30:02 UTC, Rainer Schuetze wrote:

 Hi,

 for the adventurous: I have just released a preliminary version of
 Visual D with some new major changes:

 - there is now another installer available that includes DMD and LDC,
 so no additional setup steps necessary to get you going

 - now checks for updates for Visual D, DMD and LDC and assists with
 downloading and installing

 - experimental: highlight references to the same symbol as the one at
 the caret (to be enabled in the editor options)

 - mago debugger extension: better dynamic type handling of classes and
 interfaces, show exception message

 Grab it here: https://github.com/dlang/visuald/releases/tag/v0.50.0-beta1

 Cheers,
 Rainer


 
 Awesome! It's like Christmas all over again! Like the update feature!


Thanks.


 One problem still: Dragging a variable from the debug to the memory
 still drags all the junk for v2019.


Still on the todo list...


 Also,
 
 What about installing gdc like ldc and such?


I don't think there is a reasonable GDC version available for Windows
yet. Maybe when the MinGW distributions are updated to include the GCC
9.1 suites (or better 10 when GDC will catch up with recent dmd/ldc
version).


 
 Also, can we get a monthly check and having the previous install renamed
 if there is a collision so that we have the backup of the compiler in
 case anything breaks.


Is a weekly check too often?

The downloaded installations are not removed, but are stored in a folder
named as the version.


 
 
 
 I haven't put it through the test but interfaces is working now! That is
 a big deal for me! I've enabled all the experimental features and things
 are a bit different(colorized and such).
 
 
 

 - mago debugger extension: better dynamic type handling of classes and
 interfaces, show exception message


 
 One thing I've always been confused on is the mago debugger vs visual
 studio(and the mixed mode).
 
 Is there any place that shows the difference? I'm not sure which to use.
 I want to use the best obviously. There are also several places that
 have a debugger selector and I have no idea what they are all about.


The mago debug engine was recommended before the Visual Studio debugger
allowed to be extended by plugins. I now prefer the Visual Studio engine
equipped with magos expression evaluation. The "mixed mode" allows


See https://rainers.github.io/visuald/visuald/Debugging.html for details
and some history.
May 31 2019
prev sibling next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
Hi,

new beta2 available:
https://github.com/dlang/visuald/releases/tag/v0.50.0-beta2


Changes from beta1:

* check and report invalid non-empty DMD/LDC installation folders
* VC project:
  - DMD: fix wrong selections for bounds check options
  - LDC: added -mixin option
  - added enable -mixin option to autogenerate files according to the
compilation model
  - new option for -extern-std=c++xx
* visualdproj:
  - Error List: classify warnings and deprecations according to the
respective options
  - bugzilla 19930: fix building projects with "&|<>" in directory names
* mago: fix conditional breakpoints "not supported"

Rainer


On 31/05/2019 18:30, Rainer Schuetze wrote:

 Hi,
 
 for the adventurous: I have just released a preliminary version of
 Visual D with some new major changes:
 
 - there is now another installer available that includes DMD and LDC, so
 no additional setup steps necessary to get you going
 
 - now checks for updates for Visual D, DMD and LDC and assists with
 downloading and installing
 
 - experimental: highlight references to the same symbol as the one at
 the caret (to be enabled in the editor options)
 
 - mago debugger extension: better dynamic type handling of classes and
 interfaces, show exception message
 
 Grab it here:
 https://github.com/dlang/visuald/releases/tag/v0.50.0-beta1
 
 Cheers,
 Rainer
Jun 04 2019
next sibling parent reply Amex <Amex gmail.com> writes:
On Tuesday, 4 June 2019 at 07:45:56 UTC, Rainer Schuetze wrote:

 Hi,

 new beta2 available: 
 https://github.com/dlang/visuald/releases/tag/v0.50.0-beta2


 Changes from beta1:

 * check and report invalid non-empty DMD/LDC installation 
 folders
 * VC project:
   - DMD: fix wrong selections for bounds check options
   - LDC: added -mixin option
   - added enable -mixin option to autogenerate files according 
 to the
 compilation model
   - new option for -extern-std=c++xx
 * visualdproj:
   - Error List: classify warnings and deprecations according to 
 the
 respective options
   - bugzilla 19930: fix building projects with "&|<>" in 
 directory names
 * mago: fix conditional breakpoints "not supported"

 Rainer


 On 31/05/2019 18:30, Rainer Schuetze wrote:

 Hi,
 
 for the adventurous: I have just released a preliminary 
 version of Visual D with some new major changes:
 
 - there is now another installer available that includes DMD 
 and LDC, so no additional setup steps necessary to get you 
 going
 
 - now checks for updates for Visual D, DMD and LDC and assists 
 with downloading and installing
 
 - experimental: highlight references to the same symbol as the 
 one at the caret (to be enabled in the editor options)
 
 - mago debugger extension: better dynamic type handling of 
 classes and interfaces, show exception message
 
 Grab it here: 
 https://github.com/dlang/visuald/releases/tag/v0.50.0-beta1
 
 Cheers,
 Rainer





I've noticed a weird behavior in Visual D projects. In the file 
tray(the drop down at the upper right of the source code window 
to find opened files) some of the D files have a different icon. 
One is a large red and white D while most others are a small red 
D.

The large D's use all lowercase paths while the small D's used 
mixed case(this is not 100% every time though). (for example, I 
might see the file C:\Project\main.d and c:\project\test.d each 
with a different icon)

I have had it where the same file was opened with the two 
different versions as if it was different file... changing one 
then changes the other(requiring a reload)... which can be 
dangerous since it can cause loss of changes. This has only 
happened a few times though and it happens when the debugger 
breaks in to a file and that is open(again, rare though).

I guess it has to do with a direct string compare rather than 
first converting everything to the same case. s1 == s2 vs 
s1.toLower == s2.toLower.

It's not a big problem though but you might add it to your list 
in case you come across it while fixing other stuff. One of the 
key's will be the different D icons.

It seems somewhere in Visual D.
Jun 04 2019
next sibling parent reply Amex <Amex gmail.com> writes:
I've noticed that some interfaces are not expandable in the 
watches.

Some work some don't, I have no idea what is causing it ;/ The 
type is being shown as an interface but I can't expand it. It is 
based off an abstract class and the class that it is does have an 
attribute added(that isn't added to all the ones that work).

interface X;
abstract class Y : X
 nonSerialized class Z : Y;

It may be the attribute.

Yes, it is the attribute, removing it let me expand the item but 
it crashed visual studio ;/

After the crash I ran again and I couldn't expand ;/ But not sure 
if that was just something that was messed up.

In any case, definitely seems to be some issue with attributes.
Jun 05 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 05/06/2019 10:41, Amex wrote:

 I've noticed that some interfaces are not expandable in the watches.
 
 Some work some don't, I have no idea what is causing it ;/ The type is
 being shown as an interface but I can't expand it. It is based off an
 abstract class and the class that it is does have an attribute
 added(that isn't added to all the ones that work).
 
 interface X;
 abstract class Y : X
  nonSerialized class Z : Y;
 
 It may be the attribute.
 
 Yes, it is the attribute, removing it let me expand the item but it
 crashed visual studio ;/
 
 After the crash I ran again and I couldn't expand ;/ But not sure if
 that was just something that was messed up.
 
 In any case, definitely seems to be some issue with attributes.
 


Works here, but as usual I have to guess what your code might look like.
Please provide complete examples that show the issue (and report it at
https://issues.dlang.org/ for better tracking).
Jun 05 2019
parent reply Amex <Amex gmail.com> writes:
On Wednesday, 5 June 2019 at 21:26:10 UTC, Rainer Schuetze wrote:

 On 05/06/2019 10:41, Amex wrote:

 I've noticed that some interfaces are not expandable in the 
 watches.
 
 Some work some don't, I have no idea what is causing it ;/ The 
 type is being shown as an interface but I can't expand it. It 
 is based off an abstract class and the class that it is does 
 have an attribute added(that isn't added to all the ones that 
 work).
 
 interface X;
 abstract class Y : X
  nonSerialized class Z : Y;
 
 It may be the attribute.
 
 Yes, it is the attribute, removing it let me expand the item 
 but it crashed visual studio ;/
 
 After the crash I ran again and I couldn't expand ;/ But not 
 sure if that was just something that was messed up.
 
 In any case, definitely seems to be some issue with attributes.
 


 Works here, but as usual I have to guess what your code might 
 look like. Please provide complete examples that show the issue 
 (and report it at https://issues.dlang.org/ for better 
 tracking).



Unfortunately I can't reduce the code... too much interlinked 
stuff. And sometimes it did work. All I know is that it isn't 
working 100% for interfaces. It may be random for some 
interfaces. All I know is I couldn't expand one interface(no 
expander) or some did and they would crash(but pointer was valid).

If I make a video or screen shot of it showing the behavior, will 
that help?
Jun 06 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 06/06/2019 22:20, Amex wrote:

 On Wednesday, 5 June 2019 at 21:26:10 UTC, Rainer Schuetze wrote:

 On 05/06/2019 10:41, Amex wrote:

 I've noticed that some interfaces are not expandable in the watches.

 Some work some don't, I have no idea what is causing it ;/ The type
 is being shown as an interface but I can't expand it. It is based off
 an abstract class and the class that it is does have an attribute
 added(that isn't added to all the ones that work).

 interface X;
 abstract class Y : X
  nonSerialized class Z : Y;

 It may be the attribute.

 Yes, it is the attribute, removing it let me expand the item but it
 crashed visual studio ;/

 After the crash I ran again and I couldn't expand ;/ But not sure if
 that was just something that was messed up.

 In any case, definitely seems to be some issue with attributes.


 Works here, but as usual I have to guess what your code might look
 like. Please provide complete examples that show the issue (and report
 it at https://issues.dlang.org/ for better tracking).


 
 
 Unfortunately I can't reduce the code... too much interlinked stuff. And
 sometimes it did work. All I know is that it isn't working 100% for
 interfaces. It may be random for some interfaces. All I know is I
 couldn't expand one interface(no expander) or some did and they would
 crash(but pointer was valid).
 
 If I make a video or screen shot of it showing the behavior, will that
 help?


If it has more information, it might help. I wouldn't bet on it though.
Jun 12 2019
parent reply Bert <Bert gmail.com> writes:
On Wednesday, 12 June 2019 at 07:21:10 UTC, Rainer Schuetze wrote:

 On 06/06/2019 22:20, Amex wrote:

 On Wednesday, 5 June 2019 at 21:26:10 UTC, Rainer Schuetze 
 wrote:

 On 05/06/2019 10:41, Amex wrote:

 I've noticed that some interfaces are not expandable in the 
 watches.

 Some work some don't, I have no idea what is causing it ;/ 
 The type is being shown as an interface but I can't expand 
 it. It is based off an abstract class and the class that it 
 is does have an attribute added(that isn't added to all the 
 ones that work).

 interface X;
 abstract class Y : X
  nonSerialized class Z : Y;

 It may be the attribute.

 Yes, it is the attribute, removing it let me expand the item 
 but it crashed visual studio ;/

 After the crash I ran again and I couldn't expand ;/ But not 
 sure if that was just something that was messed up.

 In any case, definitely seems to be some issue with 
 attributes.


 Works here, but as usual I have to guess what your code might 
 look like. Please provide complete examples that show the 
 issue (and report it at https://issues.dlang.org/ for better 
 tracking).


 
 
 Unfortunately I can't reduce the code... too much interlinked 
 stuff. And sometimes it did work. All I know is that it isn't 
 working 100% for interfaces. It may be random for some 
 interfaces. All I know is I couldn't expand one interface(no 
 expander) or some did and they would crash(but pointer was 
 valid).
 
 If I make a video or screen shot of it showing the behavior, 
 will that help?


 If it has more information, it might help. I wouldn't bet on it 
 though.


Still having issues with interfaces not being expandable. I'm not 
sure if this was suppose to be fixed by now or not.

What's strange is that I have an array of interfaces and some of 
the interfaces are expandable and some are not ;/


The first and last are expandable, seems the middle is not being 
resolved properly:

-		arr	{length=3 ptr=0x0000028d2cbb60c0}	
inter[]
+		[0]	0x0000028d2cbb3010 {}	inter {main.main.s1}
		[1]	0x0000028d2cbb3070 {}	inter
+		[2]	0x0000028d2cbb30d0 {}	inter {main.main.s3}


the 2nd entry is just main.main.s2


Maybe you could just generate a large array of interfaces(might 
try nestings, empty, derived classes, etc).

While the above's s's are not the same, they all are functionally 
the same so there really should be no difference. Either the bug 
is due to some type of odd/even or position dependent issue, is 
"random", or some other issue.

If I run the code again, different entries are expandable. It 
mainly seems to choose the 2nd and 3rd elements though. (after 
repeated runs I never had it like the configuration above)

E.g.,

-		arr	{length=3 ptr=0x0000028d2cbb60c0}	
inter[]
		[0]	0x0000028d2cbb3010 {}	inter {main.main.s1}
+		[1]	0x0000028d2cbb3070 {}	inter
+		[2]	0x0000028d2cbb30d0 {}	inter {main.main.s3}

Seems to be what it is 98% of the time. [Yes, it's always the 
same memory location]
Jul 10 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 11/07/2019 01:46, Bert wrote:

 The first and last are expandable, seems the middle is not being
 resolved properly:
 
 -        arr    {length=3 ptr=0x0000028d2cbb60c0}   
 inter[]
 +        [0]    0x0000028d2cbb3010 {}    inter {main.main.s1}
         [1]    0x0000028d2cbb3070 {}    inter
 +        [2]    0x0000028d2cbb30d0 {}    inter {main.main.s3}
 
 
 the 2nd entry is just main.main.s2
 
 
 Maybe you could just generate a large array of interfaces(might try
 nestings, empty, derived classes, etc).


It's a lot easier to reduce a failing test than to guess what might go
wrong, so a test case would be appreciated.

I suspect s2 has a slightly more complicated inheritance tree. The
debugger simulates what happens in _d_toObject
(https://github.com/dlang/druntime/blob/master/src/rt/cast_.d#L25). Does
explicit cast(Object) work on that instance?
Jul 12 2019
next sibling parent reply Bert <Bert gmail.com> writes:
So, after a few compiler bug crashes and a few hours I was able 
to simplify the entire code to:


module main;

import std.stdio;

interface X { }


interface I : X
{
	ref X[] S();
}


class C : I
{

	private X[] s;
	ref X[] S() { return s; }
	
	Q sQ;

	// Removing this line works, It should have absolutely zero 
effect
	I c;


	this(I m = null)
	{			
		s ~= new Q;
			
		// Removing this code works
		static if (is(Q : I))
		{
			auto S = new Q;	
			s ~= S;
			sQ = S;
		}
	}

	class Q : I
	{						
		X[] s;
		ref X[] S() { return s; }		
	}

}

void main()
{
	auto c = new C();
	getchar(); // Set BP here and then expand c then s and both the 
items should be expandable. If not remove one of the lines above 
and see if they are then expandable.
}

It's quite amazing that removing either of those marked fixes the 
problem!!!!!!!

The first is a simple field that screws everything up and it's 
never even used. The second is simply a static if. (also removing 
sQ used fixes it)


Bear in mind that I had to remove all this from meta code and so 
it was buried deep inside my original code, which is why it took 
so long to figure out. This is precisely why it is so hard to 
provide tests cases. I essentially had to delete all the 
seemingly unnecessary lines and run each time and verify until 
the issue resolved... luckily the code did not take too long to 
compile each time or I'd still be working on it for another few 
hours or days. This is not the way too solve these problems.

Now, chances are when you run the code it will work... but I have 
taken video to prove my case that it is not functioning properly. 
The code should work and there is absolutely no logical reason 
why the two blocks of code should have any effect on visual D 
expanding the interfaces.

The code this was reduced from was just a few modules... imagine 
a more complex program with hundreds of modules and some strange 
line causing problems like this. It would be worse than having to 
find a needle in a haystack. Luckily it was only an hour wasted 
in my life... Hopefully you don't have to waste more than a 
minute fixing it ;/ This I feel is a similar problem to the 
BP(not necessarily related by code but by how bizarre they work).

Remember, some elements would be expandable so this is not 
something that happens all the time. It seems to be 100% 
repeatable in the simplified code though and also happens for x86 
and x64.

It may entirely be a bug in the compiler as I did get a compiler 
crash when changing removing some code from a mixin that was 
completely irrelevant. [which I should probably report too if I 
can go back and reproduce...]
Jul 21 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 21/07/2019 22:34, Bert wrote:

 So, after a few compiler bug crashes and a few hours I was able to
 simplify the entire code to:
 
 
 module main;
 
 import std.stdio;
 
 interface X { }
 
 
 interface I : X
 {
     ref X[] S();
 }
 
 
 class C : I
 {
 
     private X[] s;
     ref X[] S() { return s; }
     
     Q sQ;
 
     // Removing this line works, It should have absolutely zero effect
     I c;
 
 
     this(I m = null)
     {           
         s ~= new Q;
            
         // Removing this code works
         static if (is(Q : I))
         {
             auto S = new Q;   
             s ~= S;
             sQ = S;
         }
     }
 
     class Q : I
     {                       
         X[] s;
         ref X[] S() { return s; }       
     }
 
 }
 
 void main()
 {
     auto c = new C();
     getchar(); // Set BP here and then expand c then s and both the
 items should be expandable. If not remove one of the lines above and see
 if they are then expandable.
 }
 
 It's quite amazing that removing either of those marked fixes the
 problem!!!!!!!
 
 The first is a simple field that screws everything up and it's never
 even used. The second is simply a static if. (also removing sQ used
 fixes it)
 
 
 Bear in mind that I had to remove all this from meta code and so it was
 buried deep inside my original code, which is why it took so long to
 figure out. This is precisely why it is so hard to provide tests cases.
 I essentially had to delete all the seemingly unnecessary lines and run
 each time and verify until the issue resolved... luckily the code did
 not take too long to compile each time or I'd still be working on it for
 another few hours or days. This is not the way too solve these problems.
 
 Now, chances are when you run the code it will work... but I have taken
 video to prove my case that it is not functioning properly. The code
 should work and there is absolutely no logical reason why the two blocks
 of code should have any effect on visual D expanding the interfaces.


Thanks for reducing the problem. Almost having given up trying to
reproduce the issue with a debug build of the debugger extension, I
tried the release build and actually had the repro case.

As it turned out, the problem was (again?) a false entry in the class
name cache that was added when an invalid pointer (including null) was
evaluated (and its dynamic was tried to be determined). Stupid bug, but
that happens.

You can try the fixed version of MagoNatCC.dll from
https://ci.appveyor.com/project/rainers/mago/build/artifacts
Jul 23 2019
parent reply Bert <Bert gmail.com> writes:
On Tuesday, 23 July 2019 at 20:57:17 UTC, Rainer Schuetze wrote:

 On 21/07/2019 22:34, Bert wrote:

 So, after a few compiler bug crashes and a few hours I was 
 able to simplify the entire code to:
 
 
 module main;
 
 import std.stdio;
 
 interface X { }
 
 
 interface I : X
 {
     ref X[] S();
 }
 
 
 class C : I
 {
 
     private X[] s;
     ref X[] S() { return s; }
 
     Q sQ;
 
     // Removing this line works, It should have absolutely 
 zero effect     I c;
 
 
     this(I m = null)
     {
         s ~= new Q;
 
         // Removing this code works
         static if (is(Q : I))
         {
             auto S = new Q;
             s ~= S;
             sQ = S;
         }
     }
 
     class Q : I
     {
         X[] s;
         ref X[] S() { return s; }
     }
 
 }
 
 void main()
 {
     auto c = new C();
     getchar(); // Set BP here and then expand c then s and 
 both the
 items should be expandable. If not remove one of the lines 
 above and see
 if they are then expandable.
 }
 
 It's quite amazing that removing either of those marked fixes 
 the problem!!!!!!!
 
 The first is a simple field that screws everything up and it's 
 never even used. The second is simply a static if. (also 
 removing sQ used fixes it)
 
 
 Bear in mind that I had to remove all this from meta code and 
 so it was buried deep inside my original code, which is why it 
 took so long to figure out. This is precisely why it is so 
 hard to provide tests cases. I essentially had to delete all 
 the seemingly unnecessary lines and run each time and verify 
 until the issue resolved... luckily the code did not take too 
 long to compile each time or I'd still be working on it for 
 another few hours or days. This is not the way too solve these 
 problems.
 
 Now, chances are when you run the code it will work... but I 
 have taken video to prove my case that it is not functioning 
 properly. The code should work and there is absolutely no 
 logical reason why the two blocks of code should have any 
 effect on visual D expanding the interfaces.


 Thanks for reducing the problem. Almost having given up trying 
 to reproduce the issue with a debug build of the debugger 
 extension, I tried the release build and actually had the repro 
 case.

 As it turned out, the problem was (again?) a false entry in the 
 class
 name cache that was added when an invalid pointer (including 
 null) was
 evaluated (and its dynamic was tried to be determined). Stupid 
 bug, but
 that happens.

 You can try the fixed version of MagoNatCC.dll from 
 https://ci.appveyor.com/project/rainers/mago/build/artifacts


That worked! I still find it very odd that it would exhibit it 
with irrelevant lines of code removed. Was that changing the 
cached version or something? Remember I basically have several 
Q's in my program all virtually identical and some would work and 
others wouldn't.

Could you post some of the code that you fixed(or I guess push it 
to master) when you get a chance... I'm just curious to what it 
looks like. While such bugs are very annoying and better coding 
methods should be used, I imagine that this type of scenario for 
interface resolution is probably well localized and this would 
probably be the last bug fix for it? If not maybe some logging 
could be implemented. Interfaces should always be resolvable so 
if the code fails it is a bug in Visual D and having it logged in 
some way might help future cases.

Thanks for the quick fix, I appreciate it!
Jul 23 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 24/07/2019 08:33, Bert wrote:

 On Tuesday, 23 July 2019 at 20:57:17 UTC, Rainer Schuetze wrote

 As it turned out, the problem was (again?) a false entry in the class
 name cache that was added when an invalid pointer (including null) was
 evaluated (and its dynamic was tried to be determined). Stupid bug, but
 that happens.

 You can try the fixed version of MagoNatCC.dll from
 https://ci.appveyor.com/project/rainers/mago/build/artifacts


 
 That worked! I still find it very odd that it would exhibit it with
 irrelevant lines of code removed. Was that changing the cached version
 or something? Remember I basically have several Q's in my program all
 virtually identical and some would work and others wouldn't.
 
 Could you post some of the code that you fixed(or I guess push it to
 master) when you get a chance... I'm just curious to what it looks like.
 While such bugs are very annoying and better coding methods should be
 used, I imagine that this type of scenario for interface resolution is
 probably well localized and this would probably be the last bug fix for
 it? If not maybe some logging could be implemented. Interfaces should
 always be resolvable so if the code fails it is a bug in Visual D and
 having it logged in some way might help future cases.


The bugfix commit is
https://github.com/rainers/mago/commit/9801da089a4b4e9ffa8f1442f4b0aff5852d5fa9?w=1.

The problem was that evaluating the dynamic type of any uninitialized or
null class/interface pointer could overwrite a previously evaluated
entry in the vtbl->class name cache depending on what happens to be in
an uninitialized local variable.

Hopefully the last bug in that area, but you never know. Adding logging
would help diagnosing bugs but would have to be more global.
Jul 24 2019
parent reply Bert <Bert gmail.com> writes:
On Wednesday, 24 July 2019 at 15:32:01 UTC, Rainer Schuetze wrote:

 On 24/07/2019 08:33, Bert wrote:

 On Tuesday, 23 July 2019 at 20:57:17 UTC, Rainer Schuetze wrote

 As it turned out, the problem was (again?) a false entry in 
 the class
 name cache that was added when an invalid pointer (including 
 null) was
 evaluated (and its dynamic was tried to be determined). 
 Stupid bug, but
 that happens.

 You can try the fixed version of MagoNatCC.dll from 
 https://ci.appveyor.com/project/rainers/mago/build/artifacts


 
 That worked! I still find it very odd that it would exhibit it 
 with irrelevant lines of code removed. Was that changing the 
 cached version or something? Remember I basically have several 
 Q's in my program all virtually identical and some would work 
 and others wouldn't.
 
 Could you post some of the code that you fixed(or I guess push 
 it to master) when you get a chance... I'm just curious to 
 what it looks like. While such bugs are very annoying and 
 better coding methods should be used, I imagine that this type 
 of scenario for interface resolution is probably well 
 localized and this would probably be the last bug fix for it? 
 If not maybe some logging could be implemented. Interfaces 
 should always be resolvable so if the code fails it is a bug 
 in Visual D and having it logged in some way might help future 
 cases.


 The bugfix commit is 
 https://github.com/rainers/mago/commit/9801da089a4b4e9ffa8f1442f4b0aff5852d5fa9?w=1.

 The problem was that evaluating the dynamic type of any 
 uninitialized or null class/interface pointer could overwrite a 
 previously evaluated entry in the vtbl->class name cache 
 depending on what happens to be in an uninitialized local 
 variable.

 Hopefully the last bug in that area, but you never know. Adding 
 logging would help diagnosing bugs but would have to be more 
 global.


Thanks.

I can't imagine though why adding a simple field would screw the 
code up.

e.g.,

class X {} // works.
class Y { int y; } // fails.

I would think that such things would have no effect on the 
pointer value?

Can you explain to me, for my own edification, why removing those 
non-essential lines would produce the effect?
Jul 27 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 28/07/2019 06:59, Bert wrote:

 On Wednesday, 24 July 2019 at 15:32:01 UTC, Rainer Schuetze wrote:

 On 24/07/2019 08:33, Bert wrote:

 On Tuesday, 23 July 2019 at 20:57:17 UTC, Rainer Schuetze wrote

 As it turned out, the problem was (again?) a false entry in the class
 name cache that was added when an invalid pointer (including null) was
 evaluated (and its dynamic was tried to be determined). Stupid bug, but
 that happens.

 You can try the fixed version of MagoNatCC.dll from
 https://ci.appveyor.com/project/rainers/mago/build/artifacts


 That worked! I still find it very odd that it would exhibit it with
 irrelevant lines of code removed. Was that changing the cached
 version or something? Remember I basically have several Q's in my
 program all virtually identical and some would work and others wouldn't.

 Could you post some of the code that you fixed(or I guess push it to
 master) when you get a chance... I'm just curious to what it looks
 like. While such bugs are very annoying and better coding methods
 should be used, I imagine that this type of scenario for interface
 resolution is probably well localized and this would probably be the
 last bug fix for it? If not maybe some logging could be implemented.
 Interfaces should always be resolvable so if the code fails it is a
 bug in Visual D and having it logged in some way might help future
 cases.


 The bugfix commit is
 https://github.com/rainers/mago/commit/9801da089a4b4e9ffa8f1442f4b0aff5852d5fa9?w=1.


 The problem was that evaluating the dynamic type of any uninitialized
 or null class/interface pointer could overwrite a previously evaluated
 entry in the vtbl->class name cache depending on what happens to be in
 an uninitialized local variable.

 Hopefully the last bug in that area, but you never know. Adding
 logging would help diagnosing bugs but would have to be more global.


 
 Thanks.
 
 I can't imagine though why adding a simple field would screw the code up.
 
 e.g.,
 
 class X {} // works.
 class Y { int y; } // fails.
 


This wouldn't have failed, int needs a class/interface member, e.g.

class X
{
   Q q; // non-null
   I c; // null
   Q s; // non-null
}


 I would think that such things would have no effect on the pointer value?
 
 Can you explain to me, for my own edification, why removing those
 non-essential lines would produce the effect?
 


The bug basically was similar to

// global cache
string[void*] mapVtblToClassName;

void showX(X x)
{
   void* vtbl;
   string classNameq;
   bool rc = ReadProcessMemory(x.q, vtbl); // reads vtbl-ptr
   if (rc)
   {
      if (vtbl in mapVtblToClassName)
      {
         classNameq = mapVtblToClassName[vtbl];
         goto Lnext;
      }
      classNameq = getClassNameFromVtbl(vtbl); // Q
   }
   mapVtblToClassName[vtbl] = classNameq;

Lnext:
   string classNamec;
   rc = ReadProcessMemory(x.c, vtbl); // fails, vtbl unchanged
   if (rc)
   {
      // same as above...
   }
   mapVtblToClassName[vtbl] = classNamec; // overwrites entry for Q
}

Next time a Q is evaluated, the determined class name will be empty.
Jul 28 2019
parent reply Bert <Bert gmail.com> writes:
On Sunday, 28 July 2019 at 11:45:21 UTC, Rainer Schuetze wrote:

 On 28/07/2019 06:59, Bert wrote:

 On Wednesday, 24 July 2019 at 15:32:01 UTC, Rainer Schuetze 
 wrote:

 On 24/07/2019 08:33, Bert wrote:

 On Tuesday, 23 July 2019 at 20:57:17 UTC, Rainer Schuetze 
 wrote

 As it turned out, the problem was (again?) a false entry in 
 the class
 name cache that was added when an invalid pointer 
 (including null) was
 evaluated (and its dynamic was tried to be determined). 
 Stupid bug, but
 that happens.

 You can try the fixed version of MagoNatCC.dll from 
 https://ci.appveyor.com/project/rainers/mago/build/artifacts


 That worked! I still find it very odd that it would exhibit 
 it with
 irrelevant lines of code removed. Was that changing the 
 cached
 version or something? Remember I basically have several Q's 
 in my
 program all virtually identical and some would work and 
 others wouldn't.

 Could you post some of the code that you fixed(or I guess 
 push it to master) when you get a chance... I'm just curious 
 to what it looks like. While such bugs are very annoying and 
 better coding methods should be used, I imagine that this 
 type of scenario for interface resolution is probably well 
 localized and this would probably be the last bug fix for 
 it? If not maybe some logging could be implemented. 
 Interfaces should always be resolvable so if the code fails 
 it is a bug in Visual D and having it logged in some way 
 might help future cases.


 The bugfix commit is 
 https://github.com/rainers/mago/commit/9801da089a4b4e9ffa8f1442f4b0aff5852d5fa9?w=1.


 The problem was that evaluating the dynamic type of any 
 uninitialized or null class/interface pointer could overwrite 
 a previously evaluated entry in the vtbl->class name cache 
 depending on what happens to be in an uninitialized local 
 variable.

 Hopefully the last bug in that area, but you never know. 
 Adding logging would help diagnosing bugs but would have to 
 be more global.


 
 Thanks.
 
 I can't imagine though why adding a simple field would screw 
 the code up.
 
 e.g.,
 
 class X {} // works.
 class Y { int y; } // fails.
 


 This wouldn't have failed, int needs a class/interface member, 
 e.g.

 class X
 {
    Q q; // non-null
    I c; // null
    Q s; // non-null
 }


 I would think that such things would have no effect on the 
 pointer value?
 
 Can you explain to me, for my own edification, why removing 
 those non-essential lines would produce the effect?
 


 The bug basically was similar to

 // global cache
 string[void*] mapVtblToClassName;

 void showX(X x)
 {
    void* vtbl;
    string classNameq;
    bool rc = ReadProcessMemory(x.q, vtbl); // reads vtbl-ptr
    if (rc)
    {
       if (vtbl in mapVtblToClassName)
       {
          classNameq = mapVtblToClassName[vtbl];
          goto Lnext;
       }
       classNameq = getClassNameFromVtbl(vtbl); // Q
    }
    mapVtblToClassName[vtbl] = classNameq;

 Lnext:
    string classNamec;
    rc = ReadProcessMemory(x.c, vtbl); // fails, vtbl unchanged
    if (rc)
    {
       // same as above...
    }
    mapVtblToClassName[vtbl] = classNamec; // overwrites entry 
 for Q
 }

 Next time a Q is evaluated, the determined class name will be 
 empty.



Thanks. Ok, I see how the caching can be overwritten but I still 
don't see how changing a field in the class, which won't even 
modify the vtable, will effect the cache. I'd expect some sort of 
determinism in this, in that if I compile the some code and 
everything works and then simply add a field to a class and 
recompile, little should change.

E.g., if the cache is being overwritten in the first case then 
adding the field shouldn't change it from being overwritten in 
the second case.

Oh, nevermind,

ReadProcessMemory(x.q, vtbl);

you are iterating over the entries in x to get their vtable! So 
changing a field could cause a shift in the execution order and 
hence initiate the overwrite. (some of the code is missing above 
but I see how it could lead to these problems).

While I still don't fully understand why the code is doing what 
it does(e.g., q and c? I assume these are suppose to be members). 
Seems there doesn't need to be a goto and 2nd branch in theory 
but I guess it's incomplete code so I'll assume it all is suppose 
to work[Or you are just showing a second iteration].


Essentially just one part of the code is buggy because classNameq 
is empty and it can blindly overwrite the vtbl value *if* any 
future iterations occur where the if(rc) check fails(e.g., an 
added field).


    void* vtbl;
    string classNameq;
    bool rc = ReadProcessMemory(x.q, vtbl); // reads vtbl-ptr
    if (rc)
    {
       if (vtbl in mapVtblToClassName)
       {
          classNameq = mapVtblToClassName[vtbl];
          goto Lnext;
       }
       classNameq = getClassNameFromVtbl(vtbl); // Q
    }
    mapVtblToClassName[vtbl] = classNameq;



which then something like

if (classNameq) mapVtblToClassName[vtbl] = classNameq;

would fix the problem?
Jul 31 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 01/08/2019 05:59, Bert wrote:

 On Sunday, 28 July 2019 at 11:45:21 UTC, Rainer Schuetze wrote:

 On 28/07/2019 06:59, Bert wrote:

 I can't imagine though why adding a simple field would screw the code
 up.

 e.g.,

 class X {} // works.
 class Y { int y; } // fails.


 This wouldn't have failed, int needs a class/interface member, e.g.

 class X
 {
    Q q; // non-null
    I c; // null
    Q s; // non-null
 }


 I would think that such things would have no effect on the pointer
 value?

 Can you explain to me, for my own edification, why removing those
 non-essential lines would produce the effect?


 The bug basically was similar to

 // global cache
 string[void*] mapVtblToClassName;

 void showX(X x)
 {
    void* vtbl;
    string classNameq;
    bool rc = ReadProcessMemory(x.q, vtbl); // reads vtbl-ptr
    if (rc)
    {
       if (vtbl in mapVtblToClassName)
       {
          classNameq = mapVtblToClassName[vtbl];
          goto Lnext;
       }
       classNameq = getClassNameFromVtbl(vtbl); // Q
    }
    mapVtblToClassName[vtbl] = classNameq;

 Lnext:
    string classNamec;
    rc = ReadProcessMemory(x.c, vtbl); // fails, vtbl unchanged
    if (rc)
    {
       // same as above...
    }
    mapVtblToClassName[vtbl] = classNamec; // overwrites entry for Q
 }

 Next time a Q is evaluated, the determined class name will be empty.


 
 
 Thanks. Ok, I see how the caching can be overwritten but I still don't
 see how changing a field in the class, which won't even modify the
 vtable, will effect the cache. I'd expect some sort of determinism in
 this, in that if I compile the some code and everything works and then
 simply add a field to a class and recompile, little should change.
 
 E.g., if the cache is being overwritten in the first case then adding
 the field shouldn't change it from being overwritten in the second case.
 
 Oh, nevermind,
 
 ReadProcessMemory(x.q, vtbl);
 
 you are iterating over the entries in x to get their vtable! So changing
 a field could cause a shift in the execution order and hence initiate
 the overwrite. (some of the code is missing above but I see how it could
 lead to these problems).
 
 While I still don't fully understand why the code is doing what it
 does(e.g., q and c? I assume these are suppose to be members). Seems
 there doesn't need to be a goto and 2nd branch in theory but I guess
 it's incomplete code so I'll assume it all is suppose to work[Or you are
 just showing a second iteration].


Yes, this was pseudo code showing the effect showing two calls to the
same function. I used "goto" where a function would use "return".


 
 
 Essentially just one part of the code is buggy because classNameq is
 empty and it can blindly overwrite the vtbl value *if* any future
 iterations occur where the if(rc) check fails(e.g., an added field).
 

    void* vtbl;
    string classNameq;
    bool rc = ReadProcessMemory(x.q, vtbl); // reads vtbl-ptr
    if (rc)
    {
       if (vtbl in mapVtblToClassName)
       {
          classNameq = mapVtblToClassName[vtbl];
          goto Lnext;
       }
       classNameq = getClassNameFromVtbl(vtbl); // Q
    }
    mapVtblToClassName[vtbl] = classNameq;


 
 
 which then something like
 
 if (classNameq) mapVtblToClassName[vtbl] = classNameq;
 
 would fix the problem?
 
 
 


The empty classname is also cached for invalid vtbl pointers (e.g. when
reading uninitialized data). The fix is to move the insertion into the
map into the "if(rc)" branch.
Aug 01 2019
parent Bert <Bert gmail.com> writes:
On Friday, 2 August 2019 at 05:28:44 UTC, Rainer Schuetze wrote:

 On 01/08/2019 05:59, Bert wrote:

 On Sunday, 28 July 2019 at 11:45:21 UTC, Rainer Schuetze wrote:

 On 28/07/2019 06:59, Bert wrote:

 I can't imagine though why adding a simple field would screw 
 the code up.

 e.g.,

 class X {} // works.
 class Y { int y; } // fails.


 This wouldn't have failed, int needs a class/interface 
 member, e.g.

 class X
 {
    Q q; // non-null
    I c; // null
    Q s; // non-null
 }


 I would think that such things would have no effect on the 
 pointer value?

 Can you explain to me, for my own edification, why removing 
 those non-essential lines would produce the effect?


 The bug basically was similar to

 // global cache
 string[void*] mapVtblToClassName;

 void showX(X x)
 {
    void* vtbl;
    string classNameq;
    bool rc = ReadProcessMemory(x.q, vtbl); // reads vtbl-ptr
    if (rc)
    {
       if (vtbl in mapVtblToClassName)
       {
          classNameq = mapVtblToClassName[vtbl];
          goto Lnext;
       }
       classNameq = getClassNameFromVtbl(vtbl); // Q
    }
    mapVtblToClassName[vtbl] = classNameq;

 Lnext:
    string classNamec;
    rc = ReadProcessMemory(x.c, vtbl); // fails, vtbl unchanged
    if (rc)
    {
       // same as above...
    }
    mapVtblToClassName[vtbl] = classNamec; // overwrites entry 
 for Q
 }

 Next time a Q is evaluated, the determined class name will be 
 empty.


 
 
 Thanks. Ok, I see how the caching can be overwritten but I 
 still don't see how changing a field in the class, which won't 
 even modify the vtable, will effect the cache. I'd expect some 
 sort of determinism in this, in that if I compile the some 
 code and everything works and then simply add a field to a 
 class and recompile, little should change.
 
 E.g., if the cache is being overwritten in the first case then 
 adding the field shouldn't change it from being overwritten in 
 the second case.
 
 Oh, nevermind,
 
 ReadProcessMemory(x.q, vtbl);
 
 you are iterating over the entries in x to get their vtable! 
 So changing a field could cause a shift in the execution order 
 and hence initiate the overwrite. (some of the code is missing 
 above but I see how it could lead to these problems).
 
 While I still don't fully understand why the code is doing 
 what it does(e.g., q and c? I assume these are suppose to be 
 members). Seems there doesn't need to be a goto and 2nd branch 
 in theory but I guess it's incomplete code so I'll assume it 
 all is suppose to work[Or you are just showing a second 
 iteration].


 Yes, this was pseudo code showing the effect showing two calls 
 to the same function. I used "goto" where a function would use 
 "return".


 
 
 Essentially just one part of the code is buggy because 
 classNameq is empty and it can blindly overwrite the vtbl 
 value *if* any future iterations occur where the if(rc) check 
 fails(e.g., an added field).
 

    void* vtbl;
    string classNameq;
    bool rc = ReadProcessMemory(x.q, vtbl); // reads vtbl-ptr
    if (rc)
    {
       if (vtbl in mapVtblToClassName)
       {
          classNameq = mapVtblToClassName[vtbl];
          goto Lnext;
       }
       classNameq = getClassNameFromVtbl(vtbl); // Q
    }
    mapVtblToClassName[vtbl] = classNameq;


 
 
 which then something like
 
 if (classNameq) mapVtblToClassName[vtbl] = classNameq;
 
 would fix the problem?
 
 
 


 The empty classname is also cached for invalid vtbl pointers 
 (e.g. when
 reading uninitialized data). The fix is to move the insertion 
 into the
 map into the "if(rc)" branch.



Ok, thanks. At least it makes it clear how these errors can 
happen.
Aug 02 2019
prev sibling parent Bert <Bert gmail.com> writes:
On Friday, 12 July 2019 at 10:06:55 UTC, Rainer Schuetze wrote:

 On 11/07/2019 01:46, Bert wrote:

 The first and last are expandable, seems the middle is not 
 being resolved properly:
 
 -        arr    {length=3 ptr=0x0000028d2cbb60c0}
 inter[]
 +        [0]    0x0000028d2cbb3010 {}    inter {main.main.s1}
         [1]    0x0000028d2cbb3070 {}    inter
 +        [2]    0x0000028d2cbb30d0 {}    inter {main.main.s3}
 
 
 the 2nd entry is just main.main.s2
 
 
 Maybe you could just generate a large array of 
 interfaces(might try nestings, empty, derived classes, etc).


 It's a lot easier to reduce a failing test than to guess what 
 might go wrong, so a test case would be appreciated.

 I suspect s2 has a slightly more complicated inheritance tree. 
 The debugger simulates what happens in _d_toObject 
 (https://github.com/dlang/druntime/blob/master/src/rt/cast_.d#L25). Does
explicit cast(Object) work on that instance?



No, they are all the same... well, they might not be identical 
because they are different classes but they were copied and 
pasted. They do have some different values for fields but all the 
fields are the same and not complicated at all. They all inherit 
from the same base class and just fill in some of the values with 
the base class doing the heavy lifting.

they are all in the same array so no casting, but this seems 
related to the interface not expanding issue that has previously 
been a problem.

It's really hard to produce a consistent test case that causes 
these problems:

1. I can't upload all my code simply to give a simple case, there 
might be too many dependencies and such.

2. It's not easy to create a simple test case because it may 
actually work. These bugs in Visual D tend to have some "random" 
component to them. Change to much and things start working or 
have some specific thing in a project and things don't work but 
the relation is not obvious or easy to find.

Many times these "bugs" change even within the same program. Add 
a new line and then the behavior changes.

3. Even if I can produce a test case it may work fine on your end 
or fine most of the time.

There seem to be a deep bug in Visual D related to these things 
but it could just be a lot of minor stuff that has bit rotted. 
Ultimately you are going to be the one in the best position too 
deal with them.

I assume you don't use D often enough in complex projects to end 
up with these types of issues or your setup doesn't exhibit them 
as much or it is something specific on my end[Although, these 
errors are too general to be specific to things on my machine].

I imagine what happens is that over time the D compiler and that 
subtly breaks Visual D in various ways and only after some long 
period does someone notice it.

Maybe the best thing to solve most of these issues would be for 
you to maintain a machine, possibly a virtual machine, that has 
just visual D/studio on it(use it to install D with the new 
install features) and download some of the largest maintained D 
projects that you would be most familiar with. Then when someone 
reports something you can use it as a test bed to see if they 
exhibit similar issues.  You might already do something like 
this. What I have noticed though is that Visual D and dmd itself 
seem to work great when the project is small but once one reaches 
some critical mass things start going awry and generally these 
are hard to track bugs(nothing obvious, usually the error 
messages are not informative, etc).


I will try to start keeping a Visual D project for this too. 
Again, what I have noticed though is that it's very hard to get 
these bugs until the project becomes complicated[when I try to 
reduce things enough to remove what seems unrelated to the bug 
then the bug disappears, even things that are unrelated 
programmatically or are used trivially].

		[0]	0x00000281eaa32048 {}	inter
+		[1]	0x00000281eaa32148 {}	inter {main.main.s1}
		[2]	0x00000281eaa32048 {}	inter
+		[3]	0x00000281eaa32148 {}	inter {main.main.s1}
		[4]	0x00000281eaa32048 {}	inter
+		[5]	0x00000281eaa32148 {}	inter {main.main.s1}

It seems that Visual D does not realize the odd elements is a 
resolvable interface.

All these types are nested:

class c
{
     class s1 : inter;
     class s2 : inter;
}


I've tried creating a similar case but it doesn't have the 
problem. In the original code I use meta programming to generate 
the structure, but the much simplified "equivalent" doesn't have 
the problem. So I don't know how to fix it besides given you all 
my code, which I don't want to do and it technically may not help.

All I can say is that that I have an array of interfaces and some 
of the elements are not expandable. It shouldn't matter what 
those objects are, they all come from the same interface and 
Visual D shouldn't have a problem resolving any of them... even 
if they were drastically different.

This suggests a bug in the Visual D code that resolves the type 
for the object from the interface.

Given that previously Visual D would not resolve any interfaces 
this suggests maybe the new code you added recently is buggy/not 
general enough. Although it is working in the simple case.


--------------------------
Ok, after much work reducing to a test case I went from it not 
working to it working ;/

I can't explain why yet except that when I simplify the code past 
a certain point it then works.

ok, well, the reason why it's failing makes no sense. I 
essentially have some members in a class and when I remove the 
members then Visual D enables expansion of the interface.

This is the code, when I delete it, changes everything:

inter foo;
inter Foo() { return foo; }

Yes, that is right, when I remove that code and run the program 
then I can expand the element.

This is exactly what I mean! It makes absolutely no sense. But 
somehow it screws Visual D up.

Once I get the code completely reduced I will post it for your 
amusement... and I'll probably have to post a video proving it is 
doing what I say it is because it will probably work for you.

These types of bugs are the once that the D ecosystem seems to be 
riddled with. It's just a standard getter that is used all over 
the place yet it breaks things.
Jul 21 2019
prev sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 05/06/2019 02:57, Amex wrote:

 On Tuesday, 4 June 2019 at 07:45:56 UTC, Rainer Schuetze wrote:

 Hi,

 new beta2 available:
 https://github.com/dlang/visuald/releases/tag/v0.50.0-beta2


 Changes from beta1:

 * check and report invalid non-empty DMD/LDC installation folders
 * VC project:
   - DMD: fix wrong selections for bounds check options
   - LDC: added -mixin option
   - added enable -mixin option to autogenerate files according to the
 compilation model
   - new option for -extern-std=c++xx
 * visualdproj:
   - Error List: classify warnings and deprecations according to the
 respective options
   - bugzilla 19930: fix building projects with "&|<>" in directory names
 * mago: fix conditional breakpoints "not supported"

 Rainer


 On 31/05/2019 18:30, Rainer Schuetze wrote:

 Hi,

 for the adventurous: I have just released a preliminary version of
 Visual D with some new major changes:

 - there is now another installer available that includes DMD and LDC,
 so no additional setup steps necessary to get you going

 - now checks for updates for Visual D, DMD and LDC and assists with
 downloading and installing

 - experimental: highlight references to the same symbol as the one at
 the caret (to be enabled in the editor options)

 - mago debugger extension: better dynamic type handling of classes
 and interfaces, show exception message

 Grab it here:
 https://github.com/dlang/visuald/releases/tag/v0.50.0-beta1

 Cheers,
 Rainer




 
 
 I've noticed a weird behavior in Visual D projects. In the file tray(the
 drop down at the upper right of the source code window to find opened
 files) some of the D files have a different icon. One is a large red and
 white D while most others are a small red D.
 
 The large D's use all lowercase paths while the small D's used mixed
 case(this is not 100% every time though). (for example, I might see the
 file C:\Project\main.d and c:\project\test.d each with a different icon)
 
 I have had it where the same file was opened with the two different
 versions as if it was different file... changing one then changes the
 other(requiring a reload)... which can be dangerous since it can cause
 loss of changes. This has only happened a few times though and it
 happens when the debugger breaks in to a file and that is open(again,
 rare though).
 
 I guess it has to do with a direct string compare rather than first
 converting everything to the same case. s1 == s2 vs s1.toLower ==
 s2.toLower.
 
 It's not a big problem though but you might add it to your list in case
 you come across it while fixing other stuff. One of the key's will be
 the different D icons.
 
 It seems somewhere in Visual D.
 


I suspect that might have to do with different case being used in
filenames by the project and the debug information. Not sure if it can
be easily be changed (if it is changed by the compiler), but needs
further investigation...
Jun 05 2019
prev sibling next sibling parent Amex <Amex gmail.com> writes:
On Tuesday, 4 June 2019 at 07:45:56 UTC, Rainer Schuetze wrote:

 Hi,

 new beta2 available: 
 https://github.com/dlang/visuald/releases/tag/v0.50.0-beta2


 Changes from beta1:

 * check and report invalid non-empty DMD/LDC installation 
 folders
 * VC project:
   - DMD: fix wrong selections for bounds check options
   - LDC: added -mixin option
   - added enable -mixin option to autogenerate files according 
 to the
 compilation model
   - new option for -extern-std=c++xx
 * visualdproj:
   - Error List: classify warnings and deprecations according to 
 the
 respective options
   - bugzilla 19930: fix building projects with "&|<>" in 
 directory names
 * mago: fix conditional breakpoints "not supported"

 Rainer


 On 31/05/2019 18:30, Rainer Schuetze wrote:

 Hi,
 
 for the adventurous: I have just released a preliminary 
 version of Visual D with some new major changes:
 
 - there is now another installer available that includes DMD 
 and LDC, so no additional setup steps necessary to get you 
 going
 
 - now checks for updates for Visual D, DMD and LDC and assists 
 with downloading and installing
 
 - experimental: highlight references to the same symbol as the 
 one at the caret (to be enabled in the editor options)
 
 - mago debugger extension: better dynamic type handling of 
 classes and interfaces, show exception message
 
 Grab it here: 
 https://github.com/dlang/visuald/releases/tag/v0.50.0-beta1
 
 Cheers,
 Rainer




Thanks!
Jun 04 2019
prev sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
Hi,

another beta available:
https://github.com/dlang/visuald/releases/tag/v0.50.0-beta3

Changes from 0.50.0-beta2:

- full installer: slightly improve dmd directory names
- updates:
  - fix link to dmd prerelease download
  - wrong update frequency used for DMD
  - check DMD releases with prerelases, too
  - display HTML error
- mago: limit maximum number of elements for an array
- add option -lowmem

Rainer

On 04/06/2019 09:45, Rainer Schuetze wrote:

 Hi,
 
 new beta2 available:
 https://github.com/dlang/visuald/releases/tag/v0.50.0-beta2
 
 
 Changes from beta1:
 
 * check and report invalid non-empty DMD/LDC installation folders
 * VC project:
   - DMD: fix wrong selections for bounds check options
   - LDC: added -mixin option
   - added enable -mixin option to autogenerate files according to the
 compilation model
   - new option for -extern-std=c++xx
 * visualdproj:
   - Error List: classify warnings and deprecations according to the
 respective options
   - bugzilla 19930: fix building projects with "&|<>" in directory names
 * mago: fix conditional breakpoints "not supported"
 
 Rainer
 
 
 On 31/05/2019 18:30, Rainer Schuetze wrote:

 Hi,

 for the adventurous: I have just released a preliminary version of
 Visual D with some new major changes:

 - there is now another installer available that includes DMD and LDC, so
 no additional setup steps necessary to get you going

 - now checks for updates for Visual D, DMD and LDC and assists with
 downloading and installing

 - experimental: highlight references to the same symbol as the one at
 the caret (to be enabled in the editor options)

 - mago debugger extension: better dynamic type handling of classes and
 interfaces, show exception message

 Grab it here:
 https://github.com/dlang/visuald/releases/tag/v0.50.0-beta1

 Cheers,
 Rainer
Jun 15 2019
prev sibling parent a11e99z <black80 bk.ru> writes:
On Friday, 31 May 2019 at 16:30:02 UTC, Rainer Schuetze wrote:

 Hi,

 for the adventurous: I have just released a preliminary version 
 of Visual D with some new major changes:

 - there is now another installer available that includes DMD 
 and LDC, so no additional setup steps necessary to get you going

 - now checks for updates for Visual D, DMD and LDC and assists 
 with downloading and installing

 - experimental: highlight references to the same symbol as the 
 one at the caret (to be enabled in the editor options)

 - mago debugger extension: better dynamic type handling of 
 classes and interfaces, show exception message

 Grab it here: 
 https://github.com/dlang/visuald/releases/tag/v0.50.0-beta1

 Cheers,
 Rainer


thank you
Aug 08 2019