Review of Coursera’s Computational Investing Part I

I got to know of Dr Tucker Balch‘s MOOC (Computational Investing Part 1) from Lin Xinshan. This is a my personal review of the recently concluded 4th offering of the course.

This is the first MOOC that I’ve actually completed (out of the many that I’ve enrolled on a whim). I think it’s a combination of:

  • My strong interest in the subject matter
  • The excellent pacing of the course materials and assignments
  • The timely release of the course textbook: What Hedge Funds Really Do

The course consists of  video lectures, graded assignments and a forum on Piazza. The video lectures mostly mirror the content of the textbook and I found the videos rather tedious actually.

The textbook does a good job of providing a palatable introduction to quantitative portfolio management. It includes the rationale behind constructing  a portfolio with CAPM and the various measures of evaluating its performance (e.g against risk free Treasuries or a broad market index like the S&P 500). Each chapter also includes a short but interesting biography of prominent traders who were able to achieve alpha (market beating returns).

I would have liked the book to discuss the quantitative aspects of measuring portfolio performance in more detail though:

  • It mentions the Sharpe (risk as both upward/downward deviations in returns) and Sortino (considers downside deviations only) ratios but focuses on the former for the entire book. Why would I use the Sharpe ratio instead of the Sortino ratio when I’m primarily interested in downside risk?
  • There is a chapter dedicated to “Event Studies” which measure the effects of events on equity prices for a period of days before and after the event. The authors suggest testing out candidate events in a simulator and backtesting it for fitness.  I take issue with the method as described in the book as it is ripe for curve fitting. I expected at least referencing methods on mitigating the risk of overfitting event rules to past data such as segregating data into In Sample and Out Of Sample data and performing Walk Forward testing on the OOS data.
  • To be fair, the authors do caution against data mining fallacies in another chapter and hints at the segregation of In Sample and Out Of Sample data for use in backtesting and validation respectively but this point is simply not made obvious enough for my liking.
  • Lastly, I would have appreciated a list of resources curated by the authors where readers can obtain deeper discussion of the main points covered by the book.

The real gem for me though is the QuantSoftware Toolkit (QSTK). The QSTK allows anyone to quickly get to grips with the tasks of analysing and visualising portfolio performance (much like how Rails provides a quickstart for web development).  I especially like the fact that It provides the components of SPX adjusted for survivorship bias.

This library is written in Python and makes extensive use of Pandas, NumPy and Matplotlib. It was an enjoyable experience picking up Python and exploring the Pandas/NumPy/Matplotlib APIs. I can safely say that I’ve gained a newfound appreciation for how I can use these powerful libraries to supplement my own quantitative analysis.

I would highly recommend this course to anyone who wishes to get a good introduction on constructing and evaluating asset portfolios with quantitative methods.

I’ve decided to relearn the C language after years of using higher level languages like Ruby and Java because I viewed it as a necessary step to the greater understanding of the computing stack comprising software and processing hardware (CPU & GPU).

I would even state that gaining a expert understanding of C provides greater value to writing high performance software by maximising the local performance of code on multiple CPU cores, than using ever more complex libraries/platforms that distribute work to multiple computers across network links. That being said, distributed computing remains very much applicable to tasks that cannot fit within the memory and storage constraints of a single computer.

I tried reading The C Programming Language but it was hard for me to get into it because the book contained a lot of preliminary material for introducing programming to beginners. The tone of instruction was also rather dry and was suited for a reference manual.

Next I looked at Learn C The Hard Way from Zed Shaw. I like it for the fact that it introduces Valgrind very early, as well as the practical bent to the exercises. However I preferred something that provided a more polished learning experience in terms on overall structure as well as a focus on the use of memory pointers.

Pointers on C by Kenneth A. Reek turned up on searches for the appropriate books and the various positive reviews were sufficient to warrant the purchase of a used copy from Amazon. Do yourself a favour and pick up used copies instead of brand new as the new books are absurdly pricey.

Pointers on C is structured into 18 chapters, excluding an appendix containing answers to selected questions at the end of each chapter.

Chapter 1: A Quick Start

Starts off by giving a glimpse of the big (programming) picture by introducing a simple C program that reads text from the standard input, modifies it and writes it to the standard output. The chapter then explains in detail the lexical rules and constructs used in the source code.

I prefer this approach to starting with lexical and syntactical rules as the reader gets to see and run a program that does something more useful than printing “Hello world”.

Chapter 2: Basic Concepts

Briefly describes the translation environment, in which source code is converted into executable machine instructions; and the execution environment, in which the code actually runs.. Gives an overview of how source files are preprocesed, compiled and linked.

Explains lexical rules pertaining to the C language, such as permitted characters, comment structure and identifiers.

Chapter 3: Data

Introduces the integer, floating point and enumerated types, along with details on their characteristics and properties. Clarifies the differences between block scope, file scope, prototype scope and function scope leading to how the compiler resolves linking to identifiers.

Additionally, the chapter provides a lucid explanation of how variable values are stored according its storage class. There are 3 possible places to store variables: ordinary memory (heap), on the runtime stack, and in hardware registers. Each type of storage class contains different characteristics in terms of variable initialisation.

The author clearly explains how the storage classes for variables can be affected through scope, as well as the use of the static and register keywords.

Chapter 4: Statements

Fairly standard treatment of the control flow and looping statements available in C.

Chapter 5: Operators and Expressions

Describes the various operators in C that support bitwise shifting, arithmetic, relational and logical operations. The author also provides good advice when working around the lack of a boolean type in C. The difference and interchangeability between L-values and R-values are clarified:

  • A L-value is something that can appear on the left side of an equal sign; an R-value is something that can appear on the right side of an equal sign, e.g a = b + 25
  • A L-value denotes a place while a R-value denotes a value.
  • A L-value can be used anywhere a R-value is needed but a R-value cannot be used when a L-value is needed.

There is also a very useful operator precedence table for reference.

Chapter 6: Pointers

A very well written chapter going into details of what C pointers are. This is the best explanation of memory pointers I have seen so far.

The author explains the topics of pointers, pointers to pointers, indirection and L-values superbly in a visual style that manages to incorporate pointer arithmetic and operator precedence into the mix. This is just the start of the focus on pointers as the rest of the book makes extensive of pointers.

Chapter 7: Functions

Syntactical explanation of function prototypes and explains how to implement variable argument functions. There is a note that states the compiler assumes an integer type is returned if the function prototype doesn’t define a return type.

Highlights the passing-by-value semantics for function arguments.The interesting part of this behaviour is that it is consistent with non-scalar values such as structs or arrays. This is due to the fact that name of the array/struct are really pointers to the first element/member.

Discusses the memory usage, computational tradeoffs between recursive and iterative functions with examples calculating factorials and Fibonacci numbers, making a compelling case for favouring iterative algorithms over recursive ones.

Chapter 8: Arrays

Expands the discussion from the previous chapter on the concept of array names containing pointer constants (address of the first element of the array) as values. Highlights the differences between pointers and subscripts in the context of arrays.

Discusses how pointers may be more efficient than subscripts by analysing the generated assembler code, concluding that optimising the assembler code should be taken only as an extreme measure. I’m inclined to agree.

Illustrates details on the storage order of arrays which includes memory layouts for multi-dimensional arrays.

Chapter 9: Strings, Characters, and Bytes

Clarifies the definition of a C string (a sequence of zero or more characters followed by a NUL byte); works through the usage of both restricted and unrestricted string functions.

Briefly describes character functions for classification and transformation, in addition to demonstrating functions for working with arbitrary sequences of bytes in memory.

Chapter 10: Structures and Unions

Describes syntax for declaring structures and accessing members. Offers an approach to defining self referential structures, and the use of incomplete declarations for declaring mutually dependent structures.

Another easy to understand visual explanation of accessing structures and structure members with pointers, including how structures are stored in memory and the implications with architectures that require boundary alignment (e.g machines with 4 byte integers and must begin at addresses evenly divisible by 4)

Discussion of Bit Fields, Unions and Variant Records with applicability and tradeoffs in terms of maintenance and memory usage.

Chapter 11: Dynamic Memory Allocation

Explains how programs can obtain and manipulate chunks of memory with malloc, free, calloc, realloc. Cautions against common errors with dynamic memory allocation and memory leaks.

Chapter 12: Using Structures and Pointers

Here the author walks the reader through the design and implementation of a linked list. The author implements the abstract data structure as a singly linked list first, then modifies it into a doubly linked list.

As is already evident from the book so far, the author is fantastic at explaining his thoughts in a straightforward manner during the design and implementation process.

Chapter 13: Advanced Pointer Topics

Introduces the concept of multiple levels of indirection that pointers can have and explains in detail advanced declarations of pointer variables in gradual levels of complexity. Mentions cdecl, a *nix utility for converting between C declarations and English. Try this on for size: int (* (*f)())[10]

Explains pointers to functions and how they can be used for callback functions and jump tables; processing command line arguments with examples.

The author includes an interesting way to perform pointer arithmetic and indirection with string literals. Even better,  there is an example code snippet that makes use of this approach to simplify the logic of performing character to integer conversion, which opened my mind to say the least.

Chapter 14: The Preprocessor

Describes the predefined symbols and directives provided by the preprocessor as well as defining macros.The author helpfully points out the possible issues with operator precedence and evaluation due to the fact that the preprocessor merely performs substitution of the macro’s text into the instances.


The precedence order of an expression with an occurrence of a macro that evaluates expressions may change, post macro substitution.

Chapter 15: Input/Output Functions

In-depth treatment to working with text and binary streams using stdio.h library functions. Introduces the FILE structure which represents an input/output stream being used by the program.

The chapter explains how to work with character, line and binary I/O, as well as provides an exhaustive table of format codes used with the printf and scanf family of functions.

Chapter 16: Standard Library

This chapter contains explanations and examples of the following categories of functions from the standard library:

  • Arithmetic <stdlib.h>
  • Random Numbers <stdlib.h>
  • Trigonometry <math.h>
  • Hyperbolic <math.h>
  • Logarithm and Exponent <math.h>
  • Floating Point Representation <math.h>
  • Power <math.h>
  • Floor, Ceiling, Absolute Value and Remainder <math.h>
  • String Conversion <stdlib.h>
  • Processor Time <time.h>
  • Time of Day <time.h>
  • Date and Time Conversions <time.h>
  • Nonlocal Jumps <setjmp.h>
  • Processing Signals <signal.h>
  • Printing Variable Argument Lists <stdarg.h>
  • Terminating Execution <stdlib.h>
  • Assertions <assert.h>
  • The Environment <stdlib.h>
  • Executing System Commands <stdlib.h>
  • Sorting and Searching <stdlib.h>
  • Numeric and Monetary Formatting <locale.h>
  • Strings and Locales <string.h>

The more notable parts of this chapter were:

Nonlocal Jumps

The functions in setjmp.h provides a mechanism similar to goto but not limited in scope to one function and are commonly used with deeply nested chains of function calls. If an error is detected in a lower-level function, it’s possible to return immediately to the top-level function without having to return an error flag to each intermediate function in the chain.

Processing Signals

The types of work available in signal handlers are limited. If the signal is asynchronous (triggered external to the program), no library functions should be called other than signal because their results are undefined in this context.

Furthermore, the handler may not access static data except to assign a value to a static variable of type volatile sig_atomic_t. To be truly safe, about all that a signal handler can do is set one of these variables and return. The rest of the program must periodically examine the variable to see if a signal has occurred.

Chapter 17: Classic Abstract Data Types

This chapter is similar to chapter 12, except the focus is on designing and implementing the stack, queue and binary tree abstract data types. The author quickly introduces each data structure and moves into design and implementation of the ADT.

Chapter 18: Runtime Environment

The final chapter deals with examining the assembly language code produced by the author’s specific compiler for his specific computer in order to learn several interesting things about the runtime environment. The author generates assembly code from compiling a C source file to determine:

  • how a static variable is initialised,
  • the maximum number of register variables available for use by programs,
  • the maximum length of external identifier names,
  • the function calling/returning protocol (i.e Application Binary Interface),
  • the stack frame layout

This chapter is highly technical and will take multiple readings to digest, and apply to other architectures and compilers. That said, it may be easier to just look up the schematics/ABI for your particular CPU online.

I enjoyed reading this book and working through the exercises after each chapter. The side notes the author included for comparisons between K&R C and ANSI C were somewhat interesting from a historical standpoint. Much more useful are the cautions and tips throughout the book that provide insights into the use of C, that would otherwise be discovered only through hard-earned experience.

libxml2 for Nokogiri in JRuby

I’ve been playing with Nokogiri on JRuby 1.3.0 and this message gets displayed when I require ‘nokogiri’:

macbookpro:~ douglas$ jirb
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'nokogiri'
HI. You're using libxml2 version 2.6.16 which is over 4 years old and has
plenty of bugs. We suggest that for maximum HTML/XML parsing pleasure, you
upgrade your version of libxml2 and re-install nokogiri. If you like using
libxml2 version 2.6.16, but don't like this warning, please define the constant
=> true

That can’t be, I’ve just upgraded libxml2 and libxslt in my MacPorts installation. Digging further, I don’t receive the message when doing the same thing on MRI. A quick look with lsof reveals that the shared libraries are being loaded from /usr/lib instead of /opt/local/lib (MacPorts is installed into /opt/local).

lsof -c java
java 390 douglas txt REG 14,2 290736 898139 /usr/lib/libexslt.0.dylib

lsof -c ruby
ruby 865 douglas txt REG 14,2 72156 1871557 /opt/local/lib/libexslt.0.8.13.dylib
ruby 865 douglas txt REG 14,2 218688 1871571 /opt/local/lib/libxslt.1.1.24.dylib
ruby 865 douglas txt REG 14,2 1251948 1866501 /opt/local/lib/libxml2.2.7.3.dylib

Nokogiri uses Ruby FFI to dynamically load native C code and FFI makes use of dlopen to do the actual loading of dynamic libraries. On OSX, dlopen searches for files specified by a couple of environment variables (LD_LIBRARY_PATH, DYLD_LIBRARY_PATH, DYLD_FALLBACK_LIBRARY_PATH), and the current working directory.

Setting LD_LIBRARY_PATH to /opt/local/lib worked for me. There may be differences in the environment variables used for dlopen on different platforms, so a look at the MAN pages would be a good idea if things don’t seem to work.

Using soap4r with .NET web services authenticated with WSSE

Recently I had to consume a .NET web service that uses WSSE based authentication. Thanks to the intarweb, I was able to get started with soap4r and insert WSSE authentication headers into my SOAP requests.The samples available on the tracker are also quite comprehensive, other than being light on explanation.

I did encounter an error when using the automatically generated client application:

ruby WSDLService_PortClient.rb
./defaultMappingRegistry.rb:5: uninitialized constant SOAP::Mapping::EncodedRegistry (NameError) from ./defaultDriver.rb:2:in `require'
from ./defaultDriver.rb:2
from ./WSDLService_PortClient.rb:2:in `require'
from ./WSDLService_PortClient

It appears that the soap library provided with Ruby 1.8.6 is being used instead of the soap4r gem. The version bundled with Ruby doesn’t have some classes referenced by the generated stubs (from wsdl2ruby) as well as a bunch of other functionality.

The solution is simple (after knowing what’s wrong of course): explicitly reference the gem so that Ruby knows which one to use.

require 'rubygems'
gem 'soap4r'

Just insert this snippet before the code that references the missing classes and you’re good to go.

Specifying raising of errors in RSpec

RSpec allows a developer to specify that an error is raised within a block with the raise_error method. It’s a nice expressive way of saying that your code should fail when it needs to.

But my tiny brain has often been confused with using it at times, more so when the error class requires parameters for instantiation and when used in conjunction with the and_raise method on a stub or a mock

Consider the snippet below where my Widget depends on Thingamajig to do its funky thing in order to run. But Thingamajig is rigged to explode in a mass of funkyness and make Widget all useless.

describe Widget do
it "should re-raise errors as a Widget::UnrecoverableError" do
# expectations
thingamajig = stub(Thingamajig)
thingamajig.should_receive(:do_funky_thing).and_raise('The funky thang exploded yo'))

# our SUT
widget =

lambda { }.should raise_error(Widget::UnrecoverableError, 'The funky thang exploded yo')

Do you notice the inconsistency between the way errors are declared in the expectation and the actual verification?

# expectations
thingamajig.should_receive(:do_funky_thing).and_raise('The funky thang exploded yo'))

lambda { }.should raise_error(Widget::UnrecoverableError, 'The funky thang exploded yo')

The expectation on the stub, ‘thingmajig’ needs the exception instantiated first while verification requires the class name and parameters used to instantiate the error instance.

And no, doing it like this doesn’t work as expected:

lambda { }.should raise_error('The funky thang exploded yo'))

It’s an unfortunate impedance mismatch that might be caused due to the way Ruby handles the raising of errors.

Using cruisecontrol.rb with repositories without anonymous access

I decided to use cruisecontrol.rb for continuous integration of an application that I’m working on at Bezurk. So I downloaded the 1.2.1 release from RubyForge and proceeded to add the project repository to the local installation of cruisecontrol.rb.

douglas@macbookpro:~$ ./cruise add MyProject --url --username 'douglas' --password 'guessable'
douglas@macbookpro:~$ ./cruise build MyProject
Builder for project 'MyProject' started
Logging to: /Users/douglas/Development/Ruby/cruisecontrolrb-1.2.1/log/MyProject_builder.log
Build loop failed
BuilderError: svn: PROPFIND request failed on '/svn/my_project/trunk'
./script/../config/../app/models/subversion.rb:98:in `execute_in_local_copy'
./script/../config/../lib/command_line.rb:86:in `call'
./script/../config/../lib/command_line.rb:86:in `e'
./script/../config/../lib/command_line.rb:84:in `popen'
./script/../config/../lib/command_line.rb:84:in `e'
./script/../config/../lib/command_line.rb:71:in `execute'
./script/../config/../lib/command_line.rb:70:in `chdir'
./script/../config/../lib/command_line.rb:70:in `execute'
./script/../config/../app/models/subversion.rb:89:in `execute_in_local_copy'
./script/../config/../app/models/subversion.rb:85:in `chdir'
./script/../config/../app/models/subversion.rb:85:in `execute_in_local_copy'
./script/../config/../app/models/subversion.rb:44:in `latest_revision'
./script/../config/../app/models/project.rb:228:in `new_revisions'
./script/../config/../app/models/change_in_source_control_trigger.rb:8:in `revisions_to_build'
./script/../config/../vendor/rails/actionpack/lib/../../activesupport/lib/active_support/core_ext/symbol.rb:10:in `__send__'
./script/../config/../vendor/rails/actionpack/lib/../../activesupport/lib/active_support/core_ext/symbol.rb:10:in `to_proc'
./script/../config/../app/models/project.rb:223:in `collect'
./script/../config/../app/models/project.rb:223:in `revisions_to_build'
./script/../config/../app/models/project.rb:202:in `build_if_necessary'
./script/../config/../app/models/polling_scheduler.rb:13:in `run'
./script/builder:78:in `catch'
./cruise:14:in `load'
./cruise:14:in `builder'
./cruise:68:in `send'
/opt/local/lib/ruby/1.8/fileutils.rb:121:in `chdir'
/opt/local/lib/ruby/1.8/fileutils.rb:121:in `cd'

Hmm, what’s with the svn: PROPFIND error? Looking at the stracktrace doesn’t tell me alot about what’s going wrong here, let’s try logging errors to the console.

douglas$ svn --non-interactive info --xml
douglas$ svn --non-interactive log --revision HEAD:20 --verbose --xml
svn: PROPFIND request failed on '/repository/trunk'
svn: PROPFIND of '/repository/trunk': authorization failed (

It happens that my repository does not have anonymous access and requires a subversion user account to do anything useful. So it should be obvious that cruisecontrol.rb is trying to get log info from the repository but subversion is quitting with authentication errors because no user credentials are being supplied.

I need to have cruisecontrol.rb make use of the –username and –password options when making queries to the repository when I give it the credentials for access.

My first stop is the app/models/subversion.rb. Only the checkout method uses the username and password instance variables. Subversion should only include the –username and –password options when executing svn commands when both the username and password instance variables are present.


def test_svn_command_uses_user_password_when_provided
	svn = => 'jer', :password => "crap")

	svn.expects(:info).with(dummy_project).returns(, 10))
	svn.expects(:execute).with(["svn", "--non-interactive", "log", "--revision", "HEAD:10", "--verbose", "--xml",
								"--username", "jer", "--password", "crap"],
								{:stderr => './svn.err'}).yields(



def checkout(target_directory, revision = nil, stdout = $stdout)
	@url or raise 'URL not specified'

	options = [@url, target_directory]
	options < < "--revision" << revision_number(revision) if revision

	# need to read from command output, because otherwise tests break
	execute(svn('co', options)) do |io|
		while line = io.gets
			stdout.puts line
		rescue EOFError

def svn(operation, *options)
	command = ["svn"]
	command << "--non-interactive" unless @interactive
	command << operation
	command += options.compact.flatten
	command += ['--username', @username, '--password', @password] if @username and @password

The username and password would then be injected into the project’s Subversion instance in the cruise_config.rb file for each project.

Project.configure do |project|
    project.source_control.username = 'douglas'
    project.source_control.password = 'guessable'

I’ve submitted a ticket along with a patch for this on cruisecontrol.rb’s tracker. Keep a lookout for it if you happen to encounter the same problem.

Serializing custom Ruby classes with YAML

I needed to be able to save an array of POROs (plain old Ruby objects) to the database on a Rails project that I’m currently working on. That should be easy, right?

This ought to do the job, yes?:
class MyModel < ActiveRecord::Base
serialize attribute_name

However, this didn’t quite work as advertised, the objects being returned were typed as YAML::Object instead of the actual class being serialized. Turns out that YAML is unable to find the reference to the actual class and so its falling back to using YAML::Object as the generic class type for deserialised objects. The answer to this: Rails ticket #7537.

Take a look at the YAML documentation for all the gory details.

Behaviour Driven Development != Testing

Testing: Executing a program with the specific intent of uncovering errors.

Software Engineering: A Practitioner’s Approach – Roger S Pressman

The definition of testing by Pressman states that the purpose of performing software testing is to detect errors in a program. This encompasses a wide range of techniques such as black box/white box testing, basis path testing, fault based testing and at a more thorough level, control structure testing.

So where do the specifications in Behaviour Driven Development (BDD) fit into the picture? In this respect, BDD isn’t about testing at all. We write specifications to say that the software exhibits a specific behaviour when its in a certain state. The specifications serve to reinforce the notion that the program is working as expected under known conditions.

Having 100% coverage for code certainly does not mean that a program is free of errors, there are still edge cases that may be too difficult or complex to replicate with an automated test suite. Traditional QA testing is still very much relevant to software projects with BDD employed religiously throughout development.

This has been discussed at length before but it bears repeating: BDD is a design technique that gives you executable documentation of what functions the software is expected to provide.

Installing SSHFS on MacPorts

I came across SSHFS in an article by Paul Gross and thought of trying it out. Unfortunately, I had to take a slightly more complicated route to have it installed with MacPorts on my laptop.


sudo port install sshfs

caused this particular error to appear:

--->  Building fusefs

Error: Target returned: shell command "cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_fuse_fusefs/work/fusefs" && xcodebuild  -target "fusefs" -configuration Release build OBJROOT=build/ SYMROOT=build/ OBJROOT=build/ SYMROOT=build/" returned error 1

Command output: === BUILDING NATIVE TARGET fusefs WITH CONFIGURATION Release ===Checking Dependencies...

Cpp build/Release/fusefs.kext/Contents/Info.plist build/

    cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_fuse_fusefs/work/fusefs

    /usr/bin/gcc -E -P -x c -Wno-trigraphs /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_fuse_fusefs/work/fusefs/build/ -o /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_fuse_fusefs/work/fusefs/build/Release/fusefs.kext/Contents/Info.plist

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_fuse_fusefs/work/fusefs/build/ error: common/fuse_version.h: No such file or directory

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_fuse_fusefs/work/fusefs/build/ error: common/fuse_param.h: No such file or directory


Error: The following dependencies failed to build: fusefs libfuse

Error: Status 1 encountered during processing.

A quick spot of googling found the answer to this pretty quickly. Hans-Göran (comment #24) mentioned that he managed to install fusefs after copying the files that the error was complaining were missing.

At first glance, it seems that the file in question (common/fuse_param.h) is indeed present in the build directory. It appears that the error is being triggered from the property list file for the build.


Taking a look at its contents reveals that it’s including 2 header files from its containing directory

#include "common/fuse_version.h"

#include "common/fuse_param.h"

So I copied over the missing directory and re-ran the sshfs install.

cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_fuse_fusefs/work/fusefs

sudo cp -r common build/

sudo port install sshfs
--->  Fetching libfuse
--->  Attempting to fetch fuse-2.6.5-macosx.patch from
--->  Attempting to fetch fuse-2.6.5.tar.gz from
--->  Verifying checksum(s) for libfuse
--->  Extracting libfuse
--->  Applying patches to libfuse
--->  Configuring libfuse
--->  Building libfuse with target all
--->  Staging libfuse into destroot
--->  Installing libfuse 2.6.5_1
--->  Activating libfuse 2.6.5_1
--->  Cleaning libfuse
--->  Fetching sshfs
--->  Attempting to fetch sshfs-fuse-1.7-macosx.patch from
--->  Attempting to fetch sshfs-fuse-1.7.tar.gz from
--->  Verifying checksum(s) for sshfs
--->  Extracting sshfs
--->  Applying patches to sshfs
--->  Configuring sshfs
--->  Building sshfs with target all
--->  Staging sshfs into destroot
--->  Installing sshfs 1.7_5
--->  Activating sshfs 1.7_5
--->  Cleaning sshfs

Now sshfs is installed!