tcl-core archive @ ASPN

[TCLCORE] help with a weird error

Max Zimet (maxzimet@...)

Hey-
I have been using 2 resources to learn tcl: the interactive window and actual applications
typed in Notepad and then run. (I'm on a windows) Well, when I run the following code in
the interactive window, it works, but when it's run in an app, I get the error: "child
killed: SIGABRT". I don't know what I'm doing wrong. Thanks a ton, in advance.

Here's the code:

set file {C:\Documents and Settings\Max Zimet\Desktop\Programs\tcl\invert.tcl}
set pipe {C:\Tcl\bin\base-tcl-thread-win32-ix86.exe}
puts -nonewline "Enter a word to be reversed: "
gets stdin input
set invert [exec $pipe $file << $input]
puts "Your input, $input, reversed is $invert"

The file in $file simply takes the input and reverses it. The error is caused by $input in
the line: 'set invert [exec $pipe $file << $input]' according to the error log.

[TCLCORE] TIP #270: Utility C Routines for String Formatting

Don Porter (dgp@...)

TIP #270: UTILITY C ROUTINES FOR STRING FORMATTING 
====================================================
 Version:      $Revision: 1.1 $
 Author:       Don Porter 
 State:        Draft
 Type:	       Project
 Tcl-Version:  8.5
 Vote:	       Pending
 Created:      Monday, 19 June 2006
 URL:	       http://purl.org/tcl/tip/270.html
 WebEdit:      http://purl.org/tcl/tip/edit/270
 Post-History: 

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

 ABSTRACT 
==========

 This TIP proposes new public C utility routines for the convenience of 
 C-coded extensions and embedded uses of Tcl. 

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

 During development of Tcl 8.5, several internal routines have been 
 created that provide useful string formatting functions. These routines 
 are most commonly used in the construction of error messages, but have 
 a generally useful nature. The Tcl source code itself makes significant 
 use of them. 

 PROPOSED CHANGES 
==================

 Add the following routines to Tcl's public interface: 

 TCL_OBJPRINTF 
---------------

       int *Tcl_ObjPrintf*(Tcl_Interp */interp/, Tcl_Obj */objPtr/, 
       CONST char */format/, ...) 

 This routine serves as a replacement for the common sequence: 

    char buf[SOME_SUITABLE_LENGTH];
    sprintf(buf, format, ...);
    Tcl_AppendStringsToObj(objPtr, buf, NULL);

 Use of the proposed routine is shorter and doesn't require the 
 programmer to determine *SOME_SUITABLE_LENGTH*. The return value is 
 either *TCL_OK* or *TCL_ERROR*. When *TCL_ERROR* is returned and 
 /interp/ is non-NULL, an error message is written as the result of 
 /interp/. The formatting is done with the same engine (internal routine 
 *TclAppendFormattedObjs*) that drives Tcl's *format* command. This 
 means the set of supported conversion specifiers is that of *format* 
 and not that of /sprintf()/ where the two sets differ. When a 
 conversion specifier includes a precision, the value is taken as a 
 number of bytes, as /sprintf()/ does, and not as a number of 
 characters, as *format* does. The variable number of arguments passed 
 in should be of the types that would be suitable for passing to 
 /sprintf()/. Note in this example usage, /x/ is of type *long*. 

     long x = 5;
     Tcl_Obj *objPtr = Tcl_NewObj();
     Tcl_ObjPrintf(NULL, objPtr, "Value is %d", x);

 TCL_FORMATOBJ 
---------------

       int *Tcl_FormatObj*(Tcl_Interp */interp/, Tcl_Obj */objPtr/, 
       CONST char */format/, ...) 

 This routine is similar to *Tcl_ObjPrintf*. The key difference is that 
 its variable number of arguments are all expected to be of type 
 *Tcl_Obj **. Choosing between *Tcl_ObjPrintf* and *Tcl_FormatObj* 
 depends on what form the data to be formatted is already in. 

 TCL_APPENDLIMITEDTOOBJ 
------------------------

       int *Tcl_AppendLimitedToObj*(Tcl_Obj */objPtr/, CONST char 
       */bytes/, int /length/, int /limit/, CONST char */ellipsis/) 

 This routine is used to append a string, but to impose a limit on how 
 many bytes are appended. This can be handy when the string to be 
 appended might be very large, but the value being constructed should 
 not be allowed to grow without bound. A common usage is when 
 constructing an error message, where the end result should be kept 
 short enough to be read. Bytes from /bytes/ are appended to /objPtr/, 
 but no more than /limit/ bytes total are to be appended. If the limit 
 prevents all /length/ bytes that are available from being appended, 
 then the appending is done so that the last bytes appended are from the 
 string /ellipsis/. This allows for an indication of the truncation to 
 be left in the string. 

 When /length/ is -1, all bytes up to the first zero byte are appended, 
 subject to the limit. When /ellipsis/ is NULL, the default string *...* 
 is used. The number of bytes appended can be less than the lesser of 
 /length/ and /limit/ when appending fewer bytes is necessary to append 
 only whole multi-byte characters. 

 For all three of these proposed routines, the *Tcl_Obj* being appended 
 to must be unshared. 

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

 This proposal includes only new features. It is believed that existing 
 scripts and C code that operate without errors will continue to do so. 

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

 The actual code is already complete as internal routines corresponding 
 to the proposed public routines. Implementation is just an exercise in 
 renaming, placing in stub tables, documentation, etc. 

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

 This document has been placed in the public domain. 

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

 TIP AutoGenerator - written by Donal K. Fellows 


_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Handles vs. internal rep's

Jean-Claude Wippler (jcw@...)

Donald G Porter wrote:

> To me, both your sketches and TIP 126 work on the same problem, and
> both have a spirit of trying to tinker around the margins and achieve
> not much more than having Tcl be somewhat less likely to cause
> trouble.  Each still leaves lots of cases where the EIAS nature of
> Tcl and the "my value is *not* a string" behavior you require still
> come into conflict.

I never claimed otherwise.

I'm looking for a change which is good enough to support auto-cleanup.

Asking me to go build Tcl 9 to get there is not helpful.

-jcw

_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Handles vs. internal rep's

Donald G Porter (dgp@...)

> 1) TIP 126 adds a field to every Tcl_Obj ...

> On 1), I'd guess that it's probably the reason why no consensus has  
> been reached on this since TIP 126 was introduced in 2003.

Indirectly.  TIP 126 explicitly targets Tcl 9.0.  Three years later
still no one is publicly working on that.  Perhaps you should start?

To me, both your sketches and TIP 126 work on the same problem, and
both have a spirit of trying to tinker around the margins and achieve
not much more than having Tcl be somewhat less likely to cause 
trouble.  Each still leaves lots of cases where the EIAS nature of
Tcl and the "my value is *not* a string" behavior you require still
come into conflict.

I'd be happier analyzing your needs and those of some other extensions
you mentioned and determine what new rule needs to be adopted for Tcl 9.
Drop "Everything is a string" and embrace "everything is a string
or a ????".  Determine how many different ??? are needed.  Try to reduce
it to a minimal set (one would be best), and start building up Tcl 9
from the implications.

I don't expect to be much help, so feel free to take my opinion for
what it's worth.

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



_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Handles vs. internal rep's

Donal K. Fellows (donal.k.fellows@...)

Jean-Claude Wippler wrote:
> If we could evolve things like Tk's "bind" to not treat their scripts  
> as strings but as lists, say (like trace does, tacking on args), then  
> bind would not lose int-reps as much and the need for the interp- 
> alias workarounds would be reduced even further.

Improving [bind] in that sort of way has been on my todo list ever since
the Tcl conference in Ann Arbor. (It's Tk FRQ 783798).

Donal.

_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Handles vs. internal rep's

Jean-Claude Wippler (jcw@...)

Donald G Porter wrote:

> I see.  A scheme to embed one of the possible intreps within the
> string rep storage area.  How does this compare with TIP 126 ?

It does address the same issue, but it differs:

1) TIP 126 adds a field to every Tcl_Obj (which is a major trade-off,  
as Donal notes).  It appears to be a bit like adding an "encoding"  
type to each Tcl_Obj, though for a specific purpose of tracking  
references.

2) TIP 126 leads to a mechanism which survives concatenation, (some)  
substitution, and (some) substring extraction, whereas what I propose  
does not.

On 1), I'd guess that it's probably the reason why no consensus has  
been reached on this since TIP 126 was introduced in 2003.

As for 2), that works in some (useful) cases, but not all.  You  
cannot save the thing, or otherwise transfer it in the EIAS way.   
Neither can the hack I described, but then I don't even try to claim  
otherwise.  I see these objects as opaque, except that Tcl has no  
mechanism to enforce that (as C has with pointers to private structs).

I've been working with Tcl_Obj's which should not lose their int-reps  
for some time now (in the Vlerq/Ratcl project), and so have a few  
other people.  It really does work out well - you get a handle-like  
string rep which displays conveniently, and you get normal command  
errors when the object they are given no longer have their int-rep.   
So with the work I've been doing, losing an int-rep is easily tracked  
(and worked around by switching to interp-aliased commands, which  
have to then be manually managed).

In practice, Tcl_Obj's which may not lose their int-rep tend to work  
out ok.  Losing an int-rep is a bit like losing whitespace when  
shimmering to a list and back - when it matters, you find out, and  
you learn to avoid certain idioms.  And just like saving a handle  
such as a channel name makes no sense, neither does saving one of  
these objects.	The string rep is handle, a volatile tag, no more.

If we could evolve things like Tk's "bind" to not treat their scripts  
as strings but as lists, say (like trace does, tacking on args), then  
bind would not lose int-reps as much and the need for the interp- 
alias workarounds would be reduced even further.

-jcw

_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Handles vs. internal rep's

Donald G Porter (dgp@...)

> > how does an additional callback when stringrep is invalidated help	
> > to give
> > automatic cleanup of handle-type Tcl_Obj value?
> 
> You could either unset some corresponding array element, or you could  
> release the object if it actually is included as ptr (that's why I  
> used 9 bytes as example, not 5).

I see.	A scheme to embed one of the possible intreps within the
string rep storage area.  How does this compare with TIP 126 ?

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



_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Handles vs. internal rep's

Jean-Claude Wippler (jcw@...)

Donald G Porter wrote:

>> It needs *one* change to Tcl: if the bytes ptr is *odd* when
>> releasing it, then do something special before actually doing the
>> ckfree.
>
> Can you clarify.... does this change happen only in Tcl, or
> in every extension that implements a Tcl_ObjType ?

Only in Tcl, in Tcl_InvalidateStringRep.  Assuming no-one ever	
releases the string rep any other way.

>> So bytes is odd.  The byte just before the string says where the
>> allocated memory really starts.  And the first item in that memory is
>> the function to call before ckfree-ing the entire memory area.
>
> The whole point is to add another callback function when stringrep
> is freed?  This hackery is preferred over just extending Tcl_ObjType?
> Why?

As a callback, it's special because typePtr may have changed, i.e.  
it's tied to the actual string, not the Tcl_Obj.  In a more general  
sense, if pointers and other data gets stored there as well, it's in  
fact object state - but again, tied to the string rep itself.  This  
state is maintained even if the object has been turned into a list  
for example - it's cleaned up when the string rep is actually deleted  
(presumably that's when the value actually changes, i.e. lappend  
list, or incr int).

What this introduces (in a hacked way), is a distinction between  
alternate representation (which are considered equivalent), and a  
change in value.

Not sure how Tcl_DuplicateObj fits into this.  Hm.

-jcw

_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Handles vs. internal rep's

Jean-Claude Wippler (jcw@...)

Donald G Porter wrote:

> how does an additional callback when stringrep is invalidated help  
> to give
> automatic cleanup of handle-type Tcl_Obj value?

You could either unset some corresponding array element, or you could  
release the object if it actually is included as ptr (that's why I  
used 9 bytes as example, not 5).

-jcw

_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Handles vs. internal rep's

Donald G Porter (dgp@...)

> The whole point is to add another callback function when stringrep
> is freed?  

And for the sake of us dumb guys who don't see the obvious... how does
an additional callback when stringrep is invalidated help to give
automatic cleanup of handle-type Tcl_Obj value?

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



_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core