matplotlib-users Mailing List for matplotlib

On 10/18/12 5:45 AM, Damon McDougall wrote:
> On Thu, Oct 18, 2012 at 10:10 AM, Alexander Eberspaecher
> <ale...@ov...> wrote:
>> Hello,
>>
>> On 2012年10月17日 11:38:27 +0100
>> Damon McDougall <dam...@gm...> wrote:
>>
>>> How do people feel about perhaps adding a matplotlib version, mocking
>>> the same calling signature as graph?
>>>
>>> I think the most important question is: would it be useful?
>> Yes, this would certainly be useful! I think there are people
>> unfamiliar with Python, but rather excited about MPL's plotting
>> capabilities.
>>
>> I personally would want it to read data from white-space separated text
>> files (np.loadtxt()), probably CSV files, and HDF5 files (e.g. using
>> h5py, if available).
>>
>> To be useful for different purposes, I'd want the tool to be able to use
>> different backends (producing e.g. PNG output in case you need a figure
>> to send via e-mail or PGF output in case you are preparing a LaTeX
>> document). Matplotlibrc should be hidden from the user.
>>
>> As Gnuplot was specifically mentioned in another e-mail in this thread,
>> let me use that opportunity to mention that MPL falls behind Gnuplot in
>> terms of line styles. Using MPL, I found ls="-" and maybe ls="--" to be
>> useful, whereas Gnuplot offers 9 linestyles that are easy to
>> distinguish visually. Compare e.g. the figure linked in
>> http://www.der-schnorz.de/2010/09/gnuplot-colors-presentations-papers-and-contrast/
>> In case this is of general interest, we might discuss that in a new
>> thread.
>>
>> As a side note, personally, for text file visualisation, I often use
>> this dirty MPL plotting plugin for the text editor of my choice (Geany):
>> https://github.com/aeberspaecher/GeanyPlot
>> A command line tool would of course be preferred.
>>
>> Cheers
>>
>> Alex
> Ok wow, awesome feedback! I started on this yesterday morning to see
> how it would go, and I've already got something working that mimics
> the command-line syntax of GNU's `graph` (except it currently only
> supports one data file as input).
>
> I'm currently just developing on a local feature branch in the
> matplotlib repository, but I'm happy to pull it out to a different
> repo and announce it here once I make some more ground on it. I
> haven't pushed anything yet. If I do I'll make an announcement here.
>
> One thing I have noticed is that GNU's `graph` is rather fast.
> Compared to matplotlib, GNU's `graph` blows matplotlib out of the
> water when it comes to speed. Though, in my opinion, matplotlib wins
> when it comes to output quality. As far as I'm concerned, quality wins
> over speed but I realise that there needs to be some speed
> improvements in matplotlib's backends. I have noticed that text takes
> quite a while to process in the backend (currently using Agg for PDF
> and PNG output).
>
> Regarding input data file-type, I agree, supporting those formats
> would expand our userbase considerably. There are already some helper
> functions in matplotlib.cbook for reading csv-type files. One downside
> of supporting lots of different file-types is that there will be more
> (optional) dependencies.
>
>
Along these lines, it would be nice to have some built in data sets to 
show off matplotlib's features--maybe just another library with a bunch 
of CSV strings, or lists. I am thinking of the built-in data sets for R 
that allow a new user to experiment without having to make up data each 
time. Although, I see that already I am suggesting more unneeded 
complexities into something that should be simple. Just a thought.
Paul

On Thu, Oct 18, 2012 at 8:13 PM, Mark Lawrence <bre...@ya...> wrote:
> On 18/10/2012 12:54, Alexander Eberspaecher wrote:
>> On 2012年10月18日 10:45:24 +0100
>> Damon McDougall <dam...@gm...> wrote:
>>
>>
>> Using e.g. optparse, multiple data files shouldn't be too complicated.
>>
>
> For the record optparse is deprecated so use argparse. This might also
> be helpful http://www.youtube.com/watch?v=pXhcPJK5cMc, my apologies if
> it's already been mentioned.
>
> --
> Cheers.
>
> Mark Lawrence.
Oh. My. God. That is unworldly.
\begin{opinons}
optparse is awful, and deprecated
argparse is better, but has *serious* limitations
getopt is also pretty bad
\end{opinions}
Thank you *so* much for posting that.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On 2012年10月18日 8:54 AM, Michael Aye wrote:
> On 2012年10月18日 05:58:46 +0000, Eric Firing said:
>
>> On 2012年10月17日 6:13 PM, Michael Aye wrote:
>>> I am using matplotlib 1.1.0 that came with the current EPD, which in
>>> turn comes without pygtk.
>>>
>>> However, the linux system I am using this on (CentOS6) has pygtk installed:
>>>
>>> /usr/lib64/pygtk/2.0
>>>
>>> Is there any change I can marry those two? Currently, when I try to
>>> matplotlib.use('gtk')
>>> I get an error
>>> ImportError("Gtk* backend requires pygtk to be installed.")
>>>
>>> Or do I need to recompile it into this matplotlib?
>>
>> Yes, you need to recompile. It will need to compile _backend_gdk.c,
>> which needs to be able to find pygtk.h.
>>
>> The plain (non-agg) gtk backend is basically unmaintained and its use is
>> discouraged.
>
> And the GTKAgg backend would have the same constraints as my current
> WxAgg, correct?
Correct. I take it you have tried with WxAgg, and run into the limitation?
>
>> Are you sure there isn't a reasonably easy way to do what
>> you need with qt4agg, for example? How do you want to visualize your
>> million points?
>
> Obviously there isn't place for displaying 1 million points, so I would
> expect the backend to do averaging/rebinninig/down-sampling of my data,
> depending on the current zoom level, meaning when I zoom in, it should
> repeat the averaging/rebinning/downsampling, optimized for the
> currently displayed data range. I'm aware and very willing to accept
> the delays this implies for display, but this would still be so much
> more comfortable then to write my own downsampling routines.
> I would believe that many believe would agree to the simplest averaging
> routines, if only it would be possible to display large data sets at
> all.
Mpl does some of this, for some plot types, at two levels. One is path 
simplification, in which points on a line that don't change the way the 
line would be displayed are deleted before being fed to agg. The second 
is slicing in the x domain when plotting a small range of a long time 
series. Both of these things are quite general and impose little or no 
penalty.
We are certainly open to suggestions for additional ways of handling 
large data sets, but finding methods that are general, fast, and 
guaranteed not to change the plot in a visually detectable way is not 
trivial.
I suspect a solution might be to provide a hook for a data subsetting 
callable, which could be supplied via a kwarg. This would allow the 
user to set the resolution versus speed tradeoff, to choose averaging 
versus subsampling, etc. mpl might then provide a few such callables, 
probably as classes with a __call__ method, and the user would be free 
to provide a custom callable optimized for a particular type of data and 
plot.
Eric
>
> Michael
>
>
>>
>> Eric
>>
>>>
>>> Thanks for your help!
>>>
>>> Michael
>>>
>>> PS.: The reason why I want to try GTK is actually that there are
>>> reports of it being able to cope with 1 million data points, something
>>> all other Agg-related backends can not do, apparently. (My linux is
>>> server is definitely not the limit ;)

On 18/10/2012 12:54, Alexander Eberspaecher wrote:
> On 2012年10月18日 10:45:24 +0100
> Damon McDougall <dam...@gm...> wrote:
>
>
> Using e.g. optparse, multiple data files shouldn't be too complicated.
>
For the record optparse is deprecated so use argparse. This might also 
be helpful http://www.youtube.com/watch?v=pXhcPJK5cMc, my apologies if 
it's already been mentioned.
-- 
Cheers.
Mark Lawrence.

On 2012年10月18日 05:58:46 +0000, Eric Firing said:
> On 2012年10月17日 6:13 PM, Michael Aye wrote:
>> I am using matplotlib 1.1.0 that came with the current EPD, which in
>> turn comes without pygtk.
>> 
>> However, the linux system I am using this on (CentOS6) has pygtk installed:
>> 
>> /usr/lib64/pygtk/2.0
>> 
>> Is there any change I can marry those two? Currently, when I try to
>> matplotlib.use('gtk')
>> I get an error
>> ImportError("Gtk* backend requires pygtk to be installed.")
>> 
>> Or do I need to recompile it into this matplotlib?
> 
> Yes, you need to recompile. It will need to compile _backend_gdk.c,
> which needs to be able to find pygtk.h.
> 
> The plain (non-agg) gtk backend is basically unmaintained and its use is
> discouraged.
And the GTKAgg backend would have the same constraints as my current 
WxAgg, correct?
> Are you sure there isn't a reasonably easy way to do what
> you need with qt4agg, for example? How do you want to visualize your
> million points?
Obviously there isn't place for displaying 1 million points, so I would 
expect the backend to do averaging/rebinninig/down-sampling of my data, 
depending on the current zoom level, meaning when I zoom in, it should 
repeat the averaging/rebinning/downsampling, optimized for the 
currently displayed data range. I'm aware and very willing to accept 
the delays this implies for display, but this would still be so much 
more comfortable then to write my own downsampling routines.
I would believe that many believe would agree to the simplest averaging 
routines, if only it would be possible to display large data sets at 
all.
Michael
> 
> Eric
> 
>> 
>> Thanks for your help!
>> 
>> Michael
>> 
>> PS.: The reason why I want to try GTK is actually that there are
>> reports of it being able to cope with 1 million data points, something
>> all other Agg-related backends can not do, apparently. (My linux is
>> server is definitely not the limit ;)
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> 
> 
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct

On Thu, Oct 18, 2012 at 2:09 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> Gökhan Sever <gok...@gm...>
> writes:
>
> > Another point I noticed is setting linewidth to 0 (in fill_between
> > function) isn't working as expected when figure is saved as a PDF
> > file.
>
> A workaround is to add edgecolor='None' to the fill_between call.
This workaround resolves the issue here. Thanks Jouni.

On 2012年10月18日 10:45:24 +0100
Damon McDougall <dam...@gm...> wrote:
> Ok wow, awesome feedback! I started on this yesterday morning to see
> how it would go, and I've already got something working that mimics
> the command-line syntax of GNU's `graph` (except it currently only
> supports one data file as input).
Great!
Using e.g. optparse, multiple data files shouldn't be too complicated.
I might need to look into GNU graph. I was ignorant about it's
existence till it was mentioned here on the MPL list.
> > I'm currently just developing on a local feature branch in the
> matplotlib repository, but I'm happy to pull it out to a different
> repo and announce it here once I make some more ground on it. I
> haven't pushed anything yet. If I do I'll make an announcement here.
Looking forward!
I think a separate repository might be the best option as you probably
do not want to modify MPL in any way, but rather build your scripts on
top of it.
> One thing I have noticed is that GNU's `graph` is rather fast.
> Compared to matplotlib, GNU's `graph` blows matplotlib out of the
> water when it comes to speed. Though, in my opinion, matplotlib wins
> when it comes to output quality. As far as I'm concerned, quality wins
> over speed but I realise that there needs to be some speed
> improvements in matplotlib's backends. I have noticed that text takes
> quite a while to process in the backend (currently using Agg for PDF
> and PNG output).
The good thing is that any command-line "frontend" certainly does not
need to care about backend specifics. The problem is completely
separable.
 
> Regarding input data file-type, I agree, supporting those formats
> would expand our userbase considerably. There are already some helper
> functions in matplotlib.cbook for reading csv-type files. One downside
> of supporting lots of different file-types is that there will be more
> (optional) dependencies.
I typically "try:" to import relevant packages and set a flag in case
that doesn't work. Using this approach, all dependencies really remain
optional.
> I think I should be able to make this public fairly soon. Furthermore,
> it will be trivial to install (copy and paste to the /usr/local/bin
> directory). The command-line utility is literally just a python script
> (with executable permissions) that parses command-line arguments and
> sets up plot and figure parameters. Of course, it may be the case in
> the future that it gets rather large and needs to be made more
> modular.
In case your approach looks right, I am pretty sure you'll find
contributors quickly.
 
Good luck!
Cheers
Alex

On Thu, Oct 18, 2012 at 10:10 AM, Alexander Eberspaecher
<ale...@ov...> wrote:
> Hello,
>
> On 2012年10月17日 11:38:27 +0100
> Damon McDougall <dam...@gm...> wrote:
>
>> How do people feel about perhaps adding a matplotlib version, mocking
>> the same calling signature as graph?
>>
>> I think the most important question is: would it be useful?
>
> Yes, this would certainly be useful! I think there are people
> unfamiliar with Python, but rather excited about MPL's plotting
> capabilities.
>
> I personally would want it to read data from white-space separated text
> files (np.loadtxt()), probably CSV files, and HDF5 files (e.g. using
> h5py, if available).
>
> To be useful for different purposes, I'd want the tool to be able to use
> different backends (producing e.g. PNG output in case you need a figure
> to send via e-mail or PGF output in case you are preparing a LaTeX
> document). Matplotlibrc should be hidden from the user.
>
> As Gnuplot was specifically mentioned in another e-mail in this thread,
> let me use that opportunity to mention that MPL falls behind Gnuplot in
> terms of line styles. Using MPL, I found ls="-" and maybe ls="--" to be
> useful, whereas Gnuplot offers 9 linestyles that are easy to
> distinguish visually. Compare e.g. the figure linked in
> http://www.der-schnorz.de/2010/09/gnuplot-colors-presentations-papers-and-contrast/
> In case this is of general interest, we might discuss that in a new
> thread.
>
> As a side note, personally, for text file visualisation, I often use
> this dirty MPL plotting plugin for the text editor of my choice (Geany):
> https://github.com/aeberspaecher/GeanyPlot
> A command line tool would of course be preferred.
>
> Cheers
>
> Alex
Ok wow, awesome feedback! I started on this yesterday morning to see
how it would go, and I've already got something working that mimics
the command-line syntax of GNU's `graph` (except it currently only
supports one data file as input).
I'm currently just developing on a local feature branch in the
matplotlib repository, but I'm happy to pull it out to a different
repo and announce it here once I make some more ground on it. I
haven't pushed anything yet. If I do I'll make an announcement here.
One thing I have noticed is that GNU's `graph` is rather fast.
Compared to matplotlib, GNU's `graph` blows matplotlib out of the
water when it comes to speed. Though, in my opinion, matplotlib wins
when it comes to output quality. As far as I'm concerned, quality wins
over speed but I realise that there needs to be some speed
improvements in matplotlib's backends. I have noticed that text takes
quite a while to process in the backend (currently using Agg for PDF
and PNG output).
Regarding input data file-type, I agree, supporting those formats
would expand our userbase considerably. There are already some helper
functions in matplotlib.cbook for reading csv-type files. One downside
of supporting lots of different file-types is that there will be more
(optional) dependencies.
Personally, when I just want to see statistics from a computational
run, I think I will find this rather helpful.
I think I should be able to make this public fairly soon. Furthermore,
it will be trivial to install (copy and paste to the /usr/local/bin
directory). The command-line utility is literally just a python script
(with executable permissions) that parses command-line arguments and
sets up plot and figure parameters. Of course, it may be the case in
the future that it gets rather large and needs to be made more
modular.
Right-o, back to more procrastinating. Thanks for all the encouragement! :)
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Hello,
On 2012年10月17日 11:38:27 +0100
Damon McDougall <dam...@gm...> wrote:
> How do people feel about perhaps adding a matplotlib version, mocking
> the same calling signature as graph?
> 
> I think the most important question is: would it be useful?
Yes, this would certainly be useful! I think there are people
unfamiliar with Python, but rather excited about MPL's plotting
capabilities.
I personally would want it to read data from white-space separated text
files (np.loadtxt()), probably CSV files, and HDF5 files (e.g. using
h5py, if available).
To be useful for different purposes, I'd want the tool to be able to use
different backends (producing e.g. PNG output in case you need a figure
to send via e-mail or PGF output in case you are preparing a LaTeX
document). Matplotlibrc should be hidden from the user.
As Gnuplot was specifically mentioned in another e-mail in this thread,
let me use that opportunity to mention that MPL falls behind Gnuplot in
terms of line styles. Using MPL, I found ls="-" and maybe ls="--" to be
useful, whereas Gnuplot offers 9 linestyles that are easy to
distinguish visually. Compare e.g. the figure linked in
http://www.der-schnorz.de/2010/09/gnuplot-colors-presentations-papers-and-contrast/
In case this is of general interest, we might discuss that in a new
thread.
As a side note, personally, for text file visualisation, I often use
this dirty MPL plotting plugin for the text editor of my choice (Geany):
https://github.com/aeberspaecher/GeanyPlot
A command line tool would of course be preferred.
Cheers
Alex

I totally agree with to general opinion that a command line tool would be beneficial.
I've written a simple mpl commandline plotter quite some time ago and use it frequently for
quick previews but also to create simple plots for presentations. It features some options to
modify the appearance just like GNU/graph.
If somebody wants to give it at try, I've attached the script.
br
Jakob
>> I was brain-storming yesterday and I wanted to test the waters to see
>> if people would find it useful.
>>
>> Currently, GNU plotutils comes with command-line utilities such as
>> `graph` to create quick and dirty line plots like this:
>> http://www.gnu.org/software/gsl/manual/html_node/DWT-Examples.html. I
>> think even gnuplot might be similar.
>>
>> How do people feel about perhaps adding a matplotlib version, mocking
>> the same calling signature as graph?
>>
>> I think the most important question is: would it be useful?

Jouni K. Seppänen <jk...@ik...> writes:
> Gökhan Sever <gok...@gm...>
> writes:
>
>> Another point I noticed is setting linewidth to 0 (in fill_between
>> function) isn't working as expected when figure is saved as a PDF
>> file.
>
> A workaround is to add edgecolor='None' to the fill_between call.
I filed an issue at https://github.com/matplotlib/matplotlib/issues/1412
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Gökhan Sever <gok...@gm...>
writes:
> Another point I noticed is setting linewidth to 0 (in fill_between
> function) isn't working as expected when figure is saved as a PDF
> file.
A workaround is to add edgecolor='None' to the fill_between call.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Benjamin Root <ben...@ou...> writes:
> On Wed, Oct 17, 2012 at 12:17 PM, Gökhan Sever
> <gok...@gm...>wrote:
>
>> Another point I noticed is setting linewidth to 0 (in fill_between
>> function) isn't working as expected when figure is saved as a PDF file.
>>
> Actually, this is not a bug in mpl. It is a "bug" in various viewers.
> Some viewers have a "minimum" linewidth and will use that for any requested
> linewidths smaller than that. Are you using Apple's Preview?
That's correct as per the pdf specification: a linewidth of zero means
the thinnest possible line on that device. That's why the pdf backend
attempts to not draw a line if the width is set to zero, but somehow
it's not working in this case. I'd call it a bug.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

I can certainly see the benefit. As Mike said, I don't think I would use it
myself, but I could see non-python users finding it useful.
Personally, I think this would be a nice extension that doesn't have to
live in the core matplotlib code base. That way release cycles and testing
can be done completely independently without complicating the matplotlib
repo.
Nice idea.
Phil
On 17 October 2012 16:20, Daπid <dav...@gm...> wrote:
> I also think that would be useful. It would, for example, allow to
> generate "preview" plots from other languages, without interfacing
> them to Python. It must be said that MPL is actually quite nice
> looking in the default settings for basic plotting, and this is an
> nice feature that can exploit.
>
> I have seen many pieces of code using SuperMongo for plotting. I find
> it absolutely ugly, and super expensive, but it is probably the easier
> plotting system to call from FORTRAN (or, at least, it was).
>
> On Wed, Oct 17, 2012 at 3:15 PM, Michael Droettboom <md...@st...>
> wrote:
> > I think this could be very useful -- and might help increase the user
> > base beyond the Python community. As I, and most of us on this list,
> > are quite comfortable with Python, I don't think I'd use it myself, but
> > I certainly see the utility of it.
> >
> > Mike
> >
> > On 10/17/2012 06:38 AM, Damon McDougall wrote:
> >> All,
> >>
> >> I was brain-storming yesterday and I wanted to test the waters to see
> >> if people would find it useful.
> >>
> >> Currently, GNU plotutils comes with command-line utilities such as
> >> `graph` to create quick and dirty line plots like this:
> >> http://www.gnu.org/software/gsl/manual/html_node/DWT-Examples.html. I
> >> think even gnuplot might be similar.
> >>
> >> How do people feel about perhaps adding a matplotlib version, mocking
> >> the same calling signature as graph?
> >>
> >> I think the most important question is: would it be useful?
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_sfd2d_oct
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

> If nothing speaks against it, i could do a pull request.
If you are willing, I would encourage you to do that, or at least make a
branch in your matplotlib fork and post the diff URL here. That way we can
discuss the pros & cons in-line, even if it means that we do no actually
merge the PR (that sounds bad, but really pull requests are a great medium
for discussing code).
Thanks!
Phil

On 2012年10月17日 6:13 PM, Michael Aye wrote:
> I am using matplotlib 1.1.0 that came with the current EPD, which in
> turn comes without pygtk.
>
> However, the linux system I am using this on (CentOS6) has pygtk installed:
>
> /usr/lib64/pygtk/2.0
>
> Is there any change I can marry those two? Currently, when I try to
> matplotlib.use('gtk')
> I get an error
> ImportError("Gtk* backend requires pygtk to be installed.")
>
> Or do I need to recompile it into this matplotlib?
Yes, you need to recompile. It will need to compile _backend_gdk.c, 
which needs to be able to find pygtk.h.
The plain (non-agg) gtk backend is basically unmaintained and its use is 
discouraged. Are you sure there isn't a reasonably easy way to do what 
you need with qt4agg, for example? How do you want to visualize your 
million points?
Eric
>
> Thanks for your help!
>
> Michael
>
> PS.: The reason why I want to try GTK is actually that there are
> reports of it being able to cope with 1 million data points, something
> all other Agg-related backends can not do, apparently. (My linux is
> server is definitely not the limit ;)
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

I am using matplotlib 1.1.0 that came with the current EPD, which in 
turn comes without pygtk.
However, the linux system I am using this on (CentOS6) has pygtk installed:
/usr/lib64/pygtk/2.0
Is there any change I can marry those two? Currently, when I try to
matplotlib.use('gtk')
I get an error
ImportError("Gtk* backend requires pygtk to be installed.")
Or do I need to recompile it into this matplotlib?
Thanks for your help!
Michael
PS.: The reason why I want to try GTK is actually that there are 
reports of it being able to cope with 1 million data points, something 
all other Agg-related backends can not do, apparently. (My linux is 
server is definitely not the limit ;)