From: Roman Perepelitsa <roman.perepelitsa@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Sebastian Gniazdowski <sgniazdowski@gmail.com>,
Zsh Users <zsh-users@zsh.org>
Subject: Re: A way to untie -T vars?
Date: Sat, 21 Jan 2023 18:48:05 +0100 [thread overview]
Message-ID: <CAN=4vMqyG8U=116uVhhEFhs2SSoK3aOb789Ki0iXBzQoAMCucQ@mail.gmail.com> (raw)
In-Reply-To: <CAH+w=7aEqLC4kSSMnvffNdP1XbeXhNTxvBPiL44WJc9YauPHcA@mail.gmail.com>
On Sat, Jan 21, 2023 at 6:32 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Sat, Jan 21, 2023 at 8:38 AM Sebastian Gniazdowski
> <sgniazdowski@gmail.com> wrote:
> >
> > I'm using -U flag to quickly uniquify the scalar, however this method is problematic as the array vars are left over.
>
> Oh, now I see what you mean. You're adding an array with typeset -T
> so that -U will remove duplicates from the scalar, but then you want
> only the scalar to be left at the end -- the array is just a vehicle
> for the "uniqueness" semantics.
>
> Is using a tied array really that much faster than VAR=${(us.:.)VAR} ?
A quick test shows that VAR=${(j.:.)${(us.:.)VAR}} is slightly faster
than `typeset -T VAR _VAR`. I could see it going either way depending
on the value and what exactly is being benchmarked, but the ballpark
performance should be the same.
Roman.
next prev parent reply other threads:[~2023-01-21 17:48 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-21 16:37 Sebastian Gniazdowski
2023-01-21 16:55 ` Bart Schaefer
2023-01-21 17:11 ` Bart Schaefer
2023-01-21 18:52 ` Bart Schaefer
2023-01-21 19:15 ` Roman Perepelitsa
2023-01-22 9:34 ` Pier Paolo Grassi
2023-01-22 9:58 ` Roman Perepelitsa
2023-01-23 2:14 ` Bart Schaefer
2023-01-23 9:47 ` Roman Perepelitsa
2023-01-23 18:27 ` Bart Schaefer
2023-01-23 18:42 ` Mikael Magnusson
2023-01-23 18:43 ` Mikael Magnusson
2023-01-23 19:12 ` Bart Schaefer
2023-01-24 5:45 ` Bart Schaefer
2023-01-24 9:56 ` Roman Perepelitsa
2023-01-24 16:42 ` Bart Schaefer
2023-01-24 16:45 ` Peter Stephenson
2023-01-24 17:40 ` Bart Schaefer
2023-01-24 17:54 ` Roman Perepelitsa
2023-01-24 22:54 ` Bart Schaefer
2023-01-25 14:41 ` Roman Perepelitsa
2023-01-25 22:39 ` Bart Schaefer
2023-01-25 23:48 ` Bart Schaefer
2023-01-26 2:34 ` Bart Schaefer
2023-01-21 17:15 ` Roman Perepelitsa
2023-01-21 17:23 ` Bart Schaefer
2023-01-21 17:31 ` Bart Schaefer
2023-01-21 17:48 ` Roman Perepelitsa [this message]
2023-01-21 17:50 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAN=4vMqyG8U=116uVhhEFhs2SSoK3aOb789Ki0iXBzQoAMCucQ@mail.gmail.com' \
--to=roman.perepelitsa@gmail.com \
--cc=schaefer@brasslantern.com \
--cc=sgniazdowski@gmail.com \
--cc=zsh-users@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).