[sage-devel] Re: devising a speed comparison test between different types

[Ralf Stephan]

On Sunday, December 4, 2016 at 12:00:58 AM UTC+1, Pierre wrote:
>
> I tried naive things like setting x and y to be integers of a certain 
> type, and then
>
> sage: %timeit x^y
>
> for example, but I always get ""  The slowest run took 59.81 times longer 
> than the fastest. This could mean that an intermediate result is being 
> cached. ""
>

Yes, the first computation is relevant so instead of timeit I would use 
time.
 

> This makes sense, but I'm not sure what else to try. Individual " %time 
> x^y " statements seem to show no difference between ZZ and numpy.int, for 
> example, which puzzles me (overhead?). Exact same issues when defining the 
> factorial via
>

Both ZZ and numpy use libgmp internally so if you subtract other factors 
the times should be similar.
 

> fac= lambda n : 1 if n == 0 else n*fac(n-1)
>

Note however that most of the time for fac is used for the Python loop.
 
sage: %time _=fac(500)
CPU times: user 397 µs, sys: 0 ns, total: 397 µs
Wall time: 344 µs
sage: %time _=factorial(500)
CPU times: user 14 µs, sys: 6 µs, total: 20 µs
Wall time: 21.9 µs

Also note that time for converting the internal result to string output can 
be significant as well.

So here is my question: does anybody know of a basic test/piece of code 
> that would illustrate the difference in speed between various types of 
> integers and/or floats?
>

As shown the differences are irrelevant if you allow other factors.

-- 
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] devising a speed comparison test between different types

[Pierre]

Hi,

I hope that this is appropriate for sage-devel, as it is technical. 

As some colleagues who are new to Sagemath were asking me what I knew, I 
realized that I was unable to comment very sensibly on the various types of 
integers and of real numbers treated by Sage (no doubt because in my own 
research, ZZ and QQ are basically fine, as far as real numbers go). This 
question is bound to come up again, and I'm curious, so I'd like to find 
out.

We are talking about very basic advice to give to a beginner, and so, I 
knew enough to say that well, C ints (so I guess numpy.int's) will be fast, 
but limited in size, and elements of ZZ can be as large as your memory 
allows etc (and a similar, but different, discussion with RDF (or 
numpy.float) and RR etc). However, I am unable to write a piece of code 
that would clearly show the difference in speed ! 

I tried naive things like setting x and y to be integers of a certain type, 
and then

sage: %timeit x^y

for example, but I always get ""  The slowest run took 59.81 times longer 
than the fastest. This could mean that an intermediate result is being 
cached. ""

This makes sense, but I'm not sure what else to try. Individual " %time x^y 
" statements seem to show no difference between ZZ and numpy.int, for 
example, which puzzles me (overhead?). Exact same issues when defining the 
factorial via

fac= lambda n : 1 if n == 0 else n*fac(n-1)

and trying to time fac(500): about the same with ZZ and numpy.int.

I thought about multiplying large matrices, but I'm afraid that completely 
different algorithms/libraries will be used depending on the parent ring 
(say, for numpy.int it would be numpy matrix multiplication, obviously very 
fast), and that's no good: I would just like to emphasize the difference in 
speed for basic operations like + or *.

Here i'm not talking about Cython: sure, I tried 'int' and 'double' in 
Cython code, it's blazingly fast, but that's not the question here.

So here is my question: does anybody know of a basic test/piece of code 
that would illustrate the difference in speed between various types of 
integers and/or floats?

thanks!

Pierre








-- 
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: three.js on 7.5 beta 5: cpu...

[Paul Masson]

On Saturday, December 3, 2016 at 2:30:36 PM UTC-8, William wrote:
>
> On Sat, Dec 3, 2016 at 2:28 PM, Paul Masson  > wrote: 
> > There's apparently no good way in general to test whether the scene is 
> > unchanged. This is a known issue: 
> > 
> > https://github.com/mrdoob/three.js/issues/7670 
> > 
> > One of the comments on this thread offers another option: only render 
> the 
> > scene upon user interaction. I'm so accustomed to writing Three.js to be 
> > ready for animation that I didn't think about this. If we restrict 
> Three.js 
> > usage in Sage to static scenes then CPU usage drops to nothing. 
> > 
> > I'm happy to make this change, but this means no animations in the 
> scenes 
> > for now. 
>
> What kind of animations are currently implemented? 
> I can only think of spin=[number]. 
>
>  -- William 
>

None right now, but the changes necessary to get rendering to work without 
an animation loop don't play nicely with requestAnimationFrame. 

-- 
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: three.js on 7.5 beta 5: cpu...

[William Stein]

On Sat, Dec 3, 2016 at 2:28 PM, Paul Masson  wrote:
> There's apparently no good way in general to test whether the scene is
> unchanged. This is a known issue:
>
> https://github.com/mrdoob/three.js/issues/7670
>
> One of the comments on this thread offers another option: only render the
> scene upon user interaction. I'm so accustomed to writing Three.js to be
> ready for animation that I didn't think about this. If we restrict Three.js
> usage in Sage to static scenes then CPU usage drops to nothing.
>
> I'm happy to make this change, but this means no animations in the scenes
> for now.

What kind of animations are currently implemented?
I can only think of spin=[number].

 -- William

>
>
> On Saturday, December 3, 2016 at 1:11:31 PM UTC-8, Volker Braun wrote:
>>
>> Well if the scene is static, the controls didn't change, and the canvas
>> size didnt't change then your callback in requestAnimationFram should just
>> do nothing instead of repainting the unchanged scene, right?
>>
>>
>>
>> On Saturday, December 3, 2016 at 9:46:50 PM UTC+1, Paul Masson wrote:
>>>
>>>
>>>
>>> On Friday, December 2, 2016 at 11:47:40 PM UTC-8, tdumont wrote:


 But why is three.js consuming cpu when the browser shouls have nothing
 to do ? (no interaction).
>>>
>>>
>>> There is a rendering loop that runs continuously to call
>>> requestAnimationFram(). This is a standard technique for JavaScript
>>> animations in the browser.
>
> --
> 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.



-- 
William (http://wstein.org)

-- 
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: three.js on 7.5 beta 5: cpu...

[Paul Masson]

There's apparently no good way in general to test whether the scene is 
unchanged. This is a known issue:

https://github.com/mrdoob/three.js/issues/7670

One of the comments on this thread offers another option: only render the 
scene upon user interaction. I'm so accustomed to writing Three.js to be 
ready for animation that I didn't think about this. If we restrict Three.js 
usage in Sage to static scenes then CPU usage drops to nothing.

I'm happy to make this change, but this means no animations in the scenes 
for now.

On Saturday, December 3, 2016 at 1:11:31 PM UTC-8, Volker Braun wrote:
>
> Well if the scene is static, the controls didn't change, and the canvas 
> size didnt't change then your callback in requestAnimationFram should just 
> do nothing instead of repainting the unchanged scene, right?
>
>
>
> On Saturday, December 3, 2016 at 9:46:50 PM UTC+1, Paul Masson wrote:
>>
>>
>>
>> On Friday, December 2, 2016 at 11:47:40 PM UTC-8, tdumont wrote:
>>>
>>>
>>> But why is three.js consuming cpu when the browser shouls have nothing 
>>> to do ? (no interaction). 
>>>
>>
>> There is a rendering loop that runs continuously to call 
>> requestAnimationFram(). 
>> This is a standard technique for JavaScript animations in the browser. 
>>
>

-- 
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: three.js on 7.5 beta 5: cpu...

[William Stein]

On Sat, Dec 3, 2016 at 1:11 PM, Volker Braun  wrote:
> Well if the scene is static, the controls didn't change, and the canvas size
> didnt't change then your callback in requestAnimationFram should just do
> nothing instead of repainting the unchanged scene, right?

+1   -- I just checked and our three.js implementation for SMC doesn't
have this problem.It's definitely not a necessary "standard
technique for JavaScript animations in the browser" to burn CPU
needlessly.

 -- William


>
>
>
> On Saturday, December 3, 2016 at 9:46:50 PM UTC+1, Paul Masson wrote:
>>
>>
>>
>> On Friday, December 2, 2016 at 11:47:40 PM UTC-8, tdumont wrote:
>>>
>>>
>>> But why is three.js consuming cpu when the browser shouls have nothing
>>> to do ? (no interaction).
>>
>>
>> There is a rendering loop that runs continuously to call
>> requestAnimationFram(). This is a standard technique for JavaScript
>> animations in the browser.
>
> --
> 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.



-- 
William (http://wstein.org)

-- 
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: three.js on 7.5 beta 5: cpu...

[Volker Braun]

Well if the scene is static, the controls didn't change, and the canvas 
size didnt't change then your callback in requestAnimationFram should just 
do nothing instead of repainting the unchanged scene, right?



On Saturday, December 3, 2016 at 9:46:50 PM UTC+1, Paul Masson wrote:
>
>
>
> On Friday, December 2, 2016 at 11:47:40 PM UTC-8, tdumont wrote:
>>
>>
>> But why is three.js consuming cpu when the browser shouls have nothing 
>> to do ? (no interaction). 
>>
>
> There is a rendering loop that runs continuously to call 
> requestAnimationFram(). 
> This is a standard technique for JavaScript animations in the browser. 
>

-- 
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: three.js on 7.5 beta 5: cpu...

[Paul Masson]

On Friday, December 2, 2016 at 11:47:40 PM UTC-8, tdumont wrote:
>
>
> But why is three.js consuming cpu when the browser shouls have nothing 
> to do ? (no interaction). 
>

There is a rendering loop that runs continuously to call 
requestAnimationFram(). 
This is a standard technique for JavaScript animations in the browser. 

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

[Thierry]

On Sat, Dec 03, 2016 at 05:55:19PM +0100, Emmanuel Charpentier wrote:
> The key words are "within the Sage source"... ;-)
> 
> More on this later (i'a bit overwhelmed right now).

Note that the following is already possible, though it seems irrelevant
for macs, which are the real problem (since most (if not all) GNU/Linux
distros ship some openssl-dev package):

On Mon, Nov 21, 2016 at 05:09:36PM +0100, Thierry wrote:
[...]
>
> - check that openssl-dev (or equivalent) is installed system-wide
> - if not:
>   - warn the user and suggest/recommend her to install it
>   - as an alternative, propose to download and install openssl from the
> Sage mirrors via http
> - build Sage

Ciao,
Thierry

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

[Emmanuel Charpentier]

The key words are "within the Sage source"... ;-)

More on this later (i'a bit overwhelmed right now).

--
Emmanuel Charpentier

Le 3 déc. 2016 17:51, "Thierry"  a écrit :

On Sat, Dec 03, 2016 at 02:50:19PM +0100, Emmanuel Charpentier wrote:
[...]
> Ok. So we might try the following sequence :
>
> 1) in a pristine, openssl-virgin VM, compile Sage, and test pip's
> ability to work (test 0, negative, as you proved).
>
> 2) install Sage's openssl, test pip's ability (test 1)
>
> If test1 positive, we win.
>
> If test 1 is negative, as you think
>
> 3a) update Python (./sage -f python2), and re-test pip's ability (test
> 2)
>
> if test 2 positive, we win (serendipitously).

I will try this, but it is supposed to work already (this is why an
optional openssl Sage package exists and is maintained).

I think i do not understand why it let us win, since we can not distribute
openssl tarball within the Sage source code anyway.

Ciao,
Thierry

--
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/92OdoUbBDbE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Thierry]

On Sat, Dec 03, 2016 at 02:50:19PM +0100, Emmanuel Charpentier wrote:
[...]
> Ok. So we might try the following sequence :
> 
> 1) in a pristine, openssl-virgin VM, compile Sage, and test pip's
> ability to work (test 0, negative, as you proved).
> 
> 2) install Sage's openssl, test pip's ability (test 1)
> 
> If test1 positive, we win.
> 
> If test 1 is negative, as you think
> 
> 3a) update Python (./sage -f python2), and re-test pip's ability (test
> 2)
> 
> if test 2 positive, we win (serendipitously).

I will try this, but it is supposed to work already (this is why an
optional openssl Sage package exists and is maintained).

I think i do not understand why it let us win, since we can not distribute
openssl tarball within the Sage source code anyway.

Ciao,
Thierry

-- 
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: make giac/giacpy a standard package

[Han Frederic]

Le samedi 3 décembre 2016 13:55:30 UTC+1, Jeroen Demeyer a écrit :
>
> On 2016-07-03 21:08, Han Frederic wrote: 
> > Yes these binaries were left in upstream 1.2.2-37 source tarball, but it 
> > is a mistake. 
>
> How do you create those binaries? It should be done by a script ("make 
> dist" if you use autotools), not by hand. 
>

I don't create binaries, they were alerady in B.Parisse's tarball by 
mistake from (1.2.2-35 to 1.2.2-45) cf the bigger files in:
http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/

But I have missed they were there, I should have deleted 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] Re: OpenSSL as a new systemwide Sage dependency ?

[Emmanuel Charpentier]

Le samedi 03 décembre 2016 à 13:02 +0100, Thierry a écrit :
> Hi,
> 
> On Sat, Dec 03, 2016 at 10:48:18AM +0100, Emmanuel Charpentier wrote:
> [...] 
> > If you still have this VM, could you try to add the current
> > "openssl"
> > Sage package and tell us if , after this addition, "sage -pip list"
> > works ?
> 
> I droped it, but i can create a new one. Do you mean just add `./sage
> -i
> openssl` after compiling ?
That's what I thought. But you gave me (below) another idea. See below

> Otherwise, give me the exact order of the
> operations you want to test (starting from initial deps and make
> command).
> 
> I am pretty sure openssl will not be taken into account until you
> recompile python2 (at least it was the case a few months ago), python
> seems not trying to guess system's libs at runtime.

Ok. So we might try the following sequence :

1) in a pristine, openssl-virgin VM, compile Sage, and test pip's
ability to work (test 0, negative, as you proved).

2) install Sage's openssl, test pip's ability (test 1)

If test1 positive, we win.

If test 1 is negative, as you think

3a) update Python (./sage -f python2), and re-test pip's ability (test
2)

if test 2 positive, we win (serendipitously).

if test2 negative, you just proved that the openssl package is not
sufficient. Which answers the "dependency on OpenSSL" question.

It would be useful to keep this VM around, because the same tests will
be interesting to run in order to test R's ability to use https-only R
repositories.


HTH,

--
Emmanuel Charpentier

> 
> Ciao,
> Thierry
> 

-- 
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: make giac/giacpy a standard package

[Jeroen Demeyer]

On 2016-07-03 21:08, Han Frederic wrote:

Yes these binaries were left in upstream 1.2.2-37 source tarball, but it
is a mistake.


How do you create those binaries? It should be done by a script ("make 
dist" if you use autotools), not by hand.


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

[Volker Braun]

+1 for the manual (bring your own .pc file) approach to blas configuration. 
Otherwise you'd need configure switches for all combinations of 
(blas+cblas+lapack) * (cflags+ldflags+libs) which would make it even more 
difficult to use.

-- 
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: make giac/giacpy a standard package

[Thierry]

Hi,

On Fri, Dec 02, 2016 at 10:59:48PM -0800, Ralf Stephan wrote:
> Apologies. I had the impression that repackaging is frowned upon for 
> security reasons. However, just removing files can be automated, either by 
> the original author or the Sage release manager, so there is room for 
> improvement.

I also like the fact that we use untouched upstream tarball. I was just
pointing that it was not related to making a package standard (look, e.g.
at rubiks bundle). It would be good to transform the 'sed' part of giac's
spkg-src into a real patch.

> So, for making giac standard package, we are practically waiting for the 
> release manager to just do it, right?

I guess the usual procedure is to ask for consensus on sage-devel, then
create a ticket that changes the 'type' file from 'optional' to
'standard', then indeed the release-manager will add the tarball to Sage
source tarball.

Ciao,
Thierry

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

[Thierry]

Hi,

On Sat, Dec 03, 2016 at 10:48:18AM +0100, Emmanuel Charpentier wrote:
[...] 
> If you still have this VM, could you try to add the current "openssl"
> Sage package and tell us if , after this addition, "sage -pip list"
> works ?

I droped it, but i can create a new one. Do you mean just add `./sage -i
openssl` after compiling ? Otherwise, give me the exact order of the
operations you want to test (starting from initial deps and make command).

I am pretty sure openssl will not be taken into account until you
recompile python2 (at least it was the case a few months ago), python
seems not trying to guess system's libs at runtime.

Ciao,
Thierry

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

[Thierry]

Hi,

On Sat, Dec 03, 2016 at 10:00:51AM +0100, Jeroen Demeyer wrote:
> On 2016-12-02 09:21, Thierry wrote:
> >Would it be
> >preferable to have this possibility dealt at configure time
> 
> Absolutely. Whatever you do, do *NOT* introduce a new environment variable.

Why ? We do this for various things.

Ciao,
Thierry


> Use a configure option instead.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Thierry]

On Sat, Dec 03, 2016 at 10:43:07AM +0100, Emmanuel Charpentier wrote:
[...]
> It remains to be seen if our "openssl" package allows a Sage system,
> initially compiled with, say, GnuTLS, to use, say PIP. That could be an
> hypocritical but efficient workaround.

No, you will have to recompile (at least) python2.

Ciao,
Thierry

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

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

[Emmanuel Charpentier]

Le vendredi 02 décembre 2016 à 13:23 -0800, Volker Braun a écrit :
> On Friday, December 2, 2016 at 9:39:13 AM UTC+1, Dima Pasechnik
> wrote:
> > Do you understand the story about root certs here? Is it a missing
> > python code (in some package, existing or not?) that would be able
> > to access OSX certs store? 
> 
> Apple has the root certs in their own keychain, which OpenSSL can't
> read (i.e. Apple did not upstream their patches to OpenSSL). You can
> manually extract the root certs or download an independent copy of
> them. Either way, a self-compiled OpenSSL will not benefit from OS
> updates to the root cert store.

This is an extremely serious problem, which I didn't grasp initially.
(To me, it's probably a conta-indication of Macs to anything a bit
serious : somehow, I have less trust in Apple's administration of the
root certs than, say, Debian's. Prejudiced ? Certainly : I've been
burned before...).
Do you know if openSSL could be retro-patched to be able to use the
systemwide installation of Apple's root certs (which, by hypothesis,
would be updated as needed) as a default ? I think that this question
has both technical and (pseudo-)legal aspects.
--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] Re: OpenSSL as a new systemwide Sage dependency ?

[Emmanuel Charpentier]

Dear Thierry,

Le jeudi 01 décembre 2016 à 22:56 +0100, Thierry 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.

If you still have this VM, could you try to add the current "openssl"
Sage package and tell us if , after this addition, "sage -pip list"
works ?

Thank you in advance !

--
Emmanuel Charpentier

> Ciao,
> Thierry
> 
> 
>  
> > There are only two possible results, and two sets of action :
> > 
> >    1. If no part of Sage depends on openSSL exclusively : fine.
> > package and 
> >    ship Gnu TLS as a standard package, and be done with the damn
> > thing
> >    2. If some part of Sage need openSSL exclusively : since we
> > *can* use a 
> >    systemwise installation but cannot (pseudo-legally) *ship* it,
> > we just 
> >    *have to* depend on this systemwide installation. Add it to the 
> >    prerequisites, and be done with it.
> > 
> > 
> > So this inventory is crucial.
> > 
> > What do you know about these dependencies ?
> > 
> > --
> > Emmanuel Charpentier
> > 
> > Le lundi 21 novembre 2016 12:21:31 UTC+1, Emmanuel Charpentier a
> > écrit :
> > > 
> > > Dear list,
> > > 
> > > The fact that we can't ship openSSL (see uncountable theads in
> > > sage-devel 
> > > and others) seems to pose more and more difficulties. See for
> > > example this 
> > > thread  > > uGT2ViM> 
> > > on sage-support, and especially Dima's answer 
> > >  > > KAwAJ>, 
> > > as well as this annoying ticket  > > /21767>, 
> > > discussed in this saga 
> > > 
> > > . 
> > > 
> > > Could'nt we add OpenSSL as a prerequisite to Sage, and it"s
> > > development 
> > > files as a prerequisite to building Sage ? This would require of
> > > the user 
> > > to install OpenSSL systemwide, thus making it "system software"
> > > and 
> > > satisfying the strange licensing requirements that bother us.
> > > 
> > > One could even do that indirectly, by requiring a systemwide
> > > libcurl 
> > > supporting https : this would de facto enforce the systemwide
> > > installation 
> > > of OpenSSL (or a reasonable facsimile). That's what I was trying
> > > to do in this 
> > > proposal ...
> > > (IIRC, 
> > > the problem with libcurl is also bound to OpenSSL : libcurl
> > > itself is not a 
> > > problem. But I'll have to check : if this is true, we can require
> > > OpenSSL 
> > > and ship libcurl which will then compile cleanly).
> > > 
> > > Comments ? Especially wrt Macs, which seem to be further
> > > encumbered by 
> > > Apple's dirty tricks...
> > > 
> > > Should we have a vote ?
> > > 
> > > --
> > > 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.
> 
> 

-- 
You received this message because you are subscribed 

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

[Emmanuel Charpentier]

Le samedi 03 décembre 2016 à 10:07 +0100, Jeroen Demeyer a écrit :
> On 2016-12-02 12:50, Emmanuel Charpentier wrote:
> > Le jeudi 1 décembre 2016 23:47:40 UTC+1, Volker Braun a écrit :
> > 
> > On Linux, you can build Sage with and without openssl. If you
> > ever
> > hit the network
> > 
> > 
> > Who doesn't ?
> 
> The 95% of Sage users who just uses Sage for computations and
> doesn't 
> want to install any packages.

Hmmm... Where do you pull your "95%" figure from ?

> That's why I'm against depending on system OpenSSL: you are adding
> an 
> extra hurdle for everybody 

It's, at worst, an extra dependency. Of which we already have some lot
(see README.md...).

> for the benefit of a minority of users.

Again : why "minority" ? 

And why do you postulate that Sage and its components have a vocation
to stay self-enclosed and forever stable ? The activity of the sage-
devel list shows that  the ability to update, upgrade and extend Sage
is important.

That is true, with severe aggravation, for R : while essential, the
"core" functionality of R is small (if not tiny) when compared to the
9000+ packages available. an unextensible R would be as useful as a
teaspoon to empty the Mediterranean...

On the top of that, Sage itself uses the net extensively. It uses tens
of Python packages, which need maintainance and possibly extension.

I'm afraid that your "average user" who "just uses Sage for
computations and doesn't want to install any packages" is about as
mythical as Ronald Reagan's "welfare queen" : a nice strawman useful to
hide a serious problem.

(In fact, two serious problems : Volker's explanation of Apple's root
certs problem makes me think that this is, for Mac users, even more
serious : they are chained to "the Apple" store" for the life of their
Macs. More of this as an answer to Volker's post).

It remains to be seen if our "openssl" package allows a Sage system,
initially compiled with, say, GnuTLS, to use, say PIP. That could be an
hypocritical but efficient workaround.

HTH,

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

[Thierry]

Hi,

On Fri, Dec 02, 2016 at 03:50:07AM -0800, Emmanuel Charpentier wrote:
[...]
> As far as I can tell, everybody else will have someday to hit the network
> (at least for PIP packages...).

It is not always possible. At least many users of Sage Debian Live from
places where there is not (much) network should not be dependent of
internet connection, not only in remote areas (which was the use case for
the creation of SDL): it has also been required during various workshops,
where this was necessary e.g. when the wifi does not allow guests to be
connected.

We should still be able to propose a self-contained software (while at the
same time let the possibility to use distro's deps). Regarding source
tarball, it might (?) be a good idea to ship an extended tarball with all
optional and pip packages (e.g. by letting pip to look into the upstream/
directory before going to PyPI).

BTW, it is pretty important that Sage only connects to the internet when
explicitely asked by the user (e.g. when using oeis). Currently, pip is
leaking when used, just to check latest version, it is pretty annoying.
The use of a remote three.js CDN is also problematic with that respect.

Ciao,
Thierry
 

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

[Francois Bissey]

> On 3/12/2016, at 22:00, Jeroen Demeyer  wrote:
> 
> On 2016-12-02 09:21, Thierry wrote:
>> Would it be
>> preferable to have this possibility dealt at configure time
> 
> Absolutely. Whatever you do, do *NOT* introduce a new environment variable. 
> Use a configure option instead.

Actually no need for a new variable at all.
Create a directory “dir”, put/copy/create
blas.pc, cblas.pc and lapack.pc in said directory.

PKG_CONFIG_PATH=$dir make
will still build openblas but the blas defined 
by the .pc files in $dir will be used first.

François

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at 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 ?

[Jeroen Demeyer]

On 2016-12-02 12:50, Emmanuel Charpentier wrote:

Le jeudi 1 décembre 2016 23:47:40 UTC+1, Volker Braun a écrit :

On Linux, you can build Sage with and without openssl. If you ever
hit the network


Who doesn't ?


The 95% of Sage users who just uses Sage for computations and doesn't 
want to install any packages.


That's why I'm against depending on system OpenSSL: you are adding an 
extra hurdle for everybody for the benefit of a minority of users.


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

[Jeroen Demeyer]

On 2016-12-02 09:21, Thierry wrote:

Would it be
preferable to have this possibility dealt at configure time


Absolutely. Whatever you do, do *NOT* introduce a new environment 
variable. Use a configure option instead.


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