tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP #349: New "-cargo" option for every Tk widget

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

Zbigniew Baniewski wrote:
> There are people - like myself - who prefer the option, because this will
> make the field contents "strictly bound" to a widget.

The problem is that the data model of such an option (given the general
models of Tcl and Tk) is such that it's only convenient if reserved
strictly for use by application code, and is left entirely alone by
libraries. If we go to something more general capable of supporting use
by both libraries and an application at the same time, you've got to
make the syntax different. (Damon's suggestion would do that exactly.)

Or you can use an array with a <Destroy> callback or command-delete
trace for cleanup, and get your functionality today. In case you've got
this idea that being an option is holy, realize that this is pretty much
what Tk does internally when working out when to clean up structures.
Wrapping that with fancy syntax is an exercise for the reader.

Donal.

Re: [TCLCORE] TIP #349: New "-cargo" option for every Tk widget

[Zbigniew B. <zb...@is...>]

On Fri, Apr 17, 2009 at 12:39:18PM -0500, Damon Courtney wrote:

>> It strikes me that an option is rather limited -- give it about 2  
>> months
>> and we will see reusable bits of code on the wiki that do cool things
>> (like tooltips) using -cargo, and suddenly its not really available  
>> for "the script author" because (s)he is trying to juggle the 5 cool
>> extensions that all want to use it.

If I may add my "3 cents/pennies" (not sure, will it reach tcl-core list
since I'm not a subscriber - please forward, if possible):

I'm pretty sure, that all of you have much more experience than I have,
but I would again point your attention, that such possibility has been
durings years "extensively tested" in Clipper, and there wasn't any
"fight for access to field". And so I think, we can trust in programmers'
sanity, and it's pretty reasonable to name such fears as exaggerated.

In case of doubt all you need to do is to make a quick check "still free?"
before use.

> it's quite easy in Tcl.  I would just use a simple command trace on the 
> deletion of the widget.  Binding to <Destroy>, as some in the original 
> thread had suggested, has the side-effect of being easy to wipe out by 
> the developer if they choose to bind <Destroy> themselves.

There are people - like myself - who prefer the option, because this will
make the field contents "strictly bound" to a widget. Of course, there will
be still available other ways to achieve similar result (available even
now) - and in my opinion that methods are less convenient, and more
complicated. And because of this I decided to make this suggestion; I'm
pretty sure, many will be pleased with such new possibility.
-- 
				pozdrawiam / regards

						Zbigniew Baniewski

Re: [TCLCORE] TIP #349: New "-cargo" option for every Tk widget

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

Zbigniew Baniewski wrote:
>  TIP #349: NEW "-CARGO" OPTION FOR EVERY TK WIDGET
> ===================================================


This has been proposed once already, and rejected,
under the name "-clientdata" instead of "-cargo".
See TIP#42.

Tcl already provides a conventional mechanism to
associate arbitrary application data with widgets:
namespaced arrays using the widget name as the key
(or part of the key, if there are multiple pieces
of data).

The proposed -cargo option addresses precisely *one*
real disadvantage with the conventional technique,
namely, that the client data is automatically freed when
the widget is destroyed.  This takes a bit of extra
work with the conventional mechanism.

Conversely, the conventional mechanism addresses *all*
of the disadvantages of the proposed -cargo option.
To name a few:

- There's only one "-cargo" option.  Applications
often have more than one piece of data to associate
with the widget.

- There's only one "-cargo" option.  That means it
must be reserved for the application.  If a library
(like, say, a tooltip library -- one of the proposed
use cases) uses "-cargo" for private data then the
application may not; and if multiple libraries use
it, then the application can only use one such library.

- The TIP suggests that the above two problems may
be remedied by a convention that "-cargo" always
holds a dictionary instead of a scalar value, and
that libraries and applications use namespaced-prefixed
keys to avoid conflicts.  This of course nullifies
the other perceived advantage of having a universal
"place to hang stuff" widget option, convenient syntax:

    [$w cget -cargo]

would become:

    [dict get [$w cget -cargo] -myoption]

and

    [$w configure -cargo "..."]

would become:

    [$w configure -cargo [dict replace [$w cget -cargo] -myoption "..."]]

Namespaced arrays start to look a lot more appealing now.

- Applications can't reliably take advantage of a universal option
until and unless it's actually universal.  Even if "-cargo" were to
appear on all Core Tk widgets in 8.7, that would still leave
all of the other toolkits and packages (to name a few: BWidgets,
[incr Tk] and the iwidgets, the BLT widgets, tablelist, mclistbox,
mentry, tkhtml, zinc, tktable, tix, and tktreectrl; not to mention
any Snit-/XOtcl-/TclOO- based megawidgets.)

So applications have a choice: (1) don't use any add-on widget that
hasn't yet added a "-cargo" option; (2) be careful to only
use "-cargo" on widgets that support it; or (3) don't bother
with "-cargo" at all.

Namespaced arrays, again, look a lot more appealing now.

And for those who feel that namespaced arrays are still
too inconvenient, a number of other solutions have been
recently posted to comp.lang.tcl.  Most involve less
than a screenful of utility code, and most don't require
amending the core.  One of these might be a good candidate
for tklib.

In fact, of all the recently-proposed solutions, trying
to add a single universal "-cargo" option is arguably
the worst of the lot!  This idea deserves to be rejected.
Again.


--Joe English

  jen...@fl...

Re: [TCLCORE] TIP #349: New "-cargo" option for every Tk widget

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

On Apr 17, 2009, at 1:01 PM, Donald G Porter wrote:

> Damon Courtney wrote:
>> clientdata .b "foo"
>> clientdata .e [dict create foo bar]
>>
>> Whatever.  If you REALLY wanted to implement this in C, you could,  
>> but
>> it's quite easy in Tcl.  I would just use a simple command trace on
>> the deletion of the widget.
>
> Note this approach is even more general, permitting data to attach to
> any Tcl command, not limited to Tk widgets.

As well as any widgets in any other toolkit or extension, I might add.

D

Re: [TCLCORE] TIP #349: New "-cargo" option for every Tk widget

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

Damon Courtney wrote:
> clientdata .b "foo"
> clientdata .e [dict create foo bar]
> 
> Whatever.  If you REALLY wanted to implement this in C, you could, but  
> it's quite easy in Tcl.  I would just use a simple command trace on  
> the deletion of the widget.  

Note this approach is even more general, permitting data to attach to
any Tcl command, not limited to Tk widgets.

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

Re: [TCLCORE] TIP #349: New "-cargo" option for every Tk widget

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

> Why an option, rather than a common command?
>
> It strikes me that an option is rather limited -- give it about 2  
> months
> and we will see reusable bits of code on the wiki that do cool things
> (like tooltips) using -cargo, and suddenly its not really available  
> for
> "the script author" because (s)he is trying to juggle the 5 cool
> extensions that all want to use it.  Only then (too late) does someone
> suggest a protocol for using -cargo (e.g. make it a dict), but there  
> are
> already incompatible uses around.
>
> A "cargo" subcommand that is set up as a key/value mechanism would
> surely be a more generic solution?
>
> e.g.
> button .b
> .b cargo ;# lists cargo keys
> .b cargo key ;# returns the value for "key"
> .b cargo key val ;# sets the value for "key"
>
> This specific interface doesn't deal with deleting cargo values; one
> could assume that the value {} is effectively a delete; one could also
> specify whether ".b cargo key" returns empty or throws an error if key
> does not exist.

I would go one further and say why add a "cargo" method to every  
widget when you can just add a cargo command to attach data to a  
widget?  I argued this same point in the referenced thread, and no one  
listened.  By the way, I prefer clientdata or something like that.

clientdata .b "foo"
clientdata .e [dict create foo bar]

Whatever.  If you REALLY wanted to implement this in C, you could, but  
it's quite easy in Tcl.  I would just use a simple command trace on  
the deletion of the widget.  Binding to <Destroy>, as some in the  
original thread had suggested, has the side-effect of being easy to  
wipe out by the developer if they choose to bind <Destroy> themselves.

D

Re: [TCLCORE] TIP #349: New "-cargo" option for every Tk widget

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

Zbigniew Baniewski wrote:
>  TIP #349: NEW "-CARGO" OPTION FOR EVERY TK WIDGET 
> ===================================================

-cargo sounds odd. Why not -clientdata or -data? Otherwise, good idea that could 
be generalized to all widget types.

Re: [TCLCORE] TIP #349: New "-cargo" option for every Tk widget

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

Hi,
>  TIP #349: NEW "-CARGO" OPTION FOR EVERY TK WIDGET 
>   
Why an option, rather than a common command?

It strikes me that an option is rather limited -- give it about 2 months 
and we will see reusable bits of code on the wiki that do cool things 
(like tooltips) using -cargo, and suddenly its not really available for 
"the script author" because (s)he is trying to juggle the 5 cool 
extensions that all want to use it.  Only then (too late) does someone 
suggest a protocol for using -cargo (e.g. make it a dict), but there are 
already incompatible uses around.

A "cargo" subcommand that is set up as a key/value mechanism would 
surely be a more generic solution?

e.g.
button .b
.b cargo ;# lists cargo keys
.b cargo key ;# returns the value for "key"
.b cargo key val ;# sets the value for "key"

This specific interface doesn't deal with deleting cargo values; one 
could assume that the value {} is effectively a delete; one could also 
specify whether ".b cargo key" returns empty or throws an error if key 
does not exist.

Finally, it is worth pointing out that it is sometimes desirable for the 
"cargo" to be accessible as a variable name that can be used by 
-variable, trace, etc.  This is especially useful in the absence of a OO 
megawidget framework, as you can easily attach arbitrary "instance data" 
to a specific widget. 

Regards,
Twylite

Re: [TCLCORE] TIP #349: New "-cargo" option for every Tk widget

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

Zbigniew Baniewski wrote:
>  TIP #349: NEW "-CARGO" OPTION FOR EVERY TK WIDGET 

Can the author please comment on how this proposal compares to TIP 42?

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

[TCLCORE] TIP #349: New "-cargo" option for every Tk widget

[Zbigniew B. <zb...@is...>]

 TIP #349: NEW "-CARGO" OPTION FOR EVERY TK WIDGET 
===================================================
 Version:      $Revision: 1.1 $
 Author:       Zbigniew Baniewski <zb_at_ispid.com.pl>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.7
 Vote:         Pending
 Created:      Friday, 17 April 2009
 URL:          http://purl.org/tcl/tip/349.html
 WebEdit:      http://purl.org/tcl/tip/edit/349
 Post-History: 

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

 ABSTRACT 
==========

 This TIP proposes adding a *-cargo* option to every Tk widget that will 
 be kept free for code that uses the widget to use as it sees fit; the 
 Tk library will assign no interpretation to the option. 

 PROPOSAL 
==========

 TCL users have long been at a disadvantage not having a possibility to 
 attach arbitrary widget-related values (e.g., "tooltip"-texts) directly 
 to widget, being forced to use workarounds (e.g. external variables to 
 hold the data) or even entire additional packages/frameworks (like 
 Snit) exactly because of the lack of the proposed option. 

 So the proposal is "solutions instead of workarounds": let's introduce 
 the option - further named "-cargo" (the name taken from Clipper) - 
 which will cancel the current need for fixes of different kind. The 
 option should allow to access a string field (or even better: a 
 dictionary), allowing to keep there any widget-related data, choosen by 
 script creator. It's value should be accessible both by "cget" and 
 "percent substitution" (like "%C"). 

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

 In a talk at <URL:news:comp.lang.tcl> everyone - or almost everyone - 
 posting in the appropriate threads, appreciated the proposed solution 
 as useful. There were some fears about possible "clashes" while using 
 that option (or that the proposed option will be even "too useful"). I 
 would to mention here, that "cargo" idea has been taken from Clipper, 
 where - during over 20 past years - there is no evidence at all of any 
 "clashes" (neither of any other damage) only because of availability of 
 such option. Being sure, that TCL programmers aren't less skilled than 
 those Clipper guys, I cannot describe such fears differently, than as 
 not reasonable ones. 

 So because such option has been successfully tested in other language 
 (there are no complaints from Clipper programmers about any 
 "cargo"-harmness), there's no need for "prophecies" of the type "it 
 will do damage", because there has been proved exactly the contrary. 

 Some more possible usage gave Bryan Oakley in his post: 

       What sort of data would I potentially keep with a widget? Perhaps 
       an index that points to context sensitive help. Or, I might keep 
       an undo stack, or a copy of the original value. Think of a label 
       widget that automatically truncates it's text and adds "..." if 
       the widget is resized smaller than it's preferred size -- you 
       need to keep the unadulterated original value that you can refer 
       to as the widget grows and shrinks. Better to keep that with the 
       widget than in a global variable, IMO. Or, I could use it to keep 
       track of a "dirty" bit that gets set when the original value of a 
       radiobutton or checkbutton changes. Or I could store a database 
       primary key that points to where the data for the widget came 
       from. 

 I believe, that's not all, because we cannot predict today, what other 
 useful things can be done with option of such "universal" (not 
 "targetted") nature. Two things for sure: a) It'll make the life of 
 every TCL-scriptor easier, b) Its use won't be obligatory, if someone 
 will be afraid of "clashes" possibility, or something like this. 

 LICENSE 
=========

 This document has been placed in the public domain. 

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

 TIP AutoGenerator - written by Donal K. Fellows 

Re: [TCLCORE] Tcl/Tk 8.5.6 on Windows

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

Pan Chai wrote:
> I'll do that.. At the mean time, I went into the Tk codes and moved the 
> missing functions declaration from tkInt.h to tkIntDecls.h and created 
> appropriate defines in tkIntDecls.h.. Recompile the codes and the 
> symbols issues disappeared.
> 
> Not sure if that is the only thing that is required. But there is a 
> troubling issue, we compiled this code on the Linux machine and all the 
> missing symbols are present.

We know. It's exactly due to a change in policy (during the development
of 8.5) to make everything that was not explicitly part of a known
official (or semi-official) API into a purely private function. The aim
was to reduce the number of different interfaces that we would have to
support to the ones that we wanted. We knew that we'd have to increase
the scope back out again, but we hoped that people would tell us
earlier. (Back in 2007 when 8.5.0 first came out - or even during the
betas earlier that year - would have been much nicer for us... :-))

There is a possible temporary workaround by defining the right #defs
when building, but I'm not nearly a good enough Windows hacker to know
it; I've always relied on other people's build recipes on that platform.
You need someone else's advice there.

Donal.

Re: [TCLCORE] Tcl/Tk 8.5.6 on Windows

[Pan C. <Pan...@na...>]

I'll do that.. At the mean time, I went into the Tk codes and moved the 
missing functions declaration from tkInt.h to tkIntDecls.h and created 
appropriate defines in tkIntDecls.h.. Recompile the codes and the 
symbols issues disappeared.

Not sure if that is the only thing that is required. But there is a 
troubling issue, we compiled this code on the Linux machine and all the 
missing symbols are present.

Pan

Donal K. Fellows wrote:
> Pan Chai wrote:
>   
>> We have a software that use tcl/tk to build GUI, and we have been 
>> providing the Windows version of software (free of charge) to 
>> astronomical community for years. This year, we decided to bring in 
>> Tcl/Tk 8.5.6.
>>
>> However, I ran into issue of unresolved external symbols.. here are some 
>> of the symbols:
>>   TkStatePrintProc
>>   TkCanvasDashPrintProc
>>   TkOffsetPrintProc
>>   TkPixelPrintProc
>>   TkPixelParseProc
>>
>> Could you shine a light on the issue? Thank you.. I really am stuck..
>>     
>
> We started being much more strict about what symbols we exported from 
> the DLL. Since we didn't know anyone was making use of those, we made 
> them private. Ooops!
>
> It's a shame that you didn't email us about this a day or two ago, as 
> we've just done the 8.5.7 release which could have fixed this issue.
>
> It'd be best (i.e. fastest path to a fix) if you could raise an issue in 
> our bug tracker:
>     https://sourceforge.net/tracker/?func=add&group_id=12997&atid=112997
> (you might need an SF account to do this due to spam problems we've had) 
> and make sure you list *all* the symbols that you're having problems 
> with in the issue.
>
> Donal.
>   

-- 
___________________________________________________________________
Pan Chai                                Pan...@na...
NASA/GSFC Code 662       HEASARC        +1-301-286-8099 (voice)
Greenbelt MD 20771                      +1-301-286-1215 (fax)

Re: [TCLCORE] Tcl/Tk 8.5.6 on Windows

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

Pan Chai wrote:
> We have a software that use tcl/tk to build GUI, and we have been 
> providing the Windows version of software (free of charge) to 
> astronomical community for years. This year, we decided to bring in 
> Tcl/Tk 8.5.6.
> 
> However, I ran into issue of unresolved external symbols.. here are some 
> of the symbols:
>   TkStatePrintProc
>   TkCanvasDashPrintProc
>   TkOffsetPrintProc
>   TkPixelPrintProc
>   TkPixelParseProc
> 
> Could you shine a light on the issue? Thank you.. I really am stuck..

We started being much more strict about what symbols we exported from 
the DLL. Since we didn't know anyone was making use of those, we made 
them private. Ooops!

It's a shame that you didn't email us about this a day or two ago, as 
we've just done the 8.5.7 release which could have fixed this issue.

It'd be best (i.e. fastest path to a fix) if you could raise an issue in 
our bug tracker:
    https://sourceforge.net/tracker/?func=add&group_id=12997&atid=112997
(you might need an SF account to do this due to spam problems we've had) 
and make sure you list *all* the symbols that you're having problems 
with in the issue.

Donal.

[TCLCORE] Tcl/Tk 8.5.6 on Windows

[Pan C. <Pan...@na...>]

Hello Tcl-core team,

I have been running around trying to figure out the reason, perhaps you 
could help.

We have a software that use tcl/tk to build GUI, and we have been 
providing the Windows version of software (free of charge) to 
astronomical community for years. This year, we decided to bring in 
Tcl/Tk 8.5.6.

However, I ran into issue of unresolved external symbols.. here are some 
of the symbols:

TkStatePrintProc
TkCanvasDashPrintProc
TkOffsetPrintProc
TkPixelPrintProc
PkPixelParseProc

I used "dumpbin" on command line to see if these are in tk85.dll.. well, 
they are not. But they are in tk84.dll.

Could you shine a light on the issue? Thank you.. I really am stuck..
Pan

-- 
___________________________________________________________________
Pan Chai                                Pan...@na...
NASA/GSFC Code 662       HEASARC        +1-301-286-8099 (voice)
Greenbelt MD 20771                      +1-301-286-1215 (fax)

[TCLCORE] ANNOUNCE: Colibri version 0.2

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

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


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

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


WHAT DOES COLIBRI STAND FOR?
============================

Colibris, known in English as hummingbirds, are a family of birds 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 renown for their stationary and backward flight
abilities on par with flying insects, which allow them to feed on the nectar of
plants and flowers in-flight.

I've chosen 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 can have synonyms, i.e. words of any type
      * synonyms can form chains of arbitrary length, so a word can have several
        synonyms 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; one of the applications is to plug
        in externally managed structures (e.g. malloc/free)
      * 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 as they get promoted to
        older generations
      * promotion is done by moving whole pages between memory pools, optionally
        performing compaction when fragmentation exceeds a certain threshold,
        thus limiting the overhead and improving the cache-friendliness over time
      * contrary to reference-counting schemes (RC), GCs allow circular
        references without memory leaks; word synonym chains take advantage of
        this, being implemented as circular lists
      * 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 32kB. The source code is
heavily commented and follows the Tcl quality standards.


HOW DOES COLIBRI RELATE 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.


CHANGES SINCE VERSION 0.1
=========================

1. Major rewrite of GC code:

   - Roots are now sorted by generation for better performances with large number
     of instances.
   - Reworked parent-child relation handling. Now uses one cell per parent
     instead of one per parent-child pair, in combination with a parent flag
     (replaces the now suppressed generation flag).
   - Roots and parent-child relations now use cells allocated in a dedicated
     memory pool.
   - No more per-cell generation flag; all cells in a page belong to the same
     generation. Promotion is now immediate upon GC.
   - Promotion is done per page rather than per cell: whole pages are moved up
     one generation at each GC. CPU overhead is much smaller.
   - As a consequence, the first generation is always emptied at each GC, which
     speeds up further allocations.
   - The last collected generation is by default merged with the first
     uncollected one, but may be relocated if fragmentation reaches a certain
     threshold; this is done by copying individual cells instead of moving pages.
   - Relocation and redirection are now performed inline during the mark phase,
     versus during later steps in previous versions. The resulting code is much
     simpler, and avoids cache-intensive traversal of whole memory pools.

2. Improved performances in every domain thanks to point 1.

3. Added two high-level data types: vectors and lists.

   - Vectors are flat collections of words. Their size is limited, as they must
     fit within one single page. They are directly addressable.
   - Lists are linear collections of words, made by assembling vectors into
     balanced binary trees. They are to vectors what ropes are to strings. Like
     ropes, lists are immutable. Iterator and traversal APIs are provided.


PLANNED FEATURES FOR NEXT VERSION
=================================

1. Mutable data types with circular references and graceful degradation to
immutable types:

  - Mutable lists. Candidate models include unrolled linked lists and skip lists.
  - Maps (AKA dicts) with string keys. Candidate models include Patricia trees
    and Ternary Search Trees, but not hash tables.

2. Proper internal and user documentation


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.


GRAND UNIFICATION SCHEME
========================

A great side project would be to reimplement Tcl over Colibri as a replacement
for the current Tcl_Obj based code. Of course the resulting library would be
incompatible on an ABI level, but this would provide a great testbed for
Colibri in real-world cases (using pure script applications) as well as a
comparison point with the official Tcl core, and will possibly open the path to
Tcl9. This most likely involves a lot of work.


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.2.src.zip?use_mirror=
     - Windows binary: 
http://downloads.sourceforge.net/tcl9/colibri0.2.win32.zip?use_mirror=


LICENSE
=======

The license is the same as for Tcl.

[TCLCORE] Tcl/Tk 8.5.7 RELEASED

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

Tcl/Tk 8.5.7 Release Announcement
April 15, 2009

The Tcl Core Team is pleased to announce the 8.5.7 releases of the Tcl
dynamic language and the Tk toolkit.  This is the seventh patch release
of Tcl/Tk 8.5.  More details can be found below.  We would like to
express our gratitude to all those who submit bug reports and patches.
This information is invaluable in enabling us to identify and eliminate
problems in the core.

Where to get the new releases:
------------------------------

Tcl/Tk 8.5.7 sources are freely available as open source from the
Tcl Developer Xchange web site at:

         http://www.tcl.tk/software/tcltk/8.5.html

This web page also contains additional information about the releases,
including new features and notes about installing and compiling the
releases.  Sources are always available from the Tcl SourceForge
project's file distribution area:

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

Binaries for most major platforms are available from:

         http://www.activestate.com/Tcl

For additional information:
---------------------------

Please visit the Tcl Developer Xchange web site:

         http://www.tcl.tk/

This site contains a variety of information about Tcl/Tk in general, the
core Tcl and Tk distributions, Tcl development tools, and much more.

Summary of Changes since Tcl/Tk 8.5.6:
--------------------------------------

The following were the main changes in Tcl/Tk 8.5.7.  A complete list
can be found in the changes file at the root of the source tree.  The
more complete ChangeLog is also included with each source release.  This
is a patch release, so it primarily includes bug fixes and corrections
to erratic behavior.  Below are only the most notable changes.

    * Embeddable CoreFoundation notifier on Darwin.

    * Improved compatibility support in [load] on Darwin.

    * Restored Tk_CreatePhotoImageFormat compat with aMSN.

    * Stopped blurry large fonts on Vista.

    * New version 1.0.3 of platform package:
      - more details in identifiers for Darwin

    * New version 2.7.3 of http package:
      - fixes connect failure when partial lines returned

    * New version 2.3.1 of tcltest package:
      - removes several unsafe [eval]s

    * Menu image display fixes.

    * Fixed crash in Tk_MakeWindowExist() seen with gitk.

    * Fixed [file pathtype] on volumerelative paths.

    * Extended virtual events to work when Caps Lock is on.

    * Stopped memory leak in [file normalize].

    * Fixed crash on exit with [chan create]d channels.

    * Prevent crashes overflowing max string lengths.

    * Improved support for MSVC builds on _WIN64 systems.

--
Tcl Core Team and Maintainers
Don Porter, Tcl Core Release Manager

Re: [TCLCORE] How do I ....??

[Harald O. <Har...@El...>]

Thank you Steve for your question.
TCL user questions are on the TCL news group comp.lang.tcl:
	http://groups.google.com/group/comp.lang.tcl/topics
To your question:
TCL'er could not help very much I suppose.
Propably, you should store the "handles" returned by the radiobutton
calls in an array (or whatever) and apply methods later on like:
$c fconfigure -state disabled

c($Mode) = Radiobutton(frameAtt, text=text, indicatoron=0,
...
$c(S) fconfigure -state disabled

Hope this helps,
Harald

norseman schrieb:
> I looked at the list headers and this seems to be the default.
> If I'm in the wrong place - please re-direct me.
> 
> 
> Python, using Tkinter to translate, seems to use Tk "as is".
> I suspect TclTk people will have a much better idea of what can and 
> cannot be done with the Tk GUI.  SO:
> 
> QUESTION #1:
> 
> I'm using Python 2.5.2 and Tkinter vers??? (which came with python)
> The following pieces do in fact work. The mode/text in the AttTyp
> list is read into the Radiobutton widget and (with the rest of the
> code needed) works as expected.
> 
> AttTyp = [
>   ("S", "Single Use"),
>   ("I", "Intercropping"),
>   ("D", "Double Cropping"),
>   ("T", "Triple Cropping"),
>   ("M", "Mixed Land Use"),
>   ("","---------------"),
>   ("t", "Toggle Table Display"),
> ]
> #
> .                      The above is almost a simple cut and paste
> .                        from the program legend. And it is the
> .                        shortest, by far, length of list of them.
> .
> #
> for mode, text in AttTyp:
>   c = Radiobutton(frameAtt, text=text, indicatoron=0,
>        variable=AttVal, value=mode, command=getAttTyp)
>   c.pack()
> #
> 
> The question is, using this approach how do I control the individual
> accessibility of each button? (gray out one or another or more under
> program control)
> "This approach" being the "for" loop as opposed to manually entering the 
> mode/text in line after line after line after....
> The computer is supposed to do the mundane, isn't it?
> 
> 
> QUESTION #2:
> 	Got the answer just before sending this.
> 
> 
> 
> Steve
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 


-- 
ELMICRON Dr. Harald Oehlmann GmbH
Koesener Str. 85
D - 06618 Naumburg
Phone: +49 (0)3445 781120
Fax: +49 (0)3445 770142
www.Elmicron.de
German legal references:
Geschaeftsfuehrer: Dr. Harald Oehlmann
UST Nr. / VAT ID No.: DE206105272
HRB 12803 / Amtsgericht Halle-Saalkreis

[TCLCORE] How do I ....??

[norseman <nor...@hu...>]

I looked at the list headers and this seems to be the default.
If I'm in the wrong place - please re-direct me.


Python, using Tkinter to translate, seems to use Tk "as is".
I suspect TclTk people will have a much better idea of what can and 
cannot be done with the Tk GUI.  SO:

QUESTION #1:

I'm using Python 2.5.2 and Tkinter vers??? (which came with python)
The following pieces do in fact work. The mode/text in the AttTyp
list is read into the Radiobutton widget and (with the rest of the
code needed) works as expected.

AttTyp = [
  ("S", "Single Use"),
  ("I", "Intercropping"),
  ("D", "Double Cropping"),
  ("T", "Triple Cropping"),
  ("M", "Mixed Land Use"),
  ("","---------------"),
  ("t", "Toggle Table Display"),
]
#
.                      The above is almost a simple cut and paste
.                        from the program legend. And it is the
.                        shortest, by far, length of list of them.
.
#
for mode, text in AttTyp:
  c = Radiobutton(frameAtt, text=text, indicatoron=0,
       variable=AttVal, value=mode, command=getAttTyp)
  c.pack()
#

The question is, using this approach how do I control the individual
accessibility of each button? (gray out one or another or more under
program control)
"This approach" being the "for" loop as opposed to manually entering the 
mode/text in line after line after line after....
The computer is supposed to do the mundane, isn't it?


QUESTION #2:
	Got the answer just before sending this.



Steve

[TCLCORE] Tcl/Tk 8.5.7 Release Candidates

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

As Kevin Kenny relayed for me a few days ago (thanks!), I've put Release
Candidate files for Tcl/Tk 8.5.7 on the ftp site:

     ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tcl8.5.7rc0-src.tar.gz
     ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tcl8.5.7rc0-html.tar.gz
     ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tk8.5.7rc1-src.tar.gz

Draft release notes are also online for review:

http://sourceforge.net/project/shownotes.php?group_id=10894&release_id=675071

Please review and test the releases for serious regressions.  Expect
to make actual release on April 15.

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

[TCLCORE] Tcl 8.5.7rc

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

Don Porter informs me that he's suffering from an email outage
at the moment.  He's asked me to announce for him that draft
release notes for Tcl/Tk 8.5.7 are available at

https://sourceforge.net/project/shownotes.php?group_id=10894&release_id=675071

and to request proofreading by interested parties.  He further
notes that the release candidates are available at

ftp://ftp.tcl.tk/pub/tcl/tcl8_5/

and requests prerelease testing.

-- 
73 de ke9tv/2, Kevin (for Don)

Re: [TCLCORE] direct access to canvas pixels

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

On 02/04/2009 3:51 AM, Arjen Markus wrote:
> On 2009-04-02 12:41, Paul Alfille wrote:
> 
>> Thank you for the responses. I guess I misspoke. Having the canvas 
>> available as a svg (or other supported vector graphics) format would be 
>> even better. My personal use was for making shrunken views of the 
>> current canvas available as an icon or menu button. Another use would be 
>> creating a drawing program. This just seems like an underdeveloped 
>> portion of the Tk toolkit.
> 
> you can of course use the canvas scale subcommand to shrink the image
> and the Img package to capture it in an image. Or you could use the
> tkpath extension to directly manipulate SVGs.

On a related note, we recently beat the tkpath build system into shape. 
  It now works across the board and you'll find it in the teapot for 
Windows, OS X soon (in build rotation).  Not for Linux or the others 
until we update systems to have the necessary Cairo prereqs.

Jeff

Re: [TCLCORE] direct access to canvas pixels

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

On 2009-04-02 12:41, Paul Alfille wrote:
> 

> Thank you for the responses. I guess I misspoke. Having the canvas 
> available as a svg (or other supported vector graphics) format would be 
> even better. My personal use was for making shrunken views of the 
> current canvas available as an icon or menu button. Another use would be 
> creating a drawing program. This just seems like an underdeveloped 
> portion of the Tk toolkit.
> 

Hi Paul,

you can of course use the canvas scale subcommand to shrink the image
and the Img package to capture it in an image. Or you could use the
tkpath extension to directly manipulate SVGs.

Regards,

Arjen


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.

Re: [TCLCORE] direct access to canvas pixels

[Paul A. <pau...@gm...>]

On Thu, Apr 2, 2009 at 6:07 AM, Donal K. Fellows <
don...@ma...> wrote:

> Paul Alfille wrote:
>
>> Is it against the tcl philosophy to have pixel access available in the
>> core language, or merely a matter of no proper process and implementation?
>>
>
> It's just that we put the pieces together differently. Canvases use a
> vector-graphics conceptual model and not a raster-graphics model. This
> means that you have to put a raster plane on the canvas (e.g. a window
> or, more usefully here, a photo image) and draw on that.
>
> Doing it this way makes some things easier, and others more difficult.
> Myself, I like having the widget know about the things I'm drawing on
> it, since that lets me do fancy features ("hypergraphics") more easily.
>
> Donal.
>
Thank you for the responses. I guess I misspoke. Having the canvas available
as a svg (or other supported vector graphics) format would be even better.
My personal use was for making shrunken views of the current canvas
available as an icon or menu button. Another use would be creating a drawing
program. This just seems like an underdeveloped portion of the Tk toolkit.

Paul Alfille

Re: [TCLCORE] direct access to canvas pixels

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

Paul Alfille wrote:
> Is it against the tcl philosophy to have pixel access available in the 
> core language, or merely a matter of no proper process and implementation?

It's just that we put the pieces together differently. Canvases use a
vector-graphics conceptual model and not a raster-graphics model. This
means that you have to put a raster plane on the canvas (e.g. a window
or, more usefully here, a photo image) and draw on that.

Doing it this way makes some things easier, and others more difficult.
Myself, I like having the widget know about the things I'm drawing on
it, since that lets me do fancy features ("hypergraphics") more easily.

Donal.

Re: [TCLCORE] direct access to canvas pixels

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

On 01/04/2009 4:32 PM, Paul Alfille wrote:
> On Wed, Apr 1, 2009 at 9:19 AM, Griffin, Brian <bri...@me... 
> <mailto:bri...@me...>> wrote:
> 
>     That being said, the answer is no, direct pixel access on the canvas
>     is not possible.  Pixel access is possible in an image and images
>     can be placed on the canvas.  I don't know if that will help.
> 
> Is it against the tcl philosophy to have pixel access available in the 
> core language, or merely a matter of no proper process and implementation?

This is a matter of process only.  Images are the containers for 
pixel-level access of an area.  Canvases can do that with single point 
lines if you want, but don't otherwise support "dots".  I don't think 
anyone would be against improvements in either place should someone 
present a good proposal and implementation (TIPd of course).

Jeff