From Fernando.Perez at colorado.edu Wed May 5 18:13:43 2004 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Wed, 05 May 2004 16:13:43 -0600 Subject: [IPython-dev] minor ipython.el news In-Reply-To: References: Message-ID: <40996717.4040501@colorado.edu> Hi Alexander, > I have however recently discovered in an email exchange with a ipytho/emacs > user that the version of ipython.el in ipython-emacs.tgz is older than the one > I use myself (I've made some slight improvements to the traceback regexp and > added some dirtrack stuff, which might actually be redundant). > > Anyway, here is the newest version: Ok, thanks for this. I just uploaded into: http://ipython.scipy.org/dist/ipython-emacs-0.3.tgz a tarball with the currently official python-mode from sourceforge and the ipython.el file you sent as well. > BTW, I think it would be nice if ipython's traceback output would be a bit > more uniform, i.e. always match this (or some other emacs-regexp) pattern: > > \(^[^\t ].+?\.py\).*\n +[0-9]+[^\00]*?\n-+> \([0-9]+\) + > > Syntax errors for example currently produce output that doesn't match the > abovee, so it's not possible to automatically jump to the right line in the > source code (and emacs regexp limitations + the way traceback parsing is > hardcoded in python-mode.el make it impossible to handle them seperately). Hmm. I poked around ultraTB.py, which is the traceback formatting code, and it looks doable. However, not particularly straightforward at first sight :( That code is rather convoluted, and I'm not super-familiar with it, since I didn't originally write it myself (though I've modified it quite a bit). So don't hold your breath on this one. However, if in your copious spare time you come up with a nice patch for it, I'll gladly include it in ;-) > P.S: There has been some effort in supplying shell like functionality to > ipython of late (not a bad idea in principle, I think, the fact that python > doesn't have syntax extension facilities is severely limiting here) -- one > thing that really often annoys me is the behavior of @run (which not only does > not perform any shell like globbing, but also doesn't seem to allow actually > passing parameters with spaces in them since there is no quoting or escaping > mechanism as far as I'm aware). Are there any plans to add globbing and > quoting or is there already an easy way to get the equivalent of > > >>./script.py --title 'some title' This one looks more feasible: it's basically adding more sophisticated quoting to @run than the simple .split() it currently does (I mean for the quoting, globbing is even easier). I'll see if I can get this one in soonish, to at least grant you one of your wishes :) I hope your health improves. Cheers, f. From Fernando.Perez at colorado.edu Wed May 5 18:50:49 2004 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Wed, 05 May 2004 16:50:49 -0600 Subject: [IPython-dev] minor ipython.el news In-Reply-To: <40996717.4040501@colorado.edu> References: <40996717.4040501@colorado.edu> Message-ID: <40996FC9.4000702@colorado.edu> Hi Al, Fernando Perez wrote: > Ok, thanks for this. I just uploaded into: > > http://ipython.scipy.org/dist/ipython-emacs-0.3.tgz > > a tarball with the currently official python-mode from sourceforge and the > ipython.el file you sent as well. I just noticed the following comment in your ipython.el: ;; Also note that you currently NEED A MODIFIED VERSION OF PYTHON.EL. I have ;; submitted the necessary patch some months ago to sourceforge, but I think ;; it hasn't been incorporated yet. You can get a patched python.el from the ;; same URL as ipython.el. Should I then NOT include the python-mode from SF? Should I go back to the python-mode I had before, or do you have the patched one around? I just tried ipython.el with the SF python-mode and don't see any problems, but perhaps I haven't quite exercised the problem areas. Plase let me know what I should do on this one so that users who grab the ipython-emacs-XXX.tgz file from the ipython website don't need to putz around any further. I'm afraid now I may have broken things a bit. Cheers, f From a.schmolck at gmx.net Thu May 6 14:29:26 2004 From: a.schmolck at gmx.net (Alexander Schmolck) Date: Thu, 06 May 2004 19:29:26 +0100 Subject: [IPython-dev] minor ipython.el news In-Reply-To: <40996717.4040501@colorado.edu> (Fernando Perez's message of "Wed, 05 May 2004 16:13:43 -0600") References: <40996717.4040501@colorado.edu> Message-ID: Fernando Perez writes: >> BTW, I think it would be nice if ipython's traceback output would be a bit >> more uniform, i.e. always match this (or some other emacs-regexp) pattern: >> \(^[^\t ].+?\.py\).*\n +[0-9]+[^\00]*?\n-+> \([0-9]+\) + >> Syntax errors for example currently produce output that doesn't match the >> abovee, so it's not possible to automatically jump to the right line in the >> source code (and emacs regexp limitations + the way traceback parsing is >> hardcoded in python-mode.el make it impossible to handle them seperately). > > Hmm. I poked around ultraTB.py, which is the traceback formatting code, and > it looks doable. However, not particularly straightforward at first sight :( > That code is rather convoluted, and I'm not super-familiar with it, since I > didn't originally write it myself (though I've modified it quite a bit). So > don't hold your breath on this one. However, if in your copious spare time > you come up with a nice patch for it, I'll gladly include it in ;-) I'll consider it (when I get time to hack python.el one more time, I'll also have a look at this; doesn't seem too much code although possibly not terribly great quality -- I get negative line numbers every now and so often -- that seems to happen if the file is rather short). >>>./script.py --title 'some title' > > This one looks more feasible: it's basically adding more sophisticated quoting > to @run than the simple .split() it currently does (I mean for the quoting, > globbing is even easier). I'll see if I can get this one in soonish, to at > least grant you one of your wishes :) Couldn't one just defer globbing and quoting to the shell (or have an extra @srun command that does that?)? > I hope your health improves. Thanks, I'm fine again. cheers, alex From a.schmolck at gmx.net Thu May 6 14:26:26 2004 From: a.schmolck at gmx.net (Alexander Schmolck) Date: Thu, 06 May 2004 19:26:26 +0100 Subject: [IPython-dev] minor ipython.el news In-Reply-To: <40996FC9.4000702@colorado.edu> (Fernando Perez's message of "Wed, 05 May 2004 16:50:49 -0600") References: <40996717.4040501@colorado.edu> <40996FC9.4000702@colorado.edu> Message-ID: Fernando Perez writes: > Should I then NOT include the python-mode from SF? I think you shouldn't -- that was what I was talking about in my last email: the CVS version of SF python-mode.el has not worked properly with my patch for some time now (since my original patch hadn't been applied I wanted to submit a new one, but then I fell ill for a few weeks -- now I'm fine again but short of time). > Should I go back to the python-mode I had before, or do you have the patched > one around? I just tried ipython.el with the SF python-mode and don't see > any problems, but perhaps I haven't quite exercised the problem areas. Do you mean SF's python-mode.el with my patch applied? I'd be pretty suprised if it looked liked it worked *without* the patch, I don't think executing regions/buffers etc should work (python-mode.el for some reason has the python prompt hardcoded in several places; my patch replaces that mess with pattern a user-definable regexp; I just downloaded and checked that this still is the case). I think it most things will work with the patched-SF-python-mode.el (I haven't tried the latest download release, though) apart from jumping around between exception locations (py-up-exception etc.) -- which happens to be incredibly handy. If you are already using the (patched) new python-mode you could just try and see if C- - does something useful after you've got a traceback; I'd guess it won't -- but if it did all we would have to do is to bug the python-mode developers to incorporate my existing patch. If someone is really terribly bothered by the fact that they can't use the latest python-mode.el with ipython.el than they can either try A) convincing the current maintainers of python-mode.el to incorporate a patch that makes qpython-mode.el ipython-compatible (and presumably a bit cleaner), should someone provide it and B) either try to adapt my patch or get me to do it (pointing out some wonderful feature of the new python-mode.el would help) As I said, I'm rather busy but if there is enough demand and I don't end up with another patch that slowly settles mould because it doesn't get incorporated I might be persuaded to have one more go. > Plase let me know what I should do on this one so that users who grab the > ipython-emacs-XXX.tgz file from the ipython website don't need to putz > around any further. I'm afraid now I may have broken things a bit. I'll attach the version of python-mode.el I'm currently using, which is based on pre-SF python-mode in case you've misplaced your old versions. -------------- next part -------------- A non-text attachment was scrubbed... Name: python-mode.el Type: application/emacs-lisp Size: 132656 bytes Desc: not available URL: -------------- next part -------------- cheers, 'as From Fernando.Perez at colorado.edu Thu May 6 19:11:17 2004 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Thu, 06 May 2004 17:11:17 -0600 Subject: [IPython-dev] minor ipython.el news In-Reply-To: References: <40996717.4040501@colorado.edu> Message-ID: <409AC615.3020407@colorado.edu> Alexander Schmolck wrote: >>Hmm. I poked around ultraTB.py, which is the traceback formatting code, and >>it looks doable. However, not particularly straightforward at first sight :( >>That code is rather convoluted, and I'm not super-familiar with it, since I >>didn't originally write it myself (though I've modified it quite a bit). So >>don't hold your breath on this one. However, if in your copious spare time >>you come up with a nice patch for it, I'll gladly include it in ;-) > > > I'll consider it (when I get time to hack python.el one more time, I'll also > have a look at this; doesn't seem too much code although possibly not terribly > great quality -- I get negative line numbers every now and so often -- that > seems to happen if the file is rather short). Yes, that code isn't great. Poorly commented (if at all) and with fairly convoluted logic. >>>>./script.py --title 'some title' >> >>This one looks more feasible: it's basically adding more sophisticated quoting >>to @run than the simple .split() it currently does (I mean for the quoting, >>globbing is even easier). I'll see if I can get this one in soonish, to at >>least grant you one of your wishes :) > > > Couldn't one just defer globbing and quoting to the shell (or have an extra > @srun command that does that?)? How does this sound? In [1]: cat argv.py #!/usr/bin/env python import sys print 'argv:',sys.argv In [2]: run argv ~ *py argv: ['argv.py', '/home/fperez', 'argv.py', 'die.py', 'div.py', 'error.py', 'exit.py', 'ramptest.py', 'scopes.py', 'strings.py', 't.py'] In [3]: !./argv.py ~ *py argv: ['./argv.py', '/home/fperez', 'argv.py', 'die.py', 'div.py', 'error.py', 'exit.py', 'ramptest.py', 'scopes.py', 'strings.py', 't.py'] Here's the bit of code which does the magic: # Try to have the underlying shell do all quoting for us # This has one eval in it, which I don't see how to avoid, since we # need to rebuild argv from the _string_ which comes from the shell # Note that I print argv[1:] because the -c option is left in there as # the first entry, even though the python man page says it shouldn't # be there. out,err = getoutputerror('%s -SEc "import sys;print sys.argv[1:]" %s' % (sys.executable,arg_str)) # If there is any problem with the shell-based expansions, we punt and # do a simple arg_str.split() if err: warn(err) argv = arg_str.split() elif not out.startswith('[') or not out.endswith(']'): argv = arg_str.split() else: try: argv = eval(out,{},{}) except: argv = arg_str.split() Let me know if you have any objections/comments. I'm not crazy about using an eval, but on the other hand I don't want to build all of the logic which bash has to parse/glob/quote a command line into an argv vector. I've just uploaded this to CVS, in case you feel like playing with it. Cheers, f ps: I gave you what you wanted, now you need to fix ultraTB's regexps :) From fperez at colorado.edu Fri May 7 01:08:13 2004 From: fperez at colorado.edu (Fernando Perez) Date: Thu, 06 May 2004 23:08:13 -0600 Subject: [IPython-dev] minor ipython.el news In-Reply-To: References: <40996717.4040501@colorado.edu> <40996FC9.4000702@colorado.edu> Message-ID: <409B19BD.9090106@colorado.edu> Alexander Schmolck wrote: > Fernando Perez writes: > > >>Should I then NOT include the python-mode from SF? > > > I think you shouldn't -- that was what I was talking about in my last email: > the CVS version of SF python-mode.el has not worked properly with my patch for > some time now (since my original patch hadn't been applied I wanted to submit > a new one, but then I fell ill for a few weeks -- now I'm fine again but short > of time). Got it, thanks. I just got a bit confused with your initial email. The file on the site now has your new ipython.el along with the old patched python-mode you'd given me a while back (CVS $Revision 4.22, along with your changes). That one has worked just fine for me for a long time, so unless anyone sends along a blend of your fixes with the current python-mode, this will do just fine. Best, f From fperez at colorado.edu Fri May 7 01:25:38 2004 From: fperez at colorado.edu (Fernando Perez) Date: Thu, 06 May 2004 23:25:38 -0600 Subject: [IPython-dev] IPython 0.6.0.rc1 available Message-ID: <409B1DD2.90207@colorado.edu> Hi all, I have just uploaded a release candidate for ipython 0.6.0. Unless I hear of any bugs/problems, I intend to make it the official 0.6.0 in a week or so. I would very much appreciate reports of success/failure with it. It includes a bunch of fixes for many things, including various crashes and problems with python 2.3 and better Gnuplot support. Some new features: the improvements to @run for proper quoting of command-line arguments, the new @sc/@sx/!! shell access system, changes to support Gary Bishop's Windows extensions,... The full details are in the changelog, along with credit to the many users who contributed. This released code is in sync with CVS as of now (but a number of changes went in today, so if you have CVS from a few days ago you may want to update). Best regards, and enjoy. I'll put together a nicer announcement with the official release. Fernando. From pythondev-dang at lazytwinacres.net Tue May 11 07:11:10 2004 From: pythondev-dang at lazytwinacres.net (Daniel 'Dang' Griffith) Date: Tue, 11 May 2004 16:11:10 +0500 Subject: [IPython-dev] Win2k IPy 0.6rc1 no problems Message-ID: <20040511111110.12237.qmail@server265.com> I've had no problems with rc 0.6 on Windows 2000, but I must say I've not been in it much the last few days. At least the installation seems to have gone smoothly. (Although, I originally put my .ipython in a stupid place, and have a batch file that sets up the environment before launching IPython, and I had to tweak that some--if I had installed it in the default location originally, I probably would not have this problem.) --dang From fperez at colorado.edu Tue May 11 21:56:33 2004 From: fperez at colorado.edu (Fernando Perez) Date: Tue, 11 May 2004 19:56:33 -0600 Subject: [IPython-dev] Win2k IPy 0.6rc1 no problems In-Reply-To: <20040511111110.12237.qmail@server265.com> References: <20040511111110.12237.qmail@server265.com> Message-ID: <40A18451.6000608@colorado.edu> Daniel 'Dang' Griffith wrote: > I've had no problems with rc 0.6 on Windows 2000, but I > must say I've not been in it much the last few days. At > least the installation seems to have gone smoothly. > (Although, I originally put my .ipython in a stupid place, > and have a batch file that sets up the environment before > launching IPython, and I had to tweak that some--if I > had installed it in the default location originally, I probably > would not have this problem.) Thanks for the report, it looks like I can put 0.6.0 out from CVS out reasonably safely (I won't use rc1 because I found a bug in the Logger module which I fixed yesterday). Best, f From fperez at colorado.edu Fri May 14 02:09:12 2004 From: fperez at colorado.edu (Fernando Perez) Date: Fri, 14 May 2004 00:09:12 -0600 Subject: [IPython-dev] [ANN] IPython 0.6.0 is officially out. Message-ID: <40A46288.9080009@colorado.edu> Hi all, I've just uploaded the packages for IPython 0.6.0 to the usual download location: http://ipython.scipy.org/dist. Third party packages (debian, fink, BSD...) should follow shortly at their respective locations. Please note that I _think_ that IPython now requires Python 2.2. I don't have 2.1 anymore on any of my systems, and I don't have the time to maintain too many versions for testing. It has been used extensively with Python 2.2 and 2.3. This is the first official release in a fairly long time (0.5.0 came out in August 2003), and it includes a number of substantial improvements. The NEWS file (http://ipython.scipy.org/NEWS) contains all ChangeLog entries since 0.5.0. I will briefly highlight the most important changes here: * Much improved Windows XP/2k support. Thanks to Gary Bishop's readline for Windows module, IPython now has tab completion, arrow key history and color support similar to that of Unix platforms. You can find Gary's tools at http://sourceforge.net/projects/uncpythontools; note that his readline module requires in turn the ctypes library, available at http://starship.python.net/crew/theller/ctypes. * Fix filename completion and other issues with python 2.3. * Improved @run command, which now properly handles all arguments so that python scripts run via it receive sys.argv as they would have at a command shell. * Improved system shell access, with new magic functions @sc and @sx (@sx has an equivalent syntax, !!). These allow quick capturing of shell commands directly into python variables. * Improved Gnuplot.py (http://gnuplot-py.sourceforge.net/) support, up to version 1.7. * Internal safety improvements of many of ipython's automatic features by removing unnecessary eval() calls. * General robustness improvements against problematic user code. * Many bug fixes, both small and critical (full IPython crashes). There are currently no known unsolved IPython crash conditions. Many thanks to all who contributed ideas, patches, bug reports, etc. I'd also like to thank here the Enthought crew (the kind folks behind scipy.org) for their generous hosting support for IPython. Enjoy, and please report any problems. Best, Fernando Perez. From ariciputi at pito.com Tue May 25 08:56:30 2004 From: ariciputi at pito.com (Andrea Riciputi) Date: Tue, 25 May 2004 14:56:30 +0200 Subject: [IPython-dev] Encoding warning. Message-ID: Hi, I was installing IPython v0.6.0 when I get the following warning. python2.3 setup.py build sys:1: DeprecationWarning: Non-ASCII character '\xe9' in file setup.py on line 10, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details I know it's only a minor one, but anyway it could be fixed in the next release. HTH, Andrea From Fernando.Perez at colorado.edu Tue May 25 14:02:20 2004 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Tue, 25 May 2004 12:02:20 -0600 Subject: [IPython-dev] Encoding warning. In-Reply-To: References: Message-ID: <40B38A2C.1020705@colorado.edu> Andrea Riciputi wrote: > Hi, > I was installing IPython v0.6.0 when I get the following warning. > > python2.3 setup.py build > sys:1: DeprecationWarning: Non-ASCII character '\xe9' in file setup.py > on line 10, but no encoding declared; see > http://www.python.org/peps/pep-0263.html for details > > I know it's only a minor one, but anyway it could be fixed in the next > release. Thanks, fixed in CVS. By the way, does anyone know how to deal with accents and encodings with Fedora? My desktop uses now Fedora2, which defaults to Utf-8 encodings, and this is giving me a lot of headaches when I modify a file and then edit it on my latptop (Fedora1 configured with Iso-8859-1). I am thinking that the simplest solution will be just to remove all encoding information from all files, and in the same step change P?rez to Perez (I think that accent is the sole non-ascii character). I can live with my name being slightly misspelled rather than dealing with the problems which may ensue if patches are submitted which change encodings. I know next to nothing about this, so any pointers will be much appreciated. There may be a 'right' way to deal with the issue, which I'd gladly follow if I knew it. Best, f