New cmdlets implemented: Import-Csv, Export-Csv, ConvertTo-Html
Improved the PSObject implementation a nice amount. PSObject now implements all public methods that the PowerShell one does (except for IFormatable, but I am working on this).
Improved WildcardPattern, FileSystemProvider, Format-List, LanguagePrimatives.
These changes will be merged with the BZR branch on http://www.launchpad.net/pash later today. I still have some more kinks to work out.
Tuesday, August 12, 2008
Thursday, August 7, 2008
PSObject & Grammar
So our PSObject can use some work, and Format/Out cmdlets really depend on a good PSObject. Hmm sounds like a direction to head in. Next I am going to work on PSObject.
We need external help for the parser in Pash. So if anyone of my tens and tens of vistors are experts in automata theory or some such, you would be very helpful to us!
We need external help for the parser in Pash. So if anyone of my tens and tens of vistors are experts in automata theory or some such, you would be very helpful to us!
Friday, August 1, 2008
The logic of formatting
Since PowerShell (and Pash) deals with objects being passed along a pipeline instead of text streams, it becomes clear to some people that reporting this data requires some extra step. PowerShell takes an 'interesting' approach to this problem, using a combination of two cmdlet groups, Format-* and Out-*
My work right now is on Out-*
Interesting huh?
My work right now is on Out-*
Interesting huh?
Friday, July 25, 2008
Format-* is hard
One of the hardest cmdlets to write for Pash thus far has been the various Format-* cmdlets. Fortunately Joel "Jaykul" Bennett who is some kind of PowerShell nut (no really, this guy is the master of PowerShell), has been helping me with the esoteric details of it's engineering (or as some would say, overengineering). So Format-* should be pretty usuable soon. Hopefully/maybe. :)
Tuesday, July 15, 2008
CompatabilityAssert
So I rewrote my custom Assert to use a stack of "drivers" for each "shell" (ie, only Pash and PowerShell). Given a set of shells, the Assert will execute a given script on each of the shells, retrieve the resulting objects, compare them against each other, and fail if they do not equal.
Got some kinks left to work out.
Got some kinks left to work out.
Unit testing
So for the testing framework, I will be building ontop of NUnit, an excellent "unit testing" framework.
Summary for the insulated:
Unit tests are basically automated tests which are designed to test individual "units" of an application. This is usually by declaring something called an "Assertion", basically a statement that says these and these conditions should always occur under these and these circumstances.
NUnit comes with many Assertions, but I don't think any are suitable for all of the kind of testing we are doing - fortunately NUnit can be extended with custom assertions, and that is what I am writing - a "Compatibility" assertion, which will take at least one string of PowerShell script, execute said script on any number of PowerShell (and Pash hosts), get the result (typically a collection of PSObjects) - take those results and compare the data stored within the objects with one another and ensure they are equal. If they are equal, the assertion is passed, if they are not the assertion fails (and typically the whole unit test fails).
This test will only run on Windows (since PowerShell runs on Windows), but the plan is to force the collection of unit tests to run when you want to create Release build of Pash. Should one fail, well, you are SOL. :)
Just one of the ways me and Igor are ensuring that we aren't making a competing shell, but that Pash will fundamentally be a cross platform implementation of PowerShell, and that most PowerShell scripts shall run on it without modification.
Summary for the insulated:
Unit tests are basically automated tests which are designed to test individual "units" of an application. This is usually by declaring something called an "Assertion", basically a statement that says these and these conditions should always occur under these and these circumstances.
NUnit comes with many Assertions, but I don't think any are suitable for all of the kind of testing we are doing - fortunately NUnit can be extended with custom assertions, and that is what I am writing - a "Compatibility" assertion, which will take at least one string of PowerShell script, execute said script on any number of PowerShell (and Pash hosts), get the result (typically a collection of PSObjects) - take those results and compare the data stored within the objects with one another and ensure they are equal. If they are equal, the assertion is passed, if they are not the assertion fails (and typically the whole unit test fails).
This test will only run on Windows (since PowerShell runs on Windows), but the plan is to force the collection of unit tests to run when you want to create Release build of Pash. Should one fail, well, you are SOL. :)
Just one of the ways me and Igor are ensuring that we aren't making a competing shell, but that Pash will fundamentally be a cross platform implementation of PowerShell, and that most PowerShell scripts shall run on it without modification.
Monday, July 7, 2008
New project: Pash test framework
My mentor Igor told me that I should work on a test framework for Pash, and that is what my current work is right now. The idea is to have an easy and simple way to test compatibility between PowerShell and Pash. The test framework uses the PowerShell hosting API, and a custom Assert, AssertCompatability. Given a script string, the framework should be able to test it and retreieve the results on any number of implementations. It then compares the results and makes sure they are equal. If they are not, it fails.
URL:
https://blueprints.launchpad.net/pash/+spec/pash-test-framework
URL:
https://blueprints.launchpad.net/pash/+spec/pash-test-framework
Subscribe to:
Posts (Atom)