Thread: [Visualpython-users] VPython on OSX

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I recently built Boost.Python 1.33.1 and VPython 3.2.9 on OSX 10.4 with
XCode 2.3 (Apple's GCC 4.0.1).  You don't need to build a custom
compiler anymore.

HTH,
-Jonathan

Are you saying that Mac OS X users won't need to use X11 anymore?

Aaron

On May 30, 2006, at 4:36 PM, Jonathan Brandmeyer wrote:

> I recently built Boost.Python 1.33.1 and VPython 3.2.9 on OSX 10.4  
> with
> XCode 2.3 (Apple's GCC 4.0.1).  You don't need to build a custom
> compiler anymore.
>
> HTH,
> -Jonathan
>
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and  
> Risk!
> Fully trained technicians. The highest number of Red Hat  
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

On Tue, 2006-05-30 at 16:48 -0400, Aaron Titus wrote:
> Are you saying that Mac OS X users won't need to use X11 anymore?

Not at all.  You still need X11 and fink.  Before, Apple's compiler (a
bastardized gcc) was too broken to build and run Boost.Python + VPython.
The build of gcc shipped with XCode 2.3 works fine.

Another user asked me what he would need to do on an Intel-based mac to
get VPython up and running.  The answer is that until the fink
developers get fink working for either fat binaries or a custom
i386-only distribution, you shouldn't bother.  You can try the beta that
is posted on fink.sourceforge.net, but don't get your hopes up.

We don't have an intel mac to test on.  If an OS-X guru would like to
speak up, I would be interested in what it takes to crank out fat
binaries from the command line on PowerPC, as Apple only sees fit to
describe the process from within XCode.

Thanks,
-Jonathan

> Aaron
> 
> On May 30, 2006, at 4:36 PM, Jonathan Brandmeyer wrote:
> 
> > I recently built Boost.Python 1.33.1 and VPython 3.2.9 on OSX 10.4  
> > with
> > XCode 2.3 (Apple's GCC 4.0.1).  You don't need to build a custom
> > compiler anymore.
> >
> > HTH,
> > -Jonathan
> >
> >
> >
> > -------------------------------------------------------
> > All the advantages of Linux Managed Hosting--Without the Cost and  
> > Risk!
> > Fully trained technicians. The highest number of Red Hat  
> > certifications in
> > the hosting industry. Fanatical Support. Click to learn more
> > http://sel.as-us.falkag.net/sel? 
> > cmd=lnk&kid=107521&bid=248729&dat=121642
> > _______________________________________________
> > Visualpython-users mailing list
> > Vis...@li...
> > https://lists.sourceforge.net/lists/listinfo/visualpython-users
> >
> 
> 
> 
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Jonathan Brandmeyer wrote:
> On Tue, 2006-05-30 at 16:48 -0400, Aaron Titus wrote:
>> Are you saying that Mac OS X users won't need to use X11 anymore?
> 
> Not at all.  You still need X11 and fink.  Before, Apple's compiler (a
> bastardized gcc) was too broken to build and run Boost.Python + VPython.
> The build of gcc shipped with XCode 2.3 works fine.

This has worked for a while already (since xcode-2.1 I think, in Fink at 
least since August 2005).

> Another user asked me what he would need to do on an Intel-based mac to
> get VPython up and running.  The answer is that until the fink
> developers get fink working for either fat binaries or a custom
> i386-only distribution, you shouldn't bother.  You can try the beta that
> is posted on fink.sourceforge.net, but don't get your hopes up.

The Fink packages for boost1.33 and for vpython 3.2.9 (packages 
visual-py23 and visual-py24, depending on which version of python you 
want to run it with) are building fine on mac/intel. They are in the 
stable tree, too, so that they will appear in the next binary 
distribution. The current (somewhat non-public for reasons I don't 
understand) binary distribution of Fink for Mac/intel only contains the 
old version 2.1.9 of visual-py23, unfortunately.

> We don't have an intel mac to test on.  If an OS-X guru would like to
> speak up, I would be interested in what it takes to crank out fat
> binaries from the command line on PowerPC, as Apple only sees fit to
> describe the process from within XCode.

Universal (fat) binaries are not interesting for the user. They may make 
life easier for those who distribute binaries, but it is not much more 
complicated to distribute separate binaries for ppc and for intel. Fink 
has separate binary distributions for ppc and for intel, and the user 
sees only the one corresponding to the the currently used machine.

-- 
Martin

Just to be clear on the matter, what are the major hurdles that must be jumped to implement VPython in Mac OS X's Aqua interface? And has anyone been making any recent progress that deserves mention?

-JS

On Wed, 2006-05-31 at 06:41 -0700, Jeremy Sachs wrote:
> Just to be clear on the matter, what are the major hurdles that must
> be jumped to implement VPython in Mac OS X's Aqua interface? 

A developer that knew something about Aqua, for starters.  Said
developer would need to write an implementation of src/gtk2/display.cpp
and/or src/gtk2/render_surface.cpp (in the vpython-core2 module).

> And has anyone been making any recent progress that deserves mention?

Not that I'm aware.  Someone mentioned that they would give it effort a
while back, but I haven't heard from them since.

-Jonathan

On 5/31/06, Jonathan Brandmeyer <jbr...@ea...> wrote:
> On Wed, 2006-05-31 at 06:41 -0700, Jeremy Sachs wrote:
> > Just to be clear on the matter, what are the major hurdles that must
> > be jumped to implement VPython in Mac OS X's Aqua interface?
>
> A developer that knew something about Aqua, for starters.  Said
> developer would need to write an implementation of src/gtk2/display.cpp
> and/or src/gtk2/render_surface.cpp (in the vpython-core2 module).
>
> > And has anyone been making any recent progress that deserves mention?
>
> Not that I'm aware.  Someone mentioned that they would give it effort a
> while back, but I haven't heard from them since.

That was probably me.  I struggled with just getting it to compile,
without having to pull in all the dependencies from Fink, but failed.
My autoconf-foo was not good enough, and I had to switch back to
projects that are tractable for me.  I know Cocoa and OpenGL, and can
find my way around Aqua, but the VPython build system defeated me.

Personally, I'd like to see a VPython built on top of PyOpenGL, so it
would play well with others (PyOpenGL works with PyGame, Cocoa,
Windows, Linux, etc.)  Since PyOpenGL is getting some speedups these
days (and machines are about 100x faster than when VPython was
created) it ought to be feasible.  Plus the code would be accessible
to more pythonistas.

I'm still willing to try again sometime, when I have time to futz with
it, but that won't be soon.

--Dethe

>
> -Jonathan
>
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

On Wed, 2006-05-31 at 15:58 -0700, Dethe Elza wrote:
> On 5/31/06, Jonathan Brandmeyer <jbr...@ea...> wrote:
> > On Wed, 2006-05-31 at 06:41 -0700, Jeremy Sachs wrote:
> > > Just to be clear on the matter, what are the major hurdles that must
> > > be jumped to implement VPython in Mac OS X's Aqua interface?
> >
> > A developer that knew something about Aqua, for starters.  Said
> > developer would need to write an implementation of src/gtk2/display.cpp
> > and/or src/gtk2/render_surface.cpp (in the vpython-core2 module).
> >
> > > And has anyone been making any recent progress that deserves mention?
> >
> > Not that I'm aware.  Someone mentioned that they would give it effort a
> > while back, but I haven't heard from them since.
> 
> That was probably me.  I struggled with just getting it to compile,
> without having to pull in all the dependencies from Fink, but failed.
> My autoconf-foo was not good enough, and I had to switch back to
> projects that are tractable for me.  I know Cocoa and OpenGL, and can
> find my way around Aqua, but the VPython build system defeated me.

How much Cocoa code did you get done for VPython before you threw in the
towel?  I can manage to beat on the autotools if you can supply the
Cocoa code.

> Personally, I'd like to see a VPython built on top of PyOpenGL, so it
> would play well with others (PyOpenGL works with PyGame, Cocoa,
> Windows, Linux, etc.)  Since PyOpenGL is getting some speedups these
> days (and machines are about 100x faster than when VPython was
> created) it ought to be feasible.  Plus the code would be accessible
> to more pythonistas.

I did some PyOpenGL stuff quite recently.  Unfortunately, it is _much_
too slow for VPython.

> I'm still willing to try again sometime, when I have time to futz with
> it, but that won't be soon.

-Jonathan

On 5/31/06, Jonathan Brandmeyer <jbr...@ea...> wrote:

> How much Cocoa code did you get done for VPython before you threw in the
> towel?  I can manage to beat on the autotools if you can supply the
> Cocoa code.

I got stuck at the getting it to compile phase.  My plan was to stub
out the functions that needed replacing, then fill them in with Cocoa
or Carbon as needed.  But I wanted it to compile first so I had a
baseline to test against, and I couldn't get that far.

> I did some PyOpenGL stuff quite recently.  Unfortunately, it is _much_
> too slow for VPython.

OK, well there are other paths to cross-platform OpenGL.  One would be
to use Glut for windowing instead of platform-dependant windows
(wouldn't help with integrating with other libraries, but wouldn't be
worse than what is there now), and posix for threading. Then it would
be usable across Linux and OS X without substantial changes, and
Windows too with the right libraries.

I don't know what you were trying with PyOpenGL, but a) I think the
speedups are on a branch, and may not have made it to Windows yet, and
b) moving as much as possible into display lists should be as fast os
OpenGL allows, regardless of whether the display lists were built from
python or C++.  Another option would be to build VPython on a rich 3D
scenegraph environment (preferably one that is already cross-platform)
such as Coin, Soya, etc. (Python has a richness of 3D environments).
Then VPython could be the easy path into 3D, but users could still
expand past it to do transparency, textures, etc.  Some of the 3D
stuff out there works with other windowing libraries (wx, PyGame)
which makes it easier to use VPython as a standard part of the python
toolbox.

Just my blue-sky ideas.  My department recently got purchased by a
company in Japan, so I'm busier than usual with work and travel, so it
will be some time before I have hobby coding time to spare,
unfortunately.

--Dethe

Thread: [Visualpython-users] VPython on OSX

This project is no longer active. See vpython.org.

visualpython-users