tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] TIP #354: Minor Production-Driven TclOO Revisions

[Donal K. F. <dk...@us...>]

 TIP #354: MINOR PRODUCTION-DRIVEN TCLOO REVISIONS 
===================================================
 Version:      $Revision: 1.2 $
 Author:       Donal K. Fellows <dkf_at_users.sf.net>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.6
 Vote:         Pending
 Created:      Wednesday, 26 August 2009
 URL:          http://purl.org/tcl/tip/354.html
 WebEdit:      http://purl.org/tcl/tip/edit/354
 Post-History: 

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

 ABSTRACT 
==========

 This TIP describes a few small changes required for solving issues that 
 have been found when using TclOO in production. 

 DESCRIPTION 
=============

 TclOO (see [TIP #257]) has now had a substantial amount of use for 
 relatively complex functionality (as well as production deployment) and 
 it has turned out that there were a few small changes required. 

    1. The scope of resolution for the target of a *forward*ed method is 
       updated so that it is with respect to the object's namespace. 
       This means that a class may create methods that forward to a 
       command given by each instance, which makes creating megawidgets 
       by wrapping real Tk widgets much easier, since the forwards do 
       not have to be created at the instance level. 

    2. A subcommand was added to *info object* to allow the discovery of 
       the namespace of an object by code outside that object. This 
       makes it far easier for code that needs to "break the 
       abstraction" to do so, which turns out to be necessary for things 
       like serialization. This subcommand, *namespace*, takes an object 
       name as its only argument and returns the name of the object's 
       namespace. 

       To expand on the requirements for serialization, the 
       serialization code needs to call a method on each object to 
       create the serialization for that object. However, the method 
       should not be part of the public API for the object as it cannot 
       perform a complete serialization correctly, since the 
       serialization depends on the rest of the object graph. (It also 
       requires a number of global overheads that are best applied once, 
       not repeatedly.) 

       Note that I plan to release the serialization code itself 
       (originally developed as part of a solution for a Rosetta Code 
       task) as a package via tcllib. This TIP does not propose its 
       inclusion with Tcl. 

    3. A new C API function has been added to allow code at that level 
       to /efficiently/ discover the name of an object that it already 
       has a handle to. This new function, *Tcl_GetObjectName*, returns 
       a shared Tcl_Obj reference to the name that needs no special 
       reference count management. 

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

 This document has been placed in the public domain. 

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

 TIP AutoGenerator - written by Donal K. Fellows 

Re: [TCLCORE] multithreaded Tcl IO / select vs. epoll and IOCP

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

Hi Roman

On Wed, Aug 26, 2009 at 9:04 AM, Roman Puls<pu...@x-...> wrote:
> Dear Core-Developers,
>
> we're using Tcl (8.6b1.1) quite heavy for our server applications,
> appreciating the simplicity of the event loop, using stacked channels
> (ssl) and the ability to run it both on linux/windows. We do most parts in C
> (using the Tcl-API heavily) and glue the components on the script level.

A selfish side question, since you're mentioning it: are you using
fileevents on ssl-capped channels ? If yes, and you have no bugs to
report in this area, then your expertise would be very helpful to
proceed with TLS's nasty stalls and empty reads (see Tcl bug 1945538).

> These days, I asked myself how to improve the performance (as we're using
> ssl quite heavy) and tried to make a quick prototype to test for
> multithreading to take advantage of the Multi-CPU core. The server accepts
> incoming connections, and echos back all data it receives to the socket.
>  [...]
> Having 4 threads, we do not take advantage of all CPUs (load <= 100%). Is
> that a limitation of the Tcl_DoOneEvent / select() call, or do you see any
> problems with the code above?

There is indeed a bottleneck in the current unix notifier: it is
centralized. The reason is the poor marriage between select() and
pthreads, which makes it hard to efficiently awaken another thread's
select().
Basically things work this way:

  - a central Notifier thread does a jumbo select() for everybody else.
  - the Tcl-interp-coupled threads themselves wait on a condition variable
  - when an fd awakens the central select, the notifier pings the
proper cond var(s).
  - interthread communication (thread::send) also uses the cond vars.

This is a long-term dream of ours (well, at least mine) to replace
this with a more distributed architecture. The reason is not only
performance, but also better symmetry with the unthreaded case,
avoiding the presence of that extra hidden thread for all
single-threaded uses of a threaded Tcl. In the end this would allow to
make the threaded core the default in unix with confidence.

(FWIW, one possibility to do this would be to use pthread_kill as an
interthread awakening mechanism, each thread having his own select()
just as in the unthreaded core)

Now I am not 100% sure this is _your_ bottleneck. But it could well be ;-)

To investigate, you could first break down the CPU consumption between
user and kernel (I suspect high kernel, because of the futex
syscalls); then get a per-thread breakdown of the consumption; then
attach strace to the hungriest one.

> We're unable to establish more than 1024 socket connections (ulimit is set
> to 8192 file handles). Having 1024 sockets, we can still open regular files.
> Is it possible to bypass that socket limit? Can we somehow specify the
> backlog for the listening socket?

Two things here:

 (1) the FD_SETSIZE limit in this case is lower than the max number of
open fds. This is directly linked with the centralized select() issue,
hinting at the fact that the OS doesn't expect a 2048-fd select (and
yes, epoll() is one modern answer).
 (2) the backlog of the listening socket is an entirely separate
issue. If you're hitting it, you must be seeing ECONNREFUSED in the
clients. Is it the case ? If yes, the limit can be upped in
/etc/sysctl.conf through net.ipv4.tcp_max_syn_backlog.

> As for one of the next major tcl-releases (yes, I know that we're not having
> the 'typical' tcl application and that linux is just one *nix), would it
> make sense to implement epoll for linux
> (e.g. http://www.monkey.org/~provos/libevent/ ) and let's say IOCP
> (http://sourceforge.net/projects/iocpsock) for the windows port?

I don't have the full picture in mind, so just one remark here: AFAIK
epoll would just allow bigger sets of waited-for fds, but not ease the
pthread interaction. So it is orthogonal to the decentralization
effort.

> Have you got any other suggestion on how to improve performance / take
> advantage of multi-processor architectures with the existing core
> implementation?

Random questions:

1a) Since you're doing all this socket event dispatching in C, are you
sure Tcl is at the proper place ?
1b) IOW, do you observe a performance boost by doing this instead of
script level and unmodified tclsh ?
2a) In the target application (not the minimized case), what is the
bottleneck: connection creation/destruction, or mid-life I/O and
computations ?
2b) IOW, what are the figures of the number of new connections per
second and average connection lifetime ?
3) What do the worker threads need to share ? Could they be processes instead ?

Based on answers to these, it might or might not be worth asking this one:

4) have you considered letting an Apache or equivalent handle the
connections, and use FastCGI or other as a gateway to your worker
process ?

> Do we have sort of round-robin in the core, so that every socket gets the
> same amount of "activity"?

Yes, unless you file a bug report showing the contrary ;-)

-Alex

[TCLCORE] multithreaded Tcl IO / select vs. epoll and IOCP

[Roman P. <pu...@x-...>]

[TCLCORE] TIP 353: Accepted

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

TIP 353 Accepted by 8-0-0 vote.
YES: Porter, Sofer, Nijtmans, Fellows, English, Kupries, Kenny, Steffen

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

Re: [TCLCORE] CFV: TIP 353

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

On Wed, Aug 5, 2009 at 19:09, Donald G Porter<don...@ni...> wrote:
> Please send votes to TCLCORE and/or back to me before the polls close at
> [clock format 1250092800].
>
> TIP #353: NR-ENABLED EXPRESSIONS FOR EXTENSIONS

TIP #353: YES

Cheers,

Daniel

Re: [TCLCORE] CFV: TIP 353

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

Donald G Porter wrote:
> As promised, here's the call for votes for TIP 353.
> 
> Please send votes to TCLCORE and/or back to me before the polls close at
> [clock format 1250092800].
> 
> TIP #353: NR-ENABLED EXPRESSIONS FOR EXTENSIONS
> 
> My vote:
> 
> 353:    YES
> 

TIP #353: YES

Re: [TCLCORE] CFV: TIP 353

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

Donald G Porter wrote:
>
> TIP #353: NR-ENABLED EXPRESSIONS FOR EXTENSIONS
>

TIP#353: YES


--Joe English

  jen...@fl...

Re: [TCLCORE] CFV: TIP 353

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

Donald G Porter wrote:
> As promised, here's the call for votes for TIP 353.
> 
> Please send votes to TCLCORE and/or back to me before the polls close at
> [clock format 1250092800].
> 
> TIP #353: NR-ENABLED EXPRESSIONS FOR EXTENSIONS

Vote #353:	YES.

Andreas.

Re: [TCLCORE] CFV: TIP 353

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

Donald G Porter wrote:
> I did not consider that, since I was continuing to pattern after
> Tcl_ExprObj().  Is anyone else interested in considering that different
> approach to the interface?  It sounds nicer to me, but will need a
> quick check that it would fit into all the places it needs to fit.

I was just thinking in terms of how Tcl_NREvalObj (or whatever it is
called) works. After all, it's not a problem to ask the caller to save
the interpreter result if they want. It also means one less slot that
has to be passed in the context, leaving it free for client code. (I
suppose I care a bit because I'm going to end up using it to fix the
likes of [for] and [while] to work with [yield] when interpreted...)

Donal.

Re: [TCLCORE] CFV: TIP 353

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

Donal K. Fellows wrote:

> Make sure that when you document it, ...

The documentation is already in the implementation patch.

> ...you also document (and provide an
> example) how to receive the results. That's a little funky, as I'd have
> expected to just take it out of the interpreter result.

I did not consider that, since I was continuing to pattern after
Tcl_ExprObj().  Is anyone else interested in considering that different
approach to the interface?  It sounds nicer to me, but will need a
quick check that it would fit into all the places it needs to fit.

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

Re: [TCLCORE] CFV: TIP 353

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

Donald G Porter wrote:
> As promised, here's the call for votes for TIP 353.
> 
> Please send votes to TCLCORE and/or back to me before the polls close at
> [clock format 1250092800].
> 
> TIP #353: NR-ENABLED EXPRESSIONS FOR EXTENSIONS

TIP#353: YES

Make sure that when you document it, you also document (and provide an
example) how to receive the results. That's a little funky, as I'd have
expected to just take it out of the interpreter result.

Donal.

Re: [TCLCORE] CFV: TIP 353

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

Donald G Porter wrote:
> As promised, here's the call for votes for TIP 353.
>
> Please send votes to TCLCORE and/or back to me before the polls close at
> [clock format 1250092800].
>
> TIP #353: NR-ENABLED EXPRESSIONS FOR EXTENSIONS
>
My vote:

353:    YES

Regards,
       Jan Nijtmans

Re: [TCLCORE] CFV: TIP 353

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

Donald G Porter wrote:
> As promised, here's the call for votes for TIP 353.
> 
> Please send votes to TCLCORE and/or back to me before the polls close at
> [clock format 1250092800].
> 
> TIP #353: NR-ENABLED EXPRESSIONS FOR EXTENSIONS
> 
My vote:

353:    YES


Miguel

[TCLCORE] CFV: TIP 353

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

As promised, here's the call for votes for TIP 353.

Please send votes to TCLCORE and/or back to me before the polls close at
[clock format 1250092800].

TIP #353: NR-ENABLED EXPRESSIONS FOR EXTENSIONS

My vote:

353:    YES

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

Re: [TCLCORE] www.tcl.tk down tonight for 12 hours

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

On 31/07/2009 5:41 PM, Jeff Hobbs wrote:
> Due to power maintenance in our building, www.tcl.tk will be down from 
> 9pm PDT to ~9am PDT Saturday (assuming it comes up cleanly, otherwise it 
> may be a while until I can revive it).  Sorry for the short notice.

To clarify, that is 9pm Friday, July 31st.

[TCLCORE] www.tcl.tk down tonight for 12 hours

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

Due to power maintenance in our building, www.tcl.tk will be down from 
9pm PDT to ~9am PDT Saturday (assuming it comes up cleanly, otherwise it 
may be a while until I can revive it).  Sorry for the short notice.

Jeff

[TCLCORE] LAST CALL: Re: TIP #353: NR-enabled Expressions for Extensions

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

Don Porter wrote:
>  TIP #353: NR-ENABLED EXPRESSIONS FOR EXTENSIONS 

Since this proposal is part of some bug fixes, and is needed to fill
a hole in the new 8.6 NRE interface, I want to approve it quickly.
Please review and comment by August 5, when I plan to call the vote.

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

[TCLCORE] TIP #353: NR-enabled Expressions for Extensions

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

 TIP #353: NR-ENABLED EXPRESSIONS FOR EXTENSIONS 
=================================================
 Version:      $Revision: 1.3 $
 Author:       Don Porter <dgp_at_users.sf.net>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.6
 Vote:         Pending
 Created:      Wednesday, 29 July 2009
 URL:          http://purl.org/tcl/tip/353.html
 WebEdit:      http://purl.org/tcl/tip/edit/353
 Post-History: 

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

 ABSTRACT 
==========

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

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

 In a few contexts, expressions that contain *yield* raise the error 
 "/cannot yield: C stack busy/"; see Tcl Bugs 2823282 
 [<URL:https://sourceforge.net/support/tracker.php?aid=2823282>] and 
 2823276 
 [<URL:https://sourceforge.net/support/tracker.php?aid=2823276>]. This 
 is because a few little-visited corners of Tcl's implementation call 
 the routine *Tcl_ExprObj* and that routine is not NR-enabled. 

 For extensions wishing to evaluate Tcl expressions, *Tcl_ExprObj* is 
 not little-visited. It is the public, supported, recommended tool for 
 the job. Just as [TIP #322] provided a routine *Tcl_NREvalObj/ as an 
 NR-enabled replacement for *Tcl_EvalObj*, extensions wishing to 
 NR-enable their commands need an analogous replacement for 
 *Tcl_ExprObj*. 

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

 Tcl has a long history of providing extensions access to the same 
 capabilities available to the built-in command set so that extension 
 commands are on an equal footing, not in a second class status. Keeping 
 with that, we want extensions to be able to create NR-enabled commands, 
 so we need to provide an interface for extensions to evaluate 
 expressions in an NR-enabled manner. This TIP can be seen as filling up 
 a hole in [TIP #322]. 

 SCOPE LIMITATIONS 
===================

 The Tcl public C interface provides a whole family of variants of 
 *Tcl_ExprObj*: *Tcl_ExprLongObj*, *Tcl_ExprDoubleObj*, 
 *Tcl_ExprBooleanObj*, *Tcl_ExprLong*, *Tcl_ExprDouble*, 
 *Tcl_ExprBoolean*, *Tcl_ExprString*. NR-enabled counterparts to these 
 routines are /not/ proposed. Extensions rewriting their command 
 procedures to use the proposed *Tcl_NRExprObj* for sake of NR-enabling 
 can at the same time be expected to convert from these convenience 
 wrappers to more direct use of a single NR-enabled primitive. 

 PROPOSAL 
==========

 Add the following routine to Tcl's public interface: 

       int *Tcl_NRExprObj*(Tcl_Interp */interp/, Tcl_Obj */objPtr/, 
       Tcl_Obj */resultPtr/) 

 This routine places on the NR stack a request that the Tcl 
 non-recursive trampoline evaluate the /objPtr/ value as a Tcl 
 expression in interpreter /interp/. 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. 

 The /resultPtr/ argument must be an unshared Tcl value. When expression 
 evaluation succeeds, the result of the expression is written to 
 /resultPtr/ in the same way that *Tcl_SetStringObj* would write a 
 string value to an unshared Tcl value. If expression evaluation 
 produces any return code other than *TCL_OK*, the value of /resultPtr/ 
 is left untouched. 

 Callers of *Tcl_NRExprObj* will also need to call *Tcl_NRAddCallback* 
 to request a *Tcl_NRPostProc* callback routine be placed on the NR 
 stack which can take care of managing /resultPtr/ as appropriate 
 depending on the /result/ value. 

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

 The patch attached to Tcl Bug 2823282 
 [<URL:https://sourceforge.net/support/tracker.php?aid=2823282>] 
 implements this proposal. 

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

 There should be no compatibility issues, since at the interface level 
 this is just the addition of a new routine. Revisions to the internal 
 implementations of existing routines should be harmless. 

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

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

   int ObjCmd(ClientData cd, Tcl_Interp *interp, int objc, Tcl_Obj *const objv[])
   {   int code;
       Tcl_Obj *resultPtr;
       /* determine expression, objPtr */
       code = Tcl_ExprObj(interp, objPtr, &resultPtr);
       if (code != TCL_OK) {return code}
       /* resultPtr holds expression result; continue */
   }

 To use *Tcl_NRExprObj* 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[])
   {   Tcl_Obj *resultPtr = Tcl_NewObj();
       /* determine expression, objPtr */
       Tcl_NRAddCallback(interp, Callback, resultPtr, /*...*/);
       return Tcl_NRExprObj(interp, objPtr, resultPtr);
   }
   
   int Callback(ClientData data[], Tcl_Interp *interp, int code)
   {   Tcl_Obj *resultPtr = data[0];
       if (code != TCL_OK) {Tcl_DecrRefCount(resultPtr); return code;}
       /* resultPtr holds expression result; continue */
   }

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

 This document has been placed in the public domain. 

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

 TIP AutoGenerator - written by Donal K. Fellows 

Re: [TCLCORE] [chan rename] RFE

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

On 7/24/09, Colin McCormack <co...@ch...> wrote:
> Alexandre asked for some comments on the SF 'artifact' comment stream,
>  but SF then decided to close the 'artifact' for further comments, so I'm
>  moving it here.

Strange, SF seems OK. It has been unresponsive for several minutes
though, perhaps you sampled at the wrong time ;-}

Now I _really_ like the central repository of ideas SF provides. The
tclcore archive is such a PITA to browse and search... can we stay in
the artifact ?

-Alex

[TCLCORE] [chan rename] RFE

[Colin M. <co...@ch...>]

Alexandre asked for some comments on the SF 'artifact' comment stream, 
but SF then decided to close the 'artifact' for further comments, so I'm 
moving it here.

My proposal:

I would like a [chan rename $oldname $newname] command, which renamed a 
channel.

This would be useful to avoid bugs (admittedly, caused by other bugs) 
where an open channel name is stored in one data structure, perhaps in a 
coro, thread or interp, and the channel is closed before the channel 
name can be removed from those data structures. The current effect of 
such uncoordinated storage is that either a delay in closing the channel 
must be suffered while all copies of the name are updated, or that a 
stale chan name is held somewhere, and causes a new chan (usually a 
socket) with the same name as the old (and now closed) chan to be 
manipulated in error.

This problem arises, essentially, because tcl reuses chan names 
frequently, and chooses them from a very compact set.

By enabling arbitrarily named chans, at construction time, chan name 
conflict could be completely avoided by an application.

Alexandre's response:

Hmmm, there are two separate issues here: (1) removing the carpet under 
a coro/thread feet and (2) too fast reuse.
I fail to see how this would solve (1), but for (2) it is clear. Can you 
clarify on (1) ?

Regarding (2), the "compact set" arises from Tcl's direct use of OS 
handles/fd, and on unix fds are a compact set. On Windows AFAIK handles 
are not reused (correct m if I'm wrong). So, an alternative way of 
solving this issue, without any intervention from the script writer, 
would be to insert an indirection in Tcl, with an intentionally compact 
set managed by Tcl, but extended with generation counts, so that no 
reuse occurs:

typedef struct {
HANDLE_OR_INT fd;
int gencount;
} UniqueHandle;

UniqueHandle *compactArrayOfFds;

The idea, then, is to have automatic channel names of the form

sock3g1

which can be looked up from string in two steps:

3 is the index in compactArrayOfFds
1 is the gencount for verification

This way, even if slot 3 of the array is reused, it will have a gencount 
of at least 2, hence any stale reference to sock3g1 will generate an 
error instead of wreaking havoc by unwanted IO on another channel.

Note that this works well with the Channel intrep too, assuming we add 
the gencount to the structure. Then the gencount verification is just an 
extra integer comparison.

Reactions ?


My Response:

I've thought of a new good reason to do this:  by renaming, one could 
introduce some application-specific encoding into the names, for example 
"connected_$ipaddress_$count"  and get connection counting for free.  I 
also thought of a new distinct area of a program which may contain chan 
names: the event system (fileevents and such)

Now, to clarify:  if you have a coro which is in the process of handling 
fileevents on a socket (socket10, let's say) and you decide you want to 
not handle events on that socket for a few seconds, so you schedule an 
[after] event to trigger to enable you to re-establish the [fileevent 
$sock] ... you must store the socket name (socket10) in the variable 
sock, which may be a coro variable, hence inaccessible to other coros.  
If a different processing stream, or coro, decides it wants to close 
socket10, it can't safely do that until and unless it has notified the 
first coro of its intention, so that it can (a) forget about socket10 - 
cancel any [after] events it may have scheduled.

If this sounds like a contrived example, it's not.  I have almost 
exactly this problem in adding input throttling to Wub right now, and 
anyone writing a producer/consumer pair with buffering where the two 
parts make use of modern Tcl facilities such as coros or [apply] or even 
[interp] will have similar problems.  The amount of data which needs to 
be shared between the distinct processing elements is too great, and is 
imposed entirely by the rapid cycling of chan names.

It is true that one could fix the cycling, but the idea of encoding 
names with significant information also appeals to me.

Colin.

Re: [TCLCORE] Tk: text widget "C" code question

[Vince D. <vin...@gm...>]

It's been a couple of years, but I've been responsible for a few of  
the changes in the text widget in 8.4/8.5. Internally the text widget  
is calculating exactly the kind of geometries you are - if you look at  
the C code which implements the timer driven calculation of geometries  
for correct updating of the scrollbar you'll see much of this. I  
suspect your best bet is to try to re-use/hook into that kind of  
calculation.

Caveat: it's been a few years, this is off the top of my head, and I'm  
off on holiday so can't advise further.

Vince

Sent from my iPhone

On 23 Jul 2009, at 18:08, Krzysztof Blicharski <bli...@gm...>  
wrote:

> Hi!
>
> My name is Krzysztof Blicharski and I'm one of participants
> the Google Summer of Code students. My project is
> Printing support for Tcl/Tk". I have question for someone
> who maintains Tk's text widget code.
>
> I need to know coordinates/bounding box of text/images/windows
> which aren't currently visible in the text widget (more precisely
> the coordinates/bounding box which the given element will has
> when the text widget would be sufficiently large to display all
> data in it) and where the text lines wraps.
>
> Is it possible to add functionality to the Tk code which will give me
> this information? If yes, how much effort (approximately) will it  
> take.
> Can you estimate how many changes in existing code (only in text  
> widget
> code or not only) it will require?.
>
> I know that my questions are very general, but I must choose between
> trying to compute this information using available introspection
> capabilities of text widget or adding to Tk's text widget code to give
> me this information.
>
> Thanks in advance!
>
> Best regards,
> Krzysztof Blicharsk
>
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] Tk: text widget "C" code question

[Krzysztof B. <bli...@gm...>]

Hi!

My name is Krzysztof Blicharski and I'm one of participants
the Google Summer of Code students. My project is
Printing support for Tcl/Tk". I have question for someone
who maintains Tk's text widget code.

I need to know coordinates/bounding box of text/images/windows
which aren't currently visible in the text widget (more precisely
the coordinates/bounding box which the given element will has
when the text widget would be sufficiently large to display all
data in it) and where the text lines wraps.

Is it possible to add functionality to the Tk code which will give me
this information? If yes, how much effort (approximately) will it take.
Can you estimate how many changes in existing code (only in text widget
code or not only) it will require?.

I know that my questions are very general, but I must choose between
trying to compute this information using available introspection
capabilities of text widget or adding to Tk's text widget code to give
me this information.

Thanks in advance!

Best regards,
Krzysztof Blicharsk

Re: [TCLCORE] CONST86 and extensions

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

Jan Nijtmans wrote:
> In most cases, the result of Tcl_GetObjType() will be stored in a
> variable. Making this variable "const *" will be sufficient. So (tclXkeylist.c):
>   static Tcl_ObjType *listType;
>   static Tcl_ObjType *stringType;
> should become:
>   static const Tcl_ObjType *listType;
>   static const Tcl_ObjType *stringType;

These are good examples why Tcl_GetObjType() is fragile and best
avoided.

The internal rep of the Tcl_ObjType registered as "list" by Tcl
changed between releases 8.4 and 8.5.

The internal rep of the Tcl_ObjType registered as "string" by Tcl
changed between releases 8.5 and 8.6.

So any code that's making decisions based on whether a value has
a Tcl_ObjType matching one returned by Tcl_GetObjType() is only
going to work across releases if it makes only assumptions that
are not disrupted by these changes in the internal rep.

Even when a particular case works, it's much more work to audit
than code which simply never made the Tcl_GetObjType() calls in
the first place.

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

Re: [TCLCORE] TIP #351: Add Striding Support to lsearch

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

Donald Arseneau wrote:
> Fredderic <mag...@gm...> writes:
>> that matches the entire item group, as in the present case of searching
>> sub-lists with a regular string match.
> 
> Good question as to whether that is the "present case"!  I would edit the TIP
> myself to specify otherwise, but maybe Donal's intention was to search
> entire sublists!  I don't think so because lsort uses the first (zeroth) 
> element of each group or the one given by -index; never the whole group.

It does? Then we should do the same here. I'm *strongly* in favour of
[lsort] and [lsearch] having as closely matching -stride semantics as
possible. (If they're different, people will hate us and rightly so...)

Donal.

Re: [TCLCORE] CONST86 and extensions

[Jan N. <jan...@gm...>]

2009/7/16 Donald G Porter <don...@ni...>:
> That said, these all appear to be calls to Tcl_GetObjType() which we
> have increasing agreement is a dicey thing at best for extensions to
> be calling.  Especially bad that there appears to be no safety checks
> for NULL returns.
>
> If Thread really needs access to the internals of the Tcl_ObjTypes
> defined by Tcl itself, should Thread really get on a path to just
> become part of Tcl?

Well, I looked at the code, and the Thread extension is not one of
the 'bad guys' which violate the API assumtions. Just putting
a "const" here and there can eliminate all warnings, without
introducing unsafe type casts or using the CONST86 macro.

I think, calling Tcl_GetObjType() is not bad, it is bad when
an extension writes to the memory where the returned pointer
is pointed to. Thead doesn't do that, it uses Tcl_GetObjType()
what it is meant for: a fast shortcut to check whether some
object is of a specific type or not. That's fully legal.

Regards,
        Jan Nijtmans