#16571: APNG (Animated PNG) for animations
-------------------------------------+-------------------------------------
Reporter: gagern | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.3
Component: graphics | Resolution:
Keywords: | Merged in:
Authors: Martin von Gagern | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/gagern/ticket/16571 | f4a242733b301b813f316d8661485b77ad520ee7
Dependencies: #16570, #16645 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by gagern):
Replying to [comment:9 niles]:
> Replying to [comment:8 gagern]:
> > I guess that in the long run, I might also add a method which I'd have
called `fallback` or `still`, which can be used to set the fallback image
to something other than the first frame. Would you prefer `set_still` or
`add_fallback` or something like this?
>
> Let's use whatever term the APNG developers (Mozilla?) use for it . . .
Mozilla terminology is talking about a “default image” which either is the
first frame or “not part of the animation”. So I'm looking for a name to
set a default image which is not part of the animation.
`set_default_image`? My main concern here is the verb, since this sounds
like a simple setter with no heavy lifting.
> > > * most of the `APngAssembler` methods are missing doctests.
> >
> > Mentioned that problem in comment:3. I can try to come up with some
doctests if you insist, but they'd be pretty ugly to read.
>
> well, we have to have doctests . . . even if humans don't read them,
they're very useful in making sure that new code doesn't break old code.
When writing them, think "What is a machine-checkable way to ensure that
this method is producing what it claims to produce?" The current doctest
for `APngAssembler` is probably overkill. Also note that, if necessary,
you can use the `#indirect doctest` flag to mark doctests which check the
relevant method implicitly, but not explicitly.
I've started to write a doctest for each of my methods, see
[http://git.sagemath.org/sage.git/tree/src/sage/plot/animate.py?id=5786dcf2a441ebf81578b7c54ec02031c60e7f37#n961
here] for the current state of affairs. But I'm very unhappy about this.
Most of the methods I consider private (and I added `_` to them by now).
Each of them doesn't do much on its own; it relies on the interplay with
the other methods to make things work. So I have basically two options.
On the one hand I could see what internal variables each of the other
methods would set up front, then reproduce this in the example, and test
the result of a single method in response to that. But this fixes the
internal mechanics of the whole class into the doctest, i.e. I'm testing
''how'' things get done, not only that they get done. This feels wrong.
On the other hand, I could write a doctest which uses high level calls,
but whose output depends on the method I want to test. That's these
indirect doctests you mentioned. But there would be a lot of boilerplate
code for each method, and most things would be common for all tests. In
the end, I'd have 20 lines of doctests for 3 lines of code, most of these
similar for all methods in question.
So instead of one doctest per method, I'd like to have a single doctest
which tests the whole machinery, designed in such a way that it will only
work if all the parts interact as intended. In fact in the code I linked
above there is such a test for the `frame` method. Can I omit the doctests
for the individual methods if I have some doctest somewhere which tests
them all? Should I somehow indicate that the test for these is somewhere
else?
I've just [https://groups.google.com/forum/#!topic/sage-devel/TtMkK6MTrOM
posted to sage-devel] to obtain some broader input on this question of
doctest granularity.
There is one other problem with the doctests as they currently are: Sphinx
is choking on them.
{{{
[plotting ] Sphinx error:
[plotting ] 'ascii' codec can't decode byte 0x89 in position 683: ordinal
not in range(128)
Error building the documentation.
}}}
I have no idea why Sphinx is trying to decode a string literal here, but
this might make doctests using binary data almost impossible. Which means
that I'll likely have to build the data in question from some `struct`
calls, or write a helper function to convert largish chunks of hex to
binary, or whatever.
--
Ticket URL: <http://trac.sagemath.org/ticket/16571#comment:10>
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.
