Re: [sage-devel] how to force package recompilation?

On 2015-09-12 10:24, Ralf Stephan wrote: In the recent beta something seriously changed That is certainly true, I'll write a more detailed post later. There are more changes coming. However, even in 6.9.beta6, "sage -f pynac" still works for me, so you need to give more details for me to repr

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-12 09:48, Simon King wrote: All versions from 2.1.2 till now were at least partially motivated by coping with backward incompatible changes. I am probably responsible for several of these backward incompatible changes. However, they were changes to the basic Sage infrastructure, li

Re: [sage-devel] Should we still support old-style packages?

On 2015-09-11 14:16, Volker Braun wrote: always pose loaded questions. I hope that's not an accusation. -- 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-deve

Re: [sage-devel] Should we still support old-style packages?

On 2015-09-11 14:07, Sébastien Labbé wrote: On Friday, September 11, 2015 at 1:10:47 PM UTC+2, Jeroen Demeyer wrote: On 2015-09-11 12:37, Sébastien Labbé wrote: > There are packages out there that are not listed on official > sagemath.org/packages_lists <http://sag

Re: [sage-devel] Should we still support old-style packages?

On 2015-09-11 12:37, Sébastien Labbé wrote: There are packages out there that are not listed on official sagemath.org/packages_lists True, but that's not what this thread is about. Nothing will change to externally-hosted old-style packages. -- You received this message because you are subscri

Re: [sage-devel] Re: A script to perform "old spkg -> new-style package"

On 2015-09-11 11:41, Simon King wrote: I published a working old-style spkg that copes with the backward incompatible changes that broke the "official" optional spkg. Great! Let's just use that and revert #19004. No Nathann script needed. -- You received this message because you are subscribed

Re: [sage-devel] Re: A script to perform "old spkg -> new-style package"

On 2015-09-10 20:12, Simon King wrote: Hi Jeroen, On 2015-09-10, Jeroen Demeyer wrote: It seems that people which are against old-style packages are against them because they are broken. Those people will probably be against old-converted-to-new-style packages too. Didn't Volker say

Re: [sage-devel] Should we still support old-style packages?

On 2015-09-10 20:30, John H Palmieri wrote: I could also be easily persuaded to (B) if we don't allow "sage -i python" to install the old python-2.5 package. Are you willing to review #19119? It's a dependency for #19105 which would do exactly that. -- You received this message because you are

Re: [sage-devel] A script to perform "old spkg -> new-style package"

On 2015-09-10 19:50, Nathann Cohen wrote: the other conversation with options A/B/C/D/E can be forgotten as a result. It seems that people which are against old-style packages are against them because they are broken. Those people will probably be against old-converted-to-new-style packages t

Re: [sage-devel] A script to perform "old spkg -> new-style package"

On 2015-09-10 19:16, Nathann Cohen wrote: Hello everybody, I wrote a short bash script that does the following: 1) Create a .tar.gz tarball containing the old .spkg package 2) Create a new-style folder $SAGE_ROOT/build/pkgs/ with the necessary files Sorry to say this Nathann, but what's the p

Re: [sage-devel] "faking" install of a package

On 2015-09-10 16:23, kcrisman wrote: say, if it didn't build on platform X but you wanted to test the rest of the build of Sage Use MAKE="make -k" for this. It will prevent make from aborting on error. It will still respect dependencies, so if package A fails and package B depends on A, then

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-10 15:14, Nathann Cohen wrote: I do not have your faith that *all* of the guys who appear as maintainers of a package would, when receiving such a bug report, immediately fix it or make sure that it will not be forgotten. Asking people to write to sage-devel sounds safer to me. +1 Be

Re: [sage-devel] Should we still support old-style packages?

at we currently have). Votes so far are: (B): Jeroen Demeyer, Simon King (D): Volker Braun, John Cremona, John Palmieri Anybody else wants to give his/her opinion? Jeroen. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubs

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-09 22:17, Thierry wrote: sorry for not participating actively to this long thread, i am currently pretty far from computers. Let me just mention that this discussion already appears some time ago, and that somehow, the mailing-list is probably not the appropriate tool for solving such

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-09 21:34, Volker Braun wrote: On Wednesday, September 9, 2015 at 6:00:22 PM UTC+2, Simon King wrote: Are you saying that the fact that something *works* If FEATURE gives you 1 case that works and 99 that fail then it is not a good feature. Just working rarely is not good enough.

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-09 19:14, Nathann Cohen wrote: Is there a list of those old spkg somewhere? http://files.sagemath.org/spkg/index.html We could see what there is to do by putting it on a wiki page Like this one: http://wiki.sagemath.org/Classify%20old-style%20packages -- You received this message

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-09 19:03, William Stein wrote: On Wed, Sep 9, 2015 at 8:22 AM, Simon King wrote: On 2015-09-09, Nathann Cohen wrote: Another way to "fix" the problem: (E) Convert the remaining old-style packages to new-style packages. I personally really like this suggestion. That's of cours

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-09 17:06, John H Palmieri wrote: I think that we should white-list at least some of these, and also try to convert some of them (all of them?) to new-style packages. Same with Simon's p_group_cohomology package, which didn't build correctly for me. I don't have objections to leaving th

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-09 18:24, Simon King wrote: Hi Volker, On 2015-09-09, Volker Braun wrote: On Wednesday, September 9, 2015 at 5:45:14 PM UTC+2, Simon King wrote: However, I believe that "sage -i " should still be supported. Agree, and this is not what this thread is about. Is it not? OK, then

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-09 18:36, Dima Pasechnik wrote: compared to the effort of keeping the whole support for them... There is no "effort" needed, we just need to undo the intentional breaking of the support. -- You received this message because you are subscribed to the Google Groups "sage-devel" group

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-09 16:42, Travis Scrimshaw wrote: A possible (hack) fix is to put something in the skpg script to explicitly ban it from installing python without specifying 2 or 3. Assuming #19119, it's very easy to this. Just two short lines need to be added to build/make/deps (one for sage -i

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-09 15:06, Volker Braun wrote: Other than deleting them all from the server, of course. The latter *would* also solve the problem. Just like reformatting your hard drive will instantly remove all software issues that you might have with your computer. -- You received this message b

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-09 14:34, Nathann Cohen wrote: This way they would all become new-style packages at a very low cost. And which problem would that solve? It would then be possible to install them with "sage -i ", which is I belive the reason you created this thread? But by reverting #19004 (which

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-09 13:14, Volker Braun wrote: Because not even 1 out of 100 will figure out that "python" actually tries to install the old and unsupported package. There are other solutions to that problem, any of the following will do: * a proper implementation of (B) to make them figure it out *

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-09 13:33, Nathann Cohen wrote: Another option: would it be possible to make "fake new-style packages", whose upstream/ tarball would be the .spkg? This way they would all become new-style packages at a very low cost. And which problem would that solve? -- You received this message

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-09 12:01, Volker Braun wrote: in order to make Sage accessible to 100 other users then we should do that. How does option (D) make "Sage accessible to 100 other users" compared with options (B) or (C)? -- You received this message because you are subscribed to the Google Groups "

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-09 11:26, John Cremona wrote: Not quite -- I was proposing to display the message and *not* install the package OK, so this is (D'): sage -i OLDSTYLEPKGNAME should give an error. However, it should determine whether an old-style package named OLDSTYLEPKGNAME exists and adjust the er

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-09 10:50, John Cremona wrote: Re (B): a deprecation warning is normally a message to the user that they should start to do things in a different way, as the old way will stop working. This does not seem appropriate here, since it is not the user who is expected to change behaviour (un

Re: [sage-devel] Re: Should we still support old-style packages?

On 2015-09-09 10:15, Nathann Cohen wrote: Another way to "fix" the problem: (E) Convert the remaining old-style packages to new-style packages. Of course we should do that, but that's orthogonal to the question I asked. I don't think that (E) is going to happen short-term. As long as there i

[sage-devel] Should we still support old-style packages?

Hello, as you might know, we currently have two kinds of packages in Sage: the old-style .spkg files which were the norm in Sage 5.x and the new-style $SAGE_ROOT/build/pkgs packages which are currently the norm. The question is: to what extent should we continue supporting old-style packages

Re: [sage-devel] Re: GAP3 spkg

On 2015-09-08 20:45, Dima Pasechnik wrote: This package is a potential virus. It distributes and installs executables. Is this acceptable?!! Obviously not. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop

Re: [sage-devel] Tarball uploads

On 2015-09-07 19:38, Volker Braun wrote: On Monday, September 7, 2015 at 7:29:54 PM UTC+2, Jeroen Demeyer wrote: So, can you remind us what exactly is the use case for this server? The goal is no manual steps when handling third-party tarballs Sorry, but I am lost. How are we, Sage

Re: [sage-devel] Tarball uploads

On 2015-09-07 18:25, Volker Braun wrote: Yes, thats intentional. Filenames might be wrong (requiring some further UI to change it) but the sha1 is tautologically correct. So, can you remind us what exactly is the use case for this server? -- You received this message because you are subscribed

Re: [sage-devel] Tarball uploads

On 2015-08-08 21:22, Volker Braun wrote: In order to streamline updating third-party tarballs I've written a small web app where you can directly upload them. That way you don't need to host files yourself. Plus, the files can be retrieved by sha1 so with a little bit more scripting I won't alway

Re: [sage-devel] Re: What is the expected output of .version()?

On 2015-09-06 22:38, Simon King wrote: Would you say that .version() should be consistent in the type of the return value, i.e., that it should always return a string? Or do you think it is ok that some interfaces return a string, some return a pair formed by a tuple and a string, some return an

Re: [sage-devel] Re: TAB, the patchbot and trac

On 2015-09-06 21:25, Frédéric Chapoton wrote: well, one would have the same problem with commas... No, my old release manager script used the CSV data and I never had any problem. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe

Re: [sage-devel] What is the expected output of .version()?

On 2015-09-06 20:33, Simon King wrote: First question: Would you agree that all interfaces should return a string that corresponds to the typical content of the package-version.txt files? No. I don't think that package-version.txt should be used as answer to package.version() in Sage. I consid

Re: [sage-devel] Pretty confusing problem stoping Sage 6.9.beta5 even try to build on OpenSolaris - it used to build fine

On 2015-09-05 11:24, Francois Bissey wrote: I guess something artful could be done about that. Someone should be able to get the behaviour suggested by Jeroen. http://trac.sagemath.org/ticket/19043 -- You received this message because you are subscribed to the Google Groups "sage-devel" group.

Re: [sage-devel] It's confusing including both "configure" and "Makefile" in source.

On 2015-09-05 10:20, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: But Sage has both in the top-level directory Both are used. If it is being used, then the Makefile should not be there. In principle, I agree, but that would require everybody (including scripts and documentation) to change t

Re: [sage-devel] Generate Python classes from C++ headers?

On 2015-09-03 18:27, Francesco Biscani wrote: It's not automatic, in the sense that you will have to write C++ source files in which you are specifying exactly what and how you want to expose. There are plenty of non-automatic solutions (Cython for example), that's not the problem. -- You rece

Re: [sage-devel] Generate Python classes from C++ headers?

On 2015-09-03 16:16, Nathann Cohen wrote: Given a compiled library Certainly not from the *compiled* library, you would at least need the C++ source code. (or .cc files) and header files, can't Cython automatically generate the code that would expose those classes at Python lev

Re: [sage-devel] Tarball uploads

On 2015-08-08 21:22, Volker Braun wrote: http://fileserver.sagemath.org:8080/ Seems down... -- 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+unsu

Re: [sage-devel] random doctest failure in modular/modform/ambient.py

On 2015-09-02 03:47, Vincent Delecroix wrote: Hello, The patchbot zorn gets unhappy with one file [1]. This is the first time I see this but it seems related to #15535. It's indeed that bug. It's in linbox, so let's hope it gets fixed by upstream. -- You received this message because you ar

Re: [sage-devel] update reference with sage -docbuild problem

Please forgive me for stating the obvious, but you can just run "make" which builds the Sage library (like sage -b) and the documentation (like sage --docbuild...) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group an

Re: [sage-devel] Short fr, de, pt, ru translation

Thanks! I added everybody who participated in this thread as author or reviewer of #19106. Can somebody please give a final review? I'm assuming that the translations are fine, but somebody just needs to check that the changes I made make sense from a high-level point of view. See http://trac.

Re: [sage-devel] Short fr, de, pt, ru translation

Any German speakers? On 2015-08-27 21:20, Jeroen Demeyer wrote: If you are a native French, German, Portuguese, Russian speaker, could you please translate the following short paragraph for #19106: For some GAP functionality, you should install two optional Sage packages. This can be done

Re: [sage-devel] Re: Short fr, de, pt, ru translation

Thanks, this is the final version on #19106: Pour utiliser certaines fonctionnalités de GAP, vous devez installer deux paquets Sage optionnels. Cela peut être fait avec la commande:: -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe

Re: [sage-devel] Re: "Creating a Tutorial from a Worksheet" mentions beautifulsoup package

On 2015-08-28 03:37, John H Palmieri wrote: See http://trac.sagemath.org/ticket/19004. Yes, I saw that ticket but I never realized that the "solution" was so drastic, especially given that there is no deprecation at all. -- You received this message because you are subscribed to the Google Gro

Re: [sage-devel] Re: Short fr, de, pt, ru translation

On 2015-08-27 22:59, François Bissey wrote: I also don't like "paquetage" unless I am told it is standard for French localization. In the same document, there is Le logiciel gnuplot est disponible comme paquet optionnel. -- You received this message because you are subscribed to the Google Gr

Re: [sage-devel] Re: Short fr, de, pt, ru translation

On 2015-08-27 22:33, Thierry Dumont wrote: I prefer "Pour utiliser GAP" ou "Pour utiliser les fonctionnalités de GAP". "Pour des fonctionnalités GAP" is not correct french. Pour utiliser *certains* fonctionnalités de GAP... (is this the correct spelling?) -- You received this message because

Re: [sage-devel] Re: "Creating a Tutorial from a Worksheet" mentions beautifulsoup package

On 2015-08-27 22:29, John H Palmieri wrote: Basically, all of the old-style packages are no longer easily available, just the new-style ones. This is not ideal, I think, but it was a solution to the problem of running "sage -i python" and getting an old version of Python installed, which broke Sa

Re: [sage-devel] Re: "Creating a Tutorial from a Worksheet" mentions beautifulsoup package

On 2015-08-27 22:42, kcrisman wrote: If you can open a ticket I may try to fix the wording to this. I made the change as part of #18859. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails fro

[sage-devel] Various packages no longer exist

Some more packages are documented in Sage but no longer actually exist. I found these when grepping for "sage -i": chomp kash (also kash3-linux-2005.11.22 and kash3_osx-2005.11.22) macaulay2 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsu

[sage-devel] cunningham_tables package does not exist

Various Sage library files mention a package 'cunningham_tables' but it seems this package is gone somehow... -- 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

[sage-devel] "Creating a Tutorial from a Worksheet" mentions beautifulsoup package

The file src/doc/en/thematic_tutorials/sws2rst.rst says * Next, you will need an optional package to parse your worksheet. Use the command:: sage -i beautifulsoup but this package no longer exists. -- You received this message because you are subscribed to the Google Groups "sage-dev

[sage-devel] "make ssl" no longer works

The top-level README.txt says 10. OPTIONAL: Read this if you are intending to run a Sage notebook server for multiple users. For security (i.e., to run "notebook(secure=True)") you want to access the server using the HTTPS protocol. First, install OpenSSL and the OpenSSL development

[sage-devel] Short fr, de, pt, ru translation

If you are a native French, German, Portuguese, Russian speaker, could you please translate the following short paragraph for #19106: For some GAP functionality, you should install two optional Sage packages. This can be done with the command:: -- You received this message because you are subsc

Re: [sage-devel] print in doctests

On 2015-08-27 19:01, Daniel Krenn wrote: Is there a reason for having this as it is? The reason is that doctests raising exceptions and normal doctests are treated fundamentally different. You can see this with failed doctests: a non-matching output gives a different message than an exception-

Re: [sage-devel] Re: heisenbugs and heisenerrors while building docs with -jN for N>1 ?

On 2015-08-26 17:49, John H Palmieri wrote: So there is a problem: although the graphs docs should have failed the first time through, the second time through, the docbuilder thought that it had built fine. The problem is that docs which are built with an error are still considered built. The

Re: [sage-devel] git diff wrong?

On 2015-08-18 23:20, Stefan wrote: Can I give something like this positive review, in spite of the trac website messing things up? Yes, the git Trac plugin is known to sometimes give wrong diffs. What matters is what the command-line git says. Jeroen. -- You received this message because yo

Re: [sage-devel] Re: Integer from mpz_t

On 2015-08-19 11:31, Jean-Pierre Flori wrote: On Wednesday, August 19, 2015 at 12:21:36 PM UTC+2, vdelecroix wrote: Note that all the solutions given will *copy* the mpz_t to the Integer. Is that what you want? It is also possible to avoid the copy if it is worth it (i.e. you have

Re: [sage-devel] Re: Should sage -i install *dependencies* of packages?

On 2015-08-18 10:51, Nathann Cohen wrote: Since I maintain an optional package that depends on another optional package that must not be automatically installed because of licence: Will the automatic installation of dependencies be involve asking the user if the licence of the dependency is not G

Re: [sage-devel] Re: Should sage -i install *dependencies* of packages?

On 2015-08-18 10:21, Simon King wrote: Hi, On 2015-08-17 19:00, Jeroen Demeyer wrote: (A) change "sage -i PKG" to also install dependencies (adding some option --no-dependencies to keep the old behaviour) Since I maintain an optional package that depends on another optional package

Re: [sage-devel] Should sage -i install *dependencies* of packages?

On 2015-08-18 21:16, Jeroen Demeyer wrote: Good for me, since it is very close to my proposal (C) I meant (B) here (add an option -m to install with dependencies) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from

Re: [sage-devel] Re: Should sage -i install *dependencies* of packages?

On 2015-08-18 20:42, Volker Braun wrote: On Tuesday, August 18, 2015 at 9:26:44 PM UTC+2, Jeroen Demeyer wrote: An obvious use-case is that you're switching branches/Sage versions and you just want to try to compile a single package and you don't want to be bothered by de

Re: [sage-devel] Should sage -i install *dependencies* of packages?

On 2015-08-18 12:00, Thierry wrote: Actually, i do not see why (A) involves more complexity than (B). 1. We need to define how the various options to -i can be combined, in particular the -f option is tricky. 2. The "sage -i" command would need to do two completely unrelated things: act as high

Re: [sage-devel] Singular random doctest failure?

On 2015-08-18 10:07, Jori Mäntysalo wrote: Failed example: singular.interrupt(timeout=3) # sometimes very slow (up to 60s on This is fixed by #10476. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop

Re: [sage-devel] Re: Should sage -i install *dependencies* of packages?

On 2015-08-18 14:49, Volker Braun wrote: Whats the use case of attempting to install a package without dependencies? An obvious use-case is that you're switching branches/Sage versions and you just want to try to compile a single package and you don't want to be bothered by dependencies. I agre

Re: [sage-devel] Should sage -i install *dependencies* of packages?

On 2015-08-17 19:01, William Stein wrote: Let's at least establish what people are likely to think "sage -i" already is (after 10+ years of Sage). Personally, I see it as a low-level command, analogous to other low-level commands like ./sage -b and ./sage --docbuild. -i [packages] --

Re: [sage-devel] Should sage -i install *dependencies* of packages?

On 2015-08-17 19:12, kcrisman wrote: How many packages currently have such (additional) dependencies now as opposed to several years ago? Currently, the only packages which depend on a package which is not standard are: * python_igraph depending on igraph * qepcad depending on saclib By a st

Re: [sage-devel] Should sage -i install *dependencies* of packages?

On 2015-08-17 18:35, William Stein wrote: On Mon, Aug 17, 2015 at 10:00 AM, Jeroen Demeyer wrote: [...] What would you like? What does every other package manager do? I don't think that's relevant. The question is not whether or not it should be possible to install pac

[sage-devel] Should sage -i install *dependencies* of packages?

This question is because of discussion at #18859. The current behaviour of "sage -i PKG" is to install package PKG (if the latest version of that package is not already installed), without looking at the dependencies of PKG. Now what should the recommended user interface be for installing a

Re: [sage-devel] using cdef to avoid code duplication?

Two orthogonal comments: * Do not make a function/method "cdef" unless there is a specific reason, for example performance or a need of C calling convention. * In general I don't think that the "100% coverage rule" should be taken too literal. I think it's more important that code is well tes

Re: [sage-devel] Re: About the "default" hash function from sage.structure.element.__hash__

On 2015-08-12 19:14, Volker Braun wrote: "==" isn't used in any group theory textbook to my knowledge... Of course group-equality should be a method, all I'm saying is that naming it __eq__() really badly interacts with associative containers. To be clear, this isn't about comparing groups, bu

[sage-devel] ./configure && make for Sage

Hello, usually, autotools-based packages are built using ./configure make which for Sage this has historically been just "make". However, I think that Sage should move to the "./configure && make" model, for various reasons: 1) it is simply the "standard" way to do things. 2) arguments to ./

[sage-devel] git port blocked

On my machine, "git fetch" no longer works and the problem looks to be that the git port is firewalled: $ git fetch fatal: unable to connect to trac.sagemath.org: trac.sagemath.org[0: 128.208.160.253]: errno=Connection timed out $ strace git fetch [...] connect(34, {sa_family=AF_INET, sin_port

Re: [sage-devel] Re: package: bzip2-1.0.6.20140317 failed to build

On 2015-07-21 17:55, rshpe...@ualberta.ca wrote: make[3]: *** write jobserver: Bad file descriptor. Stop. This seems more like a problem with "make" itself. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and sto

Re: [sage-devel] Re: package: bzip2-1.0.6.20140317 failed to build

On 2015-07-17 23:10, Volker Braun wrote: I'm pretty sure you can't build Sage with clang. Actually, bootstrapping Sage with clang should work. To the original poster: your e-mail seems to consist of concatenated logs (?) and it's not so clear how to interpret them. Most importantly, what we n

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

On 2015-07-17 13:15, Julien Puydt wrote: I'm not sure I understand how it can be an extra burden The problem is not so much with additional packages, it's with additional packages which only exist for Sage. If there is an active upstream which would exist anyway without Sage, that's healthy.

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

What if mathematica(1) or mathematica('1+1') works on the old version but something more complicated does not work? -- 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 t

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

Sorry, I didn't phrase my question clearly enough, let me try again. I'm honestly really interested in the answer, both from Sébastien and from Nathann (and please do not change the question!) I don't really care myself about the mathematica interface. But it happens that mathematica 10.0 is i

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

On 2015-07-16 13:22, Nathann Cohen wrote: This points to the core problem: we simply have no way to guess whether people want to do that or not. We do not have to care. Doctests must pass, whatever the install is. If the local install is broken then we should have a way to detect it, and if we

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

On 2015-07-16 13:22, Nathann Cohen wrote: You know that nobody will ever run those things. If it's running "make ptestextlong" instead of "make ptestlong" maybe they will. It's not really more complicated. -- You received this message because you are subscribed to the Google Groups "sage-deve

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

On 2015-07-16 13:13, Nathann Cohen wrote: Well, perhaps we could fix the problems that the doctests report, so that Sage gets better? Of course we should fix the failures, but that's really not the point of this discussion. -- You received this message because you are subscribed to the Go

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

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 compromise proposal: * keep default optional package as they

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

On 2015-07-16 12:51, Sébastien Labbé wrote: I don't really care myself about the mathematica interface. But it happens that mathematica 10.0 is installed on my machine in my lab and that most of the people in my lab use mathematica rather than sage. They won't test the mathematica doctests in the

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

Hello Nathann, I do not agree with testing all external packages. The fact that I happen to have a magma/maple/whatever installation on my computer does not mean that I care about Sage doctest failures. Maybe I have a version of the external package which is not fully compatible with Sage but

Re: [sage-devel] Re: Algebraic numbers: the '?' could be more informative (e.g.: 1.4142?)

On 2015-07-13 21:55, Bill Hart wrote: The elements of QQbar are the solutions of algebraic equations. As you probably know, the solutions of algebraic equations of degree > 4 can, in general, not be expressed that nicely. This is slightly incorrect. The general quintic can be solved

Re: [sage-devel] Server Relocation

On 2015-07-12 03:40, R. Andrew Ohana wrote: In addition, boxen.math.washington.edu will finally be going offline, and due to lack of space won't be coming back (at least for now). Important question: what will happen with the data currently stored on boxen? W

[sage-devel] Patchbot server down

http://patchbot.sagemath.org/ gives me 503 Service Unavailable -- 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. To post to

Re: [sage-devel] Error installing package ppl-1.1

On 2015-07-11 04:32, Luis Mailhos wrote: While compiling SageMath 6.7 I got an error on ppl-1.1. I am using a VM running Mint 17.2 (Ubuntu 14.04 based). I wonder if it can be fixed, or better to try the newer source? Is the bug reproducible? I.e. what happens if you just try building again? Do

Re: [sage-devel] Build failure on Arch Linux: conway_polynomials fails to build

On 2015-07-10 11:11, Joshua Hunt wrote: Thank you very much for all your help, it's now installed and happily running! Thank you for your cooperation in reporting this bug and helping with it (I wish all bug reporters would be like you...) Jeroen. -- You received this message because you ar

Re: [sage-devel] Build failure on Arch Linux: conway_polynomials fails to build

On 2015-07-09 14:35, Joshua Hunt wrote: I put Antonio's patch in the place suggested by Volker, then ran "make clean; make build" and got the same build errors; You need to explicitly rebuild PARI: ./sage -i pari That should fix the problem. -- You received this message because you are subs

Re: [sage-devel] Build failure on Arch Linux: conway_polynomials fails to build

On 2015-07-09 08:10, Francois Bissey wrote: Wasn’t that one of the command added by the latest pari snapshot merged during 6.8.beta5? If the word "that" refers to "polsturm", then no: polsturm is a very old PARI function. Just for fun, I downloaded pari-2.0.1.alpha.tar.bz2 and it contains this

Re: [sage-devel] Build failure on Arch Linux: conway_polynomials fails to build

On 2015-07-08 23:18, Joshua Hunt wrote: I would like to see if the help is also broken within GP. For that, run ./sage --gp and then (at the GP prompt): ??polsturm Similarly to before: Good, as expected. Can you also send me the log file logs/pkgs/pari.log -- You received

Re: [sage-devel] Build failure on Arch Linux: conway_polynomials fails to build

This is again correct. I give up on the "make" issue, I cannot debug it from here... Now you first need to reinstall PARI (the "echo garbage" line broke it intentionally): run ./sage -f pari I would like to see if the help is also broken within GP. For that, run ./sage --gp and then (at th

Re: [sage-devel] Build failure on Arch Linux: conway_polynomials fails to build

On 2015-07-08 18:03, Joshua Hunt wrote: Hi, Perl is v5.22.0. Did you pass any funny flags to make (apart from -j4)? Nope, only -j4. Can you please try following and send me the output? echo garbage > local/share/pari/pari.desc ./sage -ba I get the following: That's good

Re: [sage-devel] Build failure on Arch Linux: conway_polynomials fails to build

This is also strange, make just continues after an error. Did you pass any funny flags to make (apart from -j4)? Can you please try following and send me the output? echo garbage > local/share/pari/pari.desc ./sage -ba On 2015-07-08 17:22, Joshua Hunt wrote: Makefile:29: recipe for target

Re: [sage-devel] Build failure on Arch Linux: conway_polynomials fails to build

This is probably a problem, which version of Perl do you have? On 2015-07-08 17:22, Joshua Hunt wrote: Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\\b{ <-- HERE (.)}/ at /home/joshua/build/sage-6.7/local/bin/gphelp line 383. -- You received t

Re: [sage-devel] Build failure on Arch Linux: conway_polynomials fails to build

Can you please submit the file logs/pkgs/sage-6.7.log -- 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. To post to this grou

<    7   8   9   10   11   12   13   14   15   16   >