visualpython-users

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

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] Re: compiling vpython with gcc 3.2 (linux)

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

On Fri, 2003-02-14 at 15:43, Andy Dougherty wrote: 
> On Fri, 14 Feb 2003, Jonathan Brandmeyer wrote:
> 
> > The option to inherit Py::SeqBase::iterator from
> > std::random_access_iterator<> has been removed, now it inherits from
> > std::iterator<>.  STANDARD_LIBRARY_ITERATOR_TRAITS is no longer needed, and
> > has been removed.  This should comply with the standard, and has been tested
> > with g++ 3.2.1
> 
> I was afraid that's what you meant :-(.  I don't think it will work with
> somewhat older systems.  For example, in both Debian 3.0 ("woody") and
> RedHat 7.0 systems the 'std::iterator<>' stuff in
> /usr/include/g++-3/iterator.h is surrounded by
Woody includes gcc 3.0.4 in addition to 2.95.4.  On my Woody system,
iterator traits are available when compiled with gcc-3.0.  ABI
differences between compiler versions seem to be glossed-over by using
extern C {} functions to reveal cvisualmodule.so to the interpreter. 

Iterator traits' availability has been tested with gcc-3.0.4, 3.2.1, and
MSVC6.  Indirect reports show that iterator traits are available under
CodeWarrier7, and gcc-2.95 (Apple special). 
 
> I think a better "fix" would be to leave the comment and #define in
> CXX_Config.h, but change the default value of the
> STANDARD_LIBRARY_ITERATOR_TRAITS #define to match the current standard.
> 
> Specifically, I had in mind something like this:
> 
> diff -r -u VPython/cvisual/CXX/Include/CXX_Config.h VPython-andy/cvisual/CXX/Include/CXX_Config.h
> --- VPython/cvisual/CXX/Include/CXX_Config.h	Mon Jul 22 16:03:01 2002
> +++ VPython-andy/cvisual/CXX/Include/CXX_Config.h	Thu Feb 13 15:52:02 2003
> @@ -2,7 +2,7 @@
>  #define __py_config_hh__
>  // Macros to deal with deficiencies in compilers
>  #define COMPILER_SUPPORTS_NAMESPACES 1
> -#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 1
> +#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 0
Backwards.  STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 1 is the ISO-compliant
answer.  Otherwise, the header will cause inheritance from
std::random_access_iterator. 

So long as it does not continue to cause problems on the ISO-comliant
compilers, I think we can keep the macro as an available option.  I
thought about using __GNUC__ < 3 as an identifier for non-compliance,
except that an older Mac GCC was a 2.95 build that supported iterator
traits.  It is currently much harder to determine which compilers are
not in compliance than those which are. Therefore, I plan to not add any
automatic detection, and let the user manually flip the value if
absolutely required (ex. RH 7). 

Alternatively, I would prefer to use an autoconf test for the job.  It
is an area I have marked for research, and a contributed configure.in
would be gratefully accepted.  Using ./configure && make is an
intermediate-term goal that the team is persuing for source
distributions. 

-Jonathan 

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

[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] Connecting VPython to Adobe Atmosphere?

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

Seems very unlikely, since Atmosphere seems to be a proprietary development
and presumably not open to grafting in some completely different program. I
don't even know what it would mean to "integrate VPython into this
environment."

Bruce Sherwood

----- Original Message -----
From: "Tom Munnecke" <mun...@st...>
To: <vis...@li...>
Sent: Saturday, February 15, 2003 12:31 PM
Subject: [Visualpython-users] Connecting VPython to Adobe Atmosphere?


> I have just stumbled on the Adobe Atmosphere 3D world environment at
> http://www.adobe.com/products/atmosphere
>
> Quite impressive world builder, Javascript API, etc.  It has
> transparency, fog, and lots of navigational stuff, chat rooms, etc.
> still in beta.
>
> What would be the possibility of integrating Vpython into this
> environment
>
>
>
> -------------------------------------------------------
> 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
>
>

[Visualpython-users] Connecting VPython to Adobe Atmosphere?

[Tom M. <mun...@st...>]

I have just stumbled on the Adobe Atmosphere 3D world environment at
http://www.adobe.com/products/atmosphere 

Quite impressive world builder, Javascript API, etc.  It has
transparency, fog, and lots of navigational stuff, chat rooms, etc.
still in beta.

What would be the possibility of integrating Vpython into this
environment

Re: [Visualpython-users] Re: compiling vpython with gcc 3.2 (linux)

[Andy D. <dou...@la...>]

On Fri, 14 Feb 2003, Jonathan Brandmeyer wrote:

> The option to inherit Py::SeqBase::iterator from
> std::random_access_iterator<> has been removed, now it inherits from
> std::iterator<>.  STANDARD_LIBRARY_ITERATOR_TRAITS is no longer needed, and
> has been removed.  This should comply with the standard, and has been tested
> with g++ 3.2.1

I was afraid that's what you meant :-(.  I don't think it will work with
somewhat older systems.  For example, in both Debian 3.0 ("woody") and
RedHat 7.0 systems the 'std::iterator<>' stuff in
/usr/include/g++-3/iterator.h is surrounded by

    #if 0
    using __STD::iterator;
    #endif

I think a better "fix" would be to leave the comment and #define in
CXX_Config.h, but change the default value of the
STANDARD_LIBRARY_ITERATOR_TRAITS #define to match the current standard.

Specifically, I had in mind something like this:

diff -r -u VPython/cvisual/CXX/Include/CXX_Config.h VPython-andy/cvisual/CXX/Include/CXX_Config.h
--- VPython/cvisual/CXX/Include/CXX_Config.h	Mon Jul 22 16:03:01 2002
+++ VPython-andy/cvisual/CXX/Include/CXX_Config.h	Thu Feb 13 15:52:02 2003
@@ -2,7 +2,7 @@
 #define __py_config_hh__
 // Macros to deal with deficiencies in compilers
 #define COMPILER_SUPPORTS_NAMESPACES 1
-#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 1
+#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 0
 
 #ifdef MS_WIN32
 #undef STANDARD_LIBRARY_HAS_ITERATOR_TRAITS
diff -r -u VPython/cvisual/CXX/README.htm VPython-andy/cvisual/CXX/README.htm
--- VPython/cvisual/CXX/README.htm	Mon Jul 22 16:03:01 2002
+++ VPython-andy/cvisual/CXX/README.htm	Fri Feb 14 15:41:30 2003
@@ -13,6 +13,19 @@
 set the environment variables LINKCC to 'g++' and LDSHARED to 'g++ -shared'
 or whatever is appropriate for your C++ compiler.
 <h2>
+std iterator problems</h2>
+<p>
+Cvisual uses std::iterator from the standard library.  
+If you encounter error messages such as
+<pre>no class template named `iterator' in `std'</pre>
+then edit Include/CXX_Config.h and change
+<pre>#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 0</pre> to
+<pre>#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 1</pre>.
+This will cause cvisual to use random_access_iterator instead.
+This was present in early draft C++ standards, and is implemented in
+the C++ libraries in a number of Linux distributions, including RedHat
+7.0 and Debian 3.0.
+<h2>
 Version 4 (February, 2000)</h2>
 CXX compiles with gcc - 2.95. Includes new version of extension portion
 by Barry Scott.&nbsp; I have personally only tested this on RH Linux 6.&nbsp;

-- 
    Andy Dougherty		dou...@la...
    Dept. of Physics
    Lafayette College, Easton PA 18042

Re: [Visualpython-users] transparency, no-shadow objects, r --> infinity

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

I emphasize that I myself know no more about the transparency issue than you
or anyone else who read David Scherer's analysis! So I can't address
questions on that.

Concerning a backdrop a long ways away, the only thing you can do is put
very large objects a very long ways away. Just like in real life!

Here's a little program that shows the Earth going around the Sun, with the
Sun shining uniformly brightly and the Earth always lit only on the side
facing the Sun. It's based on a note from Dave Scherer a while back that if
you deliberately set a color to have components greater than 1, you happen
to get a behavior rather like what you want. The only other thing that's
needed is to continually move the light. This won't work if you want to show
the whole Solar System, because the single faraway light source can
continually point at only one of the planets.

from visual import *
from __future__ import division

scene.lights = [vector(-1,0,0)]
G = 6.7e-11 # gravitational constant
L = 1.5e11 # distance from Sun to Earth
# For the Sun, deliberately set color intensity much larger than 1:
Sun = sphere(pos=(0,0,0), radius=L/10, color=(10,10,0))
Earth = sphere(pos=(L,0,0), radius=L/20, color=color.cyan)
Sun.mass = 2e30
Earth.mass = 6e24
Earth.p = Earth.mass*vector(0,3e4,0) # initial momentum
dt = 24*60*60 # time step of one day

while 1:
    rate(100)
    r = Sun.pos-Earth.pos
    scene.lights = [norm(r)]
    F = (G*Sun.mass*Earth.mass/mag(r)**2)*norm(r)
    Earth.p += F*dt
    Earth.pos += (Earth.p/Earth.mass)*dt

Bruce Sherwood

For the other questions,
----- Original Message -----
From: "John Keck" <joh...@ho...>
To: <vis...@li...>
Sent: Friday, February 14, 2003 1:17 PM
Subject: [Visualpython-users] transparency, no-shadow objects, r -->
infinity


> Bruce,
>
> Thanks for the reply on opacity.  It was helpful, but it opens up new
> questions for me.
>
> <<These problems can be solved for triangles, but the solution involves
> things
> like clipping.  Solving it for entire Visual primitives seems impractical,
> so we would have to do something like:
>
> 1.  Render all opaque objects
> 2.  Break all transparent objects into triangles, and store the triangles
> 3.  Find any pairs of triangles not separated by a plane and split them
> 4.  Sort the triangles (using separating planes)
> 5.  Render the triangles
>
> If you want to do some research on the topic, you will usually see it
> referred to as "Painter's algorithm" or "depth sorting".
> >>
>
> It sounds like the real difficulty with implementing transparency is
> intersecting objects.  But isn't this also a difficulty for completely
> opaque objects as well?  How does VPython get around that difficulty for
> opaque objects?  How is this solution different from that for transparent
> objects?
>
> While we're on a similar subject, I'm guessing it would be simple to
> implement objects whose display color doesn't depend on the scene
lighting.
> I was trying to produce the Sun in a gravity demo I'm writing, but then I
> realized that it would look silly for the Sun to have a shaded side.  Is
> there perhaps an option for this already?  (I'm guessing that having light
> actually coming from a point inside the scene instead of off-stage from
> infinity would be difficult to realize.)
>
> Also, it is possible to have a wall-paper background at infinity, or at
> least to put objects of finite angular size at infinity?  I wanted to
> implement a star-field in my gravity demo, so that there'd actually be
some
> semi-realistic way to "see" a black hole against the star-field (plus also
> to give a sense of orientation to movement through the vacuum of space).
>
> Thanks,
>
> John Keck
>
>
> _________________________________________________________________
> MSN 8 with e-mail virus protection service: 2 months FREE*
> http://join.msn.com/?page=features/virus
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

Re: [Visualpython-users] Re: compiling vpython with gcc 3.2 (linux)

[Jonathan B. <jdb...@un...>]

The option to inherit Py::SeqBase::iterator from
std::random_access_iterator<> has been removed, now it inherits from
std::iterator<>.  STANDARD_LIBRARY_ITERATOR_TRAITS is no longer needed, and
has been removed.  This should comply with the standard, and has been tested
with g++ 3.2.1

You can read the comments in CVS here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/visualpython/
in cvisual/CXX/Include/
and /cvisual/CHANGELOG.

I will update the documentation comment, too.

-Jonathan

----- Original Message -----
From: "Andy Dougherty" <...>
To: "Jonathan Brandmeyer" <...>
Sent: Friday, February 14, 2003 8:44 AM
Subject: Re: [Visualpython-users] Re: compiling vpython with gcc 3.2 (linux)


> On Fri, 14 Feb 2003, Jonathan Brandmeyer wrote:
>
> > It's fixed in CVS as of last night.
>
> Do you mean the CXX_Config.h comment is updated, or you've changed the
> default value of the STANDARD_LIBRARY_HAS_ITERATOR_TRAITS #define?
>
> --
>     Andy Dougherty dou...@la...
>     Dept. of Physics
>     Lafayette College, Easton PA 18042
>
>
>

[Visualpython-users] transparency, no-shadow objects, r --> infinity

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

Bruce,

Thanks for the reply on opacity.  It was helpful, but it opens up new 
questions for me.

<<These problems can be solved for triangles, but the solution involves 
things
like clipping.  Solving it for entire Visual primitives seems impractical,
so we would have to do something like:

1.  Render all opaque objects
2.  Break all transparent objects into triangles, and store the triangles
3.  Find any pairs of triangles not separated by a plane and split them
4.  Sort the triangles (using separating planes)
5.  Render the triangles

If you want to do some research on the topic, you will usually see it
referred to as "Painter's algorithm" or "depth sorting".
>>

It sounds like the real difficulty with implementing transparency is 
intersecting objects.  But isn't this also a difficulty for completely 
opaque objects as well?  How does VPython get around that difficulty for 
opaque objects?  How is this solution different from that for transparent 
objects?

While we're on a similar subject, I'm guessing it would be simple to 
implement objects whose display color doesn't depend on the scene lighting.  
I was trying to produce the Sun in a gravity demo I'm writing, but then I 
realized that it would look silly for the Sun to have a shaded side.  Is 
there perhaps an option for this already?  (I'm guessing that having light 
actually coming from a point inside the scene instead of off-stage from 
infinity would be difficult to realize.)

Also, it is possible to have a wall-paper background at infinity, or at 
least to put objects of finite angular size at infinity?  I wanted to 
implement a star-field in my gravity demo, so that there'd actually be some 
semi-realistic way to "see" a black hole against the star-field (plus also 
to give a sense of orientation to movement through the vacuum of space).

Thanks,

John Keck


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus

Re: [Visualpython-users] Re: compiling vpython with gcc 3.2 (linux)

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

Excellent! Thanks, Jonathan.

Bruce Sherwood

----- Original Message -----
From: "Jonathan Brandmeyer" <jdb...@un...>
To: <vis...@li...>
Sent: Friday, February 14, 2003 7:31 AM
Subject: [Visualpython-users] Re: compiling vpython with gcc 3.2 (linux)


> It's fixed in CVS as of last night.
>
> -Jonathan
>
> > From: "Bruce Sherwood" <bas...@un...>
> > To: "vpusers" <vis...@li...>
> > Cc: "Hans Fangohr" <H.F...@so...>
> > Subject: Re: [Visualpython-users] compiling vpython with gcc 3.2 (linux)
> > Date: Thu, 13 Feb 2003 14:07:39 -0500
> >
> > Kevin Cole reported this:
> >
> > In my case, I had to change cvisual/CXX/CXX_Config.h, as suggested
> >    by the README.htm in that directory -- though I was a bit surprised,
> >    considering the date mentioned:
> >
> >    ================================================================
> >    Version 3 (June 18, 1999)
> >
> >    1.  CXX compiles with EGCS snapshot 19990616. EGCS requires a
> >        standard library class random_access_iterator that is not
> >        yet available in some other compilers (such as Windows VC6).
> >        Therefore a new switch:
> >
> >             STANDARD_LIBRARY_HAS_ITERATOR_TRAITS
> >
> >        has been added to CXX_Config.h that you may need to toggle
> >        if you get an error on the two lines that mention
> >        random_access_iterator. The current definition is correct
> >        for VC6 and EGCS-19990616.
> >    ================================================================
> >
> > Andy Dougherty added this:
> >
> > The following comments about random_access_iterator from the
stl_iterator
> > documentatino on my Debian system (libstdc++2.10-dev) might help clear
up
> > the confusion:
> >
> >    Defined in the standard header iterator, and in the nonstandard
> >    backward-compatibility header iterator.h. This class is no longer
part
> >    of the C++ standard, although it was present in early drafts of the
> >    standard. It is retained in this implementation for backward
> >    compatibility.
> >
> > ----- Original Message -----
> > From: "Hans Fangohr" <H.F...@so...>
> > To: <vis...@li...>
> > Sent: Thursday, February 13, 2003 1:16 PM
> > Subject: [Visualpython-users] compiling vpython with gcc 3.2 (linux)
> >
> >
> > > Greetings,
> > >
> > > I tried to compile vpython on a SuSE 8.1 system with gcc3.2.
> > >
> > > Here is the error I encounter - is this a gcc3-issue, or some other
> > > known problem?
> > >
> > > :~/build/VPython/cvisual # make
> > >
> >
>
g++ -I. -I./CXX/Include -I/usr/include/python2.2  -I/usr/include/gtk-1.2 -I/
> >
>
usr/include/glib-1.2 -I/usr/lib/glib/include -D_REENTRANT -I/usr/X11R6/inclu
> > de -w   -c -o arrow.o arrow.cpp
> > > In file included from pvector.h:6,
> > >                  from cvisual.h:6,
> > >                  from display.h:5,
> > >                  from prim.h:5,
> > >                  from axial.h:5,
> > >                  from arrow.cpp:1:
> > > CXX/Include/CXX_Objects.h:967: no class template named
> > `random_access_iterator'
> > >    in `std'
> > > CXX/Include/CXX_Objects.h:1077: no class template named
> > `random_access_iterator
> > >    ' in `std'
> > > make: *** [arrow.o] Error 1
> > >
> > > Thanks,
> > >
> > > Hans
> > >
> > >
> > >
> > > For completeness, the output of "gcc -v":
> > >
> > > :~/build/VPython/cvisual # gcc -v
> > > Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.2/specs
> > > Configured with:
> >
>
../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/l
> >
>
ocal --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --e
> >
>
nable-languages=c,c++,f77,objc,java,ada --enable-libgcj --with-gxx-include-d
> >
>
ir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared -
> > -enable-__cxa_atexit i486-suse-linux
> > > Thread model: posix
> > > gcc version 3.2
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> > > are you planning your Web Server Security? Click here to get a FREE
> > > Thawte SSL guide and find the answers to all your  SSL security
issues.
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> > > _______________________________________________
> > > Visualpython-users mailing list
> > > Vis...@li...
> > > https://lists.sourceforge.net/lists/listinfo/visualpython-users
> > >
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

[Visualpython-users] Re: compiling vpython with gcc 3.2 (linux)

[Jonathan B. <jdb...@un...>]

It's fixed in CVS as of last night.

-Jonathan

> From: "Bruce Sherwood" <bas...@un...>
> To: "vpusers" <vis...@li...>
> Cc: "Hans Fangohr" <H.F...@so...>
> Subject: Re: [Visualpython-users] compiling vpython with gcc 3.2 (linux)
> Date: Thu, 13 Feb 2003 14:07:39 -0500
>
> Kevin Cole reported this:
>
> In my case, I had to change cvisual/CXX/CXX_Config.h, as suggested
>    by the README.htm in that directory -- though I was a bit surprised,
>    considering the date mentioned:
>
>    ================================================================
>    Version 3 (June 18, 1999)
>
>    1.  CXX compiles with EGCS snapshot 19990616. EGCS requires a
>        standard library class random_access_iterator that is not
>        yet available in some other compilers (such as Windows VC6).
>        Therefore a new switch:
>
>             STANDARD_LIBRARY_HAS_ITERATOR_TRAITS
>
>        has been added to CXX_Config.h that you may need to toggle
>        if you get an error on the two lines that mention
>        random_access_iterator. The current definition is correct
>        for VC6 and EGCS-19990616.
>    ================================================================
>
> Andy Dougherty added this:
>
> The following comments about random_access_iterator from the stl_iterator
> documentatino on my Debian system (libstdc++2.10-dev) might help clear up
> the confusion:
>
>    Defined in the standard header iterator, and in the nonstandard
>    backward-compatibility header iterator.h. This class is no longer part
>    of the C++ standard, although it was present in early drafts of the
>    standard. It is retained in this implementation for backward
>    compatibility.
>
> ----- Original Message -----
> From: "Hans Fangohr" <H.F...@so...>
> To: <vis...@li...>
> Sent: Thursday, February 13, 2003 1:16 PM
> Subject: [Visualpython-users] compiling vpython with gcc 3.2 (linux)
>
>
> > Greetings,
> >
> > I tried to compile vpython on a SuSE 8.1 system with gcc3.2.
> >
> > Here is the error I encounter - is this a gcc3-issue, or some other
> > known problem?
> >
> > :~/build/VPython/cvisual # make
> >
>
g++ -I. -I./CXX/Include -I/usr/include/python2.2  -I/usr/include/gtk-1.2 -I/
>
usr/include/glib-1.2 -I/usr/lib/glib/include -D_REENTRANT -I/usr/X11R6/inclu
> de -w   -c -o arrow.o arrow.cpp
> > In file included from pvector.h:6,
> >                  from cvisual.h:6,
> >                  from display.h:5,
> >                  from prim.h:5,
> >                  from axial.h:5,
> >                  from arrow.cpp:1:
> > CXX/Include/CXX_Objects.h:967: no class template named
> `random_access_iterator'
> >    in `std'
> > CXX/Include/CXX_Objects.h:1077: no class template named
> `random_access_iterator
> >    ' in `std'
> > make: *** [arrow.o] Error 1
> >
> > Thanks,
> >
> > Hans
> >
> >
> >
> > For completeness, the output of "gcc -v":
> >
> > :~/build/VPython/cvisual # gcc -v
> > Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.2/specs
> > Configured with:
>
../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/l
>
ocal --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --e
>
nable-languages=c,c++,f77,objc,java,ada --enable-libgcj --with-gxx-include-d
>
ir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared -
> -enable-__cxa_atexit i486-suse-linux
> > Thread model: posix
> > gcc version 3.2
> >
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> > are you planning your Web Server Security? Click here to get a FREE
> > Thawte SSL guide and find the answers to all your  SSL security issues.
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> > _______________________________________________
> > Visualpython-users mailing list
> > Vis...@li...
> > https://lists.sourceforge.net/lists/listinfo/visualpython-users
> >

Re: [Visualpython-users] translucency in Visual Python

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

Yes, eventually there needs to be some restructuring of Visual to be able to
take advantage of the increasing capabilities of graphics cards. (Right now
for technical reasons Visual basically only asks for triangles to be drawn.)
Whether transparency is one of the things the cards can give us "for free" I
do not know.

Bruce Sherwood

----- Original Message -----
From: "Bruce Peterson" <bap...@te...>
To: <vis...@li...>
Sent: Thursday, February 13, 2003 3:02 PM
Subject: [Visualpython-users] translucency in Visual Python


> It struck me when reading some of the discussion about the challenges
> involved in implementing translucency in VP -- than many of the higher end
> graphics cards now claim to implement OGL primitives in hardware. Has
> anybody looked at whether translucency (display ordering) is something
that
> can be passed to hardware? Ideally this would lead to a version of VP with
> the current behavior for graphics hardware not supporting translucency and
> to the desired behavior for those with appropriate hardware.
>
> Bruce Peterson
> 425 466 7344
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

[Visualpython-users] translucency in Visual Python

[Bruce P. <bap...@te...>]

It struck me when reading some of the discussion about the challenges 
involved in implementing translucency in VP -- than many of the higher end 
graphics cards now claim to implement OGL primitives in hardware. Has 
anybody looked at whether translucency (display ordering) is something that 
can be passed to hardware? Ideally this would lead to a version of VP with 
the current behavior for graphics hardware not supporting translucency and 
to the desired behavior for those with appropriate hardware.

Bruce Peterson
425 466 7344

Re: [Visualpython-users] compiling vpython with gcc 3.2 (linux)

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

Kevin Cole reported this:

In my case, I had to change cvisual/CXX/CXX_Config.h, as suggested
   by the README.htm in that directory -- though I was a bit surprised,
   considering the date mentioned:

   ================================================================
   Version 3 (June 18, 1999)

   1.  CXX compiles with EGCS snapshot 19990616. EGCS requires a
       standard library class random_access_iterator that is not
       yet available in some other compilers (such as Windows VC6).
       Therefore a new switch:

            STANDARD_LIBRARY_HAS_ITERATOR_TRAITS

       has been added to CXX_Config.h that you may need to toggle
       if you get an error on the two lines that mention
       random_access_iterator. The current definition is correct
       for VC6 and EGCS-19990616.
   ================================================================

Andy Dougherty added this:

The following comments about random_access_iterator from the stl_iterator
documentatino on my Debian system (libstdc++2.10-dev) might help clear up
the confusion:

   Defined in the standard header iterator, and in the nonstandard
   backward-compatibility header iterator.h. This class is no longer part
   of the C++ standard, although it was present in early drafts of the
   standard. It is retained in this implementation for backward
   compatibility.

----- Original Message -----
From: "Hans Fangohr" <H.F...@so...>
To: <vis...@li...>
Sent: Thursday, February 13, 2003 1:16 PM
Subject: [Visualpython-users] compiling vpython with gcc 3.2 (linux)


> Greetings,
>
> I tried to compile vpython on a SuSE 8.1 system with gcc3.2.
>
> Here is the error I encounter - is this a gcc3-issue, or some other
> known problem?
>
> :~/build/VPython/cvisual # make
>
g++ -I. -I./CXX/Include -I/usr/include/python2.2  -I/usr/include/gtk-1.2 -I/
usr/include/glib-1.2 -I/usr/lib/glib/include -D_REENTRANT -I/usr/X11R6/inclu
de -w   -c -o arrow.o arrow.cpp
> In file included from pvector.h:6,
>                  from cvisual.h:6,
>                  from display.h:5,
>                  from prim.h:5,
>                  from axial.h:5,
>                  from arrow.cpp:1:
> CXX/Include/CXX_Objects.h:967: no class template named
`random_access_iterator'
>    in `std'
> CXX/Include/CXX_Objects.h:1077: no class template named
`random_access_iterator
>    ' in `std'
> make: *** [arrow.o] Error 1
>
> Thanks,
>
> Hans
>
>
>
> For completeness, the output of "gcc -v":
>
> :~/build/VPython/cvisual # gcc -v
> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.2/specs
> Configured with:
../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/l
ocal --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --e
nable-languages=c,c++,f77,objc,java,ada --enable-libgcj --with-gxx-include-d
ir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared -
-enable-__cxa_atexit i486-suse-linux
> Thread model: posix
> gcc version 3.2
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

[Visualpython-users] compiling vpython with gcc 3.2 (linux)

[Hans F. <H.F...@so...>]

Greetings,

I tried to compile vpython on a SuSE 8.1 system with gcc3.2.

Here is the error I encounter - is this a gcc3-issue, or some other
known problem?

:~/build/VPython/cvisual # make
g++ -I. -I./CXX/Include -I/usr/include/python2.2  -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -D_REENTRANT -I/usr/X11R6/include -w   -c -o arrow.o arrow.cpp
In file included from pvector.h:6,
                 from cvisual.h:6,
                 from display.h:5,
                 from prim.h:5,
                 from axial.h:5,
                 from arrow.cpp:1:
CXX/Include/CXX_Objects.h:967: no class template named `random_access_iterator'
   in `std'
CXX/Include/CXX_Objects.h:1077: no class template named `random_access_iterator
   ' in `std'
make: *** [arrow.o] Error 1

Thanks,

Hans



For completeness, the output of "gcc -v":

:~/build/VPython/cvisual # gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.2/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --enable-languages=c,c++,f77,objc,java,ada --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux
Thread model: posix
gcc version 3.2

Re: [Visualpython-users] Re: compiler error under OS 10.2

[Andy D. <dou...@la...>]

On Wed, 12 Feb 2003, Jonathan Brandmeyer wrote:

> Bruce Sherwood wrote:
> > One can compile using gcc, using essentially the same libraries as are
> used
> >  for Linux. Steve Spicklemire came up with minor modifications needed to
> >  compile for Mac OSX, and that's what was used to create the VPython
> >  installer.
> 
> The reason I ask is that current and older GCC (3.2.1 and 2.95.4 on my
> machines) use a standard library that includes std::random_access_iterator.
> This error should only be generated is if a different STL is being used on
> the host system.

The following comments about random_access_iterator from the stl_iterator
documentatino on my Debian system (libstdc++2.10-dev) might help clear up
the confusion:

   Defined in the standard header iterator, and in the nonstandard
   backward-compatibility header iterator.h. This class is no longer part
   of the C++ standard, although it was present in early drafts of the
   standard. It is retained in this implementation for backward
   compatibility.

-- 
    Andy Dougherty		dou...@la...
    Dept. of Physics
    Lafayette College, Easton PA 18042

[Visualpython-users] Re: compiler error under OS 10.2

[Jonathan B. <jdb...@un...>]

Bruce Sherwood wrote:
> One can compile using gcc, using essentially the same libraries as are
used
>  for Linux. Steve Spicklemire came up with minor modifications needed to
>  compile for Mac OSX, and that's what was used to create the VPython
>  installer.

The reason I ask is that current and older GCC (3.2.1 and 2.95.4 on my
machines) use a standard library that includes std::random_access_iterator.
This error should only be generated is if a different STL is being used on
the host system.

Jonathan.

[Visualpython-users] Linux and Mac Unix

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

I sent this note a couple days ago, and I got a copy of it, but it doesn't
appear in the VPython user mailing list archives, so I'm sending it again.
My apologies if you're seeing double.

---------------------------------------------

Recently there has been a flurry of reports of problems trying to compile
Visual and get VPython working on recent versions of Linux, and on the new
X11 environment available on Mac OSX 10.2. I haven't been able to study the
problems myself yet, but I will summarize the reports here. Those users who
have written to me personally but are not subscribed to the VPython user
list may wish to subscribe to participate more fully in whatever mutual aid
there is within the community.

From Kevin Cole came a note that seems to address the issue about
"random_access_iterator":

I had VPython working fine on my 7.2 system, but had a few minor
glitches getting it going on the RH 8.0 Beta after returning from the
Tech Circus last weekend.  In my case, the fixes (after downloading
the latest and greatest from vpython.org) were:

1) Make sure C++ is installed.  (As I recall, in 8.0, the package name
   changes from "gcc-c++" to "gcc-cpp"  but I won't swear to it.  You
   can check w/ the command "rpm -q gcc-cpp" and/or "rpm -q gcc-c++"
   assuming you've installed it using RPM.)
2) Get the Mandrake Numeric RPM.  Pretty current, and it installs no
   fuss, no muss.
3) As the documentation suggests, make sure you know where all your
   python stuff lives.  Red Hat doesn't put any of it in /usr/local.
   So rip "/local" out wherever you see it.  (I can't recall, but
   I think there was somewhere that I had to remove it that wasn't
   mentioned in the documentation.
4) In my case, I had to change cvisual/CXX/CXX_Config.h, as suggested
   by the README.htm in that directory -- though I was a bit surprised,
   considering the date mentioned:

   ================================================================
   Version 3 (June 18, 1999)

   1.  CXX compiles with EGCS snapshot 19990616. EGCS requires a
       standard library class random_access_iterator that is not
       yet available in some other compilers (such as Windows VC6).
       Therefore a new switch:

            STANDARD_LIBRARY_HAS_ITERATOR_TRAITS

       has been added to CXX_Config.h that you may need to toggle
       if you get an error on the two lines that mention
       random_access_iterator. The current definition is correct
       for VC6 and EGCS-19990616.
   ================================================================

Sven Glatthaar reported:

Impressed by the capabilities of vpython I would like to run it using
Redhat 8.0. After fixing the "random_access_iterator"-problem as it is
described in the archive of this mailing list  and running the
install-script successfully another bug occured:
<
Visual-2002-07-22
Traceback (innermost last)
  File "/usr/share/python-visual/Programs/Demos/bounce.py", line 1, in ?
    from visual import *
ImportError: /usr/lib/libgtkgl.so.5: undefined symbol: glXUseXFont

Program disconnected.
 >
As far as I understand libgtkgl.so.5 is part of the
gtkglarea-1.2.2-10.i386.rpm or gtkglarea-1.2.2-10.src.rpm package. Even
an update of this packages to release 13 doesn't help.

Jonathan Brandmeyer offers this perspective on GTK:

For background, GTK2.0 came out in June 2002, and is currently at version
2.2.1.  Gtk1.x is considered obsolete, and the Linux community is migrating
very rapidly to 2.x.

More than one person has contributed the code to make GtkGLArea fully
compliant with GTK2.x.  However, every patch and code contribution to the
tool has died.  The general consensus on the mailing lists is that as of
about September 2002, GtkGLArea is dead.

However, a replacement is available: GtkGLExt.  This library allows you to
make *any* GTK widget capable of displaying OpenGL stuff.  This project is
under active development, is more complete with regard to GL support, has
fewer bugs, and is compatible with Gtk2.x.  The catch is that GtkGLExt is
_not_ compatible with GTK1.2, and probably never will be.  This means that
older distributions will not be able to support the software,  including the
Linux setup that NCSU currently uses.  Every current distribution of Linux
uses GTK2.x today, so this may not be a serious problem for long.

The added bonus is that GtkGLExt has a close cousin: GtkGLExtmm, a C++ class
interface to the GL.  Basically, if you want a window class that shows GL,
you create a class that inherits from Gtk::GL::Widget and Gtk::Window, and
POOF!  You have a window widget that displays OpenGL.

Extra bonus: Gtk and GtkGLExt run on MS Windows, too.

Joe Heafner reported this concerning the Mac:

You may be interested in the thread I started on VPython on 10.2 in the
Mac OS X > Using Technologies > Unix discussion board on Apple's web
site. Someone has tried compiling Visual under 10.2 and has come across
some issues (too complicated for me to try to include here). Note that
he edited the install script to not install numeric and to not create a
.xinitrc file (Apple's X11 doesn't need one unless you use a window
manager other than the default quartz-wm).

[Visualpython-users] Re: compile error under OS 10.2

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

Whoops, sorry about the subject line...

> Date: Mon, 10 Feb 2003 15:48:57 -0500
> From: Joe Heafner <hea...@vn...>
> To: Vis...@li...
> Subject: [Visualpython-users] compile error under OS 10.2
>
> I'm relaying this from William Scott at UCSC:
>
> > Well, I got ghtlarea installed with fink, and I already had numeric
> > installed with fink, so next I went to the directory
> > called  ../VPython/cvisual
> >
> > and, following what is being done in the install file, I manually
> > issued make:
> >
> > The next problem that arose is this:  (% is my tcsh prompt).
> >
> > % cp Makefile.MacOSX Makefile
> >
> > % make
> > cc -g -I. -I./CXX/Include -I/sw//include/python2.2
> > -I/sw//include/python2.2/Numeric -I/sw/include/gtk-1.2
> > -I/sw/include/glib-1.2 -I/sw/lib/glib/include -D_REENTRANT
> > -I/usr/X11R6/include
> > -I/System/Library/Frameworks/OpenGL.framework/Headers
> > -I/sw//include/glib-1.2 -I/sw//include -w   -c -o arrow.o arrow.cpp
> > In file included from pvector.h:6,
> >                   from cvisual.h:6,
> >                   from display.h:5,
> >                   from prim.h:5,
> >                   from axial.h:5,
> >                   from arrow.cpp:1:
> > CXX/Include/CXX_Objects.h:967: no class template named
> > `random_access_iterator'
> >     in `std'
> > CXX/Include/CXX_Objects.h:1077: no class template named
> > `random_access_iterator
> >     ' in `std'
> > make: *** [arrow.o] Error 1
> > %
> >
> Any ideas as to how to deal with this?

I read this thread, or a similar one, on the Apple website.

Try this:

================================================================
            STANDARD_LIBRARY_HAS_ITERATOR_TRAITS

       has been added to CXX_Config.h that you may need to toggle
       if you get an error on the two lines that mention
       random_access_iterator. The current definition is correct
       for VC6 and EGCS-19990616.
================================================================

On line 5 of CXX_Config.h, switch to 0 vice 1.

Where does your STL come from on Mac?  What compiler is the standard for OS
X.n?  I am considering ways to fix the current method of determining system
dependencies with VPython, and your input will be appreciated.

-Jonathan

Re: [Visualpython-users] Re: Visualpython-users digest, Vol 1 #378 - 5 msgs

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

----- Original Message -----
From: "Jonathan Brandmeyer" <jbr...@ea...>

> Where does your STL come from on Mac?  What compiler is the standard for
OS
> X.n?  I am considering ways to fix the current method of determining
system
> dependencies with VPython, and your input will be appreciated.

The Mac situation recently got a whole lot simpler, because just a few weeks
ago Apple decided to support X11 as part of corporate strategy instead of
merely tolerating it. The practical meaning of this is that as of Mac OSX
10.2 (which I just got and installed in my office this afternoon), what is
now a fantastically complicated installation procedure for VPython on Mac
OSX described on the VPython web site could become vastly simpler for users.
I gather that Apple finally realized that given the small market share,
there weren't many people who could afford to learn to use Objective C to
create Mac-native applications tied to the Mac-specific graphics environment
(the VPython group most definitely is an example).

One can compile using gcc, using essentially the same libraries as are used
for Linux. Steve Spicklemire came up with minor modifications needed to
compile for Mac OSX, and that's what was used to create the VPython
installer.

Bruce Sherwood

Re: [Visualpython-users] Re: Visualpython-users digest, Vol 1 #378 - 5 msgs

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

----- Original Message -----
From: "Jonathan Brandmeyer" <jbr...@ea...>

> Where does your STL come from on Mac?  What compiler is the standard for
OS
> X.n?  I am considering ways to fix the current method of determining
system
> dependencies with VPython, and your input will be appreciated.

The Mac situation recently got a whole lot simpler, because just a few weeks
ago Apple decided to support X11 as part of corporate strategy instead of
merely tolerating it. The practical meaning of this is that as of Mac OSX
10.2 (which I just got and installed in my office this afternoon), what is
now a fantastically complicated installation procedure for VPython on Mac
OSX described on the VPython web site could become vastly simpler for users.
I gather that Apple finally realized that given the small market share,
there weren't many people who could afford to learn to use Objective C to
create Mac-native applications tied to the Mac-specific graphics environment
(the VPython group most definitely is an example).

One can compile using gcc, using essentially the same libraries as are used
for Linux. Steve Spicklemire came up with minor modifications needed to
compile for Mac OSX, and that's what was used to create the VPython
installer.

Bruce Sherwood

[Visualpython-users] Re: Visualpython-users digest, Vol 1 #378 - 5 msgs

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

> Date: Mon, 10 Feb 2003 15:48:57 -0500
> From: Joe Heafner <hea...@vn...>
> To: Vis...@li...
> Subject: [Visualpython-users] compile error under OS 10.2
>
> I'm relaying this from William Scott at UCSC:
>
> Well, I got ghtlarea installed with fink, and I already had numeric
> installed with fink, so next I went to the directory
> called  ../VPython/cvisual
>
> and, following what is being done in the install file, I manually
> issued make:
>
> The next problem that arose is this:  (% is my tcsh prompt).
>
> % cp Makefile.MacOSX Makefile
>
> % make
> cc -g -I. -I./CXX/Include -I/sw//include/python2.2
> -I/sw//include/python2.2/Numeric -I/sw/include/gtk-1.2
> -I/sw/include/glib-1.2 -I/sw/lib/glib/include -D_REENTRANT
> -I/usr/X11R6/include
> -I/System/Library/Frameworks/OpenGL.framework/Headers
> -I/sw//include/glib-1.2 -I/sw//include -w   -c -o arrow.o arrow.cpp
> In file included from pvector.h:6,
>                   from cvisual.h:6,
>                   from display.h:5,
>                   from prim.h:5,
>                   from axial.h:5,
>                   from arrow.cpp:1:
> CXX/Include/CXX_Objects.h:967: no class template named
> `random_access_iterator'
>     in `std'
> CXX/Include/CXX_Objects.h:1077: no class template named
> `random_access_iterator
>     ' in `std'
> make: *** [arrow.o] Error 1
> %
>
> Any ideas as to how to deal with this?

I read this thread, or a similar one, on the Apple website.

Try this:

================================================================

            STANDARD_LIBRARY_HAS_ITERATOR_TRAITS

       has been added to CXX_Config.h that you may need to toggle
       if you get an error on the two lines that mention
       random_access_iterator. The current definition is correct
       for VC6 and EGCS-19990616.
   ================================================================

On line 5, switch to 0 vice 1.

Where does your STL come from on Mac?  What compiler is the standard for OS
X.n?  I am considering ways to fix the current method of determining system
dependencies with VPython, and your input will be appreciated.

Jonathan

[Visualpython-users] Shoot the Monkey

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

John Keck's contribution, "Shoot the Monkey", is now in the user-contributed
section available from the front page of http://vpython.org. Thanks, John!

Bruce Sherwood