Re: [sage-devel] Error building deformation and libsemigroups 0.6.7

Fix for deformation has been tagged in my fork. And mentioned here: https://trac.sagemath.org/ticket/30325 Feel free to package and review. Not sure that it supports GMP instead of MPIR (which is also abandonware). Le jeudi 22 avril 2021 à 17:44:39 UTC+2, dim...@gmail.com a écrit : > errors

Re: [sage-devel] Re: Sage 9.2 does not works in macos Big Sur

I found the Mac app quite useful now I use Mac and don't have the time to build Sage anymore :( Le samedi 7 novembre 2020 à 09:20:14 UTC+1, dim...@gmail.com a écrit : > On Fri, Nov 6, 2020 at 9:50 PM Matthias Koeppe > wrote: > > > > On Friday, November 6, 2020 at 12:50:01 PM UTC-8, kcrisman

[sage-devel] Re: Valgrind - how to?

On Wednesday, February 13, 2019 at 8:44:07 AM UTC+1, Simon King wrote: > > Hi again, > > On 2019-02-12, Simon King > wrote: > > If I recall correctly, valgrind would be able to report leaking memory. > > But how to use it in Sage? > > > > I guess `sage -i valgrind` is the first step. But

[sage-devel] Re: Weak references in the coercion model

You should surely be able to extract some info in this ticket where we fought hard memory leaks: https://trac.sagemath.org/ticket/715 Maybe comment 75 though I did not really go through the whole ticket: https://trac.sagemath.org/ticket/715#comment:75 -- You received this message because you

Re: [sage-devel] A Sage interface for FGb (Gröbner bases)

For GB addict, yet another open source implementation: https://gforge.inria.fr/projects/tinygb/ -- 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] Re: zn_poly status?

On Monday, September 10, 2018 at 2:34:06 PM UTC+2, Erik Bray wrote: > > On Mon, Sep 10, 2018 at 1:43 PM 'Bill Hart' via sage-devel > > wrote: > > > > NTL is your best best. However zn_poly is a tour de force. It would be > hard to beat. > IIRC it's very hardcoded into hypellfrob

Re: [sage-devel] Re: Product of two expressions that causes hang

It might be an issue with the "printing" order which is used to sort stuff in pynac internally (but not in orignal ginac) and we already had issues with in the past. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group

[sage-devel] Re: Product of two expressions that causes hang

Ok I finally ended up in pynac code. It seems there is a bad recursion happening, with the following reversed backtrace: (Sage.)Expression._mul_ Ginac::* Ginac::exmul Ginac::ex::ex Ginac::ex::construct_from_basic Ginac::mul::eval Ginac::ex::ex Ginac::ex::construct_from_basic Ginac::mul::eval ...

[sage-devel] Re: Product of two expressions that causes hang

Kind of strange, running sage -gdb I never end up in Expression._mul_ but at random places in Python code. On Tuesday, April 24, 2018 at 2:40:50 PM UTC+2, Frédéric Chapoton wrote: > > Amusing.. Also hangs on > > sage: (1/e1)/e2 > 1/2*sqrt(2)/((I - 1)*sqrt(2) - 2) > sage: 1/_ > > > Le mardi 24

[sage-devel] Re: PY_NEW(Integer) and Integer.__new__(Integer)

I thought PY_NEW was to be avoided (except for classes overriding tp_new). See https://trac.sagemath.org/ticket/17668 and https://github.com/cython/cython/wiki/FAQ#can-cython-create-objects-or-apply-operators-to-locally-created-objects-as-pure-c-code On Sunday, April 8, 2018 at 9:41:17 AM UTC+2,

[sage-devel] Re: [sage-support] Re: Has Big-Endian support been deprecated yet?

I have (or used to have) access to a power 7 machine and so did Francois Bissey IIRC. Things were in quite good shape there. On Wednesday, March 14, 2018 at 1:52:07 PM UTC+1, Dima Pasechnik wrote: > > On Wednesday, March 14, 2018 at 6:42:33 AM UTC, vdelecroix wrote: >> >> As mentioned on the

[sage-devel] Re: 6 hours left to prepare GSoC application for this year!

I've added a project from last year that Johan and I were ok to mentor. Don't know about Johan's availability this year so if anyone is ready to comentor with me (and even take the lead) that would be nice. On Tuesday, January 23, 2018 at 10:29:34 AM UTC+1, Dima Pasechnik wrote: > > Are we

[sage-devel] Re: Getting rid of the pickle jar

Remove it. -- 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

Re: [sage-devel] A couple R tickets need review.

Note that we don't disable https support, we just let R compile it is not available... -- 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] Re: Sage packaging template

On Monday, September 11, 2017 at 3:40:41 PM UTC+2, Maarten Derickx wrote: > > On Mon, 11 Sep 2017 at 10:30 Jean-Pierre Flori <jpf...@gmail.com > > wrote: > >> >> I've made a pull request at >> https://github.com/mmasdeu/sage_package_template/pull/3 with so

[sage-devel] Re: Sage sample / sage packaging template

On Sunday, September 10, 2017 at 1:54:44 PM UTC+2, Maarten Derickx wrote: > > Changed the subject to not clutter Davids thread. > > > > On Sunday, 10 September 2017 12:01:51 UTC+2, Jeroen Demeyer wrote: >> >> On 2017-09-10 06:09, Maarten Derickx wrote: >> > I plan to work on

[sage-devel] Re: Some polynomial timings

Sure giac would be good as well! -- 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

Re: [sage-devel] Does anyone use SAGE64?

On Monday, September 4, 2017 at 6:06:35 PM UTC+2, Jean-Pierre Flori wrote: > > I would also say that passing -m64 is needed on Solaris even when the > kernel is 64bits, and I think the situation is the same on linux running on > sparc. > On these platforms default versions of

Re: [sage-devel] Does anyone use SAGE64?

I would also say that passing -m64 is needed on Solaris even when the kernel is 64bits, and I think the situation is the same on linux running on sparc. On these platforms default versions of gcc produces 32 bits stuff by default, unless you begin compiling your own gcc and convince it to do

[sage-devel] Re: Some polynomial timings

Anyway we should definitely get some multivariate polynomial arithmetic over Z based on flint and keep singular for groebner bases or things it is meant for. On Monday, September 4, 2017 at 7:13:59 AM UTC+2, parisse wrote: > > > > Le dimanche 3 septembre 2017 16:06:46 UTC+2, rjf a écrit : >> >>

Re: [sage-devel] Template (cookiecutter) for easily distributing SageMath code

Oh and the MANIFEST.in file is not quite good at the moment. You could add pxd files in there. On Wednesday, August 23, 2017 at 2:57:03 PM UTC-7, Jean-Pierre Flori wrote: > > Yes! > I support this :) > > My only suggestion would be to get rid of using the travis command. &

Re: [sage-devel] Template (cookiecutter) for easily distributing SageMath code

Yes! I support this :) My only suggestion would be to get rid of using the travis command. And maybe move the get_all_version_names into the fake sagemath package. On Wednesday, August 23, 2017 at 2:45:18 PM UTC-7, Marc Masdeu wrote: > > This is essentially what they are supposed to be. The main

Re: [sage-devel] Re: Conda package for Sage

On Thursday, June 15, 2017 at 2:31:58 PM UTC+2, William wrote: > > > (but 1st thing 1st, let's start from the current version being >>> well-supported...) >>> >> Or rather let's find someone from ODK willing to buy the hardware! >> >> (Next we could buy some sparc and itanium CPUs and Solaris

Re: [sage-devel] Re: Conda package for Sage

On Thursday, June 15, 2017 at 12:13:20 PM UTC+2, Dima Pasechnik wrote: > > > > On Thursday, June 15, 2017 at 11:03:11 AM UTC+1, Erik Bray wrote: >> >> On Thu, Jun 15, 2017 at 11:49 AM, Dima Pasechnik >> wrote: >> > https://www.apple.com/fr/shop/buy-mac/mac-pro >> > >> > I

Re: [sage-devel] Re: Conda package for Sage

On Thursday, June 15, 2017 at 8:29:37 AM UTC+2, Dima Pasechnik wrote: > > problem is, Apple headless hardware range currently available consists of > Mac Mini's, which are very much underpowered. > > they promise something better in Dec. > > Internet is offering details on how to hack OSX to

Re: [sage-devel] Re: segfault (involving flint, libthread, randstate)

Here's the bt for the latter example: #0 visit_decref (op=0xfdc9906aac2f2efe, data=0x0) at Modules/gcmodule.c:360 #1 0x3fffad7f61e0 in __pyx_tp_traverse_4sage_4misc_9randstate_randstate ( o=0x3ffb1a37c5d0, v=@0x3fffb7f62aa8: 0x3fffb7eb91d0 , a=0x0) at

[sage-devel] Re: Sage on Cygwin status update

Good job! -- 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] Re: state of the art for sparse rational linear systems

On Tuesday, April 4, 2017 at 4:02:46 PM UTC+2, vdelecroix wrote: > > Dear all, > > I am currently solving huge sparse linear systems over rationals (up to > millions of equations and variables). The equation are actually > integral, but the solutions are rationals. > > Sage is doing pretty

[sage-devel] Re: GSoC 2017 accepted SageMath

Thanks Harald. I did not realize so many of them were for my project. I only saw one and it was junk. I'll check the other ones but have little hope. Hopefully other mentors will be much luckier! -- You received this message because you are subscribed to the Google Groups "sage-devel" group.

Re: [sage-devel] Too many Maximas!

Our pexpect interface happily leaves zombies around on linux because it never waits on the processes it forks. At least for each instantiation of the pexpect class it tries to launch sage-cleaner to have at least one instance running and only the first does actual work, the other ones becoming

[sage-devel] Did anyone test latest Sage versions inculding giac on non-x86_64 64 bit systems?

On a POWER7 (ppc64), giac looks very broken in the spirit of: * http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=19=1723 I've opened: * https://trac.sagemath.org/ticket/22280 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from

Re: [sage-devel] Problem building GSL in cygwin64

The LDConvert error must be some LongDouble stuff not guarded correctly with #if HAS_LONG_DOUBLE (or a variation thereof). Cygwin does not provide these. It should be reported upstream. Actually we have a trac ticket and that has been reported upstream: https://trac.sagemath.org/ticket/21690 On

[sage-devel] Re: Suggestion for GSoC project: Polynomials - Rewriting and relinking

On Friday, January 20, 2017 at 11:03:52 AM UTC+1, Johan S. H. Rosenkilde wrote: > > Hi sage-devel, > > Our current polynomial implementation has severe issues: > > - Our speed for GF(2^e)[x] is abysmal. > > - For other cases we are probably not linking to the currently fastest >

Re: [sage-devel] Re: R fails to compile

On Wednesday, January 18, 2017 at 7:36:37 PM UTC+1, Emmanuel Charpentier wrote: > > It also used to build pcre, an lzma library and SSL tools. No longer since > 3.3, which is an itch I tried to scratch for 8 months... Hence also my > insistence on the SSL tragicomedy. > No I mean Sage itself!

[sage-devel] Re: R fails to compile

Strange, Sage used to optionally build iconv on retarded systems. On Wednesday, January 18, 2017 at 2:22:47 PM UTC+1, Emmanuel Charpentier wrote: > > Forgot to add : ISTR that R has depended on an external iconv for a long > while. I didn't see it would now be mandatory... > > -- > Emmanuel

Re: [sage-devel] Re: releasing memory in compiled components

On Monday, January 9, 2017 at 10:33:49 PM UTC+1, Jeroen Demeyer wrote: > > On 2017-01-09 16:45, Jean-Pierre Flori wrote: > > I guess you want to free the memory allocated here: > > * > > > https://github.com/sagemath/sage/blob/master/src/sage/l

[sage-devel] Re: releasing memory in compiled components

On Monday, January 9, 2017 at 7:03:57 PM UTC+1, Volker Braun wrote: > > On Monday, January 9, 2017 at 4:45:19 PM UTC+1, Jean-Pierre Flori wrote: >> >> You can just use the Python "del" operator and Cython should translate it >> to a destructor call. >> &g

[sage-devel] Re: releasing memory in compiled components

I guess you want to free the memory allocated here: * https://github.com/sagemath/sage/blob/master/src/sage/libs/eclib/newforms.pyx#L112 You should add a __dealloc__ method to your class and free the memory there: *

[sage-devel] Re: denominator() hangs on a large fraction

On Thursday, January 5, 2017 at 8:01:42 AM UTC+1, Ralf Stephan wrote: > > There was a bug in the Pynac/Singular interface. To cancel fractions > a GCD is done via Singular. This was fixed 7 days ago in > > https://github.com/pynac/pynac/commit/fd180a9a82018e97c540950c1bbf083768f703ef > and the

Re: [sage-devel] cysignal, python signal module, and alarm functions

On Sunday, December 25, 2016 at 8:22:33 PM UTC+1, Jeroen Demeyer wrote: > > On 2016-12-25 12:55, Jean-Pierre Flori wrote: > > > > > > On Sunday, December 25, 2016 at 10:32:11 AM UTC+1, Jeroen Demeyer wrote: > > > > On 2016-12-24 13:30, Jean-Pierre

Re: [sage-devel] cysignal, python signal module, and alarm functions

On Sunday, December 25, 2016 at 10:32:11 AM UTC+1, Jeroen Demeyer wrote: > > On 2016-12-24 13:30, Jean-Pierre Flori wrote: > > I just want to kill Magma > > M.quit() should work. > Sure, but how do I trigger a call to M.quit() iin the middle of a long computatio

Re: [sage-devel] cysignal, python signal module, and alarm functions

On Saturday, December 24, 2016 at 11:00:33 AM UTC+1, Jeroen Demeyer wrote: > > On 2016-12-24 10:37, Jean-Pierre Flori wrote: > > My issue is that I can not use the alarm() machinery to trigger it... > > I do not understand why you would want to use alarm() to kill magma

Re: [sage-devel] cysignal, python signal module, and alarm functions

On Saturday, December 24, 2016 at 10:22:13 AM UTC+1, Jeroen Demeyer wrote: > > On 2016-12-23 21:49, Jean-Pierre Flori wrote: > > > > > > On Friday, December 23, 2016 at 9:10:53 PM UTC+1, Jeroen Demeyer wrote: > > > > On 2016-12-23 10:34, Jean-P

Re: [sage-devel] cysignal, python signal module, and alarm functions

On Friday, December 23, 2016 at 9:10:53 PM UTC+1, Jeroen Demeyer wrote: > > On 2016-12-23 10:34, Jean-Pierre Flori wrote: > > Maybe the code in sage/except.py should at least be modified not to > > modify the class of the exception. > > I guess you are talking a

[sage-devel] Re: converting different C/C++ types/classes

On Wednesday, December 21, 2016 at 7:10:35 PM UTC+1, John Cremona wrote: > > Is there a list somewhere of which C or C++ types or classes can be > converted in cython files? > > For example, in the eclib interface (in sage/libs/eclib) a lot of > quite complicated C++ classes defined in eclib

Re: [sage-devel] cysignal, python signal module, and alarm functions

On Friday, December 23, 2016 at 7:58:11 AM UTC+1, Jeroen Demeyer wrote: > > On 2016-12-22 11:25, Jean-Pierre Flori wrote: > > Dear all, > > > > First question: Is there are fundamental differences btw using the > > cysignal alarm function and the one from the si

[sage-devel] cysignal, python signal module, and alarm functions

Dear all, First question: Is there are fundamental differences btw using the cysignal alarm function and the one from the signal module? Second question: Is there any reason to make AlarmInterrupt derive from KeyboardInterrupt? SIGALARM and SIGINT are different signals. And its troublesome

[sage-devel] Re: Sage for Windows installer (take 2)

On Wednesday, December 7, 2016 at 8:09:56 PM UTC+1, Jean-Pierre Flori wrote: > > > > On Wednesday, December 7, 2016 at 7:34:01 PM UTC+1, William wrote: >> >> Worked for me -- I installed Windows into a VM, then ran Erik's >> installer, and it worked. >> >

[sage-devel] Re: Sage for Windows installer (take 2)

On Wednesday, December 7, 2016 at 7:34:01 PM UTC+1, William wrote: > > Worked for me -- I installed Windows into a VM, then ran Erik's installer, > and it worked. > Ahah that's exactly how I used to work on Sage on Cygwin: from a Windows VM on top of Linux! -- You received this message

Re: [sage-devel] SAGE_ATLAS_LIB vs openblas

On Friday, December 2, 2016 at 9:38:01 AM UTC+1, François wrote: > > > > On 2/12/2016, at 21:30, Jean-Pierre Flori <jpf...@gmail.com > > wrote: > > > > > > > > On Friday, December 2, 2016 at 9:24:16 AM UTC+1, François wrote: > &g

Re: [sage-devel] SAGE_ATLAS_LIB vs openblas

On Friday, December 2, 2016 at 9:24:16 AM UTC+1, François wrote: > > > > On 2/12/2016, at 21:21, Thierry > wrote: > > > > Hi, > > > > the SAGE_ATLAS_LIB stuff, which allowed to use system blas belongs to > > SAGE_ROOT/build/pkgs/atlas/spkg-install Is it

Re: [sage-devel] Re: OpenSSL as a new systemwide Sage dependency ?

On Thursday, December 1, 2016 at 11:47:40 PM UTC+1, Volker Braun wrote: > > On Linux, you can build Sage with and without openssl. If you ever hit the > network you really should build with openssl(-devel) available, it will be > picked up automatically. But its not a requirement. Though we

Re: [sage-devel] Update CDDLIB source package? (was: What is the correct way to patch packages that use autotools?)

On Wednesday, November 23, 2016 at 12:24:43 PM UTC+1, Erik Bray wrote: > > On Wed, Nov 23, 2016 at 12:19 PM, Jean-Pierre Flori <jpf...@gmail.com > > wrote: > > > > > > On Wednesday, November 23, 2016 at 12:17:08 PM UTC+1, Jean-Pierre Flori > > wrote:

Re: [sage-devel] Update CDDLIB source package? (was: What is the correct way to patch packages that use autotools?)

On Wednesday, November 23, 2016 at 12:17:08 PM UTC+1, Jean-Pierre Flori wrote: > > We should definitely contact upstream if updating the autotools stuff > there is needed. > But do they ship autotools stuff or does it come from Sage? Old tickets: * https://trac.sagemath.org/

Re: [sage-devel] Update CDDLIB source package? (was: What is the correct way to patch packages that use autotools?)

We should definitely contact upstream if updating the autotools stuff there is needed. -- 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] Re: Checking out old branches

On Friday, November 18, 2016 at 8:12:32 AM UTC+1, David Roe wrote: > > If I checkout an old branch (say, from one or two versions of Sage ago), > it essentially forces a rebuild of all of Sage, even if I think better of > it and checkout develop immediately. The rebuild is a consequence of

Re: [sage-devel] Re: What is the correct way to patch packages that use autotools?

On Thursday, November 17, 2016 at 5:27:15 PM UTC+1, Erik Bray wrote: > Hmm, okay. I am using my system's autoreconf. For the sage autotools > is that just an optional package I need to install? > Yes. -- You received this message because you are subscribed to the Google Groups

[sage-devel] Re: What is the correct way to patch packages that use autotools?

On Thursday, November 17, 2016 at 5:26:39 PM UTC+1, Jean-Pierre Flori wrote: > > > > On Thursday, November 17, 2016 at 5:25:24 PM UTC+1, Jean-Pierre Flori > wrote: >> >> >> >> On Thursday, November 17, 2016 at 5:11:23 PM UTC+1, Erik Bray wrote:

[sage-devel] Re: What is the correct way to patch packages that use autotools?

On Thursday, November 17, 2016 at 5:25:24 PM UTC+1, Jean-Pierre Flori wrote: > > > > On Thursday, November 17, 2016 at 5:11:23 PM UTC+1, Erik Bray wrote: >> >> Hi, >> >> I'm in the process of patching a couple spkgs that use autotools build >> sy

[sage-devel] Re: What is the correct way to patch packages that use autotools?

On Thursday, November 17, 2016 at 5:11:23 PM UTC+1, Erik Bray wrote: > > Hi, > > I'm in the process of patching a couple spkgs that use autotools build > systems. I've done this in the past in Sage but it's never been quite > clear to me what the correct process should be. In this

[sage-devel] Singular "share" files

Dear all, We currently repackage singular so merge the source code and help files into a single archive (and renaming directories). Should we stop doing so by creating a "singular_share" package for the latter files? Best, JPF -- You received this message because you are subscribed to the

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

vote on the I-II block (which *is* urgent), and on the Ia > vs Ib alternative ? > > HTH, > > -- > Emmanuel Charpentier > > Le jeudi 27 octobre 2016 10:03:03 UTC+2, Jean-Pierre Flori a écrit : >> >> Hi all, >> >> The latest R versions depends o

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

On Friday, October 28, 2016 at 3:58:42 PM UTC+2, Volker Braun wrote: > > I think you are making it more difficult than it is. I'm pretty sure our > binaries already depend on openssl being installed, and we do this under > the GPL system library exception. We just can't ship our own openssl

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

On Friday, October 28, 2016 at 12:33:42 PM UTC+2, Emmanuel Charpentier wrote: > > I just checked (by installation on a virtual machine) that a *virgin* > (base + destktop + usual utilities) debian stable (jessie) has openssl > installed. Tentatively asking for its removal (apt-get remove -s

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

On Thursday, October 27, 2016 at 8:15:38 PM UTC+2, kcrisman wrote: > > > So either they will stop distribute R or they will patch >>> en-masse. >>> >> >> Somehow, I doubt it. >> >> > Probably nobody even bothered to notice or notify e.g. Debian? > > I think people at Debian ar well aware of

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

On Thursday, October 27, 2016 at 5:28:41 PM UTC+2, William wrote: > > On Thu, Oct 27, 2016 at 8:25 AM, Jean-Pierre Flori <jpf...@gmail.com > > wrote: > > > > > > On Thursday, October 27, 2016 at 5:16:02 PM UTC+2, Jean-Pierre Flori > wrote: > >&

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

On Thursday, October 27, 2016 at 5:23:58 PM UTC+2, William wrote: > > Hi, > > > > We've been down this road before with Sage, and it's pretty annoying. > I've personally wasted hundreds of hours on it (GNUtls, openssl, etc.) > Programmers playing lawyers have ended up with a broken and >

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

On Thursday, October 27, 2016 at 5:16:02 PM UTC+2, Jean-Pierre Flori wrote: > > But you're right, by default Debian links to openssl: > https://packages.debian.org/sid/libcurl3 > > And indeed curl is not GPL anyway: > https://curl.haxx.se/docs/copyright.html >

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

On Thursday, October 27, 2016 at 5:18:40 PM UTC+2, Emmanuel Charpentier wrote: > > > > Le jeudi 27 octobre 2016 17:00:05 UTC+2, Jean-Pierre Flori a écrit : >> >> >> >> On Thursday, October 27, 2016 at 4:59:02 PM UTC+2, Jean-Pierre Flori >> wrote: >

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

But you're right, by default Debian links to openssl: https://packages.debian.org/sid/libcurl3 And indeed curl is not GPL anyway: https://curl.haxx.se/docs/copyright.html Groumpf. See https://curl.haxx.se/legal/distro-dilemma.html for more rumbling. Now what if a GPL application links to

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

On Thursday, October 27, 2016 at 4:59:02 PM UTC+2, Jean-Pierre Flori wrote: > > > > On Thursday, October 27, 2016 at 4:49:23 PM UTC+2, Emmanuel Charpentier > wrote: >> >> >> >> Le jeudi 27 octobre 2016 16:04:52 UTC+2, Jean-Pierre Flori a écrit : >&g

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

On Thursday, October 27, 2016 at 4:49:23 PM UTC+2, Emmanuel Charpentier wrote: > > > > Le jeudi 27 octobre 2016 16:04:52 UTC+2, Jean-Pierre Flori a écrit : >> >> >> >> On Thursday, October 27, 2016 at 3:59:26 PM UTC+2, Emmanuel Charpentier >> wrote: &

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

On Thursday, October 27, 2016 at 3:59:26 PM UTC+2, Emmanuel Charpentier wrote: > > > > Le jeudi 27 octobre 2016 13:10:17 UTC+2, François a écrit : >> >> It is a most interesting point because it explain why >> the R binary installed from epel for RH7.1 and family >> isn’t linked to openssl.

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

Building R against a ssl-less libcurl works (modulo patching configure) and does not seem to add errors into R's test suite. So I suggest the following: [123]: * add curl as a standard package and let it use ssl if present except when making dist tarballs (ticket needs some tweaking in case of

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

t; install.package(“$some_package”,method=“$somemethod”) >> where $somemethod is CURL (command line) or WGET has disappeared. >> The R-3.2.1 package for RH7.1/centos7.1 is not compiled against libcurl >> or lack https support for example. An inter

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

On Thursday, October 27, 2016 at 12:02:42 PM UTC+2, Jeroen Demeyer wrote: > > On 2016-10-27 11:49, Jean-Pierre Flori wrote: > > > > > > On Thursday, October 27, 2016 at 11:41:20 AM UTC+2, Jeroen Demeyer > wrote: > > > > On 2016-10-27 11:29, Franc

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

On Thursday, October 27, 2016 at 11:41:20 AM UTC+2, Jeroen Demeyer wrote: > > On 2016-10-27 11:29, Francois Bissey wrote: > > R package system include downloading facility from repositories. > > That's fine but it should be possible to just run R without it's > packaging system. > Then I

[sage-devel] R 3.3.1 depends on a SSL/TLS implementation

Hi all, The latest R versions depends on libcurl and actually more than that: on a libcurl with https support. So we might want to build our own libcurl with https support (see #21767) but we then need an SSL/TLS implementation which Sage curretnly provides only optionally through openSSL

[sage-devel] Re: Can we depend on system's utilities and libraries ?

Sure. What you uncovered here is larger than R. -- 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,

Re: [sage-devel] add curl as a standard package

There is a curl-config utility. -- 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] Re: add curl as a standard package

On Wednesday, October 26, 2016 at 3:45:02 PM UTC+2, Volker Braun wrote: > > On Wednesday, October 26, 2016 at 2:40:42 AM UTC-4, Emmanuel Charpentier > wrote: >> >> This issue is *distinct* from the one I'm trying to solve (iL e. satisfy >> R's prerequisites). Should't you open a relevant

[sage-devel] Re: Can we depend on system's utilities and libraries ?

On Wednesday, October 26, 2016 at 3:01:48 PM UTC+2, Jean-Pierre Flori wrote: > > > > On Wednesday, October 26, 2016 at 2:58:44 PM UTC+2, Jean-Pierre Flori > wrote: >> >> >> >> On Wednesday, October 26, 2016 at 2:22:45 PM UTC+2, Jean-Pierre Flori >>

[sage-devel] Re: Can we depend on system's utilities and libraries ?

On Wednesday, October 26, 2016 at 2:58:44 PM UTC+2, Jean-Pierre Flori wrote: > > > > On Wednesday, October 26, 2016 at 2:22:45 PM UTC+2, Jean-Pierre Flori > wrote: >> >> >> >> On Wednesday, October 26, 2016 at 2:08:25 PM UTC+2, Emmanuel Charpentier &

[sage-devel] Re: Can we depend on system's utilities and libraries ?

On Wednesday, October 26, 2016 at 2:22:45 PM UTC+2, Jean-Pierre Flori wrote: > > > > On Wednesday, October 26, 2016 at 2:08:25 PM UTC+2, Emmanuel Charpentier > wrote: >> >> >> >> Le mercredi 26 octobre 2016 13:40:14 UTC+2, Jean-Pierre Flori a écrit : &g

[sage-devel] Re: Can we depend on system's utilities and libraries ?

On Wednesday, October 26, 2016 at 2:08:25 PM UTC+2, Emmanuel Charpentier wrote: > > > > Le mercredi 26 octobre 2016 13:40:14 UTC+2, Jean-Pierre Flori a écrit : >> >> It would be great to let the user choose when to use system libraries >> instead of building ou

[sage-devel] Re: Can we depend on system's utilities and libraries ?

As far as dependency tracking is concerned we could use the "need_to_install" magic in configure.ac. -- 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] Re: Can we depend on system's utilities and libraries ?

And i guess sage-on-gentoo just puts everything into standard paths. -- 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

[sage-devel] Re: Can we depend on system's utilities and libraries ?

Note that gcc or pkgconfig are easier to deal with as they just need to be in PATH and nothing links to them or includes headers from them. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails

[sage-devel] Re: Can we depend on system's utilities and libraries ?

It would be great to let the user choose when to use system libraries instead of building our own, whether its curl or gmp. A problem coming to my mind to have a simple --with-curl=[system|build] working. For packages that will still be built and use curl, what we currently do, at least for

Re: [sage-devel] add curl as a standard package

On Wednesday, October 26, 2016 at 11:18:15 AM UTC+2, Emmanuel Charpentier wrote: > > On 26/10/2016 09:59, Jean-Pierre Flori wrote: > > > > > > On Wednesday, October 26, 2016 at 9:24:35 AM UTC+2, Emmanuel Charpentier > > wrote: > > > > Le mercr

Re: [sage-devel] add curl as a standard package

On Wednesday, October 26, 2016 at 9:24:35 AM UTC+2, Emmanuel Charpentier wrote: > > Le mercredi 26 octobre 2016 09:18:06 UTC+2, Jeroen Demeyer a écrit : >> >> On 2016-10-25 23:52, Emmanuel Charpentier wrote: >> > This is now Trac#21767 . The >> >

Re: [sage-devel] add curl as a standard package

On Tuesday, October 25, 2016 at 11:11:38 AM UTC+2, Jean-Pierre Flori wrote: > > > > On Tuesday, October 25, 2016 at 12:48:39 AM UTC+2, Dima Pasechnik wrote: >> >> >> >> On Monday, October 24, 2016 at 9:45:18 PM UTC, Emmanuel Charpentier wrote: >>>

Re: [sage-devel] add curl as a standard package

On Tuesday, October 25, 2016 at 12:48:39 AM UTC+2, Dima Pasechnik wrote: > > > > On Monday, October 24, 2016 at 9:45:18 PM UTC, Emmanuel Charpentier wrote: >> >> Okay. I I have followed you correctly, we have two (mutually >> incompatible) options : >> >> >>- (Dima's option) : package curl,

Re: [sage-devel] add curl as a standard package

On Monday, October 24, 2016 at 8:47:13 PM UTC+2, Jean-Pierre Flori wrote: > > > > On Monday, October 24, 2016 at 6:39:27 PM UTC+2, Emmanuel Charpentier > wrote: >> >> Bonus question for the build system experts : can an spkg-install script >> recursively

Re: [sage-devel] add curl as a standard package

On Monday, October 24, 2016 at 6:39:27 PM UTC+2, Emmanuel Charpentier wrote: > > Bonus question for the build system experts : can an spkg-install script > recursively call $SAGE_ROOT/sage -i and get the return > status back ? A simple solution would then be to test for the existence of >

Re: [sage-devel] add curl as a standard package

Maybe it is not that bad if the automagic detection system is not that good. If the automatic stuff works magically on usual config, let's say large Linux distros, that's enough. As long as we have "--with-x" options to pass to configure for making Sage more distro friendly and let smart people

Re: [sage-devel] NTL 1v0.1.0

On Tuesday, October 18, 2016 at 8:52:23 AM UTC+2, François wrote: > > > > On 18/10/2016, at 19:42, Jean-Pierre Flori <jpf...@gmail.com > > wrote: > > > > > > > > On Tuesday, October 18, 2016 at 6:37:49 AM UTC+2, Victor Shoup

Re: [sage-devel] NTL 1v0.1.0

On Tuesday, October 18, 2016 at 6:37:49 AM UTC+2, Victor Shoup wrote: > > Good! But it should be determined if there is an interface that ntl could > provide so that this problem goes away I think that what you suggested: extracting gmp bignums from NTL's ZZ (and the other way around) would

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

Yes it is a feature of the Singular 4 update that Singular and Sage work by default with 16 bit exponents on 32 and 64 bit platform by default. If only all of of you had read carefully the 543 comments of the update ticket and remembered this tcomment

[sage-devel] Re: NTL v10

On Tuesday, October 11, 2016 at 6:06:50 AM UTC+2, Victor Shoup wrote: > > 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

  1   2   3   4   5   6   7   8   9   >