tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

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

Andreas Kupries wrote:
> I believe DonalA envisions code like

I don't envisage anything here. I'm just acting as editor for Jos.

Donal.

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

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

On Wed, Feb 11, 2009 at 22:52, Donald G Porter <dg...@ni...> wrote:
> Looks like an overlooked doc update.

ok, I misunderstood the TODO to mean make the implementation agree
with those docs...

FWIW, I have nothing against that behaviour, I mainly meant to point
out that we don't appear to need [string is number] since [string is
double] is already true for all numbers...

what we do need is an accurate, widely-understood but still unused
name for either the set of integers (neither 'entier' nor 'bignum'
fits IMO), or the set of non-integer floating point numbers (my
'float' above, not great either given the potential for confusion with
'double'...)

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

[Andreas K. <and...@ac...>]

Donald G Porter wrote:
> Donald Arseneau wrote:
>> If seamless conversion and expr support can be relied on, then 
>> the original [string is integer] could be abandoned.  When
>> people are concened about the numerical range of their integers,
>> they should check the numerical values.
> 
> Check them with what?

The standard relational operators. I believe DonalA envisions code like

if {![string is integer $input] || ($input < $min) || ($input > $max)} {
	handle out of range integr ...
}

Andreas

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

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

Donald Arseneau wrote:
> If seamless conversion and expr support can be relied on, then 
> the original [string is integer] could be abandoned.  When
> people are concened about the numerical range of their integers,
> they should check the numerical values.

Check them with what?

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

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

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

On Wed, Feb 11, 2009 at 21:10, Daniel A. Steffen
<da...@us...> wrote:
> On Wed, Feb 11, 2009 at 21:07, Daniel A. Steffen
> <da...@us...> wrote:
>> ([string is number] && ![string is double])
>
> or rather ([string is number] && ![string is float])
> with 'float' covering even those floating point numbers that are not doubles...

ugh, sorry, what I meant to say is 'float' would cover the subset of
R-Z that can be represented as floating point numbers...

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

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

On Wed, Feb 11, 2009 at 22:37, Daniel A. Steffen
<da...@ca...> wrote:
> sure, my point was that [string is double] accepts all bignums,
> including those that cannot fit into a C double without loss of
> precision, or even those bigger than DBL_MAX...

leading to things like this:

% set x [expr {10**400}]
10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% string is double $x
1
% expr {double($x)}
Inf

from the manpage text, I would not have expected an overflowing double
to be acceptable:

              double      Any of the valid forms for a  double  in  Tcl,  with
                          optional   surrounding   whitespace.    In  case  of
                          under/overflow in the value, 0 is returned  and  the
                          varname will contain -1.

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

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

On Wed, Feb 11, 2009 at 22:32, Donald G Porter <dg...@ni...> wrote:
> The meaning of [string is double] got
> established as accepting integers when it was defined in terms of
> what strtod() accepted, and they accepted integers.

sure, my point was that [string is double] accepts all bignums,
including those that cannot fit into a C double without loss of
precision, or even those bigger than DBL_MAX...

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

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

Daniel A. Steffen wrote:
> On Wed, Feb 11, 2009 at 22:37, Daniel A. Steffen
> <da...@ca...> wrote:
>> sure, my point was that [string is double] accepts all bignums,
>> including those that cannot fit into a C double without loss of
>> precision, or even those bigger than DBL_MAX...
> 
> leading to things like this:
> 
> % set x [expr {10**400}]
> 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> % string is double $x
> 1
> % expr {double($x)}
> Inf
> 
> from the manpage text, I would not have expected an overflowing double
> to be acceptable:
> 
>               double      Any of the valid forms for a  double  in  Tcl,  with
>                           optional   surrounding   whitespace.    In  case  of
>                           under/overflow in the value, 0 is returned  and  the
>                           varname will contain -1.

Looks like an overlooked doc update.

 From TIP 249, "Incompatibillities":

Third, Tcl_GetDoubleFromObj will be both more and less permissive than 
before. It will no longer accept constants with a leading zero and no 
decimal point or 'E' that are invalid octal numbers. On the other hand, 
it will accept constants that are too large to fit in a Tcl_WideInt; 
somewhat surprisingly, string repeat 9 50 cannot today be interpreted as 
a double. string is double will follow Tcl_GetDoubleFromObj in what it 
considers acceptable. Any string that is accepted as either an integer 
or a double by expr will be accepted in Tcl_GetDoubleFromObj, and only 
those strings will be accepted.


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

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

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

Daniel A. Steffen wrote:
> On Wed, Feb 11, 2009 at 19:55, Jeff Hobbs <je...@ac...> wrote:
>> As to [string is number]
> 
> looking at the implementation, it turns out that [string is double] is
> actually [string is number] already, as it does not restrict to
> numbers that fit inside the C 'double' type...
> 
> there is a TODO in that code, but given that that's been there since
> the original TIP#237 implementation and that this is now established
> behaviour in 8.5, we may be stuck with it:

That TODO was never about changing the meaning of what [string is 
double] tests for, but about reconsidering the particular implementation
in place at that point.  The meaning of [string is double] got
established as accepting integers when it was defined in terms of
what strtod() accepted, and they accepted integers.

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

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

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

On Wed, Feb 11, 2009 at 19:55, Jeff Hobbs <je...@ac...> wrote:
> As to [string is number]

looking at the implementation, it turns out that [string is double] is
actually [string is number] already, as it does not restrict to
numbers that fit inside the C 'double' type...

there is a TODO in that code, but given that that's been there since
the original TIP#237 implementation and that this is now established
behaviour in 8.5, we may be stuck with it:

http://fisheye.categorifiedcoder.info/browse/Tcl/tcl/generic/tclCmdMZ.c?r=1.132#l1533

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

[Donald A. <as...@tr...>]

Lars Hellstr?m <Lar...@re...> writes:

> Donal K. Fellows skrev:
> > Donald G Porter wrote:
> >> FWIW, this would be the first exposure of the name "bignum" to the
> >> script level, and I don't find that a good thing.  I would name the
> >> command [string is entier].
> > 
> > For the record, the TIP has been updated in accordance with this
> > (including its title).
> 
> How very depressing! The unintelligible (unless, it seems, you're 
> versed in ALGOL) "entier" is getting further entrenched, and concerns 
> about C-level arithmetic are taken as canon for the script level interface.
> 
> The natural name for this functionality is [string is integer]. 

Hear hear!  I was about to pipe in about the meanings of
"integer" and "entier", but they have already been covered.
I like the idea of "int" for the original behavior.

If seamless conversion and expr support can be relied on, then 
the original [string is integer] could be abandoned.  When
people are concened about the numerical range of their integers,
they should check the numerical values.

-- 
Donald Arseneau                          as...@tr...

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

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

On Wed, Feb 11, 2009 at 19:55, Jeff Hobbs <je...@ac...> wrote:
> As to [string is number], that may
> serve as a catch-all in addition, but the current string is are for
> classifying the limited string int types.

note however that bignum is not a limited int type, given that it
covers all integers (in the mathematical sense).

it would seem that ([string is number] && ![string is double]) would
be sufficient to cover the proposed usage of [string is entier] resp
[string is bignum], sidestepping the whole naming issue (not a fan of
entier either, but it's better than exposing bignum)

Cheers,

Daniel

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

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

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

On Wed, Feb 11, 2009 at 21:07, Daniel A. Steffen
<da...@us...> wrote:
> ([string is number] && ![string is double])

or rather ([string is number] && ![string is float])
with 'float' covering even those floating point numbers that are not doubles...

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

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

On 11-Feb-09, at 3:49 AM, Twylite wrote:
> Lars Hellström wrote:
>> How very depressing! The unintelligible (unless, it seems, you're
>> versed in ALGOL) "entier" is getting further entrenched, and concerns
>> about C-level arithmetic are taken as canon for the script level  
>> interface.
>>
> Just voicing my agreement with Lars here -- entier is barely known or
> used in english or mathematics, and actually means "the integer part"
> (as in floor / trunc) rather than "an integer".  [string is entier] is
> not only meaningless to most developers (who would understand "bignum"
> intuitively), but technically inaccurate.
>
> The best alternative proposal I have is [string is number].  But of
> course that should be true for non-integer real numbers.  I don't  
> think
> that changing the meaning of [string is integer] is the right  
> approach.

+1 on using bignum over entier.  We don't need to make Tcl seem any  
more foreign for no good reason.  As to [string is number], that may  
serve as a catch-all in addition, but the current string is are for  
classifying the limited string int types.

Jeff

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

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

Lars Hellström wrote:
> How very depressing! The unintelligible (unless, it seems, you're 
> versed in ALGOL) "entier" is getting further entrenched, and concerns 
> about C-level arithmetic are taken as canon for the script level interface.
>   
Just voicing my agreement with Lars here -- entier is barely known or 
used in english or mathematics, and actually means "the integer part" 
(as in floor / trunc) rather than "an integer".  [string is entier] is 
not only meaningless to most developers (who would understand "bignum" 
intuitively), but technically inaccurate.

The best alternative proposal I have is [string is number].  But of 
course that should be true for non-integer real numbers.  I don't think 
that changing the meaning of [string is integer] is the right approach.

My 2c.
Twylite

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

[Lars H. <Lar...@re...>]

Donal K. Fellows skrev:
> Donald G Porter wrote:
>> FWIW, this would be the first exposure of the name "bignum" to the
>> script level, and I don't find that a good thing.  I would name the
>> command [string is entier].
> 
> For the record, the TIP has been updated in accordance with this
> (including its title).

How very depressing! The unintelligible (unless, it seems, you're 
versed in ALGOL) "entier" is getting further entrenched, and concerns 
about C-level arithmetic are taken as canon for the script level interface.

The natural name for this functionality is [string is integer]. The 
functionality now occupying that name should be revised (since, 
according to TIP#297, it anyway doesn't quite do what the documentation 
says) and given a name that more clearly hints at its range 
restriction, e.g. [string is int] (which would have the advantage of 
being accepted also in older Tcl versions).

In general, I suspect the usefulness of a command that checks a string 
for being a valid integer *and* further applies a hardware-oriented 
range restriction to it (current [string is integer] and [string is 
wideinteger]) is rather limited, if there is an alternative command not 
doing the range check. Yes, current [string is integer] can be used to 
check whether e.g. [lindex] would choke on it, but how useful is it to go

   if {![string is integer $index]} then {error "Not an int"}
   set elem [lindex $list $index]

when the [lindex] command anyway throws an error in that case? Anyone 
who bothers to check this kind of argument would probably apply a more 
specific condition, e.g. that the $index must be in the range of the $list.

So: Let the proposed [string is bignum] be called [string is integer]. 
Yes, it is a potential incompatibility, but I think this change would 
/fix/ far more programs than it breaks.

Lars Hellström

[TCLCORE] GSoC 2009 [Fwd: Logo and Flyer now available]

[Andreas K. <and...@ac...>]

FYI and propagation ...

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

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

Donald G Porter wrote:
> FWIW, this would be the first exposure of the name "bignum" to the
> script level, and I don't find that a good thing.  I would name the
> command [string is entier].

For the record, the TIP has been updated in accordance with this
(including its title).

Donal.

Re: [TCLCORE] TIP #345: Kill the '''identity'''encoding

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

Alexandre Ferrieux wrote:
>  TIP #345: KILL THE '''IDENTITY'''ENCODING 
> ===========================================

Much to say on this topic, but my time is limited today.

For now just a bit of additional background.  See my commits
to Tcl and Tk from last October.  The use of the identity encoding
has been completely purged from Tk and its test suite.  The
use of the identity encoding as a place holder for the system
encoding during Tcl startup has been purged as well.

The main place the identity encoding is still in use is in
the Tcl test suite, both directly and through the command
[tcltest::bytestring] which is defined in terms of
[encoding convert* identity].

I think the next logical step is to convert the identity
encoding from one implemented directly in C code and in
the default sources of Tcl into one of the encodings that
is loaded on demand from a *.enc file.  Next Tcl can stop
distributing the identity.enc file, and those extensions or test
suites that still insist on having the encoding around
can distribute it themselves and use [encoding dirs] to
force Tcl to find it.

Getting rid of the identity encoding is a good thing, but it's
only a part of the larger task of enforcing the "contract"
we've evolved ourselves into of demanding that strings which
find their way to an objPtr->bytes must conform to our internal
encoding.  We didn't start out demanding that, but over time
more and more of our internals assume it to be true.

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

Re: [TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

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

Jos Decoster wrote:
>  TIP #347: ADD 'STRING IS BIGNUM' TO THE 'STRING IS' SUBCOMMAND

This proposal is part of what TIP 297 aims for.  I would like to see
the two TIPs merged into one and completed.

FWIW, this would be the first exposure of the name "bignum" to the
script level, and I don't find that a good thing.  I would name the
command [string is entier].

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

[TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

[Jos D. <jos...@gm...>]

 TIP #347: ADD 'STRING IS BIGNUM' TO THE 'STRING IS' SUBCOMMAND
================================================================
 Version:        $Revision: 1.3 $
 Author:         Jos Decoster <jos.decoster_at_gmail.com>
 State:          Draft
 Type:           Project
 Tcl-Version:    8.7
 Vote:           Pending
 Created:        Monday, 09 February 2009
 URL:            http://www.tcl.tk/cgi-bin/tct/tip/347.html
 Discussions-To: news:comp.lang.tcl
 Post-History:

-------------------------------------------------------------------------

 ABSTRACT
==========

 The *string* command supports tests for a number of Tcl's basic types,
 for example, integers, doubles, and booleans. This TIP proposes adding
 bignum integers, as was done for wide integers in [TIP #188].

 RATIONALE
===========

 The *string* command includes tests for the common Tcl types: *string
 is boolean*, *string is double* and *string is integer*. Unaccountably,
 *string is bignum* is missing from the list, making it difficult for an
 input validation procedure to determine whether, in fact, a string
 contains a valid (bignum) integer.

 SPECIFICATION
===============

 This document proposes augmenting the *string is* command with a
 *string is bignum* that functions the same as *string is integer* in
 every respect except for the fact that it accepts any string containing
 a substring that is valid as a bignum integer (that is, acceptable to
 /Tcl_GetBignumFromObj/) possibly surrounded by whitespace.

 REFERENCE IMPLEMENTATION
==========================

 Patches that implement *string is bignum*, provide test cases for it,
 and update /doc/string.n/ to include it are available at SourceForge as
 Tcl Patch
 #2581150[<URL:https://sourceforge.net/support/tracker.php?aid=2581150>].

 COPYRIGHT
===========

 This document has been placed in the public domain.

[TCLCORE] TIP #346: Error on Failed String Encodings

[Alexandre F. <ale...@gm...>]

 TIP #346: ERROR ON FAILED STRING ENCODINGS 
============================================
 Version:      $Revision: 1.1 $
 Author:       Alexandre Ferrieux <alexandre.ferrieux_at_gmail.com>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.7
 Vote:         Pending
 Created:      Monday, 02 February 2009
 URL:          http://purl.org/tcl/tip/346.html
 WebEdit:      http://purl.org/tcl/tip/edit/346
 Post-History: 

-------------------------------------------------------------------------

 ABSTRACT 
==========

 This TIP proposes to raise an error when a String-to-ByteArray 
 conversion loses information. 

 BACKGROUND 
============

 A String-to-ByteArray conversion occurs e.g. when writing a string to a 
 channel. In doing so, Unicode characters are converted to sequences of 
 bytes according to the channel's encoding. Alternatively, the 
 conversion can occur on request of the ByteArray internal 
 representation of an object, the target encoding being returned by 
 *encoding system*. In both cases, for some combinations of Unicode char 
 and target encoding, the mapping is lossy (non-injective). For example, 
 the "e acute" character, and many of its cousins, is mapped to a "?" in 
 the 'ascii' target encoding. 

 This loss of information, in the first case, introduces unnoticed i18n 
 mishandlings. In the second case, it makes it unreliable to do 
 pure-ByteArray operations on objects unless they have no string 
 representation. This induces unwanted and hard-to-debug performance 
 hits on bytearray manipulations when people add debugging *puts*. 

 PROPOSED CHANGE 
=================

 This TIP proposes to make this loss conspicuous. 

 For the first use case, the idea is to introduce a *-strict* option to 
 *encoding convertto*, that would raise an explicit error when 
 non-mappable characters are met. For the second case, we simply want 
 the conversion to fail, like does the Listification of an ill-formed 
 list. In both cases, the change consists of letting 
 *Tcl_GetByteArrayFromObj* return TCL_ERROR. 

 RATIONALE 
===========

 The second case does imply a Potential Incompatibility. However, it is 
 felt that virtually all cases that are sensitive to this, are actually 
 half-working in a completely hidden manner. Hence the global effect is 
 a healthy one. 

 REFERENCE EXAMPLE 
===================

 See Bug 1665628 
 [<URL:https://sourceforge.net/support/tracker.php?aid=1665628>]. 

 COPYRIGHT 
===========

 This document has been placed in the public domain. 

-------------------------------------------------------------------------

 TIP AutoGenerator - written by Donal K. Fellows 

[TCLCORE] TIP #345: Kill the '''identity'''encoding

[Alexandre F. <ale...@gm...>]

 TIP #345: KILL THE '''IDENTITY'''ENCODING 
===========================================
 Version:      $Revision: 1.1 $
 Author:       Alexandre Ferrieux <alexandre.ferrieux_at_gmail.com>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.7
 Vote:         Pending
 Created:      Thursday, 05 February 2009
 URL:          http://purl.org/tcl/tip/345.html
 WebEdit:      http://purl.org/tcl/tip/edit/345
 Post-History: 

-------------------------------------------------------------------------

 ABSTRACT 
==========

 This TIP proposes to remove the 'identity' encoding which is the 
 Pandora's Box of invalid UTF-8 string representations. 

 BACKGROUND 
============

 The contract of string representations in Tcl states that the /bytes/ 
 field (the *strep*) of a Tcl_Obj must be a valid UTF-8 byte sequence. 
 Violating it leads at best to inconsistent and shimmer-sensitive string 
 comparisons. Fortunately, nearly all of the Tcl code takes careful 
 steps to enforce it. With one exception: the 'identity' encoding. 
 Indeed, this encoding allows any byte sequence to be copied verbatim 
 into the strep of a value, as a side-effect of a strep computation on a 
 ByteArray with [*encoding system*]=="identity", or through [*encoding 
 convertfrom identity*]. Hence an invalid UTF-8 sequence can easily make 
 it to the strep and start wreaking havoc. 

 PROPOSED CHANGE 
=================

 This TIP proposes to simply close that single window to the dark side. 

 RATIONALE 
===========

 The risk of compatibility breakage is inordinately mild in that case, 
 since it has only ever been documented in tcltest. 

 REFERENCE EXAMPLE 
===================

 See Bug 2564363 
 [<URL:https://sourceforge.net/support/tracker.php?aid=2564363>] 

 COPYRIGHT 
===========

 This document has been placed in the public domain. 

-------------------------------------------------------------------------

 TIP AutoGenerator - written by Donal K. Fellows 

[TCLCORE] TIP #347: Add 'string is bignum' to the 'string is' Subcommand

[Jos D. <jos...@gm...>]

 TIP #347: ADD 'STRING IS BIGNUM' TO THE 'STRING IS' SUBCOMMAND 
================================================================
 Version:        $Revision: 1.2 $
 Author:         Jos Decoster <jos.decoster_at_gmail.com>
 State:          Draft
 Type:           Project
 Tcl-Version:    8.6
 Vote:           Pending
 Created:        Monday, 09 February 2009
 URL:            http://purl.org/tcl/tip/347.html
 WebEdit:        http://purl.org/tcl/tip/edit/347
 Discussions-To: news:comp.lang.tcl
 Post-History:   

-------------------------------------------------------------------------

 ABSTRACT 
==========

 The *string* command supports tests for a number of Tcl's basic types, 
 for example, integers, doubles, and booleans. This TIP proposes adding 
 bignum integers, as was done for wide integers in [TIP #188]. 

 RATIONALE 
===========

 The *string* command includes tests for the common Tcl types: *string 
 is boolean*, *string is double* and *string is integer*. Unaccountably, 
 *string is bignum* is missing from the list, making it difficult for an 
 input validation procedure to determine whether, in fact, a string 
 contains a valid (bignum) integer. 

 SPECIFICATION 
===============

 This document proposes augmenting the *string is* command with a 
 *string is bignum* that functions the same as *string is integer* in 
 every respect except for the fact that it accepts any string containing 
 a substring that is valid as a bignum integer (that is, acceptable to 
 /Tcl_GetBignumFromObj/) possibly surrounded by whitespace. 

 REFERENCE IMPLEMENTATION 
==========================

 Patches that implement *string is bignum*, provide test cases for it, 
 and update /doc/string.n/ to include it are available at SourceForge as 
 Tcl Patch 
 #2581150[<URL:https://sourceforge.net/support/tracker.php?aid=2581150>]. 

 COPYRIGHT 
===========

 This document has been placed in the public domain. 

-------------------------------------------------------------------------

 TIP AutoGenerator - written by Donal K. Fellows 

Re: [TCLCORE] tcludp

[Andreas K. <aku...@sh...>]

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

Note that this is a question more for us at ActiveState, and not for
the Tcl core development mailing list.

Having said that, TclUDP is one of the packages we provide only
through the TEApot. To get it you have to run

	teacup install udp

> Thanks,
> Terry

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------