Tcl on slashdot...
Goodwin Lawlor
http://games.slashdot.org/article.pl?sid=07/11/08/200234
It seems a Tcl/Tk version of SimCity has been adapted for the One
Laptop Per Child project (http://www.laptop.org/ ).
I notice the long term aim is "to convert SimCity into a scriptable
Python module" :-(
Goodwin
Bryan Oakley
I caught that too. I played with the Tcl version ages ago on an SGI
workstation (or was it a Sun?). Maybe we should get the code and spruce
it up with a bunch of 8.5 goodness.
--
Bryan Oakley
http://www.tclscripting.com
Larry W. Virden
> I caught that too. I played with the Tcl version ages ago on an SGI
> workstation (or was it a Sun?). Maybe we should get the code and spruce
> it up with a bunch of 8.5 goodness.
The other option, for those of our community who have worked on games
over the years, is to check out http://wiki.laptop.org/go/Developers_program
and see if perhaps we can get a decent native development environment
going. Efforts would probably be more accepted if we were developing
using compatible look and feel, etc.
Goodwin Lawlor
yeah - was thinking that too.
Goodwin Lawlor
from http://www.donhopkins.com/drupal/:
"The TCL/Tk scripting languages and user interface toolkit was a great
choice for X11 at the time (around 1992), and it still runs fine
because the code is self-contained and X11 hasn't changed in all that
time. But it would be wonderful to re-implement SimCity with a modern,
powerful scripting language like Python, and create a kid-friendly
user interface and scripting API, focused on Constructionist
Education, and teaching kids creative writing and programming language
skills.
The HyperLook version of SimCity had some cool features like map
zooming and editing at any scale, and a user-customizable hypercard-
like interface, that weren't easy to implement in TCL/Tk/X11 at the
time. But fortunately, the OLPC's Sugar user interface takes advantage
of Cairo and Pango for rendering graphics and text, which are better
than PostScript!
The first step in integrating SimCity with Sugar is to clean up and
modularize the C simulator code, and plug it into Python (which is a
much more powerful scripting language than TCL, and the standard
language for OLPC programming)."
Keith Nash
> The other option, for those of our community who have worked on games
> over the years, is to check out
> http://wiki.laptop.org/go/Developers_program and see if perhaps we can get
> a decent native development environment going. Efforts would probably be
> more accepted if we were developing using compatible look and feel, etc.
The standard language/toolkit on the OLPC is Python/GTK. It is great if
Tcl/Tk will also be on board. Is there any other Tcl/Tk software that
could be adapted for use on the OLPC?
The OLPC already has its major applications (Abiword, Gnumeric etc), and
these use GTK. However there is plenty of scope for adding small games and
toys, particularly if there is a development environment that allows the
users to experiment with them.
Keith.
blacksqr
The author appends a comment to the Slashdot article that details his
plans a bit, it may be of interest to those who want to know why
Python is often chosen over Tcl/Tk:
"After SimCity is recast as a C++ object, we will plug it into Python
and other scripting languages by using SWIG, which is a nice way to
integrate C and C++ code into a whole bunch of different scripting
languages.
Then we'll rewrite the user interface in Python, based on the other
efficient modules that are integrated into Python but written in C or C
++, including the GTK user interface toolkit for X11, the Cairo
graphics library (like PostScript graphics but much better and
hardware accelerated), the Pango text layout engine (draws with Cairo,
supports internationalized text, so SimCity can support Unicode text
and be translated into languages with non-English-like layout such as
Chinese, Hebrew, Arabic, etc.), a C++ tile engine I wrote for Python
that draws with Cairo, pie menus I wrote in Python that draw with
Cairo, and many other useful modules."
This project could serve as a laboratory for Tcl boosters to
understand if/how Python is/is perceived as superior to Tcl, and thus
if any priorities for changes/additions to Tcl suggest themselves.
Goodwin Lawlor
> plans a bit, it may be of interest to those who want to know why
> Python is often chosen over Tcl/Tk:
The last line in that comment is:
"The goal is to inspire kids to learn Python programming and develop
their own games, by reimplementing SimCity's user interface in terms
of reusable components."
I would have thought that Tcl was a better choice to "inspire kids to
learn"- its simple and at the same time powerful.
davidn...@gmail.com
> This project could serve as a laboratory for Tcl boosters to
> understand if/how Python is/is perceived as superior to Tcl, and thus
> if any priorities for changes/additions to Tcl suggest themselves.
I think we have a good handle on a lot of the reasons why, but a
polite email to the guy asking (really asking, not "why are you so
blind?!:-) about his views might be interesting.
Is it just a matter of perception?
Are there actual language features he has complaints about?
ZB
> It seems a Tcl/Tk version of SimCity has been adapted for the One
> Laptop Per Child project (http://www.laptop.org/ ).
Is it commercial? Cannot find any relative "download" link...
--
ZB
ewils...@gmail.com
> > ...
>
> The last line in that comment is:
> "The goal is to inspire kids to learn Python programming and develop
> their own games, by reimplementing SimCity's user interface in terms
> of reusable components."
>
> I would have thought that Tcl was a better choice to "inspire kids to
> learn"- its simple and at the same time powerful.
With respect, I think that Tcl syntax and semantics is far from
"simple" (regardless of the oft-quoted dozen rules). I believe that
the community is doing the language a disservice by perpetuating the
"Tcl is simple" myth because this often results in poorer
documentation - for language, extensions and libraries.
In this 1995 paper (http://cm.bell-labs.com/cm/cs/who/bwk/
workshop.ps.gz) Brian Kernighan says:
As a purely personal reaction it took me
perhaps a day to internalize VB's conventional
syntax and semantics, where it took me months
to become comfortable with Tcl.
Regards
E Wilson
Andrew Mangogna
And with respect, I don't see anything in your comments that gives any
indication of where Tcl is not "simple". It does not follow for me that
some disservice that is perpetuated by the community leads to poorer
documentation?? Language syntax and documentation are orthogonal for me.
Frankly, most bodies of software are in need of better documentation and
most programmers spend more time than they would like divining the actual
meaning of what little is written about the software they are using. And a
quote from the venerable and respected Mr. Kernighan that conventional
syntax is easier to internalize than unconventional syntax is perhaps an
interesting insight into Mr. Kernighan's thought processes or what he holds
as convention but lends little to the basic dichotomy: Tcl doesn't have any
substantial amount of syntax and therefore what becomes important for
getting anything accomplished is learning the semantics of the commands.
But the lack of syntax is, under many common circumstances, a power that
does take some time and effort to recognize. Some will recognized it, many
others simply will not.
--
Andrew Mangogna
Michael Schlenker
> On Nov 9, 8:29 pm, Goodwin Lawlor <goodwin.law...@gmail.com> wrote:
>>> ...
>> The last line in that comment is:
>> "The goal is to inspire kids to learn Python programming and develop
>> their own games, by reimplementing SimCity's user interface in terms
>> of reusable components."
>>
>> I would have thought that Tcl was a better choice to "inspire kids to
>> learn"- its simple and at the same time powerful.
>
> With respect, I think that Tcl syntax and semantics is far from
> "simple" (regardless of the oft-quoted dozen rules). I believe that
> the community is doing the language a disservice by perpetuating the
> "Tcl is simple" myth because this often results in poorer
> documentation - for language, extensions and libraries.
The argument is nearly identical to the typical Python weenie that
claims 'Python is easy to read'. As a person having to work with Python
and sometimes enjoying Tcl i can state its far from it.
Tcls documentation is quite good already, when compared to Pythons. At
least its mostly consistent, while Python has some real documentation
warts (fundamental class stuff like mro and new style python classes are
only documented in some kind of 'introductory' paper but not in the
reference documentation, from Python 2.2 onwards...).
But your right that pushing 'Tcl is simple.' to people knowing other
programming languages is a double edged sword. Those people usually have
a deeply ingrained world view, and some of it is 'syntax must be like
algol/c/c++/java in a way'. Tcl (and some other languages) challenge
this point of view.
Tcl IS simple, but simply != easy to learn for anybody. From simple
building blocks come surprisingly complex systems.
Michael
Uwe Klein
> In this 1995 paper (http://cm.bell-labs.com/cm/cs/who/bwk/
> workshop.ps.gz) Brian Kernighan says:
>
> As a purely personal reaction it took me
> perhaps a day to internalize VB's conventional
> syntax and semantics, where it took me months
> to become comfortable with Tcl.
The problems I had when learning tcl were all
related to assuming some functionality was
just like the (similar) stuff I already knew.
Er, Wrong.
uwe
Uwe Klein
Gnucash is scriptable in Guile/Scheme.
A couple of days ago i tried to adapt
a guile script for massaging gnucash internal
data into a listing of account movements to
give to my tax advisor.
I can now understand why all the gnu/gnome/whatnot
people want to write all code in C/C++ and shy away
from scripting.
IMHO Stallman hurt GNU heavily with his
personal animosity towards Oosterhout and tcl.
imho guile maybe one reason why the gEDA suite
doesn't really take off.
There is an (old but) interesting read here:
http://sourceware.org/ml/guile/1998-08/msg00143.html
uwe
Donal K. Fellows
> With respect, I think that Tcl syntax and semantics is far from
> "simple" (regardless of the oft-quoted dozen rules). I believe that
> the community is doing the language a disservice by perpetuating the
> "Tcl is simple" myth because this often results in poorer
> documentation - for language, extensions and libraries.
Whoa there! Tcl is syntactically simple and its core semantics are
simple too, but that is not the whole story. In particular, there's a
lot of richness and sophistication in the "standard library" that ships
with the language (i.e. the default commands). If we compare with C,
that's got a lot more complexity in the language syntax (so much so you
need BNF and regular expressions to describe it) and core semantics (it
takes some people a long time to grasp the finer points of pointers) and
the C standard library is rather complex too, especially once you start
adding things like the ability to work with files.
I suppose you could say that Tcl is simple in an analogous way to Lisp's
simplicity. Once you look past the surface, there's a lot going on.
> In this 1995 paper (http://cm.bell-labs.com/cm/cs/who/bwk/
> workshop.ps.gz) Brian Kernighan says:
>
> As a purely personal reaction it took me
> perhaps a day to internalize VB's conventional
> syntax and semantics, where it took me months
> to become comfortable with Tcl.
Yes. It just says that Tcl doesn't work like Algol (though it does have
a lot of Algol-ness built on top of its core).
Donal.
ewils...@gmail.com
:-) I expected that orthogonal argument and agree completely - I just
couldn't resist the little plug for documentation. Forget that part
of the email.
However, I would've thought that Brian Kernighan's comment would have
given some indication that Tcl is not simple.
It is clear that some think that Tcl is not difficult, just
unconventional. That any of the problem cannot be attributed to the
Tcl (Tcl/library/extensions/documentation/community) but mostly to
those staid and stodgy programmers who simply don't have the
wherewithal to "get" the powerful simplicity that is Tcl.
This position is held despite the list receiving not infrequent
messages from experienced Tclers being surprised by some unexpected
behaviour of the interpreter like just recently here:
with other Tclers also puzzling over it and giving contrary
solutions. (I'm very grateful to these Tcl experts who teach so
much.)
To me "Tcl is simple" should mean easy to learn, write, read and
comprehend. If it is to mean merely the paucity of syntax than we may
as well just say that. Otherwise we are being disengenuous.
> Frankly, most bodies of software are in need of better documentation and
> most programmers spend more time than they would like divining the actual
> meaning of what little is written about the software they are using. And a
> quote from the venerable and respected Mr. Kernighan that conventional
> syntax is easier to internalize than unconventional syntax is perhaps an
> interesting insight into Mr. Kernighan's thought processes or what he holds
> as convention but lends little to the basic dichotomy: Tcl doesn't have any
> substantial amount of syntax and therefore what becomes important for
> getting anything accomplished is learning the semantics of the commands.
> But the lack of syntax is, under many common circumstances, a power that
> does take some time and effort to recognize. Some will recognized it, many
> others simply will not.
You are merely repeating what has been said a zillion times on this
list and on the wiki and QOTW. Please stop this nonsense - one gets
the impression of the orchestra on the sinking Titanic.
First accept we can do better, that it is not merely the fact that Tcl
is unconventional to the unenlightened masses. Then we can move
forward. (I'm not saying the community should write free
documentation, by the way). Accept that Tcl has aspects that are not
at all simple and lets do something instead of repeatedly phrasing
that Tcl mantra in elegant ways and standing in denial.
I would like to say that the TCT has done an excellent job with regard
to new and convenient features. I am looking forward to buying more
books on Tcl. Maybe one on Tile, itcl (the itcl book is sadly out of
print, not a problem if you already have a copy), oratcl, etc.
Regards
E Wilson.
ewils...@gmail.com
wrote:
> Tcls documentation is quite good already, when compared to Pythons. At
> least its mostly consistent, while Python has some real documentation
> warts (fundamental class stuff like mro and new style python classes are
> only documented in some kind of 'introductory' paper but not in the
> reference documentation, from Python 2.2 onwards...).
>
Python has excellent books! Where can I buy a book on itcl?
>...
> Tcl IS simple, but simply != easy to learn for anybody.
>...
exactly
Michael Schlenker
> On Nov 11, 7:02 pm, Michael Schlenker <schl...@uni-oldenburg.de>
> wrote:
>
>> Tcls documentation is quite good already, when compared to Pythons. At
>> least its mostly consistent, while Python has some real documentation
>> warts (fundamental class stuff like mro and new style python classes are
>> only documented in some kind of 'introductory' paper but not in the
>> reference documentation, from Python 2.2 onwards...).
>>
>
> Python has excellent books! Where can I buy a book on itcl?
are really meant to be that. (e.g. something like Exploring Expect).
For IncrTcl for example:
http://www.amazon.com/incr-tcl-tk-Ground-Up/dp/0072121068
But as it is out of print, you would pay a heafty fee...
There are some fine books on Tcl, just not as many as for the more
popular languages, but thats an economic fact.
Basically there never were many books for Tcl. One might credit that to
the fringe nature of Tcl, thats not commercially viable to publish a
book. One could also credit it to the fact that basic Tcl is really
quite simple and you don't need much documentation to start doing useful
things. There are really complex corner cases and gotchas if you start
to do advanced things (vwait gotchas, trace semantics, namespaces with
creative writers, arrays vs values, sub language quoting rules (expr),
upvar/uplevel, aliases and namespace interactions, and so on). But the
basic stuff is really simple and usually does what you think it should do.
But thats not really a difference between Tcl and those algol like
languages, be it C or Python.
In Tcl you might be bitten once by the fact that args is a list in this
usage.
proc {a b args} {
}
In Python you might curse that the default might be mutable:
def fun(a,b,c=[]):
c.append('1')
Simple gotchas. There are tons of them in both languages.
If you do complex stuff, things get more complex. But from my experience
they stay far longer non-messy in Tcl than they do in Python and others,
especially if your going the metaprogramming route. (Python metaclasses
suck, as does their module system and part of their introspection
support. Works but requires lots of tinkering to do what you really want.)
Michael
Donal K. Fellows
> This position is held despite the list receiving not infrequent
> messages from experienced Tclers being surprised by some unexpected
> behaviour of the interpreter like just recently here:
>
> http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/9266d9e0253b79c0/4ddc78519fdc213c#4ddc78519fdc213c
>
> with other Tclers also puzzling over it and giving contrary
> solutions. (I'm very grateful to these Tcl experts who teach so
> much.)
>
> To me "Tcl is simple" should mean easy to learn, write, read and
> comprehend. If it is to mean merely the paucity of syntax than we may
> as well just say that. Otherwise we are being disengenuous.
It's pretty simple (given that [expr] *is not* simple).
expr 0x$cks ^ 0x$hex
is relying on double-substitution, which is in general a bad thing.
expr {0x$cks ^ 0x$hex}
is a syntax error (since [expr] doesn't do concatenation normally).
expr {"0x$cks" ^ "0x$hex"}
is your best workaround since it isn't subject to double-substitution
nasties but does do the concatenation (followed by interpretation as a
numeric). But again, [expr] is not simple (unlike Tcl itself).
Personally, I'd write this:
proc parsehex string {scan $string %x}
expr {[parsehex $cks] ^ [parsehex $hex]}
Since in that case I'd be writing what I mean, and not just something
that works. :-)
Donal.
suchenwi
> (I'm not saying the community should write free
> documentation, by the way).
But it does! The Wiki http://wiki.tcl.tk is a rich resource of
documentation and examples; http://en.wikibooks.org/wiki/Tcl_Programming
is more bookish in style (but collects many examples from the Wiki as
well).
Plus, the Tcl tutorial is open for all to read, and for CVS users to
write... :^)
Goodwin Lawlor
wrote:
I emailed Don Hopkins with a link to this thread, here's his reply:
Hello, Goodwin!
Please post this to the comp.lang.tcl list if you like.
First, the legal details:
The GPL source code version of SimCity will not be called "SimCity",
but we will use the SimCity source code to make a city building game
called "Micropolis", which was the original working title of SimCity.
That's because EA reserves the right to review and QA the official
version of the game that's published under the name "SimCity" on the
OLPC.
So we can make improvements to the TCL/Tk version of Micropolis (based
on the GPL source code), and submit them to EA for review and QA,
which if they approve, will be used as the officially branded version
of SimCity for the OLPC.
It will be the same code, but the only difference is the name, which
EA understandably wants to protect, be ensuring the quality and
integrity of OLPC SimCity.
That said, I strongly encourage you to improve the TCL/Tk version of
Micropolis, please!
I think it would be great to keep the TCL/Tk development line of the
code alive and strong, and modernize and improve it!
It will be a fair amount of work to upgrade it, but that will be a lot
less work and time than recasting SimCity in Python will require.
Of course both projects can go on in parallel, learning from each
other.
Since the Python version won't be ready for a long time, we can submit
an upgraded version of TCL/Tk Micropolis as the official version of
OLPC SimCity, based on the latest TCL/Tk, including further OLPC/Sugar
integration \(like making sound work better, supporting the gamepad,
etc).
TCL/Tk is a very cleanly written language and well designed user
interface toolkit, which has grown and improved a lot since I took a
snapshot of the code from around 1993 to use for SimCity.
I have found memories of meeting Professor Ousterhout in his office on
the UC Berkeley campus, and showing him the TCL/Tk version of SimCity,
and thanking him for the great work he'd done and shared for free.
The reason I want to convert the TCL/Tk version of SimCity to Python
is because it's the "official" programming language for OLPC Sugar
applications.
In the short term, the OLPC will include applications like SimCity
that uses TCL/Tk, eToys that uses Smalltalk/Squeak, etc.
But in the long term, new software developed for the OLPC should be
written in Python, to save memory by sharing modules, and to use great
modules like Cairo for scalable stencil/paint graphics, Pango for
rendering internationalized text, and all the Sugar modules written in
Python.
Despite not being written in Python, eToys and SimCity are included
with the OLPC.
The point is to educate and inspire people to develop new and better
software, to bootstrap the software of the future.
I'm compelled to move forward and develop a new visual programming
language, better and easier to use than Python or TCL, that kids can
use to reprogram the behavior and create extensions to SimCity, and
even write their own games and who knows what else.
-Don
PS:
Alan Kay has a vision of where to take OLPC SimCity, into the realm of
visual programming like Rockey's Boots and Robot Odyssey! He wrote
this exciting stuff:
Hi Don --
I'm writing to applaud you for your plans to reimplement SimCity for
children on the OLPC.
My main complaint about this game has always been the rigidity, and
sometimes stupidity, of its assumptions (counter crime with more
police stations) and the opaqueness of its mechanism (children can't
find out what its actual assumptions are, see what they look like, or
change them to try other systems dynamics).
So I have used SimCity as an example of an anti-ed environment despite
all the awards it has won. It's kind of an air-guitar environment.
In the past, I tried to get Maxis to take the actual (great)
educational possibilities more seriously, but to no avail.
Going to Python can help a few areas of this, but a better abstraction
for the heart of Sim-City would be a way to show its rules/heuristics
in a readable and writable form. Both of these could be stylized to
put them in the child's own thinking and doing world. For example,
just the simple route of making a drag and drop scripting interface
for Etoys allows children to make very readable and writeable scripts
and helps the children concentrate on what they are trying to do. A
carefully designed object system (that is filtered fro children) can
expose the environment so they can really think about it.
I'm not at all suggesting that Etoys be used here, but I am suggesting
that some deep design be done to come up with a "behavior modification
interface" that allows real creativity on the part of the children. So
it is much more than stringing black boxes together or having to deal
with fragile procedurals.
I sense that you have some interests in making SimCity really a
microworld for children's learning and exploration from reading your
webpage.
Children in 4th - 6th grade can do a lot here if they are given a good
UI and tools. So, we could think of part of this project as a "pre-
Python" UI.
Scalability and non-scalability of ideas are interesting. Rocky's
Boots is still one of the best ever games that provide profound
learning experiences. The extension of this to Robot Odyssey didn't
work because the logic and wires programming didn't scale well enough
-- the bang per effort dropped off precipitously. I was Chief
Scientist at Atari at that time (Warren Robbinet worked for me) and I
worked with TLC to try to get them to realize that something like
Logo, or even better, a rule-based robot programming system, was
needed. The failure of Robot Odyssey really pained me because I
thought that the concept of this game was one of the best ever (still
is). But it just needed a much better notion of how the children were
going to program the robots. I think the same goes for SimCity.
Cheers,
Alan
Alan Kay wrote this on the OLPC Sugar mailing list, about implementing
visual programming languages like eToys in Python:
Guido knows that I've been advocating that the Python folks should do
Etoys or a very Etoys like environment in Python (and that the rest of
the OLPC be given an objectification and media and scripting
integration that is Etoys like).
However, there are simply zillions of things left to be done
everywhere for OLPC so the first round of SW on the XO will be more of
a gathering of "suggestive" features and abilities (of which Etoys is
just one). That seems fine to me.
Viewpoints Research (our little non-profit) doesn't have any "ego or
identity" staked around whether the children's authoring environment
is Python based or Squeak based. I have said many times that, if the
general integrative base of XO is to be Python, then the Etoys-like
authoring should be based in Python also.
However, I will personally fight to the death to make sure that there
is a children's authoring environment that allows even young children
to do simulation style programming with very rich media objects.
For now, that is Etoys. It could be a suitable object-oriented Logo
with media objects (this is essentially what Etoys is). It could be
some better design (let's do one). The base could be Javascript (if
implemented on top of an integrated environment of sufficient power),
Python (ditto), Ruby (ditto), etc. Whatever it is, it has to be above
high thresholds, not a hack or a gesture.
Besides the programming the children use to learn important ideas in
math and science, they also need to be able to see how their own
computer world is structured by being able to "pop the hood" on
practically everything they use. Perhaps it is OK for high school
children to see the current code (but I don't think so). I think there
needs to be a wrapping on the entire set of facilities that uses the
same conventions that 9 year olds do their own programming in. Again,
if it is to be Python, then it needs to be crafted a bit for younger
children. E.g. Etoys allows easy unlimited parallel tasking, and this
is very important for children's programming. Etc.
There are many good things that can be done here. We live in a
computing world in which there is a tremendous amount of
identification between many programmers and the tools they use -- so
strong that it resembles religious fervor. From my view, ALL of the
system have such flaws that we are better off being critical of all of
them and try to use the best ideas from everywhere.
If "Children First!" is really the goal here, then we must spend most
of our energies trying to make the childrens' environments more
conducive to creative learning of powerful ideas.
Cheers,
Alan
Goodwin Lawlor
My comment wasn't based on a comparison of scipting languages but just
on the experience that new members in our lab have little trouble
learning Tcl and doing useful things very quickly.
Goodwin Lawlor
> Dnia 09.11.2007 Goodwin Lawlor <goodwin.law...@gmail.com> napisa³/a:
>
> > It seems a Tcl/Tk version of SimCity has been adapted for the One
> > Laptop Per Child project (http://www.laptop.org/).
>
> Is it commercial? Cannot find any relative "download" link...
> --
> ZB
http://dev.laptop.org/git?p=projects/simcity-activity;a=summary
http://dev.laptop.org/git?p=projects/micropolis-activity;a=summary
but there's nothing there yet...
ewils...@gmail.com
wrote:
> ewilsonm...@gmail.com schrieb:> On Nov 11, 7:02 pm, Michael Schlenker <schl...@uni-oldenburg.de>
> > wrote:
>
> >> Tcls documentation is quite good already, when compared to Pythons. At
> >> least its mostly consistent, while Python has some real documentation
> >> warts (fundamental class stuff like mro and new style python classes are
> >> only documented in some kind of 'introductory' paper but not in the
> >> reference documentation, from Python 2.2 onwards...).
>
> > Python has excellent books! Where can I buy a book on itcl?
>
> Books, sure. I wouldn't count most books as 'documentation' unless they
> are really meant to be that. (e.g. something like Exploring Expect).
>
> For IncrTcl for example:http://www.amazon.com/incr-tcl-tk-Ground-Up/dp/0072121068
> But as it is out of print, you would pay a heafty fee...
>
> There are some fine books on Tcl, just not as many as for the more
> popular languages, but thats an economic fact.
I know, I own 3 in their latest editions. I'm waiting for that genius
Ousterhout's. And others on Tile, IncrTcl, Oratcl. I may buy
"Exploring Expect" ... Is there any chance in the world that the out-
of-print books can be resurrected? Oracle express is now free to use
(with limitations) and my ActiveTcl distribution has the extension
that works perfectly. I just need more information with nice tutorial
examples like the books on Sqlite. If the author of Oratcl were to
write such a little pamphlet and self publish it, I'd buy it in a
heartbeat. I'd even offer to proof read it, ask silly questions that
make the book better and then go buy myself a copy when it's all done.
> Basically there never were many books for Tcl. One might credit that to
> the fringe nature of Tcl, thats not commercially viable to publish a
> book. One could also credit it to the fact that basic Tcl is really
> quite simple and you don't need much documentation to start doing useful
> things. There are really complex corner cases and gotchas if you start
> to do advanced things (vwait gotchas, trace semantics, namespaces with
> creative writers, arrays vs values, sub language quoting rules (expr),
> upvar/uplevel, aliases and namespace interactions, and so on). But the
> basic stuff is really simple and usually does what you think it should do.
>
> But thats not really a difference between Tcl and those algol like
> languages, be it C or Python.
>
> In Tcl you might be bitten once by the fact that args is a list in this
> usage.
> proc {a b args} {
>
> }
> In Python you might curse that the default might be mutable:
> def fun(a,b,c=[]):
> c.append('1')
>
> Simple gotchas. There are tons of them in both languages.
But this is nicely documented in the official help and tutorials and
in books - I wouldn't call this a gotcha, just different. I love this
feature by the way.
As you say, there are many corner cases that we bump into when go
beyond basic scripts - gotchas really that are not always obvious from
the man pages and missing from the standard books. These are the
things that make Tcl difficult and sometimes frustrating, it's just
not obvious what's going on until the the uber Tclers step in to help
us out, and even they don't always agree about what's happening first
pop. Frankly, pointers in C have had so much written about them as to
be relatively straightforward.
Someone could self-publish a "Tcl traps and pitfalls". But I doubt
that anyone will have the courage to do it. Maybe a "Tcl best
practices".
Regards
E Wilson
ewils...@gmail.com
<donal.k.fell...@manchester.ac.uk> wrote:
> ewilsonm...@gmail.com wrote:
> > With respect, I think that Tcl syntax and semantics is far from
> > "simple" (regardless of the oft-quoted dozen rules). I believe that
> > the community is doing the language a disservice by perpetuating the
> > "Tcl is simple" myth because this often results in poorer
> > documentation - for language, extensions and libraries.
>
> Whoa there! Tcl is syntactically simple and its core semantics are
> simple too, but that is not the whole story. In particular, there's a
> lot of richness and sophistication in the "standard library" that ships
> with the language (i.e. the default commands).
> ...
> I suppose you could say that Tcl is simple in an analogous way to Lisp's
> simplicity. Once you look past the surface, there's a lot going on.
Exactly. We are secure in claiming that Tcl is simple without all the
bits that make it useful like the default commands. After all what
would we have without [if] (fewer cache misses I guess ;-) Although
we are correct in claiming that [expr] is not part of Tcl I'm not sure
that that is the kind of simplicity worth defending. When I said Tcl,
I included at least the standard commands.
> > In this 1995 paper (http://cm.bell-labs.com/cm/cs/who/bwk/
> > workshop.ps.gz) Brian Kernighan says:
>
> > As a purely personal reaction it took me
> > perhaps a day to internalize VB's conventional
> > syntax and semantics, where it took me months
> > to become comfortable with Tcl.
>
> Yes. It just says that Tcl doesn't work like Algol (though it does have
> a lot of Algol-ness built on top of its core).
It also says that a very bright man, one of the great language
designers/implementors, took a while to grasp Tcl. It's hard to miss
really.
Regards
E Wilson.
ewils...@gmail.com
bauersa...@siemens.com> wrote:
> On 11 Nov., 12:44, ewilsonm...@gmail.com wrote:
>
> > (I'm not saying the community should write free
> > documentation, by the way).
>
> documentation and examples;http://en.wikibooks.org/wiki/Tcl_Programming
> is more bookish in style (but collects many examples from the Wiki as
> well).
> Plus, the Tcl tutorial is open for all to read, and for CVS users to
> write... :^)
Yes, that is a wonderful piece of work. I also like the chapters from
the book by Antirez (who has been absent from here awhile)
Regards
E Wilson.
Alan Anderson
> However, I would've thought that Brian Kernighan's comment would have
> given some indication that Tcl is not simple.
What I read just indicated that he found it "uncomfortable" to
"internalize" Tcl's syntax. Given that he is half of the very
definition of the C language, I don't think that's surprising.
It's probably the very fact that "Tcl is simple" which caused him to
need that much time to wrap his head around. He's got C-like syntax in
his DNA, as it were, and it isn't easy to unlearn such ingrained things
in order to get comfortable with Tcl's much simpler syntax.
> It is clear that some think that Tcl is not difficult, just
> unconventional...
It's unconventional among powerful programming languages, granted. But
compare it to a Unix command line, and the conventions can seem obvious.
> To me "Tcl is simple" should mean easy to learn, write, read and
> comprehend. If it is to mean merely the paucity of syntax than we may
> as well just say that. Otherwise we are being disengenuous.
In my experience, it *is* easy to learn, write, read, and comprehend.
Nearly every example to the contrary is due to people expecting it to be
much less easy than it is. But as soon as one recognizes that things
like [if] are just commands, rather than part of the language's syntax,
it all falls quickly into place.
EKB
Yes, I learned Tcl after learning Forth, and the idea of extending the
language via "command words" was very natural to me. Then I saw how
compact a GUI program could be, and I was determined to learn the
quoting rules. Those took me a while.
I agree with the OP that saying Tcl is "simple" is potentially
misleading. For me, the claim on the Tcl Developer Site that Tcl is
"easy to learn" was true. A bit of "Effective Tcl/Tk Programming" and
some examples I was off. But in spite of the very clean code in
EffTcl, I didn't write *well*, which I realized once I encountered the
Tcler's Wiki. There I saw a great variety of coding styles, some of
them extremely lean and elegant. That helped me improve. Meanwhile, I
prefer Tcl to VB (Kernighan's example) because over time I get faster
and faster writing Tcl code, finding numerous ways to make things
clean and elegant, while with VB there's only so much you can do.
In the end, I love Tcl because of its power and the ability to quickly
generate very useful programs. (I am annoyed by expr and, well, that
will remain the case. I see why expr is like it is, but it still
annoys me.) I program in other languages, but only when required to --
I reach in the first instance for Tcl.
That was a bit rambling, but finally: I agree with the OP that Tcl is
not simple. It has a deceptively simple syntax that, with practice and
exposure to examples, provides the Tcl developer with an incredible
range of options for rapidly developing tightly written, modular,
easily maintained programs.
Donal K. Fellows
> That was a bit rambling, but finally: I agree with the OP that Tcl is
> not simple. It has a deceptively simple syntax that, with practice and
> exposure to examples, provides the Tcl developer with an incredible
> range of options for rapidly developing tightly written, modular,
> easily maintained programs.
There was a game I used to play in my youth with the marketing line "A
minute to learn, a lifetime to master". Tcl takes more than a minute to
learn, but probably less than a lifetime to master; I'll let you know
when I get there.
Donal.
Donal K. Fellows
> Someone could self-publish a "Tcl traps and pitfalls". But I doubt
> that anyone will have the courage to do it. Maybe a "Tcl best
> practices".
Cameron Laird has a Frequently Made Mistakes page somewhere. Maybe he
even maintains it. :-)
Donl.
thel...@gmail.com
E,
You seriously want a book on Oratcl? Wow if 5 other people say they
do too, I guess I have to write one.
What subjects would you like most to be covered?
-todd
Darren New
> However, I would've thought that Brian Kernighan's comment would have
> given some indication that Tcl is not simple.
No. Tcl *is* simple. It's confusing when you're expecting complicated.
> This position is held despite the list receiving not infrequent
> messages from experienced Tclers being surprised by some unexpected
> behaviour of the interpreter
But this is common in all languages, simple and complicated.
> To me "Tcl is simple" should mean easy to learn, write, read and
> comprehend.
If you come from knowing Lisp, FORTH, or some other such language, Tcl
is pretty straightforward, just like if you already know C and Algol,
Pascal is pretty straightforward.
> First accept we can do better, that it is not merely the fact that Tcl
> is unconventional to the unenlightened masses. Then we can move
> forward.
Like what? Better documentation? I'll admit some of the packages could
be documented better, but it's open source that isn't particularly
popular(*), so what are you going to do?
(*) Contrast with the Linux kernel, Apache, etc.
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Darren New
> This position is held despite the list receiving not infrequent
> messages from experienced Tclers being surprised by some unexpected
> behaviour of the interpreter like just recently here:
>
> http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/9266d9e0253b79c0/4ddc78519fdc213c#4ddc78519fdc213c
BTW, this is only surprising and unexpected the first time. It was
pretty obvious to everyone who answered.
On the other hand, the OP asking the question was also doing something
that can't even be done (straightforwardly) in a language like C. So I'm
not sure why you think it isn't simple. As in, hey, if you know how the
system really works, it's simple to do this. If you're not sure how
things really work, then you have to code it up like you would in a
less-capable language.
Gerry Snyder
http://phaseit.net/claird/comp.lang.tcl/fmm.html
A quick look didn't find a date, so I don't know how recently it has
been updated, but it is a very valuable resource.
Gerry
Richard Owlett
> On 11 Nov., 12:44, ewilsonm...@gmail.com wrote:
>
>>(I'm not saying the community should write free
>>documentation, by the way).
>
>
> But it does! The Wiki http://wiki.tcl.tk is a rich resource of
> documentation and examples;
I'll accept "source of examples".
I just find it UNUSABLE for documentation. The organization of
individual "articles"(ww?) have much in common with "spaghetti code". I
regularly give up reading them for content and jump to the hyperlinks --
which are usually written to be read, not to serve as preserving a
discussion that occurred at some unspecified time in the past.
davidn...@gmail.com
> popular languages, but thats an economic fact.
What's interesting is that Tcl actually does pretty well on the Amazon
search here:
My guess is that Tcl has a lot of books that *mention* it, but aren't
about it, inflating that number. Pretty much any introduction to
Linux book from the late 90ies had a brief mention of Tcl and Tk.
Larry W. Virden
> To me "Tcl is simple" should mean easy to learn, write, read and
> comprehend.
And is it also your argument, based on the quote for BK, that Visual
BASIC _is_ simple? I mean, that's the illustration that was used to
argue that Tcl is not "simple", originally. Surely you don't propose
that VB is easy to learn, to write, to read, to comprehend? That its
documentation is useful?
Frankly, I don't know any language that would fit your definition of
"simple".
What I do know is that when I had a perl programmer who needed to
write a mid-level application, who had never written code in Tk, I
first provided them with perl/tk information. After several days, they
were confused and frustrated. So I provided them with a copy of Dr.
O's original power point slides. They were coding the Tk application
that day. Turned out they needed to make use of some iwidgets (this
was a half dozen yrs ago or so), so they also learned itcl and
iwidgets, in less time than it had taken them to attempt to learn perl/
tk - another day.
Cameron Laird
<URL: http://phaseit.net/claird/comp.lang.tcl/fmm.html#2007 >
ewils...@gmail.com
> E,
>
> You seriously want a book on Oratcl? Wow if 5 other people say they
> do too, I guess I have to write one.
Very seriously! Could 5 other people please step up and support this
brilliant extension. Wow, what an incredible response!
> What subjects would you like most to be covered?
Let me think about that a little and get back to you. If others have
ideas please contribute to this thread:
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/decb56dac39ad7bf/254bf4fa43634505#254bf4fa43634505
ewils...@gmail.com
> > as convention but lends little to the basic dichotomy: Tcl doesn't have any
> > substantial amount of syntax and therefore what becomes important for
> > getting anything accomplished is learning the semantics of the commands.
> > But the lack of syntax is, under many common circumstances, a power that
> > does take some time and effort to recognize. Some will recognized it, many
> > others simply will not.
>
> You are merely repeating what has been said a zillion times on this
> list and on the wiki and QOTW. Please stop this nonsense - one gets
> the impression of the orchestra on the sinking Titanic.
Sorry Andrew, I was unnecessarily harsh.
This remark from Donal Fellows in this same thread (he's said it
before, IIRC):
Tcl takes more than a minute to learn, but probably
less than a lifetime to master; I'll let you know
when I get there.
is not only insightful but also reveals that I (and maybe Kernighan)
was thinking about the part that could take more than a minute. We
may have been at cross-purposes. If we weren't, you're a a damn sight
cleverer than I am ... but we know that already. :-)
Regards
E Wilson
tom.rmadilo
that visual studio makes programming easy. Misleading. You still have
to know how to program, no language worth using is going to be
significantly 'easier', this is just a mathematical fact.
If anyone starts spewing out nonsense about how easy Tcl is, feel free
to hit them over the head. Maybe a few fact would help put Tcl into
some relationship with other languages:
1. scripted, not compiled,
2. safe...no pointers or buffer overflows,
3. minimum syntax rules, not a lack of syntax, a lack of need for
many rules
4. transportable between systems, avoiding the stupid virtual machine
nonsense
5. extensible via a Tcl C and Tcl scripting API.
6. embedable in C programs
7. memory management, garbage collection
8. thread-safe, really, always, not mostly
9. tclsh/wish -- easy to experiment and/or write system scripts.
10. automatic type conversions, just-in-time typing.
11. excellent string manipulation
12. excellent list operations
13. excellent channel/socket/fd abstractions
14. event loop (sorry I don't use it, but it is there)
15. excellent performance, improved when necessary with C extensions.
16. compact -- very few base commands
17. namespaces for dividing/grouping commands, data and execution
contexts
18. introspection
19. most generic syntax possible: cmd arg arg ...
20. syntax can be specialized -- [expr] parser
But if you can't program or don't understand how to benefit from these
features, Tcl might still make it easier for you to write a program
which doesn't fail quite as quickly as other languages, which is not
good. Failing fast is a good benefit, but Tcl makes up for it by
allowing you to test without compiling, I would say more than makes up
for it, so lets say Tcl allows you to fail more often, so you can try
more stuff and eventually get it right. That makes it easier to learn.
Donal K. Fellows
> But if you can't program or don't understand how to benefit from these
> features, Tcl might still make it easier for you to write a program
> which doesn't fail quite as quickly as other languages, which is not
> good. Failing fast is a good benefit, but Tcl makes up for it by
> allowing you to test without compiling, I would say more than makes up
> for it, so lets say Tcl allows you to fail more often, so you can try
> more stuff and eventually get it right. That makes it easier to learn.
You had a very good list, but two of the things I like most about Tcl
is that it tries very hard to never have an untrappable failure, and
that it ensures that its failure messages tell you how to fix at least
common failures. By contrast, too many languages tend to the "You
Messed Up, Sucker!" sort of messages or even to just keeling over so
you need to pick through the corpse with a third-party tool.
Donal.
tom.rmadilo
wrote:
Damn! Yes without that feature my last point would be totally
worthless. In a previous thread on [catch], I elaborated on this
feature, mostly by trying to point out that [catch] is usually abused
by new Tclers, so that errors are hard to track down. I even wrote an
entire toolkit which only uses [catch] a few times. That is how
important and useful Tcl error reporting actually is. With a regular
Tcl error message, it is extremely fast to track down the bug, again
assuming programming skills.
Andrew Mangogna
I don't think we were are cross-purposes since I did not have any real
purpose here. It was indulgent of me to even post a comment since this sort
of thread is so common in this group and rarely lends any additional
insight.
Over the years I have taught many people the basics of Tcl. Many of those
people were quite content to view Tcl as a means of slinging together a few
commands to accomplish some immediate task. Not a bad point of view and one
where it can be claimed that Tcl is more easily approached than other
languages. Others, after some time, saw more depth as they came to
understand a new level of power that is enabled by a language that allows
you to build and execute statements of that language and by the depth of
fundamental software capabilities contained in Tcl. This takes some time to
grasp because if your training is conventional static-typed Algol based
languages, executing your own language statements from within a program are
not possible and you develop other strategies to solve problems.
But one difficulty that I don't think can be overcome is the rather daunting
prospect of learning any of the modern dynamic languages. They are vast
with huge libraries of capabilities that have to be read and studied to
make the most effective use. If you peruse the landscape of modern dynamic
languages and if you come from a background of Algol based languages, then
Tcl will look very strange to you and a more natural inclination will be to
invest your time and effort toward something like Python with its more
familiar strictures of syntax. The more disturbing trend I have seen
recently is the attitude that one does not need to know any dynamic
language, deeming that skills in something like "C" or Java are sufficient.
Sad. Even before Tcl and the other modern dynamic languages, we assumed
that you at least needed to know "awk" in order to do the requisite text
processing.
--
Andrew Mangogna
Donal K. Fellows
> With a regular
> Tcl error message, it is extremely fast to track down the bug, again
> assuming programming skills.
I think I'd go further than that. Exposure to Tcl fundamentally changed
the way I think about errors in programs; no longer were they bolts from
the blue to be dreaded, and instead they were things that were there to
help me get straight to the root of the problem. Takes a bit longer to
code, but saves so much effort down the line.
Donal.
Larry W. Virden
<donal.k.fell...@manchester.ac.uk> wrote:
> tom.rmadilo wrote:
> > With a regular
> > Tcl error message, it is extremely fast to track down the bug, again
> > assuming programming skills.
>
> I think I'd go further than that. Exposure to Tcl fundamentally changed
> the way I think about errors in programs;
Since one of the themes of this thread is "let's don't oversell
things", I'd like to chime in that this is true to a certain level.
One of the most frustrating bugs to solve, for me, has to be the
"can't find package Xotcl"
error. No clues as to what went wrong. No references to that error
message in the man page that might help me track down that the problem
is that the package is XOTcl not Xotcl or xotcl.
So, there continues to be places within Tcl where things can be
improved. However, I see improvements in the error message in each
release, making it easier for developers to find the way to fixing
their problems.
Michael Schlenker
> On Nov 14, 4:34 pm, "Donal K. Fellows"
> <donal.k.fell...@manchester.ac.uk> wrote:
>> tom.rmadilo wrote:
>>> With a regular
>>> Tcl error message, it is extremely fast to track down the bug, again
>>> assuming programming skills.
>> I think I'd go further than that. Exposure to Tcl fundamentally changed
>> the way I think about errors in programs;
>
> Since one of the themes of this thread is "let's don't oversell
> things", I'd like to chime in that this is true to a certain level.
>
> One of the most frustrating bugs to solve, for me, has to be the
>
> "can't find package Xotcl"
>
> error. No clues as to what went wrong. No references to that error
> message in the man page that might help me track down that the problem
> is that the package is XOTcl not Xotcl or xotcl.
How about writing a short patch for the package unknown script to
issue a warning in case of interactive use.
(Using string tolower/string toupper on the list returned by package
names to look for a match).
Should be nearly trivial to do.
Michael
Michael Schlenker
possible nocase matches. The code is mostly there (copy and paste from
PKG_NAMES, add one simple loop to lowercase and compare with possible
matches).
Michael
tom.rmadilo
wrote:
> > Larry W. Virden schrieb:
> >> One of the most frustrating bugs to solve, for me, has to be the
>
> >> "can't find package Xotcl"
>
> >> error. No clues as to what went wrong. No references to that error
> >> message in the man page that might help me track down that the problem
> >> is that the package is XOTcl not Xotcl or xotcl.
> The alternative would be to patch tclPkg.c with a function that returns
> possible nocase matches. The code is mostly there (copy and paste from
> PKG_NAMES, add one simple loop to lowercase and compare with possible
> matches).
The problem is that you are using someone else's software, sources in
an unknown order. This is a generic problem which could occur with any
language. You have found a bug, and there is no trace showing where
the error occurred:
% source pkg-require-error.tcl
starting
can't find package adrd
% global errorInfo
% set errorInfo
can't find package adrd
while executing
"package require adrd"
(file "pkg-require-error.tcl" line 3)
invoked from within
"source pkg-require-error.tcl"
Larry W. Virden
In my specific case, I'm typically trying to write software to make
use of a pacakge, but I'm either uncertain what specific name to use
for the package, or I'm using the right package, but something is
wrong with the package or with the installation.
As I previously wrote, all I get is a "can't find" type message.
Sometimes, because of reading comp.lang.tcl, etc. for years, I know to
start by looking through the directories in $auto_path , to see if the
software is installed in any of them. If not, then I have to figure
out why it was installed in the wrong place. If it is, then I know to
look in pkgIndex.tcl and to try and figure out what is wrong there.
However, there's no references to that error (or most of the others)
in any of the man pages, and the error message that is generated is
accurate, but less than helpful to developers without the background
to know where to start.
I'm not trying to say "Bad Tcl!!!" here. I'm just pointing out that
while many of Tcl's error messages are quite helpful in solving
problems, there are others (such as this one, which I hit pretty
frequently) which are less helpful.
suchenwi
$ tclsh
% set foo 1
1
% puts $Foo
can't read "Foo": no such variable
"Case matters" is an old rule in Unix, C, and many other worlds...
Should the error message say "Make sure your capitalization is right"?
tom.rmadilo
> I'm not trying to say "Bad Tcl!!!" here. I'm just pointing out that
> while many of Tcl's error messages are quite helpful in solving
> problems, there are others (such as this one, which I hit pretty
> frequently) which are less helpful.
You probably wrote this as I was writing my response. Usually [package
require] is called from a page level script, inside a [namespace
eval]. In that case, you get the best information possible, assuming
you look at the full error message, you get a full file path and line
number. But only if you get the full error message. Not getting the
full error message is a programming mistake, not a language mistake.
If you use other peoples' code, you always run the risk that they
don't know what they are doing.
I seldom use [package require], I use a configuration/load script
which sources files and initializes code in a known order. It is
faster to source everything explicitly than it is to search for one
missing package. Failure should be fast, not slow. Programming should
be explicit, not guess-and-go. But, everyone appears to be happy to
make installation easy and debugging hard, go figure.
Donal K. Fellows
> I'm not trying to say "Bad Tcl!!!" here. I'm just pointing out that
> while many of Tcl's error messages are quite helpful in solving
> problems, there are others (such as this one, which I hit pretty
> frequently) which are less helpful.
The problem with this complaint is that it (largely) depends on
something being "not there", and so that generating an informative
error message would require knowing about code that hasn't been
executed. That would be pretty close to the pinnacle of TIP#131's
powers, let alone those of a normal script. :-)
Working out what didn't happen (or rather what didn't happen that
should have happened) remains difficult. But that's not special to any
language.
Donal.
tom.rmadilo
wrote:
> The problem with this complaint is that it (largely) depends on
> something being "not there", and so that generating an informative
> error message would require knowing about code that hasn't been
> executed.
Finding errors depends 100% on logging the errorInfo when an error
occurs. If you don't do that, you can't complain that Tcl has
unhelpful error messages, you just threw away the information you
needed. Maybe you should ask "What stupid application would continue
to operate if it can't find a required package?" The program should be
complaining very loudly, but it appears to be suppressing the
information provided by Tcl.
Here is an example of a startup. I put in a bogus [package require]:
[15/Nov/2007:08:32:29.257970][27192.1696194768][-main-] Notice:
TWS:About to package require abXdcE
[15/Nov/2007:08:32:29.275229][27192.1696194768][-main-] Error:
TWS:can't find package abXdcE
while executing
"package require abXdcE"
(file "/web/nsd45/servers/tutos/modules/tcl/twsdl/packages/tdom/
tcl/tdom-procs.tcl" line 14)
invoked from within
"::source /web/nsd45/servers/tutos/modules/tcl/twsdl/packages/tdom/tcl/
tdom-procs.tcl"
("uplevel" body line 1)
invoked from within
"uplevel ::source "$file""
(procedure "::tws::sourceFile" line 4)
invoked from within
"::tws::sourceFile [::tws::util::package::directory [file join
$packageName tcl ${packageName}-procs.tcl]]"
(procedure "procs" line 4)
invoked from within
"procs $package" PACKAGE tdom
[15/Nov/2007:08:32:29.275389][27192.1696194768][-main-] Notice:
TWS:Package wsdb: Procs loading...
The script had this appended:
log Notice "About to package require abXdcE"
package require abXdcE
log Notice "Done package require abXdcE"
So the last [log Notice] was skipped because the error aborts sourcing
the file, you get a full trace of the error. No mystery here.
Glenn Jackman
> On Nov 15, 8:00 am, "Donal K. Fellows" <donal.k.fell...@man.ac.uk>
> wrote:
> > The problem with this complaint is that it (largely) depends on
> > something being "not there", and so that generating an informative
> > error message would require knowing about code that hasn't been
> > executed.
> TWS:can't find package abXdcE
> while executing
> "package require abXdcE"
>
> So the last [log Notice] was skipped because the error aborts sourcing
> the file, you get a full trace of the error. No mystery here.
I think the mystery from Larry's perspective is "why can't package
abXdcE be found? I know it's there but I don't know precisely what it's
name is." The fact that Tcl's catchable errors are very informative
sheds no light there.
--
Glenn Jackman
"You can only be young once. But you can always be immature." -- Dave Barry
Larry W. Virden
I don't think we have to go to that level. But should the
documentation somewhere indicate that variables are case sensitive,
and the tutorial or doc or something mention that "no such variable"
could mean that the casing was wrong, or that the variable had not yet
been set, or that the variable had been unset by this time, or that it
existed in a different namespace? That would at least give the
programmer some ideas of the kinds of things that might cause the
problem, right?
I'm not saying that all of this belongs in the man page. But surely
somewhere a new programmer could hope to find some sort of guide.
Certainly there's a great guide for Perl that provides the reader with
at least some ideas on what to do next when encountering certain error
messages...
suchenwi
interactive tclsh:
% packa re ""
% join [lsort [package names]] /n
tom.rmadilo
> I think the mystery from Larry's perspective is "why can't package
> abXdcE be found? I know it's there but I don't know precisely what it's
> name is." The fact that Tcl's catchable errors are very informative
> sheds no light there.
Gee, I hope that isn't true, but maybe it is. The first thing a
developer should figure out is the exact name of the package they want
to require. This goes along with my complaint about optimistic
programming. If proc and/or package names ever become case
insensitive, that would be a real disaster. Duct tape programming
models work well up until they don't.
Next thing you know, there will be a TIP asking for hard coded paths
to be auto converted based upon platform, to avoid the necessity of
abstracting paths with [file] commands.
So to tie this back into the 'Tcl is easy' meme, I'll just add that
robust programming isn't easy. Guess-and-go programming is not robust.
Tcl makes it easier to write robust programs, not guess-and-go
programs.
Larry W. Virden
> At 2007-11-15 11:39AM, "tom.rmadilo" wrote:> On Nov 15, 8:00 am, "Donal K. Fellows" <donal.k.fell...@man.ac.uk>
> > wrote:
> > > The problem with this complaint is that it (largely) depends on
> > > something being "not there", and so that generating an informative
> > > error message would require knowing about code that hasn't been
> > > executed.
> [...]
> > TWS:can't find package abXdcE
> > while executing
> > "package require abXdcE"
>
> [... full trace ...]
>
>
>
> > So the last [log Notice] was skipped because the error aborts sourcing
> > the file, you get a full trace of the error. No mystery here.
>
> I think the mystery from Larry's perspective is "why can't package
> abXdcE be found? I know it's there but I don't know precisely what it's
> name is." The fact that Tcl's catchable errors are very informative
> sheds no light there.
And, in other cases, I know not only that it is there, but I know
precisely what its name is. But Tcl doesn't find it anyways.
Generally, after much head scratching, what I find is a mangled
pkgIndex.tcl or some other weird case. But, as Glenn accurately points
out, Tcl's error message tells me plenty about my code - where I typed
the command - but very little about the steps it took to decide that
the file that I "know" is there isn't being seen...
Larry W. Virden
wrote:
> The problem with this complaint is that it (largely) depends on
> something being "not there"
If, however, there were some extra command, or option, or variable, or
flag that could be set that said "show me the places you are looking
and why you are rejecting what you are rejecting, then I might be able
to say "oh look, it read the right file, but decided that the item
there wasn't relevant because ..." or "oh look, it didn't look in the
directory where the package is installed because ..." or whatever.
Right now, trying to figure out what is going on inside the process is
a black box - which is the right thing when everything works. It just
is a nuisance when something is going wrong and you need to figure out
what.
Larry W. Virden
probably want to use
join [lsort [package names]] \n
to make it a wee bit easier to read...
suchenwi
Of course - sorry, was multitasking too much to check what I actually
posted... :^)
tom.rmadilo
> And, in other cases, I know not only that it is there, but I know
> precisely what its name is. But Tcl doesn't find it anyways.
> Generally, after much head scratching, what I find is a mangled
> pkgIndex.tcl or some other weird case. But, as Glenn accurately points
> out, Tcl's error message tells me plenty about my code - where I typed
> the command - but very little about the steps it took to decide that
> the file that I "know" is there isn't being seen...
As Alexandre Ferrieux pointed out in another thread, strace is your
friend:
$ strace -o /tmp/log-file-access.txt tclsh
You will get a list of every directory searched. If you want the full
path, just try to find a package which doesn't exist. One problem with
[package require] is that you can mangle up the auto_path, so one
package might screw up something which used to work. This is a perfect
example of why using fuzzy programming is objectively annoying, and
strikes at the least helpful time. All of this plagues any language
which uses shared libraries, the problem is that with Tcl, using
shared libraries only saves disk space, in C, you save memory.
Darren New
> However, I would've thought that Brian Kernighan's comment would have
> given some indication that Tcl is not simple.
I'd note that Tcl is simple enough that, unlike C and C++, one doesn't
find programs out there to translate type declarations into English for
you so you can figure out what the compiler thinks you wrote.
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Michael Schlenker
> On Nov 15, 11:00 am, "Donal K. Fellows" <donal.k.fell...@man.ac.uk>
> wrote:
>
>> The problem with this complaint is that it (largely) depends on
>> something being "not there"
>
> If, however, there were some extra command, or option, or variable, or
> flag that could be set that said "show me the places you are looking
> and why you are rejecting what you are rejecting, then I might be able
> to say "oh look, it read the right file, but decided that the item
> there wasn't relevant because ..." or "oh look, it didn't look in the
> directory where the package is installed because ..." or whatever.
It is there inside the tcl libraries package.tcl file. Just register
your own version of the proc there before things go bad.
Michael