visualpython-users

[Visualpython-users] Re: Visualpython-users digest, Vol 1 #384 - 6 msgs

[Jonathan B. <jbr...@ea...>]

> Message: 2
> Date: Sun, 16 Feb 2003 17:27:43 -0500
> From: Arthur <ajs...@op...>
> Subject: Re: [Visualpython-users] History and Status?
> To: Bruce Sherwood <bas...@un...>,
>  John Keck <joh...@ho...>,
vis...@li...
>
> Bruce writes:
>
> > Design Goals:
> >
> > 1.  Preserve at least the current level of usability and performance
> > 2.  Make VPython easier to maintain
> > 3.  Make VPython easier to extend.  There should be a gentle path
> > between user and implementor, not a gaping chasm.
> > 4.  Make VPython more useful and less limiting for experts, so as to
> > increase the availability of expert help to the VPython community.
> > 5.  Make VPython play nicer with other Python packages and tools
>
> Well thought out.
>
> As to point 5, I am quite convinced that a step toward that goal is the
use
> of Python's distutils as the basis for the distribution mechanism. I can
be
> and would be willing to be helpful here - as I have gotten hands on with
it,
> and find it friendly and flexible.

Outstanding.  I have posted a Makefile.w32 that will build cvisual.dll using
MinGW.  The Win32 port has a different set of dependancies from the *nix
distribution.  Capturing the differences using the distutils, would be
excellent.  I freely admit that I am used to using GNU-style configure and
make.  But, I am also open to alternatives, especially anything that is more
natural to other Python users.

> As I have said many times, I think VPython has some unique qualities.
Which
> if built upon along the lines you suggest, will, I believe allow it be an
> enduring and even more significant project.
>
> But as you suggest, it would need to atttract some developers to get it
over
> the hump to a next phase.
>
> I, for one, am willing to spend time on it.  The problem being I am more
of
> a Python person than a C++, or C guy. But I am willing to approach the
> learning curve, especially if there are brains around to pick.  I do come
to
> it with a decent grasp of OpenGL. Though I would need to get up on some of
> the newer version features.  That being VPython's fault - as I was doing
> more directly in PyOpenGL before VPython came along, with much of what I
was
> trying to do - prebuilt.

I am much more of a C++ guy than a Python guy, and I would enjoy hearing
your thoughts and questions.

> I am even willing to try to do some recruiting for the project- perhaps at
> the PyCon event in DC next month.
>
> How do we work toward establishing some concrete ideas for bringing more
of
> your thought experiment to life.

Short term, I have been working on clearing out the cobwebs and fixing some
of the bugs that people have generously found for us.  Once that is
complete, we plan to move the interface over to Boost.Python.  Using the
boost library will allow the C++ code to take a form that closely matches
the API that is visible from within Python.  Since Boost.Python is designed
to manage the vast majority of the Python-C++ interface, the C++ code should
be much more clean and extensible.  I see the move to Boost as a major
enabling factor for VPython's future growth.

-Jonathan

Re: [Visualpython-users] Re: Visualpython-users digest, Vol 1 #384 - 6 msgs

[Arthur <ajs...@op...>]

[Jonathon]
> Outstanding.  I have posted a Makefile.w32 that will build cvisual.dll
using
> MinGW.  The Win32 port has a different set of dependancies from the *nix
> distribution.  Capturing the differences using the distutils, would be
> excellent.  I freely admit that I am used to using GNU-style configure and
> make.  But, I am also open to alternatives, especially anything that is
more
> natural to other Python users.
I have a setup.py  for VPython on Windows.  It is tested under VC6, and
builds a self installing Windows executable with the command "python
setup.py bdist_wininst". I can send it along, or post it, if interested.

Distutils will test for platform - so the idea, I think, is to have on
setup.py for all platforms. I knew Linux fairly well at one point, but have
been away from it for a while.  I have quite recently done a Linux
installation on my machines - even have my wireless network working under
Linux :) , and plan to go on to better understand:

First, in general - what are the norms for Python distributions under Linux.
Secondly, how to configure a VPython setup.py consistent with those norms.

As Bruce pointed out, there is already a setup.py for Linux in the current
source distro.  It required only a move of the visual directory in the
source tree to work fine.  It is now just a matter  of deciding upon
appropriate placement of the resulting files - the library, demos and docs.
Right now - with the current cetup.py - the library places itself in the
root of Python's site-packages directory, which I do not think is a good
alternative.

Generally speaking, I think what should happen is that the compiled visual
library and the supporting .py files should end up together in a "visual"
directory as a sub-drectory of site-packages, and the demos and docs
separate, and totally off the Python library branch.

>
> Short term, I have been working on clearing out the cobwebs and fixing
some
> of the bugs that people have generously found for us.  Once that is
> complete, we plan to move the interface over to Boost.Python.  Using the
> boost library will allow the C++ code to take a form that closely matches
> the API that is visible from within Python.  Since Boost.Python is
designed
> to manage the vast majority of the Python-C++ interface, the C++ code
should
> be much more clean and extensible.  I see the move to Boost as a major
> enabling factor for VPython's future growth.


I am thrilled to hear that this is being attended to.

One thing I think you need to think about is the transition from Numeric to
Numarray.

See:
http://www.pfdubois.com/numpy/

It looks like backward compatibility issues are being address in Numarry -
so hopefully any issues in the transition will be small.

The port to Boost would only leave unaddressed the webizing of VPython. As I
mentioned, I think a port that would work with Jython would be wonderful.
And though not a full fledged Java guy, I am more of a Java guy than I am a
C guy - and have done some 3d graphics stuff in Java.  Perhaps I will try to
follow what you are doing with Boost/ CPython in Java.  So that at least the
interface would be the same.  That is, the goal would be that the same
Python scripts could pilot either version.  Maybe a little ambitious - but I
don't see why it shouldn't be doable. If I get to the point where I am
serious about this, it might become important that we coordinate.  Right
know I would put it in the thought experiment phase.


Art

Re: [Visualpython-users] Re: Visualpython-users digest, Vol 1 #384 - 6 msgs

[Bruce S. <bas...@un...>]

Arthur mentioned the impending demise of Numeric, and its replacement by
Numarray. In June I got this advice from Dave Scherer about what will be
involved in updating Visual when the time comes:

> I just noticed that the Numeric folk intend to replace
> Numeric with a new
> module which is mostly compatible with Numeric except for having a
> completely different interface to C. This sounds suspiciously
> like we might
> have a very big task looming in the not entirely distant future?

I wouldn't expect it to be *too* horrible, but it will take some effort.
Searching cvisual for "Array" (the CXX wrapper class for numeric arrays)
gives 42 hits in arrprim, convex, curve, faceset, and pvector.  This is
not a very scientific check but it suggests that the damage would be
fairly localized.

Re: [Visualpython-users] Re: Visualpython-users digest, Vol 1 #384 - 6 msgs

[Bruce S. <bas...@un...>]

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Jonathan Brandmeyer" <jbr...@ea...>;
<vis...@li...>
Sent: Monday, February 17, 2003 9:54 AM
Subject: Re: [Visualpython-users] Re: Visualpython-users digest, Vol 1
#384 - 6 msgs


> I have a setup.py  for VPython on Windows.  It is tested under VC6, and
> builds a self installing Windows executable with the command "python
> setup.py bdist_wininst". I can send it along, or post it, if interested.

Let me play it back and see whether I've got it right. This is something
that I run on a Windows machine that has Visual C version 6, and the
resulting package is an .exe file to execute on machines that don't have a
compiler? I would be interested in trying it out.

> Generally speaking, I think what should happen is that the compiled visual
> library and the supporting .py files should end up together in a "visual"
> directory as a sub-drectory of site-packages, and the demos and docs
> separate, and totally off the Python library branch.

That sounds right. On Windows as well as Linux, presumably? Where should the
demos and docs go, on Windows and on Linux?