Settings and activity
11 results found
-
62 votes
james.manning
supported this idea
·
-
303 votes
An error occurred while saving the comment -
1,685 votes
An error occurred while saving the comment james.manning
commented
Agreed with Keith - with recent versions, using lprun.exe seems like it's sufficient to cover this use case, and we can/should close this.
-
6 votesjames.manning
shared this idea
·
-
1 vote
An error occurred while saving the comment james.manning
commented
Seems like it's a chicken-and-egg problem - if you're not going to pass in the identifying info (cache key), then how would the Cache method know whether it can/should return the cached object or not? Seems like the only option would be executing the code again, negating the value of the cache.
If you find that you do this often (caching different particular rows at different times), then you might want to instead cache a dictionary or the like so you can index into it and be more explicit about the item you're wanting to fetch from the cache? Admittedly, at that point you're reinventing the cache key, so I'd say if you have problems with mentally keeping track of what Cache is currently holding, then just never use the no-params overload and always be explicit in what you're caching by key name :)
-
266 votesjames.manning
supported this idea
·
-
14 votesjames.manning
supported this idea
·
-
73 votesjames.manning
shared this idea
·
-
7 votes
An error occurred while saving the comment james.manning
commented
I'm a little worried that this suggestion isn't getting the traction it deserves because of its brevity. To try and help that a bit, one of the experiences I love is the REPL with PowerShell, where I can fetch objects, view them, filter them, sort them, group them, etc with PowerShell's cmdlets.
The main problem is that often I want/need to use LINQ statements instead, but even if I'm willing to deal with calling the static extension methods manually, I'm still stuck with not having lambda-type support in the PowerShell parser.
Mono's project CsharpRepl (http://www.mono-project.com/CsharpRepl) is indeed a good example of the kind of experience I'd like to see - instead of LINQPad's current behavior of executing the script and then throwing everything away, it could instead keep the context / method / whatever around and after displaying the results, allow the user to execute the next statement(s) in the same context (so the local variables, etc. are all still around in memory).
On the surface of things, it seems like hosting the PowerShell engine (which is very simple, especially with v2) might make this easier for LINQPad, as it wouldn't have to maintain all that shell-like state, and could let PowerShell handle that, just compiling and executing (or having PowerShell's engine execute) the code from the user.
Another alternative would be to try and put a C# REPL on top of / inside of PowerShell, but I think that would be unfortunate since LINQPad already does so much heavy lifting around building/maintaining the data connections, providing a great UI, providing export functionality, etc.
james.manning
supported this idea
·
-
4 votesjames.manning
shared this idea
·
-
32 votes
This use case is largely handled by lprun.exe now
https://www.linqpad.net/lprun.aspx