Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

Hi, Le vendredi 24 septembre 2021 à 12:23 +0100, Dima Pasechnik a écrit : > > On Fri, 24 Sep 2021, 02:12 Matthias Koeppe, > wrote: > > I repeat my strong objections to the proposed change -- which does > > not solve any problems and only creates new ones. > > > > 1. When you refer to the "huge

Re: [sage-devel] Flint-2.6.0 alpha release (testing requested)

Le jeudi 14 mai 2020 à 18:51 +0200, 'Bill Hart' via sage-devel a écrit : > The (latest) commit c6319d1d36248f2fc699e833ab2f6fa70d21e906 in the > official Flint repository [1] is flint-2.6.0-alpha1. You could tag it : that would be clearer. Something like "git tag 2.6.0-alpha1" then "git push --t

Re: [sage-devel] Packaging Sage?

Le dimanche 10 mai 2020 à 15:02 +0200, Thierry Thomas a écrit : > > TL;TR: Packagers, how do you deal with Sage to package it for your > Linux distribution (or *BSD system)? For Debian, we use our packages as much as possible ; the repository can be seen here: https://salsa.debian.org/science-t

Re: [sage-devel] What is pynac 0.7.26.sage-2020-04-03 ?

Hi, Le samedi 02 mai 2020 à 14:03 +0100, Dima Pasechnik a écrit : > > you can recreate a patch from > https://github.com/mkoeppe/pynac/releases > indeed : https://github.com/pynac/pynac/compare/pynac-0.7.26...mkoeppe:pynac-0.7.26.sage-2020-04-03 and it shows : - cygwin patches ; - modificat

[sage-devel] What is pynac 0.7.26.sage-2020-04-03 ?

Hi, I'm maintaining pynac in Debian, with the goal of keeping sagemath packaged in Debian. According to : https://git.sagemath.org/sage.git/tree/build/pkgs/pynac/package-version.txt?h=develop the version in sage is now 0.7.26.sage-2020-04-03, while upstream is 0.7.26. Is there some patch I coul

Re: [sage-devel] Re: Database of number fields

Le samedi 22 février 2020 à 18:36 -0800, Nils Bruin a écrit : > On Saturday, February 22, 2020 at 12:54:47 PM UTC-8, Snark wrote: > > If I understand well, there's a series of build steps : > > pari code -> data files -> sobj > > and the last step is jones.py. > > > > As far as you, the soft

Re: [sage-devel] Re: Database of number fields

Hi, Le samedi 22 février 2020 à 09:33 -0800, Nils Bruin a écrit : > Sorry, code to produce the sobj is already included in the package. > From jones.py: > def _init(self, path): > """ > Create the database from scratch from the PARI files on John > Jones's > web page,

[sage-devel] Database of number fields

Hi, I wanted to package sagemath's optional package "database_jones_numfield" for Debian, but it appears to be merely a binary object. For Debian, I need sources : where is the generation script I can use to re-generate the .sobj? Thanks, JP -- You received this message because you are subscr

Re: [sage-devel] Python 2->3 incompatibility in unpickling

Le mercredi 22 janvier 2020 à 21:35 +, Simon King a écrit : > Consequently, when unpickling my old data with Python-3, I want the > Python-2 str to be interpreted as bytes. However, Python-3 insists on > misinterpreting it as str, and I have trouble to turn that str into > an appropriate bytes.

Re: [sage-devel] Re: Unpickling problem (backwards incompatibility) in Python 3

Hi, Le 02/09/2019 à 22:43, Simon King a écrit : > AFAIK, what I need to unpickle my old data is a way to tell Python-3 > that it shall (at least temporarily) unpickle all strings as bytes, in > the sense that the pickled string  '\x80\x1f' should be understood as > b'\x80\x1f'. Is there a way? I t

Re: [sage-devel] Cremona's database of elliptic curves over rationals : compilation?

Hi, Le 21/08/2019 à 13:43, John Cremona a écrit : > I suggest that you ship the whole thing so that a debian (or derivative) > user who installs the package gets everything they could also get by > either git-cloning the ecdata repository (but without the git history) > or the tarball from github.

Re: [sage-devel] Cremona's database of elliptic curves over rationals : compilation?

Hi, Le 20/08/2019 à 17:02, John Cremona a écrit : > Julien, > > [By the way, the optional spkg which is relevant here is > database_cremona_ellcurve and *not* elliptic_curves.] Yes ; in Debian: - sagemath's standard elliptic_curves is sagemath-database-elliptic-curves (I'm the maintainer) ; - sa

Re: [sage-devel] Cremona's database of elliptic curves over rationals : compilation?

Le 21/07/2019 à 13:19, John Cremona a écrit : > > On Sat, 20 Jul 2019 at 21:08, 'Julien Puydt' via sage-devel > mailto:sage-devel@googlegroups.com>> wrote: > > Le 19/07/2019 à 16:41, John Cremona a écrit : > > > Not written by me, just used

Re: [sage-devel] Cremona's database of elliptic curves over rationals : compilation?

Le 19/07/2019 à 16:41, John Cremona a écrit : > Not written by me, just used by me to update Sage's optional package.  > William would remember who wrote it. I crossed the build/pkgs/elliptic_curves and src/sage/databases/cremona.py files and obtained the following build script. I'm a bit annoy

Re: [sage-devel] Cremona's database of elliptic curves over rationals : compilation?

Le 19/07/2019 à 15:53, John Cremona a écrit : > The code to create the database is in Sage itself.  > See  > https://github.com/sagemath/sage/blob/master/src/sage/databases/cremona.py. Oh, dear... I'll see if I can't turn it into a much shorter piece of code... > I recommend that you hold off for

[sage-devel] Cremona's database of elliptic curves over rationals : compilation?

Hi, I'm considering packaging this database for Debian. I have upstream files: https://github.com/JohnCremona/ecdata I know sagemath wants a cremona.db sqlite3 database, as that's what is in the src/ for the pkg. What I miss is the file turning the data files into the database! For the smaller

Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)

Le 10/01/2019 à 22:03, Jeroen Demeyer a écrit : On 2019-01-10 21:51, 'Julien Puydt' via sage-devel wrote: Didn't François mention changing SAGE_ROOT wasn't needed? He said SAGE_ROOT should only be needed for the packaging system and possibly the doctests. I regard any ne

Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)

Hi, Le 10/01/2019 à 21:48, Jeroen Demeyer a écrit : On 2019-01-10 20:46, 'Julien Puydt' via sage-devel wrote: Perhaps upstream would accept such a trivial change? If you make a ticket for it, sure. But it won't help with SAGE_ROOT. Didn't François mention changing SAG

Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)

Le 10/01/2019 à 20:07, François Bissey a écrit : I have recently made the following change in sage-on-gentoo’s env.py _add_variable_or_fallback('SAGE_LOCAL', sysconfig.get_config_var("prefix”)) which means SAGE_LOCAL is now pulled from the system rather than a seeded value (as it was bef

Re: [sage-devel] python3 report (end of august 2018)

Hi, On 26/08/2018 17:47, Frédéric Chapoton wrote: The patchbot report on sage+python3  for 8.4.b2 has still *many* (and I mean *_many_*) failing doctests. But it also stops badly in the way shown below, complaining that too many files are open. Could somebody investigate this issue, please ? T

Re: [sage-devel] GNU/Linux debian sid/testing: "Error building Sage" 8.3 from git

Hi, Le 17/08/2018 à 11:17, Jörg-Volker a écrit : Another question I have after looking at the binary package of sage for debian 9 is: how was that built? Since in this package all packages using blas and lapack are linked against the system libraries libblas.so, liblapack.so, and libopenblas.

Re: [sage-devel] GNU/Linux debian sid/testing: "Error building Sage" 8.3 from git

Hi, Le 14/08/2018 à 11:20, Jörg-Volker a écrit : Hi, trying to build Sage 8.3 on my GNU/Linux debian testing/sid system with local gcc suite version 8.2.0 fails while compiling scipy. This is on a desktop computer with 4 cores (8 threads) and 32 GB RAM. I have no clue what "testing/sid" mig

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

Hi, Le 25/10/2017 à 00:08, Eric Gourgoulhon a écrit : > Le mardi 24 octobre 2017 20:58:17 UTC+2, Emmanuel Charpentier a écrit : > > > It is true. But we are hoisted by our own petard : from our tutorial > : > "The Sage down

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

Le 23/10/2017 à 15:40, Emmanuel Charpentier a écrit : > BTW : the vote closes in about 20 minutes. This is your last chance to > take back any "too hasty" votes. My vote: no openSSL now - wait until the license issues are solved Snark on #sagemath -- You received this message because you are

Re: [sage-devel] Use system R with sage?

Hi, Le 22/10/2017 à 10:17, Dima Pasechnik a écrit : > my limited experience with helping advanced R users was that it is not really > possible for them to use R from Sage, as they needed R packages that in turn > needed Java runtime. > > And they much preferred things done in R-studio. At some

Re: [sage-devel] python3 status

Hi, Le 13/10/2017 à 17:56, Frédéric Chapoton a écrit : > Cool, no ? Or maybe nobody cares ? Extremely cool! > Many things are still not working. The cmp problem has been much > reduced, but still not fully fixed. On our way is a large-scale unicode > problem, and maybe another large scale hash p

Re: [sage-devel] Re: Faster way to load python code

Hi, Le 17/09/2017 à 11:56, Simon King a écrit : > On 2017-09-17, Dima Pasechnik wrote: >> Isn't it what pickle/cPickle is for? > > I don't want to store data, I want to read them. And I am not the > one who stored them. So, I have to take the textfiles as I get > them. You could have the textf

Re: [sage-devel] Calculation Error

Hi, Le 26/08/2017 à 22:57, Dr. David Kirkby (Kirkby Microwave Ltd) a écrit : > I'm not a mathematician, but believe 0^0 is undefined. You can either consider 0^0 to be undefined or that it is 1 by convention : both are "correct", and neither should be considered a bug. Snark on #debian-science

Re: [sage-devel] python3 (not yet, and not for soon)

Hi, Le 07/08/2017 à 11:54, Erik Bray a écrit : > I'm working on a better solution to this as part of a more general > reworking of how Sage's dist handles dependencies that can be > fulfilled by multiple packages (in this case the dependency being > 'python'--specifically the Python used for Sage

Re: [sage-devel] Re: Python3?

Hi, On 19/01/2017 18:44, William Stein wrote: On Thu, Jan 19, 2017 at 9:39 AM, Jeroen Demeyer wrote: On 2017-01-19 17:17, William Stein wrote: ... and presumably what we already decided is now completely impossible to implement and banned from Python3? I don't think we ever decided anythi

Re: [sage-devel] Re: Python3?

Hi, On 19/01/2017 08:47, Frédéric Chapoton wrote: The problem with cmp is quite hard, and it seems that every instance of cmp() must be handled separately. I have gained some experience on the subject, but given the lack of reviewers, this implies a very slow pace. This cmp problem should be th

Re: [sage-devel] Release note auto-generation RFC

On 12/01/2017 09:54, Kwankyu Lee wrote: Wouldn't some directive like "If you think ticket #314159 is of wider interest, all you have to do is to fill in the Changes-7.6.rst file" make it possible to both drop this new tool and allow a richer structure? Said Changes-.rst could st

Re: [sage-devel] Release note auto-generation RFC

Hi, On 12/01/2017 00:09, Volker Braun wrote: There is a somewhat painless approach to generating human-readable release notes using https://github.com/hawkowl/towncrier. As far as the ticket author is concerned, if you think that your ticket #12435 is of wider interest and should be announced th

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

Hi, On 28/10/2016 15:39, Emmanuel Charpentier wrote: However, this does not seem to be a problem per se : Debian (one of the most nitpicking distros in terms of licensing) happily ships libraries and utilities (such as cups, for starter) linked with openssl-linked libcurl. I think that it wou

Re: [sage-devel] Upstream links for purely sage package

Hi, On 07/10/2016 12:19, Jeroen Demeyer wrote: On 2016-10-06 12:58, 'Julien Puydt' via sage-devel wrote: For those sage-is-upstream packages, I was pointing the helper to http://files.sagemath.org/spkg/upstream/ but now it looks like those are not available anymore on the sa

[sage-devel] Upstream links for purely sage package

Hi, I'm the maintainer of a few Debian packages, for which sage is considered upstream: rubiks sagemath-database-mutually-combinatorial-designs sagemath-database-conway-polynomials sagemath-database-elliptic-curves sagemath-database-graphs sagemath-database-polytopes To detec

Re: [sage-devel] Re: What in Sage uses Boost ? And who maintains it ?

Polybori is now brial if I remember well. Snark on? #sagemathLe 11 nov. 2015 15:21, Simon King a écrit : > > Hi! > > On 2015-11-11, 'Martin Albrecht' via sage-devel > wrote: > >> 1) What in Sage uses Boost ? > > > > I know this one: PolyBoRi. > >  > >> 2) Is someone maintaining it ? > >

Re: [sage-devel] which computation is right?

Hi, Le 20/10/2015 22:28, Sarfo a écrit : could anyone please tell me which computation evaluated in the attached file is right? Thank you. All of them? Snark on #sagemath -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from thi

Re: [sage-devel] First Joint GAP-​Sage Days (St Andrews, January 2016)

Le 16/10/2015 11:20, Samuel Lelievre a écrit : 2015-10-12 22:45:08 UTC+2, Snark: Le lundi 12 oct. 2015 à 13:02:38 (-0700), Volker Braun a écrit : > On Monday, October 12, 2015 at 3:46:29 PM UTC+2, Snark wrote: > > > > Does that mean that the libgap in sagemath will get part

Re: [sage-devel] First Joint GAP-​Sage Days (St Andrews, January 2016)

Le lundi 12 oct. 2015 à 13:02:38 (-0700), Volker Braun a écrit : > On Monday, October 12, 2015 at 3:46:29 PM UTC+2, Snark wrote: > > > > Does that mean that the libgap in sagemath will get part of upstream GAP? > > > > A better interop between Sage and GAP is definitely desirable. I don't > thin

Re: [sage-devel] First Joint GAP-​Sage Days (St Andrews, January 2016)

Le lundi 12 oct. 2015 à 13:50:04 (+0100), Alexander Konovalov a écrit : > we are happy to announce the First Joint GAP-​Sage Days which > will take place in St Andrews on January 18th-22nd, 2016. They > will be preceded by a GAP Coding Sprint on January 13th-16th. > > For the 1st Joint GAP-Sage

Re: [sage-devel] Fwd: Re: nauty in Sage

Le vendredi 09 oct. 2015 à 09:43:31 (-0700), Dima Pasechnik a écrit : > > On Friday, 9 October 2015 09:26:48 UTC-7, Nathann Cohen wrote: > > > > > we talk about nauty being included into Sage - the permission is being > > given > > > for this, and only this, AFAIU... > > > > I don't think that "

Re: [sage-devel] Fwd: Re: nauty in Sage

Hi, Le vendredi 09 oct. 2015 ą 07:30:06 (-0700), Dima Pasechnik a écrit : > On Thursday, 8 October 2015 11:46:34 UTC-7, Jeroen Demeyer wrote: > > > > On 2015-10-08 20:22, Dima Pasechnik wrote: > > > if it talks about changes, this means changes are allowed, no? > > Well, in principle I agree, bu

Re: [sage-devel] Re: Nauty vs SageMath speed comparisons?

Hi, Le mardi 06 oct. 2015 à 16:28:57 (-0700), Dima Pasechnik a écrit : > > On Tuesday, 6 October 2015 06:18:43 UTC-7, Jeroen Demeyer wrote: > > > > On 2015-10-06 15:15, kcrisman wrote: > > > Wasn't there some email relatively recently where the author of nauty > > > said it was actually okay to

Re: [sage-devel] How to declare dependencies of new-style packages?

Le dimanche 04 oct. 2015 à 13:31:19 (-0700), Simon King a écrit : > > OK. But what should happen, if I replace it with $(INST)/$(MEATAE) ? > Shouldn't it fail with an error? Well, it didn't (which was a bug, IMHO), > at least on a branch that was not very old. Hopefully the latest develop > wor

Re: [sage-devel] William Stein - CEO, SageMath, Inc. http://sagemath.com

Hi, On 12/08/2015 19:55, Nathann Cohen wrote: Hello William, I cannot say that I like your new signature the slightest bit [1]. I feel like the work to software I contribute is being stolen by somebody who wants to make money off it. I feel like its name has been stolen too. Sagemath is clearl

Re: [sage-devel] Automatically test Maple, Magma [...] when running the tests

Hi, Le 17/07/2015 12:59, Dima Pasechnik a écrit : On Friday, 17 July 2015 11:40:04 UTC+1, Snark wrote: Hi, Le 16/07/2015 13:16, Jeroen Demeyer a écrit : > On 2015-07-16 13:03, Nathann Cohen wrote: >> What is somebody has such an >> install and *wants* to use it with Sag

Re: [sage-devel] Automatically test Maple, Magma [...] when running the tests

Hi, Le 16/07/2015 13:16, Jeroen Demeyer a écrit : On 2015-07-16 13:03, Nathann Cohen wrote: What is somebody has such an install and *wants* to use it with Sage? This points to the core problem: we simply have no way to guess whether people want to do that or not. Here is a possible compromis

Re: [sage-devel] Re: Build system changes in 6.8.beta7

Hi, Le vendredi 03 juil. 2015 à 16:51:19 (+0100), Nathann Cohen a écrit : > > but this is not interactive and no confirmation is requested. Should it? > > My understanding is that you do not need to in this situation: the > user explicitly asked to install a non-GPL-compatible software, so "he >

Re: [sage-devel] Re: About the planarity package

Le 23/06/2015 12:40, Jeroen Demeyer a écrit : On 2015-06-23 09:44, Julien Puydt wrote: But after some digging around : - the tarball isn't pristine, it's heavily patched ; It's not "heavily patched", just the build system was changed. *just* ! - one has to

Re: [sage-devel] Re: About the planarity package

Hi, Le 22/06/2015 17:25, Nathann Cohen a écrit : I was heartily congratulating about having small reasonable patches to upstream, and you tell me that they're in fact against an heavily patched upstream, and upstream's licensing situation is muddy... no need to troll when the facts are so prepo

Re: [sage-devel] Re: About the planarity package

Le 22/06/2015 16:24, Nathann Cohen a écrit : How did a package in such a messy state become standard !? If you honestly want to find out and it's not just trolling, here is all I know: commit 7197d452d277ac0e186776e60176ade03ab952ec Author: Nomail Name Date: Mon Feb 4 14:49:02 2008 -0800

Re: [sage-devel] Re: About the planarity package

Hi, Le 22/06/2015 13:53, Nathann Cohen a écrit : Hell, - where is the upstream repository ? [the SPKG.txt only gives the author's name] https://code.google.com/p/planarity/ - the patches look nice : were they sent upstream ? There is a long litterature about this packag

[sage-devel] About the planarity package

Hi, I was pondering packaging the planarity package in debian, but : - where is the upstream repository ? [the SPKG.txt only gives the author's name] - the patches look nice : were they sent upstream ? Thanks, Snark on #sagemath -- You received this message because you are subscribed to th

Re: [sage-devel] Packaging rant

Hi, Le 12/06/2015 11:18, Jeroen Demeyer a écrit : On 2015-06-11 10:31, Julien Puydt wrote: Open software is about cooperation. Of course. The question is: what should we do if upstream does not want to cooperate? I don't want to call names in this thread, but I have proposed patches to

Re: [sage-devel] Packaging rant

Hi, Le 11/06/2015 10:28, Jeroen Demeyer a écrit : On 2015-06-11 03:40, François Bissey wrote: * fork upstream and keep it as a separate package but no one really wants to be the maintainer. If it's decided that we are allowed to fork polybori, can this be applied to other packages too? I hav

Re: [sage-devel] Re: Is there an online index of the standard packages shipped in Sage?

Hi, Le 12/05/2015 17:19, Thierry a écrit : On Tue, May 12, 2015 at 07:19:07AM -0700, Volker Braun wrote: IMHO: * The package type (standard/optional/experimental) should be in a file inside the package directory +1. Actually, i have a prototype of this for the purpose of checking to the upst

Re: [sage-devel] Re: [ARM] sage 6.6 -- bdist?

Le Sat, 18 Apr 2015 16:17:53 -0700 (PDT), Volker Braun a écrit : > Its a quad-core ARMv7 Cortex-A9 with 4gb ram iirc. (Calxeda) That's much more powerful than what I have here, and it shouldn't take that long to build sage 6.6 : the chromebook I (try to) use has an exynos 5 and 2Go of RAM and

Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

Le Sat, 18 Apr 2015 11:20:59 +0200, Nathann Cohen a écrit : > Hello, > > > We somehow have to come to a conclusion. > +1 > > > Never change positive_review_tickets (and adapt developer guide, > > see #18228) > -1 > > > Cool-off period > +0.5 > > Freezing tickets once release manager starts mer

Re: [sage-devel] Re: [ARM] sage 6.6 -- bdist?

Le Fri, 17 Apr 2015 04:52:10 -0700 (PDT), Volker Braun a écrit : > Still building! > > On Friday, April 17, 2015 at 4:06:38 AM UTC-4, Snark wrote: > > > > Hi, > > > > will a bdist of sage 6.6 for ARM be available using a buildbot, or > > shall I compile one myself ? > > > > Snark on #sagemath

[sage-devel] [ARM] sage 6.6 -- bdist?

Hi, will a bdist of sage 6.6 for ARM be available using a buildbot, or shall I compile one myself ? Snark on #sagemath -- 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 emai

Re: [sage-devel] Re: pynac-0.3.3

Le Thu, 09 Apr 2015 18:38:24 +0200, Vincent Delecroix <20100.delecr...@gmail.com> a écrit : > Hello, > > I found > > sage: abs(sqrt(x)) > sqrt(abs(x)) > > much better than > > (%i1) abs(sqrt(x)); > (%o1) sqrt(x) > > We discussed in #15605 that variables in the sy

Re: [sage-devel] Re: On MacDonald polynomials and pickling

Hi, Le 23/03/2015 19:22, Volker Braun a écrit : The pickle jar is about old pickles, to test that they can be unpickled. So the pickles were created with an old version of Sage. Its odd that we lost the ability to pickle them over time. Hmmm... so the pickling problem I'm trying to debug is ab

[sage-devel] On MacDonald polynomials and pickling

Hi, I'm still trying to track why calling unpickle_all twice leads to a SIGABRT crash with our experimental debian package. After some toying around, it turned out that within the whole pickle jar, only the files related to MacDonald polynomials are giving issues. That is why I'm trying to

Re: [sage-devel] Re: libgap pickling

Le 15/03/2015 21:16, Simon King a écrit : Hi Vincent, On 2015-03-15, Vincent Delecroix <20100.delecr...@gmail.com> wrote: But in that very particular case, just evaluating the string representation in GAP gives you back the same group Yes, "in *that* very particular case". So, it is not pos

Re: [sage-devel] Re: White-haired needs_review tickets

Le 14/03/2015 16:32, Ralf Stephan a écrit : On Wednesday, March 11, 2015 at 5:44:53 PM UTC+1, Snark wrote: What should be really done with long-waiting needs_review tickets ? See them as a database of ideas, similar to 5-year old requests for enhancement. Tickets are a database of ideas.

Re: [sage-devel] White-haired needs_review tickets

Le 11/03/2015 17:53, William Stein a écrit : 1. Setup/write an editorial notification system to encourage the reviewing of tickets, similar to how every journal on the planet has an automated system for ensuring papers get reviewed, seeing the status of outstanding papers, etc. Maybe we coul

[sage-devel] White-haired needs_review tickets

Hi, I was thinking it would be interesting to have a look at the tickets needing review, so I browsed the list... and saw one of them was waiting since about three years (sic). I put it to needs_info because obviously everything in it is so clearly outdated. But then there are also many who a

Re: [sage-devel] About sys_path_security.patch in the python spkg

Le 09/03/2015 16:51, Jeroen Demeyer a écrit : On 2015-03-09 16:47, Julien Puydt wrote: I was wondering about the sys_path_security.patch patch in the python spkg: (1) where is it coming from? http://trac.sagemath.org/ticket/13579 (2) why what it does isn't made in src/sage/do

[sage-devel] About sys_path_security.patch in the python spkg

Hi, I was wondering about the sys_path_security.patch patch in the python spkg: (1) where is it coming from? (2) why what it does isn't made in src/sage/doctest/control.py, where the test_safe_directory function looks like the ideal place for this ? (3) has it been forwarded upstream? Snark on

Re: [sage-devel] Looking at sage compiling

Le 09/03/2015 11:23, Jeroen Demeyer a écrit : On 2015-03-09 11:04, Julien Puydt wrote: (2) ... which brings me to the second remark : install.log ends by telling me the doc will be built... but it's still compiling sage itself! So a whole chunk of the compilation happens without a log :

[sage-devel] Looking at sage compiling

Hi, I'm bored, looking at sage compiling once again... and notice two things : (1) there is a good amount of warnings flying by (well, "flying" might not be very accurate... the box is slow) ; I guess most of them are harmless and might be due to cython spitting out innocent code, but still,

Re: [sage-devel] [Debian] Strange crash in ECL

Le 26/02/2015 10:15, Julien Puydt a écrit : Le 26/02/2015 10:08, Francois Bissey a écrit : So I think we can say there is something going with gmp 6.0.0. I think that should narrow things down considerably. I'll report our findings to upstream -- that should definitely interest them, and

Re: [sage-devel] [Debian] Strange crash in ECL

Le 26/02/2015 10:08, Francois Bissey a écrit : So I think we can say there is something going with gmp 6.0.0. I think that should narrow things down considerably. I'll report our findings to upstream -- that should definitely interest them, and help pinpoint the issue. Thanks! Snark on #sag

Re: [sage-devel] [Debian] Strange crash in ECL

Le 26/02/2015 09:05, Francois Bissey a écrit : Ok what version of gmp? 5.1.3 here. I have 6.0.0. Snark -- 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-dev

Re: [sage-devel] [Debian] Strange crash in ECL

Le 26/02/2015 08:20, Francois Bissey a écrit : On 26/02/2015, at 20:12, Julien Puydt wrote: Le 25/02/2015 22:43, François Bissey a écrit : That's fun, on Gentoo my ecl from the system just chew it without crashing. What options are you using to build ecl I currently have --enable-un

Re: [sage-devel] [Debian] Strange crash in ECL

Salut, Le 25/02/2015 23:00, Jean-Pierre Flori a écrit : Not really related but it seems ECL saw an update! Their homepage says 15.2.21, but the dowload page is always 13.5.1. As I mentioned, upstream confirmed the bug, including for their latest and greatest. Snark on #sagemath -- You rec

Re: [sage-devel] [Debian] Strange crash in ECL

Le 25/02/2015 22:43, François Bissey a écrit : That's fun, on Gentoo my ecl from the system just chew it without crashing. What options are you using to build ecl I currently have --enable-unicode -with-x and the rest turned off. Would it be thread related by any chance? Sage is using mpir a

Re: [sage-devel] [Debian] Strange crash in ECL

Hi, Le 25/02/2015 10:56, Julien Puydt a écrit : it is a strange problem I have : using either debian's ecl or upstream's the following code : (ext:set-limit 'ext:heap-size 0) (setq a (expt 10 (expt 10 5))) (setq b (expt a 600)) gives a crash (SIGABRT) "Duplicate larg

Re: [sage-devel] Re: [Debian] Strange crash in ECL

Le 25/02/2015 17:20, Nils Bruin a écrit : On Wednesday, February 25, 2015 at 1:56:39 AM UTC-8, Snark wrote: Hi, it is a strange problem I have : using either debian's ecl or upstream's the following code : (ext:set-limit 'ext:heap-size 0) (setq a (expt 10 (expt 10 5))) (setq b (expt a 600))

[sage-devel] [Debian] Strange crash in ECL

Hi, it is a strange problem I have : using either debian's ecl or upstream's the following code : (ext:set-limit 'ext:heap-size 0) (setq a (expt 10 (expt 10 5))) (setq b (expt a 600)) gives a crash (SIGABRT) "Duplicate large block deallocation". Where things get interesting, is that I get th

Re: [sage-devel] Re: [ARM] sage 6.5

Le 23/02/2015 16:25, Volker Braun a écrit : Yes, exactly! On Monday, February 23, 2015 at 4:16:40 PM UTC+1, Snark wrote: If I put something similar in configure_fast, will I be able to test it looks good using : export SAGE_ATLAS_ARCH=fast ./sage -f atlas It's ticket #17843. And this tim

Re: [sage-devel] Re: [ARM] sage 6.5

Le 23/02/2015 15:48, Julien Puydt a écrit : Le 23/02/2015 15:40, Jean-Pierre Flori a écrit : I agree with Volker, just put one thing here. I would say: arch='ARMv6' for base (and arch="ARMv7" for fast if you want to enable a "fast" configuration). It would als

Re: [sage-devel] Re: [ARM] sage 6.5

Le 23/02/2015 15:40, Jean-Pierre Flori a écrit : I agree with Volker, just put one thing here. I would say: arch='ARMv6' for base (and arch="ARMv7" for fast if you want to enable a "fast" configuration). It would also be good to put ISA="" (don't remember the var name or syntax) to explicitely d

Re: [sage-devel] Re: [ARM] sage 6.5

Le 23/02/2015 15:34, Volker Braun a écrit : The "base" configuration is supposed to be a fixed one. If you want to tune for your respective cpu then we can do that already. What do we fix to, then armv7 or armv6 ? Snark on #sagemath -- You received this message because you are subscribed to t

Re: [sage-devel] Re: [ARM] sage 6.5

Le 23/02/2015 15:33, Dima Pasechnik a écrit : hmm, shouldn't there also be a distinction between hardware and software floats? (Although I believe ARM chips you want to run Sage on all have hardware floats - but the question is how the OS is configured). There is already code in spkg-install

Re: [sage-devel] Re: [ARM] sage 6.5

Le 23/02/2015 15:05, Julien Puydt a écrit : Le 23/02/2015 14:27, Julien Puydt a écrit : That will take some time though : this box isn't fast. And I work on it while it plays with sage. In fact, when an arch is given, it does compile ad nauseum so it doesn't take that much time.

Re: [sage-devel] Re: [ARM] sage 6.5

Le 23/02/2015 14:27, Julien Puydt a écrit : Hi, Le 23/02/2015 12:13, Volker Braun a écrit : In spkg-install you need to add a suitable branch in configure_base(): Yes, but my question was : how do I know how to write that branch? I didn't manage to get "from configuration impor

Re: [sage-devel] Re: [ARM] sage 6.5

Hi, Le 23/02/2015 12:13, Volker Braun a écrit : In spkg-install you need to add a suitable branch in configure_base(): Yes, but my question was : how do I know how to write that branch? I didn't manage to get "from configuration import conf" to work, so I couldn't look at 'conf' to know what

Re: [sage-devel] Re: [ARM] sage 6.5

Hi, Le 21/02/2015 17:25, Volker Braun a écrit : The atlas build script just aborts with SAGE_ATLAS_ARCH=base, nothing else to see here. I compiled sage-6.5 with my usual setup, then tried: export SAGE_FAT_BINARY=yes ./sage -f atlas and the compilation with : Traceback (most recent call last):

Re: [sage-devel] [debian] Strange numerical errors in sage's libpari code

Hi, Le 18/02/2015 13:53, Julien Puydt a écrit : I'm having strange numerical behaviour with my experimental sage using debian packages, with two failing doctests in the src/sage/libs/pari/ directory (both in gen.pyx) : Failed example: (s*z)^5 Expected: 2.0

Re: [sage-devel] GP/PARI hangs with sage-6.4.1/6.5 on Ubuntu 14.04.2 LTS

Hi, Le 22/02/2015 20:34, Franco Saliola a écrit : Hello sage-devel, I sent the following email to sage-release, but I think it really belongs here. I'm looking for ideas on how to debug (or better, how to fix) the problems with GP/PARI interface that are causing sage to hang. The symptoms lo

Re: [sage-devel] Re: [ARM] sage 6.5

Le 21/02/2015 14:56, Volker Braun a écrit : We have an ARM buildbot but it doesn't work: atlas install fails when SAGE_FAT_BINARY=yes is set. If you have an idea about suitable defaults then we could make it automatic *hint* Is there a trac ticket or some such on the matter, with some kind of

[sage-devel] [ARM] sage 6.5

Hi, is there an ARM build box which will take care of preparing a bdist which I'll just have to unpack, or shall I build such a bdist as usual ? Snark on #sagemath -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

Le 21/02/2015 11:15, Volker Braun a écrit : I agree that we should have some user configuration mechanism to customize how we build packages (including replacing sage packages with distro dependencies), but going about it by patching Sage or adding $DISTRO subdirectories everywhere are crap. Some

Re: [sage-devel] Re: Sage trac : can't stay logged in

Le 19/02/2015 17:20, Julien Puydt a écrit : Le 19/02/2015 16:30, Volker Braun a écrit : worked for me... Sigh... still doesn't... so there's a problem on my end :-( Cleared everything I could, checked I didn't block anything, the logged in, refreshed, still logged in, trie

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

Hi, Le 20/02/2015 01:22, William Stein a écrit : On Thu, Feb 19, 2015 at 12:51 PM, Francesco Biscani wrote: On 19 February 2015 at 18:05, Julien Puydt wrote: All distributions have thousands of packages, and deps are not a big issue. Sage-the-distribution has about a hundred, and it

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

Hi, Le 20/02/2015 01:07, Volker Braun a écrit : On Thursday, February 19, 2015 at 6:36:38 PM UTC+1, Snark wrote: Sage's libgap and cddlib are problems : they correspond to upstreams That is not correct, there is no upstream library interface to gap. So there is no conflict. However, Debian i

Re: [sage-devel] [debian] Strange numerical errors in sage's libpari code

Le 19/02/2015 22:15, Francois Bissey a écrit : But some of us would like to be given some consideration. +1 Snark on #sagemath -- 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,

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

Le 19/02/2015 18:54, Michael Orlitzky a écrit : This presupposes that the status quo is not madness. My sage builds work for about two weeks before some invisible dependency update breaks them. There's a line in sage beyond which we just don't care about dependencies. We ship gcc, some utilities,

  1   2   3   4   5   6   7   8   >