gnuplot-py-users — A mailing list for the users of Gnuplot.py.

Re: [Gnuplot-py-users] is it possible to continue to Debug when figure is created??

[Sandy Y. <cd...@li...>]

I try to do it but installation seems to be complicated in Vista for beginner

 

for example 

what is it

3. Install by changing to the directory and typing "python setup.py
   install".

 

Installation
------------
 
Quick instructions:
 
1. Download gnuplot-py-1.8.tar.gz or gnuplot-py-1.8.zip.
 
2. Extract the archive to a temporary directory.
 
3. Install by changing to the directory and typing "python setup.py
   install".
 

 

or

 

 

 

.  So to run Gnuplot.py on Windows, you need to make sure that
pgnuplot.exe is installed.  

 

 

in

Installation on Windows
-----------------------
 
I don't run Windows, but thanks to the help of users there is now a
way to use Gnuplot.py on that platform.  Any feedback or additional
suggestions having to do with Windows would be especially appreciated.
 
Because the main MS-Windows gnuplot executable (wgnuplot.exe) doesn't
accept commands on standard input, Gnuplot.py cannot communicate with
it directly.  However, there is a simple little program called
`pgnuplot.exe' that accepts commands on stdin and passes them to
wgnuplot.  So to run Gnuplot.py on Windows, you need to make sure that
pgnuplot.exe is installed.  It comes with gnuplot since at least
version 3.7.1.  Alternatively you can get pgnuplot.exe alone by
downloading `testing/windows-stdin.zip' from one of the gnuplot
archives (e.g.,
<ftp://ftp.gnuplot.info/pub/gnuplot/testing/windows-stdin.zip>).
 
Continue installing Gnuplot.py by following the instructions in the
previous section.
 

 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

another question 

is it possilbe to use (see) simulataneusly several figures like in Matalb??

 

Sandy


 
> Date: Tue, 18 May 2010 10:13:24 -0400
> From: ai...@am...
> To: gnu...@li...
> Subject: Re: [Gnuplot-py-users] is it possible to continue to Debug when figure is created??
> 
> On 5/18/2010 9:47 AM, Sandy Ydnas wrote:
> > NameError: name 'Gnuplot' is not defined
> 
> http://gnuplot-py.sourceforge.net/
> 
> hth,
> Alan Isaac
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Gnuplot-py-users mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-py-users
 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969

Re: [Gnuplot-py-users] is it possible to continue to Debug when figure is created??

[Benny M. <ben...@gm...>]

2010/5/18 Flavio Coelho <fcc...@gm...>

> Hi Allan,
>
> I am the author of Liveplots and it is quite an specific project, which
> happens to use Gnuplot.py as many other projects do. I don' see what benefit
> would come from joining the two. Though naturally, being open-source
> projects, they are free to share code as needed, so that there are no
> unnecessary duplication of development effort.
>

First, I have not looked at the liveplots code, only the blog posting.

I think there are probably many users of gnuplot.py that do the drawing in a
separate process, so as not to hold up the numerics (waiting for data to be
written, ...). Moving such a construct, with a queue system, inside of
Gnuplot would be benificial, so that users can have a basic version of that
without needing to bother about processes.

Benny



> cheers,
>
> Flávio
>
>
> On Tue, May 18, 2010 at 3:36 PM, Alan G Isaac <ai...@am...> wrote:
>
>> On 5/18/2010 9:58 AM, Flavio Coelho wrote:
>> > http://code.google.com/p/liveplots/
>>
>> Might making this part of Gnuplot.py be appropriate?
>>
>> Alan Isaac
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Gnuplot-py-users mailing list
>> Gnu...@li...
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-py-users
>>
>
>
>
> --
> Flávio Codeço Coelho
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Gnuplot-py-users mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-py-users
>
>

Re: [Gnuplot-py-users] is it possible to continue to Debug when figure is created??

[Flavio C. <fcc...@gm...>]

Hi Allan,

I am the author of Liveplots and it is quite an specific project, which
happens to use Gnuplot.py as many other projects do. I don' see what benefit
would come from joining the two. Though naturally, being open-source
projects, they are free to share code as needed, so that there are no
unnecessary duplication of development effort.

cheers,

Flávio

On Tue, May 18, 2010 at 3:36 PM, Alan G Isaac <ai...@am...> wrote:

> On 5/18/2010 9:58 AM, Flavio Coelho wrote:
> > http://code.google.com/p/liveplots/
>
> Might making this part of Gnuplot.py be appropriate?
>
> Alan Isaac
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Gnuplot-py-users mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-py-users
>



-- 
Flávio Codeço Coelho

Re: [Gnuplot-py-users] is it possible to continue to Debug when figure is created??

[Alan G I. <ai...@am...>]

On 5/18/2010 9:58 AM, Flavio Coelho wrote:
> http://code.google.com/p/liveplots/

Might making this part of Gnuplot.py be appropriate?

Alan Isaac

Re: [Gnuplot-py-users] is it possible to continue to Debug when figure is created??

[Alan G I. <ai...@am...>]

On 5/18/2010 9:47 AM, Sandy Ydnas wrote:
> NameError: name 'Gnuplot' is not defined

http://gnuplot-py.sourceforge.net/

hth,
Alan Isaac

Re: [Gnuplot-py-users] is it possible to continue to Debug when figure is created??

[Flavio C. <fcc...@gm...>]

Hi Sandy,

You error is due to the fact that you have not imported Gnuplot as you
should. So that snippet would become:

import Gnuplot
Gnuplot.GnuplotOpts.prefer_inline_data = 1
Gnuplot.GnuplotOpts.prefer_fifo_data = 0

Liveplots is free-software and you are welcome to use it if you find it
suits your needs. To install it, if you have setuptools installed, you
write:

easy_install liveplots

otherwise, just checkout the code, as explained here
https://code.google.com/p/liveplots/source/checkout, and run:

python setup.py install

these commands may be sligthly different depending on which operating system
you use.

Flávio


On Tue, May 18, 2010 at 2:47 PM, Sandy Ydnas <cd...@li...> wrote:

>
> Hi Flávio
> thank you very much for help
>
> if we use
>
> from numpy import *
>
> g  = Gnuplot.Gnuplot(persist=0)
>
> then
> NameError: name 'Gnuplot' is not defined
> File "C:\start_Feb_8\my_PY_code\May_18__gnuplot_answer_test_1.py", line 3,
> in <module>
>
>   g  = Gnuplot.Gnuplot(persist=0)
> as I mentioned I am very new in Python
> may I use you project [1]http://code.google.com/p/liveplots/
>
> but how to install it??
>
> Thank you very much in advance
> Sandy
>
> ------------------------------
> From: fcc...@gm...
> Date: Tue, 18 May 2010 10:25:18 +0100
> To: gnu...@li...
> Subject: Re: [Gnuplot-py-users] is it possible to continue to Debug when
> figure is created??
>
>
> Sandy,
>
> Like Michael said, You can turn off fifo data transfer and use inline with
> these lines:
>
> Gnuplot.GnuplotOpts.prefer_inline_data = 1
> Gnuplot.GnuplotOpts.prefer_fifo_data = 0
>
> I do this in Liveplots[1] and found that inlining data improved the
> performance enormously. Besides, since I use Python's multiprocessing module
> to plot data from children processes, FIFO did not work for me.
>
> Flávio
>
>
> [1]http://code.google.com/p/liveplots/
>
> On Tue, May 18, 2010 at 8:17 AM, Benny Malengier <
> ben...@gm...> wrote:
>
>
>
> 2010/5/18 Michael Haggerty <mh...@al...>
>
>  Sandy Ydnas wrote:
> > I am staring now to use Gnuplot under Python, since Matplotlib has
> > problem - it gets stuck during debugging after show().
> >
> > pls help understand is Gnuplot­­­ debugging friendly, it means is it
> > possible to continue to Debug when figure is created??
>
> I personally don't use pdb, but I don't know of any reason why it should
> be difficult to debug code that uses Gnuplot.py.  The only thing that
> occurs to me is that the use of FIFOs to communicate data to gnuplot
> currently requires the use of additional threads that write the data to
> the FIFO, and debugging multithreaded code might be tricky.  But the use
> of FIFOs is optional; you could configure Gnuplot.py to use temporary
> files or inline data instead.
>
> Please tell us what you find out!
>
>
> Use
> g  = Gnuplot.Gnuplot(persist=0)
> The persist=0 should allow you to easily jump over the code that does the
> figure.
>
> Benny
>
>
> Michael
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Gnuplot-py-users mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-py-users
>
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Gnuplot-py-users mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-py-users
>
>
>
>
> --
> Flávio Codeço Coelho
>
>
> ------------------------------
> Hotmail: Powerful Free email with security by Microsoft. Get it now.<https://signup.live.com/signup.aspx?id=60969>
>



-- 
Flávio Codeço Coelho

Re: [Gnuplot-py-users] is it possible to continue to Debug when figure is created??

[Sandy Y. <cd...@li...>]

 

Hi Flávio

thank you very much for help

 

if we use 

 

from numpy import *

g  = Gnuplot.Gnuplot(persist=0) 

 

then

NameError: name 'Gnuplot' is not defined
File "C:\start_Feb_8\my_PY_code\May_18__gnuplot_answer_test_1.py", line 3, in <module>
  g  = Gnuplot.Gnuplot(persist=0)
as I mentioned I am very new in Python

may I use you project [1]http://code.google.com/p/liveplots/


but how to install it??

 

Thank you very much in advance

Sandy
 


From: fcc...@gm...
Date: Tue, 18 May 2010 10:25:18 +0100
To: gnu...@li...
Subject: Re: [Gnuplot-py-users] is it possible to continue to Debug when figure is created??

Sandy,

Like Michael said, You can turn off fifo data transfer and use inline with these lines:

Gnuplot.GnuplotOpts.prefer_inline_data = 1
Gnuplot.GnuplotOpts.prefer_fifo_data = 0

I do this in Liveplots[1] and found that inlining data improved the performance enormously. Besides, since I use Python's multiprocessing module to plot data from children processes, FIFO did not work for me.

Flávio


[1]http://code.google.com/p/liveplots/


On Tue, May 18, 2010 at 8:17 AM, Benny Malengier <ben...@gm...> wrote:




2010/5/18 Michael Haggerty <mh...@al...>



Sandy Ydnas wrote:
> I am staring now to use Gnuplot under Python, since Matplotlib has
> problem - it gets stuck during debugging after show().
>
> pls help understand is Gnuplot­­­ debugging friendly, it means is it
> possible to continue to Debug when figure is created??

I personally don't use pdb, but I don't know of any reason why it should
be difficult to debug code that uses Gnuplot.py.  The only thing that
occurs to me is that the use of FIFOs to communicate data to gnuplot
currently requires the use of additional threads that write the data to
the FIFO, and debugging multithreaded code might be tricky.  But the use
of FIFOs is optional; you could configure Gnuplot.py to use temporary
files or inline data instead.

Please tell us what you find out!


Use
g  = Gnuplot.Gnuplot(persist=0) 
The persist=0 should allow you to easily jump over the code that does the figure.

Benny




Michael

------------------------------------------------------------------------------

_______________________________________________
Gnuplot-py-users mailing list
Gnu...@li...
https://lists.sourceforge.net/lists/listinfo/gnuplot-py-users


------------------------------------------------------------------------------


_______________________________________________
Gnuplot-py-users mailing list
Gnu...@li...
https://lists.sourceforge.net/lists/listinfo/gnuplot-py-users



-- 
Flávio Codeço Coelho

 		 	   		  
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
https://signup.live.com/signup.aspx?id=60969

Re: [Gnuplot-py-users] is it possible to continue to Debug when figure is created??

[Flavio C. <fcc...@gm...>]

Sandy,

Like Michael said, You can turn off fifo data transfer and use inline with
these lines:

Gnuplot.GnuplotOpts.prefer_inline_data = 1
Gnuplot.GnuplotOpts.prefer_fifo_data = 0

I do this in Liveplots[1] and found that inlining data improved the
performance enormously. Besides, since I use Python's multiprocessing module
to plot data from children processes, FIFO did not work for me.

Flávio


[1]http://code.google.com/p/liveplots/

On Tue, May 18, 2010 at 8:17 AM, Benny Malengier
<ben...@gm...>wrote:

>
>
> 2010/5/18 Michael Haggerty <mh...@al...>
>
> Sandy Ydnas wrote:
>> > I am staring now to use Gnuplot under Python, since Matplotlib has
>> > problem - it gets stuck during debugging after show().
>> >
>> > pls help understand is Gnuplot­­­ debugging friendly, it means is it
>> > possible to continue to Debug when figure is created??
>>
>> I personally don't use pdb, but I don't know of any reason why it should
>> be difficult to debug code that uses Gnuplot.py.  The only thing that
>> occurs to me is that the use of FIFOs to communicate data to gnuplot
>> currently requires the use of additional threads that write the data to
>> the FIFO, and debugging multithreaded code might be tricky.  But the use
>> of FIFOs is optional; you could configure Gnuplot.py to use temporary
>> files or inline data instead.
>>
>> Please tell us what you find out!
>>
>
> Use
> g  = Gnuplot.Gnuplot(persist=0)
> The persist=0 should allow you to easily jump over the code that does the
> figure.
>
> Benny
>
>
>> Michael
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Gnuplot-py-users mailing list
>> Gnu...@li...
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-py-users
>>
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Gnuplot-py-users mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-py-users
>
>


-- 
Flávio Codeço Coelho

Re: [Gnuplot-py-users] is it possible to continue to Debug when figure is created??

[Benny M. <ben...@gm...>]

2010/5/18 Michael Haggerty <mh...@al...>

> Sandy Ydnas wrote:
> > I am staring now to use Gnuplot under Python, since Matplotlib has
> > problem - it gets stuck during debugging after show().
> >
> > pls help understand is Gnuplot­­­ debugging friendly, it means is it
> > possible to continue to Debug when figure is created??
>
> I personally don't use pdb, but I don't know of any reason why it should
> be difficult to debug code that uses Gnuplot.py.  The only thing that
> occurs to me is that the use of FIFOs to communicate data to gnuplot
> currently requires the use of additional threads that write the data to
> the FIFO, and debugging multithreaded code might be tricky.  But the use
> of FIFOs is optional; you could configure Gnuplot.py to use temporary
> files or inline data instead.
>
> Please tell us what you find out!
>

Use
g  = Gnuplot.Gnuplot(persist=0)
The persist=0 should allow you to easily jump over the code that does the
figure.

Benny


> Michael
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Gnuplot-py-users mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-py-users
>

Re: [Gnuplot-py-users] is it possible to continue to Debug when figure is created??

[Michael H. <mh...@al...>]

Sandy Ydnas wrote:
> I am staring now to use Gnuplot under Python, since Matplotlib has
> problem - it gets stuck during debugging after show().
> 
> pls help understand is Gnuplot­­­ debugging friendly, it means is it
> possible to continue to Debug when figure is created??

I personally don't use pdb, but I don't know of any reason why it should
be difficult to debug code that uses Gnuplot.py.  The only thing that
occurs to me is that the use of FIFOs to communicate data to gnuplot
currently requires the use of additional threads that write the data to
the FIFO, and debugging multithreaded code might be tricky.  But the use
of FIFOs is optional; you could configure Gnuplot.py to use temporary
files or inline data instead.

Please tell us what you find out!

Michael

[Gnuplot-py-users] is it possible to continue to Debug when figure is created??

[Sandy Y. <cd...@li...>]

Hi freinds,

 

I am staring now to use Gnuplot under Python, since Matplotlib has problem - it gets stuck during debugging after show().
pls help understand is Gnuplot­­­ debugging friendly, it means is it possible to continue to Debug when figure is created??
Best Regards
Sandy   
 
 		 	   		  
_________________________________________________________________
Hotmail: Free, trusted and rich email service.
https://signup.live.com/signup.aspx?id=60969

Re: [Gnuplot-py-users] suggestion

[Benny M. <ben...@gm...>]

2010/5/3 Flavio Coelho <fcc...@gm...>

> Hi Benny,
>
> regarding the zipped egg, It can be avoided by setting the zip_safe
> argument  to False. However, since distutils.core setup function does not
> support this argument, we will need to have two calls to setup functions
> depending on the availability of setuptools, as in the example attached
> (Warning: Untested!).
>
> However, an even better solution solution to the handle personal
> configuration would be to have an configuration file in the users home
> directory which would be read and parsed by Gnuplot.py whenever it is
> imported (using the configparser module)
>

Yes. I see there is already a .gnuplot_history and a .gnuplot-wxt directory
present, so a .gnuplot-py or so can be added with optional Gnuplot.ini to
override configs.

I have committed the change to use setuptools in trunk. Using a config in
user directory can be added later. I will myself not upload to pypi, I think
somebody with an interest in maintaining that should do that. Also,
obviously there has been no release with this change.

Benny

>
> cheers,
>
> Flávio
>
>
> On Mon, May 3, 2010 at 8:52 AM, Benny Malengier <ben...@gm...
> > wrote:
>
>>
>>
>> 2010/5/2 Flavio Coelho <fcc...@gm...>
>>
>>>
>>>
>>> On Sun, May 2, 2010 at 12:53 PM, Benny Malengier <
>>> ben...@gm...> wrote:
>>>
>>>>
>>>>
>>>> 2010/5/2 Flavio Coelho <fcc...@gm...>
>>>>
>>>>
>>>>>
>>>>> On Sun, May 2, 2010 at 9:41 AM, Benny Malengier <
>>>>> ben...@gm...> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> 2010/4/26 Flavio Coelho <fcc...@gm...>
>>>>>>
>>>>>> Hi,
>>>>>>>
>>>>>>> I use Gnuplot.py in some of my projects, and would like to thank
>>>>>>> Michael for such a useful package.
>>>>>>>
>>>>>>> One of my projects, Liveplots[1], depends on Gnuplot.py, and uses
>>>>>>> setuptools (easy_install)[2] as its main mode of distribution. It would be
>>>>>>> very convenient for me, and possibly for other Gnuplot.py users, that is
>>>>>>> could also be installed by means of the easy_install command. This is
>>>>>>> important because other projects which want to declare Gnuplot.py as a
>>>>>>> dependency can do so by listing it in their setup.py and have it be
>>>>>>> installed automatically.
>>>>>>>
>>>>>>> To enable this, all that is required is to edit one line in the
>>>>>>> setup.py:
>>>>>>>
>>>>>>> where it reads "from distutils.core import setup"  it should read:
>>>>>>> "from setuptools import setup". After this, running "python setup.py sdist.
>>>>>>> register upload", will add Gnuplot.py to Python Package Index and make it
>>>>>>> easy_installable for users with setuptools installed.
>>>>>>>
>>>>>>> I should also point out, that this edit will not affect in any way
>>>>>>> how Gnuplot.py is currently used and installed, just add a new way to
>>>>>>> install it.
>>>>>>>
>>>>>>
>>>>>> This seems easy, but is it the correct way forward? I did not follow
>>>>>> all the dirt being thrown around with respect to building/installing python
>>>>>> pacages. I know there is a lot of controversies.
>>>>>> However, distutils remains supported in python core
>>>>>> http://docs.python.org/distutils/index.html#distutils-index
>>>>>>
>>>>>> so it is a part of python 3. People still seem to use it and advocate
>>>>>> it (eg http://diveintopython3.org/packaging.html ).
>>>>>>
>>>>>> So, why not use the core packages? If we go with setuptools, we could
>>>>>> also take pip or distribute...
>>>>>>
>>>>>
>>>>> I have followed some of the discussion regarding the fork of Distribute
>>>>> from setuptools, and the issues at the core where about how to make the
>>>>> package evolve towards being included in the standard library, not about its
>>>>> usefulness. Neither Setuptools or Distribute mean to replace distutils but
>>>>> to extend it. Making a setup.py compatible with setuptools or Distribute,
>>>>> does not affect the "python setup.py install" way of installing packages of
>>>>> distutils. But it allows for packages to declare a dependency tree of
>>>>> packages, which is not available in plain distutils.
>>>>>
>>>>> Moreover, most heavily used python packages have been using setuptools
>>>>> for years. So the bottom line is that adopting setuptools costs just a
>>>>> couple of line edits in setup.py while being  completely transparent to
>>>>> users accustomed to distutils. There's much to gain and nothing to loose.
>>>>>
>>>>>
>>>> So I assume you mean that gnuplot could use a  try except block for this
>>>> import, or would you aim at making setuptools a dependency?
>>>>
>>>
>>> Actually, setuptools has a bootstrap script  (ez_setup.py) which will
>>> download and install setuptools if it is not installed. But a try/except
>>> might also be a good idea since it wouldn't require any extra installation
>>> for those who download the source tarball manually. As for the ones
>>> installing via easy_install either directly or as a dependency this is not a
>>> problem since they've got to have setuptools installed to begin with.
>>>
>>>>
>>>> What is actually the standard about running
>>>>
>>>> python setup.py sdist. register upload
>>>> The main developer should do it? Problem is a bit that Michael still
>>>> replies mails to mailing list from time to time, but there is at the time
>>>> nobody with the time to actually hack at Gnuplot.py.
>>>>
>>>
>>> Anyone could do the "...sdist register upload", but  ideally it should be
>>> someone who is also involved with the official releases of Gnuplot.py so
>>> that the PyPI package is kept up-to-date. The person which uploads the
>>> initial package becomes the manager of the package in PyPI via their  login
>>> and password.
>>>
>>>
>>>> If you build on top of gnuplot, you might be interested in exposing some
>>>> of the new capabilities of gnuplot in the Gnuplot.py API?
>>>> It is great that we have the API to directly pass gnuplot commands, but
>>>> it does mean not many people are interested in expanding the API.
>>>>
>>>
>>> I have looked at the code of Gnuplot.py and found it to be very readable
>>> and easy to understand. So if I find the time to improve it, I'll certainly
>>> post a patch to this list for review.
>>>
>>>>
>>>> I don't mind doing this change in the code myself, I use an extension to
>>>> setuptools for one of my own projects, but I'd like Michael to agree with it
>>>> before adding it, as I have only done some very small contributions up to
>>>> now.
>>>>
>>>
>>> I think that the best way to go too.
>>>
>>
>> Ok, I tried it locally.
>> I have one issue only. There are some defaults in eg Gnuplot/gp_unix.py
>> and friends users might want to change.
>>
>> Using setuptools this installs as a zipped egg file however. Is there an
>> easy way to edit the installed egg? Or does it mean like this users must
>> install from source to be able to change a default setting? It seems like
>> that to me.
>>
>> I can work around it myself with
>>
>> sudo python setup.py install --single-version-externally-managed
>> --install-layout=deb --root /
>>
>> and packagers for ubuntu/... can use that instead of an egg, but people
>> using easy-install are stuck with our defaults it seems.
>>
>> Benny
>>
>>
>>>
>>> cheers,
>>>
>>> Flávio
>>>
>>>>
>>>> Benny
>>>>
>>>> cheers,
>>>>>
>>>>> Flávio
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Flávio Codeço Coelho
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Flávio Codeço Coelho
>>>
>>>
>>
>
>
> --
> Flávio Codeço Coelho
>
>

Re: [Gnuplot-py-users] suggestion

[Flavio C. <fcc...@gm...>]

Hi Benny,

regarding the zipped egg, It can be avoided by setting the zip_safe
argument  to False. However, since distutils.core setup function does not
support this argument, we will need to have two calls to setup functions
depending on the availability of setuptools, as in the example attached
(Warning: Untested!).

However, an even better solution solution to the handle personal
configuration would be to have an configuration file in the users home
directory which would be read and parsed by Gnuplot.py whenever it is
imported (using the configparser module)

cheers,

Flávio

On Mon, May 3, 2010 at 8:52 AM, Benny Malengier
<ben...@gm...>wrote:

>
>
> 2010/5/2 Flavio Coelho <fcc...@gm...>
>
>>
>>
>> On Sun, May 2, 2010 at 12:53 PM, Benny Malengier <
>> ben...@gm...> wrote:
>>
>>>
>>>
>>> 2010/5/2 Flavio Coelho <fcc...@gm...>
>>>
>>>
>>>>
>>>> On Sun, May 2, 2010 at 9:41 AM, Benny Malengier <
>>>> ben...@gm...> wrote:
>>>>
>>>>>
>>>>>
>>>>> 2010/4/26 Flavio Coelho <fcc...@gm...>
>>>>>
>>>>> Hi,
>>>>>>
>>>>>> I use Gnuplot.py in some of my projects, and would like to thank
>>>>>> Michael for such a useful package.
>>>>>>
>>>>>> One of my projects, Liveplots[1], depends on Gnuplot.py, and uses
>>>>>> setuptools (easy_install)[2] as its main mode of distribution. It would be
>>>>>> very convenient for me, and possibly for other Gnuplot.py users, that is
>>>>>> could also be installed by means of the easy_install command. This is
>>>>>> important because other projects which want to declare Gnuplot.py as a
>>>>>> dependency can do so by listing it in their setup.py and have it be
>>>>>> installed automatically.
>>>>>>
>>>>>> To enable this, all that is required is to edit one line in the
>>>>>> setup.py:
>>>>>>
>>>>>> where it reads "from distutils.core import setup"  it should read:
>>>>>> "from setuptools import setup". After this, running "python setup.py sdist.
>>>>>> register upload", will add Gnuplot.py to Python Package Index and make it
>>>>>> easy_installable for users with setuptools installed.
>>>>>>
>>>>>> I should also point out, that this edit will not affect in any way how
>>>>>> Gnuplot.py is currently used and installed, just add a new way to install
>>>>>> it.
>>>>>>
>>>>>
>>>>> This seems easy, but is it the correct way forward? I did not follow
>>>>> all the dirt being thrown around with respect to building/installing python
>>>>> pacages. I know there is a lot of controversies.
>>>>> However, distutils remains supported in python core
>>>>> http://docs.python.org/distutils/index.html#distutils-index
>>>>>
>>>>> so it is a part of python 3. People still seem to use it and advocate
>>>>> it (eg http://diveintopython3.org/packaging.html ).
>>>>>
>>>>> So, why not use the core packages? If we go with setuptools, we could
>>>>> also take pip or distribute...
>>>>>
>>>>
>>>> I have followed some of the discussion regarding the fork of Distribute
>>>> from setuptools, and the issues at the core where about how to make the
>>>> package evolve towards being included in the standard library, not about its
>>>> usefulness. Neither Setuptools or Distribute mean to replace distutils but
>>>> to extend it. Making a setup.py compatible with setuptools or Distribute,
>>>> does not affect the "python setup.py install" way of installing packages of
>>>> distutils. But it allows for packages to declare a dependency tree of
>>>> packages, which is not available in plain distutils.
>>>>
>>>> Moreover, most heavily used python packages have been using setuptools
>>>> for years. So the bottom line is that adopting setuptools costs just a
>>>> couple of line edits in setup.py while being  completely transparent to
>>>> users accustomed to distutils. There's much to gain and nothing to loose.
>>>>
>>>>
>>> So I assume you mean that gnuplot could use a  try except block for this
>>> import, or would you aim at making setuptools a dependency?
>>>
>>
>> Actually, setuptools has a bootstrap script  (ez_setup.py) which will
>> download and install setuptools if it is not installed. But a try/except
>> might also be a good idea since it wouldn't require any extra installation
>> for those who download the source tarball manually. As for the ones
>> installing via easy_install either directly or as a dependency this is not a
>> problem since they've got to have setuptools installed to begin with.
>>
>>>
>>> What is actually the standard about running
>>>
>>> python setup.py sdist. register upload
>>> The main developer should do it? Problem is a bit that Michael still
>>> replies mails to mailing list from time to time, but there is at the time
>>> nobody with the time to actually hack at Gnuplot.py.
>>>
>>
>> Anyone could do the "...sdist register upload", but  ideally it should be
>> someone who is also involved with the official releases of Gnuplot.py so
>> that the PyPI package is kept up-to-date. The person which uploads the
>> initial package becomes the manager of the package in PyPI via their  login
>> and password.
>>
>>
>>> If you build on top of gnuplot, you might be interested in exposing some
>>> of the new capabilities of gnuplot in the Gnuplot.py API?
>>> It is great that we have the API to directly pass gnuplot commands, but
>>> it does mean not many people are interested in expanding the API.
>>>
>>
>> I have looked at the code of Gnuplot.py and found it to be very readable
>> and easy to understand. So if I find the time to improve it, I'll certainly
>> post a patch to this list for review.
>>
>>>
>>> I don't mind doing this change in the code myself, I use an extension to
>>> setuptools for one of my own projects, but I'd like Michael to agree with it
>>> before adding it, as I have only done some very small contributions up to
>>> now.
>>>
>>
>> I think that the best way to go too.
>>
>
> Ok, I tried it locally.
> I have one issue only. There are some defaults in eg Gnuplot/gp_unix.py and
> friends users might want to change.
>
> Using setuptools this installs as a zipped egg file however. Is there an
> easy way to edit the installed egg? Or does it mean like this users must
> install from source to be able to change a default setting? It seems like
> that to me.
>
> I can work around it myself with
>
> sudo python setup.py install --single-version-externally-managed
> --install-layout=deb --root /
>
> and packagers for ubuntu/... can use that instead of an egg, but people
> using easy-install are stuck with our defaults it seems.
>
> Benny
>
>
>>
>> cheers,
>>
>> Flávio
>>
>>>
>>> Benny
>>>
>>> cheers,
>>>>
>>>> Flávio
>>>>
>>>>
>>>>
>>>> --
>>>> Flávio Codeço Coelho
>>>>
>>>>
>>>
>>
>>
>> --
>> Flávio Codeço Coelho
>>
>>
>


-- 
Flávio Codeço Coelho

Re: [Gnuplot-py-users] change default term on unix to wxt

[Michael H. <mh...@al...>]

Benny Malengier wrote:
> Alternative is not to set terminal in _Gnuplot.py, as then gnuplot
> chooses it's default, so to change the default to do nothing, and only
> when gp_unix.py contains an entry different from '' use that. I think I
> like this alternative actually best.

I believe that Gnuplot.py has to know a terminal name in order to reset
it after creating a hardcopy (because to create a hardcopy it
temporarily sets the terminal to postscript or something similar).

It would be possible to leave the default terminal type until the first
hardcopy, but I think it would be confusing for the terminal type to
change in the middle of a session.

It would be possible to read the terminal type from gnuplot it self if
somebody wants to make that effort.  This could be done, for example, by
executing "show term" or by executing "output 'filename'" then looking
in the resulting file.  Or perhaps there is a more modern way of doing it.

Michael

[Gnuplot-py-users] change default term on unix to wxt

[Benny M. <ben...@gm...>]

Hi,

If nobody complains, I'll change the default terminal for unix to wxt
instead of x11. The wxwidget terminal is the default in gnuplot itself for
some time.
I believe it is time to have new users in the future have the nicest
experience, users on older system can change the default in gp_unix.py back
to x11.

Alternative is not to set terminal in _Gnuplot.py, as then gnuplot chooses
it's default, so to change the default to do nothing, and only when
gp_unix.py contains an entry different from '' use that. I think I like this
alternative actually best.

I have no other systems, should people there feel defaults should be changed
for their system too, let it be known.

Benny

Re: [Gnuplot-py-users] suggestion

[Benny M. <ben...@gm...>]

2010/5/2 Flavio Coelho <fcc...@gm...>

>
>
> On Sun, May 2, 2010 at 12:53 PM, Benny Malengier <
> ben...@gm...> wrote:
>
>>
>>
>> 2010/5/2 Flavio Coelho <fcc...@gm...>
>>
>>
>>>
>>> On Sun, May 2, 2010 at 9:41 AM, Benny Malengier <
>>> ben...@gm...> wrote:
>>>
>>>>
>>>>
>>>> 2010/4/26 Flavio Coelho <fcc...@gm...>
>>>>
>>>> Hi,
>>>>>
>>>>> I use Gnuplot.py in some of my projects, and would like to thank
>>>>> Michael for such a useful package.
>>>>>
>>>>> One of my projects, Liveplots[1], depends on Gnuplot.py, and uses
>>>>> setuptools (easy_install)[2] as its main mode of distribution. It would be
>>>>> very convenient for me, and possibly for other Gnuplot.py users, that is
>>>>> could also be installed by means of the easy_install command. This is
>>>>> important because other projects which want to declare Gnuplot.py as a
>>>>> dependency can do so by listing it in their setup.py and have it be
>>>>> installed automatically.
>>>>>
>>>>> To enable this, all that is required is to edit one line in the
>>>>> setup.py:
>>>>>
>>>>> where it reads "from distutils.core import setup"  it should read:
>>>>> "from setuptools import setup". After this, running "python setup.py sdist.
>>>>> register upload", will add Gnuplot.py to Python Package Index and make it
>>>>> easy_installable for users with setuptools installed.
>>>>>
>>>>> I should also point out, that this edit will not affect in any way how
>>>>> Gnuplot.py is currently used and installed, just add a new way to install
>>>>> it.
>>>>>
>>>>
>>>> This seems easy, but is it the correct way forward? I did not follow all
>>>> the dirt being thrown around with respect to building/installing python
>>>> pacages. I know there is a lot of controversies.
>>>> However, distutils remains supported in python core
>>>> http://docs.python.org/distutils/index.html#distutils-index
>>>>
>>>> so it is a part of python 3. People still seem to use it and advocate it
>>>> (eg http://diveintopython3.org/packaging.html ).
>>>>
>>>> So, why not use the core packages? If we go with setuptools, we could
>>>> also take pip or distribute...
>>>>
>>>
>>> I have followed some of the discussion regarding the fork of Distribute
>>> from setuptools, and the issues at the core where about how to make the
>>> package evolve towards being included in the standard library, not about its
>>> usefulness. Neither Setuptools or Distribute mean to replace distutils but
>>> to extend it. Making a setup.py compatible with setuptools or Distribute,
>>> does not affect the "python setup.py install" way of installing packages of
>>> distutils. But it allows for packages to declare a dependency tree of
>>> packages, which is not available in plain distutils.
>>>
>>> Moreover, most heavily used python packages have been using setuptools
>>> for years. So the bottom line is that adopting setuptools costs just a
>>> couple of line edits in setup.py while being  completely transparent to
>>> users accustomed to distutils. There's much to gain and nothing to loose.
>>>
>>>
>> So I assume you mean that gnuplot could use a  try except block for this
>> import, or would you aim at making setuptools a dependency?
>>
>
> Actually, setuptools has a bootstrap script  (ez_setup.py) which will
> download and install setuptools if it is not installed. But a try/except
> might also be a good idea since it wouldn't require any extra installation
> for those who download the source tarball manually. As for the ones
> installing via easy_install either directly or as a dependency this is not a
> problem since they've got to have setuptools installed to begin with.
>
>>
>> What is actually the standard about running
>>
>> python setup.py sdist. register upload
>> The main developer should do it? Problem is a bit that Michael still
>> replies mails to mailing list from time to time, but there is at the time
>> nobody with the time to actually hack at Gnuplot.py.
>>
>
> Anyone could do the "...sdist register upload", but  ideally it should be
> someone who is also involved with the official releases of Gnuplot.py so
> that the PyPI package is kept up-to-date. The person which uploads the
> initial package becomes the manager of the package in PyPI via their  login
> and password.
>
>
>> If you build on top of gnuplot, you might be interested in exposing some
>> of the new capabilities of gnuplot in the Gnuplot.py API?
>> It is great that we have the API to directly pass gnuplot commands, but it
>> does mean not many people are interested in expanding the API.
>>
>
> I have looked at the code of Gnuplot.py and found it to be very readable
> and easy to understand. So if I find the time to improve it, I'll certainly
> post a patch to this list for review.
>
>>
>> I don't mind doing this change in the code myself, I use an extension to
>> setuptools for one of my own projects, but I'd like Michael to agree with it
>> before adding it, as I have only done some very small contributions up to
>> now.
>>
>
> I think that the best way to go too.
>

Ok, I tried it locally.
I have one issue only. There are some defaults in eg Gnuplot/gp_unix.py and
friends users might want to change.

Using setuptools this installs as a zipped egg file however. Is there an
easy way to edit the installed egg? Or does it mean like this users must
install from source to be able to change a default setting? It seems like
that to me.

I can work around it myself with

sudo python setup.py install --single-version-externally-managed
--install-layout=deb --root /

and packagers for ubuntu/... can use that instead of an egg, but people
using easy-install are stuck with our defaults it seems.

Benny


>
> cheers,
>
> Flávio
>
>>
>> Benny
>>
>> cheers,
>>>
>>> Flávio
>>>
>>>
>>>
>>> --
>>> Flávio Codeço Coelho
>>>
>>>
>>
>
>
> --
> Flávio Codeço Coelho
>
>

Re: [Gnuplot-py-users] suggestion

[Michael H. <mh...@al...>]

Benny Malengier wrote:
> I don't mind doing this change in the code myself, I use an extension to
> setuptools for one of my own projects, but I'd like Michael to agree
> with it before adding it, as I have only done some very small
> contributions up to now.

I don't know much about the Python distribution tools and therefore I am
happy with whatever you decide.

Michael

Re: [Gnuplot-py-users] suggestion

[Flavio C. <fcc...@gm...>]

On Sun, May 2, 2010 at 12:53 PM, Benny Malengier
<ben...@gm...>wrote:

>
>
> 2010/5/2 Flavio Coelho <fcc...@gm...>
>
>
>>
>> On Sun, May 2, 2010 at 9:41 AM, Benny Malengier <
>> ben...@gm...> wrote:
>>
>>>
>>>
>>> 2010/4/26 Flavio Coelho <fcc...@gm...>
>>>
>>> Hi,
>>>>
>>>> I use Gnuplot.py in some of my projects, and would like to thank Michael
>>>> for such a useful package.
>>>>
>>>> One of my projects, Liveplots[1], depends on Gnuplot.py, and uses
>>>> setuptools (easy_install)[2] as its main mode of distribution. It would be
>>>> very convenient for me, and possibly for other Gnuplot.py users, that is
>>>> could also be installed by means of the easy_install command. This is
>>>> important because other projects which want to declare Gnuplot.py as a
>>>> dependency can do so by listing it in their setup.py and have it be
>>>> installed automatically.
>>>>
>>>> To enable this, all that is required is to edit one line in the
>>>> setup.py:
>>>>
>>>> where it reads "from distutils.core import setup"  it should read: "from
>>>> setuptools import setup". After this, running "python setup.py sdist.
>>>> register upload", will add Gnuplot.py to Python Package Index and make it
>>>> easy_installable for users with setuptools installed.
>>>>
>>>> I should also point out, that this edit will not affect in any way how
>>>> Gnuplot.py is currently used and installed, just add a new way to install
>>>> it.
>>>>
>>>
>>> This seems easy, but is it the correct way forward? I did not follow all
>>> the dirt being thrown around with respect to building/installing python
>>> pacages. I know there is a lot of controversies.
>>> However, distutils remains supported in python core
>>> http://docs.python.org/distutils/index.html#distutils-index
>>>
>>> so it is a part of python 3. People still seem to use it and advocate it
>>> (eg http://diveintopython3.org/packaging.html ).
>>>
>>> So, why not use the core packages? If we go with setuptools, we could
>>> also take pip or distribute...
>>>
>>
>> I have followed some of the discussion regarding the fork of Distribute
>> from setuptools, and the issues at the core where about how to make the
>> package evolve towards being included in the standard library, not about its
>> usefulness. Neither Setuptools or Distribute mean to replace distutils but
>> to extend it. Making a setup.py compatible with setuptools or Distribute,
>> does not affect the "python setup.py install" way of installing packages of
>> distutils. But it allows for packages to declare a dependency tree of
>> packages, which is not available in plain distutils.
>>
>> Moreover, most heavily used python packages have been using setuptools for
>> years. So the bottom line is that adopting setuptools costs just a couple of
>> line edits in setup.py while being  completely transparent to users
>> accustomed to distutils. There's much to gain and nothing to loose.
>>
>>
> So I assume you mean that gnuplot could use a  try except block for this
> import, or would you aim at making setuptools a dependency?
>

Actually, setuptools has a bootstrap script  (ez_setup.py) which will
download and install setuptools if it is not installed. But a try/except
might also be a good idea since it wouldn't require any extra installation
for those who download the source tarball manually. As for the ones
installing via easy_install either directly or as a dependency this is not a
problem since they've got to have setuptools installed to begin with.

>
> What is actually the standard about running
>
> python setup.py sdist. register upload
> The main developer should do it? Problem is a bit that Michael still
> replies mails to mailing list from time to time, but there is at the time
> nobody with the time to actually hack at Gnuplot.py.
>

Anyone could do the "...sdist register upload", but  ideally it should be
someone who is also involved with the official releases of Gnuplot.py so
that the PyPI package is kept up-to-date. The person which uploads the
initial package becomes the manager of the package in PyPI via their  login
and password.


> If you build on top of gnuplot, you might be interested in exposing some of
> the new capabilities of gnuplot in the Gnuplot.py API?
> It is great that we have the API to directly pass gnuplot commands, but it
> does mean not many people are interested in expanding the API.
>

I have looked at the code of Gnuplot.py and found it to be very readable and
easy to understand. So if I find the time to improve it, I'll certainly post
a patch to this list for review.

>
> I don't mind doing this change in the code myself, I use an extension to
> setuptools for one of my own projects, but I'd like Michael to agree with it
> before adding it, as I have only done some very small contributions up to
> now.
>

I think that the best way to go too.

cheers,

Flávio

>
> Benny
>
> cheers,
>>
>> Flávio
>>
>>
>>
>> --
>> Flávio Codeço Coelho
>>
>>
>


-- 
Flávio Codeço Coelho

Re: [Gnuplot-py-users] suggestion

[Benny M. <ben...@gm...>]

2010/5/2 Flavio Coelho <fcc...@gm...>

>
>
> On Sun, May 2, 2010 at 9:41 AM, Benny Malengier <ben...@gm...
> > wrote:
>
>>
>>
>> 2010/4/26 Flavio Coelho <fcc...@gm...>
>>
>> Hi,
>>>
>>> I use Gnuplot.py in some of my projects, and would like to thank Michael
>>> for such a useful package.
>>>
>>> One of my projects, Liveplots[1], depends on Gnuplot.py, and uses
>>> setuptools (easy_install)[2] as its main mode of distribution. It would be
>>> very convenient for me, and possibly for other Gnuplot.py users, that is
>>> could also be installed by means of the easy_install command. This is
>>> important because other projects which want to declare Gnuplot.py as a
>>> dependency can do so by listing it in their setup.py and have it be
>>> installed automatically.
>>>
>>> To enable this, all that is required is to edit one line in the setup.py:
>>>
>>>
>>> where it reads "from distutils.core import setup"  it should read: "from
>>> setuptools import setup". After this, running "python setup.py sdist.
>>> register upload", will add Gnuplot.py to Python Package Index and make it
>>> easy_installable for users with setuptools installed.
>>>
>>> I should also point out, that this edit will not affect in any way how
>>> Gnuplot.py is currently used and installed, just add a new way to install
>>> it.
>>>
>>
>> This seems easy, but is it the correct way forward? I did not follow all
>> the dirt being thrown around with respect to building/installing python
>> pacages. I know there is a lot of controversies.
>> However, distutils remains supported in python core
>> http://docs.python.org/distutils/index.html#distutils-index
>>
>> so it is a part of python 3. People still seem to use it and advocate it
>> (eg http://diveintopython3.org/packaging.html ).
>>
>> So, why not use the core packages? If we go with setuptools, we could also
>> take pip or distribute...
>>
>
> I have followed some of the discussion regarding the fork of Distribute
> from setuptools, and the issues at the core where about how to make the
> package evolve towards being included in the standard library, not about its
> usefulness. Neither Setuptools or Distribute mean to replace distutils but
> to extend it. Making a setup.py compatible with setuptools or Distribute,
> does not affect the "python setup.py install" way of installing packages of
> distutils. But it allows for packages to declare a dependency tree of
> packages, which is not available in plain distutils.
>
> Moreover, most heavily used python packages have been using setuptools for
> years. So the bottom line is that adopting setuptools costs just a couple of
> line edits in setup.py while being  completely transparent to users
> accustomed to distutils. There's much to gain and nothing to loose.
>
>
So I assume you mean that gnuplot could use a  try except block for this
import, or would you aim at making setuptools a dependency?

What is actually the standard about running
python setup.py sdist. register upload
The main developer should do it? Problem is a bit that Michael still replies
mails to mailing list from time to time, but there is at the time nobody
with the time to actually hack at Gnuplot.py.
If you build on top of gnuplot, you might be interested in exposing some of
the new capabilities of gnuplot in the Gnuplot.py API?
It is great that we have the API to directly pass gnuplot commands, but it
does mean not many people are interested in expanding the API.

I don't mind doing this change in the code myself, I use an extension to
setuptools for one of my own projects, but I'd like Michael to agree with it
before adding it, as I have only done some very small contributions up to
now.

Benny

cheers,
>
> Flávio
>
>
>
> --
> Flávio Codeço Coelho
>
>

Re: [Gnuplot-py-users] suggestion

[Flavio C. <fcc...@gm...>]

On Sun, May 2, 2010 at 9:41 AM, Benny Malengier
<ben...@gm...>wrote:

>
>
> 2010/4/26 Flavio Coelho <fcc...@gm...>
>
> Hi,
>>
>> I use Gnuplot.py in some of my projects, and would like to thank Michael
>> for such a useful package.
>>
>> One of my projects, Liveplots[1], depends on Gnuplot.py, and uses
>> setuptools (easy_install)[2] as its main mode of distribution. It would be
>> very convenient for me, and possibly for other Gnuplot.py users, that is
>> could also be installed by means of the easy_install command. This is
>> important because other projects which want to declare Gnuplot.py as a
>> dependency can do so by listing it in their setup.py and have it be
>> installed automatically.
>>
>> To enable this, all that is required is to edit one line in the setup.py:
>>
>> where it reads "from distutils.core import setup"  it should read: "from
>> setuptools import setup". After this, running "python setup.py sdist.
>> register upload", will add Gnuplot.py to Python Package Index and make it
>> easy_installable for users with setuptools installed.
>>
>> I should also point out, that this edit will not affect in any way how
>> Gnuplot.py is currently used and installed, just add a new way to install
>> it.
>>
>
> This seems easy, but is it the correct way forward? I did not follow all
> the dirt being thrown around with respect to building/installing python
> pacages. I know there is a lot of controversies.
> However, distutils remains supported in python core
> http://docs.python.org/distutils/index.html#distutils-index
>
> so it is a part of python 3. People still seem to use it and advocate it
> (eg http://diveintopython3.org/packaging.html ).
>
> So, why not use the core packages? If we go with setuptools, we could also
> take pip or distribute...
>

I have followed some of the discussion regarding the fork of Distribute from
setuptools, and the issues at the core where about how to make the package
evolve towards being included in the standard library, not about its
usefulness. Neither Setuptools or Distribute mean to replace distutils but
to extend it. Making a setup.py compatible with setuptools or Distribute,
does not affect the "python setup.py install" way of installing packages of
distutils. But it allows for packages to declare a dependency tree of
packages, which is not available in plain distutils.

Moreover, most heavily used python packages have been using setuptools for
years. So the bottom line is that adopting setuptools costs just a couple of
line edits in setup.py while being  completely transparent to users
accustomed to distutils. There's much to gain and nothing to loose.

cheers,

Flávio



-- 
Flávio Codeço Coelho

Re: [Gnuplot-py-users] suggestion

[Benny M. <ben...@gm...>]

2010/4/26 Flavio Coelho <fcc...@gm...>

> Hi,
>
> I use Gnuplot.py in some of my projects, and would like to thank Michael
> for such a useful package.
>
> One of my projects, Liveplots[1], depends on Gnuplot.py, and uses
> setuptools (easy_install)[2] as its main mode of distribution. It would be
> very convenient for me, and possibly for other Gnuplot.py users, that is
> could also be installed by means of the easy_install command. This is
> important because other projects which want to declare Gnuplot.py as a
> dependency can do so by listing it in their setup.py and have it be
> installed automatically.
>
> To enable this, all that is required is to edit one line in the setup.py:
>
> where it reads "from distutils.core import setup"  it should read: "from
> setuptools import setup". After this, running "python setup.py sdist.
> register upload", will add Gnuplot.py to Python Package Index and make it
> easy_installable for users with setuptools installed.
>
> I should also point out, that this edit will not affect in any way how
> Gnuplot.py is currently used and installed, just add a new way to install
> it.
>

This seems easy, but is it the correct way forward? I did not follow all the
dirt being thrown around with respect to building/installing python pacages.
I know there is a lot of controversies.
However, distutils remains supported in python core
http://docs.python.org/distutils/index.html#distutils-index

so it is a part of python 3. People still seem to use it and advocate it (eg
http://diveintopython3.org/packaging.html ).

So, why not use the core packages? If we go with setuptools, we could also
take pip or distribute...

Benny


>  cheers,
>
> --
> Flávio Codeço Coelho
>
> [1] http://code.google.com/p/liveplots/
> [2] http://pypi.python.org/pypi/setuptools
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Gnuplot-py-users mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-py-users
>
>

[Gnuplot-py-users] suggestion

[Flavio C. <fcc...@gm...>]

Hi,

I use Gnuplot.py in some of my projects, and would like to thank Michael for
such a useful package.

One of my projects, Liveplots[1], depends on Gnuplot.py, and uses setuptools
(easy_install)[2] as its main mode of distribution. It would be very
convenient for me, and possibly for other Gnuplot.py users, that is could
also be installed by means of the easy_install command. This is important
because other projects which want to declare Gnuplot.py as a dependency can
do so by listing it in their setup.py and have it be installed
automatically.

To enable this, all that is required is to edit one line in the setup.py:

where it reads "from distutils.core import setup"  it should read: "from
setuptools import setup". After this, running "python setup.py sdist.
register upload", will add Gnuplot.py to Python Package Index and make it
easy_installable for users with setuptools installed.

I should also point out, that this edit will not affect in any way how
Gnuplot.py is currently used and installed, just add a new way to install
it.

 cheers,

-- 
Flávio Codeço Coelho

[1] http://code.google.com/p/liveplots/
[2] http://pypi.python.org/pypi/setuptools

Re: [Gnuplot-py-users] Plot list of PlotItems

[Felix U. <fel...@ui...>]

AWESOME!!!!!!!

Thanks Michael for your quick reply!!

gnuplot-py rules!

Felix

Michael Haggerty wrote:
> Felix Uni wrote:
>> i have following problem:
>> i want to plot a number of lines. The number of lines can be set by an
>> user option, so i don't know it in advance. I thought of using a list of
>> Data PlotItems. Establishing the PlotItem list works, however sending it
>> to g.plot fails. Any idea how to do this/ work around it.
>> [...]
>>    19 # --- This is what i want to work :-) ---
>>    20 g.plot(ga)
>
> Use
>
>      g.plot(*ga)
>
> to treat the entries in the "ga" list as individual arguments to the
> plot() method.
>
> Michael

Re: [Gnuplot-py-users] Plot list of PlotItems

[Michael H. <mh...@al...>]

Felix Uni wrote:
> i have following problem:
> i want to plot a number of lines. The number of lines can be set by an 
> user option, so i don't know it in advance. I thought of using a list of 
> Data PlotItems. Establishing the PlotItem list works, however sending it 
> to g.plot fails. Any idea how to do this/ work around it.
> [...]
>   19 # --- This is what i want to work :-) ---
>   20 g.plot(ga)

Use

    g.plot(*ga)

to treat the entries in the "ga" list as individual arguments to the
plot() method.

Michael

[Gnuplot-py-users] Plot list of PlotItems

[Felix U. <fel...@ui...>]

Hi there,

i have following problem:
i want to plot a number of lines. The number of lines can be set by an 
user option, so i don't know it in advance. I thought of using a list of 
Data PlotItems. Establishing the PlotItem list works, however sending it 
to g.plot fails. Any idea how to do this/ work around it.

Here's a testcode to illustrate what i mean:

   1 import Gnuplot
   2 from numpy import *
   3
   4 g = Gnuplot.Gnuplot(persist=1)
   5 g('set terminal x11 size 1000,680')
   6
   7 y = []
   8 y.append([1,2,3,4,5,6])
   9 y.append([1.1,2.1,3.1,4.1,5.1,6.1])
  10
  11 ga =[]
  12 ga.append(Gnuplot.Data(y[0],binary=0,with_='lines'))
  13 ga.append(Gnuplot.Data(y[1],binary=0,with_='lines'))
  14
  15
  16 # --- This of course works---
  17 #g.plot(ga[0],ga[1])
  18
  19 # --- This is what i want to work :-) ---
  20 g.plot(ga)


Looking forward to your answers!

regards,
Felix