Andrew Cooke | Contents | Latest | RSS | Previous | Next


Welcome to my blog, which was once a mailing list of the same name and is still generated by mail. Please reply via the "comment" links.

Always interested in offers/projects/new ideas. Eclectic experience in fields like: numerical computing; Python web; Java enterprise; functional languages; GPGPU; SQL databases; etc. Based in Santiago, Chile; telecommute worldwide. CV; email.

Personal Projects

Choochoo Training Diary

Last 100 entries

[Computing] Okular and Postscript in OpenSuse; There's a fix!; [Computing] Fail2Ban on OpenSuse Leap 15.3 (NFTables); [Cycling, Computing] Power Calculation and Brakes; [Hardware, Computing] Amazing Pockit Computer; Bullying; How I Am - 3 Years Post Accident, 8+ Years With MS; Collaboration request; [USA Politics] In America's Uncivil War Republicans Are The Aggressors; [Programming] Selenium and Python; Better Walking Data; [Bike] How Fast Before Walking More Efficient Than Cycling?; [COVID] Coronavirus And Cycling; [Programming] Docker on OpenSuse; Cadence v Speed; [Bike] Gearing For Real Cyclists; [Programming] React plotting - visx; [Programming] React Leaflet; AliExpress Independent Sellers; Applebaum - Twilight of Democracy; [Politics] Back + US Elections; [Programming,Exercise] Simple Timer Script; [News] 2019: The year revolt went global; [Politics] The world's most-surveilled cities; [Bike] Hope Freehub; [Restaurant] Mama Chau's (Chinese, Providencia); [Politics] Brexit Podcast; [Diary] Pneumonia; [Politics] Britain's Reichstag Fire moment; install cairo; [Programming] GCC Sanitizer Flags; [GPU, Programming] Per-Thread Program Counters; My Bike Accident - Looking Back One Year; [Python] Geographic heights are incredibly easy!; [Cooking] Cookie Recipe; Efficient, Simple, Directed Maximisation of Noisy Function; And for argparse; Bash Completion in Python; [Computing] Configuring Github Jekyll Locally; [Maths, Link] The Napkin Project; You can Masquerade in Firewalld; [Bike] Servicing Budget (Spring) Forks; [Crypto] CIA Internet Comms Failure; [Python] Cute Rate Limiting API; [Causality] Judea Pearl Lecture; [Security, Computing] Chinese Hardware Hack Of Supermicro Boards; SQLAlchemy Joined Table Inheritance and Delete Cascade; [Translation] The Club; [Computing] Super Potato Bruh; [Computing] Extending Jupyter; Further HRM Details; [Computing, Bike] Activities in ch2; [Books, Link] Modern Japanese Lit; What ended up there; [Link, Book] Logic Book; Update - Garmin Express / Connect; Garmin Forerunner 35 v 230; [Link, Politics, Internet] Government Trolls; [Link, Politics] Why identity politics benefits the right more than the left; SSH Forwarding; A Specification For Repeating Events; A Fight for the Soul of Science; [Science, Book, Link] Lost In Math; OpenSuse Leap 15 Network Fixes; Update; [Book] Galileo's Middle Finger; [Bike] Chinese Carbon Rims; [Bike] Servicing Shimano XT Front Hub HB-M8010; [Bike] Aliexpress Cycling Tops; [Computing] Change to ssh handling of multiple identities?; [Bike] Endura Hummvee Lite II; [Computing] Marble Based Logic; [Link, Politics] Sanity Check For Nuclear Launch; [Link, Science] Entropy and Life; [Link, Bike] Cheap Cycling Jerseys; [Link, Music] Music To Steal 2017; [Link, Future] Simulated Brain Drives Robot; [Link, Computing] Learned Index Structures; Solo Air Equalization; Update: Higher Pressures; Psychology; [Bike] Exercise And Fuel; Continental Race King 2.2; Removing Lowers; Mnesiacs; [Maths, Link] Dividing By Zero; [Book, Review] Ray Monk - Ludwig Wittgenstein: The Duty Of Genius; [Link, Bike, Computing] Evolving Lacing Patterns; [Jam] Strawberry and Orange Jam; [Chile, Privacy] Biometric Check During Mail Delivery; [Link, Chile, Spanish] Article on the Chilean Drought; [Bike] Extended Gear Ratios, Shimano XT M8000 (24/36 Chainring); [Link, Politics, USA] The Future Of American Democracy; Mass Hysteria; [Review, Books, Links] Kazuo Ishiguro - Never Let Me Go; [Link, Books] David Mitchell's Favourite Japanese Fiction; [Link, Bike] Rear Suspension Geometry; [Link, Cycling, Art] Strava Artwork; [Link, Computing] Useful gcc flags; [Link] Voynich Manuscript Decoded; [Bike] Notes on Servicing Suspension Forks

© 2006-2017 Andrew Cooke (site) / post authors (content).

Using Mercurial on OpenSuse 11.1

From: "andrew cooke" <andrew@...>

Date: Sun, 26 Apr 2009 19:52:48 -0400 (CLT)

Two separate pieces of information here - how to use Mercurial in a
"centralised" way, and how to get things working nicely in OpenSuse.

First, the "centralised" part.  It wasn't clear to me at first how I would
actually use Hg.  I am used to having a central svn repo that is backed
up, and that I use as a reference from various computers.  I still wanted
that with Hg, but it wasn't clear how to arrange things.

What I ended up doing (and I am still not sure this is correct, although
it seems OK) is the following:

 - create a system group "hg"
 - create a system user "hg" whose empty home directory is /srv/hg
   and whose default group is "hg"
 - create a directory under /srv/hg called repos
 - in that directory, as the hg user, import code from svn
   (I had everything in a single svn repo but am separating things
   out with hg, so there's a single repo for lepl at the moment).
   (this uses "hg convert" - the command I ran was
   hg convert svn:// \
     --config convert.svn.trunk=lepl/trunk \
     --config convert.svn.branches=lepl
   which let me import versions at the same level as trunk)

That places a lepl repo (I had to rename it from whatever it was called by
default) in /srv/hg/repos

Next I wanted to be able to look at it via the web.  There's a fairly
detailed explanation at but it
places the repo in srv/www for some reason.  That's not necessary (as far
as I can tell so far - I'll post again to this thread if I find out

So I adapted the instructions at that link and did the following:

 - downloaded the entire hg codebase (I think) into a temp directory
   using the command
   hg clone
 - that was the only way I could get hold of hgwebdir.cgi (is it
   just me or do the links in the instructions not work for everyone?)
 - create the directory /srv/www/htdocs/hg
 - put the hgwebdir.cgi in that directory
 - add hgweb.config with contents:

/srv/hg/repos = /srv/hg/repos

style = gitweb

 - make sure permissions, ownership etc were OK (ie same as other
   projects in /srv/www - use wwwrun/www)
 - create the file hg.conf in /etc/apache2/conf.d as in the
   instructions above
 - restart apache

That gave me a very ugly site at http://localhost/hg

I should also have mentioned that I installed mercurial from Yast before
all this.

I spent some time trying to fathom why my site was so much uglier than
others on the web before realising that opensuse's defauly mercurial
install is rather old (1.0.2).  You can install a much more recent version
from the build service at - just type
"mercurial" in the box and click away.

Once that was done, I got the nice web site with trainline graphs that
showed the different release versions.  Nice :o)


Writing to Mercurial

From: "andrew cooke" <andrew@...>

Date: Mon, 27 Apr 2009 18:21:31 -0400 (CLT)

The above all seems OK.  Today I looked at writing (pushing) back to the
main repo.

Locally (and I assume via ssh) you can do this by writing to the
repository directly (ie the directory /srv/hg/repos/lepl).  All that was
necessary (as far as I can remember) to do this was to make sure that I
was a member of the hg group (log out and in again) and that the group has
write permissions.

Getting things working by HTTP was a little more tricky.  I added/modified
the following files:

/srv/hg/repos/lepl/.hg/hgrc contains:

allow_push = andrew

/etc/apache2/conf.d/hg.conf contains:

ScriptAliasMatch        ^/hg(.*)        /srv/www/htdocs/hg/hgwebdir.cgi$1
<Directory /srv/www/htdocs/hg>
  Options ExecCGI FollowSymLinks
  AllowOverride None

  AuthType Digest
  AuthName "svn"
  AuthUserFile "/srv/www/htdocs/hg/.htdigest"
  <Limit POST PUT>
    Require valid-user


The file /srv/www/htdocs/hg/.htdigest was generated with htdigest2 (see
man pages - the "realm" is "svn" as AuthName above).


groups = hg

Some tips: to resolve problems start with the simplest first, so get local
push to a file working.  Then add "GET" to the Limit above and set things
up so that you can read the web page in a browser after entering the
correct password.  Next try push to a http url (add push_ssl = false to
the appropriate hgrc) and use ngrep to sniff the response (which contains
a more detailed error message than appears elsewhere!).  Finally, test
writing to https.  This helps avoid mis-attributing errors (for a long
time I thought apache was complaining about trusted users, but it was
mercurial, and the groups=hg in the global hgrc fixed that).

With the above I now have network (except that the firewall blocks
external access) read access while network write is limited to myself.

I've also done several merges without breaking anything, as far as I can
tell.  In the process I've come to the conclusion that named branches
aren't that great.  Instead, branches are best treated more like temporary
things that you create when needed.  For releases, tagging is enough (if I
ever need to do major development on an old release I think I will clone a
new repository instead of using branches).


PS And don't forget to enable mod_auth (which is easiest to do through Yast)

Add wwwrun to hg group

From: "andrew cooke" <andrew@...>

Date: Mon, 27 Apr 2009 18:46:22 -0400 (CLT)

Forgot to mention this, but pushing via http means that wwwrun must be a
member of the hg group too.


With Eclipse

From: "andrew cooke" <andrew@...>

Date: Mon, 27 Apr 2009 21:41:00 -0400 (CLT)

Using Eclipse works fine too - I used the standard(?) extension
(MercurialEclipse) and it works just fine.  From my laptop I can clone a
version from the HTTP server, modify and commit locally, then push back to
the server later.

So I can duplicate my old svn-based workflow, but I also have the entire
repo locally on the laptop when travelling, and can commit in small chunks
(this is more important in Mercurial than Subversion, because merges are
hard to do in smaller-than-a-commit pieces; you cannot pick changes for a
particular file, but instead deal with "changesets").

Anyway, must rush - burning a CDROM to try out Mandriva :o)


Trying to Explain why Mercurial is Good

From: "andrew cooke" <andrew@...>

Date: Wed, 29 Apr 2009 08:57:15 -0400 (CLT)

I am really enjoying (well, in relative terms - I can't honestly say that
it is one of the great pleasures of my life) using Mercurial.  And since a
month ago I couldn't see the point of DVCS I think I should explain why.

Unfortunately, that's not so easy.  Just as svn was generally more solid
and useful than cvs, so hg is similarly incremental.  For me, all three
will do the job - being distributed is not a critical part of my
development.  So there's no huge argument in favour of Mercurial, but if
you've switched from cvs to svn and been pleasantly surprised, then I
think you'll find the same experience moving from svn to hg.

So, if there are no big wins, what are the small wins?

First, it *is* distributed.  So if I had been using it three weeks ago,
when I was visiting my parents in the UK, patching a bug in LEPL would
have been much easier.  You always have the full revision tree (well,
graph) available, locally.

Second, because it's local and fast, you can commit more often.  Actually
this is also a negative - you really *have* to commit more often, because
you can't go back and cherry-pick changes later.  With svn you can select
changes to individual files and merge them across to another branch.  With
hg you have to take the whole commit (there are hacks around this, but
that's the general idea).

Third, because it's local and fast and supports distribution, you can
trivially copy the whole repository just to do an experiment.  I imagine
I'll do this less as I get used to it, but for learning it's great - I can
try to do something several times and, once I get it right, "push" it back
to my main repository.

Fourth, I can still work the way I used to.  Apart from the commit v file
granularity issue, there's nothing stopping me from still having a single,
central server that I back up automatically.

Fifth, it's easy to divide work up into separate chunks by cloning.  This
is nicer than using a branch because you're not immediately making big
changes to the central repo.  You get more leeway to experiment.

Looking at that list, I guess the basic idea is that it gets in the way
less, so you use it more.  It's more flexible, and you can use it more
without making the main repo a confusing mess of branches and tags.  So it
becomes more of a useful tool than a burden.  Which I think is why the
move feels similar to the change from cvs to svn, which also made progress
in that direction.


Comment on this post