[sage-devel] Re: Installing pyopenssl for Sage 7.5.1 under Mac OS X 10.2.1 with xcode 8.2.1 not working

This seems to work with Sage 7.6. Somehow, it must have gotten fixed along the way. On Thursday, February 23, 2017 at 1:41:37 PM UTC-8, Dima Pasechnik wrote: > > looks like typical (by now) Apple's bug/feature --- using Objective C > syntax (blocks?) in plain C headers. > > > On Thursday,

Re: [sage-devel] 'make PACKAGE' does not build the toolchain

Feature Use "./sage -i PACKAGE" if you want to build the toolchain first. -- 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-combinat-devel] Sage Days 88: Opening Workshop for a Year of Coding Sprints at the IMA

Dear all, A year-long program at the IMA is being organized by Benjamin Brubaker and myself, beginning with an opening workshop August 21 - 25, 2017. Additionally, we have funding to host coding sprints during the 2017-18 academic year. The first application deadline is June 1, 2017 but we

[sage-devel] 'make PACKAGE' does not build the toolchain

If I unpack a Sage tarball, what should happen when I run 'make lcalc', for example? Should it be the same as running 'make', but stopping after the lcalc build? Right now, that does not seem to be the case: 'make lcalc' does not build the toolchain target, so on OS X or other systems requiring

[sage-devel] Better documentation on how to use spyx

There is woefully little about how to properly use these in the Sage documentation. See https://trac.sagemath.org/ticket/22698 if you can help improve this - I was alerted to it via http://stackoverflow.com/questions/43067894/differences-between-sage-and-spyx-in-numerical-evaluation -

Re: [sage-devel] Re: jsmol.js

Is there an easy way to make it work in jupyterhub? In jupyter, sage-7.6 works without any problem; for jupyterhub, threejs works but jsmol still doesn't. Thanks for the hard work. I can test any solution. Best, Enrique. El martes, 1 de noviembre de 2016, 20:03:52 (UTC+1), Volker Braun

Re: [sage-devel] linker options for C code in ext/interpreters and other stuff in sagelib

On Tuesday, March 28, 2017 at 9:13:13 AM UTC+1, François wrote: > > > > On 28/03/2017, at 21:07, Francois Bissey > wrote: > > > >> Does such "#distutils: libraries = blah " automatically imply that > libblah from $SAGE_LOCAL/lib/ will be linked? > >> > > >

Re: [sage-devel] linker options for C code in ext/interpreters and other stuff in sagelib

> On 28/03/2017, at 21:07, Francois Bissey > wrote: > >> Does such "#distutils: libraries = blah " automatically imply that libblah >> from $SAGE_LOCAL/lib/ will be linked? >> > > Unless you add -L$some_path, it should be the first one tried. If it is not

Re: [sage-devel] linker options for C code in ext/interpreters and other stuff in sagelib

> On 28/03/2017, at 21:04, Dima Pasechnik wrote: > > > > On Tuesday, March 28, 2017 at 8:32:53 AM UTC+1, Jeroen Demeyer wrote: > On 2017-03-27 23:15, François Bissey wrote: > > The generated sage/ext/interpreters/wrapper_cdf.pxd has the following > > statement: > >

Re: [sage-devel] Re: linker options for C code in ext/interpreters and other stuff in sagelib

On Tuesday, March 28, 2017 at 8:32:53 AM UTC+1, Jeroen Demeyer wrote: > > On 2017-03-27 23:15, François Bissey wrote: > > The generated sage/ext/interpreters/wrapper_cdf.pxd has the following > > statement: > > cimport sage.libs.cypari2.types > > > > That would pull `-lpari`. > > That's

Re: [sage-devel] Re: linker options for C code in ext/interpreters and other stuff in sagelib

On 2017-03-27 23:15, François Bissey wrote: The generated sage/ext/interpreters/wrapper_cdf.pxd has the following statement: cimport sage.libs.cypari2.types That would pull `-lpari`. That's not actually true. Just using the *types* from PARI doesn't need linking against PARI. It's cysignals