Site Sections
Posts
49
Comments
83
Trackbacks
0
October 2005 Entries
Wonky Monad syntax #2: Calling functions
Take the following script: 
function tester($foo, $bar) {     $foo;     “Bar:” + $bar.Name   }
$f =  [System.Net.Sockets.TcpListener]80
$b = get-process msh tester $f
$b
“Wonky call:”
tester($f,$b)
Both the last two lines of the script are valid (as in, the parser does not throw an error), but give completely different results: 
Server                            LocalEndpoint
------                            -------------
System.Net.Sockets.Socket         0.0.0.0:80
Bar: msh

Wonky call:
System.Net.Sockets.Socket         0.0.0.0:80
The second invocation does not result in displaying $bar.Name. Maybe there’s some secret use of func() syntax (which would explain why the parser does not throw an error) that I’m missing here (actually, what’s happening is that the function gets the entire contents of the paren as a list). To be really symmetric with other languages, Monad should really switch func arg1 arg2 and func(arg1,arg2) as the latter is commonly known. Though one reason for not doing it is for dynamic creation and execution of functions, in which case it might be slightly easier to call functions if you don’t have to bother with parens. The real reason is likely that the current behaviour brings consistency with how cmdlets are treated (and scritps), after all you don’t call a cmdlet like this: some-cmdlet(param1,param2). In the end the current Monad solution makes sense if you look at the big picture, but you need to realize the difference between using parens and not. Otherwise you might run into some hair pulling sessions with your script. Oh btw, you can see wonky behavior #1 as part of this script as well. So, like I’ve been telling folks on the Exchange team who are busy writing scripts for demos and testing, make sure you check your syntax before you file a bug :) .
posted @ Wednesday, October 26, 2005 12:10 PM | Feedback (0)
Documenting wonky Monad (and Exchange) behaviour
I’ve been keeping a personal list of “gotcha!” behaviors that I’ve seen while using Monad. I figured I’d publish these so they don’t trip up other users. When Exchange 12 ships (or a beta is available) I’ll do the same thing for our features. No matter how hard we try, there is always some compromise that needs to be made, and unfortunately sometimes the resulting behavior is confusing. A classic example is the Anonymous Allowed GUI tab in Exchange 2003 (yes I am partially to blame for that one). So here’s the first one to kick things off. If you write two or more commands in a script and run the script: get-childitem get-process You’ll notice that the first one returns the pretty default table format (if defined), but all the other following commands default to format-list! 
    Directory: FileSystem::H:viveksha

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---         9/21/2005  12:48 PM        764 consolesettings.reg

ProcessName : csrss
Id          : 3024
 
This is definately confusing and wonky. To fix this, you have to be explicit and add a formatting instruction like format-list, format-table or out-default to the cmdlets you execute in a script for display: get-childitem get-process | format-table This is by design as far as I know as apparently the format cannot be changed mid-stream (according to Monad team). An Exchange tester ran into this while running scripts.
posted @ Tuesday, October 25, 2005 12:10 PM | Feedback (0)
Vmake.msh and format-source.msh: Making it easier to write snippets in C# using Monad

When I want to write a snippet (let’s say with 3-4 source files and maybe a lib reference), I don’t really want to go and create a project in Visual Studio… not because its not easy, but because opening up VS for some reason feels like I’m embarking on a serious project. And that’s not bad… after all, Visual Studio is really an enterprise and professional interface. For the minor snippets, its really easy to call csc directly and compile some files. But you then miss out on some features of an IDE… So I rolled some scripts to help me write quick snippets (actually these work for large projects too!).

 Format-Source uses begin{} process{} end {} clauses to implement the classic cmdlet behaviour in script (allows pipelining etc). Vmake is pretty simple, it runs csc and parses the output to indicate at what line and character you made your mistake. The improvement over plain vanilla csc.exe is:

  • Gives you the line where you ran into your error (using format-source)
  • Gives you the character where the compiler caught an error and colors it red
  • Makes it somewhat easier to specify a quick snippet to compile: vmake new.csv,hello.cs somelibtoref.dll. The previous line will create an exe called new.exe and reference somelibtoref from the current path.

Usual caveats: if you specify a file that does not exist, the script will blow up. I haven’t bothered to fix that as its easy to run the cmdline again. Also, I only added csc.exe parameters for the values that are worthwhile for small projects, you can change these to your liking of course. Get them here: format-source.msh and vmake.msh.

posted @ Wednesday, October 05, 2005 12:10 PM | Feedback (0)
News
A little slow these days as I'm busy working on exchangelabs.com. I will try and post tidbits when I get some time. Enjoy the older posts till then!
Archives
Post Categories
Image Galleries