What's the difference
between cascaded IFs
if( cond1 ) {
...
} elsif( cond2 ) {
...
} else {
...
}
and a nested IF in the ELSE part:
if( cond1 ) {
} else {
if( cond2 ) {
...
} else {
...
}
}
?
Not much - except for intent. The latter calls out the ELSE part, the IF cond2 part, emphasizing its separateness. The latter pivots easily to a nested IF in the THEN part. The cascaded IF probably needs to be transformed to the nested IF on the WELSE part, and then pivoted.
Note that the cascaded IF is often used to express a concurrent IF:
if cond1 => ...
:: cond2 => ...
else ...
fi
where the difference is meaningful: in the concurrent IF all of the condityions, cond1 and cond2, are evaluated. Indeed, some argue that there should be no ELSE clause for a concurrent IF.
--
I wonder if there could be some useful difference made between cascaded IF and nested IF in the ELSE part.
Disclaimer
The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.
See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.
See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.
Monday, June 18, 2012
Disabling default-push in Mercurial
(I may have already posted this, but cannot find it at this time.)
On a few occasions I have embarrassed myself by pushing to
the project master repository accidentally, when I meant to push to my rep where I
keep all of my history. (My project requires me to collapse fine grain commits to a much smaller number of coarse gran commits, losing history but keeping the log small. I keep meaning to try mq for this.)
Some folks on stackoverflow *almost* describe how to
do this.
Although the post has a bug, which
I have fixed. I would post the fix to stackoverflow, except it is down right
now, far enough that I am not sure that the below is the correct URL
Here is the my current BKM to
disable default-push:
I've embellished the idea of setting
paths.default-push in ~/.hgrc, making it a little bit more self documenting and
less error-prone - since, as I point out below, setting default-push = . does
not always disable pushing.
in ~/.hgrc
[paths]
# my main
project master repo
project-master
= ...
#DISABLING
IMPLICIT PUSH
# to prevent embarassment from accidentally pushing to
the project master repo
# instead of, in my case, a repo that has fine grain
commits
# that the rest of the team does not want to see in the
project master repo
#default-push =
.
# this works mostly, but NOT if you use hg on your home
directory
# since '.' in ~/.hgrc seems to be interpreted as -R ~
#default-push =
/NONEXISTENT_default-push_--_must_specify_push_target_explicity
# this works ok, but I can clean up the error message
using blanks
# keeping this around because blanks in pathnames
cionfuse many tools
default-push =
/'NONEXISTENT default-push -- must specify push target explicitly'
# this amounts to disabling implicit push targets.
Subscribe to:
Posts (Atom)