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.

Monday, June 18, 2012

Else: what's the difference?

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.


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.