visualpython-users

Re: [Visualpython-users] Keeping labels in one place

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

You could put the time in an adjoining separate little window.

Bruce Sherwood

On Sat, Jul 17, 2010 at 5:09 PM, Robert French <rf...@rf...> wrote:

> Yes, C Anthony is correct. I want it to stay at an absolute pixel
> coordinate (2-D) in the window. Completely unaffected by any rotations or
> zooms.  The existing objects all move with the frame.
>
> I had thought about the constantly-reposition option but was hoping there
> was something easier.  This seems like it would be a common desire. For
> example, to put a title or timestamp or something in the display window.
>
> I'll try those suggestions and see if I can get it to work
>
> BTW, my application is orbit visualization of spacecraft. I just want the
> date and time to stay in one place.
>
> Thanks.
>
> On Jul 17, 2010, at 11:20 AM, C Anthony Risinger <an...@ex...> wrote:
>
> >
> >
> > On Sat, Jul 17, 2010 at 1:07 PM, Bruce Sherwood <bas...@nc...>
> wrote:
> >> The current version of VPython (5.32) offers a text object as well as a
> >> label object. The label object always faces the viewer, independent of
> >> rotation, whereas the (new) text object is extruded text that behaves
> like
> >> all other objects. Seems like one of these two should do what you want.
> The
> >> text object can have zero thickness.
> >> I'm not sure what you mean by a "time" display, but presumably you know
> >> about the graphing option.
> >> Bruce Sherwood
> >
> > i think what the OP is looking for is HUD functionality, ie. the
> > "time" display stays locked to the viewport, regardless of zoom or
> > rotation.
> >
> > AFIAK this is not currently supported in vpython.  however, the same
> > effect can be achieved by using a "HUD frame" and constantly
> > recomputing it's position/zoom/rotation as the main frame moves.  the
> > other option is to put your app into a "container" frame, and ensure
> > the main frame never moves... anything added to the main frame is a
> > part of the HUD; i think the issue with this was mouse grabs are sent
> > to the main frame (IIRC).  sorry, i don't have any code examples on
> > hand :-(
> >
> > C Anthony
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > Visualpython-users mailing list
> > Vis...@li...
> > https://lists.sourceforge.net/lists/listinfo/visualpython-users
> >
> >
> > --
> > Limited filtering has been provided due to external email forwarding.
> > For details please review:
> http://www.onlymyemail.com/faqs/forwarding.html
> >
>

Re: [Visualpython-users] Keeping labels in one place

[Robert F. <rf...@rf...>]

Yes, C Anthony is correct. I want it to stay at an absolute pixel coordinate (2-D) in the window. Completely unaffected by any rotations or zooms.  The existing objects all move with the frame. 

I had thought about the constantly-reposition option but was hoping there was something easier.  This seems like it would be a common desire. For example, to put a title or timestamp or something in the display window.

I'll try those suggestions and see if I can get it to work

BTW, my application is orbit visualization of spacecraft. I just want the date and time to stay in one place.

Thanks.  

On Jul 17, 2010, at 11:20 AM, C Anthony Risinger <an...@ex...> wrote:

> 
> 
> On Sat, Jul 17, 2010 at 1:07 PM, Bruce Sherwood <bas...@nc...> wrote:
>> The current version of VPython (5.32) offers a text object as well as a
>> label object. The label object always faces the viewer, independent of
>> rotation, whereas the (new) text object is extruded text that behaves like
>> all other objects. Seems like one of these two should do what you want. The
>> text object can have zero thickness.
>> I'm not sure what you mean by a "time" display, but presumably you know
>> about the graphing option.
>> Bruce Sherwood
> 
> i think what the OP is looking for is HUD functionality, ie. the
> "time" display stays locked to the viewport, regardless of zoom or
> rotation.
> 
> AFIAK this is not currently supported in vpython.  however, the same
> effect can be achieved by using a "HUD frame" and constantly
> recomputing it's position/zoom/rotation as the main frame moves.  the
> other option is to put your app into a "container" frame, and ensure
> the main frame never moves... anything added to the main frame is a
> part of the HUD; i think the issue with this was mouse grabs are sent
> to the main frame (IIRC).  sorry, i don't have any code examples on
> hand :-(
> 
> C Anthony
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
> 
> 
> --
> Limited filtering has been provided due to external email forwarding.
> For details please review: http://www.onlymyemail.com/faqs/forwarding.html
> 

Re: [Visualpython-users] Keeping labels in one place

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

On Sat, Jul 17, 2010 at 1:07 PM, Bruce Sherwood <bas...@nc...> wrote:
> The current version of VPython (5.32) offers a text object as well as a
> label object. The label object always faces the viewer, independent of
> rotation, whereas the (new) text object is extruded text that behaves like
> all other objects. Seems like one of these two should do what you want. The
> text object can have zero thickness.
> I'm not sure what you mean by a "time" display, but presumably you know
> about the graphing option.
> Bruce Sherwood

i think what the OP is looking for is HUD functionality, ie. the
"time" display stays locked to the viewport, regardless of zoom or
rotation.

AFIAK this is not currently supported in vpython.  however, the same
effect can be achieved by using a "HUD frame" and constantly
recomputing it's position/zoom/rotation as the main frame moves.  the
other option is to put your app into a "container" frame, and ensure
the main frame never moves... anything added to the main frame is a
part of the HUD; i think the issue with this was mouse grabs are sent
to the main frame (IIRC).  sorry, i don't have any code examples on
hand :-(

C Anthony

Re: [Visualpython-users] A donut with a hole

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

In the contributed section of vpython.org there is this:

New objects <http://vpython.org/contents/contributed/bodies.py>: hollow
tube, frustum (cone with tip cut off), and partial sphere (Thom Ives)

These objects depend on the very general faces object, which in principle
can be used to build anything but in practice can be effortful.

I'll mention in this context that thanks to the work of Kadir Haldenbilen
that led to the new 3D text object, plus some additional experimenting he
has been doing, he and I think it will be possible to augment the curve
object to have an arbitrary cross section, easily created, which can include
holes. That's the good news. The bad news is that I'm consumed by other
professional work for the next couple of months that will delay the attempt.

Bruce Sherwood

On Fri, Jul 16, 2010 at 11:16 PM, Robert French <rf...@rf...> wrote:

> I would like to create a flat, circular plate that has a hole in it.  It
> seems like I could create a solid circular plate using "convex" with
> sufficient points, or even "cylinder", but I can't figure out how to make
> the center empty.  Any thoughts?
>
> Thanks.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] Keeping labels in one place

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

The current version of VPython (5.32) offers a text object as well as a
label object. The label object always faces the viewer, independent of
rotation, whereas the (new) text object is extruded text that behaves like
all other objects. Seems like one of these two should do what you want. The
text object can have zero thickness.

I'm not sure what you mean by a "time" display, but presumably you know
about the graphing option.

Bruce Sherwood

On Fri, Jul 16, 2010 at 11:16 PM, Robert French <rf...@rf...> wrote:

> Hi,
>
> I would like to display text in the graphics window (at an absolute pixel
> coordinate) that does not move when the user rotates or zooms.  For
> example, consider the need to put a "time" display for a running
> simulation.  I've looked through the mailing list archives, and the code,
> and can't find a way to do this, but it seems like a basic function.  Is
> there some way to do this?
>
> Thanks.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

[Visualpython-users] A donut with a hole

[Robert F. <rf...@rf...>]

I would like to create a flat, circular plate that has a hole in it.  It
seems like I could create a solid circular plate using "convex" with
sufficient points, or even "cylinder", but I can't figure out how to make
the center empty.  Any thoughts?

Thanks.

[Visualpython-users] Keeping labels in one place

[Robert F. <rf...@rf...>]

Hi,

I would like to display text in the graphics window (at an absolute pixel
coordinate) that does not move when the user rotates or zooms.  For
example, consider the need to put a "time" display for a running
simulation.  I've looked through the mailing list archives, and the code,
and can't find a way to do this, but it seems like a basic function.  Is
there some way to do this?

Thanks.

Re: [Visualpython-users] Python 2.7

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

This is good news, that numpy is coming (for both 2.7 and 3.x). Thanks for
the update.

Bruce Sherwood

On Fri, Jul 16, 2010 at 8:29 AM, Gary Ruben <gr...@bi...> wrote:

> Hey Bruce,
>
> There was a recent positive announcement about this on the numpy list:
> <http://www.mail-archive.com/num...@sc.../msg26524.html>
>
> Gary R.
>
> Bruce Sherwood wrote:
> > I looked into building Visual for Python 2.7 but found that there does
> > not yet exist a numpy for Python 2.7 (or for the Python 3 series). So
> > this will have to wait.
> >
> > Bruce Sherwood
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] Python 2.7

[Gary R. <gr...@bi...>]

Hey Bruce,

There was a recent positive announcement about this on the numpy list:
<http://www.mail-archive.com/num...@sc.../msg26524.html>

Gary R.

Bruce Sherwood wrote:
> I looked into building Visual for Python 2.7 but found that there does 
> not yet exist a numpy for Python 2.7 (or for the Python 3 series). So 
> this will have to wait.
> 
> Bruce Sherwood

Re: [Visualpython-users] Python 2.7

[Gary R. <gr...@bi...>]

Hey Bruce,

There was a recent positive announcement about this on the numpy list:
<http://www.mail-archive.com/num...@sc.../msg26524.html>

Gary R.

Bruce Sherwood wrote:
> I looked into building Visual for Python 2.7 but found that there does 
> not yet exist a numpy for Python 2.7 (or for the Python 3 series). So 
> this will have to wait.
> 
> Bruce Sherwood

[Visualpython-users] Python 2.7

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

I looked into building Visual for Python 2.7 but found that there does not
yet exist a numpy for Python 2.7 (or for the Python 3 series). So this will
have to wait.

Bruce Sherwood

Re: [Visualpython-users] Problem installing on Mac (non-default python location perhaps?)

[Guy K. K. <g....@ma...>]

On Thu, 15 Jul 2010 16:26:53 K.-Michael Aye wrote:
> Just wondered, are you guys aware of the fact, that Enthought comes with an
> implementation of VPython?  It does not feel exactly like the full one
> because it's running in a tvtk window, but it is otherwise quite usable.
> It's inside the mayavi library.

I've given it a spin last year. At that time it was a spinoff of the VPython 
3.x API. Due to the fact that Mayavi2 is very powerful in its features,  
VPython has to deal with less overhead, and is quite a lot more performant for 
great numbers of individual objects. Also there were quite a few glitches in 
the implementation. But of course, it was usable for many/certain cases.

I've given a talk and written about it (among other things) at the last Kiwi 
PyCon last November. 

"Python Data Plotting and Visualisation Extravaganza"
http://ojs.pythonpapers.org/index.php/tppm/article/view/121
http://kiwipycon.blip.tv/file/3849517/

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. 9266   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss

Re: [Visualpython-users] Problem installing on Mac (non-default python location perhaps?)

[K.-Michael A. <ay...@sp...>]

Just wondered, are you guys aware of the fact, that Enthought comes with an implementation of VPython? 
It does not feel exactly like the full one because it's running in a tvtk window, but it is otherwise quite usable. 
It's inside the mayavi library. 

Br,
Michael

Sent from my iPhone

On 15.07.2010, at 00:51, vis...@li... wrote:

> Re: Problem installing on Mac (non-default    python location
>      perhaps?)

Re: [Visualpython-users] Problem installing on Mac (non-default python location perhaps?)

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

Ahh.  So, unless you need something that depends on the datetime feature, it is best to avoid Enthought until numpy 2.0.  If you need Enthought, you need to build visual yourself to match your version of numpy.

As an experiment, I just started going the other way, start with a basic vpython install and then add other packages to it.  

A download of the most recent scipy 0.7.2 binary works. I didn't try the release candidate of 0.8.

A download of the most recent matplotlib (1.0.0) does not, but version 0.99.1 from September does.  I think this indicates that the most recent binaries require numpy 1.4.1.  I assume Bruce will get around to updating the VPython build to use the most recent numpy at sometime, 

That is about 95% of what I have used, and it is easy enough that I might be able to require a physics major to do it on their machine.  For engineers, it is about 99% of what they would use Matlab for.  The best thing about PythonXY is that if you are using more than visual in a course, you can just tell students to get PythonXY, and they have everything you might ever want.  With Enthought, you have to make sure you build them a visual that matches the enthought version of numpy.

> 
> Oh ... Enthought consciously chose to stick with 1.4.0 because they wanted to retain the datetime feature. (This was the crux of a long discussion on the numpy list a while back.) They plan to stick with 1.4.0 until 2.0 comes out. 

Re: [Visualpython-users] Problem installing on Mac (non-default python location perhaps?)

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

On Wed, Jul 14, 2010 at 3:26 PM, James Mueller <mu...@pi...> wrote:

>
> On Jul 14, 2010, at 1:43 PM, Gary Pajer wrote:
>
> Yow.  I guess that's what happens when two people try to make life easy for
> the end user by producing one-click installers.  There are
> packaging/installation systems that are supposed to take care of version
> dependency, but as far as I can tell they come with there own set of
> problems.
>
> This conflict should arise on Windows, too, shouldn't it?  Evidently it's
> rare that someone wants both Vpython and Enthought... one has to wonder if
> it's worth the effort to fix (if it's fixable at all).  Of course, I have my
> own opinion on that matter.
>
> The PythonXY distribution is much better than Enthought, but that is due to
> the fact that they only support windows and can concentrate on doing one
> platform well.  They have dozens of python packages including visual, so it
> really is one-stop shopping.
>
>
> As of today Enthought Python Distribution ships with numpy 1.3, but it
> doesn't really make sense for Vpython's tail to be wagged by Enthought.  On
> the other hand, if Vpython's installer is overwriting Enthought's
> installation (or vice versa), that's no good either.
>
> I just downoaded the 6.2 version and it came with numpy 1.4.0!  This is the
> version of numpy that was pulled due to ABI breakages. I can't see mixing
> this with the 1.3 version that visual builds against.  You might be able to
> install a visual built against numpy 1.4.1.  I don't know why Enthought
> doesn't update to 1.4.1.
>


Oh ... Enthought consciously chose to stick with 1.4.0 because they wanted
to retain the datetime feature. (This was the crux of a long discussion on
the numpy list a while back.) They plan to stick with 1.4.0 until 2.0 comes
out.

Re: [Visualpython-users] Problem installing on Mac (non-default python location perhaps?)

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

On Wed, Jul 14, 2010 at 3:26 PM, James Mueller <mu...@pi...> wrote:

>
> On Jul 14, 2010, at 1:43 PM, Gary Pajer wrote:
>
> Yow.  I guess that's what happens when two people try to make life easy for
> the end user by producing one-click installers.  There are
> packaging/installation systems that are supposed to take care of version
> dependency, but as far as I can tell they come with there own set of
> problems.
>
> This conflict should arise on Windows, too, shouldn't it?  Evidently it's
> rare that someone wants both Vpython and Enthought... one has to wonder if
> it's worth the effort to fix (if it's fixable at all).  Of course, I have my
> own opinion on that matter.
>
> The PythonXY distribution is much better than Enthought, but that is due to
> the fact that they only support windows and can concentrate on doing one
> platform well.  They have dozens of python packages including visual, so it
> really is one-stop shopping.
>
>
> As of today Enthought Python Distribution ships with numpy 1.3, but it
> doesn't really make sense for Vpython's tail to be wagged by Enthought.  On
> the other hand, if Vpython's installer is overwriting Enthought's
> installation (or vice versa), that's no good either.
>
> I just downoaded the 6.2 version and it came with numpy 1.4.0!  This is the
> version of numpy that was pulled due to ABI breakages. I can't see mixing
> this with the 1.3 version that visual builds against.  You might be able to
> install a visual built against numpy 1.4.1.  I don't know why Enthought
> doesn't update to 1.4.1.
>


(AHA!!)**2

Of course, I installed Vpython after I installed EPD, so numpy 1.4.0 was
overwritten by 1.3.0  ... I failed to heed my own warning.  Ugh.





>
> This is like what I had two years ago when enthought had numpy 1.1 and
> VPython had 1.2
>
>
> James, after you built Vpython, what ended up broken?  It may turn out that
> your solution is the practical one for people in this situation.
>
> This was two years ago, so it might be different now, but then there were
> conflicts between the visual and matplotlib.
> Each one wanting to control the event loop.  You could load both of them,
> but you had to make sure that you didn't have a matplotlib graph window and
> a visual display window open at the same time.
>
> The question is, "what packages in the enthought distribution do you want?
>  Is it easier to add them to a VPython install, or add visual to an
> enthought install.
>
> -Jim
>
>
>
> -g
>
> On Wed, Jul 14, 2010 at 1:02 PM, James Mueller <mu...@pi...> wrote:
>
>> Bruce,
>> It is actually a little worse.  When I dealt with this two years ago, an
>> additional problem was that the numpy that came with enthought was different
>> from the one in the visual package.  So, after installing visual, the extra
>> packages in the Enthought distribution like scipy would crash;  if I went
>> back to enthought's numpy, then visual would crash.  I finally found it
>> easier to install the enthought distribution and then build visual using the
>> enthought numpy.
>>  -Jim
>>
>> On Jul 14, 2010, at 12:47 PM, Bruce Sherwood wrote:
>>
>> This suggests that I should make available an optional VPython installer
>> that checks for a Python being available but not check for the version at
>> all, leaving it to the person doing the installing the responsibility for
>> having an appropriate level of Python installed. Gary, as a test you might
>> install VPython on the standard Python 2.6 (maybe on a different Mac) and
>> save a copy of the files that go into site-packages, then on your Enthought
>> machine just copy those files into site-packages. If the Enthought Python is
>> in fact an instance of Python 2.6, this should work.
>>
>> If you do this experiment, please let me know, as I don't have an
>> Enthought installation to try this on myself.
>>
>> Bruce Sherwood
>>
>> On Wed, Jul 14, 2010 at 9:55 AM, Gary Pajer <gar...@gm...> wrote:
>>
>>> You're right.  Here's a snippet of my conversation with them:
>>>
>>> ----------------------------------------------------------
>>>  > The Mac EPD installer has a directory named
>>> >
>>> > /Library/Frameworks/Python.framework/Versions/6.2
>>> >
>>> > But the Vpython installer checks to see if exists:
>>>
>>> >
>>> > /Library/Frameworks/Python.framework/Versions/2.6
>>> >
>>> > I rather suspect that the "6.2" is a typo.  Simply renaming the
>>> directory
>>> > name doesn't work ... stuff doesn't get found.
>>>
>>> No, the "6.2" refers to the EPD version, not the python version. It
>>> sounds like Vpython is either hardcoded to look at that dir, rather
>>> than use sys.prefix, or you're using the system python to install it.
>>> --------------------------------------------------
>>>
>>> So the ball is back in Vpython's court: the installer should look for
>>> sys.prefix ???
>>>
>>>
>>>
>>> On Wed, Jul 14, 2010 at 11:43 AM, James Mueller <mu...@pi...>wrote:
>>>
>>>> No, this is exactly what they want.  6.2 is the version of the Enthought
>>>> distribution.  It doesn't agree with the python version, so perhaps this is
>>>> a bad choice on their part, but I don't think they would consider it a bug.
>>>>
>>>> -Jim
>>>>
>>>>
>>>>
>>>>
>> <ATT00001..txt><ATT00002..txt>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>
>>
> <ATT00001..txt><ATT00002..txt>
>
>
>

Re: [Visualpython-users] Problem installing on Mac (non-default python location perhaps?)

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

On Jul 14, 2010, at 1:43 PM, Gary Pajer wrote:

> Yow.  I guess that's what happens when two people try to make life easy for the end user by producing one-click installers.  There are packaging/installation systems that are supposed to take care of version dependency, but as far as I can tell they come with there own set of problems.
> 
> This conflict should arise on Windows, too, shouldn't it?  Evidently it's rare that someone wants both Vpython and Enthought... one has to wonder if it's worth the effort to fix (if it's fixable at all).  Of course, I have my own opinion on that matter.
The PythonXY distribution is much better than Enthought, but that is due to the fact that they only support windows and can concentrate on doing one platform well.  They have dozens of python packages including visual, so it really is one-stop shopping.
> 
> As of today Enthought Python Distribution ships with numpy 1.3, but it doesn't really make sense for Vpython's tail to be wagged by Enthought.  On the other hand, if Vpython's installer is overwriting Enthought's installation (or vice versa), that's no good either.
I just downoaded the 6.2 version and it came with numpy 1.4.0!  This is the version of numpy that was pulled due to ABI breakages. I can't see mixing this with the 1.3 version that visual builds against.  You might be able to install a visual built against numpy 1.4.1.  I don't know why Enthought doesn't update to 1.4.1.

This is like what I had two years ago when enthought had numpy 1.1 and VPython had 1.2
> 
> James, after you built Vpython, what ended up broken?  It may turn out that your solution is the practical one for people in this situation.
This was two years ago, so it might be different now, but then there were conflicts between the visual and matplotlib.
Each one wanting to control the event loop.  You could load both of them, but you had to make sure that you didn't have a matplotlib graph window and a visual display window open at the same time.

The question is, "what packages in the enthought distribution do you want?  Is it easier to add them to a VPython install, or add visual to an enthought install.

-Jim


> 
> -g
> 
> On Wed, Jul 14, 2010 at 1:02 PM, James Mueller <mu...@pi...> wrote:
> Bruce,
> 	It is actually a little worse.  When I dealt with this two years ago, an additional problem was that the numpy that came with enthought was different from the one in the visual package.  So, after installing visual, the extra packages in the Enthought distribution like scipy would crash;  if I went back to enthought's numpy, then visual would crash.  I finally found it easier to install the enthought distribution and then build visual using the enthought numpy.
> 	
> -Jim
> 
> On Jul 14, 2010, at 12:47 PM, Bruce Sherwood wrote:
> 
>> This suggests that I should make available an optional VPython installer that checks for a Python being available but not check for the version at all, leaving it to the person doing the installing the responsibility for having an appropriate level of Python installed. Gary, as a test you might install VPython on the standard Python 2.6 (maybe on a different Mac) and save a copy of the files that go into site-packages, then on your Enthought machine just copy those files into site-packages. If the Enthought Python is in fact an instance of Python 2.6, this should work.
>> 
>> If you do this experiment, please let me know, as I don't have an Enthought installation to try this on myself.
>> 
>> Bruce Sherwood
>> 
>> On Wed, Jul 14, 2010 at 9:55 AM, Gary Pajer <gar...@gm...> wrote:
>> You're right.  Here's a snippet of my conversation with them:
>> 
>> ----------------------------------------------------------
>> > The Mac EPD installer has a directory named
>> >
>> > /Library/Frameworks/Python.framework/Versions/6.2
>> >
>> > But the Vpython installer checks to see if exists:
>> 
>> >
>> > /Library/Frameworks/Python.framework/Versions/2.6
>> >
>> > I rather suspect that the "6.2" is a typo.  Simply renaming the directory
>> > name doesn't work ... stuff doesn't get found.
>> 
>> No, the "6.2" refers to the EPD version, not the python version. It
>> sounds like Vpython is either hardcoded to look at that dir, rather
>> than use sys.prefix, or you're using the system python to install it.
>> --------------------------------------------------
>> 
>> So the ball is back in Vpython's court: the installer should look for sys.prefix ???
>> 
>> 
>> 
>> On Wed, Jul 14, 2010 at 11:43 AM, James Mueller <mu...@pi...> wrote:
>> No, this is exactly what they want.  6.2 is the version of the Enthought distribution.  It doesn't agree with the python version, so perhaps this is a bad choice on their part, but I don't think they would consider it a bug.
>> 
>> -Jim
>> 
>>> 
>>> 
>> 
>> <ATT00001..txt><ATT00002..txt>
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
> 
> 
> <ATT00001..txt><ATT00002..txt>

Re: [Visualpython-users] Problem installing on Mac (non-default python location perhaps?)

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

Yow.  I guess that's what happens when two people try to make life easy for
the end user by producing one-click installers.  There are
packaging/installation systems that are supposed to take care of version
dependency, but as far as I can tell they come with there own set of
problems.

This conflict should arise on Windows, too, shouldn't it?  Evidently it's
rare that someone wants both Vpython and Enthought... one has to wonder if
it's worth the effort to fix (if it's fixable at all).  Of course, I have my
own opinion on that matter.

As of today Enthought Python Distribution ships with numpy 1.3, but it
doesn't really make sense for Vpython's tail to be wagged by Enthought.  On
the other hand, if Vpython's installer is overwriting Enthought's
installation (or vice versa), that's no good either.

James, after you built Vpython, what ended up broken?  It may turn out that
your solution is the practical one for people in this situation.

-g

On Wed, Jul 14, 2010 at 1:02 PM, James Mueller <mu...@pi...> wrote:

> Bruce,
> It is actually a little worse.  When I dealt with this two years ago, an
> additional problem was that the numpy that came with enthought was different
> from the one in the visual package.  So, after installing visual, the extra
> packages in the Enthought distribution like scipy would crash;  if I went
> back to enthought's numpy, then visual would crash.  I finally found it
> easier to install the enthought distribution and then build visual using the
> enthought numpy.
> -Jim
>
> On Jul 14, 2010, at 12:47 PM, Bruce Sherwood wrote:
>
> This suggests that I should make available an optional VPython installer
> that checks for a Python being available but not check for the version at
> all, leaving it to the person doing the installing the responsibility for
> having an appropriate level of Python installed. Gary, as a test you might
> install VPython on the standard Python 2.6 (maybe on a different Mac) and
> save a copy of the files that go into site-packages, then on your Enthought
> machine just copy those files into site-packages. If the Enthought Python is
> in fact an instance of Python 2.6, this should work.
>
> If you do this experiment, please let me know, as I don't have an Enthought
> installation to try this on myself.
>
> Bruce Sherwood
>
> On Wed, Jul 14, 2010 at 9:55 AM, Gary Pajer <gar...@gm...> wrote:
>
>> You're right.  Here's a snippet of my conversation with them:
>>
>> ----------------------------------------------------------
>>  > The Mac EPD installer has a directory named
>> >
>> > /Library/Frameworks/Python.framework/Versions/6.2
>> >
>> > But the Vpython installer checks to see if exists:
>>
>> >
>> > /Library/Frameworks/Python.framework/Versions/2.6
>> >
>> > I rather suspect that the "6.2" is a typo.  Simply renaming the
>> directory
>> > name doesn't work ... stuff doesn't get found.
>>
>> No, the "6.2" refers to the EPD version, not the python version. It
>> sounds like Vpython is either hardcoded to look at that dir, rather
>> than use sys.prefix, or you're using the system python to install it.
>> --------------------------------------------------
>>
>> So the ball is back in Vpython's court: the installer should look for
>> sys.prefix ???
>>
>>
>>
>> On Wed, Jul 14, 2010 at 11:43 AM, James Mueller <mu...@pi...> wrote:
>>
>>> No, this is exactly what they want.  6.2 is the version of the Enthought
>>> distribution.  It doesn't agree with the python version, so perhaps this is
>>> a bad choice on their part, but I don't think they would consider it a bug.
>>>
>>> -Jim
>>>
>>>
>>>
>>>
> <ATT00001..txt><ATT00002..txt>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

Re: [Visualpython-users] Problem installing on Mac (non-default python location perhaps?)

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

I'd love to help... but I'm leaving town for two weeks in the morning  
and have too much going on to be much use today. I guess you'll need  
to cook up a python script to check sys.prefix and/or  
sys.version_info. The trouble is that you'll need to install stuff  
into a directory that you won't really know until you fire up python  
and check these values. You may need to install in a 'staging' area (/ 
tmp ?) and then move the packages to the target 'site-packages' folder  
once you know where they belong.

There are several places you can inject scripts that should be  
callable under different circumstances... but it sounds like it could  
get complicated. ;-)

-steve

Re: [Visualpython-users] Problem installing on Mac (non-default python location perhaps?)

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

Bruce,
	It is actually a little worse.  When I dealt with this two years ago, an additional problem was that the numpy that came with enthought was different from the one in the visual package.  So, after installing visual, the extra packages in the Enthought distribution like scipy would crash;  if I went back to enthought's numpy, then visual would crash.  I finally found it easier to install the enthought distribution and then build visual using the enthought numpy.
	
-Jim

On Jul 14, 2010, at 12:47 PM, Bruce Sherwood wrote:

> This suggests that I should make available an optional VPython installer that checks for a Python being available but not check for the version at all, leaving it to the person doing the installing the responsibility for having an appropriate level of Python installed. Gary, as a test you might install VPython on the standard Python 2.6 (maybe on a different Mac) and save a copy of the files that go into site-packages, then on your Enthought machine just copy those files into site-packages. If the Enthought Python is in fact an instance of Python 2.6, this should work.
> 
> If you do this experiment, please let me know, as I don't have an Enthought installation to try this on myself.
> 
> Bruce Sherwood
> 
> On Wed, Jul 14, 2010 at 9:55 AM, Gary Pajer <gar...@gm...> wrote:
> You're right.  Here's a snippet of my conversation with them:
> 
> ----------------------------------------------------------
> > The Mac EPD installer has a directory named
> >
> > /Library/Frameworks/Python.framework/Versions/6.2
> >
> > But the Vpython installer checks to see if exists:
> 
> >
> > /Library/Frameworks/Python.framework/Versions/2.6
> >
> > I rather suspect that the "6.2" is a typo.  Simply renaming the directory
> > name doesn't work ... stuff doesn't get found.
> 
> No, the "6.2" refers to the EPD version, not the python version. It
> sounds like Vpython is either hardcoded to look at that dir, rather
> than use sys.prefix, or you're using the system python to install it.
> --------------------------------------------------
> 
> So the ball is back in Vpython's court: the installer should look for sys.prefix ???
> 
> 
> 
> On Wed, Jul 14, 2010 at 11:43 AM, James Mueller <mu...@pi...> wrote:
> No, this is exactly what they want.  6.2 is the version of the Enthought distribution.  It doesn't agree with the python version, so perhaps this is a bad choice on their part, but I don't think they would consider it a bug.
> 
> -Jim
> 
>> 
>> 
> 
> <ATT00001..txt><ATT00002..txt>

Re: [Visualpython-users] Problem installing on Mac (non-default python location perhaps?)

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

I'll do as you ask as soon as I can get to it.

In the meantime, note that there is also a python variable that holds
information about the python version:  sys.version_info  (there are probably
other similar variables).  So with yet more work the version could be
checked.

-g

On Wed, Jul 14, 2010 at 12:47 PM, Bruce Sherwood <bas...@nc...> wrote:

> This suggests that I should make available an optional VPython installer
> that checks for a Python being available but not check for the version at
> all, leaving it to the person doing the installing the responsibility for
> having an appropriate level of Python installed. Gary, as a test you might
> install VPython on the standard Python 2.6 (maybe on a different Mac) and
> save a copy of the files that go into site-packages, then on your Enthought
> machine just copy those files into site-packages. If the Enthought Python is
> in fact an instance of Python 2.6, this should work.
>
> If you do this experiment, please let me know, as I don't have an Enthought
> installation to try this on myself.
>
> Bruce Sherwood
>
>
> On Wed, Jul 14, 2010 at 9:55 AM, Gary Pajer <gar...@gm...> wrote:
>
>> You're right.  Here's a snippet of my conversation with them:
>>
>> ----------------------------------------------------------
>>  > The Mac EPD installer has a directory named
>> >
>> > /Library/Frameworks/Python.framework/Versions/6.2
>> >
>> > But the Vpython installer checks to see if exists:
>>
>> >
>> > /Library/Frameworks/Python.framework/Versions/2.6
>> >
>> > I rather suspect that the "6.2" is a typo.  Simply renaming the
>> directory
>> > name doesn't work ... stuff doesn't get found.
>>
>> No, the "6.2" refers to the EPD version, not the python version. It
>> sounds like Vpython is either hardcoded to look at that dir, rather
>> than use sys.prefix, or you're using the system python to install it.
>> --------------------------------------------------
>>
>> So the ball is back in Vpython's court: the installer should look for
>> sys.prefix ???
>>
>>
>>
>> On Wed, Jul 14, 2010 at 11:43 AM, James Mueller <mu...@pi...> wrote:
>>
>>> No, this is exactly what they want.  6.2 is the version of the Enthought
>>> distribution.  It doesn't agree with the python version, so perhaps this is
>>> a bad choice on their part, but I don't think they would consider it a bug.
>>>
>>> -Jim
>>>
>>>
>>>
>>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

Re: [Visualpython-users] Problem installing on Mac (non-default python location perhaps?)

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

This suggests that I should make available an optional VPython installer
that checks for a Python being available but not check for the version at
all, leaving it to the person doing the installing the responsibility for
having an appropriate level of Python installed. Gary, as a test you might
install VPython on the standard Python 2.6 (maybe on a different Mac) and
save a copy of the files that go into site-packages, then on your Enthought
machine just copy those files into site-packages. If the Enthought Python is
in fact an instance of Python 2.6, this should work.

If you do this experiment, please let me know, as I don't have an Enthought
installation to try this on myself.

Bruce Sherwood

On Wed, Jul 14, 2010 at 9:55 AM, Gary Pajer <gar...@gm...> wrote:

> You're right.  Here's a snippet of my conversation with them:
>
> ----------------------------------------------------------
> > The Mac EPD installer has a directory named
> >
> > /Library/Frameworks/Python.framework/Versions/6.2
> >
> > But the Vpython installer checks to see if exists:
>
> >
> > /Library/Frameworks/Python.framework/Versions/2.6
> >
> > I rather suspect that the "6.2" is a typo.  Simply renaming the directory
> > name doesn't work ... stuff doesn't get found.
>
> No, the "6.2" refers to the EPD version, not the python version. It
> sounds like Vpython is either hardcoded to look at that dir, rather
> than use sys.prefix, or you're using the system python to install it.
> --------------------------------------------------
>
> So the ball is back in Vpython's court: the installer should look for
> sys.prefix ???
>
>
>
> On Wed, Jul 14, 2010 at 11:43 AM, James Mueller <mu...@pi...> wrote:
>
>> No, this is exactly what they want.  6.2 is the version of the Enthought
>> distribution.  It doesn't agree with the python version, so perhaps this is
>> a bad choice on their part, but I don't think they would consider it a bug.
>>
>> -Jim
>>
>>
>>
>>

Re: [Visualpython-users] Problem installing on Mac (non-default python location perhaps?)

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

This is very helpful. Thanks much! So I need to find out (or someone needs
to tell me) how to get PackageMaker to look for an installed Python, not a
python.org Python.

Bruce Sherwood

On Wed, Jul 14, 2010 at 8:35 AM, James Mueller <mu...@pi...> wrote:

> I took a look and the file distribution.dist inside the vpython installer
> contains the lines
>
>   if(!(system.files.fileExistsAtPath('/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6')
> == true)) {
>     my.result.title = 'Need Python 2.6 from python.org';
>     my.result.message = 'Python 2.6 from python.org must be installed
> before installing VPython.';
>     my.result.type = 'Fatal';
>     return false;
>   }
>
> So it isn't looking for Current, it is looking for a specific python.
>
> So, if you also install the python 2.6 from python.org, this file will
> exist and the visual installer will work and you will be in the same setup
> as Rhett.  You will have two versions of python, one with visual and one
> with all the enthought libraries.
>
> -Jim
>
> On Jul 14, 2010, at 9:31 AM, Gary Pajer wrote:
>
> On Wed, Jul 14, 2010 at 8:35 AM, Rhett Allain <ra...@se...> wrote:
>
>> Gary,
>>
>> I have essentially the same problem.  The workaround I use is that if I
>> launch VIDLE (in the VPython folder), it can find the vpython stuff - but it
>> doesn't find the enthought stuff.  If I launch some other IDLE, then it
>> doesn't find the visual module.
>>
>> The bad part of this solution is that I can't use the visual module and
>> the pylab module at the same time.
>>
>> Rhett
>>
>
> How did you install Vpython?  In my case, the Mac installer won't run.
> -g
>
>
>>
>>
>>
>> On Wed, Jul 14, 2010 at 12:08 AM, Bruce Sherwood <bas...@nc...>wrote:
>>
>>> /Library/Frameworks/Python.framework/Versions/Current/bin/python is
>>> indeed the expected location for the Python executor, so that doesn't seem
>>> to be the problem, at least not in any simple sense. I use Apple
>>> PackageMaker to build the Mac VPython installer, and I know nothing about
>>> its criteria for recognizing the presence of Python 2.6.
>>>
>>> You made me realize that the Mac and Windows download pages at
>>> vpython.org were out of date, as they offered Python 2.6.4. After
>>> checking that the VPython installers for Mac and Windows are happy with
>>> Python 2.6.5, I've updated vpython.org to offer Python 2.6.5.
>>>
>>> Nor had I realized that now Python 2.7 is the standard release, so I need
>>> to build against that.
>>>
>>> Bruce Sherwood
>>>
>>> On Tue, Jul 13, 2010 at 8:47 PM, Gary Pajer <gar...@gm...>wrote:
>>>
>>>> I'm installing software on a new MacBook. I'm not yet very facile with
>>>> Macs.
>>>>
>>>> I have python 2.6.5 from python.org installed, but the vpython
>>>> installer says that I have to install python 2.6 before it will proceed.  I
>>>> think the problem may be that python is not installed in it's default
>>>> location.  Python was installed as part of the Enthought Python
>>>> Distribution, which installs python and a bunch of other stuff that I use.
>>>>  The python executable ended up being
>>>>
>>>> /Library/Frameworks/Python.framework/Versions/Current/bin/python
>>>>
>>>> 1.  Is this indeed *not* the default location for a "regular"
>>>> installation of python?
>>>> 2.  If it is not, is that possibly the cause of my problem?
>>>> 3.  Can I fix it by
>>>>    a. creating a symbolic link somewhere (what would it be?)
>>>>    b. or telling vpython where to look for python (set an environment
>>>> variable?)
>>>> 4. Or am I wrong, and the problem lies somewhere else?
>>>>
>>>> Thanks,
>>>> gary
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by Sprint
>>>> What will you do first with EVO, the first 4G phone?
>>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>>> _______________________________________________
>>>> Visualpython-users mailing list
>>>> Vis...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Sprint
>>> What will you do first with EVO, the first 4G phone?
>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>> _______________________________________________
>>> Visualpython-users mailing list
>>> Vis...@li...
>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>
>>>
>>
>>
>> --
>> ================
>> Rhett Allain, Ph.D.
>> Associate Professor of Physics
>> Department of Chemistry and Physics
>> Southeastern Louisiana University
>> ra...@se...
>> http://scienceblogs.com/dotphysics
>> ================
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>
>>
> <ATT00001..txt><ATT00002..txt>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

Re: [Visualpython-users] Problem installing on Mac (non-default python location perhaps?)

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

You're right.  Here's a snippet of my conversation with them:

----------------------------------------------------------
> The Mac EPD installer has a directory named
>
> /Library/Frameworks/Python.framework/Versions/6.2
>
> But the Vpython installer checks to see if exists:
>
> /Library/Frameworks/Python.framework/Versions/2.6
>
> I rather suspect that the "6.2" is a typo.  Simply renaming the directory
> name doesn't work ... stuff doesn't get found.

No, the "6.2" refers to the EPD version, not the python version. It
sounds like Vpython is either hardcoded to look at that dir, rather
than use sys.prefix, or you're using the system python to install it.
--------------------------------------------------

So the ball is back in Vpython's court: the installer should look for
sys.prefix ???



On Wed, Jul 14, 2010 at 11:43 AM, James Mueller <mu...@pi...> wrote:

> No, this is exactly what they want.  6.2 is the version of the Enthought
> distribution.  It doesn't agree with the python version, so perhaps this is
> a bad choice on their part, but I don't think they would consider it a bug.
>
> -Jim
>
> On Jul 14, 2010, at 11:15 AM, Gary Pajer wrote:
>
>
>
> On Wed, Jul 14, 2010 at 10:35 AM, James Mueller <mu...@pi...> wrote:
>
>> I took a look and the file distribution.dist inside the vpython installer
>> contains the lines
>>
>>   if(!(system.files.fileExistsAtPath('/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6')
>> == true)) {
>>     my.result.title = 'Need Python 2.6 from python.org';
>>     my.result.message = 'Python 2.6 from python.org must be installed
>> before installing VPython.';
>>     my.result.type = 'Fatal';
>>     return false;
>>   }
>>
>> So it isn't looking for Current, it is looking for a specific python.
>>
>> So, if you also install the python 2.6 from python.org, this file will
>> exist and the visual installer will work and you will be in the same setup
>> as Rhett.  You will have two versions of python, one with visual and one
>> with all the enthought libraries.
>>
>> -Jim
>>
>
>
> AHA!!!
>
> There's a typo in the Enthought distribution.  The directory that should be
> called "2.6" is actually called "6.2"
> But simply renaming that directory causes other problems.  I'll report it
> to the Enthought people.
>
>
>
>
>
>>
>> On Jul 14, 2010, at 9:31 AM, Gary Pajer wrote:
>>
>> On Wed, Jul 14, 2010 at 8:35 AM, Rhett Allain <ra...@se...> wrote:
>>
>>> Gary,
>>>
>>> I have essentially the same problem.  The workaround I use is that if I
>>> launch VIDLE (in the VPython folder), it can find the vpython stuff - but it
>>> doesn't find the enthought stuff.  If I launch some other IDLE, then it
>>> doesn't find the visual module.
>>>
>>> The bad part of this solution is that I can't use the visual module and
>>> the pylab module at the same time.
>>>
>>> Rhett
>>>
>>
>> How did you install Vpython?  In my case, the Mac installer won't run.
>> -g
>>
>>
>>>
>>>
>>>
>>> On Wed, Jul 14, 2010 at 12:08 AM, Bruce Sherwood <bas...@nc...>wrote:
>>>
>>>> /Library/Frameworks/Python.framework/Versions/Current/bin/python is
>>>> indeed the expected location for the Python executor, so that doesn't seem
>>>> to be the problem, at least not in any simple sense. I use Apple
>>>> PackageMaker to build the Mac VPython installer, and I know nothing about
>>>> its criteria for recognizing the presence of Python 2.6.
>>>>
>>>> You made me realize that the Mac and Windows download pages at
>>>> vpython.org were out of date, as they offered Python 2.6.4. After
>>>> checking that the VPython installers for Mac and Windows are happy with
>>>> Python 2.6.5, I've updated vpython.org to offer Python 2.6.5.
>>>>
>>>> Nor had I realized that now Python 2.7 is the standard release, so I
>>>> need to build against that.
>>>>
>>>> Bruce Sherwood
>>>>
>>>> On Tue, Jul 13, 2010 at 8:47 PM, Gary Pajer <gar...@gm...>wrote:
>>>>
>>>>> I'm installing software on a new MacBook. I'm not yet very facile with
>>>>> Macs.
>>>>>
>>>>> I have python 2.6.5 from python.org installed, but the vpython
>>>>> installer says that I have to install python 2.6 before it will proceed.  I
>>>>> think the problem may be that python is not installed in it's default
>>>>> location.  Python was installed as part of the Enthought Python
>>>>> Distribution, which installs python and a bunch of other stuff that I use.
>>>>>  The python executable ended up being
>>>>>
>>>>> /Library/Frameworks/Python.framework/Versions/Current/bin/python
>>>>>
>>>>> 1.  Is this indeed *not* the default location for a "regular"
>>>>> installation of python?
>>>>> 2.  If it is not, is that possibly the cause of my problem?
>>>>> 3.  Can I fix it by
>>>>>    a. creating a symbolic link somewhere (what would it be?)
>>>>>    b. or telling vpython where to look for python (set an environment
>>>>> variable?)
>>>>> 4. Or am I wrong, and the problem lies somewhere else?
>>>>>
>>>>> Thanks,
>>>>> gary
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by Sprint
>>>>> What will you do first with EVO, the first 4G phone?
>>>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>>>> _______________________________________________
>>>>> Visualpython-users mailing list
>>>>> Vis...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by Sprint
>>>> What will you do first with EVO, the first 4G phone?
>>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>>> _______________________________________________
>>>> Visualpython-users mailing list
>>>> Vis...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>>
>>>>
>>>
>>>
>>> --
>>> ================
>>> Rhett Allain, Ph.D.
>>> Associate Professor of Physics
>>> Department of Chemistry and Physics
>>> Southeastern Louisiana University
>>> ra...@se...
>>> http://scienceblogs.com/dotphysics
>>> ================
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Sprint
>>> What will you do first with EVO, the first 4G phone?
>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>> _______________________________________________
>>> Visualpython-users mailing list
>>> Vis...@li...
>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>
>>>
>> <ATT00001..txt><ATT00002..txt>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

Re: [Visualpython-users] Problem installing on Mac (non-default python location perhaps?)

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

No, this is exactly what they want.  6.2 is the version of the Enthought distribution.  It doesn't agree with the python version, so perhaps this is a bad choice on their part, but I don't think they would consider it a bug.

-Jim

On Jul 14, 2010, at 11:15 AM, Gary Pajer wrote:

> 
> 
> On Wed, Jul 14, 2010 at 10:35 AM, James Mueller <mu...@pi...> wrote:
> I took a look and the file distribution.dist inside the vpython installer contains the lines
> 
>   if(!(system.files.fileExistsAtPath('/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6') == true)) {
>     my.result.title = 'Need Python 2.6 from python.org';
>     my.result.message = 'Python 2.6 from python.org must be installed before installing VPython.';
>     my.result.type = 'Fatal';
>     return false;
>   }
> 
> So it isn't looking for Current, it is looking for a specific python.  
> 
> So, if you also install the python 2.6 from python.org, this file will exist and the visual installer will work and you will be in the same setup as Rhett.  You will have two versions of python, one with visual and one with all the enthought libraries.
> 
> -Jim
> 
> 
> AHA!!!
> 
> There's a typo in the Enthought distribution.  The directory that should be called "2.6" is actually called "6.2"
> But simply renaming that directory causes other problems.  I'll report it to the Enthought people.
> 
> 
> 
>  
> 
> On Jul 14, 2010, at 9:31 AM, Gary Pajer wrote:
> 
>> On Wed, Jul 14, 2010 at 8:35 AM, Rhett Allain <ra...@se...> wrote:
>> Gary,
>> 
>> I have essentially the same problem.  The workaround I use is that if I launch VIDLE (in the VPython folder), it can find the vpython stuff - but it doesn't find the enthought stuff.  If I launch some other IDLE, then it doesn't find the visual module.  
>> 
>> The bad part of this solution is that I can't use the visual module and the pylab module at the same time.
>> 
>> Rhett
>> 
>> How did you install Vpython?  In my case, the Mac installer won't run.
>> -g
>>  
>> 
>> 
>> 
>> On Wed, Jul 14, 2010 at 12:08 AM, Bruce Sherwood <bas...@nc...> wrote:
>> /Library/Frameworks/Python.framework/Versions/Current/bin/python is indeed the expected location for the Python executor, so that doesn't seem to be the problem, at least not in any simple sense. I use Apple PackageMaker to build the Mac VPython installer, and I know nothing about its criteria for recognizing the presence of Python 2.6.
>> 
>> You made me realize that the Mac and Windows download pages at vpython.org were out of date, as they offered Python 2.6.4. After checking that the VPython installers for Mac and Windows are happy with Python 2.6.5, I've updated vpython.org to offer Python 2.6.5.
>> 
>> Nor had I realized that now Python 2.7 is the standard release, so I need to build against that.
>> 
>> Bruce Sherwood
>> 
>> On Tue, Jul 13, 2010 at 8:47 PM, Gary Pajer <gar...@gm...> wrote:
>> I'm installing software on a new MacBook. I'm not yet very facile with Macs.
>> 
>> I have python 2.6.5 from python.org installed, but the vpython installer says that I have to install python 2.6 before it will proceed.  I think the problem may be that python is not installed in it's default location.  Python was installed as part of the Enthought Python Distribution, which installs python and a bunch of other stuff that I use.  The python executable ended up being
>> 
>> /Library/Frameworks/Python.framework/Versions/Current/bin/python
>> 
>> 1.  Is this indeed *not* the default location for a "regular" installation of python?
>> 2.  If it is not, is that possibly the cause of my problem?
>> 3.  Can I fix it by 
>>    a. creating a symbolic link somewhere (what would it be?)
>>    b. or telling vpython where to look for python (set an environment variable?)
>> 4. Or am I wrong, and the problem lies somewhere else?
>> 
>> Thanks,
>> gary
>> 
>> 
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>> 
>> 
>> 
>> 
>> -- 
>> ================
>> Rhett Allain, Ph.D.
>> Associate Professor of Physics
>> Department of Chemistry and Physics
>> Southeastern Louisiana University
>> ra...@se...
>> http://scienceblogs.com/dotphysics
>> ================
>> 
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>> 
>> 
>> <ATT00001..txt><ATT00002..txt>
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
> 
>