attributes on closing tag (pseudo-XML)

Here's an example of why I like having the ability to place attributes on closing tags in pseudo-XML.  Proper XML only allow attributes on opening tags.

I like using pseudo-XML to structure the output of a test suite. For example:

<test start "foo" >
<test start "bar">
<test "1" passed>
...
</test end "bar" passed=10 failed=0>
<test start "baz">
...
</test end "baz" passed=13 failed=2>
</test end "foo" passed=13 failed=2>

More nicely indented:
<test start "foo" >
    <test start "bar">
        <test "1" passed>
        ...
    </test end "bar" passed=10 failed=0>
    <test start "baz">
    ...
    </test end "baz" passed=13 failed=2>
</test end "foo" passed=13 failed=2>

Anyway, the basic idea is to use pseudo XML ...s to encapsulate test output.

When I translate from pseudo XML to real XML, I can use any of several nice viewers that allow sections to be opened and closed.  E.g. Internet Explorer.

Placing attributes on the closing tag allows me to do such processing in a single pass.  E.g. in a UNIX pipeline:

run-test-suite | collate-results

This is one of the reasons I like being able to place attributes on closing tags: it allows single pass processing.  Often, I am processing some other program's output.

I am fine on eventually converting to standard XML. If necedssary.

---

By the way, I do pseudo-XML, like

<test "name" passed assertions=56>

mainly because I find it more human readable than


<test name=-"name" passed="true" assertions="56">

Human readability counts, since there is not such a plethora of XML tools on the UNIX command line that I never look at the raw text.

ISO composite workspaces

Here's the thing that I really miss in the Mercurial based version control I am currently using; i.e. here is something that CVS used to do really well, that Mercurial makes a pain.

Composite workspaces.

Here's the output of a shell scruipt that goes and looks at 4 of the hg repos/clone/workspaces that I am normally working in:

/home/glew/.
        hg root: /home/glew
/home/glew/mips/.
        hg root: /home/glew/work/work.mips
M LOG
M tools/ag-mips-automation/ag-mips-automation.pl
/home/glew/mips/uarch-perf-sim/psim+stuff/.
        hg root: /home/glew/work/work.mips/uarch-perf-sim/psim+stuff
M psim-extra-stuff/diag_instruction_list_including_undefined_instructions.s
M psim-extra-stuff/parse-rtl.trace-or-ref.trace
/home/glew/mips/rtl/.
        hg root: /home/imp_scratch_perf/glew

It's not too bad - I've only made coordinated changes in two repos.  Sometimes I have made changes in 4 or 5, that are all coordinated in some sense.

Back in my CVS days I could build a composite workspace, and check them all in at the same time, with a single command and checkin message. I could even tag them together.

In Mercurial, I have to go to each repo and check in separately.

Don't say "subrepos": I am already using Mercurial subrepos: psim+stuff is actually a super-repo with 2 subrepos.  Subrepos get part of the way there, but are nowhere as easy and convenient to use as the compositeworkspaces I could set up with CVS.

---

I am reasonably certain that the above excerpt is non sensitive: it's pretty well known that I work for MIPS, on performance simulators, and with RTL.  I sanitized any product names.

---

One big reason to want composite checkins: I work better when I am keeping track in a log.  E.g. ~/LOG -> ~/mips/LOG.

(Let's skip over issues about why UNIX text files are lousy for logs.)

So nearly always I want to check in both my LOG, and my project work, at the same time.  But they are in different repos.

---

I don't make my project work a subrepo of my home directory, ~, or of my company work area under my home directory, ~/work or ~/work/work.mips, because I frequently create new ad-hoc clones, i.e. task branches.  It is a pain to have to edit Mercurial's subrepo file whenever I want an ad-hoc branch.

The nice thing about CVS composite workspaces was that, in some existing workspace, I could just say "cvs -d SOME-OTHER-CVSROOT co repo"  and it just worked.  I.e. connecting an ad hoc subrepo trivial.

In an ideal world, I might want to make the distinction

(1) clone into a new subdirectory of an existing workspace, implicitly making it an ad hoc subrepo for the workspace checking out into

(2) clone, without linking into the enclosing workspace.

---


Almost what I want:

#!/bin/sh



# Script to run Mercurial commands on tghe usual places I run them



for i in  ~/. ~/mips/. ~/mips/uarch-perf-sim/psim+stuff/. ~/mips/rtl/. ~/mips/rtl/current/.

do

 echo $i

 hg --cwd $i root 2>&1 | sed -e 's/^/        hg root: /'

 hg --cwd $i "$@" 2>&1 | sed -e 's/^/        /'

done

although "hgu ci" does not automatically copy checkin message between repos.

Shells tightly bound to directory.

I'm usually the guy who wants more. More features, more flexibility.

My rule is "first implement all reasonable features in an orthogonal manner. Then choose the defaults."

E.g. "provide a command line switch for all ioptions. But then provide a reasonable default, wghich may corresponsd to a set of switches, or a reasonabe set of switches for various default combinations".

---

However, more and more I am thinking that my present usage model might benefot from LESS flexibility in the Unix shell.

I live in emacs.  Many shell windows, each typically named for the directory they are in.

It's a pain when I chdir away from that directory inside such a window.  Occasionally I make errors.

I think that I might like to REMOVE the ability to chdir in such a shell.

(Can do this via aliases? Impefect.)

X font path problems

Can you see what has been annoying me today?

http://oss.sgi.com/LDP/LDP/LG/issue93/yuan.html


I would Google +1 this - if I could figure out how/where my +1 button got to in my Chrome browser.

A perfunctory attempt to google fails to find out how to enable +1 in my browser.  I cannot even remember if +1 works in your browser for sites that don't have their own +1 buttons.

Out of Date Installations

I have wasted so much work time discovering and working around problems that occur on old installations (that I happen to be given to work on) but which are fixed on more recent updates to the system software.

Different device inputs => different passwords, different writing styles

I am probably not the only one to notice that the reasonably secure passwords I type fairly easily on my PC, or even with handwriting recognition on my Windows tablet, can be really painful to type on an iPhone or tablet with onscreen keyboard.

? Will there be a rash of security breakins because smartphone and tablet passwords are too easily broken?  Or at least the subset of easy typing common to both PCs and portable devices?

Today added a new device: a Kindle with keyboard.  Not the latest and greatest, but okay. I love the battery life.  I can access my wiki using the experimental web browser. But the keyboard... sheesh, I force myself to write in a different style. "Zero" rather than "0".

Still, nice when its the only device I have.

(And, yes, I have 2 Android tablets - and I prefer the Kindle. e-Paper. Battery life.)

Good programmers generate good error messages

On the list of my favorite things - NOT:

Programs that respond to user input errors with crashes and stack dumps.  Whether the stackdump is machine code, Perl, Python or whatever...

I could say something like "Good programmers write code that runs with legal input.  Better programmers write code that gives good error messages and/or otherwise handles illegal input better."

Except that it is as that programmers have to write so much error handling code.  Error handling code can grow to take up more space than the real code.

I like language systems that make it easier to write error handling code.  Not necessarily user friendly error messages, but error messages that give the user more of a chance tio figure out what went wrong.

this is one thing I like about C++ exceptions: throw a string-like error message.  When caught, add more info to the string, and throw again, until you get to the outpmost level whedre you die - oer some intermediate level where you can die or otherwise handle.

But I can here the dweebies say "You aren't supposed to throw string or char* exceptions".  True - in an "out-of-memory exception.  But except for that, concatenating or stacking string exception error messages are some of the simplest and best ways to report errors.  So make the exception system handle it.

Similarly, this sounds just like a stack dump.  But it is a user intelligible stack dump - some thought can go in to the strings that get thrown.