Re: q: boolean variable handling policy

On Sat, Mar 29, 2008 at 09:35:54PM -0700, vagrant@freegeek wrote:
> > <vagrantc> i've got to go now.
> you didn't include the part of the conversation where i said i
> didn't have much time right now(or something to that effect),
> but seem to find it important to include my last comment...
> as if it were a response to your last comment. i am hoping that
> was not intentional.

Ouch, sorry -- upon re-reading, didn't catch this reading...
and didn't add subsequent details too.

> > So while this wasn't sorted out online, I'm taking discussion
> > "offline" so that it doesn't demand immediate replies

I quoted "gtg" so that it would be more clear why write the
message to the mailing list when things could be supposedly
sorted out on irc (they basically were since I first understood
that you're *running* out as it happens to me at times :)

--------------------------------------------------------------

> > Got three of them: 
> > 1) whether there is any particular policy on boolean value
> >    handling;
> at some point in the past, i recall that we agreed on
> true/false, y/n and yes/no, and that's what we implemented
> (although i did notice ldm was a little more loosely defined).
> some of this was based on what was historically used for
> booleans in LTSP, and some just on changes that happened when
> ltsp5 came along. 

Maybe time to rehash?  At least on/off is widely used, even if
0/1 might be confusing and not exactly widespread.

> how many booleans do we really need to support? what does it
> really gain us?

Rather "aliases"...  From admin's standpoint, it's good when you
write something "as usual" and it works (the principle of the
least surprise, also deployed in e.g. Ruby and as I've admitted,
in bzr).

Might make sense to look at distros functions dealing with
system-wide booleans (e.g. in RH-like it's /etc/init.d/functions
and whatever parses /etc/sysconfig/* stuff).

> though seemingly small, it does require some additional effort
> to support more potential boolean values, and i do not see how
> it actually improves the situation to add more.

Well, I'd be glad to settle with some policy on that.

The number of aliases isn't crucial to me (too much would be too
bad of course), it's not developer issue but admin's one.

> > 2) whether there's more general one
> >    (README-DEVELOPMENT-POLICY hints there's none fixated)
> we've come to all sorts of informal discussions that haven't
> really been documented, which over time eventually means we
> basically don't have any policy. :)

I guess ;)  But as people come in, it's inevitable (I tend to
think "a policy is a cache of a useful/reusable discussion").

> > 3) and how generally the collaboration is going on here.
> > The latter might require some more bytes...
> generally, what's been going on is people throw out an idea in
> irc (sometimes on the mailing list) and discuss it. we attempt
> to come to agreement on things, or at least grudging
> acceptance. failing that, it seems appropriate for the status
> quo to remain in place. this allows for ideas to percolate on
> the back burner, and frequently someone comes up with something
> better than the original idea, even if it takes longer.

Good, thanks.

> > I'm quite easy with sed -ir on is_yes/is_no but I'd really
> > want to understand the rationale after the unsung pieces of
> > server/doc/CodingStyle.
> you're adding 6 or more additional lines of code, and the only
> thing you're getting is a shorter name for the function, at the
> expense of having multiple ways of doing the exact same thing.

Well I can do two one-liners, even if asked whether it's needed,
too... led's asked whether there's any proper way of aliasing
functions, I don't know one (even wondering why).  But guess
it's not that crucial ("subst'able").

Maybe checking for/sourcing distro-specific "functions.local"
and postponing smaller style discrepancies there might be better
so that new functions could get limited testing before being
generalized?

Reviewing such "micro-forks" might help to see what is the
"habit turbulence" among people and what might be commoditized.

Maybe not.

> additionally, my intuitive feel is that is_yes and is_no sounds
> a little confusing. and while code is not spoken language, it
> almost feels to me like the grammar is somehow... not quite
> right. this is probably very subjective, though.

Well to me these are a bit more legible, but yes, it depends.

As I said before, I'm all for merging what's technically sound,
and working on stylistics and habits together to come up with
something everyone can live with.

> > It is somewhat hard for me to argue on whether
> > !boolean_is_true() is *NOT* equal to boolean_is_false(),
> > because it isn't in my shell scripting practice (it's not
> > that long though, since 1998).
> well, it is not exactly equal, but it is pretty similar. the
> default assumption with the code is that if a value is un-set,
> it is false. for booleans that default to true, it needs to be
> defined somewhere like ltsp_config.

Well, this can be a policy agreed upon not to reiterate.

> > There ain't really booleans in POSIX shell.  So we use
> > strings.  These can be empty (even unset).  This does make a
> > difference.  This is where I consider there's a technical
> > reason to reject a taste, not a code.
> if there was a strong desire and need for boolean_is_false that
> would actually simplify the code, i think it's worth
> considering. although i'd probably still do something like:
> 
>  boolean_is_false(){
>     if [ -z "$1" ] || ! boolean_is_true "$1" ; then
>         return 0
>     fi
>     return 1
>  }
> 
> rather than spelling out all the possible values for false.

The spelling is a test for value explicitly meaning "yep" or
"nope", not "maybe" or "zzz".  Might make no reason if all the
defaults are spelled already; a question of whether defaults or
actual code determine the final behaviour:

- when defaults should have final say, that's nice since these
  can be gathered in one default config file;
- when code should have final say, there's less hassle keeping
  the defaults file up-to-date.

> but i think best to leave unimplemented until it is actually
> needed.

Seems I'll have a closer look (at the code, not diffs).
For the year, managed to stay away from it (just because two
proper hands and single-tasking are much more efficient than
those two hands and another two already heavily multitasked).
So far this resulted in working packages which only had to be
quickly integrated into distro images.  OK.

> > I'm thankful to Vagrant for all the patience and help he's
> > done to me, but now I frankly don't understand where the
> > "taste" and "technical reason" border is here.
> well, i was expecting to merge patches needed to get ALTLinux
> into upstream, and mixed in with all the ALTLinux stuff was
> unrelated changes.

Yeah, it's the "git stash" case -- seeing something and doing it
immediately.  In fact, I've demanded that *no cleanups* or
questionable changes to common part are done until the specifics
are committed, but we didn't manage to avoid a couple cases as 
you can see. (the BOOTPARAM one seems to be not that
controversial, eh?)

> i was pressed for time, and said as much, and probably
> shouldn't have put any time into it. instead, i decided to try
> and give what feedback i could with a quick glance at it.

Thanks, Vagrant.  I don't have any time-based demand that you
(or anyone here) does something *immediately* or *till monday*.
Simply not applicable.

> i understand that folks are new to bzr, and that bzr has some
> unpleasant limitations with regard to cherry-picking, but in
> the end it's harder to merge *just* the ALTLinux stuff because
> of intermingling unecessary changes.

Yup.

--------------------------------------------------------------

> > I'm all for making LTSP scripts *beautiful*, currently not
> > being even "good" on that scale.  
> i don't really see this as a constructive comment. you're
> calling the code ugly

Err...  I'd probably have much harder time finding code to call
"ugly" in current trunk than it was with 4.2.  But seems there's
enough cleanup to be done still, even by my shell scripting
standards (being quite low compared to the examples referred to).

E.g. the piece you didn't defend is "broken", even if not "ugly".

> without really defining what qualities you find beautiful or
> good.

The former's very personal of course, but the latter includes
"robust", "consistent" and "readable".

> the examples below don't really make it any clearer.

I hoped they would.  Okay, then let's get back to reasonable
cleanups and continue on "good+" another day with proper mood
and some spare time to wa^H^Hinvest in sharing shell habits? ;)

> > (actually, LTSP4.2's startx made me crawl the wall and not
> > look into it for three more months until could do it again
> and i think the recent changes to the ltsp5 xdmcp (formerly
> startx) screen script are a *huge* improvement over that.

All in all, we decided to spend more time cleaning up with you
even if just dropping what hurt would be so much simpler.

It's just that reasonable free software development isn't going
on that way.

> > and this one by Solar Designer (Openwall Project) and
> > Dmitry Levin (ALT Linux, Openwall Project):
> > http://tinyurl.com/2z7h8b
> > I think it might be a honor to see LTSP scripts at that level 
> > of clarity, modularity, reliability and security as Owl ones.
> hm. i really don't see any sort of universal clarity or
> understand what you mean by reliability there.

Well, former startx was quite sloppy code relying very much on
things without checking them first -- e.g. that something to put
as "X -vt" argument would be a number.

So reliability is about corner cases (when one thinks `tty` is
always "/dev/tty*" and other doesn't presume anything regarding
the output but rather checks and if needed, falls back or exits
with a meaningful error message).

> it really just looks like stylistic differences to me, and i'm
> not particularly fond of the style. too much squiggle :)

I haven't graduated my current style yet too. :)

PS: for those who got here but not there: control(8) is ~4k of
shell scripts implementing permissions/configuration persistence
over binary package upgrades, saving the state of the old build
(RPM %preun) and restoring it for the new one (RPM %post).

-- 
 ---- WBR, Michael Shigorin <mike-u2l5PoMzF/[email protected]>
  ------ Linux.Kiev http://www.linux.kiev.ua/

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_____________________________________________________________________
Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-developer
For additional LTSP help,   try #ltsp channel on irc.freenode.net