Re: [sage-devel] Re: three.js on 7.5 beta 5: cpu...

[Thierry Dumont]

Le 02/12/2016 à 23:43, Paul Masson a écrit :
> Three.js performance is highly dependent on how the browser interacts
> with available graphics hardware. Chrome is the browser of choice for
> Three.js developers, but Firefox has made great improvements in the last
> couple years. If you're using the latest version of Firefox, then the
> bottleneck will be the GPU on your machine: if the browser can't
> interact efficiently with the GPU then the CPU has to pick up the slack.
> 
I use the beta version (weekly update) of Firefox.

But why is three.js consuming cpu when the browser shouls have nothing
to do ? (no interaction).

Ok, this is not very important.
t.d.

> Rendering this scene in Firefox on my year-old Macbook Pro settles down
> to around 30% of total CPU load. By contrast, rendering this scene in
> Firefox on my slightly older Windows 10 machine with a better GPU
> settles down to about 2% of total CPU load.
> 
> Opening multiple browser windows with Three.js scenes on my Macbook will
> bring the machine to a crawl and this is simply a machine limitation. I
> was initially worried this would be a major problem for Sage notebooks
> but it turns out not to be, since the notebook is a single browser window.
> 
> On Friday, December 2, 2016 at 7:31:27 AM UTC-8, tdumont wrote:
> 
> I have just tried three.js in 7.5 beta 5, doing (as in the doc):
> 
> sage: sage: p1 = sphere(color='red', opacity='.5')
> : sage: p2 = sphere((-1,-1,1), color='cyan', opacity='.3')
> : sage: p3 = sphere((1,-1,-1), color='yellow', opacity='.7')
> : sage: show(p1 + p2 + p3, viewer='threejs')
> 
> My firefox is launched, and the result is nice !
> 
> But looking at the cpu consumption of firefox, I found that it takes
> between 60% and 89% of one processor cpu time, even when I look at the
> steady graphic (mouse pointer out of the window).
> 
> May be there is nothing to do (some loop...),  but this is quite much!
> 
> t.d.
> 
> -- 
> 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: make giac/giacpy a standard package

[Ralf Stephan]

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.

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

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

[sage-devel] Re: three.js on 7.5 beta 5: cpu...

[Paul Masson]

Three.js performance is highly dependent on how the browser interacts with 
available graphics hardware. Chrome is the browser of choice for Three.js 
developers, but Firefox has made great improvements in the last couple 
years. If you're using the latest version of Firefox, then the bottleneck 
will be the GPU on your machine: if the browser can't interact efficiently 
with the GPU then the CPU has to pick up the slack.

Rendering this scene in Firefox on my year-old Macbook Pro settles down to 
around 30% of total CPU load. By contrast, rendering this scene in Firefox 
on my slightly older Windows 10 machine with a better GPU settles down to 
about 2% of total CPU load.

Opening multiple browser windows with Three.js scenes on my Macbook will 
bring the machine to a crawl and this is simply a machine limitation. I was 
initially worried this would be a major problem for Sage notebooks but it 
turns out not to be, since the notebook is a single browser window.

On Friday, December 2, 2016 at 7:31:27 AM UTC-8, tdumont wrote:
>
> I have just tried three.js in 7.5 beta 5, doing (as in the doc): 
>
> sage: sage: p1 = sphere(color='red', opacity='.5') 
> : sage: p2 = sphere((-1,-1,1), color='cyan', opacity='.3') 
> : sage: p3 = sphere((1,-1,-1), color='yellow', opacity='.7') 
> : sage: show(p1 + p2 + p3, viewer='threejs') 
>
> My firefox is launched, and the result is nice ! 
>
> But looking at the cpu consumption of firefox, I found that it takes 
> between 60% and 89% of one processor cpu time, even when I look at the 
> steady graphic (mouse pointer out of the window). 
>
> May be there is nothing to do (some loop...),  but this is quite much! 
>
> t.d. 
>

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

[Volker Braun]

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.

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

Hi ralf,
I am also lost because what you ask in this trac is what is done by the 
build/pkg/giac/spkg-src
{{{
VERSION="1.2.2"
VERSIONREV="103"

# The upstream tarball name is: giac"$SOURCEORIG".tar.gz
SOURCEORIG=_"$VERSION"-"$VERSIONREV"

...

# Downloading upstream source
sage-download-file 
"http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/giac$SOURCEORIG.tar.gz;
 
"giac$SOURCEORIG.tar.gz"
}}}
and I can see that bzip2, gap and singular also use a spkg-src so it looks 
allowed for a standard package to use an spkg-src when there is a reason 
right?
In giac I delete all the french html doc to have a 15Mb gpl tarball instead 
of the 49Mb original one. (the french html doc is only on a non commercial 
licence that's why I delete it)

So may be there is a misunderstanding somewhere?

If anyone still have explicit requirement for the giac spkg let me know.

Best
Frederic


Le vendredi 2 décembre 2016 16:54:29 UTC+1, Ralf Stephan a écrit :
>
> I opened https://trac.sagemath.org/ticket/22011
> to prepare the giac package to use the official tarballs.
>
> Regards,
>

-- 
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 07:54:29AM -0800, Ralf Stephan wrote:
> I opened https://trac.sagemath.org/ticket/22011
> to prepare the giac package to use the official tarballs.

What is the logical relation between "make giac a standard Sage package"
and "use the upstream unmodified tarball" ?

While both are legitimate, i do not understand the tie.

Ciao,
Thierry



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

[Ralf Stephan]

I opened https://trac.sagemath.org/ticket/22011
to prepare the giac package to use the official tarballs.

Regards,

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

[Thierry Dumont]

I have just tried three.js in 7.5 beta 5, doing (as in the doc):

sage: sage: p1 = sphere(color='red', opacity='.5')
: sage: p2 = sphere((-1,-1,1), color='cyan', opacity='.3')
: sage: p3 = sphere((1,-1,-1), color='yellow', opacity='.7')
: sage: show(p1 + p2 + p3, viewer='threejs')

My firefox is launched, and the result is nice !

But looking at the cpu consumption of firefox, I found that it takes
between 60% and 89% of one processor cpu time, even when I look at the
steady graphic (mouse pointer out of the window).

May be there is nothing to do (some loop...),  but this is quite much!

t.d.

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

[Ralf Stephan]

On Friday, December 2, 2016 at 1:49:57 PM UTC+1, Dima Pasechnik wrote:
>
> I was talking about silently changing a tarfile, without changing its name 
> at all.
>

That could happen with any package where the tarball is not on a typical 
repo server.
Is there a way for the release manager to check validity of the tarball 
link, e.g. automatically comparing with a template? If so then, as Han 
says, use the tarball from the official giac site with patches reviewed on 
trac. What else prevents giac from becoming a standard 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] Re: make giac/giacpy a standard package

[Dima Pasechnik]

On Friday, December 2, 2016 at 10:06:34 AM UTC, Ralf Stephan wrote:
>
> On Friday, December 2, 2016 at 10:51:47 AM UTC+1, Han Frederic wrote:
>>
>> We had this argument already. If you prefer to keep it this way, please 
 provide us a  VCS (git preferred) repo
 off which we can label releases by the latest commit in the master 
 branch, or something like this.
 This way at least meaningful bug reports can be filed. Please...
 We (or in fact any Linux/OSX distribution system) cannot work with 
 different tarballs that are named the same, we do not have tools to 
 support 
 this. Each tarball change without name change triggers an alert screaming 
 that it has been tampered with.

>>>
>> But the giac spkg is always built from these sources via the spkg-src:
>>
>> http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/
>> and they have a meaningful name. Ex: spkg 1.2.2.103 is from source 
>> 1.2.2-103.
>>
>
> I think numbering changes at level 4 are the problem that Dima (quote 
> above) meant.
> None of the toolos support it.
>

I was talking about silently changing a tarfile, without changing its name 
at all.
 

-- 
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 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 ? I can see two (quite marginal) use cases :


   - Military high-security un-networked machine users (who install and 
   update their software via sneakernet) ;
   - Monks (probably not even a plurality of them).

As far as I can tell, everybody else will have someday to hit the network 
(at least for PIP packages...).
 

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

That's more or less what I propose. You seem to be less affirmative than I 
would. 

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

Unacceptable, for practicability reasons (see above)

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

Hardly acceptable (how longer the PIP and R repositories will remain 
reachable without 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.
>

Dubious : where can one get "its own copy of the root certs" ? How secure 
*this* would be ? (And I have dark doubts on the possible consequences of 
the licensing issues...).

The logical conclusion would be to avoid Macs for this kind of use. (But I 
have to confess an old and deeply ingrained prejudice about these nice but 
way overpriced machines and Apple's shenanigans that forever try to chain 
you to ONE supplier, namely themselves...).

Should we discourage Sage potential users to buy Macs ?

Note that we *could* also (at least theoretically) try to replace Python's 
__ssl module with our own, more accommodating one, linked to our own 
TLSv12-enabled library. Somehow, I don't see *that* happen in a foreseeable 
future :-).

HTH (but I doubt it...)

--
Emmanuel Charpentier

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 

Re: [sage-devel] Re: make giac/giacpy a standard package

[Han Frederic]

Le vendredi 2 décembre 2016 11:06:34 UTC+1, Ralf Stephan a écrit :
>
> On Friday, December 2, 2016 at 10:51:47 AM UTC+1, Han Frederic wrote:
>>
>> We had this argument already. If you prefer to keep it this way, please 
 provide us a  VCS (git preferred) repo
 off which we can label releases by the latest commit in the master 
 branch, or something like this.
 This way at least meaningful bug reports can be filed. Please...
 We (or in fact any Linux/OSX distribution system) cannot work with 
 different tarballs that are named the same, we do not have tools to 
 support 
 this. Each tarball change without name change triggers an alert screaming 
 that it has been tampered with.

>>>
>> But the giac spkg is always built from these sources via the spkg-src:
>>
>> http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/
>> and they have a meaningful name. Ex: spkg 1.2.2.103 is from source 
>> 1.2.2-103.
>>
>
> I think numbering changes at level 4 are the problem that Dima (quote 
> above) meant.
> None of the toolos support it.
>
 
 I thought that dima was talking of the unstable file with only 1.2.2 in 
the name but was  OK with 1.2.2-xx?


> On 5/07/2016, at 17:13, parisse  wrote: 

> > 
> > disable-gui should be working. If not, then I probably made a mistake 
> while copying the archive, you can try 
> http://www-fourier.ujf-grenoble.fr/~parisse/giac/giac-1.2.2.tar.gz 
> 
>  
>
> Yes that tarball has the goods. I’ll wait for a new 1.2.2-xx tarball 
> though. No self respecting 
> packager wants to deal with an upstream tarball which changes all the 
> times. 


 


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

[Ralf Stephan]

On Friday, December 2, 2016 at 10:51:47 AM UTC+1, Han Frederic wrote:
>
> We had this argument already. If you prefer to keep it this way, please 
>>> provide us a  VCS (git preferred) repo
>>> off which we can label releases by the latest commit in the master 
>>> branch, or something like this.
>>> This way at least meaningful bug reports can be filed. Please...
>>> We (or in fact any Linux/OSX distribution system) cannot work with 
>>> different tarballs that are named the same, we do not have tools to support 
>>> this. Each tarball change without name change triggers an alert screaming 
>>> that it has been tampered with.
>>>
>>
> But the giac spkg is always built from these sources via the spkg-src:
>
> http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/
> and they have a meaningful name. Ex: spkg 1.2.2.103 is from source 
> 1.2.2-103.
>

I think numbering changes at level 4 are the problem that Dima (quote 
above) meant.
None of the toolos support 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] Re: make giac/giacpy a standard package

[Han Frederic]

Le vendredi 2 décembre 2016 08:37:20 UTC+1, Ralf Stephan a écrit :
>
> On Tuesday, July 5, 2016 at 9:31:04 AM UTC+2, Dima Pasechnik wrote:
>>
>> Yes that tarball has the goods. I’ll wait for a new 1.2.2-xx tarball 
>>> though. No self respecting 
>>> packager wants to deal with an upstream tarball which changes all the 
>>> times. 
>>
>>  
>> We had this argument already. If you prefer to keep it this way, please 
>> provide us a  VCS (git preferred) repo
>> off which we can label releases by the latest commit in the master 
>> branch, or something like this.
>> This way at least meaningful bug reports can be filed. Please...
>> We (or in fact any Linux/OSX distribution system) cannot work with 
>> different tarballs that are named the same, we do not have tools to support 
>> this. Each tarball change without name change triggers an alert screaming 
>> that it has been tampered with.
>>
>
>
But the giac spkg is always built from these sources via the spkg-src:
http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/
and they have a meaningful name. Ex: spkg 1.2.2.103 is from source 
1.2.2-103.
it worked fine since the begining of this repo (in 2014) so I don't 
understand the need of a new libgiac package from git that
 will conflict with the optional giac spkg. 

Although giacpy_sage could be built from your package(sage/libs/giac.py),  
I guess that the pexpect interface (sage/interfaces/giac.py) won't work 
(need the built of icas).


 

> As it seems (#21963) linking problems cannot be resolved without a 
> standard Giac package I'd like to restart the argument here.
> I successully cloned the giac core from the geogebra repo given here and 
> today fetched current changes, all via "git svn".
> That anwers the question of availability of an actively maintained and 
> public giac repo. Git config:
>
> [svn-remote "svn"]
> url = https://dev.geogebra.org/svn/trunk/geogebra/giac/src/giac
> fetch = :refs/remotes/git-svn
>
> However, the code in that giac subdirectory is bare bones, i.e., without 
> any autotools. The other question is, is this code sufficient to support 
> both sage/interfaces/giac.py and sage/libs/giac.py and if not,what would be 
> needed? Would it be easy to add the parser to it in C++ (the one in 
> geogebra is in java)? If not I might be tempted to create a third giac 
> package (libgiac) just for linking with Pynac, and the other giac package 
> can stay optional for eternity.
>
>

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

[Dima Pasechnik]

On Thursday, December 1, 2016 at 10:47:40 PM UTC, 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.
>
> 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,
>
> 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.
>

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? Or is it more fundamental than this?
  

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

Re: [sage-devel] SAGE_ATLAS_LIB vs openblas

[Francois Bissey]

> On 2/12/2016, at 21:30, Jean-Pierre Flori  wrote:
> 
> 
> 
> 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?


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.

Francois

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

Re: [sage-devel] 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] SAGE_ATLAS_LIB vs openblas

[Francois Bissey]

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

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.

[sage-devel] SAGE_ATLAS_LIB vs openblas

[Thierry]

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 ?

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 ?

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