From fperez.net at gmail.com  Thu Apr  8 21:11:16 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 8 Apr 2010 18:11:16 -0700
Subject: [IPython-dev] GSoc Ideas
Message-ID: <q2vdb6b5ecc1004081811i3b497b55tae552c79f34413ef@mail.gmail.com>

Hi all,

rather in the nick of time, but a couple of students have been working
on proposals to work off the recent zmq effort as part of this year's
gsoc program.  The scipy server conveniently has been very flaky
today, so the versions on the wiki are a bit old:

http://ipython.scipy.org/moin/GSoC2010/IPythonQt
http://ipython.scipy.org/moin/GSoC2010/IPythonZmq

but the work-in-progress is in Google docs:

https://docs.google.com/Doc?docid=0AYxL328I15VNZGhjdGo4OGJfNThmMm54bTljcg&hl=en
https://docs.google.com/Doc?docid=0Abqq0nDYtAPSZGdjOGpjZGZfMTNndDJtem5oYw&hl=en

Feedback/ideas welcome (even if it's unfortunately kind of late..)

Cheers,

f


From muzgash.lists at gmail.com  Fri Apr  9 01:09:10 2010
From: muzgash.lists at gmail.com (Gerardo Gutierrez)
Date: Fri, 9 Apr 2010 00:09:10 -0500
Subject: [IPython-dev] Qt/Curses interfaces future: results of the
	weekend mini-sprint (or having fun with 0mq)
In-Reply-To: <fa8579a41003251216i32a2d738k248cfeb8ba5c8905@mail.gmail.com>
References: <p2pdb6b5ecc1003231401sa46e5493k895a2d22cb2c2dee@mail.gmail.com>
	<12aaa0811003242015l7d758507h7d04d9df4587c28d@mail.gmail.com>
	<fa8579a41003242041s6c996fe8ya322fa8ba59ad748@mail.gmail.com>
	<12aaa0811003251116u5a729d87t19f8112769b73f58@mail.gmail.com>
	<fa8579a41003251216i32a2d738k248cfeb8ba5c8905@mail.gmail.com>
Message-ID: <g2v9764d2d91004082209m71db1458x25a8333fb58359c0@mail.gmail.com>

Hi all.

We Gerardo and Omar, (two of the new developers of ipython) are applying for
GSoC this year with some of the projects mentioned here.
So we ask you to please send us some feedback about the proposals linked
below so we have a better chance to participate and also to have a better
understanding of what do you want to see on these projects.

http://ipython.scipy.org/moin/GSoC2010/IPythonZmq

http://ipython.scipy.org/moin/GSoC2010/IPythonQt

The deadline for student application is apr 9, 19GMT, sorry for the delay.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100409/33298704/attachment.html>

From robert.kern at gmail.com  Mon Apr 12 00:16:46 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Sun, 11 Apr 2010 23:16:46 -0500
Subject: [IPython-dev] In-place %editing of methods
Message-ID: <hpu6sh$nr6$1@dough.gmane.org>

It just occurred to me that someone could write a very useful magic for editing 
methods and functions in-place. The following is a loose sketch to record my 
thoughts in public.

Workflow:

You think you have a problem with a particular method. You use Foo.bar?? to view 
its source. You realize that you need a print statement somewhere in there. What 
to do?!

Solution:

%inplace Foo.bar

This will inspect the source for just the method and open it in your editor. 
When you are finished, it will create a new module object with an ad hoc name 
(maybe inplace_<hashsum>.py) with a corresponding fake entry in the linecache 
for tracebacks and future %inplaces. The globals dict is populated with the 
entries from the method object's globals dict (.im_func.func_globals) in order 
to ensure that you have the appropriate global referents (be sure to fix the 
__file__ entry to the ad hoc name). If the new function needs extra imports or 
other module-level functions, that's fine (untested). No new methods, though.

Execute the code in this module's namespace. Extract the function object by 
name. If the original is a method, look up the class and assign the new function 
object to it. If the original is a function, look up the module and assign it. 
None of this is particularly difficult or problematic. Only when you need to 
edit whole classes and adjust living objects to use the new type do you run into 
difficulties. There are solutions on PyPI, but they are larger and more 
error-prone than we probably care for.

%inplace should keep a record of these modifications. Many of them are going to 
be throwaway debugging things, but some will be genuine modifications that 
should be propagated into the actual source code. A SQLite database in 
~/.ipython/ is a nice, robust location to keep them. Upon exit, IPython should 
print out the final versions of the modified functions. Additionally, you can 
have a couple of --options for %inplace that let you view/clean up the database 
instead of editing something. For bonus points, generate a unified diff against 
the actual files.

-- 
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 Apr 12 14:13:40 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 12 Apr 2010 11:13:40 -0700
Subject: [IPython-dev] In-place %editing of methods
In-Reply-To: <hpu6sh$nr6$1@dough.gmane.org>
References: <hpu6sh$nr6$1@dough.gmane.org>
Message-ID: <m2idb6b5ecc1004121113yb7af2646g652e2095b24a96fa@mail.gmail.com>

On Sun, Apr 11, 2010 at 9:16 PM, Robert Kern <robert.kern at gmail.com> wrote:
> It just occurred to me that someone could write a very useful magic for editing
> methods and functions in-place. The following is a loose sketch to record my
> thoughts in public.

Thanks, great idea.  Filed for tracking:

https://bugs.launchpad.net/ipython/+bug/561693

Cheers,

f


From fperez.net at gmail.com  Mon Apr 12 16:21:38 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 12 Apr 2010 13:21:38 -0700
Subject: [IPython-dev] GSoC applicants: patch and blog required
Message-ID: <h2ydb6b5ecc1004121321t81261cb9w3c9c99c439bc54e3@mail.gmail.com>

Hi folks,

this is mostly for the gsoc applicants, but I want to make sure that
soc communications are, within reason, always managed on the dev list
(if nothing else, it serves as a record for future years of the
process).

Please note a few important points from the application page:

http://wiki.python.org/moin/SummerOfCode/Application

Specifically, it says

"""
Even if you haven't worked on anything before this, please engage with
the project you're proposing to work on and submitting some kind of
patch (minor code patch, documentation patch, etc.) showing that you
can work through the technical issues necessary to contribute.
Applicants that do this will be prioritized over those that don't.
"""

Since the gsoc proposals are actually pieces of the development plan
for IPython, you can fulfill this requirement by submitting a branch
for merge review that has your proposal as a development document.  I
would suggest that you make a different document each (so you don't
step on each other with version control), in the development section
of the documentation. Make sure the docs build in html and pdf before
submitting the branch for review.

Note that if you don't do this *soon*, there's a very good chance your
application will not get a good score in the final evaluation process,
as all applicants are expected to have submitted some small
contribution to their project.  You already have written up most of
it, so it should be just a matter of creating it as a doc in the
sphinx tree and making sure things build, we'll review it by simply
branching from you, doing

make html && make pdf

in the docs directory and ensuring the resulting document contains the
full proposal. Feedback will be done as a regular branch review on
launchpad.

Also note that the page says:

- include a blog URL

So please do get a blog started up for this.

This page has the rest of the expectations from the Python software
foundation for students, so give it a good read because if your
proposal is accepted, this is the standard you'll have to meet (in
addition to producing good code):

http://wiki.python.org/moin/SummerOfCode/Expectations

Regards,

f


From robert.kern at gmail.com  Tue Apr 13 17:04:27 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 13 Apr 2010 16:04:27 -0500
Subject: [IPython-dev] In-place %editing of methods
In-Reply-To: <m2idb6b5ecc1004121113yb7af2646g652e2095b24a96fa@mail.gmail.com>
References: <hpu6sh$nr6$1@dough.gmane.org>
	<m2idb6b5ecc1004121113yb7af2646g652e2095b24a96fa@mail.gmail.com>
Message-ID: <hq2m8r$ahs$1@dough.gmane.org>

On 2010-04-12 13:13 PM, Fernando Perez wrote:
> On Sun, Apr 11, 2010 at 9:16 PM, Robert Kern<robert.kern at gmail.com>  wrote:
>> It just occurred to me that someone could write a very useful magic for editing
>> methods and functions in-place. The following is a loose sketch to record my
>> thoughts in public.
>
> Thanks, great idea.  Filed for tracking:
>
> https://bugs.launchpad.net/ipython/+bug/561693

I have an implementation in my kernmagic package.

http://www.enthought.com/~rkern/cgi-bin/hgwebdir.cgi/kernmagic/

No persistence or unified diffs, but I think that's fine.

-- 
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  Wed Apr 14 01:22:09 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 13 Apr 2010 22:22:09 -0700
Subject: [IPython-dev] GSoC applicants: patch and blog required
In-Reply-To: <h2ydb6b5ecc1004121321t81261cb9w3c9c99c439bc54e3@mail.gmail.com>
References: <h2ydb6b5ecc1004121321t81261cb9w3c9c99c439bc54e3@mail.gmail.com>
Message-ID: <l2jdb6b5ecc1004132222o1bdfd52dp579f77dc7b791ab6@mail.gmail.com>

On Mon, Apr 12, 2010 at 1:21 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi folks,
>
> this is mostly for the gsoc applicants, but I want to make sure that
> soc communications are, within reason, always managed on the dev list
> (if nothing else, it serves as a record for future years of the
> process).

Bringing back the discussion on-list...

2010/4/13 Omar Andr?s Zapata Mesa <andresete.chaos at gmail.com>:
> a ya!
> que pena Fernando fue que gerardo me confundio.
>
> ya le hice el push voy a empezar a organizar el codigo de
> http://github.com/fperez/pyzmq/

The official pyzmq repo is this one, mine is just a fork:

http://github.com/ellisonbg/pyzmq

The code we want as a starter is in the completer branch.

> para montarlo al branch y hacer de una manera sistematica las pruebas para
> conocer bien el sistema.
> seria bueno incluir ahi los modulos pyzmq? o suponemos que el usuario los
> tiene ya en su maquina, por mi no hay problema por que ya lo tengo cuadrado,
> pero alguien que quiera ver el codigo demas que le tomaria un trabajo extra
> cuadrarlo y seria maluco o que dcies?
> seguimos en contacto Gracias.

No, users will have to install zmq separately.  Once this system
stabilizes, we'll probably make releases of pyzmq to ease things, but
it will be a dependency (just like twisted or nose).  It's a separate
project.

Cheers,

f


From fperez.net at gmail.com  Wed Apr 14 02:30:49 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 13 Apr 2010 23:30:49 -0700
Subject: [IPython-dev] Moving to git/github
Message-ID: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com>

Hi all,

over the last couple of weeks, pretty much every time I've tried to do
something recently with ipython I've wasted the first two hours
dealing with bzr repository problems (corrupted repos, version
incompatibilities, ...).  Once bzr decided to corrupt my repo (I'd
never seen that from any other VC system!), I had to re-clone all the
branches, but I just realized that I need to do it with the old format
so I can push.  And the old format is slow as molasses.  We could
upgrade the lp repos, but frankly, rather than invest more time
dealing with a broken tool, let's just move to one that works.

I've tested converting our bzr repo into git and it works beautifully
(this will NOT be our official git repo, I was just testing things
out):

http://github.com/fperez/ip

see for example:

http://github.com/fperez/ip/network

where you can scroll and view all the merges and history.

If we get GSOC project(s) approved, having a smooth collaboration
machinery will be even more important.

So a proposed plan for the migration is:

- merge all the branches that are in-flight and ready into trunk (it's
not a lot right now).
- I repeat the conversion, and upload the new repo to github, we close
up shop on bzr.

Ideally, that would be it for the code.  So I'd like to ask anyone
with pending work to put up your branches for merging, so that we can
review them and merge them as soon as is reasonable.  If we have
unmerged branches when we make the transition they can be moved
separately, but the extra steps needed the better.

I'm deliberately *not* addressing here the question of what to do with
bugs, we have a ton of important history in the LP bugtracker so I'm
not sold on the idea of switching yet to the github one, at least
until we discuss it more carefully.

Any thoughts, feedback, holes in the above plan?

Cheers,

f

ps - anyone know what the format of our lp:ipython repo is?  I can't
seem to clone it in a way that allows me to push later again using a
shared repo because I don't know what format to use for init-repo.
Any help with that info would be much appreciated.


From fperez.net at gmail.com  Wed Apr 14 02:59:30 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 13 Apr 2010 23:59:30 -0700
Subject: [IPython-dev] Moving to git/github
In-Reply-To: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com>
References: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com>
Message-ID: <u2hdb6b5ecc1004132359m13e823d3t935c8da11ad2b576@mail.gmail.com>

On Tue, Apr 13, 2010 at 11:30 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> ps - anyone know what the format of our lp:ipython repo is? ?I can't
> seem to clone it in a way that allows me to push later again using a
> shared repo because I don't know what format to use for init-repo.
> Any help with that info would be much appreciated.

For future reference, the magic incantation needed (many thanks to
lifeless on #bzr on irc!) was:

bzr info -v nosmart+lp:ipython

This was the only way to figure out the remote LP branch format, so I
could make a new, clean local shared repo with the same format from
scratch, to start doing branch work.

Whew.  I'm putting this here in case it saves someone time in the
future (or even another one of us during the transition).

Cheers,

f


From Chris.Barker at noaa.gov  Wed Apr 14 12:26:22 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Wed, 14 Apr 2010 09:26:22 -0700
Subject: [IPython-dev] Moving to git/github
In-Reply-To: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com>
References: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com>
Message-ID: <4BC5ECAE.40904@noaa.gov>

Fernando Perez wrote:
> I've tested converting our bzr repo into git

I don't suppose you'd consider Mercurial? It seems the more "Pythonic" 
option, and I'm really not looking forward to keeping track how to use 
four different VCSs.

Oh well. I probably won't need to do more than pull the latest anyway.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov


From willmaier at ml1.net  Wed Apr 14 12:39:39 2010
From: willmaier at ml1.net (Will Maier)
Date: Wed, 14 Apr 2010 11:39:39 -0500
Subject: [IPython-dev] Moving to git/github
In-Reply-To: <4BC5ECAE.40904@noaa.gov>
References: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com>
	<4BC5ECAE.40904@noaa.gov>
Message-ID: <20100414163939.GM32724@burko.lfod.us>

Hi Christopher-

On Wed, Apr 14, 2010 at 09:26:22AM -0700, Christopher Barker wrote:
> Fernando Perez wrote:
> > I've tested converting our bzr repo into git
> 
> I don't suppose you'd consider Mercurial? It seems the more "Pythonic" 
> option, and I'm really not looking forward to keeping track how to use 
> four different VCSs.

Fortunately, you don't have to. Even though I've never installed git on any of
my systems, I've just migrated my Mercurial projects to github[0]. With the
hg-git[1] plugin (developed by github), it's easy to use Mercurial for hacking
and push my work back to github. I'm sure you could do the same when IPython
finishes its migration.

[0] FWIW, I also have mirrors on bitbucket (a service catering directly to
    Mercurial). I keep the mirrors in sync with the following in a clone's hgrc:

    [hooks]
    changegroup.bitbucket = hg push bitbucket
    changegroup.github = hg push github

    When I push to the clone, it in turn sends the changes to bitbucket and
    github (the actual paths are defined elsewhere in the hgrc).
[1] http://hg-git.github.com/

-- 

[Will Maier]-----------------[willmaier at ml1.net|http://www.lfod.us/]


From fperez.net at gmail.com  Wed Apr 14 14:11:39 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 14 Apr 2010 11:11:39 -0700
Subject: [IPython-dev] Moving to git/github
In-Reply-To: <4BC5ECAE.40904@noaa.gov>
References: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com> 
	<4BC5ECAE.40904@noaa.gov>
Message-ID: <s2udb6b5ecc1004141111z513bc3ah8a94cdf5cd22577d@mail.gmail.com>

Hi Chris,

On Wed, Apr 14, 2010 at 9:26 AM, Christopher Barker
<Chris.Barker at noaa.gov> wrote:
>
> I don't suppose you'd consider Mercurial? It seems the more "Pythonic"
> option, and I'm really not looking forward to keeping track how to use
> four different VCSs.
>
> Oh well. I probably won't need to do more than pull the latest anyway.

Fortunately as Will points out (thanks!), there's good hg <-> git
support.  I think the reality is that we'll live with git AND hg for a
while, as both seem to have crossed a threshold of interest, activity
and quality that can sustain them.

Personally I really like git, all of my current public and private
work is git-hosted, Brian also uses git extensively, matplotlib is
moving to git, the nipy project from my work is partly git hosted and
the rest of it is moving to git soon, etc.  I find git's branching
model fabulous, and I love the github interface.

So I don't see a compelling reason to go to hg, despite the fact that
I'm sure it's a perfectly good tool.  I do like the fact that hg is
there and is good, I have the impression that the competition between
hg and git is benefiting both projects and they are learning from each
other.

It's true that it's a little annoying to use all systems, but
hopefully soon we'll be down to hg and git: I don't see bzr going
anywhere, and git-svn is a pretty good option to use for svn repos
once you're familiar with git.  And as those two converge even
further, it should get even easier.

Regards,

f


From fperez.net at gmail.com  Wed Apr 14 14:37:04 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 14 Apr 2010 11:37:04 -0700
Subject: [IPython-dev] Upgrading the bzr repo at LP?
Message-ID: <g2rdb6b5ecc1004141137n6a7f63c4u7a6c3259cd445f13@mail.gmail.com>

Hi all,

after my fight with lp yesterday, it became clear that the only
reasonable way to manage the merges from the remaining branches that
are in flight (especially those in ~ipython-contrib) is to upgrade the
lp:ipython main repo.  The reason is that otherwise it's impossible to
merge from ~ipython-contrib and push back to trunk: the contrib repo
is version 2a and trunk is 0.92, and one can only push to a 0.92 from
a 0.92 repo, but one can't pull from a 2a into a 0.92 one (even
locally).

So even as we move out of LP, it's inevitable that we upgrade the
repo.  You had all OK'd the move back in February (when I had to stop
because it was taking too long and I was traveling), so I'm going to
push the process now.

The only consequence of this is that you will need to then go to your
locally housed repos at home and do

bzr upgrade --2a

before you can push again.

I'm starting the upgrade on LP now from a machine with a solid and
persistent connection (as they recommend) I'll post when it's
finished.

Cheers,

f


From erik.tollerud at gmail.com  Wed Apr 14 14:46:36 2010
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Wed, 14 Apr 2010 11:46:36 -0700
Subject: [IPython-dev] Moving to git/github
In-Reply-To: <s2udb6b5ecc1004141111z513bc3ah8a94cdf5cd22577d@mail.gmail.com>
References: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com> 
	<4BC5ECAE.40904@noaa.gov>
	<s2udb6b5ecc1004141111z513bc3ah8a94cdf5cd22577d@mail.gmail.com>
Message-ID: <z2nfbab3e0d1004141146p462990abs45f10ef779b890ad@mail.gmail.com>

As a "casual" developer/power user of ipython, I have something to add here...

> So I don't see a compelling reason to go to hg, despite the fact that
> I'm sure it's a perfectly good tool. ?I do like the fact that hg is
> there and is good, I have the impression that the competition between
> hg and git is benefiting both projects and they are learning from each
> other.

There is one compelling reason to choose hg over git: simplicity.  My
experience between bzr, hg, and git has been that they are in exactly
that order of increasing complexity... but hg and bzr are both *way*
easier than git.  Frankly, it shows that git was written by someone
who wrote the linux kernel - yes you can do a lot of things, but the
simplest of things are just more complicated or have surprising
gotchas.  The hg<->git bridge makes things easier, but the times I've
used it, it seems to negate all the advantages of hg or git (speed
and/or the advanced features), although that's only based on a couple
data points.  And anyway, if the goal is simplicity, adding an
additional conceptual layer is far worse than taking a few-percent
speed hit.

Now given that ipython is a somewhat "low-level" utility in that it
seems rather difficult to just do some quick hacks on without really
understanding what's going on, maybe this isn't an issue, as maybe all
the core devs are fine with a more complex system... but git would
certainly be a barrier to someone like me contributing.


> It's true that it's a little annoying to use all systems, but
> hopefully soon we'll be down to hg and git: I don't see bzr going
> anywhere, and git-svn is a pretty good option to use for svn repos
> once you're familiar with git. ?And as those two converge even
> further, it should get even easier.

I personally use bzr for all of my projects that I have a choice in
the matter... I think it's not at all clear-cut that bzr is going to
disappear any sooner than hg or git unless Canonical and Ubuntu
disappear - they're committed to launchpad and it is very closely tied
to bzr - a lot of people will stick with it for exactly those reasons.
 That's certainly not a reason to stick with bzr if most of the
ipython devs aren't happy with it, but it's not fair to say it's dying
by any stretch.

I'd also add that it looks like you're using the pack-0.92 format...
the more recent 2a format works quite a bit faster in my experience,
and I've never had any conversion problems...


From fperez.net at gmail.com  Wed Apr 14 15:24:30 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 14 Apr 2010 12:24:30 -0700
Subject: [IPython-dev] Moving to git/github
In-Reply-To: <z2nfbab3e0d1004141146p462990abs45f10ef779b890ad@mail.gmail.com>
References: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com> 
	<4BC5ECAE.40904@noaa.gov>
	<s2udb6b5ecc1004141111z513bc3ah8a94cdf5cd22577d@mail.gmail.com>
	<z2nfbab3e0d1004141146p462990abs45f10ef779b890ad@mail.gmail.com>
Message-ID: <j2hdb6b5ecc1004141224if842ace9ga844eb23f648d37c@mail.gmail.com>

Hi Erik,

On Wed, Apr 14, 2010 at 11:46 AM, Erik Tollerud <erik.tollerud at gmail.com> wrote:
> As a "casual" developer/power user of ipython, I have something to add here...

Thanks a lot for your feedback!

>> So I don't see a compelling reason to go to hg, despite the fact that
>> I'm sure it's a perfectly good tool. ?I do like the fact that hg is
>> there and is good, I have the impression that the competition between
>> hg and git is benefiting both projects and they are learning from each
>> other.
>
> There is one compelling reason to choose hg over git: simplicity. ?My
> experience between bzr, hg, and git has been that they are in exactly
> that order of increasing complexity... but hg and bzr are both *way*
> easier than git. ?Frankly, it shows that git was written by someone
> who wrote the linux kernel - yes you can do a lot of things, but the
> simplest of things are just more complicated or have surprising
> gotchas. ?The hg<->git bridge makes things easier, but the times I've
> used it, it seems to negate all the advantages of hg or git (speed
> and/or the advanced features), although that's only based on a couple
> data points. ?And anyway, if the goal is simplicity, adding an
> additional conceptual layer is far worse than taking a few-percent
> speed hit.
>
> Now given that ipython is a somewhat "low-level" utility in that it
> seems rather difficult to just do some quick hacks on without really
> understanding what's going on, maybe this isn't an issue, as maybe all
> the core devs are fine with a more complex system... but git would
> certainly be a barrier to someone like me contributing.

I really hope that git does not become a barrier to you nor anyone
else.  I think git is improving, and that part of the problem with git
is that a lot of the existing documentation exposes all of its
flexibility (and hence complexity) up front.  The man pages (I'll be
the first to admit) are very opaque, and a few choices of the
interface are downright wrong (for commit, -a *should* have been the
default like everywhere else, and --some-option should be used to only
commit manually staged changes).  But things do get better (e.g. the
new --set-upstream in 1.7 which is like bzr's great --remember for
push/pull).

I do take your comment to heart though (esp. since the same issue is
about to hit us on ipython, matplotlib and nipy!).  I am personally
committed to writing up a *clear* workflow document for ipython/nipy
that can be followed nicely by anyone who starts by:

- getting the sources for ipython via version control
- from there, makes a small change to fix/improve something
- then, wants to share that change with minimal effort.

The key will be, I think, not to point people to multiple tutorials
they can read and then assemble things in their head, but instead to
give them *our workflow*, with all the choices explicitly indicated
and made for them.  Once they learn more about git they can change
those decisions and lay their workflow differently if desired, but
initially they have no criterion of their own to choose, so we might
as well pick good choices for them to let them get up and running
without much pain.

So I'm not discounting your comment, I just hope that for ipython,
nipy and others I'm involved with, we'll be able to provide a clear
enough guide that git's extensive flexibility is not an upfront
hindrance to anyone.  We'll see if we succeed :)

>> It's true that it's a little annoying to use all systems, but
>> hopefully soon we'll be down to hg and git: I don't see bzr going
>> anywhere, and git-svn is a pretty good option to use for svn repos
>> once you're familiar with git. ?And as those two converge even
>> further, it should get even easier.
>
> I personally use bzr for all of my projects that I have a choice in
> the matter... I think it's not at all clear-cut that bzr is going to
> disappear any sooner than hg or git unless Canonical and Ubuntu
> disappear - they're committed to launchpad and it is very closely tied
> to bzr - a lot of people will stick with it for exactly those reasons.
> ?That's certainly not a reason to stick with bzr if most of the
> ipython devs aren't happy with it, but it's not fair to say it's dying
> by any stretch.

I said 'not going anywhere', not 'disappear'.  I simply don't see
major bzr uptake in new projects, and I do see people moving away from
it (anecdotal evidence from blog posts, no statistical study here :),
so I don't see it growing significantly, especially with the rapid
rise in popularity of hg/git.  But with the weight of LP/canonical and
other existing projects behind it, I'm sure it will remain viable for
those who like it (and I hope it will continue to improve, its
developers have certainly been super-friendly to me on irc and for
that I thank them profusely).

> I'd also add that it looks like you're using the pack-0.92 format...
> the more recent 2a format works quite a bit faster in my experience,
> and I've never had any conversion problems...

The conversion is ongoing right now at LP, so hopefully it will finish
soon and we'll have all repos on 2a, to ease the transition.

Cheers,

f


From benjaminrk at gmail.com  Wed Apr 14 15:30:37 2010
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 14 Apr 2010 12:30:37 -0700
Subject: [IPython-dev] Moving to git/github
In-Reply-To: <z2nfbab3e0d1004141146p462990abs45f10ef779b890ad@mail.gmail.com>
References: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com> 
	<4BC5ECAE.40904@noaa.gov>
	<s2udb6b5ecc1004141111z513bc3ah8a94cdf5cd22577d@mail.gmail.com>
	<z2nfbab3e0d1004141146p462990abs45f10ef779b890ad@mail.gmail.com>
Message-ID: <n2iea108cfa1004141230i80086c1cn9405ca8133bde7d0@mail.gmail.com>

I fully support moving to git, as almost every new project I encounter is on
git, and IPython is the only thing I have had occasion to touch with bzr. In
particular, github makes forking/proposing contributions easier than
anything I have observed, and I have seen many projects on github benefit
from that. Moreover, the fork/contribute behavior is very active in the git
community, and I think just being on github is likely to prompt more
contribution than living at LP.

-MinRK

On Wed, Apr 14, 2010 at 11:46, Erik Tollerud <erik.tollerud at gmail.com>wrote:

> As a "casual" developer/power user of ipython, I have something to add
> here...
>
> > So I don't see a compelling reason to go to hg, despite the fact that
> > I'm sure it's a perfectly good tool.  I do like the fact that hg is
> > there and is good, I have the impression that the competition between
> > hg and git is benefiting both projects and they are learning from each
> > other.
>
> There is one compelling reason to choose hg over git: simplicity.  My
> experience between bzr, hg, and git has been that they are in exactly
> that order of increasing complexity... but hg and bzr are both *way*
> easier than git.  Frankly, it shows that git was written by someone
> who wrote the linux kernel - yes you can do a lot of things, but the
> simplest of things are just more complicated or have surprising
> gotchas.  The hg<->git bridge makes things easier, but the times I've
> used it, it seems to negate all the advantages of hg or git (speed
> and/or the advanced features), although that's only based on a couple
> data points.  And anyway, if the goal is simplicity, adding an
> additional conceptual layer is far worse than taking a few-percent
> speed hit.
>
> Now given that ipython is a somewhat "low-level" utility in that it
> seems rather difficult to just do some quick hacks on without really
> understanding what's going on, maybe this isn't an issue, as maybe all
> the core devs are fine with a more complex system... but git would
> certainly be a barrier to someone like me contributing.
>
>
> > It's true that it's a little annoying to use all systems, but
> > hopefully soon we'll be down to hg and git: I don't see bzr going
> > anywhere, and git-svn is a pretty good option to use for svn repos
> > once you're familiar with git.  And as those two converge even
> > further, it should get even easier.
>
> I personally use bzr for all of my projects that I have a choice in
> the matter... I think it's not at all clear-cut that bzr is going to
> disappear any sooner than hg or git unless Canonical and Ubuntu
> disappear - they're committed to launchpad and it is very closely tied
> to bzr - a lot of people will stick with it for exactly those reasons.
>  That's certainly not a reason to stick with bzr if most of the
> ipython devs aren't happy with it, but it's not fair to say it's dying
> by any stretch.
>
> I'd also add that it looks like you're using the pack-0.92 format...
> the more recent 2a format works quite a bit faster in my experience,
> and I've never had any conversion problems...
> _______________________________________________
> 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/20100414/603bebb0/attachment.html>

From ellisonbg at gmail.com  Wed Apr 14 16:03:05 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Wed, 14 Apr 2010 13:03:05 -0700
Subject: [IPython-dev] Upgrading the bzr repo at LP?
In-Reply-To: <g2rdb6b5ecc1004141137n6a7f63c4u7a6c3259cd445f13@mail.gmail.com>
References: <g2rdb6b5ecc1004141137n6a7f63c4u7a6c3259cd445f13@mail.gmail.com>
Message-ID: <n2xfa8579a41004141303o52d83eaoa36e5642b7729954@mail.gmail.com>

This sounds like a good plan.  Thanks for doing this.

Brian

On Wed, Apr 14, 2010 at 11:37 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi all,
>
> after my fight with lp yesterday, it became clear that the only
> reasonable way to manage the merges from the remaining branches that
> are in flight (especially those in ~ipython-contrib) is to upgrade the
> lp:ipython main repo. ?The reason is that otherwise it's impossible to
> merge from ~ipython-contrib and push back to trunk: the contrib repo
> is version 2a and trunk is 0.92, and one can only push to a 0.92 from
> a 0.92 repo, but one can't pull from a 2a into a 0.92 one (even
> locally).
>
> So even as we move out of LP, it's inevitable that we upgrade the
> repo. ?You had all OK'd the move back in February (when I had to stop
> because it was taking too long and I was traveling), so I'm going to
> push the process now.
>
> The only consequence of this is that you will need to then go to your
> locally housed repos at home and do
>
> bzr upgrade --2a
>
> before you can push again.
>
> I'm starting the upgrade on LP now from a machine with a solid and
> persistent connection (as they recommend) I'll post when it's
> finished.
>
> 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 willmaier at ml1.net  Wed Apr 14 17:22:11 2010
From: willmaier at ml1.net (Will Maier)
Date: Wed, 14 Apr 2010 16:22:11 -0500
Subject: [IPython-dev] Moving to git/github
In-Reply-To: <20100414163939.GM32724@burko.lfod.us>
References: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com>
	<4BC5ECAE.40904@noaa.gov> <20100414163939.GM32724@burko.lfod.us>
Message-ID: <20100414212211.GO32724@burko.lfod.us>

A quick addendum...

On Wed, Apr 14, 2010 at 11:39:39AM -0500, Will Maier wrote:
> [0] FWIW, I also have mirrors on bitbucket (a service catering directly to
>     Mercurial). I keep the mirrors in sync with the following in a clone's hgrc:
> 
>     [hooks]

I just noticed that it is necessary to run the following hook before
changegroup.github:

	  changegroup.updatemaster = hg bookmark -f -r default master

hg-git uses the master revision to decide what changesets need to be sent to the
remote git repository. Since the bookmark isn't updated when the mirror repo
receives a push, the above hook is necessary.

>     changegroup.bitbucket = hg push bitbucket
>     changegroup.github = hg push github
> 
>     When I push to the clone, it in turn sends the changes to bitbucket and
>     github (the actual paths are defined elsewhere in the hgrc).

-- 

[Will Maier]-----------------[willmaier at ml1.net|http://www.lfod.us/]


From Chris.Barker at noaa.gov  Wed Apr 14 17:35:12 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Wed, 14 Apr 2010 14:35:12 -0700
Subject: [IPython-dev] Moving to git/github
In-Reply-To: <s2udb6b5ecc1004141111z513bc3ah8a94cdf5cd22577d@mail.gmail.com>
References: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com>
	<4BC5ECAE.40904@noaa.gov>
	<s2udb6b5ecc1004141111z513bc3ah8a94cdf5cd22577d@mail.gmail.com>
Message-ID: <4BC63510.4010805@noaa.gov>

Fernando Perez wrote:
> Fortunately as Will points out (thanks!), there's good hg <-> git
> support.  I think the reality is that we'll live with git AND hg for a
> while, as both seem to have crossed a threshold of interest, activity
> and quality that can sustain them.

fair enough. As it happens, I haven't had to use git at all yet, but I'm 
sure it won't be long.

> Personally I really like git,

What's most important is that the folks doing most of the work are suing 
the tools they are productive in.

-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov


From fperez.net at gmail.com  Wed Apr 14 19:34:00 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 14 Apr 2010 16:34:00 -0700
Subject: [IPython-dev] Moving to git/github
In-Reply-To: <4BC63510.4010805@noaa.gov>
References: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com> 
	<4BC5ECAE.40904@noaa.gov>
	<s2udb6b5ecc1004141111z513bc3ah8a94cdf5cd22577d@mail.gmail.com>
	<4BC63510.4010805@noaa.gov>
Message-ID: <u2qdb6b5ecc1004141634k161ec22bpd06d4468c4c3155b@mail.gmail.com>

On Wed, Apr 14, 2010 at 2:35 PM, Christopher Barker
<Chris.Barker at noaa.gov> wrote:
> What's most important is that the folks doing most of the work are suing
> the tools they are productive in.

I hadn't considered suing the git developers quite yet, but that may
be a good idea to keep in mind as a business model moving forward ;)

Cheers,

f


From fperez.net at gmail.com  Wed Apr 14 20:40:23 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 14 Apr 2010 17:40:23 -0700
Subject: [IPython-dev] Upgrade to repository format 2a in launchpad finished
Message-ID: <v2udb6b5ecc1004141740s2f907567xdb35518f7445f3a9@mail.gmail.com>

Hi all,

the repo upgrade on LP is done.  You will need to update any local
shared repos you may have with

bzr upgrade --2a

In addition, you will also need to upgrade you branches hosted on
launchpad so you can push back to them, just like I did with the trunk
repo.  For example, for my trunk-dev branch on LP I just did:

bzr upgrade --2a lp:~fdo.perez/ipython/trunk-dev

This upgrade on LP takes a good while (an hour, perhaps two), so do it
from a machine with a stable connection, as it entails constant
network traffic.  I once had mine interrupted and was left with a
'wedged' upgrade because the backup file is in the way:

https://bugs.launchpad.net/bzr/+bug/300001

The lp team on IRC helped me delete the backup file using hitchhiker:

bzr branch lp:hitchhiker

Then:

uqbar[hitchhiker]> ./hitchhiker lp:ipython
Opened bzr+ssh://bazaar.launchpad.net/~ipython-dev/ipython/trunk/
(Cmd) ls
.bzr
backup.bzr
(Cmd) rmtree backup.bzr
(Cmd) ls
.bzr

Done.

I only mention this in case somebody wedges their upgrade, it took me
a bit to find what the solution should be.  Apparently this problem is
fixed in the most recent (beta) bzr release, but getting hitchhiker
was easier than updating all of bzr just for this.

OK, I hope this upgrade doesn't cause anyone any troubles, let me know
if it does.

Cheers,

f


From fperez.net at gmail.com  Wed Apr 14 20:49:23 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 14 Apr 2010 17:49:23 -0700
Subject: [IPython-dev] In-place %editing of methods
In-Reply-To: <hq2m8r$ahs$1@dough.gmane.org>
References: <hpu6sh$nr6$1@dough.gmane.org>
	<m2idb6b5ecc1004121113yb7af2646g652e2095b24a96fa@mail.gmail.com>
	<hq2m8r$ahs$1@dough.gmane.org>
Message-ID: <z2ydb6b5ecc1004141749u256b456elddda0bfc34d9f5cb@mail.gmail.com>

On Tue, Apr 13, 2010 at 2:04 PM, Robert Kern <robert.kern at gmail.com> wrote:
> I have an implementation in my kernmagic package.
>
> http://www.enthought.com/~rkern/cgi-bin/hgwebdir.cgi/kernmagic/
>
> No persistence or unified diffs, but I think that's fine.

Duly noted on bug page, thanks!

Cheers,

f


From fperez.net at gmail.com  Wed Apr 14 22:01:30 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 14 Apr 2010 19:01:30 -0700
Subject: [IPython-dev] GSoC applicants: patch and blog required
In-Reply-To: <w2v2d5cbc321004141808n88b581atc6fdaa0eb5cca81c@mail.gmail.com>
References: <h2ydb6b5ecc1004121321t81261cb9w3c9c99c439bc54e3@mail.gmail.com> 
	<q2o2d5cbc321004121347v600cffb5m6000d81fad27d7ae@mail.gmail.com> 
	<i2idb6b5ecc1004121423ue2bc65b3u95bd98c0626cd288@mail.gmail.com> 
	<u2k2d5cbc321004131755o4fa5df20k682f0e0cc3d0e66e@mail.gmail.com> 
	<l2ydb6b5ecc1004140126wb1f4b82dob027256d86391aa8@mail.gmail.com> 
	<w2v2d5cbc321004141808n88b581atc6fdaa0eb5cca81c@mail.gmail.com>
Message-ID: <x2ldb6b5ecc1004141901rd8530f4ege5192830165df7ae@mail.gmail.com>

Hey,

[ you forgot 'reply to all' for the list, putting it back in ]

On Wed, Apr 14, 2010 at 6:08 PM, Gerardo Gutierrez <muzgash at gmail.com> wrote:
> Hi Fernando.
> When I type make pdf in the trunk working copy (without any changes, and
> obviously the trunk installed) i get this:
> reading sources... [ ?2%] api/generated/IPython.ColorANSI
> Exception occurred:
> ??File
> "/home/muzgash/MyProjects/ipython/docs/sphinxext/inheritance_diagram.py",
> line 107, in _import_class_or_module
> ?? ?"Could not import class or module '%s' specified for inheritance
> diagram" % name)
> ValueError: Could not import class or module 'IPython.ColorANSI' specified
> for inheritance diagram

Mmh, this can *not* be coming from trunk: the module IPython.ColorANSI
was from the 0.10 series, while in trunk the generated file should be:

source/api/generated/IPython.utils.coloransi.txt

It looks like you have an ipython 0.10 being pulled in somewhere...

> I Have the documentation ready and some code that need to be cleaned to
> commit and also, I think I don't know how to merge because when I try i get
> this:
> muzgash at he1:~/MyProjects$ ls
> ipython ?qt-frontend ?qt-frontend-bk
> muzgash at he1:~/MyProjects$ cd qt-frontend
> muzgash at he1:~/MyProjects/qt-frontend$ bzr merge ../ipython/
> Doing on-the-fly conversion from RepositoryFormat2a() to
> RepositoryFormatKnitPack1().
> This may take some time. Upgrade the repositories to the same format for
> better performance.
> bzr: ERROR:
> KnitPackRepository('file:///home/muzgash/MyProjects/qt-frontend/.bzr/repository/')
> is not compatible with
> CHKInventoryRepository('file:///home/muzgash/MyProjects/ipython/.bzr/repository/')
> different rich-root support
> muzgash at he1:~/MyProjects/qt-frontend$ bzr merge ../ipython/ --force
> --uncommitted
> All changes applied successfully.
> But with the last command ?there's no changes at all, the same error I got
> yesterday is there.
> I just need to fix those things, and begin writing the pyzmq module.

Aha, the fun I was dealing with last night.  Sorry to hear that...  I
would suggest you start with a clean repo:

bzr init-repo --2a repo
cd repo
bzr branch lp:ipython
bzr branch lp:~ipython-contrib/ipython/qt-frontend
cd qt-frontend/
bzr merge ../ipython

This should give you a fully merged version of the qt-frontend branch
up to date with trunk, which you can commit and push back.

You can then apply your changes to the qt-frontend branch and push
again your new changes.

Similarly for the zmq stuff, except Omar needs to create the branch,
since that one doesn't exist yet.

Cheers,

f


From vivainio at gmail.com  Thu Apr 15 12:25:52 2010
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 15 Apr 2010 19:25:52 +0300
Subject: [IPython-dev] Moving to git/github
In-Reply-To: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com>
References: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com>
Message-ID: <z2l46cb515a1004150925m19232543u4cf10c7f30ab1149@mail.gmail.com>

On Wed, Apr 14, 2010 at 9:30 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> incompatibilities, ...). ?Once bzr decided to corrupt my repo (I'd
> never seen that from any other VC system!), I had to re-clone all the

Aside: I have absolutely seen git repository (a remote one!) get
corrupted accidentally.

Was gitorious (a truly free service, as opposed to github) considered?

-- 
Ville M. Vainio
http://tinyurl.com/vainio


From fperez.net at gmail.com  Thu Apr 15 12:49:36 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 15 Apr 2010 09:49:36 -0700
Subject: [IPython-dev] Moving to git/github
In-Reply-To: <z2l46cb515a1004150925m19232543u4cf10c7f30ab1149@mail.gmail.com>
References: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com>
	<z2l46cb515a1004150925m19232543u4cf10c7f30ab1149@mail.gmail.com>
Message-ID: <r2qdb6b5ecc1004150949u2fcdf23ei74f94ffdf0b777b4@mail.gmail.com>

On Thu, Apr 15, 2010 at 9:25 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
>
>> incompatibilities, ...). ?Once bzr decided to corrupt my repo (I'd
>> never seen that from any other VC system!), I had to re-clone all the
>
> Aside: I have absolutely seen git repository (a remote one!) get
> corrupted accidentally.

Ouch, that's bad news, and worrysome.

> Was gitorious (a truly free service, as opposed to github) considered?

Honestly I have only played lightly with it.  I have more github
experience than with gitorious simply because several projects I
follow were already on github and I very much like their interface.
My experience with gitorious has been minimal.  They do have a
project/person/team model that's very similar to the LP one, while
github has no 'teams'.

I really like how github allows individual users to offer write access
to branches, how the site can follow the network of forks, their
comment system, and overall their interface: it's fluid and gets
completely out of your way. I have no experience with gitorious at
that level, but I'd be happy to hear comments on this front.

Being fully free is certainly a plus for gitorious, though since we're
not planning on hosting it ourselves, the weight of this consideration
is secondary.  Workflow, support and features are more important in
this case (LP was not free for a long time while we used it and that
didn't really stop us).

I certainly don't want to appear to be imposing a decision, so by all
means do offer any contrasting views so we can come to an informed
final choice.

Cheers,

f


From fperez.net at gmail.com  Thu Apr 15 13:54:44 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 15 Apr 2010 10:54:44 -0700
Subject: [IPython-dev] Windows crash - pyreadline? [was Re: IPython Crash
	Report]
Message-ID: <z2ydb6b5ecc1004151054l7a79e774m2bb2a7bc681dd876@mail.gmail.com>

Howdy,

below is a crash report from a windows user (full report attached).  I
tested with 0.10 on linux and can't reproduce the problem, what I get
is:

In [1]: 'esth'.startswith(None)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/home/fperez/tmp/junk/<ipython console> in <module>()

TypeError: expected a character buffer object


and the session continues OK, but I don't have a windows box right now
that I can test on.

Can anyone see it on windows?
Jorgen, do you think this could be a pyreadline problem?

Thanks for any feedback,

f

On Tue, Apr 13, 2010 at 4:30 PM, Tom Plunket <tom at readyatdawn.com> wrote:
> IPython rocks, thanks for developing it.? Sorry for any stupid formatting
> this email may bring; work requirements y'know?
>
> Anyway- I've never seen an IPython crash before so this was surprising to
> say the least.? I looked at the crash report and it appeared to have no
> history.? I was curious what some_string.startswith(None) would do.
>
> The beginning of my IPython session looks like this.? The last lines?here
> are?in the crash report preceding a bunch of blank-but-numbered lines.? On
> Windows Vista x64 with pyreadline installed.
>
> Python 2.6.4 (r264:75706, Jan 22 2010, 17:24:21) [MSC v.1500 64 bit (AMD64)]
> Type "copyright", "credits" or "license" for more information.
>
> IPython 0.10 -- 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 more.
>
> In [1]: 'esth'.startswith(None)
> ---------------------------------------------------------------------------
> WindowsError?????????????????????????? Python 2.6.4: c:\python26\python.exe
> ?????????????????????????????????????????????????? Tue Apr 13 16:20:03 2010
> A problem occured executing Python code.? Here is the sequence of function
> calls leading up to the error, with the most recent (innermost) call last.
>
> C:\Python26\Scripts\_ctypes\callbacks.c in 'calling callback function'()
> ??? 280
> ??? 281
-------------- next part --------------
***************************************************************************

IPython post-mortem report

IPython version: 0.10 

BZR revision   : 1210 

Platform info  : os.name -> nt, sys.platform -> win32

***************************************************************************

Current user configuration structure:

{'Version': 0,
 '__allownew': True,
 'alias': [],
 'args': [],
 'autocall': 1,
 'autoedit_syntax': 0,
 'autoexec': [],
 'autoindent': 1,
 'automagic': 1,
 'banner': 1,
 'c': '',
 'cache_size': 1000,
 'classic': 0,
 'color_info': 1,
 'colors': 'Linux',
 'confirm_exit': 1,
 'debug': 0,
 'deep_reload': 0,
 'editor': 'notepad',
 'embedded': False,
 'execfile': [],
 'execute': [''],
 'gthread': 0,
 'help': 0,
 'import_all': [],
 'import_mod': [],
 'import_some': [[]],
 'include': [],
 'interact': 0,
 'ipythondir': u'C:\\Users\\Tom\\_ipython',
 'log': 0,
 'logfile': '',
 'logplay': '',
 'magic_docstrings': 0,
 'messages': 1,
 'multi_line_specials': 1,
 'nosep': 0,
 'object_info_string_level': 0,
 'opts': Struct({'__allownew': True}),
 'pdb': 0,
 'pprint': 1,
 'profile': '',
 'prompt_in1': 'In [\\#]: ',
 'prompt_in2': '   .\\D.: ',
 'prompt_out': 'Out[\\#]: ',
 'prompts_pad_left': 1,
 'pydb': 0,
 'pylab': 0,
 'pylab_import_all': 1,
 'q4thread': 0,
 'qthread': 0,
 'quick': 0,
 'quiet': 0,
 'rcfile': 'ipythonrc.ini',
 'readline': 1,
 'readline_merge_completions': 1,
 'readline_omit__names': 0,
 'readline_parse_and_bind': ['tab: complete',
                             '"\\C-l": possible-completions',
                             'set show-all-if-ambiguous on',
                             '"\\C-o": tab-insert',
                             '"\\M-i": "    "',
                             '"\\M-o": "\\d\\d\\d\\d"',
                             '"\\M-I": "\\d\\d\\d\\d"',
                             '"\\C-r": reverse-search-history',
                             '"\\C-s": forward-search-history',
                             '"\\C-p": history-search-backward',
                             '"\\C-n": history-search-forward',
                             '"\\e[A": history-search-backward',
                             '"\\e[B": history-search-forward',
                             '"\\C-k": kill-line',
                             '"\\C-u": unix-line-discard'],
 'readline_remove_delims': '-/~',
 'screen_length': -2,
 'separate_in': '\n',
 'separate_out': '',
 'separate_out2': '',
 'system_header': 'IPython system call: ',
 'system_verbose': 0,
 'term_title': 1,
 'tk': 0,
 'upgrade': 0,
 'wildcards_case_sensitive': 1,
 'wthread': 0,
 'wxversion': '0',
 'xmode': 'Context'}

***************************************************************************

Crash traceback:

---------------------------------------------------------------------------
WindowsError                           Python 2.6.4: c:\python26\python.exe
                                                   Tue Apr 13 16:20:03 2010
A problem occured executing Python code.  Here is the sequence of function
calls leading up to the error, with the most recent (innermost) call last.

C:\Python26\Scripts\_ctypes\callbacks.c in 'calling callback function'()
    280 
    281 
    282 
    283 
    284 
    285 
    286 
    287 
    288 
    289 
    290 
    291 
    292 
    293 
    294 
--> 295 
    296 
    297 
    298 
    299 
    300 
    301 
    302 
    303 
    304 
    305 
    306 
    307 
    308 
    309 
    310 

c:\python26\lib\site-packages\pyreadline-1.5.dev_r0-py2.6.egg\pyreadline\console\console.pyc in hook_wrapper_23(stdin=1905849808L, stdout=1905849856L, prompt='\n\x01\x1b[0;32m\x02In [\x01\x1b[1;32m\x021\x01\x1b[0;32m\x02]: \x01\x1b[0m\x02')
    666         if res and not isinstance(res, str):
    667             raise TypeError, 'readline must return a string.'
    668     except KeyboardInterrupt:
    669         # GNU readline returns 0 on keyboard interrupt
    670         return 0
    671     except EOFError:
    672         # It returns an empty string on EOF
    673         res = ''
    674     except:
    675         print >>sys.stderr, 'Readline internal error'
    676         traceback.print_exc()
    677         res = '\n'
    678     # we have to make a copy because the caller expects to free the result
    679     n = len(res)
    680     p = Console.PyMem_Malloc(n+1)
--> 681     cdll.msvcrt.strncpy(p, res, n+1)
    682     return p
    683 
    684 def hook_wrapper(prompt):
    685     '''Wrap a Python readline so it behaves like GNU readline.'''
    686     try:
    687         # call the Python hook
    688         res = ensure_str(readline_hook(prompt))
    689         # make sure it returned the right sort of thing
    690         if res and not isinstance(res, str):
    691             raise TypeError, 'readline must return a string.'
    692     except KeyboardInterrupt:
    693         # GNU readline returns 0 on keyboard interrupt
    694         return 0
    695     except EOFError:
    696         # It returns an empty string on EOF

WindowsError: exception: access violation writing 0x0000000000000000

***************************************************************************

History of session input:

*** Last line of input (may not be in above history):

From ellisonbg at gmail.com  Thu Apr 15 14:00:31 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 15 Apr 2010 11:00:31 -0700
Subject: [IPython-dev] Moving to git/github
In-Reply-To: <r2qdb6b5ecc1004150949u2fcdf23ei74f94ffdf0b777b4@mail.gmail.com>
References: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com>
	<z2l46cb515a1004150925m19232543u4cf10c7f30ab1149@mail.gmail.com>
	<r2qdb6b5ecc1004150949u2fcdf23ei74f94ffdf0b777b4@mail.gmail.com>
Message-ID: <z2ufa8579a41004151100u5d08f364gd8a85e7921e46e95@mail.gmail.com>

In my mind, the commercial nature of github is an advantage:

* I *want* to have paid, private repos as well.
* Because I am a paying customer, if something goes wrong, there is
(hopefully) a stronger chance that they will be motivated to fix the
issue.

Another point is that github itself is one of the main reasons that I
am in favor of the transition to git.  Launchpad drives me absolutely
crazy, github gives me warm fuzzy feelings and sets my mind at peace.

Cheers,

Brian



On Thu, Apr 15, 2010 at 9:49 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Thu, Apr 15, 2010 at 9:25 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
>>
>>> incompatibilities, ...). ?Once bzr decided to corrupt my repo (I'd
>>> never seen that from any other VC system!), I had to re-clone all the
>>
>> Aside: I have absolutely seen git repository (a remote one!) get
>> corrupted accidentally.
>
> Ouch, that's bad news, and worrysome.
>
>> Was gitorious (a truly free service, as opposed to github) considered?
>
> Honestly I have only played lightly with it. ?I have more github
> experience than with gitorious simply because several projects I
> follow were already on github and I very much like their interface.
> My experience with gitorious has been minimal. ?They do have a
> project/person/team model that's very similar to the LP one, while
> github has no 'teams'.
>
> I really like how github allows individual users to offer write access
> to branches, how the site can follow the network of forks, their
> comment system, and overall their interface: it's fluid and gets
> completely out of your way. I have no experience with gitorious at
> that level, but I'd be happy to hear comments on this front.
>
> Being fully free is certainly a plus for gitorious, though since we're
> not planning on hosting it ourselves, the weight of this consideration
> is secondary. ?Workflow, support and features are more important in
> this case (LP was not free for a long time while we used it and that
> didn't really stop us).
>
> I certainly don't want to appear to be imposing a decision, so by all
> means do offer any contrasting views so we can come to an informed
> final choice.
>
> 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 Apr 15 14:08:13 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 15 Apr 2010 11:08:13 -0700
Subject: [IPython-dev] Moving to git/github
In-Reply-To: <z2ufa8579a41004151100u5d08f364gd8a85e7921e46e95@mail.gmail.com>
References: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com> 
	<z2l46cb515a1004150925m19232543u4cf10c7f30ab1149@mail.gmail.com> 
	<r2qdb6b5ecc1004150949u2fcdf23ei74f94ffdf0b777b4@mail.gmail.com> 
	<z2ufa8579a41004151100u5d08f364gd8a85e7921e46e95@mail.gmail.com>
Message-ID: <x2rdb6b5ecc1004151108w95518322ybcbb86c8e27b59e0@mail.gmail.com>

On Thu, Apr 15, 2010 at 11:00 AM, Brian Granger <ellisonbg at gmail.com> wrote:
> In my mind, the commercial nature of github is an advantage:
>
> * I *want* to have paid, private repos as well.
> * Because I am a paying customer, if something goes wrong, there is
> (hopefully) a stronger chance that they will be motivated to fix the
> issue.

Very valid points,  I just want to add that despite not being a paying
customer, I've had *excellent* response from the github admins with
questions I've asked so far.

> Another point is that github itself is one of the main reasons that I
> am in favor of the transition to git. ?Launchpad drives me absolutely
> crazy, github gives me warm fuzzy feelings and sets my mind at peace.

:)

Cheers,

f


From jorgen.stenarson at bostream.nu  Thu Apr 15 14:14:23 2010
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Thu, 15 Apr 2010 20:14:23 +0200
Subject: [IPython-dev] Windows crash - pyreadline? [was Re: IPython
 Crash Report]
In-Reply-To: <z2ydb6b5ecc1004151054l7a79e774m2bb2a7bc681dd876@mail.gmail.com>
References: <z2ydb6b5ecc1004151054l7a79e774m2bb2a7bc681dd876@mail.gmail.com>
Message-ID: <4BC7577F.2060209@bostream.nu>

Fernando Perez skrev 2010-04-15 19:54:
> Howdy,
>
> below is a crash report from a windows user (full report attached).  I
> tested with 0.10 on linux and can't reproduce the problem, what I get
> is:
>
> In [1]: 'esth'.startswith(None)
> ---------------------------------------------------------------------------
> TypeError                                 Traceback (most recent call last)
>
> /home/fperez/tmp/junk/<ipython console>  in<module>()
>
> TypeError: expected a character buffer object
>
>
> and the session continues OK, but I don't have a windows box right now
> that I can test on.
>
> Can anyone see it on windows?
> Jorgen, do you think this could be a pyreadline problem?
>
I can not reproduce this problem but I'm on XP on 32 bit machine.
However I see the c:\python26\script directory in the traceback and this 
made me think that it could be a setuptools problem. I have seen strange 
things if you launch ipython using the exe file that setuptools 
generates. Can you confirm wether you are using that exe file? If you 
are can you try launching ipython without it.

/J?rgen


> Thanks for any feedback,
>
> f
>
> On Tue, Apr 13, 2010 at 4:30 PM, Tom Plunket<tom at readyatdawn.com>  wrote:
>> IPython rocks, thanks for developing it.  Sorry for any stupid formatting
>> this email may bring; work requirements y'know?
>>
>> Anyway- I've never seen an IPython crash before so this was surprising to
>> say the least.  I looked at the crash report and it appeared to have no
>> history.  I was curious what some_string.startswith(None) would do.
>>
>> The beginning of my IPython session looks like this.  The last lines here
>> are in the crash report preceding a bunch of blank-but-numbered lines.  On
>> Windows Vista x64 with pyreadline installed.
>>
>> Python 2.6.4 (r264:75706, Jan 22 2010, 17:24:21) [MSC v.1500 64 bit (AMD64)]
>> Type "copyright", "credits" or "license" for more information.
>>
>> IPython 0.10 -- 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 more.
>>
>> In [1]: 'esth'.startswith(None)
>> ---------------------------------------------------------------------------
>> WindowsError                           Python 2.6.4: c:\python26\python.exe
>>                                                     Tue Apr 13 16:20:03 2010
>> A problem occured executing Python code.  Here is the sequence of function
>> calls leading up to the error, with the most recent (innermost) call last.
>>
>> C:\Python26\Scripts\_ctypes\callbacks.c in 'calling callback function'()
>>      280
>>      281
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev



From fperez.net at gmail.com  Thu Apr 15 14:25:55 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 15 Apr 2010 11:25:55 -0700
Subject: [IPython-dev] Merging all branches that we can for git transition...
Message-ID: <j2hdb6b5ecc1004151125vfd410b48vde0c85bd73003b88@mail.gmail.com>

Hi all,

the cleanest way to make the transition from bzr to git will be to
merge into trunk various branches we may have in flight. We can create
the git repo with extra branches if need be, and I'll be the one doing
that, but it is a little simpler if things have been merged, and it
makes for a good cleanup point as we look to what's needed for 0.11.

I just merged Laurent's 0.10 bugfixes and Dav's traitlets renames
branches, these are the only two active merge reviews that were ready
for merge.  So I would like anyone who has any branch with work
in-flight that they'd like merged to post and let us know.  Make a
merge request if the changes are substantial, or just reply here if
they are small.  I promise to review all changes and do the merge work
once we're satisfied with the review.

At that point, we'll be ready to simply make the transition to git and
reopen for business :)

Cheers,

f


From fperez.net at gmail.com  Thu Apr 15 17:43:55 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 15 Apr 2010 14:43:55 -0700
Subject: [IPython-dev] Code hosting: github, gitorious, ...?
Message-ID: <v2gdb6b5ecc1004151443tbd314d13m62ecb9313c3708dc@mail.gmail.com>

Hi all,

there were some questions about git hosting, so I want to make sure
that we allow for any points on that front to be clarified.  I'll send
a separate email about bug management to keep each discussion focused
and easy to follow.

For code hosting with git, the basic options are:

* github:

- Brian and I use it heavily and we like it a lot.  Having core
developers experienced with a tool is an important factor, though
obviously not the only one.

- It is free for free projects and has a commercial option; Brian and
I expressed some views on this already, other opinions welcome.

- they explicitly allowed us to host project repos on a 'project'
account, as I don't want to make the main repo be something like
'fperez/ipython'. I think it's healthier to have
'gtihub.com/ipython/reponame' so that the project has an identity
separate from that of any one developer.  Here is their explicit
acknowledgment of this:

http://support.github.com/discussions/email/6289-contact-per-project-account-for-open-source-projects?anon_token=5139fe18a00792fd470a9fe3b7bca187b64ddb8d

- The user interface is *really nice*, very fluid and efficient.  The
team is responsive to user requests and the site continues to improve.
 The code review system allows precise, in-line comments on commits,
their tracking of forks (for new contributors) is very useful, and
their pull request system is great.

- It offers integrated bug tracking. See more on this below, though.


* gitorious:

- It's fully open source, a plus.  Though realistically I don't think
we're looking at self-hosting.

- I know it very little.  I opened an account and played a little with
it, but I have no real usage experience.

- It doesn't offer bug tracking, as far as I can tell.


* other sites, self-hosting:

- I host my private git repos using a self-installed indefero, but I
really don't want to rely on something like this for an open source
project.  We have very limited time for admin work, and hosting always
does take time.

- Beyond gitorious and github, I don't know the other git hosting
platforms at all.


Feedback on this, critical or otherwise, much appreciated.  Based on
this we'll decide how to move forward.

Cheers,

f


From fperez.net at gmail.com  Thu Apr 15 17:45:27 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 15 Apr 2010 14:45:27 -0700
Subject: [IPython-dev] Bug handling: launchpad, github, other?
Message-ID: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com>

Hi all,

We've been fairly diligent about using the LP tracker and I actually
don't mind it too much (it's slow, but I got used to opening many tabs
in parallel so each tab does its thing while I work on the others).
The point is that we do have very valuable information there, which
we're not going to ignore.

But as we change from bzr to git for hosting, what to do with bugs
merits an informed decision. In my mind the options moving forward
are:

1. Stay with launchpad for bug handling, just start pointing to github
urls instead of internal LP ones.

  + less work to do.
  - no integration with the source control system
  - the interface is slow and a bit clunky (Brian has mentioned here
how it drives him mad)


2. Move to github for bugs.

  + good integration with the source control, e.g. bugs can be closed
from commit messages.
  - We'd have to link LP bugs for a while, so the existing ones can be
tracked until completion.

  - **The big negative one in my mind**  I'm not convinced the 'tags
only' approach is a good idea:

Github only offers labels for bugs, so all other information
(ownership, category, status, etc) has to be created via labels.
Effectively every project ends up making up a syntax for how to track
bugs.  While I think that approach is OK for something like email, I
think bug management is a well-defined enough problem that *some*
generic key/value pairs should exist.  That is, bug management is a
problem for which we know a basic model, and by not offering *any*
model, a labels-only system forces everyone to re-invent a known
wheel.  By having a common model, the user interface can offer
efficient access to certain information, like all tickets targeted to
a milestone, or open and owned by someone, etc. These have to be
manually re-created as label-based queries for every project, and
every single time you want them even for one project.

Now, bug tracking at github isn't very old, so it's possible that it
will grow a few key/value fields for the most common uses, but we
can't rely on that happening.  So I'd like to have some thought put
into this, especially if anyone has *actual experience* with
labels-only bug management.  Is it as clunky as I am making it to be,
or am I overly worried?


3. Other? Gitorious has no bug hosting that I can see, it seems all
projects hosted on gitorious have separate bug trackers.  Indefero has
bug tracking, but I think the platform is a bit young for hosting (I
do use it for self-hosting, but for private projects my requirements
are minimal).  I don't know other tools.


I'm a little torn here: I tend to prefer the tight integration between
bugs and source control, so I'm inclined to want to move out of lp.
But I'm not sold on the github approach quite yet.

Again, feedback much appreciated.

Cheers,

f


From robert.kern at gmail.com  Thu Apr 15 18:23:36 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 15 Apr 2010 17:23:36 -0500
Subject: [IPython-dev] Bug handling: launchpad, github, other?
In-Reply-To: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com>
References: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com>
Message-ID: <hq83l9$pu2$1@dough.gmane.org>

On 2010-04-15 16:45 PM, Fernando Perez wrote:
> Hi all,
>
> We've been fairly diligent about using the LP tracker and I actually
> don't mind it too much (it's slow, but I got used to opening many tabs
> in parallel so each tab does its thing while I work on the others).
> The point is that we do have very valuable information there, which
> we're not going to ignore.
>
> But as we change from bzr to git for hosting, what to do with bugs
> merits an informed decision. In my mind the options moving forward
> are:
>
> 1. Stay with launchpad for bug handling, just start pointing to github
> urls instead of internal LP ones.
>
>    + less work to do.
>    - no integration with the source control system
>    - the interface is slow and a bit clunky (Brian has mentioned here
> how it drives him mad)

It drives me mad, too.

> 2. Move to github for bugs.
>
>    + good integration with the source control, e.g. bugs can be closed
> from commit messages.
>    - We'd have to link LP bugs for a while, so the existing ones can be
> tracked until completion.
>
>    - **The big negative one in my mind**  I'm not convinced the 'tags
> only' approach is a good idea:
>
> Github only offers labels for bugs, so all other information
> (ownership, category, status, etc) has to be created via labels.
> Effectively every project ends up making up a syntax for how to track
> bugs.  While I think that approach is OK for something like email, I
> think bug management is a well-defined enough problem that *some*
> generic key/value pairs should exist.  That is, bug management is a
> problem for which we know a basic model, and by not offering *any*
> model, a labels-only system forces everyone to re-invent a known
> wheel.  By having a common model, the user interface can offer
> efficient access to certain information, like all tickets targeted to
> a milestone, or open and owned by someone, etc. These have to be
> manually re-created as label-based queries for every project, and
> every single time you want them even for one project.

Another option would be to use Google Code's issue tracker. While it is sort of 
label-based, that's mostly just an illusion of the data entry UI. Labels of the 
form CamelCaseKey-value basically create new key/value metadata pairs, and the 
project admin can control the taxonomy. I believe it comes with a sensible 
default set.

   http://code.google.com/p/support/wiki/IssueTracker

It looks like you can set up Google Code Subversion repo as a read-only mirror 
of the git trunk. This would probably permit the VCS-issue tracker integration.

   http://code.google.com/p/support/wiki/ImportingFromGit
 
http://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control

Both Launchpad's bug tracker and Google Code's issue tracker have Python APIs, 
so perhaps you could migrate the individual issues.

   http://code.google.com/p/support/wiki/IssueTrackerAPIPython
   https://help.launchpad.net/API

-- 
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 Apr 15 20:53:41 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 15 Apr 2010 17:53:41 -0700
Subject: [IPython-dev] Bug handling: launchpad, github, other?
In-Reply-To: <hq83l9$pu2$1@dough.gmane.org>
References: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com>
	<hq83l9$pu2$1@dough.gmane.org>
Message-ID: <v2xdb6b5ecc1004151753ia18b1accndac2c18c819f1bbd@mail.gmail.com>

On Thu, Apr 15, 2010 at 3:23 PM, Robert Kern <robert.kern at gmail.com> wrote:
> Another option would be to use Google Code's issue tracker. While it is sort of
> label-based, that's mostly just an illusion of the data entry UI. Labels of the
> form CamelCaseKey-value basically create new key/value metadata pairs, and the
> project admin can control the taxonomy. I believe it comes with a sensible
> default set.
>
> ? http://code.google.com/p/support/wiki/IssueTracker

Unfortunately google has decided to unconditionally block Cuba from
access to all of code.google.com. There are US export laws that Google
must follow, but for example Sourceforge has allowed individual
project admins to select whether their project contains
export-restricted code (mostly crypto-related tools), so that most
projects on SF are accessible to Cuba.  Google, on the other hand,
makes this restriction site-wide.

My colleague Matthew Brett, who travels often to Cuba and collaborates
with scientists there, has pointed this out before and I would like to
support the access to open source projects for Cuban residents.  We
have in fact been discussing how to encourage the uptake of scientific
python tools in Cuba (heavily matlab-dominated, at least in some
fields) and it would be good to make sure they can access the tools
we're promoting in the first place.

But it does seem like the Google team did a good job thinking about
this: the apparent simplicity of a labels-only approach with just
enough of an underlying model to provide some useful structure.

If we end up with GH, these are good references to have, if nothing
else, to file as requests with their system.

> It looks like you can set up Google Code Subversion repo as a read-only mirror
> of the git trunk. This would probably permit the VCS-issue tracker integration.
>
> ? http://code.google.com/p/support/wiki/ImportingFromGit
>
> http://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control
>
> Both Launchpad's bug tracker and Google Code's issue tracker have Python APIs,
> so perhaps you could migrate the individual issues.
>
> ? http://code.google.com/p/support/wiki/IssueTrackerAPIPython
> ? https://help.launchpad.net/API

The github one has a web api:

http://develop.github.com/p/issues.html

which for example someone used to write a ruby-based
lighthouse-to-github conversion script:

http://github.com/suitmymind/lighthouse-to-github/blob/master/migrate-lh-to-gh.rb

It looks easy enough to use it as a starting point and do a lp2gh bug migrator.

Thanks!

f


From fperez.net at gmail.com  Thu Apr 15 21:15:05 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 15 Apr 2010 18:15:05 -0700
Subject: [IPython-dev] GSoC applicants: patch and blog required
In-Reply-To: <t2x2d5cbc321004151429h5bdf60a9i2f8e84c98ec15e0f@mail.gmail.com>
References: <h2ydb6b5ecc1004121321t81261cb9w3c9c99c439bc54e3@mail.gmail.com>
	<q2o2d5cbc321004121347v600cffb5m6000d81fad27d7ae@mail.gmail.com>
	<i2idb6b5ecc1004121423ue2bc65b3u95bd98c0626cd288@mail.gmail.com>
	<u2k2d5cbc321004131755o4fa5df20k682f0e0cc3d0e66e@mail.gmail.com>
	<l2ydb6b5ecc1004140126wb1f4b82dob027256d86391aa8@mail.gmail.com>
	<w2v2d5cbc321004141808n88b581atc6fdaa0eb5cca81c@mail.gmail.com>
	<x2ldb6b5ecc1004141901rd8530f4ege5192830165df7ae@mail.gmail.com>
	<t2x2d5cbc321004151429h5bdf60a9i2f8e84c98ec15e0f@mail.gmail.com>
Message-ID: <j2idb6b5ecc1004151815pc7937552m3a022fb5e15fff3@mail.gmail.com>

On Thu, Apr 15, 2010 at 2:29 PM, Gerardo Gutierrez <muzgash at gmail.com> wrote:
> Hi again, this is really strange, I've done all the steps you show above but
> there's another problem :'( ...
> /home/muzgash/MyProjects/ipython/docs/sphinxext/docscrape.py:117:
> UserWarning: Unknown section Options
> ??warn("Unknown section %s" % key)
> reading sources... [ 19%] api/generated/IPython.kernel.clientconnector
> Exception occurred:
> ??File
> "/home/muzgash/MyProjects/ipython/docs/sphinxext/inheritance_diagram.py",
> line 107, in _import_class_or_module
> ?? ?"Could not import class or module '%s' specified for inheritance
> diagram" % name)
> ValueError: Could not import class or module
> 'IPython.kernel.clientconnector' specified for inheritance diagram
> The full traceback has been saved in /tmp/sphinx-err-L_nA3u.log, if you want
> to report the issue to the developers.
> Please also report this if it was a user error, so that a better error
> message can be provided next time.
> Either send bugs to the mailing list at
> <http://groups.google.com/group/sphinx-dev/>,
> or report them in the tracker at
> <http://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks!
> make: *** [latex] Error 1
> And i'm doing this with the trunk (installed).

You needed to have installed

python-foolscap python-nose

Basically, to build the docs you need to have an install of IPython
with full dependencies, not just the command-line client.  This is
because to build the api docs, Sphinx needs to be able to import all
of the modules.

I've just added them in your system (I just logged in and did it from
here), and the docs now build, you can have a look at the pdfs there:

muzgash at he1:~/MyProjects/ipython/docs/build/latex$ ls -ltr *pdf
-rw-r--r-- 1 muzgash muzgash   74773 Apr 15 16:21 two_digit_counts.pdf
-rw-r--r-- 1 muzgash muzgash   41799 Apr 15 16:21 single_digits.pdf
-rw-r--r-- 1 muzgash muzgash   48750 Apr 15 16:21 mec_simple.pdf
-rw-r--r-- 1 muzgash muzgash   50227 Apr 15 16:21 ipython_shell.pdf
-rw-r--r-- 1 muzgash muzgash   95697 Apr 15 16:21 ipcluster_start.pdf
-rw-r--r-- 1 muzgash muzgash   39558 Apr 15 16:21 ipcluster_create.pdf
-rw-r--r-- 1 muzgash muzgash   80828 Apr 15 16:21 hpc_job_manager.pdf
-rw-r--r-- 1 muzgash muzgash   42631 Apr 15 16:21 asian_put.pdf
-rw-r--r-- 1 muzgash muzgash   41078 Apr 15 16:21 asian_call.pdf
-rw-r--r-- 1 muzgash muzgash 4938311 Apr 15 20:13 ipython.pdf
-rw-r--r-- 1 muzgash muzgash  688836 Apr 15 20:14 winhpc_whitepaper.pdf


Cheers,

f


From fperez.net at gmail.com  Thu Apr 15 21:16:59 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 15 Apr 2010 18:16:59 -0700
Subject: [IPython-dev] Bug handling: launchpad, github, other?
In-Reply-To: <hq83l9$pu2$1@dough.gmane.org>
References: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com>
	<hq83l9$pu2$1@dough.gmane.org>
Message-ID: <r2jdb6b5ecc1004151816gbfc16e57t99ab91e0ffbca0a@mail.gmail.com>

On Thu, Apr 15, 2010 at 3:23 PM, Robert Kern <robert.kern at gmail.com> wrote:
> It looks like you can set up Google Code Subversion repo as a read-only mirror
> of the git trunk.

I forgot to mention that github also just added this feature:

http://github.com/blog/626-announcing-svn-support

Cheers,

f


From fperez.net at gmail.com  Thu Apr 15 21:21:18 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 15 Apr 2010 18:21:18 -0700
Subject: [IPython-dev] GSoC applicants: patch and blog required
In-Reply-To: <j2idb6b5ecc1004151815pc7937552m3a022fb5e15fff3@mail.gmail.com>
References: <h2ydb6b5ecc1004121321t81261cb9w3c9c99c439bc54e3@mail.gmail.com>
	<q2o2d5cbc321004121347v600cffb5m6000d81fad27d7ae@mail.gmail.com>
	<i2idb6b5ecc1004121423ue2bc65b3u95bd98c0626cd288@mail.gmail.com>
	<u2k2d5cbc321004131755o4fa5df20k682f0e0cc3d0e66e@mail.gmail.com>
	<l2ydb6b5ecc1004140126wb1f4b82dob027256d86391aa8@mail.gmail.com>
	<w2v2d5cbc321004141808n88b581atc6fdaa0eb5cca81c@mail.gmail.com>
	<x2ldb6b5ecc1004141901rd8530f4ege5192830165df7ae@mail.gmail.com>
	<t2x2d5cbc321004151429h5bdf60a9i2f8e84c98ec15e0f@mail.gmail.com>
	<j2idb6b5ecc1004151815pc7937552m3a022fb5e15fff3@mail.gmail.com>
Message-ID: <u2ndb6b5ecc1004151821pe3413e2i7aea8388306e5292@mail.gmail.com>

Hi,

On Thu, Apr 15, 2010 at 6:15 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>> Hi again, this is really strange, I've done all the steps you show above but
>> there's another problem :'( ...
>> /home/muzgash/MyProjects/ipython/docs/sphinxext/docscrape.py:117:
>> UserWarning: Unknown section Options
>> ??warn("Unknown section %s" % key)
>> reading sources... [ 19%] api/generated/IPython.kernel.clientconnector
>> Exception occurred:
>> ??File
>> "/home/muzgash/MyProjects/ipython/docs/sphinxext/inheritance_diagram.py",
>> line 107, in _import_class_or_module
>> ?? ?"Could not import class or module '%s' specified for inheritance
>> diagram" % name)
>> ValueError: Could not import class or module
>> 'IPython.kernel.clientconnector' specified for inheritance diagram
>> The full traceback has been saved in /tmp/sphinx-err-L_nA3u.log, if you want
>> to report the issue to the developers.

I should have also added that you need to get used to debugging these
kinds of problems, as they are a common occurrence.  The error message
there says pretty much everything you need to do, as it says:

: Could not import class or module 'IPython.kernel.clientconnector'

With that, you go into ipython and try to import
IPython.kernel.clientconnector, which shows you the underlying error:

ImportError                               Traceback (most recent call last)

/home/muzgash/MyProjects/ipython/docs/<ipython console> in <module>()

/usr/lib/python2.5/site-packages/IPython/kernel/clientconnector.py in <module>()
     16 import os
     17
---> 18 from IPython.kernel.fcutil import (
     19     Tub,
     20     find_furl,

/usr/lib/python2.5/site-packages/IPython/kernel/fcutil.py in <module>()
     24 from twisted.python import log
     25
---> 26 import foolscap
     27 try:
     28     from foolscap.api import Tub, UnauthenticatedTub

ImportError: No module named foolscap

Aha, you need something called 'foolscap'.  Then a bit of searching
will tell you that the actual package name is 'python-foolscap', so
you type:

apt-get install python-foolscap

and the problem is solved.

Debugging these types of errors may look nasty, but it's a basic
survival skill wen developing code, which you must acquire.

Cheers,

f


From robert.kern at gmail.com  Thu Apr 15 22:01:39 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 15 Apr 2010 21:01:39 -0500
Subject: [IPython-dev] Bug handling: launchpad, github, other?
In-Reply-To: <v2xdb6b5ecc1004151753ia18b1accndac2c18c819f1bbd@mail.gmail.com>
References: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com>	<hq83l9$pu2$1@dough.gmane.org>
	<v2xdb6b5ecc1004151753ia18b1accndac2c18c819f1bbd@mail.gmail.com>
Message-ID: <hq8gf9$p4u$1@dough.gmane.org>

On 2010-04-15 19:53 , Fernando Perez wrote:

> But it does seem like the Google team did a good job thinking about
> this: the apparent simplicity of a labels-only approach with just
> enough of an underlying model to provide some useful structure.
>
> If we end up with GH, these are good references to have, if nothing
> else, to file as requests with their system.

Well, not quite. Like I said, Google Code's labels only look like labels. They 
are actually flexible, possibly ad hoc, field-based metadata (or can be; some of 
the labels are just labels). For example, you could have a DueBy field with 
labels like DueBy-2010-04-15. In the table view, a DueBy column would appear, 
and 2010-04-15 would appear in the cell for that issue. With GitHub's labels, 
every single DueBy-<date> label would appear in the list of available labels. 
That would quickly make an unusable UI.

-- 
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 Apr 15 23:17:43 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 15 Apr 2010 20:17:43 -0700
Subject: [IPython-dev] Bug handling: launchpad, github, other?
In-Reply-To: <hq8gf9$p4u$1@dough.gmane.org>
References: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com>
	<hq83l9$pu2$1@dough.gmane.org>
	<v2xdb6b5ecc1004151753ia18b1accndac2c18c819f1bbd@mail.gmail.com>
	<hq8gf9$p4u$1@dough.gmane.org>
Message-ID: <g2pdb6b5ecc1004152017zc7607b21t432fee90afed8522@mail.gmail.com>

On Thu, Apr 15, 2010 at 7:01 PM, Robert Kern <robert.kern at gmail.com> wrote:
>>
>> If we end up with GH, these are good references to have, if nothing
>> else, to file as requests with their system.
>
> Well, not quite. Like I said, Google Code's labels only look like labels. They
> are actually flexible, possibly ad hoc, field-based metadata (or can be; some of
> the labels are just labels). For example, you could have a DueBy field with
> labels like DueBy-2010-04-15. In the table view, a DueBy column would appear,
> and 2010-04-15 would appear in the cell for that issue. With GitHub's labels,
> every single DueBy-<date> label would appear in the list of available labels.
> That would quickly make an unusable UI.

I perhaps didn't express myself clearly, what I meant was: asking GH
to provide support for the Google model of 'labels' that actually hide
key/value pairs in CamelCase-value syntax.  I actually really like
this solution by google: people who just want labels can have them,
and those who would like a real key/value structure can also define it
quite simply.

They've even thought of single/multi valued label handling, and
apparently provide control over that.

In summary, I really really do like that issue tracker design a lot,
many thanks for pointing that out.

Take care,

f


From ellisonbg at gmail.com  Fri Apr 16 01:09:53 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 15 Apr 2010 22:09:53 -0700
Subject: [IPython-dev] Bug handling: launchpad, github, other?
In-Reply-To: <hq83l9$pu2$1@dough.gmane.org>
References: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com>
	<hq83l9$pu2$1@dough.gmane.org>
Message-ID: <s2tfa8579a41004152209r8e2b3020x3bb56423da5527d0@mail.gmail.com>

On Thu, Apr 15, 2010 at 3:23 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On 2010-04-15 16:45 PM, Fernando Perez wrote:
>> Hi all,
>>
>> We've been fairly diligent about using the LP tracker and I actually
>> don't mind it too much (it's slow, but I got used to opening many tabs
>> in parallel so each tab does its thing while I work on the others).
>> The point is that we do have very valuable information there, which
>> we're not going to ignore.
>>
>> But as we change from bzr to git for hosting, what to do with bugs
>> merits an informed decision. In my mind the options moving forward
>> are:
>>
>> 1. Stay with launchpad for bug handling, just start pointing to github
>> urls instead of internal LP ones.
>>
>> ? ?+ less work to do.
>> ? ?- no integration with the source control system
>> ? ?- the interface is slow and a bit clunky (Brian has mentioned here
>> how it drives him mad)
>
> It drives me mad, too.
>
>> 2. Move to github for bugs.
>>
>> ? ?+ good integration with the source control, e.g. bugs can be closed
>> from commit messages.
>> ? ?- We'd have to link LP bugs for a while, so the existing ones can be
>> tracked until completion.
>>
>> ? ?- **The big negative one in my mind** ?I'm not convinced the 'tags
>> only' approach is a good idea:
>>
>> Github only offers labels for bugs, so all other information
>> (ownership, category, status, etc) has to be created via labels.
>> Effectively every project ends up making up a syntax for how to track
>> bugs. ?While I think that approach is OK for something like email, I
>> think bug management is a well-defined enough problem that *some*
>> generic key/value pairs should exist. ?That is, bug management is a
>> problem for which we know a basic model, and by not offering *any*
>> model, a labels-only system forces everyone to re-invent a known
>> wheel. ?By having a common model, the user interface can offer
>> efficient access to certain information, like all tickets targeted to
>> a milestone, or open and owned by someone, etc. These have to be
>> manually re-created as label-based queries for every project, and
>> every single time you want them even for one project.
>
> Another option would be to use Google Code's issue tracker. While it is sort of
> label-based, that's mostly just an illusion of the data entry UI. Labels of the
> form CamelCaseKey-value basically create new key/value metadata pairs, and the
> project admin can control the taxonomy. I believe it comes with a sensible
> default set.
>
> ? http://code.google.com/p/support/wiki/IssueTracker

I too like the google issue tracker.  That and the one for github are
probably my favorites.

Brian

> It looks like you can set up Google Code Subversion repo as a read-only mirror
> of the git trunk. This would probably permit the VCS-issue tracker integration.
>
> ? http://code.google.com/p/support/wiki/ImportingFromGit
>
> http://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control
>
> Both Launchpad's bug tracker and Google Code's issue tracker have Python APIs,
> so perhaps you could migrate the individual issues.
>
> ? http://code.google.com/p/support/wiki/IssueTrackerAPIPython
> ? https://help.launchpad.net/API
>
> --
> 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
>
> _______________________________________________
> 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 dwf at cs.toronto.edu  Fri Apr 16 13:15:47 2010
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Fri, 16 Apr 2010 13:15:47 -0400
Subject: [IPython-dev] Moving to git/github
In-Reply-To: <z2ufa8579a41004151100u5d08f364gd8a85e7921e46e95@mail.gmail.com>
References: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com>
	<z2l46cb515a1004150925m19232543u4cf10c7f30ab1149@mail.gmail.com>
	<r2qdb6b5ecc1004150949u2fcdf23ei74f94ffdf0b777b4@mail.gmail.com>
	<z2ufa8579a41004151100u5d08f364gd8a85e7921e46e95@mail.gmail.com>
Message-ID: <43577B5A-8D7F-42C0-A27C-E583F4161D49@cs.toronto.edu>

On 15-Apr-10, at 2:00 PM, Brian Granger wrote:

> Another point is that github itself is one of the main reasons that I
> am in favor of the transition to git.  Launchpad drives me absolutely
> crazy, github gives me warm fuzzy feelings and sets my mind at peace.

+1 on git and GitHub in general. I think I've only ever submitted one  
patch to IPython but I think I'd be more inclined to do so if not for  
the albatross of learning Launchpad hanging over my head. Every time I  
try to do something as simple as report a bug or browse the source I  
can't seem to find the right bloody menu.

David


From andresete.chaos at gmail.com  Fri Apr 16 13:55:55 2010
From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=)
Date: Fri, 16 Apr 2010 12:55:55 -0500
Subject: [IPython-dev] ipython-zmp
Message-ID: <o2qad1253101004161055vdc348a53oae534c3411d619cc@mail.gmail.com>

Hi Guys.
I am applying to GSoc with a projetc ipython-zmq, please read de
documentation in
http://ipython.scipy.org/moin/GSoC2010/IPythonZmq
or
http://ipythonzmq.blogspot.com/

  and let me know your suggestions to improve this...

The new branch with doc was create in contrib-dev
download :
bzr  clone  lp:~ipython-contrib/+junk/ipython-zmq

Thanks guys!!



-- 
Omar Andres Zapata Mesa
Integrante Grupo  de F?sica y Astrof?sica Computacional
Division Ciencias de la Computaci?n (FACom Dev)
Universidad de Antioquia
Usuario Linux  #490962
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100416/559f6fb7/attachment.html>

From andresete.chaos at gmail.com  Fri Apr 16 16:41:10 2010
From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=)
Date: Fri, 16 Apr 2010 15:41:10 -0500
Subject: [IPython-dev] About contrib-dev branch
Message-ID: <q2tad1253101004161341wa3bc6f95sa0be95ca9a076c48@mail.gmail.com>

hi all.
Why my branch in contrib-dev has +junk in the path?


-- 
Omar Andres Zapata Mesa
Integrante Grupo  de F?sica y Astrof?sica Computacional
Division Ciencias de la Computaci?n (FACom Dev)
Universidad de Antioquia
Usuario Linux  #490962
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100416/4d2f664a/attachment.html>

From muzgash.lists at gmail.com  Fri Apr 16 16:51:19 2010
From: muzgash.lists at gmail.com (Gerardo Gutierrez)
Date: Fri, 16 Apr 2010 15:51:19 -0500
Subject: [IPython-dev] IPythonQt GSoC update
Message-ID: <y2v9764d2d91004161351p962e27c9r644189142a2f2b15@mail.gmail.com>

Hi guys.

I'm upgrading the branch to the format 2a (or something, and it's awfully
slow), when this is over i'm going to push the documentation about the
project, it's still a little raw but since it's a prerequisite it is pretty
urgent.
Ii'm goint to write something deeper during the day but please, atl least go
into the blog and make some comments to help me with this.

I'm listing the links (they're practicaly the same):

https://code.launchpad.net/~ipython-contrib/ipython/qt-frontend
http://ipythonqt.blogspot.com/
http://ipython.scipy.org/moin/GSoC2010/IPythonQt
http://he1.udea.edu.co/gweb/projects/index.html#ipqt
Thanks.

Best regards.
--
Gerardo Guti?rrez Guti?rrez <http://he1.udea.edu.co/gweb>
Physics student
Universidad de Antioquia
Computationalphysics and astrophysics group
(FACom<http://urania.udea.edu.co/sites/sites.php>
)
Computational science and development
branch(FACom-dev<http://urania.udea.edu.co/sites/facom-dev/>
)
Usuario Linux #492295
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100416/c6219c21/attachment.html>

From robert.kern at gmail.com  Fri Apr 16 18:55:18 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 16 Apr 2010 17:55:18 -0500
Subject: [IPython-dev] Bug handling: launchpad, github, other?
In-Reply-To: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com>
References: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com>
Message-ID: <hqapsm$mfb$1@dough.gmane.org>

On 2010-04-15 16:45 PM, Fernando Perez wrote:

> 3. Other?

BitBucket's issue tracker is pretty nice.

<ducks>  :-)

-- 
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 muzgash.lists at gmail.com  Fri Apr 16 19:31:30 2010
From: muzgash.lists at gmail.com (Gerardo Gutierrez)
Date: Fri, 16 Apr 2010 18:31:30 -0500
Subject: [IPython-dev] notebook-like format for IPythonQt sessions.
Message-ID: <g2w9764d2d91004161631t1fb449pa74b6b9a379ec4f@mail.gmail.com>

Hi all.

I want to resume a discussion that I had with Fernando here in Medell?n a
month or 2 ago and we agreed that it was an importatn part of the design of
this project that has to be asked here.

That is about the format in wich IPythonQt should save sessions for
reloading.
We were thinking ahead with the project trying to make a help widget similar
to the one in mathematica(that is the best characteristic of it) so the help
widget would read form a website like python's tutorial and put the code
blocks in IPythonQt's cells of code and the text in text cells, this will be
then writing a parser for plain text or HTML(it's better the first option i
think) because those are natural ways for a QTextEdit to interpret a
webpage.
Then it will be natural to write the notebook sessions as plain text or
HTML.
We talked also about saving the sessions in rst format that will be native
for ipython's documentation. I've not really evaluated the pros and cons of
this choice.

This is an important part for the design of every client/interface that'll
talk to ipython's kernel, so they can share the same type of documentation.

Have a good day.


Best regards.


https://code.launchpad.net/~ipython-contrib/ipython/qt-frontend
http://ipythonqt.blogspot.com/
http://ipython.scipy.org/moin/GSoC2010/IPythonQt
--
Gerardo Guti?rrez Guti?rrez <http://he1.udea.edu.co/gweb>
Physics student
Universidad de Antioquia
Computational physics and astrophysics group
(FACom<http://urania.udea.edu.co/sites/sites.php>
)
Computational science and development
branch(FACom-dev<http://urania.udea.edu.co/sites/facom-dev/>
)
Usuario Linux #492295
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100416/996b0c05/attachment.html>

From muzgash.lists at gmail.com  Sat Apr 17 20:02:01 2010
From: muzgash.lists at gmail.com (Gerardo Gutierrez)
Date: Sat, 17 Apr 2010 19:02:01 -0500
Subject: [IPython-dev] notebook-like format for IPythonQt sessions.
In-Reply-To: <g2w9764d2d91004161631t1fb449pa74b6b9a379ec4f@mail.gmail.com>
References: <g2w9764d2d91004161631t1fb449pa74b6b9a379ec4f@mail.gmail.com>
Message-ID: <m2x9764d2d91004171702pcdc5c5bcx5491158154a6b844@mail.gmail.com>

Ok i'm going to paste a fragment of a document about this topic (that I've
not noticed until today)


*The frontend would store, for now, 5 types of data:

#. Input: this is python/ipython code to be executed.

#. Output (python): result of executing Inputs.

#. Standard output: from subprocesses.

#. Standard error: from subprocesses.

#. Text: arbitrary text. For now, we'll just store plain text and will defer
to the user on how to format it, though it should be valid reST if it is
later to be converted into html/pdf.

The non-text cells would be stored on-disk as follows::

.. input-cell::
:id: 1

3+3

.. output-cell::
:id: 1

6

.. input-cell::
:id: 2

ls

.. stdout-cell::
:id: 2

a.py b.py

.. input-cell::
:id: 3

!askdfj

.. stderr-cell::
:id: 3

sh: askdfj: command not found*


This document clears some ideas, since the natural way for an IPython's
frontend (not only IPythonQt) to load data is rst in wich Python's and
IPython's documentation is written.

Still I want to resume this discussion because there are still some points
to clear such exporting and importing formats or if the saved session should
write also the output, etc.

I want to do this because I think it is not  so difficult to implement and
it should be part of the first release.

best regards.


On 16 April 2010 18:31, Gerardo Gutierrez <muzgash.lists at gmail.com> wrote:

> Hi all.
>
> I want to resume a discussion that I had with Fernando here in Medell?n a
> month or 2 ago and we agreed that it was an importatn part of the design of
> this project that has to be asked here.
>
> That is about the format in wich IPythonQt should save sessions for
> reloading.
> We were thinking ahead with the project trying to make a help widget
> similar to the one in mathematica(that is the best characteristic of it) so
> the help widget would read form a website like python's tutorial and put the
> code blocks in IPythonQt's cells of code and the text in text cells, this
> will be then writing a parser for plain text or HTML(it's better the first
> option i think) because those are natural ways for a QTextEdit to interpret
> a webpage.
> Then it will be natural to write the notebook sessions as plain text or
> HTML.
> We talked also about saving the sessions in rst format that will be native
> for ipython's documentation. I've not really evaluated the pros and cons of
> this choice.
>
> This is an important part for the design of every client/interface that'll
> talk to ipython's kernel, so they can share the same type of documentation.
>
> Have a good day.
>
>
> Best regards.
>
>
> https://code.launchpad.net/~ipython-contrib/ipython/qt-frontend
> http://ipythonqt.blogspot.com/
> http://ipython.scipy.org/moin/GSoC2010/IPythonQt
> --
> Gerardo Guti?rrez Guti?rrez <http://he1.udea.edu.co/gweb>
> Physics student
> Universidad de Antioquia
> Computational physics and astrophysics group (FACom<http://urania.udea.edu.co/sites/sites.php>
> )
> Computational science and development branch(FACom-dev<http://urania.udea.edu.co/sites/facom-dev/>
> )
> Usuario Linux #492295
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100417/ccd5adb7/attachment.html>

From robert.kern at gmail.com  Sat Apr 17 21:08:50 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Sat, 17 Apr 2010 20:08:50 -0500
Subject: [IPython-dev] notebook-like format for IPythonQt sessions.
In-Reply-To: <m2x9764d2d91004171702pcdc5c5bcx5491158154a6b844@mail.gmail.com>
References: <g2w9764d2d91004161631t1fb449pa74b6b9a379ec4f@mail.gmail.com>
	<m2x9764d2d91004171702pcdc5c5bcx5491158154a6b844@mail.gmail.com>
Message-ID: <hqdm49$b8f$1@dough.gmane.org>

On 2010-04-17 19:02 , Gerardo Gutierrez wrote:
> Ok i'm going to paste a fragment of a document about this topic (that
> I've not noticed until today)
>
>
> /The frontend would store, for now, 5 types of data:
>
> #. Input: this is python/ipython code to be executed.
>
> #. Output (python): result of executing Inputs.
>
> #. Standard output: from subprocesses.
>
> #. Standard error: from subprocesses.
>
> #. Text: arbitrary text. For now, we'll just store plain text and will defer
> to the user on how to format it, though it should be valid reST if it is
> later to be converted into html/pdf.
>
> The non-text cells would be stored on-disk as follows::
>
> .. input-cell::
> :id: 1
>
> 3+3
>
> .. output-cell::
> :id: 1
>
> 6
>
> .. input-cell::
> :id: 2
>
> ls
>
> .. stdout-cell::
> :id: 2
>
> a.py b.py
>
> .. input-cell::
> :id: 3
>
> !askdfj
>
> .. stderr-cell::
> :id: 3
>
> sh: askdfj: command not found/
>
>
> This document clears some ideas, since the natural way for an IPython's
> frontend (not only IPythonQt) to load data is rst in wich Python's and
> IPython's documentation is written.

I would not say that it is natural, no. reST is a fine text markup, but not a 
very good datastore. The parser is difficult to work with, and there aren't any 
tools for generating valid reST from a parsed description.

I highly recommend using xml.etree to parse and generate a simple XML format.

-- 
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 andresete.chaos at gmail.com  Sat Apr 17 22:16:03 2010
From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=)
Date: Sat, 17 Apr 2010 19:16:03 -0700
Subject: [IPython-dev] notebook-like format for IPythonQt sessions.
In-Reply-To: <hqdm49$b8f$1@dough.gmane.org>
References: <g2w9764d2d91004161631t1fb449pa74b6b9a379ec4f@mail.gmail.com> 
	<m2x9764d2d91004171702pcdc5c5bcx5491158154a6b844@mail.gmail.com> 
	<hqdm49$b8f$1@dough.gmane.org>
Message-ID: <w2sad1253101004171916g665424dbz35c20f5081a6b1ed@mail.gmail.com>

I think xml  is a good idea, because you can set data in  tags, referencing
different types of inputs and outputs  in the ipython-qt?s editor, like
stdout, stderr, ipython err, ipython out, etc.

some like

<cell number=1>
               <input type=documentation>
                =============================
                rst docuemnation example in ipython-qt
                =============================

               subtitle example
               ------------------------
               etc....
              </input>
</cell>

<cell number=2>
                  <input type=ipython>  %run hello.py </input>
                  <ouput type=stdout> hello world ! </input>
</cell>

<cell number=3>
                   <input type=comment> #some python/iptyhon comment code
</input>
</cell>



2010/4/17 Robert Kern <robert.kern at gmail.com>

> On 2010-04-17 19:02 , Gerardo Gutierrez wrote:
> > Ok i'm going to paste a fragment of a document about this topic (that
> > I've not noticed until today)
> >
> >
> > /The frontend would store, for now, 5 types of data:
> >
> > #. Input: this is python/ipython code to be executed.
> >
> > #. Output (python): result of executing Inputs.
> >
> > #. Standard output: from subprocesses.
> >
> > #. Standard error: from subprocesses.
> >
> > #. Text: arbitrary text. For now, we'll just store plain text and will
> defer
> > to the user on how to format it, though it should be valid reST if it is
> > later to be converted into html/pdf.
> >
> > The non-text cells would be stored on-disk as follows::
> >
> > .. input-cell::
> > :id: 1
> >
> > 3+3
> >
> > .. output-cell::
> > :id: 1
> >
> > 6
> >
> > .. input-cell::
> > :id: 2
> >
> > ls
> >
> > .. stdout-cell::
> > :id: 2
> >
> > a.py b.py
> >
> > .. input-cell::
> > :id: 3
> >
> > !askdfj
> >
> > .. stderr-cell::
> > :id: 3
> >
> > sh: askdfj: command not found/
> >
> >
> > This document clears some ideas, since the natural way for an IPython's
> > frontend (not only IPythonQt) to load data is rst in wich Python's and
> > IPython's documentation is written.
>
> I would not say that it is natural, no. reST is a fine text markup, but not
> a
> very good datastore. The parser is difficult to work with, and there aren't
> any
> tools for generating valid reST from a parsed description.
>
> I highly recommend using xml.etree to parse and generate a simple XML
> format.
>
> --
> 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
>
> _______________________________________________
> 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/20100417/2f4c30f2/attachment.html>

From andresete.chaos at gmail.com  Sun Apr 18 16:14:27 2010
From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=)
Date: Sun, 18 Apr 2010 15:14:27 -0500
Subject: [IPython-dev] Porting python3
Message-ID: <x2jad1253101004181314h84660065jf517930a1eaac226@mail.gmail.com>

Hi all,
I am working in port iplib and some core files of ipython to python3, to
make some test in the system zmq,
but is better know if we have some plan to do this or some especail repo
with someting writed.


Thanks!


-- 
Omar Andres Zapata Mesa
Auxiliar programmer in Phenomenology of Fundamental Interactions Group  (
Gfif <http://gfif.udea.edu.co/>)
Programmer Computational Physics and Astrophysics Group
Division of computer science (FACom <http://http//urania.udea.edu.co/sites>)
Ingenier?a de Sistemas
Universidad de Antioquia
Usuario Linux  #490962
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100418/9872f392/attachment.html>

From muzgash.lists at gmail.com  Mon Apr 19 02:35:23 2010
From: muzgash.lists at gmail.com (Gerardo Gutierrez)
Date: Mon, 19 Apr 2010 01:35:23 -0500
Subject: [IPython-dev] IPythonQt GSoC update
In-Reply-To: <y2v9764d2d91004161351p962e27c9r644189142a2f2b15@mail.gmail.com>
References: <y2v9764d2d91004161351p962e27c9r644189142a2f2b15@mail.gmail.com>
Message-ID: <w2o9764d2d91004182335x6b657bb6lbdd736683c092b51@mail.gmail.com>

Hi all.

Some later updates:

*Mark Summerfield wrote on the blog:

I think you will find QPlainTextEdit more suitable that QTextEdit. Its
layout engine is much faster and it supports colors, bold, etc. (It doesn't
support tables, lists & frames, but presumably you don't need them.) Also,
you can use QSyntaxHighlighter with QPlainTextEdit just the same as
QTextEdit.

I don't really had that in mind just because of the easiness of exporting
the entire session to html, but the differences between QPlainTextEdit and
QTextEdit are minimal. so the design can be initially with a QPlainTextEdit
and if something comes up the update to a QTextEdit should be easy enough to
not to worry for now since the exporting and saving of sessions are still in
discussion.

*The documentation (in the blog, wiki and branch) has been updated, it has
more details about each one of the two main parts of the project and a
required piece of documentation for the event ("possible future
directions"). Please let us know your ideas or questions writing ni the blog
or through here, we'll appreciate your support.



Best regards.
--
Gerardo Guti?rrez Guti?rrez <http://he1.udea.edu.co/gweb>
Physics student
Universidad de Antioquia
Computational physics and astrophysics group
(FACom<http://urania.udea.edu.co/sites/sites.php>
)
Computational science and development
branch(FACom-dev<http://urania.udea.edu.co/sites/facom-dev/>
)
Usuario Linux #492295






On 16 April 2010 15:51, Gerardo Gutierrez <muzgash.lists at gmail.com> wrote:

> Hi guys.
>
> I'm upgrading the branch to the format 2a (or something, and it's awfully
> slow), when this is over i'm going to push the documentation about the
> project, it's still a little raw but since it's a prerequisite it is pretty
> urgent.
> Ii'm goint to write something deeper during the day but please, atl least
> go into the blog and make some comments to help me with this.
>
> I'm listing the links (they're practicaly the same):
>
> https://code.launchpad.net/~ipython-contrib/ipython/qt-frontend
> http://ipythonqt.blogspot.com/
> http://ipython.scipy.org/moin/GSoC2010/IPythonQt
> http://he1.udea.edu.co/gweb/projects/index.html#ipqt
> Thanks.
>
> Best regards.
> --
> Gerardo Guti?rrez Guti?rrez <http://he1.udea.edu.co/gweb>
> Physics student
> Universidad de Antioquia
> Computationalphysics and astrophysics group (FACom<http://urania.udea.edu.co/sites/sites.php>
> )
> Computational science and development branch(FACom-dev<http://urania.udea.edu.co/sites/facom-dev/>
> )
> Usuario Linux #492295
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100419/1f0031fb/attachment.html>

From muzgash.lists at gmail.com  Mon Apr 19 03:37:17 2010
From: muzgash.lists at gmail.com (Gerardo Gutierrez)
Date: Mon, 19 Apr 2010 02:37:17 -0500
Subject: [IPython-dev] IPythonQt GSoC update
In-Reply-To: <w2o9764d2d91004182335x6b657bb6lbdd736683c092b51@mail.gmail.com>
References: <y2v9764d2d91004161351p962e27c9r644189142a2f2b15@mail.gmail.com>
	<w2o9764d2d91004182335x6b657bb6lbdd736683c092b51@mail.gmail.com>
Message-ID: <y2p9764d2d91004190037l63b12171t9245cff412131b7@mail.gmail.com>

Here I'm forwarding another couple of e-mails  from a discussion with Mark
Summerfield. It is pretty exciting to have the interest (I think) and the
opinion of such a great programmer.


Hi Mark, as always a pleasure to receive your comments.

*On 19 April 2010 01:25, Mark Summerfield <mark at qtrac.eu> wrote:
Hi Gerardo,

It took me a moment or so but I think I understand.

"In [1]" is the first input, then comes the first output "NameError...",
then the next input "In [2]", then the second output "Out [2]...".*

Out[2] would mean the output of In[2].
There are various types of otputs in IPython like that error from the first
output that will not be referenced, I'll explain below.

*But I don't understand why you need to name the outputs? Also "In [1]:",
"In [2]:" etc., seems a bit long, I'd have thought that "#1:", "#2",
etc. would be sufficient for input, and no label for output? (Unless of
course the output can be referred to?)*
*
*This type of reference is to keep the notation of IPython. Also in IPython
all outputs are stored in a dictionary named Out, so you can type Out[2] or
the alias _2 to get the output of the second input for example.

*Regarding the GUI, how can the user navigate to earlier in/out
sequences since there is no scrollbar?*

In the snapshot there's no scrolling bar yet, because it is a prototype of
the front view (and because there are no enough cells), so it still doesn't
do anything at all(but being nice) but definitively it has to have a
scrollbar.

*Also, it looks like only the File menu has a keyboard accelerator. I
very much hope that you will make the entire user interface keyboard
navigable for those who cannot use the mouse (and for fast typists who
don't want to use the mouse).*
*
*Sure, I myself am not a fan of mouse and the goal is to reach a lot of
end-users.

*I haven't used ipython, but from your screenshot I'm guessing that
"Magic Commands" are shell-like commands that are understood alongside
pure python in an input editor? Might there not be more than 6 of these?
Shouldn't they be in a QScrollArea (or maybe they are already?)*
*
*Magic commands are IPython's functions which allow you to control the
behaviour of IPython itself and also a lot of system-type features. They are
used typing a % before the magic command, you can list them with %lsmagic
and view the documentation with %magic.
Yes, there would be a scrollbar too, but as I said above this is just a
protoype.

*Good luck!*

Thanks again Mark, all this important details are going directly into my
TODO list. And most importantly I have come to realize that that kind of
information should be explained in a better way for Qt developers, people
who don't use IPython or a curious non-related plausible user.

I hope I have answered your questions and as always, any comment that you
have about this project would be very welcome.




P.D. About the last e-mail, the second paragraph ("I don't really...") is my
answer to what Mark commented in the blog.




Best regards.
--
Gerardo Guti?rrez Guti?rrez <http://he1.udea.edu.co/gweb>
Physics student
Universidad de Antioquia
Computational physics and astrophysics group
(FACom<http://urania.udea.edu.co/sites/sites.php>
)
Computational science and development
branch(FACom-dev<http://urania.udea.edu.co/sites/facom-dev/>
)
Usuario Linux #492295
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100419/d1c9d54c/attachment.html>

From stefan at sun.ac.za  Mon Apr 19 16:37:06 2010
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 19 Apr 2010 22:37:06 +0200
Subject: [IPython-dev] Engineering formatting
Message-ID: <p2t9457e7c81004191337pe93de202na537c0bd38587206@mail.gmail.com>

Hi all,

This is probably an easy question, but how do I tweak IPython to
display my numerical results in engineering notation?

Regards
St?fan


From wackywendell at gmail.com  Tue Apr 20 08:55:00 2010
From: wackywendell at gmail.com (Wendell Smith)
Date: Tue, 20 Apr 2010 14:55:00 +0200
Subject: [IPython-dev] Curses Frontend Update
Message-ID: <4BCDA424.1080609@gmail.com>

Hello!

I have been busy coding away, trying to get two prototypes written for 
the eventual curses frontend.

They are EXTREMELY basic - they don't even interpret code, just spit it 
back out (although in the right place and correctly colored). They are 
full of bugs, don't resize well, etc. - but, well, they are prototypes.

What they do:
They both have 3 windows: completions, output, and input. The 
completions window shows some default text, the input window accepts 
text input, and after hitting enter or <ctrl-g>, the entered code is 
highlighted and displayed in the output window.

I wrote these both mainly to compare urwid and curses, which I think 
they do fairly well. the urwid library is quite nice, and although 
documentation is not perfect, it is good, and the whole thing provides 
far more than curses - curses requires you to manually handle resizing, 
for example. The code for the urwid part is therefore far simpler, and 
was written much faster. It of course requires urwid (easy_install 
urwid), and both require pygments (also available with easy_install). 
Urwid is much nicer... but development is only semi-active, and they 
don't seem at all prepared to port to python3, which is of course important.

Anyways, please download the code, run the prototypes, tell me what you 
think!

Code is on github here:
git://github.com/wackywendell/ipyurwid.git
git://github.com/wackywendell/ipycurses.git

-Wendell


From robert.kern at gmail.com  Tue Apr 20 13:46:05 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 20 Apr 2010 12:46:05 -0500
Subject: [IPython-dev] Engineering formatting
In-Reply-To: <p2t9457e7c81004191337pe93de202na537c0bd38587206@mail.gmail.com>
References: <p2t9457e7c81004191337pe93de202na537c0bd38587206@mail.gmail.com>
Message-ID: <hqkp8u$fnh$1@dough.gmane.org>

On 4/19/10 3:37 PM, St?fan van der Walt wrote:
> Hi all,
>
> This is probably an easy question, but how do I tweak IPython to
> display my numerical results in engineering notation?

Use the pretty extension! In your ipy_user_conf.py:


from IPython.Extensions import ipy_pretty

ipy_pretty.activate()

def float_eng_pprinter(obj, p, cycle):
     p.text('%e' % obj)

def array_eng_pprinter(obj, p, cycle):
     # ... Left as exercise for the reader.

ipy_pretty.for_type(float, float_eng_pprinter)
ipy_pretty.for_type_by_name('numpy', 'ndarray', array_eng_pprinter)


-- 
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 warren.weckesser at enthought.com  Wed Apr 21 12:17:59 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Wed, 21 Apr 2010 11:17:59 -0500
Subject: [IPython-dev] Engineering formatting
In-Reply-To: <hqkp8u$fnh$1@dough.gmane.org>
References: <p2t9457e7c81004191337pe93de202na537c0bd38587206@mail.gmail.com>
	<hqkp8u$fnh$1@dough.gmane.org>
Message-ID: <4BCF2537.9000500@enthought.com>

(I might have sent already sent a slight variation of this email--if so, 
sorry for the spam.)

Robert Kern wrote:
> On 4/19/10 3:37 PM, St?fan van der Walt wrote:
>   
>> Hi all,
>>
>> This is probably an easy question, but how do I tweak IPython to
>> display my numerical results in engineering notation?
>>     
>
> Use the pretty extension! In your ipy_user_conf.py:
>
>
> from IPython.Extensions import ipy_pretty
>
> ipy_pretty.activate()
>
> def float_eng_pprinter(obj, p, cycle):
>      p.text('%e' % obj)
>   

That shows the printing 'hook' that is needed, but for engineering 
notation, one wants the power of 10 to be a multiple of three.  Attached 
is some code that I have used to do this.

Following Robert's example, but defining float_eng_pprinter like this:

def float_eng_pprinter(obj, p, cycle):
   p.text(eng_format(obj))


scalar floats are printed in engineering format.  E.g.

In [25]: x = 12345.67

In [26]: y = 3.451e-7

In [27]: x
Out[27]:  12.346e3

In [28]: y
Out[28]: 345.100e-9

Making this work for arrays still remains as an exercise for the reader. :)

Warren


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: eng.py
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100421/6c4da078/attachment.ksh>

From fperez.net at gmail.com  Wed Apr 21 22:58:57 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 21 Apr 2010 19:58:57 -0700
Subject: [IPython-dev] Curses Frontend Update
In-Reply-To: <4BCDA424.1080609@gmail.com>
References: <4BCDA424.1080609@gmail.com>
Message-ID: <q2rdb6b5ecc1004211958ke1016fa5wed8a868e2811ed5d@mail.gmail.com>

Hi Wendell,

On Tue, Apr 20, 2010 at 5:55 AM, Wendell Smith <wackywendell at gmail.com> wrote:
> Hello!
>
> I have been busy coding away, trying to get two prototypes written for
> the eventual curses frontend.
>
> They are EXTREMELY basic - they don't even interpret code, just spit it
> back out (although in the right place and correctly colored). They are
> full of bugs, don't resize well, etc. - but, well, they are prototypes.
>
> What they do:
> They both have 3 windows: completions, output, and input. The
> completions window shows some default text, the input window accepts
> text input, and after hitting enter or <ctrl-g>, the entered code is
> highlighted and displayed in the output window.
>
> I wrote these both mainly to compare urwid and curses, which I think
> they do fairly well. the urwid library is quite nice, and although
> documentation is not perfect, it is good, and the whole thing provides
> far more than curses - curses requires you to manually handle resizing,
> for example. The code for the urwid part is therefore far simpler, and
> was written much faster. It of course requires urwid (easy_install
> urwid), and both require pygments (also available with easy_install).
> Urwid is much nicer... but development is only semi-active, and they
> don't seem at all prepared to port to python3, which is of course important.
>
> Anyways, please download the code, run the prototypes, tell me what you
> think!
>
> Code is on github here:
> git://github.com/wackywendell/ipyurwid.git
> git://github.com/wackywendell/ipycurses.git

Great!  A few comments:

- On ubuntu 9.10, I get this for the urwid code:

(master)amirbar[ipyurwid]> python interpreterwidget.py
Traceback (most recent call last):
  File "interpreterwidget.py", line 112, in <module>
    interp = fakeinterpreter(mainwin)
  File "interpreterwidget.py", line 81, in __init__
    self.formatter = UrwidFormatter(style=s)
  File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line
29, in __init__
    self._setup_styles(colors)
  File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line
92, in _setup_styles
    fgcolstr, bgcolstr, othersettings, colors)
  File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line
72, in findclosestattr
    fg = self.findclosest(fgcolstr, colors)
  File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line
54, in findclosest
    bestcol = urwid.AttrSpec('h0','default')
AttributeError: 'module' object has no attribute 'AttrSpec'

I have:

In [2]: urwid.__version__
Out[2]: '0.9.8.4'

Do I need a newer urwid to test out?

Still, this is a tough one: I am genuinely worried about depending on
a possibly undeveloped project. Have you contacted the urwid devs to
find out a little bit about future plans/py3 development ideas?

Using curses when urwid is around may feel painful, but at this point
closing the door on py3k development possibilities sounds a little
dangerous for us.  On the other hand, I do see the differences:

amirbar[wendell]> wc -l ipyurwid/*py
  117 ipyurwid/interpreterwidget.py
  252 ipyurwid/palette_test.py
  105 ipyurwid/urwidpygments.py
  474 total

amirbar[wendell]> wc -l ipycurses/*py
  151 ipycurses/basicsequence.py
  142 ipycurses/cursesextras.py
   71 ipycurses/cursesparser.py
  347 ipycurses/cursespygments.py
   32 ipycurses/interpreterwidget.py
   11 ipycurses/ipythontest.py
   18 ipycurses/keytester.py
   57 ipycurses/prototype.py
   66 ipycurses/tester.py
  241 ipycurses/vipad.py
  123 ipycurses/vipadtester.py
 1259 total

Since I can't run the urwid code right now, how equivalent are the two
in terms of functionality? I'm basically trying to gauge if the above
line counts can be fairly compared...

Cheers,

f


From fperez.net at gmail.com  Thu Apr 22 01:16:58 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 21 Apr 2010 22:16:58 -0700
Subject: [IPython-dev] IPythonQt GSoC update
In-Reply-To: <w2o9764d2d91004182335x6b657bb6lbdd736683c092b51@mail.gmail.com>
References: <y2v9764d2d91004161351p962e27c9r644189142a2f2b15@mail.gmail.com>
	<w2o9764d2d91004182335x6b657bb6lbdd736683c092b51@mail.gmail.com>
Message-ID: <w2jdb6b5ecc1004212216vf3bc4304rf4ac4ac33125c32c@mail.gmail.com>

On Sun, Apr 18, 2010 at 11:35 PM, Gerardo Gutierrez
<muzgash.lists at gmail.com> wrote:
>
> *Mark Summerfield wrote on the blog:
>
> I think you will find QPlainTextEdit more suitable that QTextEdit. Its
> layout engine is much faster and it supports colors, bold, etc. (It doesn't
> support tables, lists & frames, but presumably you don't need them.) Also,
> you can use QSyntaxHighlighter with QPlainTextEdit just the same as
> QTextEdit.
>
> I don't really had that in mind just because of the easiness of exporting
> the entire session to html, but the differences between QPlainTextEdit and
> QTextEdit are minimal. so the design can be initially with a QPlainTextEdit
> and if something comes up the update to a QTextEdit should be easy enough to
> not to worry for now since the exporting and saving of sessions are still in
> discussion.

Mark's comments on speed of layout may be worth keeping in mind
though: once a session has hundreds of cells, speed may start to
matter.

> *The documentation (in the blog, wiki and branch) has been updated, it has
> more details about each one of the two main parts of the project and a
> required piece of documentation for the event ("possible future
> directions"). Please let us know your ideas or questions writing ni the blog
> or through here, we'll appreciate your support.

Thanks for updating the branch. I'll try to get to the reviews ASAP
(both this one and the zmq one) so that you can stop using Bzr and
spend your energy on git instead.

Cheers,

f


From fperez.net at gmail.com  Thu Apr 22 01:19:30 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 21 Apr 2010 22:19:30 -0700
Subject: [IPython-dev] Porting python3
In-Reply-To: <x2jad1253101004181314h84660065jf517930a1eaac226@mail.gmail.com>
References: <x2jad1253101004181314h84660065jf517930a1eaac226@mail.gmail.com>
Message-ID: <k2odb6b5ecc1004212219r504073c5u544850f3dc9c226f@mail.gmail.com>

Hi Omar,

2010/4/18 Omar Andr?s Zapata Mesa <andresete.chaos at gmail.com>:
> Hi all,
> I am working in port iplib and some core files of ipython to python3, to
> make some test in the system zmq,
> but is better know if we have some plan to do this or some especail repo
> with someting writed.

It's important to note that the zmq project would provide the
*foundation* for a python3 port, but it's not tasked directly with
porting anything at all.  For this project, you should focus on
creating the zmq support and the 2-process implementation that retains
100% of IPython's functionality.

Once that is done, we'll have ahead of us the task of moving from
Twisted to zmq for the distributed computing aspects, a non-trivial
problem but one that will be very interesting to tackle.

Only once twisted is out of the picture will we be able to consider a
full py3 port.

Let me know if any of this isn't clear to you.

Best,
f


From fperez.net at gmail.com  Thu Apr 22 01:20:32 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 21 Apr 2010 22:20:32 -0700
Subject: [IPython-dev] Windows crash - pyreadline? [was Re: IPython
	Crash Report]
In-Reply-To: <CE70597C0569FB44B88DFEC56451B2330266A573@SNOWY.readyatdawn.com>
References: <z2ydb6b5ecc1004151054l7a79e774m2bb2a7bc681dd876@mail.gmail.com>
	<CE70597C0569FB44B88DFEC56451B2330266A573@SNOWY.readyatdawn.com>
Message-ID: <n2tdb6b5ecc1004212220r9858b395o1156cc986271ff2e@mail.gmail.com>

On Sun, Apr 18, 2010 at 9:05 AM, Tom Plunket <tom at readyatdawn.com> wrote:
> I finally tried this again on another machine, with different versions of
> things and on 32-bit Python.? The crash did not happen.? So, maybe it's
> 64-bit only?? I get the same output as Fernando.? I just realized, I should
> try the same thing at the stock Python prompt; why that hadn't come to mind
> earlier I don't know.

I suppose it could be a windows-64 bit specific problem, I'm afraid I
won't be able to help much on that front...

Cheers,

f


From andresete.chaos at gmail.com  Thu Apr 22 10:55:13 2010
From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=)
Date: Thu, 22 Apr 2010 09:55:13 -0500
Subject: [IPython-dev] Porting python3
In-Reply-To: <k2odb6b5ecc1004212219r504073c5u544850f3dc9c226f@mail.gmail.com>
References: <x2jad1253101004181314h84660065jf517930a1eaac226@mail.gmail.com> 
	<k2odb6b5ecc1004212219r504073c5u544850f3dc9c226f@mail.gmail.com>
Message-ID: <p2vad1253101004220755q431a53bfycd2cc7ef7d18e082@mail.gmail.com>

Hi Fernando.

Ok not problem I am working hardly in zmq prototypes writing a good
implementation of json library, and  I am having frequent meetings with
Jorge Zuluaga to refine the ipython-zmq`s design.

 I had talked to Brian about a howto I'm doing and a new branch for
experimental ipython-zmq code.
 Brian suggested me to write the howto on the blog then I am writing a
"howto" to test ipython-zmq in my blog http://ipythonzmq.blogspot.com/  and
I create a new branch lp:~ipython-contrib/+junk/ipython-zmq-dev
but has nothing yet, because I am ordering code. I will upload some code
tonight.

The ipython-zmq`s documentation branch is
lp:~ipython-contrib/+junk/ipython-zmq.

Thanks!!



El 22 de abril de 2010 00:19, Fernando Perez <fperez.net at gmail.com>escribi?:

> Hi Omar,
>
> 2010/4/18 Omar Andr?s Zapata Mesa <andresete.chaos at gmail.com>:
> > Hi all,
> > I am working in port iplib and some core files of ipython to python3, to
> > make some test in the system zmq,
> > but is better know if we have some plan to do this or some especail repo
> > with someting writed.
>
> It's important to note that the zmq project would provide the
> *foundation* for a python3 port, but it's not tasked directly with
> porting anything at all.  For this project, you should focus on
> creating the zmq support and the 2-process implementation that retains
> 100% of IPython's functionality.
>
> Once that is done, we'll have ahead of us the task of moving from
> Twisted to zmq for the distributed computing aspects, a non-trivial
> problem but one that will be very interesting to tackle.
>
> Only once twisted is out of the picture will we be able to consider a
> full py3 port.
>
> Let me know if any of this isn't clear to you.
>
> Best,
> f
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100422/eec46926/attachment.html>

From fperez.net at gmail.com  Thu Apr 22 12:52:18 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 22 Apr 2010 09:52:18 -0700
Subject: [IPython-dev] notebook-like format for IPythonQt sessions.
In-Reply-To: <hqdm49$b8f$1@dough.gmane.org>
References: <g2w9764d2d91004161631t1fb449pa74b6b9a379ec4f@mail.gmail.com> 
	<m2x9764d2d91004171702pcdc5c5bcx5491158154a6b844@mail.gmail.com> 
	<hqdm49$b8f$1@dough.gmane.org>
Message-ID: <w2idb6b5ecc1004220952q4db6a10h71b07cdd4ccbacfa@mail.gmail.com>

On Sat, Apr 17, 2010 at 6:08 PM, Robert Kern <robert.kern at gmail.com> wrote:
> I would not say that it is natural, no. reST is a fine text markup, but not a
> very good datastore. The parser is difficult to work with, and there aren't any
> tools for generating valid reST from a parsed description.
>
> I highly recommend using xml.etree to parse and generate a simple XML format.

This does have the advantage of using good tools already in the
stdlib, a huge plus.

I'm growing warmer to the xml idea, I have to admit...

Cheers,

f


From fperez.net at gmail.com  Thu Apr 22 12:53:36 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 22 Apr 2010 09:53:36 -0700
Subject: [IPython-dev] About contrib-dev branch
In-Reply-To: <q2tad1253101004161341wa3bc6f95sa0be95ca9a076c48@mail.gmail.com>
References: <q2tad1253101004161341wa3bc6f95sa0be95ca9a076c48@mail.gmail.com>
Message-ID: <z2mdb6b5ecc1004220953t6c545cefub1d1196cc64a4f47@mail.gmail.com>

Hi Omar,

2010/4/16 Omar Andr?s Zapata Mesa <andresete.chaos at gmail.com>:
> hi all.
> Why my branch in contrib-dev has +junk in the path?

It's just how it got created, and Launchpad uses +junk to denote
branches that were not directly attached to a project.

It's easy to fix but don't worry about it: it won't get deleted or
anything, and since we'll move to github soon, there's no point in
spending time on it.  I can still review it and merge from it there,
so don't worry.

Cheers,

f


From fperez.net at gmail.com  Thu Apr 22 12:56:32 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 22 Apr 2010 09:56:32 -0700
Subject: [IPython-dev] Moving to git/github
In-Reply-To: <43577B5A-8D7F-42C0-A27C-E583F4161D49@cs.toronto.edu>
References: <s2ydb6b5ecc1004132330yae51fae8y2811e629a7622b29@mail.gmail.com> 
	<z2l46cb515a1004150925m19232543u4cf10c7f30ab1149@mail.gmail.com> 
	<r2qdb6b5ecc1004150949u2fcdf23ei74f94ffdf0b777b4@mail.gmail.com> 
	<z2ufa8579a41004151100u5d08f364gd8a85e7921e46e95@mail.gmail.com> 
	<43577B5A-8D7F-42C0-A27C-E583F4161D49@cs.toronto.edu>
Message-ID: <v2pdb6b5ecc1004220956u6f2d3571i53261073af9658be@mail.gmail.com>

On Fri, Apr 16, 2010 at 10:15 AM, David Warde-Farley <dwf at cs.toronto.edu> wrote:
>
>
> +1 on git and GitHub in general. I think I've only ever submitted one
> patch to IPython but I think I'd be more inclined to do so if not for
> the albatross of learning Launchpad hanging over my head. Every time I
> try to do something as simple as report a bug or browse the source I
> can't seem to find the right bloody menu.

Thanks David, it seems we have clear support (if not unanimous) for a
github-based solution, and most certainly for moving away from LP.
The proof will be in the pudding, but I certainly hope this will make
it easier for people such as yourself to have a lower barrier to
making contributions, without the tools and interface getting in your
way.

I'm going to spend a bit of time writing a bug transition script so we
can move our bugs from LP to Github without data loss, and I'll report
back when things are ready to move.

Cheers,

f


From andresete.chaos at gmail.com  Thu Apr 22 17:49:44 2010
From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=)
Date: Thu, 22 Apr 2010 16:49:44 -0500
Subject: [IPython-dev] About contrib-dev branch
In-Reply-To: <z2mdb6b5ecc1004220953t6c545cefub1d1196cc64a4f47@mail.gmail.com>
References: <q2tad1253101004161341wa3bc6f95sa0be95ca9a076c48@mail.gmail.com> 
	<z2mdb6b5ecc1004220953t6c545cefub1d1196cc64a4f47@mail.gmail.com>
Message-ID: <r2rad1253101004221449i89cbfb39wb9df1a3c6e2b5aa1@mail.gmail.com>

Hi Fernando.
Thanks for the help, very soon I will give you more news on how the project
will work, tomorrow I have meeting with Zuluaga and I have to hand over the
homework ( a diagram with more detailed design work).

Thanks


El 22 de abril de 2010 11:53, Fernando Perez <fperez.net at gmail.com>escribi?:

> Hi Omar,
>
> 2010/4/16 Omar Andr?s Zapata Mesa <andresete.chaos at gmail.com>:
> > hi all.
> > Why my branch in contrib-dev has +junk in the path?
>
> It's just how it got created, and Launchpad uses +junk to denote
> branches that were not directly attached to a project.
>
> It's easy to fix but don't worry about it: it won't get deleted or
> anything, and since we'll move to github soon, there's no point in
> spending time on it.  I can still review it and merge from it there,
> so don't worry.
>
> Cheers,
>
> f
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100422/5e01d0c0/attachment.html>

From fperez.net at gmail.com  Thu Apr 22 23:53:27 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 22 Apr 2010 20:53:27 -0700
Subject: [IPython-dev] autocall print() bug finally fixed!
Message-ID: <l2qdb6b5ecc1004222053sfc9b1bc7r6358a1532af86e31@mail.gmail.com>

Hi everyone,

I just wanted to mention this because this bug is *extremely*
annoying; thanks to Robert's tip, we've been able to finally close the
bug where autocall would misfire on print statements for python 2.6
and newer like this:

In [1]: print 1, 2, 3
------> print(1, 2, 3)
(1, 2, 3)

The full report is here: https://bugs.launchpad.net/ipython/+bug/414967

now things work OK:

In [1]: print 1,2,3
1 2 3

In [2]: from __future__ import print_function

In [3]: print 1,2,3
------> print(1,2,3)
1 2 3


You do need to be running from bzr, but I did apply the fix both to
0.10.1 and trunk, so this particularly annoying problem is finally
gone.

Cheers,

f


From wackywendell at gmail.com  Fri Apr 23 03:37:52 2010
From: wackywendell at gmail.com (Wendell Smith)
Date: Fri, 23 Apr 2010 09:37:52 +0200
Subject: [IPython-dev] Curses Frontend Update
In-Reply-To: <4BD14DC0.9080202@gmail.com>
References: <4BCDA424.1080609@gmail.com>
	<q2rdb6b5ecc1004211958ke1016fa5wed8a868e2811ed5d@mail.gmail.com>
	<4BD14DC0.9080202@gmail.com>
Message-ID: <4BD14E50.6000800@gmail.com>

Hi!

Yes, you do need to upgrade urwid. I have 0.9.9.1, which is also the 
latest in pypi, so 'easy_install -U urwid' should do it.

Secondly, I agree about dropping Urwid. I hate to do it... but, well, 
python 3 support is definitely something I want, and when I asked 
them... they basically said they hadn't thought much about it.

As for line counts... they are pretty accurate. Both versions come with 
some testing code that is unnecessary ('keytester.py' and 
'vipadtester.py' in curses, 'palette_test.py' in urwid), but if you 
removed those, the line counts would be even more skewed in favor of 
urwid. As for functionality, they are quite close - except that the 
urwid version handles resizing events just from the library, and the 
curses code looks terrible / would crash after resizing, and I'll need 
to write that.

So... yes, it would be really nice to use urwid... but I may never be 
able to with python3, so I guess I can't, unfortunately. That's OK, and 
as my curses implementation shows, it may be more difficult with the 
built in curses library, but its definitely possible.

I still have a long todo list before I start doing any interpreter stuff:
  - rewrite vipad (in curses - my current implementation is cool, but 
not that useful)
  - write a nice editbox window (needed for either urwid or curses if we 
want coloring as you type)
  - get scrolling to work (needed either way, although I believe urwid 
has a widget for that)
  - allow for resizing (in curses)
  - handle adjustable-size completions box (done in urwid, not too hard 
in curses once resizing is handled)

I'm sure there's more... but that's all I've thought of so far.

Anyways, thanks for the comments!

-Wendell


On 04/22/2010 04:58 AM, Fernando Perez wrote:
> Hi Wendell,
>
> On Tue, Apr 20, 2010 at 5:55 AM, Wendell 
> Smith<wackywendell at gmail.com>  wrote:
>> Hello!
>>
>> I have been busy coding away, trying to get two prototypes written for
>> the eventual curses frontend.
>>
>> They are EXTREMELY basic - they don't even interpret code, just spit it
>> back out (although in the right place and correctly colored). They are
>> full of bugs, don't resize well, etc. - but, well, they are prototypes.
>>
>> What they do:
>> They both have 3 windows: completions, output, and input. The
>> completions window shows some default text, the input window accepts
>> text input, and after hitting enter or<ctrl-g>, the entered code is
>> highlighted and displayed in the output window.
>>
>> I wrote these both mainly to compare urwid and curses, which I think
>> they do fairly well. the urwid library is quite nice, and although
>> documentation is not perfect, it is good, and the whole thing provides
>> far more than curses - curses requires you to manually handle resizing,
>> for example. The code for the urwid part is therefore far simpler, and
>> was written much faster. It of course requires urwid (easy_install
>> urwid), and both require pygments (also available with easy_install).
>> Urwid is much nicer... but development is only semi-active, and they
>> don't seem at all prepared to port to python3, which is of course 
>> important.
>>
>> Anyways, please download the code, run the prototypes, tell me what you
>> think!
>>
>> Code is on github here:
>> git://github.com/wackywendell/ipyurwid.git
>> git://github.com/wackywendell/ipycurses.git
> Great!  A few comments:
>
> - On ubuntu 9.10, I get this for the urwid code:
>
> (master)amirbar[ipyurwid]>  python interpreterwidget.py
> Traceback (most recent call last):
>    File "interpreterwidget.py", line 112, in<module>
>      interp = fakeinterpreter(mainwin)
>    File "interpreterwidget.py", line 81, in __init__
>      self.formatter = UrwidFormatter(style=s)
>    File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line
> 29, in __init__
>      self._setup_styles(colors)
>    File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line
> 92, in _setup_styles
>      fgcolstr, bgcolstr, othersettings, colors)
>    File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line
> 72, in findclosestattr
>      fg = self.findclosest(fgcolstr, colors)
>    File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line
> 54, in findclosest
>      bestcol = urwid.AttrSpec('h0','default')
> AttributeError: 'module' object has no attribute 'AttrSpec'
>
> I have:
>
> In [2]: urwid.__version__
> Out[2]: '0.9.8.4'
>
> Do I need a newer urwid to test out?
>
> Still, this is a tough one: I am genuinely worried about depending on
> a possibly undeveloped project. Have you contacted the urwid devs to
> find out a little bit about future plans/py3 development ideas?
>
> Using curses when urwid is around may feel painful, but at this point
> closing the door on py3k development possibilities sounds a little
> dangerous for us.  On the other hand, I do see the differences:
>
> amirbar[wendell]>  wc -l ipyurwid/*py
>    117 ipyurwid/interpreterwidget.py
>    252 ipyurwid/palette_test.py
>    105 ipyurwid/urwidpygments.py
>    474 total
>
> amirbar[wendell]>  wc -l ipycurses/*py
>    151 ipycurses/basicsequence.py
>    142 ipycurses/cursesextras.py
>     71 ipycurses/cursesparser.py
>    347 ipycurses/cursespygments.py
>     32 ipycurses/interpreterwidget.py
>     11 ipycurses/ipythontest.py
>     18 ipycurses/keytester.py
>     57 ipycurses/prototype.py
>     66 ipycurses/tester.py
>    241 ipycurses/vipad.py
>    123 ipycurses/vipadtester.py
>   1259 total
>
> Since I can't run the urwid code right now, how equivalent are the two
> in terms of functionality? I'm basically trying to gauge if the above
> line counts can be fairly compared...
>
> Cheers,
>
> f


From antont at an.org  Sat Apr 24 00:09:05 2010
From: antont at an.org (Toni Alatalo)
Date: Sat, 24 Apr 2010 07:09:05 +0300
Subject: [IPython-dev] Curses Frontend Update
In-Reply-To: <q2rdb6b5ecc1004211958ke1016fa5wed8a868e2811ed5d@mail.gmail.com>
References: <4BCDA424.1080609@gmail.com>
	<q2rdb6b5ecc1004211958ke1016fa5wed8a868e2811ed5d@mail.gmail.com>
Message-ID: <4BD26EE1.3030606@an.org>

Fernando Perez kirjoitti:
>> they do fairly well. the urwid library is quite nice, and although
>> documentation is not perfect, it is good, and the whole thing provides
>> far more than curses - curses requires you to manually handle resizing,
>> for example. The code for the urwid part is therefore far simpler, and
> Still, this is a tough one: I am genuinely worried about depending on
> a possibly undeveloped project. Have you contacted the urwid devs to
> find out a little bit about future plans/py3 development ideas?

One way to think about it is to compare the efforts of:

a) reimplementing things that urwid does, like handling resizing 
mentioned above etc., in the ipython curses frontend

vs

b) converting urwid to py3k yourself (shouldn't that be relatively easy 
with 2to3 for a small pure py lib?)

I do agree it's a tough one. There is the danger that the person doing 
that ends up being the urwid maintainer in general if other devs are not 
active. That has been happening with my and PythonQt (the qtscript like 
thing for embedded py in qt apps) now, kind of, 'cause am so far the 
only one who has made it to work on Qt 4.6 (with an ugly hack) and 
haven't heard back from questions nor patches etc., that's not fun when 
you have a lot of other things todo .. but another story alltogether.

> Using curses when urwid is around may feel painful, but at this point
> closing the door on py3k development possibilities sounds a little

There are few closed doors with open source :)

I guess depends on how useful Urwid is in general, and whether there are 
other uses and devs who fix etc. it otherwise and are eventually 
switching over to py3k too. So what Fernando suggested about asking 
around seems to be the thing to do indeed.

2cently yours,
~Toni

> dangerous for us.  On the other hand, I do see the differences:
> 
> amirbar[wendell]> wc -l ipyurwid/*py
>   117 ipyurwid/interpreterwidget.py
>   252 ipyurwid/palette_test.py
>   105 ipyurwid/urwidpygments.py
>   474 total
> 
> amirbar[wendell]> wc -l ipycurses/*py
>   151 ipycurses/basicsequence.py
>   142 ipycurses/cursesextras.py
>    71 ipycurses/cursesparser.py
>   347 ipycurses/cursespygments.py
>    32 ipycurses/interpreterwidget.py
>    11 ipycurses/ipythontest.py
>    18 ipycurses/keytester.py
>    57 ipycurses/prototype.py
>    66 ipycurses/tester.py
>   241 ipycurses/vipad.py
>   123 ipycurses/vipadtester.py
>  1259 total
> 
> Since I can't run the urwid code right now, how equivalent are the two
> in terms of functionality? I'm basically trying to gauge if the above
> line counts can be fairly compared...
> 
> Cheers,
> 
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



From stefan at sun.ac.za  Sat Apr 24 14:35:42 2010
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 24 Apr 2010 20:35:42 +0200
Subject: [IPython-dev] Engineering formatting
In-Reply-To: <4BCF2537.9000500@enthought.com>
References: <p2t9457e7c81004191337pe93de202na537c0bd38587206@mail.gmail.com> 
	<hqkp8u$fnh$1@dough.gmane.org> <4BCF2537.9000500@enthought.com>
Message-ID: <p2s9457e7c81004241135g35be501at64c37f5d7469ccfe@mail.gmail.com>

Hey Warren, Robert

On 21 April 2010 18:17, Warren Weckesser <warren.weckesser at enthought.com> wrote:
> Robert Kern wrote:
>> On 4/19/10 3:37 PM, St?fan van der Walt wrote:
>>
>>> Hi all,
>>>
>>> This is probably an easy question, but how do I tweak IPython to
>>> display my numerical results in engineering notation?
>>>
>>
>> Use the pretty extension! In your ipy_user_conf.py:
[...]
> Following Robert's example, but defining float_eng_pprinter like this:
>
> def float_eng_pprinter(obj, p, cycle):
> ? p.text(eng_format(obj))
[...]

Thanks for the code snippets!  I've put them into a profile and added
array printing (attached).  Maybe a useful profile to distribute?

Regards
St?fan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipython_config_eng.py
Type: text/x-python-script
Size: 1672 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100424/e3f4e988/attachment.bin>

From stefan at sun.ac.za  Sat Apr 24 14:42:42 2010
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 24 Apr 2010 20:42:42 +0200
Subject: [IPython-dev] Curses Frontend Update
In-Reply-To: <4BCDA424.1080609@gmail.com>
References: <4BCDA424.1080609@gmail.com>
Message-ID: <p2w9457e7c81004241142tf752df3fw7f6ddfda8f26a90b@mail.gmail.com>

Hi Wendell

On 20 April 2010 14:55, Wendell Smith <wackywendell at gmail.com> wrote:
> Anyways, please download the code, run the prototypes, tell me what you
> think!
>
> Code is on github here:
> git://github.com/wackywendell/ipyurwid.git

Cool idea!  I see the code being copied from the input box to the text
box, but on my terminal everything is flashing after being
syntax-highlighted---is this normal?  I assume the completions window
isn't working yet, since TAB and ENTER does the same for me.

Cheers
St?fan


From stefan at sun.ac.za  Sat Apr 24 15:27:32 2010
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 24 Apr 2010 21:27:32 +0200
Subject: [IPython-dev] Bug handling: launchpad, github, other?
In-Reply-To: <hqapsm$mfb$1@dough.gmane.org>
References: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com> 
	<hqapsm$mfb$1@dough.gmane.org>
Message-ID: <q2z9457e7c81004241227v93dc2e23p68fd3cc0305d39aa@mail.gmail.com>

On 17 April 2010 00:55, Robert Kern <robert.kern at gmail.com> wrote:
> On 2010-04-15 16:45 PM, Fernando Perez wrote:
>
>> 3. Other?
>
> BitBucket's issue tracker is pretty nice.
>
> <ducks> ?:-)

Talking about strange bug trackers, I've noticed that IPython is even
used as part of one!

http://pitz.tplus1.com/main-idea.html#what-is-pitz

(see bottom of page)

In a similar vein, there is: http://bugseverywhere.org/be/show/HomePage

What interests me about this approach is the handy way of merging bugs
on branches along with code.

St?fan


From fperez.net at gmail.com  Sat Apr 24 21:23:37 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 24 Apr 2010 18:23:37 -0700
Subject: [IPython-dev] Bug triage frenzy
Message-ID: <m2udb6b5ecc1004241823j7f78b442ob7386805bf423a2e@mail.gmail.com>

Hi all,

if you are on the -dev team, you may see a flurry of emails from LP.
I'm in the process of triaging what I can in LP, so we only import
into github valid bugs.  I'm being fairly liberal, marking as
invalid/won't fix only things I'm convinced are fixed in trunk or
truly invalid, as I'd rather let a few false positives through than
ignore good reports.

If you are feeling generous and want to help, anything you do to
triage new open bugs:

https://bugs.launchpad.net/ipython/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&assignee_option=none&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&search=Search

will be appreciated.

I've now succeded in downloading to local python objects the entire
ipython bug database from LP, now I just need to figure out how to
programatically upload them to github (I'm using this ruby script as a
guide: http://github.com/suitmymind/lighthouse-to-github/raw/master/migrate-lh-to-gh.rb).
 Then we'll be able to make the transition to GH without losing any
bug history for open bugs.  All new issues on GH will have a link to
their parent on LP for details, though I'm trying to preserve as much
metadata as I can.

Cheers,

f


From vivainio at gmail.com  Sun Apr 25 12:32:56 2010
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sun, 25 Apr 2010 19:32:56 +0300
Subject: [IPython-dev] Bug handling: launchpad, github, other?
In-Reply-To: <q2z9457e7c81004241227v93dc2e23p68fd3cc0305d39aa@mail.gmail.com>
References: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com>
	<hqapsm$mfb$1@dough.gmane.org>
	<q2z9457e7c81004241227v93dc2e23p68fd3cc0305d39aa@mail.gmail.com>
Message-ID: <z2n46cb515a1004250932rece1ba8bl5cce2b6272fa567e@mail.gmail.com>

2010/4/24 St?fan van der Walt <stefan at sun.ac.za>:

>
> What interests me about this approach is the handy way of merging bugs
> on branches along with code.

Incidentally, launchpad + bzr does the same thing ;-) (--fixes option).

-- 
Ville M. Vainio
http://tinyurl.com/vainio


From fperez.net at gmail.com  Sun Apr 25 13:47:39 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 25 Apr 2010 10:47:39 -0700
Subject: [IPython-dev] Bug handling: launchpad, github, other?
In-Reply-To: <q2z9457e7c81004241227v93dc2e23p68fd3cc0305d39aa@mail.gmail.com>
References: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com>
	<hqapsm$mfb$1@dough.gmane.org>
	<q2z9457e7c81004241227v93dc2e23p68fd3cc0305d39aa@mail.gmail.com>
Message-ID: <g2pdb6b5ecc1004251047h1a67777apc8338f86164ab133@mail.gmail.com>

2010/4/24 St?fan van der Walt <stefan at sun.ac.za>:
> Talking about strange bug trackers, I've noticed that IPython is even
> used as part of one!
>
> http://pitz.tplus1.com/main-idea.html#what-is-pitz
>
> (see bottom of page)

Cool! It's listed here:

http://ipython.scipy.org/moin/About/Projects_Using_IPython

But I don't remember if I added it to the page or someone else did...

[ Goes and realizes that moin has history:

2009-04-14 05:51:39  FernandoPerez  	Add links to pitz ]

OK, I guess I added that a while ago, I'd totally forgotten about it.

Cheers,


From fperez.net at gmail.com  Sun Apr 25 13:50:10 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 25 Apr 2010 10:50:10 -0700
Subject: [IPython-dev] Bug handling: launchpad, github, other?
In-Reply-To: <z2n46cb515a1004250932rece1ba8bl5cce2b6272fa567e@mail.gmail.com>
References: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com>
	<hqapsm$mfb$1@dough.gmane.org>
	<q2z9457e7c81004241227v93dc2e23p68fd3cc0305d39aa@mail.gmail.com>
	<z2n46cb515a1004250932rece1ba8bl5cce2b6272fa567e@mail.gmail.com>
Message-ID: <i2vdb6b5ecc1004251050q7489598cj8aeeb21e6f0cd847@mail.gmail.com>

2010/4/25 Ville M. Vainio <vivainio at gmail.com>:
>
> Incidentally, launchpad + bzr does the same thing ;-) (--fixes option).

Grumble, grumble: I should really have noticed that option :)  I
typically use 'closes' comments, but never noticed that --fixes
existed...

Thanks, I'll start using it now!

f


From fperez.net at gmail.com  Sun Apr 25 14:07:26 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 25 Apr 2010 11:07:26 -0700
Subject: [IPython-dev] Bug handling: launchpad, github, other?
In-Reply-To: <i2vdb6b5ecc1004251050q7489598cj8aeeb21e6f0cd847@mail.gmail.com>
References: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com>
	<hqapsm$mfb$1@dough.gmane.org>
	<q2z9457e7c81004241227v93dc2e23p68fd3cc0305d39aa@mail.gmail.com>
	<z2n46cb515a1004250932rece1ba8bl5cce2b6272fa567e@mail.gmail.com>
	<i2vdb6b5ecc1004251050q7489598cj8aeeb21e6f0cd847@mail.gmail.com>
Message-ID: <i2rdb6b5ecc1004251107x7862ee1clc4d39c45ff1f5f94@mail.gmail.com>

On Sun, Apr 25, 2010 at 10:50 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> 2010/4/25 Ville M. Vainio <vivainio at gmail.com>:
>>
>> Incidentally, launchpad + bzr does the same thing ;-) (--fixes option).
>
> Grumble, grumble: I should really have noticed that option :) ?I
> typically use 'closes' comments, but never noticed that --fixes
> existed...
>
> Thanks, I'll start using it now!

And indeed:

http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/revision/1255

It's nice that it creates the link to the bug in the commit page, it
would be cool if the bug page also picked up a link to the commit
automatically (like github does when you use 'closes #XX' messages,
where *both* the commit page and the bug page get linked to each
other).  This is a nice feature, and I see they have support not just
for lp but for other trackers as well, with a reasonably generic
interface.  Thanks again for the pointer.

Cheers,

f


From fperez.net at gmail.com  Sun Apr 25 14:17:15 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 25 Apr 2010 11:17:15 -0700
Subject: [IPython-dev] Bug handling: launchpad, github, other?
In-Reply-To: <hqapsm$mfb$1@dough.gmane.org>
References: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com>
	<hqapsm$mfb$1@dough.gmane.org>
Message-ID: <o2vdb6b5ecc1004251117s858ba441mfa523c837636387f@mail.gmail.com>

On Fri, Apr 16, 2010 at 3:55 PM, Robert Kern <robert.kern at gmail.com> wrote:
>
>> 3. Other?
>
> BitBucket's issue tracker is pretty nice.
>
> <ducks> ?:-)

No need to duck, nobody's shooting :)

I think that integration between the source control system and the bug
tracker is really useful and thus I'd rather not consider bitbucket
(and I think we've settled on git by now).  But it's good to see these
other trackers moving forward: that will keep a fire lit under
github's behind on this front, and I'm sure such pressure will help
their tracker improve over time.

Bitbucket does look very nice as well, with a clean interface and what
appears to be a solid feature set (though ironically, everything but
their front page is inaccessible to me right now with "Internal Server
Error" messages :)

It seems clear that both hg and git are solid, mature projects with
enough large and important users to continue forward, much like Gnome
and KDE never 'killed' each other, despite all the silly flamewars of
the linux lists on that topic in the 90's.  And I'm sure bzr will
continue alive as a distant but useful third, since it also has
Canonical and many projects behind it; again using the desktop/window
manager analogies, XFCE and others continue to live even as Gnome/KDE
are the 'big ones' in the linux world.

We seem to be settling on a good set of solutions, and let's hope the
Github admins prove responsive to our requests...

Cheers,

f


From fperez.net at gmail.com  Sun Apr 25 14:18:49 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 25 Apr 2010 11:18:49 -0700
Subject: [IPython-dev] Bug handling: launchpad, github, other?
In-Reply-To: <i2rdb6b5ecc1004251107x7862ee1clc4d39c45ff1f5f94@mail.gmail.com>
References: <g2kdb6b5ecc1004151445p53ca6d4qff83a453187d4bf3@mail.gmail.com>
	<hqapsm$mfb$1@dough.gmane.org>
	<q2z9457e7c81004241227v93dc2e23p68fd3cc0305d39aa@mail.gmail.com>
	<z2n46cb515a1004250932rece1ba8bl5cce2b6272fa567e@mail.gmail.com>
	<i2vdb6b5ecc1004251050q7489598cj8aeeb21e6f0cd847@mail.gmail.com>
	<i2rdb6b5ecc1004251107x7862ee1clc4d39c45ff1f5f94@mail.gmail.com>
Message-ID: <w2ldb6b5ecc1004251118zb582986x791f60106b756dcc@mail.gmail.com>

On Sun, Apr 25, 2010 at 11:07 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> It's nice that it creates the link to the bug in the commit page, it
> would be cool if the bug page also picked up a link to the commit
> automatically (like github does when you use 'closes #XX' messages,
> where *both* the commit page and the bug page get linked to each
> other). ?This is a nice feature, and I see they have support not just
> for lp but for other trackers as well, with a reasonably generic
> interface. ?Thanks again for the pointer.

Never mind: it just took LP a while to create the backlinks, but now
the bug page has been updated with links to the branches.  So they do
the two-way linking, great!

I really should have known about this long ago, I feel silly...

Thanks!

f


From piotr.zolnierczuk at gmail.com  Sun Apr 25 14:29:35 2010
From: piotr.zolnierczuk at gmail.com (Piotr Zolnierczuk)
Date: Sun, 25 Apr 2010 14:29:35 -0400
Subject: [IPython-dev] embedding ipython
Message-ID: <i2icc21a0e31004251129lcba2f0c5i9b5a6903db7c7706@mail.gmail.com>

Hi,
I have been using an embedded IPython shell (sorry I am still at 0.9.1) in a
wxPython app for quite some time and I (and my users) like very much.
I cloned IPython.gui.wx.ipython_view to customize look-and-feel with the
rest of my app.

My app has a bunch of "GUI" tabs that control physics experiment hardware
(neutron scattering at Oak Ridge National Lab) and one tab that is the
IPython shell that allows for "custom" scripts. The main app needs to "pass"
some objects into the shell, for example an object that is responsible for
communication with the control hardware,
so it can be used in the interactive shell. I used user_ns dictionary for it
and it works for me.

Now I have a bunch of questions, so please bear with me:

a) what is the difference between user_ns and user_global_ns  (in particular
in IPython.gui.wx.ipshell_nonblocking)?

b) the example (wxIPython) as well I my embedded shell do not fill _oh
dictionary and '_' is always empty so users cannot "recall" the results of
the previous statement. The ipython shell works fine in that respect. Why
wxIPython does not?
c) could "passing" of the objects  be done via 'configuration' file? If yes,
how?.

d) could an external app execute a script (function) via IPython shell?

e) some users suggested a capability where user "queues" scripts and then
some kernel executes them one-by-one. Anybody knows a good python solution
for that?

Thanks for your patience :)

Any help, directions, etc greatly appreciated

Piotr
-- 

Piotr Adam Zolnierczuk
e-mail: piotr at zolnierczuk.net
www:   http://www.zolnierczuk.net
_____________________________________
written on recycled electrons
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100425/168c08c4/attachment.html>

From fperez.net at gmail.com  Sun Apr 25 15:31:23 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 25 Apr 2010 12:31:23 -0700
Subject: [IPython-dev] Demo.py on trunk
In-Reply-To: <8CC88437E319138-5DFC-537@webmail-d060.sysops.aol.com>
References: <8CC88437E319138-5DFC-537@webmail-d060.sysops.aol.com>
Message-ID: <h2idb6b5ecc1004251231wed7b1813x3745a0624ff3620@mail.gmail.com>

Hi there,

On Tue, Mar 2, 2010 at 10:18 AM, <tfetherston at aol.com> wrote:

> Looking a trunk to test out demo.py, I've changed the import statements to
> reflect the moves due to the reorganization, but I'm running into problems
> in the Demo class init method. It peeks at some of the internals of IPython
> to store some information.
>
> specifically:
>
> self.ip_colorize = __IPYTHON__.pycolorize
> self.ip_runlines = __IPYTHON__.runlines
> self.ip_showtb   = __IPYTHON__.showtraceback
> self.ip_runlines = __IPYTHON__.runlines
> self.shell       = __IPYTHON__
>
> this info is not stored at __IPYTHON__ any more, does someone know where it
> is & how to get/set it?
>

By the way, I just fixed this yesterday in trunk during the bug blitz.

Cheers,

f
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100425/0f7c1c93/attachment.html>

From fperez.net at gmail.com  Sun Apr 25 16:34:46 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 25 Apr 2010 13:34:46 -0700
Subject: [IPython-dev] Gitwash: a git/github workflow document for review
Message-ID: <t2pdb6b5ecc1004251334nc278918er676aebdac98ee100@mail.gmail.com>

Hi all,

Matthew Brett has just finished writing up a first draft of a simple,
*self-contained* description of how to download, contribute to and
develop a github-hosted project:

- rendered version of the docs: https://cirl.berkeley.edu/mb312/gitwash/
- source repo: http://github.com/matthew-brett/gitwash

We expect to use this to help the nipy project transition from bzr to
git/github, and also to use it for IPython.  So we'd like to submit it
for further feedback here, in your minds replace the hypothetical
'gitwash' with 'IPython' and that's what we would ultimately use as
our intro document for anyone wanting to work from the sources.

This document should:

- be easy to read in a short amount of time, without users new to
git/github having to read 10 different Git tutorials (which may be
very good, but may also overwhelm a newcomer with information that he
or she initially doesn't know how to prioritize for relevance).

- enable a newcomer to the project to download it with no
complications, but to later transition to doing development with a
minimal threshold.

- enable someone who knows they want to develop (or existing
ipython/nipy developers) to get started right away.


Obviously once people are comfortable with the basics they will want
(and should) read some of the excellent git/gh documentation out
there.  But at that point they will be in a position to digest it and
benefit from it, which may not be true at the raw start.

If the document fails in *any* way at this, please let us know.  Any
lack of clarity, any confusion, any dark spots should be pointed out,
we want to make this as painless as possible for everyone involved.

Cheers,

f


From fperez.net at gmail.com  Sun Apr 25 16:42:43 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 25 Apr 2010 13:42:43 -0700
Subject: [IPython-dev] Porting python3
In-Reply-To: <p2vad1253101004220755q431a53bfycd2cc7ef7d18e082@mail.gmail.com>
References: <x2jad1253101004181314h84660065jf517930a1eaac226@mail.gmail.com>
	<k2odb6b5ecc1004212219r504073c5u544850f3dc9c226f@mail.gmail.com>
	<p2vad1253101004220755q431a53bfycd2cc7ef7d18e082@mail.gmail.com>
Message-ID: <y2ndb6b5ecc1004251342xed18d4fcwfc52351305355d03@mail.gmail.com>

2010/4/22 Omar Andr?s Zapata Mesa <andresete.chaos at gmail.com>:
> Ok not problem I am working hardly in zmq prototypes writing a good
> implementation of json library, and? I am having frequent meetings with
> Jorge Zuluaga to refine the ipython-zmq`s design.

Do you mean you are writing a *new* json library? Why? Python 2.6
ships with a json module out of the box:

http://docs.python.org/library/json.html

and for 2.5 it is available externally as simplejson:

http://pypi.python.org/pypi/simplejson

We don't need a new one...

> ?I had talked to Brian about a howto I'm doing and a new branch for
> experimental ipython-zmq code.
> ?Brian suggested me to write the howto on the blog then I am writing a
> "howto" to test ipython-zmq in my blog http://ipythonzmq.blogspot.com/? and
> I create a new branch lp:~ipython-contrib/+junk/ipython-zmq-dev
> but has nothing yet, because I am ordering code. I will upload some code
> tonight.
>
> The ipython-zmq`s documentation branch is
> lp:~ipython-contrib/+junk/ipython-zmq.

Yes, I'm plowing through the git transition work and will review both
of your branches (zmq/qt) as soon as possible.

Needless to say, anyone else is invited and welcome to review this
(please do so!).

Cheers,

f


From fperez.net at gmail.com  Sun Apr 25 16:55:06 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 25 Apr 2010 13:55:06 -0700
Subject: [IPython-dev] Zmq branch on LP: re-created.
Message-ID: <n2rdb6b5ecc1004251355t861d2e0dhad945010c48b28a6@mail.gmail.com>

Hi Omar,

I just realized that because you first pushed the zmq branch on +junk
(the 'private' workspace for ~ipython-contrib), Launchpad won't let us
make a normal merge proposal.  It seems LP only makes proper proposal
for branches that are linked to a project, not on +junk.

It's not worth spending time on learning this from your side, so I
just went ahead and fixed it, but *you must re-branch* your work.  The
official zmq branch is now this one:

https://code.launchpad.net/~ipython-contrib/ipython/ipython-zmq

If you had no local changes unpushed, simply delete the branch you had and do

bzr branch lp:~ipython-contrib/ipython/ipython-zmq

to continue.  This branch is now listed for merge:

https://code.launchpad.net/~ipython-contrib/ipython/ipython-zmq/+merge/24087

so it can be properly reviewed.

If you had any changes, just don't delete your copy yet.  Do the
above, then merge your local changes into the new one, push from the
new one, and then destroy the other one.

Cheers,

f


From fperez.net at gmail.com  Sun Apr 25 19:04:12 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 25 Apr 2010 16:04:12 -0700
Subject: [IPython-dev] Brian and Vishal, help with #400600?
Message-ID: <v2mdb6b5ecc1004251604nc9cd8156x3657f6009761bdda@mail.gmail.com>

Hey guys,

I see you've been active on this one:

https://bugs.launchpad.net/ipython/+bug/400600

It's the last remaining bug on LP that both has a patch and is still
open, everything else with patches I've already committed.  Since bugs
with patches will be harder to auto-migrate to Gh, I'd like to close
them for good while still on LP where the patch is tracked, to
simplify life.

If you guys have a chance to clarify the status of this one before we
make the transition, it would be great.

Cheers,

f


From andresete.chaos at gmail.com  Sun Apr 25 21:03:20 2010
From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=)
Date: Sun, 25 Apr 2010 20:03:20 -0500
Subject: [IPython-dev] Zmq branch on LP: re-created.
In-Reply-To: <n2rdb6b5ecc1004251355t861d2e0dhad945010c48b28a6@mail.gmail.com>
References: <n2rdb6b5ecc1004251355t861d2e0dhad945010c48b28a6@mail.gmail.com>
Message-ID: <t2oad1253101004251803t5e597aafz3d6daf8e46d2dec2@mail.gmail.com>

Hi  Fernando.
Ok The new code will be mounted in the new branch.

 talking about something else in last meeting with Zuluaga  we have two
problems to solve on ipython-zmq's desing.

1)  is tab completion a process into Queue of zmq kernels or is a simple
thread?
2) is good idea make a daemon to crash recovery system?

Regards!


2010/4/25 Fernando Perez <fperez.net at gmail.com>

> Hi Omar,
>
> I just realized that because you first pushed the zmq branch on +junk
> (the 'private' workspace for ~ipython-contrib), Launchpad won't let us
> make a normal merge proposal.  It seems LP only makes proper proposal
> for branches that are linked to a project, not on +junk.
>
> It's not worth spending time on learning this from your side, so I
> just went ahead and fixed it, but *you must re-branch* your work.  The
> official zmq branch is now this one:
>
> https://code.launchpad.net/~ipython-contrib/ipython/ipython-zmq<https://code.launchpad.net/%7Eipython-contrib/ipython/ipython-zmq>
>
> If you had no local changes unpushed, simply delete the branch you had and
> do
>
> bzr branch lp:~ipython-contrib/ipython/ipython-zmq
>
> to continue.  This branch is now listed for merge:
>
>
> https://code.launchpad.net/~ipython-contrib/ipython/ipython-zmq/+merge/24087<https://code.launchpad.net/%7Eipython-contrib/ipython/ipython-zmq/+merge/24087>
>
> so it can be properly reviewed.
>
> If you had any changes, just don't delete your copy yet.  Do the
> above, then merge your local changes into the new one, push from the
> new one, and then destroy the other one.
>
> Cheers,
>
> f
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100425/22792539/attachment.html>

From andresete.chaos at gmail.com  Sun Apr 25 21:15:52 2010
From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=)
Date: Sun, 25 Apr 2010 20:15:52 -0500
Subject: [IPython-dev] notebook-like format for IPythonQt sessions.
In-Reply-To: <w2idb6b5ecc1004220952q4db6a10h71b07cdd4ccbacfa@mail.gmail.com>
References: <g2w9764d2d91004161631t1fb449pa74b6b9a379ec4f@mail.gmail.com> 
	<m2x9764d2d91004171702pcdc5c5bcx5491158154a6b844@mail.gmail.com> 
	<hqdm49$b8f$1@dough.gmane.org>
	<w2idb6b5ecc1004220952q4db6a10h71b07cdd4ccbacfa@mail.gmail.com>
Message-ID: <q2uad1253101004251815rba0af8efr5c19e780f034a5c@mail.gmail.com>

Hi
I think xml is easy way because we can write some module to ipthyton that
let me read this content directly from ipython-qt' s xml file.

regards.

2010/4/22 Fernando Perez <fperez.net at gmail.com>

> On Sat, Apr 17, 2010 at 6:08 PM, Robert Kern <robert.kern at gmail.com>
> wrote:
> > I would not say that it is natural, no. reST is a fine text markup, but
> not a
> > very good datastore. The parser is difficult to work with, and there
> aren't any
> > tools for generating valid reST from a parsed description.
> >
> > I highly recommend using xml.etree to parse and generate a simple XML
> format.
>
> This does have the advantage of using good tools already in the
> stdlib, a huge plus.
>
> I'm growing warmer to the xml idea, I have to admit...
>
> Cheers,
>
> f
> _______________________________________________
> 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/20100425/bf5049ab/attachment.html>

From ellisonbg at gmail.com  Sun Apr 25 23:55:18 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Sun, 25 Apr 2010 20:55:18 -0700
Subject: [IPython-dev] notebook-like format for IPythonQt sessions.
In-Reply-To: <hqdm49$b8f$1@dough.gmane.org>
References: <g2w9764d2d91004161631t1fb449pa74b6b9a379ec4f@mail.gmail.com>
	<m2x9764d2d91004171702pcdc5c5bcx5491158154a6b844@mail.gmail.com>
	<hqdm49$b8f$1@dough.gmane.org>
Message-ID: <n2rfa8579a41004252055pab4fcd30ud9908b872d6b6768@mail.gmail.com>

On Sat, Apr 17, 2010 at 6:08 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On 2010-04-17 19:02 , Gerardo Gutierrez wrote:
>> Ok i'm going to paste a fragment of a document about this topic (that
>> I've not noticed until today)
>>
>>
>> /The frontend would store, for now, 5 types of data:
>>
>> #. Input: this is python/ipython code to be executed.
>>
>> #. Output (python): result of executing Inputs.
>>
>> #. Standard output: from subprocesses.
>>
>> #. Standard error: from subprocesses.
>>
>> #. Text: arbitrary text. For now, we'll just store plain text and will defer
>> to the user on how to format it, though it should be valid reST if it is
>> later to be converted into html/pdf.
>>
>> The non-text cells would be stored on-disk as follows::
>>
>> .. input-cell::
>> :id: 1
>>
>> 3+3
>>
>> .. output-cell::
>> :id: 1
>>
>> 6
>>
>> .. input-cell::
>> :id: 2
>>
>> ls
>>
>> .. stdout-cell::
>> :id: 2
>>
>> a.py b.py
>>
>> .. input-cell::
>> :id: 3
>>
>> !askdfj
>>
>> .. stderr-cell::
>> :id: 3
>>
>> sh: askdfj: command not found/
>>
>>
>> This document clears some ideas, since the natural way for an IPython's
>> frontend (not only IPythonQt) to load data is rst in wich Python's and
>> IPython's documentation is written.
>
> I would not say that it is natural, no. reST is a fine text markup, but not a
> very good datastore. The parser is difficult to work with, and there aren't any
> tools for generating valid reST from a parsed description.

I agree with Robert that reST is probably not the best option for this.

> I highly recommend using xml.etree to parse and generate a simple XML format.

I am not quite as excited about XML as Robert, but my feeling is this:
 it should be XML unless someone comes up with an option that beats
it.

Cheers,

Brian

> --
> 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
>
> _______________________________________________
> 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 ellisonbg at gmail.com  Sun Apr 25 23:56:24 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Sun, 25 Apr 2010 20:56:24 -0700
Subject: [IPython-dev] Brian and Vishal, help with #400600?
In-Reply-To: <v2mdb6b5ecc1004251604nc9cd8156x3657f6009761bdda@mail.gmail.com>
References: <v2mdb6b5ecc1004251604nc9cd8156x3657f6009761bdda@mail.gmail.com>
Message-ID: <w2wfa8579a41004252056lcee1c96cvf3ad203e3e91ec38@mail.gmail.com>

This patch can be applied.

Brian

On Sun, Apr 25, 2010 at 4:04 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hey guys,
>
> I see you've been active on this one:
>
> https://bugs.launchpad.net/ipython/+bug/400600
>
> It's the last remaining bug on LP that both has a patch and is still
> open, everything else with patches I've already committed. ?Since bugs
> with patches will be harder to auto-migrate to Gh, I'd like to close
> them for good while still on LP where the patch is tracked, to
> simplify life.
>
> If you guys have a chance to clarify the status of this one before we
> make the transition, it would be great.
>
> 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 ellisonbg at gmail.com  Mon Apr 26 00:11:37 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Sun, 25 Apr 2010 21:11:37 -0700
Subject: [IPython-dev] Gitwash: a git/github workflow document for review
In-Reply-To: <t2pdb6b5ecc1004251334nc278918er676aebdac98ee100@mail.gmail.com>
References: <t2pdb6b5ecc1004251334nc278918er676aebdac98ee100@mail.gmail.com>
Message-ID: <l2kfa8579a41004252111vb4c913c2h649a6500c8479b6c@mail.gmail.com>

Fernando,

A nice lightweight way for dev's to contribute code is to use git
format-patch.  I like how Sympy encourages contributions using this
approach as it is super easy.

I almost think that this document will have the tendency to become a
larger and more involved - and eventually start to overlap with things
like the progit book.  In my experience, the most useful thing for new
devs is having an *exact*, project specific (the real project like
ipython, not gitwash) list of commands that cover %80 of the usage
cases.  Like:

# Get your fork:
git clone git at github.com:ellisonbg/ipython.git

# Create a feature branch
git branch foo
git checkout foo

# edit files, # for each file do:
git add [filename]
git commit
# rinse and repeate

# To post branch to github
git push origin foo

I am thinking like more of a single concise cheatsheet that covers
everything a new user would want.  Basically a "what to type" guide
that fits on 1 page.  The reason I say this is that existing
references like the progit book are so extremely good, there is not
reason to spend time describing the concepts.  Also, I think for a new
user, it will be confusing that the docs are about gitwash rather than
ipython or nipy.  Sorry if this is a bit pessimistic.

Cheers,

Brian


On Sun, Apr 25, 2010 at 1:34 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi all,
>
> Matthew Brett has just finished writing up a first draft of a simple,
> *self-contained* description of how to download, contribute to and
> develop a github-hosted project:
>
> - rendered version of the docs: https://cirl.berkeley.edu/mb312/gitwash/
> - source repo: http://github.com/matthew-brett/gitwash
>
> We expect to use this to help the nipy project transition from bzr to
> git/github, and also to use it for IPython. ?So we'd like to submit it
> for further feedback here, in your minds replace the hypothetical
> 'gitwash' with 'IPython' and that's what we would ultimately use as
> our intro document for anyone wanting to work from the sources.
>
> This document should:
>
> - be easy to read in a short amount of time, without users new to
> git/github having to read 10 different Git tutorials (which may be
> very good, but may also overwhelm a newcomer with information that he
> or she initially doesn't know how to prioritize for relevance).
>
> - enable a newcomer to the project to download it with no
> complications, but to later transition to doing development with a
> minimal threshold.
>
> - enable someone who knows they want to develop (or existing
> ipython/nipy developers) to get started right away.
>
>
> Obviously once people are comfortable with the basics they will want
> (and should) read some of the excellent git/gh documentation out
> there. ?But at that point they will be in a position to digest it and
> benefit from it, which may not be true at the raw start.
>
> If the document fails in *any* way at this, please let us know. ?Any
> lack of clarity, any confusion, any dark spots should be pointed out,
> we want to make this as painless as possible for everyone involved.
>
> 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 ellisonbg at gmail.com  Mon Apr 26 00:19:37 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Sun, 25 Apr 2010 21:19:37 -0700
Subject: [IPython-dev] Bug triage frenzy
In-Reply-To: <m2udb6b5ecc1004241823j7f78b442ob7386805bf423a2e@mail.gmail.com>
References: <m2udb6b5ecc1004241823j7f78b442ob7386805bf423a2e@mail.gmail.com>
Message-ID: <h2tfa8579a41004252119zdf235051lc207de93cb317814@mail.gmail.com>

Fernando,

Wow, thanks for doing this!

> if you are on the -dev team, you may see a flurry of emails from LP.
> I'm in the process of triaging what I can in LP, so we only import
> into github valid bugs. ?I'm being fairly liberal, marking as
> invalid/won't fix only things I'm convinced are fixed in trunk or
> truly invalid, as I'd rather let a few false positives through than
> ignore good reports.
>
> If you are feeling generous and want to help, anything you do to
> triage new open bugs:
>
> https://bugs.launchpad.net/ipython/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&assignee_option=none&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&search=Search
>
> will be appreciated.

I am super busy right now so I don't think I will have a chance to do
much, but I am definitely watching the progress.  Please let me know
if there are specific tickets you want me to look at.

> I've now succeded in downloading to local python objects the entire
> ipython bug database from LP, now I just need to figure out how to
> programatically upload them to github (I'm using this ruby script as a
> guide: http://github.com/suitmymind/lighthouse-to-github/raw/master/migrate-lh-to-gh.rb).
> ?Then we'll be able to make the transition to GH without losing any
> bug history for open bugs. ?All new issues on GH will have a link to
> their parent on LP for details, though I'm trying to preserve as much
> metadata as I can.

This is great.

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 ellisonbg at gmail.com  Mon Apr 26 00:25:55 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Sun, 25 Apr 2010 21:25:55 -0700
Subject: [IPython-dev] Curses Frontend Update
In-Reply-To: <4BD14E50.6000800@gmail.com>
References: <4BCDA424.1080609@gmail.com>
	<q2rdb6b5ecc1004211958ke1016fa5wed8a868e2811ed5d@mail.gmail.com>
	<4BD14DC0.9080202@gmail.com> <4BD14E50.6000800@gmail.com>
Message-ID: <o2ufa8579a41004252125q6a1e8245yeb0b2903c34e7fd2@mail.gmail.com>

Wendell,

Another thing that should be considered is what the event loops look
like for both curses and urwid.  The reason that I saw this is that I
think it will make the most sense to use 0MQ to get your frontend
talking to ipython.  For that, you will definitely want something of a
real event loop.  If urwid makes that easier then that is worth giving
urwid extra consideration.

Cheers,

Brian


On Fri, Apr 23, 2010 at 12:37 AM, Wendell Smith <wackywendell at gmail.com> wrote:
> Hi!
>
> Yes, you do need to upgrade urwid. I have 0.9.9.1, which is also the
> latest in pypi, so 'easy_install -U urwid' should do it.
>
> Secondly, I agree about dropping Urwid. I hate to do it... but, well,
> python 3 support is definitely something I want, and when I asked
> them... they basically said they hadn't thought much about it.
>
> As for line counts... they are pretty accurate. Both versions come with
> some testing code that is unnecessary ('keytester.py' and
> 'vipadtester.py' in curses, 'palette_test.py' in urwid), but if you
> removed those, the line counts would be even more skewed in favor of
> urwid. As for functionality, they are quite close - except that the
> urwid version handles resizing events just from the library, and the
> curses code looks terrible / would crash after resizing, and I'll need
> to write that.
>
> So... yes, it would be really nice to use urwid... but I may never be
> able to with python3, so I guess I can't, unfortunately. That's OK, and
> as my curses implementation shows, it may be more difficult with the
> built in curses library, but its definitely possible.
>
> I still have a long todo list before I start doing any interpreter stuff:
> ?- rewrite vipad (in curses - my current implementation is cool, but
> not that useful)
> ?- write a nice editbox window (needed for either urwid or curses if we
> want coloring as you type)
> ?- get scrolling to work (needed either way, although I believe urwid
> has a widget for that)
> ?- allow for resizing (in curses)
> ?- handle adjustable-size completions box (done in urwid, not too hard
> in curses once resizing is handled)
>
> I'm sure there's more... but that's all I've thought of so far.
>
> Anyways, thanks for the comments!
>
> -Wendell
>
>
> On 04/22/2010 04:58 AM, Fernando Perez wrote:
>> Hi Wendell,
>>
>> On Tue, Apr 20, 2010 at 5:55 AM, Wendell
>> Smith<wackywendell at gmail.com> ?wrote:
>>> Hello!
>>>
>>> I have been busy coding away, trying to get two prototypes written for
>>> the eventual curses frontend.
>>>
>>> They are EXTREMELY basic - they don't even interpret code, just spit it
>>> back out (although in the right place and correctly colored). They are
>>> full of bugs, don't resize well, etc. - but, well, they are prototypes.
>>>
>>> What they do:
>>> They both have 3 windows: completions, output, and input. The
>>> completions window shows some default text, the input window accepts
>>> text input, and after hitting enter or<ctrl-g>, the entered code is
>>> highlighted and displayed in the output window.
>>>
>>> I wrote these both mainly to compare urwid and curses, which I think
>>> they do fairly well. the urwid library is quite nice, and although
>>> documentation is not perfect, it is good, and the whole thing provides
>>> far more than curses - curses requires you to manually handle resizing,
>>> for example. The code for the urwid part is therefore far simpler, and
>>> was written much faster. It of course requires urwid (easy_install
>>> urwid), and both require pygments (also available with easy_install).
>>> Urwid is much nicer... but development is only semi-active, and they
>>> don't seem at all prepared to port to python3, which is of course
>>> important.
>>>
>>> Anyways, please download the code, run the prototypes, tell me what you
>>> think!
>>>
>>> Code is on github here:
>>> git://github.com/wackywendell/ipyurwid.git
>>> git://github.com/wackywendell/ipycurses.git
>> Great! ?A few comments:
>>
>> - On ubuntu 9.10, I get this for the urwid code:
>>
>> (master)amirbar[ipyurwid]> ?python interpreterwidget.py
>> Traceback (most recent call last):
>> ? ?File "interpreterwidget.py", line 112, in<module>
>> ? ? ?interp = fakeinterpreter(mainwin)
>> ? ?File "interpreterwidget.py", line 81, in __init__
>> ? ? ?self.formatter = UrwidFormatter(style=s)
>> ? ?File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line
>> 29, in __init__
>> ? ? ?self._setup_styles(colors)
>> ? ?File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line
>> 92, in _setup_styles
>> ? ? ?fgcolstr, bgcolstr, othersettings, colors)
>> ? ?File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line
>> 72, in findclosestattr
>> ? ? ?fg = self.findclosest(fgcolstr, colors)
>> ? ?File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line
>> 54, in findclosest
>> ? ? ?bestcol = urwid.AttrSpec('h0','default')
>> AttributeError: 'module' object has no attribute 'AttrSpec'
>>
>> I have:
>>
>> In [2]: urwid.__version__
>> Out[2]: '0.9.8.4'
>>
>> Do I need a newer urwid to test out?
>>
>> Still, this is a tough one: I am genuinely worried about depending on
>> a possibly undeveloped project. Have you contacted the urwid devs to
>> find out a little bit about future plans/py3 development ideas?
>>
>> Using curses when urwid is around may feel painful, but at this point
>> closing the door on py3k development possibilities sounds a little
>> dangerous for us. ?On the other hand, I do see the differences:
>>
>> amirbar[wendell]> ?wc -l ipyurwid/*py
>> ? ?117 ipyurwid/interpreterwidget.py
>> ? ?252 ipyurwid/palette_test.py
>> ? ?105 ipyurwid/urwidpygments.py
>> ? ?474 total
>>
>> amirbar[wendell]> ?wc -l ipycurses/*py
>> ? ?151 ipycurses/basicsequence.py
>> ? ?142 ipycurses/cursesextras.py
>> ? ? 71 ipycurses/cursesparser.py
>> ? ?347 ipycurses/cursespygments.py
>> ? ? 32 ipycurses/interpreterwidget.py
>> ? ? 11 ipycurses/ipythontest.py
>> ? ? 18 ipycurses/keytester.py
>> ? ? 57 ipycurses/prototype.py
>> ? ? 66 ipycurses/tester.py
>> ? ?241 ipycurses/vipad.py
>> ? ?123 ipycurses/vipadtester.py
>> ? 1259 total
>>
>> Since I can't run the urwid code right now, how equivalent are the two
>> in terms of functionality? I'm basically trying to gauge if the above
>> line counts can be fairly compared...
>>
>> 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 gael.varoquaux at normalesup.org  Mon Apr 26 01:10:52 2010
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 26 Apr 2010 07:10:52 +0200
Subject: [IPython-dev] Gitwash: a git/github workflow document for	review
In-Reply-To: <t2pdb6b5ecc1004251334nc278918er676aebdac98ee100@mail.gmail.com>
References: <t2pdb6b5ecc1004251334nc278918er676aebdac98ee100@mail.gmail.com>
Message-ID: <20100426051052.GA14566@phare.normalesup.org>

On Sun, Apr 25, 2010 at 01:34:46PM -0700, Fernando Perez wrote:
> This document should:

> - be easy to read in a short amount of time, without users new to
> git/github having to read 10 different Git tutorials (which may be
> very good, but may also overwhelm a newcomer with information that he
> or she initially doesn't know how to prioritize for relevance).

> - enable a newcomer to the project to download it with no
> complications, but to later transition to doing development with a
> minimal threshold.

What is your target audience?

The document starts right away with editing a config file, which is way
above the abilities of one of my target audience, but I understand that
if you target developers, this might not be a problem.

Thanks for working on that, Matthew,

Ga?l


From fperez.net at gmail.com  Mon Apr 26 01:45:35 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 25 Apr 2010 22:45:35 -0700
Subject: [IPython-dev] Gitwash: a git/github workflow document for review
In-Reply-To: <l2kfa8579a41004252111vb4c913c2h649a6500c8479b6c@mail.gmail.com>
References: <t2pdb6b5ecc1004251334nc278918er676aebdac98ee100@mail.gmail.com>
	<l2kfa8579a41004252111vb4c913c2h649a6500c8479b6c@mail.gmail.com>
Message-ID: <l2tdb6b5ecc1004252245p34486b65n1f6a387e3bc5f316@mail.gmail.com>

Hey,

On Sun, Apr 25, 2010 at 9:11 PM, Brian Granger <ellisonbg at gmail.com> wrote:

> A nice lightweight way for dev's to contribute code is to use git
> format-patch.  I like how Sympy encourages contributions using this
> approach as it is super easy.

Ah, thanks for that.  I've never used it before, do you have a
reference from the sympy guys on how they guide new users in this
direction?  We can just copy theirs.

> Also, I think for a new
> user, it will be confusing that the docs are about gitwash rather than
> ipython or nipy. ?Sorry if this is a bit pessimistic.

Oh, the name 'gitwash' was precisely so Matthew could draft something,
and then we could do a search and replace and put ipython in there :)

We do want it to be a copy/paste worksheet, most definitely, and 100%
specific to getting started for ipython and nipy.  Ideally we can use
the same workflow for both, but eventually this will be pasted into
each project's doc tree and used with project-specific urls, names,
etc.

So think of 'ipython' wherever you read 'gitwash' and critique away as
something we'll want for IPython itself.  The gitwash repo is just a
drafting/staging place to get the doc ready to move into nipy and
ipython. Hopefully we can get it in decent shape first, before each
project takes it and makes it specific to each workflow.

And we completely agree that we do *not* want it to become a
'book-lite'.  There are plenty of great tutorials with concepts,
pictures, etc. for that.  We just want it to be the 'tell me what to
copy/paste to get started with IPython/nipy' worksheet.

Cheers,

f


From fperez.net at gmail.com  Mon Apr 26 01:51:31 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 25 Apr 2010 22:51:31 -0700
Subject: [IPython-dev] Gitwash: a git/github workflow document for review
In-Reply-To: <20100426051052.GA14566@phare.normalesup.org>
References: <t2pdb6b5ecc1004251334nc278918er676aebdac98ee100@mail.gmail.com>
	<20100426051052.GA14566@phare.normalesup.org>
Message-ID: <x2jdb6b5ecc1004252251o442e556bj145b5993234a64e2@mail.gmail.com>

On Sun, Apr 25, 2010 at 10:10 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> What is your target audience?
>
> The document starts right away with editing a config file, which is way
> above the abilities of one of my target audience, but I understand that
> if you target developers, this might not be a problem.

Well, you *do* have to configure git right off the bat before you use
it.  So do you with bzr, by the way.  We gave both the config file and
the copy-paste at the command-line commands, do you think the
command-line version is friendlier?  Matthew had that first and I
thought the file one would be easier.

Remember that with bzr you have the same thing, as the 'bazaar in five
minutes' http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ doc
says:

Before you start working, it is good to tell Bazaar who you are. That
way your work is properly identified in revision logs.

Using your name and email address, instead of John Doe?s, type:

$ bzr whoami "John Doe <john.doe at gmail.com>"

This is the exact same thing as with git, it's just that Matthew also
provided a few aliases.  Do you think it would be best to only provide
this, just like bzr?

git config --global user.email you at yourdomain.example.com
git config --global user.name "Your Name Comes Here"

That would be *identical* to bzr, which you say is OK for your users
who can't edit files.  Would this then be OK for them?

Cheers,

f


From fperez.net at gmail.com  Mon Apr 26 02:00:46 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 25 Apr 2010 23:00:46 -0700
Subject: [IPython-dev] Brian and Vishal, help with #400600?
In-Reply-To: <w2wfa8579a41004252056lcee1c96cvf3ad203e3e91ec38@mail.gmail.com>
References: <v2mdb6b5ecc1004251604nc9cd8156x3657f6009761bdda@mail.gmail.com>
	<w2wfa8579a41004252056lcee1c96cvf3ad203e3e91ec38@mail.gmail.com>
Message-ID: <g2udb6b5ecc1004252300od9a92f03zb32874ca2b81c7e@mail.gmail.com>

On Sun, Apr 25, 2010 at 8:56 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> This patch can be applied.
>

Mmmh, are you sure? The patch reads:

=== modified file 'IPython/kernel/core/interpreter.py'
--- IPython/kernel/core/interpreter.py	2009-04-20 22:44:50 +0000
+++ IPython/kernel/core/interpreter.py	2009-07-17 09:46:18 +0000
@@ -375,7 +375,7 @@
             exec code in self.user_ns
             outflag = 0
         except SystemExit:
-            self.resetbuffer()
+            self.reset()
             self.traceback_trap.args = sys.exc_info()
         except:
             self.traceback_trap.args = sys.exc_info()

but the code at that location now reads:

        try:
            exec code in self.user_ns
            outflag = 0
        except SystemExit:
            self.traceback_trap.args = sys.exc_info()
        except:
            self.traceback_trap.args = sys.exc_info()

There is not even a self.resetbuffer() call anymore.  So the patch
does not apply anymore. The question is, should I put in the
self.reset() the patch had added, or should I lseave the code like it
is now?

Thanks for the help, it does look at least like this one is simple
enough that we'll be able to finish it off before the transition.

Cheers,

f


From fperez.net at gmail.com  Mon Apr 26 02:55:52 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 25 Apr 2010 23:55:52 -0700
Subject: [IPython-dev] Bug blitz: a weekend report
Message-ID: <u2ndb6b5ecc1004252355mf72ccc93m8328df29f509ba42@mail.gmail.com>

Hi folks,

my little bug blitz has been fairly successful.  I forgot to write the
numbers down yesterday morning when I started, but I think we had
around 100 new bugs, most of which hadn't even been looked at.  Now
the numbers are:

amirbar[hydrazine]> ./capture-bug-counts
loaded existing credentials
getting project... ipython (IPython - Enhanced Interactive Python)
By Status..................................................................................................................................................................................................................
     4 In Progress
https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=In
Progress
    78 Fix Committed
https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Fix
Committed
    14 Triaged https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Triaged
    96 Confirmed
https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Confirmed
    18 Incomplete
https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Incomplete

Bugs with patches................
    16 HasPatch
https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.has_patch=on

Of those 16 with patches, 15 have already been committed, and the
remaining one is 400600 that Brian and Vishal are helping with, so it
will be in as well.

We have now *zero* bugs marked 'new'.  I was able to close a ton of
small things, applied all available patches (I was trying to ensure no
user contribution went ignored), and in general marked as 'confirmed'
anything that looked remotely reasonable.  So in this case,
'confirmed' doesn't always mean that I actually confirmed the bug,
just that the report looked sensible enough to keep the bug alive on
github.

If you now look at our bug page:

https://bugs.launchpad.net/ipython

we appear to have 210 open ones, but in reality a good chunk of those
have committed fixes, just awaiting a release of 0.10.1/0.11.  If we
exclude 'fix committed', we get:

https://bugs.launchpad.net/ipython/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&search=Search

for a total of 132 open ones.

I can already download those 132 in Python, and I hope later this week
to find the time to write the github upload part, so this time around
we will not lose any bug history or data.  I still feel bad that we
abandoned some bugs reported in our old trac instance at scipy.org,
and I really don't want to repeat that mistake.

Importantly, once we close #400600, we won't have any bug with a patch
left on LP (I can't migrate those easily). For the others, I'm pretty
certain that I can migrate them back up to GH with all comment
discussion and most relevant metadata (as labels).

Upon upload, since all we have are labels, I'm going to use something
similar to what Robert showed us Google code uses: label-value for
key/value labels.  For now GH doesn't provide any semantic support
behind this syntax, but we can later ask them for it based on the
Google model, and if they follow through, we'll be ready :)

So little by little, we're making good progress towards being able to
move 100% of our relevant code and bug history from bzr/Launchpad to
git/github.  Thanks for everyone's patience.  I hope that this setup
will give us a smoother workflow where contributions will be both
easier to make and to integrate.

Regards,

f


From gael.varoquaux at normalesup.org  Mon Apr 26 02:58:23 2010
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 26 Apr 2010 08:58:23 +0200
Subject: [IPython-dev] Gitwash: a git/github workflow document for	review
In-Reply-To: <x2jdb6b5ecc1004252251o442e556bj145b5993234a64e2@mail.gmail.com>
References: <t2pdb6b5ecc1004251334nc278918er676aebdac98ee100@mail.gmail.com>
	<20100426051052.GA14566@phare.normalesup.org>
	<x2jdb6b5ecc1004252251o442e556bj145b5993234a64e2@mail.gmail.com>
Message-ID: <20100426065822.GA9303@phare.normalesup.org>

On Sun, Apr 25, 2010 at 10:51:31PM -0700, Fernando Perez wrote:
> Well, you *do* have to configure git right off the bat before you use
> it.  So do you with bzr, by the way. 

Most people around me don't, with bzr. It may be a bad thing :)

> We gave both the config file and the copy-paste at the command-line
> commands, do you think the command-line version is friendlier?  Matthew
> had that first and I thought the file one would be easier.

It depends who you target audience is. A lot a people around me are going
to try and edit these files with word :), so maybe the command line is
better. But if you target developers, it's fine the way it is.

> Remember that with bzr you have the same thing, as the 'bazaar in five
> minutes' http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ doc
> says:

That tutorial is pretty good, I find.

Once again, it depends who your target audience is. Some words in the
gitwash document may be confusing for non-developers: I have found that
people can be confused by the word 'source' (notice how the bzr tutorial
avoids the problem using 'file'). On the other hand, the bzr tutorial
uses words like 'upstream', which might not be understood either.

That said, I feel that anybody who is somewhat a developer should be able
to understand and use the gitwash document. Extending to non-developers
requires more lengthy phrasing, and more definition of terms
(repository), but I am not sure this is what you are aiming for.

Cheers,

Ga?l


From wackywendell at gmail.com  Mon Apr 26 03:03:55 2010
From: wackywendell at gmail.com (Wendell Smith)
Date: Mon, 26 Apr 2010 09:03:55 +0200
Subject: [IPython-dev] Curses Frontend Update
In-Reply-To: <4BD26EE1.3030606@an.org>
References: <4BCDA424.1080609@gmail.com>	<q2rdb6b5ecc1004211958ke1016fa5wed8a868e2811ed5d@mail.gmail.com>
	<4BD26EE1.3030606@an.org>
Message-ID: <4BD53ADB.2090003@gmail.com>

On 04/24/2010 06:09 AM, Toni Alatalo wrote:
> Fernando Perez kirjoitti:
>    
>>> they do fairly well. the urwid library is quite nice, and although
>>> documentation is not perfect, it is good, and the whole thing provides
>>> far more than curses - curses requires you to manually handle resizing,
>>> for example. The code for the urwid part is therefore far simpler, and
>>>        
>> Still, this is a tough one: I am genuinely worried about depending on
>> a possibly undeveloped project. Have you contacted the urwid devs to
>> find out a little bit about future plans/py3 development ideas?
>>      
> One way to think about it is to compare the efforts of:
>
> a) reimplementing things that urwid does, like handling resizing
> mentioned above etc., in the ipython curses frontend
>
> vs
>
> b) converting urwid to py3k yourself (shouldn't that be relatively easy
> with 2to3 for a small pure py lib?)
>
> I do agree it's a tough one. There is the danger that the person doing
> that ends up being the urwid maintainer in general if other devs are not
> active. That has been happening with my and PythonQt (the qtscript like
> thing for embedded py in qt apps) now, kind of, 'cause am so far the
> only one who has made it to work on Qt 4.6 (with an ugly hack) and
> haven't heard back from questions nor patches etc., that's not fun when
> you have a lot of other things todo .. but another story alltogether.
>
>    
>> Using curses when urwid is around may feel painful, but at this point
>> closing the door on py3k development possibilities sounds a little
>>      
> There are few closed doors with open source :)
>
> I guess depends on how useful Urwid is in general, and whether there are
> other uses and devs who fix etc. it otherwise and are eventually
> switching over to py3k too. So what Fernando suggested about asking
> around seems to be the thing to do indeed.
>
> 2cently yours,
> ~Toni
>    

Yes, I've thought about just trying to convert urwid myself... but I 
think that's a bit much for me. I have very little experience converting 
2to3, and very little with Urwid... and it would be a big time sink. Its 
a nice library... but there's an awful lot of it that I'm not using, and 
trying to convert all of it myself would, I think, be a bigger 
undertaking than its worth.

I did contact them earlier: the response from the main developer was 
something like "porting to python 3 is not currently in our plans, and 
will take a lot of time as there is a lot of str/unicode handling. 
However, someone rumored that there was a python 3 compatible version 
out there, but I haven't seen it." Which was a little weird. Maybe I'll 
ask again.

Thanks for the feedback!

-Wendell


From fperez.net at gmail.com  Mon Apr 26 03:13:43 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 26 Apr 2010 00:13:43 -0700
Subject: [IPython-dev] Gitwash: a git/github workflow document for review
In-Reply-To: <20100426065822.GA9303@phare.normalesup.org>
References: <t2pdb6b5ecc1004251334nc278918er676aebdac98ee100@mail.gmail.com>
	<20100426051052.GA14566@phare.normalesup.org>
	<x2jdb6b5ecc1004252251o442e556bj145b5993234a64e2@mail.gmail.com>
	<20100426065822.GA9303@phare.normalesup.org>
Message-ID: <i2mdb6b5ecc1004260013x79ed28d3td19dc652d84940fe@mail.gmail.com>

Hi,

On Sun, Apr 25, 2010 at 11:58 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
>
> Most people around me don't, with bzr. It may be a bad thing :)

Well, actually with git you can also avoid it altogether: I moved my
git config files out of the way:

amirbar[~]> mv .gitconfig .gitignore .gitk tmp/

and then made a toy repo:

amirbar[~]> mkdir ff
amirbar[~]> cd ff
amirbar[ff]> git init
Initialized empty Git repository in /home/fperez/ff/.git/
(master)amirbar[ff]> echo hi > readme
(master)amirbar[ff]> git add .
(master)amirbar[ff]> git commit -m"Initial commit"
[master (root-commit) 317d06f] Initial commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 readme
(master)amirbar[ff]> git log
commit 317d06f03309b57a1978330c5f0520b84af57fe5
Author: Fernando Perez <fperez at amirbar.(none)>
Date:   Mon Apr 26 00:09:25 2010 -0700

    Initial commit
(master)amirbar[ff]>

It works fine, git will try to get some identity from your username
for the commits.  So in that regard it's identical to bzr: you can use
it with *zero* config, but you'll be happier with a minimal amount of
it in the long run.

>> We gave both the config file and the copy-paste at the command-line
>> commands, do you think the command-line version is friendlier? ?Matthew
>> had that first and I thought the file one would be easier.
>
> It depends who you target audience is. A lot a people around me are going
> to try and edit these files with word :), so maybe the command line is
> better. But if you target developers, it's fine the way it is.

Well, our audience is anyone who can be expected to use nipy or
ipython from source. And we hope that any such person will become at
some point a contributor, so we want that transition to be as easy and
painless as possible.

>> Remember that with bzr you have the same thing, as the 'bazaar in five
>> minutes' http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ doc
>> says:
>
> That tutorial is pretty good, I find.
>
> Once again, it depends who your target audience is. Some words in the
> gitwash document may be confusing for non-developers: I have found that
> people can be confused by the word 'source' (notice how the bzr tutorial
> avoids the problem using 'file'). On the other hand, the bzr tutorial
> uses words like 'upstream', which might not be understood either.

I actually agree, I hadn't really looked at that tutorial very much,
but I now like it a lot.  I think the gitwash doc could be
restructured in a single page very much following the model of that
bzr doc.

> That said, I feel that anybody who is somewhat a developer should be able
> to understand and use the gitwash document. Extending to non-developers
> requires more lengthy phrasing, and more definition of terms
> (repository), but I am not sure this is what you are aiming for.

We'll iterate on it with this feedback, thanks a lot for providing it.

Cheers,

f


From satra at mit.edu  Mon Apr 26 07:46:28 2010
From: satra at mit.edu (Satrajit Ghosh)
Date: Mon, 26 Apr 2010 07:46:28 -0400
Subject: [IPython-dev] Gitwash: a git/github workflow document for review
In-Reply-To: <l2kfa8579a41004252111vb4c913c2h649a6500c8479b6c@mail.gmail.com>
References: <t2pdb6b5ecc1004251334nc278918er676aebdac98ee100@mail.gmail.com>
	<l2kfa8579a41004252111vb4c913c2h649a6500c8479b6c@mail.gmail.com>
Message-ID: <t2m83351d261004260446v9504e1d1q799f74d5bccc51df@mail.gmail.com>

hi fernando, matthew and brian,

thanks for putting this together. i'm really looking forward to (ipython,
nipy) being on github.

# Get your fork:
> git clone git at github.com:ellisonbg/ipython.git
>
> # Create a feature branch
> git branch foo
> git checkout foo
>
> # edit files, # for each file do:
> git add [filename]
> git commit
> # rinse and repeate
>
> # To post branch to github
> git push origin foo
>

talking of a cheat-sheet, there are a few other commands that i tend to use:

# to pull collaborators updates from github
git pull origin foo (if you are working with somebody on your branch)

# deleting
git branch -d foo (delete your local merged branch)
git branch -D foo (delete your local unmerged branch)
git push origin :foo (delete remote branch - this took me a search to figure
out when i started)

also for my needs this has been very helpful:
http://github.com/guides/git-cheat-sheet

users will always do all kinds of wacky things that you cannot foresee, so
you should keep it simple, perhaps just reflect your basic workflow as brian
suggests.

------------
# Get your copy
git clone git at github.com:ellisonbg/ipython.git

# update your copy (run this to sync up with the source)
git pull

#####
# if you are a user, that's all you need to know. if you
# want to hack/develop, read on.
#####

# ... the rest of brian's notes above, gitwash docs
------------

i'm about to give a talk about minimizing redundancy for data and code and i
believe it applies to documentation as well!

cheers,

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

From muzgash.lists at gmail.com  Mon Apr 26 08:11:41 2010
From: muzgash.lists at gmail.com (Gerardo Gutierrez)
Date: Mon, 26 Apr 2010 07:11:41 -0500
Subject: [IPython-dev] IPythonQt GSoC update
In-Reply-To: <w2jdb6b5ecc1004212216vf3bc4304rf4ac4ac33125c32c@mail.gmail.com>
References: <y2v9764d2d91004161351p962e27c9r644189142a2f2b15@mail.gmail.com>
	<w2o9764d2d91004182335x6b657bb6lbdd736683c092b51@mail.gmail.com>
	<w2jdb6b5ecc1004212216vf3bc4304rf4ac4ac33125c32c@mail.gmail.com>
Message-ID: <q2x9764d2d91004260511j18bc65faq5f0427478868ff95@mail.gmail.com>

David Mashburn wrote:
*
Hello Gerardo,

My name is David Mashburn and I am a graduate student in Physics at
Vanderbilt University.

I saw your GSoC proposal for IPythonQt, and though it looked very
interesting!

I just wanted to let you know about my project as you start work on yours.
 I have built a notebook interface atop wxPython's PyCrust and called it
PySlices.  It uses scintilla markers for "slice" (cell) separation, has
multi-line support, and has a text-based "almost python" save format.  I
also added a little ipython-style magic, because I couldn't find an easy way
to wrap ipython.

Anyway, I just wanted to let you know about my project so we can
collaborate.  I guess in some ways we have competing software, but I want to
make both projects better by sharing ideas.  I would really like to
collaborate on the save format so the two systems could be used
interchangeably, I think that would be awesome!

Anyway, I'm sure some of the ways I have done things are good and others are
less than ideal, but I thought you might like to see how someone else did
it!

Here are the main links to PySlices:
-------------------------------------------------------------------------
http://trac.wxwidgets.org/ticket/10959 -- Original Trac ticket at wxPython
http://code.google.com/p/wxpysuite/ -- Google code page (main development)
http://pypi.python.org/pypi/wx_py/0.9.8.3 -- PyPI page
http://www.gossamer-threads.com/lists/python/announce/819207 -- Recent
announcement

BTW, I'm the only developer on this, so I haven't really set up an svn as of
yet, but probably could if there is more interest.  The best way to look at
the code is to unzip the download from the Google code page.

Looking forward to possibly working together and seeing how IPythonQt
evolves!

Thanks,
-David Mashburn*






Best regards.
--
Gerardo Guti?rrez Guti?rrez <http://he1.udea.edu.co/gweb>
Physics student
Universidad de Antioquia
Computational physics and astrophysics group
(FACom<http://urania.udea.edu.co/sites/sites.php>
)
Computational science and development
branch(FACom-dev<http://urania.udea.edu.co/sites/facom-dev/>
)
Usuario Linux #492295
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100426/57607813/attachment.html>

From ellisonbg at gmail.com  Mon Apr 26 13:47:42 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 26 Apr 2010 10:47:42 -0700
Subject: [IPython-dev] Brian and Vishal, help with #400600?
In-Reply-To: <g2udb6b5ecc1004252300od9a92f03zb32874ca2b81c7e@mail.gmail.com>
References: <v2mdb6b5ecc1004251604nc9cd8156x3657f6009761bdda@mail.gmail.com>
	<w2wfa8579a41004252056lcee1c96cvf3ad203e3e91ec38@mail.gmail.com>
	<g2udb6b5ecc1004252300od9a92f03zb32874ca2b81c7e@mail.gmail.com>
Message-ID: <v2gfa8579a41004261047x3e4ede7i1c71512c35b167cc@mail.gmail.com>

I will look at this and try to develop a new patch.

Brian

On Sun, Apr 25, 2010 at 11:00 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Sun, Apr 25, 2010 at 8:56 PM, Brian Granger <ellisonbg at gmail.com> wrote:
>> This patch can be applied.
>>
>
> Mmmh, are you sure? The patch reads:
>
> === modified file 'IPython/kernel/core/interpreter.py'
> --- IPython/kernel/core/interpreter.py ?2009-04-20 22:44:50 +0000
> +++ IPython/kernel/core/interpreter.py ?2009-07-17 09:46:18 +0000
> @@ -375,7 +375,7 @@
> ? ? ? ? ? ? exec code in self.user_ns
> ? ? ? ? ? ? outflag = 0
> ? ? ? ? except SystemExit:
> - ? ? ? ? ? ?self.resetbuffer()
> + ? ? ? ? ? ?self.reset()
> ? ? ? ? ? ? self.traceback_trap.args = sys.exc_info()
> ? ? ? ? except:
> ? ? ? ? ? ? self.traceback_trap.args = sys.exc_info()
>
> but the code at that location now reads:
>
> ? ? ? ?try:
> ? ? ? ? ? ?exec code in self.user_ns
> ? ? ? ? ? ?outflag = 0
> ? ? ? ?except SystemExit:
> ? ? ? ? ? ?self.traceback_trap.args = sys.exc_info()
> ? ? ? ?except:
> ? ? ? ? ? ?self.traceback_trap.args = sys.exc_info()
>
> There is not even a self.resetbuffer() call anymore. ?So the patch
> does not apply anymore. The question is, should I put in the
> self.reset() the patch had added, or should I lseave the code like it
> is now?
>
> Thanks for the help, it does look at least like this one is simple
> enough that we'll be able to finish it off before the transition.
>
> 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


From ellisonbg at gmail.com  Mon Apr 26 14:04:02 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 26 Apr 2010 11:04:02 -0700
Subject: [IPython-dev] Bug blitz: a weekend report
In-Reply-To: <u2ndb6b5ecc1004252355mf72ccc93m8328df29f509ba42@mail.gmail.com>
References: <u2ndb6b5ecc1004252355mf72ccc93m8328df29f509ba42@mail.gmail.com>
Message-ID: <n2kfa8579a41004261104u800418c5qfadeac4bca39c616@mail.gmail.com>

Fernando,

Great job.  I love it!

> my little bug blitz has been fairly successful. ?I forgot to write the
> numbers down yesterday morning when I started, but I think we had
> around 100 new bugs, most of which hadn't even been looked at. ?Now
> the numbers are:
>
> amirbar[hydrazine]> ./capture-bug-counts
> loaded existing credentials
> getting project... ipython (IPython - Enhanced Interactive Python)
> By Status..................................................................................................................................................................................................................
> ? ? 4 In Progress
> https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=In
> Progress
> ? ?78 Fix Committed
> https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Fix
> Committed
> ? ?14 Triaged https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Triaged
> ? ?96 Confirmed
> https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Confirmed
> ? ?18 Incomplete
> https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Incomplete
>
> Bugs with patches................
> ? ?16 HasPatch
> https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.has_patch=on
>
> Of those 16 with patches, 15 have already been committed, and the
> remaining one is 400600 that Brian and Vishal are helping with, so it
> will be in as well.

I will look at this one soon.

> We have now *zero* bugs marked 'new'. ?I was able to close a ton of
> small things, applied all available patches (I was trying to ensure no
> user contribution went ignored), and in general marked as 'confirmed'
> anything that looked remotely reasonable. ?So in this case,
> 'confirmed' doesn't always mean that I actually confirmed the bug,
> just that the report looked sensible enough to keep the bug alive on
> github.

OK I think this makes sense.

> If you now look at our bug page:
>
> https://bugs.launchpad.net/ipython
>
> we appear to have 210 open ones, but in reality a good chunk of those
> have committed fixes, just awaiting a release of 0.10.1/0.11. ?If we
> exclude 'fix committed', we get:
>
> https://bugs.launchpad.net/ipython/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&search=Search
>
> for a total of 132 open ones.
>
> I can already download those 132 in Python, and I hope later this week
> to find the time to write the github upload part, so this time around
> we will not lose any bug history or data. ?I still feel bad that we
> abandoned some bugs reported in our old trac instance at scipy.org,
> and I really don't want to repeat that mistake.

It will be great to have all of these tickets migrated to github.  At
the same time, deleting all bug reports (like we did when we moved to
LP) is not *that* bad.  The real and important bugs always show up
again - it is sort of a way of testing which are real and important.
The only bummer is work that people have done in tracking the bugs
down, fixing them etc.  But it sounds like this time we won't loose
any of that, which is great.

> Importantly, once we close #400600, we won't have any bug with a patch
> left on LP (I can't migrate those easily). For the others, I'm pretty
> certain that I can migrate them back up to GH with all comment
> discussion and most relevant metadata (as labels).
>
> Upon upload, since all we have are labels, I'm going to use something
> similar to what Robert showed us Google code uses: label-value for
> key/value labels. ?For now GH doesn't provide any semantic support
> behind this syntax, but we can later ask them for it based on the
> Google model, and if they follow through, we'll be ready :)

Sounds great, but lets keep our labels and values simple.

> So little by little, we're making good progress towards being able to
> move 100% of our relevant code and bug history from bzr/Launchpad to
> git/github. ?Thanks for everyone's patience. ?I hope that this setup
> will give us a smoother workflow where contributions will be both
> easier to make and to integrate.

Thanks for working on this!

Brian

> Regards,
>
> 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  Mon Apr 26 14:29:31 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 26 Apr 2010 11:29:31 -0700
Subject: [IPython-dev] Brian and Vishal, help with #400600?
In-Reply-To: <v2gfa8579a41004261047x3e4ede7i1c71512c35b167cc@mail.gmail.com>
References: <v2mdb6b5ecc1004251604nc9cd8156x3657f6009761bdda@mail.gmail.com> 
	<w2wfa8579a41004252056lcee1c96cvf3ad203e3e91ec38@mail.gmail.com> 
	<g2udb6b5ecc1004252300od9a92f03zb32874ca2b81c7e@mail.gmail.com> 
	<v2gfa8579a41004261047x3e4ede7i1c71512c35b167cc@mail.gmail.com>
Message-ID: <q2ndb6b5ecc1004261129o7e39c58ex11f21c705e3fe3a2@mail.gmail.com>

On Mon, Apr 26, 2010 at 10:47 AM, Brian Granger <ellisonbg at gmail.com> wrote:
> I will look at this and try to develop a new patch.

Great, thanks!

f


From fperez.net at gmail.com  Mon Apr 26 15:42:49 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 26 Apr 2010 12:42:49 -0700
Subject: [IPython-dev] Bug blitz: a weekend report
In-Reply-To: <n2kfa8579a41004261104u800418c5qfadeac4bca39c616@mail.gmail.com>
References: <u2ndb6b5ecc1004252355mf72ccc93m8328df29f509ba42@mail.gmail.com> 
	<n2kfa8579a41004261104u800418c5qfadeac4bca39c616@mail.gmail.com>
Message-ID: <y2qdb6b5ecc1004261242sa65c979dz91113691a59ec1a6@mail.gmail.com>

On Mon, Apr 26, 2010 at 11:04 AM, Brian Granger <ellisonbg at gmail.com> wrote:
>
> Great job. ?I love it!

Thanks!


>> Of those 16 with patches, 15 have already been committed, and the
>> remaining one is 400600 that Brian and Vishal are helping with, so it
>> will be in as well.
>
> I will look at this one soon.

Excellent.

>> I can already download those 132 in Python, and I hope later this week
>> to find the time to write the github upload part, so this time around
>> we will not lose any bug history or data. ?I still feel bad that we
>> abandoned some bugs reported in our old trac instance at scipy.org,
>> and I really don't want to repeat that mistake.
>
> It will be great to have all of these tickets migrated to github. ?At
> the same time, deleting all bug reports (like we did when we moved to
> LP) is not *that* bad. ?The real and important bugs always show up
> again - it is sort of a way of testing which are real and important.
> The only bummer is work that people have done in tracking the bugs
> down, fixing them etc. ?But it sounds like this time we won't loose
> any of that, which is great.

It's partly a matter of not losing information, but also of not losing
community: people have spent their time reporting the bugs, I want to
make it clear that as a project we value that enough to protect the
result of their effort. If people feel that reporting bugs to IPython
has a 50/50 chance of being completely ignored, we're less likely to
get people contributing.  And we never know when a bug reporter will
become the next IPython contributor, so I don't want to alienate
anyone.

> Sounds great, but lets keep our labels and values simple.

Very good point.  Once I see that it works and I can make labels with
a few test bugs and a toy project I made for that, I'll run the
planned labels by all of you, so we can prune it out before the real
upload.

Cheers,

f


From andresete.chaos at gmail.com  Mon Apr 26 18:47:56 2010
From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=)
Date: Mon, 26 Apr 2010 17:47:56 -0500
Subject: [IPython-dev] About Ipython-zmq
Message-ID: <i2qad1253101004261547z732cef8cs26653943d41aedc9@mail.gmail.com>

Hi all.

More  detailed ipython-zmq's desing is avalible now on scipy`s wiki.
http://ipython.scipy.org/moin/GSoC2010/IPythonZmq

In this desing  we had two questions.

1)  is tab completion  a process into queue of ipython-zmq`s kernel or is it
a simple thread?
2) is it good idea to write a daemon for crash recovery system  to monitor
the kernel`s pid in case it fails?

regards!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100426/2f75c336/attachment.html>

From fperez.net at gmail.com  Tue Apr 27 01:16:50 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 26 Apr 2010 22:16:50 -0700
Subject: [IPython-dev] IPythonQt GSoC update
In-Reply-To: <q2x9764d2d91004260511j18bc65faq5f0427478868ff95@mail.gmail.com>
References: <y2v9764d2d91004161351p962e27c9r644189142a2f2b15@mail.gmail.com>
	<w2o9764d2d91004182335x6b657bb6lbdd736683c092b51@mail.gmail.com>
	<w2jdb6b5ecc1004212216vf3bc4304rf4ac4ac33125c32c@mail.gmail.com>
	<q2x9764d2d91004260511j18bc65faq5f0427478868ff95@mail.gmail.com>
Message-ID: <t2wdb6b5ecc1004262216o95a6d37ctb19eafb3756f8c0d@mail.gmail.com>

On Mon, Apr 26, 2010 at 5:11 AM, Gerardo Gutierrez
<muzgash.lists at gmail.com> wrote:
> David Mashburn wrote:
>
> Hello Gerardo,
>
> My name is David Mashburn and I am a graduate student in Physics at
> Vanderbilt University.
>
> I saw your GSoC proposal for IPythonQt, and though it looked very
> interesting!
>
> I just wanted to let you know about my project as you start work on yours.
> ?I have built a notebook interface atop wxPython's PyCrust and called it
> PySlices. ?It uses scintilla markers for "slice" (cell) separation, has
> multi-line support, and has a text-based "almost python" save format. ?I
> also added a little ipython-style magic, because I couldn't find an easy way
> to wrap ipython.
>

Great, I hope you can collaborate with David and exchange as much
information as possible.

Please make sure to establish communication with David (you should
invite him to join the list) as I'm sure that there will be many
useful discussions to be had.

Cheers,

f


From fperez.net at gmail.com  Tue Apr 27 01:17:40 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 26 Apr 2010 22:17:40 -0700
Subject: [IPython-dev] Gitwash: a git/github workflow document for review
In-Reply-To: <t2m83351d261004260446v9504e1d1q799f74d5bccc51df@mail.gmail.com>
References: <t2pdb6b5ecc1004251334nc278918er676aebdac98ee100@mail.gmail.com>
	<l2kfa8579a41004252111vb4c913c2h649a6500c8479b6c@mail.gmail.com>
	<t2m83351d261004260446v9504e1d1q799f74d5bccc51df@mail.gmail.com>
Message-ID: <x2wdb6b5ecc1004262217yd51edd7dt333c96d10a72e5d0@mail.gmail.com>

Hey Satra,

On Mon, Apr 26, 2010 at 4:46 AM, Satrajit Ghosh <satra at mit.edu> wrote:
> thanks for putting this together. i'm really looking forward to (ipython,
> nipy) being on github.

thanks for the feedback!  We'll try to simplify the document quite a
bit according to the comments you guys have given us.

Best,

f


From fperez.net at gmail.com  Tue Apr 27 01:23:11 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 26 Apr 2010 22:23:11 -0700
Subject: [IPython-dev] IPython projects accepted to GSoC!
Message-ID: <h2mdb6b5ecc1004262223q29d05ae4gd889919a899f997f@mail.gmail.com>

Hi everyone,

I heard today from both applicants that the two GSoC proposals from
IPython got accepted.  Congratulations to both of them!

This is very good news, as there is a lot of good work to be done on
the project.  I hope to get the github transition out of the way as
fast as possible, so that we can all work with more fluid tools, and
for Omar and Gerardo not to have to learn too much about bzr/lp since
it won't really be used in the long run (I wish I had finished this
weekend, but it was just too much work).

The full list of all 2010 gsoc projects is here:

http://socghop.appspot.com/gsoc/program/list_projects/google/gsoc2010

incidentally, I see another one that has an ipython bent to it:

http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/advancedconceptsteam/t127230757723

Student Name:  	 Dante Stroe
Mentor Name: 	Francesco Biscani
Title: 	Massively Parallel Islands via MPI, parallel IPython, and/or BOINC

Needless to say, we'll do our best to help out as well if there are
any questions from this student.

Welcome to Gerardo and Omar to the project, and I hope we all have a
very productive few months ahead!

Cheers,

f


From fperez.net at gmail.com  Tue Apr 27 01:32:16 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 26 Apr 2010 22:32:16 -0700
Subject: [IPython-dev] Zmq branch on LP: re-created.
In-Reply-To: <t2oad1253101004251803t5e597aafz3d6daf8e46d2dec2@mail.gmail.com>
References: <n2rdb6b5ecc1004251355t861d2e0dhad945010c48b28a6@mail.gmail.com>
	<t2oad1253101004251803t5e597aafz3d6daf8e46d2dec2@mail.gmail.com>
Message-ID: <q2odb6b5ecc1004262232ifdb5e22ei509d3c4d72e4d3c5@mail.gmail.com>

Hi,

2010/4/25 Omar Andr?s Zapata Mesa <andresete.chaos at gmail.com>:
>
> 1)? is tab completion a process into Queue of zmq kernels or is a simple
> thread?

There is a single zmq kernel operating, and there are no explicit
python threads here (yet, there probably will be once guis enter the
picture).

The complicated question is how to deal with the fact that
tab-completion events can come asynchronously at any point in time,
and a number of bizarre situations can occur.  For example, one client
may tab complete on x which was a number, but in the meantime x can be
reset to be a string by another client.

Think about the various possibilities that can  occur, and try to
design sensible policies for what to do in these cases.  We'll have to
discuss them and implement something reasonable (if not perfect).

> 2) is good idea make a daemon to crash recovery system?

Brian and I thought a bit about this, and we think that it might be
possible to run a 'heartbeat' socket directly in zmq.  But I  wouldn't
worry about this too much yet.

Cheers,

f


From fperez.net at gmail.com  Tue Apr 27 01:36:47 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 26 Apr 2010 22:36:47 -0700
Subject: [IPython-dev] Gsoc students: preliminary homework
Message-ID: <s2idb6b5ecc1004262236i2d12e01fhc3d5688bb8e6e8ee@mail.gmail.com>

Hi folks,

IPython is a fun project, but the internals of the code are complex to
navigate.  In order for you to succeed this summer, you'll need to get
the basic ideas right, and those are fortunately very simple, and
implemented in the Python standard library in a small and easy to read
code.  I recommend you start by understanding *extremely well* how
this module operates:

http://docs.python.org/library/code.html

That is the code that IPython originated from.  Even though today we
don't even inherit from it anymore, the interaction model is very much
the same, and it is vastly simpler to understand than IPython.  The
zmq kernel/frontend prototype that Brian and I wrote is based on it as
well.

So study and understand *every single part* of that code and the zmq
kernel/frontend examples.  IPython implements similar ideas but with a
ton of extra complexity, and you'll get lost in the IPython code if
you dive into it first.  But if you understand the code.py module,
you'll see that all IPython does is add bells and whistles to it, so
you'll be much more capable of navigating IPython itself.

Play with that, try to add a feature to it (like simple tab
completion), see how our zmq prototype uses it in a two-process model,
etc.  Once the main objects in that code make sense to you, and how
they operate, dive into the IPython source tree itself.

Given the official timeline:

http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/timeline

You have one month of 'community bonding' to get up to speed on the
project. That month starts now :)


Cheers,

f


From fperez.net at gmail.com  Tue Apr 27 01:43:25 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 26 Apr 2010 22:43:25 -0700
Subject: [IPython-dev] Engineering formatting
In-Reply-To: <p2s9457e7c81004241135g35be501at64c37f5d7469ccfe@mail.gmail.com>
References: <p2t9457e7c81004191337pe93de202na537c0bd38587206@mail.gmail.com>
	<hqkp8u$fnh$1@dough.gmane.org> <4BCF2537.9000500@enthought.com>
	<p2s9457e7c81004241135g35be501at64c37f5d7469ccfe@mail.gmail.com>
Message-ID: <q2idb6b5ecc1004262243u41ea633t3a080522c4b069a9@mail.gmail.com>

2010/4/24 St?fan van der Walt <stefan at sun.ac.za>:
>
> Thanks for the code snippets! ?I've put them into a profile and added
> array printing (attached). ?Maybe a useful profile to distribute?

Hold that thought :)  Have you tested it with trunk yet? We haven't
documented too much how to change config stuff for trunk, but I don't
want to put much more effort into 0.10 series machinery...

If you can spelunk your way to make it work with trunk definitely send
it our way, otherwise I'll give you a hand as soon as I catch  a
breather.  Right now the git transition and gsoc stuff is taking up
all  my (non-existent) available time.

cheers,

f


From stefan at sun.ac.za  Tue Apr 27 06:29:24 2010
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 27 Apr 2010 12:29:24 +0200
Subject: [IPython-dev] Engineering formatting
In-Reply-To: <q2idb6b5ecc1004262243u41ea633t3a080522c4b069a9@mail.gmail.com>
References: <p2t9457e7c81004191337pe93de202na537c0bd38587206@mail.gmail.com> 
	<hqkp8u$fnh$1@dough.gmane.org> <4BCF2537.9000500@enthought.com> 
	<p2s9457e7c81004241135g35be501at64c37f5d7469ccfe@mail.gmail.com> 
	<q2idb6b5ecc1004262243u41ea633t3a080522c4b069a9@mail.gmail.com>
Message-ID: <z2u9457e7c81004270329s8af1c83bma217c88bfcb2b7be@mail.gmail.com>

On 27 April 2010 07:43, Fernando Perez <fperez.net at gmail.com> wrote:
> Hold that thought :) ?Have you tested it with trunk yet? We haven't
> documented too much how to change config stuff for trunk, but I don't
> want to put much more effort into 0.10 series machinery...
>
> If you can spelunk your way to make it work with trunk definitely send
> it our way, otherwise I'll give you a hand as soon as I catch ?a
> breather. ?Right now the git transition and gsoc stuff is taking up
> all ?my (non-existent) available time.

I couldn't get it to work with 0.10, so I'm currently running
0.11.alpha1.bzr.r1223.  Not sure where "trunk" is exactly these days,
but maybe that's close enough?

Cheers
St?fan


From fperez.net at gmail.com  Tue Apr 27 13:21:32 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 27 Apr 2010 10:21:32 -0700
Subject: [IPython-dev] Engineering formatting
In-Reply-To: <z2u9457e7c81004270329s8af1c83bma217c88bfcb2b7be@mail.gmail.com>
References: <p2t9457e7c81004191337pe93de202na537c0bd38587206@mail.gmail.com>
	<hqkp8u$fnh$1@dough.gmane.org> <4BCF2537.9000500@enthought.com>
	<p2s9457e7c81004241135g35be501at64c37f5d7469ccfe@mail.gmail.com>
	<q2idb6b5ecc1004262243u41ea633t3a080522c4b069a9@mail.gmail.com>
	<z2u9457e7c81004270329s8af1c83bma217c88bfcb2b7be@mail.gmail.com>
Message-ID: <u2rdb6b5ecc1004271021jee64db9eh793ac9e274244797@mail.gmail.com>

2010/4/27 St?fan van der Walt <stefan at sun.ac.za>:
>
> I couldn't get it to work with 0.10, so I'm currently running
> 0.11.alpha1.bzr.r1223. ?Not sure where "trunk" is exactly these days,
> but maybe that's close enough?

Oh yes, trunk is the 0.11 series.  I'll have a look then, thanks!

Cheers,

f


From ellisonbg at gmail.com  Tue Apr 27 17:13:13 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 27 Apr 2010 14:13:13 -0700
Subject: [IPython-dev] Brian and Vishal, help with #400600?
In-Reply-To: <w2wfa8579a41004252056lcee1c96cvf3ad203e3e91ec38@mail.gmail.com>
References: <v2mdb6b5ecc1004251604nc9cd8156x3657f6009761bdda@mail.gmail.com>
	<w2wfa8579a41004252056lcee1c96cvf3ad203e3e91ec38@mail.gmail.com>
Message-ID: <t2gfa8579a41004271413x1722bf3eq28a82b3d81972c68@mail.gmail.com>

It looks like this one has already been fixed.  We are good to go.

Brian

On Sun, Apr 25, 2010 at 8:56 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> This patch can be applied.
>
> Brian
>
> On Sun, Apr 25, 2010 at 4:04 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>> Hey guys,
>>
>> I see you've been active on this one:
>>
>> https://bugs.launchpad.net/ipython/+bug/400600
>>
>> It's the last remaining bug on LP that both has a patch and is still
>> open, everything else with patches I've already committed. ?Since bugs
>> with patches will be harder to auto-migrate to Gh, I'd like to close
>> them for good while still on LP where the patch is tracked, to
>> simplify life.
>>
>> If you guys have a chance to clarify the status of this one before we
>> make the transition, it would be great.
>>
>> 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
>



-- 
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  Tue Apr 27 17:14:40 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 27 Apr 2010 14:14:40 -0700
Subject: [IPython-dev] Brian and Vishal, help with #400600?
In-Reply-To: <t2gfa8579a41004271413x1722bf3eq28a82b3d81972c68@mail.gmail.com>
References: <v2mdb6b5ecc1004251604nc9cd8156x3657f6009761bdda@mail.gmail.com>
	<w2wfa8579a41004252056lcee1c96cvf3ad203e3e91ec38@mail.gmail.com>
	<t2gfa8579a41004271413x1722bf3eq28a82b3d81972c68@mail.gmail.com>
Message-ID: <j2gdb6b5ecc1004271414n92cdcef7u161aee06dfc76375@mail.gmail.com>

On Tue, Apr 27, 2010 at 2:13 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> It looks like this one has already been fixed. ?We are good to go.

Awesome, thanks!

Cheers,

f


From hans_meine at gmx.net  Thu Apr 29 03:50:48 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Thu, 29 Apr 2010 09:50:48 +0200
Subject: [IPython-dev] Zmq branch on LP: re-created.
In-Reply-To: <q2odb6b5ecc1004262232ifdb5e22ei509d3c4d72e4d3c5@mail.gmail.com>
References: <n2rdb6b5ecc1004251355t861d2e0dhad945010c48b28a6@mail.gmail.com>
	<t2oad1253101004251803t5e597aafz3d6daf8e46d2dec2@mail.gmail.com>
	<q2odb6b5ecc1004262232ifdb5e22ei509d3c4d72e4d3c5@mail.gmail.com>
Message-ID: <201004290950.50985.hans_meine@gmx.net>

Am Dienstag 27 April 2010 07:32:16 schrieb Fernando Perez:
> > 2) is good idea make a daemon to crash recovery system?
> 
> Brian and I thought a bit about this, and we think that it might be
> possible to run a 'heartbeat' socket directly in zmq.  But I  wouldn't
> worry about this too much yet.

In our own two-process, Qt-based python terminal, we simply connected to the 
signal the TCP socket class emits when the connection closed.  AFAIK that's 
the standard approach for TCP/IP-based IPC with daemons (e.g. I recall 
KDE/DCOP etc. do that), and if 0mq really is the superior solution nowadays,
I hope it offers the same failsafe detection of a lost/closed connection.

HTH,
  Hans


From ccordoba12 at gmail.com  Thu Apr 29 11:41:52 2010
From: ccordoba12 at gmail.com (=?ISO-8859-1?Q?Carlos_C=F3rdoba?=)
Date: Thu, 29 Apr 2010 10:41:52 -0500
Subject: [IPython-dev] notebook-like format for IPythonQt sessions.
In-Reply-To: <n2rfa8579a41004252055pab4fcd30ud9908b872d6b6768@mail.gmail.com>
References: <g2w9764d2d91004161631t1fb449pa74b6b9a379ec4f@mail.gmail.com> 
	<m2x9764d2d91004171702pcdc5c5bcx5491158154a6b844@mail.gmail.com> 
	<hqdm49$b8f$1@dough.gmane.org>
	<n2rfa8579a41004252055pab4fcd30ud9908b872d6b6768@mail.gmail.com>
Message-ID: <v2k73ec3e1f1004290841mceb2628bua99b140316f3300e@mail.gmail.com>

Whatever the format for saving sessions is chosen, I think it would be a
great idea if one could execute a whole notebook from the terminal with
something like:

ipython -nb foo.inb (inb = ipython notebook)

or call it with the %run magic. This way you could write self-contained
programs with IpythonQt and use ipython as an interpreter to run them.

I'm very fond of literate
programming<http://en.wikipedia.org/wiki/Special%3ASearch/literate_programming>and
I think it would be very useful to write programs as text (with
sections, subsections, equations, figures, etc) but with the possibility to
run them as easily as possible.

Carlos

2010/4/25 Brian Granger <ellisonbg at gmail.com>

> On Sat, Apr 17, 2010 at 6:08 PM, Robert Kern <robert.kern at gmail.com>
> wrote:
> > On 2010-04-17 19:02 , Gerardo Gutierrez wrote:
> >> Ok i'm going to paste a fragment of a document about this topic (that
> >> I've not noticed until today)
> >>
> >>
> >> /The frontend would store, for now, 5 types of data:
> >>
> >> #. Input: this is python/ipython code to be executed.
> >>
> >> #. Output (python): result of executing Inputs.
> >>
> >> #. Standard output: from subprocesses.
> >>
> >> #. Standard error: from subprocesses.
> >>
> >> #. Text: arbitrary text. For now, we'll just store plain text and will
> defer
> >> to the user on how to format it, though it should be valid reST if it is
> >> later to be converted into html/pdf.
> >>
> >> The non-text cells would be stored on-disk as follows::
> >>
> >> .. input-cell::
> >> :id: 1
> >>
> >> 3+3
> >>
> >> .. output-cell::
> >> :id: 1
> >>
> >> 6
> >>
> >> .. input-cell::
> >> :id: 2
> >>
> >> ls
> >>
> >> .. stdout-cell::
> >> :id: 2
> >>
> >> a.py b.py
> >>
> >> .. input-cell::
> >> :id: 3
> >>
> >> !askdfj
> >>
> >> .. stderr-cell::
> >> :id: 3
> >>
> >> sh: askdfj: command not found/
> >>
> >>
> >> This document clears some ideas, since the natural way for an IPython's
> >> frontend (not only IPythonQt) to load data is rst in wich Python's and
> >> IPython's documentation is written.
> >
> > I would not say that it is natural, no. reST is a fine text markup, but
> not a
> > very good datastore. The parser is difficult to work with, and there
> aren't any
> > tools for generating valid reST from a parsed description.
>
> I agree with Robert that reST is probably not the best option for this.
>
> > I highly recommend using xml.etree to parse and generate a simple XML
> format.
>
> I am not quite as excited about XML as Robert, but my feeling is this:
>  it should be XML unless someone comes up with an option that beats
> it.
>
> Cheers,
>
> Brian
>
> > --
> > 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
> >
> > _______________________________________________
> > 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
> _______________________________________________
> 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/20100429/41ea52a9/attachment.html>

From ellisonbg at gmail.com  Thu Apr 29 12:28:34 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 29 Apr 2010 09:28:34 -0700
Subject: [IPython-dev] Zmq branch on LP: re-created.
In-Reply-To: <201004290950.50985.hans_meine@gmx.net>
References: <n2rdb6b5ecc1004251355t861d2e0dhad945010c48b28a6@mail.gmail.com>
	<t2oad1253101004251803t5e597aafz3d6daf8e46d2dec2@mail.gmail.com>
	<q2odb6b5ecc1004262232ifdb5e22ei509d3c4d72e4d3c5@mail.gmail.com>
	<201004290950.50985.hans_meine@gmx.net>
Message-ID: <i2tfa8579a41004290928vb479be27i19c5818689a1e24@mail.gmail.com>

Hans,

0MQ has very smart reconnection logic, and we take advantage of that
in the huge way.  For example, you can send messages to a process that
is not currently running.  Those message will be queued and when the
process appears, 0MQ detects that and will send the messages.  Also,
0MQ will disconnect/reconnect its raw sockets many times if needed.
The bottom line is that you can't detect the types of failures you are
talking about at the user API level.  At first, this bothered me as I
am used to handling the disconnect by hand.  But, as time has gone on,
I see the huge advantages this approach gives.  In this new way of
thinking a heartbeat is the only way to detect if a peer is truly
alive.

Cheers,

Brian

On Thu, Apr 29, 2010 at 12:50 AM, Hans Meine <hans_meine at gmx.net> wrote:
> Am Dienstag 27 April 2010 07:32:16 schrieb Fernando Perez:
>> > 2) is good idea make a daemon to crash recovery system?
>>
>> Brian and I thought a bit about this, and we think that it might be
>> possible to run a 'heartbeat' socket directly in zmq. ?But I ?wouldn't
>> worry about this too much yet.
>
> In our own two-process, Qt-based python terminal, we simply connected to the
> signal the TCP socket class emits when the connection closed. ?AFAIK that's
> the standard approach for TCP/IP-based IPC with daemons (e.g. I recall
> KDE/DCOP etc. do that), and if 0mq really is the superior solution nowadays,
> I hope it offers the same failsafe detection of a lost/closed connection.
>
> HTH,
> ?Hans
> _______________________________________________
> 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 Apr 29 19:30:05 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 29 Apr 2010 16:30:05 -0700
Subject: [IPython-dev] Zmq branch on LP: re-created.
In-Reply-To: <201004290950.50985.hans_meine@gmx.net>
References: <n2rdb6b5ecc1004251355t861d2e0dhad945010c48b28a6@mail.gmail.com> 
	<t2oad1253101004251803t5e597aafz3d6daf8e46d2dec2@mail.gmail.com> 
	<q2odb6b5ecc1004262232ifdb5e22ei509d3c4d72e4d3c5@mail.gmail.com> 
	<201004290950.50985.hans_meine@gmx.net>
Message-ID: <s2ldb6b5ecc1004291630g9ed679c4vfd4bc958171803d0@mail.gmail.com>

On Thu, Apr 29, 2010 at 12:50 AM, Hans Meine <hans_meine at gmx.net> wrote:
> In our own two-process, Qt-based python terminal, we simply connected to the
> signal the TCP socket class emits when the connection closed. ?AFAIK that's
> the standard approach for TCP/IP-based IPC with daemons (e.g. I recall
> KDE/DCOP etc. do that), and if 0mq really is the superior solution nowadays,
> I hope it offers the same failsafe detection of a lost/closed connection.

I don't think zmq sockets signal when they drop the connection,
though.  Brian, is that right?

Hans, were you using pure python sockets?  We're trying to avoid any
python code in the sockets layer, so that message queuing can continue
to happen even if the kernel is running blocking code (e.g. numpy).
zmq does that by releasing the gil for most of its operations.  Was
that not an issue for you guys?

Cheers,

f


From ellisonbg at gmail.com  Thu Apr 29 22:43:16 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 29 Apr 2010 19:43:16 -0700
Subject: [IPython-dev] Zmq branch on LP: re-created.
In-Reply-To: <s2ldb6b5ecc1004291630g9ed679c4vfd4bc958171803d0@mail.gmail.com>
References: <n2rdb6b5ecc1004251355t861d2e0dhad945010c48b28a6@mail.gmail.com>
	<t2oad1253101004251803t5e597aafz3d6daf8e46d2dec2@mail.gmail.com>
	<q2odb6b5ecc1004262232ifdb5e22ei509d3c4d72e4d3c5@mail.gmail.com>
	<201004290950.50985.hans_meine@gmx.net>
	<s2ldb6b5ecc1004291630g9ed679c4vfd4bc958171803d0@mail.gmail.com>
Message-ID: <u2wfa8579a41004291943wec13344dz8a026950078bab1b@mail.gmail.com>

On Thu, Apr 29, 2010 at 4:30 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Thu, Apr 29, 2010 at 12:50 AM, Hans Meine <hans_meine at gmx.net> wrote:
>> In our own two-process, Qt-based python terminal, we simply connected to the
>> signal the TCP socket class emits when the connection closed. ?AFAIK that's
>> the standard approach for TCP/IP-based IPC with daemons (e.g. I recall
>> KDE/DCOP etc. do that), and if 0mq really is the superior solution nowadays,
>> I hope it offers the same failsafe detection of a lost/closed connection.
>
> I don't think zmq sockets signal when they drop the connection,
> though. ?Brian, is that right?

Correct.

> Hans, were you using pure python sockets? ?We're trying to avoid any
> python code in the sockets layer, so that message queuing can continue
> to happen even if the kernel is running blocking code (e.g. numpy).
> zmq does that by releasing the gil for most of its operations. ?Was
> that not an issue for you guys?

Probably not my guess.

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 hans_meine at gmx.net  Fri Apr 30 05:12:27 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Fri, 30 Apr 2010 11:12:27 +0200
Subject: [IPython-dev] Zmq branch on LP: re-created.
Message-ID: <201004301112.27993.hans_meine@gmx.net>

Am Donnerstag 29 April 2010 18:28:34 schrieben Sie:
> The bottom line is that you can't detect the types of failures you are
> talking about at the user API level.  At first, this bothered me as I
> am used to handling the disconnect by hand.  But, as time has gone on,
> I see the huge advantages this approach gives.

I agree that all in all, this behaviour is very desirable.

> In this new way of
> thinking a heartbeat is the only way to detect if a peer is truly
> alive.

Hmm.  But "heartbeat" sounds as if the peer needs to respond.  Wouldn't it be 
even better to open a raw (non-0mq-)socket just to be able to watch it and get 
notified by the OS if the peer dies?

Best,
  Hans


From hans_meine at gmx.net  Fri Apr 30 05:12:34 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Fri, 30 Apr 2010 11:12:34 +0200
Subject: [IPython-dev] Zmq branch on LP: re-created.
Message-ID: <201004301112.40415.hans_meine@gmx.net>

Am Freitag 30 April 2010 01:30:05 schrieben Sie:
> Hans, were you using pure python sockets?

I was about to say no, but actually we did:
  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
although we later used Qt's QSocketNotifier around it (by taking s.fileno()), 
so the select() would happen from within C++.

> We're trying to avoid any
> python code in the sockets layer, so that message queuing can continue
> to happen even if the kernel is running blocking code (e.g. numpy).
> zmq does that by releasing the gil for most of its operations.  Was
> that not an issue for you guys?

I am not sure I understand the problem.  Of course, the backend could (and 
would) block and not respond to the commands, so for example completion would 
not work during program execution.  But I don't see a way around that.  
Messages would not be queued as in 0mq, but I guess the OS would maintain some 
buffer.

Sorry if I could not really answer your question; I guess my memory is already 
too faint (this was 2003 according to the /CVS/ logs..).

Anyhow, the 0mq approach is certainly better for the main communication, I was 
just wondering about the detection of a crashed backend.

Best,
  Hans


From edreamleo at gmail.com  Fri Apr 30 09:58:20 2010
From: edreamleo at gmail.com (Edward K. Ream)
Date: Fri, 30 Apr 2010 08:58:20 -0500
Subject: [IPython-dev] notebook-like format for IPythonQt sessions.
Message-ID: <i2uffb592891004300658pca02c496yd566f0fa586d055f@mail.gmail.com>

Hello all,

I've been on vacation without a good way to respond to this thread.  I
have no idea whether any of the following will be of any use to the
topic under discussion, but it might.

I have a keen interest in this topic, for several reasons that you may
or may not be familiar with.

First, Leo could already be said to be a "front end" to IPython, and
Leo's Qt gui works well with IPython.  Leo's Qt outline widget is
sophisticated and is highly optimized for large outlines.  It's also
solid, which is no mean feat, considering that it can be driven by
Python scripts as well as by the user.

Second, Mathematica is not the best notebook available, Leo is.
Mathematica notebooks are trees, not dags, which has profound
implications for data handling, as Leo proves.  Mathematica's DOM and
scripting are weak; Leo's (python) scripts have easy access to all
outline data via a simple and easy-to-use api.

Third, Leo outlines are xml files.  .leo files have an "extension
mechanism", uA's (user/unknown attributes), that allows any kind of
data to be attached to any node in the outline.  Thus, there is no
urgent need to define one's own xml tags.  The user (or Leo plugin)
can embed any kind of data into a Leo outline without having to reach
a consensus about the format of the data.

To repeat, I have no idea whether any part of Leo will be of use in
the project under discussion.  But it might be worthwhile to take a
look at Leo, its Qt interface, its xml file format and its in-core
data structures.  The features I have summarized here have been under
development for 15+ years.  Leo is pure Python and a single code base
works with Python 2.6 and Python 3.1.

Edward
------------------------------------------------------------------------------
Edward K. Ream email: edreamleo at gmail.com
Leo: http://webpages.charter.net/edreamleo/front.html
------------------------------------------------------------------------------


From ellisonbg at gmail.com  Fri Apr 30 11:16:04 2010
From: ellisonbg at gmail.com (Brian Granger)
Date: Fri, 30 Apr 2010 08:16:04 -0700
Subject: [IPython-dev] Zmq branch on LP: re-created.
In-Reply-To: <201004301112.40415.hans_meine@gmx.net>
References: <201004301112.40415.hans_meine@gmx.net>
Message-ID: <p2rfa8579a41004300816qf228a5e0ode7e9441ba578ec9@mail.gmail.com>

On Fri, Apr 30, 2010 at 2:12 AM, Hans Meine <hans_meine at gmx.net> wrote:
> Am Freitag 30 April 2010 01:30:05 schrieben Sie:
>> Hans, were you using pure python sockets?
>
> I was about to say no, but actually we did:
> ?s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> although we later used Qt's QSocketNotifier around it (by taking s.fileno()),
> so the select() would happen from within C++.
>
>> We're trying to avoid any
>> python code in the sockets layer, so that message queuing can continue
>> to happen even if the kernel is running blocking code (e.g. numpy).
>> zmq does that by releasing the gil for most of its operations. ?Was
>> that not an issue for you guys?
>
> I am not sure I understand the problem. ?Of course, the backend could (and
> would) block and not respond to the commands, so for example completion would
> not work during program execution. ?But I don't see a way around that.
> Messages would not be queued as in 0mq, but I guess the OS would maintain some
> buffer.

With 0MQ, the heartbeat responder will be able to reply *while* the
kernel executes code of any kind as the heartbeat responder will run
in a native C++ that doesn't hold the GIL.

> Sorry if I could not really answer your question; I guess my memory is already
> too faint (this was 2003 according to the /CVS/ logs..).
>
> Anyhow, the 0mq approach is certainly better for the main communication, I was
> just wondering about the detection of a crashed backend.
>
> Best,
> ?Hans
> _______________________________________________
> 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  Fri Apr 30 17:54:50 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 30 Apr 2010 14:54:50 -0700
Subject: [IPython-dev] notebook-like format for IPythonQt sessions.
In-Reply-To: <i2uffb592891004300658pca02c496yd566f0fa586d055f@mail.gmail.com>
References: <i2uffb592891004300658pca02c496yd566f0fa586d055f@mail.gmail.com>
Message-ID: <q2wdb6b5ecc1004301454x925bfda8jba2f65e235af1b0d@mail.gmail.com>

On Fri, Apr 30, 2010 at 6:58 AM, Edward K. Ream <edreamleo at gmail.com> wrote:
>
> To repeat, I have no idea whether any part of Leo will be of use in
> the project under discussion. ?But it might be worthwhile to take a
> look at Leo, its Qt interface, its xml file format and its in-core
> data structures. ?The features I have summarized here have been under
> development for 15+ years. ?Leo is pure Python and a single code base
> works with Python 2.6 and Python 3.1.

Thanks for the pointers. Since leo is mit licensed it's compatible
with ipython's license, so we can take ideas from there.

Regards,

f