From jwhitby at gmail.com Thu Nov 1 02:09:29 2012 From: jwhitby at gmail.com (Jared Whitby) Date: Wed, 31 Oct 2012 21:09:29 -0400 Subject: [Ironpython-users] clrtype.py duplicate type name within an assembly In-Reply-To: References: Message-ID: The existing scripting system is c#/codedom and uses reflection to find attributes on classes and methods in the assembly compiled and loaded at runtime. After finding out about clrtype.py I thought the IronPython implementation could be very easy without changing much of the existing code, until I tried reloading the script. I did have some luck getting the script to reload by changing the get_clr_type_name def in clrtype.py to add a unique string to the end of the name. I haven't spent a lot of time testing that to fully understand the ramifications though. I don't think I really care what the clrtype name is, as long as I can get an instance of it. And if its different every time, that eliminates the duplicate type name exception. I guess ideally it would only generate the unique string when the script is reloaded, but right now it generates a new one every time the function it is called. I'm sure that can't be good... need to find a way around that. Which set of DLR APIs can you use to query the objects? I know about the python inspect module, is there something similar in the DLR api? Thanks, Jared On Wed, Oct 31, 2012 at 11:53 AM, Jeff Hardy wrote: > On Tue, Oct 30, 2012 at 8:13 PM, Jared Whitby wrote: >> Hey guys, >> >> I've been trying to use IronPython as a scripting solution in a project I am >> working on. I am using clrtype.py from the clrtype sample to expose >> attributes on methods into c# so I can use reflection to register them with >> my application. The first time the script runs, everything works fine. But I >> want the users to be able to change the script while the application is >> running so I need to load and run the script again. When I try to load and >> run the script a second time I get a ArgumentException ?Duplicate type name >> within an assembly?. >> >> ... >> >> Any ideas how to get around this? Am I doing something wrong that you can >> see? > > It's a limitation of how IronPython generates code (and by extension, > clrtype.py). When it runs, it creates a dynamic assembly and creates > types in it, but it only does this once per process. Your use case is > interesting, and one that I don't think was ever considered - it was > assumed that the scripts (using clrtypes) would not be reloaded. One > potential issue is that I believe dynamic assemblies cannot be garbage > collected, although this may have changed in newer version of the CLR > (I can't keep track anymore!). > > Would it be possible to not use reflection? Or does your system > require it for other reasons? You could potentially use the DLR APIs > to query the objects and then register them, which would avoid the use > of clrtypes at all. > > - Jeff From niki at vintech.bg Thu Nov 1 09:18:53 2012 From: niki at vintech.bg (niki) Date: Thu, 01 Nov 2012 10:18:53 +0200 Subject: [Ironpython-users] ANN: Python Tools for Visual Studio 1.5 In-Reply-To: <66535cac8282494cb7dcddea5f726379@BY2PR03MB596.namprd03.prod.outlook.com> References: <66535cac8282494cb7dcddea5f726379@BY2PR03MB596.namprd03.prod.outlook.com> Message-ID: <5092306D.7080302@vintech.bg> What is minimal VS version supported? Thanks, Niki From s.j.dower at gmail.com Thu Nov 1 15:14:05 2012 From: s.j.dower at gmail.com (Steve Dower) Date: Thu, 1 Nov 2012 07:14:05 -0700 Subject: [Ironpython-users] ANN: Python Tools for Visual Studio 1.5 In-Reply-To: <5092306D.7080302@vintech.bg> References: <66535cac8282494cb7dcddea5f726379@BY2PR03MB596.namprd03.prod.outlook.com> <5092306D.7080302@vintech.bg> Message-ID: It won't work with the express editions, but you can download the (free) integrated/isolated shell (two downloads, about ~230MB all up) and install into that. The only feature that you'll miss out on is profiling, which requires Premium or higher. If you meant year-versions, PTVS supports VS2010 and VS2012. There aren't any feature differences between the two versions, but VS2012 is generally better all-round (despite the UI changes), so I'd recommend it if you can get it. Cheers, Steve On Thu, Nov 1, 2012 at 1:18 AM, niki wrote: > What is minimal VS version supported? > > Thanks, > Niki > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users From brian at python.org Thu Nov 1 15:19:19 2012 From: brian at python.org (Brian Curtin) Date: Thu, 1 Nov 2012 09:19:19 -0500 Subject: [Ironpython-users] ANN: Python Tools for Visual Studio 1.5 In-Reply-To: <66535cac8282494cb7dcddea5f726379@BY2PR03MB596.namprd03.prod.outlook.com> References: <66535cac8282494cb7dcddea5f726379@BY2PR03MB596.namprd03.prod.outlook.com> Message-ID: On Wed, Oct 31, 2012 at 5:09 PM, Dino Viehland wrote: > We?re pleased to announce the release of Python Tools for Visual Studio 1.5 > RTM And I am pleased to install it! Great work, as always, by the team. From jdhardy at gmail.com Thu Nov 1 22:47:23 2012 From: jdhardy at gmail.com (Jeff Hardy) Date: Thu, 1 Nov 2012 14:47:23 -0700 Subject: [Ironpython-users] clrtype.py duplicate type name within an assembly In-Reply-To: References: Message-ID: On Wed, Oct 31, 2012 at 6:09 PM, Jared Whitby wrote: > Which set of DLR APIs can you use to query the objects? I know about > the python inspect module, is there something similar in the DLR api? The ObjectOperations, exposed via ScriptEngine.Operations. You can do things like engine.Operations.GetMember(obj, "foo") to work with DLR objects. - Jeff From no_reply at codeplex.com Sat Nov 3 15:18:43 2012 From: no_reply at codeplex.com (no_reply at codeplex.com) Date: 3 Nov 2012 07:18:43 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 11/2/2012 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] Sockets are not properly closed 2. [New issue] AssemblyResolve event in PythonContext may load unnecessary assemblies ---------------------------------------------- ISSUES 1. [New issue] Sockets are not properly closed http://ironpython.codeplex.com/workitem/33312 User vahalae has proposed the issue: "In IronPython 2.7.3, calling close on the socket does not close the socket but only decreases the reference count: PythonSocket-class initializes the internal _referenceCount to 1. When close is explicitly called, reference count condition for closing the socket is _referenceCount < 1. Calling close only decreases the reference count. The socket is only really closed when the finalizer calls _close. The correct close condition is: public void close() { var refs = System.Threading.Interlocked.Decrement(ref _referenceCount); // Don't actually close the socket if other file objects are // still referring to this socket. if (refs < 1) { _close(); } } A simple script for reproducing the defect is attached."----------------- 2. [New issue] AssemblyResolve event in PythonContext may load unnecessary assemblies http://ironpython.codeplex.com/workitem/33313 User eldan has proposed the issue: "I've noticed in my program that this event jumps every time I refer to any of my resources for all of my projects. For an example every time I open a form in my program where the form uses something from the project's resources this event jumps. In MSDN it states here: http://msdn.microsoft.com/en-us/library/system.appdomain.assemblyresolve.aspx that now in .NET 4 this event triggers also for resource assemblies. I was wondering if I could make a patch in the code that check if args.Name.contains("resources") return null it'll make my program faster, but would it break anything? I was thinking that maybe when PythonContext.cs was written IronPython was running under .NET 3.5 so it was never intended to work for resource assemblies. This could be very great for you too, since making this patch made all my forms open 1-1.5 seconds faster. please get back to me, thanks in advance!" ---------------------------------------------- ---------------------------------------------- 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 Nov 8 14:07:54 2012 From: no_reply at codeplex.com (no_reply at codeplex.com) Date: 8 Nov 2012 05:07:54 -0800 Subject: [Ironpython-users] IronPython, Daily Digest 11/7/2012 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] AssemblyResolve event in PythonContext may load unnecessary assemblies 2. [New comment] AssemblyResolve event in PythonContext may load unnecessary assemblies ---------------------------------------------- ISSUES 1. [New comment] AssemblyResolve event in PythonContext may load unnecessary assemblies http://ironpython.codeplex.com/workitem/33313 User jdhardy has commented on the issue: "Can you post a proposed patch? I'm not exactly sure where you're proposing to make the change, and if I see it should be able to make a better decision."----------------- 2. [New comment] AssemblyResolve event in PythonContext may load unnecessary assemblies http://ironpython.codeplex.com/workitem/33313 User eldan has commented on the issue: "In PythonContext.cs file of IronPython project I'm pretty sure it was at line 1379 you have the method that was registered to the AssemblyResolve event. The problem is this event jumps a lot of times for no reason when I access my resources in my own code e.g open my form that uses some resources (images) If you take a look here: http://connect.microsoft.com/VisualStudio/feedback/details/526836/wpf-appdomain-assemblyresolve-being-called-when-it-shouldnt specifically this comment: ------------------------------------------------------------------ Posted by ShiverCube on 2/6/2010 at 3:20 AM The issue is that the AssemblyResolve event has a different behaviour in .NET 4.0 than it does in .NET 3.5. Sure, if you return null in the handler you can suppress the event, but this doesn't make any sense from an abstraction point of view. The AssemblyResolve should only be called when a resource cannot be found, and returning null should throw an Exception (as it does in .NET 3.5). My main concern is that the even though the behaviour appears to be different in the new version of .NET, I am unable to find any documentation about the matter. I would expect that if Microsoft decided to make a radical change such as this then they would at least have written something about it on MSDN. ------------------------------------------------------------------ That is the problem What I suggest is when you get the assembly name like MyProgram.resources.dll or Whatever.resources.dll or any assembly name that ends with .resources you should ignore it and return null if (args.Name.EndsWith(".resources.dll") return null; " ---------------------------------------------- ---------------------------------------------- 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 wiktor8010 at gmail.com Sat Nov 10 10:22:16 2012 From: wiktor8010 at gmail.com (Wiktor Mizdal) Date: Sat, 10 Nov 2012 10:22:16 +0100 Subject: [Ironpython-users] python 3.x Message-ID: When we will expect support python 3.x in IronPython? From jdhardy at gmail.com Sat Nov 10 18:36:55 2012 From: jdhardy at gmail.com (Jeff Hardy) Date: Sat, 10 Nov 2012 09:36:55 -0800 Subject: [Ironpython-users] python 3.x In-Reply-To: References: Message-ID: The earliest that I would expect an alpha release would be this time next year. The actual work isn't too much, but validating that the new Py3k semantics are correct could be time consuming. - Jeff On Sat, Nov 10, 2012 at 1:22 AM, Wiktor Mizdal wrote: > When we will expect support python 3.x in IronPython? > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users From misnomer at gmail.com Sun Nov 11 21:45:57 2012 From: misnomer at gmail.com (Nicholas Devenish) Date: Sun, 11 Nov 2012 20:45:57 +0000 Subject: [Ironpython-users] Differences with pyc-compiled assemblies? Message-ID: <8B4C4CFC-3E56-44FD-BF31-DFAEFB2A1A06@gmail.com> I'm seeing weird differences between importing plain packages and adding references to the compiled versions. Specifically, between importing sqlalchemy (0.7.9, from tarball, also 0.8.0b1) as a directory structure and as compiled, the uncompiled version works perfectly, whereas the compiled version appears to have standard library issues: (in SQLAlchemy-ver/lib/ in the source tarball, and on msys bash) $ find 'sqlalchemy' -name "*.py" > sqlalchemy.list $ pyc /out:SQLAlchemy @sqlalchemy.list $ ipy IronPython 2.7.3 (2.7.0.40) on .NET 4.0.30319.17929 (32-bit) Type "help", "copyright", "credits" or "license" for more information. >>> import clr >>> clr.AddReferenceToFileAndPath("SQLAlchemy.dll") >>> import sqlalchemy Traceback (most recent call last): File "", line 1, in File "sqlalchemy\__init__.py", line 52, in File "sqlalchemy\types", line 27, in File "sqlalchemy\schema", line 2670, in File "sqlalchemy\schema", line 2706, in DDLElement File "sqlalchemy\util\deprecations", line 45, in decorate File "sqlalchemy\util\deprecations", line 116, in _decorate_with_warning File "sqlalchemy\util\langhelpers", line 41, in decorate File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 814, in getargspec File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 758, in getargs IndexError: index out of range: 2 Does anyone have any idea how I can track this down? Thanks, Nick (Additionally, with 0.8.0b1 there is a failure to local import, but fixing that to import .langhelpers leads to the same error as above) From jdhardy at gmail.com Mon Nov 12 00:06:33 2012 From: jdhardy at gmail.com (Jeff Hardy) Date: Sun, 11 Nov 2012 15:06:33 -0800 Subject: [Ironpython-users] Differences with pyc-compiled assemblies? In-Reply-To: <8B4C4CFC-3E56-44FD-BF31-DFAEFB2A1A06@gmail.com> References: <8B4C4CFC-3E56-44FD-BF31-DFAEFB2A1A06@gmail.com> Message-ID: On Sun, Nov 11, 2012 at 12:45 PM, Nicholas Devenish wrote: > I'm seeing weird differences between importing plain packages and adding references to the compiled versions. Specifically, between importing sqlalchemy (0.7.9, from tarball, also 0.8.0b1) as a directory structure and as compiled, the uncompiled version works perfectly, whereas the compiled version appears to have standard library issues: SQLAlchemy works on IronPython? I didn't know that. Very cool. Is there anything that has to be done or does it just work out of the box? > > (in SQLAlchemy-ver/lib/ in the source tarball, and on msys bash) > $ find 'sqlalchemy' -name "*.py" > sqlalchemy.list > $ pyc /out:SQLAlchemy @sqlalchemy.list > $ ipy > IronPython 2.7.3 (2.7.0.40) on .NET 4.0.30319.17929 (32-bit) > Type "help", "copyright", "credits" or "license" for more information. >>>> import clr >>>> clr.AddReferenceToFileAndPath("SQLAlchemy.dll") >>>> import sqlalchemy > Traceback (most recent call last): > File "", line 1, in > File "sqlalchemy\__init__.py", line 52, in > File "sqlalchemy\types", line 27, in > File "sqlalchemy\schema", line 2670, in > File "sqlalchemy\schema", line 2706, in DDLElement > File "sqlalchemy\util\deprecations", line 45, in decorate > File "sqlalchemy\util\deprecations", line 116, in _decorate_with_warning > File "sqlalchemy\util\langhelpers", line 41, in decorate > File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 814, in getargspec > File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 758, in getargs > IndexError: index out of range: 2 > > Does anyone have any idea how I can track this down? In inspect.py, just before line 758, it looks at co.co_argcount and co.co_varnames and assumes that they are the same length, but my guess is that they might not be when compiled with pyc. If you can figure out exactly what getargspec is being called on, that might help make a simpler reproduction that I can work off of. - Jeff From misnomer at gmail.com Mon Nov 12 02:43:46 2012 From: misnomer at gmail.com (Nicholas Devenish) Date: Mon, 12 Nov 2012 01:43:46 +0000 Subject: [Ironpython-users] Differences with pyc-compiled assemblies? In-Reply-To: References: <8B4C4CFC-3E56-44FD-BF31-DFAEFB2A1A06@gmail.com> Message-ID: <5080B682-1AE2-4D58-A064-BA7B17027143@gmail.com> On 11 Nov 2012, at 23:06, Jeff Hardy wrote: > SQLAlchemy works on IronPython? I didn't know that. Very cool. Is > there anything that has to be done or does it just work out of the > box? It's supposed to work out of the box - one of the reasons I decided to go with IronPython for my current project. I haven't stress tested it, but importing the (source) package and running some simple operations on an in-memory sqlite database all works without issue. >> Traceback (most recent call last): >> File "", line 1, in >> File "sqlalchemy\__init__.py", line 52, in >> File "sqlalchemy\types", line 27, in >> File "sqlalchemy\schema", line 2670, in >> File "sqlalchemy\schema", line 2706, in DDLElement >> File "sqlalchemy\util\deprecations", line 45, in decorate >> File "sqlalchemy\util\deprecations", line 116, in _decorate_with_warning >> File "sqlalchemy\util\langhelpers", line 41, in decorate >> File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 814, in getargspec >> File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 758, in getargs >> IndexError: index out of range: 2 > In inspect.py, just before line 758, it looks at co.co_argcount and > co.co_varnames and assumes that they are the same length, but my guess > is that they might not be when compiled with pyc. If you can figure > out exactly what getargspec is being called on, that might help make a > simpler reproduction that I can work off of. So, I've traced down the stack trace with some tested output. This is what it seems to be doing: > Starting with the wrapped function (though the line number seems off slightly, > everything else in the stack trace and debug output before the exception matches > up exactly): > > @util.deprecated("0.7", "(deprecated message)") > def execute_at(self, event_name, target): > def call_event(target, connection, **kw): > if self._should_execute_deprecated(event_name, > target, connection, **kw): > return connection.execute(self.against(target)) > event.listen(target, "" + event_name.replace('-', '_'), call_event) > > > the deprecated decorator returns this function as the decorator: > > def decorate(fn): > print "In deprecated decorator: {}, {}".format(fn, message % dict(func=fn.__name__)) > return _decorate_with_warning( > fn, exc.SADeprecationWarning, > message % dict(func=fn.__name__), header) > > and this calls through to _decorate_with_warning: > > def _decorate_with_warning(func, wtype, message, docstring_header=None): > ... > @decorator > def warned(fn, *args, **kwargs): > warnings.warn(wtype(message), stacklevel=3) > return fn(*args, **kwargs) > > decorated = warned(func) > ... (above line triggers the decorator) > > > The @decorator is: > > def decorator(target): > """A signature-matching decorator factory.""" > > def decorate(fn): > if not inspect.isfunction(fn): > raise Exception("not a decoratable function") > print "Decorating: {}".format(fn) > spec = inspect_getfullargspec(fn) > ......... > return update_wrapper(decorate, target) > # update_wrapper is from python's functools > > And decorate calls through into inspect.py's aliased getfullargspec: > > def getargspec(func): > if ismethod(func): > func = func.im_func > if not isfunction(func): > raise TypeError('{!r} is not a Python function'.format(func)) > args, varargs, varkw = getargs(func.func_code) > > That calls getargs: > > def getargs(co): > if not iscode(co): > raise TypeError('{!r} is not a code object'.format(co)) > > nargs = co.co_argcount > names = co.co_varnames > args = list(names[:nargs]) > step = 0 > > for i in range(nargs): > if args[i][:1] in ('', '.'): > > With values for the variables: > > print "getargs:" > print " args: {}".format(args) > print " nargs: {}".format(nargs) > print " names: {}".format(names) > > And the output from these print statements: > > getargs: > args: ['target', 'call_event'] > nargs: 3 > names: ('target', 'call_event') Is this any help? It's 2am now, but I'll continue poking at this tomorrow. Thanks, Nick From vernondcole at gmail.com Mon Nov 12 04:45:56 2012 From: vernondcole at gmail.com (Vernon Cole) Date: Sun, 11 Nov 2012 20:45:56 -0700 Subject: [Ironpython-users] Differences with pyc-compiled assemblies? In-Reply-To: <5080B682-1AE2-4D58-A064-BA7B17027143@gmail.com> References: <8B4C4CFC-3E56-44FD-BF31-DFAEFB2A1A06@gmail.com> <5080B682-1AE2-4D58-A064-BA7B17027143@gmail.com> Message-ID: On Sun, Nov 11, 2012 at 6:43 PM, Nicholas Devenish wrote: > > On 11 Nov 2012, at 23:06, Jeff Hardy wrote: > > SQLAlchemy works on IronPython? I didn't know that. Very cool. Is > > there anything that has to be done or does it just work out of the > > box? > > It's supposed to work out of the box - one of the reasons I decided to go > with IronPython for my current project. I haven't stress tested it, but > importing the (source) package and running some simple operations on an > in-memory sqlite database all works without issue. > This is nice to hear. I was aware that adodbapi was supported (but not recommended) by SQLAlchemy, and sent an inquiry asking what needed to be done to improve support. I attempted to implement the suggestions (particularly making .rowcount work better) in subsequent versions of adodbapi. I don't think the SQLAlchemy community has really tried adodbapi since I started supporting it in 2007. Please get back to me with any suggestions or other feedback. I'd be happy to make changes to regain their support. -------------- next part -------------- An HTML attachment was scrubbed... URL: From misnomer at gmail.com Mon Nov 12 11:03:47 2012 From: misnomer at gmail.com (Nicholas Devenish) Date: Mon, 12 Nov 2012 10:03:47 +0000 Subject: [Ironpython-users] Differences with pyc-compiled assemblies? In-Reply-To: References: <8B4C4CFC-3E56-44FD-BF31-DFAEFB2A1A06@gmail.com> Message-ID: Hi Jeff again, > In inspect.py, just before line 758, it looks at co.co_argcount and > co.co_varnames and assumes that they are the same length, but my guess > is that they might not be when compiled with pyc. If you can figure > out exactly what getargspec is being called on, that might help make a > simpler reproduction that I can work off of. I spent some time this morning trying to reduce down to a standalone test case; I've got it down to the following, and don't understand what is going wrong so can't work out what else to remove; sorry about the large chain of functions, but it seems to somehow be involved. I hope it is helpful: > from functools import update_wrapper > import inspect > > def decorator(target): > def decorate(fn): > return inspect.getargspec(fn) > return update_wrapper(decorate, target) > > def _decorate_with_warning(func): > @decorator > def warned(fn): > pass > warned(func) > > @_decorate_with_warning > def execute_at(self, event_name, target): > def call_event(target, connection): > if self._somefun(event_name, target, connection): > pass As before, it runs fine as a standalone script $ ipy testipy.py But compiling with: > pyc /out:TestIPy testily.py > ipy >> import clr >> clr.AddReferenceToFileAndPath("TestIPy.dll") >> import testipy Gives the same traceback: > Traceback (most recent call last): > File "runtest.py", line 3, in > File "testipy", line 3, in > File "testipy", line 14, in _decorate_with_warning > File "testipy", line 7, in decorate > File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 820, in getargspec > File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 762, in getargs > IndexError: index out of range: 2 I hope this is helpful! Nick From jdhardy at gmail.com Mon Nov 12 17:02:49 2012 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 12 Nov 2012 08:02:49 -0800 Subject: [Ironpython-users] Differences with pyc-compiled assemblies? In-Reply-To: <5080B682-1AE2-4D58-A064-BA7B17027143@gmail.com> References: <8B4C4CFC-3E56-44FD-BF31-DFAEFB2A1A06@gmail.com> <5080B682-1AE2-4D58-A064-BA7B17027143@gmail.com> Message-ID: On Sun, Nov 11, 2012 at 5:43 PM, Nicholas Devenish wrote: >>> Traceback (most recent call last): >>> File "", line 1, in >>> File "sqlalchemy\__init__.py", line 52, in >>> File "sqlalchemy\types", line 27, in >>> File "sqlalchemy\schema", line 2670, in >>> File "sqlalchemy\schema", line 2706, in DDLElement >>> File "sqlalchemy\util\deprecations", line 45, in decorate >>> File "sqlalchemy\util\deprecations", line 116, in _decorate_with_warning >>> File "sqlalchemy\util\langhelpers", line 41, in decorate >>> File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 814, in getargspec >>> File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 758, in getargs >>> IndexError: index out of range: 2 >> In inspect.py, just before line 758, it looks at co.co_argcount and >> co.co_varnames and assumes that they are the same length, but my guess >> is that they might not be when compiled with pyc. If you can figure >> out exactly what getargspec is being called on, that might help make a >> simpler reproduction that I can work off of. > > So, I've traced down the stack trace with some tested output. This is what it seems to be doing: First off, thank you for the detailed analysis. It's very helpful. > >> Starting with the wrapped function (though the line number seems off slightly, >> everything else in the stack trace and debug output before the exception matches >> up exactly): >> ... snip ... >> That calls getargs: >> >> def getargs(co): >> if not iscode(co): >> raise TypeError('{!r} is not a code object'.format(co)) >> >> nargs = co.co_argcount >> names = co.co_varnames >> args = list(names[:nargs]) >> step = 0 >> >> for i in range(nargs): >> if args[i][:1] in ('', '.'): >> >> With values for the variables: >> >> print "getargs:" >> print " args: {}".format(args) >> print " nargs: {}".format(nargs) >> print " names: {}".format(names) >> >> And the output from these print statements: >> >> getargs: >> args: ['target', 'call_event'] >> nargs: 3 >> names: ('target', 'call_event') > It's odd that nargs (co_argcount) is 3, but names (co_varnames) has only 2 elements. I'm afraid it might be a bug in how IronPython compiles the code. It's possible that no one has tried using pyc on code that accesses the co_* values before. - Jeff From jdhardy at gmail.com Mon Nov 12 17:05:26 2012 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 12 Nov 2012 08:05:26 -0800 Subject: [Ironpython-users] Differences with pyc-compiled assemblies? In-Reply-To: References: <8B4C4CFC-3E56-44FD-BF31-DFAEFB2A1A06@gmail.com>

Message-ID: On Mon, Nov 12, 2012 at 2:03 AM, Nicholas Devenish wrote: > Hi Jeff again, > >> In inspect.py, just before line 758, it looks at co.co_argcount and >> co.co_varnames and assumes that they are the same length, but my guess >> is that they might not be when compiled with pyc. If you can figure >> out exactly what getargspec is being called on, that might help make a >> simpler reproduction that I can work off of. > > > I spent some time this morning trying to reduce down to a standalone test case; I've got it down to the following, and don't understand what is going wrong so can't work out what else to remove; sorry about the large chain of functions, but it seems to somehow be involved. I hope it is helpful: > >> from functools import update_wrapper >> import inspect >> >> def decorator(target): >> def decorate(fn): >> return inspect.getargspec(fn) >> return update_wrapper(decorate, target) >> >> def _decorate_with_warning(func): >> @decorator >> def warned(fn): >> pass >> warned(func) >> >> @_decorate_with_warning >> def execute_at(self, event_name, target): >> def call_event(target, connection): >> if self._somefun(event_name, target, connection): >> pass > > As before, it runs fine as a standalone script > $ ipy testipy.py > > But compiling with: >> pyc /out:TestIPy testily.py >> ipy >>> import clr >>> clr.AddReferenceToFileAndPath("TestIPy.dll") >>> import testipy > > Gives the same traceback: >> Traceback (most recent call last): >> File "runtest.py", line 3, in >> File "testipy", line 3, in >> File "testipy", line 14, in _decorate_with_warning >> File "testipy", line 7, in decorate >> File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 820, in getargspec >> File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 762, in getargs >> IndexError: index out of range: 2 > > I hope this is helpful! Very, thank you. Do you think you could open an issue (http://ironpython.codeplex.com/WorkItem/Create) and put the smaller repro in it? I'll try to take a look at it soon because I'm working on the compiler code anyway, but at least with an issue it won't get completely forgotten. - Jeff From misnomer at gmail.com Mon Nov 12 19:32:05 2012 From: misnomer at gmail.com (Nicholas Devenish) Date: Mon, 12 Nov 2012 18:32:05 +0000 Subject: [Ironpython-users] Differences with pyc-compiled assemblies? In-Reply-To: References: <8B4C4CFC-3E56-44FD-BF31-DFAEFB2A1A06@gmail.com>

Message-ID: <1B01739E-1376-4873-92F5-80B50DD50FF0@gmail.com> I've added it at http://ironpython.codeplex.com/workitem/33341 The formatting is screwed up now because I didn't relies it wouldn't preserve any spacing (even returns!). I'm trying to fix it up, but the site seems very slow at the moment - about a minute between any requests to the site. For now, importing directly seems to work, or I'll play around with removing the call/warning to see if that works - it's only a deprecation. Many thanks, Nick On 12 Nov 2012, at 16:05, Jeff Hardy wrote: > On Mon, Nov 12, 2012 at 2:03 AM, Nicholas Devenish wrote: >> Hi Jeff again, >> >>> In inspect.py, just before line 758, it looks at co.co_argcount and >>> co.co_varnames and assumes that they are the same length, but my guess >>> is that they might not be when compiled with pyc. If you can figure >>> out exactly what getargspec is being called on, that might help make a >>> simpler reproduction that I can work off of. >> >> >> I spent some time this morning trying to reduce down to a standalone test case; I've got it down to the following, and don't understand what is going wrong so can't work out what else to remove; sorry about the large chain of functions, but it seems to somehow be involved. I hope it is helpful: >> >>> from functools import update_wrapper >>> import inspect >>> >>> def decorator(target): >>> def decorate(fn): >>> return inspect.getargspec(fn) >>> return update_wrapper(decorate, target) >>> >>> def _decorate_with_warning(func): >>> @decorator >>> def warned(fn): >>> pass >>> warned(func) >>> >>> @_decorate_with_warning >>> def execute_at(self, event_name, target): >>> def call_event(target, connection): >>> if self._somefun(event_name, target, connection): >>> pass >> >> As before, it runs fine as a standalone script >> $ ipy testipy.py >> >> But compiling with: >>> pyc /out:TestIPy testily.py >>> ipy >>>> import clr >>>> clr.AddReferenceToFileAndPath("TestIPy.dll") >>>> import testipy >> >> Gives the same traceback: >>> Traceback (most recent call last): >>> File "runtest.py", line 3, in >>> File "testipy", line 3, in >>> File "testipy", line 14, in _decorate_with_warning >>> File "testipy", line 7, in decorate >>> File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 820, in getargspec >>> File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 762, in getargs >>> IndexError: index out of range: 2 >> >> I hope this is helpful! > > Very, thank you. Do you think you could open an issue > (http://ironpython.codeplex.com/WorkItem/Create) and put the smaller > repro in it? I'll try to take a look at it soon because I'm working on > the compiler code anyway, but at least with an issue it won't get > completely forgotten. > > - Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From slide.o.mix at gmail.com Mon Nov 12 19:39:50 2012 From: slide.o.mix at gmail.com (Slide) Date: Mon, 12 Nov 2012 11:39:50 -0700 Subject: [Ironpython-users] Differences with pyc-compiled assemblies? In-Reply-To: <1B01739E-1376-4873-92F5-80B50DD50FF0@gmail.com> References: <8B4C4CFC-3E56-44FD-BF31-DFAEFB2A1A06@gmail.com>

<1B01739E-1376-4873-92F5-80B50DD50FF0@gmail.com> Message-ID: Yes, codeplex has issues with pasting code, horrible horrible issues. slide On Mon, Nov 12, 2012 at 11:32 AM, Nicholas Devenish wrote: > I've added it at http://ironpython.codeplex.com/workitem/33341 > > The formatting is screwed up now because I didn't relies it wouldn't > preserve any spacing (even returns!). I'm trying to fix it up, but the site > seems very slow at the moment - about a minute between any requests to the > site. > > For now, importing directly seems to work, or I'll play around with > removing the call/warning to see if that works - it's only a deprecation. > > Many thanks, > > Nick > > On 12 Nov 2012, at 16:05, Jeff Hardy wrote: > > On Mon, Nov 12, 2012 at 2:03 AM, Nicholas Devenish > wrote: > > Hi Jeff again, > > In inspect.py, just before line 758, it looks at co.co_argcount and > co.co_varnames and assumes that they are the same length, but my guess > is that they might not be when compiled with pyc. If you can figure > out exactly what getargspec is being called on, that might help make a > simpler reproduction that I can work off of. > > > > I spent some time this morning trying to reduce down to a standalone test > case; I've got it down to the following, and don't understand what is going > wrong so can't work out what else to remove; sorry about the large chain of > functions, but it seems to somehow be involved. I hope it is helpful: > > from functools import update_wrapper > import inspect > > def decorator(target): > def decorate(fn): > return inspect.getargspec(fn) > return update_wrapper(decorate, target) > > def _decorate_with_warning(func): > @decorator > def warned(fn): > pass > warned(func) > > @_decorate_with_warning > def execute_at(self, event_name, target): > def call_event(target, connection): > if self._somefun(event_name, target, connection): > pass > > > As before, it runs fine as a standalone script > $ ipy testipy.py > > But compiling with: > > pyc /out:TestIPy testily.py > ipy > > import clr > clr.AddReferenceToFileAndPath("TestIPy.dll") > import testipy > > > Gives the same traceback: > > Traceback (most recent call last): > File "runtest.py", line 3, in > File "testipy", line 3, in > File "testipy", line 14, in _decorate_with_warning > File "testipy", line 7, in decorate > File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 820, in > getargspec > File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 762, in > getargs > IndexError: index out of range: 2 > > > I hope this is helpful! > > > Very, thank you. Do you think you could open an issue > (http://ironpython.codeplex.com/WorkItem/Create) and put the smaller > repro in it? I'll try to take a look at it soon because I'm working on > the compiler code anyway, but at least with an issue it won't get > completely forgotten. > > - Jeff > > > > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users > > -- Website: http://earl-of-code.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From no_reply at codeplex.com Tue Nov 13 09:33:57 2012 From: no_reply at codeplex.com (no_reply at codeplex.com) Date: 13 Nov 2012 00:33:57 -0800 Subject: [Ironpython-users] IronPython, Daily Digest 11/12/2012 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] Failure in compiled module vs directly run 2. [New comment] Failure in compiled module vs directly run 3. [New comment] Failure in compiled module vs directly run ---------------------------------------------- ISSUES 1. [New issue] Failure in compiled module vs directly run http://ironpython.codeplex.com/workitem/33341 User ndevenish has proposed the issue: "I've found a problem that only seems to happen when importing from a pyc compiled assembly, but does not show when importing the script directly. Attached is as far as I have managed to reduce a simple test case to (I first came across this in SQLAlchemy). Running directly (or, opening the repl and then importing manually): $ ipy testipy.py Works fine, but compiling with pyc (assuming you have an alias): $ pyc /out:TestIPy testily.py And then running the script: import clr clr.AddReferenceToFileAndPath("TestIPy.dll") import testipy Gives the following traceback: File "runtest.py", line 3, in File "testipy", line 3, in File "testipy", line 14, in _decorate_with_warning File "testipy", line 7, in decorate File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 820, in getargspec File "c:\Program Files\IronPython 2.7\Lib\inspect.py", line 762, in getargs IndexError: index out of range: 2"----------------- 2. [New comment] Failure in compiled module vs directly run http://ironpython.codeplex.com/workitem/33341 User ndevenish has commented on the issue: "Comment that I've added this in response to a request by Jeff Hardy on the mailing list."----------------- 3. [New comment] Failure in compiled module vs directly run http://ironpython.codeplex.com/workitem/33341 User ndevenish has commented on the issue: "Attached issue description as an attachment, because Codeplex doesn't appear to have discovered what a double quote or newline is. Baby steps, MS, Baby steps." ---------------------------------------------- ---------------------------------------------- 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 jdhardy at gmail.com Tue Nov 13 18:31:39 2012 From: jdhardy at gmail.com (Jeff Hardy) Date: Tue, 13 Nov 2012 09:31:39 -0800 Subject: [Ironpython-users] Differences with pyc-compiled assemblies? In-Reply-To: References: <8B4C4CFC-3E56-44FD-BF31-DFAEFB2A1A06@gmail.com>

<1B01739E-1376-4873-92F5-80B50DD50FF0@gmail.com> Message-ID: On Mon, Nov 12, 2012 at 10:39 AM, Slide wrote: > Yes, codeplex has issues with pasting code, horrible horrible issues. If anyone knows of a Codeplex -> GitHub issue migration script, I'd be happy to hear about it. - Jeff From slide.o.mix at gmail.com Tue Nov 13 18:32:31 2012 From: slide.o.mix at gmail.com (Slide) Date: Tue, 13 Nov 2012 10:32:31 -0700 Subject: [Ironpython-users] Differences with pyc-compiled assemblies? In-Reply-To: References: <8B4C4CFC-3E56-44FD-BF31-DFAEFB2A1A06@gmail.com>