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, Februa
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-devel+unsubscr...@googlegroups.com.
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
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
- kcrisman
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 escribió:
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?
> >>
> >
> > Unless you add -L$some_path, i
> 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
> found or
> incompatible, system
> 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:
> > cimport sage.libs.cypari2
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 not
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 w
10 matches
Mail list logo
