talk

[William Stein]

Hi,

I just wrote a short talk that I'm about to give at ICMS 2018 about a
sort of Sage status report and wishlist:

https://goo.gl/qNycb3

--
William (http://wstein.org)

[Timo Kaufmann]

I really like your wishlist! The all-or-nothing nature of sage and the slow startup time (although it's actually more like 1.3 seconds with a warm cache on my machine) are my biggest pain points.

I'm not sure if its a good idea to separate user and developer error messages. I'm also not convinced that machine learning would be of great help here, but who knows!

[William Stein]

On Tue, Jul 24, 2018 at 5:49 PM, Timo Kaufmann <eisf...@gmail.com> wrote:
> I really like your wishlist! The all-or-nothing nature of sage and the slow
> startup time
> (although it's actually more like 1.3 seconds with a warm cache
> on my machine)

Precisely how are you benchmarking this, and what is your machine?
Can you copy/paste a session?

> I'm not sure if its a good idea to separate user and developer error
> messages.

I think it might be, because most end users of Sage have very, very
different expectations, backgrounds, etc., than Sage developers.
Developers are
often intimately familiar with Python, Cython, and the Sage library.
Instructors who I've talked to who teach undergrads and who don't
give up on Sage typically create their own local "dictionaries" to
help their students figure out what the cryptic Sage error messages
actually mean. I've seen this repeatedly, and it's often done in a
context sensitive way.

Improving presentation of errors messages (especially the Sage
preparser related mangling) is probably one of the more accessible
projects. Maybe somebody will do it as a GSoC in 2019...

> I'm also not convinced that machine learning would be of great
> help here, but who knows!

It is only potentially useful if you have a large sample of actual
errors in the wild... Stackoverflow can be useful for that for some
software (not Sage).

--
William (http://wstein.org)

[John H Palmieri]

On Tuesday, July 24, 2018 at 4:32:38 PM UTC-7, William wrote:

On Tue, Jul 24, 2018 at 5:49 PM, Timo Kaufmann <eisf...@gmail.com> wrote:
> I really like your wishlist! The all-or-nothing nature of sage and the slow
> startup time
> (although it's actually more like 1.3 seconds with a warm cache
> on my machine)

Precisely how are you benchmarking this, and what is your machine?
Can you copy/paste a session?

You weren't asking me, but: cold, "sage --startuptime" gives me

    Total time (sum over exclusive time): 28884.693ms

Then rerunning it gives

    Total time (sum over exclusive time): 1019.819ms

Or if you don't like 'sage --startuptime':

$ time ./sage -c 'print("hello")'
hello

real    0m1.210s
user    0m0.849s
sys    0m0.279s

This is on a 2017 iMac, 4.2 GHz Intel i7, 32 GB, "fusion" drive.

--

John

[Kwankyu Lee]

Charming slides! I could sympathize with most of your wishlist.

Many thanks that you started Sage project, around the time when I wished something like Sage!

[jplab]

Hi,

It is great to have a recent snapshot of the status of Sage and a wishlist!

This summer marks the 10th year when my brother showed me Sage for 

the first time at the beginning of my master (So happy I did not need to 

use Maple or Matematica any more...). It is awesome to see it so 

lively and to be able to participate in improving it!

On the number of contribution graph, it seems that the number increased 

since the move to git in around 2014? Is that accurate?

About moving trac to github, I have been aware of gitlab, an "open-core" 

competitor of gitlab. My institution uses it instead of github as its platform 

for internal collaborations. As I am not an expert in this respect, but I find 

it interesting to consider, as you mention that your computer was 100% 

open source apart from Magma. Here's a letter from the CEO of gitlab, 

from 2 years ago last week:

https://about.gitlab.com/2016/07/20/gitlab-is-open-core-github-is-closed-source/

which ends by:

"In conclusion (TLDR), GitLab has an open core business model and ships 

both open and closed source software. GitHub hosts most open source 

projects but ships closed source software."

For what it's worth, I thought I would mention it here...

JP

[Erik Bray]

On Tue, Jul 24, 2018 at 9:18 PM William Stein <wst...@gmail.com> wrote:
>
> Hi,
>
> I just wrote a short talk that I'm about to give at ICMS 2018 about a
> sort of Sage status report and wishlist:
>
> https://goo.gl/qNycb3

William--I think you do a fine job proving the point of my post on
sage-flame by linking to the thread while simultaneously
misrepresenting / misunderstanding my point. Perhaps I was unclear
and "ponderous" (a perfectly fair assessment!) but where did I write
that I dislike the model of voting on topics? All I was saying was
that if you're going to respond to a disagreement or open question
with a vote it should at least fairly and accurately represent the
question being voted on.

I would just that you also fairly and accurately represent my point,
perhaps by removing that bullet point or at least rewording it.

Thanks,
E

[William Stein]

On Wed, Jul 25, 2018 at 7:54 AM, Erik Bray <erik....@gmail.com> wrote:
> On Tue, Jul 24, 2018 at 9:18 PM William Stein <wst...@gmail.com> wrote:
>>
>> Hi,
>>
>> I just wrote a short talk that I'm about to give at ICMS 2018 about a
>> sort of Sage status report and wishlist:
>>
>> https://goo.gl/qNycb3

[...]

> I would just that you also fairly and accurately represent my point,
> perhaps by removing that bullet point or at least rewording it.

I have removed the bullet point linking to your sage-flame post.

-- William

[Erik Bray]

On Wed, Jul 25, 2018 at 8:03 AM jplab <jeanphil...@gmail.com> wrote:
>
> Hi,
>
> It is great to have a recent snapshot of the status of Sage and a wishlist!
>
> This summer marks the 10th year when my brother showed me Sage for
> the first time at the beginning of my master (So happy I did not need to
> use Maple or Matematica any more...). It is awesome to see it so
> lively and to be able to participate in improving it!
>
> On the number of contribution graph, it seems that the number increased
> since the move to git in around 2014? Is that accurate?
>
> About moving trac to github, I have been aware of gitlab, an "open-core"
> competitor of gitlab. My institution uses it instead of github as its platform
> for internal collaborations. As I am not an expert in this respect, but I find
> it interesting to consider, as you mention that your computer was 100%
> open source apart from Magma. Here's a letter from the CEO of gitlab,
> from 2 years ago last week:
>
> https://about.gitlab.com/2016/07/20/gitlab-is-open-core-github-is-closed-source/
>
> which ends by:
>
> "In conclusion (TLDR), GitLab has an open core business model and ships
> both open and closed source software. GitHub hosts most open source
> projects but ships closed source software."
>
> For what it's worth, I thought I would mention it here...

We've been keeping quiet about it because we want things to be working
before we start a big discussion / flame war about it but Julian Rüth
and I have already been making some inroads towards enhancing Sage
development on GitLab (as opposed to GitHub), which we chose in part
*because* we believe it to be more politically palatable to the Sage
community (this was even before the Microsoft buyout news), as well as
the ability to go self-hosted if needed, as well as the nice built-in
continuous integration capabilities.

I discussed this a bit in a recent ticket:

https://trac.sagemath.org/ticket/25914

See also Julian's herculean effort in:

https://trac.sagemath.org/ticket/24655

Also, FWIW I should be clear, I personally do *not* want to kill of
Sage's Trac any time soon. But I do think there are benefits to
accepting contributions through GitLab including but not limited to:

1) More accessible, especially to newcomers, who don't have to learn a
new tool / workflow (even if they have not used GitLab before, it's
reasonably familiar to anyone who's used GitHub, and allows logging in
with their existing GitHub credentials).
2) Just hands-down better code review UX.

and eventually,

3) A better continuous integration experience too--the sage patchbot
is quite nice, but it will be even nicer to have a *consistent* manner
of feedback for changes, whereas sage's informal patchbot fleet is
notoriously unreliable. (The buildbot fleet, on the other hand,
still has great value in providing slower CI on a wider range of
platforms).

In order to allow Trac and GitLab to be used simultaneously I've even
been working on integration between the two through their respective
APIs through Sage's Trac plugin. See e.g.:

https://github.com/sagemath/sage_trac_plugin/commit/69aee69c6ac8b0ae67ac483a5085e3e71145bb1c


All this is to say, this is one bullet point in William's slides that
is being worked on. I believe some others are being worked on too, as
able, but progress is slow. I agree with all the main bullet points
(other than the one minor one I pointed out ;)

[William Stein]

+1 from me for GitLab; it has most of the same important advantages
over trac for us.

> All this is to say, this is one bullet point in William's slides that
> is being worked on. I believe some others are being worked on too, as
> able, but progress is slow. I agree with all the main bullet points
> (other than the one minor one I pointed out ;)

Thanks so much for working on this!

--
William (http://wstein.org)

[Timo Kaufmann]

Am Mittwoch, 25. Juli 2018 01:32:38 UTC+2 schrieb William:

On Tue, Jul 24, 2018 at 5:49 PM, Timo Kaufmann <eisf...@gmail.com> wrote:
> I really like your wishlist! The all-or-nothing nature of sage and the slow
> startup time
> (although it's actually more like 1.3 seconds with a warm cache
> on my machine)

Precisely how are you benchmarking this, and what is your machine?
Can you copy/paste a session?

 

I haven't done any real benchmarking, just a simple `time sage -c 'quit'`. That takes ~4s on the first run and ~1.3 secs on subsequent runs. My machine is pretty unsectacular: old SSD, old Intel i5 3.2GHz quad.

> I'm not sure if its a good idea to separate user and developer error
> messages.

I think it might be, because most end users of Sage have very, very
different expectations, backgrounds, etc., than Sage developers.
Developers are
often intimately familiar with Python, Cython, and the Sage library.
 Instructors who I've talked to who teach undergrads  and who don't
give up on Sage typically create their own local "dictionaries" to
help their students figure out what the  cryptic Sage error messages
actually mean.  I've seen this repeatedly, and it's often done in a
context sensitive way.

Improving presentation of errors messages (especially the Sage
preparser related mangling) is probably one of the more accessible
projects.  Maybe somebody will do it as a GSoC in 2019...

I agree that error messages should be improved. However I think it would be better to improve existing error messages, including information that is useful to users *and* developers.

[Nathan Dunfield]

On Tuesday, July 24, 2018 at 4:49:45 PM UTC-5, Timo Kaufmann wrote:

I really like your wishlist! The all-or-nothing nature of sage and the slow startup time (although it's actually more like 1.3 seconds with a warm cache on my machine) are my biggest pain points. 

I've encountered incredibly slow Sage startup times on big clusters due to, I believe, the very slow nature of their distributed file systems and the huge number of files Sage opens at startup.  This was several years ago, but at the time Sage took several *minutes* to start on the main campus cluster here at UIUC.  I ended up using a smaller cluster for my computations where the startup time was "just" 20 seconds.  (I was running things from my home directory rather that trying to convince the admins to install Sage on each node which presumably would have fixed things.)  

From the viewpoint of SnapPy, a more modular Sage would be fantastic as it would allow us to have more functionality in the stand-alone version and reduce development effort at the same time.

Nathan

 

[saad khalid]

On the topic of error messages, I would like to add that this issue has almost singlehandedly prevented any of my mathematics and physics professors from using Sage or Cocalc in a classroom setting. This of course doesn't say anything about whether they would consider using it for their own research, and a few of them have certainly considered it and one actualy did use it fairly extensively. However, if we do value students using Sage, I think it would go a long way towards making it "classroom ready" if the error messages were at all sensible from a user perspective.

[William Stein]

On Sun, Jul 29, 2018, 8:24 AM saad khalid <saad...@gmail.com> wrote:

On the topic of error messages, I would like to add that this issue has almost singlehandedly prevented any of my mathematics and physics professors from using Sage or Cocalc in a classroom setting. This of course

Yes. It greatly increases the work for instructors having to decide this stuff for their students.  This might be the difference between 50K users and 500K users...

Even disentangling the preparser would help a lot...

doesn't say anything about whether they would consider using it for their own research, and a few of them have certainly considered it and one actualy did use it fairly extensively. However, if we do value students using Sage, I think it would go a long way towards making it "classroom ready" if the error messages were at all sensible from a user perspective.

On Tuesday, July 24, 2018 at 2:18:32 PM UTC-5, William wrote:

Hi,

I just wrote a short talk that I'm about to give at ICMS 2018 about a
sort of Sage status report and wishlist:

https://goo.gl/qNycb3

--
William (http://wstein.org)

--
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+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[Jeroen Demeyer]

On 2018-07-29 17:27, William Stein wrote:
> Even disentangling the preparser would help a lot...

That's the second-oldest open ticket:
https://trac.sagemath.org/ticket/71

[William Stein]

Jeroen -- it looks like you actually implemented disentangling the
preparser in a branch on that ticket?

William

>
> --
> 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+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

--
William (http://wstein.org)

[Erik Bray]

On Sun, Jul 29, 2018 at 11:25 PM William Stein <wst...@gmail.com> wrote:
>
> On Sun, Jul 29, 2018 at 11:45 AM, Jeroen Demeyer <J.De...@ugent.be> wrote:
> > On 2018-07-29 17:27, William Stein wrote:
> >>
> >> Even disentangling the preparser would help a lot...
> >
> >
> > That's the second-oldest open ticket:
> > https://trac.sagemath.org/ticket/71
> >
>
> Jeroen -- it looks like you actually implemented disentangling the
> preparser in a branch on that ticket?

This is a bit far-out, but what if we just didn't show tracebacks at
all by default? Or at the very least, tracebacks originating from
Sage itself? Then, for example, "1/0" will just give a
ZeroDivisionError, not a full traceback deep somewhere into some
Cython code. Very useful for developers and advanced
users--positively terrifying and useless noise for new users and
students not as familiar with Python.

For their own code it's still good to have tracebacks as it is
infinitely valuable in debugging, and that's where the un-preparsing
might come in handy. But I'd hide Sage-originated tracebacks by
default (perhaps with an easy syntax for re-enabling them, such as a
%-magic, and instructions for how to do so accompanying every error).

[TB]

On 30/07/18 19:31, Erik Bray wrote:
>
> This is a bit far-out, but what if we just didn't show tracebacks at
> all by default? Or at the very least, tracebacks originating from
> Sage itself? Then, for example, "1/0" will just give a
> ZeroDivisionError, not a full traceback deep somewhere into some
> Cython code. Very useful for developers and advanced
> users--positively terrifying and useless noise for new users and
> students not as familiar with Python.
>
> For their own code it's still good to have tracebacks as it is
> infinitely valuable in debugging, and that's where the un-preparsing
> might come in handy. But I'd hide Sage-originated tracebacks by
> default (perhaps with an easy syntax for re-enabling them, such as a
> %-magic, and instructions for how to do so accompanying every error).
>

I never tried the skip traceback nbextension [1], but this looks similar
to what you suggest, at least for Jupyter.

Regards,
TB

[1]
https://github.com/ipython-contrib/jupyter_contrib_nbextensions/tree/master/src/jupyter_contrib_nbextensions/nbextensions/skip-traceback

[Nils Bruin]

Given that "%debug" works, it seems we're storing the traceback anyway. If we hide it, we could simply have a %tb or %traceback to display the traceback. There will be some limited scenarios where a traceback would normally find its way to the terminal, but sage segfaults before the prompt is available. In those cases we would lose information, but otherwise I'd be happy to type %tb to get a traceback.

In the notebook, we could do something fancy and fold the traceback, only displaying the error message, but it would have to be a rock solid implementation before that's worth it.

Of course, in doctesting we do want the tracebacks.

[Erik Bray]

prompt_toolkit is powerful-enough that traceback-folding could be done
on the CLI as well. It would probably require a keyboard-shortcut of
some kind to hide/show tracebacks, though for terminal emulators with
good mouse support it could also be done with the mouse :)

Easier said than done of course, but doable.

[William Stein]

On Mon, Jul 30, 2018, 9:31 AM Erik Bray <erik....@gmail.com> wrote:

On Sun, Jul 29, 2018 at 11:25 PM William Stein <wst...@gmail.com> wrote:
>
> On Sun, Jul 29, 2018 at 11:45 AM, Jeroen Demeyer <J.De...@ugent.be> wrote:
> > On 2018-07-29 17:27, William Stein wrote:
> >>
> >> Even disentangling the preparser would help a lot...
> >
> >
> > That's the second-oldest open ticket:
> > https://trac.sagemath.org/ticket/71
> >
>
> Jeroen -- it looks like you actually implemented disentangling the
> preparser in a branch on that ticket?

This is a bit far-out, but what if we just didn't show tracebacks at
all by default? 

That's what the sage notebook already does (since day 1 almost)...

Or at the very least, tracebacks originating from
Sage itself?  Then, for example, "1/0" will just give a
ZeroDivisionError, not a full traceback deep somewhere into some
Cython code.  Very useful for developers and advanced
users--positively terrifying and useless noise for new users and
students not as familiar with Python.

For their own code it's still good to have tracebacks as it is
infinitely valuable in debugging, and that's where the un-preparsing
might come in handy.  But I'd hide Sage-originated tracebacks by
default (perhaps with an easy syntax for re-enabling them, such as a
%-magic, and instructions for how to do so accompanying every error).

[Jeroen Demeyer]

On 2018-07-30 18:31, Erik Bray wrote:
> This is a bit far-out, but what if we just didn't show tracebacks at
> all by default?

Sorry to say, but that would be a horrible idea. Even if the tracebacks
are completely useless for ordinary users, they allow developers to
debug an issue when posted on a mailing list/asksage. I would avoid
anything that makes it harder for users to get help from developers.

[William Stein]

In sagenb it would show only the error at the bottom of the traceback, and there
is a way to toggle showing the complete traceback. It's the best of
both worlds.
I'll probably implement this for CoCalc soon-ish, at least.

-- William

[Samuel Lelievre]

Mon 2018-07-30 19:04:07 UTC+2, Erik Bray:

>
> prompt_toolkit is powerful-enough that traceback-folding could be done
> on the CLI as well. It would probably require a keyboard-shortcut of
> some kind to hide/show tracebacks, though for terminal emulators with
> good mouse support it could also be done with the mouse :)
>
> Easier said than done of course, but doable.

That would be wonderful. I miss that from SageNB.

[Erik Bray]

I agree but if you read the rest of my message you would see that I
also suggested making it very easy to obtain the actual traceback
(even including instruction for doing so with every error). That's no
harder--easier even--than what we already ask of users when give them
a path to the error log when Sage crashes on startup.

To be concrete, instead of seeing:

sage: 1 / 0
---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call last)
<ipython-input-10-b43c99900d8f> in <module>()
----> 1 Integer(1) / Integer(0)

/home/embray/src/sagemath/sage-python3/local/lib/python3.6/site-packages/sage/structure/element.pyx
in sage.structure.element.Element.__truediv__
(build/cythonized/sage/structure/element.c:13020)()
1729 cdef int cl = classify_elements(left, right)
1730 if HAVE_SAME_PARENT(cl):
-> 1731 return (<Element>left)._div_(right)
1732 if BOTH_ARE_ELEMENT(cl):
1733 return coercion_model.bin_op(left, right, truediv)

/home/embray/src/sagemath/sage-python3/local/lib/python3.6/site-packages/sage/rings/integer.pyx
in sage.rings.integer.Integer._div_
(build/cythonized/sage/rings/integer.c:13584)()
1952 """
1953 if mpz_sgn((<Integer>right).value) == 0:
-> 1954 raise ZeroDivisionError("rational division by zero")
1955 x = <Rational> Rational.__new__(Rational)
1956 mpq_div_zz(x.value, self.value, (<Integer>right).value)

ZeroDivisionError: rational division by zero


users would see:

sage: 1 / 0
ZeroDivisionError: rational division by zero (enter %tb to see the
full error traceback)


As William noted this is already roughly the behavior on SageNB, so I
would wager that it's not a "horrible idea".

[Erik Bray]

On Tue, Jul 31, 2018 at 3:57 PM Erik Bray <erik....@gmail.com> wrote:
>
> On Mon, Jul 30, 2018 at 8:34 PM Jeroen Demeyer <J.De...@ugent.be> wrote:
> >
> > On 2018-07-30 18:31, Erik Bray wrote:
> > > This is a bit far-out, but what if we just didn't show tracebacks at
> > > all by default?
> >
> > Sorry to say, but that would be a horrible idea. Even if the tracebacks
> > are completely useless for ordinary users, they allow developers to
> > debug an issue when posted on a mailing list/asksage. I would avoid
> > anything that makes it harder for users to get help from developers.
>
> I agree but if you read the rest of my message you would see that I
> also suggested making it very easy to obtain the actual traceback
> (even including instruction for doing so with every error). That's no
> harder--easier even--than what we already ask of users when give them
> a path to the error log when Sage crashes on startup.

I'll also add, from my years of experience following the "python" tag
on Stack Overflow, newbies will often post *just* the error message
anyways, even if they were given a full traceback. They don't know
what all that garbage is so they assume it's not useful. Hiding it
from them doesn't take much away from us as developers if we still
often have to ask them to provide it anyways. You can also see the
same effect often on ask.sagemath.org :)

[Jeroen Demeyer]

On 2018-07-31 15:57, Erik Bray wrote:
> That's no
> harder--easier even--than what we already ask of users when give them
> a path to the error log when Sage crashes on startup.

Yes, but I also consider that "crash log" a bad idea, so I wouldn't take
that as example.

It's kind of difficult to guess what user interface is the best. We
should really have an experiment with beginners to see what works best
(both for the users themselves as well as for users asking for help on
some public forum).

[Erik Bray]

Sure, some kind of A/B testing would be great. But from the sound of
things we don't really have to guess either...

[Vincent Delecroix]

I am +1 for this having this kind of behavior. There should also be
command line arguments to enable/disable this (perhaps --with-traceback
and --without-traceback). As for the default I don't really care since
the "sage" command on the system can be made anything.

> As William noted this is already roughly the behavior on SageNB, so I
> would wager that it's not a "horrible idea".

I would even call it a "good idea"!

Vincent

[Dima Pasechnik]

+1 here, too.

I'd even have

> ZeroDivisionError: rational division by zero (enter %tb to see the 

> full error traceback - important for reporting errors!)  

[Volker Braun]

There is a jupyter extension for that, though I haven't tried it...

https://github.com/ipython-contrib/jupyter_contrib_nbextensions/tree/master/src/jupyter_contrib_nbextensions/nbextensions/skip-traceback

[mmarco]

Do you know if something similar exists for jupyterlab?

[Sébastien Labbé]

The xmode option has three modes for tracebacks (Plain, Context and Verbose). By default, Sage is using Context. Plain does not give the context. Maybe we want to use this in Jupyter? Or else, add a fourth option?

sage: %xmode

Exception reporting mode: Plain
sage: 1/0
Traceback (most recent call last):
  File "<ipython-input-19-72ac74c5f414>", line 1, in <module>
    Integer(1)/Integer(0)
  File "sage/rings/integer.pyx", line 1925, in sage.rings.integer.Integer.__div__ (build/cythonized/sage/rings/integer.c:13288)

    raise ZeroDivisionError("rational division by zero")

ZeroDivisionError: rational division by zero

sage: %xmode
Exception reporting mode: Context
sage: 1/0

---------------------------------------------------------------------------
ZeroDivisionError                         Traceback (most recent call last)

<ipython-input-21-72ac74c5f414> in <module>()
----> 1 Integer(1)/Integer(0)

/home/slabbe/GitBox/sage/local/lib/python2.7/site-packages/sage/rings/integer.pyx in sage.rings.integer.Integer.__div__ (build/cythonized/sage/rings/integer.c:13288)()
   1923         if type(left) is type(right):
   1924             if mpz_sgn((<Integer>right).value) == 0:
-> 1925                 raise ZeroDivisionError("rational division by zero")
   1926             x = <Rational> Rational.__new__(Rational)
   1927             mpq_div_zz(x.value, (<Integer>left).value, (<Integer>right).value)

ZeroDivisionError: rational division by zero

sage: %xmode
Exception reporting mode: Verbose
sage: 1/0

---------------------------------------------------------------------------
ZeroDivisionError                         Traceback (most recent call last)

<ipython-input-23-72ac74c5f414> in <module>()
----> 1 Integer(1)/Integer(0)
        global Integer = <type 'sage.rings.integer.Integer'>

/home/slabbe/GitBox/sage/local/lib/python2.7/site-packages/sage/rings/integer.pyx in sage.rings.integer.Integer.__div__ (build/cythonized/sage/rings/integer.c:13288)()
   1923         if type(left) is type(right):
   1924             if mpz_sgn((<Integer>right).value) == 0:
-> 1925                 raise ZeroDivisionError("rational division by zero")
        global ZeroDivisionError = undefined
   1926             x = <Rational> Rational.__new__(Rational)
   1927             mpq_div_zz(x.value, (<Integer>left).value, (<Integer>right).value)

[saad khalid]

Hello:

The link seems to be broken, I was hoping to take a second look at some of the items on the wishlist. is there any way you could repost it? Thank you.

-Saad

[William Stein]

Indeed, that link is no longer valid. Please visit this one instead:

https://tinyurl.com/yac6cyzg