From Fernando.Perez at colorado.edu  Thu Sep  7 19:26:18 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 07 Sep 2006 17:26:18 -0600
Subject: [IPython-dev] Heads-up: server downtime Tuesday 9/12 7:00 PM Central
Message-ID: <4500AA9A.8050609@colorado.edu>

Subject: ISP changeover Tuesday 9/12 7:00 PM Central
From: Jeff Strunk <jstrunk at enthought.com>
Date: Thu, 7 Sep 2006 18:16:52 -0500
To: science-developers at enthought.com, authors at user-faq.openoffice.org, 
scipy-dev at scipy.org, scipy-user at scipy.org, ipython-dev at scipy.org, 
nipy-devel at scipy.org

Good afternoon,

Unfortunately, our recent change in internet service providers is not working
out. We will be switching to a more reliable provider on Tuesday 9/12 at 7:00
PM Central. Please allow for up to two hours of downtime. I will send an
email announcing the start and completion of this maintenance.

This will effect all Enthought servers as well as the SciPy server which hosts
many Open Source projects.

The problem was that our in-building internet service provider neglected to
mention that our internet connection was over a wireless link to a different
building. This link had very high latency. They have fixed this problem, but
we feel that wireless is not stable enough for our needs. In order to provide
higher quality service, we will be using 3 bonded T1s from AT&T after this
switchover.

Please pass this message along to people that I have missed. If you have any
questions, please direct them to me.

We apologize for the inconvenience.
Jeff Strunk
Enthought, Inc.


From stefan at sun.ac.za  Fri Sep 15 04:53:41 2006
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Fri, 15 Sep 2006 10:53:41 +0200
Subject: [IPython-dev] timeit bug
Message-ID: <20060915085341.GA1402@mentat.za.net>

Hi all

Unfortunately, I don't seem to have permission to create tickets on
the ipython trac -- which is why I am re-posting this.  Has anyone
taken a look at it by any chance?

Regards
St?fan

----- Forwarded message from Stefan van der Walt <stefan at sun.ac.za> -----

From: Stefan van der Walt <stefan at sun.ac.za>
To: ipython-dev at scipy.org
Subject: timeit bug
Date: Tue, 15 Aug 2006 19:13:50 +0200
User-Agent: Mutt/1.5.11
Message-ID: <20060815171350.GA32301 at mentat.za.net>

Hi all,

Can anyone confirm the following behaviour with the latest trunk?

In [1]: timeit print('x')
---------------------------------------------------------------------------
exceptions.NameError                                 Traceback (most recent call last)

/tmp/<ipython console>

/home/stefan/lib/python2.4/site-packages/IPython/iplib.py in ipmagic(self, arg_s)
    866         else:
    867             magic_args = self.var_expand(magic_args)
--> 868             return fn(magic_args)
    869
    870     def ipalias(self,arg_s):

/home/stefan/lib/python2.4/site-packages/IPython/Magic.py in magic_timeit(self, parameter_s)
   1677             for i in range(1, 10):
   1678                 number *= 10
-> 1679                 if timer.timeit(number) >= 0.2:
   1680                     break
   1681

/usr/lib/python2.4/timeit.py in timeit(self, number)
    159         gcold = gc.isenabled()
    160         gc.disable()
--> 161         timing = self.inner(it, self.timer)
    162         if gcold:
    163             gc.enable()

/tmp/<magic-timeit> in inner(_it, _timer)

NameError: global name 'x' is not defined

Regards
St?fan

----- End forwarded message -----


From stefan at sun.ac.za  Fri Sep 15 05:26:49 2006
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Fri, 15 Sep 2006 11:26:49 +0200
Subject: [IPython-dev] emacs display problems + patch
Message-ID: <20060915092649.GP963@mentat.za.net>

Hi all,

I while ago, I mentioned the following problem when running IPython
from within emacs:  if you start emacs, open a python file and use C-c
C-c to pipe the region to IPython (*before* running IPython using C-c
!), the result is garbled.

After looking at the code in ipython.el, I noticed that it *does* try
to prevent this from happening:

(defadvice py-execute-region (around py-execute-buffer-ensure-process)
  "HACK: if `py-shell' is not active or ASYNC is explicitly desired, fall back
  to python instead of ipython."
  (let ((py-python-command (if (and (comint-check-proc "*Python*") (not async))
			       py-python-command
			     ipython-backup-of-py-python-command)))
    ad-do-it))


It accomplishes this by setting py-python-command to "python"
(ipython-backup-of-py-python-command), instead of to "ipython"
(py-python-command).  The problem is that python-mode doesn't examine
py-python-command anywhere but on startup.  Rather, it examines a
variable called py-which-shell.  The attached patch simply changes
py-python-command to py-which-shell.

I'd appreciate it if a couple of people could test it, to be sure that
it works correctly on different versions on emacs.

Thanks
St?fan
-------------- next part --------------
Index: ipython.el
===================================================================
--- ipython.el	(revision 1777)
+++ ipython.el	(working copy)
@@ -248,9 +248,9 @@
 (defadvice py-execute-region (around py-execute-buffer-ensure-process)
   "HACK: if `py-shell' is not active or ASYNC is explicitly desired, fall back
   to python instead of ipython." 
-  (let ((py-python-command (if (and (comint-check-proc "*Python*") (not async))
-                               py-python-command
-                               ipython-backup-of-py-python-command)))
+  (let ((py-which-shell (if (and (comint-check-proc "*Python*") (not async))
+			    py-python-command
+			  ipython-backup-of-py-python-command)))
     ad-do-it))
 (ad-activate 'py-execute-region)
 

From vivainio at gmail.com  Fri Sep 15 07:49:43 2006
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 15 Sep 2006 14:49:43 +0300
Subject: [IPython-dev] timeit bug
In-Reply-To: <20060915085341.GA1402@mentat.za.net>
References: <20060915085341.GA1402@mentat.za.net>
Message-ID: <46cb515a0609150449l2dcf9379h6434127e1bcd7604@mail.gmail.com>

On 9/15/06, Stefan van der Walt <stefan at sun.ac.za> wrote:

> the ipython trac -- which is why I am re-posting this.  Has anyone
> taken a look at it by any chance?

Not yet. I just received my primary home computer yesterday and will
only be able to dedicate time to it on sunday, on earliest.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From Fernando.Perez at colorado.edu  Fri Sep 15 15:45:43 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 15 Sep 2006 13:45:43 -0600
Subject: [IPython-dev] [Fwd: Request for help in finding IPython
	contributors]
Message-ID: <450B02E7.5020603@colorado.edu>

Hi all,

I'm forwarding a request from Ian, from the ShowMeDo site.  Ian, sorry for the 
big delay, this week was a bit crazy...

Cheers,

f

-------- Original Message --------
Subject: Request for help in finding IPython contributors
Date: Wed, 6 Sep 2006 11:18:52 -0500 (CDT)
From: Ian Ozsvald <ian at showmedo.com>
To: Fernando Perez <Fernando.Perez at colorado.edu>
CC: Kyran <kyran.dale at gmail.com>
References: <1025.81.77.49.19.1150629930.squirrel at mail.zettai.net> 
<449B7533.5090100 at colorado.edu>

Hi Fernando.  Just a quick update mail - I'm wondering if it'd be possible
for you to put out a request on my behalf, asking for someone to make a
video (even better - a series) introducing all the new features of
IPython?

I upgraded to 0.7.2, saw the changelog and thought Wow!  But...trying to
find docs on it all is a bit tricky, and I still don't know what I might
have been missing from earlier versions.

Certainly the PickleShelve poor-man's-ZODB is very cool and I'm already
using it for large datasets (not to share, just easy persistence).
Features like the runner, timing and scripting look cool but I've no idea
where to start, or even if they're relevant to me (so I don't put in the
time to investigate, arg!).

The videos I cut for you are amongst our highest viewed of all time
(11,367 views out of close to 60,000 ShowMeDo downloads, from our growing
collection of 59 videos).  I'd bet that they're popular because people
know that they're only scratching the surface, and would love to learn
more.

To that end I've added an IPython request:
http://showmedo.com/requests?tags=IPython
but without someone picking up the baton, it might languish at the bottom
of the heap.  Previously I'd added a Django suggestion and that received a
huge amount of attention (resulting in 67 non-repeated votes):
http://groups.google.com/group/django-users/browse_thread/thread/183422adb96eaaaf
http://groups.google.com/group/django-users/browse_thread/thread/a4bde9e8c15fed61
which has helped us to find Django contributors (new Django videos are in
the works, and probably at least one TurboGears series too).

If cool with you, a mailing pointing at the IPython request and mentioning
our keen interest in IPython-demonstrations could really help us find a
few people to further promote IPython.

Am curious to hear what you think!
Ian.


From jdhunter at ace.bsd.uchicago.edu  Tue Sep 19 10:28:12 2006
From: jdhunter at ace.bsd.uchicago.edu (John Hunter)
Date: Tue, 19 Sep 2006 09:28:12 -0500
Subject: [IPython-dev] closing sys.stdout
Message-ID: <87mz8wue0z.fsf@peds-pc311.bsd.uchicago.edu>


Yes, it is possible to cause ipython to dump core!

johnh at jitter:~> ipython
Python 2.4.2 (#1, Feb 23 2006, 12:48:31)
Type "copyright", "credits" or "license" for more information.

IPython 0.7.2 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

In [1]: sys.stdout.close()
------------------------------------------------------------
Traceback (most recent call last):
  File "<ipython console>", line 1, in ?
NameError: name 'sys' is not defined


In [2]: import sys

In [3]: sys.stdout.close()
Segmentation Fault (core dumped)

(solaris 10 x86 architecture)

This came up in a script where I had done

  fh = file(fname, 'w')
  print >>fh, 'blah'
  fh.close()

later when debugging I did

  #fh = file(fname, 'w')
  fh = sys.stdout
  print >>fh, 'blah'
  fh.close()


and forgot I had the close in....

I have seen modules, yes really, that explicitly call
sys.stdout.close()

ipython may want to hijack sys.stdout.close to prevent this kind of thing...

JDH


From vivainio at gmail.com  Tue Sep 19 12:17:36 2006
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 19 Sep 2006 19:17:36 +0300
Subject: [IPython-dev] closing sys.stdout
In-Reply-To: <87mz8wue0z.fsf@peds-pc311.bsd.uchicago.edu>
References: <87mz8wue0z.fsf@peds-pc311.bsd.uchicago.edu>
Message-ID: <46cb515a0609190917t141a574et593e6e6bc099bf5@mail.gmail.com>

On 9/19/06, John Hunter <jdhunter at ace.bsd.uchicago.edu> wrote:

> ipython may want to hijack sys.stdout.close to prevent this kind of thing...

Good call, though I can't see *why* this dumps core instead of
something more orderly...

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From fperez.net at gmail.com  Tue Sep 19 13:41:46 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 19 Sep 2006 11:41:46 -0600
Subject: [IPython-dev] closing sys.stdout
In-Reply-To: <46cb515a0609190917t141a574et593e6e6bc099bf5@mail.gmail.com>
References: <87mz8wue0z.fsf@peds-pc311.bsd.uchicago.edu>
	<46cb515a0609190917t141a574et593e6e6bc099bf5@mail.gmail.com>
Message-ID: <db6b5ecc0609191041h1c7fd773x37dba58ed132f177@mail.gmail.com>

On 9/19/06, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 9/19/06, John Hunter <jdhunter at ace.bsd.uchicago.edu> wrote:
>
> > ipython may want to hijack sys.stdout.close to prevent this kind of thing...
>
> Good call, though I can't see *why* this dumps core instead of
> something more orderly...

I'd say this is a python bug, but we'd have to track it better to
submit a report.

I managed to reproduce it from a plain python console, so this is
probably worth reporting.  I don't have 2.5 on this machine, so I
can't test, but here it is from a plain python console:

planck[freeslater]> python
Python 2.3.4 (#1, Feb  2 2005, 12:11:53)
[GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import code
>>> code.I
code.InteractiveConsole      code.InteractiveInterpreter
>>> c=code.InteractiveConsole()
>>> c.interact()
Python 2.3.4 (#1, Feb  2 2005, 12:11:53)
[GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import sys
>>> sys.std
sys.stderr  sys.stdin   sys.stdout
>>> sys.stdout.close()
Segmentation fault (core dumped)


This is /certainly/ a pure python bug, though we should protect
against it until they get around to fixing it.  I'll try to test 2.5
at home tonight and will file a bug report at SF against python.

Cheers,

f


From fullung at gmail.com  Wed Sep 20 04:28:26 2006
From: fullung at gmail.com (Albert Strasheim)
Date: Wed, 20 Sep 2006 10:28:26 +0200
Subject: [IPython-dev] Chainsaw: SIGUSR1 doesn't exist on Windows
Message-ID: <E1GPxRT-00036g-0z@mail2.sun.ac.za>

Hello all

I've started cutting myself on the Chainsaw branch of IPython. Vroom-vroom.

The first issue I've run into is with starting ipengine. InteractiveShell in
core\shell.py is trying to use the USR1 signal for something. This signal
doesn't exist on Windows.

I haven't looked at the code very thoroughly, so I don't have a proposal for
fixing this issue.

Cheers,

Albert



From jaomatos at gmail.com  Wed Sep 20 05:10:53 2006
From: jaomatos at gmail.com (=?ISO-8859-1?Q?Jos=E9_Matos?=)
Date: Wed, 20 Sep 2006 10:10:53 +0100
Subject: [IPython-dev] closing sys.stdout
In-Reply-To: <db6b5ecc0609191041h1c7fd773x37dba58ed132f177@mail.gmail.com>
References: <87mz8wue0z.fsf@peds-pc311.bsd.uchicago.edu>
	<46cb515a0609190917t141a574et593e6e6bc099bf5@mail.gmail.com>
	<db6b5ecc0609191041h1c7fd773x37dba58ed132f177@mail.gmail.com>
Message-ID: <9fd2371d0609200210r561a7b28ob3f96385489cf2c0@mail.gmail.com>

Hi Fernando,

On 19/09/06, Fernando Perez <fperez.net at gmail.com> wrote:
> I'd say this is a python bug, but we'd have to track it better to
> submit a report.
>
> I managed to reproduce it from a plain python console, so this is
> probably worth reporting.  I don't have 2.5 on this machine, so I
> can't test, but here it is from a plain python console:
>
> planck[freeslater]> python
> Python 2.3.4 (#1, Feb  2 2005, 12:11:53)
> [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import code
> >>> code.I
> code.InteractiveConsole      code.InteractiveInterpreter
> >>> c=code.InteractiveConsole()
> >>> c.interact()
> Python 2.3.4 (#1, Feb  2 2005, 12:11:53)
> [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> (InteractiveConsole)
> >>> import sys
> >>> sys.std
> sys.stderr  sys.stdin   sys.stdout
> >>> sys.stdout.close()
> Segmentation fault (core dumped)
>
>
> This is /certainly/ a pure python bug, though we should protect
> against it until they get around to fixing it.  I'll try to test 2.5
> at home tonight and will file a bug report at SF against python.
>
> Cheers,
>
> f

This is what I get in python 2.5 (rc1) in FC-5:
$ python25
Python 2.5c1 (r25c1:51305, Aug 18 2006, 11:45:01)
[GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import code
>>> c = code.InteractiveConsole()
>>> c.interact()
Python 2.5c1 (r25c1:51305, Aug 18 2006, 11:45:01)
[GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import sys
>>> sys.stdout.close()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/code.py", line 234, in interact
    line = self.raw_input(prompt)
  File "/usr/lib/python2.5/code.py", line 277, in raw_input
    return raw_input(prompt)
ValueError: I/O operation on closed file
>>>

no crash. With python 2.4 I get the same crash observed in this thread.

-- 
Jos? Ab?lio


From fperez.net at gmail.com  Wed Sep 20 13:14:31 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 20 Sep 2006 11:14:31 -0600
Subject: [IPython-dev] closing sys.stdout
In-Reply-To: <9fd2371d0609200210r561a7b28ob3f96385489cf2c0@mail.gmail.com>
References: <87mz8wue0z.fsf@peds-pc311.bsd.uchicago.edu>
	<46cb515a0609190917t141a574et593e6e6bc099bf5@mail.gmail.com>
	<db6b5ecc0609191041h1c7fd773x37dba58ed132f177@mail.gmail.com>
	<9fd2371d0609200210r561a7b28ob3f96385489cf2c0@mail.gmail.com>
Message-ID: <db6b5ecc0609201014m56123d9fr9daed2b6505229ba@mail.gmail.com>

On 9/20/06, Jos? Matos <jaomatos at gmail.com> wrote:
> Hi Fernando,

> This is what I get in python 2.5 (rc1) in FC-5:
[...]

> no crash. With python 2.4 I get the same crash observed in this thread.

Thanks for the test, Jos?; I didn't have time to check last night.
It's good to know the bug was fixed in 2.5, we should probably still
file against 2.4 so the fix gets backported for 2.4.4 (which I think
the python-dev gang is planning on releasing relatively soon).

Cheers,

f


From fperez.net at gmail.com  Wed Sep 20 19:01:23 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 20 Sep 2006 17:01:23 -0600
Subject: [IPython-dev] Chainsaw: SIGUSR1 doesn't exist on Windows
In-Reply-To: <E1GPxRT-00036g-0z@mail2.sun.ac.za>
References: <E1GPxRT-00036g-0z@mail2.sun.ac.za>
Message-ID: <db6b5ecc0609201601t557fb985nc07dbef1a3a0a913@mail.gmail.com>

On 9/20/06, Albert Strasheim <fullung at gmail.com> wrote:
> Hello all
>
> I've started cutting myself on the Chainsaw branch of IPython. Vroom-vroom.
>
> The first issue I've run into is with starting ipengine. InteractiveShell in
> core\shell.py is trying to use the USR1 signal for something. This signal
> doesn't exist on Windows.
>
> I haven't looked at the code very thoroughly, so I don't have a proposal for
> fixing this issue.

Thanks for the report, Albert.  I've CC-d Brian (he has mailng list
troubles so didn't get the original), we'll look into it.

Cheers,

f


From vivainio at gmail.com  Thu Sep 21 04:56:51 2006
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 21 Sep 2006 11:56:51 +0300
Subject: [IPython-dev] timeit bug
In-Reply-To: <20060915085341.GA1402@mentat.za.net>
References: <20060915085341.GA1402@mentat.za.net>
Message-ID: <46cb515a0609210156o613d9852u1139b79510b5291d@mail.gmail.com>

On 9/15/06, Stefan van der Walt <stefan at sun.ac.za> wrote:

Hi,

If you need this to work quickly, do

timeit print(\'x\')

i.e. escape the quotes.

Using parse_options is a bad idea in timeit because it gets rid of the
quotes. It needs to be fixed properly, but I suggest using backslashes
to get over the immediate problem.


> Unfortunately, I don't seem to have permission to create tickets on
> the ipython trac -- which is why I am re-posting this.  Has anyone
> taken a look at it by any chance?
>
> Regards
> St?fan
>
> ----- Forwarded message from Stefan van der Walt <stefan at sun.ac.za> -----
>
> From: Stefan van der Walt <stefan at sun.ac.za>
> To: ipython-dev at scipy.org
> Subject: timeit bug
> Date: Tue, 15 Aug 2006 19:13:50 +0200
> User-Agent: Mutt/1.5.11
> Message-ID: <20060815171350.GA32301 at mentat.za.net>
>
> Hi all,
>
> Can anyone confirm the following behaviour with the latest trunk?
>
> In [1]: timeit print('x')
> ---------------------------------------------------------------------------
> exceptions.NameError                                 Traceback (most recent call last)
>
> /tmp/<ipython console>
>
> /home/stefan/lib/python2.4/site-packages/IPython/iplib.py in ipmagic(self, arg_s)
>     866         else:
>     867             magic_args = self.var_expand(magic_args)
> --> 868             return fn(magic_args)
>     869
>     870     def ipalias(self,arg_s):
>
> /home/stefan/lib/python2.4/site-packages/IPython/Magic.py in magic_timeit(self, parameter_s)
>    1677             for i in range(1, 10):
>    1678                 number *= 10
> -> 1679                 if timer.timeit(number) >= 0.2:
>    1680                     break
>    1681
>
> /usr/lib/python2.4/timeit.py in timeit(self, number)
>     159         gcold = gc.isenabled()
>     160         gc.disable()
> --> 161         timing = self.inner(it, self.timer)
>     162         if gcold:
>     163             gc.enable()
>
> /tmp/<magic-timeit> in inner(_it, _timer)
>
> NameError: global name 'x' is not defined
>
> Regards
> St?fan
>
> ----- End forwarded message -----
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/ipython-dev
>


-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Thu Sep 21 05:48:45 2006
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 21 Sep 2006 12:48:45 +0300
Subject: [IPython-dev] timeit bug
In-Reply-To: <46cb515a0609210156o613d9852u1139b79510b5291d@mail.gmail.com>
References: <20060915085341.GA1402@mentat.za.net>
	<46cb515a0609210156o613d9852u1139b79510b5291d@mail.gmail.com>
Message-ID: <46cb515a0609210248i7dbb65deid4a1ce2d48a73774@mail.gmail.com>

On 9/21/06, Ville M. Vainio <vivainio at gmail.com> wrote:

> On 9/15/06, Stefan van der Walt <stefan at sun.ac.za> wrote:
>
> Hi,
>
> If you need this to work quickly, do
>
> timeit print(\'x\')
>
> i.e. escape the quotes.

Or (of course):

timeit "print('x')"

timeit "print 'x'"

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From jdhunter at ace.bsd.uchicago.edu  Thu Sep 21 10:33:56 2006
From: jdhunter at ace.bsd.uchicago.edu (John Hunter)
Date: Thu, 21 Sep 2006 09:33:56 -0500
Subject: [IPython-dev] closing sys.stdout
In-Reply-To: <db6b5ecc0609201014m56123d9fr9daed2b6505229ba@mail.gmail.com>
	("Fernando Perez"'s message of "Wed, 20 Sep 2006 11:14:31 -0600")
References: <87mz8wue0z.fsf@peds-pc311.bsd.uchicago.edu>
	<46cb515a0609190917t141a574et593e6e6bc099bf5@mail.gmail.com>
	<db6b5ecc0609191041h1c7fd773x37dba58ed132f177@mail.gmail.com>
	<9fd2371d0609200210r561a7b28ob3f96385489cf2c0@mail.gmail.com>
	<db6b5ecc0609201014m56123d9fr9daed2b6505229ba@mail.gmail.com>
Message-ID: <87venhz3u3.fsf@peds-pc311.bsd.uchicago.edu>

>>>>> "Fernando" == Fernando Perez <fperez.net at gmail.com> writes:


    Fernando> Thanks for the test, Jos?; I didn't have time to check
    Fernando> last night.  It's good to know the bug was fixed in 2.5,
    Fernando> we should probably still file against 2.4 so the fix
    Fernando> gets backported for 2.4.4 (which I think the python-dev
    Fernando> gang is planning on releasing relatively soon).

I showed this to Skip Montanaro, who us fairly active on python-dev,
and he volunteered to get the bug report in for the 2.4.4 backport.

JDH


From ellisonbg.net at gmail.com  Thu Sep 21 11:22:40 2006
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 21 Sep 2006 09:22:40 -0600
Subject: [IPython-dev] Chainsaw: SIGUSR1 doesn't exist on Windows
In-Reply-To: <db6b5ecc0609201601t557fb985nc07dbef1a3a0a913@mail.gmail.com>
References: <E1GPxRT-00036g-0z@mail2.sun.ac.za>
	<db6b5ecc0609201601t557fb985nc07dbef1a3a0a913@mail.gmail.com>
Message-ID: <6ce0ac130609210822w12fcfa2dq1c291d409fd64e95@mail.gmail.com>

Just testing to see if I can post.

This should be fixed now.  Let me know if you have any other problems.

Brian

On 9/20/06, Fernando Perez <fperez.net at gmail.com> wrote:
> On 9/20/06, Albert Strasheim <fullung at gmail.com> wrote:
> > Hello all
> >
> > I've started cutting myself on the Chainsaw branch of IPython. Vroom-vroom.
> >
> > The first issue I've run into is with starting ipengine. InteractiveShell in
> > core\shell.py is trying to use the USR1 signal for something. This signal
> > doesn't exist on Windows.
> >
> > I haven't looked at the code very thoroughly, so I don't have a proposal for
> > fixing this issue.
>
> Thanks for the report, Albert.  I've CC-d Brian (he has mailng list
> troubles so didn't get the original), we'll look into it.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Thu Sep 21 13:18:43 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 21 Sep 2006 11:18:43 -0600
Subject: [IPython-dev] closing sys.stdout
In-Reply-To: <87venhz3u3.fsf@peds-pc311.bsd.uchicago.edu>
References: <87mz8wue0z.fsf@peds-pc311.bsd.uchicago.edu>
	<46cb515a0609190917t141a574et593e6e6bc099bf5@mail.gmail.com>
	<db6b5ecc0609191041h1c7fd773x37dba58ed132f177@mail.gmail.com>
	<9fd2371d0609200210r561a7b28ob3f96385489cf2c0@mail.gmail.com>
	<db6b5ecc0609201014m56123d9fr9daed2b6505229ba@mail.gmail.com>
	<87venhz3u3.fsf@peds-pc311.bsd.uchicago.edu>
Message-ID: <db6b5ecc0609211018y29ab6b89gb8dbeb50f075d8c9@mail.gmail.com>

On 9/21/06, John Hunter <jdhunter at ace.bsd.uchicago.edu> wrote:
> >>>>> "Fernando" == Fernando Perez <fperez.net at gmail.com> writes:
>
>
>     Fernando> Thanks for the test, Jos?; I didn't have time to check
>     Fernando> last night.  It's good to know the bug was fixed in 2.5,
>     Fernando> we should probably still file against 2.4 so the fix
>     Fernando> gets backported for 2.4.4 (which I think the python-dev
>     Fernando> gang is planning on releasing relatively soon).
>
> I showed this to Skip Montanaro, who us fairly active on python-dev,
> and he volunteered to get the bug report in for the 2.4.4 backport.

Great, thanks.  Just for completeness I checked with 2.5 final which I
built last night, and that's OK.  So only 2.4 needs fixing.

Cheers,

f


From vivainio at gmail.com  Tue Sep 26 17:11:34 2006
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 27 Sep 2006 00:11:34 +0300
Subject: [IPython-dev] Not crashing on exit() w/ py2.5
Message-ID: <46cb515a0609261411h4c5e81f6nc0825a6943906e71@mail.gmail.com>

I just checked in this to avoid crashing py2.5 on exit(); raw_input
will raise ValueError because py2.5 exit() closes stdin. It's a hack,
but will do for a while.

Index: IPython/iplib.py
===================================================================
--- IPython/iplib.py    (revision 1777)
+++ IPython/iplib.py    (working copy)
@@ -1740,7 +1740,7 @@
         except SystemExit:
             self.resetbuffer()
             self.showtraceback()
-            warn("Type exit or quit to exit IPython "
+            warn("Type %exit or %quit to exit IPython "
                  "(%Exit or %Quit do so unconditionally).",level=1)
         except self.custom_exceptions:
             etype,value,tb = sys.exc_info()
@@ -1801,7 +1801,14 @@
           continuation in a sequence of inputs.
         """

-        line = raw_input_original(prompt)
+        try:
+            line = raw_input_original(prompt)
+        except ValueError:
+            # python 2.5 closes stdin on exit -> ValueError
+            # xxx should we delete 'exit' and 'quit' from builtin?
+            self.exit_now = True
+            return ''
+

         # Try to be reasonably smart about not re-indenting pasted input more
         # than necessary.  We do this by trimming out the auto-indent initial


-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From fperez.net at gmail.com  Wed Sep 27 03:15:56 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 27 Sep 2006 01:15:56 -0600
Subject: [IPython-dev] Not crashing on exit() w/ py2.5
In-Reply-To: <46cb515a0609261411h4c5e81f6nc0825a6943906e71@mail.gmail.com>
References: <46cb515a0609261411h4c5e81f6nc0825a6943906e71@mail.gmail.com>
Message-ID: <db6b5ecc0609270015r480e6ac1j850156d994dd84ad@mail.gmail.com>

On 9/26/06, Ville M. Vainio <vivainio at gmail.com> wrote:
> I just checked in this to avoid crashing py2.5 on exit(); raw_input
> will raise ValueError because py2.5 exit() closes stdin. It's a hack,
> but will do for a while.

I just checked in a bunch of fixes for 2.5, and reverted this one to
use a different approach, which produces cleaner exits and works in
the presence of active %pdb.

Cheers,

f


From Fernando.Perez at colorado.edu  Wed Sep 27 03:24:23 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 27 Sep 2006 01:24:23 -0600
Subject: [IPython-dev] Fwd: IPython and closing sys.stdout
Message-ID: <451A2727.7010305@colorado.edu>

[ Skip, thanks for this, I'm forwarding it to ipython-dev which is subscriber 
only (too much spam).]


Subject:IPython and closing sys.stdout
From:skip at pobox.com
Date:Thu, 21 Sep 2006 14:46:48 -0500
To:ipython-dev at scipy.org

John Hunter alerted me to a segfault problem in code.InteractiveConsole when
sys.stdout is closed.  This problem is present in Python up to 2.4.3 as far
as I can tell, but is fixed in later versions of Python (2.5, 2.4.4 when
it's released, svn trunk).  Even with that fix, if the user calls
sys.stdout.close() you'll get a ValueError and your console will be useless.
I took a look at the code in Python that the InteractiveConsole class
exercises and see that the cause is that the naive raw_input() method simply
calls the raw_input() builtin.  That function gets the "stdin" and "stdout"
functions from the sys module and there's no way to override that behavior.

In my opinion, the best thing to do would be to subclass InteractiveConsole
and provide a more robust raw_input() method.  Ideally, I think you'd want
to dup() the file descriptors for sys.{stdin,stdout} and use those instead
of calling the builtin raw_input().  Something like (untested):

     class IC(code.InteractiveConsole):
         def __init__(self):
             code.InteractiveConsole.__init__(self)
             self.input = os.fdopen(os.dup(sys.stdin.fileno()))
             self.output = os.fdopen(os.dup(sys.stdout.fileno()))
             self.error = os.fdopen(os.dup(sys.stderr.fileno()))

         def raw_input(self, prompt=""):
             if prompt:
                 self.output.write(prompt):
                 self.output.flush()
             return self.input.readline()

         def write(self, data):
             self.error.write(data)

Also, the runcode() method will have to be overridden to use self.output
instead of sys.stdout.  Those couple changes should (hopefully) insulate
IPython from such user wackiness.

Skip Montanaro
skip at pobox.com

-------------- next part --------------
An embedded message was scrubbed...
From: skip at pobox.com
Subject: IPython and closing sys.stdout
Date: Thu, 21 Sep 2006 14:46:48 -0500
Size: 2955
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060927/f54d5fec/attachment.eml>

From Fernando.Perez at colorado.edu  Wed Sep 27 21:23:50 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 27 Sep 2006 19:23:50 -0600
Subject: [IPython-dev] The new Moin-based site is up!
Message-ID: <451B2426.1000103@colorado.edu>

Hi all,

If you go over to

http://ipython.scipy.org/moin

you'll see that the new Moin site is now up, and thanks to Brian's efforts, 
the old content is now moved over.  The old url has a simple redirect page, 
and I'll soon ask the Enthought admins to give us an automatic apache redirect 
for that page so it's faster.

Not only does this new site look less 1996-style than the old one, but now 
anyone can contribute content, in good wiki style.  Please make a user name 
for yourself and start putting in your favorite info about ipython.

Let me explain a little bit how I see the two wikis we now have:

- Trac site (which has its own wiki, and where some user-related info had been 
put): this should become purely a site for development-specific work, mostly 
tracking bugs, milestone management, etc.  I expect that we'll use precious 
little of the Wiki part of Trac, to avoid duplication of content or questions 
about 'where should this page go?'.  Trac has a wiki, but it's a fairly 
bare-bones one, so I think in the long run we can mostly ignore it, while 
using the other nice things Trac offers (bugs, SVN, timeline, milestones, etc).

- Moin site: for just about everything else that a wiki is good for.  The Moin 
engine looks nicer and is more flexible than Trac's wiki, so I expect we'll 
use this as 'the ipython site'.

As for the material we had in the old Trac site, let's try to gradually move 
it over as time allows.  Fortunately it wasn't that much, so it should be 
relatively easy.  The simplest way to move a page is to view it as plain text 
(link at the bottom) and wholesale copy it over; fortunately the markup 
conventions are such that in most cases this works.

By all means contribute, it's a wiki! (in particular, the cookbook is an area 
I hope will develop over time).

Best,

f


From vivainio at gmail.com  Thu Sep 28 08:05:16 2006
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 28 Sep 2006 15:05:16 +0300
Subject: [IPython-dev] Fwd: IPython and closing sys.stdout
In-Reply-To: <451A2727.7010305@colorado.edu>
References: <451A2727.7010305@colorado.edu>
Message-ID: <46cb515a0609280505y6d7ae2f8ja1310d96034d2a3c@mail.gmail.com>

I'll pick this up.

On 9/27/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> [ Skip, thanks for this, I'm forwarding it to ipython-dev which is subscriber
> only (too much spam).]
>
>
> Subject:IPython and closing sys.stdout
> From:skip at pobox.com
> Date:Thu, 21 Sep 2006 14:46:48 -0500
> To:ipython-dev at scipy.org
>
> John Hunter alerted me to a segfault problem in code.InteractiveConsole when
> sys.stdout is closed.  This problem is present in Python up to 2.4.3 as far
> as I can tell, but is fixed in later versions of Python (2.5, 2.4.4 when
> it's released, svn trunk).  Even with that fix, if the user calls
> sys.stdout.close() you'll get a ValueError and your console will be useless.
> I took a look at the code in Python that the InteractiveConsole class
> exercises and see that the cause is that the naive raw_input() method simply
> calls the raw_input() builtin.  That function gets the "stdin" and "stdout"
> functions from the sys module and there's no way to override that behavior.
>
> In my opinion, the best thing to do would be to subclass InteractiveConsole
> and provide a more robust raw_input() method.  Ideally, I think you'd want
> to dup() the file descriptors for sys.{stdin,stdout} and use those instead
> of calling the builtin raw_input().  Something like (untested):
>
>      class IC(code.InteractiveConsole):
>          def __init__(self):
>              code.InteractiveConsole.__init__(self)
>              self.input = os.fdopen(os.dup(sys.stdin.fileno()))
>              self.output = os.fdopen(os.dup(sys.stdout.fileno()))
>              self.error = os.fdopen(os.dup(sys.stderr.fileno()))
>
>          def raw_input(self, prompt=""):
>              if prompt:
>                  self.output.write(prompt):
>                  self.output.flush()
>              return self.input.readline()
>
>          def write(self, data):
>              self.error.write(data)
>
> Also, the runcode() method will have to be overridden to use self.output
> instead of sys.stdout.  Those couple changes should (hopefully) insulate
> IPython from such user wackiness.
>
> Skip Montanaro
> skip at pobox.com
>
>
>
>
> John Hunter alerted me to a segfault problem in code.InteractiveConsole when
> sys.stdout is closed.  This problem is present in Python up to 2.4.3 as far
> as I can tell, but is fixed in later versions of Python (2.5, 2.4.4 when
> it's released, svn trunk).  Even with that fix, if the user calls
> sys.stdout.close() you'll get a ValueError and your console will be useless.
> I took a look at the code in Python that the InteractiveConsole class
> exercises and see that the cause is that the naive raw_input() method simply
> calls the raw_input() builtin.  That function gets the "stdin" and "stdout"
> functions from the sys module and there's no way to override that behavior.
>
> In my opinion, the best thing to do would be to subclass InteractiveConsole
> and provide a more robust raw_input() method.  Ideally, I think you'd want
> to dup() the file descriptors for sys.{stdin,stdout} and use those instead
> of calling the builtin raw_input().  Something like (untested):
>
>     class IC(code.InteractiveConsole):
>         def __init__(self):
>             code.InteractiveConsole.__init__(self)
>             self.input = os.fdopen(os.dup(sys.stdin.fileno()))
>             self.output = os.fdopen(os.dup(sys.stdout.fileno()))
>             self.error = os.fdopen(os.dup(sys.stderr.fileno()))
>
>         def raw_input(self, prompt=""):
>             if prompt:
>                 self.output.write(prompt):
>                 self.output.flush()
>             return self.input.readline()
>
>         def write(self, data):
>             self.error.write(data)
>
> Also, the runcode() method will have to be overridden to use self.output
> instead of sys.stdout.  Those couple changes should (hopefully) insulate
> IPython from such user wackiness.
>
> Skip Montanaro
> skip at pobox.com
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/ipython-dev
>
>
>


-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From fullung at gmail.com  Sat Sep 30 05:09:43 2006
From: fullung at gmail.com (Albert Strasheim)
Date: Sat, 30 Sep 2006 11:09:43 +0200
Subject: [IPython-dev] Moin issues
Message-ID: <E1GTaqr-0003MB-H4@mail2.sun.ac.za>

Hello all

I noticed that some links on the IPython Moin site are pointing to the wrong
places. For example, on this page:

http://ipython.scipy.org/Parallel_Computing

there is a link to Parallel_Computing/FAQ but the URL Moin generates for
this page is:

http://ipython.scipy.org/moin/Parallel_Computing/FAQ

which goes to a non-existant page, instead of 

http://ipython.scipy.org/Parallel_Computing/FAQ

Regards,

Albert



From stefan at sun.ac.za  Sat Sep 30 17:45:56 2006
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Sat, 30 Sep 2006 23:45:56 +0200
Subject: [IPython-dev] emacs display problems + patch
Message-ID: <20060930214556.GI1607@mentat.za.net>

Hi,

Has anyone had a chance to take a look at the attached ipython.el
patch?

Cheers
St?fan
-------------- next part --------------
An embedded message was scrubbed...
From: Stefan van der Walt <stefan at sun.ac.za>
Subject: [IPython-dev] emacs display problems + patch
Date: Fri, 15 Sep 2006 11:26:49 +0200
Size: 6725
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060930/bd042d7b/attachment.mht>