From no_reply at codeplex.com Tue May 1 13:24:04 2012 From: no_reply at codeplex.com (no_reply at codeplex.com) Date: 1 May 2012 04:24:04 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 4/30/2012 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] Support all encodings CPython does for _codecs.encode and _codecs.decode ---------------------------------------------- ISSUES 1. [New comment] Support all encodings CPython does for _codecs.encode and _codecs.decode http://ironpython.codeplex.com/workitem/4565 User jdhardy has commented on the issue: "Missing 'idna' breaks requests, and requests is too awesome not to be working." ---------------------------------------------- ---------------------------------------------- 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 slide.o.mix at gmail.com Wed May 2 21:27:39 2012 From: slide.o.mix at gmail.com (Slide) Date: Wed, 2 May 2012 12:27:39 -0700 Subject: [Ironpython-users] Codeplex says "No Documentation" In-Reply-To: References: Message-ID: I have seem to have access, I haven't tried pushing anything yet. I'll take a look at the Extending section and what I can do help out there. Thanks, slide On Mon, Apr 30, 2012 at 12:00 PM, Jeff Hardy wrote: > On Mon, Apr 30, 2012 at 9:05 AM, Slide wrote: >> This sounds like a great idea Jeff. Let me know if there is anything I >> can do to help out. > > The "Extending and Embedding" section needs to be wiped out and > completely rewritten (since none of it applies to IronPython). I know > it's a lot to ask, but you had mentioned wanting to write about > creating modules - if you want to work on the "Extending" section, > that would be a great start (I'm thinking of adapting the "Embedding" > section from the existing DLR docs as much as possible). > > You should have write access to ironpython-docs repo already, but let > me know if you don't. > > - Jeff -- Website:?http://earl-of-code.com From no_reply at codeplex.com Fri May 4 09:54:02 2012 From: no_reply at codeplex.com (no_reply at codeplex.com) Date: 4 May 2012 00:54:02 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/3/2012 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] Difference in IronPython from Python with byref from ctypes ---------------------------------------------- ISSUES 1. [New issue] Difference in IronPython from Python with byref from ctypes http://ironpython.codeplex.com/workitem/32657 User ameier has proposed the issue: "I guess there is a difference when allocating a c_buffer. The address returned seems not to be valid. I would like to handle the reference to this buffer to a c-library. If I use Python, everything work fine. Please see the addresses from my log with Python and IronPython. Maybe this issue is related to issue 32048" ---------------------------------------------- ---------------------------------------------- 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 May 6 16:01:55 2012 From: no_reply at codeplex.com (no_reply at codeplex.com) Date: 6 May 2012 07:01:55 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/5/2012 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] Duplicate key in dict 2. [New comment] Duplicate key in dict ---------------------------------------------- ISSUES 1. [New comment] Duplicate key in dict http://ironpython.codeplex.com/workitem/32527 User kunom has commented on the issue: "Same buggy behaviour here: Key 'a8' appears twice. (IronPython 2.7 (2.7.0.40) on .NET 4.0.30319.261) Some other test: - behaviour can only be observed by removing 'a7', but not by removing any of the other keys. - there's no difference between "d.pop('a7')" and "del a['a7']" To me, and without having launched a debugger, this appears to be a bug in the DictionaryStorage.Remove() method held by the PythonDictionary instance."----------------- 2. [New comment] Duplicate key in dict http://ironpython.codeplex.com/workitem/32527 User kunom has commented on the issue: "This goes down to CommonDictionaryStorage with its not quite trivial code... The reason why this appears only in 32-bit mode might be that hash calculation returns different values on 64-bit. " ---------------------------------------------- ---------------------------------------------- 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 ericsnowcurrently at gmail.com Sun May 6 21:05:54 2012 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Sun, 6 May 2012 13:05:54 -0600 Subject: [Ironpython-users] feedback on PEP 421 Message-ID: Hi, I'm looking for feedback on PEP 421: "Adding sys.implementation". The idea came up in 2009 and garnered positive feedback, but didn't go anywhere. I've revived it and am hoping to get it worked out in time for Python 3.3. Any feedback would be very helpful, particularly with regard to the decision on the type of sys.implementation and the constraints on sys.implementation.version. Thanks. -eric http://www.python.org/dev/peps/pep-0421/ From jdhardy at gmail.com Mon May 7 00:20:18 2012 From: jdhardy at gmail.com (Jeff Hardy) Date: Sun, 6 May 2012 15:20:18 -0700 Subject: [Ironpython-users] feedback on PEP 421 In-Reply-To: References: Message-ID: On Sun, May 6, 2012 at 12:05 PM, Eric Snow wrote: > Hi, > > I'm looking for feedback on PEP 421: "Adding sys.implementation". ?The > idea came up in 2009 and garnered positive feedback, but didn't go > anywhere. ?I've revived it and am hoping to get it worked out in time > for Python 3.3. First off, I like it. It's long overdue, but better late than never. > > Any feedback would be very helpful, particularly with regard to the > decision on the type of sys.implementation and the constraints on > sys.implementation.version. ?Thanks. I'd strongly prefer the named-tuple approach, like version_info. The metadata attribute being a dict is fine (although the PEP doesn't actually call that out in "Required Values" section; I had to search to find out if it was actually a dict). I have some stuff I want to put in there already. I'm not really sure there's much value in having sys.version_info and sys.implementation.version be different, but I believe PyPy works that way, so I have no objection to it. They'll be the same in IronPython, though. Thanks for pushing this through. I'll probably add it the day after it's approved. - Jeff > > -eric > > > http://www.python.org/dev/peps/pep-0421/ > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users From no_reply at codeplex.com Mon May 7 09:51:09 2012 From: no_reply at codeplex.com (no_reply at codeplex.com) Date: 7 May 2012 00:51:09 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/6/2012 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] Duplicate key in dict ---------------------------------------------- ISSUES 1. [New comment] Duplicate key in dict http://ironpython.codeplex.com/workitem/32527 User KeithJRome has commented on the issue: "I have been poking around with this. The pop() is what causes things to go downhill. This is fine: d = {'1': 1, '2': 1, '3': 1, 'a7': 1, 'a8': 1} d['a8'] = 5 print d This is fine: d = {'1': 1, '2': 1, '3': 1, 'a7': 1, 'a8': 1} d['a8'] = 5 d.pop('a7') print d This is NOT fine: d = {'1': 1, '2': 1, '3': 1, 'a7': 1, 'a8': 1} d.pop('a7') d['a8'] = 5 print d" ---------------------------------------------- ---------------------------------------------- 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 3s-software.com Mon May 7 09:56:58 2012 From: m.schaber at 3s-software.com (Markus Schaber) Date: Mon, 7 May 2012 07:56:58 +0000 Subject: [Ironpython-users] feedback on PEP 421 In-Reply-To: References: Message-ID: <727D8E16AE957149B447FE368139F2B50D7BDC03@SERVER10> Hi, Eric, > Von Eric Snow > I'm looking for feedback on PEP 421: "Adding sys.implementation". The > idea came up in 2009 and garnered positive feedback, but didn't go > anywhere. I've revived it and am hoping to get it worked out in time for > Python 3.3. > > Any feedback would be very helpful, particularly with regard to the > decision on the type of sys.implementation and the constraints on > sys.implementation.version. Thanks. As a user and embedder of IronPython, and a long-time user of cPython, I welcome this idea. Maybe we can add a required variable "host" which contains a tuple (or set) of tagwords describing the hosting / embedding environment. This could contain values like: ('apache', 'mod_python') ('apache', 'cgi') ('CoDeSys') This idea just popped up in my mind, so it is not yet fully matured. :-) Best regards Markus Schaber -- ___________________________ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 From m.schaber at 3s-software.com Mon May 7 10:11:55 2012 From: m.schaber at 3s-software.com (Markus Schaber) Date: Mon, 7 May 2012 08:11:55 +0000 Subject: [Ironpython-users] feedback on PEP 421 In-Reply-To: References: Message-ID: <727D8E16AE957149B447FE368139F2B50D7BDC39@SERVER10> Hi, Jeff, > Von: Jeff Hardy > > Any feedback would be very helpful, particularly with regard to the > > decision on the type of sys.implementation and the constraints on > > sys.implementation.version. Thanks. > > I'd strongly prefer the named-tuple approach, like version_info. The > metadata attribute being a dict is fine (although the PEP doesn't actually > call that out in "Required Values" section; I had to search to find out if > it was actually a dict). I have some stuff I want to put in there already. Hmm, maybe we could put the host/embedder info I suggested in the other mail there. > I'm not really sure there's much value in having sys.version_info and > sys.implementation.version be different, but I believe PyPy works that > way, so I have no objection to it. They'll be the same in IronPython, > though. Hmm. It would open the possibility of IronPython supporting both Python 2.7 and 3.X for some grace period... > Thanks for pushing this through. I'll probably add it the day after it's > approved. Thanks. :-) Best regards Markus Schaber -- ___________________________ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 From cmello at gmail.com Mon May 7 16:41:20 2012 From: cmello at gmail.com (Cesar Mello) Date: Mon, 7 May 2012 11:41:20 -0300 Subject: [Ironpython-users] IronPython Merge Modules for Windows Message-ID: Hi, I've noticed IronRuby has merge modules available. Would this be the recommended way to redistribute IronPython? Now I need to embed IronPython in our product's installer. (This is still a prototype). Any advices about this? Probably that's an effort that can be shared, so instead of developing proprietary installation components I may contribute work on generic merge modules. Thank you a lot for the attention! Best regards Mello -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmello at gmail.com Mon May 7 16:49:25 2012 From: cmello at gmail.com (Cesar Mello) Date: Mon, 7 May 2012 11:49:25 -0300 Subject: [Ironpython-users] IronPython Merge Modules for Windows In-Reply-To: References: Message-ID: A colleague of mine also suggested implementing a stand-alone redistributable, to embed in our product's bootstrapper. That seems to be an easier trend in our installers. What do you think? Thanks a lot for the attention. Best regards Mello On Mon, May 7, 2012 at 11:41 AM, Cesar Mello wrote: > Hi, > > I've noticed IronRuby has merge modules available. Would this be the > recommended way to redistribute IronPython? > > Now I need to embed IronPython in our product's installer. (This is still > a prototype). Any advices about this? Probably that's an effort that can be > shared, so instead of developing proprietary installation components I may > contribute work on generic merge modules. > > Thank you a lot for the attention! > > Best regards > Mello > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ericsnowcurrently at gmail.com Mon May 7 16:53:56 2012 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Mon, 7 May 2012 08:53:56 -0600 Subject: [Ironpython-users] feedback on PEP 421 In-Reply-To: References: Message-ID: On Sun, May 6, 2012 at 4:20 PM, Jeff Hardy wrote: > On Sun, May 6, 2012 at 12:05 PM, Eric Snow wrote: >> Hi, >> >> I'm looking for feedback on PEP 421: "Adding sys.implementation". ?The >> idea came up in 2009 and garnered positive feedback, but didn't go >> anywhere. ?I've revived it and am hoping to get it worked out in time >> for Python 3.3. > > First off, I like it. It's long overdue, but better late than never. Agreed. Better cognizance of the alternate implementations has been a growing sentiment among the CPython core developers, especially Guido and Brett Cannon. Hopefully I'll be able to make a bigger push on this front once sys.implementation is all sorted out. >> >> Any feedback would be very helpful, particularly with regard to the >> decision on the type of sys.implementation and the constraints on >> sys.implementation.version. ?Thanks. > > I'd strongly prefer the named-tuple approach, like version_info. The > metadata attribute being a dict is fine (although the PEP doesn't > actually call that out in "Required Values" section; I had to search > to find out if it was actually a dict). I have some stuff I want to > put in there already. Good to know. Is your preference for a named tuple instead of a normal class? I'd rather not expose sys.implementation as a sequence type, but mostly I want to end up with something that's meaningful for everyone. > I'm not really sure there's much value in having sys.version_info and > sys.implementation.version be different, but I believe PyPy works that > way, so I have no objection to it. They'll be the same in IronPython, > though. > > Thanks for pushing this through. I'll probably add it the day after > it's approved. That's just what I wanted to hear. -eric From ericsnowcurrently at gmail.com Mon May 7 16:54:04 2012 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Mon, 7 May 2012 08:54:04 -0600 Subject: [Ironpython-users] feedback on PEP 421 In-Reply-To: <727D8E16AE957149B447FE368139F2B50D7BDC39@SERVER10> References: <727D8E16AE957149B447FE368139F2B50D7BDC39@SERVER10> Message-ID: On Mon, May 7, 2012 at 2:11 AM, Markus Schaber wrote: > Hi, Jeff, > >> Von: Jeff Hardy >> > Any feedback would be very helpful, particularly with regard to the >> > decision on the type of sys.implementation and the constraints on >> > sys.implementation.version. ?Thanks. >> >> I'd strongly prefer the named-tuple approach, like version_info. The >> metadata attribute being a dict is fine (although the PEP doesn't actually >> call that out in "Required Values" section; I had to search to find out if >> it was actually a dict). I have some stuff I want to put in there already. > > Hmm, maybe we could put the host/embedder info I suggested in the other mail there. > >> I'm not really sure there's much value in having sys.version_info and >> sys.implementation.version be different, but I believe PyPy works that >> way, so I have no objection to it. They'll be the same in IronPython, >> though. > > Hmm. It would open the possibility of IronPython supporting both Python 2.7 and 3.X for some grace period... Yeah, the idea of the PEP in whole is to make things easier for Python implementors. If it allows you greater flexibility then it'll have been worth it. -eric From ericsnowcurrently at gmail.com Mon May 7 16:55:58 2012 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Mon, 7 May 2012 08:55:58 -0600 Subject: [Ironpython-users] feedback on PEP 421 In-Reply-To: References: Message-ID: On Sun, May 6, 2012 at 4:20 PM, Jeff Hardy wrote: > The > metadata attribute being a dict is fine (although the PEP doesn't > actually call that out in "Required Values" section; I had to search > to find out if it was actually a dict). Thanks for pointing that out. I had certainly intended on specifying there that it's a dict. :) It'll be fixed on the next update. -eric From jdhardy at gmail.com Mon May 7 17:30:19 2012 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 7 May 2012 08:30:19 -0700 Subject: [Ironpython-users] feedback on PEP 421 In-Reply-To: References: Message-ID: On Mon, May 7, 2012 at 7:53 AM, Eric Snow wrote: >> I'd strongly prefer the named-tuple approach, like version_info. The >> metadata attribute being a dict is fine (although the PEP doesn't >> actually call that out in "Required Values" section; I had to search >> to find out if it was actually a dict). I have some stuff I want to >> put in there already. > > Good to know. ?Is your preference for a named tuple instead of a > normal class? ?I'd rather not expose sys.implementation as a sequence > type, but mostly I want to end up with something that's meaningful for > everyone. Yeah, a normal class is fine (preferable, actually). For some reason I thought the options were named tuple a la version_info, or dict. One other question - for the metadata dict, is it mutable? Even though mutable is easier to implement, I'd still prefer it be read-only. - Jeff From jdhardy at gmail.com Mon May 7 17:37:58 2012 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 7 May 2012 08:37:58 -0700 Subject: [Ironpython-users] feedback on PEP 421 In-Reply-To: <727D8E16AE957149B447FE368139F2B50D7BDC39@SERVER10> References: <727D8E16AE957149B447FE368139F2B50D7BDC39@SERVER10> Message-ID: On Mon, May 7, 2012 at 1:11 AM, Markus Schaber wrote: > Hmm, maybe we could put the host/embedder info I suggested in the other mail there. Yeah, and things like which which CLR version (3.5, 4.0), implementation (MS, Mono), subset (Silverlight, MonoTouch, MonoDroid), what host it's running under, etc. I was thinking of adding fields to clr for that information anyway, but it can go here instead. >> I'm not really sure there's much value in having sys.version_info and >> sys.implementation.version be different, but I believe PyPy works that >> way, so I have no objection to it. They'll be the same in IronPython, >> though. > > Hmm. It would open the possibility of IronPython supporting both Python 2.7 and 3.X for some grace period... That ... yikes. It already does support some (not much) stuff using -X:Python30, but that introduces a bunch of if statements and makes the code quite messy. There are other ways to do it, but a clean break in a new branch seems preferable to me. Plus there's the issue of the reorganized stdlib, which I'm not really sure how to cleanly solve. So my preference is to work in a different branch to 3k support. I'd like to do some work after 2.7.3 is released, but I'm not sure I'll get to it. - Jeff From jdhardy at gmail.com Mon May 7 17:46:00 2012 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 7 May 2012 08:46:00 -0700 Subject: [Ironpython-users] IronPython Merge Modules for Windows In-Reply-To: References: Message-ID: On Mon, May 7, 2012 at 7:41 AM, Cesar Mello wrote: > Hi, > > I've noticed IronRuby has merge modules available. Would this be the > recommended way to redistribute IronPython? > > Now I need to embed IronPython in our product's installer. (This is still a > prototype). Any advices about this??Probably that's an effort that can be > shared, so instead of developing proprietary installation components I may > contribute work on generic merge modules. If you've already got a bootstrapper, I would just but IronPython's MSI in there. Merge modules are really fragile and tend to break in weird ways, so I don't build them for IronPython (I refactored IP's MSI builds, so that's why they're different from IR's). The recommendation from MS seems to be to use full MSIs and chain them using a bootstrapper. One thing to watch for is that a user could upgrade IP and cause your app to be running against a new version. I try to make sure that upgrades shouldn't break anything for just that reason, but it does happen. The only way around this would be to build IP yourself, with a different signing key or AssemblyVersion, and ship that version with your app. - Jeff From ericsnowcurrently at gmail.com Mon May 7 17:54:39 2012 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Mon, 7 May 2012 09:54:39 -0600 Subject: [Ironpython-users] feedback on PEP 421 In-Reply-To: References: Message-ID: On Mon, May 7, 2012 at 9:30 AM, Jeff Hardy wrote: > On Mon, May 7, 2012 at 7:53 AM, Eric Snow wrote: >> Good to know. ?Is your preference for a named tuple instead of a >> normal class? ?I'd rather not expose sys.implementation as a sequence >> type, but mostly I want to end up with something that's meaningful for >> everyone. > > Yeah, a normal class is fine (preferable, actually). For some reason I > thought the options were named tuple a la version_info, or dict. > > One other question - for the metadata dict, is it mutable? Even though > mutable is easier to implement, I'd still prefer it be read-only. A plain dict would be certainly be easier to implement, just using the builtin. Exposing an immutable dict type in CPython could open a can of worms, but if it makes sense we could consider it. -eric From jdhardy at gmail.com Mon May 7 18:08:37 2012 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 7 May 2012 09:08:37 -0700 Subject: [Ironpython-users] feedback on PEP 421 In-Reply-To: References: Message-ID: On Mon, May 7, 2012 at 8:54 AM, Eric Snow wrote: > A plain dict would be certainly be easier to implement, just using the > builtin. ?Exposing an immutable dict type in CPython could open a can > of worms, but if it makes sense we could consider it. If it's going to be harder for CPython, then I wouldn't worry about it too much. I can't see any good reason to write to .metadata, so a PEP note ("Making changes to sys.implementation.metadata is not guaranteed to work" or some such) should be fine. If it somebody tries to do it and it breaks, well, they get to keep the pieces. :) - Jeff From ericsnowcurrently at gmail.com Mon May 7 21:04:57 2012 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Mon, 7 May 2012 13:04:57 -0600 Subject: [Ironpython-users] feedback on PEP 421 In-Reply-To: References: Message-ID: On Mon, May 7, 2012 at 10:08 AM, Jeff Hardy wrote: > On Mon, May 7, 2012 at 8:54 AM, Eric Snow wrote: >> A plain dict would be certainly be easier to implement, just using the >> builtin. ?Exposing an immutable dict type in CPython could open a can >> of worms, but if it makes sense we could consider it. > > If it's going to be harder for CPython, then I wouldn't worry about it > too much. > > I can't see any good reason to write to .metadata, so a PEP note > ("Making changes to sys.implementation.metadata is not guaranteed to > work" or some such) should be fine. If it somebody tries to do it and > it breaks, well, they get to keep the pieces. :) Yeah, that's the route I was planning on. -eric From cmello at gmail.com Mon May 7 21:34:16 2012 From: cmello at gmail.com (Cesar Mello) Date: Mon, 7 May 2012 16:34:16 -0300 Subject: [Ironpython-users] IronPython Merge Modules for Windows In-Reply-To: References: Message-ID: Thanks! I am evaluating both options. Installing our own version including the standard library copied from IronPython (./Lib, ./DLLs) in our application directory seem to work great! But if I install the MSI instead, how can I reference the standard library that is installed with IronPython? Where should I get the standard library path? I tried to get the path from Assembly.GetAssembly(typeof(Python)), but the GAC path is returned instead of C:\Program Files (x86)\IronPython 2.7. Thank you a lot for the attention! Best regards Mello On Mon, May 7, 2012 at 12:46 PM, Jeff Hardy wrote: > On Mon, May 7, 2012 at 7:41 AM, Cesar Mello wrote: > > Hi, > > > > I've noticed IronRuby has merge modules available. Would this be the > > recommended way to redistribute IronPython? > > > > Now I need to embed IronPython in our product's installer. (This is > still a > > prototype). Any advices about this? Probably that's an effort that can be > > shared, so instead of developing proprietary installation components I > may > > contribute work on generic merge modules. > > If you've already got a bootstrapper, I would just but IronPython's > MSI in there. Merge modules are really fragile and tend to break in > weird ways, so I don't build them for IronPython (I refactored IP's > MSI builds, so that's why they're different from IR's). The > recommendation from MS seems to be to use full MSIs and chain them > using a bootstrapper. > > One thing to watch for is that a user could upgrade IP and cause your > app to be running against a new version. I try to make sure that > upgrades shouldn't break anything for just that reason, but it does > happen. The only way around this would be to build IP yourself, with a > different signing key or AssemblyVersion, and ship that version with > your app. > > - Jeff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Tue May 8 00:21:42 2012 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 7 May 2012 15:21:42 -0700 Subject: [Ironpython-users] IronPython Merge Modules for Windows In-Reply-To: References: Message-ID: On Mon, May 7, 2012 at 12:34 PM, Cesar Mello wrote: > But if I install the MSI instead, how can I reference the standard library > that is installed with IronPython? Where should I get the standard library > path? I tried to get the path from Assembly.GetAssembly(typeof(Python)), but > the GAC path is returned instead of?C:\Program Files (x86)\IronPython 2.7. The registry key HKLM\SOFTWARE\IronPython\27\InstallPath should have it. - Jeff From cmello at gmail.com Tue May 8 00:25:41 2012 From: cmello at gmail.com (Cesar Mello) Date: Mon, 7 May 2012 19:25:41 -0300 Subject: [Ironpython-users] IronPython Merge Modules for Windows In-Reply-To: References: Message-ID: Thank you so much!! Best regards! Mello On Mon, May 7, 2012 at 7:21 PM, Jeff Hardy wrote: > On Mon, May 7, 2012 at 12:34 PM, Cesar Mello wrote: > > But if I install the MSI instead, how can I reference the standard > library > > that is installed with IronPython? Where should I get the standard > library > > path? I tried to get the path from Assembly.GetAssembly(typeof(Python)), > but > > the GAC path is returned instead of C:\Program Files (x86)\IronPython > 2.7. > > The registry key HKLM\SOFTWARE\IronPython\27\InstallPath should have it. > > - Jeff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.schaber at 3s-software.com Tue May 8 08:35:14 2012 From: m.schaber at 3s-software.com (Markus Schaber) Date: Tue, 8 May 2012 06:35:14 +0000 Subject: [Ironpython-users] feedback on PEP 421 In-Reply-To: References: <727D8E16AE957149B447FE368139F2B50D7BDC39@SERVER10> Message-ID: <727D8E16AE957149B447FE368139F2B50D7BE077@SERVER10> Hi, Jeff, Von: Jeff Hardy [mailto:jdhardy at gmail.com] > On Mon, May 7, 2012 at 1:11 AM, Markus Schaber > wrote: > > Hmm, maybe we could put the host/embedder info I suggested in the other > mail there. > > Yeah, and things like which which CLR version (3.5, 4.0), implementation > (MS, Mono), subset (Silverlight, MonoTouch, MonoDroid), what host it's > running under, etc. I was thinking of adding fields to clr for that > information anyway, but it can go here instead. Sounds good. Everything of that informational stuff is far better placed there than in clr. If only for the fact that it can be probed without "import clr" which comes with some side effects. > >> I'm not really sure there's much value in having sys.version_info and > >> sys.implementation.version be different, but I believe PyPy works > >> that way, so I have no objection to it. They'll be the same in > >> IronPython, though. > > > > Hmm. It would open the possibility of IronPython supporting both Python > 2.7 and 3.X for some grace period... > > That ... yikes. It already does support some (not much) stuff using - > X:Python30, but that introduces a bunch of if statements and makes the > code quite messy. There are other ways to do it, but a clean break in a > new branch seems preferable to me. I agree here, it is much easier and cleaner to develop in two different branches. > Plus there's the issue of the > reorganized stdlib, which I'm not really sure how to cleanly solve. For the python part, it is easy: Deliver both versions in different directories, and set sys.path accordingly. For the C# part, maybe something like [PythonBindingAttribute(2)] and [PythonBindingAttribute(3)] could help. > So my > preference is to work in a different branch to 3k support. I'd like to do > some work after 2.7.3 is released, but I'm not sure I'll get to it. >From my own experience, it is the right way to branch, but often, when everything is finished and cleaned up, one finds a realtively easy way to reintegrate both branches. After all, Python 2 and Python 3 are not two completely different languages (and IronPython2 already comes with some Python3isms.). Don't get me wrong: right now, you should not try to force a generic implementation, but at least we should keep in mind that we can reevaluate everything once IronPython 3 is finished. Best regards Markus Schaber -- ___________________________ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 From no_reply at codeplex.com Tue May 8 09:51:40 2012 From: no_reply at codeplex.com (no_reply at codeplex.com) Date: 8 May 2012 00:51:40 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/7/2012 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] Exception in IronPython on unhandled exception in hosted script ---------------------------------------------- ISSUES 1. [New issue] Exception in IronPython on unhandled exception in hosted script http://ironpython.codeplex.com/workitem/32679 User jdhardy has proposed the issue: "There seems to be an issue with handling exceptions that causes another exception to be thrown when IronPython is hosted. I noticed it when doing Android work but chalked it up to a mobile issue; a recent SO question (http://stackoverflow.com/questions/10472599/create-system-windows-media-color-in-ironpython) shows that it happens on the desktop as well." ---------------------------------------------- ---------------------------------------------- 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 cmello at gmail.com Tue May 8 15:11:27 2012 From: cmello at gmail.com (Cesar Mello) Date: Tue, 8 May 2012 10:11:27 -0300 Subject: [Ironpython-users] Guidelines for embedding Python libraries in installers Message-ID: Hi! Please I would like to know if there is any recommendation for embedding Python libraries together with IronPython in applications. I'm asking this just to know if there is a path to follow towards some "ecosystem" regarding Python libraries distribution. I have seen there is an installer for NumPy based on ironpkg here: http://www.enthought.com/repo/.iron/ Should that be a recommended approach to follow? Thank you a lot for the attention! Best regards Mello -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.blank at gmail.com Tue May 8 15:34:15 2012 From: doug.blank at gmail.com (Doug Blank) Date: Tue, 8 May 2012 09:34:15 -0400 Subject: [Ironpython-users] Guidelines for embedding Python libraries in installers In-Reply-To: References: Message-ID: On Tue, May 8, 2012 at 9:11 AM, Cesar Mello wrote: > Hi! > > Please I would like to know if there is any recommendation for embedding > Python libraries together with IronPython in applications. I'm asking this > just to know if there is a path to follow towards some "ecosystem" regarding > Python libraries distribution. > > I have seen there is an installer for NumPy based on ironpkg here: > http://www.enthought.com/repo/.iron/ > > Should that be a recommended approach to follow? I don't have any particular comment on whether that is the best approach or not, but I will note that the installation doesn't work outside of Windows. However, there were just minor issues. So, if a recommendation is suggested, let's please make it a cross-platform solution. Thanks! -Doug > Thank you a lot for the attention! > > Best regards > Mello > > > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users > From cmello at gmail.com Tue May 8 16:07:09 2012 From: cmello at gmail.com (Cesar Mello) Date: Tue, 8 May 2012 11:07:09 -0300 Subject: [Ironpython-users] Guidelines for embedding Python libraries in installers In-Reply-To: References: Message-ID: Hi Doug, I forgot to mention that' On Tue, May 8, 2012 at 10:34 AM, Doug Blank wrote: > On Tue, May 8, 2012 at 9:11 AM, Cesar Mello wrote: > > Hi! > > > > Please I would like to know if there is any recommendation for embedding > > Python libraries together with IronPython in applications. I'm asking > this > > just to know if there is a path to follow towards some "ecosystem" > regarding > > Python libraries distribution. > > > > I have seen there is an installer for NumPy based on ironpkg here: > > http://www.enthought.com/repo/.iron/ > > > > Should that be a recommended approach to follow? > > I don't have any particular comment on whether that is the best > approach or not, but I will note that the installation doesn't work > outside of Windows. However, there were just minor issues. > > So, if a recommendation is suggested, let's please make it a > cross-platform solution. > > Thanks! > > -Doug > > > > Thank you a lot for the attention! > > > > Best regards > > Mello > > > > > > _______________________________________________ > > Ironpython-users mailing list > > Ironpython-users at python.org > > http://mail.python.org/mailman/listinfo/ironpython-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmello at gmail.com Tue May 8 16:16:22 2012 From: cmello at gmail.com (Cesar Mello) Date: Tue, 8 May 2012 11:16:22 -0300 Subject: [Ironpython-users] Guidelines for embedding Python libraries in installers In-Reply-To: References: Message-ID: Hi Doug! I was about to mention the same thing. We are not targeting other platforms at this time, but platform independence is one of the main reasons we are choosing Python for our embedded scripting. Thanks! Best regards Mello On Tue, May 8, 2012 at 10:34 AM, Doug Blank wrote: > On Tue, May 8, 2012 at 9:11 AM, Cesar Mello wrote: > > Hi! > > > > Please I would like to know if there is any recommendation for embedding > > Python libraries together with IronPython in applications. I'm asking > this > > just to know if there is a path to follow towards some "ecosystem" > regarding > > Python libraries distribution. > > > > I have seen there is an installer for NumPy based on ironpkg here: > > http://www.enthought.com/repo/.iron/ > > > > Should that be a recommended approach to follow? > > I don't have any particular comment on whether that is the best > approach or not, but I will note that the installation doesn't work > outside of Windows. However, there were just minor issues. > > So, if a recommendation is suggested, let's please make it a > cross-platform solution. > > Thanks! > > -Doug > > > > Thank you a lot for the attention! > > > > Best regards > > Mello > > > > > > _______________________________________________ > > Ironpython-users mailing list > > Ironpython-users at python.org > > http://mail.python.org/mailman/listinfo/ironpython-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Tue May 8 17:47:39 2012 From: jdhardy at gmail.com (Jeff Hardy) Date: Tue, 8 May 2012 08:47:39 -0700 Subject: [Ironpython-users] Guidelines for embedding Python libraries in installers In-Reply-To: References: Message-ID: On Tue, May 8, 2012 at 6:11 AM, Cesar Mello wrote: > Hi! > > Please I would like to know if there is any recommendation for embedding > Python libraries together with IronPython in applications. I'm asking this > just to know if there is a path to follow towards some "ecosystem" regarding > Python libraries distribution. The standard home for Python packages is PyPI (aka "the Cheeseshop") - http://pypi.python.org. Python packaging in general is handled the standard distutils library, and the setuptools/distribute extensions (most of which are folded into distutils2, now known as 'packaging' in Python 3.3). Installation is done with easy_install (part of setuptools/distribute) or pip. One thing I'll give the Ruby guys - they got the gem ecosystem in place early and stuck with it. Now, IronPython doesn't support a lot of this right now. distribute and pip mostly work (there are a couple of tiny patches needed to them that I need to work on), but most of the pypi packages are bz2, which was a problem until I added bz2 a couple of days ago. Getting distribute and pip (and maybe virtualenv) working is one of my goals for 2.7.3. > > I have seen there is an installer for NumPy based on ironpkg here: > http://www.enthought.com/repo/.iron/ > > Should that be a recommended approach to follow? That was a one-off created by Enthought for distributing NumPy. I don't think there's much reason to use it. Since I know you want to include the libraries, the easiest way (for now) would be to use a clean CPython installation and use easy_install to add the necessary packages (they are stored in Lib/site-packages). Then copy the site-packages directory into the IronPython stdlib so that it can all be deployed together. - Jeff From oxcsnicho at gmail.com Tue May 8 18:43:59 2012 From: oxcsnicho at gmail.com (YANG, Lin) Date: Wed, 9 May 2012 00:43:59 +0800 Subject: [Ironpython-users] Issue on windows phone: passing parameters to functions Message-ID: Hi all, New to the list due to the fact that I'm working on embedding IronPython in WP71 :) My goal is to leverage a Python-based library as the backend of my WP application. I actually encountered another issue (in addition to the 2+2.5 one that is being discovered in March, found that in archives) that seem to be a big issue for my porting work. It looks that passing parameters in functions does not work currently. Say, you can do the following: >>> def Four(): ... print 2+2 ... >>> Four() 4 but you cannot do this: >>> def PlusFour(n) ... print 2+2+n ... >>> Four (10) Attempt to access the method failed: IronPython.Runtime.PythonFunction +FunctionCaller`1.Call1 (System.Runtime.CompilerServices.CallSite, IronPython.Runtime.CodeContext, System.Object, System.Object) Is there a way to work around this? thanks, Lin -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmello at gmail.com Tue May 8 19:25:53 2012 From: cmello at gmail.com (Cesar Mello) Date: Tue, 8 May 2012 14:25:53 -0300 Subject: [Ironpython-users] Guidelines for embedding Python libraries in installers In-Reply-To: References: Message-ID: Thank you very much for the explanation Jeff! For my current prototype I have added the IronPython's MSI to the bootstrapper; and the NumPy's \DLLs and \Lib folders to my products's dir; and then I setup the host library path with both IronPython's folders and the app's \DLLs and \Lib. It seems to be working nicely. Just as a curiosity, a small weird thing I saw with NumPy was this issue: http://stackoverflow.com/questions/5526151/ironpython-invocation-from-c-sharp-with-scipy-fails-with-importexception-no . But I added the reference and it works now. Thanks a lot! Best regards! Mello On Tue, May 8, 2012 at 12:47 PM, Jeff Hardy wrote: > On Tue, May 8, 2012 at 6:11 AM, Cesar Mello wrote: > > Hi! > > > > Please I would like to know if there is any recommendation for embedding > > Python libraries together with IronPython in applications. I'm asking > this > > just to know if there is a path to follow towards some "ecosystem" > regarding > > Python libraries distribution. > > The standard home for Python packages is PyPI (aka "the Cheeseshop") - > http://pypi.python.org. Python packaging in general is handled the > standard distutils library, and the setuptools/distribute extensions > (most of which are folded into distutils2, now known as 'packaging' in > Python 3.3). Installation is done with easy_install (part of > setuptools/distribute) or pip. > > One thing I'll give the Ruby guys - they got the gem ecosystem in > place early and stuck with it. > > Now, IronPython doesn't support a lot of this right now. distribute > and pip mostly work (there are a couple of tiny patches needed to them > that I need to work on), but most of the pypi packages are bz2, which > was a problem until I added bz2 a couple of days ago. Getting > distribute and pip (and maybe virtualenv) working is one of my goals > for 2.7.3. > > > > > I have seen there is an installer for NumPy based on ironpkg here: > > http://www.enthought.com/repo/.iron/ > > > > Should that be a recommended approach to follow? > > That was a one-off created by Enthought for distributing NumPy. I > don't think there's much reason to use it. > > Since I know you want to include the libraries, the easiest way (for > now) would be to use a clean CPython installation and use easy_install > to add the necessary packages (they are stored in Lib/site-packages). > Then copy the site-packages directory into the IronPython stdlib so > that it can all be deployed together. > > - Jeff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Tue May 8 19:30:02 2012 From: jdhardy at gmail.com (Jeff Hardy) Date: Tue, 8 May 2012 10:30:02 -0700 Subject: [Ironpython-users] Issue on windows phone: passing parameters to functions In-Reply-To: References: Message-ID: On Tue, May 8, 2012 at 9:43 AM, YANG, Lin wrote: > Hi all, > > New to the list due to the fact that I'm working on embedding IronPython in > WP71 :) My goal is to leverage a Python-based library as the backend of my > WP application. Excellent. My hope was that people would start banging on this (and Android) to suss the bugs out. > > I actually encountered another issue (in addition to the 2+2.5 one that is > being discovered in March, found that in archives) that seem to be a big > issue for my porting work. It looks that passing parameters in functions > does not work currently. Say, you can do the following: > >>>> def Four(): > ...? print 2+2 > ... >>>> Four() > 4 > > but you cannot do this: > >>>> def PlusFour(n) > ...? print 2+2+n > ... >>>> Four (10) > Attempt to access the method failed: > IronPython.Runtime.PythonFunction > +FunctionCaller`1.Call1 > (System.Runtime.CompilerServices.CallSite, > IronPython.Runtime.CodeContext, System.Object, > System.Object) Looks like a bug. Can you open an issue (http://ironpython.codeplex.com/WorkItem/Create) with a self-contained reproduction attached (both the python and C# code)? WP7 isn't very well tested. It compiles, but that's about the extent of it. You'll likely encounter more issues, but if you're willing to file bugs for them it would be a huge help. > > Is there a way to work around this? Global variables? ;) - Jeff From igor.brejc at gmail.com Tue May 8 20:45:23 2012 From: igor.brejc at gmail.com (Igor Brejc) Date: Tue, 8 May 2012 20:45:23 +0200 Subject: [Ironpython-users] Guidelines for embedding Python libraries in installers In-Reply-To: References: Message-ID: Hi, Maperitive uses IronPython for embedded scripting. What I did for Maperitive (I'm not using MSI installations, I just have a ZIP package) is to simply include the IronPython DLLs and some of the libraries from CPython (copy pasted into the package). It works on Windows, Linux and Mac. Igor On Tue, May 8, 2012 at 7:25 PM, Cesar Mello wrote: > Thank you very much for the explanation Jeff! > > For my current prototype I have added the IronPython's MSI to the > bootstrapper; and the NumPy's \DLLs and \Lib folders to my products's dir; > and then I setup the host library path with both IronPython's folders and > the app's \DLLs and \Lib. It seems to be working nicely. > > Just as a curiosity, a small weird thing I saw with NumPy was this issue: > http://stackoverflow.com/questions/5526151/ironpython-invocation-from-c-sharp-with-scipy-fails-with-importexception-no . > But I added the reference and it works now. > > Thanks a lot! > > Best regards! > Mello > > > > > > On Tue, May 8, 2012 at 12:47 PM, Jeff Hardy wrote: > >> On Tue, May 8, 2012 at 6:11 AM, Cesar Mello wrote: >> > Hi! >> > >> > Please I would like to know if there is any recommendation for embedding >> > Python libraries together with IronPython in applications. I'm asking >> this >> > just to know if there is a path to follow towards some "ecosystem" >> regarding >> > Python libraries distribution. >> >> The standard home for Python packages is PyPI (aka "the Cheeseshop") - >> http://pypi.python.org. Python packaging in general is handled the >> standard distutils library, and the setuptools/distribute extensions >> (most of which are folded into distutils2, now known as 'packaging' in >> Python 3.3). Installation is done with easy_install (part of >> setuptools/distribute) or pip. >> >> One thing I'll give the Ruby guys - they got the gem ecosystem in >> place early and stuck with it. >> >> Now, IronPython doesn't support a lot of this right now. distribute >> and pip mostly work (there are a couple of tiny patches needed to them >> that I need to work on), but most of the pypi packages are bz2, which >> was a problem until I added bz2 a couple of days ago. Getting >> distribute and pip (and maybe virtualenv) working is one of my goals >> for 2.7.3. >> >> > >> > I have seen there is an installer for NumPy based on ironpkg here: >> > http://www.enthought.com/repo/.iron/ >> > >> > Should that be a recommended approach to follow? >> >> That was a one-off created by Enthought for distributing NumPy. I >> don't think there's much reason to use it. >> >> Since I know you want to include the libraries, the easiest way (for >> now) would be to use a clean CPython installation and use easy_install >> to add the necessary packages (they are stored in Lib/site-packages). >> Then copy the site-packages directory into the IronPython stdlib so >> that it can all be deployed together. >> >> - Jeff >> > > > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Fri May 11 01:58:09 2012 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 10 May 2012 23:58:09 +0000 Subject: [Ironpython-users] [ANN Python Tools for Visual Studio 1.5 Alpha Message-ID: <6757ED2748BC0A43B9F3E4DA32D65AB019675D@CH1PRD0310MB357.namprd03.prod.outlook.com> We're pleased to announce the release of Python Tools for Visual Studio 1.5 Alpha http://pytools.codeplex.com/releases/view/82011 . Python Tools for Visual Studio (PTVS) is an open-source plug-in for Visual Studio which supports programming with the Python language. PTVS supports a broad range of features including: * Supports Cpython, IronPython, Jython and Pypy * Python editor with advanced member, signature intellisense and refactoring * Code navigation: "Find all refs", goto definition, and object browser * Local and remote debugging * Profiling with multiple views * Integrated REPL window with inline matplotlib graphics * Support for HPC clusters and MPI, including debugging & Profiling * Interactive parallel computing via integrated IPython REPL The primary new feature for this release is Django! The http://www.djangoproject.com is a popular Python webframework/CMS which is used by many reputable companies and high traffic websites. In this Alpha release the following are supported: * Create a New Project / Django Application * Add Django HTML Template * Intellisense for Django templates * Runtime debugging of Django templates * Use IIS with a pure Python FastCGI interface There have also been a couple of new intellisense features contributed from the community. This includes completions after "def " based upon methods defined in base classes and completions for exception types after "raise" statements" (thanks Zooba!). Full list of issues addressed in this release: * 673 Setting Interpreter Programmatically * 336 Pixelated Icons on Windows 7 * 665 Relative interpreter path * 664 Display each available doc strings for one element * 657 Code Completion / IntelliSense Python 3.2 (re.compile) * 662 IronPython interactive running incredibly slow * 654 Built-in functions have parameter info default value issues * 226 Display list of exceptions after typing raise or except * 637 Provide completions after "raise " for known exception types * 580 Provide completions as "def" We'd like to thank the following people who took the time to report the issues and feedback for this release: Anna0311, golubdr, hjyh, tramsay, zooba. From no_reply at codeplex.com Fri May 11 12:38:52 2012 From: no_reply at codeplex.com (no_reply at codeplex.com) Date: 11 May 2012 03:38:52 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/10/2012 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] Install w/Repair option requests disk install ---------------------------------------------- ISSUES 1. [New issue] Install w/Repair option requests disk install http://ironpython.codeplex.com/workitem/32694 User Robbins504 has proposed the issue: "I was rerunning the IronPython v2.7.2.1 setup from the .msi file, and choosing the Repair option. After a few initial steps and during the Copying files process, I am shown the following prompt: "Please insert the disk: " Clicking OK does nothing and continues to ask for an unspecified disk." ---------------------------------------------- ---------------------------------------------- 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 May 14 14:51:19 2012 From: no_reply at codeplex.com (no_reply at codeplex.com) Date: 14 May 2012 05:51:19 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/13/2012 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] [windows phone] passing parameters to functions 2. [New comment] [windows phone] passing parameters to functions 3. [New comment] [windows phone] passing parameters to functions ---------------------------------------------- ISSUES 1. [New issue] [windows phone] passing parameters to functions http://ironpython.codeplex.com/workitem/32703 User oxcsnicho has proposed the issue: "I actually encountered another issue (in addition to the 2+2.5 one that is being discovered in March, found that in archives) that seem to be a big issue for my porting work. It looks that passing parameters in functions does not work currently. Say, you can do the following: >>> def Four(): ... print 2+2 ... >>> Four() 4 but you cannot do this: >>> def PlusFour(n) ... print 2+2+n ... >>> Four (10) Attempt to access the method failed: IronPython.Runtime.PythonFunction +FunctionCaller`1.Call1 (System.Runtime.CompilerServices.CallSite, IronPython.Runtime.CodeContext, System.Object, System.Object) The C# code I was using is simple: 1.create an empty WP7.1 project; 2.create correct reference (make sure when you include the dll, you set the CopyLocal property to True) 3. in MainPage.xaml.cs, do the following ** a: add using using Microsoft.Scripting.Hosting; ** b: initialize the engine in MainPage() constructor: private ScriptEngine _engine = null; public MainPage() { InitializeComponent(); _engine = IronPython.Hosting.Python.CreateEngine(); } ** c: execute the engine against above script: _engine.Execute(scriptInputBox.Text);"----------------- 2. [New comment] [windows phone] passing parameters to functions http://ironpython.codeplex.com/workitem/32703 User oxcsnicho has commented on the issue: "attached the project that I have been using"----------------- 3. [New comment] [windows phone] passing parameters to functions http://ironpython.codeplex.com/workitem/32703 User slide_o_mix has commented on the issue: "I may be able to play around with this now, I just bought a Windows Phone and would like to have IronPython running on it for various reasons." ---------------------------------------------- ---------------------------------------------- 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 sepatan at sibmail.com Thu May 17 12:39:52 2012 From: sepatan at sibmail.com (sepatan at sibmail.com) Date: Thu, 17 May 2012 17:39:52 +0700 (NOVT) Subject: [Ironpython-users] How do I get access to the objects of this class which is loaded XAML Message-ID: <58018.83.172.33.173.1337251192.squirrel@www.sibmail.com> How do I get access to the objects of this class which is loaded XAML. Given that the objects are presented to the CLR types? What namespace should be specified? The text below gives an error. 1) module proba.py: .................................... import WPF class MyWindow(Window): # p - CLR type, has a property name global p def __init__(self): wpf.LoadComponent(self, 'proba.xaml') def button1_Click(self, sender, e): MessageBox.Show(p.name) .................................... not the entire text of the program 2) file proba.xaml: xmlns:local="clr-namespace:proba" Title="Window1" Height="300" Width="300">