visualpython-users

[Visualpython-users] History and Status?

[John K. <joh...@ho...>]

Bruce,

Thanks for your reply.  Your suggestions and the program example you 
included are very helpful.  Thanks!

VPython is such a great interface.  I can easily imagine that with a few 
more features it could rival IDL.  Plus it's free!  That of course is also 
the primary drawback since it means you don't have a commercial entity 
promoting it and paying for the developer's time.

You mention David Scherer.  I see he is listed on the VPython page first 
among the people who originally worked on the project.  I take it he is the 
leading expert.  I didn't see many other details of project history posted.

I take it David Scherer is no longer involved?  I was just wondering how the 
group was assembled and where everyone is now.  Who's still working on it 
and who is not?  What are they doing?  Are there any plans for further 
development?  If so, what are they?

John




_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: [Visualpython-users] History and Status?

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

----- Original Message -----
From: "John Keck" <joh...@ho...>
To: <vis...@li...>
Cc: <bas...@un...>
Sent: Sunday, February 16, 2003 1:53 PM
Subject: [Visualpython-users] History and Status?


> Bruce,
>
> Thanks for your reply.  Your suggestions and the program example you
> included are very helpful.  Thanks!
>
> VPython is such a great interface.  I can easily imagine that with a few
> more features it could rival IDL.  Plus it's free!  That of course is also
> the primary drawback since it means you don't have a commercial entity
> promoting it and paying for the developer's time.
>
> You mention David Scherer.  I see he is listed on the VPython page first
> among the people who originally worked on the project.  I take it he is
the
> leading expert.  I didn't see many other details of project history
posted.
>
> I take it David Scherer is no longer involved?  I was just wondering how
the
> group was assembled and where everyone is now.  Who's still working on it
> and who is not?  What are they doing?  Are there any plans for further
> development?  If so, what are they?
>
> John

In response to the questions above, here is a post I made on Dec. 29,
followed by Scherer's vision of a different architecture. One other comment.
Arthur Siegel pointed out in response to my note that Boost would be a
better connection between Visual and Python than the old CXX, and I'd like
to thank him for pointing out this newer, supported interface, which we will
probably try to utilize.

Some context and history may be helpful. The creator of Visual, David
 Scherer, left college early to take advantage of an unusual business
 opportunity. That left Ruth Chabay and me as custodians of the project, but
 during the last year and a half or so we were pretty consumed with a major
 move from Carnegie Mellon University to North Carolina State University and
 were unable to exploit a grant from the National Science Foundation to push
 VPython in new and broader directions. Also, our major responsibilities are
 not VPython, so any enhancements or maintenance we were able to undertake
 were necessarily aimed for the most part at supporting our physics
education
 work, though much of this work has been of wider benefit. We finally have
 our feet on the ground at our new institution and plan to use the NSF grant
 resoursces to hire a strong full-time programmer to begin to address wider
 interests and needs of current and potential research and educational
users.

 Also, Scherer has some interesting ideas on a longer-range restructuring of
 the Visual module to make it an open-source project in fact as well as in
 principle. Scherer's original implementation in C++ got VPython running
 amazingly quickly, with excellent capabilities, execution speed, and
 stability. However, the code is rather complex, which has meant in practice
 that no one other than Scherer has felt competent to make major changes to
 the core of Visual. Mind you, no one is preventing anyone from changing
 Visual to suit their own needs, since Visual is an open source project
 housed at sourceforge.net. But the benefits of open source may not be fully
 realizable if the source looks too difficult for newcomers to modify.

 Scherer believes that it could be possible to rewrite Visual with a
 radically different architecture which would have the goal of making it
 feasible for many people to be able to contribute to its further
 development, once the new architecture is in place. A related goal is to
 make the basic graphics capabilities sufficiently "professional" to attract
 the interest and inputs of those people who are very knowledgeable in
 computer graphics. No one is currently working on such a new architecture,
 but Scherer's vision is important, because if the project were truly
 modifable by many people it could more easily and quickly grow or be
 customized to address diverse needs and interests. And if it were made
 interesting to graphics experts that too would stimulate interesting
further
 development.

 Bruce Sherwood

-----------------------------------------------------
A vision by Dave Scherer (written Nov. 2001):

VPython 3000: A thought experiment

This is a collection of ideas about how VPython's architecture might be
improved or replaced.  Some ideas stem from dissatisfaction with some of
the choices made earlier in the VPython development process.  Others are
the result of thinking about how to make VPython's community stronger
and better able to sustain and improve VPython.

I've phrased this in terms of design notes for "VPython 3000",
counterpart to the mythical Python 3000 release.  It might help form an
agenda for a refactoring of Visual.  It might provide a source of ideas
for more incremental improvement.  I hope it will at least provoke
discussion.

These notes should be considered brainstorming - many of these are
probably bad ideas.  Others might not be worth the effort to change.

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

Corollaries:

1a.  Architectural changes that dictate changes in interface are guilty
until proven innocent.

2a.  We should try to avoid maintainership of the peripheral pieces -
like IDLE and CXX - that we use.

3a.  We should move as much functionality into Python as is consistent
with usability and performance.

Architecture:

1.  Python 2.2 supports "properties", a method of calling getter and
setter functions for attribute access that is *much* faster than the
__getattr__ and __setattr__ approach that we used for prototyping
before.  Cursory benchmarking suggests that simple properties can
sometimes be several times faster than the attribute access in the
current C++ implementation!  It might be possible to implement
primitives as Python classes instead of types, or (using another new
feature in 2.2) as Python subclasses of types implemented by cvisual.

2.  Operator overloading, by contrast, is very, very slow in Python for
reasons I can't exactly determine.  The vector library therefore *must*
be implemented in C.  A redesign of the vector library still might be
beneficial: substantial changes in Python since its introduction might
make it much more efficient.  There is a complicated method being used
right now to implement "right hand side" operations like 3 *
vector(1,2,3) that can probably be avoided using newer Python features.
The use of a Python extension type for ordinary vector operations in C++
is probably a mistake as well.

3.  Python threads have substantial advantages over native threads
created from C: they can safely run Python code, they can safely share
Python data structures, and most synchronization is handled
transparently by Python.  Python achieves this by using *extremely*
coarse-grained locking (one global lock).  This can be a big performance
problem.  It might perform fine for us if rendering operations release
the lock while running: the renderer thread should spend the vast
majority of its time rendering primitives.  Rendering functions would
have to make a local copy of instance data before releasing the lock.
This would vastly simplify the implementation, I think.

4.  If cvisual could interoperate with PyOpenGL, we would get several
benefits:

  - PyOpenGL now implements contexts for a variety of different GUI
systems like Tkinter and wxPython.  This definitely answers a FAQ for
VPython.

  - PyOpenGL could be used to prototype implementations of new
primitives, using Python code executing in the renderer thread.  This
would make it much easier for intermediate programmers to create new
primitives.

  - PyOpenGL might be used to parameterize primitives, for example by
creating display lists

  - Non-time-critical parts of the renderer, like per-frame operations,
could be written in Python

  - OpenGL code might be used directly to do 2D drawing in the GL window

  - PyOpenGL currently attracts an audience interested in graphics
programming (but not necessarily expert).  These people could benefit
from VPython while getting started, and in time would be able to
contribute enormously.

5.  CXX is a minor maintenance burden.  It would be nice to be able to
use the latest version rather than maintaining our own.  If our needs
for Python-C interfacing can be made simple enough in light of #1, it
might even be worth writing directly to the Python API.

6.  It would be nice to be able to use OpenGL transform and lighting,
since that would make more use of hardware acceleration and also make
programming extensions easier in many cases.  The key reason that we did
not choose this route before is that OpenGL implementations often do not
preserve double precision internally, so very large and very small world
spaces caused failures.  It might be that with sufficient cleverness we
can get the best of both worlds.  For example, when rendering a simple
object like a cube, the *final* transform matrix maps a fixed local
space (perhaps [0,1]^3) to a fixed screen space, and therefore shouldn't
contain very large or very small terms merely because the world scale is
large or small.  In that particular case, it might suffice to merely do
matrix multiplications in double precision, and project individual
points in hardware.  Similarly, maybe an internally-maintained global
scale factor could be used to keep "world space" always about the same
size.

7.  It might be nice to implement "rigid" primitives as triangle lists
(like "faces").  This provides one mechanism for creating new
primitives.  It also makes implementing things like transparency easier.

8.  Mouse and keyboard interaction might be done from the user thread
(e.g. do ray intersection tests when the programmer asks for
scene.mouse.pick rather than every frame)

Features:

1.  A slightly less procedural graphing interface.  It would be very
useful for programs to be able to throw off data in a table, and have
the user as well as the program able to switch between tabular and
graphical views of the data, or export it to excel or a text file.  It
would be nice to have very high-quality graphs.  It would be nice to
have printable graphs.

2.  Transparency.  It will be easier to get it as part of a refactoring
than any other way.  It may be easier to implement transparency for some
primitives than for others.

3.  It would be nice to have good tools for displaying images.  Lots of
neat things could be done by mapping a Numeric array into colors and
displaying it on the screen.  It would be nice to do something similar
with textures, even if only for a simple textured plane object.  A
*transparent* textured plane would be especially cool.  A textured
"particle" or "sprite" object would be nice.

4.  Textured text.

5.  More effective ways to "lock" updates of different objects together,
ideally without blocking rendering entirely.  This would be more
plausible with the outer rendering loop written in Python.

6.  "Higher-order" primitives.  For example:

 PrimitiveCloud( pos=[ (0,0,0), (1,0,0), (2,0,0) ],
                      item = sphere )

 would create three spheres at the specified positions, and
perhaps optimize their rendering (e.g. with OpenGL display lists).
Updating the position array would update the positions of the
primitives, and could be done faster (and more atomically) than looping
through the primitives

7.  More control over the renderer's use of processor power (update rate
vs. frame rate).  Lock-step rendering mode (1 update, 1 frame)

8.  A scheme for picking and examining objects.  Graphs of object
variables on demand.

9.  2D (pixel space) drawing.  Functions for 3D to 2D projection.

10.  scene.setcamera(pos = vector(1,2,3), lookat = vector(0,0,0))

Dave

Re: [Visualpython-users] History and Status?

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

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

Re: [Visualpython-users] History and Status?

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

Note that the ideas are Scherer's -- I can't take any credit for them. But
it's a very good vision.

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.

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
>
>
>

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

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

[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

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...>]

[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] 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] 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] 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...>]

> 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?

[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?

[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...>]

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?

[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?

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

----- Original Message -----
From: "Bruce Sherwood" <bas...@un...>
To: "Arthur" <ajs...@op...>
Cc: "vpusers" <vis...@li...>
Sent: Monday, February 17, 2003 11:25 PM
Subject: Re: [Visualpython-users] History and Status?


> 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?


The thing to understand is that distutils has a duel role.  From the point
of view of the developer/distributor it is a tool to build distributions.
From the point of the of the enduser it *can* be used - when necessary - to
install distributions.

In terms of the Windows .exe it is purely a distributors tool.   As long as
the distributor has the tools to build -  I use VC6 - the cvisual.pyd (or
.dll) then the distutils with (the correct setup.py) is a tool to build a
VPython.exe that will install on any Windows machine - quite elegantly,
IMO - with a double click.  The command to build the executable is
"python setup.py bdist_wininst".  A Windows executable is thereby created
and placed in the "dist" directory of the build tree.  that executable is
distributable and will work for any normal Windows machine - with no need
for that machine to have a compiler.

Hope that is clear.

Try it.

Its cool.

Art

Re: [Visualpython-users] History and Status?

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

Thanks! Definitely cool.

----- Original Message -----
From: "Arthur" <ajs...@op...>


> The thing to understand is that distutils has a duel role.  From the point
> of view of the developer/distributor it is a tool to build distributions.
> From the point of the of the enduser it *can* be used - when necessary -
to
> install distributions.
>
> In terms of the Windows .exe it is purely a distributors tool.   As long
as
> the distributor has the tools to build -  I use VC6 - the cvisual.pyd (or
> .dll) then the distutils with (the correct setup.py) is a tool to build a
> VPython.exe that will install on any Windows machine - quite elegantly,
> IMO - with a double click.  The command to build the executable is
> "python setup.py bdist_wininst".  A Windows executable is thereby created
> and placed in the "dist" directory of the build tree.  that executable is
> distributable and will work for any normal Windows machine - with no need
> for that machine to have a compiler.
>
> Hope that is clear.
>
> Try it.
>
> Its cool.
>
> Art

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?

[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?

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

> 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.


Joe 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.
>

Joe-

There is something hot off the press on Mac package installation issues:
http://mail.python.org/pipermail/catalog-sig/2003-February/000337.html

Jack Jansen is the main guy maintaining the Python for Mac distribution. The
Python community loves controversy. I only know about this because of a
thread trying to talk Jack out of the naming he has decided upon for his
Package Install Manager for Python: pimp. :)

The Mac issues are  mostly however Greek to me - but pimp certainly sounds
like something that should be explored as the possible solution to VPython
Mac distribution issues.

Art

Re: [Visualpython-users] History and Status?

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

I enjoyed working/playing today with the distutils package Arthur so
helpfully provided. This was on Windows, making and testing binary
installers, with and without IDLE, etc. Very nice, very convenient. Even
does a perfect job of cleaning up on an uninstall from the "Add/remove
program" control panel.

Consider for the moment the case of a complete turnkey bundle for newcomers
(ideally, a single installer for Python, Numeric, Visual and its docs and
demos, idlefork until it gets into the regular Python distribution, and less
ideally two or three installers). A rather important piece of this is
something that I don't see how to do with distutils, which is to provide a
desktop shortcut (alias) to the editing environment (idlefork). This
shortcut is created by the current VPython installer on Windows, which also
puts an entry on the Python section of the Start menu.

Any ideas on how to address that in the distutils scheme of things?

A related question is whether there is a way in distutils to refer
symbolically to the directory where Python is found (normally C:\PythonXX,
but a user can install it anywhere). That would be a piece of constructing a
shortcut (alias). I even tried including a shortcut that could be dragged
from site-packages\visual onto the desktop, but alas a shortcut must have
absolute file references.

It isn't absolutely necessary to find a distutils solution to this, because
there is really only one situation where this comes up, a novice-oriented
bundled binary installer for Windows, and I can continue building such a
thing using other tools, letting distutils handle all other situations
(presumably in source form). I would however change the installation
locations to those that Arthur and others have championed -- everything in
site-packages\visual (visual, docs, demos, idlefork).

Incidentally, I very hastily tried using the distutils installer on Mac OSX
in the X11 framework and was told, "gcc: cannot specify -o with -c or -S and
multiple compilations". I'm guessing this has to do with the
"extra_compile_args" at the start of setup.py, which look like they're set
for Windows?

Bruce Sherwood

Re: [Visualpython-users] History and Status?

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

Any idea why distutils isn't an answer to these problems? Is it the
dependencies in a source distribution on whether other libraries are
present? I read Jansen's note and it doesn't mention distutils at all.

Bruce Sherwood

----- Original Message -----
From: "Arthur" <ajs...@op...>
>
> There is something hot off the press on Mac package installation issues:
> http://mail.python.org/pipermail/catalog-sig/2003-February/000337.html
>
> Jack Jansen is the main guy maintaining the Python for Mac distribution.
The
> Python community loves controversy. I only know about this because of a
> thread trying to talk Jack out of the naming he has decided upon for his
> Package Install Manager for Python: pimp. :)
>
> The Mac issues are  mostly however Greek to me - but pimp certainly sounds
> like something that should be explored as the possible solution to VPython
> Mac distribution issues.
>
> Art

Re: [Visualpython-users] History and Status?

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

It terms of concrete effort, I will be pursuing the extension to the
setup.py for VPython I did, so that it will be workable with Linux. Other
than my own learning curve to refamiliarize myself with certain Linux
issues, should not be a big deal.  As Bruce notes, the actual Linux setup.py
is essentially  already there - its really just a matter of testing for
platform and branching appropriately.

Should be able to get it to be basically functional, with the place of docs,
demso somewhere - as a draft - pending more discussion.

But the iterator thingy (technical term) issue is on my mind.

I am working with a recent Linux install, therefore gcc3.xx.

Am I correct in assuming that the fix to the CXX file needed to compile on
gcc > 3 does not break anything if compiling under a gcc < 3.  Which would
raise the question why it was there at all.  There is probably a way to test
for gcc version and fork accordingly, but I don't know if its necessary.

Anybody?

Art