visualpython-users

[Visualpython-users] Numpy progress

[Arthur <ajs...@op...>]

Hi folks -

I had made some commitment to try to get to a vpython that integrates 
with the numpy library accomplished.

Was traveling last week and had the opportunity to spend some time with 
it at lay-overs, etc.

Long story short -

I'm getting there - but in a round-about way, as I am not a C++ 
programmer so there is a large learning curve for what would otherwise 
be a small problem. Have a build that works for some demos but fails for 
curves and convex objects. But I think I have a beat on the problem. The 
fact is that the various numeric libraries are mostly compatible, and 
there are only limited areas where code changes are needed (mostly 
related to typing).  Just took me a while to get the lay of the land.

The issue -

The main thing that complicates following the current code is that it is 
designed to accept  either the Numeric or Numarray libraries - on the 
fly.  It also complicates the build process and makefiles,  the  Python 
code for the  start-up of  vpython, etc.
 
My opinion is that we should bite the bullet and simplify -  and have 
builds that do not try to be backward compatible with Numeric and/or 
Numeric, and are tied only to numpy.

Acceptable?

Art

[Visualpython-users] new demo

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

In the contributed section of vpython.org you'll find SaraivaDemo.py, a 
fun and attractive demonstration of various VPython capabilities by 
Eduardo Saraiva. It runs full-screen; to get out, press ESC.

Bruce Sherwood

Re: [Visualpython-users] visual timing problem

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

Since as Jonathan says, it is difficult to get accurate timing with any 
of the standard multitasking operating systems (Windows, Mac, Linux), 
you might well change your requested timing but not get it. It occurs to 
me to suggest that the real experts on this kind of experimentation are 
others in your own field who make these kinds of measurements, not us. 
They presumably know how to get around or subvert the operating system 
limitations (or they're not actually measuring what they think they're 
measuring). So I would suggest talking to experimenters in your field 
about these issues.

Bruce Sherwood

Jonathan Brandmeyer wrote:

>On Wed, 2006-10-11 at 11:00 +0200, Goedele Van Belle wrote:
>  
>
>>Hi,
>>
>>I am a researcher in visual perception, more precisely we are 
>>investigating transsaccadic change blindness. This means we change the 
>>position of an object in a 3D scene, during an eye movement. Afterwards 
>>the viewer has to indicate whether or not he notices something was 
>>replaced. Therefor it is very important this position change occurs 
>>during the eye movement, and not after it.
>>
>>We are using VPython to display the scene, because it is so nice to use. 
>>But there is a slight problem with it. An eye movement takes about 30 
>>msec, and detecting it takes about 12msec. This means there is only 
>>about 18msec left to change the display. The problem with Visual is that 
>>the display is only refreshed 20 times per second, which means there can 
>>be 50msec between the command of changing the position, and the update 
>>of the cache.
>>    
>>
>
>  
>
>>Is there a way to change this 20 times per second? (where can I find 
>>it?) Would it still work if I update the video memory myself, every time 
>>I change something in the scene, or, when I update the video memory 
>>every msec? And where is the command for updating the video memory given?
>>    
>>
>
>The time delay is hard-coded in VPython.  However, you can change it in
>the C++ source code and make a custom build.  In VPython 3.x on all
>platforms, see GLDevice::render_control().  The last line of this
>function reads "return 33;"  That is the approximate number of
>milliseconds between renderings of the scene, which you can reduce to
>whatever value you like.
>
>In VPython 4 see src/win32/winrender_surface.cpp
>render_surface::on_showwindow().  The third argument to SetTimer() is
>the timeout in milliseconds (currently 30).  On Linux or OSX the process
>is somewhat complicated by an attempt at intelligent timer management
>(see src/gtk2/render_surface.cpp: render_surface::forward_render_scene()
>and render_surface::on_realize()).  If that is your platform of choice,
>then I'll explain what you have to do there.
>
>However, be forewarned that getting accurate and repeatable timing of
>this function on Windows, Linux, or a Mac is going to be very difficult.
>None of these operating systems provide hard realtime guarantees with
>regards to process scheduling.  You will probably need to observe both
>the screen update and the eye movement and be prepared to throw out some
>samples.
>
>Good luck,
>-Jonathan
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users
>  
>

Re: [Visualpython-users] visual timing problem

[Jonathan B. <jbr...@ea...>]

On Wed, 2006-10-11 at 11:00 +0200, Goedele Van Belle wrote:
> Hi,
> 
> I am a researcher in visual perception, more precisely we are 
> investigating transsaccadic change blindness. This means we change the 
> position of an object in a 3D scene, during an eye movement. Afterwards 
> the viewer has to indicate whether or not he notices something was 
> replaced. Therefor it is very important this position change occurs 
> during the eye movement, and not after it.
> 
> We are using VPython to display the scene, because it is so nice to use. 
> But there is a slight problem with it. An eye movement takes about 30 
> msec, and detecting it takes about 12msec. This means there is only 
> about 18msec left to change the display. The problem with Visual is that 
> the display is only refreshed 20 times per second, which means there can 
> be 50msec between the command of changing the position, and the update 
> of the cache.

> Is there a way to change this 20 times per second? (where can I find 
> it?) Would it still work if I update the video memory myself, every time 
> I change something in the scene, or, when I update the video memory 
> every msec? And where is the command for updating the video memory given?

The time delay is hard-coded in VPython.  However, you can change it in
the C++ source code and make a custom build.  In VPython 3.x on all
platforms, see GLDevice::render_control().  The last line of this
function reads "return 33;"  That is the approximate number of
milliseconds between renderings of the scene, which you can reduce to
whatever value you like.

In VPython 4 see src/win32/winrender_surface.cpp
render_surface::on_showwindow().  The third argument to SetTimer() is
the timeout in milliseconds (currently 30).  On Linux or OSX the process
is somewhat complicated by an attempt at intelligent timer management
(see src/gtk2/render_surface.cpp: render_surface::forward_render_scene()
and render_surface::on_realize()).  If that is your platform of choice,
then I'll explain what you have to do there.

However, be forewarned that getting accurate and repeatable timing of
this function on Windows, Linux, or a Mac is going to be very difficult.
None of these operating systems provide hard realtime guarantees with
regards to process scheduling.  You will probably need to observe both
the screen update and the eye movement and be prepared to throw out some
samples.

Good luck,
-Jonathan

[Visualpython-users] visual timing problem

[Goedele V. B. <goe...@ps...>]

Hi,

I am a researcher in visual perception, more precisely we are 
investigating transsaccadic change blindness. This means we change the 
position of an object in a 3D scene, during an eye movement. Afterwards 
the viewer has to indicate whether or not he notices something was 
replaced. Therefor it is very important this position change occurs 
during the eye movement, and not after it.

We are using VPython to display the scene, because it is so nice to use. 
But there is a slight problem with it. An eye movement takes about 30 
msec, and detecting it takes about 12msec. This means there is only 
about 18msec left to change the display. The problem with Visual is that 
the display is only refreshed 20 times per second, which means there can 
be 50msec between the command of changing the position, and the update 
of the cache.

Is there a way to change this 20 times per second? (where can I find 
it?) Would it still work if I update the video memory myself, every time 
I change something in the scene, or, when I update the video memory 
every msec? And where is the command for updating the video memory given?

Regards,

Goedele Van Belle

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[Visualpython-users] minor correction

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

I've updated the Windows VPython 3 for Python 2.5; the pointer to the 
reference manual was omitted from the Help menu in IDLE.

Haven't fixed this in the beta VPython 4 yet.

Bruce

Re: [Visualpython-users] sockets errors, vpython, and windows xp?

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

The issue is with IDLE, a component of Python, not with VPython itself 
(though the basic architecture was originally developed by David Scherer 
when he was first building VPython), so you might want to bring this to 
the attention of the Python people.

Basically, the way IDLE works is that it spawns a separate copy of 
Python, which among other things keeps the running of your program at 
arm's length from the editing of your program, and so provides more 
security in terms of not losing your editing work. A socket is created 
to permit communication between IDLE and your running program. This 
socket is purely internal and makes no connection to the outside world, 
as you see in the boiler plate shown in the shell window when you first 
run from IDLE:

Personal firewall software may warn about the connection IDLE
makes to its subprocess using this computer's internal loopback
interface.  This connection is not visible on any external
interface and no data is sent to or received from the Internet.

Some firewalls ask you whether to continue blocking access or not for 
this program, and of course you should unblock.

A possibly separate issue is that occasionally one gets a socket error 
with no firewall issue in sight. The only way I know to clear this (at 
least on Windows, where most of my experience lies) is to log out and 
log back in (if the machine is configured that way) or to reboot.

Are these Windows laptops, Mac? Linux?

Bruce Sherwood

Pete Border wrote:

>Hi:
>
>I'm trying to have students use vpython on their own laptops, and 
>several of the newer ones are getting socket errors. The errors are not 
>very repeatable, but they seem to go away if ne turns off the firewall. 
>Is this a known problem, and ifso, how does one fix it?
>                            thanks;
>                                    Pete Border
>
>  
>

[Visualpython-users] sockets errors, vpython, and windows xp?

[Pete B. <bo...@ma...>]

Hi:

I'm trying to have students use vpython on their own laptops, and 
several of the newer ones are getting socket errors. The errors are not 
very repeatable, but they seem to go away if ne turns off the firewall. 
Is this a known problem, and ifso, how does one fix it?
                            thanks;
                                    Pete Border

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: Python 2.5 (Arthur Siegel)
>    2. Re: Python 2.5 (Gary Pajer)
>    3. Re: Python 2.5 (Arthur Siegel)
>    4. Python 2.5 version for Windows available (Bruce Sherwood)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 09 Oct 2006 12:52:29 -0400
> From: Arthur Siegel <ajs...@op...>
> Subject: Re: [Visualpython-users] Python 2.5
> To: Jonathan Brandmeyer <jbr...@ea...>
> Cc: vpusers <vis...@li...>
> Message-ID: <1160412749.3105.7.camel@localhost>
> Content-Type: text/plain
>
> On Sat, 2006-10-07 at 20:37 -0400, Arthur Siegel wrote:
>
>   
>> Am I correct that num_util.h and num_util.cpp are those
>> of Phil Austin @ Univ of British Columbia?
>>
>> http://www.eos.ubc.ca/research/clouds/software/pythonlibs/num_util/num_util_release2/
>>
>> If so, there is a new version targeting Numpy, as per the above link.
>>
>> Except that I can't even get it to compile and run the tests correctly.
>>
>> Choking on `intp` types and other places.
>>
>> Grrrr...
>>
>> Numpy is moving fast toward a 1.0 release and I have to wonder whether
>> the num_util code is incompatible with the latest Numpy.
>>
>> Or else I am doing something stupid.
>>     
>
> Turns out my instincts were correct, and I was only stupid to the extent
> that it took be longer than it should have (had I had more background,
> at least) to realize this.
>
> Numpy's include files were in fact changed since Phil released his
> num_util code for numpy.  Following those changes through to the
> num_util code I now get that code to compile.
>
> I guess my strategy is to start from the new num_utils and do a bit of
> monkey-see, monkey-do, following what changes Jonathan had made to the
> orignal, making the analogous on the new, and see if I can follow things
> through from there.
>
> Lot's of moving parts though, as we also have the boost libraries in
> play, and any changes that are happening there to deal with numpy and
> Python2.5.
>
>
> We'll see.
>
> Art
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 09 Oct 2006 13:24:46 -0400
> From: Gary Pajer <gp...@ri...>
> Subject: Re: [Visualpython-users] Python 2.5
> To: vpusers <vis...@li...>
> Message-ID: <452...@ri...>
> Content-Type: text/plain; format=flowed; charset=us-ascii
>
> Arthur Siegel wrote:
>
>   
>> On Sat, 2006-10-07 at 20:37 -0400, Arthur Siegel wrote:
>>
>>  
>>
>>     
>>> Am I correct that num_util.h and num_util.cpp are those
>>> of Phil Austin @ Univ of British Columbia?
>>>    
>>>
>>>       
> [...]
>
>   
>> Numpy's include files were in fact changed since Phil released his
>> num_util code for numpy.  Following those changes through to the
>> num_util code I now get that code to compile.
>>
>>     
> This is the comment that sparked my comment on license issues.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 09 Oct 2006 13:55:04 -0400
> From: Arthur Siegel <ajs...@op...>
> Subject: Re: [Visualpython-users] Python 2.5
> To: Gary Pajer <gp...@ri...>
> Cc: vpusers <vis...@li...>
> Message-ID: <1160416504.5057.3.camel@localhost>
> Content-Type: text/plain
>
> On Mon, 2006-10-09 at 13:24 -0400, Gary Pajer wrote:
>
>   
>>> Numpy's include files were in fact changed since Phil released his
>>> num_util code for numpy.  Following those changes through to the
>>> num_util code I now get that code to compile.
>>>
>>>       
>> This is the comment that sparked my comment on license issues.
>>     
>
> Again, no change from where things are, as current VPython derives from
> its prior release, as is noted by Jonathan in the source file itself.
> The num_utils code is released subject to the Boost license, which is
> short and sweet and unrestrictive in any sense:
>
> http://www.boost.org/LICENSE_1_0.txt
>
> Art
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 09 Oct 2006 12:41:21 -0600
> From: Bruce Sherwood <Bru...@nc...>
> Subject: [Visualpython-users] Python 2.5 version for Windows available
> To: vpusers <vis...@li...>
> Message-ID: <452...@nc...>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Thanks to the suggestion to compile Numeric from source on Windows, I 
> was able to post versions of VPython for Python 2.5, both Visual 3 and 
> Visual 4. This is a stop-gap measure since we all realize the need to 
> move to the new NumPy.
>
> I had to Google to find the following syntax for compiling Numeric on 
> Windows using Msys and MinGW:
>
> /c/python25/python.exe setup.py build ?compiler=mingw32 install
>
> In the process I updated in CVS the install instructions INSTALL.txt, 
> which are now essentially identical for both Visual 3 and Visual 4. I 
> hope this is useful to Arthur and others who may be able to work on 
> Visual. I wouldn't have been able to make these releases at this time 
> had it not been that little effort was required, once it was pointed out 
> how to get around the lack of a binary distribution of Numeric for 
> Python 2.5 on Windows.
>
> FYI, in the process of testing the new releases I found that Python 2.5 
> is more restrictive than previous versions. It's pickier about 
> indentation consistency, and "from __future__ import division" must be 
> the very first line in a program. These new restrictions required minor 
> fixes to a few example programs.
>
> Bruce Sherwood
>
>
>
>
> ------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> ------------------------------
>
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>
> End of Visualpython-users Digest, Vol 5, Issue 6
> ************************************************
>   

[Visualpython-users] Python 2.5 version for Windows available

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

Thanks to the suggestion to compile Numeric from source on Windows, I=20
was able to post versions of VPython for Python 2.5, both Visual 3 and=20
Visual 4. This is a stop-gap measure since we all realize the need to=20
move to the new NumPy.

I had to Google to find the following syntax for compiling Numeric on=20
Windows using Msys and MinGW:

/c/python25/python.exe setup.py build =96compiler=3Dmingw32 install

In the process I updated in CVS the install instructions INSTALL.txt,=20
which are now essentially identical for both Visual 3 and Visual 4. I=20
hope this is useful to Arthur and others who may be able to work on=20
Visual. I wouldn't have been able to make these releases at this time=20
had it not been that little effort was required, once it was pointed out=20
how to get around the lack of a binary distribution of Numeric for=20
Python 2.5 on Windows.

FYI, in the process of testing the new releases I found that Python 2.5=20
is more restrictive than previous versions. It's pickier about=20
indentation consistency, and "from __future__ import division" must be=20
the very first line in a program. These new restrictions required minor=20
fixes to a few example programs.

Bruce Sherwood

Re: [Visualpython-users] Python 2.5

[Arthur S. <ajs...@op...>]

On Mon, 2006-10-09 at 13:24 -0400, Gary Pajer wrote:

> >Numpy's include files were in fact changed since Phil released his
> >num_util code for numpy.  Following those changes through to the
> >num_util code I now get that code to compile.
> >
> This is the comment that sparked my comment on license issues.

Again, no change from where things are, as current VPython derives from
its prior release, as is noted by Jonathan in the source file itself.
The num_utils code is released subject to the Boost license, which is
short and sweet and unrestrictive in any sense:

http://www.boost.org/LICENSE_1_0.txt

Art

Re: [Visualpython-users] Python 2.5

[Gary P. <gp...@ri...>]

Arthur Siegel wrote:

>On Sat, 2006-10-07 at 20:37 -0400, Arthur Siegel wrote:
>
>  
>
>>Am I correct that num_util.h and num_util.cpp are those
>>of Phil Austin @ Univ of British Columbia?
>>    
>>
[...]

>Numpy's include files were in fact changed since Phil released his
>num_util code for numpy.  Following those changes through to the
>num_util code I now get that code to compile.
>
This is the comment that sparked my comment on license issues.

Re: [Visualpython-users] Python 2.5

[Arthur S. <ajs...@op...>]

On Sat, 2006-10-07 at 20:37 -0400, Arthur Siegel wrote:

> Am I correct that num_util.h and num_util.cpp are those
> of Phil Austin @ Univ of British Columbia?
> 
> http://www.eos.ubc.ca/research/clouds/software/pythonlibs/num_util/num_util_release2/
> 
> If so, there is a new version targeting Numpy, as per the above link.
> 
> Except that I can't even get it to compile and run the tests correctly.
> 
> Choking on `intp` types and other places.
> 
> Grrrr...
> 
> Numpy is moving fast toward a 1.0 release and I have to wonder whether
> the num_util code is incompatible with the latest Numpy.
> 
> Or else I am doing something stupid.

Turns out my instincts were correct, and I was only stupid to the extent
that it took be longer than it should have (had I had more background,
at least) to realize this.

Numpy's include files were in fact changed since Phil released his
num_util code for numpy.  Following those changes through to the
num_util code I now get that code to compile.

I guess my strategy is to start from the new num_utils and do a bit of
monkey-see, monkey-do, following what changes Jonathan had made to the
orignal, making the analogous on the new, and see if I can follow things
through from there.

Lot's of moving parts though, as we also have the boost libraries in
play, and any changes that are happening there to deal with numpy and
Python2.5.


We'll see.

Art

Re: [Visualpython-users] Python 2.5

[Gary <pa...@in...>]

Bruce Sherwood wrote:
> You're right, I'm probably thinking about this wrong. I had for no 
> particularly good reason felt that the fact that there is no (binary) 
> version of Numeric for Python2.5 on Windows was a show-stopper. But as 
> you say, we could just compile it for Windows from source. Assuming 
> there are no problems with that, it's surely the quickest route to 
> Python 2.5.
>   
I hadn't thought of that either, and you might thing I would have... for 
a time I had authored and maintained the wiki entry on compiling numpy 
for Windows. (I've since been replaced.)  The hard part was finding the 
right version of MinGW.  The current version didn't seem to work; one 
had to use an earlier version.  Aside from that, it was pretty easy.

-g
> Visual on Windows is compiled not with commercial tools but with the 
> Linux/Unix-like open source tools MinGW and MSYS (see HACKING.txt and  
> INSTALL.txt in the Visual files). Presumably Numeric can be built using 
> these tools. I hope.
>
> That of course doesn't absolve us from the responsibility of moving to 
> NumPy with all deliberate speed.
>
> I guess one thing contributing to my blindness was that it seemed a bit 
> ghoulish to resurrect a decently and honorably buried Numeric on Windows.
>
> Bruce
>
> Arthur Siegel wrote:
>
>   
>> On Sun, 2006-10-08 at 15:45 -0600, Bruce Sherwood wrote:
>>  
>>
>>     
>>> I agree that it is a priority to be able to run Visual 3 on Python 2.5.
>>>
>>> I'm guessing that the quickest way to do that would be to comment out 
>>> references in Visual to Numeric (which isn't available for Python 2.5 
>>>    
>>>
>>>       
>> I'm confused why it is you have that impression.
>>
>> Numeric's C can compile against Python2.5, and its Python code is fully
>> compatible with Python2.5.
>>
>> I have compiled it successfully today on Linux.
>>
>> In fact, in my mind it is more stable and mature than numarray.  It is
>> my understanding that numarray was developed to optimize enormous arrays
>> confronted in analyzing astronomical data  - astronomical arrays ;) -
>> and is sub-optimum for the earthbound arrays I think is more typical in
>> the use of vpython.  It is also my impression that numarray never fully
>> matured, i.e. development was cut short when it was agreed that numpy
>> would become the standard.
>>
>> So that it is my opinion that we should be concentrating on a Numeric
>> based distribution against Python2.5.
>>
>> Though it is also true I am not understanding what the problem you see
>> in keeping things as they are, and using either/or.  
>>
>> To me this is rather straight forward - I see no reason why the existing
>> vpython 3.xxx should have any problems with Python2.5 other than the one
>> I had mentioned on 64 bit machines - which I am assuming is not a
>> practical problem for most.
>>
>> Python is generally conservative in its development philosophy.  A new
>> release generally means new features.  Great attention is paid to not
>> breaking backward compatibility. The change in the C API to accommodate
>> 64 bit machines is a rare exception, except that it was done in such a
>> way that other than possibly a warning message that wasn't there before,
>> things whould continue to run fine as they were on your standard PC.
>>
>> With my general "unless I am missing something" disclaimer, I think we
>> are making this more of an issue than it should be. 
>>
>> My problem is that I don't have the commercial tools necessary to do a
>> Windows compilation to try to understand what you are running into.  But
>> frankly I suspect it is something other than what you think it is.
>>
>> Art 
>>
>>  
>>
>>     
>>> but is required to be present for Visual to build, at least on Windows) 
>>> and go with NumArray (which should work with Visual, even though I just 
>>> discovered that it doesn't seem to). However, this is a less desirable 
>>> path than replacing both Numeric and NumArray with the new NumPy.
>>>
>>> This assumes that the amount of work required to make a stable Visual 4 
>>> with NumPy will take significantly more time than making a stable Visual 
>>> 3 with NumPy.
>>>
>>> For the information of those interested in working on Visual, using 
>>> source code from sourceforge.net: The files HACKING.txt and INSTALL.txt 
>>> contain instructions on what tools you need to have on your computer in 
>>> order to be able to build from source, and instructions on how to use 
>>> those tools. If you have questions, feel free to ask.
>>>
>>> Individual files in the project typically have pretty good commentary, 
>>> but there isn't an overview document that explains how the pieces go 
>>> together, which together with the complexity of Visual does make it 
>>> difficult to get started.
>>>
>>> Bruce
>>>
>>> Arthur Siegel wrote:
>>>
>>>    
>>>
>>>       
>>>> On Sun, 2006-10-08 at 10:05 -0400, Arthur Siegel wrote:
>>>>
>>>>
>>>>
>>>>      
>>>>
>>>>         
>>>>> So that maybe the short-term focus should
>>>>> be shifted there.  I am concerned about the perception regarding VPython
>>>>> should there be a significant delay in making Python2.5 binaries
>>>>> available, now that Python2.5 is itself final.
>>>>>   
>>>>>
>>>>>        
>>>>>
>>>>>           
>>>> to add -
>>>>
>>>> IMO, binaries for Python2.5 against the stable 3.xxx branch should be
>>>> maintained and made available until such time as the known bugs against
>>>> the 4.xxx branch get sorted out.
>>>>
>>>> Among other reasons, it is my perception that the Debian folks are quite
>>>> conservative about what they package/support so that an official Debian
>>>> distro against 3.xxx and Python2.5 is a more feasible request than one
>>>> against 4.xxx.
>>>>
>>>>
>>>> Art
>>>>
>>>>
>>>>
>>>>      
>>>>
>>>>         
>>> -------------------------------------------------------------------------
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>> opinions on IT & business topics through brief surveys -- and earn cash
>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>> _______________________________________________
>>> Visualpython-users mailing list
>>> Vis...@li...
>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>    
>>>
>>>       
>>  
>>
>>     
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>   

Re: [Visualpython-users] Python 2.5

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

You're right, I'm probably thinking about this wrong. I had for no 
particularly good reason felt that the fact that there is no (binary) 
version of Numeric for Python2.5 on Windows was a show-stopper. But as 
you say, we could just compile it for Windows from source. Assuming 
there are no problems with that, it's surely the quickest route to 
Python 2.5.

Visual on Windows is compiled not with commercial tools but with the 
Linux/Unix-like open source tools MinGW and MSYS (see HACKING.txt and  
INSTALL.txt in the Visual files). Presumably Numeric can be built using 
these tools. I hope.

That of course doesn't absolve us from the responsibility of moving to 
NumPy with all deliberate speed.

I guess one thing contributing to my blindness was that it seemed a bit 
ghoulish to resurrect a decently and honorably buried Numeric on Windows.

Bruce

Arthur Siegel wrote:

>On Sun, 2006-10-08 at 15:45 -0600, Bruce Sherwood wrote:
>  
>
>>I agree that it is a priority to be able to run Visual 3 on Python 2.5.
>>
>>I'm guessing that the quickest way to do that would be to comment out 
>>references in Visual to Numeric (which isn't available for Python 2.5 
>>    
>>
>
>I'm confused why it is you have that impression.
>
>Numeric's C can compile against Python2.5, and its Python code is fully
>compatible with Python2.5.
>
>I have compiled it successfully today on Linux.
>
>In fact, in my mind it is more stable and mature than numarray.  It is
>my understanding that numarray was developed to optimize enormous arrays
>confronted in analyzing astronomical data  - astronomical arrays ;) -
>and is sub-optimum for the earthbound arrays I think is more typical in
>the use of vpython.  It is also my impression that numarray never fully
>matured, i.e. development was cut short when it was agreed that numpy
>would become the standard.
>
>So that it is my opinion that we should be concentrating on a Numeric
>based distribution against Python2.5.
>
>Though it is also true I am not understanding what the problem you see
>in keeping things as they are, and using either/or.  
>
>To me this is rather straight forward - I see no reason why the existing
>vpython 3.xxx should have any problems with Python2.5 other than the one
>I had mentioned on 64 bit machines - which I am assuming is not a
>practical problem for most.
>
>Python is generally conservative in its development philosophy.  A new
>release generally means new features.  Great attention is paid to not
>breaking backward compatibility. The change in the C API to accommodate
>64 bit machines is a rare exception, except that it was done in such a
>way that other than possibly a warning message that wasn't there before,
>things whould continue to run fine as they were on your standard PC.
>
>With my general "unless I am missing something" disclaimer, I think we
>are making this more of an issue than it should be. 
>
>My problem is that I don't have the commercial tools necessary to do a
>Windows compilation to try to understand what you are running into.  But
>frankly I suspect it is something other than what you think it is.
>
>Art 
>
>  
>
>>but is required to be present for Visual to build, at least on Windows) 
>>and go with NumArray (which should work with Visual, even though I just 
>>discovered that it doesn't seem to). However, this is a less desirable 
>>path than replacing both Numeric and NumArray with the new NumPy.
>>
>>This assumes that the amount of work required to make a stable Visual 4 
>>with NumPy will take significantly more time than making a stable Visual 
>>3 with NumPy.
>>
>>For the information of those interested in working on Visual, using 
>>source code from sourceforge.net: The files HACKING.txt and INSTALL.txt 
>>contain instructions on what tools you need to have on your computer in 
>>order to be able to build from source, and instructions on how to use 
>>those tools. If you have questions, feel free to ask.
>>
>>Individual files in the project typically have pretty good commentary, 
>>but there isn't an overview document that explains how the pieces go 
>>together, which together with the complexity of Visual does make it 
>>difficult to get started.
>>
>>Bruce
>>
>>Arthur Siegel wrote:
>>
>>    
>>
>>>On Sun, 2006-10-08 at 10:05 -0400, Arthur Siegel wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>So that maybe the short-term focus should
>>>>be shifted there.  I am concerned about the perception regarding VPython
>>>>should there be a significant delay in making Python2.5 binaries
>>>>available, now that Python2.5 is itself final.
>>>>   
>>>>
>>>>        
>>>>
>>>to add -
>>>
>>>IMO, binaries for Python2.5 against the stable 3.xxx branch should be
>>>maintained and made available until such time as the known bugs against
>>>the 4.xxx branch get sorted out.
>>>
>>>Among other reasons, it is my perception that the Debian folks are quite
>>>conservative about what they package/support so that an official Debian
>>>distro against 3.xxx and Python2.5 is a more feasible request than one
>>>against 4.xxx.
>>>
>>>
>>>Art
>>>
>>> 
>>>
>>>      
>>>
>>-------------------------------------------------------------------------
>>Take Surveys. Earn Cash. Influence the Future of IT
>>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>opinions on IT & business topics through brief surveys -- and earn cash
>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>_______________________________________________
>>Visualpython-users mailing list
>>Vis...@li...
>>https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>    
>>
>
>  
>

Re: [Visualpython-users] Python 2.5

[Arthur S. <ajs...@op...>]

On Sun, 2006-10-08 at 15:45 -0600, Bruce Sherwood wrote:
> I agree that it is a priority to be able to run Visual 3 on Python 2.5.
> 
> I'm guessing that the quickest way to do that would be to comment out 
> references in Visual to Numeric (which isn't available for Python 2.5 

I'm confused why it is you have that impression.

Numeric's C can compile against Python2.5, and its Python code is fully
compatible with Python2.5.

I have compiled it successfully today on Linux.

In fact, in my mind it is more stable and mature than numarray.  It is
my understanding that numarray was developed to optimize enormous arrays
confronted in analyzing astronomical data  - astronomical arrays ;) -
and is sub-optimum for the earthbound arrays I think is more typical in
the use of vpython.  It is also my impression that numarray never fully
matured, i.e. development was cut short when it was agreed that numpy
would become the standard.

So that it is my opinion that we should be concentrating on a Numeric
based distribution against Python2.5.

Though it is also true I am not understanding what the problem you see
in keeping things as they are, and using either/or.  

To me this is rather straight forward - I see no reason why the existing
vpython 3.xxx should have any problems with Python2.5 other than the one
I had mentioned on 64 bit machines - which I am assuming is not a
practical problem for most.

Python is generally conservative in its development philosophy.  A new
release generally means new features.  Great attention is paid to not
breaking backward compatibility. The change in the C API to accommodate
64 bit machines is a rare exception, except that it was done in such a
way that other than possibly a warning message that wasn't there before,
things whould continue to run fine as they were on your standard PC.

With my general "unless I am missing something" disclaimer, I think we
are making this more of an issue than it should be. 

My problem is that I don't have the commercial tools necessary to do a
Windows compilation to try to understand what you are running into.  But
frankly I suspect it is something other than what you think it is.

Art 

> but is required to be present for Visual to build, at least on Windows) 
> and go with NumArray (which should work with Visual, even though I just 
> discovered that it doesn't seem to). However, this is a less desirable 
> path than replacing both Numeric and NumArray with the new NumPy.
> 
> This assumes that the amount of work required to make a stable Visual 4 
> with NumPy will take significantly more time than making a stable Visual 
> 3 with NumPy.
> 
> For the information of those interested in working on Visual, using 
> source code from sourceforge.net: The files HACKING.txt and INSTALL.txt 
> contain instructions on what tools you need to have on your computer in 
> order to be able to build from source, and instructions on how to use 
> those tools. If you have questions, feel free to ask.
> 
> Individual files in the project typically have pretty good commentary, 
> but there isn't an overview document that explains how the pieces go 
> together, which together with the complexity of Visual does make it 
> difficult to get started.
> 
> Bruce
> 
> Arthur Siegel wrote:
> 
> >On Sun, 2006-10-08 at 10:05 -0400, Arthur Siegel wrote:
> >
> >  
> >
> >>So that maybe the short-term focus should
> >>be shifted there.  I am concerned about the perception regarding VPython
> >>should there be a significant delay in making Python2.5 binaries
> >>available, now that Python2.5 is itself final.
> >>    
> >>
> >
> >to add -
> >
> >IMO, binaries for Python2.5 against the stable 3.xxx branch should be
> >maintained and made available until such time as the known bugs against
> >the 4.xxx branch get sorted out.
> >
> >Among other reasons, it is my perception that the Debian folks are quite
> >conservative about what they package/support so that an official Debian
> >distro against 3.xxx and Python2.5 is a more feasible request than one
> >against 4.xxx.
> >
> >
> >Art
> >
> >  
> >
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Python 2.5

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

I agree that it is a priority to be able to run Visual 3 on Python 2.5.

I'm guessing that the quickest way to do that would be to comment out 
references in Visual to Numeric (which isn't available for Python 2.5 
but is required to be present for Visual to build, at least on Windows) 
and go with NumArray (which should work with Visual, even though I just 
discovered that it doesn't seem to). However, this is a less desirable 
path than replacing both Numeric and NumArray with the new NumPy.

This assumes that the amount of work required to make a stable Visual 4 
with NumPy will take significantly more time than making a stable Visual 
3 with NumPy.

For the information of those interested in working on Visual, using 
source code from sourceforge.net: The files HACKING.txt and INSTALL.txt 
contain instructions on what tools you need to have on your computer in 
order to be able to build from source, and instructions on how to use 
those tools. If you have questions, feel free to ask.

Individual files in the project typically have pretty good commentary, 
but there isn't an overview document that explains how the pieces go 
together, which together with the complexity of Visual does make it 
difficult to get started.

Bruce

Arthur Siegel wrote:

>On Sun, 2006-10-08 at 10:05 -0400, Arthur Siegel wrote:
>
>  
>
>>So that maybe the short-term focus should
>>be shifted there.  I am concerned about the perception regarding VPython
>>should there be a significant delay in making Python2.5 binaries
>>available, now that Python2.5 is itself final.
>>    
>>
>
>to add -
>
>IMO, binaries for Python2.5 against the stable 3.xxx branch should be
>maintained and made available until such time as the known bugs against
>the 4.xxx branch get sorted out.
>
>Among other reasons, it is my perception that the Debian folks are quite
>conservative about what they package/support so that an official Debian
>distro against 3.xxx and Python2.5 is a more feasible request than one
>against 4.xxx.
>
>
>Art
>
>  
>

Re: [Visualpython-users] Python 2.5

[Arthur S. <ajs...@op...>]

On Sun, 2006-10-08 at 15:21 -0400, Gary Pajer wrote:

> I'd like to help with this effort, but I might not be able to run fast
> enough to keep up.  The only thing I can add right now is a reminder to be
> careful about license issues.  

Not sure I see an issue since I am really not proposing any changes to
anything. Just like to help the project - if I can - get exactly where
it already is vs Python2.4 relative to Python2.5.

In fact what I seem to be proposing is a VPython Classic distribution -
i.e., 3.2.9 with Numeric, just built against Python2.5.

Talk about not being able to keep up, though ... 

my latest conclusion is that the only compatibility issue that might
rise using Numeric and Python2.5 is on 64 bit machines since there are
issues - I think both in Numeric and in VPython itself - in regard to
conforming to the Pep353 C API change.

http://www.python.org/dev/peps/pep-0353/

My starting point is that most of this is mostly over-my-head.  But as
it happens, getting into this sorta fits with an agenda I have to get
conversant with C++, specifically with respect to Python extension
building - and I always find it better to have something real to sink my
teeth into when undertaking this kind of learning effort. 

So I will keep plugging.

Art

> I'm far from knowledgeable about this, but
> as I understand it, the vpython license is more BSD like than GPL, and GPL
> is more restrictive.  I may be wrong.  If we add stuff, we need to be
> careful about accidentally making the whole thing GPL.  I think.
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Python 2.5

[Gary P. <gp...@ri...>]

> On Sun, 2006-10-08 at 10:05 -0400, Arthur Siegel wrote:
>
>> So that maybe the short-term focus should
>> be shifted there.  I am concerned about the perception regarding VPython
>> should there be a significant delay in making Python2.5 binaries
>> available, now that Python2.5 is itself final.
>
> to add -
>
> IMO, binaries for Python2.5 against the stable 3.xxx branch should be
> maintained and made available until such time as the known bugs against
> the 4.xxx branch get sorted out.

I'd like to help with this effort, but I might not be able to run fast
enough to keep up.  The only thing I can add right now is a reminder to be
careful about license issues.  I'm far from knowledgeable about this, but
as I understand it, the vpython license is more BSD like than GPL, and GPL
is more restrictive.  I may be wrong.  If we add stuff, we need to be
careful about accidentally making the whole thing GPL.  I think.

Re: [Visualpython-users] Python 2.5

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

If I remember correctly, I found that some example programs that do 
explicit numeric operations such as stars.py and gas.py did not in fact 
work with numarray, due to some changes in external syntax (thought it's 
possible that only minor changes would have been necessary). 
Unfortunately, when I tried just now to check this memory, I find to my 
surprise that if I install VPython (either version 3 or 4) and elect 
during installation to install only numarray, not numeric, I can't run 
any programs (the error message is that the crayola module is missing).

I don't when this feature got broken. I tried 3.2.8 and 3.2.9 and the 
latest 4.

I'm the one who has been packaging the Windows distribution, and 
sometimes I've created the Linux package (which others then repackage 
for particular flavors of Linux). Martin Costabel has been making the 
fink packages for the Mac.

At the moment the Windows build wants both numeric and numarray to be 
already installed (no longer a possibility with Python 2.5) but then 
attempts to create an installer that allows the end user to choose 
(though clearly that feature is currently broken somehow).

Bruce

Arthur Siegel wrote:

>On Sat, 2006-10-07 at 16:14 -0600, Bruce Sherwood wrote:
>  
>
>>Just to try to keep the record straight: Isn't it the case that fink 
>>touches ONLY its own directory, /sw? I don't see how it can "corrupt" 
>>the system.
>>    
>>
>
>Also to keep the record straight - there is *no* incompatibility (of
>which I am aware) between Python2.5 and VPython built with either
>Numeric or numarray.
>
>The issue regarding numpy compatibility is significant since numpy is
>becoming the Python standard for multi-dimensional array processing, so
>that, for example, the lives of educational projects like courses such
>as:
>
>http://www.physics.cornell.edu/sethna/teaching/ComputationalMethods/index.html
>
>which use scipy (in which numpy is core) and which also use VPython are
>becoming more complicated than it might be.
>
>But to maintain perspective - the numpy issue is not an immediate
>crisis, provided that the maintainers of the Windows distro, the Debian
>distro, the fink distro, etc. proceed to make binary distributions
>against Python2.5 available.  So that maybe the short-term focus should
>be shifted there.  I am concerned about the perception regarding VPython
>should there be a significant delay in making Python2.5 binaries
>available, now that Python2.5 is itself final.
>
>I will see if I can figure out who might be appropriate to contact to
>urge that the ubuntu (debian based) distribution make a Python2.5
>package available.
>
>Bruce - 
>
>who has been doing the Windows distro??
>
>Mac - don't know.
>
>Art
>
>  
>

Re: [Visualpython-users] Python 2.5

[Arthur S. <ajs...@op...>]

On Sun, 2006-10-08 at 10:05 -0400, Arthur Siegel wrote:

> So that maybe the short-term focus should
> be shifted there.  I am concerned about the perception regarding VPython
> should there be a significant delay in making Python2.5 binaries
> available, now that Python2.5 is itself final.

to add -

IMO, binaries for Python2.5 against the stable 3.xxx branch should be
maintained and made available until such time as the known bugs against
the 4.xxx branch get sorted out.

Among other reasons, it is my perception that the Debian folks are quite
conservative about what they package/support so that an official Debian
distro against 3.xxx and Python2.5 is a more feasible request than one
against 4.xxx.


Art

Re: [Visualpython-users] Python 2.5

[Arthur S. <ajs...@op...>]

On Sat, 2006-10-07 at 16:14 -0600, Bruce Sherwood wrote:
> Just to try to keep the record straight: Isn't it the case that fink 
> touches ONLY its own directory, /sw? I don't see how it can "corrupt" 
> the system.

Also to keep the record straight - there is *no* incompatibility (of
which I am aware) between Python2.5 and VPython built with either
Numeric or numarray.

The issue regarding numpy compatibility is significant since numpy is
becoming the Python standard for multi-dimensional array processing, so
that, for example, the lives of educational projects like courses such
as:

http://www.physics.cornell.edu/sethna/teaching/ComputationalMethods/index.html

which use scipy (in which numpy is core) and which also use VPython are
becoming more complicated than it might be.

But to maintain perspective - the numpy issue is not an immediate
crisis, provided that the maintainers of the Windows distro, the Debian
distro, the fink distro, etc. proceed to make binary distributions
against Python2.5 available.  So that maybe the short-term focus should
be shifted there.  I am concerned about the perception regarding VPython
should there be a significant delay in making Python2.5 binaries
available, now that Python2.5 is itself final.

I will see if I can figure out who might be appropriate to contact to
urge that the ubuntu (debian based) distribution make a Python2.5
package available.

Bruce - 

who has been doing the Windows distro??

Mac - don't know.

Art

Re: [Visualpython-users] Python 2.5

[Jonathan B. <jbr...@ea...>]

On Sat, 2006-10-07 at 20:37 -0400, Arthur Siegel wrote:
> Hi Jonathan - 
> 
> I spent some (frustrating) time with this today.
> 
> Am I correct that num_util.h and num_util.cpp are those
> of Phil Austin @ Univ of British Columbia?
> 
> http://www.eos.ubc.ca/research/clouds/software/pythonlibs/num_util/num_util_release2/

The num_util code in VPython is _distantly_ descended from Phil Austin's
original work.  However, an intrepid coder may be able to learn enough
by reading his code to port the necessary changes to VPython.

-Jonathan

> If so, there is a new version targeting Numpy, as per the above link.
> 
> Except that I can't even get it to compile and run the tests correctly.
> 
> Choking on `intp` types and other places.
> 
> Grrrr...
> 
> Numpy is moving fast toward a 1.0 release and I have to wonder whether
> the num_util code is incompatible with the latest Numpy.
> 
> Or else I am doing something stupid.
> 
> Meanwhile I learn more when I get in this kind of trouble than when
> things go smoothly.
> 
> So I'm learning....
> 
> Art
> 
> On Sat, 2006-10-07 at 17:47 -0400, Jonathan Brandmeyer wrote:
> > On Fri, 2006-10-06 at 12:40 -0600, Bruce Sherwood wrote:
> > > Questions have been asked about Visual for Python 2.5. A significant 
> > > hurdle to overcome is that there is not and will not be a version of 
> > > Numeric for Python 2.5 (the last to be made was for Python 2.4). Its 
> > > successor Numarray does exist for Python 2.5 but is likely to be the 
> > > last, as the download instructions say "Use Numpy!"
> > 
> > The last time that I looked, the Numpy documentation was only available
> > for a fee.  That is why Visual was not extended to support it last
> > summer.  At any rate, the person(s) who decide to add support for Numpy
> > to VPython should see below.
> > 
> > >  Thanks to Jonathan 
> > > Brandmeyer's work, Visual can be compiled for Numarray, but some 
> > > existing VPython programs that used explicit Numeric capabilities may 
> > > break due to some incompatibilities between Numeric and Numarray.
> > > 
> > > The right thing to do is to revise Visual to use Numpy, which is the 
> > > designated to-be-supported replacement for both Numeric and Numarray. I 
> > > do not know how much work will be required to do this.
> > 
> > The revision effort should not be too difficult, as there is an
> > abstraction layer for Numeric/Numarray in VPython.  Basically, at
> > startup-time, a set of function pointers are initialized that refer to
> > either the Numarray or Numeric implementations.  Additionally,
> > Boost.Python support for the two libs is selected at run-time.
> > 
> > The affected files are:
> > VPython 3.x:
> > src/num_util_impl_numeric.cpp
> > src/num_util_impl_numarray.cpp
> > src/num_util.cpp
> > include/num_util_impl.hpp
> > include/num_util.hpp
> > 
> > The VPython 4.x files are setup in exactly the same way, except that
> > they are found in src/python and include/python.
> > 
> > See also site-packages/visual/array_backend.py in both versions,
> > although I think that there is a cleaner way to go about what this file
> > does.
> > 
> > Lastly, there are some configure script elements that would need to be
> > updated in acinclude.m4 (specifically, VISUAL_NUMERICLIBS).
> > 
> > HTH,
> > -Jonathan
> > 
> > 
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys -- and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Visualpython-users mailing list
> > Vis...@li...
> > https://lists.sourceforge.net/lists/listinfo/visualpython-users
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Python 2.5

[Arthur S. <ajs...@op...>]

Hi Jonathan - 

I spent some (frustrating) time with this today.

Am I correct that num_util.h and num_util.cpp are those
of Phil Austin @ Univ of British Columbia?

http://www.eos.ubc.ca/research/clouds/software/pythonlibs/num_util/num_util_release2/

If so, there is a new version targeting Numpy, as per the above link.

Except that I can't even get it to compile and run the tests correctly.

Choking on `intp` types and other places.

Grrrr...

Numpy is moving fast toward a 1.0 release and I have to wonder whether
the num_util code is incompatible with the latest Numpy.

Or else I am doing something stupid.

Meanwhile I learn more when I get in this kind of trouble than when
things go smoothly.

So I'm learning....

Art

On Sat, 2006-10-07 at 17:47 -0400, Jonathan Brandmeyer wrote:
> On Fri, 2006-10-06 at 12:40 -0600, Bruce Sherwood wrote:
> > Questions have been asked about Visual for Python 2.5. A significant 
> > hurdle to overcome is that there is not and will not be a version of 
> > Numeric for Python 2.5 (the last to be made was for Python 2.4). Its 
> > successor Numarray does exist for Python 2.5 but is likely to be the 
> > last, as the download instructions say "Use Numpy!"
> 
> The last time that I looked, the Numpy documentation was only available
> for a fee.  That is why Visual was not extended to support it last
> summer.  At any rate, the person(s) who decide to add support for Numpy
> to VPython should see below.
> 
> >  Thanks to Jonathan 
> > Brandmeyer's work, Visual can be compiled for Numarray, but some 
> > existing VPython programs that used explicit Numeric capabilities may 
> > break due to some incompatibilities between Numeric and Numarray.
> > 
> > The right thing to do is to revise Visual to use Numpy, which is the 
> > designated to-be-supported replacement for both Numeric and Numarray. I 
> > do not know how much work will be required to do this.
> 
> The revision effort should not be too difficult, as there is an
> abstraction layer for Numeric/Numarray in VPython.  Basically, at
> startup-time, a set of function pointers are initialized that refer to
> either the Numarray or Numeric implementations.  Additionally,
> Boost.Python support for the two libs is selected at run-time.
> 
> The affected files are:
> VPython 3.x:
> src/num_util_impl_numeric.cpp
> src/num_util_impl_numarray.cpp
> src/num_util.cpp
> include/num_util_impl.hpp
> include/num_util.hpp
> 
> The VPython 4.x files are setup in exactly the same way, except that
> they are found in src/python and include/python.
> 
> See also site-packages/visual/array_backend.py in both versions,
> although I think that there is a cleaner way to go about what this file
> does.
> 
> Lastly, there are some configure script elements that would need to be
> updated in acinclude.m4 (specifically, VISUAL_NUMERICLIBS).
> 
> HTH,
> -Jonathan
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Python 2.5

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

Just to try to keep the record straight: Isn't it the case that fink 
touches ONLY its own directory, /sw? I don't see how it can "corrupt" 
the system.

Mind you, I do very much want to eliminate dependence on fink and X11, 
for a host of good reasons, most especially because I keep getting notes 
from people saying they were unable to fight their way through a 
fink-based installation. One of the problems is that I and others have 
run into a problem that isn't fink's fault but which comes up in the 
fink/X11 context, which is that the Apple installer for X11 and/or Xcode 
fails to work properly, with no indication of the failure, and merely 
running the Apple installer again fixes the problem (not something that 
would occur to most users). So there's plenty of blame to go around in 
that non-user-friendly environment.

Bruce

Eric Ayars wrote:

>I (or my department if I can find a way to get a receipt for the  
>software "purchase") will contribute $50 towards a bounty for a Mac  
>OSX non-fink non-X11 "universal" standard-installer-package version  
>of vpython. Something I could pass out to students on CD's with  
>"double-click here" install instructions... and I know Bruce just  
>well enough that "To Bruce Sherwood's satisfaction" is sufficient for  
>me, too.
>
>At present, I use Parallels Desktop running Ubuntu to demo vpython on  
>this Mac in classes, rather than corrupt my system with fink...
>
>-ea
>
>-----------------------------------------------------------------
>Dr. Eric Ayars
>Assistant Professor of Physics
>California State University, Chico
>ay...@ma...
>
>
>On Oct 6, 2006, at 2:15 PM, Scott David Daniels wrote:
>
>  
>
>>Bruce Sherwood wrote:
>>    
>>
>>>There are two rather different routes toward supporting Visual on  
>>>Python
>>>2.5. The better route is to work with Visual 4, since that's what  
>>>we all
>>>want to use, given its greatly enhanced graphics capabilities.  
>>>However,
>>>if changing to Numpy doesn't require much effort (I have no idea), it
>>>would be good to put that into Visual 3, because there are some  
>>>serious
>>>problems with Visual 4, the most worrisome being the following
>>>(extracted from summary in Recent Developments section of  
>>>vpython.org):
>>>
>>>    1) Mouse interactions on Windows, including  
>>>scene.mouse.getclick(),
>>>    are associated with crashes. A tight loop without a rate()  
>>>statement
>>>    may crash or be hard to kill.
>>>
>>>    2) Some animations run in a jerky manner due to slow rendering of
>>>    the scene. The program gas.py is an example. The issue may be  
>>>that
>>>    the detail level on spheres needs to be decreased.
>>>
>>>    3) Graphing (from visual.graph import *) works well for many  
>>>simple
>>>    uses, but if the axes must be continually adjusted it can be very
>>>    slow. If you know the extent of your variables and can specify  
>>>xmax
>>>    and ymax for the graph, the graphing is very fast.
>>>
>>>I feel competent to deal with 3) and probably with 2) if it is just a
>>>matter of reducing the level of detail. But I don't feel competent to
>>>track down and fix problem 1), which might well involve tricky
>>>multithread issues. (For the graphing issue it is necessary to do  
>>>some
>>>work analogous to some coding I've already experimented with,  
>>>having to
>>>do with supporting different scale factors in x and y.)
>>>
>>>And there's the long-standing issue of finding someone to write a Mac
>>>version of the platform-specific files in Visual that handle  
>>>creating a
>>>window and handling mouse and keyset events, so that there could be a
>>>Mac-native version of VPython, not dependent on running X11 and  
>>>fink and
>>>difficult opaque installs. Hugh Fisher in Australia indicated  
>>>recently
>>>that he might be able to get free to do this in the near future.
>>>
>>>If we could get over the hump of having a usable Visual 4 for Windows
>>>and Mac (as far as I know it works fine on Linux), perhaps we would
>>>attract some new developers who could contribute, because Visual 4  
>>>comes
>>>much closer to offering "professional-grade" graphics likely to  
>>>interest
>>>people in the graphics area.
>>>      
>>>
>>You might consider offering a bounty for those projects (A: mouse
>>interaction, B: run on OS/X, C: move 4 to Numpy, D: move 3 to Numpy).
>>You might even solicit contributions to the bounty from your users.
>>Slightly tricky parts would be definitions of "acceptably solved",
>>though Bruce Sherwood's name has been associated with the project
>>for long enough that "to his satisfaction" may be an adequate
>>definition.  I'd be interested in working on the problem, but need
>>to keep a modicum of cash coming in, and you might well find someone
>>with the right mix of ability and cheap time to work on it.
>>
>>-- Scott David Daniels
>>Sco...@Ac...
>>
>>
>>---------------------------------------------------------------------- 
>>---
>>Take Surveys. Earn Cash. Influence the Future of IT
>>Join SourceForge.net's Techsay panel and you'll get the chance to  
>>share your
>>opinions on IT & business topics through brief surveys -- and earn  
>>cash
>>http://www.techsay.com/default.php? 
>>page=join.php&p=sourceforge&CID=DEVDEV
>>_______________________________________________
>>Visualpython-users mailing list
>>Vis...@li...
>>https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>    
>>
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users
>  
>

Re: [Visualpython-users] Python 2.5

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

Thanks much, Jonathan. This information is a big help.

Bruce

Jonathan Brandmeyer wrote:

>On Fri, 2006-10-06 at 12:40 -0600, Bruce Sherwood wrote:
>  
>
>>Questions have been asked about Visual for Python 2.5. A significant 
>>hurdle to overcome is that there is not and will not be a version of 
>>Numeric for Python 2.5 (the last to be made was for Python 2.4). Its 
>>successor Numarray does exist for Python 2.5 but is likely to be the 
>>last, as the download instructions say "Use Numpy!"
>>    
>>
>
>The last time that I looked, the Numpy documentation was only available
>for a fee.  That is why Visual was not extended to support it last
>summer.  At any rate, the person(s) who decide to add support for Numpy
>to VPython should see below.
>
>  
>
>> Thanks to Jonathan 
>>Brandmeyer's work, Visual can be compiled for Numarray, but some 
>>existing VPython programs that used explicit Numeric capabilities may 
>>break due to some incompatibilities between Numeric and Numarray.
>>
>>The right thing to do is to revise Visual to use Numpy, which is the 
>>designated to-be-supported replacement for both Numeric and Numarray. I 
>>do not know how much work will be required to do this.
>>    
>>
>
>The revision effort should not be too difficult, as there is an
>abstraction layer for Numeric/Numarray in VPython.  Basically, at
>startup-time, a set of function pointers are initialized that refer to
>either the Numarray or Numeric implementations.  Additionally,
>Boost.Python support for the two libs is selected at run-time.
>
>The affected files are:
>VPython 3.x:
>src/num_util_impl_numeric.cpp
>src/num_util_impl_numarray.cpp
>src/num_util.cpp
>include/num_util_impl.hpp
>include/num_util.hpp
>
>The VPython 4.x files are setup in exactly the same way, except that
>they are found in src/python and include/python.
>
>See also site-packages/visual/array_backend.py in both versions,
>although I think that there is a cleaner way to go about what this file
>does.
>
>Lastly, there are some configure script elements that would need to be
>updated in acinclude.m4 (specifically, VISUAL_NUMERICLIBS).
>
>HTH,
>-Jonathan
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users
>  
>