From vladimir099 at gmail.com  Tue Apr  1 13:25:18 2014
From: vladimir099 at gmail.com (Vladimir Vukovic)
Date: Tue, 1 Apr 2014 13:25:18 +0200
Subject: [Ironpython-users] SystemError: Handle is not initialized.
Message-ID: <CAO_pBq9NuJxzLwO5c2J9ywYWFnpePe4ntGWmHwTbj+stc6Ox7w@mail.gmail.com>

We embedded IronPython 2.7. to our .Net application (.net version is 4.0).

There is one abstract base class (Application) and derived class from
it (DApplication).

class Application(object):
    __metaclass__ = abc.ABCMeta

    app = None

    def __init__(self, app):
        self.app = app

class DApllication(Application):
    def __init__(self):
        super(DApllication, self).__init__(app='some_string')

After this:

d = DApllication()

exception is thrown:

Traceback (most recent call last):
  File "C:\Program Files\SmartTest\lib\python\StdLib\abc.py", line
132, in __instancecheck__
  File "C:\Program Files\SmartTest\lib\python\StdLib\_weakrefset.py",
line 73, in __contains__
SystemError: Handle is not initialized.


This happened only once, and we couldn't reproduce this anymore.

We think that GC collect some objects, with weak ref, and when we try
to use it, exception is raised.

Does anyone had this problem or know for this issue?

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140401/7ca1a61e/attachment.html>

From bruce.bromberek at gmail.com  Wed Apr  2 03:22:09 2014
From: bruce.bromberek at gmail.com (=?utf-8?B?YnJ1Y2UuYnJvbWJlcmVrQGdtYWlsLmNvbQ==?=)
Date: Tue, 01 Apr 2014 20:22:09 -0500
Subject: [Ironpython-users]
 =?utf-8?q?POST_requests_to_IronPython_CGI_unde?=
 =?utf-8?q?r_IIS_7=2E5?=
Message-ID: <533b749e.611f450a.58d4.2ac4@mx.google.com>


BBC changing 

Sent from my HTC One? S on T-Mobile. America?s First Nationwide 4G Network.

----- Reply message -----
From: "Jeff Hardy" <jdhardy at gmail.com>
To: "Dalius Dobravolskas" <dalius.dobravolskas at gmail.com>
Cc: "ironpython-users at python.org" <ironpython-users at python.org>
Subject: [Ironpython-users] POST requests to IronPython CGI under IIS 7.5
Date: Wed, Dec 19, 2012 10:51 AM


On Tue, Dec 11, 2012 at 3:26 AM, Dalius Dobravolskas
<dalius.dobravolskas at gmail.com> wrote:
> Hi,
>
> I have created python CGI script that should handle POST requests. I'm
> running this script under IIS 7.5. It works without problems if I'm using
> CPython but with IronPython I have problem (therefore I know it is
> IronPython problem and not IIS). If POST request is longer than 320 symbols
> then my script freezes. Initially I was trying to use python cgi module - it
> was working until I tried POST request with more data. Then I tried to go
> deeper and tried to parse request manually - then I found out that reading
> from sys.stdin freezes my script when more data than 320 symbols is passed
> to script.
>
> As temporary solution I will use GET requests (but kitten is killed when you
> use GET to modify data) or I will use alternative to CGI scripts (any
> recommendations).
>
> I have created bug reports here:
> http://ironpython.codeplex.com/workitem/33556

Thanks for the issue report. I have no idea if it's an IronPython
issue or an IIS issue, but since you say it works with normal Python,
my guess is IronPython somewhere.

One alternative is NWSGI (http://nwsgi.codeplex.com/) which uses
IronPython to implement the standard Python WSGI interface.

- Jeff
_______________________________________________
Ironpython-users mailing list
Ironpython-users at python.org
http://mail.python.org/mailman/listinfo/ironpython-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140401/d1f779ba/attachment.html>

From no_reply at codeplex.com  Wed Apr  2 09:22:47 2014
From: no_reply at codeplex.com (CodePlex)
Date: 2 Apr 2014 00:22:47 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/1/2014
Message-ID: <CO1MSDNADMCDS2AOeIi0000fa12@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] json.dump fails to dump Unicode strings

----------------------------------------------

ISSUES

1. [New comment] json.dump fails to dump Unicode strings
http://ironpython.codeplex.com/workitem/32331
User robden has commented on the issue:

"<p>I just hit this yesterday.  Not being able to easily use unicode strings for json seems like a big usability issue.  To get around the bug without modifying the standard library, I encoded all my strings to utf-8 before encoding into json.  It's ugly, but it works.  But it's ugly...</p>"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140402/0175367b/attachment.html>

From pommelin6fr at gmail.com  Thu Apr  3 17:26:23 2014
From: pommelin6fr at gmail.com (Lin LIU)
Date: Thu, 3 Apr 2014 17:26:23 +0200
Subject: [Ironpython-users] How to get lib json in ironpython
Message-ID: <CABSGvHg6=t7sprvKmMic-o1oOzeUXoypZUTNbuWaoKHRiTgtXQ@mail.gmail.com>

Hello everyone,

    I'm a newbie of IronPython and I'm a python user since 3 years.
Actually, I work on a .NET based project in which I use IronPython to call
the CS libs. I encountered a problem when I wanted get lib Json in
ironpython and then I put the following codes in the beginning of the
script and it works.
import sys
sys.path.append("C:\Program Files\IronPython 2.7\Lib")
import json

But this solution impose the installation of ironpython.

Otherwise, putting the IronPython.dll, IronPython.Module.dll in my app
directory can also help me to get some python libs, ex: re. But this
doesn"t work to get lib json.

I wonder if anyone of you has the same experience as mine and already has
found a DLL which contains json.

I hear that using .NET libs in script python can also get json, but I've no
idea which lib to use and how to use it. Anyone can help me. Thanks a lot.

Best regards,

Lin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140403/7fd2e2aa/attachment.html>

From rome at Wintellect.com  Thu Apr  3 19:25:38 2014
From: rome at Wintellect.com (Keith Rome)
Date: Thu, 3 Apr 2014 17:25:38 +0000
Subject: [Ironpython-users] .NET Foundation
Message-ID: <CF6311CA.13749%rome@wintellect.com>

With the announcement today of .NET Foundation "umbrella" for all of Microsoft's open-sourced products, I am curious about what distinguishes the DLR/IronLanguages work from some of these others? Is it simply forgotten about by Microsoft, or is there some other reason it is left out as a black sheep? Or is it a conscious choice to stay disassociated with the Microsoft ecosystem as much as possible?

http://www.dotnetfoundation.org/

>From what I've seen, this set of repositories has been the most "open sourced" in the spirit of true open source - in that it relies heavily on (and accepts) pull requests from non-Microsoft persons. The others seem to often follow more of a "top down" contributions model.


Keith Rome
Principal Architect @ Wintellect (www.wintellect.com<http://www.wintellect.com>)
770.617.4016 | krome at wintellect.com<mailto:rome at wintellect.com>

[cid:1E982B6A-A045-441B-A570-F52168B48288]
Register today<https://www.wintellectnow.com/Account/Promo/ROME-13> for access to our high-quality on-demand training resources!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140403/2f60a60e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 529A2558-817C-467F-8E7E-0789B90D675C[2].png
Type: image/png
Size: 6285 bytes
Desc: 529A2558-817C-467F-8E7E-0789B90D675C[2].png
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140403/2f60a60e/attachment.png>

From m.schaber at codesys.com  Fri Apr  4 07:29:43 2014
From: m.schaber at codesys.com (Markus Schaber)
Date: Fri, 4 Apr 2014 05:29:43 +0000
Subject: [Ironpython-users] How to get lib json in ironpython
In-Reply-To: <CABSGvHg6=t7sprvKmMic-o1oOzeUXoypZUTNbuWaoKHRiTgtXQ@mail.gmail.com>
References: <CABSGvHg6=t7sprvKmMic-o1oOzeUXoypZUTNbuWaoKHRiTgtXQ@mail.gmail.com>
Message-ID: <727D8E16AE957149B447FE368139F2B539B85AEF@SERVER10>

Hi, Lin,

You need to provide the IronPython standard library to your application. The IronPython standard library consists of two parts: The IronPython.modules.dll (which roughly represents the "native" part of the cPython standard library) and a Directory full of python files (which is nearly identical to the python part of the cPython standard library).

It seems you already found the first part, and (as a hack) used the cPython version of the second part.

I see three options:

1) Ship the second part of the standard Library with your application as a directory tree. You just need to add the directory to sys.path (can be done by python code, or by the hosting .NET code). This way is the most similar and compatible one compared to cPython, and e. G. also implemented by CODESYS.


2) Using ZipImport: Newer versions of IronPython support ZipImport, so you could just zip the directory tree together, and add the zip file to sys.path.


3) You can compile the python files to a .NET Assembly (.dll file) using the "pyc.py" script (which should be included in recent ironpython packages).


I've never done 2 and 3 myself, but as far as I know, others have with success.

You should use the python files which are shipped with the corresponding IronPython version instead of the cPython ones, as they contain some compatibility patches and fixes. The IronPython developers intend to unify the standard library with the cPython one, but they're not there yet.

Best regards

Markus Schaber

CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions
________________________________
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber at codesys.com<mailto:m.schaber at codesys.com> | Web: codesys.com<http://www.codesys.com> | CODESYS store: store.codesys.com<http://store.codesys.com>
CODESYS forum: forum.codesys.com<http://forum.codesys.com>

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Von: Ironpython-users [mailto:ironpython-users-bounces+m.schaber=codesys.com at python.org] Im Auftrag von Lin LIU
Gesendet: Donnerstag, 3. April 2014 17:26
An: ironpython-users at python.org
Betreff: [Ironpython-users] How to get lib json in ironpython

Hello everyone,

    I'm a newbie of IronPython and I'm a python user since 3 years. Actually, I work on a .NET based project in which I use IronPython to call the CS libs. I encountered a problem when I wanted get lib Json in ironpython and then I put the following codes in the beginning of the script and it works.
import sys
sys.path.append("C:\Program Files\IronPython 2.7\Lib")
import json

But this solution impose the installation of ironpython.

Otherwise, putting the IronPython.dll, IronPython.Module.dll in my app directory can also help me to get some python libs, ex: re. But this doesn"t work to get lib json.

I wonder if anyone of you has the same experience as mine and already has found a DLL which contains json.

I hear that using .NET libs in script python can also get json, but I've no idea which lib to use and how to use it. Anyone can help me. Thanks a lot.

Best regards,

Lin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140404/5b1c394e/attachment.html>

From no_reply at codeplex.com  Fri Apr  4 09:28:49 2014
From: no_reply at codeplex.com (CodePlex)
Date: 4 Apr 2014 00:28:49 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/3/2014
Message-ID: <CO1MSDNADMCDS2x4A2D00013c73@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New issue] int type missing __eq__ method

----------------------------------------------

ISSUES

1. [New issue] int type missing __eq__ method
http://ironpython.codeplex.com/workitem/35099
User ntimkovich has proposed the issue:

"In trying to install the back-ported enum package from Python 3.4, I came across what seems to be a strange quirk: the built-in int type does not have an __eq__ attribute for testing integer equality.  The enum package strikes upon this when it tries to copy the attributes/methods from the base integer type into the IntEnum class.

I know not if IronPython isn't complying with some spec, but it seems to be the odd-man-out.
D:\>py -2.7 -c "print(getattr(int, '__eq__'))"
<method-wrapper '__eq__' of type object at 0x000000001E2947D0>

D:\>py -3.3 -c "print(getattr(int, '__eq__'))"
<slot wrapper '__eq__' of 'int' objects>

D:\>ipy -c "print(getattr(int, '__eq__'))"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: 'type' object has no attribute '__eq__'

D:\>ipy -c "print(getattr(int(0), '__eq__'))"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: 'int' object has no attribute '__eq__'

Respective versions:

Python 3.3.5 (v3.3.5:62cf4e77f785, Mar  9 2014, 10:35:05) [MSC v.1600 64 bit (AMD64)] on win32
Python 2.7.6 (default, Nov 10 2013, 19:24:24) [MSC v.1500 64 bit (AMD64)] on win32
IronPython 2.7.4 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit)
"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140404/0d01099d/attachment.html>

From jdhardy at gmail.com  Fri Apr  4 11:39:34 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 4 Apr 2014 10:39:34 +0100
Subject: [Ironpython-users] .NET Foundation
In-Reply-To: <CF6311CA.13749%rome@wintellect.com>
References: <CF6311CA.13749%rome@wintellect.com>
Message-ID: <CAF7AXFGjD6VxtgK6hZK1uWXr3y+1-T5MwqPfUMK7m2VZUX=ZyA@mail.gmail.com>

On Thu, Apr 3, 2014 at 6:25 PM, Keith Rome <rome at wintellect.com> wrote:

>   With the announcement today of .NET Foundation "umbrella" for all of
> Microsoft's open-sourced products, I am curious about what distinguishes
> the DLR/IronLanguages work from some of these others? Is it simply
> forgotten about by Microsoft, or is there some other reason it is left out
> as a black sheep? Or is it a conscious choice to stay disassociated with
> the Microsoft ecosystem as much as possible?
>
>  http://www.dotnetfoundation.org/
>

No idea, this is the first I've heard of it. I doubt IP has been completely
forgotten, but I do feel a bit like this
guy<https://www.youtube.com/watch?v=grbSQ6O6kbs>whenever a release
comes out.

I am having a hard time figuring out what the point of the .NET Foundation
is, though, other than "advancing the conversation". I tought they tried
this once with the CodePlex/Outercurve foundation and it didn't go anywhere.


>
>  From what I've seen, this set of repositories has been the most "open
> sourced" in the spirit of true open source - in that it relies heavily on
> (and accepts) pull requests from non-Microsoft persons. The others seem to
> often follow more of a "top down" contributions model.
>

The last change from an MS person (AFAIK) was Tomas' changes to make the
DLR work with .NET 4.5 Core, a couple of years ago now. Everything now is
from outside MS.

- Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140404/4d84820d/attachment.html>

From misnomer at gmail.com  Fri Apr  4 11:52:12 2014
From: misnomer at gmail.com (Nicholas Devenish)
Date: Fri, 4 Apr 2014 10:52:12 +0100
Subject: [Ironpython-users] .NET Foundation
In-Reply-To: <CAF7AXFGjD6VxtgK6hZK1uWXr3y+1-T5MwqPfUMK7m2VZUX=ZyA@mail.gmail.com>
References: <CF6311CA.13749%rome@wintellect.com>
 <CAF7AXFGjD6VxtgK6hZK1uWXr3y+1-T5MwqPfUMK7m2VZUX=ZyA@mail.gmail.com>
Message-ID: <888390A6-F2CF-4F71-9525-0E9CA2F95E73@gmail.com>


On 4 Apr 2014, at 10:39, Jeff Hardy <jdhardy at gmail.com> wrote:
> I am having a hard time figuring out what the point of the .NET Foundation is, though, other than "advancing the conversation". I tought they tried this once with the CodePlex/Outercurve foundation and it didn't go anywhere.
>  

If I?ve read the announcements correctly, this is a list of everything that they are releasing as open source, along with Roslyn (which is under Apache2 licence, so real open source).




From pawel.jasinski at gmail.com  Fri Apr  4 14:01:52 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Fri, 4 Apr 2014 14:01:52 +0200
Subject: [Ironpython-users] .NET Foundation
In-Reply-To: <CF6311CA.13749%rome@wintellect.com>
References: <CF6311CA.13749%rome@wintellect.com>
Message-ID: <CA+7conmWJeugz=6ZaYtXF5Afhq3Hj6jJVC2EE0Nm9EEX58Sr7g@mail.gmail.com>

On Thu, Apr 3, 2014 at 7:25 PM, Keith Rome <rome at wintellect.com> wrote:

>   With the announcement today of .NET Foundation "umbrella" for all of
> Microsoft's open-sourced products, I am curious about what distinguishes
> the DLR/IronLanguages work from some of these others? Is it simply
> forgotten about by Microsoft, or is there some other reason it is left out
> as a black sheep? Or is it a conscious choice to stay disassociated with
> the Microsoft ecosystem as much as possible?
>

Does anybody know what is a benefit of being a member of this foundation?

--pawel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140404/80d4ef4e/attachment.html>

From no_reply at codeplex.com  Sun Apr  6 09:23:49 2014
From: no_reply at codeplex.com (CodePlex)
Date: 6 Apr 2014 00:23:49 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/5/2014
Message-ID: <CO1MSDNADMCDS281Tbd00016a71@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] unbound methods instead of bound methods in cloned class instances
2. [New comment] StackOverflow when enumerating dynamic members of IMOs
3. [New comment] int type missing __eq__ method

----------------------------------------------

ISSUES

1. [New comment] unbound methods instead of bound methods in cloned class instances
http://ironpython.codeplex.com/workitem/34649
User jdhardy has commented on the issue:

"<p>Looks like the culprit is aa25e7a (thank you git bisect).</p>"-----------------

2. [New comment] StackOverflow when enumerating dynamic members of IMOs
http://ironpython.codeplex.com/workitem/34893
User jdhardy has commented on the issue:

"<p>The interesting bits seem to be InstanceOps.DynamicDir and PythonType.TryGetCustomDir.</p>"-----------------

3. [New comment] int type missing __eq__ method
http://ironpython.codeplex.com/workitem/35099
User jdhardy has commented on the issue:

"<p>Fixed in 7bec672.</p>"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140406/a8a8e628/attachment.html>

From bernd.viehmann at googlemail.com  Sun Apr  6 21:20:36 2014
From: bernd.viehmann at googlemail.com (Bernd Viehmann)
Date: Sun, 06 Apr 2014 21:20:36 +0200
Subject: [Ironpython-users] nejoba. a regional microblog created with
 ironpython in asp.net is now open source :)
Message-ID: <5341A904.4000703@gmail.com>

Hello ipy-guys

I am building on a plattform for regional networking in the 
neighbourhood. it is also online : http://www.nejoba.net

The source repository will be cleaned up in the next days. But the code 
is available on google-code https://code.google.com/p/nejoba/

Reviews and critics  will be welcome. Or guys who want to help

Most of the project is in german. But a short description of the project 
is already translated :


Dear fellow people ,

the application is a form of a microblog . While other services timeline 
is linked to a user the blogs refer to postcode areas on nejoba. 
Residents or visitors share this as a city blog to publish information 
about their place to learn about local events and communicate with their 
neighbours.

Currently two applications are implemented .

Regional job market

nejoba offers a regional labor market on a private basis . In this case 
, people who want to finish a task publish an announcement . As with 
authorities may then submit an offer to private job seekers or 
professional craftsman.

Neighbour Forum

Regional information and communication are supported in the local forum. 
Here users may post informations of interest of their hometown.

The data can be grouped with hashtags to merge stakeholders. Tags have 
to nejoba (in contrast to other platforms ) always a regional reference. 
So the users create a regional information-pool for their neighbourhood.

In addition, the blog provides more attributes with which the 
contributions can be provided . With every posting an HTML document can 
be linked. For detailed description of formatted text, pictures and 
videos can be added too.

In addition a contribution can be provided with coordinated geo-info and 
visualized on a map.



-- 

it-viehmann logo sw 160*200 		


    *IT-Viehmann*


      Bernd Viehmann
      Mahrweg 46; 41836 H?ckelhoven

      Tel.: 02433 9640 100
      Fax: 02433 9640 109

      www.it-viehmann.de
      info at it-viehmann.de

Steuer Ident.: DE249193817

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140406/4d0e25a5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itv_200.png
Type: image/png
Size: 12477 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140406/4d0e25a5/attachment.png>

From no_reply at codeplex.com  Mon Apr  7 09:28:56 2014
From: no_reply at codeplex.com (CodePlex)
Date: 7 Apr 2014 00:28:56 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/6/2014
Message-ID: <CO1MSDNADMCDS2Hkidc00017dc6@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] StackOverflow when enumerating dynamic members of IMOs

----------------------------------------------

ISSUES

1. [New comment] StackOverflow when enumerating dynamic members of IMOs
http://ironpython.codeplex.com/workitem/34893
User becio has commented on the issue:

"<p>True, this bug affects the core interoperability between dynamic languages, I used DO in the example just a synonym of ANY external dynamic class.</p>"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140407/8ae8bae0/attachment.html>

From andy at britishideas.com  Mon Apr  7 12:03:07 2014
From: andy at britishideas.com (Andrew Ayre)
Date: Mon, 07 Apr 2014 11:03:07 +0100
Subject: [Ironpython-users] SymPy and IronPython 2.7.4
Message-ID: <534277DB.8090809@britishideas.com>

Hello,

I have embedded IronPython 2.7.4 into a .NET 4.0 C# application. I can
enter and run scripts and I also have an interactive console. It's
working great and I have no issues... until I tried to use SymPy.

I've asked for help from the SymPy people but they don't have any
experience with IronPython.

I have a subfolder called PythonLib into which I have copied the 2.7
standard libraries. Importing from these works:

========================================================
>>>import xml.dom
>>>
========================================================

So I have copied SymPy into PythonLib as well (e.g. I have
\PythonLib\sympy\__init__.py).

Here is the first issue:

========================================================
>>>import sympy

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
line 32, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy
\core\__init__.py", line 8, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
line 7, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
line 27, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\containers.py",
line 14, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\utilities\__init__.py", line
17, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\utilities\timeutils.py",
line 11, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\compatibility.py", line
110, in u
TypeError: unicode_escape_decode() takes no arguments (1 given)
========================================================

I can't find any description of what unicode_escape_decode does. It
seems to be a built-in function? In general SymPy is passing a string to
it to be decoded so it appears to make sense that the function has an
argument.

I've worked around this with the following:

========================================================
>>>import codecs
>>>def my_unicode_escape_decode(x):
...    return x
...
>>>codecs.unicode_escape_decode = my_unicode_escape_decode
========================================================

Now I get attribute errors. Here is the result of running several
imports. Can anyone please give me some pointers as to what might be the
issue? I'm thinking it is something to do with my environment or the way
I am embedded IronPython. Thanks! Andy

========================================================
>>>import sympy

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
line 32, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\__init__.py",
line 8, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
line 7, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
line 9, in <module>
AttributeError: 'module' object has no attribute 'mpmath'

>>>import sympy.mpmath.libmp as libmp

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
line 34, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
line 2, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
line 323, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
line 93, in wrapper
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
line 185, in __new__
ImportError: No module named fancysets

>>>from sympy.sets.fancysets import Naturals0

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
line 32, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\__init__.py",
line 8, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
line 7, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
line 9, in <module>
AttributeError: 'module' object has no attribute 'mpmath'


>>>sys.path

['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
'../../PythonLib']
========================================================

-- 
Andy
PGP Key ID: 0xDC1B5864

From andreas.beham at heuristiclab.com  Mon Apr  7 13:58:23 2014
From: andreas.beham at heuristiclab.com (Andreas Beham)
Date: Mon, 7 Apr 2014 13:58:23 +0200
Subject: [Ironpython-users] SymPy and IronPython 2.7.4
In-Reply-To: <534277DB.8090809@britishideas.com>
References: <534277DB.8090809@britishideas.com>
Message-ID: <000301cf5258$ad8b4920$08a1db60$@heuristiclab.com>

Hi,

I've not had problems running SimPy samples with IronPython. In fact, I
copied the MachineShop sample from their page and added it to a Python
project in VS2013 (you need to have PythonTools for Visual Studio installed
to do this). I could run that Python project without problems. I also ran
the model within our own environment in which I integrated IronPython-based
script execution recently. I could run the model without problems. Of course
you have to do some imports first:
import sys
sys.path.append(r"C:\Program Files (x86)\IronPython 2.7\Lib")
sys.path.append(r"C:\somepath\simpy-3.0.3")

Btw, I've also created a .NET port of SimPy, named SimSharp, which you might
be interested in:
https://github.com/abeham/SimSharp
It's not a 1:1 port, but I tried to port the basic concept of using an
iterator to model a process.

Sincerely,
Andreas

-----Urspr?ngliche Nachricht-----
Von: Ironpython-users
[mailto:ironpython-users-bounces+andreas.beham=heuristiclab.com at python.org]
Im Auftrag von Andrew Ayre
Gesendet: Montag, 07. April 2014 12:03
An: ironpython-users at python.org
Betreff: [Ironpython-users] SymPy and IronPython 2.7.4

Hello,

I have embedded IronPython 2.7.4 into a .NET 4.0 C# application. I can enter
and run scripts and I also have an interactive console. It's working great
and I have no issues... until I tried to use SymPy.

I've asked for help from the SymPy people but they don't have any experience
with IronPython.

I have a subfolder called PythonLib into which I have copied the 2.7
standard libraries. Importing from these works:

========================================================
>>>import xml.dom
>>>
========================================================

So I have copied SymPy into PythonLib as well (e.g. I have
\PythonLib\sympy\__init__.py).

Here is the first issue:

========================================================
>>>import sympy

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
line 32, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy
\core\__init__.py", line 8, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
line 7, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
line 27, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\containers.py",
line 14, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\utilities\__init__.py",
line 17, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\utilities\timeutils.py",
line 11, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\compatibility.py",
line 110, in u
TypeError: unicode_escape_decode() takes no arguments (1 given)
========================================================

I can't find any description of what unicode_escape_decode does. It seems to
be a built-in function? In general SymPy is passing a string to it to be
decoded so it appears to make sense that the function has an argument.

I've worked around this with the following:

========================================================
>>>import codecs
>>>def my_unicode_escape_decode(x):
...    return x
...
>>>codecs.unicode_escape_decode = my_unicode_escape_decode
========================================================

Now I get attribute errors. Here is the result of running several imports.
Can anyone please give me some pointers as to what might be the issue? I'm
thinking it is something to do with my environment or the way I am embedded
IronPython. Thanks! Andy

========================================================
>>>import sympy

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
line 32, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\__init__.py",
line 8, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
line 7, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
line 9, in <module>
AttributeError: 'module' object has no attribute 'mpmath'

>>>import sympy.mpmath.libmp as libmp

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
line 34, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
line 2, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
line 323, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
line 93, in wrapper
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
line 185, in __new__
ImportError: No module named fancysets

>>>from sympy.sets.fancysets import Naturals0

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
line 32, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\__init__.py",
line 8, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
line 7, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
line 9, in <module>
AttributeError: 'module' object has no attribute 'mpmath'


>>>sys.path

['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
'../../PythonLib']
========================================================

--
Andy
PGP Key ID: 0xDC1B5864
_______________________________________________
Ironpython-users mailing list
Ironpython-users at python.org
https://mail.python.org/mailman/listinfo/ironpython-users


From andy at britishideas.com  Mon Apr  7 14:47:17 2014
From: andy at britishideas.com (Andrew Ayre)
Date: Mon, 07 Apr 2014 13:47:17 +0100
Subject: [Ironpython-users] SymPy and IronPython 2.7.4
In-Reply-To: <000301cf5258$ad8b4920$08a1db60$@heuristiclab.com>
References: <534277DB.8090809@britishideas.com>
 <000301cf5258$ad8b4920$08a1db60$@heuristiclab.com>
Message-ID: <53429E55.4060709@britishideas.com>

Hi,

I was all excited for a moment... until I realized that there are two
projects called SymPy(!).

The one I am trying to use is currently at 0.7.5 and is for symbolic
computation:

http://sympy.org/en/index.html

:(

Andreas - thanks for replying, I appreciate it.

Andy

On 4/7/2014 12:58 PM, Andreas Beham wrote:
> Hi,
> 
> I've not had problems running SimPy samples with IronPython. In fact, I
> copied the MachineShop sample from their page and added it to a Python
> project in VS2013 (you need to have PythonTools for Visual Studio installed
> to do this). I could run that Python project without problems. I also ran
> the model within our own environment in which I integrated IronPython-based
> script execution recently. I could run the model without problems. Of course
> you have to do some imports first:
> import sys
> sys.path.append(r"C:\Program Files (x86)\IronPython 2.7\Lib")
> sys.path.append(r"C:\somepath\simpy-3.0.3")
> 
> Btw, I've also created a .NET port of SimPy, named SimSharp, which you might
> be interested in:
> https://github.com/abeham/SimSharp
> It's not a 1:1 port, but I tried to port the basic concept of using an
> iterator to model a process.
> 
> Sincerely,
> Andreas
> 
> -----Urspr?ngliche Nachricht-----
> Von: Ironpython-users
> [mailto:ironpython-users-bounces+andreas.beham=heuristiclab.com at python.org]
> Im Auftrag von Andrew Ayre
> Gesendet: Montag, 07. April 2014 12:03
> An: ironpython-users at python.org
> Betreff: [Ironpython-users] SymPy and IronPython 2.7.4
> 
> Hello,
> 
> I have embedded IronPython 2.7.4 into a .NET 4.0 C# application. I can enter
> and run scripts and I also have an interactive console. It's working great
> and I have no issues... until I tried to use SymPy.
> 
> I've asked for help from the SymPy people but they don't have any experience
> with IronPython.
> 
> I have a subfolder called PythonLib into which I have copied the 2.7
> standard libraries. Importing from these works:
> 
> ========================================================
>>>> import xml.dom
>>>>
> ========================================================
> 
> So I have copied SymPy into PythonLib as well (e.g. I have
> \PythonLib\sympy\__init__.py).
> 
> Here is the first issue:
> 
> ========================================================
>>>> import sympy
> 
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
> line 32, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy
> \core\__init__.py", line 8, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
> line 7, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
> line 27, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\containers.py",
> line 14, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\utilities\__init__.py",
> line 17, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\utilities\timeutils.py",
> line 11, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\compatibility.py",
> line 110, in u
> TypeError: unicode_escape_decode() takes no arguments (1 given)
> ========================================================
> 
> I can't find any description of what unicode_escape_decode does. It seems to
> be a built-in function? In general SymPy is passing a string to it to be
> decoded so it appears to make sense that the function has an argument.
> 
> I've worked around this with the following:
> 
> ========================================================
>>>> import codecs
>>>> def my_unicode_escape_decode(x):
> ...    return x
> ...
>>>> codecs.unicode_escape_decode = my_unicode_escape_decode
> ========================================================
> 
> Now I get attribute errors. Here is the result of running several imports.
> Can anyone please give me some pointers as to what might be the issue? I'm
> thinking it is something to do with my environment or the way I am embedded
> IronPython. Thanks! Andy
> 
> ========================================================
>>>> import sympy
> 
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
> line 32, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\__init__.py",
> line 8, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
> line 7, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
> line 9, in <module>
> AttributeError: 'module' object has no attribute 'mpmath'
> 
>>>> import sympy.mpmath.libmp as libmp
> 
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
> line 34, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
> line 2, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
> line 323, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
> line 93, in wrapper
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
> line 185, in __new__
> ImportError: No module named fancysets
> 
>>> >from sympy.sets.fancysets import Naturals0
> 
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
> line 32, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\__init__.py",
> line 8, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
> line 7, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
> line 9, in <module>
> AttributeError: 'module' object has no attribute 'mpmath'
> 
> 
>>>> sys.path
> 
> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
> '../../PythonLib']
> ========================================================
> 
> --
> Andy
> PGP Key ID: 0xDC1B5864
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
> 
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
> 
> 
> 

-- 
Andy
PGP Key ID: 0xDC1B5864

From pawel.jasinski at gmail.com  Mon Apr  7 20:42:06 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Mon, 7 Apr 2014 20:42:06 +0200
Subject: [Ironpython-users] SymPy and IronPython 2.7.4
In-Reply-To: <534277DB.8090809@britishideas.com>
References: <534277DB.8090809@britishideas.com>
Message-ID: <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>

this looks like https://ironpython.codeplex.com/workitem/34551 which
is fixed post 2.7.4.
Can you try 2.7.5b1 https://ironpython.codeplex.com/releases/view/115611 ?

On Mon, Apr 7, 2014 at 12:03 PM, Andrew Ayre <andy at britishideas.com> wrote:
> Hello,
>
> I have embedded IronPython 2.7.4 into a .NET 4.0 C# application. I can
> enter and run scripts and I also have an interactive console. It's
> working great and I have no issues... until I tried to use SymPy.
>
> I've asked for help from the SymPy people but they don't have any
> experience with IronPython.
>
> I have a subfolder called PythonLib into which I have copied the 2.7
> standard libraries. Importing from these works:
>
> ========================================================
>>>>import xml.dom
>>>>
> ========================================================
>
> So I have copied SymPy into PythonLib as well (e.g. I have
> \PythonLib\sympy\__init__.py).
>
> Here is the first issue:
>
> ========================================================
>>>>import sympy
>
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
> line 32, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy
> \core\__init__.py", line 8, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
> line 7, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
> line 27, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\containers.py",
> line 14, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\utilities\__init__.py", line
> 17, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\utilities\timeutils.py",
> line 11, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\compatibility.py", line
> 110, in u
> TypeError: unicode_escape_decode() takes no arguments (1 given)
> ========================================================
>
> I can't find any description of what unicode_escape_decode does. It
> seems to be a built-in function? In general SymPy is passing a string to
> it to be decoded so it appears to make sense that the function has an
> argument.
>
> I've worked around this with the following:
>
> ========================================================
>>>>import codecs
>>>>def my_unicode_escape_decode(x):
> ...    return x
> ...
>>>>codecs.unicode_escape_decode = my_unicode_escape_decode
> ========================================================
>
> Now I get attribute errors. Here is the result of running several
> imports. Can anyone please give me some pointers as to what might be the
> issue? I'm thinking it is something to do with my environment or the way
> I am embedded IronPython. Thanks! Andy
>
> ========================================================
>>>>import sympy
>
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
> line 32, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\__init__.py",
> line 8, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
> line 7, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
> line 9, in <module>
> AttributeError: 'module' object has no attribute 'mpmath'
>
>>>>import sympy.mpmath.libmp as libmp
>
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
> line 34, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
> line 2, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
> line 323, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
> line 93, in wrapper
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
> line 185, in __new__
> ImportError: No module named fancysets
>
>>>>from sympy.sets.fancysets import Naturals0
>
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
> line 32, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\__init__.py",
> line 8, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
> line 7, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
> line 9, in <module>
> AttributeError: 'module' object has no attribute 'mpmath'
>
>
>>>>sys.path
>
> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
> '../../PythonLib']
> ========================================================
>
> --
> Andy
> PGP Key ID: 0xDC1B5864
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users

From andy at britishideas.com  Mon Apr  7 23:16:33 2014
From: andy at britishideas.com (Andrew Ayre)
Date: Mon, 07 Apr 2014 22:16:33 +0100
Subject: [Ironpython-users] SymPy and IronPython 2.7.4
In-Reply-To: <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
References: <534277DB.8090809@britishideas.com>
 <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
Message-ID: <534315B1.5050907@britishideas.com>

Thanks. Unfortunately I still get the error:

=============================================
>>>import sympy

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
line 32, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\__init__.py",
line 8, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
line 7, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
line 9, in <module>
AttributeError: 'module' object has no attribute 'mpmath'
=============================================

Note that IronPython 2.7.5b1 is showing version 2.7.0.40 in my console,
but IronPython.dll in the same folder as my exe shows 2.7.5b1 in the
Windows Explorer properties.

Andy

On 4/7/2014 7:42 PM, Pawel Jasinski wrote:
> this looks like https://ironpython.codeplex.com/workitem/34551 which
> is fixed post 2.7.4.
> Can you try 2.7.5b1 https://ironpython.codeplex.com/releases/view/115611 ?
> 
> On Mon, Apr 7, 2014 at 12:03 PM, Andrew Ayre <andy at britishideas.com> wrote:
>> Hello,
>>
>> I have embedded IronPython 2.7.4 into a .NET 4.0 C# application. I can
>> enter and run scripts and I also have an interactive console. It's
>> working great and I have no issues... until I tried to use SymPy.
>>
>> I've asked for help from the SymPy people but they don't have any
>> experience with IronPython.
>>
>> I have a subfolder called PythonLib into which I have copied the 2.7
>> standard libraries. Importing from these works:
>>
>> ========================================================
>>>>> import xml.dom
>>>>>
>> ========================================================
>>
>> So I have copied SymPy into PythonLib as well (e.g. I have
>> \PythonLib\sympy\__init__.py).
>>
>> Here is the first issue:
>>
>> ========================================================
>>>>> import sympy
>>
>> Traceback (most recent call last):
>>   File "<string>", line 1, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
>> line 32, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy
>> \core\__init__.py", line 8, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
>> line 7, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
>> line 27, in <module>
>>   File
>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\containers.py",
>> line 14, in <module>
>>   File
>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\utilities\__init__.py", line
>> 17, in <module>
>>   File
>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\utilities\timeutils.py",
>> line 11, in <module>
>>   File
>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\compatibility.py", line
>> 110, in u
>> TypeError: unicode_escape_decode() takes no arguments (1 given)
>> ========================================================
>>
>> I can't find any description of what unicode_escape_decode does. It
>> seems to be a built-in function? In general SymPy is passing a string to
>> it to be decoded so it appears to make sense that the function has an
>> argument.
>>
>> I've worked around this with the following:
>>
>> ========================================================
>>>>> import codecs
>>>>> def my_unicode_escape_decode(x):
>> ...    return x
>> ...
>>>>> codecs.unicode_escape_decode = my_unicode_escape_decode
>> ========================================================
>>
>> Now I get attribute errors. Here is the result of running several
>> imports. Can anyone please give me some pointers as to what might be the
>> issue? I'm thinking it is something to do with my environment or the way
>> I am embedded IronPython. Thanks! Andy
>>
>> ========================================================
>>>>> import sympy
>>
>> Traceback (most recent call last):
>>   File "<string>", line 1, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
>> line 32, in <module>
>>   File
>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\__init__.py",
>> line 8, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
>> line 7, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
>> line 9, in <module>
>> AttributeError: 'module' object has no attribute 'mpmath'
>>
>>>>> import sympy.mpmath.libmp as libmp
>>
>> Traceback (most recent call last):
>>   File "<string>", line 1, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
>> line 34, in <module>
>>   File
>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
>> line 2, in <module>
>>   File
>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
>> line 323, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
>> line 93, in wrapper
>>   File
>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
>> line 185, in __new__
>> ImportError: No module named fancysets
>>
>>>> >from sympy.sets.fancysets import Naturals0
>>
>> Traceback (most recent call last):
>>   File "<string>", line 1, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
>> line 32, in <module>
>>   File
>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\__init__.py",
>> line 8, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
>> line 7, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
>> line 9, in <module>
>> AttributeError: 'module' object has no attribute 'mpmath'
>>
>>
>>>>> sys.path
>>
>> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
>> '../../PythonLib']
>> ========================================================
>>
>> --
>> Andy
>> PGP Key ID: 0xDC1B5864
>> _______________________________________________
>> Ironpython-users mailing list
>> Ironpython-users at python.org
>> https://mail.python.org/mailman/listinfo/ironpython-users
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
> 
> 
> 

-- 
Andy
PGP Key ID: 0xDC1B5864

From jdhardy at gmail.com  Tue Apr  8 00:32:17 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Mon, 7 Apr 2014 23:32:17 +0100
Subject: [Ironpython-users] SymPy and IronPython 2.7.4
In-Reply-To: <534315B1.5050907@britishideas.com>
References: <534277DB.8090809@britishideas.com>
 <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
 <534315B1.5050907@britishideas.com>
Message-ID: <CAF7AXFHKnXVTiO4pV6zZ2izMU3Mmk504Ow+=Wn2Pg4_yF4=YhQ@mail.gmail.com>

On Mon, Apr 7, 2014 at 10:16 PM, Andrew Ayre <andy at britishideas.com> wrote:
> Thanks. Unfortunately I still get the error:
>
> =============================================
>>>>import sympy
>
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
> line 32, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\__init__.py",
> line 8, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
> line 7, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
> line 9, in <module>
> AttributeError: 'module' object has no attribute 'mpmath'
> =============================================

You need to make sure the mpmath library is in sys.path as well; I
don't know if SymPy includes it.

>
> Note that IronPython 2.7.5b1 is showing version 2.7.0.40 in my console,
> but IronPython.dll in the same folder as my exe shows 2.7.5b1 in the
> Windows Explorer properties.

Yeah, 2.7.0.40 is the assembly version; for weird .NET-specific
reasons it never changes.

- Jeff

From andy at britishideas.com  Tue Apr  8 10:08:59 2014
From: andy at britishideas.com (Andrew Ayre)
Date: Tue, 08 Apr 2014 09:08:59 +0100
Subject: [Ironpython-users] SymPy and IronPython 2.7.4
In-Reply-To: <CAF7AXFHKnXVTiO4pV6zZ2izMU3Mmk504Ow+=Wn2Pg4_yF4=YhQ@mail.gmail.com>
References: <534277DB.8090809@britishideas.com>
 <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
 <534315B1.5050907@britishideas.com>
 <CAF7AXFHKnXVTiO4pV6zZ2izMU3Mmk504Ow+=Wn2Pg4_yF4=YhQ@mail.gmail.com>
Message-ID: <5343AE9B.90205@britishideas.com>

On 4/7/2014 11:32 PM, Jeff Hardy wrote:
> On Mon, Apr 7, 2014 at 10:16 PM, Andrew Ayre <andy at britishideas.com> wrote:
>> Thanks. Unfortunately I still get the error:
>>
>> =============================================
>>>>> import sympy
>>
>> Traceback (most recent call last):
>>   File "<string>", line 1, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
>> line 32, in <module>
>>   File
>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\__init__.py",
>> line 8, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\expr.py",
>> line 7, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\evalf.py",
>> line 9, in <module>
>> AttributeError: 'module' object has no attribute 'mpmath'
>> =============================================
> 
> You need to make sure the mpmath library is in sys.path as well; I
> don't know if SymPy includes it.

Thanks. Making progress... Now it can't find sympy.sets.fancysets. I've
added the folder where the module is defined to sys.path:

=============================================
>>>sys.path.append('../../PythonLib/sympy/sets')

>>>sys.path

['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
'../../PythonLib', '../../PythonLib', '../../PythonLib/sympy/mpmath',
'../../PythonLib/sympy/sets']

>>>from sympy.sets.fancysets import Naturals0

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
line 34, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
line 2, in <module>
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
line 323, in <module>
  File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
line 93, in wrapper
  File
"C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
line 185, in __new__
ImportError: No module named fancysets
=============================================

Here is what the folder structure looks like:

https://github.com/sympy/sympy/tree/master/sympy/sets

Andy

From jdhardy at gmail.com  Tue Apr  8 11:28:22 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Tue, 8 Apr 2014 10:28:22 +0100
Subject: [Ironpython-users] SymPy and IronPython 2.7.4
In-Reply-To: <5343AE9B.90205@britishideas.com>
References: <534277DB.8090809@britishideas.com>
 <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
 <534315B1.5050907@britishideas.com>
 <CAF7AXFHKnXVTiO4pV6zZ2izMU3Mmk504Ow+=Wn2Pg4_yF4=YhQ@mail.gmail.com>
 <5343AE9B.90205@britishideas.com>
Message-ID: <CAF7AXFFK_hYdDi=H1RXvF8+ZtYYJ-8hx5sEzettbKuR1Ych8Fg@mail.gmail.com>

On Tue, Apr 8, 2014 at 9:08 AM, Andrew Ayre <andy at britishideas.com> wrote:
> Thanks. Making progress... Now it can't find sympy.sets.fancysets. I've
> added the folder where the module is defined to sys.path:
>
> =============================================
>>>>sys.path.append('../../PythonLib/sympy/sets')
>
>>>>sys.path
>
> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
> '../../PythonLib', '../../PythonLib', '../../PythonLib/sympy/mpmath',
> '../../PythonLib/sympy/sets']
>
>>>>from sympy.sets.fancysets import Naturals0
>
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
> line 34, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
> line 2, in <module>
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
> line 323, in <module>
>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
> line 93, in wrapper
>   File
> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
> line 185, in __new__
> ImportError: No module named fancysets
> =============================================
>
> Here is what the folder structure looks like:
>
> https://github.com/sympy/sympy/tree/master/sympy/sets

Which version of IronPython? It sure looks like the import bug, but if
you're still hitting in 2.7.5b1 then we'll have to reopen it.

- Jeff

From andy at britishideas.com  Tue Apr  8 11:51:14 2014
From: andy at britishideas.com (Andrew Ayre)
Date: Tue, 08 Apr 2014 10:51:14 +0100
Subject: [Ironpython-users] SymPy and IronPython 2.7.4
In-Reply-To: <CAF7AXFFK_hYdDi=H1RXvF8+ZtYYJ-8hx5sEzettbKuR1Ych8Fg@mail.gmail.com>
References: <534277DB.8090809@britishideas.com>
 <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
 <534315B1.5050907@britishideas.com>
 <CAF7AXFHKnXVTiO4pV6zZ2izMU3Mmk504Ow+=Wn2Pg4_yF4=YhQ@mail.gmail.com>
 <5343AE9B.90205@britishideas.com>
 <CAF7AXFFK_hYdDi=H1RXvF8+ZtYYJ-8hx5sEzettbKuR1Ych8Fg@mail.gmail.com>
Message-ID: <5343C692.4030509@britishideas.com>

On 4/8/2014 10:28 AM, Jeff Hardy wrote:
> On Tue, Apr 8, 2014 at 9:08 AM, Andrew Ayre <andy at britishideas.com> wrote:
>> Thanks. Making progress... Now it can't find sympy.sets.fancysets. I've
>> added the folder where the module is defined to sys.path:
>>
>> =============================================
>>>>> sys.path.append('../../PythonLib/sympy/sets')
>>
>>>>> sys.path
>>
>> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
>> '../../PythonLib', '../../PythonLib', '../../PythonLib/sympy/mpmath',
>> '../../PythonLib/sympy/sets']
>>
>>>> >from sympy.sets.fancysets import Naturals0
>>
>> Traceback (most recent call last):
>>   File "<string>", line 1, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
>> line 34, in <module>
>>   File
>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
>> line 2, in <module>
>>   File
>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
>> line 323, in <module>
>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
>> line 93, in wrapper
>>   File
>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
>> line 185, in __new__
>> ImportError: No module named fancysets
>> =============================================
>>
>> Here is what the folder structure looks like:
>>
>> https://github.com/sympy/sympy/tree/master/sympy/sets
> 
> Which version of IronPython? It sure looks like the import bug, but if
> you're still hitting in 2.7.5b1 then we'll have to reopen it.

Jeff,

Here is my sanity check:

=============================================
>>>sys.version

'2.7.5b1 (IronPython 2.7.5b1 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit))'
=============================================

I'm using the pre-compiled binary version.

Thanks, Andy

-- 
Andy
PGP Key ID: 0xDC1B5864

From jkf359 at gmail.com  Tue Apr  8 18:02:38 2014
From: jkf359 at gmail.com (John Fullmer)
Date: Tue, 8 Apr 2014 10:02:38 -0600
Subject: [Ironpython-users] Item 34263 in 2.7.5?
Message-ID: <CA+8vhsM_wj012mKqyQLGLis7SWruz9uaw8v43kn0xmGEF9Mbow@mail.gmail.com>

Could we add this in 2.7.5?

http://ironpython.codeplex.com/workitem/34263

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140408/4d0ea1c9/attachment.html>

From no_reply at codeplex.com  Wed Apr  9 09:24:21 2014
From: no_reply at codeplex.com (CodePlex)
Date: 9 Apr 2014 00:24:21 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/8/2014
Message-ID: <CO1MSDNADMCDS2vXee40001ba4d@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] Enable Frames by default
2. [New issue] .NET and COM InterOp issues in IronPython

----------------------------------------------

ISSUES

1. [New comment] Enable Frames by default
http://ironpython.codeplex.com/workitem/34263
User jkf35 has commented on the issue:

"<p>Can we possibly add this in 2.7.5?  </p>"-----------------

2. [New issue] .NET and COM InterOp issues in IronPython
http://ironpython.codeplex.com/workitem/35113
User PlexCUser has proposed the issue:

"IronPython COM interop Vs C#/F# 
 
It appears as though one has to call COM Interface?s method explicitly in IronPython, where as methods/properties are automatically detected in C#/F#.
Is there any setting/option in IronPython to make it work similar to C#/F# for COM interop?

Unable to do the following with early binding in IronPython
Marshal.GetActiveObject("Vendor.Application").XXX.YYY, whereas this is possible in both C# and F#.
Intellisense also works fine with C#/F# in VS2013, but not with IronPython.

(Tried all the three different methods described in http://ironpython.net/documentation/dotnet/dotnet.html, Creating COM object, but the issue remains)

C#:
// Add COM typelib reference
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using VendorTypeLibNS;
using System.Runtime.InteropServices;

namespace CustomNS
{
class Program
{
    static void Main(string[] args)
    {

// PLEASE NOTE that intellisense works on any of the followng statements without any issues.
        Application app = (Application)Marshal.GetActiveObject("Vendor.Application");
        Console.WriteLine (app.secondLevelComObject.someStringProperty);
    }
}

}

F#
r "C:\Temp\ Interop.Vendor.dll"
open VendorTypeLibNs
open System.Runtime.InteropServices
let app  = Marshal.GetActiveObject("Vendor.Application"):?> VendorTypeLibNs.Application
let strProp = app.secondLevelComObject.someStringProperty

IronPython



import clr
import sys
from System.Runtime.InteropServices import Marshal
clr.AddReference("Interop.Vendor") // after updating sys.path with append
app = Marshal.GetActiveObject("Vendor.Application")
comObj2 = Application. secondLevelComObject.GetValue(app)
SecondLevelComObjectType.SecondLevelComObjectStringProp.GetValue(aDoc)
'Some String?



Unable to do the following in IronPython:
App.secondLevelComObject.someStringProperty

From InterOp DLL
Application is an Interface
secondLevelComObject is also an interface (which a property on application)
secondLevelComObject is a property on secondLevelComObject


Thank you."
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140409/4d2343db/attachment.html>

From jdhardy at gmail.com  Wed Apr  9 09:58:14 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 9 Apr 2014 08:58:14 +0100
Subject: [Ironpython-users] Item 34263 in 2.7.5?
In-Reply-To: <CA+8vhsM_wj012mKqyQLGLis7SWruz9uaw8v43kn0xmGEF9Mbow@mail.gmail.com>
References: <CA+8vhsM_wj012mKqyQLGLis7SWruz9uaw8v43kn0xmGEF9Mbow@mail.gmail.com>
Message-ID: <CAF7AXFGdq1Au9xfe9UNj9oZ2+ZOncznXQU_-8C70y-pFW8y1SA@mail.gmail.com>

On Tue, Apr 8, 2014 at 5:02 PM, John Fullmer <jkf359 at gmail.com> wrote:
> Could we add this in 2.7.5?
>
> http://ironpython.codeplex.com/workitem/34263

I think changing the defaults for ipy.exe in a point release is too
big a change. It'll have to wait for the next major release.

- Jeff

From andy at britishideas.com  Wed Apr  9 10:07:24 2014
From: andy at britishideas.com (Andrew Ayre)
Date: Wed, 09 Apr 2014 09:07:24 +0100
Subject: [Ironpython-users] SymPy and IronPython 2.7.4
In-Reply-To: <CA+7conmvb4TY+=q=ggFZLfQeBw9ijD0Jani4BRVe3NU1n88gFA@mail.gmail.com>
References: <534277DB.8090809@britishideas.com>
 <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
 <534315B1.5050907@britishideas.com>
 <CAF7AXFHKnXVTiO4pV6zZ2izMU3Mmk504Ow+=Wn2Pg4_yF4=YhQ@mail.gmail.com>
 <5343AE9B.90205@britishideas.com>
 <CAF7AXFFK_hYdDi=H1RXvF8+ZtYYJ-8hx5sEzettbKuR1Ych8Fg@mail.gmail.com>
 <5343C692.4030509@britishideas.com>
 <CA+7conmvb4TY+=q=ggFZLfQeBw9ijD0Jani4BRVe3NU1n88gFA@mail.gmail.com>
Message-ID: <5344FFBC.7060701@britishideas.com>

OK. Is there a workaround I can use?

Andy

On 4/8/2014 8:04 PM, Pawel Jasinski wrote:
> It looks like the import bug, but is different.
> This time imported is confusing already imported:  sympy.core.sets
> with sympy.sets. Is is looking for  sympy.sets.fancysets in sympty.core.sets
> 
> On Tue, Apr 8, 2014 at 11:51 AM, Andrew Ayre <andy at britishideas.com> wrote:
>> On 4/8/2014 10:28 AM, Jeff Hardy wrote:
>>> On Tue, Apr 8, 2014 at 9:08 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>> Thanks. Making progress... Now it can't find sympy.sets.fancysets. I've
>>>> added the folder where the module is defined to sys.path:
>>>>
>>>> =============================================
>>>>>>> sys.path.append('../../PythonLib/sympy/sets')
>>>>
>>>>>>> sys.path
>>>>
>>>> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
>>>> '../../PythonLib', '../../PythonLib', '../../PythonLib/sympy/mpmath',
>>>> '../../PythonLib/sympy/sets']
>>>>
>>>>>> >from sympy.sets.fancysets import Naturals0
>>>>
>>>> Traceback (most recent call last):
>>>>   File "<string>", line 1, in <module>
>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
>>>> line 34, in <module>
>>>>   File
>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
>>>> line 2, in <module>
>>>>   File
>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
>>>> line 323, in <module>
>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
>>>> line 93, in wrapper
>>>>   File
>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
>>>> line 185, in __new__
>>>> ImportError: No module named fancysets
>>>> =============================================
>>>>
>>>> Here is what the folder structure looks like:
>>>>
>>>> https://github.com/sympy/sympy/tree/master/sympy/sets
>>>
>>> Which version of IronPython? It sure looks like the import bug, but if
>>> you're still hitting in 2.7.5b1 then we'll have to reopen it.
>>
>> Jeff,
>>
>> Here is my sanity check:
>>
>> =============================================
>>>>> sys.version
>>
>> '2.7.5b1 (IronPython 2.7.5b1 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit))'
>> =============================================
>>
>> I'm using the pre-compiled binary version.
>>
>> Thanks, Andy
>>
>> --
>> Andy
>> PGP Key ID: 0xDC1B5864
>> _______________________________________________
>> Ironpython-users mailing list
>> Ironpython-users at python.org
>> https://mail.python.org/mailman/listinfo/ironpython-users
> 
> 
> 

-- 
Andy
PGP Key ID: 0xDC1B5864

From pawel.jasinski at gmail.com  Wed Apr  9 10:44:24 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Wed, 9 Apr 2014 10:44:24 +0200
Subject: [Ironpython-users] SymPy and IronPython 2.7.4
In-Reply-To: <5344FFBC.7060701@britishideas.com>
References: <534277DB.8090809@britishideas.com>
 <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
 <534315B1.5050907@britishideas.com>
 <CAF7AXFHKnXVTiO4pV6zZ2izMU3Mmk504Ow+=Wn2Pg4_yF4=YhQ@mail.gmail.com>
 <5343AE9B.90205@britishideas.com>
 <CAF7AXFFK_hYdDi=H1RXvF8+ZtYYJ-8hx5sEzettbKuR1Ych8Fg@mail.gmail.com>
 <5343C692.4030509@britishideas.com>
 <CA+7conmvb4TY+=q=ggFZLfQeBw9ijD0Jani4BRVe3NU1n88gFA@mail.gmail.com>
 <5344FFBC.7060701@britishideas.com>
Message-ID: <CA+7conmcfdEr_RSJwe4kidDWvGuLOFSp2xvNZ4e7+dMLWe=OSg@mail.gmail.com>

comment the following line out in sympy/__init__.py
from .core import *
but, I can see already another import error.
--pawel



On Wed, Apr 9, 2014 at 10:07 AM, Andrew Ayre <andy at britishideas.com> wrote:
> OK. Is there a workaround I can use?
>
> Andy
>
> On 4/8/2014 8:04 PM, Pawel Jasinski wrote:
>> It looks like the import bug, but is different.
>> This time imported is confusing already imported:  sympy.core.sets
>> with sympy.sets. Is is looking for  sympy.sets.fancysets in sympty.core.sets
>>
>> On Tue, Apr 8, 2014 at 11:51 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>> On 4/8/2014 10:28 AM, Jeff Hardy wrote:
>>>> On Tue, Apr 8, 2014 at 9:08 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>> Thanks. Making progress... Now it can't find sympy.sets.fancysets. I've
>>>>> added the folder where the module is defined to sys.path:
>>>>>
>>>>> =============================================
>>>>>>>> sys.path.append('../../PythonLib/sympy/sets')
>>>>>
>>>>>>>> sys.path
>>>>>
>>>>> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
>>>>> '../../PythonLib', '../../PythonLib', '../../PythonLib/sympy/mpmath',
>>>>> '../../PythonLib/sympy/sets']
>>>>>
>>>>>>> >from sympy.sets.fancysets import Naturals0
>>>>>
>>>>> Traceback (most recent call last):
>>>>>   File "<string>", line 1, in <module>
>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
>>>>> line 34, in <module>
>>>>>   File
>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
>>>>> line 2, in <module>
>>>>>   File
>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
>>>>> line 323, in <module>
>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
>>>>> line 93, in wrapper
>>>>>   File
>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
>>>>> line 185, in __new__
>>>>> ImportError: No module named fancysets
>>>>> =============================================
>>>>>
>>>>> Here is what the folder structure looks like:
>>>>>
>>>>> https://github.com/sympy/sympy/tree/master/sympy/sets
>>>>
>>>> Which version of IronPython? It sure looks like the import bug, but if
>>>> you're still hitting in 2.7.5b1 then we'll have to reopen it.
>>>
>>> Jeff,
>>>
>>> Here is my sanity check:
>>>
>>> =============================================
>>>>>> sys.version
>>>
>>> '2.7.5b1 (IronPython 2.7.5b1 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit))'
>>> =============================================
>>>
>>> I'm using the pre-compiled binary version.
>>>
>>> Thanks, Andy
>>>
>>> --
>>> Andy
>>> PGP Key ID: 0xDC1B5864
>>> _______________________________________________
>>> Ironpython-users mailing list
>>> Ironpython-users at python.org
>>> https://mail.python.org/mailman/listinfo/ironpython-users
>>
>>
>>
>
> --
> Andy
> PGP Key ID: 0xDC1B5864

From pawel.jasinski at gmail.com  Wed Apr  9 11:24:38 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Wed, 9 Apr 2014 11:24:38 +0200
Subject: [Ironpython-users] Fwd:  SymPy and IronPython 2.7.4
In-Reply-To: <CA+7conkg26-vLAUKXz9yaGVxwsYgNj40UXvEfDD9JOv0fvODwg@mail.gmail.com>
References: <534277DB.8090809@britishideas.com>
 <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
 <534315B1.5050907@britishideas.com>
 <CAF7AXFHKnXVTiO4pV6zZ2izMU3Mmk504Ow+=Wn2Pg4_yF4=YhQ@mail.gmail.com>
 <5343AE9B.90205@britishideas.com>
 <CAF7AXFFK_hYdDi=H1RXvF8+ZtYYJ-8hx5sEzettbKuR1Ych8Fg@mail.gmail.com>
 <5343C692.4030509@britishideas.com>
 <CA+7conmvb4TY+=q=ggFZLfQeBw9ijD0Jani4BRVe3NU1n88gFA@mail.gmail.com>
 <5344FFBC.7060701@britishideas.com>
 <CA+7conkg26-vLAUKXz9yaGVxwsYgNj40UXvEfDD9JOv0fvODwg@mail.gmail.com>
Message-ID: <CA+7conm8xOSo+oaTzUdmz4W8gkJ6ZpvE2Ykb+1SnPWT+-B+7JQ@mail.gmail.com>

---------- Forwarded message ----------
From: Pawel Jasinski <pawel.jasinski at gmail.com>
Date: Wed, Apr 9, 2014 at 11:02 AM
Subject: Re: [Ironpython-users] SymPy and IronPython 2.7.4
To: Andrew Ayre <andy at britishideas.com>


Here is the workaround which let me install the package:

*** sympy/__init__.py.orig      2014-04-09 10:59:53.361779800 +0200
--- sympy/__init__.py   2014-04-09 11:00:02.906734200 +0200
***************
*** 30,35 ****
--- 30,36 ----
  SYMPY_DEBUG = __sympy_debug()

  from .core import *
+ del sets
  from .logic import *
  from .assumptions import *
  from .polys import *



On Wed, Apr 9, 2014 at 10:07 AM, Andrew Ayre <andy at britishideas.com> wrote:
> OK. Is there a workaround I can use?
>
> Andy
>
> On 4/8/2014 8:04 PM, Pawel Jasinski wrote:
>> It looks like the import bug, but is different.
>> This time imported is confusing already imported:  sympy.core.sets
>> with sympy.sets. Is is looking for  sympy.sets.fancysets in sympty.core.sets
>>
>> On Tue, Apr 8, 2014 at 11:51 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>> On 4/8/2014 10:28 AM, Jeff Hardy wrote:
>>>> On Tue, Apr 8, 2014 at 9:08 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>> Thanks. Making progress... Now it can't find sympy.sets.fancysets. I've
>>>>> added the folder where the module is defined to sys.path:
>>>>>
>>>>> =============================================
>>>>>>>> sys.path.append('../../PythonLib/sympy/sets')
>>>>>
>>>>>>>> sys.path
>>>>>
>>>>> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
>>>>> '../../PythonLib', '../../PythonLib', '../../PythonLib/sympy/mpmath',
>>>>> '../../PythonLib/sympy/sets']
>>>>>
>>>>>>> >from sympy.sets.fancysets import Naturals0
>>>>>
>>>>> Traceback (most recent call last):
>>>>>   File "<string>", line 1, in <module>
>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
>>>>> line 34, in <module>
>>>>>   File
>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
>>>>> line 2, in <module>
>>>>>   File
>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
>>>>> line 323, in <module>
>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
>>>>> line 93, in wrapper
>>>>>   File
>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
>>>>> line 185, in __new__
>>>>> ImportError: No module named fancysets
>>>>> =============================================
>>>>>
>>>>> Here is what the folder structure looks like:
>>>>>
>>>>> https://github.com/sympy/sympy/tree/master/sympy/sets
>>>>
>>>> Which version of IronPython? It sure looks like the import bug, but if
>>>> you're still hitting in 2.7.5b1 then we'll have to reopen it.
>>>
>>> Jeff,
>>>
>>> Here is my sanity check:
>>>
>>> =============================================
>>>>>> sys.version
>>>
>>> '2.7.5b1 (IronPython 2.7.5b1 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit))'
>>> =============================================
>>>
>>> I'm using the pre-compiled binary version.
>>>
>>> Thanks, Andy
>>>
>>> --
>>> Andy
>>> PGP Key ID: 0xDC1B5864
>>> _______________________________________________
>>> Ironpython-users mailing list
>>> Ironpython-users at python.org
>>> https://mail.python.org/mailman/listinfo/ironpython-users
>>
>>
>>
>
> --
> Andy
> PGP Key ID: 0xDC1B5864

From pawel.jasinski at gmail.com  Wed Apr  9 11:25:16 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Wed, 9 Apr 2014 11:25:16 +0200
Subject: [Ironpython-users] Fwd:  SymPy and IronPython 2.7.4
In-Reply-To: <CA+7conm8xOSo+oaTzUdmz4W8gkJ6ZpvE2Ykb+1SnPWT+-B+7JQ@mail.gmail.com>
References: <534277DB.8090809@britishideas.com>
 <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
 <534315B1.5050907@britishideas.com>
 <CAF7AXFHKnXVTiO4pV6zZ2izMU3Mmk504Ow+=Wn2Pg4_yF4=YhQ@mail.gmail.com>
 <5343AE9B.90205@britishideas.com>
 <CAF7AXFFK_hYdDi=H1RXvF8+ZtYYJ-8hx5sEzettbKuR1Ych8Fg@mail.gmail.com>
 <5343C692.4030509@britishideas.com>
 <CA+7conmvb4TY+=q=ggFZLfQeBw9ijD0Jani4BRVe3NU1n88gFA@mail.gmail.com>
 <5344FFBC.7060701@britishideas.com>
 <CA+7conkg26-vLAUKXz9yaGVxwsYgNj40UXvEfDD9JOv0fvODwg@mail.gmail.com>
 <CA+7conm8xOSo+oaTzUdmz4W8gkJ6ZpvE2Ykb+1SnPWT+-B+7JQ@mail.gmail.com>
Message-ID: <CA+7conmB+RmUEPr+=dQUw+7BB9D2r7H=9aHvmvzc6Pg6Zxmypg@mail.gmail.com>

---------- Forwarded message ----------
From: Pawel Jasinski <pawel.jasinski at gmail.com>
Date: Wed, Apr 9, 2014 at 11:24 AM
Subject: Fwd: [Ironpython-users] SymPy and IronPython 2.7.4
To: "ironpython-users at python.org" <ironpython-users at python.org>


---------- Forwarded message ----------
From: Pawel Jasinski <pawel.jasinski at gmail.com>
Date: Wed, Apr 9, 2014 at 11:02 AM
Subject: Re: [Ironpython-users] SymPy and IronPython 2.7.4
To: Andrew Ayre <andy at britishideas.com>


Here is the workaround which let me install the package:

*** sympy/__init__.py.orig      2014-04-09 10:59:53.361779800 +0200
--- sympy/__init__.py   2014-04-09 11:00:02.906734200 +0200
***************
*** 30,35 ****
--- 30,36 ----
  SYMPY_DEBUG = __sympy_debug()

  from .core import *
+ del sets
  from .logic import *
  from .assumptions import *
  from .polys import *



On Wed, Apr 9, 2014 at 10:07 AM, Andrew Ayre <andy at britishideas.com> wrote:
> OK. Is there a workaround I can use?
>
> Andy
>
> On 4/8/2014 8:04 PM, Pawel Jasinski wrote:
>> It looks like the import bug, but is different.
>> This time imported is confusing already imported:  sympy.core.sets
>> with sympy.sets. Is is looking for  sympy.sets.fancysets in sympty.core.sets
>>
>> On Tue, Apr 8, 2014 at 11:51 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>> On 4/8/2014 10:28 AM, Jeff Hardy wrote:
>>>> On Tue, Apr 8, 2014 at 9:08 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>> Thanks. Making progress... Now it can't find sympy.sets.fancysets. I've
>>>>> added the folder where the module is defined to sys.path:
>>>>>
>>>>> =============================================
>>>>>>>> sys.path.append('../../PythonLib/sympy/sets')
>>>>>
>>>>>>>> sys.path
>>>>>
>>>>> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
>>>>> '../../PythonLib', '../../PythonLib', '../../PythonLib/sympy/mpmath',
>>>>> '../../PythonLib/sympy/sets']
>>>>>
>>>>>>> >from sympy.sets.fancysets import Naturals0
>>>>>
>>>>> Traceback (most recent call last):
>>>>>   File "<string>", line 1, in <module>
>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
>>>>> line 34, in <module>
>>>>>   File
>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
>>>>> line 2, in <module>
>>>>>   File
>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
>>>>> line 323, in <module>
>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
>>>>> line 93, in wrapper
>>>>>   File
>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
>>>>> line 185, in __new__
>>>>> ImportError: No module named fancysets
>>>>> =============================================
>>>>>
>>>>> Here is what the folder structure looks like:
>>>>>
>>>>> https://github.com/sympy/sympy/tree/master/sympy/sets
>>>>
>>>> Which version of IronPython? It sure looks like the import bug, but if
>>>> you're still hitting in 2.7.5b1 then we'll have to reopen it.
>>>
>>> Jeff,
>>>
>>> Here is my sanity check:
>>>
>>> =============================================
>>>>>> sys.version
>>>
>>> '2.7.5b1 (IronPython 2.7.5b1 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit))'
>>> =============================================
>>>
>>> I'm using the pre-compiled binary version.
>>>
>>> Thanks, Andy
>>>
>>> --
>>> Andy
>>> PGP Key ID: 0xDC1B5864
>>> _______________________________________________
>>> Ironpython-users mailing list
>>> Ironpython-users at python.org
>>> https://mail.python.org/mailman/listinfo/ironpython-users
>>
>>
>>
>
> --
> Andy
> PGP Key ID: 0xDC1B5864

From pawel.jasinski at gmail.com  Wed Apr  9 14:00:17 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Wed, 9 Apr 2014 14:00:17 +0200
Subject: [Ironpython-users] Fwd:  SymPy and IronPython 2.7.4
In-Reply-To: <CA+7conmS1teVcM1Gx8BZq_SzH-hn8TuckN2zk3Q0Cp4dwnj03Q@mail.gmail.com>
References: <534277DB.8090809@britishideas.com>
 <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
 <534315B1.5050907@britishideas.com>
 <CAF7AXFHKnXVTiO4pV6zZ2izMU3Mmk504Ow+=Wn2Pg4_yF4=YhQ@mail.gmail.com>
 <5343AE9B.90205@britishideas.com>
 <CAF7AXFFK_hYdDi=H1RXvF8+ZtYYJ-8hx5sEzettbKuR1Ych8Fg@mail.gmail.com>
 <5343C692.4030509@britishideas.com>
 <CA+7conmvb4TY+=q=ggFZLfQeBw9ijD0Jani4BRVe3NU1n88gFA@mail.gmail.com>
 <5344FFBC.7060701@britishideas.com>
 <CA+7conkg26-vLAUKXz9yaGVxwsYgNj40UXvEfDD9JOv0fvODwg@mail.gmail.com>
 <53450FF0.6010106@britishideas.com>
 <534510A7.80704@britishideas.com>
 <CA+7conkwt-2jG4Lc8LKJKX37qFo+aYJdRN28z9QkuP5SxDbu6A@mail.gmail.com>
 <534513C2.50904@britishideas.com>
 <53451519.3050501@britishideas.com>
 <CA+7conmS1teVcM1Gx8BZq_SzH-hn8TuckN2zk3Q0Cp4dwnj03Q@mail.gmail.com>
Message-ID: <CA+7con=vFFmmzK+MOTayBm5uTm=oWSet9h-3ksZcMJGD7fSoig@mail.gmail.com>

---------- Forwarded message ----------
From: Pawel Jasinski <pawel.jasinski at gmail.com>
Date: Wed, Apr 9, 2014 at 1:00 PM
Subject: Re: [Ironpython-users] SymPy and IronPython 2.7.4
To: Andrew Ayre <andy at britishideas.com>


What I did about unicode, is change directly in core/compatibility.py

$ diff -u compatibility.py~ compatibility.py
--- compatibility.py~   2014-02-22 20:13:32.000000000 +0100
+++ compatibility.py    2014-04-07 20:01:04.145668200 +0200
@@ -107,7 +107,8 @@
     unicode = unicode
     unichr = unichr
     def u(x):
-        return codecs.unicode_escape_decode(x)[0]
+        # return codecs.unicode_escape_decode(x)[0]
+        return x
     def u_decode(x):
         return x.decode('utf-8')


I owe you a short explanation.
IronPython is ahead of cpython in terms of unicode. All characters are
unicode character and not a byte characters.
This causes all sort of compatibility issues when cpython modules are
moved to ironpython.
But this days packages are written from day one as 2.x/3.x compatible
and contain compatibility.py or equivalent.
Most of the stuff for 2 vs. 3 can stay as it is, except the characters
conversions.
Usually the first guess is to replace things which fail, with 3.x version.
This is not perfect, but in most cases I had to deal with, is
sufficient to get going.

--pawel

On Wed, Apr 9, 2014 at 11:38 AM, Andrew Ayre <andy at britishideas.com> wrote:
> Hi Pawel,
>
> Sorry to bombard you with emails. This is interesting:
>
> The following works:
>
>  - start my application
>  - run the unicode_escape_decode workaround
>  - import sympy
>
> The following does not work:
>
>   - start my application
>   - import sympy => fails becaue of unicode_escape_decode
>   - run the unicode_escape_decode workaround
>   - import sympy => fails, can't find mpmath
>
> So perhaps the unicode_escape_decode issue and the import issue are
> connected in some way?
>
> Andy
>
> On 4/9/2014 10:32 AM, Andrew Ayre wrote:
>> Hi Pawel,
>>
>> Thanks! In my case I want to bundle it with my application so that my
>> users don't have to install it.
>>
>>  - I have turned on frames in the engine options in C#.
>>
>>  - I have put sympy into the global site-packages.
>>
>>  - I have added the global site-packages to sys.path in C#.
>>
>> Now when I start my application I can run the unicode workaround and
>> then import sympy!
>>
>> Did you also have to use the unicode_escape_decode workaround? Have you
>> any insight into what the problem is there?
>>
>> Andy
>>
>> On 4/9/2014 10:23 AM, Pawel Jasinski wrote:
>>> you can consider installing the package with:
>>>
>>> ipy.exe -X:Frames setup.py install --user
>>>
>>> which in my case put the package in:
>>> c:/Users/rejap/AppData/Roaming/Python/IronPython27/site-packages/sympy
>>> This personal site-packages is in  your sys.path by default.
>>>
>>> --pawel
>>>
>>> On Wed, Apr 9, 2014 at 11:19 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>> Hi Pawel,
>>>>
>>>> Sorry, please ignore that - I accidentally added the wrong path to sys.path.
>>>>
>>>> Thanks, Andy
>>>>
>>>> On 4/9/2014 10:16 AM, Andrew Ayre wrote:
>>>>> Hi Pawel,
>>>>>
>>>>> OK, I ran the unicode_escape_decode workaround, then I modified
>>>>> __init__.py as shown. However it seems I am back to the original
>>>>> problem. For example:
>>>>>
>>>>>>>> sys.path.append('../../PythonLib/site-packages/sympy/mpmath')
>>>>>
>>>>>>>> import sympy
>>>>>
>>>>> Traceback (most recent call last):
>>>>>   File "<string>", line 1, in <module>
>>>>>   File
>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\site-packages\sympy\__init__.py",
>>>>> line 32, in <module>
>>>>>   File
>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\site-packages\sympy\core\__init__.py",
>>>>> line 8, in <module>
>>>>>   File
>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\site-packages\sympy\core\expr.py",
>>>>> line 7, in <module>
>>>>>   File
>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\site-packages\sympy\core\evalf.py",
>>>>> line 9, in <module>
>>>>> AttributeError: 'module' object has no attribute 'mpmath'
>>>>>
>>>>> I've manually added the location of mpmath as Jeff suggested. This
>>>>> worked when I tried it before but now it doesn't.
>>>>>
>>>>> Actually the path to mpmath appears twice is sys.path so I assume sympy
>>>>> already added it and there was no need for me to add it.
>>>>>
>>>>>>>> sys.path
>>>>>
>>>>> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
>>>>> '../../PythonLib', '../../PythonLib/site-packages', '../../PythonLib',
>>>>> '../../PythonLib/sympy/mpmath',
>>>>> '../../PythonLib/site-packages/sympy/mpmath']
>>>>>
>>>>> Thanks, Andy
>>>>>
>>>>> On 4/9/2014 10:02 AM, Pawel Jasinski wrote:
>>>>>> Here is the workaround which let me install the package:
>>>>>>
>>>>>> *** sympy/__init__.py.orig      2014-04-09 10:59:53.361779800 +0200
>>>>>> --- sympy/__init__.py   2014-04-09 11:00:02.906734200 +0200
>>>>>> ***************
>>>>>> *** 30,35 ****
>>>>>> --- 30,36 ----
>>>>>>   SYMPY_DEBUG = __sympy_debug()
>>>>>>
>>>>>>   from .core import *
>>>>>> + del sets
>>>>>>   from .logic import *
>>>>>>   from .assumptions import *
>>>>>>   from .polys import *
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 9, 2014 at 10:07 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>>>> OK. Is there a workaround I can use?
>>>>>>>
>>>>>>> Andy
>>>>>>>
>>>>>>> On 4/8/2014 8:04 PM, Pawel Jasinski wrote:
>>>>>>>> It looks like the import bug, but is different.
>>>>>>>> This time imported is confusing already imported:  sympy.core.sets
>>>>>>>> with sympy.sets. Is is looking for  sympy.sets.fancysets in sympty.core.sets
>>>>>>>>
>>>>>>>> On Tue, Apr 8, 2014 at 11:51 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>>>>>> On 4/8/2014 10:28 AM, Jeff Hardy wrote:
>>>>>>>>>> On Tue, Apr 8, 2014 at 9:08 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>>>>>>>> Thanks. Making progress... Now it can't find sympy.sets.fancysets. I've
>>>>>>>>>>> added the folder where the module is defined to sys.path:
>>>>>>>>>>>
>>>>>>>>>>> =============================================
>>>>>>>>>>>>>> sys.path.append('../../PythonLib/sympy/sets')
>>>>>>>>>>>
>>>>>>>>>>>>>> sys.path
>>>>>>>>>>>
>>>>>>>>>>> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
>>>>>>>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
>>>>>>>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
>>>>>>>>>>> '../../PythonLib', '../../PythonLib', '../../PythonLib/sympy/mpmath',
>>>>>>>>>>> '../../PythonLib/sympy/sets']
>>>>>>>>>>>
>>>>>>>>>>>>> >from sympy.sets.fancysets import Naturals0
>>>>>>>>>>>
>>>>>>>>>>> Traceback (most recent call last):
>>>>>>>>>>>   File "<string>", line 1, in <module>
>>>>>>>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
>>>>>>>>>>> line 34, in <module>
>>>>>>>>>>>   File
>>>>>>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
>>>>>>>>>>> line 2, in <module>
>>>>>>>>>>>   File
>>>>>>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
>>>>>>>>>>> line 323, in <module>
>>>>>>>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
>>>>>>>>>>> line 93, in wrapper
>>>>>>>>>>>   File
>>>>>>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
>>>>>>>>>>> line 185, in __new__
>>>>>>>>>>> ImportError: No module named fancysets
>>>>>>>>>>> =============================================
>>>>>>>>>>>
>>>>>>>>>>> Here is what the folder structure looks like:
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/sympy/sympy/tree/master/sympy/sets
>>>>>>>>>>
>>>>>>>>>> Which version of IronPython? It sure looks like the import bug, but if
>>>>>>>>>> you're still hitting in 2.7.5b1 then we'll have to reopen it.
>>>>>>>>>
>>>>>>>>> Jeff,
>>>>>>>>>
>>>>>>>>> Here is my sanity check:
>>>>>>>>>
>>>>>>>>> =============================================
>>>>>>>>>>>> sys.version
>>>>>>>>>
>>>>>>>>> '2.7.5b1 (IronPython 2.7.5b1 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit))'
>>>>>>>>> =============================================
>>>>>>>>>
>>>>>>>>> I'm using the pre-compiled binary version.
>>>>>>>>>
>>>>>>>>> Thanks, Andy
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Andy
>>>>>>>>> PGP Key ID: 0xDC1B5864
>>>>>>>>> _______________________________________________
>>>>>>>>> Ironpython-users mailing list
>>>>>>>>> Ironpython-users at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/ironpython-users
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Andy
>>>>>>> PGP Key ID: 0xDC1B5864
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Andy
>>>> PGP Key ID: 0xDC1B5864
>>>
>>>
>>>
>>
>
> --
> Andy
> PGP Key ID: 0xDC1B5864

From olof.bjarnason at gmail.com  Wed Apr  9 14:40:12 2014
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Wed, 9 Apr 2014 13:40:12 +0100
Subject: [Ironpython-users] Fwd: SymPy and IronPython 2.7.4
In-Reply-To: <CA+7con=vFFmmzK+MOTayBm5uTm=oWSet9h-3ksZcMJGD7fSoig@mail.gmail.com>
References: <534277DB.8090809@britishideas.com>
 <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
 <534315B1.5050907@britishideas.com>
 <CAF7AXFHKnXVTiO4pV6zZ2izMU3Mmk504Ow+=Wn2Pg4_yF4=YhQ@mail.gmail.com>
 <5343AE9B.90205@britishideas.com>
 <CAF7AXFFK_hYdDi=H1RXvF8+ZtYYJ-8hx5sEzettbKuR1Ych8Fg@mail.gmail.com>
 <5343C692.4030509@britishideas.com>
 <CA+7conmvb4TY+=q=ggFZLfQeBw9ijD0Jani4BRVe3NU1n88gFA@mail.gmail.com>
 <5344FFBC.7060701@britishideas.com>
 <CA+7conkg26-vLAUKXz9yaGVxwsYgNj40UXvEfDD9JOv0fvODwg@mail.gmail.com>
 <53450FF0.6010106@britishideas.com>
 <534510A7.80704@britishideas.com>
 <CA+7conkwt-2jG4Lc8LKJKX37qFo+aYJdRN28z9QkuP5SxDbu6A@mail.gmail.com>
 <534513C2.50904@britishideas.com>
 <53451519.3050501@britishideas.com>
 <CA+7conmS1teVcM1Gx8BZq_SzH-hn8TuckN2zk3Q0Cp4dwnj03Q@mail.gmail.com>
 <CA+7con=vFFmmzK+MOTayBm5uTm=oWSet9h-3ksZcMJGD7fSoig@mail.gmail.com>
Message-ID: <CA+LucOi10xr4rSicxqwSJzEr1HE_Xm+hYv21yQsxTHEpmGre=A@mail.gmail.com>

Great to know Pawel ... Is that knowledge written down somewhere? On a
wiki or similar? I'm thinking a page called "Hints when converting
CPython modules to IPY" or better name...

On 9 April 2014 13:00, Pawel Jasinski <pawel.jasinski at gmail.com> wrote:
> ---------- Forwarded message ----------
> From: Pawel Jasinski <pawel.jasinski at gmail.com>
> Date: Wed, Apr 9, 2014 at 1:00 PM
> Subject: Re: [Ironpython-users] SymPy and IronPython 2.7.4
> To: Andrew Ayre <andy at britishideas.com>
>
>
> What I did about unicode, is change directly in core/compatibility.py
>
> $ diff -u compatibility.py~ compatibility.py
> --- compatibility.py~   2014-02-22 20:13:32.000000000 +0100
> +++ compatibility.py    2014-04-07 20:01:04.145668200 +0200
> @@ -107,7 +107,8 @@
>      unicode = unicode
>      unichr = unichr
>      def u(x):
> -        return codecs.unicode_escape_decode(x)[0]
> +        # return codecs.unicode_escape_decode(x)[0]
> +        return x
>      def u_decode(x):
>          return x.decode('utf-8')
>
>
> I owe you a short explanation.
> IronPython is ahead of cpython in terms of unicode. All characters are
> unicode character and not a byte characters.
> This causes all sort of compatibility issues when cpython modules are
> moved to ironpython.
> But this days packages are written from day one as 2.x/3.x compatible
> and contain compatibility.py or equivalent.
> Most of the stuff for 2 vs. 3 can stay as it is, except the characters
> conversions.
> Usually the first guess is to replace things which fail, with 3.x version.
> This is not perfect, but in most cases I had to deal with, is
> sufficient to get going.
>
> --pawel
>
> On Wed, Apr 9, 2014 at 11:38 AM, Andrew Ayre <andy at britishideas.com> wrote:
>> Hi Pawel,
>>
>> Sorry to bombard you with emails. This is interesting:
>>
>> The following works:
>>
>>  - start my application
>>  - run the unicode_escape_decode workaround
>>  - import sympy
>>
>> The following does not work:
>>
>>   - start my application
>>   - import sympy => fails becaue of unicode_escape_decode
>>   - run the unicode_escape_decode workaround
>>   - import sympy => fails, can't find mpmath
>>
>> So perhaps the unicode_escape_decode issue and the import issue are
>> connected in some way?
>>
>> Andy
>>
>> On 4/9/2014 10:32 AM, Andrew Ayre wrote:
>>> Hi Pawel,
>>>
>>> Thanks! In my case I want to bundle it with my application so that my
>>> users don't have to install it.
>>>
>>>  - I have turned on frames in the engine options in C#.
>>>
>>>  - I have put sympy into the global site-packages.
>>>
>>>  - I have added the global site-packages to sys.path in C#.
>>>
>>> Now when I start my application I can run the unicode workaround and
>>> then import sympy!
>>>
>>> Did you also have to use the unicode_escape_decode workaround? Have you
>>> any insight into what the problem is there?
>>>
>>> Andy
>>>
>>> On 4/9/2014 10:23 AM, Pawel Jasinski wrote:
>>>> you can consider installing the package with:
>>>>
>>>> ipy.exe -X:Frames setup.py install --user
>>>>
>>>> which in my case put the package in:
>>>> c:/Users/rejap/AppData/Roaming/Python/IronPython27/site-packages/sympy
>>>> This personal site-packages is in  your sys.path by default.
>>>>
>>>> --pawel
>>>>
>>>> On Wed, Apr 9, 2014 at 11:19 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>> Hi Pawel,
>>>>>
>>>>> Sorry, please ignore that - I accidentally added the wrong path to sys.path.
>>>>>
>>>>> Thanks, Andy
>>>>>
>>>>> On 4/9/2014 10:16 AM, Andrew Ayre wrote:
>>>>>> Hi Pawel,
>>>>>>
>>>>>> OK, I ran the unicode_escape_decode workaround, then I modified
>>>>>> __init__.py as shown. However it seems I am back to the original
>>>>>> problem. For example:
>>>>>>
>>>>>>>>> sys.path.append('../../PythonLib/site-packages/sympy/mpmath')
>>>>>>
>>>>>>>>> import sympy
>>>>>>
>>>>>> Traceback (most recent call last):
>>>>>>   File "<string>", line 1, in <module>
>>>>>>   File
>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\site-packages\sympy\__init__.py",
>>>>>> line 32, in <module>
>>>>>>   File
>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\site-packages\sympy\core\__init__.py",
>>>>>> line 8, in <module>
>>>>>>   File
>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\site-packages\sympy\core\expr.py",
>>>>>> line 7, in <module>
>>>>>>   File
>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\site-packages\sympy\core\evalf.py",
>>>>>> line 9, in <module>
>>>>>> AttributeError: 'module' object has no attribute 'mpmath'
>>>>>>
>>>>>> I've manually added the location of mpmath as Jeff suggested. This
>>>>>> worked when I tried it before but now it doesn't.
>>>>>>
>>>>>> Actually the path to mpmath appears twice is sys.path so I assume sympy
>>>>>> already added it and there was no need for me to add it.
>>>>>>
>>>>>>>>> sys.path
>>>>>>
>>>>>> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
>>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
>>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
>>>>>> '../../PythonLib', '../../PythonLib/site-packages', '../../PythonLib',
>>>>>> '../../PythonLib/sympy/mpmath',
>>>>>> '../../PythonLib/site-packages/sympy/mpmath']
>>>>>>
>>>>>> Thanks, Andy
>>>>>>
>>>>>> On 4/9/2014 10:02 AM, Pawel Jasinski wrote:
>>>>>>> Here is the workaround which let me install the package:
>>>>>>>
>>>>>>> *** sympy/__init__.py.orig      2014-04-09 10:59:53.361779800 +0200
>>>>>>> --- sympy/__init__.py   2014-04-09 11:00:02.906734200 +0200
>>>>>>> ***************
>>>>>>> *** 30,35 ****
>>>>>>> --- 30,36 ----
>>>>>>>   SYMPY_DEBUG = __sympy_debug()
>>>>>>>
>>>>>>>   from .core import *
>>>>>>> + del sets
>>>>>>>   from .logic import *
>>>>>>>   from .assumptions import *
>>>>>>>   from .polys import *
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 9, 2014 at 10:07 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>>>>> OK. Is there a workaround I can use?
>>>>>>>>
>>>>>>>> Andy
>>>>>>>>
>>>>>>>> On 4/8/2014 8:04 PM, Pawel Jasinski wrote:
>>>>>>>>> It looks like the import bug, but is different.
>>>>>>>>> This time imported is confusing already imported:  sympy.core.sets
>>>>>>>>> with sympy.sets. Is is looking for  sympy.sets.fancysets in sympty.core.sets
>>>>>>>>>
>>>>>>>>> On Tue, Apr 8, 2014 at 11:51 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>>>>>>> On 4/8/2014 10:28 AM, Jeff Hardy wrote:
>>>>>>>>>>> On Tue, Apr 8, 2014 at 9:08 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>>>>>>>>> Thanks. Making progress... Now it can't find sympy.sets.fancysets. I've
>>>>>>>>>>>> added the folder where the module is defined to sys.path:
>>>>>>>>>>>>
>>>>>>>>>>>> =============================================
>>>>>>>>>>>>>>> sys.path.append('../../PythonLib/sympy/sets')
>>>>>>>>>>>>
>>>>>>>>>>>>>>> sys.path
>>>>>>>>>>>>
>>>>>>>>>>>> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
>>>>>>>>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
>>>>>>>>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
>>>>>>>>>>>> '../../PythonLib', '../../PythonLib', '../../PythonLib/sympy/mpmath',
>>>>>>>>>>>> '../../PythonLib/sympy/sets']
>>>>>>>>>>>>
>>>>>>>>>>>>>> >from sympy.sets.fancysets import Naturals0
>>>>>>>>>>>>
>>>>>>>>>>>> Traceback (most recent call last):
>>>>>>>>>>>>   File "<string>", line 1, in <module>
>>>>>>>>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
>>>>>>>>>>>> line 34, in <module>
>>>>>>>>>>>>   File
>>>>>>>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
>>>>>>>>>>>> line 2, in <module>
>>>>>>>>>>>>   File
>>>>>>>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
>>>>>>>>>>>> line 323, in <module>
>>>>>>>>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
>>>>>>>>>>>> line 93, in wrapper
>>>>>>>>>>>>   File
>>>>>>>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
>>>>>>>>>>>> line 185, in __new__
>>>>>>>>>>>> ImportError: No module named fancysets
>>>>>>>>>>>> =============================================
>>>>>>>>>>>>
>>>>>>>>>>>> Here is what the folder structure looks like:
>>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/sympy/sympy/tree/master/sympy/sets
>>>>>>>>>>>
>>>>>>>>>>> Which version of IronPython? It sure looks like the import bug, but if
>>>>>>>>>>> you're still hitting in 2.7.5b1 then we'll have to reopen it.
>>>>>>>>>>
>>>>>>>>>> Jeff,
>>>>>>>>>>
>>>>>>>>>> Here is my sanity check:
>>>>>>>>>>
>>>>>>>>>> =============================================
>>>>>>>>>>>>> sys.version
>>>>>>>>>>
>>>>>>>>>> '2.7.5b1 (IronPython 2.7.5b1 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit))'
>>>>>>>>>> =============================================
>>>>>>>>>>
>>>>>>>>>> I'm using the pre-compiled binary version.
>>>>>>>>>>
>>>>>>>>>> Thanks, Andy
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Andy
>>>>>>>>>> PGP Key ID: 0xDC1B5864
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Ironpython-users mailing list
>>>>>>>>>> Ironpython-users at python.org
>>>>>>>>>> https://mail.python.org/mailman/listinfo/ironpython-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Andy
>>>>>>>> PGP Key ID: 0xDC1B5864
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Andy
>>>>> PGP Key ID: 0xDC1B5864
>>>>
>>>>
>>>>
>>>
>>
>> --
>> Andy
>> PGP Key ID: 0xDC1B5864
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users

From fernandez_dan2 at hotmail.com  Wed Apr  9 20:58:15 2014
From: fernandez_dan2 at hotmail.com (Daniel Fernandez)
Date: Wed, 9 Apr 2014 11:58:15 -0700
Subject: [Ironpython-users] Item 34263 in 2.7.5?
In-Reply-To: <CAF7AXFGdq1Au9xfe9UNj9oZ2+ZOncznXQU_-8C70y-pFW8y1SA@mail.gmail.com>
References: <CA+8vhsM_wj012mKqyQLGLis7SWruz9uaw8v43kn0xmGEF9Mbow@mail.gmail.com>,
 <CAF7AXFGdq1Au9xfe9UNj9oZ2+ZOncznXQU_-8C70y-pFW8y1SA@mail.gmail.com>
Message-ID: <BLU182-W12489903C249D6E84552ACA26A0@phx.gbl>

Hi Jeff,
Do you think this will be released in 2.7.6? 
Danny

> Date: Wed, 9 Apr 2014 08:58:14 +0100
> From: jdhardy at gmail.com
> To: jkf359 at gmail.com
> CC: ironpython-users at python.org
> Subject: Re: [Ironpython-users] Item 34263 in 2.7.5?
> 
> On Tue, Apr 8, 2014 at 5:02 PM, John Fullmer <jkf359 at gmail.com> wrote:
> > Could we add this in 2.7.5?
> >
> > http://ironpython.codeplex.com/workitem/34263
> 
> I think changing the defaults for ipy.exe in a point release is too
> big a change. It'll have to wait for the next major release.
> 
> - Jeff
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140409/9a5f7e86/attachment.html>

From vernondcole at gmail.com  Wed Apr  9 21:32:37 2014
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Wed, 9 Apr 2014 20:32:37 +0100
Subject: [Ironpython-users] Item 34263 in 2.7.5?
In-Reply-To: <BLU182-W12489903C249D6E84552ACA26A0@phx.gbl>
References: <CA+8vhsM_wj012mKqyQLGLis7SWruz9uaw8v43kn0xmGEF9Mbow@mail.gmail.com>
 <CAF7AXFGdq1Au9xfe9UNj9oZ2+ZOncznXQU_-8C70y-pFW8y1SA@mail.gmail.com>
 <BLU182-W12489903C249D6E84552ACA26A0@phx.gbl>
Message-ID: <CAH-ZgAdskxVoC1tUpAjA2wwgicYtefksgTecx3ndoo9oqvCCfQ@mail.gmail.com>

I think that would be version 3.3 (or will it be 3.4?) which will be the
next "major" release. (Since there will never be a version of Python 2
higher than "2.7" all 2.x releases henceforth will be "point" releases.
  Let me hasten to point out that, since the unicode vs string vs bytes
issue in Python 3 is well defined, the transition to IronPython 3 ought to
be painless.  Many of the incompatibilities between IronPython and CPython
will just go away. Since we will skip ["3.0", "3.1", "3.2"] we will never
have to remove the u"unicode string marker", which was the biggest pain in
writing runs-on-either version code.  2.7 <-> 3.3 is easy.




On Wed, Apr 9, 2014 at 7:58 PM, Daniel Fernandez <fernandez_dan2 at hotmail.com
> wrote:

> Hi Jeff,
>
> Do you think this will be released in 2.7.6?
>
> Danny
>
> > Date: Wed, 9 Apr 2014 08:58:14 +0100
> > From: jdhardy at gmail.com
> > To: jkf359 at gmail.com
> > CC: ironpython-users at python.org
> > Subject: Re: [Ironpython-users] Item 34263 in 2.7.5?
> >
> > On Tue, Apr 8, 2014 at 5:02 PM, John Fullmer <jkf359 at gmail.com> wrote:
> > > Could we add this in 2.7.5?
> > >
> > > http://ironpython.codeplex.com/workitem/34263
> >
> > I think changing the defaults for ipy.exe in a point release is too
> > big a change. It'll have to wait for the next major release.
> >
> > - Jeff
> > _______________________________________________
> > Ironpython-users mailing list
> > Ironpython-users at python.org
> > https://mail.python.org/mailman/listinfo/ironpython-users
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140409/21fca13d/attachment.html>

From jkf359 at gmail.com  Wed Apr  9 21:42:11 2014
From: jkf359 at gmail.com (John Fullmer)
Date: Wed, 9 Apr 2014 13:42:11 -0600
Subject: [Ironpython-users] Item 34263 in 2.7.5?
In-Reply-To: <CAH-ZgAdskxVoC1tUpAjA2wwgicYtefksgTecx3ndoo9oqvCCfQ@mail.gmail.com>
References: <CA+8vhsM_wj012mKqyQLGLis7SWruz9uaw8v43kn0xmGEF9Mbow@mail.gmail.com>
 <CAF7AXFGdq1Au9xfe9UNj9oZ2+ZOncznXQU_-8C70y-pFW8y1SA@mail.gmail.com>
 <BLU182-W12489903C249D6E84552ACA26A0@phx.gbl>
 <CAH-ZgAdskxVoC1tUpAjA2wwgicYtefksgTecx3ndoo9oqvCCfQ@mail.gmail.com>
Message-ID: <CA+8vhsP5xdeeAuhkcHyYrcqAwee6ZJksNYDKSRXMuEyt9J8RcA@mail.gmail.com>

What is the planned timeline if any?


On Wed, Apr 9, 2014 at 1:32 PM, Vernon D. Cole <vernondcole at gmail.com>wrote:

> I think that would be version 3.3 (or will it be 3.4?) which will be the
> next "major" release. (Since there will never be a version of Python 2
> higher than "2.7" all 2.x releases henceforth will be "point" releases.
>   Let me hasten to point out that, since the unicode vs string vs bytes
> issue in Python 3 is well defined, the transition to IronPython 3 ought to
> be painless.  Many of the incompatibilities between IronPython and CPython
> will just go away. Since we will skip ["3.0", "3.1", "3.2"] we will never
> have to remove the u"unicode string marker", which was the biggest pain in
> writing runs-on-either version code.  2.7 <-> 3.3 is easy.
>
>
>
>
> On Wed, Apr 9, 2014 at 7:58 PM, Daniel Fernandez <
> fernandez_dan2 at hotmail.com> wrote:
>
>> Hi Jeff,
>>
>> Do you think this will be released in 2.7.6?
>>
>> Danny
>>
>> > Date: Wed, 9 Apr 2014 08:58:14 +0100
>> > From: jdhardy at gmail.com
>> > To: jkf359 at gmail.com
>> > CC: ironpython-users at python.org
>> > Subject: Re: [Ironpython-users] Item 34263 in 2.7.5?
>> >
>> > On Tue, Apr 8, 2014 at 5:02 PM, John Fullmer <jkf359 at gmail.com> wrote:
>> > > Could we add this in 2.7.5?
>> > >
>> > > http://ironpython.codeplex.com/workitem/34263
>> >
>> > I think changing the defaults for ipy.exe in a point release is too
>> > big a change. It'll have to wait for the next major release.
>> >
>> > - Jeff
>> > _______________________________________________
>> > Ironpython-users mailing list
>> > Ironpython-users at python.org
>> > https://mail.python.org/mailman/listinfo/ironpython-users
>>
>> _______________________________________________
>> Ironpython-users mailing list
>> Ironpython-users at python.org
>> https://mail.python.org/mailman/listinfo/ironpython-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140409/7f16b5cc/attachment.html>

From fernandez_dan2 at hotmail.com  Wed Apr  9 23:26:50 2014
From: fernandez_dan2 at hotmail.com (Daniel Fernandez)
Date: Wed, 9 Apr 2014 14:26:50 -0700
Subject: [Ironpython-users] Item 34263 in 2.7.5?
In-Reply-To: <CAH-ZgAdskxVoC1tUpAjA2wwgicYtefksgTecx3ndoo9oqvCCfQ@mail.gmail.com>
References: <CA+8vhsM_wj012mKqyQLGLis7SWruz9uaw8v43kn0xmGEF9Mbow@mail.gmail.com>,
 <CAF7AXFGdq1Au9xfe9UNj9oZ2+ZOncznXQU_-8C70y-pFW8y1SA@mail.gmail.com>
 <BLU182-W12489903C249D6E84552ACA26A0@phx.gbl>,
 <CAH-ZgAdskxVoC1tUpAjA2wwgicYtefksgTecx3ndoo9oqvCCfQ@mail.gmail.com>
Message-ID: <BLU182-W47EDACF4EC2E1DC49985C5A26A0@phx.gbl>

Hi Vernon,
Sounds great! I wasn't sure about the migration from 2.7 to 3.x but now I am excited about IronPython 3.x where do I sign up :)
Danny
From: vernondcole at gmail.com
Date: Wed, 9 Apr 2014 20:32:37 +0100
Subject: Re: [Ironpython-users] Item 34263 in 2.7.5?
To: fernandez_dan2 at hotmail.com
CC: jdhardy at gmail.com; jkf359 at gmail.com; ironpython-users at python.org

I think that would be version 3.3 (or will it be 3.4?) which will be the next "major" release. (Since there will never be a version of Python 2 higher than "2.7" all 2.x releases henceforth will be "point" releases. 


  Let me hasten to point out that, since the unicode vs string vs bytes issue in Python 3 is well defined, the transition to IronPython 3 ought to be painless.  Many of the incompatibilities between IronPython and CPython will just go away. Since we will skip ["3.0", "3.1", "3.2"] we will never have to remove the u"unicode string marker", which was the biggest pain in writing runs-on-either version code.  2.7 <-> 3.3 is easy.






On Wed, Apr 9, 2014 at 7:58 PM, Daniel Fernandez <fernandez_dan2 at hotmail.com> wrote:





Hi Jeff,
Do you think this will be released in 2.7.6? 
Danny

> Date: Wed, 9 Apr 2014 08:58:14 +0100
> From: jdhardy at gmail.com


> To: jkf359 at gmail.com
> CC: ironpython-users at python.org
> Subject: Re: [Ironpython-users] Item 34263 in 2.7.5?


> 
> On Tue, Apr 8, 2014 at 5:02 PM, John Fullmer <jkf359 at gmail.com> wrote:
> > Could we add this in 2.7.5?
> >
> > http://ironpython.codeplex.com/workitem/34263


> 
> I think changing the defaults for ipy.exe in a point release is too
> big a change. It'll have to wait for the next major release.
> 
> - Jeff
> _______________________________________________


> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users


 		 	   		  

_______________________________________________

Ironpython-users mailing list

Ironpython-users at python.org

https://mail.python.org/mailman/listinfo/ironpython-users



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140409/c9e923b4/attachment.html>

From jdhardy at gmail.com  Thu Apr 10 00:22:57 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 9 Apr 2014 23:22:57 +0100
Subject: [Ironpython-users] Item 34263 in 2.7.5?
In-Reply-To: <BLU182-W47EDACF4EC2E1DC49985C5A26A0@phx.gbl>
References: <CA+8vhsM_wj012mKqyQLGLis7SWruz9uaw8v43kn0xmGEF9Mbow@mail.gmail.com>
 <CAF7AXFGdq1Au9xfe9UNj9oZ2+ZOncznXQU_-8C70y-pFW8y1SA@mail.gmail.com>
 <BLU182-W12489903C249D6E84552ACA26A0@phx.gbl>
 <CAH-ZgAdskxVoC1tUpAjA2wwgicYtefksgTecx3ndoo9oqvCCfQ@mail.gmail.com>
 <BLU182-W47EDACF4EC2E1DC49985C5A26A0@phx.gbl>
Message-ID: <CAF7AXFHe6L36r7WEkDYrWhLYy24LsGu7ooE0tk12iz-q_hB2_w@mail.gmail.com>

On Wed, Apr 9, 2014 at 10:26 PM, Daniel Fernandez
<fernandez_dan2 at hotmail.com> wrote:
> Hi Vernon,
>
> Sounds great! I wasn't sure about the migration from 2.7 to 3.x but now I am
> excited about IronPython 3.x where do I sign up :)

https://github.com/IronLanguages/ironpython3

- Jeff

From jdhardy at gmail.com  Thu Apr 10 00:30:23 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 9 Apr 2014 23:30:23 +0100
Subject: [Ironpython-users] Item 34263 in 2.7.5?
In-Reply-To: <CA+8vhsP5xdeeAuhkcHyYrcqAwee6ZJksNYDKSRXMuEyt9J8RcA@mail.gmail.com>
References: <CA+8vhsM_wj012mKqyQLGLis7SWruz9uaw8v43kn0xmGEF9Mbow@mail.gmail.com>
 <CAF7AXFGdq1Au9xfe9UNj9oZ2+ZOncznXQU_-8C70y-pFW8y1SA@mail.gmail.com>
 <BLU182-W12489903C249D6E84552ACA26A0@phx.gbl>
 <CAH-ZgAdskxVoC1tUpAjA2wwgicYtefksgTecx3ndoo9oqvCCfQ@mail.gmail.com>
 <CA+8vhsP5xdeeAuhkcHyYrcqAwee6ZJksNYDKSRXMuEyt9J8RcA@mail.gmail.com>
Message-ID: <CAF7AXFFZS7kO1t1e1qcidRq2+31RDtoWDhVxc96-MzPGVj0dsA@mail.gmail.com>

On Wed, Apr 9, 2014 at 8:42 PM, John Fullmer <jkf359 at gmail.com> wrote:
> What is the planned timeline if any?

This year, hopefully. However, my timelines often seem to be overly
optimistic. :|

It'll all depend on how many other contributions come in; me and Pawel
can't do it all.

- Jeff

From slide.o.mix at gmail.com  Thu Apr 10 00:35:39 2014
From: slide.o.mix at gmail.com (Slide)
Date: Wed, 9 Apr 2014 15:35:39 -0700
Subject: [Ironpython-users] Item 34263 in 2.7.5?
In-Reply-To: <CAF7AXFFZS7kO1t1e1qcidRq2+31RDtoWDhVxc96-MzPGVj0dsA@mail.gmail.com>
References: <CA+8vhsM_wj012mKqyQLGLis7SWruz9uaw8v43kn0xmGEF9Mbow@mail.gmail.com>
 <CAF7AXFGdq1Au9xfe9UNj9oZ2+ZOncznXQU_-8C70y-pFW8y1SA@mail.gmail.com>
 <BLU182-W12489903C249D6E84552ACA26A0@phx.gbl>
 <CAH-ZgAdskxVoC1tUpAjA2wwgicYtefksgTecx3ndoo9oqvCCfQ@mail.gmail.com>
 <CA+8vhsP5xdeeAuhkcHyYrcqAwee6ZJksNYDKSRXMuEyt9J8RcA@mail.gmail.com>
 <CAF7AXFFZS7kO1t1e1qcidRq2+31RDtoWDhVxc96-MzPGVj0dsA@mail.gmail.com>
Message-ID: <CAPiUgVcRiyFA9TgUm+Yr0KSdsapn2pNtC3aCsUWOs+TXLoJQuQ@mail.gmail.com>

I'm hoping to have some more time to work on IP this year.


On Wed, Apr 9, 2014 at 3:30 PM, Jeff Hardy <jdhardy at gmail.com> wrote:

> On Wed, Apr 9, 2014 at 8:42 PM, John Fullmer <jkf359 at gmail.com> wrote:
> > What is the planned timeline if any?
>
> This year, hopefully. However, my timelines often seem to be overly
> optimistic. :|
>
> It'll all depend on how many other contributions come in; me and Pawel
> can't do it all.
>
> - Jeff
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>



-- 
Website: http://earl-of-code.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140409/442ee072/attachment.html>

From jdhardy at gmail.com  Thu Apr 10 00:28:41 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 9 Apr 2014 23:28:41 +0100
Subject: [Ironpython-users] Item 34263 in 2.7.5?
In-Reply-To: <CAH-ZgAdskxVoC1tUpAjA2wwgicYtefksgTecx3ndoo9oqvCCfQ@mail.gmail.com>
References: <CA+8vhsM_wj012mKqyQLGLis7SWruz9uaw8v43kn0xmGEF9Mbow@mail.gmail.com>
 <CAF7AXFGdq1Au9xfe9UNj9oZ2+ZOncznXQU_-8C70y-pFW8y1SA@mail.gmail.com>
 <BLU182-W12489903C249D6E84552ACA26A0@phx.gbl>
 <CAH-ZgAdskxVoC1tUpAjA2wwgicYtefksgTecx3ndoo9oqvCCfQ@mail.gmail.com>
Message-ID: <CAF7AXFHetebshYkSFkHOO7WbbKt5tVQ7KyCbZgt42GMx-YReHw@mail.gmail.com>

On Wed, Apr 9, 2014 at 8:32 PM, Vernon D. Cole <vernondcole at gmail.com> wrote:
> I think that would be version 3.3 (or will it be 3.4?) which will be the
> next "major" release. (Since there will never be a version of Python 2
> higher than "2.7" all 2.x releases henceforth will be "point" releases.
>   Let me hasten to point out that, since the unicode vs string vs bytes
> issue in Python 3 is well defined, the transition to IronPython 3 ought to
> be painless.  Many of the incompatibilities between IronPython and CPython
> will just go away. Since we will skip ["3.0", "3.1", "3.2"] we will never
> have to remove the u"unicode string marker", which was the biggest pain in
> writing runs-on-either version code.  2.7 <-> 3.3 is easy.

Yeah, this change won't happen until IronPython 3. I'm also going to
take the opportunity to break from the convention of matching CPython
versions and just call it 3.0, even though it will have everything up
to 3.4 in it. PEP 421 (http://www.python.org/dev/peps/pep-0421/) has
the mechanism to make this work.

And yes, my hope is that moving to 3 will be much less problematic for
IronPython than it is for CPython. Other than a few things (like
changing the default Frames setting) there shouldn't be too many
breaking changes.

- Jeff

From slide.o.mix at gmail.com  Thu Apr 10 00:49:32 2014
From: slide.o.mix at gmail.com (Slide)
Date: Wed, 9 Apr 2014 15:49:32 -0700
Subject: [Ironpython-users] Item 34263 in 2.7.5?
In-Reply-To: <CAPiUgVcRiyFA9TgUm+Yr0KSdsapn2pNtC3aCsUWOs+TXLoJQuQ@mail.gmail.com>
References: <CA+8vhsM_wj012mKqyQLGLis7SWruz9uaw8v43kn0xmGEF9Mbow@mail.gmail.com>
 <CAF7AXFGdq1Au9xfe9UNj9oZ2+ZOncznXQU_-8C70y-pFW8y1SA@mail.gmail.com>
 <BLU182-W12489903C249D6E84552ACA26A0@phx.gbl>
 <CAH-ZgAdskxVoC1tUpAjA2wwgicYtefksgTecx3ndoo9oqvCCfQ@mail.gmail.com>
 <CA+8vhsP5xdeeAuhkcHyYrcqAwee6ZJksNYDKSRXMuEyt9J8RcA@mail.gmail.com>
 <CAF7AXFFZS7kO1t1e1qcidRq2+31RDtoWDhVxc96-MzPGVj0dsA@mail.gmail.com>
 <CAPiUgVcRiyFA9TgUm+Yr0KSdsapn2pNtC3aCsUWOs+TXLoJQuQ@mail.gmail.com>
Message-ID: <CAPiUgVcdnZ_oaWsTsASa08bYDWFZkrLSTTsp-FZ3GiryGz5Nnw@mail.gmail.com>

To follow up on my own email :-) I am thinking of looking at the byte code
interpreter again. It looked like a lot of fun :-)


On Wed, Apr 9, 2014 at 3:35 PM, Slide <slide.o.mix at gmail.com> wrote:

> I'm hoping to have some more time to work on IP this year.
>
>
> On Wed, Apr 9, 2014 at 3:30 PM, Jeff Hardy <jdhardy at gmail.com> wrote:
>
>> On Wed, Apr 9, 2014 at 8:42 PM, John Fullmer <jkf359 at gmail.com> wrote:
>> > What is the planned timeline if any?
>>
>> This year, hopefully. However, my timelines often seem to be overly
>> optimistic. :|
>>
>> It'll all depend on how many other contributions come in; me and Pawel
>> can't do it all.
>>
>> - Jeff
>> _______________________________________________
>> Ironpython-users mailing list
>> Ironpython-users at python.org
>> https://mail.python.org/mailman/listinfo/ironpython-users
>>
>
>
>
> --
> Website: http://earl-of-code.com
>



-- 
Website: http://earl-of-code.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140409/e8908ec8/attachment.html>

From vernondcole at gmail.com  Thu Apr 10 08:31:08 2014
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Thu, 10 Apr 2014 00:31:08 -0600
Subject: [Ironpython-users] Item 34263 in 2.7.5?
In-Reply-To: <CAF7AXFHetebshYkSFkHOO7WbbKt5tVQ7KyCbZgt42GMx-YReHw@mail.gmail.com>
References: <CA+8vhsM_wj012mKqyQLGLis7SWruz9uaw8v43kn0xmGEF9Mbow@mail.gmail.com>
 <CAF7AXFGdq1Au9xfe9UNj9oZ2+ZOncznXQU_-8C70y-pFW8y1SA@mail.gmail.com>
 <BLU182-W12489903C249D6E84552ACA26A0@phx.gbl>
 <CAH-ZgAdskxVoC1tUpAjA2wwgicYtefksgTecx3ndoo9oqvCCfQ@mail.gmail.com>
 <CAF7AXFHetebshYkSFkHOO7WbbKt5tVQ7KyCbZgt42GMx-YReHw@mail.gmail.com>
Message-ID: <CAH-ZgAeXke2ecH9gVo_xLTeY=sRf5+vUFSV7pCUbdZ5yFZdpeA@mail.gmail.com>

-1 on version number 3.0.

Just last week I was in a complete panic when I discovered that the version
of Python embedded in moneydance <http://moneydance.com> was "Jython 2.0".
After some frantic searching, I discovered that Jython 2.0 implements
Python 2.5.  Their current beta is numbered 2.7b1 because of such confusion.

I also seem to remember many emails and other explanations about
"IronPython version 2.0 implements the Python 2.5 specification" so that
the next version of IronPython was numbered to match the language spec.
That is a good tradition to keep.



On Wed, Apr 9, 2014 at 4:28 PM, Jeff Hardy <jdhardy at gmail.com> wrote:

> On Wed, Apr 9, 2014 at 8:32 PM, Vernon D. Cole <vernondcole at gmail.com>
> wrote:
> > I think that would be version 3.3 (or will it be 3.4?) which will be the
> > next "major" release. (Since there will never be a version of Python 2
> > higher than "2.7" all 2.x releases henceforth will be "point" releases.
> >   Let me hasten to point out that, since the unicode vs string vs bytes
> > issue in Python 3 is well defined, the transition to IronPython 3 ought
> to
> > be painless.  Many of the incompatibilities between IronPython and
> CPython
> > will just go away. Since we will skip ["3.0", "3.1", "3.2"] we will never
> > have to remove the u"unicode string marker", which was the biggest pain
> in
> > writing runs-on-either version code.  2.7 <-> 3.3 is easy.
>
> Yeah, this change won't happen until IronPython 3. I'm also going to
> take the opportunity to break from the convention of matching CPython
> versions and just call it 3.0, even though it will have everything up
> to 3.4 in it. PEP 421 (http://www.python.org/dev/peps/pep-0421/) has
> the mechanism to make this work.
>
> And yes, my hope is that moving to 3 will be much less problematic for
> IronPython than it is for CPython. Other than a few things (like
> changing the default Frames setting) there shouldn't be too many
> breaking changes.
>
> - Jeff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140410/2c038bb1/attachment.html>

From no_reply at codeplex.com  Thu Apr 10 09:22:46 2014
From: no_reply at codeplex.com (CodePlex)
Date: 10 Apr 2014 00:22:46 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/9/2014
Message-ID: <CO1MSDNADMCDS2vSAMf0001de53@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] StackOverflow when enumerating dynamic members of IMOs
2. [New issue] package get confused as module during import

----------------------------------------------

ISSUES

1. [New comment] StackOverflow when enumerating dynamic members of IMOs
http://ironpython.codeplex.com/workitem/34893
User jdhardy has commented on the issue:

"<p>This has proven to be delightfully nasty to solve.</p><p>The basic issue is that `PythonType.GetMemberNames` is called on `f`; that checks to see if it has a custom `__dir__`, which it does, provided by `DynamicObject`, so it ultimately calls `MetaUserObject.GetDynamicMemberNames`; seeing as this is a Python object, it then calls `Python.GetMemberNames`...</p><p>Everything I've tried breaks one of: custom `__dir__` on Python types, getting dynamic member names from other dynamic types, or getting the dynamic member names from a Python type from another language.</p><p>I feel there is a solution here, but I just can't put my finger on it. I'm all but certain it'll involve special-casing the situation where a Python class derives from a DynamicObject (really, IDMOP) class. It's just a matter of finding it.</p>"-----------------

2. [New issue] package get confused as module during import
http://ironpython.codeplex.com/workitem/35116
User paweljasinski has proposed the issue:

"In the following package structure:
top
top/pkg1
top/pkg1/m1.py
top/pkg1/__init__.py
top/pkg2
top/pkg2/pkg1.py
top/pkg2/__init__.py
top/__init__.py
test.py

and __init__.py (s) defined as in attachment, import statement can interpret top/pkg2/pkg1.py instead of top/pkg1.

running test.py produces:
rejap at WIN-CUE1I6EN9JB ~/tmp/import-aliasing
$ ipy test.py
Traceback (most recent call last):
  File "test.py", line 2, in <module>
ImportError: No module named m1

and equivalent for cpython:
rejap at WIN-CUE1I6EN9JB ~/tmp/import-aliasing
$ python test.py
42

Reference: https://mail.python.org/pipermail/ironpython-users/2014-April/016924.html"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140410/6481684e/attachment.html>

From vernondcole at gmail.com  Thu Apr 10 09:32:06 2014
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Thu, 10 Apr 2014 01:32:06 -0600
Subject: [Ironpython-users] Fwd:  Item 34263 in 2.7.5?
In-Reply-To: <CA+7conkeaFRMDVC=mg2zo_PH_mTqfR5ZA2yV=3ggkTRCX374aQ@mail.gmail.com>
References: <CA+8vhsM_wj012mKqyQLGLis7SWruz9uaw8v43kn0xmGEF9Mbow@mail.gmail.com>
 <CAF7AXFGdq1Au9xfe9UNj9oZ2+ZOncznXQU_-8C70y-pFW8y1SA@mail.gmail.com>
 <BLU182-W12489903C249D6E84552ACA26A0@phx.gbl>
 <CAH-ZgAdskxVoC1tUpAjA2wwgicYtefksgTecx3ndoo9oqvCCfQ@mail.gmail.com>
 <CAF7AXFHetebshYkSFkHOO7WbbKt5tVQ7KyCbZgt42GMx-YReHw@mail.gmail.com>
 <CAH-ZgAeXke2ecH9gVo_xLTeY=sRf5+vUFSV7pCUbdZ5yFZdpeA@mail.gmail.com>
 <CA+7conkeaFRMDVC=mg2zo_PH_mTqfR5ZA2yV=3ggkTRCX374aQ@mail.gmail.com>
Message-ID: <CAH-ZgAdCMDTvoPd=jfSzYfsPtg4_N=pbH5XE=xoLrY5FbNOGvg@mail.gmail.com>

(Blast!  When I hit <replyl> I failed to edit the CC list, so my message
went directly to Pawel  ... so when HE hit reply, his message went directly
to me.  Confusion reigns.)

---------- Forwarded message ----------
From: Pawel Jasinski <pawel.jasinski at gmail.com>
Date: Thu, Apr 10, 2014 at 1:20 AM
Subject: Re: [Ironpython-users] Item 34263 in 2.7.5?
To: "Vernon D. Cole" <vernondcole at gmail.com>


I agree with Vernon.
My typical use case is python.org docs. For ironpython 2.7, I select
2.7 for 3.0, hm ... 3.0, 3.4 or 3.5?
Why do we need to break it? What is the benefit?

--pawel

On Thu, Apr 10, 2014 at 8:31 AM, Vernon D. Cole <vernondcole at gmail.com>
wrote:
> -1 on version number 3.0.
>
> Just last week I was in a complete panic when I discovered that the
version
> of Python embedded in moneydance was "Jython 2.0".  After some frantic
> searching, I discovered that Jython 2.0 implements Python 2.5.  Their
> current beta is numbered 2.7b1 because of such confusion.
>
> I also seem to remember many emails and other explanations about
"IronPython
> version 2.0 implements the Python 2.5 specification" so that the next
> version of IronPython was numbered to match the language spec.   That is a
> good tradition to keep.
>
>
>
> On Wed, Apr 9, 2014 at 4:28 PM, Jeff Hardy <jdhardy at gmail.com> wrote:
>>
>> On Wed, Apr 9, 2014 at 8:32 PM, Vernon D. Cole <vernondcole at gmail.com>
>> wrote:
>> > I think that would be version 3.3 (or will it be 3.4?) which will be
the
>> > next "major" release. (Since there will never be a version of Python 2
>> > higher than "2.7" all 2.x releases henceforth will be "point" releases.
>> >   Let me hasten to point out that, since the unicode vs string vs bytes
>> > issue in Python 3 is well defined, the transition to IronPython 3 ought
>> > to
>> > be painless.  Many of the incompatibilities between IronPython and
>> > CPython
>> > will just go away. Since we will skip ["3.0", "3.1", "3.2"] we will
>> > never
>> > have to remove the u"unicode string marker", which was the biggest pain
>> > in
>> > writing runs-on-either version code.  2.7 <-> 3.3 is easy.
>>
>> Yeah, this change won't happen until IronPython 3. I'm also going to
>> take the opportunity to break from the convention of matching CPython
>> versions and just call it 3.0, even though it will have everything up
>> to 3.4 in it. PEP 421 (http://www.python.org/dev/peps/pep-0421/) has
>> the mechanism to make this work.
>>
>> And yes, my hope is that moving to 3 will be much less problematic for
>> IronPython than it is for CPython. Other than a few things (like
>> changing the default Frames setting) there shouldn't be too many
>> breaking changes.
>>
>> - Jeff
>
>
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140410/bfcc10dd/attachment.html>

From pawel.jasinski at gmail.com  Thu Apr 10 09:39:07 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Thu, 10 Apr 2014 09:39:07 +0200
Subject: [Ironpython-users] Fwd:  Item 34263 in 2.7.5?
In-Reply-To: <CA+7conkeaFRMDVC=mg2zo_PH_mTqfR5ZA2yV=3ggkTRCX374aQ@mail.gmail.com>
References: <CA+8vhsM_wj012mKqyQLGLis7SWruz9uaw8v43kn0xmGEF9Mbow@mail.gmail.com>
 <CAF7AXFGdq1Au9xfe9UNj9oZ2+ZOncznXQU_-8C70y-pFW8y1SA@mail.gmail.com>
 <BLU182-W12489903C249D6E84552ACA26A0@phx.gbl>
 <CAH-ZgAdskxVoC1tUpAjA2wwgicYtefksgTecx3ndoo9oqvCCfQ@mail.gmail.com>
 <CAF7AXFHetebshYkSFkHOO7WbbKt5tVQ7KyCbZgt42GMx-YReHw@mail.gmail.com>
 <CAH-ZgAeXke2ecH9gVo_xLTeY=sRf5+vUFSV7pCUbdZ5yFZdpeA@mail.gmail.com>
 <CA+7conkeaFRMDVC=mg2zo_PH_mTqfR5ZA2yV=3ggkTRCX374aQ@mail.gmail.com>
Message-ID: <CA+7connKhWib-K9HWzk89-EzMdq0mFCNwdWr2fs5W7b6BqpZRQ@mail.gmail.com>

Sorry, it happens to me all the time, I reply to person and forget
about mailing list.

---------- Forwarded message ----------
From: Pawel Jasinski <pawel.jasinski at gmail.com>
Date: Thu, Apr 10, 2014 at 9:20 AM
Subject: Re: [Ironpython-users] Item 34263 in 2.7.5?
To: "Vernon D. Cole" <vernondcole at gmail.com>


I agree with Vernon.
My typical use case is python.org docs. For ironpython 2.7, I select
2.7 for 3.0, hm ... 3.0, 3.4 or 3.5?
Why do we need to break it? What is the benefit?

--pawel

On Thu, Apr 10, 2014 at 8:31 AM, Vernon D. Cole <vernondcole at gmail.com> wrote:
> -1 on version number 3.0.
>
> Just last week I was in a complete panic when I discovered that the version
> of Python embedded in moneydance was "Jython 2.0".  After some frantic
> searching, I discovered that Jython 2.0 implements Python 2.5.  Their
> current beta is numbered 2.7b1 because of such confusion.
>
> I also seem to remember many emails and other explanations about "IronPython
> version 2.0 implements the Python 2.5 specification" so that the next
> version of IronPython was numbered to match the language spec.   That is a
> good tradition to keep.
>
>
>
> On Wed, Apr 9, 2014 at 4:28 PM, Jeff Hardy <jdhardy at gmail.com> wrote:
>>
>> On Wed, Apr 9, 2014 at 8:32 PM, Vernon D. Cole <vernondcole at gmail.com>
>> wrote:
>> > I think that would be version 3.3 (or will it be 3.4?) which will be the
>> > next "major" release. (Since there will never be a version of Python 2
>> > higher than "2.7" all 2.x releases henceforth will be "point" releases.
>> >   Let me hasten to point out that, since the unicode vs string vs bytes
>> > issue in Python 3 is well defined, the transition to IronPython 3 ought
>> > to
>> > be painless.  Many of the incompatibilities between IronPython and
>> > CPython
>> > will just go away. Since we will skip ["3.0", "3.1", "3.2"] we will
>> > never
>> > have to remove the u"unicode string marker", which was the biggest pain
>> > in
>> > writing runs-on-either version code.  2.7 <-> 3.3 is easy.
>>
>> Yeah, this change won't happen until IronPython 3. I'm also going to
>> take the opportunity to break from the convention of matching CPython
>> versions and just call it 3.0, even though it will have everything up
>> to 3.4 in it. PEP 421 (http://www.python.org/dev/peps/pep-0421/) has
>> the mechanism to make this work.
>>
>> And yes, my hope is that moving to 3 will be much less problematic for
>> IronPython than it is for CPython. Other than a few things (like
>> changing the default Frames setting) there shouldn't be too many
>> breaking changes.
>>
>> - Jeff
>
>
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>

From andy at britishideas.com  Thu Apr 10 09:44:03 2014
From: andy at britishideas.com (Andrew Ayre)
Date: Thu, 10 Apr 2014 08:44:03 +0100
Subject: [Ironpython-users] SymPy and IronPython 2.7.4
In-Reply-To: <CA+7conkg26-vLAUKXz9yaGVxwsYgNj40UXvEfDD9JOv0fvODwg@mail.gmail.com>
References: <534277DB.8090809@britishideas.com>
 <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
 <534315B1.5050907@britishideas.com>
 <CAF7AXFHKnXVTiO4pV6zZ2izMU3Mmk504Ow+=Wn2Pg4_yF4=YhQ@mail.gmail.com>
 <5343AE9B.90205@britishideas.com>
 <CAF7AXFFK_hYdDi=H1RXvF8+ZtYYJ-8hx5sEzettbKuR1Ych8Fg@mail.gmail.com>
 <5343C692.4030509@britishideas.com>
 <CA+7conmvb4TY+=q=ggFZLfQeBw9ijD0Jani4BRVe3NU1n88gFA@mail.gmail.com>
 <5344FFBC.7060701@britishideas.com>
 <CA+7conkg26-vLAUKXz9yaGVxwsYgNj40UXvEfDD9JOv0fvODwg@mail.gmail.com>
Message-ID: <53464BC3.4050108@britishideas.com>

Hi,

This workaround is working well, but will there be a fix to IronPython
so it isn't needed?

I need to give feedback to the SymPy people.

Thanks! Andy

On 4/9/2014 10:02 AM, Pawel Jasinski wrote:
> Here is the workaround which let me install the package:
> 
> *** sympy/__init__.py.orig      2014-04-09 10:59:53.361779800 +0200
> --- sympy/__init__.py   2014-04-09 11:00:02.906734200 +0200
> ***************
> *** 30,35 ****
> --- 30,36 ----
>   SYMPY_DEBUG = __sympy_debug()
> 
>   from .core import *
> + del sets
>   from .logic import *
>   from .assumptions import *
>   from .polys import *
> 
> 
> 
> On Wed, Apr 9, 2014 at 10:07 AM, Andrew Ayre <andy at britishideas.com> wrote:
>> OK. Is there a workaround I can use?
>>
>> Andy
>>
>> On 4/8/2014 8:04 PM, Pawel Jasinski wrote:
>>> It looks like the import bug, but is different.
>>> This time imported is confusing already imported:  sympy.core.sets
>>> with sympy.sets. Is is looking for  sympy.sets.fancysets in sympty.core.sets
>>>
>>> On Tue, Apr 8, 2014 at 11:51 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>> On 4/8/2014 10:28 AM, Jeff Hardy wrote:
>>>>> On Tue, Apr 8, 2014 at 9:08 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>>> Thanks. Making progress... Now it can't find sympy.sets.fancysets. I've
>>>>>> added the folder where the module is defined to sys.path:
>>>>>>
>>>>>> =============================================
>>>>>>>>> sys.path.append('../../PythonLib/sympy/sets')
>>>>>>
>>>>>>>>> sys.path
>>>>>>
>>>>>> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
>>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
>>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
>>>>>> '../../PythonLib', '../../PythonLib', '../../PythonLib/sympy/mpmath',
>>>>>> '../../PythonLib/sympy/sets']
>>>>>>
>>>>>>>> >from sympy.sets.fancysets import Naturals0
>>>>>>
>>>>>> Traceback (most recent call last):
>>>>>>   File "<string>", line 1, in <module>
>>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
>>>>>> line 34, in <module>
>>>>>>   File
>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
>>>>>> line 2, in <module>
>>>>>>   File
>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
>>>>>> line 323, in <module>
>>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
>>>>>> line 93, in wrapper
>>>>>>   File
>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
>>>>>> line 185, in __new__
>>>>>> ImportError: No module named fancysets
>>>>>> =============================================
>>>>>>
>>>>>> Here is what the folder structure looks like:
>>>>>>
>>>>>> https://github.com/sympy/sympy/tree/master/sympy/sets
>>>>>
>>>>> Which version of IronPython? It sure looks like the import bug, but if
>>>>> you're still hitting in 2.7.5b1 then we'll have to reopen it.
>>>>
>>>> Jeff,
>>>>
>>>> Here is my sanity check:
>>>>
>>>> =============================================
>>>>>>> sys.version
>>>>
>>>> '2.7.5b1 (IronPython 2.7.5b1 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit))'
>>>> =============================================
>>>>
>>>> I'm using the pre-compiled binary version.
>>>>
>>>> Thanks, Andy
>>>>
>>>> --
>>>> Andy
>>>> PGP Key ID: 0xDC1B5864
>>>> _______________________________________________
>>>> Ironpython-users mailing list
>>>> Ironpython-users at python.org
>>>> https://mail.python.org/mailman/listinfo/ironpython-users
>>>
>>>
>>>
>>
>> --
>> Andy
>> PGP Key ID: 0xDC1B5864
> 
> 
> 

-- 
Andy
PGP Key ID: 0xDC1B5864

From pawel.jasinski at gmail.com  Thu Apr 10 10:09:41 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Thu, 10 Apr 2014 10:09:41 +0200
Subject: [Ironpython-users] SymPy and IronPython 2.7.4
In-Reply-To: <53464BC3.4050108@britishideas.com>
References: <534277DB.8090809@britishideas.com>
 <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
 <534315B1.5050907@britishideas.com>
 <CAF7AXFHKnXVTiO4pV6zZ2izMU3Mmk504Ow+=Wn2Pg4_yF4=YhQ@mail.gmail.com>
 <5343AE9B.90205@britishideas.com>
 <CAF7AXFFK_hYdDi=H1RXvF8+ZtYYJ-8hx5sEzettbKuR1Ych8Fg@mail.gmail.com>
 <5343C692.4030509@britishideas.com>
 <CA+7conmvb4TY+=q=ggFZLfQeBw9ijD0Jani4BRVe3NU1n88gFA@mail.gmail.com>
 <5344FFBC.7060701@britishideas.com>
 <CA+7conkg26-vLAUKXz9yaGVxwsYgNj40UXvEfDD9JOv0fvODwg@mail.gmail.com>
 <53464BC3.4050108@britishideas.com>
Message-ID: <CA+7conm1KB69GGzGbKK3Ew_N8q9faK-YY16WGkOs06VPMzrpbg@mail.gmail.com>

I have opened a cp: https://ironpython.codeplex.com/workitem/35116
I have a fix, but before push request  I need to check if it doesn't
break something else.
It needs a to be reviewed and hopefully it is not to late for 2.7.5.
--pawel


On Thu, Apr 10, 2014 at 9:44 AM, Andrew Ayre <andy at britishideas.com> wrote:
> Hi,
>
> This workaround is working well, but will there be a fix to IronPython
> so it isn't needed?
>
> I need to give feedback to the SymPy people.
>
> Thanks! Andy
>
> On 4/9/2014 10:02 AM, Pawel Jasinski wrote:
>> Here is the workaround which let me install the package:
>>
>> *** sympy/__init__.py.orig      2014-04-09 10:59:53.361779800 +0200
>> --- sympy/__init__.py   2014-04-09 11:00:02.906734200 +0200
>> ***************
>> *** 30,35 ****
>> --- 30,36 ----
>>   SYMPY_DEBUG = __sympy_debug()
>>
>>   from .core import *
>> + del sets
>>   from .logic import *
>>   from .assumptions import *
>>   from .polys import *
>>
>>
>>
>> On Wed, Apr 9, 2014 at 10:07 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>> OK. Is there a workaround I can use?
>>>
>>> Andy
>>>
>>> On 4/8/2014 8:04 PM, Pawel Jasinski wrote:
>>>> It looks like the import bug, but is different.
>>>> This time imported is confusing already imported:  sympy.core.sets
>>>> with sympy.sets. Is is looking for  sympy.sets.fancysets in sympty.core.sets
>>>>
>>>> On Tue, Apr 8, 2014 at 11:51 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>> On 4/8/2014 10:28 AM, Jeff Hardy wrote:
>>>>>> On Tue, Apr 8, 2014 at 9:08 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>>>> Thanks. Making progress... Now it can't find sympy.sets.fancysets. I've
>>>>>>> added the folder where the module is defined to sys.path:
>>>>>>>
>>>>>>> =============================================
>>>>>>>>>> sys.path.append('../../PythonLib/sympy/sets')
>>>>>>>
>>>>>>>>>> sys.path
>>>>>>>
>>>>>>> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
>>>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
>>>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
>>>>>>> '../../PythonLib', '../../PythonLib', '../../PythonLib/sympy/mpmath',
>>>>>>> '../../PythonLib/sympy/sets']
>>>>>>>
>>>>>>>>> >from sympy.sets.fancysets import Naturals0
>>>>>>>
>>>>>>> Traceback (most recent call last):
>>>>>>>   File "<string>", line 1, in <module>
>>>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
>>>>>>> line 34, in <module>
>>>>>>>   File
>>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
>>>>>>> line 2, in <module>
>>>>>>>   File
>>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
>>>>>>> line 323, in <module>
>>>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
>>>>>>> line 93, in wrapper
>>>>>>>   File
>>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
>>>>>>> line 185, in __new__
>>>>>>> ImportError: No module named fancysets
>>>>>>> =============================================
>>>>>>>
>>>>>>> Here is what the folder structure looks like:
>>>>>>>
>>>>>>> https://github.com/sympy/sympy/tree/master/sympy/sets
>>>>>>
>>>>>> Which version of IronPython? It sure looks like the import bug, but if
>>>>>> you're still hitting in 2.7.5b1 then we'll have to reopen it.
>>>>>
>>>>> Jeff,
>>>>>
>>>>> Here is my sanity check:
>>>>>
>>>>> =============================================
>>>>>>>> sys.version
>>>>>
>>>>> '2.7.5b1 (IronPython 2.7.5b1 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit))'
>>>>> =============================================
>>>>>
>>>>> I'm using the pre-compiled binary version.
>>>>>
>>>>> Thanks, Andy
>>>>>
>>>>> --
>>>>> Andy
>>>>> PGP Key ID: 0xDC1B5864
>>>>> _______________________________________________
>>>>> Ironpython-users mailing list
>>>>> Ironpython-users at python.org
>>>>> https://mail.python.org/mailman/listinfo/ironpython-users
>>>>
>>>>
>>>>
>>>
>>> --
>>> Andy
>>> PGP Key ID: 0xDC1B5864
>>
>>
>>
>
> --
> Andy
> PGP Key ID: 0xDC1B5864

From jdhardy at gmail.com  Thu Apr 10 10:18:43 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 10 Apr 2014 09:18:43 +0100
Subject: [Ironpython-users] IronPython 3 Version Number (Was: Item 34263 in
	2.7.5?)
Message-ID: <CAF7AXFEbygNU4-b_oTVgD4f3zJjH3snoe_iB-w2MfcYUP+tSmQ@mail.gmail.com>

On Thu, Apr 10, 2014 at 7:31 AM, Vernon D. Cole <vernondcole at gmail.com> wrote:
> -1 on version number 3.0.
>
> Just last week I was in a complete panic when I discovered that the version
> of Python embedded in moneydance was "Jython 2.0".  After some frantic
> searching, I discovered that Jython 2.0 implements Python 2.5.  Their
> current beta is numbered 2.7b1 because of such confusion.
>
> I also seem to remember many emails and other explanations about "IronPython
> version 2.0 implements the Python 2.5 specification" so that the next
> version of IronPython was numbered to match the language spec.   That is a
> good tradition to keep.

I completely understand where you're coming from, and for IronPython
2.7 I think this was a good match. My concern is that this limits the
ability of IronPython to evolve in other ways not tied to CPython
versions. For example, consider issue 34263 that started this thread:
if IronPython 2.7 was instead 2.3, I would have no problem issuing a
2.4 with the Frames behaviour changed, but calling it 2.8 is right
out.

In addition, 3.0 will include most (but perhaps not all!) of 3.4's
features, mainly because I'd like to see a release later this year
(around October) and things like nonlocal or importlib could slip
because they're hard and not terribly exciting. Calling a release like
that 3.4 is a problem because it's really not 3.4-compatible.

Once the Python 3 features are in place, I want to make it as
cross-platform as possible - iOS, Android, Windows 8, etc. That would
strongly imply a new version number since it will require a new DLR
version to be used (not very good to slip a DLR version change into a
3.4.z release). Hence I'd prefer to keep the ability to call it 3.1
(or whatever) instead.

Finally, PyPy does not synchronize version numbers with CPython, and
they seem to be doing just fine. That's why sys.implementation has the
ability to distinguish interpreter version (say 3.0) from
sys.version's language version (3.4).

Of course, my mind is willing to be changed if enough people disagree,
but until we can match CPython exactly I'd prefer to keep the version
numbers independent.

On Thu, Apr 10, 2014 at 1:20 AM, Pawel Jasinski
<pawel.jasinski at gmail.com> wrote:
> My typical use case is python.org docs. For ironpython 2.7, I select 2.7 for 3.0, hm ... 3.0, 3.4 or 3.5?

Hopefully, IronPython 3 docs. Keeping a fork of the docs will be a bit
more work, but the advantage is that we can describe any IP-specific
quirks that may exist and also have a home for real documentation,
like how to embed IronPython and a cleaned-up version of the CLR
interop doc. And readthedocs.org will take care of hosting.

- Jeff

From jdhardy at gmail.com  Thu Apr 10 10:23:26 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 10 Apr 2014 09:23:26 +0100
Subject: [Ironpython-users] SymPy and IronPython 2.7.4
In-Reply-To: <CA+7conm1KB69GGzGbKK3Ew_N8q9faK-YY16WGkOs06VPMzrpbg@mail.gmail.com>
References: <534277DB.8090809@britishideas.com>
 <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
 <534315B1.5050907@britishideas.com>
 <CAF7AXFHKnXVTiO4pV6zZ2izMU3Mmk504Ow+=Wn2Pg4_yF4=YhQ@mail.gmail.com>
 <5343AE9B.90205@britishideas.com>
 <CAF7AXFFK_hYdDi=H1RXvF8+ZtYYJ-8hx5sEzettbKuR1Ych8Fg@mail.gmail.com>
 <5343C692.4030509@britishideas.com>
 <CA+7conmvb4TY+=q=ggFZLfQeBw9ijD0Jani4BRVe3NU1n88gFA@mail.gmail.com>
 <5344FFBC.7060701@britishideas.com>
 <CA+7conkg26-vLAUKXz9yaGVxwsYgNj40UXvEfDD9JOv0fvODwg@mail.gmail.com>
 <53464BC3.4050108@britishideas.com>
 <CA+7conm1KB69GGzGbKK3Ew_N8q9faK-YY16WGkOs06VPMzrpbg@mail.gmail.com>
Message-ID: <CAF7AXFE2NpnW3hY2y1FBDm=wzYa=hp0kT6akEcYiuNZ91yhQcw@mail.gmail.com>

On Thu, Apr 10, 2014 at 9:09 AM, Pawel Jasinski
<pawel.jasinski at gmail.com> wrote:
> I have opened a cp: https://ironpython.codeplex.com/workitem/35116
> I have a fix, but before push request  I need to check if it doesn't
> break something else.
> It needs a to be reviewed and hopefully it is not to late for 2.7.5.

You'll be fine. There's a few other showstoppers I want to get fixed
as well (http://bit.ly/1gbwn7O) so it's going to slip a bit from my
original late-April estimate.

From vernondcole at gmail.com  Thu Apr 10 11:05:50 2014
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Thu, 10 Apr 2014 03:05:50 -0600
Subject: [Ironpython-users] IronPython 3 Version Number (Was: Item 34263
 in 2.7.5?)
In-Reply-To: <CAF7AXFEbygNU4-b_oTVgD4f3zJjH3snoe_iB-w2MfcYUP+tSmQ@mail.gmail.com>
References: <CAF7AXFEbygNU4-b_oTVgD4f3zJjH3snoe_iB-w2MfcYUP+tSmQ@mail.gmail.com>
Message-ID: <CAH-ZgAeF7ENvLeicEHx2U_UehduvJD7m=f8J61Hx5X9+KG5qvQ@mail.gmail.com>

Jeff Hardy stated:..

> In addition, 3.0 will include most (but perhaps not all!) of 3.4's
> features, mainly because I'd like to see a release later this year
> (around October) and things like nonlocal or importlib could slip
> because they're hard and not terribly exciting. Calling a release like
> that 3.4 is a problem because it's really not 3.4-compatible.
>
> True, but calling it 3.3 would not be a problem, I think.


> Once the Python 3 features are in place, I want to make it as
> cross-platform as possible - iOS, Android, Windows 8, etc. That would
> strongly imply a new version number since it will require a new DLR
> version to be used (not very good to slip a DLR version change into a
> 3.4.z release). Hence I'd prefer to keep the ability to call it 3.1
> (or whatever) instead.
>

Well, speaking of cross-platform, most of my work in the near future will
probably be on Mono -- so different DLRs will be kind of a normal thing.  I
don't have a problem with that being a factor in a point-level release --
it is an implementation detail, not a language change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140410/5d54a230/attachment.html>

From jdhardy at gmail.com  Thu Apr 10 12:39:24 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 10 Apr 2014 11:39:24 +0100
Subject: [Ironpython-users] IronPython 3 Version Number (Was: Item 34263
 in 2.7.5?)
In-Reply-To: <CAH-ZgAeF7ENvLeicEHx2U_UehduvJD7m=f8J61Hx5X9+KG5qvQ@mail.gmail.com>
References: <CAF7AXFEbygNU4-b_oTVgD4f3zJjH3snoe_iB-w2MfcYUP+tSmQ@mail.gmail.com>
 <CAH-ZgAeF7ENvLeicEHx2U_UehduvJD7m=f8J61Hx5X9+KG5qvQ@mail.gmail.com>
Message-ID: <CAF7AXFEbY2vDCiyQoM3f02SSArPbi21Sn2acjtW1_Vqmug2kEQ@mail.gmail.com>

On Thu, Apr 10, 2014 at 10:05 AM, Vernon D. Cole <vernondcole at gmail.com> wrote:
> Jeff Hardy stated:..
>>
>> In addition, 3.0 will include most (but perhaps not all!) of 3.4's
>> features, mainly because I'd like to see a release later this year
>> (around October) and things like nonlocal or importlib could slip
>> because they're hard and not terribly exciting. Calling a release like
>> that 3.4 is a problem because it's really not 3.4-compatible.
>>
> True, but calling it 3.3 would not be a problem, I think.

But it wouldn't be 3.3 either, since nonlocal was added in 3.0. (And
I'm not saying we won't get to nonlocal, it's just an example).
IronPython 3 likely isn't going to line up with any CPython 3 release
feature-wise at first.

>
>>
>> Once the Python 3 features are in place, I want to make it as
>> cross-platform as possible - iOS, Android, Windows 8, etc. That would
>> strongly imply a new version number since it will require a new DLR
>> version to be used (not very good to slip a DLR version change into a
>> 3.4.z release). Hence I'd prefer to keep the ability to call it 3.1
>> (or whatever) instead.
>
>
> Well, speaking of cross-platform, most of my work in the near future will
> probably be on Mono -- so different DLRs will be kind of a normal thing.  I
> don't have a problem with that being a factor in a point-level release -- it
> is an implementation detail, not a language change.

It's an issue if there are multiple languages depending on the same
DLR version, which was one of the promises of the DLR. Now, I'm not
sure anyone *uses* that ability, but I don't want to casually throw it
away, either.

I think there's an expectation that in an x.y.z scheme, z releases
should not make major changes. If IronPython's x.y is fixed to
CPython's, then our ability to make major changes is tied to CPython's
~18 month release schedule. At least for the next few releases I'd
like the flexibility to increase version numbers in accordance with
expected norms (i.e. as close to semver as we can manage), but if/when
we catch up then maybe it makes sense to synchronize.

- Jeff

From no_reply at codeplex.com  Fri Apr 11 09:30:27 2014
From: no_reply at codeplex.com (CodePlex)
Date: 11 Apr 2014 00:30:27 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/10/2014
Message-ID: <CO1MSDNADMCDS25aYY60001fd5f@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New issue] IronPython.dll has wrong assembly version
2. [New issue] Try in the browser crash

----------------------------------------------

ISSUES

1. [New issue] IronPython.dll has wrong assembly version
http://ironpython.codeplex.com/workitem/35119
User DanielWolf has proposed the issue:

"For several versions now, IronPython.dll has had the wrong assembly version:

File version: 2.7.2.1001; assembly version: 2.7.0.40
File version: 2.7.3.1001; assembly version: 2.7.0.40

File version: 2.7.4.1001; assembly version: 2.7.0.40


The problem is that when trying to load an assembly, the GAC only looks at the assembly version, not the file version. So to the GAC, these three files are identical. This can lead to all kinds of nasty behavior.

In our case, the correct IronPython.dll (2.7.3) was lying just beside the .exe file. But because the assembly has a strong name, .NET first tried to load the assembly from the GAC. There happened to be an old 2.7.2 version in the GAC, but as both files share the same assembly version, .NET happily loaded the old version from the GAC. Due to a bug in 2.7.2, our application instantly crashed.

This is a critical issue. Depending on whether our end users happen to have an old version of IronPython installed, our software may or may not work on their machines.
Note that the other IronPython assemblies may well share this versioning error."-----------------

2. [New issue] Try in the browser crash
http://ironpython.codeplex.com/workitem/35121
User JordiMasip has proposed the issue:

"I have the latest Silverlight version but I can't run the IronPython console. I've attached an screenshot:"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140411/4085e358/attachment.html>

From olof.bjarnason at gmail.com  Fri Apr 11 09:50:29 2014
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Fri, 11 Apr 2014 08:50:29 +0100
Subject: [Ironpython-users] IronPython 3 Version Number (Was: Item 34263
 in 2.7.5?)
In-Reply-To: <CAF7AXFEbY2vDCiyQoM3f02SSArPbi21Sn2acjtW1_Vqmug2kEQ@mail.gmail.com>
References: <CAF7AXFEbygNU4-b_oTVgD4f3zJjH3snoe_iB-w2MfcYUP+tSmQ@mail.gmail.com>
 <CAH-ZgAeF7ENvLeicEHx2U_UehduvJD7m=f8J61Hx5X9+KG5qvQ@mail.gmail.com>
 <CAF7AXFEbY2vDCiyQoM3f02SSArPbi21Sn2acjtW1_Vqmug2kEQ@mail.gmail.com>
Message-ID: <CA+LucOh2doMQTZVU3h-0rYvJw7nb5tW7_bK3-sHwTcrNNpj_PA@mail.gmail.com>

To just add my relative outsider opinion (new user of IronPython, 5+
year user of CPython).

As long as a IronPython version does not adhere 100% to a CPython
version, it does not make sense to follow same version name
convention.

Better then to have a completely different "scale", e.g. 0.xyz. In
fact, as long as IronPython doesn't adhere to CPython <some version>,
does it even make sense to have a version beyond 1.0?

On the topic of Python compliance, how do you determine exactly how
compliant IronPython is? How does PyPy determine this?

On 10 April 2014 11:39, Jeff Hardy <jdhardy at gmail.com> wrote:
> On Thu, Apr 10, 2014 at 10:05 AM, Vernon D. Cole <vernondcole at gmail.com> wrote:
>> Jeff Hardy stated:..
>>>
>>> In addition, 3.0 will include most (but perhaps not all!) of 3.4's
>>> features, mainly because I'd like to see a release later this year
>>> (around October) and things like nonlocal or importlib could slip
>>> because they're hard and not terribly exciting. Calling a release like
>>> that 3.4 is a problem because it's really not 3.4-compatible.
>>>
>> True, but calling it 3.3 would not be a problem, I think.
>
> But it wouldn't be 3.3 either, since nonlocal was added in 3.0. (And
> I'm not saying we won't get to nonlocal, it's just an example).
> IronPython 3 likely isn't going to line up with any CPython 3 release
> feature-wise at first.
>
>>
>>>
>>> Once the Python 3 features are in place, I want to make it as
>>> cross-platform as possible - iOS, Android, Windows 8, etc. That would
>>> strongly imply a new version number since it will require a new DLR
>>> version to be used (not very good to slip a DLR version change into a
>>> 3.4.z release). Hence I'd prefer to keep the ability to call it 3.1
>>> (or whatever) instead.
>>
>>
>> Well, speaking of cross-platform, most of my work in the near future will
>> probably be on Mono -- so different DLRs will be kind of a normal thing.  I
>> don't have a problem with that being a factor in a point-level release -- it
>> is an implementation detail, not a language change.
>
> It's an issue if there are multiple languages depending on the same
> DLR version, which was one of the promises of the DLR. Now, I'm not
> sure anyone *uses* that ability, but I don't want to casually throw it
> away, either.
>
> I think there's an expectation that in an x.y.z scheme, z releases
> should not make major changes. If IronPython's x.y is fixed to
> CPython's, then our ability to make major changes is tied to CPython's
> ~18 month release schedule. At least for the next few releases I'd
> like the flexibility to increase version numbers in accordance with
> expected norms (i.e. as close to semver as we can manage), but if/when
> we catch up then maybe it makes sense to synchronize.
>
> - Jeff
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users

From andy at britishideas.com  Fri Apr 11 10:46:32 2014
From: andy at britishideas.com (Andrew Ayre)
Date: Fri, 11 Apr 2014 09:46:32 +0100
Subject: [Ironpython-users] SymPy and IronPython 2.7.4
In-Reply-To: <CA+7conm1KB69GGzGbKK3Ew_N8q9faK-YY16WGkOs06VPMzrpbg@mail.gmail.com>
References: <534277DB.8090809@britishideas.com>
 <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
 <534315B1.5050907@britishideas.com>
 <CAF7AXFHKnXVTiO4pV6zZ2izMU3Mmk504Ow+=Wn2Pg4_yF4=YhQ@mail.gmail.com>
 <5343AE9B.90205@britishideas.com>
 <CAF7AXFFK_hYdDi=H1RXvF8+ZtYYJ-8hx5sEzettbKuR1Ych8Fg@mail.gmail.com>
 <5343C692.4030509@britishideas.com>
 <CA+7conmvb4TY+=q=ggFZLfQeBw9ijD0Jani4BRVe3NU1n88gFA@mail.gmail.com>
 <5344FFBC.7060701@britishideas.com>
 <CA+7conkg26-vLAUKXz9yaGVxwsYgNj40UXvEfDD9JOv0fvODwg@mail.gmail.com>
 <53464BC3.4050108@britishideas.com>
 <CA+7conm1KB69GGzGbKK3Ew_N8q9faK-YY16WGkOs06VPMzrpbg@mail.gmail.com>
Message-ID: <5347ABE8.1070906@britishideas.com>

Hi,

I didn't realize that SymPy has a test suite built in. Trying to run it
gives:

=========================================================
>>>sympy.test()

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Program Files
(x86)\WizoScript\PythonLib\site-packages\sympy\utilities\runtests.py",
line 415, in test
  File "C:\Program Files
(x86)\WizoScript\PythonLib\site-packages\sympy\utilities\runtests.py",
line 188, in run_in_subprocess_with_hash_randomization
  File "C:\Program Files (x86)\WizoScript\PythonLib\subprocess.py", line
675, in __init__
  File "C:\Program Files (x86)\WizoScript\PythonLib\subprocess.py", line
853, in _execute_child
  File "C:\Program Files (x86)\WizoScript\PythonLib\subprocess.py", line
588, in list2cmdline
TypeError: argument of type 'str' is not iterable
=========================================================

Looking at the problem line, it is:

needquote = (" " in arg) or ("\t" in arg) or not arg

I'm guessing it doesn't like:

for arg in seq ??

Andy

On 4/10/2014 9:09 AM, Pawel Jasinski wrote:
> I have opened a cp: https://ironpython.codeplex.com/workitem/35116
> I have a fix, but before push request  I need to check if it doesn't
> break something else.
> It needs a to be reviewed and hopefully it is not to late for 2.7.5.
> --pawel
> 
> 
> On Thu, Apr 10, 2014 at 9:44 AM, Andrew Ayre <andy at britishideas.com> wrote:
>> Hi,
>>
>> This workaround is working well, but will there be a fix to IronPython
>> so it isn't needed?
>>
>> I need to give feedback to the SymPy people.
>>
>> Thanks! Andy
>>
>> On 4/9/2014 10:02 AM, Pawel Jasinski wrote:
>>> Here is the workaround which let me install the package:
>>>
>>> *** sympy/__init__.py.orig      2014-04-09 10:59:53.361779800 +0200
>>> --- sympy/__init__.py   2014-04-09 11:00:02.906734200 +0200
>>> ***************
>>> *** 30,35 ****
>>> --- 30,36 ----
>>>   SYMPY_DEBUG = __sympy_debug()
>>>
>>>   from .core import *
>>> + del sets
>>>   from .logic import *
>>>   from .assumptions import *
>>>   from .polys import *
>>>
>>>
>>>
>>> On Wed, Apr 9, 2014 at 10:07 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>> OK. Is there a workaround I can use?
>>>>
>>>> Andy
>>>>
>>>> On 4/8/2014 8:04 PM, Pawel Jasinski wrote:
>>>>> It looks like the import bug, but is different.
>>>>> This time imported is confusing already imported:  sympy.core.sets
>>>>> with sympy.sets. Is is looking for  sympy.sets.fancysets in sympty.core.sets
>>>>>
>>>>> On Tue, Apr 8, 2014 at 11:51 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>>> On 4/8/2014 10:28 AM, Jeff Hardy wrote:
>>>>>>> On Tue, Apr 8, 2014 at 9:08 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>>>>> Thanks. Making progress... Now it can't find sympy.sets.fancysets. I've
>>>>>>>> added the folder where the module is defined to sys.path:
>>>>>>>>
>>>>>>>> =============================================
>>>>>>>>>>> sys.path.append('../../PythonLib/sympy/sets')
>>>>>>>>
>>>>>>>>>>> sys.path
>>>>>>>>
>>>>>>>> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
>>>>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
>>>>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
>>>>>>>> '../../PythonLib', '../../PythonLib', '../../PythonLib/sympy/mpmath',
>>>>>>>> '../../PythonLib/sympy/sets']
>>>>>>>>
>>>>>>>>>> >from sympy.sets.fancysets import Naturals0
>>>>>>>>
>>>>>>>> Traceback (most recent call last):
>>>>>>>>   File "<string>", line 1, in <module>
>>>>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
>>>>>>>> line 34, in <module>
>>>>>>>>   File
>>>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
>>>>>>>> line 2, in <module>
>>>>>>>>   File
>>>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
>>>>>>>> line 323, in <module>
>>>>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
>>>>>>>> line 93, in wrapper
>>>>>>>>   File
>>>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
>>>>>>>> line 185, in __new__
>>>>>>>> ImportError: No module named fancysets
>>>>>>>> =============================================
>>>>>>>>
>>>>>>>> Here is what the folder structure looks like:
>>>>>>>>
>>>>>>>> https://github.com/sympy/sympy/tree/master/sympy/sets
>>>>>>>
>>>>>>> Which version of IronPython? It sure looks like the import bug, but if
>>>>>>> you're still hitting in 2.7.5b1 then we'll have to reopen it.
>>>>>>
>>>>>> Jeff,
>>>>>>
>>>>>> Here is my sanity check:
>>>>>>
>>>>>> =============================================
>>>>>>>>> sys.version
>>>>>>
>>>>>> '2.7.5b1 (IronPython 2.7.5b1 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit))'
>>>>>> =============================================
>>>>>>
>>>>>> I'm using the pre-compiled binary version.
>>>>>>
>>>>>> Thanks, Andy
>>>>>>
>>>>>> --
>>>>>> Andy
>>>>>> PGP Key ID: 0xDC1B5864
>>>>>> _______________________________________________
>>>>>> Ironpython-users mailing list
>>>>>> Ironpython-users at python.org
>>>>>> https://mail.python.org/mailman/listinfo/ironpython-users
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Andy
>>>> PGP Key ID: 0xDC1B5864
>>>
>>>
>>>
>>
>> --
>> Andy
>> PGP Key ID: 0xDC1B5864
> 
> 
> 

-- 
Andy
PGP Key ID: 0xDC1B5864

From vernondcole at gmail.com  Fri Apr 11 11:52:18 2014
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Fri, 11 Apr 2014 03:52:18 -0600
Subject: [Ironpython-users] IronPython 3 Version Number (Was: Item 34263
 in 2.7.5?)
In-Reply-To: <CA+LucOh2doMQTZVU3h-0rYvJw7nb5tW7_bK3-sHwTcrNNpj_PA@mail.gmail.com>
References: <CAF7AXFEbygNU4-b_oTVgD4f3zJjH3snoe_iB-w2MfcYUP+tSmQ@mail.gmail.com>
 <CAH-ZgAeF7ENvLeicEHx2U_UehduvJD7m=f8J61Hx5X9+KG5qvQ@mail.gmail.com>
 <CAF7AXFEbY2vDCiyQoM3f02SSArPbi21Sn2acjtW1_Vqmug2kEQ@mail.gmail.com>
 <CA+LucOh2doMQTZVU3h-0rYvJw7nb5tW7_bK3-sHwTcrNNpj_PA@mail.gmail.com>
Message-ID: <CAH-ZgAf+zxm9fu3qMK25xj8AOeAjZvfdJaK-GXWhSTWPZ20S_g@mail.gmail.com>

Compliance is determined by running the same test suite as CPython (the
reference implementation).  The only tricky part is, should a test fail,
determining whether it is testing a language feature (must fix) or an
implementation detail (can skip).
   For example, tests involving the Garbage Collector or GIL would be
skipped, because IronPython does not use them.


On Fri, Apr 11, 2014 at 1:50 AM, Olof Bjarnason <olof.bjarnason at gmail.com>wrote:

> To just add my relative outsider opinion (new user of IronPython, 5+
> year user of CPython).
>
> As long as a IronPython version does not adhere 100% to a CPython
> version, it does not make sense to follow same version name
> convention.
>
> Better then to have a completely different "scale", e.g. 0.xyz. In
> fact, as long as IronPython doesn't adhere to CPython <some version>,
> does it even make sense to have a version beyond 1.0?
>
> On the topic of Python compliance, how do you determine exactly how
> compliant IronPython is? How does PyPy determine this?
>
> On 10 April 2014 11:39, Jeff Hardy <jdhardy at gmail.com> wrote:
> > On Thu, Apr 10, 2014 at 10:05 AM, Vernon D. Cole <vernondcole at gmail.com>
> wrote:
> >> Jeff Hardy stated:..
> >>>
> >>> In addition, 3.0 will include most (but perhaps not all!) of 3.4's
> >>> features, mainly because I'd like to see a release later this year
> >>> (around October) and things like nonlocal or importlib could slip
> >>> because they're hard and not terribly exciting. Calling a release like
> >>> that 3.4 is a problem because it's really not 3.4-compatible.
> >>>
> >> True, but calling it 3.3 would not be a problem, I think.
> >
> > But it wouldn't be 3.3 either, since nonlocal was added in 3.0. (And
> > I'm not saying we won't get to nonlocal, it's just an example).
> > IronPython 3 likely isn't going to line up with any CPython 3 release
> > feature-wise at first.
> >
> >>
> >>>
> >>> Once the Python 3 features are in place, I want to make it as
> >>> cross-platform as possible - iOS, Android, Windows 8, etc. That would
> >>> strongly imply a new version number since it will require a new DLR
> >>> version to be used (not very good to slip a DLR version change into a
> >>> 3.4.z release). Hence I'd prefer to keep the ability to call it 3.1
> >>> (or whatever) instead.
> >>
> >>
> >> Well, speaking of cross-platform, most of my work in the near future
> will
> >> probably be on Mono -- so different DLRs will be kind of a normal
> thing.  I
> >> don't have a problem with that being a factor in a point-level release
> -- it
> >> is an implementation detail, not a language change.
> >
> > It's an issue if there are multiple languages depending on the same
> > DLR version, which was one of the promises of the DLR. Now, I'm not
> > sure anyone *uses* that ability, but I don't want to casually throw it
> > away, either.
> >
> > I think there's an expectation that in an x.y.z scheme, z releases
> > should not make major changes. If IronPython's x.y is fixed to
> > CPython's, then our ability to make major changes is tied to CPython's
> > ~18 month release schedule. At least for the next few releases I'd
> > like the flexibility to increase version numbers in accordance with
> > expected norms (i.e. as close to semver as we can manage), but if/when
> > we catch up then maybe it makes sense to synchronize.
> >
> > - Jeff
> > _______________________________________________
> > Ironpython-users mailing list
> > Ironpython-users at python.org
> > https://mail.python.org/mailman/listinfo/ironpython-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140411/4496acd1/attachment.html>

From olof.bjarnason at gmail.com  Fri Apr 11 12:02:21 2014
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Fri, 11 Apr 2014 11:02:21 +0100
Subject: [Ironpython-users] IronPython 3 Version Number (Was: Item 34263
 in 2.7.5?)
In-Reply-To: <CAH-ZgAf+zxm9fu3qMK25xj8AOeAjZvfdJaK-GXWhSTWPZ20S_g@mail.gmail.com>
References: <CAF7AXFEbygNU4-b_oTVgD4f3zJjH3snoe_iB-w2MfcYUP+tSmQ@mail.gmail.com>
 <CAH-ZgAeF7ENvLeicEHx2U_UehduvJD7m=f8J61Hx5X9+KG5qvQ@mail.gmail.com>
 <CAF7AXFEbY2vDCiyQoM3f02SSArPbi21Sn2acjtW1_Vqmug2kEQ@mail.gmail.com>
 <CA+LucOh2doMQTZVU3h-0rYvJw7nb5tW7_bK3-sHwTcrNNpj_PA@mail.gmail.com>
 <CAH-ZgAf+zxm9fu3qMK25xj8AOeAjZvfdJaK-GXWhSTWPZ20S_g@mail.gmail.com>
Message-ID: <CA+LucOgV7y1dmGUnTEKjPn2sSeULD0bEwQ6kNE2BvwEo9zqxpA@mail.gmail.com>

OK, that sounds like a reasonable way to do it. Very nice that it is
automatically verifiable!

But it opens more questions from me, sorry. I find this interesting :)

So when an automatic test, that is determined to be a implementation
detail, fails - how does IronPython "skip" it? Is the actual test
suite specific for IronPython? I mean, is the unit tests in IronPython
a fork of CPythons test suite?

Anyone know how many per cent of the CPython test suite that IronPython pass?


On 11 April 2014 10:52, Vernon D. Cole <vernondcole at gmail.com> wrote:
> Compliance is determined by running the same test suite as CPython (the
> reference implementation).  The only tricky part is, should a test fail,
> determining whether it is testing a language feature (must fix) or an
> implementation detail (can skip).
>    For example, tests involving the Garbage Collector or GIL would be
> skipped, because IronPython does not use them.
>
>
> On Fri, Apr 11, 2014 at 1:50 AM, Olof Bjarnason <olof.bjarnason at gmail.com>
> wrote:
>>
>> To just add my relative outsider opinion (new user of IronPython, 5+
>> year user of CPython).
>>
>> As long as a IronPython version does not adhere 100% to a CPython
>> version, it does not make sense to follow same version name
>> convention.
>>
>> Better then to have a completely different "scale", e.g. 0.xyz. In
>> fact, as long as IronPython doesn't adhere to CPython <some version>,
>> does it even make sense to have a version beyond 1.0?
>>
>> On the topic of Python compliance, how do you determine exactly how
>> compliant IronPython is? How does PyPy determine this?
>>
>> On 10 April 2014 11:39, Jeff Hardy <jdhardy at gmail.com> wrote:
>> > On Thu, Apr 10, 2014 at 10:05 AM, Vernon D. Cole <vernondcole at gmail.com>
>> > wrote:
>> >> Jeff Hardy stated:..
>> >>>
>> >>> In addition, 3.0 will include most (but perhaps not all!) of 3.4's
>> >>> features, mainly because I'd like to see a release later this year
>> >>> (around October) and things like nonlocal or importlib could slip
>> >>> because they're hard and not terribly exciting. Calling a release like
>> >>> that 3.4 is a problem because it's really not 3.4-compatible.
>> >>>
>> >> True, but calling it 3.3 would not be a problem, I think.
>> >
>> > But it wouldn't be 3.3 either, since nonlocal was added in 3.0. (And
>> > I'm not saying we won't get to nonlocal, it's just an example).
>> > IronPython 3 likely isn't going to line up with any CPython 3 release
>> > feature-wise at first.
>> >
>> >>
>> >>>
>> >>> Once the Python 3 features are in place, I want to make it as
>> >>> cross-platform as possible - iOS, Android, Windows 8, etc. That would
>> >>> strongly imply a new version number since it will require a new DLR
>> >>> version to be used (not very good to slip a DLR version change into a
>> >>> 3.4.z release). Hence I'd prefer to keep the ability to call it 3.1
>> >>> (or whatever) instead.
>> >>
>> >>
>> >> Well, speaking of cross-platform, most of my work in the near future
>> >> will
>> >> probably be on Mono -- so different DLRs will be kind of a normal
>> >> thing.  I
>> >> don't have a problem with that being a factor in a point-level release
>> >> -- it
>> >> is an implementation detail, not a language change.
>> >
>> > It's an issue if there are multiple languages depending on the same
>> > DLR version, which was one of the promises of the DLR. Now, I'm not
>> > sure anyone *uses* that ability, but I don't want to casually throw it
>> > away, either.
>> >
>> > I think there's an expectation that in an x.y.z scheme, z releases
>> > should not make major changes. If IronPython's x.y is fixed to
>> > CPython's, then our ability to make major changes is tied to CPython's
>> > ~18 month release schedule. At least for the next few releases I'd
>> > like the flexibility to increase version numbers in accordance with
>> > expected norms (i.e. as close to semver as we can manage), but if/when
>> > we catch up then maybe it makes sense to synchronize.
>> >
>> > - Jeff
>> > _______________________________________________
>> > Ironpython-users mailing list
>> > Ironpython-users at python.org
>> > https://mail.python.org/mailman/listinfo/ironpython-users
>
>

From jdhardy at gmail.com  Fri Apr 11 12:20:30 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 11 Apr 2014 11:20:30 +0100
Subject: [Ironpython-users] IronPython 3 Version Number (Was: Item 34263
 in 2.7.5?)
In-Reply-To: <CA+LucOgV7y1dmGUnTEKjPn2sSeULD0bEwQ6kNE2BvwEo9zqxpA@mail.gmail.com>
References: <CAF7AXFEbygNU4-b_oTVgD4f3zJjH3snoe_iB-w2MfcYUP+tSmQ@mail.gmail.com>
 <CAH-ZgAeF7ENvLeicEHx2U_UehduvJD7m=f8J61Hx5X9+KG5qvQ@mail.gmail.com>
 <CAF7AXFEbY2vDCiyQoM3f02SSArPbi21Sn2acjtW1_Vqmug2kEQ@mail.gmail.com>
 <CA+LucOh2doMQTZVU3h-0rYvJw7nb5tW7_bK3-sHwTcrNNpj_PA@mail.gmail.com>
 <CAH-ZgAf+zxm9fu3qMK25xj8AOeAjZvfdJaK-GXWhSTWPZ20S_g@mail.gmail.com>
 <CA+LucOgV7y1dmGUnTEKjPn2sSeULD0bEwQ6kNE2BvwEo9zqxpA@mail.gmail.com>
Message-ID: <CAF7AXFF-dyF38jBnEKioWR+YsF=8EfUHjda+9qy5cF9WPodW2Q@mail.gmail.com>

On Fri, Apr 11, 2014 at 11:02 AM, Olof Bjarnason
<olof.bjarnason at gmail.com> wrote:
> OK, that sounds like a reasonable way to do it. Very nice that it is
> automatically verifiable!
>
> But it opens more questions from me, sorry. I find this interesting :)
>
> So when an automatic test, that is determined to be a implementation
> detail, fails - how does IronPython "skip" it? Is the actual test
> suite specific for IronPython? I mean, is the unit tests in IronPython
> a fork of CPythons test suite?

Yes, since the test suite is part of the stdlib. Unittest supports an
@skipIf decorator; we just use @skipIf(sys.platform == 'cli') (or
occasionally wrap the function or part of the function in a similar
if: statement).

> Anyone know how many per cent of the CPython test suite that IronPython pass?

Nope :) To be honest, for 2.7 it's a bit of a mess. There was just
never a concerted effort to drive the number down, because there were
so many issues. The difference in string types always meant we would
ever reach 100%, and refcounting dependencies are tedious and un-fun
to debug.

For IronPython 3, we're going to work with the Jython and PyPy devs to
make the test suite work for all of us (and the PyPy team has already
done a tone of work here). More importantly, it's all going to get
pushed upstream so that we can minimize the forking necessary.
Combined with the new NUnitLite-based test runner in IronPython 3
(even running the tests for IronPython 2.7 is a chore) we should be
able to get much closer to 100% coverage.

This is probably the single biggest reason I'm excited about IP3 -
compatibility is actually a realistic goal. There will always be some
things that we can't match, but we should be able to get really close
now.

Once 2.7.5 is done I'm going to spend some time getting the CI
infrastructure up to par for 3.0 and making sure that tests are run on
a regular basis. By making it easier to actually contribute I'm hoping
to attract a few more people - understanding IronPython is hard enough
without having to understand the Byzantine build/test system 2.7 has
(OK, the build system is still complex - trying to target 8 different
platforms is hard).

- Jeff

From m.schaber at codesys.com  Fri Apr 11 12:40:21 2014
From: m.schaber at codesys.com (Markus Schaber)
Date: Fri, 11 Apr 2014 10:40:21 +0000
Subject: [Ironpython-users] IronPython 3 Version Number (Was: Item 34263
 in 2.7.5?)
In-Reply-To: <CAF7AXFF-dyF38jBnEKioWR+YsF=8EfUHjda+9qy5cF9WPodW2Q@mail.gmail.com>
References: <CAF7AXFEbygNU4-b_oTVgD4f3zJjH3snoe_iB-w2MfcYUP+tSmQ@mail.gmail.com>
 <CAH-ZgAeF7ENvLeicEHx2U_UehduvJD7m=f8J61Hx5X9+KG5qvQ@mail.gmail.com>
 <CAF7AXFEbY2vDCiyQoM3f02SSArPbi21Sn2acjtW1_Vqmug2kEQ@mail.gmail.com>
 <CA+LucOh2doMQTZVU3h-0rYvJw7nb5tW7_bK3-sHwTcrNNpj_PA@mail.gmail.com>
 <CAH-ZgAf+zxm9fu3qMK25xj8AOeAjZvfdJaK-GXWhSTWPZ20S_g@mail.gmail.com>
 <CA+LucOgV7y1dmGUnTEKjPn2sSeULD0bEwQ6kNE2BvwEo9zqxpA@mail.gmail.com>
 <CAF7AXFF-dyF38jBnEKioWR+YsF=8EfUHjda+9qy5cF9WPodW2Q@mail.gmail.com>
Message-ID: <727D8E16AE957149B447FE368139F2B539B9CF53@SERVER10>

Hi,

Von: Jeff Hardy
> On Fri, Apr 11, 2014 at 11:02 AM, Olof Bjarnason <olof.bjarnason at gmail.com>
> wrote:
> > OK, that sounds like a reasonable way to do it. Very nice that it is
> > automatically verifiable!
> >
> > But it opens more questions from me, sorry. I find this interesting :)
> >
> > So when an automatic test, that is determined to be a implementation
> > detail, fails - how does IronPython "skip" it? Is the actual test
> > suite specific for IronPython? I mean, is the unit tests in IronPython
> > a fork of CPythons test suite?
> 
> Yes, since the test suite is part of the stdlib. Unittest supports an @skipIf
> decorator; we just use @skipIf(sys.platform == 'cli') (or occasionally wrap
> the function or part of the function in a similar
> if: statement).
> 
> > Anyone know how many per cent of the CPython test suite that IronPython
> pass?
> 
> Nope :) To be honest, for 2.7 it's a bit of a mess. There was just never a
> concerted effort to drive the number down, because there were so many issues.
> The difference in string types always meant we would ever reach 100%, and
> refcounting dependencies are tedious and un-fun to debug.
> 
> For IronPython 3, we're going to work with the Jython and PyPy devs to make
> the test suite work for all of us (and the PyPy team has already done a tone
> of work here). More importantly, it's all going to get pushed upstream so
> that we can minimize the forking necessary.
> Combined with the new NUnitLite-based test runner in IronPython 3 (even
> running the tests for IronPython 2.7 is a chore) we should be able to get
> much closer to 100% coverage.
> 
> This is probably the single biggest reason I'm excited about IP3 -
> compatibility is actually a realistic goal. There will always be some things
> that we can't match, but we should be able to get really close now.

One detail where we won't be 100% compatible is indexing into strings with Non-BMP 
Characters, as .NET strings are still bound to 16 bit "char"s.

> Once 2.7.5 is done I'm going to spend some time getting the CI infrastructure
> up to par for 3.0 and making sure that tests are run on a regular basis. By
> making it easier to actually contribute I'm hoping to attract a few more
> people - understanding IronPython is hard enough without having to understand
> the Byzantine build/test system 2.7 has (OK, the build system is still
> complex - trying to target 8 different platforms is hard).

Can the new multitargeting support help here?


Best regards

Markus Schaber

CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber at codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915

From jdhardy at gmail.com  Fri Apr 11 12:58:58 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 11 Apr 2014 11:58:58 +0100
Subject: [Ironpython-users] IronPython 3 Version Number (Was: Item 34263
 in 2.7.5?)
In-Reply-To: <727D8E16AE957149B447FE368139F2B539B9CF53@SERVER10>
References: <CAF7AXFEbygNU4-b_oTVgD4f3zJjH3snoe_iB-w2MfcYUP+tSmQ@mail.gmail.com>
 <CAH-ZgAeF7ENvLeicEHx2U_UehduvJD7m=f8J61Hx5X9+KG5qvQ@mail.gmail.com>
 <CAF7AXFEbY2vDCiyQoM3f02SSArPbi21Sn2acjtW1_Vqmug2kEQ@mail.gmail.com>
 <CA+LucOh2doMQTZVU3h-0rYvJw7nb5tW7_bK3-sHwTcrNNpj_PA@mail.gmail.com>
 <CAH-ZgAf+zxm9fu3qMK25xj8AOeAjZvfdJaK-GXWhSTWPZ20S_g@mail.gmail.com>
 <CA+LucOgV7y1dmGUnTEKjPn2sSeULD0bEwQ6kNE2BvwEo9zqxpA@mail.gmail.com>
 <CAF7AXFF-dyF38jBnEKioWR+YsF=8EfUHjda+9qy5cF9WPodW2Q@mail.gmail.com>
 <727D8E16AE957149B447FE368139F2B539B9CF53@SERVER10>
Message-ID: <CAF7AXFEp_17qarDT4DYx_uXuemUOJ+E=mmSVGnUwHBALem563g@mail.gmail.com>

On Fri, Apr 11, 2014 at 11:40 AM, Markus Schaber <m.schaber at codesys.com> wrote:
> Hi,
>
> Von: Jeff Hardy
>> On Fri, Apr 11, 2014 at 11:02 AM, Olof Bjarnason <olof.bjarnason at gmail.com>
>> wrote:
>> > OK, that sounds like a reasonable way to do it. Very nice that it is
>> > automatically verifiable!
>> >
>> > But it opens more questions from me, sorry. I find this interesting :)
>> >
>> > So when an automatic test, that is determined to be a implementation
>> > detail, fails - how does IronPython "skip" it? Is the actual test
>> > suite specific for IronPython? I mean, is the unit tests in IronPython
>> > a fork of CPythons test suite?
>>
>> Yes, since the test suite is part of the stdlib. Unittest supports an @skipIf
>> decorator; we just use @skipIf(sys.platform == 'cli') (or occasionally wrap
>> the function or part of the function in a similar
>> if: statement).
>>
>> > Anyone know how many per cent of the CPython test suite that IronPython
>> pass?
>>
>> Nope :) To be honest, for 2.7 it's a bit of a mess. There was just never a
>> concerted effort to drive the number down, because there were so many issues.
>> The difference in string types always meant we would ever reach 100%, and
>> refcounting dependencies are tedious and un-fun to debug.
>>
>> For IronPython 3, we're going to work with the Jython and PyPy devs to make
>> the test suite work for all of us (and the PyPy team has already done a tone
>> of work here). More importantly, it's all going to get pushed upstream so
>> that we can minimize the forking necessary.
>> Combined with the new NUnitLite-based test runner in IronPython 3 (even
>> running the tests for IronPython 2.7 is a chore) we should be able to get
>> much closer to 100% coverage.
>>
>> This is probably the single biggest reason I'm excited about IP3 -
>> compatibility is actually a realistic goal. There will always be some things
>> that we can't match, but we should be able to get really close now.
>
> One detail where we won't be 100% compatible is indexing into strings with Non-BMP
> Characters, as .NET strings are still bound to 16 bit "char"s.

Blech, I just checked this and you're right.

>
>> Once 2.7.5 is done I'm going to spend some time getting the CI infrastructure
>> up to par for 3.0 and making sure that tests are run on a regular basis. By
>> making it easier to actually contribute I'm hoping to attract a few more
>> people - understanding IronPython is hard enough without having to understand
>> the Byzantine build/test system 2.7 has (OK, the build system is still
>> complex - trying to target 8 different platforms is hard).
>
> Can the new multitargeting support help here?

Can you be more specific? If you mean PCLs, eventually the core will
be a PCL with platform assemblies - just not right away (it requires
some deep work in the DLR and extending the existing DLR PAL to handle
a lot more cases).

- Jeff

From m.schaber at codesys.com  Fri Apr 11 13:26:23 2014
From: m.schaber at codesys.com (Markus Schaber)
Date: Fri, 11 Apr 2014 11:26:23 +0000
Subject: [Ironpython-users] IronPython 3 Version Number (Was: Item 34263
 in 2.7.5?)
In-Reply-To: <CAF7AXFEp_17qarDT4DYx_uXuemUOJ+E=mmSVGnUwHBALem563g@mail.gmail.com>
References: <CAF7AXFEbygNU4-b_oTVgD4f3zJjH3snoe_iB-w2MfcYUP+tSmQ@mail.gmail.com>
 <CAH-ZgAeF7ENvLeicEHx2U_UehduvJD7m=f8J61Hx5X9+KG5qvQ@mail.gmail.com>
 <CAF7AXFEbY2vDCiyQoM3f02SSArPbi21Sn2acjtW1_Vqmug2kEQ@mail.gmail.com>
 <CA+LucOh2doMQTZVU3h-0rYvJw7nb5tW7_bK3-sHwTcrNNpj_PA@mail.gmail.com>
 <CAH-ZgAf+zxm9fu3qMK25xj8AOeAjZvfdJaK-GXWhSTWPZ20S_g@mail.gmail.com>
 <CA+LucOgV7y1dmGUnTEKjPn2sSeULD0bEwQ6kNE2BvwEo9zqxpA@mail.gmail.com>
 <CAF7AXFF-dyF38jBnEKioWR+YsF=8EfUHjda+9qy5cF9WPodW2Q@mail.gmail.com>
 <727D8E16AE957149B447FE368139F2B539B9CF53@SERVER10>
 <CAF7AXFEp_17qarDT4DYx_uXuemUOJ+E=mmSVGnUwHBALem563g@mail.gmail.com>
Message-ID: <727D8E16AE957149B447FE368139F2B539B9CF8B@SERVER10>

Hi, Jeff,

Von: Jeff Hardy [mailto:jdhardy at gmail.com]
> On Fri, Apr 11, 2014 at 11:40 AM, Markus Schaber <m.schaber at codesys.com>
> wrote:
> > Hi,
> >
> > Von: Jeff Hardy
> >> On Fri, Apr 11, 2014 at 11:02 AM, Olof Bjarnason
> >> <olof.bjarnason at gmail.com>
> >> wrote:
> >> > OK, that sounds like a reasonable way to do it. Very nice that it
> >> > is automatically verifiable!
> >> >
> >> > But it opens more questions from me, sorry. I find this interesting
> >> > :)
> >> >
> >> > So when an automatic test, that is determined to be a
> >> > implementation detail, fails - how does IronPython "skip" it? Is
> >> > the actual test suite specific for IronPython? I mean, is the unit
> >> > tests in IronPython a fork of CPythons test suite?
> >>
> >> Yes, since the test suite is part of the stdlib. Unittest supports an
> >> @skipIf decorator; we just use @skipIf(sys.platform == 'cli') (or
> >> occasionally wrap the function or part of the function in a similar
> >> if: statement).
> >>
> >> > Anyone know how many per cent of the CPython test suite that
> >> > IronPython
> >> pass?
> >>
> >> Nope :) To be honest, for 2.7 it's a bit of a mess. There was just
> >> never a concerted effort to drive the number down, because there were so
> many issues.
> >> The difference in string types always meant we would ever reach 100%,
> >> and refcounting dependencies are tedious and un-fun to debug.
> >>
> >> For IronPython 3, we're going to work with the Jython and PyPy devs
> >> to make the test suite work for all of us (and the PyPy team has
> >> already done a tone of work here). More importantly, it's all going
> >> to get pushed upstream so that we can minimize the forking necessary.
> >> Combined with the new NUnitLite-based test runner in IronPython 3
> >> (even running the tests for IronPython 2.7 is a chore) we should be
> >> able to get much closer to 100% coverage.
> >>
> >> This is probably the single biggest reason I'm excited about IP3 -
> >> compatibility is actually a realistic goal. There will always be some
> >> things that we can't match, but we should be able to get really close now.
> >
> > One detail where we won't be 100% compatible is indexing into strings
> > with Non-BMP Characters, as .NET strings are still bound to 16 bit "char"s.
> 
> Blech, I just checked this and you're right.

For most use cases, this is not that relevant - it is rare to actually index into a string and work on the codepoints directly.

> >> Once 2.7.5 is done I'm going to spend some time getting the CI
> >> infrastructure up to par for 3.0 and making sure that tests are run
> >> on a regular basis. By making it easier to actually contribute I'm
> >> hoping to attract a few more people - understanding IronPython is
> >> hard enough without having to understand the Byzantine build/test
> >> system 2.7 has (OK, the build system is still complex - trying to target 8
> different platforms is hard).
> >
> > Can the new multitargeting support help here?
> 
> Can you be more specific? If you mean PCLs, eventually the core will be a PCL
> with platform assemblies - just not right away (it requires some deep work in
> the DLR and extending the existing DLR PAL to handle a lot more cases).

Yes, I was thinking of the PCL mechanism, I just got the name wrong...


Best regards

Markus Schaber

CODESYS? a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber at codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915


From pawel.jasinski at gmail.com  Fri Apr 11 23:20:41 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Fri, 11 Apr 2014 23:20:41 +0200
Subject: [Ironpython-users] SymPy and IronPython 2.7.4
In-Reply-To: <5347ABE8.1070906@britishideas.com>
References: <534277DB.8090809@britishideas.com>
 <CA+7conmqFyakgxdh8g+u821JGMZbh8zq7dUqy9nv7BMdtLspRQ@mail.gmail.com>
 <534315B1.5050907@britishideas.com>
 <CAF7AXFHKnXVTiO4pV6zZ2izMU3Mmk504Ow+=Wn2Pg4_yF4=YhQ@mail.gmail.com>
 <5343AE9B.90205@britishideas.com>
 <CAF7AXFFK_hYdDi=H1RXvF8+ZtYYJ-8hx5sEzettbKuR1Ych8Fg@mail.gmail.com>
 <5343C692.4030509@britishideas.com>
 <CA+7conmvb4TY+=q=ggFZLfQeBw9ijD0Jani4BRVe3NU1n88gFA@mail.gmail.com>
 <5344FFBC.7060701@britishideas.com>
 <CA+7conkg26-vLAUKXz9yaGVxwsYgNj40UXvEfDD9JOv0fvODwg@mail.gmail.com>
 <53464BC3.4050108@britishideas.com>
 <CA+7conm1KB69GGzGbKK3Ew_N8q9faK-YY16WGkOs06VPMzrpbg@mail.gmail.com>
 <5347ABE8.1070906@britishideas.com>
Message-ID: <CA+7conmWRcuBHzJJW=RV=BDbh9eKgd3i7ds0aSx6iSQhbTNxjg@mail.gmail.com>

it appears to work for me:

$ bin/Debug/ipy -X:Frames -c 'import sympy; sympy.test()'
============================= test process starts ==============================
executable:
C:\cygwin64\home\rejap\github\IronLanguages\bin\Debug\ipy.exe
(2.9.9-alpha-0) [IronPython]
architecture:       32-bit
cache:              yes
ground types:       python
random seed:        10900661
hash randomization: off

sympy\assumptions\tests\test_assumptions_2.py[5] .....                      [OK]
sympy\assumptions\tests\test_context.py[4] ....                             [OK]
sympy\assumptions\tests\test_matrices.py[19] ..........ff.......            [OK]


But, I think you have exposed an obfuscated exception because str is iterable.
Can you check what the seq is and why it is different than run from
command line.



--pawel


On Fri, Apr 11, 2014 at 10:46 AM, Andrew Ayre <andy at britishideas.com> wrote:
> Hi,
>
> I didn't realize that SymPy has a test suite built in. Trying to run it
> gives:
>
> =========================================================
>>>>sympy.test()
>
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "C:\Program Files
> (x86)\WizoScript\PythonLib\site-packages\sympy\utilities\runtests.py",
> line 415, in test
>   File "C:\Program Files
> (x86)\WizoScript\PythonLib\site-packages\sympy\utilities\runtests.py",
> line 188, in run_in_subprocess_with_hash_randomization
>   File "C:\Program Files (x86)\WizoScript\PythonLib\subprocess.py", line
> 675, in __init__
>   File "C:\Program Files (x86)\WizoScript\PythonLib\subprocess.py", line
> 853, in _execute_child
>   File "C:\Program Files (x86)\WizoScript\PythonLib\subprocess.py", line
> 588, in list2cmdline
> TypeError: argument of type 'str' is not iterable
> =========================================================
>
> Looking at the problem line, it is:
>
> needquote = (" " in arg) or ("\t" in arg) or not arg
>
> I'm guessing it doesn't like:
>
> for arg in seq ??
>
> Andy
>
> On 4/10/2014 9:09 AM, Pawel Jasinski wrote:
>> I have opened a cp: https://ironpython.codeplex.com/workitem/35116
>> I have a fix, but before push request  I need to check if it doesn't
>> break something else.
>> It needs a to be reviewed and hopefully it is not to late for 2.7.5.
>> --pawel
>>
>>
>> On Thu, Apr 10, 2014 at 9:44 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>> Hi,
>>>
>>> This workaround is working well, but will there be a fix to IronPython
>>> so it isn't needed?
>>>
>>> I need to give feedback to the SymPy people.
>>>
>>> Thanks! Andy
>>>
>>> On 4/9/2014 10:02 AM, Pawel Jasinski wrote:
>>>> Here is the workaround which let me install the package:
>>>>
>>>> *** sympy/__init__.py.orig      2014-04-09 10:59:53.361779800 +0200
>>>> --- sympy/__init__.py   2014-04-09 11:00:02.906734200 +0200
>>>> ***************
>>>> *** 30,35 ****
>>>> --- 30,36 ----
>>>>   SYMPY_DEBUG = __sympy_debug()
>>>>
>>>>   from .core import *
>>>> + del sets
>>>>   from .logic import *
>>>>   from .assumptions import *
>>>>   from .polys import *
>>>>
>>>>
>>>>
>>>> On Wed, Apr 9, 2014 at 10:07 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>> OK. Is there a workaround I can use?
>>>>>
>>>>> Andy
>>>>>
>>>>> On 4/8/2014 8:04 PM, Pawel Jasinski wrote:
>>>>>> It looks like the import bug, but is different.
>>>>>> This time imported is confusing already imported:  sympy.core.sets
>>>>>> with sympy.sets. Is is looking for  sympy.sets.fancysets in sympty.core.sets
>>>>>>
>>>>>> On Tue, Apr 8, 2014 at 11:51 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>>>> On 4/8/2014 10:28 AM, Jeff Hardy wrote:
>>>>>>>> On Tue, Apr 8, 2014 at 9:08 AM, Andrew Ayre <andy at britishideas.com> wrote:
>>>>>>>>> Thanks. Making progress... Now it can't find sympy.sets.fancysets. I've
>>>>>>>>> added the folder where the module is defined to sys.path:
>>>>>>>>>
>>>>>>>>> =============================================
>>>>>>>>>>>> sys.path.append('../../PythonLib/sympy/sets')
>>>>>>>>>
>>>>>>>>>>>> sys.path
>>>>>>>>>
>>>>>>>>> ['.', 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\Lib',
>>>>>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\DLLs',
>>>>>>>>> 'C:\\Users\\Andy\\Documents\\ADScript\\bin\\Debug\\PythonLib',
>>>>>>>>> '../../PythonLib', '../../PythonLib', '../../PythonLib/sympy/mpmath',
>>>>>>>>> '../../PythonLib/sympy/sets']
>>>>>>>>>
>>>>>>>>>>> >from sympy.sets.fancysets import Naturals0
>>>>>>>>>
>>>>>>>>> Traceback (most recent call last):
>>>>>>>>>   File "<string>", line 1, in <module>
>>>>>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\__init__.py",
>>>>>>>>> line 34, in <module>
>>>>>>>>>   File
>>>>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\__init__.py",
>>>>>>>>> line 2, in <module>
>>>>>>>>>   File
>>>>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\assumptions\ask.py",
>>>>>>>>> line 323, in <module>
>>>>>>>>>   File "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\cache.py",
>>>>>>>>> line 93, in wrapper
>>>>>>>>>   File
>>>>>>>>> "C:\Users\Andy\Documents\ADScript\PythonLib\sympy\core\function.py",
>>>>>>>>> line 185, in __new__
>>>>>>>>> ImportError: No module named fancysets
>>>>>>>>> =============================================
>>>>>>>>>
>>>>>>>>> Here is what the folder structure looks like:
>>>>>>>>>
>>>>>>>>> https://github.com/sympy/sympy/tree/master/sympy/sets
>>>>>>>>
>>>>>>>> Which version of IronPython? It sure looks like the import bug, but if
>>>>>>>> you're still hitting in 2.7.5b1 then we'll have to reopen it.
>>>>>>>
>>>>>>> Jeff,
>>>>>>>
>>>>>>> Here is my sanity check:
>>>>>>>
>>>>>>> =============================================
>>>>>>>>>> sys.version
>>>>>>>
>>>>>>> '2.7.5b1 (IronPython 2.7.5b1 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit))'
>>>>>>> =============================================
>>>>>>>
>>>>>>> I'm using the pre-compiled binary version.
>>>>>>>
>>>>>>> Thanks, Andy
>>>>>>>
>>>>>>> --
>>>>>>> Andy
>>>>>>> PGP Key ID: 0xDC1B5864
>>>>>>> _______________________________________________
>>>>>>> Ironpython-users mailing list
>>>>>>> Ironpython-users at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/ironpython-users
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Andy
>>>>> PGP Key ID: 0xDC1B5864
>>>>
>>>>
>>>>
>>>
>>> --
>>> Andy
>>> PGP Key ID: 0xDC1B5864
>>
>>
>>
>
> --
> Andy
> PGP Key ID: 0xDC1B5864

From no_reply at codeplex.com  Sat Apr 12 09:21:42 2014
From: no_reply at codeplex.com (CodePlex)
Date: 12 Apr 2014 00:21:42 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/11/2014
Message-ID: <CO1MSDNADMCDS26DqaJ000214c6@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] IronPython.dll has wrong assembly version
2. [New comment] IronPython.dll has wrong assembly version
3. [New comment] IronPython.dll has wrong assembly version
4. [New comment] Try in the browser crash
5. [New issue] argument of type 'type' is not iterable reports type of the wrong argument

----------------------------------------------

ISSUES

1. [New comment] IronPython.dll has wrong assembly version
http://ironpython.codeplex.com/workitem/35119
User MarkusSchaber has commented on the issue:

"<p>We had similar problems. Another problem was when we updated the IronPython DLL without also upgrading the DLR DLLs.</p><p>Our solution is that we compile each IronPython version we ship on our own (including all dependencies like the DLR Assemblies), with an unique version number, and signed with our own key.</p><p>As the key is part of the assembly ID, this allows our self-compiled IronPython DLLs to be identified unambigously, and they're not disturbed by whatever &quot;official&quot; IronPython assembly happens to be around on the system.</p>"-----------------

2. [New comment] IronPython.dll has wrong assembly version
http://ironpython.codeplex.com/workitem/35119
User delicb has commented on the issue:

"<p>Had the same problem.</p><p>I did think about compiling IronPython myself and chaning version, but that seemed like an overkill. So, I used ILMerge to change assembly version number and wrote the script that does so for all IronPython and DLR dlls.</p><p>One thing to note - if embeded IronPython is going to be used with 3rd party apps that check version number (for example, I wanted to use PyCharm and Eclipse as IDE for scripts that my application executed using embeded IronPython), keep 2.7 part of version and change the rest. PyCharm raised errors about unsupported python version when I changed version to 2.9.9.9. I rewrote all assembly versions to 2.7.32768.32768 and added binding redirect to app.config to always load 2.7.32768.32768 version.</p>"-----------------

3. [New comment] IronPython.dll has wrong assembly version
http://ironpython.codeplex.com/workitem/35119
User jdhardy has commented on the issue:

"<p>Even better, it's intentional *and* wrong. And it's my fault, because I'm selfish. It's a long story, so bear with me.</p><p>Rewind, oh, about 6 years. I worked on a project called NWSGI that provides a WSGI interface to IIS, which allowed running Python web apps on IIS using IronPython. Now, it (obviously) links against IronPython, and I thought it would be good if (a) IronPython were in the GAC and (b) NWSGI were in the GAC then (c) apps could be deployed to IIS with only some configuration settings.</p><p>If IronPython's AssemblyVersion changed with every patch release, I would have had to rebuild NWSGI to match, and I didn't want to do that. I don't think this was completely unreasonable, as anyone who makes a library that embeds IronPython will have the same problem. I also didn't know about [binding redirects](http://msdn.microsoft.com/en-us/library/7wd6ex19(v=vs.110).aspx) at the time either, and even once I did they seemed ugly.</p><p>Once I took over the IronPython release process, I just kept the AssemblyVersion the same across all patch releases ... but didn't do a very good job of making sure those releases were *compatible* to avoid issues. The workaround is exactly what Markus describes - build it yourself, with your own key, and you won't have any issues. That is less than ideal, obviously.</p><p>To avoid this, IronPython 3 will provide unsigned assemblies by default, with an option for signed ones if needed. Unsigned assemblies have all of the advantages of drop-in updates *and* they're never loaded from the GAC, so if you have the assemblies next to your .exe, they will always be used. The signed ones will also be there for the cases that need them, but discouraged.</p><p>For 2.7.5 I'm less sure about what to do. Sticking with a bad idea for consistency is still a bad idea. Fixing a broken app is straightforward if ugly. (And reading closer, it looks like [publisher policy files](http://msdn.microsoft.com/en-us/library/7wd6ex19(v=vs.110).aspx#BKMK_Redirectingassemblyversionsbyusingpublisherpolicy) may be able to make it seamless - I swear the documentation wasn't this clear years ago).</p><p>Ultimately this is something that has bugged for a while, but since no one has really complained about it, I've never stopped to fix it. However, since I tend to manage priorities using the squeaky wheel method, maybe now is the time. :)</p>"-----------------

4. [New comment] Try in the browser crash
http://ironpython.codeplex.com/workitem/35121
User slide_o_mix has commented on the issue:

"<p>Silverlight isn't really supported anymore. None of the main people working on IronPython keep it up as the demand has been VERY low for Silverlight use.</p>"-----------------

5. [New issue] argument of type 'type' is not iterable reports type of the wrong argument
http://ironpython.codeplex.com/workitem/35126
User paweljasinski has proposed the issue:

"At the moment we have:
>>> " " in 11
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: argument of type 'str' is not iterable

Expected:
>>> " " in 11
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: argument of type 'int' is not iterable
"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140412/c8cb1eed/attachment.html>

From no_reply at codeplex.com  Sun Apr 13 09:22:26 2014
From: no_reply at codeplex.com (CodePlex)
Date: 13 Apr 2014 00:22:26 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/12/2014
Message-ID: <CO1MSDNADMCDS2BBsQw0002228c@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] Try in the browser crash
2. [New comment] Try in the browser crash
3. [New comment] Try in the browser crash

----------------------------------------------

ISSUES

1. [New comment] Try in the browser crash
http://ironpython.codeplex.com/workitem/35121
User KeithJRome has commented on the issue:

"<p>Well, that's not exactly true :)</p><p>We cross-compile our application which embeds IP to both WPF and Silverlight, and so we require that Silverlight support be maintained. That said, this application is unlikely to move to Python 3 (simply isn't needed), and we also rarely update our IP assemblies. We build our own from source and strictly control which version our app is linked against to avoid any compat problems or regression bugs, and we only advance to a newer version of IP when there are specific features or bugfixes that we need.<br></p>"-----------------

2. [New comment] Try in the browser crash
http://ironpython.codeplex.com/workitem/35121
User KeithJRome has commented on the issue:

"<p>Judging from the submitted screenshot I don't think this is an IronPython problem.</p><p>This exception is coming from IsolatedStorage, an internal feature of Silverlight. I've never seen that error before - has someone tinkered with the private folder structure that Silverlight uses for storing local persistent data? Taking Ownership in NTFS, or anything like that?</p>"-----------------

3. [New comment] Try in the browser crash
http://ironpython.codeplex.com/workitem/35121
User JordiMasip has commented on the issue:

"<p>I was using Safari in OS X Mavericks. I?ve tried with Chrome and IronPython worked fine. Maybe the IsolatedStorage error was caused by Safari sandbox...</p>"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140413/17a18d36/attachment.html>

From no_reply at codeplex.com  Tue Apr 15 09:28:00 2014
From: no_reply at codeplex.com (CodePlex)
Date: 15 Apr 2014 00:28:00 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/14/2014
Message-ID: <CO1MSDNADMCDS24fDGC00024d38@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New issue] Rhino - IronPython - add Leap Motion
2. [New comment] Rhino - IronPython - add Leap Motion
3. [Status update] Rhino - IronPython - add Leap Motion
4. [New comment] Rhino - IronPython - add Leap Motion

----------------------------------------------

ISSUES

1. [New issue] Rhino - IronPython - add Leap Motion
http://ironpython.codeplex.com/workitem/35132
User Mjnewsum has proposed the issue:

"Hello,

I have been an IronPython used for a while now, but this is the first time that I am trying to add a module.  I have tried to get help from leap motion, but no one seems to provide a solution.

I just need to know how I add a module that can be imported into Rhino's IronPython script editor.  I must sound crazy.

Here is the post to Leap:

All,

I know this issue has been brought up before, (once by myself even about a year ago) but I have not seen a solution unfortunately. The post that included this problem from before took many turns and this issues was not really resolved as far as I can tell.

Setup:
Sample.py file in C:\Program Files\Rhinoceros 5.0 (64-bit)\Plug-ins\IronPython
Leap.dll file in C:\Program Files\Rhinoceros 5.0 (64-bit)\Plug-ins\IronPython
Leap.py file in C:\Program Files\Rhinoceros 5.0 (64-bit)\Plug-ins\IronPython\Lib
LeapPython.pyd file in C:\Program Files\Rhinoceros 5.0 (64-bit)\Plug-ins\IronPython\Lib

Leap.dll and LeapPython.pyd files are from the 64-bit folder:
LeapDeveloperKit_release_win_1.0.9+8391\LeapDeveloperKit\LeapSDK\lib\x64

When I open the Sample.py file in rhino 5.0's python script editor and run, I receive this error:

Message: No module named LeapPython

Traceback:
line 18, in swig_import_helper, "C:\Program Files\Rhinoceros 5.0 (64-bit)\Plug-ins\IronPython\Lib\Leap.py"
line 26, in , "C:\Program Files\Rhinoceros 5.0 (64-bit)\Plug-ins\IronPython\Lib\Leap.py"
line 9, in , "C:\Users\jake_newsum\AppData\Local\Temp\TempScript.py"

Any advise towards a solution would be greatly appreciated. If you need any more information from my end, please let me know. I am just trying to get up and running. I gave up when I had no response in the past, but I would like to get this running so my Leap stops collecting dust.

Kind Regards,
Jake"-----------------

2. [New comment] Rhino - IronPython - add Leap Motion
http://ironpython.codeplex.com/workitem/35132
User paweljasinski has commented on the issue:

"<p>I think you are trying to mix LeapPython.pyd which appears to be cpython extension with IronPython. IronPython will not load it.<br>Please, in the future direct your question to https://mail.python.org/mailman/listinfo/ironpython-users</p>"-----------------

3. [Status update] Rhino - IronPython - add Leap Motion
http://ironpython.codeplex.com/workitem/35132
User paweljasinski has updated the issue:
Status has changed from Proposed to Closed.

-----------------

4. [New comment] Rhino - IronPython - add Leap Motion
http://ironpython.codeplex.com/workitem/35132
User Mjnewsum has commented on the issue:

"<p>Thank you paweljasinski,</p><p>I am letting Leap know to see if there is a way that the LeapPython.pyd can be formatted in a better way for IronPython.  If you have any recommendations, I am open to them.  As I stated before, this is relatively new territory for me.</p><p>Kind Regards,<br>Jake</p>"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140415/b71e9593/attachment.html>

From germanocarella.list at gmail.com  Mon Apr 14 17:51:00 2014
From: germanocarella.list at gmail.com (Germano Carella)
Date: Mon, 14 Apr 2014 17:51:00 +0200
Subject: [Ironpython-users] Ironpython, installing third party packages
Message-ID: <045501cf57f9$56803630$0380a290$@gmail.com>

Hi,

I downloade and installed ironpython 2.7.4 on a windows 7 64 bit, visual
studio 2013 environment.

I installed python tools 2.0 for visual studio 2013.

I can't install anything from third party.

With python 2.7 I was using pip or easy_install.

 

Now, I searched on google and I tried to do something:

1)      I tried distribute_setup.py, but I received message: object has no
attribute _getframe. 

2)      I tried to set -X:Frames and -X:FullFrames, but nothing changes.

3)      From visual studio I tried to add a new package, installing pip or
easy_install, but it didn't work.

 

Ok, How can I do?

There is a way?

Help!

Germano

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140414/ac0d183b/attachment.html>

From vernondcole at gmail.com  Tue Apr 15 16:10:56 2014
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Tue, 15 Apr 2014 10:10:56 -0400
Subject: [Ironpython-users] Ironpython, installing third party packages
In-Reply-To: <045501cf57f9$56803630$0380a290$@gmail.com>
References: <045501cf57f9$56803630$0380a290$@gmail.com>
Message-ID: <CAH-ZgAfPKnLLw6g--MHBUdbSQB61rCqiL8Q3Z0j75Z4khV755Q@mail.gmail.com>

There was a patch for this bug produced a few weeks ago.
The only released version with the patch is in
setuptools-4.0b1.zip<https://bitbucket.org/pypa/setuptools/downloads/setuptools-4.0b1.zip>
AFAIK.




On Mon, Apr 14, 2014 at 11:51 AM, Germano Carella <
germanocarella.list at gmail.com> wrote:

> Hi,
>
> I downloade and installed ironpython 2.7.4 on a windows 7 64 bit, visual
> studio 2013 environment.
>
> I installed python tools 2.0 for visual studio 2013.
>
> I can?t install anything from third party.
>
> With python 2.7 I was using pip or easy_install.
>
>
>
> Now, I searched on google and I tried to do something:
>
> 1)      I tried distribute_setup.py, but I received message: object has
> no attribute _getframe.
>
> 2)      I tried to set ?X:Frames and ?X:FullFrames, but nothing changes.
>
> 3)      From visual studio I tried to add a new package, installing pip
> or easy_install, but it didn?t work.
>
>
>
> Ok, How can I do?
>
> There is a way?
>
> Help!
>
> Germano
>
>
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140415/ca804d2d/attachment.html>

From no_reply at codeplex.com  Wed Apr 16 09:23:32 2014
From: no_reply at codeplex.com (CodePlex)
Date: 16 Apr 2014 00:23:32 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/15/2014
Message-ID: <CO1MSDNADMCDS2UIEAO00026aa8@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] package gets confused as module during import
2. [New comment] "argument of type 'type' is not iterable" exception reports type of the wrong argument

----------------------------------------------

ISSUES

1. [New comment] package gets confused as module during import
http://ironpython.codeplex.com/workitem/35116
User jdhardy has commented on the issue:

"<p>Fixed in 069eaee.</p>"-----------------

2. [New comment] "argument of type 'type' is not iterable" exception reports type of the wrong argument
http://ironpython.codeplex.com/workitem/35126
User jdhardy has commented on the issue:

"<p>Fixed in 984990a.</p>"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140416/8bdae6d7/attachment.html>

From pawel.jasinski at gmail.com  Wed Apr 16 17:20:19 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Wed, 16 Apr 2014 17:20:19 +0200
Subject: [Ironpython-users] running asciidoc
Message-ID: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>

hi,

I have made an exercise of running asciidoc under ironpython
It turned out to be a performance disappointment.
Converting trivial document takes 30 seconds where cpython is done
under a second.
Can it be that asciidoc, which makes heavy use of regular expression,
exposes weak part of ironpython?

Has anybody similar experience with applications using  heavily re?

Am I doing something wrong?


--pawel

From no_reply at codeplex.com  Thu Apr 17 09:23:00 2014
From: no_reply at codeplex.com (CodePlex)
Date: 17 Apr 2014 00:23:00 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/16/2014
Message-ID: <CO1MSDNADMCDS2QHh2w000005d1@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] Rhino - IronPython - add Leap Motion
2. [New comment] Rhino - IronPython - add Leap Motion
3. [New issue] regular expression extension accepts only single flag
4. [New comment] regular expression extension accepts only single flag

----------------------------------------------

ISSUES

1. [New comment] Rhino - IronPython - add Leap Motion
http://ironpython.codeplex.com/workitem/35132
User MarkusSchaber has commented on the issue:

"<p>I don't know whether they can do that much, as IronPython simply cannot load cPython extensions directly (the internal data structures are totally different).</p><p>The IronClad project (https://code.google.com/p/ironclad/) tried to solve the gap by adding a wrapper layer, but it seems dormant right now.</p><p>As far as I could see, they also offer support for C#. My guess is that it is a .NET wrapper DLL which offers a &quot;normal&quot; .NET API - this can directly be used by IronPython via clr.AddReference and Import.</p><p>Maybe you could also leverage the websocket interface.</p>"-----------------

2. [New comment] Rhino - IronPython - add Leap Motion
http://ironpython.codeplex.com/workitem/35132
User Mjnewsum has commented on the issue:

"<p>I am trying to bring in the C# module like this:</p><p>yourFolder = r&quot;C:\Users\Jake\Desktop\CSetup&quot;<br>import sys<br>import clr<br>import os</p><p>clr.AddReferenceToFileAndPath(os.path.join(yourFolder, &quot;Leap.dll&quot;))</p><p>if yourFolder not in sys.path:<br>    sys.path.append(yourFolder)<br>import Leap</p><p>The Leap.dll file is in the folder, but when I run, it always returns:</p><p>Message: file does not exist: C:\Users\Jake\Desktop\CSetup\LeapCSharp.dll</p><p>Traceback:<br>  line 6, in &lt;module&gt;, &quot;C:\Users\Jake\Desktop\CSetup\CTesting.py&quot;</p><p><br>Is there something I am doing wrong?</p>"-----------------

3. [New issue] regular expression extension accepts only single flag
http://ironpython.codeplex.com/workitem/35135
User paweljasinski has proposed the issue:

"IronPython:
>>> import re
>>> re.compile(r"(?u)")
<RE_Pattern object at 0x000000000000002F>
>>> re.compile(r"(?s)")
<RE_Pattern object at 0x0000000000000030>
>>> re.compile(r"(?su)")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
re.error: parsing "(?su)" - Unrecognized grouping construct.

cpython:
>>> import re
>>> re.compile(r"(?u)")
<_sre.SRE_Pattern object at 0x6ffffed6630>
>>> re.compile(r"(?s)")
<_sre.SRE_Pattern object at 0x6ffffed66f0>
>>> re.compile(r"(?su)")
<_sre.SRE_Pattern object at 0x6ffffed6690>
"-----------------

4. [New comment] regular expression extension accepts only single flag
http://ironpython.codeplex.com/workitem/35135
User paweljasinski has commented on the issue:

"<p>Workaround:<br>re.compile(r&quot;(?us)&quot;)</p><p>and for more complex combinations, slit into individual<br>re.compile(r&quot;(?s)(?u)&quot;)</p>"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140417/d8c45d61/attachment.html>

From pawel.jasinski at gmail.com  Thu Apr 17 11:28:35 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Thu, 17 Apr 2014 11:28:35 +0200
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
Message-ID: <CA+7conkZj8RMgq+X_ZQp-K4HH8+xA13TBP0bVtMR+yfEyd=ybA@mail.gmail.com>

This is follow up. I run the profiler as described here:
http://blogs.msdn.com/b/curth/archive/2009/03/29/an-ironpython-profiler.aspx
The results is attached.
I am a bit confused about a strong correlation between inclusive and
exclusive time for top items.
I also calculated total for inclusive and it matches total profiling time.
Can anybody tell what is going on here?



On Wed, Apr 16, 2014 at 5:20 PM, Pawel Jasinski
<pawel.jasinski at gmail.com> wrote:
> hi,
>
> I have made an exercise of running asciidoc under ironpython
> It turned out to be a performance disappointment.
> Converting trivial document takes 30 seconds where cpython is done
> under a second.
> Can it be that asciidoc, which makes heavy use of regular expression,
> exposes weak part of ironpython?
>
> Has anybody similar experience with applications using  heavily re?
>
> Am I doing something wrong?
>
>
> --pawel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asciidoc-profile.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 37600 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140417/33a5dd76/attachment.xlsx>

From pawel.jasinski at gmail.com  Thu Apr 17 14:05:43 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Thu, 17 Apr 2014 14:05:43 +0200
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
Message-ID: <CA+7conkb3dxv4=ccVOPZF2pJWwzDHA_m3fHKsWN3=aCAvNQ5Tg@mail.gmail.com>

update 2
I have run it inside c# profiler:

Function Name Inclusive Samples Exclusive Samples Inclusive Samples %
Exclusive Samples %
System.Text.RegularExpressions.Regex.Match(string,int32,int32) 9,816 9,816
53.21 53.21
System.Text.RegularExpressions.Regex.Match(string) 4,749 4,749 25.74 25.74
System.Text.RegularExpressions.Regex..ctor(string,valuetype
System.Text.RegularExpressions.RegexOptions)2,592 2,592 14.05 14.05
Microsoft.Scripting.Interpreter.LightLambda.Run3(!!0,!!1,!!2)18,407 56
99.77 0.30

I think I have to look closer at how are the re mapped.



On Wed, Apr 16, 2014 at 5:20 PM, Pawel Jasinski <pawel.jasinski at gmail.com>wrote:

> hi,
>
> I have made an exercise of running asciidoc under ironpython
> It turned out to be a performance disappointment.
> Converting trivial document takes 30 seconds where cpython is done
> under a second.
> Can it be that asciidoc, which makes heavy use of regular expression,
> exposes weak part of ironpython?
>
> Has anybody similar experience with applications using  heavily re?
>
> Am I doing something wrong?
>
>
> --pawel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140417/7da38602/attachment.html>

From germanocarella.list at gmail.com  Thu Apr 17 15:23:30 2014
From: germanocarella.list at gmail.com (Germano Carella)
Date: Thu, 17 Apr 2014 15:23:30 +0200
Subject: [Ironpython-users] Ironpython and multimedia on windows 7 64 bit
Message-ID: <4f9e01cf5a40$3a423ce0$aec6b6a0$@gmail.com>

Hi,

I discovered ironpython cookbook and I seen examples on how to playing mp3
with DirectX.

Now, I have windws 7 pro 64 bit and when I attempt to load
Microsoft.DirectX, I receive a file not found. 

I googled to search directx sdk for windows 7, but I Was unable to find
anything.

There are solutions in order to create Audio Application with dotnet on a
windows 7 64 bit with IronPython?

Thanks!

Germano

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140417/3ddd2c1c/attachment.html>

From jdhardy at gmail.com  Thu Apr 17 17:06:38 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 17 Apr 2014 16:06:38 +0100
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CA+7conkZj8RMgq+X_ZQp-K4HH8+xA13TBP0bVtMR+yfEyd=ybA@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
 <CA+7conkZj8RMgq+X_ZQp-K4HH8+xA13TBP0bVtMR+yfEyd=ybA@mail.gmail.com>
Message-ID: <CAF7AXFGm5L4Dcv0F-bJU_U_g9wtcGEnLW88LNQKHcZKmqCyCdw@mail.gmail.com>

On Thu, Apr 17, 2014 at 10:28 AM, Pawel Jasinski
<pawel.jasinski at gmail.com> wrote:
> This is follow up. I run the profiler as described here:
> http://blogs.msdn.com/b/curth/archive/2009/03/29/an-ironpython-profiler.aspx

I didn't even know that existed.

> The results is attached.
> I am a bit confused about a strong correlation between inclusive and
> exclusive time for top items.
> I also calculated total for inclusive and it matches total profiling time.
> Can anybody tell what is going on here?

It's possible that it broke somewhere along the line and no one
noticed. Maybe Curt (cc'd) can better explain what the numbers mean.

- Jeff

From jdhardy at gmail.com  Thu Apr 17 17:10:04 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 17 Apr 2014 16:10:04 +0100
Subject: [Ironpython-users] Ironpython and multimedia on windows 7 64 bit
In-Reply-To: <4f9e01cf5a40$3a423ce0$aec6b6a0$@gmail.com>
References: <4f9e01cf5a40$3a423ce0$aec6b6a0$@gmail.com>
Message-ID: <CAF7AXFE7dm1rHwNLKMn1iq7PaSLEPHVCBvEEVyJpZgVSLxMt9g@mail.gmail.com>

The cookbook might be out of date. I think they way to access DirectX
from .NET was through XNA, which was abandoned. If you search for
information on how to do it in C# it should be possible to translate
that to IronPython, although what you tried and the exact error
message would also be helpful.

- Jeff

On Thu, Apr 17, 2014 at 2:23 PM, Germano Carella
<germanocarella.list at gmail.com> wrote:
> Hi,
>
> I discovered ironpython cookbook and I seen examples on how to playing mp3
> with DirectX.
>
> Now, I have windws 7 pro 64 bit and when I attempt to load
> Microsoft.DirectX, I receive a file not found.
>
> I googled to search directx sdk for windows 7, but I Was unable to find
> anything.
>
> There are solutions in order to create Audio Application with dotnet on a
> windows 7 64 bit with IronPython?
>
> Thanks!
>
> Germano
>
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>

From pawel.jasinski at gmail.com  Fri Apr 18 00:32:44 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Fri, 18 Apr 2014 00:32:44 +0200
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
Message-ID: <CA+7conkoLXDTF59XwPAV4EL7-F1wtHZjMvejSXysx==5jCaJDw@mail.gmail.com>

I think it is simple .net regex which is slower.
I did the following:
1. Proved that asciidoc run under python (cygwin) evaluates the same
regular expression as under ipy - there are no bugs which make ipy evaluate
more REs
2. Captured the evaluated regular expressions in a form suitable for .net
and python
3. Write trivial program in c# to evaluate captured REs. (6 seconds)
4. Write trivial program in python to evaluate captured REs (0.4s for
python3.2 and 0.65s for python 2.7.5)
I also got rid off ipy/c# quirks (extra named groups), to get functional
equivalent and no conversion overhead - no change
Number of captured REs is 46253.
For this particular sample, cpython implementation if regular expression
appears to be 12 times faster than .net implementation

--pawel


On Wed, Apr 16, 2014 at 5:20 PM, Pawel Jasinski <pawel.jasinski at gmail.com>wrote:

> hi,
>
> I have made an exercise of running asciidoc under ironpython
> It turned out to be a performance disappointment.
> Converting trivial document takes 30 seconds where cpython is done
> under a second.
> Can it be that asciidoc, which makes heavy use of regular expression,
> exposes weak part of ironpython?
>
> Has anybody similar experience with applications using  heavily re?
>
> Am I doing something wrong?
>
>
> --pawel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140418/22f77e05/attachment.html>

From no_reply at codeplex.com  Fri Apr 18 09:22:36 2014
From: no_reply at codeplex.com (CodePlex)
Date: 18 Apr 2014 00:22:36 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/17/2014
Message-ID: <CO1MSDNADMCDS2Edyt3000022d0@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] Rhino - IronPython - add Leap Motion
2. [New comment] Rhino - IronPython - add Leap Motion
3. [New comment] regular expression extension accepts only single flag
4. [New comment] regular expression extension accepts only single flag
5. [New comment] regular expression extension accepts only single flag

----------------------------------------------

ISSUES

1. [New comment] Rhino - IronPython - add Leap Motion
http://ironpython.codeplex.com/workitem/35132
User MarkusSchaber has commented on the issue:

"<p>Is the LeapCSharpDLL there, or only the Leap.dll?</p><p>Can you try the Fusion Log Viewer to check why the assembly binding fails?</p>"-----------------

2. [New comment] Rhino - IronPython - add Leap Motion
http://ironpython.codeplex.com/workitem/35132
User Mjnewsum has commented on the issue:

"<p>The files in the folder are:</p><p>Leap.dll<br>LeapCSharp.dll<br>LeapCSharp.NET3.5.dll<br>Sample.cs</p><p>I will look into the Fusion Log Viewer tonight to see if I can get that to work.  Thank you, again, for the help</p>"-----------------

3. [New comment] regular expression extension accepts only single flag
http://ironpython.codeplex.com/workitem/35135
User jdhardy has commented on the issue:

"<p>IronPython converts Python regexes into .NET regexes, using regexes! How many problems are we at now? :) That conversion is obviously no 100%, but it does work surprisingly well.</p>"-----------------

4. [New comment] regular expression extension accepts only single flag
http://ironpython.codeplex.com/workitem/35135
User paweljasinski has commented on the issue:

"<p>It looks like the problem is limited to flags and can be worked around by splitting flags into individual entries.<br>There is also ordering which can be corrected in expression as well. I have seen:<br>```(?u)^whatever``` which breaks re module, but it can be substituted with ```^(?u)```<br></p>"-----------------

5. [New comment] regular expression extension accepts only single flag
http://ironpython.codeplex.com/workitem/35135
User paweljasinski has commented on the issue:

"<p>aciidoc which I tested uses heavily re based parsing and customization. Until now, I did not discover any other problems. Ok, except performance, but this is another story.</p>"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140418/0b8485f3/attachment.html>

From jdhardy at gmail.com  Fri Apr 18 12:33:49 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 18 Apr 2014 11:33:49 +0100
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CA+7conkoLXDTF59XwPAV4EL7-F1wtHZjMvejSXysx==5jCaJDw@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
 <CA+7conkoLXDTF59XwPAV4EL7-F1wtHZjMvejSXysx==5jCaJDw@mail.gmail.com>
Message-ID: <CAF7AXFH8WRvFGExg-FZsQ6KXR+txT4H3rzS-ibMswzX=V-rirg@mail.gmail.com>

On Thu, Apr 17, 2014 at 11:32 PM, Pawel Jasinski
<pawel.jasinski at gmail.com> wrote:
> I think it is simple .net regex which is slower.
> I did the following:
> 1. Proved that asciidoc run under python (cygwin) evaluates the same regular
> expression as under ipy - there are no bugs which make ipy evaluate more REs
> 2. Captured the evaluated regular expressions in a form suitable for .net
> and python
> 3. Write trivial program in c# to evaluate captured REs. (6 seconds)
> 4. Write trivial program in python to evaluate captured REs (0.4s for
> python3.2 and 0.65s for python 2.7.5)
> I also got rid off ipy/c# quirks (extra named groups), to get functional
> equivalent and no conversion overhead - no change
> Number of captured REs is 46253.
> For this particular sample, cpython implementation if regular expression
> appears to be 12 times faster than .net implementation

Can you put the sample code in a gist? Maybe it's hitting a
pathological case in the .NET regex engine or something, because
that's a crazy difference.

- Jeff

From no_reply at codeplex.com  Sat Apr 19 09:23:48 2014
From: no_reply at codeplex.com (CodePlex)
Date: 19 Apr 2014 00:23:48 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/18/2014
Message-ID: <CO1MSDNADMCDS2carcR00003b74@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] unbound methods instead of bound methods in cloned class instances

----------------------------------------------

ISSUES

1. [New comment] unbound methods instead of bound methods in cloned class instances
http://ironpython.codeplex.com/workitem/34649
User jdhardy has commented on the issue:

"<p>Fixed in 7e5ad98b.</p>"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140419/1c352f18/attachment.html>

From doug.blank at gmail.com  Sat Apr 19 12:58:26 2014
From: doug.blank at gmail.com (Doug Blank)
Date: Sat, 19 Apr 2014 06:58:26 -0400
Subject: [Ironpython-users] IronPython in IPython notebook/console
Message-ID: <CAAusYCidCyJwLUJoAP1zWL6cXpUsoy7azFK_f2ZFsEzHKdVChA@mail.gmail.com>

If you haven't used IPython in a while, you might be surprised to find that
it can use a web browser as an IDE. They have separated out the frontends
of their interfaces (console, qtconsole, and notebook) from their backend
(called a kernel). We've written a kernel that allows our Calico system to
use any of our languages (including IronPython) through their frontends.

(This doesn't use the IPython Python codebase... we have written our own
interface in C#, which might be generally useful for IronPython.)

You can get a feel for how this works is by checking out some of our
notebooks:

http://nbviewer.ipython.org/urls/bitbucket.org/ipre/calico/raw/master/notebooks/SiteMap.ipynb

We don't have the nice pipeline provided by numpy and matplotlib, but we
are developing our own set of tools; see for example:

http://nbviewer.ipython.org/urls/bitbucket.org/ipre/calico/raw/master/notebooks/Python/Travelling%20Salesperson.ipynb

and easily getting camera images:

http://nbviewer.ipython.org/urls/bitbucket.org/ipre/calico/raw/master/notebooks/Python/CameraWidget.ipynb

We have full support for IPython 2.0 (just released) including the new
widgets. You can find out more information, and install directions here:

http://calicoproject.org/ICalico

If anyone has suggestions or ideas, please let us know!

-Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140419/493f2edf/attachment.html>

From smortaz at exchange.microsoft.com  Sat Apr 19 19:13:37 2014
From: smortaz at exchange.microsoft.com (Shahrokh Mortazavi)
Date: Sat, 19 Apr 2014 17:13:37 +0000
Subject: [Ironpython-users] IronPython in IPython notebook/console
In-Reply-To: <CAAusYCidCyJwLUJoAP1zWL6cXpUsoy7azFK_f2ZFsEzHKdVChA@mail.gmail.com>
References: <CAAusYCidCyJwLUJoAP1zWL6cXpUsoy7azFK_f2ZFsEzHKdVChA@mail.gmail.com>
Message-ID: <d2ab62fbcef94f23bd6c4f7af37fa956@DFM-DB3MBX15-08.exchange.corp.microsoft.com>

?this is great to see!  congrats!



________________________________
From: Ironpython-users <ironpython-users-bounces+smortaz=microsoft.com at python.org> on behalf of Doug Blank <doug.blank at gmail.com>
Sent: Saturday, April 19, 2014 3:58 AM
To: ironpython-users at python.org
Subject: [Ironpython-users] IronPython in IPython notebook/console

If you haven't used IPython in a while, you might be surprised to find that it can use a web browser as an IDE. They have separated out the frontends of their interfaces (console, qtconsole, and notebook) from their backend (called a kernel). We've written a kernel that allows our Calico system to use any of our languages (including IronPython) through their frontends.

(This doesn't use the IPython Python codebase... we have written our own interface in C#, which might be generally useful for IronPython.)

You can get a feel for how this works is by checking out some of our notebooks:

http://nbviewer.ipython.org/urls/bitbucket.org/ipre/calico/raw/master/notebooks/SiteMap.ipynb

We don't have the nice pipeline provided by numpy and matplotlib, but we are developing our own set of tools; see for example:

http://nbviewer.ipython.org/urls/bitbucket.org/ipre/calico/raw/master/notebooks/Python/Travelling%20Salesperson.ipynb

and easily getting camera images:

http://nbviewer.ipython.org/urls/bitbucket.org/ipre/calico/raw/master/notebooks/Python/CameraWidget.ipynb

We have full support for IPython 2.0 (just released) including the new widgets. You can find out more information, and install directions here:

http://calicoproject.org/ICalico

If anyone has suggestions or ideas, please let us know!

-Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140419/f8706a32/attachment.html>

From pawel.jasinski at gmail.com  Wed Apr 23 07:14:21 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Wed, 23 Apr 2014 07:14:21 +0200
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CA+7con=QiQ3=Z96tQQ2yQ_HxTL8aekXFKN53MuBp8MeU91ZjOA@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
 <CA+7conkoLXDTF59XwPAV4EL7-F1wtHZjMvejSXysx==5jCaJDw@mail.gmail.com>
 <CAF7AXFH8WRvFGExg-FZsQ6KXR+txT4H3rzS-ibMswzX=V-rirg@mail.gmail.com>
 <CA+7con=QiQ3=Z96tQQ2yQ_HxTL8aekXFKN53MuBp8MeU91ZjOA@mail.gmail.com>
Message-ID: <CA+7conk9em5GReZ6MawTT-MqB1u3_o=uReRH2sFY9wTfyWYE-Q@mail.gmail.com>

asciidoc calls frequently re.compile.
In case of cpython re.compile uses cache, where ironpython performs compile
unconditionally.
https://ironpython.codeplex.com/workitem/35146
--pawel


On Mon, Apr 21, 2014 at 3:09 PM, Pawel Jasinski <pawel.jasinski at gmail.com>wrote:

>
>
>
> On Fri, Apr 18, 2014 at 12:33 PM, Jeff Hardy <jdhardy at gmail.com> wrote:
>
>> On Thu, Apr 17, 2014 at 11:32 PM, Pawel Jasinski
>> <pawel.jasinski at gmail.com> wrote:
>> > I think it is simple .net regex which is slower.
>> > I did the following:
>> > 1. Proved that asciidoc run under python (cygwin) evaluates the same
>> regular
>> > expression as under ipy - there are no bugs which make ipy evaluate
>> more REs
>> > 2. Captured the evaluated regular expressions in a form suitable for
>> .net
>> > and python
>> > 3. Write trivial program in c# to evaluate captured REs. (6 seconds)
>> > 4. Write trivial program in python to evaluate captured REs (0.4s for
>> > python3.2 and 0.65s for python 2.7.5)
>> > I also got rid off ipy/c# quirks (extra named groups), to get functional
>> > equivalent and no conversion overhead - no change
>> > Number of captured REs is 46253.
>> > For this particular sample, cpython implementation if regular expression
>> > appears to be 12 times faster than .net implementation
>>
>> Can you put the sample code in a gist? Maybe it's hitting a
>> pathological case in the .NET regex engine or something, because
>> that's a crazy difference.
>>
>> - Jeff
>>
>
> The re evaluated by ipy and cpython are the same and the end result of
> ascii doc is the same but, the number of matches reported is different.
> I will keep digging.
> --pawel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140423/614b014d/attachment.html>

From no_reply at codeplex.com  Wed Apr 23 09:25:09 2014
From: no_reply at codeplex.com (CodePlex)
Date: 23 Apr 2014 00:25:09 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/22/2014
Message-ID: <CO1MSDNADMCDS26nx8d00009783@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New issue] re.compile does not use cache

----------------------------------------------

ISSUES

1. [New issue] re.compile does not use cache
http://ironpython.codeplex.com/workitem/35146
User paweljasinski has proposed the issue:

"In case of cpython:

Python 2.7.5 (default, Oct  2 2013, 22:34:09)
[GCC 4.8.1] on cygwin
Type "help", "copyright", "credits" or "license" for more information.



import re
re.compile("abc")
<_sre.SRE_Pattern object at 0x6fffffe0ab0>
re.compile("abc")
<_sre.SRE_Pattern object at 0x6fffffe0ab0>



Ironpython:



re.compile("abc")
<RE_Pattern object at 0x000000000000002E>
re.compile("abc")
<RE_Pattern object at 0x000000000000002F>


"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140423/0785a48b/attachment.html>

From jdhardy at gmail.com  Wed Apr 23 09:34:28 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 23 Apr 2014 08:34:28 +0100
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CA+7conk9em5GReZ6MawTT-MqB1u3_o=uReRH2sFY9wTfyWYE-Q@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
 <CA+7conkoLXDTF59XwPAV4EL7-F1wtHZjMvejSXysx==5jCaJDw@mail.gmail.com>
 <CAF7AXFH8WRvFGExg-FZsQ6KXR+txT4H3rzS-ibMswzX=V-rirg@mail.gmail.com>
 <CA+7con=QiQ3=Z96tQQ2yQ_HxTL8aekXFKN53MuBp8MeU91ZjOA@mail.gmail.com>
 <CA+7conk9em5GReZ6MawTT-MqB1u3_o=uReRH2sFY9wTfyWYE-Q@mail.gmail.com>
Message-ID: <CAF7AXFHt-TX8roFdgWqciBuNXqXE9PDVi8hf3nPEhotx22dbbw@mail.gmail.com>

On Wed, Apr 23, 2014 at 6:14 AM, Pawel Jasinski
<pawel.jasinski at gmail.com> wrote:
> asciidoc calls frequently re.compile.
> In case of cpython re.compile uses cache, where ironpython performs compile
> unconditionally.
> https://ironpython.codeplex.com/workitem/35146

Why would it repeatedly call compile? The point of compile is that it
should only be called once and then the result re-used.

- Jeff

From olof.bjarnason at gmail.com  Wed Apr 23 09:51:31 2014
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Wed, 23 Apr 2014 08:51:31 +0100
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CAF7AXFHt-TX8roFdgWqciBuNXqXE9PDVi8hf3nPEhotx22dbbw@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
 <CA+7conkoLXDTF59XwPAV4EL7-F1wtHZjMvejSXysx==5jCaJDw@mail.gmail.com>
 <CAF7AXFH8WRvFGExg-FZsQ6KXR+txT4H3rzS-ibMswzX=V-rirg@mail.gmail.com>
 <CA+7con=QiQ3=Z96tQQ2yQ_HxTL8aekXFKN53MuBp8MeU91ZjOA@mail.gmail.com>
 <CA+7conk9em5GReZ6MawTT-MqB1u3_o=uReRH2sFY9wTfyWYE-Q@mail.gmail.com>
 <CAF7AXFHt-TX8roFdgWqciBuNXqXE9PDVi8hf3nPEhotx22dbbw@mail.gmail.com>
Message-ID: <CA+LucOgEpmKZQYm2pV2XpnExWgNi68gpm3UsexCGSrUPPg9uYw@mail.gmail.com>

Official 2.7 documentation *hints* that re.compile does not cache
re.compile results (since some methods of module re actually are
caching result from re.compile):

https://docs.python.org/2/library/re.html#re.compile

On 23 April 2014 08:34, Jeff Hardy <jdhardy at gmail.com> wrote:
> On Wed, Apr 23, 2014 at 6:14 AM, Pawel Jasinski
> <pawel.jasinski at gmail.com> wrote:
>> asciidoc calls frequently re.compile.
>> In case of cpython re.compile uses cache, where ironpython performs compile
>> unconditionally.
>> https://ironpython.codeplex.com/workitem/35146
>
> Why would it repeatedly call compile? The point of compile is that it
> should only be called once and then the result re-used.
>
> - Jeff
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users

From pawel.jasinski at gmail.com  Wed Apr 23 10:31:22 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Wed, 23 Apr 2014 10:31:22 +0200
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CA+LucOgEpmKZQYm2pV2XpnExWgNi68gpm3UsexCGSrUPPg9uYw@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
 <CA+7conkoLXDTF59XwPAV4EL7-F1wtHZjMvejSXysx==5jCaJDw@mail.gmail.com>
 <CAF7AXFH8WRvFGExg-FZsQ6KXR+txT4H3rzS-ibMswzX=V-rirg@mail.gmail.com>
 <CA+7con=QiQ3=Z96tQQ2yQ_HxTL8aekXFKN53MuBp8MeU91ZjOA@mail.gmail.com>
 <CA+7conk9em5GReZ6MawTT-MqB1u3_o=uReRH2sFY9wTfyWYE-Q@mail.gmail.com>
 <CAF7AXFHt-TX8roFdgWqciBuNXqXE9PDVi8hf3nPEhotx22dbbw@mail.gmail.com>
 <CA+LucOgEpmKZQYm2pV2XpnExWgNi68gpm3UsexCGSrUPPg9uYw@mail.gmail.com>
Message-ID: <CA+7conmyoMWUCMnPEyivc29p9zYE53rLszPyP2eQUXsTCEYd9w@mail.gmail.com>

Sometimes documentation is not clear. The simple test confirms that cpython
re.compile caches results.
I can not imaging that asciidoc could provide reasonable performance if it
was not true. It does call multiple time compile with the same pattern.

rejap at eb60:~/Downloads$ python
Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
[GCC 4.8.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.compile('a')
<_sre.SRE_Pattern object at 0x160b0b8>
>>> re.compile('a')
<_sre.SRE_Pattern object at 0x160b0b8>
>>> re.compile('a')==re.compile('a')
True

--pawel



On Wed, Apr 23, 2014 at 9:51 AM, Olof Bjarnason <olof.bjarnason at gmail.com>wrote:

> Official 2.7 documentation *hints* that re.compile does not cache
> re.compile results (since some methods of module re actually are
> caching result from re.compile):
>
> https://docs.python.org/2/library/re.html#re.compile
>
> On 23 April 2014 08:34, Jeff Hardy <jdhardy at gmail.com> wrote:
> > On Wed, Apr 23, 2014 at 6:14 AM, Pawel Jasinski
> > <pawel.jasinski at gmail.com> wrote:
> >> asciidoc calls frequently re.compile.
> >> In case of cpython re.compile uses cache, where ironpython performs
> compile
> >> unconditionally.
> >> https://ironpython.codeplex.com/workitem/35146
> >
> > Why would it repeatedly call compile? The point of compile is that it
> > should only be called once and then the result re-used.
> >
> > - Jeff
> > _______________________________________________
> > Ironpython-users mailing list
> > Ironpython-users at python.org
> > https://mail.python.org/mailman/listinfo/ironpython-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140423/546074b9/attachment.html>

From pawel.jasinski at gmail.com  Wed Apr 23 10:48:57 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Wed, 23 Apr 2014 10:48:57 +0200
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CAF7AXFHt-TX8roFdgWqciBuNXqXE9PDVi8hf3nPEhotx22dbbw@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
 <CA+7conkoLXDTF59XwPAV4EL7-F1wtHZjMvejSXysx==5jCaJDw@mail.gmail.com>
 <CAF7AXFH8WRvFGExg-FZsQ6KXR+txT4H3rzS-ibMswzX=V-rirg@mail.gmail.com>
 <CA+7con=QiQ3=Z96tQQ2yQ_HxTL8aekXFKN53MuBp8MeU91ZjOA@mail.gmail.com>
 <CA+7conk9em5GReZ6MawTT-MqB1u3_o=uReRH2sFY9wTfyWYE-Q@mail.gmail.com>
 <CAF7AXFHt-TX8roFdgWqciBuNXqXE9PDVi8hf3nPEhotx22dbbw@mail.gmail.com>
Message-ID: <CA+7conkr5FtSyc8Bh2aocGarqBgqoWt_h4w_iAo==kPhXFP_sA@mail.gmail.com>

On Wed, Apr 23, 2014 at 9:34 AM, Jeff Hardy <jdhardy at gmail.com> wrote:

> On Wed, Apr 23, 2014 at 6:14 AM, Pawel Jasinski
> <pawel.jasinski at gmail.com> wrote:
> > asciidoc calls frequently re.compile.
> > In case of cpython re.compile uses cache, where ironpython performs
> compile
> > unconditionally.
> > https://ironpython.codeplex.com/workitem/35146
>
> Why would it repeatedly call compile? The point of compile is that it
> should only be called once and then the result re-used.
>
> - Jeff
>

I have no idea. It doesn't look right.
Sometimes it has the same pattern for different macros, so there is a valid
reason to do so, but in general it is almost always blindly calling compile
before any evaluation.

There is something else I have noticed.
cpython always compiles. Ironpython compiles only if compile is called.

The patch I have submitted (https://github.com/IronLanguages/main/pull/191)
is trying to be clever about it.
Any direct method does cache, but it does not compile (compile is
expensive, I learned it hard way :-)
Compile does cache, but if the cached version is not compiled, it gets
replaced with compiled one.

asciidoc running with patched version of ironpython performs reasonably.


--pawel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140423/91359975/attachment.html>

From jdhardy at gmail.com  Wed Apr 23 11:37:43 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 23 Apr 2014 10:37:43 +0100
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CA+7conkr5FtSyc8Bh2aocGarqBgqoWt_h4w_iAo==kPhXFP_sA@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
 <CA+7conkoLXDTF59XwPAV4EL7-F1wtHZjMvejSXysx==5jCaJDw@mail.gmail.com>
 <CAF7AXFH8WRvFGExg-FZsQ6KXR+txT4H3rzS-ibMswzX=V-rirg@mail.gmail.com>
 <CA+7con=QiQ3=Z96tQQ2yQ_HxTL8aekXFKN53MuBp8MeU91ZjOA@mail.gmail.com>
 <CA+7conk9em5GReZ6MawTT-MqB1u3_o=uReRH2sFY9wTfyWYE-Q@mail.gmail.com>
 <CAF7AXFHt-TX8roFdgWqciBuNXqXE9PDVi8hf3nPEhotx22dbbw@mail.gmail.com>
 <CA+7conkr5FtSyc8Bh2aocGarqBgqoWt_h4w_iAo==kPhXFP_sA@mail.gmail.com>
Message-ID: <CAF7AXFFuvREuqsnZxmbMw7hfUur4KREFrEzo-Q2H5h_0PTpT_A@mail.gmail.com>

On Wed, Apr 23, 2014 at 9:48 AM, Pawel Jasinski
<pawel.jasinski at gmail.com> wrote:
> asciidoc running with patched version of ironpython performs reasonably.

Can you run some numbers and add them in a comment on the pull request
or CP issue? I'm curious as to how much speedup asciidoc gets.

- Jeff

From pawel.jasinski at gmail.com  Wed Apr 23 12:49:43 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Wed, 23 Apr 2014 12:49:43 +0200
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CAF7AXFFuvREuqsnZxmbMw7hfUur4KREFrEzo-Q2H5h_0PTpT_A@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
 <CA+7conkoLXDTF59XwPAV4EL7-F1wtHZjMvejSXysx==5jCaJDw@mail.gmail.com>
 <CAF7AXFH8WRvFGExg-FZsQ6KXR+txT4H3rzS-ibMswzX=V-rirg@mail.gmail.com>
 <CA+7con=QiQ3=Z96tQQ2yQ_HxTL8aekXFKN53MuBp8MeU91ZjOA@mail.gmail.com>
 <CA+7conk9em5GReZ6MawTT-MqB1u3_o=uReRH2sFY9wTfyWYE-Q@mail.gmail.com>
 <CAF7AXFHt-TX8roFdgWqciBuNXqXE9PDVi8hf3nPEhotx22dbbw@mail.gmail.com>
 <CA+7conkr5FtSyc8Bh2aocGarqBgqoWt_h4w_iAo==kPhXFP_sA@mail.gmail.com>
 <CAF7AXFFuvREuqsnZxmbMw7hfUur4KREFrEzo-Q2H5h_0PTpT_A@mail.gmail.com>
Message-ID: <CA+7con=4LNJGLjJbcX-Xs1T5Sg2N8kiuzjFpodYFEYek9xj2mQ@mail.gmail.com>

I have added the test numbers:
https://github.com/IronLanguages/main/pull/191
--pawel


On Wed, Apr 23, 2014 at 11:37 AM, Jeff Hardy <jdhardy at gmail.com> wrote:

> On Wed, Apr 23, 2014 at 9:48 AM, Pawel Jasinski
> <pawel.jasinski at gmail.com> wrote:
> > asciidoc running with patched version of ironpython performs reasonably.
>
> Can you run some numbers and add them in a comment on the pull request
> or CP issue? I'm curious as to how much speedup asciidoc gets.
>
> - Jeff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140423/5628d598/attachment.html>

From pawel.jasinski at gmail.com  Wed Apr 23 13:39:46 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Wed, 23 Apr 2014 13:39:46 +0200
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CAF7AXFFuvREuqsnZxmbMw7hfUur4KREFrEzo-Q2H5h_0PTpT_A@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
 <CA+7conkoLXDTF59XwPAV4EL7-F1wtHZjMvejSXysx==5jCaJDw@mail.gmail.com>
 <CAF7AXFH8WRvFGExg-FZsQ6KXR+txT4H3rzS-ibMswzX=V-rirg@mail.gmail.com>
 <CA+7con=QiQ3=Z96tQQ2yQ_HxTL8aekXFKN53MuBp8MeU91ZjOA@mail.gmail.com>
 <CA+7conk9em5GReZ6MawTT-MqB1u3_o=uReRH2sFY9wTfyWYE-Q@mail.gmail.com>
 <CAF7AXFHt-TX8roFdgWqciBuNXqXE9PDVi8hf3nPEhotx22dbbw@mail.gmail.com>
 <CA+7conkr5FtSyc8Bh2aocGarqBgqoWt_h4w_iAo==kPhXFP_sA@mail.gmail.com>
 <CAF7AXFFuvREuqsnZxmbMw7hfUur4KREFrEzo-Q2H5h_0PTpT_A@mail.gmail.com>
Message-ID: <CA+7con=TBnm=a0Z2+uOVXq-AQVW-oUf8sXzi4_0Z87D5PQcnJQ@mail.gmail.com>

Given the asciidoc workload using 3 different samples (hello world, user
guide, asciidoc documentation), the best results are when .net regexp
compilation is *disabled* and everything is cached.
When .net regexp compilation is enabled, the result are similar, but not
better.
Anyway, details can be examined at
https://github.com/IronLanguages/main/pull/191
--pawel


On Wed, Apr 23, 2014 at 11:37 AM, Jeff Hardy <jdhardy at gmail.com> wrote:

> On Wed, Apr 23, 2014 at 9:48 AM, Pawel Jasinski
> <pawel.jasinski at gmail.com> wrote:
> > asciidoc running with patched version of ironpython performs reasonably.
>
> Can you run some numbers and add them in a comment on the pull request
> or CP issue? I'm curious as to how much speedup asciidoc gets.
>
> - Jeff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140423/dfa55d4c/attachment.html>

From jdhardy at gmail.com  Wed Apr 23 13:57:06 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 23 Apr 2014 12:57:06 +0100
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CA+7con=TBnm=a0Z2+uOVXq-AQVW-oUf8sXzi4_0Z87D5PQcnJQ@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
 <CA+7conkoLXDTF59XwPAV4EL7-F1wtHZjMvejSXysx==5jCaJDw@mail.gmail.com>
 <CAF7AXFH8WRvFGExg-FZsQ6KXR+txT4H3rzS-ibMswzX=V-rirg@mail.gmail.com>
 <CA+7con=QiQ3=Z96tQQ2yQ_HxTL8aekXFKN53MuBp8MeU91ZjOA@mail.gmail.com>
 <CA+7conk9em5GReZ6MawTT-MqB1u3_o=uReRH2sFY9wTfyWYE-Q@mail.gmail.com>
 <CAF7AXFHt-TX8roFdgWqciBuNXqXE9PDVi8hf3nPEhotx22dbbw@mail.gmail.com>
 <CA+7conkr5FtSyc8Bh2aocGarqBgqoWt_h4w_iAo==kPhXFP_sA@mail.gmail.com>
 <CAF7AXFFuvREuqsnZxmbMw7hfUur4KREFrEzo-Q2H5h_0PTpT_A@mail.gmail.com>
 <CA+7con=TBnm=a0Z2+uOVXq-AQVW-oUf8sXzi4_0Z87D5PQcnJQ@mail.gmail.com>
Message-ID: <CAF7AXFFjJCi3SAcj54b53HkPYT_D0-ScPyWpB0+m_6Gmqe8GEg@mail.gmail.com>

One more thing, just to calibrate the hello-world sample - how long do
`python -c 'print "hello, world"' and `ipy.exe 'print "hello, world"'`
take on your machine?

- Jeff

On Wed, Apr 23, 2014 at 12:39 PM, Pawel Jasinski
<pawel.jasinski at gmail.com> wrote:
> Given the asciidoc workload using 3 different samples (hello world, user
> guide, asciidoc documentation), the best results are when .net regexp
> compilation is *disabled* and everything is cached.
> When .net regexp compilation is enabled, the result are similar, but not
> better.
> Anyway, details can be examined at
> https://github.com/IronLanguages/main/pull/191
> --pawel
>
>
> On Wed, Apr 23, 2014 at 11:37 AM, Jeff Hardy <jdhardy at gmail.com> wrote:
>>
>> On Wed, Apr 23, 2014 at 9:48 AM, Pawel Jasinski
>> <pawel.jasinski at gmail.com> wrote:
>> > asciidoc running with patched version of ironpython performs reasonably.
>>
>> Can you run some numbers and add them in a comment on the pull request
>> or CP issue? I'm curious as to how much speedup asciidoc gets.
>>
>> - Jeff
>
>
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>

From pawel.jasinski at gmail.com  Wed Apr 23 14:25:52 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Wed, 23 Apr 2014 14:25:52 +0200
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CAF7AXFFjJCi3SAcj54b53HkPYT_D0-ScPyWpB0+m_6Gmqe8GEg@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
 <CA+7conkoLXDTF59XwPAV4EL7-F1wtHZjMvejSXysx==5jCaJDw@mail.gmail.com>
 <CAF7AXFH8WRvFGExg-FZsQ6KXR+txT4H3rzS-ibMswzX=V-rirg@mail.gmail.com>
 <CA+7con=QiQ3=Z96tQQ2yQ_HxTL8aekXFKN53MuBp8MeU91ZjOA@mail.gmail.com>
 <CA+7conk9em5GReZ6MawTT-MqB1u3_o=uReRH2sFY9wTfyWYE-Q@mail.gmail.com>
 <CAF7AXFHt-TX8roFdgWqciBuNXqXE9PDVi8hf3nPEhotx22dbbw@mail.gmail.com>
 <CA+7conkr5FtSyc8Bh2aocGarqBgqoWt_h4w_iAo==kPhXFP_sA@mail.gmail.com>
 <CAF7AXFFuvREuqsnZxmbMw7hfUur4KREFrEzo-Q2H5h_0PTpT_A@mail.gmail.com>
 <CA+7con=TBnm=a0Z2+uOVXq-AQVW-oUf8sXzi4_0Z87D5PQcnJQ@mail.gmail.com>
 <CAF7AXFFjJCi3SAcj54b53HkPYT_D0-ScPyWpB0+m_6Gmqe8GEg@mail.gmail.com>
Message-ID: <CA+7conneJkdfkLmG1qgNxcrsSKt9JAwBjwm8PwfDB-Rp-OSL1Q@mail.gmail.com>

I added the measurements to the PR.
Why is startup time of the ipy running out of development way up in
comparison with release?
--pawel


On Wed, Apr 23, 2014 at 1:57 PM, Jeff Hardy <jdhardy at gmail.com> wrote:

> One more thing, just to calibrate the hello-world sample - how long do
> `python -c 'print "hello, world"' and `ipy.exe 'print "hello, world"'`
> take on your machine?
>
> - Jeff
>
> On Wed, Apr 23, 2014 at 12:39 PM, Pawel Jasinski
> <pawel.jasinski at gmail.com> wrote:
> > Given the asciidoc workload using 3 different samples (hello world, user
> > guide, asciidoc documentation), the best results are when .net regexp
> > compilation is *disabled* and everything is cached.
> > When .net regexp compilation is enabled, the result are similar, but not
> > better.
> > Anyway, details can be examined at
> > https://github.com/IronLanguages/main/pull/191
> > --pawel
> >
> >
> > On Wed, Apr 23, 2014 at 11:37 AM, Jeff Hardy <jdhardy at gmail.com> wrote:
> >>
> >> On Wed, Apr 23, 2014 at 9:48 AM, Pawel Jasinski
> >> <pawel.jasinski at gmail.com> wrote:
> >> > asciidoc running with patched version of ironpython performs
> reasonably.
> >>
> >> Can you run some numbers and add them in a comment on the pull request
> >> or CP issue? I'm curious as to how much speedup asciidoc gets.
> >>
> >> - Jeff
> >
> >
> >
> > _______________________________________________
> > Ironpython-users mailing list
> > Ironpython-users at python.org
> > https://mail.python.org/mailman/listinfo/ironpython-users
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140423/c411ca0e/attachment.html>

From jdhardy at gmail.com  Wed Apr 23 14:30:54 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 23 Apr 2014 13:30:54 +0100
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CA+7conneJkdfkLmG1qgNxcrsSKt9JAwBjwm8PwfDB-Rp-OSL1Q@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
 <CA+7conkoLXDTF59XwPAV4EL7-F1wtHZjMvejSXysx==5jCaJDw@mail.gmail.com>
 <CAF7AXFH8WRvFGExg-FZsQ6KXR+txT4H3rzS-ibMswzX=V-rirg@mail.gmail.com>
 <CA+7con=QiQ3=Z96tQQ2yQ_HxTL8aekXFKN53MuBp8MeU91ZjOA@mail.gmail.com>
 <CA+7conk9em5GReZ6MawTT-MqB1u3_o=uReRH2sFY9wTfyWYE-Q@mail.gmail.com>
 <CAF7AXFHt-TX8roFdgWqciBuNXqXE9PDVi8hf3nPEhotx22dbbw@mail.gmail.com>
 <CA+7conkr5FtSyc8Bh2aocGarqBgqoWt_h4w_iAo==kPhXFP_sA@mail.gmail.com>
 <CAF7AXFFuvREuqsnZxmbMw7hfUur4KREFrEzo-Q2H5h_0PTpT_A@mail.gmail.com>
 <CA+7con=TBnm=a0Z2+uOVXq-AQVW-oUf8sXzi4_0Z87D5PQcnJQ@mail.gmail.com>
 <CAF7AXFFjJCi3SAcj54b53HkPYT_D0-ScPyWpB0+m_6Gmqe8GEg@mail.gmail.com>
 <CA+7conneJkdfkLmG1qgNxcrsSKt9JAwBjwm8PwfDB-Rp-OSL1Q@mail.gmail.com>
Message-ID: <CAF7AXFHOeff-+0Zhen+HvC5SWCJJzp_=w8E=UtGpRWSt9YB5iA@mail.gmail.com>

On Wed, Apr 23, 2014 at 1:25 PM, Pawel Jasinski
<pawel.jasinski at gmail.com> wrote:
> I added the measurements to the PR.
> Why is startup time of the ipy running out of development way up in
> comparison with release?

If you use the installer, NGEN. If not, I'm not sure.

- Jeff

From pawel.jasinski at gmail.com  Wed Apr 23 14:34:06 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Wed, 23 Apr 2014 14:34:06 +0200
Subject: [Ironpython-users] running asciidoc
In-Reply-To: <CAF7AXFHOeff-+0Zhen+HvC5SWCJJzp_=w8E=UtGpRWSt9YB5iA@mail.gmail.com>
References: <CA+7conkjnEhhAG1X-7jtYS43doGSQhbW3onMNJFLKxrfNJGoWg@mail.gmail.com>
 <CA+7conkoLXDTF59XwPAV4EL7-F1wtHZjMvejSXysx==5jCaJDw@mail.gmail.com>
 <CAF7AXFH8WRvFGExg-FZsQ6KXR+txT4H3rzS-ibMswzX=V-rirg@mail.gmail.com>
 <CA+7con=QiQ3=Z96tQQ2yQ_HxTL8aekXFKN53MuBp8MeU91ZjOA@mail.gmail.com>
 <CA+7conk9em5GReZ6MawTT-MqB1u3_o=uReRH2sFY9wTfyWYE-Q@mail.gmail.com>
 <CAF7AXFHt-TX8roFdgWqciBuNXqXE9PDVi8hf3nPEhotx22dbbw@mail.gmail.com>
 <CA+7conkr5FtSyc8Bh2aocGarqBgqoWt_h4w_iAo==kPhXFP_sA@mail.gmail.com>
 <CAF7AXFFuvREuqsnZxmbMw7hfUur4KREFrEzo-Q2H5h_0PTpT_A@mail.gmail.com>
 <CA+7con=TBnm=a0Z2+uOVXq-AQVW-oUf8sXzi4_0Z87D5PQcnJQ@mail.gmail.com>
 <CAF7AXFFjJCi3SAcj54b53HkPYT_D0-ScPyWpB0+m_6Gmqe8GEg@mail.gmail.com>
 <CA+7conneJkdfkLmG1qgNxcrsSKt9JAwBjwm8PwfDB-Rp-OSL1Q@mail.gmail.com>
 <CAF7AXFHOeff-+0Zhen+HvC5SWCJJzp_=w8E=UtGpRWSt9YB5iA@mail.gmail.com>
Message-ID: <CA+7con=Te9wQC=NidWjxfrMX8wO2eR8LOM59P9DZhwpRGEJxvQ@mail.gmail.com>

this is the case


On Wed, Apr 23, 2014 at 2:30 PM, Jeff Hardy <jdhardy at gmail.com> wrote:

> On Wed, Apr 23, 2014 at 1:25 PM, Pawel Jasinski
> <pawel.jasinski at gmail.com> wrote:
> > I added the measurements to the PR.
> > Why is startup time of the ipy running out of development way up in
> > comparison with release?
>
> If you use the installer, NGEN. If not, I'm not sure.
>
> - Jeff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140423/8ce1803e/attachment.html>

From no_reply at codeplex.com  Fri Apr 25 09:25:54 2014
From: no_reply at codeplex.com (CodePlex)
Date: 25 Apr 2014 00:25:54 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/24/2014
Message-ID: <CO1MSDNADMCDS2azUSx0000dc10@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New issue] random.Random(None) -> SystemError

----------------------------------------------

ISSUES

1. [New issue] random.Random(None) -> SystemError
http://ironpython.codeplex.com/workitem/35155
User pekkaklarck has proposed the issue:

"Initializing random.Random with None works fine with CPython and Jython but fails with SystemError on IronPython. Using random.Random() as well as random.seed(None) both work fine.
IronPython 2.7.3 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit)
Type "help", "copyright", "credits" or "license" for more information.
>>> import random
>>> random.seed(None)
>>> random.Random()
<Random object at 0x000000000000002B>
>>> random.Random(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Object reference not set to an instance of an object.
>>>
"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140425/83c7f5d0/attachment.html>

From no_reply at codeplex.com  Mon Apr 28 09:22:35 2014
From: no_reply at codeplex.com (CodePlex)
Date: 28 Apr 2014 00:22:35 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/27/2014
Message-ID: <CO1MSDNADMCDS2b6KZm00011ad8@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] dict lookup of System.Int64 and long is not the same
2. [New comment] dict lookup of System.Int64 and long is not the same
3. [New comment] dict lookup of System.Int64 and long is not the same
4. [New comment] random.Random(None) -> SystemError

----------------------------------------------

ISSUES

1. [New comment] dict lookup of System.Int64 and long is not the same
http://ironpython.codeplex.com/workitem/34770
User jdhardy has commented on the issue:

"<p>.NET Int32 and BigInteger hash the same, but Int64 and BigInteger do not.</p>"-----------------

2. [New comment] dict lookup of System.Int64 and long is not the same
http://ironpython.codeplex.com/workitem/34770
User jdhardy has commented on the issue:

"<p>We'll have to come up with a way to work around that, because I agree this behaviour is weird.</p>"-----------------

3. [New comment] dict lookup of System.Int64 and long is not the same
http://ironpython.codeplex.com/workitem/34770
User jdhardy has commented on the issue:

"<p>Fixed in 3c372b8.</p>"-----------------

4. [New comment] random.Random(None) -> SystemError
http://ironpython.codeplex.com/workitem/35155
User jdhardy has commented on the issue:

"<p>Fixed in 0416596.</p>"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140428/5b183166/attachment.html>

From jdhardy at gmail.com  Tue Apr 29 01:17:29 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Tue, 29 Apr 2014 00:17:29 +0100
Subject: [Ironpython-users] IronPython 2.7.5 Bug List
Message-ID: <CAF7AXFHRxGe1CWb3j9Ja9xq0uKuckshMW+CdLK71B+fGAqpjVg@mail.gmail.com>

2.7.5 Beta 2 is a bit behind schedule because there are a bunch of
things I'd like to see fixed before releasing it. The list is at
http://bit.ly/1gbwn7O; there are 10 things left on it. Some are
straightforward, some are a bit trickier. Any help would be
appreciated.

On a better note, I finally fixed encodings.idna, which had 3
different issues going back to *2005*.

- Jeff

From no_reply at codeplex.com  Tue Apr 29 09:29:31 2014
From: no_reply at codeplex.com (CodePlex)
Date: 29 Apr 2014 00:29:31 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/28/2014
Message-ID: <CO1MSDNADMCDS2SNhlx0001383c@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] Support all encodings CPython does for _codecs.encode and _codecs.decode
2. [New comment] LookupError:unknown error handler name 'ignore' / 'unicode_internal' / 'idna'
3. [New comment] cannot import idna from encodings (Ipy 2.7.3)
4. [New comment] Quoted IRONPYTHONPATH causes error with "import"

----------------------------------------------

ISSUES

1. [New comment] Support all encodings CPython does for _codecs.encode and _codecs.decode
http://ironpython.codeplex.com/workitem/4565
User jdhardy has commented on the issue:

"<p>Fixed in 0cbbf99.</p>"-----------------

2. [New comment] LookupError:unknown error handler name 'ignore' / 'unicode_internal' / 'idna'
http://ironpython.codeplex.com/workitem/23832
User jdhardy has commented on the issue:

"<p>Fixed in 0cbbf99.</p>"-----------------

3. [New comment] cannot import idna from encodings (Ipy 2.7.3)
http://ironpython.codeplex.com/workitem/34651
User jdhardy has commented on the issue:

"<p>Fixed in 0cbbf99.</p>"-----------------

4. [New comment] Quoted IRONPYTHONPATH causes error with "import"
http://ironpython.codeplex.com/workitem/34687
User slide_o_mix has commented on the issue:

"<p>The PATH environment variable in Windows doesn't like having quotes in it either, so wouldn't not allowing quotes be following the platform?</p>"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140429/99f21e8c/attachment.html>

From slide.o.mix at gmail.com  Tue Apr 29 19:30:37 2014
From: slide.o.mix at gmail.com (Slide)
Date: Tue, 29 Apr 2014 10:30:37 -0700
Subject: [Ironpython-users] IronPython 2.7.5 Bug List
In-Reply-To: <CAF7AXFHRxGe1CWb3j9Ja9xq0uKuckshMW+CdLK71B+fGAqpjVg@mail.gmail.com>
References: <CAF7AXFHRxGe1CWb3j9Ja9xq0uKuckshMW+CdLK71B+fGAqpjVg@mail.gmail.com>
Message-ID: <CAPiUgVeDCC2q7OeOda152B-1sbapVSD9LH6YchUjOqnjM+ixvA@mail.gmail.com>

Is this the PLW that is mentioned?
https://bitbucket.org/vinay.sajip/pylauncher/src


On Mon, Apr 28, 2014 at 4:17 PM, Jeff Hardy <jdhardy at gmail.com> wrote:

> 2.7.5 Beta 2 is a bit behind schedule because there are a bunch of
> things I'd like to see fixed before releasing it. The list is at
> http://bit.ly/1gbwn7O; there are 10 things left on it. Some are
> straightforward, some are a bit trickier. Any help would be
> appreciated.
>
> On a better note, I finally fixed encodings.idna, which had 3
> different issues going back to *2005*.
>
> - Jeff
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>



-- 
Website: http://earl-of-code.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140429/b84c6c79/attachment.html>

From darnold992000 at yahoo.com  Tue Apr 29 22:39:51 2014
From: darnold992000 at yahoo.com (Don Arnold)
Date: Tue, 29 Apr 2014 13:39:51 -0700 (PDT)
Subject: [Ironpython-users] issue creating object from third-party assembly
Message-ID: <1398803991.7914.YahooMailBasic@web140606.mail.bf1.yahoo.com>

Hi! I'm having trouble understanding some weird behavior when trying to use an object defined in a third-party assembly. 
When I view the assembly in Object Explorer, I see that the CosEvent class defines two constructors.

One parameterless:
 
public CosEvent()
    Member of Cos.Core.EMS.CosEvent


And one parameterized:

public CosEvent(ref string prmPlatform, ref string prmProcessname, ref int prmProcessInstance, ref char prmEventType, ref int prmEventNumber, ref int prmErrorNumber, ref string prmEventDescription)
    Member of Cos.Core.EMS.CosEvent


So far, so good. But when I run the following test script:

import clr
import System

clr.AddReferenceToFileAndPath(r'c:\dll\CosEventManagement.dll')

import Cos.Core.EMS

print 50 * '-'
print '-- parameterless constructor'
print 50 * '-'
e = Cos.Core.EMS.CosEvent()
print type(e)
print e

print 50 * '-'
print '-- parameterized constructor with keyword params'
print 50 * '-'
e = Cos.Core.EMS.CosEvent(Platform='om5681d2',ProcessName='test process',ProcessInstance=1,EventType='S',EventNumber=1000,ErrorNumber=0,EventDescription='just another lousy test')
print type(e)
print e

print 50 * '-'
print '-- parameterized constructor with positional params'
print 50 * '-'
e = Cos.Core.EMS.CosEvent('om5681d2','test process',1,'S',1000,0,'just another lousy test')
print type(e)
print e


This is its output: 

--------------------------------------------------
-- parameterless constructor
--------------------------------------------------
<type 'CosEvent'>
<Cos.Core.EMS.CosEvent object at 0x000000000000002B [Cos.Core.EMS.CosEvent]>
--------------------------------------------------
-- parameterized constructor with keyword params
--------------------------------------------------
<type 'CosEvent'>
<Cos.Core.EMS.CosEvent object at 0x000000000000002C [Cos.Core.EMS.CosEvent]>
--------------------------------------------------
-- parameterized constructor with positional params
--------------------------------------------------
<type 'tuple'>
(<Cos.Core.EMS.CosEvent object at 0x000000000000002D [Cos.Core.EMS.CosEvent]>, '
om5681d2', 'test process', 1, <System.Char object at 0x000000000000002E [S]>, 10
00, 0, 'just another lousy test')


When I call the parameterless constructor, I get back a CosEvent object.
Likewise when I call the parameterized constructor using keyword parameters.
But when I call the parameterized constructor using positional parameters, I get a tuple containing the CosEvent object and its parameters.
And it's that third result that I'm not understanding...

Am I missing (or maybe just misunderstanding) something? Why do I get a tuple instead of just the 'naked' CosEvent object? And why does it only happen when I use positional parameters?

Any help you can give is greatly appreciated.

Thanks,
Don 

From jdhardy at gmail.com  Tue Apr 29 22:42:41 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Tue, 29 Apr 2014 21:42:41 +0100
Subject: [Ironpython-users] IronPython 2.7.5 Bug List
In-Reply-To: <CAPiUgVeDCC2q7OeOda152B-1sbapVSD9LH6YchUjOqnjM+ixvA@mail.gmail.com>
References: <CAF7AXFHRxGe1CWb3j9Ja9xq0uKuckshMW+CdLK71B+fGAqpjVg@mail.gmail.com>
 <CAPiUgVeDCC2q7OeOda152B-1sbapVSD9LH6YchUjOqnjM+ixvA@mail.gmail.com>
Message-ID: <CAF7AXFFgs8-u7Jtm5CB5_yfvxFtG0v9MOj7ODT9vpoyS8yxk6w@mail.gmail.com>

On Tue, Apr 29, 2014 at 6:30 PM, Slide <slide.o.mix at gmail.com> wrote:
> Is this the PLW that is mentioned?
> https://bitbucket.org/vinay.sajip/pylauncher/src

I think it lives in the main CPython tree now:
http://hg.python.org/cpython/file/tip/PC/launcher.c.

- Jeff

From vano at mail.mipt.ru  Tue Apr 29 22:51:40 2014
From: vano at mail.mipt.ru (Ivan Pozdeev)
Date: Wed, 30 Apr 2014 00:51:40 +0400
Subject: [Ironpython-users] issue creating object from third-party
	assembly
In-Reply-To: <1398803991.7914.YahooMailBasic@web140606.mail.bf1.yahoo.com>
References: <1398803991.7914.YahooMailBasic@web140606.mail.bf1.yahoo.com>
Message-ID: <312338243.20140430005140@mail.mipt.ru>

RTFM http://ironpython.net/documentation/dotnet/dotnet.html#ref-and-out-parameters .

-----Original Message-----
From: Don Arnold <darnold992000 at yahoo.com.dmarc.invalid>
Sent: Wednesday, April 30, 2014 0:39
To: ironpython-users at python.org <ironpython-users at python.org>
Cc: 
Subject: [Ironpython-users] issue creating object from third-party assembly

Hi! I'm having trouble understanding some weird behavior when trying to use an object defined in a third-party assembly. 
When I view the assembly in Object Explorer, I see that the CosEvent class defines two constructors.

One parameterless:
 
public CosEvent()
    Member of Cos.Core.EMS.CosEvent


And one parameterized:

public CosEvent(ref string prmPlatform, ref string prmProcessname, ref int prmProcessInstance, ref char prmEventType, ref int prmEventNumber, ref int prmErrorNumber, ref string prmEventDescription)
    Member of Cos.Core.EMS.CosEvent


So far, so good. But when I run the following test script:

import clr
import System

clr.AddReferenceToFileAndPath(r'c:\dll\CosEventManagement.dll')

import Cos.Core.EMS

print 50 * '-'
print '-- parameterless constructor'
print 50 * '-'
e = Cos.Core.EMS.CosEvent()
print type(e)
print e

print 50 * '-'
print '-- parameterized constructor with keyword params'
print 50 * '-'
e = Cos.Core.EMS.CosEvent(Platform='om5681d2',ProcessName='test process',ProcessInstance=1,EventType='S',EventNumber=1000,ErrorNumber=0,EventDescription='just another lousy test')
print type(e)
print e

print 50 * '-'
print '-- parameterized constructor with positional params'
print 50 * '-'
e = Cos.Core.EMS.CosEvent('om5681d2','test process',1,'S',1000,0,'just another lousy test')
print type(e)
print e


This is its output: 

--------------------------------------------------
-- parameterless constructor
--------------------------------------------------
<type 'CosEvent'>
<Cos.Core.EMS.CosEvent object at 0x000000000000002B [Cos.Core.EMS.CosEvent]>
--------------------------------------------------
-- parameterized constructor with keyword params
--------------------------------------------------
<type 'CosEvent'>
<Cos.Core.EMS.CosEvent object at 0x000000000000002C [Cos.Core.EMS.CosEvent]>
--------------------------------------------------
-- parameterized constructor with positional params
--------------------------------------------------
<type 'tuple'>
(<Cos.Core.EMS.CosEvent object at 0x000000000000002D [Cos.Core.EMS.CosEvent]>, '
om5681d2', 'test process', 1, <System.Char object at 0x000000000000002E [S]>, 10
00, 0, 'just another lousy test')


When I call the parameterless constructor, I get back a CosEvent object.
Likewise when I call the parameterized constructor using keyword parameters.
But when I call the parameterized constructor using positional parameters, I get a tuple containing the CosEvent object and its parameters.
And it's that third result that I'm not understanding...

Am I missing (or maybe just misunderstanding) something? Why do I get a tuple instead of just the 'naked' CosEvent object? And why does it only happen when I use positional parameters?

Any help you can give is greatly appreciated.

Thanks,
Don 
_______________________________________________
Ironpython-users mailing list
Ironpython-users at python.org
https://mail.python.org/mailman/listinfo/ironpython-users


From vano at mail.mipt.ru  Tue Apr 29 22:59:20 2014
From: vano at mail.mipt.ru (Ivan Pozdeev)
Date: Wed, 30 Apr 2014 00:59:20 +0400
Subject: [Ironpython-users] issue creating object from third-party
	assembly
In-Reply-To: <1398803991.7914.YahooMailBasic@web140606.mail.bf1.yahoo.com>
References: <1398803991.7914.YahooMailBasic@web140606.mail.bf1.yahoo.com>
Message-ID: <726263365.20140430005920@mail.mipt.ru>

> Hi! I'm having trouble understanding some weird behavior when trying to use an object defined in a third-party assembly.
> When I view the assembly in Object Explorer, I see that the CosEvent class defines two constructors.

> One parameterless:
>  
> public CosEvent()
>     Member of Cos.Core.EMS.CosEvent


> And one parameterized:

> public CosEvent(ref string prmPlatform, ref string prmProcessname, ref int prmProcessInstance, ref char prmEventType,
> ref int prmEventNumber, ref int prmErrorNumber, ref string prmEventDescription)
>     Member of Cos.Core.EMS.CosEvent


> So far, so good. But when I run the following test script:

> import clr
> import System

> clr.AddReferenceToFileAndPath(r'c:\dll\CosEventManagement.dll')

> import Cos.Core.EMS

> print 50 * '-'
> print '-- parameterless constructor'
> print 50 * '-'
> e = Cos.Core.EMS.CosEvent()
> print type(e)
> print e

> print 50 * '-'
> print '-- parameterized constructor with keyword params'
> print 50 * '-'
> e = Cos.Core.EMS.CosEvent(Platform='om5681d2',ProcessName='test
> process',ProcessInstance=1,EventType='S',EventNumber=1000,ErrorNumber=0,EventDescription='just another lousy test')
> print type(e)
> print e

> print 50 * '-'
> print '-- parameterized constructor with positional params'
> print 50 * '-'
> e = Cos.Core.EMS.CosEvent('om5681d2','test process',1,'S',1000,0,'just another lousy test')
> print type(e)
> print e


> This is its output: 

> --------------------------------------------------
> -- parameterless constructor
> --------------------------------------------------
> <type 'CosEvent'>
> <Cos.Core.EMS.CosEvent object at 0x000000000000002B [Cos.Core.EMS.CosEvent]>
> --------------------------------------------------
> -- parameterized constructor with keyword params
> --------------------------------------------------
> <type 'CosEvent'>
> <Cos.Core.EMS.CosEvent object at 0x000000000000002C [Cos.Core.EMS.CosEvent]>
> --------------------------------------------------
> -- parameterized constructor with positional params
> --------------------------------------------------
> <type 'tuple'>
> (<Cos.Core.EMS.CosEvent object at 0x000000000000002D [Cos.Core.EMS.CosEvent]>, '
> om5681d2', 'test process', 1, <System.Char object at 0x000000000000002E [S]>, 10
> 00, 0, 'just another lousy test')


> When I call the parameterless constructor, I get back a CosEvent object.
> Likewise when I call the parameterized constructor using keyword parameters.
> But when I call the parameterized constructor using positional parameters, I get a tuple containing the CosEvent object and its parameters.
> And it's that third result that I'm not understanding...

> Am I missing (or maybe just misunderstanding) something? Why do I get a tuple instead of just the 'naked' CosEvent
> object? And why does it only happen when I use positional parameters?

> Any help you can give is greatly appreciated.

> Thanks,
> Don 
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users

RTFM http://ironpython.net/documentation/dotnet/dotnet.html#ref-and-out-parameters .

-- 
Best regards,
 Ivan                            mailto:vano at mail.mipt.ru


From darnold992000 at yahoo.com  Wed Apr 30 01:20:53 2014
From: darnold992000 at yahoo.com (darnold992000 at yahoo.com)
Date: Tue, 29 Apr 2014 18:20:53 -0500
Subject: [Ironpython-users] issue creating object from third-party
	assembly
Message-ID: <1659A802-BD2E-497B-AEA5-885EEF810706@yahoo.com>



Don

From darnold992000 at yahoo.com  Wed Apr 30 01:29:02 2014
From: darnold992000 at yahoo.com (darnold992000 at yahoo.com)
Date: Tue, 29 Apr 2014 18:29:02 -0500
Subject: [Ironpython-users] issue creating object from third-party
	assembly
Message-ID: <A712BC90-9F17-4325-82C5-9FB79CB16478@yahoo.com>

Thank you, Ivan. I (obviously) hadn't encountered reference params from the Ironpython side before.It all makes perfect sense, now.

Don

From no_reply at codeplex.com  Wed Apr 30 09:23:59 2014
From: no_reply at codeplex.com (CodePlex)
Date: 30 Apr 2014 00:23:59 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/29/2014
Message-ID: <CO1MSDNADMCDS23dDw800015776@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] metaclass interferes with property/partial
2. [New comment] PEP 397 -- Python launcher for Windows

----------------------------------------------

ISSUES

1. [New comment] metaclass interferes with property/partial
http://ironpython.codeplex.com/workitem/34968
User jdhardy has commented on the issue:

"<p>The issue seems to be related to how IronPython is trying to call the partial.Call method. The binding code path for builtin methods (partial is in C#) is complicated and difficult to trace. Why it's different with a metaclass than without I'm not sure.</p><p>When running in Debug mode it hits an Assert on L74 of Runtime\Microsoft.Dynamic\Actions\Calls\DefaultOverloadResolver.cs because there aren't the right number of arguments. Eventually it reaches partial.Call with arguments missing. </p>"-----------------

2. [New comment] PEP 397 -- Python launcher for Windows
http://ironpython.codeplex.com/workitem/35064
User slide_o_mix has commented on the issue:

"<p>Were these issues ever filed in the Python tracker?</p>"
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140430/8d88b3df/attachment.html>