[IPython-dev] glumpy, fast opengl visualization

[Nicolas Rougier]

Hi Fernando,

I will change the license from GPL to BSD.

Concerning the ipython-trunk, I'm not sure where to look exactly within
your sources. Currently, I'm using the IPython.ipapi.launch_new_instance
to start an ipython shell in its own thread (I need this because OpenGL
requires to be in the main thread from what I remember). Furthermore I
proxy all gl calls so they are executed within the main thread while
standard python operations are made directly from the ipython thread.

The only problem so far with this approach is to be able to kill the
IPython session cleanly from the GL thread but I did not find the way to
do it, is there something like this in the dev branch ?


Nicolas


On Mon, 2010-01-25 at 16:11 -0800, Fernando Perez wrote:
> Hi Nicolas,
> 
> On Mon, Jan 25, 2010 at 2:46 AM, Nicolas Rougier
> <Nicolas.Rougier at loria.fr> wrote:
> >
> >
> > Hello,
> >
> > This is an update about glumpy, a fast-OpenGL based numpy visualization.
> > I modified the code such that the only dependencies are PyOpenGL and
> > IPython (for interactive sessions). You will also need matplotlib and
> > scipy for some demos.
> >
> > Sources: hg clone http://glumpy.googlecode.com/hg/ glumpy
> > No installation required, you can run all demos inplace.
> >
> > Homepage: http://code.google.com/p/glumpy/
> 
> This is great, and it would be very cool to have it updated to the new
> code we're now landing in ipython with a much cleaner internal API
> (finally :)  Have you had a chance to look at the code in my trunk-dev
> branch?
> 
> https://code.launchpad.net/~fdo.perez/ipython/trunk-dev
> 
> Brian finished a large review of it and we just had a chance to go
> over his feedback directly, so there's now one more round of reviews
> to do (once he applies the changes from our discussion) and this
> should become trunk very soon.  The apis are much cleaner, this is the
> big cleanup I told you about last year, and now we're getting to the
> point where having multiple ipython frontends is a very realistic
> prospect.
> 
> Unfortunately we won't be able to use your code directly in IPython as
> it stands, since the GPL provisions in it would require us to GPL all
> of IPython to make use of any of it directly in IPython.  Your code
> uses iptyhon, numpy, matplotlib and scipy (in some demos), which
> amounts to hundreds of thousands of lines of code; here are the
> sloccount outputs from their respective trunks:
> 
> IPython
> Totals grouped by language (dominant language first):
> python:       47357 (99.24%)
> lisp:           262 (0.55%)
> sh:              62 (0.13%)
> objc:            37 (0.08%)
> 
> 
> Numpy
> Totals grouped by language (dominant language first):
> ansic:       152950 (67.19%)
> python:       73188 (32.15%)
> cpp:            828 (0.36%)
> fortran:        298 (0.13%)
> sh:             156 (0.07%)
> pascal:         120 (0.05%)
> f90:             97 (0.04%)
> 
> Matplotlib
> Totals grouped by language (dominant language first):
> python:       83290 (52.64%)
> cpp:          68212 (43.11%)
> objc:          4517 (2.85%)
> ansic:         2149 (1.36%)
> sh:              69 (0.04%)
> 
> Scipy
> Totals grouped by language (dominant language first):
> cpp:         220149 (48.35%)
> fortran:      87240 (19.16%)
> python:       79164 (17.38%)
> ansic:        68746 (15.10%)
> sh:              61 (0.01%)
> 
> Glumpy:
> Totals grouped by language (dominant language first):
> python:        3751 (100.00%)
> 
> We're looking at ~300.000 lines of python alone in these tools.  It's
> unfortunately not realistic for us to consider GPL-ing them in order
> to incorporate glumpy into the core set; it would be fantastic if you
> were willing to consider licensing your code under a license that is
> compatible with the body of work you are building on top of.
> 
> You are obviously free to choose your license as you see fit, and end
> users (myself included) will be always able to use glumpy along with
> ipython, numpy, matplotlib and scipy.  So *users* get all of the
> benefit of your contribution, and for that I am the first to be
> delighted and grateful that you've put your code out there.
> 
> But as it stands, your code builds on close to half a million lines of
> other code which can not benefit back from your contributions.  If you
> consider licensing glumpy to be compatible with ipython, numpy and
> matplotlib, it would be possible to incorporate your ideas back into
> those projects: perhaps in some places the right solution would be to
> fix our own designs to better provide what glumpy needs, in other
> cases we may find fixes you've made fit better upstream, etc.
> 
> But this kind of collaboration will not be possible as long as glumpy
> can benefit from our tools but our codes are not allowed to benefit
> from glumpy (without changing licenses, which isn't going to happen).
> 
> I hope you consider this from our perspective and in the most friendly
> and open manner: I completely respect your right to license your own
> code as you see fit (I've seen people put out GPL 'projects' that
> effectively consist of 3 lines that import IPython and make a function
> call, and that's OK too, and allowed by the license I chose to use).
> The only reason I ask you is because I think your tool is very
> interesting, and it would ultimately lead to a much more productive
> relationship with ipython, numpy and matplotlib if it could be a
> collaboration instead of a one-way benefit.
> 
> Best regards,
> 
> Fernando.