Sage 3.2.3 + fixes binary for Solaris 10/Ultra Sparc IIIi

[mabshoff]

Hi,

I spend some more time on getting clisp to play nice with Maxima on
Solaris 10/Sparc and after building gcc *3.2.3* (quite ironic) I got a
binary that for now works. Since clisp will be gone from Sage in the
next week I guess this was kind of pointless, but at least I got it to
work :).

I have stuck the binary into

http://sage.math.washington.edu/home/mabshoff/solaris-binaries/

There are two components to get:

* sage-3.2.3-Solaris-10_US_IIIi.tar.gz at 387 MB
* sparc-solaris-toolchain.tar.gz at 84 MB

You need to get both since I did build my complete own toolchain.
Eventually Sun's own freeware toolchain based on gcc 3.4.3 is likely
to work, but I haven't tried building Sage with it yet. I found the
bug in sage-env that caused it to fail somewhat by accident after
fixing some orthogonal issue in there, so this will be fixed in the
near future.

To install this:

* get sparc-solaris-toolchain.tar.gz and unpack it anywhere. Edit
toolchain.bash in it and fix the paths to the new location
* get sage-3.2.3-Solaris-10_US_IIIi.tar.gz and unpack it. Before
starting Sage source toolchain.bash from the toolchain above

You only need to get the toolchain once since for now I will keep
building Sage releases on Sparc with that toolchain since g77 support
in Sage currently is pretty broken, but I will fix that too down the
road since I really dislike g95. If you do not have the toolchain or
do not source it Sage startup will fail since the libstdc++ runtime
isn't there. If you want to you can copy the needed bits into
$SAGE_ROOT/local and it should work, but I wanted to keep toolchain
and $SAGE_LOCAL separate for now so I can reuse it for new builds.

Anyway, this build fails 14 doctests for me, i.e. 5 more than on the
Solaris 10/x86 build:

sage -t "devel/sage/sage/calculus/calculus.py"
sage -t "devel/sage/sage/combinat/schubert_polynomial.py"
sage -t "devel/sage/sage/gsl/integration.pyx"
sage -t "devel/sage/sage/interfaces/lisp.py"
sage -t "devel/sage/sage/interfaces/singular.py"
sage -t "devel/sage/sage/libs/pari/gen.pyx"
sage -t "devel/sage/sage/libs/symmetrica/sb.pxi"
sage -t "devel/sage/sage/libs/symmetrica/sc.pxi"
sage -t "devel/sage/sage/rings/number_field/number_field.py"
sage -t "devel/sage/sage/rings/number_field/
number_field_element.pyx"
sage -t "devel/sage/sage/rings/number_field/
number_field_morphisms.pyx"
sage -t "devel/sage/sage/rings/polynomial/
polynomial_element.pyx"
sage -t "devel/sage/sage/rings/polynomial/toy_d_basis.py"
sage -t "devel/sage/sage/tests/book_stein_modform.py"

For nearly all of them we are closing in on fixes or are at least
debugging this. The main problem right now is in the symmetrica
interface (which also happens on Solaris 10/x86), some pexpect trouble
with clisp (that does not happen on Solaris 10/x86, but similar issues
have been reported by others on Linux and OSX). Strangely enough the
following fails only on Solaris/Sparc, but not Solaris x86:

sage -t "devel/sage/sage/rings/polynomial/polynomial_element.pyx"
Trying:
F = ff.factor()###line 1999:_sage_ >>> F = ff.factor()
Expecting nothing
Exception exceptions.RuntimeError: 'MulMod: bad args' in
'sage.rings.polynomial.polynomial_compiled.abc_pd.eval' ignored
Exception exceptions.TypeError: "unsupported operand parent(s) for
'*': '<type 'NoneType'>' and 'Number Field in alpha0 with defining
polynomial x^6 + 10/7*x^5 - 867/49*x^4 - 76/245*x^3 + 3148/35*x^2 -
25944/245*x + 48771/1225'" in
'sage.rings.polynomial.polynomial_compiled.abc_pd.eval' ignored
Exception exceptions.TypeError: "unsupported operand parent(s) for
'*': '<type 'NoneType'>' and 'Number Field in alpha0 with defining
polynomial x^6 + 10/7*x^5 - 867/49*x^4 - 76/245*x^3 + 3148/35*x^2 -
25944/245*x + 48771/1225'" in
'sage.rings.polynomial.polynomial_compiled.abc_pd.eval' ignored
Exception exceptions.RuntimeError: 'MulMod: bad args' in
'sage.rings.polynomial.polynomial_compiled.sqr_pd.eval' ignored
Exception exceptions.TypeError: "unsupported operand type(s) for *:
'NoneType' and 'NoneType'" in
'sage.rings.polynomial.polynomial_compiled.abc_pd.eval' ignored
Exception exceptions.TypeError: "unsupported operand parent(s) for
'*': '<type 'NoneType'>' and 'Number Field in alpha0 with defining
polynomial x^6 + 10/7*x^5 - 867/49*x^4 - 76/245*x^3 + 3148/35*x^2 -
25944/245*x + 48771/1225'" in
'sage.rings.polynomial.polynomial_compiled.abc_pd.eval' ignored
<SNIP>

Anyway, if you are interested in running Sage n Solaris 10/Sparc
please give this a try and report back any issues you see. Unless you
have to please also keep this discussion on list.

Cheers,

Michael

[adrian]

I tried the binary, and here is what I got:

First I modified the file toolchain.bash
then I did

source toolchain.bash

And then, now with the right enviroment, went to the sage directory
and ran sage

Then I ran sage -notebook

The first time I had no problems.

The second time, it did not open the browser for me, but complained
that

xdg-open was not found

I don't know if it needed to be in the chain, and the fact that it was
only needed the second time is a mystery. It was still posible to
open the browser and open http://localhost:8000 It did ask for my
password for the admin account, unlike the first time.

I noticed that you posted a new one. I will try the second one.

Thanks a bunch.

-Adrian.

[adrian]

This is the actual info. By looking at the file, it shows a criptic
$@, so I assume that it is called from somewhere else with that extra
argument.

/export/user1/sage/local/src/sage-3.2.3-Solaris-10_US_IIIi/local/bin/
sage-native-execute: line 8: xdg-open: command not found

On Jan 14, 5:30 pm, adrian <nihilalienumcr...@gmail.com> wrote:
> I tried the binary, and here is what I got:
>
> First I modified the file toolchain.bash
> then I did
>
> source toolchain.bash
>
> And then, now with the right enviroment, went to the sage directory
> and ran sage
>
> Then I ran sage -notebook
>
> The first time I had no problems.
>
> The second time, it did not open the browser for me, but complained
> that
>
> xdg-open was not found
>
> I don't know if it needed to be in the chain, and the fact that it was
> only needed the second time is a mystery. It was still posible to

> open the browser and openhttp://localhost:8000 It did ask for my

[mabshoff]

On Jan 14, 4:33 pm, adrian <nihilalienumcr...@gmail.com> wrote:

Hi Adrian,

> This is the actual info.  By looking at the file, it shows a criptic
> $@, so I assume that it is called from somewhere else with that extra
> argument.

Yeah, this is some annoying buglet I did fix in some other build, but
I guess the fix did not make it into that binary. Manually opening the
notebook should work and I added getting the fix into Sage 3.3 to my
list.


<SNIP>

> > I noticed that you posted a new one.  I will try the second one.

The second one is for x86/SSE3 and I don't think the fix is in there
either. IIRC I just patched out the call to open the browser
automatically last time. So what is the clean way to launch the
default browser on Solaris?

> > Thanks a bunch.
>
> > -Adrian.

Cheers,

Michael

[William Stein]

On Wed, Jan 14, 2009 at 4:33 PM, adrian <nihilali...@gmail.com> wrote:
>
> This is the actual info. By looking at the file, it shows a criptic
> $@, so I assume that it is called from somewhere else with that extra
> argument.

If you run the notebook command without the open_viewer=False command,
then sage tries to open a web browser to the address of the notebook.
It does different things on different OS's. I guess it falls back to
xdg-open, which is evidently the wrong choice on Solaris (though it is
right on linux). Somebody should open a trac ticket for this.

For now, do notebook(open_viewer=False)

William

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

[mabshoff]

On Jan 14, 4:41 pm, "William Stein" <wst...@gmail.com> wrote:

> On Wed, Jan 14, 2009 at 4:33 PM, adrian <nihilalienumcr...@gmail.com> wrote:
>
> > This is the actual info.  By looking at the file, it shows a criptic
> > $@, so I assume that it is called from somewhere else with that extra
> > argument.
>
> If you run the notebook command without the open_viewer=False command,
> then sage tries to open a web browser to the address of the notebook.
>  It does different things on different OS's.  I guess it falls back to
> xdg-open, which is evidently the wrong choice on Solaris (though it is
> right on linux).  Somebody should open a trac ticket for this.

This is now #4979.

> For now, do notebook(open_viewer=False)
>
> William

Cheers,

Michael

[adrian]

Hi Michael,

> I guess the fix did not make it into that binary. Manually opening the
> notebook should work and I added getting the fix into Sage 3.3 to my
> list.

The strange thing is that it did open the default browser and showed
the (empty) list of worksheets the first time. Only the second time
it complained about xdg-open not being found. Hence it knew how to
open the default browser.

> automatically last time. So what is the clean way to launch the
> default browser on Solaris?

I don't know...

I really appreciate the work. Manually doing it is a hassle, but IT
WORKS!!!, and that is something I am very glad about.

Thanks.
-Adrian.
-Adrian.

[mabshoff]

On Jan 14, 4:55 pm, adrian <nihilalienumcr...@gmail.com> wrote:
> Hi Michael,

Hi,

> > I guess the fix did not make it into that binary. Manually opening the
> > notebook should work and I added getting the fix into Sage 3.3 to my
> > list.
>
> The strange thing is that it did open the default browser and showed
> the (empty) list of worksheets the first time.  Only the second time
> it complained about xdg-open not being found.  Hence it knew how to
> open the default browser.

Yes, strange indeed

> > automatically last time. So what is the clean way to launch the
> > default browser on Solaris?
>
> I don't know...

I poked around and this seems to be the best solution:

-bash-3.00$ /usr/dt/bin/sdtwebclient --help
/usr/dt/bin/sdtwebclient[117]: getopts: help bad option(s)
Usage: sdtwebclient [-b browser] [-o browser_opts] url-string
-bash-3.00$ man sdtwebclient
No manual entry for sdtwebclient.

I will add the info to the ticket.

It is well hidden and I am not 100% sure if it is guaranteed to be
installed, but dt is installed with X on Solaris IIRC. At least we can
give it a try and see what happens :)

> I really appreciate the work.   Manually doing it is a hassle, but IT
> WORKS!!!, and that is something I am very glad about.

Well, Sage on Solaris has been starting since about 2.8.14, so this is
nothing new to me. But I admit that having binaries is certainly much
easier for the user who does not want to root around in the innards of
Sage's build system for a couple hours ;)

> Thanks.
> -Adrian.

Please let us know if you run into any more trouble. Note that this
build does not pass 100% of the doctests, so you will run into issues
that are for now build specific. Compared to the official 3.2.3
release you will also see different, but mathematically identical
results since this build uses the eMPIRe.spkg instead of the old gmp
one. Since we are switching in Sage 3.3 this will be a thing of the
past shortly.

Cheers,

Michael

[adrian]

I downloaded the file from

http://portland.freedesktop.org/download/xdg-utils-1.0.2.tgz

and compiled it locally. It worked!

I was using the cholesterol free desktop (xfce), and then the terminal
spat the exo-open not found, as it seems to be the one used by the
xfce to open files.

In this machine, gnome-open works, but not on the other ones. And I
guess that is the one that xdg-open calls in this machine when I use
the gnome-desktop.

In short, compiling xdg-utils, and using gnome as the desktop
completely solves the problem in this machine, but am not sure on the
others (they have gnome-open; but it does not work)

I don't know about sdtwebclient

Thanks for all the work!

-Adrian.

[mabshoff]

On Jan 14, 5:34 pm, adrian <nihilalienumcr...@gmail.com> wrote:

Hi Adrian,

> I downloaded the file from
>
> http://portland.freedesktop.org/download/xdg-utils-1.0.2.tgz
>
> and compiled it locally.  It worked!

Ok, I am somewhat surprised those freedesktop bits are not shipped
with Solaris 10, but maybe OpenSolaris has them.

> I was using the cholesterol free desktop (xfce), and then the terminal
> spat the exo-open not found, as it seems to be the one used by the
> xfce to open files.
>
> In this machine, gnome-open works, but not on the other ones.  And I
> guess that is the one that xdg-open calls in this machine when I use
> the gnome-desktop.

Yes, we want something that works on default Solaris installs.

> In short, compiling xdg-utils, and using gnome as the desktop
> completely solves the problem in this machine, but am not sure on the
> others (they have gnome-open; but it does not work)
>
> I don't know about sdtwebclient

It goes back to CDE, so it has been around for a while. If you look
into /usr/dt/bin there is all kinds of other goodies that might be
useful. Since backward compatibility is extremely high on Solaris I
think this solution will work for a while :)

> Thanks for all the work!

Out of curiosity: What exact Solaris release are you running this
binary on? I would be curious if the build works on Nevada or even
OpenSolaris. The main issue I can see would be that the gcc or some
other component of the toolchain could not work, but once we switch to
some other compiler this might go away.

> -Adrian.

Cheers,

Michael

[adrian]

Hi,

> It goes back to CDE, so it has been around for a while. If you look
> into /usr/dt/bin there is all kinds of other goodies that might be
> useful. Since backward compatibility is extremely high on Solaris I
> think this solution will work for a while :)

I just compiled xdg-utils in the other computer (Solaris 9 USIII)
running cde, and it worked fine: the command xdg-open http://www.google.com
worked.

I guess xdg-utils could be precompiled and shipped with the chaintool,
or find another alternative.

> Out of curiosity: What exact Solaris release are you running this
> binary on? I would be curious if the build works on Nevada or even

I ran the binary in Solaris 10 in an US IV, and we were planning to
install it in some Solaris 9 USIII.

> OpenSolaris. The main issue I can see would be that the gcc or some
> other component of the toolchain could not work, but once we switch to
> some other compiler this might go away.

Thanks
-Adrian.

[mabshoff]

On Jan 14, 6:05 pm, adrian <nihilalienumcr...@gmail.com> wrote:
> Hi,

Hi,

> > It goes back to CDE, so it has been around for a while. If you look
> > into /usr/dt/bin there is all kinds of other goodies that might be
> > useful. Since backward compatibility is extremely high on Solaris I
> > think this solution will work for a while :)
>
> I just compiled xdg-utils in the other computer (Solaris 9 USIII)
> running cde, and it worked fine:  the command xdg-openhttp://www.google.com
> worked.

Ok, good to know.

> I guess xdg-utils could be precompiled and shipped with the chaintool,
> or find another alternative.

Yeah. One issue right now is that Solaris 10 does not provide any top
utility and for now we depend on it since get_memory_usage() uses it.
That might change in the long term, but for now it is unclear to me
how we could get the current memory use of a given pid directly. I am
sure it is possible and the little things like this will be smoothed
out as we get more Solaris users.

> > Out of curiosity: What exact Solaris release are you running this
> > binary on? I would be curious if the build works on Nevada or even
>
> I ran the binary in Solaris 10 in an US IV, and we were planning to
> install it in some Solaris 9 USIII.

Ok, I doubt the binary will run on Solaris 9. I have build Sage on
Solaris 9 boxen before and have some workaround headers since I never
got C99 to play nicely on that platform. It is a crude hack, but it
worked back then. I could give it a try in the next couple days since
I have access to a 4 CPU US III Solaris 9 box.

> > OpenSolaris. The main issue I can see would be that the gcc or some
> > other component of the toolchain could not work, but once we switch to
> > some other compiler this might go away.
>
> Thanks
> -Adrian.

Cheers,

Michael