From gb at cs.unc.edu  Mon Jun  2 14:37:57 2003
From: gb at cs.unc.edu (Gary Bishop)
Date: Mon, 02 Jun 2003 14:37:57 EDT
Subject: [IPython-dev] Patch for IPython with color on windows
Message-ID: <200306021838.h52IbvXo005348@wren.cs.unc.edu>

I have attached a patch that, along with my readline package, will make 
IPython function in glorious color, with completion, line editing, 
history on Windows (only tested on XP).

I don't *think* these changes impact other ports but I certainly could 
be wrong since I haven't tested anywhere else.

Most of the changes are of the form:

-            print header,output,
+            print >>ColorTerm.out, header,output,

These send prints that could contain color escapes explicitly to a file 
object instead of relying on sys.stdout. ColorTerm.out and 
ColorTerm.err are initialized to sys.stdout and sys.stderr, so 
everything should work the same. On Windows, a user may optionally 
include the following in his IPYTHONDIR

enable_color.py
===================
'''Turn on the translation of ANSI color escapes for Windows'''

import IPython
import readline

out = readline.GetOutputFile()
IPython.genutils.ColorTerm.out = out
IPython.genutils.ColorTerm.err = out
del out
del readline
del IPython
=====================

and this line in ipythonrc.ini

execfile enable_color.py

To translate ANSI color escapes into the proper colors on the Windows 
console. Without this it will work fine without color.

The second change included in these patches makes "less" work properly 
as the pager on Windows. I'm using the cygwin port of less. It doesn't 
want to work properly with popen2 so I added a clause to "page" in 
genutils to make it page from a file.

The third change is the result of our previous exchange on getting \ 
escapes to work. This variant seems to work fine.

I'll be happy to help in any way I can to get these or some better 
variant into IPython.

My readline code is now available via CVS from
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/uncpythontools/readline/

gb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diffs
Type: application/octet-stream
Size: 7735 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20030602/c49b4d49/attachment.obj>

From fperez at colorado.edu  Mon Jun  2 15:03:44 2003
From: fperez at colorado.edu (Fernando Perez)
Date: Mon, 02 Jun 2003 13:03:44 -0600
Subject: [IPython-dev] Patch for IPython with color on windows
In-Reply-To: <200306021838.h52IbvXo005348@wren.cs.unc.edu>
References: <200306021838.h52IbvXo005348@wren.cs.unc.edu>
Message-ID: <3EDB9F90.7070200@colorado.edu>

Hi Gary,

thanks a lot for this work.  Sorry if I've been a bit slow to respond, I'm 
super-swamped with 'real' work, and what little free time I've had, I've spent 
it as far as possible from a computer :)  But as soon as I find a minute I'll 
get on to this, we'll hash it a bit and get it into the mainline.

I'm sure that Windows users will greatly appreciate your changes, since they 
seem to bring ipython there up to the quality level of the unix side.

So thanks again, and please rest assured that I'll get to work on this.

Best,

f.



From gb at cs.unc.edu  Tue Jun 10 16:24:48 2003
From: gb at cs.unc.edu (Gary Bishop)
Date: Tue, 10 Jun 2003 16:24:48 EDT
Subject: [IPython-dev] IPython bug in tracebacks
Message-ID: <200306102024.h5AKOmXo007158@wren.cs.unc.edu>

The cool traceback printing code in ultraTB.py fails if a program uses 
a module from the current directory but changes it works directory 
before the traceback.

The problem originates in inspect.getinnerframes in VerboseTB.text. 
getinnerframes calls inspect.getsourcefile which insists on 
os.path.exists(filename) before it will return filename. Problem is 
after the chdir, os.path.exists will return false for things that 
aren't full pathnames.

I think this is a bug in inspect and I have posted a message to 
comp.lang.python expressing that opinion. We'll see if it gets a 
response. Meantime, watch out for this problem in IPython.

gb


From fperez at colorado.edu  Tue Jun 10 20:38:05 2003
From: fperez at colorado.edu (Fernando Perez)
Date: Tue, 10 Jun 2003 18:38:05 -0600
Subject: [IPython-dev] IPython bug in tracebacks
In-Reply-To: <200306102024.h5AKOmXo007158@wren.cs.unc.edu>
References: <200306102024.h5AKOmXo007158@wren.cs.unc.edu>
Message-ID: <3EE679ED.3080508@colorado.edu>

Gary Bishop wrote:
> The cool traceback printing code in ultraTB.py fails if a program uses 
> a module from the current directory but changes it works directory 
> before the traceback.
> 
> The problem originates in inspect.getinnerframes in VerboseTB.text. 
> getinnerframes calls inspect.getsourcefile which insists on 
> os.path.exists(filename) before it will return filename. Problem is 
> after the chdir, os.path.exists will return false for things that 
> aren't full pathnames.
> 
> I think this is a bug in inspect and I have posted a message to 
> comp.lang.python expressing that opinion. We'll see if it gets a 
> response. Meantime, watch out for this problem in IPython.

I think I recall recently running into another inspect problem which sounds 
similar.  But unfortunately I can't quite recall exactly what it was.  inspect 
  seems to have been coded with rather 'optimistic' assumptions in many 
places, and it seems to produce not too graceful failures rather easily.  I 
wish I'd been a bit more diligent in documenting this, so I could submit a 
patch for inspect itself (besides building a workaround in ipython).

Thanks for the heads-up, though.

My university's news server seems to be down, so I'll have to wait for the 
google archives to pick up this thread before I can read it.

Best,

f.



From christopher.drexler at siemens.com  Thu Jun 26 08:24:15 2003
From: christopher.drexler at siemens.com (Drexler Christopher)
Date: Thu, 26 Jun 2003 14:24:15 +0200
Subject: [IPython-dev] Ipython and Tkinter
Message-ID: <CB0365D517B7D611B5E100508B9498B6022A9B95@erlh904a.med.siemens.de>

Hello everyone,

does anybody have experiences with ipython 0.4.0, readline and Tkinter
in a Win32 (XP) environment. On starting Tkinter.Tk() the readline interface
gets unusable: the cursor keys are not recognized any more. 

test case from within ipython:

import Tkinter
r = Tkinter.Tk()


Any ideas?

Best Regards,
Chris


From fperez at colorado.edu  Thu Jun 26 19:29:33 2003
From: fperez at colorado.edu (Fernando Perez)
Date: Thu, 26 Jun 2003 17:29:33 -0600
Subject: [IPython-dev] Ipython and Tkinter
In-Reply-To: <CB0365D517B7D611B5E100508B9498B6022A9B95@erlh904a.med.siemens.de>
References: <CB0365D517B7D611B5E100508B9498B6022A9B95@erlh904a.med.siemens.de>
Message-ID: <3EFB81DD.7090801@colorado.edu>

Drexler Christopher wrote:
> Hello everyone,
> 
> does anybody have experiences with ipython 0.4.0, readline and Tkinter in a
> Win32 (XP) environment. On starting Tkinter.Tk() the readline interface 
> gets unusable: the cursor keys are not recognized any more.
> 
> test case from within ipython:
> 
> import Tkinter 
 > r = Tkinter.Tk()

Well, just to provide a simple data point, the problem isn't there under 
Linux.  But unfortunately I haven't the foggiest idea as to what may be going 
on under Windows.

Best,

f.