• Josphe Brigmo (33/33) Sep 13 2018 Suppose one does something like
• Josphe Brigmo (7/7) Sep 13 2018 Also, for functions with multiple arguments such as
• Rainer Schuetze (6/50) Sep 14 2018 Interesting idea, but not that simple. The semantic engine used in
• Josphe Brigmo (67/86) Sep 14 2018 Thanks.
• Rainer Schuetze (15/119) Sep 22 2018 Please don't confuse debugger info and semantic (compile time) info.

Josphe Brigmo <JospheBrigmo gmail.com> writes:

Suppose one does something like

baseName(x);

When highlighting the mouse over x, it VD shows the value of x.

When highlighting over baseName, it shows the functional 
information.

It would be nice if Visual D could evaluate the function at it's 
value.

It should be really simple to do:

Check if the argument's value is known, in this case it is, since 
it shows it to me. Check if the function can then be evaluated, 
which it can as it is a library function.

Basically a sort of CTFE for visual D in that it can evaluate 
functions a compile.

One thing I hate about D and visual D in general is that I almost 
always have to create compile time variables just to see what is 
going on.

By having such a feature, the computer will do all the work and 
save significant time(from a few minutes to create the temp 
variables, re-run the program, then remove them down to basically 
0 seconds).

It would actually be nice if one could see the values in any 
expression in a chain:

baseName(dire).stripExtension.toUpper....

Highlighting any of the functions will not just show 
documentation information or evaluating known variables but also 
evaluate the function on those variables if it can.

It can simply use a thread to try and evaluate the functions. If 
they are library functions it should not be difficult but also 
try functions in the user program. If they take too long simply 
time out. Should solve most of the issues.

IT would really speed up develop in D.
Maybe even string mixins could be evaluated this by showing a 
pop-up scrollable box with the expanded mixin and debug issues.

Josphe Brigmo <JospheBrigmo gmail.com> writes:

Also, for functions with multiple arguments such as

foo("a"~"asdf", 3 + 6);

It would be nice to show the arguments evaluated so we know what 
is going in to them rather than having to guess or use templates.

So the display string might show

foo("aasdf", 9) = 4

Thanks.

Rainer Schuetze <r.sagitario gmx.de> writes:

On 13/09/2018 11:26, Josphe Brigmo wrote:
 Suppose one does something like
 
 baseName(x);
 
 When highlighting the mouse over x, it VD shows the value of x.
 
 When highlighting over baseName, it shows the functional information.
 
 It would be nice if Visual D could evaluate the function at it's value.
 
 It should be really simple to do:

Interesting idea, but not that simple. The semantic engine used in 
Visual D can actually do some CTFE evaluation, but phobos library 
functions tend to be rather elaborate, so correct execution might not 
always succeed.

I can give it shot when I have some time.


 
 Check if the argument's value is known, in this case it is, since it 
 shows it to me. Check if the function can then be evaluated, which it 
 can as it is a library function.
 
 Basically a sort of CTFE for visual D in that it can evaluate functions 
 a compile.
 
 One thing I hate about D and visual D in general is that I almost always 
 have to create compile time variables just to see what is going on.
 
 By having such a feature, the computer will do all the work and save 
 significant time(from a few minutes to create the temp variables, re-run 
 the program, then remove them down to basically 0 seconds).
 
 It would actually be nice if one could see the values in any expression 
 in a chain:
 
 baseName(dire).stripExtension.toUpper....
 
 Highlighting any of the functions will not just show documentation 
 information or evaluating known variables but also evaluate the function 
 on those variables if it can.
 
 It can simply use a thread to try and evaluate the functions. If they 
 are library functions it should not be difficult but also try functions 
 in the user program. If they take too long simply time out. Should solve 
 most of the issues.
 
 IT would really speed up develop in D.
 Maybe even string mixins could be evaluated this by showing a pop-up 
 scrollable box with the expanded mixin and debug issues.
 

Josphe Brigmo <JospheBrigmo gmail.com> writes:

On Friday, 14 September 2018 at 08:14:37 UTC, Rainer Schuetze 
wrote:
 On 13/09/2018 11:26, Josphe Brigmo wrote:
 Suppose one does something like
 
 baseName(x);
 
 When highlighting the mouse over x, it VD shows the value of x.
 
 When highlighting over baseName, it shows the functional 
 information.
 
 It would be nice if Visual D could evaluate the function at 
 it's value.
 
 It should be really simple to do:

 Interesting idea, but not that simple. The semantic engine used 
 in Visual D can actually do some CTFE evaluation, but phobos 
 library functions tend to be rather elaborate, so correct 
 execution might not always succeed.

 I can give it shot when I have some time.

Thanks.

It doesn't always have to work, just most of the time(well even 
only some of the time is better than nothing).

For simple functions it should work fine except maybe in some 
cases with user functions. I imagine the library functions should 
be well behaved 99% of the time.

Also, another thing is that function results are always available 
after executing so they could be used. The problem is one would 
have to execute the line first. This is not necessarily bad as it 
still provides plenty of info but it might not always be 
applicable(e.g., we might not want to execute the line before 
validating it's arguments).

But stuff like "asdfdsa".toUpper.split("d").

should be processed. For arrays, of course, only display a 
limited number.

Executing this stuff in a thread that can terminate should help 
for any major issues(such as functions that use readln).

It's not so much about getting every case but covering the most 
common cases so temp variables don't have to be created. For more 
problematic cases, one can simply use whatever means they 
currently use without the feature(such as temp variables).


Another idea, if it is not too hard:

Allow the user to select some code that Visual D then 
"extracts"(copies) and runs in a separate process. This doesn't 
seem very useful in general because most code will not compile, 
but with some code or different coding styles one can execute 
simple code and get results.

This might work while one is debugging and Visual D takes any 
"captured" variables and gets their values from the trace.

Then runs it in a repl like environment which the user can then 
change the values or see more what is going on. (Might wrap any 
selected code in a function that takes the captured variables and 
then the user can call it many times on different values if 
needed.)

This helps diagnose certain problems and avoid wasting a lot of 
time on trying manipulate the problem to get it in a form that is 
testable(such as copying the code manually in to another project 
or using an online D compiler... which, in
fact, might work:

It could just copy it to an online D editor e.g., 
https://run.dlang.io/:

e.g.,

<selected code>
int x = 43;
foo(x);
<end>


Then VD can just copy that code in to the editor window(with 
default imports so the user doesn't have to type them every time 
such as std.stdio, std.typecons, std.meta, std.algorithm, etc 
maybe all named to avoid conflicts).

Then that allows one to quickly play and test code without having 
to do much work.

The idea is that it would save a few minutes of setting up the 
code(opening a brower(manually, takes a few seconds), finding the 
link(another few seconds), pasting the code(another few seconds), 
adding imports and main to wrap the code, etc..

So, Just to test some code one is wasting around a minute of 
time. This all could be automated so it is juts a few seconds in 
cost.

In fact, it would be cool if one could just open the editor in a 
new window in VS and do it from there.

This is not a big deal though as one can setup an environment to 
do this relatively fast(hot keys, etc) but might make some 
peoples lives easier in some ways.
)

Rainer Schuetze <r.sagitario gmx.de> writes:

On 14/09/2018 12:15, Josphe Brigmo wrote:
 On Friday, 14 September 2018 at 08:14:37 UTC, Rainer Schuetze wrote:
 On 13/09/2018 11:26, Josphe Brigmo wrote:
 Suppose one does something like

 baseName(x);

 When highlighting the mouse over x, it VD shows the value of x.

 When highlighting over baseName, it shows the functional information.

 It would be nice if Visual D could evaluate the function at it's value.

 It should be really simple to do:

 Interesting idea, but not that simple. The semantic engine used in 
 Visual D can actually do some CTFE evaluation, but phobos library 
 functions tend to be rather elaborate, so correct execution might not 
 always succeed.

 I can give it shot when I have some time.

 
 Thanks.
 
 It doesn't always have to work, just most of the time(well even only 
 some of the time is better than nothing).
 
 For simple functions it should work fine except maybe in some cases with 
 user functions. I imagine the library functions should be well behaved 
 99% of the time.
 
 Also, another thing is that function results are always available after 
 executing so they could be used. The problem is one would have to 
 execute the line first. This is not necessarily bad as it still provides 
 plenty of info but it might not always be applicable(e.g., we might not 
 want to execute the line before validating it's arguments).

Please don't confuse debugger info and semantic (compile time) info. 
These are not always available at the same time.

 
 But stuff like "asdfdsa".toUpper.split("d").

If you look at there implementations (including template constraints) 
these are not simple functions. I suspect very few of phobos are.

 
 should be processed. For arrays, of course, only display a limited number.
 
 Executing this stuff in a thread that can terminate should help for any 
 major issues(such as functions that use readln).
 
 It's not so much about getting every case but covering the most common 
 cases so temp variables don't have to be created. For more problematic 
 cases, one can simply use whatever means they currently use without the 
 feature(such as temp variables).

What I've been looking into is showing the value of compile time 
constants (e.g. enums) and expressions of them via the semantic engine. 
That usually means having a complete compiler available, though.

On the other hand, the latest build on appveyor shows the return values 
of functions that you stepped over in the debugger (but unfortunately 
not slices), see 
https://ci.appveyor.com/project/rainers/visuald/build/1.0.230/job/c2g9qeg8c1dau3v6

 
 Another idea, if it is not too hard:
 
 Allow the user to select some code that Visual D then "extracts"(copies) 
 and runs in a separate process. This doesn't seem very useful in general 
 because most code will not compile, but with some code or different 
 coding styles one can execute simple code and get results.
 
 This might work while one is debugging and Visual D takes any "captured" 
 variables and gets their values from the trace.
 
 Then runs it in a repl like environment which the user can then change 
 the values or see more what is going on. (Might wrap any selected code 
 in a function that takes the captured variables and then the user can 
 call it many times on different values if needed.)
 
 This helps diagnose certain problems and avoid wasting a lot of time on 
 trying manipulate the problem to get it in a form that is testable(such 
 as copying the code manually in to another project or using an online D 
 compiler... which, in
 fact, might work:
 
 It could just copy it to an online D editor e.g., https://run.dlang.io/:
 
 e.g.,
 
 <selected code>
 int x = 43;
 foo(x);
 <end>
 
 
 Then VD can just copy that code in to the editor window(with default 
 imports so the user doesn't have to type them every time such as 
 std.stdio, std.typecons, std.meta, std.algorithm, etc maybe all named to 
 avoid conflicts).
 
 Then that allows one to quickly play and test code without having to do 
 much work.
 
 The idea is that it would save a few minutes of setting up the 
 code(opening a brower(manually, takes a few seconds), finding the 
 link(another few seconds), pasting the code(another few seconds), adding 
 imports and main to wrap the code, etc..
 
 So, Just to test some code one is wasting around a minute of time. This 
 all could be automated so it is juts a few seconds in cost.
 
 In fact, it would be cool if one could just open the editor in a new 
 window in VS and do it from there.
 
 This is not a big deal though as one can setup an environment to do this 
 relatively fast(hot keys, etc) but might make some peoples lives easier 
 in some ways.
 )

The function "Compile and run" more or less does that: if there is a 
selection it passes the selected code to rdmd --eval. Unfortunately this 
function seems broken ATM.