tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Seeking USE_TCLALLOC users

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

 >> ....Is anyone making any use of a USE_TCLALLOC build
>> of Tcl? 

Konovalov, Vadim (Vadim)** CTR ** wrote:
> I used it,...

Thanks for the reply.  That's enough for me to keep it around.

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

[TCLCORE] TIP 356 Accepted

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

Donald G Porter wrote:
> Please cast votes on TIP 356 by [clock format 1253721600].

TIP 356 Accepted by 7-0-0 vote.
YES: Kenny, Sofer, Porter, English, Steffen, Fellows, Nijtmans


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

Re: [TCLCORE] Seeking USE_TCLALLOC users

[Konovalov, V. (Vadim)** C. ** <vko...@al...>]

> As mentioned in Tcl Bug 2557696, I believe the memory allocation
> routines enabled when Tcl sources are built with the USE_TCLALLOC
> directive have some problems.  I think there are 64-bit issues and
> argument overflow checking issues.  I've been correcting such things
> in other allocators that I know get used.
> 
> I'd rather not waste time fixing the USE_TCLALLOC allocators if it
> no longer has any users.  I'd rather just purge the dead code.  I
> would do this only on the HEAD sources.
> 
> So here's the call.  Is anyone making any use of a USE_TCLALLOC build
> of Tcl?  Can anyone report successful test or use of it for any
> productive purpose in the last year or two?

I used it, for the following reasons:

- this speeds up the wince build significantly (although I haven't built it for several years. I use old binaries, but will occasionally rebuild it)
- Sometimes I compile together Perl with Tcl/Tk with USE_PERLMALLOC and USE_TCLALLOC and substitute memory allocation calls with Perl_malloc. This gains me a common allocator, which happens to be a little bit faster, to my eye (but  I did not any real benchmarking, so I could be wrong)

I would like to see USE_TCLALLOC not reaped, I think that it is useful.

I would not be really really sad if it will go away, so I will accept reaping it with a proper courage, but my preference is to leave it.

Instead, is it possible to substitute Tcl allocatot with a 3rd party already tested one, with interface remaining the same?
As I already said, I even used Perl's allocator succesfully, but I guess it is not the only alternative :)

On the other side, reaping USE_TCLALLOC will be transparent to me if, while reaping content, the interface to allocator will be unchanged, so I will continue using Perl's allocator where applicable, and system's one otherwise.

Best regards,
Vadim.

[TCLCORE] Seeking USE_TCLALLOC users

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

As mentioned in Tcl Bug 2557696, I believe the memory allocation
routines enabled when Tcl sources are built with the USE_TCLALLOC
directive have some problems.  I think there are 64-bit issues and
argument overflow checking issues.  I've been correcting such things
in other allocators that I know get used.

I'd rather not waste time fixing the USE_TCLALLOC allocators if it
no longer has any users.  I'd rather just purge the dead code.  I
would do this only on the HEAD sources.

So here's the call.  Is anyone making any use of a USE_TCLALLOC build
of Tcl?  Can anyone report successful test or use of it for any
productive purpose in the last year or two?

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

[TCLCORE] ANNOUNCE: Colibri version 0.3

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

ANNOUNCE: Colibri version 0.3
=============================
As part of my ongoing work on the Cloverfield project, I am pleased to announce
the third 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.2
=========================

1. Multithreading support

   - Appartment model, each thread has its own memory pool

2. Linux port and code portability improvements

   - Now uses C99 types such as int8_t and uintptr_t
   - Moved platform-specific code to platform/* subtree
   - Linux version uses mmap and pthreads

3. Test app overhaul

   - Each test has its own C file
   - Multithreading support


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 the source archive primarily
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.

I also uses a CentOS 5.2 Linux VMware image for Linux development, so the
archive also includes minimalist GNU makefiles for building using the included
GCC compiler. However it makes no use of other parts of the GNU toolchain
(autoconf and the like).

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 both
Windows and Unix (Linux) version is provided, the latter using mmap. Porting to
other systems should require only minimal effort, as the platform-specific code
is limited to a handful of functions gathered in a platform-specific source
tree. 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. "Exception handling"
includes what to do upon allocation failures due to low-memory conditions. As
Colibri uses a non-prehemptive model it cannot stop-the-world and GC like other
implementations do to free memory. More generally, due to the nature of the
model, such conditions would only occur when the memory is actually used or
when the GC is not triggered often enough (for example during a long computation
phase involving a large number of temporary allocations), both being
unrecoverable anyway without explicit programming.

Tests have been run extensively during development, both on stability and
performance. However Colibri lacks a real test suite (including unit testings).
The source includes a test application that has to be hand-edited to run or
customize specific tests. Note that some tests are configured in such a way
that they require a system with a large memory size (2GB), so make sure to tune
their parameters before running them.

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.3.src.zip?use_mirror=
     - Windows binary: 
http://downloads.sourceforge.net/tcl9/colibri0.3.win32.zip?use_mirror=
     - Linux binary (x86): 
http://downloads.sourceforge.net/tcl9/colibri0.3.linux-x86.zip?use_mirror=


LICENSE
=======

The license is the same as for Tcl.

Re: [TCLCORE] CFV: TIP 356

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

Donald G Porter wrote:
> Please cast votes on TIP 356 by [clock format 1253721600].

TIP#356: YES

Regards,
          Jan Nijtmans

Re: [TCLCORE] CFV: TIP 356

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

Donald G Porter wrote:
> Please cast votes on TIP 356 by [clock format 1253721600].

TIP#356: YES

Donal.

Re: [TCLCORE] CFV: TIP 356

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

On Fri, Sep 18, 2009 at 17:50, Donald G Porter <dg...@ni...> wrote:
> Please cast votes on TIP 356 by [clock format 1253721600].

TIP#356: YES

Daniel

Re: [TCLCORE] CFV: TIP 356

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

Donald G Porter wrote:
>
> Please cast votes on TIP 356 by [clock format 1253721600].


TIP#356: YES.


--Joe English

  jen...@fl...

Re: [TCLCORE] CFV: TIP 356

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

Donald G Porter wrote:
> Please cast votes on TIP 356 by [clock format 1253721600].

Oh, yeah.  My vote:

TIP 356: YES


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

Re: [TCLCORE] CFV: TIP 356

[miguel s. <mig...@gm...>]

Donald G Porter wrote:
> Please cast votes on TIP 356 by [clock format 1253721600].
> 
> Thanks.
> 

My vote:
   TIP 356: YES

Miguel

[TCLCORE] CFV: TIP 356

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

Please cast votes on TIP 356 by [clock format 1253721600].

Thanks.

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

Re: [TCLCORE] TIP #356: NR-enabled Substitutions for Extensions

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

Donald G Porter wrote:
> Don Porter wrote:
>>  TIP #356: NR-ENABLED SUBSTITUTIONS FOR EXTENSIONS 
> 
> Since there was no controversy over TIP 353, I don't expect any for
> this one.  Unless someone requests otherwise, I'll call a vote tomorrow
> with plans to close it next Wednesday.  If anyone wants a different
> plan for any reason, I'll happily make adjustments.
> 

Since I'm going to be on the road nearly continuously between
now and when I return from Portland, let me record an advance
YES for the TIP as it stands.  I'll try to stay on top of tcl-core
traffic in the interim, but make no promises.

Re: [TCLCORE] TIP #356: NR-enabled Substitutions for Extensions

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

Don Porter wrote:
>  TIP #356: NR-ENABLED SUBSTITUTIONS FOR EXTENSIONS 

Since there was no controversy over TIP 353, I don't expect any for
this one.  Unless someone requests otherwise, I'll call a vote tomorrow
with plans to close it next Wednesday.  If anyone wants a different
plan for any reason, I'll happily make adjustments.

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

[TCLCORE] TIP #356: NR-enabled Substitutions for Extensions

[Don P. <dg...@us...>]

 TIP #356: NR-ENABLED SUBSTITUTIONS FOR EXTENSIONS 
===================================================
 Version:      $Revision: 1.1 $
 Author:       Don Porter <dgp_at_users.sf.net>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.6
 Vote:         Pending
 Created:      Thursday, 17 September 2009
 URL:          http://purl.org/tcl/tip/356.html
 WebEdit:      http://purl.org/tcl/tip/edit/356
 Post-History: 

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

 ABSTRACT 
==========

 This TIP proposes the new public routine *Tcl_NRSubstObj* to provide 
 extension commands that evaluate Tcl substitutions the ability to do so 
 in a non-recursive manner. 

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

 Continuing in the path of [TIP #322] and [TIP #353], we want extensions 
 to be able to create NR-enabled commands, and any command procedures 
 currently calling the *Tcl_SubstObj* routine are not NR-enabled. The 
 solution is to provide the NR-enabled counterpart. 

 PROPOSAL 
==========

 Add the following routine to Tcl's public interface: 

       int *Tcl_NRSubstObj*(Tcl_Interp */interp/, Tcl_Obj */objPtr/, int 
       /flags/) 

 This routine places on the NR stack a request that the Tcl 
 non-recursive trampoline evaluate the /objPtr/ value as a Tcl 
 substitution in interpreter /interp/, as controlled by the value of 
 /flags/. The /flags/ value is the same combination of 
 *TCL_SUBST_BACKSLASHES*, *TCL_SUBST_COMMANDS*, and 
 *TCL_SUBST_VARIABLES* that control *Tcl_SubstObj*. This routine returns 
 the value *TCL_OK*, since there is (currently) no way this request 
 operation can fail. The proposed interface still provides for an int 
 return value so that future revisions to Tcl's internals have the 
 freedom to change that without need to change the public interface. 

 After the trampoline completes the requested substitution, it will pass 
 the return code, either *TCL_OK* or *TCL_ERROR*, to the next callback 
 on the NR-stack, and either the result of the substitution or the error 
 message will be stored in the result of /interp/. The caller of 
 *Tcl_NRSubstObj* may also call *Tcl_NRAddCallback* to request a 
 *Tcl_NRPostProc* callback routine be placed on the NR stack to receive 
 these results, if needed to achieve the task the caller is performing. 

 IMPLEMENTATION 
================

 The proposed routine is already present in the HEAD of Tcl as the 
 internal routine *TclNRSubstObj*. This proposal would simply promote it 
 to Tcl's public interface. 

 COMPATIBILITY 
===============

 There should be no compatibility issues, since at the interface level 
 this is just the addition of a new routine. 

 MIGRATION 
===========

 As an example for extensions to follow, consider this template for a 
 *Tcl_ObjCmdProc* currently calling *Tcl_SubstObj*. 

   int ObjCmd(ClientData cd, Tcl_Interp *interp, int objc, Tcl_Obj *const objv[])
       Tcl_Obj *resultPtr;
       /* determine text to be substituted, objPtr */
       /* determine flags value to control substitution */
       resultPtr = Tcl_SubstObj(interp, objPtr, flags);
       if (resultPtr == NULL) {return TCL_ERROR}
       /* resultPtr holds substitution result; continue */
   }
   
   Tcl_CreateObjCommand(interp, name, ObjCmd, /* ... */);

 To use *Tcl_NRSubstObj* to NR-enable this command, rewrite along these 
 lines: 

   int ObjCmd(ClientData cd, Tcl_Interp *interp, int objc, Tcl_Obj *const objv[])
   {   return Tcl_NRCallObjProc(interp, NRObjCmd, cd, objc, objv);  }
   
   int NRObjCmd(ClientData cd, Tcl_Interp *interp, int objc, Tcl_Obj *const objv[])
   {   
       /* determine text to be substituted, objPtr */
       /* determine flags value to control substitution */
       Tcl_NRAddCallback(interp, Callback, /*...*/);
       return Tcl_NRSubstObj(interp, objPtr, flags);
   }
   
   int Callback(ClientData data[], Tcl_Interp *interp, int code)
   {   Tcl_Obj *resultPtr;
       if (code == TCL_ERROR) {return TCL_ERROR;}
       resultPtr = Tcl_GetObjResult(interp);
       /* resultPtr holds expression result; continue */
   }
   
   Tcl_NRCreateCommand(interp, name, ObjCmd, NRObjCmd, /*...*/);

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

 This document has been placed in the public domain. 

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

 TIP AutoGenerator - written by Donal K. Fellows 

Re: [TCLCORE] app server

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

ezhillianzz wrote:
>   I have a stand alone application developed using tcl tk. I want to 
> port this application in a web server. I have absolutely no idea, how to 
> do this . Can any one please tell me how to do that in a detailed manner.

The correct place to ask this question is the comp.lang.tcl newsgroup. 
You can subscribe to this through Google Groups.
     http://groups.google.co.uk/group/comp.lang.tcl/topics

The tcl-core mailing list is for development *of* Tcl itself (and Tk), 
and not for general questions about how to develop *with* Tcl.

Donal.

[TCLCORE] app server

[ezhillianzz <dav...@gm...>]

hi all,
  I have a stand alone application developed using tcl tk. I want to port
this application in a web server. I have absolutely no idea, how to do
this . Can any one please tell me how to do that in a detailed manner.

[TCLCORE] app server

[ezhillianzz <dav...@gm...>]

hi all,

Re: [TCLCORE] Representation vs Debugobj vs Tweezer

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

On 9/16/09, Jeff Hobbs <je...@ac...> wrote:
> On 16/09/2009 9:32 AM, Alexandre Ferrieux wrote:
>
> >  (2) I'm not sure of the portability of the %p sprintf specifier
> >
>
>  It's portable and what should be used.
>

Thanks. Cleaned up and committed.

-Alex

Re: [TCLCORE] Representation vs Debugobj vs Tweezer

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

On 16/09/2009 9:32 AM, Alexandre Ferrieux wrote:
>   (2) I'm not sure of the portability of the %p sprintf specifier

It's portable and what should be used.

Re: [TCLCORE] Representation vs Debugobj vs Tweezer

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

On 9/16/09, Donal K. Fellows <don...@ma...> wrote:
> Alexandre Ferrieux wrote:
>
> > So, would you basically accept a patch returning (not outputting):
> >
> >    value is a bignum with a refcount of 14, object pointer at
> > 0x12345678 and intrep at 0x45671234
> >
>
>  I can live with that, except don't include the intrep location because not
> all intreps are locations (and understanding the intrep is probably a few
> dozen steps too far). The main things though are that it should be
> human-readable (to discourage non-debugging use) and yet should be in the
> interpreter result (to allow for remote debugging; having to fiddle around
> with capturing stdout would suck, and I exposed the bytecode disassembler to
> avoid that sort of thing).
>
>  Hope that makes sense.

Patch updated in the SF entry, please review.

Remarks:
 (1) I kept (in hex) both ptr1 and ptr2 of the intrep and removed the
"at" (since they are not necessarily pointers as you rightfully point
out).
 (2) I'm not sure of the portability of the %p sprintf specifier
 (3) I welcome education as to the proper macros for string buffer
sizes large enough to hold an integer, a pointer, etc.

-Alex

Re: [TCLCORE] Representation vs Debugobj vs Tweezer

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

Alexandre Ferrieux wrote:
> So, would you basically accept a patch returning (not outputting):
> 
>     value is a bignum with a refcount of 14, object pointer at
> 0x12345678 and intrep at 0x45671234

I can live with that, except don't include the intrep location because 
not all intreps are locations (and understanding the intrep is probably 
a few dozen steps too far). The main things though are that it should be 
human-readable (to discourage non-debugging use) and yet should be in 
the interpreter result (to allow for remote debugging; having to fiddle 
around with capturing stdout would suck, and I exposed the bytecode 
disassembler to avoid that sort of thing).

Hope that makes sense.

Donal.

Re: [TCLCORE] Representation vs Debugobj vs Tweezer

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

On Wed, 16 Sep 2009 01:38:34 +0200, 
Alexandre Ferrieux <ale...@gm...> wrote:

>>  Indeed, and actually I wouldn't mind seeing a dict similar to the
>> output from 'info frame', but if Donal wants it to be slightly more
>> painful to parse, I won't grumble.  ;)
> Yes, but beware not to use a real Tcl container like dicts, it will +1
> the refcount and complicate refcount analysis. Also, the conversion to
> string rep would be dangerous, since the tool is most useful on very
> large objects that you absolutely never want to see duplicated nor
> printed.

I actually did that, by snagging the refcount before including the
object, and only if the object actually HAS a string rep.  (I was using
a list, because dict's only existed as a script prototype at the
time.)


> So it would seem safer to generate a pure string being a short
> sentence, starting as shown above and ending with
>     .. and no string rep
> or
>     .. and string rep: AEZAREZAREZREAZA...

I actually prefer that, and was going to do that myself, but couldn't
be bothered.  I didn't care often, beyond whether or not the string rep
actually existed, and [dict exists] with the object itself included
(AFTER reading the refcount) did that without having to mess around with
truncation and what-not.  As long as I remembered to destroy the list
before I looked at that same variable again, it was invisible.

The important bits for me, were the refcount, the question of whether
the string rep exists, and what the internal type is.

The pointer to the internal data is, well, problematic.  You can have a
stab at getting most of the internal data, but I found the best way to
achieve the intent of that item, is to actually dump the entire TclObj
in hex form (alternatively, just the intrep portion).  Anyone who cares,
knows where in the string to look for what they expect to find.


The debate on dict vs. string, is kinda silly.  The string is trivially
parsable as you suggested, and some idiot is going to rely on it no
matter what you do.  So make it a usefully inclusive dict and move on.


As an aside...  Why yours DIDN'T work for me, Alexandre, is that I was
often working remotely through what is essentially a backdoor into a
web server I was building whereby a given page would "eval" the
provided POST data (yeah, major dangerosa, but it wasn't "live", and
there was a long random string that had to be passed in the request to
enable it, etc.).  The up-shot of that, is that std* was a three lane
highway to /dev/null, so debugobj really wouldn't have helped very
much.  Otherwise, the idea of sending it to stdout would have been
pretty cool...  Although no doubt then people would jump through hoops
to capture the stdout of their application and filter it to get at the
data programmatically just the same, so I personally don't see that it's
worth the annoyance.

Why I was doing this myself, I was trying to learn how to write C
packages.  In particular, I was writing a kind of anti-[future]
implementation (strangely, it was called future also) to solve an issue
I was having with refcounted OOP.  My [future] package allowed me to
trigger a script on EITHER first use or destruction time, allowing me
to return the ID of the newly created "object", linked to an unref when
it went out of scope, causing the newly created object to self destruct
if nothing cared.  The main motivation, was that the object being
returned was actually a middle-stage by-product of something else, which
happened to be occasionally useful to the caller, and the alternative
was to set up an idle event to kill the internal reference (the idea
of sticking a variable in the calling proc really doesn't appeal to
me - it'd be nice if there was a way to "trace add proc finished").
The idle thing was ugly, and at worst dangerous.  Anyhow...

As an interesting side-point, this is what, the forth recent incarnation
of this tool?  [debugobj], tweezer, my [future debug], and now
[representation]...  It's obviously a wanted feature, as frighteningly
internal as it may be.


Would it make sense to have the entire unsupported namespace as a
core-included package, just to emphasise that these things aren't
supposed to be used?

-- 
Fredderic

Debian/unstable (LC#384816) on i686 2.6.30-1-686 2009 (up 8 days, 17:40)

Re: [TCLCORE] Representation vs Debugobj vs Tweezer

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

On 9/16/09, Alexandre Ferrieux <ale...@gm...> wrote:
>
> Yes, but beware not to use a real Tcl container like dicts, it will +1
>  the refcount and complicate refcount analysis. Also, the conversion to
>  string rep would be dangerous, since the tool is most useful on very
>  large objects that you absolutely never want to see duplicated nor
>  printed.

Oops, just realized you were not suggesting to have the object itself
mentioned in the dict.
Ignore my remarks about this. Only remains the idea that a dict is
awfully too easy to extract data from ;-)

-Alex

Re: [TCLCORE] Representation vs Debugobj vs Tweezer

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

>  Indeed, and actually I wouldn't mind seeing a dict similar to the output
> from 'info frame', but if Donal wants it to be slightly more painful to
> parse, I won't grumble.  ;)

Yes, but beware not to use a real Tcl container like dicts, it will +1
the refcount and complicate refcount analysis. Also, the conversion to
string rep would be dangerous, since the tool is most useful on very
large objects that you absolutely never want to see duplicated nor
printed.

So it would seem safer to generate a pure string being a short
sentence, starting as shown above and ending with

    .. and no string rep

or

    .. and string rep: AEZAREZAREZREAZA...

(the three dots at the end to show truncation at  a few chars)

OK?

-Alex