From pawel.jasinski at gmail.com  Wed Jan  1 17:42:04 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Wed, 1 Jan 2014 16:42:04 +0000
Subject: [Ironpython-users] __future__.py
Message-ID: <CA+7conkNQCGv6Eeg-c_=gqUh6rcxd4Z5yLkgSMBFrkvoR3xTTA@mail.gmail.com>

hi,

There is a special version of __future__.py in
IronLanguages/Languages/IronPython/IronPython/Lib which is getting in
my way when running out of the development environment.

I wonder why is it there?

--pawel

From no_reply at codeplex.com  Thu Jan  2 09:20:11 2014
From: no_reply at codeplex.com (CodePlex)
Date: 2 Jan 2014 00:20:11 -0800
Subject: [Ironpython-users] IronPython, Daily Digest 1/1/2014
Message-ID: <CO1MSDNADMCDS2VzrAS000136db@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New issue] subprocess.Popen should accept os.environ as env argument

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

ISSUES

1. [New issue] subprocess.Popen should accept os.environ as env argument
http://ironpython.codeplex.com/workitem/34837
User paweljasinski has proposed the issue:

"the following is not possible in IronPython but works in cpython
>>> import os
>>> import subprocess
>>> subprocess.Popen("command.com",env=os.environ)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\rejap\IronPython27\Lib\subprocess.py", line 675, in __init__
  File "C:\Users\rejap\IronPython27\Lib\subprocess.py", line 887, in _execute_child
TypeError: expected dict, got instance
>>>
"
----------------------------------------------



----------------------------------------------
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/20140102/7b01d769/attachment.html>

From pawel.jasinski at gmail.com  Fri Jan  3 03:40:30 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Fri, 3 Jan 2014 02:40:30 +0000
Subject: [Ironpython-users] ipython with notepad
Message-ID: <CA+7conmxQFsk_2Q6RedPpBAoygX0xG7LQtOhB3QFY116zjOWqQ@mail.gmail.com>

hi,

I managed to get ipython notepad to work.
For anybody interested, you need:
- jinja2
- MarkupSafe
- tornado (https://github.com/paweljasinski/tornado/tree/iron-wip)
- zmq (https://github.com/paweljasinski/pyzmq/tree/iron)
- ipython (https://github.com/paweljasinski/ipython)
- ironpython (https://github.com/paweljasinski/IronLanguages/tree/ipython-notepad)

--pawel

From no_reply at codeplex.com  Fri Jan  3 09:25:38 2014
From: no_reply at codeplex.com (CodePlex)
Date: 3 Jan 2014 00:25:38 -0800
Subject: [Ironpython-users] IronPython, Daily Digest 1/2/2014
Message-ID: <CO1MSDNADMCDS2bXCH5000151ca@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New issue] multiple calls to ctype.windll.kernel32.CreateEvent fails

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

ISSUES

1. [New issue] multiple calls to ctype.windll.kernel32.CreateEvent fails
http://ironpython.codeplex.com/workitem/34839
User paweljasinski has proposed the issue:

"When definition of the structure used as a parameter is recreated before the call, second and following call fail. Test:
import ctypes
def create_interrupt_event():
    class SECURITY_ATTRIBUTES(ctypes.Structure):
        _fields_ = [ ("nLength", ctypes.c_int),
            ("lpSecurityDescriptor", ctypes.c_void_p),
            ("bInheritHandle", ctypes.c_int) ]

    sa = SECURITY_ATTRIBUTES()
    sa_p = ctypes.pointer(sa)
    sa.nLength = ctypes.sizeof(SECURITY_ATTRIBUTES)
    sa.lpSecurityDescriptor = 0
    sa.bInheritHandle = 1

    return ctypes.windll.kernel32.CreateEventA(
        sa_p,  # lpEventAttributes
        False, # bManualReset
        False, # bInitialState
        '')    # lpName
print "firs call with success"
print create_interrupt_event()
print "second call fails"
print create_interrupt_event()

output:
firs call with success
884
second call fails
Traceback (most recent call last):
  File "create-event.py", line 22, in <module>
  File "create-event.py", line 14, in create_interrupt_event
_ctypes.ArgumentError: expected LP_SECURITY_ATTRIBUTES, got LP_SECURITY_ATTRIBUTES

Workaround, move definition of the parameter structure to the module scope"
----------------------------------------------



----------------------------------------------
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/20140103/ea5fa619/attachment.html>

From pawel.jasinski at gmail.com  Sat Jan  4 03:15:42 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Sat, 4 Jan 2014 02:15:42 +0000
Subject: [Ironpython-users] identifying cli implementation
Message-ID: <CA+7conkF6d8jO9S+dbuUjvEORZT78Q3HaiNUxQWeSE-K5=nuxw@mail.gmail.com>

hi,

until now, to detect IronPython I have checked sys.platform == 'cli'
Now I need to distinguish between .net and mono.
The check candidate is os.name, but is there a better one?

--pawel

From vilibald.wanca at gmail.com  Sun Jan  5 00:39:04 2014
From: vilibald.wanca at gmail.com (Vilibald Wanca)
Date: Sun, 05 Jan 2014 00:39:04 +0100
Subject: [Ironpython-users] identifying cli implementation
In-Reply-To: <CA+7conkF6d8jO9S+dbuUjvEORZT78Q3HaiNUxQWeSE-K5=nuxw@mail.gmail.com>
References: <CA+7conkF6d8jO9S+dbuUjvEORZT78Q3HaiNUxQWeSE-K5=nuxw@mail.gmail.com>
Message-ID: <52C89B98.3040503@gmail.com>

Hi,

> until now, to detect IronPython I have checked sys.platform == 'cli'
> Now I need to distinguish between .net and mono.
> The check candidate is os.name, but is there a better one?

I'd rely on official approach from mono:

http://www.mono-project.com/FAQ:_Technical#How_can_I_detect_if_am_running_in_Mono.3F

How can I detect if am running in Mono?
---------

using System;

class Program {
     static void Main ()
     {
         Type t = Type.GetType ("Mono.Runtime");
         if (t != null)
              Console.WriteLine ("You are running with the Mono VM");
         else
              Console.WriteLine ("You are running something else");
     }
}
------------

Regards,

vilibald

From no_reply at codeplex.com  Sun Jan  5 09:20:02 2014
From: no_reply at codeplex.com (CodePlex)
Date: 5 Jan 2014 00:20:02 -0800
Subject: [Ironpython-users] IronPython, Daily Digest 1/4/2014
Message-ID: <CO1MSDNADMCDS2ad2Vq00018d69@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New issue] unicode.encode() returns wrong type

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

ISSUES

1. [New issue] unicode.encode() returns wrong type
http://ironpython.codeplex.com/workitem/34842
User bdarnell has proposed the issue:

"IronPython (2.7.4) has both unicode and byte strings, with str as an alias for unicode (python 3 style) instead of bytes (as it is in cpython 2.7).  So far so good.  However, the encode/decode methods for converting between the two don't work as expected:  u'\u00e9'.encode('utf8') returns the unicode string '\xc3\xa9', instead of a byte string (bytes.decode('utf8') returns a unicode string as expected).  This means it is impossible to use isinstance(s, unicode) to determine whether you are dealing with a unicode string that needs to be encoded or a byte string that has already been encoded.

This isinstance pattern is used extensively in some Python libraries (e.g. Tornado), so these libraries cannot be used with IronPython unless this is fixed.  unicode.encode() should always return byte strings.  bytes.decode() should mostly return unicode strings (which it already does) except for a few bytes-to-bytes oddities like the base64 codec (which were removed in python 3)."
----------------------------------------------



----------------------------------------------
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/20140105/34074dfd/attachment.html>

From lchaplin13 at gmail.com  Sun Jan  5 00:32:26 2014
From: lchaplin13 at gmail.com (Lee Chaplin)
Date: Sun, 5 Jan 2014 12:32:26 +1300
Subject: [Ironpython-users] out, in and byref
Message-ID: <CAJ_5dtpNsrh-fo7OKssuw82oN=5Y9xK0NNEXvPvbD3+RytHGvQ@mail.gmail.com>

Hi,

I am trying to understand IPY by converting some VB.NET code to IPY and I
am stuck at some in/out and byref code.
In summary in VB I've got the line:

Call objEdge.GetFaces(NumFaces:=lngNumFaces, Faces:=objFaces)
where
Dim objFaces(1 To 2) As Geometry.Face
Dim lngNumFaces As Long
Public Sub GetFaces(ByRef *NumFaces* As Long, ByRef *Faces*() As Object)

ILSpy tells me that GetFaces (in a third party lib) has the definition (VB):
Sub GetFaces(<Out()> ByRef NumFaces As Integer,
<MarshalAs(UnmanagedType.SafeArray, SafeArraySubType =
VarEnum.VT_DISPATCH)> <[In]()> <Out()> ByRef Faces As Array)

I tried this
    NumFaces = clr.Reference[float](2)
    objFaces = clr.Reference[System.Array[Geometry.Face]]((None,None))  #?
    NumFaces, objFaces = objEdge.GetFaces(NumFaces, objFaces)

but I've got an error saying:
Could not convert argument 1 for call to GetFaces.

Any help is greatly appreciated.

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

From jdhardy at gmail.com  Mon Jan  6 00:18:50 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sun, 5 Jan 2014 23:18:50 +0000
Subject: [Ironpython-users] identifying cli implementation
In-Reply-To: <52C89B98.3040503@gmail.com>
References: <CA+7conkF6d8jO9S+dbuUjvEORZT78Q3HaiNUxQWeSE-K5=nuxw@mail.gmail.com>
 <52C89B98.3040503@gmail.com>
Message-ID: <CAF7AXFEy5u8iiQ-f-x=y5PZOxr2NP-2Z95HTEtJK_3X0pOGtgQ@mail.gmail.com>

If os.name == 'posix' then you're on Mono (or some bizarro world where
MS has a Unix .NET impl), but Mono on Windows will still have os.name
== 'nt'. Vilibald's suggestion will work for now but it would be nice
to have an easily usable built in under sys.implementation.

- Jeff

On Sat, Jan 4, 2014 at 11:39 PM, Vilibald Wanca
<vilibald.wanca at gmail.com> wrote:
> Hi,
>
>> until now, to detect IronPython I have checked sys.platform == 'cli'
>> Now I need to distinguish between .net and mono.
>> The check candidate is os.name, but is there a better one?
>
>
> I'd rely on official approach from mono:
>
> http://www.mono-project.com/FAQ:_Technical#How_can_I_detect_if_am_running_in_Mono.3F
>
> How can I detect if am running in Mono?
> ---------
>
> using System;
>
> class Program {
>     static void Main ()
>     {
>         Type t = Type.GetType ("Mono.Runtime");
>         if (t != null)
>              Console.WriteLine ("You are running with the Mono VM");
>         else
>              Console.WriteLine ("You are running something else");
>     }
> }
> ------------
>
> Regards,
>
> vilibald
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users

From no_reply at codeplex.com  Mon Jan  6 09:20:07 2014
From: no_reply at codeplex.com (CodePlex)
Date: 6 Jan 2014 00:20:07 -0800
Subject: [Ironpython-users] IronPython, Daily Digest 1/5/2014
Message-ID: <CO1MSDNADMCDS2YQYx300019f5d@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] json.dump fails to dump Unicode strings
2. [New comment] unicode.encode() returns wrong type
3. [New comment] unicode.encode() returns wrong type
4. [New comment] unicode.encode() returns wrong type

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

ISSUES

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

"<p>workaround: https://github.com/paweljasinski/IronLanguages/commit/365933a00d1a1b65e7bc06ee6dec660f07d9923d</p>"-----------------

2. [New comment] unicode.encode() returns wrong type
http://ironpython.codeplex.com/workitem/34842
User paweljasinski has commented on the issue:

"<p>Can you give me exact problem with tornado (preferred on the mailing list). I have been tinkering with it recently (https://github.com/paweljasinski/tornado/compare/facebook:branch3.1...iron-wip) and got reasonable results with ipython notebook.</p><p>From what I can see there are the following instances of the pattern (tornado uses unicode_type, not unicode directly):<br>```<br>auth.py:1008:            if isinstance(extended_permissions, (unicode_type, bytes_type)):<br>auth.py:1145:        if isinstance(body, unicode_type):<br>auth.py:1362:    if isinstance(val, unicode_type):<br>escape.py:191:    assert isinstance(value, unicode_type), \<br>test/locale_test.py:49:        self.assertTrue(isinstance(name, unicode_type))<br>util.py:211:        if isinstance(impl, (unicode_type, bytes_type)):<br>web.py:322:        elif isinstance(value, unicode_type):<br>web.py:370:            if isinstance(v, unicode_type):<br>web.py:554:                if isinstance(file_part, (unicode_type, bytes_type)):<br>web.py:563:                if isinstance(file_part, (unicode_type, bytes_type)):<br>web.py:2401:            if isinstance(f, (unicode_type, bytes_type)):<br>web.py:2413:            if isinstance(f, (unicode_type, bytes_type)):<br>web.py:2512:            if not isinstance(a, (unicode_type, bytes_type)):<br>websocket.py:464:        if isinstance(message, unicode_type):<br>```<br>After we take out all of unicode_type or bytes_type, which are not what you are talking about, there are:<br>```<br>auth.py:1145:        if isinstance(body, unicode_type):<br>auth.py:1362:    if isinstance(val, unicode_type):<br>escape.py:191:    assert isinstance(value, unicode_type), \<br>test/locale_test.py:49:        self.assertTrue(isinstance(name, unicode_type))<br>web.py:322:        elif isinstance(value, unicode_type):<br>web.py:370:            if isinstance(v, unicode_type):<br>websocket.py:464:        if isinstance(message, unicode_type):<br>```<br>we have 7 hits.<br>I looked at first 2 and from what I can tell, pattern is not to avoid double encoding of strings, but to make sure nothing bigger than 255 is passed down. In case of misdiagnosed ascii strings it makes no harm.</p><p>From my experience the real show stopper is here: https://ironpython.codeplex.com/workitem/32331</p><p> <br></p>"-----------------

3. [New comment] unicode.encode() returns wrong type
http://ironpython.codeplex.com/workitem/34842
User bdarnell has commented on the issue:

"<p>The main issue is tornado.escape.utf8, which calls .encode('utf8') on unicode strings and does nothing for byte strings.  This is used often in tornado code and is expected to be idempotent, but on IronPython it is not.</p>"-----------------

4. [New comment] unicode.encode() returns wrong type
http://ironpython.codeplex.com/workitem/34842
User paweljasinski has commented on the issue:

"<p>after applying the following to json/encode.py I can even round trip umlauts in notebook.<br>```<br>+++ b/External.LCA_RESTRICTED/Languages/IronPython/27/Lib/json/encoder.py<br>@@ -45,7 +45,11 @@ def py_encode_basestring_ascii(s):</p><p>     &quot;&quot;&quot;<br>     if isinstance(s, str) and HAS_UTF8.search(s) is not None:<br>-        s = s.decode('utf-8')<br>+        try:<br>+            s = s.decode('utf-8')<br>+        except UnicodeDecodeError as ex:<br>+            print &quot;ignoring %s&quot; % ex<br>+            pass<br>     def replace(match):<br>         s = match.group(0)<br>         try:<br>```<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/20140106/2560477b/attachment.html>

From no_reply at codeplex.com  Tue Jan  7 09:21:01 2014
From: no_reply at codeplex.com (CodePlex)
Date: 7 Jan 2014 00:21:01 -0800
Subject: [Ironpython-users] IronPython, Daily Digest 1/6/2014
Message-ID: <CO1MSDNADMCDS2DlrMi0001d143@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] unicode.encode() returns wrong type
2. [New issue] top level exception handler of the interpreter prints wrong traceback

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

ISSUES

1. [New comment] unicode.encode() returns wrong type
http://ironpython.codeplex.com/workitem/34842
User paweljasinski has commented on the issue:

"<p>I have to agree there is no way to make all test cases pass, particularly escape_test is hitting the limits you mentioned.<br>However, I think it is far from &quot;can not be used with ironpython&quot;. I have a dirty version (https://github.com/paweljasinski/tornado/compare/facebook:branch3.1...httpserver-ip-hack) which passes HTTPConnectionTest, HTTPServerRawTest, HTTPServerTest, KeepAliveTest, ManualProtocolTest.</p><p>So far I have taken the &quot;2.7&quot; approach and try to deal with differences individually. It possible to chose &quot;3.x&quot;. The consequence is that all stdlib (including build-ins) must act as in 3.x. Of course one of them is encode.</p>"-----------------

2. [New issue] top level exception handler of the interpreter prints wrong traceback
http://ironpython.codeplex.com/workitem/34849
User paweljasinski has proposed the issue:

"In the following snipped, it is expected that stacktrace of the last f3() invocation includes f1, f2 and f3
import sys
import traceback

def f1():
    raise Exception("test exception")

def f2():
    f1()

def f3():
    f2()

def t1():
    e = None
    try:
        f3()
    except:
        e = sys.exc_info()
        print "-"*80
        print traceback.print_exception(e[0], e[1], e[2])
    return e

def t2():
    e = t1()
    raise e[0], e[1], e[2]

def t3():
    t2()

try:
    t3()
except:
    print "-"*80
    e = sys.exc_info()
    print traceback.print_exception(e[0], e[1], e[2])

print "="*80
t3()
"
----------------------------------------------



----------------------------------------------
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/20140107/94fbec83/attachment.html>

From jdhardy at gmail.com  Tue Jan  7 16:53:07 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Tue, 7 Jan 2014 15:53:07 +0000
Subject: [Ironpython-users] __future__.py
In-Reply-To: <CA+7conkNQCGv6Eeg-c_=gqUh6rcxd4Z5yLkgSMBFrkvoR3xTTA@mail.gmail.com>
References: <CA+7conkNQCGv6Eeg-c_=gqUh6rcxd4Z5yLkgSMBFrkvoR3xTTA@mail.gmail.com>
Message-ID: <CAF7AXFEb+d6EHK9qnEua_E5fzpoK==Lbex-0M0WuwN=49nXGpg@mail.gmail.com>

On Wed, Jan 1, 2014 at 4:42 PM, Pawel Jasinski <pawel.jasinski at gmail.com> wrote:
> hi,
>
> There is a special version of __future__.py in
> IronLanguages/Languages/IronPython/IronPython/Lib which is getting in
> my way when running out of the development environment.
>
> I wonder why is it there?

Historical reasons, maybe? I added Dino to see if he knows.

- Jeff

From jdhardy at gmail.com  Tue Jan  7 16:58:33 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Tue, 7 Jan 2014 15:58:33 +0000
Subject: [Ironpython-users] ipython with notepad
In-Reply-To: <CA+7conmxQFsk_2Q6RedPpBAoygX0xG7LQtOhB3QFY116zjOWqQ@mail.gmail.com>
References: <CA+7conmxQFsk_2Q6RedPpBAoygX0xG7LQtOhB3QFY116zjOWqQ@mail.gmail.com>
Message-ID: <CAF7AXFGE9Cf-8cThBXQJz3CNFVs-u6fCu+42M0HQLid3hvzcWA@mail.gmail.com>

Fantastic!!

Once I get recovered from the move and the new job I'll take a look.

- Jeff

On Fri, Jan 3, 2014 at 2:40 AM, Pawel Jasinski <pawel.jasinski at gmail.com> wrote:
> hi,
>
> I managed to get ipython notepad to work.
> For anybody interested, you need:
> - jinja2
> - MarkupSafe
> - tornado (https://github.com/paweljasinski/tornado/tree/iron-wip)
> - zmq (https://github.com/paweljasinski/pyzmq/tree/iron)
> - ipython (https://github.com/paweljasinski/ipython)
> - ironpython (https://github.com/paweljasinski/IronLanguages/tree/ipython-notepad)
>
> --pawel
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users

From rahulg1190 at gmail.com  Tue Jan  7 18:12:15 2014
From: rahulg1190 at gmail.com (Rahul Gupta)
Date: Tue, 7 Jan 2014 22:42:15 +0530
Subject: [Ironpython-users] Developing Windows Store Apps using Python
Message-ID: <CADSxiBPNdGxn=dUL5ZEMziwZsxCe-edzk_3OtuRH0_ejPQ8SYg@mail.gmail.com>

Hi Folks,

I am trying to figure out if there is anyway by which i can build a Windows
Store App using Python. I have browsed through the web extensively and
can't seem to find any resources for the same. Any pointers would be
tremendously appreciated.

Thanks,
Rahul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140107/0f5e2c14/attachment.html>

From no_reply at codeplex.com  Thu Jan  9 09:22:38 2014
From: no_reply at codeplex.com (CodePlex)
Date: 9 Jan 2014 00:22:38 -0800
Subject: [Ironpython-users] IronPython, Daily Digest 1/8/2014
Message-ID: <CO1MSDNADMCDS2IhA1q000211ed@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New issue] Unhandled traceback does not end with newline

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

ISSUES

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

"When a process exists with an unhandled exception, the traceback does not have a newline at the end. This affects the following line of output or the subsequent prompt. For example:
Traceback (most recent call last):
  File "c:\ . . . \IronPythonApplication1\IronPythonApplication1.py", line 1, in <module>
TypeError: exceptions must be classes, or instances, not strPress any key to continue . . .

Expected:
Traceback (most recent call last):
  File "c:\ . . . \IronPythonApplication1\IronPythonApplication1.py", line 1, in <module>
TypeError: exceptions must be classes, or instances, not str
Press any key to continue . . .
"
----------------------------------------------



----------------------------------------------
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/20140109/35f53a39/attachment.html>

From no_reply at codeplex.com  Sun Jan 12 09:19:55 2014
From: no_reply at codeplex.com (CodePlex)
Date: 12 Jan 2014 00:19:55 -0800
Subject: [Ironpython-users] IronPython, Daily Digest 1/11/2014
Message-ID: <CO1MSDNADMCDS2KkCZx00026d18@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New issue] System.Windows.Threading.DispatcherTimer not working in IronPython

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

ISSUES

1. [New issue] System.Windows.Threading.DispatcherTimer not working in IronPython
http://ironpython.codeplex.com/workitem/34877
User adnanumer has proposed the issue:

"System.Windows.Threading.DispatcerTimer doesn't tick in IronPython.

Snapshot is attached. Timer Interval is one second however after 1 minute value of global variable 'i' remains unchanged also nothing prints out."
----------------------------------------------



----------------------------------------------
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/20140112/4bfcb585/attachment.html>

From no_reply at codeplex.com  Tue Jan 14 09:20:36 2014
From: no_reply at codeplex.com (CodePlex)
Date: 14 Jan 2014 00:20:36 -0800
Subject: [Ironpython-users] IronPython, Daily Digest 1/13/2014
Message-ID: <CO1MSDNADMCDS2PGNkY0002b3bf@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] System.Windows.Threading.DispatcherTimer not working in IronPython

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

ISSUES

1. [New comment] System.Windows.Threading.DispatcherTimer not working in IronPython
http://ironpython.codeplex.com/workitem/34877
User MarkusSchaber has commented on the issue:

"<p>As far as I can see, the DispatcherTimer is &quot;fired&quot; from within the WPF Thread Dispatcher loop. The normal IronPython console just sits there, waiting for input from the command line, and is never executing the WPF Dispatcher (why should it?).</p><p>You should be able to get the same behaviour with a C# or VB console application which just sits there using Thread.Sleep() or Console.ReadLine().</p><p></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/20140114/5071d381/attachment.html>

From no_reply at codeplex.com  Wed Jan 15 09:23:29 2014
From: no_reply at codeplex.com (CodePlex)
Date: 15 Jan 2014 00:23:29 -0800
Subject: [Ironpython-users] IronPython, Daily Digest 1/14/2014
Message-ID: <CO1MSDNADMCDS2cDjoY0002de10@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New issue] ctypes.memmove doesn't tolerate 0 size

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

ISSUES

1. [New issue] ctypes.memmove doesn't tolerate 0 size
http://ironpython.codeplex.com/workitem/34892
User paweljasinski has proposed the issue:

"from ctypes import *
src = b''
dest = create_string_buffer(0)
memmove(dest, src, 0)

works on cpython, but created exception on ip:
Traceback (most recent call last):
  File "ctypes-memmove.py", line 4, in <module>
IndexError: Index was outside the bounds of the array.
"
----------------------------------------------



----------------------------------------------
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/20140115/b9c3622e/attachment.html>

From no_reply at codeplex.com  Thu Jan 16 09:20:37 2014
From: no_reply at codeplex.com (CodePlex)
Date: 16 Jan 2014 00:20:37 -0800
Subject: [Ironpython-users] IronPython, Daily Digest 1/15/2014
Message-ID: <CO1MSDNADMCDS23cJab00030358@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] Conflict with ExtensionAttribute in ASP.NET 3.5 website
2. [New issue] StackOverflow when enumerating dynamic members of IMOs

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

ISSUES

1. [New comment] Conflict with ExtensionAttribute in ASP.NET 3.5 website
http://ironpython.codeplex.com/workitem/19126
User sbronson has commented on the issue:

"<p>Why is this closed if people are still having this issue? (And they are: see &lt;http://stackoverflow.com/questions/835592/ambigious-reference-for-extensionattribute-when-using-iron-python-in-asp-net&gt;.)</p>"-----------------

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

"Tested on IronPyton 2.7.4

import System
import clr
clr.AddReference("System.Core")
from System.Dynamic import DynamicObject

class Foo(DynamicObject):
  def bar():
      pass


f = Foo()
System.ComponentModel.TypeDescriptor.GetProperties(f)"
----------------------------------------------



----------------------------------------------
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/20140116/d0071b9c/attachment.html>

From bernd.viehmann at googlemail.com  Fri Jan 17 08:15:00 2014
From: bernd.viehmann at googlemail.com (Bernd Viehmann)
Date: Fri, 17 Jan 2014 08:15:00 +0100
Subject: [Ironpython-users] Build-Problem : ASP.NET with IronPython 2.7.4
Message-ID: <CAOi=b4StJ2KXBkdfD9jD61z2NHke4gubcea5QrN3kGMdT2rqnw@mail.gmail.com>

Hi,

i am playing and have tried to create an ASP.NET project with IronPython
2.7.4. I have copied the dlls to the bin-folder in my project. But in the
platform-folder of the 2.7.4. version there is dll missing:
Microsoft.Web.Scripting.

This dll is used in the old dynamic.language-support example-project (which
is older now). So when i try to build the project i get an error-message
that the type "Microsoft.Web.Scripting.UI.NoCompileCodePageParserFilter"
could not be loaded.

The Microsoft.Web.Scripting.dll is used several times in the web.config
that i have taken from the older dynamic-lng-spprt example. Here is a list:

    <pages compilationMode="Auto"
pageParserFilterType="Microsoft.Web.Scripting.UI.NoCompileCodePageParserFilter"
pageBaseType="Microsoft.Web.Scripting.UI.ScriptPage"
userControlBaseType="Microsoft.Web.Scripting.UI.ScriptUserControl">
      <controls>
        <add tagPrefix="asp" namespace="System.Web.UI"
assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35"/>
        <add tagPrefix="asp" namespace="System.Web.UI.WebControls"
assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35"/>
      </controls>
    </pages>

    <httpModules>
      <add name="DynamicLanguageHttpModule"
type="Microsoft.Web.Scripting.DynamicLanguageHttpModule"/>
      <add name="ScriptModule" type="System.Web.Handlers.ScriptModule,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35"/>
    </httpModules>


    <modules>
      <remove name="ScriptModule"/>
      <add name="ScriptModule" preCondition="managedHandler"
type="System.Web.Handlers.ScriptModule, System.Web.Extensions,
Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
      <add name="DynamicLanguageHttpModule" preCondition="integratedMode"
type="Microsoft.Web.Scripting.DynamicLanguageHttpModule"/>
    </modules>


does somebody fixed that? is the dll not longer used and i have to make
some changes in my web.config ? or is there an upgrade for this dll?

thanks much for your help and kind regards

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

From jdhardy at gmail.com  Fri Jan 17 09:42:00 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 17 Jan 2014 08:42:00 +0000
Subject: [Ironpython-users] Build-Problem : ASP.NET with IronPython 2.7.4
In-Reply-To: <CAOi=b4StJ2KXBkdfD9jD61z2NHke4gubcea5QrN3kGMdT2rqnw@mail.gmail.com>
References: <CAOi=b4StJ2KXBkdfD9jD61z2NHke4gubcea5QrN3kGMdT2rqnw@mail.gmail.com>
Message-ID: <CAF7AXFE32SamiORAdu6SMFuuO8wYxX_AZUjXjCtDaCg414S8fg@mail.gmail.com>

I don't actually know where that DLL comes from. I thought all of the
ASP.NET support was in Microsoft.Scripting.AspNet, so you could see of
those types are in there.

- Jeff

On Fri, Jan 17, 2014 at 7:15 AM, Bernd Viehmann
<bernd.viehmann at googlemail.com> wrote:
> Hi,
>
> i am playing and have tried to create an ASP.NET project with IronPython
> 2.7.4. I have copied the dlls to the bin-folder in my project. But in the
> platform-folder of the 2.7.4. version there is dll missing:
> Microsoft.Web.Scripting.
>
> This dll is used in the old dynamic.language-support example-project (which
> is older now). So when i try to build the project i get an error-message
> that the type "Microsoft.Web.Scripting.UI.NoCompileCodePageParserFilter"
> could not be loaded.
>
> The Microsoft.Web.Scripting.dll is used several times in the web.config that
> i have taken from the older dynamic-lng-spprt example. Here is a list:
>
>     <pages compilationMode="Auto"
> pageParserFilterType="Microsoft.Web.Scripting.UI.NoCompileCodePageParserFilter"
> pageBaseType="Microsoft.Web.Scripting.UI.ScriptPage"
> userControlBaseType="Microsoft.Web.Scripting.UI.ScriptUserControl">
>       <controls>
>         <add tagPrefix="asp" namespace="System.Web.UI"
> assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
> PublicKeyToken=31BF3856AD364E35"/>
>         <add tagPrefix="asp" namespace="System.Web.UI.WebControls"
> assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
> PublicKeyToken=31BF3856AD364E35"/>
>       </controls>
>     </pages>
>
>     <httpModules>
>       <add name="DynamicLanguageHttpModule"
> type="Microsoft.Web.Scripting.DynamicLanguageHttpModule"/>
>       <add name="ScriptModule" type="System.Web.Handlers.ScriptModule,
> System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
> PublicKeyToken=31BF3856AD364E35"/>
>     </httpModules>
>
>
>     <modules>
>       <remove name="ScriptModule"/>
>       <add name="ScriptModule" preCondition="managedHandler"
> type="System.Web.Handlers.ScriptModule, System.Web.Extensions,
> Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
>       <add name="DynamicLanguageHttpModule" preCondition="integratedMode"
> type="Microsoft.Web.Scripting.DynamicLanguageHttpModule"/>
>     </modules>
>
>
> does somebody fixed that? is the dll not longer used and i have to make some
> changes in my web.config ? or is there an upgrade for this dll?
>
> thanks much for your help and kind regards
>
> Bernd
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>

From bernd.viehmann at googlemail.com  Fri Jan 17 10:28:18 2014
From: bernd.viehmann at googlemail.com (Bernd Viehmann)
Date: Fri, 17 Jan 2014 10:28:18 +0100
Subject: [Ironpython-users] Build-Problem : ASP.NET with IronPython 2.7.4
In-Reply-To: <CAF7AXFE32SamiORAdu6SMFuuO8wYxX_AZUjXjCtDaCg414S8fg@mail.gmail.com>
References: <CAOi=b4StJ2KXBkdfD9jD61z2NHke4gubcea5QrN3kGMdT2rqnw@mail.gmail.com>
 <CAF7AXFE32SamiORAdu6SMFuuO8wYxX_AZUjXjCtDaCg414S8fg@mail.gmail.com>
Message-ID: <CAOi=b4QGrsqMf0XfWs0qo9CXMynP8MthSpbwJ1hWs5yj6B5HKw@mail.gmail.com>

Hi, Jeff.

I have tried this. I also found an remark on the blog of Jimmy Schementi.
He says that you just have to rename Microsoft.Web.Scripting to
Microsoft.Scripting.AspNet. But now it throws an exception when
initialising the type "Microsoft.Scripting.AspNet.EngineHelper".

Jimmy wrote:

Background

This download enables IronPython as an ASP.NET programming
language<http://www.asp.net/dynamiclanguages>.
To create a new IronPython ASP.NET WebForms project, simply copy
examples\web.config and examples\bin, and use
examples\hello-webforms.aspxas a reference. A redistributed copy of
the IronPython 2.7 Alpha 1 binaries
can be found in the examples\bin directory; all files except
Microsoft.Scripting.AspNet.dll, the IronPython ASP.NET integration, are
from the IronPython 2.7 Alpha 1 release.

For more detail on getting started, here?s a simple walk-through of making
the ?hello-webforms?
app<http://blog.jimmy.schementi.com/2008/09/aspnet-dynamic-language-support.html>
.


I will try it with a question in the ASP.NET Forum. Thanxx much, Jeff :-)


2014/1/17 Jeff Hardy <jdhardy at gmail.com>

> I don't actually know where that DLL comes from. I thought all of the
> ASP.NET support was in Microsoft.Scripting.AspNet, so you could see of
> those types are in there.
>
> - Jeff
>
> On Fri, Jan 17, 2014 at 7:15 AM, Bernd Viehmann
> <bernd.viehmann at googlemail.com> wrote:
> > Hi,
> >
> > i am playing and have tried to create an ASP.NET project with IronPython
> > 2.7.4. I have copied the dlls to the bin-folder in my project. But in the
> > platform-folder of the 2.7.4. version there is dll missing:
> > Microsoft.Web.Scripting.
> >
> > This dll is used in the old dynamic.language-support example-project
> (which
> > is older now). So when i try to build the project i get an error-message
> > that the type "Microsoft.Web.Scripting.UI.NoCompileCodePageParserFilter"
> > could not be loaded.
> >
> > The Microsoft.Web.Scripting.dll is used several times in the web.config
> that
> > i have taken from the older dynamic-lng-spprt example. Here is a list:
> >
> >     <pages compilationMode="Auto"
> >
> pageParserFilterType="Microsoft.Web.Scripting.UI.NoCompileCodePageParserFilter"
> > pageBaseType="Microsoft.Web.Scripting.UI.ScriptPage"
> > userControlBaseType="Microsoft.Web.Scripting.UI.ScriptUserControl">
> >       <controls>
> >         <add tagPrefix="asp" namespace="System.Web.UI"
> > assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
> > PublicKeyToken=31BF3856AD364E35"/>
> >         <add tagPrefix="asp" namespace="System.Web.UI.WebControls"
> > assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
> > PublicKeyToken=31BF3856AD364E35"/>
> >       </controls>
> >     </pages>
> >
> >     <httpModules>
> >       <add name="DynamicLanguageHttpModule"
> > type="Microsoft.Web.Scripting.DynamicLanguageHttpModule"/>
> >       <add name="ScriptModule" type="System.Web.Handlers.ScriptModule,
> > System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
> > PublicKeyToken=31BF3856AD364E35"/>
> >     </httpModules>
> >
> >
> >     <modules>
> >       <remove name="ScriptModule"/>
> >       <add name="ScriptModule" preCondition="managedHandler"
> > type="System.Web.Handlers.ScriptModule, System.Web.Extensions,
> > Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
> >       <add name="DynamicLanguageHttpModule" preCondition="integratedMode"
> > type="Microsoft.Web.Scripting.DynamicLanguageHttpModule"/>
> >     </modules>
> >
> >
> > does somebody fixed that? is the dll not longer used and i have to make
> some
> > changes in my web.config ? or is there an upgrade for this dll?
> >
> > thanks much for your help and kind regards
> >
> > Bernd
> >
> > _______________________________________________
> > Ironpython-users mailing list
> > Ironpython-users at python.org
> > https://mail.python.org/mailman/listinfo/ironpython-users
> >
>



-- 

Mit freundlichen Gr??en

Bernd Viehmann
Mahrweg 46
41836 H?ckelhoven

Tel.: 02433 9640 100
Fax: 02433 9640 109
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140117/8d360c2e/attachment.html>

From bernd.viehmann at googlemail.com  Fri Jan 17 10:35:43 2014
From: bernd.viehmann at googlemail.com (Bernd Viehmann)
Date: Fri, 17 Jan 2014 10:35:43 +0100
Subject: [Ironpython-users] multi-core programming with iron-python
Message-ID: <CAOi=b4Qu8bnryhjP9tbxrWnBEsbEKAM_N8=87U0Y5c8r8xu46w@mail.gmail.com>

Hi folks,

in the python wiki i have read the following statement:

" IronPython has *no GIL* and multi-threaded code can use multi core
processors"
https://wiki.python.org/moin/IronPython

Is there anything special to take care off? Or do i just to impotz and use
the thread-module of python. I want to write a script which will read data
from a ado.net data-table in memory. it should be able to use all cores
available on the host.

thanks much and regards

bernd

-- 

Mit freundlichen Gr??en

Bernd Viehmann
Mahrweg 46
41836 H?ckelhoven

Tel.: 02433 9640 100
Fax: 02433 9640 109
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140117/c1b206ce/attachment.html>

From jdhardy at gmail.com  Fri Jan 17 13:36:00 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 17 Jan 2014 12:36:00 +0000
Subject: [Ironpython-users] multi-core programming with iron-python
In-Reply-To: <CAOi=b4Qu8bnryhjP9tbxrWnBEsbEKAM_N8=87U0Y5c8r8xu46w@mail.gmail.com>
References: <CAOi=b4Qu8bnryhjP9tbxrWnBEsbEKAM_N8=87U0Y5c8r8xu46w@mail.gmail.com>
Message-ID: <CAF7AXFGXAiYQss7Pmv7M5kZn4dHnMQqV5UOdHVVLJMAJ7=93bg@mail.gmail.com>

On Fri, Jan 17, 2014 at 9:35 AM, Bernd Viehmann
<bernd.viehmann at googlemail.com> wrote:
> Hi folks,
>
> in the python wiki i have read the following statement:
>
> " IronPython has no GIL and multi-threaded code can use multi core
> processors"
> https://wiki.python.org/moin/IronPython
>
> Is there anything special to take care off? Or do i just to impotz and use
> the thread-module of python. I want to write a script which will read data
> from a ado.net data-table in memory. it should be able to use all cores
> available on the host.

The only special care you have to take is what you normally would when
writing multithreaded code.

If you do hit any issues they might be bugs, so please report what you find.

- Jeff


>
> thanks much and regards
>
> bernd
>
> --
>
> Mit freundlichen Gr??en
>
> Bernd Viehmann
> Mahrweg 46
> 41836 H?ckelhoven
>
> Tel.: 02433 9640 100
> Fax: 02433 9640 109
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>

From rome at Wintellect.com  Fri Jan 17 18:53:02 2014
From: rome at Wintellect.com (Keith Rome)
Date: Fri, 17 Jan 2014 17:53:02 +0000
Subject: [Ironpython-users] multi-core programming with iron-python
In-Reply-To: <CAF7AXFGXAiYQss7Pmv7M5kZn4dHnMQqV5UOdHVVLJMAJ7=93bg@mail.gmail.com>
References: <CAOi=b4Qu8bnryhjP9tbxrWnBEsbEKAM_N8=87U0Y5c8r8xu46w@mail.gmail.com>
 <CAF7AXFGXAiYQss7Pmv7M5kZn4dHnMQqV5UOdHVVLJMAJ7=93bg@mail.gmail.com>
Message-ID: <CEFED6DB.F113%rome@wintellect.com>

You do need to be careful with imports and other global side-effects. The last time I did some threaded work in IP, the dictionary structure that contained the imported modules for the engine was not thread-safe. And I don't recall seeing anything committed that would have changed that. If you pre-import the modules prior to forking then it's fine - using a cached module is OK, it's just adding newly loaded modules to the cache that causes trouble. And I'm sure there are other similar situations.

Actual execution of scripts that are side-effect-free is perfectly fine.


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

[cid:5B509F53-9AEB-4247-A9A4-CA642CCFBCBB]
Register today<https://www.wintellectnow.com/Account/Promo/ROME-13> for access to our high-quality on-demand training resources!

From: Jeff Hardy <jdhardy at gmail.com<mailto:jdhardy at gmail.com>>
Date: Friday, January 17, 2014 at 7:36 AM
To: Bernd Viehmann <bernd.viehmann at googlemail.com<mailto:bernd.viehmann at googlemail.com>>
Cc: "ironpython-users at python.org<mailto:ironpython-users at python.org>" <ironpython-users at python.org<mailto:ironpython-users at python.org>>
Subject: Re: [Ironpython-users] multi-core programming with iron-python

On Fri, Jan 17, 2014 at 9:35 AM, Bernd Viehmann
<bernd.viehmann at googlemail.com<mailto:bernd.viehmann at googlemail.com>> wrote:
Hi folks,

in the python wiki i have read the following statement:

" IronPython has no GIL and multi-threaded code can use multi core
processors"
https://wiki.python.org/moin/IronPython

Is there anything special to take care off? Or do i just to impotz and use
the thread-module of python. I want to write a script which will read data
from a ado.net data-table in memory. it should be able to use all cores
available on the host.

The only special care you have to take is what you normally would when
writing multithreaded code.

If you do hit any issues they might be bugs, so please report what you find.

- Jeff



thanks much and regards

bernd

--

Mit freundlichen Gr??en

Bernd Viehmann
Mahrweg 46
41836 H?ckelhoven

Tel.: 02433 9640 100
Fax: 02433 9640 109

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

_______________________________________________
Ironpython-users mailing list
Ironpython-users at python.org<mailto: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/20140117/fa9193ba/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 529A2558-817C-467F-8E7E-0789B90D675C[18].png
Type: image/png
Size: 6285 bytes
Desc: 529A2558-817C-467F-8E7E-0789B90D675C[18].png
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140117/fa9193ba/attachment.png>

From no_reply at codeplex.com  Sat Jan 18 09:25:53 2014
From: no_reply at codeplex.com (CodePlex)
Date: 18 Jan 2014 00:25:53 -0800
Subject: [Ironpython-users] IronPython, Daily Digest 1/17/2014
Message-ID: <CO1MSDNADMCDS21Gj0300003933@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New issue] os.stat should accept bytes as argument

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

ISSUES

1. [New issue] os.stat should accept bytes as argument
http://ironpython.codeplex.com/workitem/34910
User paweljasinski has proposed the issue:

"cpython 2.7 and 3.3 accept bytes as argument of os.stat, ip doesn't
IronPython 2.7.4 (2.7.0.40) on .NET 4.0.30319.18052 (32-bit)
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.stat(b'/')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected str, got bytes

Python 2.7.4 (default, Sep 26 2013, 03:20:26) 
[GCC 4.7.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.stat(b'/')
posix.stat_result(st_mode=16877, st_ino=2, st_dev=2049L, st_nlink=24, st_uid=0, st_gid=0, st_size=4096, st_atime=1355492921, st_mtime=1388838281, st_ctime=1388838281)

Python 3.3.1 (default, Sep 25 2013, 19:29:01) 
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.stat(b'/')
posix.stat_result(st_mode=16877, st_ino=2, st_dev=2049, st_nlink=24, st_uid=0, st_gid=0, st_size=4096, st_atime=1355492921, st_mtime=1388838281, st_ctime=1388838281)
"
----------------------------------------------



----------------------------------------------
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/20140118/03ee5302/attachment.html>

From pawel.jasinski at gmail.com  Sun Jan 19 12:14:22 2014
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Sun, 19 Jan 2014 11:14:22 +0000
Subject: [Ironpython-users] porting things to ironpython
Message-ID: <CA+7conkwbbk7rmn8GGkry_Ho3-NxS8-7P=nzzJ4m-RRgn9RdxQ@mail.gmail.com>

hi,

I have been playing with some cpython packages and tried to get them
to work under ironpython.
Ironpython, similar to jython, is a hybrid with true unicode strings
(as it is defined in 3.x) and arguments and returned values of
standard library and build-ins conforming to 2.x.

Modules I have tried, have already provisions for 2->3 transition,
which means, that most of the str/unicode/byte differences are already
figured out.
After some try and error, I have chosen to configure existing
compatibility layer to run in 3.x mode and patch api entry/exit
points. As far as I can tell it works but ...
it appears to bit a bit inefficient.

For example, socket.send is a call where 2.x expects str and 3.x bytes.
In my case, buffer to be used for socket.send is being constructed
using bytes, unicodes are encoded as they are appended. In case of
ironpython 2.7, before send can be called, it has to be converted into
string: whatever_bytes.decode('latin-1')
I also explored use of buffer, but internally I can see it performs
redundant string conversion as well.

How about we expose, in addition to existing 2.x, extra 3.x argument happy api?
For socket.send, in addition to:

public int send(string data, [DefaultParameterValue(0)] int flags) {

we would have

public int send(byte[] data, [DefaultParameterValue(0)] int flags) {

The additional 3.x-isch api could be an activated using option.

Another question, what is the plan for 3.x? As far as I can tell,
entire unicode/api problematic would be gone.

--pawel

From jdhardy at gmail.com  Mon Jan 20 09:50:53 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Mon, 20 Jan 2014 08:50:53 +0000
Subject: [Ironpython-users] porting things to ironpython
In-Reply-To: <CA+7conkwbbk7rmn8GGkry_Ho3-NxS8-7P=nzzJ4m-RRgn9RdxQ@mail.gmail.com>
References: <CA+7conkwbbk7rmn8GGkry_Ho3-NxS8-7P=nzzJ4m-RRgn9RdxQ@mail.gmail.com>
Message-ID: <CAF7AXFFQEg2bbAdsqT_XDPEHBOGLR9UA15erNhYAj3X_TamX4g@mail.gmail.com>

On Sun, Jan 19, 2014 at 11:14 AM, Pawel Jasinski
<pawel.jasinski at gmail.com> wrote:
> hi,
>
> I have been playing with some cpython packages and tried to get them
> to work under ironpython.
> Ironpython, similar to jython, is a hybrid with true unicode strings
> (as it is defined in 3.x) and arguments and returned values of
> standard library and build-ins conforming to 2.x.
>
> Modules I have tried, have already provisions for 2->3 transition,
> which means, that most of the str/unicode/byte differences are already
> figured out.
> After some try and error, I have chosen to configure existing
> compatibility layer to run in 3.x mode and patch api entry/exit
> points. As far as I can tell it works but ...
> it appears to bit a bit inefficient.
>
> For example, socket.send is a call where 2.x expects str and 3.x bytes.
> In my case, buffer to be used for socket.send is being constructed
> using bytes, unicodes are encoded as they are appended. In case of
> ironpython 2.7, before send can be called, it has to be converted into
> string: whatever_bytes.decode('latin-1')
> I also explored use of buffer, but internally I can see it performs
> redundant string conversion as well.

Yeah, it's kind of a hack to just make things work.

>
> How about we expose, in addition to existing 2.x, extra 3.x argument happy api?
> For socket.send, in addition to:
>
> public int send(string data, [DefaultParameterValue(0)] int flags) {
>
> we would have
>
> public int send(byte[] data, [DefaultParameterValue(0)] int flags) {

This is a better option, and it's needed for 3.x anyway.

>
> The additional 3.x-isch api could be an activated using option.
>
> Another question, what is the plan for 3.x? As far as I can tell,
> entire unicode/api problematic would be gone.

Moving to 3.x is my major goal for the year. I've just finished moving
to Ireland (and my Windows box is still on a boat somewhere) so I
haven't had much time to work on it lately, but a couple of people
have contacted me about how to help on IP 3, which should hopefully
make things go faster. My own thoughts from last year are at
http://blog.jdhardy.ca/2013/06/ironpython-3-todo.html. Figuring out
which "native" APIs need bytes and string versions would be a huge
help.

There's also some other changes I'd like to make, but I'll start a new
thread for those.

- Jeff

From jdhardy at gmail.com  Mon Jan 20 10:09:40 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Mon, 20 Jan 2014 09:09:40 +0000
Subject: [Ironpython-users] Splitting up the IronPython repo
Message-ID: <CAF7AXFEEQCqdkVRemgZA2m2FA8b=XmvPBj-Wovh75Z_FyznkiQ@mail.gmail.com>

One of the big issues with working on IronPython is the size of the
git repository (specifically https://github.com/IronLanguages/main) -
git does not like really big repos, especially on Windows. Part of the
problem is that the repository includes:

* The DLR
* IronPython
* IronRuby
* Two copies of the Python stdlib
* The Ruby stdlib
* WiX
* and a bunch of reference assemblies

Even on a fast machine, 'git status' takes several seconds to return.
I believe this is because it was originally a TFS repo, which can
scale to handle bigger repos by using a bigger server. With git that
option doesn't exist - if the repo is too big, the only option is to
split it up.

I've created two repos - https://github.com/jdhardy/dlr and
https://github.com/jdhardy/ironpython-only - that contain just the DLR
and IronPython, respectively. In them, git calls are nearly
instantaneous, which makes working with it a lot less painful.

There are other advantages - the DLR can get its own release cycle and
packaging, and IP can then depend on a specific version of the DLR.
Each project has a modified version of the IronPython build system
that makes it easy to build for other platforms (iOS, Android, Win8,
etc. - they still need to ported and tested, but the builds are
easier).

I did most of the work using Mono/xbuild, so I know it works there
(except for a bug in Mono's .NET 4.5 support), but it has some errors
on Windows that I need to sort out.

Once I get my Windows box back and get some time to fix the few
remaining issues, I'll move the repos to the IronLanguages account and
use them for development of a real DLR release and IronPython 3.0. Any
more 2.7 releases will come out of the existing repo.

One downside is that copying patches between 3.0 and 2.7 is going to
be extra work, but 3.0 will solve so many problems with strings that I
think it will quickly become the more common target. In general Python
3 momentum is picking up so it's a good time (some recent
hand-wringing notwithstanding) to try and have IronPython 3 in the
right spot at the right time.

I haven't really addressed IronRuby because, for intents and purposes,
it's dead.

All of that said, if anyone has any objections I'd like to hear them.
The split repos work well for me but I'm curious if others prefer the
combined repo.

- Jeff

From m.schaber at codesys.com  Mon Jan 20 11:13:34 2014
From: m.schaber at codesys.com (Markus Schaber)
Date: Mon, 20 Jan 2014 10:13:34 +0000
Subject: [Ironpython-users] Splitting up the IronPython repo
In-Reply-To: <CAF7AXFEEQCqdkVRemgZA2m2FA8b=XmvPBj-Wovh75Z_FyznkiQ@mail.gmail.com>
References: <CAF7AXFEEQCqdkVRemgZA2m2FA8b=XmvPBj-Wovh75Z_FyznkiQ@mail.gmail.com>
Message-ID: <727D8E16AE957149B447FE368139F2B53984F51A@SERVER10>

Hi, Jeff,

Good work, I'm all in favour of it. Splitting DLR, IronPython and IronRuby into different projects is a good thing.

Just some unordered thoughts:

The python standard library could be fetched by the build script directly from the cPython servers (maybe with a few local patches applied until those are included upstream). The same may apply to other dependencies.

For the first IronPython 3 release, I suggest that you try to target Python 3.4 directly, and skip the intermediate 3.0-3.3 releases.

Also, I think now it's time to hard-code .NET 4 as dependency and drop .NET 2/3 - this will allow us to lots of #ifdefs and some other nasty code.  Also, the PAL concept may be extended to replace some of those #ifdefs (as already mentioned on http://blog.jdhardy.ca/2013/06/ironpython-3-todo.html). In my eyes, the main benefit of this will be that we (hopefully) can get rid of the conditional project references (which are a little PITA because they are not handled well by Visual Studio).

For debugging purposes, it may still be handy to have a combined .sln which contains IronPython, DLR and maybe the hosting application, but it should be possible to retain the capability to create such a solution.

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
> -----Urspr?ngliche Nachricht-----
> Von: Ironpython-users [mailto:ironpython-users-
> bounces+m.schaber=codesys.com at python.org] Im Auftrag von Jeff Hardy
> Gesendet: Montag, 20. Januar 2014 10:10
> An: ironpython-users at python.org
> Betreff: [Ironpython-users] Splitting up the IronPython repo
> 
> One of the big issues with working on IronPython is the size of the git
> repository (specifically https://github.com/IronLanguages/main) - git does
> not like really big repos, especially on Windows. Part of the problem is that
> the repository includes:
> 
> * The DLR
> * IronPython
> * IronRuby
> * Two copies of the Python stdlib
> * The Ruby stdlib
> * WiX
> * and a bunch of reference assemblies
> 
> Even on a fast machine, 'git status' takes several seconds to return.
> I believe this is because it was originally a TFS repo, which can scale to
> handle bigger repos by using a bigger server. With git that option doesn't
> exist - if the repo is too big, the only option is to split it up.
> 
> I've created two repos - https://github.com/jdhardy/dlr and
> https://github.com/jdhardy/ironpython-only - that contain just the DLR and
> IronPython, respectively. In them, git calls are nearly instantaneous, which
> makes working with it a lot less painful.
> 
> There are other advantages - the DLR can get its own release cycle and
> packaging, and IP can then depend on a specific version of the DLR.
> Each project has a modified version of the IronPython build system that makes
> it easy to build for other platforms (iOS, Android, Win8, etc. - they still
> need to ported and tested, but the builds are easier).
> 
> I did most of the work using Mono/xbuild, so I know it works there (except
> for a bug in Mono's .NET 4.5 support), but it has some errors on Windows that
> I need to sort out.
> 
> Once I get my Windows box back and get some time to fix the few remaining
> issues, I'll move the repos to the IronLanguages account and use them for
> development of a real DLR release and IronPython 3.0. Any more 2.7 releases
> will come out of the existing repo.
> 
> One downside is that copying patches between 3.0 and 2.7 is going to be extra
> work, but 3.0 will solve so many problems with strings that I think it will
> quickly become the more common target. In general Python
> 3 momentum is picking up so it's a good time (some recent hand-wringing
> notwithstanding) to try and have IronPython 3 in the right spot at the right
> time.
> 
> I haven't really addressed IronRuby because, for intents and purposes, it's
> dead.
> 
> All of that said, if anyone has any objections I'd like to hear them.
> The split repos work well for me but I'm curious if others prefer the
> combined repo.
> 
> - Jeff
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users

From jdhardy at gmail.com  Wed Jan 22 14:33:41 2014
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 22 Jan 2014 13:33:41 +0000
Subject: [Ironpython-users] Splitting up the IronPython repo
In-Reply-To: <727D8E16AE957149B447FE368139F2B53984F51A@SERVER10>
References: <CAF7AXFEEQCqdkVRemgZA2m2FA8b=XmvPBj-Wovh75Z_FyznkiQ@mail.gmail.com>
 <727D8E16AE957149B447FE368139F2B53984F51A@SERVER10>
Message-ID: <CAF7AXFGUeChBWBHogPPuy7409n6qA4YW79eywJfe2yBbV1nzCA@mail.gmail.com>

On Mon, Jan 20, 2014 at 10:13 AM, Markus Schaber <m.schaber at codesys.com> wrote:
> Hi, Jeff,
>
> Good work, I'm all in favour of it. Splitting DLR, IronPython and IronRuby into different projects is a good thing.
>
> Just some unordered thoughts:
>
> The python standard library could be fetched by the build script directly from the cPython servers (maybe with a few local patches applied until those are included upstream). The same may apply to other dependencies.

One of my stumbling blocks has been the best way to do this. Ideally I
could bring in new versions using a 3-way merge to make it easier to
deal with patches not available upstream.

>
> For the first IronPython 3 release, I suggest that you try to target Python 3.4 directly, and skip the intermediate 3.0-3.3 releases.

Yeah, that's the plan. Targeting 3.0 would be hard because IP already
has the "native" _io module introduced in 3.1. :)

This is also an opportunity to break the correspondence between
CPython and IronPython version numbers, with the caveat that
IronPython will never have a version number higher than CPython.

>
> Also, I think now it's time to hard-code .NET 4 as dependency and drop .NET 2/3 - this will allow us to lots of #ifdefs and some other nasty code.  Also, the PAL concept may be extended to replace some of those #ifdefs (as already mentioned on http://blog.jdhardy.ca/2013/06/ironpython-3-todo.html). In my eyes, the main benefit of this will be that we (hopefully) can get rid of the conditional project references (which are a little PITA because they are not handled well by Visual Studio).

The new projects handle conditional refs a bit differently, and Visual
Studio gets much less confused. Extending the PAL is probably the
biggest architectural change I want to make (in a perfect world
IronPython.dll would be a PCL, but I don't know if that's possible),
but major refactorings there are less time spent on implementing
Python 3 features (and there are only so many hours in a day, sadly).

Right now I think 3.0 should focus on Python 3 features and 3.1 should
focus on better platform support. Python 3 evolves very slowly, so
once we get caught up, there'll be more time to work on other stuff.

>
> For debugging purposes, it may still be handy to have a combined .sln which contains IronPython, DLR and maybe the hosting application, but it should be possible to retain the capability to create such a solution.

Yeah, I've had to do that a few times, so it will wtill be possible if
not supplied. If I can get symbolsource.org integrated with the NuGet
packages it might reduce the need to do that.

- Jeff

From doug.blank at gmail.com  Wed Jan 22 15:20:05 2014
From: doug.blank at gmail.com (Doug Blank)
Date: Wed, 22 Jan 2014 09:20:05 -0500
Subject: [Ironpython-users] Splitting up the IronPython repo
In-Reply-To: <CAF7AXFEEQCqdkVRemgZA2m2FA8b=XmvPBj-Wovh75Z_FyznkiQ@mail.gmail.com>
References: <CAF7AXFEEQCqdkVRemgZA2m2FA8b=XmvPBj-Wovh75Z_FyznkiQ@mail.gmail.com>
Message-ID: <CAAusYCjBMF2gm1ArPKHJAE2828A3LOSw0mFYrH2e1L-2ty2srA@mail.gmail.com>

+1 for these plans! I think this split will be good for the dlr, which
hasn't (so far) been used as much as it could.

BTW, (and this is a small point) even though IronRuby is dead and was
never complete, it is still functional for some purposes. So, if it is
possible without major time commitments to keep it at least as-is,
that would be useful for our purposes.

Thanks for all of your work, especially for thinking about the big picture!

-Doug

On Mon, Jan 20, 2014 at 4:09 AM, Jeff Hardy <jdhardy at gmail.com> wrote:
> One of the big issues with working on IronPython is the size of the
> git repository (specifically https://github.com/IronLanguages/main) -
> git does not like really big repos, especially on Windows. Part of the
> problem is that the repository includes:
>
> * The DLR
> * IronPython
> * IronRuby
> * Two copies of the Python stdlib
> * The Ruby stdlib
> * WiX
> * and a bunch of reference assemblies
>
> Even on a fast machine, 'git status' takes several seconds to return.
> I believe this is because it was originally a TFS repo, which can
> scale to handle bigger repos by using a bigger server. With git that
> option doesn't exist - if the repo is too big, the only option is to
> split it up.
>
> I've created two repos - https://github.com/jdhardy/dlr and
> https://github.com/jdhardy/ironpython-only - that contain just the DLR
> and IronPython, respectively. In them, git calls are nearly
> instantaneous, which makes working with it a lot less painful.
>
> There are other advantages - the DLR can get its own release cycle and
> packaging, and IP can then depend on a specific version of the DLR.
> Each project has a modified version of the IronPython build system
> that makes it easy to build for other platforms (iOS, Android, Win8,
> etc. - they still need to ported and tested, but the builds are
> easier).
>
> I did most of the work using Mono/xbuild, so I know it works there
> (except for a bug in Mono's .NET 4.5 support), but it has some errors
> on Windows that I need to sort out.
>
> Once I get my Windows box back and get some time to fix the few
> remaining issues, I'll move the repos to the IronLanguages account and
> use them for development of a real DLR release and IronPython 3.0. Any
> more 2.7 releases will come out of the existing repo.
>
> One downside is that copying patches between 3.0 and 2.7 is going to
> be extra work, but 3.0 will solve so many problems with strings that I
> think it will quickly become the more common target. In general Python
> 3 momentum is picking up so it's a good time (some recent
> hand-wringing notwithstanding) to try and have IronPython 3 in the
> right spot at the right time.
>
> I haven't really addressed IronRuby because, for intents and purposes,
> it's dead.
>
> All of that said, if anyone has any objections I'd like to hear them.
> The split repos work well for me but I'm curious if others prefer the
> combined repo.
>
> - Jeff
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users

From vernondcole at gmail.com  Thu Jan 23 16:33:34 2014
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Thu, 23 Jan 2014 16:33:34 +0100
Subject: [Ironpython-users] Splitting up the IronPython repo
In-Reply-To: <CAAusYCjBMF2gm1ArPKHJAE2828A3LOSw0mFYrH2e1L-2ty2srA@mail.gmail.com>
References: <CAF7AXFEEQCqdkVRemgZA2m2FA8b=XmvPBj-Wovh75Z_FyznkiQ@mail.gmail.com>
 <CAAusYCjBMF2gm1ArPKHJAE2828A3LOSw0mFYrH2e1L-2ty2srA@mail.gmail.com>
Message-ID: <CAH-ZgAfXW5wVMsxjDpjM2Wd=Q2fFNH+i9WRpwzSwoniTPVEivQ@mail.gmail.com>

+1 on splitting.

I have been trying to quietly lobby for returning IronPython into the
Ubuntu distribution.
Splitting out Ruby would be a helpful step.



On Wed, Jan 22, 2014 at 3:20 PM, Doug Blank <doug.blank at gmail.com> wrote:

> +1 for these plans! I think this split will be good for the dlr, which
> hasn't (so far) been used as much as it could.
>
> BTW, (and this is a small point) even though IronRuby is dead and was
> never complete, it is still functional for some purposes. So, if it is
> possible without major time commitments to keep it at least as-is,
> that would be useful for our purposes.
>
> Thanks for all of your work, especially for thinking about the big picture!
>
> -Doug
>
> On Mon, Jan 20, 2014 at 4:09 AM, Jeff Hardy <jdhardy at gmail.com> wrote:
> > One of the big issues with working on IronPython is the size of the
> > git repository (specifically https://github.com/IronLanguages/main) -
> > git does not like really big repos, especially on Windows. Part of the
> > problem is that the repository includes:
> >
> > * The DLR
> > * IronPython
> > * IronRuby
> > * Two copies of the Python stdlib
> > * The Ruby stdlib
> > * WiX
> > * and a bunch of reference assemblies
> >
> > Even on a fast machine, 'git status' takes several seconds to return.
> > I believe this is because it was originally a TFS repo, which can
> > scale to handle bigger repos by using a bigger server. With git that
> > option doesn't exist - if the repo is too big, the only option is to
> > split it up.
> >
> > I've created two repos - https://github.com/jdhardy/dlr and
> > https://github.com/jdhardy/ironpython-only - that contain just the DLR
> > and IronPython, respectively. In them, git calls are nearly
> > instantaneous, which makes working with it a lot less painful.
> >
> > There are other advantages - the DLR can get its own release cycle and
> > packaging, and IP can then depend on a specific version of the DLR.
> > Each project has a modified version of the IronPython build system
> > that makes it easy to build for other platforms (iOS, Android, Win8,
> > etc. - they still need to ported and tested, but the builds are
> > easier).
> >
> > I did most of the work using Mono/xbuild, so I know it works there
> > (except for a bug in Mono's .NET 4.5 support), but it has some errors
> > on Windows that I need to sort out.
> >
> > Once I get my Windows box back and get some time to fix the few
> > remaining issues, I'll move the repos to the IronLanguages account and
> > use them for development of a real DLR release and IronPython 3.0. Any
> > more 2.7 releases will come out of the existing repo.
> >
> > One downside is that copying patches between 3.0 and 2.7 is going to
> > be extra work, but 3.0 will solve so many problems with strings that I
> > think it will quickly become the more common target. In general Python
> > 3 momentum is picking up so it's a good time (some recent
> > hand-wringing notwithstanding) to try and have IronPython 3 in the
> > right spot at the right time.
> >
> > I haven't really addressed IronRuby because, for intents and purposes,
> > it's dead.
> >
> > All of that said, if anyone has any objections I'd like to hear them.
> > The split repos work well for me but I'm curious if others prefer the
> > combined repo.
> >
> > - Jeff
> > _______________________________________________
> > Ironpython-users mailing list
> > Ironpython-users at python.org
> > https://mail.python.org/mailman/listinfo/ironpython-users
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140123/12eed4ca/attachment.html>

From no_reply at codeplex.com  Sat Jan 25 09:22:27 2014
From: no_reply at codeplex.com (CodePlex)
Date: 25 Jan 2014 00:22:27 -0800
Subject: [Ironpython-users] IronPython, Daily Digest 1/24/2014
Message-ID: <CO1MSDNADMCDS2BxxLJ00003b6e@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] Using reference to unicode function on unicode string containing non-ASCII characters throws UnicodeDecodeError
2. [New issue] nt.kill(pid, sig) ignores sig argument

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

ISSUES

1. [New comment] Using reference to unicode function on unicode string containing non-ASCII characters throws UnicodeDecodeError
http://ironpython.codeplex.com/workitem/29505
User pacrook has commented on the issue:

"<p>I hit the same issue trying to use unicode with map. The following works in Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)]</p><p>&gt; \&gt;\&gt;\&gt; print '\t'.join(map(unicode, [u'\xe5', 1.0]))<br>?       1.0</p><p>but in IronPython 2.7.4 (2.7.0.40) on .NET 4.0.30319.34003 (64-bit)<br>&gt; \&gt;\&gt;\&gt; print '\t'.join(map(unicode, [u'\xe5', 1.0]))<br>Traceback (most recent call last):<br>  File &quot;&lt;stdin&gt;&quot;, line 1, in &lt;module&gt;<br>UnicodeDecodeError: ('unknown', u'\xe5', 0, 1, '')</p><p>the problem arises from the map(unicode, ...) call, e.g.<br>&gt; \&gt;\&gt;\&gt; print map(unicode, [u'\xe5', 1.0])<br>Traceback (most recent call last):<br>  File &quot;&lt;stdin&gt;&quot;, line 1, in &lt;module&gt;<br>UnicodeDecodeError: ('unknown', u'\xe5', 0, 1, '')</p><p>introducing a labda reference as suggested above fixes the Iron Python version of the code:<br>&gt; \&gt;\&gt;\&gt; print '\t'.join(map(lambda x:unicode(x), [u'\xe5', 1.0]))<br>?       1.0 </p><p></p>"-----------------

2. [New issue] nt.kill(pid, sig) ignores sig argument
http://ironpython.codeplex.com/workitem/34928
User paweljasinski has proposed the issue:

"nt.kill ignores sig arguments and performs unconditional Terminate
It should distinguish CTRL_C_EVENT, CTRL_BREAK_EVENT and try to use GenerateConsoleCtrlEvent
This of course on Windows only, mono on linux can use posix signals."
----------------------------------------------



----------------------------------------------
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/20140125/4a639c68/attachment.html>

From no_reply at codeplex.com  Sun Jan 26 09:21:47 2014
From: no_reply at codeplex.com (CodePlex)
Date: 26 Jan 2014 00:21:47 -0800
Subject: [Ironpython-users] IronPython, Daily Digest 1/25/2014
Message-ID: <CO1MSDNADMCDS2lNY3000004f58@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New issue] no public usable FunctionType.__new__

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

ISSUES

1. [New issue] no public usable FunctionType.__new__
http://ironpython.codeplex.com/workitem/34932
User paweljasinski has proposed the issue:

"the only visible implementation of FunctionType.new raises NotImplementedException.
For small tweaks (e.g. faking module membership) it would be beneficial to have any usable FunctionType.new


example of use, out of ipython\interactive\utils.py
def interactive(f):
"""decorator for making functions appear as interactively defined.
This results in the function being linked to the user_ns as globals()
instead of the module globals().
"""
    # build new FunctionType, so it can have the right globals
    # interactive functions never have closures, that's kind of the point
    if isinstance(f, FunctionType):
        mainmod = __import__('__main__')
        f = FunctionType(f.__code__, mainmod.__dict__,
            f.__name__, f.__defaults__,
        )
    # associate with __main__ for uncanning
    f.__module__ = '__main__'
    return f

Our implementation in PythonFunctions:
        private PythonFunction(CodeContext context, FunctionCode code, PythonDictionary globals, string name, PythonTuple defaults, PythonTuple closure) {
            throw new NotImplementedException();
        }
"
----------------------------------------------



----------------------------------------------
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/20140126/a941e1df/attachment.html>

From vano at mail.mipt.ru  Thu Jan 30 07:31:34 2014
From: vano at mail.mipt.ru (Ivan Pozdeev)
Date: Thu, 30 Jan 2014 10:31:34 +0400
Subject: [Ironpython-users] Get objects of the currently running Interpreter
Message-ID: <1863887576.20140130103134@mail.mipt.ru>

Hello Ironpython-users,

I'm trying to create a child interactive console in ipy.exe that would
reside in another AddDomain to be able to unload and reload specific
assemblies. Its enviromnet should copy the parent's one in every
detail, and it should load the unloadable module and initialize a few
variables before entering the interactive loop.

The question is: how can I get any objects related to the currently
running interpreter (e.g. IConsole and ConsoleOptions to be able to run
CommandLine().Run) ?

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