tcl-core — Tcl Core Team discussions about Tcl development

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

Re: [TCLCORE] CONST86 and extensions

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

2009/7/16 Alexandre Ferrieux <ale...@gm...>:
> Hi Jan,
>
> I'm really ignorant about const-nightmares. I would just like a tiny
> piece advice on how to handle CONST86 qualifiers that are present in
> the generic stubs stable and thus could be accessed by extensions.

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;
(and the same for booleanObjTypePtr and its friends)

If (list|string)Type is only accessed for reading (and it looks like it
is), this will compile and run against any Tcl version.

If you use the value in another function, e.g. Sv_RegisterObjType,
which doesn't expect a "const", then that parameter should
be changed to a const as well. So
  Sv_RegisterObjType(Tcl_ObjType*, Tcl_DupInternalRepProc*);
should become.
  Sv_RegisterObjType(const Tcl_ObjType*, Tcl_DupInternalRepProc*);

Most cases can be made compatible with any Tcl version this way,
without using the CONST86 macro. And you will gain type safety:
the compiler can check now that you never illegally write somewhere
you are not supposed to write to.

I'm willing to have a look at the Threads extension for more examples,
but those two examples I spotted by simply looking at the code.

Regards,
         Jan Nijtmans

Re: [TCLCORE] CONST86 and extensions

[Vasiljevic Z. <zv...@ar...>]

On 16.07.2009, at 01:19, Donald G Porter wrote:

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


In my experience...

A simplified (i.e. a partial) version could be incorporated.
Just the ability to create singleton threads and exchange
messages. Adding all that is in the threading extension now
is kind of difficult to maintain and it is not really needed
for majority of users. As of that, peraphs the better is to
combine the singleton thread and thread pool and integrate
just the thread pool. The pool with just one worker is effectively
equal to the singleton thread. And, threadpool is much more
versatile and flexible, of course.

Cheers,
Zoran

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

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

On 15 Jul 2009 18:19:07 -0700, 
Donald Arseneau <as...@tr...> wrote:

> Fredderic <mag...@gm...> writes:
>> I don't understand that...  Given the following line:
>> 
>>     lsearch -all -stride 3 -start 1 \
>>         {junk abc def ghi 123 456 789} {*[e8]*}
>> 
>> I want lsearch to return {1 4}, you seem to want it to return {2 6}.
> 
> No!  I expect it to return {2}.  lsearch without -stride returns {2 6}
> but when given "-stride 3 -start 1" lsearch should only ever look at
> items 1,4,7,... and should not match any other elements.

Yes, if you specify "-index 0", then that is exactly what it would do.
And if you specify "-index 1", it would be checking items 2, 5, 8,
etc.  My point, is that if you don't specify an index, then it should do
exactly the same as it does any other time it's faced with a sub-list
and no search index; it should match the entire sub-list (stride group
in this case) as a string.  To do anything else, other than throw an
error because there's no -index term provided (which would be an
unfortunate omission of functionality), is an inconsistency with other
existing behaviours of the command.


>> Given {1 4} as a return value, I can directly access any element
>> within the indicated group(s).  Without the -all, the result will
>> be 1, and regardless of which word in the group matched (eg. using
>> the pattern *[b8]* instead),
> 
> What you are looking for is not a stride of 3, but some "funky modulo
> math" (actually, divide and multiply) appled to a regular [lsearch] 
> result. I don't see how that merits any change to the lsearch command 
> itself.  And how much use would such whole-group searches be? When
> you have a flat key-value list you usually want to search the keys or
> the values, not both indiscriminantly.

No.  I am not looking for some "funky modulo math".  [lsearch] I
suspect, will be stepping over the list in units of -stride already.
It doesn't have to do any funky modulo math to figure out the result I
want, it already has it as part of its basic functionality.  But if it
returns the result you prescribe, than the script may have to do that
funky modulo math to get back what [lsearch] already had.  Let me
repeat that, because it's important; [lsearch] already HAS the result
of the "funky modulo math" as the basis of its most obvious
implementation of this feature with the capabilities suggested here.

As for the second part, strangely, I have several instances of matching
against entire sub-lists as a string.  One prime example, is
three-element sub-list, all three elements are quite distinctive, and
so any given search pattern will only match one of the three elements.
So rather than fiddling with -index, a simple search against the entire
sub-list does quite well.  That would work just the same if it were a
flat list with "-stride 3" and no -index specifier.

Is it a common situation?  Probably not.  But it IS part of TCL's
legacy.  It's been the way in the other well-known context, and it
should be the way here, too.  In TCL, EIAS, after all.  Isn't that
what's always said?  What sense, then, is blocking a function because we
don't want to consider something as a string?

In the interim, though, I do recognise that the naive approach is going
to incur a significant performance penalty, and clutter the
implementation to a slight degree.  I would hope, though, that this
situation is handled by a temporary error on missing -index specifier,
and that the TIP states this is an omission to be remedied at a point
not too many releases thereafter.


> We really need a more detailed TIP to eliminate these discussions at
> cross-purposes.

I don't see any cross-purpose going on at all.  You don't want to
consider the grouping as a whole, as a potential search target, where I
believe it's just common sense to do so, even if it comes with a
performance warning on large lists.  There may well be a change at some
point (such as the move to ropes) that removes that performance issue,
and there may well come a hitherto unrealised bright idea at some point
that makes to trivial and just as quick as the rest. Treating sub-lists
as a string is part of TCL.  The result of [lrange] is used as a string
quite regularly around the place.  Deal with it.

What you're proposing, is like saying that [lsort] should only sort
every -stride'th element, and leave the rest where they were.  ie.

	lsort -stride 3 -index 0 {9 8 7 6 5 4 3 2 1 0}
	-> {0 8 7 3 5 4 6 2 1 9}

Now, that looks a little strange to me.  Don't you think?


>> Given your response of {2 6}, 
> 
> not 

With the assumption that the feature goes ahead despite your
reservations, that IS the result you were suggesting, as far as I can
determine.  What I wasn't considering at the time, because it seemed a
little odd given my understanding of TCL's very essense, was that you
were proposing omitting that obvious feature all together.


>> in order to do any of that I need to do a bit of funky modulo math
>> to adjust the index back to the start of the group, and then add the
>> offset to the item and/or group that I want.
> 
> No modulo math.  You are talking about a searching all elements
> in the group, and I don't think that is what the TIP proposes.
> We need a clearer TIP.  

I'll repeat my stance yet again: [lsearch] already treats sub-lists as
strings when searching.  It doesn't recognise the item is a list, and
say, "oh, I'm only going to match the first word of this list!".  Which
is what you're proposing; we have a group of items, so we'll only match
against the first item in the group and ignoring the rest.

I *DO* however recognise that this will require special case handling,
at least until someone comes up with a better idea.  Implementation
wise, the naive way shouldn't complicate things very much, but it will
be slow.  It would involve looping over the -stride items from the
current position, composing a list, converting that list into a string,
and taking that as the value to match against.  This would be
implemented as an alternative to the line that already obtains the list
items string to match against.

Doing the task fast is also possible, but does involve some extra
complexity and possibly rearrangement of the search implementation.  I'm
hoping someone finds a better middle-ground, but regardless, the slow
way is evil performance wise, but I think it's trivial enough that it
should be available as an option where its performance is acceptable.


>>> (We should have TIP#176 to simplify extraction of "strident
>>> groups"!)
>> Probably...  An expr function to calculate an index given an offset
>> striding, might be handy...  Something like:
> 
> Actually, #176 got implemented for 8.6, so extracting a group
> is a simple [lrange] command without any expr, multiplication, 
> division, or modulo.

Yes, but finding the group isn't!  At the very least, index arithmetic
would need to be extended to allow multiple additions/subtractions so
you can remove the -start offset prior to adding the offset into the
group that you're wanting.  And it comes in many cases with a small but
not irrelevant increase in script complexity, and at least three
variable accesses that weren't needed previously.  The whole point of
adding index arithmetic is to make things simpler, and the whole point
of -stride without -index matching against the whole group of items is
exactly the same, making things simpler, and taking complexity out of
the script.


>>> Assuming $index is the index into sub-lists, and the index of
>>> the actual matching element were returned, it would be
>>>   set first [lsearch -index $index -start 1 -stride 2]
>>>   set second [lsearch -index $index -start $first -stride 2]
>> No, it wouldn't, because the second search is being started on an
>> item that already matches the search, and so the exact same item
>> will be found twice.  You need to adjust the first returned index,
>> prior to the second search.
> 
> Ooops, sorry!  The same for the existing lsearch, requiring an
> (ugly) [expr $previous+1] or [incr previous], so the striding
> lsearch (as I see it) would need [incr previous 2] (for -stride 2).

That is the basis for my wish to add -stride scaling to the index
arithmetic.  You could then simply say "-start $previous+(1)", or
something along those lines, with the "(1)" being interpreted as
"multiply 1 by the -stride value".


> # a  key,value,value  list:
> 
> set kvv [list key1 A1 B1 key2 A2 B2 key3 A3 B3 key4 A4 B4 keyn An Bn
> key12 A12 B12]
> 
> # search for "2" in A entries (only!):
> 
> set match [lseach -stride 3 -start 1 $kvv {*2*}]
> if { $match <0 } { return ... } 
> puts "found group [lrange $kvv $match-1 $match+1]"
> set another [lseach -stride 3 -start [incr match 3] $kvv {*2*}]
> if { $another>=0 } {
>   puts "found another group [lrange $kvv $another-1 $another+1]"
> }
> 
> should report:
> 
> found group key2 A2 B2
> found another group key12 A12 B12

Yeah.  I agree, sans the odd typo.  Except that there should be an
"-index 0" added to your [lsearch] command.  OR, use "-index 1" instead
of the "-start 1".

That doesn't address in any way, however, the whole argument I've been
making all this time.


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

I believe that is an error, personally.  [lsort] in its present state
should throw an error if -index isn't given, or add this very same
functionality.  As it stands, "-index 0" in [lsort] is "default
behaviour", and should either be made explicit, or generalised to the
natural extent, which is what I'm talking about here for [lsearch].
I'd hazard to say that it wouldn't be any harder to implement for
[lsearch], although the performance impact of the naive approach would
be compounded due to the fact [lsort] quite commonly compares any given
item multiple times during the sort.  So I'd personally recommend
amending it to insist that -index be given when -stride is used.

-- 
Fredderic

Debian/unstable (LC#384816) on i686 2.6.29-2-686 2009 (up 4 days,  2:57)

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

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

Fredderic <mag...@gm...> writes:

> On 14 Jul 2009 20:44:32 -0700, 
> Donald Arseneau <as...@tr...> wrote:
> 
> > But the TIP states "it should return the indices of the first element 
> > of the striding group(s) that is/are being indicated", and I think
> > that is terribly wrong!  It should return the index/indices of the
> > actual list element that matched.  That would enable the simple
> > countinuation using -start and would fit better with what other
> > lsearches return (the actual raw index).
> 
> I don't understand that...  Given the following line:
> 
>     lsearch -all -stride 3 -start 1 \
>         {junk abc def ghi 123 456 789} {*[e8]*}
> 
> I want lsearch to return {1 4}, you seem to want it to return {2 6}.

No!  I expect it to return {2}.  lsearch without -stride returns {2 6}
but when given "-stride 3 -start 1" lsearch should only ever look at
items 1,4,7,... and should not match any other elements.

> Given {1 4} as a return value, I can directly access any element within
> the indicated group(s).  Without the -all, the result will be 1, and
> regardless of which word in the group matched (eg. using the pattern
> *[b8]* instead),

What you are looking for is not a stride of 3, but some "funky modulo
math" (actually, divide and multiply) appled to a regular [lsearch] 
result. I don't see how that merits any change to the lsearch command 
itself.  And how much use would such whole-group searches be? When
you have a flat key-value list you usually want to search the keys or
the values, not both indiscriminantly.

We really need a more detailed TIP to eliminate these discussions at
cross-purposes.

> Given your response of {2 6}, 

not 

> in order to do any of that I need to do a
> bit of funky modulo math to adjust the index back to the start of the
> group, and then add the offset to the item and/or group that I want.

No modulo math.  You are talking about a searching all elements
in the group, and I don't think that is what the TIP proposes.
We need a clearer TIP.  

> > (We should have TIP#176 to simplify extraction of "strident groups"!)
> 
> Probably...  An expr function to calculate an index given an offset
> striding, might be handy...  Something like:

Actually, #176 got implemented for 8.6, so extracting a group
is a simple [lrange] command without any expr, multiplication, 
division, or modulo.

> > Assuming $index is the index into sub-lists, and the index of
> > the actual matching element were returned, it would be
> > 
> > set first [lsearch -index $index -start 1 -stride 2]
> > set second [lsearch -index $index -start $first -stride 2]
> 
> No, it wouldn't, because the second search is being started on an item
> that already matches the search, and so the exact same item will be
> found twice.  You need to adjust the first returned index, prior to the
> second search.

Ooops, sorry!  The same for the existing lsearch, requiring an
(ugly) [expr $previous+1] or [incr previous], so the striding
lsearch (as I see it) would need [incr previous 2] (for -stride 2).


# a  key,value,value  list:

set kvv [list key1 A1 B1 key2 A2 B2 key3 A3 B3 key4 A4 B4 keyn An Bn key12 A12 B12]

# search for "2" in A entries (only!):

set match [lseach -stride 3 -start 1 $kvv {*2*}]
if { $match <0 } { return ... } 
puts "found group [lrange $kvv $match-1 $match+1]"
set another [lseach -stride 3 -start [incr match 3] $kvv {*2*}]
if { $another>=0 } {
  puts "found another group [lrange $kvv $another-1 $another+1]"
}

should report:

found group key2 A2 B2
found another group key12 A12 B12


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


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

Re: [TCLCORE] CONST86 and extensions

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

Alexandre Ferrieux wrote:
> Hi Jan,
> 
> I'm really ignorant about const-nightmares. I would just like a tiny
> piece advice on how to handle CONST86 qualifiers that are present in
> the generic stubs stable and thus could be accessed by extensions.
> More concretely, Thread has a bunch of warnings due to not using the
> qualifier when calling Tcl_GetObjType and assigning the result.
> So: should extensions use CONST86 too ? (I know it is a compile-time
> value, but it doesn't affect the ABI, right ?)

The statements tossing warnings all seem to be examples of what
I called "Type II" when giving migration advice for CONST84.
See http://wiki.tcl.tk/3669 .

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?

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

[TCLCORE] CONST86 and extensions

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

Hi Jan,

I'm really ignorant about const-nightmares. I would just like a tiny
piece advice on how to handle CONST86 qualifiers that are present in
the generic stubs stable and thus could be accessed by extensions.
More concretely, Thread has a bunch of warnings due to not using the
qualifier when calling Tcl_GetObjType and assigning the result.
So: should extensions use CONST86 too ? (I know it is a compile-time
value, but it doesn't affect the ABI, right ?)

TIA,

-Alex

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

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

Fredderic wrote:
> I don't understand that...  Given the following line:
> 
>     lsearch -all -stride 3 -start 1 \
>         {junk abc def ghi 123 456 789} {*[e8]*}
> 
> I want lsearch to return {1 4}, you seem to want it to return {2 6}.

I think that if you use -stride without -index, you must be matching
against the string version of the whole sublist. In that situation, you
have to return the index of the first item in the sublist because you
don't know where in the sublist you matched. By extension, when you add
-index you should still be getting the indices of the start of the
matched sublists, as you're still matching the whole group.

> If I want to start the search from the 2nd item in the 3rd group with a
> stride of 4 and allowing for 5 junk items at the start of the list, how
> else would you calculate the item position?  The non-modulo proposal
> requires that I calculate that to get the index of the item to search
> on.  ie. 4*3+2+5 -> 19

The purpose of -start is to allow people to incrementally find all items
in a list. This means that it should accept the values as are produced
by [lsearch] (though incremented by the -stride I suppose).

More interesting is dealing with what happens at the end of the list if
there is an incomplete sublist there. Not sure what to do in that case
(assume empty or error?)

> Returning a value modulo the stride, gives you a perfect base from
> which to work.  You can trivially find the start of any group relative
> to the one found, and any item at a known position within that group.
> Without the modulo.  In the case where you're searching a specific item
> within the sub-group, it's trivial to go forwards or backwards a couple
> items.  The difficulty comes in when you're searching for a pattern
> that matches the entire item group, as in the present case of searching
> sub-lists with a regular string match.

That'll be an expensive case. Perhaps enough so that maybe we should
disallow -stride without -index; matching what [lsort] does would be
best I suppose.

> The idea of -stride is to avoid having to rebuild a potentially very
> large list into a list of sub-lists.  If [lsearch -stride] can't
> accomplish that goal, then there's next to no point to having it, and
> this entire discussion is moot.

Precisely.

>> Back to TIP#351, one thing is certainly clear -- that the TIP is 
>> under-specified by not describing the proposed functionality in
>> detail.
> 
> No argument there...

Then improve it. (Sheesh!)

Donal.

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

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

On Mon, 13 Jul 2009 20:04:23 -0500, 
Peter da Silva <pe...@ta...> wrote:

>> To turn the question on its head, if you have sublists, why do
>> you need -stride?  
> 
> Same reason. It just doesn't seem obvious to me to deal with them as  
> virtual embedded sublists and change the meaning of -index. But if  
> it's already gone out that way in lsort I guess I'd best bow to the  
> inevitable gracefully. :)

At the risk of repeating myself...  Again, you're NOT changing the
meaning of -index.  It means exactly the same as it always has.

What you ARE changing, is the interpretation of the list structure.
You're adding a level of grouping before the first obvious level, and
therefore further information is required.  Why not put it in -index,
along with all the other information of exactly the same intent?

How you choose to view the concept, whether it's "virtual embedded
sublists" or whatever, is immaterial.  It's still a grouping of items
within an otherwise flat list, which COULD be represented as a list of
sub-lists, with some extra processing effort.  Whether the grouping size
is permanent for the life of the list, or variable, is likewise
irrelevant, and the theoretical possibility of variable grouping size
is about all the reason we need for the existence of -stride, rather
than having to repeatedly re-group the list for each possible grouping.

-- 
Fredderic

Debian/unstable (LC#384816) on i686 2.6.29-2-686 2009 (up 3 days, 12:42)

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

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

On 14 Jul 2009 20:44:32 -0700, 
Donald Arseneau <as...@tr...> wrote:

> Fredderic <mag...@gm...> writes:
>> But how much sense does it make for a human?  -start already has a
>> purpose.  It should accept a value relative to the value returned
>> from a previous [lsearch], for the purpose of continuing the
>> previous [lsearch].  Complicating it by adding in the index of the
>> item you want is unnecessary.
> 
> Those purposes complement each other well.  One could start the
> striding at a fixed position (say 1), get the index of the first
> match, and later resume striding from that match result.

No issue here...  An initial list offset to skip any fixed out-of-band
items at the start, and the offset from there to the group of items
being searched right here, are exactly what -start has always been for.


> But the TIP states "it should return the indices of the first element 
> of the striding group(s) that is/are being indicated", and I think
> that is terribly wrong!  It should return the index/indices of the
> actual list element that matched.  That would enable the simple
> countinuation using -start and would fit better with what other
> lsearches return (the actual raw index).

I don't understand that...  Given the following line:

    lsearch -all -stride 3 -start 1 \
        {junk abc def ghi 123 456 789} {*[e8]*}

I want lsearch to return {1 4}, you seem to want it to return {2 6}.

Given {1 4} as a return value, I can directly access any element within
the indicated group(s).  Without the -all, the result will be 1, and
regardless of which word in the group matched (eg. using the pattern
*[b8]* instead), I know the next group will be at 4, the one after at
7, and so forth.

Given your response of {2 6}, in order to do any of that I need to do a
bit of funky modulo math to adjust the index back to the start of the
group, and then add the offset to the item and/or group that I want.
The thing is, I can already do that, simply by leaving off the -stride
option entirely.  Without it, it'll find the first/every word that
matches, and I can do whatever I want with it just the same.  Having
-stride do the modulo thing on the result, is exposing information which
[lsearch] already has, which IS useful, and which isn't always obvious
how to obtain.  (It took me a moment to work out how to perform a
modulo with an offset.)


> I imagine (without foundation) that the "first element" index was
> chosen to simplify later lrange and such for the whole group, but 
> it doesn't seem to simplify that use by much.

I disagree.  With it, we can use the built in index arithmetic
capability of [lindex] and friends.  Without it, we need to mess around
with [expr], subtracting the offset, performing the modulo, adding the
offset back on, and then adding the offset to to the item/group we want.

Unless you can give me an example demonstrating otherwise...


> (We should have TIP#176 to simplify extraction of "strident groups"!)

Probably...  An expr function to calculate an index given an offset
striding, might be handy...  Something like:

	stride_to_idx(stride,group?,start?,offset??) :=
	(stride*group+start+offset)

and maybe

	group_from_index(index,stride,offset) :=
	((index-offset)%stride+offset)

Not sure if they're exactly correct, but hopefully you get the idea...
It is, however, a separate issue.


>>  -index $index -start [expr {$stride*$strideOffset+$startOffset}]
> Very ugly, and I'm not sure why you multiply.

Probably should of used "groupNumber" instead of "strideOffset"...
Confusing the terminology.

If I want to start the search from the 2nd item in the 3rd group with a
stride of 4 and allowing for 5 junk items at the start of the list, how
else would you calculate the item position?  The non-modulo proposal
requires that I calculate that to get the index of the item to search
on.  ie. 4*3+2+5 -> 19


> Assuming $index is the index into sub-lists, and the index of
> the actual matching element were returned, it would be
> 
> set first [lsearch -index $index -start 1 -stride 2]
> set second [lsearch -index $index -start $first -stride 2]

No, it wouldn't, because the second search is being started on an item
that already matches the search, and so the exact same item will be
found twice.  You need to adjust the first returned index, prior to the
second search.


>> The -start argument should work in the context of the index value
>> returned by [lsearch].  If [lsearch] returns a value module the
>> stride,
> Surely it would never return a value modulo the stride!  That would be
> useless -- always returning the same value!  If it returns a value 
> *divided by* the stride (integer division) then it is hard to use,
> and I surely would not like it (see "ugly" above).

Returning a value modulo the stride, gives you a perfect base from
which to work.  You can trivially find the start of any group relative
to the one found, and any item at a known position within that group.
Without the modulo.  In the case where you're searching a specific item
within the sub-group, it's trivial to go forwards or backwards a couple
items.  The difficulty comes in when you're searching for a pattern
that matches the entire item group, as in the present case of searching
sub-lists with a regular string match.

The idea of -stride is to avoid having to rebuild a potentially very
large list into a list of sub-lists.  If [lsearch -stride] can't
accomplish that goal, then there's next to no point to having it, and
this entire discussion is moot.


>> I do think, however, that -start needs index arithmetic capability,
>> and that capability needs to be extended to allow for stride
>> scaling.
> Yes TIP176.  But stride "scaling"?  Just offsets gives good
> usefulness.

I agree, just offsets gives good usefulness.  But not complete
usefulness.  Think about the "load effective address" instruction in
various microprocessors.  It does exactly this job; takes one value,
multiplies it by a (usually) directly specified constant scaling factor,
and then adds an offset (and on some processors even another,
usually directly specified, constant offset).  This instruction,
intended for calculating addresses into arrays of structs, ends up
being used by intelligent compilers to factor out portions of regular
mathematical expressions as well.

The -stride option to [lsearch] is analogous to that array addressing.
You have an array "element" which is a given number of list words
long.  The first item may be at an offset from the start of the address
space (the first word of the list), and you want to find an item within
that array element.  Doing that requires, at least, two additions and a
multiplication, with one multiplicand and one offset being constants
according to the current interpretation of the list structure.


>> Perhaps something like bracketed numbers should be scaled...?  (2)+1
>> would mean (stride*2)+1.  Doing that would negate this question
>> out-right.  "-start 1+(2)" would mean "skip one item, and then start
>> with the second stride grouping".
> More "ugly".

I agree, it's not pretty.  But it is simple, which was the intention.
If people agree that it's useful, then hopefully new discussion will
help alleviate the "ugly".  I'm just focusing on the useful part for
now.


> I see now that overloading -index on the lsort command was a mistake,
> and it would have been better to introduce -start (or -offset or such)
> to indicate the item within the stride, and have the interpretation
> of -index be consistent between [lsort] and [lsort -stride];  it is
> quite ugly that [lsort -index 1] is different from [lsort -index 1
> -stride 1].

I don't think it was a mistake.  I think it does the job just fine.
-index immediately said to me exactly what was intended, that it's
being used to select the item within a stride group at which the sort
keying is to be applied.  Likewise, it says to me exactly what it should
be saying, with [lsearch].  And still does, with the addition of stride
groups.

The -stride option is saying that there is a non-obvious level
grouping, that we didn't know existed otherwise.  EACH level of
grouping, obvious or otherwise, needs the index specified.  -stride
isn't adding anything new, it's simply specifying what's already
there.  And if you're using it, then you already know it's there, so
what's the problem?

The difference in interpretation of -index in this case, really doesn't
exist at all.  It still means the exact same thing; "-index 1" is still
referring tot he second word of the first level of grouping.  What HAS
changed, isn't the meaning of -index, but the number of levels of
grouping, and the level at which the first obvious grouping occurs.

Obviously, to access the same item with the addition of a new level of
grouping, you need to provide a new piece of information.


>>> As I recall, the alternatives I considered for specifying
>>> the offset within each group when using lsort -stride were:
>>> 1) A new -strideOffset option.
> Much better (but what was wrong with -offset?).

Whether you add an extra item to -index, or add a whole new -offset
option, is 6 of this and half a dozen of the other.  Personally, I'd
rather have -index hold the extra information.  If -stride is given,
then you already know you need to provide an offset.  Using -index
allows the same operation to be performed with one piece of data,
instead of two, and maintains the conceptual link.

Now, if it made sense that the caller of your function might not know
that one level of grouping in the list structure had been added
mysteriously, then I'd be supporting keeping them separate.  But I
really can't imagine that being sane.  -offset does the same thing as
-index, the structure of the list (sub-lists vs. stride) should be an
implementation detail, and nothing more.  In my mind, at least, -stride
and -index alone, facilitate that.


> Back to TIP#351, one thing is certainly clear -- that the TIP is 
> under-specified by not describing the proposed functionality in
> detail.

No argument there...

-- 
Fredderic

Debian/unstable (LC#384816) on i686 2.6.29-2-686 2009 (up 3 days, 11:41)

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

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

Fredderic <mag...@gm...> writes:

> But how much sense does it make for a human?  -start already has a
> purpose.  It should accept a value relative to the value returned from
> a previous [lsearch], for the purpose of continuing the previous
> [lsearch].  Complicating it by adding in the index of the item you want
> is unnecessary.

Those purposes complement each other well.  One could start the striding
at a fixed position (say 1), get the index of the first match, and later
resume striding from that match result.

But the TIP states "it should return the indices of the first element 
of the striding group(s) that is/are being indicated", and I think that
is terribly wrong!  It should return the index/indices of the actual
list element that matched.  That would enable the simple countinuation
using -start and would fit better with what other lsearches return
(the actual raw index).

I imagine (without foundation) that the "first element" index was
chosen to simplify later lrange and such for the whole group, but 
it doesn't seem to simplify that use by much.

(We should have TIP#176 to simplify extraction of "strident groups"!)

>  -index $index -start [expr {$stride*$strideOffset+$startOffset}]

Very ugly, and I'm not sure why you multiply.

Assuming $index is the index into sub-lists, and the index of
the actual matching element were returned, it would be

set first [lsearch -index $index -start 1 -stride 2]
set second [lsearch -index $index -start $first -stride 2]


> The -start argument should work in the context of the index value
> returned by [lsearch].  If [lsearch] returns a value module the stride,

Surely it would never return a value modulo the stride!  That would be
useless -- always returning the same value!  If it returns a value 
*divided by* the stride (integer division) then it is hard to use, and 
I surely would not like it (see "ugly" above).

> I do think, however, that -start needs index arithmetic capability, and
> that capability needs to be extended to allow for stride scaling.

Yes TIP176.  But stride "scaling"?  Just offsets gives good usefulness.

> Perhaps something like bracketed numbers should be scaled...?  (2)+1
> would mean (stride*2)+1.  Doing that would negate this question
> out-right.  "-start 1+(2)" would mean "skip one item, and then start
> with the second stride grouping".

More "ugly".


I see now that overloading -index on the lsort command was a mistake,
and it would have been better to introduce -start (or -offset or such)
to indicate the item within the stride, and have the interpretation of 
-index be consistent between [lsort] and [lsort -stride];  it is quite
ugly that [lsort -index 1] is different from [lsort -index 1 -stride 1].

> > As I recall, the alternatives I considered for specifying
> > the offset within each group when using lsort -stride were:
> > 1) A new -strideOffset option.

Much better (but what was wrong with -offset?).

Back to TIP#351, one thing is certainly clear -- that the TIP is 
under-specified by not describing the proposed functionality in detail.


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