From vilibald.wanca at gmail.com Tue Oct 1 11:44:44 2013 From: vilibald.wanca at gmail.com (Vilibald Wanca) Date: Tue, 1 Oct 2013 11:44:44 +0200 Subject: [Ironpython-users] newbie : Building exe from script Message-ID: Hi all, as a newbie to IronPython and .NET in general I'm trying to build an executable from a .py scripts using the pyc.py : c:\SRC\GEWSTest>ipy.exe c:/"Program Files (x86)"/"IronPython 2.7"/Tools/Scripts/pyc.py /main:mymain.py /platform:x64 /target:exe The build seems to be successful but when I try to execute it I get an Exception : " Unhandled Exception: IronPython.Runtime.Exceptions.ImportException: No module named ConfigParser " Do I need to copy some dlls or am I missing some step in preparing the project? Thanks a lot for any help. vilda From no_reply at codeplex.com Fri Oct 4 09:26:22 2013 From: no_reply at codeplex.com (CodePlex) Date: 4 Oct 2013 00:26:22 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 10/3/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] io.open and mmap ---------------------------------------------- ISSUES 1. [New issue] io.open and mmap http://ironpython.codeplex.com/workitem/34528 User Libbnor has proposed the issue: "with io.open("somefile", "r+b") as f: mm = mmap.mmap(f.fileno(), 0) fails with: mmap.error: [Errno 9] Bad file descriptor" ---------------------------------------------- ---------------------------------------------- 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 Oct 5 09:20:56 2013 From: no_reply at codeplex.com (CodePlex) Date: 5 Oct 2013 00:20:56 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 10/4/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] bytes.decode() encoding should default to sys.getdefaultencoding(), not None ---------------------------------------------- ISSUES 1. [New issue] bytes.decode() encoding should default to sys.getdefaultencoding(), not None http://ironpython.codeplex.com/workitem/34532 User marcel_r has proposed the issue: "---------------------------------------------------------------------------------------------------- IP VERSION AFFECTED: 2.7.4 BUILD TYPE: Release FLAGS PASSED TO IPY.EXE: None OPERATING SYSTEM: 32-bit WinXP CLR VERSION: .NET 4.0 ---------------------------------------------------------------------------------------------------- BRIEF DESCRIPTION: The method bytes.decode([encoding[,errors]]) can be called without arguments. In this case, according to Python documentation, "encoding will be the default encoding," which I believe is the value returned from sys.getdefaultencoding(). This works on CPython 2.7. On IronPython 2.7.4, however, encoding apparently defaults to None, causing a TypeError whenever you call bytes.encoding() without arguments. Note that str.decode() doesn't have this problem. ---------------------------------------------------------------------------------------------------- REPRODUCTION SNIPPET: "foo".decode() 'foo' b"foo".decode() Traceback (most recent call last): File "", line 1, in TypeError: decode() expected string, got 'NoneType' import sys b"foo".decode(sys.getdefaultencoding()) 'foo' " ---------------------------------------------- ---------------------------------------------- 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 avinhan at gmail.com Mon Oct 7 01:22:07 2013 From: avinhan at gmail.com (Aravin) Date: Mon, 7 Oct 2013 10:22:07 +1100 Subject: [Ironpython-users] Embedded IronPython and Python Libraries Message-ID: Hi All, I am having some issues with embedded ironpython and using standard python libraries. I have installed IronPython 2.7.4 and copied the "lib" folder to my applications output directory. I have added the path for the "lib" directory in Engine.SetSearchPaths(). However it is unable to load any packages installed in "site-packages". To get around this I need to add "lib\site-packages" to the search path. Is this the correct approach or am I doing something wrong? Also, I installed numpy and scipy and it works fine from IronPython. However in my application when I try to import numpy, it gives an error, "No module found: mtrand". If I import clr and and do clr.AddReference('mtrand'), then import numpy it all works fine. So it seems like ironpython looks into dll's when we import a module, but my embedded engine does not. How do I fix this? Regards, Aravin -------------- next part -------------- An HTML attachment was scrubbed... URL: From no_reply at codeplex.com Tue Oct 8 09:21:40 2013 From: no_reply at codeplex.com (CodePlex) Date: 8 Oct 2013 00:21:40 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 10/7/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] IronPython Memory Leak When Calling Function With More Than 13 Parameters ---------------------------------------------- ISSUES 1. [New comment] IronPython Memory Leak When Calling Function With More Than 13 Parameters http://ironpython.codeplex.com/workitem/30131 User tansm has commented on the issue: "

I too.

" ---------------------------------------------- ---------------------------------------------- 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 misnomer at gmail.com Thu Oct 10 17:59:11 2013 From: misnomer at gmail.com (Nicholas Devenish) Date: Thu, 10 Oct 2013 16:59:11 +0100 Subject: [Ironpython-users] Calling len() on a DynamicObject instance? Message-ID: Hi All, I have a DynamicObject subclass that is being passed into IronPython. Sometimes, this subclass represents a collection - at which point it is currently either Enumerated through TryConvert or Indexed by TryGetIndex. However, when in python code calling len(myobject), I get the error "len() of unsized object" - And I can't work out what it is doing such that I can get this to work - I thought the TryUnaryOperation overload might be involved, but it doesn't seem to get called at all. Is there a way to achieve this? Thanks, Nick From misnomer at gmail.com Thu Oct 10 18:40:47 2013 From: misnomer at gmail.com (Nicholas Devenish) Date: Thu, 10 Oct 2013 17:40:47 +0100 Subject: [Ironpython-users] Calling len() on a DynamicObject instance? In-Reply-To: References: Message-ID: On 10 Oct 2013, at 17:36, Jeff Hardy wrote: > I haven't looked at the implementation of len() yet, so I could be > wrong, but my guess is that if your object doesn't implement IList (or > something else with .Count) it will look for a __len__ method > (http://bit.ly/16TDkIJ) on the object. This should be reified as a > call to TryGetMember/TryInvoke, so you should be able to selectively > provide __len__ for those objects that are collections and leave it > out for those that are not. In my tests, it wasn't trying to resolve __len__ on the dynamic object (I specifically tracked everything going through in case this was the solution). For now, I'll just return an IList-implementing separate DynamicObject subclass when appropriate. Thanks, Nick From jdhardy at gmail.com Thu Oct 10 18:36:49 2013 From: jdhardy at gmail.com (Jeff Hardy) Date: Thu, 10 Oct 2013 09:36:49 -0700 Subject: [Ironpython-users] Calling len() on a DynamicObject instance? In-Reply-To: References: Message-ID: On Thu, Oct 10, 2013 at 8:59 AM, Nicholas Devenish wrote: > Hi All, > > I have a DynamicObject subclass that is being passed into IronPython. Sometimes, this subclass represents a collection - at which point it is currently either Enumerated through TryConvert or Indexed by TryGetIndex. > > However, when in python code calling len(myobject), I get the error "len() of unsized object" - And I can't work out what it is doing such that I can get this to work - I thought the TryUnaryOperation overload might be involved, but it doesn't seem to get called at all. > > Is there a way to achieve this? I haven't looked at the implementation of len() yet, so I could be wrong, but my guess is that if your object doesn't implement IList (or something else with .Count) it will look for a __len__ method (http://bit.ly/16TDkIJ) on the object. This should be reified as a call to TryGetMember/TryInvoke, so you should be able to selectively provide __len__ for those objects that are collections and leave it out for those that are not. - Jeff From no_reply at codeplex.com Sat Oct 12 09:19:06 2013 From: no_reply at codeplex.com (CodePlex) Date: 12 Oct 2013 00:19:06 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 10/11/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] Can't call custom extension method that takes a string instead of a Predicate ---------------------------------------------- ISSUES 1. [New issue] Can't call custom extension method that takes a string instead of a Predicate http://ironpython.codeplex.com/workitem/34550 User ekolis has proposed the issue: "Details here: http://stackoverflow.com/questions/19328892/cant-use-custom-extension-methods-with-ironpython" ---------------------------------------------- ---------------------------------------------- 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 Oct 13 09:26:45 2013 From: no_reply at codeplex.com (CodePlex) Date: 13 Oct 2013 00:26:45 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 10/12/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] import hides modules ---------------------------------------------- ISSUES 1. [New issue] import hides modules http://ironpython.codeplex.com/workitem/34551 User paweljasinski has proposed the issue: "As mentioned here: https://github.com/ipython/ipython/issues/4062 and here: https://github.com/IronLanguages/main/issues/123 ironpython has import related problem triggered by release version of ipython. I have managed to narrow it down - test attached. Session under linux/cpython rejap at eb60:~/ip$ python t.py importing IP/__init__ importing m2 importing m1 ['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__path__', 'core', 'fnx', 'start'] Session under win7/ironpython Z:\rejap\ip>ipy t.py importing IP/__init__ importing m2 importing m1 ['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__path__', 'core.m2', 'fnx', 'start'] Traceback (most recent call last): File "t.py", line 2, in File "Z:\rejap\ip\IP\__init__.py", line 4, in start File "Z:\rejap\ip\IP\core\m2.py", line 6, in fnx AttributeError: 'module' object has no attribute 'core' " ---------------------------------------------- ---------------------------------------------- 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 Oct 17 09:20:26 2013 From: no_reply at codeplex.com (CodePlex) Date: 17 Oct 2013 00:20:26 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 10/16/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] Ipy Crash...Please help ---------------------------------------------- ISSUES 1. [New issue] Ipy Crash...Please help http://ironpython.codeplex.com/workitem/34567 User alabview has proposed the issue: "Hi there, I am new to Python scripting language. I hope you all can help me. I am running a python script in IronPython for a few times continuously with different variable but with same DLL and it reported as CRASH. There is no issue if I run once. But, it never happen on Python 2.7 and 3.3. Please help me... I have attached the screenshot and Python code for your reference. Python Code, from ctypes import * from sys import exit CLOSEDLOOP="CLOSEDLOOP{SOURCE|VOLTAGE|CH2|0.5|0|10|1000}" CLOSEDLOOPSTATUS="" INPUT2=c_char_p(CLOSEDLOOP.encode()) OUTPUT2=c_char_p(CLOSEDLOOPSTATUS.encode()) Y2 = c_int(100) Ypoint2 = pointer(Y2) CallDLL2 = cdll.LoadLibrary("C:\INSTRDLL\RAMP.dll") Output2 = CallDLL2.LINEARRAMP Output2.argtype = [c_char_p,c_char_p,c_int] Output2(INPUT2,OUTPUT2,Ypoint2) CLOSEDLOOPERRSTATUS = OUTPUT2.value.decode("utf-8") print(CLOSEDLOOPERRSTATUS) from ctypes import * from sys import exit CLOSEDLOOP="CLOSEDLOOP{SOURCE|VOLTAGE|CH2|0.5|0|10|1000}" CLOSEDLOOPSTATUS="" INPUT2=c_char_p(CLOSEDLOOP.encode()) OUTPUT2=c_char_p(CLOSEDLOOPSTATUS.encode()) Y2 = c_int(100) Ypoint2 = pointer(Y2) CallDLL2 = cdll.LoadLibrary("C:\INSTRDLL\RAMP.dll") Output2 = CallDLL2.LINEARRAMP Output2.argtype = [c_char_p,c_char_p,c_int] Output2(INPUT2,OUTPUT2,Ypoint2) CLOSEDLOOPERRSTATUS = OUTPUT2.value.decode("utf-8") print(CLOSEDLOOPERRSTATUS) from ctypes import * from sys import exit CLOSEDLOOP="CLOSEDLOOP{SOURCE|VOLTAGE|CH2|0.5|0|10|1000}" CLOSEDLOOPSTATUS="" INPUT2=c_char_p(CLOSEDLOOP.encode()) OUTPUT2=c_char_p(CLOSEDLOOPSTATUS.encode()) Y2 = c_int(100) Ypoint2 = pointer(Y2) CallDLL2 = cdll.LoadLibrary("C:\INSTRDLL\RAMP.dll") Output2 = CallDLL2.LINEARRAMP Output2.argtype = [c_char_p,c_char_p,c_int] Output2(INPUT2,OUTPUT2,Ypoint2) CLOSEDLOOPERRSTATUS = OUTPUT2.value.decode("utf-8") print(CLOSEDLOOPERRSTATUS) Walter." ---------------------------------------------- ---------------------------------------------- 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 Fri Oct 18 09:21:35 2013 From: no_reply at codeplex.com (CodePlex) Date: 18 Oct 2013 00:21:35 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 10/17/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] Import modules from a zip archive containing non-ASCII characters does not work ---------------------------------------------- ISSUES 1. [New issue] Import modules from a zip archive containing non-ASCII characters does not work http://ironpython.codeplex.com/workitem/34571 User vabe has proposed the issue: "Example module(encoding windows-1251): # coding=windows-1251 print "?????? ???!" If import the module from the zip file does not print "?????? ???!"" ---------------------------------------------- ---------------------------------------------- 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 eirik.ardal at bouvet.no Fri Oct 18 10:20:47 2013 From: eirik.ardal at bouvet.no (=?iso-8859-1?Q?Eirik_=C5rdal?=) Date: Fri, 18 Oct 2013 08:20:47 +0000 Subject: [Ironpython-users] Issues with multithreading, ironpython and numpy Message-ID: <3E4778095ED11E47BAD0E6632E57BD1826EAB179@EXMB1.bouvet.no> Hi First, let me start by saying that I don't have a lot of experience with Iron Python, or Python for that matter, but I know a person involved with the current project who is an experienced Python developer, but is unable to help with this issue since we believe it has to do with our integration between my C# code and his Python code. Also, I am aware that this might not be directly a IronPython issue, but it's certainly involving IronPython, NymPy for .net and C# and integration between them. The short version of our problem is that when I call his Python scripts through IronPython in a multithreaded context, I get a System.InsufficientMemoryException thrown by NumPyDotNet. However, if I run my code synchronously on one thread, it works fine. The long version is that I have a Windows Service that constantly checks in a database for new entries that will trigger work to be done (calculating data). I need to be able to do the calculation work on another thread in order to not lock up the service, making it unresponsive. But calling the Python scripts through IronPython on my worker thread results in the exception above. If I run my code on one thread, the service is unresponsive during start-up and windows terminates it after a certain time, saying it could not put it into its "started" state since its locked by work. I have tried various ways to do my work asynchronous, like starting a Task and using the timers in Microsoft's libraries. I have not tried async/await from .net 4.5 since upgrading to .net 4.5 is not desireable by the project management. The same problem was explained (not by me) in this stackoverflow post http://stackoverflow.com/questions/10003344/ironpython-version-of-numpy-doesnt-work-in-multi-threaded-environment but there are very few other similar issues when I search forums. Any suggestions or tips will be greatly appreciated. Eirik ?rdal / 54?24'42" S 3?25'33" E Konsulent Bouvet Norge AS, Solheimsgaten 15, NO-5058 Bergen Mobil +47 992 999 31 http://www.bouvet.no eirik.ardal at bouvet.no [bouvetlogomini] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1671 bytes Desc: image003.jpg URL: From rome at Wintellect.com Fri Oct 18 18:37:24 2013 From: rome at Wintellect.com (Keith Rome) Date: Fri, 18 Oct 2013 16:37:24 +0000 Subject: [Ironpython-users] Issues with multithreading, ironpython and numpy In-Reply-To: <3E4778095ED11E47BAD0E6632E57BD1826EAB179@EXMB1.bouvet.no> Message-ID: Your threading code isn't as correct or robust as you think it is, if you are getting service startup timeout errors. Windows assumes that the service control callbacks will be executed quickly without being blocked. Typically, the Start callback would be creating the service's main work thread, starting it (without waiting on anything from it), and then immediately returning to the SCM. This should generally be an activity that takes up to perhaps a second at most, but the SCM gives you a wide grace period - you should never be coming close to that timeout unless something really serious is wrong. Similarly, the Stop and Pause/Resume callbacks would typically use thread synchronization objects (Manual/Auto Reset Events are very common) to communicate the requested operation to the main work thread without blocking. Of course, this all means that your main work thread needs to be extremely robust and needs to regularly check for those event signals (and discontinue work with minimal latency) - which is not entirely trivial unless you have a fair amount [successful] of experience with it. SCM timeout errors are indicating an insufficient service design. Depending on what your scripts are doing have you considered just using Process.Start() to invoke them, or to invoke a small managed executable that wraps the script execution? There is more overhead with this approach but it is significantly less hassle (and more robust) than dealing with a service threading model if you aren't experienced in such things. Keith Rome Principal Architect @ Wintellect (www.wintellect.com) 770.617.4016 | krome at wintellect.com [cid:DB4B3CED-8E4A-4404-A5B0-2853E1AA014D] Register today for access to our high-quality on-demand training resources! Use promotion code ROME-13 to activate your 14-day free trial. From: Eirik ?rdal > Date: Friday, October 18, 2013 4:20 AM To: "ironpython-users at python.org" > Subject: [Ironpython-users] Issues with multithreading, ironpython and numpy Hi First, let me start by saying that I don't have a lot of experience with Iron Python, or Python for that matter, but I know a person involved with the current project who is an experienced Python developer, but is unable to help with this issue since we believe it has to do with our integration between my C# code and his Python code. Also, I am aware that this might not be directly a IronPython issue, but it's certainly involving IronPython, NymPy for .net and C# and integration between them. The short version of our problem is that when I call his Python scripts through IronPython in a multithreaded context, I get a System.InsufficientMemoryException thrown by NumPyDotNet. However, if I run my code synchronously on one thread, it works fine. The long version is that I have a Windows Service that constantly checks in a database for new entries that will trigger work to be done (calculating data). I need to be able to do the calculation work on another thread in order to not lock up the service, making it unresponsive. But calling the Python scripts through IronPython on my worker thread results in the exception above. If I run my code on one thread, the service is unresponsive during start-up and windows terminates it after a certain time, saying it could not put it into its "started" state since its locked by work. I have tried various ways to do my work asynchronous, like starting a Task and using the timers in Microsoft's libraries. I have not tried async/await from .net 4.5 since upgrading to .net 4.5 is not desireable by the project management. The same problem was explained (not by me) in this stackoverflow post http://stackoverflow.com/questions/10003344/ironpython-version-of-numpy-doesnt-work-in-multi-threaded-environment but there are very few other similar issues when I search forums. Any suggestions or tips will be greatly appreciated. Eirik ?rdal / 54?24'42" S 3?25'33" E Konsulent Bouvet Norge AS, Solheimsgaten 15, NO-5058 Bergen Mobil +47 992 999 31 http://www.bouvet.no eirik.ardal at bouvet.no [bouvetlogomini] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 529A2558-817C-467F-8E7E-0789B90D675C[26].png Type: image/png Size: 6285 bytes Desc: 529A2558-817C-467F-8E7E-0789B90D675C[26].png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1671 bytes Desc: image003.jpg URL: From no_reply at codeplex.com Sat Oct 19 09:20:35 2013 From: no_reply at codeplex.com (CodePlex) Date: 19 Oct 2013 00:20:35 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 10/18/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] import hides modules ---------------------------------------------- ISSUES 1. [New comment] import hides modules http://ironpython.codeplex.com/workitem/34551 User paweljasinski has commented on the issue: "

fixed in 94b55df ipy-2.7-maint

" ---------------------------------------------- ---------------------------------------------- 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 Oct 27 18:51:42 2013 From: no_reply at codeplex.com (CodePlex) Date: 27 Oct 2013 10:51:42 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 10/26/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] Importing .NET types causes ImportExceptions (zipimport handler) ---------------------------------------------- ISSUES 1. [New issue] Importing .NET types causes ImportExceptions (zipimport handler) http://ironpython.codeplex.com/workitem/34602 User sopelt has proposed the issue: "When hosting IronPython in a C#/.NET application the first import of a .NET type (and possibly non-zip python modules?) causes an internally thrown and ignored IronPython.Runtime.Exceptions.ImportException having not a Zip file as its message. This seem to happen during initial construction of the zipimporter. In situations where third-party libraries are being debugged or profiled in a project using IronPython this can cause lots of unwanted exceptions and complicate development. A minimal example could look like: namespace ConsoleApplication { using IronPython.Hosting; class Program { static void Main(string[] args) { var e = Python.CreateEngine(); var source = e.CreateScriptSourceFromString(@"from System import Guid"); var result = source.Execute(); } } } with the resulting stack at the time of the unwanted exception as > IronPython.Modules.dll!IronPython.Runtime.ZipImportModule.zipimporter.zipimporter(IronPython.Runtime.CodeContext context, object pathObj, System.Collections.Generic.IDictionary kwArgs) Line 142 C# [Native to Managed Transition] Microsoft.Dynamic.dll!Microsoft.Scripting.Interpreter.NewInstruction.Run(Microsoft.Scripting.Interpreter.InterpretedFrame frame) Line 73 C# Microsoft.Dynamic.dll!Microsoft.Scripting.Interpreter.Interpreter.Run(Microsoft.Scripting.Interpreter.InterpretedFrame frame) Line 126 C# Microsoft.Dynamic.dll!Microsoft.Scripting.Interpreter.LightLambda.Run4(System.Runtime.CompilerServices.CallSite arg0, IronPython.Runtime.CodeContext arg1, object arg2, object arg3) Line 165 C# System.Core.dll!System.Dynamic.UpdateDelegates.UpdateAndExecute3(System.Runtime.CompilerServices.CallSite site, IronPython.Runtime.CodeContext arg0, object arg1, object arg2) Unknown IronPython.dll!IronPython.Runtime.PythonContext.Call(IronPython.Runtime.CodeContext context, object func, object arg0) Line 2827 C# IronPython.dll!IronPython.Runtime.Operations.PythonCalls.Call(IronPython.Runtime.CodeContext context, object func, object arg0) Line 30 C# IronPython.dll!IronPython.Runtime.Importer.FindImporterForPath(IronPython.Runtime.CodeContext context, string dirname) Line 884 C# IronPython.dll!IronPython.Runtime.Importer.ImportFromPathHook(IronPython.Runtime.CodeContext context, string name, string fullName, IronPython.Runtime.List path, System.Func defaultLoader) Line 836 C# IronPython.dll!IronPython.Runtime.Importer.ImportFromPath(IronPython.Runtime.CodeContext context, string name, string fullName, IronPython.Runtime.List path) Line 818 C# IronPython.dll!IronPython.Runtime.Importer.ImportTopAbsolute(IronPython.Runtime.CodeContext context, string name) Line 622 C# IronPython.dll!IronPython.Runtime.Importer.ImportModule(IronPython.Runtime.CodeContext context, object globals, string modName, bool bottom, int level) Line 262 C# IronPython.dll!IronPython.Modules.Builtin.__import__(IronPython.Runtime.CodeContext context, string name, object globals, object locals, object fromlist, int level) Line 108 C# Microsoft.Dynamic.dll!Microsoft.Scripting.Interpreter.FuncCallInstruction.Run(Microsoft.Scripting.Interpreter.InterpretedFrame frame) Line 812 C# Microsoft.Dynamic.dll!Microsoft.Scripting.Interpreter.Interpreter.Run(Microsoft.Scripting.Interpreter.InterpretedFrame frame) Line 126 C# Microsoft.Dynamic.dll!Microsoft.Scripting.Interpreter.LightLambda.Run7(System.Runtime.CompilerServices.CallSite arg0, IronPython.Runtime.CodeContext arg1, object arg2, string arg3, IronPython.Runtime.PythonDictionary arg4, IronPython.Runtime.PythonDictionary arg5, IronPython.Runtime.PythonTuple arg6) Line 282 C# System.Core.dll!System.Dynamic.UpdateDelegates.UpdateAndExecute6(System.Runtime.CompilerServices.CallSite site, IronPython.Runtime.CodeContext arg0, object arg1, string arg2, IronPython.Runtime.PythonDictionary arg3, IronPython.Runtime.PythonDictionary arg4, IronPython.Runtime.PythonTuple arg5) Unknown IronPython.dll!IronPython.Runtime.Importer.ImportLightThrow(IronPython.Runtime.CodeContext context, string fullName, IronPython.Runtime.PythonTuple from, int level) Line 64 C# IronPython.dll!IronPython.Runtime.Operations.PythonOps.ImportWithNames(IronPython.Runtime.CodeContext context, string fullName, string[] names, int level) Line 1805 C# Microsoft.Dynamic.dll!Microsoft.Scripting.Interpreter.FuncCallInstruction.Run(Microsoft.Scripting.Interpreter.InterpretedFrame frame) Line 764 C# Microsoft.Dynamic.dll!Microsoft.Scripting.Interpreter.Interpreter.Run(Microsoft.Scripting.Interpreter.InterpretedFrame frame) Line 126 C# Microsoft.Dynamic.dll!Microsoft.Scripting.Interpreter.LightLambda.Run1(IronPython.Runtime.FunctionCode arg0) Line 66 C# IronPython.dll!IronPython.Compiler.RuntimeScriptCode.InvokeTarget(Microsoft.Scripting.Runtime.Scope scope) Line 79 C# IronPython.dll!IronPython.Compiler.RuntimeScriptCode.Run() Line 55 C# Microsoft.Scripting.dll!Microsoft.Scripting.SourceUnit.Execute() Line 249 C# Microsoft.Scripting.dll!Microsoft.Scripting.Hosting.ScriptSource.Execute() Line 143 C# ConsoleApplication2.exe!ConsoleApplication.Program.Main(string[] args) Line 11 C# [Native to Managed Transition] mscorlib.dll!System.AppDomain.ExecuteAssembly(string assemblyFile, System.Security.Policy.Evidence assemblySecurity, string[] args) Unknown Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() Unknown mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) Unknown mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) Unknown mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) Unknown mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) Unknown mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() Unknown " ---------------------------------------------- ---------------------------------------------- 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 Oct 28 08:20:24 2013 From: no_reply at codeplex.com (CodePlex) Date: 28 Oct 2013 00:20:24 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 10/27/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] Importing .NET types causes ImportExceptions (zipimport handler) 2. [New comment] Importing .NET types causes ImportExceptions (zipimport handler) ---------------------------------------------- ISSUES 1. [New comment] Importing .NET types causes ImportExceptions (zipimport handler) http://ironpython.codeplex.com/workitem/34602 User slide_o_mix has commented on the issue: "

This is how the python importer works. The importer is supposed to raise an exception if the importer can't handle that type of import. So, in short this behavior needs to be maintained for compatibility.

"----------------- 2. [New comment] Importing .NET types causes ImportExceptions (zipimport handler) http://ironpython.codeplex.com/workitem/34602 User jdhardy has commented on the issue: "

I usually just tell the debugger to ignore those exceptions.

One option to mitigate could be switching to lightweight exceptions, which don't throw a real exception but fake it instead. They're faster too, but it one has to remember to deal with them or they get ignored.

" ---------------------------------------------- ---------------------------------------------- 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 Tue Oct 29 08:22:33 2013 From: no_reply at codeplex.com (CodePlex) Date: 29 Oct 2013 00:22:33 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 10/28/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] Importing .NET types causes ImportExceptions (zipimport handler) 2. [New issue] help() commands from StdLib fail/hang ---------------------------------------------- ISSUES 1. [New comment] Importing .NET types causes ImportExceptions (zipimport handler) http://ironpython.codeplex.com/workitem/34602 User sopelt has commented on the issue: "

Thank you for the quick response.

> this behavior needs to be maintained for compatibility

So the importer architecture and implementation is specified to that detail?


> just tell the debugger to ignore those exceptions

I know that Visual Studio's "Just my Code" will help for many situations but we often run into the scenario that we want to see "significant" exceptions occuring in third party libraries.

> lightweight exceptions

What do you mean by lightweight exceptions in the context of .NET/DLR/IronPython? Is there a concept for that or do you mean using something like return codes? I don't expect this to be super-easy because the exception seems to be thrown by the zipimporter constructor.

I am not quite sure why the zipimporter needs to be consulted at all for non-zipfile situations but I must admit that I haven't looked into the spec and the code with too much detail...

"----------------- 2. [New issue] help() commands from StdLib fail/hang http://ironpython.codeplex.com/workitem/34606 User owlmonkey has proposed the issue: "We incorporate IronPython into our app as a console and it's super handy for reflection of our objects. Some folks like using the stdlib pydoc help commands to get a summary of object methods and usage. This started failing and/or hanging our process when we upgraded to IronPython 2.6.2 and now 2.7.4 so I finally dug into it. Looks like the problem is in the StdLib, in that it doesn't recognize the "cli" returned from sys.platform in the pydoc module. As a result it chooses a pipedpager which then fails or hangs based on the output length. Specifically it's in the code that determines what kind of pager to use, for long outputs. It checks for sys.platform to see if it should use a pipe (on unix presumably) or a temporary file or just stream the output directly. What's happening in our system on Windows or on Mono is that sys.platform returns "cli" and the code tries to use a pager that's not really supported. And then the IO.StreamWriter it uses can hang if it buffer overflows. My workaround for now is to add some code to check for a "cli" response to that file and have it return a plainpager instead of a pipedpager. This worked around the problem fully for us. So when including the StdLib code into the IronPython project, would be super helpful to incorporate some diffs wherever it uses sys.platform based logic to also recognize "cli"" ---------------------------------------------- ---------------------------------------------- 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 Wed Oct 30 08:21:34 2013 From: no_reply at codeplex.com (CodePlex) Date: 30 Oct 2013 00:21:34 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 10/29/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] Importing .NET types causes ImportExceptions (zipimport handler) 2. [New comment] Importing .NET types causes ImportExceptions (zipimport handler) 3. [New comment] help() commands from StdLib fail/hang ---------------------------------------------- ISSUES 1. [New comment] Importing .NET types causes ImportExceptions (zipimport handler) http://ironpython.codeplex.com/workitem/34602 User jdhardy has commented on the issue: "

slide wrote the `zipimport` support, so I'll defer to him on the specification and the implementation details.

[Lightweight exceptions](https://github.com/IronLanguages/main/blob/master/Runtime/Microsoft.Dynamic/Runtime/LightExceptions.cs) are a DLR feature that IronPython uses to pass exception information without using real .NET exceptions. `zipimport` might need some refactoring to use light exceptions, but it should be possible.

Unfortunately one has to be careful when using them, as any C# calling code has to be aware that it is dealing with a light throwing function and either be light throwing itself or wrap the call with `LightExceptions.CheckAndThrow`. Functions that are called directly from Python have it easier because IronPython will automatically deal with those and convert them to Python exceptions as needed.

"----------------- 2. [New comment] Importing .NET types causes ImportExceptions (zipimport handler) http://ironpython.codeplex.com/workitem/34602 User sopelt has commented on the issue: "

Thanks for all the info. We would be really happy if there was some way to resolve this situation.

As a workaround we would even prefer temporarily disabling zipimport support.
I had a look at the code but there currently does not seem to be any public api which would allow that (e.g. removing from path_hooks...).

"----------------- 3. [New comment] help() commands from StdLib fail/hang http://ironpython.codeplex.com/workitem/34606 User vernondcole has commented on the issue: "

Owlmonkey:

You should pass this patch on to the python core group.

Much to my surprise, an IronPython specific patch of mine was accepted and is now part of the standard library. My patch was related to the correct operation of "import antigravity" -- yours is somewhat more important. ;-)

" ---------------------------------------------- ---------------------------------------------- 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 Oct 31 08:22:38 2013 From: no_reply at codeplex.com (CodePlex) Date: 31 Oct 2013 00:22:38 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 10/30/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] help() commands from StdLib fail/hang 2. [New comment] help() commands from StdLib fail/hang ---------------------------------------------- ISSUES 1. [New comment] help() commands from StdLib fail/hang http://ironpython.codeplex.com/workitem/34606 User owlmonkey has commented on the issue: "

Thanks for the encouragement. Just submitted as issue 19453 for this with the core group:
http://bugs.python.org/issue19453

"----------------- 2. [New comment] help() commands from StdLib fail/hang http://ironpython.codeplex.com/workitem/34606 User jdhardy has commented on the issue: "

FWIW the plan for IronPython 3 is to ship the Python stdlib unmodified - all required changes will go upstream rather then be maintained as part of IronPython. Because Python 2.7 is in maintenance mode the stdlibs will remain forked.

" ---------------------------------------------- ---------------------------------------------- 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: