Re: [sage-devel] coercion issue
Interesting. It seems the problem is that cm.discover_action(GF(5), ZZ, operator.div) tries to look for a right action on of cm.discover_action(GF(5), Frac(ZZ), operator.mul) which doesn't exist as there are no coercions between GF(5) and QQ. I posted a patch to http://trac.sagemath.org/ticket/17740 . On Thu, Feb 5, 2015 at 1:39 PM, Jonas Jermann wrote: > Hi > > Set x=GF(5)['x'].gen() > I dunno if this helps but here is an explanation why one gets a > different behavior for x/7 than cm.bin_op(x,7,operator.div): > > If you do "x/7" then I think it calls __div__ from polynomial_element > (Polynomial class): > > try: > if not isinstance(right, Element) or right.parent() != self.parent(): > R = self.parent().base_ring() > x = R._coerce_(right) > return self * ~x > except (TypeError, ValueError): > pass > return RingElement.__div__(self, right) > > Here right=ZZ(7), self=x, so right.parent() != self.parent() > so it does x = GF(5)._coerce_(7) > which is why you end up without the Fraction Field... > > If on the other hand you do cm.bin_op(x,7,operator.div) or x._div_(7) you > get a Fraction Field element at the moment. > > > Best > Jonas > > > On 05.02.2015 22:08, Vincent Delecroix wrote: >> >> 2015-02-05 21:38 UTC+01:00, John Cremona : >>> >>> If you ask for operator.mul instead of operator.div then you get the >>> poly ring. Is that it, perhaps? >> >> >> Nope. I want to get rid of many hacks in rings/polynomial. In order to >> do that I need the div operation to be correctly handled by the >> coercion (or perhaps I missed something about the aim of coercion?). >> Namely, if p is an element of GF(5)['x,y'] then (p/Integer(2)) should >> be an element of GF(5)['x,y']. You can argue that this is what you get >> in Sage >> >> sage: R = GF(5)['x','y'] >> sage: (R.an_element() / 2).parent() >> Multivariate Polynomial Ring in x, y over Finite Field of size 5 >> >> But the reason why is a bit of a hack that actually introduce many >> bugs in other places: >> >> sage: R = GF(5)['x,y'] >> sage: (R.one() / R.one()).parent() >> Multivariate Polynomial Ring in x, y over Finite Field of size 5 >> >> the above should be an element of the fraction field! And you can >> build more involved examples. >> >> Vincent >> > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: flint-2.4.4 compile error for Sage-6.4 on MacOSX Mavericks
Thanks. Unfortunately, I haven't been able to figure out what is causing this. It looks like your gmp.h is turning either mpn_com or mpn_com_n into __gmpn_com_n as it should. It certainly doesn't turn it into ___gmpn_com. I have absolutely no idea what could be causing the extra underscore, or the com instead of com_n. Somehow, a header file has to be being picked up from somewhere else that is doing the wrong thing. You could verify that mpir and flint build standalone by downloading mpir-2.7.0-alpha (from mpir.org), mpfr-3.1.2 (from mpfr.org) and flint-2.4 (from flintlib.org). Untar the files in your home directory. cd mpir-2.7.0 ./configure -- enable-gmpcompat ABI=64 make make check cd ../mpfr-3.1.2 ./configure --with-gmp-build=/home/xander/mpir-2.7.0 make cd ../flint2 ./configure --with-mpir=/home/xander/mpir-2.7.0 --with-mpfr=/home/xander/mpfr-3.1.2 ABI=64 make where I am assuming your home directory is /home/xander. If not, just change it to whatever it is. If all that works, then the issue must surely be sage specific. I honestly have no idea how this particular issue can happen. After more thought, I think the only thing that should matter is gmp.h. And your gmp.h looks correct. Bill. On Thursday, 5 February 2015 23:18:20 UTC+1, Xander Faber wrote: > > attached! > > On Thursday, February 5, 2015 at 4:17:26 PM UTC-5, Bill Hart wrote: >> >> Can you post sage/local/include/gmp.h here. I can't see how it is getting >> the wrong symbol name, under any circumstances. >> >> On Thursday, 5 February 2015 22:04:55 UTC+1, Bill Hart wrote: >>> >>> Actually, we call mpn_com_n in flint. In flint.h this becomes mpn_com. >>> >>> In gmp.h in MPIR this becomes __MPN(com_n) which must be ___gmpn_com_n >>> on your machine. >>> >>> If headers are included in the reverse order, mpn_com_n becomes directly >>> ___gmpn_com_n in gmp.h. >>> >>> This is indeed the name of the symbol we export. I can't see why it >>> should be looking for the symbol ___gmpn_com, which certainly doesn't exist. >>> >>> I don't see why this is happening. >>> >>> On Thursday, 5 February 2015 21:50:59 UTC+1, Bill Hart wrote: I can't shed much light on this. We do indeed call mpn_com_n from those flint functions. In flint.h mpn_com_n is #defined to mpn_com for compatibility with various versions of MPIR. The latter becomes xxxmpn_com where xxx can be g, _g, __g or ___g depending on the global symbol prefix on your platform. On lines 23 and 24 of mpn/generic/com_n.c in MPIR we have #undef mpn_com_n #define mpn_com_n __MPN(com_n) Who knows what the effect of this is. But on a core i5, this should all be irrelevant, since for all core2 and later Intel processors, mpn/x86_64/core2/com_n.as should be compiled and should use the standard symbol prefix for your system regardless. I'd be inclined to look at the MPIR build log and see if it detected your processor correctly, or whether it thought it was just a generic x86_64. Unless your OS kernel is 32 bits somehow. But even in that case, mpn/x86/core2/com_n.asm should take care of it for you. Bill. On Tuesday, 3 February 2015 13:33:18 UTC+1, Xander Faber wrote: > > I was building Sage 6.4 on a Mac Pro 2.6 GHz Intel Core i5. > > Tail end of the flint log file: > > > > > CC ../build/fq_zech_poly_factor/../fq_zech_poly_factor.lo > > CXX build/interfaces/NTL-interface.lo > > Undefined symbols for architecture x86_64: > > "___gmpn_com", referenced from: > > _fmpz_bit_pack in fmpz.lo > > _fmpz_bit_unpack in fmpz.lo > > ld: symbol(s) not found for architecture x86_64 > > collect2: error: ld returned 1 exit status > > make[4]: *** [libflint.dylib] Error 1 > > make[3]: *** [library] Error 2 > > Error: Failed to build FLINT shared library. > > > > > real 3m30.826s > > user 2m32.253s > > sys 0m51.078s > > > > > Error installing package flint-2.4.4 > > > > > Please email sage-devel (http://groups.google.com/group/sage-devel) > > explaining the problem and including the relevant part of the log > file > > /Users/xander/sage/logs/pkgs/flint-2.4.4.log > > Describe your computer, operating system, etc. > > If you want to try to fix the problem yourself, *don't* just cd to > > /Users/xander/sage/local/var/tmp/sage/build/flint-2.4.4 and type 'make' > or whatever is appropriate. > > Instead, the following commands setup all environment variables > > correctly and load a subshell for you to debug t
[sage-devel] Re: weil restriction for affine schemes as a functor?
This is now #17729 On Monday, February 2, 2015 at 8:59:33 PM UTC-5, Ben Hutz wrote: > > I'm interested in implementing Weil restriction (restriction of scalars) > for affine schemes. I see from #5569, that there is an implementation for > ideals. I'd like to extend this to affine schemes/points/morphisms. There > is also an aborted attempt of Weil restriction for projective models of > elliptic curves #13266 that does not seem to be going anywhere. > > While the code for the restriction for each of these (affine) objects is > not difficult, this seems like something that should be implemented as a > functor as you'd like the resulting schemes/points/morphisms to all play > nicely together. However, I know little about functors in Sage. I've looked > around in the code a little bit hoping to find an example where something > like this was done before, but I'm having some trouble. I see where Spec is > implemented as a functor, but I'm not sure that is helpful. I've also seen > the documentation about which functions a new functor class should > override. I'm sure I'm going to get this wrong, but as a place to start > this discussion would an implementation look something like this > > 1) create a new functor class WeilRestrictionAffineFunctor which implements > _coerce_into_domain(self, x) > _apply_functor(self, x) > _apply_functor_to_morphism(self, f) > > although it doesn't seem like any of these three would apply to the points > of the affine scheme. > > 2) Given an affine scheme A and a morphism f:A -> A, have the methods > A.weil_restriction() and f.weil_restriction() call the functor so that > domains/codomains all match-up nicely? For example, I'd like something like > this to work > > sage: K.=QuadraticField(3) > sage: A.=AffineSpace(K,2) > sage: X=A.subscheme([y^2-x^2]) > sage: H=End(X) > sage: f=H([y,x]) > sage: P=X(-1,1) > sage: f(P).weil_restriction() == f.weil_restriction(P.weil_restriction()) > True > > > I'm sure I could make this work manually by caching the weil_restriction > of a scheme so that a new one is only created when it doesn't already exist > (like 'homogenize' does) but, at least mathematically, this really should > be a functor. I guess my first question is then: Is a functor the 'right' > choice for implementation of Weil restriction in Sage? If yes, is there > anywhere else in Sage something like this is done from which I can base > this new functionality? > > Thanks, > Ben > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Pari, SR, number fields, strings, and coercions
Hi,
The following example from q_analogues.py happens to work for a number
of questionable reasons:
sage: q_binomial(6,1,I)
1 + I
I'm working on a patch that breaks (or fixes, depending how you look at
it) one of the behaviors it relies on, and I'd like advice on how to
handle the situation.
Here is my understanding of what is going on. Please correct me if I'm
missing something.
The implementation of q_binomial(n, k, q) in this case essentially
amounts to:
from sage.rings.polynomial.cyclotomic import cyclotomic_value
return prod(cyclotomic_value(d,q)
for d in range(2,n+1)
if floor(n/d) != floor(k/d) + floor((n-k)/d))
and that cyclotomic_value(n, x) to
if n < 3:
if n == 1:
return x - 1
if n == 2:
return x + 1
raise ValueError("n must be positive")
try:
return x.parent()(pari.polcyclo_eval(n, x))
...
Now recall that I is an element of SR that wraps an element of a
quadratic number field equipped with a complex embedding:
sage: I.parent()
Symbolic Ring
sage: I.pyobject().parent()
Number Field in I with defining polynomial x^2 + 1
sage: I.pyobject().parent().coerce_embedding()
Generic morphism:
From: Number Field in I with defining polynomial x^2 + 1
To: Complex Lazy Field
Defn: I -> 1*I
At first cyclotomic_value() appears to work well when called with q=I:
sage: cyclotomic_value(1, I)
I - 1
sage: cyclotomic_value(3, I)
I
The call to polcyclo_eval() succeeds "thanks" to the fact that
essentially anything can be converted (and even coerced) to a Pari
object based, ultimately, on its string representation. (This happens
through a maze of calls to _pari_, _pari_init_, _interface_init_,
PariInstance.__call__ and objtogen. By the way, can anyone explain the
interplay between the *two* places where the conversion falls back to
using the string representation, namely in SageObject._interface_init_
and pari.gen.objtogen?)
As cyclotomic_value() is careful to convert back the result to the
parent of x, we have:
sage: cyclotomic_value(1, I).parent()
Symbolic Ring
sage: cyclotomic_value(3, I).parent()
Symbolic Ring
But depending on the value of the first parameter, the true numeric
object wrapped by the symbolic result will not have the same parent:
sage: cyclotomic_value(1, I).pyobject().parent()
Number Field in I with defining polynomial x^2 + 1
sage: cyclotomic_value(3, I).pyobject().parent()
Interface to the PARI C library
Not very nice, but hopefully the coercion system should be able to
handle this, right? As it turns out, number fields have a properly
implemented conversion to Pari (one that doesn't just take the string
representation and hope for the best). This conversion, however, ignores
the embedding:
sage: pari(I.pyobject())
Mod(y, y^2 + 1)
Thus:
sage: pari(I)*pari(I.pyobject())
Mod(I*y, y^2 + 1)
and yet:
sage: pari(I)*I.pyobject()
-1
sage: (pari(I)*I.pyobject()).parent()
Interface to the PARI C library
The trick is that the coercion discovery system currently prefers
sage: pari.coerce_map_from(I.pyobject().parent())
Composite map:
From: Number Field in I with defining polynomial x^2 + 1
To: Interface to the PARI C library
Defn: Generic morphism:
From: Number Field in I with defining polynomial x^2 + 1
To: Complex Lazy Field
Defn: I -> 1*I
then
Call morphism:
From: Complex Lazy Field
To: Interface to the PARI C library
to the direct conversion (which, as already mentioned, is also marked as
a coercion). Of course, the coercion diagram is supposed to be
commutative, but we all know this is currently far from true.
This indirect coercion has the benefit of taking the embedding into
account, and turns out to give the correct result in our particular
example. In general, however, it is much worse than the direct one.
Indeed, the CLF -> pari step is the fall-back conversion based on the
string representation:
sage: pari(1)*(I.pyobject()/3)
*** Warning: unused characters: ?*I.
0.333
Now to my questions. A side effect of the patches I'm working on at
#14982 to fix another coercion problem is that the direct conversion
NF -> pari would be preferred to the indirect one, leading to:
sage: q_binomial(6,1,I)
Mod(y + 1, y^2 + 1)
So:
(1) What would be an acceptable workaround for the regression in
q_binomial() that would allow me to move forward with the ticket
I was originally working on?
(2) In the longer term, how do we deal with that mess?
Thanks,
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this
Re: [sage-devel] Is CMake OK for a standard spkg?
Le 06/02/2015 08:15, Francois Bissey a écrit : > Cmake is a reverse approach compared to autotools. You need cmake installed > to configure the software. The system to build (make or something else) is > somewhat OS dependent. autotool generate a script and you don’t need > auto tool installed on the target system. > > The main issue that you need to bootstrap it. i.e. cmake is used to build > cmake. > > Francois > This means we can only rely on a system wide installed cmake ? For the user, it is only one package to install (apt-get...). But the autotools, too, are supposed to be installed system wide. So, where is the problem? I understand that Sage uses as few as possible dependencies as possible -which extremly nice-, but cmake is now widely used. I think that, sooner or later, sage will need cmake: most programmers are switching from the autotools to cmake: it is much easier to learn, to adapt and to use, and extremely powerfull. I have ported all my codes (generally C++ + some Fortran + MPI +...) to cmake. I feel much better now :-) t.d. >> On 6/02/2015, at 19:54, Jeroen Demeyer wrote: >> >> On 2015-02-05 23:06, William wrote: >>> I wonder what is the latest on Sage and cmake? Ondrej Certik was >>> just telling me about csympy, which uses cmake, and wondered whether >>> that would be a deal break for inclusion of csympy as standard in Sage. >>>Definitely 4 years ago it would have been. >> >> Isn't cmake more like automake, i.e. run at packaging-time, not build-time? >> >> I don't know how reliable/portable cmake is, but generally I don't like "yet >> another build system". IMHO, nothing beats autotools and SCons is a disaster >> (but I'm sure other people have other opinions on this). I don't know where >> on this scale CMake lies. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sage-devel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to sage-devel+unsubscr...@googlegroups.com. >> To post to this group, send email to sage-devel@googlegroups.com. >> Visit this group at http://groups.google.com/group/sage-devel. >> For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. <>
Re: [sage-devel] Is CMake OK for a standard spkg?
On 2015-02-06 14:42, Thierry Dumont wrote: But the autotools, too, are supposed to be installed system wide. Not true. Building a package using autotools doesn't require autotools. Autotools generates files like configure which are shipped with the sources. Executing those files does not require autotools. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Is CMake OK for a standard spkg?
On 6 February 2015 at 14:47, Jeroen Demeyer wrote: > > Not true. Building a package using autotools doesn't require autotools. > Autotools generates files like configure which are shipped with the > sources. Executing those files does not require autotools. But it requires some sort of GNU environment to be available... Which in platforms such as Windows could be a problem. CMake was chosen as the build system for KDE starting with version 4 and - as far as I have seen - it has become the de-facto standard for Qt applications in general. It is certainly up to the task of being able to deal with non-trivial software projects. I am not a big fan of the macro syntax, but after having used CMake for a quite a long time I am rather satisfied with it personally. Cheers, Francesco. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Is CMake OK for a standard spkg?
On 2015-02-06, Thierry Dumont wrote: > Le 06/02/2015 08:15, Francois Bissey a écrit : >> Cmake is a reverse approach compared to autotools. You need cmake installed >> to configure the software. The system to build (make or something else) is >> somewhat OS dependent. autotool generate a script and you don’t need >> auto tool installed on the target system. >> >> The main issue that you need to bootstrap it. i.e. cmake is used to build >> cmake. >> >> Francois >> > > This means we can only rely on a system wide installed cmake ? For the > user, it is only one package to install (apt-get...). > But the autotools, too, are supposed to be installed system wide. So, > where is the problem? I understand that Sage uses as few as possible > dependencies as possible -which extremly nice-, but cmake is now widely > used. > > I think that, sooner or later, sage will need cmake: most programmers > are switching from the autotools to cmake: it is much easier to learn, Wait, Kiware's, the main cmake company, only non-US office is in Lyon... :-) > to adapt and to use, and extremely powerfull. I have ported all my codes > (generally C++ + some Fortran + MPI +...) to cmake. I feel much better > now :-) it might be easier for programmers, but less so for users. My experience is that that install of a project under cmake starts bugging you with a lot of stupid or hard questions. And how does one use it to do cross-platform shared libraries? Dima > > t.d. > > >>> On 6/02/2015, at 19:54, Jeroen Demeyer wrote: >>> >>> On 2015-02-05 23:06, William wrote: I wonder what is the latest on Sage and cmake? Ondrej Certik was just telling me about csympy, which uses cmake, and wondered whether that would be a deal break for inclusion of csympy as standard in Sage. Definitely 4 years ago it would have been. >>> >>> Isn't cmake more like automake, i.e. run at packaging-time, not build-time? >>> >>> I don't know how reliable/portable cmake is, but generally I don't like >>> "yet another build system". IMHO, nothing beats autotools and SCons is a >>> disaster (but I'm sure other people have other opinions on this). I don't >>> know where on this scale CMake lies. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "sage-devel" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to sage-devel+unsubscr...@googlegroups.com. >>> To post to this group, send email to sage-devel@googlegroups.com. >>> Visit this group at http://groups.google.com/group/sage-devel. >>> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Is CMake OK for a standard spkg?
> On 7/02/2015, at 06:10, Dima Pasechnik wrote: > > On 2015-02-06, Thierry Dumont wrote: >> Le 06/02/2015 08:15, Francois Bissey a écrit : >>> Cmake is a reverse approach compared to autotools. You need cmake installed >>> to configure the software. The system to build (make or something else) is >>> somewhat OS dependent. autotool generate a script and you don’t need >>> auto tool installed on the target system. >>> >>> The main issue that you need to bootstrap it. i.e. cmake is used to build >>> cmake. >>> >>> Francois >>> >> >> This means we can only rely on a system wide installed cmake ? For the >> user, it is only one package to install (apt-get...). >> But the autotools, too, are supposed to be installed system wide. So, >> where is the problem? I understand that Sage uses as few as possible >> dependencies as possible -which extremly nice-, but cmake is now widely >> used. >> >> I think that, sooner or later, sage will need cmake: most programmers >> are switching from the autotools to cmake: it is much easier to learn, > > Wait, Kiware's, the main cmake company, only non-US office is in Lyon... :-) > >> to adapt and to use, and extremely powerfull. I have ported all my codes >> (generally C++ + some Fortran + MPI +...) to cmake. I feel much better >> now :-) > > it might be easier for programmers, but less so for users. My > experience is that that install of a project under cmake starts bugging > you with a lot of stupid or hard questions. > > And how does one use it to do cross-platform shared libraries? I am not sure what you mean by that. But basically cmake knows the platform you install it on and set things appropriately. cross-compilation is also possible and has about as many caveat than autotools. I personally prefer autotools but cmake is often an acceptable solution. Francois -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Sagemath : wild experiments
Hi, Le 05/02/2015 22:10, Julien Puydt a écrit : Good news ! I did some cleaning, and I now have all your symptoms ! Well, perhaps that's not that good a piece of news, but at least now I have something to play with. Ok, I found the time to fight with it some today. I followed those steps : - apt-get source pari ; - apply sage's cb_pari_err_handle.patch patch ; - dpkg-buildpackage -b -us -uc (I have all deps so that's ok) - install the useful packages, and also copy by hand anal.h in /usr/include/x86_64-linux-gnu/pari/ I reported a wishlist bug on pari's debian package (#77237). Snark on #debian-science -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: flint-2.4.4 compile error for Sage-6.4 on MacOSX Mavericks
Hi Bill, Thanks for the detailed instructions. mpir-2.7.0 and mpfr-3.1.2 build fine on my system. When I run the makefile for flint, I get the following messages after a while: ` CC ../build/fq_zech_poly_factor/fq_zech_poly_factor_print.o CC ../build/fq_zech_poly_factor/fq_zech_poly_factor_print_pretty.o CC ../build/fq_zech_poly_factor/fq_zech_poly_factor_realloc.o CC ../build/fq_zech_poly_factor/fq_zech_poly_factor_set.o AR libflint.a /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libflint.a(fq_zech_clear.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libflint.a(fq_zech_clear.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libflint.a(fq_zech_clear.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libflint.a(fq_zech_clear.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libflint.a(fq_zech_clear.o) has no symbols` It does, however, proceed beyond the point where Sage's flint compile crashes. Afterward, I ran make check and everything passed. S ... Sage specific problem, you're thinking? Since I've now compiled mpir-2.70, mpfr-3.1.2, and flint-2.4.4 separately, is it feasible to just copy these libraries into the Sage directory and proceed with the Sage build? Any idea where I would put them? -Xander -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] git upgrade?
>From the Github team, this mention: Don't forget: an important Git security vulnerability was fixed last December. If you haven't upgraded your Git client since then, we recommend that you do so as soon as possible. The new release, 2.3.0, includes the security fix, as do the maintenance releases 1.8.5.6, 1.9.5, 2.0.5, and 2.1.4, which were released in December. The Sage website seems to indicate we are at 2.1.2, not 2.1.4. Upgrade? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] git upgrade?
On 7/02/2015, at 17:09, kcrisman wrote: > > From the Github team, this mention: > > Don't forget: an important Git security vulnerability was fixed last > December. If you haven't upgraded your Git client since then, we recommend > that you do so as soon as possible. The new release, 2.3.0, includes the > security fix, as do the maintenance releases 1.8.5.6, 1.9.5, 2.0.5, and > 2.1.4, which were released in December. > > The Sage website seems to indicate we are at 2.1.2, not 2.1.4. Upgrade? +1 François -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
