Removetwisted #325

Closed
wants to merge 5 commits into
from

Conversation

Projects
None yet
5 participants
@ellisonbg
Member

ellisonbg commented Mar 31, 2011

This pull request removes the Twisted based IPython.kernel. I have tried to go through the entire codebase and remove all twisted/zope.interface/foolscap using code. This includes the test suite and setup scripts, but not (yet) documentation or examples as we need to transition those to the new zmq parallel stuff. I will add issues for that work.

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Mar 31, 2011

Member

Does this mean that the newparallel scripts should just be ipcontroller/engine/cluster, and not with the 'z' suffix, since kernel and newparallel will not coexist?

Member

minrk commented Mar 31, 2011

Does this mean that the newparallel scripts should just be ipcontroller/engine/cluster, and not with the 'z' suffix, since kernel and newparallel will not coexist?

@takluyver

This comment has been minimized.

Show comment
Hide comment
@takluyver

takluyver Mar 31, 2011

Member

The thinking at sage days was that the old parallel stuff would be kept around but deprecated in 0.11, so that people can upgrade to it and then start changing their code to the new framework.

Member

takluyver commented Mar 31, 2011

The thinking at sage days was that the old parallel stuff would be kept around but deprecated in 0.11, so that people can upgrade to it and then start changing their code to the new framework.

@ellisonbg

This comment has been minimized.

Show comment
Hide comment
@ellisonbg

ellisonbg Mar 31, 2011

Member

Min, Fernando and I talked yesterday and decided it would be best to
remove it. The reasoning was this: when we update the config stuff in
master, it will completely break IPython.kernel. We hadn't realized
this when we last talked about it. Because we don't want to (or have
the time to) fix those regressions, we feel it is better to remove it
outright. The changes required to fix this will be significant and
require a lot of difficult testing on different platforms and batch
schedulers.

Brian

On Thu, Mar 31, 2011 at 3:35 AM, takluyver
reply@reply.github.com
wrote:

The thinking at sage days was that the old parallel stuff would be kept around but deprecated in 0.11, so that people can upgrade to it and then start changing their code to the new framework.

Reply to this email directly or view it on GitHub:
#325 (comment)

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

Member

ellisonbg commented Mar 31, 2011

Min, Fernando and I talked yesterday and decided it would be best to
remove it. The reasoning was this: when we update the config stuff in
master, it will completely break IPython.kernel. We hadn't realized
this when we last talked about it. Because we don't want to (or have
the time to) fix those regressions, we feel it is better to remove it
outright. The changes required to fix this will be significant and
require a lot of difficult testing on different platforms and batch
schedulers.

Brian

On Thu, Mar 31, 2011 at 3:35 AM, takluyver
reply@reply.github.com
wrote:

The thinking at sage days was that the old parallel stuff would be kept around but deprecated in 0.11, so that people can upgrade to it and then start changing their code to the new framework.

Reply to this email directly or view it on GitHub:
#325 (comment)

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

@takluyver

This comment has been minimized.

Show comment
Hide comment
@takluyver

takluyver Mar 31, 2011

Member

Ah, I see. Maybe we should codename 0.11 "a new dawn" ;-)

Member

takluyver commented Mar 31, 2011

Ah, I see. Maybe we should codename 0.11 "a new dawn" ;-)

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Mar 31, 2011

Member

Or for that matter, maybe we should skip right by 1.0, and just go straight to IPython 2.0. It would be more representative of the amount of work in 0.11.

Member

minrk commented Mar 31, 2011

Or for that matter, maybe we should skip right by 1.0, and just go straight to IPython 2.0. It would be more representative of the amount of work in 0.11.

@fperez

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Mar 31, 2011

Member

Thomas, I think we should call it 0.80 or something, indicating that we're preparing for 1.0 but there may still be some api shakedown. The idea will be:

  • 0.10.x -> old code, with twisted in it
  • 0.8x -> new project layout, stabilisation of apis. Basically what we have now, once this pull request goes in and we merge newparallel and new config.
  • 0.9x -> api stable, shake out bugs for release
  • 1.0 -> once we're happy enough with the 0.9x series.

How does that sound?

Brian, thanks a lot for doing this! This is phenomenal :)

Member

fperez commented Mar 31, 2011

Thomas, I think we should call it 0.80 or something, indicating that we're preparing for 1.0 but there may still be some api shakedown. The idea will be:

  • 0.10.x -> old code, with twisted in it
  • 0.8x -> new project layout, stabilisation of apis. Basically what we have now, once this pull request goes in and we merge newparallel and new config.
  • 0.9x -> api stable, shake out bugs for release
  • 1.0 -> once we're happy enough with the 0.9x series.

How does that sound?

Brian, thanks a lot for doing this! This is phenomenal :)

@takluyver

This comment has been minimized.

Show comment
Hide comment
@takluyver

takluyver Mar 31, 2011

Member

I don't like 0.80 - it's too liable to be confused with 0.8. I prefer Min's idea of working towards a 2.0 release. IPython as I'm already using it (0.10) is a perfectly usable and working "1.0" solution. So I suggest we call the next release something like 1.9, then have a series of bugfixes and stabilisations leading up to IPython 2.0.

Member

takluyver commented Mar 31, 2011

I don't like 0.80 - it's too liable to be confused with 0.8. I prefer Min's idea of working towards a 2.0 release. IPython as I'm already using it (0.10) is a perfectly usable and working "1.0" solution. So I suggest we call the next release something like 1.9, then have a series of bugfixes and stabilisations leading up to IPython 2.0.

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Mar 31, 2011

Member

That sounds fine to me. 0.11 just seems too small.

Member

minrk commented Mar 31, 2011

That sounds fine to me. 0.11 just seems too small.

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Mar 31, 2011

Member

matplotlib did 0.99.x for their stabilization stage. We are considering an extra stage prior to that. Maybe 0.88.x? That won't be confused with 0.8.

Member

minrk commented Mar 31, 2011

matplotlib did 0.99.x for their stabilization stage. We are considering an extra stage prior to that. Maybe 0.88.x? That won't be confused with 0.8.

@fperez

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Mar 31, 2011

Member

Sure, 0.88x sounds like a good plan.

Member

fperez commented Mar 31, 2011

Sure, 0.88x sounds like a good plan.

@takluyver

This comment has been minimized.

Show comment
Hide comment
@takluyver

takluyver Mar 31, 2011

Member

0.88.x is more clearly distinguished, but... I don't know, it just seems a little ridiculous. I don't think there's any way to do sensible version numbering leading up to a 1.0 release down the line. Also, how much of the codebase has been refactored or rewritten, I think you were right that 2.0 is a more accurate way to describe it.

Member

takluyver commented Mar 31, 2011

0.88.x is more clearly distinguished, but... I don't know, it just seems a little ridiculous. I don't think there's any way to do sensible version numbering leading up to a 1.0 release down the line. Also, how much of the codebase has been refactored or rewritten, I think you were right that 2.0 is a more accurate way to describe it.

@ellisonbg

This comment has been minimized.

Show comment
Hide comment
@ellisonbg

ellisonbg Mar 31, 2011

Member

I am still not satisfied with the versioning. 0.88 seems almost arbitrary and 0.99 implies we very close to 1.0 (not quite there). I am almost thinking that just sticking with 0.11, 0.12, etc. until we are really thinking about 1.0 makes the most sense.

Member

ellisonbg commented Mar 31, 2011

I am still not satisfied with the versioning. 0.88 seems almost arbitrary and 0.99 implies we very close to 1.0 (not quite there). I am almost thinking that just sticking with 0.11, 0.12, etc. until we are really thinking about 1.0 makes the most sense.

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Apr 1, 2011

Member

Sure, we can stick with 0.x if there are objections, it has the inertia, but I think we are really thinking about 1.0. Even if we are sticking to 0.11 with newparallel and config in April, and 0.12 with htmlnotebook very soon after, I think that 0.99 (or whatever we decide to call pre-1.0 preparation) would come immediately thereafter. I expect (or at least hope) that this will happen in 2011.

New things IPython 1.0 will have, not in 0.10:

  • completely reorganized codebase (0.11)
  • no twisted (0.11)
  • newparallel (0.11)
  • new config (0.11)
  • display (0.11)
  • unicode (0.11)
  • qtconsole (0.11)
  • html notebook (0.12)
  • two-process 0MQ terminal (0.12?)
    Anything else? Curses Terminal?

I see two options here. Either we consider 0.99.0 as the point where we don't mind breaking everything in preparation for 1.0 (what we are doing in 0.11), or we jump to 0.99 the instant we are 1.0 feature-complete (not bug-free, just having a releasable version of all new features), and consider it strictly stabilization and cleanup. I like the former, because it better prepares users for the changes they will face in an update, but the latter makes sense too. I don't think too many users would expect approximately zero API compatibility between 0.10 and 0.11.

I checked matplotlib's history, and they had a 0.98.x series prior to 0.99.x. I think this is better than 0.88, other than Fernando's comment that 0.88 is 0.11, but 8 times as awesome.

Other options are: jump a short distance to 0.20, or say we are halfway there with 0.50. If there's no consensus, let's stick to 0.11, but I would vote for approximately every other proposal so far before 0.11.

Member

minrk commented Apr 1, 2011

Sure, we can stick with 0.x if there are objections, it has the inertia, but I think we are really thinking about 1.0. Even if we are sticking to 0.11 with newparallel and config in April, and 0.12 with htmlnotebook very soon after, I think that 0.99 (or whatever we decide to call pre-1.0 preparation) would come immediately thereafter. I expect (or at least hope) that this will happen in 2011.

New things IPython 1.0 will have, not in 0.10:

  • completely reorganized codebase (0.11)
  • no twisted (0.11)
  • newparallel (0.11)
  • new config (0.11)
  • display (0.11)
  • unicode (0.11)
  • qtconsole (0.11)
  • html notebook (0.12)
  • two-process 0MQ terminal (0.12?)
    Anything else? Curses Terminal?

I see two options here. Either we consider 0.99.0 as the point where we don't mind breaking everything in preparation for 1.0 (what we are doing in 0.11), or we jump to 0.99 the instant we are 1.0 feature-complete (not bug-free, just having a releasable version of all new features), and consider it strictly stabilization and cleanup. I like the former, because it better prepares users for the changes they will face in an update, but the latter makes sense too. I don't think too many users would expect approximately zero API compatibility between 0.10 and 0.11.

I checked matplotlib's history, and they had a 0.98.x series prior to 0.99.x. I think this is better than 0.88, other than Fernando's comment that 0.88 is 0.11, but 8 times as awesome.

Other options are: jump a short distance to 0.20, or say we are halfway there with 0.50. If there's no consensus, let's stick to 0.11, but I would vote for approximately every other proposal so far before 0.11.

@takluyver

This comment has been minimized.

Show comment
Hide comment
@takluyver

takluyver Apr 1, 2011

Member

I'd support 0.98.x/0.99.x, i.e. 'nearly 1.0', or 0.50.x as 'a big jump from 0.10.x'.

Member

takluyver commented Apr 1, 2011

I'd support 0.98.x/0.99.x, i.e. 'nearly 1.0', or 0.50.x as 'a big jump from 0.10.x'.

@fperez

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Apr 3, 2011

Member

matplotlib had a 0.51, 0.52... series half-way through the transition too.

Honestly I don't really care much. We're burning pointless cycles here, which means we should simply stop worrying about this, keep going with 0.11, etc, and one day call it 1.0 as soon as it's ready. We have better things to spend our time on than endlessly debating numbering schemes. It's even less interesting than bsd/gpl conversations, which at least have some interesting philosophical side-tracks...

Member

fperez commented Apr 3, 2011

matplotlib had a 0.51, 0.52... series half-way through the transition too.

Honestly I don't really care much. We're burning pointless cycles here, which means we should simply stop worrying about this, keep going with 0.11, etc, and one day call it 1.0 as soon as it's ready. We have better things to spend our time on than endlessly debating numbering schemes. It's even less interesting than bsd/gpl conversations, which at least have some interesting philosophical side-tracks...

@fperez

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Apr 3, 2011

Member

So, back to the actual pull request: Brian, do you think we should pull the trigger on this one now? In my mind, this should be merged sooner rather than later so that Min can rebase newparallel on top of master at that point. He can then adjust the startup scripts and we can simplify things. The only major thing left to do will then be the config work. I'm having a look at this code now, but I wanted to know what you guys think timeline-wise...

Member

fperez commented Apr 3, 2011

So, back to the actual pull request: Brian, do you think we should pull the trigger on this one now? In my mind, this should be merged sooner rather than later so that Min can rebase newparallel on top of master at that point. He can then adjust the startup scripts and we can simplify things. The only major thing left to do will then be the config work. I'm having a look at this code now, but I wanted to know what you guys think timeline-wise...

IPython/kernel/__init__.py
@@ -1,25 +1,6 @@
-# encoding: utf-8
-"""The IPython1 kernel.
+msg = """IPython.kernel has been replaced by IPython.parallel.

This comment has been minimized.

@fperez

fperez Apr 3, 2011

Member

This should just be left as a docstring, and then the import error can do

raise ImportError(__doc__)

that way even afterwards, introspection will do the expected thing on the module object.

I also think the message here needs to be longer and more detailed, so that in addition to the above line there's a short indication of what that means and a link to the page on the docs that provides usage/transition info. Even if for now that URL isn't ready, let's put something in here as a placeholder so we don't forget later. The idea is that the importerror alone should give people enough to go on by themselves without having to ask us on-list.

@fperez

fperez Apr 3, 2011

Member

This should just be left as a docstring, and then the import error can do

raise ImportError(__doc__)

that way even afterwards, introspection will do the expected thing on the module object.

I also think the message here needs to be longer and more detailed, so that in addition to the above line there's a short indication of what that means and a link to the page on the docs that provides usage/transition info. Even if for now that URL isn't ready, let's put something in here as a placeholder so we don't forget later. The idea is that the importerror alone should give people enough to go on by themselves without having to ask us on-list.

@fperez

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Apr 3, 2011

Member

Other than my minor inline notes, the code cleanup itself looks great, thanks!

The one thing I'd like to see added right away is some note in the docs about what's going on, even if it's just a short explanatory paragraph. Because we'll want to build the docs and push a build with this information immediately to the users, so people can start preparing for it (as well as announcing it quite loudly on the lists).

In fact, I'd suggest pinging the -dev and -user lists right away pointing to this pull request and indicating what's going on, so people can start preparing. Because the moment it gets merged, anyone who was running from master with twisted code (and I'm sure there are people like that, for whom it was working with local clusters) are going to be in for a really rough ride...

So I think before actually pulling the trigger on this one, we really need to make an announcement on the lists, so people at least are given a warning.

Member

fperez commented Apr 3, 2011

Other than my minor inline notes, the code cleanup itself looks great, thanks!

The one thing I'd like to see added right away is some note in the docs about what's going on, even if it's just a short explanatory paragraph. Because we'll want to build the docs and push a build with this information immediately to the users, so people can start preparing for it (as well as announcing it quite loudly on the lists).

In fact, I'd suggest pinging the -dev and -user lists right away pointing to this pull request and indicating what's going on, so people can start preparing. Because the moment it gets merged, anyone who was running from master with twisted code (and I'm sure there are people like that, for whom it was working with local clusters) are going to be in for a really rough ride...

So I think before actually pulling the trigger on this one, we really need to make an announcement on the lists, so people at least are given a warning.

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Apr 4, 2011

Member

notice sent.

Member

minrk commented Apr 4, 2011

notice sent.

@fperez

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Apr 4, 2011

Member

Awesome, thanks! This is great to have right away...

Member

fperez commented Apr 4, 2011

Awesome, thanks! This is great to have right away...

@ellisonbg

This comment has been minimized.

Show comment
Hide comment
@ellisonbg

ellisonbg Apr 5, 2011

Member

I am +1 on this being merged now.

On Mon, Apr 4, 2011 at 3:35 PM, fperez
reply@reply.github.com
wrote:

Awesome, thanks! This is great to have right away...

Reply to this email directly or view it on GitHub:
#325 (comment)

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

Member

ellisonbg commented Apr 5, 2011

I am +1 on this being merged now.

On Mon, Apr 4, 2011 at 3:35 PM, fperez
reply@reply.github.com
wrote:

Awesome, thanks! This is great to have right away...

Reply to this email directly or view it on GitHub:
#325 (comment)

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

@fperez

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Apr 5, 2011

Member

Did you have a chance to make the fixes I indicated? Also, I think we should have a note in the docs (can be short) ready to go in this pull request, so that when the merge goes in, we can immediately build the docs and have our dev docs properly indicate to people what's going on (even if the full porting doc isn't complete yet). I don't want the docs to start falling badly behind...

Once these two minor things are in, go for it! The tests look good.

thanks!

Member

fperez commented Apr 5, 2011

Did you have a chance to make the fixes I indicated? Also, I think we should have a note in the docs (can be short) ready to go in this pull request, so that when the merge goes in, we can immediately build the docs and have our dev docs properly indicate to people what's going on (even if the full porting doc isn't complete yet). I don't want the docs to start falling badly behind...

Once these two minor things are in, go for it! The tests look good.

thanks!

@mrceresa

This comment has been minimized.

Show comment
Hide comment
@mrceresa

mrceresa Apr 5, 2011

Really looking forward to see this merged! I think all the work in ipython has been amazing so far: thanks a lot!

mrceresa commented Apr 5, 2011

Really looking forward to see this merged! I think all the work in ipython has been amazing so far: thanks a lot!

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Apr 5, 2011

Member

I think my first question got lost behind the versioning discussion: Does this mean I should remove my 'z' suffix everywhere after this is merged?

Member

minrk commented Apr 5, 2011

I think my first question got lost behind the versioning discussion: Does this mean I should remove my 'z' suffix everywhere after this is merged?

@ellisonbg

This comment has been minimized.

Show comment
Hide comment
@ellisonbg

ellisonbg Apr 5, 2011

Member

Yes,

I think so. Although I do like all of the "All yur clusterz are mine"
joke possibilities....

Brian

On Tue, Apr 5, 2011 at 9:26 AM, minrk
reply@reply.github.com
wrote:

I think my first question got lost behind the versioning discussion:  Does this mean I should remove my 'z' suffix everywhere after this is merged?

Reply to this email directly or view it on GitHub:
#325 (comment)

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

Member

ellisonbg commented Apr 5, 2011

Yes,

I think so. Although I do like all of the "All yur clusterz are mine"
joke possibilities....

Brian

On Tue, Apr 5, 2011 at 9:26 AM, minrk
reply@reply.github.com
wrote:

I think my first question got lost behind the versioning discussion:  Does this mean I should remove my 'z' suffix everywhere after this is merged?

Reply to this email directly or view it on GitHub:
#325 (comment)

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

@fperez

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Apr 5, 2011

Member

On Tue, Apr 5, 2011 at 9:31 AM, ellisonbg
reply@reply.github.com
wrote:

Yes,

I think so.  Although I do like all of the "All yur clusterz are mine"
joke possibilities....

I agree too, despite the loss of comedy potential :)

f

Member

fperez commented Apr 5, 2011

On Tue, Apr 5, 2011 at 9:31 AM, ellisonbg
reply@reply.github.com
wrote:

Yes,

I think so.  Although I do like all of the "All yur clusterz are mine"
joke possibilities....

I agree too, despite the loss of comedy potential :)

f

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Apr 5, 2011

Member

I'll do this merge today (with Fernando's notes), unless someone objects.

Member

minrk commented Apr 5, 2011

I'll do this merge today (with Fernando's notes), unless someone objects.

@ellisonbg

This comment has been minimized.

Show comment
Hide comment
@ellisonbg

ellisonbg Apr 5, 2011

Member

I need to fix a few quick things first...

Brian

On Tue, Apr 5, 2011 at 3:40 PM, minrk
reply@reply.github.com
wrote:

I'll do this merge today (with Fernando's notes), unless someone objects.

Reply to this email directly or view it on GitHub:
#325 (comment)

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

Member

ellisonbg commented Apr 5, 2011

I need to fix a few quick things first...

Brian

On Tue, Apr 5, 2011 at 3:40 PM, minrk
reply@reply.github.com
wrote:

I'll do this merge today (with Fernando's notes), unless someone objects.

Reply to this email directly or view it on GitHub:
#325 (comment)

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Apr 5, 2011

Member

Okay, sure. If you want to do the merge that's fine, but I'm happy to do it if you are busy.

(I already removed the kernel scripts, and fixed the dangling check_for_x for zope,twisted,fs, and openssl in my local branch, put IPython.kernel back as a package, etc.)

Member

minrk commented Apr 5, 2011

Okay, sure. If you want to do the merge that's fine, but I'm happy to do it if you are busy.

(I already removed the kernel scripts, and fixed the dangling check_for_x for zope,twisted,fs, and openssl in my local branch, put IPython.kernel back as a package, etc.)

@ellisonbg

This comment has been minimized.

Show comment
Hide comment
@ellisonbg

ellisonbg Apr 6, 2011

Member

OK I just fixed things. This can be merged. Woohoo!

Member

ellisonbg commented Apr 6, 2011

OK I just fixed things. This can be merged. Woohoo!

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Apr 6, 2011

Member

remove IPython.kernel scripts and put migration notice in docs.

closed by 627e381

Member

minrk commented Apr 6, 2011

remove IPython.kernel scripts and put migration notice in docs.

closed by 627e381

@minrk minrk closed this Apr 6, 2011

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Apr 6, 2011

Member

I also pushed a new build of the docs, with a link to the new docs, rather than just a void where the old parallel docs:

http://ipython.github.com/ipython-doc/dev/parallel/index.html

Member

minrk commented Apr 6, 2011

I also pushed a new build of the docs, with a link to the new docs, rather than just a void where the old parallel docs:

http://ipython.github.com/ipython-doc/dev/parallel/index.html

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Apr 6, 2011

Member

newparallel has been rebased onto this, so all temporary 'ip___z' scripts are now back to 'ipengine/ipcontroller/ipcluster'.

Member

minrk commented Apr 6, 2011

newparallel has been rebased onto this, so all temporary 'ip___z' scripts are now back to 'ipengine/ipcontroller/ipcluster'.

@fperez

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Apr 6, 2011

Member

On Wed, Apr 6, 2011 at 2:57 PM, minrk
reply@reply.github.com
wrote:

newparallel has been rebased onto this, so all temporary 'ip___z' scripts are now back to 'ipengine/ipcontroller/ipcluster'.

Awesome, thanks!

Member

fperez commented Apr 6, 2011

On Wed, Apr 6, 2011 at 2:57 PM, minrk
reply@reply.github.com
wrote:

newparallel has been rebased onto this, so all temporary 'ip___z' scripts are now back to 'ipengine/ipcontroller/ipcluster'.

Awesome, thanks!

markvoorhies pushed a commit to markvoorhies/ipython that referenced this pull request Apr 21, 2011

mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this pull request Nov 3, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment