Menu
▾
▴
visualpython-users
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(15) |
Oct
(32) |
Nov
(35) |
Dec
(48) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(46) |
Feb
(22) |
Mar
(65) |
Apr
(49) |
May
(22) |
Jun
(29) |
Jul
(51) |
Aug
(34) |
Sep
(32) |
Oct
(46) |
Nov
(30) |
Dec
(32) |
| 2002 |
Jan
(48) |
Feb
(4) |
Mar
(20) |
Apr
(28) |
May
(13) |
Jun
(34) |
Jul
(51) |
Aug
(15) |
Sep
(15) |
Oct
(35) |
Nov
(15) |
Dec
(20) |
| 2003 |
Jan
(31) |
Feb
(111) |
Mar
(41) |
Apr
(28) |
May
(36) |
Jun
(29) |
Jul
(27) |
Aug
(29) |
Sep
(47) |
Oct
(28) |
Nov
(7) |
Dec
(26) |
| 2004 |
Jan
(44) |
Feb
(9) |
Mar
(17) |
Apr
(26) |
May
(58) |
Jun
(13) |
Jul
(44) |
Aug
(64) |
Sep
(30) |
Oct
(11) |
Nov
(21) |
Dec
(28) |
| 2005 |
Jan
(29) |
Feb
(11) |
Mar
(11) |
Apr
(22) |
May
(85) |
Jun
(46) |
Jul
(17) |
Aug
(18) |
Sep
(14) |
Oct
(22) |
Nov
(1) |
Dec
(45) |
| 2006 |
Jan
(20) |
Feb
(36) |
Mar
(18) |
Apr
(24) |
May
(21) |
Jun
(48) |
Jul
(23) |
Aug
(20) |
Sep
(10) |
Oct
(41) |
Nov
(46) |
Dec
(40) |
| 2007 |
Jan
(40) |
Feb
(20) |
Mar
(13) |
Apr
(6) |
May
(24) |
Jun
(31) |
Jul
(30) |
Aug
(11) |
Sep
(11) |
Oct
(10) |
Nov
(56) |
Dec
(64) |
| 2008 |
Jan
(64) |
Feb
(22) |
Mar
(63) |
Apr
(28) |
May
(25) |
Jun
(36) |
Jul
(11) |
Aug
(9) |
Sep
(14) |
Oct
(41) |
Nov
(46) |
Dec
(130) |
| 2009 |
Jan
(95) |
Feb
(41) |
Mar
(24) |
Apr
(35) |
May
(53) |
Jun
(67) |
Jul
(48) |
Aug
(48) |
Sep
(86) |
Oct
(75) |
Nov
(64) |
Dec
(52) |
| 2010 |
Jan
(57) |
Feb
(31) |
Mar
(28) |
Apr
(40) |
May
(25) |
Jun
(42) |
Jul
(79) |
Aug
(31) |
Sep
(49) |
Oct
(66) |
Nov
(38) |
Dec
(25) |
| 2011 |
Jan
(29) |
Feb
(18) |
Mar
(44) |
Apr
(6) |
May
(28) |
Jun
(31) |
Jul
(36) |
Aug
(24) |
Sep
(30) |
Oct
(23) |
Nov
(21) |
Dec
(27) |
| 2012 |
Jan
(14) |
Feb
(11) |
Mar
(2) |
Apr
(48) |
May
(7) |
Jun
(32) |
Jul
(22) |
Aug
(25) |
Sep
(31) |
Oct
(32) |
Nov
(21) |
Dec
(17) |
| 2013 |
Jan
(44) |
Feb
(27) |
Mar
(3) |
Apr
(1) |
May
|
Jun
|
Jul
(3) |
Aug
(4) |
Sep
(1) |
Oct
(7) |
Nov
(5) |
Dec
(5) |
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(2) |
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bruce S. <Bru...@nc...> - 2009-06-29 06:25:28
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
It's good that you provide two versions, but there's an informational
problem for someone trying to figure out the ramifications of which to
use.<br>
<br>
There aren't just two sides to this; there are more like four sides.
Sides 3 and 4 are these:<br>
<br>
3) There exists a large body of existing VPython programs developed
over the last 9 years that various constituencies depend on working,
and removing the numpy and math imports will break many (most?) of
these. Many of these users are students and faculty who cannot be
easily reached to explain a major change; they don't read computer
lists.<br>
<br>
4) There is a tricky point concerning mathematical functions that
appear in both math and numpy. When Arthur Siegel did the work to
convert Visual from dependence on Numeric to dependence on numpy,
performance on many existing programs was horrible, because numpy
scalar floats, unlike Numeric scalar floats, were no longer captured by
the fast math functions but instead were processed by the
array-handling numpy functions. There is arcane code in Visual to get
around this problem. Few users would be able to figure this out for
themselves.<br>
<br>
Bruce Sherwood<br>
<br>
Guy K. Kloss wrote:
<blockquote cite="mid:200...@ma..."
type="cite">
<pre wrap="">Hold your horses there ...
On Mon, 29 Jun 2009 17:52:11 Bruce Sherwood wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Warning: I do not accept the notion of removing the full importation of
numpy and math without vastly more discussion.
</pre>
</blockquote>
<pre wrap=""><!---->
That's why that package is provided *additionally*, but the basic one is given
first on that page.
</pre>
<blockquote type="cite">
<pre wrap="">There were and are good
reasons for the existing scheme, and changing this will break existing
programs right and left, programs that large numbers of people depend
on. Most of these people are students and instructors who aren't working
on Linux, so there's little immediate danger. And I accept that for some
advanced users cleaning the name space can be useful. But it should be
understood that this is for "consenting adults." My concern is that it
could be very difficult for someone who is not expert to be able to
figure out what has gone wrong.
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, so can be the difficulty trying to figure out why the code is all of a
sudden behaving erratically, although you did everything the way you usually
do in Python.
There are strong arguments for both sides. The one to make it easier, and the
one to keep it in a Pythonic way. And after all, the ones using it are using
Python, so that's the common denominator one should adhere to. And telling
them to do a wild card import should be easy as anyway, if they want it to be
simple but messy.
Guy
</pre>
</blockquote>
</body>
</html>
|
|
From: Guy K. K. <g....@ma...> - 2009-06-29 06:07:36
|
Hold your horses there ... On Mon, 29 Jun 2009 17:52:11 Bruce Sherwood wrote: > Warning: I do not accept the notion of removing the full importation of > numpy and math without vastly more discussion. That's why that package is provided *additionally*, but the basic one is given first on that page. > There were and are good > reasons for the existing scheme, and changing this will break existing > programs right and left, programs that large numbers of people depend > on. Most of these people are students and instructors who aren't working > on Linux, so there's little immediate danger. And I accept that for some > advanced users cleaning the name space can be useful. But it should be > understood that this is for "consenting adults." My concern is that it > could be very difficult for someone who is not expert to be able to > figure out what has gone wrong. Yes, so can be the difficulty trying to figure out why the code is all of a sudden behaving erratically, although you did everything the way you usually do in Python. There are strong arguments for both sides. The one to make it easier, and the one to keep it in a Pythonic way. And after all, the ones using it are using Python, so that's the common denominator one should adhere to. And telling them to do a wild card import should be easy as anyway, if they want it to be simple but messy. Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Massey University, Albany (North Shore City, Auckland) 473 State Highway 17, Gate 1, Mailroom, Quad B Building voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: Bruce S. <Bru...@nc...> - 2009-06-29 05:52:13
|
Warning: I do not accept the notion of removing the full importation of numpy and math without vastly more discussion. There were and are good reasons for the existing scheme, and changing this will break existing programs right and left, programs that large numbers of people depend on. Most of these people are students and instructors who aren't working on Linux, so there's little immediate danger. And I accept that for some advanced users cleaning the name space can be useful. But it should be understood that this is for "consenting adults." My concern is that it could be very difficult for someone who is not expert to be able to figure out what has gone wrong. Bruce Sherwood Guy K. Kloss wrote: > OK, creating a proper Debian package for Jaunty/Python 2.6 was a bit of a > challgenge. Gladly Jonas Smedegaard has recently created packages for the > upcoming Karmic Koala (9.10) release. So it was just a matter of a backport > making it *much* easier. > > Additionally I have patched the 5.11 version to not wildcard import visual, > numpy and math all over the place. So the name space is not polluted and > VPython should play much more nicely with other Python stuff on the system. > > Both packages are available for download here: > > https://gutefee.massey.ac.nz/moin/Python/3D > > (You need to accept the self signed certificate as an exception to get the > packages) > > Enjoy, > > Guy > > |
|
From: Symion <kn...@ip...> - 2009-06-29 05:30:43
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> Hi there,<br> I have found a problem with Clone Universe routine from Vpython documentation.<br> Everything seems to work well except for Points() and Convex(), Especially convex!<br> The following program contains Clone Universe and a small driver that demonstrates the problem.<br> I have set it up so that a simple change to the passed parameter can test multiple objects.<br> <br> Source Code: <a href="http://home.iprimus.com.au/knoware/webpage/cloneuniverse.py">Clone Universe</a><br> <br> Does anyone else find problems with this?<br> <br> Symion<br> <br> PS<br> I am using <font color="#cc0000"><big>VPython-Win-Py2.6-5.1-exp.exe</big></font> on a ASUS PRO50series 2.0 Ghz running under Windows Vista and a Radeon Xpress 1100 graphics card (Pixel Shader 2.0)<br> <br> </body> </html> |
|
From: Guy K. K. <g....@ma...> - 2009-06-29 02:34:59
|
OK, creating a proper Debian package for Jaunty/Python 2.6 was a bit of a challgenge. Gladly Jonas Smedegaard has recently created packages for the upcoming Karmic Koala (9.10) release. So it was just a matter of a backport making it *much* easier. Additionally I have patched the 5.11 version to not wildcard import visual, numpy and math all over the place. So the name space is not polluted and VPython should play much more nicely with other Python stuff on the system. Both packages are available for download here: https://gutefee.massey.ac.nz/moin/Python/3D (You need to accept the self signed certificate as an exception to get the packages) Enjoy, Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Massey University, Albany (North Shore City, Auckland) 473 State Highway 17, Gate 1, Mailroom, Quad B Building voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: Guy K. K. <g....@ma...> - 2009-06-29 01:24:39
|
On Mon, 29 Jun 2009 11:28:22 Bruce Sherwood wrote: > Here's what I've put into the documentation at vpython.org (and will go > into the documentation that is installed locally for Visual): > > > To hide a Visual object just make it invisible: ball.visible = 0. This does > not delete the object from computer memory, and you can make it visible > again later. > > If however you later re-use the name ball, for example by creating a new > object and naming it ball, Python will be free to release the memory used > by the object formerly named ball (assuming no other names currently refer > to that object). If the object is visible when you re-use the name ball, > the original object will not be deleted from computer memory, and it will > remain visible in the window. > > Suggestions for improvement? You might want to add something how to explicitly delete items as well. E. g. to remove them *now* call "del foobar" after setting the object to "obj.visible = False". BTW, I'd also suggest to use "ball.visible = False" rather than "... = 0". The boolean nature is much more expressive, and it also implies that you don't have a "value" there, which could be interpreted as visible = 0.5 is like opacity and makes it only half visible. This change would remove ambiguity straight off the bat. Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Massey University, Albany (North Shore City, Auckland) 473 State Highway 17, Gate 1, Mailroom, Quad B Building voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: Bruce S. <Bru...@nc...> - 2009-06-28 23:28:22
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Here's what I've put into the documentation at vpython.org (and will go into the documentation that is installed locally for Visual):<br> <br> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"> <p class="Normal" style="margin: 6pt 0pt 0pt; display: block; text-align: justify; text-indent: 0pt; font-size: 10pt; color: rgb(0, 0, 0); text-decoration: none; vertical-align: baseline; text-transform: none; font-family: sans-serif;">To hide a Visual object just make it invisible:<span class="Apple-converted-space"> </span><span class="attribute" style="color: rgb(255, 0, 0);">ball.visible = 0</span>. This does not delete the object from computer memory, and you can make it visible again later.</p> <p class="Normal" style="margin: 6pt 0pt 0pt; display: block; text-align: justify; text-indent: 0pt; font-size: 10pt; color: rgb(0, 0, 0); text-decoration: none; vertical-align: baseline; text-transform: none; font-family: sans-serif;">If however you later re-use the name<span class="Apple-converted-space"> </span><span class="attribute" style="color: rgb(255, 0, 0);">ball</span>, for example by creating a new object and naming it<span class="Apple-converted-space"> </span><span class="attribute" style="color: rgb(255, 0, 0);">ball</span>, Python will be free to release the memory used by the object formerly named<span class="Apple-converted-space"> </span><span class="attribute" style="color: rgb(255, 0, 0);">ball</span><span class="Apple-converted-space"> </span>(assuming no other names currently refer to that object). If the object is visible when you re-use the name<span class="Apple-converted-space"> </span><span class="attribute" style="color: rgb(255, 0, 0);">ball</span>, the original object will not be deleted from computer memory, and it will remain visible in the window.</p> </span><br> Suggestions for improvement?<br> <br> Bruce Sherwood<br> <br> Bruce Sherwood wrote: <blockquote cite="mid:4A4...@nc..." type="cite"> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> I guess the documentation needs to be more clear, in that it's using the word "delete" too informally. But it is important to note the full statement:<br> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"> <p class="Normal" style="margin: 6pt 0pt 0pt; display: block; text-align: justify; text-indent: 0pt; font-size: 10pt; color: rgb(0, 0, 0); text-decoration: none; vertical-align: baseline; text-transform: none; font-family: sans-serif;">To delete a Visual object just make it invisible:<span class="Apple-converted-space"> </span><span class="attribute" style="color: rgb(255, 0, 0);">ball.visible = 0</span></p> <p class="Normal" style="margin: 6pt 0pt 0pt; display: block; text-align: justify; text-indent: 0pt; font-size: 10pt; color: rgb(0, 0, 0); text-decoration: none; vertical-align: baseline; text-transform: none; font-family: sans-serif;">Technical detail: If you later re-use the name<span class="Apple-converted-space"> </span><span class="attribute" style="color: rgb(255, 0, 0);">ball</span>, for example by creating a new object and naming it <span class="attribute" style="color: rgb(255, 0, 0);">ball</span>, Python will be free to release the memory used by the object formerly named<span class="Apple-converted-space"> </span><span class="attribute" style="color: rgb(255, 0, 0);">ball</span><span class="Apple-converted-space"> </span>(assuming no other names currently refer to that object).</p> </span><br> Probably the first sentence should be replaced by this: "To hide a Visual object just make it invisible: ball.visible = 0. This does not delete the information about the object from the computer's memory, since you can at a later time make it visible again by setting ball.visible = 1."<br> <br> Additional technical point: Python maintains a reference count on objects, with the policy that if the reference count goes to zero the object can be deleted from memory, as there is no longer any way to refer to it. A Visual object has one additional reference count associated with the fact that some human may be looking at the object if it is "visible", which is why you have to make an object invisible (which decrements the reference count) before you can get it fully deleted.<br> <br> Bruce Sherwood<br> <br> Jamie Riotto wrote: <blockquote cite="mid:958...@ma..." type="cite"> <pre wrap="">On Sat, Jun 27, 2009 at 11:38 PM, Guy K. Kloss <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:g....@ma..."><g....@ma...></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">On Sun, 28 Jun 2009 17:51:47 Jamie Riotto wrote: </pre> <blockquote type="cite"> <pre wrap="">I believe setting scene.visible to false just makes the scene invisible, it doesn't delete it, unlike objects. If you'd like to reinitialize the scene then just delete all visible objects: for obj in scene.objects: obj.visible = false </pre> </blockquote> <pre wrap="">That ought to be "False". But that also doesn't work, as visual.scene is the object that complains about re-initialised, and that one is a module level variable, so it can only be initialised once per running Python process. Iterating over the objects and setting their visibility to False should (A) just hide them, but not delete them, and (B) still leave the current scene's instance in the state it's in. So that's not helpful, either. </pre> </blockquote> <pre wrap=""><!----> Guy, I understand my suggestion didn't fix your problem, but as to your point (A), that setting visiblity to False should hide objects and not delete them, from the VPython Docs: Deleting an Object To delete a Visual object just make it invisible: ball.visible = 0 (Not that I agree with the behavior, I'd prefer being able to make things visible and invisible at will without having to manage the invisible objects (i.e. deleted) myself) Cheers - jamie ------------------------------------------------------------------------------ _______________________________________________ Visualpython-users mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Vis...@li...">Vis...@li...</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/visualpython-users">https://lists.sourceforge.net/lists/listinfo/visualpython-users</a> </pre> </blockquote> <pre wrap=""> <hr size="4" width="90%"> ------------------------------------------------------------------------------ </pre> <pre wrap=""> <hr size="4" width="90%"> _______________________________________________ Visualpython-users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Vis...@li...">Vis...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/visualpython-users">https://lists.sourceforge.net/lists/listinfo/visualpython-users</a> </pre> </blockquote> </body> </html> |
|
From: Bruce S. <Bru...@nc...> - 2009-06-28 23:15:29
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I guess the documentation needs to be more clear, in that it's using
the word "delete" too informally. But it is important to note the full
statement:<br>
<span class="Apple-style-span"
style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;">
<p class="Normal"
style="margin: 6pt 0pt 0pt; display: block; text-align: justify; text-indent: 0pt; font-size: 10pt; color: rgb(0, 0, 0); text-decoration: none; vertical-align: baseline; text-transform: none; font-family: sans-serif;">To
delete a Visual object just make it invisible:<span
class="Apple-converted-space"> </span><span class="attribute"
style="color: rgb(255, 0, 0);">ball.visible = 0</span></p>
<p class="Normal"
style="margin: 6pt 0pt 0pt; display: block; text-align: justify; text-indent: 0pt; font-size: 10pt; color: rgb(0, 0, 0); text-decoration: none; vertical-align: baseline; text-transform: none; font-family: sans-serif;">Technical
detail: If you later re-use the name<span class="Apple-converted-space"> </span><span
class="attribute" style="color: rgb(255, 0, 0);">ball</span>, for
example by creating a new object and naming it <span class="attribute"
style="color: rgb(255, 0, 0);">ball</span>, Python will be free to
release the memory used by the object formerly named<span
class="Apple-converted-space"> </span><span class="attribute"
style="color: rgb(255, 0, 0);">ball</span><span
class="Apple-converted-space"> </span>(assuming no other names
currently refer to that object).</p>
</span><br>
Probably the first sentence should be replaced by this: "To hide a
Visual object just make it invisible: ball.visible = 0. This does not
delete the information about the object from the computer's memory,
since you can at a later time make it visible again by setting
ball.visible = 1."<br>
<br>
Additional technical point: Python maintains a reference count on
objects, with the policy that if the reference count goes to zero the
object can be deleted from memory, as there is no longer any way to
refer to it. A Visual object has one additional reference count
associated with the fact that some human may be looking at the object
if it is "visible", which is why you have to make an object invisible
(which decrements the reference count) before you can get it fully
deleted.<br>
<br>
Bruce Sherwood<br>
<br>
Jamie Riotto wrote:
<blockquote
cite="mid:958...@ma..."
type="cite">
<pre wrap="">On Sat, Jun 27, 2009 at 11:38 PM, Guy K. Kloss <a class="moz-txt-link-rfc2396E" href="mailto:g....@ma..."><g....@ma...></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Sun, 28 Jun 2009 17:51:47 Jamie Riotto wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I believe setting scene.visible to false just makes the scene invisible, it
doesn't delete it, unlike objects. If you'd like to reinitialize the scene
then just delete all visible objects:
for obj in scene.objects:
obj.visible = false
</pre>
</blockquote>
<pre wrap="">That ought to be "False". But that also doesn't work, as visual.scene is the
object that complains about re-initialised, and that one is a module level
variable, so it can only be initialised once per running Python process.
Iterating over the objects and setting their visibility to False should (A)
just hide them, but not delete them, and (B) still leave the current scene's
instance in the state it's in. So that's not helpful, either.
</pre>
</blockquote>
<pre wrap=""><!---->
Guy,
I understand my suggestion didn't fix your problem, but as to your point (A),
that setting visiblity to False should hide objects and not delete them,
from the VPython Docs:
Deleting an Object
To delete a Visual object just make it invisible: ball.visible = 0
(Not that I agree with the behavior, I'd prefer being able to make
things visible and invisible
at will without having to manage the invisible objects (i.e. deleted) myself)
Cheers - jamie
------------------------------------------------------------------------------
_______________________________________________
Visualpython-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Vis...@li...">Vis...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/visualpython-users">https://lists.sourceforge.net/lists/listinfo/visualpython-users</a>
</pre>
</blockquote>
</body>
</html>
|
|
From: Jamie R. <jam...@gm...> - 2009-06-28 20:22:31
|
On Sat, Jun 27, 2009 at 11:38 PM, Guy K. Kloss <g....@ma...> wrote: > > On Sun, 28 Jun 2009 17:51:47 Jamie Riotto wrote: > > I believe setting scene.visible to false just makes the scene invisible, it > > doesn't delete it, unlike objects. If you'd like to reinitialize the scene > > then just delete all visible objects: > > > > for obj in scene.objects: > > obj.visible = false > > That ought to be "False". But that also doesn't work, as visual.scene is the > object that complains about re-initialised, and that one is a module level > variable, so it can only be initialised once per running Python process. > > Iterating over the objects and setting their visibility to False should (A) > just hide them, but not delete them, and (B) still leave the current scene's > instance in the state it's in. So that's not helpful, either. Guy, I understand my suggestion didn't fix your problem, but as to your point (A), that setting visiblity to False should hide objects and not delete them, from the VPython Docs: Deleting an Object To delete a Visual object just make it invisible: ball.visible = 0 (Not that I agree with the behavior, I'd prefer being able to make things visible and invisible at will without having to manage the invisible objects (i.e. deleted) myself) Cheers - jamie |
|
From: Guy K. K. <g....@ma...> - 2009-06-28 20:08:20
|
Hi Bruce, thanks for the explanations, I'll give it a try. I think whenever I set the visual.scene.visible = False my program stopped. It was a very strange behaviour. It was like there's still an event loop or so going from the GUI, and the only way to terminate the process was through an explicit kill. I need to have a look at it again. On Mon, 29 Jun 2009 03:59:02 Bruce Sherwood wrote: > I'm worried that something's apparently wrong with the del statement, > which should have gotten rid of the first display completely. I'll look > into that. Setting all the objects to invisible before making the > display invisible doesn't change anything. I've seen things like that before, wrapping native code in Python. I believe it's got more to do with the C side of things rather than the Python side. Python's del only acts on things that live in the Python world, and it does not/cannot call memory frees, destructors, etc. in the shared library's native code world. What I've done on ctypes based projects before was to add cleaning code to the Python object's __del__ method that performs some native code cleaning on deleting the Python object. Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Massey University, Albany (North Shore City, Auckland) 473 State Highway 17, Gate 1, Mailroom, Quad B Building voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: Bruce S. <Bru...@nc...> - 2009-06-28 15:59:46
|
There does seem to be a bug, but it's easy to make it work properly. Consider this: d = display() box() my_scene = visual.display.get_selected() my_scene.mouse.getclick() my_scene.visible = False # makes invisible but does not delete print my_scene del my_scene # should get rid of it completely ##d = display() sphere(pos=(2,0,0)) # this should create a new scene, but no window appears print visual.display.get_selected() # shows the same ID as before The cure is to uncomment the second display() statement, and then it works as expected. In other words, don't rely on the default "scene" mechanism but make your own displays if you are going to manipulate those displays. I'm worried that something's apparently wrong with the del statement, which should have gotten rid of the first display completely. I'll look into that. Setting all the objects to invisible before making the display invisible doesn't change anything. Bruce Sherwood Guy K. Kloss wrote: > Hi, > > as some may have noticed, I also run VPython with many things in batch mode. > Unfortunately I've just hit a bump doing so. I introduced another layer for > batching some computations/visualisations. So I'm wrapping my module and > calling it repeatedly with changing parameters in a batch. Unfortunately when > I'm doing that for me VPython "misbehaves". I cannot seem to find a way to > discard a previous scene to create a new one. Whenever I just do it naively, I > get this error: > > RuntimeError: Cannot change parameters of an active window > > As the new scene is being initialised with window title, size, ... > > I've already tried to retrieve the current scene with > > my_scene = visual.display.get_selected() > > And then set its visibility to False: > > my_scene.visible = False > > In this case the program just stalls and needs to be killed from another > console. Or I try to delete the scene instance using: > > del my_scene > > or > > del visual.scene > > Which doesn't do anything as apparently visual.scene is a static module > variable that cannot be discarded. > > Any ideas on how to make use of it in a sensible way without having to > manually create new processes for each sample just to discard the scene? > > Guy > > |
|
From: Guy K. K. <g....@ma...> - 2009-06-28 06:38:38
|
On Sun, 28 Jun 2009 17:51:47 Jamie Riotto wrote: > I believe setting scene.visible to false just makes the scene invisible, it > doesn't delete it, unlike objects. If you'd like to reinitialize the scene > then just delete all visible objects: > > for obj in scene.objects: > obj.visible = false That ought to be "False". But that also doesn't work, as visual.scene is the object that complains about re-initialised, and that one is a module level variable, so it can only be initialised once per running Python process. Iterating over the objects and setting their visibility to False should (A) just hide them, but not delete them, and (B) still leave the current scene's instance in the state it's in. So that's not helpful, either. I did help myself by checking whether visible.scene.title has been changed, and if so then to hide all objects and not re-initialise the scene. But that's more of a dirty hack, rather than a real solution. It just targets this *one* case, and cannot be generally used for other modules using visual as it would be expectable from Python code. Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Massey University, Albany (North Shore City, Auckland) 473 State Highway 17, Gate 1, Mailroom, Quad B Building voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: Jamie R. <jam...@gm...> - 2009-06-28 05:51:51
|
Sorry, here's the rest...
for obj in scene.objects:
obj.visible = false
2009/6/27 Jamie Riotto <jam...@gm...>
> I believe setting scene.visible to false just makes the scene invisible, it
> doesn't delete it,
> unlike objects. If you'd like to reinitialize the scene then just delete
> all visible objects:
>
> for obj in scene.objects:
>
>
>
>
> On Sat, Jun 27, 2009 at 5:29 PM, Guy K. Kloss <g....@ma...>wrote:
>
>> Hi,
>>
>> as some may have noticed, I also run VPython with many things in batch
>> mode.
>> Unfortunately I've just hit a bump doing so. I introduced another layer
>> for
>> batching some computations/visualisations. So I'm wrapping my module and
>> calling it repeatedly with changing parameters in a batch. Unfortunately
>> when
>> I'm doing that for me VPython "misbehaves". I cannot seem to find a way to
>> discard a previous scene to create a new one. Whenever I just do it
>> naively, I
>> get this error:
>>
>> RuntimeError: Cannot change parameters of an active window
>>
>> As the new scene is being initialised with window title, size, ...
>>
>> I've already tried to retrieve the current scene with
>>
>> my_scene = visual.display.get_selected()
>>
>> And then set its visibility to False:
>>
>> my_scene.visible = False
>>
>> In this case the program just stalls and needs to be killed from another
>> console. Or I try to delete the scene instance using:
>>
>> del my_scene
>>
>> or
>>
>> del visual.scene
>>
>> Which doesn't do anything as apparently visual.scene is a static module
>> variable that cannot be discarded.
>>
>> Any ideas on how to make use of it in a sensible way without having to
>> manually create new processes for each sample just to discard the scene?
>>
>> Guy
>>
>> --
>> Guy K. Kloss
>> Institute of Information and Mathematical Sciences
>> Te Kura Pūtaiao o Mōhiohio me Pāngarau
>> Massey University, Albany (North Shore City, Auckland)
>> 473 State Highway 17, Gate 1, Mailroom, Quad B Building
>> voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181
>> G....@ma... http://www.massey.ac.nz/~gkloss
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>
>
>
|
|
From: Jamie R. <jam...@gm...> - 2009-06-28 05:50:35
|
I believe setting scene.visible to false just makes the scene invisible, it doesn't delete it, unlike objects. If you'd like to reinitialize the scene then just delete all visible objects: for obj in scene.objects: On Sat, Jun 27, 2009 at 5:29 PM, Guy K. Kloss <g....@ma...> wrote: > Hi, > > as some may have noticed, I also run VPython with many things in batch > mode. > Unfortunately I've just hit a bump doing so. I introduced another layer for > batching some computations/visualisations. So I'm wrapping my module and > calling it repeatedly with changing parameters in a batch. Unfortunately > when > I'm doing that for me VPython "misbehaves". I cannot seem to find a way to > discard a previous scene to create a new one. Whenever I just do it > naively, I > get this error: > > RuntimeError: Cannot change parameters of an active window > > As the new scene is being initialised with window title, size, ... > > I've already tried to retrieve the current scene with > > my_scene = visual.display.get_selected() > > And then set its visibility to False: > > my_scene.visible = False > > In this case the program just stalls and needs to be killed from another > console. Or I try to delete the scene instance using: > > del my_scene > > or > > del visual.scene > > Which doesn't do anything as apparently visual.scene is a static module > variable that cannot be discarded. > > Any ideas on how to make use of it in a sensible way without having to > manually create new processes for each sample just to discard the scene? > > Guy > > -- > Guy K. Kloss > Institute of Information and Mathematical Sciences > Te Kura Pūtaiao o Mōhiohio me Pāngarau > Massey University, Albany (North Shore City, Auckland) > 473 State Highway 17, Gate 1, Mailroom, Quad B Building > voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 > G....@ma... http://www.massey.ac.nz/~gkloss > > > ------------------------------------------------------------------------------ > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users > |
|
From: Guy K. K. <g....@ma...> - 2009-06-28 02:58:18
|
A bit more on why namespace pollution is bad, particularly in this case: On Sun, 28 Jun 2009 12:50:24 Guy K. Kloss wrote: > from math import * > from numpy import * math and numpy both define certain functions and constants. So there's already a clash happening on the import with the latter import overwriting certain functionality of the former. NumPy provides quite a few functions that behave (almost) the same as the ones from math (e. g. abs(), sin(), ...). But the NumPy versions mostly also work on arrays, whereas the ones from math do not. So there is potentially already quite some confusion for the developer (of the VPython module). Own tests resulted in the math versions of the functions to be more performant than the NumPy version. This is not unusual, as they don't have to deal with arrays and can be launched directly at the passed parameters. If now users also naively import "from visual import *" they will have (A) a totally polluted name space themselves, but (B) also not have the choice any more over what *exact* functions they are using. In many cases that might not matter, but it can be very dangerous in cases of reproducibility or when one *depends* on a specific behaviour! So just for a minor convenience or laziness of the developer everybody further downstream is potentially suffering of the snowball imports. There *are* valid use cases for snowball imports, but they are not like this (e. g. developing a package to offer functions, which in turn are implemented in various sub modules. Then the __init__ of the package may snowball import these to expose the API to the outside.). So, please let's help clean up this mess! Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Massey University, Albany (North Shore City, Auckland) 473 State Highway 17, Gate 1, Mailroom, Quad B Building voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: Guy K. K. <g....@ma...> - 2009-06-28 01:18:22
|
Hi, just trying to hunt down on how to delete a scene, so I can create a new one within the same running program. Trying to hunt this down I've been wondering why there are so many things within the visual module. It is absolutely a highly polluted name space. It's happening already in the visual.__init__ module through two snowball imports: from math import * from numpy import * Would it be possible to refactor VPython in the future to be a little bit better behaved and just import numpy and math and use the functions using the dot notation (numpy.array, math.sin, ...) rather than them blended *all* directly into the name space? All Python style guides tell to *not* pollute the name space. Here's one from the "Code Like a Pythonista: Idiomatic Python" from David Goodger's PyCon 2007 talk: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing Let's try to make Visual Python a good Python citizen! Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Massey University, Albany (North Shore City, Auckland) 473 State Highway 17, Gate 1, Mailroom, Quad B Building voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: Guy K. K. <g....@ma...> - 2009-06-28 01:01:59
|
Hi,
as some may have noticed, I also run VPython with many things in batch mode.
Unfortunately I've just hit a bump doing so. I introduced another layer for
batching some computations/visualisations. So I'm wrapping my module and
calling it repeatedly with changing parameters in a batch. Unfortunately when
I'm doing that for me VPython "misbehaves". I cannot seem to find a way to
discard a previous scene to create a new one. Whenever I just do it naively, I
get this error:
RuntimeError: Cannot change parameters of an active window
As the new scene is being initialised with window title, size, ...
I've already tried to retrieve the current scene with
my_scene = visual.display.get_selected()
And then set its visibility to False:
my_scene.visible = False
In this case the program just stalls and needs to be killed from another
console. Or I try to delete the scene instance using:
del my_scene
or
del visual.scene
Which doesn't do anything as apparently visual.scene is a static module
variable that cannot be discarded.
Any ideas on how to make use of it in a sensible way without having to
manually create new processes for each sample just to discard the scene?
Guy
--
Guy K. Kloss
Institute of Information and Mathematical Sciences
Te Kura Pūtaiao o Mōhiohio me Pāngarau
Massey University, Albany (North Shore City, Auckland)
473 State Highway 17, Gate 1, Mailroom, Quad B Building
voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss
|
|
From: Symion <kn...@ip...> - 2009-06-27 07:47:24
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> Hi there,<br> I have just updated my New web page with a section on Vpython, and I would like to invite any interested parties to take a look.<br> All programs are Open Source and the copywrite is mine.<br> <br> The address is: <a href="http://home.iprimus.com.au/knoware/webpage/index.htm">my personal web page</a><br> <br> Look for the Vpython button!<br> Screen shots connect to the Source Code of each Project!<br> <br> Symion<br> <br> </body> </html> |
|
From: Bruce S. <Bru...@nc...> - 2009-06-23 17:14:11
|
Thanks much for these improvements! I'll get these into the posted version. Bruce Sherwood Guy K. Kloss wrote: > Attached a patch for a first attempt to also do labels. > > Unfortunately I know by far too little about POVray, so it's quite a feeble > attempt on that. But it *does* produce some text output at the right places, > in the right text colour, just not rotated and sized properly. > > Guy > > > |
|
From: Michele M. <mat...@gm...> - 2009-06-23 10:53:02
|
Hi list, I would like to know if it's possible to extend visio into a GTKWidget. it seems to me that visuul fire up a GTK2 window and use gtkmain to control it's own events. It would be really handy to have the visual loop under the main gtk so any event from any external app will be used evaluated at any time and not only when visual return. Thanks, Michele. |
|
From: Guy K. K. <g....@ma...> - 2009-06-22 05:33:57
|
On Mon, 22 Jun 2009 17:29:06 Guy K. Kloss wrote: > Unfortunately I know by far too little about POVray, so it's quite a feeble > attempt on that. But it *does* produce some text output at the right > places, in the right text colour, just not rotated and sized properly. Maybe this gives some insight for someone with more POVray experience: http://news.povray.org/povray.text.tutorials/message/<b27i0tg8l509mufq63lg56efmdotq6kgqs%404ax.com>/#<b27i0tg8l509mufq63lg56efmdotq6kgqs%404ax.com> Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Massey University, Albany (North Shore City, Auckland) 473 State Highway 17, Gate 1, Mailroom, Quad B Building voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: Guy K. K. <g....@ma...> - 2009-06-22 05:28:58
|
Attached a patch for a first attempt to also do labels. Unfortunately I know by far too little about POVray, so it's quite a feeble attempt on that. But it *does* produce some text output at the right places, in the right text colour, just not rotated and sized properly. Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Massey University, Albany (North Shore City, Auckland) 473 State Highway 17, Gate 1, Mailroom, Quad B Building voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: Guy K. K. <g....@ma...> - 2009-06-22 04:30:40
|
Hi Bruce, On Mon, 22 Jun 2009 07:28:47 Bruce Sherwood wrote: > I believe that if you use the latest povexport you'll find that the arrow > opacity issue has been fixed (thanks to Scott David Daniels). I've just given it a shot, and it didn't really do the trick for me, either. There are still two bugs in the module: * The box for the arrow does not take the (calculated) value sw in the function, but uses a.shaftwidth directly * For very long arrows the box becomes too thin. To mock the behaviour as in VPython the shaftwidth should be limited to 1/50 th of the arrow length. Attached is a minimal patch against the 2009-06-14 version that should fix that. Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Massey University, Albany (North Shore City, Auckland) 473 State Highway 17, Gate 1, Mailroom, Quad B Building voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: Bruce S. <Bru...@nc...> - 2009-06-21 23:16:04
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Sigh. Thanks. Now fixed in those two places, too.<br> <br> The standard place where I had made the fix is in the Documentation section of vpython.org, reached by clicking on "Documentation" on the home page of vpython.org.<br> <br> Note that <a class="moz-txt-link-freetext" href="http://www.vpython.org/FAQ.html">http://www.vpython.org/FAQ.html</a> is in the "old" Visual 3 section of vpython.org, which will eventually go away after a decent interval.<br> <br> Bruce Sherwood<br> <br> Guy K. Kloss wrote: <blockquote cite="mid:200...@ma..." type="cite"> <pre wrap="">On Mon, 22 Jun 2009 07:28:47 you wrote: </pre> <blockquote type="cite"> <pre wrap="">Thanks for the info. That FAQ link is now fixed. </pre> </blockquote> <pre wrap=""><!----> That's odd, I still see a link to povexport-2008-11-25.zip here: * <a class="moz-txt-link-freetext" href="http://vpython.wikidot.com/">http://vpython.wikidot.com/</a> * <a class="moz-txt-link-freetext" href="http://www.vpython.org/FAQ.html">http://www.vpython.org/FAQ.html</a> But none to a newer version. Guy </pre> </blockquote> </body> </html> |
|
From: Guy K. K. <g....@ma...> - 2009-06-21 23:05:39
|
On Mon, 22 Jun 2009 07:28:47 you wrote: > Thanks for the info. That FAQ link is now fixed. That's odd, I still see a link to povexport-2008-11-25.zip here: * http://vpython.wikidot.com/ * http://www.vpython.org/FAQ.html But none to a newer version. Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Massey University, Albany (North Shore City, Auckland) 473 State Highway 17, Gate 1, Mailroom, Quad B Building voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
33 messages has been excluded from this view by a project administrator.
