visualpython-users

[Visualpython-users] bug report - or what?

[Gregor L. <gl...@ao...>]

Hi VPython people!

Below I enclose an exchange of postings on comp.lang.py
with Alex Martelli on an observation when working with
VPython, which reveals something we consider to be a
bug or at least an anomaly ...

Does somebody have an explanation?

Hope this goes to the right adress ... (otherwise could you
redirect it ?)

Gregor Lingl

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


1:: Gregor Lingl:

I thought to understand the dir() function, but...

... when playing around with VPython I encountered the
following:

>>> from visual import *
Visual-2002-06-14
>>> s=3Dsphere() # beautiful white sphere displayed immediately
>>> s
<Primitive object at 0x01563D34>
>>> dir(s)
['__class__', 'axis', 'blue', 'color', 'constr',
 'display', 'frame', 'green', 'name', 'pos', 'radius',
'red', 'rotate', 'up', 'visible', 'x', 'y', 'z']
>>> s.__methods__
['rotate']
>>> s.__dict__
{'__class__': <built-in method sphere of tuple object at 0x00A65590>}
>>> s.__members__
['axis', 'blue', 'color', 'display', 'frame', 'green',
'pos', 'radius', 'red', 'up', 'visible', 'x', 'y', 'z']
>>> s.name
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in ?
    s.name
AttributeError: name
>>>

So, what are 'name' and 'constr', which both do not appear
neither in s.__members__ nor in s.__dict__ nor in s.__methods__,
but in the list returned by dir(s)?

(Or: what is generally returned by dir() ?)

Perhaps there is somebody who can explain this.

Thanks, Gregor


In other words: what happens in the following example, should not
happen in my understanding:

>>> from visual import *
Visual-2002-06-14
>>> s =3D sphere()
>>> for att in dir(s):
        print att, ':',
        print type(eval('s.'+att))


__class__ : <type 'instance'>
axis : <type 'vector'>
blue : <type 'float'>
color : <type 'tuple'>
constr :
Traceback (most recent call last):
  File "<pyshell#46>", line 3, in ?
    print type(eval('y.'+att))
  File "<string>", line 0, in ?
AttributeError: constr
>>>

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

2:: Alex Martelli:

Gregor Lingl wrote:

> I thought to understand the dir() function, but...

dir() is somewhat in transition between Python 2.1 and 2.2.
Not sure what Python level should be installed with Visual-06-14.
It does matter which exact level you did install, and on which
platform, though.

I just downloaded and installed Visual-2002-07-07 on top of
my Python 2.2.1 but the s.__members__ access, and thus also
dir(s), just kills the Python interactive session stone dead
with 'Aborted' as the only message.  Maybe the 06-14 version
had its own problems -- not quite as serious as 07-07's (at
least with Python 2.2.1 on Mandrake Linux 8.2:-) but enough
to give the anomalies you observe.

(It's also possible that I made some mistake in installation,
of course, but I closely followed the specific instructions
for Mandrake on the "additional info" page of Visual).


Alex

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

3:: Gregor Lingl:

What a surprise to come into contact with martellibot just
after having read your interview on the Euro Python website.

I'm working with Python 2.2.1 on a Windows2000 machine.
Curious if something similar would happen on my machine
I just deinstalled Visual-2002-06-14 and replaced it by
Visual-2002-07-07 and I obtain exactly the same results
as before - the session remaining alive...

Let's see, if somebody else will give us more information
on this ...

Gregor

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

4:: Alex Martelli:

Gregor Lingl wrote:

> What a surprise to come into contact with martellibot just
> after having read your interview on the Euro Python website.

Pleased to meet you!  I shouldn't be here (don't tell my
O'Reilly editor I'm writing on c.l.py when I should be
busy finishing the Nutshell book...), but...


> I'm working with Python 2.2.1 on a Windows2000 machine.

I have not tried VPython anywhere except on Linux, where
I just tried reproducing your problem -- as I said, it's
slightly different there.

> Curious if something similar would happen on my machine
> I just deinstalled Visual-2002-06-14 and replaced it by
> Visual-2002-07-07 and I obtain exactly the same results
> as before - the session remaining alive...
>
> Let's see, if somebody else will give us more information
> on this ...

I think you should forward a copy of these exchanges (or
a pointer to them via google advanced group search) to
the VPython guys -- I'm sure they'll be able to debug and
fix the problem very simply, while it would take longer
for somebody utterly unfamiliar with VPython's internals,
such as yours truly...


Alex

[Visualpython-users] Mandrake Linux

[Bruce S. <bas...@un...>]

Thanks to Francois Papa, there is now information on the Linux download 
page ("additional info") for installing VPython on Mandrake Linux.

Bruce Sherwood

Fwd: [Visualpython-users] Re: Trouble installing on Debian

[Bruce S. <bas...@un...>]

I just came across this old email that relates to problems compiling 
VPython for Debian:

>From: "Neal M. Holtz" <nh...@do...>
>To: vis...@li...
>User-Agent: Mutt/1.3.28i
>Subject: [Visualpython-users] Re: Trouble installing on Debian
>Sender: vis...@li...
>X-BeenThere: vis...@li...
>X-Mailman-Version: 2.0.9-sf.net
>List-Help: 
><mailto:vis...@li...?subject=help>
>List-Post: <mailto:vis...@li...>
>List-Subscribe: 
><https://lists.sourceforge.net/lists/listinfo/visualpython-users>,
> 
><mailto:vis...@li...?subject=subscribe>
>List-Id: <visualpython-users.lists.sourceforge.net>
>List-Unsubscribe: 
><https://lists.sourceforge.net/lists/listinfo/visualpython-users>,
> 
><mailto:vis...@li...?subject=unsubscribe>
>List-Archive: 
><http://www.geocrawler.com/redir-sf.php3?list=visualpython-users>
>X-Original-Date: Sat, 4 May 2002 07:58:31 -0400
>Date: Sat, 4 May 2002 07:58:31 -0400
>
>A couple of replies with respect to a "segfault" problem on Debian
>(and also on my highly non-standard Caldera) mentioned problems
>with passing const char * pointers.   Those points may be valid,
>but consider the original method causing the problem:
>
>void PythonType::name( const char* nam )
>{
>    table->tp_name = const_cast<char *>( name );
>}
>
>I bet that line should be:
>
>    table->tp_name = const_cast<char *>( nam );
>
>Otherwise, the code is storing a pointer to the method
>and not the string -- a simple typo.
>
>Changing it this way fixes the segfault on my Caldera system.
>
>Cheers, and thanks for making it easy for me to fix
>the problem get VPython to run ..
>
>neal
>
>
>      FROM: Bruce Sherwood
>      DATE: 04/26/2002 06:40:58
>      SUBJECT:  [Visualpython-users] Trouble installing on Debian
>
> >     Here is some nice detective work by Yves Bailly in France. I should
> >     incorporate his change, but in the meantime here is what he found. I'm
> >     puzzled that others running on Debian did not run into this problem.
> >
> >     Bruce Sherwood
> >
> >     --On Friday, April 26, 2002 1:57 AM +0200 Yves BAILLY
> >     <<EMAIL: PROTECTED>> wrote:
> >
> >     > Hello,
> >     >
> >     > First of all, I have to say : contragulation for your great work !
> >     >
> >     > Now, my problem :
> >     > I tried to install VPython on a Debian "sid", using :
> >     > - Python 2.2.1
> >     > - Numeric 21.0
> >     > - GtkGlArea 1.2.3
> >     > - Mesa which comes with XFree86 4.1.0
> >     >
> >     > Everything compiles fine, but when running
> >     > from visual import *
> >     > ...I was always getting a segfault.
> >     >
> >     > I dig a little bit, and found this in 
> cvisual/CXX/Src/cxx_extensions.cxx :
> >     > void PythonType::name( const char* nam )
> >     > {
> >     >        table->tp_name = const_cast<char *>( name );
> >     > }
> >     > The segfault seemed to occure during this method.
> >     >
> >     > Considering the char* is a rather strange thing, that should 
> always be
> >     > used with care, moreover when you give a litteral string to a 
> function,
> >     > I just modified this method a little, to allocate and duplicate the
> >     > string :
> >     > void PythonType::name( const char* nam )
> >     > {
> >     >        char* str = new char[strlen(nam)+1] ;
> >     >        strcpy(str, nam) ;
> >     >        table->tp_name = const_cast<char *>( str );
> >     > }
> >     >
> >     > ...and now it works fine, I can even use the KineticsKit !
> >     >
> >     > Just a quick hack, for sure there should something better (nicer).
> >     >
> >     > Best regards,
> >     >
> >     > --
> >     > ( | Yves Bailly  : http://kafka-fr.net   | -
> >     > //\ | Linux Dijon  : http://www.coagul.org | //\
> >     > \_/ | Don d'organe : http://adot21.free.fr | \_/`
> >
>
>--
>Neal Holtz                             http://www.docuweb.ca/~nholtz
>Dept. of Civil and Environmental Engineering,   Carleton University,
>Ottawa, Ontario, Canada K1S 5B6.                   nh...@do...
>
>
>_______________________________________________________________
>
>Have big pipes? SourceForge.net is looking for download mirrors. We supply
>the hardware. You get the recognition. Email Us: ban...@so...
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users

[Visualpython-users] GCC3.1 anyone?

[Toan N. <ttn...@ph...>]

Hi, does anybody here successfully compile VPython with the new GCC 3.1 ?
I want to make sure this is the problem before degrade my GCC back to
3.0.4 (It used to compile with GCC 3.0.4 on my machine before I upgrade
GCC)

Thanks.




-----------------------------------------
Nguyen, Toan The
School of Physics and Astronomy
University of Minnesota
116 Church St. SE

Tel: +612 624 8335
Fax: +612 626 8606
URL: http://www.physics.umn.edu/~ttnguyen

[Visualpython-users] dir() for vPython objects

[Gregor L. <gl...@ao...>]

Hi!
I'm still a newbie in looking behind the scene.

When playing around with VPython I encountered the
following:

>>> from visual import *
Visual-2002-06-14
>>> s=3Dsphere() # beautiful white sphere displayed immediately
>>> s
<Primitive object at 0x01563D34>
>>> dir(s)
['__class__', 'axis', 'blue', 'color', 'constr',
 'display', 'frame', 'green', 'name', 'pos', 'radius',=20
'red', 'rotate', 'up', 'visible', 'x', 'y', 'z']
>>> s.__methods__
['rotate']
>>> s.__dict__
{'__class__': <built-in method sphere of tuple object at 0x00A65590>}
>>> s.__members__
['axis', 'blue', 'color', 'display', 'frame', 'green',=20
'pos', 'radius', 'red', 'up', 'visible', 'x', 'y', 'z']
>>> s.name
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in ?
    s.name
AttributeError: name
>>>=20

So, what are 'name' and 'constr', which both do not appear
neither in s.__members__ nor in s.__dict__ nor in s.__methods__,
but in the list returned by dir(s)?

(Or: what is generally returned by dir() ?)

Perhaps there is somebody who can explain this.=20

Thanks, Gregor

Re: [Visualpython-users] VPython compile problems - Mandrake 8.1

[Andy D. <dou...@la...>]

On Sun, 7 Jul 2002, rod holland wrote:

> To list:
> 
> I will start with a general explanation and provide more details later if
> needed.
> 
> 1. I am compiling on Mandrake 8.1
> 2. Python 2.2, Idle-Fork, and Numeric are installed and functioning
> 3. Two problems arise with installing VPython
> 	a. the gtkglarea.rpm installation process (from the install script) says
> it is already installed and then spits out a long list of database 	errors

Here, I can't help, since I'm unfamiliar with rpm packages and the
associated errors.

> - then the script continues to compilation of cvisual.
> 	b. the compilation of cvisual always ends in a seg fault - usually in
> vthread.h.

Could you send more specific info -- perhaps the last few lines of a build
log?  

> 2) commenting out the offending lines in the include files that generate
> seg faults
> 
> Neither work.  Are there any suggestions?

What are the offending lines?  What process is segfaulting -- is it
Python, gcc, ld, ... ?

-- 
    Andy Dougherty		dou...@la...
    Dept. of Physics
    Lafayette College, Easton PA 18042

Re: [Visualpython-users] mag2

[Bruce S. <bas...@un...>]

Yes, Will. Exactly. Change the magnitude (or magnitude squared) but keep 
the direction. so setting v.mag = 1 is the same as setting v = norm(v).

Bruce Sherwood

At 10:32 AM 02/07/08 -0400, William A. Chase wrote:
>Professor Sherwood,
>    I have a quick question about the mag/mag2 functionality that you
>explained where you can explicitly set the variable mag equal to a value.
>Does the syntax "v.mag = X" maintain the direction of the vector v, but
>setting it's magnitude to X? Say we perform the code:
>
>v = vector(5,10,15) #arbitrary direction & magnitutude
>v.mag = 1
>
>Would this make the vector v into a unit vector in the same direction?
>Just curious... Thanks a bundle!
>
>-- Will Chase
>Sophomore Astro Major
>CMU

Re: [Visualpython-users] mag2

[William A. C. <wc...@an...>]

Professor Sherwood,
   I have a quick question about the mag/mag2 functionality that you
explained where you can explicitly set the variable mag equal to a value.
Does the syntax "v.mag = X" maintain the direction of the vector v, but
setting it's magnitude to X? Say we perform the code:

v = vector(5,10,15) #arbitrary direction & magnitutude
v.mag = 1

Would this make the vector v into a unit vector in the same direction?
Just curious... Thanks a bundle!

-- Will Chase
Sophomore Astro Major
CMU

On Sun, 7 Jul 2002, Bruce Sherwood wrote:

> Thanks to Arthur Siegel for suggesting making the mag2 function available.
> This function for vectors gives the square of the magnitude of a vector:
>
> v = vector(1,2,3) # a vector whose magnitude is 14
> mag(v) or v.mag is sqrt(14)
> mag2(v) or v.mag2 is 14
>
> Not previously documented for mag, and now also available for mag2, is the
> possibility of setting the associated attribute for a vector:
>
> v.mag = 5 # make the magnitude of v be 5
> v.mag2 = 2.7 # make the square of the magnitude of v by 2.7
>
> At http://vpython.org there are new files associated with mag2:
> documentation, the visual folder, source, Windows DLL, and a full Windows
> installer. Haven't yet updated installers for Linux or Macintosh.
>
> Bruce Sherwood
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> We have stuff for geeks like you.
> http://thinkgeek.com/sf
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] VPython compile problems - Mandrake 8.1

[Bruce S. <bas...@un...>]

You've probably seen this note ("additional info" on the Linux download 
page), but just in case you missed it, here's a comment on getting VPython 
to work on Debian.

The VPython installation procedure should work on most versions of Red Hat
   Linux, and it may work in other Linux environments as well. If not, Andy 
Dougherty
   offers the following useful information.

Other packages you may need are commonly, but not universally, installed on
   many Linux systems. I can tell you that on my Debian system, I also 
needed to
   add glib, gtk+, and some sort of OpenGL library. You may need to check that
   you have the development versions of the libraries. [1]

VPython includes gtkglarea, but if you can't use the supplied i386 rpm [2]
   you may also need to install gtkglarea from source. If so, I'd recommend 
using
   the slightly-newer gtkglarea-1.2.3 -- it worked marginally better for me.

Where you get OpenGL may depend, in part, on which X server you're using. I'm
   currently trying Mesa as an OpenGL replacement, but with mixed success. The
   Visual window only seems to be updated occasionally; with the same 
program under
   Windows, the updating is nearly continuous. Hope this helps,

   Andy Dougherty
   Dept. of Physics
   Lafayette College
   Easton PA 18042

[1] For some libraries, some Linux distributions sometimes ship both runtime
   and development versions. You need the development version if you want 
to compile.

[2] e.g. if you don't have an rpm command, or if if you're running on a 
different
   architecture, such as an Alpha or SPARC.

Re: [Visualpython-users] VPython compile problems - Mandrake 8.1

[Andrew M. <mor...@ph...>]

On Sun, 2002-07-07 at 13:24, rod holland wrote:
> To list:
>=20
> I will start with a general explanation and provide more details later if
> needed.
>=20
> 1. I am compiling on Mandrake 8.1
> 2. Python 2.2, Idle-Fork, and Numeric are installed and functioning
> 3. Two problems arise with installing VPython
> 	a. the gtkglarea.rpm installation process (from the install script) says
> it is already installed and then spits out a long list of database 	error=
s
> - then the script continues to compilation of cvisual.
> 	b. the compilation of cvisual always ends in a seg fault - usually in
> vthread.h.
>=20
> What I have tried so far-
> 1) using the gtkglarea libs from the Mandrake disks and commenting out th=
e
> rpm process from the install script.
> 2) commenting out the offending lines in the include files that generate
> seg faults
>=20
> Neither work.  Are there any suggestions?
>=20
> Thanks,
>=20
> Rod
>=20

I have also had this problem.  I can't offer a solution, but I can add
that using the gtkglarea rpm from red-carpet (ximian) does not work,
either.  Tried uninstalling w/ red-carpet to allow the install script to
do its thing, also to no avail.  Rpm database seems to be intact, as I
tried --rebuilddb and met same end result.


Andrew =20

[Visualpython-users] mag2 for Linux

[Bruce S. <bas...@un...>]

The Linux installer has been updated to offer the mag2 function.

Bruce Sherwood

[Visualpython-users] mag2

[Bruce S. <bas...@un...>]

Thanks to Arthur Siegel for suggesting making the mag2 function available. 
This function for vectors gives the square of the magnitude of a vector:

v = vector(1,2,3) # a vector whose magnitude is 14
mag(v) or v.mag is sqrt(14)
mag2(v) or v.mag2 is 14

Not previously documented for mag, and now also available for mag2, is the 
possibility of setting the associated attribute for a vector:

v.mag = 5 # make the magnitude of v be 5
v.mag2 = 2.7 # make the square of the magnitude of v by 2.7

At http://vpython.org there are new files associated with mag2: 
documentation, the visual folder, source, Windows DLL, and a full Windows 
installer. Haven't yet updated installers for Linux or Macintosh.

Bruce Sherwood

[Visualpython-users] VPython compile problems - Mandrake 8.1

[rod h. <rh...@St...>]

To list:

I will start with a general explanation and provide more details later if
needed.

1. I am compiling on Mandrake 8.1
2. Python 2.2, Idle-Fork, and Numeric are installed and functioning
3. Two problems arise with installing VPython
	a. the gtkglarea.rpm installation process (from the install script) says
it is already installed and then spits out a long list of database 	errors
- then the script continues to compilation of cvisual.
	b. the compilation of cvisual always ends in a seg fault - usually in
vthread.h.

What I have tried so far-
1) using the gtkglarea libs from the Mandrake disks and commenting out the
rpm process from the install script.
2) commenting out the offending lines in the include files that generate
seg faults

Neither work.  Are there any suggestions?

Thanks,

Rod

RE: [Visualpython-users] disconnect between curve position and color

[Bruce S. <bas...@un...>]

Sounds like a good suggestion. One oddity is that curve.pos and curve.color 
are very similar to Numeric arrarys (but not the same as?). Numeric arrays 
don't permit slice deletion. But presumably Visual can do whatever it wants to?

Bruce Sherwood

At 05:29 PM 02/07/02 -0400, David Scherer wrote:
>Maybe slice deletion?
>
>c = curve(...)
>del c[:3]

RE: [Visualpython-users] disconnect between curve position and color

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

> What this does suggest is that what is missing is a method 
> for the curve 
> object which would let you specify how to slice the pos and 
> color lists in 
> the same way at the same time.

Maybe slice deletion?

c = curve(...)
del c[:3]

Re: [Visualpython-users] disconnect between curve position and color

[Bruce S. <bas...@un...>]

On second thought, I guess it isn't a bug, though there might be a missing 
feature. Here's the issue:

When you assign a new set of points trail.pos = trail.pos[1:], as far as 
Visual is concerned you could be assigning any completely new list, as in 
trail.pos = mylist. When the new assignment is noticed, Visual has no 
choice but to adjust the length of the trail.color list to be the same as 
the length of the trail.pos list. Visual doesn't know anything about the 
"1", just that a shorter list is being assigned to trail.pos. So it doesn't 
and can't do an intelligent job and delete the first slot in the color 
list; it arbitrarily deletes the last slot in the color list. You could 
argue that a better arbitrary guess would be to delete the first slot 
rather than the last, and I don't know where that would take us.

What this does suggest is that what is missing is a method for the curve 
object which would let you specify how to slice the pos and color lists in 
the same way at the same time.

Bruce Sherwood

At 10:36 PM 02/07/01 -0400, Bruce Sherwood wrote:
>This looks like a bug to me, and I'll try to see whether it can be fixed 
>(assuming it's a bug, not a feature!). Here is a workaround, though it is 
>a workaround that will do the wrong thing in the future if the bug is fixed:
>
>    trail.color[:-1] = trail.color[1:]  # move the colors down one slot to 
> compensate
>    trail.pos = trail.pos[1:]  # delete first slot in the position list
>
>Bruce Sherwood

Re: [Visualpython-users] disconnect between curve position and color

[Bruce S. <bas...@un...>]

This looks like a bug to me, and I'll try to see whether it can be fixed 
(assuming it's a bug, not a feature!). Here is a workaround, though it is a 
workaround that will do the wrong thing in the future if the bug is fixed:

    trail.color[:-1] = trail.color[1:]  # move the colors down one slot to 
compensate
    trail.pos = trail.pos[1:]  # delete first slot in the position list

Bruce Sherwood

At 02:20 PM 02/07/01 -0700, Bruce Peterson wrote:
>The VPython documentation discusses using the curve object to
>create trails for moving objects. The curve can also be used to record
>the history of an intrinsic parameter (such as temperature represented
>by object color) with code like:
>         obj.pos=newpos
>         obj.color=newcolor
>         trail.append(pos=newpos, color=newcolor)
>However if an abbreviated history is desired then the code
>         obj.pos=newpos
>         obj.color=newcolor
>         trail.append(pos=newpos, color=newcolor)
>         if len(trail.pos)>maxlen:
>                 trail.pos=trail.pos[1:]
>
>correctly truncates the curve length but incorrectly truncates the color.
>Internally the curve object appears to implement:
>
>                 if len(self.color)>len(self.pos):
>                         self.color=self.color[0:len(self.pos)-1]
>
>Is there any known way around this so that colors remain correctly associated
>with position?
>
>BTW storing position and color in a seperate list and replacing the entire
>list on each iteration rapidly goes into memory management meltdown - it
>works for small examples but rapidly dies with larger examples.
>
>
>Bruce Peterson
>Terastat, Inc
>Information Access Systems
>Voice (425) 466 7344
>Fax (206) 350 3685
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users

[Visualpython-users] disconnect between curve position and color

[Bruce P. <bap...@te...>]

The VPython documentation discusses using the curve object to
create trails for moving objects. The curve can also be used to record
the history of an intrinsic parameter (such as temperature represented
by object color) with code like:
         obj.pos=newpos
         obj.color=newcolor
         trail.append(pos=newpos, color=newcolor)
However if an abbreviated history is desired then the code
         obj.pos=newpos
         obj.color=newcolor
         trail.append(pos=newpos, color=newcolor)
         if len(trail.pos)>maxlen:
                 trail.pos=trail.pos[1:]

correctly truncates the curve length but incorrectly truncates the color.
Internally the curve object appears to implement:

                 if len(self.color)>len(self.pos):
                         self.color=self.color[0:len(self.pos)-1]

Is there any known way around this so that colors remain correctly associated
with position?

BTW storing position and color in a seperate list and replacing the entire
list on each iteration rapidly goes into memory management meltdown - it
works for small examples but rapidly dies with larger examples.


Bruce Peterson
Terastat, Inc
Information Access Systems
Voice (425) 466 7344
Fax (206) 350 3685

[Visualpython-users] cT archives

[Bruce S. <bas...@un...>]

For historical interest, archives of the cT programming language are now 
accessible at http://vpython.org, including C-language source code for the 
compiler and executor.

Bruce Sherwood

Re: [Visualpython-users] mag2()

[Bruce S. <bas...@un...>]

Absolutely! It was always the intention and hope that users would jump in 
with suggested improvements. So do please post your patch. Thanks.

Bruce Sherwood

At 11:08 AM 02/06/24 -0400, Arthur Siegel wrote:

>Bruce writes -
>
> > Sounds like a useful idea. I'll put this on a to-do list. >Thanks!
>
>And thanks for the response.  I do think that mag2 would be useful - a clue
>in fact being its utilization in the cvisual code. I can send along a small
>"patch" which exposes it to Python.
>
>Truth is I am first learning about extending Python via C++ by digging a bit
>into the cvisual code.  And am already doing other customizations.
>
>I would not like to have my (small) user base need to rely on my own
>"forked" cvisual - especially since my changes are likely to be minor and
>only add stuff, rather than change any existing functionality.
>
>I am therefore hoping that VPython can begin to come more of a collaborative
>Open Source project.
>
>That is someone like myself proposing a change *and* submitting a patch -
>with its acceptance opened up to discussion both as to the soundness of the
>feature  *and* its implementation.
>
>What you do think?
>
>Art

Re: [Visualpython-users] mag2()

[Arthur S. <aj...@ix...>]

Bruce writes -

> Sounds like a useful idea. I'll put this on a to-do list. >Thanks!

And thanks for the response.  I do think that mag2 would be useful - a clue
in fact being its utilization in the cvisual code. I can send along a small
"patch" which exposes it to Python.

Truth is I am first learning about extending Python via C++ by digging a bit
into the cvisual code.  And am already doing other customizations.

I would not like to have my (small) user base need to rely on my own
"forked" cvisual - especially since my changes are likely to be minor and
only add stuff, rather than change any existing functionality.

I am therefore hoping that VPython can begin to come more of a collaborative
Open Source project.

That is someone like myself proposing a change *and* submitting a patch -
with its acceptance opened up to discussion both as to the soundness of the
feature  *and* its implementation.

What you do think?

Art

Re: [Visualpython-users] mag2()

[Bruce S. <bas...@un...>]

Sounds like a useful idea. I'll put this on a to-do list. Thanks!

Bruce Sherwood

At 05:00 PM 02/06/22 -0400, Arthur Siegel wrote:
>I am refactoring some code, focusing on performance
>issues.
>
>And find it quite common in my code  to be calculating the squared
>length of a vector.
>
>A look at cvisual finds mag2() already there as the underlying function
>for mag(), but it is not exposed to Python.
>
>So in doing mag(vector)**2 I am essentially calculating a
>square root(in C) and then squaring it (in Python).  Unpretty.
>
>I did the trivial work to expose mag2 as a Python function, and
>am using it, and hoping the change could be made in the "official"
>distribution
>
>Art
>
>
>
>-------------------------------------------------------
>Sponsored by:
>ThinkGeek at http://www.ThinkGeek.com/
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users

[Visualpython-users] mag2()

[Arthur S. <aj...@ix...>]

I am refactoring some code, focusing on performance
issues.

And find it quite common in my code  to be calculating the squared
length of a vector.

A look at cvisual finds mag2() already there as the underlying function
for mag(), but it is not exposed to Python.  

So in doing mag(vector)**2 I am essentially calculating a
square root(in C) and then squaring it (in Python).  Unpretty.

I did the trivial work to expose mag2 as a Python function, and
am using it, and hoping the change could be made in the "official"
distribution

Art

RE: [Visualpython-users] rate() function

[Bruce S. <bas...@un...>]

Oops. I see I misread Dave Scherer's comment: 15 ms time slices have 
nothing to do with clock accuracy. The clock could be accurate to a 
microsecond yet with time slices allocated by Windows to processes with 15 
ms slop the clock accuracy is irrelevant.

Bruce Sherwood

At 11:22 AM 6/22/02 -0400, Bruce Sherwood wrote:
>The crux of the matter seems to be the question, what is the accuracy of 
>the Windows clock? On the Windows machine where I tried Gary's test 
>routine and saw the bizarre results he reported, I got 700 loop/sec with 
>no rate statement, which implies that one loop took 1.4 millisecond. If 
>the clock is accurate to microseconds, no problem. If the clock is 
>accurate to 15 ms (1/60 s?), it's hopeless.
>
>Bruce Sherwood
>
>At 03:45 PM 6/21/02 -0400, David Scherer wrote:
>>The time slices used by Windows are often on the
>>order of 15ms, which is quite a large margin of error in the type of
>>test you are doing.
>
>
>At 04:48 PM 6/21/02 -0400, Gary Strangman wrote:
>>Interestingly, replacing the rate() call in my previous program with a
>>spin-loop of the short you mentioned above (but based on time.clock(),
>>which on Windows is supposed to be accurate down to microseconds), I still
>>get the stair-stepping ...
>
>
>
>
>-------------------------------------------------------
>Sponsored by:
>ThinkGeek at http://www.ThinkGeek.com/
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users

RE: [Visualpython-users] rate() function

[Bruce S. <bas...@un...>]

The crux of the matter seems to be the question, what is the accuracy of 
the Windows clock? On the Windows machine where I tried Gary's test routine 
and saw the bizarre results he reported, I got 700 loop/sec with no rate 
statement, which implies that one loop took 1.4 millisecond. If the clock 
is accurate to microseconds, no problem. If the clock is accurate to 15 ms 
(1/60 s?), it's hopeless.

Bruce Sherwood

At 03:45 PM 6/21/02 -0400, you wrote:
>The time slices used by Windows are often on the
>order of 15ms, which is quite a large margin of error in the type of
>test you are doing.


At 04:48 PM 6/21/02 -0400, Gary Strangman wrote:
>Interestingly, replacing the rate() call in my previous program with a
>spin-loop of the short you mentioned above (but based on time.clock(),
>which on Windows is supposed to be accurate down to microseconds), I still
>get the stair-stepping ...