visualpython-users

Re: [Visualpython-users] Installer issues

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

I had the vague notion that ScITE is Windows-specific -- right or wrong?

Highlighting Visual keywords might be nice, but it is really the high
interactivity of idlefork that matters to me. Anything that offers one-key
edit/run cycles is what I want, and what I want for my students. Is that
possible with ScITE?

Bruce Sherwood

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Bruce Sherwood" <bas...@un...>;
<vis...@li...>
Sent: Tuesday, February 18, 2003 8:44 PM
Subject: Re: [Visualpython-users] Installer issues


> > Small technical note: There isn't any real "marriage" of Visual and
> > idlefork; anyone can obviously edit Visual programs with any editor
> > whatsoever. But there has to be at least one way to do it in a bundled
> > distribution, and idlefork has served the purpose well.
>
> I might be getting ahead of myself.  But even the new IDLE is only syntax
> aware as to Python. Is it easy enough to, for example, add syntax
> highlighting of VPython keywords?
>
> I do know that with something like SciTE, with a little futzing that even
> someone of my modest C++ skills is capable of, you can have an editor
aware
> of Python *and* VPython keywords - with the potential of acutally going
> quite a bit further than that in customizing it as a VPython environment.
>
> BTW, the creator of ScITE is also the author of scintilla, SciTE's
> underlying C++ library. Scintilla is widley used in the non-Python world,
> but is also used as an underlying library for PythonWin and the wxPython
> editor text widget.  And though it is C++,  its creator considers Python
his
> favorite programming langauge, and he in fact uses Python as a
configration
> tool for customizations.  So its all in the family.  And probably why
> someone like myself is comforatable with it's customization features.
>
> Just a thought really.  Its the conclusion I have reached as to what works
> best as to PyGeo, in any case.
>
> Art
>
>
>

Re: [Visualpython-users] History and Status?

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

> Any idea why distutils isn't an answer to these problems? Is it the
> dependencies in a source distribution on whether other libraries are
> present? I read Jansen's note and it doesn't mention distutils at all.

Not I.

Maybe Joe?

Art

Re: [Visualpython-users] History and Status?

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

> Consider for the moment the case of a complete turnkey bundle for
newcomers
> (ideally, a single installer for Python, Numeric, Visual and its docs and
> demos, idlefork until it gets into the regular Python distribution, and
less
> ideally two or three installers). A rather important piece of this is
> something that I don't see how to do with distutils, which is to provide a
> desktop shortcut (alias) to the editing environment (idlefork). This
> shortcut is created by the current VPython installer on Windows, which
also
> puts an entry on the Python section of the Start menu.

> Any ideas on how to address that in the distutils scheme of things?

distulis has the ability to trigger a post-install script, which can do
that.  I've seen it done in at least one distribution and we can pigeon - I
mean learn from ;) - that  distribution  precisely how it is achieved.
>
> A related question is whether there is a way in distutils to refer
> symbolically to the directory where Python is found (normally C:\PythonXX,
> but a user can install it anywhere). That would be a piece of constructing
a
> shortcut (alias). I even tried including a shortcut that could be dragged
> from site-packages\visual onto the desktop, but alas a shortcut must have
> absolute file references.

Not sure what you are asking here.  The installer does not assume any
particular location for Python.  I am not sure whether it searches the
directory tree, or refers to the windows registy entry - but it finds the
installation, and does not assume it is an any particular place.  But I am
not sure that addresses your question.

> It isn't absolutely necessary to find a distutils solution to this,
because
> there is really only one situation where this comes up, a novice-oriented
> bundled binary installer for Windows, and I can continue building such a
> thing using other tools, letting distutils handle all other situations
> (presumably in source form). I would however change the installation
> locations to those that Arthur and others have championed -- everything in
> site-packages\visual (visual, docs, demos, idlefork).
>
> Incidentally, I very hastily tried using the distutils installer on Mac
OSX
> in the X11 framework and was told, "gcc: cannot specify -o with -c or -S
and
> multiple compilations". I'm guessing this has to do with the
> "extra_compile_args" at the start of setup.py, which look like they're set
> for Windows?

The extra_compile_args are definitely Windows specific. Just so that people
understand, I'm clueless what they mean.  I simply mechanically followed
what was being done in the VC project files included with the source distro.

Or else it was I who actually wrote VC6.

I forget which. ;)

Art

Re: [Visualpython-users] History and Status?

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

On Tue, 2003-02-18 at 16:34, Arthur wrote:
> It terms of concrete effort, I will be pursuing the extension to the
> setup.py for VPython I did, so that it will be workable with Linux. Other
> than my own learning curve to refamiliarize myself with certain Linux
> issues, should not be a big deal.  As Bruce notes, the actual Linux setup.py
> is essentially  already there - its really just a matter of testing for
> platform and branching appropriately.
> 
> Should be able to get it to be basically functional, with the place of docs,
> demso somewhere - as a draft - pending more discussion.
> 
> But the iterator thingy (technical term) issue is on my mind.
> 
> I am working with a recent Linux install, therefore gcc3.xx.
> 
> Am I correct in assuming that the fix to the CXX file needed to compile on
> gcc > 3 does not break anything if compiling under a gcc < 3.  Which would
> raise the question why it was there at all.  There is probably a way to test
> for gcc version and fork accordingly, but I don't know if its necessary.

Unfortunately, No.  Most GCC < 3 are broken by the current setup. 
Namely the stock versions distributed with RH7 and Debian woody (at the
minimum).  It's not as simple as testing for __GNUC__ < 3, because at
least one of the 2.95 builds supported only the ISO version, and would
subsequently fail.  Most G++ 3.x distributions' verson of libstdc++
support both the old random_access_iterator<> and newer iterator<>.  The
problem is that Apple distributes their G++ with a C++ standard library
that is not backwards compatable in this respect.

In the Great ISO Migration, some older distributions are only partially
in compliance.  Most current distributions are fully compliant or nearly
so, and are also backwards-compatable (stock g++3.2.x with corrisponding
libstdc++).  A handful of current distributions are fully or nearly
fully ISO compliant and are NOT backwards compatable (Apple special
distro).  Ironically, the last group is the one causing causing us the
trouble.

Is it possible to run a shell command from within setup.py, and capture
the return value to set a CXXFLAG?  If so, then a solution could look
like this:

Provide a file named iterator_traits_test.cpp:
--------iterator_traits_test.cpp--------------
#include <iterator>

std::iterator< std::random_access_iterator_tag, int, int> test;

----------------------------------------------
From within setup.py, shell execute
g++ -c iterator_traits_test.cpp
If it returns 0, add -DSTL_HAS_ITERATOR_TRAITS to CXXFLAGS.

This would work in conjunction with removing the default definition in
CXX_Config.h, and changing the conditional within that file to #ifdef
vice #if.  It would also virtually require using setup.py to build. 
Everything is a trade-off.

OTOH, if what I described is possible for the iterator thing, than it
could be used to capture all of our platform differences with only one
setup.py.

-Jonathan

Re: [Visualpython-users] Installer issues

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

Sounds like we are in fierce agreement!

Small technical note: There isn't any real "marriage" of Visual and
idlefork; anyone can obviously edit Visual programs with any editor
whatsoever. But there has to be at least one way to do it in a bundled
distribution, and idlefork has served the purpose well.

Bruce Sherwood

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Matthew Kohlmyer" <mak...@un...>;
<vis...@li...>
Sent: Tuesday, February 18, 2003 12:42 PM
Subject: Re: [Visualpython-users] Installer issues


> > for those who have never used Python, and one for Python experts.
> > Ideally, (though Bruce has pointed out the practical difficulties of
> > doing this) the novice installation package should contain everything
> > needed to get started (Python, VPython, Numarray, etc.).
>
> Again - I am not as far off from that thinking as might be surmised.  I
> would like to get PyGeo in the hands as many folks as possible - its quite
> cool, IMO - and do not want to limit the audience to geeks of any stripe.
> So an all-in-one environment - that includes Python itself - is an
> alternative that interests me as well.  The additional upside, if its
> configured not to interfere with anything that might already exist on
> anyone's machine, is that there would be alot of freedom to do things like
> configure a IDE and help files specific to VPython.  I already have, for
> example, a working compilation of a nice open source editor - ScITE -
> configured for the syntax hightlighting of PyGeo keywords.  Easy enough to
> do that for VPython.  (Frankly I think that VPython should unmarry itself
> from IDLE.  There are a lot of alternatives, free and open source, that
> might be explored.)
>
> But I also agree with Bruce that a line needs to be drawn as to what
> platforms will be supported.  The all-in-one distribution, for example,
> might sensibly have more limited platform support than the distutils based
> distribution, for example.
>
> For my purposes Windows would be the target of the all-in-one distro.  I
do
> understand the importance of Apple in the educational community - but
don't
> know enough about it to comment about what is appropriate there.  Other
than
> understanding that Linux compatibility is being achieved.
>
> But an effort at an all-in-one Linux distribution seems to me a bad idea.
> Though it is probably achievable in some reasonable way if limited to
let's
> say a version or two of Redhat and compatables, and done via rpm.
>
> And again, I certainly think there should be a good distribution for those
> "in the loop" as to geeky kinds of things.
>
>  There is no reason those folks will not appreciate VPython, and are the
> ones likely to help create a community capable of sustaining and extending
> it.
>
> Some of the recent demos posted up to VPython gives a good idea of the
kinds
> of things it is capable of in experienced hands.
>
> Art

Re: [Visualpython-users] History and Status?

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

Any idea why distutils isn't an answer to these problems? Is it the
dependencies in a source distribution on whether other libraries are
present? I read Jansen's note and it doesn't mention distutils at all.

Bruce Sherwood

----- Original Message -----
From: "Arthur" <ajs...@op...>
>
> There is something hot off the press on Mac package installation issues:
> http://mail.python.org/pipermail/catalog-sig/2003-February/000337.html
>
> Jack Jansen is the main guy maintaining the Python for Mac distribution.
The
> Python community loves controversy. I only know about this because of a
> thread trying to talk Jack out of the naming he has decided upon for his
> Package Install Manager for Python: pimp. :)
>
> The Mac issues are  mostly however Greek to me - but pimp certainly sounds
> like something that should be explored as the possible solution to VPython
> Mac distribution issues.
>
> Art

Re: [Visualpython-users] History and Status?

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

I enjoyed working/playing today with the distutils package Arthur so
helpfully provided. This was on Windows, making and testing binary
installers, with and without IDLE, etc. Very nice, very convenient. Even
does a perfect job of cleaning up on an uninstall from the "Add/remove
program" control panel.

Consider for the moment the case of a complete turnkey bundle for newcomers
(ideally, a single installer for Python, Numeric, Visual and its docs and
demos, idlefork until it gets into the regular Python distribution, and less
ideally two or three installers). A rather important piece of this is
something that I don't see how to do with distutils, which is to provide a
desktop shortcut (alias) to the editing environment (idlefork). This
shortcut is created by the current VPython installer on Windows, which also
puts an entry on the Python section of the Start menu.

Any ideas on how to address that in the distutils scheme of things?

A related question is whether there is a way in distutils to refer
symbolically to the directory where Python is found (normally C:\PythonXX,
but a user can install it anywhere). That would be a piece of constructing a
shortcut (alias). I even tried including a shortcut that could be dragged
from site-packages\visual onto the desktop, but alas a shortcut must have
absolute file references.

It isn't absolutely necessary to find a distutils solution to this, because
there is really only one situation where this comes up, a novice-oriented
bundled binary installer for Windows, and I can continue building such a
thing using other tools, letting distutils handle all other situations
(presumably in source form). I would however change the installation
locations to those that Arthur and others have championed -- everything in
site-packages\visual (visual, docs, demos, idlefork).

Incidentally, I very hastily tried using the distutils installer on Mac OSX
in the X11 framework and was told, "gcc: cannot specify -o with -c or -S and
multiple compilations". I'm guessing this has to do with the
"extra_compile_args" at the start of setup.py, which look like they're set
for Windows?

Bruce Sherwood

[Visualpython-users] Re: Limitations Re: transparency, no-shadow objects, r --> infinity

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

As far as I know there is no solution curently to the question posed. I
should point out though that you can always turn off userspin and/or
userzoom and handle mouse navigation yourself. For an example, see the demo
program stonehenge.py.

The deliberate setting of RGB values to be greater than one is a kludge --
it just happens to sort of do what was wanted, but not by design!

Bruce Sherwood

----- Original Message -----
From: "John Keck" <joh...@ho...>
To: <bas...@un...>; <vis...@li...>
Sent: Tuesday, February 18, 2003 5:20 PM
Subject: Limitations Re: transparency, no-shadow objects, r --> infinity


> <<Concerning a backdrop a long ways away, the only thing you can do is put
> very large objects a very long ways away. Just like in real life!>>
>
> The problem with this solution is that the viewer is necessarily
> "Cartesian," i.e., disembodied, and as long as zooming is enabled (which I
> think necessary for the rest of the demo), he can always zoom "outside" of
> infinity, as it were-- a behavior I was hoping to avoid.
>
> Is there no other solution?
>
> <<It's based on a note from Dave Scherer a while back that if you
> deliberately set a color to have components greater than 1, you happen to
> get a behavior rather like what you want.>>
>
> The limitation being that one of the RGB color components of the color
> expressed will have a value of one.  (Is this the same as full saturation
in
> HSV?)
>
> I've heard that at Walmart, they don't have problems, but "opportunities."
> Maybe you could consider these limitations of the present VPython as
> opportunities for improving the next version.  The package is great and
has
> unlimited potential.
>
> John
>
> _________________________________________________________________
> The new MSN 8: advanced junk mail protection and 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
>
>

Re: [Visualpython-users] Re: compiling vpython with gcc 3.2 (linux)

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

> In short, a standard Woody system system probably needs
> std::random_access_iterator, while a newer system needs std::iterator.
> 
> > Iterator traits' availability has been tested with gcc-3.0.4, 3.2.1, and
> > MSVC6.  Indirect reports show that iterator traits are available under
> > CodeWarrier7, and gcc-2.95 (Apple special).
> 
> They are a function of compiler version + library version, not just
> compiler version alone.  Fortunately for the end user, a good dependency
> system, such as Debian's, tends to hide such details, but it does make it
> harder for the developer to pin things down.

My exposure to the STL has mostly included libstdc++, whose releases
have been coupled to g++, but I understand the difference.  This
particualar feature required support from the compiler for partial
template specialization.  In each of the cases that I mentioned, I was
referring to the compiler + library combination that was shipped from
the compiler vendor.

> > > I think a better "fix" would be to leave the comment and #define in
> > > CXX_Config.h, but change the default value of the
> > > STANDARD_LIBRARY_ITERATOR_TRAITS #define to match the current standard.
> > > 
> > > Specifically, I had in mind something like this:
> > > 
> > > diff -r -u VPython/cvisual/CXX/Include/CXX_Config.h VPython-andy/cvisual/CXX/Include/CXX_Config.h
> > > --- VPython/cvisual/CXX/Include/CXX_Config.h	Mon Jul 22 16:03:01 2002
> > > +++ VPython-andy/cvisual/CXX/Include/CXX_Config.h	Thu Feb 13 15:52:02 2003
> > > @@ -2,7 +2,7 @@
> > >  #define __py_config_hh__
> > >  // Macros to deal with deficiencies in compilers
> > >  #define COMPILER_SUPPORTS_NAMESPACES 1
> > > -#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 1
> > > +#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 0
> 
> 
> > Backwards.  STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 1 is the ISO-compliant
> > answer.  Otherwise, the header will cause inheritance from
> > std::random_access_iterator. 
> 
> No, I had it right.  Quoting from the 2002-07-22 VPython distribution,
> cvisual/CXX/Include/CXX_Config.h (wrapping long lines for clarity):

I apologize, see below.

> #if STANDARD_LIBRARY_HAS_ITERATOR_TRAITS
> #  define random_access_iterator_parent(itemtype) \
> 	STD::random_access_iterator<itemtype, int>
> #else
> #  define random_access_iterator_parent(itemtype) \
> 	STD::iterator<STD::random_access_iterator_tag,itemtype,int>
> #endif
> 
> I'd agree with you that the name, in retrospect, probably seems backwards
> and is easily confusing, but my suggested patch did exactly what I wanted
> it to do, namely change the default value of the
> STANDARD_LIBRARY_ITERATOR_TRAITS #define to match the current standard.
> I also changed the error message in cvisual/CXX/README.htm to match that
> new default value.

The name was exactly backwards and was confusing.  When I put the flag
back in, I named it STL_HAS_ITERATOR_TRAITS, and implemented it with the
right meaning.

> In short, my patch will cause compilation to fail on a standard Debian
> "Woody" system without g++-3.0 (and also on RedHat 7.0), but it should
> also allow compilation to succeed without this particular problem on newer
> standard-conforming systems.  The failure message in the patched
> README.htm advises users how to work around the compilation failure.

Yes, exactly.

> > So long as it does not continue to cause problems on the ISO-comliant
> > compilers, I think we can keep the macro as an available option.
> 
> Yes.  My patch just suggested toggling the default to work with newer
> systems by default, and changing the documentation to match.  Sorry if my
> original message was too brief to indicate I had already thought about
> your valid points.

I think that we have ended up saying the same thing.  Take a look at
what I imported over the weekend.  I think you will see that the
behavior is as you suggested, and the flag defauts to true for
ISO-compliant compilers.

-Jonathan

[Visualpython-users] Limitations Re: transparency, no-shadow objects, r --> infinity

[John K. <joh...@ho...>]

<<Concerning a backdrop a long ways away, the only thing you can do is put 
very large objects a very long ways away. Just like in real life!>>

The problem with this solution is that the viewer is necessarily 
"Cartesian," i.e., disembodied, and as long as zooming is enabled (which I 
think necessary for the rest of the demo), he can always zoom "outside" of 
infinity, as it were-- a behavior I was hoping to avoid.

Is there no other solution?

<<It's based on a note from Dave Scherer a while back that if you 
deliberately set a color to have components greater than 1, you happen to 
get a behavior rather like what you want.>>

The limitation being that one of the RGB color components of the color 
expressed will have a value of one.  (Is this the same as full saturation in 
HSV?)

I've heard that at Walmart, they don't have problems, but "opportunities."  
Maybe you could consider these limitations of the present VPython as 
opportunities for improving the next version.  The package is great and has 
unlimited potential.

John

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: [Visualpython-users] Installer issues

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

> I agree.  I mostly had Windows in mind when I made my comments, since
> it's the most widespread OS.  I think once you've crossed into the
> technical, "geeky" Unix/Linux domain, you're entitled to less
hand-holding.

But how do I sneak PyGeo into it? :)

Art

Re: [Visualpython-users] History and Status?

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

It terms of concrete effort, I will be pursuing the extension to the
setup.py for VPython I did, so that it will be workable with Linux. Other
than my own learning curve to refamiliarize myself with certain Linux
issues, should not be a big deal.  As Bruce notes, the actual Linux setup.py
is essentially  already there - its really just a matter of testing for
platform and branching appropriately.

Should be able to get it to be basically functional, with the place of docs,
demso somewhere - as a draft - pending more discussion.

But the iterator thingy (technical term) issue is on my mind.

I am working with a recent Linux install, therefore gcc3.xx.

Am I correct in assuming that the fix to the CXX file needed to compile on
gcc > 3 does not break anything if compiling under a gcc < 3.  Which would
raise the question why it was there at all.  There is probably a way to test
for gcc version and fork accordingly, but I don't know if its necessary.

Anybody?

Art

Re: [Visualpython-users] Installer issues

[Matthew K. <mak...@un...>]

Arthur wrote:

> For my purposes Windows would be the target of the all-in-one distro.  I do
> understand the importance of Apple in the educational community - but don't
> know enough about it to comment about what is appropriate there.  Other than
> understanding that Linux compatibility is being achieved.
> 
> But an effort at an all-in-one Linux distribution seems to me a bad idea.
> Though it is probably achievable in some reasonable way if limited to let's
> say a version or two of Redhat and compatables, and done via rpm.
> 
> And again, I certainly think there should be a good distribution for those
> "in the loop" as to geeky kinds of things.
> 

I agree.  I mostly had Windows in mind when I made my comments, since 
it's the most widespread OS.  I think once you've crossed into the 
technical, "geeky" Unix/Linux domain, you're entitled to less hand-holding.


Matt

Re: [Visualpython-users] History and Status?

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

> Having recently switched to the Mac platform from Linux and Windows I
> too would love to help out, especially in getting a uniform dist
> package of some sort. I suspect the Mac packaging would be very similar
> to the Linux packaging. I intend to try my hand at a Fink package for
> VPython.


Joe wrote:

> > I volunteer to help. My value may be limited: I'm a user, not a
> > developer,
> > and I don't know C.  But I'll do what I can.
>

Joe-

There is something hot off the press on Mac package installation issues:
http://mail.python.org/pipermail/catalog-sig/2003-February/000337.html

Jack Jansen is the main guy maintaining the Python for Mac distribution. The
Python community loves controversy. I only know about this because of a
thread trying to talk Jack out of the naming he has decided upon for his
Package Install Manager for Python: pimp. :)

The Mac issues are  mostly however Greek to me - but pimp certainly sounds
like something that should be explored as the possible solution to VPython
Mac distribution issues.

Art

Re: [Visualpython-users] I can't run VPython on Linux RedHat

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

On Tue, 2003-02-18 at 06:16, LAZARUS MAKGALEMANE wrote:
> 
> Hi
> 
> I have tried to install the VPython software on Redhat, and followed
> the instruction. It did install and I was able to call the "idle", and
> to open the demo files.
> 
> But when I "run (F5)", it says there is no module "cvisual".
> 
> I have change the location directories in the files mensioned.
> 
> Location:
> 
> >From "/usr/local/bin"  to "/usr/bin"
> 
> My python2.2 is installed in ("/usr/bin/" , "/usr/lib/" , etc").

Look for cvisualmodule.so and a subdirectory named visual under
/usr/local/lib/python2.2/site-pakcages/.

On my system, Python finds the module there without problems.  If this
setup doesn't work for you, than cvisualmodule.so and the visual
directory must be copied into /usr/lib/python2.2/site-packages/

> Now, I was wondering if is it possible that you can email me the copy
> of VPython that is configured to run under this location "/usr/bin/"
> rather that "/usr/local/bin/". Or send me some information as to how
> should I configure the VPython that I have to suite this location.

There is no such copy right now.  The details of future distributions
are being hashed out in the "History and Status" thread.  Some people
have simply edited their install scripts to do the job.

-Jonathan

Re: [Visualpython-users] History and Status?

[Andy D. <dou...@la...>]

On Mon, 17 Feb 2003, Jonathan Brandmeyer wrote:

> Here is one idea for Debian that looks consistant with other Debian
> packages on my system.  I think that as binary debs, Vpython could be
> installed in three packages, like this:
> 
> python2.2-visual:
> 	Install runtime shared object library and runtime scripts in 
> 	/usr/lib/site-packages/visual
> 	Install documentation in /usr/share/doc/python-visual
 
> The first package is the only one that someone must have to get started
> with visual.  We can use the deb dependancy system to ensure that
> Numeric, Tkinter, and Python2.2 are installed if required.

One worry I have is that the versions required by VPython may not
necessarily match well with the versions supplied by the user's Linux
distribution.  As a specific example, the current 'stable' Debian
distribution (code name "Woody") has python-2.1.3 as its standard python.
I'm unclear whether or not a user can safely make '/usr/bin/python' be
python2.2 without possibly affecting other software installed on the
system.  In fact, in my experience with Vpython (which, admittedly, is
only 1 year long) the requirements of VPython (e.g. python version,
gtkglarea, numeric) have *never* been in agreement with the packages
available from my distribution.

Now I'm quite happy to install everything from source, so I always install
all vpython-related things into '/usr/local' or equivalent so as to not
overwrite the system versions.  If an automated Linux installation scheme
is going to update stuff in /usr/bin, then it had better do so with
extreme care.

-- 
    Andy Dougherty		dou...@la...
    Dept. of Physics
    Lafayette College, Easton PA 18042

Re: [Visualpython-users] Re: compiling vpython with gcc 3.2 (linux)

[Andy D. <dou...@la...>]

On Sun, 16 Feb 2003, Jonathan Brandmeyer wrote:

> On Fri, 2003-02-14 at 15:43, Andy Dougherty wrote: 
> > On Fri, 14 Feb 2003, Jonathan Brandmeyer wrote:
> > 
> > > The option to inherit Py::SeqBase::iterator from
> > > std::random_access_iterator<> has been removed, now it inherits from
> > > std::iterator<>.  STANDARD_LIBRARY_ITERATOR_TRAITS is no longer needed, and
> > > has been removed.  This should comply with the standard, and has been tested
> > > with g++ 3.2.1
> > 
> > I was afraid that's what you meant :-(.  I don't think it will work with
> > somewhat older systems.  For example, in both Debian 3.0 ("woody") and
> > RedHat 7.0 systems the 'std::iterator<>' stuff in
> > /usr/include/g++-3/iterator.h is surrounded by

> Woody includes gcc 3.0.4 in addition to 2.95.4.

Only sort of.  On Intel systems, g++-3.0 is not included in a standard
Woody installation.  On SPARC systems, it's not even an option.  I haven't
checked the other architectures.  The standard compiler is g++-2.95.  
(gcc-3.0 is listed as 'standard' for Intel, but it's the g++ compiler
that's relevant here, and that's listed as 'optional' for Intel.)

>                                                  On my Woody system,
> iterator traits are available when compiled with gcc-3.0. 

That's because g++-3.0 has a dependency on the libstdc++-3.0-dev package,
which is where the iterator.h header is.  The standard Woody system
without g++-3.0 has the older libstdc++-2.0, which is the one without
std::iterator<>.

In short, a standard Woody system system probably needs
std::random_access_iterator, while a newer system needs std::iterator.

> Iterator traits' availability has been tested with gcc-3.0.4, 3.2.1, and
> MSVC6.  Indirect reports show that iterator traits are available under
> CodeWarrier7, and gcc-2.95 (Apple special).

They are a function of compiler version + library version, not just
compiler version alone.  Fortunately for the end user, a good dependency
system, such as Debian's, tends to hide such details, but it does make it
harder for the developer to pin things down.

> > I think a better "fix" would be to leave the comment and #define in
> > CXX_Config.h, but change the default value of the
> > STANDARD_LIBRARY_ITERATOR_TRAITS #define to match the current standard.
> > 
> > Specifically, I had in mind something like this:
> > 
> > diff -r -u VPython/cvisual/CXX/Include/CXX_Config.h VPython-andy/cvisual/CXX/Include/CXX_Config.h
> > --- VPython/cvisual/CXX/Include/CXX_Config.h	Mon Jul 22 16:03:01 2002
> > +++ VPython-andy/cvisual/CXX/Include/CXX_Config.h	Thu Feb 13 15:52:02 2003
> > @@ -2,7 +2,7 @@
> >  #define __py_config_hh__
> >  // Macros to deal with deficiencies in compilers
> >  #define COMPILER_SUPPORTS_NAMESPACES 1
> > -#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 1
> > +#define STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 0


> Backwards.  STANDARD_LIBRARY_HAS_ITERATOR_TRAITS 1 is the ISO-compliant
> answer.  Otherwise, the header will cause inheritance from
> std::random_access_iterator. 

No, I had it right.  Quoting from the 2002-07-22 VPython distribution,
cvisual/CXX/Include/CXX_Config.h (wrapping long lines for clarity):

#if STANDARD_LIBRARY_HAS_ITERATOR_TRAITS
#  define random_access_iterator_parent(itemtype) \
	STD::random_access_iterator<itemtype, int>
#else
#  define random_access_iterator_parent(itemtype) \
	STD::iterator<STD::random_access_iterator_tag,itemtype,int>
#endif

I'd agree with you that the name, in retrospect, probably seems backwards
and is easily confusing, but my suggested patch did exactly what I wanted
it to do, namely change the default value of the
STANDARD_LIBRARY_ITERATOR_TRAITS #define to match the current standard.
I also changed the error message in cvisual/CXX/README.htm to match that
new default value.

In short, my patch will cause compilation to fail on a standard Debian
"Woody" system without g++-3.0 (and also on RedHat 7.0), but it should
also allow compilation to succeed without this particular problem on newer
standard-conforming systems.  The failure message in the patched
README.htm advises users how to work around the compilation failure.

> So long as it does not continue to cause problems on the ISO-comliant
> compilers, I think we can keep the macro as an available option.

Yes.  My patch just suggested toggling the default to work with newer
systems by default, and changing the documentation to match.  Sorry if my
original message was too brief to indicate I had already thought about
your valid points.

-- 
    Andy Dougherty		dou...@la...
    Dept. of Physics
    Lafayette College, Easton PA 18042

Re: [Visualpython-users] Installer issues

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

> for those who have never used Python, and one for Python experts.
> Ideally, (though Bruce has pointed out the practical difficulties of
> doing this) the novice installation package should contain everything
> needed to get started (Python, VPython, Numarray, etc.).

Again - I am not as far off from that thinking as might be surmised.  I
would like to get PyGeo in the hands as many folks as possible - its quite
cool, IMO - and do not want to limit the audience to geeks of any stripe.
So an all-in-one environment - that includes Python itself - is an
alternative that interests me as well.  The additional upside, if its
configured not to interfere with anything that might already exist on
anyone's machine, is that there would be alot of freedom to do things like
configure a IDE and help files specific to VPython.  I already have, for
example, a working compilation of a nice open source editor - ScITE -
configured for the syntax hightlighting of PyGeo keywords.  Easy enough to
do that for VPython.  (Frankly I think that VPython should unmarry itself
from IDLE.  There are a lot of alternatives, free and open source, that
might be explored.)

But I also agree with Bruce that a line needs to be drawn as to what
platforms will be supported.  The all-in-one distribution, for example,
might sensibly have more limited platform support than the distutils based
distribution, for example.

For my purposes Windows would be the target of the all-in-one distro.  I do
understand the importance of Apple in the educational community - but don't
know enough about it to comment about what is appropriate there.  Other than
understanding that Linux compatibility is being achieved.

But an effort at an all-in-one Linux distribution seems to me a bad idea.
Though it is probably achievable in some reasonable way if limited to let's
say a version or two of Redhat and compatables, and done via rpm.

And again, I certainly think there should be a good distribution for those
"in the loop" as to geeky kinds of things.

 There is no reason those folks will not appreciate VPython, and are the
ones likely to help create a community capable of sustaining and extending
it.

Some of the recent demos posted up to VPython gives a good idea of the kinds
of things it is capable of in experienced hands.

Art

Re: [Visualpython-users] History and Status?

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

Andrew asks-

>Is it possible to create a Vpython rpm (or deb) for easy linux
>installation?  I know that wouldn't necessarily answer the question of
>where the demos and docs should go, but it might simplify installation
>problems for people new to Vpython.

distutils does rpms as well.  Again, given a good setup.py  - creating an
rpm as opposed to a Windows .exe or a pure source distribution, is only a
command line switch to the python setup.py xxxx.

cool, no?

Art

[Visualpython-users] Installer issues

[Matthew K. <mak...@un...>]

I'd like to add my two cents to the discussion of the best way to 
distribute VPython and its associated modules.  I've been involved with 
Bruce in an introductory course that makes use of VPython for a few 
years.  I can attest to the fact that there is a huge variance in the 
level of introductory university students' computer savvy.  Some of our 
students come into the class with experience in compiling software.  But 
many others have never downloaded and installed a software package before!

We've had many cases where students have told us that they can't get 
VPython running on their own computers.  When pressed, they reveal that 
they've only installed VPython and not Python, even though the website 
clearly states that you need to install two executables.  Students are 
often notoriously poor at following directions, especially ones that 
have several steps.

The majority of our students don't have any problems with installation 
issues.  But when you're dealing with a class of 100 students or more, 
even if a small fraction of students have problems, it's enough to give 
instructors major headaches.  If educators are going to be one target 
audience of VPython, the installation procedure has to be as simple as 
possible for their students.

The best solution, IMO, is for there to be two distribution methods--one 
for those who have never used Python, and one for Python experts. 
Ideally, (though Bruce has pointed out the practical difficulties of 
doing this) the novice installation package should contain everything 
needed to get started (Python, VPython, Numarray, etc.).



Matt Kohlmyer

Re: [Visualpython-users] History and Status?

[Andrew M. <mor...@ph...>]

On Tue, 2003-02-18 at 07:41, Bruce Sherwood wrote:
> ----- Original Message -----
>=20
> From: "Jonathan Brandmeyer" <jbr...@ea...>

>=20
> > Arthur has convinced me that the right way to go for source and binary
> > distributions is to provide a setup.py (or other appropriate mechanism,
> > e.g, debs, windows exe) that does The Right Thing.  IMO, The Right Thin=
g
> > is that which bears the same look and feel as other extension modules
> > for a given platform.  We may be able to provide binaries for only a fe=
w
> > platforms, so the source distribution must be clean.
>=20
>=20
>=20
> It is possible that the only binary distribution we need is for Windows,
> simply because that's almost the only platform where it is unlikely to fi=
nd
> a compiler. It's also the platform where the user is most likely to be a
> novice with respect to Python and to programming.
>=20

Is it possible to create a Vpython rpm (or deb) for easy linux
installation?  I know that wouldn't necessarily answer the question of
where the demos and docs should go, but it might simplify installation
problems for people new to Vpython.

--=20
Andrew Morrison <mor...@ph...>

Re: Re: [Visualpython-users] History and Status?

[Joe H. <hea...@vn...>]

> From: "Bruce Sherwood" <bas...@un...>
> 
> work there). As you may know, Apple very recently started supporting X11
> itself, and it is now vastly easier to install X11 than it was a few months
> ago. I haven't verified this, but I was even told that Python comes with.
> This means that it should be possible to use the source-based installer on
> the Mac as on other Linux/Unix platforms.
> 
OS X indeed ships with Python, but I have been told there are no development libraries. Most everyone I've asked about this recommends installing Python via Fink.


Cheers,
Joe Heafner - Instructional Astronomy and Physics
Home Page http://users.vnet.net/heafnerj/index.html
I don't have a Lexus, but I do have a Mac. Same thing.

Re: [Visualpython-users] History and Status?

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

Thanks! Definitely cool.

----- Original Message -----
From: "Arthur" <ajs...@op...>


> The thing to understand is that distutils has a duel role.  From the point
> of view of the developer/distributor it is a tool to build distributions.
> From the point of the of the enduser it *can* be used - when necessary -
to
> install distributions.
>
> In terms of the Windows .exe it is purely a distributors tool.   As long
as
> the distributor has the tools to build -  I use VC6 - the cvisual.pyd (or
> .dll) then the distutils with (the correct setup.py) is a tool to build a
> VPython.exe that will install on any Windows machine - quite elegantly,
> IMO - with a double click.  The command to build the executable is
> "python setup.py bdist_wininst".  A Windows executable is thereby created
> and placed in the "dist" directory of the build tree.  that executable is
> distributable and will work for any normal Windows machine - with no need
> for that machine to have a compiler.
>
> Hope that is clear.
>
> Try it.
>
> Its cool.
>
> Art

Re: [Visualpython-users] History and Status?

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

----- Original Message -----

From: "Jonathan Brandmeyer" <jbr...@ea...>



> Here is one idea for Debian that looks consistant with other Debian
> packages on my system.  I think that as binary debs, Vpython could be
> installed in three packages, like this:
>
> python2.2-visual:
> Install runtime shared object library and runtime scripts in
> /usr/lib/site-packages/visual
> Install documentation in /usr/share/doc/python-visual
>
> python2.2-visual-examples:
> Install the demonstration scripts in
> /usr/share/doc/python-visual/examples
>
> (until no longer required)
> python2.2-visual-idle:
> Install the scripts in /usr/bin/python-visual-idle
> , with a symlink from /usr/bin/python-visual/idle.py to
> /usr/bin/vidle.py
>
> Can anyone confirm or refute similar behavior on other Linux
> distributions?  Since I custom built my visual componants, I have
> everything installed under /usr/local instead of /usr, using the same
> scheme.



This looks consistent with what I see on RedHat 8.0. It's a reasonable
suggestion to put the demos in with the documentation, but note that a user
recently ask that the demos be put in site-packages/visual, because he's
used to looking there for everything (other than documentation?). What do
others think?


> Arthur has convinced me that the right way to go for source and binary
> distributions is to provide a setup.py (or other appropriate mechanism,
> e.g, debs, windows exe) that does The Right Thing.  IMO, The Right Thing
> is that which bears the same look and feel as other extension modules
> for a given platform.  We may be able to provide binaries for only a few
> platforms, so the source distribution must be clean.



It is possible that the only binary distribution we need is for Windows,
simply because that's almost the only platform where it is unlikely to find
a compiler. It's also the platform where the user is most likely to be a
novice with respect to Python and to programming.



The Mac is a special case. I propose dropping the attempt to maintain a
version for pre-OSX, both because of declining demand and because we never
did succeed in making a good editing environment (couldn't make the new Idle
work there). As you may know, Apple very recently started supporting X11
itself, and it is now vastly easier to install X11 than it was a few months
ago. I haven't verified this, but I was even told that Python comes with.
This means that it should be possible to use the source-based installer on
the Mac as on other Linux/Unix platforms.


> As for the question, "Can the average non-programmer handle installing
> many packages?" IMHO, _given proper instructions_, the answer is yes.  I
> honestly do not see a connection between an inability to handle
> dependancies, and a lack of programming experience.



All I can say (again) is that there are experimental data on this: it's not
a theoretical question. It is observed that smart college students in
technical fields have trouble in this area. It's not necessarily programming
experience per se, but that's the most direct way to acquire the necessary
expertise. As an instructor I have an absolute need for an extremely robust,
simple installer, mainly on Windows. In classes involving hundreds of
students I can't deal with installer difficulties among a sizable fraction
of the students in those classes. I lived through an early phase of Python
and Visual installers that were not robust and simple, and it was a minor
nightmare.



What this may mean is that whatever nearly-universal installer is available
for all platforms, we may need to offer in addition a "bundled" installer
for newcomers to Python on Windows.



There are also some very specific community issues with the Mac. It happens
in physics that many 4-year liberal arts college physics departments are
Mac-only, and these instructors are a particularly interested constituency
for the physics curriculum with which I'm involved and which involves
VPython. For that reason some special care and feeding may be warranted.



Bruce Sherwood

Re: [Visualpython-users] History and Status?

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

----- Original Message -----
From: "Bruce Sherwood" <bas...@un...>
To: "Arthur" <ajs...@op...>
Cc: "vpusers" <vis...@li...>
Sent: Monday, February 17, 2003 11:25 PM
Subject: Re: [Visualpython-users] History and Status?


> Arthur, I just started to look at your materials and I have some naive
> questions:
>
> I gather that this setup.py is for use on Windows only if one has the
Visual
> C compiler?


The thing to understand is that distutils has a duel role.  From the point
of view of the developer/distributor it is a tool to build distributions.
From the point of the of the enduser it *can* be used - when necessary - to
install distributions.

In terms of the Windows .exe it is purely a distributors tool.   As long as
the distributor has the tools to build -  I use VC6 - the cvisual.pyd (or
.dll) then the distutils with (the correct setup.py) is a tool to build a
VPython.exe that will install on any Windows machine - quite elegantly,
IMO - with a double click.  The command to build the executable is
"python setup.py bdist_wininst".  A Windows executable is thereby created
and placed in the "dist" directory of the build tree.  that executable is
distributable and will work for any normal Windows machine - with no need
for that machine to have a compiler.

Hope that is clear.

Try it.

Its cool.

Art