Re: [IronPython] Decorators on classes
Keith J. Farmer wrote: Py3k has ASTs, right? .. if the ASTs were mapped to System.Linq.Expressions wherever possible, that would be a great start. Even better if we got complaints if trying to cast an expression that couldn't be cast to the CLR nodes. Well - Python has had ASTs from the start through the compiler package: http://docs.python.org/lib/compiler.html The compiler contains libraries to generate an abstract syntax tree from Python source code and to generate Python bytecode from the tree. This is only available in FePy and not straight IronPython. Additionally, there's a super-secret _ast module in Python 2.5. Documented in the dev docs for 2.6 http://docs.python.org/dev/library/_ast.html The compiler package *is* being replaced in Python 3, but I don't know the details and a quick googling didn't reveal anything. Not sure how this helps with LINQ though as I don't believe that Python 3 ASTs will allow you to modify the grammar - so it could only help if you pass in your queries as strings? (Which is problematic as they need access to the enclosing namespace of course.) Michael http://www.manning.com/foord From: [EMAIL PROTECTED] on behalf of Michael Foord Sent: Mon 2/4/2008 4:09 PM To: Discussion of IronPython Subject: Re: [IronPython] Decorators on classes Dino Viehland wrote: from future import clr_hacks sounds like the start of an awfully slippery slope. lol :-) Although I do recall suggesting a while back that it might be impossible to avoid incompatible syntax if we are to have full LINQ support in IronPython, and that a future import would be one way to go... Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Monday, February 04, 2008 2:54 PM To: Discussion of IronPython Subject: Re: [IronPython] Decorators on classes On Feb 4, 2008 2:27 PM, Dino Viehland [EMAIL PROTECTED] wrote: As other people have pointed out decorators are a runtime concept and I don't think we get to change that. So consider a class decorator You could theoretically have a slightly alternate parsing mode that recognizes a specific class decorator name before the class definition is closed (and therefore before codegen). In other words, the following definition @ClrAttribute(System.SerializableAttribute) class X(ISomething, object): treats the decorator differently if it matches one of the special-case names. The change in parsing could be triggered by something like from future import clr_hacks. On Feb 4, 2008 2:32 PM, Keith J. Farmer [EMAIL PROTECTED] wrote: CPythonista outrage over not being able to read something they could never run is rather silly. :) You're clearly having trouble envisioning the following Slashdot headline: Microsoft inflicts 'embrace and extend' on Python. Silly or not, perceptions are hugely important. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Decorators on classes
In our project 98% of attributes are on class definition and properties. The 2% left are field attributes, [field: NonSerialized()], on user defined events. On Feb 5, 2008 1:07 AM, Keith J. Farmer [EMAIL PROTECTED] wrote: My personal experience says that the most prevalent use of attributes in .NET *is* on methods and properties, as part of the original class definition. Consider: LINQ to SQL: http://msdn2.microsoft.com/en-us/library/bb386971.aspx WCF: http://linqinaction.net/blogs/jwooley/archive/2007/05/14/wcf-with-the-linq-to-sql-designer.aspx XML Serialization: http://www.devhood.com/Tutorials/tutorial_details.aspx?tutorial_id=236 It is rather ugly. :-) Thanks; I thought so myself. Would this technique have anything to offer for attributes on methods and properties (etc). It's hard to see how, but it's been a while since I looked at that part of the source. I'm pretty sure that the CLR class itself needs to be emitted entirely by the contents of the one class statement -- and well before the first method is defined. Which means that none of the properties or methods of the class could influence codegen. Frankly, I don't think that attributes on methods or properties are realistic -- at least, not as part of the original class definition. What I think you'd be looking at is the ability to define a class wrapper that wraps the initially-defined dynamic class with a new statically-defined class that allows you to put attributes on methods and properties. Hmm... where have I heard that recently... :) ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
Would it be hugely tricky to get it working in IP 1.1 as well as 2.0, do you think? I'm imagining some kind of --target:1.1 flag to the tool. Michael Foord wrote: Curt Hagenlocher wrote: On Feb 4, 2008 11:07 AM, Michael Foord [EMAIL PROTECTED] wrote: Curt Hagenlocher wrote: The assemblies call into the IronPython engine (version 2) to load and execute the script. Currently, the script is loaded from the file system, but I'd eventually like to support embedding any required scripts as resources in the assembly, so that the whole thing can be distributed as a single neat package. Great - you beat me to it. :-) If you make this open source then I'll be happy to help on it. I'm thinking of putting it on Codeplex. Be warned that I prefer ILGenerator to CodeDOM, probably because I'm reliving the glory years of assembly language programming. 6502 4eva! :) Ouch. :-) Although in my case it was 68000 forever (truly beautiful CPU - based appreciated inside an Amiga). I'd love to learn more about generating IL - although it does make the learning curve steeper (I have tinkered but nothing more). The current implementation is written in Python. I would recommend leaving it in Python unless you have compelling reasons to rewrite... I'm sure you will - but when you get it up on CodeDOM post an announcement here so that I can blog about it. This is great news as it fills one 'missing piece of the puzzle' when it comes to integrating IronPython with other .NET languages. Michael -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 Try out Resolver One! http://www.resolversystems.com/get-it/ (Free registration required) 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
Curt, This is a great feature and was one of the first features that I investigated when I first got my hands on IP. I see an immediate need for this feature in using data binding with Windows Forms controls. Many controls (such as DataGridView and ListView) reflect over the properties of bound objects in order to display this data dynamically with no programmer setup. Because IP types are dynamic, WinForms cannot find any properties to bind and creates an empty object. In order to use these features now, I must create static interfaces with the required properties in a separate assembly and then inherit that interface whenever I bind to business objects. To make using these UI controls easier, it would be great if property statements could be turned into static properties either automatically or via a flag. It seems that IP already matches properties to the correct static getter/setter as defined in the interfaces so this should be a reasonable request. This staticization would remove the need for the separate static interface. Another situation in which this would be really helpful--although less critical--involves situations where I want to use a static tool on an IP assembly (for example, I want to use NUnit to test my IP classes). I say that this is not critical as a lot of tools already have Python-specific versions available--PyUnit is a good example. Finally, would there be a way to simplify programmer work by providing standard static creators that are turned on and off at a high level? For example, programmers could use a compiler switch to turn all functions into void func(object, . . .) and object func(obj. . . ). I see this being useful in situations such as using NUnit because all that is really needed is the proper number of arguments and the right function name (all of which are already known in Python). If things then work the way that I think they work, you could then just pass the objects into the correct comparators, and if they are the right type, then the tests will run. Otherwise, you'll get an exception. Hope that helps, Rocco From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Monday, February 04, 2008 1:31 PM To: Discussion of IronPython Subject: [IronPython] Exporting Python code as an assembly After a bit of spare-time hacking this weekend, I've got a proof-of-concept program that takes a Python class and exports it as a (statically-defined) assembly. It uses Pythonic function annotations to signal attributes and input and output types to the wrapper generator. You end up with something like this def Test(object): @ClrAttribute(Xunit.FactAttribute) def WorthlessTest(self): Xunit.Assert.Equal[type(1)](1, 1) @ClrAccepts(System.String, System.Int32) @ClrReturns(System.Int32) def CalculateValue(self, s, i): return len(s) + i The program takes this source and spits out a DLL containing the class Test which implements WorthlessTest and CalculateValue. The class itself contains a reference to the actual Python object, and each of the public functions simply delegates to the Pythonic implementation. I'm still working on cleaning up the source a little before releasing it, but was wondering if anyone had some feedback on the design as described so far. What should be changed or implemented in order for this to be more useful to you? Thanks, -Curt -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
On Feb 5, 2008 5:50 AM, Giles Thomas [EMAIL PROTECTED] wrote: Would it be hugely tricky to get it working in IP 1.1 as well as 2.0, do you think? I'm imagining some kind of --target:1.1 flag to the tool. I can't imagine that this would be a problem. It's been a while since I played with the hosting-level interfaces of 1.1, but I seem to recall that (at the level in question) they're largely isomorphic with what's currently in 2.0. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
On Feb 5, 2008 9:15 AM, Pigneri, Rocco [EMAIL PROTECTED] wrote: To make using these UI controls easier, it would be great if property statements could be turned into static properties either automatically or via a flag. Yes, one of the thoughts I had was that you should be able to run such a tool in a greedy mode (which tries to wrap everything) and a precision mode (which only wraps what you tell it to). -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
Curt Hagenlocher wrote: I can't imagine that this would be a problem. It's been a while since I played with the hosting-level interfaces of 1.1, but I seem to recall that (at the level in question) they're largely isomorphic with what's currently in 2.0. Excellent - that's what I thought. I'd love to add that once it's online. Cheers, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 Try out Resolver One! http://www.resolversystems.com/get-it/ (Free registration required) 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Decorators on classes
I am only an egg. The basic requirement for IQueryable (and, by extension as it were, the interesting variations of LINQ providers) is that the compiler be able to emit a series of calls to build expressions. I only imagine (read: I haven't studied Python's AST offerings) that *for the most part* it should be a fairly straightforward mapping of a subset to the new Expressions namespace. Enough that probably a fairly simple visitor could transform from one to the other. Using dotted notation for the query operators themselves is okay. Creating new Expression trees is a PITA without help. From: [EMAIL PROTECTED] on behalf of Fuzzyman Sent: Tue 2/5/2008 3:12 AM To: Discussion of IronPython Subject: Re: [IronPython] Decorators on classes Keith J. Farmer wrote: Py3k has ASTs, right? .. if the ASTs were mapped to System.Linq.Expressions wherever possible, that would be a great start. Even better if we got complaints if trying to cast an expression that couldn't be cast to the CLR nodes. Well - Python has had ASTs from the start through the compiler package: http://docs.python.org/lib/compiler.html The compiler contains libraries to generate an abstract syntax tree from Python source code and to generate Python bytecode from the tree. This is only available in FePy and not straight IronPython. Additionally, there's a super-secret _ast module in Python 2.5. Documented in the dev docs for 2.6 http://docs.python.org/dev/library/_ast.html The compiler package *is* being replaced in Python 3, but I don't know the details and a quick googling didn't reveal anything. Not sure how this helps with LINQ though as I don't believe that Python 3 ASTs will allow you to modify the grammar - so it could only help if you pass in your queries as strings? (Which is problematic as they need access to the enclosing namespace of course.) Michael http://www.manning.com/foord From: [EMAIL PROTECTED] on behalf of Michael Foord Sent: Mon 2/4/2008 4:09 PM To: Discussion of IronPython Subject: Re: [IronPython] Decorators on classes Dino Viehland wrote: from future import clr_hacks sounds like the start of an awfully slippery slope. lol :-) Although I do recall suggesting a while back that it might be impossible to avoid incompatible syntax if we are to have full LINQ support in IronPython, and that a future import would be one way to go... Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Monday, February 04, 2008 2:54 PM To: Discussion of IronPython Subject: Re: [IronPython] Decorators on classes On Feb 4, 2008 2:27 PM, Dino Viehland [EMAIL PROTECTED] wrote: As other people have pointed out decorators are a runtime concept and I don't think we get to change that. So consider a class decorator You could theoretically have a slightly alternate parsing mode that recognizes a specific class decorator name before the class definition is closed (and therefore before codegen). In other words, the following definition @ClrAttribute(System.SerializableAttribute) class X(ISomething, object): treats the decorator differently if it matches one of the special-case names. The change in parsing could be triggered by something like from future import clr_hacks. On Feb 4, 2008 2:32 PM, Keith J. Farmer [EMAIL PROTECTED] wrote: CPythonista outrage over not being able to read something they could never run is rather silly. :) You're clearly having trouble envisioning the following Slashdot headline: Microsoft inflicts 'embrace and extend' on Python. Silly or not, perceptions are hugely important. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
You can download my work-in-progress from http://hagenlocher.org/software/ClrWrapper.zip The source consists of the three files ClrBuilder.py, ClrWrapper.py and MakeModule.py. There are also two demo files: Xtest.py and WcfServer.py. The program can currently be run as follows: PS F:\IronPython-2.0A8 *.\ipy.exe MakeModule.py Xtest.py* This will produce a file called Xtest.dll. At this point, the application doesn't require any of the standard Python library files. It's only been tried with the Alpha 8 binaries -- and in fact, the hosting interfaces for IronPython still aren't entirely stable so there's no guarantee that the DLLs produced will work with Alpha 9. Xtest.py is a trivial application that implements a single xunit-compatible unit test PS F:\IronPython-2.0A8 *.\xunit.console.exe Xtest.dll /noshadow* . Total tests: 1, Failures: 0, Skipped: 0, Time: 0.275 seconds WcfServer.py theoretically implements a WCF server, though I haven't gotten as far as actually testing the output yet. (The generated code passes the eyeball compiler.) Code quality is unimpressive; your mileage may vary. And I've got to get back to my day job for a few hours now :). -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
I was testing out the code provided and when I tested it using the example I got the following error. Note: I'm using IronPython 2.0 Alpha (2.0.0.800) on .NET 2.0.50727.1433 C:\Documents and Settings\TJRiley\Desktop\ClrWrapperipy.exe MakeModule.py Xtest.py Traceback (most recent call last): File , line unknown, in _stub_##2 File C:\Documents and Settings\TJRiley\Desktop\ClrWrapper\Xtest.py, line 4, in Initialize File MakeModule.py, line 331, in Initialize File MakeModule.py, line 39, in GetExportedClasses IOError: Could not add reference to assembly xunit.dll On Feb 5, 2008 3:00 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote: You can download my work-in-progress from http://hagenlocher.org/software/ClrWrapper.zip The source consists of the three files ClrBuilder.py, ClrWrapper.py and MakeModule.py. There are also two demo files: Xtest.py and WcfServer.py. The program can currently be run as follows: PS F:\IronPython-2.0A8 .\ipy.exe MakeModule.py Xtest.py This will produce a file called Xtest.dll. At this point, the application doesn't require any of the standard Python library files. It's only been tried with the Alpha 8 binaries -- and in fact, the hosting interfaces for IronPython still aren't entirely stable so there's no guarantee that the DLLs produced will work with Alpha 9. Xtest.py is a trivial application that implements a single xunit-compatible unit test PS F:\IronPython-2.0A8 .\xunit.console.exe Xtest.dll /noshadow . Total tests: 1, Failures: 0, Skipped: 0, Time: 0.275 seconds WcfServer.py theoretically implements a WCF server, though I haven't gotten as far as actually testing the output yet. (The generated code passes the eyeball compiler.) Code quality is unimpressive; your mileage may vary. And I've got to get back to my day job for a few hours now :). -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
On Feb 5, 2008 1:24 PM, Tim Riley [EMAIL PROTECTED] wrote: I was testing out the code provided and when I tested it using the example I got the following error. [snip] IOError: Could not add reference to assembly xunit.dll Sorry, you need xunit for that -- it's not part of IronPython. Xunit is a kind of next generation NUnit for unit testing, and I recommend it highly. You can find it at http://www.codeplex.com/xunit -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
Data binding isn't working for you? We have support for this via
CustomTypeDescriptors which describe the Python objects and we have some test
cases to verify it works. Note it was broken before 1.1.1 although it's been
working in 2.0 for a little while now. For example:
import clr
clr.AddReference('System.Windows.Forms')
import System.Windows.Forms as SWF
import System
class AgeQualifier(object):
def __get__(self, instance, ctx):
if instance.Age 13: return 'young'
if instance.Age 20: return 'teen'
if instance.Age 30: return 'twenties'
if instance.Age 40: return 'thirties'
if instance.Age 50: return 'forties'
return 'old'
SAMPLE_DATA = [('Joe', 23, 'twenties'), ('Bob', 8, 'young'), ('Thomas', 32,
'thirties'), ('Patrick', 41, 'forties'), ('Kathy', 19, 'teen'), ('Sue' , 77,
'old'),]
class Person(System.Object):
def __init__(self, name, age):
self._name = name
self._age = age
def get_name(self):
return self._name
def set_name(self, value):
self._name = value
Name = property(get_name, set_name)
def get_age(self):
return self._age
def set_age(self, value):
self._age = value
Age = property(get_age, set_age)
AgeDescription = AgeQualifier()
class Form(SWF.Form):
def __init__(self):
SWF.Form.__init__(self)
self._people = people = []
for name, age, ignored in SAMPLE_DATA:
people.append(Person(name, age))
grid = SWF.DataGridView()
grid.AutoGenerateColumns = True
grid.DataSource = people
grid.Dock = SWF.DockStyle.Fill
self.grid = grid
self.Controls.Add(grid)
form = Form()
SWF.Application.Run(form)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pigneri, Rocco
Sent: Tuesday, February 05, 2008 9:15 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly
Curt,
This is a great feature and was one of the first features that I investigated
when I first got my hands on IP.
I see an immediate need for this feature in using data binding with Windows
Forms controls. Many controls (such as DataGridView and ListView) reflect over
the properties of bound objects in order to display this data dynamically with
no programmer setup. Because IP types are dynamic, WinForms cannot find any
properties to bind and creates an empty object. In order to use these
features now, I must create static interfaces with the required properties in a
separate assembly and then inherit that interface whenever I bind to business
objects.
To make using these UI controls easier, it would be great if property
statements could be turned into static properties either automatically or via a
flag. It seems that IP already matches properties to the correct static
getter/setter as defined in the interfaces so this should be a reasonable
request. This staticization would remove the need for the separate static
interface.
Another situation in which this would be really helpful--although less
critical--involves situations where I want to use a static tool on an IP
assembly (for example, I want to use NUnit to test my IP classes). I say that
this is not critical as a lot of tools already have Python-specific versions
available--PyUnit is a good example.
Finally, would there be a way to simplify programmer work by providing
standard static creators that are turned on and off at a high level? For
example, programmers could use a compiler switch to turn all functions into
void func(object, . . .) and object func(obj. . . ). I see this being
useful in situations such as using NUnit because all that is really needed is
the proper number of arguments and the right function name (all of which are
already known in Python). If things then work the way that I think they work,
you could then just pass the objects into the correct comparators, and if they
are the right type, then the tests will run. Otherwise, you'll get an
exception.
Hope that helps,
Rocco
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher
Sent: Monday, February 04, 2008 1:31 PM
To: Discussion of IronPython
Subject: [IronPython] Exporting Python code as an assembly
After a bit of spare-time hacking this weekend, I've got a proof-of-concept
program that takes a Python class and exports it as a (statically-defined)
assembly. It uses Pythonic function annotations to signal attributes and input
and output types to the wrapper generator. You end up with something like this
def Test(object):
@ClrAttribute(Xunit.FactAttribute)
def WorthlessTest(self):
Xunit.Assert.Equal[type(1)](1, 1)
@ClrAccepts(System.String, System.Int32)
@ClrReturns(System.Int32)
def CalculateValue(self, s, i):
return len(s) + i
The program takes this source and spits out a DLL containing the class Test
which
[IronPython] Easy Access to the DLR from C#
For the five people here who aren't on it, the following link was posted to the IronRuby mailing list: http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
Well don't I feel like a moron. I should have spotted that. I apologize for posting before thinking. On Feb 5, 2008 4:29 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote: On Feb 5, 2008 1:24 PM, Tim Riley [EMAIL PROTECTED] wrote: I was testing out the code provided and when I tested it using the example I got the following error. [snip] IOError: Could not add reference to assembly xunit.dll Sorry, you need xunit for that -- it's not part of IronPython. Xunit is a kind of next generation NUnit for unit testing, and I recommend it highly. You can find it at http://www.codeplex.com/xunit -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Easy Access to the DLR from C#
Curt Hagenlocher wrote: For the five people here who aren't on it, the following link was posted to the IronRuby mailing list: http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx Plus the two who don't subscribe to IronPython-URLs ;-) http://ironpython-urls.blogspot.com/2008/01/dynamic-lookup-in-c.html Michael -- Curt Hagenlocher [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
