Re: [IronPython] [Simpy-users] Simpy under IronPython 0.96
I think I have the first idea why the tests are failing: [bin] ./IronPythonConsole.exe IronPython 0.9.6 on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. def testgenerator(): .. for i in range(0,10): .. yield i .. testgenerator function testgenerator at 0x002B type(testgenerator) type 'function' import types type(testgenerator) == types.GeneratorType False -- The problem is that the following code doesn't work with either IronPythonConsole, or standard CPython 2.4. Any idea what I may be missing? Thanks, Stan. I propose we look at the tests one-by-one, and try to solve the problems. First failed test: def testActivate(self): Test activate() P1 = P(name=P1,T=100.0) initialize() activate(P1,P1.execute(),0) simulate(until=5) assert(now()==5),Simulate stopped at %s not %s%(now(),5) ERROR: Test activate() -- class 'SimPy.Simulation.Simerror': Fatal SimPy error: activating function whi ch is not a generator (contains no 'yield') ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [Simpy-users] Simpy under IronPython 0.96
if not (type(process) == types.GeneratorType): raise Simerror(Fatal SimPy error: activating function which+ is not a generator (contains no 'yield')) I suspect that the type system on IronPython is somehow different from that in CPython. given test.py: #from __future__ import generators import types def gentest(): for i in range(0,10): yield i #assert type(gentest) == types.GeneratorType print type(gentest) assert isinstance(gentest,types.GeneratorType) [bin] ./IronPythonConsole.exe test.py type 'function' Could you check what e.g. the type of a generator is? Klaus Müller -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stanislas Pinte Sent: Friday, December 16, 2005 5:29 PM To: [EMAIL PROTECTED] Cc: users@lists.ironpython.com Subject: [Simpy-users] Simpy under IronPython 0.96 Hello, I am trying to start unit testing Simpy under IronPython, and make a state of current affairs... 1: I had to comment out all the from __future__ import statements. 2: I had to copy the following standard CPython modules in IronPythonConsole.exe directory: [bin] ls *.py bisect.py* ntpath.py* stat.py* unittest.py* copy_reg.py* os.py* traceback.py* warnings.py* linecache.py* random.py* types.py* [bin] 3: then running ./IronPythonConsole.exe SimPy/testSimPy_ip.py gave me: Ran 41 tests in 0.280s FAILED (failures=1, errors=28) I propose we look at the tests one-by-one, and try to solve the problems. First failed test: def testActivate(self): Test activate() P1 = P(name=P1,T=100.0) initialize() activate(P1,P1.execute(),0) simulate(until=5) assert(now()==5),Simulate stopped at %s not %s%(now(),5) ERROR: Test activate() -- class 'SimPy.Simulation.Simerror': Fatal SimPy error: activating function whi ch is not a generator (contains no 'yield') -- -- Full test output: ERROR: Test activate() -- class 'SimPy.Simulation.Simerror': Fatal SimPy error: activating function whi ch is not a generator (contains no 'yield') == ERROR: Test yield hold and simulate(until) -- class 'SimPy.Simulation.Simerror': Fatal SimPy error: activating function whi ch is not a generator (contains no 'yield') == ERROR: Test request -- class 'SimPy.Simulation.Simerror': Fatal SimPy error: activating function whi ch is not a generator (contains no 'yield') == ERROR: Test request2 with capacity = 1 -- class 'SimPy.Simulation.Simerror': Fatal SimPy error: activating function whi ch is not a generator (contains no 'yield') == ERROR: Test request3 with capacity = 1 several requests -- class 'SimPy.Simulation.Simerror': Fatal SimPy error: activating function whi ch is not a generator (contains no 'yield') == ERROR: Test request4 with capacity = 2 several requests -- class 'SimPy.Simulation.Simerror': Fatal SimPy error: activating function whi ch is not a generator (contains no 'yield') == ERROR: Test PriorityQ, with no preemption, 0 capacity -- class 'SimPy.Simulation.Simerror': Fatal SimPy error: activating function whi ch is not a generator (contains no 'yield') == ERROR: Test PriorityQ, with no preemption, capacity == 1 -- class 'SimPy.Simulation.Simerror': Fatal SimPy error: activating function whi ch is not a generator (contains no 'yield') == ERROR: Test PriorityQ, with preemption, capacity == 1 -- class 'SimPy.Simulation.Simerror': Fatal SimPy error:
Re: [IronPython] [Simpy-users] Simpy under IronPython 0.96
Selon Klaus Muller [EMAIL PROTECTED]: Stan, Your assertion must be: assert type(gentest()) == types.GeneratorType, _not_: assert type(gentest) == types.GeneratorType. The call of a generator function generates a generator object. You are right, sorry!! there we are: [bin] python test.py 'import site' failed; use -v for traceback type 'generator' [bin] ./IronPythonConsole.exe test.py type '__main__+gentest0' Traceback (most recent call last): at __main__.Initialize() in c:\Program Files\IronPython-0.9.6\bin\test.py:lin e 9 AssertionError [bin] So let's file a bug to IronPython... ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [Simpy-users] Simpy under IronPython 0.96
Selon Klaus Muller [EMAIL PROTECTED]: Good work! What type does IronPython actually return for a generator? a generated type... type '__main__+gentest0' not looking like a generator... Stan. Klaus Müller -Original Message- From: Stanislas Pinte [mailto:[EMAIL PROTECTED] Sent: Friday, December 16, 2005 6:04 PM To: Klaus Muller Cc: [EMAIL PROTECTED]; users@lists.ironpython.com Subject: RE: [Simpy-users] Simpy under IronPython 0.96 Selon Klaus Muller [EMAIL PROTECTED]: Stan, Your assertion must be: assert type(gentest()) == types.GeneratorType, _not_: assert type(gentest) == types.GeneratorType. The call of a generator function generates a generator object. You are right, sorry!! there we are: [bin] python test.py 'import site' failed; use -v for traceback type 'generator' [bin] ./IronPythonConsole.exe test.py type '__main__+gentest0' Traceback (most recent call last): at __main__.Initialize() in c:\Program Files\IronPython-0.9.6\bin\test.py:lin e 9 AssertionError [bin] So let's file a bug to IronPython... ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] New proposed exception model for IronPython
Title: [IronPython] New proposed exception model for IronPython
Your proposal is essentially what we have today (we have a separate
exception hierarchy that represents Python exceptions that is not correlated
with the CLR exception hierarchy in any way). This actually leads to *less*
compatibility with CPython because our exception classes end up showing up as
new-style classes instead of old-style classes. We also are forced to
have a slightly different starting point for our exception hierarchy than
CPython. If you see someway we'll be less true to CPython under the
proposed model let us know and we can see if we can tweak it to better fit in
here.
The current story also makes it more difficult for other CLS code to
consume Python code. For example under today's story no pre-written .NET
code will ever catch Python exceptions. Under the current model .NET
developers need to have a dependency on IronPython.dll and then write:
try{
}
catch(PythonIOError){
}
Where all the existing code in the .NET world has:
try{
}catch(IOException){
}
While it might be reasonable to expect that new .NET code written with
Python in mind might handle Python exceptions we certainly can't expect that
all the existing code be updated to handle this - and certainly not in a timely
manner.
Finally I want to point out we dont want to take away your
ability to handle .NET exceptions from Python code or raise specific .NET
exceptions either. What you catch will be based upon the type specified
in your except clause. So you can always do:
try:
o = System.IO.StreamReader(doesnotexist.txt)
except System.IO.IOException, e:
raise MySpecialIOError
So if you want to provide a more customized exception experience when
wrapping calls into .NET code you have the power. Likewise if you want to
throw a CLS exception that doesn't get wrapped under the proposed model you can
do that as well:
raise System.Exception('Hello world!')
We don't want to make it hard for the library writer to provide a more
customized experience (going either way through the interop story). If
you think the new proposal would do this I'd love to hear some specific
examples of what you'd like to be able to accomplish and why you think this
would interfere with that.
Thanks for your feedback!
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Ernst, Nathan
Sent: Thursday, December 15, 2005
6:22 PM
To: Discussion of IronPython
Subject: Re: [IronPython] New
proposed exception model for IronPython
Personally, what I would propose would be:
Python
libraries throw python exceptions.
.Net
libs ought to throw .Net exceptions
Where
python libs are implemented using .Net libs, .Net exceptions ought to be
wrapped with python libs to the fullest extent reasonably possible.
I believe these three points would lead to
a consistent behavior and compatibility with CPython based scripts.
While I like Keiths suggestion of a
file-scoped mapping, Im worried it might even further complicate matters
by having to compensate for both schemes (throwing python exceptions, versus
throwing .Net exceptions). I make my suggestion of having it effectively
left up to the library implementer because I think it is reasonable to expect
standard python libraries to throw python exceptions. I also think its
reasonable that if you are using ironpython specific libraries (or .Net libs
directly) to expect to have to handle .Net exceptions.
Im happy to see the progress that
is being made with the new releases (especially with regards to regex
support). I think were fast approaching the point where ironpython
can be used as a replacement for CPython.
Thanks,
Nathan Ernst
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Keith J. Farmer
Sent: Thursday, December 15, 2005
7:27 PM
To: Discussion of IronPython
Subject: RE: [IronPython] New
proposed exception model for IronPython
It's something that should be scoped at
the source file level or lower. Otherwise, someone could map Foo
exception to PythonFoo exception, someone else could map Foo to PythonBar, and
some poor slob would be left wondering why the first bit of code is suddenly
misbehaving.
#BeginMapException CliException1
PythonException1
...
#BeginMapException CliException2
PythonException2
...
#EndMapException CliException2
...
#EndMapException CliException1
#BeginMapException CliException1 PythonException3
...
#EndMapException CliException1
From:
[EMAIL PROTECTED] on behalf of Dino Viehland
Sent: Thu 12/15/2005 3:40 PM
To: Discussion of IronPython
Subject: Re: [IronPython] New
proposed exception model for IronPython
Its an extremely interesting idea
and one that I personally like. Being the new guy Ill want to hear
Jim and Martins input too J.
Ultimately theres no reason why we
couldnt either expose supplementary
