Re: matplotlib change?

[bill . janssen]

On Thursday, June 22, 2017 at 11:24:53 AM UTC-7, Michael F. Stemper wrote:
> On 2017-06-22 12:56, bill.jans...@gmail.com wrote:
> > On Thursday, June 22, 2017 at 10:14:21 AM UTC-7, Michael F. Stemper wrote:
> >> On 2017-06-22 09:50, breamore...@gmail.com wrote:
> >>> On Thursday, June 22, 2017 at 3:33:36 PM UTC+1, Michael F. Stemper wrote:
> >
> 
>  Is it likely that the difference in plots due to something that
>  changed in matplotlib between 2.7.12 and 2.7.13? If so, is there
>  some argument that I could specify in one of the functions to
>  prevent this padding/margin/waste? Is there a separate function
>  to call?
> 
>  If the difference isn't due to a change in matplotlib, would it be
>  something OS-dependent? How can I track it down?
> >>
> >>> Id check to see which matplotlib versions you have rather than the Python 
> >>> version.  Either:-
> >>
> >> Okay, that was easy enough:
> 
> >>   >>> import matplotlib
> >>   >>> matplotlib.__version__
> >> '2.0.0'
> >>   >>>
> >>
> >> What's my next step?
> 
> > There were a number of changes to line-drawing in the bump from 1 to 2 -- I 
> > found that some of them were not listed in the change notes.  It's worth 
> > reviewing 
> > https://matplotlib.org/users/dflt_style_changes.html#plotting-functions.
> 
> That nailed it! This section:
> 
> addressed my exact problem.
> 
> (Unfortunately, the parameters are not back-compatible, but at least
> I'll be ready when they upgrade the box where I usually work.)
> 
> Thanks for your help.
> 
> BTW, your name is familiar. Were you ever at PARC?
> 
> -- 
> Michael F. Stemper
> This post contains greater than 95% post-consumer bytes by weight.

Still am.

Bill
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: matplotlib change?

[bill . janssen]

On Thursday, June 22, 2017 at 10:14:21 AM UTC-7, Michael F. Stemper wrote:
> On 2017-06-22 09:50, breamore...@gmail.com wrote:
> > On Thursday, June 22, 2017 at 3:33:36 PM UTC+1, Michael F. Stemper wrote:
> >> I have some scripts running as cronjobs that capture the status
> >> of some long-term processes and then periodically plot the data.
> >> The box where they normally run went down yesterday for some
> >> unknown reason, so I ran them manually on another box so that
> >> others on the project could continue to watch progress.
> >>
> >> I was surprised to see that the lines on the plot no longer went
> >> all of the way to its border. Investigating showed me that this
> >> is box-dependent.
> 
> >> Is it likely that the difference in plots due to something that
> >> changed in matplotlib between 2.7.12 and 2.7.13? If so, is there
> >> some argument that I could specify in one of the functions to
> >> prevent this padding/margin/waste? Is there a separate function
> >> to call?
> >>
> >> If the difference isn't due to a change in matplotlib, would it be
> >> something OS-dependent? How can I track it down?
> 
> > Id check to see which matplotlib versions you have rather than the Python 
> > version.  Either:-
> 
> Okay, that was easy enough:
> 
> mstemper2@greenbay$ python
> Python 2.7.12 (default, Nov 19 2016, 06:48:10)
> [GCC 5.4.0 20160609] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import matplotlib
>  >>> matplotlib.__version__
> '1.5.1'
>  >>>
> 
> mstemper2@vv322f$ python
> Python 2.7.13 (default, Jan 19 2017, 14:48:08)
> [GCC 6.3.0 20170118] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import matplotlib
>  >>> matplotlib.__version__
> '2.0.0'
>  >>>
> 
> What's my next step?
> 
> -- 
> Michael F. Stemper
> Deuteronomy 24:17

There were a number of changes to line-drawing in the bump from 1 to 2 -- I 
found that some of them were not listed in the change notes.  It's worth 
reviewing 
https://matplotlib.org/users/dflt_style_changes.html#plotting-functions.

Bill
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: PyGUI 2.5

[Bill Janssen]

Gregory Ewing  wrote:

> Terry Reedy wrote:
> 
> > Greg left out the most important to me:
> > "Now works with Python 3 on MacOSX and Windows!"
> 
> I'm not making too much of that at the moment, because it
> *doesn't* work on Linux yet, and I've no idea how long
> it will be before it does.
> 
> The issue is that there will apparently not be any
> Python 3 version of pygtk, on the grounds that gobject
> introspection can be used instead. Unfortunately,
> Gtk 3 and related libraries don't quite handle gobject
> introspection well enough to support PyGUI at the moment.

One possibility would be to develop a PyGUI branch on top of Tk, so that
it would work with Python anywhere.

Bill
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ANN: PyGUI 2.3

[Bill Janssen]

Gregory Ewing  wrote:

> Daniel Fetchinson wrote:
> 
> > Any reason your project is not easy_installable?
> 
> Mainly because I'm not a setuptools user and haven't been
> motivated to learn how to do this so far.

Applause!!

Bill
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: using Python distutils bdist_msi to create installer for large complicated package

[Bill Janssen]

Martin v. Löwis  wrote:

> > I've been re-thinking the UpLib Windows installer technology, and it
> > occurred to me to wonder why I can't just use the nice bdist_msi module
> > in Python to build my packages.  I took a look, and it seems almost
> > doable.  Presumably you wrote it?
> 
> Correct.
> 
> > UpLib is a big package, with lots of Python and Java and C programs, and
> > for Windows I package it with lots of other programs like those from
> > xpdf.  All of this is installed in C:\Program Files\UpLib\VERSION\, in
> > bin, lib, share, and so forth subdirectories.  If I autogenerated a
> > setup.py file which described everything as "data_files", it should be
> > simple to package everything up in a Cab, and bdist_msi apparently also
> > provides the ability to add pre- and post-install scripts.  Everything
> > I need, really.
> > 
> > There are a couple of Python-specific options in the code: the "Product
> > Name" is prefixed with the python version, and in the GUI, the default
> > location is the location of a Python distro.  If the package had a
> > "--non-python" option which would defeat these, and perhaps also set
> > "no-target-optimize" and "no-target-compile" to True, it would be a
> > simple but pretty general-purpose packager module.
> 
> I'd rather recommend to base this off msilib directly, instead of trying
> to subvert bdist_msi to do what you want.

Yes, that was the first thing I looked at.  But as you've pointed out in
the past, it requires a lot of MSI know-how to use that library
directly.  For a variety of applications, you've already embedded most
if not all of that know-how in the bdist_msi class.  And subclassing
is the indicated way to build on distutils, isn't it?

> There is actually quite a lot python-specifics in bdist_msi.

Well, sort of.  If a setup only references "data_files" -- no Python
packages, no extensions -- it's pretty generic.

The "add_find_python" method seems the most python-specific.  I'd
remove a lot of that in the generic case.  And, of course, modify "run"
so that the product name isn't prefixed with "Python x.y".

> If you find this too tedious to use,
> please propose *base classes* that could become part of msilib, rather
> than trying to create *subclasses* of the bdist_msi classes.

Yes, good idea.  For example, all those panels that are in get_ui
could be added by a InstallerBaseGUI class of some sort.

But still, just a few mods to bdist_msi could go a long way.  For
instance, you've already pulled out "get_installer_filename". I'd add a
similar method, "get_product_name", which would typically just return
the user-specific name, but in the default case could prefix the product
name with Python 2.6.

Bill
-- 
http://mail.python.org/mailman/listinfo/python-list

using Python distutils bdist_msi to create installer for large complicated package

[Bill Janssen]

Martin,

I've been re-thinking the UpLib Windows installer technology, and it
occurred to me to wonder why I can't just use the nice bdist_msi module
in Python to build my packages.  I took a look, and it seems almost
doable.  Presumably you wrote it?

UpLib is a big package, with lots of Python and Java and C programs, and
for Windows I package it with lots of other programs like those from
xpdf.  All of this is installed in C:\Program Files\UpLib\VERSION\, in
bin, lib, share, and so forth subdirectories.  If I autogenerated a
setup.py file which described everything as "data_files", it should be
simple to package everything up in a Cab, and bdist_msi apparently also
provides the ability to add pre- and post-install scripts.  Everything
I need, really.

There are a couple of Python-specific options in the code: the "Product
Name" is prefixed with the python version, and in the GUI, the default
location is the location of a Python distro.  If the package had a
"--non-python" option which would defeat these, and perhaps also set
"no-target-optimize" and "no-target-compile" to True, it would be a
simple but pretty general-purpose packager module.

I'll subclass it and play around a bit.

Bill

-- 
http://mail.python.org/mailman/listinfo/python-list

new version of SSL module on PyPI

[Bill Janssen]

I've uploaded ssl-1.15.tgz, the backport of the 2.6/3.x SSL module to
Python 2.3-2.5.  It provides an option for not using SSLv2, and also
fixes a bug with write retries.

Bill
-- 
http://mail.python.org/mailman/listinfo/python-list

UpLib 1.7.6 available

[Bill Janssen]

I've released the latest version of my UpLib personal digital library
system.

For those of you unfamiliar with UpLib, here's the abstract:

  The UpLib personal digital library system provides a secure
  long-term storage system, and a visually-oriented retrieval
  mechanism, for a wide variety of personal documents such as papers,
  photos, receipts, music, Web pages, books, clippings, and email. It
  is suitable for collections comprising tens of thousands of
  documents, and provides for ease of document entry and access as
  well as high levels of security and privacy. It is highly extensible
  through user scripting, and supports collaborative sharing of those
  extensions through a common extensions library.

It's mainly written in Python -- there's a scrap of C code for page
image zone classification, PyLucene is used for indexing and search,
and there's a fairly extensive Java client-side library, including a
document reader.

Among other things, it includes my Python IMAP server, which allows an
UpLib document repository to be used as an IMAP mail server.

http://uplib.parc.com/

Bill
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Browser plug-in for Python?

[Bill Janssen]

Yes, thanks, back in the day I used Grail and played with rexec.

I notice that one of the Summer of Code projects was to recreate
rexec, but don't know if it was funded.

Presumably a Firefox plug-in for Python would restrict the execution
environment in some safe way, and provide some kind of UI toolkit API
so that the Python program could draw on the area given to the
plug-in.  If I were doing it, I'd probably add something like Joel
Bartlett's "ezd" drawing system (see
http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-91-6.pdf), replacing
the Scheme used in ezd with Python.

Bill
-- 
http://mail.python.org/mailman/listinfo/python-list

Browser plug-in for Python?

[Bill Janssen]

Has anyone written a browser plug-in for Python, similar to the Java
plug-in that Sun has switched to for applets?

Bill
-- 
http://mail.python.org/mailman/listinfo/python-list