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

[Jean-Pierre Flori]

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 building libsemigroups should be reported on its github page:
>
> https://github.com/libsemigroups/libsemigroups
>
> deformation package, on the other hand is more or less abandonware.
>
>
>
> On Thu, 22 Apr 2021, 15:17 Tirthankar Mazumder,  
> wrote:
>
>> While running make ptestalllong, I was able to build all the packages 
>> that it needs except for Deformation. I tried building it many times, but 
>> it failed every time. It said
>> /usr/bin/ld: -r and -pie may not be used together
>> collect2: error: ld returned 1 exit status
>>
>> I got all the other packages to install, even though in some of them I 
>> had to manually go to their download directory (which was in 
>> SAGE_ROOT/local/var/tmp/sage/build/) and edit the Makefile. The reason 
>> for this was, some of the packages (specifically, libsemigroups-0.6.7) 
>> output a Makefile with the -march and -mtune flags set for the compiler, 
>> but I have an 11th gen Intel processor, so GCC doesn't accept tigerlake or 
>> native as a valid flag yet. The Makefile generator for that library 
>> (which I believe is GNU AutoTools) should incorporate a check to see if the 
>> -march=native flag is available on the target system, like the 
>> cryptominisat-5.6.8 package does.
>>
>> I'm attaching 4 log files: The entire log for for deformation-d05941b.p0, 
>> which contains the build output for every single time I tried to build the 
>> package, a shortened version of that log file which contains what (I feel) 
>> is the relevant portion of that log file, the entire log file of 
>> libsemigroups-0.6.7, and a shorter version of the libsemigroups-0.6.7 
>> log file which contains what (I feel) is the relevant portion of that 
>> lengthy log file.
>>
>> P.S. --- I have some experience in building Sage on WSL2, having done it 
>> twice (on two different machines), so I want to edit the Sage on Windows 
>>  page's WSL section, but it 
>> appears that you can't use your GitHub-linked Trac account on the Wiki. How 
>> would I go about getting an account I can use on the Wiki? I'd prefer 
>> having one account to use across trac.sagemath.org and the Wiki, if 
>> that's possible.
>>
>> Thanks in advance,
>> Tirthankar
>>
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/f1184a5e-d6d4-4247-ad07-703de70a6fefn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/136b5fce-5f05-4d78-8bdf-97defa9bfd4bn%40googlegroups.com.

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

[Jean-Pierre Flori]

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 wrote:
> >>
> >> "Viable open source competitor" in the mission statement should include 
> this type of functionality. That said, I know that the forces against 
> actually having user-friendly interfaces for newbies that don't rely on 
> having an internet connection are too big.
> >
> >
> > The best routes, in my opinion, are to
> >
> > 1) use what the Jupyter community uses - see for example 
> https://gist.github.com/xiaolai/697ec3ea1607994440abf574c0f017e5
>
> this looks quite interesting. Can something like this be made to work
> for Sage? Wrapping the whole thing into one script to run
> looks doable...
>
> >
> > 2) improve support and provide documentation for using Sage with major 
> user-friendly development environments such as Anaconda or vscode. 
> https://trac.sagemath.org/ticket/30500
> >
> >
> >
> >
> > --
> > 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/a4c0f0f6-0bfa-4fcf-94e2-6653f0e7bd50o%40googlegroups.com
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/bb6d3325-e8b9-4637-9e1c-f2ed8fff4bc6n%40googlegroups.com.

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

[Jean-Pierre Flori]

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 then? `make start`? 
> > `sage -ba`? Can you also point me to a valgrind tutorial that 
> > demonstrates how to use it to analyse a memory leak? 
>
> It seems that with a debug build (`export SAGE_DEBUG=yes`), 
>   `sage --valgrind` 
> pretty much does what I was looking for. 
>
> I guess that it is the way to go. 

> Note that `sage -i valgrind` fails, so, the experimental valgrind 
> package is broken. But `sage --valgrind` apparently is able to use a 
> system-wide valgrind installation. 
>
> Yes, I think nobody updated the valgrind package for a long time.
Anyway uing the system wide one is surely a better idea.
 

> Best regards, 
> Simon 
>
>

-- 
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: Weak references in the coercion model

[Jean-Pierre Flori]

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 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] A Sage interface for FGb (Gröbner bases)

[Jean-Pierre Flori]

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 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] Re: zn_poly status?

[Jean-Pierre Flori]

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 
(http://web.maths.unsw.edu.au/~davidharvey/code/hypellfrob/) and very fast 
indeed.
As far as I know we have no alternative implementation to whats in 
hypellfrob though PARI/GP now offers more or less the same functionality 
with a different algorithm.

-- 
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] Re: Product of two expressions that causes hang

[Jean-Pierre Flori]

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 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: Product of two expressions that causes hang

[Jean-Pierre Flori]

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
...
Ginac::ex::ex
Ginac::ex::construct_from_basic
Ginac::mul::eval
Ginac::ex::integer_content
which calls sage code
which calls pynac code
...

The latter sage/pynac back and forth movement involves the numeric class in 
pynac which uses sage...

-- 
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: Product of two expressions that causes hang

[Jean-Pierre Flori]

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 avril 2018 14:10:04 UTC+2, Erik Bray a écrit :
>>
>> Hi all, 
>>
>> In working on an unrelated topic I encountered an indefinite hang, 
>> which I narrowed down to the following exact operation (I haven't 
>> found a way to simplify it further): 
>>
>> sage: e1 = sqrt(2)*I - sqrt(2) - 2 
>> sage: e2 = sqrt(2) 
>>
>> simple enough, right? 
>>
>> But then it appears to hang forever in pynac when I do: 
>>
>> sage: e1 * e2 
>>
>> When I hit Ctrl-C, cysignals just returns to the sig_on() in the 
>> beginning of Expression._mul_. 
>>
>> Any ideas? 
>>
>

-- 
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: PY_NEW(Integer) and Integer.__new__(Integer)

[Jean-Pierre Flori]

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, vdelecroix wrote:
>
> Dear all, 
>
> What is the status of Integer.__new__(Integer) vs PY_NEW(Integer). One 
> can find both versions in the source code 
>
> $ grep -R "PY_NEW(Integer)" | wc -l 
> 152 
> $ grep -R "Integer.__new__(Integer)" | wc -l 
> 94 
>
> But the doc of PY_NEW (ext/stdsage.pxd) says that we should avoid the 
> second one 
>
>  Return ``t.__new__(t)``.  This works even for types like 
>  :class:`Integer` where we change ``tp_new`` at runtime (Cython 
>  optimizations assume that ``tp_new`` doesn't change). 
>
> Should I change the 94 bad usage? 
>
> Vincent 
>
> PS: this happen to be a question from 
> https://trac.sagemath.org/ticket/24717 
>

-- 
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: [sage-support] Re: Has Big-Endian support been deprecated yet?

[Jean-Pierre Flori]

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 ticket, this big-endian incompatibility does not 
>> prevent the inclusion of primecount as an "experimental package" that I 
>> still aim to achieve (the type of the package "experimental", "optional" 
>> or "standard" is simply a flag). In practice "experimental" means "not 
>> officially supported" and "less tested". 
>>
>> And as Dima mentioned, it would be simpler for SageMath to have 
>> primecount supporting big-endian. We certainly do not want that a single 
>> library prevents using SageMath on big-endian architecture. 
>>
>> Now, three questions for Sage developers: 
>>
>> - Who is testing a big-endian architecture? 
>>
>> - Are all optional packages big-endian compatible? 
>>
>> - Is it reasonable to ask for big-endian compatibility for 
>>optional packages? 
>>
>
> The current status of big-endian Sage is that it sort of works on SPARC 
> Solaris 11 (thanks to Jeroen and your humble servant),
> but more work is needed. I  underestimated how much effort it would be, 
> when I started this back in January. :-)
> Interesting (and not so interesting) upstream bugs emerged in many 
> packages...
>
> see https://trac.sagemath.org/ticket/24596
>
> The machine is a VM (Solaris "zone") hosted at Warwick University, and we 
> would be able to run a patchbot there,
> once the port iis in reasonable shape.
>
> I understand that there are other big-endian architectures out there 
> capable of running Sage.
> (they are often able to do both big- and little-endian, though)
>
> Dima
>
>
>
>> Vincent 
>>
>> PS: to discuss these kind of issues related to development, it is better 
>> to use the other google group sage-devel. 
>>
>> On 13/03/2018 23:11, Dima Pasechnik wrote: 
>> > 
>> > 
>> > On Tuesday, March 13, 2018 at 9:41:50 PM UTC, Kim Walisch wrote: 
>> >> 
>> >> Hi, 
>> >> 
>> >> We all know that the big-endian CPU architecture is slowly dying, 
>> >> some people even state that "Big-Endian is effectively dead". 
>> >> 
>> >> So my question is: Does sagemath still support big-endian CPU 
>> >> architectures like e.g. 32-bit Sparc? 
>> >> 
>> > 
>> > We have recently more or less revived a SPARC Solaris 11 port of 
>> Sagemath. 
>> > So yes, please, make it both-endian... 
>> > 
>> > 
>> >   
>> > 
>> >> 
>> >> I am asking because there is a ticket 
>> >> (https://trac.sagemath.org/ticket/24966 
>> >> <
>> https://www.google.com/url?q=https%3A%2F%2Ftrac.sagemath.org%2Fticket%2F24966=D=1=AFQjCNHvco5SWFB7CiS50MxgtC2P8g3mxA>)
>>  
>>
>> >> to integrate my primecount 
>> >> library into sagemath and primecount currently only supports 
>> >> little-endian CPUs. I could support big-endian CPUs but I want to 
>> >> make sure this is required by sagemath. 
>> >> 
>> >> Thanks, 
>> >> Kim 
>> >> 
>> > 
>>
>

-- 
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: 6 hours left to prepare GSoC application for this year!

[Jean-Pierre Flori]

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 skipping this year?
> I'm about to add the 3rd project to the wiki: 
> https://wiki.sagemath.org/GSoC/2018
> but this is not enough, I think. Can we get 3-4 more?
>
> Harald, is everything else ready?
>

-- 
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: Getting rid of the pickle jar

[Jean-Pierre Flori]

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 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] A couple R tickets need review.

[Jean-Pierre Flori]

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+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: Sage packaging template

[Jean-Pierre Flori]

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 some 
>> changes and info to skip some of the requirements when using it. 
>>
>  
> I don't have write acces to that repository so I can't accept your pull 
> request. But Marc Masdue (in the CC) does.
> I guess it would be a good idea to put Marc his cookie cutter in the 
> Sagemath github repo under https://github.com/sagemath so it can be 
> turned into a more collaborative development experience.
>
>
> I know the sage_package_template cookie cutter was made based on 
> sage_sample. It might be a good idea to think about how these can be 
> developed in parallel.
>
Sure, I just wanted to make you aware of this in case you also wanted to 
suggest/make further changes. 

-- 
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: Sage sample / sage packaging template

[Jean-Pierre Flori]

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 https://github.com/sagemath/sage_sample quite a bit. 
>> For which I hope that it falls under sage packaging ;) 
>>
>> I think we have 2 or 3 such projects in the mean time. Maybe we should 
>> take the best ideas from each. 
>>
>
> I actually only know the one I linked to, do you have links to other ones?
>
> p.s. there are two related projects which serve distinct purposes:
>
> 1) https://github.com/sagemath/sage-package a utilities/tools python 
> package which is meant to be used in sage_sample and other external sage 
> python packages.
>
> 2) https://github.com/mmasdeu/sage_package_template this is a cookie 
> cutter template based on sage_sample .
>
I've made a pull request at 
https://github.com/mmasdeu/sage_package_template/pull/3 with some changes 
and info to skip some of the requirements when using 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 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: Some polynomial timings

[Jean-Pierre Flori]

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 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] Does anyone use SAGE64?

[Jean-Pierre Flori]

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 gcc produces 32 bits stuff by 
> default, unless you begin compiling your own gcc and convince it to do 
> something else.
>
I'm not sure that this is a sufficient reason to keep the SAGE64 semi 
broken mess in the install scripts though.
I would even consider it a good idea to remove it now and reintroduce it 
later if someone really needs such support.
In btw playing with C*FLAGS should do the trick. 

-- 
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] Does anyone use SAGE64?

[Jean-Pierre Flori]

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 
something else.

-- 
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: Some polynomial timings

[Jean-Pierre Flori]

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 :
>>
>> I was doing timing on the same task and found that one system
>> (used for celestial mechanics) was spectacularly fast on a test just like 
>> this one.
>> One reason was that it first changed f*(f+1)   to
>>
>> f^2 +f
>> and was clever in computing f^2.  You should be clever
>> at this too.
>>
>> Anyway, be careful when you are testing.
>>
>>
> giac does not cheat, it does the product f*(f+1) not f^2+f. For more 
> details, you can have a look at Bill Hart blog:
>
> http://wbhart.blogspot.fr/2017/07/update-on-fast-multivariate-polynomial.html
>

-- 
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] Template (cookiecutter) for easily distributing SageMath code

[Jean-Pierre Flori]

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.
> 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 goal of 
>> this cookie cutter is to easily set up the project with Travis CI and 
>> automatic documentation generation and deployment. 
>> Marc 
>> -
>>  
>>
>> marc.masdeu AT gmail DOT com 
>> -
>>  
>>
>>
>>
>> On Wed, Aug 23, 2017 at 6:43 PM, Jeroen Demeyer <jdem...@cage.ugent.be> 
>> wrote: 
>> > On 2017-08-23 17:44, Marc Masdeu wrote: 
>> >> 
>> >> I know that there is several people who think that this is not the way 
>> >> that code should be distributed. I am asking feedback from the 
>> >> complementary set of people, really (although constructive comments 
>> from 
>> >> anyone are definitely welcome!). 
>> > 
>> > 
>> > My personal opinion is that "SageMath packages" should use as little 
>> > Sage-specific things as possible. In other words, a SageMath package 
>> should 
>> > really be just a Python package with a dependency on SageMath. 
>> > 
>> > 
>> > -- 
>> > You received this message because you are subscribed to a topic in the 
>> > Google Groups "sage-devel" group. 
>> > To unsubscribe from this topic, visit 
>> > https://groups.google.com/d/topic/sage-devel/OoTNcZpAwPo/unsubscribe. 
>> > To unsubscribe from this group and all its topics, 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] Template (cookiecutter) for easily distributing SageMath code

[Jean-Pierre Flori]

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 goal of 
> this cookie cutter is to easily set up the project with Travis CI and 
> automatic documentation generation and deployment. 
> Marc 
> - 
>
> marc.masdeu AT gmail DOT com 
> - 
>
>
>
> On Wed, Aug 23, 2017 at 6:43 PM, Jeroen Demeyer  > wrote: 
> > On 2017-08-23 17:44, Marc Masdeu wrote: 
> >> 
> >> I know that there is several people who think that this is not the way 
> >> that code should be distributed. I am asking feedback from the 
> >> complementary set of people, really (although constructive comments 
> from 
> >> anyone are definitely welcome!). 
> > 
> > 
> > My personal opinion is that "SageMath packages" should use as little 
> > Sage-specific things as possible. In other words, a SageMath package 
> should 
> > really be just a Python package with a dependency on SageMath. 
> > 
> > 
> > -- 
> > You received this message because you are subscribed to a topic in the 
> > Google Groups "sage-devel" group. 
> > To unsubscribe from this topic, visit 
> > https://groups.google.com/d/topic/sage-devel/OoTNcZpAwPo/unsubscribe. 
> > To unsubscribe from this group and all its topics, 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] Re: Conda package for Sage

[Jean-Pierre Flori]

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 licenses and a 
>> power8/9 :))
>>
>
> We literally used to have such a cluster for sage testing, including 
> itanium!
>
Yes I remember and I advocated that one of ODK goals should  be portability 
and such hardware should be bought back, including hardware for testing 
cygwin portability, but I was never an official member of ODK.

-- 
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] Re: Conda package for Sage

[Jean-Pierre Flori]

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 don't see why ODK cannot spend 4600 euro to buy one of these... 
>> > (it is way above my ODK budget, but would still be peanuts for the 
>> whole 
>> > project) 
>>
>> Plus licenses for a range of OSX versions (at least those that are 
>> still supported by Apple...) 
>>
>
> these are peanuts, e.g. £20 for 10.7
> https://www.apple.com/uk/shop/product/D6106ZM/A/os-x-lion
>
> (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 licenses and a 
power8/9 :))

-- 
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] Re: Conda package for Sage

[Jean-Pierre Flori]

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 run in a VM which is 
> not running on Apple hardware. Perhaps this is the best way out.
>
>From what I tried and heard that more or less works depending on OS X 
version.
And is unfortunately illegal according to Apple though I'm not a lawyer.

-- 
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] Re: segfault (involving flint, libthread, randstate)

[Jean-Pierre Flori]

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 
/home/jpflori/sage.git/src/build/cythonized/sage/misc/randstate.c:5496
#2  0x3fffb7eb95dc in subtract_refs (
containers=0x3fffb7f4db10 ) at Modules/gcmodule.c:385
#3  collect (generation=) at Modules/gcmodule.c:925
#4  0x3fffb7eba490 in gc_collect (self=, 
args=, kws=) at Modules/gcmodule.c:1121
#5  0x3fffb7dc77cc in PyCFunction_Call (func=0x3fffb0081878, 
arg=, kw=) at Objects/methodobject.c:85
#6  0x3fffb7e5d728 in call_function (oparg=, 
pp_stack=0x3fffa228) at Python/ceval.c:4352

On Thursday, May 11, 2017 at 12:09:55 PM UTC+2, vdelecroix wrote:
>
> The bug also shows up with 
> {{{ 
> sage: a = matrix(QQ, 1) 
> sage: a.randomize() 
> sage: del a 
> sage: import gc 
> sage: gc.collect() 
> }}} 
>
> On 11/05/2017 11:55, Dima Pasechnik wrote: 
> > given libpthread being involved, I guess it might have to do with GIL vs 
> > NOGIL stuff... 
> > 
> > 
> > On Thursday, May 11, 2017 at 10:50:39 AM UTC+1, vdelecroix wrote: 
> >> 
> >> Dear all, 
> >> 
> >> While working on [1] I stumbled on a strange segfault. Namely, with the 
> >> branch applied I got 
> >> 
> >> {{{ 
> >> sage: a = matrix(QQ, 1) 
> >> sage: a.randomize() 
> >> sage: quit 
> >> Exiting Sage (CPU time 0m1.48s, Wall time 0m5.80s). 
> >> 
>  
> >> .../cysignals/signals.so 
> >> .../cysignals/signals.so 
> >> .../cysignals/signals.so 
> >> .../libpthread.so.0 
> >> .../libpython2.7.so.1.0 
> >> .../sage/misc/randstate.so 
> >>  
> >> 
>  
> >> Unhandled SIGSEGV: A segmentation fault occurred. 
> >> 
>  
> >> }}} 
> >> 
> >> I indeed modified the randomization method to use flint random 
> >> generators, you can have a look at commits [2] and [3]. But I don't 
> >> understand at all where the error might come from. 
> >> 
> >> Any help would be more than welcome! 
> >> 
> >>   [1] https://trac.sagemath.org/ticket/22970 
> >>   [2] 
> >> 
> >> 
> https://git.sagemath.org/sage.git/commit?id=b52e2c347a28b301485c6cc5bb221873ca5ac636
>  
> >>   [3] 
> >> 
> >> 
> https://git.sagemath.org/sage.git/commit?id=d5ea72b364534c3ce4374c6d78b54852c8333cc3
>  
> >> 
> >> Best, 
> >> 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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jean-Pierre Flori]

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@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: state of the art for sparse rational linear systems

[Jean-Pierre Flori]

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 good up to dimension 1000 with the generic 
> solve_right method. Where should I look for libraries implementing 
> somethig less naive? 
>
> Over prime finite fields, you could look at what CADO-NFS ships.

Maybe Linbox does things over the rationals.

You could also try to work over a finite field and lift the result :)

-- 
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: GSoC 2017 accepted SageMath

[Jean-Pierre Flori]

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.
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] Too many Maximas!

[Jean-Pierre Flori]

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 zombies.
Not sure about the real process, i.e. maxima, magma, ..., anymore.

-- 
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] Did anyone test latest Sage versions inculding giac on non-x86_64 64 bit systems?

[Jean-Pierre Flori]

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 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] Problem building GSL in cygwin64

[Jean-Pierre Flori]

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 Thursday, January 26, 2017 at 5:04:52 AM UTC+1, Frank Garvan wrote:
>
> As suggested I did the following:
>
>   cd sage
>   export SAGE_ATLAS_ARCH=base
>   ./configure --with-blas=atlas
>   make
>
> Go the following error:
>
> Error building Sage.
>
> The following package(s) may have failed to build (not necessarily
> during this run of 'make all'):
>
> * package: libfplll-5.0.3rc0
>   log file: /home/Owner/sage/logs/pkgs/libfplll-5.0.3rc0.log
>   build directory: 
> /home/Owner/sage/local/var/tmp/sage/build/libfplll-5.0.3rc0
>
>
> Have attached log file libfplll-5.0.3rc0.log
>
> Thanks
> FG
>
> On Wednesday, January 25, 2017 at 9:02:26 AM UTC-5, Erik Bray wrote:
>>
>> On Tue, Jan 24, 2017 at 7:50 PM, Francois Bissey 
>>  wrote: 
>> > That was my suspicion. Now does sage-on-cygwin use openblas? 
>> > If not that means the corresponding `.pc` files have to be filled 
>> > with something appropriate before installing any blas/lapack 
>> dependencies. 
>> > 
>> > The present hack I introduced in gsl and causes this error is to force 
>> > the linking of libgsl to our selected cblas. By default upstream 
>> > leave it underlinked. The problem with underlinking is that you get 
>> > in corner cases when the sage library components using gsl are also 
>> > underlinked if you have “-Wl,—as-needed” in your LDFLAGS and you 
>> > use the gold linker. And sage won’t start up… 
>> > Generally speaking the underlinking is a bad idea in our context. 
>> > Adding a “LIBS” at configuration time was the easiest thing to do. 
>> > May be it needs to be avoided on cygwin. 
>>
>>
>> I currently build Sage on Cygwin using the system-provided lapack 
>> package and ./configure --with-blas=atlas.  I don't think I've 
>> explicitly gotten it working with a self-built openblas yet but it 
>> hasn't been a priority. 
>>
>>
>> >> On 25/01/2017, at 03:57, Dima Pasechnik  wrote: 
>> >> 
>> >> 
>> >> 
>> >> On Tuesday, January 24, 2017 at 2:00:54 PM UTC, Frank Garvan wrote: 
>> >> 
>> >> Have attached config.log file 
>> >> 
>> >> Thanks. I think what really happens is that openblas did not install 
>> correctly, and gsl 
>> >> has a dependence on it. 
>> >> In more detail, your log says: 
>> >> 
>> >> configure:3502: gcc -g -O2   -L/home/Owner/sage/local/lib 
>> -Wl,-rpath,/home/Owner/sage/local/lib  conftest.c -lopenblas -lm >&5 
>> >> 
>> /usr/lib/gcc/x86_64-pc-cygwin/5.4.0/../../../../x86_64-pc-cygwin/bin/ld: 
>> cannot find -lopenblas 
>> >> 
>> >> Could you post the corresponding log (SAGEROOT/logs/pkgs/openblas-*) ? 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> On Tuesday, January 24, 2017 at 3:26:49 AM UTC-5, François wrote: 
>> >> Need to see 
>> >> /home/Owner/sage/local/var/tmp/sage/build/gsl-2.1.p1/src/config.log 
>> >> but I suspect I am responsible. 
>> >> 
>> >> François 
>> >> 
>> >> > On 24/01/2017, at 14:51, Frank Garvan  wrote: 
>> >> > 
>> >> > 
>> >> > Have attached log file. 
>> >> > 
>> >> > Can this be fixed? 
>> >> > 
>> >> > Thanks 
>> >> > 
>> >> > PS: Running cygwin64 on windows10 
>> >> > processor: Intel Core i3-6100 CPU @ 3.70 Ghz 
>> >> > RAM: 8.00 GB 
>> >> > system type: 64-bit operating system, x64-based processor 
>> >> > 
>> >> > -- 
>> >> > 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+...@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+...@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 

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

[Jean-Pierre Flori]

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 
>   libraries. 
>
> - We don't have multi-point evaluation or fast Lagrange interpolation, 
>   even though the libraries we link to often have this. 
>
> - Bruno Grenet remarked at SD75 that there were issues and lots of 
>   crufted code in the class structure handling generic/specific and 
>   dense/sparse/etc. polynomials. 
>
> - Jeroen Demeyer remarked that the Cython code is from the prehistoric 
>   era and has lots of cruft from back when Cython was a lot more 
>   primitive than it is now. 
>
> - add more things yourself. 
>
> Considering how central polynomial arithmetic is in many parts of 
> algebra, I think this is bad, and it impedes gradual improvement (e.g. I 
> am at a loss on how to improve the GF(2^e)[x] thing which is my personal 
> main itch). 
>
> I would be interested in co-mentoring such a GSoC project for improving 
> this. But I lack understanding of, especially Cython and linking. I 
> would like to know if someone else would be a co-mentor with me on this, 
> or technical advisor on e.g. Cython issues. 
>
> Best, 
> Johan 
>
>
> I would be very interested in working on this.

-- 
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] Re: R fails to compile

[Jean-Pierre Flori]

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!
Not through R.
https://github.com/sagemath/sage/tree/master/build/pkgs/iconv

-- 
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: R fails to compile

[Jean-Pierre Flori]

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 Charpentier
>
> Le mercredi 18 janvier 2017 14:15:57 UTC+1, Emmanuel Charpentier a écrit :
>>
>> Do you have iconv installed systemwide ?
>>
>> Le mardi 17 janvier 2017 03:24:54 UTC+1, Rob Gross a écrit :
>>>
>>> Hi,
>>>
>>> I tried to upgrade to 7.5.1 on several different Macs which I thought 
>>> had identical software.
>>>
>>> However, on one of them, R failed to compile, with the error:
>>>
>>>   installing 'sysdata.rda'
>>> dyld: Symbol not found: __libiconv_version
>>>   Referenced from: 
>>> /Users/gross/sage-7.0/local/var/tmp/sage/build/r-3.2.4-revised.p0/src/lib/libR.dylib
>>>   Expected in: flat namespace
>>>  in 
>>> /Users/gross/sage-7.0/local/var/tmp/sage/build/r-3.2.4-revised.p0/src/lib/libR.dylib
>>> /bin/sh: line 1: 22794 Doneecho 
>>> "tools:::sysdata2LazyLoadDB(\"./R/sysdata.rda\",\"../../../library/tools/R\")"
>>>  22795 Abort trap: 6   | R_DEFAULT_PACKAGES=NULL LC_ALL=C 
>>> ../../../bin/R --vanilla --slave
>>>
>>> Any ideas?
>>>
>>> Thanks.--Rob
>>>
>>>
>>>

-- 
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] Re: releasing memory in compiled components

[Jean-Pierre Flori]

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/libs/eclib/newforms.pyx#L112
>  
>
> Alternatively, instead of a pointer you could store the object itself in 
> the Python class. Then you wouldn't use new and wouldn't need to delete 
> anything. I'm not at all saying that this is the best option, it's just 
> something to consider... 
>
I guess that to do that you need an argless constructor which does not seem 
to be the case here. 

-- 
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: releasing memory in compiled components

[Jean-Pierre Flori]

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.
>>
>
> No, there is the following caveat when cyclic Python references are 
> involved:
>
> __dealloc__ is always called, but there is no guarantee that pure Python 
> attributes are still set (they may be cleared, that is, set to None, in 
> order to break cycles). Cython (cdef) attributes are still set.
>
> __del__ will not always be called, some garbage objects are skipped to 
> break cycles. If __del__ is being called then all Python attributes are 
> still set.
>
> TLDR: use __dealloc__ to destroy wrapped C++ objects.
>
I meat write with __dealloc__:
cdef __dealloc__:
blablabla

if I_made_sure_new_was_called_and_constructor_got_called:
del my_cdefed_c++_pointer_which_has_been_allocated_with_new

Isn't that the correct way to trigger Cytohn writin down an explicit call 
to the destructor?

-- 
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: releasing memory in compiled components

[Jean-Pierre Flori]

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:
* 
http://docs.cython.org/en/latest/src/userguide/special_methods.html#finalization-method-dealloc
You can just use the Python "del" operator and Cython should translate it 
to a destructor call.

-- 
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: denominator() hangs on a large fraction

[Jean-Pierre Flori]

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 new Pynac version has the fix, see
> https://trac.sagemath.org/ticket/22136
>
> Regards,
>
Thanks!
I think I've seen this one when updating Singular.
But as it only made doctests fail in debug mode I did not take time to 
investigate or report it yet. 

-- 
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] cysignal, python signal module, and alarm functions

[Jean-Pierre Flori]

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 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 
> > computation? 
>
> ??? Didn't you answer this question yourself before? 
>
> M = magma() # I only need an ephemeral Magma instance 
> try: 
>  alarm(3600) 
>  M(...) # potentially very long one shot computation 
> except AlarmInterrupt: 
>  M.quit() 
>
That does not work!

First the AlarmInterrupt gets caught as a KeyboardInterrupt inside 
expect.py which softly interrupts Magma and watis for its prompt.
And even when done it raises a KeyboardInterrupt and does not end up in the 
except clause...

-- 
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] cysignal, python signal module, and alarm functions

[Jean-Pierre Flori]

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 
computation? 

-- 
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] cysignal, python signal module, and alarm functions

[Jean-Pierre Flori]

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. It 
> seems like an instance of the XY problem (http://xyproblem.info/) to me, 
> where X=killing magma and Y=using alarm. 
>
> If Magma has special needs to be interrupted or killed, you need to 
> modify sage/interfaces/magma.py to have things work correctly with magma. 
>
> But maybe I am misunderstanding your explanation. 
>
Let me be more explicit, I want to do something like that:
"""
M = magma() # I only need an ephemeral Magma instance
try: 
alarm(3600)
M(...) # potentially very long one shot computation
except AlarmInterrupt:
M.violently_kill() # I don't care about getting back the Magma prompt
"""
I don't want to use M.interrupt() although it does its job: it tries to 
cleanly interrupt Magma and get back a prompt which can still take a long 
time.
I just want to kill Magma because I don't hae anything valuable in the 
Magma session, I'mm just doing a long computation.
That's easy to code: send to SIGINT's or another signal.
But the issue with using alarm() is that the expect.py will call 
M.interrupt() and I'm stuck...
(On top of that the above code won't end up in the except clause as 
expect.py will raise a Keyboardinterrupt.)

I can setup my own signals/timers but it seems to me that alarm is made for 
my purpose: launch a long computation (or blockinf syscall) and interrupt 
it.
With the current state of the cysignal alarms and expect.py, the only way I 
see to modifythe Magma interface is as follow:tin
* give an option when setting up a Magma interface "interrupting_equal_kill"
* overloading the "interrupt" method to act as the generic method from 
expect.py if the option was not set, and kill Magma if it was.

-- 
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] cysignal, python signal module, and alarm functions

[Jean-Pierre Flori]

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-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 about src/sage/interfaces/expect.py 
> > 
> > Yes indeed. 
> > 
> > 
> > Yes, that code is crazy when it comes to KeyboardInterrupt. Believe 
> me, 
> > it has been worse before and I already cleaned it up a little bit. 
> > 
> > If you have an explicit use case (as in: something that we could add 
> a 
> > doctest for), I could try to fix it. 
> > 
> > Killing Magma? 
>
> If Magma needs a "special" trick to get interrupted, you should just 
> modify the interrupt() method in sage/interfaces/magma.py 
>
You need this special trick to kill it.
My issue is that I can not use the alarm() machinery to trigger 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 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] cysignal, python signal module, and alarm functions

[Jean-Pierre Flori]

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 about src/sage/interfaces/expect.py 
>
Yes indeed. 

>
> Yes, that code is crazy when it comes to KeyboardInterrupt. Believe me, 
> it has been worse before and I already cleaned it up a little bit. 
>
> If you have an explicit use case (as in: something that we could add a 
> doctest for), I could try to fix it. 
>
Killing Magma?
To be sure it quits quick you have to send two SIGINT's.
It it just gets one it waits (for I don't know how long depending on what 
it's doing) before actually stopping its current computation.
So my plan was to trigger a SIGALARM and send a couple of SIGINT's.
And I used the alarm() stuff.
But with it,  except.py code gets the AlarmInterrupt and sends SIGINT to 
Magma and then waits for its prompt...
I've not tested how bad it gets, that is: does it way forever? does Magma 
sometimes take ages to quit or not?
So maybe that's overreacting but at first I got frustrated because Magma 
took longer than planned to quit even though it was not that longer...

-- 
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: converting different C/C++ types/classes

[Jean-Pierre Flori]

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 are made available, all 
> essentailly based on int.  But I want to make available a function 
> which returns an NTL RR (real number).  The NTL interface does not 
> include RR.   Would it be possible to do this, by first adding RR to 
> the list of NTL types Sage knows about and then using that? 
>
I would say yes, this should be possible.
Actually Cython even supports templating nowadays if that's what you had in 
mind.

What do you class look like?
And where are they defined in Sage's cython files?
I guess in:
* 
https://github.com/sagemath/sage/blob/develop/src/sage/libs/eclib/__init__.pxd

I would also say that the interface in sage/interface/eclib might deserve a 
little bit of clean up along the lines of what was done for MPIR, MPFR, 
PARI and partially for NTL.
At least, you could put all the class definition into a decl.pxd file as 
for the aforementioned libraries.
Or even its own pip installable package :)

-- 
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] cysignal, python signal module, and alarm functions

[Jean-Pierre Flori]

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 signal module? 
>
> Depends what you mean with "fundamental". The internal implementation is 
> different. The main user-visible difference is that Python's alarm 
> requires an integer timeout, while cysignals accepts a floating-point 
> timeout. 
>
> > Second question: Is there any reason to make AlarmInterrupt derive from 
> > KeyboardInterrupt? 
> > SIGALARM and SIGINT are different signals. 
>
> I give you 3 reasons: 
>
> 1. Historically, Sage has used KeyboardInterrupt for alarm(). So 
> deriving AlarmInterrupt from KeyboardInterrupt is backwards-compatible 
> with code catching KeyboardInterrupt for alarms. 
>
> 2. Conceptually, KeyboardInterrupt and AlarmInterrupt are quite close. 
> They both originate from signals and can interrupt code in the middle of 
> a computation. 
>
> 3. Since alarm() raises a sub-class of KeyboardInterrupt, alarm() 
> provides an easy way to test interrupt-handling of code. 
>
> > And its troublesome when using sage pexpect interfaces as they eat 
> > KeyboardInterrupt (and so AlarmInterrupt). 
>
> What do you mean, they "eat" KeyboardInterrupt? 
>
They handle it themselves with a try/except clause.
So if I raise an AlarmInterrupt which derives on KeyboardInterrupt, it gets 
caught and I don't really have control:
the code in sage/expect.py does it thing and then I get back a 
KeyboardInterrupt (and not an AlarmInterrupt).

Maybe the code in sage/except.py should at least be modified not to modify 
the class of the exception.

For the fact that it also does its own stuff before raising the error I 
could live with it but maybe we should also add an option to the except 
interface to directly raise the exception without trying anything.

-- 
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] cysignal, python signal module, and alarm functions

[Jean-Pierre Flori]

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 when using sage pexpect interfaces as they eat 
KeyboardInterrupt (and so AlarmInterrupt).

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.

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

[Jean-Pierre Flori]

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.
>>
> Ahah that's exactly how I used to work on Sage on Cygwin: from a Windows 
> VM on top of Linux!
>
And good job Erik! 

-- 
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: Sage for Windows installer (take 2)

[Jean-Pierre Flori]

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 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] SAGE_ATLAS_LIB vs openblas

[Jean-Pierre Flori]

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: 
> > 
> > > On 2/12/2016, at 21:21, Thierry <sage-goo...@lma.metelu.net> wrote: 
> > > 
> > > Hi, 
> > > 
> > > the SAGE_ATLAS_LIB stuff, which allowed to use system blas belongs to 
> > > SAGE_ROOT/build/pkgs/atlas/spkg-install Is it possible to have such 
> option 
> > > (perhaps renamed SAGE_BLAS_LIB) available even if openblas is selected 
> as 
> > > the default blas, or a specific (SAGE_OPENBLAS_LIB) one ? Would it be 
> > > preferable to have this possibility dealt at configure time, not 
> depending 
> > > on Sage's default blas ? 
> > > 
> > 
> > I am all for it, but we need a mechanism to generate appropriate .pc 
> files 
> > in that case. 
> > Or couldn't we ask for a pointer to .pc file? 
> > And copy it/use it inside Sage? 
>
>
> Manual all the way, eh? So “SYSTEM_BLAS_PC” pointing to pc files for blas, 
> cblas 
> and lapack. Difficulty, at least on OS X we cannot assume a system 
> pkg-config 
> to be present, so validation of pc file at configure time is of the menu - 
> at least by invoking pkg-config. 
>
At least when installing our packages needing blas we have a working 
pkgconfig.

-- 
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] SAGE_ATLAS_LIB vs openblas

[Jean-Pierre Flori]

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 possible to have such 
> option 
> > (perhaps renamed SAGE_BLAS_LIB) available even if openblas is selected 
> as 
> > the default blas, or a specific (SAGE_OPENBLAS_LIB) one ? Would it be 
> > preferable to have this possibility dealt at configure time, not 
> depending 
> > on Sage's default blas ? 
> > 
>
> I am all for it, but we need a mechanism to generate appropriate .pc files 
> in that case. 
>
Or couldn't we ask for a pointer to .pc file?
And copy it/use it inside Sage?

-- 
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] Re: OpenSSL as a new systemwide Sage dependency ?

[Jean-Pierre Flori]

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 should 
> probably strongly recommend it in the installation instructions.
>
Yes. 

>
> GnuTLS and other implementations won't solve our problem, as Python's _ssl 
> module is specifically written against OpenSSL and can't be linked against 
> anything else.
>
> On OSX, you can do either
>
> a) nothing => no https support,
>
> Note a very simple patch allows to build R without ranting about ssl... 
Sure this is bad for the mondane user with internet access and no license 
issues, but it simplifies our task. 

> a) supply the (missing) openssl headers for the system openssl. This is 
> still a shitty solution as it doesn't (and probably will never) support 
> TLSv12.
>
> c) compile your own openssl implementation AND bring your own copy of the 
> root certificates as your self-compiled openssl will not be able to access 
> the OSX certificate store. Distributing the resulting binary has some 
> license issues.
>
>
> On Thursday, December 1, 2016 at 11:25:42 PM UTC+1, Emmanuel Charpentier 
> wrote:
>>
>> Dear Thierry,
>>
>> Thank you for this answer : you have done a large work that I planned for 
>> my next opportunity. Comments below :
>>
>> Le jeudi 1 décembre 2016 22:56:15 UTC+1, Thierry (sage-googlesucks@xxx) a 
>> écrit :
>>>
>>> Hi, 
>>>
>>> On Sun, Nov 27, 2016 at 03:52:59AM -0800, Emmanuel Charpentier wrote: 
>>> > OK. Let's try again : 
>>> > I have two questions : 
>>> > 
>>> >1. What are the parts (standard, optional or experimental, except, 
>>> of 
>>> >course, the openssl package itself) of Sage that need (directly or 
>>> >indirectly) a secure transport layer but would accept either 
>>> openSSL or 
>>> >reasonable substitutes such as Gnu TLS or Mozilla's NSS ? 
>>> >2. What are the parts (standard, optional or experimental, except, 
>>> of 
>>> >course, the openssl package itself) of Sage that (directly or 
>>> indirectly) 
>>> >need openSSL, no substitute accepted ? 
>>> > 
>>> > My favorite itch to be scratched (namely R), seems to fall in the 
>>> first 
>>> > category, but I have trouble proving it : I would need a reasonable 
>>> test 
>>> > machine with no openSSL library to check whether R installs or not 
>>> using 
>>> > only Gnu TLS.  All the Linux *desktop* installation I tried install 
>>> > openSSL, one way or another (even Debian, which is notably prudish 
>>> about 
>>> > licensing). I would have to install an ultra-basic virtual machine. 
>>> This 
>>> > setup could be used to prove or disprove the dependencies of various 
>>> parts 
>>> > of Sage. 
>>>
>>> A priori (?), openssl package should not interfere if you do not have 
>>> libssl-dev installed. 
>>>
>>> I tried building Sage 7.3 on a VM without libssl-dev, but with both 
>>> libgnutls28-dev and libgnutls-openssl27 installed (on a Debian jessie). 
>>> Sage builds and tests fine, but i do not have SSL support when using 
>>> pip: 
>>>
>>> ./sage -pip search blah 
>>> SSLError: Can't connect to HTTPS URL because the SSL module is not 
>>> available. 
>>>
>>
>> This seems a serious problem, given the increasing dependency of Sage on 
>> pip packages. This is also one aspect of more and more services migrating 
>> to secured protocols (the new https requirement of R, which started this 
>> epopea, is another example).
>>
>> I think that your experiment demonstrates that GnuTLS does not (yet) 
>> offer a substitute to (at least some) OpenSSL functionalities.
>>
>> My experiments with R led me to think the same thing.
>>
>> So I think it's time to bite the bullet, acknowledge that we depend on 
>> OpenSSL and document it. We should also test for it when building Sage.
>>
>> For the first task, I think that the right places are :
>>
>>- README.md in the root directory ;
>>- The developer's guide.
>>
>>
>> For the second task, the most logical place would be in the toplevel 
>> configure file, after checking for a "minimal" toolset (C compiler, make, 
>> etc..). Since at this point, we do not have pkg-config, we have to use the 
>> Great White Shark method : bite and see what happens. In this case,, 
>> compile, link and run a minimal program festing the existence and basic 
>> functionality of of libssl. Ideas on what to test an how are much welcome : 
>> I'm a bit out of my depth here...
>>
>> We could also wait for the installation of Sage's pkg-config, which makes 
>> the ssl test trivial, but, IIRC that comes a bit late (i. e. after Sage's 
>> python compilation), and we leave the user with partially unusable Sage's 
>> parts, that whould have to be recompiled after a correct OpenSSL 
>> installation. It's probably better to fail early.
>>
>> Again, your advice, criticisms and ideas are welcome.

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

[Jean-Pierre Flori]

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: 
> >> 
> >> 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/ticket/13026 
> > * https://trac.sagemath.org/ticket/15871 
>
> That's what I was unclear about.  I saw those tickets and assumed that 
> we had been messing with the autotools stuff, and wasn't sure if it 
> was still maintained by its creator.  But the upstream source tarball 
> contains the same autotools files so maybe we upstreamed that at some 
> point, but it originated from Sage? 
>
> I don't know.  It doesn't say in the changelog. 
>
>From what I see, the current situation is still a mess.
Yes upstream ships an autotool build system but we heavily patch it.
We should definitely exchange with 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 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] Update CDDLIB source package? (was: What is the correct way to patch packages that use autotools?)

[Jean-Pierre Flori]

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/ticket/13026
* https://trac.sagemath.org/ticket/15871

-- 
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] Update CDDLIB source package? (was: What is the correct way to patch packages that use autotools?)

[Jean-Pierre Flori]

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+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: Checking out old branches

[Jean-Pierre Flori]

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 the 
> fact that Cython builds based on timestamp and all of the files have been 
> touched.
>
> I'd like to solicit ideas to make this less painful.  Here's one, based on 
> a conversation with Julian Rüth.
>
> Create a new git trac subcommand to replace `git trac checkout 1234`, say 
> `git trac old 1234`.  This would fetch the branch, check it out into a 
> completely separate folder within ($SAGE_ROOT/merge_tree or something), 
> merge in develop.  If the merge is successful, create a new branch and pull 
> the changes in.  This ends up with only a few files changing if you started 
> at develop.  If the merge is not successful, report to the user and ask 
> them to fix the merge in 
> $SAGE_ROOT/merge_tree.  There would then be some way to resume and pull 
> in the changes.
>
> There are some details to fill in, but I think that an approach like this 
> can work.  It does mean having another 100MB working tree floating around 
> just for merging into, and also stepping a bit further away from normal git 
> practices.
>
> Any other ideas?
> David
>
Fix cycache ? :p
It seems there is a related discussion here:
https://trac.sagemath.org/ticket/17851 

-- 
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] Re: What is the correct way to patch packages that use autotools?

[Jean-Pierre Flori]

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" 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: What is the correct way to patch packages that use autotools?

[Jean-Pierre Flori]

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:
>>>
>>> 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 particular 
>>> case I am patching both confgure.ac and Makefile.am files. 
>>>
>>> Should I add just patches for the input files, or should I also 
>>> include patches for the output files (configure, Makefile(.in), etc.)? 
>>>
>> I'd say both... 
>>
>>>  Should I merge them all together or keep them separate? 
>>>
>>> ...in separate patches, the one to "source" files not being applied.
>>
> But submitted upstream :)
>
(And put it in a subdirectory of the patch directory in the sage tree.) 

-- 
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: What is the correct way to patch packages that use autotools?

[Jean-Pierre Flori]

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 
>> 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 particular 
>> case I am patching both confgure.ac and Makefile.am files. 
>>
>> Should I add just patches for the input files, or should I also 
>> include patches for the output files (configure, Makefile(.in), etc.)? 
>>
> I'd say both... 
>
>>  Should I merge them all together or keep them separate? 
>>
>> ...in separate patches, the one to "source" files not being applied.
>
But submitted 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: What is the correct way to patch packages that use autotools?

[Jean-Pierre Flori]

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 particular 
> case I am patching both confgure.ac and Makefile.am files. 
>
> Should I add just patches for the input files, or should I also 
> include patches for the output files (configure, Makefile(.in), etc.)? 
>
I'd say both... 

>  Should I merge them all together or keep them separate? 
>
> ...in separate patches, the one to "source" files not being applied.
 

> Further, for patching the generated files, what's a good way to go 
> about that?  If I don't have the exact versions of autoconf and 
> automake as were used in the upstream sources then I can wind up with 
> a lot of unrelated changes in the generated files.  How are you 
> normally dealing with that? 
>
> There is a autotools spkg.
If you  autoreconf from a sage shell it should then use matching versions 
of the autostuff.

-- 
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] Singular "share" files

[Jean-Pierre Flori]

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 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: R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

I would say we even have a shorter-time solution: close the tickets for 
including curl (modulo adding a SAGE_FAT_BINARY mode to avoid overlinking) 
and updating R (modulo adding a 6-line patch to not check for https 
support, note that most of the time https will be supported anyway).


On Wednesday, November 2, 2016 at 11:19:52 AM UTC+1, Emmanuel Charpentier 
wrote:
>
> So far, the only plan I can propose which is consistent with the various 
> points that have been stated  is : 
>
> I) short-term workaround : add a dependance for Sage, by :
> a) depending on libcurl and its development files, or
> b) depending on a systemwide R + its development files
> II) solve current issues with the pexpexct interface (e. g. graphs in 
> Jupyter...) and its documentation (e. g. use of RElement to retrieve an R 
> object).
>
> This solves the immediate problem at hand (which is urgent : more and more 
> R packages won't install on R 3.2.x). But since some have pointed out the 
> inefficiencies of the current R interface and its documentation, we could :
>
> III) Build some steamlined interface ("newR") to R (via rpy2 ? via 
> IRkernel ?). Test it
> IV) Based on newR, build a reasonable wrapper emulating 
> feature-for-feature the current pexpect interface. Test it.
> V) replace the pexpect interface by the wrapper.
>
> This is not urgent, and can be discussed further.
>
> Now, for Ia vs Ib :
>
>- Both require modifying the installation documentation and the main 
>configure file. These do not seem to be large modifications (I just need 
> to 
>learn a modicum of autotools in order to do this correctly).
>- Both allow the current pexpect to remain a standard part of Sage.
>
> Ib seems to have two slight advantages on Ia :
>
>- R and its development files seem to be well-packaged on the few 
>(Linux) distributions I have checked, as well as Cygwin, and probably are 
>elsewhere (other GNU/Linuxes, assorted Unices). The Macintosh case, as 
>usual, bears a large question mark...
>- Paradoxically, it is probably easier for an end-user to check this 
>requirement than to check the suitability of his libcurl...
>- Ib does not require xz and pcre to become standard packages.
>
> Could we have a 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 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 because of license issues so we can:
>> [1] either make R depend on libcurl depend on openssl and they all become 
>> optional,
>> [2] or make R depend on libcurl and make them standard and add an SSL/TLS 
>> implementation and its development headers a prereq,
>> [3] or make libcurl with https support (and development headers) a 
>> prereq, which basically means adding an SSL/TLS implementation as a prereq 
>> as well,
>> [4] or make R a prereq,
>> [5] or drop R support,
>> [6] or patch R not to use curl,
>> [7] or patch R to use curl but without https support,
>> [8] or wait until the end of times,
>> [9] or a mix of all of this,
>> [10] or do something else.
>>
>> What do you think?
>>
>> 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.

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

[Jean-Pierre Flori]

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 (nor 
> would I want to).
>
Yup that is most distro trick: considering openssl is part of the system 
lib of the operating system and invoke the corresponding GPL exception to 
link GPL stuff to it.
 
If our binaries already depends on openssl being installed, which I don't 
find really satisfactory, let it be and sotp the madness.
Not that if we want to ship binaries without this dependency it is not that 
hard (conifgure curl properly and a 10 line patch to R which won't support 
https).

-- 
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] R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

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 openssl) 
> tells that it would remove a ton of system utilities.
>

desktop :)

-- 
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] R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

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 such cases.
Not sure what they'll do about it.

Yet another interesting discussion for freeradius, they do add a specific 
exception for openssl...
* https://bugzilla.redhat.com/show_bug.cgi?id=317271 

Thanks for working on this; how annoying. 
>
Enough for me, I'm gonna stop here :) 

-- 
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] R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

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: 
> >> 
> >> 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. 
> >> 
> > Apart from the linking issue, doesn't it apply that we cannot ship curl 
> > sources? 
> > 
> > I seem to remember that stuff about Sage already violating the GPL as it 
> is 
> > GPL v3+ and ships some GPL v2 only code. 
>
> Such as?  I don't think this is the case. 
>
> Indeed, it was a wrong souvenir:
https://groups.google.com/d/msg/sage-devel/amxAxHkmvbw/bgnBseSV_u8J

-- 
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] R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

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 
> inconsistent legal foundation. There is no easy way out, since only 
> copyright owners can change licenses.  Because this is volunteer open 
> source, much of the generation that got us into this mess is MIA (or 
> even dead in some cases).Sigh... 
>
>  
>

Yup it's a uselessly messy situation :/
I certainly do not want to play lawyers. 

-- 
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] R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

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
> Groumpf.
> See https://curl.haxx.se/legal/distro-dilemma.html for more rumbling.
>
> Apart from the linking issue, doesn't it apply that we cannot ship curl 
sources?

I seem to remember that stuff about Sage already violating the GPL as it is 
GPL v3+ and ships some GPL v2 only code.
No idea about the implication for LGPL and other funny stuff.

-- 
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] R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

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:
>>>
>>>
>>>
>>> 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:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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. 
>>>>>>>
>>>>>>
>>>>>> How old is RH7.1 ? The introduction of the libcurl requirement dates 
>>>>>> from the R 3.3.0 release, (May 3, 2016).
>>>>>>
>>>>>> I note that Debian (notoriously twitchy about license issues) didn't 
>>>>>> seem to have any qualms packaging 3.3.0, nor 3.3.1. 
>>>>>>
>>>>>  
>>>>> I'd say Debian links curl to GnuTLS.
>>>>>
>>>>
>>>> Probably not : My system's curl-config --protocols says that HTTPS: is 
>>>> supported. A trial of curl's configure --without-ssl --with-gnutls does 
>>>> not 
>>>> claim to support it (in the summary printed at th end of ./configure...).
>>>>
>>>> Are you sure you  installed the gnutls dev headers?
>>> GnuTLS provides an SSL implem, not just SSL.
>>>  
>>>
>>>> However, I'm not sure : Debian's blurb about libcurl3-gnutls says that 
>>>> it supports https, imaps, ldaps, smtps and pop3s.
>>>>
>>>> To be sure, I'll have to setup a virtual machine with a minimal 
>>>> environment (no openssl, of course) and try to setup libcurl (and, if 
>>>> successful, Sage) in that environment. This is time consuming, so not 
>>>> quite 
>>>> real soon...
>>>>
>>> You mean with gnutls?
>>> Or with no ssl/tls at all?
>>>
>>> I already did the latter and it works (modulo hacking R's configure).
>>>
>>
>>  (sage-sh) jpflori@gcc1-power7:sage.git$ curl-config --protocols
>> DICT
>> FILE
>> FTP
>> GOPHER
>> HTTP
>> IMAP
>> POP3
>> RTSP
>> SCP
>> SFTP
>> SMTP
>> TELNET
>> TFTP
>> (sage-sh) jpflori@gcc1-power7:sage.git$ R --version
>> R version 3.3.1 (2016-06-21) -- "Bug in Your Hair"
>> Copyright (C) 2016 The R Foundation for Statistical Computing
>> Platform: powerpc64-unknown-linux-gnu (64-bit)
>>
>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>> You are welcome to redistribute it under the terms of the
>> GNU General Public License versions 2 or 3.
>> For more information about these matters see
>> http://www.gnu.org/licenses/.
>>
>
> No HTTPS. Damn.. 
>
As far as installing packages goes, R suggest me 27 https mirrors and a 
28-th option "HTTP mirrors", if I go there it works. 

-- 
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] R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

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 libcurl?
Section 6 of https://curl.haxx.se/docs/faq.html tells its a legal issue and 
they cannot help you.

-- 
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] R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

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 :
>>>
>>>
>>>
>>> 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. 
>>>>>
>>>>
>>>> How old is RH7.1 ? The introduction of the libcurl requirement dates 
>>>> from the R 3.3.0 release, (May 3, 2016).
>>>>
>>>> I note that Debian (notoriously twitchy about license issues) didn't 
>>>> seem to have any qualms packaging 3.3.0, nor 3.3.1. 
>>>>
>>>  
>>> I'd say Debian links curl to GnuTLS.
>>>
>>
>> Probably not : My system's curl-config --protocols says that HTTPS: is 
>> supported. A trial of curl's configure --without-ssl --with-gnutls does not 
>> claim to support it (in the summary printed at th end of ./configure...).
>>
>> Are you sure you  installed the gnutls dev headers?
> GnuTLS provides an SSL implem, not just SSL.
>  
>
>> However, I'm not sure : Debian's blurb about libcurl3-gnutls says that it 
>> supports https, imaps, ldaps, smtps and pop3s.
>>
>> To be sure, I'll have to setup a virtual machine with a minimal 
>> environment (no openssl, of course) and try to setup libcurl (and, if 
>> successful, Sage) in that environment. This is time consuming, so not quite 
>> real soon...
>>
> You mean with gnutls?
> Or with no ssl/tls at all?
>
> I already did the latter and it works (modulo hacking R's configure).
>

 (sage-sh) jpflori@gcc1-power7:sage.git$ curl-config --protocols
DICT
FILE
FTP
GOPHER
HTTP
IMAP
POP3
RTSP
SCP
SFTP
SMTP
TELNET
TFTP
(sage-sh) jpflori@gcc1-power7:sage.git$ R --version
R version 3.3.1 (2016-06-21) -- "Bug in Your Hair"
Copyright (C) 2016 The R Foundation for Statistical Computing
Platform: powerpc64-unknown-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under the terms of the
GNU General Public License versions 2 or 3.
For more information about these matters see
http://www.gnu.org/licenses/.

-- 
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] R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

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:
>>>
>>>
>>>
>>> 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. 
>>>>
>>>
>>> How old is RH7.1 ? The introduction of the libcurl requirement dates 
>>> from the R 3.3.0 release, (May 3, 2016).
>>>
>>> I note that Debian (notoriously twitchy about license issues) didn't 
>>> seem to have any qualms packaging 3.3.0, nor 3.3.1. 
>>>
>>  
>> I'd say Debian links curl to GnuTLS.
>>
>
> Probably not : My system's curl-config --protocols says that HTTPS: is 
> supported. A trial of curl's configure --without-ssl --with-gnutls does not 
> claim to support it (in the summary printed at th end of ./configure...).
>
> Are you sure you  installed the gnutls dev headers?
GnuTLS provides an SSL implem, not just SSL.
 

> However, I'm not sure : Debian's blurb about libcurl3-gnutls says that it 
> supports https, imaps, ldaps, smtps and pop3s.
>
> To be sure, I'll have to setup a virtual machine with a minimal 
> environment (no openssl, of course) and try to setup libcurl (and, if 
> successful, Sage) in that environment. This is time consuming, so not quite 
> real soon...
>
You mean with gnutls?
Or with no ssl/tls at all?

I already did the latter and it works (modulo hacking R's configure).

-- 
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] R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

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. 
>>
>
> How old is RH7.1 ? The introduction of the libcurl requirement dates from 
> the R 3.3.0 release, (May 3, 2016).
>
> I note that Debian (notoriously twitchy about license issues) didn't seem 
> to have any qualms packaging 3.3.0, nor 3.3.1. 
>
 
I'd say Debian links curl to GnuTLS.

-- 
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] R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

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 dist tarballs).
* patch R unconditionally and build it against the potentially ssl-free 
curl (patch is ready).

-- 
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] R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

On Thursday, October 27, 2016 at 12:22:37 PM UTC+2, Emmanuel Charpentier 
wrote:
>
> I'm afraid that we don't have much say in the matter : the R core 
> development team has choosen to rely on curl, and their build system will 
> fail without it. Furthermore, among those 9402 packages, a lot of them may 
> have choosen to follow R "guidance" an use CURL.
>
> If we choose to use another library, we are effectively forking R and a 
> $#!+load of those packages. Somehow, I doubt that we have the workforce to 
> do that credibly...
>
> So, before coming to these extremities, I'd like to explore two avenues :
> Question the R Core Team to know how they reconcile their DPL 2-3 license 
> and teir use of OpenSSL, and discuss if we can use the same loophole as 
> they did. In which case, all is fine and dandy...
>
I don't know how much they thought about it, or rather how many lawyers 
they did pay, but if they ship binaries including the libcurl and openssl 
that might be risky.
Some people invoke the special exception clause of the GPL...
See:
* https://people.gnome.org/~markmc/openssl-and-the-gpl.html
* 
https://groups.google.com/forum/#!searchin/sage-devel/openssl|sort:relevance/sage-devel/mbGbpRz96q0/8nsKRNyLs3oJ
 
(OpenSSL license issue) 
* 
https://groups.google.com/forum/#!searchin/sage-devel/openssl|sort:relevance/sage-devel/Jl11JxIb2E8/-1NrQmjbMKIJ
 
(why GnuTLS which is GPL is not a drop in replacement

If they rely on the user having its own libcurl and openssl then there is 
no problem.
 

> Excise R *proprio dictu* and keep the R interface(s) as optional, 
> reworking them to use an externally-installed R. And get rid of the damn 
> beast...
>
> What do you think ?
>
> Le jeudi 27 octobre 2016 12:11:43 UTC+2, François a écrit :
>>
>> My own examination of R-3.3.1 configure script is that configure will 
>> fail if libcurl 7.28+ is not present or present with ssl disabled 
>> [m4/R.m4 line 4215 thereafter]. 
>> Unless the code for `install.package` has significantly changed between 
>> 3.2.x and 3.3.x it is an unnecessary failure dictated by an unwillingness 
>> to have to support the alternatives. i.e.. not needing to explain what to 
>> do in when libcurl is not present or without ssl support. 
>> I doubt that 
>> 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 interesting experience I had at 
>> work 
>> today with a user. 
>>
>> François 
>>   
>> > On 27/10/2016, at 22:49, Jean-Pierre Flori <jpf...@gmail.com> wrote: 
>> > 
>> > 
>> > 
>> > 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 suggest a new solution: 
>> > [666] : 
>> > * patch R if curl (with https support) is not there and make curl an 
>> optional package, 
>> > * not patch R if curl (with https support) is ther. 
>> > 
>> > -- 
>> > 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] R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

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, 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 suggest a new solution: 
> > [666] : 
> > * patch R if curl (with https support) is not there and make curl an 
> > optional package, 
> > * not patch R if curl (with https support) is ther. 
>
> Conditionally patching is really bad because it cannot be pushed upstream. 
>
> Instead, in proper autoconfig style, we should conditionally build the 
> parts requiring curl. That is, change the logic in the R build system to 
> build R without the packaging system if curl is not available. 
>
Upstream R devs might be somewhat uncooperative.
I don't plan on pushing anything 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] R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

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 suggest a new solution:
[666] :
* patch R if curl (with https support) is not there and make curl an 
optional package,
* not patch R if curl (with https support) is ther.

-- 
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] R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

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 because of license issues so we can:
[1] either make R depend on libcurl depend on openssl and they all become 
optional,
[2] or make R depend on libcurl and make them standard and add an SSL/TLS 
implementation and its development headers a prereq,
[3] or make libcurl with https support (and development headers) a prereq, 
which basically means adding an SSL/TLS implementation as a prereq as well,
[4] or make R a prereq,
[5] or drop R support,
[6] or patch R not to use curl,
[7] or patch R to use curl but without https support,
[8] or wait until the end of times,
[9] or a mix of all of this,
[10] or do something else.

What do you think?

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.

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

[Jean-Pierre Flori]

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, 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] add curl as a standard package

[Jean-Pierre Flori]

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@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: add curl as a standard package

[Jean-Pierre Flori]

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 ticket ? 
>>
>
> Its not really a distinct issue, its a general caveat of compiling your 
> own curl. And even if we (and/or R) don't use curl to download over ssl 
> today, this will surely change in the future.
>
Hum, it seems to me that R wants curl with https support, look at
https://svn.r-project.org/R/trunk/m4/R.m4 

"libcurl >= 7.28.0 library and headers are required with support for https"


-- 
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: Can we depend on system's utilities and libraries ?

[Jean-Pierre Flori]

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 
>> 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 :
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> That means, if I follow you, to have to patch each and every 
>>>> (candidate) package potentially using curl in order to consider this flag. 
>>>> Not exactly low-maintainance... 
>>>>
>>> What do we gain ?
>>>>
>>> I don't get you.
>>>
>>> The current situation is that for every package built by Sage depending 
>>> on any other package built by Sage, we have to tell them to look into 
>>> $SAGE_LOCAL for including headers and linking to libraries.
>>>
>>> I suggest to add a --with-curl=... or --with-systemwide-pkgs=... option 
>>> to the toplevel configure of "Sage the distribution" to tell "Sage the 
>>> distribution" not to build its own curl but to rely on a system wide one.
>>> But then we have to tell each package built by "Sage the distribution" 
>>> to look for its dependencies either in $SAGE_LOCAL (which is basically 
>>> always the case at the moment) or in standard system-wide paths (hopefully 
>>> we won't support non standard paths in the near future).
>>>
>>> So we indeed need to modify the configure options in each spkg-install 
>>> scripts of pkgs depending on curl to have "--with-curl=`pkgconfig 
>>> --blablbabla`" or anything sensible which would tell it to either look into 
>>> $SAGE_LOCAL or in default paths.
>>> The only other way to do this without passing stuff to configure scripts 
>>> of each package is playing with LDFLAGS and CFLAGS and this has 
>>> unfortunately less chances of success than using configure scripts options, 
>>> good luck with that.
>>>
>>>
>>>> Furthermore, that introduce the possibility of having *simultaneously* 
>>>> some packages using  our version of curl and others using system's 
>>>> version. 
>>>> Ouch...
>>>>
>>>> Yes maybe.
>>> I can surely make it so that Sage gets both ATLAS and openblas installed 
>>> if I really want to and link to both of them in a random way. 
>>>
>>> A more consistent way would be to pass a flag to curl's installation 
>>>> script telling it to fake installation or to force build. That is 
>>>> possible, 
>>>> but, again, not very consistent with the primitive idea of enforcing some 
>>>> consistency.
>>>>
>>> No it does not solve the issue of packages having to link to libcurl. 
>>> Unless you want to play with LDFLAGS and C[...]FLAGS rather than passing 
>>> options to configure scripts of these packages.
>>>
>> In fact you still have to deal with LDFLAGS and CPPFLAGS.
>> At least R only looks in what they define and you cannot give anything 
>> through a --with-curl= option.
>>
>> By the way it seems that Sage modifies by default LDFLAGS globally to 
>> include $SAGE_LOCAL/lib but not CPPFLAGS. 
>>
>
> Maybe we can use config.site as well:
> https://www.gnu.org/software/automake/manual/html_node/config_002esite.html 
>

We set CPATH, but I'm not sure it is enough for 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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jean-Pierre Flori]

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 
>> 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 our own, whether its curl or gmp.
>>>> A problem coming to my mind to have a simple --with-curl=[system|build] 
>>>> working.
>>>>
>>>
>>> That means, if I follow you, to have to patch each and every (candidate) 
>>> package potentially using curl in order to consider this flag. Not exactly 
>>> low-maintainance... 
>>>
>> What do we gain ?
>>>
>> I don't get you.
>>
>> The current situation is that for every package built by Sage depending 
>> on any other package built by Sage, we have to tell them to look into 
>> $SAGE_LOCAL for including headers and linking to libraries.
>>
>> I suggest to add a --with-curl=... or --with-systemwide-pkgs=... option 
>> to the toplevel configure of "Sage the distribution" to tell "Sage the 
>> distribution" not to build its own curl but to rely on a system wide one.
>> But then we have to tell each package built by "Sage the distribution" to 
>> look for its dependencies either in $SAGE_LOCAL (which is basically always 
>> the case at the moment) or in standard system-wide paths (hopefully we 
>> won't support non standard paths in the near future).
>>
>> So we indeed need to modify the configure options in each spkg-install 
>> scripts of pkgs depending on curl to have "--with-curl=`pkgconfig 
>> --blablbabla`" or anything sensible which would tell it to either look into 
>> $SAGE_LOCAL or in default paths.
>> The only other way to do this without passing stuff to configure scripts 
>> of each package is playing with LDFLAGS and CFLAGS and this has 
>> unfortunately less chances of success than using configure scripts options, 
>> good luck with that.
>>
>>
>>> Furthermore, that introduce the possibility of having *simultaneously* 
>>> some packages using  our version of curl and others using system's version. 
>>> Ouch...
>>>
>>> Yes maybe.
>> I can surely make it so that Sage gets both ATLAS and openblas installed 
>> if I really want to and link to both of them in a random way. 
>>
>> A more consistent way would be to pass a flag to curl's installation 
>>> script telling it to fake installation or to force build. That is possible, 
>>> but, again, not very consistent with the primitive idea of enforcing some 
>>> consistency.
>>>
>> No it does not solve the issue of packages having to link to libcurl. 
>> Unless you want to play with LDFLAGS and C[...]FLAGS rather than passing 
>> options to configure scripts of these packages.
>>
> In fact you still have to deal with LDFLAGS and CPPFLAGS.
> At least R only looks in what they define and you cannot give anything 
> through a --with-curl= option.
>
> By the way it seems that Sage modifies by default LDFLAGS globally to 
> include $SAGE_LOCAL/lib but not CPPFLAGS. 
>

Maybe we can use config.site as well:
https://www.gnu.org/software/automake/manual/html_node/config_002esite.html 

-- 
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: Can we depend on system's utilities and libraries ?

[Jean-Pierre Flori]

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 :
>>>
>>> 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.
>>>
>>
>> That means, if I follow you, to have to patch each and every (candidate) 
>> package potentially using curl in order to consider this flag. Not exactly 
>> low-maintainance... 
>>
> What do we gain ?
>>
> I don't get you.
>
> The current situation is that for every package built by Sage depending on 
> any other package built by Sage, we have to tell them to look into 
> $SAGE_LOCAL for including headers and linking to libraries.
>
> I suggest to add a --with-curl=... or --with-systemwide-pkgs=... option to 
> the toplevel configure of "Sage the distribution" to tell "Sage the 
> distribution" not to build its own curl but to rely on a system wide one.
> But then we have to tell each package built by "Sage the distribution" to 
> look for its dependencies either in $SAGE_LOCAL (which is basically always 
> the case at the moment) or in standard system-wide paths (hopefully we 
> won't support non standard paths in the near future).
>
> So we indeed need to modify the configure options in each spkg-install 
> scripts of pkgs depending on curl to have "--with-curl=`pkgconfig 
> --blablbabla`" or anything sensible which would tell it to either look into 
> $SAGE_LOCAL or in default paths.
> The only other way to do this without passing stuff to configure scripts 
> of each package is playing with LDFLAGS and CFLAGS and this has 
> unfortunately less chances of success than using configure scripts options, 
> good luck with that.
>
>
>> Furthermore, that introduce the possibility of having *simultaneously* 
>> some packages using  our version of curl and others using system's version. 
>> Ouch...
>>
>> Yes maybe.
> I can surely make it so that Sage gets both ATLAS and openblas installed 
> if I really want to and link to both of them in a random way. 
>
> A more consistent way would be to pass a flag to curl's installation 
>> script telling it to fake installation or to force build. That is possible, 
>> but, again, not very consistent with the primitive idea of enforcing some 
>> consistency.
>>
> No it does not solve the issue of packages having to link to libcurl. 
> Unless you want to play with LDFLAGS and C[...]FLAGS rather than passing 
> options to configure scripts of these packages.
>
In fact you still have to deal with LDFLAGS and CPPFLAGS.
At least R only looks in what they define and you cannot give anything 
through a --with-curl= option.

By the way it seems that Sage modifies by default LDFLAGS globally to 
include $SAGE_LOCAL/lib but not CPPFLAGS. 

-- 
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: Can we depend on system's utilities and libraries ?

[Jean-Pierre Flori]

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 our own, whether its curl or gmp.
>> A problem coming to my mind to have a simple --with-curl=[system|build] 
>> working.
>>
>
> That means, if I follow you, to have to patch each and every (candidate) 
> package potentially using curl in order to consider this flag. Not exactly 
> low-maintainance... 
>
What do we gain ?
>
I don't get you.

The current situation is that for every package built by Sage depending on 
any other package built by Sage, we have to tell them to look into 
$SAGE_LOCAL for including headers and linking to libraries.

I suggest to add a --with-curl=... or --with-systemwide-pkgs=... option to 
the toplevel configure of "Sage the distribution" to tell "Sage the 
distribution" not to build its own curl but to rely on a system wide one.
But then we have to tell each package built by "Sage the distribution" to 
look for its dependencies either in $SAGE_LOCAL (which is basically always 
the case at the moment) or in standard system-wide paths (hopefully we 
won't support non standard paths in the near future).

So we indeed need to modify the configure options in each spkg-install 
scripts of pkgs depending on curl to have "--with-curl=`pkgconfig 
--blablbabla`" or anything sensible which would tell it to either look into 
$SAGE_LOCAL or in default paths.
The only other way to do this without passing stuff to configure scripts of 
each package is playing with LDFLAGS and CFLAGS and this has unfortunately 
less chances of success than using configure scripts options, good luck 
with that.


> Furthermore, that introduce the possibility of having *simultaneously* 
> some packages using  our version of curl and others using system's version. 
> Ouch...
>
> Yes maybe.
I can surely make it so that Sage gets both ATLAS and openblas installed if 
I really want to and link to both of them in a random way. 

A more consistent way would be to pass a flag to curl's installation script 
> telling it to fake installation or to force build. That is possible, but, 
> again, not very consistent with the primitive idea of enforcing some 
> consistency.
>
No it does not solve the issue of packages having to link to libcurl. 
Unless you want to play with LDFLAGS and C[...]FLAGS rather than passing 
options to configure scripts of these packages.

-- 
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: Can we depend on system's utilities and libraries ?

[Jean-Pierre Flori]

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+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: Can we depend on system's utilities and libraries ?

[Jean-Pierre Flori]

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 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: Can we depend on system's utilities and libraries ?

[Jean-Pierre Flori]

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 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: Can we depend on system's utilities and libraries ?

[Jean-Pierre Flori]

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 packages using autotools or standard configure/make/make 
install strategies, is that we pass --with-curl=$SAGE_LOCAL or something 
like that.
Now if we allow curl to be either in $SAGE_LOCAL or in a sytem-wide default 
path we cannot go this way.

Using --with-curl=`pkgconfig --lib curl` (or whatever pkgconfig syntax is) 
might do the trick for libs providing pkgconfig files (once we make sure 
Sage or systemwide pkgconfig looks first in $SAGE_LOCAL, then in systemwide 
dirs).

Another solution is to globally tweak CFLAGS and LDFLAGS but that will be 
hell.

How does sage-on-gentoo deal with this?

-- 
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] add curl as a standard package

[Jean-Pierre Flori]

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 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 <https://trac.sagemath.org/ticket/21767 
> > <https://trac.sagemath.org/ticket/21767>>. The 
> > > unconditional installation works okay on top of 7.5beta0. 
> > > 
> > > The conditional installation can probably be obtained with 
> > this bash 
> > > snippet, at the top of spkg-install : 
> > 
> > Unless there is a good reason to do otherwise, such checks are 
> > better 
> > done in the top-level configure instead. 
> > 
> > 
> > I'm not so sure : harder to do, harder to understand, not obvious at 
> > reading the spkg-install script. But cleaner, indeed. 
> > 
> > One good reason is that when two packages will depend on curl we don't 
> > need to duplicate code. 
>
> ??? I don't understand your point : the code being at the top of curl's 
> spkg-install script, it has not to be duplicated (nor executed twice : 
> curl would be marked as installed, and packages depending on it wouldn't 
> trigger it twice. 
>
> Putting something analogous in the main (Sage's) configure scriptt would 
> mean integrating curl in Sage itself. R being a standard package and 
> depending on curl, it would amount to the same thing. In which case, 
> "packaging" curl (i. e. create a distinct software entity) is nonsense ; 
> just add it to  Sage's source tarball and, indeed, add the necessray 
> voodoo in configure (or, rather, to its sources, if any). 
>
> I'm not sure I'm following you... 
>
nah it was morning,I thought you  meant at top of the R spkg-install script.

>
> Furthermore : 
>
> > 
> > BTW, I'm having second thoughts on the wisdom of installing 
> > conditionally to the current system's state. I'll open the 
> > discussion in another thread. 
>
> -- 
> Emmanuel Charpentier 
>
>

-- 
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] add curl as a standard package

[Jean-Pierre Flori]

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 
>> > unconditional installation works okay on top of 7.5beta0. 
>> > 
>> > The conditional installation can probably be obtained with this bash 
>> > snippet, at the top of spkg-install : 
>>
>> Unless there is a good reason to do otherwise, such checks are better 
>> done in the top-level configure instead. 
>>
>
> I'm not so sure : harder to do, harder to understand, not obvious at 
> reading the spkg-install script. But cleaner, indeed.
>
> One good reason is that when two packages will depend on curl we don't 
need to duplicate code.

> BTW, I'm having second thoughts on the wisdom of installing conditionally 
> to the current system's state. I'll open the discussion in another thread.
>
> --
> Emmanuel Charpentier
>

-- 
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] add curl as a standard package

[Jean-Pierre Flori]

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:
>>>
>>> Okay. I I have followed you correctly, we have two (mutually 
>>> incompatible) options :
>>>
>>>
>>>- (Dima's option) : package curl, pcre and xz as standard packages, 
>>>and make R depend on them (unconditionnally).
>>>- (Jean-Pierre option) : add tjem to Sage's core, but build them if 
>>>and only if they are not installed systemwide (= useable at Sage's 
>>> compile 
>>>time) ; do this before trying to build R.
>>>
>>> The first option is extremely simple and failsafe. The cost is about 15 
>>> MB (sum of all installed files in a temporary "prefix" directory, without 
>>> shaving anything) and about 3 minutes of compilation time (no parallelism 
>>> used). We might shave 4,9 MB of docs (local/share/(doc|man). Binaries are  
>>> about 0.9MB. The total potential cots (sum of sizes of the three build 
>>> directories) is 89 MB (= potential cost if the three build directories ate 
>>> kept after building i. e. for debugging purposes).
>>>
>>
>> I don't really follow you: note that gcc is also a standard package, but 
>> it only really gets installed if the system gcc is 
>> not good enough. That is to say, if curl, pcre, and xz are available 
>> system-wide, Sage should not try to install them,
>> no megabytes used...
>>
> I don't think the real issue is megabytes, but rather making sage more 
> modular and easier to ship into distributions (other than sage-the-distrib).
>  
>
>>  
>>
>>>
>>> The second one requires hacking the main Sage configuration. I do not 
>>> feel currently quite at ease with this one, but I'm just reading the 
>>> relevant docs. I have no idea of the potential costs, save for what can be 
>>> deduced from the costs of Dima's options.
>>>
>>> The first option is compatible with the "batteries included" philosophy 
>>> flaunted by Sage. are the potential 10-15 MB savings worth of hacking the 
>>> main Sage config file ?
>>>
>> You can already add them as standard packages and then we can work on 
> making them installed only if not available system-wide.
> These two steps can be done sequentially though it would be better to get 
> the two of them at the same time.
>
If you open a tcket with the first step, I'll do the second one, and Jeroen 
or someone else can review 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 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] add curl as a standard package

[Jean-Pierre Flori]

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, pcre and xz as standard packages, 
>>and make R depend on them (unconditionnally).
>>- (Jean-Pierre option) : add tjem to Sage's core, but build them if 
>>and only if they are not installed systemwide (= useable at Sage's 
>> compile 
>>time) ; do this before trying to build R.
>>
>> The first option is extremely simple and failsafe. The cost is about 15 
>> MB (sum of all installed files in a temporary "prefix" directory, without 
>> shaving anything) and about 3 minutes of compilation time (no parallelism 
>> used). We might shave 4,9 MB of docs (local/share/(doc|man). Binaries are  
>> about 0.9MB. The total potential cots (sum of sizes of the three build 
>> directories) is 89 MB (= potential cost if the three build directories ate 
>> kept after building i. e. for debugging purposes).
>>
>
> I don't really follow you: note that gcc is also a standard package, but 
> it only really gets installed if the system gcc is 
> not good enough. That is to say, if curl, pcre, and xz are available 
> system-wide, Sage should not try to install them,
> no megabytes used...
>
I don't think the real issue is megabytes, but rather making sage more 
modular and easier to ship into distributions (other than sage-the-distrib).
 

>  
>
>>
>> The second one requires hacking the main Sage configuration. I do not 
>> feel currently quite at ease with this one, but I'm just reading the 
>> relevant docs. I have no idea of the potential costs, save for what can be 
>> deduced from the costs of Dima's options.
>>
>> The first option is compatible with the "batteries included" philosophy 
>> flaunted by Sage. are the potential 10-15 MB savings worth of hacking the 
>> main Sage config file ?
>>
> You can already add them as standard packages and then we can work on 
making them installed only if not available system-wide.
These two steps can be done sequentially though it would be better to get 
the two of them at the same time.

-- 
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] add curl as a standard package

[Jean-Pierre Flori]

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 call $SAGE_ROOT/sage -i  and get the return 
>> status back ? A simple solution would then be to test for the existence of 
>> the relevant binaries/executables in the R spkg-install script, and 
>> recursively install the (optional) relevant packages before proceeding to 
>> install R.
>>
>> What do you think ?
>>
>> I would say the good solution would be to mimick what is done for GCC.
> Some calls to the autoconf macros here:
> https://github.com/sagemath/sage/blob/master/configure.ac#L393 
>
> Also have a look at what is done for the integer multi precision library:
> https://github.com/sagemath/sage/blob/master/configure.ac#L657
>
> What is done for BLAS can also help.
>
> I don't have much time these days, but if you don't feel at ease enough 
> with autotools I can give it a try.
>

There is also the need_to_install  magic:
https://github.com/sagemath/sage/blob/master/configure.ac#L807 

-- 
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] add curl as a standard package

[Jean-Pierre Flori]

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 
> the relevant binaries/executables in the R spkg-install script, and 
> recursively install the (optional) relevant packages before proceeding to 
> install R.
>
> What do you think ?
>
> I would say the good solution would be to mimick what is done for GCC.
Some calls to the autoconf macros here:
https://github.com/sagemath/sage/blob/master/configure.ac#L393 

Also have a look at what is done for the integer multi precision library:
https://github.com/sagemath/sage/blob/master/configure.ac#L657

What is done for BLAS can also help.

I don't have much time these days, but if you don't feel at ease enough 
with autotools I can give it a try.

-- 
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] add curl as a standard package

[Jean-Pierre Flori]

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 do whatever they want quite 
easily.

On Monday, October 24, 2016 at 3:38:10 PM UTC+2, Emmanuel Charpentier wrote:
>
>
>
> Le lundi 24 octobre 2016 12:41:14 UTC+2, vdelecroix a écrit :
>>
>> In between? 
>>
>>  * having a curl pacakge that will be installed if not present on the 
>> system (~the same way we deal with gcc) 
>>
>
> Great idea, if I can implement it. Looking in the $PATH is not quite easy 
> to do portably. I'm currently looking at configure.in, and begin to 
> suspect I've fallen in a trap...
>
> Ideas ?
>

-- 
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 1v0.1.0

[Jean-Pierre Flori]

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 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 be great. 
>
> Who is doing the reporting to singular upstream? Preferably someone 
> who already has an account on singular’s trac. 
>
> François

Usually I just post on the google group libsingular-devel and Hans read it 
and fixes the issue.
The singular trac server uses a high port and I can not reach it from some 
of my computers. 

-- 
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 1v0.1.0

[Jean-Pierre Flori]

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 be great.

-- 
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

[Jean-Pierre Flori]

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 
https://trac.sagemath.org/ticket/17254#comment:126 and commit 
https://git.sagemath.org/sage.git/commit/?id=8c0275427c66b709413188b82da7845a3196e4bb
 
that would be obvious to you.
Now if we want to give more bits when fewer variables are used that should 
be possible.
(I'm just kidding, this is a not so serious post except for the previous 
sentence.)

-- 
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

[Jean-Pierre Flori]

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 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.
>
> Yes this one is fishy, and as you can see I did not mention it here :)
Anyway we are currently transitioning to Singular 4 (woohoo) so there is 
hope this is not needed anymore.
In fact it was maybe already fixed before...

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