OpenSCAD and Emacs

Yesterday I discovered OpenSCAD which is basically a tool where you program your 3D scene instead of interactively modeling it. Take a look at the following example.

difference () {
  cube([5, 5, 0.5], center=true);
  cylinder(r=2, h=1, center=true, $fn=72);


By adding and subtracting primitives you can form modules (parts) and use them in more complex parts. There was of course already an emacs mode for OpenSCAD called scad-mode which ships with OpenSCAD but can also be found on MELPA. Together with scad-preview you can build parts within emacs and preview them. The big benefit here is that the preview can be controlled (rotating, zooming, …) from within emacs.

The only thing missing was org-babel support so you can integrate it in your org files. So I quickly hacked it together: ob-scad.el.

October 18, 2015 | emacs, openscad

Travis: CMake, Qt5 and Tests

It took me a while until I understood howto setup travis-ci to build and test Solstice. So here are the steps I took and the difficulties I encountered.

The Application

The Application is written in C++ and uses QT5.5 as GUI Framework. The build tool is CMake. Unit Tests will be using google-test to test the c++ core and qml Tests will test the frontend. The project is hosted in GitHub.

Project Structure

I followed this post by David Corvoysier to find a good structure to integrate CMake and google-test. There are however a few changes. The test directory has several sub directories: one for each C++ Module and one named qmltests, which contains all GUI tests.

wose:Solstice/ (master) $ tree .
├── cmake
│   └── modules
│       └── QmlTest.cmake
├── CMakeLists.txt
├── qml
│   ├── CMakeLists.txt
│   ├── images
│   │   └── menu.svg
│   ├── main.qml
│   ├── qml.qrc
│   ├── RingMenu.qml
│   └── SettingsDialog.qml
├── src
│   ├── CMakeLists.txt
│   └── main.cpp
└── tests
    ├── CMakeLists.txt
    ├── core
    └── qmltests
        ├── CMakeLists.txt
        └── tst_QmlTestTest.qml


google-tests worked without any issues. CMake will fetch the corresponding archive and adds gtest and gmock as external projects. The following CMakeLists.txt is an example of one which can be used in any of the tests/[modulename] directories.

 1: file(GLOB SRCS *.cpp)
 3: ADD_EXECUTABLE(testfoo ${SRCS})
 6:     libgtest
 7:     libgmock
 8: )
10: add_test(NAME testfoo
11:          COMMAND testfoo)

Here I compile all *.cpp files 1 to an executable named testfoo 3. Link it against libgtest and libgmock 5. And finally tell CMake that testfoo is a test also named testfoo 10.

I used the following test to verify that c++ tests are working.

#include "gtest/gtest.h"

int main(int argc, char **argv)
    ::testing::InitGoogleTest(&argc, argv);
    int ret = RUN_ALL_TESTS();
    return ret;

TEST(FactorialTest, Zero) {
  EXPECT_EQ(1, 1);

qml Tests

The CMake module cmake/QmlTest.cmake is stolen from playground-qtmirserver. It provides a function add_qml_test to simply add qml tests to the test suite. The following CMakeLists.txt is from tests/qmltests.


add_qml_test(. QmlTestTest)


As I started reading on howto use travis I learned about howto use the new addon feature to add all needed repositories and install the required software. After some tests I figured out that the repositories and packages have to be whitelisted to be able to use them. As of this writing either the repository nor the qt5.5 packes are on those lists. A corresponding issue is open, it'll probably just take a little more time.

So I switched back to the legacy mode and got the project to compile. But the qml tests failed for OTHER_FAULT. I first thought missing qt packages could be the reason and added the qt55quickcontrols package to the installation. No change. Turns out the qml tests need a valid DISPLAY environment variable. To achieve this I started xvfb within the before_install section 6.

 1: language: cpp
 3: compiler:
 4:   - gcc
 6: before_install:
 7:   - export DISPLAY=:99.0
 8:   - sh -e /etc/init.d/xvfb start
10: install:
11:   - sudo apt-add-repository -y ppa:ubuntu-toolchain-r/test
12:     && sudo apt-add-repository -y ppa:beineri/opt-qt55
13:   - sudo apt-get -qq update
14:   - sudo apt-get -qq install g++-4.9 qt55base qt55quickcontrols qt55declarative qt55tools qt55svg lcov curl
15:   - export CXX="g++-4.9"
16:     && export CC="gcc-4.9"
17:   - source /opt/qt55/bin/
18:   - wget -qO- | tar xvz
19:   - sudo cp -fR cmake-3.1.0-Linux-x86_64/* /usr
21: before_script:
22:   - mkdir build
23:   - cd build
24:   - cmake -DCMAKE_BUILD_TYPE=debug -DCMAKE_PREFIX_PATH=/opt/qt55/lib/cmake ..
26: script: make && make test
28: notifications:
29:   email: false

I manually fetch and install cmake to get a newer version (>=3.1) 18.

All of the above is included here and can probably be used as some sort of boilerplate for similar projects.

October 07, 2015 | Travis, CMake, c++11, Qt5, TDD

Android apps with emacs

Recently my $gf got her first smartphone and since I don't own one it was the first chance I got messing around with android and its API. I tried some basic java samples and fiddled with the NDK as well. I did all this using AndroidStudio, but since it won't run on my laptop (not enough RAM) and there were no c/c++ plugins (yet) to aid the development of native apps, I dumped it. My first choice as an alternative is Emacs. I found android-mode quite easy to use. I added a small patch from lateau which adds support for the ndk-build command. To get class/function/package… completion for the java part I'm using the fork of ajc-java-complete from whitypig. Creating the tags of the system jars didn't work though. I used the prebuild tags and created the android tags with Tags.jar as described in the install file. I'm still using pidcat as a nice colorful logcat alternative until I'm happy with or used to the implementation which android-mode supplies.

So here are a few steps to get a android development environment powered by Emacs.

1 Get the android SDK and NDK.

> mkdir -p ~/projects/android
> cd ~/projects/android
> wget
> tar xfz android-sdk_r23.0.2-linux.tgz
> wget
> tar xfj android-ndk32-r10b-linux-x86_64.tar.bz2

2 Add some of those newly created folders to your PATH


Add these lines to your .bashrc or .zshrc or whatever.

3 Install/update the android API

> android sdk

4 Create a virtual device for local testing

> android avd

5 Install android-mode

M-x el-get-install<RET>


M-x list-packages
(select android-mode and install)

6 Patch android-mode (fork with applied changes follow)

7 Test the whole thing using an NDK sample

> mkdir -p ~/projects/android/workspace
> cp -r ~/projects/android/android-ndk-r10b/samples/hello-jni ~/projects/android/workspace/
> cd ~/projects/android/workspace/hello-jni
> android update project -n hello-jni -p . -t 1

We'll use ant to build our project. The last line creates the necessary files for ant. Now fire up Emacs, and open the file ./src/com/example/hellojni/ Enable android-mode if not done automatically and try the following.

M-x android-ndk-build

A new buffer should open and you should see something like this:

-*- mode: compilation; default-directory: "~/projects/android/workspace/hello-jni/" -*-
Compilation started at Wed Oct  1 22:49:22

Android NDK: WARNING: APP_PLATFORM android-17 is larger than android:minSdkVersion 3 in ./AndroidManifest.xml    
[armeabi-v7a] Gdbserver      : [arm-linux-androideabi-4.6] libs/armeabi-v7a/gdbserver
[armeabi-v7a] Gdbsetup       : libs/armeabi-v7a/gdb.setup
[armeabi] Gdbserver      : [arm-linux-androideabi-4.6] libs/armeabi/gdbserver
[armeabi] Gdbsetup       : libs/armeabi/gdb.setup
[x86] Gdbserver      : [x86-4.6] libs/x86/gdbserver
[x86] Gdbsetup       : libs/x86/gdb.setup
[mips] Gdbserver      : [mipsel-linux-android-4.6] libs/mips/gdbserver
[mips] Gdbsetup       : libs/mips/gdb.setup
[armeabi-v7a] Install        : => libs/armeabi-v7a/
[armeabi] Install        : => libs/armeabi/
[x86] Install        : => libs/x86/
[mips] Install        : => libs/mips/

Compilation finished at Wed Oct  1 22:49:24

The native part was compiled successfully. To build the java part just run:

M-x android-build-debug

A new buffer will open and you will see the verbose output of ant compiling you sources using the previously generated build.xml.

To test the created app, start an emulator and deploy the app using the commands android-mode provides.

M-x android-start-emulator
the tab key should complete the previously created avd name
M-x android-build-install
M-x android-logcat
M-x android-start-app

Your native app should now be running within your emulator. Hooray.


October 01, 2014 | android, java, c++, c, emacs

changes in org-mode

It has been almost a year since my last post and apparently there were some changes in org-mode which broke my blog setup. I have no idea which org-mode version I used a year ago but currently I'm running version 20140210.

The publishing-function org-publish-org-to-html changed to org-html-publish-to-html and the variable org-export-htmlize-output-type changed to org-html-htmlize-output-type.

February 19, 2014 | org-mode, emacs


A few weeks ago I stumbled across the awesome pedalSHIELD from It's basically an Arduino shield which allows you to build your own programmable guitar/bass effect pedal. I ordered all parts including an Arduino DUE. I didn't order a prebuild shield since there were some things missing I'd like to have on my pedal:

  • a LCD display as UI (change effect parameters etc.)
  • a build in tuner, this is mostly software but some additional LEDs or a LCD display will be required
  • a little amp which can be toggled, so you can plug in your headphones
  • a possibility to switch between bass and guitar

So I tweaked the available schematics a little bit and started building a robust housing, which I hope will endure that the foot switch is pressed with an actual foot more than once.

"pedalSHIELD housing"

The pcb layout was a little bit tricky since I needed wide tracks for the toner-transfer-method to work properly. I have no image of the finished pcb but I screwed up. The layer were perfectly aligned but I forgot about the pcb while it was in the etch bath. The result were broken tracks all over the pcb. So I'll need to redo the layout to be more forgiving.

I'll post the reviewed schematics and the pcb layout as soon as I got a working version.

February 17, 2014 | guitar, arduino
about | blog | archives