-
-
Notifications
You must be signed in to change notification settings - Fork 522
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document that SAGE_DEBUG is three-state #13865
Comments
Author: Volker Braun |
comment:2
I've posted to sage-devel since this might be of interest to a larger audience: https://groups.google.com/d/topic/sage-devel/Lmo6mmDylj4/discussion |
comment:3
Ah, 'anything else' sounds like a great 3rd case. Is there any standard on whether "yes/no", "!Yes/No", "true/false", "on/off" etc. is preferred? I always end up having to google the environment variables and then hope and check later that the value I used had the desired effect. |
comment:4
I think all documented environment variables use yes/no for a binary setting. In Python we always use !True/False since those are Python bools. |
comment:5
Component: Documentation? |
comment:6
You want to file it under something else? It is just a doc patch. |
comment:7
Is this ticket about fixing documentation of |
comment:8
I intended it just as a discussion and fix for the docstring. But if you want to add a new singular spkg then thats fine with me, too. |
comment:9
Replying to @vbraun:
Well, the documentation is certainly wrong (or not up-to-date), as the default is actually rather no. (We decided to add debug symbols by default since that doesn't have a performance impact -- except for larger files and hence probably slower start-up/loading, but one can strip these symbols later. W.r.t. the component: I just meant changing the meaning certainly extends to more than a documentation change (cf. the ticket's title; otherwise I'd call it "Clarify SAGE_DEBUG", say). Actually, what you propose is IMHO what we already have (or shouldTM have)... ;-) So just correcting or clarifying the documentation may indeed be sufficient. :-) (But I'd then change the ticket's title, as mentioned.) |
comment:11
Ok...
|
comment:12
Not sure whether the Sage Developer's Guide (on spkgs) is up-to-date right now. |
comment:13
We should probably also mention that (or how) debug symbols can be stripped afterwards... |
comment:14
Fixed. I grepped the docs and this is the only place that mentions |
comment:15
Replying to @vbraun:
Oh. I thought it was at least in some
There used to be (We now -- or still -- have the "micro-release" |
comment:16
The patch needs a proper commit message. |
comment:17
Fixed |
Reviewer: Jeroen Demeyer |
comment:18
Fine for me. Actually changing packages to be consistent with this documentation should be done in separate tickets. |
comment:19
Replying to @jdemeyer:
Of course. |
Merged: sage-5.6.beta2 |
Attachment: trac_13865_SAGE_DEBUG_documentation.patch.gz Updated patch |
comment:21
Rebased to #13032. |
Currently,
SAGE_DEBUG
is documented asThis is fine if you just add
gcc -g
, but the utility of having a real Python debug build shows that there should be more to debugging than just adding symbols. However, this has a real performance impact and should not be the default. So I propose thatSAGE_DEBUG
have three possible values:SAGE_DEBUG=no
means no debugging symbols (nogcc -g
), which mostly saves disk space.SAGE_DEBUG=yes
builds debug versions if possible (in particular, Python and Singular). These will be notable slower.SAGE_DEBUG
) is the same as the old default, compile with debugging symbols but no debugging options that influence performance.CC: @nexttime
Component: documentation
Author: Volker Braun
Reviewer: Jeroen Demeyer
Merged: sage-5.6.beta2
Issue created by migration from https://trac.sagemath.org/ticket/13865
The text was updated successfully, but these errors were encountered: