Re: [IronPython] Issue triage

I've closed the closeable issues. Thanks for looking at these! - Jeff On Sun, Feb 13, 2011 at 11:08 AM, Andrés Martinelli wrote: > Hi, > > I have checked out a few work items: > >  Not reproducible in 2.7B2: > >    - #26940/Medium/2.7: >      Wrong line numbers in traceback when ecoding is speci

[IronPython] Issue triage

Hi, I have checked out a few work items: Not reproducible in 2.7B2: - #26940/Medium/2.7: Wrong line numbers in traceback when ecoding is specified ( http://ironpython.codeplex.com/workitem/26940 ) could be closed. - #23650/Medium/2.6.2: Pdb set_trace and post_m

[IronPython] Issue Triage

I've closed the following issues: #23744: overtime for the method test_long in pickletester.py #23747: NotImplementedError: readbuffer_encode #23749: TypeError: EncodeQuotedPrintable() takes at most 1 non

[IronPython] Issue Triage

The following issues have been closed: - get different result for locale.setlocale method against Ironpython and cpython - OSError, because it is being used by another process.

Re: [IronPython] Issue Triage

> > *From:* users-boun...@lists.ironpython.com [mailto: > users-boun...@lists.ironpython.com] *On Behalf Of *Bruce Bromberek > *Sent:* Sunday, January 30, 2011 12:22 PM > *To:* Discussion of IronPython > *Subject:* [IronPython] Issue Triage > > > > I though I'd h

Re: [IronPython] Issue Triage

[mailto:users-boun...@lists.ironpython.com] On Behalf Of Bruce Bromberek Sent: Sunday, January 30, 2011 12:22 PM To: Discussion of IronPython Subject: [IronPython] Issue Triage I though I'd help by going through any issues tagged with High importance, unassigned, starting with ones from previous releases and

[IronPython] Issue Triage

I though I'd help by going through any issues tagged with High importance, unassigned, starting with ones from previous releases and seeing is they are still relevant. Issue 26426, which involves sympy (algebraic manipulation) under ironpython. With the most recent git version of sympy and IronP

Re: [IronPython] Issue Triage

> On Thu, Jan 27, 2011 at 6:38 AM, Richard Nienaber > wrote: > > Issues that reference 'SNAP' and 'merlin-*' e.g. > > > > SNAP: test_memory.py has begun failing > > IronPython: test_weakref.py fails on merlin-18 > > > > If the test passes, is it okay to close issues like this? I know SNAP > > was

Re: [IronPython] Issue Triage

Excellent - 10 more down, only ~1000 to go :) On Thu, Jan 27, 2011 at 6:38 AM, Richard Nienaber wrote: > Issues that reference 'SNAP' and 'merlin-*' e.g. > > SNAP: test_memory.py has begun failing > IronPython: test_weakref.py fails on merlin-18 > > If the test passes, is it okay to close issues

[IronPython] Issue Triage

I've closed the following issues - Negative: Different error thrown for wrong number of parameters under PreferComDispatch mode - compiling a package with sub-packages doesnt preserve the hierarchy.

Re: [IronPython] Issue Triage

users-boun...@lists.ironpython.com] On Behalf Of Brian Curtin Sent: Sunday, January 16, 2011 3:13 PM To: Discussion of IronPython Subject: Re: [IronPython] Issue Triage On Sun, Jan 16, 2011 at 16:06, Richard Nienaber mailto:rjniena...@gmail.com>> wrote: Having said that, I'm still looking for a guide

Re: [IronPython] Issue Triage

IronPython] Issue Triage I've closed the following issues: test blocking: support setting field of value type when calling ctor<http://ironpython.codeplex.com/workitem/24008> keyword argument is also treated as args for params array<http://ironpython.codeplex.com/workitem/24000>

Re: [IronPython] Issue Triage

On Sun, Jan 16, 2011 at 16:06, Richard Nienaber wrote: > Having said that, I'm still looking for a guideline about what to do in the > scenario where the behaviour of IronPython is more 'correct' than CPython. > > Richard > I would suggest creating issues on the CPython bug tracker for those case

Re: [IronPython] Issue Triage

Oh, I see my mistake now. My reasoning about when strings are expanded was faulty and when writing the example in C#, I didn't notice the option to not expand environment strings. Having said that, I'm still looking for a guideline about what to do in the scenario where the behaviour of IronPython

Re: [IronPython] Issue Triage

Going by the Windows documentation, I would expect REG_EXPAND_SZ to _optionally_ expand when retrieving the value, but never expand when setting it. The main set of Windows functions don't expand the value - the type is only an indicator that it may contain environment variables. That said, the on

Re: [IronPython] Issue Triage

> > Hmmm... it is still probably worth filing an issue with CPython: > http://bugs.python.org/ Will do. On Sun, Jan 16, 2011 at 5:29 PM, Michael Foord wrote: > On 16/01/2011 09:23, Richard Nienaber wrote: > > I've closed the following issues: > > test blocking: sup

Re: [IronPython] Issue Triage

On 16/01/2011 09:23, Richard Nienaber wrote: I've closed the following issues: test blocking: support setting field of value type when calling ctor keyword argument is also treated as args for params array

[IronPython] Issue Triage

I've closed the following issues: test blocking: support setting field of value type when calling ctor keyword argument is also treated as args for params array unable to invoke delegate object with metho

Re: [IronPython] Issue Triage

Jeff wrote: > On Fri, Jan 7, 2011 at 11:12 AM, Dino Viehland > wrote: > > I've added a comment to this one.  Personally my vote is (and has been > > for some > > Time) to move all method binder bugs to IronPython 3k.  Method binding > > is subtle enough and changing it could break existing code th

Re: [IronPython] Issue Triage

On Fri, Jan 7, 2011 at 11:12 AM, Dino Viehland wrote: > I've added a comment to this one.  Personally my vote is (and has been for > some > Time) to move all method binder bugs to IronPython 3k.  Method binding is > subtle > enough and changing it could break existing code that we should tread

Re: [IronPython] Issue Triage

Jeff wrote: > > I think the following needs some further scrutiny before closing: > > > > module globals are reported incorrectly to sys.settrace > > (http://ironpython.codeplex.com/workitem/26243) > > Finish FunctionEnvironment cleanup > > (http://ironpython.codeplex.com/workitem/23992) > > Unable

Re: [IronPython] Issue Triage

On Wed, Dec 29, 2010 at 2:42 PM, Richard Nienaber wrote: > I think the following needs some further scrutiny before closing: > > module globals are reported incorrectly to sys.settrace > (http://ironpython.codeplex.com/workitem/26243) > Finish FunctionEnvironment cleanup > (http://ironpython.cod

[IronPython] Issue Triage

I've closed the following items: precision not respected when formatting strings IsolateStorage.GetUserStoreForApplication throws SystemError in IronPython 2.6 ipy.exe doesn't set module __name__ correct

Re: [IronPython] Issue Triage

On Mon, Dec 13, 2010 at 7:14 AM, Richard Nienaber wrote: > The issues below look like they can be set to fixed. > > ref parameter doesn't work with protected methods > > Skype4COM and System.Windows.Forms.AxHost+InvalidActiveXStateException > > logging module still crashing even with Python Issue5

Re: [IronPython] Issue Triage

First off: thanks, again, for doing this. I haven't had a chance to look at these, but I'll try ASAP. On Mon, Dec 13, 2010 at 7:14 AM, Richard Nienaber wrote: > Sorry, if this is covered somewhere in the documentation but how do I run > the tests in the '\Src\IronPython_Main\Languages\IronPython\

[IronPython] Issue Triage

The issues below look like they can be set to fixed. - ref parameter doesn't work with protected methods - Skype4COM and System.Windows.Forms.AxHost+Invalid ActiveXStateException

Re: [IronPython] Issue Triage

On Fri, Dec 10, 2010 at 1:42 AM, Jeff Hardy wrote: > On Thu, Dec 9, 2010 at 7:10 PM, Dino Viehland wrote: >> Thanks for doing this!  I’ve gone ahead and closed the first three.  I’m >> going to leave the compile() one open so it can get the right exception. > > It looks like IndentationError is a

Re: [IronPython] Issue Triage

On Thu, Dec 9, 2010 at 7:10 PM, Dino Viehland wrote: > Thanks for doing this!  I’ve gone ahead and closed the first three.  I’m > going to leave the compile() one open so it can get the right exception. It looks like IndentationError is a subclass of SyntaxError anyway, so it should still work, r

Re: [IronPython] Issue Triage

r 09, 2010 12:32 AM To: Discussion of IronPython Subject: Re: [IronPython] Issue Triage I've identified the following issues that I think are fixed: PEP 342 broken -- generator.send() causes IPy exception<http://ironpython.codeplex.com/workitem/25574> socket.gethostbyaddr("&quo

Re: [IronPython] Issue Triage

I've identified the following issues that I think are fixed: PEP 342 broken -- generator.send() causes IPy exception socket.gethostbyaddr("") broken under .NET 4.0 Beta (It looks like the correct behavio

[IronPython] Issue Triage

There are over 1000 open issues on CodePlex (http://ironpython.codeplex.com/workitem/list/basic), many of them dating back to IronPython 1.0. A few people have wondered what they can do to help IronPython without being familiar with the project. If you're one of those people, then triaging issues w