Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

I came, I saw, I deleted all your files.


programming / comp.lang.tcl / Re: How to call procs that use each-others data

SubjectAuthor
* How to call procs that use each-others dataCecil Westerhof
`* Re: How to call procs that use each-others dataRich
 +- Re: How to call procs that use each-others dataCecil Westerhof
 `* Re: How to call procs that use each-others dataRobert Heller
  +* Re: How to call procs that use each-others datajtyler
  |`- Re: How to call procs that use each-others datamango
  `- Re: How to call procs that use each-others dataapn

1
Subject: How to call procs that use each-others data
From: Cecil Westerhof
Newsgroups: comp.lang.tcl
Organization: Decebal Computing
Date: Sat, 7 May 2022 04:08 UTC
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Cec...@decebal.nl (Cecil Westerhof)
Newsgroups: comp.lang.tcl
Subject: How to call procs that use each-others data
Date: Sat, 07 May 2022 06:08:53 +0200
Organization: Decebal Computing
Lines: 16
Message-ID: <877d6yhtm2.fsf@munus.decebal.nl>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="0bb501fec4c7843ba82d15083014ff3d";
logging-data="3161"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/5aJETfIaR51RiVz1L/URST8HpemU/O/k="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Cancel-Lock: sha1:lK5t7u/NXcc4PXm4+WlxgKYVYcQ=
sha1:P/2bFyzaRJYcNdoLjNrvcPfJLA0=
View all headers
I had the following code:
    set swapDict [fillSwapDict]
    set swapDict [mergeSwapDict ${swapDict} ${mergeList}]
    set swapList [sortedList ${swapDict}]
    displayList  ${swapList} ${end}

Each call does use the data of the call before it. So I thought it is
better to write it like this:
    displayList [sortedList [mergeSwapDict [fillSwapDict] ${mergeList}]] ${end}

Which is the 'better' way, or is another way better?

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof


Subject: Re: How to call procs that use each-others data
From: Rich
Newsgroups: comp.lang.tcl
Organization: A noiseless patient Spider
Date: Sat, 7 May 2022 12:39 UTC
References: 1
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ric...@example.invalid (Rich)
Newsgroups: comp.lang.tcl
Subject: Re: How to call procs that use each-others data
Date: Sat, 7 May 2022 12:39:07 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <t55p9b$2sv$1@dont-email.me>
References: <877d6yhtm2.fsf@munus.decebal.nl>
Injection-Date: Sat, 7 May 2022 12:39:07 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="287f73e33e98a5e0e6d50118f3c338ef";
logging-data="2975"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+JQDNd+lslfMM9UTxMDgvY"
User-Agent: tin/2.0.1-20111224 ("Achenvoir") (UNIX) (Linux/3.10.17 (x86_64))
Cancel-Lock: sha1:qMG+RfS7KiFLo3xSYC1u4Sv6QrY=
View all headers
Cecil Westerhof <Cecil@decebal.nl> wrote:
I had the following code:
   set swapDict [fillSwapDict]
   set swapDict [mergeSwapDict ${swapDict} ${mergeList}]
   set swapList [sortedList ${swapDict}]
   displayList  ${swapList} ${end}

Each call does use the data of the call before it. So I thought it is
better to write it like this:
   displayList [sortedList [mergeSwapDict [fillSwapDict] ${mergeList}]] ${end}

Which is the 'better' way, or is another way better?

There isn't.  You are slowly moving closer to merely a "stylistic"
issue on the order of whether this:

if (...) {
  ...
}

or this

if (...)
{
  ...
}

Arrangement of the openbrace for a C if clause is the "better way".

The second is more LISP like, and avoids having to allocate, and
ultimately destroy, three variables.  But you will find people who
argue with convincing reasons why either is 'better' than the other.

Use whichever you prefer, and don't fret over it.  Myself I use the
LISP like layout mostly, but will use the tempvar version on occasion
(and esp.  if one of the tempvar version can avoid processing the same
data into the same result two or more times).


Subject: Re: How to call procs that use each-others data
From: Cecil Westerhof
Newsgroups: comp.lang.tcl
Organization: Decebal Computing
Date: Sat, 7 May 2022 13:44 UTC
References: 1 2
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Cec...@decebal.nl (Cecil Westerhof)
Newsgroups: comp.lang.tcl
Subject: Re: How to call procs that use each-others data
Date: Sat, 07 May 2022 15:44:00 +0200
Organization: Decebal Computing
Lines: 56
Message-ID: <87zgjtfof3.fsf@munus.decebal.nl>
References: <877d6yhtm2.fsf@munus.decebal.nl> <t55p9b$2sv$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="0bb501fec4c7843ba82d15083014ff3d";
logging-data="990"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/NmpMhbzkeJXNQfi6PFLTzgABL3OV00V0="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Cancel-Lock: sha1:+fGSI9C/6rImBH+4UAV6a6rF9WU=
sha1:I2jr0kPknJtGXwDNt/9xQd9uf5w=
View all headers
Rich <rich@example.invalid> writes:

Cecil Westerhof <Cecil@decebal.nl> wrote:
I had the following code:
   set swapDict [fillSwapDict]
   set swapDict [mergeSwapDict ${swapDict} ${mergeList}]
   set swapList [sortedList ${swapDict}]
   displayList  ${swapList} ${end}

Each call does use the data of the call before it. So I thought it is
better to write it like this:
   displayList [sortedList [mergeSwapDict [fillSwapDict] ${mergeList}]] ${end}

Which is the 'better' way, or is another way better?

There isn't.  You are slowly moving closer to merely a "stylistic"
issue on the order of whether this:

if (...) {
  ...
}

or this

if (...)
{
  ...
}

Arrangement of the openbrace for a C if clause is the "better way".

Personally I prefer the first, but if I would work somewhere where
they prefer the second, I would use the second.


The second is more LISP like, and avoids having to allocate, and
ultimately destroy, three variables.  But you will find people who
argue with convincing reasons why either is 'better' than the other.

Yes, that is why I prefer the second. But when sharing your code (what
I intend to do) it is best to use a style that most people understand
better.


Use whichever you prefer, and don't fret over it.  Myself I use the
LISP like layout mostly, but will use the tempvar version on occasion
(and esp.  if one of the tempvar version can avoid processing the same
data into the same result two or more times).

I added extra functionality and for that I put the first tempvar back.
Shaved about a third of the execution time.

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof


Subject: Re: How to call procs that use each-others data
From: Robert Heller
Newsgroups: comp.lang.tcl
Organization: Deepwoods Software
Date: Sat, 7 May 2022 14:32 UTC
References: 1 2
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 07 May 2022 09:32:37 -0500
MIME-Version: 1.0
From: hel...@deepsoft.com (Robert Heller)
Organization: Deepwoods Software
X-Newsreader: TkNews 3.0 (1.2.12)
Subject: Re: How to call procs that use each-others data
In-Reply-To: <t55p9b$2sv$1@dont-email.me>
References: <877d6yhtm2.fsf@munus.decebal.nl> <t55p9b$2sv$1@dont-email.me>
Newsgroups: comp.lang.tcl
Content-Type: text/plain;
charset="us-ascii"
Originator: heller@sharky4.deepsoft.com
Message-ID: <0-6dnR8EDPCYHuv_nZ2dnUU7-afNnZ2d@giganews.com>
Date: Sat, 07 May 2022 09:32:37 -0500
Lines: 58
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-0M4QiZLYGuLDT6m31mCKztCHMPHjFCTk/EnARB8ULCQQmyk7LoEU/gs/rolBmwNIZHspkPgNbtWdKlD!GDBGcC8TbZ9fTwdypKv8vUBX64lvQo6e/D9Oad5YFoZvgF+osKOUgM9lQVIg1R1MkhyPrGqwm8OS!8OM=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3408
View all headers
At Sat, 7 May 2022 12:39:07 -0000 (UTC) Rich <rich@example.invalid> wrote:


Cecil Westerhof <Cecil@decebal.nl> wrote:
I had the following code:
   set swapDict [fillSwapDict]
   set swapDict [mergeSwapDict ${swapDict} ${mergeList}]
   set swapList [sortedList ${swapDict}]
   displayList  ${swapList} ${end}

Each call does use the data of the call before it. So I thought it is
better to write it like this:
   displayList [sortedList [mergeSwapDict [fillSwapDict] ${mergeList}]] ${end}

Which is the 'better' way, or is another way better?

There isn't.  You are slowly moving closer to merely a "stylistic"
issue on the order of whether this:

if (...) {
  ...
}

or this

if (...)
{
  ...
}

Arrangement of the openbrace for a C if clause is the "better way".

The second is more LISP like, and avoids having to allocate, and
ultimately destroy, three variables.  But you will find people who
argue with convincing reasons why either is 'better' than the other.

Use whichever you prefer, and don't fret over it.  Myself I use the
LISP like layout mostly, but will use the tempvar version on occasion
(and esp.  if one of the tempvar version can avoid processing the same
data into the same result two or more times).

The only other issue is source code readablity.  *Sometimes* you end up with
either a really long line (which does not "fit" on your screen, unless you
have an insanely large edit windows and/or are using a really small font), or
an insanely large number of continue lines (and possibly really large
indenting).  Sometime breaking up a large and complex expression into
subexpressions results in code that is easier to read and understand (and in
some cases easier to debug).

                                                                                                                


--
Robert Heller             -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
          


Subject: Re: How to call procs that use each-others data
From: jtyler
Newsgroups: comp.lang.tcl
Organization: Aioe.org NNTP Server
Date: Sat, 7 May 2022 17:43 UTC
References: 1 2 3
Path: i2pn2.org!i2pn.org!aioe.org!YN2ulY6LKp1eoOUw2OJ8ig.user.46.165.242.91.POSTED!not-for-mail
From: jtyler...@gmail.com (jtyler)
Newsgroups: comp.lang.tcl
Subject: Re: How to call procs that use each-others data
Date: Sat, 7 May 2022 10:43:45 -0700
Organization: Aioe.org NNTP Server
Message-ID: <t56b4i$1c58$1@gioia.aioe.org>
References: <877d6yhtm2.fsf@munus.decebal.nl> <t55p9b$2sv$1@dont-email.me>
<0-6dnR8EDPCYHuv_nZ2dnUU7-afNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="45224"; posting-host="YN2ulY6LKp1eoOUw2OJ8ig.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-US
View all headers
On 5/7/2022 7:32 AM, Robert Heller wrote:

The only other issue is source code readablity.  *Sometimes* you end up with
either a really long line (which does not "fit" on your screen, unless you
have an insanely large edit windows and/or are using a really small font), or
an insanely large number of continue lines (and possibly really large
indenting).  Sometime breaking up a large and complex expression into
subexpressions results in code that is easier to read and understand (and in
some cases easier to debug).

                                                                                                                 


Cecil:

I totally agree with Robert, especially with debugging.

I will often  go even further and create more specific temporary variables, since it often results in more self-explanatory code:

set filledDict [fillSwapDict]
set mergedDict [mergeSwapDict ${filledDict} ${mergeList}]
set swapList [sortedList ${mergedDict}]


But the primary reason is that if you create one functional style statement with nested proc/command calls, it becomes quite difficult to tell which of the intermediate steps isn't working correctly when the final result is not as expected.

To that end, with my editor, I can do 4 drag and drop copies of those variables onto a single line, like so:

filledDict mergedDict swapList mergeList

then a triple click on the line selects the 4 and 1 keystroke launches an external editor tool where the 4 variables are sent to a tcl program and returned with this text to replace the 4:

puts "filledDict= |$filledDict| mergedDict= |$mergedDict| ..."

I might then add some newlines to this, or [lsort] them etc.

Given the speed of computers these days, I seldom write more than a few lines of code before I hit my launch key in the editor which will write out the file and launch it as the arg to a tclkit. In about 1 second, I will have a console window in front of me with the output of that puts right there. A [vwait ::ffff] can work like a breakpoint there as well.

I find that this is far easier and quicker than to navigate to the code in some sort of single stepping and break-point setting debugging tool.

And when done, I comment them out, and usually right indent the puts past say column 50 so they're still right there if needed again while not making the real code hard to see.

I tend to build bottom-up and so I develop small functional procedures that I can grow and debug independent of the rest of some program. Later I glue the pieces together after I know they are all working correctly.

Hope this helps.




Subject: Re: How to call procs that use each-others data
From: mango
Newsgroups: comp.lang.tcl
Date: Sun, 8 May 2022 01:21 UTC
References: 1 2 3 4
X-Received: by 2002:ac8:59d3:0:b0:2f3:d7ee:2b54 with SMTP id f19-20020ac859d3000000b002f3d7ee2b54mr307993qtf.290.1651972917958;
Sat, 07 May 2022 18:21:57 -0700 (PDT)
X-Received: by 2002:a4a:b912:0:b0:33a:4543:8608 with SMTP id
x18-20020a4ab912000000b0033a45438608mr3507153ooo.94.1651972917611; Sat, 07
May 2022 18:21:57 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!peer03.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.tcl
Date: Sat, 7 May 2022 18:21:57 -0700 (PDT)
In-Reply-To: <t56b4i$1c58$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=24.176.163.173; posting-account=ZFot6woAAABKx26r18WnGS2aDcK8wnRB
NNTP-Posting-Host: 24.176.163.173
References: <877d6yhtm2.fsf@munus.decebal.nl> <t55p9b$2sv$1@dont-email.me>
<0-6dnR8EDPCYHuv_nZ2dnUU7-afNnZ2d@giganews.com> <t56b4i$1c58$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f8bba070-d9ec-40ca-b747-c02334331a06n@googlegroups.com>
Subject: Re: How to call procs that use each-others data
From: amango...@modelrealization.com (mango)
Injection-Date: Sun, 08 May 2022 01:21:57 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 1550
View all headers
This is Tcl. If you don't like the way it looks, create commands to make it look the way you want. Perhaps the wiki page on pipeline programming has some ideas of one way to deal with deeply nested commands.
https://wiki.tcl-lang.org/page/Pipeline+programming


Subject: Re: How to call procs that use each-others data
From: apn
Newsgroups: comp.lang.tcl
Organization: A noiseless patient Spider
Date: Sun, 8 May 2022 05:56 UTC
References: 1 2 3
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: palm...@yahoo.com (apn)
Newsgroups: comp.lang.tcl
Subject: Re: How to call procs that use each-others data
Date: Sun, 8 May 2022 11:26:11 +0530
Organization: A noiseless patient Spider
Lines: 32
Message-ID: <t57m24$eim$1@dont-email.me>
References: <877d6yhtm2.fsf@munus.decebal.nl> <t55p9b$2sv$1@dont-email.me>
<0-6dnR8EDPCYHuv_nZ2dnUU7-afNnZ2d@giganews.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 8 May 2022 05:56:20 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6f5229fd4079b707d56d67601e49eed0";
logging-data="14934"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19OfCPIzXv00sh+5cQ1AAtN"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.1
Cancel-Lock: sha1:tCvKnwHQHtshsYB6b2xdt42e6UU=
In-Reply-To: <0-6dnR8EDPCYHuv_nZ2dnUU7-afNnZ2d@giganews.com>
Content-Language: en-US
View all headers
On 5/7/2022 8:02 PM, Robert Heller wrote:
The only other issue is source code readablity.  *Sometimes* you end up with
either a really long line (which does not "fit" on your screen, unless you
have an insanely large edit windows and/or are using a really small font), or
an insanely large number of continue lines (and possibly really large
indenting).  Sometime breaking up a large and complex expression into
subexpressions results in code that is easier to read and understand (and in
some cases easier to debug).


While I agree with the above in terms of readability, note that temporary variables can have an significant impact on performance when dealing with even moderately large data. It's not the temporary variable itself but rather Tcl's reference counting and COW implementation means that the additional variable reference does not allow Tcl's in-place modification optimization. Consider for example,

% proc p {} {lrepeat 10000 x}
% timerate -calibrate p; # Tell timerate to ignore overhead of p - not relevant
46.01236794640557 µs/#-overhead 48.2837 µs/# 40428 # 20710.9 #/sec
% timerate {linsert [p] end x}
4.052869 µs/# 19974 # 246738 #/sec 80.952 net-ms
% timerate {set l [p]; linsert $l end x}
59.1994 µs/# 9505 # 16892.1 #/sec 562.690 net-ms

The temp version is slower by an order of magnitude. Of course, this is only true when the value returned by the procedure does not have another reference elsewhere in which case the additional temp reference will not matter. It's just another consideration to keep in mind.

/Ashok


1
rocksolid light 0.7.2
clearneti2ptor