Try doing
sage: hg_scripts.merge()
sage: hg_scripts.commit()
and answer any interactive questions.
This doesn't seem to do anything:
sage: hg_scripts.merge()
cd /pkgs/sage-2.7.1/local/bin hg merge
abort: there is nothing to merge - use hg update instead
sage: hg_scripts.commit()
cd
On Nov 23, 4:20 am, mabshoff wrote:
More to the point, I do recall being asked some questions by hg
during the upgrade process ((k)eep or (d)iscard or similar). ...
It might have been captured in the log. Could you check there? It has
come up at least twice with 2.8.13 and we should
As before, you need to install mayavi (perhaps sage -i
mayavi_2.0.20080117 will work, at least under Linux); then run sage -
wthread,
This mayavi package didn't work for me on the following system:
OS: OS X version 10.4.11 with gcc 4.0.1 build 5367
Hardware: Intel Core 2 Duo
Sage: Clean
One feature that would be really nice is to have distinct text cells,
in html or even better latex mode. A text cell could created by a hot key
(say
cntrl-t) in edit mode which displays the source latex or html, then toggled
out
of edit mode to display the formatted text. This could be
The ace-5.0.spkg for the GAP component is broken --- it tries to copy
itself into the non-existent directory of GAP version 4.4.9 instead of
the current 4.4.10. This is a one line fix to the spkg-install
file. I've put a fixed version at
http://dunfield.info/temp/ace-5.0.spkg
I'm not sure
VIII. Finite Groups; Finitely-Presented Groups
* I'm not enough of a group theorist to appreciate differences
between what Sage provides via GAP and Magma. They seem pretty
similar to me for group theory. Sage exposes much of GAP's
functionality for groups.
William,
I
Much more complicated would it be to construct a Seifert surface of
*minimal* genus. It is possible, though, based on the theory of normal
surfaces that goes back to Wolfgang Haken. In a nutshell (hope I
remember things correctly):
Yes, you do.
In the Wiki, I mention a package t3m, that,
If there are any OS X sysadmins out there that actually know how to
create accounts remotely via the command line, let me know.
William,
The following works for me under 10.5.8:
sudo mkdir -p /Users/ta
sudo dscl . -create /Users/ta
sudo dscl . -create /Users/ta PrimaryGroupID 20
sudo dscl .
On Aug 20, 10:22 am, William Stein wst...@gmail.com wrote:
On Thu, Aug 20, 2009 at 7:59 AM, Nathan Dunfieldnat...@dunfield.info wrote:
If there are any OS X sysadmins out there that actually know how to
create accounts remotely via the command line, let me know.
William,
The following
Yes, I got confused between Nathans. Sorry. And many thanks again for the
directions!!
You're welcome. It's often annoying how hard it is to do certain
administrative tasks on OS X from the command line. Even for just
creating an account, it's no harder to do a full screenshare via ssh
and
On Sep 4, 12:26 am, William A. Stein wst...@gmail.com wrote:
Also, it would just be very nice having an easy scratchpad anywhere in
an worksheet.
As a topologist, I couldn't agree more. ;-)
Nathan
--~--~-~--~~~---~--~~
To post to this group, send an email to
So, I vote +1 to include it at least as an optional package. Making it
a standard part of SAGE
should IMHO wait until a solid FreeGroup and FinitelyPresentedGroup
(Python) class are created for SAGE. If I had more time I would do this
myself.
Yeah, it would be great if SAGE had support of
I'm working on an Cython extension module for Sage, but source code
introspection isn't working for me.
The extension is built from a single *.pyx file via the following
setup.py file:
-setup.py-
from distutils.core import setup
from distutils.extension import Extension
from
When you run the build command *precisely* what Cython and GCC
commands are executed? I.e., touch the .pyx file, rebuild it
and paste the build log into an email.
William,
It's below
System: MacPro 8 core (Jan 2008) with OS 10.5
gcc: i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc.
Oh, that's annoying, it doesn't display the Cython command line.
Anyway, if you don't give the -p or --embed-positions option to
Cython, then source introspection should *not* work:
I cython'd on the command line with the -p option and then setup.py
installed.
I now get a different error
William and Nick,
With the default cythoning, introtest.intro.__doc__ is empty (as
there is no docstring). If I invoke cython by hand with the -p
option, intro.__doc__ becomes
'File: introtest.pyx (starting at line 1)'
If I then copy introtest.pyx to $SAGEROOT/devel/sage, then source
On May 14, 6:33 am, David Joyner [EMAIL PROTECTED] wrote:
I cannot find the code browser or wiki links, both of which I use a lot.
Maybe that is because it is so slow, I give up looking. For me, each page
takes
30 seconds. I guess sagemath.org is just slow this morning
I just tried
[X] Yes, for removal. I tried with little success to use dsage some
years ago, but quickly switched to the processing module.
Nathan
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
manifolds,
can also work with hyperbolic knots, etc.
If I understand correctly, it is under GNU GPL and may be used as a
Python module.
A longtime Sage user -- Nathan Dunfield -- I think wrote the Python
interface, and uses SnapPea from Sage for his research.
Actually, most of the current
Having glanced at the other projects this one seems to be the most
promising, but it certainly seems rather strange regarding build
system and so on. I.e. I did not see any obvious way to build the
kernel as a library for example. There is no meaningful documentation,
but a longer worded
I'm having the following problem with basic symbolics in Sage 4.3.2.
I create some variables with var, combine them into rational
functions, then take their numerator and denominator and coerce them
into a PolynomialRing. This works fine most of the time, but very
occasionally (every few 1
On Apr 14, 2:57 pm, William Stein wst...@gmail.com wrote:
You should post exact code so that we can replicate your problem.
I've boiled down the problem into the example below. Just attach and
then run prob().
One thing to note is that's just doing the exact same thing again and
again, but
Here is a more concise, but essentially equivalent, code snippet which
exhibits the problem. Just attach and run prob() Again, it takes
10-12 minutes to crash on my MacPro3,1 with 2 Quad-Core Xeon
Processors @ 2.8 Ghz, running 10.5.8, with Sage 4.3.2 self-compiled
with
Here is a more concise, but essentially equivalent, code snippet which
exhibits the problem. Just attach and run prob() Again, it takes
10-12 minutes to crash on my MacPro3,1 with 2 Quad-Core Xeon
Processors @ 2.8 Ghz, running 10.5.8, with Sage 4.3.2 self-compiled
with
I can confirm that the above function eventually desynchronizes Maxima;
I'm using Sage 4.3.5 with Ubuntu 9.10 on a quad-core Core 2 processor.
One more date point: I reproduced the problem on my Mac Book, which
has a dual-core Core 2. Despite the fact that it's a lot slower than
my Mac Pro, it
To follow up on myself one last time, here's what appears to be the
minimal example exhibiting thisproblem
def prob():
for i in xrange(100):
a = var('a')
eqn = (a - 1)/(a)
eqn.numerator()
I've gone ahead and filed this in Trac as
On a similar note cvxopt can make use of glpk as well.
Yes, it can --- I was just using this yesterday.
The trick is that you have to tell cvxopt that glpk is available when
it is compiled/installed. Now that glpk is standard, the install
script for cvxopt should be told to make use of it.
so I guess foolscap (http://foolscap.lothar.com/) wasn't included. Was
this - after all optional but still - dependency omitted on purpose,
i.e. it does not work like it should, or just none tried it yet? If
the second, I might give it a shot - it would be nice to build sage
cluster using
On Jul 14, 5:30 pm, Nathann Cohen nathann.co...@gmail.com wrote:
Has this
already been done, or should I file a patch for this?
If you would be so kind... I saw no mention of it until I read your
message :-)
Done, including patch, at
http://trac.sagemath.org/sage_trac/ticket/9598
Also,
William, David, and Jack,
Many thanks for all the excellent suggestions. Initially, I'll use
Jack's local variable trick, though as David says a more complete
implementation would probably want to keep track of the parent free
group. There's also a clean multistep way that doesn't introduce
On May 31, 11:38 pm, William Stein [EMAIL PROTECTED] wrote:
Now there is a GAP package that allows use of ACE within GAP, and
perhaps that offers better performance. I'll give it a try tomorrow
and report back.
I've made it an optional SAGE package and posted it to the repository.
The very first thing I tried was show(2/3* x^(3/2 + pi)). On sagenb.org
with jsmath it
looks amazing -- just like pdflatex output. On test.sagenb.org it
looks horrible to my eye -- definitely nowhere close to tex or even
jsmath.
I don't know if this helps, but the visual horribleness is
On Dec 29 2010, 11:50 pm, Rob Beezer goo...@beezer.cotse.net wrote:
I'd like to improve the current state of the linear algebra code over
CDF (and by extension, over RDF).
[...] I'm trolling for anything else folks can send me that might
help: advice, informative Trac tickets, potential
Through version 5.12, Sage could exponentiate vanilla Python integers by
PARI gen objects. However, in 5.13 and 6.1 the follow code throws an
error:
sage: int(1)**pari(1)
---
TypeError
On Saturday, February 22, 2014 2:33:19 AM UTC+11, vdelecroix wrote:
* the matplotlib widgets: Sage right now uses matplotlib for main
graphics capabilities. matplpotlib comes with a very complete and
useful library for making interactive graphics in native windows (with
cursors and all
[ ] Yes, make pip a standard part of Sage.
[ ] No, pip does not belong in Sage.
Yes, pip should definitely be part of Sage. Independent of its potential
use dealing with spkgs, as the now standard Python package manager it's
something end users need. The very first thing I do when
Hoping to hear from the community.Thanks.
Personally, I would start by stress-testing the code on a variety of inputs
to determine it's robustness. If it crashes a lot, there's not much point
wrapping it. On the other hand, if it turns out to be bullet-proof, I
would recommend against
On Sunday, March 10, 2013 1:35:28 PM UTC-5, mmarco wrote:
I am not sure pyGTK (or pyQT, or any other python bindings) is the way
to go. As you said, it would require to install pyGTK, but also GTK
itself and python. I think that is overkill.
I haven't used PyGTK, but I do have experience
The optional package ChomP installs cleanly but then does not actually work
on Sage 6.1.1 on OS X Mavericks. The specific error I get on both
platforms is below.
Best,
Nathan
sage: from sage.interfaces.chomp import CHomP
sage: T = cubical_complexes.Torus()
sage:
Sorry, my original message had a typo. I have observed this only with Sage
6.1.1 on OS X Mavericks not both platforms.
The optional package ChomP installs cleanly but then does not actually
work on Sage 6.1.1 on OS X Mavericks. The specific error I get on both
platforms is below.
The optional package ChomP installs cleanly but then does not actually
work on Sage 6.1.1 on OS X Mavericks.
Seems this is fixed in Sage 6.2.
You're completely right, sorry about that. For some reason, I thought Sage
6.2 was still in beta and so didn't test it there. I tried it now
If someone is interested in getting numpy-1.8.1/scipy-0.14.0 in sage,
they can review http://trac.sagemath.org/ticket/16299
I just reviewed it. Thanks for doing this, I recently ran into an annoying
memory leak in numpy 1.7.0, which was fixed in 1.7.1 (and 1.8.1).
Nathan
--
You
It would greatly simplify the life of package maintainer!
Just a +1 from me to this project. When I started the whole spkg
business, the state of Python package management was a total
mess/disaster. Today with pip things are much, much better.
Total +1 based on my experience with
There's something wrong with comparison operators for elements of
QuaternionAlgebras defined over a number field. Here's a simple example,
where first it gives the wrong answer and then, after doing some arithmetic
with the elements, a mix of right and wrong answers:
sage: K =
I looked at Vincent's patch and tested it on my own machine. It definitely
fixes the issue and the new doctest passes. However, buildbot reports
doctest failures in other modules (including ones almost certainly
unconnected with the quaternion algebra code, like
How hard would it be to switch from the singular interface to the
MAcualay2 one for the polynomial stuff?
I believe Macaulay 2 also uses Singular for its basic polynomial stuff:
See http://trac.sagemath.org/ticket/4970 - I have a feeling this is long
since superseded
I agree: Tkinter works out-of-the box on OS X with any recent source or
binary release of Sage.
Nathan
--
You received this message because you are subscribed to the Google Groups
sage-devel
I agree: Tkinter works out-of-the box on OS X with any recent source or
binary release of Sage.
Can you review that ticket, then? I have no experience with Tkinter
myself.
Sure, but what does that mean given that nothing needs to be done? More
specifically, what trac status should
Sure, but what does that mean given that nothing needs to be done? More
specifically, what trac status should I assign? Positive review doesn't
sound right since there's an attached patch that should *not* be applied...
Put it to positive review and set the status to invalid/won't fix.
I think it's http://trac.sagemath.org/ticket/18249
http://www.google.com/url?q=http%3A%2F%2Ftrac.sagemath.org%2Fticket%2F18249sa=Dsntz=1usg=AFQjCNEl-q0wWr7NJk8fwcQOBqduw0uY2g
.
I think you're right, thanks.
Nathan
--
You received this message because you are subscribed to the
Dear all,
In four different copies of Sage 6.6 on three different computers, I get
the below traceback whenever I try to do introspection. I tried deleting
.sage and .ipython but to no avail. I poked at it in pdb, and the
object argument at the last stage is, as you would expect, the
Homebrew tries to avoid exposing headers and libraries for packages that
are already bundled with OS X or have alternatives on OS X (e.g. readline
vs libedit) by installing such packages into what they call Cellars. At
least in my personal experience, this has been successful, however
And for what it is worth, I very strongly believe we should do
everything we can to transition Sage itself over to using current
standard current approaches to development and distribution. That
means fully supporting pip, using github (instead of a custom trac and
wiki install), and
>
> can someone summarize the status on making SageMath Python3 compatible?
> (...or more provocatively: When will SageMath start using Python3?)
See
http://trac.sagemath.org/ticket/15530
and tickets 15980 and 16052 referenced therein.
Best,
Nathan
--
You received this message because
>
> (2) The current version on the pyx website is 0.14 (and they had
> releases this year), but we're distributing version 0.10 from *2007*!
Not that it matters, but for Python 2.7 the current version of pyx is
0.12.1 (circa 2012); subsequent versions only work with Python 3.
Nathan
--
>
> The binary I posted should work on any OSX 10.11 machine. Possibly even on
> older OSX versions, though I don't have any way to test.
>
I tested this binary on 10.8 (Mavicks) and 10.9 (Yosemite) and it worked
fine on both!
Nathan
--
You received this message because you are subscribed
On Sunday, June 5, 2016 at 11:49:55 PM UTC-5, leif wrote:
>
> Well, GCC accepting '-march=native' doesn't imply the dumb Apple
> assembler accepts all the instructions (here AVX) GCC then emits...
>
If you pass gcc the flag "-Wa,-q", then it will use clang's assembler
rather than the ancient
>
> I'm wondering, if we should delete the beta3 and beta0 variants to avoid
> confusion?
>
That definitely seems like the right move to me.
Nathan
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
>
> I used the instructions on https://github.com/sagemath/binary-pkg to
> build sage .app.dmg packages for Mac OS 10.9.
> It works for 7.1 and 7.2*, but I compiling ECL failed with the attached
> log for 7.3.beta3 - this seems to be a regression.
>
Weird, I was able to build the ECL in
Also works in Sage 7.2 for me on OS X version 10.9 and a hoary RHEL 6
derivative. In both cases, Sage was compiled straight from the source
tarball.
Nathan
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and
>
> Did you compile sage yourself on the same machine on which you are trying
> to update the NTL package or are using a binary distribution built on >10.9
> ?
>
I was doing a clean Sage build from scratch against the git commit
(715566f4bf9) corresponding to 7.3.beta3. I have successfully
>
> I have successfully compiled Sage 7.2, which has an earlier version of
> NTL, from source on both 10.8 and 10.9.
>
Checking the logs for my Sage 7.2 builds, the old NTL version 9.6.2 spkg
did *not* specify the "-march=native" flag on 10.8 and 10.9, unlike the
current spkg for 9.8.1.
>
> > Agreed, it's certainly what the Cython docs recommend:
> >
> >
> http://docs.cython.org/src/reference/compilation.html#distributing-cython-modules
>
>
> Ah, okay. I didn't see that before. At least it's the recommended
> best practice. It should be easier to do automatically though
Erik,
Interesting, I didn't realize that build-time (as opposed to run-time)
dependencies were even *possible* with setuptools, even if it does require
a hack. With SnapPy, we just ship the Cython-generated C/C++-files in the
tarball that we post on PyPI. It adds a bit to the tarball's size,
>
> > Interesting, I didn't realize that build-time (as opposed to run-time)
> > dependencies were even *possible* with setuptools, even if it does
> require a
> > hack. With SnapPy, we just ship the Cython-generated C/C++-files in the
> > tarball that we post on PyPI.
>
> I was going to
>
> While this might work for simple projects, this won't work when you need
> the metadata that cythonize() adds. For example, anything using
> cysignals really must use cythonize(), it won't work otherwise.
>
Jeroen,
As of Cython 0.22, it looks like the metadata you refer to is cached in
>
> That made me think that sage fails to set everything required to let
> "--user" work properly (I noticed installation path names containing
> ".../.sage/..." so at least it was trying something distinct from what
> python would do in a standard config.)
>
Hmmm, I install Python packages
>
> Is there a ticket for this?
>
I just created one --- trac was down when I posted originally:
http://trac.sagemath.org/ticket/20779#ticket
Nathan
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
>
> Which operating systems / distros would be affected by this (i.e., only
> ship with 2.6.x [and probably some older 3.x])?
>
What I'd seriously worry about here is RHEL 6 and derivatives (CentOS,
SciLinux). It only comes with Python 2.6 by default, and while old (came
out in 2010), it is
On OS X versions 10.8 (Mountain Lion) and 10.9 (Mavricks), the recently
updated NTL package fails to build with the following error (complete log
also attached).
g++ -I../include -I. -march=native -O2 -g -fno-common -c MakeDescAux.c
>
> Is this a parallel make?
>
No, it was single-threaded. (Unless parallel make is the default, to be
precise I just typed "make".)
Nathan
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving
When trying to build Sage 7.2 from source on OS X (10.8 and 10.9), I get
the following error (complete logs also attached):
Installed
/pkgs/sage-7.2/local/lib/python2.7/site-packages/jupyter_core-4.1.0-py2.7.egg
Processing dependencies for jupyter-core==4.1.0
Searching for traitlets
Reading
>
> It's like if setuptools is loaded for whatever reason, then setuptools
> will be used to install jupyter_core. The question is: why was
> setuptools loaded in the first place? Do you have any custom Python
> packages installed which could do this?
>
Yes, that is indeed this issue! I
>
> We don't have a buildbot on old OSX machines.
>
One possible idea: VirtualBox supports running OS X clients on OS X hosts,
and the OS X versions don't have to match. I know someone who has VB VM's
of every release from 10.6 to 10.11 running on a 10.11 host.
Nathan
--
You received
Currently, the only OS X binaries available on the official SageMath site
are labeled as being for OS X 10.11 (El Capitan) only, with names like
"sage-7.1-OSX_10.11.3-x86_64*". My question is: shouldn't there versions
for older versions of OS X? El Capitan is less than 7 months old, and Sage
On Friday, May 13, 2016 at 7:54:30 AM UTC-5, kcrisman wrote:
>
> I was planning on building the next Sage release on 10.7, before my
> computer is upgraded. But I'm confused as to why the older versions for
> older systems were deleted from the downloads page?
>
There are a of couple 10.7
FYI, I found a very similar issue with "exp" and "log" for purely imaginary
numbers:
http://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=1896
Nathan
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
>
> It's ridiculous that we spend no effort on pandas/statsmodels, and all
> this
> effort on R.
+1
> For example, I recall that there are some issues involving pandas +
> statsmodels + the sage preparser.
>
I use Pandas in the default Sage Interpreter on a daily basis and have only
>
> How do people get VMs for testing different OSX / XCode versions?
>
Both VirtualBox and VMWare (Fusion) fully support OS X VMs with the
important caveat you have to use actual Apple hardware for the host.
I've used both without major problems on a Mac Pro. Currently I mostly use
VMWare
>
> Plus licenses for a range of OSX versions (at least those that are
>> still supported by Apple...)
>>
>
> these are peanuts, e.g. £20 for 10.7
>
I don't know if this is still the case, but as of a year ago if you become
a registered Apple Developer then you got access to all the old
On Thursday, June 15, 2017 at 12:38:40 PM UTC-5, Volker Braun wrote:
>
> On Thursday, June 15, 2017 at 3:10:22 PM UTC+2, Nathan Dunfield wrote:
>>
>> but of course the Mac Mini has only 2 cores.
>>
>
> For the record, our OSX buildbot is a quad-core mac mi
On a good day, assuming the user has the Xcode command-line tools
installed, the following suffices to get pip working with the current
binary version of SageMath on macOS 10.12:
sage -i openssl
sage -f python2
It would be great if the next release of SageMath had a working version of
pip on
|X| Yes, we should fully support OpenSSL now, and clarify the licensing
issue.
--
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
I would suggest adding a link or instructions for how to download your new
SageMath installer for Windows.
Nathan
--
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
>
> In the interim, could you try to install OpenSSL and its development files
> a,d reinstall Sage's pip ?
>
Actually, I fixed the problem simply by installing the (non-development)
Ubuntu package "openssl". In particular, I did not need to reinstall or
rebuild any part of Sage itself.
Just tried out the latest Sage Docker image and, unlike all previous
versions, I can no longer use pip to fetch packages off PyPI:
docker run -it sagemath/sagemath:8.2 /bin/bash
sage@6bf664a266cd:~/sage$ sage -pip install FXrays
pip is configured with locations that require TLS/SSL, however the
On Saturday, May 26, 2018 at 7:43:14 PM UTC-4, Julian Rüth wrote:
>
> Thanks for reporting this and even providing a workaround :)
>
> You are right, Sage was built with libssl-dev but the final container had
> been missing openssl. I fixed it for the 8.2 build and pushed a new image
> to the
I tried building Sage from source on the new Ubuntu 18.04 in a clean Docker
container with just a handful of basic packages installed, principally gcc
7. It was unable to build ecm-7.0.4.p1 which is included in 8.2rc1. Here
is what seems to be the core of the error message:
mv -f
On Sunday, April 29, 2018 at 4:55:35 AM UTC-5, Erik Bray wrote:
>
> Yep, SAGE_FAT_BINARY=yes is what did it. I'll look into it further.
>
Erik,
Thanks! I just confirmed that setting SAGE_FAT_BINARY to "no" fixes the
problem on my machine as well.
Nathan
--
You received this message
On Saturday, April 28, 2018 at 7:41:49 PM UTC-5, Erik Bray wrote:
>
> I just finished a full build from scratch on Ubuntu 18.04 and it went
> fine. This was of 8.2.rc4.
>
> I don't recall off the top of my head whether anything changed between
> rc1 and rc4 that might have effected this, but
On Monday, October 23, 2017 at 7:32:03 AM UTC-5, Erik Bray wrote:
>
> > I also balk at the idea of shipping a crippled pip.
>
> It's not crippled if you don't need it to install from HTTPS which not
> everyone does.
>
I agree with Emmanuel that providing "pip" without HTTPS is shipping a
On Tuesday, July 24, 2018 at 4:49:45 PM UTC-5, Timo Kaufmann wrote:
>
> I really like your wishlist! The all-or-nothing nature of sage and the
> slow startup time (although it's actually more like 1.3 seconds with a warm
> cache on my machine) are my biggest pain points.
>
I've encountered
On Tuesday, October 2, 2018 at 10:40:28 AM UTC-5, Nathan Dunfield wrote:
>
> This is a known bug and we are working on it (there's even a ticket). It
> should be fixed soon. It's some issue with our configuration script.
>
FYI, this issue has now been fixed and the corre
This is a known bug and we are working on it (there's even a ticket). It
should be fixed soon. It's some issue with our configuration script.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving
>
> It's bad packaging by upstream: it's running Cython but the Cython
> source files are not in the snappy source tarball.
>
Yes, we ship the Cython generated C/C++ files rather than Cython code
itself. My understanding from the Cython docs is that this is the
recommended approach for
>
> Thanks, Thierry. Sounds like we need a ticket for this. In particular, I
> wasn't even able to get sage -pip install mercurial to work on OS X.
>
I was just helping a colleague install SnapPy into SageMath on OS X and hit
the above issue. I just downloaded the source tarball from
>
> > The idea is that cython produces fully compliant C code, so that no
> tuning
> > of the generated C code is required. Distributing the cythonized c-files
> > has the advantage that the installing user does not need cython
> installed.
> > In sage we have run into trouble with that due
I am a developer of the Python package "snappy" which acquires extra
features when imported inside of Sage. Some of our Linux users have
recently reported difficulties with SnapPy on machines where Sage was
installed by the standard package manger making use of the system libraries
and in
On Thursday, January 10, 2019 at 6:47:33 AM UTC-6, vdelecroix wrote:
>
> Le 10/01/2019 à 04:47, Nathan Dunfield a écrit :
> >
> > P.S. In the Debian package "sage" does not accept the "-pip" flag, even
> > though installing the "sagemath&qu
On Thursday, January 10, 2019 at 9:38:15 AM UTC-6, vdelecroix wrote:
>
> Could you repeat the order in which things are broken.
>
Any of the following sequences of commands will install both the SnapPy
Python package and SageMath without producing any errors:
0) install python2 and python-pip
1 - 100 of 171 matches
Mail list logo
