Version controlling VCS metadata

My project .hg/hgrc is growing pretty long.

It needs to be under version control.

Unfortunately, hg does not, refuses to, version metadat such as .hg/hgrc.  Security.  Since .hg/hgrc may contain executable hooks...

Seems to me there should be a better way. E.g. disabling it's executability, although allowing it to be versioned.

Or - since some (but by no means all) such metadata is per repo, and is meaningless in a clone, perhaps there should be a meta-VCS system.  This is fairly natural for me, since i have had my repos nested within each other for decades.

Unfortunately, not so natural for Mercurial.

Symlinks to URLs

http://superuser.com/questions/277186/symlink-to-a-url/384182#384182

As people have explained, although you can create a symlink that links to an URL, it does not accomplish much.  UNIX is not smart enough to look at the link content, recognize it as an URL, and then do something appropriate to it.

Nevertheless, I occasionally do create symlinks to URLs.  Mainly just as documentation - I am used to going to looking at ~/links/* when I forget where, on the filesystem, I have stored something.  It's not much of a stretch to do the same thing for URLs.  However, doing so tends to break consistency checks and other stuff that assumess or requires that symlinks point to valid filesystem locations.

Furthermore, I have made some of my own tools smart enough to recognize that, if they see a symlink where an URL is needed, that they should dereference the symlink and look at its contents.  More and more of my tools treat URLs and paths in the filesystem as interchangeable.  Assuming, of course, that the URL protocol has appropriate methods for reading and writing.

[[Write coalescing]] is the term some GPUs, notably AMD/ATI and Nvidia, use to describe how they, umm, combine or coalesce writes from different N different SIMD threads into a single, or at least fewer than N, accesses. There is also [[read coalescing]], and one can imagine other forms of coalescing, such as atomic fetch-and-op coalescing.

At AFDS11 I (Glew) asked an AMD/ATI GPU architect
"What is the difference between [[write coalescing]] and [[write combining]]?"

He replied that [[write combining]] was an x86 CPU feature that used a [[write combining buffer]],
whereas [[write coalescing]] was a GPU feature that performed the optimization between multiple writes that were occurring simultaneously, not in a buffer.

Hmmm...

Since I (Glew) had a lot to do with x86 write combining
- arguably I invented it on P6, although I was inspired by a long line of work in this area,
most notably the [[NYU Ultracomputer]] [[fetch-and-op]] [[combining network]]
- I am not sure that this distinction is fundamental.

Or, rather, it _is_ useful to distinguish between buffer based implementations and implementations that look at simultaneous accesses.

However, in the original NYU terminology, [[combining]] referred to both:
operations received at the same time by a switch in the [[combining network]],
and operations received at a later time that match an operation buffered in the switch,
awaiting either to be forwarded on,
or a reply.
(I'm not sure which was in the Ultracomputer.)

A single P6 processor only did one store per cycle, so a buffer based implementation that performed [[write combining]] between stores
at different times was the only possibility. Or at least the most useful.
Combining stores from different processors was not done (at least, not inside the processor, and could not legally be done to all UC stores).

The NYU Ultracomputer performed this optimization in a switch for multiple processors,
so combining both simultaneous operations and operations performed at different times
was a possibility.

GPUs do many, many, stores at the same time, in a [[data memory coherent]] manner.
This creates a great opportunity for optimizing simultaneous stores.
Although I would be surprised and disappointed to learn that
GPUs did not combine or coalesce
(a) stores from different cycles in the typically 4 cycle wavefront or warp,
and
(b) stores from different SIMD engines, if they encounter each other on the way to memory.

I conclude therefore that the difference between [[write combining]] and [[write coalescing]] is really one of emphasis.
Indeed, this may be yet another example where my
(Glew's) predilection is to [[create new terms by using adjectives]],
e.g. [[write combining buffer]] or [[buffer-based write combining]]
versus [[simultaneous write combining]] (or the [[AFAIK]] hypiothetical special case [[snoop based write combining]]),
rather than creating gratuitous new terminology,
such as [[write combining]] (implicitly restricted to buffer based)
versus [[write coalescing]] (simultaneous, + ...).

= See Also =

This discussion prompts me to create

* [[a vocabulary of terms for memory operation combining]]

Project structure: code, tests, external depndencies

Say you have a project foo, which I will call .../foo, to emphasize that there is probably a project directory somewhere in the namespace.

.../foo

Where do you put the tests?  It's nice to put them in .../foo/tests, so that when you checkout the project, you get the tests as well:

.../foo/tests

by which I mean


.../foo
    .../foo/tests

or


...
   foo
      tests

but  emphasizing the full context via .../ and .../foo/

It's also good to minimize the external dependencies of .../foo.

But what if the tests have more external dependencies than the non-test part of the project.  Should you increase the external dependencies of the non-test part just to have the tests?

Conversely, should you make it harder to write the tests by forbidding external dependencies in them?  Tests are hard enough to write, and they often depend on extra libraries that the source code per se does not?

More specifically, should you get stuff that has increased external dependencies if you check out .../foo and .../foo/tests comes along for the ride?

If you don't want the extra dependencies in .../foo/tests to come along with .../foo, you might structure them as separate modules, possibly separate in the file space:

.../foo+tests
    .../foo
    .../tests


This works, but it creates extra levels of such "meta-modules": .../foo+tests, .../foo+interactive_tests, .../foo+debugging_tools+tests, etc.

You might structure it as a series of optional modules, all within a single metamodule:

.../foo+stuff
    .../foo
    .../tests
    .../stress-tests

or, rather


.../foo+stuff
    .../foo+stuff/foo
    .../foo+stuff/tests
    .../foo+stuff/stress-tests

and so on.

It's still annoying to have an extra level of indirection, but the purity of the bodily fluids of .../foo is maintained.

Now, of course, it is highly likely that you will have some tests within foo and some that are assoviated with foo, but that foo won't let in:

.../foo+stuff
    .../foo+stuff/foo
        .../foo+stuff/foo/tests
    .../foo+stuff/tests
    .../foo+stuff/stress-tests

This can be confusing, but apart from changing names it may be unavoidable: if a country has immigration control country, you often get refugee camps on the border.  The country may ignore them, but the UNHCR does not.

Some systems allow this "stuff" to be overlays within foo:

.../foo

    .../foo/tests -- optional

    .../foo/stress-tests  -- optional

Perl test brackets with deterministic finalization

I just realized that you can use deterministic finalization in Perl just like C++. Yay!

{
    package Brackets;
    # my first attempt to use determinsitic finalization in Perl;
    sub name {
 my $self = {};
 $self->{name} = shift @_;
 bless $self;
 print "{name}>\n";
 return $self;
    }
    sub DESTROY {
 my $self = shift @_;
 print "{name}>\n";
    }
}

Note that I use my "pseudo-XML" notation:

<TEST START name>
...
</TEST END name>

It's not nice to violate the standard, but IMHO this is a alot easirr to read than

<TEST context="START" name="name">
...
</TEST context="END" name="name">

and readability is a concern - since I plop these things in test output read by my human coworkers. Human coworkers who really don't like XML because it is so ugly. I can readily translate my pseudo XML into real XML, in case I wanted to use any real XML tools. And can do many operations without such translation. Unfortunately, there aren't many real XML tools to be used withot a lot of work :-(. I need to fix up my pseudo-XML UNIX command line tools, suitable fr use in pipezs and so on.

googletalkplugin issues

I started having problems with google talk, specifically the googletalkplugin that I get when clicking on "phone" in gmail. I believe I have had these before. Not sure of old workarounds have all been tried, none so far work. Started off with not being able to hear gtalk dial. Then got messages like "XXX-XXX-XXXX (a phone number) cannot be reached." Uninstalled/reinstalled. Witho rebooting. Running as Asministrator. No joy. Just noticed many googletalkplugin processes running. This is what tickled my memory. A new one starts every time I start Chrome. Doesn't always go away.

Code ordering, want none: perl example

I have several times posted how I find languages without code ordering pleasant, more readable.

E.g.

  let x = y + z
      where z = some log and complicated expressions

Here's an example from writing "shell scripts" - although here I am doing the shell script in Perl: Start off with:

   system("command with some long and complicated command line");

Realize that you want to repeat the command in a pre-announcement of what you are doing, and in an error message: Start off with:

   print "RUNNING: command with some long and complicated command line\n";
   my $exitcode = system("command with some long and complicated command line");
   print "error: exitcode=$exitcode: command with some long and complicated command line\n"
      if there_is_a_problem($exitcode);

Now avoid repetition: Standard way:

   my $cmd = command with some long and complicated command line";
   print "RUNNING: $cmd";
   my $exitcode = system("cmd");
   print "error: exitcode=$exitcode: $cmd\n"
      if there_is_a_problem($exitcode);

In my opinion the non-code ordered way is more readable:

{
   my $cmd;  # maybe some declaration to say it is not ordered?
   print "RUNNING: $cmd";
   my $exitcode = system($cmd = "command with some long and complicated command line");
   print "error: exitcode=$exitcode: $cmd\n"
      if there_is_a_problem($exitcode);
}

I think it is more readable because you see the value set at the point where it matters, where it is used most intensely (the other uses are mild, just prints). Note that I have used a scope.