From no_reply at codeplex.com Mon Sep 1 09:22:09 2014 From: no_reply at codeplex.com (CodePlex) Date: 1 Sep 2014 00:22:09 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 8/31/2014 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] Paramiko in python script throws exception- TypeError: expected _counter, got _counterStarting ... 2. [New comment] Paramiko in python script throws exception- TypeError: expected _counter, got _counterStarting ... ---------------------------------------------- ISSUES 1. [New comment] Paramiko in python script throws exception- TypeError: expected _counter, got _counterStarting ... http://ironpython.codeplex.com/workitem/35515 User paweljasinski has commented on the issue: "

> We were able to run the python scripts from command prompt and connecting to SSH without any issues
how does your command line looks like?

"----------------- 2. [New comment] Paramiko in python script throws exception- TypeError: expected _counter, got _counterStarting ... http://ironpython.codeplex.com/workitem/35515 User paweljasinski has commented on the issue: "

> We were able to run the python scripts from command prompt and connecting to SSH without any issues

how does your command line looks like?

Fixed in 587184

"----------------- 2. [New comment] b64encode(bz2.compress()) throws exception. http://ironpython.codeplex.com/workitem/35507 User paweljasinski has commented on the issue: "

fixed in 542d74f05ba7e673448ebae766378879301ba185

"----------------- 3. [New comment] Paramiko in python script throws exception- TypeError: expected _counter, got _counterStarting ... http://ironpython.codeplex.com/workitem/35515 User jamini has commented on the issue: "

We are running the scripts from command line as follows :

C:\Program Files (x86)\IronPython 2.7> ipy.exe -X:Frames C:\...\...\...\Sample.py

I'm attaching the output for above execution, please find it.

Thanks,
Jamini Mungara.

"----------------- 4. [New comment] Paramiko in python script throws exception- TypeError: expected _counter, got _counterStarting ... http://ironpython.codeplex.com/workitem/35515 User paweljasinski has commented on the issue: "

I am afraid I have no simple answer for your question.
I would look for differences between command line run and embedded run.
Some candidates:
- sys.path
- permissions/credentials (who runs it)
- current working directory
Another line of attack is to find out more about the exception. Rudimentary check in paramiko reveals that the origin is obfuscated. Try to find the place where it is raised.

Something puzzling, I can find _counter but see no traces of _counterStarting. I checked paramiko and ironpycrypto.

"----------------- 5. [New comment] Paramiko in python script throws exception- TypeError: expected _counter, got _counterStarting ... http://ironpython.codeplex.com/workitem/35515 User jamini has commented on the issue: "

Hi,

Sorry I forgot to say this, the output "Starting" which was a simple print statement was appended to that _counter. So it appears as _counterStarting.

Thanks,
Jamini Mungara.

We added a Microsoft.scripting.debugging.dll to our solution to debug the python scripts. While debugging them we found self.active property is getting false in client.py file in paramiko when executing ssh connect statement. There we are getting that exception.

__TypeError:Expected _counter, got _counter.__

The stack trace for that exception is as follows :
at Microsoft.Scripting.Interpreter.MethodInfoCallInstruction.InvokeWorker(Object[] args)
at Microsoft.Scripting.Interpreter.MethodInfoCallInstruction.Invoke(Object[] args)
at Microsoft.Scripting.Interpreter.MethodInfoCallInstruction.Run(InterpretedFrame frame)
at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame)
at Microsoft.Scripting.Interpreter.LightLambda.Run7[T0,T1,T2,T3,T4,T5,T6,TRet](T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6)
at System.Dynamic.UpdateDelegates.UpdateAndExecute6[T0,T1,T2,T3,T4,T5,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5)
at Microsoft.Scripting.Interpreter.DynamicInstruction`7.Run(InterpretedFrame frame)
at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame)
at Microsoft.Scripting.Interpreter.LightLambda.Run6[T0,T1,T2,T3,T4,T5,TRet](T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5)
at System.Dynamic.UpdateDelegates.UpdateAndExecute5[T0,T1,T2,T3,T4,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
at NHRTest1$2.__init__$54(PythonFunction $function, Object self, Object IP, Object user, Object password) in C:\xxtws\trunk\NHRLibrary\NHRTest1.py:line 678
at IronPython.Runtime.FunctionCaller`4.Call4(CallSite site, CodeContext context, Object func, T0 arg0, T1 arg1, T2 arg2, T3 arg3)
at System.Dynamic.UpdateDelegates.UpdateAndExecute6[T0,T1,T2,T3,T4,T5,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5)
at IronPython.Runtime.Method.MethodBinding`3.SelfTarget(CallSite site, CodeContext context, Object target, T0 arg0, T1 arg1, T2 arg2)
at System.Dynamic.UpdateDelegates.UpdateAndExecute5[T0,T1,T2,T3,T4,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
at Microsoft.Scripting.Interpreter.DynamicInstruction`6.Run(InterpretedFrame frame)
at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame)
at Microsoft.Scripting.Interpreter.LightLambda.Run6[T0,T1,T2,T3,T4,T5,TRet](T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5)
at System.Dynamic.UpdateDelegates.UpdateAndExecute5[T0,T1,T2,T3,T4,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
at <unnamed>$1.<unnamed>(CodeContext $globalContext, FunctionCode $functionCode) in C:\xxtws\trunk\Server\Test3.py:line 55
at IronPython.Compiler.PythonScriptCode.RunWorker(CodeContext ctx)
at IronPython.Compiler.PythonScriptCode.Run(Scope scope)
at IronPython.Compiler.RuntimeScriptCode.InvokeTarget(Scope scope)
at IronPython.Compiler.RuntimeScriptCode.Run(Scope scope)
at Microsoft.Scripting.SourceUnit.Execute(Scope scope, ErrorSink errorSink)
at Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope scope)
at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteFile(String path)
at Microsoft.Scripting.Hosting.ScriptRuntime.ExecuteFile(String path)

Hope this information may help you to suggest us the approach to be followed.

I managed to compile it with Mono 3.8 and a few modifications, see PR: https://github.com/IronLanguages/main/pull/218

"----------------- 2. [Status update] Connecting to ssh through Paramiko from c# throws exception TypeError: expected _counter, got _counterStarting ... http://ironpython.codeplex.com/workitem/35514 User paweljasinski has updated the issue: Status has changed from Proposed to Closed with the following comment, "dup 35515"----------------- 3. [New comment] Paramiko in python script throws exception- TypeError: expected _counter, got _counterStarting ... http://ironpython.codeplex.com/workitem/35515 User paweljasinski has commented on the issue: "

what is inside C:\xxtws\trunk\NHRLibrary\NHRTest1.py around line 678?

C:\Program Files (x86)\IronPython 2.7>pwd
C:\Program Files (x86)\IronPython 2.7

C:\Program Files (x86)\IronPython 2.7>ipy
IronPython 2.7.5b2 (2.7.5.0) on .NET 4.0.30319.34014 (32-bit)
Type "help", "copyright", "credits" or "license" for more information.
>>> 'a'.encode('idna')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
LookupError: unknown encoding: idna

"----------------- 2. [New comment] bytearray constructor should accept string http://ironpython.codeplex.com/workitem/35493 User paweljasinski has commented on the issue: "

fixed in cdc970f22f3e1b975777373b199277204fd72b5c

Why hasn't this been merged in yet? I just ran into this bug and it makes me sad to see this unmerged patch fix from 3 years ago.

any chance you could create a pull request on github?

"----------------- 2. [New comment] assertRaises ignores CLR exceptions http://ironpython.codeplex.com/workitem/30119 User slide_o_mix has commented on the issue: "

I'm not sure this it is the best fix for the issue. We'd like to keep the standard library the same as CPython if possible.

" ---------------------------------------------- ---------------------------------------------- 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: From no_reply at codeplex.com Sun Sep 14 09:21:33 2014 From: no_reply at codeplex.com (CodePlex) Date: 14 Sep 2014 00:21:33 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 9/13/2014 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] socket.send, socket.sendto, socket.sendall should accept bytes as parameter 2. [New issue] b'a'.decode() throws TypeError ---------------------------------------------- ISSUES 1. [New issue] socket.send, socket.sendto, socket.sendall should accept bytes as parameter http://ironpython.codeplex.com/workitem/35543 User paweljasinski has proposed the issue: "This is another cpython incompatibility. socket.send(b'x') throws exception TypeError: expected buffer, got bytes"----------------- 2. [New issue] b'a'.decode() throws TypeError http://ironpython.codeplex.com/workitem/35544 User paweljasinski has proposed the issue: "it looks like 25d3b819ca758c388bec280df66429751f4e88fc introduced a another problem. b'a'.decode() throws: TypeError: decode() expected string, got 'NoneType'" ---------------------------------------------- ---------------------------------------------- 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: From m.schaber at codesys.com Tue Sep 16 17:59:56 2014 From: m.schaber at codesys.com (Markus Schaber) Date: Tue, 16 Sep 2014 15:59:56 +0000 Subject: [Ironpython-users] Unicode Message-ID: <727D8E16AE957149B447FE368139F2B539CBD7D6@SERVER10> Hi, I just noticed that the non-BMP Unicode Literals don't seem to work correctly in IronPython, this seems to work correctly in cPython 2.7.8: Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)] on win32 >>> u"\U00010042" u'\U00010042' IronPython 2.7.4 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit) >>> u"\U00010042" 'B' I guess this truncation is caused by the UTF-16 nature of .NET strings. I guess the most sensible thing IronPython could do here is to create the correct surrogate pair: >>> System.Text.Encoding.UTF32.GetString((0x42, 0, 1, 0)) u'\ud800\udc42' 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 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From vernondcole at gmail.com Tue Sep 16 21:52:36 2014 From: vernondcole at gmail.com (Vernon D. Cole) Date: Tue, 16 Sep 2014 19:52:36 +0000 Subject: [Ironpython-users] Unicode In-Reply-To: <727D8E16AE957149B447FE368139F2B539CBD7D6@SERVER10> References: <727D8E16AE957149B447FE368139F2B539CBD7D6@SERVER10> Message-ID: Just out of curiosity, how does it work in CPython 3.4? (That's where we should be headed. All of this fiddling with obscure str bugs in 2.7 is a bit of a waste, IMHO.) On Tue, Sep 16, 2014 at 3:59 PM, Markus Schaber wrote: > Hi, > > I just noticed that the non-BMP Unicode Literals don't seem to work > correctly in IronPython, this seems to work correctly in cPython 2.7.8: > > Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)] > on win32 > >>> u"\U00010042" > u'\U00010042' > > IronPython 2.7.4 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit) > >>> u"\U00010042" > 'B' > > I guess this truncation is caused by the UTF-16 nature of .NET strings. I > guess the most sensible thing IronPython could do here is to create the > correct surrogate pair: > > >>> System.Text.Encoding.UTF32.GetString((0x42, 0, 1, 0)) > u'\ud800\udc42' > > > 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 > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received > this e-mail in error) please notify the sender immediately and destroy > this e-mail. Any unauthorised copying, disclosure > or distribution of the material in this e-mail is strictly forbidden. > > _______________________________________________ > 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: From pawel.jasinski at gmail.com Tue Sep 16 23:18:27 2014 From: pawel.jasinski at gmail.com (Pawel Jasinski) Date: Tue, 16 Sep 2014 23:18:27 +0200 Subject: [Ironpython-users] Unicode In-Reply-To: References: <727D8E16AE957149B447FE368139F2B539CBD7D6@SERVER10> Message-ID: On Tue, Sep 16, 2014 at 9:52 PM, Vernon D. Cole wrote: > Just out of curiosity, how does it work in CPython 3.4? > As expected I guess: Python 3.4.0 (default, Apr 11 2014, 13:05:11) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> u"\U0001D4AE" '?' I even get correct character on my terminal. Wow! >>> import sys >>> sys.maxunicode 1114111 This means python I have is compiled with UCS4 Looks like .net has surrogates and no direct UCS4 support. I guess we don't have many alternatives. > (That's where we should be headed. All of this fiddling with obscure str > bugs in 2.7 is a bit of a waste, IMHO.) > > > It saves effort when working with generic python packages. Any fix of "obscure" bytes conversion pays back. --pawel -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.schaber at codesys.com Wed Sep 17 09:10:12 2014 From: m.schaber at codesys.com (Markus Schaber) Date: Wed, 17 Sep 2014 07:10:12 +0000 Subject: [Ironpython-users] Unicode In-Reply-To: References: <727D8E16AE957149B447FE368139F2B539CBD7D6@SERVER10>

Message-ID: <727D8E16AE957149B447FE368139F2B539CBD938@SERVER10> Hi, Von: Pawel Jasinski > On Tue, Sep 16, 2014 at 9:52 PM, Vernon D. Cole wrote: > > Just out of curiosity, how does it work in CPython 3.4? > As expected I guess: > Python 3.4.0 (default, Apr 11 2014, 13:05:11) > [GCC 4.8.2] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> u"\U0001D4AE" > '?' > I even get correct character on my terminal. Wow! On my windows machine, I just get the \U sequence back, but at least, the character is not lost. > >>> import sys > >>> sys.maxunicode > 1114111 > This means python I have is compiled with UCS4 > Looks like .net has surrogates and no direct UCS4 support. I guess we don't have many alternatives. While Python 2 existed in 16- and 32-bit Unicode flavours, Python 3 was UCS-4 from the beginning. All strings are full unicode. (In Python 3.3, they included an optimization to use 8 or 16 bit for strings which do not actually use higher code points, but this is purely an internal optimization: https://docs.python.org/3.4/whatsnew/3.3.html#pep-393) As .NET is inherently UTF-16, we won't be fully compatible with Python strings wr/t direct indexing of codepoints (emulating it is possible, but will be incredibly slow). But at least, we should try to not lose characters. > > (That's where we should be headed. All of this fiddling with obscure str bugs in 2.7 is a bit of a waste, IMHO.) > It saves effort when working with generic python packages. Any fix of "obscure" bytes conversion pays back. I think that fixing this by using two surrogates is the closest behaviour we can get to both Python 2 and Python 3. 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: codesys.com | CODESYS store: store.codesys.com CODESYS forum: forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 ________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From m.schaber at codesys.com Wed Sep 17 09:42:34 2014 From: m.schaber at codesys.com (Markus Schaber) Date: Wed, 17 Sep 2014 07:42:34 +0000 Subject: [Ironpython-users] Unicode In-Reply-To: <727D8E16AE957149B447FE368139F2B539CBD938@SERVER10> References: <727D8E16AE957149B447FE368139F2B539CBD7D6@SERVER10>

<727D8E16AE957149B447FE368139F2B539CBD938@SERVER10> Message-ID: <727D8E16AE957149B447FE368139F2B539CBD99B@SERVER10> Hi, It seems I have to correct myself: Von: Markus Schaber > While Python 2 existed in 16- and 32-bit Unicode flavours, Python 3 was UCS-4 from the beginning. All strings are full unicode. > (In Python 3.3, they included an optimization to use 8 or 16 bit for strings which do not actually use higher code points, but this is purely an internal optimization: https://docs.python.org/3.4/whatsnew/3.3.html#pep-393) It seems that this is not true - python 3.2 and older seemingly still had the two flavours, using surrogates internally if necessary. 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 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From Stefan.Richthofer at gmx.de Wed Sep 17 15:18:39 2014 From: Stefan.Richthofer at gmx.de (Stefan Richthofer) Date: Wed, 17 Sep 2014 15:18:39 +0200 Subject: [Ironpython-users] Some questions about gc and finalizers Message-ID: Dear IronPython community, I recently worked on Jython issue 1057 (http://bugs.jython.org/issue1057) and also improved the current solution of http://bugs.jython.org/issue1634167 a bit. For these issues, it is very hard for Jython to emulate CPython behavior due to the fundamentally different GC implementation, so I suspected, IronPython might have similar problems and wondered how they are solved here. Since I never used IronPython or .net, I would appreciate answers on a rather abstract level and apologize that I have no ambition to look into the source myself. I'm just hoping to find someone (optimally a core-dev), who can simply answer it and is maybe open for a discussion of solutions. My questions are: - does IronPython support acquired finalizers? i.e. class A(): pass def A__del__(): print "A finalized" a1 = A() A.__del__ = A__del__ a1 = None Would it output "A finalized" or not? In Jython this won't work so easy, because Jython avoids to overwrite the finalize method for all instances for its expensiveness. So only instances known to need finalization on creation time will be finalized. AfaIk, finalizers in .net are as expensive as in Java, so how would this work in IronPython? - how complete is the support of the gc module? i.e. In Jython the support is rather poor; most methods are just implemented as stubs, i.e. one-liners as throw Py.NotImplementedError("not applicable to Java GC") gc.collect usually returns the number of collected objects, but Jython just calls java.lang.System.gc() and returns None. I believe, tracking the number of collected objects would be possible, but very expensive, so this maybe could be added as a start-up-flag feature for debugging. How far does IronPython support this currently? Thanks in advance! - Stefan From jdhardy at gmail.com Thu Sep 18 14:35:30 2014 From: jdhardy at gmail.com (Jeff Hardy) Date: Thu, 18 Sep 2014 13:35:30 +0100 Subject: [Ironpython-users] Some questions about gc and finalizers In-Reply-To: References: Message-ID: (+dinov, who just needs to page this in rather than learn it all from scratch) On Wed, Sep 17, 2014 at 2:18 PM, Stefan Richthofer wrote: > Dear IronPython community, > > I recently worked on Jython issue 1057 (http://bugs.jython.org/issue1057) and also improved the current solution of http://bugs.jython.org/issue1634167 a bit. For these issues, it is very hard for Jython to emulate CPython behavior due to the fundamentally different GC implementation, so I suspected, IronPython might have similar problems and wondered how they are solved here. > Since I never used IronPython or .net, I would appreciate answers on a rather abstract level and apologize that I have no ambition to look into the source myself. I'm just hoping to find someone (optimally a core-dev), who can simply answer it and is maybe open for a discussion of solutions. > > My questions are: > - does IronPython support acquired finalizers? > i.e. > class A(): > pass > > def A__del__(): > print "A finalized" > > a1 = A() > A.__del__ = A__del__ > a1 = None > > > Would it output "A finalized" or not? A quick test (on Mono) says "no", but trying with a class that declares __del__ doesn't either, so I'd want to hook up a debugger on Windows to check for sure. I'm not sure if the backing types created by IronPython have finalizers, but I think not (and reading through the RefEmit code will take longer than I have right now.) > In Jython this won't work so easy, because Jython avoids to overwrite the finalize method for all instances for its expensiveness. So only instances known to need finalization on creation time will be finalized. AfaIk, finalizers in .net are as expensive as in Java, so how would this work in IronPython? > > > - how complete is the support of the gc module? > i.e. > In Jython the support is rather poor; most methods are just implemented as stubs, i.e. one-liners as > throw Py.NotImplementedError("not applicable to Java GC") > IronPython is about the same: https://github.com/IronLanguages/main/blob/ipy-2.7-maint/Languages/IronPython/IronPython.Modules/gc.cs > gc.collect usually returns the number of collected objects, but Jython just calls java.lang.System.gc() and returns None. I believe, tracking the number of collected objects would be possible, but very expensive, so this maybe could be added as a start-up-flag feature for debugging. How far does IronPython support this currently? IronPython just returns the number of bytes freed by the call: https://github.com/IronLanguages/main/blob/ipy-2.7-maint/Languages/IronPython/IronPython/Runtime/PythonContext.cs#L3465. - Jeff From Stefan.Richthofer at gmx.de Thu Sep 18 17:10:32 2014 From: Stefan.Richthofer at gmx.de (Stefan Richthofer) Date: Thu, 18 Sep 2014 17:10:32 +0200 Subject: [Ironpython-users] Some questions about gc and finalizers In-Reply-To: References: , Message-ID: > A quick test (on Mono) says "no", but trying with a class that > declares __del__ doesn't either, so I'd want to hook up a debugger on > Windows to check for sure. I'm not sure if the backing types created > by IronPython have finalizers, but I think not (and reading through > the RefEmit code will take longer than I have right now.) Sounds like IronPython would not support __del__ at all. Is this a basic, maybe well-known issue or are finalizers principally supported, but currently broken? I appended a unit test file and would like to know which of the tests exactly fail on IronPython. I will surely take the time to test this myself, but it might take some days until I come to setting up mono and IronPython. And I thought you might be interested in these tests too ;-) To support acquired finalizers, Jython would have to track all instances for each class. So it could update them if the class would acquire a finalizer. Obviously this is insanely expensive for such a rare use-case, so I added a builtin method __ensure_finalizer__ to Jython, which allows - at least manually - to fix this. One can tell already existing instances manually that their class acquired a finalizer (also works for new style classes): class A(): pass def A__del__(): print "A finalized" a1 = A() A.__del__ = A__del__ a1.__ensure_finalizer__() a1 = None I have only rough knowledge of .net, but believe it behaves somewhat equal to Java regarding to gc and finalizers. Since IronPython appears to have equal issues, I would offer guidance and discussion if you might want to port the Jython approach. At least I wanted to make you aware of the __ensure_finalizer__()-method-manual-fix-approach and suggest that if IronPython would ever implement an equal method to agree on a common name for it. > IronPython is about the same: > https://github.com/IronLanguages/main/blob/ipy-2.7-maint/Languages/IronPython/IronPython.Modules/gc.cs Okay, I already expected something like this. I have rough plans to enhance the Jython gc module by a manual track-method. For debugging one can add certain objects to it via gc.track(object). Then gc would monitor these and serve the original gc module methods with this information (e.g. number of collected (i.e. monitored and collected) objects). I just wanted to make you aware of this and suggest that if you might want to do an equal monitoring, to agree on a common name for the manual track method too. However, I would resume this topic when I proceed with this. - Stefan > Gesendet: Donnerstag, 18. September 2014 um 14:35 Uhr > Von: "Jeff Hardy" > An: "Stefan Richthofer" > Cc: "ironpython-users at python.org" , "Dino Viehland" > Betreff: Re: [Ironpython-users] Some questions about gc and finalizers > > (+dinov, who just needs to page this in rather than learn it all from scratch) > > On Wed, Sep 17, 2014 at 2:18 PM, Stefan Richthofer > wrote: > > Dear IronPython community, > > > > I recently worked on Jython issue 1057 (http://bugs.jython.org/issue1057) and also improved the current solution of http://bugs.jython.org/issue1634167 a bit. For these issues, it is very hard for Jython to emulate CPython behavior due to the fundamentally different GC implementation, so I suspected, IronPython might have similar problems and wondered how they are solved here. > > Since I never used IronPython or .net, I would appreciate answers on a rather abstract level and apologize that I have no ambition to look into the source myself. I'm just hoping to find someone (optimally a core-dev), who can simply answer it and is maybe open for a discussion of solutions. > > > > My questions are: > > - does IronPython support acquired finalizers? > > i.e. > > class A(): > > pass > > > > def A__del__(): > > print "A finalized" > > > > a1 = A() > > A.__del__ = A__del__ > > a1 = None > > > > > > Would it output "A finalized" or not? > > A quick test (on Mono) says "no", but trying with a class that > declares __del__ doesn't either, so I'd want to hook up a debugger on > Windows to check for sure. I'm not sure if the backing types created > by IronPython have finalizers, but I think not (and reading through > the RefEmit code will take longer than I have right now.) > > > In Jython this won't work so easy, because Jython avoids to overwrite the finalize method for all instances for its expensiveness. So only instances known to need finalization on creation time will be finalized. AfaIk, finalizers in .net are as expensive as in Java, so how would this work in IronPython? > > > > > > - how complete is the support of the gc module? > > i.e. > > In Jython the support is rather poor; most methods are just implemented as stubs, i.e. one-liners as > > throw Py.NotImplementedError("not applicable to Java GC") > > > > IronPython is about the same: > https://github.com/IronLanguages/main/blob/ipy-2.7-maint/Languages/IronPython/IronPython.Modules/gc.cs > > > gc.collect usually returns the number of collected objects, but Jython just calls java.lang.System.gc() and returns None. I believe, tracking the number of collected objects would be possible, but very expensive, so this maybe could be added as a start-up-flag feature for debugging. How far does IronPython support this currently? > > IronPython just returns the number of bytes freed by the call: > https://github.com/IronLanguages/main/blob/ipy-2.7-maint/Languages/IronPython/IronPython/Runtime/PythonContext.cs#L3465. > > - Jeff > -------------- next part -------------- A non-text attachment was scrubbed... Name: test_finalizers.py Type: text/x-java Size: 12490 bytes Desc: not available URL: From no_reply at codeplex.com Fri Sep 19 09:21:24 2014 From: no_reply at codeplex.com (CodePlex) Date: 19 Sep 2014 00:21:24 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 9/18/2014 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] "{} in {}" returns False instead of raising TypeError 2. [New comment] socket.send, socket.sendto, socket.sendall should accept bytes as parameter 3. [New comment] b'a'.decode() throws TypeError ---------------------------------------------- ISSUES 1. [New comment] "{} in {}" returns False instead of raising TypeError http://ironpython.codeplex.com/workitem/35348 User paweljasinski has commented on the issue: "

fixed in 2e9b42b667f94f247d54f912230d4e83968d05e6

"----------------- 2. [New comment] socket.send, socket.sendto, socket.sendall should accept bytes as parameter http://ironpython.codeplex.com/workitem/35543 User paweljasinski has commented on the issue: "

fixed in e95ecd623df2cb3be51ce9466cc34a1ef8cfda2e

"----------------- 3. [New comment] b'a'.decode() throws TypeError http://ironpython.codeplex.com/workitem/35544 User paweljasinski has commented on the issue: "

resolved in 7fb50784c48df31d4c610a720da47c28db42e9db

Message-ID: On Thu, Sep 18, 2014 at 4:10 PM, Stefan Richthofer wrote: >> A quick test (on Mono) says "no", but trying with a class that >> declares __del__ doesn't either, so I'd want to hook up a debugger on >> Windows to check for sure. I'm not sure if the backing types created >> by IronPython have finalizers, but I think not (and reading through >> the RefEmit code will take longer than I have right now.) > > Sounds like IronPython would not support __del__ at all. Is this a basic, maybe well-known issue or are finalizers principally supported, but currently broken? I redid my tests by calling GC.Collect() afterwards, and the "normal" case works just fine, but not the attached case. So yes, they do work. :) > I appended a unit test file and would like to know which of the tests exactly fail on IronPython. I will surely take the time to test this myself, but it might > take some days until I come to setting up mono and IronPython. And I thought you might be interested in these tests too ;-) I'll run the tests when I get a chance on my Windows machine; it might be a better test bed just to eliminate Mono bugs. > > To support acquired finalizers, Jython would have to track all instances for each class. So it could update them if the class would acquire a finalizer. > Obviously this is insanely expensive for such a rare use-case, so I added a builtin method __ensure_finalizer__ to Jython, which allows - at least manually - to fix this. > One can tell already existing instances manually that their class acquired a finalizer (also works for new style classes): > > class A(): > pass > > def A__del__(): > print "A finalized" > > a1 = A() > A.__del__ = A__del__ > a1.__ensure_finalizer__() > a1 = None But then the end user has to know to run __ensure_finalizer__() on each instance, correct? > > I have only rough knowledge of .net, but believe it behaves somewhat equal to Java regarding to gc and finalizers. > Since IronPython appears to have equal issues, I would offer guidance and discussion if you might want to port the Jython approach. > At least I wanted to make you aware of the __ensure_finalizer__()-method-manual-fix-approach and suggest that if IronPython would > ever implement an equal method to agree on a common name for it. I thought the .NET GC might store this information already, but no dice. It is available to the profiler API, but that's not really a good way to go about it (unmanaged code, separate DLL, etc.). :) I don't know about the cost of finalization in .NET, although I assume they are similar. Reading about it doesn't seem to be helping much, since it's the sort of thing that's esoteric enough to fall in to cargo-cult land pretty quickly. .NET does have GC.SuppressFinalize that supposedly removes the penalty, but I'm not immediately clear on if that helps in this case. Keeping a set of weak references would solve the problem at a not-too-horrible cost (which I think is what PyPy does, but they can share it with the GC so it's not really overhead). Honestly though, why in the heck would anyone even want to do this? Is there a use case, or is it just matching compatibility with CPython? - Jeff From m.schaber at codesys.com Fri Sep 19 13:39:40 2014 From: m.schaber at codesys.com (Markus Schaber) Date: Fri, 19 Sep 2014 11:39:40 +0000 Subject: [Ironpython-users] Some questions about gc and finalizers In-Reply-To: References:

Message-ID: <727D8E16AE957149B447FE368139F2B539CBF302@SERVER10> Hi, Jeff, Von: Jeff Hardy On Thu, Sep 18, 2014 at 4:10 PM, Stefan Richthofer wrote: > >> A quick test (on Mono) says "no", but trying with a class that > >> declares __del__ doesn't either, so I'd want to hook up a debugger on > >> Windows to check for sure. I'm not sure if the backing types created > >> by IronPython have finalizers, but I think not (and reading through > >> the RefEmit code will take longer than I have right now.) > > > > Sounds like IronPython would not support __del__ at all. Is this a basic, maybe well-known issue or are finalizers principally supported, but currently broken? > I redid my tests by calling GC.Collect() afterwards, and the "normal" > case works just fine, but not the attached case. So yes, they do work. > :) And I just wanted to write a mail and ask whether you made sure that the GC actually kicks in when reading your first mail - it's good I did hesitate and read the whole thread :-) The asynchrony and non-deterministic nature of the .NET and Java GCs are one of the biggest difference to cPython, this especially gets visible with "unclean" code which relies on the reference counting to release resources (like files). [...] > > I have only rough knowledge of .net, but believe it behaves somewhat equal to Java regarding to gc and finalizers. > > Since IronPython appears to have equal issues, I would offer guidance and discussion if you might want to port the Jython approach. > > At least I wanted to make you aware of the > > __ensure_finalizer__()-method-manual-fix-approach and suggest that if IronPython would ever implement an equal method to agree on a common name for it. > I thought the .NET GC might store this information already, but no dice. It is available to the profiler API, but that's not really a good way to go about it (unmanaged code, separate DLL, etc.). :) Sadly, not even the performance counters provide that numbers: http://msdn.microsoft.com/en-us/library/x2tyfybc%28v=vs.110%29.aspx I also agree that the profiling API is not a good way just to get this metadata. > I don't know about the cost of finalization in .NET, although I assume they are similar. Reading about it doesn't seem to be helping much, since it's the sort of thing that's esoteric enough to fall in to cargo-cult land pretty quickly. .NET does have GC.SuppressFinalize that supposedly removes the penalty, but I'm not immediately clear on if that helps in this case. > Keeping a set of weak references would solve the problem at a not-too-horrible cost (which I think is what PyPy does, but they can share it with the GC so it's not really overhead). I think weak references are not worth that effort. > Honestly though, why in the heck would anyone even want to do this? Is there a use case, or is it just matching compatibility with CPython? I guess it's just interesting for debug code. 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 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From Stefan.Richthofer at gmx.de Fri Sep 19 14:55:44 2014 From: Stefan.Richthofer at gmx.de (Stefan Richthofer) Date: Fri, 19 Sep 2014 14:55:44 +0200 Subject: [Ironpython-users] Some questions about gc and finalizers In-Reply-To: References:

, Message-ID: > I redid my tests by calling GC.Collect() afterwards, and the "normal" > case works just fine, but not the attached case. So yes, they do work. > :) Yes, of course an equivalent step is necessary in Jython too. test_finalizers.py cares for this via the gc module, which should be the right implementation-independent way. (Hope the waittime of 0.1s is sufficient for the asynchronous gc in practice) > But then the end user has to know to run __ensure_finalizer__() on > each instance, correct? Yes, correct. Sure, this is not nice, but technically I see no better way with reasonable costs. On the other hand I thought - better provide this manual way to fix it than completely ignore the issue. (__ensure_finalizer__ was -anyway- only a byproduct of implementing finalizer support for new-style classes) > Keeping a set of weak references would solve the problem at a > not-too-horrible cost (which I think is what PyPy does, but they can > share it with the GC so it's not really overhead). Is this regarding to acquired finalizers or gc statistics? Case acquired finalizers: There was a discussion in the Jython bugtracker with the clear result that instances of a class won't be tracked. Too many additional references, too expensive, not worth the cost. Case GC statistics: Since it is for debugging, I think it would be okay if one could explicitly tell the gc module which objects to monitor, or maybe make monitoring optional by a start up flag. In both cases - indeed - a set of weak references as you suggested would be the way. > Honestly though, why in the heck would anyone even want to do this? Is > there a use case, or is it just matching compatibility with CPython? Case GC statistics: Debugging like Markus pointed out. Actually test_gc.py completely relies on it and would currently not pass on Jython or IronPython, although both support gc in fact. (I am currently reasoning how to improve this, because I will need gc test tools for JyNI.) Case acquired finalizers: Yes, indeed I don't know. But I still think, "why would anyone want this?" frequently caused subtle bugs, wrong optimizations, several regressions and lots of spam on stack overflow during the history of software design. So, for me "matching compatibility with CPython" is a fair enough reason to take the issue serious - at least when I work on related stuff anyway. Honestly, the right solution would be that CPython would disallow acquired finalizers, if nobody needs this anyway. Maybe I will try to turn this into a PEP one day - since they already disallowed repeated finalization/resurrection, it might be not too utopian. However I would need more information on the issue throughout the Python eco system (which is why I bother you :-) ) - Stefan From m.schaber at codesys.com Fri Sep 19 16:02:07 2014 From: m.schaber at codesys.com (Markus Schaber) Date: Fri, 19 Sep 2014 14:02:07 +0000 Subject: [Ironpython-users] Some questions about gc and finalizers In-Reply-To: References:

Message-ID: <727D8E16AE957149B447FE368139F2B539CBF3DD@SERVER10> Hi, I checked whether the ETW Events of the .NET Framework could be helpful, at least a bit: http://msdn.microsoft.com/en-us/library/ff356162%28v=vs.100%29.aspx The GCHeapStats_V1 event delivers a FinalizationPromotedCount. The GCFinalizersEnd_V1 event comes with a Count: "The number of finalizers that were run". But both is not equal to the number of "unreachable objects", as they also contain the objects without finalizers. Personally, I tend to think we should overestimate those methods for real-life usage. Things like gc.get_referrers or gc.get_referents are not really useful in .NET or Java context, and only very expensive to emulate. There are other places where compatibility to cPython has more critical problems. 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 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From vano at mail.mipt.ru Sat Sep 20 22:15:31 2014 From: vano at mail.mipt.ru (Ivan Pozdeev) Date: Sun, 21 Sep 2014 00:15:31 +0400 Subject: [Ironpython-users] Unicode In-Reply-To: <727D8E16AE957149B447FE368139F2B539CBD7D6@SERVER10> References: <727D8E16AE957149B447FE368139F2B539CBD7D6@SERVER10> Message-ID: <1773826026.20140921001531@mail.mipt.ru> > Hi, > I just noticed that the non-BMP Unicode Literals don't seem to work correctly > in IronPython, this seems to work correctly in cPython 2.7.8: > Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)] on win32 >>>> u"\U00010042" > u'\U00010042' > IronPython 2.7.4 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit) >>>> u"\U00010042" > 'B' > I guess this truncation is caused by the UTF-16 nature of .NET strings. I > guess the most sensible thing IronPython could do here is to create the correct surrogate pair: >>>> System.Text.Encoding.UTF32.GetString((0x42, 0, 1, 0)) > u'\ud800\udc42' Yup, as well as in CPython 'narrow' builds. Check sys.maxunicode to determine the flavor of the build you're working in. > 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 > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received > this e-mail in error) please notify the sender immediately and destroy this > e-mail. Any unauthorised copying, disclosure > or distribution of the material in this e-mail is strictly forbidden. > _______________________________________________ > 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 vano at mail.mipt.ru Sat Sep 20 22:29:55 2014 From: vano at mail.mipt.ru (Ivan Pozdeev) Date: Sun, 21 Sep 2014 00:29:55 +0400 Subject: [Ironpython-users] Unicode In-Reply-To: <1773826026.20140921001531@mail.mipt.ru> References: <727D8E16AE957149B447FE368139F2B539CBD7D6@SERVER10> <1773826026.20140921001531@mail.mipt.ru> Message-ID: <299077092.20140921002955@mail.mipt.ru> >> Hi, >> I just noticed that the non-BMP Unicode Literals don't seem to work correctly >> in IronPython, this seems to work correctly in cPython 2.7.8: >> Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)] on win32 >>>>> u"\U00010042" >> u'\U00010042' >> IronPython 2.7.4 (2.7.0.40) on .NET 4.0.30319.18444 (32-bit) >>>>> u"\U00010042" >> 'B' >> I guess this truncation is caused by the UTF-16 nature of .NET strings. I >> guess the most sensible thing IronPython could do here is to create the correct surrogate pair: >>>>> System.Text.Encoding.UTF32.GetString((0x42, 0, 1, 0)) >> u'\ud800\udc42' > Yup, as well as in CPython 'narrow' builds. Check sys.maxunicode to determine the > flavor of the build you're working in. Whoops, sorry, in CPython's 'narrow' build , it is represented by a surrogate pair but the truncation doesn't happen. The latter is indeed a bug. >> 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 >> This e-mail may contain confidential and/or privileged information. If you >> are not the intended recipient (or have received >> this e-mail in error) please notify the sender immediately and destroy this >> e-mail. Any unauthorised copying, disclosure >> or distribution of the material in this e-mail is strictly forbidden. >> _______________________________________________ >> 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 no_reply at codeplex.com Wed Sep 24 09:21:50 2014 From: no_reply at codeplex.com (CodePlex) Date: 24 Sep 2014 00:21:50 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 9/23/2014 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] Missing wiki page: https://github.com/IronLanguages/main/compare/ipy-2.7.4...ipy-2.7.5-b2 ---------------------------------------------- ISSUES 1. [New issue] Missing wiki page: https://github.com/IronLanguages/main/compare/ipy-2.7.4...ipy-2.7.5-b2 http://ironpython.codeplex.com/workitem/35563 User benjaminjnr2k11 has proposed the issue: "Hello, The documentation on the following page seems to be missing: https://login.live.com/login.srf?wa=wsignin1.0&wtrealm=urn:www.codeplex.com&wreply=https://www.codeplex.com/site/login/federation.aspx?redirectUrl=https%253a%252f%252fironpython.codeplex.com%252fWorkItem%252fCreate%253fwikiPageTitle%253dhttps%253a%252f%252fgithub.com%252fIronLanguages%252fmain%252fcompare%252fipy-2.7.4...ipy-2.7.5-b2%2526referer%253dhttp%253a%252f%252fblog.ironpython.net%252f2014%252f05%252fironpython-275-beta-2-released.html%2526ProjectName%253dironpython I found the link on this page: http://blog.ironpython.net/2014/05/ironpython-275-beta-2-released.html Can you look into fixing this page? Thank you." ---------------------------------------------- ---------------------------------------------- You are receiving this email because you subscribed to notifications on CodePlex. To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From no_reply at codeplex.com Thu Sep 25 09:22:14 2014 From: no_reply at codeplex.com (CodePlex) Date: 25 Sep 2014 00:22:14 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 9/24/2014 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] PYC - Allow the Setting of the Icon if generating EXE 2. [New comment] pyc should generate try/catch around module call 3. [New comment] Missing wiki page: https://github.com/IronLanguages/main/compare/ipy-2.7.4...ipy-2.7.5-b2 ---------------------------------------------- ISSUES 1. [New comment] PYC - Allow the Setting of the Icon if generating EXE http://ironpython.codeplex.com/workitem/22138 User slide_o_mix has commented on the issue: "

Fixed in e4c740

"----------------- 2. [New comment] pyc should generate try/catch around module call http://ironpython.codeplex.com/workitem/32419 User slide_o_mix has commented on the issue: "

Implemented in e4c740

"----------------- 3. [New comment] Missing wiki page: https://github.com/IronLanguages/main/compare/ipy-2.7.4...ipy-2.7.5-b2 http://ironpython.codeplex.com/workitem/35563 User slide_o_mix has commented on the issue: "

The page should direct you to github with the change list between the two tags. It is not a wiki page. The link is in error.

" ---------------------------------------------- ---------------------------------------------- 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: From no_reply at codeplex.com Sat Sep 27 09:23:28 2014 From: no_reply at codeplex.com (CodePlex) Date: 27 Sep 2014 00:23:28 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 9/26/2014 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] ast.literal_eval in IronPython raises exception for negative numbers in expressions ---------------------------------------------- ISSUES 1. [New issue] ast.literal_eval in IronPython raises exception for negative numbers in expressions http://ironpython.codeplex.com/workitem/35572 User s3e3 has proposed the issue: "Interactive session in CPython 2.7.5 and 3.4.0: >>> import ast >>> ast.literal_eval('-1') -1 Interactive session in IronPython 2.7.3 and 2.7.5beta2: >>> import ast >>> ast.literal_eval('-1') Traceback (most recent call last): File "", line 1, in File "C:\Program Files (x86)\IronPython 2.7\Lib\ast.py", line 80, in literal_eval return _convert(node_or_string) File "C:\Program Files (x86)\IronPython 2.7\Lib\ast.py", line 79, in _convert raise ValueError('malformed string') ValueError: malformed string I came accross this issue while trying to use IronPython and jenkinsapi python package for access to our Jenkins instance. One of parameters in return expression string from Jenkins job had negative number which caused exception, which is obviously not expected to happen." ---------------------------------------------- ---------------------------------------------- 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: From no_reply at codeplex.com Sun Sep 28 09:20:35 2014 From: no_reply at codeplex.com (CodePlex) Date: 28 Sep 2014 00:20:35 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 9/27/2014 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] ipy-2.7-maint does't compile under windows 2. [New issue] socket.create_connection() causes exception "getaddrinfo returns an empty list" ---------------------------------------------- ISSUES 1. [New issue] ipy-2.7-maint does't compile under windows http://ironpython.codeplex.com/workitem/35575 User paweljasinski has proposed the issue: "$ ./make.cmd Microsoft.Scripting -> C:\cygwin64\home\rejap\github\IronLanguages\bin\Debug\Microsoft.Scripting.dll Microsoft.Scripting.Metadata -> C:\cygwin64\home\rejap\github\IronLanguages\bin\Debug\Microsoft.Scripting.Metadata.dll Microsoft.Dynamic -> C:\cygwin64\home\rejap\github\IronLanguages\bin\Debug\Microsoft.Dynamic.dll Runtime\CommonDictionaryStorage.cs(905,43): error CS0168: Warning as Error: The variable 'e' is declared but never used [C:\cygwin64\home\rejap\github\IronLanguages\Languages\IronPython\IronPython\IronPython.csproj] Microsoft.Scripting.AspNet -> C:\cygwin64\home\rejap\github\IronLanguages\bin\Debug\Microsoft.Scripting.AspNet.dll "----------------- 2. [New issue] socket.create_connection() causes exception "getaddrinfo returns an empty list" http://ironpython.codeplex.com/workitem/35576 User tcalmant has proposed the issue: "An exception is raised any time I use the method socket.create_connection(...), or call something that uses it (like the base HTTP server). This beheviour is really strange as a direct call to getaddrinfo() works correctly. IPython version: IronPython 2.7.4 (2.7.0.40) on .NET 4.0.30319.34014 (32-bit) OS: Windows 8.1 Pro 64 bits Complete trace: C:\Users\Thomas>ipy -X:ExceptionDetail IronPython 2.7.4 (2.7.0.40) on .NET 4.0.30319.34014 (32-bit) Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> socket.getaddrinfo('localhost', 8080) [(23, 0, 0, '', ('::1', 8080, 0L, 0L)), (2, 0, 0, '', ('127.0.0.1', 8080))] >>> socket.create_connection(('localhost', 8080)) getaddrinfo returns an empty list ? IronPython.Modules.PythonSocket.create_connection(CodeContext context, PythonTuple address, Object timeout, PythonTuple source_address) ? IronPython.Modules.PythonSocket.create_connection(CodeContext context, PythonTuple address) ? Microsoft.Scripting.Interpreter.FuncCallInstruction`3.Run(InterpretedFrame frame) ? Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) ? Microsoft.Scripting.Interpreter.LightLambda.Run4[T0,T1,T2,T3,TRet](T0 arg0, T1 arg1, T2 arg2, T3 arg3) ? System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2) ? Microsoft.Scripting.Interpreter.FuncCallInstruction`6.Run(InterpretedFrame frame) ? Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) ? Microsoft.Scripting.Interpreter.LightLambda.Run4[T0,T1,T2,T3,TRet](T0 arg0, T1 arg1, T2 arg2, T3 arg3) ? IronPython.Compiler.Ast.CallExpression.Invoke1Instruction.Run(InterpretedFrame frame) ? Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) ? Microsoft.Scripting.Interpreter.LightLambda.Run2[T0,T1,TRet](T0 arg0, T1 arg1) ? IronPython.Compiler.PythonScriptCode.RunWorker(CodeContext ctx) ? IronPython.Compiler.PythonScriptCode.Run(Scope scope) ? IronPython.Hosting.PythonCommandLine.<>c__DisplayClass1.b__0() socket.error: getaddrinfo returns an empty list >>> " ---------------------------------------------- ---------------------------------------------- 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: From no_reply at codeplex.com Mon Sep 29 09:22:21 2014 From: no_reply at codeplex.com (CodePlex) Date: 29 Sep 2014 00:22:21 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 9/28/2014 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] Telnetlib exception - "getaddrinfo returns an empty list" 2. [New comment] bytearray fails comparison with string value 3. [New comment] ast.literal_eval in IronPython raises exception for negative numbers in expressions 4. [New comment] socket.create_connection() causes exception "getaddrinfo returns an empty list" ---------------------------------------------- ISSUES 1. [New comment] Telnetlib exception - "getaddrinfo returns an empty list" http://ironpython.codeplex.com/workitem/35388 User paweljasinski has commented on the issue: "

This exception is erroneously thrown when connection to all addresses fails.

"----------------- 2. [New comment] bytearray fails comparison with string value http://ironpython.codeplex.com/workitem/35470 User paweljasinski has commented on the issue: "

fixed in 7f4343961781373b4ade5f630b9e8d4ab7733ca3

"----------------- 3. [New comment] ast.literal_eval in IronPython raises exception for negative numbers in expressions http://ironpython.codeplex.com/workitem/35572 User paweljasinski has commented on the issue: "

As a quick workaround you can adopt the following:[0A][0A]```[0A]import ast[0A][0A]class Fix(ast.NodeTransformer):[0A] def visit_UnaryOp(self, node):[0A] if isinstance(node.operand, ast.Num):[0A] if isinstance(node.op, ast.USub):[0A] node.operand.n=-node.operand.n[0A] return node.operand[0A] if isinstance(node.op, ast.UAdd):[0A] return node.operand[0A] return node[0A][0A]def literal_eval_fix(string_only):[0A] tree = ast.parse(string_only, mode="eval" )[0A] tree = Fix().visit(tree)[0A] return ast.literal_eval(tree)[0A][0A]print literal_eval_fix("42")[0A]print literal_eval_fix("-42")[0A]print literal_eval_fix("{ -1:-2, 2:'aaaaa'}")[0A]```[0A][0A][0A]

"----------------- 4. [New comment] socket.create_connection() causes exception "getaddrinfo returns an empty list" http://ironpython.codeplex.com/workitem/35576 User paweljasinski has commented on the issue: "

This exception is erroneously thrown when connection to all addresses fails.

This still happends in IronPython 2.7.4.[0A][0A]```[0A]C:\Users\Thomas\>ipy -X:ExceptionDetail [0A]IronPython 2.7.4 (2.7.0.40) on .NET 4.0.30319.34014 (32-bit) [0A]Type "help", "copyright", "credits" or "license" for more information. [0A]>>> from BaseHTTPServer import HTTPServer [0A]>>> from SimpleHTTPServer import SimpleHTTPRequestHandler [0A]>>> HTTPServer(('', 80), SimpleHTTPRequestHandler) [0A]L'adresse IPv4 0.0.0.0 et l'adresse IPv6 ::0 sont des adresses non sp?cifi?es qui ne peuvent pas ?tre utilis?es comme adresses cibles. [0A]Nom du param?tre : hostNameOrAddress [0A] ? System.Net.Dns.GetHostEntry(String hostNameOrAddress) [0A] ? IronPython.Modules.PythonSocket.getfqdn(String host) [0A] ? Microsoft.Scripting.Interpreter.FuncCallInstruction`2.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.LightLambda.Run4[T0,T1,T2,T3,TRet](T0 arg0, T1 arg1, T2 arg2, T3 arg3) [0A] ? System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2) [0A] ? Microsoft.Scripting.Interpreter.FuncCallInstruction`6.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.LightLambda.Run4[T0,T1,T2,T3,TRet](T0 arg0, T1 arg1, T2 arg2, T3 arg3) [0A] ? IronPython.Compiler.Ast.CallExpression.Invoke1Instruction.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.LightLambda.Run2[T0,T1,TRet](T0 arg0, T1 arg1) [0A] ? IronPython.Compiler.PythonCallTargets.OriginalCallTarget1(PythonFunction function, Object arg0) [0A] ? IronPython.Runtime.FunctionCaller`1.Call1(CallSite site, CodeContext context, Object func, T0 arg0) [0A] ? System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2) [0A] ? IronPython.Runtime.FunctionCaller`1.Default1Call1(CallSite site, CodeContext context, Object func, T0 arg0) [0A] ? IronPython.Runtime.Method.MethodBinding.SelfTarget(CallSite site, CodeContext context, Object target) [0A] ? System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite site, T0 arg0, T1 arg1) [0A] ? Microsoft.Scripting.Interpreter.FuncCallInstruction`5.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.LightLambda.Run3[T0,T1,T2,TRet](T0 arg0, T1 arg1, T2 arg2) [0A] ? IronPython.Compiler.Ast.CallExpression.Invoke0Instruction.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.LightLambda.Run5[T0,T1,T2,T3,T4,TRet](T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) [0A] ? IronPython.Compiler.PythonCallTargets.OriginalCallTarget4(PythonFunction function, Object arg0, Object arg1, Object arg2, Object arg3) [0A] ? IronPython.Runtime.FunctionCaller`3.Default1Call3(CallSite site, CodeContext context, Object func, T0 arg0, T1 arg1, T2 arg2) [0A] ? System.Dynamic.UpdateDelegates.UpdateAndExecute5[T0,T1,T2,T3,T4,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) [0A] ? Microsoft.Scripting.Interpreter.FuncCallInstruction`8.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.LightLambda.Run6[T0,T1,T2,T3,T4,T5,TRet](T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5) [0A] ? IronPython.Runtime.Method.MethodBinding`2.SelfTarget(CallSite site, CodeContext context, Object target, T0 arg0, T1 arg1) [0A] ? System.Dynamic.UpdateDelegates.UpdateAndExecute4[T0,T1,T2,T3,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3) [0A] ? Microsoft.Scripting.Interpreter.DynamicInstruction`5.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.LightLambda.Run5[T0,T1,T2,T3,T4,TRet](T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) [0A] ? System.Dynamic.UpdateDelegates.UpdateAndExecute4[T0,T1,T2,T3,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3) [0A] ? Microsoft.Scripting.Interpreter.FuncCallInstruction`7.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.LightLambda.Run5[T0,T1,T2,T3,T4,TRet](T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) [0A] ? IronPython.Compiler.Ast.CallExpression.Invoke2Instruction.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) [0A] ? Microsoft.Scripting.Interpreter.LightLambda.Run2[T0,T1,TRet](T0 arg0, T1 arg1) [0A] ? IronPython.Compiler.PythonScriptCode.RunWorker(CodeContext ctx) [0A] ? IronPython.Compiler.PythonScriptCode.Run(Scope scope) [0A] ? IronPython.Hosting.PythonCommandLine.<>c__DisplayClass1.<RunOneInteraction>b__0() [0A]ValueError: L'adresse IPv4 0.0.0.0 et l'adresse IPv6 ::0 sont des adresses non sp?cifi?es qui ne peuvent pas ?tre utilis?es comme adresses cibles.[0A]Nom du param?tre : hostNameOrAddress [0A]```

"----------------- 2. [New comment] BaseHTTPServer doesn't accept empty string as server address like CPython does http://ironpython.codeplex.com/workitem/29477 User tcalmant has commented on the issue: "

(Don't known what happened with previous comment format)[0A][0A]This error happens only when binding the '::0' IPv6 address: no problem with '0.0.0.0' nor other IPv6 addresses like '::1'.[0A]

As usually I am not able to format things on the first try :-)[0A][0A]```[0A]import ast[0A][0A]class Fix(ast.NodeTransformer):[0A] def visit_UnaryOp(self, node):[0A] if isinstance(node.operand, ast.Num):[0A] if isinstance(node.op, ast.USub):[0A] node.operand.n=-node.operand.n[0A] return node.operand[0A] if isinstance(node.op, ast.UAdd):[0A] return node.operand[0A] return node[0A][0A]def literal_eval_fix(string_only):[0A] tree = ast.parse(string_only, mode="eval" )[0A] tree = Fix().visit(tree)[0A] return ast.literal_eval(tree)[0A][0A]print literal_eval_fix("42")[0A]print literal_eval_fix("-42")[0A]print literal_eval_fix("{ -1:-2, 2:'aaaaa'}")[0A]```

"----------------- 4. [New comment] ast.literal_eval in IronPython raises exception for negative numbers in expressions http://ironpython.codeplex.com/workitem/35572 User s3e3 has commented on the issue: "

Thank you very much for this workaround.[0A]I will use it in our local instance of jenkinsapi package untill this issue is fixed.

"----------------- 5. [New comment] socket.create_connection() causes exception "getaddrinfo returns an empty list" http://ironpython.codeplex.com/workitem/35576 User tcalmant has commented on the issue: "

Indeed, this exception is therefore caused by the lack of server, due to issue #29477[0A]https://ironpython.codeplex.com/workitem/29477

"----------------- 6. [New issue] formatting inconsistency between % and format http://ironpython.codeplex.com/workitem/35580 User paweljasinski has proposed the issue: "IronPython 2.7.5b3 DEBUG (2.7.5.0) on .NET 4.0.30319.18444 (32-bit) Type "help", "copyright", "credits" or "license" for more information. >>> format(9.3126672485384569e+23, ".16e") '9.3126672485384600e+23' >>> "%.16e"%9.3126672485384569e+23 '9.3126672485384569e+23' Given the sys.float_info.dig returning 15, both values are correct, but what bothers me, is that they are different."----------------- 7. [New issue] % formattin for '%f#...' and '%g#...' are broken http://ironpython.codeplex.com/workitem/35581 User paweljasinski has proposed the issue: "detailed list of failing test cases can be found under Languages/IronPython/Tests/formatfloat_testcases.txt"----------------- 8. [New issue] Re-import module using importlib fails http://ironpython.codeplex.com/workitem/35586 User tcalmant has proposed the issue: "Loading a module with importlib.import_module, deleting it in sys.modules then reloading it with importlib causes an exception in IronPython while it is transparent in CPython. With IronPython: C:\Users\Thomas\Documents\Git\ipopo>ipy -X:ExceptionDetail IronPython 2.7.4 (2.7.0.40) on .NET 4.0.30319.34014 (32-bit) Type "help", "copyright", "credits" or "license" for more information. >>> import importlib >>> module1 = importlib.import_module('samples.remote.provider') >>> import sys >>> del sys.modules['samples.remote.provider'] >>> module2 = importlib.import_module('samples.remote.provider') samples.remote.provider ? IronPython.Runtime.PythonDictionary.GetItem(Object key) ? IronPython.Runtime.PythonDictionary.get_Item(Object key) ? Microsoft.Scripting.Interpreter.DynamicInstruction`3.Run(InterpretedFrame frame) ? Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) ? Microsoft.Scripting.Interpreter.LightLambda.Run3[T0,T1,T2,TRet](T0 arg0, T1 arg1, T2 arg2) ? IronPython.Runtime.FunctionCaller`1.Default1Call1(CallSite site, CodeContext context, Object func, T0 arg0) ? System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2) ? Microsoft.Scripting.Interpreter.FuncCallInstruction`6.Run(InterpretedFrame frame) ? Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) ? Microsoft.Scripting.Interpreter.LightLambda.Run4[T0,T1,T2,T3,TRet](T0 arg0, T1 arg1, T2 arg2, T3 arg3) ? IronPython.Compiler.Ast.CallExpression.Invoke1Instruction.Run(InterpretedFrame frame) ? Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) ? Microsoft.Scripting.Interpreter.LightLambda.Run2[T0,T1,TRet](T0 arg0, T1 arg1) ? IronPython.Compiler.PythonScriptCode.RunWorker(CodeContext ctx) ? IronPython.Compiler.PythonScriptCode.Run(Scope scope) ? IronPython.Hosting.PythonCommandLine.<>c__DisplayClass1.b__0() KeyError: samples.remote.provider With Python (here with Python 3.4, but Python 2.7 behaves the same way): C:\Users\Thomas\Documents\Git\ipopo>python Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:45:13) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import importlib >>> module1 = importlib.import_module('samples.remote.provider') >>> import sys >>> del sys.modules['samples.remote.provider'] >>> module2 = importlib.import_module('samples.remote.provider') >>> module1 is module2 False "----------------- 9. [New comment] Re-import module using importlib fails http://ironpython.codeplex.com/workitem/35586 User tcalmant has commented on the issue: "

It seems to only happen for modules under packages:[0A][0A]- urlparse works[0A]- logging.config raises the error