From Fernando.Perez at colorado.edu  Tue Feb  1 04:26:15 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 01 Feb 2005 02:26:15 -0700
Subject: [IPython-dev] Re: IPython & Windows Installer in Python 2.3.x
In-Reply-To: <mailman.1919.1107249250.895.ipython-dev@scipy.net>
References: <mailman.1919.1107249250.895.ipython-dev@scipy.net>
Message-ID: <41FF4B37.2040401@colorado.edu>

Hi Thomas,

Thanks for looking into this.  I'm forwarding your reply to the list for the 
record.  IPython's lists discard non-subscriber posts (the spam flood was out 
of control).

Regards,

f

ipython-dev-bounces at scipy.net wrote:
> 
> Subject:
> Re: IPython & Windows Installer in Python 2.3.x
> From: Thomas Heller <theller at python.net>
> Date: Tue, 01 Feb 2005 10:15:34 +0100
> To:  viktor.ransmayr at t-online.de
> 
> To: viktor.ransmayr at t-online.de
> CC: Fernando Perez <Fernando.Perez at colorado.edu>, IPython-user List 
> <ipython-user at scipy.net>, IPython-dev List <ipython-dev at scipy.net>, 
> theller at python.net
> 
> 
> viktor.ransmayr at t-online.de (Viktor Ransmayr) writes:
> 
> 
>>Hi Fernando,
>>
>>I wrote:
>>
>>
>>>Just to clarify and make sure there are no misunderstandings. - It
>>>works, since
>>>I created the binary installer within the same device, C:\ in my
>>>case, where also
>>>Python resided.
>>>
>>>I tried to do the same from a separate device (E:\ - a USB-Disk in
>>>my case).
>>>- I was able to create the binary installer, but received a
>>>MS-Traceback when
>>>I tried to install the created executable.
>>>
>>>I'll follow up on this one. (Distutil in Python 2.3.4 vs. 2.3.5c1
>>>vs. 2.4 ...
>>
>>As a last thing for the day I'd like to report that above problem is
>>fixed with
>>the distutils version distributed with Python-2.3.5c1.
>>
>>Regards,
>>
>>Viktor
> 
> 
> Great!  Thanks for the report.
> 
> Thomas
> 



From Fernando.Perez at colorado.edu  Tue Feb 15 03:44:29 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 15 Feb 2005 01:44:29 -0700
Subject: [IPython-dev] [ANN] IPython 0.6.11 is out.
Message-ID: <4211B66D.9090904@colorado.edu>

Hi all,

I'm glad to announce the release of IPython 0.6.11.  IPython's homepage is at:

http://ipython.scipy.org

and downloads are at:

http://ipython.scipy.org/dist

I've provided RPMs (for Python 2.3 and 2.4, built under Fedora Core 3), plus 
source downloads (.tar.gz).  We now also have a native win32 installer which 
should work correctly for both Python 2.3 and 2.4.

NOTE: Win32 users who grabbed the 0.6.11 which I put in testing last week 
should still update, since today's release is actually quite different, and it 
has a few win32-specific fixes (plus the big new backgrounding feature).

Debian, Fink and BSD packages for this version should be coming soon, as the
respective maintainers (many thanks to Jack Moffit, Andrea Riciputi and Dryice
Liu) have the time to follow their packaging procedures.

Many thanks to Enthought for their continued hosting support for IPython, and
to all the users who contributed ideas, fixes and reports.


Release notes
-------------

As always, the NEWS file can be found at http://ipython.scipy.org/NEWS, and
the full ChangeLog at http://ipython.scipy.org/ChangeLog.

* A new subsystem has been added to IPython for background execution (in a 
separate thread) of commands and function calls.  This system is by no means 
perfect, and some of its limitations are unavoidable due to the nature of 
python threads.  But it can still be useful to put in the background 
long-running commands and regain control of the prompt to continue doing other 
things.  The new jobs builtin has extensive docstrings, and the new %bg magic 
complements it.  Please type %bg? and jobs? for further details.

The user-level API of this system is brand new, so I am very open to 
suggestions and comments.  While a threads-based model has limitations, this 
is also a testbed for future integration into ipython of other models of 
background execution, including parallel processing both on local 
(multiprocessor/multicore) machines and on remote clusters.  So please 
consider this an exploratory feature where we can test these ideas and better 
understand what works and what doesn't.

This system was inspired by discussions with Brian Granger <bgranger at scu.edu> 
and the BackgroundCommand class described in the book Python Scripting for 
Computational Science, by H. P. Langtangen:

http://folk.uio.no/hpl/scripting

(although ultimately no code from this text was used, as IPython's system is a
separate implementation).

* Tab completion now shows all possible completions, both for python names and 
files/directories.  This is different from the old behavior, but in practice 
much more convenient (thanks to John Hunter for the request).

* The readline_omit__names rc option now allows you to fine-tune the behavior 
of tab-completion.  You can filter out names starting with one underscore or 
two separately.  If set to 1, you only filter double-underscore names (like 
before), but if set to 2, you also filter out single-underscore names.  Thanks 
to a patch by Brian Wong <BrianWong at AirgoNetworks.Com>.

* Improvements for win32 users continue.  The installer bug for 2.4 has been 
fixed by the Python team, so the provided binary installer should now complete 
without problems (let me know otherwise).  Just in case, a manual 
post-installer for win32 still ships with the .tar.gz sources, though it 
should never be needed.

Gary Bishop also squashed a number of readline bugs, so if you update to his 
most recent release from

http://sourceforge.net/projects/uncpythontools

you should benefit from fully correct source highlighting under Win32.  Thanks 
to Vivian De Smedt, autoindent now also works under win32.

As far as I know, at this point (for the first time ever, fingers crossed...), 
all of ipython's features exist in a win32 environment.  Many thanks to all 
the patient users who have helped with this task.

I would appreciate reports of any problems from Win32 users.

* Fix issue28 in the bug tracker by disabling the startup output traps.  This 
subsystem, while nice when it works (it organizes startup error messages 
neatly) can lead to mysterious, impossible to debug problems during 
initialization.

* Fix 'ed -p' not working when the previous call produced a syntax error.

* Fix crash when inspecting classes without constructor.

* Other small fixes and cleanups.


Enjoy, and as usual please report any problems.

Regards,

Fernando.



From Fernando.Perez at colorado.edu  Wed Feb 16 13:52:10 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 16 Feb 2005 11:52:10 -0700
Subject: [IPython-dev] A note for pysh users
Message-ID: <4213965A.1030302@colorado.edu>

Hi all,

There was an incompatible change in pysh.py for 0.6.11, but since this lives 
in $HOME/.ipython, it doesn't get automatically upgraded.  You may experience 
problems with tab-completion.

To fix this, simply delete $HOME/.ipython/pysh.py and copy the new one from 
sys.prefix/lib/site-packages/IPython/UserConfig/pysh.py.

Under *nix, sys.prefix is typically /usr or /usr/local, while for Win32 it's 
often C:\PythonNN, but this will vary depending on your installation.  You can 
find it simply in python via

import sys
print sys.prefix

Thanks to Ville Vainio for tracking this down, and sorry it slipped past.

Regards,

f



From titus at caltech.edu  Fri Feb 18 01:47:59 2005
From: titus at caltech.edu (Titus Brown)
Date: Thu, 17 Feb 2005 22:47:59 -0800
Subject: [IPython-dev] ESC_QUOTE in InteractiveShell
Message-ID: <20050218064759.GB9608@caltech.edu>

Hi all,

I'm playing around with the implementation of a small scripting language
in IPython, and it turns out one of the bits of behavior I need is
auto-quoting.  (More on the *purpose* of all of this at a later date...)

If you look at iplib.py, line 1556, you'll see:

	if pre == self.ESC_QUOTE: ...

This is the 'if' statement that I need to have always be true for my
purposes.  If I can make a clean patch to add this as a configuration
option ('autoquote' or some such) or at least provide an API handle
to set this option, would there be any objections?

thanks,
--titus



From Fernando.Perez at colorado.edu  Fri Feb 18 02:50:04 2005
From: Fernando.Perez at colorado.edu (Fernando.Perez at colorado.edu)
Date: Fri, 18 Feb 2005 00:50:04 -0700
Subject: [IPython-dev] ESC_QUOTE in InteractiveShell
In-Reply-To: <20050218064759.GB9608@caltech.edu>
References: <20050218064759.GB9608@caltech.edu>
Message-ID: <1108713003.42159e2c00b67@webmail.colorado.edu>

Quoting Titus Brown <titus at caltech.edu>:

> Hi all,
>
> I'm playing around with the implementation of a small scripting language
> in IPython, and it turns out one of the bits of behavior I need is
> auto-quoting.  (More on the *purpose* of all of this at a later date...)
>
> If you look at iplib.py, line 1556, you'll see:
>
> 	if pre == self.ESC_QUOTE: ...
>
> This is the 'if' statement that I need to have always be true for my
> purposes.  If I can make a clean patch to add this as a configuration
> option ('autoquote' or some such) or at least provide an API handle
> to set this option, would there be any objections?

No, there's no need to patch anything at all.  Please have a look at how pysh is
implemented, it's just a profile, which loads an extra line prefilter hook. 
Also study the tutorial or physics profiles, they do similar processing of the
input line.  You can simply put in your own prefilter hook which
unconditionally appends this character into the user input line, to guarantee
that the above statements always evaluates to true.

Note, however, that I screwed up in 0.6.11 and autoquoting is actually broken. 
Now, I suspect very few people use this feature, but Murphy's law being what it
is, the first time I break the feature in 3 years has to be precisely the only
time a user actually talks about it. Oh well...

The bug is already fixed in CVS, so you may want to use that instead.

Regards,

f



From vivainio at kolumbus.fi  Fri Feb 18 11:11:11 2005
From: vivainio at kolumbus.fi (Ville Vainio)
Date: Fri, 18 Feb 2005 18:11:11 +0200
Subject: [IPython-dev] ESC_QUOTE in InteractiveShell
In-Reply-To: <1108713003.42159e2c00b67@webmail.colorado.edu>
References: <20050218064759.GB9608@caltech.edu>
	<1108713003.42159e2c00b67@webmail.colorado.edu>
Message-ID: <1108743071.8700.5.camel@ubuntu>

On Fri, 2005-02-18 at 00:50 -0700, Fernando.Perez at colorado.edu wrote:

>The bug is already fixed in CVS, so you may want to use that instead.

Time for a release soon? I'd like to see a release at least on this
month, since I'm going to use ipython on a company-local python course
and suggest others install ipython as well. I'd rather see them
installing it with an official exe installer than with CVS HEAD :).




From Fernando.Perez at colorado.edu  Fri Feb 18 12:32:56 2005
From: Fernando.Perez at colorado.edu (Fernando.Perez at colorado.edu)
Date: Fri, 18 Feb 2005 10:32:56 -0700
Subject: [IPython-dev] ESC_QUOTE in InteractiveShell
In-Reply-To: <1108743071.8700.5.camel@ubuntu>
References: <20050218064759.GB9608@caltech.edu>
	<1108713003.42159e2c00b67@webmail.colorado.edu>
	<1108743071.8700.5.camel@ubuntu>
Message-ID: <1108747976.421626c87c5ae@webmail.colorado.edu>

Quoting Ville Vainio <vivainio at kolumbus.fi>:

> On Fri, 2005-02-18 at 00:50 -0700, Fernando.Perez at colorado.edu wrote:
>
> >The bug is already fixed in CVS, so you may want to use that instead.
>
> Time for a release soon? I'd like to see a release at least on this
> month, since I'm going to use ipython on a company-local python course
> and suggest others install ipython as well. I'd rather see them
> installing it with an official exe installer than with CVS HEAD :).

Rumble grumble... :)

OK, I'll put one out, but I'd like to wait as late as possible to catch the
inevitable few bugs which are always reported after a release.  I'd like to
have a date from you for your course, and how close to it would be your time
limit.  I can then wait until then to put out 0.6.12 with whatever other
bugfixes I can get in.

Let me know,

f



From vivainio at kolumbus.fi  Fri Feb 18 13:16:04 2005
From: vivainio at kolumbus.fi (Ville Vainio)
Date: Fri, 18 Feb 2005 20:16:04 +0200
Subject: [IPython-dev] ESC_QUOTE in InteractiveShell
In-Reply-To: <1108747976.421626c87c5ae@webmail.colorado.edu>
References: <20050218064759.GB9608@caltech.edu>
	<1108713003.42159e2c00b67@webmail.colorado.edu>
	<1108743071.8700.5.camel@ubuntu>
	<1108747976.421626c87c5ae@webmail.colorado.edu>
Message-ID: <1108750564.8700.15.camel@ubuntu>

On Fri, 2005-02-18 at 10:32 -0700, Fernando.Perez at colorado.edu wrote:

>inevitable few bugs which are always reported after a release.  I'd like to
>have a date from you for your course, and how close to it would be your time
>limit.  I can then wait until then to put out 0.6.12 with whatever other
>bugfixes I can get in.

It's thursday 3.3, so there's still two weeks. Take your time, but do
think of those unfortunate souls that are going to have a $HOME/.ipython
full of uneditable files on Windows ;-).




From Fernando.Perez at colorado.edu  Fri Feb 18 13:44:53 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 18 Feb 2005 11:44:53 -0700
Subject: [IPython-dev] ESC_QUOTE in InteractiveShell
In-Reply-To: <1108750564.8700.15.camel@ubuntu>
References: <20050218064759.GB9608@caltech.edu>
	<1108713003.42159e2c00b67@webmail.colorado.edu>
	<1108743071.8700.5.camel@ubuntu>
	<1108747976.421626c87c5ae@webmail.colorado.edu>
	<1108750564.8700.15.camel@ubuntu>
Message-ID: <421637A5.2010002@colorado.edu>

Ville Vainio wrote:
> On Fri, 2005-02-18 at 10:32 -0700, Fernando.Perez at colorado.edu wrote:
> 
> 
>>inevitable few bugs which are always reported after a release.  I'd like to
>>have a date from you for your course, and how close to it would be your time
>>limit.  I can then wait until then to put out 0.6.12 with whatever other
>>bugfixes I can get in.
> 
> 
> It's thursday 3.3, so there's still two weeks. Take your time, but do
> think of those unfortunate souls that are going to have a $HOME/.ipython
> full of uneditable files on Windows ;-).

No worries, that's actually a good deadline.  I'm also co-teaching a python 
workshop (with John Hunter of matplotlib fame) on Sunday 3.6, so I'd have .12 
out by then.  There's also a new problem because debian removed the profiler 
module from their python free package, so now ipython doesn't work under 
debian.  That kind of forced my hand no matter what.

Regards,

f



From Fernando.Perez at colorado.edu  Fri Feb 18 18:59:01 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 18 Feb 2005 16:59:01 -0700
Subject: [IPython-dev] Re: some trouble with screen formatting in ipython
In-Reply-To: <mailman.3733.1108763185.895.ipython-dev@scipy.net>
References: <mailman.3733.1108763185.895.ipython-dev@scipy.net>
Message-ID: <42168145.1080505@colorado.edu>

Hi,

I've added you to the ipython-dev whitelist, by default non-subscriber posts 
are discarded (too much spam).

ipython-dev-bounces at scipy.net wrote:
> Subject: Re: some trouble with screen formatting in ipython
> From: Dennis Heuer <dh at triple-media.com>
> Date: Fri, 18 Feb 2005 21:50:00 +0000
> To: ipython-dev at scipy.net
> 
> I write to here because I refuse to create the next zillion'st accout for another bugzilla engine (really hate these beasts).
> 
> There was a correspondence with fperez before this mail, which I post first:
> 
> Dennis Heuer wrote:
> 
>>Hello
>>
>>Up to the latest release, ipython produces some errors on my terminal. For
>>example, the 'out' prompt is placed on the center of the line though there
>>is no such hint in the prompt definition. When I define colors for the
>>prompt, they are valid for only the single line that contains the color
>>definition. The next line starts with the default color. The 'history'
>>number appears in green, though -- and it refuses own color settings. When
>>I define: '\C_Red\#', I still get a green number.
>>
>>I've set $TERM to different terminals but without success. The errors
>>appear on both my framebuffer shell and my (native X) nvidia-based
>>gnome-terminal.
> 
> 
> I'm sorry, but I can't reproduce any of this behavior.  Try nuking your ~/.
> ipython directory to start with a fresh one, and see if that helps. Otherwise, 
> please post again to the list, in case a user may have seen in the past 
> something similar and can help.  Also post with detailed system info (OS, 
> python version, ipython version, etc.).
> 
> I've tested with the framebuffer console, xterm, gnome-terminal, KDE's konsole 
> (my normal environment) and an Xemacs shell buffer (which I also use 
> extensively).  They all work as expected, so I'm at a loss to guess what may 
> be going on.
> 
> 
>>And, CTRL-D only quits if the cursor is on a fresh line. Shouldn't it
>>always work?
> 
> 
> No, try it in a plain python prompt and you'll see it's the same as ipython. I 
> can't get the EOF exception from the middle of a line, so there's nothing I 
> can do about it.
> 
> Best,
> 
> fperez
> 
> 
> First to CTRL-D because that's the more simple issue: Is anybody having contacts to the python developers to tell them that the above explained restriction is quite annoying...

If you care about this, you'll have to follow it up yourself.  It's not an 
issue for me, and I am swamped with other things.  Since it's core python 
behavior, I can't deal with it as an ipython-specific bug.

> Second: I nuked ~/.ipython and reinstalled ipython but still have the same trouble. I appended a screenshot for demonstration. The only line of configuration I've changed is the 'in'-prompt definition in ~/.ipython/ipythonrc-pysh:
> 
> prompt_in1 '\C_LightGreen\u@\h\C_LightBlue[\C_LightCyan\Y1\C_LightBlue]\C_Red|\#>'
> 
> As you can see in the screenshot, the # is still green. And, the 'out' prompt appears at the center of the line (it seems to be placed adjusted to the 'in' prompt, but from the right end. I could not find such a flag or prompt definition in the rc files, though).
> 
> Do I have to activate or de-activate something somewhere else?

OK, your screenshot gives much better info.  There's an important difference 
between 'hello' and 'print "hello"'.  The first _returns_ a value, hence there 
is a return prompt.  The second prints to stdout, and does not return anything 
(well, it returns None, technically).  By default, ipython aligns the output 
prompt with the input.  While this may look a little funny in pysh, it looks 
very natural in plain ipython with numbered In/Out prompts.

I'll try to add an option for flush left prompts in a convenient manner, as 
this is a reasonable request.  I'll also allow empty output prompts if you 
want: while I personally don't like this (I like to know the difference 
between a return value --which is cached-- and plain print statements), it's 
up to the users.

As far as the green \#, this is a minor bug of the coloring code due to the 
vagaries of history.   While the color strings allow you to control the 
coloring of most elements, there are a few which are still controlled by the 
old ipython internal coloring code, which only accepts a global 'color scheme' 
choice.  So basically the input/output numbers are hardwired to the choice in 
the color scheme, and there are only 'Linux', 'LightBG' and 'NoColor' schemes 
to choose from.

This is a buglet, but I'm not sure right now I can spend too much time 
clearing it up, as it would basically force a rewrite of much of the prompt 
handling code to abstract out the color management into the prompt definition 
strings.  I've put it on the todo list, but for now I'm afraid that bug stays. 
  Minor as it sounds, a clean fix requires a ton of work.  That code is fairly 
tricky, due to the fact that computing on-screen string sizes with embedded 
color escapes is a bit delicate.

Regards,

f



From Fernando.Perez at colorado.edu  Sat Feb 19 05:58:49 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sat, 19 Feb 2005 03:58:49 -0700
Subject: [IPython-dev] Re: some trouble with screen formatting in ipython
In-Reply-To: <42168145.1080505@colorado.edu>
References: <mailman.3733.1108763185.895.ipython-dev@scipy.net>
	<42168145.1080505@colorado.edu>
Message-ID: <42171BE9.9020109@colorado.edu>

Fernando Perez wrote:

> I'll try to add an option for flush left prompts in a convenient manner, as 
> this is a reasonable request.  I'll also allow empty output prompts if you 
> want: while I personally don't like this (I like to know the difference 
> between a return value --which is cached-- and plain print statements), it's 
> up to the users.

Fixed in CVS, please see the new option for prompt padding in the rc file.

Best,

f



From dh at triple-media.com  Sat Feb 19 14:34:24 2005
From: dh at triple-media.com (Dennis Heuer)
Date: Sat, 19 Feb 2005 19:34:24 +0000
Subject: [IPython-dev] Re: some trouble with screen formatting in ipython
In-Reply-To: <42171BE9.9020109@colorado.edu> (from
	Fernando.Perez@colorado.edu on Sat Feb 19 11:58:49 2005)
References: <mailman.3733.1108763185.895.ipython-dev@scipy.net>
	<42168145.1080505@colorado.edu> <42171BE9.9020109@colorado.edu>
Message-ID: <1108841664l.1566l.0l@Foo>

Am 19.02.2005 11:58:49 schrieb(en) Fernando Perez:
> Fernando Perez wrote:
> 
> > I'll try to add an option for flush left prompts in a convenient manner, as 
> > this is a reasonable request.  I'll also allow empty output prompts if you 
> > want: while I personally don't like this (I like to know the difference 
> > between a return value --which is cached-- and plain print statements), it's 
> > up to the users.
> 
> Fixed in CVS, please see the new option for prompt padding in the rc file.
> 
> Best,
> 
> f


OK, I can live with no colors at the moment but the alignment problem is somewhat crucial and lets me ignore ipython completely. The point is that if there are two cases that align output differently, this is rather confusing than helpful. Second, when the input prompt is somewhat long (because of the full path name, for example) and the output prompt aligns to it, the often rather longer output is squeezed against the right border while the left area is fully left blank. This is of no help.

P.s.: Your statement to the coloring code made me think. Possibly, you want to control the screen too much and should rather go with default ncurses functions? Just an imagination (I don't know the code). Often, doing it all manually is the wrong choice.

Regards,

Dennis




From Fernando.Perez at colorado.edu  Sat Feb 19 16:00:14 2005
From: Fernando.Perez at colorado.edu (Fernando.Perez at colorado.edu)
Date: Sat, 19 Feb 2005 14:00:14 -0700
Subject: [IPython-dev] Re: some trouble with screen formatting in ipython
In-Reply-To: <1108841664l.1566l.0l@Foo>
References: <mailman.3733.1108763185.895.ipython-dev@scipy.net>
	<42168145.1080505@colorado.edu> <42171BE9.9020109@colorado.edu>
	<1108841664l.1566l.0l@Foo>
Message-ID: <1108846814.4217a8de40a49@webmail.colorado.edu>

Quoting Dennis Heuer <dh at triple-media.com>:

> Am 19.02.2005 11:58:49 schrieb(en) Fernando Perez:

> > Fixed in CVS, please see the new option for prompt padding in the rc file.

> OK, I can live with no colors at the moment but the alignment problem is
> somewhat crucial and lets me ignore ipython completely. The point is that if
> there are two cases that align output differently, this is rather confusing
> than helpful. Second, when the input prompt is somewhat long (because of the
> full path name, for example) and the output prompt aligns to it, the often
> rather longer output is squeezed against the right border while the left area
> is fully left blank. This is of no help.

Huh, did you actually read what I just said?

> > Fixed in CVS, please see the new option for prompt padding in the rc file.

It's fixed.  Everything you asked for (except for the coloring buglet, for
reasons I explained), is there.

> P.s.: Your statement to the coloring code made me think. Possibly, you want
> to control the screen too much and should rather go with default ncurses
> functions? Just an imagination (I don't know the code). Often, doing it all
> manually is the wrong choice.

Curses is not portable to win32, and though I don't use win32 myself, there is a
sizeable win32 user community for ipython.  But yes, in the future ipython will
evolve into a backend/frontend split, so that you can use any gui frontend you
want (IDLE, pycrust, a Qt shell, etc).

Regards,

f



From cmoad at indiana.edu  Mon Feb 21 09:46:59 2005
From: cmoad at indiana.edu (Charles Moad)
Date: Mon, 21 Feb 2005 09:46:59 -0500
Subject: [IPython-dev] Feature request/how?
Message-ID: <4219F463.1070306@indiana.edu>

I would like a new magic function, "time".  I am not quite ipython savvy 
enough yet to do this correctly I think.  Here is what I forsee.

In [1]: %time blah() # for example
Out[1]: 'Blah return value'
   Call took 0.432 seconds


The code I am thinking would be something like:

def magic_time(self,parameter_s=''):
	import timing
	timing.start()
	self.run_in_current(parameter_s) # ??? What here
	timing.finish()
	print '\n  Call took %.3f seconds\n' % (timing.milli / 1000.0,)

Thanks for any help you can give,
	Charlie



From Fernando.Perez at colorado.edu  Mon Feb 21 13:58:18 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 21 Feb 2005 11:58:18 -0700
Subject: [IPython-dev] Feature request/how?
In-Reply-To: <4219F463.1070306@indiana.edu>
References: <4219F463.1070306@indiana.edu>
Message-ID: <421A2F4A.7030900@colorado.edu>

Charles Moad wrote:
> I would like a new magic function, "time".  I am not quite ipython savvy 
> enough yet to do this correctly I think.  Here is what I forsee.
> 
> In [1]: %time blah() # for example
> Out[1]: 'Blah return value'
>    Call took 0.432 seconds

from IPython.genutils import timing,timings

look at their docstrings.

Cheers,

f



From cmoad at indiana.edu  Mon Feb 21 15:17:09 2005
From: cmoad at indiana.edu (Charles Moad)
Date: Mon, 21 Feb 2005 15:17:09 -0500
Subject: [IPython-dev] Feature request/how?
In-Reply-To: <421A2F4A.7030900@colorado.edu>
References: <4219F463.1070306@indiana.edu> <421A2F4A.7030900@colorado.edu>
Message-ID: <421A41C5.40804@indiana.edu>

	Thanks for the pointer.  I am still fuzzy on how I would create a magic 
function using this, since I need to run the parameter_s arg of the 
magic function in the current context.  timing/timings takes the 
actually function and args, not a string.

Thanks,

Fernando Perez wrote:
> Charles Moad wrote:
> 
>> I would like a new magic function, "time".  I am not quite ipython 
>> savvy enough yet to do this correctly I think.  Here is what I forsee.
>>
>> In [1]: %time blah() # for example
>> Out[1]: 'Blah return value'
>>    Call took 0.432 seconds
> 
> 
> from IPython.genutils import timing,timings
> 
> look at their docstrings.
> 
> Cheers,
> 
> f
> 
> 



From Fernando.Perez at colorado.edu  Tue Feb 22 01:44:24 2005
From: Fernando.Perez at colorado.edu (Fernando.Perez at colorado.edu)
Date: Mon, 21 Feb 2005 23:44:24 -0700
Subject: [IPython-dev] Feature request/how?
In-Reply-To: <421A41C5.40804@indiana.edu>
References: <4219F463.1070306@indiana.edu> <421A2F4A.7030900@colorado.edu>
	<421A41C5.40804@indiana.edu>
Message-ID: <1109054664.421ad4c88bf4b@webmail.colorado.edu>

Quoting Charles Moad <cmoad at indiana.edu>:

> 	Thanks for the pointer.  I am still fuzzy on how I would create a magic
> function using this, since I need to run the parameter_s arg of the
> magic function in the current context.  timing/timings takes the
> actually function and args, not a string.

It was quicker to just write the code rather than to explain how to do it.  Here
it is, it will go into the .12 release.  I still need to write a docstring for
it (that always takes longer than the actual code).

Best,

f

    def magic_time(self,parameter_s = ''):
        """Time execution of an expression which can be passed to eval().

        The value of the expression is returned."""

        # fail immediately if the given expression can't be compiled
        code = compile(parameter_s,'<timed evaluation>','eval')
        # skew measurement as little as possible
        glob = self.shell.user_ns
        clk = clock
        # time execution
        s = clk()
        out = eval(code,glob)
        tot = clk()-s
        print "Call time: %.2f s." % tot
        return out



From cmoad at indiana.edu  Tue Feb 22 09:29:31 2005
From: cmoad at indiana.edu (Charles Moad)
Date: Tue, 22 Feb 2005 09:29:31 -0500
Subject: [IPython-dev] Feature request/how?
In-Reply-To: <1109054664.421ad4c88bf4b@webmail.colorado.edu>
References: <4219F463.1070306@indiana.edu> <421A2F4A.7030900@colorado.edu>
	<421A41C5.40804@indiana.edu>
	<1109054664.421ad4c88bf4b@webmail.colorado.edu>
Message-ID: <421B41CB.7000004@indiana.edu>

	First of all, thanks for the code.  I am getting unexpected results 
however.  For example, "%time time.sleep(5)" shows "Call time: 0.00 s." 
  I also have xmlrpc calls that take about 60 seconds that show a call 
time of about 0.04 s.  Are we thinking of different things?
	Is it not possible to include assignment operators as well?  Only 
simple expressions seem to work.

Thanks again,
	Charlie

Fernando.Perez at colorado.edu wrote:
> Quoting Charles Moad <cmoad at indiana.edu>:
> 
> 
>>	Thanks for the pointer.  I am still fuzzy on how I would create a magic
>>function using this, since I need to run the parameter_s arg of the
>>magic function in the current context.  timing/timings takes the
>>actually function and args, not a string.
> 
> 
> It was quicker to just write the code rather than to explain how to do it.  Here
> it is, it will go into the .12 release.  I still need to write a docstring for
> it (that always takes longer than the actual code).
> 
> Best,
> 
> f
> 
>     def magic_time(self,parameter_s = ''):
>         """Time execution of an expression which can be passed to eval().
> 
>         The value of the expression is returned."""
> 
>         # fail immediately if the given expression can't be compiled
>         code = compile(parameter_s,'<timed evaluation>','eval')
>         # skew measurement as little as possible
>         glob = self.shell.user_ns
>         clk = clock
>         # time execution
>         s = clk()
>         out = eval(code,glob)
>         tot = clk()-s
>         print "Call time: %.2f s." % tot
>         return out
> 
> 



From vivainio at kolumbus.fi  Tue Feb 22 10:59:51 2005
From: vivainio at kolumbus.fi (Ville Vainio)
Date: Tue, 22 Feb 2005 17:59:51 +0200
Subject: [IPython-dev] Feature request/how?
In-Reply-To: <421B41CB.7000004@indiana.edu>
References: <4219F463.1070306@indiana.edu> <421A2F4A.7030900@colorado.edu>
	<421A41C5.40804@indiana.edu>
	<1109054664.421ad4c88bf4b@webmail.colorado.edu>
	<421B41CB.7000004@indiana.edu>
Message-ID: <1109087992.11518.5.camel@localhost.localdomain>

On Tue, 2005-02-22 at 09:29 -0500, Charles Moad wrote:

>	Is it not possible to include assignment operators as well?  Only 
>simple expressions seem to work.

Yeah, that's because the code uses eval instead of exec. It might make
more sense to use exec.

However, I can't help but think something like this should be done with
the "timeit" module. I don't know if there is a way to force it to use
ipython's namespace instead of the namespace of timeit-module - perhaps
this is something that could be done with a patch to the timeit module.




From Fernando.Perez at colorado.edu  Tue Feb 22 14:05:16 2005
From: Fernando.Perez at colorado.edu (Fernando.Perez at colorado.edu)
Date: Tue, 22 Feb 2005 12:05:16 -0700
Subject: [IPython-dev] Feature request/how?
In-Reply-To: <421B41CB.7000004@indiana.edu>
References: <4219F463.1070306@indiana.edu> <421A2F4A.7030900@colorado.edu>
	<421A41C5.40804@indiana.edu>
	<1109054664.421ad4c88bf4b@webmail.colorado.edu>
	<421B41CB.7000004@indiana.edu>
Message-ID: <1109099116.421b826c298bc@webmail.colorado.edu>

Quoting Charles Moad <cmoad at indiana.edu>:

> 	First of all, thanks for the code.  I am getting unexpected results
> however.  For example, "%time time.sleep(5)" shows "Call time: 0.00 s."
>   I also have xmlrpc calls that take about 60 seconds that show a call
> time of about 0.04 s.  Are we thinking of different things?

This is expected: the code I gave you uses genutils.clock(), which is written
(at least on Unix) to report only true CPU time.  A sleep() call doesn't
consume almost any cpu time at all.  Feel free to make a modified version of
this function which uses other timing routines from the time module if you want
wall clock time.  As far as I'm concerned, reporting wall clock time is in most
cases a bug, since it's completely context dependent.  But there are valid
cases for wanting it, so you could for example add a -w switch to this function
to use a wall clock instead.

> 	Is it not possible to include assignment operators as well?  Only
> simple expressions seem to work.

It's possible, but you'll have to make the code a bit more complicated.  You
can't return anything, since an assignment is a statement, and not an
expression.  I don't have time right now to work on coding all the
alternatives, but if you want to do so, read up on compile, exec and eval. 
Those are the three calls you'll need to combine to make it work.

Regards,

f



From Fernando.Perez at colorado.edu  Tue Feb 22 14:09:13 2005
From: Fernando.Perez at colorado.edu (Fernando.Perez at colorado.edu)
Date: Tue, 22 Feb 2005 12:09:13 -0700
Subject: [IPython-dev] Feature request/how?
In-Reply-To: <1109087992.11518.5.camel@localhost.localdomain>
References: <4219F463.1070306@indiana.edu> <421A2F4A.7030900@colorado.edu>
	<421A41C5.40804@indiana.edu>
	<1109054664.421ad4c88bf4b@webmail.colorado.edu>
	<421B41CB.7000004@indiana.edu>
	<1109087992.11518.5.camel@localhost.localdomain>
Message-ID: <1109099353.421b83591c2b4@webmail.colorado.edu>

Quoting Ville Vainio <vivainio at kolumbus.fi>:

> On Tue, 2005-02-22 at 09:29 -0500, Charles Moad wrote:
>
> >	Is it not possible to include assignment operators as well?  Only
> >simple expressions seem to work.
>
> Yeah, that's because the code uses eval instead of exec. It might make
> more sense to use exec.

But if you use exec, there's nothing to return, which the OP wanted.  The
generic solution has to check whether the given code compiles as an expression
or not, and use eval/return or exec/no return accordingly.  That's what I
suggested.

> However, I can't help but think something like this should be done with
> the "timeit" module. I don't know if there is a way to force it to use
> ipython's namespace instead of the namespace of timeit-module - perhaps
> this is something that could be done with a patch to the timeit module.

Yes, but timeit is python 2.3 only, and I still support 2.2.  That's why I went
with a more pedestrian approach.

Best,

f



From vivainio at kolumbus.fi  Tue Feb 22 16:24:03 2005
From: vivainio at kolumbus.fi (Ville Vainio)
Date: Tue, 22 Feb 2005 23:24:03 +0200
Subject: [IPython-dev] Feature request/how?
In-Reply-To: <1109099116.421b826c298bc@webmail.colorado.edu>
References: <4219F463.1070306@indiana.edu> <421A2F4A.7030900@colorado.edu>
	<421A41C5.40804@indiana.edu>
	<1109054664.421ad4c88bf4b@webmail.colorado.edu>
	<421B41CB.7000004@indiana.edu>
	<1109099116.421b826c298bc@webmail.colorado.edu>
Message-ID: <1109107444.14685.4.camel@localhost.localdomain>

On Tue, 2005-02-22 at 12:05 -0700, Fernando.Perez at colorado.edu wrote:

>This is expected: the code I gave you uses genutils.clock(), which is written
>(at least on Unix) to report only true CPU time.  A sleep() call doesn't
>consume almost any cpu time at all.  Feel free to make a modified version of
>this function which uses other timing routines from the time module if you want
>wall clock time.  As far as I'm concerned, reporting wall clock time is in most
>cases a bug, since it's completely context dependent.  But there are valid
>cases for wanting it, so you could for example add a -w switch to this function
>to use a wall clock instead.

I'd be tempted to think that wall clock time should be the default.
Isn't CPU time quite arbitrary measurement if the problem is I/O bound?
timeit module also measures wallclock time (using time.time() on posix).

Knowing the wallclock time is also necessary to see whether the solution
under experimentation will fly in a real application. It's hard to get
an intuitive grasp from CPU time.




From Fernando.Perez at colorado.edu  Tue Feb 22 16:32:33 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 22 Feb 2005 14:32:33 -0700
Subject: [IPython-dev] Feature request/how?
In-Reply-To: <1109107444.14685.4.camel@localhost.localdomain>
References: <4219F463.1070306@indiana.edu> <421A2F4A.7030900@colorado.edu>
	<421A41C5.40804@indiana.edu>	<1109054664.421ad4c88bf4b@webmail.colorado.edu>
	<421B41CB.7000004@indiana.edu>	<1109099116.421b826c298bc@webmail.colorado.edu>
	<1109107444.14685.4.camel@localhost.localdomain>
Message-ID: <421BA4F1.9050006@colorado.edu>

Ville Vainio wrote:
> On Tue, 2005-02-22 at 12:05 -0700, Fernando.Perez at colorado.edu wrote:
> 
> 
>>This is expected: the code I gave you uses genutils.clock(), which is written
>>(at least on Unix) to report only true CPU time.  A sleep() call doesn't
>>consume almost any cpu time at all.  Feel free to make a modified version of
>>this function which uses other timing routines from the time module if you want
>>wall clock time.  As far as I'm concerned, reporting wall clock time is in most
>>cases a bug, since it's completely context dependent.  But there are valid
>>cases for wanting it, so you could for example add a -w switch to this function
>>to use a wall clock instead.
> 
> 
> I'd be tempted to think that wall clock time should be the default.
> Isn't CPU time quite arbitrary measurement if the problem is I/O bound?
> timeit module also measures wallclock time (using time.time() on posix).
> 
> Knowing the wallclock time is also necessary to see whether the solution
> under experimentation will fly in a real application. It's hard to get
> an intuitive grasp from CPU time.

Well, I guess we just come from different backgrounds.  For me, cpu time is 
pretty much the only relevant number 99% of the time, but that's because I 
work in scientific computing problems which are not I/O bound.  For others, 
wall time may be what matters (I said as much above: "As far as I'm concerned, 
reporting wall clock time is in most cases a bug", note the _I_ in that quote).

I am unfortunately completely swamped right now, and can't afford to write a 
nice, generic, flexible timing magic which can address all valid usage cases. 
  If anyone volunteers a patch, I'll gladly include it (it's not hard). 
Otherwise, the basic, cpu-bound %time I wrote stays.  As is, it will be quite 
useful to scientific computing types (my most significant target market).

Regards,

f



From ariciputi at pito.com  Wed Feb 23 05:24:54 2005
From: ariciputi at pito.com (Andrea Riciputi)
Date: Wed, 23 Feb 2005 11:24:54 +0100
Subject: [IPython-dev] GTK warning.
Message-ID: <28BD6A6D-8585-11D9-824E-000A95C0BC68@pito.com>

I was working with version 0.6.11 when I noticed the following warning 
message:

> ibook:~ andrea$ ipython -pylab
>
> ** (ipython:29305): WARNING **: `GtkTextSearchFlags' is not an enum 
> type
> Python 2.3.4 (#1, Aug 30 2004, 11:02:41)
> Type "copyright", "credits" or "license" for more information.
>
> IPython 0.6.11 -- An enhanced Interactive Python.
> ?       -> Introduction to IPython's features.
> %magic  -> Information about IPython's 'magic' % functions.
> help    -> Python's own help system.
> object? -> Details about 'object'. ?object also works, ?? prints more.
>
>   Welcome to pylab, a matplotlib-based Python environment
>     help(matplotlib) -> generic matplotlib information
>     help(pylab)      -> matlab-compatible commands from matplotlib
>     help(plotting)   -> plotting commands

Nevertheless plotting functionalities seem to work correctly.

HTH,
  Andrea.



From Fernando.Perez at colorado.edu  Wed Feb 23 08:06:13 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 23 Feb 2005 06:06:13 -0700
Subject: [IPython-dev] GTK warning.
In-Reply-To: <28BD6A6D-8585-11D9-824E-000A95C0BC68@pito.com>
References: <28BD6A6D-8585-11D9-824E-000A95C0BC68@pito.com>
Message-ID: <421C7FC5.9020201@colorado.edu>

Andrea Riciputi wrote:
> I was working with version 0.6.11 when I noticed the following warning 
> message:
> 
> 
>>ibook:~ andrea$ ipython -pylab
>>
>>** (ipython:29305): WARNING **: `GtkTextSearchFlags' is not an enum 

Mmh.  What is your matplotlib backend? Gtk or GtkAgg?  I don't directly use 
much of gtk, so it's possible that this is triggered by the pylab backend code.

I should also note that under linux (fedora3) I don't see it, so it may well 
be a pygtk/gtk version thing.

If it continues to be a bother as you update versions of pygtk/gtk/matplotlib, 
   I'd suggest informing the matplotlib list directly, since I suspect this is 
on their side of things.

Best,

f



From ariciputi at pito.com  Wed Feb 23 09:05:32 2005
From: ariciputi at pito.com (Andrea Riciputi)
Date: Wed, 23 Feb 2005 15:05:32 +0100
Subject: [IPython-dev] GTK warning.
In-Reply-To: <421C7FC5.9020201@colorado.edu>
References: <28BD6A6D-8585-11D9-824E-000A95C0BC68@pito.com>
	<421C7FC5.9020201@colorado.edu>
Message-ID: <FAF1F1A8-85A3-11D9-824E-000A95C0BC68@pito.com>

The warning appears with both Gtk and GtkAgg. But probably you are 
right, it is a version problem. My pygtk/gtk and matplotlib are a 
little bit outdated. Unfortunately, the deadline for my PhD thesis is 
approaching and I have no time now to play with these sort of things. 
When the discussion will be over, I'll try to fix it and I'll let you 
know.

Thanks,
  Andrea.

On 23 Feb 2005, at 14:06, Fernando Perez wrote:

> Mmh.  What is your matplotlib backend? Gtk or GtkAgg?  I don't 
> directly use much of gtk, so it's possible that this is triggered by 
> the pylab backend code.
>
> I should also note that under linux (fedora3) I don't see it, so it 
> may well be a pygtk/gtk version thing.
>
> If it continues to be a bother as you update versions of 
> pygtk/gtk/matplotlib,   I'd suggest informing the matplotlib list 
> directly, since I suspect this is on their side of things.
>
> Best,
>
> f