From: John Stone (johns_at_ks.uiuc.edu)
Date: Tue Oct 26 2004 - 13:25:45 CDT

Hi,
  I forgot to amplify one other issue with using system-provided
Python libraries; At present, almost nobody ships 64-bit builds of
things like Tcl/Tk/FLTK/Python/Numeric, etc with the core OS. The
next rev of MacOS X will probably do some of this, but this too has
been a historic reason why VMD does everything for itself. In the
early (and even recent!) days I had to hand-edit Tcl/Tk/FLTK/Python
makefiles to get those libraries to compile correctly on 64-bit platforms.
It would take a lot of work to get automated build scripts to fix all
of the problems I typically have to cure by hand when I build all
these libraries in 64-bit mode.

On SGI's IRIX on MIPS, I've also had problems where the global offset
table gets overflowed when linking VMD, requiring that I recompile _all_ of
the constituent libraries from source with -G0 to prevent a linkage problem
from occuring. Granted, I'd say this was caused by a weakness in SGI's
development tools for MIPS4 CPUs, but nevertheless, this is something
you can't fix if you're using vendor-provided libraries, you have no
choice to but to compile your own.

These are some of the other reasons I've had to compile my own libraries
rather than use the libraries provided by the system...

  John

On Tue, Oct 26, 2004 at 10:25:52AM -0700, Warren DeLano wrote:
> Konrad,
>
> While I agree that those of us who make use of Python as an integral part of
> our software need to get our act together when it comes to guaranteeing
> interoperability between our programs (and PyMOL is certain no exception to
> this), there is another side of the picture, since there are many thousands
> of PyMOL and VMD users who don't care about Python and don't want to be
> troubled with Python installation, versioning, and sys.path-configuration
> issues. John and I both put in significant work to insure that the
> precompiled executable we ship will work in *most* cases on each platform,
> in heterogenous environments, with or without Python of any vesion, and even
> for the most naïve users. Even the Mac situation isn't quite as clean as you
> suggest since there are really two camps: those that use Python in an
> X11-dependent (with an X11-build of Tkinter), and those who do not.
>
> Regardless, I do think that all of us (Konrad, John, Michel Sanner, the
> Chimera team, the PHENIX team, the CCP4mg team, myself, and others) should
> come to a meeting of minds with respect to how we are going to support
> Python-based interporability on each platform. That would imply a standard
> Python build and an agreed set of conventions for linking to it. It could
> the system Python on 10.3+ based macs, but the situation is less well
> defined on Windows and Linux.
>
> Two of the key problems with viewing Python "as an integral part of a
> computer system" is that (1) root access is usually required for
> installation and (2) it then becomes nearly impossible to support multiple
> simultaneous versions of interdependent components. I personally believe
> that unprivileged, user-space Python installs have significant advantages.
>
> Cheers,
> Warren
>
> --
> mailto:warren_at_delsci.com
> Warren L. DeLano, Ph.D.
> Principal Scientist
> DeLano Scientific LLC
> 400 Oyster Pt. Blvd., Ste 213
> South San Francisco, CA 94080
> (650)-346-1154 Fax:(650)-593-4020
>
>
> > -----Original Message-----
> > From: owner-vmd-l_at_ks.uiuc.edu
> > [mailto:owner-vmd-l_at_ks.uiuc.edu] On Behalf Of hinsen_at_llb.saclay.cea.fr
> > Sent: Tuesday, October 26, 2004 9:07 AM
> > To: John Stone
> > Cc: vmd-l_at_ks.uiuc.edu
> > Subject: Re: vmd-l: python2.3 and vmd
> >
> > On Oct 25, 2004, at 20:37, John Stone wrote:
> >
> > > Another option that appeals to me is to just include the python
> > > library that VMD is compiled against in the binary
> > distribution. This
> > > would eliminate the necessity for the average user to have to mess
> > > with
> >
> > The question is: why do people use Python within VMD? If most
> > users just want to script VMD and happen to prefer Python to
> > Tcl, that approach would help. If, on the other hand, most
> > users are Python programmers who see VMD as "yet another
> > Python module", then they wouldn't be interested: they would
> > most certainly want to use the copy of Python they already
> > have fine-tuned for their needs with added modules.
> >
> > I am not going to hide the fact that I am in the second category.
> >
> > > problem at present. As far as I know, Python does not provide an
> > > equivalent of Tcl's "tcl stubs" functionality, so there's
> > basically no
> > > way to strongly insulate VMD against Python version changes and
> > > incompatbilities.
> >
> > No. Compatibility is pretty good over many generations of
> > Python, but at the source code level. C modules need to be
> > recompiled with every change in the second digit of the
> > version number.
> >
> > I see Python as an integral part of a computer system. It is
> > there, and everything that needs it builds on the existing
> > interpreter. That way all modules can be freely used
> > together, which is what makes Python so powerful. Linux and
> > MacOS (since 10.3) follow that approach: they come with
> > Python preinstalled and nobody other then Python developers
> > and testers would ever install another copy.
> >
> > > What would be ideal would be to implement text interpreters
> > in VMD as
> > > plugins that are completely dynamically linked. There are numerous
> >
> > Either that, or have interpreters in separate processes that
> > communicate over sockets.
> >
> > Konrad.
> > --
> > ---------------------------------------------------------------------
> > Konrad Hinsen
> > Laboratoire Léon Brillouin, CEA Saclay,
> > 91191 Gif-sur-Yvette Cedex, France
> > Tel.: +33-1 69 08 79 25
> > Fax: +33-1 69 08 82 61
> > E-Mail: hinsen_at_llb.saclay.cea.fr
> > ---------------------------------------------------------------------
> >
> >
> >
>
>

-- 
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
Email: johns_at_ks.uiuc.edu                 Phone: 217-244-3349              
  WWW: http://www.ks.uiuc.edu/~johns/      Fax: 217-244-6078