Opened 11 years ago

Closed 3 years ago

#6357 closed enhancement (invalid)

make sage -t worksheet.sws work

Reported by: ncalexan Owned by: tbd
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: doctest framework Keywords: doctest sws notebook worksheet test
Cc: kini, novoselt Merged in:
Authors: Reviewers: Andrey Novoseltsev, Frédéric Chapoton
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by was)

This came up on the mailing list: it would be nice if sage -t worksheet.sws worked.

Also, it would be nice to have a button when using notebook that would launch sage -t on it and display the result.

Separate, but also nice, would be "worksheet-ify" command that took a series of doctests and made a nice worksheet out of it.

Change History (10)

comment:1 Changed 11 years ago by ncalexan

  • Type changed from defect to enhancement

comment:2 Changed 11 years ago by was

(NOTE -- I rethought this in the last paragraph below, but didn't delete the stuff above, in case it is useful still.)

How I would implement this:

 sage -t foo.sws

would

  1. extract foo.sws into a temporary directory. Try to use builtin library calls instead of calling tar on the command line, if possible. Note that foo.sws is a .tar.bz2
  1. Ignore everything not in {{}}'s. I'm using {{ instead of triple {'s to avoid trac's wiki preformat mode.
  1. Create a file foo.py. For each chunk of code
    {{
    input lines
    ///
    output lines
    

insert into the file foo.py lines:

sage: sage.server.notebook.cell.eval_for_testing(r"""input lines
input lines...""")
output lines

since I think how the notebook works is best simulated by using the sage0 pexpect interface (that's what the notebook really uses).

  1. Doctest foo.py using sage -t foo.py and let normal doctest report the results. Possibly postprocess the print sage0.eval(r""" wrapper crap out of the result.

The above plan has the advantage that it reduces things to the existing python doctest framework instead of trying to write another doctest system. One disadvantage is that using sage0 means that two Python processes are spawned instead of 1.

The function sage.server.notebook.cell.eval_for_testing has not been written. It would make a blank directory, call sage0.eval -- just like the notebook does -- then apply all transformations the notebook does on output.

Actually, writing the above makes me think that this problem is harder than I thought when I started writing this comment! The problem is the output is potentially very complicated, since it can be a bunch of sagexxx.png files, html, etc. Maybe a better approach is to completely use the notebook codebase -- as is done in all the notebook doctesting -- to run a *copy* of the whole worksheet (a sort of evaluate all) -- then simply compare the original's output to the copy's.

comment:3 Changed 11 years ago by was

  • Description modified (diff)

comment:4 Changed 8 years ago by kini

  • Cc kini added
  • Keywords sws notebook added; sage removed
  • Report Upstream set to N/A

comment:5 Changed 8 years ago by novoselt

  • Cc novoselt added

comment:6 Changed 7 years ago by roed

After #12415, this just needs to add a parser for .sws files in sage.doctest.sources analogous to PythonSource, RestSource and TexSource.

comment:7 Changed 7 years ago by roed

  • Component changed from doctest to doctest framework

comment:8 Changed 3 years ago by novoselt

  • Milestone changed from sage-feature to sage-duplicate/invalid/wontfix
  • Status changed from new to needs_review

With no progress on it and with sws planned for retirement together with SageNB, I think we should close it.

comment:9 Changed 3 years ago by chapoton

  • Reviewers set to Andrey Novoseltsev, Frédéric Chapoton
  • Status changed from needs_review to positive_review

yes, let us close that

comment:10 Changed 3 years ago by vbraun

  • Resolution set to invalid
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.