Dear Fidel, On Mar 3, 5:29 am, Minh Nguyen <nguyenmi...@gmail.com> wrote: > You might want to have a look at this site: > > http://trac.sagemath.org/sage_trac/report/10 > > It contains tickets with patches, so you can picket any ticket and > view the attached patches.
Perhaps the use of a "patch" needs an explanation. You can find an introduction in the programming tutorial, see the subsections of http://modular.math.washington.edu/sage/doc/prog/node39.html Here is my outline: A patch defines a change in the code: Some old lines will be removed, others will be changed, new will be inserted, and so on. How to obtain a patch from a ticket? The ticket has some link to its attachments. The first thing you see is an *annotated* version of the patch, i.e. a html page where the changes are highlighted. At the bottom of the page, you see a link that gives you the original format of the patch; this is a simple text file and is what you should download. You might consider to do development work in a separate branch of Sage, so that you can return to something that works (just in case if you mess up things). This is done (on a shell) by sage -clone Name_of_new_repository sage -b Name_of_new_repository If you want to return to the original repository, just do sage -b main Sage includes Mercurial, which helps to keep track of code changes in a cooperative way. And it can also deal with the patch (say "newstuff.patch") that you just downloaded. In Sage, you can do sage: hg_sage.import_patch("path_to/newstuff") If this does not work, then you should complain at the ticket. If it works, then the source code is now changed -- but the Sage executable is still unchanged. Therefore, quit Sage and do sage -b This command will do a new compilation of those files that were altered by the patch (and the dependent files as well). And now you can test if you like the new code... The opposite way: You want to change the code and submit a patch for some ticket. The files that are considered by hg_sage are located in sub-folders SAGE_ROOT/devel/sage-Name_of_new_repository/. So, please do your changes there. Of course, the files concerning the main branch of Sage are in SAGE_ROOT/devel/sage-main/ If you did your changes, then you should again do "sage -b" and test. If it works, you inform Mercurial that your changes shall make up a new version of your *local* sage. This is done by sage: hg_sage.commit() First, you will see what is changed. Second, an editor pops up and you are asked to type a comment about your changes. If this is done, you are back at the sage prompt. If you do sage: hg_sage.log() then you will see the complete history of Sage revisions, including the change that you just did yourself. Take down the version number of your change, and do sage: hg_sage.export(version_number, 'Some_path/new_patch_name') The result will be a patch, i.e. a text file named new_patch_name.patch in the given path. Now you can attach this file to the ticket. If it gets a positive review then the patch may be included into one of the next releases of Sage, i.e., only at that point your changes are more-than-local. > EXAMPLES: > # put your doctests here > # should include lots and lots of examples on how to use my_function() > """ More details can be found in subsections of http://modular.math.washington.edu/sage/doc/prog/node11.html Essentially, you include in your doc-string the output of a Sage session. If a line starts with 'sage:', then the rest of the line is interpreted as a command. The other lines are the expected output. So, if my_function() raises any appropriate input to the second power, then your doc string may contain: sage: my_function(sqrt(2)) 2 sage: my_function(Matrix(ZZ,2,2,[0,1,1,0])) [1 0] [0 1] sage: my_function('bla') 'blabla' If your function is supposed to raise an error under certain circumstances, this can be tested as well: sage: my_function(Matrix(ZZ,2,1,[1,0])) Traceback (most recent call last): ... ArithmeticError: self must be a square matrix The line 'Traceback (most recent call last):' informs the test suite that you *want* to have an error. The last line tells which type of error and which error message is expected. And the "..." is very useful. If parts of the output is random, you can replace the random parts by '...' and only give the non-random parts. For example, if my_function has an option to print out a timing, then you could do sage: my_function(2,withTime=True) -> Total computation time: ... seconds 4 Best regards, Simon --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
