visualpython-users

[Visualpython-users] Can't load cvisual on win32 machine.

[Kevin B. P. <ke...@ne...>]

    Python info:
            Platform:            Window98SE(win32)
            Python ver:        2.1a1
            Numeric ver:     <17 - 19> Same results with any of the 3.
            VPython ver:      VPython-2001-03-08-win.exe
            cvisual.dll ver:    Taken from DLLs-2001-02-27.zip

    Installed Python 2.1a1 first and then installed vpython from the=
 windows installer. (Installed Numeric module again since the one supplied=
 with vpython will not work with python2.1a1

Traceback(s):

1) >>> from visual import *

Visual-2001-03-08
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in ?
    from visual import *
  File "d:\guess\python21\visual\__init__.py", line 17, in ?
    import cvisual
ImportError: DLL load failed: One of the library files needed to run this=
 application cannot be found.

2)>>> import cvisual
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in ?
    import cvisual
ImportError: DLL load failed: One of the library files needed to run this=
 application cannot be found.
______

    I have tried loading visual with the cvisual.dll in the visual=
 directoy(alone) the python/dll directory(alone) and in both directories=
 with the same results for each.
    
    Is there another library(.dll) file that I'm missing from the standard=
 windows installer? 

    Any help would be appreciated since I have yet to even see VPython=
 running...

kevin88
ke...@ne...
North East Ohio Storm Chasers - Pres.
http://www.neosc.com
"Not the core punching twister wanna-be
that say's cut at the end of a take."

Re: [Visualpython-users] install w/ rpm

[Roger F. <fe...@bi...>]

On Wed, 28 Mar 2001, Bruce Sherwood wrote:

> The report of Andrew Morrison about the difficulties of installing VPython 
> on RH6.2 is pretty discouraging. Unfortunately I am not (yet) a Linux user, 
> so I don't understand the problem. We keep seeing report after report about 
> the extreme difficulty of installing VPython on (some brand of) Linux. Is 
> this a general malady with all applications on Linux? Is it generally the 
> case that it is almost impossible to install Linux applications? If not, 
> what is special about VPython? AAAAARRRRGGGHHHHH!!

It seems to be a number of things (all special about RH6.2?).

- the VPython rpm has been linked against a later (and
  incompatible) version of the C++ libraries. A better way for a general
  Linux distribution might be a source distribution with the usual
  configure; make approach.  

- unfortunately, the compiler that comes with RH6.2 falls over while
  trying to compile CXX (internal compiler error). 
  -> upgrade to get this compiled.

- unfortunately, once that is done, there is a certain amount of brokeness
  in RH6.2 with respect to threading. It seems best to update the kernel
  and libc to get this working 
  -> RH 6.2 updates.

AAARGHHHHHH indeed.

Then, it all works fine!

I guess VPython is some sort of worst-case test for RH 6.2!

Roger.

-- 
Roger Fearick
Dept. of Physics
University of Cape Town

Re: [Visualpython-users] install w/ rpm

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

On Tue, 27 Mar 2001, Andrew Morrison wrote:

> Finally, after I could not get libstdc++ upgraded or changed to the right
> version anymore, I gave up and installed via rpm with --nodeps.

Ennnt! You lose ;)

You *must* install visual with the correct libstdc++ version. The libstdc++
version is specified in the dynamic dependencies of the Visual
library, cvisualmodule.so: 
  nimrod:~/cvs/cvisual$ ldd cvisualmodule.so 
        ...
        libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x406b5000)
        ...

You must find the package on rpmfind and install it. It lists itself as being
in the libstdc++2.10-glibc2.2 package on this machine. I'm sure the version on
RH is at least a few versions behind that. It looks like RH 7 has changed their
naming scheme and are calling the package libstdc++-2.69-69.rpm.

> 
> Then I found out I was using python1.5, which the webstie said not to do,
> so I went out and got python2.0 after getting that installed, I tried to
> uninstall the python-visual rpm and the python-15. rpm and  reinstall
> visual-python with the new version of python.

That's the website being unclear. We removed all the Python-2 syntax in
Visual; it now works in python 1.5.2, and the Linux packages expect to run on
top of 1.5.2.

> 
> It didn't work.   Maybe I'm not using rpm correctly.   Any help would be
> greatly appreciated since I love vpython on my winows machine at home, I'd
> like to use it in the office at school, too.
> 

I apologize for this being a mess. You're welcome to get the source and build
it yourself; putting it in place is not too unstraightforward and it will solve
your library versioning problems. I run debian, and i can't keep around
machines for 3 or 4 RH versions just to produce VPython packages for them.





Ari

Re: [Visualpython-users] install w/ rpm

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

On Wed, 28 Mar 2001, Bruce Sherwood wrote:

> packages for other platforms. In particular, Ari Heitner has carried most 
> of the burden of making Linux versions available, and David Andersen has 
> 
> We have tried to incorporate into the FAQ tips from Linux users about what 
> they had to do to get VPython to work, and we would be delighted to get 
> further information to share.
> 
Sorry, I'm in boston hacking for ibm and i've been dropping the ball on this
one. 

i'll try and go back and reply to the previous msg in this thread.




ari

Re: [Visualpython-users] install w/ rpm

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

Dave Scherer developed the Visual module, and the much-improved version of 
IDLE, on Windows, and that is the platform we have been using with our 
physics students. Members of the VPython group have worked to build 
packages for other platforms. In particular, Ari Heitner has carried most 
of the burden of making Linux versions available, and David Andersen has 
been working on the Macintosh version (which is even harder than the Linux 
version).

We have tried to incorporate into the FAQ tips from Linux users about what 
they had to do to get VPython to work, and we would be delighted to get 
further information to share.

As to how VPython works, Visual is a module implemented in C++ but 
importable by Python as though it were any other ordinary Python module, 
thanks to some glue. We have given the name VPython to the combination of 
Python with the Visual module (and the improved IDLE).

Bruce Sherwood

Re: [Visualpython-users] install w/ rpm

[Andrew M. <mo...@tb...>]

Thanks for keeping this thread alive, Bruce!  :)   I was worried I had 
been forgotten about.   I am new to Vpython, but not so new to linux,
although I am no expert.   In general, rpm installations on RedHat based
distributions work for me about 95% of the time.  The other 5% of the
time, I usually have a missing dependency which I can correct by
downloading and installing the right library or module.

Since I am so new to Vpython, I am still confused about how it
operates.  If it is simply an extension of python, then would it be safe
to call it a collection of libraries?   I don't think it's that simple,
but I really don't know.

Some of the things that I'd like to know are: What OS was Vpython
developed on?   Why is there so little documentation for the linux
version?

I'd be willing to post some error messages I am getting, if that would
help.



On Wed, 28 Mar 2001, Bruce Sherwood wrote:

> The report of Andrew Morrison about the difficulties of installing VPython 
> on RH6.2 is pretty discouraging. Unfortunately I am not (yet) a Linux user, 
> so I don't understand the problem. We keep seeing report after report about 
> the extreme difficulty of installing VPython on (some brand of) Linux. Is 
> this a general malady with all applications on Linux? Is it generally the 
> case that it is almost impossible to install Linux applications? If not, 
> what is special about VPython? AAAAARRRRGGGHHHHH!!
> 
> Bruce Sherwood
> 
> 
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> http://lists.sourceforge.net/lists/listinfo/visualpython-users
> 

Re: [Visualpython-users] install w/ rpm

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

The report of Andrew Morrison about the difficulties of installing VPython 
on RH6.2 is pretty discouraging. Unfortunately I am not (yet) a Linux user, 
so I don't understand the problem. We keep seeing report after report about 
the extreme difficulty of installing VPython on (some brand of) Linux. Is 
this a general malady with all applications on Linux? Is it generally the 
case that it is almost impossible to install Linux applications? If not, 
what is special about VPython? AAAAARRRRGGGHHHHH!!

Bruce Sherwood

Re: [Visualpython-users] Re:How to print ?

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

I installed DISLIN, tried a simple demo, and looked at the documentation. 
DISLIN is an excellent graphing package to go with Python, but as far as I 
can tell it does not address the graphing needs of my physics students. 
(And I don't see how to get a Mac version created.)

The input to DISLIN plotting routines are arrays of data. We don't even 
teach our students about arrays! A typical student program computes step by 
step the motion of (say) a binary star, with a display of the two stars in 
motion. Often there is an accompanying graph of (say) energy vs. time, with 
data points added one at a time to the graph as they are computed. Both the 
motion of the stars and the graph evolve in time, with continual updates.

The reason why we are able to introduce serious computer modeling with 3D 
animations into an introductory physics course is that we can spend just 50 
minutes teaching a very small subset of Python, adequate for modeling a 
range of physical systems, even if the student has never written a program 
before. In this minimalist situation, arrays are one of the very many 
features of Python which we don't introduce. Moreover, we want the graph 
and the animation to run continuously, in parallel. If the issue were 
simply that of making graphs, in the absence of DISLIN we could just have 
students write data to a data file and import that file into Excel or other 
graphing package.

Being able to graph incrementally is a bit tricky, because for autoscaling 
you need incrementally to detect the need to change the axes, tick marks, 
and labels, and rearrange the screen. That's what visual.graph does (and 
dislin doesn't, because it plots arrays, not individual points). So I say 
again that it would be useful to have the ability for visual.graph to 
output postscript and print, even with the availability of the excellent 
DISLIN library.

Bruce Sherwood

Re: [Visualpython-users] fix/hack for hanging program

[Fred Y. <fr...@on...>]

David,

Thank you for considering this problem.  I look forward to getting an
updated VPython that fixes the problem without requiring my hack.

On Wed, Mar 28, 2001 at 11:52:04AM -0500, David Scherer wrote:
> This is fairly embarrassing, and also rather puzzling - why is it working
> for everyone except Fred?

Such situations no longer surprise me.  ;-)

> Maybe you are unaware of the syntactic trick being used to implement the
> locks?  Each lock is removed when it goes out of scope (roughly, when you
> hit a } in the code ):

I thought that might be the case, but I wasn't sure if C++ guaranteed
that behavior -- calling the destructor at exactly the end of the
block -- and I didn't completely trust the compiler in any case.

-- 
Fred Yankowski           fr...@On...      tel: +1.630.879.1312
Principal Consultant     www.OntoSys.com       fax: +1.630.879.1370
OntoSys, Inc             38W242 Deerpath Rd, Batavia, IL 60510, USA

RE: [Visualpython-users] fix/hack for hanging program

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

> I've simply disabled the first 'read_lock' in the
> DisplayObject::remove() method.  I came to this because my application
> always seems to hang at the point where it sets the 'visible' attribute
> of an object to false, and this function is called in response to that
> action.
>
> So, is there something wrong with the locking scheme in cvisual

Yes, there is apparently something wrong.

First of all, some background on the situation: The code in question is
invoked to add or remove an object from the list of visible objects in a
display.  The reason it employs locking is that the visual renderer, in a
separate thread, may be iterating through the same list and displaying the
objects.  It needs to be protected from encountering deleted objects,
objects that are being modified, etc.

To understand what's happening, we need to look in several places

(1) The insert() and remove() functions themselves
(2) DisplayListIterator::next() in displaylist.h - this is the function used
by the renderer to walk through the list
(3) The code in prim.cpp and arrprim.cpp that calls SetVisible(), which
calls insert() and remove()

This last is important, because it turns out that that code takes *another*
write_lock, on "this".  So the sequence for insert goes

lock this
  lock head of list
    lock first item in list
    unlock first item
  unlock head
unlock this

The sequence for remove goes

lock this
  lock prev
  unlock prev
  lock next
  unlock next
unlock this

The sequence for next is a little harder to see:

lock head
  lock first
  unlock head
  lock second
  unlock first
  lock third
  unlock second
  lock fourth

And so on.  We need to watch out for deadlocks between next() in the
rendering thread and either insert() or remove() in the other thread.

No deadlocks can occur between insert() and next().  Intuitively, this is
because both functions are walking down the list "with the grain".

Specifically, each one locks a node A only if
  (1) It holds no other locks
or
  (2) It holds a lock on A.prev and no other nodes

If (1) is the case, this thread has *no* locks and so there can't possibly
be a deadlock while this thread waits for A.  If (2) is the case, and A is
locked by the other thread, the other thread cannot be waiting for A.prev
because it can't have both A.prev.prev and A locked.

However, this logic doesn't work for remove(), which locks this->prev
"against the grain".  In fact, it's pretty easy to see that there CAN be a
deadlock.  To look at just one case:

remove()             next()
--------             ------
lock this
                     lock prev
  lock prev          unlock prev.prev
                     lock this (deadlock)

This is fairly embarrassing, and also rather puzzling - why is it working
for everyone except Fred?

Now, Fred's fix removes the lock on prev.  It's easy to see that the
deadlock is eliminated, since remove() then runs with the grain of the list:

  lock this
    lock next
    unlock next
  unlock this

Alas, this version of remove(), while deadlock proof, is highly suspicious
in another way: it is modifying an object (prev) that isn't locked.  To give
a simple example of how this could cause problems, imagine that next() was
written this way:

void DisplayListIterator::next() {
  DisplayObject *old = ptr;
  ptr = old->next;                 // (1)
  if (old->next)                   // (2)
    old->next->mtx.sync_lock();
  old->mtx.sync_unlock();
}

This is a perfectly legitimate way to write it - ptr is locked going in, so
all the accesses are to a locked object.  However, imagine this code running
alongside Fred's remove().  I won't give the details, but remove() could
change old->next in between (1) and (2) above, resulting in ptr being set to
one object, but a different object being locked!

Now, the agonizing thing is that Fred's version probably *does* work as
things are implemented now.  The prev and next pointers are only used (thank
goodness) in a very small number of places, and from a cursory examination
all of them will probably work given the memory ordering semantics of Intel
SMP.  However, I hesitate to leave this land mine around for the next person
who tries to work with (or port) the code.

I think the best solution is for the locking in remove() to work like this:

lock prev
unlock prev
lock this
  lock next
  unlock next
unlock this

This should be safe because the rendering thread never *modifies* the prev
or this pointers, and multiple Python threads are protected from one another
by the global interpreter lock.  Therefore it isn't necessary to have this
locked until we need to actually modify its prev or next pointers.

For this to work, the write locks have to be *removed* from the code that
calls SetVisible (in prim.cpp and arrprim.cpp, and maybe elsewhere?)
insert() and remove() both need to be modified to lock "this" themselves.  A
plausible implementation of remove() is something like

void DisplayObject::remove() {
  if (prev) {
    DisplayObject::read_lock P(prev->mtx);
    prev->next = next;
  }
  DisplayObject::write_lock T(this->mtx);
  if (next) {
    DisplayObject::read_lock N(next->mtx);
    next->prev = prev;
  }
  prev = next = 0;
  getObject().decrement_reference_count();
}

Unfortunately, I have no more time for this today.

> It does bother me that the insert() and remove() methods of
> DisplayObject both create two locks, not releasing the first one before
> acquiring the second even though the first seems no longer to be needed
> when the second is acquired.  I tried hacking the code to explicitly
> delete the first lock as soon as possible, but that version still
> deadlocks.

Maybe you are unaware of the syntactic trick being used to implement the
locks?  Each lock is removed when it goes out of scope (roughly, when you
hit a } in the code ):

  if (prev) {
    DisplayObject::read_lock P(prev->mtx);
    prev->next = next;
  }                         // <---- unlock P

Dave

FW: [Visualpython-users] UserVector - related question

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

> Don't off-hand follow the visual __iinit__.py code
> related to vector:
>
> >import copy_reg
> >copy_reg.pickle(cvisual.VectorType, lambda v: (vector, tuple(v)), vector)
>
> Whats happening there?

This makes the vector type pickleable by providing functions to convert it
to and from a tuple.  You probably don't need to duplicate it for a
UserVector class - as long as your UserVector is implemented as a Python
class using only pickleable types (including vector) it should be fine.

Dave

[Visualpython-users] install w/ rpm

[Andrew M. <mo...@tb...>]

I have tried just about everything I know how to do to get vpython
installed on a RH6.2 box.

Finally, after I could not get libstdc++ upgraded or changed to the right
version anymore, I gave up and installed via rpm with --nodeps.

Then I found out I was using python1.5, which the webstie said not to do,
so I went out and got python2.0 after getting that installed, I tried to
uninstall the python-visual rpm and the python-15. rpm and  reinstall
visual-python with the new version of python.

It didn't work.   Maybe I'm not using rpm correctly.   Any help would be
greatly appreciated since I love vpython on my winows machine at home, I'd
like to use it in the office at school, too.


Thanks!  


Andrew Morrison 

[Visualpython-users] UserVector - related question

[<Art...@rs...>]

Can someone save me some time:

Don't off-hand follow the visual __iinit__.py code 
related to vector:

>import copy_reg
>copy_reg.pickle(cvisual.VectorType, lambda v: (vector, tuple(v)), vector)

Whats happening there?

ART

[Visualpython-users] UserVector

[<Art...@rs...>]

I have taken a stab at a UserVector mod in the spirit of UserArray, 
with the goal of allowing as seamless as possible interaction between
the cvisual vector and Python classes subbed from UserVector.

Am I reinventing something?

Would like some comment, collaboration on getting it right, as it
does seem a possibly generally useful piece of VPythonica.

How might I go proceed?.

ART

[Visualpython-users] Re:How to print ?

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

> From: Bruce Sherwood <ba...@an...>

> (And I repeat, it does not seem to be available for Macintosh at all.)
    Yes, It is not available for Mac due to very simple reason - Helmut
Michels  (DISLIN creator)  has no Mac in his institute.

> I think there are two different kinds of use. Sophisticated users need a
> sophisticated graphing package, and DISLIN may be it. My intro physics
> students need some very simple autoscaled graph capability of the kind
> offered by visual.graph.

DISLIN contains so called 'quickplots' which are ideal for your purposes.
The following simple example plots a function on the screen

from Numeric import *
from dislin import *
x=arange(100)
qplot(x,sin(x/5.0),100)

To save a plot in Postscript you should add  line

metafl("post")

before calling qplot. There are similar one-line functions for plotting 3D
colour plot, surface plot, contour plot, etc. I think it exactly the thing
your students need. You can find more information about using DISLIN with
NumPy in the SHORT article at

http://www.oreillynet.com/pub/a/network/2000/06/02/magazine/numerically.html

printer-friendly version -
http://www.oreillynet.com/lpt/a/231

Ihor Rokach

Re: [Visualpython-users] Re:How to print ?

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

It sounds like DISLIN is ideal for sophisticated creation of graphs, and 
those who need this power should use it. It sounds like there is no 
particular reason for VPython to have any particular connection to DISLIN, 
or am I still missing something? (And I repeat, it does not seem to be 
available for Macintosh at all.)

--On Sunday, March 25, 2001 10:19 +0200 Ihor Rokach <ro...@tu...> 
wrote:

>      My point was to use DISLIN _instead_ of Visual to produce graphs.
> Visual is the best tool to produce 3D animations, etc. In my opinion,
> however, there are many other more suitable tools to produce 2D plots.
> Please, do not start to reinvent a wheel !  The last C-version of DISLIN
> consist of  565 functions. Are you going to make your 'plot making part'
> of Visual larger and more powerfull? Perhaps, it would be better to
> improve more 'native' Visual capabilities.

I think there are two different kinds of use. Sophisticated users need a 
sophisticated graphing package, and DISLIN may be it. My intro physics 
students need some very simple autoscaled graph capability of the kind 
offered by visual.graph. If I had known about DISLIN perhaps I could have 
gotten the simple capability I need by wrapping some DISLIN functions, 
though the unavailibility for Macintosh would have prevented going in this 
direction.

I have no desire to add features to visual.graph: it is what it is -- a 
very basic graphing routine. And I do not have the time nor currently the 
expertise to improve Visual itself, so my working on visual.graph did not 
take anything away from the evolution of Visual.

Perhaps you (or someone else) could contribute a replacement for 
visual.graph, based on DISLIN or whatever, and if it had the properties my 
students need I would definitely use it. Or if this is not feasible (or not 
available for Macintosh), then it would be nice to have a module that could 
produce Postscript starting from visual.graph. Someone familiar with 
Postscript could presumably create such a module quite quickly, whereas at 
the moment I'm trying to finish a physics textbook for publication this 
summer.

Bruce Sherwood

[Visualpython-users] Re: vpython future direction

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

I realized that the following reply to an individual might be of interest 
to the VPython user group in general:

--On Sunday, March 25, 2001 09:18 -0800 Dale Yocum <da...@yo...> wrote:

> I'm considering using VPython for a intro to computer science course I'm
> developing for high school students.  Can you give me some idea of how
> stable it is for such an application.  Will the students get confused due
> to hitting bugs frequently?

David Binger at Centre College (bi...@ce...) has used VPython in an 
intro programming course, so you might like to ask him about his 
experiences.

We have found VPython to be exceptionally stable on Windows, the only 
platform on which we have had extensive personal experience. The Mac 
version has had little testing and does not yet have a full integrated 
programming environment. Linux versions seem to be subject to difficulties 
in installing, but as far as I know they work well once this is 
straightened out.

During the fall semester we did experience some crashes on Windows, but 
these went away after we installed a later version of the video driver. It 
appears that video driver support for OpenGL has been improving, but that 
earlier drivers didn't always do the right thing. Even in the fall our 
students didn't experience loss of work, because on Windows the VPython 
version of IDLE automatically saves the file when you run (and there is 
unlimited undo). After updating the video drivers our students have not 
experienced any crashes.

There are some language issues to watch for, though I judge them to be 
vastly less severe than in say C++ or Java (and some are shared with these 
other languages). For our purposes in a physics course, it is quite 
unfortunate that 1/2 is zero rather than 0.5, and we have to continually 
warn our students about this. Guido van Rossum has indicated a strong 
interest in addressing this problem in future versions of Python (done in a 
way to preserve compatibility with older programs).

Because names in Python are just labels for structures in memory, the 
following can be confusing:

a = [1, 2, 3]
b = a
b[0] = 555
print a # prints [555, 2, 3]

Changing b[0] changes the same cell in memory as changing a[0]; b = a isn't 
a copy but just the creation of another label for the same list. This holds 
only for "mutable" objects such as lists.

This "bug" ("feature" of Python) affected our students very rarely, given 
the nature of the physics modeling they were doing.

A recent amusing "bug" surfaced, having to do with vectors and Numeric:

B = vector(0,1,0) # magnetic field
omega = e*B/m # angular speed of proton in circular orbit
E = E0*cos(omega*t) # no error message

The student should have written omega = (e/m)*mag(B), because omega is a 
scalar, not a vector. But the calculation of E gave no error message; it 
evaluated a vector corresponding to the three components of omega. Subtle. 
Like the problem of 1/2 not being 0.5, the nasty bugs are the ones that 
give no error messages (or if you like, they do exactly what you told 
Python to do, not what you wanted it to do or expected it to do).

An issue (or non-issue) kicking around the Python community is that 
supposedly the case sensitivity of Python is a big problem for novices. We 
have seen absolutely no evidence for such a problem with novice 
programmers. The data supporting there being a problem were collected in 
circumstances that call the data into question.

> Also, what are the future plans for VPython given your busy school
> schedules?

Several of us continue working on VPython and its upkeep. We also hope that 
additional contributions will come from the growing VPython community.

Bruce Sherwood

[Visualpython-users] Re:How to print ?

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

Bruce Sherwood wrote:
>It was Dave Scherer who said this, not me.
    Oh, excuse me!

> I went and looked at Dislin, and it wasn't obvious to me how this would
> address the problem. For starters, it isn't available for the Macintosh,
> and only certain versions are freeware. Is Dislin intended to display on
> the screen or to a printer (or both)?

First of all, according to the documentation,
    " DISLIN is a  library  of routines for easy drawing of axis sys-
     tems,  curves,  legends,  bar graphs,  pie charts,   3-D colour
     plots, surfaces, contours and maps The software is available
     for several C, Fortran 77 and Fortran 90 compilers."

     DISLIN is free for all free operational systems and for all free
compilers for non-free OS. All DISLIN  extensions for Python (as well as for
Perl or Java) are free. Thus, most of DISLIN versions are freeware.
    Last year there was a long-time discussion in the NumPy mailing list
about the quality and capabilities of different plotting libraries available
for Python. The conclusion was that DISLIN is very flexible and rich library
and gives the highest quality of a hardcopy.


> I agree with the notion that Visual doesn't have to do everything, but
> being able to print (at high resolution) the graphs that are already being
> produced in VPython certainly seems a desirable feature.
     My point was to use DISLIN _instead_ of Visual to produce graphs.
Visual is the best tool to produce 3D animations, etc. In my opinion,
however, there are many other more suitable tools to produce 2D plots.
Please, do not start to reinvent a wheel !  The last C-version of DISLIN
consist of  565 functions. Are you going to make your 'plot making part' of
Visual larger and more powerfull? Perhaps, it would be better to improve
more 'native' Visual capabilities.

> Ihor, can you explain what role (if any?) Dislin could play in making it
> possible to print a  graph produced by visual.graph?
     You can use DISLIN for plotting graphs on screen as well as to save it
in several different formats (WMF, PNG, PPM, Postscript and PDF included).
On Windows you can print plots directly if your printer is HP-compatible.
    BTW, OOP addicts may use a bit outdated pxDISLIN (an object-oriented
wrapper around the DISLIN) available at
http://pantheon.yale.edu/~pmm34/pxdislin.html

With best wishes,
Ihor Rokach

[Visualpython-users] fix/hack for hanging program

[Fred Y. <fc...@ac...>]

As I've mentioned before, I've got a VPython/Tk program that hangs on my
machine, a dual Pentium3 800 system running WinNT4 SP6.  Others have
tried to recreate my problem, but none have seen it.

I've found that with one small change to the C++ code for VPython
itself, I can prevent the deadlock without seeming to cause any other
problems.  Here's the patch:

--- displaylist.cpp.orig        Sat Mar 24 07:09:58 2001
+++ displaylist.cpp     Sat Mar 24 07:12:11 2001
@@ -143,7 +143,7 @@

 void DisplayObject::remove() {
   if (prev) {
-    DisplayObject::read_lock P(prev->mtx);
+    //DisplayObject::read_lock P(prev->mtx);
     prev->next = next;
   }
   if (next) {

--

I've simply disabled the first 'read_lock' in the
DisplayObject::remove() method.  I came to this because my application
always seems to hang at the point where it sets the 'visible' attribute
of an object to false, and this function is called in response to that
action.

So, is there something wrong with the locking scheme in cvisual, or am I
just hacking around a deeper problem such as some glitch in display
drivers?  I admit that I know nothing about OpenGL, much less about what
locking strategy is necessary.  I don't even understand how there can be
contention in my application since all work would seem to be done in the
Tk thread in response to callback functions associated with the Slider
objects.  But here too, I don't understand just what threads are
involved and how they can interleave.

It does bother me that the insert() and remove() methods of
DisplayObject both create two locks, not releasing the first one before
acquiring the second even though the first seems no longer to be needed
when the second is acquired.  I tried hacking the code to explicitly
delete the first lock as soon as possible, but that version still
deadlocks.

My problematic application is still at
<http://www.ontosys.com/src/residue.py>.

Here's the output from glinfo.py, showing my private version of
cvisual.dll.  My video card is a 3Dfx Voodoo-3 3000 16MB AGP, set at
1600 x 1200 x 32 at 85 Hz:

--
$ python glinfo.py
Visual-2001-02-27
  e:\programs\python20\dlls\cvisual.dll Sat Mar 24 07:12:18 2001
  e:\programs\python20\visual\__init__.py Tue Feb 27 21:58:28 2001
  e:\programs\python20\visual\graph.py Tue Feb 20 20:35:42 2001
  d:\winnt\system32\opengl32.dll Thu Nov 18 10:04:00 1999
OpenGL renderer active.
  Vendor: Microsoft Corporation
  Version: 1.1.0
  Renderer: GDI Generic
  Extensions:
                       GL_WIN_swap_hint
                            GL_EXT_bgra
                GL_EXT_paletted_texture

-- 
Fred Yankowski           fr...@On...      tel: +1.630.879.1312
Principal Consultant     www.OntoSys.com       fax: +1.630.879.1370
OntoSys, Inc             38W242 Deerpath Rd, Batavia, IL 60510, USA

[Visualpython-users] fix/hack for hanging program

[Fred Y. <fr...@on...>]

As I've mentioned before, I've got a VPython/Tk program that hangs on my
machine, a dual Pentium3 800 system running WinNT4 SP6.  Others have
tried to recreate my problem, but none have seen it.

I've found that with one small change to the C++ code for VPython
itself, I can prevent the deadlock without seeming to cause any other
problems.  Here's the patch:

--- displaylist.cpp.orig        Sat Mar 24 07:09:58 2001
+++ displaylist.cpp     Sat Mar 24 07:12:11 2001
@@ -143,7 +143,7 @@

 void DisplayObject::remove() {
   if (prev) {
-    DisplayObject::read_lock P(prev->mtx);
+    //DisplayObject::read_lock P(prev->mtx);
     prev->next = next;
   }
   if (next) {

--

I've simply disabled the first 'read_lock' in the
DisplayObject::remove() method.  I came to this because my application
always seems to hang at the point where it sets the 'visible' attribute
of an object to false, and this function is called in response to that
action.

So, is there something wrong with the locking scheme in cvisual, or am I
just hacking around a deeper problem such as some glitch in display
drivers?  I admit that I know nothing about OpenGL, much less about what
locking strategy is necessary.  I don't even understand how there can be
contention in my application since all work would seem to be done in the
Tk thread in response to callback functions associated with the Slider
objects.  But here too, I don't understand just what threads are
involved and how they can interleave.

It does bother me that the insert() and remove() methods of
DisplayObject both create two locks, not releasing the first one before
acquiring the second even though the first seems no longer to be needed
when the second is acquired.  I tried hacking the code to explicitly
delete the first lock as soon as possible, but that version still
deadlocks.

My problematic application is still at
<http://www.ontosys.com/src/residue.py>.

Here's the output from glinfo.py, showing my private version of
cvisual.dll.  My video card is a 3Dfx Voodoo-3 3000 16MB AGP, set at
1600 x 1200 x 32 at 85 Hz:

--
$ python glinfo.py
Visual-2001-02-27
  e:\programs\python20\dlls\cvisual.dll Sat Mar 24 07:12:18 2001
  e:\programs\python20\visual\__init__.py Tue Feb 27 21:58:28 2001
  e:\programs\python20\visual\graph.py Tue Feb 20 20:35:42 2001
  d:\winnt\system32\opengl32.dll Thu Nov 18 10:04:00 1999
OpenGL renderer active.
  Vendor: Microsoft Corporation
  Version: 1.1.0
  Renderer: GDI Generic
  Extensions:
                       GL_WIN_swap_hint
                            GL_EXT_bgra
                GL_EXT_paletted_texture

-- 
Fred Yankowski           fr...@On...      tel: +1.630.879.1312
Principal Consultant     www.OntoSys.com       fax: +1.630.879.1370
OntoSys, Inc             38W242 Deerpath Rd, Batavia, IL 60510, USA

Re: [Visualpython-users] Re:How to print ?

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

--On Friday, March 23, 2001 09:13 +0100 Ihor Rokach <ro...@tu...> 
wrote:

> Bruce Sherwood wrote:
>> For printing graphs, the best thing would probably be to bring in another
>> graphing or drawing package that supports high-quality postscript output,
>> and write code to convert a visual.graph into that package's conception
>> of
> a
>> graph.
>
> Simply use Dislin
>
> http://www.linmpi.mpg.de/dislin
>
> Visual should not be 'the best tool for everything'.

It was Dave Scherer who said this, not me.

I went and looked at Dislin, and it wasn't obvious to me how this would 
address the problem. For starters, it isn't available for the Macintosh, 
and only certain versions are freeware. Is Dislin intended to display on 
the screen or to a printer (or both)?

I agree with the notion that Visual doesn't have to do everything, but 
being able to print (at high resolution) the graphs that are already being 
produced in VPython certainly seems a desirable feature.

Ihor, can you explain what role (if any?) Dislin could play in making it 
possible to print a  graph produced by visual.graph?

Bruce Sherwood

[Visualpython-users] VPython in the Mac

[Aureli S. F. <Aur...@ip...>]

Hi (I am not member of the list, so please answer me directly)!

I tried to install VPython on my computer MacOS 8.6 and OpenGL 1.0 (I have
a DVD and cannot install v.1.2.1 without malfunctioning of the DVD).

The installation was succesful (the demos were running ok) but the display
not so much. I ran the box&sphere example in the doc and:
a)I could not access to the display window (always unselected)
b) No 3D graphics: the bix was just a rectangle andd the sphere was not there.

Is that normal?

I want to use in order to display numerical results from neural networks.
Has someone some experience with that? Do you think is this the correct
tool?

The info on the web sounds great: congratulations! I hope you success so
good for the Mac.
Thanks in advance,
Aureli

#################################
Aureli Soria Frisch
Fraunhofer IPK
Dept. Pattern Recognition

post: Pascalstr. 8-9, 10587 Berlin, Germany
e-mail:au...@ip...
fon: +49 30 39 00 61 50
fax: +49 30 39 17 517
#################################

[Visualpython-users] Re:How to print ?

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

Bruce Sherwood wrote:
> For printing graphs, the best thing would probably be to bring in another
> graphing or drawing package that supports high-quality postscript output,
> and write code to convert a visual.graph into that package's conception of
a
> graph.

Simply use Dislin

http://www.linmpi.mpg.de/dislin

Visual should not be 'the best tool for everything'.

I.Rokach

RE: [Visualpython-users] How to print ?

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

On Wed, 21 Mar 2001, David Scherer wrote:

> For printing graphs, the best thing would probably be to bring in another
> graphing or drawing package that supports high-quality postscript output,
> and write code to convert a visual.graph into that package's conception of a
> graph.
> 
heheheeh.

i vote for a conversion tool that uses the SML-NJ "Turtle" postscript-output
language .... a python module that generates Turtle code (which runs under
SML).



ari

RE: [Visualpython-users] How to print ?

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

For printing graphs, the best thing would probably be to bring in another
graphing or drawing package that supports high-quality postscript output,
and write code to convert a visual.graph into that package's conception of a
graph.

"Direct" high-resolution printing of 3D scenes could be done by modifying
cvisual to point its OpenGL context at a high-resolution WMF in memory and
rendering a frame.  That approach obviously requires some C++, OpenGL, and
Windows programming skills.

The POV approach also doesn't sound bad, although I haven't tried it.  Maybe
for convenience povexport.py should be able to run POVray through
os.system()?

Dave

> -----Original Message-----
> From: vis...@li...
> [mailto:vis...@li...]On Behalf Of
> Markus Gritsch
> Sent: Wednesday, March 21, 2001 12:18 PM
> To: Bruce Sherwood; vis...@li...
> Subject: Re: [Visualpython-users] How to print ?
>
>
> Bruce Sherwood wrote:
>
> > So really what is needed (I think) is for someone to write a
> module to go
> > from a Visual scene (or graph) to Postscript, analogous to what
> Ruth Chabay
> > has done for going to PovRay. This might be useful even for 3D scenes if
> > you don't care about the ray-traced quality obtained from PovRay.
>
> For a moment i thought about this, too, but this would be a *LOT*
> of work if
> you would like to reproduce the scene exactly, although it would not be
> impossible.  Maybe things would simplify if only 2D is considered, but
> creating a reasonable PostScript image of a 3D scene is quite complicated
> (geometry transformation, color shading, ...).
>
> Markus
>
>
>
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> http://lists.sourceforge.net/lists/listinfo/visualpython-users
>