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: <yfs8yge4l41.fsf@black132.ex.ac.uk>
References: <yfs8yge4l41.fsf@black132.ex.ac.uk>
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: <yfs8yge4l41.fsf@black132.ex.ac.uk> <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: <yfs8yge4l41.fsf@black132.ex.ac.uk> <40996717.4040501@colorado.edu>
Message-ID: <yfs3c6d2yux.fsf@black132.ex.ac.uk>

Fernando Perez <Fernando.Perez at colorado.edu> 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: <yfs8yge4l41.fsf@black132.ex.ac.uk>
	<40996717.4040501@colorado.edu> <40996FC9.4000702@colorado.edu>
Message-ID: <yfs7jvp2yzx.fsf@black132.ex.ac.uk>

Fernando Perez <Fernando.Perez at colorado.edu> 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: <http://mail.python.org/pipermail/ipython-dev/attachments/20040506/c391bbdc/attachment.bin>
-------------- 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: <yfs3c6d2yux.fsf@black132.ex.ac.uk>
References: <yfs8yge4l41.fsf@black132.ex.ac.uk>
	<40996717.4040501@colorado.edu> <yfs3c6d2yux.fsf@black132.ex.ac.uk>
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: <yfs7jvp2yzx.fsf@black132.ex.ac.uk>
References: <yfs8yge4l41.fsf@black132.ex.ac.uk>
	<40996717.4040501@colorado.edu> <40996FC9.4000702@colorado.edu>
	<yfs7jvp2yzx.fsf@black132.ex.ac.uk>
Message-ID: <409B19BD.9090106@colorado.edu>

Alexander Schmolck wrote:
> Fernando Perez <Fernando.Perez at colorado.edu> 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: <F160C336-AE4A-11D8-9C01-000A95C0BC68@pito.com>

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: <F160C336-AE4A-11D8-9C01-000A95C0BC68@pito.com>
References: <F160C336-AE4A-11D8-9C01-000A95C0BC68@pito.com>
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