tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP #348: Substituted 'errorStack' / 'traceback'

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

Jeff Hobbs wrote:
> I don't believe the options dict applies in this case because we are 
> trying to establish improved error traceability, without necessarily a 
> catch being used.  What would happen with uncaught errors?

Depends on the bgerror handler or main loop code, surely? So long as the
info is in the result of Tcl_GetReturnOptions, we can handle it one way
or another.

Donal.

Re: [TCLCORE] TIP #348: Substituted 'errorStack' / 'traceback'

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

Alexandre Ferrieux wrote:
> On Fri, Feb 27, 2009 at 6:06 PM, Donald G Porter <dg...@ni...> wrote:
>> That said, I think the proposal itself steps off on the wrong foot
>> by proposing another magic variable.  We've had extensible
>> return options since 8.5 (TIP 90) and this is a perfect
>> place to make use of them.
> 
> Oh of course, the important thing is the content, not the vehicle :)
> ::tcl::errorStack, [interp errorStack], or $optionsdict(errorStack)
> are equally palatable to me...
> 
> (I believed ::tcl::errorStack was a neat cleanup wrt ::errorStack ...
> everything is relative !)

I don't believe the options dict applies in this case because we are 
trying to establish improved error traceability, without necessarily a 
catch being used.  What would happen with uncaught errors?

Jeff

Re: [TCLCORE] TIP #348: Substituted 'errorStack' / 'traceback'

[Konstantin K. <fla...@us...>]

Alexandre Ferrieux wrote:
>  TIP #348: SUBSTITUTED 'ERRORSTACK' / 'TRACEBACK' 
[...]
>  This TIP proposes to create a *::tcl::errorStack* variable which is a 
>  list of lists, made of the [*info level* 0] lists of command-and-args 
>  at each proc level at the time of error unwinding. 
[...]
>  The performance hit of maintaining ::errorStack should be very small, 
>  since basically it amounts to growing a (usually short) list whose 
>  elements are already existing Tcl_Obj's (the [*info level* 0] lists).  
>  However, if it proves necessary to provide an on/off switch, one can 
>  imagine a *::tcl::useErrorStack* boolean linked var. 
[...]

I don't know Tcl internals well, so here's my question: what occurs if a 
script fails, which processed some immense amount of data that was 
passed by value, following the Tcl semantics -- say, some huge list?

If what [info level 0] internally returns is just a Tcl_ListObj, 
referencing several other Tcl_Objs, growing a list behind ::errorStack 
is OK, but when it would be converted to the user-visible form, that is, 
to a string rep, the proposed approach might turn out to be too 
simple-minded as it might blow too much data at the user.

In this case something akin to what Erlang shell does could be used -- 
it elides that part of the string representation which is beyond a 
certain threshold using "..." (see format() in [1], the description of 
the 'W' format specifier).

Another problem is showing byte arrays.

1. http://www.erlang.org/doc/man/io.html

Re: [TCLCORE] TIP #348: Substituted 'errorStack' / 'traceback'

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

On Fri, Feb 27, 2009 at 6:06 PM, Donald G Porter <dg...@ni...> wrote:
>
> That said, I think the proposal itself steps off on the wrong foot
> by proposing another magic variable.  We've had extensible
> return options since 8.5 (TIP 90) and this is a perfect
> place to make use of them.

Oh of course, the important thing is the content, not the vehicle :)
::tcl::errorStack, [interp errorStack], or $optionsdict(errorStack)
are equally palatable to me...

(I believed ::tcl::errorStack was a neat cleanup wrt ::errorStack ...
everything is relative !)

-Alex

Re: [TCLCORE] TIP #348: Substituted 'errorStack' / 'traceback'

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

Alexandre Ferrieux wrote:
>  TIP #348: SUBSTITUTED 'ERRORSTACK' / 'TRACEBACK' 

Some implementation of this capability has long been
a request.  See Tracker Reports 523900 and 1047543
for two examples; there may be more.

Alexandre has a good habit of prompting action on
languishing good ideas, so I'm happy to see action here.

That said, I think the proposal itself steps off on the wrong foot
by proposing another magic variable.  We've had extensible
return options since 8.5 (TIP 90) and this is a perfect
place to make use of them.

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

[TCLCORE] TIP #348: Substituted 'errorStack' / 'traceback'

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

 TIP #348: SUBSTITUTED 'ERRORSTACK' / 'TRACEBACK' 
==================================================
 Version:      $Revision: 1.2 $
 Author:       Alexandre Ferrieux <alexandre.ferrieux_at_gmail.com>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.7
 Vote:         Pending
 Created:      Thursday, 26 February 2009
 URL:          http://purl.org/tcl/tip/348.html
 WebEdit:      http://purl.org/tcl/tip/edit/348
 Post-History: 

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

 ABSTRACT 
==========

 This TIP proposes to add a *::tcl::errorStack* variable giving a 
 "substituted" traceback similar to Python's or gdb's ones. 

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

 The ::errorInfo variable is a valuable tool for debugging; however, it 
 yields mostly static information regarding each level of procedure 
 call, as it only gives the static text (extracted from the source) at 
 the call site. This leads to frustrating situations, like when an error 
 occurs at a deep level of a recursive function, /::errorInfo/ 
 repeatedly reporting "f $x [foo [bar]]" or similar un-substituted 
 commands. In other languages, the traceback is more useful in that it 
 contains the actual values passed as arguments. 

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

 This TIP proposes to create a *::tcl::errorStack* variable which is a 
 list of lists, made of the [*info level* 0] lists of command-and-args 
 at each proc level at the time of error unwinding. 

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

 In a natural implementation, its construction is analogous to 
 ::errorInfo's, which is built incrementally, one level at a time while 
 popping back from the error site. The only differences are that (1) 
 dynamic arglists (from [*info level* 0]) are stored, (2) the result is 
 a true list built by *lappend*, and (3) the granularity is coarser than 
 ::errorInfo's since there is just one element per proc level (and not 
 for intervening *while* or *foreach* constructs) and no adornment like 
 "... while executing ..." . 

 The performance hit of maintaining ::errorStack should be very small, 
 since basically it amounts to growing a (usually short) list whose 
 elements are already existing Tcl_Obj's (the [*info level* 0] lists). 

 However, if it proves necessary to provide an on/off switch, one can 
 imagine a *::tcl::useErrorStack* boolean linked var. 

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

 A C reference implementation will be provided shortly. In the meantime, 
 a pure-Tcl proof of concept based on write traces on ::errorInfo can be 
 found at <URL:http://wiki.tcl.tk/traceback> . 

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

 This document has been placed in the public domain. 

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

 TIP AutoGenerator - written by Donal K. Fellows 

Re: [TCLCORE] Serializing and Mmapping dicts

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

Hi Donal,

On Mon, Feb 23, 2009 at 2:16 PM, Donal K. Fellows
<don...@ma...> wrote:
>
> My point about arrays is that I think it might be possible to have an
> array that doesn't have a Tcl_HashTable behind it.

I followed your advice and dug through the guts of array lookups.

Then I noticed one nasty thing: the focal point, which is
TclLookupArrayElement, must return a (Var *), that is a structure
witnessing the fact that arrays are collections of variables.
So, if I plug a readonly backend (like an mmapped hashtable) behind
the Array API, each and every such lookup will require the allocation
of a "fake Var". In addition to that being cumulative side-effects
(but I've been prepared to them for values' string reps which cannot
stay in the readonly area and must be copied), it also implies
emulating much of the traditional array's internal state....

While [dict get] is just supposed to yield a Tcl_Obj.

Superficially, it would then look like dicts are way simpler to handle
than arrays...
Can you comment on this ?

-Alex

Re: [TCLCORE] Serializing and Mmapping dicts

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

On Mon, Feb 23, 2009 at 11:41 AM, Donal K. Fellows
<don...@ma...> wrote:
> But in
> general, I think attaching to arrays has much better "Architectural
> Smell" (by analogy with "Code Smell" :-)) than attaching to dicts.

OK, thanks for the info. In fact I mentioned dicts thinking "dicts or
arrays", meaning infact the Tcl_HashTable that underlies both.
So I'll happily follow your advice and attack by the south face.

As to the value semantics and the "leaf" Tcl_Objs, of course the
serialization process takes care of that too, and yes I am aware that
serialization involves turning all pointers into offsets. Again, I'm
serializing hashtables all the time at work. So I was just proposing
to do it to Tcl hashtables too.

> In short, your current plan is a bit wonky but the larger picture scheme
> should be quite practical.

OK.

To play the devil's advocate, instead of this positive feedback, I was
also prepared to hear something along the lines of:

 "Don't do that. People can already [puts $d] or [puts [array get a]]
for small hashes, and for large ones we're entering the realm of True
Databases."

But you didn't say that, and I'm glad ;-)

-Alex

Re: [TCLCORE] Serializing and Mmapping dicts

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

Alexandre Ferrieux wrote:
> On the margin of discussions about the init overhead of database
> engines, I am wondering whether the following could make sense:
> 
>   - allow for the hashtable behind a dict to be saved (serialized) in
> its internal form (not the strep)

Well, the natural iteration order is the one that is in the string rep.
The parts of the dict that are not saved all don't matter that much
(e.g. pointers to preceding and following entries or the computed count
of the number of entries) because they're implied by the string rep.

>   - allow for the resulting serialized form to be directly mmap()ped
> and reused in a (readonly) dict

Dicts are poorly suited to mmap()ing, because they're chock full of real
pointers (as opposed to offsets within an array). Plus a dict isn't much
use without the Tcl_Objs to go into it.

> I know the overall process is no rocket science, it is just yet
> another hash-based micro-database engine, but I'd like your opinion on
> how it could blend with Tcl.

With great difficulty. Dicts are explicitly and utterly about being
values, and Tcl's values don't have their own identities; one copy of a
value is very much like another.

> But the main idea is to provide something that could instantly read
> and use a very large dict, with absolutely zero I/O overhead if the
> pages are still in RAM after recent use.
> (I'm doing this already outside the context of Tcl, and it really
> rocks: fork/exec/lookup under a jiffy)

I think you'd do better with reworking the guts of array so that you can
plug in there. More generally, it's something I've wanted to look into
myself for a while, with an aim to allowing the setup of different types
of array (e.g. an integer-indexed array of variables, or even an array
of doubles, so putting BLT vectors on a more formal basis) and the fact
that arrays are complex named entities means that there's a sensible
place to hang the extra bits of state off. But it has been on my "to do"
list for a while now, so don't feel that you're intruding. If you want
to have a go and report back what you find out, be my guest. But in
general, I think attaching to arrays has much better "Architectural
Smell" (by analogy with "Code Smell" :-)) than attaching to dicts.

In short, your current plan is a bit wonky but the larger picture scheme
should be quite practical.

Donal.

Re: [TCLCORE] TIP#146: Add Overall Anchoring to the Grid Geometry Manager

[<Tie...@ca...>]

Hi Peter Spjuth,
   I'm a member of Elisoft that's in Vietnam (that's belong to CA-US).
   While I'm looking a good syntax checker for tcl script, I found that it is in your project (Nagelfar). Because I don't know how to contact to you to dicuss about your application, today I write this mail base on Subject "Re: TIP#146: Add Overall Anchoring to the Grid Geometry Manager"  to ask you for buying this application(Nagelfar). Can you send to me the trial version of syntax checker for tcl script? Thanks for your help.

Thank you.
Tran Tien

Yahoo Messenger: tqt...@ya...
Email: Tie...@ca...

[TCLCORE] Serializing and Mmapping dicts

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

Hi,

On the margin of discussions about the init overhead of database
engines, I am wondering whether the following could make sense:

  - allow for the hashtable behind a dict to be saved (serialized) in
its internal form (not the strep)
  - allow for the resulting serialized form to be directly mmap()ped
and reused in a (readonly) dict

I know the overall process is no rocket science, it is just yet
another hash-based micro-database engine, but I'd like your opinion on
how it could blend with Tcl.
At the script level this could look like:

          dict set x foo bar
          set ch [open saved.dic w]
          ...
          puts -nonewline $ch [dict serialize x]

# in another process:

          set x [dict mmap saved.dic]
          puts [dict get $x foo] => bar
          dict set x try it => raises "Dict is read-only"

Of course, plenty of variants may exist, like using a type distinct
from Dict, or allowing to unfreeze a read-only dict, etc.

But the main idea is to provide something that could instantly read
and use a very large dict, with absolutely zero I/O overhead if the
pages are still in RAM after recent use.
(I'm doing this already outside the context of Tcl, and it really
rocks: fork/exec/lookup under a jiffy)

Reactions ?

-Alex

[TCLCORE] version tags

[Rene Z. <r.z...@fr...>]

Hi,

I use the following package sources from cvs.
Unfortunately are there no tags.
So finding later the used source is complicated.
Would it be possible to tag the corresponding version,
at least on major changes?
I think people with the according rights are reading this list.

I'm not looking on the wrong place or missed the tags?
  tclvfs.cvs.sourceforge.net:/cvsroot/tclvfs
  tcl.cvs.sourceforge.net:/cvsroot/tcl thread
  tkimg.cvs.sourceforge.net:/cvsroot/tkimg
  memchan.cvs.sourceforge.net:/cvsroot/memchan (version 2.2.1 has problems in 
configure)
  tclx.cvs.sourceforge.net:/cvsroot/tclx
  tkcon.cvs.sourceforge.net:/cvsroot/tkcon
  tktable.cvs.sourceforge.net:/cvsroot/tktable

Thank you,
rene

Re: [TCLCORE] [Tcl-soc2008] GSoC 2009: Where do we stand so far?

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

Clif Flynt wrote:
> Hi,
>   I've exchanged some e-mail with Kryzstof, who worked with
> me last year, and Joe English about seeing if we can put the kind
> of introspection into the TTK widgets that normal Tk widgets support.
> 
>   I've jumped through all the hoops with Google, and should see the
> money from last year's efforts showing up in the next bank statement.
> 
>   Do we have the wiki and/or whatever infrastructure for managing the
> proposals set up?  Would someone remind me where it is if I've been too
> lost in the weeds to notice?

"Project Ideas for Google Summer of Code 2009" is at
	http://wiki.tcl.tk/22182

Andreas.

Re: [TCLCORE] [Tcllib-devel] GSoC 2009: Where do we stand so far?

[Arjen M. <arj...@de...>]

Hi Clif,

a bunch of proposals have been collected at http://wiki.tcl.tk/22182.

Regards,

Arjen

On 2009-02-19 13:50, Clif Flynt wrote:
> Hi,
>   I've exchanged some e-mail with Kryzstof, who worked with
> me last year, and Joe English about seeing if we can put the kind
> of introspection into the TTK widgets that normal Tk widgets support.
> 
>   I've jumped through all the hoops with Google, and should see the
> money from last year's efforts showing up in the next bank statement.
> 
>   Do we have the wiki and/or whatever infrastructure for managing the
> proposals set up?  Would someone remind me where it is if I've been too
> lost in the weeds to notice?
> 
>   Thanks,
>   Clif
> 


Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 

 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[TCLCORE] GSoC 2009: Where do we stand so far?

[Clif F. <cl...@cf...>]

Hi,
  I've exchanged some e-mail with Kryzstof, who worked with
me last year, and Joe English about seeing if we can put the kind
of introspection into the TTK widgets that normal Tk widgets support.

  I've jumped through all the hoops with Google, and should see the
money from last year's efforts showing up in the next bank statement.

  Do we have the wiki and/or whatever infrastructure for managing the
proposals set up?  Would someone remind me where it is if I've been too
lost in the weeds to notice?

  Thanks,
  Clif

-- 
... Clif Flynt ... http://www.cwflynt.com ... cl...@cf... ...
.. Tcl/Tk: A Developer's Guide (2nd edition) - Morgan Kauffman ..
.... 16'th Annual Tcl/Tk Conference:  2009,  West Coast, USA ....
.............  http://www.tcl.tk/community/tcl2008/  ............

[TCLCORE] ANNOUNCE: Colibri version 0.1

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

ANNOUNCE: Colibri version 0.1
=============================
As part of my ongoing work on the Cloverfield project, I am pleased to 
announce the first version of Colibri.


WHAT IS CLOVERFIELD ?
=====================

Wiki page: http://wiki.tcl.tk/Cloverfield


WHAT DOES COLIBRI STANDS FOR ?
==============================

Colibris, known in English as hummingbirds, are a family of bird known 
for their small size and high wing speed. The bee hummingbird (Mellisuga 
helenae), found in Cuba, is the smallest of all birds, with a mass of 
1.8 g and a total length of about 5cm. They are renowed for their 
stationary and backward flight abilities on par with flying insects, 
which allows them to feed on the nectar of plants and flowers in-flight.

I've chose this name for this project because its goal is to be fast and 
lightweight, and to follow the feather and bird theme shared with Tcl 
and many related projects.


WHAT IS COLIBRI ?
=================

Colibri is a string and data type infrastructure. It features:

  - Rope-based strings (see http://wiki.tcl.tk/20690) :

      * ropes are immutable
        ... but ...
      * extraction, insertion, deletion, concatenation... are fast
      * limited compatibility with native C strings allocated in static
        space (or guaranteed to survive the whole application lifetime)
      * support for the full Unicode range (up to 32-bit codepoints)
      * 1/2/4-byte fixed-width encodings as well as variable-width UTF-8
        with transparent conversions and access
      * custom rope types allows for lazy or procedural representations
      * iterator interface for easy access

  - Extensible data type sytem dubbed "words"

      * similar to Tcl_Obj
      * minimum payload is identical to that of Tcl_Obj, i.e. 8 bytes,
        but can take more space if needed
      * words have values that can be of any type, including other words
      * values can form chains of arbitrary length, so a word can have
        several values with different representations -- no more
        shimmering!
      * predefined types such as ints, single chars and small strings (up
        to 3 chars on 32-bit systems) are represented as immediate
        values: the value is stored directly in the pointer rather than
        in an allocated structure

  - Fast and efficient cell-based allocator

      * page-based allocation for optimal locality of reference and cache
        use
      * 16-byte cells on 32-bit systems fit most needs, but elements can
        allocate more cells if needed (up to 63 cells on 32-bit systems)
      * overhead is small: 2 bits per 16-byte cell.
      * raw alloc performances are competitive with the stock system
        malloc, and in many cases much faster (up to 5 times as fast on
        small strings and on words vs. Tcl_Obj-like structs)
      * single cell allocation (the most frequent case) is very fast

  - Automatic memory management thanks to an exact (AKA accurate or
    precise), generational, copying, mark-and-sweep, garbage collector

      * exact GC implies that roots (externally referenced elements) and
        parent-child relations must be declared by the application, using
        a simple API
      * custom types can define a finalizer
      * the GC process is fully controllable (pause/resume) so that the
        application don't get interrupted unexpectedly
      * generational GC limits the overhead by restricting the collection
        to newer elements, which are typically short-lived
      * longer-living elements are collected less often and get promoted
        after two cycles
      * promotion is done by copying old elements to older pools, which
        performs compaction as a side effect, thus limiting the
        fragmentation and improving the cache-friendliness over time
      * contrary to reference-counting schemes (RC), GCs allow circular
        references without memory leaks
      * studies show that GCs consistently outperform RC in raw
        performances and real-world cases, because the cost (both space
        and time) of maintaining reference counters outweights the
        amortized GC overhead, especially with generational GCs


Colibri is written in plain C and is free of any dependency besides
system libraries. The compiled binary DLL on Windows is about 27kB. The 
source code is heavily commented and follows the Tcl quality standards.


HOW DOES COLIBRI RELATES TO TCL
===============================

 From the Cloverfield announcement:

"   The last major point of the project is related to implementation and
     low level issues. The existing Tcl implementation is notoriously
     solid, however some changes are too radical to be performed on the
     current code base, so a reimplementation is certainly needed on vast
     portions. For example, the string representations, object
     structures, and virtual machines will certainly require complete
     rewrite to accommodate with the needed changes, which means that a
     lot of code won't be reused. However vast portions of library code
     and algorithms certainly will (clock scan, bigint, regexp...), as
     well as the high coding standards and QA that are the trademarks of
     our beloved language.  "

So Colibri is a candidate infrastructure for Tcl9 as an alternative to 
the current Tcl_Obj-based core implementation. I believe that the 
features provided by Colibri shall yield higher levels of performances 
than the current architecture, at the price of an ABI incompatibility 
(for which major versions are made anyway), but with a similar 
philosophy that should ease conversion of existing code.


WHAT NEEDS TO BE DONE ?
=======================

My main development platform is Windows, so for now the source archive 
only includes Microsoft Visual Studio project files. Microsoft provides 
a free edition of their development environment known as Visual Studio 
Express for those willing to compile and test the library without having 
to buy an expensive license. Other systems need a makefile and/or 
autoconf scripts.

The code is fairly portable on 32-bit systems. 64-bit support will need 
more work because all the internals are fine-tuned and optimized at the 
bit level; however porting to 64-bit should be rather straightforward: 
the algorithms will remain unchanged, structure access is abstracted 
behing macros, and cell size is proportional to the word size (a cell 
should be able to store 4 pointers, which add up to 16 bytes on 32-bit 
systems).

The only part that needs platform-specific code is the low-level page 
allocator. Colibri needs system calls that allocate boundary-aligned 
pages. At present only a Windows version is provided, but porting to 
other systems should require minimal effort, as the platform-specific 
code is limited to a handful of functions. Platform-specific 
peculiarities should not impact the overall architecture.

Exception handling is poor, especially because Colibri is meant to be 
part of a larger system that provides the appropriate infrastructure.

The current implementation is not thread-safe as it uses unprotected 
global structures. However I don't think that adding synchronization is 
necessary given that it should eventually be integrated into a larger 
application with the same appartment threading model as Tcl. The main 
advantage of having a global allocator is inter-thread data sharing, and 
Tcl typically shares no data between threads. As Colibri is not designed 
to be a general-purpose solution, and unless there is a real benefit in 
using a global thread-safe allocator, converting global structures to 
thread-local should fit our needs.

Tests have been run extensively during development, both on stability 
and performance. However Colibri lacks a real test suite. The source 
includes a test application that has to be hand-edited to run or 
customize specific tests. Note that the current values defined by this 
application require a system with a large memory size (2GB).

Last, it lacks user and design documentation, although the source code 
is extensively commented.


WHERE CAN IT BE FOUND ?
=======================

Wiki page: http://wiki.tcl.tk/Colibri
Project page @ SourceForge.net: https://sourceforge.net/projects/tcl9/
Mailing list: 
https://sourceforge.net/mailarchive/forum.php?forum_name=tcl9-colibri
Direct Download:
     - source: 
http://downloads.sourceforge.net/tcl9/colibri0.1.src.zip?use_mirror=
     - Windows binary: 
http://downloads.sourceforge.net/tcl9/colibri0.1.win32.zip?use_mirror=


LICENSE
=======

The license is the same as for Tcl.

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

[Fredderic <mag...@gm...>]

On Wed, 11 Feb 2009 21:07:37 +0100, 
"Daniel A. Steffen" <da...@us...> wrote:

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

Would it make sense at all to throw the whole lot backwards a step,
instead of having a bunch of [string is XXX]'s for various integer
ranges.  Something like one of these options;

1) how about adding -options to [string is integer] to constrain it to
specific sizes of integer, with the default being any integer that
TCL can handle (ie. the proposed [string is bignum]).  This also would
allow for a -?un?signed flag, and -8/16/32-bit (eg. "-bits 8/16/32"),
etc., which could come in handy for testing whether a number will fit
into a given [binary] field, for example.

2) add an easy way to obtain the number of bits needed to store a given
number, or the number of bytes needed to store it.  (The latter would
likely be more useful anyhow.)  Then just add an equally easy way to
obtain the number of bits/bytes contained in various common integer
types, and the test is only a comparison away.

3) a [string classes] command that will return a list of all the
standard string classes which match a given value.  Return the list
sorted, suitable for use with [lsearch -sorted] or the "in" operator.
Then, if the basic [string is] tests don't do it for you, [string
classes] provides a bunch of properties that can be tested on.  I can
see this being painfully slow to use on a regular basis, however.

My preference would be for option #1...  A single [string is integer]
class with optional constraints as to exactly what it will accept, but
defaulting to the script-wise view of any integer TCL supports.


Just a thought...

-- 
Fredderic

Debian/unstable (LC#384816) on i686 2.6.26-z2 2008 (up 4 days,  9:37)

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

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

Twylite wrote:
> Larry W. Virden wrote:
>>>> % string is double $x
>>>> 1
>>>> % expr {double($x)}
>>>> Inf
>>>>       
>> Is this the way things will be staying in Tcl over the long haul - one
>> value some times being reported as a double and the same value being
>> rejected when one tries to use it as a double?
>>
>>   
> My 2c: the [string is TYPE] should indicate accurately whether 
> subsequent use of the string as that type will break due to a type 
> incompatibility.

For what it's worth, Inf is not "rejected":

% string is double Inf
1
% set x Inf; expr {$x + 1}
Inf

-- 
73 de ke9tv/2, Kevin

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

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

Hi,

I extended tip 347 to align the [string is <integer_range>] and
[::tcl::mathfunc::<integer_range>] commands.

http://www.tcl.tk/cgi-bin/tct/tip/347

Kind  regards,

Jos.

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

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

Larry W. Virden wrote:
>>> % string is double $x
>>> 1
>>> % expr {double($x)}
>>> Inf
>>>       
>
> Is this the way things will be staying in Tcl over the long haul - one
> value some times being reported as a double and the same value being
> rejected when one tries to use it as a double?
>
>   
My 2c: the [string is TYPE] should indicate accurately whether 
subsequent use of the string as that type will break due to a type 
incompatibility.  The answer is necessarily platform specific, which is 
why these sort of functions are required.  In short [string is TYPE] 
should probably be implemented using GetTYPEFromObj() where 
possible/appropriate.

My experience using these functions is mostly limited to checking input 
(from a user, config file, input data file, etc.) to ensure that it is a 
number (typically an integer, possibly a non-negative integer), a 
hexadecimal string (xdigit), or a boolean ([string is true] / [string is 
false]). I could use [regexp] most of the time, but that's a pain when I 
can just ask Tcl to determine for me based on its usual conversion 
capabilities.

Regards,
Twylite

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

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

> From: Donald G Porter <dg...@ni...>
>> leading to things like this:
>>
>> % set x [expr {10**400}]
>> 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>> % string is double $x
>> 1
>> % expr {double($x)}
>> Inf

Is this the way things will be staying in Tcl over the long haul - one
value some times being reported as a double and the same value being
rejected when one tries to use it as a double?

Or is this something that will be improved at the appropriate (Tcl 9
perhaps) time?

Just curious whether the community sees this along the "ho hum, I
don't use it, so I don't care" or a "this is crisis" spectrum.

-- 
Tcl - The glue of a new generation.   http://wiki.tcl.tk/
Larry W. Virden http://www.purl.org/net/lvirden/
http://www.xanga.com/lvirden/
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

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

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

Quoting "Donald Arseneau" <as...@tr...>:
> something like
> if { [string is integer $x] && $x == ($x & 0xFFFFFFFF) } {

But that's not what the current [string is integer] does.

It enforces a limited range that is platform dependent.

DGP

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

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

Donald G Porter <dg...@ni...> writes:

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

something like 
if { [string is integer $x] && $x == ($x & 0xFFFFFFFF) } {

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

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

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

Donal K. Fellows wrote:
> Andreas Kupries wrote:
>> I believe DonalA envisions code like
> 
> I don't envisage anything here. I'm just acting as editor for Jos.

Apologies. I meant Donal<d>A, i.e. Donald Arsenau.

Andreas.

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.