From fperez at colorado.edu Mon Dec 1 16:49:41 2003 From: fperez at colorado.edu (Fernando Perez) Date: Mon, 01 Dec 2003 14:49:41 -0700 Subject: [IPython-dev] Updates to CVS: tab completion and Windows coloring Message-ID: <3FCBB775.6080004@colorado.edu> Hi all, today I've committed a fair amount of changes to CVS, mainly from the contributions of Jeff Collins and Gary Bishop. I'd like to give all a brief update on this, since it would be great to see some testing of this code as I start cleaning things up for a new release. - Jeff's work: it fixes tab completion for filenames under python 2.3, which broke because the python developers changed the hardcoded behavior of the readline library. One small caveat: under redhat 8.0, I am seeing an extraneous space appended to completed filenames. Jeff helped me track its source, and it is an improperly built readline.so by redhat, which is missing the rl_completion_append_character variable. This variable can NOT be set via python code, so there's nothing I can do about it. Redhat 9's python, and almost any correctly built python, should not exhibit this small annoyance. - Gary's work: this allows coloring under Windows, with some extra code provided by Gary. Please note that I modified his patches somewhat, in particular I renamed ColorTerm to Term because in the future I'll be using this facility for all I/O, not just coloring. So I'm reposting his instructions here with the necessary changes for the benefit of Windows users: ################################# Gary's instructions for Windows, modified to work with the current CVS ipython: I have attached a patch for IPython 0.5-cvs that, along with my readline package, will make IPython on Windows work like it does on more capable systems. My readline code is available via CVS from http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/uncpythontools/readline/ I use it inside and outside IPython and it seems to work fine. I don't think these changes impact other platforms 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 >>Term.out, header,output, These send prints that could contain color escapes explicitly to a file object instead of relying on sys.stdout. Term.out and Term.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.Term.out = out IPython.genutils.Term.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. ################################# Gary: I'd also like you to help me with a couple of things concerning this code. 1. You made changes to page(), to make it work with 'less' under windows+cygwin. I want to be sure that users who DON'T have cygwin are still ok. Is that the case? 2. The code below is around line 913 of genutils.py. Do you know which exceptions can this trigger under Windows, so we only trap those? I don't like blanket except clauses (ipython has many, but I'm trying to clean them up as much as possible). I also added the inner try/finally to ensure proper cleanup. try: try: tmpname = tempfile.mktemp('.txt') tmpfile = file(tmpname,'wt') tmpfile.write(strng) tmpfile.close() cmd = pager_cmd + ' < ' + tmpname os.system(cmd) retval = None finally: os.remove(tmpname) except: # FIXME: trap only the reasonable exceptions retval = 1 You can send me any new patches against current CVS. Ok folks, I'll be working some more on ipython over the next few weeks, to finish cleaning up some other things. But these two big changes are important enough that I'd really like to hear some feedback, especially if there are problems. Many thanks to Jeff and Gary, both for their work and for their patience with my sloooow response. Regards, Fernando. From gb at cs.unc.edu Wed Dec 3 11:00:47 2003 From: gb at cs.unc.edu (Gary Bishop) Date: Wed, 03 Dec 2003 11:00:47 EST Subject: [IPython-dev] Updates to CVS: tab completion and Windows coloring Message-ID: <200312031600.hB3G0lFB002614@wren.cs.unc.edu> On Mon, 01 Dec 2003 14:49:41 -0700 "Fernando Perez" wrote: > Gary: I'd also like you to help me with a couple of things concerning > this code. > 1. You made changes to page(), to make it work with 'less' under > windows+cygwin. I want to be sure that users who DON'T have cygwin are > still ok. Is that the case? I will test this. I believe it will fall back to the default as it should. It *may* even work with the windows more like it should. > 2. The code below is around line 913 of genutils.py. Do you know > which exceptions can this trigger under Windows, so we only trap those? > I don't like blanket except clauses (ipython has many, but I'm trying > to clean them up as much as possible). I also added the inner > try/finally to ensure proper cleanup. > try: > try: > tmpname = tempfile.mktemp('.txt') > tmpfile = file(tmpname,'wt') > tmpfile.write(strng) > tmpfile.close() > cmd = pager_cmd + ' < ' + tmpname > os.system(cmd) > retval = None > finally: > os.remove(tmpname) > except: # FIXME: trap only the reasonable exceptions > retval = 1 > You can send me any new patches against current CVS. I'll check. > Ok folks, I'll be working some more on ipython over the next few weeks, > to finish cleaning up some other things. But these two big changes are > important enough that I'd really like to hear some feedback, especially > if there are problems. I'm super busy right now with the end of the semester and a grant proposal but I'll get to this (hopefully) soon. From fperez at colorado.edu Wed Dec 3 12:53:09 2003 From: fperez at colorado.edu (Fernando Perez) Date: Wed, 03 Dec 2003 10:53:09 -0700 Subject: [IPython-dev] Re: ipython cvs on NT4 with readline and color In-Reply-To: <3FCDEE36.1792.F85A0F@localhost> References: <3FCDEE36.1792.F85A0F@localhost> Message-ID: <3FCE2305.3060905@colorado.edu> Hi Sean, I'm replying with copy to the ipython list, in case one of the Windows experts can also comment on this (Gary?) Sean David Richards wrote: > Hi Fernando, > > Thanks for creating such a great tool ! Thanks for the kind comments, I'm glad you find it useful. > I have been using ipython for a while now primarily on my Linux box at home, > but also on NT4 on my office machine at university. Saw your latest posting > on the ipython-dev list about readline and colors with ipython on windows. > This is a great step forward as lack of readline on windows is a real curse. > Setting it all up is easy though there are a couple of minor points. I know > you don't work on windows but you could perhaps pass these on to the relevant > person(s). > > Console.py in the readline package is version specific. i.e it is hard > coded to use python22. Line 177 is ... > self.inputHookPtr = > c_int.from_address(addressof(cdll.python22.PyOS_InputHook)).value > > Colors and readline work fine (after fixing the above) however the python > prompt is now garbled with a+?x instead of >>> > > I will keep an eye on the ipython mailing lists (I just read the web > archives) to see if there is any resolution and if I manage to make any > progress myself will let you know. Thanks for this info, and if you or anyone else makes any progress on this, please post to the list (or privately). Once this settles a bit, I'll add a section to the manual on how to do the Windows configuration. Perhaps Gary or another windows user can sketch a minimal writeup of the necessary steps? It can be mailed to me in any format, but either plain text or LyX/TeX would be better than word processing formats. Gary, I just saw your message about how busy you are, so don't worry. I very much appreciate your contributions already, and I'm still working on some Gnuplot and localization bugs (not in cvs yet), so there's no rush. Best, Fernando. From gb at cs.unc.edu Wed Dec 3 13:40:06 2003 From: gb at cs.unc.edu (Gary Bishop) Date: Wed, 03 Dec 2003 13:40:06 EST Subject: [IPython-dev] Re: ipython cvs on NT4 with readline and color Message-ID: <200312031840.hB3Ie6FB011757@wren.cs.unc.edu> Sean, How did you fix the reference to the python22 dll? Using the version string somehow? Also, I don't see the garbling here but I haven't tried Python23 either, maybe it is related. It would be a great help if you could edit Console.py up at the top and change the 0 in the logging code to a 1 and run it. # primitive debug printing that won't interfere with the screen if 0: <--- change this to 1 fp = open('debug.txt', 'w') def log(s): print >>fp, s fp.flush() else: def log(s): pass Then run it and look at the resulting debug.txt file. It should show the characters that got sent in. Thanks gb On Wed, 03 Dec 2003 10:53:09 -0700 "Fernando Perez" wrote: > Hi Sean, > I'm replying with copy to the ipython list, in case one of the Windows > experts can also comment on this (Gary?) > Sean David Richards wrote: >> Hi Fernando, >> Thanks for creating such a great tool ! > Thanks for the kind comments, I'm glad you find it useful. >> I have been using ipython for a while now primarily on my Linux box at >> home, but also on NT4 on my office machine at university. Saw your >> latest posting on the ipython-dev list about readline and colors with >> ipython on windows. This is a great step forward as lack of readline on >> windows is a real curse. Setting it all up is easy though there are a >> couple of minor points. I know you don't work on windows but you could >> perhaps pass these on to the relevant person(s). >> Console.py in the readline package is version specific. i.e it is hard >> coded to use python22. Line 177 is ... >> self.inputHookPtr = >> c_int.from_address(addressof(cdll.python22.PyOS_InputHook)).value >> Colors and readline work fine (after fixing the above) however the >> python prompt is now garbled with a+?x instead of >>> >> I will keep an eye on the ipython mailing lists (I just read the web >> archives) to see if there is any resolution and if I manage to make any >> progress myself will let you know. > Thanks for this info, and if you or anyone else makes any progress on > this, please post to the list (or privately). Once this settles a bit, > I'll add a section to the manual on how to do the Windows > configuration. Perhaps Gary or another windows user can sketch a > minimal writeup of the necessary steps? It can be mailed to me in any > format, but either plain text or LyX/TeX would be better than word > processing formats. > Gary, I just saw your message about how busy you are, so don't worry. > I very much appreciate your contributions already, and I'm still > working on some Gnuplot and localization bugs (not in cvs yet), so > there's no rush. > Best, > Fernando. > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.net > http://scipy.net/mailman/listinfo/ipython-dev From fperez at colorado.edu Thu Dec 4 15:41:18 2003 From: fperez at colorado.edu (Fernando Perez) Date: Thu, 04 Dec 2003 13:41:18 -0700 Subject: [IPython-dev] IPython lists and spam: good news Message-ID: <3FCF9BEE.3060005@colorado.edu> Hi all, I know you've all been frustrated with the spam flow as of late. With Joe Cooper's (SciPy admin) help, I finally found the right options to change in mailman. As of now, non-subscriber posts will be held for me to moderate, so hopefully you shouldn't see any more random spam coming in from the outside world. However, if I start getting too many requests (which I just don't have the time to deal with), I'll flat out block non-subscriber posts with a 'discard' option. I hope this improves things a bit for everyone. Best regards, Fernando. From fperez at colorado.edu Thu Dec 4 16:56:31 2003 From: fperez at colorado.edu (Fernando Perez) Date: Thu, 04 Dec 2003 14:56:31 -0700 Subject: [IPython-dev] Testing the new filtering rules... Message-ID: <3FCFAD8F.9020002@colorado.edu> Please ignore this, we're just testing that subscribers can still post with the new setup. -- 2nd try f. From mathew at yeates.tv Sat Dec 6 15:41:44 2003 From: mathew at yeates.tv (Mathew Yeates) Date: Sat, 06 Dec 2003 12:41:44 -0800 Subject: [IPython-dev] Still no color on Windows XP In-Reply-To: <3FCBB775.6080004@colorado.edu> References: <3FCBB775.6080004@colorado.edu> Message-ID: <3FD23F08.4050501@yeates.tv> I still get no color. And the prompt is a bunch of weird characters. I turned on readlines logging and I get the following at the bottom of the log prompt="'`\xd7\xc5w'" C:`??w attr=None C: attr=None any ideas? Mathew Fernando Perez wrote: > Hi all, > > today I've committed a fair amount of changes to CVS, mainly from the > contributions of Jeff Collins and Gary Bishop. I'd like to give all a > brief update on this, since it would be great to see some testing of > this code as I start cleaning things up for a new release. > > - Jeff's work: it fixes tab completion for filenames under python 2.3, > which broke because the python developers changed the hardcoded > behavior of the readline library. > > One small caveat: under redhat 8.0, I am seeing an extraneous space > appended to completed filenames. Jeff helped me track its source, and > it is an improperly built readline.so by redhat, which is missing the > rl_completion_append_character variable. This variable can NOT be set > via python code, so there's nothing I can do about it. Redhat 9's > python, and almost any correctly built python, should not exhibit this > small annoyance. > > - Gary's work: this allows coloring under Windows, with some extra > code provided by Gary. Please note that I modified his patches > somewhat, in particular I renamed ColorTerm to Term because in the > future I'll be using this facility for all I/O, not just coloring. So > I'm reposting his instructions here with the necessary changes for the > benefit of Windows users: > > ################################# Gary's instructions for Windows, > modified to work with the current CVS ipython: > > I have attached a patch for IPython 0.5-cvs that, along with my > readline package, will make IPython on Windows work like it does on > more capable systems. > > My readline code is available via CVS from > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/uncpythontools/readline/ > I use it inside and outside IPython and it seems to work fine. > > I don't think these changes impact other platforms 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 >>Term.out, header,output, > > These send prints that could contain color escapes explicitly to a file > object instead of relying on sys.stdout. Term.out and > Term.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.Term.out = out > IPython.genutils.Term.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. > > ################################# > > Gary: I'd also like you to help me with a couple of things concerning > this code. > > 1. You made changes to page(), to make it work with 'less' under > windows+cygwin. I want to be sure that users who DON'T have cygwin > are still ok. Is that the case? > > 2. The code below is around line 913 of genutils.py. Do you know > which exceptions can this trigger under Windows, so we only trap > those? I don't like blanket except clauses (ipython has many, but I'm > trying to clean them up as much as possible). I also added the inner > try/finally to ensure proper cleanup. > > > try: > try: > tmpname = tempfile.mktemp('.txt') > tmpfile = file(tmpname,'wt') > tmpfile.write(strng) > tmpfile.close() > cmd = pager_cmd + ' < ' + tmpname > os.system(cmd) > retval = None > finally: > os.remove(tmpname) > except: # FIXME: trap only the reasonable exceptions > retval = 1 > > You can send me any new patches against current CVS. > > Ok folks, I'll be working some more on ipython over the next few > weeks, to finish cleaning up some other things. But these two big > changes are important enough that I'd really like to hear some > feedback, especially if there are problems. > > Many thanks to Jeff and Gary, both for their work and for their > patience with my sloooow response. > > Regards, > > Fernando. > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.net > http://scipy.net/mailman/listinfo/ipython-dev > From gb at cs.unc.edu Sat Dec 6 15:47:20 2003 From: gb at cs.unc.edu (Gary Bishop) Date: Sat, 06 Dec 2003 15:47:20 EST Subject: [IPython-dev] Still no color on Windows XP Message-ID: <200312062047.hB6KlKFB000564@wren.cs.unc.edu> This results from a change in the interface to readline that they made in 2.3 (which I'm guessing that you are running). I have uploaded changes to CVS (uncpythontools at sourceforge) that should fix this. There isn't a new release yet but you can checkout the code from CVS and see if it works for you. gb On Sat, 06 Dec 2003 12:41:44 -0800 "Mathew Yeates" wrote: > I still get no color. And the prompt is a bunch of weird characters. I > turned on readlines logging and I get the following at the bottom of the log > prompt="'`\xd7\xc5w'" > C:`??w > attr=None > C: > attr=None > any ideas? > Mathew > Fernando Perez wrote: >> Hi all, >> today I've committed a fair amount of changes to CVS, mainly from the >> contributions of Jeff Collins and Gary Bishop. I'd like to give all a >> brief update on this, since it would be great to see some testing of >> this code as I start cleaning things up for a new release. >> - Jeff's work: it fixes tab completion for filenames under python 2.3, >> which broke because the python developers changed the hardcoded >> behavior of the readline library. >> One small caveat: under redhat 8.0, I am seeing an extraneous space >> appended to completed filenames. Jeff helped me track its source, and >> it is an improperly built readline.so by redhat, which is missing the >> rl_completion_append_character variable. This variable can NOT be set >> via python code, so there's nothing I can do about it. Redhat 9's >> python, and almost any correctly built python, should not exhibit this >> small annoyance. >> - Gary's work: this allows coloring under Windows, with some extra >> code provided by Gary. Please note that I modified his patches >> somewhat, in particular I renamed ColorTerm to Term because in the >> future I'll be using this facility for all I/O, not just coloring. So >> I'm reposting his instructions here with the necessary changes for the >> benefit of Windows users: >> ################################# Gary's instructions for Windows, >> modified to work with the current CVS ipython: >> I have attached a patch for IPython 0.5-cvs that, along with my >> readline package, will make IPython on Windows work like it does on >> more capable systems. >> My readline code is available via CVS from >> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/uncpythontools/readline/ >> I use it inside and outside IPython and it seems to work fine. >> I don't think these changes impact other platforms 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 >>Term.out, header,output, >> These send prints that could contain color escapes explicitly to a file >> object instead of relying on sys.stdout. Term.out and >> Term.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.Term.out = out >> IPython.genutils.Term.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. >> ################################# >> Gary: I'd also like you to help me with a couple of things concerning >> this code. >> 1. You made changes to page(), to make it work with 'less' under >> windows+cygwin. I want to be sure that users who DON'T have cygwin are >> still ok. Is that the case? >> 2. The code below is around line 913 of genutils.py. Do you know >> which exceptions can this trigger under Windows, so we only trap those? >> I don't like blanket except clauses (ipython has many, but I'm trying >> to clean them up as much as possible). I also added the inner >> try/finally to ensure proper cleanup. >> try: >> try: >> tmpname = tempfile.mktemp('.txt') >> tmpfile = file(tmpname,'wt') >> tmpfile.write(strng) >> tmpfile.close() >> cmd = pager_cmd + ' < ' + tmpname >> os.system(cmd) >> retval = None >> finally: >> os.remove(tmpname) >> except: # FIXME: trap only the reasonable exceptions >> retval = 1 >> You can send me any new patches against current CVS. >> Ok folks, I'll be working some more on ipython over the next few weeks, >> to finish cleaning up some other things. But these two big changes are >> important enough that I'd really like to hear some feedback, especially >> if there are problems. >> Many thanks to Jeff and Gary, both for their work and for their >> patience with my sloooow response. >> Regards, >> Fernando. >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.net >> http://scipy.net/mailman/listinfo/ipython-dev > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.net > http://scipy.net/mailman/listinfo/ipython-dev From mathew at yeates.tv Sat Dec 6 15:55:11 2003 From: mathew at yeates.tv (Mathew Yeates) Date: Sat, 06 Dec 2003 12:55:11 -0800 Subject: [IPython-dev] Still no color on Windows XP In-Reply-To: <200312062047.hB6KlKFB000564@wren.cs.unc.edu> References: <200312062047.hB6KlKFB000564@wren.cs.unc.edu> Message-ID: <3FD2422F.1050102@yeates.tv> Yes, I am running 2.3. I just noticed that I AM getting colors... The only problem is that the prompt is funky. Gary Bishop wrote: > This results from a change in the interface to readline that they made > in 2.3 (which I'm guessing that you are running). I have uploaded > changes to CVS (uncpythontools at sourceforge) that should fix this. > There isn't a new release yet but you can checkout the code from CVS > and see if it works for you. > > gb > > On Sat, 06 Dec 2003 12:41:44 -0800 "Mathew Yeates" > wrote: > >> I still get no color. And the prompt is a bunch of weird characters. >> I turned on readlines logging and I get the following at the bottom >> of the log > > >> prompt="'`\xd7\xc5w'" >> C:`??w >> attr=None >> C: >> attr=None > > >> any ideas? > > >> Mathew > > > >> Fernando Perez wrote: > > >>> Hi all, >> > >>> today I've committed a fair amount of changes to CVS, mainly from >>> the contributions of Jeff Collins and Gary Bishop. I'd like to give >>> all a brief update on this, since it would be great to see some >>> testing of this code as I start cleaning things up for a new release. >> > >>> - Jeff's work: it fixes tab completion for filenames under python >>> 2.3, which broke because the python developers changed the hardcoded >>> behavior of the readline library. >> > >>> One small caveat: under redhat 8.0, I am seeing an extraneous space >>> appended to completed filenames. Jeff helped me track its source, >>> and it is an improperly built readline.so by redhat, which is >>> missing the rl_completion_append_character variable. This variable >>> can NOT be set via python code, so there's nothing I can do about >>> it. Redhat 9's python, and almost any correctly built python, >>> should not exhibit this small annoyance. >> > >>> - Gary's work: this allows coloring under Windows, with some extra >>> code provided by Gary. Please note that I modified his patches >>> somewhat, in particular I renamed ColorTerm to Term because in the >>> future I'll be using this facility for all I/O, not just coloring. >>> So I'm reposting his instructions here with the necessary changes >>> for the benefit of Windows users: >> > >>> ################################# Gary's instructions for Windows, >>> modified to work with the current CVS ipython: >> > >>> I have attached a patch for IPython 0.5-cvs that, along with my >>> readline package, will make IPython on Windows work like it does on >>> more capable systems. >> > >>> My readline code is available via CVS from >>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/uncpythontools/readline/ >>> I use it inside and outside IPython and it seems to work fine. >> > >>> I don't think these changes impact other platforms 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 >>Term.out, header,output, >> > >>> These send prints that could contain color escapes explicitly to a file >>> object instead of relying on sys.stdout. Term.out and >>> Term.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.Term.out = out >>> IPython.genutils.Term.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. >> > >>> ################################# >> > >>> Gary: I'd also like you to help me with a couple of things >>> concerning this code. >> > >>> 1. You made changes to page(), to make it work with 'less' under >>> windows+cygwin. I want to be sure that users who DON'T have cygwin >>> are still ok. Is that the case? >> > >>> 2. The code below is around line 913 of genutils.py. Do you know >>> which exceptions can this trigger under Windows, so we only trap >>> those? I don't like blanket except clauses (ipython has many, but >>> I'm trying to clean them up as much as possible). I also added the >>> inner try/finally to ensure proper cleanup. >> > > >>> try: >>> try: >>> tmpname = tempfile.mktemp('.txt') >>> tmpfile = file(tmpname,'wt') >>> tmpfile.write(strng) >>> tmpfile.close() >>> cmd = pager_cmd + ' < ' + tmpname >>> os.system(cmd) >>> retval = None >>> finally: >>> os.remove(tmpname) >>> except: # FIXME: trap only the reasonable exceptions >>> retval = 1 >> > >>> You can send me any new patches against current CVS. >> > >>> Ok folks, I'll be working some more on ipython over the next few >>> weeks, to finish cleaning up some other things. But these two big >>> changes are important enough that I'd really like to hear some >>> feedback, especially if there are problems. >> > >>> Many thanks to Jeff and Gary, both for their work and for their >>> patience with my sloooow response. >> > >>> Regards, >> > >>> Fernando. >> > >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.net >>> http://scipy.net/mailman/listinfo/ipython-dev >> > > > >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.net >> http://scipy.net/mailman/listinfo/ipython-dev > > From gb at cs.unc.edu Sat Dec 6 16:39:55 2003 From: gb at cs.unc.edu (Gary Bishop) Date: Sat, 06 Dec 2003 16:39:55 EST Subject: [IPython-dev] Updates to CVS: tab completion and Windows coloring Message-ID: <200312062139.hB6LdtFB003315@wren.cs.unc.edu> Fernando, here are the updates you requested. On Mon, 01 Dec 2003 14:49:41 -0700 "Fernando Perez" wrote: > Gary: I'd also like you to help me with a couple of things concerning > this code. > 1. You made changes to page(), to make it work with 'less' under > windows+cygwin. I want to be sure that users who DON'T have cygwin are > still ok. Is that the case? The changes below appear to make it work with no pager, with the "more" that ships with Windows, and with "less" from Cygwin. With the environment variable PAGER unset it will use iPython's pager. With PAGER=more, it will use the windows more.com. With PAGER=less it will use the cygwin pager. Probably works with others too. I tried this on both 2.2 and 2.3. > 2. The code below is around line 913 of genutils.py. Do you know > which exceptions can this trigger under Windows, so we only trap those? > I don't like blanket except clauses (ipython has many, but I'm trying > to clean them up as much as possible). I also added the inner > try/finally to ensure proper cleanup. It turns out that there really weren't any exceptions possible there. That is fixed in the patch below as well. > You can send me any new patches against current CVS. $ diff genutils.py genutils.py.~1.7.~ 912,922c912,925 < if os.name == 'nt' and not pager_cmd.startswith('type'): < tmpname = tempfile.mktemp('.txt') < tmpfile = file(tmpname,'wt') < tmpfile.write(strng) < tmpfile.close() < cmd = pager_cmd + ' < ' + tmpname < if os.system(cmd): < retval = 1 < else: < retval = None < os.remove(tmpname) --- > if os.name == 'nt': > try: > try: > tmpname = tempfile.mktemp('.txt') > tmpfile = file(tmpname,'wt') > tmpfile.write(strng) > tmpfile.close() > cmd = pager_cmd + ' < ' + tmpname > os.system(cmd) > retval = None > finally: > os.remove(tmpname) > except: # FIXME: trap only the reasonable exceptions > retval = 1 I have also uploaded changes to CVS for my readline library to make it work with 2.3. All the 2.3 stuff has been only very lightly tested because I don't run use it yet. gb From fperez at colorado.edu Sun Dec 7 18:53:39 2003 From: fperez at colorado.edu (Fernando Perez) Date: Sun, 07 Dec 2003 16:53:39 -0700 Subject: [IPython-dev] Updates to CVS: tab completion and Windows coloring In-Reply-To: <200312062139.hB6LdtFB003315@wren.cs.unc.edu> References: <200312062139.hB6LdtFB003315@wren.cs.unc.edu> Message-ID: <3FD3BD83.9070600@colorado.edu> Gary Bishop wrote: > Fernando, here are the updates you requested. Thanks Gary, some comments below. >>1. You made changes to page(), to make it work with 'less' under >>windows+cygwin. I want to be sure that users who DON'T have cygwin are >>still ok. Is that the case? > > > The changes below appear to make it work with no pager, with the "more" > that ships with Windows, and with "less" from Cygwin. With the > environment variable PAGER unset it will use iPython's pager. With > PAGER=more, it will use the windows more.com. With PAGER=less it will > use the cygwin pager. Probably works with others too. I tried this on > both 2.2 and 2.3. Great! >>2. The code below is around line 913 of genutils.py. Do you know >>which exceptions can this trigger under Windows, so we only trap those? >>I don't like blanket except clauses (ipython has many, but I'm trying >>to clean them up as much as possible). I also added the inner >>try/finally to ensure proper cleanup. > > > It turns out that there really weren't any exceptions possible there. > That is fixed in the patch below as well. Just a quick question before I commit this version: is the filename generated by mktemp guaranteed to be in a directory the user has write access to? If not, an IOError exception could be triggered when trying to actually write to the file, couldn't it? That's about the only thing that I can think of to keep the try blocks in there. But I'd prefer it if you are right, because it would save a double try in the code. > I have also uploaded changes to CVS for my readline library to make it > work with 2.3. All the 2.3 stuff has been only very lightly tested > because I don't run use it yet. Nice. When you get a chance (zero hurry) and this settles, I'd like to include a bit more info about this both as links on the webpage, and as a short section in the manual. Basically the relevant links and some brief instructions Windows users (both with and without cygwin) can follow to use your tools in conjunction with ipython. Thanks again for your work, Fernando. From gb at cs.unc.edu Tue Dec 9 15:04:02 2003 From: gb at cs.unc.edu (Gary Bishop) Date: Tue, 09 Dec 2003 15:04:02 EST Subject: [IPython-dev] Updates to CVS: tab completion and Windows coloring Message-ID: <200312092004.hB9K42FB015268@wren.cs.unc.edu> On Sun, 07 Dec 2003 16:53:39 -0700 "Fernando Perez" wrote: > Just a quick question before I commit this version: is the filename > generated by mktemp guaranteed to be in a directory the user has write > access to? If not, an IOError exception could be triggered when trying > to actually write to the file, couldn't it? That's about the only > thing that I can think of to keep the try blocks in there. But I'd > prefer it if you are right, because it would save a double try in the code. I checked the code for tempname and it can raise IOError if it cannot find a temp directory. This would be a pretty terrible circumstance where lots of Python stuff wouldn't work but may well be worth protecting against. gb From fperez at colorado.edu Tue Dec 9 15:24:45 2003 From: fperez at colorado.edu (Fernando Perez) Date: Tue, 09 Dec 2003 13:24:45 -0700 Subject: [IPython-dev] Updates to CVS: tab completion and Windows coloring In-Reply-To: <200312092004.hB9K42FB015268@wren.cs.unc.edu> References: <200312092004.hB9K42FB015268@wren.cs.unc.edu> Message-ID: <3FD62F8D.6070403@colorado.edu> Gary Bishop wrote: > On Sun, 07 Dec 2003 16:53:39 -0700 "Fernando Perez" > wrote: > > >>Just a quick question before I commit this version: is the filename >>generated by mktemp guaranteed to be in a directory the user has write >>access to? If not, an IOError exception could be triggered when trying >>to actually write to the file, couldn't it? That's about the only >>thing that I can think of to keep the try blocks in there. But I'd >>prefer it if you are right, because it would save a double try in the code. > > > I checked the code for tempname and it can raise IOError if it cannot > find a temp directory. This would be a pretty terrible circumstance > where lots of Python stuff wouldn't work but may well be worth > protecting against. Nah. If someone has a system _that_ badly broken, ipython is the least of their concerns :) And the double try is ugly and expensive, so I'll instead apply your simpler patch (the last one) later today. The cost/benefit ratio for this one makes me prefer the simpler solution. If we ever actually get a bug report on this, we'll worry about it. Thanks for clarifying this. Regards, f From mathew at yeates.tv Tue Dec 9 17:48:27 2003 From: mathew at yeates.tv (Mathew Yeates) Date: Tue, 09 Dec 2003 14:48:27 -0800 Subject: [IPython-dev] readline breaks regular python interp? Message-ID: <3FD6513B.8060608@yeates.tv> weird. On Windows Xp with Python 2.3 IPython is working fine. But when I start up regular python, things are whacked! F:\>python Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> def foo(): File "", line 1 ^ IndentationError: expected an indented block >>> what gives? Mathew From gb at cs.unc.edu Tue Dec 9 17:53:52 2003 From: gb at cs.unc.edu (Gary Bishop) Date: Tue, 09 Dec 2003 17:53:52 EST Subject: [IPython-dev] readline breaks regular python interp? Message-ID: <200312092253.hB9MrqFB024353@wren.cs.unc.edu> Works fine for me here on XP with Python 2.3.2 running on vmware. C:\Documents and Settings\gb>c:\Python23\python.exe Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> def foo(): ... return 5 ... gb On Tue, 09 Dec 2003 14:48:27 -0800 "Mathew Yeates" wrote: > weird. On Windows Xp with Python 2.3 IPython is working fine. But when > I start up regular python, things are whacked! > F:\>python > Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. >>>> def foo(): > File "", line 1 > ^ > IndentationError: expected an indented block > what gives? > Mathew > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.net > http://scipy.net/mailman/listinfo/ipython-dev From fperez at colorado.edu Mon Dec 22 01:22:20 2003 From: fperez at colorado.edu (Fernando Perez) Date: Sun, 21 Dec 2003 23:22:20 -0700 Subject: [IPython-dev] Feedback request on a new feature Message-ID: <3FE68D9C.8000806@colorado.edu> Hi all, I'd like to solicit a bit of feedback from the community on a new feature. I often get asked about a quick way to capture shell output to a python variable for further manipulation. Granted, you can always do In [7]: import commands In [8]: a=commands.getoutput('ls C*.py') In [9]: print a ColorANSI.py ConfigLoader.py CrashHandler.py But since ipython is after all a shell which tries to let you do a lot with very little typing, having a builtin shortcut for this doesn't sound like an unreasonable request to me. So as a test I coded up the ability to do the following: In [10]: $b=ls C*.py --- IPython variable set --- b: ColorANSI.py ConfigLoader.py CrashHandler.py the proposed syntax is: $var_name=shell command I'd like some feedback on whether people like the idea, both in principle and in its current (very much a prototype) implementation. Some possible viewpoints I could see people making, but for which I'd like to know whether anyone would _actually_ make them: - It's bloat: anyone who needs it enough can easily code it. - It's not bloat, but a different syntax would be better, like !!b=ls *py This subsumes it into the already existing shell syntax without introducing yet another special character. At the rate things are going, ipython is making python look like perl! - I like it, just leave out the stupid comment, people know what they did. Just print the output like a shell would. - Don't even print the output, it should just behave like getoutput(). People can print out the variable if they need it (esp. useful if the output is potentially huge, but you want it trapped for processing). - You should split the output and return a list, since that's what people will want most of the time. - ... more? Anyway, as you can see, I think it may be useful to many, but I'm a bit concerned about ugliness and implementation specifics. Since it's something people have asked for, I'd like some feedback. I've put the code into CVS so you can play with it and tell me what you think. I can later just back it off if there's consensus that it was just a stupid idea. I'd also like to know of anything else you may consider necessary for the next release. At this point I have pretty much everything ready and I'd like to move forward with releasing the code relatively soon. The only things currently remaining in my mind are: 1. A gettext() related bug which was reported on the tracker. I'm still trying to clarify if that one is really all that different in ipython from normal python. 2. Documenting a bit in the manual Gary Bishop's contributions for Windows users. 3. ??? Let me know of anything you think is important, because after this release I'll probably start, with Jeff Collin's help, tearing ipython apart for a big internal cleanup. This will mean no more development (except for critical bugfixes) done to the current branch. Thanks, and to all of you who celebrate, Happy Holidays! Regards, f. From fperez at colorado.edu Mon Dec 22 13:51:19 2003 From: fperez at colorado.edu (Fernando Perez) Date: Mon, 22 Dec 2003 11:51:19 -0700 Subject: [IPython-dev] Re: [IPython-user] Feedback request on a new feature In-Reply-To: <16359.1553.506625.591262@monster.linux.in> References: <3FE68D9C.8000806@colorado.edu> <16359.1553.506625.591262@monster.linux.in> Message-ID: <3FE73D27.5090802@colorado.edu> Prabhu Ramachandran wrote: >>>>>>"FP" == Fernando Perez writes: > > > FP> Hi all, I'd like to solicit a bit of feedback from the > FP> community on a new feature. I often get asked about a quick > FP> way to capture shell output to a python variable for further > FP> manipulation. Granted, you can always do > > [snip] > FP> In [10]: $b=ls C*.py > > Yes, yes! This would be useful. > > [snip] > > FP> - It's not bloat, but a different syntax would be better, like > > FP> !!b=ls *py > > That sounds good. There's already '!ls' so !! is a natural extension. > How about `ls`, i.e. back quotes? I can't reuse back quotes, because they are already a python synonym for repr(). But !! might be a good thing: it has the advantage that if you do !something, and later want its output, you just need to up-arrow and add another ! character. The implementation is a tad more involved than with a separate character ($), but it may be worth the added hassle once to keep the number of special syntaxes to a minimum. > FP> - Don't even print the output, it should just behave like > FP> getoutput(). People > FP> can print out the variable if they need it (esp. useful if the > FP> output is potentially huge, but you want it trapped for > FP> processing). > > Yes, that sounds good. For example if you want to read a file you > would just do: > > a = `cat foo` > > or whatever (I am not sure if the above will be implementable or not). OK. > If you want to print it you can always do > > !cat foo > > So, I don't see why you'd want to print out the command. > > FP> - You should split the output and return a list, since that's > FP> what people will > FP> want most of the time. > > No, please, that sounds unPythonic to me. OK. Thanks for the feedback. I'll give it a few days to hear back from people and will post a final draft of how to implement it. Regards, f. ps: Prabhu, I think you are mailing from a different address than you originally subscribed from, because your mails to the list were bounced. If you want, I can subscribe you from your new address. Sorry, but the volume of spam was out of control, so I started blocking non-subscriber posts, and this may catch legitimate subscribers who use different addresses. From fperez at colorado.edu Mon Dec 22 16:38:57 2003 From: fperez at colorado.edu (Fernando Perez) Date: Mon, 22 Dec 2003 14:38:57 -0700 Subject: [IPython-dev] Re: [IPython-user] Feedback request on a new feature In-Reply-To: <3FE75EF0.9080300@lbl.gov> References: <3FE68D9C.8000806@colorado.edu> <3FE75EF0.9080300@lbl.gov> Message-ID: <3FE76471.7050602@colorado.edu> Keith Beattie wrote: >>the proposed syntax is: >> >>$var_name=shell command > > > Seems kinda like bloat to me, but what about making ! a magic command? Then > it is clearly an ipython thing (with no perly '$'s) and you could have the > freedom to use whatever syntax or options you want (though I would stick with > sh as much as possible). Something like > > @! [options] var_name=shell command > > Though how far would you want to go here? Would variable substitution be > supported on the right of the '='? Could be a rat-hole of feature creep here... Mmh, I kinda like this idea. A bit involved to code, but it can be done. What do people think? It would allow for example solving the list/string or print/quiet decisions via flags: I'd default to quiet+string, but a -l switch could enable list splitting and a -v, verbose printing. I like it more and more... I'm thinking of having it a magic called shv, short for shell variable (or even sv?). This is a deliberately short name so it requires minimal typing, and @! would be an alternate way to access it. It needs a 'real' magic name anyway (you can't write a function called magic_! in python), and this also allows you to access it without the @ sign if you have automagic on. Opinions? >>- Don't even print the output, it should just behave like getoutput(). >>People can print out the variable if they need it (esp. useful if the >>output is potentially huge, but you want it trapped for processing). > > > Yea, stick with the unix 'no news is good news' default on output. Agreed. > > >>- You should split the output and return a list, since that's what >>people will want most of the time. > > > Perhaps this could be an option of the magic command or set in ipythonrc. Yup. As a magic, a simple -l switch could do. If people _really_ want it, I could (in the rewrite) create a framework for people to set default flags for any magic command they wish. Something like: magic_NAME_default_flags = -l -v would pass -l -v always to @NAME. This could be done with minimal effort as a generic solution, not as a special case option. I already think that ipython has too many special options, and this is not a good thing. But having an option framework for the entire magic system is reasonable, especially since people can just ignore it all if they wish. >>I'd also like to know of anything else you may consider necessary for >>the next release. At this point I have pretty much everything ready and >>I'd like to move forward with releasing the code relatively soon. The >>only things currently remaining in my mind are: > > > Personally, I'd like to see ipython become better integrated with the > debugger, or perhaps the other way around. There is probably many things I > could currently do to make it better, that I just haven't discovered yet, so > perhaps a 'debugging tricks' documentation section for us lazy people? Well, I'm not sure what you have in mind. I did try once to get the pdb prompt to have all the niceties of ipython (coloring, tab support, etc), but I failed. Or did you have something else in mind? Keep in mind that this attempt showed me that almost any 'real' integration beyond what exists would almost require rewriting an entire pdb replacement with the ipython framework. That's just too much for me (feel free to send the patches though ;) As for better documentation, feel free (you or anyone else) to send in ideas you have. I have a 'quick tips' section in the manual where I could include these, and I'd be happy to do so. Thanks for the feedback! Regards, f