visualpython-users

Re: [Visualpython-users] synchronization of visualization thread

[Bruce S. <ba...@an...>]

I've added this feature request to the "bug" list on sourceforge.net. I too 
have sometimes felt the need of something like this.

Bruce Sherwood

--On Friday, December 15, 2000 4:22 PM +0100 Markus Gritsch 
<gr...@iu...> wrote:

> It would be nice if the visualization thread could be somehow
> synchronized with the thread running the Python script.  The problem
> without synchronization is that the visualization of a scene with much
> animation in it is "distorted", because during a visualization cycle
> some objects have their old position and some others already appear on
> their new location.  For example I have a scene with some springs in
> it, each represented by a helix (curve).  Because the whole spring is
> moveing around quite fast, part of it has the old coordinates and the
> other part already appears at the new calculated ones.
>
> Would it be possible to hav a function similar to visual.rate() which
> suspends the visualization thread and another to reactivate it?  In
> this way it would be possible in the while loop to suspend it, do the
> calculations, activate it and suspend it again before doing the next
> cycle.
>
> while 1:
>     visual.stop() # suspend the visualization thread
>     doMyCalculations()
>     visual.start() # resume the visualization thread
>     visual.rate(30)
>
> Would this be possible with the current VPython design?

Re: [Visualpython-users] Documenting delete

[Ari H. <ahe...@an...>]

On Wed, 27 Dec 2000, Bruce Sherwood wrote:

> --On Wednesday, December 27, 2000 1:37 PM -0500 Ari Heitner 
> <ahe...@an...> wrote:
> > why not include a little "delete" function that takes the name, and does
> > this for you?
> 
> Should this be part of Visual, or just an example in the documentation?
> 
> (It is my understanding from previous conversations that there may be a 
> problem with performing the delete inside Visual, due to thread 
> synchronization, or something....?)

um, defined in visual. only used from the user-thread side if that's what's
needed for safety.

needs to do a bit of magic to look up a variable name in the caller's
namespace, and kill it. but hey, this is python, that's the kind of
gobbledygood this language is for, right?

:)

ari

Re: [Visualpython-users] Documenting delete

[Bruce S. <ba...@an...>]

--On Wednesday, December 27, 2000 1:37 PM -0500 Ari Heitner 
<ahe...@an...> wrote:

>> I've updated the Visual documentation to include a section on how to
>> delete  a Visual object (by making it invisible, then reassigning the
>> name).
>>
>
> why not include a little "delete" function that takes the name, and does
> this for you?
>
> just a sugar, but it seems to be in demand.

Should this be part of Visual, or just an example in the documentation?

(It is my understanding from previous conversations that there may be a 
problem with performing the delete inside Visual, due to thread 
synchronization, or something....?)

Bruce Sherwood

P.S. Sorry for the duplicate notes about the update of the documentation.

Re: [Visualpython-users] Documenting delete

[Ari H. <ahe...@an...>]

On Wed, 27 Dec 2000, Bruce Sherwood wrote:

> I've updated the Visual documentation to include a section on how to delete 
> a Visual object (by making it invisible, then reassigning the name).
> 

why not include a little "delete" function that takes the name, and does this
for you?

just a sugar, but it seems to be in demand.



ari

[Visualpython-users] Documenting delete

[Bruce S. <ba...@an...>]

I've updated the Visual documentation to include a section on how to delete 
a Visual object (by making it invisible, then reassigning the name).

Bruce Sherwood

[Visualpython-users] Documentation of deletion

[Bruce S. <ba...@an...>]

I've added a section on deleting Visual objects to the Visual 
documentation, both on the VPython web site and in the Doc zip file.

Bruce Sherwood

Re: [Visualpython-users] Automation

[Bruce S. <ba...@an...>]

--On Wednesday, December 27, 2000 8:26 AM -0800 Matthew Grimm 
<mat...@ya...> wrote:

>   Store the data (pos, axis, color, etc) for
>   each individual component of a complex item
>   in a database

Clearly a database issue, nothing particularly to do with Visual.

>   Pull the data from the database and feed it
>   into Visual

If as you say Visual is running on a different computer, you have the 
problem of using a socket or some such mechanism for moving the data, and 
your Visual program has to be checking that new data has arrived. It is my 
understanding that Python has modules for doing this kind of 
intercommunication, though I've never done anything of this kind myself. 
Again, there isn't anything here particularly germane to Visual.

>   Automate the process of refreshing the scene
>   when changes are made to the data

There are three different issues: modify an existing object (change axis or 
color, for example), create a new object, or delete an old object. Only 
deletion involves "nuances of Visual's behavior". There is no direct delete 
of a Visual object. Deletion is a two-step process:

1) Make the object invisible.
2) Assign the name of the object to something else, so that there is no 
longer a valid reference to the object. Example:

     ball = sphere()
     .....
     ball.visible = 0  # make invisible
     ball = None  # no Python name is associated with the sphere any more

Python automatically does "garbage collection" -- that is, Python 
periodically checks to see whether any objects are no longer referenced, 
and removes them from memory, freeing up this memory for other uses. When 
you set ball = None, the number of names referencing the original sphere 
drops to zero, and the memory set aside for keeping track of the sphere 
becomes available to be reclaimed.

If however you set ball = None before making the sphere invisible, Visual 
itself still refers to the sphere (since Visual has to keep displaying it, 
and allowing the user to navigate around it), and Python can't delete the 
sphere. Nor can you delete the sphere, because you no longer have a name of 
the sphere to be able to say ball.visible = 0 (this statement would give an 
error, since "None" doesn't have a visible attribute).

Bruce Sherwood

[Visualpython-users] Automation

[Matthew G. <mat...@ya...>]

I'd like to use Visual to model complex items and I'd
like to accomplish these tasks:

  Store the data (pos, axis, color, etc) for
  each individual component of a complex item
  in a database

  Pull the data from the database and feed it
  into Visual

  Automate the process of refreshing the scene
  when changes are made to the data

I picture the Visual window running on one computer
while on another computer I manipulate the data using
standard DB tools.  Periodically, the scene will be
refreshed and I can look at the results of my data
manipulation.

If anyone has learned any nuances of Visual's behavior
that might help me accomplish these tasks, I'd be
grateful for the sharing.

Thanks so much,

Matthew Grimm
Minneapolis

ps.  Visual rocks! - I've been able to accomplish in
few hours what has taken weeks to do in the past -
nice work Team Visual!

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

[Visualpython-users] Zip files again

[Bruce S. <ba...@an...>]

Thanks to the suggestion of Ihor Rokach to do automated zipping of VPython 
components, there are now again (smaller) zip files on the VPython web 
site. This is going to make my life a lot easier. I'm now using .bat files 
that invoke zip.exe, available at no cost from

	ftp://ftp.freesoftware.com/pub/infozip/Zip.html

To create the full VPython installer package I will continue to use the 
excellent Inno Setup freeware from

	http://www.jrsoftware.org/

The sharp-eyed observer will note that the Doc and Numeric zip files are a 
lot bigger than they used to be. In the Doc zip file, I had previously 
failed to include the Numeric documentation (a large pdf file). In the 
Numeric zip file, I had previously failed to include all of the components 
such as FFT, etc.

Bruce Sherwood

[Visualpython-users] POV-Ray export

[ruth c. <rc...@an...>]

Various people have asked for a way to export VPython scenes to POV-Ray.
There is now a VPython module that will do this - see the VPython home page
or FAQ list.

	Ruth Chabay

RE: [Visualpython-users] Re: download components

[Bruce S. <ba...@an...>]

--On Monday, December 18, 2000 9:15 AM -0500 David Scherer 
<dsc...@CM...> wrote:

>> I have never used it, but have you looked at the dist-utils
>> included in Python
>> 2.0?  I thought here one can write a Python install script, which builds
>> and/or installs extension Modules written in Python and/or C.
>> Doesn't this
>> work as expected?
>
> I think distutils are an easy-to-use setup system by the standards of
> 1970s UNIX.

I looked briefly, and my reaction is like Dave's. In fact, I tried using a 
disk-util package to install Numeric and basically bounced off, because it 
wanted me to run a DOS window in an appropriate directory and type a 
command line with flags. Forget it for many of the users we want to include 
in the enterprise.

Bruce Sherwood

[Visualpython-users] Macintosh update; zip files

[Bruce S. <ba...@an...>]

At http://cil.andrew.cmu.edu/projects/visual the Macintosh version is now 
up to date with the Windows version, except for there being no integrated 
IDLE and some speed issues. Work is proceeding on these issues.

The VPython download adds to Mac Python 2.0 up-to-date demo programs and an 
up-to-date documentation package, with integrated Python and Visual 
documentation. Mac Python 2.0 is a somewhat different package than Windows 
Python 2.0. The Mac version does not include Python documentation but does 
include Numeric. The Windows version has the Python documentation but does 
not include Numeric. For this reason the VPython add-on is different for 
the two platforms.

I am again indebted to Ihor Rokach for his helpful suggestion on how to 
automate the creation of zip files. It would indeed be much better to have 
the zip files for the individual Windows components, especially to ease 
download problems, so I'll try to put this together. (I will continue to 
use an installer, Inno Setup, to make the full VPython package, to address 
the problems we've found with newcomers failing to put Visual in the right 
place.)

Bruce Sherwood

RE: [Visualpython-users] Re: download components

[Ihor R. <ro...@tu...>]

David Scherer wrote:

>However, it's somewhat unfair to ask Bruce to maintain two separate
>installation methods for the sake of the minority of users who fall 
>into one of these cases.  Perhaps someone else will step up (e.g. 
>to write scripts to compile .ZIP files automatically)?

The simplest solution - put into your c:\Python20 directory the
following COMP_ZIP.BAT

zip -9 -u c:Numeric.zip Numeric\*.py Numeric\*.pyd
zip -9 -u c:DLLs.zip DLLs\cvisual.dll
zip -9 -u c:visual.zip visual\*.py  
etc.

and run it every time you need to create a new distribution (here all
the options are for free INFO-ZIP zip.exe utility). 
==
Ihor V.Rokach, PhD

RE: [Visualpython-users] Re: download components

[David S. <dsc...@cm...>]

> Bruce Sherwood wrote:
>
> >Ihor Rokach asked for zip files for experienced users; I'm hoping
> >that it won't actually be necessary to maintain two kinds of files.
> >Is there any issue here other than download time?
>
> 1. There are a LOT of countries with non-free Internet and transmission
> rate < 1Kb/sec :-(
>
> 2. Some people are using the newest version of the Numeric from CVS.
> They will not be happy if your installation overwrites their files. Of
> course, Inno Setup scripts could be configured to avoid such a problem.
> However, nobody knows what is inside the 'black-box'-like installation
> file before the installation :-).

3.  ZIP files can be useful to people on other platforms, who might intend
to take source or Python files and leave the rest.

However, it's somewhat unfair to ask Bruce to maintain two separate
installation methods for the sake of the minority of users who fall into one
of these cases.  Perhaps someone else will step up (e.g. to write scripts to
compile .ZIP files automatically)?

Dave

RE: [Visualpython-users] Re: download components

[David S. <dsc...@cm...>]

> I have never used it, but have you looked at the dist-utils
> included in Python
> 2.0?  I thought here one can write a Python install script, which builds
> and/or installs extension Modules written in Python and/or C.
> Doesn't this
> work as expected?

I think distutils are an easy-to-use setup system by the standards of 1970s
UNIX.

Admittedly, this opinion is based only on experience with an old version of
distutils.

Dave

Re: [Visualpython-users] Re: download components

[Markus G. <gr...@iu...>]

Hi!

I have never used it, but have you looked at the dist-utils included in Python
2.0?  I thought here one can write a Python install script, which builds
and/or installs extension Modules written in Python and/or C.  Doesn't this
work as expected?

Kind regards, Markus

--
                                                                      |\/\/\/|
/------------------------------------------------------------------\  |      |
| Markus GRITSCH                 | phone:    +43 / 1 / 58801-36015 |  |      |
| Institute for Microelectronics | cellular: +43 / 676 / 4973431   |  | (o)(o)
| Technical University of Vienna | fax:      +43 / 1 / 58801-36099 |  C      _)
| Gusshausstrasse  27-29 / E360  | email: gr...@iu... |   | ,___|
| A-1040  Vienna / AUSTRIA       | SMS:   436...@ma... |   |   /
\------------------------------------------------------------------/  /____\
                                                                     /      \
"Computers let you make more mistakes faster than any other invention in human
 history, with the possible exception of handguns and tequila."
                                                               Mitch Radcliffe

[Visualpython-users] Re: download components

[Ihor R. <ro...@tu...>]

Bruce Sherwood wrote:

>Ihor Rokach asked for zip files for experienced users; I'm hoping 
>that it won't actually be necessary to maintain two kinds of files. 
>Is there any issue here other than download time?

1. There are a LOT of countries with non-free Internet and transmission
rate < 1Kb/sec :-(

2. Some people are using the newest version of the Numeric from CVS.
They will not be happy if your installation overwrites their files. Of
course, Inno Setup scripts could be configured to avoid such a problem.
However, nobody knows what is inside the 'black-box'-like installation
file before the installation :-).
==
Ihor V.Rokach

Re: [Visualpython-users] Re: download components

[Bruce S. <ba...@an...>]

--On Sunday, December 17, 2000 1:40 PM +0100 Ihor Rokach 
<ro...@tu...> wrote:

> I have been using free Inno Setup installer
> http://jordanr.dhs.org/isinfo.htm
> since 1998. It is very nice and powerful program especially when used
> together with accompanying tools like Scriptmaker
> http://www.tafweb.com/scriptmaker.html

Many many thanks for this recommendation. Despite of (or because of) it 
being a scripting installer maker, I found it easier to use than the Wise 
engine which I previewed, and more powerful as well. I didn't even feel a 
need to pick up the Scriptmaker tools. With the low-end $200 Wise installer 
I couldn't actually do everything that needed to be done, whereas Inno 
Setup is freeware and has all the power I need.

I've updated the VPython web site Windows download page to feature 
install.exe files rather than zip files. These installers automatically 
detect where Python 2.0 is installed and put the VPython additions into 
that folder. A desktop shortcut is produced by the full VPython installer 
that points to the right place. You can uninstall using the Add/Remove 
Programs control panel.

A disadvantage is that these exe files are bigger than the corresponding 
zip files (particularly noticeable for some unknown reason in the case of 
the documentation files). However, I was going slightly crazy and was in 
danger of making serious mistakes using WinZip. With Inno Setup (stands for 
"Innovative Setup" program), I'm able to have scripts that automatically 
produce the right stuff, with separate control over source and destination 
folders, something that WinZip doesn't provide. And when additional files 
are added to a VPython folder these scripts pick them up, thanks to wild 
cards. Ihor Rokach asked for zip files for experienced users; I'm hoping 
that it won't actually be necessary to maintain two kinds of files. Is 
there any issue here other than download time?

Now does anyone have a comparable great suggestion for the Macintosh?

Bruce Sherwood

P.S. Dave Scherer had pointed out that I had omitted some components from 
the Numeric suite, such as the FFT module. The new stuff includes those 
pieces.

[Visualpython-users] Re: download components

[Ihor R. <ro...@tu...>]

Bruce Sherwood wrote:
> Do any of you have experience with various installer engines? For Windows
> we're thinking that maybe Wise InstallMaker might be the right tool (GUI
> interface and not too expensive). What do you think? And for the Mac there
> is Vise, but while it is free to independent shareware builders it is
> something like $700 to people at universities. Suggestions?

	I have been using free Inno Setup installer 
http://jordanr.dhs.org/isinfo.htm

since 1998. It is very nice and powerful program especially when used
together with accompanying tools like Scriptmaker
http://www.tafweb.com/scriptmaker.html

and Inno Setup Extensions

http://www.wintax.nl/isx/

Anyway, I think simple ZIP-based installation should be available in the
future for some Very Experienced Users who could manage ZIP-files :-).

With best regards,
==
Ihor Rokach

[Visualpython-users] download components

[Bruce S. <ba...@an...>]

I remade the component zip files on the VPython download page (Doc, Demos, 
etc.). I discovered to my chagrin and amazement that the Doc zip file for 
example also contained the Program and Tools folders, even though these 
files didn't display in WinZip itself!

I've also made a tiny name change to prepare for an improved Mac packaging, 
so that F1 in Idle invokes Python20\Doc\VPython.html rather than 
Python20\Doc\\idleindex.html.

Ruth Chabay and I are interested in better ways to handle this stuff. There 
are two problems. We find experimentally that novices, including 
intelligent college students, cannot dependably unzip into a specified 
place: "I installed VPython and nothing works" turns out to translate into 
"I installed Python 2.0 and then installed from your zip file into a random 
folder and I can't figure out how you run the program."

The second problem is that WinZip doesn't provide for specifying a 
destination directory but mimics the directory in which the file currently 
resides. So if I want to make a zip file of C:\Python20\visual, in such a 
way that someone can install into some other location of Python20, I have 
to copy to C:\visual before zipping. Annoying.

Do any of you have experience with various installer engines? For Windows 
we're thinking that maybe Wise InstallMaker might be the right tool (GUI 
interface and not too expensive). What do you think? And for the Mac there 
is Vise, but while it is free to independent shareware builders it is 
something like $700 to people at universities. Suggestions?

At a minimum, the tool should suggest C:\Python20 as the place to install 
files into. It would be even better if the tool could seek out the location 
of Python, no matter where the person had installed it. It would be awfully 
nice not to have to learn yet another scripting language but to be able to 
use a GUI for this work.

Bruce Sherwood

[Visualpython-users] synchronization of visualization thread

[Markus G. <gr...@iu...>]

Hi!

It would be nice if the visualization thread could be somehow
synchronized with the thread running the Python script.  The problem
without synchronization is that the visualization of a scene with much
animation in it is "distorted", because during a visualization cycle
some objects have their old position and some others already appear on
their new location.  For example I have a scene with some springs in
it, each represented by a helix (curve).  Because the whole spring is
moveing around quite fast, part of it has the old coordinates and the
other part already appears at the new calculated ones.

Would it be possible to hav a function similar to visual.rate() which
suspends the visualization thread and another to reactivate it?  In
this way it would be possible in the while loop to suspend it, do the
calculations, activate it and suspend it again before doing the next
cycle.

while 1:
    visual.stop() # suspend the visualization thread
    doMyCalculations()
    visual.start() # resume the visualization thread
    visual.rate(30)

Would this be possible with the current VPython design?

Kind regards, Markus

--
                                                                      |\/\/\/|
/------------------------------------------------------------------\  |      |
| Markus GRITSCH                 | phone:    +43 / 1 / 58801-36015 |  |      |
| Institute for Microelectronics | cellular: +43 / 676 / 4973431   |  | (o)(o)
| Technical University of Vienna | fax:      +43 / 1 / 58801-36099 |  C      _)
| Gusshausstrasse  27-29 / E360  | email: gr...@iu... |   | ,___|
| A-1040  Vienna / AUSTRIA       | SMS:   436...@ma... |   |   /
\------------------------------------------------------------------/  /____\
                                                                     /      \
"Computers let you make more mistakes faster than any other invention in human
 history, with the possible exception of handguns and tequila."
                                                               Mitch Radcliffe

Re: [Visualpython-users] Philosophical question

[Dethe E. <de...@al...>]

> > But I'm not asking about the pure-Python version, I'm asking about
Python
> > + pyOpenGL
> > + Numeric.  What I wanted to know is how much of what VPython does goes
> > beyond
> > what pyOpenGL and Numeric have already ported to C?  And the answer
seems
> > to be,
> > quite a bit: maintaining double-precision floating point and error
> > checking especially.
>
> What Dave Scherer was describing was indeed Python+PyOpenGL+Numeric.
> It was precisely this combination that was not nearly fast enough to be
> usable.

OK, thanks!  That's what I was trying to find out.  Do you think it is the
specific kind of
work being done by VPython, or performance problems with pyOpenGL in
general?

--Dethe

Re: [Visualpython-users] Philosophical question

[Bruce S. <ba...@an...>]

--On Wednesday, December 13, 2000 8:13 AM -0800 Dethe Elza 
<de...@an...> wrote:

> But I'm not asking about the pure-Python version, I'm asking about Python
> + pyOpenGL
> + Numeric.  What I wanted to know is how much of what VPython does goes
> beyond
> what pyOpenGL and Numeric have already ported to C?  And the answer seems
> to be,
> quite a bit: maintaining double-precision floating point and error
> checking especially.

What Dave Scherer was describing was indeed Python+PyOpenGL+Numeric.
It was precisely this combination that was not nearly fast enough to be 
usable.

He went from there to C++ as late as possible, with reluctance, because of 
course after going to C++ it became much more difficult to make changes and 
additions. Yes, precision and error checking are indeed important, but the 
central issue was raw speed.

Bruce Sherwood

Re: [Visualpython-users] Philosophical question

[Dethe E. <de...@an...>]

> That shouldn't be hard to arrange -- looking at the all-python version of
> Visual would indeed be informative. Might not be the simplest example of
GL in
> Python ... but it's easy to arrange.
>
> I don't see any of the pure-python version hanging around the Attics of
> sourceforge cvs. I guess it wasn't on sourceforge yet. But I'm sure Dave
can
> post an old version somewhere, or check it in (or just send a copy) ...

That would be very cool, I'd love to see it.

--Dethe

Re: [Visualpython-users] Philosophical question

[Ari H. <ahe...@an...>]

On Wed, 13 Dec 2000, Dethe Elza wrote:

> > b) why it should matter "as a pedagogical tool" how Visual is implemented. 
> >If the internals were one extremely long PERL line, it shouldn't matter. 
> >The main thing is the friendly Python API. 
> 
> VPython is very nice and simple to use, but it is still easy to want to do
> things which go beyond it.  I'd like to have some good examples of OpenGL
> programming in Python, but this isn't one of them.  Not a criticism of
> VPython, just a disappointment on my part--got to keep looking or roll my
> own. 
> 

That shouldn't be hard to arrange -- looking at the all-python version of
Visual would indeed be informative. Might not be the simplest example of GL in
Python ... but it's easy to arrange.

I don't see any of the pure-python version hanging around the Attics of
sourceforge cvs. I guess it wasn't on sourceforge yet. But I'm sure Dave can
post an old version somewhere, or check it in (or just send a copy) ...




Ari