Drystone walling
"All Derbyshire is full of steep hills and you see neither hedge nor tree but only low drye stone walls"
Celia Fiennes - 1697
Today I got a chance to try my hand at something I've been wanting to have a go at for a long time - drystone walling. For those of you who don't know what this is, it's a technique for building walls using just stone and with absolutely no mortar, hence the name. In Derbyshire the practice dates back to at least 2500 BC, with systematic building starting in the 14th and 15th centuries and carrying all the way through to the 19th century. The Parliamentary Enclosure Act of 1750 saw the building of standardised walls, paid for the landowners wo were claiming the land for their own use. By 1820 most of the existing walls were complete, and since then there has been a gradual decline, with many of the walls falling into disrepair. More recently there has been a resurgence in interest in preserving and maintaining the walls, which form a distinctive feature of the Peak District landscape. The number of professional wallers is beginning to climb both in response to this interest and also because of the availability of government grants for walling work.
The section we were working on was an existing wall that had become derelict, alongside the Pennine Bridleway at Hayfield. The first job was to take down the remnants of the existing wall, laying the stone to one side so we could reuse it. The foundations were OK, so we didn't need to dig right down - when starting a fresh wall the top 6 inches of soil need to be dug out to give a firm footing. Most field walls are 4'6" high and are 2' wide at the base. As the wall rises it gets narrower, the amount is known as the 'batter' of the wall, in our case we were using a ratio of 1:8, so at the top our wall needed to be about a foot wide - we used metal bars at either end of the section with strings between them as a guide, moving the strings up the bars as the wall rose.
The wall is actually made up of several different components. Free-standing walls are double-skinned with each face being built seperately, so they can be thought of almost as two walls leaning against each other. The components of the wall are as follows:
- Footings. These are the largest (and heaviest!) stones and take the entire weight of the wall - there can be between 1 and 2 tons of stone per meter of wall - and my back says that's probably about right!
- Face stones. These make up the two outside faces of the wall, and start off with the largest ones at the bottom. Narrow stones are placed with their long edges into the wall, not along it in order to give the wall strength.
- Hearting. This is small stone used to pack the middle of the wall between the faces. Soil isn't used as it would wash out over time - a well-built wall will last for over 100 years.
- Throughs. These span the entire width of the wall and tie the two faces together. On a 4'6" wall they are about 2' from the ground, spaced about a yard apart along the wall.
- Copestones. Usually semicircular, these fit vertically on top of the wall and again tie the two faces of the wall together.
Here you can see the base of the wall, showing the two faces and the heartings between them.
The wall is a bit higher here and you can see that it is starting to narrow. Although the stone is all irregular, it is considered to be cheating to dress it to shape. The aim is to build in regular horizontal courses (as far as possible), and to overlap the vertical joints in the same way as is done for brick walls.
Here the wall is at full height, with the top being levelled up with small face stones so that the copestones will sit evenly across the wall.
The final stage is to add the vertical copestones that tie the top of the wall together.. Some walls have dressed semicircular copestones of a regular size, but here we are going for the rustic look - actually, we didn't have any dressed stone!
Job done, and I have the aching back and bruised fingernail to prove it! As I said I'd always wanted to have a go at walling, and I was lucky enough to have a fine bright autumn day (and pleasant company to boot!) for my first attempt. Many thanks to Terry for showing me the tricks of the trade, and I can't wait to go back to do a bit more. Hopefully the wall I helped to build today will last considerably longer than I will :-)
Alan in wonDLLand
Yesterday evening I had another poke at the Java wrapper for OziExplorer that I'm sporadically working on, OziExplorer is the GPS mapping application that I use. It's a pretty fat API so I'm gradually chipping away at it. My latest tweak was to add a simple Swing GUI to my test app, but as soon as I did it blew up every time I exited with two rather foreboding messages,
The exception unknown software exception (oxoeedfade) occurred in the application at location 0x7c81eb33 and Runtime error 217 at 0009D54. Google told me that second message was coming from Delphi - OziAPI.dll is generated with Delphi, but didn't shed much light on exactly what was causing the error. Some experimentation revealed that the problem was actually nothing to do with Swing, I could get the same effect by just calling System.exit immediately after calling any of the functions in the Delphi DLL. If I just let the program fall off the end of main the problem didn't happen, which suggested that whatever was going belly up was being caused by something that System.exit was doing, either directly or by indirectly perturbing the ordering of the JVM exit processing.
A bit more googling revealed that other people had hit the same problem and that one workaround was to manually open the DLL with LoadLibrary, find the symbol addresses via GetProcAddress and finally manually free the DLL with FreeLibrary on exit. (For those in the Solaris seats that's the Win32 equivalent of dlopen, dlysm and dlclose). This suggested to me that the problem was something to do with the timing of the DLL initialisation and/or cleanup. In my case I was pulling in the OziAPI DLL via a linker dependency from the JNI DLL, and I was loathe to have to manually pull in OziAPI.dll and look up the symbols just to work around this problem. Some more spelunking through the Microsoft documentation revealed the following interesting snippets:
If you terminate a process by calling TerminateProcess or TerminateJobObject, the DLLs of that process do not receive DLL_PROCESS_DETACH notifications. If you terminate a thread by calling TerminateThread, the DLLs of that thread do not receive DLL_THREAD_DETACH notifications.
The TerminateProcess function is used to unconditionally cause a process to exit. The state of global data maintained by dynamic-link libraries (DLLs) may be compromised if TerminateProcess is used rather than ExitProcess.
I grabbed a copy of strace for NT and traced the execution of my test application, and although I could see calls to TerminateProcess I couldn't see any calls at all to ExitProcess, not only when I called System.exit but also when I let the program fall of the end of main. Hmm. If that was what was happening there didn't seem to be much I could do to change the behaviour of System.exit, but I already knew that if the process exited by falling off the end of main the problem didn't occur - what I needed to do was to find out how to make that happen from inside a Swing callback. I was wandering around the JDK documentation when I found an interesting document titled AWT Threading Issues, which says:
- Make sure that all AWT or Swing components are made undisplayable when the application finishes. This can be done by calling Window.dispose on all top-level Windows. See Frame.getFrames.
- Make sure that no method of AWT event listeners registered by the application with any AWT or Swing component can run into an infinite loop or hang indefinitely. For example, an AWT listener method triggered by some AWT event can post a new AWT event of the same type to the EventQueue. The argument is that methods of AWT event listeners are typically executed on helper threads.
So the code to work around my problem turned out to be trivial, I just needed to put the following in my exit button callback to make sure that all the threads in the application exit cleanly:
for (Frame f : Frame.getFrames()) {
f.dispose();
}
Hey presto, everything now works. Obviously if the application creates it's own threads they will also need to be gracefully terminated. I'm still discussing the exact cause of the problem with the JVM folks, but for now I'm happy that I've got a workaround. Hopefully this information will save someone some grief as my searching revealed that quite a few people had been hit by this issue but that nobody quite understood how to work around it other than the nasty manual DLL loading hack.