[sage-devel] Re: a 7(!) year old (Singular) overflow issue still holds

['Bill Hart' via sage-devel]

On Monday, 10 October 2016 12:31:25 UTC+2, Dima Pasechnik wrote:
>
>
>
> On Sunday, October 9, 2016 at 4:48:31 PM UTC, Bill Hart wrote:
>>
>>
>>
>> On Sunday, 9 October 2016 18:08:29 UTC+2, Dima Pasechnik wrote:
>>>
>>>
>>>
>>> On Sunday, October 9, 2016 at 3:35:57 PM UTC, Bill Hart wrote:

 By default, Singular uses 16 bit exponents. But it is perfectly capable 
 of working with exponents up to 64 bits. That will be slower of course.

 why? I presume arithmetic on 16-bit integers is not faster than on 
>>> 32-bit, or even 64-bit.
>>>
>>
>> It's the exponent arithmetic, not the coefficients we are talking about.
>>
>  
> sure - I was thinking about univariate case; in the multivariate case, if 
> you want fast arithmetic on exponents of monomials given as integer vectors 
> in year 2016, you probably would want to use GPU 
>
>
>> The exponents are packed, with four 16 bit field in a 64 bit word. This 
>> is *much* faster. I use the same trick, as does just about every decent 
>> computer algebra system out there.
>>
>> Interestingly, Magma only allows exponents up to about 30 bits, but it 
>> takes a few minutes to compute x^(2^30 - 1).
>>
>
> I wonder why this happens - a Flint issue? :
>
> sage: R.=QQ[]
> sage: x^(2^30)-1
> Exception (FLINT memory_manager). Unable to allocate memory.
>

I'm not precisely sure why that happens. How much memory did you have 
available on your machine?

This should create the polynomial x, then try to raise it to the power of 
2^30, which is about a billion I think.

Along the way it will use the FFT, which is a bit of a memory hog.

One day we ought to fix the powering code to handle monomials separately. 
It is 2016 after all.


> sage: x^(2^30-1)
> Killed
>
> (which appears to indicate that the recovery from the exception was not 
> complete)
>
> On the other hand:
>
> sage: timeit('x^(2^20-1)')
> 125 loops, best of 3: 1.66 ms per loop
> sage: 2^20-1
> 1048575
> sage: timeit('x^1048575')
> 125 loops, best of 3: 1.66 ms per loop
> sage: timeit('x^10')
> 625 loops, best of 3: 381 ns per loop
> sage: 2^30-1
> 1073741823
> sage: timeit('x^1073741823')
> 5 loops, best of 3: 1.72 s per loop
> sage: timeit('x^(2^30-1)')
> 5 loops, best of 3: 1.71 s per loop
>
> but then
>
> sage: x^(2^30-1)
>  at 0x7fbb07bd7910>) failed: MemoryError>
>
>
There's some caching in Flint I guess, though I'm not entirely sure why 
that would matter here.

Bill.
 

>
>  looks quite  strange...
> Dima
>
>  
>>
>>>  
>>>  
>>>
 I guess it isn't easy for Sage to change the relevant ring upon 
 overflow to one using 64 bit exponents.

 I can't say whether it would be easy or hard for Singular to 
 automatically change the exponent size for you. For basic arithmetic, I 
 have implemented precisely this in the code I've been writing. But 
 Singular 
 is almost infinitely more complex than the very simple cases I've been 
 dealing with in my own code. At this stage I couldn't even hazard a guess.

 I'll ask Hans if I remember. But either way, I believe this would be an 
 *extremely* time consuming thing to fix. How important is it?

 Bill.

 On Wednesday, 5 October 2016 01:10:31 UTC+2, Jakob Kroeker wrote:
>
>
> https://trac.sagemath.org/ticket/6472
>
> even for recent singular upgrade 
>
> https://trac.sagemath.org/ticket/17254
>
> and it was not(?) reported to upstream...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: NTL v10

[Victor Shoup]

I looked at the singular patch, regarding the use of nothrow new.
I dug up "ticket #852" which lead to that patch.
In all honesty, it looks like singular is doing something wrong,
so "fixing" NTL is just the wrong thing to do.
So I won't implement that patch in NTL.
This is a problem that should be fixed in singular, if it hasn't 
been already.


On Saturday, October 8, 2016 at 4:21:14 PM UTC-4, Victor Shoup wrote:
>
> I hope this is of some interest to the Sage community.
> I've just released a new version of NTL at http://www.shoup.net/ntl
>
> Here is a summary of changes.
>
> *New License: LGPLv2.1*
>
>- With the permission of all relevant contributors, NTL is now 
>licensed under  LGPLv2.1+ (the Lesser GNU Public License version 2.1 or 
>later).
>- Previously, NTL was licensed under the GPL. This new, less 
>restrictive licensing should hopefully increase the  impact of NTL.
>
>
> *Long integer package restructuring*
>
>- I've restructured the long integer package so that the GMP and 
>"classical LIP" modules share much of the same code base.
>- This greatly reduces the amount of redundant code, which will make 
>maintenance easier moving forward.
>- As a bonus, the classical LIP module is simpler, faster, and 
>(finally) thread safe. 
>- As another bonus, the GMP module now is much closer to being 
>compatible with "non-empty nails". Although it has not been tested in that 
>mode as of yet, it may eventually be helpful in the future if I want to 
>replace some GMP code with code that exploits AVX-512 IFMA instructions.
>- As a part of this transition, "make check" now includes much more 
>extensive "unit testing" of the long integer package.
>- Despite the drastic changes "under the hood", this restructuring 
>should not affect at all any  NTL client code that relies only on the 
>documented interface, including even the ancient legacy interfaces 
>pre-dating NTLv5a from 2000.
>
>
> *File name restructuring*
>
>- I've renamed all the ".c" files to ".cpp" files in the Unix 
>distribution. This seems to be more in line with common practice, and 
>should make it easier to work with compilers and other software 
> development 
>tools.
>
>
>

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: a 7(!) year old (Singular) overflow issue still holds

[Ralf Stephan]

See also the comments in https://trac.sagemath.org/ticket/12589

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[Francois Bissey]

And actually I said some stuff without revisiting what is done
in Gentoo and in sage and I am not sure which one is overkill
anymore. I inherit cruft from someone else (possibly me in the past).
I need to sort it out.

To go back to:
Second, in the patch, you write
   $(LINK) $(LIBTOOL_FLAGS)
whereas it seems to me more logical to put
  $(LIBTOOL_FLAGS) $(LINK)

I think libtool is able to figure it regardless of the order.
This flag is only used for cygwin in sage. It is then set to 
“-no-undefined” which is definitely recognised as a special 
argument for -mode=link and it will be treated specially.
But the libtool manual doesn’t say it has to be specified before 
or after the “linking” command. People are more comfortable with it 
being part of the linking command I guess.
I’d say the way it is done in the patch is the most usual way to do it.

François

> On 11/10/2016, at 13:26, Victor Shoup  wrote:
> 
> Anyway, like I said, I'm pretty much done, modulo a couple
> of things that I asked about two posts above.
> Hopefully, someone can clarify those points soon,
> and then there will be a distribution of NTL that does 
> not require any patching :-) 
> 
> On Monday, October 10, 2016 at 8:16:17 PM UTC-4, François wrote:
> Autotools is nicer for a lot of things. sage does patch 
> to use libtools and I stayed away from that in Gentoo. 
> The main advantage as far as I am concerned is that it makes 
> it easier to produce shared libraries, correctly on a variety 
> of platforms. Just for linux, and OS X, you don’t strictly 
> need to do that but it is a good investment in the future. 
> 
> In that regard the current sage solution is a bit of a halfway point. 
> You really should couple it with automake and autoconf but that’s 
> more work. 
> 
> But we should have pestered you about make/$(MAKE) a lot more 
> as it is a much bigger sin ;) 
> 
> François 
> 
> > On 11/10/2016, at 13:03, Victor Shoup  wrote: 
> > 
> > First, you are definitely wrong about punch cards. I started programming 
> > with Fortran on punch cards in the 70s. 
> > 
> > Second, a complete transition to auto tools still feels like overkill at 
> > this point. 
> > But I agree that it could come one day. 
> > In any case, I am almost done with all the requested changes. 
> > I will follow up with a couple of quick questions, though. 
> > 
> > On Monday, October 10, 2016 at 5:09:48 PM UTC-4, Dima Pasechnik wrote: 
> > 
> > 
> > On Monday, October 10, 2016 at 9:09:38 PM UTC+1, François wrote: 
> > On 11/10/16 01:58, Victor Shoup wrote: 
> > > Another issue. I'm not sure if $(MAKE) is specific to gnu make or if it 
> > > is universal. 
> > > In general, I don't want to assume gnu. But I can certainly make this the 
> > > default, 
> > > and provide a config variable to override. 
> > 
> > I'll have another go at this when you use 
> > $(MAKE) inside a makefile you are making sure 
> > that the make command used is the same one that 
> > you called on the initial makefile. 
> > 
> > As other people mentioned it enable parallel make 
> > to proceed nicely, and in the case where there is 
> > several make command installed on the system 
> > you avoid funny things happening. I have AIX 
> > system which comes with its own posix make 
> > command. Something like ntl probably require 
> > gmake (GNU make), calling AIX make in the 
> > middle is not a good idea. 
> > 
> > 
> > Perhaps the most natural solution would be to change NTL build system so 
> > that 
> > it uses the standard autotools chain (autoconf/automake etc), not only 
> > libtool. 
> > Given that it uses very few external libraries, it ought to be an easy 
> > task. 
> > 
> > Given that I am perhaps the only person in this thread who learned to 
> > program using punch cards, 
> > I am a dinosaur from an earlier period, yet, I look into the future :-) 
> >   
> > Dima 
> > 
> > 
> > 
> > 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+...@googlegroups.com. 
> > To post to this group, send email to sage-...@googlegroups.com. 
> > Visit this group at https://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 https://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 

Re: [sage-devel] NTL v10

[Victor Shoup]

Anyway, like I said, I'm pretty much done, modulo a couple
of things that I asked about two posts above.
Hopefully, someone can clarify those points soon,
and then there will be a distribution of NTL that does 
not require any patching :-) 

On Monday, October 10, 2016 at 8:16:17 PM UTC-4, François wrote:
>
> Autotools is nicer for a lot of things. sage does patch 
> to use libtools and I stayed away from that in Gentoo. 
> The main advantage as far as I am concerned is that it makes 
> it easier to produce shared libraries, correctly on a variety 
> of platforms. Just for linux, and OS X, you don’t strictly 
> need to do that but it is a good investment in the future. 
>
> In that regard the current sage solution is a bit of a halfway point. 
> You really should couple it with automake and autoconf but that’s 
> more work. 
>
> But we should have pestered you about make/$(MAKE) a lot more 
> as it is a much bigger sin ;) 
>
> François 
>
> > On 11/10/2016, at 13:03, Victor Shoup  
> wrote: 
> > 
> > First, you are definitely wrong about punch cards. I started programming 
> > with Fortran on punch cards in the 70s. 
> > 
> > Second, a complete transition to auto tools still feels like overkill at 
> this point. 
> > But I agree that it could come one day. 
> > In any case, I am almost done with all the requested changes. 
> > I will follow up with a couple of quick questions, though. 
> > 
> > On Monday, October 10, 2016 at 5:09:48 PM UTC-4, Dima Pasechnik wrote: 
> > 
> > 
> > On Monday, October 10, 2016 at 9:09:38 PM UTC+1, François wrote: 
> > On 11/10/16 01:58, Victor Shoup wrote: 
> > > Another issue. I'm not sure if $(MAKE) is specific to gnu make or if 
> it is universal. 
> > > In general, I don't want to assume gnu. But I can certainly make this 
> the default, 
> > > and provide a config variable to override. 
> > 
> > I'll have another go at this when you use 
> > $(MAKE) inside a makefile you are making sure 
> > that the make command used is the same one that 
> > you called on the initial makefile. 
> > 
> > As other people mentioned it enable parallel make 
> > to proceed nicely, and in the case where there is 
> > several make command installed on the system 
> > you avoid funny things happening. I have AIX 
> > system which comes with its own posix make 
> > command. Something like ntl probably require 
> > gmake (GNU make), calling AIX make in the 
> > middle is not a good idea. 
> > 
> > 
> > Perhaps the most natural solution would be to change NTL build system so 
> that 
> > it uses the standard autotools chain (autoconf/automake etc), not only 
> libtool. 
> > Given that it uses very few external libraries, it ought to be an easy 
> task. 
> > 
> > Given that I am perhaps the only person in this thread who learned to 
> program using punch cards, 
> > I am a dinosaur from an earlier period, yet, I look into the future :-) 
> >   
> > Dima 
> > 
> > 
> > 
> > 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+...@googlegroups.com . 
> > To post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at https://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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[Francois Bissey]

Autotools is nicer for a lot of things. sage does patch
to use libtools and I stayed away from that in Gentoo.
The main advantage as far as I am concerned is that it makes
it easier to produce shared libraries, correctly on a variety
of platforms. Just for linux, and OS X, you don’t strictly 
need to do that but it is a good investment in the future.

In that regard the current sage solution is a bit of a halfway point.
You really should couple it with automake and autoconf but that’s
more work.

But we should have pestered you about make/$(MAKE) a lot more
as it is a much bigger sin ;)

François

> On 11/10/2016, at 13:03, Victor Shoup  wrote:
> 
> First, you are definitely wrong about punch cards. I started programming
> with Fortran on punch cards in the 70s.
> 
> Second, a complete transition to auto tools still feels like overkill at this 
> point.
> But I agree that it could come one day.
> In any case, I am almost done with all the requested changes.
> I will follow up with a couple of quick questions, though.
> 
> On Monday, October 10, 2016 at 5:09:48 PM UTC-4, Dima Pasechnik wrote:
> 
> 
> On Monday, October 10, 2016 at 9:09:38 PM UTC+1, François wrote:
> On 11/10/16 01:58, Victor Shoup wrote: 
> > Another issue. I'm not sure if $(MAKE) is specific to gnu make or if it is 
> > universal. 
> > In general, I don't want to assume gnu. But I can certainly make this the 
> > default, 
> > and provide a config variable to override. 
> 
> I'll have another go at this when you use 
> $(MAKE) inside a makefile you are making sure 
> that the make command used is the same one that 
> you called on the initial makefile. 
> 
> As other people mentioned it enable parallel make 
> to proceed nicely, and in the case where there is 
> several make command installed on the system 
> you avoid funny things happening. I have AIX 
> system which comes with its own posix make 
> command. Something like ntl probably require 
> gmake (GNU make), calling AIX make in the 
> middle is not a good idea. 
> 
> 
> Perhaps the most natural solution would be to change NTL build system so that
> it uses the standard autotools chain (autoconf/automake etc), not only 
> libtool.
> Given that it uses very few external libraries, it ought to be an easy task.
> 
> Given that I am perhaps the only person in this thread who learned to program 
> using punch cards, 
> I am a dinosaur from an earlier period, yet, I look into the future :-)
>  
> Dima
> 
> 
> 
> 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 https://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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[Victor Shoup]

I am almost done with everything!!
I have just a couple of remaining questions.

First, I am having a hard time understanding why singular is having a hard 
time
with the definition of NTL_NEW_OP.  It is defined that way for a reason, 
and this
is completely standard C++ (standard, as in C++98).
Could somebody explain what is going on?
The suggested patch, here
https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/new_singular.patch
is not really the correct semantics.

Second, I have two questions about the libtool flags patch, here:
https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/libtool_flag.patch

First, it would seem more logical to me to have a different flag for each 
libtool mode
(i.e., compile, link, etc). That is easy enough to do. Does that seem right?
Or is one global flag OK (but it will get added to every invocation of 
libtool).

Second, in the patch, you write
   $(LINK) $(LIBTOOL_FLAGS)
whereas it seems to me more logical to put
  $(LIBTOOL_FLAGS) $(LINK)
so that the libtool flags come towards the beginning of the invocation of 
libtool.
Otherwise, these are acting more like compiler flags.

Maybe it would be much clearer if I knew what the typical use case of 
LIBTOOL_FLAGS
actually was.
Thanks!

The sooner you clarify the issues, the sooner I can release the patched up 
version.
I'm already done with all the other libtool and $(MAKE) issues.


On Monday, October 10, 2016 at 5:58:05 AM UTC-4, Jean-Pierre Flori wrote:
>
> Thanks for the hint, we are already a few versions behind.
>
> I've opened #21676 for us to update, if anyone wants to review it:
> * https://trac.sagemath.org/ticket/21676#ticket
>
> By the way we are still shipping a few patches, have a look at:
> * https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/
>
> I'd say the most annoying one is:
> * 
> https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/configure.ac
> We're just making an empty autotool project, running autoreconf, and 
> repackaging your tarball so that it provides its own version of libtool.
> (All of this is done by this script:
> * https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/spkg-src
> )
> Indeed some systems do not provide any "default" libtool script.
>
> And surely the following one is about using $MAKE rather than make in your 
> makefile:
> * 
> https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/make.patch
> Its purpose is quite obvious :)
>
> And finally, giving the ability to pass flags to libtool:
> * 
> https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/libtool_flag.patch
> This is useful when building on cygwin/mingw where libtool wants an 
> -no-undefined flag to even try to build a shared lib (without it it does 
> not even try).
>
> Best,
> JPF
>

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[Victor Shoup]

First, you are definitely wrong about punch cards. I started programming
with Fortran on punch cards in the 70s.

Second, a complete transition to auto tools still feels like overkill at 
this point.
But I agree that it could come one day.
In any case, I am almost done with all the requested changes.
I will follow up with a couple of quick questions, though.

On Monday, October 10, 2016 at 5:09:48 PM UTC-4, Dima Pasechnik wrote:
>
>
>
> On Monday, October 10, 2016 at 9:09:38 PM UTC+1, François wrote:
>>
>> On 11/10/16 01:58, Victor Shoup wrote: 
>> > Another issue. I'm not sure if $(MAKE) is specific to gnu make or if it 
>> is universal. 
>> > In general, I don't want to assume gnu. But I can certainly make this 
>> the default, 
>> > and provide a config variable to override. 
>>
>> I'll have another go at this when you use 
>> $(MAKE) inside a makefile you are making sure 
>> that the make command used is the same one that 
>> you called on the initial makefile. 
>>
>> As other people mentioned it enable parallel make 
>> to proceed nicely, and in the case where there is 
>> several make command installed on the system 
>> you avoid funny things happening. I have AIX 
>> system which comes with its own posix make 
>> command. Something like ntl probably require 
>> gmake (GNU make), calling AIX make in the 
>> middle is not a good idea. 
>>
>>
> Perhaps the most natural solution would be to change NTL build system so 
> that
> it uses the standard autotools chain (autoconf/automake etc), not only 
> libtool.
> Given that it uses very few external libraries, it ought to be an easy 
> task.
>
> Given that I am perhaps the only person in this thread who learned to 
> program using punch cards, 
> I am a dinosaur from an earlier period, yet, I look into the future :-)
>  
> Dima
>
>
>
> 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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[Dima Pasechnik]

On Monday, October 10, 2016 at 9:09:38 PM UTC+1, François wrote:
>
> On 11/10/16 01:58, Victor Shoup wrote: 
> > Another issue. I'm not sure if $(MAKE) is specific to gnu make or if it 
> is universal. 
> > In general, I don't want to assume gnu. But I can certainly make this 
> the default, 
> > and provide a config variable to override. 
>
> I'll have another go at this when you use 
> $(MAKE) inside a makefile you are making sure 
> that the make command used is the same one that 
> you called on the initial makefile. 
>
> As other people mentioned it enable parallel make 
> to proceed nicely, and in the case where there is 
> several make command installed on the system 
> you avoid funny things happening. I have AIX 
> system which comes with its own posix make 
> command. Something like ntl probably require 
> gmake (GNU make), calling AIX make in the 
> middle is not a good idea. 
>
>
Perhaps the most natural solution would be to change NTL build system so 
that
it uses the standard autotools chain (autoconf/automake etc), not only 
libtool.
Given that it uses very few external libraries, it ought to be an easy task.

Given that I am perhaps the only person in this thread who learned to 
program using punch cards, 
I am a dinosaur from an earlier period, yet, I look into the future :-)
 
Dima



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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[François Bissey]

On 11/10/16 01:58, Victor Shoup wrote:

Another issue. I'm not sure if $(MAKE) is specific to gnu make or if it is 
universal.
In general, I don't want to assume gnu. But I can certainly make this the 
default,
and provide a config variable to override.


I'll have another go at this when you use
$(MAKE) inside a makefile you are making sure
that the make command used is the same one that
you called on the initial makefile.

As other people mentioned it enable parallel make
to proceed nicely, and in the case where there is
several make command installed on the system
you avoid funny things happening. I have AIX
system which comes with its own posix make
command. Something like ntl probably require
gmake (GNU make), calling AIX make in the
middle is not a good idea.

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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[Victor Shoup]

About the make variable...  I can definitely see it's utility with make -j... I 
would guess that's the main advantage, and that's easy enough to fix in the 
makefile itself. 

The other calls to make from other scripts are a bit more problematic. Would 
you say they are a priority? And if so, would one assume that a user would set 
the environment variable MAKE? 

As I understand it, in gnuc make, the  variable MAKE is not an ordinary 
environment variable. It is a special variable with extra magic specific to 
make (including -j magic). 

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[Jean-Pierre Flori]

Hum sorry I did not read the previous  posts completely.

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[Jean-Pierre Flori]

Using MAKE also let you trigger parallel build for subtargets with MAKE="make 
-j128".
Given the current use of make within the makefile it is not really the case.

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Giving Sage AI-based step-by-step equation solving abilities

[Ted Kosan]

Matthieu wrote:

> Is this solver works only for systems of linear equations ?

The solver I am writing is based on an AI program written in the 1970s
named PRESS (PRolog Equation Solving System), and PRESS was designed
to solve R Elementary equations, which can contain polynomial,
trigonometric, exponential and logarithmic functions. I have not
implemented all of PRESS's capabilities in my solver yet, but I am in
the process of doing so.

Ted

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[Jeroen Demeyer]

On 2016-10-10 16:13, Victor Shoup wrote:

One more question, relating to $(MAKE). There are a number of scripts besides 
the makefile that also invoke make. Should these also be modified? But then the 
mechanism would have to be different (environment variable?). Before I can sort 
that out, I would like to know what is the goal here? Is system make really not 
used in some environments? Or is there some magic in $(MAKE) within a makefile 
that is being used? If the latter, then I can probably just keep the other 
invocations of make are OK as is.


In other scripts, I think that "$MAKE" is mainly used to allow using a 
different version of make. For example, some systems might have a GNU 
make (installed as gmake) and a non-GNU make (installed as make). The 
MAKE environment variable can be set to the chosen make variant.


--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[Jean-Pierre Flori]

On Monday, October 10, 2016 at 3:53:34 PM UTC+2, Victor Shoup wrote:
>
> Let me get this straight...
> You say that the tarball does not contain a libtool script, but rather, 
> contains a directory that contains files that will build a libtool script 
> at compile time. Is that right?

Which tarball?

NTL tarball does not contain anything providing libtool, it relies on the 
availibility of a systemwide one, which is not standard, but can be 
provided by installing some packages as John does. Unfortunately the 
mondane user will just feel lost and won't be able to perform this step (or 
does not want to pollute her system with yet another package).

The repackaged tarball Sage ships contains:
* the verbatim content of the NTL upstream tarball in a ntl folder,
* an additional libtool folder where you can run "./configure" to produce a 
"libtool" script. Note that all that is contained in this folder was 
produced running autoreconf on a configure.ac file on a "development" 
machine.

Then when one want to build Sage and its version of ntl on her machine, the 
"configure" script is run and produces a "libtool" script to be used by the 
compilation chain in the ntl folder.
So you could call this step configuration time or compilation time.

What is sure is that calling the "configure" script is performed on the 
machine where NTL will be compiled, not on the machine where "autoreconf" 
was run to produce "configure" and "ltmain.sh" from the quite empty 
"configure.ac".

In fact running "configure" on the "development" machine rather than on the 
"compilation" machine, maybe hoping to provide a universal libtool script, 
would be wrong.
The "configure" and "ltmain.sh" scripts made by autoreconf are meant to be 
portable, the "libtool" script they produce is much less.

So maybe the answer to your question is "yes": the best solution would be 
that the ntl upstream tarball contains waht is needed to produce the 
libtool script on the machine where ntl will be compiled.

And the answer to the question "how to produce that stuff easily and 
without changing all of ntl build system" is:
* make a quite empty autotools project, that is a configure.ac file like 
the one at:
  $ 
https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/configure.ac
* modify ntl's configure script to run the configure script that will be 
produced by autoreconf at distribution time
* modify the ntl's makefile to use the libtool script that will be produced 
by configure
* when you want to ship a new release:
  $ run autoreconf where configure.ac
  $ make your tarball

Another option would be to migrate all ntl build system to autotools but 
that would be much more time consuming... with the above steps you just 
hack to get a portable way to produce a libtool script (and not relying 
anymore on the user installing a system wide one).

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[Victor Shoup]

One more question, relating to $(MAKE). There are a number of scripts besides 
the makefile that also invoke make. Should these also be modified? But then the 
mechanism would have to be different (environment variable?). Before I can sort 
that out, I would like to know what is the goal here? Is system make really not 
used in some environments? Or is there some magic in $(MAKE) within a makefile 
that is being used? If the latter, then I can probably just keep the other 
invocations of make are OK as is.

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[Victor Shoup]

Let me get this straight...
You say that the tarball does not contain a libtool script, but rather, 
contains a directory that contains files that will build a libtool script at 
compile time. Is that right?

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[John Cremona]

On 10 October 2016 at 14:46, Victor Shoup  wrote:
> Ok, thanks. I will try to get this done this week. Your explanation was very 
> helpful. Hopefully, I can piece together a solution based on the scripts you 
> pointed to in your previous reply.
>
> I admit, I've been quite a dinosaur when it comes to autotools stuff...when I 
> started, none of this really existed, and at any particular point in time, it 
> seemed easier to "roll my own" scripts than to figure out autotools. In the 
> short term, I will probably not change too much, but I agree that this 
> libtool issue really needs to be fixed.
>

Note from another dinosaur: I have my own notes to help me install
pari, mpir, mpfr, flint and ntl on a new machine, propr to being able
to work on eclib.  And in the NTL section (only!) there's a line
(You may need to now do "sudo apt install libtool-bin")

John
> --
> 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 https://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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[Victor Shoup]

Ok, thanks. I will try to get this done this week. Your explanation was very 
helpful. Hopefully, I can piece together a solution based on the scripts you 
pointed to in your previous reply.

I admit, I've been quite a dinosaur when it comes to autotools stuff...when I 
started, none of this really existed, and at any particular point in time, it 
seemed easier to "roll my own" scripts than to figure out autotools. In the 
short term, I will probably not change too much, but I agree that this libtool 
issue really needs to be fixed.

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[Jean-Pierre Flori]

On Monday, October 10, 2016 at 2:58:38 PM UTC+2, Victor Shoup wrote:
>
> Ok, I will start working on these issues.  The one I understand the least 
> is libtool.
> It looks like you are saying I should generate a libtool script on the 
> machine X on which
> I create the NTL tarball. But this seems very strange. How could that 
> script be any better
> than one generated/installed on the machine Y where the build is taking 
> place?
> Wouldn't it be better to generate libtool on Y?
>
> And why isn't there a libtool command on Y in the first place?
> I mean, if you assume the whole autoconf toolchain, why not assume libtool?
>
That's the point: you should not assume any part of the autotools chain 
present, that's not needed nor the way it is supposed to be used.
Autotools is a great way to autogenerate boring stuff as conifgure scripts 
and Makefiles.
So it is meant to be run on the developer machine and what it generates 
(typically: configure script from configure.ac, Makefile.in form 
Makefile.am, some m4 macro stuff, and a ltmain.sh script which will be used 
to generate the libtool script!) is supposed to be portable enough, shipped 
with the distributed tarball, and should run with no issues on the machine 
where NTL actually gets compiled.

For example, have a look at the gmp "devel" source tree:
https://gmplib.org/repo/gmp/file/tip
There is only (among related stuff) a configure.ac file at the top level 
and Makefile.am files in subdirectories.

But in the "distributed" source tarball where "autoreconf -fiv" or 
equivalent stuff has been run also includes configure, ltmain.sh and so on.

To come back to NTL, you only used the libtool script, you don't need all 
the autotools machinery, but you currently assume that this script is 
available system wide, which is not that common.

So what we do in Sage is the following at distribution time:
* create a fake autotools project (mostly a quite empty configure.ac file)
* run autoreconf on it which produces mainly a configure script, an 
ltmain.sh script and a few other things.
* include its output along with your source in a separate libtool directory

At compilation time:
* we go into this libtool directory and run the configure script which uses 
ltmain.sh and makes a libtool script
* we go back to ntl directory and run make passing the generated libtool 
script to it (through LIBTOOL envvar).

It looks a little bit overkill but that's the way autotools stuff works...
Note that the configure script generated here does almost nothing, mostly 
only creating the libtool script on the compilation machine!
And that's the only thing we need to build ntl.

Or, is it that maybe there are parts of the toolchain that are X but not Y?
>
> Sorry...I'm not much of an expert on libtool or autoconf.
>
 

> Another issue. I'm not sure if $(MAKE) is specific to gnu make or if it is 
> universal.
> In general, I don't want to assume gnu. But I can certainly make this the 
> default,
> and provide a config variable to override.
>
I cannot answer on the top of my head, so it might be broken with some 
strange make versions :) 

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[Victor Shoup]

Ok, I will start working on these issues.  The one I understand the least is 
libtool.
It looks like you are saying I should generate a libtool script on the machine 
X on which
I create the NTL tarball. But this seems very strange. How could that script be 
any better
than one generated/installed on the machine Y where the build is taking place?
Wouldn't it be better to generate libtool on Y?

And why isn't there a libtool command on Y in the first place?
I mean, if you assume the whole autoconf toolchain, why not assume libtool?
Or, is it that maybe there are parts of the toolchain that are X but not Y?

Sorry...I'm not much of an expert on libtool or autoconf.

Another issue. I'm not sure if $(MAKE) is specific to gnu make or if it is 
universal.
In general, I don't want to assume gnu. But I can certainly make this the 
default,
and provide a config variable to override.

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Is Brown's construction available in the graph component of sagemath?

[Dima Pasechnik]

On Sunday, October 9, 2016 at 9:10:50 PM UTC, ni732...@gmail.com wrote:
>
> Brown's construction is the function which takes a finite field to a graph 
> with diameter 2.
> http://www.emis.ams.org/journals/EJC/Surveys/ds14.pdf
>
> Is it available in the graph component of sagemath?
>

I won't be surprised if it could be constructed as a subgraph of one of 
many strongly regular graphs
known to Sage, but there is no direct way to build such a graph in Sage, 
IMHO.

The description of the adjacency in the link you provide is a bit too brief 
to see what exactly it does, 
but I think these graphs are also known as  Erdős–Rényi graphs, from 
P. Erdós, A. Rényi, V.T. Sós
On a problem of graph theory
Studia Sci. Math. Hungar., 1 (1966), pp. 215–235

Brown's paper was published in the same year: W.G. Brown
On graphs that do not contain a Thomsen graph
Canad. Math. Bull., 9 (1966), pp. 281–285

We published a paper where these graphs were considered, and I implemented
a construction of them in GAP, but not in Sage :-)
https://www.cs.ox.ac.uk/publications/publication7266-abstract.html

Please feel free to cc me on the Sage ticket with an implementation, I'd be 
glad to review it.

Dima
 

> If not, I plan to implement it for sagemath.
>
> yawara
>

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Is Brown's construction available in the graph component of sagemath?

[David Joyner]

On Sun, Oct 9, 2016 at 4:59 PM,   wrote:
> Brown's construction is the function which takes a finite field to a graph
> with diameter 2.
> http://www.emis.ams.org/journals/EJC/Surveys/ds14.pdf
>
> Is it available in the graph component of sagemath?


I don't know but the Paley graph construction is in Sage. Is that
related to what you are talking about? You might look in the
graphs/generators/families.py module.


> If not, I plan to implement it for sagemath.
>
> yawara
>
> --
> 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 https://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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: a 7(!) year old (Singular) overflow issue still holds

[Dima Pasechnik]

On Sunday, October 9, 2016 at 4:48:31 PM UTC, Bill Hart wrote:
>
>
>
> On Sunday, 9 October 2016 18:08:29 UTC+2, Dima Pasechnik wrote:
>>
>>
>>
>> On Sunday, October 9, 2016 at 3:35:57 PM UTC, Bill Hart wrote:
>>>
>>> By default, Singular uses 16 bit exponents. But it is perfectly capable 
>>> of working with exponents up to 64 bits. That will be slower of course.
>>>
>>> why? I presume arithmetic on 16-bit integers is not faster than on 
>> 32-bit, or even 64-bit.
>>
>
> It's the exponent arithmetic, not the coefficients we are talking about.
>
 
sure - I was thinking about univariate case; in the multivariate case, if 
you want fast arithmetic on exponents of monomials given as integer vectors 
in year 2016, you probably would want to use GPU 


> The exponents are packed, with four 16 bit field in a 64 bit word. This is 
> *much* faster. I use the same trick, as does just about every decent 
> computer algebra system out there.
>
> Interestingly, Magma only allows exponents up to about 30 bits, but it 
> takes a few minutes to compute x^(2^30 - 1).
>

I wonder why this happens - a Flint issue? :

sage: R.=QQ[]
sage: x^(2^30)-1
Exception (FLINT memory_manager). Unable to allocate memory.

sage: x^(2^30-1)
Killed

(which appears to indicate that the recovery from the exception was not 
complete)

On the other hand:

sage: timeit('x^(2^20-1)')
125 loops, best of 3: 1.66 ms per loop
sage: 2^20-1
1048575
sage: timeit('x^1048575')
125 loops, best of 3: 1.66 ms per loop
sage: timeit('x^10')
625 loops, best of 3: 381 ns per loop
sage: 2^30-1
1073741823
sage: timeit('x^1073741823')
5 loops, best of 3: 1.72 s per loop
sage: timeit('x^(2^30-1)')
5 loops, best of 3: 1.71 s per loop

but then

sage: x^(2^30-1)



 looks quite  strange...
Dima

 
>
>>  
>>  
>>
>>> I guess it isn't easy for Sage to change the relevant ring upon overflow 
>>> to one using 64 bit exponents.
>>>
>>> I can't say whether it would be easy or hard for Singular to 
>>> automatically change the exponent size for you. For basic arithmetic, I 
>>> have implemented precisely this in the code I've been writing. But Singular 
>>> is almost infinitely more complex than the very simple cases I've been 
>>> dealing with in my own code. At this stage I couldn't even hazard a guess.
>>>
>>> I'll ask Hans if I remember. But either way, I believe this would be an 
>>> *extremely* time consuming thing to fix. How important is it?
>>>
>>> Bill.
>>>
>>> On Wednesday, 5 October 2016 01:10:31 UTC+2, Jakob Kroeker wrote:


 https://trac.sagemath.org/ticket/6472

 even for recent singular upgrade 

 https://trac.sagemath.org/ticket/17254

 and it was not(?) reported to upstream...
















-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Giving Sage AI-based step-by-step equation solving abilities

[Matthieu Dien]

Hello Ted,

Is this solver works only for systems of linear equations ?
If it is the case, why do you need an AI ? Is a standard Gauss algorithm
not sufficient ?

Cheers

Matthieu


2016-10-09 20:40 GMT+02:00 David Joyner :

> On Sun, Oct 9, 2016 at 2:20 PM, Ted Kosan  wrote:
> > David wrote:
> >
> >> I think a graphical version of this would be useful as a sage-based
> >> online high school math tutorial program, such as the khan academy
> >> algebra modules.
> >
> > Are either of the following examples close to what you have in mind?:
> >
> > http://data.ssucet.org/temp/solve_steps_example.png
> >
>
> This doesn't seem to have anything.
>
> > https://www.youtube.com/watch?v=cy6bwNBkAK0
> >
>
> Not quite. I'm just talking about an automated system to help a create
> student hint (like webassign has). A student goes through a khan
> academy assignment, gets stuck, and they click a "help" button (which
> would then call your program to create a series of graphics) to see
> how a similar problem is solved step-by-step.
>
> > Ted
> >
> >
> >
> > --
> > 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 https://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 https://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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL v10

[Jean-Pierre Flori]

Thanks for the hint, we are already a few versions behind.

I've opened #21676 for us to update, if anyone wants to review it:
* https://trac.sagemath.org/ticket/21676#ticket

By the way we are still shipping a few patches, have a look at:
* https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/

I'd say the most annoying one is:
* 
https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/configure.ac
We're just making an empty autotool project, running autoreconf, and 
repackaging your tarball so that it provides its own version of libtool.
(All of this is done by this script:
* https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/spkg-src
)
Indeed some systems do not provide any "default" libtool script.

And surely the following one is about using $MAKE rather than make in your 
makefile:
* 
https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/make.patch
Its purpose is quite obvious :)

And finally, giving the ability to pass flags to libtool:
* 
https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/libtool_flag.patch
This is useful when building on cygwin/mingw where libtool wants an 
-no-undefined flag to even try to build a shared lib (without it it does 
not even try).

Best,
JPF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.