visualpython-users

Re: [Visualpython-users] to show visualization in a web page

[Flavio C. <fcc...@gm...>]

2005/6/30, Jonathan Brandmeyer <jbr...@ea...>:
>=20
> On Wed, 2005-06-29 at 23:21 -0700, Anton Sherwood wrote:
> > Titi Anggono wrote:
> > > I have a physics visualization using vpython. I just
> > > curios to show it in a web page. I want when a visitor
> > > clicks this file, a web browser will execute the
> > > program and generate the visualization.
>=20
> Starting your script from a web page shouldn't be a problem , see cherryp=
y=20
(www.cherrypy.org <http://www.cherrypy.org>) for a web application=20
framework, see also snakelets (www.snakelets.org <http://www.snakelets.org>=
).=20
your main chalenge will be to get the output of vpython in a format that ca=
n=20
be visualized through a web-browser: animated gif, mpg perhaps?=20
In any case, I believe, interactivity such as we heve in the standard=20
vpython canvas, would be out of the question.

I hope someone in vpython development team will correct if I am wrong. It=
=20
would be really good to have a way to integrate vpython into a web=20
application.



--=20
Fl=E1vio Code=E7o Coelho
registered Linux user # 386432
---------------------------
Great spirits have always found violent opposition from mediocrities. The
latter cannot understand it when a man does not thoughtlessly submit to
hereditary prejudices but honestly and courageously uses his intelligence.
Albert Einstein

Re: [Visualpython-users] to show visualization in a web page

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

On Wed, 2005-06-29 at 23:21 -0700, Anton Sherwood wrote:
> Titi Anggono wrote:
> > I have a physics visualization using vpython. I just
> > curios to show it in a web page. I want when a visitor
> > clicks this file, a web browser will execute the
> > program and generate the visualization.
> 
> Can VP be wrapped in a browser plugin?


Any such plugin would have to do some kind of sandboxing to insulate the
user from potentially malicious Python scripts (which can do anything a
virus, trojan, or other malware can).  As far as I know there is no such
execution environment for Python.

-Jonathan

Re: [Visualpython-users] to show visualization in a web page

[Anton S. <br...@po...>]

Titi Anggono wrote:
> I have a physics visualization using vpython. I just
> curios to show it in a web page. I want when a visitor
> clicks this file, a web browser will execute the
> program and generate the visualization.

Can VP be wrapped in a browser plugin?

-- 
Anton Sherwood, http://www.ogre.nu/
"How'd ya like to climb this high *without* no mountain?" --Porky Pine

[Visualpython-users] to show visualization in a web page

[Titi A. <tia...@ya...>]

hi all,

I have a physics visualization using vpython. I just
curios to show it in a web page. I want when a visitor
clicks this file, a web browser will execute the
program and generate the visualization.

I have tried using CGI but it didn't work. I use RH 9,
apache2.0.40, python2.2.2, mod_python-3.0.

Thank you for any suggestion about this problem




		
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 

Re: [Visualpython-users] OS X Native

[Eric A. <Ay...@ma...>]

I don't know if this would be helpful or not, but are you familiar  
with AquaTerm?

http://www.apple.com/downloads/macosx/unix_open_source/aquaterm.html

It's a display program for things that would normally be displayed  
under Xwindows. I know nothing about its inner workings, but I use it  
for Gnuplot output under OS X. Would this be a simple way to get  
vpython working in OS X without using Xwindows?

Good luck with the port either way. I'd be happy to help in any way  
possible, but my area of expertise does not extend to any serious  
system coding. I too dislike using fink, and would LOVE to be able to  
use vpython directly from the terminal with the default OS X install  
of python.

-EA

-----------------------------------------------------------------
Dr. Eric Ayars
Assistant Professor of Physics
California State University, Chico
ay...@ma...


On Jun 24, 2005, at 11:51 AM, Dethe Elza wrote:

> Hi folks,
>
> I'm willing to take another stab at porting VPython to OS X.  The  
> last time I tried I was not very familiar with the OS X libraries,  
> but I've grown more familiar with them since then, and I know where  
> to ask questions.  On the other hand, the VPython library itself  
> has been overhauled since then, and I am totally unfamiliar with  
> Boost.  Is there a specific version of Boost that I need (I know  
> SWIG is sensitive down the the point.point release).
>
> I'm hoping this will be fairly straightforward using the Apple  
> guidelines for porting Linux apps.  I don't have tons of spare  
> time, but I have a bunch of VPython scripts lying around that I'd  
> like to do something with, and the thought of installing Fink or  
> running on X11 gives me the heebie-jeebies.
>
> Any pointers for starting points appreciated.  I've read through  
> the list archives to see that I'll probably have to implement  
> glContext, glFont and platmac.(cpp|h).  Anything else?  The last  
> time I tried this, most of the work appeared to be handling locking  
> and bootstrapping an OpenGL context.
>
> Also, in CVS there are a number of modules.  The installer and DLLs  
> modules don't look applicable to OS X, but I'm not sure of the  
> status of the others.  There is a README in vpython-core2 saying  
> that it is an experimental branch, but it looks like that may be  
> the new Boost-based version.  Which modules are currently relevant?
>
> Thanks a bunch.
>
> --Dethe
>
> p.s., I realized when this mail bounced to me, that my last mail to  
> this list also bounced and I haven't had a chance to debug *why* it  
> bounced until today.  Here is that previous mail to give some  
> context to the above.
>
>
>> On 7-Jun-05, at 7:16 PM, Jon Schull wrote:
>>
>>
>>> Thanks I have done that (by adding " set path = (/usr/local/bin  
>>> $path)" to  .tcshrc) and all is well.
>>>
>>> Now, as momentary liaison between the  pythonmac and vpython  
>>> lists I'll mention that VPython (a truly beautiful thing) could  
>>> be made independent of  X11 if someone from this group knew how  
>>> to liberate it...
>>>
>>
>> I took a stab at it once, before VPython was refactored into C++,  
>> but I was still pretty new to OS X programming at the time, and it  
>> defeated me.  I haven't yet taken a look at the C++ version, it's  
>> on my todo list, but not a high priority right now.  I'd love to  
>> see VPython on OS X properly, but my hobby coding time is pretty  
>> limited right now.
>>
>> --Dethe
>>
>
>
> --
> Dethe Elza
> http://livingcode.org/
>
> When laws are outlawed, only outlaws will have laws.
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] Minor Windows installer fix

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

I've tried to cover this issue by something similar to option 3, though 
the other way around (which you may find unacceptable). The following 
text has been prominently displayed at the top of the Windows download 
page for a year or more:

"Note to experienced users of IDLE: The VPython installer overwrites the 
Python file Lib\idlelib\config-main.def to add the Visual reference 
manual to the Help menu, and to make the defaults editor-on-startup= 1 
and autosave= 1, as these have proved to be appropriate for most new 
users of VPython. You may wish to edit the file to reset these 
parameters to zero, or use the Options menu to reconfigure these 
options, or save a copy of the file before installing VPython and 
restore it afterwards."

In many educational settings it is not the user who installs VPython, so 
it does no good for the installation procedure to write into the user's 
settings, and a version of option 3 where there is a ReadMe on how to 
choose our settings would mean that every user, every time, would have 
to find that ReadMe file and carry out its instructions. (I'm not sure 
whether putting a file .idlerc in "All Users" would do the job, and I 
should try the experiment, and see whether InnoSetup can handle that.)

For what it's worth concerning option 2 (not a lot, since he doesn't set 
policy for Python), the main developer of the current version of IDLE 
told me that he personally likes our settings, at least the auto-save 
feature. So it's not a question of convincing him.

Bruce

Arthur wrote:
> 
>>-----Original Message-----
>>From: vis...@li... [mailto:visualpython-
> 
> 
> 
>>Here's what happened. Python24\Lib\idlelib\config-main.def contains the
>>specs for how IDLE works, and these preferences are used if you don't
>>have one of your own. I made a mistake in generating the Python 2.4
>>VPython for Windows in not setting these general preferences to the ones
>>novice users of VPython expect (start up edit window; autosave on run).
>>The second bug I fixed is that uninstall should not remove this file.
>>
>>In your Documents and Settings\Your Name\.idlerc is a personal file that
>>overrides, so that depending on past history you might or might not get
>>the behavior you expect.
> 
> 
> I haven't understood this decision. Nor find it supportable. 
> 
> IMO, config-main.def should be considered to be untouchable by an
> installation program.  It is a library file that represents the defaults
> chosen by the author of Idle. Idle is designed to allow these defaults to be
> overridden by specific mechanisms built-in to Idle and its users interface.
> Protocol, it seems to me, is to respect - if not the author's sense of "what
> a novice user expects" - than at least his/her mechanism for overriding it. 
> 
> The proper options seem to be to be (in no particular order):
> 
> 1) Have the Vpython installation create or overwrite (with warning) the
> .idlerc file in the appropriate location. 
> 
> 2) Convince the author of Idle to change the defaults in the official
> distribution to the one's you seem to think  "novice users of VPython
> expect".
> 
> 3) Include a Readme of some sort with VPython which instructs folks on the
> very simple and straightforward mechanism for changing the start-up defaults
> provided through the user interface.
> 
> I find no way to include the current VPython distribution decision -
> overwriting a library file - on a list of proper options.
> 
> I think the Windows distribution has in fact made great strides both
> technically, and in its handling of its responsibility to "play nice with
> others".  This is my last bone of contention with it.  
> 
> It's a small enough point, but to me represents an important principal of
> cooperation. So I happen to get a bit heated on the issue.
> 
> Do you see me as missing something here? 
> 
> Please do correct me if you see the basis to do so.
> 
> Art
> 
> 

RE: [Visualpython-users] Minor Windows installer fix

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

> -----Original Message-----
> From: vis...@li... [mailto:visualpython-


> Here's what happened. Python24\Lib\idlelib\config-main.def contains the
> specs for how IDLE works, and these preferences are used if you don't
> have one of your own. I made a mistake in generating the Python 2.4
> VPython for Windows in not setting these general preferences to the ones
> novice users of VPython expect (start up edit window; autosave on run).
> The second bug I fixed is that uninstall should not remove this file.
> 
> In your Documents and Settings\Your Name\.idlerc is a personal file that
> overrides, so that depending on past history you might or might not get
> the behavior you expect.

I haven't understood this decision. Nor find it supportable. 

IMO, config-main.def should be considered to be untouchable by an
installation program.  It is a library file that represents the defaults
chosen by the author of Idle. Idle is designed to allow these defaults to be
overridden by specific mechanisms built-in to Idle and its users interface.
Protocol, it seems to me, is to respect - if not the author's sense of "what
a novice user expects" - than at least his/her mechanism for overriding it. 

The proper options seem to be to be (in no particular order):

1) Have the Vpython installation create or overwrite (with warning) the
.idlerc file in the appropriate location. 

2) Convince the author of Idle to change the defaults in the official
distribution to the one's you seem to think  "novice users of VPython
expect".

3) Include a Readme of some sort with VPython which instructs folks on the
very simple and straightforward mechanism for changing the start-up defaults
provided through the user interface.

I find no way to include the current VPython distribution decision -
overwriting a library file - on a list of proper options.

I think the Windows distribution has in fact made great strides both
technically, and in its handling of its responsibility to "play nice with
others".  This is my last bone of contention with it.  

It's a small enough point, but to me represents an important principal of
cooperation. So I happen to get a bit heated on the issue.

Do you see me as missing something here? 

Please do correct me if you see the basis to do so.

Art

Re: [Visualpython-users] vpython and ode solvers

[Hans F. <H.F...@so...>]

Hi Gary,

> I've been wondering if there would be a programming, accuracy, or
> performance benefit to using a fancy ode solver with vpython rather than
> the canonical v = v + F/m * dt especially as the number of objects
> grows.  My thinking was that I could call the solver once per "frame"
> (say, 1/30 sec), solve for all of the variables all at once, and perhaps
> have better accuracy, and perhaps get more objects into the simulation.
>
> I began to experiment with scipy's odeint, and got some demos working.
> I ran across some instabilites that I tracked down, but before going any
> further I thought I'd ask:
>
> Does this seem worth the effort?

We used scipy.integrate.odeint quite successfully (in a teaching context).

> Is there something I haven't considered that dooms this idea?
Not sure. What doesn't work?

> Has someone already done this?
>
> The instablilty I found is related to in the way odeint (LSODA??)
> manages the independent variable.  I'd like to look at other solvers.
Are saying, it takes too large steps?


> Any suggestions?  In particular I'd like to look at a 4th order
> Runge-Kutta solver, but  the only RK4s that I've found are written in
> python.  Does anyone know where there's a python-wrapped C or Fortran RK
> solver?
My feeling is that the solver in odeint is far more sophisticated than a
RK4 solver. However, I would need more information as to what is
'instable' and what you have tried to overcome this.

Cheers,

Hans

[Visualpython-users] Minor Windows installer fix

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

Found and fixed two bugs in the Windows installer for Python 2.4, and 
updated vpython.org. I didn't change the version number.

Here's what happened. Python24\Lib\idlelib\config-main.def contains the 
specs for how IDLE works, and these preferences are used if you don't 
have one of your own. I made a mistake in generating the Python 2.4 
VPython for Windows in not setting these general preferences to the ones 
novice users of VPython expect (start up edit window; autosave on run). 
The second bug I fixed is that uninstall should not remove this file.

In your Documents and Settings\Your Name\.idlerc is a personal file that 
overrides, so that depending on past history you might or might not get 
the behavior you expect.

Bruce

[Visualpython-users] new povexport

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

At vpython.org is a new POV-Ray export module (povexport) that corrects 
an error. The older version failed to scale coordinates to fall within 
the range acceptable to POV-Ray. Now your VPython scene can be 
astronomical (e.g. 1e11) and export okay to POV-Ray.

Bruce Sherwood

Re: [Visualpython-users] OS X Native

[Dethe E. <de...@li...>]

On 24-Jun-05, at 6:39 PM, Jonathan Brandmeyer wrote:

> VPython itself will work with Boost.Python 1.31 or higher (1.33
> recommended right now).  However, different releases of Boost do not
> maintain any binary compatibility between them.  So if you decide to
> upgrade Boost.Python, you must recompile VPython.  Note that you do  
> not
> need to build any part of Boost other than the Python library.  The
> Boost Serialization Library is known to break Apple's custom  
> release of
> GCC, so your build will probably fail if you try to build everything.
>

Ah, knowing I only had to build Boost.Python would have helped.   
Boost 1.32.0_0 appears to have built cleanly from darwin ports, but  
it took a *loooong* time.


> That assessment is correct.  I think you will probably be able to  
> reuse
> the parts of platlinux.{cpp,h} that use POSIX (esp Pthreads).
>

Excellent!  As I recall the earlier version used GTK methods for  
threading, which complicated porting.  Posix will be a breath of  
fresh air after that.


> Thanks to the threading, some of the code flowpaths are hard to  
> follow,
> but I'll be happy to answer any questions you have about it.
>

I'll try to ask questions sooner rather than later.  I have a bad  
habit of trying to figure everything out for myself, which takes a  
lot longer and is far more frustrating.


> Your effort will be best spent working on the current release series,
> since the platform-specific/platform-agnostic boundaries are going to
> change a lot in the development sources before I start releasing  
> it.  I
> expect that your experience porting the stable VPython to native OSX
> will carry over to vpython-core2 (which will be publicly numbered  
> 4.0).
>

Yes, I will cut my teeth on the stable source.  If that goes well,  
perhaps I can
help port to the Cocoa context.  The new branch sounds very exciting,  
some things
I've looked forward to for a long time.

Thanks for the help and feedback!

--Dethe

There are two ways of constructing a software design.  One way is to  
make it so simple there are obviously no deficiencies and the other  
way is to make it so complicated that there are no obvious  
deficiencies.  --C.A.R. Hoare

Re: [Visualpython-users] OS X Native

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

On Fri, 2005-06-24 at 11:51 -0700, Dethe Elza wrote:
> Hi folks,
> 
> I'm willing to take another stab at porting VPython to OS X.

Wonderful!

>   The  
> last time I tried I was not very familiar with the OS X libraries,  
> but I've grown more familiar with them since then, and I know where  
> to ask questions.  On the other hand, the VPython library itself has  
> been overhauled since then, and I am totally unfamiliar with Boost.   
> Is there a specific version of Boost that I need (I know SWIG is  
> sensitive down the the point.point release).

VPython itself will work with Boost.Python 1.31 or higher (1.33
recommended right now).  However, different releases of Boost do not
maintain any binary compatibility between them.  So if you decide to
upgrade Boost.Python, you must recompile VPython.  Note that you do not
need to build any part of Boost other than the Python library.  The
Boost Serialization Library is known to break Apple's custom release of
GCC, so your build will probably fail if you try to build everything.

> I'm hoping this will be fairly straightforward using the Apple  
> guidelines for porting Linux apps.  I don't have tons of spare time,  
> but I have a bunch of VPython scripts lying around that I'd like to  
> do something with, and the thought of installing Fink or running on  
> X11 gives me the heebie-jeebies.
> 
> Any pointers for starting points appreciated.  I've read through the  
> list archives to see that I'll probably have to implement glContext,  
> glFont and platmac.(cpp|h).  Anything else?  The last time I tried  
> this, most of the work appeared to be handling locking and  
> bootstrapping an OpenGL context.

That assessment is correct.  I think you will probably be able to reuse
the parts of platlinux.{cpp,h} that use POSIX (esp Pthreads).

Thanks to the threading, some of the code flowpaths are hard to follow,
but I'll be happy to answer any questions you have about it.

> Also, in CVS there are a number of modules.  The installer and DLLs  
> modules don't look applicable to OS X, but I'm not sure of the status  
> of the others.  There is a README in vpython-core2 saying that it is  
> an experimental branch, but it looks like that may be the new Boost- 
> based version.  Which modules are currently relevant?

I restructured CVS a while ago to clean things up, but I left the old
modules in place to retain their history.  The "vpython" module contains
everything in the source distribution (except for the files built by the
autotools).  The "vpython-core2" module contains a complete rewrite of
the rendering engine that supports translucency, advanced lighting,
texture mapping, a more extensible rendering model, and support for
Python-level GUI toolkit integration (think VPython scene tightly
integrated with a PyGtk, wxPython, PyQT, PyWhoKnowsWhatTK application).
This module is fairly unstable right now, and will need quite a bit of
work before I start releasing betas.

Your effort will be best spent working on the current release series,
since the platform-specific/platform-agnostic boundaries are going to
change a lot in the development sources before I start releasing it.  I
expect that your experience porting the stable VPython to native OSX
will carry over to vpython-core2 (which will be publicly numbered 4.0).

-Jonathan

Re: [Visualpython-users] OS X Native

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

On Fri, 2005-06-24 at 19:25 -0400, Ilan Volow wrote:
> I've never understood why VPython wasn't written purely in python  
> using PyOpenGL as opposed to using C/C++ to do the OpenGL stuff as it  
> currently does. The few times I've looked at the VPython code, it  
> looked like a messy interweaving of python calling C calling python  
> calling C calling python etc.

Actually, its entirely Python->C++.  Right now, C++ never calls Python
code.

>  If all the OpenGL stuff were done with  
> PyOpenGL (and possibly PyGame), I would think that the code would be  
> cleaner and far more portable.

Bruce hit on the first reason - raw speed.  The fewer CPU cycles spent
rendering, the more can be spent doing physics.  The second is that the
rendering is performed asynchronously in a separate thread.  Python is
not really designed for multithreading; only one thread at a time can be
executing, even on Hyperthreading-equipped Pentium 4s, multiprocessor,
and multicore systems.

I have done some experimentation with PyOpenGL to prototype a different
OpenGL-using application.  I found that the performance was unacceptable
for any kind of dynamic scene, such as what most VPython client programs
create.

-Jonathan

Re: [Visualpython-users] OS X Native

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

It is complex code for a reason: performance. Computers do get faster, 
so this is a moving target. But when David Scherer was first 
implementing the Visual module in the spring of 2000, with a need to run 
on 200 Mhz PC's, it was not an option to use anything other than very 
tightly coded multithreaded C++. I don't know enough about other 
alternatives to be able to judge whether it would be feasible now to use 
a simpler architecture, though I doubt it.

Bruce Sherwood

Ilan Volow wrote:
> I've never understood why VPython wasn't written purely in python  using 
> PyOpenGL as opposed to using C/C++ to do the OpenGL stuff as it  
> currently does. The few times I've looked at the VPython code, it  
> looked like a messy interweaving of python calling C calling python  
> calling C calling python etc. If all the OpenGL stuff were done with  
> PyOpenGL (and possibly PyGame), I would think that the code would be  
> cleaner and far more portable.
> 
> 
> On Jun 24, 2005, at 3:56 PM, Dethe Elza wrote:
> 
>>
>> I realize that it's easier, but I don't want Fink on my system.   Too 
>> many problems last time I did that.  Also, while I have X11  installed 
>> (just in case), I really prefer not to use it--and don't  see why I 
>> should for an OpenGL-based program when OS X has great  OpenGL support.
>>
>> So I'll tilt at the windmill and see who wins.  %-)
>>
>> --Dethe
>>
>> This past week, everyday when I opened my Wall Street Journal, I  was 
>> met with a full page ad from Microsoft. This ad was dominated  by 
>> three simple words "Protect your PC." This strikes me as  something 
>> akin to the Saudi government running ads in the New York  Times in 
>> mid-September of 2001 saying "Protect your Tall  Buildings." --Russ 
>> McGuire
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] OS X Native

[Ilan V. <ig...@nc...>]

I've never understood why VPython wasn't written purely in python  
using PyOpenGL as opposed to using C/C++ to do the OpenGL stuff as it  
currently does. The few times I've looked at the VPython code, it  
looked like a messy interweaving of python calling C calling python  
calling C calling python etc. If all the OpenGL stuff were done with  
PyOpenGL (and possibly PyGame), I would think that the code would be  
cleaner and far more portable.


On Jun 24, 2005, at 3:56 PM, Dethe Elza wrote:

>
> I realize that it's easier, but I don't want Fink on my system.   
> Too many problems last time I did that.  Also, while I have X11  
> installed (just in case), I really prefer not to use it--and don't  
> see why I should for an OpenGL-based program when OS X has great  
> OpenGL support.
>
> So I'll tilt at the windmill and see who wins.  %-)
>
> --Dethe
>
> This past week, everyday when I opened my Wall Street Journal, I  
> was met with a full page ad from Microsoft. This ad was dominated  
> by three simple words "Protect your PC." This strikes me as  
> something akin to the Saudi government running ads in the New York  
> Times in mid-September of 2001 saying "Protect your Tall  
> Buildings." --Russ McGuire
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] OS X Native

[Dethe E. <de...@li...>]

On 24-Jun-05, at 12:06 PM, Bruce Sherwood wrote:

> What you want is vpython; vpython-core2 is the experimental work  
> Jonathan Brandmeyer is doing to add transparency, surface textures,  
> and sophisticated lighting.

Well, that's both useful (work in vpython) and great news (textures  
and transparency are my two highest wishlist items for VPython).   
Thanks!

> I made an uninformed and unsuccessful attempt to compile the boost  
> libraries (www.boost.org) on OSX 10.4. First I tried using the gcc  
> that comes with, and that didn't work, complaining about something  
> having to do with "shared" (libraries). Jonathan had mentioned that  
> the gcc 4.0.0 that comes with 10.4 was grabbed from the GNU people  
> when it was still very unstable, so I tried installing from  
> gcc.gnu.org. There is a recent 4.0.0 there, but to avoid confusion  
> I tried installing (bootstrap install) of gcc 3.4.4, with the  
> parameters specified in vpython/INSTALL.txt, which unfortunately  
> failed in a way meaningless to me. So I didn't get very far just  
> trying to get an X11 version compiled for 10.4.

I'm working on getting Boost to compile right now.  I'll let you know  
if I succeed.

> I will say that installing the old VPython on 10.4 using fink is  
> actually quite painless now, thanks to the packaging done by Martin  
> Costabel. And you can easily install X11 and Xcode from the 10.4  
> DVD. Building a native-mode Mac VPython would be a wonderful  
> contribution, but certainly vastly more difficult than merely  
> installing the old pre-boost VPython.

I realize that it's easier, but I don't want Fink on my system.  Too  
many problems last time I did that.  Also, while I have X11 installed  
(just in case), I really prefer not to use it--and don't see why I  
should for an OpenGL-based program when OS X has great OpenGL support.

So I'll tilt at the windmill and see who wins.  %-)

--Dethe

This past week, everyday when I opened my Wall Street Journal, I was  
met with a full page ad from Microsoft. This ad was dominated by  
three simple words "Protect your PC." This strikes me as something  
akin to the Saudi government running ads in the New York Times in mid- 
September of 2001 saying "Protect your Tall Buildings." --Russ McGuire

Re: [Visualpython-users] OS X Native

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

What you want is vpython; vpython-core2 is the experimental work 
Jonathan Brandmeyer is doing to add transparency, surface textures, and 
sophisticated lighting.

I made an uninformed and unsuccessful attempt to compile the boost 
libraries (www.boost.org) on OSX 10.4. First I tried using the gcc that 
comes with, and that didn't work, complaining about something having to 
do with "shared" (libraries). Jonathan had mentioned that the gcc 4.0.0 
that comes with 10.4 was grabbed from the GNU people when it was still 
very unstable, so I tried installing from gcc.gnu.org. There is a recent 
4.0.0 there, but to avoid confusion I tried installing (bootstrap 
install) of gcc 3.4.4, with the parameters specified in 
vpython/INSTALL.txt, which unfortunately failed in a way meaningless to 
me. So I didn't get very far just trying to get an X11 version compiled 
for 10.4.

I will say that installing the old VPython on 10.4 using fink is 
actually quite painless now, thanks to the packaging done by Martin 
Costabel. And you can easily install X11 and Xcode from the 10.4 DVD. 
Building a native-mode Mac VPython would be a wonderful contribution, 
but certainly vastly more difficult than merely installing the old 
pre-boost VPython.

Bruce Sherwood

Dethe Elza wrote:
> Hi folks,
> 
> I'm willing to take another stab at porting VPython to OS X.  The  last 
> time I tried I was not very familiar with the OS X libraries,  but I've 
> grown more familiar with them since then, and I know where  to ask 
> questions.  On the other hand, the VPython library itself has  been 
> overhauled since then, and I am totally unfamiliar with Boost.   Is 
> there a specific version of Boost that I need (I know SWIG is  sensitive 
> down the the point.point release).
> 
> I'm hoping this will be fairly straightforward using the Apple  
> guidelines for porting Linux apps.  I don't have tons of spare time,  
> but I have a bunch of VPython scripts lying around that I'd like to  do 
> something with, and the thought of installing Fink or running on  X11 
> gives me the heebie-jeebies.
> 
> Any pointers for starting points appreciated.  I've read through the  
> list archives to see that I'll probably have to implement glContext,  
> glFont and platmac.(cpp|h).  Anything else?  The last time I tried  
> this, most of the work appeared to be handling locking and  
> bootstrapping an OpenGL context.
> 
> Also, in CVS there are a number of modules.  The installer and DLLs  
> modules don't look applicable to OS X, but I'm not sure of the status  
> of the others.  There is a README in vpython-core2 saying that it is  an 
> experimental branch, but it looks like that may be the new Boost- based 
> version.  Which modules are currently relevant?
> 
> Thanks a bunch.
> 
> --Dethe
> 
> p.s., I realized when this mail bounced to me, that my last mail to  
> this list also bounced and I haven't had a chance to debug *why* it  
> bounced until today.  Here is that previous mail to give some context  
> to the above.
> 
>> On 7-Jun-05, at 7:16 PM, Jon Schull wrote:
>>
>>> Thanks I have done that (by adding " set path = (/usr/local/bin  
>>> $path)" to  .tcshrc) and all is well.
>>>
>>> Now, as momentary liaison between the  pythonmac and vpython lists  
>>> I'll mention that VPython (a truly beautiful thing) could be made  
>>> independent of  X11 if someone from this group knew how to  liberate 
>>> it...
>>
>>
>> I took a stab at it once, before VPython was refactored into C++,  but 
>> I was still pretty new to OS X programming at the time, and it  
>> defeated me.  I haven't yet taken a look at the C++ version, it's  on 
>> my todo list, but not a high priority right now.  I'd love to  see 
>> VPython on OS X properly, but my hobby coding time is pretty  limited 
>> right now.
>>
>> --Dethe
> 
> 
> 
> -- 
> Dethe Elza
> http://livingcode.org/
> 
> When laws are outlawed, only outlaws will have laws.
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

[Visualpython-users] OS X Native

[Dethe E. <de...@li...>]

Hi folks,

I'm willing to take another stab at porting VPython to OS X.  The  
last time I tried I was not very familiar with the OS X libraries,  
but I've grown more familiar with them since then, and I know where  
to ask questions.  On the other hand, the VPython library itself has  
been overhauled since then, and I am totally unfamiliar with Boost.   
Is there a specific version of Boost that I need (I know SWIG is  
sensitive down the the point.point release).

I'm hoping this will be fairly straightforward using the Apple  
guidelines for porting Linux apps.  I don't have tons of spare time,  
but I have a bunch of VPython scripts lying around that I'd like to  
do something with, and the thought of installing Fink or running on  
X11 gives me the heebie-jeebies.

Any pointers for starting points appreciated.  I've read through the  
list archives to see that I'll probably have to implement glContext,  
glFont and platmac.(cpp|h).  Anything else?  The last time I tried  
this, most of the work appeared to be handling locking and  
bootstrapping an OpenGL context.

Also, in CVS there are a number of modules.  The installer and DLLs  
modules don't look applicable to OS X, but I'm not sure of the status  
of the others.  There is a README in vpython-core2 saying that it is  
an experimental branch, but it looks like that may be the new Boost- 
based version.  Which modules are currently relevant?

Thanks a bunch.

--Dethe

p.s., I realized when this mail bounced to me, that my last mail to  
this list also bounced and I haven't had a chance to debug *why* it  
bounced until today.  Here is that previous mail to give some context  
to the above.

> On 7-Jun-05, at 7:16 PM, Jon Schull wrote:
>
>> Thanks I have done that (by adding " set path = (/usr/local/bin  
>> $path)" to  .tcshrc) and all is well.
>>
>> Now, as momentary liaison between the  pythonmac and vpython lists  
>> I'll mention that VPython (a truly beautiful thing) could be made  
>> independent of  X11 if someone from this group knew how to  
>> liberate it...
>
> I took a stab at it once, before VPython was refactored into C++,  
> but I was still pretty new to OS X programming at the time, and it  
> defeated me.  I haven't yet taken a look at the C++ version, it's  
> on my todo list, but not a high priority right now.  I'd love to  
> see VPython on OS X properly, but my hobby coding time is pretty  
> limited right now.
>
> --Dethe


--
Dethe Elza
http://livingcode.org/

When laws are outlawed, only outlaws will have laws.

Re: [Visualpython-users] ImportError

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

On Wed, 2005-06-22 at 14:48 -0400, Michael F. Vineyard wrote:
> Hi Folks,
> 
> I just installed vpython on a Fedora Core 1 Linux system with python
> 2.4, boost 1.32, and numeric-24. After some messing around with boost,
> numeric, and some libraries, vpython appeared to build just fine. But I
> get the following error when I try to run a demo. Any ideas?
> 
> Thanks,
> 
> Mike
> 
> Traceback (most recent call last):
>   File
> "/home/vineyard/teaching/m_and_i_demos/Lib/site-packages/visual/demos/bounce.py", line 1, in -toplevel-
>     from visual import *
>   File "/usr/local/lib/python2.4/site-packages/visual/__init__.py", line
> 15, in -toplevel-
>     import array_backend
>   File "/usr/local/lib/python2.4/site-packages/visual/array_backend.py",
> line 1, in -toplevel-
>     import cvisual
> ImportError: /usr/local/lib/python2.4/site-packages/cvisualmodule.so:
> undefined symbol:
> _ZNK5boost6python7objects21py_function_impl_base9max_arityEv

cvisualmodule.so didn't link properly to libboost_python.so.  First
guess: Does your Boost.Python build include shared libraries as well as
static libs?

-Jonathan

Re: [Visualpython-users] vpython and ode solvers

[Eric A. <Ay...@ma...>]

I've been using Python (occasionally with vpython) for an undergrad- 
level computational physics course, and have had excellent results  
with an RK4 routine. Here's a sample program: http:// 
phys.csuchico.edu/ayars/250/code/spring-pendulum.shtml (Ignore the  
"error processing directive" messages on the webpage -- the page is  
not up to date at the moment but the code shown is good.) As you  
suggest, I solve all variables at once: in this example I use the  
array y[] as a container.

I've found that for displaying things on-screen in vpython, a python- 
based RK4 routine is not the speed-limiting factor. If you need to go  
with a c routine, though, you might consider writing your own and  
then using SWIG (http://www.swig.org/) as a way of making a python  
wrapper for it. I'm new to SWIG (as of this week, actually) but it is  
working very well for me so far.

Hope this helps.
-EA

-----------------------------------------------------------------
Dr. Eric Ayars
Assistant Professor of Physics
California State University, Chico
ay...@ma...


On Jun 22, 2005, at 10:53 AM, Gary wrote:

> I've been wondering if there would be a programming, accuracy, or  
> performance benefit to using a fancy ode solver with vpython rather  
> than the canonical v = v + F/m * dt especially as the number of  
> objects grows.  My thinking was that I could call the solver once  
> per "frame" (say, 1/30 sec), solve for all of the variables all at  
> once, and perhaps have better accuracy, and perhaps get more  
> objects into the simulation.
>
> I began to experiment with scipy's odeint, and got some demos  
> working.  I ran across some instabilites that I tracked down, but  
> before going any further I thought I'd ask:
>
> Does this seem worth the effort?
>
> Is there something I haven't considered that dooms this idea?
>
> Has someone already done this?
>
> The instablilty I found is related to in the way odeint (LSODA??)  
> manages the independent variable.  I'd like to look at other  
> solvers.  Any suggestions?  In particular I'd like to look at a 4th  
> order Runge-Kutta solver, but  the only RK4s that I've found are  
> written in python.  Does anyone know where there's a python-wrapped  
> C or Fortran RK solver?
>
> Thanks,
> Gary
>
>

RE: [Visualpython-users] vpython and ode solvers

[Rodney D. <rod...@gm...>]

Gary,

I'm working on a solar-system dynamics package using VPython, so I've
been dealing with these issues for several weeks now-- although I'm
not familiar with scipy's solver.  Which integration method is best
(an RK variant or a symplectic integrator) depends on what type of
information you need to extract from the model.  But in all cases the
accuracy is controlled by the time step.

Several of the best integration routines make use of backward time
steps to reduce errors.  You must find a way of hiding these steps
from the animation; else your objects will do a "cha-cha" dance when
they should be moving in the direction of the current velocity.  Many
of the integrators in the RK family use variable step sizes to improve
accuracy.  If directly connected to the animation, these integrators
will cause your particles to speed up and slow down with the varying
time step, masking the particles' true changes in speed.  If you use
of these integrators, you must find a way to disconnect the integrator
from the animation.

I don't know the details of your simulation.  In my experience, aside
from the usual places (square roots and cross products), the
performance hit comes in the routine that updates the forces, not the
integrator.  If the particles are interacting, you will need to find
the particle-particle distance for each pair in order to update the
forces.  So the computational effort required to update the forces
scales with the square of the number of particles.  The good news
though is that the accuracy is nearly at machine precision.  If you
have a simulation with a large number of particles, there are several
strategies that can improve performance by avoiding direct force
calculations-- although at a cost in accuracy.  The best solution
depends on the details of your problem.

Hope this helps.

--
Rodney Dunning
rdu...@bs...
Assistant Professor of Physics
Birmingham-Southern College

[Visualpython-users] ImportError

[Michael F. V. <vin...@un...>]

Hi Folks,

I just installed vpython on a Fedora Core 1 Linux system with python
2.4, boost 1.32, and numeric-24. After some messing around with boost,
numeric, and some libraries, vpython appeared to build just fine. But I
get the following error when I try to run a demo. Any ideas?

Thanks,

Mike

Traceback (most recent call last):
  File
"/home/vineyard/teaching/m_and_i_demos/Lib/site-packages/visual/demos/bounce.py", line 1, in -toplevel-
    from visual import *
  File "/usr/local/lib/python2.4/site-packages/visual/__init__.py", line
15, in -toplevel-
    import array_backend
  File "/usr/local/lib/python2.4/site-packages/visual/array_backend.py",
line 1, in -toplevel-
    import cvisual
ImportError: /usr/local/lib/python2.4/site-packages/cvisualmodule.so:
undefined symbol:
_ZNK5boost6python7objects21py_function_impl_base9max_arityEv

-- 
Michael F. Vineyard			Email: vin...@un...
Department of Physics & Astronomy	Web: http://www1.union.edu/~vineyarm
Union College				Phone: (518) 388-8353
Schenectady, NY 12308			Fax: (518) 388-6947

[Visualpython-users] vpython and ode solvers

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

I've been wondering if there would be a programming, accuracy, or 
performance benefit to using a fancy ode solver with vpython rather than 
the canonical v = v + F/m * dt especially as the number of objects 
grows.  My thinking was that I could call the solver once per "frame" 
(say, 1/30 sec), solve for all of the variables all at once, and perhaps 
have better accuracy, and perhaps get more objects into the simulation.

I began to experiment with scipy's odeint, and got some demos working.  
I ran across some instabilites that I tracked down, but before going any 
further I thought I'd ask:

Does this seem worth the effort?

Is there something I haven't considered that dooms this idea?

Has someone already done this?

The instablilty I found is related to in the way odeint (LSODA??) 
manages the independent variable.  I'd like to look at other solvers.  
Any suggestions?  In particular I'd like to look at a 4th order 
Runge-Kutta solver, but  the only RK4s that I've found are written in 
python.  Does anyone know where there's a python-wrapped C or Fortran RK 
solver?

Thanks,
Gary

[Visualpython-users] Vpython with pygame.game

[cchuang <cc...@ma...>]

Hi,
  
    I had released a booklet about VPython and Pygame. All are written 
within TeXmacs with its Python plugin and shell plugin.
 
   In this booklet, there are some vpython examples including:
1. a 3D reflected Brownian partitle travels within a box, (Neuman 
condition). As the RBM particle hits one of the walls, the hitting sound 
will be rendering by pygame.sound.
2. Runge-Kutta method for ODE.s. Model the projectile of baseball and 
Rutherford Scattering Experiment.

The file can be downloaded from:  
ftp://math.cgu.edu.tw/pub/KNOPPIX/game4.pdf

In this  file  server, we also  apply some  variant  KNOPPIX  bootable 
DVD image file, based on  knoppix-3.8.  Python Environment  is also 
included, for example,  visual,  scipy etc.  User can easily extend 
his/her need with the help of unionfs in KNOPPIX. In other words, users  
can read, write even install the packages on the DVD-linux.
Hope this  really help to you!

Re: [Visualpython-users] Mac OSX 10.4

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

Thanks for the explanation, Martin. Also, I found the following Fink FAQ 
about the matter, with the key comment at the end that there's more to 
this than just adding /sw/bin to the application search path.

Q5.15: I get "command not found" errors when I run Fink or anything that 
I installed with Fink.

A: If this always happens, then you may have inadvertently modified (or 
failed to modify) your startup scripts. Run the /sw/bin/pathsetup.sh 
script in a terminal window. This program will attempt to detect your 
default shell and add a command to load Fink's shell initialization 
script into your shell's configuration. You'll then need to open a new 
terminal session so that your environment settings are loaded. Note: 
Some older versions fink called this script pathsetup.command instead of 
pathsetup.sh. Alternately, you can run the pathsetup.app application on 
the Fink binary distribution disk image.

On the other hand, if you only have problems in the Apple X11 terminal, 
this probably means that you need to create a .xinitrc file and add the line

. /sw/bin/init.sh

near the beginning (i.e. before any programs get run). Restart X11 (if 
running) after you do this.

These /sw/bin/init.* scripts do much more than just add /sw/bin to your 
PATH. Many packages will not work correctly without these additional 
actions.

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

Martin Costabel wrote:
> Bruce Sherwood wrote:
> 
>> I did a clean install of Mac OSX 10.4, installed X11 (found by 
>> scrolling down to "Optional Installs" on the installer DVD), installed 
>> Fink, and installed VPython, all as per instructions which have been 
>> updated at vpython.org. Many thanks to Martin Costabel for getting a 
>> version of Visual into the packages for the 10.4 version of Fink.
>>
>> One minor thing went wrong: Fink creates a statment in my .profile 
>> file which should effectively add /sw/bin to the application search 
>> path. However, it doesn't work: I have to execute /sw/bin/vpython 
>> rather than simply executing vpython. I tried putting other 
>> path-setting statements in .profile to no avail. I suspect that 
>> somehow my .profile is not being processed when I start up X11. A 
>> colleage also had this problem. Is there a Unix expert who can advise 
>> us on this? Thanks.
> 
> 
> If there were a FAQ for Apple's X11, this would be one of the most FAQs :-)
> 
> X11.app, since it is not started from a shell but from the Finder, does 
> not inherit any environment from shell startup scripts. You have to make 
> sure yourself that the environment is loaded at the point where you 
> start your command; how to do it depends on how you start your vpython 
> command. There are lots of different possibilities, depending on whether 
> you run your command on the command line from an xterm, from ~/.xinitrc 
> or the Applications menu and in case you start it from an xterm, whether 
> you started your xterm from ~/.xinitrc or from the Applications menu.
> 
> Three of the most popular ways to get over this hurdle are:
> 
> 1. Don't use xterm. Set DISPLAY=:0 in your Terminal.app window and run 
> vpython from there. The shell running inside Terminal.app windows has a 
> decent environment. Or use "open-x11 vpython". This has the additional 
> advantage of starting X11.app if it is not running.
> 2. Start your xterm not as "xterm" but as "xterm -ls".
> 3. Start your xterm from ~/.xinitrc, but have a line
> "source /sw/bin/init.sh" as first line of ~/.xinitrc.
>