ActiveTcl 8.6.0.0 Beta 3 released
AndreasK
Beta 3, a beta release of the complete, ready-to-install Tcl
distribution for Windows, Mac OS X, Linux, Solaris, AIX and HP-UX;
based on the Tcl/Tk 8.6b1.2 core.
For detailed information or to download these releases, see:
http://www.activestate.com/activetcl/
== New in ActiveTcl 8.6.0.0b3 ==
A beta update release with updates, including:
* Updated Tcl/Tk core to 8.6b1.2
* Updated teacup package management application
* Updated packages
** platform 1.0.8
** BWidget 1.9.1
** struct::stack 1.5.1
** struct::queue 1.4.2
** pngtcl 1.4.1
** zlibtcl 1.2.5
** sqlite 3.6.23
Download ActiveTcl 8.6.0.0b3 now:
http://www.activestate.com/activetcl
For access to more packages, use the included [teacup] application.
=== Getting Started ===
Whether you're a first-time user or a long-time fan, our free
resources
will help you get the most from ActiveTcl.
User forums and FAQs:
http://community.activestate.com/products/ActiveTcl
Mailing list archives:
http://aspn.activestate.com/ASPN/Mail/?topic=Tcl
Documentation:
http://docs.activestate.com/activetcl/8.6/
=== On what platforms does ActiveTcl run? ===
ActiveTcl includes installers for the following platforms:
- Windows/x86
- Mac OS X
- Linux/x86
- Linux/x86_64 (aka "AMD64")
- Solaris/SPARC (Business Edition only)
- Solaris/x86 (Business Edition only)
- HP-UX/PA-RISC (Business Edition only)
- AIX/PowerPC (Business Edition only)
Custom builds are available in Enterprise Edition:
http://www.activestate.com/activetcl/enterprise/
=== Feedback ===
Everyone is encouraged to participate in making Tcl an even better
language. For bugs related to ActiveTcl, please use:
http://bugs.ActiveState.com/enter_bug.cgi?product=ActiveTcl&version=8.6.0.0b3
Tcl/Tk is maintained by the Tcl community, with the sources and bug
database at SourceForge:
http://tcl.SourceForge.net/
Enjoy!
--
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts
P: 778.786.1122
F: 778.786.1133
andr...@activestate.com
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog
leonid
>
> Tcl/Tk is maintained by the Tcl community, with the sources and bug
> database at SourceForge:
> http://tcl.SourceForge.net/
>
> Enjoy!
>
> --
> Andreas Kupries
> Senior Tcl Developer
> ActiveState, The Dynamic Language Experts
>
> P: 778.786.1122
> F: 778.786.1133
> Get insights on Open Source and Dynamic Languages atwww.activestate.com/blog
Hello . I have got next message from tcl/tk 8.6.0.0 beta3
() 1 % package require Tkhtml 3.0
Keyword 'catch' not found where expected.
() 2 %
This is a new check. How to solve this problem ?
Thank you. Leonid
AndreasK
Just tried this on Linux and had no problem loading this package. My
session, roughly:
% ... get the distribution ...
% ./ActiveTcl8.6.0.0b3.292682-linux-ix86-threaded/install.sh --
directory FOX
% ./FOX/bin/teacup install Tkhtml 3
% ./FOX/bin/tclsh8.6
% package require Tkhtml 3
3.0
% exit
Some questions.
What platform are you on ?
Do you get this message only for Tkhtml 3, or for other packages as
well ?
Did you install your AT 8.6 into a separate directory, or is is
sharing with other/older AT installations ?
If it is sharing please install into a separate directory and try if
that is ok.
leonid
>
> - Show quoted text -
I test new Tcl/tk 8.6 beta3 in Windows and have got this message from
several packages
Thank you. Leonid
AndreasK
I am unable to reproduce this here for a test Windows installation
either.
Tkhtml 3 loads fine into wish8.6, without any type of error message.
C:\Tcl.8600b3.292682\bin>teacup.exe install Tkhtml 3
Resolving Tkhtml 3 ... [package Tkhtml 3.0 win32-ix86 @ http://teapot.activestate.com]
Resolving Tcl 8.4 -is package ... [package Tcl 8.6 _ ... Installed
outside repository, probing dependencies]
Resolving Tk 8.4 -is package ... [package Tk 8.6b1.2 _ ... Installed
outside repository, probing dependencies]
Retrieving package Tkhtml 3.0 win32-ix86 ...@ http://teapot.activestate.com
... Ok
Installing into C:/Tcl.8600b3.292682/lib/teapot
Installing package Tkhtml 3.0 win32-ix86
C:\Tcl.8600b3.292682\bin>wish86.exe
(bin) 1 % package require Tkhtml 3.0
3.0
(bin) 2 % join [info loaded] \n
c:/tcl.8600b3.292682/lib/teapot/package/win32-ix86/lib/Tkhtml3.0/
Tkhtml30.dll Tkhtml
{} Tk
C:/Tcl.8600b3.292682/lib/tcl8.6/reg1.3/tclreg13.dll Registry
(bin) 3 %
> Thank you. Leonid
At this point I have to assume that this is something in your setup
which causes this.
Do you have maybe code in ~/tclshrc.tcl and/or ~/wishrc.tcl ?
(Where ~ is your home directory)
Another thing to look at, what are the contents of the
variable ::errorInfo immediately after the failing 'package require'
command ? I.e. please run wish8.6, then
package require Tkhtml 3.0
puts $::errorInfo
It might make sense to switch to email for a quicker turnaround.
Andreas
leonid
> Resolving Tcl 8.4 -is package ... [package Tcl 8.6 _ ... Installed
> outside repository, probing dependencies]
> Resolving Tk 8.4 -is package ... [package Tk 8.6b1.2 _ ... Installed
> outside repository, probing dependencies]
> ... Ok
> Installing into C:/Tcl.8600b3.292682/lib/teapot
> Installing package Tkhtml 3.0 win32-ix86
>
> C:\Tcl.8600b3.292682\bin>wish86.exe
> (bin) 1 % package require Tkhtml 3.0
> 3.0
> (bin) 2 % join [info loaded] \n
> c:/tcl.8600b3.292682/lib/teapot/package/win32-ix86/lib/Tkhtml3.0/
> Tkhtml30.dll Tkhtml
> {} Tk
> C:/Tcl.8600b3.292682/lib/tcl8.6/reg1.3/tclreg13.dll Registry
> (bin) 3 %
>
> > Thank you. Leonid
>
> At this point I have to assume that this is something in your setup
> which causes this.
>
> Do you have maybe code in ~/tclshrc.tcl and/or ~/wishrc.tcl ?
> (Where ~ is your home directory)
>
> Another thing to look at, what are the contents of the
> variable ::errorInfo immediately after the failing 'package require'
> command ? I.e. please run wish8.6, then
>
> package require Tkhtml 3.0
> puts $::errorInfo
>
> It might make sense to switch to email for a quicker turnaround.
>
>
> - Show quoted text -
I am sorry for my mistake. I reinstall tcl and now all works OK. The
problem was in old wish.exe command
Sorry and thank you. Leonid
Georgios Petasis
> ActiveState is pleased to announce the release of ActiveTcl 8.6.0.0
> Beta 3, a beta release of the complete, ready-to-install Tcl
> distribution for Windows, Mac OS X, Linux, Solaris, AIX and HP-UX;
> based on the Tcl/Tk 8.6b1.2 core.
I have just upgraded, and tablelist_tile (obtained through teacup) does
not seem to use ttk (or tile) widgets. It looks strange...
And the problem of tile still getting loading (despite the fact that I
don't have "package require tile" in my code) is still alive...
George
Csaba Nemethi
I have just installed ActiveTcl 8.6.0.0 Beta 3 on Linux. The
distribution includes the last stable version 4.12.1 of the Tablelist
package. For me it works as expected, I couldn't reproduce any of your
problems.
As promised by Jeff a few weeks ago, the file
lib/teapot/package/tcl/teapot/tcl8/8.4/tablelist_tile-4.12.1.tm
no longer loads tile if not needed, and I can confirm that tile is not
loaded, indeed.
I suspect that something is wrong with your ActiveTcl installation.
Also, I don't see any reason for using teacup, because, as said, you
automatically get the latest stable Tablelist version (4.12.1) if you
install ActiveTcl 8.6.0.0 Beta 3.
--
Csaba Nemethi http://www.nemethi.de mailto:csaba....@t-online.de
Georgios Petasis
> Beta 3, a beta release of the complete, ready-to-install Tcl
> distribution for Windows, Mac OS X, Linux, Solaris, AIX and HP-UX;
> based on the Tcl/Tk 8.6b1.2 core.
I think there is a conflict in the Thread package:
Main console display active (Tcl8.6b1.2 / Tk8.6b1.2)
(petasis) 49 % package ifneeded Thread 2.6.5
thread_load C:/TclApps/Tcl/lib/tcl8.6/thread2.6.5
(petasis) 50 % package ifneeded Thread 2.6.6
thread_load c:/tclapps/tcl/lib/teapot/package/win32-ix86/lib/Thread2.6.6
(petasis) 51 % package require Thread
couldn't load library
"c:/tclapps/tcl/lib/teapot/package/win32-ix86/lib/Thread2.6.6/thread265.dll":
this library or a dependent library could not be found in library path
(petasis) 52 % info body thread_load
load [file join $dir thread265.dll]
rename thread_load {}
(petasis) 53 %
(petasis) 54 % cd
{C:\TclApps\Tcl\lib\teapot\package\win32-ix86\lib\Thread2.6.6}
(Thread2.6.6) 55 % load ./thread266.dll
(Thread2.6.6) 56 % package req Thread
2.6.6
(Thread2.6.6) 57 %
I think that the problem is in the re-definition of thread_load. Perhaps
the version should be also be an argument?
George
Georgios Petasis
Dear Csaba,
I am still searching for the problem: it seems to be dependencies among
packages in ActiveTcl. I usually issue a "teacup update" just after
every install. I am not sure if this is a good or a bad thing yet :-)
So, here is the problem I am facing: I have an app that does some stuff,
which never calls "package require tile".
Starting up the application and showing a tablelist widget, works just fine:
http://www.ellogon.org/~petasis/tcl/Images/bugs/tile/tablelist-ok.png
In this image, there are 2 tablelist widgets (on the window left side),
which are drawn correctly.
Then, if I choose to annotate something, the following happens:
1) Tile gets loaded. This has a visual effect on labels (smaller font is
used) and scrollbars (they get thinner).
2) The new window that opens, has tablelist widgets that are not drawn
correctly:
http://www.ellogon.org/~petasis/tcl/Images/bugs/tile/tablelist-ok-not-ok.png
(you can see the tablelist widget on the bottom right corner of the
window on top - Id & Value are simple square boxes).
Closing the app, and restarting it, having as its first line "package
require tile" (yes I know, obsolete in 8.6...), I get this:
http://www.ellogon.org/~petasis/tcl/Images/bugs/tile/tablelist-ok-ok.png
Consistent look of all tablelist widgets. The same happens if I add
"package provide tile 2.0" as the first line in the app.
It seems that this behaviour occurs when at least a tablelist widget has
been created, and then tile gets loaded afterwards. Then any tablelist
widget created after tile was loaded will not be drawn correctly.
I think that is not a tablelist problem, but a problem of tile being
loaded in Tk 8.6. I will check for the package that does that...
Regards,
George
AndreasK
wrote:
Checking the package index in the sources of Thread I have to agree.
Multiple versions of Thread will overwrite each other's thread_load
procedure, allowing for version mismatches to occur, i.e. 2.6.6
actually loading 2.6.5. because that index was read last, per chance.
> Perhaps
> the version should be also be an argument?
In this case the command is so simple that it can be the whole
ifneeded script on its own, without and procedure at all. That is
pretty much the standard for binary packages and it is not clear to me
why Thread deviates.
In the case of more complex load code (like for TTrace below) a
procedure is a necessary eval, at least before we had ::apply (TIP
194). There having the version number or whatever is changing between
version as argument is IMHO the best way of doing things, i.e.
multiple versions still overwrite their procedures, but always with
identical code.
With 8.5+ and ::apply on the other we can separate all version
properly. Wrap the code into a lambda, no need for polluting the
command namespace, yet still complex code, and a local variable scope,
without quoting hell.
I will now endeavor to cleanup the Thread package index.
Andreas
Csaba Nemethi
Hi George,
I am pretty sure that you have the following problem:
Whatever scripts you use for annotation, some of them loads an older
tile version without explicit support for the vista theme. After that
you create a tablelist widget. The Tablelist package uses Ttk style
elements for displaying the header labels. However, the old tile
version that got loaded interferes with the built-in tile engine of Tk,
giving rise to the incorrect rendering of the header labels.
For example, if you load tile 0.7.8 and then create a tile-based
tablelist widget, then the header labels will look like in your 2nd
screenshot (I have just tested this).
Please make sure that your Tcl/Tk installation cannot "see" any old tile
version without explicit support for the vista theme. Alternatively,
find out which one of your scripts invokes an explicit "package require
tile" and remove this command from the script in question.
Best regards
Csaba
George Petasis
> Alternatively,
> find out which one of your scripts invokes an explicit "package require
> tile" and remove this command from the script in question.
>
Dear Csaba,
I have found the package that loads tile, is widget::scrolledwindow.
Doing a simple "package require widget::scrolledwindow" results in tile
being loaded:
C:\Tcl\lib\teapot\package\tcl\teapot\tcl8\8.4\widget\scrolledwindow-1.2.tm
package provide widget::scrolledwindow 1.2
package require widget
package require tile
It seems that almost all widget::* packages just issue a package require
tile.
I hope that we find a way to fix them, as loading tile in 8.5+ is a
little bit adventurus...
Best regards,
George
Jeff Hobbs
> στις 31/5/2010 11:08 μμ, O/H Csaba Nemethi έγραψε:
> > Alternatively,
> > find out which one of your scripts invokes an explicit "package require
> > tile" and remove this command from the script in question.
>
> Doing a simple "package require widget::scrolledwindow" results in tile
> being loaded:
> It seems that almost all widget::* packages just issue a package require
> tile.
Ah, thanks for the analysis. I'll update the widget packages to
qualify the use of package require tile.
> I hope that we find a way to fix them, as loading tile in 8.5+ is a
> little bit adventurus...
Yes, this wasn't the case for quite a while, then things started to
diverge again. I wish they didn't (and it's not always clear why they
do, especially in visually striking incompatible ways), but that's dev
for you.
Jeff
Csaba Nemethi
It is always a potentially bad idea to invoke "package require tile"
from within Tk 8.5 or later, for the following reason:
If you have an older tile version then the "package require tile"
command will load it (if it can "see" it) and several Ttk-related things
will no longer be performed by the built-in tile engine of Tk but by
that older one. George seems to have exactly this problem: Some older
tile version gets loaded and overrides the built-in one. That older
tile engine doesn't support the vista theme, thus giving rise to some
unexpected visual effects related to that theme.
While one can make sure that Tk cannot find any older tile versions, and
(alternatively/additionally) that "package require tile" doesn't get
invoked when the Tk version is 8.5 or later, I still fail to understand
how an *older* tile engine can override the built-in one, which in this
case is guaranteed to be the *most recent* one. This behavior is
totally different from the common package loading mechanism, where an
already loaded package cannot be overridden by an older version of the
same package. *Isn't this a bug in Tk?*
Georgios Petasis
> While one can make sure that Tk cannot find any older tile versions, and
> (alternatively/additionally) that "package require tile" doesn't get
> invoked when the Tk version is 8.5 or later, I still fail to understand
> how an *older* tile engine can override the built-in one, which in this
> case is guaranteed to be the *most recent* one. This behavior is
> totally different from the common package loading mechanism, where an
> already loaded package cannot be overridden by an older version of the
> same package. *Isn't this a bug in Tk?*
>
I think this is easy: the included in Tk package has been renamed to
Ttk. So, the presence of Ttk does not suggest to Tcl that tile cannot be
loaded. So, the tile package that gets loaded is not an older version of
the Ttk package, it is a different package.
George
Csaba Nemethi
You are right, but wouldn't it be possible to instruct Tcl to view the
built-in Ttk "package" within Tk at the same time as tile package? This
would automatically prevent any older tile version from being loaded. I
think this could be done with a small patch of the Tcl or Tk code.
Jeff Hobbs
> Am 01.06.2010 20:58, schrieb Georgios Petasis:
> > στις 1/6/2010 21:47, O/H Csaba Nemethi έγραψε:
> >> While one can make sure that Tk cannot find any older tile versions, and
> >> (alternatively/additionally) that "package require tile" doesn't get
> >> invoked when the Tk version is 8.5 or later, I still fail to understand
> >> how an *older* tile engine can override the built-in one, which in this
> >> case is guaranteed to be the *most recent* one. This behavior is
> >> totally different from the common package loading mechanism, where an
> >> already loaded package cannot be overridden by an older version of the
> >> same package. *Isn't this a bug in Tk?*
>
> > I think this is easy: the included in Tk package has been renamed to
> > Ttk. So, the presence of Ttk does not suggest to Tcl that tile cannot be
> > loaded. So, the tile package that gets loaded is not an older version of
> > the Ttk package, it is a different package.
>
> built-in Ttk "package" within Tk at the same time as tile package? This
> would automatically prevent any older tile version from being loaded. I
> think this could be done with a small patch of the Tcl or Tk code.
8.5+ has actually defined a 'tile' package in the core, v0.8.0. This
was to prevent older versions of tile loading. Since then however,
tile has moved beyond that version, so what you actually get are
_newer_ tile versions that aren't 100% compatible to the core Ttk.
While the C side is ok because symbols were renamed, some of the Tcl-
level names remain the same and can be overwritten.
I would argue that now is the time to disambiguate tile from Ttk at
the Tcl level. This would be an incompatibility for tile users, but
this could be handled with a tile major version shift. Users of tile
v1+ could then more happily coexist with core Ttk. That would be up
to Joe English though, as the tile maintainer. It is a little
backwards (Ttk coopting all the Tcl references), but it helps for
those that had grown used to tile, but now want Ttk (which I think
most are), while disambiguating issues for tile bleeding edge users
(the few?).
Jeff
Georgios Petasis
I am a little surprised that tile gets still developed. Wasn't ttk in
the core the successor of tile?
George