visualpython-users

[Visualpython-users] Zoom and spin under complete program control

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

In the Contributed section of vpython.org there is now a little
program that handles zoom and spin under complete program control.

Bruce Sherwood

Re: [Visualpython-users] Problems Setting Camera Location

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

There are two answers to your question.

One answer is that there is indeed a hidden user scaling factor based
on the user's mouse operations. I confess I don't understand all of
the design issues, but the last time I talked with David Scherer, the
creator of Visual, he suggested creating a "reset" function (or some
such name) whose arguments would be all of the view elements: camera
position, center, forward, and field of view (of course, any element
not reset would retain its current value). Presumably you could
specify range instead of camera position and field of view. The point
would be to make sure in one statement (running in the computational
thread) that all the view status was set at once, so that you wouldn't
get garbled renderings. This isn't an issue with non-real-time
applications such as Pov-Ray.

The other answer is to handle the user zoom and spin yourself. I've
appended a program that does that. Pressing f or g does what you want
and expect. I'll put a version of this in the contributed section of
vpython.org.

Bruce Sherwood

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

import visual
vs = visual.scene
vs.userzoom = False
vs.userspin = False
vs.range = 2
visual.box(color=visual.color.red)
visual.arrow(pos=(0,.5,0), axis=(0,1,0), color=visual.color.green)
visual.arrow(pos=(.5,0,0), axis=(1,0,0), color=visual.color.cyan)
zoom = False
spin = False
rangemin = .5
rangemax = 20
while True:
  visual.rate(50)
  if vs.kb.keys:
      k = vs.kb.getkey()
      if k == 'f':
          vs.range = 5
      elif k == 'g':
          vs.range = 3
  elif vs.mouse.events:
      m = vs.mouse.getevent()
      if m.drag == 'middle':
          zoom = True
          lasty = m.pos.y
      elif m.drop == 'middle':
          zoom = False
      elif m.drag == 'right':
          spin = True
          lastray = vs.mouse.ray
      elif m.drop == 'right':
          spin = False
  elif zoom:
      newy = vs.mouse.pos.y
      if newy != lasty:
          distance = (vs.center-vs.mouse.camera).mag
          scaling = 10**((lasty-newy)/distance)
          newrange = scaling*vs.range.y
          if rangemin < newrange < rangemax:
              vs.range = newrange
              lasty = scaling*newy
  elif spin:
      newray = vs.mouse.ray
      dray = newray-lastray
      right = vs.forward.cross(vs.up).norm() # unit vector to the right
      up = right.cross(vs.forward).norm() # unit vector upward
      anglex = -4*visual.arcsin(dray.dot(right))
      newforward = visual.vector(vs.forward)
      newforward = visual.rotate(newforward, angle=anglex, axis=vs.up)
      newray = visual.rotate(newray, angle=anglex, axis=vs.up)
      angley = 4*visual.arcsin(dray.dot(up))
      maxangle = vs.up.diff_angle(newforward)
      if not (angley >= maxangle or angley <= maxangle-visual.pi):
          newforward = visual.rotate(newforward, angle=angley, axis=right)
          newray = visual.rotate(newray, angle=angley, axis=right)
      vs.forward = newforward
      lastray = newray

On Fri, Sep 10, 2010 at 2:19 PM, Aaron Mavrinac <mav...@gm...> wrote:
> Hi,
>
> I have an application which requires me to view a scene from a
> particular point in space (pointed along a particular axis). Suppose I
> want the camera at point (a, b, c), pointed at (d, e, f). This may
> occur at any point in the program -- i.e., I want the ability to
> rotate and zoom the scene freely before jumping into this view.
>
> First, I set display.center = (d, e, f). Then, I set display.forward
> to something like (d, e, f) - (a, b, c). This gives me the correct
> axis, but the actual position of the camera along that axis (i.e. the
> "zoom" level, or range/scale) is incorrect, and appears somehow linked
> to whatever my range/scale was before I switched to that view.
>
> >From what I understand, the magnitude of display.forward ought to put
> the camera at the appropriate distance from display.center.
>
> I also tried explicitly setting display.range, based on a complex set
> of calculations involving the relative position of the center and the
> field of view, and while I am somewhat encouraged that this gives me
> the same result as the simpler solution above, it's still not the
> correct result.
>
> I suspect, if I am not misunderstanding something, that there may be
> some issue with how Visual is storing the current position when the
> user rotates and zooms with the mouse. Take the following short
> program:
>
> import visual
> visual.box()
> while True:
>    visual.rate(50)
>    if visual.scene.kb.keys:
>        k = visual.scene.kb.getkey()
>        if k == 'f':
>            visual.scene.range = 5
>        elif k == 'g':
>            visual.scene.range = 3
>
> Running this gives the following results:
>
> F - the box zooms out to size A
> G - the box zooms in a bit, to size B
> F - the box zooms out, back to size A
> <mouse zoom> - the box zooms out to size C
> F - the box remains at size C
> G - the box zooms in a bit, to size D (!= B)
> F - the box zooms out, back to size C
>
> I would have expected from the documentation that, assuming the only
> mouse interaction is zooming, hitting F again should return the box to
> size A -- in other words, that the range/scale is absolute.
>
> If this is buggy behavior, is there a fix or workaround? If this is
> the expected behavior, how can I achieve what I am trying to do above?
>
> --
> Aaron Mavrinac
> www.mavrinac.com

[Visualpython-users] Problems Setting Camera Location

[Aaron M. <mav...@gm...>]

Hi,

I have an application which requires me to view a scene from a
particular point in space (pointed along a particular axis). Suppose I
want the camera at point (a, b, c), pointed at (d, e, f). This may
occur at any point in the program -- i.e., I want the ability to
rotate and zoom the scene freely before jumping into this view.

First, I set display.center = (d, e, f). Then, I set display.forward
to something like (d, e, f) - (a, b, c). This gives me the correct
axis, but the actual position of the camera along that axis (i.e. the
"zoom" level, or range/scale) is incorrect, and appears somehow linked
to whatever my range/scale was before I switched to that view.

>From what I understand, the magnitude of display.forward ought to put
the camera at the appropriate distance from display.center.

I also tried explicitly setting display.range, based on a complex set
of calculations involving the relative position of the center and the
field of view, and while I am somewhat encouraged that this gives me
the same result as the simpler solution above, it's still not the
correct result.

I suspect, if I am not misunderstanding something, that there may be
some issue with how Visual is storing the current position when the
user rotates and zooms with the mouse. Take the following short
program:

import visual
visual.box()
while True:
    visual.rate(50)
    if visual.scene.kb.keys:
        k = visual.scene.kb.getkey()
        if k == 'f':
            visual.scene.range = 5
        elif k == 'g':
            visual.scene.range = 3

Running this gives the following results:

F - the box zooms out to size A
G - the box zooms in a bit, to size B
F - the box zooms out, back to size A
<mouse zoom> - the box zooms out to size C
F - the box remains at size C
G - the box zooms in a bit, to size D (!= B)
F - the box zooms out, back to size C

I would have expected from the documentation that, assuming the only
mouse interaction is zooming, hitting F again should return the box to
size A -- in other words, that the range/scale is absolute.

If this is buggy behavior, is there a fix or workaround? If this is
the expected behavior, how can I achieve what I am trying to do above?

-- 
Aaron Mavrinac
www.mavrinac.com

PGP Public Key: http://www.mavrinac.com/pgp.asc

[Visualpython-users] unsubscribe

[Ramiro C. <cas...@gm...>]

On Thu, Sep 9, 2010 at 4:36 PM, <
vis...@li...> wrote:

> Send Visualpython-users mailing list submissions to
>        vis...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.sourceforge.net/lists/listinfo/visualpython-users
> or, via email, send a message with subject or body 'help' to
>        vis...@li...
>
> You can reach the person managing the list at
>        vis...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Visualpython-users digest..."
>
>
> Today's Topics:
>
>   1. Re: Mac installation question. (Bruce Sherwood)
>   2. Re: Mac installation question. (Martin Costabel)
>   3. Re: Mac installation question. (Steve Spicklemire)
>   4. Re: Mac installation question. (Martin Costabel)
>   5. Re: Mac installation question. (Bruce Sherwood)
>   6. Re: Mac installation question. (Bruce Sherwood)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 8 Sep 2010 17:41:58 -0600
> From: Bruce Sherwood <bas...@nc...>
> Subject: Re: [Visualpython-users] Mac installation question.
> To: vpusers <vis...@li...>
> Message-ID:
>        <AANLkTim7ZPVXMTQR2b1w=+6C...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> It's not a problem of not finding packages, since when you import
> numpy you find numpy. The problem is that numpy can't find a resource
> it needs.
>
> I don't know what could be set up oddly on these Macs, but the trace
> claims that ___memcpy_chk should be found in
> /usr/lib/libSystem.B.dylib. So the first thing to do is to verify that
> indeed this file is missing (or damaged?). Is it?
>
> Note that to see /usr/lib in the Finder you need to use the Finder
> menu Go > Go to Folder.
>
> Bruce Sherwood
>
> On Wed, Sep 8, 2010 at 4:51 PM, Gary Pajer <gar...@gm...> wrote:
> > Our IT dept. just installed vpython on the 'clean' Macs in our lab.?
> AFAIK,
> > they followed the instructions on vpython.org.
> >
> > Unfortunately, python can't find packages.? numpy and visual are
> installed
> > in the "Frameworks" site-packages directory, but they are not found on
> > import.
> >
> > One problem is that PATH is not set properly.? which python ==>
> > /usr/bin/python
> >
> > But if I launch python using the entire path to the executable, then
> import
> > numpy, I get the attached traceback.
> >
> > Anyone know what the missing link is?
> >
> > thanks,
> > gary
> >
> >
> ---------------------------------------------------------------------------------
> >
> >>>> import numpy
> > Traceback (most recent call last):
> > ? File "<stdin>", line 1, in <module>
> > ? File "/Library/Frameworks/Python.
> > framework/Versions/2.7/lib/python2.7/site-packages/numpy/__init__.py",
> line
> > 136, in <module>
> > ??? import add_newdocs
> > ? File
> >
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/add_newdocs.py",
> > line 9, in <module>
> > ??? from numpy.lib import add_newdoc
> > ? File
> >
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/__init__.py",
> > line 4, in <module>
> > ??? from type_check import *
> > ? File
> >
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/type_check.py",
> > line 8, in <module>
> > ??? import numpy.core.numeric as _nx
> > ? File
> >
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/__init__.py",
> > line 5, in <module>
> > ??? import multiarray
> > ImportError:
> >
> dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so,
> > 2): Symbol not found: ___memcpy_chk
> > ? Referenced from:
> >
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so
> > ? Expected in: /usr/lib/libSystem.B.dylib
> >
> >
> >
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 09 Sep 2010 10:10:10 +0200
> From: Martin Costabel <cos...@wa...>
> Subject: Re: [Visualpython-users] Mac installation question.
> To: Bruce Sherwood <bas...@nc...>
> Cc: vpusers <vis...@li...>
> Message-ID: <4C8...@wa...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 9/09/10 01:41, Bruce Sherwood wrote:
> >
> > It's not a problem of not finding packages, since when you import
> > numpy you find numpy. The problem is that numpy can't find a resource
> > it needs.
> >
> > I don't know what could be set up oddly on these Macs, but the trace
> > claims that ___memcpy_chk should be found in
> > /usr/lib/libSystem.B.dylib. So the first thing to do is to verify that
> > indeed this file is missing (or damaged?). Is it?
>
> The symbol in question appeared in MacOSX 10.5. Gary's Macs are probably
> running the old MacOSX 10.4 while the installed numpy from the vpython
> package was compiled on MacOSX 10.5 or 10.6 (10.6, as far as I can
> tell). This won't work, although the vpython web page says it should.
>
> --
> Martin
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 9 Sep 2010 04:55:06 -0400
> From: Steve Spicklemire <st...@sp...>
> Subject: Re: [Visualpython-users] Mac installation question.
> To: Bruce Sherwood <bas...@nc...>
> Cc: vpusers <vis...@li...>
> Message-ID: <F56...@sp...>
> Content-Type: text/plain; charset=us-ascii
>
> Possible clue...  on my PPC running Leopard (10.5.8) I see:
>
> $ otool -vT /usr/lib/libSystem.B.dylib | grep memcpy
> single module    ___memcpy_chk
> single module    _memcpy
> single module    _wmemcpy
>
> on my intel, running Snow Leopard
>
> $ otool -vT /usr/lib/libSystem.B.dylib
> /usr/lib/libSystem.B.dylib:
> Table of contents (0 entries)
> module name      symbol name
>
> So... that's interesting. Having said that I installed v5.32/py2.7 and it
> works correctly on my Snow Leopard intel system... so the numpy that's
> installed with visual doesn't seem to link to the missing symbol.
>
> Gary... did anything else get installed besides visual/py2.7 ? Maybe a
> different version of numpy?
>
> This might also be useful:
>
> IntelMini:~ steve$ python -v -c 'import numpy' 2>&1  | grep multiarray
> dlopen("/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so",
> 2);
> import numpy.core.multiarray # dynamically loaded from
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so
> # cleanup[2] numpy.core.multiarray
> IntelMini:~ steve$
>
> -steve
>
> On Sep 8, 2010, at 7:41 PM, Bruce Sherwood wrote:
>
> > It's not a problem of not finding packages, since when you import
> > numpy you find numpy. The problem is that numpy can't find a resource
> > it needs.
> >
> > I don't know what could be set up oddly on these Macs, but the trace
> > claims that ___memcpy_chk should be found in
> > /usr/lib/libSystem.B.dylib. So the first thing to do is to verify that
> > indeed this file is missing (or damaged?). Is it?
> >
> > Note that to see /usr/lib in the Finder you need to use the Finder
> > menu Go > Go to Folder.
> >
> > Bruce Sherwood
> >
> > On Wed, Sep 8, 2010 at 4:51 PM, Gary Pajer <gar...@gm...> wrote:
> >> Our IT dept. just installed vpython on the 'clean' Macs in our lab.
>  AFAIK,
> >> they followed the instructions on vpython.org.
> >>
> >> Unfortunately, python can't find packages.  numpy and visual are
> installed
> >> in the "Frameworks" site-packages directory, but they are not found on
> >> import.
> >>
> >> One problem is that PATH is not set properly.  which python ==>
> >> /usr/bin/python
> >>
> >> But if I launch python using the entire path to the executable, then
> import
> >> numpy, I get the attached traceback.
> >>
> >> Anyone know what the missing link is?
> >>
> >> thanks,
> >> gary
> >>
> >>
> ---------------------------------------------------------------------------------
> >>
> >>>>> import numpy
> >> Traceback (most recent call last):
> >>   File "<stdin>", line 1, in <module>
> >>   File "/Library/Frameworks/Python.
> >> framework/Versions/2.7/lib/python2.7/site-packages/numpy/__init__.py",
> line
> >> 136, in <module>
> >>     import add_newdocs
> >>   File
> >>
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/add_newdocs.py",
> >> line 9, in <module>
> >>     from numpy.lib import add_newdoc
> >>   File
> >>
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/__init__.py",
> >> line 4, in <module>
> >>     from type_check import *
> >>   File
> >>
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/type_check.py",
> >> line 8, in <module>
> >>     import numpy.core.numeric as _nx
> >>   File
> >>
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/__init__.py",
> >> line 5, in <module>
> >>     import multiarray
> >> ImportError:
> >>
> dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so,
> >> 2): Symbol not found: ___memcpy_chk
> >>   Referenced from:
> >>
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so
> >>   Expected in: /usr/lib/libSystem.B.dylib
> >>
> >>
> >>
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net Dev2Dev email is sponsored by:
> >
> > Show off your parallel programming skills.
> > Enter the Intel(R) Threading Challenge 2010.
> > http://p.sf.net/sfu/intel-thread-sfd
> > _______________________________________________
> > Visualpython-users mailing list
> > Vis...@li...
> > https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 09 Sep 2010 14:25:55 +0200
> From: Martin Costabel <cos...@wa...>
> Subject: Re: [Visualpython-users] Mac installation question.
> To: Steve Spicklemire <st...@sp...>
> Cc: vpusers <vis...@li...>
> Message-ID: <4C8...@wa...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 9/09/10 10:55, Steve Spicklemire wrote:
> >
> > Possible clue...  on my PPC running Leopard (10.5.8) I see:
> >
> > $ otool -vT /usr/lib/libSystem.B.dylib | grep memcpy
> > single module    ___memcpy_chk
> > single module    _memcpy
> > single module    _wmemcpy
> >
> > on my intel, running Snow Leopard
> >
> > $ otool -vT /usr/lib/libSystem.B.dylib
> > /usr/lib/libSystem.B.dylib:
> > Table of contents (0 entries)
> > module name      symbol name
>
> It seems that otool -T behaves in an "unexpected" way on Snow Leopard
> (AKA "doesn't work"). If you use nm instead, it shows you the same thing
> for ___memcpy as on Leopard.
>
> > So... that's interesting. Having said that I installed v5.32/py2.7 and it
> works correctly on my Snow Leopard intel system... so the numpy that's
> installed with visual doesn't seem to link to the missing symbol.
>
> It does link:
>
> costabel% nm -m multiarray.so | grep memcpy_chk
>       (undefined [lazy bound]) external ___memcpy_chk (from libSystem)
>
> This is on Snow Leopard. If I try the same command with the same file on
> Leopard, I get
>
> nm: for architecture i386 object: core/multiarray.so malformed object
> (unknown load command 4).
>
> Load command 4 is LC_DYLD_INFO_ONLY, which was introduced with MacOSX
> 10.6. This means that this binary doesn't even work correctly on MacOSX
> 10.5, although it is rather "fat":
>
> % file  core/multiarray.so
> core/multiarray.so: Mach-O universal binary with 3 architectures
> core/multiarray.so (for architecture i386):     Mach-O bundle i386
> core/multiarray.so (for architecture ppc7400):  Mach-O bundle ppc
> core/multiarray.so (for architecture x86_64):   Mach-O 64-bit bundle x86_64
>
> Whoever built this version of numpy might want to rebuild it with the
> 10.4 SDK.
>
> --
> Martin
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 9 Sep 2010 10:02:21 -0600
> From: Bruce Sherwood <bas...@nc...>
> Subject: Re: [Visualpython-users] Mac installation question.
> To: vpusers <vis...@li...>
> Message-ID:
>        <AANLkTi=83h...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Sigh. I innocently simply used the numpy Mac installer. Is the short
> statement that at least for now the vpython.org Mac download page
> should say that the VPython installer is for 10.5 and higher?
>
> Bruce
>
> On Thu, Sep 9, 2010 at 6:25 AM, Martin Costabel <cos...@wa...>
> wrote:
> > On 9/09/10 10:55, Steve Spicklemire wrote:
> >>
> >> Possible clue... ?on my PPC running Leopard (10.5.8) I see:
> >>
> >> $ otool -vT /usr/lib/libSystem.B.dylib | grep memcpy
> >> single module ? ?___memcpy_chk
> >> single module ? ?_memcpy
> >> single module ? ?_wmemcpy
> >>
> >> on my intel, running Snow Leopard
> >>
> >> $ otool -vT /usr/lib/libSystem.B.dylib
> >> /usr/lib/libSystem.B.dylib:
> >> Table of contents (0 entries)
> >> module name ? ? ?symbol name
> >
> > It seems that otool -T behaves in an "unexpected" way on Snow Leopard
> (AKA
> > "doesn't work"). If you use nm instead, it shows you the same thing for
> > ___memcpy as on Leopard.
> >
> >> So... that's interesting. Having said that I installed v5.32/py2.7 and
> it
> >> works correctly on my Snow Leopard intel system... so the numpy that's
> >> installed with visual doesn't seem to link to the missing symbol.
> >
> > It does link:
> >
> > costabel% nm -m multiarray.so | grep memcpy_chk
> > ? ? ?(undefined [lazy bound]) external ___memcpy_chk (from libSystem)
> >
> > This is on Snow Leopard. If I try the same command with the same file on
> > Leopard, I get
> >
> > nm: for architecture i386 object: core/multiarray.so malformed object
> > (unknown load command 4).
> >
> > Load command 4 is LC_DYLD_INFO_ONLY, which was introduced with MacOSX
> 10.6.
> > This means that this binary doesn't even work correctly on MacOSX 10.5,
> > although it is rather "fat":
> >
> > % file ?core/multiarray.so
> > core/multiarray.so: Mach-O universal binary with 3 architectures
> > core/multiarray.so (for architecture i386): ? ? Mach-O bundle i386
> > core/multiarray.so (for architecture ppc7400): ?Mach-O bundle ppc
> > core/multiarray.so (for architecture x86_64): ? Mach-O 64-bit bundle
> x86_64
> >
> > Whoever built this version of numpy might want to rebuild it with the
> 10.4
> > SDK.
> >
> > --
> > Martin
> >
> >
> >
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 9 Sep 2010 13:36:11 -0600
> From: Bruce Sherwood <bas...@nc...>
> Subject: Re: [Visualpython-users] Mac installation question.
> To: vpusers <vis...@li...>
> Message-ID:
>        <AAN...@ma...<AANLkTimu_kKi54NMiur2PBk7E%2BRBJ6OqBGeKPHw%2B...@ma...>
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> Further comment: I've been careful to use the 10.4 c++ compiler on the
> Mac, and in PackageMaker to specify OSX >= 10.4. Alas, it must be that
> the latest numpy installer isn't built that way, and I didn't think of
> that potential problem. I'm going to change the note on vpython.org to
> say "10.5 or 10.6", and suggest people use an older version if they're
> running 10.4.
>
> I can't help observing that Python and Visual work fine across a very
> long time period of Windows versions, from XP, or even before, through
> Windows 7. But there are all sorts of little glitches in Mac OSX
> releases that make it necessary to pay close attention to the specific
> release.
>
> Also, for everyone's information, there still isn't a numpy installer
> for Python 3.1 on the Mac, and I was unable to build numpy from source
> (I found some notes on the web about others having this problem, too).
>
> Bruce
>
> On Thu, Sep 9, 2010 at 10:02 AM, Bruce Sherwood <bas...@nc...> wrote:
> > Sigh. I innocently simply used the numpy Mac installer. Is the short
> > statement that at least for now the vpython.org Mac download page
> > should say that the VPython installer is for 10.5 and higher?
> >
> > Bruce
> >
> > On Thu, Sep 9, 2010 at 6:25 AM, Martin Costabel <cos...@wa...>
> wrote:
> >> On 9/09/10 10:55, Steve Spicklemire wrote:
> >>>
> >>> Possible clue... ?on my PPC running Leopard (10.5.8) I see:
> >>>
> >>> $ otool -vT /usr/lib/libSystem.B.dylib | grep memcpy
> >>> single module ? ?___memcpy_chk
> >>> single module ? ?_memcpy
> >>> single module ? ?_wmemcpy
> >>>
> >>> on my intel, running Snow Leopard
> >>>
> >>> $ otool -vT /usr/lib/libSystem.B.dylib
> >>> /usr/lib/libSystem.B.dylib:
> >>> Table of contents (0 entries)
> >>> module name ? ? ?symbol name
> >>
> >> It seems that otool -T behaves in an "unexpected" way on Snow Leopard
> (AKA
> >> "doesn't work"). If you use nm instead, it shows you the same thing for
> >> ___memcpy as on Leopard.
> >>
> >>> So... that's interesting. Having said that I installed v5.32/py2.7 and
> it
> >>> works correctly on my Snow Leopard intel system... so the numpy that's
> >>> installed with visual doesn't seem to link to the missing symbol.
> >>
> >> It does link:
> >>
> >> costabel% nm -m multiarray.so | grep memcpy_chk
> >> ? ? ?(undefined [lazy bound]) external ___memcpy_chk (from libSystem)
> >>
> >> This is on Snow Leopard. If I try the same command with the same file on
> >> Leopard, I get
> >>
> >> nm: for architecture i386 object: core/multiarray.so malformed object
> >> (unknown load command 4).
> >>
> >> Load command 4 is LC_DYLD_INFO_ONLY, which was introduced with MacOSX
> 10.6.
> >> This means that this binary doesn't even work correctly on MacOSX 10.5,
> >> although it is rather "fat":
> >>
> >> % file ?core/multiarray.so
> >> core/multiarray.so: Mach-O universal binary with 3 architectures
> >> core/multiarray.so (for architecture i386): ? ? Mach-O bundle i386
> >> core/multiarray.so (for architecture ppc7400): ?Mach-O bundle ppc
> >> core/multiarray.so (for architecture x86_64): ? Mach-O 64-bit bundle
> x86_64
> >>
> >> Whoever built this version of numpy might want to rebuild it with the
> 10.4
> >> SDK.
> >>
> >> --
> >> Martin
> >>
> >>
> >>
> >
>
>
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
>
> ------------------------------
>
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>
> End of Visualpython-users Digest, Vol 52, Issue 3
> *************************************************
>



-- 
----------------------------
Ramiro Castro
Cordoba, Argentina

Re: [Visualpython-users] Mac installation question.

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

Further comment: I've been careful to use the 10.4 c++ compiler on the
Mac, and in PackageMaker to specify OSX >= 10.4. Alas, it must be that
the latest numpy installer isn't built that way, and I didn't think of
that potential problem. I'm going to change the note on vpython.org to
say "10.5 or 10.6", and suggest people use an older version if they're
running 10.4.

I can't help observing that Python and Visual work fine across a very
long time period of Windows versions, from XP, or even before, through
Windows 7. But there are all sorts of little glitches in Mac OSX
releases that make it necessary to pay close attention to the specific
release.

Also, for everyone's information, there still isn't a numpy installer
for Python 3.1 on the Mac, and I was unable to build numpy from source
(I found some notes on the web about others having this problem, too).

Bruce

On Thu, Sep 9, 2010 at 10:02 AM, Bruce Sherwood <bas...@nc...> wrote:
> Sigh. I innocently simply used the numpy Mac installer. Is the short
> statement that at least for now the vpython.org Mac download page
> should say that the VPython installer is for 10.5 and higher?
>
> Bruce
>
> On Thu, Sep 9, 2010 at 6:25 AM, Martin Costabel <cos...@wa...> wrote:
>> On 9/09/10 10:55, Steve Spicklemire wrote:
>>>
>>> Possible clue...  on my PPC running Leopard (10.5.8) I see:
>>>
>>> $ otool -vT /usr/lib/libSystem.B.dylib | grep memcpy
>>> single module    ___memcpy_chk
>>> single module    _memcpy
>>> single module    _wmemcpy
>>>
>>> on my intel, running Snow Leopard
>>>
>>> $ otool -vT /usr/lib/libSystem.B.dylib
>>> /usr/lib/libSystem.B.dylib:
>>> Table of contents (0 entries)
>>> module name      symbol name
>>
>> It seems that otool -T behaves in an "unexpected" way on Snow Leopard (AKA
>> "doesn't work"). If you use nm instead, it shows you the same thing for
>> ___memcpy as on Leopard.
>>
>>> So... that's interesting. Having said that I installed v5.32/py2.7 and it
>>> works correctly on my Snow Leopard intel system... so the numpy that's
>>> installed with visual doesn't seem to link to the missing symbol.
>>
>> It does link:
>>
>> costabel% nm -m multiarray.so | grep memcpy_chk
>>      (undefined [lazy bound]) external ___memcpy_chk (from libSystem)
>>
>> This is on Snow Leopard. If I try the same command with the same file on
>> Leopard, I get
>>
>> nm: for architecture i386 object: core/multiarray.so malformed object
>> (unknown load command 4).
>>
>> Load command 4 is LC_DYLD_INFO_ONLY, which was introduced with MacOSX 10.6.
>> This means that this binary doesn't even work correctly on MacOSX 10.5,
>> although it is rather "fat":
>>
>> % file  core/multiarray.so
>> core/multiarray.so: Mach-O universal binary with 3 architectures
>> core/multiarray.so (for architecture i386):     Mach-O bundle i386
>> core/multiarray.so (for architecture ppc7400):  Mach-O bundle ppc
>> core/multiarray.so (for architecture x86_64):   Mach-O 64-bit bundle x86_64
>>
>> Whoever built this version of numpy might want to rebuild it with the 10.4
>> SDK.
>>
>> --
>> Martin
>>
>>
>>
>

Re: [Visualpython-users] Mac installation question.

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

Sigh. I innocently simply used the numpy Mac installer. Is the short
statement that at least for now the vpython.org Mac download page
should say that the VPython installer is for 10.5 and higher?

Bruce

On Thu, Sep 9, 2010 at 6:25 AM, Martin Costabel <cos...@wa...> wrote:
> On 9/09/10 10:55, Steve Spicklemire wrote:
>>
>> Possible clue...  on my PPC running Leopard (10.5.8) I see:
>>
>> $ otool -vT /usr/lib/libSystem.B.dylib | grep memcpy
>> single module    ___memcpy_chk
>> single module    _memcpy
>> single module    _wmemcpy
>>
>> on my intel, running Snow Leopard
>>
>> $ otool -vT /usr/lib/libSystem.B.dylib
>> /usr/lib/libSystem.B.dylib:
>> Table of contents (0 entries)
>> module name      symbol name
>
> It seems that otool -T behaves in an "unexpected" way on Snow Leopard (AKA
> "doesn't work"). If you use nm instead, it shows you the same thing for
> ___memcpy as on Leopard.
>
>> So... that's interesting. Having said that I installed v5.32/py2.7 and it
>> works correctly on my Snow Leopard intel system... so the numpy that's
>> installed with visual doesn't seem to link to the missing symbol.
>
> It does link:
>
> costabel% nm -m multiarray.so | grep memcpy_chk
>      (undefined [lazy bound]) external ___memcpy_chk (from libSystem)
>
> This is on Snow Leopard. If I try the same command with the same file on
> Leopard, I get
>
> nm: for architecture i386 object: core/multiarray.so malformed object
> (unknown load command 4).
>
> Load command 4 is LC_DYLD_INFO_ONLY, which was introduced with MacOSX 10.6.
> This means that this binary doesn't even work correctly on MacOSX 10.5,
> although it is rather "fat":
>
> % file  core/multiarray.so
> core/multiarray.so: Mach-O universal binary with 3 architectures
> core/multiarray.so (for architecture i386):     Mach-O bundle i386
> core/multiarray.so (for architecture ppc7400):  Mach-O bundle ppc
> core/multiarray.so (for architecture x86_64):   Mach-O 64-bit bundle x86_64
>
> Whoever built this version of numpy might want to rebuild it with the 10.4
> SDK.
>
> --
> Martin
>
>
>

Re: [Visualpython-users] Mac installation question.

[Martin C. <cos...@wa...>]

On 9/09/10 10:55, Steve Spicklemire wrote:
>
> Possible clue...  on my PPC running Leopard (10.5.8) I see:
>
> $ otool -vT /usr/lib/libSystem.B.dylib | grep memcpy
> single module    ___memcpy_chk
> single module    _memcpy
> single module    _wmemcpy
>
> on my intel, running Snow Leopard
>
> $ otool -vT /usr/lib/libSystem.B.dylib
> /usr/lib/libSystem.B.dylib:
> Table of contents (0 entries)
> module name      symbol name

It seems that otool -T behaves in an "unexpected" way on Snow Leopard 
(AKA "doesn't work"). If you use nm instead, it shows you the same thing 
for ___memcpy as on Leopard.

> So... that's interesting. Having said that I installed v5.32/py2.7 and it works correctly on my Snow Leopard intel system... so the numpy that's installed with visual doesn't seem to link to the missing symbol.

It does link:

costabel% nm -m multiarray.so | grep memcpy_chk
       (undefined [lazy bound]) external ___memcpy_chk (from libSystem)

This is on Snow Leopard. If I try the same command with the same file on 
Leopard, I get

nm: for architecture i386 object: core/multiarray.so malformed object 
(unknown load command 4).

Load command 4 is LC_DYLD_INFO_ONLY, which was introduced with MacOSX 
10.6. This means that this binary doesn't even work correctly on MacOSX 
10.5, although it is rather "fat":

% file  core/multiarray.so
core/multiarray.so: Mach-O universal binary with 3 architectures
core/multiarray.so (for architecture i386):	Mach-O bundle i386
core/multiarray.so (for architecture ppc7400):	Mach-O bundle ppc
core/multiarray.so (for architecture x86_64):	Mach-O 64-bit bundle x86_64

Whoever built this version of numpy might want to rebuild it with the 
10.4 SDK.

-- 
Martin

Re: [Visualpython-users] Mac installation question.

[Steve S. <st...@sp...>]

Possible clue...  on my PPC running Leopard (10.5.8) I see:

$ otool -vT /usr/lib/libSystem.B.dylib | grep memcpy
single module    ___memcpy_chk
single module    _memcpy
single module    _wmemcpy

on my intel, running Snow Leopard 

$ otool -vT /usr/lib/libSystem.B.dylib 
/usr/lib/libSystem.B.dylib:
Table of contents (0 entries)
module name      symbol name

So... that's interesting. Having said that I installed v5.32/py2.7 and it works correctly on my Snow Leopard intel system... so the numpy that's installed with visual doesn't seem to link to the missing symbol.

Gary... did anything else get installed besides visual/py2.7 ? Maybe a different version of numpy?

This might also be useful:

IntelMini:~ steve$ python -v -c 'import numpy' 2>&1  | grep multiarray
dlopen("/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so", 2);
import numpy.core.multiarray # dynamically loaded from /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so
# cleanup[2] numpy.core.multiarray
IntelMini:~ steve$ 

-steve

On Sep 8, 2010, at 7:41 PM, Bruce Sherwood wrote:

> It's not a problem of not finding packages, since when you import
> numpy you find numpy. The problem is that numpy can't find a resource
> it needs.
> 
> I don't know what could be set up oddly on these Macs, but the trace
> claims that ___memcpy_chk should be found in
> /usr/lib/libSystem.B.dylib. So the first thing to do is to verify that
> indeed this file is missing (or damaged?). Is it?
> 
> Note that to see /usr/lib in the Finder you need to use the Finder
> menu Go > Go to Folder.
> 
> Bruce Sherwood
> 
> On Wed, Sep 8, 2010 at 4:51 PM, Gary Pajer <gar...@gm...> wrote:
>> Our IT dept. just installed vpython on the 'clean' Macs in our lab.  AFAIK,
>> they followed the instructions on vpython.org.
>> 
>> Unfortunately, python can't find packages.  numpy and visual are installed
>> in the "Frameworks" site-packages directory, but they are not found on
>> import.
>> 
>> One problem is that PATH is not set properly.  which python ==>
>> /usr/bin/python
>> 
>> But if I launch python using the entire path to the executable, then import
>> numpy, I get the attached traceback.
>> 
>> Anyone know what the missing link is?
>> 
>> thanks,
>> gary
>> 
>> ---------------------------------------------------------------------------------
>> 
>>>>> import numpy
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>>   File "/Library/Frameworks/Python.
>> framework/Versions/2.7/lib/python2.7/site-packages/numpy/__init__.py", line
>> 136, in <module>
>>     import add_newdocs
>>   File
>> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/add_newdocs.py",
>> line 9, in <module>
>>     from numpy.lib import add_newdoc
>>   File
>> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/__init__.py",
>> line 4, in <module>
>>     from type_check import *
>>   File
>> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/type_check.py",
>> line 8, in <module>
>>     import numpy.core.numeric as _nx
>>   File
>> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/__init__.py",
>> line 5, in <module>
>>     import multiarray
>> ImportError:
>> dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so,
>> 2): Symbol not found: ___memcpy_chk
>>   Referenced from:
>> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so
>>   Expected in: /usr/lib/libSystem.B.dylib
>> 
>> 
>> 
> 
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Mac installation question.

[Martin C. <cos...@wa...>]

On 9/09/10 01:41, Bruce Sherwood wrote:
>
> It's not a problem of not finding packages, since when you import
> numpy you find numpy. The problem is that numpy can't find a resource
> it needs.
>
> I don't know what could be set up oddly on these Macs, but the trace
> claims that ___memcpy_chk should be found in
> /usr/lib/libSystem.B.dylib. So the first thing to do is to verify that
> indeed this file is missing (or damaged?). Is it?

The symbol in question appeared in MacOSX 10.5. Gary's Macs are probably 
running the old MacOSX 10.4 while the installed numpy from the vpython 
package was compiled on MacOSX 10.5 or 10.6 (10.6, as far as I can 
tell). This won't work, although the vpython web page says it should.

-- 
Martin

Re: [Visualpython-users] Mac installation question.

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

It's not a problem of not finding packages, since when you import
numpy you find numpy. The problem is that numpy can't find a resource
it needs.

I don't know what could be set up oddly on these Macs, but the trace
claims that ___memcpy_chk should be found in
/usr/lib/libSystem.B.dylib. So the first thing to do is to verify that
indeed this file is missing (or damaged?). Is it?

Note that to see /usr/lib in the Finder you need to use the Finder
menu Go > Go to Folder.

Bruce Sherwood

On Wed, Sep 8, 2010 at 4:51 PM, Gary Pajer <gar...@gm...> wrote:
> Our IT dept. just installed vpython on the 'clean' Macs in our lab.  AFAIK,
> they followed the instructions on vpython.org.
>
> Unfortunately, python can't find packages.  numpy and visual are installed
> in the "Frameworks" site-packages directory, but they are not found on
> import.
>
> One problem is that PATH is not set properly.  which python ==>
> /usr/bin/python
>
> But if I launch python using the entire path to the executable, then import
> numpy, I get the attached traceback.
>
> Anyone know what the missing link is?
>
> thanks,
> gary
>
> ---------------------------------------------------------------------------------
>
>>>> import numpy
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/Library/Frameworks/Python.
> framework/Versions/2.7/lib/python2.7/site-packages/numpy/__init__.py", line
> 136, in <module>
>     import add_newdocs
>   File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/add_newdocs.py",
> line 9, in <module>
>     from numpy.lib import add_newdoc
>   File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/__init__.py",
> line 4, in <module>
>     from type_check import *
>   File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/type_check.py",
> line 8, in <module>
>     import numpy.core.numeric as _nx
>   File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/__init__.py",
> line 5, in <module>
>     import multiarray
> ImportError:
> dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so,
> 2): Symbol not found: ___memcpy_chk
>   Referenced from:
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so
>   Expected in: /usr/lib/libSystem.B.dylib
>
>
>

[Visualpython-users] Mac installation question.

[Gary P. <gar...@gm...>]

Our IT dept. just installed vpython on the 'clean' Macs in our lab.  AFAIK,
they followed the instructions on vpython.org.

Unfortunately, python can't find packages.  numpy and visual are installed
in the "Frameworks" site-packages directory, but they are not found on
import.

One problem is that PATH is not set properly.  which python ==>
/usr/bin/python

But if I launch python using the entire path to the executable, then import
numpy, I get the attached traceback.

Anyone know what the missing link is?

thanks,
gary

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

>>> import numpy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.
framework/Versions/2.7/lib/python2.7/site-packages/numpy/__init__.py", line
136, in <module>
    import add_newdocs
  File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/add_newdocs.py",
line 9, in <module>
    from numpy.lib import add_newdoc
  File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/__init__.py",
line 4, in <module>
    from type_check import *
  File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/type_check.py",
line 8, in <module>
    import numpy.core.numeric as _nx
  File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/__init__.py",
line 5, in <module>
    import multiarray
ImportError:
dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so,
2): Symbol not found: ___memcpy_chk
  Referenced from:
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so
  Expected in: /usr/lib/libSystem.B.dylib

Re: [Visualpython-users] Adding Visual to another Python install

[Mirko B. <mir...@ie...>]

Hi,

last spring I was in a similar situation and I wrote a portfile for visual
myself, which I then submitted to the macports maintainers for inclusion in
the official repository. It was rejected because of something unorthodox in
it that the reviewer pointed out, and back then I did not really have time
to fix this problem. However, it does work, but for a number of reasons only
with python26 @2.6.4 (basically because the boost libraries were compiled
against this version, and I did not recompile them for 2.6.6).

Since I noticed that a port for py27-numpy appeared, I might get a shot at
reworking the portfile so as to work with python27. For the moment, you
might want to take a look at
www.mmmi.sdu.dk/~mirko/macports/python/py26-visual.tgz, or directly add
http://www.mmmi.sdu.dk/macports/ to your
/opt/local/etc/macports/sources.conf.

bye,
Mirko Bordignon


On Mon, Sep 6, 2010 at 7:23 PM, Alex Edelman <ale...@gm...> wrote:

> Thanks for the suggestions, all.
>
> As far as I know, Macports doesn't have a version of visual - I gather
> from various trac comments that there was a lack of interest. Macports
> (which is where I get my Python) does have (almost?) all of visual's
> dependencies, so compiling by hand shouldn't be too much of a pain.
>
>
> Alex Edelman
> Carnegie Mellon University
> Physics, Class of 2012
> ale...@gm...
> ao...@cm...
>
>
>
> On Mon, Sep 6, 2010 at 13:11, Danny Caballero <dan...@gm...>
> wrote:
> > Macports too.
> >
> > --
> > Sent from a mobile device
> > Please excuse typos
> >
> > On Sep 6, 2010, at 11:00 AM, Bruce Sherwood <bas...@nc...> wrote:
> >
> >> I should add that if you use Fink on a Mac, Visual is one of the
> >> available packages. So that's another environment that offers Visual
> >> on a Mac without having to build from source.
> >>
> >> Bruce Sherwood
> >>
> >> On Sun, Sep 5, 2010 at 5:06 PM, Bruce Sherwood <bas...@nc...>
> wrote:
> >>> You certainly don't have to use VIDLE if you don't wish to. As for
> >>> installing Visual for some Python other than the one for which it has
> >>> been built, no, I don't see any way around building Visual yourself
> >>> from source. Of course if your "existing Python installation" happens
> >>> to be the standard Python for the Mac recommended by python.org,
> >>> you're all set; just use the Visual installer for the Mac.
> >>>
> >>> By the way, you might be interested to know that Visual was created at
> >>> Carnegie Mellon in 2000 by David Scherer, then a sophomore in computer
> >>> science.
> >>>
> >>> Bruce Sherwood
> >>>
> >>> On Sun, Sep 5, 2010 at 4:20 PM, Alex Edelman <ale...@gm...>
> wrote:
> >>>> This is perhaps a basic question, but I haven't been able to find
> >>>> documentation on the subject elsewhere. Is there a way to install
> >>>> Visual so that it plays nice with an existing Python installation,
> >>>> preferably without building from source? (I'm on a mac, have my python
> >>>> set up the way I like it, and would really love to avoid VIDLE and
> >>>> all.)
> >>>>
> >>>> With thanks for any help,
> >>>>
> >>>> Alex Edelman
> >>>> Carnegie Mellon University
> >>>> Physics, Class of 2012
> >>>> ale...@gm...
> >>>> ao...@cm...
> >>>>
> >>>>
> ------------------------------------------------------------------------------
> >>>> This SF.net Dev2Dev email is sponsored by:
> >>>>
> >>>> Show off your parallel programming skills.
> >>>> Enter the Intel(R) Threading Challenge 2010.
> >>>> http://p.sf.net/sfu/intel-thread-sfd
> >>>> _______________________________________________
> >>>> Visualpython-users mailing list
> >>>> Vis...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
> >>>>
> >>>
> >>
> >>
> ------------------------------------------------------------------------------
> >> This SF.net Dev2Dev email is sponsored by:
> >>
> >> Show off your parallel programming skills.
> >> Enter the Intel(R) Threading Challenge 2010.
> >> http://p.sf.net/sfu/intel-thread-sfd
> >> _______________________________________________
> >> Visualpython-users mailing list
> >> Vis...@li...
> >> https://lists.sourceforge.net/lists/listinfo/visualpython-users
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net Dev2Dev email is sponsored by:
> >
> > Show off your parallel programming skills.
> > Enter the Intel(R) Threading Challenge 2010.
> > http://p.sf.net/sfu/intel-thread-sfd
> > _______________________________________________
> > Visualpython-users mailing list
> > Vis...@li...
> > https://lists.sourceforge.net/lists/listinfo/visualpython-users
> >
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] Adding Visual to another Python install

[Alex E. <ale...@gm...>]

Thanks for the suggestions, all.

As far as I know, Macports doesn't have a version of visual - I gather
from various trac comments that there was a lack of interest. Macports
(which is where I get my Python) does have (almost?) all of visual's
dependencies, so compiling by hand shouldn't be too much of a pain.


Alex Edelman
Carnegie Mellon University
Physics, Class of 2012
ale...@gm...
ao...@cm...



On Mon, Sep 6, 2010 at 13:11, Danny Caballero <dan...@gm...> wrote:
> Macports too.
>
> --
> Sent from a mobile device
> Please excuse typos
>
> On Sep 6, 2010, at 11:00 AM, Bruce Sherwood <bas...@nc...> wrote:
>
>> I should add that if you use Fink on a Mac, Visual is one of the
>> available packages. So that's another environment that offers Visual
>> on a Mac without having to build from source.
>>
>> Bruce Sherwood
>>
>> On Sun, Sep 5, 2010 at 5:06 PM, Bruce Sherwood <bas...@nc...> wrote:
>>> You certainly don't have to use VIDLE if you don't wish to. As for
>>> installing Visual for some Python other than the one for which it has
>>> been built, no, I don't see any way around building Visual yourself
>>> from source. Of course if your "existing Python installation" happens
>>> to be the standard Python for the Mac recommended by python.org,
>>> you're all set; just use the Visual installer for the Mac.
>>>
>>> By the way, you might be interested to know that Visual was created at
>>> Carnegie Mellon in 2000 by David Scherer, then a sophomore in computer
>>> science.
>>>
>>> Bruce Sherwood
>>>
>>> On Sun, Sep 5, 2010 at 4:20 PM, Alex Edelman <ale...@gm...> wrote:
>>>> This is perhaps a basic question, but I haven't been able to find
>>>> documentation on the subject elsewhere. Is there a way to install
>>>> Visual so that it plays nice with an existing Python installation,
>>>> preferably without building from source? (I'm on a mac, have my python
>>>> set up the way I like it, and would really love to avoid VIDLE and
>>>> all.)
>>>>
>>>> With thanks for any help,
>>>>
>>>> Alex Edelman
>>>> Carnegie Mellon University
>>>> Physics, Class of 2012
>>>> ale...@gm...
>>>> ao...@cm...
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net Dev2Dev email is sponsored by:
>>>>
>>>> Show off your parallel programming skills.
>>>> Enter the Intel(R) Threading Challenge 2010.
>>>> http://p.sf.net/sfu/intel-thread-sfd
>>>> _______________________________________________
>>>> Visualpython-users mailing list
>>>> Vis...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] Adding Visual to another Python install

[Danny C. <dan...@gm...>]

Macports too.

--
Sent from a mobile device
Please excuse typos

On Sep 6, 2010, at 11:00 AM, Bruce Sherwood <bas...@nc...> wrote:

> I should add that if you use Fink on a Mac, Visual is one of the
> available packages. So that's another environment that offers Visual
> on a Mac without having to build from source.
>
> Bruce Sherwood
>
> On Sun, Sep 5, 2010 at 5:06 PM, Bruce Sherwood <bas...@nc...> wrote:
>> You certainly don't have to use VIDLE if you don't wish to. As for
>> installing Visual for some Python other than the one for which it has
>> been built, no, I don't see any way around building Visual yourself
>> from source. Of course if your "existing Python installation" happens
>> to be the standard Python for the Mac recommended by python.org,
>> you're all set; just use the Visual installer for the Mac.
>>
>> By the way, you might be interested to know that Visual was created at
>> Carnegie Mellon in 2000 by David Scherer, then a sophomore in computer
>> science.
>>
>> Bruce Sherwood
>>
>> On Sun, Sep 5, 2010 at 4:20 PM, Alex Edelman <ale...@gm...> wrote:
>>> This is perhaps a basic question, but I haven't been able to find
>>> documentation on the subject elsewhere. Is there a way to install
>>> Visual so that it plays nice with an existing Python installation,
>>> preferably without building from source? (I'm on a mac, have my python
>>> set up the way I like it, and would really love to avoid VIDLE and
>>> all.)
>>>
>>> With thanks for any help,
>>>
>>> Alex Edelman
>>> Carnegie Mellon University
>>> Physics, Class of 2012
>>> ale...@gm...
>>> ao...@cm...
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net Dev2Dev email is sponsored by:
>>>
>>> Show off your parallel programming skills.
>>> Enter the Intel(R) Threading Challenge 2010.
>>> http://p.sf.net/sfu/intel-thread-sfd
>>> _______________________________________________
>>> Visualpython-users mailing list
>>> Vis...@li...
>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>
>>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Adding Visual to another Python install

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

I should add that if you use Fink on a Mac, Visual is one of the
available packages. So that's another environment that offers Visual
on a Mac without having to build from source.

Bruce Sherwood

On Sun, Sep 5, 2010 at 5:06 PM, Bruce Sherwood <bas...@nc...> wrote:
> You certainly don't have to use VIDLE if you don't wish to. As for
> installing Visual for some Python other than the one for which it has
> been built, no, I don't see any way around building Visual yourself
> from source. Of course if your "existing Python installation" happens
> to be the standard Python for the Mac recommended by python.org,
> you're all set; just use the Visual installer for the Mac.
>
> By the way, you might be interested to know that Visual was created at
> Carnegie Mellon in 2000 by David Scherer, then a sophomore in computer
> science.
>
> Bruce Sherwood
>
> On Sun, Sep 5, 2010 at 4:20 PM, Alex Edelman <ale...@gm...> wrote:
>> This is perhaps a basic question, but I haven't been able to find
>> documentation on the subject elsewhere. Is there a way to install
>> Visual so that it plays nice with an existing Python installation,
>> preferably without building from source? (I'm on a mac, have my python
>> set up the way I like it, and would really love to avoid VIDLE and
>> all.)
>>
>> With thanks for any help,
>>
>> Alex Edelman
>> Carnegie Mellon University
>> Physics, Class of 2012
>> ale...@gm...
>> ao...@cm...
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>
>

[Visualpython-users] Enhanced gas program

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

In the Contributed section of vpython.org is an enhanced version of
gas.py by Giulio Venezian. Here are notes from the program:

## Based on gas.py, which is distributed in the VPython example programs.
##   modified so initial distribution has no overlapping atoms
##   modified for isotropic distribution (but all atoms start with the
same energy)
##   modified to display additional histograms
## This is an attempt to handle collisions in the order they occur;
## in previous versions, they were handled by position in the loop,
not in order of occurrence
## which makes the system irreversible (aside from rounoff errors).

Bruce Sherwood

Re: [Visualpython-users] Adding Visual to another Python install

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

You certainly don't have to use VIDLE if you don't wish to. As for
installing Visual for some Python other than the one for which it has
been built, no, I don't see any way around building Visual yourself
from source. Of course if your "existing Python installation" happens
to be the standard Python for the Mac recommended by python.org,
you're all set; just use the Visual installer for the Mac.

By the way, you might be interested to know that Visual was created at
Carnegie Mellon in 2000 by David Scherer, then a sophomore in computer
science.

Bruce Sherwood

On Sun, Sep 5, 2010 at 4:20 PM, Alex Edelman <ale...@gm...> wrote:
> This is perhaps a basic question, but I haven't been able to find
> documentation on the subject elsewhere. Is there a way to install
> Visual so that it plays nice with an existing Python installation,
> preferably without building from source? (I'm on a mac, have my python
> set up the way I like it, and would really love to avoid VIDLE and
> all.)
>
> With thanks for any help,
>
> Alex Edelman
> Carnegie Mellon University
> Physics, Class of 2012
> ale...@gm...
> ao...@cm...
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

[Visualpython-users] Adding Visual to another Python install

[Alex E. <ale...@gm...>]

This is perhaps a basic question, but I haven't been able to find
documentation on the subject elsewhere. Is there a way to install
Visual so that it plays nice with an existing Python installation,
preferably without building from source? (I'm on a mac, have my python
set up the way I like it, and would really love to avoid VIDLE and
all.)

With thanks for any help,

Alex Edelman
Carnegie Mellon University
Physics, Class of 2012
ale...@gm...
ao...@cm...

[Visualpython-users] Updated VPython for Python 2.7 on Mac

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

The VPython 5.32 installer for Python 2.7 on the Mac has been rebuilt
to include the production version of numpy.

Bruce Sherwood

Re: [Visualpython-users] Visual 5.32 now available for Python 2.7

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

Despite travel, I was able to rebuild and replace VPython 5.32 for
Python 2.7 for Windows at vpython.org using the new production version
of numpy 1.5.0. I won't be able to replace the Mac version for several
days, however.

It seems doubtful to me that the one using the beta version of numpy
will cause problems for students, since all the VPython test programs
ran fine.

As for stable production versions, all previous versions (except the
previous one for Python 2.7) were built with production versions of
numpy.

Bruce Sherwood

On Tue, Aug 31, 2010 at 10:42 AM, James Mueller <mu...@pi...> wrote:
> Bruce,
>        Now that classes are starting and students are going to the download site, I am a little disturbed to see that the version of visual presented for students to download is the one linked vs the first beta version of numpy 1.5.0.  To download a version linked against a production version of numpy requires going to the "older versions" page and trying to figure out what you are getting.  For instance, which version would one download if one wanted to stick to the production version of numpy?  Could we please have a section of the download pages that will link to stable versions to download?
>        Beta versions are not meant to be stable.  I note that since the "current" version of visual was built, there have been two updates to the numpy beta released, and as I typed this email, the final version was released.  So I guess the solution is to just relink using the new production release of numpy 1.5.0
>
>        -Jim
>
> On Aug 17, 2010, at 6:44 PM, Bruce Sherwood wrote:
>
>> Aha. I see that there is indeed now a numpy download for Python 3.1,
>> posted for the first time today!
>>
>> I'll make a note about the beta numpy status on the vpython.org
>> download pages. I did check that VPython demo programs that use numpy
>> in a significant way work fine (gas, stars).
>>
>> Bruce Sherwood
>>
>> On Tue, Aug 17, 2010 at 1:36 PM, James Mueller <mu...@pi...> wrote:
>>> Bruce,
>>>        Two points:
>>>
>>> 1) the 1.5 series supports BOTH python 3 as well as 2.7.  The major advance they made this year was discovering that they could support both from the same code base.
>>>
>>> 2) numpy-1.5.0b1 is the first BETA release of the 1.5 series.  Release notes for a VPython using this numpy should clearly state that it is beta.  In fact the second beta was release about 4 hours ago.
>>>
>>> -Jim
>>>
>>> On Aug 17, 2010, at 12:56 PM, Bruce Sherwood wrote:
>>>
>>>> Here's what I used.
>>>>
>>>> Windows: numpy-1.5.0b1-win32-superpack-python2.7.exe
>>>> Mac: numpy-1.5.0b1-py2.7-python.org.dmg
>>>>
>>>> So it's 1.5.0b1, but it's definitely for Python 2.7, not Python 3.
>>>>
>>>> FYI, I happened to use Boost 1.42 on Windows and Boost 1.43 on Mac.
>>>>
>>>> Bruce Sherwood
>>>>
>>>> On Tue, Aug 17, 2010 at 6:50 AM, James Mueller <mu...@pi...> wrote:
>>>>> Bruce,
>>>>>        Which version of numpy was used for this?  1.3.0, 1.4.1, 1.5.0b1? (I doubt it is the beta release of 1.5, as that is aimed at python 3.)
>>>>>
>>>>> -Jim
>>>>>
>>>>> On Aug 16, 2010, at 11:34 PM, Bruce Sherwood wrote:
>>>>>
>>>>>> Visual 5.32, which has been available for Python 2.6, is now available
>>>>>> for Python 2.7 for Windows and Mac.
>>>>>>
>>>>>> This became possible with the release of Numpy for Python 2.7.
>>>>>>
>>>>>> It has been announced that Python 2.7 will be the last of the Python
>>>>>> 2.x series. Major development is now concentrated on Python 3, the
>>>>>> first version of Python to have intentional incompatibilities with the
>>>>>> Python 2 series, though there are some tools in Python 2.7 for easing
>>>>>> the transition. There is not yet a version of Numpy for Python 3,
>>>>>> which is why there is no VPython yet for Python 3.
>>>>>>
>>>>>> Bruce Sherwood
>>>>>>
>>>>>> P.S. Technical note: The file MAC-OSX.txt in CVS now has much
>>>>>> simplified instructions for building the Boost libraries on a Mac.
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> This SF.net email is sponsored by
>>>>>>
>>>>>> Make an app they can't live without
>>>>>> Enter the BlackBerry Developer Challenge
>>>>>> http://p.sf.net/sfu/RIM-dev2dev
>>>>>> _______________________________________________
>>>>>> Visualpython-users mailing list
>>>>>> Vis...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by
>>>>
>>>> Make an app they can't live without
>>>> Enter the BlackBerry Developer Challenge
>>>> http://p.sf.net/sfu/RIM-dev2dev
>>>> _______________________________________________
>>>> Visualpython-users mailing list
>>>> Vis...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] Visual 5.32 now available for Python 2.7

[James M. <mu...@pi...>]

Bruce,
	Now that classes are starting and students are going to the download site, I am a little disturbed to see that the version of visual presented for students to download is the one linked vs the first beta version of numpy 1.5.0.  To download a version linked against a production version of numpy requires going to the "older versions" page and trying to figure out what you are getting.  For instance, which version would one download if one wanted to stick to the production version of numpy?  Could we please have a section of the download pages that will link to stable versions to download?  
	Beta versions are not meant to be stable.  I note that since the "current" version of visual was built, there have been two updates to the numpy beta released, and as I typed this email, the final version was released.  So I guess the solution is to just relink using the new production release of numpy 1.5.0

	-Jim

On Aug 17, 2010, at 6:44 PM, Bruce Sherwood wrote:

> Aha. I see that there is indeed now a numpy download for Python 3.1,
> posted for the first time today!
> 
> I'll make a note about the beta numpy status on the vpython.org
> download pages. I did check that VPython demo programs that use numpy
> in a significant way work fine (gas, stars).
> 
> Bruce Sherwood
> 
> On Tue, Aug 17, 2010 at 1:36 PM, James Mueller <mu...@pi...> wrote:
>> Bruce,
>>        Two points:
>> 
>> 1) the 1.5 series supports BOTH python 3 as well as 2.7.  The major advance they made this year was discovering that they could support both from the same code base.
>> 
>> 2) numpy-1.5.0b1 is the first BETA release of the 1.5 series.  Release notes for a VPython using this numpy should clearly state that it is beta.  In fact the second beta was release about 4 hours ago.
>> 
>> -Jim
>> 
>> On Aug 17, 2010, at 12:56 PM, Bruce Sherwood wrote:
>> 
>>> Here's what I used.
>>> 
>>> Windows: numpy-1.5.0b1-win32-superpack-python2.7.exe
>>> Mac: numpy-1.5.0b1-py2.7-python.org.dmg
>>> 
>>> So it's 1.5.0b1, but it's definitely for Python 2.7, not Python 3.
>>> 
>>> FYI, I happened to use Boost 1.42 on Windows and Boost 1.43 on Mac.
>>> 
>>> Bruce Sherwood
>>> 
>>> On Tue, Aug 17, 2010 at 6:50 AM, James Mueller <mu...@pi...> wrote:
>>>> Bruce,
>>>>        Which version of numpy was used for this?  1.3.0, 1.4.1, 1.5.0b1? (I doubt it is the beta release of 1.5, as that is aimed at python 3.)
>>>> 
>>>> -Jim
>>>> 
>>>> On Aug 16, 2010, at 11:34 PM, Bruce Sherwood wrote:
>>>> 
>>>>> Visual 5.32, which has been available for Python 2.6, is now available
>>>>> for Python 2.7 for Windows and Mac.
>>>>> 
>>>>> This became possible with the release of Numpy for Python 2.7.
>>>>> 
>>>>> It has been announced that Python 2.7 will be the last of the Python
>>>>> 2.x series. Major development is now concentrated on Python 3, the
>>>>> first version of Python to have intentional incompatibilities with the
>>>>> Python 2 series, though there are some tools in Python 2.7 for easing
>>>>> the transition. There is not yet a version of Numpy for Python 3,
>>>>> which is why there is no VPython yet for Python 3.
>>>>> 
>>>>> Bruce Sherwood
>>>>> 
>>>>> P.S. Technical note: The file MAC-OSX.txt in CVS now has much
>>>>> simplified instructions for building the Boost libraries on a Mac.
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by
>>>>> 
>>>>> Make an app they can't live without
>>>>> Enter the BlackBerry Developer Challenge
>>>>> http://p.sf.net/sfu/RIM-dev2dev
>>>>> _______________________________________________
>>>>> Visualpython-users mailing list
>>>>> Vis...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>> 
>>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by
>>> 
>>> Make an app they can't live without
>>> Enter the BlackBerry Developer Challenge
>>> http://p.sf.net/sfu/RIM-dev2dev
>>> _______________________________________________
>>> Visualpython-users mailing list
>>> Vis...@li...
>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>> 
>> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] VPython works on Python 3

[James M. <mu...@pi...>]

Bruce,
	Just posted to the numpy list:
> I am pleased to announce the availability of the first release candidate of NumPy 1.5.0. This will be the first NumPy release to include support for Python 3, as well as for Python 2.7. 
> 
> Please try this RC and report any problems on the NumPy mailing list. Especially with Python 3 testing will be very useful. On Linux and OS X building from source should be straightforward, for Windows a binary installer is provided. 
> 
> Binaries, sources and release notes can be found at
> https://sourceforge.net/projects/numpy/files/
> 
> Enjoy,
So support for python 3 is getting very close to official stage now.

-Jim

On Aug 21, 2010, at 9:53 AM, Peter Borcherds wrote:

> Dear Bruce
> 
> Thank you for this excellent news, I am sure I am not the only member of the vpython community who recognises the enormous debt we owe you and your colleagues.
> 
> Regards
> 
> Peter
> 
> P H Borcherds  +44 [0] 121 475 3029
> ________________________________
> From: Bruce Sherwood [bas...@nc...]
> Sent: 21 August 2010 06:28
> To: vpusers
> Subject: [Visualpython-users] VPython works on Python 3
> 
> After quite a lot of changes to FontTools and a few changes to
> ttfquery, I've managed to get 3D text working on Python 3, which was
> the last thing needed to make a Python 3 version of VPython. I'll be
> in France for a couple weeks so there won't be a Python 3 version
> instantly, as I need to clean up some stuff. I'm accompanying Ruth
> Chabay, who has been invited to give a talk at an international
> physics education conference in Reims. She's going to talk about the
> computational modeling our physics students do using VPython.
> 
> The problems I had to overcome were of course in areas where the 2to3
> conversion just couldn't do the job, due to data interpretation
> issues. I even found a couple of cases in ttfquery where there was N/2
> (giving 1.5 if N is 3) which should have been N//2 (giving 1 if N is
> 3). There was also a case of map returning a map instead of a list,
> and list(map(....)) wouldn't work.
> 
> Bruce Sherwood
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Segmentation Fault

[Samuel P. <sam...@gm...>]

Hi Nicolas,

I do experience the same "too slow" behavior on VPython with my
integrated Intel graphics card. Other OpenGL applications run smoothly. I
also get the weird message:
i915_program_error: Exceeded max instructions
<visual.primitives.sphere object at 0x2314c58>

Have you (or anybody in the list) found a fix for this annoyance? It makes
my VPython applications unusable!

Regards,
Samuel

On Wed, Aug 18, 2010 at 2:34 AM, Nicolas Bigaouette
<nbi...@gm...>wrote:

> 2010/8/17 Guenter Schneider <Gue...@ph...>
>
>> I am not surprised that visual runs on nvidia. I never had problems
>> before. For ATI cards the following worked for me (note that my problem was
>> never a complete crash on import but a seg fault for particular commands,
>> but it may work for you).
>>
>> import wx
>> import visual
>>
>> The rational is that wx has proper initialization for opengl while visual
>> does not.
>>
>> Guenter
>>
>
> Wow, ok, so that made it:
>
>> $ python
>> Python 2.6.5 (r265:79063, Aug 17 2010, 14:03:21)
>> [GCC 4.5.1] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import wx
>> >>> import visual
>> >>> visual.sphere()
>> i915_program_error: Exceeded max instructions
>> <visual.primitives.sphere object at 0x22d47e0>
>>
> and I see a sphere.
>
> I just tried my script and it seems to work. But it is really slow compared
> to pymol with the same data, even on the intel card.. On the nvidia card,
> it's blazing fast...
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

Re: [Visualpython-users] VPython works on Python 3

[Peter B. <p.h...@bh...>]

Dear Bruce

Thank you for this excellent news, I am sure I am not the only member of the vpython community who recognises the enormous debt we owe you and your colleagues.

Regards

Peter

P H Borcherds  +44 [0] 121 475 3029
________________________________
From: Bruce Sherwood [bas...@nc...]
Sent: 21 August 2010 06:28
To: vpusers
Subject: [Visualpython-users] VPython works on Python 3

After quite a lot of changes to FontTools and a few changes to
ttfquery, I've managed to get 3D text working on Python 3, which was
the last thing needed to make a Python 3 version of VPython. I'll be
in France for a couple weeks so there won't be a Python 3 version
instantly, as I need to clean up some stuff. I'm accompanying Ruth
Chabay, who has been invited to give a talk at an international
physics education conference in Reims. She's going to talk about the
computational modeling our physics students do using VPython.

The problems I had to overcome were of course in areas where the 2to3
conversion just couldn't do the job, due to data interpretation
issues. I even found a couple of cases in ttfquery where there was N/2
(giving 1.5 if N is 3) which should have been N//2 (giving 1 if N is
3). There was also a case of map returning a map instead of a list,
and list(map(....)) wouldn't work.

Bruce Sherwood

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Visualpython-users mailing list
Vis...@li...
https://lists.sourceforge.net/lists/listinfo/visualpython-users

[Visualpython-users] VPython works on Python 3

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

After quite a lot of changes to FontTools and a few changes to
ttfquery, I've managed to get 3D text working on Python 3, which was
the last thing needed to make a Python 3 version of VPython. I'll be
in France for a couple weeks so there won't be a Python 3 version
instantly, as I need to clean up some stuff. I'm accompanying Ruth
Chabay, who has been invited to give a talk at an international
physics education conference in Reims. She's going to talk about the
computational modeling our physics students do using VPython.

The problems I had to overcome were of course in areas where the 2to3
conversion just couldn't do the job, due to data interpretation
issues. I even found a couple of cases in ttfquery where there was N/2
(giving 1.5 if N is 3) which should have been N//2 (giving 1 if N is
3). There was also a case of map returning a map instead of a list,
and list(map(....)) wouldn't work.

Bruce Sherwood