Build ffplay 2.6.2 on Mac OSX 10.10.2

Every few years we desperately need ffmpeg and ffplay for some reason. The ffmpeg suite is my go-to swiss-army knife for whipping video into shape. Unfortunately, the compilation process is sometimes difficult. Here is a summary of the recipe I used to build these tools on OSX 10.10.2. It was not straightforward.

The main pain-point seemed to be getting SDL-1 to build. ( I tried using SDL-2 to get ffplay to compile, but these two do not seem to work together. SDL-1 needed some manual edits to get it going. Whew.

Continue reading

Posted in Software | Tagged , , , , , , | Leave a comment

UIButton coded programmatically does not show: the tale of the weak reference

I am transitioning a little project from Interface Builder to “not Interface Builder.” Or rather, I will be programmatically coding objects, views and constraints. In transitioning an old project to this new style, I ran into a little problem. The symptom was that I could not make my UIButtons appear. The root of the problem was that I left stray weak attributes in my property definitions. Here’s what I learned.

When using Interface Builder, buttons and labels and UIKit objects in your view are connected to your controller with properties.  But what is a @property declaration?  Properties are backed by instance variables and provide convenient getters and setters.  That part is easy enough.

Properties may also have attributes that define how they are managed with respect to Automatic Reference Counting (ARC) and threading.  That sounds nice and convenient, but it’s easy to not keep track of what is going on.

Interface Builder defines the properties on your buttons like this in the interface of your controller.

@propery (nonatomic, weak) UIButton *mybutton;

When using .XIB files, the NIB loader actually “own” the reference count to your button, and your controller only has a weak reference to it.

The trouble started for me when I eliminated my .XIB files, but kept the button declarations.  I created my button programmatically like this.

myButton = [UIButton buttonWithType:UIButtonTypeRoundedRect];
myButton.frame = CGRectMake(0, 100, 100, 20);
[myButton setTitle:@"My Button Title"];
[self.view addSubview:myButton]

This should have added the button to the view, but it refused to appear.  The mystery was solved when I added another button which did not use the old property definitions from Interface Builder.   The corrected property definition for programmatically creating the button is this.

@propery (nonatomic, strong) UIButton *mybutton;

This instructs ARC that the instance variable mybutton owns a reference to the button. It is interesting that this problem would not have occurred in a project created from scratch, just a project that has evolved over time. (Some of the code in my project began even before ARC was available). It’s hard to keep up.

Posted in Software | Tagged , , , , | Leave a comment

A medium-level language for Linux dev?

A nagging question has held my attention for a week or so now: is there a good high- or medium-level language with a modern enviroment for software development on Linux?

Modern Electric Drill

Let me explain.

In the last few years, I have worked with Objc-C on iOS/OSX, Java on Android and .NET/C# on uSoft. Each of these language environments offers a level above C with garbage collection and a dynamic runtime. The development kits support the easy deployment of code onto devices .. and maybe even a distribution channel like an app store.

On Linux, I have access to C++ and all of the dynamic languages (Python, Ruby, Lua, and many others). C++ is not exactly easy to develop with (for me, at this point at least). Python, Ruby and Lua are great, but have inherited a lot of ideas. The biggest problem with these interpreted languages is that they attempt to target ALL of the operating systems. Python and Ruby distributions are designed to be portable to every version of Linux and also Windows. Python and Ruby programs include features to deal with old versions of the language. What if that was not the case? How much cleaner could they be if their purpose was to produce a single program for a single version of an operating system?

XCode with Obj-C (and now Swift) on iOS set a high bar for what a development environment can look like. It benefits from the fact that the execution target is well-defined and well-managed. There is basically only one target: iOS. I want something like this for Linux. A dynamic language that compiles down to a single executable for Linux. One that is not burdened with support for Windows, or old versions of an interpreter.

Forward your ideas my way.

Posted in Software | Tagged , , | Leave a comment

Nuitka Compiler for Python

I like developing using Python.  I like its program structure, its performance and the way it supports coroutines.  What I don’t like is distributing Python programs.  Python installations from one computer to the next are notoriously different from one another.  I may have two seemingly similar Linux computers running the same version of Python and a program may run well on one and may not find a dependency on another.

While the language and run-time system is well-defined, they way in which search-paths are set up and resolved does not seem to be. (See Virtualenv aims to help, but the contract between Python and “the system” seems not well-defined.  The result for me has that it has been difficult to produce shrink-wrapped programs for distribution from Python source.

The types of programs I’ve developed usually have dependencies on locally-developed SWIG-generated shared-libraries (.so), so my case may not be typical.  (However, it is interesting :-)  I’ve looked at using Cython to compile Python modules, and it works well for building an extension module in C, or for extending a C program with Python.
However, if your aim is software construction using Python for the distribution of a complete application, then Cython seems lacking.


Nuitka ( is a “Python Compiler.”   Nuitka can compile just one or a few modules, or it can compile an entire Python program.  It takes a higher-level view of the job of compiling an entire project.
Continue reading

Posted in Software | Tagged , , , , , | 4 Comments