Re-issued: Just enough to start ipython jython support #4226

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
10 participants
@ghjc

ghjc commented Sep 17, 2013

Requires a slightly modified version of jython 2.7b1 (https://bitbucket.org/bbjc/jython - ipython-fixes branch).

JC
Just enough to start ipython jython support
Requires a slightly modified version of jython 2.7b1 (https://bitbucket.org/bbjc/jython - ipython-fixes branch).
IPython/config/__init__.py
@@ -13,6 +13,6 @@
# Imports
#-------------------------------------------------------------------------------
-from .application import *

This comment has been minimized.

Show comment Hide comment
@ghjc

ghjc Sep 17, 2013

These are issues with jython itself. I'll take a look.

@ghjc

ghjc Sep 17, 2013

These are issues with jython itself. I'll take a look.

IPython/core/compilerop.py
@@ -91,6 +91,7 @@ def __init__(self):
# stdlib that call it outside our control go through our codepath
# (otherwise we'd lose our tracebacks).
linecache.checkcache = check_linecache_ipython
+ self.flags = codeop.PyCF_DONT_IMPLY_DEDENT

This comment has been minimized.

Show comment Hide comment
@ghjc

ghjc Sep 17, 2013

I'll look into if there is a more appropriate default.

@ghjc

ghjc Sep 17, 2013

I'll look into if there is a more appropriate default.

@takluyver

This comment has been minimized.

Show comment Hide comment
@takluyver

takluyver Sep 17, 2013

Owner

For the record, this pull request follows on from #4215 .

Owner

takluyver commented Sep 17, 2013

For the record, this pull request follows on from #4215 .

@ellisonbg

This comment has been minimized.

Show comment Hide comment
@ellisonbg

ellisonbg Oct 9, 2013

Owner

@ghjc any progress on this?

Owner

ellisonbg commented Oct 9, 2013

@ghjc any progress on this?

@ghjc

This comment has been minimized.

Show comment Hide comment
@ghjc

ghjc Oct 9, 2013

Thanks for the reminder. I was able to make some changes to Jython itself to keep it from improperly handling relative imports. So I'll revert the changes related to relative imports in this request once I push that out.

I had one other issue to look at related to compiler defaults.

NOTE: iPython would still need to run against my branch of Jython, but I'll issue the pull request there and maybe they'll pick it up. Unfortunately, the changes to Jython involved downgrading jline and issues related to jline were an area of focus for those guys. I suspect there will be some additional effort on that end before this entire subject can be resolved.

Thanks for your patience. I can make some progress this weekend.

ghjc commented Oct 9, 2013

Thanks for the reminder. I was able to make some changes to Jython itself to keep it from improperly handling relative imports. So I'll revert the changes related to relative imports in this request once I push that out.

I had one other issue to look at related to compiler defaults.

NOTE: iPython would still need to run against my branch of Jython, but I'll issue the pull request there and maybe they'll pick it up. Unfortunately, the changes to Jython involved downgrading jline and issues related to jline were an area of focus for those guys. I suspect there will be some additional effort on that end before this entire subject can be resolved.

Thanks for your patience. I can make some progress this weekend.

JC
Backed out changes that compenstated for jython.
Requires custom jython 2.7b1 build:
https://bbjc@bitbucket.org/bbjc/jython
@jimbaker

This comment has been minimized.

Show comment Hide comment
@jimbaker

jimbaker Oct 15, 2013

I'm very excited about this, and plan to work with ghjc to see what we could to ensure that changes in Jython are promptly made. Currently my only concern is we should do this in the context of a planned upgrade to JLine2 as Jython's standard console.

Looking at the commits, let me suggest that any dispatching on running on Jython should use the platform module; specifically platform.python_implementation(), which is "Jython".

I am also interested in the possibility of fixing the os.name bug in Jython so that it actually reports the correct OS, instead of having to use the nonstandard os._name. In looking at the code here, I don't know what os._name would report for windows, vs getProperty('os.name') from java.lang.System, but it should be whatever cpython would report. Apparently someone did this research: http://stackoverflow.com/a/2336254

I'm very excited about this, and plan to work with ghjc to see what we could to ensure that changes in Jython are promptly made. Currently my only concern is we should do this in the context of a planned upgrade to JLine2 as Jython's standard console.

Looking at the commits, let me suggest that any dispatching on running on Jython should use the platform module; specifically platform.python_implementation(), which is "Jython".

I am also interested in the possibility of fixing the os.name bug in Jython so that it actually reports the correct OS, instead of having to use the nonstandard os._name. In looking at the code here, I don't know what os._name would report for windows, vs getProperty('os.name') from java.lang.System, but it should be whatever cpython would report. Apparently someone did this research: http://stackoverflow.com/a/2336254

@ghjc

This comment has been minimized.

Show comment Hide comment
@ghjc

ghjc Oct 16, 2013

Thanks again Jim.

If os.name reported the host os name as opposed to 'java', many of my changes would go away which is a good thing. Any remaining differences could be handled as you suggest.

That said, os.name reporting 'java' does in some ways also make sense for jython.

ghjc commented Oct 16, 2013

Thanks again Jim.

If os.name reported the host os name as opposed to 'java', many of my changes would go away which is a good thing. Any remaining differences could be handled as you suggest.

That said, os.name reporting 'java' does in some ways also make sense for jython.

@damianavila

This comment has been minimized.

Show comment Hide comment
@damianavila

damianavila Nov 25, 2013

Contributor

@ghjc do you have plans to push this PR forward? thanks...

Contributor

damianavila commented Nov 25, 2013

@ghjc do you have plans to push this PR forward? thanks...

@ghjc

This comment has been minimized.

Show comment Hide comment
@ghjc

ghjc Nov 26, 2013

Thanks for reaching out. I am planning to continue. This PR is related to some changes that would need to be made to jython itself. Next chance I get, I'll take a look at jython and see if any progress has been made there.

ghjc commented Nov 26, 2013

Thanks for reaching out. I am planning to continue. This PR is related to some changes that would need to be made to jython itself. Next chance I get, I'll take a look at jython and see if any progress has been made there.

@erny

This comment has been minimized.

Show comment Hide comment
@erny

erny Dec 4, 2013

Hi. Thanks for your great work. I just tried to:

java -jar jython-standalone.jar
>>> import sys
>>> sys.path.insert(0, '/usr/local/lib/python2.7/dist-packages/ipython-2.0.0_dev-py2.7.egg')
>>> import IPython
>>> IPython.start_ipython()
Traceback (most recent call last):
...
  File "/usr/local/lib/python2.7/dist-packages/ipython-2.0.0_dev-py2.7.egg/IPython/config/application.py", line 195, in _log_default
    if sys.executable.endswith('pythonw.exe'):
AttributeError: 'NoneType' object has no attribute 'endswith'

So sys.executable is None in jython.
Hmmm, shouldn't it be something like 'jython' or 'jython-standalone.jar' or 'java' ?

I could report it also on ghjc's Jython fork on bitbucket.

Thanks again for the great work.

erny commented Dec 4, 2013

Hi. Thanks for your great work. I just tried to:

java -jar jython-standalone.jar
>>> import sys
>>> sys.path.insert(0, '/usr/local/lib/python2.7/dist-packages/ipython-2.0.0_dev-py2.7.egg')
>>> import IPython
>>> IPython.start_ipython()
Traceback (most recent call last):
...
  File "/usr/local/lib/python2.7/dist-packages/ipython-2.0.0_dev-py2.7.egg/IPython/config/application.py", line 195, in _log_default
    if sys.executable.endswith('pythonw.exe'):
AttributeError: 'NoneType' object has no attribute 'endswith'

So sys.executable is None in jython.
Hmmm, shouldn't it be something like 'jython' or 'jython-standalone.jar' or 'java' ?

I could report it also on ghjc's Jython fork on bitbucket.

Thanks again for the great work.

@ghjc

This comment has been minimized.

Show comment Hide comment
@ghjc

ghjc Dec 4, 2013

Thanks for the kind words.

I think this is an issue with jython-standalone

I tried:

jython
>>>import sys
>>>sys.executable
/path-to-jython/bin/jython
>>>

Then I tried:

java -jar ../jython-standalone.jar
>>>import sys
>>>sys.executable
>>>

It is tempting to try this as a workaround:

java -jar ./jython-standalone.jar
>>>import sys
>>>import IPython #my set up is a little different
>>>sys.executable='/path-to-jython/jython-standalone.jar'
>>>IPython.start_ipython()

IPython 'starts' on my system, but without colors or proper input handling. So clearly something is going wrong here when using jython-standalone.

Thank you. I didn't know to try to run it this way. I'll take a look the next chance I get. It is probably more of a jython issue.

ghjc commented Dec 4, 2013

Thanks for the kind words.

I think this is an issue with jython-standalone

I tried:

jython
>>>import sys
>>>sys.executable
/path-to-jython/bin/jython
>>>

Then I tried:

java -jar ../jython-standalone.jar
>>>import sys
>>>sys.executable
>>>

It is tempting to try this as a workaround:

java -jar ./jython-standalone.jar
>>>import sys
>>>import IPython #my set up is a little different
>>>sys.executable='/path-to-jython/jython-standalone.jar'
>>>IPython.start_ipython()

IPython 'starts' on my system, but without colors or proper input handling. So clearly something is going wrong here when using jython-standalone.

Thank you. I didn't know to try to run it this way. I'll take a look the next chance I get. It is probably more of a jython issue.

@damianavila

This comment has been minimized.

Show comment Hide comment
@damianavila

damianavila Dec 18, 2013

Contributor

This PR is related to some changes that would need to be made to jython itself.
Proposal: Close and wait for re-open when jython work is done? Thoughts?

Contributor

damianavila commented Dec 18, 2013

This PR is related to some changes that would need to be made to jython itself.
Proposal: Close and wait for re-open when jython work is done? Thoughts?

@Carreau

This comment has been minimized.

Show comment Hide comment
@Carreau

Carreau Dec 18, 2013

Owner

If we know that the change will be made to Jython, and we know the fix that have to be made here, I would be in favor of integrating them so that IPython 2.0 will be compatible if Jython is updated between 2.0 and 3.0.

Owner

Carreau commented Dec 18, 2013

If we know that the change will be made to Jython, and we know the fix that have to be made here, I would be in favor of integrating them so that IPython 2.0 will be compatible if Jython is updated between 2.0 and 3.0.

@ghjc

This comment has been minimized.

Show comment Hide comment
@ghjc

ghjc Dec 18, 2013

I don't have any insight to whether or not the necessary changes to jython will happen, although I'd like to help with that as well. That said, pushing these changes into ipython increases the likelyhood the there will be a version of jython that supports enough of a running ipython that the work can be completed. IPython on jython will likely be generally helpful to the jython community.

Something like this is challenging because it really spans two projects. This would seem to begin to break the dependency.

ghjc commented Dec 18, 2013

I don't have any insight to whether or not the necessary changes to jython will happen, although I'd like to help with that as well. That said, pushing these changes into ipython increases the likelyhood the there will be a version of jython that supports enough of a running ipython that the work can be completed. IPython on jython will likely be generally helpful to the jython community.

Something like this is challenging because it really spans two projects. This would seem to begin to break the dependency.

+ if 'Windows' in java_host_os:
+ aliases = nt_aliases
+ else:
+ default_pager_cmd = 'type'

This comment has been minimized.

Show comment Hide comment
@takluyver

takluyver Dec 18, 2013

Owner

Outside Java, this is 'type' if the platform is Windows, but you seemingly set it to 'type' if the platform is not Windows, and don't set it at all for other platforms. Is this correct?

@takluyver

takluyver Dec 18, 2013

Owner

Outside Java, this is 'type' if the platform is Windows, but you seemingly set it to 'type' if the platform is not Windows, and don't set it at all for other platforms. Is this correct?

- raise ImportError (str(e) + """
+ if os.name == 'java':
+ #Temporariy ignore the lack of some key imports
+ pass

This comment has been minimized.

Show comment Hide comment
@takluyver

takluyver Dec 18, 2013

Owner

This change would need to be removed before we merge - if some of these imports fail, parts of pexpect won't work, so the module as a whole should simply fail to load.

@takluyver

takluyver Dec 18, 2013

Owner

This change would need to be removed before we merge - if some of these imports fail, parts of pexpect won't work, so the module as a whole should simply fail to load.

- self.PYFUNC = ctypes.PYFUNCTYPE(ctypes.c_int)
+ if os.name == 'java':
+ #temporarily ignore this
+ self.PYFUNC = None

This comment has been minimized.

Show comment Hide comment
@takluyver

takluyver Dec 18, 2013

Owner

Not convinced about this. This allows InputHookManager to be created, but it's not actually functional. I thought part of the advantage of ctypes was that it could work on different Python implementations? But if it can't, I think input hooks should be disabled, rather than just broken.

@takluyver

takluyver Dec 18, 2013

Owner

Not convinced about this. This allows InputHookManager to be created, but it's not actually functional. I thought part of the advantage of ctypes was that it could work on different Python implementations? But if it can't, I think input hooks should be disabled, rather than just broken.

+ if os.name == 'java':
+ from java.lang import System
+ java_os = System.getProperty('os.name')
+ if 'Windows' in java_os:

This comment has been minimized.

Show comment Hide comment
@takluyver

takluyver Dec 18, 2013

Owner

This seems like a common pattern - is it worth abstracting it out? Or can we use sys.platform instead - we use that interchangeably with os.name, so if that actually tells us about the underlying platform on Jython, maybe we should be using sys.platform more.

(Aside: why is os.name set to 'java'? Surely os.name ought to be the name of the OS?)

@takluyver

takluyver Dec 18, 2013

Owner

This seems like a common pattern - is it worth abstracting it out? Or can we use sys.platform instead - we use that interchangeably with os.name, so if that actually tells us about the underlying platform on Jython, maybe we should be using sys.platform more.

(Aside: why is os.name set to 'java'? Surely os.name ought to be the name of the OS?)

@takluyver

This comment has been minimized.

Show comment Hide comment
@takluyver

takluyver Dec 18, 2013

Owner

If the changes are fairly simple, I'm happy to land them. I've got a few suggestions on how it might be cleaner, though.

Owner

takluyver commented Dec 18, 2013

If the changes are fairly simple, I'm happy to land them. I've got a few suggestions on how it might be cleaner, though.

@ghjc

This comment has been minimized.

Show comment Hide comment
@ghjc

ghjc Dec 18, 2013

All great feedback. I'll take a look and see if I can clean up the changes.

ghjc commented Dec 18, 2013

All great feedback. I'll take a look and see if I can clean up the changes.

@damianavila

This comment has been minimized.

Show comment Hide comment
@damianavila

damianavila Dec 18, 2013

Contributor

Thanks to all to answer, I just wanted to avoid that the PR got stuck for the delay in jython 😉

Contributor

damianavila commented Dec 18, 2013

Thanks to all to answer, I just wanted to avoid that the PR got stuck for the delay in jython 😉

@takluyver

This comment has been minimized.

Show comment Hide comment
@takluyver

takluyver Jan 13, 2014

Owner

@ghjc : ping! Do you think you'll get a chance to do those bits of cleanup?

Owner

takluyver commented Jan 13, 2014

@ghjc : ping! Do you think you'll get a chance to do those bits of cleanup?

@ghjc

This comment has been minimized.

Show comment Hide comment
@ghjc

ghjc Jan 13, 2014

@takluyver Thanks for the ping. Sorry for the delay. The issues of what to do with pexpect and disabling InputHookManager will require a little more research on thought on my part.

In terms of the bigger picture, what would an optimal time be for me to finish this up?

ghjc commented Jan 13, 2014

@takluyver Thanks for the ping. Sorry for the delay. The issues of what to do with pexpect and disabling InputHookManager will require a little more research on thought on my part.

In terms of the bigger picture, what would an optimal time be for me to finish this up?

@takluyver

This comment has been minimized.

Show comment Hide comment
@takluyver

takluyver Jan 13, 2014

Owner

Whenever you like - we're going to start to stabilise things for a release in a few weeks, but if it misses this release, it can go in for the next one. Feel free to ask if you want to talk through any problems/solutions.

Owner

takluyver commented Jan 13, 2014

Whenever you like - we're going to start to stabilise things for a release in a few weeks, but if it misses this release, it can go in for the next one. Feel free to ask if you want to talk through any problems/solutions.

@takluyver

This comment has been minimized.

Show comment Hide comment
@takluyver

takluyver Jan 13, 2014

Owner

Oh, and so you're aware, you'll need to rebase this branch, because it appears to have a merge conflict.

Owner

takluyver commented Jan 13, 2014

Oh, and so you're aware, you'll need to rebase this branch, because it appears to have a merge conflict.

@ghjc

This comment has been minimized.

Show comment Hide comment
@ghjc

ghjc Jan 14, 2014

Thanks. I might be able to manage that. Thanks also for the heads up on the rebase. When I have a minute, I'll take a closer look and see if I have any questions.

ghjc commented Jan 14, 2014

Thanks. I might be able to manage that. Thanks also for the heads up on the rebase. When I have a minute, I'll take a closer look and see if I have any questions.

@ellisonbg

This comment has been minimized.

Show comment Hide comment
@ellisonbg

ellisonbg Feb 5, 2014

Owner

@ghjc any progress on this? Release is approaching.

Owner

ellisonbg commented Feb 5, 2014

@ghjc any progress on this? Release is approaching.

@ghjc

This comment has been minimized.

Show comment Hide comment
@ghjc

ghjc Feb 5, 2014

No progress yet. I'm not likely to make much progress in the next week or so either. I do still think this is important and will revisit the topic soon.

ghjc commented Feb 5, 2014

No progress yet. I'm not likely to make much progress in the next week or so either. I do still think this is important and will revisit the topic soon.

@dsblank

This comment has been minimized.

Show comment Hide comment
@dsblank

dsblank Feb 22, 2014

Contributor

Hi! Just thought I'd post a note here letting you know that I am working on similar goals (allowing IPython to be useful with other Python implementations). #5055 makes minimal changes to import IPython from IronPython. BTW, IronPython uses the following:

import os, sys
os.name, sys.platform
('posix', 'cli')

when running on Linux or Mac, and os.name == 'nt' (I believe) when under any Windows. It would be good if we could get Jython and IronPython to have a consistent method of identification.

Contributor

dsblank commented Feb 22, 2014

Hi! Just thought I'd post a note here letting you know that I am working on similar goals (allowing IPython to be useful with other Python implementations). #5055 makes minimal changes to import IPython from IronPython. BTW, IronPython uses the following:

import os, sys
os.name, sys.platform
('posix', 'cli')

when running on Linux or Mac, and os.name == 'nt' (I believe) when under any Windows. It would be good if we could get Jython and IronPython to have a consistent method of identification.

@jdfreder

This comment has been minimized.

Show comment Hide comment
@jdfreder

jdfreder Mar 12, 2014

Owner

Since the 2.0 beta was released, I'm going to set the target of this to 3.0.

Owner

jdfreder commented Mar 12, 2014

Since the 2.0 beta was released, I'm going to set the target of this to 3.0.

@jdfreder jdfreder added this to the 3.0 milestone Mar 12, 2014

@jimbaker

This comment has been minimized.

Show comment Hide comment
@jimbaker

jimbaker Apr 3, 2014

@dsblank Jython has been using os.name/os._name for a while - it's going to be really hard for us to change without breaking existing code. I say this despite advocating for this very change :)

@takluyver I'm going to look into removing ctypes. It really never should be put into Jython because it was not complete/does not really work, and I don't expect we will see it being finished. We are moving to cffi and C extension API support instead, although slowly.

@ghjc Jython standalone has some issues. I plan to look at this after beta 3. I'm currently looking at relative imports support, which is seen in this bug: http://bugs.jython.org/issue1973 and is causing other issues in important packages, specifically in pypa.

jimbaker commented Apr 3, 2014

@dsblank Jython has been using os.name/os._name for a while - it's going to be really hard for us to change without breaking existing code. I say this despite advocating for this very change :)

@takluyver I'm going to look into removing ctypes. It really never should be put into Jython because it was not complete/does not really work, and I don't expect we will see it being finished. We are moving to cffi and C extension API support instead, although slowly.

@ghjc Jython standalone has some issues. I plan to look at this after beta 3. I'm currently looking at relative imports support, which is seen in this bug: http://bugs.jython.org/issue1973 and is causing other issues in important packages, specifically in pypa.

@ghjc

This comment has been minimized.

Show comment Hide comment
@ghjc

ghjc Apr 4, 2014

@jimbaker Great to hear from you. This version of jython: https://bitbucket.org/bbjc/jython seems to fix relative imports (at least in this case). Removing ctypes will help get this working also. I'm not sure I follow what you are thinking with os._name.

The big issue identified by @takluyver was what to do with pexpect. I agree that letting it load in a half broken state is not a good thing. IPython needs the parts of it that do work. So maybe something jython environment enabled that provides the required functionality will need to be devised. I never had a chance to come up with a good answer for that.

Probably the next big thing after that to get working is command history. That requires SQLite. I have some ideas, but maybe JyNI could be used. Also on the todo list is cleaning up how IPython locates some the files it uses. I'm seeing a _ipython directory in my home directory which should probably be ._ipython or something.

There is a fair amount to be done. I'd like to coordinate efforts and contribute as best as I can.

ghjc commented Apr 4, 2014

@jimbaker Great to hear from you. This version of jython: https://bitbucket.org/bbjc/jython seems to fix relative imports (at least in this case). Removing ctypes will help get this working also. I'm not sure I follow what you are thinking with os._name.

The big issue identified by @takluyver was what to do with pexpect. I agree that letting it load in a half broken state is not a good thing. IPython needs the parts of it that do work. So maybe something jython environment enabled that provides the required functionality will need to be devised. I never had a chance to come up with a good answer for that.

Probably the next big thing after that to get working is command history. That requires SQLite. I have some ideas, but maybe JyNI could be used. Also on the todo list is cleaning up how IPython locates some the files it uses. I'm seeing a _ipython directory in my home directory which should probably be ._ipython or something.

There is a fair amount to be done. I'd like to coordinate efforts and contribute as best as I can.

@jimbaker

This comment has been minimized.

Show comment Hide comment
@jimbaker

jimbaker May 2, 2014

@ghjc Relative star imports are in Jython trunk; a substantial portion of what will be added in beta 3 (shortly) is in https://bitbucket.org/jimbaker/jython-socket-reboot

Re pexpect, I looked at https://github.com/pexpect/pexpect/blob/master/pexpect/__init__.py; there are four problematic imports:

  • pty
  • tty
  • termios
  • fcntl

It looks like https://github.com/jawi/JPty and its dependency https://github.com/nyholku/purejavacomm may allow Jython to support pty and termio; it's not clear to me how JPty manages file descriptors, although in principle they are accessible through JFFI/JNI.

So more stuff to look into!

jimbaker commented May 2, 2014

@ghjc Relative star imports are in Jython trunk; a substantial portion of what will be added in beta 3 (shortly) is in https://bitbucket.org/jimbaker/jython-socket-reboot

Re pexpect, I looked at https://github.com/pexpect/pexpect/blob/master/pexpect/__init__.py; there are four problematic imports:

  • pty
  • tty
  • termios
  • fcntl

It looks like https://github.com/jawi/JPty and its dependency https://github.com/nyholku/purejavacomm may allow Jython to support pty and termio; it's not clear to me how JPty manages file descriptors, although in principle they are accessible through JFFI/JNI.

So more stuff to look into!

@takluyver

This comment has been minimized.

Show comment Hide comment
@takluyver

takluyver May 7, 2014

Owner

Jython 2.7 reached beta 2, which might make this a bit more practical.

Owner

takluyver commented May 7, 2014

Jython 2.7 reached beta 2, which might make this a bit more practical.

@jimbaker

This comment has been minimized.

Show comment Hide comment
@jimbaker

jimbaker May 22, 2014

Beta 3 was recently released. With this, we really need to figure out any dependencies that should be part of 2.7 beta 4 that IPython would require.

Beta 3 was recently released. With this, we really need to figure out any dependencies that should be part of 2.7 beta 4 that IPython would require.

@Carreau

This comment has been minimized.

Show comment Hide comment
@Carreau

Carreau Jul 21, 2014

Owner

FYI, This seem to conflict and need a rebase. what is the status of jython now ?

Owner

Carreau commented Jul 21, 2014

FYI, This seem to conflict and need a rebase. what is the status of jython now ?

@takluyver takluyver referenced this pull request Jul 26, 2014

Open

Jython support #6213

@takluyver

This comment has been minimized.

Show comment Hide comment
@takluyver

takluyver Jul 26, 2014

Owner

Closing for inactivity - we'll keep tracking this as issue #6213 until someone wants to work on it again.

Owner

takluyver commented Jul 26, 2014

Closing for inactivity - we'll keep tracking this as issue #6213 until someone wants to work on it again.

@takluyver takluyver closed this Jul 26, 2014

@minrk minrk modified the milestones: 3.0, no action Feb 14, 2015

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