Tcl philosophy
Peter Murray-Rust
extremely impressed with all aspects of it and its user community, including
the high quality of this newsgroup which I have followed for about a month.
My area of interest is protein crystallography/bioinformatics and the
spate of tools that I have seen here recently has enormous potential
for much of what our community needs. We tend to use UNIX boxes (SGI or
ESV) where incoming experimental scientists are often required to use the UNIX
command-line (e.g. find, ps, etc) and have difficulty in navigating the system.
Our first use, therefore has been to build an ad-hoc set of menus (based
initially on the distributed demos) to make these less forbidding. We have
also started to add a "help" facility which includes a simple "apropos"
(where the user selects a word in the text and the system greps the rest of
the help files and displays those relevant). Simple extensions allow users to
grep parts or all of their filestore and display the result as a tree of files
(managed by the pack/unpack command).
I have become slightly "religious" about the value of Tcl/wish and am
hoping that some of the community I am part of will adopt it as a de facto
standard. One or two others have also discovered it independently and share
my zeal. Most programming in our field is presently done by scientists who
find time to do some, and the number of trained computer scientists is small
(although their importance is recognised and increasing). I have met *very* few
people who are fluent in Xt, for example.
I started to build interfaces using a commercial interface builder but
then discovered Tcl, which I find at least 10x quicker and easier. We are
also beginning to incorporate the tools which are published here (such as the
photo, hypertext and tree - to mention a few). The potential for developing a
graphical hypertext system for navigation through biological databases seems
considerable, and I suspect that your community is well on the way to building
some of the tools we shall need. Some of your contributors may not realise how
important what they have already done is to the problems that confront us.
When I evangelise about Tcl, I am often asked about its future. For
example:
1. Will it continue to grow and be supported?
2. Will it always be available? In the public domain?
3. What user tools are already available and who supports them?
4. If I want a tool, should I write it myself or is the community eager
to do it anyway?
5. Will I get locked into a non-standard language?
6. Is anyone else using these tools in our disciplines?
Recent discussion leaves me with no worries about 1,2 and 5. On 6, I
would be interested to know of major uses of Tcl/wish in the area of
biology or chemistry - I know that GCG started using wish for their
programs a year or so back but haven't heard anything since. What I
find more difficult is navigating through the various themes in the discussion.
I think there will be an increasing number of correspondents writing (like
myself) along the lines of "Hi! I've just discovered wish. I think it's great!
Please, can someone help me write a file browser or tell me why I can't get a
particular button to work..."
Tcl/wish seems to have matured to the state where there is value in
collecting some standard components and procedures and documenting how they
are used. (If this already exists, please forgive me :), and explain
where/how.) Given that this is so, I think the potential "market" - and I am
very supportive of the "free" "market" in this newsgroup - for wish is very
large. UNIX/X boxes pose a very considerable problem for scientists with
relatively little time to develop interfaces and this is only partially solved
by commercial tools.
So thanks to all those who have formed this self-help community.
------------------------------------------------------------------------------
Peter Murray-Rust | "Nothing exists except atoms and empty space; all else
pmr...@ggr.co.uk | is opinion" - Democritos. (My opinion, not my employer's)
------------------------------------------------------------------------------
Karl Lehenbauer
>I write as a user of Tcl and its associated tools and utilities, and have been
>extremely impressed with all aspects of it and its user community, including
>the high quality of this newsgroup which I have followed for about a month.
All right, another Tcl fan ;-)
>We have
>also started to add a "help" facility which includes a simple "apropos"
>(where the user selects a word in the text and the system greps the rest of
>the help files and displays those relevant). Simple extensions allow users to
>grep parts or all of their filestore and display the result as a tree of files
>(managed by the pack/unpack command).
There are help and apropos commands in Extended Tcl which cover all of Tcl
and TclX. Hopefully we'll cover Tk in the not too distant future.
I have written a Tk browser for the help stuff, which should appear in the
next release of Extended Tcl. I should note, however, that your browser may
already be more elaborate than this one.
>The potential for developing a
>graphical hypertext system for navigation through biological databases seems
>considerable, and I suspect that your community is well on the way to building
>some of the tools we shall need. Some of your contributors may not realise how
>important what they have already done is to the problems that confront us.
Are you guys aware of the hypertext work being done by the high-energy
physics community, along with numerous others on the net interested in
hypertext? It's called WWW, and stands for World-Wide Web. It is a hypertext
system where any node can be on any machine on a network, including of course
the Internet.
There are a number of compatible hypertext browsers, including Tk-WWW, a
Tcl/Tk-based one written by Joseph Wang. (Available from
harbor.ecn.purdue.edu).
For a demo of the text-based hypertext browser, and the web itself,
telnet to eies2.njit.edu, info.cern.ch, vms.huji.ac.il or info.funet.fi
and login as "www".
Also, a browser of emacs-style info files was recently made available.
I believe it is called tkinfo.
> When I evangelise about Tcl, I am often asked about its future. For
>example:
> 1. Will it continue to grow and be supported?
Hmm, flip over the Magic 8 Ball here, it says "All signs point to yes."
I mean, who can say, but there are many encouraging signs, like the Tcl book
(books?), the activity in the group, and so forth.
> 3. What user tools are already available and who supports them?
There are quite a few tools available on harbor.ecn.purdue.edu. They
are maintained by their authors.
(Don't miss xf, for example, a terrific interface builder for Tcl/Tk.)
> 4. If I want a tool, should I write it myself or is the community eager
> to do it anyway?
Depends. Go ahead and write the things that interest you, but you might
check to see what's already available before undertaking anything really big.
> 5. Will I get locked into a non-standard language?
There is no standard for Tcl at this point, in that no standards body
produces a specification for Tcl. As Tcl's popularity continues to
grow, that may well change.
You have the source code to everything, so you're not as locked in
as if you'd hooked up with some for-pay binary-only proprietary tool.
--
-- Email me for info on getting interactive Internet access.
"File names are infinite in length where infinity is set to 255 characters."
-- Peter Collinson, "The Unix File System"
Larry W. Virden
: When I evangelise about Tcl, I am often asked about its future. For
:example:
: 1. Will it continue to grow and be supported?
: 2. Will it always be available? In the public domain?
: 3. What user tools are already available and who supports them?
See the monthly FAQ, part 3, for a catalog of the tools that have been
announced in the group - well, unless I missed one...
: 5. Will I get locked into a non-standard language?
Hmm - non-standard. I am not sure what is meant here. Tcl is Tcl.
The biggest danger in my mind is the 'perl philosophy' that currently
exists in Tcl/Tk - anytime someone has a new extension, it requires one
to build a brand new wish interpretor to support it. One might have
a wish (Tk, straight from the source), wishx (extended Tcl - quite
invaluable), extentions for Tcp, Expect, Vogle, MIDI, and so on, and so
on, and so on... Sigh.
: 6. Is anyone else using these tools in our disciplines?
Please post about the tools that you are developing - especially if you
are willing to share them! I want to keep the catalog up to date, and
might even know some folk who have similar interests.
: Tcl/wish seems to have matured to the state where there is value in
:collecting some standard components and procedures and documenting how they
:are used. (If this already exists, please forgive me :), and explain
:where/how.) Given that this is so, I think the potential "market" - and I am
:very supportive of the "free" "market" in this newsgroup - for wish is very
:large. UNIX/X boxes pose a very considerable problem for scientists with
:relatively little time to develop interfaces and this is only partially solved
:by commercial tools.
I think that folk need to understand how important this point is. X11 itself
has provided very little freely available help to the non-technical user.
Look at the X11R4 or R5 release. A user who perhaps is somewhat phobic
about use of computers anyways is going to be 'stuck' with out of the box
resources, etc. until they locate a techie who has time and knowlege to
tailor their environment. Man pages are NOT designed for such users.
Let us not let Tcl/Tk/and friends suffer the same fate. While the techie
doc is critical for continued development, I hope that out in the user
community are folk who are interested in developing training materials,
tutorials, and tools to make the user's job of coming up to speed in the
environment much faster and more productive.
I also would like to suggest that folk reread those inital papers that the
father of Tcl and Tk wrote several years ago now. Think about the potentials
talked about in the ability to intercommunicate, to allow the user
to set up defaults, etc. and build your tools to take such things into
account.
--
--
Larry W. Virden INET: lvi...@cas.org
Personal: 674 Falls Place, Reynoldsburg, OH 43068-1614
Per-Erik Martin
>Hmm - non-standard. I am not sure what is meant here. Tcl is Tcl.
>The biggest danger in my mind is the 'perl philosophy' that currently
>exists in Tcl/Tk - anytime someone has a new extension, it requires one
>to build a brand new wish interpretor to support it. One might have
>a wish (Tk, straight from the source), wishx (extended Tcl - quite
>invaluable), extentions for Tcp, Expect, Vogle, MIDI, and so on, and so
>on, and so on... Sigh.
Hear, hear!
I've rapidly become a great fan of Tcl and Tk and am currently
trying to convince the staff at my site to make it THE Supported
Interface environment, but everytime I see the words "Extended Tcl",
"Tclx", "wishx", "wishy", "wishz", or whatever, I get an urge to
throw it all into /dev/null and forget I ever heard about it.
I DON'T WANT ALL THESE THINGS! I want one and only one tcl, tk and
wish.
I'd really hate to see tcl go the same way as so many good ideas,
diverging into an endless number of fighting "my tcl is better than
your tcl" fractions, or growing into a cancerous mess of creeping
featurism.
I may sound conservative, but in the 10 years I've been in this business
I have grown to appreciate small, clean, and *standardized* software,
that stays put and don't evolve into something completely new over the
weekend.
Of course I understand the need to let a young language like tcl evolve
but it has to be controlled. When I read this newsgroup I often get an
uneasy feeling that it's already slipping out of control.
But I do hope someone will say that I'm imagining things and need not
worry...
--
|\/|\/|\/| Per-Erik Martin,
| | |/\| Department of Computer Systems, Uppsala University,
|/\| | | Email: p...@minsk.DoCS.UU.SE
Mark Diekhans
In article <1parib$h...@corax.udac.uu.se> p...@Minsk.DoCS.UU.SE (Per-Erik Martin) writes:
>In article <1993Mar30.2...@cas.org> lw...@cas.org (Larry W. Virden) writes:
>>The biggest danger in my mind is the 'perl philosophy' that currently
>>exists in Tcl/Tk - anytime someone has a new extension, it requires one
>>to build a brand new wish interpretor to support it. One might have
The problem here is a lack of a standard dynamic code loader in Unix,
>I've rapidly become a great fan of Tcl and Tk and am currently
>trying to convince the staff at my site to make it THE Supported
>Interface environment, but everytime I see the words "Extended Tcl",
>"Tclx", "wishx", "wishy", "wishz", or whatever, I get an urge to
>throw it all into /dev/null and forget I ever heard about it.
>I DON'T WANT ALL THESE THINGS! I want one and only one tcl, tk and
>wish.
Your posting indicates that you don't know what these things are, so how do
you know that you don't need them? I am not trying to be rude, this seems to
be a rather sweeping statement based on never having needed or use the
functionality provided by Extended Tcl or the other packages.
Tcl is designed to be extended, its part of the Tcl philosophy. Saying that
you don't want commands that provided additional functionality is like saying
you want to program in C and never use any library but libc.
>I'd really hate to see tcl go the same way as so many good ideas,
>diverging into an endless number of fighting "my tcl is better than
>your tcl" fractions, or growing into a cancerous mess of creeping
>featurism.
Thats not what is going on. The extensions are all additional commands to the
language, not divergent languages, kind of like function in a library are to
C. Many commands that were originally part of Extended Tcl are now part of
plain Tcl (like file I/O), but many more stay as "extended" commands because
John has not viewed them as essential.
In addition, Extended Tcl provides an environment to develop non-Tk based
Tcl scripts in that is similar to an Unix shell interpreter.
>But I do hope someone will say that I'm imagining things and need not
>worry...
Don't worry!!! Write Tcl scripts instead!
Mark
Bill Poitras
: In article <1993Mar30.2...@cas.org> lw...@cas.org (Larry W. Virden) writes:
: I've rapidly become a great fan of Tcl and Tk and am currently
: trying to convince the staff at my site to make it THE Supported
: Interface environment, but everytime I see the words "Extended Tcl",
: "Tclx", "wishx", "wishy", "wishz", or whatever, I get an urge to
: throw it all into /dev/null and forget I ever heard about it.
: I DON'T WANT ALL THESE THINGS! I want one and only one tcl, tk and
: wish.
REXX for OS/2 (REXX/2) fixes this problem by having a way of loading
functions at interpret time. Doesn't Tcl support dynamic loading of
routines? If that is true there should only be one program with
everything else loadable. I don't know Tk very well, but judging from
how it really affects the way the shell program is written, wish should
be the standard program. Then you could have a function which loads a
program from a library and assigns it to a command. To avoid having to
do that for every routine in the library, library writers could also have
a single routine which registers all of the others. For example
loadRoutine routine_in_library mylibrary routine_name_in_shell
would load a routine called routine_in_library from mylibrary and
register its name as routine_name_in_shell.
loadRoutine loadAll tcldp loadTclDp
loadTclDp
This would register all the functions in TclDp.
It is this sort of mechanism that allows REXX/2 programs to create
Presentation Manager dialog boxes and such. Someone went out and wrote a
REXX compatible library and hooked up the standard PM toolbox routines.
Actually with that in mind, it would be neat to allow the GUI be loadable
as well, but just the standard Tcl (or maybe Extended Tcl too) in the
base shell:
loadRoutine loadAll tclMotif loadTclMotif
loadTclMotif
..
<setup before the GUI starts>
runTclMotif # runs until the Motif event loop is terminated.
Am I way out there or is this feasible?
--
+-------------------+----------------------------+------------------------+
| Bill Poitras | Molecular Simulations Inc. | Tel (408)522-9229 |
| bi...@west.msi.com | Sunnyvale, CA 94086-3522 | FAX (408)732-0831 |
+-------------------+----------------------------+------------------------+
|FTP Mail |mail ftp...@decwrl.dec.com | Offers:ftp via email |
| |Subject:<CR>help<CR>quit | |
+-------------------------------------------------------------------------+
Larry W. Virden
fault this keeps coming up.
Anyone want to help me write a note about dynamic libraries and Tcl?
There are currently two packages in the Tcl catalog which extend Tcl
to support dynamic libraries. The difficulty is that there is no
standard for dynamically loading of run time code in Unix (or MSDOS I
believe). I don't know whether Mac has any such thing or not.
My proposal is this. One of the packages - tclX_dld.shar.Z - is
designed to use the GNU dynamic libraries. These were intended to be
as portable as the GNU folk could make them. How about a representative
from the various environments where tclX is known to work take the
patches and try them in your environment. Work with the dld authors
(perhaps there are newer versions, etc.) and the experts in your
system's area and improve the code so that it works. If enough folk
do this, then perhaps we can get these patches incorporated into tclX
as a permanent feature!
Per-Erik Martin
> The problem here is a lack of a standard dynamic code loader in Unix,
If we can't have dynamically loaded library routines we have to take
the consequences and stick to one standard Tcl.
(At the end of this posting there's more about libraries contra
different languages.)
>>I've rapidly become a great fan of Tcl and Tk and am currently
>>trying to convince the staff at my site to make it THE Supported
>>Interface environment, but everytime I see the words "Extended Tcl",
>>"Tclx", "wishx", "wishy", "wishz", or whatever, I get an urge to
>>throw it all into /dev/null and forget I ever heard about it.
>>I DON'T WANT ALL THESE THINGS! I want one and only one tcl, tk and
>>wish.
>Your posting indicates that you don't know what these things are, so how do
>you know that you don't need them? I am not trying to be rude, this seems to
>be a rather sweeping statement based on never having needed or use the
>functionality provided by Extended Tcl or the other packages.
I didn't say I don't *need* them, I said I don't *want* them!
For one thing, I do need some standard math, like a sqrt function. But
don't want to hear that "it's in tclXXX, you can get it from foo.x.y.z",
I want it to be in THE tcl (and I saw that it will be in tcl7.0).
>Tcl is designed to be extended, its part of the Tcl philosophy. Saying that
>you don't want commands that provided additional functionality is like saying
>you want to program in C and never use any library but libc.
But I never use any library but libc (the ansi-library, that is). If I do
the code isn't portable. (Of course I occasionally have to use Unix-
specific routines, but that's another matter and only happens for system
programs that have to be system specific anyway.)
If there was an "extended" library libcx, there would be two different
C languages, C and Cx. C++ is an "extended C" (well, not quite, but almost)
and it's definitely considered to be a different language from C.
>>I'd really hate to see tcl go the same way as so many good ideas,
>>diverging into an endless number of fighting "my tcl is better than
>>your tcl" fractions, or growing into a cancerous mess of creeping
>>featurism.
>Thats not what is going on. The extensions are all additional commands to the
>language, not divergent languages, kind of like function in a library are to
>C. Many commands that were originally part of Extended Tcl are now part of
>plain Tcl (like file I/O), but many more stay as "extended" commands because
>John has not viewed them as essential.
If I write scripts for Extended Tcl, they wont work with Tcl. They're
tclX scripts, not tcl scripts. You have to choose between tcl and tclx;
you have to choose between two different languages.
And if they're supported at different sites (I get the impression that
that's the case here) they may not be divergent now, but I can't see that
anything will prevent them from diverging in the future.
And I definitely get the impression that there is some competition between
the two versions. Everytime someone asks for something in Tcl I see a reply
from you Mark, or Karl, that they should get tclX instead.
>Don't worry!!! Write Tcl scripts instead!
Tcl or TclX scripts?
I am writing Tcl scripts, but I want them to be portable.
I have nothing against the extensions in Extended Tcl, on the contrary,
I like most of them. What's disturbing me is that it's not in the original
Tcl and apparently it's developed and maintained by a different group than
the original upon which it is built. From my experience they're bound to
diverge, sooner or later.
The reason I'm so paranoid about this is because over the years I've
hacked a lot of (pre-ANSI) C, (pre-Common) Lisp, Prolog, and some C++.
Portability in C was a pain before the standard. Before Common Lisp
it wasn't even possible, and you can forget about writing portable Prolog
programs. I haven't hacked C++ for about a year or so, so I'm not sure
about it's current status. One of the reasons for giving it up was that
there was a multitude of different libraries for C++ and no standard, and
the language itself, at the time, was a moving target.
What I'm simply asking for is a guarantee that I'm not wasting my time
with something that only part of the world will be able to use in the
future, and that I'm going to be able to use all the Tcl software
produced, not only part of it.
I can live with extensions in the form of libraries. Even if we can't
have dynamically loaded libraries, you can build libraries of tcl
scripts and necessary C functions, and link them statically into your
wish. But there must be no patching of the original, the shell should
always have the same name, and some basic things must not be changed,
such as how command line arguments are handled, or the behaviour of
predefined functions.
The problem here is that TclX and wishx are shipped as Extended Tcl
and shell different from wish. And since the tclX release actually
patches the source code of tcl, I can't see how this can be called
just an "extension".
(Oh, btw, I don't really care which version becomes "standard", as
long as there is only one.)
David Herron
Namely..
- TCL has some core functionality.
- To add extensions (like tk, expect, interp, graph, htext, photo, etc)
you must hack on a main.c -- giving you a new program.
- As you come up with new combinations of extensions you hack up
different main.c's for each combination.
- In order for a user to combine a particular set of extensions they
must not only be a C programmer, but also understand a non-trivial
amount of the TCL and/or TK API.
The last greatly limits the number of people who can use TCL for what
it was meant for -- developing software with an embedded programming
language and *application*specific*extensions*.
The way this is solved in other interpretors is some functions along
the line of:
load_library
release_library
call_library_function
Given those three you could implement all extensions in the form of
something like a DLL. To access the DLL you load_library and define
a bunch of wrapper proc's for the functions you want to access.
Each wrapper does call_library_function with all the necessary
magic to convert parameters into what's required at the C level.
If we wanted to standardize a bit beyond that.. define a C function
named `add_library_commands' which takes at least an `interp' and
adds whatever commands the library provides to that interp.
To create a running TCL process with a particular set of extensions
merely requires some scripts -- no C programming.
It makes perfect sense for the core functionality of TCL to be kept
as small as possible. This makes it easier to sell people on the
idea of embedding it into things.
But keeping it small makes it that much more likely to need extension.
And makes the above discussion much more attractive.
Idea: Would it be useful to have a registry of command names?
There is the problem of expect and tk both having `send' commands ...
<- David Herron <da...@twg.com> (work) <da...@davids.mmdf.com> (home)
<-
<- "That's our advantage at Microsoft; we set the standards and we can change them."
<- Karen Hargrove of Microsoft quoted in the Feb 1993 Unix Review editorial.
Louis A. Mamakos
>I don't see the current situation as being terribly useful.
>Namely..
>
>- TCL has some core functionality.
>
>- To add extensions (like tk, expect, interp, graph, htext, photo, etc)
>you must hack on a main.c -- giving you a new program.
>
>- As you come up with new combinations of extensions you hack up
>different main.c's for each combination.
Actually, what I find really distasteful about the current situation
is that Extended TCL mucks with the plain /local/lib/libtcl.a library,
rather than being *just another library* that I'd link my application
with if I wanted Extended TCL functions.
I don't generally use any of the standalone "tcl" programs like the
one with Extended TCL, wish, etc. I used expect and I embed TCL
inside my own applications.
For example, the SLIP/CSLIP product I did for the NeXT; all of the
modem scripting and control is done with TCL. The new version is even
more dependent on TCL, and uses dynamically loaded Objective-C
classes, with dynamically added TCL commands that map to Objective-C
messages. This works great.
>It makes perfect sense for the core functionality of TCL to be kept
>as small as possible. This makes it easier to sell people on the
>idea of embedding it into things.
Yes! Yes!
>But keeping it small makes it that much more likely to need extension.
>And makes the above discussion much more attractive.
In some cases. Do you really feel the need, for example, to use Tk
functions from inside of expect very frequently? There is a certain
class of applications that use TCL mainly to provide some bit of
control and extensibility; most of the "extensions" are just
application specific operations, like "expect" inside the expect
program.
There really is a class of users out here that don't write full-blown
standalone applications that use wish or the Extended TCL "tcl"
program; our use of TCL is just below the surface.. What we (or at
least I) want is this small easily extended core interpreter function,
not a large, monolithic TCL application.
Just a slightly different perspective, from someone that wants a tool
and not necessarily a "solution."
Louis Mamakos
George M. Sipe
>
>My proposal is this. One of the packages - tclX_dld.shar.Z - is
>designed to use the GNU dynamic libraries. These were intended to be
>as portable as the GNU folk could make them. How about a representative
>from the various environments where tclX is known to work take the
>patches and try them in your environment. Work with the dld authors
>(perhaps there are newer versions, etc.) and the experts in your
>system's area and improve the code so that it works. If enough folk
>do this, then perhaps we can get these patches incorporated into tclX
>as a permanent feature!
This is a ***VERY*** bad idea.
If GNU code were combined with tcl, the result could not (easily, at
least) be used in commercial products. For that matter, even your
freely available packages would be encumbered by the GNU copyright
(referred to as the GNU copyleft, but a large and encumbering copyright
none-the-less).
tcl can never be a universal embedded language if it can not be freely
used in all software without tainting the result by licensing
encumberments. If it falls under the GNU copyright (and it would if it
were combined with other GNU code), commercial users will avoid it like
the plague.
Please note that I consider myself in general to be a supporter of GNU,
the FSF, and the LPF, but am strongly opposed to the GNU copyright
being applied to code libraries or the subsequent use of such libraries.
--
-=--------- George M. Sipe
---===------- Manager of Strategic Services
-----=====----- Pyramid Technology Corporation
-------=======--- 2970 Clairmont Road, Suite 850
---------=========- Atlanta, GA 30329
Phone: (404) 728-8977 E-mail: Georg...@Pyramid.com
Larry W. Virden
:
:In article <1993Mar31.1...@cas.org> lvi...@cas.org (Larry W. Virden) writes:
:>
:>My proposal is this. One of the packages - tclX_dld.shar.Z - is
:>designed to use the GNU dynamic libraries. These were intended to be
:>as portable as the GNU folk could make them. How about a representative
: This is a ***VERY*** bad idea.
:
:If GNU code were combined with tcl, the result could not (easily, at
:least) be used in commercial products. For that matter, even your
Fine. I won't debate GNU usability issues - I am sick of reading them in
every group including tv groups, kids groups, etc. We disagree about
what can and cannot be done with GNU software. Let's leave it at that.
Feel free to either point us towards a package which meets yours (and
the others) idea of freely usable or someone go out and re-invent the
wheel with regards to dynamically loadable object modules.
I have no personal stake in what package we use - I was merely pointing
at the only package of which I am aware.
The point is, let's pick some code, get it working on all the existing
platforms, then get folks to start using it. That's the only way we
have a prayer of resolving the situation.
Joe Buck
>I have no personal stake in what package we use - I was merely pointing
>at the only package of which I am aware.
>
>The point is, let's pick some code, get it working on all the existing
>platforms, then get folks to start using it. That's the only way we
>have a prayer of resolving the situation.
The incremental linking module included in the Ptolemy system might be
adapted to do the job. It is not as powerful as DLD, but has everything
needed for loading in Tk widgets on demand. Ptolemy is freely
redistributable under exactly the same terms as Tcl and Tk, so this should
eliminate licensing worries.
(See the FAQ list regularly posted to comp.dsp for more information on
Ptolemy).
The linker module currently works on Sparcs, Sun-3's, Vax/Ultrix, and
DecStations but should be portable to other platforms (except for the
HP-PA architecture: I've been struggling for months to get it to work
there because of the unusual properties of that system and the lack of
certain features in the linker, specifically the -N flag).
Some changes would be needed: it is currently designed to load in C++
code, invoking any global constructors found in the loaded-in code (it
handles both cfront and g++ style constructors). The approach is to
search for certain standard global symbols and invoke them as functions
taking no arguments and returning nothing. The system is structured so
that these constructors register objects in a known list. The
corresponding action in Tcl/Tk would be to register new commands in the
Tcl interpreter, associating them with newly-loaded-in code, and giving
the registration function a special name that the linker module would
recognize.
It would probably be desirable to re-do the thing in C for wider
portability -- this could be done quickly because this particular class
(Linker) just uses the class system to provide a module, and does not use
many features of C++.
If anyone is interested in working on this, let me know. I don't have
a whole lot of time to spend on it myself, what with dissertation-writing
and all, but I could assist (since I wrote the linker module).
--
Joe Buck jb...@ohm.berkeley.edu
Mark Harrison
>Tcl is designed to be extended, its part of the Tcl philosophy. Saying that
>you don't want commands that provided additional functionality is like saying
>you want to program in C and never use any library but libc.
In my view, there are two main uses of tk/tcl.
1. As an embedded command language in a custom application.
2. As a general purpose "script" language for X programming (using wish).
In my former job, we used tk/tcl primarily as #1. Currently, I am
using it primarily as #2.
For #1, there's not a lot of extra headache. You are already setting
up tcl commands, so there's not much extra work to add a few more
lines of code to do this. For #2, it's a bit more difficult.
Suppose a new package (tcl-dp, for example) is released. It is built
with C code, so a new version of wish has to be built which includes
the appropriate tcl code to incorporate the new commands. With tcl-dp,
this was no problem at all ("make dpwish"). Any wish scripts
Now, suppose another really good package comes along (a version
of "expect" that is integrated with tk, for example). We do the
same thing, and now we have an "expectwish" to use. Now we have
three versions of wish:
wish "classic"
dpwish
expectwish
Pretty soon, we can have a sizable collection of wish's, each of which
with its own unique extensions. In many cases, there's not a problem:
I run my dp applications with dpwish, etc. BUT, some of these packages
are SO GOOD that I'd like to be able to use some of the functions from
both.
Unfortunately, each of the packages "ghettoizes" the others. If you
want to combine functionality, you have to grab one of the main.c's,
diff, grep, etc, to find out what needs to be done to incorporate
the two, make, test, and install it.
and now there's yet ANOTHER wish! expect+dp-wish
What happens here (and many other places, I think) is this:
1. Someone posts a new package, we grab a copy.
2. If it's a wish script ("#!wish -f"), we try running it. If it
gets errors because of missing commands, we delete it and
forget about it.
3. If it's a package incorporating C code, we consider "Does this
provide functionality that we
a) don't want
b) want
c) really want
d) REALLY want
If the answer is a-c, most of the time it doesn't even get built.
(tclX is an example of (c) -- we really want some of the
extensions, but not badly enough to have two different wish's,
tcl libraries, etc. sitting around. For most of the things
that we would otherwise be using tclX for, we now use Perl.)
Tcl-dp is the first example of (d) that we've had. We built it
and now have a few "#!dpwish" scripts.
One non-technical reason that we want to avoid this is to circumvent
fights like "Of course it doesn't work with your-crummy-wish, you
should be using my-good-wish!"
It would be nice to have dynamic library support, but how's this
for an alternative.
1. There be a "standard" wish.c -- different from main.c, this is
especially used for building a configurable wish executable.
The main() would look like this:
main()
{
interp = Tcl_CreateInterp();
tclInit(interp);
tkInit(interp);
wish_main(interp);
}
2. Provide a standard interface for adding features. We can handle
adding one line to a main... we don't usually feel like messing
around with a bunch of #includes and Tcl_CreateCommand() calls.
I think this is a feasible approach (that's how tcl-dp does it).
If this were a *standard* way for packages to work, it would
make feature integration a LOT easier and much more feasible.
(This also would make a dynamic loading version much more
feasible as well).
From the tcl-dp main:
/*
* The only addition needed to add Tcl-DP to the
* standard Tk main.c (besides the TK_EXTENDED code
* for Extended Tcl) was this comment and the
* following call of dpInit.
*/
dpInit(interp);
Side note: Even in my C code, I don't want to have a lot of things
like this, from the dpwish main.c:
#ifdef TK_EXTENDED
static char initCmd[] = "load wishx.tcl";
#else
static char initCmd[] = "source $tk_library/wish.tcl";
#endif
Mark.
--
Mark Harrison, mhar...@dsccc.com
Robert Andrew Ryan
Excerpts from netnews.comp.lang.tcl: 1-Apr-93 Re: There Shall Be One
Tcl/.. Larry W. Vir...@cas.org (1419)
> :In article <1993Mar31.1...@cas.org> lvi...@cas.org (Larry W.
> Virden) writes:
> :>
> :>My proposal is this. One of the packages - tclX_dld.shar.Z - is
> :>designed to use the GNU dynamic libraries. These were intended to be
> :>as portable as the GNU folk could make them. How about a representative
Excerpts from netnews.comp.lang.tcl: 1-Apr-93 Re: There Shall Be One
Tcl/.. Larry W. Vir...@cas.org (1419)
> Feel free to either point us towards a package which meets yours (and
> the others) idea of freely usable or someone go out and re-invent the
> wheel with regards to dynamically loadable object modules.
If someone wants to pursue this they may wish to check out
andrew/overhead/class/{lib,machdep} of the ATK distribution. (Available
on the X tapes in the contrib tree.) It shouldn't take too much effort
to divorce the code there from the rest of the toolkit and it supports
dynamic loading on a number of platforms. (Using OS support where
available.) I don't claim it's better than anyone elses or anything
like that, only that it works for us :-)
(Bias: I work on ATK for the Andrew Consortium.)
-Rob
John Ousterhout
subject line:
1. First, I think dynamic loading is a great idea, and I think it would
be useful to define a Tcl command for this, even if it's not part of the
core, and then let people provide implementations of that command for
various systems. It would be nice to publish the command interface so
that the implementations that exist would at least all be compatible.
2. Second, I don't think dynamic loading will solve the problem about
having lots of divergent Tcl applications with different command sets.
It will just replace that problem with a different one. You'll still
get scripts that depend on certain sets of C commands that aren't part
of the core. Let's call this stuff "foobar". Instead of asking the
question "does application foobar exist on my machine? I need it to
run this script" you'll have to ask "does dynamic link library foobar
exist on my machine? I need to load it to run this script". The
second case is slightly better than the first, but only slightly.
There's a basic tradeoff that has to be made here. Either you accept
the idea of contributed software or you don't. If you do, then in order
to use anything that depends on the contributed software, you have to
*have* the contributed software. This is true whether the contributed
software is an application, a linkable library, or even Tcl procedures.
If you don't accept the idea of contributed software then either the
core Tcl system becomes monstrous and includes a lot of stuff that only
a few people need, or features that are needed by only a few people
aren't available at all. Personally I think the contributed software
approach is better, but if anyone doesn't like it then the solution is
just not to use it!
Vivek Khera
I don't see the current situation as being terribly useful.
Namely..
- TCL has some core functionality.
- To add extensions (like tk, expect, interp, graph, htext, photo, etc)
you must hack on a main.c -- giving you a new program.
- As you come up with new combinations of extensions you hack up
different main.c's for each combination.
This would be great if it were the current situation. What I see is
that "extensions" to tcl require me to unpack my compressed source
distribution, add the new code right in there and rebuild the whole
thing. If extensions were able to compile stand-alone and just link
to the installed tcl and tk libs using just the installed tcl/tk
headers, things would be much nicer. Maybe the install procedure
should install some of the "private" headers needed for writing new
functions? I don't know...
What I'd like to see is that if a program needs functionality beyond
what is provided by wish, that it should provide a new interpreter
that has the needed functions and just links to libtcl.a and libtk.a
without having me need to rebuild wish from scratch to add the
necessary functions.
Just my two cents.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Gradual Student/Systems Guy Department of Computer Science
Internet: kh...@cs.duke.edu Box 90129
(MIME mail accepted) Durham, NC 27708-0129 (919)660-6528
Dwight Shih
to consolidate my current set of extensions into a single location.
Here's a diff on my main.c:
*** main.c Tue Mar 30 13:48:14 1993
--- ../tk3.2/main.c Wed Feb 3 10:20:52 1993
***************
*** 167,173 ****
fprintf(stderr, "%s\n", interp->result);
exit(1);
}
- Tk_AddLocalCommands ( interp, w );
Tk_SetClass(w, "Tk");
Tk_CreateEventHandler(w, StructureNotifyMask, StructureProc,
(ClientData) NULL);
--- 167,172 ----
and Tk_AddLocalCommands just makes some declarations and calls
Tcl_CreateCommand so that the interpreter knows about them.
This approach doesn't address extensive modifications such as tclX,
but I think that it has a lot of promise if you're just adding some
addtional commands.
Here's a sample that pulls in graphing and hypertext widgets from
george howlett, the bell and cutbuffer commands (from ?) and the
clock formatting from tclX (I'm not quite sure about going whole
hog on tclX):
#include "tk.h"
extern int Tcl_ConvertclockCmd _ANSI_ARGS_((ClientData clientData,
Tcl_Interp *interp, int argc, char **argv));
extern int Tcl_FmtclockCmd _ANSI_ARGS_((ClientData clientData,
Tcl_Interp *interp, int argc, char **argv));
extern int Tcl_GetclockCmd _ANSI_ARGS_((ClientData clientData,
Tcl_Interp *interp, int argc, char **argv));
extern int Tk_GraphCmd _ANSI_ARGS_((ClientData clientData,
Tcl_Interp *interp, int argc, char **argv));
extern int Tk_HypertextCmd _ANSI_ARGS_((ClientData clientData,
Tcl_Interp *interp, int argc, char **argv));
extern int Tk_BellCmd _ANSI_ARGS_((ClientData clientData,
Tcl_Interp *interp, int argc, char **argv));
extern int Tk_CutBufferCmd _ANSI_ARGS_((ClientData clientData,
Tcl_Interp *interp, int argc, char **argv));
typedef struct {
char *name; /* Name of command. */
int (*cmdProc) _ANSI_ARGS_((ClientData clientData, Tcl_Interp *interp,
int argc, char **argv));
/* Command procedure. */
} TkCmd;
static TkCmd tcl_local[] = {
/*
* clock support lifted out of the tclX distribution
*/
{"convertclock", Tcl_ConvertclockCmd},
{"fmtclock", Tcl_FmtclockCmd},
{"getclock", Tcl_GetclockCmd},
/*
* termination token
*/
{(char *) NULL, (int (*)()) NULL}
};
static TkCmd tk_local[] = {
/*
* Widgets
*/
{"barchart", Tk_GraphCmd},
{"xygraph", Tk_GraphCmd},
{"hypertext", Tk_HypertextCmd},
/*
* low level X lib related commands
*/
{"bell", Tk_BellCmd},
{"cutbuffer", Tk_CutBufferCmd},
/*
* termination token
*/
{(char *) NULL, (int (*)()) NULL}
};
void
Tk_AddLocalCommands ( interp, tkwin )
Tcl_Interp *interp;
Tk_Window tkwin;
{
TkCmd *cmdPtr;
for ( cmdPtr = tcl_local ; cmdPtr->name != NULL ; cmdPtr++ ) {
Tcl_CreateCommand(interp, cmdPtr->name, cmdPtr->cmdProc,
(ClientData) NULL, (void (*)()) NULL);
}
for ( cmdPtr = tk_local ; cmdPtr->name != NULL ; cmdPtr++ ) {
Tcl_CreateCommand(interp, cmdPtr->name, cmdPtr->cmdProc,
(ClientData) tkwin, (void (*)()) NULL);
}
}
hume smith
could we redo the version stuff? say into an array...
so that the dpwish i use, for instance, would have
the equivalent of
set version(tcl) 6.7
set version(tk) 3.2
set version(dp) 1.0
in the startup somewhere. having [info tclversion]
for one and $tk_version for the other is a pain.
furthermore, a program could more easily figure out
what sort of a wish it's running in with a simple
array names version
and, any loaded script could add its own version
so that other scripts that happen to be loaded
alongside it can tell too.
--
Hume Smith Homer: Disingenuous mountebanks with
hume....@acadiau.ca their subliminal chicanery!
hume....@bnr.ca A pox on them!
hume smith
hs> i just want to throw one wee little thing in here...
hs> could we redo the version stuff? say into an array...
hs> so that the dpwish i use, for instance, would have
hs> the equivalent of
hs> set version(tcl) 6.7
hs> set version(tk) 3.2
hs> set version(dp) 1.0
or maybe a way to register the stuff in the info, in the
way so familiar to tclers:
> info version
DP Tcl Tk
> info version Tk
3.2
> info version Hiccup 0.1
> info version
DP Hiccup Tk Tcl
>
etc...
Larry W. Virden
indicate that folks didn't want contributed code, I myself am happy to
see the contributed code approach. This approach works great for the C
code developer. S/he builds a new lib*.a, adds some new .h files to
an appropriate place, and off they go.
Perhaps the situation is this - and it just occured to me this week.
There are a number of folks who are becoming wish programmers. And it
is the problem that these folk have, of needing multiple languages to
do development, that I am addressing.
I understand that Wish is just an interactive interface to the libraries.
That is the point. If one has to switch interpreters to switch libraries,
some of the interactivity (hey, is that a new word? ;-) is lost.
TERRENCE MONROE BRANNON
Unfortunately, each of the packages "ghettoizes" the others. If you
want to combine functionality, you have to grab one of the main.c's,
diff, grep, etc, to find out what needs to be done to incorporate
the two, make, test, and install it.
YES: This is a problem I have run into too many times.
2. If it's a wish script ("#!wish -f"), we try running it. If it
gets errors because of missing commands, we delete it and
forget about it.
How can we solve this aggravation?
3. If it's a package incorporating C code, we consider "Does this
provide functionality that we
a) don't want
b) want
c) really want
d) REALLY want
yep, but we can only dynamic load by files -- everything in one .o file .
i think
2. Provide a standard interface for adding features. We can handle
adding one line to a main... we don't usually feel like messing
around with a bunch of #includes and Tcl_CreateCommand() calls.
AMEN: I have torn the hair out of my head so many times over this.
--
Terry Brannon tbra...@lion.eecs.lehigh.edu
medical biology via acupunctural bioelectrics
primitive reigns supreme over nearly everyone
Don Libes
} Now, suppose another really good package comes along (a version
} of "expect" that is integrated with tk, for example). We do the
} same thing, and now we have an "expectwish" to use. Now we have
} three versions of wish:
} wish "classic"
} dpwish
} expectwish
Actually, it is called "expectk".
} Pretty soon, we can have a sizable collection of wish's, each of which
} with its own unique extensions. In many cases, there's not a problem:
} I run my dp applications with dpwish, etc. BUT, some of these packages
} are SO GOOD that I'd like to be able to use some of the functions from
} both.
} Unfortunately, each of the packages "ghettoizes" the others. If you
} want to combine functionality, you have to grab one of the main.c's,
} diff, grep, etc, to find out what needs to be done to incorporate
} the two, make, test, and install it.
Much as I enjoy the use of Expect in everyone's tirades (uh ...examples),
I feel obliged to point out that I went to some effort in version 4 to
avoid "ghettoizing" other's contributions. (Before that, it had simply
never occurred to me that Expect should be available as a linkable
library.) To add Expect to a program that already has a main and other
Tcl calls, just add:
#include "exp_main.h"
and after you've created an interpreter, call:
exp_init(interp);
Because Expect uses Tk's event handler if it's present, there are two
different Expect libraries however:
If you're just using Tcl, link with libexptcl.a.
If you're using Tcl & Tk, link with libexptk.a.
-Don
Allan Brighton
>Sigh - I had better add something about this to the FAQ - since it is MY
>fault this keeps coming up.
>
>Anyone want to help me write a note about dynamic libraries and Tcl?
>
Dynamic loading of C routines should not be too difficult. However
I do most of my work in C++, and I think that complicates matters somewhat.
Has anybody done this ? Are there any problems with virtual tables and
all that ugly stuff ? I also heard that making shared libraries for
C++ classes is not worth the trouble (on a Sun at least, until SVR4).
As to some of the other posts on this topic, it seems that some people
misunderstand the problem. The problem as I see it is that without
using dynamic loading of object files, you end up either with one
very large "wish" binary that contains everything, even though
you don't always need it or you have lots of little wishes running
around...
On the other hand (there is always another hand...), by using something
like the "interp" package, you should be able to have many tcl/tk
applications all running withing the same UNIX process and sharing
the same memory.
In any case, it might still be preferable to load what you need
at run time (if you are not sure that you will need it anyway and if
the performance doesn't suffer too much).
(By the way, has anybody tried out the tree widget/Directory browser I
posted ? I'll be on vacation in Arizona and California from Apr. 6 to
May 6, so I won't be able to answer any mail on that...)
---
_______________________________________________
Allan Brighton
Free-lance Software Engineer
E-mail: al...@piano.sta.sub.org
Snail-Mail: Zaissing 3, 8019 Steinhoering
Phone: +49 08094/1370 (near Munich, Germany)
_______________________________________________
Tim Thompson
>Dynamic loading of C routines should not be too difficult. However
>I do most of my work in C++, and I think that complicates matters somewhat.
>Has anybody done this ? Are there any problems with virtual tables and
>all that ugly stuff ?
I'm doing dynamic loading with C++. I haven't seen any problems with
virtual tables. The only problems I've had have been with the new
templates (in terms of getting all the proper instantiations generated),
and these problems are fairly easily addressed. ...Tim...
Lack Mr G M
I, too, would like there to be only one Tcl/Tk, but it's a little
impractical if that means there are no widgte extensions (I *want* some
of them!!). Perhaps a *standard* way of adding extensions would do, so
that individuals could add the extra widgets that they choose. It's all
weel and good (or rather it isn't) to have "dish", "pish", "wishx" etc,
but what do you call a wish that is "dish" + "pish" + "wishx"?
One thing I *would* like to see is for TclX to use the "standard"
Tcl mechanism for auto-loading source (yes, there is one - read the
"library" man page). Perhaps the TclX method could be *added* to this
rather than replacing it completely?
-------------------------- Gordon Lack ----------------------------------
The contents of this message *may* reflect my personal opinion. They are
*not* intended to reflect those of my employer, or anyone else.
Mark Diekhans
In article <930406100...@uk0x06.ggr.co.uk> gml...@ggr.co.uk (Lack Mr G M) writes:
>
> One thing I *would* like to see is for TclX to use the "standard"
>Tcl mechanism for auto-loading source (yes, there is one - read the
>"library" man page). Perhaps the TclX method could be *added* to this
>rather than replacing it completely?
The current TclX supports loading the standard libraries (tclIndex files)!
The thing that is missing are the auto_load and mkindex function. We are
looking at how to support this functions. If you want these functions
now, including the standard auto_mkindex and the following function in
your TclInit.tcl or as a package in your tcl.tlib file.
auto_load cmd {demand_load $cmd}
Why does TclX have its own mechanism? Well, it came first and the single
.tlib file is viewed as better for large applications.
Mail any input you have on this issue to tcl-p...@neosoft.com
Thanks,
Mark
Jon Fields
the notion of dynamic loading of C/C++ functions on SVR4.0. I have looked
at GNU dld, but it does not support SVR4. I have also looked at the code
for the Postgres dynamic loaders, but they mostly depend upon functionality
in `ld' which is not available in SVR4 (in particular, the -A option).
Any suggestions on how to accomplish dynamic loading on SVR4.0? Any references
to other packages that I could use as a starting point?
===============================================================================
Jon Fields | E-mail: jon.f...@sdrc.com
Structural Dynamics Research Corp. |------------------------------------------
2000 Eastman Drive | Tel: 513-576-5826
Milford, OH 45150-2789 | Fax: 513-576-5919
===============================================================================
David Herron
libraries.
I compared API's of GNU dld and Sun libdl.a some time ago. They provide
nearly (or exactly?) the same functionality, but with different API's.
(You can load and unload a library, and retrieve addresses given a
symbol name. Between those two abilities we would be able to do everything
I can envision *needing* to do to support dynamically constructed TCL
based processes.)
Is there something I'm missing?
Joe Kelsey
>Does SysVr4 have a libdl.a? It should since it uses Sun-style shared
>libraries.
Well, SVR4 does not have a libdl.so per se -- however, the
Sun-compatible dlopen, etc. routines all appear in the standard C
library, libc.so.
So, SVR4 contains everything necessary to do dynamic loading. I don't
know why the GNU package contains a note about not working on SVR4 --
I haven't looked at it but maybe the person who reported that misread
a note about not working on System V Release 3 and generalized that to
SVR4...
/Joe
Jeff Sparkes
The following comes from a paper in the elk-2.0 documentation. Elk
uses dynamic loading quite heavily, so I guess that the Oliver Laumann
has looked into this in detail. Apparently dlopen() is *not*
sufficient for these purposes.
Begin quote:
Incremental loading is generally supported by the link-
ers of UNIX versions that use the BSD-style a.out format and
by those of several UNIX systems based on more modern a.out
formats (e.g. Ultrix). It is not supported by any existing
release of UNIX System V. Some newer UNIX versions that
have shared libraries and dynamic linking (such as System V
Release 4 or SunOS) offer a library interface to the dynamic
linker. In some systems this kind of interface is intended
to replace the incremental loading functionality of the sys-
tem linker. These dynamic linker interfaces usually come in
the form of a library that exports functions such as dlo-
pen() to map a shared object module or shared library into
the address space of the caller (the base program) and
dlsym() to obtain the address of a function or data item in
the newly attached object module.
In some implementations, object files attached through
dlopen() may directly reference symbols in the base program;
in other implementations they may not. In any case, object
files cannot directly reference symbols defined by objects
that have been placed into the program by previous calls to
dlopen() (only, if at all, indirectly by calling dlsym()).
Thus, these dynamic linker interfaces are clearly inferior
to incremental loading, as they lack the important capabil-
ity to load a set of object files incrementally. Vendors
who have replaced ``/bin/ld -A'' by a dlopen-style library
in their UNIX systems, or who intend to do so, do not seem
to be aware of the fact that this change will break applica-
tions that rely on incremental loading.
For Elk, the consequence of being restricted to dynamic
linker interfaces of that kind is that, except for the sim-
plest applications, one must pre-link all possible combina-
tions of extensions that are not completely independent of
each other. In general, given a set of n extensions each of
which can be based on one out of m other extensions, this
means having to prepare and keep around nxm pre-linked
object files; not to mention the contortions one has to go
through when the hierarchy of extensions has a depth greater
than two (not an unlikely scenario in practice). If the
number of extensions and relations between them is larger
than trivial, or if the extensions are large or require
large libraries, keeping around all pre-linked combinations
of object modules will waste a considerable amount of disk
space.
Another, although minor, problem with these dynamic
linker interfaces is that they usually offer only a simple-
minded function (such as dlsym()) to look up the address of
a specific symbol of a newly accessed object module (typi-
cally some kind of module initialization function); but they
do not provide a way to scan all newly defined symbols.
This functionality is insufficient to implement extension
initialization in Elk, where a dynamically loadable exten-
sion often is composed from a number of small modules, each
defining its own initialization function. Requiring a sin-
gle, common initialization function name for the entire
object file implies that (often configuration-dependent)
``glue code'' must be added to call all the individual ini-
tialization functions, including the C++ static construc-
tors.
--
Jeff Sparkes jspa...@bnr.ca Bell-Northern Research, Ottawa (613)765-2503
We are Barney. You will be assimilated.
Robert Andrew Ryan
Spa...@bcars68a.bn (4452)
> In some implementations, object files attached through
> dlopen() may directly reference symbols in the base program;
> in other implementations they may not. In any case, object
> files cannot directly reference symbols defined by objects
> that have been placed into the program by previous calls to
> dlopen() (only, if at all, indirectly by calling dlsym()).
> Thus, these dynamic linker interfaces are clearly inferior
> to incremental loading, as they lack the important capabil-
> ity to load a set of object files incrementally.
I really doubt this will be a terrible burden for the purposes of tcl.
(If it is, my previous plug for the ATK dynamic loading code can address
that issue, if you're willing to use a pseudo- object oriented
programming system under C.) Also, in every system I'm aware of the
main executable, and any dlopen'd objects can all access symbols from
shared libraries... In fact in some circles shared libraries seem to be
regarded as making dynamic loading "obsolete". (Basically the strategy
is to make everything but a very minimal main(), a shared library.)
I would also like to point out that ld -A has the drawback that it's
usage varies greatly by architecture, and takes substantially longer to
link. (In the case of elk I gather that it is only done once and the
binary kept so it's not much of an issue, but if the dynamically loaded
code is still in the debug-compile-debug cycle it would be.)
Just trying to provide a little balance maybe...
-Rob Ryan
Andrew Consortium