Re: testing canvas and API change consideration
Ethan Burns
Sorry for the delay. By the way, I CCed plotinum-discuss so that our
ideas are discussed in a more-public forum. I hope that is OK.
I think that the testing canvas is a very interesting idea. One
reason why Plotinum didn't have tests written to begin with is that I
wasn't quite sure how to test that a drawing came out correctly. Your
approach could work, and I wouldn't be opposed to including it in
Plotinum.
As for the vg.Length change, what you described is exactly what I
intended. I say that we wait until Plotinum moves to gonum before we
make this change, however. In fact, I think that we should make a
list of API breaking changes that we want to make when Plotinum is
moved. I think that there were a couple of other things mentioned
either in plotinum-discuss or on the gonum list, but now I don't
remember; a list would be helpful. For now I added a label "gonum"
label to a couple of the issues in the tracker.
Ethan
On Thu, Jul 4, 2013 at 8:11 AM, Ethan Burns <burns...@gmail.com> wrote:
> Hi Dan,
>
> I am on vacation this week, but I'll take a look and get back to you Sunday.
>
> Ethan
>
> On Jul 3, 2013 10:37 PM, "Dan Kortschak" <dan.ko...@adelaide.edu.au>
> wrote:
>>
>> Hi Ethan,
>>
>> I've been putting together tests for my rings package and figured the
>> best way to test the implementation without testing the underlying
>> canvas implementations was to make a very simple testing canvas[1]. You
>> have a TODO about testing, so if/when you decide to take that on, I'd be
>> very happy to donate this code to the plotinum project; it has worked
>> well in my tests and makes it reasonably clear what expectations are for
>> tests.
>>
>> On another note that came up while writing the tests is the vg.Length
>> handling and plot.Save parameterisation. In vg, you have a TODO on
>> making the unit conversions more like how time.Duration is handled. And
>> looking at how it is necessary to describe non-Imperial dimension for
>> Save (e.g. [2], it would be worse for metric specification). I'd like to
>> propose that Save take vg.Length size parameters and at the same time
>> vg.Length handling be altered so you can:
>>
>> p.Save(15*vg.Centimeter, 20*vg.Centimeter, "file.png")
>>
>> or
>>
>> p.Save(6*vg.Inch, 8*vg.Inch, "file.png")
>>
>> If you're happy with these proposals (they are both API breaking), I'm
>> able to put together the CL for that.
>>
>> cheers
>> Dan
>>
>>
>> [1]http://code.google.com/p/biogo/source/browse/rings/vgtest_test.go?repo=graphics&name=feature%2Frings
>>
>> [2]http://code.google.com/p/biogo/source/browse/rings/rings_test.go?repo=graphics&name=feature%2Frings&L166#166
>>
>
Dan Kortschak
Dan Kortschak
dredge up when I wrote the OP.
plot.New can return an error. It seems that the code all depends on
unexported default variable which I would imaging should not fail. This
would be a prime case for changing the signature to New() *Plot with a
panic on failure.
On a long standing issue - the pie chart suggestion issue. I have code
that does nearly all of what you might want for pie charts at [1] in the
labels.go and highlight.go files. The only thing that's missing is an
aesthetic placement of pie segments; it seems to me that if you want to
have a pie chart (this is arguable) then the segments should be equally
gapped along their straight edges - I don't do this. As it stands it can
do donut charts with a bit of forcing.
cheers
Dan
[1]http://code.google.com/p/biogo/source/browse/rings/?repo=graphics&name=feature/rings
Ethan Burns
On Jul 7, 2013 8:01 PM, "Dan Kortschak" <dan.ko...@adelaide.edu.au> wrote:
>
> There was one other thing that I had thought of, but forgot and couldn't
> dredge up when I wrote the OP.
>
> plot.New can return an error. It seems that the code all depends on
> unexported default variable which I would imaging should not fail. This
> would be a prime case for changing the signature to New() *Plot with a
> panic on failure.
I agree. Actually, if I recall correctly, the code that may error is for finding fonts. Instead of panicking when the fonts aren't found, we should do the font initialization lazily. This way if someone makes a plot or image without text, then they don't need the fonts installed at all. There was a request for this behavior on plotinum-discuss recently. I'll open an issue for it tomorrow.
> On a long standing issue - the pie chart suggestion issue. I have code
> that does nearly all of what you might want for pie charts at [1] in the
> labels.go and highlight.go files. The only thing that's missing is an
> aesthetic placement of pie segments; it seems to me that if you want to
> have a pie chart (this is arguable) then the segments should be equally
> gapped along their straight edges - I don't do this. As it stands it can
> do donut charts with a bit of forcing.
I think that I closed the issue with the status "won't fix." I don't like pie charts much, because I think that bar charts are easier to understand. But, they are popular, so if your plotter fits in well with Plotinum then maybe I should reconsider adding them. Certainly, if/when Plotinum is moved over to gonum, and is effectively handed over to the to the community, then maybe the community could decide to add them.
Ethan
Dan Kortschak
argument with the co-authors of one of my paper about use of a pie chart
where they insisted on representing an ordered set of classes as a pie
chart instead of a bar chart - I lost that one.
Perhaps we can leave this as a way marker for people who want to use
them - the code I pointed to would take very little to make into a pie
chart plotter. If it's wanted, the wanter can do it.
Dan