On Jul 16, 1:33 am, "Dr. David Kirkby" <[EMAIL PROTECTED]>
wrote:
> On 15 Jul, 23:48, mabshoff <[EMAIL PROTECTED]> wrote:
>
> > On Jul 15, 3:18 pm, "Dr. David Kirkby" <[EMAIL PROTECTED]>
> > > According to ls -l, the file is 139557984 bytes long. Here's the
> > > checksum:
Hi David,
> > > $ digest -v -a md5 sage-3.0.5-sse3-i86pc--SunOS_BETA.tar.gz
>
> > > md5 (sage-3.0.5-sse3-i86pc-SunOS_BETA.tar.gz) =
> > > 5f206b211d29e5c49518de8982ac92bc
>
> > Whatever you downloaded is truncated:
>
> Yes, I see that. I've got it going now, so it can be downloaded from
> Europe OK, despite the mention of it now (In case you don't know, I'm
> in the UK).
>
> $ ./sage
> ----------------------------------------------------------------------
> | SAGE Version 3.0.5, Release Date: 2008-07-11 |
> | Type notebook() for the GUI, and license() for information. |
> ----------------------------------------------------------------------
> The SAGE install tree may have moved.
> Regenerating Python.pyo and .pyc files that hardcode the install PATH
> (please wait at most a few minutes)...
> Please do not interrupt this.
> Setting permissions of DOT_SAGE directory so only you can read and
> write it.
Ok, so far so good.
> sage: notebook()
> The notebook files are stored in: /export/home/drkirkby/.sage//
> sage_notebook
>
> There does not appear to be anything acting as a server on port 8000,
> but I know you said there were bugs on Solaris, so I guess the GUI is
> one of them.
Yes, it is a known issue to me. The notebook just sits there waiting
for entropy. I suspect this has to do with RAND_MAX on Solaris being
2^15-1 instead of 2^31-1. We had a similar bug in the randgen
framework which caused ZZ.random_element() to take between 3 and 8
seconds of CPU time to return 0 with probablity 1. On sage.math things
are a little quicker:
sage: %timeit ZZ.random_element()
1000000 loops, best of 3: 519 ns per loop
sage:
So those order of magnitudes are screwing us at the moment.
> > > Since I have had half a dozen beers tonight, that might possibly be
> > > the issues, but I doubt it. I'll try to download again.
>
> > "Mothers against drunk downloading" anyone? ;)
>
> Yeah, it needs it.
:)
> > > I would be interested in a SPARC version. The machine I have is a
> > > Blade 2000, 2 x 1.2 GHz, 8 GB RAM. That has Solaris 10, update 4
> > > (August 2007).
>
> > That should be doable, the problem right now is that clisp on Sparc is
>
> OK, well let us know when the SPARC looks more hopeful.
The ecls switch is very high up on my priority list since it is always
very needed for Sage on native Windows.
> > > Like Vincent, I believe there would be interest from Solaris users who
> > > do not subscribe here, but I think it would be premature to advertise
> > > a binary in Solaris newsgroups. Obvious places would be
> > > comp.unix,solaris, alt.solaris.x86 and a couple of the OpenSolaris
> > > forums. I know there have been several Mathematica discussions on the
> > > Solaris forums.
>
> > Sure, this is way too early. I would want to do that once Sage builds
> > actually pass doctest at least on the Solaris boxen I have access to,
> > not any time before that.
>
> Though you should weigh that against the fact that there are some real
> Sun experts on these places, that are good at debugging Solaris
> problems. It seems to me that might be what is needed now. Clearly you
> don't want mathmaticians whose universities give them Sun boxes to
> debug it, but Sun employees, or other Sun experts who have some
> interest in maths software might be persuaded to look at the
> problems.
I have no such problem letting anyone debug Sage on Solaris, but the
time has not come yet since right now I need to fix some build issue
and about three or four known bugs before Sage becomes usable to
debug. The problems are:
* multimodular matrix matrix multiply broken
* numpy 1.0.4 borken, numpy 1.1.0 fixes the issue
* pexpect Singular hangs
* factory from Singular segfaults
All of the above are things that an outsider is unlikely to solve
quickly and I have told the right people off-list about the problem.
There are certainly issues that I would happy to have solved:
* sympow returns wrong results on Sparc
* sympow does not build with gcc on x86 or x86-64, build with cc it
goes into infinite loops
* cvxopt does not build with gcc on x86, x86-64 or sparc due to
complex.h issues
If you get anybody willing to fix those issues let me know and I can
provide detailed problem reports. All of the above are independent of
Sage.
> Casper Dik for example, who works for Sun and hangs out on
> comp.unix.solaris a lot, sorted out a Mathematica issue on Solaris
> that Wolfram Research could not. Mathematica started using tons of CPU
> time on Solaris 10 on some machines, but not on others, despite it
> worked on Solaris 9 fine. Basically Sun had changed a minimum timeout
> value from 1 ms to 1 us in Solaris 10, and WRI were using the minimum
> for something. On slower machines a particular task would not complete
> in 1 us, so would time out and be done again. The result was
> Mathematica would peg the CPU usage after computing something as
> simple as 1+1. Casper wrote me a shared library, which used the old
> timeout. The library was then pre-loaded with LD_PRELOAD_64, so
> Mathematica see that code, rather than the normal Solaris version.
>
> It was with the help from someone on comp.unix.solaris that a solution
> to the Mathematica on Solaris x86 with an Intel CPU was found.
>
> Then I can think of the problem with GPIB drivers for the National
> Instruments GPIB board, which would not work in Solaris 10, despite
> working on Solaris 2.6 to 9. Casper Dik sorted that out, despite
> National Instruments being totally stuck. It turned out National
> Instruments had used the name 'ib' for the GPIB driver. Then in
> Solaris 10, Sun used a name 'ib' for the Infiniband driver. Needless
> to say, two drivers of the same name did not work. Casper suggested I
> removed Infiniband support since I had no need for it, then the GPIB
> board worked.
I am sure there are a lot of competent people around at Sun and in the
news groups, but getting them up to speed on Sage will take longer
than for us to fix the problems. Once the toolchain issues are sorted
out and the above four bugs are fixed I am more than happy to throw a
development version of Sage out there to the Solaris community.
> I know a few regular users of comp.unix.solaris that use Mathematica
> and/or MATLAB on Solaris. There are also a few people keen for
> Mathworks to port MATLAB to Solaris x86 (it runs on SPARC).
Ok.
> > > You could actually beat Wolfram Research to a Computer Algebra System
> > > on Solaris x86 on Intel, as Wolfram's Mathematica only runs on ADM
> > > CPUs, not Intel ones if the OS is Solaris x86. Netiher Maple or MATLAB
> > > run on Solaris x86.
>
> > Yeah, that is strangely odd. Any reason why they would do so? 3DNOW
> > cannot be the reason since MMA and Maple do run of plenty of Intel
> > CPUs with those other OSes ;)
>
> The error message says its a lack of hardware support for AMD_3DNOW:
>
> ld.so.1: MathKernel: fatal:
> /usr/local/Wolfram/Mathematica/6.0/SystemFiles/Libraries/Solaris-
> x86-64/libsunperf.so.1:
> hardware capability unsupported: 0x100 [ AMD_3DNow ]
>
> Running 'file' on the library indicates its a 64-bit library neededing
> AMD_3DNOW.
This is pathetic to say the least. I am curious now that Sun also
ships Intel boxen if they will fix it.
> Running
>
> $ /usr/bin/isalist
> amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86
>
> on my laptop shows the instructions my CPU supports - as you can see
> it lacks AMD_3DNOW. If you was to run that command on a modern AMD
> CPU, it should reports AMD_3DNOW in that list. (I can't be bothered to
> fire up my AMD Solaris x86 box to find out, but I believe that is
> so).
>
> Hence I'm pretty sure the Mathematica issue is related to AMD_3DNOW.
> That information was passed to Wolfram back last year, but so far they
> have not resolved the issue. All they need do is to ship updated
> libraries!!
>
> > Sure, I got sidetracked doing other things the last day, but now I am
> > back on the case again.
>
> Good.
>
> > > It's great to see a Solaris port progress. At a later date, you could
> > > try getting Sage on the OpenSolaris DVD images. Sum might well do
> > > that.
>
> > Some Sun fellow contacted the group a while back, but after contacting
> > him off list we never heard back. Maybe it is time to ping him again.
>
> There are several "live DVD" versions of OpenSolaris around. Pretty
> much anyone can produce one of those, so anyone producing one could be
> asked to add Sage once you have it fully debugged. Not now of course.
>
> More useful, from an advertising point of view would be to get Sun to
> add Sage to the Solaris Express DVD. There is noting remotely similar
> on there now. People using Solaris tend to be technically savvy, so it
> might be an application that would be welcome. However, I do know that
> Sun have spent a lot of time working with Wolfram Research on
> Mathematica. At one point, the Mathematica record was held on a Sun.
> So there might be some reluctance in Sun to include free software in
> direct competition to that they are paid to work on. That said, a lot
> of Sun employees would not care too hoots about that, so it might
> never be considered.
Yeah, I would be glad if this worked out. But packaging for Solaris is
on the to do list, but will probably take a while.
> BTW, I think it would be useful if Sage reported that the Solaris
> build was in an early stage of development, and so is not considered
> stable. It could prevent anyone getting the wrong impression if they
> happen to find the binary somehow.
>
> Something like the following should work on any Unix/Linux system,
> although I've tested only on Solaris x86 and SPARC.
>
> #include <sys/utsname.h>
> #include <stdio.h>
> #include <string.h>
>
> int main() {
> struct utsname machine_data;
> uname(&machine_data);
> if(strcmp("SunOS",machine_data.sysname) == 0) {
> fprintf(stderr,"WARNING - The Solaris port of Sage is an an
> early stage, and has several severe bugs.\n");
> }
>
> }
It is easier to stick it into the banner, I have some code to do that.
> Cheers,
>
> Dave
Thanks for your feedback.
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
