Graphing/charting application

I'm hunting around for a simple application that generates images like
bar graphs. PNG output would be ideal. I just need to create a chart or
two, so I'm not sure that learning the API for a new library and writing
software is exactly what I need.

Is there something in gems that'd suit my needs? I'd be perfectly happy
with something that just takes a series of numbers and strings as input
and dumps an image file. My preference would be for a 3D-looking chart
(with those faux-3D verticle bars in many a PowerPoint slide, for
instance), but 2D is acceptable as well. In addition to helping with my
current need to generate a couple of visual aids, such a thing might also
provide some useful hints on how to accomplish similar tasks in the
future when I look at the source code -- which is one of the reasons I'd
like to find something written in Ruby.

Any help is appreciated.

···

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Brian K. Reid: "In computer science, we stand on each other's feet."

Have you taken a look at Gruff? I haven't used it myself, but it seems to be popular. Looks like it can do PNG bar graphs:

http://geoffreygrosenbach.com/projects/show/5
http://rubyforge.org/projects/gruff

Michael Glaesemann
grzm seespotcode net

···

On Jul 14, 2007, at 17:05 , Chad Perrin wrote:

I'm hunting around for a simple application that generates images like
bar graphs.

Chad Perrin wrote:

I'm hunting around for a simple application that generates images like
bar graphs. PNG output would be ideal. I just need to create a chart or
two, so I'm not sure that learning the API for a new library and writing
software is exactly what I need.

http://scruffy.rubyforge.org/

gruff has been mentioned already

Is there something in gems that'd suit my needs? I'd be perfectly happy
with something that just takes a series of numbers and strings as input
and dumps an image file. My preference would be for a 3D-looking chart
(with those faux-3D verticle bars in many a PowerPoint slide, for

You should really try to avoid those faux-3D bars - they make the
graph much hard to read.

If you want to learn more about the basics of good graph design
junkcharts, http://junkcharts.typepad.com/junk_charts/, is a good
place to start.

Hadley

I'd normally agree, but in this case the purpose is to create a
pseudo-joking maretroid presentation graphic.

···

On Sun, Jul 15, 2007 at 04:16:13PM +0900, hadley wickham wrote:

>Is there something in gems that'd suit my needs? I'd be perfectly happy
>with something that just takes a series of numbers and strings as input
>and dumps an image file. My preference would be for a 3D-looking chart
>(with those faux-3D verticle bars in many a PowerPoint slide, for

You should really try to avoid those faux-3D bars - they make the
graph much hard to read.

If you want to learn more about the basics of good graph design
junkcharts, http://junkcharts.typepad.com/junk_charts/, is a good
place to start.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
They always say that when life gives you lemons you should make lemonade.
I always wonder -- isn't the lemonade going to suck if life doesn't give
you any sugar?

Is there some kind of rule that states that, when something like RDoc is
available, library developers are disallowed from producing good
documentation? I'm constantly frustrated by the fact that many libraries
figure a skeleton map of available methods constitutes "documentation".

···

On Sun, Jul 15, 2007 at 08:01:43AM +0900, Michael Glaesemann wrote:

On Jul 14, 2007, at 17:05 , Chad Perrin wrote:

>I'm hunting around for a simple application that generates images like
>bar graphs.

Have you taken a look at Gruff? I haven't used it myself, but it
seems to be popular. Looks like it can do PNG bar graphs:

http://geoffreygrosenbach.com/projects/show/5
http://rubyforge.org/projects/gruff

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Amazon.com interview candidate: "When C++ is your hammer, everything starts
to look like your thumb."

I'm sure that Geoffry would appreciate documentation patches.

···

On 7/15/07, Chad Perrin <perrin@apotheon.com> wrote:

On Sun, Jul 15, 2007 at 08:01:43AM +0900, Michael Glaesemann wrote:
>
> On Jul 14, 2007, at 17:05 , Chad Perrin wrote:
>
> >I'm hunting around for a simple application that generates images like
> >bar graphs.
>
> Have you taken a look at Gruff? I haven't used it myself, but it
> seems to be popular. Looks like it can do PNG bar graphs:
>
> http://geoffreygrosenbach.com/projects/show/5
> http://rubyforge.org/projects/gruff

Is there some kind of rule that states that, when something like RDoc is
available, library developers are disallowed from producing good
documentation? I'm constantly frustrated by the fact that many libraries
figure a skeleton map of available methods constitutes "documentation".

Is there some kind of rule that states that, when something is freely made available to the public, the users are disallowed from being polite? I'm constantly frustrated by the fact that many users figure a scathing comment in IRC or a mail to ruby-talk constitutes "constructive criticism".

Why do so many users never seem to bother to put in an ounce of effort in looking at something for every pound of effort the author puts into writing it in the first place?

It took me less than 60 seconds to download gruff, unpack it, and notice that there is over 92K(!!) of tests. PLENTY of live testable "documentation" right there. But instead of doing something like that, your sense of entitlement made you think the above paragraph was a good idea.

...Made slightly redundant by Gregory's replies, but I had to get it off my chest...

···

On Jul 15, 2007, at 09:26 , Chad Perrin wrote:

Is there some kind of rule that states that, when something like RDoc is
available, library developers are disallowed from producing good
documentation? I'm constantly frustrated by the fact that many libraries
figure a skeleton map of available methods constitutes "documentation".

s/Geoffry/Geoffrey/

···

On 7/15/07, Gregory Brown <gregory.t.brown@gmail.com> wrote:

On 7/15/07, Chad Perrin <perrin@apotheon.com> wrote:
> On Sun, Jul 15, 2007 at 08:01:43AM +0900, Michael Glaesemann wrote:
> >
> > On Jul 14, 2007, at 17:05 , Chad Perrin wrote:
> >
> > >I'm hunting around for a simple application that generates images like
> > >bar graphs.
> >
> > Have you taken a look at Gruff? I haven't used it myself, but it
> > seems to be popular. Looks like it can do PNG bar graphs:
> >
> > http://geoffreygrosenbach.com/projects/show/5
> > http://rubyforge.org/projects/gruff
>
> Is there some kind of rule that states that, when something like RDoc is
> available, library developers are disallowed from producing good
> documentation? I'm constantly frustrated by the fact that many libraries
> figure a skeleton map of available methods constitutes "documentation".

I'm sure that Geoffry would appreciate documentation patches.

Sure . . . just as soon as I figure out how to use the library. With the
information that's provided, I could probably sort out how to create
simplest-case line graphs, but beyond that I'd have to put real time into
it -- time I might prefer to spend on Scruffy, which it appears has
better documentation.

···

On Mon, Jul 16, 2007 at 01:33:12AM +0900, Gregory Brown wrote:

On 7/15/07, Chad Perrin <perrin@apotheon.com> wrote:
>On Sun, Jul 15, 2007 at 08:01:43AM +0900, Michael Glaesemann wrote:
>>
>> On Jul 14, 2007, at 17:05 , Chad Perrin wrote:
>>
>> >I'm hunting around for a simple application that generates images like
>> >bar graphs.
>>
>> Have you taken a look at Gruff? I haven't used it myself, but it
>> seems to be popular. Looks like it can do PNG bar graphs:
>>
>> http://geoffreygrosenbach.com/projects/show/5
>> http://rubyforge.org/projects/gruff
>
>Is there some kind of rule that states that, when something like RDoc is
>available, library developers are disallowed from producing good
>documentation? I'm constantly frustrated by the fact that many libraries
>figure a skeleton map of available methods constitutes "documentation".

I'm sure that Geoffry would appreciate documentation patches.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Kent Beck: "I always knew that one day Smalltalk would replace Java. I
just didn't know it would be called Ruby."

>Is there some kind of rule that states that, when something like
>RDoc is
>available, library developers are disallowed from producing good
>documentation? I'm constantly frustrated by the fact that many
>libraries
>figure a skeleton map of available methods constitutes
>"documentation".

Is there some kind of rule that states that, when something is freely
made available to the public, the users are disallowed from being
polite? I'm constantly frustrated by the fact that many users figure
a scathing comment in IRC or a mail to ruby-talk constitutes
"constructive criticism".

Is there some kind of rule that states that everyone who takes note of
what I said has to blow it out of proportion, assign intent to it that
wasn't present, and generally try to put words in my mouth?

Why do so many users never seem to bother to put in an ounce of
effort in looking at something for every pound of effort the author
puts into writing it in the first place?

It took me less than 60 seconds to download gruff, unpack it, and
notice that there is over 92K(!!) of tests. PLENTY of live testable
"documentation" right there. But instead of doing something like
that, your sense of entitlement made you think the above paragraph
was a good idea.

Lay off the caffeine. You're assuming an awful lot.

...Made slightly redundant by Gregory's replies, but I had to get it
off my chest...

You should have sat on it.

···

On Tue, Jul 17, 2007 at 07:49:16AM +0900, Ryan Davis wrote:

On Jul 15, 2007, at 09:26 , Chad Perrin wrote:

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Thomas McCauley: "The measure of a man's real character is what he would do
if he knew he would never be found out."

This might sound rude, but I don't intend it to be offensive.

What makes you think maintainers of weakly documented projects care
whether or not *you* use their software?

It really irks me when people whine about lack of documentation for
projects. Yes, it sucks, yes it makes it harder for general adoption
of projects, but that burden isn't necessarily on the original
developer's shoulders.

Free software is a gift. It's also a collaborative effort. If I
release an undocumented library and people who are skillful enough and
have sufficient time to read the source can make use of it, great. If
someone wants to help document the software to show appreciation for
my work and learn in the process, as well as provide a resource for
others, even better.

What people forget to consider or refuse to consider is that adding
features to software or fixing bugs benefits the developers directly.
Writing documentation *might* benefit them, but often the folks who
write these things are very busy and are already working on other
important things, so documentation doesn't get written.

It's fine to say "I don't have the time to learn this undocumented
lib" and move on to another one, but criticizing projects for not
being documented is a baseless argument. You're asking why volunteers
don't volunteer more of their time to make *your* life easier, instead
of helping things along or at least *shutting up* when you're not
happy.

I apologize for a mini-rant here, but users who think project
maintainers owe them something really suck.

···

On 7/15/07, Chad Perrin <perrin@apotheon.com> wrote:

> I'm sure that Geoffry would appreciate documentation patches.

Sure . . . just as soon as I figure out how to use the library. With the
information that's provided, I could probably sort out how to create
simplest-case line graphs, but beyond that I'd have to put real time into
it -- time I might prefer to spend on Scruffy, which it appears has
better documentation.

The above is a direct quote of yours, so I didn't put words in your mouth. I found it snide and rude because _it_is_snide_ so I didn't blow it out of proportion. At worst, I could be guilty of assigning intent, except, it really was your intent to be snide, wasn't it? That seems plain as day to the rest of us.

snide |snīd| |snaɪd| |snʌɪd|
adjective
1 derogatory or mocking in an indirect way : "snide remarks about my mother."
• (of a person) devious and underhanded : "a snide divorce lawyer."

snide
adjective
"at his final snide comment, she slapped him across the face"
disparaging, derogatory, deprecating, denigratory, insulting, contemptuous; mocking, taunting, sneering, scornful, derisive, sarcastic, spiteful, nasty, mean.

···

On Jul 16, 2007, at 17:05 , Chad Perrin wrote:

On Tue, Jul 17, 2007 at 07:49:16AM +0900, Ryan Davis wrote:

On Jul 15, 2007, at 09:26 , Chad Perrin wrote:

Is there some kind of rule that states that, when something like
RDoc is
available, library developers are disallowed from producing good
documentation? I'm constantly frustrated by the fact that many
libraries
figure a skeleton map of available methods constitutes
"documentation".

Is there some kind of rule that states that, when something is freely
made available to the public, the users are disallowed from being
polite? I'm constantly frustrated by the fact that many users figure
a scathing comment in IRC or a mail to ruby-talk constitutes
"constructive criticism".

Is there some kind of rule that states that everyone who takes note of
what I said has to blow it out of proportion, assign intent to it that
wasn't present, and generally try to put words in my mouth?

>> I'm sure that Geoffry would appreciate documentation patches.
>
>Sure . . . just as soon as I figure out how to use the library. With the
>information that's provided, I could probably sort out how to create
>simplest-case line graphs, but beyond that I'd have to put real time into
>it -- time I might prefer to spend on Scruffy, which it appears has
>better documentation.

This might sound rude, but I don't intend it to be offensive.

What makes you think maintainers of weakly documented projects care
whether or not *you* use their software?

This might sound rude, too, and I honestly don't intend it to be
offensive either:

If you think my statement implied that they should care whether or not
*I* use their software, you need to learn some reading comprehension
skills. I just answered the suggestion that I should contribute
documentation patches with some very concrete, real-world, reasonable
explanation for why that's unlikely -- even though I wish I *could*
submit documentation patches that easily.

What people forget to consider or refuse to consider is that adding
features to software or fixing bugs benefits the developers directly.
Writing documentation *might* benefit them, but often the folks who
write these things are very busy and are already working on other
important things, so documentation doesn't get written.

What I find most annoying about the whole situation is that tools like
RDoc were written specifically to ease the process of creating
documentation, to provide a solid beginning to that documentation so that
half the work is already done for someone that intimately knows the
software, but the end result is that many people seem to think that *is*
the documentation and never bother finishing the job. Documentation is
an important part of any development effort -- almost as important as the
software itself. Documentation is important for the same reason readable
code is important, and yet people who will argue for days on end about
the best way to eke that last bit of readability out of code will turn
around and go on producing software without even the most rudimentary
attempt to make documentation clear and useful.

Why bother creating a website with screenshots, marketing-speak
glorifications of the software, a Sourceforge project to entice other
users, and a gem package for distribution, without even doing the minimal
documentation necessary to make it generally useful? Time would be
better spent writing some useful documentation than creating image
galleries and using CSS to produce color gradients on the webpage.

I understand my goals are not the same as everyone else's, but I find it
quite difficult to figure out what goals are served by this sort of
example of priorities.

It's fine to say "I don't have the time to learn this undocumented
lib" and move on to another one, but criticizing projects for not
being documented is a baseless argument. You're asking why volunteers
don't volunteer more of their time to make *your* life easier, instead
of helping things along or at least *shutting up* when you're not
happy.

This got blown far out of proportion from the intent of my previous
statements, thanks to comments about "whining" and passive-aggressive
insinuations that I should produce documentation or just enjoy the
software without any documentation.

I apologize for a mini-rant here, but users who think project
maintainers owe them something really suck.

I don't think project maintainers owe me something. I think failing
utterly to produce useful documentation is kind of a strange trend to see
in languages that come with excellent documentation tools, and I think
that my time is better spent using Scruffy (which has better
documentation) unless I want to actually become the Gruff project
maintainer myself. You're the one that assigned value judgments, whining
tone, and an attitude of entitlement to what I said -- not me.

I think people who put words in my mouth really suck.

···

On Mon, Jul 16, 2007 at 01:53:25AM +0900, Gregory Brown wrote:

On 7/15/07, Chad Perrin <perrin@apotheon.com> wrote:

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
They always say that when life gives you lemons you should make lemonade.
I always wonder -- isn't the lemonade going to suck if life doesn't give
you any sugar?

>>
>>
>>>Is there some kind of rule that states that, when something like
>>>RDoc is
>>>available, library developers are disallowed from producing good
>>>documentation? I'm constantly frustrated by the fact that many
>>>libraries
>>>figure a skeleton map of available methods constitutes
>>>"documentation".
>>
>>Is there some kind of rule that states that, when something is freely
>>made available to the public, the users are disallowed from being
>>polite? I'm constantly frustrated by the fact that many users figure
>>a scathing comment in IRC or a mail to ruby-talk constitutes
>>"constructive criticism".
>
>Is there some kind of rule that states that everyone who takes note of
>what I said has to blow it out of proportion, assign intent to it that
>wasn't present, and generally try to put words in my mouth?

The above is a direct quote of yours, so I didn't put words in your
mouth. I found it snide and rude because _it_is_snide_ so I didn't
blow it out of proportion. At worst, I could be guilty of assigning
intent, except, it really was your intent to be snide, wasn't it?
That seems plain as day to the rest of us.

See above, re: what *you* said about my words -- which, by the way, do
not reflect my intent or the necessary interpretation of my words at all.

snide |sn??d| |sna??d| |sn???d|
adjective
1 derogatory or mocking in an indirect way : "snide remarks about my
mother."
??? (of a person) devious and underhanded : "a snide divorce lawyer."

That was ironic.

···

On Tue, Jul 17, 2007 at 10:24:19AM +0900, Ryan Davis wrote:

On Jul 16, 2007, at 17:05 , Chad Perrin wrote:
>On Tue, Jul 17, 2007 at 07:49:16AM +0900, Ryan Davis wrote:
>>On Jul 15, 2007, at 09:26 , Chad Perrin wrote:

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
McCloctnick the Lucid: "The first rule of magic is simple. Don't waste your
time waving your hands and hopping when a rock or a club will do."

I think many developers underestimate the significance of documentation
to projects. Of course, most of us have at least some practice figuring
things out without documentation, reading source, and so on...

But putting in a few years as a writer leaves me more concerned with
documentation than I used to be. I'll say that much.

-s

···

In message <20070715212911.GC18755@demeter.hydra>, Chad Perrin writes:

RDoc were written specifically to ease the process of creating
documentation, to provide a solid beginning to that documentation so that
half the work is already done for someone that intimately knows the
software, but the end result is that many people seem to think that *is*
the documentation and never bother finishing the job. Documentation is
an important part of any development effort -- almost as important as the
software itself. Documentation is important for the same reason readable
code is important, and yet people who will argue for days on end about
the best way to eke that last bit of readability out of code will turn
around and go on producing software without even the most rudimentary
attempt to make documentation clear and useful.

You're right. What I said came off as harsh and rude, and I apologize
for that. I actually was more springboarding into the general field
of complaints I hear about Ruby libs not being properly documented,
and I shouldn't have made it seem like I was directing that
frustration at you.

That having been said, undocumented software can be useful to those
who are willing to read the source. Usually, unit tests are very
illuminating so long as they exist, and if some examples are
distributed with the source, that's enough to get going. I really
wish that users would contribute more documentation to projects,
because often maintainers simply don't have the time.

So I suppose what I'm saying is that users should meet maintainers
half way. When that doesn't happen, documentation doesn't get
written. For example... you could probably help out gruff enormously
by asking relevant questions about things you cannot figure out easily
from the API docs. But if you have no time for that, well, that's
understandable. But I feel like all of us are only entitled to get
back what we put in.

Again, sorry for flipping out before, it was unwarranted.

-greg

···

On 7/15/07, Chad Perrin <perrin@apotheon.com> wrote:

I don't think project maintainers owe me something. I think failing
utterly to produce useful documentation is kind of a strange trend to see
in languages that come with excellent documentation tools, and I think
that my time is better spent using Scruffy (which has better
documentation) unless I want to actually become the Gruff project
maintainer myself. You're the one that assigned value judgments, whining
tone, and an attitude of entitlement to what I said -- not me.

I think people who put words in my mouth really suck.

Chad Perrin wrote:

??? (of a person) devious and underhanded : "a snide divorce lawyer."

That was ironic.

There are non-snide divorce lawyers?

Peter Seebach wrote:

I think many developers underestimate the significance of documentation
to projects. Of course, most of us have at least some practice figuring
things out without documentation, reading source, and so on...

But putting in a few years as a writer leaves me more concerned with
documentation than I used to be. I'll say that much.
  

+1. I did my time, too, helping document a C compiler/linker on a system that had never had a C compiler/linker before. Then I worked in a publications department for 3 years and got to see the other side, how developers (generally) treat writers, which is to say, not well. This left me with much more respect for the writer's point-of-view. A dedicated and skilled writer can do a lot to make the software successful.

Hobbyist software does not require documentation. Developers are certainly free to simply throw it over the wall and say "here, take it or leave it." But users are also free to evaluate the software by the quality of its documentation.

···

--
RMagick OS X Installer [http://rubyforge.org/projects/rmagick/\]
RMagick Hints & Tips [http://rubyforge.org/forum/forum.php?forum_id=1618\]
RMagick Installation FAQ [http://rmagick.rubyforge.org/install-faq.html\]

>RDoc were written specifically to ease the process of creating
>documentation, to provide a solid beginning to that documentation so that
>half the work is already done for someone that intimately knows the
>software, but the end result is that many people seem to think that *is*
>the documentation and never bother finishing the job. Documentation is
>an important part of any development effort -- almost as important as the
>software itself. Documentation is important for the same reason readable
>code is important, and yet people who will argue for days on end about
>the best way to eke that last bit of readability out of code will turn
>around and go on producing software without even the most rudimentary
>attempt to make documentation clear and useful.

I think many developers underestimate the significance of documentation
to projects. Of course, most of us have at least some practice figuring
things out without documentation, reading source, and so on...

True. It's a shame that there isn't better documentation for some
projects, however -- especially since that often means someone will go
use something else (with better documentation) instead. While I could
eventually puzzle out how to use Gruff effectively, for instance, I'd
rather have something with good documentation at my fingertips than have
to pore over source code just for a trivial use of the library.

Since I've been accused of something akin to solipsism before in this
discussion, I'll be clear: I'm not saying that I, personally, am an
important user to whom developers must cater. Read my personal
experience as a symptom of a deeper problem with the lack of quality
documentation, please.

But putting in a few years as a writer leaves me more concerned with
documentation than I used to be. I'll say that much.

Writing what amounts to tutorial documentation for money in the last few
years has certainly improved my understanding of the importance of
documentation -- but I think the biggest change to my perspective is in
the fact that I'm using libraries much more these days than I used to,
and thus finding poor library documentation far more problematic than I
used to.

···

On Mon, Jul 16, 2007 at 06:34:22AM +0900, Peter Seebach wrote:

In message <20070715212911.GC18755@demeter.hydra>, Chad Perrin writes:

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Marvin Minsky: "It's just incredible that a trillion-synapse computer could
actually spend Saturday afternoon watching a football game."