Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#42468 closed enhancement (fixed)

py-scipy @0.13.3: enable py34 subport, python34 @3.4.0rc1:

Reported by: petrrr Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: seanfarley (Sean Farley), michaelld (Michael Dickens), jyrkiwahlstedt
Port: py-scipy, python34

Description

This port is quite relevant also as dependency. At least it is a dependency for a port I maintain. So it would be desirable to have Python 3.4 support enabled soon.

However, there might be an issue with this:

http://comments.gmane.org/gmane.comp.python.scientific.devel/18467

Note: I am a bit confused with the date of this, which seems not to correspond with rc 1 release, so the issue might in reality refer to "beta" instead of "release candidate". Here the release schedule:

http://www.python.org/dev/peps/pep-0429/

In case the above issue applies, I guess there are two options:

  • wait for Python 3.4 rc 2 (upstream fix);
  • apply the patch proposed above;

The maintainer of python34 might want to consider applying the cited patch before Python 3.4 rc2 is available, so I CC as well.

Change History (7)

comment:1 Changed 11 years ago by petrrr

Better close #42467. Here the description is complete.

Last edited 11 years ago by petrrr (previous) (diff)

comment:2 Changed 11 years ago by michaelld (Michael Dickens)

Does anyone have a diff on what MacPorts provides regarding py-scipy (still currently 0.13.3) support for python34 (now at rc2)? I don't have time right now to work out the details; hopefully someone else does have some time. If this were as simple as adding "34" support to the py-scipy list, that would be great ... but, I'm doubting this is the case.

comment:3 Changed 11 years ago by petrrr

I understand that the above documented possible issue should not apply any more. Anyway, if nobody is faster, I might try to see what happens if py34 is enabled.

comment:4 Changed 11 years ago by michaelld (Michael Dickens)

Go for it! Let this ticket know & if it works for you then I'll push the change.

comment:5 Changed 11 years ago by petrrr

I now was able to do some testing regarding py34 subport. The port builds fine.

But there seems to be some problem with opportunistic linking. When I first build I had atlas installed, subsequent testing caused a segmentation fault. Building with atlas deactivated, avoids this problem. I imagine, this problem could affect the other subports as well. I have not tested this yet.

Some of the tests actually fail, but I think this is a know issued as the testing framework seems to have some flaws.

So I would propose to enable 'py34' subport here and track the opportunistic linking issue in a separate ticket.

comment:6 Changed 11 years ago by michaelld (Michael Dickens)

Resolution: fixed
Status: newclosed

I enabled Python 3.4 support in r117983. It seems to work for the most part for me, e.g.,

python3.4 -c "import scipy; scipy.test()"

returns

Ran 2027 tests in 22.574s
FAILED (KNOWNFAIL=2, SKIP=15, errors=13)

The same for Python 3.3 returns:

Ran 8775 tests in 113.905s
OK (KNOWNFAIL=113, SKIP=210)

which is obviously better. The same for Python 2.7 bombs out after just a few 100 tests, which is worse than for 3.4!

So, yeah; if there are opportunistic linking issue then open a new ticket with those.

comment:7 in reply to:  6 Changed 11 years ago by petrrr

Replying to michaelld@…:

I enabled Python 3.4 support in r117983. It seems to work for the most part for me, e.g.,

python3.4 -c "import scipy; scipy.test()"

returns

Ran 2027 tests in 22.574s
FAILED (KNOWNFAIL=2, SKIP=15, errors=13)

The same for Python 3.3 returns:

Ran 8775 tests in 113.905s
OK (KNOWNFAIL=113, SKIP=210)

which is obviously better. The same for Python 2.7 bombs out after just a few 100 tests, which is worse than for 3.4!

Python 3.3 vs 3.4 looks very similar to what I was observing. I do not recall any problems with 2.7, but I can re-run the test again. However, when testing 3.4 for the first time I got a segmentation fault on testing due to opportunistic linking. Maybe you want to check for this as well.

So, yeah; if there are opportunistic linking issue then open a new ticket with those.

Yes, this is what I was planning. I just have not found the time to do more exhaustive testing on this, e.g. testing also for py33 and py27.

Note: See TracTickets for help on using tickets.