[IPython-dev] Adding a nice progressbar to scipy

[Ondrej Certik]

On Jan 12, 2008 4:12 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> [ Note: this is continued from scipy-dev:
> http://projects.scipy.org/pipermail/scipy-dev/2008-January/008200.html
>
> The code in question is:
> http://pypi.python.org/pypi/progressbar
>
> I'm moving the discussion here b/c now it's an ipython thing. ]
>
> On Jan 11, 2008 7:54 PM, Ondrej Certik <ondrej at certik.cz> wrote:
> > On Jan 12, 2008 3:26 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> > >
> > > On Jan 11, 2008 6:52 PM, Ondrej Certik <ondrej at certik.cz> wrote:
> > > > So what is the conclusion?
> > > >
> > > > Maybe I should stress, that the progress bar is just one file with 300
> > > > lines of code.
> > > >
> > > > So it's not really a package, just a feature. I was thinking of
> > > > scipy.io, but ipython
> > > > is maybe better. If it can contain interaction with gnuplot, why not a simple
> > > > progressbar? :)
>
> BTW, the gnuplot and numeric support are old and deprecated, code from
> 2001 when Numeric was much more limited than numpy and matplotlib
> didn't exist :)  We've precisely moved into a world where we try to
> have better defined responsibilities (scipy used to have plotting and
> that got taken out, matplotlib used to have a shell and that got taken
> out, etc.).  Having said that, an interactive progress bar *does* make
> sense for ipython, which is why I'm willing to entertain this
> discussion.
>
> > > A few questions:
> > >
> > > - Will it run *correctly* under Windows?  I don't use it, but I don't
> > > want the text-only core of ipython to start sprouting functionality
> > > that breaks under windows (or any OS for that matter).  Same thing for
> > > Linux/OSX.  I know it says 'os independent', but I want independent
> > > confirmation of that statement.
> >
> > Right, I don't know, since I don't use windows and I cannot test it.
>
> I don't want to sound harsh, but since you're the one asking for the
> feature, you'll have to do a bit of the work.  Either a windows user
> from the list can help you out with testing it, or you can borrow a
> friend's windows computer for 20 minutes for testing it.
>
> I'm sorry to say this, but even as much as I dislike windows myself
> for personal use, we do our best with ipython to be good windows
> citizens. Ville and Jorgen have put a LOT of work into making ipython
> behave well for windows, and I'm not about to throw on their lap a
> feature  that could cause them grief, especially since they didn't
> even ask for it in the first place.
>
> So if you want it, you'll need to first satisfy these concerns and
> find a way to get it checked.  Now, it looks like it's doable, so over
> a few days I'm sure you can find a way to get the code checked out and
> cleaned up; if it makes your life easier we can drop it in for SVN and
> you can work on the cleanup. We recently had a WX ipython committed
> that had cross-platform issues, and the developer has been gradually
> working on them.
>
> So I'm not asking you for perfect code out of the box, but I can't
> drop code in that may have cross-platform problems if you don't commit
> to fixing them if they arise.

Agree.

>
> > > - It makes calls to ioctl() without checks that the import at the top
> > > actually worked.  That will break somewhere, I guarantee it.
> >
> > It's used in handle_resize only, which is only used in
> >
> >             try:
> >                 self.handle_resize(None,None)
> >                 signal.signal(signal.SIGWINCH, self.handle_resize)
> >                 self.signal_set = True
> >             except:
> >                 self.term_width = 79
> >
> > I am not saying it's the best programming practice, but I think
> > it will work without ioctl quite well.
> >
> > > - Is signal.SIGWINCH available on all OSes?
> >
> > I don't know.
> >
> > > - termios is also used without checks.  That will likely throw an
> > > exception under windows.
> >
> > Again only in handle_resize(), which is only called in the code above,
> > so it should be safe.
> >
> > > - Etc.  This code doesn't look like it's ever been properly tested for
> > > cross-platform compatibility.  Welcome to the real world.
> >
> > Right. I can only say that it works well in Debian.
> >
> > > If all of the above were to be addressed, it's small enough that I'm
> > > willing to throw it into ipython.externals for convenience.  300 lines
> > > is a drop in the bucket at this point, and for interactive work it can
> > > come in very handy, I agree.  No sysadmin will notice it's hiding in
> > > there :)
> > >
> > > In this case, a few things:
> > >
> > > - You said that the author would BSD license it, but the current code
> > > http://pypi.python.org/pypi/progressbar still shows LGPL-only.  I
> > > won't put it in until we get from him a BSD-licensed file.
> >
> > Yes, he only sent an email to me, I can ask him to send an email to
> > this list too.
> >
> > > - Please send us the patch you suggested writing for the more comon case.
> >
> > I'll send it to the ipython list.
> >
> > > - You commit to letting us know when an update is warranted and
> > > sending us the corresponding patch, so that the ipython developers can
> > > apply it with minimal effort.
> >
> > I commit. The final decision needs to be made by ipython developers though,
> > if they are willing to maintain such a code if I won't be available
> > (for any reason). But except
> > the points you raised, I think it's very readable, so there shouldn't
> > be a problem with that.
>
> I hope the above is clear enough.  If one of our core windows people
> finds this code useful and is willing to help Ondrej test that part
> and clean it up, that would be great.  I think this feature can be
> useful, but I'm just making sure that Ville and Jorgen don't end up
> with a problem on their hands they didn't bargain for.

Of course. Attached find the first draft of the patch.

Apply like this:

$ patch -p1 < /tmp/progressbar.patch

in the trunk. Could someone plese test this example on windows?

from progressbar import progressbar
pbar=progressbar(maxval=10000)
for i in range(10000):
    pbar.update(i)
    #do some heavy calculation in each step
pbar.finish()

(you can increase the number of iterations from 10000 to something
bigger, to see the progress).

If you have some comments, I'll by happy to improve the patch.

Thanks a lot,
Ondrej
-------------- next part --------------
A non-text attachment was scrubbed...
Name: progressbar.patch
Type: text/x-patch
Size: 14838 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080112/15e4e329/attachment.bin>