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

2016-12-02 Thread 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

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

2016-12-02 Thread 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

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

2016-12-02 Thread 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 w

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

2016-12-02 Thread 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

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

2016-12-02 Thread 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

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

2016-12-02 Thread 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" ? Whi

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

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

2016-12-02 Thread 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 f

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

2016-12-02 Thread 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

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

2016-12-02 Thread 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 rele

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

2016-12-02 Thread 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

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

2016-12-02 Thread 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 relea

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

2016-12-02 Thread 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. >

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

2016-12-02 Thread 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 tarbal

Re: [sage-devel] SAGE_ATLAS_LIB vs openblas

2016-12-02 Thread 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

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

2016-12-02 Thread 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 shoul

Re: [sage-devel] SAGE_ATLAS_LIB vs openblas

2016-12-02 Thread 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/atl

Re: [sage-devel] SAGE_ATLAS_LIB vs openblas

2016-12-02 Thread 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 > >

Re: [sage-devel] SAGE_ATLAS_LIB vs openblas

2016-12-02 Thread 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,

[sage-devel] SAGE_ATLAS_LIB vs openblas

2016-12-02 Thread 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 prefe

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

2016-12-02 Thread 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 sho