DEV Community: Russell Standish

Tramp mode not working on emacs 26

Russell Standish — Tue, 18 Sep 2018 23:32:51 +0000

On a recent upgrade to emacs, I discovered that remote editing of files via tramp stopped working. This bugged me a lot, as I use it a lot. After much Googling (much), I came across a workaround using sshfs, which allows mounting a remote ssh connection as an fuse mount point.

But the real reason why tramp stopped working is that now an extra “method” parameter is required in the tramp string, eg

^X^F /ssh:remote:file

You can abbreviate ssh to ‘-‘ if you have not changed the defaults too much.

A nice additional feature is the su and sudo methods, eg

^X^F /sudo:/etc/passwd

See What’s new in emacs 26.1 (search for “tramp”).

Making the web great again

Russell Standish — Sat, 03 Feb 2018 04:37:57 +0000

After a number of years getting increasingly frustrated at how slow websites were on my phone, I finally bit the bullet and disabled Javascript.

I mostly use my phone to read news websites/aggregator such as slashdot, which are text heavy. Javascript really only serves the useless function of serving ads, which I don’t read. I really only kept Javascript on because many sites do not work properly without it.

When I open up slashdot with Javascript disabled, I get the message:

It looks like your browser doesn't support Javascript or it is disabled. Please use the desktop site instead.

The link to the desktop site just takes you back to the same address, but in the web browser (using just the standard Android browser, as Chrome is rather heavy weight), there is the option “Desktop view”. Setting this now takes one to the desktop version of the Slashdot website. And apart from having to zoom in a bit to be able to read the text, load times are, well, blisteringly fast. Pages load in seconds, rather than minutes. And no more browser crashes. Bliss!!!!

So I’m going all retro, and reading the web like its 1996. And it is so much better!

Cross-compiling openSUSE build service projects

Russell Standish — Tue, 24 Oct 2017 03:33:21 +0000

I recently needed to debug one of my OBS projects that was failing on the ARM architecture. Unfortunately, my only ARM computer (a Raspberry Pi) was of a too-old architecture to run the OBS toolset directly – the Raspberry was armv6l, and I needed armv7l.

After poking around a lot to figure out how to run OBS as a cross compiler, I eventually had success. These are my notes, which refer to doing this on an OpenSUSE Tumbleweed system on a 64 bit Intel CPU.

Install the emulator

zypper install qemu zypper install build-initvm-x86-64
Enable binfmt support for ARM (allows the running of ARM executable on x86_64 CPUs)

cat >/etc/binfmt.d/arm.conf <<EOF :arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00: \xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff :/usr/bin/qemu-arm-binfmt:P :armeb:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x2 8:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\x ff:/usr/bin/qemu-armeb-binfmt:P EOF

restart the binfmt service

systemctl restart systemd-binfmt

run osc build using:

osc build --alternative-project=openSUSE:Factory:ARM standard armv7l ecolab.spec

This will fail, because it can’t run the ARM executables.

copy the qemu-arm-binfmt executable into the build root

cp /usr/bin/qemu-arm-binfmt /var/tmp/build-root/standard-armv7l/usr/bin

rerun the osc build command above. It will complain that the built root is corrupt. Do not clean the build root, but just type continue.

How to build a Macintosh executable that will run on older versions of MacOSX.

Russell Standish — Mon, 13 Mar 2017 06:30:26 +0000

This took me a good day of drilling into MacOSX, with a paucity of appropriate advice on the internet, which is why I’m writing this post.

-mmacosx-version-min compiler flag

The first hint is to use the -mmacosx-version-min compiler flag, which takes values like 10.9 (for Mavericks) or 10.12 (for Sierra). If you are compiling everything from self-contained source code, it suffices to add this compiler flag to your CFLAGS variable, and build away. I discovered by experimentation that Mavericks was about the earliest OSX that support the C++11 standard library.

Checking the minimum version of an executable or library

Use otool -l executable or library and then look for the tag LC_VERSION_MIN_MACOSX

MACOSX_DEPLOYMENT_TARGET environment variable

If you don’t specify the above compiler flag, then the clang compiler will examine the value of the MACOSX_DEPLOYMENT_TARGET environment variable, and use that the target of the compiler. This is useful as a way of setting the deployment target without editing a bunch of files (say you’re compiling a bunch of 3rd party libraries).

If the environment variable not set, then the current OSX release version is used.

MacPorts

The problem with MacPorts is that it overrides the MACOSX_DEPLOYMENT_TARGET and sets it to your current machine’s value.

After a lot of browsing of the TCL scripts that MacPorts used, I found that you can add it as a configuration option to /opt/local/etc/macports/macports.conf

macosx\_deployment\_target 10.9 buildfromsource always

The second option is required to prevent macports downloading prebuilt binary packages.

Final tip is if you have already built some packages before setting the above options, then you can rebuild the ports via

port upgrade --force installed

Saying goodbye to Aegis

Russell Standish — Mon, 20 Jun 2016 02:16:39 +0000

After nearly 16 years, I am now saying a long farewell the the Aegis source code management system (http://aegis.sf.net). Aegis was, in its day, years ahead of its time. But now, with Aegis’s author dead, and only a handful of stalwarts promoting and maintaining Aegis, it is time to look for a replacement. After now more than 18 months of using git and github in anger, I think I finally have have an SCM that is up to the job. On the plus side, Github’s enormous developer community, and fork/pull request model means that people are more likely to contribute. Whilst Aegis has something similar, the reality is very few people will bother to download and install Aegis, so you’re left implementing clunky workflows combining multiple SCMs. More than once, the heterogenous repositories lead to code regressions.

The biggest hurdle was how to handle continuous integration, a feature Aegis had from its inception. After a considerable learning curve, I found a solution in terms of TravisCI, which integrates quite nicely with Github. Then I needed something to replace the versioning workflow I had with Aegis. After studying Gitflow, I realised it was pretty close to what I was doing with Aegis, so I have implemented a versioning workflow using a script “makeRelease.sh” that uses the git tag feature to add version numbers, and added a dist target to the Makefile to create clean tarballs of a particular version.

I’m changing things slightly, though. Whereas Aegis branch numbers bear no relation to delta numbers, so branch ecolab.5.32 is actually incremental work on top of ecolab release 5.D29, with my new workflow, branches and deltas will be identical. Release 5.32.1 will be an incremental beta release on ecolab.5.32. Also to indicate that the new system is in place, Aegis’s delta numberings (D in final place) are gone, and versions will be purely numeric.

You can check out the new stuff in the github repositories, https://github.com/highperformancecoder/minsky and https://github.com/highperformancecoder/ecolab.

Living la vida Hackintosh

Russell Standish — Tue, 04 Aug 2015 04:47:27 +0000

Like many, I make a living from open source software development, which I develop on Linux, but then build on Windows and Macintosh. I do have a Mac, a rather cute Mac mini, which is a cost effective way of owning the platform, however it does have a couple of disadvantages:

I need to test my software on a minimally installed user machine, not my developer machine, to ensure I have bundled all the necessary dynamic libraries required for my software to run.
I need to build a 32 bit version of the software for maximum compatibility, whereas my Mac mini is 64 bits
I’d like to have my Macintosh environment with me when travelling, without having to throw the mac mini in my suitcase, along with montor, keyboard etc.

Yes, I know, I could buy a Mac laptop, but I don’t particularly like MacOS for my development environment, so it would still be an extra piece of hardware to throw into the suitcase.

The answer to all of these questions is to load MacOSX onto a Virtual Machine, such as Oracle’s Virtual Box, available as Freeware. Initially, I loaded the MacOSX Snow Leopard distribution provided with my Mac Mini into Virtual Box. This worked on some versions of Virtual Box, but not others, so I was constantly having to ignore the pleading to upgrade Virtual Box. Then I discovered I could run the Vbox image on my main Linux computer, provided I didn’t need to boot it, as MacOSX checks that it is running on genuine hardware at boot time only. This was a great liberation – I could now do the Macintosh portioon of my work from the comfort of my linux workstation.

Then, unfortunately, upgrades happened – both the Mac Mini to Yosemite, and my Linux machine to OpenSUSE 13. With the upgrades, Virtual Box also neeeded to be upgraded, with the result that the VMs would only run on the Mac Mini. Unhappy day.

But now I have discovered the iBoot tool from Tony Mac http://www.tonymacx86.com. This great tool allows one to install a “Hackintosh”, Macintosh operating system running on a virtual machine anywhere – exactly what I need. Whilst Apple seem to take a dim view towards people running their software on virtual machines – really that is exactly what I need to do, and all other alternatives don’t cut the mustard.

To get iBoot to work took a little bit of getting used. The most important points were:

Ensure EFI boot is disabled. Virtual Box will enable it by default if you tell it you’re loading MacOSX.
Other settings to be selected are PA/NX, VT-x/AMD-V and Nested Paging
Under display, select 3D acceleration, and about 20MB of video memory
Make sure the SATA type is AHCI
The other item that really tripped me up was getting the correct version of iBoot. Initially, I downloaded iBoot-3.3.0, which did not work. What I had to do was consult my processor information in /proc/cpuinfo, which told me:

Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz

Then I looked up Intel chips on Wikipedia, and found that chip’s model number on the “Haswell” page. So I needed to download iBoot-Haswell-1.0.1, which did the trick.

With the iBoot.iso file, put it into your virtual DVD drive, and boot up your virtual machine. If you already have MacOSX installed in your VM, you can use the right arrow key to select it and boot it. Since that is the situation I found myself in, that is what I did. However, if you don’t, you just replace the iBoot.iso image with a MacOSX install disk, and boot that instead.

That’s it. I’m now in the processing of cloning one of my VMs and upgrading it to Yosemite! Wish me luck.

Regression test coverage analysis in TCL

Russell Standish — Tue, 25 Nov 2014 05:38:09 +0000

If you’re like me, you like having lots of regression tests to keep you covered from making stupid mistakes when hacking up some complicated piece of code. Whilst code coverage tools exist for the major development enviroments, one major blind spot is how do do coverage analysis of TCL, which becomes a problem when your application (eg Minsky) starts to sport a significant amount of application logic in TCL.

A quick Google indicated that you could buy into the Active TCL way of doing things (not so useful for me), or use and application called Nagelfar. Unfortunately, Nagelfar really assumes you are coding in a standard environment, such as wish or tclsh, not in an application scripting environment such as Minsky or EcoLab. Then the realisation I could do it fairly simply in TCL. Well I did have a few false turns which took its time, but I found I could attach a command to fire on every step executed in TCL. Then I peek into the immediately enclosing stack frame to look at details such as which line I’m executing, and save these to a database. Since I’m doing this in the EcoLab environment, I make use of the cachedDBM class to accumulate executaion counts as their found. Finally, I write a C++ program that reads in a TCL file, identifies which proc I’m in and checks whether an entry for the proc, or for the file line number is in the database, and produces output not unlike gcov, with ### indicating a line that wasn’t executed.

The C++ code is called tcl-cov, and is currently located in Minsky’s test directory, although I’m considering moving it to the ecolab utilities directory.

The TCL code to be added to the main application? Here is is:

proc attachTraceProc {namesp} {
    foreach p [info commands $namesp*] {
        if {$p ne "::traceProc"} {
            trace add execution $p enterstep traceProc
        }
    }
    # recursively process child namespaces
    foreach n [namespace children $namesp] {
        attachTraceProc ${n}::
    }
}`

# check whether coverage analysis is required  
if [info exists env(MINSKY\_COV)] {  
# trace add execution proc leave enableTraceProc  
 proc traceProc {args} {  
 array set frameInfo [info frame -2]  
 if {$frameInfo(type)=="proc"} {  
 minsky.cov.add $frameInfo(proc) $frameInfo(line)  
 }  
 if {$frameInfo(type)=="source"} {  
 minsky.cov.add $frameInfo(file) $frameInfo(line)  
 }  
 }  
# open coverage database, and set cache size  
 minsky.cov.init $env(MINSKY\_COV) w  
 minsky.cov.max\_elem 10000  
# attach trace execuation to all created procs  
 attachTraceProc ::  
}

The name of the coverage database is passed in via the MINSKY_COV environment variable. minsky.cov.add is a command for adding 1 to the counter for file/line, or proc/line as appropriate. The traceProc command is attached to all defined procs, which requires walking through all namespaces, hence the recursive call into attachTraceProc (which starts in global namespace ::).

That’s it! Enjoy.