tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] tcludp

[T. H. <ts...@mr...>]

I've got the ActiveTcl8.6.0 kit installed on a windows box
and I need to install tcludp as well. What would be the recommended
procedure for this? I havent so far found a windows binary of tcludp,
so if I have to build my own, should I install Cygwin to do this,
or should I use the windows native C-compiler, or a windows gcc if
I can find one...
I wonder how the windows ActiveTcl8.6.0 itself was built?

Thanks,
Terry

[TCLCORE] How to deal with Tracker Spam

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

This is a short note to all Tcl and Tk maintainers that describes how to
deal with the insidious scourge that is spam in our issue trackers.

It is a well-known problem that a spammer won't stop. They're scum.
Therefore when dealing with tracker spam, it is important to squelch the
issue completely so that it isn't possible (for a non-maintainer) to add
to the junk pile or for search engines to index it.

To do this, you need to use several steps (which you can do in one
change, fortunately):

  1: Move the issue to the Support Requests tracker (which invalidates
     existing URLs to the issue and stops non-maintainers from creating
     new URLs to it)
  2: Mark the issue as private (stops non-maintainers from reaching the
     issue if they don't have its URL — in combination with 1, this makes
     the issue useless as spam)
  3: Mark the issue as Deleted (so its out of our face anyway!)

You don't need any kind of resolution; you're kicking it out of the
park, not dealing with it. :-)

There is one other thing we could do — preventing people from submitting
issues if they aren't logged into SF — but that would lock out too many
people in the community from doing bug reports, and I'd rather have more
bug reports and spam than the alternative. I hope you agree.

Donal.

[TCLCORE] Tcl 2008 Conference Contacts

[Tomasz K. <tk...@gm...>]

I have finally resent contacts gathered during last year Tcl /Tk
conference (http://purl.org/net/tcl-2008-tk).
All interested folks, please check you spam filter for a message from
tk...@gm....

Regards,
Tomasz Kosiak

[TCLCORE] profiling C code run under Tcl

[Randy W. <ar...@fa...>]

Greets:

I found a few posts about using gprof under Tcl in this user group dated 2005 but didn't see anything there that answered my question.

My question: how do you get a gprof gmon file to be produced when you compile C code and run it under a Tcl script? I know the problem is due to the C code having been compiled and loaded as a shared library (which doesn't exit the way gprof requires therefore no profiling dump file). What do you do precisely to work around this?  I am presently 1)fumbling with trying to get C code to compile statically and be loaded that way (and shutdown while still in that static C code thus triggering the profiling dump) and 2)throwing away the top level Tcl script and rewriting the C code to be standalone with a bare-bones startup main routine.  Problem with that is, the C code is GL graphics and the Togl widget I use (avail on the net) sets up the graphics environment. No Togl in the bare-bones startup means no graphics calls, no graphics calls means the C data structures aren't set up right, therefore bad profiling results. 2) isn't the ideal way to do this anyway.  Thanks for any suggestions you might have.  The TclDevKit I got from activestate will profile the top level Tcl code, will give black box profile information on the Togl calls, but I need to get the low level GL C code to run much faster.  I'm suspect that what I need to know is the exact options to feed the gcc linking call in my makefile.

r wolf

Re: [TCLCORE] a comment with regard to the fix of bug 2494093

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

WANGNICK Sebastian wrote:
> I for one am happy that this issue is not hidden in the Tracker ...

FWIW (and for those who don't know this already) this is really just bug
219196 - yes, it's an old one - in another guise. I plan to tackle it
properly when we drop the ABI/API full compatibility promise for 9.0,
but the changes required are far too messy to do before then. The issue
is really that Tcl mixes up between 'int' and 'long' and 'size_t' and
many other integer-ish types in many places, and sometime that Augean
Stable must be cleaned. Everything done before then is merely marking
time...

Donal.

Re: [TCLCORE] a comment with regard to the fix of bug 2494093

[WANGNICK S. <seb...@eu...>]

I for one am happy that this issue is not hidden in the Tracker ...

-----Original Message-----
From: Donald G Porter [mailto:dg...@NI...] 
Sent: Wednesday 14 January 2009 23:48
To: Matthias Kraft
Cc: tcl-core
Subject: Re: [TCLCORE] a comment with regard to the fix of bug 2494093

Matthias Kraft wrote:
> I want to give two points to your attention that concern me with the 
> fix of bug 2494093 ...

The right place to raise these concerns is on Ticket 2494093 in the Tcl
Bug Tracker.  Re-open if need be.
____

This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.

Any views expressed in this message are those of the sender.

Re: [TCLCORE] a comment with regard to the fix of bug 2494093

[Donald G P. <dg...@NI...>]

Matthias Kraft wrote:
> I want to give two points to your attention that concern me with the fix
> of bug 2494093 ...

The right place to raise these concerns is on Ticket 2494093 in the
Tcl Bug Tracker.  Re-open if need be.

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

[TCLCORE] a comment with regard to the fix of bug 2494093

[Matthias K. <ma...@us...>]

Hi everybody,

I want to give two points to your attention that concern me with the fix
of bug 2494093 (buffer overflow in AppendUnicodeToUnicode() ->
SEGFAULT). But first thank you very much for helping to find the problem
and then fixing it promptly!

1) The fix as now implemented restricts the content of variables to
  INT_MAX/4 which is 512MB! To my mind this is comparatively small and
  should be documented somewhere. Please notice that this is also half
  the size, of what was possible in 8.4.19 / 8.5.6.

2) In tclStringObj.c is a lengthy documentation of the memory allocation
  algorithm for strings. This is now obsolete in the case when more than
  INT_MAX/4 memory is free and could be allocated. As in this case we
  panic() before even coming to the attemptckalloc().

What you should make with this information? Well, I don't know. I just
wanted to make sure it doesn't get lost and someone has to learn it the
hard way. I can live with the fix now.

Where is the use case that needs so much memory? Consider vfs::memchan.
This is where I stumbled over the issue. I thought I use vfs::memchan to
be able to transparently uncompress and evaluate the crc of archives...

kind regards
-- Matthias Kraft

[TCLCORE] Maintaining bundled packages

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

With tdbc and itcl now bundled, developers of core Tcl are going to
encounter their bugs more frequently, and with luck discover and
contribute fixes.  That's great!

However, it would be most helpful to me and I believe to the upstream
developers of these packages to contribute those fixes upstream, and
not by committing fixes to the directories in our repository that import
upstream releases.

I really don't want to be in the position as release manager of deciding
what local patches do and do not go into our releases, and whether
having our own customizations demands a new version number or package
name or other relabeling.  I just want to take what upstream gives and
send it back out again.

One way to structure your sandbox so that you won't mistakenly commit
patches to the Tcl repos is to checkout the "tcl-only" module and then
fill the tcl/pkgs directory of your sandbox from the upstream sources.
Then you can arrange to be working off the "HEAD" of everything.

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

[TCLCORE] test - please ignore

[Frédéric B. <fre...@fr...>]

My latest message (posted on 20090112) didn't show up yet but is visible 
on the archive page @ sourceforge.net

[TCLCORE] TIP 50: Final

[<dg...@ni...>]

I've just imported the source code for
Itcl 4.0b2 into our cvs repository as
the new module "itcl".  I've also revised
the "pkgs" module to include it, so now
fresh checkouts of the "tcl" modules will
include it in the pkgs directory as a
bundled package.  (The "tcl-only" module
should be unchanged).

I think this completes TIP 50.

Big thanks to Arnulf Wiedemann for the
work getting things ready.

DGP

[TCLCORE] Ropes

[<fre...@fr...>]

Hi all,

First, happy new year!


Following the discussions we've had a while back about string representations, Unicode, Tcl9, Cloverfield and the like, I've been working during the past weeks on a rope package. You can find it here on the Tcl9 project on Sourceforge:

http://sourceforge.net/project/showfiles.php?group_id=216988

The implementation is a materialization of several ideas I've developed over the years, with some borrowed from the seminal paper on Cedar Ropes by Hans Boehm et. al., available here:

http://www.cs.ubc.ca/local/reading/proceedings/spe91-95/spe/vol25/issue12/spe986.pdf

Ropes are string structures where data is not stored in flat NUL-terminated arrays but in self-balancing binary trees, allowing for fast insertion/removal of arbitrarily long strings. The package is built around a dedicated memory allocator based on fixed-size cells, coupled with a generational, exact, mark-and-sweep garbage collector.


Data structures:
================
Ropes are made of chunks of Unicode string data that can use either fixed-width formats (native C strings, UCS 1, 2 or 4 bytes) or UTF-8. Such string data chunks can take a variable number of cells; if the provided data is larger than the maximum size (here 63 cells, i.e. 1008 bytes minus the 4 or 8 byte header), it is split into several chunks and assembled transparently. Ropes can be made of chunks having different representations, thus allowing maximum compacity when mixing e.g. typically 7-bit Tcl code and foreign language data. Moreover, native NUL-terminated C strings are recognized as valid ropes from C code. 

Basic string chunks are assembled by concatenation to form larger ropes. Small strings are transparently merged into flat leaves, whereas larger ones use a self-balancing binary tree made of concat nodes. Substrings can also be extracted, and form either flat leaves for the smallest ones, or use a substr node for larger ones. The combination of both techniques allows for easy handling of arbitrarily large strings with minimal duplication and maximal sharing of raw string data.

Apart from strings, all nodes are designed to fit into one single cell, thus providing maximum allocation performances and minimal memory impact.

Indexing is O(1) for flat fixed-width ropes, O(n) for UTF-8 (as with Tcl), and O(logn) in general for complex ropes. The fact that basic string chunk size is limited also means that very large UTF-8 strings have better performances than flat UTF-8 strings (such as those used by Tcl) thanks to the intermediary indexing levels.


Memory management:
==================
The dedicated memory allocator is based on fixed-size cells (16 bytes on 32-bit architectures) within page-aligned memory. Each page contains a bitmask that indicates the cell status. For 1024-byte pages, this gives 64 16-byte cells, of which one is reserved. This results in a very small overhead (2 bit per cell) and a very good memory locality, both improving the performances dramatically (more on that below) on modern architectures compared to a traditional allocator (which typically uses linked list structures). This choice has been made because, with the exception of pure string data, rope nodes are typically small and easily fit within a 16-byte cell.

Moreover, this allocator is coupled with a generational, exact (as opposed to conservative), mark-and-sweep garbage collector that again provides a huge speedup compared to manual free() calls. The only needed action is root declaration for all ropes that are externally referenced, using a simple reference counting scheme. The GC process is fully controllable in the sense that sections of code can be protected by pausing and resuming the automatic collection. Generational GC means that older ropes (having survived several GC cycles) are promoted to older pools that are collected less frequently; this limits the CPU impact of collections.


Other features:
===============
The package provides iterator structures and procedures, so porting existing code should be easy. I'm thinking especially about the regexp engine, which needs flat Unicode strings. Iterators abstract the whole stuff into a random-access model. Direct traversal of the string is O(1).

A custom rope is available for extensions. Typical use would be for example memory-mapping of potentially very large datasets, even on memory-constrained systems (e.g. mobile platforms). Another use case would be programmatically generated data. Or it could be used to wrap malloc'd strings into ropes.


Connections with Tcl:
=====================
Tcl currently uses UTF-8 flat strings as its string representation. There have been some discussions about the format that future versions should use. One such proposal was augmented strings, where flat strings would be supplemented by additional information (indexing of UTF-8 strings for instance). Another concern was memory consumption needed for the support of UCS4 (32-bit chars).

I think ropes provides a good solution to all this problems. Ropes are immutable strings, which fit the Tcl model perfectly. One can mix several formats transparently, making byte arrays unnecessary and removing a prominent cause of shimmering. And as complex types such as lists build their string representations from those of their elements, maximum reuse of existing strings is ensured and limits the memory impact even further. Last, the impact on client code is minimal thanks to the automatic garbage collector and the backward compatibility with C strings. For these reasons I think that ropes would be a good choice as a native string representation for future versions of Tcl.


Performances:
=============
Of course there are lies, damn lies and benchmarks, but the first performance test I've run on my system are very satisfactory.

On a Core 2 Duo P8400 2.26GHz WinXP SP3 with 2GB RAM I get the following results (from test.c):
(figures in ms)

---------------------------------------------------------------------
testAlloc: ropes vs. malloc raw allocation performances

Ropes: 40000000 12-byte ropes = 480000000 data bytes ...
        1859 create + 610 GC = 2469
malloc: 40000000 12-byte C strings = 480000000 data bytes ...
        6718 malloc + memcpy + 7922 free = 14640

Ropes: 20000000 28-byte ropes = 560000000 data bytes ...
        1453 create + 625 GC = 2078
malloc: 20000000 28-byte C strings = 560000000 data bytes ...
        3813 malloc + memcpy + 3828 free = 7641

Ropes: 15000000 44-byte ropes = 660000000 data bytes ...
        1375 create + 703 GC = 2078
malloc: 15000000 44-byte C strings = 660000000 data bytes ...
        3016 malloc + memcpy + 2953 free = 5969*

Ropes: 1000000 1000-byte ropes = 1000000000 data bytes ...
        1062 create + 1000 GC = 2062
malloc: 1000000 1000-byte C strings = 1000000000 data bytes ...
        1047 malloc + memcpy + 391 free = 1438
---------------------------------------------------------------------

This shows that the allocator+GC performs usually faster than malloc+free, mostly because of the GC performances compared to free(). The malloc version outperforms the ropes only in the case of a large number of large strings. So this benchmark shows the real benefits of automatic memory management even on the simplest cases; in the general real-world case where a lot of small structure are allocated and freed during the lifetime of the application, the malloc version would perform closer to the worst case above, and maybe worse because of memory fragmentation.

The following test is closer to a real world application: it runs several (10,000) cycles during which 80 large strings are allocated and preserved. 

---------------------------------------------------------------------
testGeneration:

With all ropes preserved:
10000 x 80 988-byte ropes + roots = 790400000 data bytes : 16953

With no more than 10000 ropes preserved:
10000 x 80 988-byte ropes + roots = 790400000 data bytes : 4406
---------------------------------------------------------------------

This shows the generational properties of the GC: older ropes will be promoted to older pools and thus traversed less often by the collector.

A real world application during its lifetime would typically store a fairly constant number of stable objects (global or static data, business models) and allocate a larger number of short-lived objects (input, output and temporary values). Generational GC ensures that the latter get collected more often than the former, and let stable objects percolate to deeper layers.


Conclusion:
===========

The package needs some polish (test suite, docs, etc.) but I think the code is fairly usable in its current state. At present it only works on 32-bit architectures, but a port to 64-bit should be straightforward. Moreover, as the custom allocator needs page-aligned memory, I've only implemented a Win32 version based on VirtualAlloc(). Posix systems would need posix_memalign() or something more suitable to get the same result (it uses a 1024-byte boundary on 32-bit systems).

I plan to design a similar package but for objects, especially lists since they are very similar to strings, and integrate both closely.

Comments welcome!

Re: [TCLCORE] ANN: TDBC drivers available as Win32 binaries

[Kevin K. <ke...@ac...>]

Kevin Kenny wrote:
> Because building TEA modules on Windows is problematic for so many
> people, I've packaged pre-built binaries of the packages:
> 
> tdbc::mysql
> tdbc::odbc
> tdbc::sqlite3
> 
> for 32-bit Windows.  They are available from SourceForge at:
> 
> https://sourceforge.net/project/showfiles.php?group_id=10894&package_id=305160&release_id=651729
> (or http://preview.tinyurl.com/7j8zws)

The buggy INSTALL.tcl script in the release ZIP has now been corrected.

--
73 de ke9tv/2, Kevin

[TCLCORE] ns-2

[sandeeph <san...@gm...>]

hi may i know how to read the packet from the trace file using awk
programming in ns-2
-- 
View this message in context: http://www.nabble.com/ns-2-tp21367195p21367195.html
Sent from the tcl-core mailing list archive at Nabble.com.

Re: [TCLCORE] [Tcl-bugs] tcl-cvs: "tcl/unix configure.in" modified

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

Jan Nijtmans wrote:
> 2009/1/5 Joe English wrote:
>>> Many Unices replace or augment Tcl's `make install-manpages`
>>> rules anyway to account for local conventions.
> 
> I don't think that starting to use autoconf 2.63 or later (2.61 is
> a bad idea) would be really a problem, but it should be considered
> a new Tcl feature that the 'default Tcl installation conforms
> to the FHS standard'. I think it requires a TIP, and it should
> be prominently mentioned in the docs and installation notes.
> For Tcl 8.6 I don't see enough reasons to d,, since
> Tcl doesn't depend on any autoconf 2.61+ features and
> the TIP deadline already passed.
> But for Tcl 8.7 it should be considered again (IMHO).
> 
> Anyway, thanks for the reactions. Now I know why
> upgrading autoconf is a bad idea for now.

It is always fraught with difficulty because the maintainers change 
things in very odd ways given their versioning system.  However, I would 
recommend not expecting to maintain ac 2.61 through the 8.6 timeline. 
Experience has shown that it becomes very difficult to try and stick 
with a particular version as the default installed versions change out 
from under us.

Jeff

Re: [TCLCORE] [Tcl-bugs] tcl-cvs: "tcl/unix configure.in" modified

[Jan N. <nij...@us...>]

2009/1/5 Joe English wrote:
>> Many Unices replace or augment Tcl's `make install-manpages`
>> rules anyway to account for local conventions.

I don't think that starting to use autoconf 2.63 or later (2.61 is
a bad idea) would be really a problem, but it should be considered
a new Tcl feature that the 'default Tcl installation conforms
to the FHS standard'. I think it requires a TIP, and it should
be prominently mentioned in the docs and installation notes.
For Tcl 8.6 I don't see enough reasons to d,, since
Tcl doesn't depend on any autoconf 2.61+ features and
the TIP deadline already passed.
But for Tcl 8.7 it should be considered again (IMHO).

Anyway, thanks for the reactions. Now I know why
upgrading autoconf is a bad idea for now.

Regards,
         Jan Nijtmans

Re: [TCLCORE] Build problem with 8.6b1 on XP if dirs have whitespace

[Jan N. <jan...@gm...>]

2009/1/5 Ashok P. Nadkarni <apn...@ya...>:
> My questions are - is this known/expected behaviour or should I log a
> bug? If the former, is there a way to check for whitespace and exit with
> a more appropriate error message so folks like me don't spend half the
> afternoon trying to figure out what's wrong? I couldn't figure out how
> one might do this within NMAKE's very limited capabilities.

Yes, I think this is worth to file a bug for it. Pat Thoys is more an
expert in this than I am, but my recommendation would be to
revert this change in makefile.vc (unless Pat has a better solution)

Regards,
        Jan Nijtmans

[TCLCORE] ANN: TDBC drivers available as Win32 binaries

[Kevin K. <ke...@ac...>]

Because building TEA modules on Windows is problematic for so many
people, I've packaged pre-built binaries of the packages:

tdbc::mysql
tdbc::odbc
tdbc::sqlite3

for 32-bit Windows.  They are available from SourceForge at:

https://sourceforge.net/project/showfiles.php?group_id=10894&package_id=305160&release_id=651729
(or http://preview.tinyurl.com/7j8zws)

To install them, download the file 'tdbc1.0b6-win32-drivers.ZIP'.
Extract this file in a convenient place, and use 'wish8.6' to run the
script, 'INSTALL.TCL' inside the folder that's created.  All the
necessary files should be copied to your Tcl 8.6 installation.

I hope this gives many more people the opportunity to start testing
TDBC.

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] [Tcl-bugs] tcl-cvs: "tcl/unix configure.in" modified

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

Joe English wrote:
> Donal K. Fellows asked:
>> (Rhetorical question: Why doesn't autoconf provide a way to configure
>> what the default @datarootdir@ is?)
> 
> You can specify --datarootdir at configure-time:
> "sh ./configure --datarootdir=...".
> 
> Default is ${prefix}/share; ${prefix} in turn can be
> specified with "--prefix=...", and defaults to /usr/local.
> You can also specify a different --mandir (defaults
> to ${datarootdir}/man == ${prefix}/share/man).
> 
> Many Unices replace or augment Tcl's `make install-manpages`
> rules anyway to account for local conventions.
> Debian for instance installs a gzipped soelim'ed copy of
> tcl/doc/$foo.n in /usr/share/man/man3/foo.3tcl.gz;
> IRIX stores a preformatted pack(1)ed copy in
> /usr/share/catman/u_man/cat3/Tcl/[string tolower $foo].z.

You missed my point. By *default*, $datarootdir is $prefix/share and (so
far as I can see) there is no way to change that default so that what
people get without specifying --datarootdir= is something that follows
the old conventions. (You can specify the default $prefix, but not the
default rules for deriving things from it; indeed, at least in autoconf
2.61 those rules are hard-coded in the system general.m4 so they
definitely can't be set easily. You'd have to post-process the configure
file itself with sed, and I don't think there's rules for doing that...)

Donal (it's not every day I complain about default defaults...)

Re: [TCLCORE] [Tcl-bugs] tcl-cvs: "tcl/unix configure.in" modified

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

Donald G Porter wrote:
> Jan Nijtmans wrote:
>> Are there other arguments pro or contra specific autoconf versions?
>
> Some version post 2.59 has changed the default mandir, which changes
> the default place where Tcl installs man pages.

See: http://www.gnu.org/software/autoconf/manual/html_node/Changed-Directory-Variables.html

It was changed to match the FHS standard, which specifies
that manpages go under /usr/share/man instead of the traditional
/usr/man.  (I don't know when FHS started gaining widespread
adoption, but from a quick look at the 1997 vintage Unices I still
have available it looks like the move from /usr/man to /usr/share/man
had started by then).

Donal K. Fellows asked:
>
> (Rhetorical question: Why doesn't autoconf provide a way to configure
> what the default @datarootdir@ is?)

You can specify --datarootdir at configure-time:
"sh ./configure --datarootdir=...".

Default is ${prefix}/share; ${prefix} in turn can be
specified with "--prefix=...", and defaults to /usr/local.
You can also specify a different --mandir (defaults
to ${datarootdir}/man == ${prefix}/share/man).

Many Unices replace or augment Tcl's `make install-manpages`
rules anyway to account for local conventions.
Debian for instance installs a gzipped soelim'ed copy of
tcl/doc/$foo.n in /usr/share/man/man3/foo.3tcl.gz;
IRIX stores a preformatted pack(1)ed copy in
/usr/share/catman/u_man/cat3/Tcl/[string tolower $foo].z.



--Joe English

Re: [TCLCORE] [Tcl-bugs] tcl-cvs: "tcl/unix configure.in" modified

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

Donal K. Fellows wrote:
> Yes, that does mean that a rebuild of 'configure' before release is
> indeed a good idea...

Just for the record, this is part of the `make dist` target.

(Thanks to das, IINM).

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

Re: [TCLCORE] [Tcl-bugs] tcl-cvs: "tcl/unix configure.in" modified

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

Daniel A. Steffen wrote:
> On Mon, Jan 5, 2009 at 13:09, Jan Nijtmans <jan...@gm...> wrote:
>> 2009/1/3 Daniel A. Steffen <da...@us...>:
>>> (in particular compatible with autoconf 2.61, which some insist on using even though it was decided we could not switch to it yet...)
> 
> to clarify, the fix in question was for compatibility with 2.61 _and
> later_, I wasn't advocating using 2.61 specifically.
> Last time we discussed updating past autoconf 2.59, there was
> opposition to the idea (c.f. bug tracker, re uintptr_t detection
> IIRC).
> FWIW I'm perfectly happy to stay at 2.59, it's trivial to install it
> locally if your system only has a later version...
> what I would like to see however is that everybody stick to the
> version we decide on, if you look at the recent history of
> tcl/unix/configure, it is full of 2000 line diffs from repeated
> back-and-forth between 2.61 and 2.59...

Generally speaking, configure is a generated file and so should never be
edited directly anyway, so big diffs aren't a big problem...

But I admit I'm probably responsible for quite a bit of the use of 2.61,
mostly because I've lost access to the machines I was using that had
2.59 on them. (Theoretically I can get onto others, but I've yet to
identify which to switch to; our clusters are rather complex...) I
operate on the principle that, most of the time, it's better to have a
fix at all rather than to leave broken for want of the exact version.
Yes, that does mean that a rebuild of 'configure' before release is
indeed a good idea...

(Rhetorical question: Why doesn't autoconf provide a way to configure
what the default @datarootdir@ is?)

Donal.

Re: [TCLCORE] [Tcl-bugs] tcl-cvs: "tcl/unix configure.in" modified

[Daniel A. S. <da...@us...>]

On Mon, Jan 5, 2009 at 13:09, Jan Nijtmans <jan...@gm...> wrote:
> 2009/1/3 Daniel A. Steffen <da...@us...>:
>> (in particular compatible with autoconf 2.61, which some insist on using even though it was decided we could not switch to it yet...)

to clarify, the fix in question was for compatibility with 2.61 _and
later_, I wasn't advocating using 2.61 specifically.
Last time we discussed updating past autoconf 2.59, there was
opposition to the idea (c.f. bug tracker, re uintptr_t detection
IIRC).
FWIW I'm perfectly happy to stay at 2.59, it's trivial to install it
locally if your system only has a later version...
what I would like to see however is that everybody stick to the
version we decide on, if you look at the recent history of
tcl/unix/configure, it is full of 2000 line diffs from repeated
back-and-forth between 2.61 and 2.59...

Cheers,

Daniel

-- 
** Daniel A. Steffen                   **
** <mailto:da...@us...>  **

Re: [TCLCORE] [Tcl-bugs] tcl-cvs: "tcl/unix configure.in" modified

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

Jan Nijtmans wrote:
> Are there other arguments pro or contra specific autoconf versions? 

Some version post 2.59 has changed the default mandir, which changes
the default place where Tcl installs man pages.

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

Re: [TCLCORE] [Tcl-bugs] tcl-cvs: "tcl/unix configure.in" modified

[Jan N. <jan...@gm...>]

2009/1/3 Daniel A. Steffen <da...@us...>:
> (in particular compatible with autoconf 2.61, which some insist on using even though it was decided we could not switch to it yet...)

Just sharing some experience that Andreas and I had with autoconf 2.61:

It appears that autoconf 2.61 has a bug in determining the platform
endianness on some
platforms, which created a problem trying to use it in tkImg. I don't
remember the exact
details, but in autoconf 2.63 this problem didn't occur any more,
therefore tkImg
switched to autoconf 2.63 recently.

Further on, Cygwin currently uses 2.63 as default autoconf version, a
lot of packages
build fine on cygwin. Conclusion: autoconf 2.63 can be thrusted more than
autoconf 2.61, so if we switch to another version then it should not be 2.61.

Are there other arguments pro or contra specific autoconf versions? Because
of the good results with autoconf 2.63 in tkImg, I would propose that version.

Regards,
         Jan Nijtmans