Hi Nicolas, On Mon, Jan 25, 2010 at 2:46 AM, Nicolas Rougier <nicolas.roug...@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. ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
