Making a long story as short as I can: Taking on the project of getting vpython to numpy compatibility (think I got there) brought me for the first time to a serious look at vpython 4.0 beta, which I had been avoiding, knowing it was buggy.
Bugs, aside - turns out it is a major step forward, implementing transparency, texturing, advanced lighting, among other cool features - including some undocumented features that are intended to make vpython accessible to other GUI toolkits (from what I gather). Anybody interested might run the texture_and_lighting.py demo to get a feel for some of the new capabilities. Very cool. The only deal killing bug seems to be the one related to mouse.getclick() crashes, on Windows. So I thought I'd have a look, getting quickly way over my C++ head, finding that a mouse click event involved code that included shared pointers, signals and slots, threads,and the direct manipulation of the Python GIL. Way over my C++ head. I tried to follow the code and on a gander decided to see what would happen if I cut out the direct Python gil manipulation, having some clue/instinct that there was some conflict between that and what the boost::shared_ptr library was doing in managing object life cycles. And with that one change (simple changing a call from "py_pop" to "pop" to short-circuit going into the gil code), the demo that was consistently crashing, the diople.py demo, now seems stable Which of course seems too good to be true, because presumably Jonathan Brandmeyer, the CS student author of this, had some specific reasons to be messing with the Python gil, and I don't know what I may be breaking, on what platforms, by my fix, if it is in fact a fix at all. Or else I'm a genius, or lucky, or something. Anybody willing to jump in here, to any extent, to have a look see? Art _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
