Python (Enthought Edition) for Windows test release
Hi all, The much anticipated new release of the Enthought Edition of Python (a.k.a. Enthon) is just about ready for release into the real world. I'd like for some of you brave developer-type folks to give it a go before I announce it more widely and link it from the Enthon home page. Some highlights of the latest version: - iPython 0.6.7_rc2 is the default shell - The Enthought Open Source Python tools have been added. This includes a few things that migrated out of the SciPy CVS repository and into the Enthought SVN repository about a year ago, or thereabouts. Specifically, new versions of traits, chaco, kiva, etc. It's all really cool, but documentation is not yet available that I know of. If it doesn't work for you, ask Dave lots of questions. Tell him I said it would be OK. (I'm joking. Don't ask Dave anything. Documentation exists, somewhere, and I'll chase someone around the office until it is made available on the website.) - matplotlib - Pyrex - Elmer - Most packages have been updated to their latest revision, with exceptions for compatibility - readline (from UNC Tools, to be specific) - Additional documentation and some reorganization of the menus to make it less confusing and more functional - An extra 20 megabytes of random-seeming stuff...Woohoo! It's not over 100MB, yet, but I reckon one more revision will do it. What isn't in this latest version: - Python 2.4 There will be an all-singing, all-dancing, all-new, from-scratch Enthon built from the new MSI-based Python 2.4 installer, but it's a pretty big job, so I wanted to get a final 2.3 release out into the world before I hunker down and figure out the new msi installer. That said, I'm downright ecstatic to be giving Wise the boot. If I never see that line editor again in this lifetime, it will be too soon. In the meantime, if you all can grab this latest test release and let me know how it works for you, I'd be very grateful. Do whatever it is that you currently do with build 1057 of Enthon (the last public release), and if it doesn't work right in build 1062, let me know--send the error output and a test case so I can reproduce it and know it is fixed. If there's other stuff you'd like to be able to do, but Enthon never quite worked right, I won't mind hearing about that either. So, without further ado, here's the link: http://download.enthought.com/enthought_python-2.3.3-1062.exe Thanks!
Hey Joe, Quoting Joe Cooper <joe@enthought.com>:
Hi all,
The much anticipated new release of the Enthought Edition of Python (a.k.a. Enthon) is just about ready for release into the real world. I'd like for some of you brave developer-type folks to give it a go before I announce it more widely and link it from the Enthon home page.
Some highlights of the latest version:
- iPython 0.6.7_rc2 is the default shell
Many thanks for this, I really appreciate it. However, I have bad news: just today I committed a fix into CVS for a really nasty crash which can be triggered by a simple 'foo?', when foo is an instance without an __init__ method. Unfortunately since '?' is one of ipython's most frequently used features, this is really likely to bite a lot of users. I wish I'd caught this before, but for the last couple of weeks I've been mired in other things and hadn't been using ipython much myself. I just got a crash report a couple of days ago from a user. I hate to report this to you right at the 11th hour, esp. considering that you gave me ample time to triple check everything. But that's just how it goes, I honestly just checked the fix into CVS today. If it's at all possible to you to update ipython, I've put up an rc3 set of files here: http://ipython.scipy.org/dist/testing/ There's .zip, .tar.gz and an rpm built on Fedora3 (py23). It would be really nice if you could use this updated source instead of rc2, but I'll obviously understand (and take full blame) if you can't this late in the game. Best regards, f
Fernando.Perez@colorado.edu wrote:
Hey Joe,
Quoting Joe Cooper <joe@enthought.com>:
Hi all,
The much anticipated new release of the Enthought Edition of Python (a.k.a. Enthon) is just about ready for release into the real world. I'd like for some of you brave developer-type folks to give it a go before I announce it more widely and link it from the Enthon home page.
Some highlights of the latest version:
- iPython 0.6.7_rc2 is the default shell
Many thanks for this, I really appreciate it. However, I have bad news: just today I committed a fix into CVS for a really nasty crash which can be triggered by a simple 'foo?', when foo is an instance without an __init__ method. Unfortunately since '?' is one of ipython's most frequently used features, this is really likely to bite a lot of users.
I wish I'd caught this before, but for the last couple of weeks I've been mired in other things and hadn't been using ipython much myself. I just got a crash report a couple of days ago from a user.
I hate to report this to you right at the 11th hour, esp. considering that you gave me ample time to triple check everything. But that's just how it goes, I honestly just checked the fix into CVS today.
If it's at all possible to you to update ipython, I've put up an rc3 set of files here:
http://ipython.scipy.org/dist/testing/
There's .zip, .tar.gz and an rpm built on Fedora3 (py23). It would be really nice if you could use this updated source instead of rc2, but I'll obviously understand (and take full blame) if you can't this late in the game.
It's not too late. This is the kind of thing I want fixed before the real release happens. I've updated iPython now, I'll start a new release building before I get out of here for the day.
Joe Cooper wrote:
If it's at all possible to you to update ipython, I've put up an rc3 set of files here:
http://ipython.scipy.org/dist/testing/
There's .zip, .tar.gz and an rpm built on Fedora3 (py23). It would be really nice if you could use this updated source instead of rc2, but I'll obviously understand (and take full blame) if you can't this late in the game.
It's not too late. This is the kind of thing I want fixed before the real release happens. I've updated iPython now, I'll start a new release building before I get out of here for the day.
Great! Much appreciated, thanks. Cheers, f
Hi Joe, that's fantastic - many thanks!!! I am only wondering whether the latest changes (scipy CVS, 5 days ago) concerning scipy.xplt (thanks Travis!) made it into the enthought edition? (there were a couple of bugs, some of them specifically for Windows...). I don't have Windows, so I can't check this myself, but I will ask one of my co-workers to go through our list of points. BTW: would it be possible to make a scipy CVS snapshot of the version which enters into the enthought edition? This would allow for some consistency across platforms (I am thinking of packages for debian and others). Thanks for all the work, best wishes, Arnd
On Wed, 2005-01-19 at 09:28 +0100, Arnd Baecker wrote:
Hi Joe,
that's fantastic - many thanks!!!
I am only wondering whether the latest changes (scipy CVS, 5 days ago) concerning scipy.xplt (thanks Travis!) made it into the enthought edition? (there were a couple of bugs, some of them specifically for Windows...). I don't have Windows, so I can't check this myself, but I will ask one of my co-workers to go through our list of points.
SciPy is the latest released version (0.3.2), which is actually quite old at this point. I prefer to stick to released versions when it works. But if there are problems that effect folks, I will roll forward to CVS. I have a build recipe for both, and have done some interim releases over the past year that were CVS versions.
BTW: would it be possible to make a scipy CVS snapshot of the version which enters into the enthought edition? This would allow for some consistency across platforms (I am thinking of packages for debian and others).
Since I'm currently on a release version, there is already a snapshot on the website (this consistency is the reason I like to use releases rather than CVS--when there are dozens of packages included, it becomes really difficult to maintain sanity with bug reports, upstream fixes, etc.). I'll need to track down who is handling the SciPy releases these days and see what the likelihood of a new release is.
On Wed, 19 Jan 2005, Joe Cooper wrote:
On Wed, 2005-01-19 at 09:28 +0100, Arnd Baecker wrote:
Hi Joe,
that's fantastic - many thanks!!!
I am only wondering whether the latest changes (scipy CVS, 5 days ago) concerning scipy.xplt (thanks Travis!) made it into the enthought edition? (there were a couple of bugs, some of them specifically for Windows...). I don't have Windows, so I can't check this myself, but I will ask one of my co-workers to go through our list of points.
SciPy is the latest released version (0.3.2), which is actually quite old at this point. I prefer to stick to released versions when it works. But if there are problems that effect folks, I will roll forward to CVS. I have a build recipe for both, and have done some interim releases over the past year that were CVS versions.
If there is any chance at all, I have a "+n" with pretty large n to go for the CVS (or equivalently for a new snapshot).
BTW: would it be possible to make a scipy CVS snapshot of the version which enters into the enthought edition? This would allow for some consistency across platforms (I am thinking of packages for debian and others).
Since I'm currently on a release version, there is already a snapshot on the website (this consistency is the reason I like to use releases rather than CVS--when there are dozens of packages included, it becomes really difficult to maintain sanity with bug reports, upstream fixes, etc.).
I'll need to track down who is handling the SciPy releases these days and see what the likelihood of a new release is.
Thanks for your effort - I really hope that a new release can be used (in particular because the enthought editions are not that frequent, which is very understandable with all the work involved!). Best wishes, Arnd
On Wed, 19 Jan 2005, Joe Cooper wrote:
I'll need to track down who is handling the SciPy releases these days and see what the likelihood of a new release is.
I guess one person would be me:). I think we have agreed to release Scipy on a half-yearly basis, at least. 0.3.2 was released on October 2004, so formally the next release should be around April 2005. But I am not saying that we could not make the next release earlier than that. I think the current SciPy in CVS has the same functionality as in 0.3.2 plus many bug fixes and new features and so would be appropiate replacing 0.3.2 in Enthought Edition if all tests pass ok. However, there are too many unfinished tasks in SciPy CVS (e.g. creating Lib/lib, numarray support, doc updates, etc.) that I would not recommend making a new Scipy release in early future. Pearu
Pearu Peterson wrote:
On Wed, 19 Jan 2005, Joe Cooper wrote:
I'll need to track down who is handling the SciPy releases these days and see what the likelihood of a new release is.
I guess one person would be me:).
I think we have agreed to release Scipy on a half-yearly basis, at least. 0.3.2 was released on October 2004, so formally the next release should be around April 2005. But I am not saying that we could not make the next release earlier than that.
I think the current SciPy in CVS has the same functionality as in 0.3.2 plus many bug fixes and new features and so would be appropiate replacing 0.3.2 in Enthought Edition if all tests pass ok.
However, there are too many unfinished tasks in SciPy CVS (e.g. creating Lib/lib, numarray support, doc updates, etc.) that I would not recommend making a new Scipy release in early future.
Pearu
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
AFAIK, there is still a mysterious segmentation fault in scipy.test() ? How about that ? Is ATLAS recommended or shall we use export BLAS_SRC=~/src/blas export LAPACK_SRC=~/src/lapack mkdir $BLAS_SRC cd $BLAS_SRC wget http://www.netlib.org/blas/blas.tgz tar xzf blas.tgz cd $LAPACK_SRC/.. wget http://www.netlib.org/lapack/lapack.tgz tar xzf lapack.tgz export BLAS=None export LAPACK=None export ATLAS=None Nils
On Wed, 19 Jan 2005, Nils Wagner wrote:
AFAIK, there is still a mysterious segmentation fault in scipy.test() ? How about that ?
These segfaults would be present also in 0.3.2 if the new features in CVS would be added to 0.3.2. As far as I understand, these segfaults are due to gcc bugs and to avoid segfaults with bugy gcc, one should either rebuild lapack libraries with -O2, or we can disable these new features in scipy. The former may be a pain for most users but the latter does not make much sense to me. Just for the records, I cannot reproduce the segfaults in my debian sid box, and probably because debian sid provides rather uptodate software, including gcc 3.4.4 that I am using for building scipy. And, obviously, if I cannot reproduce a failure, there's little I can to do to find a workaround for it.
Is ATLAS recommended or shall we use
export BLAS_SRC=~/src/blas export LAPACK_SRC=~/src/lapack mkdir $BLAS_SRC cd $BLAS_SRC wget http://www.netlib.org/blas/blas.tgz tar xzf blas.tgz
cd $LAPACK_SRC/.. wget http://www.netlib.org/lapack/lapack.tgz tar xzf lapack.tgz
export BLAS=None export LAPACK=None export ATLAS=None
If that works for you then building lapack with -O2 and completing ATLAS lapack with it should fix the segfault. Pearu
On Wed, 19 Jan 2005, Pearu Peterson wrote:
On Wed, 19 Jan 2005, Joe Cooper wrote:
I'll need to track down who is handling the SciPy releases these days and see what the likelihood of a new release is.
I guess one person would be me:).
I think we have agreed to release Scipy on a half-yearly basis, at least. 0.3.2 was released on October 2004, so formally the next release should be around April 2005. But I am not saying that we could not make the next release earlier than that.
I think the current SciPy in CVS has the same functionality as in 0.3.2 plus many bug fixes and new features and so would be appropiate replacing 0.3.2 in Enthought Edition if all tests pass ok.
In view of this, I think it would be good if the upcoming enthought edition could benefit from all the bug fixes! (Jow, if you would need any additional testers then, just let us know.)
However, there are too many unfinished tasks in SciPy CVS (e.g. creating Lib/lib, numarray support, doc updates, etc.) that I would not recommend making a new Scipy release in early future.
Would it be possible/reasonable to make a 0.3.3. bugfix snapshot (without calling this a "release", because of the unfinished tasks) - well maybe this is just semantics ;-). Or maybe an internal-only 0.3.3 tag would make Joe more happy concerning his consistency argument? Best, Arnd
On Wed, 2005-01-19 at 04:02 -0600, Pearu Peterson wrote:
On Wed, 19 Jan 2005, Joe Cooper wrote:
I'll need to track down who is handling the SciPy releases these days and see what the likelihood of a new release is.
I guess one person would be me:).
I think we have agreed to release Scipy on a half-yearly basis, at least. 0.3.2 was released on October 2004, so formally the next release should be around April 2005. But I am not saying that we could not make the next release earlier than that.
In that case, I suspect it will coincide nicely with the Enthon 2.4 release, and I'll just track SciPy for Enthon releases from that point forward, releasing every six months. SciPy is the heart and soul of Enthon, and given that I'd like to /only/ have released software in Enthon, it seems like SciPy releases are what I need to track.
I think the current SciPy in CVS has the same functionality as in 0.3.2 plus many bug fixes and new features and so would be appropiate replacing 0.3.2 in Enthought Edition if all tests pass ok.
So it would be a appropriate to use a CVS version in a new Enthon release, but not in a new tarball release version of SciPy? Even thought it has many bug fixes and new features and does not break old code?
However, there are too many unfinished tasks in SciPy CVS (e.g. creating Lib/lib, numarray support, doc updates, etc.) that I would not recommend making a new Scipy release in early future.
I think you just set too high a standard for "releases". ;-) That said, SciPy is your boat to bail and Enthon is mine. I'll run SciPy from CVS, if that's the best possible SciPy for Enthon users.
On Wed, 19 Jan 2005, Joe Cooper wrote:
However, there are too many unfinished tasks in SciPy CVS (e.g. creating Lib/lib, numarray support, doc updates, etc.) that I would not recommend making a new Scipy release in early future.
I think you just set too high a standard for "releases". ;-)
Making a Scipy release is still a few full days job (building/testing/fixing bugs/rebuilding/testing/... for different platforms), and with the given state, I would reserve a week for it (atlas libraries may need a rebuild), and at the moment I don't have resources to do that. Pearu
Joe, I'll try this on my home machine in the next couple of days. Last weekend I installed the 1057 enthon install and our proava svn converge branch. While basic python was fine, anything that used swig failed to build. Something about unable to find a definition for PyCObject or something like that. I didn't trace down the problem. I'll let you know how it goes.... Joe Cooper wrote:
Hi all,
The much anticipated new release of the Enthought Edition of Python (a.k.a. Enthon) is just about ready for release into the real world. I'd like for some of you brave developer-type folks to give it a go before I announce it more widely and link it from the Enthon home page.
Some highlights of the latest version:
- iPython 0.6.7_rc2 is the default shell
- The Enthought Open Source Python tools have been added. This includes a few things that migrated out of the SciPy CVS repository and into the Enthought SVN repository about a year ago, or thereabouts. Specifically, new versions of traits, chaco, kiva, etc. It's all really cool, but documentation is not yet available that I know of. If it doesn't work for you, ask Dave lots of questions. Tell him I said it would be OK. (I'm joking. Don't ask Dave anything. Documentation exists, somewhere, and I'll chase someone around the office until it is made available on the website.)
- matplotlib
- Pyrex
- Elmer
- Most packages have been updated to their latest revision, with exceptions for compatibility
- readline (from UNC Tools, to be specific)
- Additional documentation and some reorganization of the menus to make it less confusing and more functional
- An extra 20 megabytes of random-seeming stuff...Woohoo! It's not over 100MB, yet, but I reckon one more revision will do it.
What isn't in this latest version:
- Python 2.4
There will be an all-singing, all-dancing, all-new, from-scratch Enthon built from the new MSI-based Python 2.4 installer, but it's a pretty big job, so I wanted to get a final 2.3 release out into the world before I hunker down and figure out the new msi installer. That said, I'm downright ecstatic to be giving Wise the boot. If I never see that line editor again in this lifetime, it will be too soon.
In the meantime, if you all can grab this latest test release and let me know how it works for you, I'd be very grateful. Do whatever it is that you currently do with build 1057 of Enthon (the last public release), and if it doesn't work right in build 1062, let me know--send the error output and a test case so I can reproduce it and know it is fixed. If there's other stuff you'd like to be able to do, but Enthon never quite worked right, I won't mind hearing about that either.
So, without further ado, here's the link:
http://download.enthought.com/enthought_python-2.3.3-1062.exe
Thanks!
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
-- ====================== Greg Rogers Enthought grogers@enthought.com
"Joe" == Joe Cooper <joe@enthought.com> writes:
Joe> Some highlights of the latest version:... Joe> - matplotlib Hi Joe -- excellent work. I recommend one important change to the matplotlib configuration file .matplotlibrc (which resides in the same directory as setup.py and ultimately gets placed in C:\Python23\share\.matplotlibrc. The default backend in the src tarball which you used is GTKAgg, which doesn't work in the default enthon install because pygtk is not available. I suggest changing this to either TkAgg or WXAgg. Since most of the enthon tools default to wx, perhaps WXAgg is the natural choice. Eg, the line in .matplotlibrc should read backend : WXAgg # the default backend I tested enthon matplotlib with tkagg, wxagg and ran my suite of example figure drivers for the image backends (PNG/PS/SVG) and it passed with flying colors. There are already a few bugs that are not mission critical that have been fixed in CVS since the 0.70.1 release. Perhaps we can get together for an updated version for the enthon 2.4 release. Many thanks! JDH
On Wed, 2005-01-19 at 09:06 -0600, John Hunter wrote:
"Joe" == Joe Cooper <joe@enthought.com> writes:
Joe> Some highlights of the latest version:...
Joe> - matplotlib
Hi Joe -- excellent work. I recommend one important change to the matplotlib configuration file .matplotlibrc (which resides in the same directory as setup.py and ultimately gets placed in C:\Python23\share\.matplotlibrc. The default backend in the src tarball which you used is GTKAgg, which doesn't work in the default enthon install because pygtk is not available. I suggest changing this to either TkAgg or WXAgg. Since most of the enthon tools default to wx, perhaps WXAgg is the natural choice. Eg, the line in .matplotlibrc should read
backend : WXAgg # the default backend
I tested enthon matplotlib with tkagg, wxagg and ran my suite of example figure drivers for the image backends (PNG/PS/SVG) and it passed with flying colors.
There are already a few bugs that are not mission critical that have been fixed in CVS since the 0.70.1 release. Perhaps we can get together for an updated version for the enthon 2.4 release.
Hey John, Thanks for giving it a spin and the configuration tip. I'll get that change into the next test release. If you'd like to roll a 0.70.2 release between now and the end of the week, I'll be happy to drop the new version in. Since you added build fixes for 0.70.1, my aap recipe downloads, builds, and installs into the installer prefix with a single command (and it apparently works!). As long as that keeps happening, I'll happily update it as frequently as you do until we go gold. ;-) This is just the kind of feedback I need. I have no clue how folks are using Enthon out there, or even how many of the components are called, and having developers who know what's supposed to happen try it out is very nice.
"Joe" == Joe Cooper <joe@enthought.com> writes:
Joe> Thanks for giving it a spin and the configuration tip. I'll Joe> get that change into the next test release. If you'd like to Joe> roll a 0.70.2 release between now and the end of the week, Joe> I'll be happy to drop the new version in. Since you added Joe> build fixes for 0.70.1, my aap recipe downloads, builds, and Joe> installs into the installer prefix with a single command (and Joe> it apparently works!). As long as that keeps happening, I'll Joe> happily update it as frequently as you do until we go gold. Joe> ;-) Great, I was afraid to ask :-) I figured 30 package developers saying "wait, wait, just one more bug fix please" would make your life hell. I'll definitely try and get a 70.2 out. Since there are two more bugs I would like to see fixed yet, I'll get cracking. JDH
John Hunter wrote:
Joe> - matplotlib
Hi Joe -- excellent work. I recommend one important change to the matplotlib configuration file .matplotlibrc (which resides in the same directory as setup.py and ultimately gets placed in C:\Python23\share\.matplotlibrc. The default backend in the src tarball which you used is GTKAgg, which doesn't work in the default enthon install because pygtk is not available. I suggest changing this to either TkAgg or WXAgg. Since most of the enthon tools default to wx, perhaps WXAgg is the natural choice. Eg, the line in .matplotlibrc should read
backend : WXAgg # the default backend
I tested enthon matplotlib with tkagg, wxagg and ran my suite of example figure drivers for the image backends (PNG/PS/SVG) and it passed with flying colors.
Just curious: did you test this from a normal terminal or from ipython -pylab? I ask because I was just trying to help a colleague get going with Enthon, and starting ipython -pylab with the WXAgg backend gave me a nasty ipython crash, related to signal handling. Unfortunately I didn't have time to investigate, since I was supposed to help him with other things. I just set the default backend to TkAgg and moved on. The error, as far as I remember, was a SystemError exception when attempting to install a SIGINT handler by runcode. In Shell.py: def runcode(self): """Execute a code object. Multithreaded wrapper around IPython's runcode().""" # lock thread-protected stuff self.ready.acquire() # Install sigint handler signal.signal(signal.SIGINT, sigint_handler) this works just fine under Linux (though it's an unpleasant hack), but apparently it breaks something in Windows. I know signal handling is not a cross-platform-frienly problem... If this really breaks things for windows users, I'd appreciate if someone could test (keeping the WXAgg backend), changing the above to: # Install sigint handler try: signal.signal(signal.SIGINT, sigint_handler) except SystemError: pass If that helps, then we can use this for protecting windows users so they can use ipython/pylab with WX, which is probably the preferred combination for Windows users (native widgets and all). Sorry to offload debugging on others, but I have nowhere to test this, and I'm just working from memory from the traceback I saw fly by on my friend's screen. Regards, f
Fernando> Just curious: did you test this from a normal terminal Fernando> or from ipython -pylab? I ask because I was just trying Fernando> to help a colleague get going with Enthon, and starting Fernando> ipython -pylab with the WXAgg backend gave me a nasty Fernando> ipython crash, related to signal handling. Fernando> Unfortunately I didn't have time to investigate, since I Fernando> was supposed to help him with other things. I just set Fernando> the default backend to TkAgg and moved on. I tested in a normal terminal, not pylab. Fernando> cross-platform-frienly problem... If this really breaks Fernando> things for windows users, I'd appreciate if someone Fernando> could test (keeping the WXAgg backend), changing the Fernando> above to: Yes, it does break wxagg/pylab on win32. And your change fixes it. With the try/except block I was able to run --pylab with wxagg as my default backend. Good catch, Fernando! JDH
John Hunter wrote:
Yes, it does break wxagg/pylab on win32. And your change fixes it. With the try/except block I was able to run --pylab with wxagg as my default backend.
Thanks for testing, John. Since this is such a nasty crash, and it happens squarely with the interaction of matplotlib and ipython, I decided to wrap up all the recent fixes and just made a 0.6.7 release of ipython. Joe, it would be great if (again :) you could grab this for the final enthon release, otherwise the recommended defaults (pylab+wxagg+ipython) will give users just an instant crash. I've now made it official, so it sits in: http://ipython.scipy.org/dist/ I'm too swamped with other things to make an announcement right now, but as long as Joe gets this I'm happy (if there's still time to include it). I also have a couple of minor suggestions to make on Enthon: 1. The included .matplotlibrc file has unix (\n) line endings. It might be worth running unix2dos over it before shipping, since notepad makes a glorious mess out of it (I saw it yesterday when trying to change backends on my friend's laptop). 2. Would it be possible to add a second IPython shortcut beyond the one you already have, but which also opens pylab? Something like "IPython+pylab", or simply Pylab (whatever John likes), where the command would be '...python.exe ipython -pylab -p enthought'. The current one loads the enthought profile, this would just add the -pylab switch, which is required as a startup flag because it modifies the ipython initialization sequence. Having this would give the new Win32 users a single-click way to get started plotting and running pylab commands, while maintaining the same enviroment they'd get with the default ipython (since in both cases we'd load the enthought profile). Anyway, many thanks for this, you've done a phenomenal job, Joe. My friend (an experimental physicist) was thrilled yesterday seeing the potential, all the included tools and documentation, etc. This is really great! Sorry I've been causing all these last-minute troubles. Cheers, f
On Tue, 2005-01-18 at 23:49 -0600, Joe Cooper wrote:
Hi all,
The much anticipated new release of the Enthought Edition of Python (a.k.a. Enthon) is just about ready for release into the real world. I'd like for some of you brave developer-type folks to give it a go before I announce it more widely and link it from the Enthon home page.
Some highlights of the latest version:
- iPython 0.6.7_rc2 is the default shell
- The Enthought Open Source Python tools have been added. This includes a few things that migrated out of the SciPy CVS repository and into the Enthought SVN repository about a year ago, or thereabouts. Specifically, new versions of traits, chaco, kiva, etc. It's all really cool, but documentation is not yet available that I know of. If it doesn't work for you, ask Dave lots of questions. Tell him I said it would be OK. (I'm joking. Don't ask Dave anything. Documentation exists, somewhere, and I'll chase someone around the office until it is made available on the website.)
- matplotlib
- Pyrex
- Elmer
- Most packages have been updated to their latest revision, with exceptions for compatibility
- readline (from UNC Tools, to be specific)
- Additional documentation and some reorganization of the menus to make it less confusing and more functional
- An extra 20 megabytes of random-seeming stuff...Woohoo! It's not over 100MB, yet, but I reckon one more revision will do it.
What isn't in this latest version:
- Python 2.4
There will be an all-singing, all-dancing, all-new, from-scratch Enthon built from the new MSI-based Python 2.4 installer, but it's a pretty big job, so I wanted to get a final 2.3 release out into the world before I hunker down and figure out the new msi installer. That said, I'm downright ecstatic to be giving Wise the boot. If I never see that line editor again in this lifetime, it will be too soon.
In the meantime, if you all can grab this latest test release and let me know how it works for you, I'd be very grateful. Do whatever it is that you currently do with build 1057 of Enthon (the last public release), and if it doesn't work right in build 1062, let me know--send the error output and a test case so I can reproduce it and know it is fixed. If there's other stuff you'd like to be able to do, but Enthon never quite worked right, I won't mind hearing about that either.
So, without further ado, here's the link:
http://download.enthought.com/enthought_python-2.3.3-1062.exe
Is there any thought of including pyTables and the HDF5 libraries? I use these myself on a regular basis.
Joe Cooper wrote:
Hi all,
The much anticipated new release of the Enthought Edition of Python (a.k.a. Enthon) is just about ready for release into the real world. I'd like for some of you brave developer-type folks to give it a go before I announce it more widely and link it from the Enthon home page.
Sweet. Do you have a list of included packages with version numbers so I can mimic as much as possible with MacEnthon? -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
Robert Kern wrote:
Joe Cooper wrote:
Hi all,
The much anticipated new release of the Enthought Edition of Python (a.k.a. Enthon) is just about ready for release into the real world. I'd like for some of you brave developer-type folks to give it a go before I announce it more widely and link it from the Enthon home page.
Sweet. Do you have a list of included packages with version numbers so I can mimic as much as possible with MacEnthon?
Not at the moment, but grep ought to be able to generate one...Expect it shortly (I may or may not be able to convince our build box to let me remotely login, if it has any apps running it refuses to give me a display...Windows is classy that way. If not, it will be tomorrow.).
Hi Joe,
"Joe" == Joe Cooper <joe@enthought.com> writes:
Joe> Hi all, The much anticipated new release of the Enthought Joe> Edition of Python (a.k.a. Enthon) is just about ready for Joe> release into the real world. I'd like for some of you brave Joe> developer-type folks to give it a go before I announce it more Joe> widely and link it from the Enthon home page. I finally had the chance to install this under WinXP. The installer is excellent! Many thanks for the effort! Some comments: 1. I suspect you are still using MayaVi-1.3. This version has a buggy volume module. The CVS snapshot is available here http://vvikram.com/~prabhu/download/mayavi/MayaVi-1.3.cvs20040814.zip I recommend using this instead because it supports time series, incorporates serious bug fixes and also supports user module/filter directories. I'll try and make a 1.4 release sometime soon so this is easier, but if its not a hassle would appreciate if you could use the above snapshot till then. Thanks! 2. The default heart.mv example that is installed (Enthought/examples/mayavi/examples) has unix style line endings and won't work under win32. If you convert these to dos style line endings this will work. All I needed to do was to run lfcr.py on the offending file. Would be cool if this were done by default. 3. Seems like the 'enthought' package included is a little dated. Do you plan to update this to a more recent version? 4. The chm docs are amazing. However some of the docs like IPython, elmer, SWIG etc. are not part of it. Would be awesome if these could also be integrated. 5. The number of useful packages installed is *very* large (you could say "universe included" ;-). I was actually unaware of all the installed packages -- for example mingw and swig were pleasant surprises. It would add a nice touch if a small (or not so small :) README.txt with just a listing of all the packages that ship with the installer could be shown after the install so the user is aware of what is installed. 6. You seem to have two copies of the VTK Python dlls. One in site-packages/vtk_python and another in site-packages/vtk_python/vtk. Plus the vtk*TCL.dll's are also installed. These are unnecessary and may be removed. In fact your build script need not build the TCL wrappers at all. You just need to make sure CMake gets the Tcl/Tk paths so it can build the TkRenderWidget for Python. No need to turn on Tcl wrapping. You've also turned on building the Patented classes. This _could_ land you in legal trouble. So, I'd advise that you turn patented libs off. Finally, I am interested in learning of your experience with aap. It looks to be a very interesting tool. I've used scons and scons really shines when it comes to building code but I don't think it easily allows for the kind of thing that aap is so strong in. Care to share your thoughts and experience with aap? In particular, do you think it is possible to abandon distutils in the future in favor of it? Anyway thanks again to you and Enthought for the enormous effort involved in this task and for the quality of the packaging! cheers, prabhu
Prabhu Ramachandran wrote:
Hi Joe,
"Joe" == Joe Cooper <joe@enthought.com> writes:
Joe> Hi all, The much anticipated new release of the Enthought Joe> Edition of Python (a.k.a. Enthon) is just about ready for Joe> release into the real world. I'd like for some of you brave Joe> developer-type folks to give it a go before I announce it more Joe> widely and link it from the Enthon home page.
I finally had the chance to install this under WinXP. The installer is excellent! Many thanks for the effort! Some comments:
Thanks for giving it a try!
1. I suspect you are still using MayaVi-1.3. This version has a buggy volume module. The CVS snapshot is available here
http://vvikram.com/~prabhu/download/mayavi/MayaVi-1.3.cvs20040814.zip
I recommend using this instead because it supports time series, incorporates serious bug fixes and also supports user module/filter directories.
I'll try and make a 1.4 release sometime soon so this is easier, but if its not a hassle would appreciate if you could use the above snapshot till then. Thanks!
My policy was to use only the latest release versions of everything, but it seems no one does releases anymore, so all the "stable releases" of everything are broken in horrible ways, according to the developers. ;-) (I grin, but it's proven to be true for just about everything in Enthon. If I don't laugh, I'll cry.) I've be diverted to working on the Linux version of Enthon for the rest of this week, so if 1.4 can happen by Monday or Tuesday, that would make me much happier than including yet another snapshot.
2. The default heart.mv example that is installed (Enthought/examples/mayavi/examples) has unix style line endings and won't work under win32. If you convert these to dos style line endings this will work. All I needed to do was to run lfcr.py on the offending file. Would be cool if this were done by default.
Hmmm...I didn't have any problems with this file when I was testing. But I did re-add lfcr.py and all of the Python tools (or util, or whatever it's called, I'm not on a Windows box at the moment) directory to the Enthon package with build 1059 or thereabouts. So I'll take your word for it that it is broken and run it through before bundling.
3. Seems like the 'enthought' package included is a little dated. Do you plan to update this to a more recent version?
Yes. As soon as I get one that builds. ;-)
4. The chm docs are amazing. However some of the docs like IPython, elmer, SWIG etc. are not part of it. Would be awesome if these could also be integrated.
Sure would. I have little clue how to make it happen...but I'll look into it.
5. The number of useful packages installed is *very* large (you could say "universe included" ;-). I was actually unaware of all the installed packages -- for example mingw and swig were pleasant surprises. It would add a nice touch if a small (or not so small :) README.txt with just a listing of all the packages that ship with the installer could be shown after the install so the user is aware of what is installed.
Agreed. I'll add one to the documentation submenu.
6. You seem to have two copies of the VTK Python dlls. One in site-packages/vtk_python and another in site-packages/vtk_python/vtk. Plus the vtk*TCL.dll's are also installed. These are unnecessary and may be removed. In fact your build script need not build the TCL wrappers at all. You just need to make sure CMake gets the Tcl/Tk paths so it can build the TkRenderWidget for Python. No need to turn on Tcl wrapping. You've also turned on building the Patented classes. This _could_ land you in legal trouble. So, I'd advise that you turn patented libs off.
Hmmm...I inherited the tcl wrappers building stuff. Will look into removing it. Eric asked for the Patented classes. I will re-open the issue with him, if you think the patents are still in effect, and distributing them will cause issues--I don't think there is a problem with us dsitributing them, but I would like to warn people off of them, if the patents are still in effect.
Finally, I am interested in learning of your experience with aap. It looks to be a very interesting tool. I've used scons and scons really shines when it comes to building code but I don't think it easily allows for the kind of thing that aap is so strong in. Care to share your thoughts and experience with aap? In particular, do you think it is possible to abandon distutils in the future in favor of it?
Given my experience with distutils, I believe it would be possible to abandon distutils for a ball of twine and some used chewing gum. (OK, I exaggerate, but distutils strikes me as being incredibly fragile...see the thread yesterday on Scipy-users about my troubles building Scipy_core.) aap is very very good, and Bram Moolenaar has been very responsive to bug reports. It is also pure python, which gives it a leg up for my needs, since I can bootstrap up a new Enthon build environment (theoretically--this won't become reality until I don't need MSVC6 and the Wise install builder...which happens in Python 2.4) with only Python 2.4 and the free compiler from MS. And, again theoretically until some of the other ugliness has been excised from the system, I can install aap and point it to the right place, and have it download all of the packages, build them, and bundle them up, without any human intervention. New versions will be a lot easier. But for a general build/install utility, I have little experience with it. I certainly wouldn't argue against it, as it simply has to be better than distutils. It's only negative is that it is a new thing for folks to learn. It took me an afternoon to get the gist of it, and I've never bothered to get much beyond that--though I will spend more time with it once I'm working on 2.4 and all of the uglies in the 2.3 build are just a bad memory.
Anyway thanks again to you and Enthought for the enormous effort involved in this task and for the quality of the packaging!
Thanks for the kind words. And thanks again for looking at it. Because I have so little knowledge of most of the components (there's just too many to keep up with, and a lot of it is far outside my area of expertise), I really need input on how stuff works. If I don't hear complaints or comments, I assume everything is perfect, and I work on other things.
Joe Cooper wrote:
Prabhu Ramachandran wrote:
4. The chm docs are amazing. However some of the docs like IPython, elmer, SWIG etc. are not part of it. Would be awesome if these could also be integrated.
Sure would. I have little clue how to make it happen...but I'll look into it.
As for ipython, you only get html and pdf from me. I don't know if that html is enough for you to make a .chm out of it or not. If there's anything I can do from linux to make the process easier, I'd love to help. But the sources from the manual are in lyx, so I'm limited to formats I can export from lyx (html, latex, postscript, pdf, docbook).
Given my experience with distutils, I believe it would be possible to abandon distutils for a ball of twine and some used chewing gum. (OK, I exaggerate, but distutils strikes me as being incredibly fragile...see
You exaggerate, but only a tiny, tiny bit. Distutils is easily the worst part of the python standard toolset, by a very long shot. Cheers, f
"JC" == Joe Cooper <joe@enthought.com> writes:
JC> Prabhu Ramachandran wrote: >> I'll try and make a 1.4 release sometime soon so this is >> easier, but if its not a hassle would appreciate if you could >> use the above snapshot till then. Thanks! JC> My policy was to use only the latest release versions of JC> everything, but it seems no one does releases anymore, so all JC> the "stable releases" of everything are broken in horrible JC> ways, according to the developers. JC> ;-) (I grin, but it's proven to be true for just about JC> ;everything in JC> Enthon. If I don't laugh, I'll cry.) Well, in my case the CVS snapshots are actually stable. ;-) I have had several problems making a release. The biggest being lack of easy availability of a win32 box to build the win32 binary. Starting this week I have easy access to a win32 box, so this is not an issue anymore. JC> I've be diverted to working on the Linux version of Enthon for JC> the rest of this week, so if 1.4 can happen by Monday or JC> Tuesday, that would make me much happier than including yet JC> another snapshot. OK, I'll push its priority up and try to get a 1.4 release done ASAP. >> 3. Seems like the 'enthought' package included is a little >> dated. Do >> you plan to update this to a more recent version? JC> Yes. As soon as I get one that builds. ;-) :) >> 4. The chm docs are amazing. However some of the docs like >> IPython, >> elmer, SWIG etc. are not part of it. Would be awesome if these >> could also be integrated. JC> Sure would. I have little clue how to make it happen...but JC> I'll look into it. Hmm, well you (or some magical elf on your machine ;-) seems to have done it for the MayaVi documentation -- its part of the big Enthought Python chm. So I guess the same magic would do for these. >> wrapping. You've also turned on building the Patented classes. >> This _could_ land you in legal trouble. So, I'd advise that >> you turn patented libs off. JC> Eric asked for the Patented classes. I will re-open the issue JC> with him, if you think the patents are still in effect, and JC> distributing them will cause issues--I don't think there is a JC> problem with us dsitributing them, but I would like to warn JC> people off of them, if the patents are still in effect. IIRC, Robert Kern raised very valid concerns about this on the MacEnthon thread on this list. I am totally clueless as to the nature of the patents and when they expire. I just thought I'd mention it so you are aware of potential problems. >> Finally, I am interested in learning of your experience with >> aap. It looks to be a very interesting tool. I've used scons >> and scons really shines when it comes to building code but I >> don't think it easily allows for the kind of thing that aap is >> so strong in. Care to share your thoughts and experience with >> aap? In particular, do you think it is possible to abandon >> distutils in the future in favor of it? JC> Given my experience with distutils, I believe it would be JC> possible to abandon distutils for a ball of twine and some JC> used chewing gum. (OK, I exaggerate, but distutils strikes me JC> as being incredibly fragile...see the thread yesterday on JC> Scipy-users about my troubles building Scipy_core.) I love your description. ;-) JC> aap is very very good, and Bram Moolenaar has been very JC> responsive to bug reports. It is also pure python, which JC> gives it a leg up for my needs, since I can bootstrap up a new JC> Enthon build environment (theoretically--this won't become JC> reality until I don't need MSVC6 and the Wise install JC> builder...which happens in Python 2.4) with only Python JC> 2.4 and the free compiler from MS. And, again theoretically JC> until some JC> of the other ugliness has been excised from the system, I can JC> install aap and point it to the right place, and have it JC> download all of the packages, build them, and bundle them up, JC> without any human intervention. New versions will be a lot JC> easier. Sounds very cool. JC> But for a general build/install utility, I have little JC> experience with it. I certainly wouldn't argue against it, as JC> it simply has to be better than distutils. It's only negative JC> is that it is a new thing for folks to learn. It took me an JC> afternoon to get the gist of it, and I've never bothered to The aap docs are very good (with lots of examples). I spent an hour reading it up earlier and was very impressed. So, I really don't think learning a well documented and useful tool would be too much to ask. JC> get much beyond that--though I will spend more time with it JC> once I'm working on 2.4 and all of the uglies in the 2.3 build JC> are just a bad memory. Good luck! >> Anyway thanks again to you and Enthought for the enormous >> effort involved in this task and for the quality of the >> packaging! JC> Thanks for the kind words. And thanks again for looking at JC> it. Because I have so little knowledge of most of the JC> components (there's just too many to keep up with, and a lot JC> of it is far outside my area of expertise), I really need JC> input on how stuff works. If I don't hear complaints or JC> comments, I assume everything is perfect, and I work on other JC> things. Sure, glad to be of assistance. I will try to cut a 1.4 release of MayaVi sometime soon. regards, prabhu
Prabhu Ramachandran wrote:
"JC" == Joe Cooper <joe@enthought.com> writes:
JC> Prabhu Ramachandran wrote: >> I'll try and make a 1.4 release sometime soon so this is >> easier, but if its not a hassle would appreciate if you could >> use the above snapshot till then. Thanks!
JC> My policy was to use only the latest release versions of JC> everything, but it seems no one does releases anymore, so all JC> the "stable releases" of everything are broken in horrible JC> ways, according to the developers. JC> ;-) (I grin, but it's proven to be true for just about JC> ;everything in JC> Enthon. If I don't laugh, I'll cry.)
Well, in my case the CVS snapshots are actually stable. ;-) I have had several problems making a release. The biggest being lack of easy availability of a win32 box to build the win32 binary. Starting this week I have easy access to a win32 box, so this is not an issue anymore.
Understandable. The reason for not using CVS snaps is not entirely stability. It is the "known quantity" state of releases. It makes it easier to deal with bug reports to have a known version--and one that others or I can compare the Enthon build against. Because there can be problems with either my build or the software itself, and I'm going to hear about both, it's nice for me to be able to say "Do you have the same problem with a non-Enthon build of the same version of the software?" And though they may not have an answer or be capable of testing, at least there's somewhere to start. Snapshots are much harder if I want to do this, because I have to make the snapshot available somewhere, for later comparison sake. Bug fixes upstream are easier to keep up with for versioned software. Bug reports upstream are easier to make for versioned software. (Rather than saying "I checked out from CVS...ummm, a couple of weeks ago...maybe?") Versioned software is easier to sync up across multiple platforms. I am building for multiple Linux distros and Windows. If I know the version, and it is a release version, I can pull it from the origin with my build scripts without having to keep a synced up repository of my own pristine sources that all platforms can access. I'd like for all of the platforms to be using the same version--and Robert Kern has expressed an interest attempting to roughly mimic that policy for Mac Enthon. The goal, of course, is for someone to be able to work on their Mac laptop on the road, their Linux desktop at home, and their Windows desktop at work, without having to think differently for each platform...to as great a degree as is possible given the current state of the tools on each platform (for an example of a limitation to this plan, wx 2.4 is not supported on Mac OSX, but it is the version we continue to distribute for Windows and Linux and will for the foreseeable future--Dave adamantly refuses to work with APIs that change frequently, and until there is an official 2.5 release, I agree whole-heartedly with him).
JC> I've be diverted to working on the Linux version of Enthon for JC> the rest of this week, so if 1.4 can happen by Monday or JC> Tuesday, that would make me much happier than including yet JC> another snapshot.
OK, I'll push its priority up and try to get a 1.4 release done ASAP.
I do appreciate it. Don't work yourself too hard to do it...My ideal world won't be happening with this release, regardless of whether your release occurs. But I'm trying to establish some guidelines that make it easy for developers to get their software into Enthon in a form that works well, making both me and the developer look good to the end user. ;-) By the time of the 2.4 release, I will likely be much more stringent about including release-only versions of software. Since that is a couple of months away to coincide with the next versioned release of SciPy, it gives everyone a little while to make up their mind about inclusion in Enthon and how much it means to them. I have an inkling of an idea for making it possible for developers to make easily installable sub-packages available for Enthon, without having to make it in on my release schedule...we'll see how that turns out. It might even mean the main Enthon download can shrink in the next release. ;-)
>> 3. Seems like the 'enthought' package included is a little >> dated. Do >> you plan to update this to a more recent version?
JC> Yes. As soon as I get one that builds. ;-)
:)
>> 4. The chm docs are amazing. However some of the docs like >> IPython, >> elmer, SWIG etc. are not part of it. Would be awesome if these >> could also be integrated.
JC> Sure would. I have little clue how to make it happen...but JC> I'll look into it.
Hmm, well you (or some magical elf on your machine ;-) seems to have done it for the MayaVi documentation -- its part of the big Enthought Python chm. So I guess the same magic would do for these.
Yes. I believe everyone here likes to think of Dave Morrill as our resident magical elf. But he no longer waves his wand over Enthon, so we're stuck with what I can manage. That said, by my understanding the process that Dave used to generate the .chm was neither magical nor vaguely automatic. So it has taken a back-seat to getting a package that works. I have focused a bit on getting better access to documentation into the menu, though, and I will see if I can work towards automating the process of importing the existing HTML/LaTeX/Docbook/man/whatever documentation into the .chm.
>> wrapping. You've also turned on building the Patented classes. >> This _could_ land you in legal trouble. So, I'd advise that >> you turn patented libs off.
JC> Eric asked for the Patented classes. I will re-open the issue JC> with him, if you think the patents are still in effect, and JC> distributing them will cause issues--I don't think there is a JC> problem with us dsitributing them, but I would like to warn JC> people off of them, if the patents are still in effect.
IIRC, Robert Kern raised very valid concerns about this on the MacEnthon thread on this list. I am totally clueless as to the nature of the patents and when they expire. I just thought I'd mention it so you are aware of potential problems.
Yeah...My position was "I will not include the patented classes, until those patents are confirmed expired". Eric vetoed that position on the basis that he thinks one of the patented classes is pretty cool. I think there was some debate on whether some or all of the patents were still enforceable. I suppose we'll have to see. Anyway, my understanding is that free distribution is never a problem. So our primary responsibility is to warn people of their existence within the distribution, so they won't use them in commercial software without awareness of their liability...since they have to read the VTK docs to use them, I would guess that would know which classes were questionable. But I'll add a "README.PATENTED" to the docs directory and docs menu to explain it all. Thanks again for the feedback. And don't forget (like I did for the first several months after I took over the project) that there is an issue tracker just for Enthon: https://www.enthought.com/roundup/enthon Wishes and bugs reported here are more likely to be acted upon than any others. Not because I don't want to do everything everybody mentions on the mailing list, it's just impossible to keep up with all of it.
Joe Cooper wrote: [snip]
Yeah...My position was "I will not include the patented classes, until those patents are confirmed expired". Eric vetoed that position on the basis that he thinks one of the patented classes is pretty cool.
Well, yeah. If it weren't cool and useful, it wouldn't be patented. :-)
I think there was some debate on whether some or all of the patents were still enforceable. I suppose we'll have to see.
(Before I begin, I will state that I am not a lawyer; this is not legal advice.) Which ones? Two of the patents look like they are going to expire this summer (assuming the usual 20-year patent term) but not before then. One of the patents is still pending. vtkDecimate http://patft.uspto.gov/netacgi/nph-Parser?u=/netahtml/srchnum.htm&Sect1=PTO1&Sect2=HITOFF&p=1&r=1&l=50&f=G&d=PALL&s1=5590248.WKU.&OS=PN/5590248&RS=PN/5590248 5,590,248 February 24, 1995 [Note: the title given in the header file has a typo: s/Reducting/Reducing/, and the patent number given is just wrong.] vtkDividingCubes http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=4,719,585.WKU.&OS=PN/4,719,585&RS=PN/4,719,585 4,719,585 August 28, 1985 vtkGridSynchronizedTemplates3D vtkRectilinearSynchronizedTemplates vtkSynchronizedTemplates2D vtkSynchronizedTemplates3D Patent pending vtkImageMarchingCubes vtkMarchingContourFilter vtkMarchingCubes vtkMarchingSquares vtkSliceCubes http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=4,710,876.WKU.&OS=PN/4,710,876&RS=PN/4,710,876 4,710,876 June 5, 1985 vtkSweptSurface http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=5,542,036.WKU.&OS=PN/5,542,036&RS=PN/5,542,036 5,542,036 July 5, 1994 The others have no comments about patents, but I believe they depend on the other classes in VTK/Patented.
Anyway, my understanding is that free distribution is never a problem. So our primary responsibility is to warn people of their existence within the distribution, so they won't use them in commercial software without awareness of their liability...since they have to read the VTK docs to use them, I would guess that would know which classes were questionable. But I'll add a "README.PATENTED" to the docs directory and docs menu to explain it all.
The problem with this is that patent infringement isn't like GPL infringement. GPL's conditions are triggered when you redistribute code, but simple use of the software is unrestricted. That's why it makes sense to include readline et al. with a warning that if people intend to redistribute Enthon binaries, they have to also distribute (or offer to distribute) the readline sources. They don't have to think about the GPL until they start distributing stuff, in which case, reading licenses is something they have to do regardless. However, patent infringement triggers on *use* for commercial purposes (which, as of 2003, now includes essentially all university research as well). Anyone using Marching Cubes to make an image is potentially infringing on the patent; if and how they distribute the code that makes the image is immaterial. Every time a user sits down with Mayavi or tvtk, they're going to have to think about which classes to avoid if they care about not infringing on the patents. Now, if Eric has talked with Enthought's lawyer about this, I'll shut up about the Windows and Linux releases although I still don't feel right about doing it myself for the Mac version. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
Robert Kern wrote:
(Before I begin, I will state that I am not a lawyer; this is not legal advice.)
Which ones? Two of the patents look like they are going to expire this summer (assuming the usual 20-year patent term) but not before then. One of the patents is still pending.
Oops. I was wrong. The 20-year term wasn't enacted until 1995. Patents filed before then usually have a 17-year term[1] (Note: this is all Google-fu, not a legal opinion. If you need one, please retain your own lawyer and ask him). It looks like Marching Cubes/Squares and Dividing Cubes *may* be safe to use. I'll look into futzing with the VTK build process to be able to compile just these classes. [1] http://assembler.law.cornell.edu/uscode/html/uscode35/usc_sec_35_00000154---... -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
Robert Kern wrote:
Robert Kern wrote:
(Before I begin, I will state that I am not a lawyer; this is not legal advice.)
Which ones? Two of the patents look like they are going to expire this summer (assuming the usual 20-year patent term) but not before then. One of the patents is still pending.
Oops. I was wrong. The 20-year term wasn't enacted until 1995. Patents filed before then usually have a 17-year term[1] (Note: this is all Google-fu, not a legal opinion. If you need one, please retain your own lawyer and ask him). It looks like Marching Cubes/Squares and Dividing Cubes *may* be safe to use. I'll look into futzing with the VTK build process to be able to compile just these classes.
[1] http://assembler.law.cornell.edu/uscode/html/uscode35/usc_sec_35_00000154---...
I remember some discussion on the VTK list (or somewhere) about this. The main developers were saying they thought that most of the patents expired Dec 2004 or something like that -- but they weren't sure. Hmmm. Here it is: http://public.kitware.com/pipermail/vtk-developers/2002-July/001755.html and http://public.kitware.com/pipermail/vtk-developers/2002-July/001763.html They mention Dec 2004 and June 2005. We can either do some digging to be sure Dec 2004 is right, or we can wait until June and then turn on the expired ones then... For now, I am happy to keep them turned off. eric
"eric" == eric jones <eric@enthought.com> writes:
eric> http://public.kitware.com/pipermail/vtk-developers/2002-July/001755.html eric> and eric> http://public.kitware.com/pipermail/vtk-developers/2002-July/001763.html eric> They mention Dec 2004 and June 2005. We can either do some eric> digging to be sure Dec 2004 is right, or we can wait until eric> June and then turn on the expired ones then... eric> For now, I am happy to keep them turned off. Hey Eric, My read on that discussion is that Dec 2004 is the proper date. Bill Lorensen suggested marching cubes was patented through June 2005, and then Ken Martin responded Actually we are both wrong. I added incorrectly. It expires December 2004 not 2003. The 20 year rule is for patents filed after 1995. I included a brief desc below. and cited Utility and plant patents issued prior to June 8, 1995 expire 17 years from the date of issue with the payment of maintenance fees. Since marching cubes was issued on December 1, 1987 [1], despite some beer jokes that follow in the thread you linked, Dec 2004 appears to be the right answer in the eyes of the vtk devs for marching cubes. But dividing cubes was not issued until Dec 5, 1989 [2], which in my read means its protected until Dec 5, 2006. All of this of course hinges upon the claim that these patents both indeed expire 17 years from date of issue, and despite the fact that I've stared for a long while at the helpful link [3] Robert provided, I can't really figure that one out. As an aside, on an unrelated quest to find out if marching squares was enforceable, an enterprising matplotlib user contacted GE corporate counsel Carl Horton for clarification -- his response was less than edifying, basically amounting to "show me the money!" [4] JDH [1] http://patft.uspto.gov/netacgi/nph-Parser?u=/netahtml/srchnum.htm&Sect1=PTO1&Sect2=HITOFF&p=1&r=1&l=50&f=G&d=PALL&s1=4710876.WKU.&OS=PN/4710876&RS=PN/4710876 [2] http://patft.uspto.gov/netacgi/nph-Parser?u=/netahtml/srchnum.htm&Sect1=PTO1&Sect2=HITOFF&p=1&r=1&l=50&f=G&d=PALL&s1=4885688.WKU.&OS=PN/4885688&RS=PN/4885688 [3] http://assembler.law.cornell.edu/uscode/html/uscode35/usc_sec_35_00000154---... [4] http://sourceforge.net/mailarchive/message.php?msg_id=9890501
Hey Joe, I haven't checked into the patent issues at all with lawyeres, so we should definitely turn off the patented code for the distribution. I needed to test one of them for some internal work, hence my request to have them turned on for a distribution. Turns out we didn't need them after all for what we were doing. thanks, eric Robert Kern wrote:
Joe Cooper wrote:
[snip]
Yeah...My position was "I will not include the patented classes, until those patents are confirmed expired". Eric vetoed that position on the basis that he thinks one of the patented classes is pretty cool.
Well, yeah. If it weren't cool and useful, it wouldn't be patented. :-)
I think there was some debate on whether some or all of the patents were still enforceable. I suppose we'll have to see.
(Before I begin, I will state that I am not a lawyer; this is not legal advice.)
Which ones? Two of the patents look like they are going to expire this summer (assuming the usual 20-year patent term) but not before then. One of the patents is still pending.
5,590,248 February 24, 1995 [Note: the title given in the header file has a typo: s/Reducting/Reducing/, and the patent number given is just wrong.]
4,719,585 August 28, 1985
vtkGridSynchronizedTemplates3D vtkRectilinearSynchronizedTemplates vtkSynchronizedTemplates2D vtkSynchronizedTemplates3D Patent pending
vtkImageMarchingCubes vtkMarchingContourFilter vtkMarchingCubes vtkMarchingSquares vtkSliceCubes http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=4,710,876.WKU.&OS=PN/4,710,876&RS=PN/4,710,876
4,710,876 June 5, 1985
5,542,036 July 5, 1994
The others have no comments about patents, but I believe they depend on the other classes in VTK/Patented.
Anyway, my understanding is that free distribution is never a problem. So our primary responsibility is to warn people of their existence within the distribution, so they won't use them in commercial software without awareness of their liability...since they have to read the VTK docs to use them, I would guess that would know which classes were questionable. But I'll add a "README.PATENTED" to the docs directory and docs menu to explain it all.
The problem with this is that patent infringement isn't like GPL infringement. GPL's conditions are triggered when you redistribute code, but simple use of the software is unrestricted. That's why it makes sense to include readline et al. with a warning that if people intend to redistribute Enthon binaries, they have to also distribute (or offer to distribute) the readline sources. They don't have to think about the GPL until they start distributing stuff, in which case, reading licenses is something they have to do regardless.
However, patent infringement triggers on *use* for commercial purposes (which, as of 2003, now includes essentially all university research as well). Anyone using Marching Cubes to make an image is potentially infringing on the patent; if and how they distribute the code that makes the image is immaterial. Every time a user sits down with Mayavi or tvtk, they're going to have to think about which classes to avoid if they care about not infringing on the patents.
Now, if Eric has talked with Enthought's lawyer about this, I'll shut up about the Windows and Linux releases although I still don't feel right about doing it myself for the Mac version.
"RK" == Robert Kern <rkern@ucsd.edu> writes:
[...] RK> immaterial. Every time a user sits down with Mayavi or tvtk, RK> they're going to have to think about which classes to avoid if RK> they care about not infringing on the patents. Well, just to clarify. MayaVi does not use a single patented class. For contouring I only use the slower vtkContourFilter. So, generating images with vanilla MayaVi will not land you in trouble. However, if someone creates a VTK pipeline using the patented algorithms (the VTK libs that ship so far with MayaVi include patented) and renders it on MayaVi then they are in trouble. This also does not insulate users of MayaVi who make custom modules/filters that use patented. Therefore the average MayaVi user does not have a problem. Its only someone who uses raw VTK who is in trouble. Obviously, Enthon cannot rely on this because folks are free to import VTK from Python and do whatever they want to. In these cases it is possible to find out what the patented classes are by doing something like this: from vtk import patented dir(patented) They can choose not to use these classes. In fact, I could whip up a simple Python script to ensure that the only way patented is imported is via: from vtk import patented and not by 'import vtk'. Thus, no one can use the patented stuff from Python unless they know precisely what they are doing. This would require a patch to just one file (vtk_python/vtk/__init__.py). Therefore, we have two choices. 1. We simply advertize the patented classes and pop up a window on install saying: "The following classes are patented." or something along those lines. Then if someone wants to use it they run the risk. 2. We disable importing patented into the vtk module and make it available only from vtk.patented. This way if someone desperately wants the patented stuff, they don't have to rebuild, plus we are safe. Comments? cheers, prabhu
"JC" == Joe Cooper <joe@enthought.com> writes:
JC> Prabhu Ramachandran wrote: >>>>>>> "JC" == Joe Cooper <joe@enthought.com> writes: >> OK, I'll push its priority up and try to get a 1.4 release done >> ASAP. JC> I do appreciate it. Don't work yourself too hard to do JC> it...My ideal world won't be happening with this release, JC> regardless of whether your release occurs. But I'm trying to JC> establish some guidelines that make it easy for developers to JC> get their software into Enthon in a form that works well, JC> making both me and the developer look good to the end user. JC> ;-) OK, it is done. 1.4 is now officially released. :) cheers, prabhu
"Joe" == Joe Cooper <joe@enthought.com> writes:
Joe> Hi all, The much anticipated new release of the Enthought Joe> Edition of Python (a.k.a. Enthon) is just about ready for Joe> release into the real world. I'd like for some of you brave Joe> developer-type folks to give it a go before I announce it Joe> more widely and link it from the Enthon home page. Sorry to bring this up so late in the game, but it appears numarray is not in this test release. Is this correct? If so, it seems like a glaring omission for a scientific computing python rollup. Since numarray offers functionality not found elsewhere, it would be nice to have. Or have I got my local win32 system screwed up with 4 (count em 4!) python installs? JDH
participants (12)
-
Arnd Baecker -
Charles R Harris -
eric jones -
Fernando Perez -
Fernando.Perez＠colorado.edu
-
grogers -
Joe Cooper -
John Hunter -
Nils Wagner -
Pearu Peterson -
Prabhu Ramachandran -
Robert Kern