visualpython-users

[Visualpython-users] Unum

[Kevin K. <ka...@so...>]

I tried doing 4.P.89 and 4.P.90 using the Unum package for keeping
track of units.  I found this quite nice, as it caught several typos
where I had the wrong variable causing the wrong units.

It would be even nicer if object.pos,.length,.axis, ... could be
specified with units, rather than having to be converted to pure
numbers.

Kevin Karplus

[Visualpython-users] VPython at Haverford College

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

In the contributed section of vpython.org is a link to a variety of
Haverford College research and education materials in VPython, offered
by Suzanne Amador Kane.

Bruce Sherwood

Re: [Visualpython-users] Help with Linux?

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

On Dec 16, 2011 12:34 PM, "Bruce Sherwood" <Bru...@nc...> wrote:
>
> Isn't there a knowledgeable Ubuntu user in the VPython community who
> could collaborate with Aaron on this?

I think you'll want to be working with Debian more than anything -- AFAIK
Ubuntu just syncs the vast majority of packages from Debian Sid.  Get a
maintainer there and you'll probably get an updated Ubuntu for free ...
been a long time since I used the 'buntu so maybe the process is a bit
different now.

--

C Anthony [mobile]

Re: [Visualpython-users] Help with Linux?

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

Aaron Mavrinac has volunteered to help with Linux but comments about
Ubuntu, "This I can't help with, as I don't use Ubuntu. I do maintain
an up-to-date ebuild for Gentoo/Funtoo in my unofficial overlay."

Isn't there a knowledgeable Ubuntu user in the VPython community who
could collaborate with Aaron on this? It now seems clear that what is
needed is really just 1) testing VPython on new Ubuntu releases, to
catch problems such as happened recently with a library function no
longer working, and 2) preparing up-to-date packages to be hosted at
vpython.org, because Ubuntu can be a couple years behind VPython
developments (it's a secondary issue to pester Ubuntu to put "our"
package in "their" distribution).

Bruce Sherwood

On Sat, Dec 10, 2011 at 7:57 PM, Bruce Sherwood <Bru...@nc...> wrote:
> If you have significant experience with Linux, please consider helping
> maintain the Linux version of VPython.
>
> It has been some years since a real Linux expert worked with VPython;
> that was Jonathan Brandmeyer. Some expertise is needed, because with
> every new release of Ubuntu, presumably the most popular Linux
> distribution, there's a pretty high probability that something will go
> wrong, as was the case with the function Gdk::GL::get_proc_address
> breaking. Moreover, the Ubuntu package python-visual is typically far
> behind the current version of Visual. The latest version of Ubuntu
> offers a python-visual package that is version 5.12, released in
> August 2009, over two years ago (the current version is 5.72).
>
> I hope very much that one or more Linux VPython users will step
> forward and take responsibility for some aspects of maintaining Visual
> on Linux. Here are the main issues that I see as needing ongoing
> attention:
>
> * Improve the build machinery. Brandmeyer made a very important
> contribution in creating the autoconfigure machinery that made it
> possible to build on diverse Linuxes. However, this machinery is
> showing its age. For example, it doesn't deal with 64-bit machines,
> and it's aimed at site-packages rather than the now-favored
> dist-packages. Moreover, the autoconfigure machinery is quite complex
> and not easy to modify. Probably someone(s) should experiment with
> using distutils instead of autoconfig for building Visual.
>
> * Get involved with the process that leads to a python-visual package
> for Ubuntu. I know nothing about this process, but it's clearly not
> working. It would seem that there is little or no testing of the
> package, and as noted above the package is woefully out of date. The
> Ubuntu/Debian package should be built and tested by users of VPython
> and offered to those who assemble the next version of the Linux
> distribution.
>
> I'm guessing that for someone who knows Linux well, these tasks would
> not be difficult, but they need to be done.
>
> Bruce Sherwood

Re: [Visualpython-users] Help with Linux?

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

On Sun, Dec 11, 2011 at 6:47 PM, Bruce Sherwood <Bru...@nc...> wrote:
> Upon reflection, maybe it's irrelevant to worry about official Linux
> packages and updates. If Aaron and others could build packages for
> Visual for the most popular distributions (rpm etc.), they could be
> hosted on the download page at vpython.org. As long as the packages do
> their job of automatically resolving the many dependencies, it's not
> all that important whether Ubuntu and other distributions include
> "our" packages in their official list of packages or not.

This is essentially the approach we took with Thousand Parsec [1]
packaging: provide up-to-date in-house packages and
repositories/overlays for the most popular distributions' package
managers, and (secondarily) attempt to get them included/updated in
official repositories. The main thing needed for the latter is for
someone to "adopt" the package within each distro -- shouldn't be a
problem for Visual, as it's fairly well established in this sense --
and then for an upstream (VPython) developer to poke the various
maintainers whenever there's a new release. As long as upstream
developers do the actual packaging work, the distro developers should
normally only need to QA and update, with minimal back-and-forth.
Incidentally, this line of communication can help upstream build
better packages for each distro as well.


[1] http://thousandparsec.net/tp

(Sorry for the double message, Bruce!)

-- 
Aaron Mavrinac
www.mavrinac.com

Re: [Visualpython-users] Fixed Linux problem

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

I look forward to seeing what you're able to do with a pure Python version.

Bruce Sherwood

On Sun, Dec 11, 2011 at 2:36 PM, James Thomas <jt...@mi...> wrote:
> Thanks for getting that fixed Bruce, now I can get on to my simulation.  I
> actually have an almost working version of a PyOpenGL version of visual that
> supports a few of the simple shapes and frames.  After I get my near term
> work finished I hope to be able to continue that to a more complete state.
>
> JT
>
> On Sat, Dec 10, 2011 at 4:06 PM, Bruce Sherwood <Bru...@nc...>
> wrote:
>>
>> On the Linux download page at vpython.org there is a rebuilt source
>> package for VPython 5.72 which fixes the crashes on Linux (tested on
>> the latest Ubuntu).
>>
>> The problem turned out to be that in src/gtk2/display.cpp the function
>> Gdk::GL::get_proc_address is broken on recent releases of Ubuntu and
>> Debian (and maybe Fedora) and has been replaced with glXGetProcAddress
>> which does work.
>>
>> Bruce Sherwood
>>
>> P.S. I'll mention that in my many years of work with VPython on three
>> different platforms, the Windows environment has been remarkably
>> stable across operating system changes, the Mac environment much less
>> so (in that until recently things broke when the OS version number
>> changed in the last decimal place), and Linux also has been somewhat
>> unstable.
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
>> Microsoft is holding a special Learn Windows Azure training event for
>> developers. It will provide a great way to learn Windows Azure and what it
>> provides. You can attend the event by watching it streamed LIVE online.
>> Learn more at http://p.sf.net/sfu/ms-windowsazure
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

Re: [Visualpython-users] Help with Linux?

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

Upon reflection, maybe it's irrelevant to worry about official Linux
packages and updates. If Aaron and others could build packages for
Visual for the most popular distributions (rpm etc.), they could be
hosted on the download page at vpython.org. As long as the packages do
their job of automatically resolving the many dependencies, it's not
all that important whether Ubuntu and other distributions include
"our" packages in their official list of packages or not.

Bruce Sherwood

Re: [Visualpython-users] Fixed Linux problem

[James T. <jt...@mi...>]

Thanks for getting that fixed Bruce, now I can get on to my simulation.  I
actually have an almost working version of a PyOpenGL version of visual
that supports a few of the simple shapes and frames.  After I get my near
term work finished I hope to be able to continue that to a more complete
state.

JT

On Sat, Dec 10, 2011 at 4:06 PM, Bruce Sherwood <Bru...@nc...>wrote:

> On the Linux download page at vpython.org there is a rebuilt source
> package for VPython 5.72 which fixes the crashes on Linux (tested on
> the latest Ubuntu).
>
> The problem turned out to be that in src/gtk2/display.cpp the function
> Gdk::GL::get_proc_address is broken on recent releases of Ubuntu and
> Debian (and maybe Fedora) and has been replaced with glXGetProcAddress
> which does work.
>
> Bruce Sherwood
>
> P.S. I'll mention that in my many years of work with VPython on three
> different platforms, the Windows environment has been remarkably
> stable across operating system changes, the Mac environment much less
> so (in that until recently things broke when the OS version number
> changed in the last decimal place), and Linux also has been somewhat
> unstable.
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

[Visualpython-users] Second Display Closing Problem

[Kadir H. <kha...@ya...>]

I know we have more strategic problems, but I have a funny small problem with closing (set invisible) the second display.
Consider the following simple code:

from visual import *

d1 = display()
d2 = display()

b1 = box(color=(1,0,0), display=d1)
b2 = box(color=(0,0,1), display=d2)

tl = label(text="Which display is selected?")

sd = tl.display

sd.mouse.getclick()
sd.visible = 0


The label text appears on the second display. Upon click, second display should be closed. It does, but then Vpython crashes.

There is no problem with closing the first display.

I am running on 5.50

Am I missing something?

Kadir

Re: [Visualpython-users] Help with Linux?

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

Another issue:

* Find out how to get a working python-visual package into the regular
Ubuntu update process, so that we don't have to wait for another full
operating system update.

Bruce Sherwood

On Sat, Dec 10, 2011 at 7:57 PM, Bruce Sherwood <Bru...@nc...> wrote:
> If you have significant experience with Linux, please consider helping
> maintain the Linux version of VPython.
>
> It has been some years since a real Linux expert worked with VPython;
> that was Jonathan Brandmeyer. Some expertise is needed, because with
> every new release of Ubuntu, presumably the most popular Linux
> distribution, there's a pretty high probability that something will go
> wrong, as was the case with the function Gdk::GL::get_proc_address
> breaking. Moreover, the Ubuntu package python-visual is typically far
> behind the current version of Visual. The latest version of Ubuntu
> offers a python-visual package that is version 5.12, released in
> August 2009, over two years ago (the current version is 5.72).
>
> I hope very much that one or more Linux VPython users will step
> forward and take responsibility for some aspects of maintaining Visual
> on Linux. Here are the main issues that I see as needing ongoing
> attention:
>
> * Improve the build machinery. Brandmeyer made a very important
> contribution in creating the autoconfigure machinery that made it
> possible to build on diverse Linuxes. However, this machinery is
> showing its age. For example, it doesn't deal with 64-bit machines,
> and it's aimed at site-packages rather than the now-favored
> dist-packages. Moreover, the autoconfigure machinery is quite complex
> and not easy to modify. Probably someone(s) should experiment with
> using distutils instead of autoconfig for building Visual.
>
> * Get involved with the process that leads to a python-visual package
> for Ubuntu. I know nothing about this process, but it's clearly not
> working. It would seem that there is little or no testing of the
> package, and as noted above the package is woefully out of date. The
> Ubuntu/Debian package should be built and tested by users of VPython
> and offered to those who assemble the next version of the Linux
> distribution.
>
> I'm guessing that for someone who knows Linux well, these tasks would
> not be difficult, but they need to be done.
>
> Bruce Sherwood

[Visualpython-users] Help with Linux?

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

If you have significant experience with Linux, please consider helping
maintain the Linux version of VPython.

It has been some years since a real Linux expert worked with VPython;
that was Jonathan Brandmeyer. Some expertise is needed, because with
every new release of Ubuntu, presumably the most popular Linux
distribution, there's a pretty high probability that something will go
wrong, as was the case with the function Gdk::GL::get_proc_address
breaking. Moreover, the Ubuntu package python-visual is typically far
behind the current version of Visual. The latest version of Ubuntu
offers a python-visual package that is version 5.12, released in
August 2009, over two years ago (the current version is 5.72).

I hope very much that one or more Linux VPython users will step
forward and take responsibility for some aspects of maintaining Visual
on Linux. Here are the main issues that I see as needing ongoing
attention:

* Improve the build machinery. Brandmeyer made a very important
contribution in creating the autoconfigure machinery that made it
possible to build on diverse Linuxes. However, this machinery is
showing its age. For example, it doesn't deal with 64-bit machines,
and it's aimed at site-packages rather than the now-favored
dist-packages. Moreover, the autoconfigure machinery is quite complex
and not easy to modify. Probably someone(s) should experiment with
using distutils instead of autoconfig for building Visual.

* Get involved with the process that leads to a python-visual package
for Ubuntu. I know nothing about this process, but it's clearly not
working. It would seem that there is little or no testing of the
package, and as noted above the package is woefully out of date. The
Ubuntu/Debian package should be built and tested by users of VPython
and offered to those who assemble the next version of the Linux
distribution.

I'm guessing that for someone who knows Linux well, these tasks would
not be difficult, but they need to be done.

Bruce Sherwood

[Visualpython-users] Fixed Linux problem

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

On the Linux download page at vpython.org there is a rebuilt source
package for VPython 5.72 which fixes the crashes on Linux (tested on
the latest Ubuntu).

The problem turned out to be that in src/gtk2/display.cpp the function
Gdk::GL::get_proc_address is broken on recent releases of Ubuntu and
Debian (and maybe Fedora) and has been replaced with glXGetProcAddress
which does work.

Bruce Sherwood

P.S. I'll mention that in my many years of work with VPython on three
different platforms, the Windows environment has been remarkably
stable across operating system changes, the Mac environment much less
so (in that until recently things broke when the OS version number
changed in the last decimal place), and Linux also has been somewhat
unstable.

Re: [Visualpython-users] Visual Python /win7 file questions

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

No, unfortunately IDLE (and its variant VIDLE) don't attach .py as the
default. It would seem useful for someone to change IDLE/VIDLE to do
that, but it's not currently something you can set in the
configurations.

Searching the VPython archives and googling I found various schemes
for restoring the behavior that used to be available for starting IDLE
(or VIDLE) by right-clicking a .py file, but I couldn't get any of
these to work. Maybe someone else on this list has found a way. I
agree that it was a very convenient scheme.

Bruce Sherwood

On Thu, Dec 8, 2011 at 9:44 AM, Jim Deane <jim...@gm...> wrote:
> Hello all, sorry to ask what seems like a couple of low level
> questions.  Nevertheless, they are annoying and persistent.  I am
> unable to search any archives other than what I have in my email
> account because my district blocks Sourceforge.
>
> 1.  When saving files from 2.7, they do not automatically save with
> the ".py" extension.  Is there a fix to this?
>
> 2.  When browsing files in windows and trying to open a vpython file
> (.py), it always runs rather than opening for editing.  I have set
> Windows to open with VIdle, but it still runs the file instead of
> opening it for editing.  Do you know of a way to set Windows to
> automatically open .py files for editing in VIdle, rather than running
> them?
>
> Thank you,
>
> Jim Deane
>
> ------------------------------------------------------------------------------
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point of
> discussion for anyone considering optimizing the pricing and packaging model
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

[Visualpython-users] Visual Python /win7 file questions

[Jim D. <jim...@gm...>]

Hello all, sorry to ask what seems like a couple of low level
questions.  Nevertheless, they are annoying and persistent.  I am
unable to search any archives other than what I have in my email
account because my district blocks Sourceforge.

1.  When saving files from 2.7, they do not automatically save with
the ".py" extension.  Is there a fix to this?

2.  When browsing files in windows and trying to open a vpython file
(.py), it always runs rather than opening for editing.  I have set
Windows to open with VIdle, but it still runs the file instead of
opening it for editing.  Do you know of a way to set Windows to
automatically open .py files for editing in VIdle, rather than running
them?

Thank you,

Jim Deane

[Visualpython-users] R: Python-visual in latest Ubuntu

[marco b. <mar...@un...>]

James and Bruce,
our group is using VP in a variety of applications and we
are involved in writing 3D numerical solutions of heat and fluid
transport in porous media. We started using VP as our visualization systems
of choice for both structured and unstructured grids. 

We would be very interested in VP as Python graphics back-end. We found many
valuable features of VP. 

Marco

-----Messaggio originale-----
Da: Aaron Mavrinac [mailto:mav...@gm...] 
Inviato: Tuesday, December 06, 2011 9:19 PM
A: vis...@li...
Oggetto: Re: [Visualpython-users] Python-visual in latest Ubuntu

James/Bruce,

If there is a serious attempt made at migrating Visual onto a pure
Python graphics back-end, I'd definitely be interested in joining that
project. The Python API for Visual is brilliant and the graphics are
fast, but the nature of the current implementation imposes several
limitations (notably, GTK+ event loop issues and some disconnects in
display and object interaction) that might be easier to address -- and
failing that, for users to monkey-patch their way around -- if it were
pure Python. This is, of course, in addition to the aforementioned.

On a related note, there seems to be much demand for a good native 3D
geometry library in pure Python [1]. If the above were to happen, it
might make sense to spin off a separate efficient geometry library at
the same time (something in which I'd be even more interested in
participating).

[1]
http://stackoverflow.com/questions/1076778/good-geometry-library-in-python

-- 
Aaron Mavrinac
www.mavrinac.com

----------------------------------------------------------------------------
--
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of

discussion for anyone considering optimizing the pricing and packaging model

of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________
Visualpython-users mailing list
Vis...@li...
https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Linux workaround

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

Yes, I think you're right. I was going around in circles on the issue
of getting a pointer to the function when, as you say, apparently
that's needed only on Windows. Apparently the VPython code needs to be
refactored slightly to not ask for the pointer if on Linux, since for
some reason that no longer works, needed or not.

Note that the Mac code in Visual is this (and notice the comments):

#include <dlfcn.h>
display::EXTENSION_FUNCTION
display::getProcAddress(const char* name) {
	void *lib = dlopen( (const char *)0L, RTLD_LAZY | RTLD_GLOBAL );
	void *sym = dlsym( lib, name );
	dlclose( lib );
	return (EXTENSION_FUNCTION)sym;
	//return (EXTENSION_FUNCTION)::wglGetProcAddress( name ); // Windows
	//return (EXTENSION_FUNCTION)Gdk::GL::get_proc_address( name ); // GTK2
}

Bruce Sherwood

On Wed, Dec 7, 2011 at 8:23 PM, Kevin Karplus <ka...@so...> wrote:
>
> I retract my previous question.  It seems that Microsoft implemented
> OpenGL in a weird way, so that on Windows systems you need
> wglGetProcAddress and other awkward workarounds.
>
> It looks like all the code that need the addresses is Windows-specific
> and should be isolated to parts of the code only compiled for Windows systems.
>
> (info from further down on the
> http://www.opengl.org/resources/features/OGLextensions/
> page I mentioned in the retracted message.)
>

Re: [Visualpython-users] Linux workaround

[Kevin K. <ka...@so...>]

I retract my previous question.  It seems that Microsoft implemented
OpenGL in a weird way, so that on Windows systems you need
wglGetProcAddress and other awkward workarounds.

It looks like all the code that need the addresses is Windows-specific
and should be isolated to parts of the code only compiled for Windows systems.

(info from further down on the
http://www.opengl.org/resources/features/OGLextensions/ 
page I mentioned in the retracted message.)

Re: [Visualpython-users] Linux workaround

[Kevin K. <ka...@so...>]

Bruce, I'm not sure why you need the address of an extension.

Once you've determined that an extension is available, can't you just
call its functions?

That's what the examples at
	http://www.opengl.org/resources/features/OGLextensions/ 
imply anyway.

What are you trying to accomplish that needs the address of an extension?

Kevin Karplus

Re: [Visualpython-users] Linux workaround

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

Yes, I too have my eye on that library, but I'm missing something.
It's true that I need to be able to determine whether an extension is
available, but I'm having trouble finding out how to get the address
of the extension, which is what the (failing) get_proc_address is
supposed to do.

Bruce Sherwood

On Wed, Dec 7, 2011 at 5:44 PM, Kevin Karplus <ka...@so...> wrote:
>
> I'm not an OpenGL user, but it looks like the OpenGL Extension
>  Wrangler at
>         http://glew.sourceforge.net/
> may be what you need
>
>    The OpenGL Extension Wrangler Library (GLEW) is a cross-platform
>    open-source C/C++ extension loading library. GLEW provides
>    efficient run-time mechanisms for determining which OpenGL
>    extensions are supported on the target platform. OpenGL core and
>    extension functionality is exposed in a single header file. GLEW
>    has been tested on a variety of operating systems, including
>    Windows, Linux, Mac OS X, FreeBSD, Irix, and Solaris.

Re: [Visualpython-users] Linux workaround

[Kevin K. <ka...@so...>]

I'm not an OpenGL user, but it looks like the OpenGL Extension
 Wrangler at
	 http://glew.sourceforge.net/ 
may be what you need

    The OpenGL Extension Wrangler Library (GLEW) is a cross-platform
    open-source C/C++ extension loading library. GLEW provides
    efficient run-time mechanisms for determining which OpenGL
    extensions are supported on the target platform. OpenGL core and
    extension functionality is exposed in a single header file. GLEW
    has been tested on a variety of operating systems, including
    Windows, Linux, Mac OS X, FreeBSD, Irix, and Solaris.

Re: [Visualpython-users] Linux workaround

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

Where I got to today is finding that the real problem is in
src/gtk2/display.cpp:

display::EXTENSION_FUNCTION
display::getProcAddress(const char* name) {
	return (EXTENSION_FUNCTION)Gdk::GL::get_proc_address( name );
}

Calling Gdk::GL::get_proc_address( name ) crashes the program. The
purpose of this routine is to obtain information about extensions to
OpenGL. The "hack" mentioned earlier (see below) isn't the actual
problem; the problem is that the get_proc_address() function which
worked on earlier Ubuntu/Debian systems doesn't work now (and I guess
maybe it doesn't work on Fedora, either).

I have the impression that VPython as is works for Linux users with
low-end graphics cards, probably because there are no relevant
extensions asked for.

At the moment, I can only recommend the workaround described below. It
would seem necessary to find a different way to look up extensions,
one that doesn't use the get_proc_address() function. I welcome
suggestions from those of you who are knowledgeable about OpenGL.

Bruce Sherwood

On Tue, Dec 6, 2011 at 5:28 PM, Bruce Sherwood <Bru...@nc...> wrote:
> Now that I was able to work on the Linux crashes, I immediately found
> that the crash occurs on the following statement in the realize
> routine in src/core/display_kernel.cpp:
>
> // The test is a hack so that subclasses not bothering to implement
> getProcAddress just
>                //   don't get any extensions.
>                if (getProcAddress("display_kernel::getProcAddress") != notImplemented)
>                        glext.init( *this );
>
> If this statement is commented out, VPython runs on the latest Ubuntu,
> but there are no materials. I'll look deeper into this, but if you're
> capable of building from source you can have a working VPython just by
> compiling without the offending statement. The comment "The test is a
> hack" suggests something that might well go bad with a system change,
> though this hasn't been a problem on Windows or Mac.
>
> Bruce Sherwood

[Visualpython-users] Linux workaround

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

Now that I was able to work on the Linux crashes, I immediately found
that the crash occurs on the following statement in the realize
routine in src/core/display_kernel.cpp:

// The test is a hack so that subclasses not bothering to implement
getProcAddress just
		//   don't get any extensions.
		if (getProcAddress("display_kernel::getProcAddress") != notImplemented)
			glext.init( *this );

If this statement is commented out, VPython runs on the latest Ubuntu,
but there are no materials. I'll look deeper into this, but if you're
capable of building from source you can have a working VPython just by
compiling without the offending statement. The comment "The test is a
hack" suggests something that might well go bad with a system change,
though this hasn't been a problem on Windows or Mac.

Bruce Sherwood

Re: [Visualpython-users] Python-visual in latest Ubuntu

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

If some people do get serious about redoing VPython, here's something
to keep in mind. I believe that one of the reasons why very few people
have made substantive contributions to VPython development is that it
involves multithreaded C++ and must work on all platforms, all of
which requires uncommon expertise (and some fearlessness). Compare
with the GlowScript project (JavaScript + WebGL instead of Python +
OpenGL; see glowscript.org).

Basically, JavaScript doesn't have threads (ignore the special and
strictly limited "worker" thread for purposes of this discussion). If
you write an infinite loop in JavaScript, nothing can break into that
loop, and your web page is hung forever. In VPython the render thread
interrupts your Python calculations, and there are complex issues
associated with having more than one thread.

In GlowScript, this strategy is literally impossible to implement.
Rather, your program MUST be organized into chunks that are called at
times you specify. GlowScript uses the Streamline library to chop up
your VPython-like program into such chunks; for example, a rate(50)
statement in a loop causes GlowScript/Streamline to compile the loop
contents into a separate routine that is driven 50 times a second. One
of the timer-driven chunks is the render routine, which runs about 30
times a second, similar to VPython, but it's not a thread, it's just
one of the many timer-driven short routines.

One consequence is that in GlowScript, if you execute a lengthy piece
of code to set up a complex 3D scene, you know that the scene will be
completely defined and appear all at once when you execute that code
and the render routine gets a chance to run (the render routine may
have been delayed for much more than 1/30 second but will run
immediately when other activity has ceased). In contrast, in VPython
the render thread will break into your scene creation and display a
partial, incomplete scene unless you make the scene invisible until
you're finished with creating the scene.

Even though the Python environment permits threading, it's worth
considering a GlowScript-like strategy, simply to avoid the
complexities of multithreading and thereby reduce the barriers to
people making contributions to the core code.

An important issue to bear in mind is that one would like the look and
feel to be native on all platforms, but I repeat that there's a
serious problem on the Mac, in that we didn't find a way to base
VPython on Cocoa due to threading issues, and Carbon is deprecated and
doesn't run with 64-bit programs. If the threading issues go away,
maybe the Mac issue could also go away.

Another thing to keep in mind is that in 2000 few people had graphics
cards with powerful GPUs, whereas a new "VPython" presumably should
require such cards and be built from the start to exploit them.

I agree with Aaron that the most important feature of VPython is its
API, not the particular implementation. If some of you see a better
way to implement that API, go for it! And if you do go for it, do pay
attention to GlowScript development, whose API is very similar to but
not identical to VPython, and I think the (relatively minor) changes
are good ones.

I would be very willing to help anyone interested in rebuilding
VPython by providing explanations of the existing code, though I
confess that there are some aspects that I don't fully understand. On
the other hand, the current code may be mostly irrelevant; it's the
API that defines what needs to be done.

Bruce Sherwood

On Tue, Dec 6, 2011 at 1:19 PM, Aaron Mavrinac <mav...@gm...> wrote:
> James/Bruce,
>
> If there is a serious attempt made at migrating Visual onto a pure
> Python graphics back-end, I'd definitely be interested in joining that
> project. The Python API for Visual is brilliant and the graphics are
> fast, but the nature of the current implementation imposes several
> limitations (notably, GTK+ event loop issues and some disconnects in
> display and object interaction) that might be easier to address -- and
> failing that, for users to monkey-patch their way around -- if it were
> pure Python. This is, of course, in addition to the aforementioned.
>
> On a related note, there seems to be much demand for a good native 3D
> geometry library in pure Python [1]. If the above were to happen, it
> might make sense to spin off a separate efficient geometry library at
> the same time (something in which I'd be even more interested in
> participating).
>
> [1] http://stackoverflow.com/questions/1076778/good-geometry-library-in-python
>
> --
> Aaron Mavrinac
> www.mavrinac.com

Re: [Visualpython-users] Python-visual in latest Ubuntu

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

James/Bruce,

If there is a serious attempt made at migrating Visual onto a pure
Python graphics back-end, I'd definitely be interested in joining that
project. The Python API for Visual is brilliant and the graphics are
fast, but the nature of the current implementation imposes several
limitations (notably, GTK+ event loop issues and some disconnects in
display and object interaction) that might be easier to address -- and
failing that, for users to monkey-patch their way around -- if it were
pure Python. This is, of course, in addition to the aforementioned.

On a related note, there seems to be much demand for a good native 3D
geometry library in pure Python [1]. If the above were to happen, it
might make sense to spin off a separate efficient geometry library at
the same time (something in which I'd be even more interested in
participating).

[1] http://stackoverflow.com/questions/1076778/good-geometry-library-in-python

-- 
Aaron Mavrinac
www.mavrinac.com

Re: [Visualpython-users] Python-visual in latest Ubuntu

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

Thanks for the report. It's helpful to know that you see the problem
with an ATI card, in addition to the reports concerning computers with
NVIDIA cards. So that pretty much rules out the graphic driver being
the problem. I've come to a pause in other high-priority work and will
make a serious attempt at debugging this.

I'll mention that when David Scherer first created VPython in the
spring of 2000, he first tried implementing it in pure Python but had
to give up because the performance was quite poor. However, maybe
there are now better tools and platforms in the Python world, and if
you can get this to work in a pure Python environment that would be
great.

A parallel is that the new GlowScript environment Scherer and I are
developing (glowscript.org), with an API similar to VPython but which
runs in a browser, is implemented in pure JavaScript, which is
feasible because JavaScript is compiled rather than interpreted.

Bruce Sherwood

On Tue, Dec 6, 2011 at 9:59 AM, James Thomas <jt...@mi...> wrote:
> Another data point.  I'm running LMDE (debian testing) 64-bit and I get the
> segfault error with the ATI proprietary driver.  libgtkglextmm-x11-1.2-dev
> was not installed but installing it made no difference.  Playing around with
> site_settings.py made no difference.  Purge-reinstall made no difference.
>
> Seems like this is a perpetual problem I keep running into every time I come
> back to visual after an extended break or on a new system.  Now I'm
> regretting not making good on my intention 2 years ago to re-implement
> vPython in Python (like it should be) two years ago.  I have a library and a
> lot of simulation code that is unusable because I can't get visual to run.
>
> My last hope is to bypass the repositories and hope that a newer version or
> building from sources will fix this.  Otherwise I'm fairly well screwed.
>
> JT
>
>
>
>
> ------------------------------------------------------------------------------
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point of
> discussion for anyone considering optimizing the pricing and packaging model
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>