visualpython-users

Re: [Visualpython-users] Python Interpreter exits when Display window is closed

[Gerrat R. <gri...@co...>]

Got it!

I haven't completely read the docs - I've just started using VPython.
I ran the first example in the tutorial (
http://www.vpython.org/contents/docs/visual/VPython_Intro.pdf),
and was curious why the interpreter exited.

A slight tweak to the example now:

>>>from visual import *
>>>scene.exit = False
>>>sphere()

Now, when I close the display window, the python interpreter stays 
active.  This is all I wanted!  Solved.  Thanks!

Without the "scene.exit", the regular python command prompt exits, 
whereas VIDLE doesn't (well, it prints a message saying it has restarted,
but ends up leaving you in the interpreter).


On a related note (sort of), Christoph Gohlke emailed me back about 
the 64bit binary builds to say that he was aware they were missing
some of the modules like Polygon, Fonttools, and ttyfquery, and adding
them is on his todo list.  He said that VIDLE is already included.
There is a vidle directory in my installation - I just can't 
figure out how to invoke it correctly (There is no shortcut VIdle icon 
installed when I installed the 64bit python2.7 VPython binary).

I've tried:
"python run.py" (seems to do nothing)

and each of:
"python PYShell.py"
"python EditorWindow.py"
"python idle.py"
from the vidle directory all give me a similar traceback:

C:\Python27\Lib\site-packages\vidle>python idle.py
Traceback (most recent call last):
  File "idle.py", line 11, in <module>
    vidle.PyShell.main()
  File "C:\Python27\Lib\site-packages\vidle\PyShell.py", line 1463, in main
    flist.new()
  File "C:\Python27\Lib\site-packages\vidle\FileList.py", line 44, in new
    return self.EditorWindow(self, filename)
  File "C:\Python27\Lib\site-packages\vidle\PyShell.py", line 107, in __init__
    EditorWindow.__init__(self, *args)
  File "C:\Python27\Lib\site-packages\vidle\EditorWindow.py", line 306, in __init__
    self.askinteger = tkSimpleDialog.askinteger
AttributeError: 'module' object has no attribute 'askinteger'


Is there a way to invoke VIdle from the command prompt?


> -----Original Message-----
> From: Bruce Sherwood [mailto:Bru...@nc...]
> Sent: July 17, 2012 12:34 PM
> To: vis...@li...
> Subject: Re: [Visualpython-users] Python Interpreter exits when Display
> window is closed
> 
> Sorry, but I don't fully understand the situation. It is standard
> procedure for your program to quit if you close a VPython window. From
> the help:
> 
> exit If sceneb.exit is False, the program does not quit when the close
> box of the sceneb display is clicked. The default is sceneb.exit =
> True, in which case clicking the close box does make the program quit.
> 
> Can you give a bit more detail about what is different between IDLE and
> VIDLE? I wouldn't expect there to be any difference in this respect.
> 
> I will however mention the following: I very rarely run from the
> command prompt on Windows, but in recent days I have been doing so for
> testing purposes and I was surprised by the behavior of this simple
> program:
> 
> from vis import box
> box()
> 
> This program flashes a box and exits. If instead I say "from visual
> import *" the program behaves normally. That is, the window stays open
> and I can rotate and zoom. I don't know whether this unexpected
> behavior is related to the problem you see.
> 
> Bruce Sherwood
> 
> On Tue, Jul 17, 2012 at 7:54 AM, Gerrat Rickert
> <gri...@co...> wrote:
> > I have a bit more information on this.
> > I had a friend install the 64bit python3.2 VPython version, and, like
> > my 2.7 version, it did not include the Polygon, ttfquery, or
> FontTools module, or VIDLE.
> > It's odd that the python 3.1 version seems to have included these (as
> > Norm Derby tells you).
> > It appears that the 64bit binaries for VPython for both python 2.7
> and
> > 3.2 are doing what your 32bit version calls a "Compact" install vs. a
> full install.
> > I emailed Christoph Gohlke to ask if he'd consider changing to a
> 64bit
> > full install version (but as these are unofficial/unsupported, I'm
> not sure what to expect).
> >
> >
> > I still have a question for you though.  It appears that the 32bit
> > version of VPython exits the (regular, not VIDLE) interpreter as well
> > when the Display window is closed (so my original question has
> nothing to do with me using a 64bit version).
> > It looks like VIDLE somehow restarts itself when the display window
> is closed.
> > Is there a reason for this behaviour?
> > Is it possible to have the regular interpreter not exit just because
> > the display window is closed?
> >
> > Regards,
> >         Gerrat
> >
> >
> >> -----Original Message-----
> >> From: Bruce Sherwood [mailto:Bru...@nc...]
> >> Sent: July 16, 2012 6:16 PM
> >> To: vis...@li...
> >> Subject: Re: [Visualpython-users] Python Interpreter exits when
> >> Display window is closed
> >>
> >> Oh, now I see. I hadn't read your note sufficiently carefully, and I
> >> wasn't aware that someone had gone to the trouble of providing 64-
> bit
> >> builds of VPython for Windows, which is great. I should add to
> >> vpython.org a link to this work. Norm Derby tells me this:
> >>
> >> ----------------------------------------------
> >> The website referenced by Gerrat Rickert:
> >>
> >> http://www.lfd.uci.edu/~gohlke/pythonlibs/#vpython
> >>
> >> is maintained by Christoph Gohlke at UC-Irvine. It is wonderful. He
> >> has produced unofficial versions VPython for 64-bit Windows and LOTS
> >> of other Python programs that do not yet have official 64-bit
> >> versions. I have installed Python 3.1 64-bit and a VPython version
> >> that runs under it. Unlike Gerrat, my installation included Vidle
> and
> >> everything works like a charm.
> >> ------------------------------------------------
> >>
> >> There remains the question of why this works for Derby but not for
> >> you, and I have no idea.
> >>
> >> General comment: Note that these 64-bit versions are for Windows,
> not
> >> Mac. A 64-bit Mac version requires major restructuring of VPython to
> >> function in the Cocoa framework. As I indicated in an earlier note,
> >> I'm working on a possible solution to that problem.
> >>
> >> Bruce Sherwood
> >>
> >> On Mon, Jul 16, 2012 at 2:39 PM, Gerrat Rickert
> >> <gri...@co...> wrote:
> >> > In my question, I included the link where *unofficial* versions of
> >> many python 3rd party libraries have been compiled to 64bit.
> >> > ...and I mentioned that it was unofficial.
> >> > ...not sure why you think its a puzzle that anything works - this
> >> > is
> >> probably the first 64bit library on this site I've run into issues
> >> with (and exiting the interactive python interpreter when the
> display
> >> window is closed is mostly just an inconvenience).
> >> >
> >> > I know there is no official version, but like many with 64bit
> >> computers, I'd prefer to use 64bit programs.  I have over a dozen of
> >> other 64bit python 3rd party libs installed, and working correctly,
> >> downloaded from the page I linked to (...since there weren't any
> >> official 64bit versions of these either).
> >> >
> >> >
> >> > ...so reading into your "answer", I'll surmise that:
> >> > 1.  The 32bit version doesn't have this issue.
> >> > 2.  You don't know why it doesn't work for this unofficial 64bit
> >> version.
> >> >
> >> >
> >> > Thanks for your time.
> >
> > [...remainder elided]
> 
> -----------------------------------------------------------------------
> -------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond.
> Discussions will include endpoint security, mobile security and the
> latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Python Interpreter exits when Display window is closed

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

Sorry, but I don't fully understand the situation. It is standard
procedure for your program to quit if you close a VPython window. From
the help:

exit If sceneb.exit is False, the program does not quit when the close
box of the sceneb display is clicked. The default is sceneb.exit =
True, in which case clicking the close box does make the program quit.

Can you give a bit more detail about what is different between IDLE
and VIDLE? I wouldn't expect there to be any difference in this
respect.

I will however mention the following: I very rarely run from the
command prompt on Windows, but in recent days I have been doing so for
testing purposes and I was surprised by the behavior of this simple
program:

from vis import box
box()

This program flashes a box and exits. If instead I say "from visual
import *" the program behaves normally. That is, the window stays open
and I can rotate and zoom. I don't know whether this unexpected
behavior is related to the problem you see.

Bruce Sherwood

On Tue, Jul 17, 2012 at 7:54 AM, Gerrat Rickert
<gri...@co...> wrote:
> I have a bit more information on this.
> I had a friend install the 64bit python3.2 VPython version, and, like my 2.7 version,
> it did not include the Polygon, ttfquery, or FontTools module, or VIDLE.
> It's odd that the python 3.1 version seems to have included these (as Norm
> Derby tells you).
> It appears that the 64bit binaries for VPython for both python 2.7 and 3.2
> are doing what your 32bit version calls a "Compact" install vs. a full install.
> I emailed Christoph Gohlke to ask if he'd consider changing to a 64bit full install
> version (but as these are unofficial/unsupported, I'm not sure what to expect).
>
>
> I still have a question for you though.  It appears that the 32bit version of
> VPython exits the (regular, not VIDLE) interpreter as well when the Display
> window is closed (so my original question has nothing to do with me using a 64bit version).
> It looks like VIDLE somehow restarts itself when the display window is closed.
> Is there a reason for this behaviour?
> Is it possible to have the regular interpreter not exit just because the display
> window is closed?
>
> Regards,
>         Gerrat
>
>
>> -----Original Message-----
>> From: Bruce Sherwood [mailto:Bru...@nc...]
>> Sent: July 16, 2012 6:16 PM
>> To: vis...@li...
>> Subject: Re: [Visualpython-users] Python Interpreter exits when Display
>> window is closed
>>
>> Oh, now I see. I hadn't read your note sufficiently carefully, and I
>> wasn't aware that someone had gone to the trouble of providing 64-bit
>> builds of VPython for Windows, which is great. I should add to
>> vpython.org a link to this work. Norm Derby tells me this:
>>
>> ----------------------------------------------
>> The website referenced by Gerrat Rickert:
>>
>> http://www.lfd.uci.edu/~gohlke/pythonlibs/#vpython
>>
>> is maintained by Christoph Gohlke at UC-Irvine. It is wonderful. He has
>> produced unofficial versions VPython for 64-bit Windows and LOTS of
>> other Python programs that do not yet have official 64-bit versions. I
>> have installed Python 3.1 64-bit and a VPython version that runs under
>> it. Unlike Gerrat, my installation included Vidle and everything works
>> like a charm.
>> ------------------------------------------------
>>
>> There remains the question of why this works for Derby but not for you,
>> and I have no idea.
>>
>> General comment: Note that these 64-bit versions are for Windows, not
>> Mac. A 64-bit Mac version requires major restructuring of VPython to
>> function in the Cocoa framework. As I indicated in an earlier note, I'm
>> working on a possible solution to that problem.
>>
>> Bruce Sherwood
>>
>> On Mon, Jul 16, 2012 at 2:39 PM, Gerrat Rickert
>> <gri...@co...> wrote:
>> > In my question, I included the link where *unofficial* versions of
>> many python 3rd party libraries have been compiled to 64bit.
>> > ...and I mentioned that it was unofficial.
>> > ...not sure why you think its a puzzle that anything works - this is
>> probably the first 64bit library on this site I've run into issues with
>> (and exiting the interactive python interpreter when the display window
>> is closed is mostly just an inconvenience).
>> >
>> > I know there is no official version, but like many with 64bit
>> computers, I'd prefer to use 64bit programs.  I have over a dozen of
>> other 64bit python 3rd party libs installed, and working correctly,
>> downloaded from the page I linked to (...since there weren't any
>> official 64bit versions of these either).
>> >
>> >
>> > ...so reading into your "answer", I'll surmise that:
>> > 1.  The 32bit version doesn't have this issue.
>> > 2.  You don't know why it doesn't work for this unofficial 64bit
>> version.
>> >
>> >
>> > Thanks for your time.
>
> [...remainder elided]

Re: [Visualpython-users] Python Interpreter exits when Display window is closed

[Gerrat R. <gri...@co...>]

I have a bit more information on this.  
I had a friend install the 64bit python3.2 VPython version, and, like my 2.7 version, 
it did not include the Polygon, ttfquery, or FontTools module, or VIDLE.
It's odd that the python 3.1 version seems to have included these (as Norm 
Derby tells you).
It appears that the 64bit binaries for VPython for both python 2.7 and 3.2
are doing what your 32bit version calls a "Compact" install vs. a full install.
I emailed Christoph Gohlke to ask if he'd consider changing to a 64bit full install
version (but as these are unofficial/unsupported, I'm not sure what to expect).  


I still have a question for you though.  It appears that the 32bit version of
VPython exits the (regular, not VIDLE) interpreter as well when the Display 
window is closed (so my original question has nothing to do with me using a 64bit version).  
It looks like VIDLE somehow restarts itself when the display window is closed.
Is there a reason for this behaviour?
Is it possible to have the regular interpreter not exit just because the display
window is closed?

Regards,
	Gerrat


> -----Original Message-----
> From: Bruce Sherwood [mailto:Bru...@nc...]
> Sent: July 16, 2012 6:16 PM
> To: vis...@li...
> Subject: Re: [Visualpython-users] Python Interpreter exits when Display
> window is closed
> 
> Oh, now I see. I hadn't read your note sufficiently carefully, and I
> wasn't aware that someone had gone to the trouble of providing 64-bit
> builds of VPython for Windows, which is great. I should add to
> vpython.org a link to this work. Norm Derby tells me this:
> 
> ----------------------------------------------
> The website referenced by Gerrat Rickert:
> 
> http://www.lfd.uci.edu/~gohlke/pythonlibs/#vpython
> 
> is maintained by Christoph Gohlke at UC-Irvine. It is wonderful. He has
> produced unofficial versions VPython for 64-bit Windows and LOTS of
> other Python programs that do not yet have official 64-bit versions. I
> have installed Python 3.1 64-bit and a VPython version that runs under
> it. Unlike Gerrat, my installation included Vidle and everything works
> like a charm.
> ------------------------------------------------
> 
> There remains the question of why this works for Derby but not for you,
> and I have no idea.
> 
> General comment: Note that these 64-bit versions are for Windows, not
> Mac. A 64-bit Mac version requires major restructuring of VPython to
> function in the Cocoa framework. As I indicated in an earlier note, I'm
> working on a possible solution to that problem.
> 
> Bruce Sherwood
> 
> On Mon, Jul 16, 2012 at 2:39 PM, Gerrat Rickert
> <gri...@co...> wrote:
> > In my question, I included the link where *unofficial* versions of
> many python 3rd party libraries have been compiled to 64bit.
> > ...and I mentioned that it was unofficial.
> > ...not sure why you think its a puzzle that anything works - this is
> probably the first 64bit library on this site I've run into issues with
> (and exiting the interactive python interpreter when the display window
> is closed is mostly just an inconvenience).
> >
> > I know there is no official version, but like many with 64bit
> computers, I'd prefer to use 64bit programs.  I have over a dozen of
> other 64bit python 3rd party libs installed, and working correctly,
> downloaded from the page I linked to (...since there weren't any
> official 64bit versions of these either).
> >
> >
> > ...so reading into your "answer", I'll surmise that:
> > 1.  The 32bit version doesn't have this issue.
> > 2.  You don't know why it doesn't work for this unofficial 64bit
> version.
> >
> >
> > Thanks for your time.

[...remainder elided]

Re: [Visualpython-users] Python Interpreter exits when Display window is closed

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

The Windows download page at vpython.org now has a link to Christoph
Gohlke's 64-bit versions of VPython.

Bruce Sherwood

Re: [Visualpython-users] Python Interpreter exits when Display window is closed

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

Oh, now I see. I hadn't read your note sufficiently carefully, and I
wasn't aware that someone had gone to the trouble of providing 64-bit
builds of VPython for Windows, which is great. I should add to
vpython.org a link to this work. Norm Derby tells me this:

----------------------------------------------
The website referenced by Gerrat Rickert:

http://www.lfd.uci.edu/~gohlke/pythonlibs/#vpython

is maintained by Christoph Gohlke at UC-Irvine. It is wonderful. He
has produced unofficial versions VPython for 64-bit Windows and LOTS
of other Python programs that do not yet have official 64-bit
versions. I have installed Python 3.1 64-bit and a VPython version
that runs under it. Unlike Gerrat, my installation included Vidle and
everything works like a charm.
------------------------------------------------

There remains the question of why this works for Derby but not for
you, and I have no idea.

General comment: Note that these 64-bit versions are for Windows, not
Mac. A 64-bit Mac version requires major restructuring of VPython to
function in the Cocoa framework. As I indicated in an earlier note,
I'm working on a possible solution to that problem.

Bruce Sherwood

On Mon, Jul 16, 2012 at 2:39 PM, Gerrat Rickert
<gri...@co...> wrote:
> In my question, I included the link where *unofficial* versions of many python 3rd party libraries have been compiled to 64bit.
> ...and I mentioned that it was unofficial.
> ...not sure why you think its a puzzle that anything works - this is probably the first 64bit library on this site I've run into issues with (and exiting the interactive python interpreter when the display window is closed is mostly just an inconvenience).
>
> I know there is no official version, but like many with 64bit computers, I'd prefer to use 64bit programs.  I have over a dozen of other 64bit python 3rd party libs installed, and working correctly, downloaded from the page I linked to (...since there weren't any official 64bit versions of these either).
>
>
> ...so reading into your "answer", I'll surmise that:
> 1.  The 32bit version doesn't have this issue.
> 2.  You don't know why it doesn't work for this unofficial 64bit version.
>
>
> Thanks for your time.
>
>
>> -----Original Message-----
>> From: Bruce Sherwood [mailto:Bru...@nc...]
>> Sent: July 16, 2012 4:18 PM
>> To: vis...@li...
>> Subject: Re: [Visualpython-users] Python Interpreter exits when Display
>> window is closed
>>
>> The deep puzzle is why anything works at all, as there isn't a version
>> of VPython that has been built for Windows 64-bit Python. Here are the
>> instructions on the Windows download page at vpython.org:
>>
>> First, download and install Python-2.7.2 (Important: Let it install in
>> C:\Python27)
>> (There is not a VPython version for Windows 64-bit Python, but this 32-
>> bit version of Python works fine on 64-bit Windows machines) Second,
>> download and install VPython-Win-Py2.7-5.74
>>
>> Bruce Sherwood
>>
>> On Mon, Jul 16, 2012 at 12:39 PM, Gerrat Rickert
>> <gri...@co...> wrote:
>> > I’m running the 64-bit version of VPython 5.72
>> > (http://www.lfd.uci.edu/~gohlke/pythonlibs/#vpython), on Windows 7,
>> > with a normal, 64bit python 2.7.2 interpreter (not Vidle).
>> >
>> > I realize this isn’t an “official” version of VPython, but seems to
>> > work otherwise.
>> >
>> >
>> >
>> > From the interactive python prompt, with a simple program like:
>> >
>> > from visual import *
>> >
>> > sphere()
>> >
>> >
>> >
>> > It displays the sphere, but when I close the Display window, the
>> > python interpreter itself exits.
>> >
>> > Is there a way to prevent this?
>> >
>> >
>> >
>> > ...I can’t seem to use Vidle, if that’s the solution...either the
>> > 64bit version doesn’t install it correctly, or I’m not invoking it
>> > correctly (there is no desktop shortcut, and when I run idle.bat from
>> > the command line I get a “Windows cannot find ‘idle.pyw’.  Make sure
>> > you typed the name correctly, and then try again”.)  There is a file,
>> > idle.pyw in the vidle directory, so I’m not sure why it can’t find
>> it.
>> >
>> >
>> >
>> > Thanks for any assistance,
>> >
>> > Gerrat
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> -
>> > --------
>> > Live Security Virtual Conference
>> > Exclusive live event will cover all the ways today's security and
>> > threat landscape has changed and how IT managers can respond.
>> > Discussions will include endpoint security, mobile security and the
>> > latest in malware threats.
>> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> > _______________________________________________
>> > Visualpython-users mailing list
>> > Vis...@li...
>> > https://lists.sourceforge.net/lists/listinfo/visualpython-users
>> >
>>
>> -----------------------------------------------------------------------
>> -------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond.
>> Discussions will include endpoint security, mobile security and the
>> latest in malware threats.
>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Python Interpreter exits when Display window is closed

[Gerrat R. <gri...@co...>]

In my question, I included the link where *unofficial* versions of many python 3rd party libraries have been compiled to 64bit.
...and I mentioned that it was unofficial.  
...not sure why you think its a puzzle that anything works - this is probably the first 64bit library on this site I've run into issues with (and exiting the interactive python interpreter when the display window is closed is mostly just an inconvenience).

I know there is no official version, but like many with 64bit computers, I'd prefer to use 64bit programs.  I have over a dozen of other 64bit python 3rd party libs installed, and working correctly, downloaded from the page I linked to (...since there weren't any official 64bit versions of these either).


...so reading into your "answer", I'll surmise that:
1.  The 32bit version doesn't have this issue.
2.  You don't know why it doesn't work for this unofficial 64bit version.


Thanks for your time.


> -----Original Message-----
> From: Bruce Sherwood [mailto:Bru...@nc...]
> Sent: July 16, 2012 4:18 PM
> To: vis...@li...
> Subject: Re: [Visualpython-users] Python Interpreter exits when Display
> window is closed
> 
> The deep puzzle is why anything works at all, as there isn't a version
> of VPython that has been built for Windows 64-bit Python. Here are the
> instructions on the Windows download page at vpython.org:
> 
> First, download and install Python-2.7.2 (Important: Let it install in
> C:\Python27)
> (There is not a VPython version for Windows 64-bit Python, but this 32-
> bit version of Python works fine on 64-bit Windows machines) Second,
> download and install VPython-Win-Py2.7-5.74
> 
> Bruce Sherwood
> 
> On Mon, Jul 16, 2012 at 12:39 PM, Gerrat Rickert
> <gri...@co...> wrote:
> > I’m running the 64-bit version of VPython 5.72
> > (http://www.lfd.uci.edu/~gohlke/pythonlibs/#vpython), on Windows 7,
> > with a normal, 64bit python 2.7.2 interpreter (not Vidle).
> >
> > I realize this isn’t an “official” version of VPython, but seems to
> > work otherwise.
> >
> >
> >
> > From the interactive python prompt, with a simple program like:
> >
> > from visual import *
> >
> > sphere()
> >
> >
> >
> > It displays the sphere, but when I close the Display window, the
> > python interpreter itself exits.
> >
> > Is there a way to prevent this?
> >
> >
> >
> > ...I can’t seem to use Vidle, if that’s the solution...either the
> > 64bit version doesn’t install it correctly, or I’m not invoking it
> > correctly (there is no desktop shortcut, and when I run idle.bat from
> > the command line I get a “Windows cannot find ‘idle.pyw’.  Make sure
> > you typed the name correctly, and then try again”.)  There is a file,
> > idle.pyw in the vidle directory, so I’m not sure why it can’t find
> it.
> >
> >
> >
> > Thanks for any assistance,
> >
> > Gerrat
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> -
> > --------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions will include endpoint security, mobile security and the
> > latest in malware threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Visualpython-users mailing list
> > Vis...@li...
> > https://lists.sourceforge.net/lists/listinfo/visualpython-users
> >
> 
> -----------------------------------------------------------------------
> -------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond.
> Discussions will include endpoint security, mobile security and the
> latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Python Interpreter exits when Display window is closed

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

The deep puzzle is why anything works at all, as there isn't a version
of VPython that has been built for Windows 64-bit Python. Here are the
instructions on the Windows download page at vpython.org:

First, download and install Python-2.7.2 (Important: Let it install in
C:\Python27)
(There is not a VPython version for Windows 64-bit Python, but this
32-bit version of Python works fine on 64-bit Windows machines)
Second, download and install VPython-Win-Py2.7-5.74

Bruce Sherwood

On Mon, Jul 16, 2012 at 12:39 PM, Gerrat Rickert
<gri...@co...> wrote:
> I’m running the 64-bit version of VPython 5.72
> (http://www.lfd.uci.edu/~gohlke/pythonlibs/#vpython), on Windows 7, with a
> normal, 64bit python 2.7.2 interpreter (not Vidle).
>
> I realize this isn’t an “official” version of VPython, but seems to work
> otherwise.
>
>
>
> From the interactive python prompt, with a simple program like:
>
> from visual import *
>
> sphere()
>
>
>
> It displays the sphere, but when I close the Display window, the python
> interpreter itself exits.
>
> Is there a way to prevent this?
>
>
>
> ...I can’t seem to use Vidle, if that’s the solution...either the 64bit
> version doesn’t install it correctly, or I’m not invoking it correctly
> (there is no desktop shortcut, and when I run idle.bat from the command line
> I get a “Windows cannot find ‘idle.pyw’.  Make sure you typed the name
> correctly, and then try again”.)  There is a file, idle.pyw in the vidle
> directory, so I’m not sure why it can’t find it.
>
>
>
> Thanks for any assistance,
>
> Gerrat
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

[Visualpython-users] Python Interpreter exits when Display window is closed

[Gerrat R. <gri...@co...>]

I'm running the 64-bit version of VPython 5.72  (http://www.lfd.uci.edu/~gohlke/pythonlibs/#vpython), on Windows 7, with a normal, 64bit python 2.7.2 interpreter (not Vidle).
I realize this isn't an "official" version of VPython, but seems to work otherwise.

>From the interactive python prompt, with a simple program like:
from visual import *
sphere()

It displays the sphere, but when I close the Display window, the python interpreter itself exits.
Is there a way to prevent this?

...I can't seem to use Vidle, if that's the solution...either the 64bit version doesn't install it correctly, or I'm not invoking it correctly (there is no desktop shortcut, and when I run idle.bat from the command line I get a "Windows cannot find 'idle.pyw'.  Make sure you typed the name correctly, and then try again".)  There is a file, idle.pyw in the vidle directory, so I'm not sure why it can't find it.

Thanks for any assistance,
Gerrat

Re: [Visualpython-users] VPython for Graph Visualization

[C A. R. <an...@xt...>]

On Tue, Jul 10, 2012 at 4:29 PM, Mark Adam <dre...@gm...> wrote:
>
> I'm wondering if there's been anyone who's explored using the 3-d
> visualization extension of python for graph visualization?

ha, well, i'm actually giving a short presentation/demo of exactly
this at work tomorrow for ~40 or so other developers, and, in
retrospect ... all of you ;-)

i can't really share the code ATM (it belongs to me but currently
integrates with the production AMQP network, etc) but i do intend on
releasing at a later time.

tbh, it really is just a demo at this point, but still rather
impressive (many oohs and ahhs) considering a SLOC barely over 200 --
strongly hinting at vpython's power-thru-simplicity model.

the talk itself focuses on the natural intuitions behind generic 3D
interfaces, and self-organizing, real[ish]-time visualizations (sadly,
for both, sans some sweet HID equip + libs needed to move from dream
-> reality -- eg. Xbox Kinect sensors4all -- kbds and mice are
OBSOLETE! yuck! :-)

SOURCE: application binds to message queue, subscribing to real-time
phone-state queues (emitted by ~400 CSR agents in another facility,
across the country [US]). these are nothing more than (time, agent,
state); other properties are available but unused.

INTERFACE: outside "observers" (ie. users) may navigate this universe:
 - free-space navigation
 - click-to-mount camera (to an arbitrary sphere)
... or influence fundamental constants/properties as deemed useful:
 - gravity
 - intial vector
 - intial vector magnitude
 - various constants like growth/etc
... modifying the output + user perception/experience stream, and
[potentially] surface new insights. introspection/aggregation
[stats/avg/etc] on individual agents and/or logical groupings
contribute usefulness as a human interface (think current-get FPS
games, and the massive information I/O densities in effect).

SELF-ORGANIZING: to complement humans already superb pattern matching
abilities, the visualizer renders agents as simple, colored spheres
orbiting a gravity-well anchored to origin. state change == color
change. agents grow at a continuous pace while idling in one state;
any transition resets the radius back to 1. from just these basic
"truths", patterns emerge like:
 - "seems like ~40% in idle at any given time"
 - "why are so many busy/unavailable [red]?"
 - "why agent XYZ in red [busy], and 3x larger?"
 - "technical problem? everyone just went IDLE"
... what's truly incredible is the fact that near *everyone*
interprets the output similarly, by virtue of a shared experience,
that of life (another variant employs magnetic-like interactions
between agents)

[1/2] tl;dr, physics fits really well in this domain! it's something
we've practice, without choice, since day 1, and are pretty well
disciplined by now :-)

quick aside: at a previous company, we ran gltail [
http://www.fudgie.org/ ] all day, every day, and i can't even begin to
tell you how many times network or completely unrelated *problems*
were spotted by my peers throughout the office -- read: very
NON-TECHIE folk! -- on numerous occasion. often, IMO, the anomalies
were often subtle -- far from approaching boundary alarms a la
Nagios/Cactus/whatever, but still with [complex] negative implications
if left unbound -- these people simply noticed "the blobber feels
off/out-of-sync today".  it was phenomenal ... inspiring continued
interest, and soon after, leading me to [v]python :-)

moving along ... the impl is not too crazy-fancy, but worthy of
mention.  i run the vpython bits under uWSGI
[http://projects.unbit.it/uwsgi/ : absolutely fabulous, check it out]
within an offloaded/independent "--mule" process, avoiding detrimental
conflict with HTTP/WSGI request/response cycles. this is critical, and
allows painless interaction with the vpython/visualizer loop, from the
outside, via any one of the umpteen uWSGI methods. a single FX class
manages transitions thru staticmethod(generator) members.  each agent
sphere carries an "FXQ" [effects queue], filled with LIVE,
instantiated generators.  during each cycle/iteration/Hz, i simply
call next(generator) on each generator, in each queue, thereby
advancing the entire system one unit-over-Hz. FX behave asynchronously
(thx to generator-awesome-ness) and perform everything from applying
gravity -> velocity -> new_pos all the way to managing the camera
updates, timeouts, etc. etc. when a generator expires (raises
StopIteration), it's removed from it's respective FXQ.

the FXQ model its immensely simple, but i suspect not all that
efficient or scalable; better would be some
generic-as-possible-low-level-transform-engine parallelizing some
relationships, eg. via matrices or other transforms ... sadly, despite
insatiable fervor for mathematics and physics, i get paid to architect
web/system/business applications, my computational physics skills
surely suck ... pointer very much welcomed!

... hopefully you found what became a short story either interestingly
entertaining or entertainingly interesting, because The End, is ...
NOW!

* tune in next week for the shocking conclusion! *

-- 

C Anthony

[Visualpython-users] VPython for Graph Visualization

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

I asked a colleague who might possibly have done some graph
visualization using VPython, and here is what he said:

I haven't really done anything along those lines, although it would be
quite straightforward in principle to do Kamada-Kawai or something
similar.  Attached is a simple program from my undergrad class to do
simulated annealing on the traveling salesman problem, which shows how
one could visualize a graph or network.

> From: Mark Adam <dre...@gm...>
> Date: Tue, Jul 10, 2012 at 3:29 PM
> Subject: [Visualpython-users] VPython for Graph Visualization
> To: net...@go...
> Cc: vis...@li...
>
>
> I'm wondering if there's been anyone who's explored using the 3-d
> visualization extension of python for graph visualization?
>
> Cheers,
>
> mark
> pangaia.sf.net
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

[Visualpython-users] VPython for Graph Visualization

[Mark A. <dre...@gm...>]

I'm wondering if there's been anyone who's explored using the 3-d
visualization extension of python for graph visualization?

Cheers,

mark
pangaia.sf.net

Re: [Visualpython-users] Help needed with 'import visual' error

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

You need to follow the instructions on the Windows download page at vpython.org:

First, download and install Python-2.7.2 (Important: Let it install in
C:\Python27)
(There is not a VPython version for Windows 64-bit Python, but this
32-bit version of Python works fine on 64-bit Windows machines)
Second, download and install VPython-Win-Py2.7-5.74

On Thu, Jul 5, 2012 at 2:02 AM, Osemeka Osuagwu <aba...@gm...> wrote:
> Hi,
> I came across VPython for the first time, yesterday. I installed it and
> tried to run some code but my import statement kept causing an error as
> follows:
>
> Code:
> import visual
>
> Error:
> Traceback (most recent call last):
>   File "Untitled", line 2
>     import visual
>   File "C:\Python27\lib\site-packages\visual\__init__.py", line 1
>     from .visual_all import *
>   File "C:\Python27\lib\site-packages\visual\visual_all.py", line 1
>     from vis import version
>   File "C:\Python27\lib\site-packages\vis\__init__.py", line 3
>     from .cvisual import (vector, dot, mag, mag2, norm, cross, rotate,
> ImportError: DLL load failed: %1 is not a valid Win32 application.
>
> How can I deal with this, please?
> I use Windows7 64bit with Python ver2.7.
> I installed VPython in my C:\Python27 directory
>
> Thanks,
> Abasiemeka

[Visualpython-users] Help needed with 'import visual' error

[Osemeka O. <aba...@gm...>]

*Hi,*
*I came across VPython for the first time, yesterday. I installed it and
tried to run some code but my import statement kept causing an error as
follows:*
*
*
*Code:*
import visual

*Error:*
Traceback (most recent call last):
  File "Untitled", line 2
    import visual
  File "C:\Python27\lib\site-packages\visual\__init__.py", line 1
    from .visual_all import *
  File "C:\Python27\lib\site-packages\visual\visual_all.py", line 1
    from vis import version
  File "C:\Python27\lib\site-packages\vis\__init__.py", line 3
    from .cvisual import (vector, dot, mag, mag2, norm, cross, rotate,
ImportError: DLL load failed: %1 is not a valid Win32 application.

*How can I deal with this, please?*
*I use Windows7 64bit with Python ver2.7.*
*I installed VPython in my C:\Python27 directory*
*
*
*Thanks,*
*Abasiemeka*

Re: [Visualpython-users] vPython

[Jose R. <on...@gm...>]

I think there is no windows 64x  version of vPython.  I installed pythonxy
which is 32 bit and gets you a running version of vPython.

Jose



On Jul 2, 2012, at 6:21 PM, Frank Drown <fdr...@gm...> wrote:

I have installed Python v2.7.3 64bit with wxPython v2.8 64 bit.

Python is installed in the default directory c:\python27

I installed vPython for Python 2.7 using installation defaults.

When I run vPython with the desktop icon, the Python Shell starts and
nothing else.

What have I done wrong and what do I need to do to get vPython to run?

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
Visualpython-users mailing list
Vis...@li...
https://lists.sourceforge.net/lists/listinfo/visualpython-users

[Visualpython-users] vPython

[Frank D. <fdr...@gm...>]

I have installed Python v2.7.3 64bit with wxPython v2.8 64 bit.

Python is installed in the default directory c:\python27

I installed vPython for Python 2.7 using installation defaults.

When I run vPython with the desktop icon, the Python Shell starts and
nothing else.

What have I done wrong and what do I need to do to get vPython to run?

Re: [Visualpython-users] gtk embedding.

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

I don't really follow the details of this, but it doesn't sound like a
good candidate for the standard version of VPython because it is
apparently GTK-specific, and VPython attempts to be
platform-independent.

I'm currently studying how it might be possible to base VPython on
wxPython, in which case the OpenGL canvas could be part of a window,
with cross-platform support for menus etc. My immediate concern is, as
I've commented before, to be able to run VPython on a 64-bit Python on
the Mac, based on Cocoa. On the wxpython-users list, wxPython experts
have been very helpful in my quest, including making a suggestion on
how to get around the very serious problem that the Cocoa interact
loop must be in the primary thread, the roadblock that David Scherer
and I were unable to get around when we tried in 2008.

Bruce Sherwood

On Fri, Jun 29, 2012 at 9:43 AM, Yann Golanski <ygo...@is...> wrote:
> A bug has risen from the embedding code I send earlier.  The code works
> fine under the fvwm2 window manager but not under Gnome.  It appears
> that Gnome is more picky with GTK.  This result in any embedding command
> destroying the VPythong window instead of embedding it.
>
> Basically, to embed a GTK window into another one, you need to have a
> pair of Gtk::Plug and Gtk::Socket.  The child process (VPython in this
> case) creates a plug and exposes the plug ID.  The programme that
> will embed VPython uses this plug ID as a parameter to its Gtk::Socket
> and thus can embed the plug.
>
> So, would it be possible to have a gtk::Plug() object within main_gui()
> and a method that would return the Plug ID?  Ideally, this would be
> wrapped within a Python call so that I could do something akin to:
>
>    display.get_selected()
>    plug_id = display.get_gtk_plug_id()
>
> Would it be okay if this became a feature request?
>
> --
> GPG Fingerprint 8666 7F9A 17E7 AC8E CC36  1D1E C707 D658 6685 2528
>   The views expressed in this e-mail may or may not reflect those of the
>   author and do not necessarily reflect those of Isotek Oil and Gas Ltd.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] gtk embedding.

[Yann G. <ygo...@is...>]

A bug has risen from the embedding code I send earlier.  The code works
fine under the fvwm2 window manager but not under Gnome.  It appears
that Gnome is more picky with GTK.  This result in any embedding command
destroying the VPythong window instead of embedding it.  

Basically, to embed a GTK window into another one, you need to have a
pair of Gtk::Plug and Gtk::Socket.  The child process (VPython in this
case) creates a plug and exposes the plug ID.  The programme that
will embed VPython uses this plug ID as a parameter to its Gtk::Socket
and thus can embed the plug. 

So, would it be possible to have a gtk::Plug() object within main_gui()
and a method that would return the Plug ID?  Ideally, this would be
wrapped within a Python call so that I could do something akin to:

    display.get_selected() 
    plug_id = display.get_gtk_plug_id()

Would it be okay if this became a feature request? 

-- 
GPG Fingerprint 8666 7F9A 17E7 AC8E CC36  1D1E C707 D658 6685 2528
   The views expressed in this e-mail may or may not reflect those of the
   author and do not necessarily reflect those of Isotek Oil and Gas Ltd.

Re: [Visualpython-users] Future = (Vpython + Glowscript) | Glowscript | ???

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

I certainly welcome any and all suggestions for the appropriate
framework for VPython+. As attractive as the promise of pypy is, it
sounds to me like it's not a sufficiently mature platform on which to
base a first try at VPython+.

Bruce

On Tue, Jun 12, 2012 at 4:20 PM, John Zelle <joh...@wa...> wrote:
> Let me just second that pypy is definitely worth looking at. For programs that have one main loop with many independent (random?) calculations, pypy can provide much more speedup. I've gotten over 100 fold speedup in some cases (yes that's 100 fold, not 100%). Pypy makes it possible to do things like real-time image manipulation or ray-tracing in pure Python code. At least on Linux (see below).
>
> Since pypy is compatible with ctypes, it would be possible to combine it with something like pyglet for a cross-platform, pure Python, VPython+ that relies on a modern graphics card for the heavy lifting on the graphics side. However, pypy does have a couple downsides:
>
> 1) it's Python 2.7, not 3.x
> 2) I'm not sure what the status of the JIT compiler is for non-linux platforms. I think they are working on this.
> 3) Numpy support is experimental/in-development at this point.
>
> If I had the time, which I don't, I would definitely be interested in working on a pure Python reimplementation of VPython along these lines.
>
> John Zelle, PhD
> Professor of Computer Science
> Wartburg College
>
>
> ________________________________________
> From: C Anthony Risinger [an...@xt...]
> Sent: Tuesday, June 12, 2012 12:56 PM
> To: Bru...@nc...
> Cc: vis...@li...
> Subject: Re: [Visualpython-users] Future = (Vpython + Glowscript) | Glowscript | ???
>
> On Sat, Jun 9, 2012 at 10:14 AM, Bruce Sherwood <Bru...@nc...> wrote:
>> Very interesting. There is much in your message about which I have no
>> knowledge and no opinion. However, I can make some comments about the
>> Big Picture.
>>
>> For a variety of reasons, I am personally committed to the further
>> development and maintenance of both VPython and GlowScript.
>
> ok, good news :-)
>
>> [...]
>>
>> As I've said, I'm dreaming of constructing a VPython+ that would
>> require a modern graphics card. If possible, I'd like to build it on
>> top of one of the newer Python frameworks that work cross-platform, in
>> particular to solve the menacing problem that Carbon on the Mac is not
>> available for 64-bit Python.
>
> out of curiosity, which frameworks are you considering/referencing?
>
>> [...]
>>
>> I wasn't aware of the pypy.org project, and certainly running 5 times
>> faster than CPython is important. What is "co", which you mention?
>
> oh sorry, i just meant "and company", ie. pypy and all it's
> dependencies, along with whatever other considerations are needed.
> pypy is pretty incredible, and IMO, is the future of Python, and
> possible other dynamic langs like Ruby et al.
>
> thanks for your comments Bruce; i will note the vitality of both
> projects during my demonstration.
>
> --
>
> C Anthony

Re: [Visualpython-users] Future = (Vpython + Glowscript) | Glowscript | ???

[John Z. <joh...@wa...>]

Let me just second that pypy is definitely worth looking at. For programs that have one main loop with many independent (random?) calculations, pypy can provide much more speedup. I've gotten over 100 fold speedup in some cases (yes that's 100 fold, not 100%). Pypy makes it possible to do things like real-time image manipulation or ray-tracing in pure Python code. At least on Linux (see below).

Since pypy is compatible with ctypes, it would be possible to combine it with something like pyglet for a cross-platform, pure Python, VPython+ that relies on a modern graphics card for the heavy lifting on the graphics side. However, pypy does have a couple downsides:

1) it's Python 2.7, not 3.x
2) I'm not sure what the status of the JIT compiler is for non-linux platforms. I think they are working on this. 
3) Numpy support is experimental/in-development at this point.

If I had the time, which I don't, I would definitely be interested in working on a pure Python reimplementation of VPython along these lines.

John Zelle, PhD
Professor of Computer Science
Wartburg College


________________________________________
From: C Anthony Risinger [an...@xt...]
Sent: Tuesday, June 12, 2012 12:56 PM
To: Bru...@nc...
Cc: vis...@li...
Subject: Re: [Visualpython-users] Future = (Vpython + Glowscript) | Glowscript | ???

On Sat, Jun 9, 2012 at 10:14 AM, Bruce Sherwood <Bru...@nc...> wrote:
> Very interesting. There is much in your message about which I have no
> knowledge and no opinion. However, I can make some comments about the
> Big Picture.
>
> For a variety of reasons, I am personally committed to the further
> development and maintenance of both VPython and GlowScript.

ok, good news :-)

> [...]
>
> As I've said, I'm dreaming of constructing a VPython+ that would
> require a modern graphics card. If possible, I'd like to build it on
> top of one of the newer Python frameworks that work cross-platform, in
> particular to solve the menacing problem that Carbon on the Mac is not
> available for 64-bit Python.

out of curiosity, which frameworks are you considering/referencing?

> [...]
>
> I wasn't aware of the pypy.org project, and certainly running 5 times
> faster than CPython is important. What is "co", which you mention?

oh sorry, i just meant "and company", ie. pypy and all it's
dependencies, along with whatever other considerations are needed.
pypy is pretty incredible, and IMO, is the future of Python, and
possible other dynamic langs like Ruby et al.

thanks for your comments Bruce; i will note the vitality of both
projects during my demonstration.

--

C Anthony

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Visualpython-users mailing list
Vis...@li...
https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Future = (Vpython + Glowscript) | Glowscript | ???

[C A. R. <an...@xt...>]

On Sat, Jun 9, 2012 at 10:14 AM, Bruce Sherwood <Bru...@nc...> wrote:
> Very interesting. There is much in your message about which I have no
> knowledge and no opinion. However, I can make some comments about the
> Big Picture.
>
> For a variety of reasons, I am personally committed to the further
> development and maintenance of both VPython and GlowScript.

ok, good news :-)

> [...]
>
> As I've said, I'm dreaming of constructing a VPython+ that would
> require a modern graphics card. If possible, I'd like to build it on
> top of one of the newer Python frameworks that work cross-platform, in
> particular to solve the menacing problem that Carbon on the Mac is not
> available for 64-bit Python.

out of curiosity, which frameworks are you considering/referencing?

> [...]
>
> I wasn't aware of the pypy.org project, and certainly running 5 times
> faster than CPython is important. What is "co", which you mention?

oh sorry, i just meant "and company", ie. pypy and all it's
dependencies, along with whatever other considerations are needed.
pypy is pretty incredible, and IMO, is the future of Python, and
possible other dynamic langs like Ruby et al.

thanks for your comments Bruce; i will note the vitality of both
projects during my demonstration.

-- 

C Anthony

Re: [Visualpython-users] gtk embedding.

[Yann G. <ygo...@is...>]

Quoth Jerzy Karczmarczuk on Tue, Jun 12, 2012 at 11:53:17 +0200
> Of course this will not work on Windows (no os.fork, although some 
> people manufactured some unsafe hacks).

That is true.

> The problem can be probably solved using .subprocess in Python, but this 
> is not my domain. Perhaps somebody could add something?

It should be trivial to do so.  You just have a function that starts the
VPython process instead of the child fork.  Note that then you need to
either set the VPython window title as a parameter or have an agreed
title name (otherwise xwininfo will not work).  That reminds me, I am
not sure that xwininfo works on Windows either... So maybe not so
trivial.

A much nicer solution would involve threading.  However, I could not
make it work.  The code core dumps when it attempt to embed VPython.  If
anyone wanted to help, I would not mind working it out but cannot afford
to spend the time at work doing it.  Sorry.

-- 
GPG Fingerprint 8666 7F9A 17E7 AC8E CC36  1D1E C707 D658 6685 2528
   The views expressed in this e-mail may or may not reflect those of the
   author and do not necessarily reflect those of Isotek Oil and Gas Ltd.

Re: [Visualpython-users] gtk embedding.

[Jerzy K. <jer...@un...>]

Le 12/06/2012 09:11, Yann Golanski a écrit :
> Here is an example of embedding VPython within a GTK GUI.
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
Nice idea...

Of course this will not work on Windows (no os.fork, although some 
people manufactured some unsafe hacks).
The problem can be probably solved using .subprocess in Python, but this 
is not my domain. Perhaps somebody could
add something?

Jerzy Karczmarczuk

Re: [Visualpython-users] gtk embedding.

[Yann G. <ygo...@is...>]

Hi,

Here is an example of embedding VPython within a GTK GUI.  It is a trivial
skeleton type of thing.  Process communication can be done via a named file
(FIFO) pipe or a Queue().  

Feel free to add this example to your project if you think it will help
others.

================================================================================
#!/usr/bin/env python
# -*- coding: utf-8 -*-
import subprocess
import sys
import os
import re
import time
from visual import *


def find_window_id (title):
    """Gets the OpenGL window ID."""
    pattern = re.compile('0x[0-9abcdef]{7}')
    proc = subprocess.Popen(['xwininfo', '-name', title],
            stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    errors = proc.stderr.readlines()
    if errors:
        return None
    for line in proc.stdout.readlines():
        match = pattern.findall(line)
        if len(match):
            return long(match[0], 16)
    return None



class Setting ():
    """VPython/OpenGL class."""

    def __init__ (self, w=256, h=256, title='OpenGL via VPython'):
        """Initiator."""
        self.width = w
        self.height = h
        self.title = title
        self.scene = display.get_selected() 
        self.scene.title = self.title
        self.scene.width = self.width
        self.scene.height = self.height
        self.sphere = sphere()



class GTKDisplay ():

    def __init__ (self, winID):
        """Initiator: Draws the GTK GUI."""
        import gtk
        import pygtk
        self.OpenGLWindowID = winID
        window = gtk.Window()
        window.show()
        socket = gtk.Socket()
        socket.show()
        window.add(socket)
        window.connect("destroy", lambda w: gtk.main_quit())
        socket.add_id(long(self.OpenGLWindowID))
        gtk.main()



def main ():
    """Main entry point."""
    name = 'sphere OpenGL window'
    child_pid = os.fork()
    if 0 == child_pid:
        sut = Setting(title=name)
    else:
        winID = None
        while not winID:
            time.sleep(.1)
            winID = find_window_id(name)
        try:
            gui = GTKDisplay(winID)
        except KeyboardInterrupt, err:
            print '\nAdieu monde cruel!'


if __name__ == "__main__":
    main()
================================================================================

-- 
GPG Fingerprint 8666 7F9A 17E7 AC8E CC36  1D1E C707 D658 6685 2528
   The views expressed in this e-mail may or may not reflect those of the
   author and do not necessarily reflect those of Isotek Oil and Gas Ltd.

Re: [Visualpython-users] Does Glowscript have numpy-like performance?

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

The plot thickens. David Scherer rewrote a small piece of the
GlowScript gas example, and the time on both Chrome and Firefox
dropped to 1 second, not so different from the 0.4 second seen with
the numpy version. (The change has to do with disabling vector
overloading in the GlowScript handling of JavaScript.)

Bruce Sherwood

On Sun, Jun 10, 2012 at 9:59 PM, Bruce Sherwood <Bru...@nc...> wrote:
> After more study of GlowScript vs. VPython versions of the VPython
> gas.py program:
>
> VPython gas.py with 100 atoms, dt = 1e-5, rate 500, no graphing: 100
> iterations = 0.4 seconds.
>
> If gas.py is modified to not use numpy, the time is 3.6 s.
>
> The similar Glowsript program with same conditions: 100 iterations =
> 3.2 seconds on Firefox.
>
> Oddly, on at least one 64-bit Windows machine, the time is 5.3 seconds
> on Chrome.
>
> On a 32-bit Windows laptop, 4.2 seconds on Firefox, 2.5 seconds on
> Chrome, the reverse of the ordering on the other Windows machine.
>
> There is a very major difference between Chrome and Firefox. With
> Firefox, the animation periodically freezes, probably due to
> JavaScript garbage collection. These freeze-ups do not occur with
> Chrome or Safari.
>
> -----------------------
>
> You can run this program (if you have a WebGL-enabled browser; see the
> Help at glowscript.org) at
>
> http://www.glowscript.org/#/user/GlowScriptDemos/folder/Examples/program/HardSphereGas
>
> A summary statement is that the factor of 10 speed advantage of
> VPython over GlowScript comes completely from the parallel C-speed
> numpy arrays. Without numpy, the VPython and GlowScript (Python and
> JavaScript) execution speeds are about the same. I had mistakenly
> thought that JavaScript was much faster than Python, but  that seems
> not to be the case.
>
> Bruce Sherwood

Re: [Visualpython-users] Does Glowscript have numpy-like performance?

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

After more study of GlowScript vs. VPython versions of the VPython
gas.py program:

VPython gas.py with 100 atoms, dt = 1e-5, rate 500, no graphing: 100
iterations = 0.4 seconds.

If gas.py is modified to not use numpy, the time is 3.6 s.

The similar Glowsript program with same conditions: 100 iterations =
3.2 seconds on Firefox.

Oddly, on at least one 64-bit Windows machine, the time is 5.3 seconds
on Chrome.

On a 32-bit Windows laptop, 4.2 seconds on Firefox, 2.5 seconds on
Chrome, the reverse of the ordering on the other Windows machine.

There is a very major difference between Chrome and Firefox. With
Firefox, the animation periodically freezes, probably due to
JavaScript garbage collection. These freeze-ups do not occur with
Chrome or Safari.

-----------------------

You can run this program (if you have a WebGL-enabled browser; see the
Help at glowscript.org) at

http://www.glowscript.org/#/user/GlowScriptDemos/folder/Examples/program/HardSphereGas

A summary statement is that the factor of 10 speed advantage of
VPython over GlowScript comes completely from the parallel C-speed
numpy arrays. Without numpy, the VPython and GlowScript (Python and
JavaScript) execution speeds are about the same. I had mistakenly
thought that JavaScript was much faster than Python, but  that seems
not to be the case.

Bruce Sherwood