Indeed! I am part of HPCCF (HPC certification forum) and at the beginning of
the week
we had some kind of assembly. In two parts.
UK->Americas on Monday [would have turned out as 2am Tuesday for me]
UK->NZ on Wednesday [it was still 8pm to 10pm for NZ-ers like me]
> On 22/05/2020, at 8:13 AM, Dim
Hum. May 21, 19:30GMT = May 22 7:30 NZ time I was in the middle of preparing
breakfast
for the kids and we should go to school shortly.
Needless to say I won’t participate at 7:30am on a Saturday morning.
François
> On 22/05/2020, at 7:57 AM, Matthias Koeppe wrote:
>
> On Thursday, May 21, 202
In sage-on-gentoo and some other distros (I think arch) I completely ignore
the meta packaging of sage. Every single packages is a system package.
and sage itself is built as a normal python package.
Because of problems with maintaining python2 compatibility, and keeping
around some packages compat
The flask packages definitely should be made optional.
> On 12/03/2020, at 12:02 PM, Antonio Rojas wrote:
>
> sagenb was made optional, but its dependencies (such as flask-* packages) are
> still standard and installed by default as of 9.1.beta7. Shouldn't they be
> made optional too?
>
> --
Timo Kaufmann (eisfre...@gmail.com) is packaging for nix. You should ask him
for tips.
François
> On 18/02/2020, at 9:17 AM, Maxime Boissonneault
> wrote:
>
> Hi Vincent,
>
> It is a rather complex setup, as this is for a national network of HPC
> clusters. We have thousands of software pac
> On 8/02/2020, at 1:20 AM, Simon King wrote:
>
> On 2020-02-07, Han Frederic wrote:
>> It is indeed rare for an spkg to be linked to the sage library...
>
> ... but it is not the only one. p_group_cohomology is similar in that
> regard.
Being a downstream package that way is absolutely fin
I’ll claim responsibility for the name change request!
More seriously, after reading this and thinking a little bit I would
really prefer if it was merged in sage/libs. The alternative means that
we have a true circular dependency sage <-> giacpy_sage and things
will start to get wild as soon as
It looks to me like there could be a bad interaction between compiler headers
(probably installed by brew)
in /usr/local and system headers.
If it is not then I would think there could be a bug for upstream givaro.
François
> On 26/01/2020, at 12:21 PM, Andrew wrote:
>
> On sage-release Justin
> On 10/01/2020, at 11:23 PM, E. Madison Bray wrote:
>
> On Fri, Jan 10, 2020 at 10:41 AM Timo Kaufmann wrote:
>>
>> I have said this before, but I feel like the point was dropped out of the
>> discussion so I'll stress it again. The major issue here is *not* the
>> compatibility of sage's
> On 6/01/2020, at 8:44 AM, Frédéric Chapoton wrote:
>
> Hello,
>
> I would like to suggest that the sooner we drop Python 2 support the better.
> We still need to handle the upgrade to ipython7 and the compatibility with
> python 3.8. All this will be made very difficult if we insist on ma
To be honest, I thought turning on using the GPU required manual
intervention. Obviously it was turned on automatically for you.
I'll get a ticket to fix this.
In the meantime do
CUDA=no make suitesparse
and it should build
François
On Fri, Dec 20, 2019 at 9:59 AM Olivier Guillon
wrote:
> Hel
I suspect gcc/gfortran shipped with sage is too old to build on 10.15.
Upgrading to 9.x may help.
> On 31/10/2019, at 11:04 AM, Dima Pasechnik wrote:
>
> I think at the moment most people who tried cannot build Sage on MacOS
> 10.15 with Xcode 11.1 (the latest one).
> Regarding gfortran, perhaps
+1
> On 27/10/2019, at 12:58 PM, Vincent Delecroix <20100.delecr...@gmail.com>
> wrote:
>
> +1
>
> Le 26/10/2019 à 16:58, Volker Braun a écrit :
>> Maybe I missed it, but I didn't find a ticket for that. I think now would
>> be a good time to flip the switch, though. Any thoughts?
>
> --
> Yo
> On 11/10/2019, at 4:53 AM, Dima Pasechnik wrote:
>
> (IIRC there are few places that need static libs)
There are a few places where people claim they want the static libraries
for performance reasons. I live perfectly well without static libraries
in sage-on-gentoo and I would think most ot
Have you used “SAGE_FAT_BINARY=yes”? it is the only way to make a somewhat
portable
binary that doesn’t have the problem you describe.
> On 1/10/2019, at 10:47 PM, Dima Pasechnik wrote:
>
> looks like you need to pass some flags to NTL,
> apparently it doesn't know what Core 2 CPUs are any more
Is this what you expect to happen but doesn’t?
fbissey@moonloop ~ $ sage
┌┐
│ SageMath version 8.9.rc0, Release Date: 2019-09-11 │
│ Using Python 2.7.15. Type "help()" for help. │
└
I’d say it is missing libstdc++ because it is linked with clang. But this is
strange
CXX should be used according to the Makefile of flint. Do you do accidental
patching
to CC or do you somehow pass CXX=clang to flint?
> On 20/09/2019, at 8:18 PM, Dima Pasechnik wrote:
>
> at the moment its NT
Taking into account the fact that there is some kind of processing and
communication
time to the node when you issue such a command some drift by a second is not
unexpected.
And the output of pdsh has been sorted so you cannot see the order the time was
returned.
> On 19/09/2019, at 1:17 AM, Di
???).
That would be a problem for an administrator to look at.
François
> On 18/09/2019, at 12:07 PM, Marco Castronovo
> wrote:
>
> I'm on gpfs.
>
> Marco
>
> On Tuesday, September 17, 2019 at 4:49:10 PM UTC-4, François Bissey wrote:
> Quick question Marco. What fi
> On 18/09/2019, at 8:51 AM, Dima Pasechnik wrote:
>
> On Tue, Sep 17, 2019 at 9:49 PM François Bissey wrote:
>>
>> Quick question Marco. What file system are you running on? It seems to me
>> you have all
>> these build issues that could be related
Quick question Marco. What file system are you running on? It seems to me you
have all
these build issues that could be related to timestamps being messed up on your
file system.
François
> On 18/09/2019, at 8:34 AM, Marco Castronovo
> wrote:
>
> The problem still persists with the file buil
/lib is dropped there then it should work IMHO.
>
> I don't quite see why -L/lib gets there at all, though...
>
>
> On Sun, Aug 25, 2019 at 11:34 PM François Bissey wrote:
>>
>> What would be interesting is the config.log for the eclib compile that goes
>&g
gt;>
> >>> On Sun, 25 Aug 2019 15:01 Vincent Delecroix, <20100.delecr...@gmail.com>
> >>> wrote:
> >>>
> >>>> The install log says
> >>>>
> >>>> Successfully installed pari-2.11.1.p2
> >&g
First question. Is sage’s pari installed?
François
> On 25/08/2019, at 11:30 PM, Vincent Delecroix <20100.delecr...@gmail.com>
> wrote:
>
> Dear all,
>
> I obtain an error while building eclib. The end of the log
> says
>
> /usr/bin/ld: avma: TLS definition in /lib/libpari.so section .tbss mi
This is https://trac.sagemath.org/ticket/28082
> On 2/08/2019, at 8:41 PM, 'PJ' via sage-devel
> wrote:
>
> When trying to install giacpy_sage via
>
> sage -i giacpy_sage
>
> I'm encountering errors that seem to indicate that C++11 should be used but
> isn't. I haven't managed to fix the ins
Hi all,
I am giving a shot at getting maxima-5.43.0 working for sage-on-gentoo
and it looks good overall but there are couple of things that needs
attention.
I believe that is the first time in a long while we had maxima tests
running in Gentoo.
Two of the patches that sage uses are breaking ma
you have to make a note in the doc that ARB_LIBRARY needs to be set during
build
one way or another or something of that effect.
I don’t know what other people think of it.
François
> On 16/07/2019, at 9:44 PM, Dima Pasechnik wrote:
>
> On Tue, Jul 16, 2019 at 1:13 AM François Biss
My contingency plan for sage-on-gentoo is
sed “s:@ARB_LIBRARY@:arb:” src/sage/env.py.in > src/sage/env.py
Replace “arb” and the paths with what is appropriate for your distribution.
> On 16/07/2019, at 12:04 PM, François Bissey wrote:
>
> I will not give it a positive review. I w
u have a better solution than there, implement it, if not,
> accept what it already provided.
>
> On Mon, Jul 15, 2019 at 11:31 PM François Bissey wrote:
>>
>> For those not reading the ticket.
>> Dima:
>> well, I don't see a point of not running ./configure.
sagelib" being treated special instead of as
a normal package.
So many things would have to click in place once you do that. Other superbuild
systems like the one
for paraview don't treat the main target in a special way like sage's does.
—
François
> On 16/07/2019, at 10:15 AM, F
> On 16/07/2019, at 10:11 AM, arojas wrote:
>
>
>
> El martes, 16 de julio de 2019, 0:07:19 (UTC+2), François Bissey escribió:
>
> And here I don’t run configure at all in sage-on-gentoo. I only use python
> standard
> tools to build the sage library itself. I
> On 16/07/2019, at 9:58 AM, Antonio Rojas wrote:
>
>
>
> El lunes, 15 de julio de 2019, 14:49:54 (UTC+2), Dima Pasechnik escribió:
>
>
> A quick way would be to create src/sage/env.py.in, with a template for, say,
> `aliases["ARB_LIBRARIES"]` in `cython_aliases`
> filled in by a call t
Fill a bug on the tracker. giacpy_sage is using CC when it should use CXX with
c++11
standard options. This is why it is failing
1) compile with gcc instead g++
2) complaints about the use c++11 “extensions” which of course shouldn’t be
available
from plain “gcc”.
> On 29/06/2019, at 4:27 AM, Ma
gt;> On Tuesday, June 25, 2019 at 12:26:57 PM UTC+12, François Bissey wrote:
>>>
>>> Hi,
>>>
>>> in the latest rc (8.8.rc3) and using texlive-2017 we have some missing
>>> references in
>>> the pdf doc but not the html.
>>> See htt
PM UTC+12, François Bissey wrote:
>
> Hi,
>
> in the latest rc (8.8.rc3) and using texlive-2017 we have some missing
> references in
> the pdf doc but not the html.
> See https://github.com/cschwan/sage-on-gentoo/issues/543
> and note we have reproduced the issue in van
Hi,
in the latest rc (8.8.rc3) and using texlive-2017 we have some missing
references in
the pdf doc but not the html.
See https://github.com/cschwan/sage-on-gentoo/issues/543
and note we have reproduced the issue in vanilla (not sage-on-gentoo) builds.
Because we don’t look at the pdf that ofte
> On 19/06/2019, at 10:17 PM, Julian Rüth wrote:
>
> Not sure why nm does not see any symbols here.
>
nm -D doesn’t show anything?
--
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
I totally split it in sage-on-gentoo and keep 3 separate tarballs on
a mirror.
François
> On 19/06/2019, at 11:15 AM, Isuru Fernando wrote:
>
> Hi,
>
> Rubiks package is a combination of 3 packages with lots of patches to the
> build system
>
> Keeping it standard requires package managers t
https://trac.sagemath.org/ticket/27676
> On 16/05/2019, at 8:44 PM, Dima Pasechnik wrote:
>
> I accidentally installed gcc 9.1, so I decided to give the latest Sage
> beta a spin with it, and the result wasn't very impressive --- a lot
> of tests ended with "Bad exit", due to memory overflows.
>
It looks like you are using tachyon instead of jmol for rendering some
3D plots. I think that's what is causing the issues. Your jmol install
may be broken and tachyon is used as the fallback.
Francois
On 14/05/19 4:22 am, David Coudert wrote:
I already had issues building the doc with 8.8.bet
Hi,
configure:13910: gcc -o conftest -m64 -O2 -march=corei7-avx -mtune=corei7-avx
-g -I/home/pwissing/sage-8.7/local/include
-I/home/pwissing/sage-8.7/local/include -L/home/pwissing/sage-8.7/local/lib
-L/home/pwissing/sage-8.7/local/lib -L/home/pwissing/sage-8.7/local/lib
-Wl,-rpath,/home/pw
And it has to be 8.8.beta2 or lower not beta3 which is the latest.
elliptic_curves has been
bumped to 0.8.1 in beta3.
> On 19/04/2019, at 17:07, Dima Pasechnik wrote:
>
> How about posting logs of packages that failed to build?
>
> It would also be great to know whether it was a build from scr
I used to build on GPFS some time ago. I still have an old GPFS system on which
I could trial
things again but I’d like to know a little bit more about the failure you are
experiencing.
I don’t remember having that kind of issues.
François
> On 13/04/2019, at 02:41, 'Juri' via sage-devel
> w
Hi all,
I am currently working with ticket merging sphinx 1.8.5.
I also have been looking a lot at testing the available
optional packages I can in sage-on-gentoo.
Which is how I ended up having topcom installed.
With topcom installed the documentation fails to build
in python3:
Error building t
not ATLAS? Should I look at the numpy makefile?
>
> On Sun, Mar 3, 2019, 15:37 François Bissey wrote:
> Ok. Well it is finding openblas
>
> customize UnixCCompiler
> FOUND:
> libraries = ['openblas', 'blas']
> library_dirs = ['/usr/local/
e']
/usr/local/src/Misc/sage-8.6/local/lib/python2.7/distutils/dist.py:267:
UserWarning: Unknown distribution option: 'define_macros'
warnings.warn(msg)
Is it supposed to find something else?
> On 4/03/2019, at 10:33, Ike Stoddard wrote:
>
> Numpy log and sagelib lo
LAS_LIB at some
> point?
>
>
> On Sunday, March 3, 2019 at 2:17:24 AM UTC-6, François Bissey wrote:
> You suffer from a classic case of gcc/gfortran upgrade. I have been fielding
> bugs
> for the same kind of errors in Gentoo for a number of months now.
> up to gc
You suffer from a classic case of gcc/gfortran upgrade. I have been fielding
bugs
for the same kind of errors in Gentoo for a number of months now.
up to gcc-6, gfortran provided its runtime with libgfortran.so.3.
But gcc-7 broke the compatibility and provided libgfortran.so.4.
And gcc-8 broke the
> On 1/03/2019, at 08:40, Timo Kaufmann wrote:
>
> I suggest a middle ground: I don't believe this behavior should be
> tested in Sage's test suite, because this is a question about the
> Python interpreter's behavior, not Sage.
> [...]
> Otherwise, I don't think the Sage test suite has any
> On 22/02/2019, at 08:27, Dima Pasechnik wrote:
>
> The primary author of PALP died in 2010:
> http://hep.itp.tuwien.ac.at/~kreuzer/CY/
So it is abandon-ware? If it is, then it is clearly in need of adoption :)
François
--
You received this message because you are subscribed to the Google
Your answer is not appropriate Dima.
You have switched to a distro supported package from arch Ike.
The appropriate people to ask are the arch maintainers for the package
not this mailing list.
Sorry.
> On 21/02/2019, at 20:29, Dima Pasechnik wrote:
>
> On Thu, Feb 21, 2019 at 6:25 AM Ike Stod
Yes and that does work.
> On 21/02/2019, at 17:19, Ike Stoddard wrote:
>
> But without sage installed, it just uses the “local” script ./sage to do the
> 1-shot?
>
> On Wed, Feb 20, 2019 at 22:16 François Bissey wrote:
> TO some extent, configure would have to be run
:13, Ike Stoddard wrote:
>
> But will this work without a prior installation?
>
> On Wed, Feb 20, 2019 at 19:00 François Bissey wrote:
> ./sage -i linbox
>
> > On 21/02/2019, at 13:51, Ike Stoddard wrote:
> >
> > Unfortunately, I cannot see how to do that. H
./sage -i linbox
> On 21/02/2019, at 13:51, Ike Stoddard wrote:
>
> Unfortunately, I cannot see how to do that. How do I install a one-shot?
> In the unpacked linbox subtree: spkg-install? src/linbox-auto-install?
>
> On Wednesday, February 20, 2019 at 1:51:33 PM UTC-6, Fra
Yes from the log it seems like there is an issue between openCL and C++11.
linbox uses an older macro for c++11 detection so the standard flag is not
added. I honestly think it may be an upstream bug in the testing code.
> On 21/02/2019, at 08:45, Ike Stoddard wrote:
>
> Yep. Wanted to check sub
sage is not yet able to use a system installed linbox.
You could install linbox as a one shot without testing with
sage and resume make.
> On 21/02/2019, at 08:49, Ike Stoddard wrote:
>
> There is a native linbox I can install. Will do so and reconfigure. Is there
> a way to use the stuff compi
> On 16/02/2019, at 22:40, Emmanuel Charpentier
> wrote:
>
> I see (modulo the legendary readability of m4, which has been compared to
> line noise or a cat's nap on the keyboard...).
>
Any language is a bit like that when you don’t know it to be fair.
And you can produce line noise in mos
> On 16/02/2019, at 22:25, Emmanuel Charpentier
> wrote:
>
> Pushing to use system sqlite
>
> What do you mean ? Do you mean removing "our" sqlite and dependig on system's
> sqlite ? Nice idea... except for Cygwin,and/or WSL...
>
Erik has been pushing that for a number of package. In a c
>
> This is more explainable: "our" sqlite3 is at 3.22, whereas system's sqlite3
> is at 3.26+fossilbc891ac6b (whatever that means...).
>
> I might try to update "our" sqlite3 *if* I can figure what is the "right"
> source Debian unst
Can you send us the error message you get when installing sp/spdep?
What version of openblas do you have on your system? The latest beta
of sage uses openblas 0.3.5 which is latest available release.
François
> On 16/02/2019, at 21:46, Emmanuel Charpentier
> wrote:
>
> Dear list,
>
> I start
Can you send `config.log` please?
François
> On 13/02/2019, at 21:36, Andreas Hermann wrote:
>
> The output of ./configure FC=gfortran-8 says among other things
>
> checking SPKGs to install...
>
> gcc-7.2.0 not installed (configure check)
>
> gfortran-7.2.0
>
> I have attached the
What is really happening is that compilers have become increasingly chatty about
bad coding practices especially in the last couple of years.
> On 12/02/2019, at 14:10, Randall wrote:
>
> Is the amount of warnings for the palp build normal? This might be used as a
> great exercise in a software
I will formally vote for “True”.
However I think the default should be "use online if available" and fall back
if not.
But that implies writing new code to check online availability.
François
> On 12/02/2019, at 06:31, Eric Gourgoulhon wrote:
>
> Hi,
>
> As pointed out in the Free Computatio
> On 11/01/2019, at 09:48, Jeroen Demeyer wrote:
>
> On 2019-01-10 20:46, 'Julien Puydt' via sage-devel wrote:
>>
>>
>> Le 10/01/2019 à 20:07, François Bissey a écrit :
>>> I have recently made the following change in sage-on-gentoo’s en
> On 11/01/2019, at 05:04, E. Madison Bray wrote:
>
> If you want to look-before-you-leap you could also check if
> `SAGE_ROOT` and `SAGE_LOCAL` are set to something reasonable in
> `os.environ`.
Just SAGE_LOCAL. SAGE_ROOT should only be needed for the packaging system
and possibly the docte
labels was the
> order on vertices that minimize the adjacency matrix in
> lexicographic order...
>
> Vincent
>
> Le 02/01/2019 à 08:32, Vincent Delecroix a écrit :
>> I opened #26994
>> https://trac.sagemath.org/ticket/26994
>> Le 02/01/2019 à 07:25, François B
5
C~ 46
“C]” for “Cr”. There are other.
François
> On 2/01/2019, at 19:35, Dima Pasechnik wrote:
>
> Is this purely whitespace difference?
>
> On Wed, 2 Jan 2019 14:25 François Bissey We already have seen it in 8.5.beta but no
We already have seen it in 8.5.beta but no one has opened a ticket yet for it
I think. Nor does anyone knows the real trigger for it.
Because I first spotted it in sage-on-gentoo I thought that it was a sqlite
version mismatch, but pure sage people started to report it…
François
> On 2/01/2019, a
Good timing https://trac.sagemath.org/ticket/26782 needs reviewing.
> On 7/12/2018, at 19:59, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
>
> Dear all,
>
> Here is the report. There is apparently a problem with our
> install script.
>
> Vincent
>
>
>
> boost-1_66_0
> ===
I filled this little interesting configuration bug with pari
yesterday:
https://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=2097
In short if the deadline on your system doesn’t match the readline
shipped by sage your pari/gp doesn’t have readline support.
Not a big deal in and of itself, bu
> On 21/11/2018, at 03:52, Jeroen Demeyer wrote:
>
> On 2018-11-06 19:07, François Bissey wrote:
>> SAGE_LOCAL is another story,
>> however we probably could figure it out from the python configuration rather
>> than a seed.
>
> Isn't SAGE_LOCAL == sys
I wonder if this is a result of some recent changes by Erik in detecting system
packages.
I certainly didn’t design things to have this behaviour when I introduced the
gfortran
package to complement clang.
François
> On 18/11/2018, at 23:30, Volker Braun wrote:
>
> I just upgraded the buildbo
On 7/11/18 4:41 AM, Daniel Ouimet wrote:
Here is the gcc --version :
# gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY o
> On 7/11/2018, at 01:12, Erik Bray wrote:
>
> I'm not necessary suggesting a full replacement: Just a dumb config in
> addition to it that can be used both from sage.env and perhaps
> sage-env as well. I tossed about some ideas for this in
> https://trac.sagemath.org/ticket/22652 and possibl
Can you provide
/usr/local/soft/sage-8.4/local/var/tmp/sage/build/mpir-3.0.0-644faf502c56f97d9accd301965fc57d6ec70868.p0/src/config.log
as well? Something looks strange in that log.
François
> On 6/11/2018, at 11:41, François Bissey wrote:
>
> Your compiler is very old and right no
Your compiler is very old and right now you are failing even bootstrapping
a better compiler.
Nevertheless trying to compile those instructions shouldn’t have happened.
Can you post the output of
as —version
please.
François
> On 6/11/2018, at 11:03, Daniel Ouimet wrote:
>
> Hi,
>
> on a Linu
I’d be curious about that, but yes that may be off-list.
François
> On 5/11/2018, at 20:42, Jori Mäntysalo wrote:
>
> Now it's time for polyamory, i.e. getting also shibboleth ready. But that
> will be off-topic for this list.
--
You received this message because you are subscribed to the Go
Didn’t we have that conversation a couple of months ago?
The message here comes from this section of code in sage-env
# New value for SAGE_ROOT: either SAGE_ROOT (if given)
# or a guessed value based on pwd.
if [ -n "$SAGE_ROOT" ]; then
NEW_SAGE_ROOT="$SAGE_ROOT"
elif [ -f sage -a -d build ];
It is the file, thank you. And the relevant bit is:
configure:41026: checking if libcurl is version 7 and >= 7.22.0
configure:41055: gcc -o conftest -g -O2 -fPIC
-I/Users/mercatp/anaconda3/include -L/Users/mercatp/sage/local/lib
-Wl,-rpath,/Users/mercatp/sage/local/lib conftest.c
-L/Users/m
> On 14/10/2018, at 21:37, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
>
> I am impressed by the number of persons
> I see still using the legacy notebook.
The whole math department of university of Canterbury (New Zealand) where
I work for starter. They have heaps of legacy notebooks
https://trac.sagemath.org/ticket/26114 should be in the next beta and fix this
issue.
François
> On 27/08/2018, at 22:18, Eric Gourgoulhon wrote:
>
> Hi,
>
> Since Sage 8.4.beta0, the default 3D viewer (Jmol) seems broken in Jupyter
> notebooks. For instance, typing
> sphere()
> results in
> On 16/08/2018, at 10:04, John H Palmieri wrote:
>
> On ticket 25382, https://trac.sagemath.org/ticket/25382, the following
> questions have been raised:
>
> - Is the old Sage notebook deprecated?
>
> - If not, should it be?
>
> - In any case, the documentation builds with Python 2. It do
That looks like a symptom of not installing (or re-installing after an upgrade)
the
xcode command line tools.
François
> On 16/08/2018, at 07:51, Jeremy Martin wrote:
>
> I am trying to install sage 8.3 from source, running MacOS 10.13.6 High
> Sierra. A snippet of the output is below. I'm
That’s fine. redhat’s naming scheme can be confusing, especially if you come
from
another distro.
François
> On 12/08/2018, at 21:34, Will Sinclair wrote:
>
> I tried the command yum install gfortran, but however it required root, so I
> tried it with root access, but ended up with "no packag
https://trac.sagemath.org/ticket/26007
It will be in the next beta.
François
> On 11/08/2018, at 16:19, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
>
> Hello,
>
> Apparently, there is some problem of dependencies between sage-lib and
> libbraiding. More precisely, braiding.h is missing
clang: error: clang frontend command failed with exit code 70 (use -v to see
invocation)
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
We support building with Xcode 7 (based on clang 3.7) but never tried to go
back further. Do you have access to a newer Xcode on that machine? Yo
There is one example in
https://trac.sagemath.org/ticket/25799
If you want a glaring example about fonts see
https://trac.sagemath.org/ticket/23696#comment:111
on the original upgrade to matplotlib 2.1.0 ticket.
François
> On 16/07/2018, at 11:11, Thierry wrote:
>
> Hi,
>
> could you please p
Generally equations look better with the font choices in the “classic” style
which was
the default before matplotlib-2.
> On 9/07/2018, at 20:34, Kwankyu Lee wrote:
>
> Yeah, I found one thing that looks ugly on my machine:
>
> In the 'classic' style:
>
>
> In the current default style:
>
I am sorry to have introduced that in the upgrade to matplotlib 2.1. Hardcoding
was easier than setting the style to classic for every calls for the
documentation.
The reports I had was that the default style from 2.1 onwards made the
documentation
plots look ugly.
François
> On 9/07/2018, at 1
Classic error you get when the first pass gcc cannot find the right
gmp/mpfr/mpc to load.
It should be visible in the file
/data/GitHub/others/sage/local/var/tmp/sage/build/gcc-7.2.0/gcc-build/x86_64-pc-linux-gnu/libgcc/config.log
François
> On 5/07/2018, at 09:07, BJH2017 wrote:
>
> Strangely
> On 23/05/2018, at 10:27, François Bissey wrote:
>
>
>
>> On 23/05/2018, at 10:02, Nils Bruin wrote:
>>
>> On Saturday, May 19, 2018 at 12:08:22 AM UTC-7, Antonio Rojas wrote:
>>
>>
>> OK, so how do we see whether the $SAGE_ROOT/sage
> On 23/05/2018, at 10:02, Nils Bruin wrote:
>
> On Saturday, May 19, 2018 at 12:08:22 AM UTC-7, Antonio Rojas wrote:
>
>
> OK, so how do we see whether the $SAGE_ROOT/sage script needs to be used?
> Can we just see if $SAGE_ROOT/sage is present and executable and if not, use
> $SAGE_LOCAL
> On 19/05/2018, at 18:30, Nils Bruin wrote:
>
> On Thursday, May 17, 2018 at 1:01:21 AM UTC-7, François Bissey wrote:
> Actually in sage-on-gentoo I reduced that quite a bit. In vanilla we have
> "argv": ["/home/fbissey/sandbox/git-fork/sage-8.3.b0/local
Actually in sage-on-gentoo I reduced that quite a bit. In vanilla we have
"argv": ["/home/fbissey/sandbox/git-fork/sage-8.3.b0/local/bin/sage",
"--python", "-m", "sage.repl.ipython_kernel", "-f", "{connection_file}”]
That is, sage-devs go to quite some lengths to launch sage’s python with the
sag
Forwarding this from on another list. I was going to only post it
to sage-packaging but I really think it belongs here.
PDF:
https://fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/attachments/slides/2297/export/events/attachments/how_to_make_package_managers_cry/slides/2297/how_to
I’d say this is the root cause of the problem but I am not sure what it all
means
gcc build/temp.linux-x86_64-2.7/scratch/check_sys_un.o
-L/opt/modules/sagemath/8.1/lib -Wl,-R/opt/modules/sagemath/8.1/lib -o
build/temp.linux-x86_64-2.7/scratch/check_sys_un
Warning: No sys/un.h, IPC_PATH_
at 5:36:41 PM UTC-5, François Bissey wrote:
> The real interesting bit is
> /bin/bash ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
> -I. -I../../.. -I../../.. -I../../../fflas-ffpack/utils/
> -I../../../fflas-ffpack/fflas/ -I../../../fflas-ffpack/ffpack
> -I../../.
The real interesting bit is
/bin/bash ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I../../.. -I../../.. -I../../../fflas-ffpack/utils/
-I../../../fflas-ffpack/fflas/ -I../../../fflas-ffpack/ffpack
-I../../../fflas-ffpack/field -fPIC -std=gnu++11 -fabi-version=6
-I/opt
You might want to look at https://trac.sagemath.org/ticket/24735
François
> On 27/04/2018, at 10:11, Brent W. Baccala wrote:
>
> Hi -
>
> Has anybody worked on porting Singular 4.1.1 to Sage? (4.1.1 was released in
> February; 4.1.1p2 was released on Monday)
>
> I'm having problems loading
> On 21/04/2018, at 02:43, Dima Pasechnik wrote:
>
> clang -pthread does not do what gcc -pthread does, see
> https://stackoverflow.com/a/19382746/557937
>
> This means that with clang you need -lpthread
> whereas with gcc you need -pthread
>
> It's probably OK to have them both, no?
>
Th
101 - 200 of 813 matches
Mail list logo
