I've done some major updating of my Plot2kill plotting library lately, such that I thought it was worth posting an announcement and calling it version 0.2.  The code is at http://dsource.org/projects/plot2kill/wiki .  The documentation unfortunately won't compile due to DMD Bug 5704 (http://d.puremagic.com/issues/show_bug.cgi?id=5704).

New features/improvements:

Box Plots

Grouped Bar Plots

X and Y tick labels can be rotated

Legends

Better tick label drawing heuristics

Several settings (Labels, legends, zoom, fonts, tick labels and settings) exposed in GTK default plot window GUI.

A new sample image is located at: http://dsource.org/projects/plot2kill/browser/docs/sp.png   Note that some of the plots look a little weird because they're so compacted. Rest assured, they look better when you zoom in.

For those who aren't familiar with it, Plot2kill supports both gtkD and DFL.  I've put the DFL port in maintenance mode.  It still works, but I won't be backporting any of the GUI-specific changes anytime soon.  This is mostly because DFL has a few key limitations that would make this port second-rate compared to the GTK port no matter what.  The most important ones are lack of support for non-Windows OS's and lack of an easy way to save in vector formats.  Furthermore, DFL has bit rotted such that it doesn't even compile without some modifications on DMD 2.052.

On Sat, 05 Mar 2011 13:09:15 -0500, dsimcha wrote:

> I've done some major updating of my Plot2kill plotting library lately, such that I thought it was worth posting an announcement and calling it version 0.2.

Cool! :)  I'll be sure to try it out.

> [...]
> 
> For those who aren't familiar with it, Plot2kill supports both gtkD and DFL.  I've put the DFL port in maintenance mode.  It still works, but I won't be backporting any of the GUI-specific changes anytime soon.  This is mostly because DFL has a few key limitations that would make this port second-rate compared to the GTK port no matter what.  The most important ones are lack of support for non-Windows OS's and lack of an easy way to save in vector formats.  Furthermore, DFL has bit rotted such that it doesn't even compile without some modifications on DMD 2.052.

Does this mean that it can save to vector formats now, or just that you intend to add that functionality?  EPS would be awesome, because it's pretty much the only thing you can use directly with LaTeX.  (Yes, pdfLaTeX accepts many other formats, but many scientific journals still require you to provide EPS figures.)

Of course, one can usually convert losslessly between the various vector formats, but it would be most convenient if Plot2kill could save directly to EPS, PDF and SVG.

-Lars

On 3/5/2011 1:27 PM, Lars T. Kyllingstad wrote:
> Does this mean that it can save to vector formats now, or just that you
> intend to add that functionality?  EPS would be awesome, because it's
> pretty much the only thing you can use directly with LaTeX.  (Yes,
> pdfLaTeX accepts many other formats, but many scientific journals still
> require you to provide EPS figures.)
>
> Of course, one can usually convert losslessly between the various vector
> formats, but it would be most convenient if Plot2kill could save directly
> to EPS, PDF and SVG.
>
> -Lars

?????  Plot2kill (the GTK version) has been able to save to EPS, SVG, PDF, PNG, JPEG and BMP since I switched the GTK port to use the Cairo backend last July.  (The DFL port can only do BMP and PNG.)  If this is a killer feature for you, I apologize for not publicizing it more back then.  I've been eating my own dogfood since then.  All of the graphs in my Ph.D. proposal and a publication manuscript I'm working on are Plot2Kill rendered and saved in vector formats.

dsimcha:

> I've done some major updating of my Plot2kill plotting library lately,

I see code that wants named arguments :-)

65 	    auto sleepinessFig = Figure(sleepinessPlot)
66 	        .title("Sleepiness Survey")
67 	        .yLabel("Sleepiness Rating")
68 	        .xLabel("Activity")
69 	        .legendLocation(LegendLocation.right)
70 	        .horizontalGrid(true)
71 	        .xTickLabels(
72 	            iota(3),
73 	            ["In Meeting", "On Phone", "Coding"]
74 	        );

Bye,
bearophile

On Sat, 05 Mar 2011 13:42:32 -0500, bearophile <bearophileHUGS@lycos.com> wrote:

> dsimcha:
>
>> I've done some major updating of my Plot2kill plotting library lately,
>
> I see code that wants named arguments :-)
>
> 65 	    auto sleepinessFig = Figure(sleepinessPlot)
> 66 	        .title("Sleepiness Survey")
> 67 	        .yLabel("Sleepiness Rating")
> 68 	        .xLabel("Activity")
> 69 	        .legendLocation(LegendLocation.right)
> 70 	        .horizontalGrid(true)
> 71 	        .xTickLabels(
> 72 	            iota(3),
> 73 	            ["In Meeting", "On Phone", "Coding"]
> 74 	        );
>
> Bye,
> bearophile

Why? Each of those arguments should be able to be set after creation. So given DRY principals, method chaining is the way to go. Besides, Figure takes a variable number of plot arguments, which means you couldn't support default arguments (at least with the current syntax).

On 2011-03-05 15:22:15 -0500, "Robert Jacques" <sandford@jhu.edu> said:

> On Sat, 05 Mar 2011 13:42:32 -0500, bearophile <bearophileHUGS@lycos.com>  wrote:
> 
>> dsimcha:
>> 
>>> I've done some major updating of my Plot2kill plotting library lately,
>> 
>> I see code that wants named arguments :-)
>> 
>> 65 	    auto sleepinessFig = Figure(sleepinessPlot)
>> 66 	        .title("Sleepiness Survey")
>> 67 	        .yLabel("Sleepiness Rating")
>> 68 	        .xLabel("Activity")
>> 69 	        .legendLocation(LegendLocation.right)
>> 70 	        .horizontalGrid(true)
>> 71 	        .xTickLabels(
>> 72 	            iota(3),
>> 73 	            ["In Meeting", "On Phone", "Coding"]
>> 74 	        );
>> 
>> Bye,
>> bearophile
> 
> Why? Each of those arguments should be able to be set after creation. So  given DRY principals, method chaining is the way to go. Besides, Figure  takes a variable number of plot arguments, which means you couldn't  support default arguments (at least with the current syntax).

The funny thing is what will happen to this code once @property is properly implemented? I think this is a cleaner way to write the above, and it'll work with @property:

	auto sleepinessFig = Figure(sleepinessPlot);
	with (sleepinessFig) {
		title = "Sleepiness Survey";
		yLabel = "Seeliness Rating";
		xLabel = "Activity";
		legendLocation = LegendLocation.right;
		horizontalGrid = true;
		xTickLabels(iota(3), ["In meeting, "On Phone", "Coding]);
	}

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Robert Jacques:

> Why?

Because that syntax works, but it's a little brutal.


> Each of those arguments should be able to be set after creation.

Then call again a method of Figure that takes arguments for changes after creation:

auto sleepinessFig = Figure(args...);
sleepinessFig.modify(args...);


> Besides, Figure takes a variable number of plot arguments, which means you couldn't support default arguments (at least with the current syntax).

I see. Something to try to design for D3.

Bye,
bearophile

This is why I don't want to see @property fully implemented.  Ever.  I love this method chaining stuff and you can pry it out of my cold, dead hands.  There was a discussion about this a long time ago when I was writing the first version of Plot2kill that gave me the impression that @property was to be used for disambiguation only.  (See http://www.digitalmars.com/d/archives/digitalmars/D/Overloading_property_vs._non-property_113421.html .)

The problem with the with statement idea is that you still need to declare the variable.  I often throw up quick anonymous plots with anonymous Figure objects, like:

Histogram(someDataSet).toFigure
    .title("A Title")
    .xLabel("Stuff")
    .showAsMain();

I consider the ability to have the same function be called with both syntaxes to be a beautiful thing, not a defect.  If @property is ever fully implemented, I'll nag for an @optionalproperty tag to bring back this **feature**.

On 3/5/2011 3:30 PM, Michel Fortin wrote:
> On 2011-03-05 15:22:15 -0500, "Robert Jacques" <sandford@jhu.edu> said:
>
>> On Sat, 05 Mar 2011 13:42:32 -0500, bearophile
>> <bearophileHUGS@lycos.com> wrote:
>>
>>> dsimcha:
>>>
>>>> I've done some major updating of my Plot2kill plotting library lately,
>>>
>>> I see code that wants named arguments :-)
>>>
>>> 65 auto sleepinessFig = Figure(sleepinessPlot)
>>> 66 .title("Sleepiness Survey")
>>> 67 .yLabel("Sleepiness Rating")
>>> 68 .xLabel("Activity")
>>> 69 .legendLocation(LegendLocation.right)
>>> 70 .horizontalGrid(true)
>>> 71 .xTickLabels(
>>> 72 iota(3),
>>> 73 ["In Meeting", "On Phone", "Coding"]
>>> 74 );
>>>
>>> Bye,
>>> bearophile
>>
>> Why? Each of those arguments should be able to be set after creation.
>> So given DRY principals, method chaining is the way to go. Besides,
>> Figure takes a variable number of plot arguments, which means you
>> couldn't support default arguments (at least with the current syntax).
>
> The funny thing is what will happen to this code once @property is
> properly implemented? I think this is a cleaner way to write the above,
> and it'll work with @property:
>
> auto sleepinessFig = Figure(sleepinessPlot);
> with (sleepinessFig) {
> title = "Sleepiness Survey";
> yLabel = "Seeliness Rating";
> xLabel = "Activity";
> legendLocation = LegendLocation.right;
> horizontalGrid = true;
> xTickLabels(iota(3), ["In meeting, "On Phone", "Coding]);
> }
>

BTW, my proposal for the @property debacle is the following:

1.  Getter @property functions **must** be called without ()s and the compiler may use this to disambiguate things like function pointer/delegate returns, etc.  Functions not marked @property **may** be called without ()s and in all respects the status quo is preserved (whatever that is--I don't know or care what it is in the weird corner cases) w.r.t. non-@property functions.

2.  Setter @property functions **must** be called with a.property = b and the compiler may use this to disambiguate corner cases.  Again, the status quo is preserved for functions not marked as such.

On 2011-03-05 16:30:06 -0500, dsimcha <dsimcha@yahoo.com> said:

> The problem with the with statement idea is that you still need to declare the variable.  I often throw up quick anonymous plots with anonymous Figure objects, like:
> 
> Histogram(someDataSet).toFigure
>      .title("A Title")
>      .xLabel("Stuff")
>      .showAsMain();

But does 'with' really need a variable name? Wouldn't that work?

	with (Histogram(someDataSet).toFigure()) {
		title = "A Title";
		xLabel = "Stuff";
		showAsMain();
	}

I'd even say it's more readable this way since you're now using '=' to set your properties.


> I consider the ability to have the same function be called with both syntaxes to be a beautiful thing, not a defect.  If @property is ever fully implemented, I'll nag for an @optionalproperty tag to bring back this **feature**.

I've always been on the fence about this. I find it useful too, and I like the visual effect of optional parenthesis. But returning anything that is callable make things ambiguous to the reader and can even bring bugs when it comes to generic programming; and ambiguity and bugs are things I really don't want to see.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/