Menu
▾
▴
visualpython-users
|
From: Bruce S. <Bru...@nc...> - 2006-10-06 18:40:35
|
Questions have been asked about Visual for Python 2.5. A significant hurdle to overcome is that there is not and will not be a version of Numeric for Python 2.5 (the last to be made was for Python 2.4). Its successor Numarray does exist for Python 2.5 but is likely to be the last, as the download instructions say "Use Numpy!" Thanks to Jonathan Brandmeyer's work, Visual can be compiled for Numarray, but some existing VPython programs that used explicit Numeric capabilities may break due to some incompatibilities between Numeric and Numarray. The right thing to do is to revise Visual to use Numpy, which is the designated to-be-supported replacement for both Numeric and Numarray. I do not know how much work will be required to do this. Bruce Sherwood |
|
From: Gary P. <gp...@ri...> - 2006-10-06 18:55:14
|
Bruce Sherwood wrote: >Questions have been asked about Visual for Python 2.5. A significant >hurdle to overcome is that there is not and will not be a version of >Numeric for Python 2.5 (the last to be made was for Python 2.4). Its >successor Numarray does exist for Python 2.5 but is likely to be the >last, as the download instructions say "Use Numpy!" Thanks to Jonathan >Brandmeyer's work, Visual can be compiled for Numarray, but some >existing VPython programs that used explicit Numeric capabilities may >break due to some incompatibilities between Numeric and Numarray. > >The right thing to do is to revise Visual to use Numpy, which is the >designated to-be-supported replacement for both Numeric and Numarray. I >do not know how much work will be required to do this. > >Bruce Sherwood > I seem to recall that a Numeric-to-Numpy script was once available. I don't know its current status. I also don't know if it would work with vpython. I'm pretty busy right now, but I'll guess that Bruce is busier. This weekend I'll try to find some time to dig a little deeper into this problem. -gary |
|
From: <ajs...@op...> - 2006-10-06 20:18:56
|
I have began to look at this as well, at least for the 3.xxx tree. I don't know to what extent things are different for 4.xxx. For 3.xxx, I don't think that the Numeric to Numpy script solves the issue because the integration with Numeric is via the boost.python library. >From what I see there is another 3rd party code module that is used to enhance the boost.python support for Numeric and Numarray. The good news that there has been a new release of this module quite recently specifcally shifting its focus to Numpy. I have the details on my Linux box at home. Is this in line with others' understanding? I am not much of a C++ programmer, but this is something I might be able to get to the bottom of with some work. But with Jonathan gone, I am suggesting that the vpython project should reach out to the wider Python community. I think that the vpython project is (or should be) significant enough to that community as a whole - it certainly is to me - that the project should be able to elicit support from appropriate quarters. I would be happy to help try to elicit assitance on this with some consensus that doing so is appopriate. I am copying this to the Python edu-sig list, where I had just raised the issue of Numopy incompatible this morning, and expressed some concern - with Bruce tied-up, and Jonathan gone - of getting the issue proper attention. Art ----- Original Message ----- From: Gary Pajer Date: Friday, October 6, 2006 2:55 pm Subject: Re: [Visualpython-users] Python 2.5 To: vpusers > Bruce Sherwood wrote: > > >Questions have been asked about Visual for Python 2.5. A > significant > >hurdle to overcome is that there is not and will not be a > version of > >Numeric for Python 2.5 (the last to be made was for Python > 2.4). Its > >successor Numarray does exist for Python 2.5 but is likely to > be the > >last, as the download instructions say "Use Numpy!" Thanks to > Jonathan > >Brandmeyer's work, Visual can be compiled for Numarray, but > some > >existing VPython programs that used explicit Numeric > capabilities may > >break due to some incompatibilities between Numeric and Numarray. > > > >The right thing to do is to revise Visual to use Numpy, which > is the > >designated to-be-supported replacement for both Numeric and > Numarray. I > >do not know how much work will be required to do this. > > > >Bruce Sherwood > > > I seem to recall that a Numeric-to-Numpy script was once available. > I don't know its current status. > I also don't know if it would work with vpython. > > I'm pretty busy right now, but I'll guess that Bruce is busier. > This weekend I'll try to find some time to dig a little deeper > into this > problem. > > -gary > > ----------------------------------------------------------------- > -------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance > to share your > opinions on IT & business topics through brief surveys -- and > earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users > |
|
From: Bruce S. <Bru...@nc...> - 2006-10-06 20:43:29
|
Many thanks for your initiative, Art. While I intend to get back to working on Visual after November 1 (the deadline for sending our publisher the second edition of our physics textbook), I can't do anything now, and I'm not at all confident of my abilities to replace Visual dependencies on Numeric/Numarray by suitable connections to Numpy. At the very least, I could sure use help. There are two rather different routes toward supporting Visual on Python 2.5. The better route is to work with Visual 4, since that's what we all want to use, given its greatly enhanced graphics capabilities. However, if changing to Numpy doesn't require much effort (I have no idea), it would be good to put that into Visual 3, because there are some serious problems with Visual 4, the most worrisome being the following (extracted from summary in Recent Developments section of vpython.org): 1) Mouse interactions on Windows, including scene.mouse.getclick(), are associated with crashes. A tight loop without a rate() statement may crash or be hard to kill. 2) Some animations run in a jerky manner due to slow rendering of the scene. The program gas.py is an example. The issue may be that the detail level on spheres needs to be decreased. 3) Graphing (from visual.graph import *) works well for many simple uses, but if the axes must be continually adjusted it can be very slow. If you know the extent of your variables and can specify xmax and ymax for the graph, the graphing is very fast. I feel competent to deal with 3) and probably with 2) if it is just a matter of reducing the level of detail. But I don't feel competent to track down and fix problem 1), which might well involve tricky multithread issues. (For the graphing issue it is necessary to do some work analogous to some coding I've already experimented with, having to do with supporting different scale factors in x and y.) And there's the long-standing issue of finding someone to write a Mac version of the platform-specific files in Visual that handle creating a window and handling mouse and keyset events, so that there could be a Mac-native version of VPython, not dependent on running X11 and fink and difficult opaque installs. Hugh Fisher in Australia indicated recently that he might be able to get free to do this in the near future. If we could get over the hump of having a usable Visual 4 for Windows and Mac (as far as I know it works fine on Linux), perhaps we would attract some new developers who could contribute, because Visual 4 comes much closer to offering "professional-grade" graphics likely to interest people in the graphics area. I should thank the National Science Foundation for supporting VPython for several years, but that grant just ended (last week!). I'm personally committed to continued support of VPython, but a community effort is needed to move forward. Again, thanks much, Art. Bruce Sherwood ajs...@op... wrote: >I have began to look at this as well, at least for the 3.xxx tree. I don't know >to what extent things are different for 4.xxx. > >For 3.xxx, I don't think that the Numeric to Numpy script solves the issue >because the integration with Numeric is via the boost.python library. > >>From what I see there is another 3rd party code module that is used to >enhance the boost.python support for Numeric and Numarray. > >The good news that there has been a new release of this module quite >recently specifcally shifting its focus to Numpy. I have the details on my >Linux box at home. > >Is this in line with others' understanding? > >I am not much of a C++ programmer, but this is something I might be able >to get to the bottom of with some work. > >But with Jonathan gone, I am suggesting that the vpython project >should reach out to the wider Python community. > >I think that the vpython project is (or should be) significant enough to >that community as a whole - it certainly is to me - that the project should >be able to elicit support from appropriate quarters. > >I would be happy to help try to elicit assitance on this with some >consensus that doing so is appopriate. > >I am copying this to the Python edu-sig list, where I had just >raised the issue of Numopy incompatible this morning, and expressed >some concern - with Bruce tied-up, and Jonathan gone - of getting >the issue proper attention. > > >Art > >----- Original Message ----- >From: Gary Pajer >Date: Friday, October 6, 2006 2:55 pm >Subject: Re: [Visualpython-users] Python 2.5 >To: vpusers > > > >>Bruce Sherwood wrote: >> >> >> >>>Questions have been asked about Visual for Python 2.5. A >>> >>> >>significant >> >> >>>hurdle to overcome is that there is not and will not be a >>> >>> >>version of >> >> >>>Numeric for Python 2.5 (the last to be made was for Python >>> >>> >>2.4). Its >> >> >>>successor Numarray does exist for Python 2.5 but is likely to >>> >>> >>be the >> >> >>>last, as the download instructions say "Use Numpy!" Thanks to >>> >>> >>Jonathan >> >> >>>Brandmeyer's work, Visual can be compiled for Numarray, but >>> >>> >>some >> >> >>>existing VPython programs that used explicit Numeric >>> >>> >>capabilities may >> >> >>>break due to some incompatibilities between Numeric and Numarray. >>> >>>The right thing to do is to revise Visual to use Numpy, which >>> >>> >>is the >> >> >>>designated to-be-supported replacement for both Numeric and >>> >>> >>Numarray. I >> >> >>>do not know how much work will be required to do this. >>> >>>Bruce Sherwood >>> >>> >>> >>I seem to recall that a Numeric-to-Numpy script was once available. >>I don't know its current status. >>I also don't know if it would work with vpython. >> >>I'm pretty busy right now, but I'll guess that Bruce is busier. >>This weekend I'll try to find some time to dig a little deeper >>into this >>problem. >> >>-gary >> >>----------------------------------------------------------------- >>-------- >>Take Surveys. Earn Cash. Influence the Future of IT >>Join SourceForge.net's Techsay panel and you'll get the chance >>to share your >>opinions on IT & business topics through brief surveys -- and >>earn cash >>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>_______________________________________________ >>Visualpython-users mailing list >>Vis...@li... >>https://lists.sourceforge.net/lists/listinfo/visualpython-users >> >> >> > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys -- and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >Visualpython-users mailing list >Vis...@li... >https://lists.sourceforge.net/lists/listinfo/visualpython-users > > |
|
From: Eric A. <Ay...@ma...> - 2006-10-07 18:04:03
|
I (or my department if I can find a way to get a receipt for the software "purchase") will contribute $50 towards a bounty for a Mac OSX non-fink non-X11 "universal" standard-installer-package version of vpython. Something I could pass out to students on CD's with "double-click here" install instructions... and I know Bruce just well enough that "To Bruce Sherwood's satisfaction" is sufficient for me, too. At present, I use Parallels Desktop running Ubuntu to demo vpython on this Mac in classes, rather than corrupt my system with fink... -ea ----------------------------------------------------------------- Dr. Eric Ayars Assistant Professor of Physics California State University, Chico ay...@ma... On Oct 6, 2006, at 2:15 PM, Scott David Daniels wrote: > Bruce Sherwood wrote: >> There are two rather different routes toward supporting Visual on >> Python >> 2.5. The better route is to work with Visual 4, since that's what >> we all >> want to use, given its greatly enhanced graphics capabilities. >> However, >> if changing to Numpy doesn't require much effort (I have no idea), it >> would be good to put that into Visual 3, because there are some >> serious >> problems with Visual 4, the most worrisome being the following >> (extracted from summary in Recent Developments section of >> vpython.org): >> >> 1) Mouse interactions on Windows, including >> scene.mouse.getclick(), >> are associated with crashes. A tight loop without a rate() >> statement >> may crash or be hard to kill. >> >> 2) Some animations run in a jerky manner due to slow rendering of >> the scene. The program gas.py is an example. The issue may be >> that >> the detail level on spheres needs to be decreased. >> >> 3) Graphing (from visual.graph import *) works well for many >> simple >> uses, but if the axes must be continually adjusted it can be very >> slow. If you know the extent of your variables and can specify >> xmax >> and ymax for the graph, the graphing is very fast. >> >> I feel competent to deal with 3) and probably with 2) if it is just a >> matter of reducing the level of detail. But I don't feel competent to >> track down and fix problem 1), which might well involve tricky >> multithread issues. (For the graphing issue it is necessary to do >> some >> work analogous to some coding I've already experimented with, >> having to >> do with supporting different scale factors in x and y.) >> >> And there's the long-standing issue of finding someone to write a Mac >> version of the platform-specific files in Visual that handle >> creating a >> window and handling mouse and keyset events, so that there could be a >> Mac-native version of VPython, not dependent on running X11 and >> fink and >> difficult opaque installs. Hugh Fisher in Australia indicated >> recently >> that he might be able to get free to do this in the near future. >> >> If we could get over the hump of having a usable Visual 4 for Windows >> and Mac (as far as I know it works fine on Linux), perhaps we would >> attract some new developers who could contribute, because Visual 4 >> comes >> much closer to offering "professional-grade" graphics likely to >> interest >> people in the graphics area. > > You might consider offering a bounty for those projects (A: mouse > interaction, B: run on OS/X, C: move 4 to Numpy, D: move 3 to Numpy). > You might even solicit contributions to the bounty from your users. > Slightly tricky parts would be definitions of "acceptably solved", > though Bruce Sherwood's name has been associated with the project > for long enough that "to his satisfaction" may be an adequate > definition. I'd be interested in working on the problem, but need > to keep a modicum of cash coming in, and you might well find someone > with the right mix of ability and cheap time to work on it. > > -- Scott David Daniels > Sco...@Ac... > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users |
|
From: Bruce S. <Bru...@nc...> - 2006-10-07 22:14:24
|
Just to try to keep the record straight: Isn't it the case that fink touches ONLY its own directory, /sw? I don't see how it can "corrupt" the system. Mind you, I do very much want to eliminate dependence on fink and X11, for a host of good reasons, most especially because I keep getting notes from people saying they were unable to fight their way through a fink-based installation. One of the problems is that I and others have run into a problem that isn't fink's fault but which comes up in the fink/X11 context, which is that the Apple installer for X11 and/or Xcode fails to work properly, with no indication of the failure, and merely running the Apple installer again fixes the problem (not something that would occur to most users). So there's plenty of blame to go around in that non-user-friendly environment. Bruce Eric Ayars wrote: >I (or my department if I can find a way to get a receipt for the >software "purchase") will contribute $50 towards a bounty for a Mac >OSX non-fink non-X11 "universal" standard-installer-package version >of vpython. Something I could pass out to students on CD's with >"double-click here" install instructions... and I know Bruce just >well enough that "To Bruce Sherwood's satisfaction" is sufficient for >me, too. > >At present, I use Parallels Desktop running Ubuntu to demo vpython on >this Mac in classes, rather than corrupt my system with fink... > >-ea > >----------------------------------------------------------------- >Dr. Eric Ayars >Assistant Professor of Physics >California State University, Chico >ay...@ma... > > >On Oct 6, 2006, at 2:15 PM, Scott David Daniels wrote: > > > >>Bruce Sherwood wrote: >> >> >>>There are two rather different routes toward supporting Visual on >>>Python >>>2.5. The better route is to work with Visual 4, since that's what >>>we all >>>want to use, given its greatly enhanced graphics capabilities. >>>However, >>>if changing to Numpy doesn't require much effort (I have no idea), it >>>would be good to put that into Visual 3, because there are some >>>serious >>>problems with Visual 4, the most worrisome being the following >>>(extracted from summary in Recent Developments section of >>>vpython.org): >>> >>> 1) Mouse interactions on Windows, including >>>scene.mouse.getclick(), >>> are associated with crashes. A tight loop without a rate() >>>statement >>> may crash or be hard to kill. >>> >>> 2) Some animations run in a jerky manner due to slow rendering of >>> the scene. The program gas.py is an example. The issue may be >>>that >>> the detail level on spheres needs to be decreased. >>> >>> 3) Graphing (from visual.graph import *) works well for many >>>simple >>> uses, but if the axes must be continually adjusted it can be very >>> slow. If you know the extent of your variables and can specify >>>xmax >>> and ymax for the graph, the graphing is very fast. >>> >>>I feel competent to deal with 3) and probably with 2) if it is just a >>>matter of reducing the level of detail. But I don't feel competent to >>>track down and fix problem 1), which might well involve tricky >>>multithread issues. (For the graphing issue it is necessary to do >>>some >>>work analogous to some coding I've already experimented with, >>>having to >>>do with supporting different scale factors in x and y.) >>> >>>And there's the long-standing issue of finding someone to write a Mac >>>version of the platform-specific files in Visual that handle >>>creating a >>>window and handling mouse and keyset events, so that there could be a >>>Mac-native version of VPython, not dependent on running X11 and >>>fink and >>>difficult opaque installs. Hugh Fisher in Australia indicated >>>recently >>>that he might be able to get free to do this in the near future. >>> >>>If we could get over the hump of having a usable Visual 4 for Windows >>>and Mac (as far as I know it works fine on Linux), perhaps we would >>>attract some new developers who could contribute, because Visual 4 >>>comes >>>much closer to offering "professional-grade" graphics likely to >>>interest >>>people in the graphics area. >>> >>> >>You might consider offering a bounty for those projects (A: mouse >>interaction, B: run on OS/X, C: move 4 to Numpy, D: move 3 to Numpy). >>You might even solicit contributions to the bounty from your users. >>Slightly tricky parts would be definitions of "acceptably solved", >>though Bruce Sherwood's name has been associated with the project >>for long enough that "to his satisfaction" may be an adequate >>definition. I'd be interested in working on the problem, but need >>to keep a modicum of cash coming in, and you might well find someone >>with the right mix of ability and cheap time to work on it. >> >>-- Scott David Daniels >>Sco...@Ac... >> >> >>---------------------------------------------------------------------- >>--- >>Take Surveys. Earn Cash. Influence the Future of IT >>Join SourceForge.net's Techsay panel and you'll get the chance to >>share your >>opinions on IT & business topics through brief surveys -- and earn >>cash >>http://www.techsay.com/default.php? >>page=join.php&p=sourceforge&CID=DEVDEV >>_______________________________________________ >>Visualpython-users mailing list >>Vis...@li... >>https://lists.sourceforge.net/lists/listinfo/visualpython-users >> >> > > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys -- and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >Visualpython-users mailing list >Vis...@li... >https://lists.sourceforge.net/lists/listinfo/visualpython-users > > |
|
From: Arthur S. <ajs...@op...> - 2006-10-08 14:06:05
|
On Sat, 2006-10-07 at 16:14 -0600, Bruce Sherwood wrote: > Just to try to keep the record straight: Isn't it the case that fink > touches ONLY its own directory, /sw? I don't see how it can "corrupt" > the system. Also to keep the record straight - there is *no* incompatibility (of which I am aware) between Python2.5 and VPython built with either Numeric or numarray. The issue regarding numpy compatibility is significant since numpy is becoming the Python standard for multi-dimensional array processing, so that, for example, the lives of educational projects like courses such as: http://www.physics.cornell.edu/sethna/teaching/ComputationalMethods/index.html which use scipy (in which numpy is core) and which also use VPython are becoming more complicated than it might be. But to maintain perspective - the numpy issue is not an immediate crisis, provided that the maintainers of the Windows distro, the Debian distro, the fink distro, etc. proceed to make binary distributions against Python2.5 available. So that maybe the short-term focus should be shifted there. I am concerned about the perception regarding VPython should there be a significant delay in making Python2.5 binaries available, now that Python2.5 is itself final. I will see if I can figure out who might be appropriate to contact to urge that the ubuntu (debian based) distribution make a Python2.5 package available. Bruce - who has been doing the Windows distro?? Mac - don't know. Art |
|
From: Bruce S. <Bru...@nc...> - 2006-10-08 17:21:06
|
If I remember correctly, I found that some example programs that do explicit numeric operations such as stars.py and gas.py did not in fact work with numarray, due to some changes in external syntax (thought it's possible that only minor changes would have been necessary). Unfortunately, when I tried just now to check this memory, I find to my surprise that if I install VPython (either version 3 or 4) and elect during installation to install only numarray, not numeric, I can't run any programs (the error message is that the crayola module is missing). I don't when this feature got broken. I tried 3.2.8 and 3.2.9 and the latest 4. I'm the one who has been packaging the Windows distribution, and sometimes I've created the Linux package (which others then repackage for particular flavors of Linux). Martin Costabel has been making the fink packages for the Mac. At the moment the Windows build wants both numeric and numarray to be already installed (no longer a possibility with Python 2.5) but then attempts to create an installer that allows the end user to choose (though clearly that feature is currently broken somehow). Bruce Arthur Siegel wrote: >On Sat, 2006-10-07 at 16:14 -0600, Bruce Sherwood wrote: > > >>Just to try to keep the record straight: Isn't it the case that fink >>touches ONLY its own directory, /sw? I don't see how it can "corrupt" >>the system. >> >> > >Also to keep the record straight - there is *no* incompatibility (of >which I am aware) between Python2.5 and VPython built with either >Numeric or numarray. > >The issue regarding numpy compatibility is significant since numpy is >becoming the Python standard for multi-dimensional array processing, so >that, for example, the lives of educational projects like courses such >as: > >http://www.physics.cornell.edu/sethna/teaching/ComputationalMethods/index.html > >which use scipy (in which numpy is core) and which also use VPython are >becoming more complicated than it might be. > >But to maintain perspective - the numpy issue is not an immediate >crisis, provided that the maintainers of the Windows distro, the Debian >distro, the fink distro, etc. proceed to make binary distributions >against Python2.5 available. So that maybe the short-term focus should >be shifted there. I am concerned about the perception regarding VPython >should there be a significant delay in making Python2.5 binaries >available, now that Python2.5 is itself final. > >I will see if I can figure out who might be appropriate to contact to >urge that the ubuntu (debian based) distribution make a Python2.5 >package available. > >Bruce - > >who has been doing the Windows distro?? > >Mac - don't know. > >Art > > > |
|
From: Arthur S. <ajs...@op...> - 2006-10-08 15:03:37
|
On Sun, 2006-10-08 at 10:05 -0400, Arthur Siegel wrote: > So that maybe the short-term focus should > be shifted there. I am concerned about the perception regarding VPython > should there be a significant delay in making Python2.5 binaries > available, now that Python2.5 is itself final. to add - IMO, binaries for Python2.5 against the stable 3.xxx branch should be maintained and made available until such time as the known bugs against the 4.xxx branch get sorted out. Among other reasons, it is my perception that the Debian folks are quite conservative about what they package/support so that an official Debian distro against 3.xxx and Python2.5 is a more feasible request than one against 4.xxx. Art |
|
From: Gary P. <gp...@ri...> - 2006-10-08 19:22:00
|
> On Sun, 2006-10-08 at 10:05 -0400, Arthur Siegel wrote: > >> So that maybe the short-term focus should >> be shifted there. I am concerned about the perception regarding VPython >> should there be a significant delay in making Python2.5 binaries >> available, now that Python2.5 is itself final. > > to add - > > IMO, binaries for Python2.5 against the stable 3.xxx branch should be > maintained and made available until such time as the known bugs against > the 4.xxx branch get sorted out. I'd like to help with this effort, but I might not be able to run fast enough to keep up. The only thing I can add right now is a reminder to be careful about license issues. I'm far from knowledgeable about this, but as I understand it, the vpython license is more BSD like than GPL, and GPL is more restrictive. I may be wrong. If we add stuff, we need to be careful about accidentally making the whole thing GPL. I think. |
|
From: Bruce S. <Bru...@nc...> - 2006-10-08 21:45:35
|
I agree that it is a priority to be able to run Visual 3 on Python 2.5. I'm guessing that the quickest way to do that would be to comment out references in Visual to Numeric (which isn't available for Python 2.5 but is required to be present for Visual to build, at least on Windows) and go with NumArray (which should work with Visual, even though I just discovered that it doesn't seem to). However, this is a less desirable path than replacing both Numeric and NumArray with the new NumPy. This assumes that the amount of work required to make a stable Visual 4 with NumPy will take significantly more time than making a stable Visual 3 with NumPy. For the information of those interested in working on Visual, using source code from sourceforge.net: The files HACKING.txt and INSTALL.txt contain instructions on what tools you need to have on your computer in order to be able to build from source, and instructions on how to use those tools. If you have questions, feel free to ask. Individual files in the project typically have pretty good commentary, but there isn't an overview document that explains how the pieces go together, which together with the complexity of Visual does make it difficult to get started. Bruce Arthur Siegel wrote: >On Sun, 2006-10-08 at 10:05 -0400, Arthur Siegel wrote: > > > >>So that maybe the short-term focus should >>be shifted there. I am concerned about the perception regarding VPython >>should there be a significant delay in making Python2.5 binaries >>available, now that Python2.5 is itself final. >> >> > >to add - > >IMO, binaries for Python2.5 against the stable 3.xxx branch should be >maintained and made available until such time as the known bugs against >the 4.xxx branch get sorted out. > >Among other reasons, it is my perception that the Debian folks are quite >conservative about what they package/support so that an official Debian >distro against 3.xxx and Python2.5 is a more feasible request than one >against 4.xxx. > > >Art > > > |
|
From: Arthur S. <ajs...@op...> - 2006-10-08 19:59:30
|
On Sun, 2006-10-08 at 15:21 -0400, Gary Pajer wrote: > I'd like to help with this effort, but I might not be able to run fast > enough to keep up. The only thing I can add right now is a reminder to be > careful about license issues. Not sure I see an issue since I am really not proposing any changes to anything. Just like to help the project - if I can - get exactly where it already is vs Python2.4 relative to Python2.5. In fact what I seem to be proposing is a VPython Classic distribution - i.e., 3.2.9 with Numeric, just built against Python2.5. Talk about not being able to keep up, though ... my latest conclusion is that the only compatibility issue that might rise using Numeric and Python2.5 is on 64 bit machines since there are issues - I think both in Numeric and in VPython itself - in regard to conforming to the Pep353 C API change. http://www.python.org/dev/peps/pep-0353/ My starting point is that most of this is mostly over-my-head. But as it happens, getting into this sorta fits with an agenda I have to get conversant with C++, specifically with respect to Python extension building - and I always find it better to have something real to sink my teeth into when undertaking this kind of learning effort. So I will keep plugging. Art > I'm far from knowledgeable about this, but > as I understand it, the vpython license is more BSD like than GPL, and GPL > is more restrictive. I may be wrong. If we add stuff, we need to be > careful about accidentally making the whole thing GPL. I think. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users |
|
From: Arthur S. <ajs...@op...> - 2006-10-08 22:45:03
|
On Sun, 2006-10-08 at 15:45 -0600, Bruce Sherwood wrote: > I agree that it is a priority to be able to run Visual 3 on Python 2.5. > > I'm guessing that the quickest way to do that would be to comment out > references in Visual to Numeric (which isn't available for Python 2.5 I'm confused why it is you have that impression. Numeric's C can compile against Python2.5, and its Python code is fully compatible with Python2.5. I have compiled it successfully today on Linux. In fact, in my mind it is more stable and mature than numarray. It is my understanding that numarray was developed to optimize enormous arrays confronted in analyzing astronomical data - astronomical arrays ;) - and is sub-optimum for the earthbound arrays I think is more typical in the use of vpython. It is also my impression that numarray never fully matured, i.e. development was cut short when it was agreed that numpy would become the standard. So that it is my opinion that we should be concentrating on a Numeric based distribution against Python2.5. Though it is also true I am not understanding what the problem you see in keeping things as they are, and using either/or. To me this is rather straight forward - I see no reason why the existing vpython 3.xxx should have any problems with Python2.5 other than the one I had mentioned on 64 bit machines - which I am assuming is not a practical problem for most. Python is generally conservative in its development philosophy. A new release generally means new features. Great attention is paid to not breaking backward compatibility. The change in the C API to accommodate 64 bit machines is a rare exception, except that it was done in such a way that other than possibly a warning message that wasn't there before, things whould continue to run fine as they were on your standard PC. With my general "unless I am missing something" disclaimer, I think we are making this more of an issue than it should be. My problem is that I don't have the commercial tools necessary to do a Windows compilation to try to understand what you are running into. But frankly I suspect it is something other than what you think it is. Art > but is required to be present for Visual to build, at least on Windows) > and go with NumArray (which should work with Visual, even though I just > discovered that it doesn't seem to). However, this is a less desirable > path than replacing both Numeric and NumArray with the new NumPy. > > This assumes that the amount of work required to make a stable Visual 4 > with NumPy will take significantly more time than making a stable Visual > 3 with NumPy. > > For the information of those interested in working on Visual, using > source code from sourceforge.net: The files HACKING.txt and INSTALL.txt > contain instructions on what tools you need to have on your computer in > order to be able to build from source, and instructions on how to use > those tools. If you have questions, feel free to ask. > > Individual files in the project typically have pretty good commentary, > but there isn't an overview document that explains how the pieces go > together, which together with the complexity of Visual does make it > difficult to get started. > > Bruce > > Arthur Siegel wrote: > > >On Sun, 2006-10-08 at 10:05 -0400, Arthur Siegel wrote: > > > > > > > >>So that maybe the short-term focus should > >>be shifted there. I am concerned about the perception regarding VPython > >>should there be a significant delay in making Python2.5 binaries > >>available, now that Python2.5 is itself final. > >> > >> > > > >to add - > > > >IMO, binaries for Python2.5 against the stable 3.xxx branch should be > >maintained and made available until such time as the known bugs against > >the 4.xxx branch get sorted out. > > > >Among other reasons, it is my perception that the Debian folks are quite > >conservative about what they package/support so that an official Debian > >distro against 3.xxx and Python2.5 is a more feasible request than one > >against 4.xxx. > > > > > >Art > > > > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users |
|
From: Scott D. D. <Sco...@Ac...> - 2006-10-06 21:14:43
|
Bruce Sherwood wrote: > There are two rather different routes toward supporting Visual on Python > 2.5. The better route is to work with Visual 4, since that's what we all > want to use, given its greatly enhanced graphics capabilities. However, > if changing to Numpy doesn't require much effort (I have no idea), it > would be good to put that into Visual 3, because there are some serious > problems with Visual 4, the most worrisome being the following > (extracted from summary in Recent Developments section of vpython.org): > > 1) Mouse interactions on Windows, including scene.mouse.getclick(), > are associated with crashes. A tight loop without a rate() statement > may crash or be hard to kill. > > 2) Some animations run in a jerky manner due to slow rendering of > the scene. The program gas.py is an example. The issue may be that > the detail level on spheres needs to be decreased. > > 3) Graphing (from visual.graph import *) works well for many simple > uses, but if the axes must be continually adjusted it can be very > slow. If you know the extent of your variables and can specify xmax > and ymax for the graph, the graphing is very fast. > > I feel competent to deal with 3) and probably with 2) if it is just a > matter of reducing the level of detail. But I don't feel competent to > track down and fix problem 1), which might well involve tricky > multithread issues. (For the graphing issue it is necessary to do some > work analogous to some coding I've already experimented with, having to > do with supporting different scale factors in x and y.) > > And there's the long-standing issue of finding someone to write a Mac > version of the platform-specific files in Visual that handle creating a > window and handling mouse and keyset events, so that there could be a > Mac-native version of VPython, not dependent on running X11 and fink and > difficult opaque installs. Hugh Fisher in Australia indicated recently > that he might be able to get free to do this in the near future. > > If we could get over the hump of having a usable Visual 4 for Windows > and Mac (as far as I know it works fine on Linux), perhaps we would > attract some new developers who could contribute, because Visual 4 comes > much closer to offering "professional-grade" graphics likely to interest > people in the graphics area. You might consider offering a bounty for those projects (A: mouse interaction, B: run on OS/X, C: move 4 to Numpy, D: move 3 to Numpy). You might even solicit contributions to the bounty from your users. Slightly tricky parts would be definitions of "acceptably solved", though Bruce Sherwood's name has been associated with the project for long enough that "to his satisfaction" may be an adequate definition. I'd be interested in working on the problem, but need to keep a modicum of cash coming in, and you might well find someone with the right mix of ability and cheap time to work on it. -- Scott David Daniels Sco...@Ac... |
|
From: Jonathan B. <jbr...@ea...> - 2006-10-07 21:47:32
|
On Fri, 2006-10-06 at 12:40 -0600, Bruce Sherwood wrote: > Questions have been asked about Visual for Python 2.5. A significant > hurdle to overcome is that there is not and will not be a version of > Numeric for Python 2.5 (the last to be made was for Python 2.4). Its > successor Numarray does exist for Python 2.5 but is likely to be the > last, as the download instructions say "Use Numpy!" The last time that I looked, the Numpy documentation was only available for a fee. That is why Visual was not extended to support it last summer. At any rate, the person(s) who decide to add support for Numpy to VPython should see below. > Thanks to Jonathan > Brandmeyer's work, Visual can be compiled for Numarray, but some > existing VPython programs that used explicit Numeric capabilities may > break due to some incompatibilities between Numeric and Numarray. > > The right thing to do is to revise Visual to use Numpy, which is the > designated to-be-supported replacement for both Numeric and Numarray. I > do not know how much work will be required to do this. The revision effort should not be too difficult, as there is an abstraction layer for Numeric/Numarray in VPython. Basically, at startup-time, a set of function pointers are initialized that refer to either the Numarray or Numeric implementations. Additionally, Boost.Python support for the two libs is selected at run-time. The affected files are: VPython 3.x: src/num_util_impl_numeric.cpp src/num_util_impl_numarray.cpp src/num_util.cpp include/num_util_impl.hpp include/num_util.hpp The VPython 4.x files are setup in exactly the same way, except that they are found in src/python and include/python. See also site-packages/visual/array_backend.py in both versions, although I think that there is a cleaner way to go about what this file does. Lastly, there are some configure script elements that would need to be updated in acinclude.m4 (specifically, VISUAL_NUMERICLIBS). HTH, -Jonathan |
|
From: Bruce S. <Bru...@nc...> - 2006-10-07 22:09:49
|
Thanks much, Jonathan. This information is a big help. Bruce Jonathan Brandmeyer wrote: >On Fri, 2006-10-06 at 12:40 -0600, Bruce Sherwood wrote: > > >>Questions have been asked about Visual for Python 2.5. A significant >>hurdle to overcome is that there is not and will not be a version of >>Numeric for Python 2.5 (the last to be made was for Python 2.4). Its >>successor Numarray does exist for Python 2.5 but is likely to be the >>last, as the download instructions say "Use Numpy!" >> >> > >The last time that I looked, the Numpy documentation was only available >for a fee. That is why Visual was not extended to support it last >summer. At any rate, the person(s) who decide to add support for Numpy >to VPython should see below. > > > >> Thanks to Jonathan >>Brandmeyer's work, Visual can be compiled for Numarray, but some >>existing VPython programs that used explicit Numeric capabilities may >>break due to some incompatibilities between Numeric and Numarray. >> >>The right thing to do is to revise Visual to use Numpy, which is the >>designated to-be-supported replacement for both Numeric and Numarray. I >>do not know how much work will be required to do this. >> >> > >The revision effort should not be too difficult, as there is an >abstraction layer for Numeric/Numarray in VPython. Basically, at >startup-time, a set of function pointers are initialized that refer to >either the Numarray or Numeric implementations. Additionally, >Boost.Python support for the two libs is selected at run-time. > >The affected files are: >VPython 3.x: >src/num_util_impl_numeric.cpp >src/num_util_impl_numarray.cpp >src/num_util.cpp >include/num_util_impl.hpp >include/num_util.hpp > >The VPython 4.x files are setup in exactly the same way, except that >they are found in src/python and include/python. > >See also site-packages/visual/array_backend.py in both versions, >although I think that there is a cleaner way to go about what this file >does. > >Lastly, there are some configure script elements that would need to be >updated in acinclude.m4 (specifically, VISUAL_NUMERICLIBS). > >HTH, >-Jonathan > > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys -- and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >Visualpython-users mailing list >Vis...@li... >https://lists.sourceforge.net/lists/listinfo/visualpython-users > > |
|
From: Arthur S. <ajs...@op...> - 2006-10-08 00:45:49
|
Hi Jonathan - I spent some (frustrating) time with this today. Am I correct that num_util.h and num_util.cpp are those of Phil Austin @ Univ of British Columbia? http://www.eos.ubc.ca/research/clouds/software/pythonlibs/num_util/num_util_release2/ If so, there is a new version targeting Numpy, as per the above link. Except that I can't even get it to compile and run the tests correctly. Choking on `intp` types and other places. Grrrr... Numpy is moving fast toward a 1.0 release and I have to wonder whether the num_util code is incompatible with the latest Numpy. Or else I am doing something stupid. Meanwhile I learn more when I get in this kind of trouble than when things go smoothly. So I'm learning.... Art On Sat, 2006-10-07 at 17:47 -0400, Jonathan Brandmeyer wrote: > On Fri, 2006-10-06 at 12:40 -0600, Bruce Sherwood wrote: > > Questions have been asked about Visual for Python 2.5. A significant > > hurdle to overcome is that there is not and will not be a version of > > Numeric for Python 2.5 (the last to be made was for Python 2.4). Its > > successor Numarray does exist for Python 2.5 but is likely to be the > > last, as the download instructions say "Use Numpy!" > > The last time that I looked, the Numpy documentation was only available > for a fee. That is why Visual was not extended to support it last > summer. At any rate, the person(s) who decide to add support for Numpy > to VPython should see below. > > > Thanks to Jonathan > > Brandmeyer's work, Visual can be compiled for Numarray, but some > > existing VPython programs that used explicit Numeric capabilities may > > break due to some incompatibilities between Numeric and Numarray. > > > > The right thing to do is to revise Visual to use Numpy, which is the > > designated to-be-supported replacement for both Numeric and Numarray. I > > do not know how much work will be required to do this. > > The revision effort should not be too difficult, as there is an > abstraction layer for Numeric/Numarray in VPython. Basically, at > startup-time, a set of function pointers are initialized that refer to > either the Numarray or Numeric implementations. Additionally, > Boost.Python support for the two libs is selected at run-time. > > The affected files are: > VPython 3.x: > src/num_util_impl_numeric.cpp > src/num_util_impl_numarray.cpp > src/num_util.cpp > include/num_util_impl.hpp > include/num_util.hpp > > The VPython 4.x files are setup in exactly the same way, except that > they are found in src/python and include/python. > > See also site-packages/visual/array_backend.py in both versions, > although I think that there is a cleaner way to go about what this file > does. > > Lastly, there are some configure script elements that would need to be > updated in acinclude.m4 (specifically, VISUAL_NUMERICLIBS). > > HTH, > -Jonathan > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users |
|
From: Jonathan B. <jbr...@ea...> - 2006-10-08 02:48:56
|
On Sat, 2006-10-07 at 20:37 -0400, Arthur Siegel wrote: > Hi Jonathan - > > I spent some (frustrating) time with this today. > > Am I correct that num_util.h and num_util.cpp are those > of Phil Austin @ Univ of British Columbia? > > http://www.eos.ubc.ca/research/clouds/software/pythonlibs/num_util/num_util_release2/ The num_util code in VPython is _distantly_ descended from Phil Austin's original work. However, an intrepid coder may be able to learn enough by reading his code to port the necessary changes to VPython. -Jonathan > If so, there is a new version targeting Numpy, as per the above link. > > Except that I can't even get it to compile and run the tests correctly. > > Choking on `intp` types and other places. > > Grrrr... > > Numpy is moving fast toward a 1.0 release and I have to wonder whether > the num_util code is incompatible with the latest Numpy. > > Or else I am doing something stupid. > > Meanwhile I learn more when I get in this kind of trouble than when > things go smoothly. > > So I'm learning.... > > Art > > On Sat, 2006-10-07 at 17:47 -0400, Jonathan Brandmeyer wrote: > > On Fri, 2006-10-06 at 12:40 -0600, Bruce Sherwood wrote: > > > Questions have been asked about Visual for Python 2.5. A significant > > > hurdle to overcome is that there is not and will not be a version of > > > Numeric for Python 2.5 (the last to be made was for Python 2.4). Its > > > successor Numarray does exist for Python 2.5 but is likely to be the > > > last, as the download instructions say "Use Numpy!" > > > > The last time that I looked, the Numpy documentation was only available > > for a fee. That is why Visual was not extended to support it last > > summer. At any rate, the person(s) who decide to add support for Numpy > > to VPython should see below. > > > > > Thanks to Jonathan > > > Brandmeyer's work, Visual can be compiled for Numarray, but some > > > existing VPython programs that used explicit Numeric capabilities may > > > break due to some incompatibilities between Numeric and Numarray. > > > > > > The right thing to do is to revise Visual to use Numpy, which is the > > > designated to-be-supported replacement for both Numeric and Numarray. I > > > do not know how much work will be required to do this. > > > > The revision effort should not be too difficult, as there is an > > abstraction layer for Numeric/Numarray in VPython. Basically, at > > startup-time, a set of function pointers are initialized that refer to > > either the Numarray or Numeric implementations. Additionally, > > Boost.Python support for the two libs is selected at run-time. > > > > The affected files are: > > VPython 3.x: > > src/num_util_impl_numeric.cpp > > src/num_util_impl_numarray.cpp > > src/num_util.cpp > > include/num_util_impl.hpp > > include/num_util.hpp > > > > The VPython 4.x files are setup in exactly the same way, except that > > they are found in src/python and include/python. > > > > See also site-packages/visual/array_backend.py in both versions, > > although I think that there is a cleaner way to go about what this file > > does. > > > > Lastly, there are some configure script elements that would need to be > > updated in acinclude.m4 (specifically, VISUAL_NUMERICLIBS). > > > > HTH, > > -Jonathan > > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > opinions on IT & business topics through brief surveys -- and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Visualpython-users mailing list > > Vis...@li... > > https://lists.sourceforge.net/lists/listinfo/visualpython-users > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users |
|
From: Bruce S. <Bru...@nc...> - 2006-10-08 23:40:37
|
You're right, I'm probably thinking about this wrong. I had for no particularly good reason felt that the fact that there is no (binary) version of Numeric for Python2.5 on Windows was a show-stopper. But as you say, we could just compile it for Windows from source. Assuming there are no problems with that, it's surely the quickest route to Python 2.5. Visual on Windows is compiled not with commercial tools but with the Linux/Unix-like open source tools MinGW and MSYS (see HACKING.txt and INSTALL.txt in the Visual files). Presumably Numeric can be built using these tools. I hope. That of course doesn't absolve us from the responsibility of moving to NumPy with all deliberate speed. I guess one thing contributing to my blindness was that it seemed a bit ghoulish to resurrect a decently and honorably buried Numeric on Windows. Bruce Arthur Siegel wrote: >On Sun, 2006-10-08 at 15:45 -0600, Bruce Sherwood wrote: > > >>I agree that it is a priority to be able to run Visual 3 on Python 2.5. >> >>I'm guessing that the quickest way to do that would be to comment out >>references in Visual to Numeric (which isn't available for Python 2.5 >> >> > >I'm confused why it is you have that impression. > >Numeric's C can compile against Python2.5, and its Python code is fully >compatible with Python2.5. > >I have compiled it successfully today on Linux. > >In fact, in my mind it is more stable and mature than numarray. It is >my understanding that numarray was developed to optimize enormous arrays >confronted in analyzing astronomical data - astronomical arrays ;) - >and is sub-optimum for the earthbound arrays I think is more typical in >the use of vpython. It is also my impression that numarray never fully >matured, i.e. development was cut short when it was agreed that numpy >would become the standard. > >So that it is my opinion that we should be concentrating on a Numeric >based distribution against Python2.5. > >Though it is also true I am not understanding what the problem you see >in keeping things as they are, and using either/or. > >To me this is rather straight forward - I see no reason why the existing >vpython 3.xxx should have any problems with Python2.5 other than the one >I had mentioned on 64 bit machines - which I am assuming is not a >practical problem for most. > >Python is generally conservative in its development philosophy. A new >release generally means new features. Great attention is paid to not >breaking backward compatibility. The change in the C API to accommodate >64 bit machines is a rare exception, except that it was done in such a >way that other than possibly a warning message that wasn't there before, >things whould continue to run fine as they were on your standard PC. > >With my general "unless I am missing something" disclaimer, I think we >are making this more of an issue than it should be. > >My problem is that I don't have the commercial tools necessary to do a >Windows compilation to try to understand what you are running into. But >frankly I suspect it is something other than what you think it is. > >Art > > > >>but is required to be present for Visual to build, at least on Windows) >>and go with NumArray (which should work with Visual, even though I just >>discovered that it doesn't seem to). However, this is a less desirable >>path than replacing both Numeric and NumArray with the new NumPy. >> >>This assumes that the amount of work required to make a stable Visual 4 >>with NumPy will take significantly more time than making a stable Visual >>3 with NumPy. >> >>For the information of those interested in working on Visual, using >>source code from sourceforge.net: The files HACKING.txt and INSTALL.txt >>contain instructions on what tools you need to have on your computer in >>order to be able to build from source, and instructions on how to use >>those tools. If you have questions, feel free to ask. >> >>Individual files in the project typically have pretty good commentary, >>but there isn't an overview document that explains how the pieces go >>together, which together with the complexity of Visual does make it >>difficult to get started. >> >>Bruce >> >>Arthur Siegel wrote: >> >> >> >>>On Sun, 2006-10-08 at 10:05 -0400, Arthur Siegel wrote: >>> >>> >>> >>> >>> >>>>So that maybe the short-term focus should >>>>be shifted there. I am concerned about the perception regarding VPython >>>>should there be a significant delay in making Python2.5 binaries >>>>available, now that Python2.5 is itself final. >>>> >>>> >>>> >>>> >>>to add - >>> >>>IMO, binaries for Python2.5 against the stable 3.xxx branch should be >>>maintained and made available until such time as the known bugs against >>>the 4.xxx branch get sorted out. >>> >>>Among other reasons, it is my perception that the Debian folks are quite >>>conservative about what they package/support so that an official Debian >>>distro against 3.xxx and Python2.5 is a more feasible request than one >>>against 4.xxx. >>> >>> >>>Art >>> >>> >>> >>> >>> >>------------------------------------------------------------------------- >>Take Surveys. Earn Cash. Influence the Future of IT >>Join SourceForge.net's Techsay panel and you'll get the chance to share your >>opinions on IT & business topics through brief surveys -- and earn cash >>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>_______________________________________________ >>Visualpython-users mailing list >>Vis...@li... >>https://lists.sourceforge.net/lists/listinfo/visualpython-users >> >> > > > |
|
From: Gary <pa...@in...> - 2006-10-09 02:29:39
|
Bruce Sherwood wrote: > You're right, I'm probably thinking about this wrong. I had for no > particularly good reason felt that the fact that there is no (binary) > version of Numeric for Python2.5 on Windows was a show-stopper. But as > you say, we could just compile it for Windows from source. Assuming > there are no problems with that, it's surely the quickest route to > Python 2.5. > I hadn't thought of that either, and you might thing I would have... for a time I had authored and maintained the wiki entry on compiling numpy for Windows. (I've since been replaced.) The hard part was finding the right version of MinGW. The current version didn't seem to work; one had to use an earlier version. Aside from that, it was pretty easy. -g > Visual on Windows is compiled not with commercial tools but with the > Linux/Unix-like open source tools MinGW and MSYS (see HACKING.txt and > INSTALL.txt in the Visual files). Presumably Numeric can be built using > these tools. I hope. > > That of course doesn't absolve us from the responsibility of moving to > NumPy with all deliberate speed. > > I guess one thing contributing to my blindness was that it seemed a bit > ghoulish to resurrect a decently and honorably buried Numeric on Windows. > > Bruce > > Arthur Siegel wrote: > > >> On Sun, 2006-10-08 at 15:45 -0600, Bruce Sherwood wrote: >> >> >> >>> I agree that it is a priority to be able to run Visual 3 on Python 2.5. >>> >>> I'm guessing that the quickest way to do that would be to comment out >>> references in Visual to Numeric (which isn't available for Python 2.5 >>> >>> >>> >> I'm confused why it is you have that impression. >> >> Numeric's C can compile against Python2.5, and its Python code is fully >> compatible with Python2.5. >> >> I have compiled it successfully today on Linux. >> >> In fact, in my mind it is more stable and mature than numarray. It is >> my understanding that numarray was developed to optimize enormous arrays >> confronted in analyzing astronomical data - astronomical arrays ;) - >> and is sub-optimum for the earthbound arrays I think is more typical in >> the use of vpython. It is also my impression that numarray never fully >> matured, i.e. development was cut short when it was agreed that numpy >> would become the standard. >> >> So that it is my opinion that we should be concentrating on a Numeric >> based distribution against Python2.5. >> >> Though it is also true I am not understanding what the problem you see >> in keeping things as they are, and using either/or. >> >> To me this is rather straight forward - I see no reason why the existing >> vpython 3.xxx should have any problems with Python2.5 other than the one >> I had mentioned on 64 bit machines - which I am assuming is not a >> practical problem for most. >> >> Python is generally conservative in its development philosophy. A new >> release generally means new features. Great attention is paid to not >> breaking backward compatibility. The change in the C API to accommodate >> 64 bit machines is a rare exception, except that it was done in such a >> way that other than possibly a warning message that wasn't there before, >> things whould continue to run fine as they were on your standard PC. >> >> With my general "unless I am missing something" disclaimer, I think we >> are making this more of an issue than it should be. >> >> My problem is that I don't have the commercial tools necessary to do a >> Windows compilation to try to understand what you are running into. But >> frankly I suspect it is something other than what you think it is. >> >> Art >> >> >> >> >>> but is required to be present for Visual to build, at least on Windows) >>> and go with NumArray (which should work with Visual, even though I just >>> discovered that it doesn't seem to). However, this is a less desirable >>> path than replacing both Numeric and NumArray with the new NumPy. >>> >>> This assumes that the amount of work required to make a stable Visual 4 >>> with NumPy will take significantly more time than making a stable Visual >>> 3 with NumPy. >>> >>> For the information of those interested in working on Visual, using >>> source code from sourceforge.net: The files HACKING.txt and INSTALL.txt >>> contain instructions on what tools you need to have on your computer in >>> order to be able to build from source, and instructions on how to use >>> those tools. If you have questions, feel free to ask. >>> >>> Individual files in the project typically have pretty good commentary, >>> but there isn't an overview document that explains how the pieces go >>> together, which together with the complexity of Visual does make it >>> difficult to get started. >>> >>> Bruce >>> >>> Arthur Siegel wrote: >>> >>> >>> >>> >>>> On Sun, 2006-10-08 at 10:05 -0400, Arthur Siegel wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>>> So that maybe the short-term focus should >>>>> be shifted there. I am concerned about the perception regarding VPython >>>>> should there be a significant delay in making Python2.5 binaries >>>>> available, now that Python2.5 is itself final. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> to add - >>>> >>>> IMO, binaries for Python2.5 against the stable 3.xxx branch should be >>>> maintained and made available until such time as the known bugs against >>>> the 4.xxx branch get sorted out. >>>> >>>> Among other reasons, it is my perception that the Debian folks are quite >>>> conservative about what they package/support so that an official Debian >>>> distro against 3.xxx and Python2.5 is a more feasible request than one >>>> against 4.xxx. >>>> >>>> >>>> Art >>>> >>>> >>>> >>>> >>>> >>>> >>> ------------------------------------------------------------------------- >>> Take Surveys. Earn Cash. Influence the Future of IT >>> Join SourceForge.net's Techsay panel and you'll get the chance to share your >>> opinions on IT & business topics through brief surveys -- and earn cash >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>> _______________________________________________ >>> Visualpython-users mailing list >>> Vis...@li... >>> https://lists.sourceforge.net/lists/listinfo/visualpython-users >>> >>> >>> >> >> >> > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users > > |
|
From: Arthur S. <ajs...@op...> - 2006-10-09 16:53:20
|
On Sat, 2006-10-07 at 20:37 -0400, Arthur Siegel wrote: > Am I correct that num_util.h and num_util.cpp are those > of Phil Austin @ Univ of British Columbia? > > http://www.eos.ubc.ca/research/clouds/software/pythonlibs/num_util/num_util_release2/ > > If so, there is a new version targeting Numpy, as per the above link. > > Except that I can't even get it to compile and run the tests correctly. > > Choking on `intp` types and other places. > > Grrrr... > > Numpy is moving fast toward a 1.0 release and I have to wonder whether > the num_util code is incompatible with the latest Numpy. > > Or else I am doing something stupid. Turns out my instincts were correct, and I was only stupid to the extent that it took be longer than it should have (had I had more background, at least) to realize this. Numpy's include files were in fact changed since Phil released his num_util code for numpy. Following those changes through to the num_util code I now get that code to compile. I guess my strategy is to start from the new num_utils and do a bit of monkey-see, monkey-do, following what changes Jonathan had made to the orignal, making the analogous on the new, and see if I can follow things through from there. Lot's of moving parts though, as we also have the boost libraries in play, and any changes that are happening there to deal with numpy and Python2.5. We'll see. Art |
|
From: Gary P. <gp...@ri...> - 2006-10-09 17:24:37
|
Arthur Siegel wrote: >On Sat, 2006-10-07 at 20:37 -0400, Arthur Siegel wrote: > > > >>Am I correct that num_util.h and num_util.cpp are those >>of Phil Austin @ Univ of British Columbia? >> >> [...] >Numpy's include files were in fact changed since Phil released his >num_util code for numpy. Following those changes through to the >num_util code I now get that code to compile. > This is the comment that sparked my comment on license issues. |
|
From: Arthur S. <ajs...@op...> - 2006-10-09 17:55:20
|
On Mon, 2006-10-09 at 13:24 -0400, Gary Pajer wrote: > >Numpy's include files were in fact changed since Phil released his > >num_util code for numpy. Following those changes through to the > >num_util code I now get that code to compile. > > > This is the comment that sparked my comment on license issues. Again, no change from where things are, as current VPython derives from its prior release, as is noted by Jonathan in the source file itself. The num_utils code is released subject to the Boost license, which is short and sweet and unrestrictive in any sense: http://www.boost.org/LICENSE_1_0.txt Art |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X