Comments - SwensenSoftware/fseye GitHub Wiki
Comments, Suggestions, and Feedback
The following is an archive of comments on the old Google Code project site.
Comment by oldrich.svec, Jun 7, 2011
Hi,
this looks as a very nice tool! Would it be possible to make it into a Visual Studio addon, so that the window would be part of the VS?
Thanks again for your great work! Oldrich
Comment by project member stephen.swensen, Jun 8, 2011
Hi Oldrich,
Thanks again for your encouraging feedback, I'm really glad you like it. As I said over on Stack Overflow, I am definitely planning on investigating making it into a Visual Studio add-on.
Stephen
Comment by oldrich.svec, Jun 8, 2011
Hi Stephen,
I think that a good starting point might be to watch this 18 minutes long video: http://msdn.microsoft.com/en-us/vstudio/cc512461
Comment by paul.v.young, Aug 4, 2011
Hi Stephen, I would also like to say thank you for your excellent work. I'm new to F# and I'm exploring using FSI for technical computing. This makes FsEye an incredibly useful tool for me.
I do have a handful of comments (sorry if these are repeats)..
it would be great if there was a way of organising watches within FsEye window. It can quickly fill up and it can be hard to find and compare values. For example, if tabs could be added and named at will and then watches dragged between them that would help. perhaps you could explore using grids. it would help with the viewing and comparison between lists, arrays etc. performance seems slow. I'm not sure if I have a problem, but if I start a new FSI, and type let z = [1..100];; it can take 5 to 10 seconds before the watch appears and FSI returns a prompt? thanks again, Paul
Comment by paul.v.young, Aug 4, 2011
Just to add to my previous comment. Whereas typing "let z = [1..100];;" can take 10 sec to return if I type "eye.Watch("x",[1..100]);;" this always returns instantly. Paul
(Win 7 64bit, VS2010 v10.0.40219.1 SP1Rel, .NET v4.0.30319 SP1, FSI build 4.0.40219.1)
Comment by project member stephen.swensen, Aug 7, 2011
Hi Paul - thanks for the excellent feedback!
I really like your ideas for organizing watches, I will look into this. Note that right now FsEye does have a much more limited way of organizing watches into "Archives", but this only allows you to archive all the currently active watches without the fine-grained organization you are talking about (see the User Guide for more info if you were not aware of this feature).
Your idea about using grids is less clear to me. Do you mean something basically like what the Visual Studio Watch and Locals window use, a hybrid TreeView / Grid
Regarding performance this is a known issue and is due to the way FsEye discovers all FSI session variables and is notified of new session variables. FSI does not expose a rich API for interacting with it. In order to discover all the variables in the FSI session we need to use reflection to scan all the FSI related dynamic assemblies. While that in itself takes some serious CPU cycles, it's sub-second in one pass. However, the only way I am aware of being notified that a new variable has been submitted to the FSI session is by adding a PrintTransformer which is notified every-time time an object is printed in FSI. Now, for simple objects this is not a problem, since the print transformer event is only fired once. However for composite objects like a list of integers this can be can harm performance since, for example, [1..100] will trigger the event 100 times! I will continue to look into ways to avoid the performance issues that arise from this hack. But in the mean-time there is one thing you can do: you can tell FSI to limit the number of elements shown in lists using fsi.PrintLength, e.g. fsi.PrintLength <- 5 would tell FSI to only print the first 5 elements of lists which should lead to a dramatic performance improvement since then the print transformer event will only fire 5 times instead of 100!
Thanks again for your feedback, it really helps motive me knowing folks find this tool useful!
Comment by project member stephen.swensen, Aug 8, 2011
Paul - I elevated to performance issue to a formal high-priority issue, Issue 14 . I fixed it using a nice async hack: I turn off the listener temporarily for 100ms when the first print event is raised, and then turn it back on again after the non-blocking sleep. I will be releasing FsEye 1.0.0 final soon so you'll be able to see this fix soon.
Comment by paul.v.young, Oct 29, 2011
Hi Stephen, I just wanted to say thanks for the new release. FsEye is a really useful tool and really appreciate the work you have put into it and the fact that you have made it available to everyone. regards, Paul
Comment by DavidGrenier, Jan 2, 2012
Just mighty!
Comment by nicolas.rolland, Mar 13, 2012
your software is amazing. truely amazing. Is it possible to enable only the programmatic way of adding watch ? Aka, disable to first way, from "let bindings" to have watch appear in the window.
Comment by nicolas.rolland, Mar 13, 2012
I imagine I can instantiate the same way you do in your script, which binds the fsi session. Is there any way to "unbind" once binded btw?
Comment by project member stephen.swensen, Mar 13, 2012
Hi Nicolas - thanks for the complement, glad FsEye is as useful to you as it is to me!
Good question, and the answer is: "yes"! Simply execute
eye.Listen <- false;;
within the FSI session and that will "unbind" automatic FSI watch listening but you can still programmatically add and remove watches.
Comment by funnelweb007, Nov 23, 2012
Hi Stephen,
Would you like to move this project into the F# open source group, http://fsharp.github.com? It may help you get more contributors and raise the visibility of the project in the F# community
-- ben winkel (@winkler_ben on twitter)
Comment by funnelweb007, Nov 23, 2012
If you would like to, please email me
Comment by project member stephen.swensen, Nov 24, 2012
Hi Ben - I appreciate your invitation, I know a lot of good stuff is going on over at http://fsharp.github.com. But I am pleased with google code's open source project hosting, and believe it will continue to be a good home for FsEye.
Thanks, Stephen
Comment by funnelweb007, Dec 9, 2012
That's fine. Can we link to it from http://fsharp.github.com - so it is part of the F# OSG "family" but not actually in github?
Comment by project member stephen.swensen, Dec 9, 2012
Ben - Absolutely. I would be honored to have FsEye linked to as part of the F# OSG family.
Comment by kukulcanenator, Mar 18, 2013
Hi, if effort is been made to make this a VS plugin could this also be extended to MonoDevelop, perhaps having a platform agnostic base would be the first step. I.e gtk GUI maybe, I would be interested in helping with a MonoDevelop integration point.
As Ben mentioned having this on GitHub would be nice.
Cheers Dave.
Comment by project member stephen.swensen, Mar 18, 2013
Hi Dave - I made a strong effort to get FsEye embedded as a VS plugin (see issue 18, and the vs-addin and vs-ext source branches), but found my self at a dead end. The big difficulty is that VS plugins and extensions live in separate AppDomains, and marshaling and unmarshaling communication between the FSI plugin and a would-be FsEye plugin or extension presents a very deep difficulty. I am not sure what the MonoDevelop architecture is like. However, I think a very doable solution for both VS and MonoDevelop, would be to create and new "Visual FSI" plugin which combines FSI and FsEye (or perhaps more generally FSI + a pluggable visual panel area) into one plugin so that they can communicate freely within the same AppDomain.
A GTK-based GUI would be very much in the realm as possibility, since the FsEye WatchModel is well-separated from the EyeForm (and other WinForm views). However, note that the FsEye binaries do run against mono's WinForms implementation (on linux at least), and I was able to even get an experimental MonoDevelop-based project running with minimal effort (see the mono source branch). Also, I worry that GUI fragmentation would undermine FsEye plugin development (which is based on WinForms), not to mention cross-platform feature parity. Also note that a big reason for the selection of WinForms for FsEye is because the FSI built-in GUI event loop is made for WinForms (and low-barrier to entry is a major goal of FsEye).
I went ahead and gave you committer access on the project. Please avoid committing to trunk for now, but feel free to create branches for any work you wish to pursue.
Regards, Stephen.