From: Dethe E. <de...@li...> - 2005-06-24 18:51:48
|
Hi folks, I'm willing to take another stab at porting VPython to OS X. The last time I tried I was not very familiar with the OS X libraries, but I've grown more familiar with them since then, and I know where to ask questions. On the other hand, the VPython library itself has been overhauled since then, and I am totally unfamiliar with Boost. Is there a specific version of Boost that I need (I know SWIG is sensitive down the the point.point release). I'm hoping this will be fairly straightforward using the Apple guidelines for porting Linux apps. I don't have tons of spare time, but I have a bunch of VPython scripts lying around that I'd like to do something with, and the thought of installing Fink or running on X11 gives me the heebie-jeebies. Any pointers for starting points appreciated. I've read through the list archives to see that I'll probably have to implement glContext, glFont and platmac.(cpp|h). Anything else? The last time I tried this, most of the work appeared to be handling locking and bootstrapping an OpenGL context. Also, in CVS there are a number of modules. The installer and DLLs modules don't look applicable to OS X, but I'm not sure of the status of the others. There is a README in vpython-core2 saying that it is an experimental branch, but it looks like that may be the new Boost- based version. Which modules are currently relevant? Thanks a bunch. --Dethe p.s., I realized when this mail bounced to me, that my last mail to this list also bounced and I haven't had a chance to debug *why* it bounced until today. Here is that previous mail to give some context to the above. > On 7-Jun-05, at 7:16 PM, Jon Schull wrote: > >> Thanks I have done that (by adding " set path = (/usr/local/bin >> $path)" to .tcshrc) and all is well. >> >> Now, as momentary liaison between the pythonmac and vpython lists >> I'll mention that VPython (a truly beautiful thing) could be made >> independent of X11 if someone from this group knew how to >> liberate it... > > I took a stab at it once, before VPython was refactored into C++, > but I was still pretty new to OS X programming at the time, and it > defeated me. I haven't yet taken a look at the C++ version, it's > on my todo list, but not a high priority right now. I'd love to > see VPython on OS X properly, but my hobby coding time is pretty > limited right now. > > --Dethe -- Dethe Elza http://livingcode.org/ When laws are outlawed, only outlaws will have laws. |
From: Bruce S. <Bru...@nc...> - 2005-06-24 19:06:11
|
What you want is vpython; vpython-core2 is the experimental work Jonathan Brandmeyer is doing to add transparency, surface textures, and sophisticated lighting. I made an uninformed and unsuccessful attempt to compile the boost libraries (www.boost.org) on OSX 10.4. First I tried using the gcc that comes with, and that didn't work, complaining about something having to do with "shared" (libraries). Jonathan had mentioned that the gcc 4.0.0 that comes with 10.4 was grabbed from the GNU people when it was still very unstable, so I tried installing from gcc.gnu.org. There is a recent 4.0.0 there, but to avoid confusion I tried installing (bootstrap install) of gcc 3.4.4, with the parameters specified in vpython/INSTALL.txt, which unfortunately failed in a way meaningless to me. So I didn't get very far just trying to get an X11 version compiled for 10.4. I will say that installing the old VPython on 10.4 using fink is actually quite painless now, thanks to the packaging done by Martin Costabel. And you can easily install X11 and Xcode from the 10.4 DVD. Building a native-mode Mac VPython would be a wonderful contribution, but certainly vastly more difficult than merely installing the old pre-boost VPython. Bruce Sherwood Dethe Elza wrote: > Hi folks, > > I'm willing to take another stab at porting VPython to OS X. The last > time I tried I was not very familiar with the OS X libraries, but I've > grown more familiar with them since then, and I know where to ask > questions. On the other hand, the VPython library itself has been > overhauled since then, and I am totally unfamiliar with Boost. Is > there a specific version of Boost that I need (I know SWIG is sensitive > down the the point.point release). > > I'm hoping this will be fairly straightforward using the Apple > guidelines for porting Linux apps. I don't have tons of spare time, > but I have a bunch of VPython scripts lying around that I'd like to do > something with, and the thought of installing Fink or running on X11 > gives me the heebie-jeebies. > > Any pointers for starting points appreciated. I've read through the > list archives to see that I'll probably have to implement glContext, > glFont and platmac.(cpp|h). Anything else? The last time I tried > this, most of the work appeared to be handling locking and > bootstrapping an OpenGL context. > > Also, in CVS there are a number of modules. The installer and DLLs > modules don't look applicable to OS X, but I'm not sure of the status > of the others. There is a README in vpython-core2 saying that it is an > experimental branch, but it looks like that may be the new Boost- based > version. Which modules are currently relevant? > > Thanks a bunch. > > --Dethe > > p.s., I realized when this mail bounced to me, that my last mail to > this list also bounced and I haven't had a chance to debug *why* it > bounced until today. Here is that previous mail to give some context > to the above. > >> On 7-Jun-05, at 7:16 PM, Jon Schull wrote: >> >>> Thanks I have done that (by adding " set path = (/usr/local/bin >>> $path)" to .tcshrc) and all is well. >>> >>> Now, as momentary liaison between the pythonmac and vpython lists >>> I'll mention that VPython (a truly beautiful thing) could be made >>> independent of X11 if someone from this group knew how to liberate >>> it... >> >> >> I took a stab at it once, before VPython was refactored into C++, but >> I was still pretty new to OS X programming at the time, and it >> defeated me. I haven't yet taken a look at the C++ version, it's on >> my todo list, but not a high priority right now. I'd love to see >> VPython on OS X properly, but my hobby coding time is pretty limited >> right now. >> >> --Dethe > > > > -- > Dethe Elza > http://livingcode.org/ > > When laws are outlawed, only outlaws will have laws. > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users |
From: Dethe E. <de...@li...> - 2005-06-24 19:56:23
|
On 24-Jun-05, at 12:06 PM, Bruce Sherwood wrote: > What you want is vpython; vpython-core2 is the experimental work > Jonathan Brandmeyer is doing to add transparency, surface textures, > and sophisticated lighting. Well, that's both useful (work in vpython) and great news (textures and transparency are my two highest wishlist items for VPython). Thanks! > I made an uninformed and unsuccessful attempt to compile the boost > libraries (www.boost.org) on OSX 10.4. First I tried using the gcc > that comes with, and that didn't work, complaining about something > having to do with "shared" (libraries). Jonathan had mentioned that > the gcc 4.0.0 that comes with 10.4 was grabbed from the GNU people > when it was still very unstable, so I tried installing from > gcc.gnu.org. There is a recent 4.0.0 there, but to avoid confusion > I tried installing (bootstrap install) of gcc 3.4.4, with the > parameters specified in vpython/INSTALL.txt, which unfortunately > failed in a way meaningless to me. So I didn't get very far just > trying to get an X11 version compiled for 10.4. I'm working on getting Boost to compile right now. I'll let you know if I succeed. > I will say that installing the old VPython on 10.4 using fink is > actually quite painless now, thanks to the packaging done by Martin > Costabel. And you can easily install X11 and Xcode from the 10.4 > DVD. Building a native-mode Mac VPython would be a wonderful > contribution, but certainly vastly more difficult than merely > installing the old pre-boost VPython. I realize that it's easier, but I don't want Fink on my system. Too many problems last time I did that. Also, while I have X11 installed (just in case), I really prefer not to use it--and don't see why I should for an OpenGL-based program when OS X has great OpenGL support. So I'll tilt at the windmill and see who wins. %-) --Dethe This past week, everyday when I opened my Wall Street Journal, I was met with a full page ad from Microsoft. This ad was dominated by three simple words "Protect your PC." This strikes me as something akin to the Saudi government running ads in the New York Times in mid- September of 2001 saying "Protect your Tall Buildings." --Russ McGuire |
From: Ilan V. <ig...@nc...> - 2005-06-24 23:25:54
|
I've never understood why VPython wasn't written purely in python using PyOpenGL as opposed to using C/C++ to do the OpenGL stuff as it currently does. The few times I've looked at the VPython code, it looked like a messy interweaving of python calling C calling python calling C calling python etc. If all the OpenGL stuff were done with PyOpenGL (and possibly PyGame), I would think that the code would be cleaner and far more portable. On Jun 24, 2005, at 3:56 PM, Dethe Elza wrote: > > I realize that it's easier, but I don't want Fink on my system. > Too many problems last time I did that. Also, while I have X11 > installed (just in case), I really prefer not to use it--and don't > see why I should for an OpenGL-based program when OS X has great > OpenGL support. > > So I'll tilt at the windmill and see who wins. %-) > > --Dethe > > This past week, everyday when I opened my Wall Street Journal, I > was met with a full page ad from Microsoft. This ad was dominated > by three simple words "Protect your PC." This strikes me as > something akin to the Saudi government running ads in the New York > Times in mid-September of 2001 saying "Protect your Tall > Buildings." --Russ McGuire > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users > |
From: Bruce S. <Bru...@nc...> - 2005-06-25 00:15:51
|
It is complex code for a reason: performance. Computers do get faster, so this is a moving target. But when David Scherer was first implementing the Visual module in the spring of 2000, with a need to run on 200 Mhz PC's, it was not an option to use anything other than very tightly coded multithreaded C++. I don't know enough about other alternatives to be able to judge whether it would be feasible now to use a simpler architecture, though I doubt it. Bruce Sherwood Ilan Volow wrote: > I've never understood why VPython wasn't written purely in python using > PyOpenGL as opposed to using C/C++ to do the OpenGL stuff as it > currently does. The few times I've looked at the VPython code, it > looked like a messy interweaving of python calling C calling python > calling C calling python etc. If all the OpenGL stuff were done with > PyOpenGL (and possibly PyGame), I would think that the code would be > cleaner and far more portable. > > > On Jun 24, 2005, at 3:56 PM, Dethe Elza wrote: > >> >> I realize that it's easier, but I don't want Fink on my system. Too >> many problems last time I did that. Also, while I have X11 installed >> (just in case), I really prefer not to use it--and don't see why I >> should for an OpenGL-based program when OS X has great OpenGL support. >> >> So I'll tilt at the windmill and see who wins. %-) >> >> --Dethe >> >> This past week, everyday when I opened my Wall Street Journal, I was >> met with a full page ad from Microsoft. This ad was dominated by >> three simple words "Protect your PC." This strikes me as something >> akin to the Saudi government running ads in the New York Times in >> mid-September of 2001 saying "Protect your Tall Buildings." --Russ >> McGuire >> >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >> from IBM. Find simple to follow Roadmaps, straightforward articles, >> informative Webcasts and more! Get everything you need to get up to >> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >> _______________________________________________ >> Visualpython-users mailing list >> Vis...@li... >> https://lists.sourceforge.net/lists/listinfo/visualpython-users >> > > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users |
From: Jonathan B. <jbr...@ea...> - 2005-06-25 01:18:17
|
On Fri, 2005-06-24 at 19:25 -0400, Ilan Volow wrote: > I've never understood why VPython wasn't written purely in python > using PyOpenGL as opposed to using C/C++ to do the OpenGL stuff as it > currently does. The few times I've looked at the VPython code, it > looked like a messy interweaving of python calling C calling python > calling C calling python etc. Actually, its entirely Python->C++. Right now, C++ never calls Python code. > If all the OpenGL stuff were done with > PyOpenGL (and possibly PyGame), I would think that the code would be > cleaner and far more portable. Bruce hit on the first reason - raw speed. The fewer CPU cycles spent rendering, the more can be spent doing physics. The second is that the rendering is performed asynchronously in a separate thread. Python is not really designed for multithreading; only one thread at a time can be executing, even on Hyperthreading-equipped Pentium 4s, multiprocessor, and multicore systems. I have done some experimentation with PyOpenGL to prototype a different OpenGL-using application. I found that the performance was unacceptable for any kind of dynamic scene, such as what most VPython client programs create. -Jonathan |
From: Jonathan B. <jbr...@ea...> - 2005-06-25 01:39:33
|
On Fri, 2005-06-24 at 11:51 -0700, Dethe Elza wrote: > Hi folks, > > I'm willing to take another stab at porting VPython to OS X. Wonderful! > The > last time I tried I was not very familiar with the OS X libraries, > but I've grown more familiar with them since then, and I know where > to ask questions. On the other hand, the VPython library itself has > been overhauled since then, and I am totally unfamiliar with Boost. > Is there a specific version of Boost that I need (I know SWIG is > sensitive down the the point.point release). VPython itself will work with Boost.Python 1.31 or higher (1.33 recommended right now). However, different releases of Boost do not maintain any binary compatibility between them. So if you decide to upgrade Boost.Python, you must recompile VPython. Note that you do not need to build any part of Boost other than the Python library. The Boost Serialization Library is known to break Apple's custom release of GCC, so your build will probably fail if you try to build everything. > I'm hoping this will be fairly straightforward using the Apple > guidelines for porting Linux apps. I don't have tons of spare time, > but I have a bunch of VPython scripts lying around that I'd like to > do something with, and the thought of installing Fink or running on > X11 gives me the heebie-jeebies. > > Any pointers for starting points appreciated. I've read through the > list archives to see that I'll probably have to implement glContext, > glFont and platmac.(cpp|h). Anything else? The last time I tried > this, most of the work appeared to be handling locking and > bootstrapping an OpenGL context. That assessment is correct. I think you will probably be able to reuse the parts of platlinux.{cpp,h} that use POSIX (esp Pthreads). Thanks to the threading, some of the code flowpaths are hard to follow, but I'll be happy to answer any questions you have about it. > Also, in CVS there are a number of modules. The installer and DLLs > modules don't look applicable to OS X, but I'm not sure of the status > of the others. There is a README in vpython-core2 saying that it is > an experimental branch, but it looks like that may be the new Boost- > based version. Which modules are currently relevant? I restructured CVS a while ago to clean things up, but I left the old modules in place to retain their history. The "vpython" module contains everything in the source distribution (except for the files built by the autotools). The "vpython-core2" module contains a complete rewrite of the rendering engine that supports translucency, advanced lighting, texture mapping, a more extensible rendering model, and support for Python-level GUI toolkit integration (think VPython scene tightly integrated with a PyGtk, wxPython, PyQT, PyWhoKnowsWhatTK application). This module is fairly unstable right now, and will need quite a bit of work before I start releasing betas. Your effort will be best spent working on the current release series, since the platform-specific/platform-agnostic boundaries are going to change a lot in the development sources before I start releasing it. I expect that your experience porting the stable VPython to native OSX will carry over to vpython-core2 (which will be publicly numbered 4.0). -Jonathan |
From: Dethe E. <de...@li...> - 2005-06-25 03:32:32
|
On 24-Jun-05, at 6:39 PM, Jonathan Brandmeyer wrote: > VPython itself will work with Boost.Python 1.31 or higher (1.33 > recommended right now). However, different releases of Boost do not > maintain any binary compatibility between them. So if you decide to > upgrade Boost.Python, you must recompile VPython. Note that you do > not > need to build any part of Boost other than the Python library. The > Boost Serialization Library is known to break Apple's custom > release of > GCC, so your build will probably fail if you try to build everything. > Ah, knowing I only had to build Boost.Python would have helped. Boost 1.32.0_0 appears to have built cleanly from darwin ports, but it took a *loooong* time. > That assessment is correct. I think you will probably be able to > reuse > the parts of platlinux.{cpp,h} that use POSIX (esp Pthreads). > Excellent! As I recall the earlier version used GTK methods for threading, which complicated porting. Posix will be a breath of fresh air after that. > Thanks to the threading, some of the code flowpaths are hard to > follow, > but I'll be happy to answer any questions you have about it. > I'll try to ask questions sooner rather than later. I have a bad habit of trying to figure everything out for myself, which takes a lot longer and is far more frustrating. > Your effort will be best spent working on the current release series, > since the platform-specific/platform-agnostic boundaries are going to > change a lot in the development sources before I start releasing > it. I > expect that your experience porting the stable VPython to native OSX > will carry over to vpython-core2 (which will be publicly numbered > 4.0). > Yes, I will cut my teeth on the stable source. If that goes well, perhaps I can help port to the Cocoa context. The new branch sounds very exciting, some things I've looked forward to for a long time. Thanks for the help and feedback! --Dethe There are two ways of constructing a software design. One way is to make it so simple there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. --C.A.R. Hoare |
From: Eric A. <Ay...@ma...> - 2005-06-28 05:38:09
|
I don't know if this would be helpful or not, but are you familiar with AquaTerm? http://www.apple.com/downloads/macosx/unix_open_source/aquaterm.html It's a display program for things that would normally be displayed under Xwindows. I know nothing about its inner workings, but I use it for Gnuplot output under OS X. Would this be a simple way to get vpython working in OS X without using Xwindows? Good luck with the port either way. I'd be happy to help in any way possible, but my area of expertise does not extend to any serious system coding. I too dislike using fink, and would LOVE to be able to use vpython directly from the terminal with the default OS X install of python. -EA ----------------------------------------------------------------- Dr. Eric Ayars Assistant Professor of Physics California State University, Chico ay...@ma... On Jun 24, 2005, at 11:51 AM, Dethe Elza wrote: > Hi folks, > > I'm willing to take another stab at porting VPython to OS X. The > last time I tried I was not very familiar with the OS X libraries, > but I've grown more familiar with them since then, and I know where > to ask questions. On the other hand, the VPython library itself > has been overhauled since then, and I am totally unfamiliar with > Boost. Is there a specific version of Boost that I need (I know > SWIG is sensitive down the the point.point release). > > I'm hoping this will be fairly straightforward using the Apple > guidelines for porting Linux apps. I don't have tons of spare > time, but I have a bunch of VPython scripts lying around that I'd > like to do something with, and the thought of installing Fink or > running on X11 gives me the heebie-jeebies. > > Any pointers for starting points appreciated. I've read through > the list archives to see that I'll probably have to implement > glContext, glFont and platmac.(cpp|h). Anything else? The last > time I tried this, most of the work appeared to be handling locking > and bootstrapping an OpenGL context. > > Also, in CVS there are a number of modules. The installer and DLLs > modules don't look applicable to OS X, but I'm not sure of the > status of the others. There is a README in vpython-core2 saying > that it is an experimental branch, but it looks like that may be > the new Boost-based version. Which modules are currently relevant? > > Thanks a bunch. > > --Dethe > > p.s., I realized when this mail bounced to me, that my last mail to > this list also bounced and I haven't had a chance to debug *why* it > bounced until today. Here is that previous mail to give some > context to the above. > > >> On 7-Jun-05, at 7:16 PM, Jon Schull wrote: >> >> >>> Thanks I have done that (by adding " set path = (/usr/local/bin >>> $path)" to .tcshrc) and all is well. >>> >>> Now, as momentary liaison between the pythonmac and vpython >>> lists I'll mention that VPython (a truly beautiful thing) could >>> be made independent of X11 if someone from this group knew how >>> to liberate it... >>> >> >> I took a stab at it once, before VPython was refactored into C++, >> but I was still pretty new to OS X programming at the time, and it >> defeated me. I haven't yet taken a look at the C++ version, it's >> on my todo list, but not a high priority right now. I'd love to >> see VPython on OS X properly, but my hobby coding time is pretty >> limited right now. >> >> --Dethe >> > > > -- > Dethe Elza > http://livingcode.org/ > > When laws are outlawed, only outlaws will have laws. > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users > |