The Tcl Core Team is pleased to announce the 8.5.1 releases of the Tcl
dynamic language and the Tk toolkit. This is the first patch release
of Tcl/Tk 8.5. More details can be found below. We would like to
express our gratitude to all those who submit bug reports and patches.
This information is invaluable in enabling us to identify and eliminate
problems in the core.
Where to get the new releases:
------------------------------
Tcl/Tk 8.5.1 sources are freely available as open source from the
Tcl Developer Xchange web site at:
http://www.tcl.tk/software/tcltk/8.5.html
This web page also contains additional information about the releases,
including new features and notes about installing and compiling the
releases. Sources are always available from the Tcl SourceForge
project's file distribution area:
http://sourceforge.net/project/showfiles.php?group_id=10894
Binaries for most major platforms are available from:
http://www.activestate.com/Tcl
For additional information:
---------------------------
Please visit the Tcl Developer Xchange web site:
This site contains a variety of information about Tcl/Tk in general, the
core Tcl and Tk distributions, Tcl development tools, and much more.
Summary of Changes since Tcl/Tk 8.5.0:
--------------------------------------
The following were the main changes in Tcl/Tk 8.5.1. A complete list
can be found in the changes file at the root of the source tree. The
more complete ChangeLog is also included with each source release. This
is a patch release, so it primarily included bug fixes and corrections
to erratic behavior. Below are only the most notable changes.
* Repaired buffer overflow in GIF handling code (CVE-2008-0553).
* Corrected broken regexp engine usage that lost backref support.
* Fixed binary reads from stacked channels.
* Fixed [format %lli 0] and [lreverse {}] crashes.
* Fixed crash in [labelframe -style].
* Fixed crash in a read-only serial channel.
* Corrected memory leak in literals in expressions.
* Revised font size values returned by [font actual]
* Improved [lsort] performance.
* Fixed Tk's Dutch message catalog.
--
Tcl Core Team and Maintainers
Don Porter, Tcl Core Release Manager
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
C:\Tcl\bin>teacup update
Retrieving application base-tcl-thread 8.5.1.0.284069 win32-ix86
...@ http://teapot.activestate.com ... Ok
...
Installing application base-tcl-thread 8.5.1.0.284069 win32-ix86
...
C:\Tcl\bin>tclsh85
% info patch
8.5.0
% exit
Just a guess: The update only updated the basekit, not the tclsh.
Michael
> Just a guess: The update only updated the basekit, not the tclsh.
For some reason, tclsh and wish are not registered as applications
available from teapot. So to truly get an update, one has to download
a new install file.
Aside from posting to Usenet in a manner so that your posts, and only your
posts, always are attachments?
He just sends a PGP signature with his posts..., if your newsreader
has troubles with MIME bodies you might see his post as an attachment.
Michael
You just updated the basekit, not the core. At this time we do not
update the core with the teacup at all - just extensions and some
extras.
Jeff
Perhaps. The interesting part is that in years of using Usenet his are the
only posts that have this behavior.
Most people don't bother signing their messages, and there's a few
different ways to attach a crypto signature to a message.
Donal.
>Most people don't bother signing their messages
Too bad, though, as it's easy to forge an apparent identity on USENET.
!Donal.
Donal K. Fellows wrote:
| Most people don't bother signing their messages, and there's a few
| different ways to attach a crypto signature to a message.
Signed in free text looks kinda ugly.. http://rfc.net/rfc1847.html is a
nice way to do it without requiring that the application understand PGP
to thus ignore it. If newsreaders can understand what to do with
multipart/alternative, and choose to render for display the text/plain
one or the text/html part, what's wrong with understanding
multipart/signed and choosing to display the text/plain section and
ignore the non understood part?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkerWrkACgkQlZadkQh/RmH/MwCg8sgv6xCI3GxTSq+PDgTbrAIW
Gn0AniszeLmOY9XXRQWFc1oNzZQnj/dl
=q2iS
-----END PGP SIGNATURE-----
Interesting. You've changed your signing so now it appears
as ugly text in the message for me. Previously your postings
were fine, with a 1-k signatire attachment underneath the
message text.
(UBC stopped carrying usenet, so I am stuck on google now.)
Donald Arseneau as...@triumf.ca
> Interesting. You've changed your signing so now it appears
> as ugly text in the message for me.
Donald, Thank you. That was the point I was trying to make.
> Previously your postings
> were fine, with a 1-k signatire attachment underneath the
> message text.
Yes, I'm on Google-Groups from work, and their system does choose to
render the text/plain half, and ignore the application/pgp-signature
part properly. The problem with standards is that there are just so
many to choose from. Even Lynx had to first understand the <img> tag
before it could display the alt= text. Yet here is a MIME type not
listed in STD-1 as required ("MIME-Encryp", RFC-1847), but works quite
well.
If I owned Outlook, I'd put in a feature request to allow for proper
ignorance.