Home

LINQPad Debugger - Early Input Request!

edited July 2014
What are your thoughts on integrated debugging within LINQPad?

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 :)
And when would you like a preview? :)
«1

Comments

  • I do debugging inside VS for linq queries by attaching a process.
    But its a good idea nevertheless :)
  • What features in Visual Studio's debugger do you consider important / unimportant for LINQPad?


    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.
  • Breakpoints and Watch/QuickWatch would definitely be the most important features. A call stack of some sort would also be handy, so we could see where the query jumped in and out of our Extensions, and any external code we're using.

    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.
  • Breakpoints + Quick watch
    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.
  • Breakpoints + Quick watch
    Step Into, Over, and Out
  • +1 for breakpoints + watch window. locals window would be useful, but not as important as watch window (IMHO). in any event, it would be the clincher if the watch/locals would be implemented with DumpLive for interactivity.

    In terms of funding, I have the pro license, I would expect that to be included as well.
  • Hi Joe,

    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?
  • Debugging support would be GREAT - BUT - I don't want to comprise the speed and light weight nature of the tool!

    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...
  • edited July 2014
    I'm with you, ehoffman, there can be no compromise in speed or weight!

    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.
  • Essential:
    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.
  • Just-in-time debugging on an unhandled exception would be very handy for debugging a failing script.
  • I use Enumerable Debugger Visualizer extensively to debug my queries. (http://rapiddevbookcode.codeplex.com/wikipage?title=EnumerableDebugVisualizer) including this kind of thing with quickwatch will be a huge plus.
  • Hello, I agree with the functionality comments of others, and would really love query focused debugging.

    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.
  • Re: dump

    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.
  • I think most have been said, so I wont repeat the basics.

    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.
  • I use Linqpad mainly for lightweight scripts and for checking basic behavior of C# syntax. As such I don't need fancy debug viewers like threads etc.
    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
  • I' d like:
    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.

  • I love LinqPad and use it in my daily workflow, sometimes even more than Visual Studio. Because I use it so much, I have no problems paying for it. Therefore, a extra cost to get these features are absolutely justified, because it will make my workflow easier. So yes, I'd definitely pay extra for this.
  • Thanks for your feedback! To clarify a few of points:
    • LINQPad will stay lightweight, with the debugger having a minimal effect on performance except when explicitly invoked. The model I'm working on right now is "just-in-time": it will kick in only when you set a breakpoint, hit "Break", or an unhandled exception occurs. When you resume (or delete/disable breakpoints), the debugger will automatically disconnect.
    • Any additional fee for the debugger would be via a new licensing tier. If you don't care for debugging, you'll still receive updates/improvements/new features in accordance with your license, debugging features excluded.
    • Edit and continue is possible but incompatible with just-in-time debugging. So you would have to commit in advance to running a query with the debugger attached.
  • Hey Joe - looking forward to some betas of the debugger. The new licensing tier makes sense, and can't say enough how some simple breakpoints and watch lists will speed up development.
  • I find that launching Visual Studio for debugging is usually good enough for me. But I also notice that I mostly do that for stepping into (sometimes automatically decompiled third-party) libraries. I doubt it'd be economical to add debugging abilities up to that level to LINQPad.

    For debugging the (often non-trivial) code that I write in LINQPad, I find .Dump() and (the less memory hungry) Console.WriteLine quite sufficient. But I do note that I nowadays wrap many of those state-dumps inside #if debug statements, 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 debug is 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.
  • A prerequisite for writing a debugger is moving from AppDomain isolation to process isolation. A beta with this feature is now ready:

    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
  • Nice work, But this change makes it a little harder to know which process is running the query (useful when you wan to attach visual studio) so it would be nice to have away to identify the process running the query (other than Process.GetCurrentProcess().Id.Dump()) .
    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
  • Good call. Adding the name of the query to the process is problematic in that the process is created in advance from a global cache. However, it's easy enough to add the process PID to LINQPad's status bar, which is what I'll do.
  • Object/variable inspector in VS is slow for complex things. QuickWatch in vs is sometimes really not quick especially when dealing with large result sets. If you can beat that with a simpler interface like your dump() to HTML, I think you'll have a win and can charge a little more.
  • This would be great. If it involved making something like Linqpad v5 a paid update I wouldn't mind that. It's a great tool, and I did find debugging by attaching to process and viewing it in VS to be pretty crashy so I'm really looking forward to this one.
  • I think it would be great to be able to just allow to pause after each dump then it would be sort of debugging!
  • Just loaded the beta - incredible! Looking forward to using it more this week,

    -Karl
  • Hi,

    Just downloaded the beta (and upgraded to Premium).
    A quick suggestion: Allowing to place breakpoints in "My Extensions" could be useful
Sign In or Register to comment.