Re: [sage-support] Plotting in Julia notebook in Cloud.Sagemath.com
On 27 May 2016 at 17:52, William Stein wrote: > On Fri, May 27, 2016 at 6:32 AM, wrote: > > Hi, > > > > apologies if this question is better asked somewhere else, but I'm not > > aware of any support mailing list specific to Cloud.Sagemath. > > > > Go to https://cloud.sagemath.com/help and click on the link "support > mailing list", which links to > >https://groups.google.com/forum/?fromgroups#!forum/sage-cloud > > That said, I'm cc'ing Bill Hart, since he uses Julia a lot and has > used iJulia. I don't know if he has used it in SMC though. > > > I just started trying out a Julia notebook in Cloud.Sagemath.com, but I > > don't seem to be able to use any of the usual packages for plotting > > (Winston, PyPlot, etc.). > I haven't used the plotting libraries from IJulia. It's my understanding they should work, but you would have to install them each time you log in I think. The alternative is if William installs them systemwide as he currently installs Nemo, say. But that assumes they work locally first, of course. I just don't know which ones should work with IJulia. That is something you could ask directly at the julia-users Google group. Bill. > > > > Do you know, in general, of any document explaining which packages are > > available for the different kernels? Is it possible to include new > > packages per notebook? Specifically, which plotting packages could I use > > and how? > > > > Thanks, > > -- > > Ángel de Vicente > > http://www.iac.es/galeria/angelv/ > > > > -- > > You received this message because you are subscribed to the Google > Groups "sage-support" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to sage-support+unsubscr...@googlegroups.com. > > To post to this group, send email to sage-support@googlegroups.com. > > Visit this group at https://groups.google.com/group/sage-support. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > William (http://wstein.org) > -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
[sage-support] Re: quiery about polynomial rings
On 19 Aug, 18:52, kcrisman wrote: > > I wonder if there is a reason for this. Do the additions break the > > lexeme or is there a syntactic ambiguity... > > William or Mike H. would know for sure, but I believe the additions > are all invalid Python which happen to be convenient mathematics :) ...which is bizarre, because I remember when this polynomial "sugar" was being discussed that various suggestions were rejected precisely *because* they weren't valid python. Which sequence of events convinced me that what was settled on *was* valid. Oh wells. > > > > > > > > And using the preparse() command to find out how Sage > > > "really" constructs the ring will still be helpful for creating a Sage > > > library Python file. > > > Hmm. So sage library files are all in python. This is going to be > > difficult to explain > > > So presumably when constructing polynomials you need to use ** instead > > of ^, but it does *not* mean you can't use all the nice _functions_ > > Sage provides for handling polynomials. That is not what is meant by > > Sage only accepts pure python from a .py file (which Sage library > > files are). It merely means that some nice syntactical sugar, such as > > R. and ZZ[] and ^ aren't available in .py files. You can still > > use those things, you just have to type them in a slightly different > > way that is "valid python" (though python.exe wouldn't accept them > > without quite a bit of setting up.) > > Yup, I guess. I don't know anything about python.exe - we're talking > now about files that would be included in the Sage library. > > > > from sage.rings.polynomial.polynomial_ring_constructor import > > > PolynomialRing > > > Well, this is an example of where the source doesn't seem to import > > anything. > > ? seems clear to me, but maybe I'm being vague. > > > It's also not really clear how you divined that you should > > import PolynomialRing. My guess would have been: > > > from sage.rings.polynomial import polynomial_ring_constructor > > No, because the thing in the preparse output used PolynomialRing, > which then we learned from ? lived in polynomial_ring_constructor. > Though the actual question from that standpoint has already been > answered, I hope. > > - kcrisman -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Re: quiery about polynomial rings
On 19 Aug, 18:19, kcrisman wrote:
> On Aug 19, 12:48 pm, Bill Hart wrote:
>
> > I'm not sure if that is what he means. He is using Sage to load
> > the .py file, not python.
>
> Exactly. Sage interprets .py files as pure Python, I believe. But it
> turns .sage files into .py files which have already been 'preparsed'.
> A .py file is just Python, even in Sage.
Ah, so that is the important missing piece. He should be using a .sage
file, not a .py file. I didn't know that.
So in some respects Sage is like SML in that the language it accepts
at the interpreter is subtly different from the one it accepts from a
file. Fair enough. Though slightly confusing.
I wonder if there is a reason for this. Do the additions break the
lexeme or is there a syntactic ambiguity...
>
> > So he wants to know which modules to import to be able to use
> > multivariate polynomials in Sage from a (sage, not python) .py file.
> > He is trying to develop for Sage, not just use it from the sage
> > prompt.
>
> For making a new file for the Sage library, to use a given object, I
> would do
>
> sage: Object?
>
> and see where it lives; one should be able to then do (in the .py
> file)
>
> from sage.rings.whatever import some_object
>
> and it ought to work.
Ok. That's what I thought.
>
> However, since he talked about 'loading' it sounded more like the
> former issue.
You might be right, since he asked me first and I didn't know about
the above.
> And using the preparse() command to find out how Sage
> "really" constructs the ring will still be helpful for creating a Sage
> library Python file.
>
Hmm. So sage library files are all in python. This is going to be
difficult to explain
So presumably when constructing polynomials you need to use ** instead
of ^, but it does *not* mean you can't use all the nice _functions_
Sage provides for handling polynomials. That is not what is meant by
Sage only accepts pure python from a .py file (which Sage library
files are). It merely means that some nice syntactical sugar, such as
R. and ZZ[] and ^ aren't available in .py files. You can still
use those things, you just have to type them in a slightly different
way that is "valid python" (though python.exe wouldn't accept them
without quite a bit of setting up.)
Urgghh, this is a bit hard to explain.
> sage: preparse('R.=PolynomialRing(GF(5),2,"z")')
> 'R = PolynomialRing(GF(Integer(5)),Integer(2),"z", names=(\'z1\',
> \'z2\',)); (z1, z2,) = R._first_ngens(2)'
> sage: PolynomialRing?
> String Form:
> Namespace: Interactive
> File: /Users/karl-dietercrisman/Downloads/sage-4.5.3.alpha1/
> local/lib/python2.6/site-packages/sage/rings/polynomial/
> polynomial_ring_constructor.py
> Definition: PolynomialRing(base_ring, arg1=None, arg2=None,
> sparse=False, order='degrevlex', names=None, name=None,
> implementation=None)
> Docstring:
> Return the globally unique univariate or multivariate
> polynomial
> ring with given properties and variable name or names.
>
> There are four ways to call the polynomial ring constructor:
>
>
>
> so perhaps (I'm not totally familiar with this part of the code)
>
> from sage.rings.polynomial.polynomial_ring_constructor import
> PolynomialRing
Well, this is an example of where the source doesn't seem to import
anything. It's also not really clear how you divined that you should
import PolynomialRing. My guess would have been:
from sage.rings.polynomial import polynomial_ring_constructor
But I am totally guessing. Maybe someone more familiar with the
developer documentation can point to where this is discussed and I can
get Andrew to read up on it (and tell me too).
>
> could work.
>
> Good luck!
>
> - kcrisman
Thanks for the help.
Bill.
--
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org
[sage-support] Re: quiery about polynomial rings
I'm not sure if that is what he means. He is using Sage to load
the .py file, not python.
So he wants to know which modules to import to be able to use
multivariate polynomials in Sage from a (sage, not python) .py file.
He is trying to develop for Sage, not just use it from the sage
prompt.
My answer was to look at the examples in the source for the various
objects he uses, as they import anything that is needed to run those
examples.
Some of the Sage docs he found online said that Sage implements
multivariate polys using PolyDicts, so he was originally importing
PolyDict and that wasn't helping. But looking at the source, it seems
that singular is actually used. I don't know what one needs to
"import" to use singular as the examples for that don't import
anything, though I seemed to be able to guess something that was at
least syntactically acceptable.
Anyhow, I wasn't able to help him with his question. Apparently
importing all these things didn't help unless he is doing
something else wrong.
Bill.
On 19 Aug, 17:00, kcrisman wrote:
> Dear Andrew,
>
> It turns out that
>
> R.=PolynomialRing(GF(5),2,"z")
>
> is not valid Python, I believe; Sage has a 'preparser' that helps make
> more things possible. I believe if you do
>
> sage: preparse('command')
>
> you will see the actual Python that gets done. One the other hand,
> you could just name your .py file to .sage and you wouldn't have to
> worry about this, and can still load it, etc. (this is what I do).
>
> Hope this helps!
>
> - kcrisman
>
> On Aug 19, 10:44 am, andrew ewart wrote:
>
>
>
> > If i input
> > R.=PolynomialRing(GF(5),2,"z")
> > direclty to sage it accepts it as a polynomial ring
> > But if i try to save it as part of a .py file and then load it from
> > there into sage
> > ie sage my.py it gives me a syntax error
> > what module am i missing and so what command do i need to make sage
> > recognise it in the .py file
--
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org
[sage-support] Re: MPIR 1.3.0 released (at last)
I found another Ultrasparc2 which is set up correctly (same linux), and the MPIR C++ tests pass no problems. So this confirms my belief that gcc54 was just set up wrongly. I'm going to close the longstanding ticket we have open for that, and I'll just build on the other machine I have found, in future. Bill. 2010/1/28 Bill Hart : > Hi all, > > it is with pleasure that we (finally) officially release MPIR 1.3.0. > It is available at our website http://www.mpir.org/ > > Please note the following important things: > > * I have been unable to get any tests to pass on ultrasparc2 machines, > including t2 (solaris) and gcc54 (linux). I am confident there are not > bugs in the ultrasparc assembly code (as we haven't changed it and it > worked before). Thus if someone can tell me how to get MPIR to behave > on these machines "out-of-the-box" I will make the necessary changes > to MPIR. In the mean time, we have to officially consider MPIR broken > on such machines (or the machines we test on to be broken). Note this > is *not* a Solaris issue as MPIR builds just fine on Solaris. > > * It is no longer necessary to issue make install gmp-compat, however > it is still necessary to use --enable-gmpcompat with configure if you > want a gmp.h and libgmp > > * Many users believe that mpz_nextprime returns a prime. In fact it is > only guaranteed to define a number which is with high probability > prime. For this reason the function has been deprecated. Please use > the new mpz_next_likely_prime in its place. > > * Most of the random functions in MPIR which require global random > state have been deprecated and new functions provided which have local > state. This allows code using MPIR random functions to be threadsafe. > > * The functions mpz_div_2exp and mpz_div_ui have been removed from > MPIR. These were deprecated many years ago, but many people have > continued to use them. > > A quick workaround is to use the following defines: > > #ifndef mpz_div_2exp > #define mpz_div_2exp mpz_tdiv_q_2exp > #endif > > #ifndef mpz_div_ui > #define mpz_div_ui mpz_tdiv_q_ui > #endif > > However, the better fix is to actually replace all occurrences in > code. (Users of FLINT will have to wait a couple of days until I issue > an update to FLINT, in particular the quadratic sieve, which still > uses the old functions - in the mean time, just add the above defines > to flint.h). > > Bill. > -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
Re: [sage-support] Re: [mpir-devel] Re: [sage-devel] MPIR 1.3.0 released (at last)
Ah, got it. LD_LIBRARY_PATH_64 needs to also contain /home/wbhart/mpir-1.3.0/.libs. Basically if LD_LIBRARY_PATH_64 is not specified at all, i.e. left blank, the linker uses whatever is in LD_LIBRARY_PATH. Otherwise it uses LD_LIBRARY_PATH_64 exclusively, which means that *all* 64 bit library paths must be in LD_LIBRARY_PATH_64. So, in order to make MPIR work on t2, we'd need LD_LIBRARY_PATH_64 to be set globally for users *and* we'd need libtool to recognise that it needs to set LD_LIBRARY_PATH_64. Unfortunately libtool doesn't do this automatically. So this is seems to be a bug in the version of libtool we use. Another solution is to set LD_LIBRARY_PATH_64 to include $LD_LIBRARY_PATH. This actually works because the substitution is done live by the shell. In other words, if LD_LIBRARY_PATH_64 is set to /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9:$LD_LIBRARY_PATH for all users of t2 globally, I believe MPIR will work just fine on that machine. Bill. 2010/1/29 Bill Hart : > OK, the problem is as follows. For very straightforward C programs, no > problems occur on t2 because the compiler emits inline code for > everything. However, once the program becomes too complicated for it > to do this, it uses libgcc: > > http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html > > The problem is, when the compiler compiles such a program, the linker > does not know where to find libgcc on the machine. It needs to know > that it is in: > > /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 > > However, this is not in /etc/ld.so.conf, which does not exist on > Solaris machines, nor is it in LD_LIBRARY_PATH. > > Why it won't work with this in LD_LIBRARY_PATH_64 I do not know. > > But either way, this problem is not something we can work around in > MPIR, that I know of. It's just that MPIR uses some very complex > arithmetic expressions for which gcc is unable to emit inline > assembly. Even writing a basic test case that exhibits this failure > would be difficult. > > I've no idea what the solution to the problem is. Back to the sparc > expert for this one! > > Bill. > > 2010/1/28 Bill Hart : >> One sensible solution would seem to be to set >> LD_LIBRARY_PATH_64=/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 on t2, >> but this actually doesn't seem to work. I'm not sure why. >> >> However it seems that one can just add >> /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 to the LD_LIBRARY_PATH (it >> doesn't matter whether at the beginning or end) and this fixes the >> problems on t2. Shouldn't this be done globally for all users? >> >> Bill. >> >> 2010/1/28 Bill Hart : >>> 2010/1/28 Dr. David Kirkby : >>>> Bill Hart wrote: >>>>> >>>>> 2010/1/28 Dr. David Kirkby : >>>>>> >>>>>> The problem is that 64-bit libraries should never be in /usr/local/lib. >>>>>> Instead they should be in /usr/local/lib/sparcv9. >>>>> >>>>> I am not installing MPIR on these machines, as I do not have root >>>>> access on either. Thus whatever is in /usr/local/lib is not my >>>>> responsibility. >>>> >>>> But I was using a compiler installed in /usr/local. When that compiler was >>>> installed, by default it uses >>>> >>>> /usr/local/man - man pages >>>> /usr/local/bin - binaries >>>> /usr/local/lib - 32-bit libraries >>>> /usr/local/lib/sparcv9 - 64-bit libraries. >>>> >>>> To answer your other question about 't2'. Agreed it has no >>>> /usr/local/lib/sparcv9, but gcc is not installed in /usr/local. >>>> >>>> Instead gcc is installed under /usr/local/gcc-4.4.1-sun-linker/ >>>> >>>> So the 32-bit libraries will be under /usr/local/gcc-4.4.1-sun-linker/lib >>>> and the 64-bit libraries under /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9. >>> >>> And indeed if I add this to LD_LIBRARY_PATH, MPIR passes its tests. >>> >>> Is this a standard directory that libtool should know to look in? >>> >>>> >>>> $ ls /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 >>>> libgcc_s.so libgomp.so.1 libssp.so.0.0.0 >>>> libgcc_s.so.1 libgomp.so.1.0.0 libstdc++.a >>>> libgfortran.a libgomp.spec libstdc++.la >>>> libgfortran.la libiberty.a libstdc++.so >>>> libgfortran.so libssp.a libstdc++.so.6 >>>> libgfortran.so.3 libssp.la libstdc++.so.6.0.12 >>>> libgfortran.so
Re: [sage-support] Re: [mpir-devel] Re: [sage-devel] MPIR 1.3.0 released (at last)
OK, the problem is as follows. For very straightforward C programs, no problems occur on t2 because the compiler emits inline code for everything. However, once the program becomes too complicated for it to do this, it uses libgcc: http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html The problem is, when the compiler compiles such a program, the linker does not know where to find libgcc on the machine. It needs to know that it is in: /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 However, this is not in /etc/ld.so.conf, which does not exist on Solaris machines, nor is it in LD_LIBRARY_PATH. Why it won't work with this in LD_LIBRARY_PATH_64 I do not know. But either way, this problem is not something we can work around in MPIR, that I know of. It's just that MPIR uses some very complex arithmetic expressions for which gcc is unable to emit inline assembly. Even writing a basic test case that exhibits this failure would be difficult. I've no idea what the solution to the problem is. Back to the sparc expert for this one! Bill. 2010/1/28 Bill Hart : > One sensible solution would seem to be to set > LD_LIBRARY_PATH_64=/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 on t2, > but this actually doesn't seem to work. I'm not sure why. > > However it seems that one can just add > /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 to the LD_LIBRARY_PATH (it > doesn't matter whether at the beginning or end) and this fixes the > problems on t2. Shouldn't this be done globally for all users? > > Bill. > > 2010/1/28 Bill Hart : >> 2010/1/28 Dr. David Kirkby : >>> Bill Hart wrote: >>>> >>>> 2010/1/28 Dr. David Kirkby : >>>>> >>>>> The problem is that 64-bit libraries should never be in /usr/local/lib. >>>>> Instead they should be in /usr/local/lib/sparcv9. >>>> >>>> I am not installing MPIR on these machines, as I do not have root >>>> access on either. Thus whatever is in /usr/local/lib is not my >>>> responsibility. >>> >>> But I was using a compiler installed in /usr/local. When that compiler was >>> installed, by default it uses >>> >>> /usr/local/man - man pages >>> /usr/local/bin - binaries >>> /usr/local/lib - 32-bit libraries >>> /usr/local/lib/sparcv9 - 64-bit libraries. >>> >>> To answer your other question about 't2'. Agreed it has no >>> /usr/local/lib/sparcv9, but gcc is not installed in /usr/local. >>> >>> Instead gcc is installed under /usr/local/gcc-4.4.1-sun-linker/ >>> >>> So the 32-bit libraries will be under /usr/local/gcc-4.4.1-sun-linker/lib >>> and the 64-bit libraries under /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9. >> >> And indeed if I add this to LD_LIBRARY_PATH, MPIR passes its tests. >> >> Is this a standard directory that libtool should know to look in? >> >>> >>> $ ls /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 >>> libgcc_s.so libgomp.so.1 libssp.so.0.0.0 >>> libgcc_s.so.1 libgomp.so.1.0.0 libstdc++.a >>> libgfortran.a libgomp.spec libstdc++.la >>> libgfortran.la libiberty.a libstdc++.so >>> libgfortran.so libssp.a libstdc++.so.6 >>> libgfortran.so.3 libssp.la libstdc++.so.6.0.12 >>> libgfortran.so.3.0.0 libssp_nonshared.a libsupc++.a >>> libgomp.a libssp_nonshared.la libsupc++.la >>> libgomp.la libssp.so >>> libgomp.so libssp.so.0 >>> >>>> Libtool builds the MPIR library in a directory in the MPIR source >>>> tree, then links against that. This works on every other architecture >>>> I am aware of. >>> >>> libtool picks the right libraries under many programs in Solaris. I would >>> suggest there is some error in how libtool is being used. I would ask on the >>> libtool mailing list, and see if they can help you. >>> >>> Most platforms do not support both 32 and 64-bit builds, so most platforms >>> do not have to have different directories for 32 and 64-bit libraries. >>> >>> The compiler should know to pick up the correct library. I've no idea why it >>> is not in this case, but I can assure you there are many programs I've built >>> as 64-bit under Solaris on SPARC which use libtool. >> >> It's because LD_LIBRARY_PATH is set incorrectly on t2. >> >>> >>> You said it did not build on UltraSPARC II. I suspect you will find it will >>> not build on any SPARC system.
Re: [sage-support] Re: [mpir-devel] Re: [sage-devel] MPIR 1.3.0 released (at last)
One sensible solution would seem to be to set LD_LIBRARY_PATH_64=/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 on t2, but this actually doesn't seem to work. I'm not sure why. However it seems that one can just add /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 to the LD_LIBRARY_PATH (it doesn't matter whether at the beginning or end) and this fixes the problems on t2. Shouldn't this be done globally for all users? Bill. 2010/1/28 Bill Hart : > 2010/1/28 Dr. David Kirkby : >> Bill Hart wrote: >>> >>> 2010/1/28 Dr. David Kirkby : >>>> >>>> The problem is that 64-bit libraries should never be in /usr/local/lib. >>>> Instead they should be in /usr/local/lib/sparcv9. >>> >>> I am not installing MPIR on these machines, as I do not have root >>> access on either. Thus whatever is in /usr/local/lib is not my >>> responsibility. >> >> But I was using a compiler installed in /usr/local. When that compiler was >> installed, by default it uses >> >> /usr/local/man - man pages >> /usr/local/bin - binaries >> /usr/local/lib - 32-bit libraries >> /usr/local/lib/sparcv9 - 64-bit libraries. >> >> To answer your other question about 't2'. Agreed it has no >> /usr/local/lib/sparcv9, but gcc is not installed in /usr/local. >> >> Instead gcc is installed under /usr/local/gcc-4.4.1-sun-linker/ >> >> So the 32-bit libraries will be under /usr/local/gcc-4.4.1-sun-linker/lib >> and the 64-bit libraries under /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9. > > And indeed if I add this to LD_LIBRARY_PATH, MPIR passes its tests. > > Is this a standard directory that libtool should know to look in? > >> >> $ ls /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 >> libgcc_s.so libgomp.so.1 libssp.so.0.0.0 >> libgcc_s.so.1 libgomp.so.1.0.0 libstdc++.a >> libgfortran.a libgomp.spec libstdc++.la >> libgfortran.la libiberty.a libstdc++.so >> libgfortran.so libssp.a libstdc++.so.6 >> libgfortran.so.3 libssp.la libstdc++.so.6.0.12 >> libgfortran.so.3.0.0 libssp_nonshared.a libsupc++.a >> libgomp.a libssp_nonshared.la libsupc++.la >> libgomp.la libssp.so >> libgomp.so libssp.so.0 >> >>> Libtool builds the MPIR library in a directory in the MPIR source >>> tree, then links against that. This works on every other architecture >>> I am aware of. >> >> libtool picks the right libraries under many programs in Solaris. I would >> suggest there is some error in how libtool is being used. I would ask on the >> libtool mailing list, and see if they can help you. >> >> Most platforms do not support both 32 and 64-bit builds, so most platforms >> do not have to have different directories for 32 and 64-bit libraries. >> >> The compiler should know to pick up the correct library. I've no idea why it >> is not in this case, but I can assure you there are many programs I've built >> as 64-bit under Solaris on SPARC which use libtool. > > It's because LD_LIBRARY_PATH is set incorrectly on t2. > >> >> You said it did not build on UltraSPARC II. I suspect you will find it will >> not build on any SPARC system. > > It does build in the UltraSPARC II. I was only looking at the output > of the C++ tests, and these had always failed on that machine, but > this is due to a library which is completely missing from the machine. > I can't change that as I do not have root access. It has failed for > every version of MPIR. > >> >>> Libtool builds the MPIR library in a directory in the MPIR source >>> tree, then links against that. This works on every other architecture >>> I am aware of. >> >> Loads of packages build in Sage with libtool, and do not have this problem. >> Perhaps there is some mis-configuration of libtool. If the compiler is >> called with the -m64 option, and asked to link against one of its libraries, >> it should automatically know to look in the sparcv9 subdirectory. > > That's probably true, if the sparcv9 directory is in a standard place. > >> However, >> no doubt a mis-configuration of libtool would cause it to look elsewhere. >> >> >>>> So what is happening is that the 64-bit objects are trying to link with >>>> libraries in a directory where the 32-bit libraries should be, and not >>>> where >>>> the 64-bit libraries should be. That will certainly fail. >>> >>> So maybe that
Re: [sage-support] Re: [mpir-devel] Re: [sage-devel] MPIR 1.3.0 released (at last)
2010/1/28 Dr. David Kirkby : > Bill Hart wrote: >> >> 2010/1/28 Dr. David Kirkby : >>> >>> The problem is that 64-bit libraries should never be in /usr/local/lib. >>> Instead they should be in /usr/local/lib/sparcv9. >> >> I am not installing MPIR on these machines, as I do not have root >> access on either. Thus whatever is in /usr/local/lib is not my >> responsibility. > > But I was using a compiler installed in /usr/local. When that compiler was > installed, by default it uses > > /usr/local/man - man pages > /usr/local/bin - binaries > /usr/local/lib - 32-bit libraries > /usr/local/lib/sparcv9 - 64-bit libraries. > > To answer your other question about 't2'. Agreed it has no > /usr/local/lib/sparcv9, but gcc is not installed in /usr/local. > > Instead gcc is installed under /usr/local/gcc-4.4.1-sun-linker/ > > So the 32-bit libraries will be under /usr/local/gcc-4.4.1-sun-linker/lib > and the 64-bit libraries under /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9. And indeed if I add this to LD_LIBRARY_PATH, MPIR passes its tests. Is this a standard directory that libtool should know to look in? > > $ ls /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 > libgcc_s.so libgomp.so.1 libssp.so.0.0.0 > libgcc_s.so.1 libgomp.so.1.0.0 libstdc++.a > libgfortran.a libgomp.spec libstdc++.la > libgfortran.la libiberty.a libstdc++.so > libgfortran.so libssp.a libstdc++.so.6 > libgfortran.so.3 libssp.la libstdc++.so.6.0.12 > libgfortran.so.3.0.0 libssp_nonshared.a libsupc++.a > libgomp.a libssp_nonshared.la libsupc++.la > libgomp.la libssp.so > libgomp.so libssp.so.0 > >> Libtool builds the MPIR library in a directory in the MPIR source >> tree, then links against that. This works on every other architecture >> I am aware of. > > libtool picks the right libraries under many programs in Solaris. I would > suggest there is some error in how libtool is being used. I would ask on the > libtool mailing list, and see if they can help you. > > Most platforms do not support both 32 and 64-bit builds, so most platforms > do not have to have different directories for 32 and 64-bit libraries. > > The compiler should know to pick up the correct library. I've no idea why it > is not in this case, but I can assure you there are many programs I've built > as 64-bit under Solaris on SPARC which use libtool. It's because LD_LIBRARY_PATH is set incorrectly on t2. > > You said it did not build on UltraSPARC II. I suspect you will find it will > not build on any SPARC system. It does build in the UltraSPARC II. I was only looking at the output of the C++ tests, and these had always failed on that machine, but this is due to a library which is completely missing from the machine. I can't change that as I do not have root access. It has failed for every version of MPIR. > >> Libtool builds the MPIR library in a directory in the MPIR source >> tree, then links against that. This works on every other architecture >> I am aware of. > > Loads of packages build in Sage with libtool, and do not have this problem. > Perhaps there is some mis-configuration of libtool. If the compiler is > called with the -m64 option, and asked to link against one of its libraries, > it should automatically know to look in the sparcv9 subdirectory. That's probably true, if the sparcv9 directory is in a standard place. > However, > no doubt a mis-configuration of libtool would cause it to look elsewhere. > > >>> So what is happening is that the 64-bit objects are trying to link with >>> libraries in a directory where the 32-bit libraries should be, and not >>> where >>> the 64-bit libraries should be. That will certainly fail. >> >> So maybe that has nothing to do with MPIR. > > I think you will find it is. Otherwise this problem would be seen whenever > 64-bit programs are installed on Solaris SPARC. It works fine on SkyNet/mark which is a Solaris SPARC machine. Of course the LD_LIBRARY_PATH needs to be set correctly there too. > > You may not have come across this problem on other platforms, as most other > platforms do not support the use of both 32 and 64-bit objects. > > I would add the same arises with Solaris on x86/x64 processors. But in that > case, the libraries are stored under 'amd64' rather than the 'sparcv9' > subdirectories. Why this is working on Solaris x86/x64 (i.e. my Intel Xeon) > and not on any SPARC I've tried, is something best asked on the autolib > mailing list. > > Ralf Wildenhues,
[sage-support] Re: [mpir-devel] Re: [sage-devel] MPIR 1.3.0 released (at last)
OK, on gcc54 only the C++ tests fail. But they always did. There is
actually a library missing from the machine which is needed to run
binaries compiled by the C++ compiler. All the C test binaries pass on
gcc54.
So the only issue is actually on t2. Basically I think there is a
whole pile of wrong stuff in LD_LIBRARY_PATH. By default when I log
into that machine it is set to:
/usr/local/gcc-4.2.4-sun-linker/lib:/usr/local/lib
So not much wonder 64 bit binaries don't work. Basically my guess is
this is not an MPIR problem, but a problem with the way the machine is
set up. But I could easily turn out to be wrong about this.
Bill.
2010/1/28 Bill Hart :
> On t2 all the tests fail, complaining of the same issue. If I actually
> go into the tests directory and run one of the test scripts directly,
> here is what it does:
>
> ./t-modlinv
> ld.so.1: t-modlinv: fatal: libmpir.so.8: open failed: No such file or
> directory
> Killed
>
> So let's see what the script does:
>
> program='t-modlinv'
> progdir="$thisdir/.libs"
>
>
> if test -f "$progdir/$program"; then
> # Add our own library path to LD_LIBRARY_PATH
> LD_LIBRARY_PATH="/home/wbhart/mpir-1.3.0/.libs:$LD_LIBRARY_PATH"
>
> # Some systems cannot cope with colon-terminated LD_LIBRARY_PATH
> # The second colon is a workaround for a bug in BeOS R4 sed
> LD_LIBRARY_PATH=`$echo "X$LD_LIBRARY_PATH" | $Xsed -e 's/::*$//'`
>
> export LD_LIBRARY_PATH
>
> In fact if I do:
>
> ldd /home/wbhart/mpir-1.3.0/tests/.libs/t-modlinv
> libmpir.so.8 => (file not found)
> libc.so.1 => /usr/lib/sparcv9//libc.so.1
> libm.so.2 => /usr/lib/sparcv9//libm.so.2
> /platform/SUNW,T5240/lib/sparcv9/libc_psr.so.1
>
> So it can't find libmpir.so.8. But I don't see why.
>
> echo $LD_LIBRARY_PATH
> /usr/lib/sparcv9:/home/wbhart/mpir-1.3.0/.libs
>
> But:
>
> wbh...@t2:~/mpir-1.3.0/tests$ ls ../.libs
>
> compat.o libmpir.so.8 randbui.o rands.o
> dummy.o libmpir.so.8.0.0 randclr.o randsd.o
>
>
> So it's there.
>
> Do sparc machines just ignore LD_LIBRARY_PATH or something?
>
> Bill.
>
> 2010/1/28 Bill Hart :
>> 2010/1/28 Dr. David Kirkby :
>>> Bill Hart wrote:
>>>>
>>>> Hi all,
>>>>
>>>> it is with pleasure that we (finally) officially release MPIR 1.3.0.
>>>> It is available at our website http://www.mpir.org/
>>>>
>>>> Please note the following important things:
>>>>
>>>> * I have been unable to get any tests to pass on ultrasparc2 machines,
>>>
>>> I've just tried on an UltraSPARC III+, and no tests pass. The problem is
>>> quite easy to see, though don't ask me how you solve it, as I don't know how
>>> to use 'libtool'.
>>>
>>> Assuming gcc is installed under /usr/local (for simplicity), then the
>>> object files are built 64-bit, but then a message similar to this is shown:
>>>
>>> ld.so.1: t-hightomask: fatal: /usr/local/lib/libgcc_s.so.1: wrong ELF class:
>>> ELFCLASS32
>>> /bin/bash: line 1: 22883 Killed ${dir}$tst
>>>
>>> The problem is that 64-bit libraries should never be in /usr/local/lib.
>>> Instead they should be in /usr/local/lib/sparcv9.
>>
>> I am not installing MPIR on these machines, as I do not have root
>> access on either. Thus whatever is in /usr/local/lib is not my
>> responsibility.
>>
>> Libtool builds the MPIR library in a directory in the MPIR source
>> tree, then links against that. This works on every other architecture
>> I am aware of.
>>
>>>
>>> If we run 'ldd' on some files in /usr/lib, we see they are all 32-bit.
>>>
>>> $ file /usr/lib/*
>>> /usr/lib/libsldap.so: ELF 32-bit MSB dynamic lib SPARC Version 1,
>>> dynamically linked, not stripped, no debugging information available
>>> /usr/lib/libsldap.so.1: ELF 32-bit MSB dynamic lib SPARC Version 1,
>>> dynamically linked, not stripped, no debugging information available
>>>
>>> But if we do so on /usr/lib/sparcv9, then we see they are 64-bit.
>>>
>>> $ file /usr/lib/sparcv9/*
>>> /usr/lib/sparcv9/libST.so: ELF 64-bit MSB dynamic lib SPARCV9 Version
>>> 1, dynamically linked, not stripped
>>> /usr/lib/sparcv9/libST.so.1: ELF 64-bit MSB dynamic lib SPARCV9 Version
>>> 1, dynamically linked, not stripped
>>> /usr/lib/sparcv9/libUil.so:
[sage-support] Re: [mpir-devel] Re: [sage-devel] MPIR 1.3.0 released (at last)
As far as I know that is only necessary on OS X. Anyhow, I tried it just in case, and no change. Thanks for the suggestion though. Bill. 2010/1/28 Craig Citro : >> So it can't find libmpir.so.8. But I don't see why. >> >> echo $LD_LIBRARY_PATH >> /usr/lib/sparcv9:/home/wbhart/mpir-1.3.0/.libs >> > > Total random guess: could it be that you need this to be in your > DYLD_LIBRARY_PATH, too? > > -cc > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to mpir-de...@googlegroups.com. > To unsubscribe from this group, send email to > mpir-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Re: MPIR 1.3.0 released (at last)
I forgot to mention, the long deprecated function mpz_random has also finally been removed. Bill. 2010/1/28 Bill Hart : > Hi all, > > it is with pleasure that we (finally) officially release MPIR 1.3.0. > It is available at our website http://www.mpir.org/ > > Please note the following important things: > > * I have been unable to get any tests to pass on ultrasparc2 machines, > including t2 (solaris) and gcc54 (linux). I am confident there are not > bugs in the ultrasparc assembly code (as we haven't changed it and it > worked before). Thus if someone can tell me how to get MPIR to behave > on these machines "out-of-the-box" I will make the necessary changes > to MPIR. In the mean time, we have to officially consider MPIR broken > on such machines (or the machines we test on to be broken). Note this > is *not* a Solaris issue as MPIR builds just fine on Solaris. > > * It is no longer necessary to issue make install gmp-compat, however > it is still necessary to use --enable-gmpcompat with configure if you > want a gmp.h and libgmp > > * Many users believe that mpz_nextprime returns a prime. In fact it is > only guaranteed to define a number which is with high probability > prime. For this reason the function has been deprecated. Please use > the new mpz_next_likely_prime in its place. > > * Most of the random functions in MPIR which require global random > state have been deprecated and new functions provided which have local > state. This allows code using MPIR random functions to be threadsafe. > > * The functions mpz_div_2exp and mpz_div_ui have been removed from > MPIR. These were deprecated many years ago, but many people have > continued to use them. > > A quick workaround is to use the following defines: > > #ifndef mpz_div_2exp > #define mpz_div_2exp mpz_tdiv_q_2exp > #endif > > #ifndef mpz_div_ui > #define mpz_div_ui mpz_tdiv_q_ui > #endif > > However, the better fix is to actually replace all occurrences in > code. (Users of FLINT will have to wait a couple of days until I issue > an update to FLINT, in particular the quadratic sieve, which still > uses the old functions - in the mean time, just add the above defines > to flint.h). > > Bill. > -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Re: [mpir-devel] Re: [sage-devel] MPIR 1.3.0 released (at last)
On t2 all the tests fail, complaining of the same issue. If I actually
go into the tests directory and run one of the test scripts directly,
here is what it does:
./t-modlinv
ld.so.1: t-modlinv: fatal: libmpir.so.8: open failed: No such file or directory
Killed
So let's see what the script does:
program='t-modlinv'
progdir="$thisdir/.libs"
if test -f "$progdir/$program"; then
# Add our own library path to LD_LIBRARY_PATH
LD_LIBRARY_PATH="/home/wbhart/mpir-1.3.0/.libs:$LD_LIBRARY_PATH"
# Some systems cannot cope with colon-terminated LD_LIBRARY_PATH
# The second colon is a workaround for a bug in BeOS R4 sed
LD_LIBRARY_PATH=`$echo "X$LD_LIBRARY_PATH" | $Xsed -e 's/::*$//'`
export LD_LIBRARY_PATH
In fact if I do:
ldd /home/wbhart/mpir-1.3.0/tests/.libs/t-modlinv
libmpir.so.8 => (file not found)
libc.so.1 => /usr/lib/sparcv9//libc.so.1
libm.so.2 => /usr/lib/sparcv9//libm.so.2
/platform/SUNW,T5240/lib/sparcv9/libc_psr.so.1
So it can't find libmpir.so.8. But I don't see why.
echo $LD_LIBRARY_PATH
/usr/lib/sparcv9:/home/wbhart/mpir-1.3.0/.libs
But:
wbh...@t2:~/mpir-1.3.0/tests$ ls ../.libs
compat.o libmpir.so.8 randbui.o rands.o
dummy.o libmpir.so.8.0.0 randclr.o randsd.o
So it's there.
Do sparc machines just ignore LD_LIBRARY_PATH or something?
Bill.
2010/1/28 Bill Hart :
> 2010/1/28 Dr. David Kirkby :
>> Bill Hart wrote:
>>>
>>> Hi all,
>>>
>>> it is with pleasure that we (finally) officially release MPIR 1.3.0.
>>> It is available at our website http://www.mpir.org/
>>>
>>> Please note the following important things:
>>>
>>> * I have been unable to get any tests to pass on ultrasparc2 machines,
>>
>> I've just tried on an UltraSPARC III+, and no tests pass. The problem is
>> quite easy to see, though don't ask me how you solve it, as I don't know how
>> to use 'libtool'.
>>
>> Assuming gcc is installed under /usr/local (for simplicity), then the
>> object files are built 64-bit, but then a message similar to this is shown:
>>
>> ld.so.1: t-hightomask: fatal: /usr/local/lib/libgcc_s.so.1: wrong ELF class:
>> ELFCLASS32
>> /bin/bash: line 1: 22883 Killed ${dir}$tst
>>
>> The problem is that 64-bit libraries should never be in /usr/local/lib.
>> Instead they should be in /usr/local/lib/sparcv9.
>
> I am not installing MPIR on these machines, as I do not have root
> access on either. Thus whatever is in /usr/local/lib is not my
> responsibility.
>
> Libtool builds the MPIR library in a directory in the MPIR source
> tree, then links against that. This works on every other architecture
> I am aware of.
>
>>
>> If we run 'ldd' on some files in /usr/lib, we see they are all 32-bit.
>>
>> $ file /usr/lib/*
>> /usr/lib/libsldap.so: ELF 32-bit MSB dynamic lib SPARC Version 1,
>> dynamically linked, not stripped, no debugging information available
>> /usr/lib/libsldap.so.1: ELF 32-bit MSB dynamic lib SPARC Version 1,
>> dynamically linked, not stripped, no debugging information available
>>
>> But if we do so on /usr/lib/sparcv9, then we see they are 64-bit.
>>
>> $ file /usr/lib/sparcv9/*
>> /usr/lib/sparcv9/libST.so: ELF 64-bit MSB dynamic lib SPARCV9 Version
>> 1, dynamically linked, not stripped
>> /usr/lib/sparcv9/libST.so.1: ELF 64-bit MSB dynamic lib SPARCV9 Version
>> 1, dynamically linked, not stripped
>> /usr/lib/sparcv9/libUil.so: ELF 64-bit MSB dynamic lib SPARCV9 Version
>> 1, dynamically linked, not stripped, no debugging information available
>>
>> So what is happening is that the 64-bit objects are trying to link with
>> libraries in a directory where the 32-bit libraries should be, and not where
>> the 64-bit libraries should be. That will certainly fail.
>
> So maybe that has nothing to do with MPIR.
>
>>
>> I've just tried on a Sun Ultra 27 Xeon, and all tests pass, though I think
>> the processor being chosen is not optimal. It is picking 'core2' but I think
>> there is a better choice for the Xeon. (I forget what it is).
>
> There are only two possibilities, core2 and penryn. If you tell me the
> family and model of the processor I'll check that it is selecting the
> correct one.
>
>>
>> It would be helpful if all the tests were run together. It is a bit
>> confusing when 9 tests are run, then some more tests are compiled. Then some
>> more tests are run, then some more bits compiled.
>
[sage-support] Re: [mpir-devel] Re: [sage-devel] MPIR 1.3.0 released (at last)
So on t2 there is no /usr/local/lib/sparcv9, so that's a bit useless!
Does this mean t2 is not capable of running 64 bit binaries?
2010/1/28 Dr. David Kirkby :
> Bill Hart wrote:
>>
>> Hi all,
>>
>> it is with pleasure that we (finally) officially release MPIR 1.3.0.
>> It is available at our website http://www.mpir.org/
>>
>> Please note the following important things:
>>
>> * I have been unable to get any tests to pass on ultrasparc2 machines,
>
> I've just tried on an UltraSPARC III+, and no tests pass. The problem is
> quite easy to see, though don't ask me how you solve it, as I don't know how
> to use 'libtool'.
>
> Assuming gcc is installed under /usr/local (for simplicity), then the
> object files are built 64-bit, but then a message similar to this is shown:
>
> ld.so.1: t-hightomask: fatal: /usr/local/lib/libgcc_s.so.1: wrong ELF class:
> ELFCLASS32
> /bin/bash: line 1: 22883 Killed ${dir}$tst
>
> The problem is that 64-bit libraries should never be in /usr/local/lib.
> Instead they should be in /usr/local/lib/sparcv9.
>
> If we run 'ldd' on some files in /usr/lib, we see they are all 32-bit.
>
> $ file /usr/lib/*
> /usr/lib/libsldap.so: ELF 32-bit MSB dynamic lib SPARC Version 1,
> dynamically linked, not stripped, no debugging information available
> /usr/lib/libsldap.so.1: ELF 32-bit MSB dynamic lib SPARC Version 1,
> dynamically linked, not stripped, no debugging information available
>
> But if we do so on /usr/lib/sparcv9, then we see they are 64-bit.
>
> $ file /usr/lib/sparcv9/*
> /usr/lib/sparcv9/libST.so: ELF 64-bit MSB dynamic lib SPARCV9 Version
> 1, dynamically linked, not stripped
> /usr/lib/sparcv9/libST.so.1: ELF 64-bit MSB dynamic lib SPARCV9 Version
> 1, dynamically linked, not stripped
> /usr/lib/sparcv9/libUil.so: ELF 64-bit MSB dynamic lib SPARCV9 Version
> 1, dynamically linked, not stripped, no debugging information available
>
> So what is happening is that the 64-bit objects are trying to link with
> libraries in a directory where the 32-bit libraries should be, and not where
> the 64-bit libraries should be. That will certainly fail.
>
> I've just tried on a Sun Ultra 27 Xeon, and all tests pass, though I think
> the processor being chosen is not optimal. It is picking 'core2' but I think
> there is a better choice for the Xeon. (I forget what it is).
>
> It would be helpful if all the tests were run together. It is a bit
> confusing when 9 tests are run, then some more tests are compiled. Then some
> more tests are run, then some more bits compiled. So one has to scroll up
> the screen, and check that each set of tests have been successful. It would
> be good if all the tests were first compiled, then all run together.
>
> Dave
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To post to this group, send email to mpir-de...@googlegroups.com.
> To unsubscribe from this group, send email to
> mpir-devel+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mpir-devel?hl=en.
>
>
--
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org
[sage-support] Re: [mpir-devel] Re: [sage-devel] MPIR 1.3.0 released (at last)
2010/1/28 Dr. David Kirkby :
> Bill Hart wrote:
>>
>> Hi all,
>>
>> it is with pleasure that we (finally) officially release MPIR 1.3.0.
>> It is available at our website http://www.mpir.org/
>>
>> Please note the following important things:
>>
>> * I have been unable to get any tests to pass on ultrasparc2 machines,
>
> I've just tried on an UltraSPARC III+, and no tests pass. The problem is
> quite easy to see, though don't ask me how you solve it, as I don't know how
> to use 'libtool'.
>
> Assuming gcc is installed under /usr/local (for simplicity), then the
> object files are built 64-bit, but then a message similar to this is shown:
>
> ld.so.1: t-hightomask: fatal: /usr/local/lib/libgcc_s.so.1: wrong ELF class:
> ELFCLASS32
> /bin/bash: line 1: 22883 Killed ${dir}$tst
>
> The problem is that 64-bit libraries should never be in /usr/local/lib.
> Instead they should be in /usr/local/lib/sparcv9.
I am not installing MPIR on these machines, as I do not have root
access on either. Thus whatever is in /usr/local/lib is not my
responsibility.
Libtool builds the MPIR library in a directory in the MPIR source
tree, then links against that. This works on every other architecture
I am aware of.
>
> If we run 'ldd' on some files in /usr/lib, we see they are all 32-bit.
>
> $ file /usr/lib/*
> /usr/lib/libsldap.so: ELF 32-bit MSB dynamic lib SPARC Version 1,
> dynamically linked, not stripped, no debugging information available
> /usr/lib/libsldap.so.1: ELF 32-bit MSB dynamic lib SPARC Version 1,
> dynamically linked, not stripped, no debugging information available
>
> But if we do so on /usr/lib/sparcv9, then we see they are 64-bit.
>
> $ file /usr/lib/sparcv9/*
> /usr/lib/sparcv9/libST.so: ELF 64-bit MSB dynamic lib SPARCV9 Version
> 1, dynamically linked, not stripped
> /usr/lib/sparcv9/libST.so.1: ELF 64-bit MSB dynamic lib SPARCV9 Version
> 1, dynamically linked, not stripped
> /usr/lib/sparcv9/libUil.so: ELF 64-bit MSB dynamic lib SPARCV9 Version
> 1, dynamically linked, not stripped, no debugging information available
>
> So what is happening is that the 64-bit objects are trying to link with
> libraries in a directory where the 32-bit libraries should be, and not where
> the 64-bit libraries should be. That will certainly fail.
So maybe that has nothing to do with MPIR.
>
> I've just tried on a Sun Ultra 27 Xeon, and all tests pass, though I think
> the processor being chosen is not optimal. It is picking 'core2' but I think
> there is a better choice for the Xeon. (I forget what it is).
There are only two possibilities, core2 and penryn. If you tell me the
family and model of the processor I'll check that it is selecting the
correct one.
>
> It would be helpful if all the tests were run together. It is a bit
> confusing when 9 tests are run, then some more tests are compiled. Then some
> more tests are run, then some more bits compiled.
As far as I know that's impossible to change. The tests are run per
source directory by autotools. All packages that use autotools do
that. You could report this issue on the autotools list.
> So one has to scroll up
> the screen, and check that each set of tests have been successful. It would
> be good if all the tests were first compiled, then all run together.
>
If you run make check a second time you will see all the tests without
the compilation. Also, if any tests fail in any directory the whole
process stops (assuming they even ran in the first place).
Bill.
--
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org
[sage-support] Re: [mpir-devel] Re: [sage-devel] MPIR 1.3.0 released (at last)
2010/1/28 Dr. David Kirkby : > Bill Hart wrote: >> >> Hi all, >> >> it is with pleasure that we (finally) officially release MPIR 1.3.0. >> It is available at our website http://www.mpir.org/ >> >> Please note the following important things: >> >> * I have been unable to get any tests to pass on ultrasparc2 machines, >> including t2 (solaris) and gcc54 (linux). > > 't2' is not an UltraSPARC II machine. It is a sun4v architecture, with T2+ > processors. OK, but it doesn't build on t2, whatever architecture that is. It used to, and we haven't changed anything sparc related, that I know of. > > UltraSPARC II is pretty old now. I can't say I know exactly what machines > have that. > > Can you give further examples on machines on which this does not build? gcc54, which according to http://gcc.gnu.org/wiki/CompileFarm is gcc54 9084 36G 0.5 GHz TI UltraSparc IIe (Hummingbird) / 1.5 GB RAM / Sun Netra T1 200 That is the only other machine which it is failing on. > > The nearest I have is an UltraSPARC-IIe. I also have an UltraSPARC-III+ > > I'll try a build on these later and let you know. > Thanks. Bill. -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] MPIR 1.3.0 released (at last)
Hi all, it is with pleasure that we (finally) officially release MPIR 1.3.0. It is available at our website http://www.mpir.org/ Please note the following important things: * I have been unable to get any tests to pass on ultrasparc2 machines, including t2 (solaris) and gcc54 (linux). I am confident there are not bugs in the ultrasparc assembly code (as we haven't changed it and it worked before). Thus if someone can tell me how to get MPIR to behave on these machines "out-of-the-box" I will make the necessary changes to MPIR. In the mean time, we have to officially consider MPIR broken on such machines (or the machines we test on to be broken). Note this is *not* a Solaris issue as MPIR builds just fine on Solaris. * It is no longer necessary to issue make install gmp-compat, however it is still necessary to use --enable-gmpcompat with configure if you want a gmp.h and libgmp * Many users believe that mpz_nextprime returns a prime. In fact it is only guaranteed to define a number which is with high probability prime. For this reason the function has been deprecated. Please use the new mpz_next_likely_prime in its place. * Most of the random functions in MPIR which require global random state have been deprecated and new functions provided which have local state. This allows code using MPIR random functions to be threadsafe. * The functions mpz_div_2exp and mpz_div_ui have been removed from MPIR. These were deprecated many years ago, but many people have continued to use them. A quick workaround is to use the following defines: #ifndef mpz_div_2exp #define mpz_div_2exp mpz_tdiv_q_2exp #endif #ifndef mpz_div_ui #define mpz_div_ui mpz_tdiv_q_ui #endif However, the better fix is to actually replace all occurrences in code. (Users of FLINT will have to wait a couple of days until I issue an update to FLINT, in particular the quadratic sieve, which still uses the old functions - in the mean time, just add the above defines to flint.h). Bill. -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Re: sage server setup support sought
Ah, OK, thanks for clearing that up. Bill. On Aug 17, 7:04 pm, William Stein wrote: > On Mon, Aug 17, 2009 at 4:27 AM, Bill Hart wrote: > > > It's ubuntu and we can open the port as we have root access (assuming > > John is talking about the same machine - which I am pretty sure he > > is). > > > How secure is the notebook server these days. Is it still advised to > > set it up in a chroot jail (see my other post about problems I had > > doing that). > > That was *only* for a public notebook server. If you're using > secure=True and accounts=False, so only people with existing accounts > can us the notebook server, there is no reason to use a chroot. > > Moreover, the standard wisdom in security is that it is in fact never > ever in any case ever a good idea to use a chroot for security > purposes. Thus one should never do that for the Sage notebook. The > only acceptable thing for a public server is to use a virtual machine > (say virtualbox or vmware). > > William --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: sage server setup support sought
Actually, to keep everything in the same place, here is a message I tried to send but which bounced because I hadn't subscribed yet, relevant to the same machine John is trying to set up a server on. I'm trying to set up a chroot_jail for sage to run in so I can get a notebook working on my new machine. I followed the instructions here: http://www.msri.org/about/computing/docs/sage/inst/node4.html There seems to be one step missing, which is to first create the directory /sage_chroot, otherwise when you try to mount onto it Ubuntu complains. However, even after I do that, it says: mount: not a directory when I try to do mount -a It doesn't give me any other clues. The only thing I am doing slightly differently to the instructions is I made the image (and the filesystem it contains) on /storage, which is where the Raid array is mounted. But I don't see that this is part of the problem. Naturally I changed all the relevant paths in the instructions to /storage/sage_chroot.image. Can anyone help? Bill. On Aug 17, 8:40 am, William Stein wrote: > On Sun, Aug 16, 2009 at 4:45 PM, Kevin Horton wrote: > > > Actually, I probably spoke out of turn. The ":8000" at the end of the > > url specifies the port to use, so https shouldn't be using the default > > port. But, there could be a firewall preventing port 8000 from > > working, or a port forwarding problem if your server is hiding behind > > a router. > > > I recall having similar issues connecting to sage over https, but I > > don't recall all the gory details. I do recall that I had to set up > > ssl certificates, and enable ssh in apache before I could connect with > > https. Google "enable https ubuntu". > > > I can connect to your server using http, but not using https. I think > > the first step is to ensure you can connect to your web server using > > https. Once you've confirmed that https works, you can then try > > connecting to the sage server. > > The Sage notebook run via the notebook command has nothing to do with > apache or your web server. So that's not the first step, IMHO. > > Kevin's other remarks seem very on I'm guessing you have a firewall > setup on that computer which doesn't let anything in except on ports > that have been explicitly opened. > > The right command (now that you gave more info) is > > sage: notebook(address="137.205.37.242", port=8000, secure=True) > > Questions: > > (1) On that computer itself say from a text console, can you do > > lynxhttps://137.205.37.242:8000 > ? > > Can you do > > lynxhttps://localhost:8000 > > (2) What happens if you try > > sage: notebook(address="137.205.37.242", port=8000, secure=False) > > andhttp://137.205.37.242 > > (3) What happens if you try shutting down apache, then run the > notebook as *root* and type > > sage: notebook(address="137.205.37.242", port=80, secure=True) > > and try to connect from some other computer? Maybe you can't if > you're not root and the university controls root. (I'm guessing this > box is at Univ of Warwick.) > > (4) Precisely what operating system are you using? Was it say > Redhat (or similar) setup by the university? If so, they almost > *surely* have lots of firewall stuff setup completely standard to > avoid malware, hackers, etc. If this is the case, you must talk to > them and ask them to open up port 8000 so you can run a Sage notebook > server on it and have outside connections. > > (5) Failing all that, you might want to do ssh port forwarding. I > think Nils Bruin posted some nice instructions about how to do this to > sage-devel once. > > -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: sage server setup support sought
It's ubuntu and we can open the port as we have root access (assuming John is talking about the same machine - which I am pretty sure he is). How secure is the notebook server these days. Is it still advised to set it up in a chroot jail (see my other post about problems I had doing that). Bill. On Aug 17, 8:40 am, William Stein wrote: > On Sun, Aug 16, 2009 at 4:45 PM, Kevin Horton wrote: > > > Actually, I probably spoke out of turn. The ":8000" at the end of the > > url specifies the port to use, so https shouldn't be using the default > > port. But, there could be a firewall preventing port 8000 from > > working, or a port forwarding problem if your server is hiding behind > > a router. > > > I recall having similar issues connecting to sage over https, but I > > don't recall all the gory details. I do recall that I had to set up > > ssl certificates, and enable ssh in apache before I could connect with > > https. Google "enable https ubuntu". > > > I can connect to your server using http, but not using https. I think > > the first step is to ensure you can connect to your web server using > > https. Once you've confirmed that https works, you can then try > > connecting to the sage server. > > The Sage notebook run via the notebook command has nothing to do with > apache or your web server. So that's not the first step, IMHO. > > Kevin's other remarks seem very on I'm guessing you have a firewall > setup on that computer which doesn't let anything in except on ports > that have been explicitly opened. > > The right command (now that you gave more info) is > > sage: notebook(address="137.205.37.242", port=8000, secure=True) > > Questions: > > (1) On that computer itself say from a text console, can you do > > lynxhttps://137.205.37.242:8000 > ? > > Can you do > > lynxhttps://localhost:8000 > > (2) What happens if you try > > sage: notebook(address="137.205.37.242", port=8000, secure=False) > > andhttp://137.205.37.242 > > (3) What happens if you try shutting down apache, then run the > notebook as *root* and type > > sage: notebook(address="137.205.37.242", port=80, secure=True) > > and try to connect from some other computer? Maybe you can't if > you're not root and the university controls root. (I'm guessing this > box is at Univ of Warwick.) > > (4) Precisely what operating system are you using? Was it say > Redhat (or similar) setup by the university? If so, they almost > *surely* have lots of firewall stuff setup completely standard to > avoid malware, hackers, etc. If this is the case, you must talk to > them and ask them to open up port 8000 so you can run a Sage notebook > server on it and have outside connections. > > (5) Failing all that, you might want to do ssh port forwarding. I > think Nils Bruin posted some nice instructions about how to do this to > sage-devel once. > > -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
