visualpython-users

Re: [Visualpython-users] One more stab at OS X compatibility

[Martin C. <cos...@wa...>]

Arthur wrote:
[]
> gtkglextmm is more of an issue

There is now a Fink package of gtkglextmm, so this is now no more an 
issue than the other packages. In fact, I got vpython-core2 CVS to build 
on OSX 10.4.8/intel without problem, using existing Fink packages for 
all prerequisites:

   fink install freetype219 fontconfig2-dev libglademm2.4 gtkglextmm 
scipy-py25 boost1.33
     (this list is probably not complete)
   sh ./autogen.sh
   export 
PKG_CONFIG_PATH=/sw/lib/fontconfig2/lib/pkgconfig:/sw/lib/xft2/lib/pkgconfig:/sw/lib/freetype219/lib/pkgconfig
   ./configure --prefix=/sw
   make

-- 
Martin

Re: [Visualpython-users] Mac 10.4: _tkinter.TclError: this isn't a Tk application couldn't connect to display ":0.0"

[Jon S. <js...@gm...>]

Thanks

I did determine that the problem was an X11 problem, and after repairing
permissions, reinstalling python, and vpython, and resinstalling x11
1.1.3...I'm happy to say that back in business.

Happy Thanksgiving to all


On 11/22/06 4:19 PM, "Martin Costabel" <cos...@wa...> wrote:

> Jon Schull wrote:
>> Vpython has stopped working.  What to do?
> 
> What you show has nothing to do with vpython nor with tkinter. You need
> to run X11 which you don't seem to be able to.
> 
>> I'm suddenly having problems I remember from 3 years ago and gather it has
>> something to do with the upgrade of x11.  But I can't figure out how to get
>> it going again.
>> 
>> When I run vpython I get
>> 
>> Xlib: connection to ":0.0" refused by server
>> Xlib: No protocol specified
> 
> The X server is not starting up completely.
> 
>> Traceback (most recent call last):
>>   File "/sw/bin/idle2.4", line 5, in ?
>>     main()
>>   File "/sw/lib/python2.4/idlelib/PyShell.py", line 1350, in main
>>     root = Tk(className="Idle")
>>   File "/sw/lib/python2.4/lib-tk/Tkinter.py", line 1569, in __init__
>>     self.tk = _tkinter.create(screenName, baseName, className, interactive,
>> wantobjects, useTk, sync, use)
>> _tkinter.TclError: this isn't a Tk applicationcouldn't connect to display
>> ":0.0"
>> [apples-powerbook-g4-99:/] apple%
> 
> You get this when you try to run vpython without running X11.
> 
>> x11 is running
> 
> Actually no. It tries to start, but doesn't manage.
> 
>> But if I try running startX from a non-x11 terminal I get this:
> 
> Using startx on MacOSX is always a bad idea. Why don't you just
> double-click on X11.app?
> 
>> /usr/X11R6/bin/startx: line 33: [: /Users/apple: binary operator expected
>> /usr/X11R6/bin/startx: line 42: [: /Users/apple: binary operator expected
> 
> This looks like you have a user name with a space inside, like "apple
> user". Dont't do this, it will break all kinds of things.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon Schull, Ph.D.
Associate Professor
Information Technology
Rochester Institute of Technology
102 Lomb Memorial Drive
Rochester, New York 14623
sc...@di...
fax: 978-246-0487
cell: 585-738-6696

Re: [Visualpython-users] Mac 10.4: _tkinter.TclError: this isn't a Tk application couldn't connect to display ":0.0"

[Martin C. <cos...@wa...>]

Jon Schull wrote:
> Vpython has stopped working.  What to do?

What you show has nothing to do with vpython nor with tkinter. You need 
to run X11 which you don't seem to be able to.

> I'm suddenly having problems I remember from 3 years ago and gather it has
> something to do with the upgrade of x11.  But I can't figure out how to get
> it going again.
> 
> When I run vpython I get
> 
> Xlib: connection to ":0.0" refused by server
> Xlib: No protocol specified

The X server is not starting up completely.

> Traceback (most recent call last):
>   File "/sw/bin/idle2.4", line 5, in ?
>     main()
>   File "/sw/lib/python2.4/idlelib/PyShell.py", line 1350, in main
>     root = Tk(className="Idle")
>   File "/sw/lib/python2.4/lib-tk/Tkinter.py", line 1569, in __init__
>     self.tk = _tkinter.create(screenName, baseName, className, interactive,
> wantobjects, useTk, sync, use)
> _tkinter.TclError: this isn't a Tk applicationcouldn't connect to display
> ":0.0"
> [apples-powerbook-g4-99:/] apple%

You get this when you try to run vpython without running X11.

> x11 is running

Actually no. It tries to start, but doesn't manage.

> But if I try running startX from a non-x11 terminal I get this:

Using startx on MacOSX is always a bad idea. Why don't you just 
double-click on X11.app?

> /usr/X11R6/bin/startx: line 33: [: /Users/apple: binary operator expected
> /usr/X11R6/bin/startx: line 42: [: /Users/apple: binary operator expected

This looks like you have a user name with a space inside, like "apple 
user". Dont't do this, it will break all kinds of things.

-- 
Martin

[Visualpython-users] Mac 10.4: _tkinter.TclError: this isn't a Tk application couldn't connect to display ":0.0"

[Jon S. <js...@gm...>]

Vpython has stopped working.  What to do?

I'm suddenly having problems I remember from 3 years ago and gather it has
something to do with the upgrade of x11.  But I can't figure out how to get
it going again.

When I run vpython I get

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

Traceback (most recent call last):
  File "/sw/bin/idle2.4", line 5, in ?
    main()
  File "/sw/lib/python2.4/idlelib/PyShell.py", line 1350, in main
    root = Tk(className="Idle")
  File "/sw/lib/python2.4/lib-tk/Tkinter.py", line 1569, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive,
wantobjects, useTk, sync, use)
_tkinter.TclError: this isn't a Tk applicationcouldn't connect to display
":0.0"
[apples-powerbook-g4-99:/] apple%

   
x11 is running
But if I try running startX from a non-x11 terminal I get this:

/usr/X11R6/bin/startx: line 33: [: /Users/apple: binary operator expected
/usr/X11R6/bin/startx: line 42: [: /Users/apple: binary operator expected


XFree86 Version 4.4.0 / X Window System
(protocol Version 11, revision 0, vendor release 6600)
[DRI] screen 0 installation complete
 

Re: [Visualpython-users] New version of x11 (1.1.3) again

[Bruce S. <Bru...@nc...>]

Yup. It had been a while since I looked to see whether there was a 
binary version. I've updated vpython.org to reflect the new situation.

Bruce

Martin Costabel wrote:

>Mark Hammond wrote:
>  
>
>>I did finally get Vpython working... and it wasn't all that hard. As I
>>mentioned in my earlier post, I used the expert installation instructions
>>on my daughter's new MacBook (which has the latest version of X11 on it).
>>It didn't work. I followed Bruce's suggestions, finding that vpython and
>>python were apparently not where they should be (I guess not on my hard
>>drive at all). I opened Fink Commander and followed the easy non-Intel
>>instructions, installing visualpython2.4 from binaries. It worked fine.
>>
>>So I'm not sure why the need for the expert/Intel instructions.
>>    
>>
>
>There is indeed no need right now. Binaries for 
>visual-py2[34]-3.2.9-1002 exist for both ppc and intel on the Fink 
>bindist server. The instructions on the web page are from some months 
>ago when there was no intel binary package yet. Plus, it is somewhat 
>hard to verify, because the Fink package database web page pretends not 
>to know the existence of any binary version of visual-pyXX-3.2.9 for OSX 
>10.4. This is a known bug of the package database (shows only packages 
>in "release", not in "current".)
>
>But I would still like to understand why building from source ("expert 
>instructions") did not work. It should, too.
>
>  
>

Re: [Visualpython-users] New version of x11 (1.1.3) again

[Martin C. <cos...@wa...>]

Mark Hammond wrote:
> I did finally get Vpython working... and it wasn't all that hard. As I
> mentioned in my earlier post, I used the expert installation instructions
> on my daughter's new MacBook (which has the latest version of X11 on it).
> It didn't work. I followed Bruce's suggestions, finding that vpython and
> python were apparently not where they should be (I guess not on my hard
> drive at all). I opened Fink Commander and followed the easy non-Intel
> instructions, installing visualpython2.4 from binaries. It worked fine.
> 
> So I'm not sure why the need for the expert/Intel instructions.

There is indeed no need right now. Binaries for 
visual-py2[34]-3.2.9-1002 exist for both ppc and intel on the Fink 
bindist server. The instructions on the web page are from some months 
ago when there was no intel binary package yet. Plus, it is somewhat 
hard to verify, because the Fink package database web page pretends not 
to know the existence of any binary version of visual-pyXX-3.2.9 for OSX 
10.4. This is a known bug of the package database (shows only packages 
in "release", not in "current".)

But I would still like to understand why building from source ("expert 
instructions") did not work. It should, too.

-- 
Martin

[Visualpython-users] New version of x11 (1.1.3) again

[Mark H. <mha...@st...>]

I did finally get Vpython working... and it wasn't all that hard. As I
mentioned in my earlier post, I used the expert installation instructions
on my daughter's new MacBook (which has the latest version of X11 on it).
It didn't work. I followed Bruce's suggestions, finding that vpython and
python were apparently not where they should be (I guess not on my hard
drive at all). I opened Fink Commander and followed the easy non-Intel
instructions, installing visualpython2.4 from binaries. It worked fine.

So I'm not sure why the need for the expert/Intel instructions.

Mark

Re: [Visualpython-users] visual python and qt (by pyqt4)

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

Bruce Sherwood wrote:
> I don't really know anything about pyqt, but its web site seems to 
> specify a rather restrictive licensing policy, which is moreover 
> different for different platforms, plus complications in installing the 
> product, so this doesn't seem a suitable sample program for VPython. I 
> can't comment on threading etc.
>
> Bruce Sherwood
>   

I agree that general support for PyQt4 is outside the interests and 
goals of the developers, but it's not necessarily outside the interests 
and goals of other Vpython users.  (As far as sample programs are 
concerned,  I can argue both ways.  There's room for discussion.) Qt has 
some nice features.  I have been planning to look at Vpython PyQt 
integration after the semester ends.

I don't think that the licenses vary by platform in PyQt4,  but they did 
in PyQt3   (I may be wrong about that.)
There is a GPL version of PyQt4 as well as an educational version and a 
commercial version.   I can't read legalese, but IFAICT all three 
versions are identical except that the commercial version allows for 
inclusion in commercial products and includes support,  while the 
educational version includes support. 

Without a doubt, the website is not clear on this, and installation 
instructions are not the best (and possibly even wrong).  Without a 
doubt PyQt4/Vpython is not for the average user.

In the meantime, I think this list might be the right place to discuss 
the technical issues.  As I said, I want to explore the issue, but not 
right now.

-gary


> nom de guerre wrote:
>
>   
>> hello.
>>
>> i try to use pyqt interface to connect with visual python. i would 
>> like to ask what do You think about that kind of methodology (whether 
>> it is thread safe, elegant, etc.). It seems to work modulo the 
>> quiting. maybe after some edition and disscussion we can include a 
>> sample like this in vpython examples?
>>
>> ps the program requires PyQt4 to run..
>>
>> bests,
>> szymon stoma.
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>  
>>
>>     
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>   

Re: [Visualpython-users] visual python and qt (by pyqt4)

[Bruce S. <Bru...@nc...>]

I don't really know anything about pyqt, but its web site seems to 
specify a rather restrictive licensing policy, which is moreover 
different for different platforms, plus complications in installing the 
product, so this doesn't seem a suitable sample program for VPython. I 
can't comment on threading etc.

Bruce Sherwood

nom de guerre wrote:

> hello.
>
> i try to use pyqt interface to connect with visual python. i would 
> like to ask what do You think about that kind of methodology (whether 
> it is thread safe, elegant, etc.). It seems to work modulo the 
> quiting. maybe after some edition and disscussion we can include a 
> sample like this in vpython examples?
>
> ps the program requires PyQt4 to run..
>
> bests,
> szymon stoma.
>
>------------------------------------------------------------------------
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys - and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users
>  
>

[Visualpython-users] New X11

[Mark H. <mha...@st...>]

Earlier someone noted that after updating X11, Vpython didn't work. Thank=
s
for the heads-up... it prevented me from updating X11.

Out of curiosity, I decided to do a fresh install on my daughter's brand
new MacBook.  I loaded Developer Tools and X11 using the OS X disk (this
included the newest version of X11). I then followed the expert
instructions for loading Vpython to the letter.

The result: "No such file or directory" when I try to start vpython.

I should note that the Vpython install on my own MacBook Pro this summer
did not go perfectly smoothly... for some unknown (to me) reason, in bash
I get a permission denied message. I can only start Vpython in tcsh. I
checked the permissions, and all appears in order.

I am not a very sophisticated user... I don't know alot of Unix commands,
I don't see problems such as the above as an "interesting" challenge. Yet=
,
I DO know how to follow directions and I'm not freaked out by the command
line (I am of a certain age... "in the beginning there was the command
line").  So not being able to install Vpython from the current instructio=
n
set is a real problem.

Mark Hammond

[Visualpython-users] pipes demo

[Bruce S. <Bru...@nc...>]

In the Contributed section of vpython.org is a new program pipes.py by a 
student at North Carolina State University. It looks similar to a screen 
saver, with pipes getting randomly connected.

Bruce Sherwood

Re: [Visualpython-users] One more stab at OS X compatibility

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

Dethe Elza wrote:

>Hi folks,
>
>I'm trying to get beta5 to build and I'm stuck in ./configure.  I've  
>even buckled and installed Fink, against my better judgement, just  
>for this one project.  I've tried to install all the pre-requisites  
>for VPython but I'm still getting the following error:
>
>checking for GTK... configure: error: gtkglextmm 1.2, pangoft2,  
>glibmm-2.4, and pangomm-1.4 libglademm-2.4 are arequired on Unix-like  
>systems
>
>  
>
The "mm" series of GTK+ libraries are (as I understand it) the C++ 
wrapper for the corresponding gtk libraries.

Some of what I think you are missing glibmm, libglademm (grab sigc++ 
while you are there) seem to be available at

http://ftp.acc.umu.se/pub/GNOME/bindings/2.16/2.16.0/sources/c++/

gtkglextmm is more of an issue

Which is a guess consistent with what I see at 

http://www.student.cs.uwaterloo.ca/~azolotko/cse more 488onmac.html

where instructions on building gtkglextmm for fink are given.

I don't understand the relationship between FreeBSD and fink, but there 
does seem to be a FreeBSD version of gtkglextmm.

http://www.freebsdsoftware.org/x11-toolkits/

Pangomm is a wildcard. I don't see a separate fink version, but do see 
evidence of programs dependent on it being built on fink.  I suspect it 
is included in
what you have.

Have you dealt with., prepared for, the boost dependency issues.  I 
promise you that they are there as well, but not sure configure deals 
with them.

Anxious to help...

And counseling patience.

Art







>Now, I have gtk+, gtk+-shlibs, gtk+2, gtk+2-dev, gtk+2-shlibs, gtk- 
>glarea, gtkglarea2, gtkglext1, gtkglext1-shlibs, gtkmm2, gtkmm2-dev,  
>gtkmm2-shlibs, pango1, pango1-dev, pango1-shlibs, pango1-xft2, pango1- 
>xft2-dev, pango1-xft2-shlibs, etc.
>
>In other words, I've installed every fink library I can find which  
>might be helpful in getting VPython to build, but no luck so far.   
>Apparently VPython wasn't dependent enough on GTK and had to move  
>further towards platform-dependence.  Please correct me if I'm wrong,  
>but at this point my guess is that VPython no longer supports  
>building on OS X at all.
>
>--Dethe
>
>"Any idea that couldn't stand a few decades of neglect is not worth  
>anything." --Gabriel Garcia Marquez
>
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>
>  
>

[Visualpython-users] One more stab at OS X compatibility

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

Hi folks,

I'm trying to get beta5 to build and I'm stuck in ./configure.  I've  
even buckled and installed Fink, against my better judgement, just  
for this one project.  I've tried to install all the pre-requisites  
for VPython but I'm still getting the following error:

checking for GTK... configure: error: gtkglextmm 1.2, pangoft2,  
glibmm-2.4, and pangomm-1.4 libglademm-2.4 are required on Unix-like  
systems

Now, I have gtk+, gtk+-shlibs, gtk+2, gtk+2-dev, gtk+2-shlibs, gtk- 
glarea, gtkglarea2, gtkglext1, gtkglext1-shlibs, gtkmm2, gtkmm2-dev,  
gtkmm2-shlibs, pango1, pango1-dev, pango1-shlibs, pango1-xft2, pango1- 
xft2-dev, pango1-xft2-shlibs, etc.

In other words, I've installed every fink library I can find which  
might be helpful in getting VPython to build, but no luck so far.   
Apparently VPython wasn't dependent enough on GTK and had to move  
further towards platform-dependence.  Please correct me if I'm wrong,  
but at this point my guess is that VPython no longer supports  
building on OS X at all.

--Dethe

"Any idea that couldn't stand a few decades of neglect is not worth  
anything." --Gabriel Garcia Marquez

Re: [Visualpython-users] windows.getclick() issue resolved???

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

Jonathan -

Thanks for the brain dump.

Lots to try to digest. 

But with the little experimentation I have just done, on Windows, I am 
not seeing a difference in the shutdown behavior when using the *.pyd
with my patch that (seems to) avoid the mouse.getclick() crash, and the 
one in the regular distro of 4.0bets5. 

In fact when running the Hanoi.py demo, either from SciTE or from IDLE, 
and shutting the  display window, the python process  stays alive and  I 
need to force  a shutdown. 

I hadn't noticed this previously because I had been using Textpad using 
python.exe which in effect opens a DOS window to run python, and I have 
gotten used to closing the DOS window manually after the display window 
closes, which must force the python process to shutdown. There is a 
"Close DOS window on exit" option in Textpad that I generally don't use, 
since I want to see any error messages generated.  But I just toggled it 
on, and the DOS window does *not* close when closing  the visual 
display, again consistent with the fact that the python process is not 
exiting.

Is anyone finding anything different than what I am finding?

Frankly I consider the process end issue a nuisance, but nothing worse, 
whereas the mouse.getclick() crash is a deal killer for vpython 4.xxx on 
Windows.  Seems to me that if my patch solves that, we should go with it 
and try to deal with the shutdown issue as a separate matter, which at 
the moment it does seem to be in any case.

All being said from what I am seeing from a Windows-centric viewpoint.  
Guess I should see if anything changes about this position when I try my 
patch on Linux, hopefully tomorrow.

Art

Jonathan Brandmeyer wrote:

>On Sat, 2006-11-04 at 09:33 -0500, Arthur wrote:
>  
>
>>Hi folks -
>>
>>Bruce is tied up, I know, trying to get his book to the publisher and 
>>will not get to looking to what I am proposing re: numpy compatibility 
>>until he gets that behind him. 
>>
>>In the meantime ---
>>
>>A side effect of getting myself involved in that process was getting a 
>>more serious look at Vpython4.0 beta, which I had been avoiding because 
>>of the known bugs. And one look at the lighting_and_texture.py does get 
>>one excited.
>>
>>The mouse.getclick() issue - which I first saw manifested in running the 
>>dipole.py demo - seems the only deal killer bug. 
>>
>>So I have taken a shot at it.
>>
>>After gaining what - given my C++ (lack of) expertise - is only a vague 
>>understanding of what is going on in the relevant code,  I took a shot - 
>>just changing line 185 of the mouseobject.cpp from:
>>
>>shared_ptr<event> ret = events.py_pop();
>>
>>to
>>
>>shared_ptr<event> ret = events.pop();
>>
>>which has the effect - in the context of the code - of short-circuiting 
>>the running of code that involves the direct manipulation of the Python 
>>gil (global interpreter lock) when processing the return value from a 
>>mouseclick.
>>
>>And - lo and behold - from the best I can presently determine, the 
>>mouse.getclick() crash issues go away.
>>    
>>
>
>Very interesting.  The function of py_pop() vs pop() is related to
>shutdown.
>
>Keep the following rule in mind:
>The Python interpreter itself is not thread-safe.  For any C/C++ code to
>invoke any python function, including Py_INCREF() and kin, that code
>must hold the Global Interpreter Lock.  In native/plain/pure python
>multithreaded code, both threads run because each one periodically
>releases and re-acquires the lock.
>
>VPython's rendering thread directly accesses Python objects very rarely,
>and therefore tries hard to avoid holding the GIL.  The rendering of any
>array-like object (curve, convex, faces) must access the elements of the
>Numeric array, and shutdown code must tell the interpreter to force any
>infinite loops to exit.  In the case of array access, no Python
>functions are called because the numeric/numarray wrappers for those
>particular access functions dove below the published API and accessed
>the pointers directly.
>
>
>Scenario:
>- user program calls mouse.get_click() when no events are queued up.
>This eventually dispatches to events.pop(), which blocks indefinitely
>until user action through the GUI generates a click event.
>- Instead of generating a click event, the user is done with the program
>and clicks on the window-close button.
>- The window management code closes out the windows and exits the
>background/worker/renderer thread.  As the last action of the outgoing
>thread, (see src/python/wrap_display_kernel.cpp), force_py_exit() is
>called.  This function adds a "pending call" to the interpreter to call
>std::exit() (which is also called by sys.exit()).  This is necessary to
>force an infinite loop in the user's code (a very common idiom) to
>terminate.
>
>But - in order to add the pending call, the shutdown code must make a
>call into the interpreter.  Therefore, it must acquire the GIL.  Since
>the interpreter did not release the lock when it called events.pop(), a
>deadlock occurred.  The interpreter thread is waiting for a user event
>that will never arrive, and the gui thread is waiting for the
>interpreter to release a lock that it never will.
>
>My solution to this problem was to explicitly release the GIL when
>popping events off any of the event queues (which is what py_pop()
>does), and periodically wake up to call any pending events (see
>include/util/atomic_queue.hpp, src/core/util/atomic_queue.cpp).
>Apparently, the code that makes this happen has a bug in it.  Your
>options are to either fix that code or come up with a new shutdown
>strategy and implement it.
>
>  
>
>>Problem is that I suspect Jonathan had his reasons for doing his Python 
>>gil thing, and I cannot determine what unwanted side effects this change 
>>might have, e.g. on platforms other than windows.
>>    
>>
>
>I think the "failure to exit" problem will persist on Windows, although
>IDLE may attempt to force program termination in a way that I'm not
>expecting.
>
>  
>
>>Jonathan is probably the only person in a position to comment here.
>>
>>You there, Jonathan?
>>    
>>
>
>Yep.  Hope this information helps.
>
>-Jonathan
>
>
>
>  
>

Re: [Visualpython-users] windows.getclick() issue resolved???

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

On Sat, 2006-11-04 at 09:33 -0500, Arthur wrote:
> Hi folks -
> 
> Bruce is tied up, I know, trying to get his book to the publisher and 
> will not get to looking to what I am proposing re: numpy compatibility 
> until he gets that behind him. 
> 
> In the meantime ---
> 
> A side effect of getting myself involved in that process was getting a 
> more serious look at Vpython4.0 beta, which I had been avoiding because 
> of the known bugs. And one look at the lighting_and_texture.py does get 
> one excited.
> 
> The mouse.getclick() issue - which I first saw manifested in running the 
> dipole.py demo - seems the only deal killer bug. 
> 
> So I have taken a shot at it.
> 
> After gaining what - given my C++ (lack of) expertise - is only a vague 
> understanding of what is going on in the relevant code,  I took a shot - 
> just changing line 185 of the mouseobject.cpp from:
> 
> shared_ptr<event> ret = events.py_pop();
> 
> to
> 
> shared_ptr<event> ret = events.pop();
> 
> which has the effect - in the context of the code - of short-circuiting 
> the running of code that involves the direct manipulation of the Python 
> gil (global interpreter lock) when processing the return value from a 
> mouseclick.
> 
> And - lo and behold - from the best I can presently determine, the 
> mouse.getclick() crash issues go away.

Very interesting.  The function of py_pop() vs pop() is related to
shutdown.

Keep the following rule in mind:
The Python interpreter itself is not thread-safe.  For any C/C++ code to
invoke any python function, including Py_INCREF() and kin, that code
must hold the Global Interpreter Lock.  In native/plain/pure python
multithreaded code, both threads run because each one periodically
releases and re-acquires the lock.

VPython's rendering thread directly accesses Python objects very rarely,
and therefore tries hard to avoid holding the GIL.  The rendering of any
array-like object (curve, convex, faces) must access the elements of the
Numeric array, and shutdown code must tell the interpreter to force any
infinite loops to exit.  In the case of array access, no Python
functions are called because the numeric/numarray wrappers for those
particular access functions dove below the published API and accessed
the pointers directly.


Scenario:
- user program calls mouse.get_click() when no events are queued up.
This eventually dispatches to events.pop(), which blocks indefinitely
until user action through the GUI generates a click event.
- Instead of generating a click event, the user is done with the program
and clicks on the window-close button.
- The window management code closes out the windows and exits the
background/worker/renderer thread.  As the last action of the outgoing
thread, (see src/python/wrap_display_kernel.cpp), force_py_exit() is
called.  This function adds a "pending call" to the interpreter to call
std::exit() (which is also called by sys.exit()).  This is necessary to
force an infinite loop in the user's code (a very common idiom) to
terminate.

But - in order to add the pending call, the shutdown code must make a
call into the interpreter.  Therefore, it must acquire the GIL.  Since
the interpreter did not release the lock when it called events.pop(), a
deadlock occurred.  The interpreter thread is waiting for a user event
that will never arrive, and the gui thread is waiting for the
interpreter to release a lock that it never will.

My solution to this problem was to explicitly release the GIL when
popping events off any of the event queues (which is what py_pop()
does), and periodically wake up to call any pending events (see
include/util/atomic_queue.hpp, src/core/util/atomic_queue.cpp).
Apparently, the code that makes this happen has a bug in it.  Your
options are to either fix that code or come up with a new shutdown
strategy and implement it.

> Problem is that I suspect Jonathan had his reasons for doing his Python 
> gil thing, and I cannot determine what unwanted side effects this change 
> might have, e.g. on platforms other than windows.

I think the "failure to exit" problem will persist on Windows, although
IDLE may attempt to force program termination in a way that I'm not
expecting.

> Jonathan is probably the only person in a position to comment here.
> 
> You there, Jonathan?

Yep.  Hope this information helps.

-Jonathan

[Visualpython-users] windows.getclick() issue resolved???

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

Hi folks -

Bruce is tied up, I know, trying to get his book to the publisher and 
will not get to looking to what I am proposing re: numpy compatibility 
until he gets that behind him. 

In the meantime ---

A side effect of getting myself involved in that process was getting a 
more serious look at Vpython4.0 beta, which I had been avoiding because 
of the known bugs. And one look at the lighting_and_texture.py does get 
one excited.

The mouse.getclick() issue - which I first saw manifested in running the 
dipole.py demo - seems the only deal killer bug. 

So I have taken a shot at it.

After gaining what - given my C++ (lack of) expertise - is only a vague 
understanding of what is going on in the relevant code,  I took a shot - 
just changing line 185 of the mouseobject.cpp from:

shared_ptr<event> ret = events.py_pop();

to

shared_ptr<event> ret = events.pop();

which has the effect - in the context of the code - of short-circuiting 
the running of code that involves the direct manipulation of the Python 
gil (global interpreter lock) when processing the return value from a 
mouseclick.

And - lo and behold - from the best I can presently determine, the 
mouse.getclick() crash issues go away.

Problem is that I suspect Jonathan had his reasons for doing his Python 
gil thing, and I cannot determine what unwanted side effects this change 
might have, e.g. on platforms other than windows.

Jonathan is probably the only person in a position to comment here.

You there, Jonathan?

Art

Re: [Visualpython-users] Numpy compatibility

[Eric A. <Ay...@ma...>]

I'll second this! Thanks a lot for the good work!

-ea

-----------------------------------------------------------------
Dr. Eric Ayars
Assistant Professor of Physics
California State University, Chico
ay...@ma...


On Oct 30, 2006, at 5:35 AM, Bruce Sherwood wrote:

> This is wonderful news, Arthur. Thank you!

Re: [Visualpython-users] Numpy compatibility

[Bruce S. <Bru...@nc...>]

This is wonderful news, Arthur. Thank you!

I am very far from an expert on autoconf, but I have worked with it some 
and can probably make the necessary changes next week, after sending the 
textbook revision to the publisher. I will of course need your changes.

I agree with your approach of not using the compatibility library. I 
think there are few existing programs that need to be changed (of the 
VPython example programs, maybe only gas and stars). I think I read that 
numpy offers a Python program that reads Python source and fixes it up. 
If so, we can advertise that utility to users.

Again, thanks so much on behalf of all the VPython community for 
stepping up the plate and hitting a home run when one was needed.

Bruce

Arthur wrote:
> Folks,
>
> I have now  - I believe - successfully implemented a VPython that is 
> compatible with the final 1.0 release of the numpy library.
>
> I have tried to do so touching as little of the existing code as 
> possible, hoping to avoid the possibility of inadvertently introducing 
> bugs into the code in this process. In fact the most radical surgery to 
> the existing code is a simplification - i.e. removing code and logic 
> that was there only to allow for the build against the *both* Numeric 
> and numarray libraries and the selection of one or the other as a 
> preference.  My code assumes a build against numpy, and only numpy.
>
> As hoped, there wasn't all that more that needed to be done to get the 
> basic compatibility issues resolved beyond what could be learned from 
> Phil Austin's approach in moving his num_util  helper functions for 
> boost::python::numeric arrays (used in the current vpython release) to 
> numpy compatibility.
>
> See.
>
> http://www.eos.ubc.ca/research/clouds/software/pythonlibs/num_util/num_util_release2/
>
> The only problems I have had running the demos and my own code that 
> utilizes vpython is in differences between the Numeric and numpy Python 
> APIs. For example numpy wants a lower case type identifier, e.g."float", 
> rather than as upper case "Float" when creating an array with a type 
> identifier.
>
> Numpy does have an "oldnumeric.py" library whose purpose - as the name 
> implies - is to add a compatibility layer between numpy and the older 
> numeric libraries at the Python coding level.. It is trivial to have 
> that library load as part of the start-up of vpython.  For my purposes, 
> I want to begin to understand the numpy library better, and having the 
> incompatibilities fall out is helpful, so I have not done so.  But Bruce 
> might want to include it in the vpython start-up routines, at least 
> during some transition period.
>
> What I have. *not* done is accomplish the changes to the build mechanism 
> that are necessary to detect the numpy library as part of the configure 
> routine and to create the proper Makefile or issue the appropriate 
> messages in case of its failure to do so.  I have simply been manually 
> editing the Makefile for the few changes necessary to build against numpy.
>
> My interest in learning more about the vpython, boost and numpy 
> internals, and get more hands on with C++ in general, made this little 
> numpy compatibility effort on my part something I enjoyed, being 
> compatible with my more general personal objectives.  Dealing with the 
> build issues would be less so.So I am hoping someone else will step up 
> to the plate.  OTOH, the necessary changes are probably not hard to 
> accomplish, and if no one else does, I will try to get to it.
>
> Bruce,
>
> What next?
>
> Art
>
>
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>   

[Visualpython-users] Numpy compatibility

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

Folks,

I have now  - I believe - successfully implemented a VPython that is 
compatible with the final 1.0 release of the numpy library.

I have tried to do so touching as little of the existing code as 
possible, hoping to avoid the possibility of inadvertently introducing 
bugs into the code in this process. In fact the most radical surgery to 
the existing code is a simplification - i.e. removing code and logic 
that was there only to allow for the build against the *both* Numeric 
and numarray libraries and the selection of one or the other as a 
preference.  My code assumes a build against numpy, and only numpy.

As hoped, there wasn't all that more that needed to be done to get the 
basic compatibility issues resolved beyond what could be learned from 
Phil Austin's approach in moving his num_util  helper functions for 
boost::python::numeric arrays (used in the current vpython release) to 
numpy compatibility.

See.

http://www.eos.ubc.ca/research/clouds/software/pythonlibs/num_util/num_util_release2/

The only problems I have had running the demos and my own code that 
utilizes vpython is in differences between the Numeric and numpy Python 
APIs. For example numpy wants a lower case type identifier, e.g."float", 
rather than as upper case "Float" when creating an array with a type 
identifier.

Numpy does have an "oldnumeric.py" library whose purpose - as the name 
implies - is to add a compatibility layer between numpy and the older 
numeric libraries at the Python coding level.. It is trivial to have 
that library load as part of the start-up of vpython.  For my purposes, 
I want to begin to understand the numpy library better, and having the 
incompatibilities fall out is helpful, so I have not done so.  But Bruce 
might want to include it in the vpython start-up routines, at least 
during some transition period.

What I have. *not* done is accomplish the changes to the build mechanism 
that are necessary to detect the numpy library as part of the configure 
routine and to create the proper Makefile or issue the appropriate 
messages in case of its failure to do so.  I have simply been manually 
editing the Makefile for the few changes necessary to build against numpy.

My interest in learning more about the vpython, boost and numpy 
internals, and get more hands on with C++ in general, made this little 
numpy compatibility effort on my part something I enjoyed, being 
compatible with my more general personal objectives.  Dealing with the 
build issues would be less so.So I am hoping someone else will step up 
to the plate.  OTOH, the necessary changes are probably not hard to 
accomplish, and if no one else does, I will try to get to it.

Bruce,

What next?

Art

Re: [Visualpython-users] Plugins for VPython

[Gary P. <gp...@ri...>]

On the other hand, some applications allow the launching of external apps.

I have included links in PowerPoint presentations that launch Vpython 
demos.
During the presentation one clicks on the link and python and the demo 
starts.
Works quite smoothly.  I can't remember the procedure, but searching the 
ppt
help for "launching external application" or something like that should 
produce
results.

I'd be very surprised if the equivalent functionality were not available 
in pdf documents and
OpenOffice.org documents.

-gary

Bruce Sherwood wrote:

>These seem to be Python questions and should be addressed to a Python 
>mailing list.
>
>If you really meant VPython, the answer is that no, a VPython program 
>won't run in a browser, nor can it be embedded in other applications.
>
>Bruce Sherwood
>
>Dr. Aly El-Iraki wrote:
>
>  
>
>>Hi
>> 
>>1. Is there an IE browser plug-in for Python?
>> 
>>2. Can Python files be embedded in Adobe Acrobat Professional, Adobe 
>>InDesign, Adobe Illustrator, Macromedia Flash, etc?
>> 
>>Thanks
>>Al
>>
>>------------------------------------------------------------------------
>>
>>-------------------------------------------------------------------------
>>Using Tomcat but need to do more? Need to support web services, security?
>>Get stuff done quickly with pre-integrated technology to make your job easier
>>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Visualpython-users mailing list
>>Vis...@li...
>>https://lists.sourceforge.net/lists/listinfo/visualpython-users
>> 
>>
>>    
>>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>  
>

Re: [Visualpython-users] Plugins for VPython

[Bruce S. <Bru...@nc...>]

These seem to be Python questions and should be addressed to a Python 
mailing list.

If you really meant VPython, the answer is that no, a VPython program 
won't run in a browser, nor can it be embedded in other applications.

Bruce Sherwood

Dr. Aly El-Iraki wrote:

> Hi
>  
> 1. Is there an IE browser plug-in for Python?
>  
> 2. Can Python files be embedded in Adobe Acrobat Professional, Adobe 
> InDesign, Adobe Illustrator, Macromedia Flash, etc?
>  
> Thanks
> Al
>
>------------------------------------------------------------------------
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users
>  
>

[Visualpython-users] Plugins for VPython

[Dr. A. El-I. <ira...@ho...>]

Hi

1. Is there an IE browser plug-in for Python?

2. Can Python files be embedded in Adobe Acrobat Professional, Adobe =
InDesign, Adobe Illustrator, Macromedia Flash, etc?

Thanks
Al

Re: [Visualpython-users] Python-2.3 version of the new beta version available somewhere?

[Bruce S. <Bru...@nc...>]

I doubt that anyone would make a beta version to run on Python 2.3, 
since that version of Python is now two levels out of date (the current 
version is Python 2.5). I can't think of any reason why one wouldn't 
upgrade to Python 2.5....?

Bruce Sherwood

Carl Dr. Kleffner wrote:

>Hi list,
>
>I hope someone has still compiled a winpy-2.3 vpython beta version. If then I appreciate if (s)he can send me the binaries.
>
>Regards
>
>Carl
>  
>

[Visualpython-users] Python-2.3 version of the new beta version available somewhere?

[Carl D. K. <cmk...@gm...>]

Hi list,

I hope someone has still compiled a winpy-2.3 vpython beta version. If then I appreciate if (s)he can send me the binaries.

Regards

Carl
-- 
GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist!
NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl

Re: [Visualpython-users] Numpy progress

[Bruce S. <Bru...@nc...>]

That's impressive progress, Art. Yes, by all means ruthlessly remove all 
references to the old machinery. Note that the current scheme of using 
either Numeric or numarray is broken. When Jonathan Brandmeyer first 
made it possible for Visual to use either one, I too tested the 
capability by installing only numarray and it worked except for some 
minor problems with slightly changed numeric syntax in some demo 
programs. Then I was surprised to find this capability does not work 
with recent versions, and I didn't try to find out why, because clearly 
no user of Visual noticed nor complained. I don't know how this 
capability got broken.

Bruce Sherwood

Arthur wrote:

>Hi folks -
>
>I had made some commitment to try to get to a vpython that integrates 
>with the numpy library accomplished.
>
>Was traveling last week and had the opportunity to spend some time with 
>it at lay-overs, etc.
>
>Long story short -
>
>I'm getting there - but in a round-about way, as I am not a C++ 
>programmer so there is a large learning curve for what would otherwise 
>be a small problem. Have a build that works for some demos but fails for 
>curves and convex objects. But I think I have a beat on the problem. The 
>fact is that the various numeric libraries are mostly compatible, and 
>there are only limited areas where code changes are needed (mostly 
>related to typing).  Just took me a while to get the lay of the land.
>
>The issue -
>
>The main thing that complicates following the current code is that it is 
>designed to accept  either the Numeric or Numarray libraries - on the 
>fly.  It also complicates the build process and makefiles,  the  Python 
>code for the  start-up of  vpython, etc.
> 
>My opinion is that we should bite the bullet and simplify -  and have 
>builds that do not try to be backward compatible with Numeric and/or 
>Numeric, and are tied only to numpy.
>
>Acceptable?
>
>Art
>
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users
>  
>