Speaking of Matlab, I was able to get version r2008a (most recent
version) working in a linux-2.6 zone using the CentOS 5 distribution.
I then installed RPyC 3.00 RC1 ( http://rpyc.wikispaces.com/ ) in both
the lx zone's copy of sage and in the native solaris sage
installation. I started up the RPyC server (which could be turned
into a daemon) in the lx zone:
sage: load rpyc_classic_server.sage # this is one of the server
scripts that came with RPyC, renamed to a ".sage" file
In the solaris client:
sage: import rpyc
c = rpyc.classic.connect("192.168.5.10") # 192.168.5.10 is the ip of
the linux zone
sage: c.modules.__main__.matlab('3+3')
6
Though I suppose this has some minimal use on its own as being a way
to call proprietary software not available natively on solaris while
still using native applications from sage (OpenGL visualization comes
to mind), I think a more common benefit would be in having a solaris
zone that is used to house a sage notebook server while not having to
sacrifice the ability to call proprietary software (from a lx zone).
Once I move in to my new apartment and have access to my sever again I
will try it out ... it doesn't look like it will be long before the
solaris port is adequate ;)
On Jul 16, 11:17 am, mabshoff <[EMAIL PROTECTED]> wrote:
> 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 onSolaris, 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 onSolarisbeing
> 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 hasSolaris10, 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 fromSolarisusers who
> > > > do not subscribe here, but I think it would be premature to advertise
> > > > a binary inSolarisnewsgroups. 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
> > > >Solarisforums.
>
> > > Sure, this is way too early. I would want to do that once Sage builds
> > > actually pass doctest at least on theSolarisboxen 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 debuggingSolaris
> > 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 onSolaris, 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.solarisa lot, sorted out a Mathematica issue onSolaris
> > that Wolfram Research could not. Mathematica started using tons of CPU
> > time onSolaris10 on some machines, but not on others, despite it
> > worked onSolaris9 fine. Basically Sun had changed a minimum timeout
> > value from 1 ms to 1 us inSolaris10, 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 normalSolarisversion.
>
> > It was with the help from someone on comp.unix.solaristhat a solution
> > to the Mathematica onSolarisx86 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 inSolaris10, despite
> > working onSolaris2.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
> >Solaris10, 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 theSolariscommunity.
>
> > I know a few regular users of comp.unix.solaristhat use Mathematica
> > and/or MATLAB onSolaris. There are also a few people keen for
> > Mathworks to port MATLAB toSolarisx86 (it runs on SPARC).
>
> Ok.
>
>
>
> > > > You could actually beat Wolfram Research to a Computer Algebra System
> > > > onSolarisx86 on Intel, as Wolfram's Mathematica only runs on ADM
> > > > CPUs, not Intel ones if the OS isSolarisx86. Netiher Maple or MATLAB
> > > > run onSolarisx86.
>
> > > 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 AMDSolarisx86 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 aSolarisport 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 theSolarisExpress DVD. There is noting remotely similar
> > on there now. People usingSolaristend 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 forSolarisis
> on the to do list, but will probably take a while.
>
> > BTW, I think it would be useful if Sage reported that theSolaris
> > build was in an early stage of development, and so is not
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
