Since Travis answered, I'll also throw in some answers for variety (I
mainly going to mention things that are complementary)...
On Fri, Sep 21, 2018 at 9:29 AM, Andy Howell <a...@gamubaru.com> wrote:
> How to setup a testing environment that won't interfere with my
> installed sage.
I would *always* install a completely separate copy of Sage for this
purpose. You definitely don't want
your dev version messing up your production work. Just download the
sage source code, extract it
somewhere else, and build it. That will be your "test environment".
If you have the disk space but your computer
isn't super fast, then this may be better than what Travis suggests,
since switching branches and doing
a build can be very slow with Sage, unfortunately.
> How to debug code on the command line.
In addition to what Travis said, don't be embarrassed to simply use
print. Also, sys.stdout.flush() can be useful
to ensure that your output appears exactly when you expect it to appear.
For debugging Cython code, gdb is also very useful. For memory leaks,
valgrind is useful.
> How to debug in code in Jupyter.
Don't -- just switch to the command line. If you're debugging or
profiling something, it's best to be as close to the metal
as you can get, and eliminate any sources of complexity, if possible.
> What are the differences between Sage's use of python and vanilla python?
The Sage command line prompt uses a preparser. Given a line of code
"foo...", type
sage: preparse("foo...")
to see exactly what it is transformed into before being given to
Python. This can be a very sensible
thing to do as a first step when debugging, in order to eliminate a
layer of complexity (see above).
The Sage library itself does NOT have any code that is run through the
preparser -- it's 100% normal
Python (or Cython) code, plus the other languages in Sage.
> Are there tricks to sage development that make it simpler?
Yes, tons, but that tricks that are useful depend heavily on what area
of Sage you want to do development on.
> How to I find the code being called?
I think %prun is very useful for this, since it shows all functions
called in evaluating a line of code, how many times
they were called, how long it took, etc.
> Which python debugger are best for sage?
Personally I like print statements and Ipython's built in debugger,
which is very good for Python code (but useless for Cython).
> I can write those sections, but I will need help and direction from the
> community. My goal is to make it dead easy for people like myself to fix
> minor problems. Some of the above are probably generic python questions.
> However, having them addressed here makes it more likely the casual user
> will contribute. Even if all the doc does is to provide links to python
> sites, that is helpful.
>
> A couple weeks ago I was looking at a latex formatting issue that Samuel
> Lelievre helped me with (Thanks Samuel), but I wasn't able to trace the
> code in the debugger. I still want to address that.
>
> Regards,
>
> Andy
>
> --
> 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 to sage-devel@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)
--
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
