Opened 5 years ago

Closed 5 years ago

#16902 closed enhancement (fixed)

Advertise sig_check() better in the developers manual

Reported by: jdemeyer Owned by:
Priority: minor Milestone: sage-6.4
Component: documentation Keywords:
Cc: Merged in:
Authors: Jeroen Demeyer Reviewers: Vincent Delecroix, Dima Pasechnik
Report Upstream: N/A Work issues:
Branch: 3a21668 (Commits) Commit: 3a216680137ecb96b97b8ac6f7b34e7d0eb8c673
Dependencies: Stopgaps:

Description


Attachments (1)

coding_in_cython.html (58.3 KB) - added by jdemeyer 5 years ago.
Built documentation

Download all attachments as: .zip

Change History (24)

comment:1 Changed 5 years ago by jdemeyer

  • Branch set to u/jdemeyer/ticket/16902
  • Created changed from 08/29/14 11:46:49 to 08/29/14 11:46:49
  • Modified changed from 08/29/14 11:46:49 to 08/29/14 11:46:49

comment:2 Changed 5 years ago by jdemeyer

  • Commit set to 313d884ab090c89dbaaa2a6958166d053e99627a
  • Status changed from new to needs_review

New commits:

313d884Improve sig_check() documentation

comment:3 follow-up: Changed 5 years ago by vdelecroix

  • Status changed from needs_review to needs_info

1) sig_on/sig_off is Sage specific or is it included within Cython? It would be worth mentioning it. If it is Sage specific, why is that? and how do people coding in Cython do? (seems to be with nogil). If it is shipped with Cython, there should a pointer toward its documentation.

2) I am not sure that the following example is relevant.

def stack_sig_on():
    sig_on()
    sig_on()
    sig_on()
    # (some code)
    sig_off()
    sig_off()
    sig_off()

I mean, what would be the purpose of such code? If it is none, it is still interesting to mention it within a stack of calls like

def f1():
    sig_on()
    x = f2()
    sig_off()
    # ...

def f2():
    sig_on()
    # ...
    sig_off()
    return ans

3) The section Releasing the Global Interpreter Lock (GIL) was a bit obscure to me. It would be nice to have one sentence to say what it is. I guess it is related to my remark 1.

4) After reading the implementation of alarm I wonder why using alarm in doctests rather than directly the setitimer from the signal library? It is basically in TESTS blocks that such test would appear, and involving there the signal library is not ugly (and people reading it will learn about it instead of learning Sage wrapper!)

I learned many things reading it! Thanks! Vincent

comment:4 in reply to: ↑ 3 Changed 5 years ago by jdemeyer

Replying to vdelecroix:

1) sig_on/sig_off is Sage specific or is it included within Cython? It would be worth mentioning it. If it is Sage specific, why is that? and how do people coding in Cython do? (seems to be with nogil). If it is shipped with Cython, there should a pointer toward its documentation.

It is completely Sage-specific, I guess other people writing Cython code do not care about interrupts. There has been talking about putting these in Cython, but that has not happened yet.

2) If it is none, it is still interesting to mention it within a stack of calls like

def f1():
    sig_on()
    x = f2()
    sig_off()
    # ...

def f2():
    sig_on()
    # ...
    sig_off()
    return ans

Good suggestion!

3) The section Releasing the Global Interpreter Lock (GIL) was a bit obscure to me. It would be nice to have one sentence to say what it is. I guess it is related to my remark 1.

It is one of those things where, if you don't know it, you don't need to care. But I can put a link to the Cython documentation.

4) After reading the implementation of alarm I wonder why using alarm in doctests rather than directly the setitimer from the signal library?

Because alarm() is much cleaner.

It is basically in TESTS blocks that such test would appear, and involving there the signal library is not ugly

Why is it not ugly?

and people reading it will learn about it instead of learning Sage wrapper!

If people care about Sage's wrapper, they can still figure out the implementation and can find out about setitimer that way.

comment:5 Changed 5 years ago by git

  • Commit changed from 313d884ab090c89dbaaa2a6958166d053e99627a to 26a3edcd203369c1fb1e9d9561c998f9abe671cd

Branch pushed to git repo; I updated commit sha1. New commits:

26a3edcFurther documentation fixes

comment:6 Changed 5 years ago by jdemeyer

  • Status changed from needs_info to needs_review

New commits:

26a3edcFurther documentation fixes

comment:7 Changed 5 years ago by vdelecroix

Nothing more to say. You can set to positive review or ask another signal newbie to reread it!

Vincent

comment:8 Changed 5 years ago by jdemeyer

  • Reviewers set to Vincent Delecroix
  • Status changed from needs_review to positive_review

comment:9 follow-up: Changed 5 years ago by dimpase

my complaint about the change is about the line

or possibly the next Python code.

this is too vague (and grammatically weird - it should better be Python statement).

Does it mean that one need reach a Python exception? Or any Python statement? And what is the role of the word possible there? I don't get it.

comment:10 Changed 5 years ago by dimpase

  • Status changed from positive_review to needs_work

comment:11 in reply to: ↑ 9 ; follow-up: Changed 5 years ago by jdemeyer

Replying to dimpase:

it should better be Python statement.

I could change this.

Or any Python statement? And what is the role of the word possible there? I don't get it.

I mean that Python code can sometimes raise a KeyboardInterrupt, but I also don't know exactly when this happens. For example, the following can be interrupted:

cython('while True: print "foo"')

But the following cannot be interrupted:

cython('while True: x = ["foo"] * 100')

comment:12 in reply to: ↑ 11 ; follow-up: Changed 5 years ago by dimpase

Replying to jdemeyer:

Replying to dimpase:

it should better be Python statement.

I could change this.

yes please.

Or any Python statement? And what is the role of the word possible there? I don't get it.

I mean that Python code can sometimes raise a KeyboardInterrupt, but I also don't know exactly when this happens. For example, the following can be interrupted:

cython('while True: print "foo"')

But the following cannot be interrupted:

cython('while True: x = ["foo"] * 100')

Do you mean to say that Python won't be able to catch the interrupt in the former case, but not in the latter case (i.e. the latter loop will keep running)?

comment:13 in reply to: ↑ 12 ; follow-up: Changed 5 years ago by jdemeyer

Replying to dimpase:

Replying to jdemeyer:

Replying to dimpase:

it should better be Python statement.

I could change this.

yes please.

Or any Python statement? And what is the role of the word possible there? I don't get it.

I mean that Python code can sometimes raise a KeyboardInterrupt, but I also don't know exactly when this happens. For example, the following can be interrupted:

cython('while True: print "foo"')

But the following cannot be interrupted:

cython('while True: x = ["foo"] * 100')

Do you mean to say that Python won't be able to catch the interrupt in the former case, but not in the latter case (i.e. the latter loop will keep running)?

I mean that the loop in the last case will keep running because Python doesn't check for interrupts when executing x = ["foo"] * 100.

comment:14 in reply to: ↑ 13 ; follow-up: Changed 5 years ago by dimpase

Replying to jdemeyer:

Replying to dimpase:

Replying to jdemeyer:

Replying to dimpase:

it should better be Python statement.

I could change this.

yes please.

Or any Python statement? And what is the role of the word possible there? I don't get it.

I mean that Python code can sometimes raise a KeyboardInterrupt, but I also don't know exactly when this happens. For example, the following can be interrupted:

cython('while True: print "foo"')

But the following cannot be interrupted:

cython('while True: x = ["foo"] * 100')

Do you mean to say that Python won't be able to catch the interrupt in the former case, but not in the latter case (i.e. the latter loop will keep running)?

I mean that the loop in the last case will keep running because Python doesn't check for interrupts when executing x = ["foo"] * 100.

Whereas if the next statement after the latter was also cython, it would be terminated? Is this what you mean by possibly?

comment:15 in reply to: ↑ 14 Changed 5 years ago by jdemeyer

Replying to dimpase:

Whereas if the next statement after the latter was also cython, it would be terminated?

No, that's not what I mean. Pure Cython statements (which do not involve Python library calls) can never be interrupted.

comment:16 Changed 5 years ago by git

  • Commit changed from 26a3edcd203369c1fb1e9d9561c998f9abe671cd to cae40236d24c65cb1131402e77232d96dfa23373

Branch pushed to git repo; I updated commit sha1. New commits:

cae4023Clarify that Python can also interrupt

comment:17 Changed 5 years ago by jdemeyer

  • Status changed from needs_work to needs_review

comment:18 Changed 5 years ago by dimpase

  • Reviewers changed from Vincent Delecroix to Vincent Delecroix, Dima Pasechnik
  • Status changed from needs_review to positive_review

comment:19 Changed 5 years ago by vbraun

  • Status changed from positive_review to needs_work
File "src/doc/en/developer/coding_in_cython.rst", line 253, in doc.en.developer.coding_in_cython
Failed example:
    cython('print "Hello"')
Expected nothing
Got:
    Hello

comment:20 Changed 5 years ago by jdemeyer

Obviously :-)

comment:21 Changed 5 years ago by git

  • Commit changed from cae40236d24c65cb1131402e77232d96dfa23373 to 3a216680137ecb96b97b8ac6f7b34e7d0eb8c673

Branch pushed to git repo; I updated commit sha1. New commits:

3a21668Fix silly doctest

comment:22 Changed 5 years ago by jdemeyer

  • Status changed from needs_work to positive_review

comment:23 Changed 5 years ago by vbraun

  • Branch changed from u/jdemeyer/ticket/16902 to 3a216680137ecb96b97b8ac6f7b34e7d0eb8c673
  • Resolution set to fixed
  • Status changed from positive_review to closed

Changed 5 years ago by jdemeyer

Built documentation

Note: See TracTickets for help on using tickets.