From ellisonbg at gmail.com  Mon Nov  1 01:25:56 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Sun, 31 Oct 2010 22:25:56 -0700
Subject: [IPython-dev] Parallel IPython with ZMQ slides
In-Reply-To: <AANLkTi=d6HdwOJO2XmnM=6yQ6E5Jo-ESmvcFO_bTBgib@mail.gmail.com>
References: <AANLkTi=d6HdwOJO2XmnM=6yQ6E5Jo-ESmvcFO_bTBgib@mail.gmail.com>
Message-ID: <AANLkTinRd_i9M83KHRCBp3-uMZYeySSbkc+FujGaJETf@mail.gmail.com>

Min,

Thanks for posting this!

Brian

On Sat, Oct 30, 2010 at 1:27 PM, MinRK <benjaminrk at gmail.com> wrote:
> As requested, the slides from my presentation of the new parallel code to
> Py4Science last week:
> http://ptsg.berkeley.edu/~minrk/ipzmq/ipzmq.p4s.pdf
> And code for some of the demos (+ NetworkX DAG dependencies):
> http://ptsg.berkeley.edu/~minrk/ipzmq/demo.zip
>
> -MinRK



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com


From hans_meine at gmx.net  Mon Nov  1 05:55:26 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Mon, 1 Nov 2010 10:55:26 +0100
Subject: [IPython-dev] filename completion - anyone working on it?
In-Reply-To: <AANLkTi=B_zmNoVzeoJEQ9UeHLi76ndtvOw2ti921uuSZ@mail.gmail.com>
References: <201010261531.56428.hans_meine@gmx.net>
	<AANLkTi=B_zmNoVzeoJEQ9UeHLi76ndtvOw2ti921uuSZ@mail.gmail.com>
Message-ID: <201011011055.27196.hans_meine@gmx.net>

Hi Fernando!

Op den Dingsdag 26 Oktober 2010 Klock 21:15:40 hett Fernando Perez schreven:
> On Tue, Oct 26, 2010 at 6:31 AM, Hans Meine <hans_meine at gmx.net> wrote:
> > I am constantly bugged by filename completion in IPython.  To be
> > specific, there are two cases that maybe need to be considered
> > separately: 1) Completion of filenames in arguments to IPython magics,
> > e.g. %run foo<tab> 2) Completion of filenames in strings, i.e. filename
> > = "../subdir/bar<tab>"
> 
> Could you pull from trunk and let me know if you find the situation
> any better?  Invoking my time machine for your question, I rewound to
> yesterday afternoon and put more time than I'd like to admit into this
> very problem:

Aaah, I love it when you pull that trick! :-)

> Things already work as you imagine, with a custom completer for magics
> without quotes, and a generic file completer that should work in
> strings.  This weekend John and I actually ran into the limitations of
> the completions-in-strings, and that prompted my effort to fix this.

The strange thing is - I updated my git repo and tried it out, and it was 
certainly working to some extent (read: at least some completions I tried with 
paths containing spaces did work, so I was happy).  I planned to try it out 
more thoroughly for some days before reporting back, but right now I tried 
again (with updated git master), and it does not work at all anymore?!
(OK, it's monday morning, but...)

I tried the following two versions:

current HEAD, i.e. commit bd2a307834c957701bf36e3552ff4072c6bf3d78,
reporting as "0.11.dev" on startup, and

commit 02eecaf061408f26a3c6029886b8794f73581938, which you pointed me to,
reporting as "0.11.alpha1.git" on startup.

Both seem to behave identically.

Given a directory "../Daten/FLIM/1004 Nadine", I tried to <tab>-complete like 
this:

a = "../Daten/FLIM/1004<tab>
-> gives proper completion list, and adds a space (which then fails as below)

a = "../Daten/FLIM/1004 <tab>
%run foo.py "../Daten/FLIM/1004 <tab>
-> fails, gives wrong / default completions

%run "../Daten/FLIM/1004 <tab>
-> fails: gives correct completion list, but adds the full prefix again on 
every <tab> press.

The last one looks easy to fix though, and seems to be the only case where 
pressing <tab> *behind* a space in a filename takes the previous part into 
account.

The test suite mostly runs fine, though - I get one error because of a 
missing/inaccessible /usr/games/bin, and two failures which seem to be related 
to output formatting/coloring:

======================================================================
FAIL: Test that object's __del__ methods are called on exit.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.6/site-packages/nose/case.py", line 186, in runTest
    self.test(*self.arg)
  File 
"/informatik/home/meine/Programming/ipython/IPython/testing/decorators.py", 
line 225, in skipper_func
    return f(*args, **kwargs)
  File 
"/informatik/home/meine/Programming/ipython/IPython/core/tests/test_run.py", 
line 172, in test_obj_del
    tt.ipexec_validate(self.fname, 'object A deleted')
  File "/informatik/home/meine/Programming/ipython/IPython/testing/tools.py", 
line 252, in ipexec_validate
    nt.assert_equals(out.strip(), expected_out.strip())
AssertionError: '\x1b[?1034hobject A deleted' != 'object A deleted'
>>  raise self.failureException, \
          (None or '%r != %r' % ('\x1b[?1034hobject A deleted', 'object A 
deleted'))
    

======================================================================
FAIL: IPython.core.tests.test_run.TestMagicRunSimple.test_tclass
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.6/site-packages/nose/case.py", line 186, in runTest
    self.test(*self.arg)
  File 
"/informatik/home/meine/Programming/ipython/IPython/testing/decorators.py", 
line 225, in skipper_func
    return f(*args, **kwargs)
  File 
"/informatik/home/meine/Programming/ipython/IPython/core/tests/test_run.py", 
line 186, in test_tclass
    tt.ipexec_validate(self.fname, out)
  File "/informatik/home/meine/Programming/ipython/IPython/testing/tools.py", 
line 252, in ipexec_validate
    nt.assert_equals(out.strip(), expected_out.strip())
AssertionError: "\x1b[?1034hARGV 1-: ['C-first']\nARGV 1-: ['C-
second']\ntclass.py: deleting object: C-first" != "ARGV 1-: ['C-first']\nARGV 
1-: ['C-second']\ntclass.py: deleting object: C-first"
>>  raise self.failureException, \
          (None or '%r != %r' % ("\x1b[?1034hARGV 1-: ['C-first']\nARGV 1-: 
['C-second']\ntclass.py: deleting object: C-first", "ARGV 1-: ['C-
first']\nARGV 1-: ['C-second']\ntclass.py: deleting object: C-first"))
    
Is there a good way to debug these kind of things? (completion)
I would like to contribute test cases, but they would obviously require some 
temp. dir setup, and I don't know yet how to write good unit tests for this.

Given a setup like this:

mkdir tabcomplete && cd $_

mkdir "Test 1"
mkdir "Test 2"
echo 'print "hello world"' > foo.py
echo 'print "from subdir"' > "Test 1/bar.py"

I would expect this to work:

a = "Test<tab> -> should add a space and list 2 possible completions
a = "Test 1/b<tab> -> should fully complete "Test1/bar.py"
a = "Test 1/b<tab>" -> should fully complete "Test1/bar.py" (no 3rd quote)

Similarly:

%run foo.py "Test<tab>
%run foo.py "Test 1/b<tab>
%run "Test<tab>
%run "Test 1/b<tab>

And finally without quotes, too:

%run foo.py Test<tab>
%run foo.py Test\ 1/b<tab>
%run Test<tab>
%run Test\ 1/b<tab>

Thanks,
  Hans


From hans_meine at gmx.net  Mon Nov  1 06:05:19 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Mon, 1 Nov 2010 11:05:19 +0100
Subject: [IPython-dev] Some questions concerning current development
	versions and docs
Message-ID: <201011011105.20551.hans_meine@gmx.net>

Hi again,

I am still not very confident about my use of git; is there any public 
ipython-instance of the Gitwash-document online yet?

It's unfortunate that everything still points to 
http://ipython.scipy.org/doc/stable/html/development/ which is from 0.10.1 and 
still mentioning bzr.

Is the inputhook-stuff documented somewhere?  I recall several postings on 
this list mentioning the new way to detect whether a mainloop is already 
running, but I did not find it in http://ipython.scipy.org/doc/nightly/html/ 
(yet).

Have a nice day,
  Hans


From hans_meine at gmx.net  Mon Nov  1 06:14:01 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Mon, 1 Nov 2010 11:14:01 +0100
Subject: [IPython-dev] Some questions concerning current development
	versions and docs
In-Reply-To: <201011011105.20551.hans_meine@gmx.net>
References: <201011011105.20551.hans_meine@gmx.net>
Message-ID: <201011011114.01902.hans_meine@gmx.net>

Op den Maandag 01 November 2010 Klock 11:05:19 hett Hans Meine schreven:
> Is the inputhook-stuff documented somewhere?  I recall several postings on
> this list mentioning the new way to detect whether a mainloop is already
> running, but I did not find it in
> http://ipython.scipy.org/doc/nightly/html/ (yet).

OK, searching the full PDF manual for "mainloop" revealed two relevant hits:

4.2.7 GUI event loop support support
(BTW: double "support"?)

8.77 lib.guisupport

I am sorry for the noise.  I guess people should be able to find this; I was 
just looking in the wrong spots.

Have a nice day,
  Hans


From hans_meine at gmx.net  Mon Nov  1 10:36:10 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Mon, 1 Nov 2010 15:36:10 +0100
Subject: [IPython-dev] Ctrl-C quitting ipython
Message-ID: <201011011536.10871.hans_meine@gmx.net>

Hi,

I colleague of mine (CC'ed) complained about Ctrl-C not only not clearing the 
input line (we know about this, in conjunction with Qt/WX), but actually 
quitting ipython without further feedback.  This was happening not only with 
the distribution-provided ipython 0.10 and --wthread, but also with the 
current git version and --gui qt. 

From time to time (not everytime), Ctrl-C would kick him back into the shell, 
closing his ipython without further notice.  It is not reproducable, so I was 
guessing that it's a threading issue.  However, it still happens with the 
current development version, so I though I should mention it here.

He's using Ubuntu 10.04 (lucid) with
* readline 5.2-7build1 and
* python 2.6.5-0ubuntu1
* PyQt4 4.7.2 (using Qt 4.6.2)

Have a nice day,
  Hans


From hans_meine at gmx.net  Mon Nov  1 12:20:41 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Mon, 1 Nov 2010 17:20:41 +0100
Subject: [IPython-dev] Revival of %store (pspersistence)?
Message-ID: <201011011720.41814.hans_meine@gmx.net>

Hi again,

yet another question concerning newer IPythons: I have just missed %store, 
which I happened to use a lot (and happily) in the past, but has gone into 
quarantine/ in 0.10.  I have had a quick look at the code (encouraged by all 
the recent talk about the nicer codebase) and wonder what the main reasons are 
that this has gone?  (Let's put it like this: limited manpower aside, are 
there any non-obvious roadblocks?)

Also, the pickleshare DB seems to still exist (used for shadowhist), so this 
does not seem to be a roadblock.

Oh, and I was missing %clear recently, too.

Unfortunately, nobody is in #ipython right now (not your timezone probably), 
otherwise I would start hacking with some help ASAP.

[Update] I have just forked ipython on github and added a 
"revive_pspersistence" branch.  The basic functionality I tested seems to work 
already.  However, I guess there are a number of "no-gos", right?

Concerning magics and argument handling: I still see a lot of getopt-like arg. 
handling - wasn't there some newer, argparse-based approach?  Apart from 
better argument checking (I am sure a lot of unwanted cases will go unnoticed, 
like "%store -d a b c" or maybe "%store -r -d a" or whatever), it would also 
make sense to have better argument completion.  (Maybe even with help texts, 
zsh-like.)  I saw that %hist used quick_completer(), but that does not seem 
like a desirable approach (listing all valid options again).

Have a nice day,
  Hans


From robert.kern at gmail.com  Mon Nov  1 12:48:20 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 01 Nov 2010 11:48:20 -0500
Subject: [IPython-dev] Revival of %store (pspersistence)?
In-Reply-To: <201011011720.41814.hans_meine@gmx.net>
References: <201011011720.41814.hans_meine@gmx.net>
Message-ID: <iamr0k$4r6$1@dough.gmane.org>

On 11/1/10 11:20 AM, Hans Meine wrote:

> Concerning magics and argument handling: I still see a lot of getopt-like arg.
> handling - wasn't there some newer, argparse-based approach?

I have proposed one, but it has not been adopted yet:

   http://bitbucket.org/robertkern/kernmagic/src/tip/kernmagic/magic_arguments.py

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



From fperez.net at gmail.com  Mon Nov  1 13:09:55 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 1 Nov 2010 10:09:55 -0700
Subject: [IPython-dev] Revival of %store (pspersistence)?
In-Reply-To: <iamr0k$4r6$1@dough.gmane.org>
References: <201011011720.41814.hans_meine@gmx.net>
	<iamr0k$4r6$1@dough.gmane.org>
Message-ID: <AANLkTimz5b1JRbTGuCJ-5=asDsVzSTE=3UyKmubZNx8Q@mail.gmail.com>

On Mon, Nov 1, 2010 at 9:48 AM, Robert Kern <robert.kern at gmail.com> wrote:
>
> I have proposed one, but it has not been adopted yet:
>
> ? http://bitbucket.org/robertkern/kernmagic/src/tip/kernmagic/magic_arguments.py
>

Pull request, pull request!  :)

Sorry, I'm crazy busy today, will catch up with the list tomorow...

f


From matthew.brett at gmail.com  Mon Nov  1 13:17:36 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 1 Nov 2010 10:17:36 -0700
Subject: [IPython-dev] git workflow and gitwash and what's next
Message-ID: <AANLkTimWn0+4jFqE0SE-MB468utMwdO2C2WNDqHBv+_H@mail.gmail.com>

Hi guys,

Any interest in trying to harmonize / summarize recent git workflow
discussions in gitwash?  Or is it time to diverge in our gitwash
versions?

To summarize, I think everyone agrees with:

http://mail.scipy.org/pipermail/ipython-dev/2010-October/006746.html

More controversial is Fernando's 'always rebase' proposal:

http://mail.scipy.org/pipermail/ipython-dev/2010-October/006748.html

Then, Pauli extended and adapted the numpy gitwash workflow docs,
partly as a result of the conversation on the numpy mailing list:

http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html

I wonder whether it's worth a little pause for discussing where we all
agree and differ in order for us all to benefit from the recent
improvements by Fernando (mail) Pauli (edits)?  It may also make it
clearer whether there is still room to share a common set of gitwash
docs, or whether it's time to diverge.

Is there enough fundamental agreement on workflow?  My feeling is that there is.

See y'all,

Matthew


From robert.kern at gmail.com  Mon Nov  1 13:24:49 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 01 Nov 2010 12:24:49 -0500
Subject: [IPython-dev] Revival of %store (pspersistence)?
In-Reply-To: <201011011720.41814.hans_meine@gmx.net>
References: <201011011720.41814.hans_meine@gmx.net>
Message-ID: <iamt52$gr9$1@dough.gmane.org>

On 11/1/10 11:20 AM, Hans Meine wrote:
> Hi again,
>
> yet another question concerning newer IPythons: I have just missed %store,
> which I happened to use a lot (and happily) in the past, but has gone into
> quarantine/ in 0.10.  I have had a quick look at the code (encouraged by all
> the recent talk about the nicer codebase) and wonder what the main reasons are
> that this has gone?  (Let's put it like this: limited manpower aside, are
> there any non-obvious roadblocks?)

Personally, I dislike the %store functionality as it is currently written. Among 
other things, I don't like that it restores all of the variables at the start of 
the session. Every time I've used it, I've forgotten about the %stored variables 
until I begin to investigate why it takes ipython so long to start up.

I wouldn't mind its being brought back as an extension, though.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



From vivainio at gmail.com  Mon Nov  1 16:34:28 2010
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 1 Nov 2010 22:34:28 +0200
Subject: [IPython-dev] Revival of %store (pspersistence)?
In-Reply-To: <iamt52$gr9$1@dough.gmane.org>
References: <201011011720.41814.hans_meine@gmx.net>
	<iamt52$gr9$1@dough.gmane.org>
Message-ID: <AANLkTikJF1sJQS+HM9jg2WWiZG5eqS0Q=ZCPz2CsFrRS@mail.gmail.com>

On Mon, Nov 1, 2010 at 7:24 PM, Robert Kern <robert.kern at gmail.com> wrote:

> Personally, I dislike the %store functionality as it is currently written. Among
> other things, I don't like that it restores all of the variables at the start of
> the session. Every time I've used it, I've forgotten about the %stored variables
> until I begin to investigate why it takes ipython so long to start up.

The answer is not to use it for large data.

I regularly use it for small things like strings, macros and aliases
and haven't noticed any slowdowns.

-- 
Ville M. Vainio @@ Forum Nokia


From robert.kern at gmail.com  Mon Nov  1 16:42:44 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 01 Nov 2010 15:42:44 -0500
Subject: [IPython-dev] Revival of %store (pspersistence)?
In-Reply-To: <AANLkTikJF1sJQS+HM9jg2WWiZG5eqS0Q=ZCPz2CsFrRS@mail.gmail.com>
References: <201011011720.41814.hans_meine@gmx.net>	<iamt52$gr9$1@dough.gmane.org>
	<AANLkTikJF1sJQS+HM9jg2WWiZG5eqS0Q=ZCPz2CsFrRS@mail.gmail.com>
Message-ID: <ian8o5$e86$1@dough.gmane.org>

[PS to everyone: I am on the mailing list. Do not Cc me!]

On 11/1/10 3:34 PM, Ville M. Vainio wrote:
> On Mon, Nov 1, 2010 at 7:24 PM, Robert Kern<robert.kern at gmail.com>  wrote:
>
>> Personally, I dislike the %store functionality as it is currently written. Among
>> other things, I don't like that it restores all of the variables at the start of
>> the session. Every time I've used it, I've forgotten about the %stored variables
>> until I begin to investigate why it takes ipython so long to start up.
>
> The answer is not to use it for large data.
>
> I regularly use it for small things like strings, macros and aliases
> and haven't noticed any slowdowns.

Ah. I was using it for large data because it was a convenient way to restart a 
fresh IPython for new code without having to recalculate the data. I thought 
that's what it was for.

There are two good features being intermingled by %store: persistence of IPython 
objects like macros and aliases, and the persistence of user data. I would 
suggest that the former should be built in to IPython as part of the 
configuration system. The latter ought to live in an extension and needs to grow 
some more features from the current %store implementation.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



From arokem at berkeley.edu  Mon Nov  1 17:22:25 2010
From: arokem at berkeley.edu (Ariel Rokem)
Date: Mon, 1 Nov 2010 14:22:25 -0700
Subject: [IPython-dev] [Nipy-devel] git workflow and gitwash and what's
	next
In-Reply-To: <AANLkTimWn0+4jFqE0SE-MB468utMwdO2C2WNDqHBv+_H@mail.gmail.com>
References: <AANLkTimWn0+4jFqE0SE-MB468utMwdO2C2WNDqHBv+_H@mail.gmail.com>
Message-ID: <AANLkTinE6R=ZJGMnioKyPexO-+T=5_YxwBUVEksvM_xM@mail.gmail.com>

Hi everyone,

On Mon, Nov 1, 2010 at 10:17 AM, Matthew Brett <matthew.brett at gmail.com>wrote:

> Hi guys,
>
> Any interest in trying to harmonize / summarize recent git workflow
> discussions in gitwash?  Or is it time to diverge in our gitwash
> versions?
>
> To summarize, I think everyone agrees with:
>
> http://mail.scipy.org/pipermail/ipython-dev/2010-October/006746.html
>
> More controversial is Fernando's 'always rebase' proposal:
>
> http://mail.scipy.org/pipermail/ipython-dev/2010-October/006748.html
>
> Then, Pauli extended and adapted the numpy gitwash workflow docs,
> partly as a result of the conversation on the numpy mailing list:
>
> http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html
>
>
This is very good! I sometimes wish there was a 'git undo' command, so I
particularly like this section:

http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html#rebasing-on-master

My recent experiences with rebasing have been quite painful and I wish I
always had a tmp branch to reset to, before I get myself into trouble.
People like me should not be allowed to follow Fernando's instructions about
rebasing, without having a tmp branch to go to, when they (that is, I) screw
up.



> I wonder whether it's worth a little pause for discussing where we all
> agree and differ in order for us all to benefit from the recent
> improvements by Fernando (mail) Pauli (edits)?  It may also make it
> clearer whether there is still room to share a common set of gitwash
> docs, or whether it's time to diverge.
>
> Is there enough fundamental agreement on workflow?  My feeling is that
> there is.
>
>
I agree with you that there is  agreement :-)

Best,

Ariel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101101/5c85daa1/attachment.html>

From mark.voorhies at ucsf.edu  Mon Nov  1 17:56:32 2010
From: mark.voorhies at ucsf.edu (Mark Voorhies)
Date: Mon, 1 Nov 2010 14:56:32 -0700
Subject: [IPython-dev] Revival of %store (pspersistence)?
In-Reply-To: <ian8o5$e86$1@dough.gmane.org>
References: <201011011720.41814.hans_meine@gmx.net>
	<AANLkTikJF1sJQS+HM9jg2WWiZG5eqS0Q=ZCPz2CsFrRS@mail.gmail.com>
	<ian8o5$e86$1@dough.gmane.org>
Message-ID: <201011011456.32914.mark.voorhies@ucsf.edu>

On Monday, November 01, 2010 01:42:44 pm Robert Kern wrote:
> [PS to everyone: I am on the mailing list. Do not Cc me!]
> 
> On 11/1/10 3:34 PM, Ville M. Vainio wrote:
> > On Mon, Nov 1, 2010 at 7:24 PM, Robert Kern<robert.kern at gmail.com>  wrote:
> >
> >> Personally, I dislike the %store functionality as it is currently written. Among
> >> other things, I don't like that it restores all of the variables at the start of
> >> the session. Every time I've used it, I've forgotten about the %stored variables
> >> until I begin to investigate why it takes ipython so long to start up.
> >
> > The answer is not to use it for large data.

R saves session data in $PWD/.Rdata and restores it when R is re-invoked from $PWD.
The usual workflow is to have project-specific data directories and invoke R next to
the data that the session will operate on.  R frontends (e.g., ESS for Emacs) support this
workflow by prompting for a working directory when invoked (and R prompts for saving
session data on exit).  Would this be a useful way to make persistent data loading in 
IPython "deliberate but automatic"?

--Mark


From matthew.brett at gmail.com  Tue Nov  2 13:25:49 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 2 Nov 2010 10:25:49 -0700
Subject: [IPython-dev] [Nipy-devel] git workflow and gitwash and what's
	next
In-Reply-To: <AANLkTinE6R=ZJGMnioKyPexO-+T=5_YxwBUVEksvM_xM@mail.gmail.com>
References: <AANLkTimWn0+4jFqE0SE-MB468utMwdO2C2WNDqHBv+_H@mail.gmail.com>
	<AANLkTinE6R=ZJGMnioKyPexO-+T=5_YxwBUVEksvM_xM@mail.gmail.com>
Message-ID: <AANLkTimdBTz7mdO=a9kNHSPDPv81kOKfSV_Yhzowk0bD@mail.gmail.com>

Yo,

> This is very good! I sometimes wish there was a 'git undo' command, so I
> particularly like this section:
>
> http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html#rebasing-on-master
>
> My recent experiences with rebasing have been quite painful and I wish I
> always had a tmp branch to reset to, before I get myself into trouble.
> People like me should not be allowed to follow Fernando's instructions about
> rebasing, without having a tmp branch to go to, when they (that is, I) screw
> up.

The gitwash docs so far have the idea of a spectrum of experience - so
we were trying to cover:

1) User who just wants to run from the latest source, but will not do
edits (just git clone)
2) Someone who has done some small edits (bugfix, docs) but with not
much experience (make patches and email)
3) Full on developer (feature branch, pull request)

I wonder if in fact we want to extend the distinctions to:

3a) Developer fairly new to git (feature branch, pull request, never
rebase nor merge)
3b) Developer with a lot of git experience (feature branch, rebase,
pull request)

?

See y'all,

Matthew


From fperez.net at gmail.com  Wed Nov  3 02:38:06 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 2 Nov 2010 23:38:06 -0700
Subject: [IPython-dev] git workflow and gitwash and what's next
In-Reply-To: <AANLkTimWn0+4jFqE0SE-MB468utMwdO2C2WNDqHBv+_H@mail.gmail.com>
References: <AANLkTimWn0+4jFqE0SE-MB468utMwdO2C2WNDqHBv+_H@mail.gmail.com>
Message-ID: <AANLkTimCSN-aXAKn2jpA5J=+k_VENvuEiYpFk_V8j+Tb@mail.gmail.com>

On Mon, Nov 1, 2010 at 10:17 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
>
> More controversial is Fernando's 'always rebase' proposal:
>
> http://mail.scipy.org/pipermail/ipython-dev/2010-October/006748.html
>
>

Just for the record (I mentioned this today to Matthew), I'm totally
on board with *not* requiring rebase.  It's pretty clear from the
feedback that it would only scare/confuse many potential contributors,
so there's no point in asking for that.

A *committer* who needs to rebase a branch in order to disentangle a
particularly problematic piece of history may choose to do so if
really necessary, but we shouldn't ask that a random contributor need
to become a git guru just to send us a few commits in a branch.

So I think overall we're in pretty good agreement on the workflow ideas.

Cheers,

f


From hans_meine at gmx.net  Wed Nov  3 10:09:50 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Wed, 3 Nov 2010 15:09:50 +0100
Subject: [IPython-dev] Ctrl-C quitting ipython
In-Reply-To: <201011011536.10871.hans_meine@gmx.net>
References: <201011011536.10871.hans_meine@gmx.net>
Message-ID: <201011031509.51051.hans_meine@gmx.net>

Hi again,

Op den Maandag 01 November 2010 Klock 15:36:10 hett Hans Meine schreven:
> From time to time (not everytime), Ctrl-C would kick him back into the
> shell, closing his ipython without further notice. [...]

OK, here's some more info; without any active GUI support, it happened again 
today, and I let Chris work from within GDB in order to check why ipython 
exits sometimes without even resetting the terminal correctly.

The result: "Program exited with code 01." - looks like sys.exit(1) (or the 
equivalent in C in some library) being called.  Probably some extension 
installed a signal handler (we suspect openmesh).

To make this thread at least slightly on-topic again: could such things be 
trapped/recognized/warned about in ipython?

Have a nice day,
  Hans


From hans_meine at gmx.net  Wed Nov  3 11:49:45 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Wed, 3 Nov 2010 16:49:45 +0100
Subject: [IPython-dev] Ctrl-C quitting ipython
In-Reply-To: <201011031509.51051.hans_meine@gmx.net>
References: <201011011536.10871.hans_meine@gmx.net>
	<201011031509.51051.hans_meine@gmx.net>
Message-ID: <201011031649.45453.hans_meine@gmx.net>

Op den Middeweken 03 November 2010 Klock 15:09:50 hett Hans Meine schreven:
> The result: "Program exited with code 01." - looks like sys.exit(1) (or the
> equivalent in C in some library) being called.  Probably some extension
> installed a signal handler (we suspect openmesh).

Problem solved, it was "from enthought.tvtk.api import tvtk" which installed a 
SIGINT handler, and updating the ETS helped.

Sorry for the noise,
  Hans


From gael.varoquaux at normalesup.org  Wed Nov  3 11:51:04 2010
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 3 Nov 2010 16:51:04 +0100
Subject: [IPython-dev] Ctrl-C quitting ipython
In-Reply-To: <201011031649.45453.hans_meine@gmx.net>
References: <201011011536.10871.hans_meine@gmx.net>
	<201011031509.51051.hans_meine@gmx.net>
	<201011031649.45453.hans_meine@gmx.net>
Message-ID: <20101103155103.GI27927@phare.normalesup.org>

On Wed, Nov 03, 2010 at 04:49:45PM +0100, Hans Meine wrote:
> Op den Middeweken 03 November 2010 Klock 15:09:50 hett Hans Meine schreven:
> > The result: "Program exited with code 01." - looks like sys.exit(1) (or the
> > equivalent in C in some library) being called.  Probably some extension
> > installed a signal handler (we suspect openmesh).

> Problem solved, it was "from enthought.tvtk.api import tvtk" which installed a 
> SIGINT handler, and updating the ETS helped.

Ugly! How did updating ETS help? Is the SIGINT handler removed in the new
ETS?

Gael


From hans_meine at gmx.net  Wed Nov  3 12:08:03 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Wed, 3 Nov 2010 17:08:03 +0100
Subject: [IPython-dev] Ctrl-C quitting ipython
In-Reply-To: <20101103155103.GI27927@phare.normalesup.org>
References: <201011011536.10871.hans_meine@gmx.net>
	<201011031649.45453.hans_meine@gmx.net>
	<20101103155103.GI27927@phare.normalesup.org>
Message-ID: <201011031708.04141.hans_meine@gmx.net>

Op den Middeweken 03 November 2010 Klock 16:51:04 hett Gael Varoquaux 
schreven:
> On Wed, Nov 03, 2010 at 04:49:45PM +0100, Hans Meine wrote:
> > Op den Middeweken 03 November 2010 Klock 15:09:50 hett Hans Meine
> > schreven:
> > > The result: "Program exited with code 01." - looks like sys.exit(1) (or
> > > the equivalent in C in some library) being called.  Probably some
> > > extension installed a signal handler (we suspect openmesh).
> > 
> > Problem solved, it was "from enthought.tvtk.api import tvtk" which
> > installed a SIGINT handler, and updating the ETS helped.
> 
> Ugly! How did updating ETS help? Is the SIGINT handler removed in the new
> ETS?

I don't know the details, but that's my impression, yes.  Such are the risks 
of running software from development repositories, I guess... ;-)

Unfortunately, it's probably not possible to detect this within ipython, 
right?  After all, the SIGINT handler might also have played nice.  It would 
be interesting to know 

- whether we can detect and report signal handlers being installed
- whether that would be annoying (don't know how noisy the result would be)
- whether we can catch exit() being called and at least report "IPython 
noticed some extension/C-code called exit()", which would have at least 
reduced the debugging time for us

Greetings,
  Hans


From gael.varoquaux at normalesup.org  Wed Nov  3 12:26:11 2010
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 3 Nov 2010 17:26:11 +0100
Subject: [IPython-dev] Ctrl-C quitting ipython
In-Reply-To: <201011031708.04141.hans_meine@gmx.net>
References: <201011011536.10871.hans_meine@gmx.net>
	<201011031649.45453.hans_meine@gmx.net>
	<20101103155103.GI27927@phare.normalesup.org>
	<201011031708.04141.hans_meine@gmx.net>
Message-ID: <20101103162611.GL27927@phare.normalesup.org>

On Wed, Nov 03, 2010 at 05:08:03PM +0100, Hans Meine wrote:
> Unfortunately, it's probably not possible to detect this within ipython, 
> right?  After all, the SIGINT handler might also have played nice.  It would 
> be interesting to know 

> - whether we can detect and report signal handlers being installed
> - whether that would be annoying (don't know how noisy the result would be)
> - whether we can catch exit() being called and at least report "IPython 
> noticed some extension/C-code called exit()", which would have at least 
> reduced the debugging time for us

Yes, absolutely. There is also a logic with installing signal handlers,
and they may really bring in value. How to do this well is beyond my
expertise, I must admit, so I cannot comment at all.

Gael


From robert.kern at gmail.com  Wed Nov  3 15:01:21 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 03 Nov 2010 14:01:21 -0500
Subject: [IPython-dev] Ctrl-C quitting ipython
In-Reply-To: <201011031708.04141.hans_meine@gmx.net>
References: <201011011536.10871.hans_meine@gmx.net>	<201011031649.45453.hans_meine@gmx.net>	<20101103155103.GI27927@phare.normalesup.org>
	<201011031708.04141.hans_meine@gmx.net>
Message-ID: <iasbi3$pcb$1@dough.gmane.org>

On 11/3/10 11:08 AM, Hans Meine wrote:
> Op den Middeweken 03 November 2010 Klock 16:51:04 hett Gael Varoquaux
> schreven:
>> On Wed, Nov 03, 2010 at 04:49:45PM +0100, Hans Meine wrote:
>>> Op den Middeweken 03 November 2010 Klock 15:09:50 hett Hans Meine
>>> schreven:
>>>> The result: "Program exited with code 01." - looks like sys.exit(1) (or
>>>> the equivalent in C in some library) being called.  Probably some
>>>> extension installed a signal handler (we suspect openmesh).
>>>
>>> Problem solved, it was "from enthought.tvtk.api import tvtk" which
>>> installed a SIGINT handler, and updating the ETS helped.
>>
>> Ugly! How did updating ETS help? Is the SIGINT handler removed in the new
>> ETS?
>
> I don't know the details, but that's my impression, yes.  Such are the risks
> of running software from development repositories, I guess... ;-)
>
> Unfortunately, it's probably not possible to detect this within ipython,
> right?  After all, the SIGINT handler might also have played nice.  It would
> be interesting to know

> - whether we can detect and report signal handlers being installed

You can get any Python-installed handler using signal.getsignal(signal.SIGINT). 
I don't know if you can determine C-installed handlers. Would you mind reverting 
to your previous version of ETS to see if getsignal() returns you anything? I 
don't think we ever installed a handler directly in ETS, but VTK or your GUI 
toolkit might have. Did you update either of those along with ETS?

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



From fperez.net at gmail.com  Thu Nov  4 00:58:48 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Nov 2010 21:58:48 -0700
Subject: [IPython-dev] Sockets by name, adding a control socket...
Message-ID: <AANLkTimB_B7nt_vYScB+P7XoU8NbgpC+95xSQ24JBnBS@mail.gmail.com>

Hi folks,

[ sorry for not having replied to a few mails on the list and starting
a new thread, I'm trying to avoid bottlenecking Min right now.  I'll
catch up with the list asap]

Min and I today had a long discussion about the messaging spec and our
sockets, with an eye towards harmonizing as much as possible the
design of the kernels in the parallel code with that of the
interactive one (as those guys will get merged hopefully soon).

As usual, this is all based on our reference doc:
http://ipython.scipy.org/doc/nightly/html/development/messaging.html

There are two main points:

1. Our 'XREP' socket does too much, and it would be cleaner if we
break it into two.  Right now that socket manages both control
commands (liek connect or shutdown) and things related to user
'shell-like' activity (code execution, object info, history, etc).  In
the parallel code Min uses a separate control socket, and it seems
clear we should do the same here.  So the plan would be to have two
sockets (we'll get to the names later):

XREP-a: used for
- code execution
- object info
- completion
- history
- anything else that could come up in the future that's along these
lines (i.e. mostly user namespace-related manipulations)

XREP-b: used for:
- connect
- shutdown
- abort
- kernel attribute access
- other kernel-specific manipulations


2. We should name all of our sockets based on what they do, not on the
zmq socket type they use.  Min and I scribbled a bunch on paper and
came up with:

- XREP-a: 'shell'.   It handles all the things that are 'shell-like'.
- XREP-b: 'control'. It handles all kernel control stuff.
- PUB: 'iopub'.  This publishes the i/o streams.
- REQ: 'kstdin'. This is the socket that forwards the kernel's stdin
when needed.
- 'heartbeat': can stay, it's already named by function and not by type

Variations, suggestions, etc, all welcome.

We think Min will start updating the parallel code to follow this
convention, minor tweaks can always be made later but I doubt we'll
want to make major changes.  But feedback on the names is welcome, if
anyone has any.

Cheers,

f


From ellisonbg at gmail.com  Thu Nov  4 01:11:40 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Wed, 3 Nov 2010 22:11:40 -0700
Subject: [IPython-dev] Sockets by name, adding a control socket...
In-Reply-To: <AANLkTimB_B7nt_vYScB+P7XoU8NbgpC+95xSQ24JBnBS@mail.gmail.com>
References: <AANLkTimB_B7nt_vYScB+P7XoU8NbgpC+95xSQ24JBnBS@mail.gmail.com>
Message-ID: <AANLkTi=yXdKh7RjtYnH_pcw5PkcyoZmbBYP-wdxajNQh@mail.gmail.com>

On Wed, Nov 3, 2010 at 9:58 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi folks,
>
> [ sorry for not having replied to a few mails on the list and starting
> a new thread, I'm trying to avoid bottlenecking Min right now. ?I'll
> catch up with the list asap]
>
> Min and I today had a long discussion about the messaging spec and our
> sockets, with an eye towards harmonizing as much as possible the
> design of the kernels in the parallel code with that of the
> interactive one (as those guys will get merged hopefully soon).
>
> As usual, this is all based on our reference doc:
> http://ipython.scipy.org/doc/nightly/html/development/messaging.html
>
> There are two main points:
>
> 1. Our 'XREP' socket does too much, and it would be cleaner if we
> break it into two. ?Right now that socket manages both control
> commands (liek connect or shutdown) and things related to user
> 'shell-like' activity (code execution, object info, history, etc). ?In
> the parallel code Min uses a separate control socket, and it seems
> clear we should do the same here. ?So the plan would be to have two
> sockets (we'll get to the names later):
>
> XREP-a: used for
> - code execution
> - object info
> - completion
> - history
> - anything else that could come up in the future that's along these
> lines (i.e. mostly user namespace-related manipulations)
>
> XREP-b: used for:
> - connect
> - shutdown
> - abort
> - kernel attribute access
> - other kernel-specific manipulations

The connect/shutdown/abort logic does seem to to together, but kernel
attribute access seems to go with the XREP-a things.  For the parallel
stuff, the different between these two types of XREP channels makes
sense, because they are talking to different processes.  But here, it
is just 1 process, so I am not sure it makes sense.  I am a little
concerned about un-needed proliferation of channels.

>
> 2. We should name all of our sockets based on what they do, not on the
> zmq socket type they use. ?Min and I scribbled a bunch on paper and
> came up with:
>
> - XREP-a: 'shell'. ? It handles all the things that are 'shell-like'.
> - XREP-b: 'control'. It handles all kernel control stuff.
> - PUB: 'iopub'. ?This publishes the i/o streams.
> - REQ: 'kstdin'. This is the socket that forwards the kernel's stdin
> when needed.
> - 'heartbeat': can stay, it's already named by function and not by type

Yep, we definitely need better names.  Some comments:

> - XREP-a: 'shell'. ? It handles all the things that are 'shell-like'.
> - XREP-b: 'control'. It handles all kernel control stuff.

Both of these are pretty good if we separate the XREP channel into 2.

> - PUB: 'iopub'. ?This publishes the i/o streams.

But we publish more than the io streams on this channel.  In reality,
it is for sideeffects, so would that name make sense.

> - REQ: 'kstdin'. This is the socket that forwards the kernel's stdin

I think he "k" is a bit too short and confusing.  Maybe kernelstdin?
Or just stdin?



> Variations, suggestions, etc, all welcome.
>
> We think Min will start updating the parallel code to follow this
> convention, minor tweaks can always be made later but I doubt we'll
> want to make major changes. ?But feedback on the names is welcome, if
> anyone has any.

Great, glad you were able to talk about this.

Cheers,

Brian

> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com


From fperez.net at gmail.com  Thu Nov  4 01:28:53 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Nov 2010 22:28:53 -0700
Subject: [IPython-dev] Sockets by name, adding a control socket...
In-Reply-To: <AANLkTi=yXdKh7RjtYnH_pcw5PkcyoZmbBYP-wdxajNQh@mail.gmail.com>
References: <AANLkTimB_B7nt_vYScB+P7XoU8NbgpC+95xSQ24JBnBS@mail.gmail.com>
	<AANLkTi=yXdKh7RjtYnH_pcw5PkcyoZmbBYP-wdxajNQh@mail.gmail.com>
Message-ID: <AANLkTinZ4z+DfhNCjPHOs8syAep=mbFgf1z3MabyjCiN@mail.gmail.com>

On Wed, Nov 3, 2010 at 10:11 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> The connect/shutdown/abort logic does seem to to together, but kernel
> attribute access seems to go with the XREP-a things. ?For the parallel
> stuff, the different between these two types of XREP channels makes
> sense, because they are talking to different processes. ?But here, it
> is just 1 process, so I am not sure it makes sense. ?I am a little
> concerned about un-needed proliferation of channels.

Our reasoning for putting attribute access there was to keep the -a
socket strictly for things the user would normally see in his regular
namespace, and -b for things that had to do with manipulating the
kernel object itself.  While it's true that one can get the kernel via
'ip = get_ipython()' and start working on it, that's not the "regular"
mode of operation in most user activities.

And Min brought up a compelling point for wanting the separate kernel
control channel: so that things like abort commands can jump to the
front of the queue.  This will become more important once the web
notebook makes it natural to queue up multiple cells for execution,
for example.

And once we update the connection logic to use the mechanism Min has
with a single socket for initial connection and all others
auto-negotiated after that, having one more socket shouldn't be too
big of a deal.  I do agree with you that we don't want these things
growing like dandelions, but I don't think we have too many more in
store, to me this seems like a reasonably complete coverage of what we
need.

>> - PUB: 'iopub'. ?This publishes the i/o streams.
>
> But we publish more than the io streams on this channel. ?In reality,
> it is for sideeffects, so would that name make sense.

We thought about that but it seemed a little too long... And we looked
at the actual list of what goes there, right now we have:

# Streams (stdout, stderr, etc)
# Python inputs
# Python outputs
# Python errors
# Kernel status
# Kernel crashes

It seemed like most of this was the kind of thing that normally shows
up on i/o streams at a console/log, so while not literally being
stdout/err, 'iopub' seemed like a reasonable, and short, way to
describe 'publish all i/o activity produced by the kernel'.  I/O is
more or less by definition a side effect (which is why functional
languages typically have to do something a bit odd to provide it, as
it doesn't really fit into a purely functional paradigm)...

But if this justification doesn't convince you, I'm happy to
reconsider (though I'd like to find something a little shorter than
side_effects, we're likely to use these names a lot everywhere...).

>> - REQ: 'kstdin'. This is the socket that forwards the kernel's stdin
>
> I think he "k" is a bit too short and confusing. ?Maybe kernelstdin?
> Or just stdin?

Yes, the k alone didn't seem very nice.  kernel_stdin?  (In general, I
think we should avoid run-in words without underscores as much as
possible).  It's a bit long but this one isn't likely to be used
super-often, and I think it's a good idea to keep explicit the fact
that this one is a special socket handling something from the kernel,
rather than client-side stdin.

Thanks for the feedback!

Cheers,

f


From fperez.net at gmail.com  Thu Nov  4 02:17:50 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Nov 2010 23:17:50 -0700
Subject: [IPython-dev] Ctrl-C quitting ipython
In-Reply-To: <iasbi3$pcb$1@dough.gmane.org>
References: <201011011536.10871.hans_meine@gmx.net>
	<201011031649.45453.hans_meine@gmx.net>
	<20101103155103.GI27927@phare.normalesup.org>
	<201011031708.04141.hans_meine@gmx.net>
	<iasbi3$pcb$1@dough.gmane.org>
Message-ID: <AANLkTikAN_v99qDdXABk2kz-vXYF=xvNPZOZgs+CC_Kj@mail.gmail.com>

On Wed, Nov 3, 2010 at 12:01 PM, Robert Kern <robert.kern at gmail.com> wrote:
>
> You can get any Python-installed handler using signal.getsignal(signal.SIGINT).
> I don't know if you can determine C-installed handlers. Would you mind reverting

No, you can't, unfortunately:

http://svn.python.org/view/python/branches/release27-maint/Modules/signalmodule.c?revision=85145&view=markup

if you scroll down to getsignal, you'll see that it just reads from a
global table it keeps, which is filled by signal().  A C-installed
handler can call the raw PyOS_setsig() without updating the table, and
getsignal() will be none the wiser.

Cheers,

f


From fperez.net at gmail.com  Thu Nov  4 02:19:41 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Nov 2010 23:19:41 -0700
Subject: [IPython-dev] Ctrl-C quitting ipython
In-Reply-To: <201011031708.04141.hans_meine@gmx.net>
References: <201011011536.10871.hans_meine@gmx.net>
	<201011031649.45453.hans_meine@gmx.net>
	<20101103155103.GI27927@phare.normalesup.org>
	<201011031708.04141.hans_meine@gmx.net>
Message-ID: <AANLkTi=v-2xEQa+he0vC2Wjz7PUUsgqNhn_E1fsQV_mt@mail.gmail.com>

On Wed, Nov 3, 2010 at 9:08 AM, Hans Meine <hans_meine at gmx.net> wrote:
> - whether we can detect and report signal handlers being installed

One could monkeypatch signal to catch and report signal.signal()
calls, but that's about it.  As I said in my prior reply, C code can
install handlers we'll never know about.

> - whether that would be annoying (don't know how noisy the result would be)
> - whether we can catch exit() being called and at least report "IPython
> noticed some extension/C-code called exit()", which would have at least
> reduced the debugging time for us

Nope, unfortunately there's no way to catch that, to the best of my
knowledge (would love to be proven wrong, though).

Cheers,

f


From fperez.net at gmail.com  Thu Nov  4 02:26:50 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Nov 2010 23:26:50 -0700
Subject: [IPython-dev] filename completion - anyone working on it?
In-Reply-To: <201011011055.27196.hans_meine@gmx.net>
References: <201010261531.56428.hans_meine@gmx.net>
	<AANLkTi=B_zmNoVzeoJEQ9UeHLi76ndtvOw2ti921uuSZ@mail.gmail.com>
	<201011011055.27196.hans_meine@gmx.net>
Message-ID: <AANLkTimM=DLfrVDsp+5f6UDSx4v+rWetFOcVTVRUkdWF@mail.gmail.com>

Hi Hans,

On Mon, Nov 1, 2010 at 2:55 AM, Hans Meine <hans_meine at gmx.net> wrote:
>> Could you pull from trunk and let me know if you find the situation
>> any better? ?Invoking my time machine for your question, I rewound to
>> yesterday afternoon and put more time than I'd like to admit into this
>> very problem:
>
> Aaah, I love it when you pull that trick! :-)

:)

>> Things already work as you imagine, with a custom completer for magics
>> without quotes, and a generic file completer that should work in
>> strings. ?This weekend John and I actually ran into the limitations of
>> the completions-in-strings, and that prompted my effort to fix this.
>
> The strange thing is - I updated my git repo and tried it out, and it was
> certainly working to some extent (read: at least some completions I tried with
> paths containing spaces did work, so I was happy). ?I planned to try it out
> more thoroughly for some days before reporting back, but right now I tried
> again (with updated git master), and it does not work at all anymore?!

I'm afraid I must run now (will try to continue tomorrow), but in the
meantime...

> Is there a good way to debug these kind of things? (completion)
> I would like to contribute test cases, but they would obviously require some
> temp. dir setup, and I don't know yet how to write good unit tests for this.

Yes, again my time machine at your service:

https://github.com/ipython/ipython/commit/ae65e73c8ec9564613aaa9acd3868b9fe15f9c63

That was added *precisely* for doing what you want (that time machine
is accurate, to boot :)

https://github.com/ipython/ipython/commit/02eecaf061408f26a3c6029886b8794f73581938

Hopefully that commit shows you the kind of code that's needed for
completions.  Debugging completion code is annoying, it typically
involves activating a bunch of print statements that you'll find in
the core/completer.py file, and likely turning on this debug flag:

https://github.com/ipython/ipython/blob/master/IPython/core/completer.py#L858

so that you can see exceptions that are otherwise silently gobbled up
by readline.

I hope this gets you started, and please don't hesitate to pester me.
Yell loud enough, I'll end up answering ;)  I'm really sorry not to be
more responsive, but 'real life' calls sometimes :)

Cheers,

f


From hans_meine at gmx.net  Thu Nov  4 09:37:33 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Thu, 4 Nov 2010 14:37:33 +0100
Subject: [IPython-dev] Ctrl-C quitting ipython
In-Reply-To: <AANLkTi=v-2xEQa+he0vC2Wjz7PUUsgqNhn_E1fsQV_mt@mail.gmail.com>
References: <201011011536.10871.hans_meine@gmx.net>
	<201011031708.04141.hans_meine@gmx.net>
	<AANLkTi=v-2xEQa+he0vC2Wjz7PUUsgqNhn_E1fsQV_mt@mail.gmail.com>
Message-ID: <201011041437.33559.hans_meine@gmx.net>

Op den Dunnersdag 04 November 2010 Klock 07:19:41 hett Fernando Perez 
schreven:
> > - whether that would be annoying (don't know how noisy the result would
> > be) - whether we can catch exit() being called and at least report
> > "IPython noticed some extension/C-code called exit()", which would have
> > at least reduced the debugging time for us
> 
> Nope, unfortunately there's no way to catch that, to the best of my
> knowledge (would love to be proven wrong, though).

There would be a way with C code, but that's against ipython's design AFAICS:
One could write a tiny extension that uses atexit(3) to register a handler 
which prints a warning after checking a flag whether the exit was expected 
(initiated from IPython).

To a certain degree, it is possible to do the same with ctypes, but AFAICS the 
case in which python was shut down would make problems (since the handler 
would be implemented in python code, but the interpreter will already be shut 
down).

At least, sys.exit() / SystemExit is already caught.  However, I find it 
strange that %tb is announced, while it does not give a valuable result:

In [6]: sys.exit()
An exception has occurred, use %tb to see the full traceback.

SystemExit

To exit: use any of 'exit', 'quit', %Exit or Ctrl-D.

In [7]: %tb
---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)
IndexError: list index out of range

Have a nice day,
  Hans


From hans_meine at gmx.net  Fri Nov  5 12:10:37 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Fri, 5 Nov 2010 17:10:37 +0100
Subject: [IPython-dev] Ctrl-C quitting ipython
In-Reply-To: <iasbi3$pcb$1@dough.gmane.org>
References: <201011011536.10871.hans_meine@gmx.net>
	<201011031708.04141.hans_meine@gmx.net>
	<iasbi3$pcb$1@dough.gmane.org>
Message-ID: <201011051710.37535.hans_meine@gmx.net>

Hi Robert!

Op den Middeweken 03 November 2010 Klock 20:01:21 hett Robert Kern schreven:
> You can get any Python-installed handler using
> signal.getsignal(signal.SIGINT). I don't know if you can determine
> C-installed handlers.

I was thinking about the latter, but obviously there's no API for that.

> Would you mind reverting to your previous version of
> ETS to see if getsignal() returns you anything?

I don't know if Chris can recover which revision he had checked out last time 
(and that was probably months ago).

> I don't think we ever
> installed a handler directly in ETS, but VTK or your GUI toolkit might
> have. Did you update either of those along with ETS?

I don't think so, or did you, Chris?  I just saw him updating his ETS 
checkout.

Since this has been fixed, I hope it is not too important anymore.

Have a nice weekend,
  Hans


From jdh2358 at gmail.com  Mon Nov 15 06:57:50 2010
From: jdh2358 at gmail.com (John Hunter)
Date: Mon, 15 Nov 2010 05:57:50 -0600
Subject: [IPython-dev] check_for_gtk fails with no X11 in 0.10.1
Message-ID: <AANLkTikdXL9dtcmWfStn6zmFsQK2eHdw_sbSMUdXkHXC@mail.gmail.com>

I am unable to use ipython 0.10.1 in a screen session (no X11) because
it fails with the following traceback (included below).   Fernando
initially told me he thought this bug was fixed in 0.10.1 but
apparently not for all cases.  Here is my clean install log

johnh@:~> cd tmp
johnh@:tmp> rm -rf ipython-0.10.1
~/dev/lib/python2.4/site-packages/IPython/ ipython-0.10.1.tar.gz
johnh@:tmp> wget http://ipython.scipy.org/dist/0.10.1/ipython-0.10.1.tar.gz
--05:44:48--  http://ipython.scipy.org/dist/0.10.1/ipython-0.10.1.tar.gz
johnh@:tmp> tar xvfz ipython-0.10.1.tar.gz
...snip
ipython-0.10.1/setupegg.py
ipython-0.10.1/README.txt
ipython-0.10.1/setupbase.py
johnh@:ipython-0.10.1> python setup.py install --prefix=~/dev
...snip
changing mode of /home/titan/johnh/dev/bin/pycolor to 755
changing mode of /home/titan/johnh/dev/bin/irunner to 755
changing mode of /home/titan/johnh/dev/bin/iptest to 755
running install_data
johnh@:~> PYTHONPATH=~/dev/lib/python2.4/site-packages/ ~/dev/bin/ipython
Python 2.4.5 (#4, Apr 12 2008, 09:09:16)
Type "copyright", "credits" or "license" for more information.

IPython 0.10.1 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints mo\
re.

In [1]:


So far so good, but now see what happens when gtk is in my path....

johnh@:~> PYTHONPATH=~/dev/lib/python2.4/site-packages/:/opt/app/g++lib6/python-2.4/lib/python2.4/site-packages/3rdParty/gtk-2.6
~/dev/bin/ipython
Xlib: connection to "localhost:14.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Traceback (most recent call last):
  File "/home/titan/johnh/dev/bin/ipython", line 28, in ?
    IPython.Shell.start().mainloop()
  File "/home/titan/johnh/dev/lib/python2.4/site-packages/IPython/Shell.py",
line 1258, in start
    shell = _select_shell(sys.argv)
  File "/home/titan/johnh/dev/lib/python2.4/site-packages/IPython/Shell.py",
line 1246, in _select_shell
    th_mode = check_gtk(th_mode)
  File "/home/titan/johnh/dev/lib/python2.4/site-packages/IPython/Shell.py",
line 1154, in check_gtk
    import gtk
  File "/opt/app/g++lib6/python-2.4/lib/python2.4/site-packages/3rdParty/gtk-2.6/gtk/__init__.py",
line 37, in ?
    from _gtk import *
RuntimeError: could not open display


Adding the RuntimeError exception to check_gtk.py works for me --
sorry for simply pasting int he amended function but I do not have a
git branch checked out here.  It is just the inclusion of the two
except RuntimeError lines that is needed.  This may be a gtk version
difference -- some versions may throw a RuntimeError and some may
throw and ImporError --welcome to my world :-)

# amened function in Shell.py:

def check_gtk(mode):
    try:
        import gtk
    except ImportError:
        return mode
    except RuntimeError:
        return mode
    if hasattr(gtk,'set_interactive'):
        gtk.set_interactive(False)
        return 'tkthread'
    else:
        return mode


From fperez.net at gmail.com  Mon Nov 15 17:58:33 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 15 Nov 2010 14:58:33 -0800
Subject: [IPython-dev] check_for_gtk fails with no X11 in 0.10.1
In-Reply-To: <AANLkTikdXL9dtcmWfStn6zmFsQK2eHdw_sbSMUdXkHXC@mail.gmail.com>
References: <AANLkTikdXL9dtcmWfStn6zmFsQK2eHdw_sbSMUdXkHXC@mail.gmail.com>
Message-ID: <AANLkTikXHGwDHFAWyTZuhGEEwdRPXwC-N1wD55OuH2RX@mail.gmail.com>

Hey John,

On Mon, Nov 15, 2010 at 3:57 AM, John Hunter <jdh2358 at gmail.com> wrote:
> I am unable to use ipython 0.10.1 in a screen session (no X11) because
> it fails with the following traceback (included below). ? Fernando
> initially told me he thought this bug was fixed in 0.10.1 but
> apparently not for all cases.

sorry to have misled you, my memory failed me.  I had fixed the bug in
the  0.10.2 branch (soon to be released):

https://github.com/ipython/ipython/commit/8161523536289eaed01ca42707f6785f59343cd7

not in 0.10.1 as I originally said.

If you download the current state of 0.10.2 from

https://github.com/ipython/ipython/tarball/0.10.2

(in case you don't have a git checkout of the full repo handy) you should be OK.

Let me know if it works, and apologies for the confusion.

Cheers,

f


From tomspur at fedoraproject.org  Tue Nov 16 04:43:03 2010
From: tomspur at fedoraproject.org (Thomas Spura)
Date: Tue, 16 Nov 2010 10:43:03 +0100
Subject: [IPython-dev] check_for_gtk fails with no X11 in 0.10.1
In-Reply-To: <AANLkTikXHGwDHFAWyTZuhGEEwdRPXwC-N1wD55OuH2RX@mail.gmail.com>
References: <AANLkTikdXL9dtcmWfStn6zmFsQK2eHdw_sbSMUdXkHXC@mail.gmail.com>
	<AANLkTikXHGwDHFAWyTZuhGEEwdRPXwC-N1wD55OuH2RX@mail.gmail.com>
Message-ID: <20101116104303.0da97ee5@moon>

On Mon, 15 Nov 2010 14:58:33 -0800
Fernando Perez wrote:

> Hey John,
> 
> On Mon, Nov 15, 2010 at 3:57 AM, John Hunter <jdh2358 at gmail.com>
> wrote:
> > I am unable to use ipython 0.10.1 in a screen session (no X11)
> > because it fails with the following traceback (included below).
> > Fernando initially told me he thought this bug was fixed in 0.10.1
> > but apparently not for all cases.
> 
> sorry to have misled you, my memory failed me.  I had fixed the bug in
> the  0.10.2 branch (soon to be released):
> 
> https://github.com/ipython/ipython/commit/8161523536289eaed01ca42707f6785f59343cd7
> 
> not in 0.10.1 as I originally said.
> 
> If you download the current state of 0.10.2 from
> 
> https://github.com/ipython/ipython/tarball/0.10.2
> 
> (in case you don't have a git checkout of the full repo handy) you
> should be OK.
> 
> Let me know if it works, and apologies for the confusion.

I backported the fix to 0.10.1 and according to the original reporter,
this is fixed now:
https://admin.fedoraproject.org/updates/ipython-0.10.1-3.fc14

Thanks.
   Thomas


From satra at mit.edu  Tue Nov 16 10:31:08 2010
From: satra at mit.edu (Satrajit Ghosh)
Date: Tue, 16 Nov 2010 10:31:08 -0500
Subject: [IPython-dev] condor support in ipython 0.1x.y
Message-ID: <AANLkTi=rvc1TH9jjByxb_sBGs89k_sB8uJFJzq2ECPKL@mail.gmail.com>

hi all,

a. does ipython support condor in 0.10.x (it seems not) and is there a plan
for it in 0.11.x?
b. does anybody on this list have experience with sge/pbs and condor? i
would like to know if the operating mechanisms are similar to the extent we
can create a wrapper for some subset of condor functionality.

cheers,

satra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101116/38f27729/attachment.html>

From ellisonbg at gmail.com  Tue Nov 16 14:09:55 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 16 Nov 2010 11:09:55 -0800
Subject: [IPython-dev] condor support in ipython 0.1x.y
In-Reply-To: <AANLkTi=rvc1TH9jjByxb_sBGs89k_sB8uJFJzq2ECPKL@mail.gmail.com>
References: <AANLkTi=rvc1TH9jjByxb_sBGs89k_sB8uJFJzq2ECPKL@mail.gmail.com>
Message-ID: <AANLkTikuG-ODznbce0s043XJRyYcpkqKRvY2HAH_aGBh@mail.gmail.com>

Satra,

a. does ipython support condor in 0.10.x (it seems not) and is there a plan
> for it in 0.11.x?
>

Not in 0.10 yet, and 0.11 is still undergoing heavy development.  But,
supporting condor is a great idea, especially as sge is no longer  open
source.


> b. does anybody on this list have experience with sge/pbs and condor? i
> would like to know if the operating mechanisms are similar to the extent we
> can create a wrapper for some subset of condor functionality.
>
>
I don't have any experience with condor as of yet.

Brian


> cheers,
>
> satra
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101116/9e1750be/attachment.html>

From ellisonbg at gmail.com  Tue Nov 16 17:46:34 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 16 Nov 2010 14:46:34 -0800
Subject: [IPython-dev] Sockets by name, adding a control socket...
In-Reply-To: <AANLkTinZ4z+DfhNCjPHOs8syAep=mbFgf1z3MabyjCiN@mail.gmail.com>
References: <AANLkTimB_B7nt_vYScB+P7XoU8NbgpC+95xSQ24JBnBS@mail.gmail.com>
	<AANLkTi=yXdKh7RjtYnH_pcw5PkcyoZmbBYP-wdxajNQh@mail.gmail.com>
	<AANLkTinZ4z+DfhNCjPHOs8syAep=mbFgf1z3MabyjCiN@mail.gmail.com>
Message-ID: <AANLkTi=CUEgkF09K8-ZSaMiL5vy0rm6FmL6Gs1FZBgeu@mail.gmail.com>

Boy I am busy these days...continuing on...

On Wed, Nov 3, 2010 at 10:28 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Wed, Nov 3, 2010 at 10:11 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> > The connect/shutdown/abort logic does seem to to together, but kernel
> > attribute access seems to go with the XREP-a things.  For the parallel
> > stuff, the different between these two types of XREP channels makes
> > sense, because they are talking to different processes.  But here, it
> > is just 1 process, so I am not sure it makes sense.  I am a little
> > concerned about un-needed proliferation of channels.
>
> Our reasoning for putting attribute access there was to keep the -a
> socket strictly for things the user would normally see in his regular
> namespace, and -b for things that had to do with manipulating the
> kernel object itself.  While it's true that one can get the kernel via
> 'ip = get_ipython()' and start working on it, that's not the "regular"
> mode of operation in most user activities.
>
>
But wouldn't both XREP channels probe the users namespace?


> And Min brought up a compelling point for wanting the separate kernel
> control channel: so that things like abort commands can jump to the
> front of the queue.  This will become more important once the web
> notebook makes it natural to queue up multiple cells for execution,
> for example.
>
>
Yes, that does make sense.  But then I think that the control channel should
*never* touch the user's namespace.


> And once we update the connection logic to use the mechanism Min has
> with a single socket for initial connection and all others
> auto-negotiated after that, having one more socket shouldn't be too
> big of a deal.  I do agree with you that we don't want these things
> growing like dandelions, but I don't think we have too many more in
> store, to me this seems like a reasonably complete coverage of what we
> need.
>
>
I am not too sure of this.  If you think about remote connections, this is 1
more firewall port that has to be opened.  Also 1 more point of security...


> >> - PUB: 'iopub'.  This publishes the i/o streams.
> >
> > But we publish more than the io streams on this channel.  In reality,
> > it is for sideeffects, so would that name make sense.
>
> We thought about that but it seemed a little too long... And we looked
> at the actual list of what goes there, right now we have:
>
> # Streams (stdout, stderr, etc)
> # Python inputs
> # Python outputs
> # Python errors
> # Kernel status
> # Kernel crashes
>
> It seemed like most of this was the kind of thing that normally shows
> up on i/o streams at a console/log, so while not literally being
> stdout/err, 'iopub' seemed like a reasonable, and short, way to
> describe 'publish all i/o activity produced by the kernel'.  I/O is
> more or less by definition a side effect (which is why functional
> languages typically have to do something a bit odd to provide it, as
> it doesn't really fit into a purely functional paradigm)...
>
>
I just think that IO is too limiting because of our moving the payload to
this channel.  So maybe:

datapub?


> But if this justification doesn't convince you, I'm happy to
> reconsider (though I'd like to find something a little shorter than
> side_effects, we're likely to use these names a lot everywhere...).
>
> >> - REQ: 'kstdin'. This is the socket that forwards the kernel's stdin
> >
> > I think he "k" is a bit too short and confusing.  Maybe kernelstdin?
> > Or just stdin?
>
> Yes, the k alone didn't seem very nice.  kernel_stdin?  (In general, I
> think we should avoid run-in words without underscores as much as
> possible).  It's a bit long but this one isn't likely to be used
> super-often, and I think it's a good idea to keep explicit the fact
> that this one is a special socket handling something from the kernel,
> rather than client-side stdin.
>
>
Yes, I think that kernel_stdin is better.

Cheers,

Brian


> Thanks for the feedback!
>
> Cheers,
>
> f
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101116/50d39948/attachment.html>

From benjaminrk at gmail.com  Tue Nov 16 18:51:10 2010
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 16 Nov 2010 15:51:10 -0800
Subject: [IPython-dev] Sockets by name, adding a control socket...
In-Reply-To: <AANLkTi=CUEgkF09K8-ZSaMiL5vy0rm6FmL6Gs1FZBgeu@mail.gmail.com>
References: <AANLkTimB_B7nt_vYScB+P7XoU8NbgpC+95xSQ24JBnBS@mail.gmail.com>
	<AANLkTi=yXdKh7RjtYnH_pcw5PkcyoZmbBYP-wdxajNQh@mail.gmail.com>
	<AANLkTinZ4z+DfhNCjPHOs8syAep=mbFgf1z3MabyjCiN@mail.gmail.com>
	<AANLkTi=CUEgkF09K8-ZSaMiL5vy0rm6FmL6Gs1FZBgeu@mail.gmail.com>
Message-ID: <AANLkTikYUi7=owz95FCou963+YDaucPWn+0vMNcSO+cc@mail.gmail.com>

On Tue, Nov 16, 2010 at 14:46, Brian Granger <ellisonbg at gmail.com> wrote:

> Boy I am busy these days...continuing on...
>
> On Wed, Nov 3, 2010 at 10:28 PM, Fernando Perez <fperez.net at gmail.com>wrote:
>
>> On Wed, Nov 3, 2010 at 10:11 PM, Brian Granger <ellisonbg at gmail.com>
>> wrote:
>> > The connect/shutdown/abort logic does seem to to together, but kernel
>> > attribute access seems to go with the XREP-a things.  For the parallel
>> > stuff, the different between these two types of XREP channels makes
>> > sense, because they are talking to different processes.  But here, it
>> > is just 1 process, so I am not sure it makes sense.  I am a little
>> > concerned about un-needed proliferation of channels.
>>
>> Our reasoning for putting attribute access there was to keep the -a
>> socket strictly for things the user would normally see in his regular
>> namespace, and -b for things that had to do with manipulating the
>> kernel object itself.  While it's true that one can get the kernel via
>> 'ip = get_ipython()' and start working on it, that's not the "regular"
>> mode of operation in most user activities.
>>
>>
> But wouldn't both XREP channels probe the users namespace?
>

No. Control does: connect, shutdown/kill/signal, abort, and access *kernel*
properties, never touching the user namespace.


>
>
>> And Min brought up a compelling point for wanting the separate kernel
>> control channel: so that things like abort commands can jump to the
>> front of the queue.  This will become more important once the web
>> notebook makes it natural to queue up multiple cells for execution,
>> for example.
>>
>>
> Yes, that does make sense.  But then I think that the control channel
> should *never* touch the user's namespace.
>

I don't think we have proposed that it does, but you are right, it
shouldn't.


>
>
>> And once we update the connection logic to use the mechanism Min has
>> with a single socket for initial connection and all others
>> auto-negotiated after that, having one more socket shouldn't be too
>> big of a deal.  I do agree with you that we don't want these things
>> growing like dandelions, but I don't think we have too many more in
>> store, to me this seems like a reasonably complete coverage of what we
>> need.
>>
>>
> I am not too sure of this.  If you think about remote connections, this is
> 1 more firewall port that has to be opened.  Also 1 more point of
> security...
>

>
>>  >> - PUB: 'iopub'.  This publishes the i/o streams.
>> >
>> > But we publish more than the io streams on this channel.  In reality,
>> > it is for sideeffects, so would that name make sense.
>>
>> We thought about that but it seemed a little too long... And we looked
>> at the actual list of what goes there, right now we have:
>>
>> # Streams (stdout, stderr, etc)
>> # Python inputs
>> # Python outputs
>> # Python errors
>> # Kernel status
>> # Kernel crashes
>>
>> It seemed like most of this was the kind of thing that normally shows
>> up on i/o streams at a console/log, so while not literally being
>> stdout/err, 'iopub' seemed like a reasonable, and short, way to
>> describe 'publish all i/o activity produced by the kernel'.  I/O is
>> more or less by definition a side effect (which is why functional
>> languages typically have to do something a bit odd to provide it, as
>> it doesn't really fit into a purely functional paradigm)...
>>
>>
> I just think that IO is too limiting because of our moving the payload to
> this channel.  So maybe:
>
> datapub?
>

I'm fine with something other than iopub, but I still think it's the most
descriptive.  What goes in the payload that is not IO?  Plots absolutely are
IO. Maybe not stdio, but IO nonetheless.

I'm not entirely sure that just 'pub' is inappropriate here, since it's the
general purpose publish socket.  So far, all of what it publishes is IO, as
far as I know, but there could be future side effects that might not be
considered IO.  If for some reason we later need to add another pub socket,
presumably that will be because it has a function distinct from general
publishing, and will have a more readily available descriptive name.


>
>
>> But if this justification doesn't convince you, I'm happy to
>> reconsider (though I'd like to find something a little shorter than
>> side_effects, we're likely to use these names a lot everywhere...).
>>
>> >> - REQ: 'kstdin'. This is the socket that forwards the kernel's stdin
>> >
>> > I think he "k" is a bit too short and confusing.  Maybe kernelstdin?
>> > Or just stdin?
>>
>> Yes, the k alone didn't seem very nice.  kernel_stdin?  (In general, I
>> think we should avoid run-in words without underscores as much as
>> possible).  It's a bit long but this one isn't likely to be used
>> super-often, and I think it's a good idea to keep explicit the fact
>> that this one is a special socket handling something from the kernel,
>> rather than client-side stdin.
>>
>>
> Yes, I think that kernel_stdin is better.
>

kernel_stdin is a fine name, and certainly explicit, as long as the
'kernel_' doesn't propagate to the kernel object itself.
 Kernel.kernel_stdin certainly should never happen, but:

KernelManager.kernel_stdin/KernelStdInChannel
and
Kernel.stdin

will work fine.


>
> Cheers,
>
> Brian
>
>
>> Thanks for the feedback!
>>
>> Cheers,
>>
>> f
>>
>
>
>
> --
> Brian E. Granger, Ph.D.
> Assistant Professor of Physics
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu
> ellisonbg at gmail.com
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101116/2ce2dae1/attachment.html>

From ellisonbg at gmail.com  Tue Nov 16 21:57:50 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 16 Nov 2010 18:57:50 -0800
Subject: [IPython-dev] Sockets by name, adding a control socket...
In-Reply-To: <AANLkTikYUi7=owz95FCou963+YDaucPWn+0vMNcSO+cc@mail.gmail.com>
References: <AANLkTimB_B7nt_vYScB+P7XoU8NbgpC+95xSQ24JBnBS@mail.gmail.com>
	<AANLkTi=yXdKh7RjtYnH_pcw5PkcyoZmbBYP-wdxajNQh@mail.gmail.com>
	<AANLkTinZ4z+DfhNCjPHOs8syAep=mbFgf1z3MabyjCiN@mail.gmail.com>
	<AANLkTi=CUEgkF09K8-ZSaMiL5vy0rm6FmL6Gs1FZBgeu@mail.gmail.com>
	<AANLkTikYUi7=owz95FCou963+YDaucPWn+0vMNcSO+cc@mail.gmail.com>
Message-ID: <AANLkTikfh5dRZuNOqJTGL0dYNF=nDZngqkVOq6+2=phe@mail.gmail.com>

On Tue, Nov 16, 2010 at 3:51 PM, MinRK <benjaminrk at gmail.com> wrote:

>
>
> On Tue, Nov 16, 2010 at 14:46, Brian Granger <ellisonbg at gmail.com> wrote:
>
>> Boy I am busy these days...continuing on...
>>
>> On Wed, Nov 3, 2010 at 10:28 PM, Fernando Perez <fperez.net at gmail.com>wrote:
>>
>>> On Wed, Nov 3, 2010 at 10:11 PM, Brian Granger <ellisonbg at gmail.com>
>>> wrote:
>>> > The connect/shutdown/abort logic does seem to to together, but kernel
>>> > attribute access seems to go with the XREP-a things.  For the parallel
>>> > stuff, the different between these two types of XREP channels makes
>>> > sense, because they are talking to different processes.  But here, it
>>> > is just 1 process, so I am not sure it makes sense.  I am a little
>>> > concerned about un-needed proliferation of channels.
>>>
>>> Our reasoning for putting attribute access there was to keep the -a
>>> socket strictly for things the user would normally see in his regular
>>> namespace, and -b for things that had to do with manipulating the
>>> kernel object itself.  While it's true that one can get the kernel via
>>> 'ip = get_ipython()' and start working on it, that's not the "regular"
>>> mode of operation in most user activities.
>>>
>>>
>> But wouldn't both XREP channels probe the users namespace?
>>
>
> No. Control does: connect, shutdown/kill/signal, abort, and access *kernel*
> properties, never touching the user namespace.
>
>

Ok, I was under the (incorrect) impression that kernel properties could
touch the namespace.  This is less of an issue then.


>
>>
>>> And Min brought up a compelling point for wanting the separate kernel
>>> control channel: so that things like abort commands can jump to the
>>> front of the queue.  This will become more important once the web
>>> notebook makes it natural to queue up multiple cells for execution,
>>> for example.
>>>
>>>
>> Yes, that does make sense.  But then I think that the control channel
>> should *never* touch the user's namespace.
>>
>
> I don't think we have proposed that it does, but you are right, it
> shouldn't.
>
>

My misunderstanding.


>
>>
>>> And once we update the connection logic to use the mechanism Min has
>>> with a single socket for initial connection and all others
>>> auto-negotiated after that, having one more socket shouldn't be too
>>> big of a deal.  I do agree with you that we don't want these things
>>> growing like dandelions, but I don't think we have too many more in
>>> store, to me this seems like a reasonably complete coverage of what we
>>> need.
>>>
>>>
>> I am not too sure of this.  If you think about remote connections, this is
>> 1 more firewall port that has to be opened.  Also 1 more point of
>> security...
>>
>
>>
>>>  >> - PUB: 'iopub'.  This publishes the i/o streams.
>>> >
>>> > But we publish more than the io streams on this channel.  In reality,
>>> > it is for sideeffects, so would that name make sense.
>>>
>>> We thought about that but it seemed a little too long... And we looked
>>> at the actual list of what goes there, right now we have:
>>>
>>> # Streams (stdout, stderr, etc)
>>> # Python inputs
>>> # Python outputs
>>> # Python errors
>>> # Kernel status
>>> # Kernel crashes
>>>
>>> It seemed like most of this was the kind of thing that normally shows
>>> up on i/o streams at a console/log, so while not literally being
>>> stdout/err, 'iopub' seemed like a reasonable, and short, way to
>>> describe 'publish all i/o activity produced by the kernel'.  I/O is
>>> more or less by definition a side effect (which is why functional
>>> languages typically have to do something a bit odd to provide it, as
>>> it doesn't really fit into a purely functional paradigm)...
>>>
>>>
>> I just think that IO is too limiting because of our moving the payload to
>> this channel.  So maybe:
>>
>> datapub?
>>
>
> I'm fine with something other than iopub, but I still think it's the most
> descriptive.  What goes in the payload that is not IO?  Plots absolutely are
> IO. Maybe not stdio, but IO nonetheless.
>
>
I know that IO broadly defined includes things like plots.  But there are
some types of things that stretch the notion of IO pretty far. But I am
mostly fine with iopub as well as datapub.


> I'm not entirely sure that just 'pub' is inappropriate here, since it's the
> general purpose publish socket.  So far, all of what it publishes is IO, as
> far as I know, but there could be future side effects that might not be
> considered IO.  If for some reason we later need to add another pub socket,
> presumably that will be because it has a function distinct from general
> publishing, and will have a more readily available descriptive name.
>

In this case, I think that pub is pretty good.  The only issue is if we
later have another pub channel like for logging.  So maybe iopub is best.


>
>
>>
>>
>>> But if this justification doesn't convince you, I'm happy to
>>> reconsider (though I'd like to find something a little shorter than
>>> side_effects, we're likely to use these names a lot everywhere...).
>>>
>>> >> - REQ: 'kstdin'. This is the socket that forwards the kernel's stdin
>>> >
>>> > I think he "k" is a bit too short and confusing.  Maybe kernelstdin?
>>> > Or just stdin?
>>>
>>> Yes, the k alone didn't seem very nice.  kernel_stdin?  (In general, I
>>> think we should avoid run-in words without underscores as much as
>>> possible).  It's a bit long but this one isn't likely to be used
>>> super-often, and I think it's a good idea to keep explicit the fact
>>> that this one is a special socket handling something from the kernel,
>>> rather than client-side stdin.
>>>
>>>
>> Yes, I think that kernel_stdin is better.
>>
>
> kernel_stdin is a fine name, and certainly explicit, as long as the
> 'kernel_' doesn't propagate to the kernel object itself.
>  Kernel.kernel_stdin certainly should never happen, but:
>
> KernelManager.kernel_stdin/KernelStdInChannel
> and
> Kernel.stdin
>
> will work fine.
>

Sounds good.

Brian


>
>
>>
>> Cheers,
>>
>> Brian
>>
>>
>>> Thanks for the feedback!
>>>
>>> Cheers,
>>>
>>> f
>>>
>>
>>
>>
>> --
>> Brian E. Granger, Ph.D.
>> Assistant Professor of Physics
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu
>> ellisonbg at gmail.com
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>


-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101116/03f0aa08/attachment.html>

From alex.gaynor at gmail.com  Thu Nov 18 13:03:36 2010
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Thu, 18 Nov 2010 13:03:36 -0500
Subject: [IPython-dev] IPython on PyPy
Message-ID: <AANLkTi=V4heYw4fRM7AxnB_Kx44YUDcgGhBJ1pPWdqq8@mail.gmail.com>

Hello all,

I've been spending the last couple of days working on getting IPython
working on PyPy.  Most of this has been easy things like unimplemented
features in our readline module (such as get_line_buffer, get_endidx,
and insert_text), however now I'm facing some harder issues that I
could use some suggestions on.  For reference our readline module
comes from pyrepl (http://codespeak.net/pyrepl/).

1) First when using Gnome Terminal I get some strange unicode
"artifacts": http://i.imgur.com/Vz9uw.png, this doesn't appear when
running IPython on CPython in GNOME terminal, nor does it appear with
pypy under xterm.  I have no idea what causes this, any advice would
be great.

2) When using <tab> to complete the current line gets swallowed up:
http://i.imgur.com/9ND2x.png.  What was done was 1) `import sys` 2)
`sys.pyp<tab><tab>`.  I assume this is either a bug in our readline or
in IPython, but I have no idea how to diagnose it.

One question I have is: is IPython's autocompletion stuff unittested
at all?  Unfortunately our readline module isn't well tested at all
(especially compared to the rest of our code base).

Thanks for any input,
Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me


From fperez.net at gmail.com  Fri Nov 19 15:15:08 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 19 Nov 2010 12:15:08 -0800
Subject: [IPython-dev] IPython on PyPy
In-Reply-To: <AANLkTi=V4heYw4fRM7AxnB_Kx44YUDcgGhBJ1pPWdqq8@mail.gmail.com>
References: <AANLkTi=V4heYw4fRM7AxnB_Kx44YUDcgGhBJ1pPWdqq8@mail.gmail.com>
Message-ID: <AANLkTimNExqRBN5mkJ1zNajJBuuxRm_+X4bxSFZ8egKM@mail.gmail.com>

Hi Alex,

On Thu, Nov 18, 2010 at 10:03 AM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> Hello all,
>
> I've been spending the last couple of days working on getting IPython
> working on PyPy. ?Most of this has been easy things like unimplemented
> features in our readline module (such as get_line_buffer, get_endidx,
> and insert_text), however now I'm facing some harder issues that I
> could use some suggestions on. ?For reference our readline module
> comes from pyrepl (http://codespeak.net/pyrepl/).

Great news, thanks for working on this!  Just so we know, are you
working off of trunk (ipython/master) or from one of the older
branches (0.10.x)?

> 1) First when using Gnome Terminal I get some strange unicode
> "artifacts": http://i.imgur.com/Vz9uw.png, this doesn't appear when
> running IPython on CPython in GNOME terminal, nor does it appear with
> pypy under xterm. ?I have no idea what causes this, any advice would
> be great.

Mmh, very strange.  Those are the ansi escape sequences, which somehow
are getting mangled up.  They are defined in (on trunk, in the old
branches the directory layout was different):

https://github.com/ipython/ipython/blob/master/IPython/utils/coloransi.py

As you see, those are all plain python strings (in the 2.x sense).
It's possible that something is messing them up and adding weird
encoding artifacts when treated as unicode, I don't know...

> 2) When using <tab> to complete the current line gets swallowed up:
> http://i.imgur.com/9ND2x.png. ?What was done was 1) `import sys` 2)
> `sys.pyp<tab><tab>`. ?I assume this is either a bug in our readline or
> in IPython, but I have no idea how to diagnose it.

This may be related to problem #1.  I suspect what's happening is that
the line length calculation is being thrown off by the bogus data in
the color ansi codes, and when readline rewrites the input line for
the completion, it writes in the wrong part of the line.  So I think
fixing 1 will fix both.

> One question I have is: is IPython's autocompletion stuff unittested
> at all? ?Unfortunately our readline module isn't well tested at all
> (especially compared to the rest of our code base).

Minimally.  We're doing better lately as we refactor things and make
it less readline dependent, which is easier to unittest, but there's
still a long way to go.  Here's what we have so far:

https://github.com/ipython/ipython/blob/master/IPython/core/tests/test_completer.py


Regards,

f


From fperez.net at gmail.com  Fri Nov 19 15:16:34 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 19 Nov 2010 12:16:34 -0800
Subject: [IPython-dev] IPython on PyPy
In-Reply-To: <AANLkTi=V4heYw4fRM7AxnB_Kx44YUDcgGhBJ1pPWdqq8@mail.gmail.com>
References: <AANLkTi=V4heYw4fRM7AxnB_Kx44YUDcgGhBJ1pPWdqq8@mail.gmail.com>
Message-ID: <AANLkTikkwmYMiBOfTTHzA05CdY=SRNSKLauop0fJL3PP@mail.gmail.com>

[ apologies if this arrives twice, my gmail is glitching out...]

Hi Alex,

On Thu, Nov 18, 2010 at 10:03 AM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> Hello all,
>
> I've been spending the last couple of days working on getting IPython
> working on PyPy. ?Most of this has been easy things like unimplemented
> features in our readline module (such as get_line_buffer, get_endidx,
> and insert_text), however now I'm facing some harder issues that I
> could use some suggestions on. ?For reference our readline module
> comes from pyrepl (http://codespeak.net/pyrepl/).

Great news, thanks for working on this!  Just so we know, are you
working off of trunk (ipython/master) or from one of the older
branches (0.10.x)?

> 1) First when using Gnome Terminal I get some strange unicode
> "artifacts": http://i.imgur.com/Vz9uw.png, this doesn't appear when
> running IPython on CPython in GNOME terminal, nor does it appear with
> pypy under xterm. ?I have no idea what causes this, any advice would
> be great.

Mmh, very strange.  Those are the ansi escape sequences, which somehow
are getting mangled up.  They are defined in (on trunk, in the old
branches the directory layout was different):

https://github.com/ipython/ipython/blob/master/IPython/utils/coloransi.py

As you see, those are all plain python strings (in the 2.x sense).
It's possible that something is messing them up and adding weird
encoding artifacts when treated as unicode, I don't know...

> 2) When using <tab> to complete the current line gets swallowed up:
> http://i.imgur.com/9ND2x.png. ?What was done was 1) `import sys` 2)
> `sys.pyp<tab><tab>`. ?I assume this is either a bug in our readline or
> in IPython, but I have no idea how to diagnose it.

This may be related to problem #1.  I suspect what's happening is that
the line length calculation is being thrown off by the bogus data in
the color ansi codes, and when readline rewrites the input line for
the completion, it writes in the wrong part of the line.  So I think
fixing 1 will fix both.

> One question I have is: is IPython's autocompletion stuff unittested
> at all? ?Unfortunately our readline module isn't well tested at all
> (especially compared to the rest of our code base).

Minimally.  We're doing better lately as we refactor things and make
it less readline dependent, which is easier to unittest, but there's
still a long way to go.  Here's what we have so far:

https://github.com/ipython/ipython/blob/master/IPython/core/tests/test_completer.py


Regards,

f


From alex.gaynor at gmail.com  Sun Nov 21 12:34:16 2010
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Sun, 21 Nov 2010 12:34:16 -0500
Subject: [IPython-dev] IPython on PyPy
In-Reply-To: <AANLkTimNExqRBN5mkJ1zNajJBuuxRm_+X4bxSFZ8egKM@mail.gmail.com>
References: <AANLkTi=V4heYw4fRM7AxnB_Kx44YUDcgGhBJ1pPWdqq8@mail.gmail.com>
	<AANLkTimNExqRBN5mkJ1zNajJBuuxRm_+X4bxSFZ8egKM@mail.gmail.com>
Message-ID: <AANLkTik4C66GhgH-frFyiNE1JkbU-6mvf=23HFt1r=S7@mail.gmail.com>

Fernando,

On Fri, Nov 19, 2010 at 3:15 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi Alex,
>
> On Thu, Nov 18, 2010 at 10:03 AM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
>> Hello all,
>>
>> I've been spending the last couple of days working on getting IPython
>> working on PyPy. ?Most of this has been easy things like unimplemented
>> features in our readline module (such as get_line_buffer, get_endidx,
>> and insert_text), however now I'm facing some harder issues that I
>> could use some suggestions on. ?For reference our readline module
>> comes from pyrepl (http://codespeak.net/pyrepl/).
>
> Great news, thanks for working on this! ?Just so we know, are you
> working off of trunk (ipython/master) or from one of the older
> branches (0.10.x)?
>

I've been using .10.1 (what was installed with pip).  Is master stable
enough that testing with it is a good idea?

>> 1) First when using Gnome Terminal I get some strange unicode
>> "artifacts": http://i.imgur.com/Vz9uw.png, this doesn't appear when
>> running IPython on CPython in GNOME terminal, nor does it appear with
>> pypy under xterm. ?I have no idea what causes this, any advice would
>> be great.
>
> Mmh, very strange. ?Those are the ansi escape sequences, which somehow
> are getting mangled up. ?They are defined in (on trunk, in the old
> branches the directory layout was different):
>
> https://github.com/ipython/ipython/blob/master/IPython/utils/coloransi.py
>
> As you see, those are all plain python strings (in the 2.x sense).
> It's possible that something is messing them up and adding weird
> encoding artifacts when treated as unicode, I don't know...
>

Yep, I suppose there's somehow a bug in our readline handling them,
but I'm not sure what, any idea how to debug that?

>> 2) When using <tab> to complete the current line gets swallowed up:
>> http://i.imgur.com/9ND2x.png. ?What was done was 1) `import sys` 2)
>> `sys.pyp<tab><tab>`. ?I assume this is either a bug in our readline or
>> in IPython, but I have no idea how to diagnose it.
>
> This may be related to problem #1. ?I suspect what's happening is that
> the line length calculation is being thrown off by the bogus data in
> the color ansi codes, and when readline rewrites the input line for
> the completion, it writes in the wrong part of the line. ?So I think
> fixing 1 will fix both.
>
>> One question I have is: is IPython's autocompletion stuff unittested
>> at all? ?Unfortunately our readline module isn't well tested at all
>> (especially compared to the rest of our code base).
>
> Minimally. ?We're doing better lately as we refactor things and make
> it less readline dependent, which is easier to unittest, but there's
> still a long way to go. ?Here's what we have so far:
>
> https://github.com/ipython/ipython/blob/master/IPython/core/tests/test_completer.py
>
>
> Regards,
>
> f
>

Thanks,
Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me


From zubin.mithra at gmail.com  Sun Nov 21 22:18:50 2010
From: zubin.mithra at gmail.com (Zubin Mithra)
Date: Mon, 22 Nov 2010 08:48:50 +0530
Subject: [IPython-dev] Porting Ipython to py3
Message-ID: <AANLkTin3oFF0JJO6SjpuoYwjvZJsp4XUOSDbCfhTz+Zy@mail.gmail.com>

Hello everyone,

My name is Zubin Mithra and I have worked on porting a few python packages
over to python3k. I would like to know if there is a porting effort going on
already, so that I could help out too.

Could someone point me to the repository where IPython is being ported?

Thanks,
zm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101122/f96acb1b/attachment.html>

From sunqiang at gmail.com  Sun Nov 21 22:28:45 2010
From: sunqiang at gmail.com (sunqiang)
Date: Mon, 22 Nov 2010 11:28:45 +0800
Subject: [IPython-dev] Porting Ipython to py3
In-Reply-To: <AANLkTin3oFF0JJO6SjpuoYwjvZJsp4XUOSDbCfhTz+Zy@mail.gmail.com>
References: <AANLkTin3oFF0JJO6SjpuoYwjvZJsp4XUOSDbCfhTz+Zy@mail.gmail.com>
Message-ID: <AANLkTikNVTbA7HUaFW=gzhQ_7v5wvNxyCU_vaUdkcA8Q@mail.gmail.com>

should be here: http://github.com/ipython/ipython-py3k
I think it's still not as solid as 2.x version.

On Mon, Nov 22, 2010 at 11:18 AM, Zubin Mithra <zubin.mithra at gmail.com> wrote:
> Hello everyone,
>
> My name is Zubin Mithra and I have worked on porting a few python packages
> over to python3k. I would like to know if there is a porting effort going on
> already, so that I could help out too.
>
> Could someone point me to the repository where IPython is being ported?
>
> Thanks,
> zm
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


From takowl at gmail.com  Mon Nov 22 13:32:43 2010
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 22 Nov 2010 18:32:43 +0000
Subject: [IPython-dev] IPython-dev Digest, Vol 82, Issue 14
In-Reply-To: <mailman.5.1290448803.13359.ipython-dev@scipy.org>
References: <mailman.5.1290448803.13359.ipython-dev@scipy.org>
Message-ID: <AANLkTi=rM2t4s_8xR_p=kRqVhtb8na+SVkp2nDfoGS9Q@mail.gmail.com>

On 22 November 2010 18:00, <ipython-dev-request at scipy.org> wrote:

> should be here: http://github.com/ipython/ipython-py3k
> I think it's still not as solid as 2.x version.
>

Basic terminal operation is pretty good now (but please test it and report
any bugs you find at https://github.com/ipython/ipython-py3k/issues ). One
of the new things for IPython 0.11, however, is to be a system of multiple
frontends (first off, a Qt console), communicating with IPython via the ZMQ
framework. I've not had much luck getting this bit running with Py 3k (last
time I tried, pyzmq 2.0.10 wouldn't even compile on my computer), so any
help there is welcome.

Let me know if you want any pointers on getting set up.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101122/03493f2a/attachment.html>

From danciac at gmail.com  Wed Nov 24 06:19:35 2010
From: danciac at gmail.com (Daniel Cracan)
Date: Wed, 24 Nov 2010 13:19:35 +0200
Subject: [IPython-dev] gsoc with ipython
Message-ID: <201011241319.35443.danciac@gmail.com>

Hey everybody!

I am a student at a technical university, and I would be interested in coding 
for the IPython project at gsoc this summer.

I thought it would be much better if I got to know a bit more about the 
project, before applying for it at gsoc.

So if there is anyone willing to point me to the right direction I would 
appreciate that very much.

Have a nice day,
Daniel.


From erik.tollerud at gmail.com  Mon Nov 29 13:51:26 2010
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Mon, 29 Nov 2010 10:51:26 -0800
Subject: [IPython-dev] gsoc with ipython
In-Reply-To: <201011241319.35443.danciac@gmail.com>
References: <201011241319.35443.danciac@gmail.com>
Message-ID: <AANLkTikTpB0zSz9ntTYoMHYn4AEgpkSc4VSApmFB=N2g@mail.gmail.com>

I think a number of the main developers have been busy with other
things in the last few weeks, but I'm sure they'd be happy to see
another GSOC.  Last year I understand there were a couple of quite
positive ones (see http://ipython.scipy.org/moin/GSoC2010/IPythonQt
and http://ipython.scipy.org/moin/GSoC2010/IPythonZmq)...

If you are asking where to familiarize yourself with the development
process, the best place is
http://ipython.scipy.org/doc/nightly/html/development/index.html -
although some of those details may be in flux given the recent rapid
pace of changes. If you're asking for specific suggestions for
proposals, hopefully one of the senior devs can get back to you.

On Wed, Nov 24, 2010 at 3:19 AM, Daniel Cracan <danciac at gmail.com> wrote:
> Hey everybody!
>
> I am a student at a technical university, and I would be interested in coding
> for the IPython project at gsoc this summer.
>
> I thought it would be much better if I got to know a bit more about the
> project, before applying for it at gsoc.
>
> So if there is anyone willing to point me to the right direction I would
> appreciate that very much.
>
> Have a nice day,
> Daniel.
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Erik Tollerud