Opened 11 years ago

Closed 11 years ago

#9474 closed defect (fixed)

Revert ECL back to ecl-10.2.1 and apply patches for Solaris 10 and OpenSolaris x64

Reported by: drkirkby Owned by: drkirkby
Priority: blocker Milestone: sage-4.5
Component: porting: Solaris Keywords:
Cc: Merged in: sage-4.5.rc1
Authors: David Kirkby Reviewers: John Palmieri
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by jhpalmieri)

Since it is claimed ECL and Maxima are causing doctest failures on sage.math (see #9460) a decision has been made to revert ECL and Maxima. This patch will use the old version, but with a couple of patches which are already positively reviewed to allow ECL to build on Solaris 10 and OpenSolaris x64.

Let's hope this solves the problem, as several people manage to build sage-4.5.alpah4 on sage.math.washington.edu with Maxima tests passing, and other tests have failed on sage.math too.

Dave

To the release manager: merge the spkg from #9187 instead.

Attachments (2)

9474.patch (3.0 KB) - added by drkirkby 11 years ago.
Reverts ECL back to an older version, while preseving a couple of important Solaris and OpenSolaris patches
9474.2.patch (607 bytes) - added by drkirkby 11 years ago.
Correction SunOs? -> SunOS

Download all attachments as: .zip

Change History (24)

Changed 11 years ago by drkirkby

Reverts ECL back to an older version, while preseving a couple of important Solaris and OpenSolaris patches

comment:1 follow-up: Changed 11 years ago by leif

I think SunOs should be SunOS in spkg-install, right?

comment:2 in reply to: ↑ 1 Changed 11 years ago by drkirkby

Replying to leif:

I think SunOs should be SunOS in spkg-install, right?

Yes, give me a few minutes and I'll update it.

Changed 11 years ago by drkirkby

Correction SunOs? -> SunOS

comment:3 Changed 11 years ago by drkirkby

  • Authors set to David Kirkby
  • Status changed from new to needs_review

comment:4 follow-up: Changed 11 years ago by leif

Looks at least reasonable, and doesn't break things on other platforms.

I cannot really judge (or test) the behavior on SunOS/Solaris, though, especially regarding the test for ... 5.11 i86pc.

comment:5 follow-up: Changed 11 years ago by leif

Btw,

if [ "$VAR" = word ] ; then
    ...

is sufficient, you don't need an extra character there, nor does word (not containing spaces) need to be quoted. ;-)

-Leif

comment:6 Changed 11 years ago by rlm

  • Priority changed from blocker to major

comment:7 in reply to: ↑ 5 Changed 11 years ago by drkirkby

Replying to leif:

Btw,

if [ "$VAR" = word ] ; then
    ...

is sufficient, you don't need an extra character there, nor does word (not containing spaces) need to be quoted. ;-)

-Leif

It's less portable without the extra character! (You might note that autoconf adds the extra character too). I just get into a habit of writing my code the most portable way, even if in this case it will be run with bash, which for all recent versions at least does not require an extra character.

I'm aware that there are no quotes needed - you might not the new code which deletes the temporary files has no such quotes.

Dave

comment:8 in reply to: ↑ 4 ; follow-up: Changed 11 years ago by drkirkby

Replying to leif:

Looks at least reasonable, and doesn't break things on other platforms.

I cannot really judge (or test) the behavior on SunOS/Solaris, though, especially regarding the test for ... 5.11 i86pc.

I appreciate that. But all 3 options are POSIX, and as you say it does not break on any other platform. Basically that test ensures the code will only be executed on a very specific platform where I know there is an issue.

Here's the output on my Sony Vaio laptop (OpenSolaris 2009.06 snv_111b)

drkirkby@laptop:~$ uname -rsm
SunOS 5.11 i86pc

on disk.math.washington.edu (OpenSolaris 2008.11 snv_101b_rc2)

-bash-3.2$ uname -rsm
SunOS 5.11 i86pc

and my Sun Ultra 27 (OpenSolaris 2009.06, upgraded to snv_134)

drkirkby@hawk:~$ uname -rsm
SunOS 5.11 i86pc

Note I did not use the unportable '-p' option. That does not work on HP-UX.

So can this get a positive review?

Dave

comment:9 follow-up: Changed 11 years ago by rlm

Can you or someone test this on a few non-Solaris systems before the positive review?

comment:10 Changed 11 years ago by rlm

  • Priority changed from major to blocker

comment:11 in reply to: ↑ 8 ; follow-up: Changed 11 years ago by leif

Replying to drkirkby:

Replying to leif:

I cannot really judge (or test) the behavior on SunOS/Solaris, though, especially regarding the test for ... 5.11 i86pc.

I appreciate that. But all 3 options are POSIX, and as you say it does not break on any other platform.

I had only the specific version number (and to some extent "i86pc") in mind, not the options to uname, i.e. I did not know if all affected systems report exactly the same.

comment:12 in reply to: ↑ 11 Changed 11 years ago by drkirkby

Replying to leif:

I had only the specific version number (and to some extent "i86pc") in mind, not the options to uname, i.e. I did not know if all affected systems report exactly the same.

All systems I know of report the same. It may be the problem exists on some other variations of Solaris (OpenSolaris? on SPARC, Solaris 10 on x86, Solaris 10 on 64-bit SPARC), but I don't know that. Hence it is restricted to only the systems where I know its a problem.

Dave

comment:13 in reply to: ↑ 9 Changed 11 years ago by drkirkby

Replying to rlm:

Can you or someone test this on a few non-Solaris systems before the positive review?

Testing on sage.math (a Sun running Ubuntu Linux 8.04.4 LTS. )

It built fine and failed one doctest on sage.math:

----------------------------------------------------------------------

The following tests failed:

	sage -t  -long devel/sage/sage/schemes/elliptic_curves/lseries_ell.py # 3 doctests failed
----------------------------------------------------------------------
Total time for all tests: 1076.9 secon

This is the same failure William got with the sage-4.5.alpha4, and is a result of a lack of memory:

**********************************************************************
File "/mnt/usb1/scratch/kirkby/sage-4.5.rc0/devel/sage-main/sage/schemes/elliptic_curves/lseries_ell.py", line 226:
    sage: E.lseries().zeros(2)
Exception raised:
    Traceback (most recent call last):
      File "/mnt/usb1/scratch/kirkby/sage-4.5.rc0/local/bin/ncadoctest.py", line 1231, in run_one_test
        self.run_one_example(test, example, filename, compileflags)
      File "/mnt/usb1/scratch/kirkby/sage-4.5.rc0/local/bin/sagedoctest.py", line 38, in run_one_example
        OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
      File "/mnt/usb1/scratch/kirkby/sage-4.5.rc0/local/bin/ncadoctest.py", line 1172, in run_one_example
        compileflags, 1) in test.globs
      File "<doctest __main__.example_9[3]>", line 1, in <module>
        E.lseries().zeros(Integer(2))###line 226:
    sage: E.lseries().zeros(2)
      File "/mnt/usb1/scratch/kirkby/sage-4.5.rc0/local/lib/python/site-packages/sage/schemes/elliptic_curves/lseries_ell.py", line 236, in zeros
        return lcalc.zeros(n, L=self.__E)
      File "/mnt/usb1/scratch/kirkby/sage-4.5.rc0/local/lib/python/site-packages/sage/lfunctions/lcalc.py", line 125, in zeros
        X = self('-z %s %s'%(int(n), L))
      File "/mnt/usb1/scratch/kirkby/sage-4.5.rc0/local/lib/python/site-packages/sage/lfunctions/lcalc.py", line 65, in __call__
        return os.popen(cmd).read().strip()
    OSError: [Errno 12] Cannot allocate memory
**********************************************************************

I don't know how much memory that tests needs, but its passed for me before. Perhaps it needs more RAM than other tests.

I'll test on OS X (bsd.math) too, but note the changes are Solaris specific, so Linux and OX X should see exactly the same code.

Dave

comment:14 follow-up: Changed 11 years ago by cremona

I successfully installed the spkg linked here onto a build of 4.5.rc0, and am now testing the sage library. I ignored the two patches on this ticket since they appear to be changes to an spkg. If this is wrong (i.e. if I need to do something with the two patches before testing) please tell me.

This is on an AMD Opteron running ubuntu linux.

comment:15 in reply to: ↑ 14 Changed 11 years ago by drkirkby

Replying to cremona:

I successfully installed the spkg linked here onto a build of 4.5.rc0, and am now testing the sage library.

Thank you.

I ignored the two patches on this ticket since they appear to be changes to an spkg. If this is wrong (i.e. if I need to do something with the two patches before testing) please tell me.

That is not wrong. The patches are already in the .spkg, so you do not need to apply.

This is on an AMD Opteron running ubuntu linux.

Dave

comment:16 Changed 11 years ago by cremona

OK then, I can now report that testing the whole Sage library worked fine after installing the new spkg.

comment:17 Changed 11 years ago by jhpalmieri

The new spkg (actually this one plus the patch at #9187) installs for me on OS X 10.6 when building spkgs in parallel. I haven't gotten to the doctesting part of things, but if there are problems, I'll report them here.

comment:18 follow-up: Changed 11 years ago by jhpalmieri

All doctests pass for me on OS X 10.6. The new spkg also has built successfully on t2.math, and I'm running doctests now.

comment:19 in reply to: ↑ 18 Changed 11 years ago by drkirkby

Replying to jhpalmieri:

All doctests pass for me on OS X 10.6. The new spkg also has built successfully on t2.math, and I'm running doctests now.

I looked in John's directory /scratch/palmieri/sage-4.5.rc0 on t2.math, and see the doctests had completed with 7 failures. However, three of those end with # File not found which is actually just a timeout - hopefully #9316 should fix that bug. After running the tests that failed for John at the command line, with longer timeouts, I find there are two failures which will not go away.

	sage -t -long "devel/sage/doc/en/thematic_tutorials/group_theory.rst"
	sage -t -long "devel/sage/sage/libs/galrep/wrapper.pyx"

Those two failures need to be resolved. I created tickets (#9489 and #9490) for these two doctest failures.

The longest test was:

sage -t -long "devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py"
	 [3023.2 s]
 
----------------------------------------------------------------------
All tests passed!
Total time for all tests: 3023.2 seconds

so it looks like one needs a SAGE_TIMEOUT_LONG >= 3600 seconds (one hour) to be reasonably confident of not getting a timeout on 't2.math'.

Dave

comment:20 follow-up: Changed 11 years ago by drkirkby

John's successful tests would appear to have been built with ecl-10.2.1.p1.spkg from #9187, which has these changes, plus the changes to allow better building in parallel. I'm basing this on the fact that John has the ecl-10.2.1.p1.spkg in his directory, but not the ecl-10.2.1.p0.spkg I created.

kirkby@t2:[/scratch/palmieri/sage-4.5.rc0/spkg/standard] $ ls -l ecl-*
-rw-r--r--   1 palmieri 1005     4850369 Jul 12 13:31 ecl-10.2.1.p1.spkg
-rw-r--r--   1 palmieri 1005     4820179 Jul 11 12:12 ecl-10.2.1.spkg

My successful tests on OS X were also using ecl-10.2.1.p1.spkg from #9187.

Dave

comment:21 in reply to: ↑ 20 Changed 11 years ago by jhpalmieri

  • Description modified (diff)
  • Reviewers set to John Palmieri
  • Status changed from needs_review to positive_review

Replying to drkirkby:

John's successful tests would appear to have been built with ecl-10.2.1.p1.spkg from #9187, which has these changes, plus the changes to allow better building in parallel.

Yes, that's right. That's what I meant in my comment above.

I'm marking this as "positive review" since it builds on sage.math, OS X, and t2 without problem.

By the way, Dave, my build on t2 only took 2 hours this time (!) -- this is without ATLAS and the docs, of course. Some of the speedup is probably because of building in /scratch instead of /home, so thanks for that pointer.

comment:22 Changed 11 years ago by rlm

  • Merged in set to sage-4.5.rc1
  • Resolution set to fixed
  • Status changed from positive_review to closed

Merged, but as part of #9187.

Note: See TracTickets for help on using tickets.