visualpython-users

[Visualpython-users] I can't run VPython on Linux RedHat

[LAZARUS M. <mak...@we...>]

Hi

I have tried to install the VPython software on Redhat, and followed
the instruction. It did install and I was able to call the "idle", and
to open the demo files.

But when I "run (F5)", it says there is no module "cvisual".

I have change the location directories in the files mensioned.

Location:

From "/usr/local/bin"  to "/usr/bin"

My python2.2 is installed in ("/usr/bin/" , "/usr/lib/" , etc").


Now, I was wondering if is it possible that you can email me the copy
of VPython that is configured to run under this location "/usr/bin/"
rather that "/usr/local/bin/". Or send me some information as to how
should I configure the VPython that I have to suite this location.


Thanks!


Regards
Lazarus
_______________________________________________________________
 http://www.webmail.co.za the South-African free email service

  NetWiseGurus.Com Portal - Your Own Internet Business Today!

Re: [Visualpython-users] History and Status?

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

On Mon, 2003-02-17 at 21:49, Bruce Sherwood wrote:
> I did ask about this at the time I was creating a Linux installer, and I
> didn't get any clear answer. I was left with the impression that there is
> quite a bit of flux in the Linux community. I think you should just poll
> this VPython list for opinions and preferences; there seem to be plenty of
> people reading this list who use Linux a lot. There doesn't seem to be one
> right answer, so why not do what this group suggests?
> 
> The docs issue is an interesting one, in that here again there is quite a
> bit of variation. For example, Windows Python comes with extensive
> documentation, but at least in the past if I remember correctly Mac Python
> didn't. I certainly want Visual docs to be included with Visual, at least
> for most users, but maybe here again this is not okay with experts.


Here is one idea for Debian that looks consistant with other Debian
packages on my system.  I think that as binary debs, Vpython could be
installed in three packages, like this:

python2.2-visual:
	Install runtime shared object library and runtime scripts in 
	/usr/lib/site-packages/visual
	Install documentation in /usr/share/doc/python-visual

python2.2-visual-examples:
	Install the demonstration scripts in
	/usr/share/doc/python-visual/examples

(until no longer required)
python2.2-visual-idle:
	Install the scripts in /usr/bin/python-visual-idle
	, with a symlink from /usr/bin/python-visual/idle.py to  
	/usr/bin/vidle.py

The first package is the only one that someone must have to get started
with visual.  We can use the deb dependancy system to ensure that
Numeric, Tkinter, and Python2.2 are installed if required.  We can add
some remarks on the website that briefly explain what they are, although
I think that the package names are fairly self-explanatory.  

Can anyone confirm or refute similar behavior on other Linux
distributions?  Since I custom built my visual componants, I have
everything installed under /usr/local instead of /usr, using the same
scheme.

Arthur has convinced me that the right way to go for source and binary
distributions is to provide a setup.py (or other appropriate mechanism,
e.g, debs, windows exe) that does The Right Thing.  IMO, The Right Thing
is that which bears the same look and feel as other extension modules
for a given platform.  We may be able to provide binaries for only a few
platforms, so the source distribution must be clean.

As for the question, "Can the average non-programmer handle installing
many packages?" IMHO, _given proper instructions_, the answer is yes.  I
honestly do not see a connection between an inability to handle
dependancies, and a lack of programming experience.

-Jonathan

Re: [Visualpython-users] History and Status?

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

Arthur, I just started to look at your materials and I have some naive
questions:

I gather that this setup.py is for use on Windows only if one has the Visual
C compiler?

What would be involved in making an installer based on distutils for those
who do not have a C compiler on their Windows machine?

What would be involved in making an installer based on distutils in the form
of an .exe file that is doubleclickable, to avoid sending a novice to the
DOS command prompt? I understood you to say that this is possible, and I
understand that what you've just sent out isn't that.

I assume it is your intention that a zip file would contain everything in
your manifest list, ready to go, in the appropriate directories. Is that
right? That is, despite what you mention in your current README.txt, the
visual and cvisual files would be included, right? On the other hand, if you
do intend the user to follow the current instructions, wouldn't you have to
give more explicit instructions about getting the visual files, getting the
cvisual files, putting the cvisual folder inside the visual folder, and
putting setup.py at the same level as the visual folder? "Change to the
top-level directory" might not mean much to the novice.

Why in setup.py is it "IDLE_Builder"? What does this have to do with IDLE?

Minor typos in README.txt:

VPYTHON was misspelled in this line:

BUILDING AND INSTALLING VPYTHON FROM SOURCE

And in the following line you said "Numeric" when you meant Visual:

    Using the python into which you wish to install Visual, execute:

Thanks for working on this, Arthur!

Bruce Sherwood

Re: [Visualpython-users] History and Status?

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

I did ask about this at the time I was creating a Linux installer, and I
didn't get any clear answer. I was left with the impression that there is
quite a bit of flux in the Linux community. I think you should just poll
this VPython list for opinions and preferences; there seem to be plenty of
people reading this list who use Linux a lot. There doesn't seem to be one
right answer, so why not do what this group suggests?

The docs issue is an interesting one, in that here again there is quite a
bit of variation. For example, Windows Python comes with extensive
documentation, but at least in the past if I remember correctly Mac Python
didn't. I certainly want Visual docs to be included with Visual, at least
for most users, but maybe here again this is not okay with experts.

Bruce Sherwood

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Gary Pajer" <pa...@in...>; "vpusers"
<vis...@li...>
Sent: Monday, February 17, 2003 6:39 PM
Subject: Re: [Visualpython-users] History and Status?


> > And I always look for packages in site-packages.  I think they all
should
> > be  there.
>
> That was my instinct, and exactly how I put together my current effort at
a
> distutils setup.py for Windows.
>
> But as I mention, there seems to be less concensus about what should be
done
> here. And the main reservation I have about this approach is that it seems
> to work better for Windows than Linux.  Though I am still trying to
> understand what other people doing with Linux Python module distributions.
>
> Numeric seems to have converted to an approach of 2 separate downloads,
one
> for the library files and one for the docs.
>
> I'd ask Guido for his opinion - if we were are speaking terms ;).
>
> Might you pose this to Guido, Bruce?
>
> Art
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

Re: [Visualpython-users] History and Status?

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

So as to avoid confusion, thought I should note that the following two line
in the setup.py file sent along are superfluous

packages = [pkgname,demo_dir]
pkg_dir= {"visual": ".",demo_dir:"demos"}

Who knows what else.

But it does seem to work.

Art

Re: [Visualpython-users] History and Status?

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

> And I always look for packages in site-packages.  I think they all should
> be  there.

That was my instinct, and exactly how I put together my current effort at a
distutils setup.py for Windows.

But as I mention, there seems to be less concensus about what should be done
here. And the main reservation I have about this approach is that it seems
to work better for Windows than Linux.  Though I am still trying to
understand what other people doing with Linux Python module distributions.

Numeric seems to have converted to an approach of 2 separate downloads, one
for the library files and one for the docs.

I'd ask Guido for his opinion - if we were are speaking terms ;).

Might you pose this to Guido, Bruce?

Art

Re: [Visualpython-users] History and Status?

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

Attached is a zip with 4 files.

1) The setup.py which has been tested under Windows and VC6.  It is
configured to do the install for which there seems to be some concensus - at
least as to Windows, .ie. it creates a directory under site-packages called
"visual" in which the cviusal.pyd and supporting .py files are placed and
then 2 subdirectories of  "visual" - one for demos, one for docs.

2) The Manifest file used for the source distribution

3) A README.txt which I put together if I were to do a separate, VPython
distributition off of the www.vpython.org site.

4) And an index.html - slightly modifed from the original.

In order for the setup.py to work, a particular organization of the
directories is necessary.  A "holding" directory for the setup.py, Manifest
and readme, and below it a "visual" directory, empty but with 3 separate
sub-directories - cvisual (with its subdirectories), demos, and docs. The
"docs" directory contains the attached index.html, and a "visual"
sub-directory with the rest of the VPython docs.

python setup.py bdist_wininst will compile the cvisual.pyd and create a
Windows self installing executable containing it and the rest of the files,
docs and demos.
python setup.py sdist will create a source distribution.
python setup.py install will compile and install VPython as described.

Feedback appreciated.

Art

[Visualpython-users] two directions

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

I just realized that there's a useful way of expressing the nature of the
conflicting views of needs and expectations of users. Arthur is
appropriately concerned about the needs and expectations of current Python
users who might consider adding the Visual module to their installation. I
have been concerned about the needs and expectations of nonusers of Python
(who are in many cases nonprogrammers) who are coming to Python (and even to
programming) for the first time. I can't begin to list all of the hidden
assumptions that are associated with thinking about these two opposite
directions of approach to VPython! A related way of capturing the two
directions is to say that the current Python user wants to add the Visual
module, not install VPython. "VPython" is a term that describes a bundle
that gets the newcomer to Python up and running and doing interesting things
quickly.

It was suggested that if I really wanted a simple installation I should have
bundled Python itself in with everything else, so that novices could do one
installation. As was asked, if two installers, why not three or more? If I
had seen how to make it one, I would have done it, because despite lots of
effort, even just two installations has caused problems (not frequent, but
annoying). Every additional installation will bring in its own chances for a
problem. In his "Brief History of Time," Stephen Hawking said that his
publisher told him that he would cut his readership in half by every
equation he included. He decided to include one equation and take the 50%
cut in audience.

On Windows, the current VPython installer uses Python registry entries to
find the PythonXX directory and install into it. Earlier installers merely
asked the user to install into the PythonXX directory, but many users didn't
and then couldn't figure out why nothing worked. Even with the
registry-based scheme I occasionally get reports from novices that they get
the message "can't find visual module". I've never been able to extract a
coherent statement of what went wrong, but if they uninstall and reinstall
they typically get it working, and I'm guessing that it has something to do
with where they installed Python. There's an echo here of a recent comment
by Guido in response to someone having a problem with Python when they chose
to install it somewhere other than in C:\PythonXX. His comment was basically
that they shouldn't have done that! So maybe there's something wrong with
Python itself with respect to location on Windows.

I'm hopeful that through the use of distutils we can make things good for
both approaches, either with appropriate interactions with the user in the
installation process or by providing two different packages.

Bruce Sherwood

Re: [Visualpython-users] History and Status?

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

This sounds fine to me, too. And it would be fine on Linux, too, which has
much to recommend it.

Bruce Sherwood

----- Original Message -----
From: "Gary Pajer" <pa...@in...>
To: "vpusers" <vis...@li...>
Sent: Monday, February 17, 2003 5:29 PM
Subject: Re: [Visualpython-users] History and Status?


> > That leaves the question of where to put the Visual demos. Currently
> they're
> > in PythonXX\Programs\Demos, which is highly arbitrary. Moreover, the
> > Programs part has proven to be irrelevant, so that PythonXX\Demos would
> make
> > more sense. I don't discern any pattern on Windows that suggests where
> > Python demos should go. By default, I favor PythonXX\Demos\Visual, and
> start
> > to encourage developers of other packages to put associated demos in
> > PythonXX\Demos\SomePackage.
>
> Another two cents:  visual is the only package that uses
> PythonXX\Programs\Demos.
> More sensible to me is Pythonxx\Libs\site-packages\visual\demos
> IMHO, it doesn't sit right to have a catch-all Demo directory:
> \PythonXX\Demos.
> When I want to look for something about a package, I always start looking
in
> site-packages\packagename.  In fact, I prefer to see *everything*
associated
> with a package under site-packages\packagename, although the case for the
> docs is arguable.
>
> And I always look for packages in site-packages.  I think they all should
be
> there.
>
> -gary

Re: [Visualpython-users] History and Status?

[Gary P. <pa...@in...>]

> That leaves the question of where to put the Visual demos. Currently
they're
> in PythonXX\Programs\Demos, which is highly arbitrary. Moreover, the
> Programs part has proven to be irrelevant, so that PythonXX\Demos would
make
> more sense. I don't discern any pattern on Windows that suggests where
> Python demos should go. By default, I favor PythonXX\Demos\Visual, and
start
> to encourage developers of other packages to put associated demos in
> PythonXX\Demos\SomePackage.

Another two cents:  visual is the only package that uses
PythonXX\Programs\Demos.
More sensible to me is Pythonxx\Libs\site-packages\visual\demos
IMHO, it doesn't sit right to have a catch-all Demo directory:
\PythonXX\Demos.
When I want to look for something about a package, I always start looking in
site-packages\packagename.  In fact, I prefer to see *everything* associated
with a package under site-packages\packagename, although the case for the
docs is arguable.

And I always look for packages in site-packages.  I think they all should be
there.

-gary

Re: [Visualpython-users] History and Status?

[Joe H. <hea...@vn...>]

I forgot to mention that I have rudimentary knowledge of C, but C++ is 
a big mystery to me. In fact, my tiny and hopelessly incomplete 
understanding of OOP came from looking at VPython!

Cheers,
Joe Heafner

-----
I don't have a Lexus, but I have a Mac. Same thing.

Re: [Visualpython-users] History and Status?

[Joe H. <hea...@vn...>]

On Monday, Feb 17, 2003, at 15:52 US/Eastern, Gary Pajer wrote:

> I volunteer to help. My value may be limited: I'm a user, not a 
> developer,
> and I don't know C.  But I'll do what I can.

Having recently switched to the Mac platform from Linux and Windows I 
too would love to help out, especially in getting a uniform dist 
package of some sort. I suspect the Mac packaging would be very similar 
to the Linux packaging. I intend to try my hand at a Fink package for 
VPython.

Cheers,
Joe Heafner

-----
If Mr. Sterling is anything close to realistic, it's no wonder our 
government is the atrocity that it has become.

Re: [Visualpython-users] History and Status?

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

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Bruce Sherwood" <bas...@un...>; "John Keck"
<joh...@ho...>; <vis...@li...>
Sent: Monday, February 17, 2003 3:48 PM
Subject: Re: [Visualpython-users] History and Status?

> I agree 100% that community expectations have evolved, and are not today
> what they were say when VPython was first released.  And that this
accounts
> in part for the problem.  But I do think certain things are clear. Like
> using site-packages for the visual "library" files.  What is less clear -
> and where there seems to be more divergence in practice - is in the
> placement of demo and documentation files.
>
> It seems to me that these, in the end, should be totally off the python
> directory tree.  I guess the way I would think of it, in a typical Windows
> distribution analogy, is that the install of the functonal dlls (and
related
> .py files) that no one is expected to access directly (we are only
> interested in their functionality) is placed ujnder c:/Windows (analogous
> here to the Lib\site-packages under Python directory) and the "program
> files" - here the demos, docs, and maybe a customized IDE - under the
> c:\Program Files directory (which might simply be a c:\Program
Files\VPython
> direcotry, or a c:\VPython directory.
>
> That's my preference.

I tried the experiment on Windows of moving the "visual" folder (containing
the Visual-associated .py files) to Lib\site-packages and also moving
DLLs\cvisual.dll into Lib\site-packages\visual. Works fine. Wouldn't that be
a reasonable deployment on Windows? Keep all the technical stuff in one
place?

I would prefer not to put any of these pieces in C:\Windows because that's
such an amorphous hodge-podge. And while there's no point in accessing
cvisual.dll directly, it can be of interest to an increasingly sophisticated
user to examine the .py files. Note that Numeric puts everything in one
place, too, so there's some precedent.

There's really only one place for the Visual docs on Windows -- in
Doc\visual.

As I mentioned in an earlier note, the Idle issue is on its way to a
solution, given the intent for the standard Idle to be replaced in Python
2.3 with the daughter of Scherer's version of Idle. The only issue for
novices is the need to offer different configuration files for the new Idle:
adding a pointer to the Visual help, specifying the editor window as the
default startup (rather than the interactive Python shell), and (assuming
that this is going to get into the configuration machinery for the new Idle)
specifying autosave of files on each run (the default is that each time you
press F5 a dialog box intrudes asking whether you want to save the file).
Possibly these could be choices the user would be asked to make in the
distutil installation.

That leaves the question of where to put the Visual demos. Currently they're
in PythonXX\Programs\Demos, which is highly arbitrary. Moreover, the
Programs part has proven to be irrelevant, so that PythonXX\Demos would make
more sense. I don't discern any pattern on Windows that suggests where
Python demos should go. By default, I favor PythonXX\Demos\Visual, and start
to encourage developers of other packages to put associated demos in
PythonXX\Demos\SomePackage.

I don't have much feel for conventions on Linux/Unix, but if it wouldn't
violate community standards it does seem attractive to put as much stuff as
possible in one place, site-packages/visual.

There's one more item concerning bundling. The Numeric installer doesn't
install any documentation. The bundled VPython installer does install the
Numeric pdf file. I'd like this to continue to be an easy option.

Bruce Sherwood

Re: [Visualpython-users] History and Status?

[Gary P. <pa...@in...>]

Here's two bits from a user.  I think Arthur is absolutely correct (that's
not to say that Bruce is not listening and being open minded).  Uniform
packaging has great value.  When I first installed visual I was a little
apprehensive that I might have some sort of conflict with Numeric.  Nothing
happened, everything works ok, but I had a concern.  I point out that the
current installation of visual already requires a two-step process by the
physics student.  One for python, one for visual.
Without knowing the implications: maybe two packages, a "turn key" package
and a conventional package would meet both needs.

I volunteer to help. My value may be limited: I'm a user, not a developer,
and I don't know C.  But I'll do what I can.
[note to Arthur:  my previous offer still stands]

-Gary


----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Bruce Sherwood" <bas...@un...>; "John Keck"
<joh...@ho...>; <vis...@li...>
Sent: Monday, February 17, 2003 9:11 AM
Subject: Re: [Visualpython-users] History and Status?


> [Bruce]
> > Since so far Arthur is the
> > only person who has complained about this, I haven't been able to make
> this
> > a priority, as it does involve extra work. Until very recently there has
> not
> > been sufficient people power to address issues such as this, but I
> certainly
> > don't rule out providing more installation options in the future.
>
> If there is to be an open source community approach, then there has to be
> some sense of openness to community based decision making.  I am willing
to
> undertake responsility for creating and maintaining a distutils
> installation - source and binary, Windows and Linux - for VPython as a
stand
> alone distribution.  The fact is that I am so unhappy about the current
> distribution, that I was pursuing this in any case, and was going to make
it
> available for PyGeo users. Though I would much prefer to have it on the
> VPython site.  And I have no objection to offering PyGeo users the
> "all-in-one" distribution that you prefer for the strudents you focus on
as
> your prime concern.  Though there would have to be some coordination to
> assure that the distributions are consistent -  in terms of where files
are
> place,d for example.  I  have a sense of what I would call general
> expectations within the community of Python users of how a third party
> module should install (and uninstall).  It is important to me that those
> expectations are met. Because I think that the general community of active
> Python users is an important audience for VPython.
>
> So I can help you solve the manpower issue as to the distribution, but
only
> assuming "we" - and I think the we here goes beyond Bruce and myuself -
can
> agree as to what is and is not appropriate in terms of how the
distribution
> behaves.
>
> But let me say directly, I have problems with your wording above. On one
> hand we are talking about a more community based approach to VPython and
its
> future, on the other hand you are talking about what *you* are willing to
> rule in or out. Without a clear idea of what your criteria might be.
>
> If your own focus is narrowly on the constituency of physics students, and
> you understand their needs quite well, is it possible that someone like
> myself who has an idea that VPython could and should have a broader focus,
> go his own way with it.  In other words, offer my own distribution - and
> essentially fork VPython.
>
> It seems to me that should be totally unnecessary and unfortunate.  But I
> also shouldn't need to send you reports of issues as to the current
> distribution by certified mail.  I submit you don't see the issues because
> you have a narrow focus on a particular constituency.  Looking at it from
> the prespective of a broader constituency, ths issues I rasie are quite
> obvious.  There is no good reason why all constinuencies needs cannot be
> addressed at www.vpython.org.  But it is difficult to work cooperatively
if
> you seem to think other people  judgment on these matters cannot be relied
> upon.
>
>
> Art
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] History and Status?

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

[Bruce]

> Excellent, Arthur! Many thanks for volunteering to work on these issues.
The
> excessive use of "I" and "me" in some of my postings was due to the fact
> that no one had previously offered to contribute to the task of building
> installers, whether to their liking and needs or to my liking and needs.
And
> I felt defensive of the needs of my students because I had seen little
> understanding in the Python community that not every potential user of
> Python, even Linux users if they are new to Linux, is comfortable with the
> following incomprehensible statement from the download page at the Python
> site: "All others should download Python-2.3a1.tgz, the source tarball,
and
> do the usual "gunzip; tar; ./configure; make" dance."

You have every right to be defensive as to the needs of your constituency -
and I would expect you to be.  And as it happends, the folks I am trying to
reach are not vastly different.  We agree, for example, as to the need of
Window self- installing executables as an essential alternative.

It seems to me, though, that with a little coordination - the needs of a
broader community can be served without sacrificing anything significant as
to the needs of any sub-community.

The other possiblity - it seems to me - is that if you are looking for a
"stand-alone" VPython distribution, you perhaps need to consider actually
going one step further than you have already - and have your distribution
not only include VPython and Numeric, but the core of the Python files that
VPython requires to run.  In that scenario you are much more free as to what
and how you place the files, help, icons, whatever, etc.  The licenses of
all these efforts would, I believe, allow you a lot of flexibility in doing
this.

It is only when VPython is offered as an add-on - which is how I view
VPython when wearing its "third party module" hat - that I think conformity
to expectations that it will tread lightly and politely on an existing
Python installations, need to be met.

The present distribution is neither fish nor foul, in this respect.  Which
is why I perceive there to be a problem.

But it is a problem, I am confident, with a good solution or two, if we work
at it.

> I'd also love to see a consensus on improved placement of the files. I'm
> quite certain that I made wrong choices, especially in the Linux case,
> partly out of ignorance and partly because there has been something of a
> moving target in the last few years about community expectations of where
> various pieces should go.

I agree 100% that community expectations have evolved, and are not today
what they were say when VPython was first released.  And that this accounts
in part for the problem.  But I do think certain things are clear. Like
using site-packages for the visual "library" files.  What is less clear -
and where there seems to be more divergence in practice - is in the
placement of demo and documentation files.

It seems to me that these, in the end, should be totally off the python
directory tree.  I guess the way I would think of it, in a typical Windows
distribution analogy, is that the install of the functonal dlls (and related
.py files) that no one is expected to access directly (we are only
interested in their functionality) is placed ujnder c:/Windows (analogous
here to the Lib\site-packages under Python directory) and the "program
files" - here the demos, docs, and maybe a customized IDE - under the
c:\Program Files directory (which might simply be a c:\Program Files\VPython
direcotry, or a c:\VPython directory.

That's my preference.

>
> As you work with installer schemes, perhaps you could treat the needs of
my
> students as a kind of superset of your needs. That is, there could be two
> distutil schemes that differ only in that one of them has some extra stuff
> added to make a single bundle.

Not an issue.  But the truth is, we are not so much serving different
audiences, as we have different attitudes, philosophies about these kinds of
things.  I don't see it as a big deal to ask someone to click on a link to a
Numeric self.executing installation file, as a separate step in getting up
and running.

The mechanics are no different then the Python or VPython installation
process as it is currently.  Just an extra click or two.  And I think
cleaner. It defies logic that your students can successfully install 2
packages, but not 3.  I would again encourage you to think of it in all or
nothing terms.  Either provide a single download solution that includes the
needed Python files - which will allow you lots of freedoms - or resign
yourself to adjust to the standard practice of having separate and distinct
distributions treated as such.

But I am open to other ideas.

Art

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?

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] History and Status?

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

Excellent, Arthur! Many thanks for volunteering to work on these issues. The
excessive use of "I" and "me" in some of my postings was due to the fact
that no one had previously offered to contribute to the task of building
installers, whether to their liking and needs or to my liking and needs. And
I felt defensive of the needs of my students because I had seen little
understanding in the Python community that not every potential user of
Python, even Linux users if they are new to Linux, is comfortable with the
following incomprehensible statement from the download page at the Python
site: "All others should download Python-2.3a1.tgz, the source tarball, and
do the usual "gunzip; tar; ./configure; make" dance."

It is already the case that http://vpython.org has a growing set of links to
the contributions of many people (including your own PyGeo), and one
feasible scheme is that as you create new and better installers they can
live at your site with links to them (with those links increasingly
replacing the current installers). Alternatively they can be moved to the
VPython site and stored there -- whichever would work best for you. FYI:
VPython is housed at pair.com, a very good and surprisingly inexpensive
host.

I'd also love to see a consensus on improved placement of the files. I'm
quite certain that I made wrong choices, especially in the Linux case,
partly out of ignorance and partly because there has been something of a
moving target in the last few years about community expectations of where
various pieces should go.

As you work with installer schemes, perhaps you could treat the needs of my
students as a kind of superset of your needs. That is, there could be two
distutil schemes that differ only in that one of them has some extra stuff
added to make a single bundle.

Note that while the Visual source code and the demos are in CVS at
sourceforge.net, the html reference manual is not but could be if and when
others would like to contribute to its care and feeding. Currently it's just
a zip file at http://vpython.org.

Bruce Sherwood

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Bruce Sherwood" <bas...@un...>; "John Keck"
<joh...@ho...>; <vis...@li...>
Sent: Monday, February 17, 2003 9:11 AM
Subject: Re: [Visualpython-users] History and Status?


> [Bruce]
> > Since so far Arthur is the
> > only person who has complained about this, I haven't been able to make
> this
> > a priority, as it does involve extra work. Until very recently there has
> not
> > been sufficient people power to address issues such as this, but I
> certainly
> > don't rule out providing more installation options in the future.
>
> If there is to be an open source community approach, then there has to be
> some sense of openness to community based decision making.  I am willing
to
> undertake responsility for creating and maintaining a distutils
> installation - source and binary, Windows and Linux - for VPython as a
stand
> alone distribution.  The fact is that I am so unhappy about the current
> distribution, that I was pursuing this in any case, and was going to make
it
> available for PyGeo users. Though I would much prefer to have it on the
> VPython site.  And I have no objection to offering PyGeo users the
> "all-in-one" distribution that you prefer for the strudents you focus on
as
> your prime concern.  Though there would have to be some coordination to
> assure that the distributions are consistent -  in terms of where files
are
> place,d for example.  I  have a sense of what I would call general
> expectations within the community of Python users of how a third party
> module should install (and uninstall).  It is important to me that those
> expectations are met. Because I think that the general community of active
> Python users is an important audience for VPython.
>
> So I can help you solve the manpower issue as to the distribution, but
only
> assuming "we" - and I think the we here goes beyond Bruce and myuself -
can
> agree as to what is and is not appropriate in terms of how the
distribution
> behaves.
>
> But let me say directly, I have problems with your wording above. On one
> hand we are talking about a more community based approach to VPython and
its
> future, on the other hand you are talking about what *you* are willing to
> rule in or out. Without a clear idea of what your criteria might be.
>
> If your own focus is narrowly on the constituency of physics students, and
> you understand their needs quite well, is it possible that someone like
> myself who has an idea that VPython could and should have a broader focus,
> go his own way with it.  In other words, offer my own distribution - and
> essentially fork VPython.
>
> It seems to me that should be totally unnecessary and unfortunate.  But I
> also shouldn't need to send you reports of issues as to the current
> distribution by certified mail.  I submit you don't see the issues because
> you have a narrow focus on a particular constituency.  Looking at it from
> the prespective of a broader constituency, ths issues I rasie are quite
> obvious.  There is no good reason why all constinuencies needs cannot be
> addressed at www.vpython.org.  But it is difficult to work cooperatively
if
> you seem to think other people  judgment on these matters cannot be relied
> upon.
>
>
> Art

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] History and Status?

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

[Bruce]
> Since so far Arthur is the
> only person who has complained about this, I haven't been able to make
this
> a priority, as it does involve extra work. Until very recently there has
not
> been sufficient people power to address issues such as this, but I
certainly
> don't rule out providing more installation options in the future.

If there is to be an open source community approach, then there has to be
some sense of openness to community based decision making.  I am willing to
undertake responsility for creating and maintaining a distutils
installation - source and binary, Windows and Linux - for VPython as a stand
alone distribution.  The fact is that I am so unhappy about the current
distribution, that I was pursuing this in any case, and was going to make it
available for PyGeo users. Though I would much prefer to have it on the
VPython site.  And I have no objection to offering PyGeo users the
"all-in-one" distribution that you prefer for the strudents you focus on as
your prime concern.  Though there would have to be some coordination to
assure that the distributions are consistent -  in terms of where files are
place,d for example.  I  have a sense of what I would call general
expectations within the community of Python users of how a third party
module should install (and uninstall).  It is important to me that those
expectations are met. Because I think that the general community of active
Python users is an important audience for VPython.

So I can help you solve the manpower issue as to the distribution, but only
assuming "we" - and I think the we here goes beyond Bruce and myuself -  can
agree as to what is and is not appropriate in terms of how the distribution
behaves.

But let me say directly, I have problems with your wording above. On one
hand we are talking about a more community based approach to VPython and its
future, on the other hand you are talking about what *you* are willing to
rule in or out. Without a clear idea of what your criteria might be.

If your own focus is narrowly on the constituency of physics students, and
you understand their needs quite well, is it possible that someone like
myself who has an idea that VPython could and should have a broader focus,
go his own way with it.  In other words, offer my own distribution - and
essentially fork VPython.

It seems to me that should be totally unnecessary and unfortunate.  But I
also shouldn't need to send you reports of issues as to the current
distribution by certified mail.  I submit you don't see the issues because
you have a narrow focus on a particular constituency.  Looking at it from
the prespective of a broader constituency, ths issues I rasie are quite
obvious.  There is no good reason why all constinuencies needs cannot be
addressed at www.vpython.org.  But it is difficult to work cooperatively if
you seem to think other people  judgment on these matters cannot be relied
upon.


Art

[Visualpython-users] EField in VPython?

[Aaron T. <ti...@ma...>]

Bruce,

Have you (or Ruth or...) made anything similar to EField and Electric 
Field Hockey using VPython?

Just curious,

AT

[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] History and Status?

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

It is simple ignorance that I didn't know that one could produce a
self-executing file using distutils. I had only seen the type that asked you
to go into a DOS command window, get to the appropriate directory, and type
a command line. The availability of a doubleclickable installer would indeed
address one of the issues,  but there are still issues some of which happily
are being addressed by the (much) larger Python community.

The version of Idle created by Dave Scherer and bundled with VPython has
been the subject of intense further development, and with the blessing of
Guido is intended to replace the old pre-Scherer Idle in Python 2.3, which
would obviate the need for any special relationship between it and VPython.

Moreover, the new Idle has an excellent configuration scheme for referencing
help, which will make it unnecessary to tamper with the html documentation
files.

As to the larger issues, there is a tension between the norms of the
community of experts and the needs of nonexperts. Experts are used to
assembling applications from many sources. My views have been strongly
affected by observing experimentally what college students in engineering,
science, and computer science are and are not able to do reliably. What I
found was that it was very important to offer an installer (especially on
Windows, the platform most used by nonexperts) that bundled everything
together in an integrated way (Scherer's idle, Numeric, documentation).
Theoretically this could cause problems, although I've never actually heard
of any in practice, though one can construct a problem artificially if one
tries.

The only way I can see to address the needs of nonexperts, which
historically have hardly been addressed in the Python community, and also be
compatible with the expectations of experts, would be to offer two different
installation schemes: a bundle that does it all (this would for example
include Numeric) and a nonbundle where you install each piece (in
particular, Numeric would be listed separately). Since so far Arthur is the
only person who has complained about this, I haven't been able to make this
a priority, as it does involve extra work. Until very recently there has not
been sufficient people power to address issues such as this, but I certainly
don't rule out providing more installation options in the future.

Bruce Sherwood

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Bruce Sherwood" <bas...@un...>; "John Keck"
<joh...@ho...>; <vis...@li...>
Sent: Sunday, February 16, 2003 6:54 PM
Subject: Re: [Visualpython-users] History and Status?


> > On the specific issue of distutils: It is probably correct that
distutils
> is
> > exactly the right mechanism for all Linux/Unix-like environments,
> including
> > the new Mac OSX 10.2 X11 environment. But it seems a poor mechanism for
> > nonexpert users on Windows, who typically don't have a compiler
available
> > (needed for source distribution) and are not comfortable working in a
> > command prompt window.
>
> You're under a misconception here.  Distutils makes a fine self executing
> installation file for Windows.  I have already prepared one for VPython as
a
> matter of fact - but it is VPython standalone, i.e including VPython demo
> and docs, but not including Numeric or V_Idle.  I personally see no need
to
> integrate the Numeric distribution with VPython.  Its own installation -
> including a Windows self installing executable - is quite expert, and I
> don't see it as a big deal to simply ask people who do not already have
> Numeric to download it seperately.  Unless I am missing something.
>
> In a way, this kind of thing is to me part of the issue. Its a form of not
> playing nice with other Python programs, IMO, to include Numeric in the
> VPython distro.  Numeric has thousands of users.  They should be able to
> download VPython without any fear of having their existing installation
> disturbed  in any way. For those who don't already have Numeric, its an
> extra click or two to install it as a separate distribution.
>
> If "we" want to attract other open source developers, I think we have to
> more carefully follow certain protocols.  I have felt strongly, for
example,
> that it is a bad  mistake to be manipulating the standard Python
index.html
> file. How might I convince you that is a signficant breach of protocol?
>
> Art

Re: [Visualpython-users] History and Status?

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

It is simple ignorance that I didn't know that one could produce a
self-executing file using distutils. I had only seen the type that asked you
to go into a DOS command window, get to the appropriate directory, and type
a command line. The availability of a doubleclickable installer would indeed
address one of the issues,  but there are still issues some of which happily
are being addressed by the (much) larger Python community.

The version of Idle created by Dave Scherer and bundled with VPython has
been the subject of intense further development, and with the blessing of
Guido is intended to replace the old pre-Scherer Idle in Python 2.3, which
would obviate the need for any special relationship between it and VPython.

Moreover, the new Idle has an excellent configuration scheme for referencing
help, which will make it unnecessary to tamper with the html documentation
files.

As to the larger issues, there is a tension between the norms of the
community of experts and the needs of nonexperts. Experts are used to
assembling applications from many sources. My views have been strongly
affected by observing experimentally what college students in engineering,
science, and computer science are and are not able to do reliably. What I
found was that it was very important to offer an installer (especially on
Windows, the platform most used by nonexperts) that bundled everything
together in an integrated way (Scherer's idle, Numeric, documentation).
Theoretically this could cause problems, although I've never actually heard
of any in practice, though one can construct a problem artificially if one
tries.

The only way I can see to address the needs of nonexperts, which
historically have hardly been addressed in the Python community, and also be
compatible with the expectations of experts, would be to offer two different
installation schemes: a bundle that does it all (this would for example
include Numeric) and a nonbundle where you install each piece (in
particular, Numeric would be listed separately). Since so far Arthur is the
only person who has complained about this, I haven't been able to make this
a priority, as it does involve extra work. Until very recently there has not
been sufficient people power to address issues such as this, but I certainly
don't rule out providing more installation options in the future.

Bruce Sherwood

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Bruce Sherwood" <bas...@un...>; "John Keck"
<joh...@ho...>; <vis...@li...>
Sent: Sunday, February 16, 2003 6:54 PM
Subject: Re: [Visualpython-users] History and Status?


> > On the specific issue of distutils: It is probably correct that
distutils
> is
> > exactly the right mechanism for all Linux/Unix-like environments,
> including
> > the new Mac OSX 10.2 X11 environment. But it seems a poor mechanism for
> > nonexpert users on Windows, who typically don't have a compiler
available
> > (needed for source distribution) and are not comfortable working in a
> > command prompt window.
>
> You're under a misconception here.  Distutils makes a fine self executing
> installation file for Windows.  I have already prepared one for VPython as
a
> matter of fact - but it is VPython standalone, i.e including VPython demo
> and docs, but not including Numeric or V_Idle.  I personally see no need
to
> integrate the Numeric distribution with VPython.  Its own installation -
> including a Windows self installing executable - is quite expert, and I
> don't see it as a big deal to simply ask people who do not already have
> Numeric to download it seperately.  Unless I am missing something.
>
> In a way, this kind of thing is to me part of the issue. Its a form of not
> playing nice with other Python programs, IMO, to include Numeric in the
> VPython distro.  Numeric has thousands of users.  They should be able to
> download VPython without any fear of having their existing installation
> disturbed  in any way. For those who don't already have Numeric, its an
> extra click or two to install it as a separate distribution.
>
> If "we" want to attract other open source developers, I think we have to
> more carefully follow certain protocols.  I have felt strongly, for
example,
> that it is a bad  mistake to be manipulating the standard Python
index.html
> file. How might I convince you that is a signficant breach of protocol?
>
> Art

Re: [Visualpython-users] History and Status?

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

> On the specific issue of distutils: It is probably correct that distutils
is
> exactly the right mechanism for all Linux/Unix-like environments,
including
> the new Mac OSX 10.2 X11 environment. But it seems a poor mechanism for
> nonexpert users on Windows, who typically don't have a compiler available
> (needed for source distribution) and are not comfortable working in a
> command prompt window.

You're under a misconception here.  Distutils makes a fine self executing
installation file for Windows.  I have already prepared one for VPython as a
matter of fact - but it is VPython standalone, i.e including VPython demo
and docs, but not including Numeric or V_Idle.  I personally see no need to
integrate the Numeric distribution with VPython.  Its own installation -
including a Windows self installing executable - is quite expert, and I
don't see it as a big deal to simply ask people who do not already have
Numeric to download it seperately.  Unless I am missing something.

In a way, this kind of thing is to me part of the issue. Its a form of not
playing nice with other Python programs, IMO, to include Numeric in the
VPython distro.  Numeric has thousands of users.  They should be able to
download VPython without any fear of having their existing installation
disturbed  in any way. For those who don't already have Numeric, its an
extra click or two to install it as a separate distribution.

If "we" want to attract other open source developers, I think we have to
more carefully follow certain protocols.  I have felt strongly, for example,
that it is a bad  mistake to be manipulating the standard Python index.html
file. How might I convince you that is a signficant breach of protocol?

Art
>
> David Andersen once put together a distutils package for Linux, but
> unfortunately I never followed up on deploying it. His script is shown
> below. Suggestions are welcome on this; maybe it's ready to go?
>
> Bruce Sherwood
>
> -------------------------------------------------
>
> After wasting a considerable amount of time thinking I had to parse the
> includes and libraries my self, I finally realized the easy way to do it.
>
> Here is a Unix/Linux setup.py:  Impressive that it takes so little code.
>
> #!/usr/bin/env python
> # To use:
> #       python setup.py install
> #
> import sys
> if not hasattr(sys, 'version_info') or sys.version_info <
(2,0,0,'alpha',0):
>     raise SystemExit, "Python 2.0 or later required to build VPython."
> import distutils
> from distutils.core import setup, Extension
> from os import popen3
>
> w,r,e = popen3("gtk-config --cflags gtk gthread")
> gtkconfig = r.read()
> err = e.read()
> if (err):
>     raise ValueErr("Unexpected %s on gtk-config stderr",`err`)
> extra_compile_args = gtkconfig.split()
>
> w,r,e = popen3("gtk-config --libs gtk gthread")
> gtkconfig = r.read()
> err = e.read()
> if (err):
>     raise ValueErr("Unexpected %s on gtk-config stderr",`err`)
> extra_link_args = gtkconfig.split()
>
> setup (name = "cvisual",
>   include_dirs = ["CXX/Include"],
>          ext_modules = [Extension('cvisualmodule',
> ['cvisual.cpp',
> 'CXX/Src/cxx_extensions.cxx',
> 'CXX/Src/cxxextensions.c',
> 'CXX/Src/cxxsupport.cxx',
> 'arrow.cpp',
> 'arrprim.cpp',
> 'box.cpp',
> 'color.cpp',
> 'cone.cpp',
> 'convex.cpp',
> 'curve.cpp',
> 'cylinder.cpp',
> 'display.cpp',
> 'displaylist.cpp',
> 'faceset.cpp',
> 'frame.cpp',
> 'gldevice.cpp',
> 'kbobject.cpp',
> 'label.cpp',
> 'light.cpp',
> 'mouseobject.cpp',
> 'platlinux.cpp',
> 'prim.cpp',
> 'pvector.cpp',
> 'rate.cpp',
> 'ring.cpp',
> 'sphere.cpp',
> 'tmatrix.cpp',
> 'vcache.cpp',
> 'xgl.cpp'],
>     extra_compile_args = extra_compile_args,
>     extra_link_args = extra_link_args,
>     libraries = ["GL","gtkgl"])
>                      ]
>        )
>
> ----- Original Message -----
> From: "Arthur" <ajs...@op...>
> To: "Bruce Sherwood" <bas...@un...>; "John Keck"
> <joh...@ho...>; <vis...@li...>
> Sent: Sunday, February 16, 2003 5:27 PM
> Subject: Re: [Visualpython-users] History and Status?
>
>
> > 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.
> >
> > 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 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.
> >
> > Art
> >
> >
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users