Visual D evaluate simple functions for information

[Rainer Schuetze]

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.