[Ironpython-users] IronPython 3 Version Number (Was: Item 34263 in 2.7.5?)

[Markus Schaber]

Hi, Jeff,

Von: Jeff Hardy [mailto:jdhardy at gmail.com]
> On Fri, Apr 11, 2014 at 11:40 AM, Markus Schaber <m.schaber at codesys.com>
> wrote:
> > Hi,
> >
> > Von: Jeff Hardy
> >> On Fri, Apr 11, 2014 at 11:02 AM, Olof Bjarnason
> >> <olof.bjarnason at gmail.com>
> >> wrote:
> >> > OK, that sounds like a reasonable way to do it. Very nice that it
> >> > is automatically verifiable!
> >> >
> >> > But it opens more questions from me, sorry. I find this interesting
> >> > :)
> >> >
> >> > So when an automatic test, that is determined to be a
> >> > implementation detail, fails - how does IronPython "skip" it? Is
> >> > the actual test suite specific for IronPython? I mean, is the unit
> >> > tests in IronPython a fork of CPythons test suite?
> >>
> >> Yes, since the test suite is part of the stdlib. Unittest supports an
> >> @skipIf decorator; we just use @skipIf(sys.platform == 'cli') (or
> >> occasionally wrap the function or part of the function in a similar
> >> if: statement).
> >>
> >> > Anyone know how many per cent of the CPython test suite that
> >> > IronPython
> >> pass?
> >>
> >> Nope :) To be honest, for 2.7 it's a bit of a mess. There was just
> >> never a concerted effort to drive the number down, because there were so
> many issues.
> >> The difference in string types always meant we would ever reach 100%,
> >> and refcounting dependencies are tedious and un-fun to debug.
> >>
> >> For IronPython 3, we're going to work with the Jython and PyPy devs
> >> to make the test suite work for all of us (and the PyPy team has
> >> already done a tone of work here). More importantly, it's all going
> >> to get pushed upstream so that we can minimize the forking necessary.
> >> Combined with the new NUnitLite-based test runner in IronPython 3
> >> (even running the tests for IronPython 2.7 is a chore) we should be
> >> able to get much closer to 100% coverage.
> >>
> >> This is probably the single biggest reason I'm excited about IP3 -
> >> compatibility is actually a realistic goal. There will always be some
> >> things that we can't match, but we should be able to get really close now.
> >
> > One detail where we won't be 100% compatible is indexing into strings
> > with Non-BMP Characters, as .NET strings are still bound to 16 bit "char"s.
> 
> Blech, I just checked this and you're right.

For most use cases, this is not that relevant - it is rare to actually index into a string and work on the codepoints directly.

> >> Once 2.7.5 is done I'm going to spend some time getting the CI
> >> infrastructure up to par for 3.0 and making sure that tests are run
> >> on a regular basis. By making it easier to actually contribute I'm
> >> hoping to attract a few more people - understanding IronPython is
> >> hard enough without having to understand the Byzantine build/test
> >> system 2.7 has (OK, the build system is still complex - trying to target 8
> different platforms is hard).
> >
> > Can the new multitargeting support help here?
> 
> Can you be more specific? If you mean PCLs, eventually the core will be a PCL
> with platform assemblies - just not right away (it requires some deep work in
> the DLR and extending the existing DLR PAL to handle a lot more cases).

Yes, I was thinking of the PCL mechanism, I just got the name wrong...


Best regards

Markus Schaber

CODESYS® a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber at codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915