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-07-08 15:36:45
|
That's due to the change from Numeric, which is no longer supported, to numpy, which is. The VPython example program gas.py upon which this was probably based was rewritten to work either with Numeric or with numpy. Similarly, the example program stars.py (upon which nebula_20p.py might possibly be based) has also been revised in this way. Bruce Sherwood roberto wrote: > hello, > i downloaded the following demo files: gas-KE_07.py from > http://lurbano-5.memphis.edu/GeoMod/index.php/Main_Page > > and encountered this error > gas-KE_07.py", line 213, in <module> > r = pos-pos[:,NewAxis] # all pairs of atom-to-atom vectors > NameError: name 'NewAxis' is not defined > > also, the atoms do not move at all nor the slider is working > > the very same problem is in the code: nebula_20p.py > > if anyone has solved the issue, let me know > thank you in advance > > |
|
From: roberto <rob...@gm...> - 2009-07-08 08:02:43
|
hello, i downloaded the following demo files: gas-KE_07.py from http://lurbano-5.memphis.edu/GeoMod/index.php/Main_Page and encountered this error gas-KE_07.py", line 213, in <module> r = pos-pos[:,NewAxis] # all pairs of atom-to-atom vectors NameError: name 'NewAxis' is not defined also, the atoms do not move at all nor the slider is working the very same problem is in the code: nebula_20p.py if anyone has solved the issue, let me know thank you in advance -- roberto |
|
From: Bruce S. <Bru...@nc...> - 2009-07-08 04:13:15
|
A user reported a bug in the Windows installer of Visual 5.11 for Python 2.5, now fixed. It's interesting that it took this long to get this report, as the bug would have affected anyone trying to use the installer. Maybe few people are now using Python 2.5. Bruce Sherwood |
|
From: Bruce S. <Bru...@nc...> - 2009-07-07 03:03:52
|
Yet more corrections to the handling of arrows in povexport. It's just possible that arrows are now exported correctly in all cases, in that the code for shaftwidth, headwidth, and headlength now mimics as near as I can tell the Visual C++ code. Dunno why this has been so difficult for the several of us who have made repeated attempts! Available in the contributed section of vpython.org. Bruce Sherwood |
|
From: Bruce S. <Bru...@nc...> - 2009-07-06 05:39:45
|
Placing the camera in a particular position is not as simple as it probably ought to be. I think the reason that scene.mouse.camera is read-only has to do with synchronizations issues, but I'll admit to being a bit hazy on this issue. Here is a way to place the camera at a specific location, in this case (10,10,10): from visual import * box() d = vector(10,10,10) scene.forward = -norm(d) #scene.fov = pi/3 (the default fov) scene.range = mag(d)*tan(scene.fov/2) print scene.mouse.camera # not updated yet print scene.forward scene.mouse.getclick() print scene.mouse.camera # now shows <10,10,10> The key geometrical point is that scene.fov is the angle subtended by the scene, so the tangent of half of that angle is the range (recall that range=1 means the scene goes from -1 to +1). Bruce Sherwood |
|
From: Bruce S. <Bru...@nc...> - 2009-07-05 23:37: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"> I'm not sure this is an answer to your question, but have you looked at scene.fov (field of view)?<br> <br> Bruce Sherwood<br> <br> Chris Colbert wrote: <blockquote cite="mid:7f0...@ma..." type="cite">Hi,<br> <br> I've searched around and in the docs and haven't found an answer to this.<br> <br> I'm thinking of using Vpython to simulate models for 3d reconstruction from 2d views. That is, I will create the 3d shape, and then take several 2d images of it in order to test reconstruction algorithms. <br> <br> To do this, I need to know the camera position and orientation, and its focal length. The first two (position and orientation) are no problem. I haven't seen anything on the third (focal length). I'm assuming that the camera position is actually the focal point, so is there a way to determine (or better, specify) the offset of the image plane from the camera location (focal point)? <br> <br> Thanks for any help,<br> <br> Chris<br> <br> <br> <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: Chris C. <scc...@gm...> - 2009-07-05 21:18:59
|
Hi, I've searched around and in the docs and haven't found an answer to this. I'm thinking of using Vpython to simulate models for 3d reconstruction from 2d views. That is, I will create the 3d shape, and then take several 2d images of it in order to test reconstruction algorithms. To do this, I need to know the camera position and orientation, and its focal length. The first two (position and orientation) are no problem. I haven't seen anything on the third (focal length). I'm assuming that the camera position is actually the focal point, so is there a way to determine (or better, specify) the offset of the image plane from the camera location (focal point)? Thanks for any help, Chris |
|
From: Bruce S. <Bru...@nc...> - 2009-07-03 16:17: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">
I checked the Mac, and it behaves correctly, like Windows. It's only
Linux that doesn't, and I don't know why.<br>
<br>
I think you're right that the thing to do is to expose the same method
that is driven by clicking on the close box. I might not get to this
very soon, as I'm swamped getting out the third edition of a physics
textbook on a tight deadline.<br>
<br>
I don't know enough about GTK widgets to be able to comment on whether
your suggestion about widgets is feasible.<br>
<br>
Bruce Sherwood<br>
<br>
Michele Mattioni wrote:
<blockquote
cite="mid:290...@ma..."
type="cite">
<pre wrap="">On Fri, Jul 3, 2009 at 5:49 AM, Bruce Sherwood<a class="moz-txt-link-rfc2396E" href="mailto:Bru...@nc..."><Bru...@nc...></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">What platform are you running on?
I find that on Windows this does work properly running from a command
line. The C++ code does intend to exit the program if we reach the end
of the program and there are no windows visible. However, for some
reason exit doesn't happen on Ubuntu Linux. I didn't yet try on the Mac.
</pre>
</blockquote>
<pre wrap=""><!---->
I'm running Ubuntu Jaunty.
</pre>
<blockquote type="cite">
<pre wrap="">It also does not exit on Windows when running from VIDLE or IDLE, maybe
because in the shell window you can still execute statements, such as
scene.visible = True, so you're not really at the end of the program.
Clearly we need some statement that unequivocally kills the program.
</pre>
</blockquote>
<pre wrap=""><!---->
I need to exit programmatically from the visual and close the window.
I'm using visual together with another main GUI window, so when I
close the main also visual should close properly.
When I click on the x in the right corner of the window the program
closes in a proper way, so why we don't expose the same method to the
python interface?
<a class="moz-txt-link-freetext" href="http://visualpython.cvs.sourceforge.net/viewvc/visualpython/vpython-core2/src/gtk2/display.cpp?revision=1.57&view=markup">http://visualpython.cvs.sourceforge.net/viewvc/visualpython/vpython-core2/src/gtk2/display.cpp?revision=1.57&view=markup</a>
I think the method attached with the on_quit_clicked() (line 240)
should do the work.. we can give it a try.
On a side note making visual a GtkWidget Visual window would give much
more control, a nice integration within the gtk main loop, and more
sane event handling.
Do you think it is a good idea?
Regards,
Michele
P.S.: The application is this one: <a class="moz-txt-link-freetext" href="http://mattions.github.com/neuronvisio/">http://mattions.github.com/neuronvisio/</a>
</pre>
<blockquote type="cite">
<pre wrap="">Bruce Sherwood
Michele Mattioni wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello list,
I'm trying to figure out how to close visual from the code and not
from the GUI, 'cause I need this feature.
Consider the following code:
import visual
import time
scene = visual.display()
cyl = visual.cylinder()
time.sleep(3)
scene.visible = False
if you run it with
python test.py
the command line keeps to be busy and the prompt never show up.
This does not happen if I click on the x on top of the gui.
I'm missing some bit?
Regards,
Michele.
------------------------------------------------------------------------------
_______________________________________________
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>
<pre wrap="">------------------------------------------------------------------------------
_______________________________________________
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>
</blockquote>
</body>
</html>
|
|
From: Kadir H. <kha...@ya...> - 2009-07-03 10:37:14
|
Hello All,
Inspired by Bruce's notification on the demo, I perpared a quick Vpython version for the windmills part of it.
I used PyAudio to capture mic input and used it to control head axis, and rotation speed.
My laptop has a mono built-in mic, so I can only see the blades rotation. If you have a stereo built-in mic, I believe you should see both.
I did not elaborate on using a web-cam's mic for stereo input since I could not see any support for it by PyAudio, and I did not want to go into details of
wave library and WinMM api.
The video part is more tricky of course. It needs a lot more work on image processing, and also some new capabilities on VPython side, to paint the background with a live video image, rather than a plane color, as it is today, which is well beyond my scope.
Start the application, and just talk to the screen ( the mic)...
Kadir
# ecoMILLs in VPython
from visual import *
import pyaudio
import sys
from array import array
###### Set the Scene
scene.autocenter = 0
scene.center = (0,10,0)
scene.range = 20
scene.autoscale = 0
scene.width = 1024
scene.height = 768
scene.title = "ecoMILLs"
field = box(size=(50,1,50), color=(0,1,0))
###### Prepare Audio
threshold = 200
maxValue = 0
chunk = 2048
FORMAT = pyaudio.paInt16
CHANNELS = 2
RATE = 44100
RECORD_SECONDS = 1
p = pyaudio.PyAudio()
stream = p.open(format = FORMAT,
channels = CHANNELS,
rate = RATE,
input = True,
output = True,
frames_per_buffer = chunk)
######### Setup a windmill
class WindMill():
def __init__(self, offset=(0,0,0), color1=(1,0,0), color2=(1,1,0),
color3=(0,0,1)):
self.wndml = frame(pos=offset)
self.head = frame(frame=self.wndml)
self.wings = frame(frame=self.head)
self.pole = cone(frame=self.wndml, radius=0.5, axis=(0,10,0))
self.dyno1 = cone(frame=self.head, pos=self.pole.axis-(0,0,1), radius=0.5,
axis=(0,0,-1))
self.dyno2 = cylinder(frame=self.head, pos=self.pole.axis-(0,0,1),
radius=0.5, axis=(0,0,1))
self.bld1 = pyramid(frame=self.wings, pos=self.pole.axis+(0,2.5,0),
size=(0.5, 5.0, 0.05), color=color1)
self.bld2 = pyramid(frame=self.wings, pos=self.pole.axis+(0,2.5,0),
size=(0.5, 5.0, 0.05), color=color2)
self.bld2.rotate(axis=(0,0,1), angle=pi*2/3, origin=self.pole.axis)
self.bld3 = pyramid(frame=self.wings, pos=self.pole.axis+(0,2.5,0),
size=(0.5, 5.0, 0.05), color=color3)
self.bld3.rotate(axis=(0,0,1), angle=-pi*2/3, origin=self.pole.axis)
self.shaft = cylinder(frame=self.wings, pos=self.pole.axis, radius=0.1,
axis=(0,0,0.1), color=(0.4,0.4,0.4))
axis = (1,0,0)
self.rotate_wings(pi/5+random.uniform(-pi/4,+pi/4))
def rotate_head(self, axis):
self.head.axis = axis
rotang = pi/64.0
def rotate_wings(self, rotang):
self.wings.rotate(axis=self.dyno1.axis, origin=self.pole.axis,
angle=rotang)
##### Create WindMills
mills = []
mill1 = WindMill()
mill2 = WindMill((10,0,3), color1=(0,1,0), color2=(0,1,1), color3=(1,0,1))
mill3 = WindMill((-10,0,3), color1=(1,1,1), color2=(1,1,0), color3=(1,0,0))
mills.append(mill1)
mills.append(mill2)
mills.append(mill3)
left = 1
right = 1
headax = (1,0,0)
rotang = pi/64.
while left >0 or right > 0:
for i in range(0, 44100 / chunk * RECORD_SECONDS):
data = stream.read(chunk)
asInts = array('h', data)
for j in range(0,len(asInts),2):
left += asInts[j]
right += asInts[j+1]
if left > threshold or right > threshold:
headax = ((1,0,1-(right/left)))
rotang = pi/64 + (pi/64)*(left+right)/10000
for mill in mills:
mill.rotate_head(headax)
mill.rotate_wings(rotang)
left = 1
right = 1
stream.stop_stream()
stream.close()
p.terminate()
________________________________
From: Bruce Sherwood <Bru...@nc...>
To: VPython <vis...@li...>
Sent: Tuesday, June 30, 2009 8:03:28 AM
Subject: [Visualpython-users] Very cool 3D demo
Fans of 3D, you might find this as intriguing as I did:
http://ge.ecomagination.com/smartgrid/#/augmented_reality
Print the "Solar Panel Marker"
page, then follow the rest of the instructions on the page.
You need to have a webcam on your computer; the webcam views the
special page that you print and follows the page as you move it around,
thereby giving you navigation in the 3D scene.
Bruce Sherwood
|
|
From: Michele M. <mat...@gm...> - 2009-07-03 08:34:26
|
On Fri, Jul 3, 2009 at 5:49 AM, Bruce Sherwood<Bru...@nc...> wrote: > What platform are you running on? > > I find that on Windows this does work properly running from a command > line. The C++ code does intend to exit the program if we reach the end > of the program and there are no windows visible. However, for some > reason exit doesn't happen on Ubuntu Linux. I didn't yet try on the Mac. > I'm running Ubuntu Jaunty. > It also does not exit on Windows when running from VIDLE or IDLE, maybe > because in the shell window you can still execute statements, such as > scene.visible = True, so you're not really at the end of the program. > Clearly we need some statement that unequivocally kills the program. > I need to exit programmatically from the visual and close the window. I'm using visual together with another main GUI window, so when I close the main also visual should close properly. When I click on the x in the right corner of the window the program closes in a proper way, so why we don't expose the same method to the python interface? http://visualpython.cvs.sourceforge.net/viewvc/visualpython/vpython-core2/src/gtk2/display.cpp?revision=1.57&view=markup I think the method attached with the on_quit_clicked() (line 240) should do the work.. we can give it a try. On a side note making visual a GtkWidget Visual window would give much more control, a nice integration within the gtk main loop, and more sane event handling. Do you think it is a good idea? Regards, Michele P.S.: The application is this one: http://mattions.github.com/neuronvisio/ > Bruce Sherwood > > Michele Mattioni wrote: >> Hello list, >> >> I'm trying to figure out how to close visual from the code and not >> from the GUI, 'cause I need this feature. >> >> Consider the following code: >> >> >> import visual >> import time >> scene = visual.display() >> cyl = visual.cylinder() >> time.sleep(3) >> scene.visible = False >> >> >> if you run it with >> >> python test.py >> >> the command line keeps to be busy and the prompt never show up. >> This does not happen if I click on the x on top of the gui. >> >> I'm missing some bit? >> >> Regards, >> Michele. >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Visualpython-users mailing list >> Vis...@li... >> https://lists.sourceforge.net/lists/listinfo/visualpython-users >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users > |
|
From: Bruce S. <Bru...@nc...> - 2009-07-03 05:44:51
|
A somewhat distinctive feature of VPython is that there is no exit when you reach the end of a program such as from visual import * sphere() The reason of course is that you may be viewing the scene and spinning or zooming. However, as you imply, if your program has finished and there is no scene to be viewed, VPython should exit. A separate issue is how to programmatically exit a program. I thought there was a way using sys.exit(), but that doesn't work (doesn't seem to work in Visual 3, either). Bruce Sherwood Michele Mattioni wrote: > Hello list, > > I'm trying to figure out how to close visual from the code and not > from the GUI, 'cause I need this feature. > > Consider the following code: > > > import visual > import time > scene = visual.display() > cyl = visual.cylinder() > time.sleep(3) > scene.visible = False > > > if you run it with > > python test.py > > the command line keeps to be busy and the prompt never show up. > This does not happen if I click on the x on top of the gui. > > I'm missing some bit? > > Regards, > Michele. > > ------------------------------------------------------------------------------ > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users > |
|
From: Bruce S. <Bru...@nc...> - 2009-07-03 04:49:43
|
What platform are you running on? I find that on Windows this does work properly running from a command line. The C++ code does intend to exit the program if we reach the end of the program and there are no windows visible. However, for some reason exit doesn't happen on Ubuntu Linux. I didn't yet try on the Mac. It also does not exit on Windows when running from VIDLE or IDLE, maybe because in the shell window you can still execute statements, such as scene.visible = True, so you're not really at the end of the program. Clearly we need some statement that unequivocally kills the program. Bruce Sherwood Michele Mattioni wrote: > Hello list, > > I'm trying to figure out how to close visual from the code and not > from the GUI, 'cause I need this feature. > > Consider the following code: > > > import visual > import time > scene = visual.display() > cyl = visual.cylinder() > time.sleep(3) > scene.visible = False > > > if you run it with > > python test.py > > the command line keeps to be busy and the prompt never show up. > This does not happen if I click on the x on top of the gui. > > I'm missing some bit? > > Regards, > Michele. > > ------------------------------------------------------------------------------ > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users > |
|
From: Aaron M. <ajm...@al...> - 2009-07-02 19:32:47
|
Ah, yes... I just found a recent post and related info in site_settings.py that enable me to disable the shaders. Sorry for the bother, Aaron ------------------------------------------------------ Aaron J. Miller, Ph.D. Department of Physics 328 Palenske Hall Albion College, Albion, MI 49224 ajm...@al... 517-629-0684 phone 517-629-0264 fax |
|
From: Aaron M. <ajm...@al...> - 2009-07-02 19:32:24
|
Hello VPython Folks, As I work toward a greater implementation of using VPython in my courses this fall, I have run into some trouble with the new rendering engine. We have ~35 <1yr old Tablet PCs that will be used in class and in lab and I am working on developing vpython exercises and demos along these lines. I have found that the tablets seem to have no pixel shader rendering in hardware, so under the new vpython 5 (Python 2.6.2, VPython 2.6-5.11), my simulations are extremely slow (few frames per second instead of >15). Although I don't know what units the measurement is in, if I set the show_rendertime property of the scene to True I see "cycle" reported in the 200s and "render" around 70. If I subsequently set the enable_shaders property to False, everything works just like with previous versions of vpython and the "cycle" changes to ~40 and "render" to 6 or 7. Furthermore, with the shaders enabled pythonw crashes on closing the display window, whereas disabled pythonw closes just fine. So, here is my question: For now, I think it best for me to disable shaders by default, so students don't have to deal with this in their code. Where is the best place to put the command to disable these shaders? Thank you, Aaron ------------------------------------------------------ Aaron J. Miller, Ph.D. Department of Physics 328 Palenske Hall Albion College, Albion, MI 49224 ajm...@al... 517-629-0684 phone 517-629-0264 fax |
|
From: Michele M. <mat...@gm...> - 2009-07-02 13:25:56
|
Hello list, I'm trying to figure out how to close visual from the code and not from the GUI, 'cause I need this feature. Consider the following code: import visual import time scene = visual.display() cyl = visual.cylinder() time.sleep(3) scene.visible = False if you run it with python test.py the command line keeps to be busy and the prompt never show up. This does not happen if I click on the x on top of the gui. I'm missing some bit? Regards, Michele. |
|
From: Bruce S. <Bru...@nc...> - 2009-06-30 17:12:55
|
<!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">
Thanks for the elegant commentary, Craig. Because I too work with large
numbers of naive users, in particular including teachers and students,
this is precisely my concern and experience as well, but you've said it
better than I could.<br>
<br>
At the same time, we want Visual to be useful to and usable by power
users, and I'm glad that Guy Kloss has raised the issues, and happy to
see the constructive discussions that are under way. Your choice of
"visual.core" is exactly the same name that Dave Scherer, the
originator of Visual, suggested when I talked recently with him about
these issues. He too is in favor of cleaning the space, but with
caution. One possible approach is to import very few essential things
from the very large numpy module, but probably all of the much smaller
math module (though even there one should look carefully); the point of
including the math module is that you can hardly do anything with
Visual without sines and cosines and square roots. He also suggested a
factoring that would include "visual.math" (which would perform the
magic needed to get good performance out of choosing the math sqrt
instead of the numpy sqrt when possible).<br>
<br>
I'm strongly against eliminating numpy from the Windows and Mac
installers. We found experimentally that even college students majoring
in engineering and science fairly frequently have difficulties with a
two-part installation (Python and Visual), and there have been serious
questions about the advisability of a one-part installer for novices. A
three-part installation would be 50% worse than the current situation.
Linux is a different beast, and there the dependencies can be taken
care of by the package manager, if someone makes a Visual package for a
particular distribution.<br>
<br>
I'll mention that you'll see in __init__.py the following:<br>
# Names defined for backward compatibility with Visual 3:<br>
import sys, time<br>
true = True<br>
false = False<br>
We shouldn't be importing sys and time; the last time this issue was
visited, there were fears of introducing incompatibilities, but I'm not
sure how valid those particular fears were.<br>
<br>
Bruce Sherwood<br>
<br>
Craig Struble wrote:
<blockquote
cite="mid:C43...@ma..."
type="cite">
<pre wrap="">I want to echo Bruce's request for careful thought in this process.
Changing the API to be more Pythonesque and changing the distribution
to using a more ideal dependency structure may have certain aesthetic
and large scale advantages, but I fear they would be hurdles that
would prevent larger adoption.
Having just taught a 3-day workshop on computational thinking using
Python and VPython to high school science teachers, who have never
used Python or VPython before, the current simple to use import
behavior was essential to getting them to begin writing their own
simulations in a short period of time. Our goal was to have the
teachers focus on the science they wanted to teach, not to master
Python's language or namespaces. Every additional line of code needed
to get a simple simulation running is a very large penalty to many
users.
My main point is that there needs to be an option in the mix that
maintains the simplicity both in imports and in distribution. I also
thought, as a Gary suggested, that a namespace such as
from visual.core import *
(instead of visual.visual, which is a confusing name) would be a
reasonable transition from the current behavior to something more in
line with good Python practice. So
from visual import *
could import everything into a single namespace and let the other
modules be better suited for developers needing more control. The
visual.graph module would probably need some refactoring to act more
like a proper Python module that doesn't pollute namespaces, but then
there would be more consistency in behavior. (The current behavior of
visual.graph is a little confusing to explain.) Gary's other
suggestion about visual.all is also reasonable.
Craig
On Jun 30, 2009, at 8:07 AM, Gary Ruben wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Guy K. Kloss wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, 30 Jun 2009 00:15:09 Gary Ruben wrote:
</pre>
<blockquote type="cite">
<pre wrap="">would
adding another namespace within visual provide the best of both
worlds -
that way one might do something like
"from visual.visual import *"
instead of "from visual import *"
if you just want the visual module without the other imports?
</pre>
</blockquote>
<pre wrap="">Since when is obfuscation helpful?
</pre>
</blockquote>
<pre wrap="">OK, I don't deny that this is probably not the best idea.
I should clarify myself. Personally, I would be more than happy for
vpython to be changed to remove the wholesale namespace importation -
this would be a forward step. I think what you propose is a good
course
of action. However, since Bruce suggested that there is careful
thought
behind the current operation, I'm just wondering whether Python
permits
you to *not* do this via an admittedly less-than-ideal mechanism like
that which I suggested. Alternatively, not knowing the full thinking
behind the current behaviour, what do you think of following through
with your suggestion for 6.x, and maybe providing a subordinate
namespace (dare I say like visual.visual or visual.all) that does the
full environment setup, presumably to simplify use of vpython in a
teaching environment.
While I'm at it, I'd like to see numpy removed completely from the
installer - I think it's mature enough and a slow enough moving target
to be made a dependency instead.
</pre>
<blockquote type="cite">
<pre wrap="">BTW, I am *not* intending to aim at breaking compatibility for the
5.x release
series. I am aiming at hinting towards refining the API for maybe a
future 6.x
series. And I am intending to hint towards that in the spirit of
Python, which
is well established and it is what made the language as popular as
it is
today. These suggestions go fully conform with "The Zen of
Python" (see below,
you get it when typing "import this" in the interactive Python
shell).
In my opinion a refinement of the API in that direction for future
release
series would already touch 5 of the Zen of Python statements, and
therefore
largely serve the usability in Python at the little expense of
having to adapt
with the switch over from 5.x to 6.0"
</pre>
</blockquote>
<pre wrap=""><snip>
Gary
------------------------------------------------------------------------------
_______________________________________________
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>
<pre wrap=""><!---->
--
Craig A. Struble, Ph.D. | 369 Cudahy Hall | Marquette University
Associate Professor of Computer Science | (414)288-3783
Director, Master of Bioinformatics Program | (414)288-5472 (fax)
<a class="moz-txt-link-freetext" href="http://www.mscs.mu.edu/~cstruble">http://www.mscs.mu.edu/~cstruble</a> | <a class="moz-txt-link-abbreviated" href="mailto:cra...@ma...">cra...@ma...</a>
------------------------------------------------------------------------------
_______________________________________________
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: James M. <mu...@pi...> - 2009-06-30 15:41:53
|
As an example, matplotlib has already done something like this. The old syntax was from pylab import * which also imported numpy, resulting in a very polluted namespace. They now suggest from matplotlib import pyplot as plt which deals with namespaces in a much more sensible way. They also re- implemented the pylab import such that it consists of an import of pyplot and numpy, so old code (and coders) can have their old code work as it did before. -Jim On Jun 30, 2009, at 9:07 AM, Gary Ruben wrote: > Guy K. Kloss wrote: >> On Tue, 30 Jun 2009 00:15:09 Gary Ruben wrote: >>> would >>> adding another namespace within visual provide the best of both >>> worlds - >>> that way one might do something like >>> "from visual.visual import *" >>> instead of "from visual import *" >>> if you just want the visual module without the other imports? >> >> Since when is obfuscation helpful? > > OK, I don't deny that this is probably not the best idea. > > I should clarify myself. Personally, I would be more than happy for > vpython to be changed to remove the wholesale namespace importation - > this would be a forward step. I think what you propose is a good > course > of action. However, since Bruce suggested that there is careful > thought > behind the current operation, I'm just wondering whether Python > permits > you to *not* do this via an admittedly less-than-ideal mechanism like > that which I suggested. Alternatively, not knowing the full thinking > behind the current behaviour, what do you think of following through > with your suggestion for 6.x, and maybe providing a subordinate > namespace (dare I say like visual.visual or visual.all) that does the > full environment setup, presumably to simplify use of vpython in a > teaching environment. > > While I'm at it, I'd like to see numpy removed completely from the > installer - I think it's mature enough and a slow enough moving target > to be made a dependency instead. > >> BTW, I am *not* intending to aim at breaking compatibility for the >> 5.x release >> series. I am aiming at hinting towards refining the API for maybe a >> future 6.x >> series. And I am intending to hint towards that in the spirit of >> Python, which >> is well established and it is what made the language as popular as >> it is >> today. These suggestions go fully conform with "The Zen of >> Python" (see below, >> you get it when typing "import this" in the interactive Python >> shell). >> >> In my opinion a refinement of the API in that direction for future >> release >> series would already touch 5 of the Zen of Python statements, and >> therefore >> largely serve the usability in Python at the little expense of >> having to adapt >> with the switch over from 5.x to 6.0" > <snip> > > Gary > > ------------------------------------------------------------------------------ > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users |
|
From: Craig S. <cra...@ma...> - 2009-06-30 15:26:57
|
I want to echo Bruce's request for careful thought in this process.
Changing the API to be more Pythonesque and changing the distribution
to using a more ideal dependency structure may have certain aesthetic
and large scale advantages, but I fear they would be hurdles that
would prevent larger adoption.
Having just taught a 3-day workshop on computational thinking using
Python and VPython to high school science teachers, who have never
used Python or VPython before, the current simple to use import
behavior was essential to getting them to begin writing their own
simulations in a short period of time. Our goal was to have the
teachers focus on the science they wanted to teach, not to master
Python's language or namespaces. Every additional line of code needed
to get a simple simulation running is a very large penalty to many
users.
My main point is that there needs to be an option in the mix that
maintains the simplicity both in imports and in distribution. I also
thought, as a Gary suggested, that a namespace such as
from visual.core import *
(instead of visual.visual, which is a confusing name) would be a
reasonable transition from the current behavior to something more in
line with good Python practice. So
from visual import *
could import everything into a single namespace and let the other
modules be better suited for developers needing more control. The
visual.graph module would probably need some refactoring to act more
like a proper Python module that doesn't pollute namespaces, but then
there would be more consistency in behavior. (The current behavior of
visual.graph is a little confusing to explain.) Gary's other
suggestion about visual.all is also reasonable.
Craig
On Jun 30, 2009, at 8:07 AM, Gary Ruben wrote:
> Guy K. Kloss wrote:
>> On Tue, 30 Jun 2009 00:15:09 Gary Ruben wrote:
>>> would
>>> adding another namespace within visual provide the best of both
>>> worlds -
>>> that way one might do something like
>>> "from visual.visual import *"
>>> instead of "from visual import *"
>>> if you just want the visual module without the other imports?
>>
>> Since when is obfuscation helpful?
>
> OK, I don't deny that this is probably not the best idea.
>
> I should clarify myself. Personally, I would be more than happy for
> vpython to be changed to remove the wholesale namespace importation -
> this would be a forward step. I think what you propose is a good
> course
> of action. However, since Bruce suggested that there is careful
> thought
> behind the current operation, I'm just wondering whether Python
> permits
> you to *not* do this via an admittedly less-than-ideal mechanism like
> that which I suggested. Alternatively, not knowing the full thinking
> behind the current behaviour, what do you think of following through
> with your suggestion for 6.x, and maybe providing a subordinate
> namespace (dare I say like visual.visual or visual.all) that does the
> full environment setup, presumably to simplify use of vpython in a
> teaching environment.
>
> While I'm at it, I'd like to see numpy removed completely from the
> installer - I think it's mature enough and a slow enough moving target
> to be made a dependency instead.
>
>> BTW, I am *not* intending to aim at breaking compatibility for the
>> 5.x release
>> series. I am aiming at hinting towards refining the API for maybe a
>> future 6.x
>> series. And I am intending to hint towards that in the spirit of
>> Python, which
>> is well established and it is what made the language as popular as
>> it is
>> today. These suggestions go fully conform with "The Zen of
>> Python" (see below,
>> you get it when typing "import this" in the interactive Python
>> shell).
>>
>> In my opinion a refinement of the API in that direction for future
>> release
>> series would already touch 5 of the Zen of Python statements, and
>> therefore
>> largely serve the usability in Python at the little expense of
>> having to adapt
>> with the switch over from 5.x to 6.0"
> <snip>
>
> Gary
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
--
Craig A. Struble, Ph.D. | 369 Cudahy Hall | Marquette University
Associate Professor of Computer Science | (414)288-3783
Director, Master of Bioinformatics Program | (414)288-5472 (fax)
http://www.mscs.mu.edu/~cstruble | cra...@ma...
|
|
From: Gary R. <gr...@bi...> - 2009-06-30 14:53:09
|
Guy K. Kloss wrote: > On Tue, 30 Jun 2009 00:15:09 Gary Ruben wrote: >> would >> adding another namespace within visual provide the best of both worlds - >> that way one might do something like >> "from visual.visual import *" >> instead of "from visual import *" >> if you just want the visual module without the other imports? > > Since when is obfuscation helpful? OK, I don't deny that this is probably not the best idea. I should clarify myself. Personally, I would be more than happy for vpython to be changed to remove the wholesale namespace importation - this would be a forward step. I think what you propose is a good course of action. However, since Bruce suggested that there is careful thought behind the current operation, I'm just wondering whether Python permits you to *not* do this via an admittedly less-than-ideal mechanism like that which I suggested. Alternatively, not knowing the full thinking behind the current behaviour, what do you think of following through with your suggestion for 6.x, and maybe providing a subordinate namespace (dare I say like visual.visual or visual.all) that does the full environment setup, presumably to simplify use of vpython in a teaching environment. While I'm at it, I'd like to see numpy removed completely from the installer - I think it's mature enough and a slow enough moving target to be made a dependency instead. > BTW, I am *not* intending to aim at breaking compatibility for the 5.x release > series. I am aiming at hinting towards refining the API for maybe a future 6.x > series. And I am intending to hint towards that in the spirit of Python, which > is well established and it is what made the language as popular as it is > today. These suggestions go fully conform with "The Zen of Python" (see below, > you get it when typing "import this" in the interactive Python shell). > > In my opinion a refinement of the API in that direction for future release > series would already touch 5 of the Zen of Python statements, and therefore > largely serve the usability in Python at the little expense of having to adapt > with the switch over from 5.x to 6.0" <snip> Gary |
|
From: Bruce S. <Bru...@nc...> - 2009-06-30 05:04:25
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> Fans of 3D, you might find this as intriguing as I did:<br> <br> <a href="http://ge.ecomagination.com/smartgrid/#/augmented_reality" _base_href="data:">http://ge.ecomagination.com/smartgrid/#/augmented_reality</a> <div style="font-family: Helvetica; font-size: 16px; color: black; text-align: left;"><br class="webkit-block-placeholder"> </div> <div style="font-family: Helvetica; font-size: 16px; color: black; text-align: left;"><font face="Times New Roman, Times, serif">Print the "Solar Panel Marker" page, then follow the rest of the instructions on the page.<br> <br> You need to have a webcam on your computer; the webcam views the special page that you print and follows the page as you move it around, thereby giving you navigation in the 3D scene.<br> <br> Bruce Sherwood<br> <br> </font></div> </body> </html> |
|
From: Guy K. K. <g....@ma...> - 2009-06-29 22:55:23
|
On Tue, 30 Jun 2009 09:36:14 Bruce Sherwood wrote: > I should go through all the docs and change 1/0 to True/False. The history > is that in 2000 Python didn't have True/False. At some point Scherer > implemented true=1 and false=0, but the documentation didn't exploit this. > And then even later True/False got added to Python; I don't remember when > that happened. True and False were added as built in constants in Python 2.3: http://docs.python.org/library/constants.html -- 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 21:36:14
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Makes sense; thanks. I considered saying something about del but for no
good reason didn't. <br>
<br>
I should go through all the docs and change 1/0 to True/False. The
history is that in 2000 Python didn't have True/False. At some point
Scherer implemented true=1 and false=0, but the documentation didn't
exploit this. And then even later True/False got added to Python; I
don't remember when that happened.<br>
<br>
Bruce Sherwood<br>
<br>
Guy K. Kloss wrote:
<blockquote cite="mid:200...@ma..."
type="cite">
<pre wrap="">On Mon, 29 Jun 2009 11:28:22 Bruce Sherwood wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
</blockquote>
</body>
</html>
|
|
From: Guy K. K. <g....@ma...> - 2009-06-29 19:46:21
|
On Tue, 30 Jun 2009 00:15:09 Gary Ruben wrote: > would > adding another namespace within visual provide the best of both worlds - > that way one might do something like > "from visual.visual import *" > instead of "from visual import *" > if you just want the visual module without the other imports? Since when is obfuscation helpful? BTW, I am *not* intending to aim at breaking compatibility for the 5.x release series. I am aiming at hinting towards refining the API for maybe a future 6.x series. And I am intending to hint towards that in the spirit of Python, which is well established and it is what made the language as popular as it is today. These suggestions go fully conform with "The Zen of Python" (see below, you get it when typing "import this" in the interactive Python shell). In my opinion a refinement of the API in that direction for future release series would already touch 5 of the Zen of Python statements, and therefore largely serve the usability in Python at the little expense of having to adapt with the switch over from 5.x to 6.0" * Namespaces are one honking great idea -- let's do more of those! * Readability counts. * Special cases aren't special enough to break the rules. * In the face of ambiguity, refuse the temptation to guess. * There should be one-- and preferably only one --obvious way to do it. And it's not rocket science. I've patched the original sources within 30 minutes, and it's been quite helpful for me. As a proof of concept attached with a warning, that might also help others, I have provided these packages. So beware, they *will* break the common use and all examples, but they do retain the 5.x API. Guy In [32]: import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! -- 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: Gary R. <gr...@bi...> - 2009-06-29 15:11:55
|
Just to add another voice to this discussion, rather than prevent the import of numpy and math, which breaks backward compatibility, would adding another namespace within visual provide the best of both worlds - that way one might do something like "from visual.visual import *" instead of "from visual import *" if you just want the visual module without the other imports? Gary R. |
|
From: Guy K. K. <g....@ma...> - 2009-06-29 07:07:50
|
BTW, I have added a warning to the wiki page on the modified version to clarify the difference between the two versions. On Mon, 29 Jun 2009 18:25:28 Bruce Sherwood wrote: > 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. I can understand this point of view. That's why it's vital to keep the API frozen on a major release series (5.x). > 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. But those distinctions happen in module space of the visual module, not on the user level. What the user gets is just a cluttered mix and mash of functions with overlapping name spaces. There's nothing wrong in keeping this distinction for speed up under the bonnet of the module (which is what I have done in the modification, too). The aim is just to give the user a *predictable* experience for future versions, which is not guaranteed if a module messes with the name spaces from other modules that are not obviously related. The modifications I have provided are (A) for my own sanity, and might (B) be used as a basis for future development towards a 6.x release series of VPython. I just wanted to be *nice* by offering that stuff to others as well, who've been bitten by the polluted name space. BTW, have you ever tried to familiarise yourself with a new module/package by using IPython interactively? It's quite neat, as it offers tab completion to find potential good candidates for something. This has bitterly failed using the default visual module, as it is just cluttered by 100s of members that have got nothing obvious to do with VPython, but are swamped in through numpy and math, and they totally obfuscate the use. 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.
