Re: Arm Release 1.4.0

[Damian Johnson <atagar1@xxxxxxxxx>]

> Stable download URLs would indeed be useful.

I'll put this and all new releases in a static subdirectory, so here's
the current one:
http://www.atagar.com/arm/resources/static/arm-1.4.0-2.tar.bz2

My plan was to do the next release in a month or so (finishing the
proc enhancement and including a few other bits from the todo) but if
you'd like a release sooner to have a release version with your bsd
compatibility fixes then let me know. Of course, if using one of the
bsdTest tarballs is sufficient then I can just copy one into the
static directory to make sure it doesn't get deleted.

> I would expect messing with LANG or other localization-related
> variables in the arm shell script or in arm itself to be without
> consequences for the user's terminal once arm is stopped.

Patches welcome on this one. I'm not sure of the exact fix you have in
mind nor do I have a repro use case, so if you're sure this can be
done safely then I'd be happy to include it.

> Nope, but I'm also under the impression that they don't
> really matter and that the load is mainly caused by the
> algorithms used in arm itself.

Kinda yes, kinda no. More no I think. I've changed the arm cpu usage
to instead be samplings of '(os.times() results + system call
runtimes) / sampling time'. I'm not sure if this is a more or less
arbitrary measure of the actual cpu time, but this at least takes the
system calls into account which I'm finding to be useful.

The bad news is that the system calls component was just as large as
the arm cpu usage (about 1.2% on arm, 1.0% on netstat/ps calls). This
isn't surprising and matches reports from some users that on devices
with low resources (mobile, old computers, etc) that arm has trouble
running with the connection resolution.

The good news is that the proc enhancements mentioned earlier
practically eliminates the need for system calls (yay!). I'm
suspecting that there will be some low hanging fruit for the baseline
python cpu usage too when refactoring the controller too.

> So far it happened maybe four or five times on both FreeBSD and
> Debian GNU/Linux combined, always when not interacting with arm.
> I haven't found a way to reproduce it, yet.

When you have log file results for a few freezes I'd love to know what
they end with (any commonalities, for instance if there's a specific
system call giving it trouble).

Family is arriving now, so off to visit. Happy holidays! -Damian