Version 339 of Tcl/Tk 8.6 Roadmap

Updated 2012-12-07 09:48:40 by oehhar

Timing

  • 31 March 2008, Don Porter on tcl-core: The HEAD branch is now aimed for development of 8.6a*.
  • 12 December 2008, Feature set plan finished ? to implement the ones listed below ASAP (excluding new features required to fix important bugs or issues that are related to poor implementation; note that NRE-enabling commands is not a TIPped feature)
  • 23 December 2008, Release of 8.6b1
  • 05 August 2011, Release of 8.6b2
  • 18 September 2012, Release of 8.6b3
  • By/at Tcl 2012 Conference, 8.6.0rc0 (with full 8.6.0 to follow once all contrib packages are non-beta)

Also see:


Implementation Work Roster

TIPs

Projected for after 8.6.0 (they represent co-distributed packages, not Tcl itself in a sense):

In vote:

Link Title Notes

Accepted:

Who Link What Notes
Harald Oehlmann TIP #399 Dynamic Locale Changing for msgcat Likely to be Withdrawn and superseded by TIP #412 (desired functionality is not acheved)

Non-TIP Big Items

  • Improve the Unix version of tk_getOpenFile
    • Important because the old version is looking rather clunky now. (Difficult because it's a lot of work...) Related to TIP #271 but of smaller scope due to desire to keep official script API the same on all platforms. Acting as a testbed for megawidget development in Tk (work planned to be exposed publicly in future releases).

Blocking Bugs/Issues

These are all the current “Priority 9” bugs in the Tcl and Tk trackers, and all should be either fixed or reduced in priority (i.e., marked as not being really blockers) before 8.6.0 is released. Note that just because a bug is assigned to someone doesn't mean that they have to be the person to fix it. It's just formally their responsibility; they can also badger someone else into actually doing it…

Summary

Module Artifact Type Count
Tcl Bug 4
Tcl Patch 0
Tcl FRQ 2
Tk Bug 4
Tk Patch 2
Tk FRQ 0

Detail

Link Module Bug Title Who Categorization
[L1 ] Tcl thread::cancel not reporting error mistachkin semantics
[L2 ] Tcl lappend inconsistency with respect to read traces hobbs semantics
[L3 ] Tcl http::geturl abuses vwait on async call patthoyts
[L4 ] Tcl thread::release on win32 does not release all memory dgp memleak
[L5 ] Tk Crash in open/save file dialog in Windows 7 libraries hobbs crash
[L6 ] Tk Change to grab on windows breaks application behaviour patthoyts semantics
[L7 ] Tk wish8.5 hangs up in tkcvs and nVidia driver. wish8.4 working hobbs portability
[L8 ] Tk Win32 menu keyboard traversal broken tmh portability
Link Module Patch Title Who Categorization
Tcl none
[L9 ] Tk Windows-style Open and Save file dialog on Unix dkf usability/GOOBE
[L10 ] Tk TIP 145: Font handling enhancements pt TIP impl.
Link Module Feature Request Title Who Categorization
[L11 ] Tcl override-able CFLAGS? dgp build
[L12 ] Tcl tag thread tree zv thread as contrib
Tk none

  Comments

LV - 2009-10-28 07:50:11

I don't notice this bug, listed 2762041 , in the list above. Is it too hard, or deemed harmless enough, to not make it into the next release?


dkf - 2009-10-28 10:27:52

It's not too hard, and there's no reason at all to not fix it; we're just not currently planning to block the release until it is fixed. In fact, of the ones above some are probably not release blockers either, and shouldn't be prio9. From the perspective of the roadmap, it is the blocking issues that are critical...


LV - 2009-10-28 12:34:37

Okay, that makes sense. I just was uncertain how the determination of where the bug fixes stop and the release happens worked. Thanks DKF!


dkf - 2009-10-28 17:42:00

Sometimes prio9 bugs come and get fixed so fast they don't have time to show up here (as this list is manually maintained). For example issue#2888044 came and went too fast for me to note...


thomasmenez - 2009-11-30 13:29:00

Why not add SF queries links to have up-to-date bug lists ? And get rid of those 'manually maintained' tables...

Oustanding Tcl prio 9 open bugs

Oustanding Tk prio 9 open bugs

Note : I had to tweak SF URLs a bit (I actually removed the brackets) as this Wiki page was unable to display them correctly. Fortunately, those tweaked SF links still work that way.


dkf - 2009-11-30 08:50:29

The links in the summary table are live, and have been for a while. Or at least they work for me. Part of my reasoning for listing them here is as part of a "naming and shaming" exercise. It helped prompt me to nail a lot of the bugs that had been assigned to myself ...


Martyn Smith - 2010-03-27 10:00:55 Donal is there any particular reason why Schelte Bron's File selection dialog for Tile could not be used as the replacement for tk_getOpenFile, I use is in a few applications and have not had any problems so far ?

Maybe the license is not compatible it says # Copyright (C) Schelte Bron. Freely redistributable. And there does not seem to be a specific license file.


dkf - 2010-03-27 10:53:44

Quite apart from the fact that I'm not keen on having directories separate, I'd like to be able to do things like having a details view so that I can do things like sorting by file mtime.

I'm also taking the opportunity to work on changing the previously-existing megawidgets used to implement the dialog into more robust things. Who knows, the framework that comes out of that might be properly published in 8.7...

Martyn Smith - 2010-03-27 18:55 Have you looked at the little tool menu, I unselected 'Separate Folders' and then selected 'Detailed View' the sort/reverse sort by date and folders first options are also available. It only seems to be missing the click on the titles to change the sort order. Maybe treeview would look good here.

Schelte Bron - 2010-06-10 The license was just slapped on there as suggested by Joe English. Any license that makes it fit for inclusion in Tk is fine with me. I sent the code to Joe for exactly that purpose in the first place.

At the time I started writing the dialogs, ttk::treeview still had several serious shortcomings, especially on unix/linux. That has improved by now, so probably the code could be simplified and/or functionality enhanced by using ttk::treeview.

RLH - 2011-05-31 In a very real sense, does anybody really follow this?

DKF 2011-06-01: Not really. :-(

witek 2012-01-26 it seems 8.6 is approaching asymptotically and never really comes.

APE 2012-03-27 : Did you notice that the 8.6 development started nearly 4 years ago ? It could be great if we can have an update of the schedule to know when it will be available. Thanks !


MG Are there any recent 8.6 Tclkits available? I found a "tclkit86b1.2.exe" for Windows, but it predates the feature I wanted 8.6 for (native/built-in IPv6 support), and I can't find anything more recent. Not sure if anyone is actually building them while 8.6 is still in beta, but if so I'd be very grateful for a link (for Windows and Linux, ideally). Thanks. :)

RLE (2011-06-01) Tclkit Kitgen Build System will build 8.6 Tclkits, but I don't know if the version it builds includes what you desire. On Linux it works quite well, I built some 8.6 tclkits with it a month or so ago and it worked fine once I updated a couple URL's in the script that had changed (unless that has been fixed now). There is also Building Tclkit with kitgen on Windows but I have no input on how well that works as I avoid windows myself.

APN Check out http://www.rkeene.org/devel/kitcreator/kitbuild/nightly/ from Roy Keene for daily builds on multiple platforms.

MG Awesome, thanks for the quick responses, guys.

LV The tip at http://www.tcl.tk/cgi-bin/tct/tip/311 only covers changes through 2010 releases of 8.6. Have any additional tips been implemented in 8.6 since that time? Has there been any discussion regarding freezing features for 8.6.0 and releasing it and doing subsequent work against 8.6.1 and beyond?

DKF: Since it is manually-maintained, it only gets changed occasionally.


HaO: 2012-12-06 Donald Porter posted on MS VC++ build using win/Makefile.vc on the tdbc-devel list:

Empirically you and Jos Decoster are the only folks who complain about ability to build using MSVC (maybe Twylite too?). I imagine your voices represent multitudes, but still those are the only folks I have evidence for caring about nmake builds.

FWIW, I have "negative" care for them. They cause a whole lot of trouble for me getting releases done. I have no reasonable way to test them. Their presence always adds at least an additional RC round if not two or three. I'd be overjoyed to see them tossed overboard.

If the nmake crowd can live with fragile warnings not to build/test in paths with spaces, I'm not going to more effort to overrule that.

Perhaps with 8.6.0 made real by a release, the other crowds who care about nmake builds may show up. We'll see.

HaO: 2012-12-07 Twylite gave on tdbc-devel those two contributions, one to enlight cmake and one to compare build methods:

I'd really like to convince you that CMake should replace NMake for Windows only (thus not 'another').

A cross-platform cmake build by comparison would be 'another' build method to maintain, because I can't see everyone agreeing to drop autoconf.

I've looked at the work that Clifford Yapp has done on a cross-platform CMake build (http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2011/CliffordYapp/tcltk_cmake_paper.pdf) and it's really good, but it tries to shoehorn the Windows build into a Unix model, and in doing so it reproduces a bunch of the complexity and problems of the current (autoconf + NMake) approach.

The build - and particularly the install - needs of Windows are different from *nix.  You _can_ support both in one build system, but when you do you end up complicating the *nix build and getting an un-Windowsy result on Windows.  You also end up with frequent breaks of the Windows build when developers on a *nix platform make non-trivial updates to the build files (and that's a problem in Tcl where there are relatively few developers building on Windows).

The main reason why I started work on a CMake build was to be able to build Tcl extensions.  Tcl went through about a four-year period of chronic build failures on Windows (from 2007 to 2011 I could not once check out HEAD/trunk from Tcl, Tk, Itcl, Thread and get a successful build+install using NMake), and many other extensions had woefully out of date NMake support (or none at all).  I'm no stranger to NMake, but getting an extension building and installing with it is not a task for the faint of heart. Even maintaining an NMake build over time is tricky.

I wanted something that I could easily use to get extensions building, and that would be easy for a non-Windows developer to set up (with a high chance of success).  That is why Coffee (my CMake builds) focuses on _really simply_ CMakefiles and targets Windows only.  The CMakefile feels more like a config.in than a Makefile.in.  You can't achieve that level of simplicity in a cross-platform build.

TL;DR: replace NMake with CMake, then we have the same number of supported build methods, but the build is easier to maintain on Windows and supports more compliers.
> I will not try CMake, as it will not bring us further to the aim.
I agree with that approach, which is why I contributed the attempt at a 
makefile.vc for tdbcodbc.  I would like to see a move to CMake in the 
longer term, but it won't help towards an 8.6.0 release.

> There should be a general decision like:
> 1) we use CMAKE and MSVC++ 6,7,8,9,10 (any set of them)
Yes.  In fact the CMake team made specific changes to support the path 
quoting needed for pkgConfig defines passed in from the build file, 
which require some really weird quoting in MSVC 6 and 8 project files.

> 2) we use NMAKE and MSVC++ 6,7,8,9,10 (any set of them)
What we have now.  Painful to maintain, and doesn't allow Windows users 
to work in the MSVC IDE, use interactive debugging, use third-party 
memory checking tools, etc.

> 3) we use cygwin/msys make and MSVC++ 6,7,8,9,10 (any set of them)
Over the past couple of years the msys installer has been broken on and 
off for months.  It is not acceptable to rely on a technology that is 
not itself reliable.  Using msys also means requiring Windows developers 
to learn how to use a *nix shell prompt, maintain builds using autoconf 
(which is itself a black art), and not use the MSVC IDE and its 
facilities (as mentioned above).  In short it's just keeps Windows as a 
second-class environment for Tcl development.