Re: [IronPython] Switching DLR tests from MSTest to NUnit

[Richard Nienaber]

> Richard, any particular reason you went with NUnit?

I went with NUnit because it's the one I'm most familiar with and the one
that seems to be in wide spread use. The CI build servers that I've used (
TeamCity,
CruiseControl.net)
have NUnit support out the box. I know the CodeBetter build server is
TeamCity which would mean setting up NUnit would be fairly easy.

Having said that, I don't feel really strongly about the use of NUnit as my
main goal was just removing a dependency on Visual Studio.

Richard

On Tue, Feb 1, 2011 at 11:40 PM, Jeff Hardy  wrote:

> On Tue, Feb 1, 2011 at 4:19 PM, Tomas Matousek
>  wrote:
> > I have an experience with xUnit.net (
> http://xunit.codeplex.com/wikipage?title=WhyDidWeBuildXunit&referringTitle=Home),
> so I would personally prefer that one. It has a pretty good VS integration.
> I haven't used NUnit. If you prefer it I don't have objections.
>
> One nice thing about NUnit is just how little needs to change from MSTest.
>
> I do wonder how much of a change going to xUnit.net would be, as all
> of my experience is with xUnit.net as well. Richard, any particular
> reason you went with NUnit?
>
> - Jeff
> ___
> 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] Switching DLR tests from MSTest to NUnit

[Jeff Hardy]

On Tue, Feb 1, 2011 at 4:19 PM, Tomas Matousek
 wrote:
> I have an experience with xUnit.net 
> (http://xunit.codeplex.com/wikipage?title=WhyDidWeBuildXunit&referringTitle=Home),
>  so I would personally prefer that one. It has a pretty good VS integration. 
> I haven't used NUnit. If you prefer it I don't have objections.

One nice thing about NUnit is just how little needs to change from MSTest.

I do wonder how much of a change going to xUnit.net would be, as all
of my experience is with xUnit.net as well. Richard, any particular
reason you went with NUnit?

- Jeff
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Switching DLR tests from MSTest to NUnit

[Tomas Matousek]

I have an experience with xUnit.net 
(http://xunit.codeplex.com/wikipage?title=WhyDidWeBuildXunit&referringTitle=Home),
 so I would personally prefer that one. It has a pretty good VS integration. I 
haven't used NUnit. If you prefer it I don't have objections.

One comment on the placement of the framework dlls - a better place than 
/Runtime/Tests/Lib would be /Util/NUnit.

Tomas

-Original Message-
From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Tuesday, February 01, 2011 2:37 PM
To: Discussion of IronPython
Subject: [IronPython] Switching DLR tests from MSTest to NUnit

There's a pull request (https://github.com/IronLanguages/main/pull/10)
pending that changes the unit tests for the DLR from MsTest to NUnit.
The advantage of doing this is that NUnit test can be run without having Visual 
Studio installed on the machine, which will make it much easier to run tests in 
a CI environment, and I presume for running on Mono as well. The downside is 
that MsTest has an integrated test runner in VS, and NUnit doesn't out of the 
box (but there are some available).

Since I don't work on the DLR code, I wanted to make sure this change is 
acceptable to those that do. Tomas, Dino - thoughts?

- Jeff
___
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] Disabling optimized methods

[Daniel Jennings]

We aren't constructing a ScriptSource at any point, so that's probably it.


From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Daniel Jennings
Sent: Tuesday, February 01, 2011 1:32 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Disabling optimized methods


I'll give that a shot, thanks!



Dino Viehland  wrote:


Is Path on your ScriptSource non-null?  That should be the only other thing 
which has an effect.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Daniel Jennings
Sent: Tuesday, February 01, 2011 12:51 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Disabling optimized methods

Alright, we're using DebugMode = true already (when the application starts with 
the debugger attached) so we must be seeing something else that is causing us 
to get the 'function has been optimized' message.

Thanks


From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Tuesday, February 01, 2011 12:50 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Disabling optimized methods

You can use -X:Debug now to specifiy this at the command line.  If you want to 
do it while you're hosting you can set the DebugMode option to true on the 
ScriptRuntimeSetup object used to create the ScriptRuntime.  You'll need to 
make sure the ScriptSource's you create have filenames though.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Daniel Jennings
Sent: Tuesday, February 01, 2011 11:55 AM
To: Discussion of IronPython
Subject: [IronPython] Disabling optimized methods

I was reading an old post by Dino here: 
http://www.mail-archive.com/users@lists.ironpython.com/msg04829.html that 
mentions that using -X:StaticMethods will force methods into types so that you 
can get the typical CLR-style debugging. I was wondering two things: 1. Is this 
still relavant to 2.7A1? 2. How do you specify such a flag when you're 
embedding IronPython in your application (building your own engine.)

Thanks!
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] Switching DLR tests from MSTest to NUnit

[Jeff Hardy]

There's a pull request (https://github.com/IronLanguages/main/pull/10)
pending that changes the unit tests for the DLR from MsTest to NUnit.
The advantage of doing this is that NUnit test can be run without
having Visual Studio installed on the machine, which will make it much
easier to run tests in a CI environment, and I presume for running on
Mono as well. The downside is that MsTest has an integrated test
runner in VS, and NUnit doesn't out of the box (but there are some
available).

Since I don't work on the DLR code, I wanted to make sure this change
is acceptable to those that do. Tomas, Dino - thoughts?

- Jeff
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Issue Triage

[Richard Nienaber]

> I usually start import bugs by trying to re-create a simple repro of the
issue and then work from there.

I've managed to get as far as this point. I've tried to boild down the
problem to a simple test case which I've added to the
issue.
What seems to be happening is this:

   - import sympy is called
   - sympy import gets to simpify.py, imports decimal (stdlib) which then
   imports numbers.py (stdlib)
   - sympy import gets to function.py, which attempts to import Integer from
   numbers (sympy)
  - It fails here because it tries to import Integer from numbers.py
  (stdlib)


The test case works in 2.6.2 but fails in 2.7b1 which seems to indicate a
regression. I tried importing the sympy library in 2.6.2 but it fails
with: ImportError: No module named signal

Richard


On Sun, Jan 30, 2011 at 9:16 PM, Dino Viehland  wrote:

>  There’s probably an Integer.py somewhere in sympy and this is probably an
> import bug.  If someone was particularly ambitious they could re-write
> import by porting CPython’s import to IronPython – viola, no more import
> bugs! J
>
>
>
> Otherwise it’s all about figuring out how we’re differing in import
> semantics – I usually start import bugs by trying to re-create a simple
> repro of the issue and then work from there.  I always thought import bugs
> but if you look at the CPython source code it might be much easier.
>
>
>
> *From:* users-boun...@lists.ironpython.com [mailto:
> users-boun...@lists.ironpython.com] *On Behalf Of *Bruce Bromberek
> *Sent:* Sunday, January 30, 2011 12:22 PM
> *To:* Discussion of IronPython
> *Subject:* [IronPython] Issue Triage
>
>
>
> I though I'd help by going through any issues tagged with High importance,
> unassigned, starting with ones from previous releases and seeing is they are
> still relevant.
>
> Issue 26426,  which involves sympy (algebraic manipulation) under
> ironpython.  With the most recent git version of sympy and IronPython 2.7B1,
> I get a better error message.
>
>
>
> C:\GITHUB\sympy>"c:\Program Files\IronPython 2.7\ipy.exe"
>
> IronPython 2.7 Beta 1 (2.7.0.10) on .NET 4.0.30319.1
>
> Type "help", "copyright", "credits" or "license" for more information.
>
> >>> import sympy
>
> Traceback (most recent call last):
>
>   File "", line 1, in 
>
>   File "C:\GITHUB\sympy\sympy\__init__.py", line 30, in 
>
>   File "C:\GITHUB\sympy\sympy\core\__init__.py", line 8, in 
>
>   File "C:\GITHUB\sympy\sympy\core\expr.py", line 1008, in 
>
>   File "C:\GITHUB\sympy\sympy\core\mul.py", line 962, in 
>
>   File "C:\GITHUB\sympy\sympy\core\power.py", line 806, in 
>
>   File "C:\GITHUB\sympy\sympy\core\add.py", line 516, in 
>
>   File "C:\GITHUB\sympy\sympy\core\symbol.py", line 6, in 
>
>   File "C:\GITHUB\sympy\sympy\logic\__init__.py", line 1, in 
>
>   File "C:\GITHUB\sympy\sympy\logic\boolalg.py", line 4, in 
>
>   File "C:\GITHUB\sympy\sympy\core\function.py", line 1091, in 
>
> ImportError: Cannot import name Integer
>
>
>
>
>
> Line 1091 is :
>
> from numbers import Rational, Integer
>
>
>
> I though the issue was 'Integer' as a reserved word in Ironpython.
>  However, I can create a function or a class named Integer in
> the interpreter without a problem.  Now I'm stuck.  Any thoughts on how to
> proceed
>
> ___
> 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] Disabling optimized methods

[Daniel Jennings]

I'll give that a shot, thanks!

Dino Viehland  wrote:


Is Path on your ScriptSource non-null?  That should be the only other thing 
which has an effect.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Daniel Jennings
Sent: Tuesday, February 01, 2011 12:51 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Disabling optimized methods

Alright, we’re using DebugMode = true already (when the application starts with 
the debugger attached) so we must be seeing something else that is causing us 
to get the ‘function has been optimized’ message.

Thanks


From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Tuesday, February 01, 2011 12:50 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Disabling optimized methods

You can use –X:Debug now to specifiy this at the command line.  If you want to 
do it while you’re hosting you can set the DebugMode option to true on the 
ScriptRuntimeSetup object used to create the ScriptRuntime.  You’ll need to 
make sure the ScriptSource’s you create have filenames though.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Daniel Jennings
Sent: Tuesday, February 01, 2011 11:55 AM
To: Discussion of IronPython
Subject: [IronPython] Disabling optimized methods

I was reading an old post by Dino here: 
http://www.mail-archive.com/users@lists.ironpython.com/msg04829.html that 
mentions that using –X:StaticMethods will force methods into types so that you 
can get the typical CLR-style debugging. I was wondering two things: 1. Is this 
still relavant to 2.7A1? 2. How do you specify such a flag when you’re 
embedding IronPython in your application (building your own engine.)

Thanks!
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Disabling optimized methods

[Dino Viehland]

Is Path on your ScriptSource non-null?  That should be the only other thing 
which has an effect.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Daniel Jennings
Sent: Tuesday, February 01, 2011 12:51 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Disabling optimized methods

Alright, we're using DebugMode = true already (when the application starts with 
the debugger attached) so we must be seeing something else that is causing us 
to get the 'function has been optimized' message.

Thanks


From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Tuesday, February 01, 2011 12:50 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Disabling optimized methods

You can use -X:Debug now to specifiy this at the command line.  If you want to 
do it while you're hosting you can set the DebugMode option to true on the 
ScriptRuntimeSetup object used to create the ScriptRuntime.  You'll need to 
make sure the ScriptSource's you create have filenames though.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Daniel Jennings
Sent: Tuesday, February 01, 2011 11:55 AM
To: Discussion of IronPython
Subject: [IronPython] Disabling optimized methods

I was reading an old post by Dino here: 
http://www.mail-archive.com/users@lists.ironpython.com/msg04829.html that 
mentions that using -X:StaticMethods will force methods into types so that you 
can get the typical CLR-style debugging. I was wondering two things: 1. Is this 
still relavant to 2.7A1? 2. How do you specify such a flag when you're 
embedding IronPython in your application (building your own engine.)

Thanks!
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Disabling optimized methods

[Daniel Jennings]

Alright, we're using DebugMode = true already (when the application starts with 
the debugger attached) so we must be seeing something else that is causing us 
to get the 'function has been optimized' message.

Thanks


From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Tuesday, February 01, 2011 12:50 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Disabling optimized methods

You can use -X:Debug now to specifiy this at the command line.  If you want to 
do it while you're hosting you can set the DebugMode option to true on the 
ScriptRuntimeSetup object used to create the ScriptRuntime.  You'll need to 
make sure the ScriptSource's you create have filenames though.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Daniel Jennings
Sent: Tuesday, February 01, 2011 11:55 AM
To: Discussion of IronPython
Subject: [IronPython] Disabling optimized methods

I was reading an old post by Dino here: 
http://www.mail-archive.com/users@lists.ironpython.com/msg04829.html that 
mentions that using -X:StaticMethods will force methods into types so that you 
can get the typical CLR-style debugging. I was wondering two things: 1. Is this 
still relavant to 2.7A1? 2. How do you specify such a flag when you're 
embedding IronPython in your application (building your own engine.)

Thanks!
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Disabling optimized methods

[Dino Viehland]

You can use -X:Debug now to specifiy this at the command line.  If you want to 
do it while you're hosting you can set the DebugMode option to true on the 
ScriptRuntimeSetup object used to create the ScriptRuntime.  You'll need to 
make sure the ScriptSource's you create have filenames though.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Daniel Jennings
Sent: Tuesday, February 01, 2011 11:55 AM
To: Discussion of IronPython
Subject: [IronPython] Disabling optimized methods

I was reading an old post by Dino here: 
http://www.mail-archive.com/users@lists.ironpython.com/msg04829.html that 
mentions that using -X:StaticMethods will force methods into types so that you 
can get the typical CLR-style debugging. I was wondering two things: 1. Is this 
still relavant to 2.7A1? 2. How do you specify such a flag when you're 
embedding IronPython in your application (building your own engine.)

Thanks!
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com