From: Mike Frysinger <vapier@gentoo.org>
To: "Michał Górny" <mgorny@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] evar_push/pop helpers
Date: Sun, 2 Jun 2013 11:40:45 -0400 [thread overview]
Message-ID: <201306021140.46386.vapier@gentoo.org> (raw)
In-Reply-To: <20130602103932.759bee82@gentoo.org>
[-- Attachment #1: Type: Text/Plain, Size: 1929 bytes --]
On Sunday 02 June 2013 04:39:32 Michał Górny wrote:
> Dnia 2013-06-02, o godz. 03:29:33 Mike Frysinger napisał(a):
> > On Sunday 02 June 2013 03:16:53 Michał Górny wrote:
> > > Dnia 2013-06-02, o godz. 03:09:31 Mike Frysinger napisał(a):
> > > > On Sunday 02 June 2013 02:51:34 Michał Górny wrote:
> > > > > Dnia 2013-06-01, o godz. 23:03:20 Mike Frysinger napisał(a):
> > > > > > simple set of helpers to save/restore a variable in a limited
> > > > > > section of code
> > > > > >
> > > > > > you can see an example of it in action at the end of the file
> > > > > > where i need to tweak epatch (and no, doing `LC_COLLATE=C set --
> > > > > > ....` does not work).
> > > > >
> > > > > Why the ugly hackery instead of proper 'local' scope?
> > > >
> > > > there's no way to undo the local thus it affects the rest of the
> > > > func. this makes sure the change is actually localized to where it
> > > > is needed.
> > >
> > > By use of global variables and a bunch of additional code and evals.
> >
> > the implementation details of estack_* doesn't matter
>
> It's not beautiful language with proper local scopes, so it *does*
> matter.
then go ahead and propose something different. otherwise you're pointlessly
twisting in the wind.
> > > Also, do you really want the collation to be changed only in this one
> > > place? This looks weird to me.
> >
> > yes, i only want to force it here, because it's the only place where
> > collation matters in the func currently.
>
> So, effectively, changing it once in the beginning of the function
> would be simpler and wouldn't cost anything.
most likely, *today*, yes. in the future, who knows. but since this is the
only place in the func where we need to force a specific sorting, it makes
sense to localize the change to that.
i snipped the rest of your e-mail because it wasn't worth responding to
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-06-02 15:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-02 3:03 [gentoo-dev] evar_push/pop helpers Mike Frysinger
2013-06-02 6:51 ` Michał Górny
2013-06-02 7:09 ` Mike Frysinger
2013-06-02 7:16 ` Michał Górny
2013-06-02 7:29 ` Mike Frysinger
2013-06-02 7:48 ` Tom Wijsman
2013-06-17 5:45 ` Mike Frysinger
2013-06-02 8:39 ` Michał Górny
2013-06-02 15:40 ` Mike Frysinger [this message]
2013-06-02 15:57 ` Andreas K. Huettel
2013-06-02 7:33 ` Tom Wijsman
2013-06-02 17:38 ` [gentoo-dev] " Steven J. Long
2013-06-17 5:42 ` Mike Frysinger
2013-06-17 16:06 ` Mike Frysinger
2013-06-17 5:46 ` [gentoo-dev] " Mike Frysinger
2013-06-17 17:51 ` Greg KH
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=201306021140.46386.vapier@gentoo.org \
--to=vapier@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=mgorny@gentoo.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox