#16640: Graphics3d.show abuses graphics_filename
-------------------------------------+-------------------------------------
Reporter: gagern | Owner:
Type: defect | Status: needs_work
Priority: major | Milestone: sage-6.4
Component: graphics | Resolution:
Keywords: | Merged in:
Authors: Martin von Gagern | Reviewers: Jeroen Demeyer
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/jdemeyer/ticket/16640 | bd1479d38fe1adb42755ab92499ff8c1ba35592d
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by gagern):
Replying to [comment:19 kcrisman]:
> Finally, I don't understand this comment - I'm sorry if I am just
thinking inside the box:
> {{{
> # when testing this, modify graphics_filename so that it
> # returns files which don't automatically share a base
name,
> # e.g.: "import random; i = random.randint(0, 10000)"
> }}}
> Was this just a "note to self" or do you mean that, as a tester, I
should actually change `graphics_filename` instead of letting it just keep
adding one to base names, or ... ?
Doctests mostly check whether a given file can be created, but to check
whether that file displays as intended, you'd use an interactive setup not
a doctest. So I envision testers using the notebook to run tests, with no
way to programmatically tell whether he is doing tests or something else.
And the notebook numbers files by incrementing some counter until they are
unique. I.e. starting by `sage0.png` then `sage1.png`. But the critical
point here is that the collision detection takes file extensions into
account. So if I were to request e.g. a `.foo` file and a `.bar` file, I'd
get `sage0.foo` and `sage0.bar` not `sage1.bar`. Usually. Unless
`sage0.bar` already exists at the time the graphics file name is
requested, in which case I'd get `sage0.foo` but `sage1.bar`.
The problematic case I had in mind was one where some viewer uses one file
name to derive some other file name. So if a viewer were to open
`sage0.foo` and ''from that name'' infer that it also has to open
`sage0.bar`, then this would work during test cases, but might fail
unexpectedly if a user creates `sage0.bar` in some other code inside the
same cell.
I'd like to detect such situations. I'd like to make sure that if there is
more than one file required for some viewer, then all file names are
stated explicitly somewhere, and not inferred by some extension
replacement. And that's the point of the comment. I'd like to break the
sequential numbering and replace it by random numbers to ensure that
inferred file names would break.
So yes, anyone who tests a patch that might be affected by the scenario
outlined above should, in my opinion, temporarily modify the code of
`graphics_filename` to ensure that no file name inference is used. If you
can think of a better wording to convey this idea, please let me know. I
guess we could also add a link to this comment here, since the whole
explanation is too long to put into such a comment, imho.
--
Ticket URL: <http://trac.sagemath.org/ticket/16640#comment:29>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
