Tcl/Tk 8.5.2 Release Candidates
Donald G Porter
Tcl/Tk 8.5.2 RC 2 now available in
ftp://ftp.tcl.tk/pub/tcl/tcl8_5/
Authors of code that calls the Ttk_* C routines are especially
encouraged to test this release. Significant changes and efforts have
been made to correct interface failures. Please confirm that the
current attempt works for you.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Mats
symbols I need are indeed found during linkage provided I have
USE_TTK_STUBS defined. However, when I try to run it on my Mac I get
EXC_BAD_ACCESS when doing:
Ttk_Theme theme = Ttk_GetTheme(interp, "aqua");
Have no idea what is going on.
Code: http://sourceforge.net/cvs/?group_id=84344 and the
chasingarrows module.
Mats
Daniel A. Steffen
On Mar 28, 9:02 am, Mats <mats...@gmail.com> wrote:
> I was testing with my chasingarrows ttk element project, and all
> symbols I need are indeed found during linkage provided I have
> USE_TTK_STUBS defined. However, when I try to run it on my Mac I get
> EXC_BAD_ACCESS when doing:
> Ttk_Theme theme = Ttk_GetTheme(interp, "aqua");
> Have no idea what is going on.
looks like you are not calling Ttk_InitStubs(interp) in 8.5 in
Chasingarrowselem_Init(), you need to with USE_TTK_STUBS defined.
Cheers,
Daniel
Mats
wrote:
Thanks, that helped :-)
Now I just have to figure out how to make it display anything...
Mats
Eric Hassold
While running tests with eTcl builds with this RC, and/or running
htmlviewer3, found a problem which is not really a bug, but a serious
incompatibility related to new http 2.7 packages merged into 8.5 branch,
and more exactly to chunk transfer support.
When a -handler argument is defined, chunk processing is not done, so
returned data has "<size>\n" chunk headers leaked in, together with a
terminating "0\n" segment. It means any current code whuch calls geturl
with a -handler argument (e.g. hv3, but also probably most code caring
about reporting progress during non-blocking http transfer) will get
corrupted answer. In new http.tcl:1029, one can find:
if {[info exists state(-handler)]} {
set n [eval $state(-handler) [list $sock $token]]
} elseif {[info exists state(transfer_final)]} {
....
} elseif {[info exists state(transfer)]
&& $state(transfer) eq "chunked"} {
....
Also, while having a look at this new http implementation, I noticed
that in the chunk handling code, socket is temporaly switched back to
blocking mode when reading chunk length header
fconfigure $sock -blocking 1
set chunk [read $sock $size]
fconfigure $sock -blocking $bl
which seems to me quite hazardous, since this might freeze a whole
application in a Event callback one may assume to be non-blocking. So
I'm wondering if, while support for chunk transfer and deflate encoding
is a nice addon, this major step forward in this (pure Tcl) http package
is really stabilized and compatible enough to be introduced during a
minor version update (8.5.1->8.5.2)? Wouldn't be more safe to leave it
as an option for those needing those features, or or provide it side by
side with previous implementation?
Eric
PS: shall I report this in SF bug report as well, or, since RC has been
announced in c.l.t, is this report enough ?
Donald G Porter wrote :
>
> Tcl/Tk 8.5.2 RC 2 now available in
>
> ftp://ftp.tcl.tk/pub/tcl/tcl8_5/
>
> Authors of code that calls the Ttk_* C routines are especially
> encouraged to test this release. Significant changes and efforts have
> been made to correct interface failures. Please confirm that the
> current attempt works for you.
>
-----
Eric Hassold
Evolane - http://www.evolane.com/
Donald G Porter
> PS: shall I report this in SF bug report as well, or, since RC has been
> announced in c.l.t, is this report enough ?
Please put it in the Tracker to be sure the http maintainers see it.
Donald G Porter
> ... this major step forward in this (pure Tcl) http package
> minor version update (8.5.1->8.5.2)? Wouldn't be more safe to leave it
> as an option for those needing those features, or or provide it side by
> side with previous implementation?
On this point only, I observe that anyone making the 8.5.1 -> 8.5.2
upgrade is going to end up with the packages http 2.5.3 and http 2.7
installed side by side anyway.
Eric Hassold
> Eric Hassold wrote:
>> PS: shall I report this in SF bug report as well, or, since RC has
>> been announced in c.l.t, is this report enough ?
>
> Please put it in the Tracker to be sure the http maintainers see it.
>
Here it is. #1928131.
Eric
Eric Hassold
> Eric Hassold wrote:
>> ... this major step forward in this (pure Tcl) http package is really
>> stabilized and compatible enough to be introduced during a minor
>> version update (8.5.1->8.5.2)? Wouldn't be more safe to leave it as an
>> option for those needing those features, or or provide it side by side
>> with previous implementation?
>
> On this point only, I observe that anyone making the 8.5.1 -> 8.5.2
> upgrade is going to end up with the packages http 2.5.3 and http 2.7
> installed side by side anyway.
>
I guess you mean anyone using ActiveTcl and teapot? because anyone using
tclkit, etcl, distro specific builds, or building Tcl core from sources
will have only http 2.7, since 2.5.3 is not in sources (could have been
left there, actually, just like hhtp1.0 is still there, and maybe
bumping new http version to 3.0).
BTW, after diving deeper into this code, I'm finding it even more
hasardous for 8.5.2: in chunked mode (which is nearly always true with
all servers, as long as protocol sent by client is now 1.1), not only
the chunk header is read in blocking mode, but the whole chunk. That is,
any network congestion occuring in the middle of a chunk will freeze the
whole Tcl application, making asynchronous http request no more possible
(even -timeout parameter will have no more effect).
Providing this as the default (since higher version) http package when a
"package require http" is issued will, IMHO, break lots of code.
Eric
Donald G Porter
>> On this point only, I observe that anyone making the 8.5.1 -> 8.5.2
>> upgrade is going to end up with the packages http 2.5.3 and http 2.7
>> installed side by side anyway.
> I guess you mean anyone using ActiveTcl and teapot? because anyone using
> tclkit, etcl, distro specific builds, or building Tcl core from sources
> will have only http 2.7, since 2.5.3 is not in sources
No. I mean http 2.5.3 will remain installed since it was installed
when Tcl 8.5.1 was installed.
New versions of packages don't overwrite (sufficiently different) older
versions. They get installed beside the existing installation(s).
Donald G Porter
One remaining flaw in the Ttk_* interfaces has been corrected, as well
as a few more bug fixes. Tcl/Tk 8.5.2 RC3 is at:
ftp://ftp.tcl.tk/pub/tcl/tcl8_5/
I expect this to become the actual release.
Jeffery Small
addressed in this proposed release?
Regards,
--
Jeff
Donald G Porter
> Have the floating point rounding problems on Solaris Intel platforms been
> addressed in this proposed release?
What's the Tracker ID? And what do the comments and fields attached
to that Tracker report say?
Mats
Now running, at least on Mac.Complete code and universal dylib in cvs.
Thanks to everyone that has made this possible.
Mats
schlenk
> Jeffery Small wrote:
> > Have the floating point rounding problems on Solaris Intel platforms been
> > addressed in this proposed release?
>
> What's the Tracker ID? And what do the comments and fields attached
> to that Tracker report say?
#1839067
Basically there is a patch available, but should be tested on stock
Solaris 10 x86 and the Sparc versions
so it does not break stuff by accident. Hoped Jeff Hobbs could take a
look (because he could reproduce those issues on the AS Solaris Intel
build), but AFAIK he hasn't done yet.
Michael