LINQPad Debugger - Early Input Request!
What are your thoughts on integrated debugging within LINQPad?
In particular:
In particular:
- What features in Visual Studio's debugger do you consider important / unimportant for LINQPad?
- What unique/original/outside-the-box debugging features could fit well with LINQPad? For instance, would the ability to send any local variable to the Dump pipeline be useful?
- Debugger support requires that LINQPad shifts from an AppDomain-isolation model to a process-isolation model. The performance cost on today's hardware is minimal, but there will be subtle changes in how queries execute. Mostly good (StackOverflowException will not take down the host, the current directory would be stable and locked to the query's path, etc). Your thoughts?
- Funding: would you pay extra for this functionality? The development cost to get this to production quality is maybe 3-4 man-months with late nights
Comments
But its a good idea nevertheless
In that order:
Breakpoints + Quick watch
Callstack window
Threads window
Funding: would you pay extra for this functionality?
I think I would, however I would still be rather annoyed if my original purchase didn't get the update with this additional feature once its added.
I already have the pro license, so obviously I'd like to see that include the debugging features, but if I hadn't purchased it yet then the addition of debugging support would definitely have convinced me to purchase.
Callstack window
Threads window
see variables in the output window
process-isolation model would be fine by me. i mostly use it to test out small things quickly.
yes i would if i buy linqpad license. i already have license so it would be nice to get it as upgrade.
Step Into, Over, and Out
In terms of funding, I have the pro license, I would expect that to be included as well.
Thanks for looking into this, it will make LinqPad even more useful to me !
What features in Visual Studio's debugger do you consider important / unimportant for LINQPad?
Must have
- step by step execution
- breakpoints
- watch on variable/field/property
Nice to have :
- break on exception
- call stack view, thread list
- move "next statement" cursor
- watch on expression (method call, etc)
Probably overkill :
- edit and continue ;-)
What unique/original/outside-the-box debugging features could fit well with LINQPad? For instance, would the ability to send any local variable to the Dump pipeline be useful?
That would certainly be useful. I can't think of anything else right now.
Debugger support requires that LINQPad shifts from an AppDomain-isolation model to a process-isolation model. The performance cost on today's hardware is minimal, but there will be subtle changes in how queries execute. Mostly good (StackOverflowException will not take down the host, the current directory would be stable and locked to the query's path, etc). Your thoughts?
I don't have a problem with that, and I think most people won't either. For most queries, the differences will probably have no effect, as far as I can tell.
Funding: would you pay extra for this functionality?
By "extra", do you mean in addition to the cost of the premium edition? Or just that the feature will not be in the free version?
One of the most important things to me about this tool is that it is quick to install, launches quickly, lets me prototype & run w/o all the bloat of a the full IDE.
When I need to do real debugging, I fire up the big guns...
There is a small performance hit in attaching a debugger, but my plan is for this to be incurred only if you set breakpoints or do something that explicitly requires a debugger. The default will be to run without debugging.
1. Breakpoints
2. Ability to step line by line
3. Watch field/variable/property
I don't know that call stack or thread view is that essential to me. I view this more as a lightweight bonus feature that saves me from having to fire up VS just to watch a couple of variables. I definitely like the idea of the ability to send any local variable to the dump pipeline. I would say, the addition of breakpoints and line by line stepping with the dump line addition would satisfy my needs.
I disagree with all the comments that want this feature for free. It is a lot of work and to develop and you should be able to charge for a large upgrade. Perhaps call it linqpad 5.0 and charge $20+ to upgrade? Every business has an upgrade or subscription model to encourage continued development. Linqpad is my second most used tool behind VS, and I would be surprised if you don't develop a similar model.
I'd like to be able to specify .Dump() (and overloads) without having to write it. Being able to select a spot in the code/expression, right click add dump. Being able to then view the output on demand rather than all the time would be great. Treating dumps like a log level would be great. That's how I've been debugging in linqpad for years.
I like the idea of treating .dump()like a watch
The biggest feature I miss in linqpad from VS w/ R# is being able to navigate the code, like clicking on the function and going to definition, or viewing implementation.
Are you considering using roslyn for these new features? That's why I mentioned navigation.
I'd pay $20 extra for all these features. Considering the value I've gotten from linqpad, I'd pay $100+ all up.
For most small and fast queries, we do not need it. LINQPad already excels in debug-by-printf. Most of our users do not write sophisticated C# programs.
You were asking if there was a LINQPad angle to this. I think that one (ambitious) such angle would be to be able to break execution and then do ad-hoc queries within that context acting on the live context.
This would have more uses than debugging. This would cover the cases of object reuse where Util.Cache is either contrived or limited. It may even redefine C# programming if variables had value as you are typing the program.
Considering you are a one man shop, I'm not suggesting that this "breaking into a C# shell" is where you should put your efforts. I am just applying the LINQPad game changing mentality to debugging.
Would we pay? Yes, we would. There are definetely caveats that warrant a "LINQPad ultimate", but the first item on my wish list is actually source control (git), then debugger, then code navigation. Being an early backer of LINQPad certainly paid off last time and it has been great value for us. Being an active user on this forum, as well.
I would happily pay a couple of hundred bucks to upgrade my corporate license. Just keep it lightweight and hassle free activation within the organization. The latter has been a huge win with us. I even contacted you on an earlier occasion asking if we should pay you more as the deal appeared one-sided in our favour.
The LINQPad story in my organization has been to put enormous initial power in the hands of domain experts, who then can follow the trail of business problems into the rabbit hole till they are full time programmers. Due to the licensing model, there is no internal administration to set up a new user with the environment that could potentially turn some trivial business problem to a life changing event.
When I need to do intense debugging, I add a line like System.Diagnostics.Debugger.Attach() which will launch VS.
The most useful functionality would be
1. SetBreakpoint (If we get an exception, Linqpad already shows where the exception occurs, and I can rerun by setting a breakpoint there)
2. View variables (Dumping into the output window would be great and enough. I already wrote VS visualizers which emulate the Dump and use those mainly for any complex object)
3. Step In / Step Over
Regarding paying:
We all new when we payed for Linqpad (a ridiculously low amount IMHO), that we were paying for auto completion. Debugging is a whole new type of functionality, which we should support (not only in words).
OTOH, having debugging built in would probably make it even more useful, and would give you more users, which might pay for the premium edition. In my previous company I was credited with introducing them to Linqpad, and they bought the Premium edititon. I have failed to do so in my current company so far (I use the Autocomplete licenses I personally bought) and having debugging might help change their mind. As I don't have any statistics on the users of Linqpad and the amount of licenses sold, only Joe A. can make the marketing decisison as how to charge for it.
I use Linqpad so much that I would like any kind of preview (even with only limited functionality) any time
1. Breakpoints, step in/out
2. Variable window
3. to be able to change variable values / code (including intellisense) and continue to debug
4. Make jumps to variable or method definition from code that's using it.
Yes, I would like to pay extra for it - I wouldn't mind if my life-time upgrade license wouldn't cover this kind of upgrade. AFAIK you could consider releasing the debugger as an additional product or add-on to LinqPad if you think other people would mind.
For debugging the (often non-trivial) code that I write in LINQPad, I find
.Dump()and (the less memory hungry)Console.WriteLinequite sufficient. But I do note that I nowadays wrap many of those state-dumps inside#if debugstatements, to ensure I only see them when I run in LINQPad.exe and not when I use LPRun.exe. So in a sense, LINQPad is already my debugger, while LPRun is the runtime for a release version.But wrapping code in
#if debugis tedious and makes it harder to read. I'd prefer to keep my application logic separate from my debugging code. One great way to accomplish this would be to add a feature like a TracePoint from Visual Studio to LINQPad. A TracePoint allows you to write a message to the debug console, including values of variables, so it would essentially take the.Dump()outside of my code into the gutter. LINQPad proper would execute these TracePoints, while LPRun would ignore them. Combine that with making such TracePoints conditional (like they are in Visual Studio) and I doubt I'd ever have a need to actually pause execution of a script.http://www.linqpad.net/beta.aspx
Each query now runs in its own process. This improves robustness in that uncatchable exceptions (such as StackOverflowException) can no longer take down the LINQPad host process.
Performance should improve insofar as each query now has its own memory space and GC, at the expense of a small latency in spinning a new process, which I've mitigated with a speculative process cache. I've also gone to some lengths to ensure that query processes are never left behind after LINQPad exits, even if the host is rudely terminated or the query is unresponsive.
Tell me what you think of the performance, and whether you find any gremlins. It's possible that there may be subtle differences in how queries execute in their own process.
Cheers
Joe
My suggestions are :
- either add a way to get the current process id on the tab
- or add the name of the query to the process created
http://www.linqpad.net/beta.aspx
-Karl
Just downloaded the beta (and upgraded to Premium).
A quick suggestion: Allowing to place breakpoints in "My Extensions" could be useful