tcl-core

[TCLCORE] Patch 2962373 awaiting review: tzdata2010c

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

I've auto-generated the patch for Olson's tzdata2010c
(available from ftp://elsie.nci.nih.giv/). The tables were
generated by the usual automatic process of

    - download and untar the latest tzdata
    - run 'tclsh tools/tclZIC.tcl path/to/tzdata2010c library/tzdata'

Nations affected are Bangladesh, Fiji, Mexico (some locales
near the US border), Paraguay, and the Antarctic bases.

Changes are available at

https://sourceforge.net/tracker/?func=detail&aid=2962373&group_id=10894&atid=310894

(I daresay there's not much to review - it's all numbers.
Probably the most effective review would simply be to run
tclZIC independently and confirm that the numbers match.)

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] Patch 2962373 awaiting review: tzdata2010c

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

Larry McVoy wrote:
> Would it help if I had Damon what you suggest across our cluster?

Not really, in the case of 2962373; it's just running a bog-simple Tcl
script. If two runs get different answers *anywhere*, we've got
far worse problems than anything the patch is doing. I've been
running tclZIC every month or two since 8.5 to keep the time zone
information in sync with Olson's files. It's a completely automated
process, and I'd just commit the results - the way I've been doing
for the last couple of years - except that it seems to have been
decided that proper engineering practice demands pre-commit review.

But, if you've got that huge farm available, it might be worthwhile
to use it to vet the patches for TIP 357.  Let's let them stabilize
before we put Damon through the work, though.

Also, I see that you have Linux-ia64, HPUX-ia64 and SGI on the list.
Could you possibly do a test of 2952904 and verify that it fixes the
issue where an ia64 kernel writes a spurious message to syslog
(about a "floating point software assist fault") on Tcl startup?
I'm certain that the coding change is harmless - it's in a platform
independent path that is exercised in 'make test' - but have no way
to verify that it fixes the bug. (It should have negligible performance
impact, since the changes that it makes are either in straight-line
code in startup, or else affect only the printing of numbers that
have suffered gradual floating-point underflow; surely not a common
case!)

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] Patch 2962373 awaiting review: tzdata2010c

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

On Thu, Mar 04, 2010 at 12:00:26AM -0500, Kevin Kenny wrote:
> Larry McVoy wrote:
>> Would it help if I had Damon what you suggest across our cluster?
>
> Not really [...]

> except that it seems to have been
> decided that proper engineering practice demands pre-commit review.

I missed that memo but I absolutely support it.  And since I whined
about that process it seems appropriate to offer to help.  All whine
and no help makes jack a dull boy :)

> But, if you've got that huge farm available, it might be worthwhile
> to use it to vet the patches for TIP 357.  Let's let them stabilize
> before we put Damon through the work, though.

OK.

> Also, I see that you have Linux-ia64, HPUX-ia64 and SGI on the list.
> Could you possibly do a test of 2952904 and verify that it fixes the
> issue where an ia64 kernel writes a spurious message to syslog
> (about a "floating point software assist fault") on Tcl startup?
> I'm certain that the coding change is harmless - it's in a platform
> independent path that is exercised in 'make test' - but have no way
> to verify that it fixes the bug. (It should have negligible performance
> impact, since the changes that it makes are either in straight-line
> code in startup, or else affect only the printing of numbers that
> have suffered gradual floating-point underflow; surely not a common
> case!)

Yes, we can, but I'll need a little education on your process.  2952904
is checked in or it is a patch somewhere?  I just need to know how to
do what you want.

Also, I'm stewing on an idea here.  Suppose we had CVS installed on
the entire cluster (which I think we do and if not we can).  Suppose
we built a simple batch system where you could specify a tuple

	<head revision>, <patch>, <test>

and we went, checked out that revision, applied the patch, built, and
ran the test and reported back the results.

Leaving aside the security details of a test like

	/bin/rm -rf /

or

	cd where/we/keep/bk/src && tar cf - . | mail git+bzr+hg_guys

would a service like that make any sense?  
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] Patch 2962373 awaiting review: tzdata2010c

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

Larry McVoy wrote:
> Yes, we can, but I'll need a little education on your process.  2952904
> is checked in or it is a patch somewhere?  I just need to know how to
> do what you want.

2952904 is the bug ID at SourceForge, accessible like any other
tracker item. The patch is attached to the bug.

The test is simply to launch a Tcl shell and determine that it
doesn't write to syslog.

(For most patches, the test is to run the test suite; we're
generally quite good about including regression test cases with
our patches where needed. If you see a patch without a test case
it's usually because the existing test suite exposed the bug. The
test suite doesn't take that long to run; most of us routinely run
the whole thing on one or two configurations before committing.)

In this particular case, on the kernel in question, running the
full-up test suite *will* write to syslog, because the test suite
is intentionally exercising the floating-point software assist.
The patch is specifically a change to avoid the annoying message
from a Tcl shell that doesn't use the functionality.

> Also, I'm stewing on an idea here.  Suppose we had CVS installed on
> the entire cluster (which I think we do and if not we can).  Suppose
> we built a simple batch system where you could specify a tuple
> 
> 	<head revision>, <patch>, <test>
> 
> and we went, checked out that revision, applied the patch, built, and
> ran the test and reported back the results.
> 
> Leaving aside the security details of a test like
> 
> 	/bin/rm -rf /
> 
> or
> 
> 	cd where/we/keep/bk/src && tar cf - . | mail git+bzr+hg_guys
> 
> would a service like that make any sense?  

Possibly. It's an idea like the old "SourceForge compile farm;"
we'd perhaps do well, before doing anything like that, to try
to determine what issues killed it, so that our ship doesn't
founder on the same rock.

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] Patch 2962373 awaiting review: tzdata2010c

[Damon C. <da...@tc...>]

> Possibly. It's an idea like the old "SourceForge compile farm;"
> we'd perhaps do well, before doing anything like that, to try
> to determine what issues killed it, so that our ship doesn't
> founder on the same rock.

SourceForge killed the compile farm themselves.  If I recall, it was mainly just a pain for them to manage and it cost more money than it was worth. BitMover will always have its server farm.  It's how we build our software, so there's no chance of it going away.  We do periodically remove nodes from the cluster as we deprecate a platform, but we support a helluva lot of platforms.

That being said, if we could work out the security issues, I think it would be awesome.  For the record, we already compile Tcl / Tk 8.6 on every platform that Larry listed since we ship them with our product.  We've had to make a few small build adjustments over the years as the Tcl maintainers have deprecated platforms before we do, but we still build Tcl/Tk on every platform every time we crank.  We don't run the test suite though that I'm aware of.  I'm pretty sure we run the L test suite, but I don't know if we run the entire Tcl/Tk regressions.

It would be an awesome platform for build and release testing if we can work it all out.  I would love to see an ActiveTcl-style batteries included release in binary form for all the available platforms.  Don't get me wrong, I love ActiveTcl, but there will always be platforms it's not cost-effective for them to support.  I've been asking for FreeBSD for years.

D