Aargh!! Out of date systems!!!

Aargh!!! I am sick and tired of working on out of date Linux boxes (that I am not sysadmin ion, that I cannot easily update.)

Today's trivial annoyance:

bash prompt \D{strftime format}

doesn't work on the bash 2.05a.0(2) copyright 2001
installed on the machine I am working on at work
works on a more recent ubuntu ...  4.1.5(1) - copyright 2009

---

Many pf my frioends just maintain their own virtual machines with whatever they depend on
- usually more recent than work - installed.
I must start doing that.

(Last time I tried, I ran out of disk space. Plus, the laptop I can install on is much slower than the workstations I can run on, even though they have old software.)

And then there's the risk that what works in my virtual box won't work on a standard work machine that somebody else is using...


--

These are trivial annoyances.  But finding failures like this wastes a trivial amount of time.  Many times in any given week.

Brackets - XML, and non

I like XML's "brackets":  <longname attributes="attributes"> ... </longname>.

Makes XML much less vulnerable to mismatches like dropping a paren:

<A> <B> <C> <D> ... </D> </B> </A> - the missing &lt/C> can be inferred, and possibly even repaired

(A: (B: (C: (D: .... ) ) )
which closing paren is missing? A, B, C, or D's?

But... sometimes I end up editing XML by hand. (Like on a wiki. (Or in blogger :-( )  And sometimes typing <longname>...</longname> is just too much.

Sometimes I would like the option of having a more compact, but less robust, bracket notation. Like the above mentioned (A: ... )

Or [A: ... ].  Or {B: ...}.  Or (although that latter is hard to tell from XML.)

Consider

<A> (B: {C: [D: ... ] ) </A>

it is still pretty easier to infer that the closing } for {C:  is missing.

Here's a thought: the matchingness of brackets is orthogonal to the actual name of the construct that uses the bracket - in XML parlance, the element.

LISP dialects that use only parens ( and ) exclusively are at one end of the spectrum.

XML, with arbitrary <tag> ... </tag> is at the other end.

And in between, we can have notations that use matching { and }, [ and ], < and >, << and >> - heck, Perl and regexps show that there don't even need to be matching pairs.  ' and '. " and ". Or ‘ and ’, etc.

These could be intermixed, as I have done before.

Indeed, the same entity, the same statement type, could use either bracketing form: &ltA> (A: ... ) </A>

I can imagine tools that translate between these forms.

From XML: &ltA> <A> ... </A> </A>

To strictly lisp-like parens: (A: (A: ... ) )

To forms that employ multiple bracket types for "clarity": (A: {A: ... } )

 ---

I guess that I am using (A: ...) as the compact representation of <A>...</A>.

Q: what about attributes? (A at1="at1" at2="at2" ... : ...)

 ---

There seems to be little lossage here. Except for the lost opportunity to place attributes on closing XML tags, <tag attributes>...</A closing-attributes> --- something that XML does not allow, but which I have supported in my own pseudo-XML dialects.

The HTML Mediawiki passes through

http://en.wikipedia.org/wiki/Help:HTML_in_wikitext

I've ranted before about quotification.

In the link is described the HTML that Mediawiki allows in wiki pages - i.e. the stuff it passes through.

Now, Mediawiki has to have a white list, because it cannot allow arbitrary HTML constructs that a maluser might use, e.g. to inject malware onto wiki pages.  E.g. all, or mostly all, user provided JavaScript must not be allowed. Even basic formatting may not be allowed - e.g. an attacker may be able to use CSS styles creatively to render invisble much text on a page, and thereby creating a phishing page with what remains. Plus the usual issues with tracking links, etc.

More basically, Mediawiki must not allow arbitrary user text. In particular, it must not allow text that would interfere with the HTML that Mediawiki is itself producing.

Now, that last is what my "modest proposal for quotification" specifically attacks: basically add a tag bit to every character that the user inserts, so that it can be distinguished from mediawiki added HTML.

But my "modest proposal" would disallow any user added HTML.  Except for the user added HTML that Mediawiki specifically whitelists, finds, filters, and explicitly removes the tag bit from. And, of course, any bugs in that procedure could lead to security holes...

At least HTML, XML, etc. is easy enough to parse that Mediawiki can filter out anything that isn't on the whitelist.  It does not have to worry TOO MUCH that new syntax will be added that it does not know about.  That's the joy about HTML/XML:  the syntax is (relatively) stable. Extensions can be added by adding new elements and attributes, but existing parsers can recognize such additions, and decide to pass them through or filter them out.

But, it would be nice if Mediawiki (or my own tools) could pass through much, much, more mediawiki.  If instead of having to whitelist specific constructs, they could say "Evaluate all HTML that does not consistute a security risk".  And especially Javascript.

E.g.

• do not evaluate any HTML or JavaScript that opens client files (without special permission)
• do not evaluate any HTML or Javascript that renders existing page elements invisible (except for 
• specially marked stuff.)  I.e. no switching to white on white zero size.

the above is a blacklist.  Or a whitelist:

• only evaluate HTML or JavaScript or CSS that changes colors in a likmited way, or fonts in a limited way, or text size in a limited way...

and so on.

I.e. it would be nice to be able to EVALUATE arbitrary HTML and Javascript, in a sandbox whose capabilities are explicitly circumscribed.

Whitelist the capabilities. 

Not necessarily the text.

Whitelist what the code does.  Not the input.

windows hang, android bitches

I hate it when Windows (7)
stops accepting keyboard input & must be rebooted.

but at least i can bitch about it using my android.

Monitoring histamine like blood glucose

OK, I admit it in public: I have Type 2 diabetes. Controlled by diet.

Regularly monitoring my blood sugar with the home tests made  a great difference:

• I learned how much of my mental state - alertness, fatigue, ability to concentrate - is related to blood sugar. Not all, but a lot.
• I learned that what I thought was low blood sugar, hypoglycemia, is more often than not high blood sugar, hyperglycemia.

Regular tracking has helped me keep to my diet and exercise program.

--

Since tracking my blood sugar has helped so much, I wonder about tracking another health issue for me: allergies.

Since I have started tracking and logging and journaling more diligently, I have noticed what I call a "pre-allergy" pattern: there are days when I definitely have allergies, sniffling, etc. And days when I am definitely clear of allergies.  But there are also days when I don't feel clear of allergies, but when I don't really have allergy syndromes: instead of my nose being blocked (as it is today), I just feel a little tickle.

The funny thing is that these "pre-allergy" days seem to be the days that I am most likely to be irritable and anxious and have trouble concentrating.  Sure, sniffling all day long can be distracting, but I have started feeling relieved when I wake up sniffling, because that usually means I will have a relatively good day at work. Except for the sniffling.  A full blown allergy attack - constant sniffling, eyes sore, skin itching - is distracting, but a mild one can be worked through.

I call these days of low but present allergy symptoms "pre-allergy" because quite often after a few days of "pre-allergy" I will have more intense allergy symptoms.  Although sometimes it is post-allergy as well.  I imagine that it is the "shoulders" of my allergy intensity curve, at levels just below the levels that trigger full allergy attacks.

I wonder if there is a home blood test to measure allergic intensity, i.e. histamine levels?  I can see that there are lab tests for histamine, http://www.integrativepsychiatry.net/histamine_level_whole_blood.html.  But they are heavyweight - go to a lab.  Not something you can measure 2-3 times a day, as I measue my blood sugar.

--

OK, I admit it further: since I started tracking my blood sugar, I have gotten into Quantified Self / Personal Monitoring.

For manual tracking of ...probably too many things... I use KeepTrack on my Samsung Galaxy Player.

But its best when the tracking is done automatically.  E.g. I splureged on the Withings wifi connected scale, http://www.withings.com/en/bodyscale, that uploads my weight to their website every time I weigh myself. Without me having to intervene.

I had hopes for MapMyHike, http://www.mapmyhike.com/.  It's great when it works.  But (1) the GPS on my Samung device is unreliable, at least where I live, an area with deep ravines and canyons and poor sky exposure, and (2) even tolerating the GPS fragility, the MapMyHike app is much slower than most other aps, and often loses data that it has promised to upload later.

I wish there was an aggregator for these cloud based tracking tools.  I would like to see all of my stuff in one place.

etc, etc.

How to search within an Outlook message (hint: can't search in preview pane)

Quick stupid Outlook question:

How to search within an Outlook message?  So that I can jump quickly to the details for XXX in a long message.

I guess I could use Outlook Web Access, and just use ^F in my browser.  .. Well, I could, if OWA was working.

But there must be some way to do this in Outlook itself.

(I suspect that I have asked this question before, and forgotten the answer. For the life of me, can't see a button or menu item. Yes, I'm trying helpﾅ)

...

Ah.

F4 to search

- but it doesn't work in the preview or reading pane. Must open the message in a window of its own.

Google works better than MS help.  When something as basic as this needs a help page on about.com, it must be a UserInterface bug.

http://email.about.com/od/outlooktips/qt/et102904.htm

How to Search Inside a Message in Outlook

Finding messages is easy, accessible and reasonably fast in Outlook, but finding text inside a message I find more challenging. It can be done, though a few detours are involved.

Double-click the message to open it in its own window.
" You cannot search inside a message shown in the Outlook preview pane.

---

Posting this on my blog so that I can find it quickly.

Ron Jeffries on Exceptions => I want the best of both worlds

In an earlier blog entry, I expressed my liking for Andrei Alexandresciu's presentation about the D programming language:

D tries to make the easiest code to write also correct. Handle errors. E.g. throwing exceptions, implicitly caught outside main, usual path for library error reporting.http://blog.andy.glew.ca/2009/07/andrei-alexandrescu-case-for-d-attended.html

I.e. it made me look more favorably than before on exceptions.

Moreover, I have long found that "stacked exceptions" are one of the best ways of providing useful error messages: throw an exception, with a string message explaining the context If caught and handled by the caller, great. If not caught and handled by the caller, but caught somewhere higher up, then that place  can either handle it - or can concatenate more context information. And so on.

So, the exception either gets handled... or you get a useful set of nested, stacked, context error mssages:

• error: file Foo.tmp could not be created, already existed, not overwiteable.
• error: Unpacking archive Foo.tgz
• error: installing software package Foo

I.e. not a useless error message like "could not open file of unrecognizable name".  Not a segmentation fault. And not a buffer overflow.

--

However, what Rin Jeffries wrote in the [XP] mailing list thread "Exceptions are evil?" also appeals:

** Exceptions are not an object oriented mechanism
This is true, they are not OO, although one can implement an exception object.


** In reality, all exceptions are is a mechanism for a multi-level return.
** A method may return its intended value, or an exception.
That's a bit like saying "all a nuclear weapon is is a big firecracker".
It may be true but somehow it misses something.


** To me, calling something and getting an exception is NOT a bug,
** It is using an interface in a (hopefully) documented way.
My concerns about them include:

as used on the ground, the exception handling often occurs multiple levels up, and then it's not handled after all.

Used in a single class or method, the good case and the bad case or separated in the code and even in a single class we often don't really know where the exception came from. Either way the code flow is inherently obfuscated.

Exceptions are often used to pass the buck instead of dealing properly with an unusual condition at the level where it could best be dealt with.

The alternative to exceptions is not "return a flag which you must then check all the time and that is a stupid pain in the ass".

The often better alternative is "return a result which can be interrogated if you wish to try something different or which can be returned blindly to the next guy up the chain, who has the same option". If no one looks at the object and deals with it, it embodies sensible, generally mostly null behavior. This generates code that works better, is easier to read, and discourages laziness.

Once you get into a language style that runs on exception thinking, you kind of have no choice. If you build the software better from the beginning, there is a choice and IMO it is much nicer.

Ron's point is valid. Exceptions are hard to follow.

But, on the other hand, exceptions work when callers buggily do not check for errors returned.

I want the best of both worlds.

This suggests using extended or wrapper types, like the Valid template I have used for years in simulators.  Let's be a bit more explicit, and call it Valid_or_Throw_Exception, although it is possible that there is no need for a difference - in fact, my Valids often throw exceptions if accessed when invalid.   The only big reason for a new type Valid_or_Throw_Exception is that you might want to carry an error message around, in my usual stacked error message approach - whereas my ordinary Valids are stripped down to be as efficient as possible.

Something like, in C++

template Valid_or_Throw_Exception
     : public Wrapper_Type
{
     bool valid = false;
     string errmsg;
public:
     Valid_Valid_or_Throw_Exception(const T& init) : Wrapper_Type(init), valid(true) {}
     Valid_Valid_or_Throw_Exception() : valid(false), errmsg("uninitialized") {}
     Valid_or_Throw_Exception Error(string msg) {
          Valid_or_Throw_Exception ret;
          ret.valid = false;
          ret.errmsg = msg;
          return ret;
      }
private:
     virtual void wrapper_pre_check() {
           if( ! this->valid ) {
                  throw "accessing invalid data item returned as an error by ..." + this->errmsg;
           }
      }
}

Where Wrapper_Type is a template that wraps the base type T, and arranges for all of the methods, etc., of T to be callable on the object that is wrapping.  In this case, first calling wrapper_pre_check().

(I may have played a bit fast and loose here.  My Valids so far have always been performance critical, so I would never have called a virtual function inside them. (Yes, I have measured the performance - that's what I do.) But outside of performance critical code, this seems reasonable.)

This allows values to be returned.  If the values are good, then no worries.  If the values are bad, exceptional, indicating an error, then the caller can still check. Or arrange to pass up the call stack nicely without checking, copy around, etc.

But if somebody tries to use the value without handling a possible error that actually occurred, bang!

But at least then you get the stacked error messages, which are nicer than not.

--

This makes me feel better about my nested exception string messages.  They are useful when you aren't really handling error exceptions, but are just trying to provide the most meaningful error message possible.  More context that "seg fault", but less context than a raw stack dump.  (I have always imagined a clickable interface, so that you could see the outermost, top level, error message, and then click deeper and deeper if necessary.)

My preference is to throw strings.  And only ever to throw strings, or possibly lists of strings in lieu of concatenation.

But this gets in the way of throwing proper exception objects for proper exception based error handling.

This hybrid approach gives both:  well-behaved error handling via the objects returned, and nested exception string contexts when the well-behaved stuff fails.

===

Cool: attempting to reply to the [XP] mailing list via Yahoo's web posting facility gave the error:

Post Message

Post Message Help

PythonError: exception.NameErrot at d8c9c0 

Which is an example both good and bad of exceptions.

It gets better -> cutting and pasting the error message into Blogger resulted in lossage because of angle brackets. That's the sort of "null behavior" that is annoying. I tweaked the error message.

First off, this is a fairly useless error message to provide to the user of a web page. I can only gues that NameError might be associated with my login name. Or maybe not.

Also, hex addresses like d8c9c0 are the sort of thing that make black hats drool. This *might* be a machine address.  It gives me hints as to what addresses I might put into a code packet, if I could find a buffer overflow. This isn't a buffer overflow, but now I can go and look up Python exploits.

So far, Ron wins.  It would be much nicer if the error message was something like

Bad login name: XXXXX

Turned out to be not having a profile. See how useless the Python exception is to the end user?

But... at least the error was checked and thrown. At least this was Python. In C++, it might have been unchecked, and there might have been a buffer overflow that a bad guy could use to break in.

It would be nice to have an appropriate error message. Ron's point about having the good and bad paths together wins: the programmer is much less likely to forget to handle the error if he can see "return[ed] a result which can be interrogated".

But sometimes these errors occur deep, deep in library functions.  Possibly libraries that presently assert. Sometimes changing the library is not an option, no matter how often one chants the XP "courage" mantra.

It's easy to #define assert to throw an exception. (Harder from a signal handler.)  This gets you to Andrei's place.

And the next step is to my nested or stacked error messages:

Post Message

Post Message Help

PythonError:  exception.NameErrot at d8c9c0 
User does not have Yahoo Profile: you must create one beforre possting.
Error trying to Post Message.

Not as good as what somebody following Ron's prescription could do. But better than nothing.

--

By the way, one of the big reasons why I was attracted to exceptions for error handling in C++ is that I found it made writing my own CppUnit equivalent (actually, not equivalent, minimalist) easy, especially when testing existing code that exit'ed or asserted on an error: rather than having to mess with multiple processes in ways that are often not portable, I culd usually #define assert to throw and/or use one of the exit hooks.

I.e. I used exceptions to make the test jig easier in the presence of ill behaved legacy code.  And faster, fast enough to be used regularly - as opposed to forking processes around often very small test cases, which back in 1996, and even still today, produce horrible slowdowns, discouraging the team from using tests.