> 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
