Menu
▾
▴
tcl-core
|
From: Donal K. F. <don...@ma...> - 2010-03-16 19:45:39
Attachments:
donal_k_fellows.vcf
|
Hi everyone
I think I speak for just about everyone here when I say that I'd like to
see Tcl 8.6.0. After all, it will have many interesting features and
there's plenty of evidence that it is able to support intensive use
(e.g., the Wiki runs on 8.6). But we seem to be stuck at 8.6b1.1!
What needs to change?
Well, someone (several of us someones in fact) needs to pull their
finger out and get on with it! It's about as simple as that.
More specifically, we need to stop waiting on features before doing
another beta. The features that I see people being interested in are:
TIPs:
#348 on better information about errors
#357 on better ways to handle libraries
#362 on a fix for the [registry] command
Non-TIPs (included for "strategic" reasons which we can discuss):
Add basic IPv6 support (no official API changes)
Add the Thread package to tcl/pkgs/
Make the Unix [tk_getOpenFile] more powerful
(Plus the usual bugfixes, of course.)
What's involved in making a release if we ignore these things? Well, the
HEAD is (usually) buildable from checkout and mostly passes its test
suite so we're not actually that far. Given how much has changed since
8.6b1, I'd actually argue that the best thing we can do now is to make
another beta. Now.
Or at least a release candidate for a beta so that we can check to see
if we build in at least the critical configurations on key platforms.
I'd argue that none of the features above are likely to be worth waiting
a beta on, and the benefit for getting out of our current stasis far
exceeds the cost of not having all the above. (Only build bugs should be
fixed in the period from b2RC1 to b2, so I'd hope that we can make that
very short.)
Once 8.6b2 is out, we can sort the above features out (or explicitly
decide to postpone them) and refocus on getting to the finishing line.
The main point is that we've got to stop messing about. The community
deserves better from us.
Donal.
|
|
From: Donald G P. <don...@ni...> - 2010-03-16 21:04:50
|
Donal K. Fellows wrote: > What's involved in making a release if we ignore these things? I need bundle-able releases of Itcl and tdbc. -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Donal K. F. <don...@ma...> - 2010-03-16 22:14:25
Attachments:
donal_k_fellows.vcf
|
On 16/03/2010 21:04, Donald G Porter wrote: > Donal K. Fellows wrote: >> What's involved in making a release if we ignore these things? > > I need bundle-able releases of Itcl and tdbc. I'd argue that those are not blockers, merely good-to-haves. We really cannot (as a matter of general policy) allow contributed packages to delay a beta release. Donal. |
|
From: Donald G P. <don...@ni...> - 2010-03-16 22:18:57
|
Donal K. Fellows wrote: > On 16/03/2010 21:04, Donald G Porter wrote: >> Donal K. Fellows wrote: >>> What's involved in making a release if we ignore these things? >> I need bundle-able releases of Itcl and tdbc. > > I'd argue that those are not blockers, merely good-to-haves. We really > cannot (as a matter of general policy) allow contributed packages to > delay a beta release. I'm not going to engage this argument and simply take your message as the prod it's intended to be. -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Kevin K. <ke...@ac...> - 2010-03-17 01:23:48
|
Donald G Porter wrote: > Donal K. Fellows wrote: >> What's involved in making a release if we ignore these things? > > I need bundle-able releases of Itcl and tdbc. > Let me know what you need. I keep the "vendor branch" of tdbc in release-worthy condition (although it needs the drivers to be useful). -- 73 de k9etv/2, Kevin |
|
From: Arnulf W. <ar...@wi...> - 2010-03-18 08:43:52
|
Am Dienstag 16 März 2010 22:04:29 schrieb Donald G Porter: > Donal K. Fellows wrote: > > What's involved in making a release if we ignore these things? > > I need bundle-able releases of Itcl and tdbc. > OK, I will try to make a new release of itcl within the next few days, that can be used for being bundled to tcl 8.6b2 Arnulf |
|
From: Arnulf W. <ar...@wi...> - 2010-03-18 10:51:23
|
Am Dienstag 16 März 2010 22:04:29 schrieb Donald G Porter: > Donal K. Fellows wrote: > > What's involved in making a release if we ignore these things? > > I need bundle-able releases of Itcl and tdbc. > Hello Donald, I have built a new version of itcl tagged itcl-4-0b4 in cvs, which can be used for bundling with tcl8.6b2. This is mostly a bugfix release of itcl. Hope that helps to get 8.6b2 forward :) Arnulf (apw) |
|
From: Alexandre F. <ale...@gm...> - 2010-03-16 22:34:18
|
On 3/16/10, Donal K. Fellows <don...@ma...> wrote: > Hi everyone > > I think I speak for just about everyone here when I say that I'd like to > see Tcl 8.6.0. After all, it will have many interesting features and > there's plenty of evidence that it is able to support intensive use > (e.g., the Wiki runs on 8.6). But we seem to be stuck at 8.6b1.1! > > What needs to change? > > Well, someone (several of us someones in fact) needs to pull their > finger out and get on with it! It's about as simple as that. > > More specifically, we need to stop waiting on features before doing > another beta. The features that I see people being interested in are: > > TIPs: > #348 on better information about errors > #357 on better ways to handle libraries > #362 on a fix for the [registry] command > Non-TIPs (included for "strategic" reasons which we can discuss): > Add basic IPv6 support (no official API changes) > Add the Thread package to tcl/pkgs/ > Make the Unix [tk_getOpenFile] more powerful > (Plus the usual bugfixes, of course.) > > What's involved in making a release if we ignore these things? Well, the > HEAD is (usually) buildable from checkout and mostly passes its test > suite so we're not actually that far. Given how much has changed since > 8.6b1, I'd actually argue that the best thing we can do now is to make > another beta. Now. > > Or at least a release candidate for a beta so that we can check to see > if we build in at least the critical configurations on key platforms. > I'd argue that none of the features above are likely to be worth waiting > a beta on, and the benefit for getting out of our current stasis far > exceeds the cost of not having all the above. (Only build bugs should be > fixed in the period from b2RC1 to b2, so I'd hope that we can make that > very short.) > > Once 8.6b2 is out, we can sort the above features out (or explicitly > decide to postpone them) and refocus on getting to the finishing line. > The main point is that we've got to stop messing about. The community > deserves better from us. > > Donal. I don't know exactly for the other items, but please note that #348 is close to being fully baked, only awaiting Don's review. Given this status, it would be very disappointing to let that TIP miss a second chance of contact with beta testers. -Alex |
|
From: Donal K. F. <don...@ma...> - 2010-03-16 22:38:31
Attachments:
donal_k_fellows.vcf
|
On 16/03/2010 18:36, Donal K. Fellows wrote: > TIPs: > #348 on better information about errors > #357 on better ways to handle libraries > #362 on a fix for the [registry] command > Non-TIPs (included for "strategic" reasons which we can discuss): > Add basic IPv6 support (no official API changes) > Add the Thread package to tcl/pkgs/ > Make the Unix [tk_getOpenFile] more powerful For these things, it's probably better if, instead of making any specific commitment to have them in 8.6b2 or not, we instead set a strict timebox on how long we'll wait. Call me impatient if you want, but the community has been waiting for b2 for 16 months now. :-) OK, the specific discussions: #348 and #362 are two TIPs that I just don't have a great feel for one way or the other. They might well be ready right now; I'm too ignorant to be able to say. :-) #357 is very close, and I keep getting surprised that Kevin and Joe can't reach agreement over it. What can the rest of us do to help? IPv6... This is the one we have to deal with. Possibly also back-port to 8.5. The issue is that (if my reading of the runes is right) it won't be very long (year or two) before the IPv4 address space is exhausted in some parts of the world. Getting Tcl ready before the catastrophe strikes is a good thing, especially as it takes time to roll things out into distributions. I'd like the script-level API to be as non-invasive as possible too, please (but only TCP is needed over IPv6; other things are out of scope). Thread package... We've needed this for ages (along with making the threaded build default) so that we can take advantage of modern hardware, and it is a quite thoroughly tested configuration and package, but we keep getting stymied by Expect on Unix. Can we dare to move anyway? Can we tell if Expect needs problem things like [fork]? A lot of expect scripts don't. Unix [tk_getOpenFile]... Oh well, mea culpa. In my defence, it's actually a tricky thing to improve in the ways suggested in the submitted patches. In summary, of these I'd say that two (IPv6 and Thread) are very important due to the changing nature of the environment in which Tcl finds itself; the driving changes are coming whether we change ourselves or not. And #357 would be nice to have too (as it is a blocker for including TDBC drivers with a Tcl distribution). The other three could slip b2 without any great harm, though if they get done that's cool too. I'm not planning to listen to anyone who suggests that we should wait until all prio9 bugs are dealt with. Well, not unless they also work on dealing with the remaining nasty ones... ;-) Donal. |
|
From: Kevin K. <kev...@gm...> - 2010-03-17 01:26:46
|
Donal K. Fellows wrote: > #357 is very close, and I keep getting surprised that Kevin and Joe > can't reach agreement over it. What can the rest of us do to help? Joe and I have reached private agreement. I'm doing his suggested change to make symv on Tcl_LoadFile NULL-terminated, and adding an (unused) 'flags' option so that he can have his RTLD_GLOBAL at some point. We've agreed that the remaining changes aren't needed in the first release. Expect a vote late in the week. -- 73 de ke9tv/2, Kevin |
|
From: Joe E. <jen...@fl...> - 2010-03-17 05:08:48
|
Donal K. Fellows wrote: > OK, the specific discussions: > > #348 and #362 are two TIPs that I just don't have a great feel for > one way or the other. They might well be ready right now; I'm too > ignorant to be able to say. :-) > > #357 is very close, and I keep getting surprised that Kevin and Joe > can't reach agreement over it. What can the rest of us do to help? As I explained to kbk off-list, I have no objections to the TIP as it stands; I just think that the API could be improved. Feel free to ignore if you don't think that the refactoring I proposed is not, in fact, an improvement :-) I certainly did not intend to block the release over this. There was a CFD; I gave my review notes. That's all. TIP#348 r1.10 (-errorstack return option) looks OK to me too. No opinion on TIP#362 (64-bit Registry support). --Joe English jen...@fl... |
|
From: Elchonon E. <cas...@gm...> - 2010-03-17 05:27:36
|
Donal K. Fellows wrote: > Thread package... We've needed this for ages (along with making the > threaded build default) so that we can take advantage of modern > hardware, and it is a quite thoroughly tested configuration and > package, but we keep getting stymied by Expect on Unix. Can we dare > to move anyway? Can we tell if Expect needs problem things like > [fork]? A lot of expect scripts don't. What are the problems with Expect that make threads such a non-option? What options are there for a fix, or a work-around? If there were a good writeup of the issue, a good starting point would be to include a note in the Expect distribution, and possibly have Expect's ./configure issue a warning if you're configuring against a threaded Tcl. While I like Expect, and would very much hate to lose it, I don't think an extension should be able to hold Tcl hostage in the way that it sounds like Expect is doing. My opinion is that you should do what you need to with Tcl. By all means, of course, let Expect know how and why it's being broken, and maybe if what's being broken is important enough, someone will find a way to fix it. In the mean time, if they need it that badly, they'll still be able to make their own non-threaded build, just for Expect, right? -EE |
|
From: Donal K. F. <don...@ma...> - 2010-03-17 09:04:41
Attachments:
donal_k_fellows.vcf
|
On 17/03/2010 05:27, Elchonon Edelson wrote: > What are the problems with Expect that make threads such a non-option? I don't know. To be honest, I don't really grok the innards of Expect enough to be able to say off-hand. However, if you're up to looking then the things to check for are fork() and signal handling; they're known to be problems (due to the notifier and POSIX botches, respectively). Both of those become nastier when there are threads about. I ought to look at the Expect sources sometime so I can argue from knowledge instead of (mainly) ignorance. :-) > What options are there for a fix, or a work-around? If there were a good > writeup of the issue, a good starting point would be to include a note > in the Expect distribution, and possibly have Expect's ./configure issue > a warning if you're configuring against a threaded Tcl. Yes. If fork and signals are just in there "because it is convenient" then it might be better off to say that people wanting them should add a [package require TclX] too. Separation of concerns and all that. > While I like Expect, and would very much hate to lose it, I don't think > an extension should be able to hold Tcl hostage in the way that it > sounds like Expect is doing. My opinion is that you should do what you > need to with Tcl. By all means, of course, let Expect know how and why > it's being broken, and maybe if what's being broken is important enough, > someone will find a way to fix it. In the mean time, if they need it > that badly, they'll still be able to make their own non-threaded build, > just for Expect, right? My big concern with that is that a lot of the deployed uses of Tcl are for Expect, and they tend to be people who are not following what we're doing here closely. Being able to say "oh, you'll need an updated Expect" is one type of story, saying "oh, that doesn't work any more" is a totally different one. Donal. |
|
From: Donald G P. <don...@ni...> - 2010-03-17 13:46:21
|
Donal K. Fellows wrote: > For these things, it's probably better if, instead of making any > specific commitment to have them in 8.6b2 or not, we instead set a > strict timebox on how long we'll wait. The snag for me is that for any new feature, I think it ought to appear in a beta release before 8.6.0 . So if the set of features still desired is not going to be in b2, yet they are still coming to get into 8.6 somehow, then there must be a b3 release and likely will need to be a b4 release. In that scenario, getting 8.6b2 out the door doesn't do a whole lot to accelerate the release of .0. Only getting the features done, or abandoning them will do that. Yes, b2 should go out ASAP for other important reasons (notably delivering the fixes and features already in it), and has been far too long delayed, but the reasoning above explains why "don't release yet" has been such an attractive local minimum. -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Kevin K. <ke...@ac...> - 2010-03-17 02:42:36
|
Donal K. Fellows wrote: > #357 on better ways to handle libraries > #362 on a fix for the [registry] command I'm the TCT member responsible for both of these. And I intend to have both of them voting next week, if someone else can tally (I'm going to be traveling.) They just need fiddly changes. > Non-TIPs (included for "strategic" reasons which we can discuss): > Add basic IPv6 support (no official API changes) > Add the Thread package to tcl/pkgs/ Maybe tdbc::odbc and tdbc::sqlite as well, if we can sort out the dependency issues. The MySQL, Postgres and Oracle native drivers are going to be more work (but can go in post-release, since we've agreed that pkgs/ doesn't need to be tied to the Core release cycle). > Make the Unix [tk_getOpenFile] more powerful > (Plus the usual bugfixes, of course.) > > What's involved in making a release if we ignore these things? Well, the > HEAD is (usually) buildable from checkout and mostly passes its test > suite so we're not actually that far. Given how much has changed since > 8.6b1, I'd actually argue that the best thing we can do now is to make > another beta. Now. +1. Just don't burn out Don! -- 73 de ke9tv/2, Kevin |
|
From: Jeff H. <je...@ac...> - 2010-03-17 21:16:40
|
On 2010-03-17, at 9:20 AM, Pat Thoyts wrote: > Reinhard Max <ma...@tc...> writes: >> On Tue, 16 Mar 2010 at 21:26, Jeff Hobbs wrote: >> >>> [...] but I believe that Reinhard was in process with a variant >>> patch that had "improved" characteristics. >> >> that one got sort of stuck due to the lack of volunteers to test it >> and help fixing/finishing it on non-Linux platforms (or better: my >> lack to find such people). >> > > I've been running Reinhard's ipv6 patch on my site for ages now. It > was solaris and is now linux. And iirc my local linux tclkits are all > using it too so when I go to irc it uses ipv6 magically. > > I reckon we should just jam in the unix ipv6 support and windows can > follow later. No please. The patch I had was 100% cross-platform (from big iron to Windows). I'd like to make sure we don't find that the patch makes us have to make horrible hacks to make it work on Windows. Also, I don't think it will be that hard. Unless I missed an email, Reinhard didn't get a chance to post his latest to the ipv6 bug (e.g. 1782896). I see he's now created a cvs branch for it though, so we can hash this out (though I'm at a conference this week). Jeff |
|
From: Reinhard M. <ma...@tc...> - 2010-03-17 22:22:27
|
Hi, On Wed, 17 Mar 2010 at 22:16, Jeff Hobbs wrote: > The patch I had was 100% cross-platform (from big iron to Windows). > I'd like to make sure we don't find that the patch makes us have to > make horrible hacks to make it work on Windows. as my patch only touches files in the unix subdir and passes the original test suite, I don't see how it should force us into hacks on the Windows side that wouldn't be needed anyways. What my patch does not yet have is a switch to enforce the address family, but that should be easy to add once the low level functionality is there on all platforms. I left that out for now, because my primary goal was to add IPv6 support as transparent and backwards compatible as possible, i.e. with no API changes. BTW, does HEAD still support any unix'ish platform that does not know about stuff like AF_INET6 and getaddrinfo()? I removed the ifdefery to switch between getaddrinfo() and gethostbyname(), because that was easier for the initial implementation, but I would add it back in a second step if it is really still needed. cu Reinhard |
|
From: Jeff H. <je...@ac...> - 2010-03-16 20:26:17
|
On 2010-03-16, at 11:36 AM, Donal K. Fellows wrote: > Non-TIPs (included for "strategic" reasons which we can discuss): > Add basic IPv6 support (no official API changes) This actually has adds one option to 'socket' (-type or -family, depending on what you want to choose), as you need to have support to provide selection of the INET type for key applications. I provided a patch for this that was tested, but I believe that Reinhard was in process with a variant patch that had "improved" characteristics. Jeff |
|
From: Reinhard M. <ma...@tc...> - 2010-03-17 00:00:36
|
Hi, On Tue, 16 Mar 2010 at 21:26, Jeff Hobbs wrote: > [...] but I believe that Reinhard was in process with a variant > patch that had "improved" characteristics. that one got sort of stuck due to the lack of volunteers to test it and help fixing/finishing it on non-Linux platforms (or better: my lack to find such people). cu Reinhard |
|
From: Donal K. F. <don...@ma...> - 2010-03-17 08:50:38
Attachments:
donal_k_fellows.vcf
|
On 16/03/2010 23:42, Reinhard Max wrote: > On Tue, 16 Mar 2010 at 21:26, Jeff Hobbs wrote: >> [...] but I believe that Reinhard was in process with a variant >> patch that had "improved" characteristics. > > that one got sort of stuck due to the lack of volunteers to test it > and help fixing/finishing it on non-Linux platforms (or better: my > lack to find such people). I'm very happy to help review. Point at the patch and I'll see how it looks (and check for buildability/working-ness on OSX, up to the extent that my available IPv6 networking allows). Donal. |
|
From: Pat T. <pat...@us...> - 2010-03-17 19:49:22
|
Reinhard Max <ma...@tc...> writes: >Hi, > >On Tue, 16 Mar 2010 at 21:26, Jeff Hobbs wrote: > >> [...] but I believe that Reinhard was in process with a variant >> patch that had "improved" characteristics. > >that one got sort of stuck due to the lack of volunteers to test it >and help fixing/finishing it on non-Linux platforms (or better: my >lack to find such people). > I've been running Reinhard's ipv6 patch on my site for ages now. It was solaris and is now linux. And iirc my local linux tclkits are all using it too so when I go to irc it uses ipv6 magically. I reckon we should just jam in the unix ipv6 support and windows can follow later. -- Pat Thoyts http://www.patthoyts.tk/ PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD |
|
From: Twylite <tw...@cr...> - 2010-03-18 11:13:07
|
Pat Thoyts wrote: > I reckon we should just jam in the unix ipv6 support and windows can > follow later. Please, no! A huge amount of Tcl's value is in its ability to run cross-platform. Windows developers (of Tcl) are already marginalised by the atrociously Windows-unfriendly GNU build system. We can do without marginalising Windows users (of Tcl for development) on functionality as well. Regards, Twylite |
|
From: Twylite <tw...@cr...> - 2010-03-18 12:42:04
|
Hi, Kevin Kenny wrote: > Twylite wrote: >> Please, no! A huge amount of Tcl's value is in its ability to run >> cross-platform. Windows developers (of Tcl) are already marginalised >> by the atrociously Windows-unfriendly GNU build system. We can do >> without marginalising Windows users (of Tcl for development) on >> functionality as well. > Listen to yourself: "If I can't have it on Windows, then nobody > should have it, so the Unix support (which is already done) will > just have to wait." Is that the sort of attitude that should > govern the developers? It is normal for software distributions to identify officially supported platforms, and to provide releases with identical (or equivalent) functionality on all officially supported platforms at the same time. To my knowledge the Tcl core has in the past followed this approach, and I am advocating that it continues to do so. Further, I understood from Reinhard's and Jeff's posts that there isn't a major technical impediment to Windows support. I don't see a problem with putting ipv6 support for unix only into a beta release (to allow it to gain widespread testing), but I do think that any decision to roll out a final release with core functionality that supports a subset of the official platforms needs a strong _technical_ justification. Regards, Twylite |
|
From: Larry W. V. <lv...@gm...> - 2010-03-18 12:58:37
|
Perhaps it would be best to release Tcl 8.6 without the IPv6 support, so that the rest of the functionality becomes available. Then aim towards a Tcl 8.7 release that has the IPv6 in it, if those working on it can get it done within a reasonable time frame. |
|
From: Donal K. F. <don...@ma...> - 2010-03-18 13:19:43
Attachments:
donal_k_fellows.vcf
|
On 18/03/2010 12:41, Twylite wrote: > It is normal for software distributions to identify officially supported > platforms, and to provide releases with identical (or equivalent) > functionality on all officially supported platforms at the same time. > To my knowledge the Tcl core has in the past followed this approach, and > I am advocating that it continues to do so. > > Further, I understood from Reinhard's and Jeff's posts that there isn't > a major technical impediment to Windows support. Since the plan seems to be to get the IPv6 support working for Windows as soon as possible, I'm not going to beat anyone up over it. Whether it makes the cut for b2 is separate, but we don't need to panic over that. What is important is that we get b2 done soon, and that we get IPv6 support (by which I mean for _all_ key target platforms[*]) in by the time 8.6.0 escapes^Wis released. (To LWV: I doubt that 8.7 could be done by the point it gets critical; I just don't think we can push out a release that fast.) Donal. [* Single platform stuff can always be done in an extension, yes? ] |
Thanks for helping keep SourceForge clean.
X