visualpython-users

Re: [Visualpython-users] Debian installation: gtkglarea is required on Unix-like systems

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

On Mon, 2003-06-23 at 23:09, Ole...@ga... wrote:

> 
> checking GL... no
> 
> checking GL with threads... no
> 
> checking Mesa... no
> 
> checking Mesa with pthreads... no
> 
> configure: error: gtkglarea is required on Unix-like systems

You can find the detailed version of the error about half-way down
config.log (generated in the directory that you are configuring).  But I
think that I will cover your problem below.

> but I have xlibmesa3=4.2.0=0prev1v3 and gtkglarea5=1.2.3-1 installed.
> Can anyone help me out here?

The one thing that is probably missing is a GL -dev library.  If you are
using nvidia-supplied drivers, you will need to install the
nvidia-glx-dev package that is provided when you built the kernel
drivers (on my system, nvidia-glx-dev_1.0.4349-1_i386.deb).  If you are
using a Mesa-supported graphics card than you will need the
xlibmesa3-dev package from the usual Debian sources.

HTH,
-Jonathan

P.S.  Dr. Sherwood, do you think you could summarize that last paragraph
for the Debian-specific portion of the installation instructions?  This
question seems to come up a lot.

Re: [Visualpython-users] Debian installation: gtkglarea is required on Unix-like systems

[Arnd B. <arn...@we...>]

Hi,

I am not sure if I am the right person to say something here - first I
had basically no problems installing Vpython
on a debian testing box. Let's see -

For dpkg -l | grep gtkgl   I get

ii  gtkglarea5     1.2.3-2        Gimp Toolkit OpenGL area widget shared
libra
ii  gtkglarea5-dev 1.2.3-2        Gimp Toolkit OpenGL area widget include
file

But I would be surprised if the difference in version number is
the origin of the problem.

Hmm, so a closer look at the configure output on my machine, which reads
 checking GTHREAD_LIBS... -lgthread -lpthread -lglib
 checking GL... yes
 checking GtkGLArea... yes
suggests in comparison with your output below, that maybe some GL stuff
is missing...
(For example I have
/usr/lib/libGL.a
/usr/lib/libGLU.a
)

These  are from xlibmesa-dev/xlibmesa-glu-dev and on my machine I have
dpkg -l | grep xlibmesa
ii  xlibmesa-dev   4.2.1-6        XFree86 Mesa development libraries
pseudopac
ii  xlibmesa-gl-de 4.2.1-6        Mesa 3D graphics library development
files [
ii  xlibmesa-glu-d 4.2.1-6        Mesa OpenGL utility library development
file
ii  xlibmesa3      4.2.1-6        XFree86 Mesa libraries pseudopackage
ii  xlibmesa3-gl   4.2.1-6        Mesa 3D graphics library [XFree86]
ii  xlibmesa3-glu  4.2.1-6        Mesa OpenGL utility library [XFree86]

So maybe you have to install xlibmesa-gl-dev
as well  ? ((maybe you don't need the xlibmesa-glu-dev))
(hmm, and what the heck is that xlibmesa*3 stuff good for then ?? ;-)

Good, luck,

Arnd


On Tue, 24 Jun 2003 Ole...@ga... wrote:

> Hi there
>
> I am having problems installing VPython on several debian boxes ('woody'
> as wells as 'testing').
> I have successfully installed:
>
>   gtkglarea5-dev
>   python2.2-numeric
>   python2.2-dev
>   gtk+ 1.2
>   xlibmesa3
>   pkg-config
>
> and their dependencies.
> I even succeeded in installing python-gtkglarea, python-opengl and
> python-gtk so something must be working.
>
> However, when running
>
>   ./configure
>
> from the installation directory I get the following error:
>
> ---------------------------------------------------------
> ... (snip)
> checking for gthread >= 1.0... yes
> checking GTHREAD_CFLAGS... -D_REENTRANT -I/usr/include/glib-1.2
> -I/usr/lib/glib/include
> checking GTHREAD_LIBS... -lgthread -lpthread -lglib
> checking GL... no
> checking GL with threads... no
> checking Mesa... no
> checking Mesa with pthreads... no
> configure: error: gtkglarea is required on Unix-like systems
> --------------------------------------------------------
>
> but I have xlibmesa3=4.2.0=0prev1v3 and gtkglarea5=1.2.3-1 installed.
>
> Can anyone help me out here?
>
> Cheers
> Ole
>
>
> ----------------------------------------------------
> Dr. Ole Nielsen           | Software Engineer
> Urban Risk Research Group | E: Ole...@ga...
> Geoscience Australia      | P: +61 2 6249 9048
> Canberra, Australia       | F: +61 2 6249 9986
> ----------------------------------------------------
>
>

[Visualpython-users] Debian installation: gtkglarea is required on Unix-like systems

[<Ole...@ga...>]

Hi there
=20
I am having problems installing VPython on several debian boxes ('woody'
as wells as 'testing').
I have successfully installed:
=20
  gtkglarea5-dev=20
  python2.2-numeric
  python2.2-dev=20
  gtk+ 1.2
  xlibmesa3 =20
  pkg-config =20
=20
and their dependencies.
I even succeeded in installing python-gtkglarea, python-opengl and
python-gtk so something must be working.
=20
However, when running
=20
  ./configure=20
=20
from the installation directory I get the following error:
=20
---------------------------------------------------------
... (snip)
checking for gthread >=3D 1.0... yes
checking GTHREAD_CFLAGS... -D_REENTRANT -I/usr/include/glib-1.2
-I/usr/lib/glib/include =20
checking GTHREAD_LIBS... -lgthread -lpthread -lglib =20
checking GL... no
checking GL with threads... no
checking Mesa... no
checking Mesa with pthreads... no
configure: error: gtkglarea is required on Unix-like systems
--------------------------------------------------------
=20
but I have xlibmesa3=3D4.2.0=3D0prev1v3 and gtkglarea5=3D1.2.3-1 =
installed.
=20
Can anyone help me out here?
=20
Cheers
Ole
=20
=20
----------------------------------------------------
Dr. Ole Nielsen           | Software Engineer   =20
Urban Risk Research Group | E: Ole...@ga...
Geoscience Australia      | P: +61 2 6249 9048
Canberra, Australia       | F: +61 2 6249 9986=20
----------------------------------------------------
=20

Re: [Visualpython-users] Documentation regarding default values?

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

Good suggestions which are now implemented. Thanks. There was already a 
separate section on defaults, but redundancy is good, so each of the 
relevant objects now lists all its defaults. (And previously there was 
no mention of the defaults for lighting.)

The "length" attribute for sphere was simply a mistake; there is no such 
attribute.

Bruce Sherwood

Mike C. Fletcher wrote:

> The online documentation doesn't cover what the default values for node 
> properties should be.  For instance:
>    http://www.vpython.org/webdoc/visual/cone.html
> Doesn't mention the default values to use for radius, axis, up, or 
> length.  Similarly, the default values to use for scene.lights aren't 
> mentioned.  Is there a single place where this information is kept?  Is 
> it possible to have it added to the docs?
> 
> Also note that:
>    http://www.vpython.org/webdoc/visual/sphere.html
> says that spheres have a "length" attribute, but doesn't say what that 
> attribute does.
> 
> Enjoy all,
> Mike
> 
> _______________________________________
>  Mike C. Fletcher
>  Designer, VR Plumber, Coder
>  http://members.rogers.com/mcfletch/
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

[Visualpython-users] Documentation regarding default values?

[Mike C. F. <mcf...@ro...>]

The online documentation doesn't cover what the default values for node 
properties should be.  For instance:
    http://www.vpython.org/webdoc/visual/cone.html
Doesn't mention the default values to use for radius, axis, up, or 
length.  Similarly, the default values to use for scene.lights aren't 
mentioned.  Is there a single place where this information is kept?  Is 
it possible to have it added to the docs?

Also note that:
    http://www.vpython.org/webdoc/visual/sphere.html
says that spheres have a "length" attribute, but doesn't say what that 
attribute does.

Enjoy all,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

[Visualpython-users] Visual Python in an Immersive 3D Environment

[Shaun P. <sha...@an...>]

The slides from my project seminar on Visual Python in an Immersive 3D
Environment are available at
http://www.syseng.anu.edu.au/~shaun/vpython/projectseminar

Shaun Press

[Visualpython-users] New for Windows

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

New VPython for Windows at http://vpython.org; Linux/Unix/Mac OSX coming 
soon.

Thanks to Hugh Fisher of Australia for submitting a patch to permit setting

	scene.fullscreen = 1

in which case the graphics window fills the entire screen. Because there 
is no close box in this case (at least on Windows), making it difficult 
to get out of the program, I added code so that pressing ESCAPE closes 
the window. It might be better if this were conditioned on fullscreen 
mode, but I didn't immediately see how to arrange this.

Fisher also provided a patch to fix up keyboard key names on Linux/Unix 
to be like those on Windows.

This is an important milestone in the development of VPython, as 
Fisher's submission of patch files represents the first addition to 
Visual by someone not at Carnegie Mellon or North Carolina State University.

Small bonus by popular request: color.orange is now available, 
equivalent to (1, 0.5, 0).

Documentation also updated.

Bruce Sherwood

Re: [Visualpython-users] new installer glitches

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

On Wed, 2003-06-11 at 05:59, Arnd Baecker wrote:
> 1.) As I used
>   export PHOME=/home/baecker/morepub/PYTHON/
> instead of
>   export PHOME=/home/baecker/morepub/PYTHON
> (notice the missing back-slash at the end of the previous line!)
> I got the following error message

> The "//" prevents configure to see that it is in the  python module search
> path.
> (Surely, mea culpa, but hard to spot ;-)

If we were preforming a genuine directory search to verify this, the
trailing slash wouldn't matter.  However, we are actually using string
comparison within python, comparing the computed destination for the
visual module against the python variable sys.path (a python list).

If you want to improve this, you can check the file acinclude.m4,
shortly below the line AC_DEFUN([VISUAL_CHECK_PYTHON_SYS_PATH], you
should see a python script, bounded by _ACEOF.

> Also the reference to Python 2.3 might be misleading, in the sense
> that someone could think that Python 2.3 is necessary for the installation
> of Visual.

It isn't required.  This manual section is MUCH better than the
equivalant documentation in the 2.2.x manuals, and equally applicable to
both; that is why we point there.  The 2.2.x manuals are almost useless
in this particular regard.

> 2.) The second glitch occurs for "make install":
> 
> /usr/bin/install -c -m 755 vpython /bin/vpython
> /usr/bin/install: cannot create regular file `/bin/vpython': Permission
> denied
> make[1]: *** [install] Error 1
> make[1]: Leaving directory
> `/home/scratch/baecker/INSTALL_SOFT/PythonNeu/visual-2.0.3/cvisual'
> make: *** [install-recursive] Error 1
> 
> As a hack I changed the Makefile in the "cvisual" subdirectory,
> (Namely bindir = ${exec_prefix}/bin to bindir = ${prefix}/bin
> but I don't know configure at all to provide the correct fix here ...)

The value of 'bindir' as a variable in the makefile is set automatically
by configure.  You can manually set $(bindir) with --bindir=/foo/bar at
configure time to install wherever you like.  I don't think that this
particular file sets exec_prefix, which is a problem for me to fix. 
Otherwise, it would have worked for you as-is.

You can run configure --help to get a list of most of the options and
environment variables that are supported.

Thanks for your feedback,
-Jonathan

[Visualpython-users] new installer glitches

[Arnd B. <arn...@we...>]

Hi,

I just tried out the new installer - excellent - many thanks for this
big improvement!

I encountered two glitches when doing the following:

tar xzf Sources/visual-2.0.3-2003-06-07.tar.gz
cd visual-2.0.3
export PHOME=/home/baecker/morepub/PYTHON/
./configure --prefix=${PHOME}
make
make install

1.) As I used
  export PHOME=/home/baecker/morepub/PYTHON/
instead of
  export PHOME=/home/baecker/morepub/PYTHON
(notice the missing back-slash at the end of the previous line!)
I got the following error message

####################
checking the python module search path ... ['',
'/home/scratch/baecker/INSTALL_SOFT/PythonNeu/visual-2.0.3',
'/home/baecker/morepub/PYTHON/lib/python2.2',
'/home/baecker/morepub/PYTHON/lib/python2.2/plat-linux2',
'/home/baecker/morepub/PYTHON/lib/python2.2/lib-tk',
'/home/baecker/morepub/PYTHON/lib/python2.2/lib-dynload',
'/home/baecker/morepub/PYTHON/lib/python2.2/site-packages',
'/home/baecker/morepub/PYTHON/lib/python2.2/site-packages/Numeric']
configure: error:
"/home/baecker/morepub/PYTHON//lib/python2.2/site-packages is
not in the python module search path.
 See the Python 2.3  Installing Python Modules manual, section 4.1 for
details"
#####################

The "//" prevents configure to see that it is in the  python module search
path.
(Surely, mea culpa, but hard to spot ;-)
Also the reference to Python 2.3 might be misleading, in the sense
that someone could think that Python 2.3 is necessary for the installation
of Visual.


2.) The second glitch occurs for "make install":

/usr/bin/install -c -m 755 vpython /bin/vpython
/usr/bin/install: cannot create regular file `/bin/vpython': Permission
denied
make[1]: *** [install] Error 1
make[1]: Leaving directory
`/home/scratch/baecker/INSTALL_SOFT/PythonNeu/visual-2.0.3/cvisual'
make: *** [install-recursive] Error 1

As a hack I changed the Makefile in the "cvisual" subdirectory,
(Namely bindir = ${exec_prefix}/bin to bindir = ${prefix}/bin
but I don't know configure at all to provide the correct fix here ...)

Best,

Arnd

[Visualpython-users] re: OFSET/ Freeduc - distribution of VPython?

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

Jonathan Brandmeyer wrote:

 > What was his address?  I trust that you will forward this to Mr.
 > Khaznadar, but it would be easier if all parties could e-mail each other
 > directly.


The converstaion is occurring on the the ofset-freduc mailing list

archives at

https://sourceforge.net/mailarchive/forum.php?forum_id=2414

though I notice that most of the discussion has not made it to the 
archives - for whatever reason.

George's address is:

gek...@ne...

The conversation remains a little frustrating as I keep trying to 
emphasize that I am not a VPython developer or decsionmaker, and he 
keeps addressing me as if I were, or were claiming to be.  Assuming its 
a language issue.

Passing your response along will hopefully clarify things a bit.  If you 
have any interest in what they are up to, there is the alternative of 
you joining the list.

But based on Bruce's response to the IDLE fork issue, I would like to 
edit out your concerns on that score, as it will probably confuse 
further an already a somewhat confused conversation.

Art

Re: [Visualpython-users] OFSET/ Freeduc - distribution of VPython?

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

Good news on the idlefork front: The latest release of idlefork is in 
very good shape. Kurt Kaiser managed to fix the serious bugs. He has 
also fixed in CVS some minor problems that showed up in the beta 
release. I've used the new idlefork extensively, and I encourage people 
to try it by downloading the installer available at

	http://sourceforge.net/projects/idlefork

I think it is very likely that this WILL replace the old IDLE in the 
final release of Python 2.3, especially because Guido has been keeping a 
close watch on it and even contributed a recent patch himself. If it 
does become the standard distributed IDLE, starting with Python 2.3 we 
will retire Idle_VPython, and it will no longer be a part of the VPython 
package.

The new idlefork has all of the features and capabilities of 
Idle_VPython plus many excellent new features. The most obvious 
difference you'll see is that there is only one output window, no matter 
how many program files you have open, and this output window is actually 
the Python shell, so you can investigate the present values of variables 
in your program, etc. There is an excellent facility for configuring the 
editor (change font size etc.), and changes take effect immediately. You 
can specify Windows keyboard shortcuts on a Linux or Mac machine (or 
Linux shortcuts on Windows or Mac, etc.). This is a great convenience if 
you do most of your work on one platform but occasionally run on a 
different platform.

The default behavior in some respects is not the same as Idle_VPython. 
If you want the same behavior as Idle_VPython, you need to go to 
Configure IDLE on the Options menu, choose the General tab, and set At 
Startup to "Open Edit Window" (default is to open a Python shell), and 
set At Start of Run (F5) to "No Prompt" (the default is to ask you 
whether to save each time you run, unless you remember to save before 
running).

Bruce Sherwood

Jonathan Brandmeyer wrote:

> Other notes:
> You mentioned that the idle/idlefork issue will be moot since the "main"
> fork of idle should be merged into Python 2.3.  Don't count your
> chickens until they hatch.  That is the plan, but there remain some
> severe bugs to work out first.  Taking the worst case (idlefork doesn't
> make it), make sure that Idle for VPython doesn't conflict with the main
> Idle.  We prevent this by keeping idle_VPython under the site-packages
> directory, and installing a shell script named "vpython" in the PATH
> that runs our version of idle.
> 
> Of course, I would love to see the new idlefork make it.  That last bit
> was "just in case".

Re: [Visualpython-users] OFSET/ Freeduc - distribution of VPython?

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

On Sun, 2003-06-08 at 15:29, Arthur wrote:
> For those who have the patience, I enclose below a rather lengthy 
> exchange with George Khaznadar, one of the key folks at OFSET
> 
> Organization for Free Software in Education and Teaching
> 
> http://www.ofset.org

> Response by Georges Khaznadar, of OFSET

What was his address?  I trust that you will forward this to Mr.
Khaznadar, but it would be easier if all parties could e-mail each other
directly.

>  > Please can you author a short manpage for visual ? the sections may be
>  > NAME, SYNOPSIS, DESCRIPTION, AUTHOR, INTERNET RESOURCES, LICENSING
>  > and each of them can be very short or pasted from your existing
>  > documentation. Don't worry with the groff syntax, just release it like
>  > plain text, I'll put it straight. Of course you can refer to your
>  > already written html documentation.

A man page for a library?  Perhaps for idle_VPython, but not for the
core visual module.  Ever run "man gtk+"?  I think that placing the
documentation under /usr/share/doc/python-visual, with the appropriate
pointers for dhelp would be best for the library docs.  Best in the
sence that it fits in with the Debian Policy.

However, if you do this, make sure that idle's help menu is updated to
point to the right place such that when a user presses F1 or selects the
menu item that the system webbrowser is pointed in the right place.

>  > I would be obliged if you could give me some hints about the
>  > building dependencies of your package. It seems to depend from at least
>  > gtkglarea5-dev, python2.2-dev. Have you noticed other dependances at
>  > build-time ?

Simply having gtkglarea5-dev isn't always enough.  Some form of OpenGL
support under gtkglarea is required.  gtkglarea5 depends on some OpenGL
back-end, but at least one person has complained before to us that their
GL support was busted in spite of this dependancy.

>  > As to dependencies, the only additional dependency not on your list is
>  > Numerical Python

Quite right.  In fact, if its not found, configure will bomb out with a
(hopefully useful) error message.  VPython Depends on python-numeric.

>  >Would you agree for renaming the debian package to python-visual ? It
>  >makes it more visible when browsing python resources available in a
>  >machine.

And follows Debian's standards for python package names.

That would be fine for a downstream distribution package name.  We don't
really plan to change the name here, and the debian documentation should
be more than adequate to point users in the right direction to complain
about/give thanks for this software.

Other notes:
You mentioned that the idle/idlefork issue will be moot since the "main"
fork of idle should be merged into Python 2.3.  Don't count your
chickens until they hatch.  That is the plan, but there remain some
severe bugs to work out first.  Taking the worst case (idlefork doesn't
make it), make sure that Idle for VPython doesn't conflict with the main
Idle.  We prevent this by keeping idle_VPython under the site-packages
directory, and installing a shell script named "vpython" in the PATH
that runs our version of idle.

Of course, I would love to see the new idlefork make it.  That last bit
was "just in case".

HTH,
-Jonathan

[Visualpython-users] OFSET/ Freeduc - distribution of VPython?

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

For those who have the patience, I enclose below a rather lengthy 
exchange with George Khaznadar, one of the key folks at OFSET

Organization for Free Software in Education and Teaching

http://www.ofset.org

Among other things, they distribute Freduc - what I think is an 
outstanding "run from CD" Debian based Linux distro chock full of 
educational related software.  The focus is K-12, I would say.

The main point of all this is the last question from George. He is 
asking about whether VPython/visual might be named python-visual for the 
purposes of Debian based distros, presumedly so that it identifies 
itself as a python related project, in comformity with what he seems to 
perceive as accepted naming conventions for this kind of project.  He 
seems to me  quite knowledgeable about these kinds of issues, so I am 
assuming his perception has a good basis. But of course I have no way to 
respond to him.

Bruce?

Anyone?

Also wouldn't mind some direction on the man pages issue he requested. 
Again, I tried to make it clear I was a user and a fan, not a 
decisionmaker, with respect to VPython, but it doesn't seem to have 
registered.  Will there be something in the way of official manpages to 
send along?

Bruce?

Anyone?

I do think it quite worthwhile to try to cooperate with helping them 
feel fully comfortable and "in compliance" in distributing Python/visual 
as part of Freeduc.

Art


 > Now having become as excited as I have about the Freeduc distro, I will
 > begin my lobbying campaign for inclusion on some of my favorite apps,
 > starting with VPython:
 >
 > www.vpython.org
 > VPython
 > 3D Programming for Ordinary Mortals
 >
 > It is being actively used in physics education at the University level,
 > which I understand is not the Freeduc target audience.  But I am
 > convinced it could also serve as an enticing and satsifying and fun
 > education tool at the K-12 level.
 >
 > I feel particularly free to promote it in that I have nothing to do with
 > its development.  But would be willing to write some demos, and a
 > tutorial more appropriate to the Freeduc audience were it to be
 > considered for inclusion in the distribution.
 >
 > How are these decisions made, and what should one do beyond babbling on
 > this list if one feels strongly about the inclusion of a particular
 > resource.
 >
 > Art


Response by Georges Khaznadar, of OFSET

 > Very interesting indeed.
 > It yelds a debian package with no problem (based on a debian sarge
 > distribution). Package size : 588738 bytes, installed size : 2253 kbytes.
 >
 > There has been a e-mail thread about an ITP (intent to package), later
 > requalified as an RTP (request to package) inside the debian bug
 > tracking system :
 > http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=112118
 >
 > So it appears that your software has not yet been packaged for a debian
 > system.
 >
 > Please can you author a short manpage for visual ? the sections may be
 > NAME, SYNOPSIS, DESCRIPTION, AUTHOR, INTERNET RESOURCES, LICENSING
 > and each of them can be very short or pasted from your existing
 > documentation. Don't worry with the groff syntax, just release it like
 > plain text, I'll put it straight. Of course you can refer to your
 > already written html documentation.
 >
 > I would be obliged if you could give me some hints about the
 > building dependencies of your package. It seems to depend from at least
 > gtkglarea5-dev, python2.2-dev. Have you noticed other dependances at
 > build-time ?
 >
 > The licensing has already been estimated as DFSG-compliant, which means
 > that your software can be part of the debian projets (i.e. a debian/free
 > package).
 >
 > Best regards,			Georges.
 >

My (edited) response

 > As to dependencies, the only additional dependency not on your list is
 > Numerical Python
 >
 > http://pfdubois.com/numpy/
 >
 > """Numerical Python adds a fast, compact, multidimensional array
 > language facility to Python."""
 >
 > Numerical Python was developed as Lawrence Livermore National Laboratory.
 >
 > It is quite mature as an open source project, well documented, nice
 > tutorial.  Much of what I now understand about matrix algebra was
 > learned "playing" with Numerica Python.
 >
 > IMO, a nice addition to Freeduc, in and of itself.
 >
 > It is going to be superceded at some point by an "improved" but largely
 > compatible library being called NumArray.
 >
 > A further note on dependencies is the fact the it appears that gtkglarea
 > is no longer being supported and is being superceded by a new library.
 >  There are plans and committed resources to adapt VPython to NumArray
 > and to the newer gl context for gtk, as the libraries phase-in as the
 > standards.
 >
 > There has also been a close association between the development of
 > VPython and that of IDLE.
 >
 > IDLE is the simple IDE for Python which has been a pet project of Guido
 > Von Rossum, the creator of Python.
 >
 > Python itself  - for those who do not know the history - grew out of the
 > ABC language, which was originally developed with young learning
 > programmers in mind.  Guido has a keen interest in the use of Python for
 > educational purposes, and IDLE was developed in large part out of that
 > interest.
 >
 > The story gets a little complicated from there, as there have been 2
 > versions of IDLE, the stable and the experimental fork. VPython was
 > dependent, for technical reasons, on the experimtental fork version. As
 > of Python2.3, just released, the two versions are integrated back as one
 > "official" version, so that potential additional complication is now 
gone.
 >
 >

At which point George asks,

 >Would you agree for renaming the debian package to python-visual ? It
 >makes it more visible when browsing python resources available in a
 >machine.

Perhaps a bit of a language barrier because I had made it clear that 
VPython/visual was not my project. And that the fact that I was not 
*the* or even *a* developer was one of the reasons I was comfortable 
promoting it so baldly.

On the other hand I have been upfront about my own agenda - that I would 
also like to see PyGeo in the distribution, when it is ready, which it 
isn't quite, in any case.


Art

Re: [Visualpython-users] Success on OSX

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

Now available at http://vpython.org, for Linux/Unix as well as for Mac 
OSX. Please report problems with either the instructions or the installer.

MANY THANKS, Jonathan!

What Jonathan has done is very important. He has created an installer 
that can compile and install VPython on a wide range of platforms.

Bruce Sherwood

Jonathan Brandmeyer wrote:
> I am pleased to announce that VPython will build cleanly on OS X out of
> the box.  The 2.0.3 release should be appearing on our download page
> soon, which implements the required features.
> 
> You should use the latest patch release of OSX due to conflics with
> OpenGL in some earlier versions.  We used 10.2.6 on our test machine.
> Use the December 2002 developers tools to build visual.
> Use the fink-suppled Python 2.2.x  We have not tested visual with a
> framework based python installation, as found in MacPython.  Some clever
> manipulation of environment variables might make this possible in the
> current state, but we haven't tried yet.
> Use the latest X11 environment from Apple, *and* the X11 SDK.
> 
> ./configure --prefix=/sw
> make
> make install
> 
> should be all you need to do to build and install VPython on OSX.  Make
> sure that python is started from within X11.  If you get an error like,
> "cannot open display", followed by a crash, than you started the
> interpreter from outside the X11 environment.
> 
> The installation script also produces a shell script that automatically
> starts Idle for VPython using the interpreter that visual was configured
> and installed under.  The script is installed into $(prefix)/bin.  Fine
> control may be achieved with --bindir=/foo/bar.  Simply run "vpython"
> and everything should "just work".  All platforms recieve this feature.
> 
> The source package also builds on Windows with the MinGW port of GCC. 
> This is mainly to help test on Windows with a Free compiler.  The
> Windows binary distribution that we provide will continue to be built
> with MSVC 6.
> 
> As a final enhancement, many superfluous warnings have been silenced,
> making for a much quiter build.
> 
> Enjoy,
> Jonathan Brandmeyer
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Success on OSX

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

Jonathon,

As a recent convert to the Mac, I just wanted to say a big THANK YOU! 
I've been using the version of visual using Steve Spicklemire's 
original build, but I'm still thrilled to hear of your recent success.

AT


On Friday, June 6, 2003, at 10:32 PM, Jonathan Brandmeyer wrote:

> I am pleased to announce that VPython will build cleanly on OS X out of
> the box.  The 2.0.3 release should be appearing on our download page
> soon, which implements the required features.
>
> You should use the latest patch release of OSX due to conflics with
> OpenGL in some earlier versions.  We used 10.2.6 on our test machine.
> Use the December 2002 developers tools to build visual.
> Use the fink-suppled Python 2.2.x  We have not tested visual with a
> framework based python installation, as found in MacPython.  Some 
> clever
> manipulation of environment variables might make this possible in the
> current state, but we haven't tried yet.
> Use the latest X11 environment from Apple, *and* the X11 SDK.
>
> ./configure --prefix=/sw
> make
> make install
>
> should be all you need to do to build and install VPython on OSX.  Make
> sure that python is started from within X11.  If you get an error like,
> "cannot open display", followed by a crash, than you started the
> interpreter from outside the X11 environment.
>
> The installation script also produces a shell script that automatically
> starts Idle for VPython using the interpreter that visual was 
> configured
> and installed under.  The script is installed into $(prefix)/bin.  Fine
> control may be achieved with --bindir=/foo/bar.  Simply run "vpython"
> and everything should "just work".  All platforms recieve this feature.
>
> The source package also builds on Windows with the MinGW port of GCC.
> This is mainly to help test on Windows with a Free compiler.  The
> Windows binary distribution that we provide will continue to be built
> with MSVC 6.
>
> As a final enhancement, many superfluous warnings have been silenced,
> making for a much quiter build.
>
> Enjoy,
> Jonathan Brandmeyer
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The 
> best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

[Visualpython-users] Success on OSX

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

I am pleased to announce that VPython will build cleanly on OS X out of
the box.  The 2.0.3 release should be appearing on our download page
soon, which implements the required features.

You should use the latest patch release of OSX due to conflics with
OpenGL in some earlier versions.  We used 10.2.6 on our test machine.
Use the December 2002 developers tools to build visual.
Use the fink-suppled Python 2.2.x  We have not tested visual with a
framework based python installation, as found in MacPython.  Some clever
manipulation of environment variables might make this possible in the
current state, but we haven't tried yet.
Use the latest X11 environment from Apple, *and* the X11 SDK.

./configure --prefix=/sw
make
make install

should be all you need to do to build and install VPython on OSX.  Make
sure that python is started from within X11.  If you get an error like,
"cannot open display", followed by a crash, than you started the
interpreter from outside the X11 environment.

The installation script also produces a shell script that automatically
starts Idle for VPython using the interpreter that visual was configured
and installed under.  The script is installed into $(prefix)/bin.  Fine
control may be achieved with --bindir=/foo/bar.  Simply run "vpython"
and everything should "just work".  All platforms recieve this feature.

The source package also builds on Windows with the MinGW port of GCC. 
This is mainly to help test on Windows with a Free compiler.  The
Windows binary distribution that we provide will continue to be built
with MSVC 6.

As a final enhancement, many superfluous warnings have been silenced,
making for a much quiter build.

Enjoy,
Jonathan Brandmeyer

Re: [Visualpython-users] Visual Python in a 3D Immersive Environment

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

On Wed, 2003-06-04 at 19:12, Shaun Press wrote:
> I have modified Visual Python to run on The Wedge system at the
> Department of Computer Science, Australian National University. The
> Wedge is a 3D Immersive Environment, which presents scenes in real 3D.
> The details about The Wedge can be found at http://escience.anu.edu.au
> (usage information) and http://ephebe.anu.edu.au/wedge/index.html
> (technical and hardware information).
> Credit must also go to Hugh Fisher (author of the Stereo Visual Python
> Program) for assisting with the 3D transformation calculations. 
> 
> I have also added a couple of extras to Visual Python
> New shapes: Pyramid and Frustum
> New shape set: Points (which are a set of single points on the screen)
> New shape attribute: Wire (when true the shape is drawn as a wire frame)

Great stuff!  Please send a diff against CVS HEAD, that will be the
easiest format for us to use.  

Right now, everything under "examples" represents our test suite for the
upcoming archetectural changes, for regression purposes.  So, please
also send some kind of documented test suite so that we can verify that
the new features' behavior doesn't get broken as things progress.

> I am giving a seminar next week on the project and I hope to have
> slides/screenshots/source available after that.
> 
> Now, a number of questions ....
> 
> Did anyone have problems building Visual Python under Windows from
> source? (either using the Visual C++ workspace file that came supplied,
> or linking the vector library)

No problems.  We are using a MSVC build environment and a MinGW build
environment for all of our testing on Windows.  An OSX box has just been
added to the fray (yesterday), as well as a pair of Linux machines:
RedHat and Debian.

> Did anyone have any problems running any demo's under the windows build
> that use vectors eg stars.py?

No problems here, that works identically for us on all platforms.

> Can anyone confirm that the algorithms used to generate the shapes do
> not follow the "winding" rules for front-facing or back-facing surfaces?

Sorry, I can't confirm or refute that.  I'm mostly focusing on the
python <-> C++ interface area.

-Jonathan Brandmeyer

Re: [Visualpython-users] Visual Python in a 3D Immersive Environment

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

I see now that I hadn't paid attention to Hugh Fisher's announcement in 
March. Thanks for the pointer. I'm unclear as to what I've got when I 
pick up Fisher's zip file. That doesn't include your work, does it, Shaun?

I'm puzzled by what you say about the winding issue. Can you post a 
short test routine that shows a blotchy appearance? I've never seen this 
effect.

Bruce Sherwood

Shaun Press wrote:

> On Thu, 2003-06-05 at 11:05, Bruce Sherwood wrote:
> 
>>I would be interested in adding your enhancements to Visual, if you are 
>>willing. I haven't heard previously of the problems you report. As to 
>>the winding rules, where does this come up, other than in the faces 
>>primitive? What is the "Stereo Visual Python Program"?
>>
> 
> As some of the enhancements are intended to extend the use of Visual
> Python in the teaching/modelling environment adding them to the next
> release is what I had in mind. It saves the ANU from having a "local"
> version instead of a standard version.
> 
> On the topic of winding. One of the enhancements I attempted was to
> replace the software lighting model with the OpenGL lighting model. The
> existing model just uses white light and simulates lighting by
> brightening (or dimming) the colour values for each face. Replacing it
> with the OpenGL lighting system, while more complex, would allow the
> addition of different coloured lights as well as adding different type
> of lights (spotlights etc). 
> To do this, each shape needs to have associated normals for each
> surface. The clasical way to calculate this is to take 3 points on the
> surface (usally the vertex points) and use the formula (v1-v2) x (v2-v3)
> where <x> is the cross product operator. However the direction of the
> normal depends upon whether the points are in clockwise or
> anti-clockwise order. Surfaces "face" the viewer in an anti-clockwise
> direction (IIRC). It appears with some of the shapes the order is a
> mixture of clockwise and anti-clockwise, so some normals face the viewer
> and some face away. This results in a blotchy effect on the shapes
> surface. While it gives a surreal effect for the viewer, it doesn't
> improve the modelling in any way.
> This also has consequences for other extensions such as add textures to
> shapes and making shapes transparent. 
> 
> The Stereo Visual Python program was written by Hugh Fisher to provide
> fullscreen and/or quad-buffered stereo displays. He posted the details
> on this list in early march. The source is at
> http://cs.anu.edu.au/~hugh.fisher/3dstuff/cvisual.zip
> 
> 
> 
> 
>>Just yesterday I had an email exchange with people involved with the 
>>Geowall consortium (http://www.geowall.org) who use stereo projection in 
>>the service of geographic visualization. Their hardware configuration is 
>>two projectors with polarizers mounted very close together, projecting 
>>onto a screen that preserves polarization. They use passive polarizing 
>>glasses. They may try out VPython in their context.
> 
> 
> It sound similar to the Wedge except that they have a single screen
> rather than the two we use. They may be able to use Hugh's program
> without much modification at all.
> 
> 

Re: [Visualpython-users] Visual Python in a 3D Immersive Environment

[Shaun P. <sha...@an...>]

On Thu, 2003-06-05 at 11:05, Bruce Sherwood wrote:
> I would be interested in adding your enhancements to Visual, if you are 
> willing. I haven't heard previously of the problems you report. As to 
> the winding rules, where does this come up, other than in the faces 
> primitive? What is the "Stereo Visual Python Program"?
> 
As some of the enhancements are intended to extend the use of Visual
Python in the teaching/modelling environment adding them to the next
release is what I had in mind. It saves the ANU from having a "local"
version instead of a standard version.

On the topic of winding. One of the enhancements I attempted was to
replace the software lighting model with the OpenGL lighting model. The
existing model just uses white light and simulates lighting by
brightening (or dimming) the colour values for each face. Replacing it
with the OpenGL lighting system, while more complex, would allow the
addition of different coloured lights as well as adding different type
of lights (spotlights etc). 
To do this, each shape needs to have associated normals for each
surface. The clasical way to calculate this is to take 3 points on the
surface (usally the vertex points) and use the formula (v1-v2) x (v2-v3)
where <x> is the cross product operator. However the direction of the
normal depends upon whether the points are in clockwise or
anti-clockwise order. Surfaces "face" the viewer in an anti-clockwise
direction (IIRC). It appears with some of the shapes the order is a
mixture of clockwise and anti-clockwise, so some normals face the viewer
and some face away. This results in a blotchy effect on the shapes
surface. While it gives a surreal effect for the viewer, it doesn't
improve the modelling in any way.
This also has consequences for other extensions such as add textures to
shapes and making shapes transparent. 

The Stereo Visual Python program was written by Hugh Fisher to provide
fullscreen and/or quad-buffered stereo displays. He posted the details
on this list in early march. The source is at
http://cs.anu.edu.au/~hugh.fisher/3dstuff/cvisual.zip



> Just yesterday I had an email exchange with people involved with the 
> Geowall consortium (http://www.geowall.org) who use stereo projection in 
> the service of geographic visualization. Their hardware configuration is 
> two projectors with polarizers mounted very close together, projecting 
> onto a screen that preserves polarization. They use passive polarizing 
> glasses. They may try out VPython in their context.

It sound similar to the Wedge except that they have a single screen
rather than the two we use. They may be able to use Hugh's program
without much modification at all.

Re: [Visualpython-users] Visual Python in a 3D Immersive Environment

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

I would be interested in adding your enhancements to Visual, if you are 
willing. I haven't heard previously of the problems you report. As to 
the winding rules, where does this come up, other than in the faces 
primitive? What is the "Stereo Visual Python Program"?

Just yesterday I had an email exchange with people involved with the 
Geowall consortium (http://www.geowall.org) who use stereo projection in 
the service of geographic visualization. Their hardware configuration is 
two projectors with polarizers mounted very close together, projecting 
onto a screen that preserves polarization. They use passive polarizing 
glasses. They may try out VPython in their context.

Bruce Sherwood

Shaun Press wrote:
> I have modified Visual Python to run on The Wedge system at the
> Department of Computer Science, Australian National University. The
> Wedge is a 3D Immersive Environment, which presents scenes in real 3D.
> The details about The Wedge can be found at http://escience.anu.edu.au
> (usage information) and http://ephebe.anu.edu.au/wedge/index.html
> (technical and hardware information).
> Credit must also go to Hugh Fisher (author of the Stereo Visual Python
> Program) for assisting with the 3D transformation calculations. 
> 
> I have also added a couple of extras to Visual Python
> New shapes: Pyramid and Frustum
> New shape set: Points (which are a set of single points on the screen)
> New shape attribute: Wire (when true the shape is drawn as a wire frame)
> 
> I am giving a seminar next week on the project and I hope to have
> slides/screenshots/source available after that.
> 
> Now, a number of questions ....
> 
> Did anyone have problems building Visual Python under Windows from
> source? (either using the Visual C++ workspace file that came supplied,
> or linking the vector library)
> Did anyone have any problems running any demo's under the windows build
> that use vectors eg stars.py?
> Can anyone confirm that the algorithms used to generate the shapes do
> not follow the "winding" rules for front-facing or back-facing surfaces?
> 
> Shaun Press
> Department of Systems Engineering
> Research School of Information Sciences and Engineering
> Australian National University
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

[Visualpython-users] Visual Python in a 3D Immersive Environment

[Shaun P. <sha...@an...>]

I have modified Visual Python to run on The Wedge system at the
Department of Computer Science, Australian National University. The
Wedge is a 3D Immersive Environment, which presents scenes in real 3D.
The details about The Wedge can be found at http://escience.anu.edu.au
(usage information) and http://ephebe.anu.edu.au/wedge/index.html
(technical and hardware information).
Credit must also go to Hugh Fisher (author of the Stereo Visual Python
Program) for assisting with the 3D transformation calculations. 

I have also added a couple of extras to Visual Python
New shapes: Pyramid and Frustum
New shape set: Points (which are a set of single points on the screen)
New shape attribute: Wire (when true the shape is drawn as a wire frame)

I am giving a seminar next week on the project and I hope to have
slides/screenshots/source available after that.

Now, a number of questions ....

Did anyone have problems building Visual Python under Windows from
source? (either using the Visual C++ workspace file that came supplied,
or linking the vector library)
Did anyone have any problems running any demo's under the windows build
that use vectors eg stars.py?
Can anyone confirm that the algorithms used to generate the shapes do
not follow the "winding" rules for front-facing or back-facing surfaces?

Shaun Press
Department of Systems Engineering
Research School of Information Sciences and Engineering
Australian National University

Re: [Visualpython-users] more on idlefork problems

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

> I have news to report re: my problems with idlefork.

I just noticed that a new version of idlefork is available.  I haven't tried
that new one yet.

[Visualpython-users] more on idlefork problems

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

I have news to report re: my problems with idlefork.

Again, I know that I seem to be the only one having problems, but maybe
someday someone else will ...

Recall that under Win98 idlefork froze my system requiring reboot.

I've upgraded to XP.   Now idlefork will run and everything seems fine, but
when I close idlefork an error is generated ... can't read locatation
0x000000028 or something.

if I start idlefork from the command line (python idle.py) it starts
normally.
if I start it using python -v idle.py it spews an enormous number of
messages, most of which go by too fast to read. THere is one that I can
sort-of read because it is repeated about 50 times.  It contains the
filename "CallTips.py", but that's about all I can grab.  Then it seems to
go into shut-down mode.  The final messages are

----------------------------------
[...]
# cleanup sys
# cleanup __builtin__
PyThreadState_Clear:  warning: thread still has a frame
# cleanup ints:  14 unfreed ints in 3 out of 6 blocks
# cleanup floats:  4 unfreed floats in 1 out of 1 block

[here there is a looooonng pause during which the cpu roars along at 100%]

Font Tahoma 8 still in cache.
TkFontPkgFree:  all fonts should have been freed already

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information
--------------------------------------

What's the DOS way of redirecting all that output into a file?
If I start regular idle using "python -v idle.py"  it starts just fine
(spewing many fewers messages than idlefork), and quits just fine.
Ringing any bells?

-Gary

Re: [Visualpython-users] debs of VPython

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

On Fri, 2003-05-30 at 02:18, Nils Wagner wrote:
> Hi all,
> 
> I wonder, if someone has built a debian package from a recent CVS of
> vpython.

Not that I know of.  Someone contributed the metadata needed to do so a
while ago, but it is somewhat stale right now.

The current source package IS the CVS version right now (on the
visual_2_0 branch), so you are getting the latest and greatest.

-Jonathan

[Visualpython-users] debs of VPython

[Nils W. <nw...@me...>]

Hi all,

I wonder, if someone has built a debian package from a recent CVS of
vpython.

Nils