View mode: basic / threaded / horizontal-split · Log in · Help
March 05, 2011
Plot2kill 0.2
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.
March 05, 2011
Re: Plot2kill 0.2
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
March 05, 2011
Re: Plot2kill 0.2
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.
March 05, 2011
Re: Plot2kill 0.2
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
March 05, 2011
Re: Plot2kill 0.2
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).
March 05, 2011
Re: Plot2kill 0.2
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/
March 05, 2011
Re: Plot2kill 0.2
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
March 05, 2011
Re: Plot2kill 0.2
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]);
> }
>
March 05, 2011
Re: Plot2kill 0.2
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.
March 05, 2011
Re: Plot2kill 0.2
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/
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home