From no_reply at codeplex.com  Fri May  2 09:23:38 2014
From: no_reply at codeplex.com (CodePlex)
Date: 2 May 2014 00:23:38 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/1/2014
Message-ID: <CO1MSDNADMCDS2Jk99f00019439@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New issue] types.FunctionType(...) raise NotImplementedError
2. [New comment] types.FunctionType(...) raise NotImplementedError

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

ISSUES

1. [New issue] types.FunctionType(...) raise NotImplementedError
http://ironpython.codeplex.com/workitem/35180
User jdhardy has proposed the issue:

"(from http://stackoverflow.com/questions/23379383/ironpython-2-7-with-networkx-1-8-1).

This piece of networkX (https://github.com/networkx/networkx/blob/master/networkx/algorithms/isomorphism/matchhelpers.py#L24):
types.FunctionType(f.func_code, f.func_globals,
                              name or f.__name__, f.func_defaults,
                              f.func_closure)


raises:
NotImplementedError: The method or operation is not implemented.
File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\networkx\algorithms\isomorphism\matchhelpers.py", line 23, in copyfunc
return types.FunctionType(f.func_code, f.func_globals, name or f.name, .....
"-----------------

2. [New comment] types.FunctionType(...) raise NotImplementedError
http://ironpython.codeplex.com/workitem/35180
User jdhardy has commented on the issue:

"<p>The relevant code in IronPython is at https://github.com/IronLanguages/main/blob/ipy-2.7-maint/Languages/IronPython/IronPython/Runtime/PythonFunction.cs#L72. I'm not sure why that constructor throws an exception.</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/20140502/330b03c1/attachment.html>

From no_reply at codeplex.com  Sat May  3 09:22:50 2014
From: no_reply at codeplex.com (CodePlex)
Date: 3 May 2014 00:22:50 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/2/2014
Message-ID: <CO1MSDNADMCDS2Hkidc0001b02d@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [Status update] no public usable FunctionType.__new__
2. [New comment] no public usable FunctionType.__new__
3. [New comment] types.FunctionType(...) raise NotImplementedError
4. [New comment] types.FunctionType(...) raise NotImplementedError

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

ISSUES

1. [Status update] no public usable FunctionType.__new__
http://ironpython.codeplex.com/workitem/34932
User paweljasinski has updated the issue:
Status has changed from Proposed to Closed with the following comment, 

"There is a new issue with active discussion."-----------------

2. [New comment] no public usable FunctionType.__new__
http://ironpython.codeplex.com/workitem/34932
User paweljasinski has commented on the issue:

"<p>Dupplicate: https://ironpython.codeplex.com/workitem/35180</p>"-----------------

3. [New comment] types.FunctionType(...) raise NotImplementedError
http://ironpython.codeplex.com/workitem/35180
User jdhardy has commented on the issue:

"<p>From DinoV:</p><p>&quot;I think the reason it's not implemented is due to the closure object and the globals dictionary.  Those need to be converted into the appropriate MutableTuple and into the correct CodeContext which defines the function.  If there is a closure then that means going off and constructing a RuntimeVariablesDictionaryStorage for the dictionary used for the code context of the function.</p><p>&quot;Depending on the function that's being copied it might be easy enough to make this work in the non-closure case (checking both the FunctionCode and the passed in closure tuple) and throwing NotImplemented in the closure case.  Or someone needs to work through recreating these data structures.  I'd actually have to go back and look at how we're generating functions to remember what goes into the MutableTuple, I suspect it's the actual ClosureCell objects and maybe the CodeContext as well.  It's probably not too difficult to implement it was just never necessary :)&quot;</p>"-----------------

4. [New comment] types.FunctionType(...) raise NotImplementedError
http://ironpython.codeplex.com/workitem/35180
User paweljasinski has commented on the issue:

"<p>dupplicate: https://ironpython.codeplex.com/workitem/34932</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/20140503/260d87df/attachment.html>

From vernondcole at gmail.com  Sun May  4 11:43:14 2014
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Sun, 4 May 2014 03:43:14 -0600
Subject: [Ironpython-users] Announcing adodbapi version 2.6
Message-ID: <CAH-ZgAcTfDOHOiOw4vcKROqAi6nc1AxJnJLN4KjFyZpYwuFQOg@mail.gmail.com>

Active Data Objects Data-Base Application Program Interface is a PEP-249
compliant SQL database package which will work with a large number of
tabular data sources.  It is tested using a Microsoft SQL Server database,
along with PostgreSQL, MySQL and Jet (Microsoft ACCESS) databases.  An
included example manipulates an .xls spreadsheet using SQL commands.

Although adodbapi continues to lead in development and standardization of
API extensions (such as referencing data columns by name), version 2.6 is
mostly a maintenance release with some refactoring, and only a few new
features:

It now supports prepared SQL statements using a simple interface. For
example...

> conn = adodbapi.connect('your connection string here')
> crsr = conn.cursor()
> crsr.prepare('some SQL statement where ? = ?')
> for parameters in sequence_of_parameter_sequences:
>
    crsr.execute(crsr.command, parameters)
>

In addition to the conjectured db-api version 3 standard of requiring SQL
parameter "paramstyles" of 'qmark' and 'numeric' , version 2.6 extends the
list to ['qmark', 'numeric', 'format', 'pyformat', 'dynamic'].  Switching
between sequences of parameters, and dictionaries of parameters, is dynamic
for some paramstyles.  [If you don't know what a 'paramstyle' is, it might
be better to remain oblivious.  ;-)   ]

Lightweight documentation athttp://adodbapi.sourceforge.net/quick_reference.pdf

Project at https://sourceforge.net/projects/adodbapi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140504/823fcd2d/attachment.html>

From vernondcole at gmail.com  Tue May  6 10:37:57 2014
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Tue, 6 May 2014 09:37:57 +0100
Subject: [Ironpython-users] Supporting ensurepip early in the development
	timeline?
Message-ID: <CAH-ZgAdYhZkrQJMLynX2w=vBCz+F-ypL2HW9aTj8v9QWSWYhVQ@mail.gmail.com>

The following post appeared in Jython-dev this morning.

I think that this might be a really good idea for IronPython, too,
especially now that there is a patch for setuptools so that it will not
choke on Iron.

Should this be included as a work item in our tracker?
--
Vernon Cole
v v v v v v v

Date: Mon, 5 May 2014 12:24:41 -0600
From: Jim Baker <jim.baker at python.org>
Subject: [Jython-dev] Supporting ensurepip in beta 4
To: Jython Developers <jython-dev at lists.sourceforge.net>
Message-ID:
        <CAL9RhrX8HNzFvRX4YNC6za7mc8tboWJC7+b16w2YEHVwvG8F9w at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I just had a nice conversation on #pypa-dev re ensurepip, which is part of
Python 3.4 and will also be bundled in PyPy 2.3, which supports both 2.7
and 3.4 versions of Python. I recommend that Jython 2.7 do the same, given
that like PyPy we are under active development, unlike CPython 2.7.

We should be able to do this in time for beta 4.

ensurepip (https://docs.python.org/3/library/ensurepip.html) provides
support for having a bundled version of pip, which is then used to install
the current version of pip in a matter that's transparent to the user.
Jython simply needs to bundle the required pip and setuptools wheels and
the ensurepip package in stdlib.

This will mean that our users will have pip immediately available to them
upon installing Jython, with no extra steps required. PyPy has done the
hard work to provide a 2.7-compatible version. More rationale here:
http://legacy.python.org/dev/peps/pep-0453/

This timeline depends on a pull request I made against pip's vendor lib
dependency html5lib-python getting made, but I don't expect us to see any
blockers there.

- Jim
^ ^ ^ ^ ^ ^ ^ ^ ^
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140506/75012c7b/attachment.html>

From olof.bjarnason at gmail.com  Tue May  6 15:09:10 2014
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Tue, 6 May 2014 14:09:10 +0100
Subject: [Ironpython-users] Supporting ensurepip early in the
	development timeline?
In-Reply-To: <CAH-ZgAdYhZkrQJMLynX2w=vBCz+F-ypL2HW9aTj8v9QWSWYhVQ@mail.gmail.com>
References: <CAH-ZgAdYhZkrQJMLynX2w=vBCz+F-ypL2HW9aTj8v9QWSWYhVQ@mail.gmail.com>
Message-ID: <CA+LucOiDRdrC16q1CRGDB4Bdq=Oc03-VXR3rkfeiAM5nOKgzog@mail.gmail.com>

PIP built-in sounds like a dream :)

Is there anything I can help out on testing this?

On 6 May 2014 09:37, Vernon D. Cole <vernondcole at gmail.com> wrote:
> The following post appeared in Jython-dev this morning.
>
> I think that this might be a really good idea for IronPython, too,
> especially now that there is a patch for setuptools so that it will not
> choke on Iron.
>
> Should this be included as a work item in our tracker?
> --
> Vernon Cole
> v v v v v v v
>
> Date: Mon, 5 May 2014 12:24:41 -0600
> From: Jim Baker <jim.baker at python.org>
> Subject: [Jython-dev] Supporting ensurepip in beta 4
> To: Jython Developers <jython-dev at lists.sourceforge.net>
> Message-ID:
>         <CAL9RhrX8HNzFvRX4YNC6za7mc8tboWJC7+b16w2YEHVwvG8F9w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I just had a nice conversation on #pypa-dev re ensurepip, which is part of
> Python 3.4 and will also be bundled in PyPy 2.3, which supports both 2.7
> and 3.4 versions of Python. I recommend that Jython 2.7 do the same, given
> that like PyPy we are under active development, unlike CPython 2.7.
>
> We should be able to do this in time for beta 4.
>
> ensurepip (https://docs.python.org/3/library/ensurepip.html) provides
> support for having a bundled version of pip, which is then used to install
> the current version of pip in a matter that's transparent to the user.
> Jython simply needs to bundle the required pip and setuptools wheels and
> the ensurepip package in stdlib.
>
> This will mean that our users will have pip immediately available to them
> upon installing Jython, with no extra steps required. PyPy has done the
> hard work to provide a 2.7-compatible version. More rationale here:
> http://legacy.python.org/dev/peps/pep-0453/
>
> This timeline depends on a pull request I made against pip's vendor lib
> dependency html5lib-python getting made, but I don't expect us to see any
> blockers there.
>
> - Jim
> ^ ^ ^ ^ ^ ^ ^ ^ ^
>
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>

From hmarne at gmail.com  Tue May  6 15:31:00 2014
From: hmarne at gmail.com (Harshal Marne)
Date: Tue, 6 May 2014 19:01:00 +0530
Subject: [Ironpython-users] Use 'ipy.exe' to run tests in Robot framework
Message-ID: <CAO-NeNB2NFr8bx1+vDrqLTTr5bHYPdex4BRad+iVoq3g2E_52g@mail.gmail.com>

Setup details:
System: windows 2008
Robot framework: 2.8.4
Python 2.7.6
IronPython 2.7

Task:
To run tests based on (.dll created out of c# code) as described in
https://code.google.com/p/robotframework/wiki/HowToUseCSharp

Issue:
  File "C:\Python27\Lib\site-packages\robot\utils\__init__.py", line 44, in
<module>
  File "C:\Python27\Lib\site-packages\robot\utils\etreewrapper.py", line
46, in <module>
ImportError: No valid ElementTree XML parser module found
Press any key to continue . . .

Work-around tried:
As described in
https://code.google.com/p/robotframework/issues/detail?id=154 copied
https://svn.code.sf.net/p/fepy/code/trunk/lib/pyexpat.py and placed it
in C:\Program Files (x86)\IronPython 2.7\Lib as expat.py

Queries:
1) Is the fix in workaround being tried is correct or not?
2) If not does any idea if this issue (
http://ironpython.codeplex.com/workitem/31923, 21047 ) will get fixed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140506/49f3051b/attachment.html>

From no_reply at codeplex.com  Wed May  7 09:29:40 2014
From: no_reply at codeplex.com (CodePlex)
Date: 7 May 2014 00:29:40 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/6/2014
Message-ID: <CO1MSDNADMCDS2FJ3sl00021434@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] types.FunctionType(...) raise NotImplementedError
2. [New issue] Code coverage for Ironpython scripts

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

ISSUES

1. [New comment] types.FunctionType(...) raise NotImplementedError
http://ironpython.codeplex.com/workitem/35180
User paweljasinski has commented on the issue:

"<p>Dino, can you elaborate on &quot;correct CodeContext which defines the function&quot;.<br>My minimal use case is to replace function globals as described here:  https://ironpython.codeplex.com/workitem/34932<br></p>"-----------------

2. [New issue] Code coverage for Ironpython scripts
http://ironpython.codeplex.com/workitem/35194
User AnandkumarP has proposed the issue:

"Hi,
Is there any code coverage tool identified for Iron python? If so please let me know the tool. If not, please let me know when it will be available."
----------------------------------------------



----------------------------------------------
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/20140507/de643f8e/attachment.html>

From jdhardy at gmail.com  Wed May  7 09:50:40 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 7 May 2014 08:50:40 +0100
Subject: [Ironpython-users] Supporting ensurepip early in the
	development timeline?
In-Reply-To: <CA+LucOiDRdrC16q1CRGDB4Bdq=Oc03-VXR3rkfeiAM5nOKgzog@mail.gmail.com>
References: <CAH-ZgAdYhZkrQJMLynX2w=vBCz+F-ypL2HW9aTj8v9QWSWYhVQ@mail.gmail.com>
 <CA+LucOiDRdrC16q1CRGDB4Bdq=Oc03-VXR3rkfeiAM5nOKgzog@mail.gmail.com>
Message-ID: <CAF7AXFEuYAcGVocp5GViYiy6GAwSLvKqYikSWPF9MWpecwsfOg@mail.gmail.com>

On Tue, May 6, 2014 at 2:09 PM, Olof Bjarnason <olof.bjarnason at gmail.com> wrote:
> PIP built-in sounds like a dream :)
>
> Is there anything I can help out on testing this?

First, open an issue: https://ironpython.codeplex.com/WorkItem/Create,
and send me your CodePlex username so I can add you to the project
(after 2.7.5 everything will move to GitHub, but I'm using CP for one
last release, for old times' sake) and you can edit/close issues.

I've wanted to have pip working for quite a while now but just never
found the time.[1] Honestly though, it should be pretty easy.
ensurepip I've never looked at, so I don't know, but I can't imagine
it being too difficult. Upstream on these projects is open to patches
for IronPython support as well, so there shouldn't be any issues
there. With ensurepip we could even distribute our own fork if we had
to.

>From what I recall the major issue with pip was making sure that it
had with: blocks where needed, since parts of it implicitly relied on
CPython's refcounting GC to close files deterministically. That may
have been cleaned up over the years.

Because of various things over the next month 2.7.5 probably won't
land until June, so there should be lots of time to get pip/ensurepip
ready.

- Jeff

[1] http://wondermark.com/729/

>
> On 6 May 2014 09:37, Vernon D. Cole <vernondcole at gmail.com> wrote:
>> The following post appeared in Jython-dev this morning.
>>
>> I think that this might be a really good idea for IronPython, too,
>> especially now that there is a patch for setuptools so that it will not
>> choke on Iron.
>>
>> Should this be included as a work item in our tracker?
>> --
>> Vernon Cole
>> v v v v v v v
>>
>> Date: Mon, 5 May 2014 12:24:41 -0600
>> From: Jim Baker <jim.baker at python.org>
>> Subject: [Jython-dev] Supporting ensurepip in beta 4
>> To: Jython Developers <jython-dev at lists.sourceforge.net>
>> Message-ID:
>>         <CAL9RhrX8HNzFvRX4YNC6za7mc8tboWJC7+b16w2YEHVwvG8F9w at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> I just had a nice conversation on #pypa-dev re ensurepip, which is part of
>> Python 3.4 and will also be bundled in PyPy 2.3, which supports both 2.7
>> and 3.4 versions of Python. I recommend that Jython 2.7 do the same, given
>> that like PyPy we are under active development, unlike CPython 2.7.
>>
>> We should be able to do this in time for beta 4.
>>
>> ensurepip (https://docs.python.org/3/library/ensurepip.html) provides
>> support for having a bundled version of pip, which is then used to install
>> the current version of pip in a matter that's transparent to the user.
>> Jython simply needs to bundle the required pip and setuptools wheels and
>> the ensurepip package in stdlib.
>>
>> This will mean that our users will have pip immediately available to them
>> upon installing Jython, with no extra steps required. PyPy has done the
>> hard work to provide a 2.7-compatible version. More rationale here:
>> http://legacy.python.org/dev/peps/pep-0453/
>>
>> This timeline depends on a pull request I made against pip's vendor lib
>> dependency html5lib-python getting made, but I don't expect us to see any
>> blockers there.
>>
>> - Jim
>> ^ ^ ^ ^ ^ ^ ^ ^ ^
>>
>>
>> _______________________________________________
>> 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

From jdhardy at gmail.com  Wed May  7 09:57:21 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 7 May 2014 08:57:21 +0100
Subject: [Ironpython-users] Use 'ipy.exe' to run tests in Robot framework
In-Reply-To: <CAO-NeNB2NFr8bx1+vDrqLTTr5bHYPdex4BRad+iVoq3g2E_52g@mail.gmail.com>
References: <CAO-NeNB2NFr8bx1+vDrqLTTr5bHYPdex4BRad+iVoq3g2E_52g@mail.gmail.com>
Message-ID: <CAF7AXFGL0n3GQpODBVcH6mO17M4pyz08J2xrVCSEgCuN+Qf4ZA@mail.gmail.com>

On Tue, May 6, 2014 at 2:31 PM, Harshal Marne <hmarne at gmail.com> wrote:
> Setup details:
> System: windows 2008
> Robot framework: 2.8.4
> Python 2.7.6
> IronPython 2.7
>
> Task:
> To run tests based on (.dll created out of c# code) as described in
> https://code.google.com/p/robotframework/wiki/HowToUseCSharp
>
> Issue:
>   File "C:\Python27\Lib\site-packages\robot\utils\__init__.py", line 44, in
> <module>
>   File "C:\Python27\Lib\site-packages\robot\utils\etreewrapper.py", line 46,
> in <module>
> ImportError: No valid ElementTree XML parser module found
> Press any key to continue . . .

I wonder if robot is picking up the Python ElemtTree implementation
instead of IronPython's (we patch ETree to not require pyexpat). Try
copying the robot files into IronPython's Lib/site-packages and see if
anything changes.

>
> Work-around tried:
> As described in
> https://code.google.com/p/robotframework/issues/detail?id=154 copied
> https://svn.code.sf.net/p/fepy/code/trunk/lib/pyexpat.py and placed it in
> C:\Program Files (x86)\IronPython 2.7\Lib as expat.py
>
> Queries:
> 1) Is the fix in workaround being tried is correct or not?

That's really old code, so I don't know if it has enough to run ElementTree.

> 2) If not does any idea if this issue (
> http://ironpython.codeplex.com/workitem/31923, 21047 ) will get fixed.

I don't think anyone is currently working on it. Alex did some work
that I think is in a GH fork somewhere that could be a starting
(resuming?) point.

- Jeff

From hmarne at gmail.com  Wed May  7 10:05:03 2014
From: hmarne at gmail.com (Harshal Marne)
Date: Wed, 7 May 2014 13:35:03 +0530
Subject: [Ironpython-users] Use 'ipy.exe' to run tests in Robot framework
In-Reply-To: <CAF7AXFGL0n3GQpODBVcH6mO17M4pyz08J2xrVCSEgCuN+Qf4ZA@mail.gmail.com>
References: <CAO-NeNB2NFr8bx1+vDrqLTTr5bHYPdex4BRad+iVoq3g2E_52g@mail.gmail.com>
 <CAF7AXFGL0n3GQpODBVcH6mO17M4pyz08J2xrVCSEgCuN+Qf4ZA@mail.gmail.com>
Message-ID: <CAO-NeNCxWP0z3j9_B9SSxa7LLK70KR0OKwnY0JgGo+q209E7iA@mail.gmail.com>

Hi Jeff,

Was able to run the test after installing
http://effbot.org/media/downloads/elementtree-1.2.7-20070827-preview.win32.exe
This fixes - 'ImportError' and test-cases created by calling functions in a
.dll created out of .cs code are run successfully.

Regards,
~ Harshal


On Wed, May 7, 2014 at 1:27 PM, Jeff Hardy <jdhardy at gmail.com> wrote:

> On Tue, May 6, 2014 at 2:31 PM, Harshal Marne <hmarne at gmail.com> wrote:
> > Setup details:
> > System: windows 2008
> > Robot framework: 2.8.4
> > Python 2.7.6
> > IronPython 2.7
> >
> > Task:
> > To run tests based on (.dll created out of c# code) as described in
> > https://code.google.com/p/robotframework/wiki/HowToUseCSharp
> >
> > Issue:
> >   File "C:\Python27\Lib\site-packages\robot\utils\__init__.py", line 44,
> in
> > <module>
> >   File "C:\Python27\Lib\site-packages\robot\utils\etreewrapper.py", line
> 46,
> > in <module>
> > ImportError: No valid ElementTree XML parser module found
> > Press any key to continue . . .
>
> I wonder if robot is picking up the Python ElemtTree implementation
> instead of IronPython's (we patch ETree to not require pyexpat). Try
> copying the robot files into IronPython's Lib/site-packages and see if
> anything changes.
>
> >
> > Work-around tried:
> > As described in
> > https://code.google.com/p/robotframework/issues/detail?id=154 copied
> > https://svn.code.sf.net/p/fepy/code/trunk/lib/pyexpat.py and placed it
> in
> > C:\Program Files (x86)\IronPython 2.7\Lib as expat.py
> >
> > Queries:
> > 1) Is the fix in workaround being tried is correct or not?
>
> That's really old code, so I don't know if it has enough to run
> ElementTree.
>
> > 2) If not does any idea if this issue (
> > http://ironpython.codeplex.com/workitem/31923, 21047 ) will get fixed.
>
> I don't think anyone is currently working on it. Alex did some work
> that I think is in a GH fork somewhere that could be a starting
> (resuming?) point.
>
> - Jeff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140507/06b21f69/attachment.html>

From jdhardy at gmail.com  Wed May  7 10:20:06 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 7 May 2014 09:20:06 +0100
Subject: [Ironpython-users] Missing encodings in IronPython
Message-ID: <CAF7AXFFjKQ=FYbGf1Qm=ixbNYhbxTMb91ghnYd9DPT1WRRt3Yg@mail.gmail.com>

There are still a few "native" encodings missing from
(https://ironpython.codeplex.com/workitem/1214 and others - search for
"encoding").

In particular, https://ironpython.codeplex.com/workitem/15506 would be
a really easy fix for anyone who wants to get started.

- Jeff

From olof.bjarnason at gmail.com  Wed May  7 10:34:45 2014
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Wed, 7 May 2014 09:34:45 +0100
Subject: [Ironpython-users] Supporting ensurepip early in the
	development timeline?
In-Reply-To: <CAF7AXFEuYAcGVocp5GViYiy6GAwSLvKqYikSWPF9MWpecwsfOg@mail.gmail.com>
References: <CAH-ZgAdYhZkrQJMLynX2w=vBCz+F-ypL2HW9aTj8v9QWSWYhVQ@mail.gmail.com>
 <CA+LucOiDRdrC16q1CRGDB4Bdq=Oc03-VXR3rkfeiAM5nOKgzog@mail.gmail.com>
 <CAF7AXFEuYAcGVocp5GViYiy6GAwSLvKqYikSWPF9MWpecwsfOg@mail.gmail.com>
Message-ID: <CA+LucOjVvXhX94h2aJLJn44uuwCvzJ_HYqoOMKkUh7WjwmORKA@mail.gmail.com>

My codeplex username is "objarni" (same on github) and here is the
CodePlex issue to add ensurepip support:

https://ironpython.codeplex.com/workitem/35198

On 7 May 2014 08:50, Jeff Hardy <jdhardy at gmail.com> wrote:
> On Tue, May 6, 2014 at 2:09 PM, Olof Bjarnason <olof.bjarnason at gmail.com> wrote:
>> PIP built-in sounds like a dream :)
>>
>> Is there anything I can help out on testing this?
>
> First, open an issue: https://ironpython.codeplex.com/WorkItem/Create,
> and send me your CodePlex username so I can add you to the project
> (after 2.7.5 everything will move to GitHub, but I'm using CP for one
> last release, for old times' sake) and you can edit/close issues.
>
> I've wanted to have pip working for quite a while now but just never
> found the time.[1] Honestly though, it should be pretty easy.
> ensurepip I've never looked at, so I don't know, but I can't imagine
> it being too difficult. Upstream on these projects is open to patches
> for IronPython support as well, so there shouldn't be any issues
> there. With ensurepip we could even distribute our own fork if we had
> to.
>
> From what I recall the major issue with pip was making sure that it
> had with: blocks where needed, since parts of it implicitly relied on
> CPython's refcounting GC to close files deterministically. That may
> have been cleaned up over the years.
>
> Because of various things over the next month 2.7.5 probably won't
> land until June, so there should be lots of time to get pip/ensurepip
> ready.
>
> - Jeff
>
> [1] http://wondermark.com/729/
>
>>
>> On 6 May 2014 09:37, Vernon D. Cole <vernondcole at gmail.com> wrote:
>>> The following post appeared in Jython-dev this morning.
>>>
>>> I think that this might be a really good idea for IronPython, too,
>>> especially now that there is a patch for setuptools so that it will not
>>> choke on Iron.
>>>
>>> Should this be included as a work item in our tracker?
>>> --
>>> Vernon Cole
>>> v v v v v v v
>>>
>>> Date: Mon, 5 May 2014 12:24:41 -0600
>>> From: Jim Baker <jim.baker at python.org>
>>> Subject: [Jython-dev] Supporting ensurepip in beta 4
>>> To: Jython Developers <jython-dev at lists.sourceforge.net>
>>> Message-ID:
>>>         <CAL9RhrX8HNzFvRX4YNC6za7mc8tboWJC7+b16w2YEHVwvG8F9w at mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> I just had a nice conversation on #pypa-dev re ensurepip, which is part of
>>> Python 3.4 and will also be bundled in PyPy 2.3, which supports both 2.7
>>> and 3.4 versions of Python. I recommend that Jython 2.7 do the same, given
>>> that like PyPy we are under active development, unlike CPython 2.7.
>>>
>>> We should be able to do this in time for beta 4.
>>>
>>> ensurepip (https://docs.python.org/3/library/ensurepip.html) provides
>>> support for having a bundled version of pip, which is then used to install
>>> the current version of pip in a matter that's transparent to the user.
>>> Jython simply needs to bundle the required pip and setuptools wheels and
>>> the ensurepip package in stdlib.
>>>
>>> This will mean that our users will have pip immediately available to them
>>> upon installing Jython, with no extra steps required. PyPy has done the
>>> hard work to provide a 2.7-compatible version. More rationale here:
>>> http://legacy.python.org/dev/peps/pep-0453/
>>>
>>> This timeline depends on a pull request I made against pip's vendor lib
>>> dependency html5lib-python getting made, but I don't expect us to see any
>>> blockers there.
>>>
>>> - Jim
>>> ^ ^ ^ ^ ^ ^ ^ ^ ^
>>>
>>>
>>> _______________________________________________
>>> 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

From notifications at codeplex.com  Wed May  7 10:40:05 2014
From: notifications at codeplex.com (CodePlex)
Date: 7 May 2014 01:40:05 -0700
Subject: [Ironpython-users] User added as Contributor to your CodePlex
	project, ironpython
Message-ID: <CO1MSDNADMCDS2x4XFK00021a30@discussions.codeplex.com>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140507/1efb55e2/attachment.html>

From no_reply at codeplex.com  Thu May  8 09:24:23 2014
From: no_reply at codeplex.com (CodePlex)
Date: 8 May 2014 00:24:23 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/7/2014
Message-ID: <CO1MSDNADMCDS24A2Dr00023737@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] Implement standard python encodings
2. [New issue] ensurepip support
3. [New issue] Using str() on non-ASCII string throws Exception: Unable to translate bytes from specified code page to Unicode
4. [New issue] %f directive does not work with datetime/time.strptime/strftime
5. [New issue] Specific case causes traceback to be incomplete

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

ISSUES

1. [New comment] Implement standard python encodings
http://ironpython.codeplex.com/workitem/1214
User jdhardy has commented on the issue:

"<p>See IronPython.Modules\binascii.cs and IronPython.Modules\_codecs.cs. Also see https://ironpython.codeplex.com/workitem/15507, and https://ironpython.codeplex.com/workitem/15506, and many others (search for &quot;encoding&quot;).</p>"-----------------

2. [New issue] ensurepip support
http://ironpython.codeplex.com/workitem/35198
User objarni has proposed the issue:

"It would be swell if IronPython, out of the box, could have pip available to it's users. 

"ensurepip (https://docs.python.org/3/library/ensurepip.html) provides
support for having a bundled version of pip, which is then used to install
the current version of pip in a matter that's transparent to the user.
Jython simply needs to bundle the required pip and setuptools wheels and
the ensurepip package in stdlib."
"-----------------

3. [New issue] Using str() on non-ASCII string throws Exception: Unable to translate bytes from specified code page to Unicode
http://ironpython.codeplex.com/workitem/35199
User acl2 has proposed the issue:

"I am hosting IronPython (IronPython.dll 2.7.4.1000; Microsoft.Scripting.dll 1.1.0.21) inside a .NET 4.0 application.

The IronPyhton.Runtime throws a System.Text.DecoderFallbackException whenever I use the built-in Python str() function on a non-ASCII string.

So basically, when I execute the following python code:
s = str("?")

I get a System.Text.DecoderFallbackException "Unable to translate bytes [E4] at index 0 from specified code page to Unicode.".

This is problematic, since I use str() almost everywhere to convert various types (unknown at rutime) to strings.

Here is the complete exception info:
System.Text.DecoderFallbackException was unhandled by user code
  HResult=-2147024809
  Index=0
  Message=Unable to translate bytes [E4] at index 0 from specified code page to Unicode.
  Source=mscorlib
  StackTrace:
       at System.Text.DecoderExceptionFallbackBuffer.Throw(Byte[] bytesUnknown, Int32 index)
       at System.Text.DecoderExceptionFallbackBuffer.Fallback(Byte[] bytesUnknown, Int32 index)
       at IronPython.Runtime.PythonAsciiEncoding.GetCharCount(Byte[] bytes, Int32 index, Int32 count)
       at System.Text.Encoding.GetChars(Byte[] bytes, Int32 index, Int32 count)
       at System.Text.Encoding.GetString(Byte[] bytes, Int32 index, Int32 count)
       at IronPython.Runtime.Operations.StringOps.DoDecode(CodeContext context, String s, String errors, String encoding, Encoding e)
       at IronPython.Runtime.Operations.StringOps.RawDecode(CodeContext context, String s, Object encodingType, String errors)
       at IronPython.Runtime.Operations.StringOps.decode(CodeContext context, String s, Object encoding, String errors)
       at IronPython.Runtime.Operations.StringOps.__new__(CodeContext context, PythonType cls, Object string, String encoding, String errors)
       at IronPython.Runtime.Operations.StringOps.CheckAsciiString(CodeContext context, String s)
       at IronPython.Runtime.Operations.StringOps.__new__(CodeContext context, PythonType cls, String object)
       at Microsoft.Scripting.Interpreter.FuncCallInstruction`4.Run(InterpretedFrame frame)
       at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame)
       at Microsoft.Scripting.Interpreter.LightLambda.Run4[T0,T1,T2,T3,TRet](T0 arg0, T1 arg1, T2 arg2, T3 arg3)
       at System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2)
       at Microsoft.Scripting.Interpreter.DynamicInstruction`4.Run(InterpretedFrame frame)
       at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame)
       at Microsoft.Scripting.Interpreter.LightLambda.Run1[T0,TRet](T0 arg0)
       at IronPython.Compiler.PythonCallTargets.OriginalCallTarget0(PythonFunction function)
       at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0)
       at _Scripting_(Object[] )
       at App.Test.Misc.IronPythonUmlautTest() in C:\Dev\App\Test\Misc.vb:line 79
  InnerException: 


Here is a unit test that reproduces the issue (sorry it's in VB.NET):
    <TestMethod()> _
    Public Sub IronPythonUmlautTest()
        Dim e = IronPython.Hosting.Python.CreateEngine()
        Dim s As Microsoft.Scripting.Hosting.ScriptScope
        Dim code As String
        Dim f As Func(Of Object)

        ' TEST 1: Returning string directly works
        s = e.CreateScope()
        code = "def somefunction():      " & vbCrLf & _
               "    s = ""?""            " & vbCrLf & _
               "    return s             "

        e.CreateScriptSourceFromString(code).Execute(s)
        f = s.GetVariable(Of Func(Of Object))("somefunction")

        ' Ok
        Assert.IsTrue(CStr(f()) = "?")


        ' TEST 2: Returning string set via .NET
        s = e.CreateScope()
        s.SetVariable("astring", "?")
        code = "def somefunction():      " & vbCrLf & _
               "    return astring       "

        e.CreateScriptSourceFromString(code).Execute(s)
        f = s.GetVariable(Of Func(Of Object))("somefunction")

        ' Ok
        Assert.IsTrue(CStr(f()) = "?")


        ' TEST 3: Running string to python str() function
        s = e.CreateScope()
        code = "def somefunction():      " & vbCrLf & _
               "    s = ""?""            " & vbCrLf & _
               "    return str(s)        "

        e.CreateScriptSourceFromString(code).Execute(s)
        f = s.GetVariable(Of Func(Of Object))("somefunction")

        ' The following line throws a System.Text.DecoderFallbackException: 
        ' Unable to translate bytes [E4] at index 0 from specified code page to Unicode.
        Assert.IsTrue(CStr(f()) = "?")


        ' TEST 3: Running string from .NET to python str() function
        s = e.CreateScope()
        s.SetVariable("astring", "?")
        code = "def somefunction():      " & vbCrLf & _
               "    return str(astring)  "

        e.CreateScriptSourceFromString(code).Execute(s)
        f = s.GetVariable(Of Func(Of Object))("somefunction")

        ' The following line throws a System.Text.DecoderFallbackException: 
        ' Unable to translate bytes [E4] at index 0 from specified code page to Unicode.
        Assert.IsTrue(CStr(f()) = "?")
    End Sub


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

4. [New issue] %f directive does not work with datetime/time.strptime/strftime
http://ironpython.codeplex.com/workitem/35202
User pekkaklarck has proposed the issue:

"CPython supports %f directive (microseconds) with time.strptime and datetime.strptime since version 2.6. With IronPython 2.7 you get ValueError with a very confusing message:
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 time, datetime
>>> time.strptime('123', '%f')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: cannot parse %j, %W, or %U w/ other values
>>> datetime.datetime.strptime('123', '%f')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: cannot parse %j, %W, or %U w/ other values
>>> ^Z

Additionally, datetime.strftime doesn't work correctly either:
>>> from datetime import datetime
>>> d = datetime.now()
>>> d.microsecond
377000
>>> d.strftime('%f')
'000000'
"-----------------

5. [New issue] Specific case causes traceback to be incomplete
http://ironpython.codeplex.com/workitem/35204
User kliberty has proposed the issue:

"from traceback import print_exc
def foo():
    return 1[0]
    
try:
    try:
        foo()
    except:
        raise
except:
    print_exc()

ipy64 bug_bad.py
TypeError: 'int' object is unsubscriptable
"
----------------------------------------------



----------------------------------------------
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/20140508/4ff2dd70/attachment.html>

From pawel.jasinski at gmail.com  Thu May  8 14:21:15 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Thu, 8 May 2014 14:21:15 +0200
Subject: [Ironpython-users] tinkering with cp35180 - types.FunctionType(...)
	raise NotImplementedError
Message-ID: <CA+7con=7+Pdkp5cU3SjpFcA7RbGkVJh-PM=SOmmmApDsph4tyg@mail.gmail.com>

What I am trying to accomplish is minimal use case, where function globals
are replaced/faked.
The samples I am using can be examined at:
https://gist.github.com/paweljasinski/1d3a18a885e3040449de
I have replaced the context used by function, but the reference to
global_variable out of fc0 is stuck.

I have made a snapshot of function code as LightLambdaExpression and
reference to global variable is expressed as PythonGlobalVariableExpression
(lightLambda, line 39)
This appears to contain the context which can not be changed.
Would it make sense to use LookupGlobalVariable instead?

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

From pawel.jasinski at gmail.com  Thu May  8 18:18:49 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Thu, 8 May 2014 18:18:49 +0200
Subject: [Ironpython-users] tinkering with cp35180 -
	types.FunctionType(...) raise NotImplementedError
In-Reply-To: <CA+7con=7+Pdkp5cU3SjpFcA7RbGkVJh-PM=SOmmmApDsph4tyg@mail.gmail.com>
References: <CA+7con=7+Pdkp5cU3SjpFcA7RbGkVJh-PM=SOmmmApDsph4tyg@mail.gmail.com>
Message-ID: <CA+7conk8zhaccuthv1d4249CpL6pYwj6UKnWHSRSYNpsNshFOw@mail.gmail.com>

Forget about the LookupGlobalVariable. I think something around RewriteBody
with adjusted scope would be better. Comments?


On Thu, May 8, 2014 at 2:21 PM, Pawel Jasinski <pawel.jasinski at gmail.com>wrote:

> What I am trying to accomplish is minimal use case, where function globals
> are replaced/faked.
> The samples I am using can be examined at:
> https://gist.github.com/paweljasinski/1d3a18a885e3040449de
> I have replaced the context used by function, but the reference to
> global_variable out of fc0 is stuck.
>
> I have made a snapshot of function code as LightLambdaExpression and
> reference to global variable is expressed as PythonGlobalVariableExpression
> (lightLambda, line 39)
> This appears to contain the context which can not be changed.
> Would it make sense to use LookupGlobalVariable instead?
>
> --pawel
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140508/8d3ede68/attachment.html>

From doug.blank at gmail.com  Thu May  8 18:32:22 2014
From: doug.blank at gmail.com (Doug Blank)
Date: Thu, 8 May 2014 12:32:22 -0400
Subject: [Ironpython-users] IronPython SQLite interface
In-Reply-To: <1413646938.20140211172553@mail.mipt.ru>
References: <CAAusYCgLrRFOhnCEmMxXsfXqdirRVjquM6N6F1T4FN=Wk1HHMg@mail.gmail.com>
 <CAPiUgVcyXxn0D21K0iS_Hg4rPU26AZUqz0Jqa400dP0_OFhd1w@mail.gmail.com>
 <CAAusYCi=h9t9aAsg_Dnu8zW7CFkYkd0PW-qP59rCZiYF73TqnQ@mail.gmail.com>
 <CAPiUgVfHcm5E=8JhBMYh-uw=FnDbe0=XzR_XntX7tsgk1eB5aQ@mail.gmail.com>
 <CAAusYCgT66iVMRq_m9-z___WKnk9HCy568ebf8U4bA68HfS+Yg@mail.gmail.com>
 <CAAusYCj9xGJBXUK44PW1WdMo4s5PW5v9H_PdnUvBGKujs2y6nQ@mail.gmail.com>
 <CAAusYCg8zv=MoAMJth27zS0SwWz-coS449jkmJ68jKR0r+mpgw@mail.gmail.com>
 <CAPiUgVc04tQ6hB_0dyjasaE9b86DPhcpEDAYYQQxkDr==uMBMA@mail.gmail.com>
 <CAF7AXFG1bBuS-=kxzzsA8XBx4SfiCfGSJY2iLita2Vc2-W3RQA@mail.gmail.com>
 <CAAusYCgYq6gWqDwaDmnhnJ1osfsvcEHQ8augCbEDebRVOA8pHA@mail.gmail.com>
 <1413646938.20140211172553@mail.mipt.ru>
Message-ID: <CAAusYCi6hmemt9gCZcKQTSgrg95eBo3ShG0B0CDXOvsPgoaJsw@mail.gmail.com>

Just getting back to attempting to use sqlite3 on computers other than
Windows, and it looks like this C# library has other problems on other OSes.

The first issue is that it appears that all activity must happen in the
same thread (connection, cursor, execution). That can mitigated against if
that is the way that it has to be. (A wrapper could be supplied to run
everything in a specific thread).

The next problem is a show stopper:

import sqlite3
conn = sqlite3.connect("test.db")
cur = conn.cursor()
cur.execute("select * from tables;")

This works on Windows, but gives a SystemError: LockFileEx on Linux. I
suspect that the information that Ivan pointed to (below) indicates that
these patches screwed up sqlite port so that it no longer will work on
Linux and Mac.

Anyone have ideas, on either a fix, or using a different library, different
version?

-Doug



On Tue, Feb 11, 2014 at 8:25 AM, Ivan Pozdeev <vano at mail.mipt.ru> wrote:

> > Issue #173 with patch:
>
> > https://github.com/IronLanguages/main/issues/173
>
>
>
> > That works for me! I just removed the removal of the slash. I don't
> > know what that will do for Windows users that had a path that started
> with "/".
>
>
> > We distribute our own DLLs, so no rush for a new release.
>
>
> > Thanks!
>
>
> > -Doug
>
>
> > On Tue, Feb 11, 2014 at 4:39 AM, Jeff Hardy <jdhardy at gmail.com> wrote:
> >
> > On Mon, Feb 10, 2014 at 10:15 PM, Slide <slide.o.mix at gmail.com> wrote:
>   >> That seems a little odd. Perhaps Jeff can shed some light on it, I
> think he
>  >> wrote the SQLite adaptation layer.
> >
> >  I did, but the funny code is part of the C#-sqlite library, which is a
> >  port of the C library to C#. (if you're feeling brave, dig through the
> >  code. It's ... interesting.) It looks like the author just assumed
> >  Windows-ish systems in all cases, and Doug has to go and break
> >  everything by trying to run it on Unix. :(
> >
> The file is indeed os_win_c.cs while the original library
> (http://www.sqlite.org/cgi/src/tree?ci=trunk) has os_unix.c as well.
>
> The relevant change in csharp-sqlite is
>
> http://code.google.com/p/csharp-sqlite/source/detail?r=2fd39fa5400f6492b97617816c4f20a891b2e432&path=/Community.CsharpSqlite/src/os_win_c.cs
> with a rather evasive message "Initial 3.7.7 changes".
>
> It appears to be a bad port of the original sqlite diff 3.7.6.8->3.7.7
>
> http://www.sqlite.org/cgi/src/fdiff?v1=24d72407a9055196&v2=eafcd6b91cf204a7&sbs=1
>
> with related lines in it ultimately coming from changeset
> http://www.sqlite.org/cgi/src/info/fe57a8f621
> that clearly states "Have the xFullpath method in os_win.c discard the
> initial "/" if a filename begins with "/X:", where X is any alphabetic
> character"
> without explaining the cause.
>
> The branch is called `uri' so I guess it's needed to handle URIs
> like file:///C:/what/ya/mah/call/it.sqlite
> (Windows kernel APIs treat (and always treated) '/' and '\' the same
> (
> http://bytes.com/topic/python/answers/23123-when-did-windows-start-accepting-forward-slash-path-separator)).
>
>
>
> So, the code was clearly intended for Windows only but ultimately,
> it's csharp-sqlite's /bydlocode/ that broke things down in this
> particular case.
>
>
> >  I have no idea what that code is trying to do (context:
> >
> >
> https://github.com/IronLanguages/main/blob/master/Languages/IronPython/IronPython.SQLite/c%23sqlite/os_win_c.cs#L2646
> );
> >   it might be some vestigial part of SQLite that's not needed. Since //
> >  seems OK I'm assuming that's the case.
> >
> >  Doug, can you open an issue? And in the meantime, is using // an
> >  acceptable workaround?
> >
> >  - Jeff
> >
>
>  >>
>  >>
>  >> On Mon, Feb 10, 2014 at 3:14 PM, Doug Blank <doug.blank at gmail.com>
> wrote:
>  >>>
>  >>> That must be the issue, as "//home/dblank/name.db" works:
>  >>>
>  >>> $ ipy.exe
>  >>> IronPython 2.9.9a0 DEBUG (2.9.0.0) on Mono 4.0.30319.1 (64-bit)
>  >>> Type "help", "copyright", "credits" or "license" for more information.
>  >>> >>> import sqlite3
>  >>> >>> sqlite3.connect("//home/dblank/test.db")
>  >>> <Connection object at 0x000000000000002B>
>  >>> >>>
>  >>>
>  >>> -Doug
>  >>>
>  >>>
>  >>>
>  >>> On Mon, Feb 10, 2014 at 5:12 PM, Doug Blank <doug.blank at gmail.com>
> wrote:
>  >>>>
>  >>>> After more testing, it appears that it only fails when the path
> begins
>  >>>> with a slash "/".
>  >>>>
>  >>>> I see:
>  >>>>
>  >>>> ./c#sqlite/os_win_c.cs:      if ( zConverted.StartsWith( "/" ) &&
>  >>>> !zConverted.StartsWith( "//"
>  >>>>
>  >>>> I'll try a couple of more things...
>  >>>>
>  >>>> -Doug
>  >>>>
>  >>>>
>  >>>> On Mon, Feb 10, 2014 at 9:19 AM, Doug Blank <doug.blank at gmail.com>
> wrote:
>  >>>>>
>  >>>>>
>  >>>>> On Mon, Feb 10, 2014 at 8:47 AM, Slide <slide.o.mix at gmail.com>
> wrote:
>  >>>>>>
>  >>>>>> All the connect call does is this:
>  >>>>>>
>  >>>>>> int rc = Sqlite3.sqlite3_open(database, out this.db);
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>> if(rc != Sqlite3.SQLITE_OK)
>  >>>>>>     throw GetSqliteError(this.db, null);
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>> Which makes me thing that sqlite3_open is returning an error code.
> What
>  >>>>>> happens if you do the same in CPython?
>  >>>>>
>  >>>>>
>  >>>>> No error, creates a file of length 0, and works:
>  >>>>>
>  >>>>> $ python
>  >>>>> Python 2.7.5+ (default, Sep 19 2013, 13:48:49)
>  >>>>> [GCC 4.8.1] on linux2
>  >>>>> Type "help", "copyright", "credits" or "license" for more
> information.
>  >>>>> >>> import sqlite3
>  >>>>> >>> sqlite3.connect("/home/dblank/test.db")
>  >>>>> <sqlite3.Connection object at 0x7fc3c21b6118>
>  >>>>> >>>
>  >>>>>
>  >>>>> $ ls -al /home/dblank/test.db
>  >>>>> -rw-r--r-- 1 dblank dblank 0 Feb 10 09:15 /home/dblank/test.db
>  >>>>>
>  >>>>> -Doug
>  >>>>>
>  >>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>> On Fri, Feb 7, 2014 at 6:01 AM, Doug Blank <doug.blank at gmail.com>
>  >>>>>> wrote:
>  >>>>>>>
>  >>>>>>>
>  >>>>>>> On Fri, Feb 7, 2014 at 7:47 AM, Slide <slide.o.mix at gmail.com>
> wrote:
>  >>>>>>>>
>  >>>>>>>> Do you get a specific error message?
>  >>>>>>>
>  >>>>>>>
>  >>>>>>> Sorry, yes:
>  >>>>>>>
>  >>>>>>> Traceback (most recent call last):
>  >>>>>>>   File "<string>", line 1, in <module>
>  >>>>>>> _sqlite3.OperationalError: unable to open database file
>  >>>>>>>
>  >>>>>>> Does this work for you? I get this error running latest ipy.exe
> (Mono
>  >>>>>>> 2.10, Ubuntu 13.10) and IronPython in Calico.
>  >>>>>>>
>  >>>>>>> -Doug
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>> On Fri, Feb 7, 2014 at 5:37 AM, Doug Blank <doug.blank at gmail.com
> >
>  >>>>>>>> wrote:
>  >>>>>>>>>
>  >>>>>>>>> Just recently discovered the sqlite3 port for IronPython, but
> having
>  >>>>>>>>> some basic trouble:
>  >>>>>>>>>
>  >>>>>>>>> This works fine:
>  >>>>>>>>>
>  >>>>>>>>> import sqlite3
>  >>>>>>>>> sqlite3.connect("test.db")
>  >>>>>>>>>
>  >>>>>>>>> but this doesn't:
>  >>>>>>>>>
>  >>>>>>>>> import sqlite3
>  >>>>>>>>> sqlite3.connect("/home/dblank/test.db")
>  >>>>>>>>>
>  >>>>>>>>> Any ideas?
>  >>>>>>>>>
>  >>>>>>>>> -Doug
>  >>>>>>>>>
>  >>>>>>>>>
>  >>>>>>>>> _______________________________________________
>  >>>>>>>>> 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
>  >>>>>>
>  >>>>>> _______________________________________________
>  >>>>>> Ironpython-users mailing list
>  >>>>>> Ironpython-users at python.org
>  >>>>>> https://mail.python.org/mailman/listinfo/ironpython-users
>  >>>>>>
>  >>>>>
>  >>>>
>  >>>
>  >>
>  >>
>  >>
>  >> --
>  >> Website: http://earl-of-code.com
>  >>
>  >> _______________________________________________
>  >> Ironpython-users mailing list
>  >> Ironpython-users at python.org
>  >> https://mail.python.org/mailman/listinfo/ironpython-users
>  >>
> >
>
>
>
>
> --
> Best regards,
>  Ivan                            mailto:vano at mail.mipt.ru
>
> _______________________________________________
> 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/20140508/f77adaf8/attachment.html>

From no_reply at codeplex.com  Fri May  9 09:23:46 2014
From: no_reply at codeplex.com (CodePlex)
Date: 9 May 2014 00:23:46 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/8/2014
Message-ID: <CO1MSDNADMCDS2rcR4Z00025959@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [Status update] Code coverage for Ironpython scripts
2. [New comment] Using str() on non-ASCII string throws Exception: Unable to translate bytes from specified code page to Unicode
3. [New comment] %f directive does not work with datetime/time.strptime/strftime
4. [Status update] %f directive does not work with datetime/time.strptime/strftime
5. [New comment] Specific case causes traceback to be incomplete

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

ISSUES

1. [Status update] Code coverage for Ironpython scripts
http://ironpython.codeplex.com/workitem/35194
User slide_o_mix has updated the issue:
Status has changed from Proposed to Closed with the following comment, 

"Please use the mailing to ask questions."-----------------

2. [New comment] Using str() on non-ASCII string throws Exception: Unable to translate bytes from specified code page to Unicode
http://ironpython.codeplex.com/workitem/35199
User jdhardy has commented on the issue:

"<p>I'm pretty sure there's another issue with the same problem but I can't find it right now.</p>"-----------------

3. [New comment] %f directive does not work with datetime/time.strptime/strftime
http://ironpython.codeplex.com/workitem/35202
User paweljasinski has commented on the issue:

"<p>duplicate: https://ironpython.codeplex.com/workitem/34706</p>"-----------------

4. [Status update] %f directive does not work with datetime/time.strptime/strftime
http://ironpython.codeplex.com/workitem/35202
User paweljasinski has updated the issue:
Status has changed from Active to Closed.

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

5. [New comment] Specific case causes traceback to be incomplete
http://ironpython.codeplex.com/workitem/35204
User paweljasinski has commented on the issue:

"<p>similar: https://ironpython.codeplex.com/workitem/34849</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/20140509/defd3e79/attachment.html>

From anand.kr.p at gmail.com  Fri May  9 06:09:52 2014
From: anand.kr.p at gmail.com (Anand Kumar)
Date: Fri, 9 May 2014 09:39:52 +0530
Subject: [Ironpython-users] Code coverage for Ironpython scripts
Message-ID: <CAOnSPFaf71J1jUS9uAu2FTxFom_T4fhw3HSf62r6KaLU-e=d=w@mail.gmail.com>

Hi,
Is there any code coverage tool identified for Iron python? If so please
let me know the tool. If not, please let me know when it will be available.

Thanks and Regards,
Anandkumar.P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140509/e96f02fe/attachment.html>

From jdhardy at gmail.com  Fri May  9 10:42:52 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 9 May 2014 09:42:52 +0100
Subject: [Ironpython-users] IronPython SQLite interface
In-Reply-To: <CAAusYCi6hmemt9gCZcKQTSgrg95eBo3ShG0B0CDXOvsPgoaJsw@mail.gmail.com>
References: <CAAusYCgLrRFOhnCEmMxXsfXqdirRVjquM6N6F1T4FN=Wk1HHMg@mail.gmail.com>
 <CAPiUgVcyXxn0D21K0iS_Hg4rPU26AZUqz0Jqa400dP0_OFhd1w@mail.gmail.com>
 <CAAusYCi=h9t9aAsg_Dnu8zW7CFkYkd0PW-qP59rCZiYF73TqnQ@mail.gmail.com>
 <CAPiUgVfHcm5E=8JhBMYh-uw=FnDbe0=XzR_XntX7tsgk1eB5aQ@mail.gmail.com>
 <CAAusYCgT66iVMRq_m9-z___WKnk9HCy568ebf8U4bA68HfS+Yg@mail.gmail.com>
 <CAAusYCj9xGJBXUK44PW1WdMo4s5PW5v9H_PdnUvBGKujs2y6nQ@mail.gmail.com>
 <CAAusYCg8zv=MoAMJth27zS0SwWz-coS449jkmJ68jKR0r+mpgw@mail.gmail.com>
 <CAPiUgVc04tQ6hB_0dyjasaE9b86DPhcpEDAYYQQxkDr==uMBMA@mail.gmail.com>
 <CAF7AXFG1bBuS-=kxzzsA8XBx4SfiCfGSJY2iLita2Vc2-W3RQA@mail.gmail.com>
 <CAAusYCgYq6gWqDwaDmnhnJ1osfsvcEHQ8augCbEDebRVOA8pHA@mail.gmail.com>
 <1413646938.20140211172553@mail.mipt.ru>
 <CAAusYCi6hmemt9gCZcKQTSgrg95eBo3ShG0B0CDXOvsPgoaJsw@mail.gmail.com>
Message-ID: <CAF7AXFH7hC4n1P2H1VBxGCRy9ZnEvoEh8AS7RBzQytkCWAAkWw@mail.gmail.com>

On Thu, May 8, 2014 at 5:32 PM, Doug Blank <doug.blank at gmail.com> wrote:
> Just getting back to attempting to use sqlite3 on computers other than
> Windows, and it looks like this C# library has other problems on other OSes.
>
> The first issue is that it appears that all activity must happen in the same
> thread (connection, cursor, execution). That can mitigated against if that
> is the way that it has to be. (A wrapper could be supplied to run everything
> in a specific thread).
>
> The next problem is a show stopper:
>
> import sqlite3
> conn = sqlite3.connect("test.db")
> cur = conn.cursor()
> cur.execute("select * from tables;")
>
> This works on Windows, but gives a SystemError: LockFileEx on Linux. I
> suspect that the information that Ivan pointed to (below) indicates that
> these patches screwed up sqlite port so that it no longer will work on Linux
> and Mac.
>
> Anyone have ideas, on either a fix, or using a different library, different
> version?

Right now, I don't know if there's much that can be done. The C#
SQLite port it uses is pretty Windows-specific, and I doubt it's worth
the effort to fix it since it's no longer maintained anyway. I've been
pondering replacing the guts of the SQLite module with
https://github.com/ericsink/SQLitePCL.raw, which wraps the *actual*
SQLite library instead of the C# port.

The module implementation shouldn't have to change that much, since
most of the function names should be the same. I don't yet know if
SQLitePCL works on Unix/Mac but it does support Android and iOS so
it's probably going to be a lot easier to fix it than it would be for
C#-SQLite.

I hadn't planned on this until IronPython 3, but I'd be very happy to
include it in 2.7.5 (or a possible 2.7.6) if someone else does the
work.

- Jeff

From jdhardy at gmail.com  Fri May  9 10:46:41 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 9 May 2014 09:46:41 +0100
Subject: [Ironpython-users] Code coverage for Ironpython scripts
In-Reply-To: <CAOnSPFaf71J1jUS9uAu2FTxFom_T4fhw3HSf62r6KaLU-e=d=w@mail.gmail.com>
References: <CAOnSPFaf71J1jUS9uAu2FTxFom_T4fhw3HSf62r6KaLU-e=d=w@mail.gmail.com>
Message-ID: <CAF7AXFGgAyNEMwAmnHp0tKcxCvtBsRtyjnsp2t2dbYBM4Atq6w@mail.gmail.com>

On Fri, May 9, 2014 at 5:09 AM, Anand Kumar <anand.kr.p at gmail.com> wrote:
> Hi,
> Is there any code coverage tool identified for Iron python? If so please let
> me know the tool. If not, please let me know when it will be available.

I don't know of any that explicitly support it. I'm not sure what
would be needed to make coverage.py work if it doesn't; I'm not sure
if it's even been tried.

- Jeff

From anand.kr.p at gmail.com  Fri May  9 10:53:03 2014
From: anand.kr.p at gmail.com (Anand Kumar)
Date: Fri, 9 May 2014 14:23:03 +0530
Subject: [Ironpython-users] Code coverage for Ironpython scripts
In-Reply-To: <CAF7AXFGgAyNEMwAmnHp0tKcxCvtBsRtyjnsp2t2dbYBM4Atq6w@mail.gmail.com>
References: <CAOnSPFaf71J1jUS9uAu2FTxFom_T4fhw3HSf62r6KaLU-e=d=w@mail.gmail.com>
 <CAF7AXFGgAyNEMwAmnHp0tKcxCvtBsRtyjnsp2t2dbYBM4Atq6w@mail.gmail.com>
Message-ID: <CAOnSPFYQYZQOZUrGq2ZGZx++XiHLDszcBWEwOBYxHojTBPGmNg@mail.gmail.com>

I am using PTVS along with Visual studio2010 to try coverage.py. I
attached the py files used to try. i got the below exception when i
run mathunittest.py file from VS2010.
Please let me know what should i do to make it work.
<string>:1: DeprecationWarning: object.__new__() takes no parameters
Traceback (most recent call last):
  File "<string>", line 4, in <module>
  File "C:\Program Files (x86)\IronPython
2.7\lib\site-packages\coverage\control.py", line 403, in start
    self.collector.start()
  File "C:\Program Files (x86)\IronPython
2.7\lib\site-packages\coverage\collector.py", line 288, in start
    threading.settrace(self._installation_trace)
  File "C:\Program Files (x86)\IronPython
2.7\lib\site-packages\coverage\collector.py", line 83, in _trace
    tracename = self.should_trace(filename, frame)
  File "C:\Program Files (x86)\IronPython
2.7\lib\site-packages\coverage\control.py", line 296, in _should_trace
    canonical, reason = self._should_trace_with_reason(filename, frame)
  File "C:\Program Files (x86)\IronPython
2.7\lib\site-packages\coverage\control.py", line 253, in
_should_trace_with_reason
    dunder_file = frame.f_globals.get('__file__')
AttributeError: 'NoneType' object has no attribute 'get'



On Fri, May 9, 2014 at 2:16 PM, Jeff Hardy <jdhardy at gmail.com> wrote:

> On Fri, May 9, 2014 at 5:09 AM, Anand Kumar <anand.kr.p at gmail.com> wrote:
> > Hi,
> > Is there any code coverage tool identified for Iron python? If so please
> let
> > me know the tool. If not, please let me know when it will be available.
>
> I don't know of any that explicitly support it. I'm not sure what
> would be needed to make coverage.py work if it doesn't; I'm not sure
> if it's even been tried.
>
> - Jeff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140509/6468a048/attachment.html>
-------------- next part --------------
#import clr
#from System import Math

def CompareMax(a,b):
    normalResult = None
    if(a==b):
        normalResult = 0
    elif (a<b):
        normalResult = b
    else:
        normalResult = a
    return True
    #mathResult = Math.Max(a,b)
    #if(normalResult == mathResult):
    #    return True
    #else:
    #    return False
-------------- next part --------------
import coverage

cov = coverage.coverage()
cov.start()
print "start"
import unittest
from CoverageToolEvaluation import *

class TestMath(unittest.TestCase):
    """description of class"""
    
    def testAequalsB(self):        
        val = CompareMax(5,5)
        self.assertTrue(val,"Math value is not equal")

print "before calling main"
print __name__
if __name__ == "__main__":
    print "main"
    unittest.main()  
print __file__

suite = unittest.TestLoader().loadTestsFromTestCase(TestMath)
unittest.TextTestRunner(verbosity=2).run(suite)  
cov.stop()
cov.save()
cov.html_report(directory='covhtml')
print "end" 

From jdhardy at gmail.com  Fri May  9 11:20:19 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 9 May 2014 10:20:19 +0100
Subject: [Ironpython-users] Code coverage for Ironpython scripts
In-Reply-To: <CAOnSPFYQYZQOZUrGq2ZGZx++XiHLDszcBWEwOBYxHojTBPGmNg@mail.gmail.com>
References: <CAOnSPFaf71J1jUS9uAu2FTxFom_T4fhw3HSf62r6KaLU-e=d=w@mail.gmail.com>
 <CAF7AXFGgAyNEMwAmnHp0tKcxCvtBsRtyjnsp2t2dbYBM4Atq6w@mail.gmail.com>
 <CAOnSPFYQYZQOZUrGq2ZGZx++XiHLDszcBWEwOBYxHojTBPGmNg@mail.gmail.com>
Message-ID: <CAF7AXFFhYxXQPf5qEPcv=dXmPSLS6gxUU8-U-OFrG3Fb=wLNrg@mail.gmail.com>

I'm not sure how to do it from PTVS, but you'll need to add
-X:FullFrames to the ipy.exe command line and try it again.

- Jeff

On Fri, May 9, 2014 at 9:53 AM, Anand Kumar <anand.kr.p at gmail.com> wrote:
> I am using PTVS along with Visual studio2010 to try coverage.py. I attached
> the py files used to try. i got the below exception when i run
> mathunittest.py file from VS2010.
>
> Please let me know what should i do to make it work.
> <string>:1: DeprecationWarning: object.__new__() takes no parameters
> Traceback (most recent call last):
>   File "<string>", line 4, in <module>
>   File "C:\Program Files (x86)\IronPython
> 2.7\lib\site-packages\coverage\control.py", line 403, in start
>     self.collector.start()
>   File "C:\Program Files (x86)\IronPython
> 2.7\lib\site-packages\coverage\collector.py", line 288, in start
>     threading.settrace(self._installation_trace)
>   File "C:\Program Files (x86)\IronPython
> 2.7\lib\site-packages\coverage\collector.py", line 83, in _trace
>     tracename = self.should_trace(filename, frame)
>   File "C:\Program Files (x86)\IronPython
> 2.7\lib\site-packages\coverage\control.py", line 296, in _should_trace
>     canonical, reason = self._should_trace_with_reason(filename, frame)
>   File "C:\Program Files (x86)\IronPython
> 2.7\lib\site-packages\coverage\control.py", line 253, in
> _should_trace_with_reason
>     dunder_file = frame.f_globals.get('__file__')
> AttributeError: 'NoneType' object has no attribute 'get'
>
>
>
> On Fri, May 9, 2014 at 2:16 PM, Jeff Hardy <jdhardy at gmail.com> wrote:
>>
>> On Fri, May 9, 2014 at 5:09 AM, Anand Kumar <anand.kr.p at gmail.com> wrote:
>> > Hi,
>> > Is there any code coverage tool identified for Iron python? If so please
>> > let
>> > me know the tool. If not, please let me know when it will be available.
>>
>> I don't know of any that explicitly support it. I'm not sure what
>> would be needed to make coverage.py work if it doesn't; I'm not sure
>> if it's even been tried.
>>
>> - Jeff
>
>

From anand.kr.p at gmail.com  Fri May  9 11:48:44 2014
From: anand.kr.p at gmail.com (Anand Kumar)
Date: Fri, 9 May 2014 15:18:44 +0530
Subject: [Ironpython-users] Code coverage for Ironpython scripts
In-Reply-To: <CAF7AXFFhYxXQPf5qEPcv=dXmPSLS6gxUU8-U-OFrG3Fb=wLNrg@mail.gmail.com>
References: <CAOnSPFaf71J1jUS9uAu2FTxFom_T4fhw3HSf62r6KaLU-e=d=w@mail.gmail.com>
 <CAF7AXFGgAyNEMwAmnHp0tKcxCvtBsRtyjnsp2t2dbYBM4Atq6w@mail.gmail.com>
 <CAOnSPFYQYZQOZUrGq2ZGZx++XiHLDszcBWEwOBYxHojTBPGmNg@mail.gmail.com>
 <CAF7AXFFhYxXQPf5qEPcv=dXmPSLS6gxUU8-U-OFrG3Fb=wLNrg@mail.gmail.com>
Message-ID: <CAOnSPFZMWTy_oUcT928j3YKKZLYmA17V+fO9X7k2=Wfggk4GNQ@mail.gmail.com>

Jeff,
Thanks for quick responses.

I tried that. i am still getting the below exception

C:\Program Files (x86)\IronPython 2.7>ipy.exe -X:FullFrames MathUnitTest.py
C:\Program Files (x86)\IronPython
2.7\lib\site-packages\coverage\__init__.py:1:
DeprecationWarning: object.__new__() takes no parameters
  """Code coverage measurement for Python.
Traceback (most recent call last):
  File "MathUnitTest.py", line 4, in <module>
  File "C:\Program Files (x86)\IronPython
2.7\lib\site-packages\coverage\control
.py", line 403, in start
  File "C:\Program Files (x86)\IronPython
2.7\lib\site-packages\coverage\collect
or.py", line 288, in start
  File "C:\Program Files (x86)\IronPython
2.7\lib\site-packages\coverage\collect
or.py", line 83, in _trace
  File "C:\Program Files (x86)\IronPython
2.7\lib\site-packages\coverage\control
.py", line 296, in _should_trace
  File "C:\Program Files (x86)\IronPython
2.7\lib\site-packages\coverage\control
.py", line 253, in _should_trace_with_reason
AttributeError: 'NoneType' object has no attribute 'get'
C:\Program Files (x86)\IronPython 2.7>



On Fri, May 9, 2014 at 2:50 PM, Jeff Hardy <jdhardy at gmail.com> wrote:

> I'm not sure how to do it from PTVS, but you'll need to add
> -X:FullFrames to the ipy.exe command line and try it again.
>
> - Jeff
>
> On Fri, May 9, 2014 at 9:53 AM, Anand Kumar <anand.kr.p at gmail.com> wrote:
> > I am using PTVS along with Visual studio2010 to try coverage.py. I
> attached
> > the py files used to try. i got the below exception when i run
> > mathunittest.py file from VS2010.
> >
> > Please let me know what should i do to make it work.
> > <string>:1: DeprecationWarning: object.__new__() takes no parameters
> > Traceback (most recent call last):
> >   File "<string>", line 4, in <module>
> >   File "C:\Program Files (x86)\IronPython
> > 2.7\lib\site-packages\coverage\control.py", line 403, in start
> >     self.collector.start()
> >   File "C:\Program Files (x86)\IronPython
> > 2.7\lib\site-packages\coverage\collector.py", line 288, in start
> >     threading.settrace(self._installation_trace)
> >   File "C:\Program Files (x86)\IronPython
> > 2.7\lib\site-packages\coverage\collector.py", line 83, in _trace
> >     tracename = self.should_trace(filename, frame)
> >   File "C:\Program Files (x86)\IronPython
> > 2.7\lib\site-packages\coverage\control.py", line 296, in _should_trace
> >     canonical, reason = self._should_trace_with_reason(filename, frame)
> >   File "C:\Program Files (x86)\IronPython
> > 2.7\lib\site-packages\coverage\control.py", line 253, in
> > _should_trace_with_reason
> >     dunder_file = frame.f_globals.get('__file__')
> > AttributeError: 'NoneType' object has no attribute 'get'
> >
> >
> >
> > On Fri, May 9, 2014 at 2:16 PM, Jeff Hardy <jdhardy at gmail.com> wrote:
> >>
> >> On Fri, May 9, 2014 at 5:09 AM, Anand Kumar <anand.kr.p at gmail.com>
> wrote:
> >> > Hi,
> >> > Is there any code coverage tool identified for Iron python? If so
> please
> >> > let
> >> > me know the tool. If not, please let me know when it will be
> available.
> >>
> >> I don't know of any that explicitly support it. I'm not sure what
> >> would be needed to make coverage.py work if it doesn't; I'm not sure
> >> if it's even been tried.
> >>
> >> - Jeff
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140509/d95477dd/attachment.html>

From doug.blank at gmail.com  Fri May  9 13:01:40 2014
From: doug.blank at gmail.com (Doug Blank)
Date: Fri, 9 May 2014 07:01:40 -0400
Subject: [Ironpython-users] IronPython SQLite interface
In-Reply-To: <CAF7AXFH7hC4n1P2H1VBxGCRy9ZnEvoEh8AS7RBzQytkCWAAkWw@mail.gmail.com>
References: <CAAusYCgLrRFOhnCEmMxXsfXqdirRVjquM6N6F1T4FN=Wk1HHMg@mail.gmail.com>
 <CAPiUgVcyXxn0D21K0iS_Hg4rPU26AZUqz0Jqa400dP0_OFhd1w@mail.gmail.com>
 <CAAusYCi=h9t9aAsg_Dnu8zW7CFkYkd0PW-qP59rCZiYF73TqnQ@mail.gmail.com>
 <CAPiUgVfHcm5E=8JhBMYh-uw=FnDbe0=XzR_XntX7tsgk1eB5aQ@mail.gmail.com>
 <CAAusYCgT66iVMRq_m9-z___WKnk9HCy568ebf8U4bA68HfS+Yg@mail.gmail.com>
 <CAAusYCj9xGJBXUK44PW1WdMo4s5PW5v9H_PdnUvBGKujs2y6nQ@mail.gmail.com>
 <CAAusYCg8zv=MoAMJth27zS0SwWz-coS449jkmJ68jKR0r+mpgw@mail.gmail.com>
 <CAPiUgVc04tQ6hB_0dyjasaE9b86DPhcpEDAYYQQxkDr==uMBMA@mail.gmail.com>
 <CAF7AXFG1bBuS-=kxzzsA8XBx4SfiCfGSJY2iLita2Vc2-W3RQA@mail.gmail.com>
 <CAAusYCgYq6gWqDwaDmnhnJ1osfsvcEHQ8augCbEDebRVOA8pHA@mail.gmail.com>
 <1413646938.20140211172553@mail.mipt.ru>
 <CAAusYCi6hmemt9gCZcKQTSgrg95eBo3ShG0B0CDXOvsPgoaJsw@mail.gmail.com>
 <CAF7AXFH7hC4n1P2H1VBxGCRy9ZnEvoEh8AS7RBzQytkCWAAkWw@mail.gmail.com>
Message-ID: <CAAusYCgO7D2zgoijCky+s_Q9_uksKd4bCbj1GbOrSctfTpgTUQ@mail.gmail.com>

On Fri, May 9, 2014 at 4:42 AM, Jeff Hardy <jdhardy at gmail.com> wrote:

> On Thu, May 8, 2014 at 5:32 PM, Doug Blank <doug.blank at gmail.com> wrote:
> > Just getting back to attempting to use sqlite3 on computers other than
> > Windows, and it looks like this C# library has other problems on other
> OSes.
> >
> > The first issue is that it appears that all activity must happen in the
> same
> > thread (connection, cursor, execution). That can mitigated against if
> that
> > is the way that it has to be. (A wrapper could be supplied to run
> everything
> > in a specific thread).
> >
> > The next problem is a show stopper:
> >
> > import sqlite3
> > conn = sqlite3.connect("test.db")
> > cur = conn.cursor()
> > cur.execute("select * from tables;")
> >
> > This works on Windows, but gives a SystemError: LockFileEx on Linux. I
> > suspect that the information that Ivan pointed to (below) indicates that
> > these patches screwed up sqlite port so that it no longer will work on
> Linux
> > and Mac.
> >
> > Anyone have ideas, on either a fix, or using a different library,
> different
> > version?
>
> Right now, I don't know if there's much that can be done. The C#
> SQLite port it uses is pretty Windows-specific, and I doubt it's worth
> the effort to fix it since it's no longer maintained anyway. I've been
> pondering replacing the guts of the SQLite module with
> https://github.com/ericsink/SQLitePCL.raw, which wraps the *actual*
> SQLite library instead of the C# port.
>
> The module implementation shouldn't have to change that much, since
> most of the function names should be the same. I don't yet know if
> SQLitePCL works on Unix/Mac but it does support Android and iOS so
> it's probably going to be a lot easier to fix it than it would be for
> C#-SQLite.
>
> I hadn't planned on this until IronPython 3, but I'd be very happy to
> include it in 2.7.5 (or a possible 2.7.6) if someone else does the
> work.
>

Thanks for the information!

As I am also interested in other .NET/Mono languages (and other DB
connections), I wonder if we are going to spend any time on this, if it
wouldn't be better to use (and perhaps refine, if needed) the
ADO.NETSqlite interface:

http://www.mono-project.com/SQLite

Perhaps it is better to move away from the sqlite-specific API and towards
a standard that would allow people to move between db backends? I suspect
Vern may have some information on this point, considering his recent
announcement here on adodbapi version 2.6.

-Doug


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

From jdhardy at gmail.com  Fri May  9 14:59:27 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 9 May 2014 13:59:27 +0100
Subject: [Ironpython-users] IronPython SQLite interface
In-Reply-To: <CAAusYCgO7D2zgoijCky+s_Q9_uksKd4bCbj1GbOrSctfTpgTUQ@mail.gmail.com>
References: <CAAusYCgLrRFOhnCEmMxXsfXqdirRVjquM6N6F1T4FN=Wk1HHMg@mail.gmail.com>
 <CAPiUgVcyXxn0D21K0iS_Hg4rPU26AZUqz0Jqa400dP0_OFhd1w@mail.gmail.com>
 <CAAusYCi=h9t9aAsg_Dnu8zW7CFkYkd0PW-qP59rCZiYF73TqnQ@mail.gmail.com>
 <CAPiUgVfHcm5E=8JhBMYh-uw=FnDbe0=XzR_XntX7tsgk1eB5aQ@mail.gmail.com>
 <CAAusYCgT66iVMRq_m9-z___WKnk9HCy568ebf8U4bA68HfS+Yg@mail.gmail.com>
 <CAAusYCj9xGJBXUK44PW1WdMo4s5PW5v9H_PdnUvBGKujs2y6nQ@mail.gmail.com>
 <CAAusYCg8zv=MoAMJth27zS0SwWz-coS449jkmJ68jKR0r+mpgw@mail.gmail.com>
 <CAPiUgVc04tQ6hB_0dyjasaE9b86DPhcpEDAYYQQxkDr==uMBMA@mail.gmail.com>
 <CAF7AXFG1bBuS-=kxzzsA8XBx4SfiCfGSJY2iLita2Vc2-W3RQA@mail.gmail.com>
 <CAAusYCgYq6gWqDwaDmnhnJ1osfsvcEHQ8augCbEDebRVOA8pHA@mail.gmail.com>
 <1413646938.20140211172553@mail.mipt.ru>
 <CAAusYCi6hmemt9gCZcKQTSgrg95eBo3ShG0B0CDXOvsPgoaJsw@mail.gmail.com>
 <CAF7AXFH7hC4n1P2H1VBxGCRy9ZnEvoEh8AS7RBzQytkCWAAkWw@mail.gmail.com>
 <CAAusYCgO7D2zgoijCky+s_Q9_uksKd4bCbj1GbOrSctfTpgTUQ@mail.gmail.com>
Message-ID: <CAF7AXFHhusQUEO51eT8fA=ahNdvetg8-gkoVLNXCK-+KMWe4Ww@mail.gmail.com>

On Fri, May 9, 2014 at 12:01 PM, Doug Blank <doug.blank at gmail.com> wrote:
> On Fri, May 9, 2014 at 4:42 AM, Jeff Hardy <jdhardy at gmail.com> wrote:
>>
>> On Thu, May 8, 2014 at 5:32 PM, Doug Blank <doug.blank at gmail.com> wrote:
>> > Just getting back to attempting to use sqlite3 on computers other than
>> > Windows, and it looks like this C# library has other problems on other
>> > OSes.
>> >
>> > The first issue is that it appears that all activity must happen in the
>> > same
>> > thread (connection, cursor, execution). That can mitigated against if
>> > that
>> > is the way that it has to be. (A wrapper could be supplied to run
>> > everything
>> > in a specific thread).
>> >
>> > The next problem is a show stopper:
>> >
>> > import sqlite3
>> > conn = sqlite3.connect("test.db")
>> > cur = conn.cursor()
>> > cur.execute("select * from tables;")
>> >
>> > This works on Windows, but gives a SystemError: LockFileEx on Linux. I
>> > suspect that the information that Ivan pointed to (below) indicates that
>> > these patches screwed up sqlite port so that it no longer will work on
>> > Linux
>> > and Mac.
>> >
>> > Anyone have ideas, on either a fix, or using a different library,
>> > different
>> > version?
>>
>> Right now, I don't know if there's much that can be done. The C#
>> SQLite port it uses is pretty Windows-specific, and I doubt it's worth
>> the effort to fix it since it's no longer maintained anyway. I've been
>> pondering replacing the guts of the SQLite module with
>> https://github.com/ericsink/SQLitePCL.raw, which wraps the *actual*
>> SQLite library instead of the C# port.
>>
>> The module implementation shouldn't have to change that much, since
>> most of the function names should be the same. I don't yet know if
>> SQLitePCL works on Unix/Mac but it does support Android and iOS so
>> it's probably going to be a lot easier to fix it than it would be for
>> C#-SQLite.
>>
>> I hadn't planned on this until IronPython 3, but I'd be very happy to
>> include it in 2.7.5 (or a possible 2.7.6) if someone else does the
>> work.
>
>
> Thanks for the information!
>
> As I am also interested in other .NET/Mono languages (and other DB
> connections), I wonder if we are going to spend any time on this, if it
> wouldn't be better to use (and perhaps refine, if needed) the ADO.NET Sqlite
> interface:
>
> http://www.mono-project.com/SQLite
>
> Perhaps it is better to move away from the sqlite-specific API and towards a
> standard that would allow people to move between db backends? I suspect Vern
> may have some information on this point, considering his recent announcement
> here on adodbapi version 2.6.

I actually tried to use that, originally, but Python's sqlite module
exposes some low-level features of SQLite that can't be emulated with
an ADO-type interface. The only way to implementing it faithfully is
to have direct(ish) access to the SQLite library.

Most real apps will use a higher-level wrapper, but IronPython still
needs to provide the sqlite module, since most of the high-level
wrappers will expect it to be there.

- Jeff

From slide.o.mix at gmail.com  Fri May  9 15:41:13 2014
From: slide.o.mix at gmail.com (Slide)
Date: Fri, 9 May 2014 06:41:13 -0700
Subject: [Ironpython-users] IronPython SQLite interface
In-Reply-To: <CAF7AXFHhusQUEO51eT8fA=ahNdvetg8-gkoVLNXCK-+KMWe4Ww@mail.gmail.com>
References: <CAAusYCgLrRFOhnCEmMxXsfXqdirRVjquM6N6F1T4FN=Wk1HHMg@mail.gmail.com>
 <CAPiUgVcyXxn0D21K0iS_Hg4rPU26AZUqz0Jqa400dP0_OFhd1w@mail.gmail.com>
 <CAAusYCi=h9t9aAsg_Dnu8zW7CFkYkd0PW-qP59rCZiYF73TqnQ@mail.gmail.com>
 <CAPiUgVfHcm5E=8JhBMYh-uw=FnDbe0=XzR_XntX7tsgk1eB5aQ@mail.gmail.com>
 <CAAusYCgT66iVMRq_m9-z___WKnk9HCy568ebf8U4bA68HfS+Yg@mail.gmail.com>
 <CAAusYCj9xGJBXUK44PW1WdMo4s5PW5v9H_PdnUvBGKujs2y6nQ@mail.gmail.com>
 <CAAusYCg8zv=MoAMJth27zS0SwWz-coS449jkmJ68jKR0r+mpgw@mail.gmail.com>
 <CAPiUgVc04tQ6hB_0dyjasaE9b86DPhcpEDAYYQQxkDr==uMBMA@mail.gmail.com>
 <CAF7AXFG1bBuS-=kxzzsA8XBx4SfiCfGSJY2iLita2Vc2-W3RQA@mail.gmail.com>
 <CAAusYCgYq6gWqDwaDmnhnJ1osfsvcEHQ8augCbEDebRVOA8pHA@mail.gmail.com>
 <1413646938.20140211172553@mail.mipt.ru>
 <CAAusYCi6hmemt9gCZcKQTSgrg95eBo3ShG0B0CDXOvsPgoaJsw@mail.gmail.com>
 <CAF7AXFH7hC4n1P2H1VBxGCRy9ZnEvoEh8AS7RBzQytkCWAAkWw@mail.gmail.com>
 <CAAusYCgO7D2zgoijCky+s_Q9_uksKd4bCbj1GbOrSctfTpgTUQ@mail.gmail.com>
 <CAF7AXFHhusQUEO51eT8fA=ahNdvetg8-gkoVLNXCK-+KMWe4Ww@mail.gmail.com>
Message-ID: <CAPiUgVeFUsoxO_dodiV1pC71epFxXVR8azn+j7rPd8qS4J5CUQ@mail.gmail.com>

Would it be useful to pick up something like this:
https://code.google.com/p/csharp-sqlite/ ?


On Fri, May 9, 2014 at 5:59 AM, Jeff Hardy <jdhardy at gmail.com> wrote:

> On Fri, May 9, 2014 at 12:01 PM, Doug Blank <doug.blank at gmail.com> wrote:
> > On Fri, May 9, 2014 at 4:42 AM, Jeff Hardy <jdhardy at gmail.com> wrote:
> >>
> >> On Thu, May 8, 2014 at 5:32 PM, Doug Blank <doug.blank at gmail.com>
> wrote:
> >> > Just getting back to attempting to use sqlite3 on computers other than
> >> > Windows, and it looks like this C# library has other problems on other
> >> > OSes.
> >> >
> >> > The first issue is that it appears that all activity must happen in
> the
> >> > same
> >> > thread (connection, cursor, execution). That can mitigated against if
> >> > that
> >> > is the way that it has to be. (A wrapper could be supplied to run
> >> > everything
> >> > in a specific thread).
> >> >
> >> > The next problem is a show stopper:
> >> >
> >> > import sqlite3
> >> > conn = sqlite3.connect("test.db")
> >> > cur = conn.cursor()
> >> > cur.execute("select * from tables;")
> >> >
> >> > This works on Windows, but gives a SystemError: LockFileEx on Linux. I
> >> > suspect that the information that Ivan pointed to (below) indicates
> that
> >> > these patches screwed up sqlite port so that it no longer will work on
> >> > Linux
> >> > and Mac.
> >> >
> >> > Anyone have ideas, on either a fix, or using a different library,
> >> > different
> >> > version?
> >>
> >> Right now, I don't know if there's much that can be done. The C#
> >> SQLite port it uses is pretty Windows-specific, and I doubt it's worth
> >> the effort to fix it since it's no longer maintained anyway. I've been
> >> pondering replacing the guts of the SQLite module with
> >> https://github.com/ericsink/SQLitePCL.raw, which wraps the *actual*
> >> SQLite library instead of the C# port.
> >>
> >> The module implementation shouldn't have to change that much, since
> >> most of the function names should be the same. I don't yet know if
> >> SQLitePCL works on Unix/Mac but it does support Android and iOS so
> >> it's probably going to be a lot easier to fix it than it would be for
> >> C#-SQLite.
> >>
> >> I hadn't planned on this until IronPython 3, but I'd be very happy to
> >> include it in 2.7.5 (or a possible 2.7.6) if someone else does the
> >> work.
> >
> >
> > Thanks for the information!
> >
> > As I am also interested in other .NET/Mono languages (and other DB
> > connections), I wonder if we are going to spend any time on this, if it
> > wouldn't be better to use (and perhaps refine, if needed) the ADO.NETSqlite
> > interface:
> >
> > http://www.mono-project.com/SQLite
> >
> > Perhaps it is better to move away from the sqlite-specific API and
> towards a
> > standard that would allow people to move between db backends? I suspect
> Vern
> > may have some information on this point, considering his recent
> announcement
> > here on adodbapi version 2.6.
>
> I actually tried to use that, originally, but Python's sqlite module
> exposes some low-level features of SQLite that can't be emulated with
> an ADO-type interface. The only way to implementing it faithfully is
> to have direct(ish) access to the SQLite library.
>
> Most real apps will use a higher-level wrapper, but IronPython still
> needs to provide the sqlite module, since most of the high-level
> wrappers will expect it to be there.
>
> - 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/20140509/0e8ddbfa/attachment.html>

From jdhardy at gmail.com  Fri May  9 15:48:34 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 9 May 2014 14:48:34 +0100
Subject: [Ironpython-users] IronPython SQLite interface
In-Reply-To: <CAPiUgVeFUsoxO_dodiV1pC71epFxXVR8azn+j7rPd8qS4J5CUQ@mail.gmail.com>
References: <CAAusYCgLrRFOhnCEmMxXsfXqdirRVjquM6N6F1T4FN=Wk1HHMg@mail.gmail.com>
 <CAPiUgVcyXxn0D21K0iS_Hg4rPU26AZUqz0Jqa400dP0_OFhd1w@mail.gmail.com>
 <CAAusYCi=h9t9aAsg_Dnu8zW7CFkYkd0PW-qP59rCZiYF73TqnQ@mail.gmail.com>
 <CAPiUgVfHcm5E=8JhBMYh-uw=FnDbe0=XzR_XntX7tsgk1eB5aQ@mail.gmail.com>
 <CAAusYCgT66iVMRq_m9-z___WKnk9HCy568ebf8U4bA68HfS+Yg@mail.gmail.com>
 <CAAusYCj9xGJBXUK44PW1WdMo4s5PW5v9H_PdnUvBGKujs2y6nQ@mail.gmail.com>
 <CAAusYCg8zv=MoAMJth27zS0SwWz-coS449jkmJ68jKR0r+mpgw@mail.gmail.com>
 <CAPiUgVc04tQ6hB_0dyjasaE9b86DPhcpEDAYYQQxkDr==uMBMA@mail.gmail.com>
 <CAF7AXFG1bBuS-=kxzzsA8XBx4SfiCfGSJY2iLita2Vc2-W3RQA@mail.gmail.com>
 <CAAusYCgYq6gWqDwaDmnhnJ1osfsvcEHQ8augCbEDebRVOA8pHA@mail.gmail.com>
 <1413646938.20140211172553@mail.mipt.ru>
 <CAAusYCi6hmemt9gCZcKQTSgrg95eBo3ShG0B0CDXOvsPgoaJsw@mail.gmail.com>
 <CAF7AXFH7hC4n1P2H1VBxGCRy9ZnEvoEh8AS7RBzQytkCWAAkWw@mail.gmail.com>
 <CAAusYCgO7D2zgoijCky+s_Q9_uksKd4bCbj1GbOrSctfTpgTUQ@mail.gmail.com>
 <CAF7AXFHhusQUEO51eT8fA=ahNdvetg8-gkoVLNXCK-+KMWe4Ww@mail.gmail.com>
 <CAPiUgVeFUsoxO_dodiV1pC71epFxXVR8azn+j7rPd8qS4J5CUQ@mail.gmail.com>
Message-ID: <CAF7AXFEiG+_iRN4U1NTYwVU7tfNcfZ-3hXi=q3y0RQonojCXMA@mail.gmail.com>

On Fri, May 9, 2014 at 2:41 PM, Slide <slide.o.mix at gmail.com> wrote:
> Would it be useful to pick up something like this:
> https://code.google.com/p/csharp-sqlite/ ?

That's what it already uses. :) It's no longer maintained, doesn't
work on non-Windows platforms, and is perpetually behind the actual
SQLite releases. It's served well, but there are better options now.

- Jeff

From slide.o.mix at gmail.com  Fri May  9 15:56:01 2014
From: slide.o.mix at gmail.com (Slide)
Date: Fri, 9 May 2014 06:56:01 -0700
Subject: [Ironpython-users] IronPython SQLite interface
In-Reply-To: <CAF7AXFEiG+_iRN4U1NTYwVU7tfNcfZ-3hXi=q3y0RQonojCXMA@mail.gmail.com>
References: <CAAusYCgLrRFOhnCEmMxXsfXqdirRVjquM6N6F1T4FN=Wk1HHMg@mail.gmail.com>
 <CAPiUgVcyXxn0D21K0iS_Hg4rPU26AZUqz0Jqa400dP0_OFhd1w@mail.gmail.com>
 <CAAusYCi=h9t9aAsg_Dnu8zW7CFkYkd0PW-qP59rCZiYF73TqnQ@mail.gmail.com>
 <CAPiUgVfHcm5E=8JhBMYh-uw=FnDbe0=XzR_XntX7tsgk1eB5aQ@mail.gmail.com>
 <CAAusYCgT66iVMRq_m9-z___WKnk9HCy568ebf8U4bA68HfS+Yg@mail.gmail.com>
 <CAAusYCj9xGJBXUK44PW1WdMo4s5PW5v9H_PdnUvBGKujs2y6nQ@mail.gmail.com>
 <CAAusYCg8zv=MoAMJth27zS0SwWz-coS449jkmJ68jKR0r+mpgw@mail.gmail.com>
 <CAPiUgVc04tQ6hB_0dyjasaE9b86DPhcpEDAYYQQxkDr==uMBMA@mail.gmail.com>
 <CAF7AXFG1bBuS-=kxzzsA8XBx4SfiCfGSJY2iLita2Vc2-W3RQA@mail.gmail.com>
 <CAAusYCgYq6gWqDwaDmnhnJ1osfsvcEHQ8augCbEDebRVOA8pHA@mail.gmail.com>
 <1413646938.20140211172553@mail.mipt.ru>
 <CAAusYCi6hmemt9gCZcKQTSgrg95eBo3ShG0B0CDXOvsPgoaJsw@mail.gmail.com>
 <CAF7AXFH7hC4n1P2H1VBxGCRy9ZnEvoEh8AS7RBzQytkCWAAkWw@mail.gmail.com>
 <CAAusYCgO7D2zgoijCky+s_Q9_uksKd4bCbj1GbOrSctfTpgTUQ@mail.gmail.com>
 <CAF7AXFHhusQUEO51eT8fA=ahNdvetg8-gkoVLNXCK-+KMWe4Ww@mail.gmail.com>
 <CAPiUgVeFUsoxO_dodiV1pC71epFxXVR8azn+j7rPd8qS4J5CUQ@mail.gmail.com>
 <CAF7AXFEiG+_iRN4U1NTYwVU7tfNcfZ-3hXi=q3y0RQonojCXMA@mail.gmail.com>
Message-ID: <CAPiUgVcXhz=0zwoHeSmDygKy6nchsJ2rvGkKrTAOLXsC_Drc1g@mail.gmail.com>

Ah, I guess it would help if I actually went and looked at what was being
used :-)


On Fri, May 9, 2014 at 6:48 AM, Jeff Hardy <jdhardy at gmail.com> wrote:

> On Fri, May 9, 2014 at 2:41 PM, Slide <slide.o.mix at gmail.com> wrote:
> > Would it be useful to pick up something like this:
> > https://code.google.com/p/csharp-sqlite/ ?
>
> That's what it already uses. :) It's no longer maintained, doesn't
> work on non-Windows platforms, and is perpetually behind the actual
> SQLite releases. It's served well, but there are better options now.
>
> - Jeff
>



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

From doug.blank at gmail.com  Fri May  9 15:54:22 2014
From: doug.blank at gmail.com (Doug Blank)
Date: Fri, 9 May 2014 09:54:22 -0400
Subject: [Ironpython-users] IronPython SQLite interface
In-Reply-To: <CAF7AXFHhusQUEO51eT8fA=ahNdvetg8-gkoVLNXCK-+KMWe4Ww@mail.gmail.com>
References: <CAAusYCgLrRFOhnCEmMxXsfXqdirRVjquM6N6F1T4FN=Wk1HHMg@mail.gmail.com>
 <CAPiUgVcyXxn0D21K0iS_Hg4rPU26AZUqz0Jqa400dP0_OFhd1w@mail.gmail.com>
 <CAAusYCi=h9t9aAsg_Dnu8zW7CFkYkd0PW-qP59rCZiYF73TqnQ@mail.gmail.com>
 <CAPiUgVfHcm5E=8JhBMYh-uw=FnDbe0=XzR_XntX7tsgk1eB5aQ@mail.gmail.com>
 <CAAusYCgT66iVMRq_m9-z___WKnk9HCy568ebf8U4bA68HfS+Yg@mail.gmail.com>
 <CAAusYCj9xGJBXUK44PW1WdMo4s5PW5v9H_PdnUvBGKujs2y6nQ@mail.gmail.com>
 <CAAusYCg8zv=MoAMJth27zS0SwWz-coS449jkmJ68jKR0r+mpgw@mail.gmail.com>
 <CAPiUgVc04tQ6hB_0dyjasaE9b86DPhcpEDAYYQQxkDr==uMBMA@mail.gmail.com>
 <CAF7AXFG1bBuS-=kxzzsA8XBx4SfiCfGSJY2iLita2Vc2-W3RQA@mail.gmail.com>
 <CAAusYCgYq6gWqDwaDmnhnJ1osfsvcEHQ8augCbEDebRVOA8pHA@mail.gmail.com>
 <1413646938.20140211172553@mail.mipt.ru>
 <CAAusYCi6hmemt9gCZcKQTSgrg95eBo3ShG0B0CDXOvsPgoaJsw@mail.gmail.com>
 <CAF7AXFH7hC4n1P2H1VBxGCRy9ZnEvoEh8AS7RBzQytkCWAAkWw@mail.gmail.com>
 <CAAusYCgO7D2zgoijCky+s_Q9_uksKd4bCbj1GbOrSctfTpgTUQ@mail.gmail.com>
 <CAF7AXFHhusQUEO51eT8fA=ahNdvetg8-gkoVLNXCK-+KMWe4Ww@mail.gmail.com>
Message-ID: <CAAusYChbjq10ArC6sm_9Y3SSwfcL3SYb6q6smQY+6goP+TwgEg@mail.gmail.com>

On Fri, May 9, 2014 at 8:59 AM, Jeff Hardy <jdhardy at gmail.com> wrote:

> On Fri, May 9, 2014 at 12:01 PM, Doug Blank <doug.blank at gmail.com> wrote:
> > On Fri, May 9, 2014 at 4:42 AM, Jeff Hardy <jdhardy at gmail.com> wrote:
> >>
> >> On Thu, May 8, 2014 at 5:32 PM, Doug Blank <doug.blank at gmail.com>
> wrote:
> >> > Just getting back to attempting to use sqlite3 on computers other than
> >> > Windows, and it looks like this C# library has other problems on other
> >> > OSes.
> >> >
> >> > The first issue is that it appears that all activity must happen in
> the
> >> > same
> >> > thread (connection, cursor, execution). That can mitigated against if
> >> > that
> >> > is the way that it has to be. (A wrapper could be supplied to run
> >> > everything
> >> > in a specific thread).
> >> >
> >> > The next problem is a show stopper:
> >> >
> >> > import sqlite3
> >> > conn = sqlite3.connect("test.db")
> >> > cur = conn.cursor()
> >> > cur.execute("select * from tables;")
> >> >
> >> > This works on Windows, but gives a SystemError: LockFileEx on Linux. I
> >> > suspect that the information that Ivan pointed to (below) indicates
> that
> >> > these patches screwed up sqlite port so that it no longer will work on
> >> > Linux
> >> > and Mac.
> >> >
> >> > Anyone have ideas, on either a fix, or using a different library,
> >> > different
> >> > version?
> >>
> >> Right now, I don't know if there's much that can be done. The C#
> >> SQLite port it uses is pretty Windows-specific, and I doubt it's worth
> >> the effort to fix it since it's no longer maintained anyway. I've been
> >> pondering replacing the guts of the SQLite module with
> >> https://github.com/ericsink/SQLitePCL.raw, which wraps the *actual*
> >> SQLite library instead of the C# port.
> >>
> >> The module implementation shouldn't have to change that much, since
> >> most of the function names should be the same. I don't yet know if
> >> SQLitePCL works on Unix/Mac but it does support Android and iOS so
> >> it's probably going to be a lot easier to fix it than it would be for
> >> C#-SQLite.
> >>
> >> I hadn't planned on this until IronPython 3, but I'd be very happy to
> >> include it in 2.7.5 (or a possible 2.7.6) if someone else does the
> >> work.
> >
> >
> > Thanks for the information!
> >
> > As I am also interested in other .NET/Mono languages (and other DB
> > connections), I wonder if we are going to spend any time on this, if it
> > wouldn't be better to use (and perhaps refine, if needed) the ADO.NETSqlite
> > interface:
> >
> > http://www.mono-project.com/SQLite
> >
> > Perhaps it is better to move away from the sqlite-specific API and
> towards a
> > standard that would allow people to move between db backends? I suspect
> Vern
> > may have some information on this point, considering his recent
> announcement
> > here on adodbapi version 2.6.
>
> I actually tried to use that, originally, but Python's sqlite module
> exposes some low-level features of SQLite that can't be emulated with
> an ADO-type interface. The only way to implementing it faithfully is
> to have direct(ish) access to the SQLite library.
>
> Most real apps will use a higher-level wrapper, but IronPython still
> needs to provide the sqlite module, since most of the high-level
> wrappers will expect it to be there.
>

Agreed. But maybe there is a way to still use the Mono.Data.Sqlite code
base? Perhaps add in more functionality (wouldn't be exposed by ADO),
accessible via a intermediate API. It seems a waste to have two low-level
interfaces to sqlite3...

-Doug


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

From jdhardy at gmail.com  Fri May  9 16:31:36 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 9 May 2014 15:31:36 +0100
Subject: [Ironpython-users] IronPython SQLite interface
In-Reply-To: <CAAusYChbjq10ArC6sm_9Y3SSwfcL3SYb6q6smQY+6goP+TwgEg@mail.gmail.com>
References: <CAAusYCgLrRFOhnCEmMxXsfXqdirRVjquM6N6F1T4FN=Wk1HHMg@mail.gmail.com>
 <CAPiUgVcyXxn0D21K0iS_Hg4rPU26AZUqz0Jqa400dP0_OFhd1w@mail.gmail.com>
 <CAAusYCi=h9t9aAsg_Dnu8zW7CFkYkd0PW-qP59rCZiYF73TqnQ@mail.gmail.com>
 <CAPiUgVfHcm5E=8JhBMYh-uw=FnDbe0=XzR_XntX7tsgk1eB5aQ@mail.gmail.com>
 <CAAusYCgT66iVMRq_m9-z___WKnk9HCy568ebf8U4bA68HfS+Yg@mail.gmail.com>
 <CAAusYCj9xGJBXUK44PW1WdMo4s5PW5v9H_PdnUvBGKujs2y6nQ@mail.gmail.com>
 <CAAusYCg8zv=MoAMJth27zS0SwWz-coS449jkmJ68jKR0r+mpgw@mail.gmail.com>
 <CAPiUgVc04tQ6hB_0dyjasaE9b86DPhcpEDAYYQQxkDr==uMBMA@mail.gmail.com>
 <CAF7AXFG1bBuS-=kxzzsA8XBx4SfiCfGSJY2iLita2Vc2-W3RQA@mail.gmail.com>
 <CAAusYCgYq6gWqDwaDmnhnJ1osfsvcEHQ8augCbEDebRVOA8pHA@mail.gmail.com>
 <1413646938.20140211172553@mail.mipt.ru>
 <CAAusYCi6hmemt9gCZcKQTSgrg95eBo3ShG0B0CDXOvsPgoaJsw@mail.gmail.com>
 <CAF7AXFH7hC4n1P2H1VBxGCRy9ZnEvoEh8AS7RBzQytkCWAAkWw@mail.gmail.com>
 <CAAusYCgO7D2zgoijCky+s_Q9_uksKd4bCbj1GbOrSctfTpgTUQ@mail.gmail.com>
 <CAF7AXFHhusQUEO51eT8fA=ahNdvetg8-gkoVLNXCK-+KMWe4Ww@mail.gmail.com>
 <CAAusYChbjq10ArC6sm_9Y3SSwfcL3SYb6q6smQY+6goP+TwgEg@mail.gmail.com>
Message-ID: <CAF7AXFHJ_g2eLVf4BzUB7xAL4-RkBHPJw=OSECsQW1GTroq2Lw@mail.gmail.com>

On Fri, May 9, 2014 at 2:54 PM, Doug Blank <doug.blank at gmail.com> wrote:
> Agreed. But maybe there is a way to still use the Mono.Data.Sqlite code
> base? Perhaps add in more functionality (wouldn't be exposed by ADO),
> accessible via a intermediate API. It seems a waste to have two low-level
> interfaces to sqlite3...

It doesn't seem like a good use of effort to add things to
Mono.Data.SQLite (System.Data.SQLite, which is similar) that are
already exposed in SQLitePCL.raw. The intent of SQLitePCL.raw is to
*be* the definitive low-level wrapper around SQLite that everything
else can build on, so I'd rather put effort there.

Of course, I don't *really* care what library underlies it; if someone
gives me a version that uses M.D.S and supports all of the needed
platforms and all of the functionality, I wouldn't object to it.

- Jeff

From no_reply at codeplex.com  Sat May 10 09:24:30 2014
From: no_reply at codeplex.com (CodePlex)
Date: 10 May 2014 00:24:30 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/9/2014
Message-ID: <CO1MSDNADMCDS2NrMSY00027afa@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] regular expression extension accepts only single flag
2. [New comment] re.compile does not use cache
3. [New comment] Using str() on non-ASCII string throws Exception: Unable to translate bytes from specified code page to Unicode

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

ISSUES

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

"<p>fixed in 9032f8cbc51bdc76650a9e29dc96b37f2c6043f4</p>"-----------------

2. [New comment] re.compile does not use cache
http://ironpython.codeplex.com/workitem/35146
User paweljasinski has commented on the issue:

"<p>fixed in 9032f8cbc51bdc76650a9e29dc96b37f2c6043f4</p>"-----------------

3. [New comment] Using str() on non-ASCII string throws Exception: Unable to translate bytes from specified code page to Unicode
http://ironpython.codeplex.com/workitem/35199
User paweljasinski has commented on the issue:

"<p>As a workaround you can try to set defaultencoding to latin-1 in site.py</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/20140510/0e473141/attachment.html>

From no_reply at codeplex.com  Wed May 14 09:23:20 2014
From: no_reply at codeplex.com (CodePlex)
Date: 14 May 2014 00:23:20 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/13/2014
Message-ID: <CO1MSDNADMCDS2Y1SWo00000b58@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New issue] byte and string should be interchengable as arguments of string methods
2. [New issue] Error when write dicom file using IronPython
3. [New comment] Error when write dicom file using IronPython
4. [New comment] Error when write dicom file using IronPython

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

ISSUES

1. [New issue] byte and string should be interchengable as arguments of string methods
http://ironpython.codeplex.com/workitem/35212
User paweljasinski has proposed the issue:

"The following code snippet works in cpython, but throws in ipy.
class estr(str):
    pass

x=estr("a")
y=estr("a")

print x.__contains__("a")
print x.__contains__(b"a")
print x.__contains__(y)

print
print "a".__contains__("a")
print "a".__contains__(b"a")
print "a".__contains__(y)

print
print b"a".__contains__("a")
print b"a".__contains__(b"a")
print b"a".__contains__(y)

The list of the methods: https://docs.python.org/2/library/stdtypes.html#string-methods
Original problem report: https://github.com/IronLanguages/main/issues/195"-----------------

2. [New issue] Error when write dicom file using IronPython
http://ironpython.codeplex.com/workitem/35215
User shktang has proposed the issue:

"c:> ipy
IronPython 2.7.4 (2.7.0.40) on .NET 4.0.30319.18408 (32-bit)
Type "help", "copyright", "credits" or "license" for more information.



import dicom
da = dicom.read_file("CT.test01.dcm")
dicom.write_file("CT.out.dcm")



Which causes the following error message:


File "C:\IronPython2.7.4\lib\site-packages\dicom\filewriter.py", line 338, in write_file
  File "C:\IronPython2.7.4\lib\site-packages\dicom\filewriter.py", line 278, in _write_file_meta_info
  File "C:\IronPython2.7.4\lib\site-packages\dicom\filewriter.py", line 196, in write_dataset
  File "C:\IronPython2.7.4\lib\site-packages\dicom\filewriter.py", line 132, in write_data_element
  File "C:\IronPython2.7.4\lib\site-packages\dicom\filebase.py", line 47, in write_tag
  File "C:\IronPython2.7.4\lib\site-packages\dicom\filebase.py", line 86, in write_leUS

Any way to resolve the problem?"-----------------

3. [New comment] Error when write dicom file using IronPython
http://ironpython.codeplex.com/workitem/35215
User paweljasinski has commented on the issue:

"<p>Please, direct question like this one to ironpython mailing list: http://blog.gmane.org/gmane.comp.python.ironpython.user<br>or https://mail.python.org/mailman/listinfo/ironpython-users<br>I also believe that the actual error/exception got lost during the copy/paste. Is there anything else you have got?</p>"-----------------

4. [New comment] Error when write dicom file using IronPython
http://ironpython.codeplex.com/workitem/35215
User shktang has commented on the issue:

"<p>Forget the last line of the error message:</p><p>TypeError: expected str, got bytes</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/20140514/ff6a0c37/attachment.html>

From no_reply at codeplex.com  Thu May 15 09:27:17 2014
From: no_reply at codeplex.com (CodePlex)
Date: 15 May 2014 00:27:17 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/14/2014
Message-ID: <CO1MSDNADMCDS2z5b6K00003124@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] byte and string should be interchengable as arguments of string methods

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

ISSUES

1. [New comment] byte and string should be interchengable as arguments of string methods
http://ironpython.codeplex.com/workitem/35212
User jdhardy has commented on the issue:

"<p>Not opposed, as long as we remember that we have to undo everything for IronPython 3, where str and bytes cannot mix.</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/20140515/b7d4e5d1/attachment.html>

From no_reply at codeplex.com  Fri May 16 09:23:03 2014
From: no_reply at codeplex.com (CodePlex)
Date: 16 May 2014 00:23:03 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/15/2014
Message-ID: <CO1MSDNADMCDS2Ln5WJ00004e13@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] Error when write dicom file using IronPython
2. [New comment] Error when write dicom file using IronPython
3. [New comment] Error when write dicom file using IronPython
4. [New issue] bytes "can only join an iterable of bytes"

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

ISSUES

1. [New comment] Error when write dicom file using IronPython
http://ironpython.codeplex.com/workitem/35215
User paweljasinski has commented on the issue:

"<p>1. I have pulled sources from dicom version 0.9.8 and tried. It looks like you are using different version. Can you upgrade to the latest?</p><p>2. I tried my luck and in __init__.py of the dicom changed:<br>```in_py3 = sys.version_info[0] &gt; 2```<br>to<br>```in_py3 = sys.version_info[0] &gt; 2 or sys.platform == 'cli'```</p><p>3. at this point tried:<br>```<br>import dicom<br>ds = dicom.read_file(&quot;CT_small.dcm&quot;)<br>ds.save_as(&quot;foo&quot;)<br>```<br>which discovers real bug in IronPython<br>```<br>Traceback (most recent call last):<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\filewriter.py&quot;, line 91, in write_PN<br>  File &quot;di.py&quot;, line 3, in &lt;module&gt;<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\dataset.py&quot;, line 467, in save_as<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\filewriter.py&quot;, line 344, in write_file<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\filewriter.py&quot;, line 196, in write_dataset<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\filewriter.py&quot;, line 160, in write_data_element<br>TypeError: can only join an iterable of bytes<br>```</p><p><br></p>"-----------------

2. [New comment] Error when write dicom file using IronPython
http://ironpython.codeplex.com/workitem/35215
User paweljasinski has commented on the issue:

"<p>if I could only edit my post ...<br>Anyway, the last issue is reported separately: bytes &quot;can only join an iterable of bytes&quot;</p>"-----------------

3. [New comment] Error when write dicom file using IronPython
http://ironpython.codeplex.com/workitem/35215
User paweljasinski has commented on the issue:

"<p>I mean: https://ironpython.codeplex.com/workitem/35224</p>"-----------------

4. [New issue] bytes "can only join an iterable of bytes"
http://ironpython.codeplex.com/workitem/35224
User paweljasinski has proposed the issue:

"Another cpython/ironpython mismatch when mixing bytes/string.
c:\cygwin64\home\rejap>ipy
IronPython 2.7.5a1 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit)
Type "help", "copyright", "credits" or "license" for more information.
>>> b"b".join(["a"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only join an iterable of bytes
>>>
"
----------------------------------------------



----------------------------------------------
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/20140516/229f174c/attachment.html>

From no_reply at codeplex.com  Sat May 17 09:22:51 2014
From: no_reply at codeplex.com (CodePlex)
Date: 17 May 2014 00:22:51 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/16/2014
Message-ID: <CO1MSDNADMCDS2KFRJr00006ad1@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] types.FunctionType(...) raise NotImplementedError
2. [New comment] byte and string should be interchengable as arguments of string methods
3. [New comment] byte and string should be interchengable as arguments of string methods
4. [New comment] Error when write dicom file using IronPython
5. [Status update] Error when write dicom file using IronPython
6. [New issue] stack trace reported out of order by top level exception handler

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

ISSUES

1. [New comment] types.FunctionType(...) raise NotImplementedError
http://ironpython.codeplex.com/workitem/35180
User paweljasinski has commented on the issue:

"<p>partial fix (only 34932) in b24c9301b3eb2f90a0fa9eaca9fb4bdc145dbe5f</p>"-----------------

2. [New comment] byte and string should be interchengable as arguments of string methods
http://ironpython.codeplex.com/workitem/35212
User paweljasinski has commented on the issue:

"<p>fixed in b24c9301b3eb2f90a0fa9eaca9fb4bdc145dbe5f</p>"-----------------

3. [New comment] byte and string should be interchengable as arguments of string methods
http://ironpython.codeplex.com/workitem/35212
User paweljasinski has commented on the issue:

"<p>oops, fixed in 83ea081cb8659c8589a87534d9b51f47f7daff4c</p>"-----------------

4. [New comment] Error when write dicom file using IronPython
http://ironpython.codeplex.com/workitem/35215
User paweljasinski has commented on the issue:

"<p>As I tried to explain (but failed to format), you have to <br>1. take dicom 0.9.8<br>2. Edit ```__init__.py```, replace:<br>```<br>in_py3 = sys.version_info[0] &gt; 2<br>```<br>with<br>```<br>in_py3 = sys.version_info[0] &gt; 2 or sys.platform == 'cli'<br>```<br>3. Use fix provided in https://ironpython.codeplex.com/workitem/35212<br>4. Use fix provided here: https://github.com/IronLanguages/main/pull/199</p><p>You can also wait a few days and very likely it will be in ipy-2.7-main branch</p>"-----------------

5. [Status update] Error when write dicom file using IronPython
http://ironpython.codeplex.com/workitem/35215
User paweljasinski has updated the issue:
Status has changed from Proposed to Closed.

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

6. [New issue] stack trace reported out of order by top level exception handler
http://ironpython.codeplex.com/workitem/35230
User paweljasinski has proposed the issue:

"I have discovered it when playing with dicom. If I take dicom version 0.8.9 and try the following script:
import dicom
ds = dicom.read_file("CT_small.dcm")
ds.save_as("foo")

I get the following traceback reported:
Traceback (most recent call last):
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\dataset.py", line 285, in __getitem__
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\values.py", line 188, in convert_value
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\values.py", line 117, in <lambda$214>
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\valuerep.py", line 360, in __new__
  File "di.py", line 3, in <module>
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\dataset.py", line 467, in save_as
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\filewriter.py", line 344, in write_file
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\filewriter.py", line 196, in write_dataset
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\dataelem.py", line 338, in DataElement_fro                           m_raw
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\values.py", line 120, in convert_PN
TypeError: expected IList[Byte], got str

the di.py line reported in the middle make no sense.

However if I dump traceback myself, things look as expected:
import dicom
import traceback
try:
    ds = dicom.read_file("CT_small.dcm")
    ds.save_as("foo")
except:
    traceback.print_exc()

traceback:
Traceback (most recent call last):
  File "di.py", line 5, in <module>
    ds.save_as("foo")
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\dataset.py", line 467, in save_as
    dicom.write_file(filename, self, WriteLikeOriginal)
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\filewriter.py", line 344, in write_file
    write_dataset(fp, dataset)
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\filewriter.py", line 196, in write_dataset
    write_data_element(fp, dataset[tag], dataset_encoding)
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\dataset.py", line 285, in __getitem__
    self[tag] = DataElement_from_raw(data_elem, character_set)
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\dataelem.py", line 338, in DataElement_from_raw
    value = convert_value(VR, raw, encoding)
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\values.py", line 188, in convert_value
    value = converter(byte_string, is_little_endian, encoding=encoding)
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\values.py", line 120, in convert_PN
    return valtype(splitup[0])
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\values.py", line 117, in <lambda$214>
    valtype = lambda x: PersonName(x, *args)
  File "C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pydicom-0.9.8-py2.7.egg\dicom\valuerep.py", line 360, in __new__
    return super(PersonName, cls).__new__(cls, val)
TypeError: expected IList[Byte], got str
"
----------------------------------------------



----------------------------------------------
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/20140517/5c06b51d/attachment.html>

From no_reply at codeplex.com  Sun May 18 09:23:59 2014
From: no_reply at codeplex.com (CodePlex)
Date: 18 May 2014 00:23:59 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/17/2014
Message-ID: <CO1MSDNADMCDS2Ywlib00007c30@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New issue] Django & IronPython - Not working
2. [New comment] Django & IronPython - Not working

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

ISSUES

1. [New issue] Django & IronPython - Not working
http://ironpython.codeplex.com/workitem/35231
User PlexCUser has proposed the issue:

"Hello,

The basic Django example (manage.py) fails to execute in IronPython.

Dajngo - 1.6.1
IronPython - 2.7
Visual Studio Ultimate with SP1- 2013 - 2.0 (Django Integration - 2.0)
Visual Studio Debug Interpreter Args: -X:FullFrame
Steps:

Install IrnoPython 2.7 msi package
install Django 1.6.1 from command line with -X:FullFrame option
install setuptools 2.1 from command line with -X:FullFrame option
Open a Dajngo project in Visual Studio
Set PythonEnvironment to 2.7  64bit
Set Project's Debug intepreter args: -X:FullFrame

StartDebug


Error: "AttributeError: 'NoneType' object has no attribute '_meta'"

Full Stack trace:

Validating models...

C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\forms\forms.py:58
: DeprecationWarning: object.__new__() takes no parameters
  return SortedDict(fields)

Traceback (most recent call last):
  File "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensio
ns\Microsoft\Python Tools for Visual Studio\2.0\visualstudio_py_util.py", line 7
6, in exec_file
exec(code_obj, global_variables)

File "C:\devs\django\HelloWorld\HelloWorld\HelloWorld\manage.py", line 10, in
<module>
execute_from_command_line(sys.argv)

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\core\mana
gement__init__.py", line 399, in execute_from_command_line
utility.execute()

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\core\mana
gement__init__.py", line 392, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\core\mana
gement\base.py", line 242, in run_from_argv
self.execute(*args, **options.__dict__)

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\core\mana
gement\base.py", line 285, in execute
output = self.handle(*args, **options)

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\core\mana
gement\commands\runserver.py", line 79, in handle
self.run(*args, **options)

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\core\mana
gement\commands\runserver.py", line 90, in run
self.inner_run(*args, **options)

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\core\mana
gement\commands\runserver.py", line 101, in inner_run
self.validate(display_num_errors=True)

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\core\mana
gement\base.py", line 310, in validate
num_errors = get_validation_errors(s, app)

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\core\mana
gement\validation.py", line 34, in get_validation_errors
for (app_name, error) in get_app_errors().items():

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\db\models
\loading.py", line 196, in get_app_errors
self._populate()

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\db\models
\loading.py", line 75, in _populate
self.load_app(app_name, True)

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\db\models
\loading.py", line 99, in load_app
models = import_module('%s.models' % app_name)

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\utils\imp
ortlib.py", line 40, in import_module
__import__(name)

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\contrib\a
uth\models.py", line 361, in <module>
class AbstractUser(AbstractBaseUser, PermissionsMixin):

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\db\models
\base.py", line 212, in new
new_class.add_to_class(field.name, copy.deepcopy(field))

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\db\models
\base.py", line 264, in add_to_class
value.contribute_to_class(cls, name)

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\db\models
\fields\related.py", line 1489, in contribute_to_class
setattr(cls, self.name, ReverseManyRelatedObjectsDescriptor(self))

File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\db\models
\fields\related.py", line 831, in set
if not self.field.rel.through._meta.auto_created:

AttributeError: 'NoneType' object has no attribute '_meta'
Press any key to continue . . . Unhandled exception on thread
Traceback (most recent call last):
SystemError: Object reference not set to an instance of an object.


Any help is really appreciated.
Thank you."-----------------

2. [New comment] Django & IronPython - Not working
http://ironpython.codeplex.com/workitem/35231
User paweljasinski has commented on the issue:

"<p>Sorry for the trivial question, does django works without of VS/PTVS environment?</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/20140518/0492e35f/attachment.html>

From vernondcole at gmail.com  Sun May 18 16:28:06 2014
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Sun, 18 May 2014 08:28:06 -0600
Subject: [Ironpython-users] Django & IronPython - Not working
Message-ID: <CAH-ZgAft0VCHVAcZ8MF+LQ9kW-2JZ_RDcK7z6EwxcqUdmP4xWg@mail.gmail.com>

>
> User PlexCUser has proposed the issue:
>
> "Hello,
>
> The basic Django example (manage.py) fails to execute in IronPython.
>
> Dajngo - 1.6.1
> IronPython - 2.7
> Visual Studio Ultimate with SP1- 2013 - 2.0 (Django Integration - 2.0)
>
[...clipped...]

I have been aiming at this target literally for years, and the time is
indeed almost here, but it will be a while yet before the result would be
production ready.  (Another volunteer on the project would help motivate
me.)

I never expected django to run on IronPython 2 because of the historically
confused use of bytes vs strings in django.  Recently, they have had to
clean django up in order to run it on Python 3, and my plan all along has
been to wait until IronPython 3 to actually try it.  With that in mind, I
have cloned a copy of the IronPython3 source, but have not yet got it to
build using Visual Studio Express.  I may have to get serious and license a
real version of Visual Studio.  [side question: which version of VS is
recommended?]

The next hurdle for the project is a suitable database back-end for the
django ORM.  The Sqlite3 back-end should work straight out of the box --
but Sqlite is not suitable for production operation.  The other officially
supported database engines all use driver code written in C, so are
non-starters for IronPython.

This leaves (as far as I know) only the django-mssql package as a viable
backend. That package uses a fork of an early version of adodbapi as its
database api layer -- a very old fork with neither IronPython nor Python3
capability.  I entered into a project with Michael Manfre (the maintainer
of django-mssql) to replace that old fork with the current
sourceforge/adodbapi <http://sourceforge.net/projects/adodbapi> and vastly
refactored adodbapi for that purpose.  That work is in
https://bitbucket.org/vernondcole/django-mssql-ado-merge and is complete
enough that it is being used here at eHealth Africa in a lightweight role
(where a Linux django server modifies a SQL Server database.)

Unfortunately, Michael has decided to abandon that effort and will maintain
his separate fork of adodbapi. His efforts are dedicated to improving the
commercial environment he works in: CPython2.7, Windows, and SQL Server.
He felt that my efforts to widen the choices (Python3, IronPython, Linux,
other database engines) would impact his ability to support his target
system. Therefore, the "merge" fork is (as of this morning) 93 commits
behind his work.  I included several of his changes in the adodbapi version
I released last week, but the rest still need to be evaluated and manually
merged. Having to maintain a separate fork of the django database back-end
will slow me down, I fear.

Nevertheless, I hope to have an alpha-test version of django on IronPython
running in a few weeks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140518/0ae4594f/attachment.html>

From pawel.jasinski at gmail.com  Mon May 19 00:31:55 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Mon, 19 May 2014 00:31:55 +0200
Subject: [Ironpython-users] Django & IronPython - Not working
In-Reply-To: <CAH-ZgAft0VCHVAcZ8MF+LQ9kW-2JZ_RDcK7z6EwxcqUdmP4xWg@mail.gmail.com>
References: <CAH-ZgAft0VCHVAcZ8MF+LQ9kW-2JZ_RDcK7z6EwxcqUdmP4xWg@mail.gmail.com>
Message-ID: <CA+7conn8siWoLPWibj=n-a-yWN+hPYk42esWLM7kAvOON2RR7A@mail.gmail.com>

 [side question: which version of VS is recommended?]

I am using VS2013 (update 2 did not break anything) and Resharper 8.2.
In VS2010 and older version of Resharper lag after recompile was
intolerable.
I also believe (only subjective observation) that project dependency
calculation improved. I remember manually mocking with Configuration
Manager to get reasonable recompile time - this is not the case in 2013.

What else is in use?


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

From jdhardy at gmail.com  Mon May 19 09:03:04 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Mon, 19 May 2014 08:03:04 +0100
Subject: [Ironpython-users] Django & IronPython - Not working
In-Reply-To: <CAH-ZgAft0VCHVAcZ8MF+LQ9kW-2JZ_RDcK7z6EwxcqUdmP4xWg@mail.gmail.com>
References: <CAH-ZgAft0VCHVAcZ8MF+LQ9kW-2JZ_RDcK7z6EwxcqUdmP4xWg@mail.gmail.com>
Message-ID: <CAF7AXFEZpXoRoUBtDg_t=A5vRZZBN2A2Bny966aOCsv21+T8xg@mail.gmail.com>

On Sun, May 18, 2014 at 3:28 PM, Vernon D. Cole <vernondcole at gmail.com> wrote:
> Nevertheless, I hope to have an alpha-test version of django on IronPython
> running in a few weeks.

Sweeeeet. I've been interested in seeing this since 2007 - although
I've come to hate web development with a passion, hopefully others are
still interested. :)

When IP3 is out I'll rewrite NWSGI on top of OWIN to plug in to the
new ASP.NET stack, which could open up some interesting options for
integrating ASP.NET and Django, which is what I wanted to do way back
when (and SharePoint...*shudder*).

One thing is that Pawel has done a bunch of work to make bytes-str
interop better in 2.7.5. We'll have to rip it all out in 3.0, but I
think it might help with Django even without IP3 (which is way behind
the 2.7.5 repo at the moment).

- Jeff

From no_reply at codeplex.com  Mon May 19 09:22:06 2014
From: no_reply at codeplex.com (CodePlex)
Date: 19 May 2014 00:22:06 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/18/2014
Message-ID: <CO1MSDNADMCDS2s7nlT00008d39@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] Unhandled traceback does not end with newline
2. [New comment] bytes "can only join an iterable of bytes"
3. [New comment] stack trace reported out of order by top level exception handler

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

ISSUES

1. [New comment] Unhandled traceback does not end with newline
http://ironpython.codeplex.com/workitem/34871
User paweljasinski has commented on the issue:

"<p>fixed in e1dd08908a9c75a588bd77663da61d416259300a</p>"-----------------

2. [New comment] bytes "can only join an iterable of bytes"
http://ironpython.codeplex.com/workitem/35224
User paweljasinski has commented on the issue:

"<p>fixed in c5a0422e13aac600dd75d09205ad1380ffc93f2d</p>"-----------------

3. [New comment] stack trace reported out of order by top level exception handler
http://ironpython.codeplex.com/workitem/35230
User paweljasinski has commented on the issue:

"<p>fixed in e1dd08908a9c75a588bd77663da61d416259300a</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/20140519/5fc085f0/attachment.html>

From pawel.jasinski at gmail.com  Mon May 19 10:07:40 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Mon, 19 May 2014 10:07:40 +0200
Subject: [Ironpython-users] Django & IronPython - Not working
In-Reply-To: <CAF7AXFEZpXoRoUBtDg_t=A5vRZZBN2A2Bny966aOCsv21+T8xg@mail.gmail.com>
References: <CAH-ZgAft0VCHVAcZ8MF+LQ9kW-2JZ_RDcK7z6EwxcqUdmP4xWg@mail.gmail.com>
 <CAF7AXFEZpXoRoUBtDg_t=A5vRZZBN2A2Bny966aOCsv21+T8xg@mail.gmail.com>
Message-ID: <CA+7conmNa7ft+x2MJG58s2c9Basy=kMRoekAhawLv2Ci0w539Q@mail.gmail.com>

If I have a moment, I will give it a spin under current state of 2.7.5
--pawel


On Mon, May 19, 2014 at 9:03 AM, Jeff Hardy <jdhardy at gmail.com> wrote:

> On Sun, May 18, 2014 at 3:28 PM, Vernon D. Cole <vernondcole at gmail.com>
> wrote:
> > Nevertheless, I hope to have an alpha-test version of django on
> IronPython
> > running in a few weeks.
>
> Sweeeeet. I've been interested in seeing this since 2007 - although
> I've come to hate web development with a passion, hopefully others are
> still interested. :)
>
> When IP3 is out I'll rewrite NWSGI on top of OWIN to plug in to the
> new ASP.NET stack, which could open up some interesting options for
> integrating ASP.NET and Django, which is what I wanted to do way back
> when (and SharePoint...*shudder*).
>
> One thing is that Pawel has done a bunch of work to make bytes-str
> interop better in 2.7.5. We'll have to rip it all out in 3.0, but I
> think it might help with Django even without IP3 (which is way behind
> the 2.7.5 repo at the moment).
>
> - 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/20140519/2852471d/attachment.html>

From no_reply at codeplex.com  Tue May 20 09:26:50 2014
From: no_reply at codeplex.com (CodePlex)
Date: 20 May 2014 00:26:50 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/19/2014
Message-ID: <CO1MSDNADMCDS2swFCH0000aaff@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] Specific case causes traceback to be incomplete
2. [New comment] Django & IronPython - Not working

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

ISSUES

1. [New comment] Specific case causes traceback to be incomplete
http://ironpython.codeplex.com/workitem/35204
User paweljasinski has commented on the issue:

"<p>I think in ip `raise` without argument wipes out traceback.<br>If I replace `raise` with:<br>```<br>ex_tuple = sys.exc_info()<br>raise ex_tuple[0], ex_tuple[1], ex_tuple[2]<br>```<br>I see an expected result.</p>"-----------------

2. [New comment] Django & IronPython - Not working
http://ironpython.codeplex.com/workitem/35231
User PlexCUser has commented on the issue:

"<p>I am getting different error when launched from command line, no VS/PTVS environment.<br>Error is: <br>  File &quot;C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django<br>base.py&quot;, line 1133, in dec<br>AttributeError: attribute '__doc__' of 'partial' object is read-only</p><p>Here are the steps to reproduce the problem:</p><p>&gt;ipy64.exe -X:FullFrames &quot;%IRONPYTHONPATH%&quot;\Scripts\django-a<br>dmin.py startproject todos<br>&gt; cd todos<br>&gt;ipy64 -X:FullFrames manage.py runserver</p><p><br>Same issue even if I use'ipy.exe', instead of 'ipy64' in the above command.</p><p>Stack trace:</p><p>C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\forms\forms.py:1:<br> DeprecationWarning: object.__new__() takes no parameters<br>  &quot;&quot;&quot;</p><p>Traceback (most recent call last):<br>  File &quot;C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\core\mana<br>gement\__init__.py&quot;, line 399, in execute_from_command_line<br>  File &quot;C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\core\mana<br>gement\__init__.py&quot;, line 392, in execute<br>  File &quot;C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\core\mana<br>gement\base.py&quot;, line 242, in run_from_argv<br>  File &quot;C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\utils\tra<br>nslation\__init__.py&quot;, line 130, in activate<br>  File &quot;C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\utils\tra<br>nslation\trans_real.py&quot;, line 188, in activate<br>  File &quot;C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\utils\tra<br>nslation\trans_real.py&quot;, line 177, in translation<br>  File &quot;C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\utils\tra<br>nslation\trans_real.py&quot;, line 159, in _fetch<br>  File &quot;C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\utils\imp<br>ortlib.py&quot;, line 40, in import_module<br>  File &quot;C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\contrib\a<br>dmin\__init__.py&quot;, line 3, in &lt;module&gt;<br>  File &quot;C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\contrib\a<br>dmin\helpers.py&quot;, line 6, in &lt;module&gt;<br>  File &quot;C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\contrib\a<br>dmin\templatetags\admin_static.py&quot;, line 11, in &lt;module&gt;<br>  File &quot;C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\template\<br>base.py&quot;, line 1142, in simple_tag<br>  File &quot;manage.py&quot;, line 10, in &lt;module&gt;<br>  File &quot;C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\core\mana<br>gement\base.py&quot;, line 280, in execute<br>  File &quot;C:\Program Files (x86)\IronPython 2.7\lib\site-packages\django\template\<br>base.py&quot;, line 1133, in dec<br>AttributeError: attribute '__doc__' of 'partial' object is read-only<br></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/20140520/beadbf23/attachment.html>

From no_reply at codeplex.com  Wed May 21 09:23:22 2014
From: no_reply at codeplex.com (CodePlex)
Date: 21 May 2014 00:23:22 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/20/2014
Message-ID: <CO1MSDNADMCDS2bC8wS0000ce95@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] Django & IronPython - Not working

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

ISSUES

1. [New comment] Django & IronPython - Not working
http://ironpython.codeplex.com/workitem/35231
User jdhardy has commented on the issue:

"<p>Looks like https://ironpython.codeplex.com/workitem/35021, which will be fixed in 2.7.5. Can't remember if the fix is in B1 or not, but it will be in B2 (coming soon).</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/20140521/8071572f/attachment.html>

From jdhardy at gmail.com  Wed May 21 10:20:37 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 21 May 2014 09:20:37 +0100
Subject: [Ironpython-users] Changing AssemblyVersion in 2.7.5 Beta 2
Message-ID: <CAF7AXFFZK+w5-O7JX-fhUV13NWZuU4WxjFBmR1AZ-O8G-=njpA@mail.gmail.com>

There's a request on CodePlex[1] to change the AssemblyVersion for
2.7.5 instead of keeping it the same (it's been 2.7.0.40 since the
first 2.7 release). The pull request is at [2] and I want to get some
feedback before pushing the changes to see how it affects people.

For those who weren't aware (and I envy you), AssemblyVersion - along
with the assembly name, culture, and signature (the "4 part name") -
is one of the things .NET uses to decide which assembly to load. If an
assembly is unsigned/not-strong-named, .NET only uses the assembly
name; if it is signed/strong-named, it requires the entire 4 part name
to match. IronPython 2.7 assemblies are strong-named because it is
required to put them in the GAC and in certain other contexts.

By keeping the version same, IronPython releases are drop-in
replacements for each other, but this applies backwards as well as
forwards (i.e. an app built against 2.7.4 can end up running against
2.7.3). Add in that IronPython installs to the GAC by default and that
.NET will always prefer the GAC over non-GAC assemblies and it's a
mess. If an app bundles IronPython 2.7.4 (and depends on that version)
but the user has 2.7.3 installed, the app will load the 2.7.3
assemblies from the GAC.

The workaround is to do a custom build with a different strong-name
key, but that's unnecessary work for the common case. In a world with
NuGet, it makes less and less sense to have it installed in the GAC
*at all* except in rare cases (such as SharePoint or SQL Server that
require it).

In 2.7.5, the version will change to 2.7.5.0. The new installer will
include a publisher policy file in the GAC that binds the new version
to anything trying to load 2.7.0.40 (i.e. 2.7.4 and earlier). This is
actually no different than it would be if the version number stayed
the same, it's just more obvious what is happening.

The reason for the change comes to anything built against 2.7.5 - it
will no longer accidentally load an older version of IronPython (you
may still get a newer one, if there ever is a 2.7.6; I'm still sorting
out what policy files allow). Had I known about publisher policy back
in 2011 I doubt I would have stuck with the same version the whole
time.

I don't see a scenario where this causes more problems; it leaves one
case the same and improves the other. However, if you see something I
missed, *please* let me know. If not I'll push the changes and spin
2.7.5B2 this weekend so that people can test the installer.

- Jeff

P.S. I was on the fence before, but not after sorting this out:
IronPython 3 will not be strong-named and will not go into the GAC.
I'll provide a script for anyone who *needs* that, but the default
will be for anyone embedding it to distribute it (via NuGet, most
likely) and for installations to not potentially mess up everything
else on the system.

[1] https://ironpython.codeplex.com/workitem/35119
[2] https://github.com/IronLanguages/main/pull/202

From m.schaber at codesys.com  Wed May 21 11:13:52 2014
From: m.schaber at codesys.com (Markus Schaber)
Date: Wed, 21 May 2014 09:13:52 +0000
Subject: [Ironpython-users] Changing AssemblyVersion in 2.7.5 Beta 2
In-Reply-To: <CAF7AXFFZK+w5-O7JX-fhUV13NWZuU4WxjFBmR1AZ-O8G-=njpA@mail.gmail.com>
References: <CAF7AXFFZK+w5-O7JX-fhUV13NWZuU4WxjFBmR1AZ-O8G-=njpA@mail.gmail.com>
Message-ID: <727D8E16AE957149B447FE368139F2B539BD9BD8@SERVER10>

Hi, Jeff,

Let me add some thoughts out of my view (I'm managing the IronPython script interpreter hosted within the CODESYS IDE):

Von: Jeff Hardy

> There's a request on CodePlex[1] to change the AssemblyVersion for
> 2.7.5 instead of keeping it the same (it's been 2.7.0.40 since the first 2.7
> release). The pull request is at [2] and I want to get some feedback before
> pushing the changes to see how it affects people.

I'm generally strongly in favour of this idea.

> For those who weren't aware (and I envy you), AssemblyVersion - along with
> the assembly name, culture, and signature (the "4 part name") - is one of the
> things .NET uses to decide which assembly to load. If an assembly is
> unsigned/not-strong-named, .NET only uses the assembly name; if it is
> signed/strong-named, it requires the entire 4 part name to match. IronPython
> 2.7 assemblies are strong-named because it is required to put them in the GAC
> and in certain other contexts.
> 
> By keeping the version same, IronPython releases are drop-in replacements for
> each other, but this applies backwards as well as forwards (i.e. an app built
> against 2.7.4 can end up running against 2.7.3). Add in that IronPython
> installs to the GAC by default and that .NET will always prefer the GAC over
> non-GAC assemblies and it's a mess. If an app bundles IronPython 2.7.4 (and
> depends on that version) but the user has 2.7.3 installed, the app will load
> the 2.7.3 assemblies from the GAC.

We exactly had this kind of problems, including a mix between a different IronPython and DLR libraries (parts of them were downgraded), which lead to very naughty debugging sessions.

Luckily, most of this happened in our in-house usage and tests, so no real customer / end-user was harmed.

> The workaround is to do a custom build with a different strong-name key, but
> that's unnecessary work for the common case.

That's exactly what we're doing now.

> In a world with NuGet, it makes
> less and less sense to have it installed in the GAC *at all* except in rare
> cases (such as SharePoint or SQL Server that require it).

NuGet is not really appropriate for our own build system and workflows (which are established between us and our OEMs since years before NuGet appeared). :-(

(OT: Just to prevent questions: Our Home-Grown "Automation Platform" framework predates MEF, MAF, NuGet and several other, now wide-spread technologies by years, and it is not easy to replace them as we need to strongly respect backwards compatibility for our OEMs which modify and adapt our product. :-)


> In 2.7.5, the version will change to 2.7.5.0. The new installer will include
> a publisher policy file in the GAC that binds the new version to anything
> trying to load 2.7.0.40 (i.e. 2.7.4 and earlier). This is actually no
> different than it would be if the version number stayed the same, it's just
> more obvious what is happening.
> 
> The reason for the change comes to anything built against 2.7.5 - it will no
> longer accidentally load an older version of IronPython (you may still get a
> newer one, if there ever is a 2.7.6; I'm still sorting out what policy files
> allow). Had I known about publisher policy back in 2011 I doubt I would have
> stuck with the same version the whole time.

I'm not sure whether those publisher policy is a good thing. We need to make sure that the whole dependency tree (IronPython, IronPython.Modules and the various DLR assemblies) always are guaranteed to match.

Another bunch of problems might arise when we run upgraded IronPython libraries against an older standard library - we ship the (Iron)Python standard library in our own directory (currently 2.7.4), and I'm not sure whether there might be problems when those python files run against a newer (2.7.5, 2.7.6?) version of the IronPython interpreter.

Is there any way a hosting application can influence the publisher policy programmatically?

> I don't see a scenario where this causes more problems; it leaves one case
> the same and improves the other. However, if you see something I missed,
> *please* let me know. If not I'll push the changes and spin
> 2.7.5B2 this weekend so that people can test the installer.

For me, upgrading the Assembly Version is a strict improvement against the previous system. It will most probably eliminate the only reason why we build IronPython on our own right now.

As explained, I'm not yet sure about the side-effects of the publisher policy, but even with them, the situation is not worse than before, and we can still ship our own builds if necessary. :-)


> - Jeff
> 
> P.S. I was on the fence before, but not after sorting this out:
> IronPython 3 will not be strong-named and will not go into the GAC.
> I'll provide a script for anyone who *needs* that, but the default will be
> for anyone embedding it to distribute it (via NuGet, most
> likely) and for installations to not potentially mess up everything else on
> the system.

Until recently, our build system and component manager had no way to deal with "external" depencencies which are not signed, and deployed to the GAC. We recently implemented an extension which allows us to deal with external dependencies which are not in the GAC, signed or unsigned.


> [1] https://ironpython.codeplex.com/workitem/35119
> [2] https://github.com/IronLanguages/main/pull/202

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  Wed May 21 21:18:38 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 21 May 2014 20:18:38 +0100
Subject: [Ironpython-users] Changing AssemblyVersion in 2.7.5 Beta 2
In-Reply-To: <727D8E16AE957149B447FE368139F2B539BD9BD8@SERVER10>
References: <CAF7AXFFZK+w5-O7JX-fhUV13NWZuU4WxjFBmR1AZ-O8G-=njpA@mail.gmail.com>
 <727D8E16AE957149B447FE368139F2B539BD9BD8@SERVER10>
Message-ID: <CAF7AXFFrn-WT6=7FwLhT-frii2G=i=s2EuSkdLgqiFGzhOVHKA@mail.gmail.com>

On Wed, May 21, 2014 at 10:13 AM, Markus Schaber <m.schaber at codesys.com> wrote:
> Hi, Jeff,
>
> Let me add some thoughts out of my view (I'm managing the IronPython script interpreter hosted within the CODESYS IDE):
>
>> In a world with NuGet, it makes
>> less and less sense to have it installed in the GAC *at all* except in rare
>> cases (such as SharePoint or SQL Server that require it).
>
> NuGet is not really appropriate for our own build system and workflows (which are established between us and our OEMs since years before NuGet appeared). :-(
>
> (OT: Just to prevent questions: Our Home-Grown "Automation Platform" framework predates MEF, MAF, NuGet and several other, now wide-spread technologies by years, and it is not easy to replace them as we need to strongly respect backwards compatibility for our OEMs which modify and adapt our product. :-)

Don't worry, the zip files won't be going away. I do expect most
embedders to move to NuGet over time, though.

>
>
>> In 2.7.5, the version will change to 2.7.5.0. The new installer will include
>> a publisher policy file in the GAC that binds the new version to anything
>> trying to load 2.7.0.40 (i.e. 2.7.4 and earlier). This is actually no
>> different than it would be if the version number stayed the same, it's just
>> more obvious what is happening.
>>
>> The reason for the change comes to anything built against 2.7.5 - it will no
>> longer accidentally load an older version of IronPython (you may still get a
>> newer one, if there ever is a 2.7.6; I'm still sorting out what policy files
>> allow). Had I known about publisher policy back in 2011 I doubt I would have
>> stuck with the same version the whole time.
>
> I'm not sure whether those publisher policy is a good thing. We need to make sure that the whole dependency tree (IronPython, IronPython.Modules and the various DLR assemblies) always are guaranteed to match.

The policy files will only redirect 2.7.0.40 to whatever the latest
version is. They won't redirect 2.7.5 to 2.7.6.

>
> Another bunch of problems might arise when we run upgraded IronPython libraries against an older standard library - we ship the (Iron)Python standard library in our own directory (currently 2.7.4), and I'm not sure whether there might be problems when those python files run against a newer (2.7.5, 2.7.6?) version of the IronPython interpreter.
>
> Is there any way a hosting application can influence the publisher policy programmatically?

Not programmatically, but I think the binding redirects in the
app.config file can override the publisher policy.

Thanks for the input. I knew that your team was impacted by this and
forcing custom builds is not satisfactory from my point of view.

- Jeff

From m.schaber at codesys.com  Thu May 22 08:54:50 2014
From: m.schaber at codesys.com (Markus Schaber)
Date: Thu, 22 May 2014 06:54:50 +0000
Subject: [Ironpython-users] Changing AssemblyVersion in 2.7.5 Beta 2
In-Reply-To: <CAF7AXFFrn-WT6=7FwLhT-frii2G=i=s2EuSkdLgqiFGzhOVHKA@mail.gmail.com>
References: <CAF7AXFFZK+w5-O7JX-fhUV13NWZuU4WxjFBmR1AZ-O8G-=njpA@mail.gmail.com>
 <727D8E16AE957149B447FE368139F2B539BD9BD8@SERVER10>
 <CAF7AXFFrn-WT6=7FwLhT-frii2G=i=s2EuSkdLgqiFGzhOVHKA@mail.gmail.com>
Message-ID: <727D8E16AE957149B447FE368139F2B539BD9EAF@SERVER10>

Hi, Jeff,

Von: Jeff Hardy [mailto:jdhardy at gmail.com]
> > Let me add some thoughts out of my view (I'm managing the IronPython script
> > interpreter hosted within the CODESYS IDE):
> >
> >> In a world with NuGet, it makes
> >> less and less sense to have it installed in the GAC *at all* except
> >> in rare cases (such as SharePoint or SQL Server that require it).
> >
> > NuGet is not really appropriate for our own build system and workflows
> > (which are established between us and our OEMs since years before
> > NuGet appeared). :-(
> >
> > (OT: Just to prevent questions: Our Home-Grown "Automation Platform"
> > framework predates MEF, MAF, NuGet and several other, now wide-spread
> > technologies by years, and it is not easy to replace them as we need
> > to strongly respect backwards compatibility for our OEMs which modify
> > and adapt our product. :-)
> 
> Don't worry, the zip files won't be going away. I do expect most embedders to
> move to NuGet over time, though.

Until now, I did our custom build using a GIT checkout, so that's no problem either. :-)

> >> In 2.7.5, the version will change to 2.7.5.0. The new installer will
> >> include a publisher policy file in the GAC that binds the new version
> >> to anything trying to load 2.7.0.40 (i.e. 2.7.4 and earlier). This is
> >> actually no different than it would be if the version number stayed
> >> the same, it's just more obvious what is happening.
> >>
> >> The reason for the change comes to anything built against 2.7.5 - it
> >> will no longer accidentally load an older version of IronPython (you
> >> may still get a newer one, if there ever is a 2.7.6; I'm still
> >> sorting out what policy files allow). Had I known about publisher
> >> policy back in 2011 I doubt I would have stuck with the same version the
> whole time.
> >
> > I'm not sure whether those publisher policy is a good thing. We need to
> > make sure that the whole dependency tree (IronPython, IronPython.Modules and
> > the various DLR assemblies) always are guaranteed to match.
> 
> The policy files will only redirect 2.7.0.40 to whatever the latest version
> is. They won't redirect 2.7.5 to 2.7.6.

Unless 2.7.6 comes with a policy file redirecting 2.7.5 to 2.7.6 :-)

> > Another bunch of problems might arise when we run upgraded IronPython
> > libraries against an older standard library - we ship the (Iron)Python
> > standard library in our own directory (currently 2.7.4), and I'm not sure
> > whether there might be problems when those python files run against a newer
> > (2.7.5, 2.7.6?) version of the IronPython interpreter.
> >
> > Is there any way a hosting application can influence the publisher policy
> > programmatically?
> 
> Not programmatically, but I think the binding redirects in the app.config
> file can override the publisher policy.

Ah, that might be a workaround if necessary. (I hope it is not).
 
> Thanks for the input. I knew that your team was impacted by this and forcing
> custom builds is not satisfactory from my point of view.

The new versioning policy will improve a lot of use cases, and it will not hurt ours, so I encourage you to go forward.

Our tests will show whether we can drop our custom builds (my guess is that it will work), but if not, it still is not worse than now. :-)

If Python 3 really comes with unsigned DLLs, this will be easily handled by our recent changes in our framework - providing a nice migration path for our users scripts to will be the bigger challenge.

(Our ideas range from automatically applying 2to3.py to bundling both python versions for some time range, but that's a different story. :-) )


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 no_reply at codeplex.com  Thu May 22 09:26:35 2014
From: no_reply at codeplex.com (CodePlex)
Date: 22 May 2014 00:26:35 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/21/2014
Message-ID: <CO1MSDNADMCDS2FRaqb000004e3@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] Specific case causes traceback to be incomplete
2. [New comment] Django & IronPython - Not working

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

ISSUES

1. [New comment] Specific case causes traceback to be incomplete
http://ironpython.codeplex.com/workitem/35204
User paweljasinski has commented on the issue:

"<p>fixed in 3f84f157a002270f9703e7504a16e4e53111c30c</p>"-----------------

2. [New comment] Django & IronPython - Not working
http://ironpython.codeplex.com/workitem/35231
User paweljasinski has commented on the issue:

"<p>With a head of ipy-2.7-maint I am getting:<br>```<br>rejap at WIN-CUE1I6EN9JB ~/django/first<br>$ /home/rejap/github/IronLanguages/bin/Debug/ipy.exe -X:Frames manage.py runserver<br>C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\forms\forms.py:1: DeprecationWarning: object.__new__() takes no parameters<br>  &quot;&quot;&quot;</p><p>Traceback (most recent call last):<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\core\management\base.py&quot;, line 242, in run_from_argv<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\core\management\base.py&quot;, line 280, in execute<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\utils\translation\__init__.py&quot;, line 130, in activate<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\utils\translation\trans_real.py&quot;, line 188, in activate<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\utils\translation\trans_real.py&quot;, line 177, in translation<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\utils\translation\trans_real.py&quot;, line 159, in _fetch<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\utils\importlib.py&quot;, line 40, in import_module<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\contrib\admin\__init__.py&quot;, line 6, in &lt;module&gt;<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\contrib\admin\sites.py&quot;, line 4, in &lt;module&gt;<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\contrib\admin\forms.py&quot;, line 6, in &lt;module&gt;<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\contrib\auth\forms.py&quot;, line 17, in &lt;module&gt;<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\contrib\auth\models.py&quot;, line 361, in &lt;module&gt;<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\db\models\base.py&quot;, line 212, in __new__<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\db\models\base.py&quot;, line 264, in add_to_class<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\db\models\fields\related.py&quot;, line 1491, in contribute_to_class<br>  File &quot;C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\django\db\models\fields\related.py&quot;, line 833, in __set__<br>AttributeError: 'NoneType' object has no attribute '_meta'<br>```</p><p>which is consistent with your first report. I trying to run django 1.6.5</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/20140522/daf8d666/attachment.html>

From no_reply at codeplex.com  Fri May 23 09:26:35 2014
From: no_reply at codeplex.com (CodePlex)
Date: 23 May 2014 00:26:35 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/22/2014
Message-ID: <CO1MSDNADMCDS2Rqf6900002506@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] f_locals in sys.exc_info()

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

ISSUES

1. [New comment] f_locals in sys.exc_info()
http://ironpython.codeplex.com/workitem/34029
User paweljasinski has commented on the issue:

"<p>This is a side effect of not having full frames enabled by default.<br>If you provide -X:FullFrames parameter example script behaves as expected.</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/20140523/9ef9b47b/attachment.html>

From no_reply at codeplex.com  Sat May 24 00:30:44 2014
From: no_reply at codeplex.com (CodePlex)
Date: 23 May 2014 15:30:44 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/22/2014
Message-ID: <CO1MSDNADMCDS2XOCcU00003c85@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] f_locals in sys.exc_info()

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

ISSUES

1. [New comment] f_locals in sys.exc_info()
http://ironpython.codeplex.com/workitem/34029
User paweljasinski has commented on the issue:

"<p>This is a side effect of not having full frames enabled by default.<br>If you provide -X:FullFrames parameter example script behaves as expected.</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/20140523/0ae97617/attachment.html>

From no_reply at codeplex.com  Sat May 24 09:21:14 2014
From: no_reply at codeplex.com (CodePlex)
Date: 24 May 2014 00:21:14 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/23/2014
Message-ID: <CO1MSDNADMCDS2KLpgT000045c3@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] Memory Leak  when using AppDomains
2. [Status update] f_locals in sys.exc_info()

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

ISSUES

1. [New comment] Memory Leak  when using AppDomains
http://ironpython.codeplex.com/workitem/33242
User matomo has commented on the issue:

"<p>Is there any plan to do anything about this?  The issue is still present in IronPython 2.7.4.</p>"-----------------

2. [Status update] f_locals in sys.exc_info()
http://ironpython.codeplex.com/workitem/34029
User jdhardy has updated the issue:
Status has changed from Proposed to Closed with the following comment, 

"Note that for compatibility IronPython 3 ipy.exe will enable this by default."
----------------------------------------------



----------------------------------------------
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/20140524/3f367d2c/attachment.html>

From jmfrank63 at gmail.com  Sun May 25 00:09:34 2014
From: jmfrank63 at gmail.com (Johannes Frank)
Date: Sun, 25 May 2014 00:09:34 +0200
Subject: [Ironpython-users] Powershell environment
Message-ID: <CAMgHmh-9D10BSmbypYtt+vPqs-ukot82Cwx0RdR3GLLzWSASHQ@mail.gmail.com>

Hello,
 I cloned the ironpython main and followed the instructions to set up the
environment. For the cmd shell this worked flawless, but for the powershell
I got errors:

(Sorry, German powershell I am going to fix this :-) )

C:\Users\jmfra_000\Documents\GitHub\IronLanguages\main\Scripts\Bat\invoke-cmdscript.ps1
: No separator line encounted,
cmdscript exited with error
In
C:\Users\jmfra_000\Documents\GitHub\IronLanguages\main\Scripts\Bat\psdev.ps1:114
Zeichen:1
+ . $PWD\invoke-cmdscript.ps1 Dev.bat $args
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error],
WriteErrorException
    + FullyQualifiedErrorId :
Microsoft.PowerShell.Commands.WriteErrorException,invoke-cmdscript.ps1

resolve-path : Der Pfad
"C:\Users\jmfra_000\Documents\GitHub\IronLanguages\main\Scripts\Bat\aliasInternal.txt"
kann
nicht gefunden werden, da er nicht vorhanden ist.
In
C:\Users\jmfra_000\Documents\GitHub\IronLanguages\main\Scripts\Bat\psdev.ps1:116
Zeichen:31
+ (resolve-path "./alias.txt"),(resolve-path "./aliasInternal.txt") |
+                               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound:
(C:\Users\jmfra_...iasInternal.txt:String) [Resolve-Path], ItemNotFoundE
   xception
    + FullyQualifiedErrorId :
PathNotFound,Microsoft.PowerShell.Commands.ResolvePathCommand

Das Argument kann nicht verarbeitet werden, da der Wert des Arguments
"path" ung?ltig ist. ?ndern Sie den Wert des
Arguments "path", und f?hren Sie den Vorgang erneut aus.
In Zeile:2 Zeichen:1
+ ${function:..} = { invoke-expression('& cd ..') }
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [], PSArgumentException
    + FullyQualifiedErrorId : Argument


Is powershell maintained or do I just do something stupidly wrong (as I am
new to IronPython)?

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

From jdhardy at gmail.com  Sun May 25 21:44:45 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sun, 25 May 2014 20:44:45 +0100
Subject: [Ironpython-users] IronPython 2.7.5 Beta 2 Released
Message-ID: <CAF7AXFFnycAhv+ke=2G8e0enfUz3u0G3nK1a1wnjJFWegq9rDw@mail.gmail.com>

On behalf of the IronPython team, I'm happy to announce the second beta
release of IronPython
2.7.5<https://ironpython.codeplex.com/releases/view/115611>.
This release includes everything from IronPython
2.7.4<https://ironpython.codeplex.com/releases/view/90087> and
earlier. Like all IronPython 2.7-series releases, .NET 4 is required to
install it. Installing this release will replace any existing IronPython
2.7-series installation. Assemblies for embedding are provided for .NET
3.5, .NET 4, .NET 4.5, and Silverlight 5.

IronPython 2.7.5 Beta 2 is primarily a collection of bug
fixes<http://bit.ly/ipy275b2fixed> which
smooths off many of the remaining rough edges. The complete list of
changes<https://ironpython.codeplex.com/wikipage?title=https%3a%2f%2fgithub.com%2fIronLanguages%2fmain%2fcompare%2fipy-2.7.4...ipy-2.7.5-b2>
is
also available.

*Note:* *The assembly version of IronPython has changed to 2.7.5.0.* All
previous 2.7 versions had the same version (2.7.0.40) which caused issues
when different versions were installed. Publisher policy files are used to
so that applications don't have to be recompiled, but recompiling is
strongly recommended.

A huge thanks goes out to Pawel Jasinski <https://github.com/paweljasinski>,
who contributed most of the changes in this release. Thanks is also
due to Simon
Opelt <https://github.com/sopelt>, Alex Earl
<https://github.com/slide>, Jeffrey
Bester <https://github.com/jbester>, and yngipy
hernan<https://github.com/yYHernan>
.

For Visual Studio integration, check out Python Tools for Visual
Studio<http://pytools.codeplex.com/> which
has support for IronPython as well as CPython, and many other fantastic
features.

IronPython 2.7.5 Beta 2 is also available for embedding via
NuGet<http://nuget.org/>.
The main package is IronPython, and the standard library is in
IronPython.StdLib.

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

From no_reply at codeplex.com  Mon May 26 09:20:21 2014
From: no_reply at codeplex.com (CodePlex)
Date: 26 May 2014 00:20:21 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/25/2014
Message-ID: <CO1MSDNADMCDS2ZuNY10000636e@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] Memory Leak  when using AppDomains

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

ISSUES

1. [New comment] Memory Leak  when using AppDomains
http://ironpython.codeplex.com/workitem/33242
User jdhardy has commented on the issue:

"<p>Unfortunately I haven't been able to narrow down exactly why it happens. I'll try and take a look again before 2.7.5.</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/20140526/5a8042ac/attachment.html>

From jdhardy at gmail.com  Mon May 26 09:46:17 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Mon, 26 May 2014 08:46:17 +0100
Subject: [Ironpython-users] Powershell environment
In-Reply-To: <CAMgHmh-9D10BSmbypYtt+vPqs-ukot82Cwx0RdR3GLLzWSASHQ@mail.gmail.com>
References: <CAMgHmh-9D10BSmbypYtt+vPqs-ukot82Cwx0RdR3GLLzWSASHQ@mail.gmail.com>
Message-ID: <CAF7AXFH6E=X69AmgPppHUa=g9m1OYfVTsTPKaPxqwfm4qQHYsA@mail.gmail.com>

On Sat, May 24, 2014 at 11:09 PM, Johannes Frank <jmfrank63 at gmail.com>wrote:

> Hello,
>  I cloned the ironpython main and followed the instructions to set up the
> environment. For the cmd shell this worked flawless, but for the powershell
> I got errors:
>
> (Sorry, German powershell I am going to fix this :-) )
>
> ...snip...
>
> Is powershell maintained or do I just do something stupidly wrong (as I am
> new to IronPython)?
>

It's unmaintained. It was written in the PowerShell 1.0 era, so it probably
needs some tweaking. If you can get it to work, send a pull request. :)

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

From no_reply at codeplex.com  Tue May 27 09:25:52 2014
From: no_reply at codeplex.com (CodePlex)
Date: 27 May 2014 00:25:52 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/26/2014
Message-ID: <CO1MSDNADMCDS2k31TZ00007c43@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] Memory Leak  when using AppDomains

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

ISSUES

1. [New comment] Memory Leak  when using AppDomains
http://ironpython.codeplex.com/workitem/33242
User Loupi has commented on the issue:

"<p>Hello,</p><p>I'd like to add my two cents on that. After raising that bug almost 2 years ago,<br>I've used a workaround solution with Code Access Security. First, I created a PermissionSet like this:</p><p>```<br>PermissionSet CreatePermissions()<br>        {<br>            PermissionSet permissions = new PermissionSet(null);<br>            permissions.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution));<br>            permissions.AddPermission(new ReflectionPermission(ReflectionPermissionFlag.MemberAccess));<br>            permissions.AddPermission(new FileIOPermission(FileIOPermissionAccess.Read | FileIOPermissionAccess.PathDiscovery,<br>                                                            AccessControlActions.View, AppDomain.CurrentDomain.BaseDirectory));</p><p>            new Type[] <br>            {<br>                typeof(DateTime),<br>                typeof(Uri),<br>                typeof(IronPython.BytesConversionAttribute),<br>                typeof(IronPython.Modules.ArrayModule),<br>                typeof(Enumerable),<br>                typeof(SandBox)<br>            }<br>            .Select(t =&gt; t.Assembly.Evidence.GetHostEvidence&lt;StrongName&gt;())<br>            .Select(t =&gt; permissions.AddPermission(new StrongNameIdentityPermission(t.PublicKey, t.Name, t.Version)));</p><p>            return permissions;<br>        }<br>```</p><p>Then I executed Python scripts like that:</p><p>```<br>private void RunWorkflowInternal(CompiledCode compiledCode, ScriptScope scriptScope)<br>        {        <br>            myPermissionSet.PermitOnly();<br>            compiledCode.Execute(scriptScope);<br>        }<br>```</p><p>No app domain involved. This solution worked with millions of script executions, on a single ScriptEngine, on the same windows service process, for months (no reboot, no recycle, no process kill).</p><p>Then came KB2835393, which contains a new memory leak with Code Access Security. So after applying KB2835393 OR installing .NET 4.5 (which affects 4.0 too), myPermissionSet.PermitOnly() leaks.</p><p>I opened a case with my MSDN account, it is currently in the escalation state.</p><p>Just wanted to let you know in case it could be usefull/related.</p><p>Regards<br>Loupi<br></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/20140527/bc0e53ff/attachment.html>

From pawel.jasinski at gmail.com  Wed May 28 10:22:56 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Wed, 28 May 2014 10:22:56 +0200
Subject: [Ironpython-users] pylint fails randomly
Message-ID: <CA+7conk3r8mg2QdW5PtvpUQsKA0NZf92JjAaA_q-3bKagPc=Lg@mail.gmail.com>

Hi,

I am observing random crashes when trying to run pylint.
Anybody out there has experience anything similar?


Usually a run gets through a couple of modules and than throws.

 ipy -m pylint.lint -r n eax

... skip standard log of pylint ...

Unhandled exception:
Traceback (most recent call last):
  File "C:\Program Files (x86)\IronPython 2.7\Lib\runpy.py", line 175, in
run_module
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\lint.py",
line 1094, in <module>
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\lint.py",
line 628, in check
  File "C:\Program Files (x86)\IronPython 2.7\Lib\runpy.py", line 81, in
_run_module_code
  File "C:\Program Files (x86)\IronPython 2.7\Lib\runpy.py", line 72, in
_run_code
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\lint.py",
line 1039, in __init__
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\checkers\similar.py",
line 304, in close
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\checkers\similar.py",
line 75, in _compute_sims
TypeError: cannot compare sets using cmp()


Run again, this time it comes out faster:

Unhandled exception:
Traceback (most recent call last):
  File "C:\Program Files (x86)\IronPython 2.7\Lib\runpy.py", line 175, in
run_module
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\lint.py",
line 1039, in __init__
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\lint.py",
line 621, in check
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\lint.py",
line 707, in check_astroid_module
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\utils.py",
line 715, in walk
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\utils.py",
line 715, in walk
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\utils.py",
line 715, in walk
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\utils.py",
line 715, in walk
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\utils.py",
line 715, in walk
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\utils.py",
line 715, in walk
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\utils.py",
line 715, in walk
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\utils.py",
line 712, in walk
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\checkers\typecheck.py",
line 210, in visit_getattr
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\astroid\bases.py",
line 166, in getattr
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\astroid\scoped_nodes.py",
line 979, in getattr
  File "C:\Program Files (x86)\IronPython 2.7\Lib\contextlib.py", line 35,
in __exit__
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\astroid\bases.py",
line 87, in restore_path
  File "C:\Program Files (x86)\IronPython 2.7\Lib\runpy.py", line 81, in
_run_module_code
  File "C:\Program Files (x86)\IronPython 2.7\Lib\runpy.py", line 72, in
_run_code
  File
"C:\Users\rejap\AppData\Roaming\Python\IronPython27\site-packages\pylint\lint.py",
line 1094, in <module>
GeneratorExit: Exception of type
'IronPython.Runtime.Exceptions.GeneratorExitException' was thrown.

The second comes more ofter than first.
I also tried -X:Frame, -X:FullFrame, -X:ExceptionDetails, -X:MTA (out of
desperation)
The only think is, that it keeps the random pattern. At the beginning I
blamed fixes in the actual code for changing the test condition, but now I
do not change anything.

I checked codeplex for generator related issues and there are a couple of
hits.
For now I will probably validate them against 2.7.5b2 and vote everything
what is still broken.

Any suggestion on how to attack the problem triggered by pylint are greatly
appreciated.


--pawel


If you are still reading, I attached output from:
ipy -X:FullFrames -X:ExceptionDetail -m pylint.lint -r n eax
sample 1-3

and
~/github/IronLanguages/bin/Debug/ipy -X:FullFrames -X:ExceptionDetail -m
pylint.lint -r n eax
sample 4-5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140528/85c15251/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pylint-run1.out
Type: application/octet-stream
Size: 12961 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140528/85c15251/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pylint-run2.out
Type: application/octet-stream
Size: 10928 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140528/85c15251/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pylint-run3.out
Type: application/octet-stream
Size: 13579 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140528/85c15251/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pylint-run4.out
Type: application/octet-stream
Size: 18714 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140528/85c15251/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pylint-run5.out
Type: application/octet-stream
Size: 20025 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140528/85c15251/attachment-0004.obj>

From doug.blank at gmail.com  Fri May 30 15:50:20 2014
From: doug.blank at gmail.com (Doug Blank)
Date: Fri, 30 May 2014 09:50:20 -0400
Subject: [Ironpython-users] numpy in IronPython
Message-ID: <CAAusYCi1Cvp8cEEWNv8E8WfYAS0rwPSxJwBaWtPn3wuMxPyg5Q@mail.gmail.com>

numpy is a numeric package for CPython that used a lot in science.
Wondering about what it would take to develop a numpy for IronPython...

I know a few years ago that there was a paid project to port numpy to
IronPython [1], but that appears to have been only for Windows, and they
seem to have some unfinished bits. Not sure what the license of that is.

What to do for numpy IronPython on other platforms?

PyPy has been working on their numpy for years [2] and have made some great
progress [3].  Would that help a numpy on IronPython?

-Doug

[1] - https://www.enthought.com/repo/.iron/
[2] - https://bitbucket.org/pypy/numpy.git
[3] - http://buildbot.pypy.org/numpy-status/latest.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140530/906dd625/attachment.html>

From jdhardy at gmail.com  Fri May 30 22:12:29 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 30 May 2014 21:12:29 +0100
Subject: [Ironpython-users] numpy in IronPython
In-Reply-To: <CAAusYCi1Cvp8cEEWNv8E8WfYAS0rwPSxJwBaWtPn3wuMxPyg5Q@mail.gmail.com>
References: <CAAusYCi1Cvp8cEEWNv8E8WfYAS0rwPSxJwBaWtPn3wuMxPyg5Q@mail.gmail.com>
Message-ID: <CAF7AXFGph3FKJiw-x2ogU=tekN25RLqcg3YfJK2OgejiEvRxUQ@mail.gmail.com>

On Fri, May 30, 2014 at 2:50 PM, Doug Blank <doug.blank at gmail.com> wrote:

> numpy is a numeric package for CPython that used a lot in science.
> Wondering about what it would take to develop a numpy for IronPython...
>
> I know a few years ago that there was a paid project to port numpy to
> IronPython [1], but that appears to have been only for Windows, and they
> seem to have some unfinished bits. Not sure what the license of that is.
>
> What to do for numpy IronPython on other platforms?
>

I think you're out of luck, unfortunately.


> PyPy has been working on their numpy for years [2] and have made some
> great progress [3].  Would that help a numpy on IronPython?
>

I'm not sure how the PyPy team is doing the port anymore. At one point I
thought they were going to rewrite it in RPython but I don't know if that's
the case. I also thought Cython might be involved. Ialso heard that the
NumPy team would make their core a plain C library that could be wrapped
with ctypes/CFFI. I have no idea if any of those panned out.

NumPy (and SciPy/Pandas/etc) is one of those projects I would love to see
working but just don't have the time or need to do it myself. Someone else
will have to step up to lead that project if it's ever going to get done.

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

From steve at mcneel.com  Fri May 30 23:22:57 2014
From: steve at mcneel.com (Steve Baer)
Date: Fri, 30 May 2014 14:22:57 -0700
Subject: [Ironpython-users] numpy in IronPython
In-Reply-To: <CAF7AXFGph3FKJiw-x2ogU=tekN25RLqcg3YfJK2OgejiEvRxUQ@mail.gmail.com>
References: <CAAusYCi1Cvp8cEEWNv8E8WfYAS0rwPSxJwBaWtPn3wuMxPyg5Q@mail.gmail.com>
 <CAF7AXFGph3FKJiw-x2ogU=tekN25RLqcg3YfJK2OgejiEvRxUQ@mail.gmail.com>
Message-ID: <CAGj3xTsz9dH8OQOM=gg7Q-g00uvBhTWDLfac94Pgx8QuYt1tSw@mail.gmail.com>

I would definitely be interested in helping, but don't exactly know where
to start. We have a lot of users who would love to get access to numpy on
our OSX and 64bit windows versions of our product.  This is only going to
become a bigger problem in the future since we will probably only have a
64bit version for Window in the next version of Rhino.

Any suggestions?

-Steve

Steve Baer
Robert McNeel & Associates
www.rhino3d.com


On Fri, May 30, 2014 at 1:12 PM, Jeff Hardy <jdhardy at gmail.com> wrote:

> On Fri, May 30, 2014 at 2:50 PM, Doug Blank <doug.blank at gmail.com> wrote:
>
>> numpy is a numeric package for CPython that used a lot in science.
>> Wondering about what it would take to develop a numpy for IronPython...
>>
>> I know a few years ago that there was a paid project to port numpy to
>> IronPython [1], but that appears to have been only for Windows, and they
>> seem to have some unfinished bits. Not sure what the license of that is.
>>
>> What to do for numpy IronPython on other platforms?
>>
>
> I think you're out of luck, unfortunately.
>
>
>> PyPy has been working on their numpy for years [2] and have made some
>> great progress [3].  Would that help a numpy on IronPython?
>>
>
> I'm not sure how the PyPy team is doing the port anymore. At one point I
> thought they were going to rewrite it in RPython but I don't know if that's
> the case. I also thought Cython might be involved. Ialso heard that the
> NumPy team would make their core a plain C library that could be wrapped
> with ctypes/CFFI. I have no idea if any of those panned out.
>
> NumPy (and SciPy/Pandas/etc) is one of those projects I would love to see
> working but just don't have the time or need to do it myself. Someone else
> will have to step up to lead that project if it's ever going to get done.
>
> - 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/20140530/a24d677f/attachment.html>

From no_reply at codeplex.com  Sat May 31 09:21:12 2014
From: no_reply at codeplex.com (CodePlex)
Date: 31 May 2014 00:21:12 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/30/2014
Message-ID: <CO1MSDNADMCDS2fCM960000ee4e@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New issue] wrong line dumped out along with warning message

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

ISSUES

1. [New issue] wrong line dumped out along with warning message
http://ironpython.codeplex.com/workitem/35263
User JozefAlexovic has proposed the issue:

"When issue warning with warnings.warn() function the first line of module is dumped instead of actual warning line.     [IronPython 2.7.4 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit)]

module warn.py:
'''
Created on 30 May 2014
'''
import warnings
warnings.warn('you have been warned!')

running this module with ipy leads to:

warnings.py:1: UserWarning: you have been warned!
 '''

while runing it with python:

warnings.py:5: UserWarning: you have been warned!
 warnings.warn('you have been warned!')
"
----------------------------------------------



----------------------------------------------
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/20140531/f980fb2a/attachment.html>

From doug.blank at gmail.com  Sat May 31 16:23:12 2014
From: doug.blank at gmail.com (Doug Blank)
Date: Sat, 31 May 2014 10:23:12 -0400
Subject: [Ironpython-users] numpy in IronPython
In-Reply-To: <CAGj3xTsz9dH8OQOM=gg7Q-g00uvBhTWDLfac94Pgx8QuYt1tSw@mail.gmail.com>
References: <CAAusYCi1Cvp8cEEWNv8E8WfYAS0rwPSxJwBaWtPn3wuMxPyg5Q@mail.gmail.com>
 <CAF7AXFGph3FKJiw-x2ogU=tekN25RLqcg3YfJK2OgejiEvRxUQ@mail.gmail.com>
 <CAGj3xTsz9dH8OQOM=gg7Q-g00uvBhTWDLfac94Pgx8QuYt1tSw@mail.gmail.com>
Message-ID: <CAAusYChw5nr+pywOGpsJPbsYejL5ZiAd7qrAW2ArA2BM1JhiZA@mail.gmail.com>

On Fri, May 30, 2014 at 5:22 PM, Steve Baer <steve at mcneel.com> wrote:

> I would definitely be interested in helping, but don't exactly know where
> to start. We have a lot of users who would love to get access to numpy on
> our OSX and 64bit windows versions of our product.  This is only going to
> become a bigger problem in the future since we will probably only have a
> 64bit version for Window in the next version of Rhino.
>

I agree. Let's start a serious discussion about how to solve the lack of
numpy in IronPython.

We could look into using ctypes (IronClad?) and wrap what already exists.

We could look into a cross-platform DLL drop-in replacement.

Between speed and compatibility, initially I'm most interested in
compatibility. But speed should be a long term goal.

We could write a pure-python prototype initially, and slowly move that to
C#, or another CLR language. That would be useful for all non-C-based
Python implementations, and would probably be quickest to write and test.

A related note: Python3 just added a new matrix multiplication operator
[1]. Hope to see more numpy-related functionality in standard Python in the
future.

Other ideas? Where to start?

-Doug

[1] - http://legacy.python.org/dev/peps/pep-0465/


>
> Any suggestions?
>
> -Steve
>
> Steve Baer
> Robert McNeel & Associates
> www.rhino3d.com
>
>
> On Fri, May 30, 2014 at 1:12 PM, Jeff Hardy <jdhardy at gmail.com> wrote:
>
>> On Fri, May 30, 2014 at 2:50 PM, Doug Blank <doug.blank at gmail.com> wrote:
>>
>>> numpy is a numeric package for CPython that used a lot in science.
>>> Wondering about what it would take to develop a numpy for IronPython...
>>>
>>> I know a few years ago that there was a paid project to port numpy to
>>> IronPython [1], but that appears to have been only for Windows, and they
>>> seem to have some unfinished bits. Not sure what the license of that is.
>>>
>>> What to do for numpy IronPython on other platforms?
>>>
>>
>> I think you're out of luck, unfortunately.
>>
>>
>>> PyPy has been working on their numpy for years [2] and have made some
>>> great progress [3].  Would that help a numpy on IronPython?
>>>
>>
>> I'm not sure how the PyPy team is doing the port anymore. At one point I
>> thought they were going to rewrite it in RPython but I don't know if that's
>> the case. I also thought Cython might be involved. Ialso heard that the
>> NumPy team would make their core a plain C library that could be wrapped
>> with ctypes/CFFI. I have no idea if any of those panned out.
>>
>> NumPy (and SciPy/Pandas/etc) is one of those projects I would love to see
>> working but just don't have the time or need to do it myself. Someone else
>> will have to step up to lead that project if it's ever going to get done.
>>
>> - 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/20140531/4e89674a/attachment.html>

From vano at mail.mipt.ru  Sat May 31 17:09:41 2014
From: vano at mail.mipt.ru (Ivan Pozdeev)
Date: Sat, 31 May 2014 19:09:41 +0400
Subject: [Ironpython-users] numpy in IronPython
In-Reply-To: <CAGj3xTsz9dH8OQOM=gg7Q-g00uvBhTWDLfac94Pgx8QuYt1tSw@mail.gmail.com>
References: <CAAusYCi1Cvp8cEEWNv8E8WfYAS0rwPSxJwBaWtPn3wuMxPyg5Q@mail.gmail.com>
 <CAF7AXFGph3FKJiw-x2ogU=tekN25RLqcg3YfJK2OgejiEvRxUQ@mail.gmail.com>
 <CAGj3xTsz9dH8OQOM=gg7Q-g00uvBhTWDLfac94Pgx8QuYt1tSw@mail.gmail.com>
Message-ID: <941583953.20140531190941@mail.mipt.ru>

> I would definitely be interested in helping, but don't exactly know where to start. We have a lot of users who would
> love to get access to numpy on our OSX and 64bit windows versions of our product. ?This is only going to become a
> bigger problem in the future since we will probably only have a 64bit version for Window in the next version of Rhino.
>  

> Any suggestions?

Host it in a CPython instance and use through smth like rpyc.
IMO that's good enough if it's so critical to have that functionality.

After all, numpy is specifically designed for performance and memory-efficiency on large data sets.
Why even consider moving it to an IL environment infested with metadata and safety checks?

> -Steve

> Steve Baer
> Robert McNeel & Associates
> www.rhino3d.com  


> On Fri, May 30, 2014 at 1:12 PM, Jeff Hardy <jdhardy at gmail.com> wrote:

>  
> On Fri, May 30, 2014 at 2:50 PM, Doug Blank <doug.blank at gmail.com> wrote:
>   
> numpy is a numeric package for CPython that used a lot in science. Wondering about what it would take to develop a numpy for IronPython...


> I know a few years ago that there was a paid project to port numpy to IronPython [1], but that appears to have been
> only for Windows, and they seem to have some unfinished bits. Not sure what the license of that is.   


> What to do for numpy IronPython on other platforms??



> I think you're out of luck, unfortunately.
> ?
>   
> PyPy has been working on their numpy for years [2] and have made some great progress [3]. ?Would that help a numpy on IronPython?




> I'm not sure how the PyPy team is doing the port anymore. At one point I thought they were going to rewrite it in
> RPython but I don't know if that's the case. I also thought Cython might be involved. Ialso heard that the NumPy team
> would make their core a plain C library that could be wrapped with ctypes/CFFI. I have no idea if any of those panned out.


> NumPy (and SciPy/Pandas/etc) is one of those projects I would love to see working but just don't have the time or
> need to do it myself. Someone else will have to step up to lead that project if it's ever going to get done.  


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





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


From hfoffani at gmail.com  Sat May 31 18:04:37 2014
From: hfoffani at gmail.com (Hernan M. F.)
Date: Sat, 31 May 2014 18:04:37 +0200
Subject: [Ironpython-users] numpy in IronPython
In-Reply-To: <CAAusYChw5nr+pywOGpsJPbsYejL5ZiAd7qrAW2ArA2BM1JhiZA@mail.gmail.com>
References: <CAAusYCi1Cvp8cEEWNv8E8WfYAS0rwPSxJwBaWtPn3wuMxPyg5Q@mail.gmail.com>
 <CAF7AXFGph3FKJiw-x2ogU=tekN25RLqcg3YfJK2OgejiEvRxUQ@mail.gmail.com>
 <CAGj3xTsz9dH8OQOM=gg7Q-g00uvBhTWDLfac94Pgx8QuYt1tSw@mail.gmail.com>
 <CAAusYChw5nr+pywOGpsJPbsYejL5ZiAd7qrAW2ArA2BM1JhiZA@mail.gmail.com>
Message-ID: <D954E54A-11BF-4863-8785-FBD21FA9C539@gmail.com>

> I would definitely be interested in helping, but don't exactly know where to start. We have a lot of users who would love to get access to numpy on our OSX and 64bit windows versions of our product.  This is only going to become a bigger problem in the future since we will probably only have a 64bit version for Window in the next version of Rhino.
> 
> I agree. Let's start a serious discussion about how to solve the lack of numpy in IronPython.
> 
> We could look into using ctypes (IronClad?) and wrap what already exists.
> 
> We could look into a cross-platform DLL drop-in replacement. 
> 
> Between speed and compatibility, initially I'm most interested in compatibility. But speed should be a long term goal. 


I concur. Given the wide range of third party science and math libraries that uses numpy, completeness will bring us a good start even if it implies paying a high price on speed.


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