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