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.

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.

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.
> 

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.
)

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.