Visual D evaluate simple functions for information

[Josphe Brigmo]

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