tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Arnulf W. <ar...@wi...>]

Am Donnerstag 18 März 2010 16:00:33 schrieb Donald G Porter:
> Arnulf Wiedemann wrote:
> > 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 :)
> 
> Thanks!  Will try to test it out today or tomorrow.
> 
> Does it include the changes that got made to the Itcl sources in
> the Tcl repos?  (documentation, I think it was?)
> 
The changes made to fit to the changed interface for some TclOO functions have 
been integrated, I forgot about the docu changes dkf gave me, I will add these 
tomorrow.

Arnulf

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Donal K. F. <don...@ma...>]

On 18/03/2010 17:48, Larry McVoy wrote:
> I personally could care less about IPv6, I believe that NAT solves the
> address problem and the world will come to that realization and we'll
> claw back all those class A blocks but whatever.   I just need a tcl
> that works w/ IPv4 on those old platforms.

There was a piece on slashdot a few weeks back IIRC on how the last
major free blocks have been released for handing out, but what that
really depends on where you are in the world, as the major allocations
are done on a continental scale. It's like to be an issue in Asia fairly
soon. Nobody's quite sure how long North America will be OK. Africa has
oodles of space (internet adoption is relatively slow there) and Europe,
despite being short, will last a long time due to the strictness of the
rules in place[*]. While maybe it's not an issue for you, for others it
most certainly is a problem.

For example, at work we have a problem with running out of addresses for
servers *despite* our using NAT a lot. Some of that is due to local
policies to be sure (no, I don't particularly wish to discuss them) but
even so. Now I happen to know that it might be a while before we can
switch to IPv6, but putting off doing anything about the software that
is in use doesn't help. It takes a long time to roll things out into all
the nooks and crannies.

Donal.
[* I think you can't get a anything as large as a class B any more in
Europe. They're just no longer for sale. ]

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Joe E. <jen...@fl...>]

Jeff Hobbs wrote:
> Reinhard Max wrote:
> > Joe English wrote:
> >> The two oldest machines I have available -- a 2002-vintage Octane
> >> (IRIX 6.5) and a 1997-era AIX box -- both lack getaddrinfo().  Last
> >> I checked, HEAD was still able to build on both of those (with a bit
> >> of coaxing).
> > Hmm - how about a compat/getaddrinfo.c so that we can still support
> > those platforms, but avoid putting back the ifdef'ery and duplicated
> > logic into tclUnixSock.c and friends?
>
> IMO this is a place where we draw the line on Tcl support.  Those are both we
> ll beyond EOL systems by their manufacturers and should have no expectation f
> or IPv6 support.


[ IRIX 6.5 isn't so much EOLed by the manufacturer
  as the manufacturer is EOLed itself, sigh :-( ]

But what the current patch does isn't "no getaddrinfo() => no IPV6",
it's "no getaddrinfo() => no socket support whatsoever".

Reinhard's proposing (and I kinda agree) to completely
replace gethostbyname() / htons() / etc. with calls
to the modern RFC 3493 API.  I think this is a good idea:
kill the #ifdefs.


> I suspect Joe having them is more a curiosity than a busine
> ss need.  Someone actually running those in production just wouldn't update t
> o Tcl 8.6.


Actually no, the Octane box is still in production.
We still have a handful of customers using IRIX,
and we've got a couple on-and-off projects that
require it.

(The AIX box OTOH is mostly for amusement value :-)

I also keep them around because they've got good compilers --
they're useful for detecting portability and other problems that
the GCC/MSVC double monoculture miss.

> We need to spend our time supporting today's systems and to some extent yeste
> rdays, but not yesterdecades.  ;)

Vintage 2002 isn't really all that old for Unix minis.
Those suckers are *reliable*.

That said, I still wouldn't object if mainline Tcl dropped
support for getaddrinfo()less Unices.  I know how to get it
back if I need it.


--Joe English

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Larry M. <lm...@bi...>]

On Thu, Mar 18, 2010 at 10:05:05AM -0700, Jeff Hobbs wrote:
> On 2010-03-18, at 9:57 AM, Reinhard Max wrote:
> > On Thu, 18 Mar 2010 at 17:41, Joe English wrote:
> > 
> >> The two oldest machines I have available -- a 2002-vintage Octane 
> >> (IRIX 6.5) and a 1997-era AIX box -- both lack getaddrinfo().  Last 
> >> I checked, HEAD was still able to build on both of those (with a bit 
> >> of coaxing).
> > 
> > Hmm - how about a compat/getaddrinfo.c so that we can still support 
> > those platforms, but avoid putting back the ifdef'ery and duplicated 
> > logic into tclUnixSock.c and friends?
> 
> IMO this is a place where we draw the line on Tcl support.  Those are
> both well beyond EOL systems by their manufacturers and should have
> no expectation for IPv6 support.  I suspect Joe having them is more
> a curiosity than a business need.  Someone actually running those in
> production just wouldn't update to Tcl 8.6.

We have both of those in our cluster and they find bugs.  And IRIX 6.5.19
supports IPv6.

So putting a change into the tree that doesn't compile on these machines
is kind of a bummer for us.  If there is a way to ifdef it out we can
change our build process to do so.

I personally could care less about IPv6, I believe that NAT solves the
address problem and the world will come to that realization and we'll
claw back all those class A blocks but whatever.   I just need a tcl
that works w/ IPv4 on those old platforms.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Joe E. <jen...@fl...>]

Reinhard Max wrote:
>
> Hmm - how about a compat/getaddrinfo.c so that we can still support
> those platforms, but avoid putting back the ifdef'ery and duplicated
> logic into tclUnixSock.c and friends?

That would be ideal.

It would also be an extremely good idea to scrap all of the
ill-considered HAVE_GETHOSTBYNAME_R_5 vs GETHOSTBYNAME_R_6
vs GETHOSTBYNAME_R_3 vs NEED_COPYHOSTENT vs. .... #ifdeffery;
the compat routine strictly use the classic 4BSD API and
just protect things by a mutex where necessary.


--JE

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Reinhard M. <ma...@tc...>]

Hi,

On Thu, 18 Mar 2010 at 18:05, Jeff Hobbs wrote:

> IMO this is a place where we draw the line on Tcl support.  Those 
> are both well beyond EOL systems by their manufacturers and should 
> have no expectation for IPv6 support.

Well, such a wrapper won't add IPv6 support to those platforms, it 
would just retain IPv4 networking for them.

> Someone actually running those in production just wouldn't update to 
> Tcl 8.6.

Fine with me if that's the consensus.

I only want to avoid that the rest of my work gets rejected just 
because I dropped support for gethostbyname(), so I'd rather provide a 
compat layer, if so desired.

cu
 	Reinhard

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Jeff H. <je...@ac...>]

On 2010-03-18, at 9:57 AM, Reinhard Max wrote:
> On Thu, 18 Mar 2010 at 17:41, Joe English wrote:
> 
>> The two oldest machines I have available -- a 2002-vintage Octane 
>> (IRIX 6.5) and a 1997-era AIX box -- both lack getaddrinfo().  Last 
>> I checked, HEAD was still able to build on both of those (with a bit 
>> of coaxing).
> 
> Hmm - how about a compat/getaddrinfo.c so that we can still support 
> those platforms, but avoid putting back the ifdef'ery and duplicated 
> logic into tclUnixSock.c and friends?

IMO this is a place where we draw the line on Tcl support.  Those are both well beyond EOL systems by their manufacturers and should have no expectation for IPv6 support.  I suspect Joe having them is more a curiosity than a business need.  Someone actually running those in production just wouldn't update to Tcl 8.6.

We need to spend our time supporting today's systems and to some extent yesterdays, but not yesterdecades.  ;)

Jeff

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Reinhard M. <ma...@tc...>]

On Thu, 18 Mar 2010 at 17:41, Joe English wrote:

> The two oldest machines I have available -- a 2002-vintage Octane 
> (IRIX 6.5) and a 1997-era AIX box -- both lack getaddrinfo().  Last 
> I checked, HEAD was still able to build on both of those (with a bit 
> of coaxing).

Hmm - how about a compat/getaddrinfo.c so that we can still support 
those platforms, but avoid putting back the ifdef'ery and duplicated 
logic into tclUnixSock.c and friends?


cu
 	Reinhard

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Joe E. <jen...@fl...>]

Reinhard Max wrote:

> 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.

The two oldest machines I have available -- a 2002-vintage
Octane (IRIX 6.5) and a 1997-era AIX box -- both lack
getaddrinfo().  Last I checked, HEAD was still able to
build on both of those (with a bit of coaxing).

For context: RFC3493 was published in Feb 2003; it looks
like there were only minor changes from RFC2533 (Mar 1999).
(The original specification RFC2133 was published in Apr 1997,
but there were relatively major changes between that one
and RFC2533).

I would not strongly object to dropping support for older
Unices that lack getaddrinfo() (but will note that if we do,
then it's open season on stuff like sgtty/termio support,
the Solaris/Tru64 "strtod" bug, and any mention of MP-RAS
in tcl.m4.)



--Joe English

  jen...@fl...

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Reinhard M. <ma...@tc...>]

Hi,

On Thu, 18 Mar 2010 at 11:51, Arnulf Wiedemann wrote:

> I have built a new version of itcl tagged itcl-4-0b4 in cvs,

itk4.0b4 doesn't built against an installed build of itcl4.0b4, 
because some header files that are referenced by itclInt.h don't get 
installed along with it. Fixed by the first attached patch.

Then, I was getting segfaults from CallItclObjectCmd() when using 
4.0b4 with Tcl HEAD as of yesterday. Fixed by the second attached 
patch.

Then, I found that 4.0b4 breaks [info complete] when used inside a 
method, because the arguments get expanded somewhere along the way:

--- snip ---
package require Itcl
::itcl::class foo {
     public method bar {a} {
 	info complete $a
     }
}
foo myfoo
myfoo bar {bla blubb}
--- snap ---
$ tclsh ./check.tcl
wrong # args: should be "::info complete command"
     while executing
"::info complete bla blubb"
     ("uplevel" body line 1)
     invoked from within
"::itcl::builtin::Info {*}$args"
     (object "::myfoo" procedure "::foo::info" body line 1)
     invoked from within
"info complete $a"
     (object "::myfoo" method "::foo::bar" body line 2)
     invoked from within
"myfoo bar {bla blubb}"
     (file "./check.tcl" line 8)
--- snup ---


cu
 	Reinhard

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Donald G P. <don...@ni...>]

Arnulf Wiedemann wrote:
> 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 :)

Thanks!  Will try to test it out today or tomorrow.

Does it include the changes that got made to the Itcl sources in
the Tcl repos?  (documentation, I think it was?)

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Reinhard M. <ma...@tc...>]

On Thu, 18 Mar 2010 at 14:04, Arnulf Wiedemann wrote:

> do you mean the part in the pkgs directory of tcl head?

no, I never noticed that one.

I mean the Itcl4.0.tar.gz tarball from 2008 that the "Download Now!" 
button on http://sourceforge.net/projects/incrtcl/ links to.

I only now found out that "View all files" shows much newer releases 
and that the tarball mentioned above appears to be a misnamed 8.4a0 
release.

Can you fix "Download Now!" to point to the latest release?


cu
 	Reinhard

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Arnulf W. <ar...@wi...>]

Am Donnerstag 18 März 2010 12:32:26 schrieb Reinhard Max:
> Hi,
> 
> On Thu, 18 Mar 2010 at 11:51, Arnulf Wiedemann wrote:
> > I have built a new version of itcl tagged itcl-4-0b4 in cvs,
> 
> while we are there: How does the CVS content relate to the tarball
> from 2008 that is labelled Itcl4.0?
> 
> cu
>  	Reinhard
> 
do you mean the part in the pkgs directory of tcl head? Itcl4.0b3 from the 
[incr Tcl] SourceForge releases is the one that went into pkgs directory of 
tcl head. Since that time there were mostly bugfixes for Itcl4.0b4

Arnulf

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Donal K. F. <don...@ma...>]

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? ]

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Larry W. V. <lv...@gm...>]

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.

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Twylite <tw...@cr...>]

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

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Kevin K. <kev...@gm...>]

> Pat Thoyts wrote:
>> I reckon we should just jam in the unix ipv6 support and windows can
>> follow later.

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?

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Reinhard M. <ma...@tc...>]

Hi,

On Thu, 18 Mar 2010 at 11:51, Arnulf Wiedemann wrote:

> I have built a new version of itcl tagged itcl-4-0b4 in cvs,

while we are there: How does the CVS content relate to the tarball 
from 2008 that is labelled Itcl4.0?

cu
 	Reinhard

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Twylite <tw...@cr...>]

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

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Arnulf W. <ar...@wi...>]

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)

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Arnulf W. <ar...@wi...>]

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

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Reinhard M. <ma...@tc...>]

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

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Jeff H. <je...@ac...>]

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

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Pat T. <pat...@us...>]

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

Re: [TCLCORE] The Long and Winding Road.. to 8.6.0

[Donald G P. <don...@ni...>]

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 |
|______________________________________________________________________|