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
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
├── LICENSE
├── qml
│ ├── CMakeLists.txt
│ ├── images
│ │ └── menu.svg
│ ├── main.qml
│ ├── qml.qrc
│ ├── RingMenu.qml
│ └── SettingsDialog.qml
├── README.org
├── src
│ ├── CMakeLists.txt
│ └── main.cpp
└── tests
├── CMakeLists.txt
├── core
└── qmltests
├── CMakeLists.txt
└── tst_QmlTestTest.qml
google-test
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)
2:
3: ADD_EXECUTABLE(testfoo ${SRCS})
4:
5: TARGET_LINK_LIBRARIES(testfoo
6: libgtest
7: libgmock
8: )
9:
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.
include(QmlTest)
add_qml_test(. QmlTestTest)
travis-ci
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
2:
3: compiler:
4: - gcc
5:
6: before_install:
7: - export DISPLAY=:99.0
8: - sh -e /etc/init.d/xvfb start
9:
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/qt55-env.sh
18: - wget -qO- http://www.cmake.org/files/v3.1/cmake-3.1.0-Linux-x86_64.tar.gz | tar xvz
19: - sudo cp -fR cmake-3.1.0-Linux-x86_64/* /usr
20:
21: before_script:
22: - mkdir build
23: - cd build
24: - cmake -DCMAKE_BUILD_TYPE=debug -DCMAKE_PREFIX_PATH=/opt/qt55/lib/cmake ..
25:
26: script: make && make test
27:
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
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 http://dl.google.com/android/android-sdk_r23.0.2-linux.tgz
> tar xfz android-sdk_r23.0.2-linux.tgz
> wget http://dl.google.com/android/ndk/android-ndk32-r10b-linux-x86_64.tar.bz2
> tar xfj android-ndk32-r10b-linux-x86_64.tar.bz2
2 Add some of those newly created folders to your PATH
ANDROID_SDK=$HOME/projects/android/android-sdk-linux
ANDROID_NDK=$HOME/projects/android/android-ndk-r10b
PATH=$PATH:$ANDROID_SDK/tools:$ANDROID_SDK/platform-tools:$ANDROID_NDK
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>
android-mode
or
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/HelloJni.java. 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
ndk-build
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 : libhello-jni.so => libs/armeabi-v7a/libhello-jni.so
[armeabi] Install : libhello-jni.so => libs/armeabi/libhello-jni.so
[x86] Install : libhello-jni.so => libs/x86/libhello-jni.so
[mips] Install : libhello-jni.so => libs/mips/libhello-jni.so
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
<tab>TestEmu<ret>
...
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.
Refs:
October 01, 2014
|
android,
java,
c++,
c,
emacs
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
electrosmash.com. 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.
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
