hg --close-branch updates tip :-(

Here's something joyful: when you close a branch in Mercurial, e.g. via

  hg update -C branch-to-be-closed
  hg commit --close-branch -m 'branch to be closed'

it becomes the "tip" - the most recent changest.

Many tools confuse "tip" with something like "the tip of the default branch".  And do stuff like checking out or diffstat'ing with tip.

Which probably is not what you want for a closed branch.

Merge node common to several branches

Noticing a pattern:

  hg branch b
  ... edit b ...
  ... test ...
  hg merge -r default
  ... test ...
  hg ci -m 'merged default into b'
  hg update -r default
  hg merge -r b
  ... diff -r default -r b
  ... test ...
  hg ci -m 'merged from branch b into default (after already merged default into branch b, i.e. identical node in both default and branch b'

This seems suboptimal.

It seems to me that instead of creating the same node, wrt content, on two branches, in this case default and b, we could create it once.  And link it in to both branches.

Key: must remember that the node is on both branches, so that afterwards can continue working separately.

I.e. could have updated to the merge node M but be on the default branch.  Or on the b branch.  (Or possibly both?)


It may be common to end a branch at such a merge node.  Perhaps commn enough to be the default.  But not univeral.  

Postfix if with else

Today I found myself writing

   do A if possible, else do B if possible, else error

English that is.

But it caused me to think about Perl's Postfix if

     statement if condition;
  versus
     if( condition ) {code} [[elsif(cond) {code}]* else {code}]
  i.e.

     if( condition ) {code}
     if( condition ) {code} else {code}
     if( condition ) {code} elsif(cond) {code} else {code}
   etc.

Strange to many programming languages, but sometimes makes conde more readable.

I wonder if the posifix if woth else, that I wrote in English, might be worth thinking about.

Syntactically  it is a ternary operator:
      operand1  IF operand2 ELSE operand3

I vaguely recall disjoint operator and function syntax - Algol 68? or was it Algol 60? - ...

Reading email in more than place

Andy Glew

1:55 PM  -  Public

I read email in more than one place, on more than one device, in more than one situation (phone (actually, PDA, but that's a story in itself), tablet, tablet PC by itself, tablet PC docked with 4 big monitors).

I need more dispositions than Archive or Delete.

I need "I can't read this now/here/on this device".

I suppose that it might be useful to be able to say where I could read it - e.g. "defer reading until I'm docked at my desk with 4 external monitors".

But "I can't read read it {in this situation}" is a simple button. It could probably fit on my phone's screen.  Whereas "Defer to another situation" is a multi-valued control, and harder to fit.

Note that "I can't read it in this situation" is NOT the same as "Later".  It may be a superset.  But being re-presented an email to read, later, on the same device that it was too painful to read on in the first place doesn't help.

--

Possibility of learning: record where deferred, and where finally read. Infer. Next time the user presses the "I can't read this {in this situation}" button, you might prompt "Read it at home?"

--

As usual, if already available, I'd like to hear about it.

Error Handling

I sometimes say "the most important part of programming is error handling".

This is not true. Shown by how many programs, how many library routines, how much code, does not handle errors at all.  Successful programs, libraries, code.

How about "one of the hardest parts of programming is error handling"?  That error handling is hard is one of reasons it is so often neglected.

And "one of the biggest barriers to reuse is error handling".

In at least two senses:

(1) You pick up a tool or library, try to use it on what you believe to be correct input - and it craps out with something like a Python stack dump.  Rather than debug, you try something else. Whereas, if an error message had explained what the problem was - if the code had checked format, rather than assuming - then you might have fixed the input.

(2) In a much narrower sense, the error handling conventions a code assumes may get in the way.  E.g. I assume that you throw an exception, you assume that it returns 0. Or -1.  If throwing an exception, what type of exception object do I throw?  (I have given up, and just throw strings.)


Can you tell I am debugging Python today?  I'm not 100% sure, but the Python code I have encountered has made more such assumptions...

The Joel Tests "best tools money can buy" and free software

I like the Joel Test:

http://www.joelonsoftware.com/articles/fog0000000043.html

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

But some of the questions have set me to musing.

E.g. 9 Do you use the best tools money can buy?

One might interpret this as saying that it is unreasonable to use free or Open Source tools, if there are tools that can be bought that are better.

But: better is arguable.  The fact that something is free, or, better, Open Source, greatly reduces many hassles. E.g. "We can't have your work on XYZZY because that would need a new license." 

(By the way: SW can be free but not Open Source, or vice versa.  Best if its free and Open Source.)

Joel's examples talk mainly about being wiling to spend money on fast computers for builds and tests, extra monitors, and disk space wars.  Mentioning a software tool, a bitmap editor, only as an aside.

But let's talk about SW tools, fre and Open Source.

I think here the proper way to consider this question is "Do you have the latest and greatest versions of the free and Open Source tools you are using installed?"

Or rather, since I am not an advocate of gratuitous feature creep: are you ever held back by lack of a feature in the version of free and Open Source tools you have installed --- that is fixed in more recent, stable, versions that will probably run on your machines?

One of the nice things about virtual machines is that more and more you can have N different distros running, so you can pick which tool versions you need.

ISO phone camera app to recognize pills

Historically I've only ever needed to take 1 pill, an antihistamine for my allergies, circa once a day. Ah, youth!

Unfortunately, now I need to take more than one pill, more than once a day. (I'm an overweight guy over 50, with a history of allergies - you guess at what my medical conditions are.) Enough that I want to carry the pills that I will use in the next day or so around in a pill carrier in my pocket.  And I notice that it can be hard to tell the pills apart.

I started off with an old film case, with all the pills in one place. But this became confusing: which pill is which?

I just noticed that there are several different designs, some with compartments by day of the week.

Hmm... I suppose that keeping the pills physically separate may reduce contamination - medication 1 rubbing off on medication 2.

I am sure that there will be some pill carriers that have little codes of letters on the boxes that remind you which pill is which.  But those make the box bigger - and you have to remember which code belongs to which pill.

I tried little slips of paper, or little envelopes.  Haven't found any tiny enough.

So, thinking about this today, I decided to take photographs of the different pills.  So far, all of them have been different enough in color and shape and size and markings that I can tell them apart - so long as I remember what they look like. Or so long as I have a photograph to remind me.

Which causes me to wonder if there is yet a "pill recognizer" app?  An app that can run, on Google Goggles or whatever, and tell you what pills it is looking at? May disambiguate based on what pills it knows you are taking.

---

Who would have thought that there could be technology involved in taking pills?

Different varieties and purposes of pillboxes.

Photographs, pill recognizer apps.

Heck: just realizing that I needed a pill carrier in my pocket, and a "health supplies" bag - was a learning experience.  I can't just keep all of this stuff on a shelf in my medicine cabinet - especially since I need to move it around if I travel.  Bags are not sophisticated technology, but they are ... (By the way, I am looking for a bag that is better suited to carrying bottles and vials.  Currently I'm using an old bookbag from a conference.)

---

Here's another: pill dippers.  Take some pills that you have received, that are easily confused with other pills that you already have.  And dip them in some sort of uniqifying color coating, that dissolves in all the appropriate ways in your moth, esophagus, or stomach.

---

I have often heard that doctors complain about patient non-compliance: patients who don't take their prescriptions.

There is the issue of cost - many folks in the USA may only be able to afford to take a prescription once a week or as needed, when the doctor prescribes it to be taken daily or more often (fortunately I have good health insurance, so that does not apply to me, at this time).

... I wonder if compliance is better in countries with socialized medicine? ...

Anyway, apart from the issue of cost, this pill taking is just plain confusing:

• some have to be taken with food.
• some without
• some at night
• some in the morning

Let alone when your doctor suggests that you take something in a way not described on the Rx label.