From dd55 at cornell.edu  Thu Aug  2 10:48:38 2007
From: dd55 at cornell.edu (Darren Dale)
Date: Thu, 2 Aug 2007 10:48:38 -0400
Subject: [IPython-dev] problems with qt4 threading
Message-ID: <200708021048.39188.dd55@cornell.edu>

I recently updated to Qt-4.3 and PyQt-4.3. When I run "ipython -q4thread", I 
get a stream of error messages:

QSocketNotifier: Can only be used with threads started with QThread
QApplication::exec: Must be called from the main thread
QSocketNotifier: Can only be used with threads started with QThread
QApplication::exec: Must be called from the main thread
QSocketNotifier: Can only be used with threads started with QThread
QApplication::exec: Must be called from the main thread
...

I can interrupt IPython by hitting CTRL-D/Enter in rapid succession. If I run 
ipython -pylab with the qt4 backend enabled, I can still create plots and 
show windows, even with these warnings scrolling up the screen at a rate of 
10/second.

There is a page on threading in Qt4 here: 
http://doc.trolltech.com/4.3/threads.html

I'm sorry to say that after looking at the code for two hours, I don't have 
any suggestions on how to fix it.

Darren


From fperez.net at gmail.com  Tue Aug  7 13:38:01 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 7 Aug 2007 11:38:01 -0600
Subject: [IPython-dev] InterpreterPasteInput.py =>
	ipy_interpreter_paste.py
In-Reply-To: <46cb515a0708071015i1026eb1y57a8d0e9337a0c81@mail.gmail.com>
References: <46cb515a0708071015i1026eb1y57a8d0e9337a0c81@mail.gmail.com>
Message-ID: <db6b5ecc0708071038n7ad2add4u4034258654e1edc3@mail.gmail.com>

On 8/7/07, Ville M. Vainio <vivainio at gmail.com> wrote:

I'm cc-ing the dev list so this discussion is available to other
developers with commit rights.

> Hi,
>
> could you change the file name as suggested in the subject? It's very
> handy to see what ipy extensions/profiles are availably be entering
> "import ipy_<TAB>".

No, it will break backwards compatibility unnecessarily.  People have
existing installations with profiles that may call this file with the
old name, and there's absolutely no point in having an ipython update
break their installs.

We strive to keep things compatible with existing behavior.  Adding
features is great, but I see a lot of gratuitous changes here and
there, things that after an svn update stop working, etc.  I haven't
said anything because I don't want to appear to get in the way of
developing, but I think perhaps I should.

Once we have a project out that many people use daily, we should
really triple-think the justification behind changes that can break
daily usage patterns.  Even if a change is somehow an improvement
(though I fail to see how %hist changing to returning raw history is
one, it just bit me a few days ago), that has to be weighed against
existing user practice.

In cases where a change is a feature addition, we should just go for
it.  But wherever we break how a command used to work or any other
backwards-incompatible change, we should have a *really* good
justification for it.

I've started a separate file in doc/ besides the changelog, called
api_changes, where we should list any backward incompatibilities.
This can be as simple as copying over a changelog entry, but it will
help users be aware of what to look for in terms of potential
problems.

*****
For all developers: PLEASE document in api_changes any
backwards-incompatible change you make.  And do so AFTER we've
discussed here that such breakage is really necessary.

Matplotlib has had such a development policy for a long time, we
should have as well.  Now we do.
*****

I'm not saying we *never* break compatibility, but that we should only
do so if absolutely necessary.

Your original question is better answered by having an
ipy_interpreter_paste module that wraps the necessary functions in the
other one.  Note also that ipy_interperter must NOT actually import
the other one, since that one (unfortunately) installs its prefilter
unconditionally on import.  So the best alternative is probably to put
the implementation in ipy_interpreter_paste, and leave the old one
(for backwards compatibility) to load and activate it from
ipy_interpreter_paste.

That solution gives us:

- your desired tab completion
- backwards compatibility
- a cleaner behavior of the new module, which instead of
unconditionally installing the filter, will have something like an
activate_input_filter() routine that does the activation.

The old module could then become

from ipy_interpreter_paste import *
activate_input_filter()

and its code would be moved into the new ipy_interpreter_paste.

> Also, there is the general rule that advices against upper / mixed
> case module names...

Yes, the old codebase is a naming mess.  Again, not something worth
breaking every user's installation for.

The IPython1 codebase is much stricter on its naming/coding standards,
enforcement of documentation, real testing, etc.

Cheers,

f


From vivainio at gmail.com  Tue Aug  7 14:06:11 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 7 Aug 2007 20:06:11 +0200
Subject: [IPython-dev] InterpreterPasteInput.py =>
	ipy_interpreter_paste.py
In-Reply-To: <db6b5ecc0708071038n7ad2add4u4034258654e1edc3@mail.gmail.com>
References: <46cb515a0708071015i1026eb1y57a8d0e9337a0c81@mail.gmail.com>
	<db6b5ecc0708071038n7ad2add4u4034258654e1edc3@mail.gmail.com>
Message-ID: <46cb515a0708071106o7477d8cdk27a4bbc1d2d0fd06@mail.gmail.com>

On 8/7/07, Fernando Perez <fperez.net at gmail.com> wrote:

> Once we have a project out that many people use daily, we should
> really triple-think the justification behind changes that can break
> daily usage patterns.  Even if a change is somehow an improvement
> (though I fail to see how %hist changing to returning raw history is
> one, it just bit me a few days ago), that has to be weighed against
> existing user practice.

Why do you think "raw" mode for %hist is not an improvement? There was
a bug a while ago that screwed up the numbering, but it's fixed now.
Overall, I think it's better to have the default behaviour that has as
little "clutter" as possible (_ip.system etc.).

> In cases where a change is a feature addition, we should just go for
> it.  But wherever we break how a command used to work or any other
> backwards-incompatible change, we should have a *really* good
> justification for it.

Justification in this particular case is that %hist is an interactive
command, and as such unlikely to break scripts. In most "daily usage"
scenarios it should be a net win. I'm reluctant to talk about
"backwards compatibility" when we are dealing with interactive stuff.

I am not opposed to adding -t as default option to %hist in ipy_legacy.py.

> Yes, the old codebase is a naming mess.  Again, not something worth
> breaking every user's installation for.

I had no intention of breaking the profiles; in fact, after a hurried
svn up at work I thought it was a new file (even as only the profile
was new).

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


From fperez.net at gmail.com  Tue Aug  7 14:41:00 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 7 Aug 2007 12:41:00 -0600
Subject: [IPython-dev] InterpreterPasteInput.py =>
	ipy_interpreter_paste.py
In-Reply-To: <46cb515a0708071106o7477d8cdk27a4bbc1d2d0fd06@mail.gmail.com>
References: <46cb515a0708071015i1026eb1y57a8d0e9337a0c81@mail.gmail.com>
	<db6b5ecc0708071038n7ad2add4u4034258654e1edc3@mail.gmail.com>
	<46cb515a0708071106o7477d8cdk27a4bbc1d2d0fd06@mail.gmail.com>
Message-ID: <db6b5ecc0708071141t3c9bb68eucc81beb9f01b8dbd@mail.gmail.com>

On 8/7/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 8/7/07, Fernando Perez <fperez.net at gmail.com> wrote:
>
> > Once we have a project out that many people use daily, we should
> > really triple-think the justification behind changes that can break
> > daily usage patterns.  Even if a change is somehow an improvement
> > (though I fail to see how %hist changing to returning raw history is
> > one, it just bit me a few days ago), that has to be weighed against
> > existing user practice.
>
> Why do you think "raw" mode for %hist is not an improvement? There was
> a bug a while ago that screwed up the numbering, but it's fixed now.
> Overall, I think it's better to have the default behaviour that has as
> little "clutter" as possible (_ip.system etc.).

Fixing a bug is obviously an improvement.  The raw change can go
either way, since there are cases (such as when a prefilter cleans up
input) where the filtered history may be what you want.  All I'm
saying is that it's not an *unconditional* improvement: it is better
in some cases, worse in others.  In such a scenario, then we stick to
the existing behavior.  But let's not change anything here again, I'm
just explaining policy for the long term.

> > In cases where a change is a feature addition, we should just go for
> > it.  But wherever we break how a command used to work or any other
> > backwards-incompatible change, we should have a *really* good
> > justification for it.
>
> Justification in this particular case is that %hist is an interactive
> command, and as such unlikely to break scripts. In most "daily usage"
> scenarios it should be a net win. I'm reluctant to talk about
> "backwards compatibility" when we are dealing with interactive stuff.

People use ipython to write .ipy scripts now, so the behavior of
interactive commands *IS* part of what we have to worry about in terms
of backwards compatibility.  Imagine if the standard unix command-line
utilities changed their flags and default behavior on every release.
We'd all have gone bonkers by now.  I'm sure they *do* change, and
they break stuff, but the less that happens, the happier we'll all be.


Cheers,

f


From fperez.net at gmail.com  Wed Aug  8 19:39:32 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 8 Aug 2007 17:39:32 -0600
Subject: [IPython-dev] ANN: SnakeOil - Python testing that doesn't squeak :)
Message-ID: <db6b5ecc0708081639m78d4b15fw1f6799467d405921@mail.gmail.com>

Hi all,

For a long time I've been really fed up with feeling that the workflow
for testing in Python just isn't very fluid.  Generating doctests
requires typing code in text mode, rerunning and modifying them is
annoying, having a standalone test script become a unit test isn't
convenient, and the worst of all, writing parametrized tests in
unittest is a huge PITA.

IPython SVN now has a doctest profile to help a little (and I'll add a
magic to switch at runtime in and out of it, hopefully later tonight).
 But that's just a fix for one small annoyance among many.

I know there are testing frameworks out there that address some of
these issues (nose, py.test), but I wanted something small(ish), that
could be used without installing anything (easy to copy inside the
test area of any project and carry it from there, or install it in a
private area after a rename, etc), and that would only depend on the
stdlib (+ ipython, of course, since I use that everywhere).

So the IPython team is happy to announce SnakeOil:

svn co http://ipython.scipy.org/svn/ipython/ipython/branches/saw/sandbox/snakeoil/snakeoil

It's raw alpha, svn-only, lightly tested (about 2k LOC).  But it lets
me do *easily* all the things I needed to feel that adding tests
wasn't getting in *my* way.  If it doesn't work for you, no worries,
you can get your money back.

It's also fairly hackish in places (surprise, coming from me).
Unittest doesn't lend itself to much of anything, really, so I had to
beat it into behaving in a few places.  Still, I wanted to stick to
valid unittest classes so that using SnakeOil would not make your
tests citizens of yet-another-framework.

The doc/ directory has a reST document with some more details as well
as a fully worked set of examples.

The highlights:

- Easy creation of parametric tests (unittests that take arguments).
That includes tests that share state (yes, I know about shared state
in tests.  I'm an adult, I know what I'm doing and I need that.  Now
unittest, get out of my way and let me actually work).

- Immediate use of any standalone testing script as a unit test, without having
to subclass anything.

- Easy mechanisms for creating valid doctest (.txt) files from true Python
sources, so that one can edit real Python code in an editor and convert that
code to a set of doctests with minimal effort.



This will be integrated in ipython1 later, but for now it sits in the
sandbox.  We'll announce when we move it out.  We first need to check
that everything works with Twisted trial correctly (I think it does,
but I haven't checked enough yet).

Comments/feedback welcome.

Cheers,

f


From fperez.net at gmail.com  Sat Aug 11 14:55:00 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 11 Aug 2007 12:55:00 -0600
Subject: [IPython-dev] ipython1 saw exception transport and raising
In-Reply-To: <1315be7e0708100654l5e652497h594c51ea8679b02e@mail.gmail.com>
References: <1315be7e0707090759u6bedef93nea0d65e87fe2536@mail.gmail.com>
	<6ce0ac130707121951l1a5e4c8bt6d7b1e4fcc656dfc@mail.gmail.com>
	<1315be7e0707161058i6f958cb5sc8188928c3aad433@mail.gmail.com>
	<db6b5ecc0707161207v70275897l2a2f7fe743050580@mail.gmail.com>
	<1315be7e0707161558u27450a57s19949d902db9f7ae@mail.gmail.com>
	<db6b5ecc0707161601y361cfc92yb7bb64d6139c7343@mail.gmail.com>
	<1315be7e0708100654l5e652497h594c51ea8679b02e@mail.gmail.com>
Message-ID: <db6b5ecc0708111155x9b044edo520a375540d23397@mail.gmail.com>

Hi Doug,

On 8/10/07, Doug Jones <dfj225 at gmail.com> wrote:
> I didn't see any messages in response to this, so I'm curious, has
> this been fixed in svn yet?

I'm afraid no, and I'm embarrassed to say so.  All my recent time for
ipython went into two large pieces of infrastructure that were
long-needed and that required a solid, concentrated effort (the
TConfig system and the SnakeOil testing tools, both now in the
sandbox).

That was roughly 6000 LOC I had to write in just the last 3 weeks, and
 it required a lot of concentrated effort.

Those are now both finished, and I  hope that this week while at the
Scipy conference, Brian and I will be able to pound a bit on these
remaining problems.

My apology: I know the exception propagation bug is *critical* and I'd
promised to fix it long ago.  But there's only so much code I can
write...

Cheers,

f


From fperez.net at gmail.com  Sat Aug 11 14:56:18 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 11 Aug 2007 12:56:18 -0600
Subject: [IPython-dev] ipython1 saw exception transport and raising
In-Reply-To: <db6b5ecc0708111155x9b044edo520a375540d23397@mail.gmail.com>
References: <1315be7e0707090759u6bedef93nea0d65e87fe2536@mail.gmail.com>
	<6ce0ac130707121951l1a5e4c8bt6d7b1e4fcc656dfc@mail.gmail.com>
	<1315be7e0707161058i6f958cb5sc8188928c3aad433@mail.gmail.com>
	<db6b5ecc0707161207v70275897l2a2f7fe743050580@mail.gmail.com>
	<1315be7e0707161558u27450a57s19949d902db9f7ae@mail.gmail.com>
	<db6b5ecc0707161601y361cfc92yb7bb64d6139c7343@mail.gmail.com>
	<1315be7e0708100654l5e652497h594c51ea8679b02e@mail.gmail.com>
	<db6b5ecc0708111155x9b044edo520a375540d23397@mail.gmail.com>
Message-ID: <db6b5ecc0708111156h45266e87xd1f9f32549ebf9c3@mail.gmail.com>

On 8/11/07, Fernando Perez <fperez.net at gmail.com> wrote:

> That was roughly 6000 LOC I had to write in just the last 3 weeks, and
                   ^^^^
Oops, typo: just 4000.

Cheers,

f


From fperez.net at gmail.com  Sun Aug 12 20:28:36 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 12 Aug 2007 18:28:36 -0600
Subject: [IPython-dev] Doctest fixes, testing release out
Message-ID: <db6b5ecc0708121728q39296af9t4c239ae06d1e435f@mail.gmail.com>

Hi all,

over time, there have been repeated reports of doctest not working
when running under IPython.  I think I finally fixed it deep enough
that things should now work correctly in all cases, so that you can
run any script or test suite that calls the various doctest testing
runners, when inside ipython, and everything should just work.  If you
are on SVN just update, or grab a testing release that I just made
from current SVN here:

http://ipython.scipy.org/dist/testing/

I need these publicly available for a conference this week, and they
wrap up all the recent fixes.  We'll start thinking about a release
soon, but for now this will do.


I should also mention that there's a new magic, %doctest_mode, that
toggles you in and out of a mode where the prompts are
doctest-compliant, and where you can paste into the interactive
session code with '>>>' prompts (including leading whitespace).  The
doctest profile is not really needed anymore, since you can just
switch at runtime into this mode from a normal ipython session without
having to restart, and you can switch out again to the normal In[]
prompts as needed.  Note that even though you don't see the numbered
prompts, they continue to exist:

In [20]: 2**4
Out[20]: 16

In [21]: %doctest_mode
Exception reporting mode: Plain
Doctest mode is: ON
>>> _20+99
115
>>> %doctest_mode
Exception reporting mode: Context
Doctest mode is: OFF

In [24]: Out.keys()
Out[24]: [1, 3, 4, 9, 14, 16, 19, 20, 22]

In [25]: _22
Out[25]: 115


Between SnakeOil and the new doctest support, ipython should now be a
good system for workflows that rely heavily on doctests.  Please
report any problems you may find with this...

Cheers,

f


From fperez.net at gmail.com  Mon Aug 13 13:44:12 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 13 Aug 2007 11:44:12 -0600
Subject: [IPython-dev] [Ipython-svndiff] 2609 - prefilter: make sure
	that ! gets precedence
In-Reply-To: <20070813173913.B90AD39C0F4@new.scipy.org>
References: <20070813173913.B90AD39C0F4@new.scipy.org>
Message-ID: <db6b5ecc0708131044pcb68bfaje912266475b8b114@mail.gmail.com>

On 8/13/07, ipython-svndiff at scipy.org <ipython-svndiff at scipy.org> wrote:
> Author: vivainio
> Date: 2007-08-13 12:39:08 -0500 (Mon, 13 Aug 2007)
> New Revision: 2609
>
> Modified:
>    ipython/trunk/IPython/prefilter.py
> Log:
> prefilter: make sure that ! gets precedence
>
> Modified: ipython/trunk/IPython/prefilter.py
> ===================================================================
> --- ipython/trunk/IPython/prefilter.py  2007-08-13 17:37:41 UTC (rev 2608)
> +++ ipython/trunk/IPython/prefilter.py  2007-08-13 17:39:08 UTC (rev 2609)
> @@ -48,6 +48,11 @@
>          self.pre, self.iFun, self.theRest = splitUserInput(line)
>
>          self.preChar       = self.pre.strip()
> +
> +        # special override for !, which MUST always have top priority
> +        if not self.preChar and self.iFun.startswith('!'):
> +            self.preChar = self.pre = '!'

Please don't hardcode the special escapes, that's why we have a table
of constants:

        # escapes for automatic behavior on the command line
        self.ESC_SHELL  = '!'
        self.ESC_SH_CAP = '!!'
        self.ESC_HELP   = '?'
        self.ESC_MAGIC  = '%'
        self.ESC_QUOTE  = ','
        self.ESC_QUOTE2 = ';'
        self.ESC_PAREN  = '/'

If anyone ever writes a customized shell and modifies this, hardcoded
symbols deep inside are going to make a mess.

f


From jussi.rasinmaki at helsinki.fi  Wed Aug 15 02:28:54 2007
From: jussi.rasinmaki at helsinki.fi (=?ISO-8859-1?Q?Jussi_Rasinm=E4ki?=)
Date: Wed, 15 Aug 2007 09:28:54 +0300
Subject: [IPython-dev] Failing trial ipython1
Message-ID: <70cb18dc0708142328i338fd340of5aa1b172b591b4f@mail.gmail.com>

Hi,

Just informing about a failing ipython1 test suite.
I installed IPython1 on a cluster following the instruction on
http://projects.scipy.org/ipython/ipython/browser/ipython/branches/saw/INSTALL.
The cluster consists of an HP ProLiant DL585 front end node and 128 HP
ProLiant DL145G2 compute nodes running on Rocks Linux 3.2.0. As I
don't have the admin privileges on the cluster, I first installed
Python 2.5.1 in my home directory, hence the strange site-packages
location in the error message.
For IPython I tried both the current and development version.

Jussi
========================
trial ipython1 results:

ipython1.test.test_newserialized
  SerializedTestCase
    testNDArraySerialized ...                                              [OK]
    testPickleSerialized ...                                               [OK]
    testSerializedInterfaces ...                                           [OK]
                                       [ERROR]
ipython1.test.util
  DeferredTestCase
    runTest ...                                                            [OK]
ipython1.test.test_pendingdeferred
  PendingDeferredManagerTest
    testBasic ...                                                          [OK]
    testPDA ...                                                            [OK]
ipython1.test.test_shell
  BasicShellTest
    testCommand ...                                                        [OK]
    testExecute ...                                                        [OK]
    testPutGet ...                                                         [OK]
    testUpdate ...                                                         [OK]
ipython1.test.test_task
  TaskTest
    testAbort ...                                                          [OK]
    testClears ...                                                         [OK]
    testInfiniteRecoveryLoop ...                                           [OK]
    testRecoveryTasks ...                                                  [OK]
    testSetupNS ...                                                        [OK]
    testSimpleRetries ...                                                  [OK]
    testTaskIDs ...                                                        [OK]
    testTaskResults ...                                                    [OK]
ipython1.test.test_tools_utils
  utilsTestCase
    test_foo ...                                                           [OK]
doctest
  DocFileCase
    tst_tools_utils_doctest_txt ...                                        [OK]
    tst_tools_utils_doctest2_txt ...                                       [OK]
  DocTestCase
    extractVars ...                                                        [OK]
    list_strings ...                                                       [OK]
    marquee ...                                                            [OK]
    shexp ...                                                              [OK]

===============================================================================
[ERROR]: ipython1.test.test_notebook

Traceback (most recent call last):
  File "/home/u1/rasinma/local/lib/python2.5/site-packages/twisted/trial/runner.py",
line 555, in loadPackage
    module = modinfo.load()
  File "/home/u1/rasinma/local/lib/python2.5/site-packages/twisted/python/modules.py",
line 386, in load
    return self.pathEntry.pythonPath.moduleLoader(self.name)
  File "/home/u1/rasinma/local/lib/python2.5/site-packages/twisted/python/modules.py",
line 621, in moduleLoader
    return self._moduleLoader(modname)
  File "/home/u1/rasinma/local/lib/python2.5/site-packages/twisted/python/reflect.py",
line 357, in namedAny
    topLevelPackage = __import__(trialname)
  File "/home/u1/rasinma/local/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/test/test_notebook.py",
line 22, in <module>
    from ipython1.notebook import notebook, dbutil, xmlutil
  File "/home/u1/rasinma/local/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/notebook/notebook.py",
line 23, in <module>
    from ipython1.notebook import models, dbutil, xmlutil
  File "/home/u1/rasinma/local/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/notebook/models.py",
line 547, in <module>
    tagMapper = mapper(Tag, tagsTable,
exceptions.NameError: name 'mapper' is not defined
-------------------------------------------------------------------------------
Ran 116 tests in 6.780s

FAILED (errors=1, successes=116)


From fperez.net at gmail.com  Wed Aug 15 02:55:06 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 15 Aug 2007 00:55:06 -0600
Subject: [IPython-dev] Failing trial ipython1
In-Reply-To: <70cb18dc0708142328i338fd340of5aa1b172b591b4f@mail.gmail.com>
References: <70cb18dc0708142328i338fd340of5aa1b172b591b4f@mail.gmail.com>
Message-ID: <db6b5ecc0708142355m35532f9dva8cacbc5aaf87cd2@mail.gmail.com>

Hi Jussi,

On 8/15/07, Jussi Rasinm?ki <jussi.rasinmaki at helsinki.fi> wrote:
> Hi,
>
> Just informing about a failing ipython1 test suite.
> I installed IPython1 on a cluster following the instruction on
> http://projects.scipy.org/ipython/ipython/browser/ipython/branches/saw/INSTALL.
> The cluster consists of an HP ProLiant DL585 front end node and 128 HP
> ProLiant DL145G2 compute nodes running on Rocks Linux 3.2.0. As I
> don't have the admin privileges on the cluster, I first installed
> Python 2.5.1 in my home directory, hence the strange site-packages
> location in the error message.
> For IPython I tried both the current and development version.

> ===============================================================================
> [ERROR]: ipython1.test.test_notebook

thanks for the report.  We'll look into it, but in the meantime, don't
worry.  The notebook component is under heavy development and not
currently used anywhere as user-visible code, so this failure has no
impact at all on the use of the system for distributed/parallel work.

regards,

f


From fperez.net at gmail.com  Wed Aug 15 03:43:37 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 15 Aug 2007 01:43:37 -0600
Subject: [IPython-dev] ipython1 saw exception transport and raising
In-Reply-To: <1315be7e0707161058i6f958cb5sc8188928c3aad433@mail.gmail.com>
References: <1315be7e0707090759u6bedef93nea0d65e87fe2536@mail.gmail.com>
	<6ce0ac130707121951l1a5e4c8bt6d7b1e4fcc656dfc@mail.gmail.com>
	<1315be7e0707161058i6f958cb5sc8188928c3aad433@mail.gmail.com>
Message-ID: <db6b5ecc0708150043u39d2201byca071a5ba359868b@mail.gmail.com>

On 7/16/07, Doug Jones <dfj225 at gmail.com> wrote:

> As you see, some of the information that is part of the ArgumentError
> is either not transported or not displayed. Unlike last time, I don't
> really have any ideas as to why.

OK, I think I got it finally... Please svn up and let us know.  Here's
what I'm getting for simple tests:

ZeroDivisionError: integer division or modulo by zero
***************************************************************************
Exception in the IPython Engine.

Engine action that caused the error:

engine: 0
method: execute(lines)
lines =
import os
os.chdir('/home/fperez/ipython/test/ip1')
import err
err.bad()
#abd snytxx


Full traceback:
---------------------------------------------------------------------------
ZeroDivisionError                         Traceback (most recent call last)

/home/fperez/ipython/test/ip1/<string> in <module>()

/home/fperez/ipython/test/ip1/err.py in bad()
     14
     15 def bad():
---> 16     1/0
     17
     18 #bad()

ZeroDivisionError: integer division or modulo by zero
***************************************************************************

WARNING: Failure executing file: <tst.py>


Syntax errors are reported with a clumsy traceback:

SyntaxError: invalid syntax (line 5)
***************************************************************************
Exception in the IPython Engine.

Engine action that caused the error:

engine: 0
method: execute(lines)
lines =
import os
os.chdir('/home/fperez/ipython/test/ip1')
import err
err.bad()
abd snytxx


Full traceback:
---------------------------------------------------------------------------
SyntaxError                               Traceback (most recent call last)

/home/fperez/usr/lib/python2.5/site-packages/ipython1/core/interpreter.py
in split_commands(self, python)
    511         # Uncomment to help debug the ast tree
    512         # for n in ast.node:
--> 513         #     print n.lineno,'->',n
    514
    515         # Each separate command is available by iterating over
ast.node. The

/home/fperez/ipython/test/ip1/compiler/transformer.py in parse(buf, mode)
     50
     51
---> 52
     53
     54

/home/fperez/ipython/test/ip1/compiler/transformer.py in parsesuite(self, text)
    127
    128
--> 129
    130
    131

SyntaxError: invalid syntax (line 5)
***************************************************************************


WARNING: Failure executing file: <tst.py>


But the info is really  all there.   It's just that managing traceback
formatting across the network in this way is not particularly easy,
and I'm a bit too fried now to do more...

But at least now we are getting all the necessary info across, even if
for syntax errors the report isn't the nicest.

Cheers,

f


From fredmfp at gmail.com  Thu Aug 16 19:35:28 2007
From: fredmfp at gmail.com (fred)
Date: Fri, 17 Aug 2007 01:35:28 +0200
Subject: [IPython-dev] confirm_exit issue with scipy profile...
Message-ID: <46C4DF40.2000008@gmail.com>

Hi all,

I have set

confirm_exit 0

in my ipythonrc file.

So I type Ctrl+D in ipython, it exits
as expected.

But if I use the scipy profile

ipython -p scipy,

confirmation is asked when I want to exit.

Any clue ?

TIA.

Cheers,

PS: my ipythonrc-scipy file only contains

include ipythonrc

# import ...
# Load SciPy by itself so that 'help scipy' works
import_mod scipy

# from ... import ...
from scipy.io.numpyio import fread, fwrite

# Now we load all of SciPy
# from ... import *
import_all scipy

# code
execute print 'Welcome to the SciPy Scientific Computing Environment.'

PS2: I use svn #2635.

-- 
http://scipy.org/FredericPetit




From fredmfp at gmail.com  Thu Aug 16 19:36:50 2007
From: fredmfp at gmail.com (fred)
Date: Fri, 17 Aug 2007 01:36:50 +0200
Subject: [IPython-dev] confirm_exit issue with scipy profile...
In-Reply-To: <46C4DF40.2000008@gmail.com>
References: <46C4DF40.2000008@gmail.com>
Message-ID: <46C4DF92.7010609@gmail.com>

fred a ?crit :

Oops, sorry.

Too tired...

-- 
http://scipy.org/FredericPetit



From vivainio at gmail.com  Fri Aug 17 01:04:01 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 17 Aug 2007 07:04:01 +0200
Subject: [IPython-dev] confirm_exit issue with scipy profile...
In-Reply-To: <46C4DF40.2000008@gmail.com>
References: <46C4DF40.2000008@gmail.com>
Message-ID: <46cb515a0708162204u21000259m440ff7b66aaa3c26@mail.gmail.com>

On 8/17/07, fred <fredmfp at gmail.com> wrote:

> Hi all,
>
> I have set
>
> confirm_exit 0
>
> in my ipythonrc file.

No time to explore right now, but your best bet is to put this in
ipy_user_conf.py instead.

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


From ellisonbg.net at gmail.com  Fri Aug 17 12:33:11 2007
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Fri, 17 Aug 2007 09:33:11 -0700
Subject: [IPython-dev] Failing trial ipython1
In-Reply-To: <70cb18dc0708142328i338fd340of5aa1b172b591b4f@mail.gmail.com>
References: <70cb18dc0708142328i338fd340of5aa1b172b591b4f@mail.gmail.com>
Message-ID: <6ce0ac130708170933n41c6fffbg1a41d7ff3c6d2810@mail.gmail.com>

As Fernando says, the notebook is not part of the core parallel stuff
and is under heavy development.  This is not a problem.  Thanks though

Brian

On 8/14/07, Jussi Rasinm?ki <jussi.rasinmaki at helsinki.fi> wrote:
> Hi,
>
> Just informing about a failing ipython1 test suite.
> I installed IPython1 on a cluster following the instruction on
> http://projects.scipy.org/ipython/ipython/browser/ipython/branches/saw/INSTALL.
> The cluster consists of an HP ProLiant DL585 front end node and 128 HP
> ProLiant DL145G2 compute nodes running on Rocks Linux 3.2.0. As I
> don't have the admin privileges on the cluster, I first installed
> Python 2.5.1 in my home directory, hence the strange site-packages
> location in the error message.
> For IPython I tried both the current and development version.
>
> Jussi
> ========================
> trial ipython1 results:
>
> ipython1.test.test_newserialized
>   SerializedTestCase
>     testNDArraySerialized ...                                              [OK]
>     testPickleSerialized ...                                               [OK]
>     testSerializedInterfaces ...                                           [OK]
>                                        [ERROR]
> ipython1.test.util
>   DeferredTestCase
>     runTest ...                                                            [OK]
> ipython1.test.test_pendingdeferred
>   PendingDeferredManagerTest
>     testBasic ...                                                          [OK]
>     testPDA ...                                                            [OK]
> ipython1.test.test_shell
>   BasicShellTest
>     testCommand ...                                                        [OK]
>     testExecute ...                                                        [OK]
>     testPutGet ...                                                         [OK]
>     testUpdate ...                                                         [OK]
> ipython1.test.test_task
>   TaskTest
>     testAbort ...                                                          [OK]
>     testClears ...                                                         [OK]
>     testInfiniteRecoveryLoop ...                                           [OK]
>     testRecoveryTasks ...                                                  [OK]
>     testSetupNS ...                                                        [OK]
>     testSimpleRetries ...                                                  [OK]
>     testTaskIDs ...                                                        [OK]
>     testTaskResults ...                                                    [OK]
> ipython1.test.test_tools_utils
>   utilsTestCase
>     test_foo ...                                                           [OK]
> doctest
>   DocFileCase
>     tst_tools_utils_doctest_txt ...                                        [OK]
>     tst_tools_utils_doctest2_txt ...                                       [OK]
>   DocTestCase
>     extractVars ...                                                        [OK]
>     list_strings ...                                                       [OK]
>     marquee ...                                                            [OK]
>     shexp ...                                                              [OK]
>
> ===============================================================================
> [ERROR]: ipython1.test.test_notebook
>
> Traceback (most recent call last):
>   File "/home/u1/rasinma/local/lib/python2.5/site-packages/twisted/trial/runner.py",
> line 555, in loadPackage
>     module = modinfo.load()
>   File "/home/u1/rasinma/local/lib/python2.5/site-packages/twisted/python/modules.py",
> line 386, in load
>     return self.pathEntry.pythonPath.moduleLoader(self.name)
>   File "/home/u1/rasinma/local/lib/python2.5/site-packages/twisted/python/modules.py",
> line 621, in moduleLoader
>     return self._moduleLoader(modname)
>   File "/home/u1/rasinma/local/lib/python2.5/site-packages/twisted/python/reflect.py",
> line 357, in namedAny
>     topLevelPackage = __import__(trialname)
>   File "/home/u1/rasinma/local/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/test/test_notebook.py",
> line 22, in <module>
>     from ipython1.notebook import notebook, dbutil, xmlutil
>   File "/home/u1/rasinma/local/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/notebook/notebook.py",
> line 23, in <module>
>     from ipython1.notebook import models, dbutil, xmlutil
>   File "/home/u1/rasinma/local/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/notebook/models.py",
> line 547, in <module>
>     tagMapper = mapper(Tag, tagsTable,
> exceptions.NameError: name 'mapper' is not defined
> -------------------------------------------------------------------------------
> Ran 116 tests in 6.780s
>
> FAILED (errors=1, successes=116)
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Fri Aug 17 15:20:31 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 17 Aug 2007 13:20:31 -0600
Subject: [IPython-dev] confirm_exit issue with scipy profile...
In-Reply-To: <46cb515a0708162204u21000259m440ff7b66aaa3c26@mail.gmail.com>
References: <46C4DF40.2000008@gmail.com>
	<46cb515a0708162204u21000259m440ff7b66aaa3c26@mail.gmail.com>
Message-ID: <db6b5ecc0708171220r32189d9t485f39266c707f55@mail.gmail.com>

On 8/16/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 8/17/07, fred <fredmfp at gmail.com> wrote:
>
> > Hi all,
> >
> > I have set
> >
> > confirm_exit 0
> >
> > in my ipythonrc file.
>
> No time to explore right now, but your best bet is to put this in
> ipy_user_conf.py instead.
>

There's a bug in priorities, because it's possible that the new
ipy_profile_scipy profile is overriding the one in Fred's home dir.
Data/configs in the user's directory should always override
system-provided ones.

Currently, the new system-side scipy profile is overriding Fred's, and
not properly loading the base one.  That's a bug in the new system to
load profiles, which will hopefully be fixed soon:

http://projects.scipy.org/ipython/ipython/ticket/177

Cheers,

f


From Glen.Mabey at swri.org  Mon Aug 20 12:33:07 2007
From: Glen.Mabey at swri.org (Glen W. Mabey)
Date: Mon, 20 Aug 2007 11:33:07 -0500
Subject: [IPython-dev] pull()ing instances of custom classes
Message-ID: <20070820163307.GA22017@bams.ccf.swri.edu>

Hello,

I'm using saw with python2.5.1, and have encountered either a bug or a
limitation with ... I don't know what part of ipython1.

What I want to be able to do is to pull back instances of a class, which
chokes.  The error produced makes sense now that I understand what the
problem is, but it sure had me going in the wrong direction for quite a
while.

The error looks like this:

<type 'exceptions.ImportError'>: No module named importerrorexample
> /usr/local/stow/twisted-20070806_svn-py2.5/lib/python2.5/site-packages/twisted/python/failure.py(301)raiseException()
    300         """
--> 301         raise self.type, self.value, self.tb
    302 


from the attached code, when a controller is passed to run().

Any insight into this issue would be very much appreciated.

Thanks,
Glen Mabey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: importerrorexample.py
Type: text/x-python
Size: 871 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070820/0f6cec8b/attachment.py>

From vivainio at gmail.com  Mon Aug 20 17:08:14 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 20 Aug 2007 23:08:14 +0200
Subject: [IPython-dev] confirm_exit issue with scipy profile...
In-Reply-To: <db6b5ecc0708171220r32189d9t485f39266c707f55@mail.gmail.com>
References: <46C4DF40.2000008@gmail.com>
	<46cb515a0708162204u21000259m440ff7b66aaa3c26@mail.gmail.com>
	<db6b5ecc0708171220r32189d9t485f39266c707f55@mail.gmail.com>
Message-ID: <46cb515a0708201408k6b3881ecmac61b6e114549daf@mail.gmail.com>

On 8/17/07, Fernando Perez <fperez.net at gmail.com> wrote:

> > > I have set
> > >
> > > confirm_exit 0
> > >
> > > in my ipythonrc file.
> >
> > No time to explore right now, but your best bet is to put this in
> > ipy_user_conf.py instead.
> >
>
> There's a bug in priorities, because it's possible that the new
> ipy_profile_scipy profile is overriding the one in Fred's home dir.
> Data/configs in the user's directory should always override
> system-provided ones.
>
> Currently, the new system-side scipy profile is overriding Fred's, and
> not properly loading the base one.  That's a bug in the new system to
> load profiles, which will hopefully be fixed soon:

I'm not sure I want to fix this.

The deal is, we don't typically want profiles in ~/_ipython, but let
them stay in Extensions. The profile in itself should be as
"functional" out of the box as possible, and the user should be
content in doing their settings/customization in ipy_user_conf.py (or
add a new profile that imports the old profile and specializes it).

The particular issue with scipy profile is that it does "import
ipy_defaults", which sets the "sensible" default values for many
variables (i.e. what ipythonrc was basically doing). "ipythonrc"
should not override them. My guess is that there is no "scipy" profile
in fred's ~/_ipython (and hence no "include ipythonrc" that it came
with), they are not installed anymore (but are honored if they do
exist).

The change I *will* probably put in (and that will take care of
backwards compatibility) is:

- If ipythonrc-PROFILE is found, do not import ipy_profile_PROFILE

ipythonrc-PROFILE files still will not be installed to ~/_ipython,
this feature is retained for backwards compatibility on/y (i.e. for
people w/ existing profile files they do not want to convert over to
the new system).

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


From vivainio at gmail.com  Mon Aug 20 17:11:45 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 20 Aug 2007 23:11:45 +0200
Subject: [IPython-dev] confirm_exit issue with scipy profile...
In-Reply-To: <46cb515a0708201408k6b3881ecmac61b6e114549daf@mail.gmail.com>
References: <46C4DF40.2000008@gmail.com>
	<46cb515a0708162204u21000259m440ff7b66aaa3c26@mail.gmail.com>
	<db6b5ecc0708171220r32189d9t485f39266c707f55@mail.gmail.com>
	<46cb515a0708201408k6b3881ecmac61b6e114549daf@mail.gmail.com>
Message-ID: <46cb515a0708201411o4f48cbedpc2480b99bec8549e@mail.gmail.com>

> should not override them. My guess is that there is no "scipy" profile
> in fred's ~/_ipython (and hence no "include ipythonrc" that it came

Ok, that was a bad guess. But nevertheless, this will be fixed by my
stated plan - though what we really need to fix is the docs.

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


From hans_meine at gmx.net  Tue Aug 21 02:32:46 2007
From: hans_meine at gmx.net (Hans Meine)
Date: Tue, 21 Aug 2007 08:32:46 +0200
Subject: [IPython-dev] confirm_exit issue with scipy profile...
In-Reply-To: <46cb515a0708201408k6b3881ecmac61b6e114549daf@mail.gmail.com>
References: <46C4DF40.2000008@gmail.com>
	<db6b5ecc0708171220r32189d9t485f39266c707f55@mail.gmail.com>
	<46cb515a0708201408k6b3881ecmac61b6e114549daf@mail.gmail.com>
Message-ID: <200708210833.02750.hans_meine@gmx.net>

BTW: My (stock) ip_profile_sh already says:
> # The import below effectively obsoletes your old-style ipythonrc[.ini],
> # so consider yourself warned!
>
> import ipy_sane_defaults

On Montag 20 August 2007, Ville M. Vainio wrote:
> ipythonrc-PROFILE files still will not be installed to ~/_ipython,
> this feature is retained for backwards compatibility on/y (i.e. for
> people w/ existing profile files they do not want to convert over to
> the new system).
FWIW, I mostly prefer the old ipythonrc files -- I am only using import_mod 
and import_all (and import_some) anyways.

import_mod is easy to replace with a real import without getting much longer, 
but import_all is a very convenient shortcut.

And -- please point out if I missed something -- although I would occasionally 
like to run arbitrary python code *in the user namespace*, the new config 
files need me to wrap it in string quotes for ip.ex(), no?
(Losing syntax highlighting, automatic indentation etc. in my editor..)

-- 
Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070821/f187c30e/attachment.sig>

From vivainio at gmail.com  Tue Aug 21 03:17:24 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 21 Aug 2007 09:17:24 +0200
Subject: [IPython-dev] confirm_exit issue with scipy profile...
In-Reply-To: <200708210833.02750.hans_meine@gmx.net>
References: <46C4DF40.2000008@gmail.com>
	<db6b5ecc0708171220r32189d9t485f39266c707f55@mail.gmail.com>
	<46cb515a0708201408k6b3881ecmac61b6e114549daf@mail.gmail.com>
	<200708210833.02750.hans_meine@gmx.net>
Message-ID: <46cb515a0708210017o56774c36p9259cea783747534@mail.gmail.com>

On 8/21/07, Hans Meine <hans_meine at gmx.net> wrote:

> BTW: My (stock) ip_profile_sh already says:
> > # The import below effectively obsoletes your old-style ipythonrc[.ini],
> > # so consider yourself warned!
> >
> > import ipy_sane_defaults

Ok, that's probably an old version. It has been called ipy_defaults for a while.

> FWIW, I mostly prefer the old ipythonrc files -- I am only using import_mod
> and import_all (and import_some) anyways.
>
> import_mod is easy to replace with a real import without getting much longer,
> but import_all is a very convenient shortcut.

Yeah, the benefits of the new config files mostly become apparent with
less trivial cases. Of course you could add

def import_all(m): ip.ex('from %s import *' % m)

to the beginning of the file yourself.

> And -- please point out if I missed something -- although I would occasionally
> like to run arbitrary python code *in the user namespace*, the new config
> files need me to wrap it in string quotes for ip.ex(), no?
> (Losing syntax highlighting, automatic indentation etc. in my editor..)

Of course you can still put stuff in modules, and import them with ip.ex.

There is really nothing you "need" to do with the new style, apart
from verifying it's legal Python... and that's a good thing.

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


From hans_meine at gmx.net  Tue Aug 21 05:17:47 2007
From: hans_meine at gmx.net (Hans Meine)
Date: Tue, 21 Aug 2007 11:17:47 +0200
Subject: [IPython-dev] confirm_exit issue with scipy profile...
In-Reply-To: <46cb515a0708210017o56774c36p9259cea783747534@mail.gmail.com>
References: <46C4DF40.2000008@gmail.com>
	<200708210833.02750.hans_meine@gmx.net>
	<46cb515a0708210017o56774c36p9259cea783747534@mail.gmail.com>
Message-ID: <200708211117.47915.hans_meine@gmx.net>

Am Dienstag, 21. August 2007 09:17:24 schrieben Sie:
> Yeah, the benefits of the new config files mostly become apparent with
> less trivial cases.
I noticed that.  I just wanted to point this out (again), so maybe the trivial 
cases can get better support.

> Of course you could add 
>
> def import_all(m): ip.ex('from %s import *' % m)
>
> to the beginning of the file yourself.

That's a good idea.  But wouldn't it be nice to provide this function in 
ipython itself?  Maybe extended like this:

def import_all(*modules):
  for m in modules:
    ip.ex('from %s import *' % m)

or even:

def import_all(modules):
  for m in modules.split():
    ip.ex('from %s import *' % m)

The latter would allow writing e.g.

import_all("math os numpy")

Also, one might include "from IPython import ipapi" in the namespace.

> > And -- please point out if I missed something -- although I would
> > occasionally like to run arbitrary python code *in the user namespace*,
> > the new config files need me to wrap it in string quotes for ip.ex(), no?
> > (Losing syntax highlighting, automatic indentation etc. in my editor..)
>
> Of course you can still put stuff in modules, and import them with ip.ex.
>
> There is really nothing you "need" to do with the new style, apart
> from verifying it's legal Python... and that's a good thing.

Yes, it's a really good thing, but not every ipython user wants to write a 
sophisticated config file (I know a lot of people who do not even bother 
creating their own profiles, but simply execfile() their setup scripts).  It 
would simplify matters if there was an additional config API for the simple 
things.

Reciting you from above:
> Of course you can still put stuff in modules, and import them with ip.ex.
I thought about that, yes.  But I wonder if it wouldn't be better to accompany 
each ip_profile_foo with an ipy_profile_foo_userspace which is automatically 
loaded?  Or - even better - add a special entrypoint in ipy_profile_foo.py 
for code automatically run in userspace.  Currently, the code is simply 
import'ed, right?  Hmm, I see no nice (and backwards-compatible), 
non-complicated way of differentiating between the two namespaces then. :-(

Is .ipython in sys.path?  Apparently not.  I tried moving my code into an 
ipy_handy_utils.py and adding ip.ex("from ipy_handy_utils import *") to 
ipy_user_conf.py, but I am getting:
> WARNING: Could not import user config!
>  ('/home/meine/.ipython/ipy_user_conf.py' does not exist? Please run
> '%upgrade')
Seems to be a caught exception - obviously all ImportErrors are caught.  
AFAICS, this should be changed to check whether the failed import actually 
was ipy_user_conf itself.  I cannot check right now, because the 
ipython.scipy.org seems to be down right now.

Nice greetings,
  Hans


From vivainio at gmail.com  Tue Aug 21 07:18:24 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 21 Aug 2007 13:18:24 +0200
Subject: [IPython-dev] confirm_exit issue with scipy profile...
In-Reply-To: <200708211117.47915.hans_meine@gmx.net>
References: <46C4DF40.2000008@gmail.com>
	<200708210833.02750.hans_meine@gmx.net>
	<46cb515a0708210017o56774c36p9259cea783747534@mail.gmail.com>
	<200708211117.47915.hans_meine@gmx.net>
Message-ID: <46cb515a0708210418h145fa4e2ve439b3313f590017@mail.gmail.com>

On 8/21/07, Hans Meine <hans_meine at gmx.net> wrote:

> or even:
>
> def import_all(modules):
>  for m in modules.split():
>    ip.ex('from %s import *' % m)
>
> The latter would allow writing e.g.
>
> import_all("math os numpy")

That would be ok, I guess: the ipapi already has some redundancy for
convenience, a'la to_user_ns.

> Also, one might include "from IPython import ipapi" in the namespace.

It is there. '_ip' always points to an ipapi instance in a live
IPython interpreter.

> > There is really nothing you "need" to do with the new style, apart
> > from verifying it's legal Python... and that's a good thing.
>
> Yes, it's a really good thing, but not every ipython user wants to write a
> sophisticated config file (I know a lot of people who do not even bother
> creating their own profiles, but simply execfile() their setup scripts).  It
> would simplify matters if there was an additional config API for the simple
> things.

The existing IPApi is quite simple already, as in minimal. Perhaps
what you really need is execfile?

> > Of course you can still put stuff in modules, and import them with ip.ex.
> I thought about that, yes.  But I wonder if it wouldn't be better to accompany
> each ip_profile_foo with an ipy_profile_foo_userspace which is automatically
> loaded?  Or - even better - add a special entrypoint in ipy_profile_foo.py
> for code automatically run in userspace.  Currently, the code is

ip.execfile should do that sufficiently well.

> Is .ipython in sys.path?  Apparently not.  I tried moving my code into an
> ipy_handy_utils.py and adding ip.ex("from ipy_handy_utils import *") to
> ipy_user_conf.py, but I am getting:
> > WARNING: Could not import user config!
> >  ('/home/meine/.ipython/ipy_user_conf.py' does not exist? Please run
> > '%upgrade')
> Seems to be a caught exception - obviously all ImportErrors are caught.
> AFAICS, this should be changed to check whether the failed import actually
> was ipy_user_conf itself.  I cannot check right now, because the
> ipython.scipy.org seems to be down right now.

.ipython should definitely be on sys.path. Gotta look into it later
when I have the time.

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


From hans_meine at gmx.net  Tue Aug 21 07:26:05 2007
From: hans_meine at gmx.net (Hans Meine)
Date: Tue, 21 Aug 2007 13:26:05 +0200
Subject: [IPython-dev] confirm_exit issue with scipy profile...
In-Reply-To: <200708211117.47915.hans_meine@gmx.net>
References: <46C4DF40.2000008@gmail.com>
	<46cb515a0708210017o56774c36p9259cea783747534@mail.gmail.com>
	<200708211117.47915.hans_meine@gmx.net>
Message-ID: <200708211326.05735.hans_meine@gmx.net>

[Sending this again due to wrong sender address (did not receive any error 
though)..  Thanks Ville for your answer, I am sorry that this mail did not 
make it to the list in time!]

Am Dienstag, 21. August 2007 11:17:47 schrieb Hans Meine:
> Is .ipython in sys.path?  Apparently not.  I tried moving my code into an
> ipy_handy_utils.py and adding ip.ex("from ipy_handy_utils import *") to
> ipy_user_conf.py, but I am getting:
> > WARNING: Could not import user config!

I have to correct myself - I did not actually save the ipy_handy_utils.py ;-/

So this is a viable solution for me - I can then call my modules 
ipy_profile_foo_userspace.py and import them with that name.

Now it's all a matter of nice, *simple* examples in the default installation.  
Recently (0.8.1), I still got mostly old examples:

-rw-r--r--  1 meine bvp  6582 May  4 22:01 ipy_profile_sh.py
-rw-r--r--  1 meine bvp  1279 May  4 22:01 ipy_user_conf.py
-rw-r--r--  1 meine bvp  1025 Aug 21 11:21 ipy_user_conf.pyc
-rw-r--r--  1 meine bvp 24168 Aug 21 11:21 ipythonrc
-rw-r--r--  1 meine bvp  1345 Aug 21 11:21 ipythonrc-math
-rw-r--r--  1 meine bvp  2138 Aug 21 11:21 ipythonrc-numeric
-rw-r--r--  1 meine bvp  1603 Aug 21 11:21 ipythonrc-physics
-rw-r--r--  1 meine bvp  3602 Aug 21 11:21 ipythonrc-pysh
-rw-r--r--  1 meine bvp  1266 Aug 21 11:21 ipythonrc-scipy
-rw-r--r--  1 meine bvp  1260 Aug 21 11:21 ipythonrc-tutorial

If these were converted to the new syntax, more people would probably use it.

Ciao, /  /
     /--/
    /  / ANS


From vivainio at gmail.com  Tue Aug 21 14:36:31 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 21 Aug 2007 20:36:31 +0200
Subject: [IPython-dev] %hist -t now default again (instead of raw history)
Message-ID: <46cb515a0708211136y5357a6d5se0d1e83bccdc9226@mail.gmail.com>

A heads up for svn users: the default history is again the translated
one. Raw history has a number of broken corner cases as far as
numbering goes, and I figured %hist -t is much more predictable, at
least for as long as we get the raw history fixed for good.

My current idea: abandon the idea of using raw history as a list, and use a dict
{
linenum, 'line contents',
linenum2, 'another line '
}

instead.

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


From gael.varoquaux at normalesup.org  Wed Aug 22 07:35:28 2007
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 22 Aug 2007 13:35:28 +0200
Subject: [IPython-dev] __file__ in a file executed by %run
Message-ID: <20070822113528.GC18548@clipper.ens.fr>

Hi,

Is there a reason why __file__ is not set to the absolute path of the
file ran, when running a file with %run. I am running 0.7.3 on the box I
have right now, so maybe this behavior has changed.

Cheers,

Ga?l


From gael.varoquaux at normalesup.org  Wed Aug 22 12:08:46 2007
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 22 Aug 2007 18:08:46 +0200
Subject: [IPython-dev] __file__ in a file executed by %run
In-Reply-To: <db6b5ecc0708220904t644ec760n3bdada6205ac267c@mail.gmail.com>
References: <20070822113528.GC18548@clipper.ens.fr>
	<db6b5ecc0708220904t644ec760n3bdada6205ac267c@mail.gmail.com>
Message-ID: <20070822160846.GE18548@clipper.ens.fr>

On Wed, Aug 22, 2007 at 10:04:54AM -0600, Fernando Perez wrote:
> > Is there a reason why __file__ is not set to the absolute path of the
> > file ran, when running a file with %run. I am running 0.7.3 on the box I
> > have right now, so maybe this behavior has changed.

> Yup, to conform to how python does it:

Good. Thanks (sorry, I don't want to install a non packaged version of
ipython on the lab's server, so I couldn't test).

Ga?l


From jorgen.stenarson at bostream.nu  Wed Aug 22 14:45:15 2007
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Wed, 22 Aug 2007 20:45:15 +0200
Subject: [IPython-dev] Doctest fixes, testing release out
In-Reply-To: <db6b5ecc0708121728q39296af9t4c239ae06d1e435f@mail.gmail.com>
References: <db6b5ecc0708121728q39296af9t4c239ae06d1e435f@mail.gmail.com>
Message-ID: <46CC843B.1010405@bostream.nu>

Fernando Perez skrev:
> Hi all,
> 
> over time, there have been repeated reports of doctest not working
> when running under IPython.  I think I finally fixed it deep enough
> that things should now work correctly in all cases, so that you can
> run any script or test suite that calls the various doctest testing
> runners, when inside ipython, and everything should just work.  If you
> are on SVN just update, or grab a testing release that I just made
> from current SVN here:
> 
> http://ipython.scipy.org/dist/testing/
> 
> I need these publicly available for a conference this week, and they
> wrap up all the recent fixes.  We'll start thinking about a release
> soon, but for now this will do.
> 

This sounds great, unfortunately I can't get it to work using svn r2653.

Is there some extra configuration necessary, like updating configuration 
files?

I have tried both on mac and win32 and get similar results, and the 
script works when running as python try_doctest.py

/J?rgen


I have the following testfile (try_doctest.py)
-------


import doctest

def a(x):
     """
     >>> a(10)
     11
     >>> a(31)
     32
     """
     return x+1


def _test():
     doctest.testmod()

if __name__=="__main__":
     _test()

-------
Resulting in the following ipython session:

C:\python\ipython>ipython
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)]
Type "copyright", "credits" or "license" for more information.

IPython 0.8.2.svn.r2647 -- 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]: %run try_doctest.py
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

C:\python\ipython\try_doctest.py
      15
      16 if __name__=="__main__":
---> 17     _test()
         _test = <function _test at 0x013DF0B0>
      18
      19

C:\python\ipython\try_doctest.py in _test()
      12
      13 def _test():
---> 14     doctest.testmod()
         global doctest.testmod = <function testmod at 0x01277FB0>
      15
      16 if __name__=="__main__":

c:\python24\lib\doctest.py in testmod(m=<IPython.FakeModule instance>, 
name=None, globs=None, verbose=None, isprivate=None, report=True, 
optionflags=0, extraglobs=None, raise_on_error=False, exclude_empty=False)
    1825     # Check that we were actually given a module.
    1826     if not inspect.ismodule(m):
-> 1827         raise TypeError("testmod: module required; %r" % (m,))
         global TypeError = undefined
         m = <IPython.FakeModule instance>
    1828
    1829     # If no name was given, then use the module's name.

TypeError: testmod: module required; <IPython.FakeModule instance>
WARNING: Failure executing file: <try_doctest.py>

In [2]:


From vivainio at gmail.com  Wed Aug 22 14:47:32 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 22 Aug 2007 20:47:32 +0200
Subject: [IPython-dev] Custom completer creation now extra easy
Message-ID: <46cb515a0708221147s184bae4eha6e97d89f87fdf87@mail.gmail.com>

Sometimes you just need a trivial completer, e.g. to "document" an api
of a magic function.

I added ipy_completers.quick_completer, the usage of which is just:

        [d:\ipython]|1> import ipy_completers
        [d:\ipython]|2> ipy_completers.quick_completer('foo',
['bar','baz'])
        [d:\ipython]|3> foo b<tab>
        bar baz
        [d:\ipython]|3> foo ba

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


From dd55 at cornell.edu  Thu Aug 23 12:52:20 2007
From: dd55 at cornell.edu (Darren Dale)
Date: Thu, 23 Aug 2007 12:52:20 -0400
Subject: [IPython-dev] problems with qt4 threading
Message-ID: <200708231252.20774.dd55@cornell.edu>

I recently reported a problem with ipython when using -q4thread, which showed 
up when I updated to qt-4.3 and PyQt-4.3. The original post didn't generate 
any interest, but the problem renders ipython unusable with qt4, so I wanted 
to post it once more. 

I made a little bit of progress with the attached patch, which silenced 
the "QSocketNotifier" messages. I can still make plots, interact with them, 
and close them. The patch can *not* be applied though, because a PyQt4 import 
appears outside of the class definitions.

I'll be away next week, I just needed to get this in print before I forget 
what I have learned today.

Darren

Here is the original post:
___
I recently updated to Qt-4.3 and PyQt-4.3. When I run "ipython -q4thread", I 
get a stream of error messages:

QSocketNotifier: Can only be used with threads started with QThread
QApplication::exec: Must be called from the main thread
QSocketNotifier: Can only be used with threads started with QThread
QApplication::exec: Must be called from the main thread
QSocketNotifier: Can only be used with threads started with QThread
QApplication::exec: Must be called from the main thread
...

I can interrupt IPython by hitting CTRL-D/Enter in rapid succession. If I run 
ipython -pylab with the qt4 backend enabled, I can still create plots and 
show windows, even with these warnings scrolling up the screen at a rate of 
10/second.

There is a page on threading in Qt4 here: 
http://doc.trolltech.com/4.3/threads.html

I'm sorry to say that after looking at the code for two hours, I don't have 
any suggestions on how to fix it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Qt4Threading.diff
Type: text/x-diff
Size: 2261 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070823/2148e03f/attachment.diff>

From fperez.net at gmail.com  Thu Aug 23 13:28:45 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 23 Aug 2007 11:28:45 -0600
Subject: [IPython-dev] problems with qt4 threading
In-Reply-To: <200708231252.20774.dd55@cornell.edu>
References: <200708231252.20774.dd55@cornell.edu>
Message-ID: <db6b5ecc0708231028q521e1e6y7a4062d5883f414f@mail.gmail.com>

Hi Darren,

On 8/23/07, Darren Dale <dd55 at cornell.edu> wrote:
> I recently reported a problem with ipython when using -q4thread, which showed
> up when I updated to qt-4.3 and PyQt-4.3. The original post didn't generate
> any interest, but the problem renders ipython unusable with qt4, so I wanted
> to post it once more.
>
> I made a little bit of progress with the attached patch, which silenced
> the "QSocketNotifier" messages. I can still make plots, interact with them,
> and close them. The patch can *not* be applied though, because a PyQt4 import
> appears outside of the class definitions.
>
> I'll be away next week, I just needed to get this in print before I forget
> what I have learned today.

thanks for the report, but I'm afraid that I have no idea either.  I
don't know the Qt APIs at all (in fact the Qt4 backend was contributed
by you :).  Since this one may linger for a while until we get a Qt
expert, it would be great if you could file it as a bug report on our
Trac:

http://projects.scipy.org/ipython/ipython

else we'll forget.

Sorry not to have a better answer, but without knowing the Qt API, I'm
not really sure where to start (and I don't have time at the moment
for an expedition inside Qt4, unfortunately).

Cheers,

f


From fperez.net at gmail.com  Thu Aug 23 14:34:50 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 23 Aug 2007 12:34:50 -0600
Subject: [IPython-dev] Doctest fixes, testing release out
In-Reply-To: <46CC843B.1010405@bostream.nu>
References: <db6b5ecc0708121728q39296af9t4c239ae06d1e435f@mail.gmail.com>
	<46CC843B.1010405@bostream.nu>
Message-ID: <db6b5ecc0708231134u32838c46rd51564039944e60b@mail.gmail.com>

On 8/22/07, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
> Fernando Perez skrev:
> > Hi all,
> >
> > over time, there have been repeated reports of doctest not working
> > when running under IPython.  I think I finally fixed it deep enough
> > that things should now work correctly in all cases, so that you can
> > run any script or test suite that calls the various doctest testing
> > runners, when inside ipython, and everything should just work.  If you
> > are on SVN just update, or grab a testing release that I just made
> > from current SVN here:
> >
> > http://ipython.scipy.org/dist/testing/
> >
> > I need these publicly available for a conference this week, and they
> > wrap up all the recent fixes.  We'll start thinking about a release
> > soon, but for now this will do.
> >
>
> This sounds great, unfortunately I can't get it to work using svn r2653.
>
> Is there some extra configuration necessary, like updating configuration
> files?

No, it should just work.  I'm a bit swamped right now, but I'll look
into it as soon as I can.  I want all doctest functionality to really
'just work', no fuss.


Cheers,

f


From jorgen.stenarson at bostream.nu  Thu Aug 23 17:29:47 2007
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Thu, 23 Aug 2007 23:29:47 +0200
Subject: [IPython-dev] Doctest fixes, testing release out
In-Reply-To: <db6b5ecc0708231134u32838c46rd51564039944e60b@mail.gmail.com>
References: <db6b5ecc0708121728q39296af9t4c239ae06d1e435f@mail.gmail.com>	
	<46CC843B.1010405@bostream.nu>
	<db6b5ecc0708231134u32838c46rd51564039944e60b@mail.gmail.com>
Message-ID: <46CDFC4B.30205@bostream.nu>

Fernando Perez skrev:
> On 8/22/07, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
>> Fernando Perez skrev:
>>> Hi all,
>>>
>>> over time, there have been repeated reports of doctest not working
>>> when running under IPython.  I think I finally fixed it deep enough
>>> that things should now work correctly in all cases, so that you can
>>> run any script or test suite that calls the various doctest testing
>>> runners, when inside ipython, and everything should just work.  If you
>>> are on SVN just update, or grab a testing release that I just made
>>> from current SVN here:
>>>
>>> http://ipython.scipy.org/dist/testing/
>>>
>>> I need these publicly available for a conference this week, and they
>>> wrap up all the recent fixes.  We'll start thinking about a release
>>> soon, but for now this will do.
>>>
>> This sounds great, unfortunately I can't get it to work using svn r2653.
>>
>> Is there some extra configuration necessary, like updating configuration
>> files?
> 
> No, it should just work.  I'm a bit swamped right now, but I'll look
> into it as soon as I can.  I want all doctest functionality to really
> 'just work', no fuss.
> 
> 
> Cheers,
> 
> f
> 
When you get around to it let me know if you need me to do some tests on 
my end to figure this out.

/J?rgen


From arne at ras.ucalgary.ca  Thu Aug 23 18:21:56 2007
From: arne at ras.ucalgary.ca (Arne Grimstrup)
Date: Thu, 23 Aug 2007 16:21:56 -0600
Subject: [IPython-dev] Syntax and Indentation Errors during build of
	ipython1 (saw)
Message-ID: <46CE0884.9040309@ras.ucalgary.ca>

Hi everyone,

I checked out ipython1 yesterday and was attempting to build it for the first 
time today.  Near the end of the build, the following errors appeared:

Processing ipython1-0.9alpha2-py2.5.egg
creating 
/alma/ACS-7.0/Python/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg
Extracting ipython1-0.9alpha2-py2.5.egg to 
/alma/ACS-7.0/Python/lib/python2.5/site-packages
   File 
"/alma/ACS-7.0/Python/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/core1/console.py", 
line 6
     self.in
           ^
SyntaxError: invalid syntax

Sorry: IndentationError: ('expected an indented block', 
('/alma/ACS-7.0/Python/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/core1/interprete
rinterface.py', 46, 7, '    def ipsystem(self,arg_s):\n'))

The build is on RHEL 4 using a separately built Python 2.5.1 and Setuptools
0.6c6.

I understand that the core1 modules are under heavy development right now,
but I'm hoping to include ipython1 in the tool suite for our application.
In the meantime, should I revert to chainsaw?

Thanks,

Arne


From fperez.net at gmail.com  Thu Aug 23 18:43:30 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 23 Aug 2007 16:43:30 -0600
Subject: [IPython-dev] Syntax and Indentation Errors during build of
	ipython1 (saw)
In-Reply-To: <46CE0884.9040309@ras.ucalgary.ca>
References: <46CE0884.9040309@ras.ucalgary.ca>
Message-ID: <db6b5ecc0708231543h19d99650gaaf54ca5ee233660@mail.gmail.com>

On 8/23/07, Arne Grimstrup <arne at ras.ucalgary.ca> wrote:
> Hi everyone,
>
> I checked out ipython1 yesterday and was attempting to build it for the first
> time today.  Near the end of the build, the following errors appeared:
>
> Processing ipython1-0.9alpha2-py2.5.egg
> creating
> /alma/ACS-7.0/Python/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg
> Extracting ipython1-0.9alpha2-py2.5.egg to
> /alma/ACS-7.0/Python/lib/python2.5/site-packages
>    File
> "/alma/ACS-7.0/Python/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/core1/console.py",
> line 6
>      self.in
>            ^
> SyntaxError: invalid syntax
>
> Sorry: IndentationError: ('expected an indented block',
> ('/alma/ACS-7.0/Python/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/core1/interprete
> rinterface.py', 46, 7, '    def ipsystem(self,arg_s):\n'))
>
> The build is on RHEL 4 using a separately built Python 2.5.1 and Setuptools
> 0.6c6.
>
> I understand that the core1 modules are under heavy development right now,
> but I'm hoping to include ipython1 in the tool suite for our application.
> In the meantime, should I revert to chainsaw?

Not, just update SVN and try again please.  Indeed the core1 stuff is
completely off-limits for users, but I hadn't realized I'd left a
stray non-compiling file in there.  Sorry about that.

You should be OK with saw, since I won't move any of the new work into
core/ until I'm 100% sure that it passes all tests and provides all
the old functionality.

So stick with saw, and yell at me when it breaks.  I'll listen :)

Cheers,

f


From ndg.disc at gmail.com  Fri Aug 24 04:17:41 2007
From: ndg.disc at gmail.com (nom de guerre)
Date: Fri, 24 Aug 2007 10:17:41 +0200
Subject: [IPython-dev] problems with -qt4
Message-ID: <b0fcc3630708240117s656cedb6wdacdc7831f46c02b@mail.gmail.com>

i have similar problem as Darren:

after updating to Qt-4.3 and PyQt-4.3. When I run "ipython -q4thread", I
get a stream of error messages:

QSocketNotifier: Can only be used with threads started with QThread
QApplication::exec: Must be called from the main thread
QSocketNotifier: Can only be used with threads started with QThread
QApplication::exec: Must be called from the main thread
QSocketNotifier: Can only be used with threads started with QThread
QApplication::exec: Must be called from the main thread
...

i tried to do sth. with this but it seems i lost the afternoon..

anyhow the problem comes from:
shell.py

class IPShellQt4(IPThread):
  mainloop(..):
    while True:
    ...
    QtGui.qApp.exec_() # this gives the messages

i tried hard, but
i was unable to understand the good order of creating the qt thread
application. in my opinion the one used in ipython is ok. (while comparing
with
tutorials). but i bet sth. was changed and undocumented.. so i see two
possible solutions: someone will try to suspend displaying of this
message ;] (i
have no idea if it's
possible) or someone with broader knowlage will go into pyqt or even
qt to check if it is a bug. if it is -- we may ask to correct it -- if
not maybe IPShellQt4 can be changed to walk it around.

thank you all for all help (in
advance) and developers of IPython for really nice shell. please don't
leave the problem as is.. ;]


bests,
szymon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070824/ee22e7d4/attachment.html>

From gael.varoquaux at normalesup.org  Fri Aug 24 04:21:39 2007
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Fri, 24 Aug 2007 10:21:39 +0200
Subject: [IPython-dev] problems with -qt4
In-Reply-To: <b0fcc3630708240117s656cedb6wdacdc7831f46c02b@mail.gmail.com>
References: <b0fcc3630708240117s656cedb6wdacdc7831f46c02b@mail.gmail.com>
Message-ID: <20070824082139.GC11989@clipper.ens.fr>

On Fri, Aug 24, 2007 at 10:17:41AM +0200, nom de guerre wrote:
>    thank you all for all help (in
>    advance) and developers of IPython for really nice shell. please don't leave the problem as is.. ;]

The problem is that IPython developers don't use QT4 and don't know the
API. They therefore cannot fix the problem. It might be nice to have
someone who knows PyQT well to have a look at that, maybe together with
someone who knows IPython well.

My 2 cents,

Ga??l


From hans_meine at gmx.net  Fri Aug 24 07:09:00 2007
From: hans_meine at gmx.net (Hans Meine)
Date: Fri, 24 Aug 2007 13:09:00 +0200
Subject: [IPython-dev] problems with qt4 threading
In-Reply-To: <200708231252.20774.dd55@cornell.edu>
References: <200708231252.20774.dd55@cornell.edu>
Message-ID: <200708241309.00683.hans_meine@gmx.net>

Hi!

Am Donnerstag, 23. August 2007 18:52:20 schrieb Darren Dale:
> I recently reported a problem with ipython when using -q4thread, which
> showed up when I updated to qt-4.3 and PyQt-4.3. The original post didn't
> generate any interest, but the problem renders ipython unusable with qt4,
> so I wanted to post it once more.

Reading the error message:
> QSocketNotifier: Can only be used with threads started with QThread
I would suggest to use the Qt API for creating the thread, and..

> I made a little bit of progress with the attached patch, which silenced
> the "QSocketNotifier" messages.
..reading your patch, this is what it does.  So this is the way to go AFAICS.

> I can still make plots, interact with them, 
> and close them. The patch can *not* be applied though, because a PyQt4
> import appears outside of the class definitions.

Right, so this is the only thing that needs to be fixed.  It is not trivial to 
do, since the current code needs to know the base class (which should be 
different for the Qt4 IPShell) before the IPShell being used is known.

Apart from that, I wonder why you moved the two code lines that start the 
timer?

Ciao, /  /
     /--/
    /  / ANS


From dd55 at cornell.edu  Fri Aug 24 08:22:04 2007
From: dd55 at cornell.edu (Darren Dale)
Date: Fri, 24 Aug 2007 08:22:04 -0400
Subject: [IPython-dev] problems with qt4 threading
Message-ID: <200708240822.05256.dd55@cornell.edu>

[Sorry for not replying in-thread. I'm having problems with my mail client 
losing messages from IPython and Numpy]

> Am Donnerstag, 23. August 2007 18:52:20 schrieb Darren Dale:
> > I can still make plots, interact with them,
> > and close them. The patch can *not* be applied though, because a PyQt4
> > import appears outside of the class definitions.
>
> Right, so this is the only thing that needs to be fixed.  It is not trivial
> to do, since the current code needs to know the base class (which should be
> different for the Qt4 IPShell) before the IPShell being used is known.
>
> Apart from that, I wonder why you moved the two code lines that start the
> timer?

It was not important. I dont have much experience with threading, I just 
wanted to test starting the timer before starting the thread, to see what 
affect it would have.

Darren


From dd55 at cornell.edu  Fri Aug 24 08:32:15 2007
From: dd55 at cornell.edu (Darren Dale)
Date: Fri, 24 Aug 2007 08:32:15 -0400
Subject: [IPython-dev] problems with -qt4
Message-ID: <200708240832.15228.dd55@cornell.edu>


Gael wrote:
> On Fri, Aug 24, 2007 at 10:17:41AM +0200, nom de guerre wrote:
> >    thank you all for all help (in
> >    advance) and developers of IPython for really nice shell. please don't
> > leave the problem as is.. ;]
>
> The problem is that IPython developers don't use QT4 and don't know the
> API. They therefore cannot fix the problem. It might be nice to have
> someone who knows PyQT well to have a look at that, maybe together with
> someone who knows IPython well.

I know the ipython devs are not qt experts, and shouldnt be expected to solve 
this. However, the qt4 features in ipython and mpl have been used by John and 
Fernando for tutorials. My main concern with posting is to raise awareness, I 
wouldn't feel to good if someone got surprised by this behavior in front of a 
group of people.

Darren


From arne at ras.ucalgary.ca  Fri Aug 24 12:24:09 2007
From: arne at ras.ucalgary.ca (Arne Grimstrup)
Date: Fri, 24 Aug 2007 10:24:09 -0600
Subject: [IPython-dev] Syntax and Indentation Errors during build of
 ipython1 (saw)
In-Reply-To: <db6b5ecc0708231543h19d99650gaaf54ca5ee233660@mail.gmail.com>
References: <46CE0884.9040309@ras.ucalgary.ca>
	<db6b5ecc0708231543h19d99650gaaf54ca5ee233660@mail.gmail.com>
Message-ID: <46CF0629.9070301@ras.ucalgary.ca>

Hi Fernando,

Fernando Perez wrote:
[Reverting to chainsaw]
> Not, just update SVN and try again please.  Indeed the core1 stuff is
> completely off-limits for users, but I hadn't realized I'd left a
> stray non-compiling file in there.  Sorry about that.
> 
> You should be OK with saw, since I won't move any of the new work into
> core/ until I'm 100% sure that it passes all tests and provides all
> the old functionality.
> 
> So stick with saw, and yell at me when it breaks.  I'll listen :)
> 
> Cheers,
> 
> f

I tried again this morning and here is what I got:

Extracting ipython1-0.9alpha2-py2.5.egg to 
/alma/ACS-7.0/Python/lib/python2.5/site-packages
Sorry: IndentationError: ('expected an indented block', 
('/alma/ACS-7.0/Python/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/core1/interpreterinterface.py', 
46, 7, '    def ipsystem(self,arg_s):\n'))

Adding either 'pass' or an empty docstring to all of the
functions removed the error.

Hope this helps,

Arne


From ellisonbg.net at gmail.com  Fri Aug 24 13:05:45 2007
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Fri, 24 Aug 2007 11:05:45 -0600
Subject: [IPython-dev] Syntax and Indentation Errors during build of
	ipython1 (saw)
In-Reply-To: <46CF0629.9070301@ras.ucalgary.ca>
References: <46CE0884.9040309@ras.ucalgary.ca>
	<db6b5ecc0708231543h19d99650gaaf54ca5ee233660@mail.gmail.com>
	<46CF0629.9070301@ras.ucalgary.ca>
Message-ID: <6ce0ac130708241005g354831e0td926c3bf9d3bedf5@mail.gmail.com>

I fixed a few more syntax bug in saw/core1.  Sorry about this.  As
Fernando said, core1 is sort of a mini developer branch embedded
inside saw.  The rest of saw should be very stable at this point - we
just need to make sure that we don't have these types of show stoppers
in core1.  Can you give saw (svn up), try again and let us know how it
goes?

Thanks

Brian

On 8/24/07, Arne Grimstrup <arne at ras.ucalgary.ca> wrote:
> Hi Fernando,
>
> Fernando Perez wrote:
> [Reverting to chainsaw]
> > Not, just update SVN and try again please.  Indeed the core1 stuff is
> > completely off-limits for users, but I hadn't realized I'd left a
> > stray non-compiling file in there.  Sorry about that.
> >
> > You should be OK with saw, since I won't move any of the new work into
> > core/ until I'm 100% sure that it passes all tests and provides all
> > the old functionality.
> >
> > So stick with saw, and yell at me when it breaks.  I'll listen :)
> >
> > Cheers,
> >
> > f
>
> I tried again this morning and here is what I got:
>
> Extracting ipython1-0.9alpha2-py2.5.egg to
> /alma/ACS-7.0/Python/lib/python2.5/site-packages
> Sorry: IndentationError: ('expected an indented block',
> ('/alma/ACS-7.0/Python/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/core1/interpreterinterface.py',
> 46, 7, '    def ipsystem(self,arg_s):\n'))
>
> Adding either 'pass' or an empty docstring to all of the
> functions removed the error.
>
> Hope this helps,
>
> Arne
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Fri Aug 24 13:09:27 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 24 Aug 2007 11:09:27 -0600
Subject: [IPython-dev] Syntax and Indentation Errors during build of
	ipython1 (saw)
In-Reply-To: <6ce0ac130708241005g354831e0td926c3bf9d3bedf5@mail.gmail.com>
References: <46CE0884.9040309@ras.ucalgary.ca>
	<db6b5ecc0708231543h19d99650gaaf54ca5ee233660@mail.gmail.com>
	<46CF0629.9070301@ras.ucalgary.ca>
	<6ce0ac130708241005g354831e0td926c3bf9d3bedf5@mail.gmail.com>
Message-ID: <db6b5ecc0708241009q46071ea4p37886a88a48ccd8@mail.gmail.com>

On 8/24/07, Brian Granger <ellisonbg.net at gmail.com> wrote:
> I fixed a few more syntax bug in saw/core1.  Sorry about this.  As
> Fernando said, core1 is sort of a mini developer branch embedded
> inside saw.  The rest of saw should be very stable at this point - we
> just need to make sure that we don't have these types of show stoppers
> in core1.  Can you give saw (svn up), try again and let us know how it
> goes?

Thanks for pitching in, Brian.  I'll add a compile script to the core1
dir to make sure that we don't commit code that doesn't compile, to
avoid tripping installation.  Since I work directly off the
development directory, I hadn't noticed this.

Sorry again for the hassle, Arne.

Cheers,

f


From arne at ras.ucalgary.ca  Fri Aug 24 13:21:08 2007
From: arne at ras.ucalgary.ca (Arne Grimstrup)
Date: Fri, 24 Aug 2007 11:21:08 -0600
Subject: [IPython-dev] Syntax and Indentation Errors during build of
 ipython1 (saw)
In-Reply-To: <db6b5ecc0708241009q46071ea4p37886a88a48ccd8@mail.gmail.com>
References: <46CE0884.9040309@ras.ucalgary.ca>	
	<db6b5ecc0708231543h19d99650gaaf54ca5ee233660@mail.gmail.com>	
	<46CF0629.9070301@ras.ucalgary.ca>	
	<6ce0ac130708241005g354831e0td926c3bf9d3bedf5@mail.gmail.com>
	<db6b5ecc0708241009q46071ea4p37886a88a48ccd8@mail.gmail.com>
Message-ID: <46CF1384.8000003@ras.ucalgary.ca>

Hi Brian and Fernando,

Fernando Perez wrote:
> On 8/24/07, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> I fixed a few more syntax bug in saw/core1.  Sorry about this.  As
>> Fernando said, core1 is sort of a mini developer branch embedded
>> inside saw.  The rest of saw should be very stable at this point - we
>> just need to make sure that we don't have these types of show stoppers
>> in core1.  Can you give saw (svn up), try again and let us know how it
>> goes?

The latest update compiled and installed cleanly.  Thanks for making the
fix so quickly.

> Thanks for pitching in, Brian.  I'll add a compile script to the core1
> dir to make sure that we don't commit code that doesn't compile, to
> avoid tripping installation.  Since I work directly off the
> development directory, I hadn't noticed this.
> 
> Sorry again for the hassle, Arne.
> 
> Cheers,
> 
> f

No problem, guys.  I'm just trying to be a helpful user.

Regards,

Arne


From arne at ras.ucalgary.ca  Fri Aug 24 14:25:55 2007
From: arne at ras.ucalgary.ca (Arne Grimstrup)
Date: Fri, 24 Aug 2007 12:25:55 -0600
Subject: [IPython-dev] Undocumented Dependency on SQLAlchemy?
Message-ID: <46CF22B3.5080104@ras.ucalgary.ca>

Hi everyone,

I ran the test suite for ipython1 and got the following report:

[ERROR]: ipython1.test.test_notebook

Traceback (most recent call last):
   File 
"/alma/ACS-7.0/Python/lib/python2.5/site-packages/twisted/trial/runner.py", line 
555, in loadPackage
     module = modinfo.load()
   File 
"/alma/ACS-7.0/Python/lib/python2.5/site-packages/twisted/python/modules.py", 
line 386, in load
     return self.pathEntry.pythonPath.moduleLoader(self.name)
   File 
"/alma/ACS-7.0/Python/lib/python2.5/site-packages/twisted/python/modules.py", 
line 621, in moduleLoader
     return self._moduleLoader(modname)
   File 
"/alma/ACS-7.0/Python/lib/python2.5/site-packages/twisted/python/reflect.py", 
line 357, in namedAny
     topLevelPackage = __import__(trialname)
   File 
"/alma/BUILDAREA/ACS/ExtProd/PRODUCTS/ipython1-saw/ipython1/test/test_notebook.py", 
line 22, in <module>
     from ipython1.notebook import notebook, dbutil, xmlutil
   File 
"/alma/BUILDAREA/ACS/ExtProd/PRODUCTS/ipython1-saw/ipython1/notebook/notebook.py", 
line 20, in <module>
     import sqlalchemy as sqla
exceptions.ImportError: No module named sqlalchemy
-------------------------------------------------------------------------------
Ran 116 tests in 7.629s

FAILED (errors=1, successes=116)

I reviewed the INSTALL and README files and didn't find any reference to
SQLAlchemy being a requirement, like Zope/Twisted.  A search of the
website (http://iptyon.scipy.org) also came up empty.  Is there somewhere
else I should look for this information?

Regards,

Arne


From fperez.net at gmail.com  Fri Aug 24 17:33:36 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 24 Aug 2007 15:33:36 -0600
Subject: [IPython-dev] Undocumented Dependency on SQLAlchemy?
In-Reply-To: <46CF22B3.5080104@ras.ucalgary.ca>
References: <46CF22B3.5080104@ras.ucalgary.ca>
Message-ID: <db6b5ecc0708241433x1debd560o45b9a093835b7668@mail.gmail.com>

Hi Arne,

On 8/24/07, Arne Grimstrup <arne at ras.ucalgary.ca> wrote:
> Hi everyone,
>
> I ran the test suite for ipython1 and got the following report:
>
> [ERROR]: ipython1.test.test_notebook
>
> Traceback (most recent call last):
>    File
> "/alma/ACS-7.0/Python/lib/python2.5/site-packages/twisted/trial/runner.py", line
> 555, in loadPackage
>      module = modinfo.load()
>    File
> "/alma/ACS-7.0/Python/lib/python2.5/site-packages/twisted/python/modules.py",
> line 386, in load
>      return self.pathEntry.pythonPath.moduleLoader(self.name)
>    File
> "/alma/ACS-7.0/Python/lib/python2.5/site-packages/twisted/python/modules.py",
> line 621, in moduleLoader
>      return self._moduleLoader(modname)
>    File
> "/alma/ACS-7.0/Python/lib/python2.5/site-packages/twisted/python/reflect.py",
> line 357, in namedAny
>      topLevelPackage = __import__(trialname)
>    File
> "/alma/BUILDAREA/ACS/ExtProd/PRODUCTS/ipython1-saw/ipython1/test/test_notebook.py",
> line 22, in <module>
>      from ipython1.notebook import notebook, dbutil, xmlutil
>    File
> "/alma/BUILDAREA/ACS/ExtProd/PRODUCTS/ipython1-saw/ipython1/notebook/notebook.py",
> line 20, in <module>
>      import sqlalchemy as sqla
> exceptions.ImportError: No module named sqlalchemy
> -------------------------------------------------------------------------------
> Ran 116 tests in 7.629s
>
> FAILED (errors=1, successes=116)
>
> I reviewed the INSTALL and README files and didn't find any reference to
> SQLAlchemy being a requirement, like Zope/Twisted.  A search of the
> website (http://iptyon.scipy.org) also came up empty.  Is there somewhere
> else I should look for this information?

The two areas that are 'hard hat only' are core1/frontend and
notebook, and you've hit problems on both :)  You can safely ignore
all errors on them, but we should find a solution to make the notebook
tests optional, so they just get skipped or pass silently if
SQLALCHEMY is not installed.

So for now just ignore them, and we'll hide the dependency soon.  When
that stuff gets ready for release we'll revisit the issue, but since
right now you can't really even use the code yet, there's no point in
spending any time on getting SQLAlchemy at all.

Thanks for your patience and detailed reports though, we greatly
appreciate them.

Cheers,

f


From arne at ras.ucalgary.ca  Fri Aug 24 18:15:23 2007
From: arne at ras.ucalgary.ca (Arne Grimstrup)
Date: Fri, 24 Aug 2007 16:15:23 -0600
Subject: [IPython-dev] Undocumented Dependency on SQLAlchemy?
In-Reply-To: <db6b5ecc0708241433x1debd560o45b9a093835b7668@mail.gmail.com>
References: <46CF22B3.5080104@ras.ucalgary.ca>
	<db6b5ecc0708241433x1debd560o45b9a093835b7668@mail.gmail.com>
Message-ID: <46CF587B.7030805@ras.ucalgary.ca>

Hi Brian and Fernando,

Fernando Perez wrote:
> Hi Arne,
> 
[Error report deleted]
> 
> The two areas that are 'hard hat only' are core1/frontend and
> notebook, and you've hit problems on both :)  You can safely ignore
> all errors on them, but we should find a solution to make the notebook
> tests optional, so they just get skipped or pass silently if
> SQLALCHEMY is not installed.

I find the bugs so others don't have to. :-)  Brian mentioned earlier
that pexpect is also used in these areas, but I have that installed so
the error didn't manifest itself.

> So for now just ignore them, and we'll hide the dependency soon.  When
> that stuff gets ready for release we'll revisit the issue, but since
> right now you can't really even use the code yet, there's no point in
> spending any time on getting SQLAlchemy at all.
> 
> Thanks for your patience and detailed reports though, we greatly
> appreciate them.
> 
> Cheers,
> 
> f

Just another (minor) contribution on my part.  Thanks very much for
the quick responses!

Regards,

Arne


From dfj225 at gmail.com  Mon Aug 27 10:16:59 2007
From: dfj225 at gmail.com (Doug Jones)
Date: Mon, 27 Aug 2007 10:16:59 -0400
Subject: [IPython-dev] ipython1 saw exception transport and raising
In-Reply-To: <db6b5ecc0708150043u39d2201byca071a5ba359868b@mail.gmail.com>
References: <1315be7e0707090759u6bedef93nea0d65e87fe2536@mail.gmail.com>
	<6ce0ac130707121951l1a5e4c8bt6d7b1e4fcc656dfc@mail.gmail.com>
	<1315be7e0707161058i6f958cb5sc8188928c3aad433@mail.gmail.com>
	<db6b5ecc0708150043u39d2201byca071a5ba359868b@mail.gmail.com>
Message-ID: <1315be7e0708270716w2779849biddbe1ac2d2e45bec@mail.gmail.com>

Fernando,

First, sorry that it has taken me so long to respond.

Second, I have updated my ipython1 source and the behavior on my end
seems to be correct as well. I am testing with exceptions generated
from Boost.Python and now all information associated with the
exceptions seems to be displayed, including the correct traceback on
the engine.

Thank you,
~Doug

On 8/15/07, Fernando Perez <fperez.net at gmail.com> wrote:
> On 7/16/07, Doug Jones <dfj225 at gmail.com> wrote:
>
> > As you see, some of the information that is part of the ArgumentError
> > is either not transported or not displayed. Unlike last time, I don't
> > really have any ideas as to why.
>
> OK, I think I got it finally... Please svn up and let us know.  Here's
> what I'm getting for simple tests:
>
> ZeroDivisionError: integer division or modulo by zero
> ***************************************************************************
> Exception in the IPython Engine.
>
> Engine action that caused the error:
>
> engine: 0
> method: execute(lines)
> lines =
> import os
> os.chdir('/home/fperez/ipython/test/ip1')
> import err
> err.bad()
> #abd snytxx
>
>
> Full traceback:
> ---------------------------------------------------------------------------
> ZeroDivisionError                         Traceback (most recent call last)
>
> /home/fperez/ipython/test/ip1/<string> in <module>()
>
> /home/fperez/ipython/test/ip1/err.py in bad()
>      14
>      15 def bad():
> ---> 16     1/0
>      17
>      18 #bad()
>
> ZeroDivisionError: integer division or modulo by zero
> ***************************************************************************
>
> WARNING: Failure executing file: <tst.py>
>
>
> Syntax errors are reported with a clumsy traceback:
>
> SyntaxError: invalid syntax (line 5)
> ***************************************************************************
> Exception in the IPython Engine.
>
> Engine action that caused the error:
>
> engine: 0
> method: execute(lines)
> lines =
> import os
> os.chdir('/home/fperez/ipython/test/ip1')
> import err
> err.bad()
> abd snytxx
>
>
> Full traceback:
> ---------------------------------------------------------------------------
> SyntaxError                               Traceback (most recent call last)
>
> /home/fperez/usr/lib/python2.5/site-packages/ipython1/core/interpreter.py
> in split_commands(self, python)
>     511         # Uncomment to help debug the ast tree
>     512         # for n in ast.node:
> --> 513         #     print n.lineno,'->',n
>     514
>     515         # Each separate command is available by iterating over
> ast.node. The
>
> /home/fperez/ipython/test/ip1/compiler/transformer.py in parse(buf, mode)
>      50
>      51
> ---> 52
>      53
>      54
>
> /home/fperez/ipython/test/ip1/compiler/transformer.py in parsesuite(self, text)
>     127
>     128
> --> 129
>     130
>     131
>
> SyntaxError: invalid syntax (line 5)
> ***************************************************************************
>
>
> WARNING: Failure executing file: <tst.py>
>
>
> But the info is really  all there.   It's just that managing traceback
> formatting across the network in this way is not particularly easy,
> and I'm a bit too fried now to do more...
>
> But at least now we are getting all the necessary info across, even if
> for syntax errors the report isn't the nicest.
>
> Cheers,
>
> f
>


From fperez.net at gmail.com  Mon Aug 27 12:23:44 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 27 Aug 2007 10:23:44 -0600
Subject: [IPython-dev] ipython1 saw exception transport and raising
In-Reply-To: <1315be7e0708270716w2779849biddbe1ac2d2e45bec@mail.gmail.com>
References: <1315be7e0707090759u6bedef93nea0d65e87fe2536@mail.gmail.com>
	<6ce0ac130707121951l1a5e4c8bt6d7b1e4fcc656dfc@mail.gmail.com>
	<1315be7e0707161058i6f958cb5sc8188928c3aad433@mail.gmail.com>
	<db6b5ecc0708150043u39d2201byca071a5ba359868b@mail.gmail.com>
	<1315be7e0708270716w2779849biddbe1ac2d2e45bec@mail.gmail.com>
Message-ID: <db6b5ecc0708270923o2548d120rcf6165c25c7e3604@mail.gmail.com>

On 8/27/07, Doug Jones <dfj225 at gmail.com> wrote:
> Fernando,
>
> First, sorry that it has taken me so long to respond.
>
> Second, I have updated my ipython1 source and the behavior on my end
> seems to be correct as well. I am testing with exceptions generated
> from Boost.Python and now all information associated with the
> exceptions seems to be displayed, including the correct traceback on
> the engine.

Great, glad we got this one.  Let us know of any other issues you may see.

Cheers,

f


From vivainio at gmail.com  Tue Aug 28 12:00:09 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 28 Aug 2007 18:00:09 +0200
Subject: [IPython-dev] Preparing for 0.8.2 release
Message-ID: <46cb515a0708280900r2df89f0axdf9097ebb734d739@mail.gmail.com>

I guess this could be opportune time to start preparing for 0.8.2;
there are no serious bugs that I know of.

Is all the doctest stuff in shape for the release? Does anyone have
anything that should go in?

There's a win32 installer for your testing pleasure at
http://vivainio.googlepages.com/ipython-0.8.2.svn.r2680.win32.exe

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


From vivainio at gmail.com  Tue Aug 28 15:12:32 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 28 Aug 2007 21:12:32 +0200
Subject: [IPython-dev] pyreadline gets confused when a 'returned' process
	prints
Message-ID: <46cb515a0708281212r631478a1tfe6200ee89e2fcf8@mail.gmail.com>

There are some programs that fork to background but keep on printing
to the terminal after returning control to ipython. They are some
proprietary programs I use at work.

This confuses pyreadline, which probably thinks cursor is where it was
the last time it checked (unless changed by itself). pyreadline should
probably check the "real" situation without assuming anything.

I do not know whether this is easy to fix or reproduce. This is just a heads-up.

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


From vivainio at gmail.com  Tue Aug 28 16:16:18 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 28 Aug 2007 22:16:18 +0200
Subject: [IPython-dev] Remove copyright statement?
Message-ID: <46cb515a0708281316m50333bffs4be075ec11d1e6bf@mail.gmail.com>

It's bike shed time!

Default IPython banner is now:

----------
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)]
Type "copyright", "credits" or "license" for more information.

IPython 0.8.2.svn.r2680 -- An enhanced Interactive Python.
? or %quickref -> Introduction to IPython's features, or quick reference.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
----------

(Yes, I just added %quickref there).

Now, would it make sense to remove the line with:

'Type "copyright", "credits" or "license" for more information.'

These days, when open source is such an "obvious" thing, it feels a
bit GNU/RMS and takes up space. And probably means nothing
juridically, anyway.

I don't care much personally, I use the sh profile with the minimal banner:

----
d:\ipython>python IPython.py -p sh
IPython 0.8.2.svn.r2680   [on Py 2.5.1]
[d:/ipython]|1>
-----

but this could be an aesthetic win for the users of default profile. I
could also combine the ipython and python version on the same line as
is done in sh profile.

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


From fperez.net at gmail.com  Tue Aug 28 16:38:49 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 28 Aug 2007 14:38:49 -0600
Subject: [IPython-dev] Preparing for 0.8.2 release
In-Reply-To: <46cb515a0708280900r2df89f0axdf9097ebb734d739@mail.gmail.com>
References: <46cb515a0708280900r2df89f0axdf9097ebb734d739@mail.gmail.com>
Message-ID: <db6b5ecc0708281338l7e7e7a9cpd66d2bbf113c47a@mail.gmail.com>

On 8/28/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> I guess this could be opportune time to start preparing for 0.8.2;
> there are no serious bugs that I know of.
>
> Is all the doctest stuff in shape for the release? Does anyone have
> anything that should go in?

No, I'll probably get to it this weekend, so let's shoot for sometime
next week for release.

Note: I'll be reverting the deprecation of some of the %pdef &
friends.   There are several tutorials out on the net, widely used in
scientific computing circles, that list these and they do get used.  A
minor point release is not a time for any API breakage of this kind.
We'll have a chance for a deep cleanup with the 0.9 series, which
thanks to the great help from Eric Jones and Gael Varoquaux at scipy
is now starting to take shape.  There, *everything* will be fair game
for deprecation/cleanup, but there's really no value in breaking
people's work habits right now.

Cheers,

f


From ellisonbg.net at gmail.com  Tue Aug 28 16:48:08 2007
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 28 Aug 2007 14:48:08 -0600
Subject: [IPython-dev] Remove copyright statement?
In-Reply-To: <46cb515a0708281316m50333bffs4be075ec11d1e6bf@mail.gmail.com>
References: <46cb515a0708281316m50333bffs4be075ec11d1e6bf@mail.gmail.com>
Message-ID: <6ce0ac130708281348v74214551v431756144f5b7235@mail.gmail.com>

I am fine with the addition of quickref, but I would prefer to keep
the "->"s aligned.  To do this we might want to put the ? and
%quickref on different lines.  This makes it more readable.

Brian

On 8/28/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> It's bike shed time!
>
> Default IPython banner is now:
>
> ----------
> Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)]
> Type "copyright", "credits" or "license" for more information.
>
> IPython 0.8.2.svn.r2680 -- An enhanced Interactive Python.
> ? or %quickref -> Introduction to IPython's features, or quick reference.
> %magic  -> Information about IPython's 'magic' % functions.
> help    -> Python's own help system.
> object? -> Details about 'object'. ?object also works, ?? prints more.
> ----------
>
> (Yes, I just added %quickref there).
>
> Now, would it make sense to remove the line with:
>
> 'Type "copyright", "credits" or "license" for more information.'
>
> These days, when open source is such an "obvious" thing, it feels a
> bit GNU/RMS and takes up space. And probably means nothing
> juridically, anyway.
>
> I don't care much personally, I use the sh profile with the minimal banner:
>
> ----
> d:\ipython>python IPython.py -p sh
> IPython 0.8.2.svn.r2680   [on Py 2.5.1]
> [d:/ipython]|1>
> -----
>
> but this could be an aesthetic win for the users of default profile. I
> could also combine the ipython and python version on the same line as
> is done in sh profile.
>
> --
> Ville M. Vainio - vivainio.googlepages.com
> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From vivainio at gmail.com  Tue Aug 28 17:23:17 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 28 Aug 2007 23:23:17 +0200
Subject: [IPython-dev] Preparing for 0.8.2 release
In-Reply-To: <db6b5ecc0708281338l7e7e7a9cpd66d2bbf113c47a@mail.gmail.com>
References: <46cb515a0708280900r2df89f0axdf9097ebb734d739@mail.gmail.com>
	<db6b5ecc0708281338l7e7e7a9cpd66d2bbf113c47a@mail.gmail.com>
Message-ID: <46cb515a0708281423h5287ebcdya0826167a8b1096b@mail.gmail.com>

On 8/28/07, Fernando Perez <fperez.net at gmail.com> wrote:

> Note: I'll be reverting the deprecation of some of the %pdef &
> friends.   There are several tutorials out on the net, widely used in
> scientific computing circles, that list these and they do get used.  A

Yeah, that's ok for me.

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


From fperez.net at gmail.com  Tue Aug 28 18:02:39 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 28 Aug 2007 16:02:39 -0600
Subject: [IPython-dev] Remove copyright statement?
In-Reply-To: <6ce0ac130708281348v74214551v431756144f5b7235@mail.gmail.com>
References: <46cb515a0708281316m50333bffs4be075ec11d1e6bf@mail.gmail.com>
	<6ce0ac130708281348v74214551v431756144f5b7235@mail.gmail.com>
Message-ID: <db6b5ecc0708281502n13061085ib3da71d8dfc8125f@mail.gmail.com>

On 8/28/07, Brian Granger <ellisonbg.net at gmail.com> wrote:
> I am fine with the addition of quickref, but I would prefer to keep
> the "->"s aligned.  To do this we might want to put the ? and
> %quickref on different lines.  This makes it more readable.

Don't worry, I'm an OCD sufferer too, so I was going to fix that  :)

Cheers,

f


From vivainio at gmail.com  Tue Aug 28 18:18:05 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 29 Aug 2007 00:18:05 +0200
Subject: [IPython-dev] Remove copyright statement?
In-Reply-To: <db6b5ecc0708281502n13061085ib3da71d8dfc8125f@mail.gmail.com>
References: <46cb515a0708281316m50333bffs4be075ec11d1e6bf@mail.gmail.com>
	<6ce0ac130708281348v74214551v431756144f5b7235@mail.gmail.com>
	<db6b5ecc0708281502n13061085ib3da71d8dfc8125f@mail.gmail.com>
Message-ID: <46cb515a0708281518p318acf9bi1cb1c2a6aa5880a@mail.gmail.com>

On 8/29/07, Fernando Perez <fperez.net at gmail.com> wrote:
> On 8/28/07, Brian Granger <ellisonbg.net at gmail.com> wrote:
> > I am fine with the addition of quickref, but I would prefer to keep
> > the "->"s aligned.  To do this we might want to put the ? and
> > %quickref on different lines.  This makes it more readable.
>
> Don't worry, I'm an OCD sufferer too, so I was going to fix that  :)

Being more of an ADHD personality myself, I'd remove from banner:

- copyright statement
- %magic (%quickref is enough)
- help (do people still use it these days? if they do, they don't need
to be told about it again)

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


From fperez.net at gmail.com  Tue Aug 28 18:29:37 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 28 Aug 2007 16:29:37 -0600
Subject: [IPython-dev] Remove copyright statement?
In-Reply-To: <46cb515a0708281518p318acf9bi1cb1c2a6aa5880a@mail.gmail.com>
References: <46cb515a0708281316m50333bffs4be075ec11d1e6bf@mail.gmail.com>
	<6ce0ac130708281348v74214551v431756144f5b7235@mail.gmail.com>
	<db6b5ecc0708281502n13061085ib3da71d8dfc8125f@mail.gmail.com>
	<46cb515a0708281518p318acf9bi1cb1c2a6aa5880a@mail.gmail.com>
Message-ID: <db6b5ecc0708281529jdc4224v5cfff1e94ef1c26f@mail.gmail.com>

On 8/28/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 8/29/07, Fernando Perez <fperez.net at gmail.com> wrote:
> > On 8/28/07, Brian Granger <ellisonbg.net at gmail.com> wrote:
> > > I am fine with the addition of quickref, but I would prefer to keep
> > > the "->"s aligned.  To do this we might want to put the ? and
> > > %quickref on different lines.  This makes it more readable.
> >
> > Don't worry, I'm an OCD sufferer too, so I was going to fix that  :)
>
> Being more of an ADHD personality myself, I'd remove from banner:
>
> - copyright statement

The default python still carries it, so I'm leaving it.  We build on
Python through and through, and I want to keep it clear that ipython
is just python+lots more, but acknowledging that foundation very
explicitly.

> - %magic (%quickref is enough)

Yup, I'm happy replacing this, as long as we add a little blurb about
what magics are in the first place to %quickref (could just be to
copy/paste the first paragraph of %magic to %quidref).

> - help (do people still use it these days? if they do, they don't need
> to be told about it again)

New users do need to be told about it, since by definition of 'new'
it's not 'again'.  So help stays.

Cheers,

f


From Glen.Mabey at swri.org  Wed Aug 29 09:44:50 2007
From: Glen.Mabey at swri.org (Glen W. Mabey)
Date: Wed, 29 Aug 2007 08:44:50 -0500
Subject: [IPython-dev] load on controller node
Message-ID: <20070829134450.GC2324@bams.ccf.swri.edu>

Hello,

Using 'saw', I'm trying to understand the CPU usage levels that I'm
observing on the 40 engines (10x2x2 xeon) relative to the load on the
controller CPU (the remote controller is instantiated on yet another
host).

In my outermost for-loop, I use executeAll() followed by a pullAll().  I
inserted a time.sleep(5) between them, and observed the CPU load shown
on the attached graph.  On this graph, each host's % utilization for
each CPU is summed together, for a max of 4.  The mp* hosts run 4
engines each, and the tp host runs the controller, and the most recent
stats appear on the right (axis mis-labeled).  Thus, the hump between 10
and 17 corresponds to the executeAll(), between 17 and 21 the sleep(),
and 22 to 25 the pullAll().

What is surprising to me is that the load on the controller lasts so
much longer (in time) than the load on the engines caused by the
pullAll(), although they probably have the same area ...  

So, I guess there is nothing shocking in the graph, although it would be
interesting to see how things would change if the controller were able
to use more than 1 CPU.

Best Regards,
Glen Mabey

BTW, the low time between 25 and 27 is a disk access, and I plan to
reduce the effect of this by running a tandem set of engines that simply
pull the data into the NFS cache ...  we'll see how that goes.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gkrellShoot_08-29-07_082048.png
Type: image/png
Size: 70286 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070829/751a4957/attachment.png>

From ellisonbg.net at gmail.com  Wed Aug 29 11:59:53 2007
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 29 Aug 2007 09:59:53 -0600
Subject: [IPython-dev] load on controller node
In-Reply-To: <20070829134450.GC2324@bams.ccf.swri.edu>
References: <20070829134450.GC2324@bams.ccf.swri.edu>
Message-ID: <6ce0ac130708290859o2eeadfe5r6706cc781e61468c@mail.gmail.com>

Glen,

I think what is going on is the following.  When you issue a pullAll
command, and that request reaches the engines, the engines each send
back the data.  Once that data has been sent to the controller, the
engine load goes back down.  But, now think about what the controller
has to do:

1) Receive all the data *from every engine*

2) Collate the resulting data from each engine into a single list of
pulled results

3) Send the data back to the RemoteController.

Steps 2 and 3 won't happen until after the engine load goes back down,
so I think that is what you are seeing.  The other aspect the
amplifies this effect, is that each engine only handles 1 object,
whereas the controller handles N objects (for N engines).  There is
simply a lot more for the controller to do.

One thing that this shows is that the controller can be a bottleneck
for certain types of algorithms.  Anytime, I end up with such a
bottleneck, I try to see if there are ways of moving more things onto
the engines and avoid the data movement through the controller.

With that said, I guess we need to submit the final version of the
slides by tomorrow.  Are you on target for that.  It is great to got
this working with 40 engines.

> So, I guess there is nothing shocking in the graph, although it would be
> interesting to see how things would change if the controller were able
> to use more than 1 CPU.

You can do this right now pretty easily - but I am not sure it is
worth it.  You could start two controllers and have 20 engines connect
to each.  Then in your client code you would simply create 2
RemoteControllers and write the algorithm in terms of those.  In the
future, we really need to create a MetaRemoteController object that
supports the notion of aggregating multiple RemoteController objects
into a single one.  But, even if you do this, it is possible that the
process running the RemoteController will still be a bottleneck.  Not
sure if you have time to explore all this.

Let me know if you need anything else.

Brian

> Best Regards,
> Glen Mabey
>
> BTW, the low time between 25 and 27 is a disk access, and I plan to
> reduce the effect of this by running a tandem set of engines that simply
> pull the data into the NFS cache ...  we'll see how that goes.
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>
>
>


From Glen.Mabey at swri.org  Wed Aug 29 14:43:43 2007
From: Glen.Mabey at swri.org (Glen W. Mabey)
Date: Wed, 29 Aug 2007 13:43:43 -0500
Subject: [IPython-dev] waiting for a executeAll( ..., block=False) to finish
Message-ID: <20070829184342.GG2324@bams.ccf.swri.edu>

Hello,

After having called executeAll() with block=False, is there some way to
wait for it to have completed on all engines?

Thanks,
Glen



From ellisonbg.net at gmail.com  Wed Aug 29 15:41:52 2007
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 29 Aug 2007 13:41:52 -0600
Subject: [IPython-dev] waiting for a executeAll( ...,
	block=False) to finish
In-Reply-To: <20070829184342.GG2324@bams.ccf.swri.edu>
References: <20070829184342.GG2324@bams.ccf.swri.edu>
Message-ID: <6ce0ac130708291241k72a85120l626dfcba16f1ce5@mail.gmail.com>

Yep,

This page:

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

Has a section on non-blocking execution that has the details.  Here is
the short story though.

When execute is called with block =False, it returns a PendingResult object:

[15]: pr = rc.executeAll('time.sleep(5)',block=False)

This object has a getResult method that can called at a later moment
in time to get the results.  By default PendingResult.getResult will
block, but it too can be made to not-block (which allows you to poll
for a result) by doing PendingResult.getResult(block=False).  So the
following works:

In [16]: pr.getResult()                                     # now
block for the result
Out[16]:
<Results List>
[0] In [6]: time.sleep(5)
[1] In [4]: time.sleep(5)
[2] In [6]: time.sleep(5)
[3] In [6]: time.sleep(5)

If the call to execute raised an exception, calling getResult will
raise the exception at that point.

Also, it is worth noting that most methods of RemoteController have
this behavior.  The blocking behavior of all methods can be controlled
by setting rc.block = False.  Then all methods (push, pull, execute,
scatter, gather) will return PendingResults objects.

Hope this helps

Brian


On 8/29/07, Glen W. Mabey <Glen.Mabey at swri.org> wrote:
> Hello,
>
> After having called executeAll() with block=False, is there some way to
> wait for it to have completed on all engines?
>
> Thanks,
> Glen
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Wed Aug 29 21:15:32 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 29 Aug 2007 19:15:32 -0600
Subject: [IPython-dev] [Ipython-svndiff] 2688 - use subprocess for
	ipy_workdir'
In-Reply-To: <20070829114229.8CF3C39C0A8@new.scipy.org>
References: <20070829114229.8CF3C39C0A8@new.scipy.org>
Message-ID: <db6b5ecc0708291815of2325d3jfd64972eba7f699b@mail.gmail.com>

I just noticed this commit while checking recent SVN activity:

On 8/29/07, ipython-svndiff at scipy.org <ipython-svndiff at scipy.org> wrote:

> +import os, subprocess

This is a problem: subprocess is a 2.4-only module, and we're trying
to remain available to 2.3 users.

If this functionality is made optional with a nice error message, I'm
OK with it.

We can also decide to ditch 2.3 compatibility (at some point we
obviously will), but just as Robert said when the same discussion took
place for scipy, we shouldn't do it just for a minor convenience.

My position is largely Robert's:

http://projects.scipy.org/pipermail/scipy-dev/2007-August/007710.html

And the fact that numpy/scipy seem to have agreed to stick with 2.3
compatibility is one more argument for us to do the same.  The
scientific community is a large ipython user, and I don't want to make
ipython require 2.4 when numpy/scipy don't.


Once the 2.4 (or 2.5) features we need become truly compelling we'll
switch over, but if we can remain available to a larger user base (at
the cost of a small inconvenience to ourselves) we'll do so.

Cheers,

f


From stefan at sun.ac.za  Thu Aug 30 03:39:26 2007
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Thu, 30 Aug 2007 09:39:26 +0200
Subject: [IPython-dev] [Ipython-svndiff] 2688 - use subprocess for
	ipy_workdir'
In-Reply-To: <db6b5ecc0708291815of2325d3jfd64972eba7f699b@mail.gmail.com>
References: <20070829114229.8CF3C39C0A8@new.scipy.org>
	<db6b5ecc0708291815of2325d3jfd64972eba7f699b@mail.gmail.com>
Message-ID: <20070830073926.GY14395@mentat.za.net>

On Wed, Aug 29, 2007 at 07:15:32PM -0600, Fernando Perez wrote:
> I just noticed this commit while checking recent SVN activity:
> 
> On 8/29/07, ipython-svndiff at scipy.org <ipython-svndiff at scipy.org> wrote:
> 
> > +import os, subprocess
> 
> This is a problem: subprocess is a 2.4-only module, and we're trying
> to remain available to 2.3 users.

I tried running IPython under 2.3 before this change, and then already
it gave up with

AttributeError: 'module' object has no attribute 'DocTestRunner'

Cheers
St?fan


From fperez.net at gmail.com  Thu Aug 30 13:13:17 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 30 Aug 2007 11:13:17 -0600
Subject: [IPython-dev] [Ipython-svndiff] 2688 - use subprocess for
	ipy_workdir'
In-Reply-To: <20070830073926.GY14395@mentat.za.net>
References: <20070829114229.8CF3C39C0A8@new.scipy.org>
	<db6b5ecc0708291815of2325d3jfd64972eba7f699b@mail.gmail.com>
	<20070830073926.GY14395@mentat.za.net>
Message-ID: <db6b5ecc0708301013j2722edd6s115cc98ae08d1607@mail.gmail.com>

Hi Stefan,

On 8/30/07, Stefan van der Walt <stefan at sun.ac.za> wrote:
> On Wed, Aug 29, 2007 at 07:15:32PM -0600, Fernando Perez wrote:
> > I just noticed this commit while checking recent SVN activity:
> >
> > On 8/29/07, ipython-svndiff at scipy.org <ipython-svndiff at scipy.org> wrote:
> >
> > > +import os, subprocess
> >
> > This is a problem: subprocess is a 2.4-only module, and we're trying
> > to remain available to 2.3 users.
>
> I tried running IPython under 2.3 before this change, and then already
> it gave up with
>
> AttributeError: 'module' object has no attribute 'DocTestRunner'

If you have 2.3 installed, could you please try svn update and run
again?  I just fixed this particular one, but there could be more
lurking.

Thanks for catching it.

Cheers,

f


From vivainio at gmail.com  Fri Aug 31 08:43:03 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 31 Aug 2007 14:43:03 +0200
Subject: [IPython-dev] [Ipython-svndiff] 2688 - use subprocess for
	ipy_workdir'
In-Reply-To: <db6b5ecc0708291815of2325d3jfd64972eba7f699b@mail.gmail.com>
References: <20070829114229.8CF3C39C0A8@new.scipy.org>
	<db6b5ecc0708291815of2325d3jfd64972eba7f699b@mail.gmail.com>
Message-ID: <46cb515a0708310543s6f3201clf2a83c3aa22366ab@mail.gmail.com>

On 8/30/07, Fernando Perez <fperez.net at gmail.com> wrote:

> > +import os, subprocess
>
> This is a problem: subprocess is a 2.4-only module, and we're trying
> to remain available to 2.3 users.

For extensions, it's not really a problem. Here, the subprocess
doesn't matter much, but e.g. jobctrl extension really needs it.
Usability for ipython proper for 2.3 users is not hampered at all.

Also, subprocess is available as an external module.

Not directly related to this particular issue:

Extensions should be thought of as "contributions that may or may not
be useful", with quality and compatibility requirements to match -
i.e., not much.

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


From fperez.net at gmail.com  Fri Aug 31 12:51:15 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 31 Aug 2007 10:51:15 -0600
Subject: [IPython-dev] [Ipython-svndiff] 2688 - use subprocess for
	ipy_workdir'
In-Reply-To: <46cb515a0708310543s6f3201clf2a83c3aa22366ab@mail.gmail.com>
References: <20070829114229.8CF3C39C0A8@new.scipy.org>
	<db6b5ecc0708291815of2325d3jfd64972eba7f699b@mail.gmail.com>
	<46cb515a0708310543s6f3201clf2a83c3aa22366ab@mail.gmail.com>
Message-ID: <db6b5ecc0708310951o7693419ve0939bfd5c3f9713@mail.gmail.com>

On 8/31/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 8/30/07, Fernando Perez <fperez.net at gmail.com> wrote:
>
> > > +import os, subprocess
> >
> > This is a problem: subprocess is a 2.4-only module, and we're trying
> > to remain available to 2.3 users.
>
> For extensions, it's not really a problem. Here, the subprocess
> doesn't matter much, but e.g. jobctrl extension really needs it.
> Usability for ipython proper for 2.3 users is not hampered at all.
>
> Also, subprocess is available as an external module.
>
> Not directly related to this particular issue:
>
> Extensions should be thought of as "contributions that may or may not
> be useful", with quality and compatibility requirements to match -
> i.e., not much.

That's OK with me: as long as the core remains fully functional under
2.3, I'm perfectly OK with the idea that extensions may require 2.4 to
work.  I'd prefer not to have extensions that depend on 2.5, but even
that could be OK if a really good one is a pain to write under 2.4.

We just want to give 2.3 users the 'basic' ipython, which I think will
satisfy the needs of most.

Cheers,

f


From Glen.Mabey at swri.org  Fri Aug 31 14:25:31 2007
From: Glen.Mabey at swri.org (Glen W. Mabey)
Date: Fri, 31 Aug 2007 13:25:31 -0500
Subject: [IPython-dev] utility to monitor CPU utilization
Message-ID: <20070831182531.GA5142@bams.ccf.swri.edu>


Hello,

If you happen to have PyQt3 installed on your system, and you happen to
have gkrellmd running on a whole bunch of nodes whose CPU utilization
you want to monitor, and you happen to have gkrellm installed, then you
might find the attached source code files really useful.   Oh yeah, you
also have to matplotlib installed.

Basically, I hacked a C source file that was posted to the gkrellm
mailing list:

http://lists.jutley.org/pipermail/gkrellm/2006-November/000209.html

see also:

http://lists.jutley.org/pipermail/gkrellm/2007-August/000350.html

Anyway, the attached files are a terrible hack and are strictly only
provided as an example of what could be done.

Really, all of the network operations done in gkrellmd_to_text.c should
be done in python.  And if a network connection fails on the first time
things run, a gkrellmd instance could be spawned via `ssh -f hostname
gkrellmd ---options...`

Those that don't want to use PyQt3 could probably implement something
similar with their toolkit of choice very easily -- it's very simple,
but can be extremely useful for dealing with IPython1 setups.

Best Regards,
Glen Mabey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gkrellmd_to_text.c
Type: text/x-csrc
Size: 6528 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070831/9fa49e65/attachment.c>
-------------- next part --------------
<!DOCTYPE UI><UI version="3.3" stdsetdef="1">
<class>Form1</class>
<comment>Python:from mplwidget import *</comment>
<widget class="QMainWindow">
    <property name="name">
        <cstring>Form1</cstring>
    </property>
    <property name="geometry">
        <rect>
            <x>0</x>
            <y>0</y>
            <width>600</width>
            <height>480</height>
        </rect>
    </property>
    <property name="caption">
        <string>Form1</string>
    </property>
    <hbox>
        <property name="name">
            <cstring>unnamed</cstring>
        </property>
        <widget class="MatplotlibWidget">
            <property name="name">
                <cstring>cpu_matplotlibWidget</cstring>
            </property>
        </widget>
        <widget class="QLayoutWidget">
            <property name="name">
                <cstring>layout2</cstring>
            </property>
            <vbox>
                <property name="name">
                    <cstring>unnamed</cstring>
                </property>
                <spacer>
                    <property name="name">
                        <cstring>spacer1_2</cstring>
                    </property>
                    <property name="orientation">
                        <enum>Vertical</enum>
                    </property>
                    <property name="sizeType">
                        <enum>Expanding</enum>
                    </property>
                    <property name="sizeHint">
                        <size>
                            <width>21</width>
                            <height>16</height>
                        </size>
                    </property>
                </spacer>
                <widget class="QPushButton">
                    <property name="name">
                        <cstring>host_pushButton_tp</cstring>
                    </property>
                    <property name="text">
                        <string>tp</string>
                    </property>
                </widget>
                <widget class="QPushButton">
                    <property name="name">
                        <cstring>host_pushButton_1</cstring>
                    </property>
                    <property name="text">
                        <string>mp1</string>
                    </property>
                </widget>
                <widget class="QPushButton">
                    <property name="name">
                        <cstring>host_pushButton_2</cstring>
                    </property>
                    <property name="text">
                        <string>mp2</string>
                    </property>
                </widget>
                <widget class="QPushButton">
                    <property name="name">
                        <cstring>host_pushButton_3</cstring>
                    </property>
                    <property name="text">
                        <string>mp3</string>
                    </property>
                </widget>
                <widget class="QPushButton">
                    <property name="name">
                        <cstring>host_pushButton_4</cstring>
                    </property>
                    <property name="text">
                        <string>mp4</string>
                    </property>
                </widget>
                <widget class="QPushButton">
                    <property name="name">
                        <cstring>host_pushButton_5</cstring>
                    </property>
                    <property name="text">
                        <string>mp5</string>
                    </property>
                </widget>
                <widget class="QPushButton">
                    <property name="name">
                        <cstring>host_pushButton_6</cstring>
                    </property>
                    <property name="text">
                        <string>mp6</string>
                    </property>
                </widget>
                <widget class="QPushButton">
                    <property name="name">
                        <cstring>host_pushButton_7</cstring>
                    </property>
                    <property name="text">
                        <string>mp7</string>
                    </property>
                </widget>
                <widget class="QPushButton">
                    <property name="name">
                        <cstring>host_pushButton_8</cstring>
                    </property>
                    <property name="text">
                        <string>mp8</string>
                    </property>
                </widget>
                <widget class="QPushButton">
                    <property name="name">
                        <cstring>host_pushButton_9</cstring>
                    </property>
                    <property name="text">
                        <string>mp9</string>
                    </property>
                </widget>
                <widget class="QPushButton">
                    <property name="name">
                        <cstring>host_pushButton_10</cstring>
                    </property>
                    <property name="text">
                        <string>mp10</string>
                    </property>
                </widget>
                <spacer>
                    <property name="name">
                        <cstring>spacer1</cstring>
                    </property>
                    <property name="orientation">
                        <enum>Vertical</enum>
                    </property>
                    <property name="sizeType">
                        <enum>Expanding</enum>
                    </property>
                    <property name="sizeHint">
                        <size>
                            <width>21</width>
                            <height>20</height>
                        </size>
                    </property>
                </spacer>
            </vbox>
        </widget>
    </hbox>
</widget>
<toolbars>
    <toolbar dock="2">
        <property name="name">
            <cstring>toolBar</cstring>
        </property>
        <property name="label">
            <string>Tools</string>
        </property>
        <action name="editUndoAction"/>
    </toolbar>
</toolbars>
<customwidgets>
    <customwidget>
        <class>MatplotlibWidget</class>
        <header location="global">mplwidget</header>
        <sizehint>
            <width>200</width>
            <height>120</height>
        </sizehint>
        <container>0</container>
        <sizepolicy>
            <hordata>7</hordata>
            <verdata>7</verdata>
            <horstretch>0</horstretch>
            <verstretch>0</verstretch>
        </sizepolicy>
        <pixmap>image0</pixmap>
        <property type="String">margins</property>
    </customwidget>
</customwidgets>
<actions>
    <action>
        <property name="name">
            <cstring>editUndoAction</cstring>
        </property>
        <property name="iconSet">
            <iconset>image1</iconset>
        </property>
        <property name="text">
            <string>Undo</string>
        </property>
        <property name="menuText">
            <string>&amp;Undo</string>
        </property>
        <property name="accel">
            <string>Ctrl+Z</string>
        </property>
    </action>
</actions>
<images>
    <image name="image0">
        <data format="PNG" length="1002">89504e470d0a1a0a0000000d4948445200000016000000160806000000c4b46c3b000003b149444154789cad945f4c5b551cc73fe7dc4b7b4bcba0762d45c43114323599ee6192609c51d883892ce083f1718b3ebb185f8dc91e972cf39d2d2a2f1af664b6f1e0fe3863a0718969700eb0c52142da0242a1bd6d696f7bcff101585203ceb8fd9ece39f99dcff9fe7edf939f88c562ec465f5f9fe609442c161362173c3e3eae7b7a7ac8e7f36432196cdbfe4f907c3e4f2291201e8fe338cec3737357e9e8e828aded1e229d650e1f2d51754b082110124c13a4dc5ea341eb9dc284c0558a853f3ce8cb0677ef500fde7d39d2596679e326597b8e9abb85d7a770ab16ab6983ec5a05b487a70e36f0f4e10afe408d6a558310980108478dba4a1e8233990c5d474b64ed39aa3a8fe5f3317fbf81dbd70bccfeb205947632fd74f6589c1c6ea2f70d03a58ba0c1f2c9bdc1b66de3b8256a6e11cbe7e3ee1d181b590124fe2693aeee08d223c82c3a2c24b7b874bec8f26288774f7bd054504aef0dde6e99c0eb83f9fb266323cb80a27fb0958141836044605a2ee5523393371cc646fee2da37195aa35d0c0c5b4859ac03d7e91712dcaac5adab3650a3ff9d08ef7dd8404bb48869e5d958b5b87dadc4c9a1464e9f0d0326df7ebd86bd2e310cb1bf62d384d59441f2d70a070e1c60e09489929b988681bdd9cc97170bcc4c65595f71f8e0e3301337fc24a7732467831875a47f289652b0be5e4151e6d07316c1b0c0340d8ab92023e76d66a6b2840e36d2fb7a13fee632475e6edc367ea98a90fb98b7dd6310ca0328a44761582e1bab41befabcc0ec940d28bc5e93b68e064cab84e1d9beaeb48934eac1f53b01c1b000fca496aa54b61a99fcde61662a4b4b4b23d1680be9d426173e4df3602a48ea411989a4fd590f52a8fd156b05ed9d350e3defe3cfdf4b4c7ce770ea7d3fb9f520afbe1620daeee5c26735d20b9b9cfb6811a754a439e4e5c5639a4caa1e5caf586bfc0197b78702005cb9b4cae4cd3267ce8638fe964bd72b393e39d74928d242617303a756a37f284447770dcdbffc6384a05a85de1306e9a52057c7527c7131c3c42d3f475eb2303c82d4fc3276d6811db37efeb148723082d9b08f79f97c1e5729109a9a28307cc622d2d6cdf52b2b24efe548dedb00142009862cfa879ee1a71f6cec928353511472fbf4389148b0b0e0c108081412458dfe21c9f11351e67e7358595468246d1d1e5e38a6e9e851bc39d84ab502a669331dafec0d8ec7e3e8cb06e1a881d727d1ae40180a434a8c9db129a54126ad48a7358c2b4c5352c8c374bcccdab2bb37d8719cba79fab8211f9df218e0582c261e95f8bfc04f1a1e8bc5c4dfe0a19017a725d8c60000000049454e44ae426082</data>
    </image>
    <image name="image1">
        <data format="PNG" length="172">89504e470d0a1a0a0000000d4948445200000016000000160806000000c4b46c3b0000007349444154789ced92c10e80200840b1ef661d1cff4d876aa888a17669f9360f283ed80060f159425f3a71f53602e08e992b098801d02854176ae47f21ce1fb5b05d38eddc9060d0f11379635b3bc92bd518e239a943ec1d5ab7785cee107be4b215af4091f894de47181ecea59ede9ec59f380062ac28b10fe74fef0000000049454e44ae426082</data>
    </image>
</images>
<layoutdefaults spacing="6" margin="11"/>
<includehints>
    <includehint>mplwidget</includehint>
</includehints>
</UI>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blademon.py
Type: text/x-python
Size: 6560 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070831/9fa49e65/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplwidget.py
Type: text/x-python
Size: 1789 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070831/9fa49e65/attachment-0001.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blademon_designer.py
Type: text/x-python
Size: 4962 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070831/9fa49e65/attachment-0002.py>

From fperez.net at gmail.com  Fri Aug 31 19:20:27 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 31 Aug 2007 17:20:27 -0600
Subject: [IPython-dev] [Ipython-svndiff] 2688 - use subprocess for
	ipy_workdir'
In-Reply-To: <20070831112645.GA10668@mentat.za.net>
References: <20070829114229.8CF3C39C0A8@new.scipy.org>
	<db6b5ecc0708291815of2325d3jfd64972eba7f699b@mail.gmail.com>
	<20070830073926.GY14395@mentat.za.net>
	<db6b5ecc0708301013j2722edd6s115cc98ae08d1607@mail.gmail.com>
	<20070831112645.GA10668@mentat.za.net>
Message-ID: <db6b5ecc0708311620r8dc3260n52446e1fe74b3790@mail.gmail.com>

Hi Stefan,

On 8/31/07, Stefan van der Walt <stefan at sun.ac.za> wrote:
> Hi Fernando,
>
> On Thu, Aug 30, 2007 at 11:13:17AM -0600, Fernando Perez wrote:
> > If you have 2.3 installed, could you please try svn update and run
> > again?  I just fixed this particular one, but there could be more
> > lurking.
>
> OK, it runs now.  But the colour prompt is gone (no readline).  I did
> install ctypes, but still no luck:
>
> WARNING: Readline services not available on this platform.
> WARNING: The auto-indent feature requires the readline library

Mmh, what platform are you on?  Windows or linux?  If linux, try at
the normal python2.3 prompt

import readline

if you get an error, it means you built your python2.3 without readline support.

cheers,

f