On Wed, Dec 10, 2008 at 12:28 AM, Dan Drake <[EMAIL PROTECTED]> wrote:
> On Wed, 10 Dec 2008 at 01:43AM -0600, Jason Grout wrote:
>> Cool. I just posted a note on Arxiv with a .sage program file, and
>> I'm seeing the same problem. (I thought the doctests passed, but
>> apparently they don't and I'm seeing the same problem; I think I got
>> around this once by "including" the file as part of the sage standard
>> library and then running the doctests.).
>
> Yeah, I can easily put the file in the standard library and doctest it,
> but the point is that it should be easy for other people to run
> doctests; they download the code, run a "sage -t", and when everything
> passes, they start using it. This preprint will get posted sometime
> soon, but (hopefully!) people will find my code useful many years from
> now with a future version of Sage.
>
> Doctesting is like putting your code in the refrigerator instead of
> leaving it out -- it helps prevent bitrot. :)
That "sage -t foo.sage" doesn't import the functions somehow is a
sucky new-ish bug, that needs to be fixed ASAP, in my opinion. This
is related to recent major changes in how sage -t works on *.sage
files. See this ticket I just made:
http://trac.sagemath.org/sage_trac/ticket/4750
I don't think this will be hard to fix -- probably just a few lines of
code in the
right place.
Note that you could also submit a patch to Sage with the code you're doctesting.
I did that with all the tests from both of the books I published, and
I encourage you and many others to do the same with the code from your
article. The code would go in a file
devel/sage/sage/tests/
like the file devel/sage/sage/tests/book_stein_modform.py
In fact, I could imagine having dozens of files in that directory, and
when doctests break there, we could notify the authors before
releasing the version of Sage that breaks their doctests for feedback
-- then they could update their papers or Sage. Maybe this is how
the technical aspect of jsage should work:
http://www.sagemath.org/library/jsage/index.html
>> 2. (this is totally a preference thing) I think it's helpful for
>> people if you put that there is a Sage program included in the
>> preprint in the comments, just like you would if there was a figure or
>> something. Plus, everyone that gets the arxiv email starts seeing
>> references to Sage programs; that helps our marketing department :).
>
> Exactly! I'm using the listings package to actually put the code into
> the PDF and am including some explanatory propaganda. I understand that
> very few people will actually download the tarball and get the .sage
> file, so I figured I can at least put the code in front of their eyes.
>
> While I am adding to this thread, I'll mention a trick: in the article,
> I want to mention how to get the .sage file -- but to do that, I need to
> know the arXiv URL. But how do you find out the eprint number before you
> submit? The answer is to make your submission early in the day, get it
> accepted -- so you find out the eprint number! -- then go back, update
> your TeX file with the URL, and resubmit. If you do this early enough
> (before 4 pm ET?) it doesn't show up as a new version.
>
> Dan
Here's a question for you -- is there a way to embed a block of text
in an extractable way inside a pdf, etc.? If so, I think we could
easily change the notebook so ".pdf" is one of the formats for
uploading a sage worksheet. Then you could somehow embed the
worksheet itself in the pdf. Then tell readers of the pdf -- "hey,
just upload this pdf you're reading right now to any sage notebook
server, and you're good to go!"
Thoughts?
William
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
