Re: [sage-devel] sage -docbuild fails ? O_o

On 2016-02-08 13:31, Nathann Cohen wrote: Hello everybody, I installed a fresh Sage on a new computer, and I get a weird message when trying to build the doc: ~$ sage -docbuild reference/graphs html /home/ncohen/.Sage/local/bin/python: No module named interrupt; 'sage_setup.docbuild'

Re: [sage-devel] Re: interrupt.pyx on PyPi?

See https://github.com/malb/signal.pyx/issues/2 -- 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 group,

Re: [sage-devel] is_prime failing silently

On 2016-02-07 14:50, Travis Scrimshaw wrote: So then what do you think about the current behavior, where if there is no (implemented) is_prime(), we then try to convert to ZZ? We don't *try* to convert, we just convert. No problem with that. -- You received this message because you are

Re: [sage-devel] Re: Failure to Compile Sage 7.0 Stable on openSUSE Linux

On 2016-02-04 18:50, Martin Vahi wrote: The compilation of the Sage 7.0 was with LLVM, not GCC. Are you sure? The log file says C compiler: gcc C compiler version: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper Target:

Re: [sage-devel] is_prime failing silently

On 2016-02-06 00:07, Travis Scrimshaw wrote: try to coerce it to the base ring -1 These kind of conditionals only make things worse. Either you convert to the base ring or you don't convert to the base ring. But *trying* to convert is the most confusing thing you can do. Jeroen. -- You

Re: [sage-devel] Re: error rebuilding sage

On 2016-02-06 10:28, jhonrubia6 wrote: So, if I understand you correctly, say I have sage 7.0 on my machine and try to review some old ticket, do you recommend me to merge the ticket branch with my copy I don't know what you mean with "my copy". Anyway, merging with a more recent version of

Re: [sage-devel] Re: Output of Matrix.plot() depends on whether the Matrix is sparse of dense

On 2016-02-05 18:08, Nathann Cohen wrote: Yes, this is a more universal problem in the UI: I object. It is a *very* simple mistake that has a *very* simple solution: Any function that takes **kwargs as argument must: 1) Remove from kwargs all values it understands Or just not

Re: [sage-devel] Output of Matrix.plot() depends on whether the Matrix is sparse of dense

On 2016-02-05 15:43, Nathann Cohen wrote: sage: Matrix(whatever=58) [] I just created http://trac.sagemath.org/ticket/20015 for this -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving

Re: [sage-devel] Re: Relocating sage

On 2016-02-05 09:08, Dima Pasechnik wrote: By the way, I do not see why the present binary patchning procedure cannot get an undo mode. It's not technically impossible, just more work to implement I guess. -- You received this message because you are subscribed to the Google Groups

Re: [sage-devel] is_prime failing silently

On 2016-02-05 19:59, William Stein wrote: Maybe is_prime for field elements should just raise an exception? This reminds me very much about the recent discussion we had about floor division... and which didn't really come to a conclusion. It's really the same problem: you have something

Re: [sage-devel] is_prime failing silently

On 2016-02-05 20:45, Vincent Delecroix wrote: About the code, the current version is {{{ def is_prime(n): try: return n.is_prime() except (AttributeError, NotImplementedError): return ZZ(n).is_prime() }}} I think that we should change it to {{{ from

Re: [sage-devel] Getting reminders for tickets in needs_work

On 2016-02-05 10:49, Nathann Cohen wrote: I'll just add this thing on the heap on which I store the ideas you oppose by requesting things I cannot do, with the "Testing CPLEX/Maple/Matlab" and "spkg-src" tickets. What did I request that you cannot do regarding "spkg-src"? I am still in favour

Re: [sage-devel] Re: error rebuilding sage

On 2016-02-04 22:00, jhonrubia6 wrote: How do I know the version of a given ticket which needs review? Checkout the branch and run "cat VERSION.txt" -- 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] Getting reminders for tickets in needs_work

On 2016-02-05 10:26, Nathann Cohen wrote: There many useful trac reports which can be used instead of this, for example http://trac.sagemath.org/report/57 is what you want I guess. This only works if everybody checks that page regularly, which is not the case. Hell, even getting a message if a

Re: [sage-devel] Getting reminders for tickets in needs_work

On 2016-02-05 10:10, Nathann Cohen wrote: I was just wondering if this situation was worth getting some script running (I can give it a try): every week or so it would run, and if a ticket has been in needs_work for more than a month with no comment on it, the script would add a message on the

Re: [sage-devel] Re: hardcoded paths [Was: [sage-support] after a long compiling time i got this]

On 2016-02-04 13:02, Jan Groenewald wrote: Does it matter for the PPA? Isn't that installed in a fixed location anyway? Yes, changes to this it is what broke the PPA since 6.9. Sorry, I didn't understand to what you answered "yes". Is the PPA installed in a fixed location? If so,

Re: [sage-devel] Re: hardcoded paths [Was: [sage-support] after a long compiling time i got this]

On 2016-02-04 13:02, Jan Groenewald wrote: Is it difficult because of legacy code? No, it's difficult because Sage is like a distribution. Relocating Sage is like relocating /usr to /otherpath/usr in your favorite Linux distro. I bet things will break down completely. Jeroen. -- You

Re: [sage-devel] Relocating sage

On 2016-02-05 00:24, John H Palmieri wrote: Should the model when building from scratch be ./configure --prefix=/target/location make make install One thing which we could try is to make it such that ./configure --prefix=/target/location make installs in /target/location. Like Volker said,

Re: [sage-devel] Re: Relocating sage

On 2016-02-05 01:44, John H Palmieri wrote: run the relocation script. There is no such thing anymore. Sage can no longer be relocated. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails

Re: [sage-devel] Re: hardcoded paths [Was: [sage-support] after a long compiling time i got this]

On 2016-02-04 15:09, Jan Groenewald wrote: But can I say most binaries should not have hard-coded paths patched just after compilation? You are right, but only because "most binaries" are compiled with the correct path in the first place. You have that option with Sage: if you compile

Re: [sage-devel] Re: hardcoded paths [Was: [sage-support] after a long compiling time i got this]

On 2016-02-04 13:58, Jan Groenewald wrote: I thought it would be more like moving / since it was completely self-contained. It doesn't matter: I'm sure that moving / will break everything too. I also agree with Volker that most software is *not* meant to be relocatable. I wonder why you think

Re: [sage-devel] Re: error rebuilding sage

On 2016-02-04 19:32, jhonrubia6 wrote: I passed that point and now fails building ecm,... I do not understand what I am making wrong. I had a working installation on 7.0, then after checking out a ticket to review (#18408)I tried to build again and I'm having a lot of problems to get the

Re: [sage-devel] interrupt.pyx on PyPi?

One more thing: I think that this "interrupt" project would really benefit from autoconf. I know that Python + autoconf is not a common combination, but there are some non-trivial system-specific things which are best handled by autoconf. Moreover, I have always wanted to add support for

Re: [sage-devel] interrupt.pyx on PyPi?

On 2016-02-02 09:51, Volker Braun wrote: The system-specific part could be a separate C library "libinterrupt" that the python package depends on. That is how many other Python packages depend on system-specific libraries... That just adds an extra step, I don't see why this is a good idea. I

Re: [sage-devel] interrupt.pyx on PyPi?

On 2016-02-02 10:16, 'Martin R. Albrecht' via sage-devel wrote: I guess this ends my plan to just pip install -r requirements.txt I'm not sure it does. I have no idea what pip install $FOO actually does. If it just runs setup.py, we can still run ./configure from setup.py.

Re: [sage-devel] interrupt.pyx on PyPi?

On 2016-02-02 11:04, Jean-Pierre Flori wrote: "cygnals"? Sounds too much like Cygwin. -- 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

Re: [sage-devel] interrupt.pyx on PyPi?

On 2016-02-02 11:16, Volker Braun wrote: * makes it easier for distros, e.g. passing custom arguments to ./configure Why is it easier to pass custom arguments to ./configure if there are 2 packages instead of 1 package? * easier and faster venv installations if you don't have to recompile

Re: [sage-devel] interrupt.pyx on PyPi?

On 2016-02-02 11:33, 'Martin R. Albrecht' via sage-devel wrote: Hi Jeroen, my concern is mainly of convention: I don’t think people expect pip to install shared libraries. I am not convinced that this "cysignals" package should contain a shared library. In Sage, it's a Python module(*), not

Re: [sage-devel] Re: interrupt.pyx on PyPi?

On 2016-02-02 11:12, Volker Braun wrote: Right now all tests for interrupts use "sage:" markers and customized magic comments. So its not easy to run the existing doctests under $favorite_testing_framework. At least for the interrupt tests, this shouldn't be a big issue. For other parts of

Re: [sage-devel] interrupt.pyx on PyPi?

On 2016-02-02 12:00, Volker Braun wrote: One might want to use it without Cython, e.g. plain CPython or boost::python Well, the Cython and C parts are quite intertwined, so I do not intend to support anything but Cython. -- You received this message because you are subscribed to the Google

Re: [sage-devel] interrupt.pyx on PyPi?

On 2016-02-01 10:40, 'Martin R. Albrecht' via sage-devel wrote: In particular, I am *very* interested in turning Sage’s interrupt handling into something that can be easily installed from PyPI. For those who don’t know what Sage’s interrupt handling does: it allows that you can press Ctrl-C to

Re: [sage-devel] Fwd: Re: genus2reduction

version of PARI and of Sage did you use, and what is the bug? Best regards, Jeroen Demeyer. -- 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

[sage-devel] Forking/patching of upstream projects

Hello sage-devel, There are various degrees of patching upstream projects for Sage: (0) vanilla upstream stable release (1) upstream stable release with patches accepted by upstream (2) upstream development code (e.g. git master) (3) upstream code with patches not accepted by upstream (4) fork

Re: [sage-devel] Re: Forking/patching of upstream projects

On 2016-01-27 17:52, Dima Pasechnik wrote: For the record, I never proposed to create a fork of either of them in the 1st place. True, you didn't propose anything. You just did it. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe

Re: [sage-devel] Re: Forking/patching of upstream projects

On 2016-01-27 17:52, Dima Pasechnik wrote: I really do not understand why a complicated, buggy, hard to maintain, fix, or even read patches and scripts (e.g. https://github.com/sagemath/sage/blob/master/build/pkgs/cliquer/spkg-install and its role in Sage 7.0 OSX binaries facepalm) should be

Re: [sage-devel] Re: Forking/patching of upstream projects

On 2016-01-27 19:46, Dima Pasechnik wrote: Since when creating a public git repo of something is called forking? It is forking if the only way to obtain the tarball is using some obscure git repo that you created. -- You received this message because you are subscribed to the Google Groups

Re: [sage-devel] Re: Forking/patching of upstream projects

On 2016-01-27 20:03, Dima Pasechnik wrote: The exciting alternative approach proposed by Jeroen is patching makefiles, and possibly other parts of upstream, by hand. Again false dichotomy... -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To

Re: [sage-devel] Re: Forking/patching of upstream projects

On 2016-01-27 20:27, Volker Braun wrote: Imho if upstream hasn't made any changes in the last 5 years and/or can't be bothered with the added value of building a shared library then its better to fork. I agree! However, note the very important condition "can't be bothered with the added

Re: [sage-devel] Re: Forking/patching of upstream projects

On 2016-01-27 19:42, Dima Pasechnik wrote: Note that planarity already had a ./configure && make install support. This autoconf build system his was added by Nathann Cohen and accepted by upstream. -- You received this message because you are subscribed to the Google Groups "sage-devel"

Re: [sage-devel] Conversion Jupyter Notebook -> Doctests

On 2016-01-27 07:22, Clemens Heuberger wrote: - diffs between various versions would be much easier than diffing the .ipynb file. I know that "diffability" of ipynb files is on upstream's TODO list. -- You received this message because you are subscribed to the Google Groups "sage-devel"

Re: [sage-devel] Random doctest error in real_double.pyx

On 2016-01-25 14:28, Eric Gourgoulhon wrote: Should this doctest be skipped by adding the marker # random to it? Even better: remove the whole time_alloc() function with its doctests. It's not clear what those doctests test anyway... -- You received this message because you are subscribed

Re: [sage-devel] Developing in general

On 2016-01-25 14:47, Jori Mäntysalo wrote: But numbers 2-1 does not seem so strong base for decision. Sure, but that is because it is such a specific question about Posets. You cannot expect every Sage developer to have an opinion about Posets. I never used Posets in Sage, so I don't have an

Re: [sage-devel] Developing in general

On 2016-01-25 13:26, Jori Mäntysalo wrote: But what if -- a slightly artificial example -- I make function A that uses Poset as a wrapper, function B that does not, then Nathann reviews A and Travis reviews B...? In such a case you should try to agree with everybody which of the two

Re: [sage-devel] Plots in plot.py documentation

I'm sure there is probably a good reason, but why don't we just display all plots in the documentation? -- 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

Re: [sage-devel] Developing in general

I actually think that it's a very good thing if reviewers point out flaws and give constructive suggestions. I wish all my tickets had that... Jeroen. -- 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] Merging sage-7.0 into existing branch

On 2016-01-23 22:34, David Roe wrote: python -u setup.py install Traceback (most recent call last): File "setup.py", line 47, in from module_list import ext_modules, library_order, aliases File

Re: [sage-devel] The sage.rings.finite_rings.constructor module

On 2016-01-22 11:41, Nathann Cohen wrote: Do you see have any objection to setting things right? Of course not, but we need to deprecate the old modules. -- 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] Do we really need Element, RingElement, AdditiveGroupElement, ...?

A related question now that I'm thinking about refactoring: can we drop the in-place methods like __iadd__? May we assume that no Element will need in-place methods with coercion? The problem is when classes want to implement a special __add__ without coercion (that is legitimate). If those

Re: [sage-devel] The sage.rings.finite_rings.constructor module

On 2016-01-22 11:13, Nathann Cohen wrote: Hello everybody, The title of the following module is 'Finite Fields'. Its contains code related to finite fields. sage/rings/finite_rings/constructor.py Is it just me, or is there a noticeable discrepancy between the filename and the

Re: [sage-devel] vote for making nauty a standard package (Re: About license of nauty and poset generator)

On 2016-01-21 00:29, Dima Pasechnik wrote: Surely, if the official nauty got another licence it would have solved the problem easier. Maybe you could ask McKay if he is willing to license *every* version of nauty (past and future) with a GPL-compatible license? If we are only allowed to ship

Re: [sage-devel] Should a // b really be the same as a / b in fields?

On 2016-01-20 15:49, William Stein wrote: All that said, without history in the way, making floordiv agree with float floor div would be nice. For the record, this is #15260. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from

Re: [sage-devel] Bug: rational point on a conic triggers a segfault

Reported upstream: http://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=1778 -- 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

Re: [sage-devel] vote for making nauty a standard package (Re: About license of nauty and poset generator)

On 2016-01-20 22:12, Dima Pasechnik wrote: Here is a ticket with the new nauty release, and a proposal to make it a standard package. http://trac.sagemath.org/ticket/19919 Please vote (it is already an optional package for long time, I think), and there are no more formal copyright reasons

Re: [sage-devel] Bug: rational point on a conic triggers a segfault

Fixed in PARI master (not in Sage yet). -- 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 group, send email

Re: [sage-devel] Should a // b really be the same as a / b in fields?

On 2016-01-19 22:50, Volker Braun wrote: Presumably nobody has a problem with sage: R. = QQ[] sage: (3*x^2+1) // (2*x) 3/2*x and it would be rather strange if the binary operations on the scalars behave different in QQ vs degree-0-part(QQ[x]). Well, you cannot have a fully consistent floor

Re: [sage-devel] Should a // b really be the same as a / b in fields?

On 2016-01-20 11:17, Volker Braun wrote: On Wednesday, January 20, 2016 at 8:28:23 AM UTC, Jeroen Demeyer wrote: Well, you cannot have a fully consistent floor division in any case: Either you make floor division on QQ consistent with ZZ or with QQ[x] but you cannot have both

Re: [sage-devel] Should a // b really be the same as a / b in fields?

On 2016-01-20 12:32, Volker Braun wrote: Of course you can define as ZZ-floor division as the above operation in QQ, but thats doesn't generalize to other rings. True, this doesn't work in full mathematical generality. But that's not a good reason to just throw everything away. Many useful

[sage-devel] Should a // b really be the same as a / b in fields?

Feature or bug? sage: QQ(7) // QQ(2) 7/2 I would expect sage: QQ(7) // QQ(2) 3 -- 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

Re: [sage-devel] Should a // b really be the same as a / b in fields?

On 2016-01-19 13:31, John Cremona wrote: This would only make sense if ZZ was the only ring of which QQ was the field of fractions. Similarly with rational function fields, in my opinion. Well, you are thinking too mathematical. Of course, defining a//b = a/b makes any field into a Euclidean

Re: [sage-devel] Should a // b really be the same as a / b in fields?

On 2016-01-19 12:49, Vincent Delecroix wrote: 1. Should we always have a == a//b + a%b I guess you mean a == (a//b)*b + a%b Buy yes, this invariant is very important and should always be satisfied. -- You received this message because you are subscribed to the Google Groups

Re: [sage-devel] Sage GSOC 2016

For GSoC, we should really insist that the coders try to get their code on trac from the start. In particular, they should follow the "one ticket, one issue" rule and not just dump everything on one ticket. I have seen some GSoC projects where one person codes for the summer, puts the code on

Re: [sage-devel] sagemath developer manual

On 2016-01-18 09:19, Samuel Lelièvre wrote: http://www.sagemath.org/git-developer-guide/trac.html This looks like an oudated version of the real developer guide. Not sure what it's doing there. -- You received this message because you are subscribed to the Google Groups "sage-devel"

Re: [sage-devel] Error testing package cython-0.23-3

On 2016-01-16 21:47, Buck Evan wrote: It passed on subsequent `make`. Then it might be a hardware problem. I suggest you run memtest on your system to check for that. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this

Re: [sage-devel] incremental migration to github?

On 2016-01-16 14:29, Ralf Stephan wrote: https://gist.github.com/piscisaureus/3342247 Sorry, but something which involves manually editing config files is not "easily checkout a pull request". But at least it works. -- You received this message because you are subscribed to the Google

Re: [sage-devel] incremental migration to github?

On 2016-01-16 08:15, Ralf Stephan wrote: Another useful thing is that everything on trac is in one git tree. I can do "git fetch" and have all tickets ready to check out without any hassle. I don't know if you can easily checkout a pull request from github. Of course you can.

Re: [sage-devel] incremental migration to github?

On 2016-01-16 08:15, Ralf Stephan wrote: On the other hand you can unsubscribe from each of these branches of conversation. Also, since a new code branch is a separate pull request the old branch stays visible until it's explicitly closed. It's up to you to add # links if you want. Moreover,

Re: [sage-devel] Error testing package cython-0.23-3

On 2016-01-16 20:15, Buck Evan wrote: The cause seems to be gcc segfaulting during tests of cython compilation. A broken GCC? Let me guess... Debian? You can rebuild Sage with the environment variable SAGE_INSTALL_GCC=yes That will install a properly working GCC. -- You received this message

Re: [sage-devel] incremental migration to github?

On 2016-01-15 16:00, William Stein wrote: Why Python moved to github: http://www.snarky.ca/the-history-behind-the-decision-to-move-python-to-github It seems to boil down to "we use GitHub because everybody

Re: [sage-devel] Error building branch from git clone

On 2016-01-14 21:18, Anna Haensch wrote: So, per the instructions on the Sage Developer's Guide I ran: sage$ ./sage -br Are you referring to the paragraph Once you have made any changes you of course want to build Sage and try out your edits. As long as you only modified the Sage library

Re: [sage-devel] error modifying branch in trac (ticket#19856)

It would help a lot if you stated the *exact* command that you executed and the *exact* output that you got. On 2016-01-14 21:23, jhonrubia6 wrote: I just made the error of committing changes on my local branch t/19856/new_plot_function_hyperbolic_regular_polygon__ before updating the branch

Re: [sage-devel] Missing file in src/build/cythonized/sage/structure/list_clone.c

On 2016-01-12 15:30, Jan Groenewald wrote: Hi The sagemath-upstream-binary in the PPA which excludes most of the src folder, gives this error on startup: Are you sure that you're not accidentally running the script twice? -- You received this message because you are subscribed to the Google

Re: [sage-devel] incremental migration to github?

On 2016-01-11 17:26, William Stein wrote: Hi, For what it is worth I'm highly supportive of Sage development moving to github. I like trac (especially the way Sage uses it) a lot better than github. What I mostly dislike about github is that "issues" and "pull requests" are different

Re: [sage-devel] cython string problem

On 2016-01-10 18:26, Daniel Krenn wrote: This shows that the problem is += in s += self.separator.join(E) Are you sure? I already get a problem here: /usr/local/src/sage-config/src/sage/data_structures/lazy_list.pyx in sage.data_structures.lazy_list.lazy_list_abstract.__repr__

Re: [sage-devel] Re: A Sage function with a good deal of GAP native code

On 2016-01-09 10:39, Jori Mäntysalo wrote: On Wed, 6 Jan 2016, David Joyner wrote: Just to be clear what the disagreement is, as far as I can tell, this is not simply a call to GAP but a call to a GAP package "Grape" which is not part of Sage's standard installation of GAP. How it is then

Re: [sage-devel] Re: Jupyter notebook by default?

On 2016-01-06 10:05, Volker Braun wrote: And certainly nobody wants a piece of their output discarded in a long-running computation. +1. Actually throwing away output is the worst solution. The full output should still be available somehow. -- You received this message because you are

Re: [sage-devel] Re: Jupyter notebook by default?

On 2016-01-05 19:27, Jason Grout wrote: FYI, Sylvain Corlay is making some changes to ipywidgets to bring them more into line with the Sage syntax. He said in the Jupyter dev meeting just now that he'll be making a PR today. Cool, however it seems from

Re: [sage-devel] Sage & pip

On 2016-01-05 14:02, John Cremona wrote: ImportError: No module named 'pip._vendor.requests' See https://github.com/pypa/pip/issues/2345 I would try ./sage -f openssl python2 Let us know if that helped. -- You received this message because you are subscribed to the Google Groups

Re: [sage-devel] Re: Jupyter notebook by default?

On 2016-01-03 14:41, Emmanuel Charpentier wrote: * Interacts : In a Python worksheet, ipywidgets offers a nice interactive framework, ... which turns out no be non obvious to use from a Sage worksheet. A replacement and/or a compatibility layer are needed. (Even if we offer a

Re: [sage-devel] Re: Jupyter notebook by default?

On 2016-01-03 17:36, Emmanuel Charpentier wrote: how to define the function in the global namespace as in the command line or Sage notebook... The relevant compile_and_load() function returns a module (from which one can of course import *, which would mimic the current Sage notebook behavior) ;

Re: [sage-devel] 32 bits packages

On 2015-12-31 10:57, Jori Mäntysalo wrote: Isn't it an indicator of bad code quality if the software works in 32-bit but not in 64-bit or vice versa? Of course it is. So I think it's a valid reason to move those packages to "experimental". -- You received this message because you are

Re: [sage-devel] error building sage

On 2015-12-25 20:37, jhonrubia6 wrote: Could somebody give me a clue on this? You need to actually build Sage first, i.e. run "make". -- 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

[sage-devel] Bliss is gone

Where did bliss go? $ ./sage -i bliss Attempting to download package bliss-0.73.zip from mirrors [...] Traceback (most recent call last): File "/usr/local/src/sage-git/build/bin/../sage_bootstrap/cmdline.py", line 228,

Re: [sage-devel] modulo operators (integers, rationals, real numbers)

On 2015-12-22 09:59, Jori Mäntysalo wrote: Other option would be to remove it for non-integer arguments. -1 Modulo can be useful for floating-point numbers and it makes sense mathematically. -- You received this message because you are subscribed to the Google Groups "sage-devel" group.

Re: [sage-devel] Re: Jupyter notebook by default?

On 2015-12-21 09:40, Volker Braun wrote: Interacts DO work. Its just Jupyter interacts and not SageNB interacts. I think that the SageNB @interact API is much better designed and more consistent than the Jupyter @interact API. Unfortunately, I am not able to convince upstream Jupyter (really:

Re: [sage-devel] Re: Inverting Integers gives different behaviour than in Python

On 2015-12-21 17:53, Volker Braun wrote: In any case, if you are serious about binary operations then the next question is going to be: why is ^ not bitwise xor like for Python ints. That's actually a different question since it involves the preparser. In Sage, the ^ operator is calling

[sage-devel] Jupyter notebook by default?

Should the Jupyter notebook be the default notebook for the next Sage 7.0 release? I don't really have an opinion on the matter. Pros: * Nice tracebacks! * The Jupyter notebook is a mature well-maintained project, unlike SageNB. It is widely used in the "scientific Python" community. *

Re: [sage-devel] Re: Sage-7.0 ?

On 2015-12-18 07:05, Andrey Novoseltsev wrote: We also hope to upgrade pexpect and do some nice changes in SageNB, although 7.0 is probably a great version to consider switching default notebook to IPython/Jupiter. (But please keep shipping SageNB forever!) There are some things which don't

Re: [sage-devel] BUG: segfault in 6.10.beta7

I added this to http://trac.sagemath.org/ticket/18639 -- 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

Re: [sage-devel] Re: make distclean fails

There is still this: On 2015-12-07 20:55, David Coudert wrote: configure: error: "found MacPorts in /opt/local/bin/port. Either: (1) rename /opt/local and /sw, or (2) change PATH and DYLD_LIBRARY_PATH (Once Sage is built, you can restore them.) -- You received this message because you are

Re: [sage-devel] Re: make distclean fails

On 2015-12-07 19:33, David Coudert wrote: Unfortunately the problem remains. Which problem? Log please. -- 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

Re: [sage-devel] Using pyximport with Sage

On 2015-12-03 23:39, Jean-Pierre Flori wrote: So my questions are: * why does Cython complains whereas it was able to find the pxd file (just next to the pxi file)? Because .pxd files are more like Python modules (except cimported instead of imported). They are found in sys.path for example.

Re: [sage-devel] make ptestlong doesn't run the test when there are docbuild errors

On 2015-12-02 11:40, Sébastien Labbé wrote: Would it be possible that make ptestlong run the tests even if the documentation fails to build because of "spurious" errors? The fact that "make ptestlong" builds the documentation is a *feature*, not a bug. You will get doctest errors if the

Re: [sage-devel] Re: install_package('whatever')

On 2015-11-27 09:06, Jori Mäntysalo wrote: And server_pool makes it impossible to have %cython cells. As a workaround, doing cython(""" # Cython code here """) does work. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from

Re: [sage-devel] Re: install_package('whatever')

On 2015-11-27 11:16, Jori Mäntysalo wrote: On Fri, 27 Nov 2015, Jeroen Demeyer wrote: And server_pool makes it impossible to have %cython cells. As a workaround, doing cython(""" # Cython code here """) does work. Great! Somebody please document this. Or

Re: [sage-devel] Re: install_package('whatever')

On 2015-11-27 09:06, Jori Mäntysalo wrote: And server_pool makes it impossible to have %cython cells. By the way, this is https://github.com/sagemath/sagenb/issues/260 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this

Re: [sage-devel] Re: Do we really need Element, RingElement, AdditiveGroupElement, ...?

On 2015-11-26 11:08, Simon King wrote: Hi Travis, On 2015-11-23, Travis Scrimshaw wrote: However, I'm +1 for flatting things down to Element as it would probably solve #15160 and #15947 . See

Re: [sage-devel] poseidon patchbot and cbc

On 2015-11-26 12:41, Nathann Cohen wrote: Could the owner stop the patchbot and try to investigate if there is something wrong? Any lights from people with graphs/cbc knowledge would be useful as well. At first sight I have no idea of what's going wrong, though Jeroen has been patching the

Re: [sage-devel] poseidon patchbot and cbc

On 2015-11-26 13:42, Vincent Delecroix wrote: Harder: could you fix all of them with another ticket? Now I fixed #19622, so I just need the broken patchbots to test #19622 again. Is there a way to force a particular patchbot to test a particular ticket? -- You received this message because

Re: [sage-devel] Re: install_package('whatever')

On 2015-11-25 06:22, Jori Mäntysalo wrote: Code that needs some package should raise an error if the package is not installed. And the interface should catch it and give consistent and friendly error message. Either "Do this" or "Ask you system administrator". Do you have an example where this

Re: [sage-devel] install_package('whatever')

On 2015-11-24 19:22, Nathann Cohen wrote: Is there a technical reason why "install_package" cannot work anymore? Yes, installing Sage packages within a Sage shell (let alone within a running Sage session) is not supported. It may or may not work. Since we cannot guarantee that it can work,

<    5   6   7   8   9   10   11   12   13   14   >