I wanted to include "parray" output in a report (on stdout),
but I needed it indented by a given string before each line.

The trick was rather simple in hindsight:

proc ind_parray {ind arr} {
upvar 1 $arr "$ind$arr"; parray "$ind$arr"
}

It works well for pure whitespace-indentations, and probably
most others as long as $ind doesn't contain "::" .

Just thought I'd share.

On 2/7/2023 5:09 PM, Andreas Leitgeb wrote:
> I wanted to include "parray" output in a report (on stdout),
> but I needed it indented by a given string before each line.
>
> The trick was rather simple in hindsight:
>
> proc ind_parray {ind arr} {
> upvar 1 $arr "$ind$arr"; parray "$ind$arr"
> }
>
> It works well for pure whitespace-indentations, and probably
> most others as long as $ind doesn't contain "::" .
>
> Just thought I'd share.

I too often use parray, and since it's easily modified (it's
autoloaded and found in tcl86/lib along with a few other commands) I
change it to use a -dictionary sort by default. I find that works
better when the indices are numerical, and alpha when not.

I wrote up a ticket once, since IMHO it is an oversight not to use a
dictionary sort and found a TIP to be a bit overkill.

My modified version changes the arglist to:

proc parray {a {pattern *} {type -dictionary}} {

and the lsort to:

set names [lsort {*}$type [array names array $pattern]]

which then allows for such things as -ascii or {-ascii -decreasing}
at the small cost of requiring the * if you still want that.

Andreas Leitgeb <avl@logic.at> writes:
> I wanted to include "parray" output in a report (on stdout),
> but I needed it indented by a given string before each line.
>
> The trick was rather simple in hindsight:
>
> proc ind_parray {ind arr} {
> upvar 1 $arr "$ind$arr"; parray "$ind$arr"
> }
>
> It works well for pure whitespace-indentations, and probably
> most others as long as $ind doesn't contain "::" .
>
> Just thought I'd share.

But .. I don't get it? Could you please elaborate a bit more what do you
do here?

Rolf Ade <rolf@pointsman.de> wrote:
>
> Andreas Leitgeb <avl@logic.at> writes:
>> I wanted to include "parray" output in a report (on stdout),
>> but I needed it indented by a given string before each line.
>>
>> The trick was rather simple in hindsight:
>>
>> proc ind_parray {ind arr} {
>> upvar 1 $arr "$ind$arr"; parray "$ind$arr"
>> }
>>
>> It works well for pure whitespace-indentations, and probably
>> most others as long as $ind doesn't contain "::" .
>>
>> Just thought I'd share.
>
> But .. I don't get it? Could you please elaborate a bit more what do you
> do here?

Inside the proc ind_parray the array variable that is being printed is
linked to a new name, that new name being the concatenation of an
"indent string" ($ind - presumably usually spaces or a few ASCII tabs
would be the usual content) and the origional array name from the
caller ($arr).

Then parray is called to "print" this new variable name.

Since the new name has the indent string prefixed, the array names
output from parray come out "spaced over" from where they would
otherwise be:

$ rlwrap tclsh
% parray tcl_platform
tcl_platform(byteOrder) = littleEndian
...

% ind_parray " " tcl_platform
tcl_platform(byteOrder) = littleEndian
...

Indent string can be just about anything, other than containing a :: or
[] sequence:

% ind_parray "Mary Had A Little Lamb " tcl_platform
Mary Had A Little Lamb tcl_platform(byteOrder) = littleEndian
...

% ind_parray " { } [ ] $ " tcl_platform
{ } $ tcl_platform(byteOrder) = littleEndian
...

On Tuesday, February 7, 2023 at 5:09:38 PM UTC-8, Andreas Leitgeb wrote:
> I wanted to include "parray" output in a report (on stdout),
> but I needed it indented by a given string before each line.
>
> The trick was rather simple in hindsight:
>
> proc ind_parray {ind arr} {
> upvar 1 $arr "$ind$arr"; parray "$ind$arr"
> }
>
> It works well for pure whitespace-indentations, and probably
> most others as long as $ind doesn't contain "::" .
>
> Just thought I'd share.
Andreas,
Simple and useful. Clever, thanks...and doesn't require 6000 scrollable text boxes {;-)

> Rolf Ade <rolf@pointsman.de> wrote:
>> Andreas Leitgeb <avl@logic.at> writes:
>>> I wanted to include "parray" output in a report (on stdout),
>>> but I needed it indented by a given string before each line.
>>> The trick was rather simple in hindsight:
>>> proc ind_parray {ind arr} {
>>> upvar 1 $arr "$ind$arr"; parray "$ind$arr"
>>> }
>>> It works well for pure whitespace-indentations, and probably
>>> most others as long as $ind doesn't contain "::" .
>> But .. I don't get it? Could you please elaborate a bit more what do you
>> do here?

My specific context was parsing pdf-files - which contain data structures
similar to dict values. I then turn them into an array and use my indenting
parray wrapper to print the array out to stdout. Depending on where exactly
the dict occurred in the pdf (i.e.: maybe nested) I want it indented.

Rich <rich@example.invalid> wrote:
> Indent string can be just about anything, other than containing a :: or
> [] sequence:

Rich, regarding [ ] you got confused over Tcl's parsing rules...

> % ind_parray " { } [ ] $ " tcl_platform
> { } $ tcl_platform(byteOrder) = littleEndian

The "[ ]" inside the double-quoted string got substed away, even before
ind_parray got to see it.

The only thing that really must not occur in the indent is "::",
as that would let the array appear to be in a namespace.

Originally, I expected open parentheses "(" to cause problems, but that
isn't the case... unless the original array name itself ends in ")",
which it easily could ;-)

et99 <et99@rocketship1.me> wrote:
> I too often use parray, and since it's easily modified (it's
> autoloaded and found in tcl86/lib along with a few other commands) I
> change it to use a -dictionary sort by default. I find that works
> better when the indices are numerical, and alpha when not.
>
> I wrote up a ticket once, since IMHO it is an oversight not to use a
> dictionary sort

I agree.
Purely integral array indices are probably quite common in practice.

> and found a TIP to be a bit overkill.

I disagree. At least it's not overkill for the following
extended suggestion:

> My modified version changes the arglist to:
> proc parray {a {pattern *} {type -dictionary}} {
> and the lsort to:
> set names [lsort {*}$type [array names array $pattern]]
> which then allows for such things as -ascii or {-ascii -decreasing}
> at the small cost of requiring the * if you still want that.

and I'd also welcome another option for indentation ;-)

On 12/02/2023 16:04, Andreas Leitgeb wrote:
> et99 <et99@rocketship1.me> wrote:
>> I too often use parray, and since it's easily modified (it's
>> autoloaded and found in tcl86/lib along with a few other commands) I
>> change it to use a -dictionary sort by default. I find that works
>> better when the indices are numerical, and alpha when not.
>>
>> I wrote up a ticket once, since IMHO it is an oversight not to use a
>> dictionary sort
>
> I agree.
> Purely integral array indices are probably quite common in practice.
>
>> and found a TIP to be a bit overkill.
>
> I disagree. At least it's not overkill for the following
> extended suggestion:
>
>> My modified version changes the arglist to:
>> proc parray {a {pattern *} {type -dictionary}} {
>> and the lsort to:
>> set names [lsort {*}$type [array names array $pattern]]
>> which then allows for such things as -ascii or {-ascii -decreasing}
>> at the small cost of requiring the * if you still want that.
>
> and I'd also welcome another option for indentation ;-)
>
If you're putting together a TIP, I'd welcome an argument to specify an
output script, making the calling sequence

proc parray {a {pattern *} {type -dictionary} {script {puts stdout}}}

On Monday, February 13, 2023 at 1:41:20 PM UTC+1, Alan Grunwald wrote:
> On 12/02/2023 16:04, Andreas Leitgeb wrote:
> > et99 wrote:
> >> I too often use parray, and since it's easily modified (it's
> >> autoloaded and found in tcl86/lib along with a few other commands) I
> >> change it to use a -dictionary sort by default. I find that works
> >> better when the indices are numerical, and alpha when not.
> >>
> >> I wrote up a ticket once, since IMHO it is an oversight not to use a
> >> dictionary sort
> >
> > I agree.
> > Purely integral array indices are probably quite common in practice.
> >
> >> and found a TIP to be a bit overkill.
> >
> > I disagree. At least it's not overkill for the following
> > extended suggestion:
> >
> >> My modified version changes the arglist to:
> >> proc parray {a {pattern *} {type -dictionary}} {
> >> and the lsort to:
> >> set names [lsort {*}$type [array names array $pattern]]
> >> which then allows for such things as -ascii or {-ascii -decreasing}
> >> at the small cost of requiring the * if you still want that.
> >
> > and I'd also welcome another option for indentation ;-)
> >
> If you're putting together a TIP, I'd welcome an argument to specify an
> output script, making the calling sequence
>
> proc parray {a {pattern *} {type -dictionary} {script {puts stdout}}}

Looking to balance cost for effort, isn't that asking for a wrapper to the example of the array command?

foreach {color count} [array get colorcount] {
puts "Color: $color Count: $count"
}

I'd understand optional {channelId stdout} - and I would still warn about bad experience with this many optional positional parameters, i.e. I'd prefer switches.

parray -dictionary -format {Color: %10s Count: %10s} -chan stderr colorcount

On 2/13/2023 7:41 AM, Alan Grunwald wrote:

> If you're putting together a TIP, I'd welcome an argument to specify an
> output script, making the calling sequence
>
> proc parray {a {pattern *} {type -dictionary} {script {puts stdout}}}
>
>

Not mentioned yet but for me a major inconvenience with parray is that
it is not copy-paste ready. If you are using parray, most likely you are
interested in the contents of an element or a list. And almost always
you'd want to update it with some changes. Here comes the trouble: you
need to type "set ", copy-paste the array variable name, skip over the
"=", and copy paste the value and make changes to it. Since the value is
stripped off its braces, you will need to be a bit careful about
including those as well. In other words, its output is not "source"-able
and requires editing.

Am 13.02.23 um 19:10 schrieb saitology9:
> On 2/13/2023 7:41 AM, Alan Grunwald wrote:
>
>> If you're putting together a TIP, I'd welcome an argument to specify
>> an output script, making the calling sequence
>>
>> proc parray {a {pattern *} {type -dictionary} {script {puts stdout}}}
>>
>>
>
> Not mentioned yet but for me a major inconvenience with parray is that
> it is not copy-paste ready. If you are using parray, most likely you are
> interested in the contents of an element or a list. And almost always
> you'd want to update it with some changes. Here comes the trouble: you
> need to type "set ", copy-paste the array variable name, skip over the [....]

Use tkcon. Then you say "edit <varname>" and a window pops up with an
editable version. By choosing "Send to slave" from the menu, it will be
updated in the interpreter. The nice thing is that it works with procs,
arrays and ordinary variables.

Christian

On 2/13/2023 1:14 PM, Christian Gollwitzer wrote:

>
> Use tkcon. Then you say "edit <varname>" and a window pops up with an
> editable version. By choosing "Send to slave" from the menu, it will be
> updated in the interpreter. The nice thing is that it works with procs,
> arrays and ordinary variables.
>

Nice! It still requires editing if you need to change one item only but
I can see it being quite useful.

On 2/13/2023 12:53 PM, saitology9 wrote:
> On 2/13/2023 1:14 PM, Christian Gollwitzer wrote:
>
>>
>> Use tkcon. Then you say "edit <varname>" and a window pops up with an editable version. By choosing "Send to slave" from the menu, it will be updated in the interpreter. The nice thing is that it works with procs, arrays and ordinary variables.
>>
>
> Nice! It still requires editing if you need to change one item only but I can see it being quite useful.
>

I felt a TIP was overkill since the parray code is so easily
modified being just 18 lines long. I also think most TIP
voters would also just say use tkcon. Something TIP worthy should
probably be an ensemble of debug listing commands, which is
how I use parray.

I actually shorten it to [la] and it's one of my set of [l?]
commands for listing globals, lists, arrays, dicts, procedure
bodies, widgets, etc. My [la] version also can match against
the value or the indices, and output either matches or non-
matches.

With any new release, I begin with an Ashok tclkit with twapi
and gui, and create a starpak with my l? commands for
debugging. This way I can have many tcl (and twapi) versions
available if some change breaks my code (like when twapi
handles changed their format).

[lg] for globals, is actually my favorite. I first make a list
of all the initial global variables in the starpak init, and
then by default only list globals I've added afterwards. Very
handy for debugging the smallish programs I typically write to
script tedious windows gui actions using twapi.

On 13/02/2023 13:55, heinrichmartin wrote:
> On Monday, February 13, 2023 at 1:41:20 PM UTC+1, Alan Grunwald wrote:
>> On 12/02/2023 16:04, Andreas Leitgeb wrote:
>>> et99 wrote:
>>>> I too often use parray, and since it's easily modified (it's
>>>> autoloaded and found in tcl86/lib along with a few other commands) I
>>>> change it to use a -dictionary sort by default. I find that works
>>>> better when the indices are numerical, and alpha when not.
>>>>
>>>> I wrote up a ticket once, since IMHO it is an oversight not to use a
>>>> dictionary sort
>>>
>>> I agree.
>>> Purely integral array indices are probably quite common in practice.
>>>
>>>> and found a TIP to be a bit overkill.
>>>
>>> I disagree. At least it's not overkill for the following
>>> extended suggestion:
>>>
>>>> My modified version changes the arglist to:
>>>> proc parray {a {pattern *} {type -dictionary}} {
>>>> and the lsort to:
>>>> set names [lsort {*}$type [array names array $pattern]]
>>>> which then allows for such things as -ascii or {-ascii -decreasing}
>>>> at the small cost of requiring the * if you still want that.
>>>
>>> and I'd also welcome another option for indentation ;-)
>>>
>> If you're putting together a TIP, I'd welcome an argument to specify an
>> output script, making the calling sequence
>>
>> proc parray {a {pattern *} {type -dictionary} {script {puts stdout}}}
>
> Looking to balance cost for effort, isn't that asking for a wrapper to the example of the array command?
>
> foreach {color count} [array get colorcount] {
> puts "Color: $color Count: $count"
> }
>
> I'd understand optional {channelId stdout} - and I would still warn about bad experience with this many optional positional parameters, i.e. I'd prefer switches.
>
> parray -dictionary -format {Color: %10s Count: %10s} -chan stderr colorcount
I agree that many optional parameters is a Bad Idea, and have no
objection to using switches.

I'd prefer

parray ... -output {whatever}

because at times you might wish to direct the output from parray to a
text widget or the like, rather than simply write it to a particular
channel.

Alan

I'm afraid, I think this thread has gone a bit "out of control"...

I don't think, "parray" itself ought to be turned into a swiss army
knife tool, but maybe some parray-on-steroids could be added to tcllib...

If that happens, I would suggest using
https://wiki.tcl-lang.org/page/TclImplForNamedArguments
to do the argument parsing ;-) - Afterall it's pure Tcl.

On 2/15/2023 5:00 AM, Andreas Leitgeb wrote:
> I'm afraid, I think this thread has gone a bit "out of control"...
>
> I don't think, "parray" itself ought to be turned into a swiss army
> knife tool, but maybe some parray-on-steroids could be added to tcllib...
>
I agree. I don't think I was clear; I was suggesting
that a new ensemble command like parray that would output
several types of info might be useful, not a
repurposing of parray itself.