VSLab Regression tests and doc

by cisterni 28. September 2008 18:30

I've just added a project for regression tests in VSLab. It is also interesting because it shows very simple viewlets doing simple things and it can also be a good way to learn Viewlet development. So far there are two viewlets checking mouse move and resize events. Here is the code:

#light

open System.Drawing

open VSLab

type ShowStringViewlet() =  inherit Viewlet()

 

  [<DefaultValue>]

  val mutable displayString : string

 

  override self.OnPaint(e) =     let g = e.Graphics

    g.DrawString(self.displayString, self.Font, Brushes.Black, 0.0f, 0.0f)

 

type
MouseMotionViewlet() as x =  inherit ShowStringViewlet()

 

  do x.displayString <- "Move the mouse inside the area"

 

  override self.OnMouseMove(e) =     self.displayString <- sprintf "x: %d, y: %d" (e.X) (e.Y)

    self.Invalidate(new Rectangle(0, 0, 200, 50))

let mmv = new MouseMotionViewlet()

mmv.Show()

mmv.Close()

 

type
ResizeViewlet() as x =  inherit ShowStringViewlet()

 

  do x.displayString <- "Resize the viewlet"

 

  override x.OnSizeChanged (e) =

    x.displayString <- sprintf "Size is (%d, %d)" (x.Width) (x.Height)

let rv = new ResizeViewlet()

rv.Show()

rv.Close()

 

 I hope this can be useful.

Currently rated 1.5 by 2 people

  • Currently 1.5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,

General | Viewlets

VSLab: Call for feedback

by cisterni 23. September 2008 00:18

I'm googling to check how people is receiving VSLab and how it is used. I know that so far the project is useful only if you want to extend VS and basic packages are missing. Today I found a post about someone having problem with VSLab installation and upgrading. I wish people will contact me through the CodePlex Web site or on this blog to notify issues as well as success stories. VSLab is turning 0.25 (3 months) and 1k downloads are close!

I know I have to do doc update, but there are cool things going on under the hood, the VSLab Shell is perhaps the coolest, but we are also working to new Viewlets and samples to make VSLab more useful. If you developed a viewlet let us know, so that we can let other people know about your work and experiments. Don't hesitate also to ask for improvements, according to our resources we are willing to improve VSLab.

Antonio

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Design | General

Piping processes, VSLab Shell foundations

by cisterni 16. September 2008 09:40

VSLab provides the foundations for using Visual Studio as an interactive environment, a sort of big environment for Domain Specific Languages in which you can issue commands interactively to control virtually anything. Now that this foundation is in place we are working to provide the set of packages that shows this potential and transform VSLab into something that is usable for people, not only by F# programmers. Of course this is also a way to find the right abstractions you need when developing packages so that we can possibly extend the core to support new functionalities.

One of the coolest packages I'm working on is the VSLab Shell package, a mean to turn VS into next generation interactive shell, in which text and GUI mix together to obtain a new environment in which point-and-click is used in conjunction with text-based scripts to get the best from the two environments. We are currently defining the core operations of a traditional shell, such as process management and piping, and I want to share with you a neat piece of code we wrote this night to express process piping using F# and F# interactive. Here is the code:

open System.Diagnostics

open System.IO

let pwd = Directory.GetCurrentDirectory

let createProcess exec args =

  let pi = new ProcessStartInfo()

  pi.Arguments <- args

  pi.CreateNoWindow <- false

  pi.RedirectStandardInput <- true

  pi.RedirectStandardError <- true

  pi.RedirectStandardOutput <- true

  pi.UseShellExecute <- false

  pi.WorkingDirectory <- pwd()

  pi.FileName <- exec

  let p = new Process()

  p.StartInfo <- pi  p

let (^>) (out:Process) (pf: bool -> string -> unit) =

  out.ErrorDataReceived.Add(fun d -> pf false d.Data)

  out.OutputDataReceived.Add(fun d -> pf true d.Data)

  out.Start()

  out.BeginErrorReadLine()

  out.BeginOutputReadLine()

  out

let (^|) (inp:Process) (out:Process) =

  inp.EnableRaisingEvents <- true

  inp.ErrorDataReceived.Add(fun d -> out.StandardInput.WriteLine d.Data)

  inp.OutputDataReceived.Add(fun d -> out.StandardInput.WriteLine d.Data)

  inp.Exited.Add(fun _ -> out.StandardInput.Close())

  inp.Start()

  inp.BeginErrorReadLine()

  inp.BeginOutputReadLine()

  inp

let p = createProcess @"c:\Windows\System32\Robocopy.exe" "/?"

let s = createProcess @"c:\Windows\System32\sort.exe" ""

let q = createProcess @"c:\Windows\System32\sort.exe" "/R"

p ^| q ^| s ^> (fun out d -> printfn "%s: %s" (if out then "out" else "err") d)

s.WaitForExit()

This code shows a limit of .NET API, we have to coordinate the piping process explicitly because we cannot specify the handle to the streams in the ProcessStartInfo structure (in Win32 would be possible). We define two overloaded operators using the ^ prefix to have right association. The callbacks provided by the Process class allow to avoid polling of streams. This code has requested an amount of spelunking of System.IO namespace, I was surprised to find that using the general Stream class it is not possible to multiplex IO operations as the select system call would have permitted. Some day I will post considerations about this design that at a first sight may seem weird but after some thoughts I decided that is reasonable though far from elegant.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: ,

General | Shell

Minor VSLab release

by cisterni 14. September 2008 17:23

If you are using VSLab maybe you are interesting into a minor upgrade released yesterday. I fixed a minor bug on the 3D function viewer which on ATI cards wasn't working (hope this will not compromise the others :) and changed a couple of minor (but annoying) things.

First of all I've make more robust the invocation of ExecuteCommand method on the DTE object, sometimes an exception was raised, especially at VSLab startup, complaining about RPC server busy. Usually this happens whenever VS is loading and the COM infrastructure is stressed. Now VSLab addin performs a number of retrials before giving up, and the situation seems to be better.

The second change is due to the fact that VSLab register a command in the VS context menu which causes the addin loading when you right click on a text editor for the first time. Since when you are developing C# is rather annoying to have VSLab starting but there is no way to block this (unless commands are deleted at every quit of VSLab). So now the addin does almost nothing during load and everything else is demanded to the command executed when you press Alt+Shift+V key combination. We hope in this way VS is less intrusive, though this decision may be subject to changes if Viewlets are used to quickly extend Visual Studio using F#, in this case we will change startup once again.

Now we are updating the documentation, and in particular the visual tutorial, though it is a little bit more difficult than before since of the big changes in the internals. We plan to release the new documentation by the end of this week.

 

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

General

VSLab Viewlets and lightweight controls

by cisterni 10. September 2008 21:13

Back to normal work, still fixes to do for the CTP update rush, but I'm finally able to restart the work I stopped to update the code base. A major update that is available in the current release of VSLab though not entirely defined is the support for lightweight controls. The inner working of VSLab requires (have a look to the white paper discussing the implementation) the use of Windows Form instead than WPF for developing viewlets. I hope to circumvent this limitation some day, but this is the current situation. Moreover you cannot aggregate user controls when developing viewlets, again for core reasons (essentially VSLab runs in the F# interactive process and draws in toolwindows owned by the VS process). This is the reason for implementing lightweight controls for Windows Forms: this kind of controls are available on other systems such as Java AWT and offer a mean to have logical controls without having to pay for GUI window peers.

The ViewletControls project contains the panel responsible for implementing the lightweight controls abstractions, still under definiton and debugging. The Viewlet class already inherits from this container nonetheless. We are defining basic controls to ease the implementation of viewlets, though we believe that drawing should remain the core of viewlet development since the composition is obtained through the toolwindows in Visual Studio and dialogs can be opened directly from F# without having to fill the viewlet area with controls.

Another feature recently introduced for viewlets is the Windows caret support. It is now possible to display the Windows caret at (x, y) to have input directly in the viewlet toolwindow without having to resort to textboxes.

I love this part, reimplement controls is always a good opportunity to remember the good old days.

The lightweight controls also will include a timer to express animations easily using yield expressions (continuations) using a single timer. The library has been designed after another library designed for Web applications and recalls features available in the WPF framework. Future posts will discuss with examples the usage and the implementation of this library.

 

Currently rated 5.0 by 2 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,

Design | General

VSLab, F# and subnotebook

by cisterni 8. September 2008 16:18

I just installed VS Shell, F# and VSLab R2D2 on my brand new Acer Aspire One sub notebook. I have the 8Gb HD SSD version (featuring Atom processor and 512Mb RAM) so I was curious to see if I can use it for development on the way. I am impressed, really, because I've been able to run VSLab on it and it works great, including 3D graphics as witnessed by the following snapshot: 

The only drawback is that disk writes are very slow, but this really matters during installations. I think that VS Shell and F# teams did a very great job. This makes VSLab great for laboratory and scientific computing.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Applications | General

VSLab R2D2 released

by cisterni 8. September 2008 01:45

Ok, I finally managed to get VSLab working again with the new F# CTP. Thanks to the really improved project system I've been able to get rid of several hacks that taunted my dreams. I expect bugs and improvements to do in the near future. The VSLab API has not been changed so Viewlet should work without changes.

I have to update the documentation, changes have been few, but relevant since VSLab now uses F# interactive toolwindow. To start VSLab use Shift+Alt+V after installation.

 

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Community | General

September CTP and VSLab again

by cisterni 7. September 2008 12:12

As discussed in the previous post we are working to get VSLab back on the September CTP because the VS project system has completely changed. The core mechanism used to build Viewlets do not depend on this integration, they rather rely on deeper mechanisms available on Windows. The only feature the VSLab addin used of the project system was the ability to send F# code to the F# interactive toolwindow. In the former implementation F# interactive was essentially a user control, now the system provides support for F# as a VS package, thus the toolwindow has a completely different implementation.

Although I'm talking with the F# product team I continued to look for a hack to quickly update VSLab because many people have downloaded it and I know how hateful is when a tool ceases working. Yesterday evening mostly by accident I found the solution that I quickly describe here to those interested in sending F# code to fsi.exe from VS addins. The first step is to obtain a reference to DTE2 object available from the VS automation model and here referred as appObj.

To show the F# interactive toolwindow you can simply trigger the menu command as follows:

appObj.ExecuteCommand("View.F#Interactive", "") 

The toolwindow should be loaded before you can get a reference to it: 

let tw = (appObj.ToolWindows).GetToolWindow("F# Interactive") :?> Microsoft.FSharp.VisualStudio.Session.FsiToolWindow

It is interesting to have a look to the cast, the object you are getting from GetToolWindow is not a COM wrapper but the .NET object of a type defined in the FSharp.VS.FSI.dll assembly. Now after a little bit of use of Reflector I found that the method I was interested in was executeNoHistory@182 that is clearly an inner function object and cannot be invoked directly. While I'm waiting for a public method I resorted to reflection to invoke it:

let mi = (tw.GetType()).GetMethod("executeTextNoHistory@182")

mi.Invoke(tw, [| ("2+2;;" :> obj) |]) |> ignore

And this is the only true dependency VSLab has from the F# VS integration. Now I'm working to port project templates, but these are minor things. Hope to release the new version VSLab by wednesday.

 

Currently rated 1.5 by 2 people

  • Currently 1.5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Design | General

F# September CTP and VSLab

by cisterni 6. September 2008 15:52

Hello everybody,

 while I was in holydays I received an e-mail from F# team that VSLab was not working with the new CTP of F#. I tried to recompile it for this new release finding that the VS integration has been redesigned and now I'm trying to figure out which way to go. The core of VSLab works perfectly, the only problem is that I used to send commands to F# interactive from VSLab addin and now this is not possible using the previous interface. I'm trying to figure out how this can be overcome, and at the same time I'm collaborating with the F# team in Redmond which has been really great in supporting me. Stay tuned, new information will be available ASAP.

-- Antonio

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Design | General

VSLab Shell

by cisterni 27. July 2008 17:26

I think that one of the most interesting areas of VSLab, partly unforeseen, is the project of developing a next generation system shell as a package. System shells have a long history and there is always an attempt to find the new one, but I think these are here to stay, but they also are the past. We are living in a world where the stream-based composition of software is far from satisfactory, and also the completion forms provided by shells are inadequate.

In 2001 I defined a shell called ObjShell, attempting to exploit the component-based nature of COM for software composition. At that time I realized that Unix shells are just a simpler version of this where each program was a component with a well defined interface and an associated process, and the shell was the mean by which these components were integrated. ObjShell were a very nice project and today I can say it's a pity I didn't find the time to work on it for the .NET version, otherwise the Power Shell would have arrived several years before. And in fact I was contacted by the PS team (I spoke to Jeffrey Snover when He was in charge of PS) though I didn't succeded in trying to convince on some basic design principles of the ObjShell that I would have loved to see in the PS. I'm not a PS fan, I like the object streaming metaphor, but I didn't feel need for another unreadable language full of switches and dollars.

I think that programming languages and the associated toolchain have grown enough to blur the distinction between the program and the shell, it was true for VB and COM and it is more true nowadays with .NET and languages such as F# using the interactive top level. Now with few lines you can read system counters as PerfMon does and do several other things. VSLab Shell will be a package designed to be next generation shell, where statements are highlighted to be executed and a single file may contain several scripts. Intellisense it is far better than Tab-based completion. At the moment we are working on the core functionalities of the shell, but also designing interfaces to hardware such as ILO featured by HP.

More about VSLab Shell will be available in the next release of VSLab.

Currently rated 2.3 by 7 people

  • Currently 2.285714/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: ,

Design | Shell

Powered by BlogEngine.NET 1.4.0.0
Theme by Mads Kristensen

VSLab blog

VSLab is a Visual Studio extension designed to support Visual Studio interaction from F# interactive. It is a Microsoft product developed at University of Pisa, by a team lead by Antonio Cisternino.

Resources

Recent comments

Comment RSS

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in  anyway.

© Copyright 2008