MrEpl is a REPL processor for the MSchema language and is a great way to play around with M and learn about it.

I have recorded a screen cast of some adventuring through MrEpl and it is posted on the Oslo dev center here: http://wm.microsoft.com/ms/msdn/oslo/MrEplWalkthrough.wmv

For those who just want to play, make sure you have the Oslo SDK installed, then run “Intellipad (With Samples)”.

- Once in Intellipad type “Ctrl-/” to get to the minibuffer.

- There type "SetMode(‘MScriptMode’)”

You’re now in MrEpl. Feel free to type an M expression: 1 + 1

Have Fun!

MGrammar is great for tying in with MSchema, and you can write custom IGraphBuilder implementations for all kinds of things, but in the end most of the code I am writing is still C# and needs instances as input.

Enter Xaml, a wonderful format for writing down arbitrary .Net objects (well many of them anyway). And, it turns out that the MGraph data rep is reasonably friendly to a Xaml projection. So, now posted as a sample on the Oslo dev center is some code I wrote to enable targeting Xaml with MGrammar output.

Get the bits here: [updated link on 11/28, apparently the bits moved]http://download.microsoft.com/download/B/9/8/B982BFD9-3E17-426A-A537-833BEF376698/MGrammarXamlSample.msi

And after that go watch a couple of screen casts that I recorded about using the sample.

First: a very simple example of instantiating a Person object from MGrammar output: http://wm.microsoft.com/ms/msdn/oslo/PersonExample.wmv

This example takes a simple grammar and some input, creates a graph and then runs it through the MGraphXamlReader to create instances of the type Person (see below) which I defined in C#.

public class Person
{
    List<Person> children = new List<Person>();

    public string First { get; set; }
    public string Last { get; set; }
    public ICollection<Person> Children { get { return children; } }

}

A more complex example of a grammar for writing down WPF applications in an English like syntax:

http://wm.microsoft.com/ms/msdn/oslo/mwindowexample.wmv

You can check out a bunch of interesting content about the Oslo product on MSDN at http://msdn.microsoft.com/oslo. Or, just hang around here as I’m sure to post entries now that things are public about my adventures in this new family of languages and their uses.

http://www.douglasp.com/blog/2007/11/15/MyTeamIsHiring.aspx

Interested in kick ass technology with crazy smart people? Email Doug (douglasp@microsoft.com).

Patrick is super-smart... Hopefullly his blog will pick up where Chris Brumme's left off a couple years back.

 -josh

- pet projects related to the product (in this case CLR) which they are prototyping in the hope of getting some traction in the problem space

- pet projects related to the engineering effort around the product (e.g. static analysis, etc...)

- tools related to software engineering in general (much of my stuff falls into this category)

- random stuff using managed code just to use manage code (eating your own dog food is good right? especially when it tastes this good)

Many of the tools that we use to build and test the CLR started this way, two public examples being PerfConsole and MDBG. Both of these were started as pet projects and have become an integral part of CLR processes (admittedly MDBG significantly more so than PerfConsole at the moment, MDBG being the CLR's primary managed debugging test harness).

Anecdotally I believe that there are lots of people inside Microsoft doing this as well, internally we have a system for sharing tools you've written that help you get things done and last time I checked it had 4500+ tools on it, and that's just the stuff that people bother to publish.

I strongly believe that pet projects should be encouraged within any software development team. I'm glad that my experience with Microsoft has been that they do encourage experimentation, after all where do you think the CLR came from?

As we have seen in the previous entry it is nice that the VSTS Profiler team has provided a tool which converts their .VSP files into something which is more easily readable by other programs. While I was working on CLR oerformance last year I spent a lot of time playing with the output of the VSTS Profiler before the UI pieces were ready, so I spent a lot of time using the data in the .CSV files to diagnose problems. After just a short amount of time doing this by hand I decided to go ahead and automate the process, I created a number of utilities to parse the output CSV files and find some interesting information. In that first rev you basically ha d to run the application anytime you wanted to change the inputs to the query (different string, different cutoffs for various things, etc.). It didn't take too long to realize that this wasn't going to scale, and PerfConsole was born...

What we can see above are some of the basics of PerfConsole's command syntax; overall it strives to mix some of the console module that cmd.exe or Windows PowerShell has with what is more or less a domain specifica language for interpreting profile data. There are a number of commands which are included in the base package which include the following which we can see above:

- load: loads a profile from disk, commonly you specify a .VSP file and PerfConsole will look for the (required) associated .CSV files which were generated either from the "export" function in VS or using the command line as outlined here.

- functions: takes a profile as input and returns the piece that corresponds to a list of functions which were seen in the profile with Inclusive and Exclusive times.

- modules: takes a profile as input and returns the piece that contains a list of modules which were seen in the profile with Inclusive and Exclusive times.

- sort: takes in a list and returns a sorted list ordered by some property (in this case "ex" is shorthand for "ExclusivePercentage")

- top: takes in a list and returns a subset of that list including X elements starting at element 0

Through the example above we can start to see the basic syntax of using PerfConsole: you use the '|' to connect statements where each statement (reading left to right) has input from the return value of the previous statement and the parameters specified. Like Windows PowerShell when things are passed from left to right they are full fledged .Net objects, and PerfConsole can use those objects to do some type checking as you go in order to tell you if you're combining commands in unsupported ways.

Incidentally I initially tried really hard to reverse the execution order and instead execute from right to left, it made for statements that read like a sentance "top 5 | sort ex | functions @board_ngen" == "get me the top 5 exclusive functions in @board_ngen"; however the people internally revolted and said that if that is what I wanted I couldn't overload '|' to do it.

As a side effect (or design point) of the way that PerfConsole passes objects between statements I have been able to implement a very powerful help system, for instance at any point you're able to pipe the result of any statement or set of statements to '?' and it will tell you the resulting data type and which commands will accept that type as a input (in a strongly typed manner). For instance:

> functions @board_ngen | ?
Data type is: PerfConsole.Data.FunctionSummaryData

This data type can be input to the following commands:

bottom
count
find
getitem
getproperty
sort
top
trim
timebytype
partition

Here we see that the functions command returns a FunctionSummaryData object which can be input to a number of other commands, including the top and sort commands. Here we also see that functions has this wierd "@board_ngen" parameter, in PerfConsole @ denotes a temporary (you can create these using the save command), and the temporary named "board_ngen" is the profile that I've imported for this demo.

Help also works well with commands. For instance:

> ? sort
Sort a ISortable (e.g. FunctionSummary, ModuleSummary). Each type has its own
sort types (e.g. 'name', 'address', 'exclusive', etc...).

Usage:
ISortable | sort <field:SortField> | ISortable
ISortable | sort <field:SortField> <direction:SortDirection> | ISortable

Have enum paramters:
SortDirection { Ascending, Descending }
SortField { Name, ExclusivePercentage, InclusivePercentage, Address }

Here we can see that we are able to see that the sort command takes as input something which implements ISortable (which by inference from the previous help output we believe that FunctionSummaryData does), it also can take up to two parameters which are values of the enum SortField and SortDirection (these are allowed to be shortened arbitrarially so long as they remain disabiguated from their peers). As a return value sort specifies that it returns an ISortable, if we pipe the return value from sort to the help we see:

> functions @board_ngen | sort ex | ?
Data type is: PerfConsole.Data.FunctionSummaryData

This indicates that sort actually returns a FunctionSummaryData (which implements ISortable), behind the scenes the sort command clones the original FunctionSummaryData and returns the modified copy.

Note that for simplicity's sake I've used PerfConsole with the /console command line option which causes results to show in the console, the default is to show results as HTML which you can click around to do more queries and such, in fact, before I end this blog entry which has already managed to get too long I'll show you Rico's favorite command:

> calltree @board_ngen | trim in > 5 | compacttree

Anyway, that's a primer on using PerfConsole, please download it here. When you start it up, the ?? command will open a longer document which should hopefully get you started quickly.

If you have VSTS and want to learn more about the profiler see the team's blog: http://blogs.msdn.com/profiler/

VSTS Profiler has many options and through those can get at a lot of data about your application, however I usually find that some of the most interesting can be obtained with simple vanilla sample based profiling. You can do this through the VS interface, or from the command line using the VSTS Profiler command line utilities, basically the steps are as follows:

1) Only if profiling managed code: vsPerfClrEnv.cmd /sampleOn 

2) vsPerfCmd.exe /start:sample /output:<name>.VSP

3) vsPerfCmd.exe /launch:<application>.exe

    <<wait for application to close>>

4) vsPerfCmd.exe /shutdown

By following those 4 steps you can profile an application, the result is a .VSP file named <name>.VSP. This contains all the profile data collected during the run. This file is readable directly by VSTS. There are however interesting analysis to do on the data that the VSTS 2005 interface doesn't have support for, to address this issue the VSTS Profiler team has included a utility called vsPerfReport.exe which can translate a .VSP file into a set of comma seperated value (CSV) files, one for each of the major views seen in VSTS. In order to do this you execute:

5) vsPerfReport.exe /summary:all <name>.VSP

at the end of all this you will have a set of files named <name>_<type>.CSV which are views into the data in the VSP, you can open these in Notepad to view the text or import them into Excel to see the columns more clearly called out.

Once the data is in this form we can do whatever we like with it, for instance sorting by a particular column in Excel or searching for a particular row using a string in Notepad. However, wouldn't it be interesting to be able to do more?

Stay tuned...

http://msdn.microsoft.com/vstudio/products/trial/

This is AWESOME because VSTS has a great profiler included in the package!

>>>>>>> snip >>>>>>>>>>>>>>>>>