visualpython-users

[Visualpython-users] OFSET/ Freeduc - distribution of VPython?

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

For those who have the patience, I enclose below a rather lengthy 
exchange with George Khaznadar, one of the key folks at OFSET

Organization for Free Software in Education and Teaching

http://www.ofset.org

Among other things, they distribute Freduc - what I think is an 
outstanding "run from CD" Debian based Linux distro chock full of 
educational related software.  The focus is K-12, I would say.

The main point of all this is the last question from George. He is 
asking about whether VPython/visual might be named python-visual for the 
purposes of Debian based distros, presumedly so that it identifies 
itself as a python related project, in comformity with what he seems to 
perceive as accepted naming conventions for this kind of project.  He 
seems to me  quite knowledgeable about these kinds of issues, so I am 
assuming his perception has a good basis. But of course I have no way to 
respond to him.

Bruce?

Anyone?

Also wouldn't mind some direction on the man pages issue he requested. 
Again, I tried to make it clear I was a user and a fan, not a 
decisionmaker, with respect to VPython, but it doesn't seem to have 
registered.  Will there be something in the way of official manpages to 
send along?

Bruce?

Anyone?

I do think it quite worthwhile to try to cooperate with helping them 
feel fully comfortable and "in compliance" in distributing Python/visual 
as part of Freeduc.

Art


 > Now having become as excited as I have about the Freeduc distro, I will
 > begin my lobbying campaign for inclusion on some of my favorite apps,
 > starting with VPython:
 >
 > www.vpython.org
 > VPython
 > 3D Programming for Ordinary Mortals
 >
 > It is being actively used in physics education at the University level,
 > which I understand is not the Freeduc target audience.  But I am
 > convinced it could also serve as an enticing and satsifying and fun
 > education tool at the K-12 level.
 >
 > I feel particularly free to promote it in that I have nothing to do with
 > its development.  But would be willing to write some demos, and a
 > tutorial more appropriate to the Freeduc audience were it to be
 > considered for inclusion in the distribution.
 >
 > How are these decisions made, and what should one do beyond babbling on
 > this list if one feels strongly about the inclusion of a particular
 > resource.
 >
 > Art


Response by Georges Khaznadar, of OFSET

 > Very interesting indeed.
 > It yelds a debian package with no problem (based on a debian sarge
 > distribution). Package size : 588738 bytes, installed size : 2253 kbytes.
 >
 > There has been a e-mail thread about an ITP (intent to package), later
 > requalified as an RTP (request to package) inside the debian bug
 > tracking system :
 > http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=112118
 >
 > So it appears that your software has not yet been packaged for a debian
 > system.
 >
 > Please can you author a short manpage for visual ? the sections may be
 > NAME, SYNOPSIS, DESCRIPTION, AUTHOR, INTERNET RESOURCES, LICENSING
 > and each of them can be very short or pasted from your existing
 > documentation. Don't worry with the groff syntax, just release it like
 > plain text, I'll put it straight. Of course you can refer to your
 > already written html documentation.
 >
 > I would be obliged if you could give me some hints about the
 > building dependencies of your package. It seems to depend from at least
 > gtkglarea5-dev, python2.2-dev. Have you noticed other dependances at
 > build-time ?
 >
 > The licensing has already been estimated as DFSG-compliant, which means
 > that your software can be part of the debian projets (i.e. a debian/free
 > package).
 >
 > Best regards,			Georges.
 >

My (edited) response

 > As to dependencies, the only additional dependency not on your list is
 > Numerical Python
 >
 > http://pfdubois.com/numpy/
 >
 > """Numerical Python adds a fast, compact, multidimensional array
 > language facility to Python."""
 >
 > Numerical Python was developed as Lawrence Livermore National Laboratory.
 >
 > It is quite mature as an open source project, well documented, nice
 > tutorial.  Much of what I now understand about matrix algebra was
 > learned "playing" with Numerica Python.
 >
 > IMO, a nice addition to Freeduc, in and of itself.
 >
 > It is going to be superceded at some point by an "improved" but largely
 > compatible library being called NumArray.
 >
 > A further note on dependencies is the fact the it appears that gtkglarea
 > is no longer being supported and is being superceded by a new library.
 >  There are plans and committed resources to adapt VPython to NumArray
 > and to the newer gl context for gtk, as the libraries phase-in as the
 > standards.
 >
 > There has also been a close association between the development of
 > VPython and that of IDLE.
 >
 > IDLE is the simple IDE for Python which has been a pet project of Guido
 > Von Rossum, the creator of Python.
 >
 > Python itself  - for those who do not know the history - grew out of the
 > ABC language, which was originally developed with young learning
 > programmers in mind.  Guido has a keen interest in the use of Python for
 > educational purposes, and IDLE was developed in large part out of that
 > interest.
 >
 > The story gets a little complicated from there, as there have been 2
 > versions of IDLE, the stable and the experimental fork. VPython was
 > dependent, for technical reasons, on the experimtental fork version. As
 > of Python2.3, just released, the two versions are integrated back as one
 > "official" version, so that potential additional complication is now 
gone.
 >
 >

At which point George asks,

 >Would you agree for renaming the debian package to python-visual ? It
 >makes it more visible when browsing python resources available in a
 >machine.

Perhaps a bit of a language barrier because I had made it clear that 
VPython/visual was not my project. And that the fact that I was not 
*the* or even *a* developer was one of the reasons I was comfortable 
promoting it so baldly.

On the other hand I have been upfront about my own agenda - that I would 
also like to see PyGeo in the distribution, when it is ready, which it 
isn't quite, in any case.


Art

Re: [Visualpython-users] OFSET/ Freeduc - distribution of VPython?

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

On Sun, 2003-06-08 at 15:29, Arthur wrote:
> For those who have the patience, I enclose below a rather lengthy 
> exchange with George Khaznadar, one of the key folks at OFSET
> 
> Organization for Free Software in Education and Teaching
> 
> http://www.ofset.org

> Response by Georges Khaznadar, of OFSET

What was his address?  I trust that you will forward this to Mr.
Khaznadar, but it would be easier if all parties could e-mail each other
directly.

>  > Please can you author a short manpage for visual ? the sections may be
>  > NAME, SYNOPSIS, DESCRIPTION, AUTHOR, INTERNET RESOURCES, LICENSING
>  > and each of them can be very short or pasted from your existing
>  > documentation. Don't worry with the groff syntax, just release it like
>  > plain text, I'll put it straight. Of course you can refer to your
>  > already written html documentation.

A man page for a library?  Perhaps for idle_VPython, but not for the
core visual module.  Ever run "man gtk+"?  I think that placing the
documentation under /usr/share/doc/python-visual, with the appropriate
pointers for dhelp would be best for the library docs.  Best in the
sence that it fits in with the Debian Policy.

However, if you do this, make sure that idle's help menu is updated to
point to the right place such that when a user presses F1 or selects the
menu item that the system webbrowser is pointed in the right place.

>  > I would be obliged if you could give me some hints about the
>  > building dependencies of your package. It seems to depend from at least
>  > gtkglarea5-dev, python2.2-dev. Have you noticed other dependances at
>  > build-time ?

Simply having gtkglarea5-dev isn't always enough.  Some form of OpenGL
support under gtkglarea is required.  gtkglarea5 depends on some OpenGL
back-end, but at least one person has complained before to us that their
GL support was busted in spite of this dependancy.

>  > As to dependencies, the only additional dependency not on your list is
>  > Numerical Python

Quite right.  In fact, if its not found, configure will bomb out with a
(hopefully useful) error message.  VPython Depends on python-numeric.

>  >Would you agree for renaming the debian package to python-visual ? It
>  >makes it more visible when browsing python resources available in a
>  >machine.

And follows Debian's standards for python package names.

That would be fine for a downstream distribution package name.  We don't
really plan to change the name here, and the debian documentation should
be more than adequate to point users in the right direction to complain
about/give thanks for this software.

Other notes:
You mentioned that the idle/idlefork issue will be moot since the "main"
fork of idle should be merged into Python 2.3.  Don't count your
chickens until they hatch.  That is the plan, but there remain some
severe bugs to work out first.  Taking the worst case (idlefork doesn't
make it), make sure that Idle for VPython doesn't conflict with the main
Idle.  We prevent this by keeping idle_VPython under the site-packages
directory, and installing a shell script named "vpython" in the PATH
that runs our version of idle.

Of course, I would love to see the new idlefork make it.  That last bit
was "just in case".

HTH,
-Jonathan

Re: [Visualpython-users] OFSET/ Freeduc - distribution of VPython?

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

Good news on the idlefork front: The latest release of idlefork is in 
very good shape. Kurt Kaiser managed to fix the serious bugs. He has 
also fixed in CVS some minor problems that showed up in the beta 
release. I've used the new idlefork extensively, and I encourage people 
to try it by downloading the installer available at

	http://sourceforge.net/projects/idlefork

I think it is very likely that this WILL replace the old IDLE in the 
final release of Python 2.3, especially because Guido has been keeping a 
close watch on it and even contributed a recent patch himself. If it 
does become the standard distributed IDLE, starting with Python 2.3 we 
will retire Idle_VPython, and it will no longer be a part of the VPython 
package.

The new idlefork has all of the features and capabilities of 
Idle_VPython plus many excellent new features. The most obvious 
difference you'll see is that there is only one output window, no matter 
how many program files you have open, and this output window is actually 
the Python shell, so you can investigate the present values of variables 
in your program, etc. There is an excellent facility for configuring the 
editor (change font size etc.), and changes take effect immediately. You 
can specify Windows keyboard shortcuts on a Linux or Mac machine (or 
Linux shortcuts on Windows or Mac, etc.). This is a great convenience if 
you do most of your work on one platform but occasionally run on a 
different platform.

The default behavior in some respects is not the same as Idle_VPython. 
If you want the same behavior as Idle_VPython, you need to go to 
Configure IDLE on the Options menu, choose the General tab, and set At 
Startup to "Open Edit Window" (default is to open a Python shell), and 
set At Start of Run (F5) to "No Prompt" (the default is to ask you 
whether to save each time you run, unless you remember to save before 
running).

Bruce Sherwood

Jonathan Brandmeyer wrote:

> Other notes:
> You mentioned that the idle/idlefork issue will be moot since the "main"
> fork of idle should be merged into Python 2.3.  Don't count your
> chickens until they hatch.  That is the plan, but there remain some
> severe bugs to work out first.  Taking the worst case (idlefork doesn't
> make it), make sure that Idle for VPython doesn't conflict with the main
> Idle.  We prevent this by keeping idle_VPython under the site-packages
> directory, and installing a shell script named "vpython" in the PATH
> that runs our version of idle.
> 
> Of course, I would love to see the new idlefork make it.  That last bit
> was "just in case".