SAGE_DEBUG=[yes|no|unset]

19 views
Skip to first unread message

Volker Braun

unread,
Dec 26, 2012, 1:04:02 PM12/26/12
to sage-...@googlegroups.com
Currently, SAGE_DEBUG is documented as

    "If it is unset (the default) or set to 'yes', then debugging is turned on."

As the "How to proceed to reduce Sage's memory leaking" thread shows, we should make it easy for developers to build Python with debugging, which has a certain performance impact. So that shouldn't be the default, but we don't really need another arcane environment variable either. I propose that we use SAGE_DEBUG in three different ways:

  * SAGE_DEBUG=no means no debugging symbols (no gcc -g), which basically only saves disk space.

  * SAGE_DEBUG=yes builds debug versions if possible (in particular, Python and Singular). These will be notable slower but allow us to pinpoint memory problems much more easily.

  * Anything else (including unset SAGE_DEBUG) is the same as the old default, compile with debugging symbols but no debugging options that influence performance.

Nils Bruin

unread,
Dec 26, 2012, 1:18:18 PM12/26/12
to sage-devel
On Dec 26, 10:04 am, Volker Braun <vbraun.n...@gmail.com> wrote:
> I propose
> that we use SAGE_DEBUG in three different ways:
[...]

+1. Obvious and easy to use.

Very minor mod: Also provide an assignable value for SAGE_DEBUG for
the default behaviour, rather than relying on SAGE_DEBUG being unset.
Probably SAGE_DEBUG='', unset SAGE_DEBUG and perhaps also
SAGE_DEBUG='default' should have the same effect.

Volker Braun

unread,
Dec 26, 2012, 1:20:27 PM12/26/12
to sage-...@googlegroups.com

Nils Bruin

unread,
Dec 26, 2012, 1:30:45 PM12/26/12
to sage-devel
On Dec 26, 10:18 am, Nils Bruin <nbr...@sfu.ca> wrote:
> Very minor mod: Also provide an assignable value for SAGE_DEBUG for
> the default behaviour, rather than relying on SAGE_DEBUG being unset.
> Probably SAGE_DEBUG='', unset SAGE_DEBUG and perhaps also
> SAGE_DEBUG='default' should have the same effect.

Never mind. That's what you propose even more generally. I need coffee.

Jeroen Demeyer

unread,
Dec 26, 2012, 1:43:16 PM12/26/12
to sage-...@googlegroups.com
On 2012-12-26 19:04, Volker Braun wrote:
> * SAGE_DEBUG=no means no debugging symbols (no gcc -g), which
> basically only saves disk space.
>
> * SAGE_DEBUG=yes builds debug versions if possible (in particular,
> Python and Singular). These will be notable slower but allow us to
> pinpoint memory problems much more easily.
>
> * Anything else (including unset SAGE_DEBUG) is the same as the old
> default, compile with debugging symbols but no debugging options that
> influence performance.
Good idea!

Let me add that the GCC spkg also implements SAGE_DEBUG=yes by building
a slower compiler with more internal checks (but the programs generated
by GCC are the same).

Jean-Pierre Flori

unread,
Dec 26, 2012, 1:47:16 PM12/26/12
to sage-...@googlegroups.com
As far as i remember, some spkg already have such a behavior, i.e. pass different flags depending whether SAGE_DEBUG is actually set to yes or is not set, which already differs from what the doc says.

saad saadgee

unread,
Dec 26, 2012, 3:21:12 PM12/26/12
to sage-...@googlegroups.com
Yar i do not undarstand u?
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To post to this group, send email to sage-...@googlegroups.com.
> To unsubscribe from this group, send email to
> sage-devel+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel?hl=en.
>
>
>
Reply all
Reply to author
Forward
0 new messages