Posts Tagged ‘make’

Make the most recent tex document in the current directory and open it

Wednesday, January 13th, 2016

Here’s a little bash script to compile (pdflatex, bitex, 2*pdflatex,etc.) the most recent .tex file in your current directory that contains begin{document} (i.e. the main document):

if [ -z "$LMAKEFILE" ]; then
  echo "Error: didn't find LMAKEFILE environment variable"
  exit 1
TEX=$( \
  grep -Il1dskip "begin{document}" *.tex | \
  xargs stat -f "%m %N" | \
  sort -r | \
  head -n 1 | \
  sed -e "s/^[^ ]* //")
if [ -z "$TEX" ]; then
  echo "Error: Didn't find begin{document} in any .tex files"
  exit 1
make -f $LMAKEFILE $BASE && open $BASE.pdf

Simply use it:


Alias for universal latex makefile

Wednesday, December 31st, 2014

A friend recently turned me on to latex-makefile. This little script generates a universal Makefile for building latex documents. I was pretty impressed. All you need to do is copy the generated Makefile into your working directory of tex files and issue:


or if you have many .tex files

make [main_document]

I caught myself copying this makefile into a few places which seemed a bit silly so instead I put it in a reasonable place and made an alias to find it there:

export LMAKEFILE="/usr/local/include/UniversalLatexMakefile"
alias lmake="make -f $LMAKEFILE"

Now I can type from anywhere:

lmake [main document]

without copying the Makefile

Coffee Shop Compiler

Monday, December 15th, 2014

Here’s a proposal for a compiler/build system for developers like myself who often find themselves coding in a coffee shop with strong wifi connection, but poor power outlet availability and limited battery life.

The standard coding and debugging cycle looks like:

  1. Code for a bit
  2. Think for a bit
  3. Repeat steps 1 and 2 for a bit
  4. Compile (make)
  5. If compile failed return to step 2
  6. Run executable
  7. Return to step 2

The power bottleneck (for my typical cycle) is by far step 4. My idea is to outsource compiling to a server (plugged into a wall outlet). The naive implementation would change the cylce to:

  1. Code for a bit
  2. Think for a bit
  3. Repeat steps 1 and 2 for a bit
  4. compile on server
    1. send code to server
    2. compile on server
    3. if compile failed, send back errors and return to 2
    4. send back executable
  5. Run executable
  6. Return to step 2

A better implementation might roll git into the make command on the local machine:

  1. Code for a bit
  2. Think for a bit
  3. Repeat steps 1 and 2 for a bit
  4. special make
    1. git commit; git push on client
    2. git pull on server
    3. regular make on server
    4. if compile failed, send back errors and return to 2
    5. send back executable
  5. Run executable
  6. Return to step 2

An even fancier implementation might try to keep the changing files in sync during idle time in step 2.

I guess this is assuming my executable is relatively small. Here dynamic (shared) libraries would be especially handy.

Tricking latexmk into using -draftmode

Thursday, June 12th, 2014

A friend recently showed me latexmk, an alternative to my current setup of using make to compile complicated tex documents (calling bibtex and pdflatex). Latexmk seems cool because it’s really tracking all the dependencies and not just recompiling everything. However, it seems to always run pdflatex in “final draft” mode, even for early passes which might as well use the -draftmode option. On my thesis (218 page document with figures on roughly every other page), this meant latexmk took 50s and my makefile routine took 23s (assuming a cold start).

I guess the sad answer is that it’s impossible to know if the current run of pdflatex should be the last (and hence should not be using -draftmode). So I guess latexmk plays it safe and runs everything without -draftmode.

My makefile assumes that I only ever need 3 passes, which I guess is pretty common but by no means universal.

I came up with gnarly alternative, which almost needs a makefile itsel:

latexmk -f -pdf -pdflatex="touch thesis.pdf && pdflatex -draftmode" thesis.tex && rm thesis.pdf && latexmk -pdf thesis.tex

First it runs latexmk forcing pdflatex to use -draftmode, but also always touching the pdf so latexmk is convinced that it succeeded in making its targets, then before running a final pass with latexmk I need to remove the pdf so that latexmk thinks there’s something to do. Draftmode passes cost very little so this also runs at about 24s on my thesis.

Wonder if there’s a cleaner way. Especially if thesis.pdf could be inferred nicely from thesis.tex (I guess using basename) and whether I can safely wrap this into an alias:

alias latexmk="..."

Update: Here’s a better version, my friend came up with. It still needs the tex filename twice, but at least it’s using substitution in the pdflatex “command” and the -g option forces latexmk to run at least once.

latexmk -f -pdf -pdflatex='pdflatex -draftmode %O %S && touch %D' thesis && latexmk -pdf -g thesis

Compiling and running the nVidia dual depth peeling example on Mac OS X

Friday, September 27th, 2013

Achieving order-independent transparency is one of the biggest embarrassments to real-time graphics. We want something like:


But instead we often resort to complicated, dirty hacks, expensive sorting with isn’t even correct, or giving up and living with ugly order-dependent alpha blending.

There are a few good ways to do it right and “Order Independent Transparency” and the follow-up “Order Independent Transparency with Dual Depth Peeling” are clever solutions.

Dual depth peeling demo running on mac

I finally managed to get there 2008(!) demo code running on my iMac (with AMD Radeon HD 6970M OpenGL Engine) running Mac OS X 10.7. This is quite a feat considering the OpenGL support on my machine is circa 1999.

Here are the steps to get this demo running. Download the source code.

Travel to the source directory

cd dual_depth_peeling/OpenGL/src/dual_depth_peeling

and create a Makefile with:

.PHONY: all


all: obj dual_depth_peeling

CFLAGS += -O3 -Wall -DNDEBUG -Winvalid-pch -m64 -fopenmp -msse4.2

CPP_FILES=$(wildcard *.cpp)
OBJ_FILES=$(addprefix obj/,$(notdir $(CPP_FILES:.cpp=.o)))

NVIDIA_COMMON_INC=-I../../common/include/ -I../../common/nvModel/include

OPENGL_LIB=-framework OpenGL
GLUT_LIB=-framework GLUT


dual_depth_peeling: $(OBJ_FILES)
    ${CXX} $(CFLAGS) -o $@ $(OBJ_FILES) $(LIB)

    mkdir -p obj

obj/%.o: %.cpp %.h
    ${CXX} $(CFLAGS) -o $@ -c $< $(INC) 

obj/%.o: %.cpp
    ${CXX} $(CFLAGS) -o $@ -c $< $(INC)

    rm -f $(OBJ_FILES)
    rm -f dual_depth_peeling

Before making we need to fix some bugs and compiler issues in the included math code. My edits are of the form:

// Alec
// Original code
New code

In nvMatrix.h:

// Alec
//for (int i = 0; i < 4; i++) v[i] = element(i,r);
for (int i = 0; i < 4; i++) v[i] = element(i,c);

In nvQuaternion.h

// Alec
//mult_vec(vec3(src_and_dst), src_and_dst);
mult_vec(vec3<T>(src_and_dst), src_and_dst);


// Alec
//vec3 axis;
vec3<T> axis;


// Alec
//return  &q[0];
return  &_array[0];


// Alec
//q0 = q[0];
//q1 = q[1];
//q2 = q[2];
//q3 = q[3];
q0 = _array[0];
q1 = _array[1];
q2 = _array[2];
q3 = _array[3];


  // Alec
  //vec3 v;
  vec3<T> v;

In nvShaderUtils.h and other files later replace

#include <GL/glew.h> 


// Alec
#ifdef __APPLE__
#include <OpenGL/GL.h>
#include <GL/glew.h>

In nvVector.h there are a bunch of lines that look like:

T::value_type ...

which produce errors like

../../common/include/nvVector.h:681:5: Error: error: need 'typename' before 'T:: value_type' because 'T' is a dependent scope

replace these lines with something like

typename T::value_type ...


// Alec
//return *this;
return lhs;

The Makefile we wrote is setup not to use the included nvModel.h. The original demo only included the header and a binary. Instead I got the header and cpp files: nvModel.h,, and from this random website I found by googling “nvModel.cpp”. Download those files into dual_depth_peeling/OpenGL/src/dual_depth_peeling and rename the *.cc files into *.cpp.

Go back to dual_depth_peeling/OpenGL/src/dual_depth_peeling and find and replace lines like

#include <GL/glew.h>
#include <GL/glut.h>


// Alec
#ifdef __APPLE__
#include <OpenGL/GL.h>
#include <GLUT/glut.h>
#include <GL/glew.h>
#include <GL/glut.h>

and change the include to find our new nvModel.h

// Alec 
//#include <nvModel.h>
#include "nvModel.h"

In dual_depth_peeling.cpp change the following lines:

        // Alec
        //glTexImage2D(GL_TEXTURE_RECTANGLE_ARB, 0, GL_FLOAT_RG32_NV, g_imageWidth, g_imageHeight,
        glTexImage2D(GL_TEXTURE_RECTANGLE_ARB, 0, GL_RG32F, g_imageWidth, g_imageHeight,


        // Alec


// Alec


                //g_opacity = max(g_opacity, 0.0);
                g_opacity = std::max(g_opacity, 0.0f);


                //g_opacity = min(g_opacity, 1.0);
                g_opacity = std::min(g_opacity, 1.0f);

and put and ifndef around the glew stuff

#ifndef __APPLE__
        if (glewInit() != GLEW_OK)
                printf("glewInit failed. Exiting...\n");

    if (!glewIsSupported( "GL_VERSION_2_0 "
                          "GL_ARB_texture_rectangle "
                                                  "GL_ARB_texture_float "
                                                  "GL_NV_float_buffer "
                          "GL_NV_depth_buffer_float "))
        printf("Unable to load the necessary extensions\n");
                printf("This sample requires:\n");
                printf("OpenGL version 2.0\n");

We’re almost done. If you now issue:


You’ll see that it compiles and runs but it fails to compile the shaders. So now we fix compatibility issues with the shaders. Comment any extension lines like this:

// Alec
//#extension ARB_draw_buffers : require

and change any sampleRECT and textureRECT lines like this

// Alec
//uniform samplerRECT TempTex;
uniform sampler2DRect TempTex;

and this

    // Alec
    //gl_FragColor = textureRect(TempTex, gl_FragCoord.xy);
    gl_FragColor = texture2DRect(TempTex, gl_FragCoord.xy);

Fix any issues with comparisons between floats and ints like this:

    // Alec
    //if (gl_FragColor.a == 0) discard;
    if (gl_FragColor.a == 0.0) discard;

Finally fix problems with operations not acting on vec3 and vec4 like this:

    // Alec
    //gl_FragColor.rgb = frontColor + backColor * alphaMultiplier;
    gl_FragColor.rgb = frontColor.rgb + backColor * alphaMultiplier;

also in shaders/shade_fragment.glsl swap fmod for mod like this:

    //color.rgb = (fmod(i, 2.0) == 0) ? vec3(.4,.85,.0) : vec3(1.0);
    color.rgb = (mod(i, 2.0) == 0.0) ? vec3(.4,.85,.0) : vec3(1.0);

That ought to do it. Looking through the code this probably won’t be the absolute easiest thing to integrate into my apps, but I’m happy to finally really see something that works on my own machine.

Here’s a table of the results. It compares this method to two naive methods for order independent alpha blending: averaging and summing. Those naive methods have obvious flaws.

Dual depth peeling compared to averaging and summing
Update: To skip all these steps and just trust me. Download my edited source.

Compiling and running qslim on Mac OS x

Thursday, May 23rd, 2013

I recently successfully compiled and executed qslim on mac os x. It took a little tweaking but here’s how I did it.


Before anything else, be sure to install fltk. I did this using macports:

sudo port install fltk


Then, following the instructions in qslim-2.1/README.txt, I first compiled libgfx:

cd libgfx

The libpng support seems out of date and I don’t really need it so in raster-png.cxx I replaced:

//#ifdef HAVE_LIBPNG
#if false

memcopy was shoing up undefined so I added the following include to raster.cxx:

#include <cstring>

Similarly there was a missing include in time.cxx:

#elif defined(HAVE_TIMES)
#include <sys/times.h>

Know, while inside libgfx I issue:

make -C src


First travel inside mixkit and configure:

cd ../mixkit

Trying to make I got a bunch of errors of the form:

MxDynBlock.h:44:33: Error: 'resize' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
MxDynBlock.h:44:33: Error: note: declarations in dependent base 'MxBlock<MxStdModel*>' are not found by unqualified lookup
MxDynBlock.h:44:33: Error: note: use 'this->resize' instead

There’re at least two ways to fix this. You can add this-> everywhere gcc is tell you to: edit MxStack.h and MxDynBlock.h or you can add -fpermissive to the CXXFLAGS. This is awkwardly done not in mix-config but in ../libgfx/gfx-config. Where you can edit into something like:

CXXFLAGS = -g -O2  -I/Users/ajx/Downloads/qslim-2.1/libgfx/include -DHAVE_CONFIG_H $(WIN_FLAGS) -fpermissive

Alternatively you could have done this when configuring libgfx with:

cd ../libgfx
./configure CXXFLAGS='-fpermissive'
cd ../mixkit/

If you do it this way then you’ll get warnings instead of errors.

Now you can build with:

make -C src

qslim and qvis

Travel to the qslim tools directory:

cd ../tools/qslim

Here I need to add libfltk_gl to the linker commands in Makefile:

        $(CXX) -o qslim $(OBJS) $(LDFLAGS) $(LIBMIX) -lm -lfltk_gl
        $(CXX) -o qvis $(QVIS_OBJS) $(LDFLAGS) $(LIBMIX) $(GUI_LIBS) -lm -lfltk_gl

Then build with:


(those fpermissive warnings may show up again, but no problem)

Finally I can run the command line program qslim or the gui qvis. For some reason the qui immediately closes if I double click on it. But I can run it by issuing:


where I’m then prompted to load a .smf file.


./ input.smf

You can call the command line program with:

./qslim -t 1000 -M smf -q 2>/dev/null

which spills the .smf file to stdout

It seems .smf format is the same as .obj, at least if there are only vertices and triangular faces. So, you can compose—a rather long—bash oneliner that simplifies an input.obj file to an output.obj file:

grep "^[vf] " input.obj | sed -e "s/^f *\([0-9][0-9]*\)\/[^ ]*  *\([0-9][0-9]*\)\/[^ ]*  *\([0-9][0-9]*\)\/.*/f \1 \2 \3/g" | ./qslim -t 1000 -M smf -q 2>/dev/null | grep "^[vf]" > output.obj


I also built the “filters” (converters?) with:

cd ../filters

Note that ply2smf only acts on stdin and stdout so call it with:

cat input.ply | ./ply2smf >output.smf

Update: I found an easier way to setup the configure script and ensure that all macports libraries are found:

env CPPFLAGS="-I/opt/local/include -fpermissive" LDFLAGS="-L/opt/local/lib" ./configure

Correct sse flags for compiling against embree with gcc

Tuesday, May 14th, 2013

I had trouble compiling against the embree raytracing library. I first tried compiling a small test problem with gcc (g++-mp-4.7) and immediately got errors:

error: '_mm_abs_epi32' was not declared in this scope
error: '_mm_shuffle_epi8' was not declared in this scope
error: '_mm_abs_epi32' was not declared in this scope

I tried adding the gcc flag -msse to no avail. I tried -mavx I got tons of errors like:

/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:20:no such instruction: `vxorps %xmm0, %xmm0,%xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:21:no such instruction: `vmovaps %xmm0, __ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:22:no such instruction: `vmovss LC0(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:23:no such instruction: `vmovaps %xmm0, 16+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:24:no such instruction: `vmovaps LC1(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:25:no such instruction: `vmovaps %xmm0, 32+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:26:no such instruction: `vmovaps LC2(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:27:no such instruction: `vmovaps %xmm0, 48+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:28:no such instruction: `vmovaps LC3(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:29:no such instruction: `vmovaps %xmm0, 64+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:30:no such instruction: `vmovaps LC4(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:31:no such instruction: `vmovaps %xmm0, 80+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:32:no such instruction: `vmovaps LC5(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:33:no such instruction: `vmovaps %xmm0, 96+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:34:no such instruction: `vmovaps LC6(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:35:no such instruction: `vmovaps %xmm0, 112+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:36:no such instruction: `vmovaps LC7(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:37:no such instruction: `vmovaps %xmm0, 128+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:38:no such instruction: `vmovaps LC8(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:39:no such instruction: `vmovaps %xmm0, 144+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:40:no such instruction: `vmovaps LC9(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:41:no such instruction: `vmovaps %xmm0, 160+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:42:no such instruction: `vmovaps LC10(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:43:no such instruction: `vmovaps %xmm0, 176+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:44:no such instruction: `vmovaps LC11(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:45:no such instruction: `vmovaps %xmm0, 192+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:46:no such instruction: `vmovaps LC12(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:47:no such instruction: `vmovaps %xmm0, 208+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:48:no such instruction: `vmovaps LC13(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:49:no such instruction: `vmovaps %xmm0, 224+__ZL17_mm_lookupmask_ps(%rip)'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:50:no such instruction: `vmovaps LC14(%rip), %xmm0'
/var/folders/6g/l7c387896dz565996h9tz6d40000gn/T//ccZ5EWof.s:51:no such instruction: `vmovaps %xmm0, 240+__ZL17_mm_lookupmask_ps(%rip)'

Finally I looked into the commands embree’s makefile was issuing to compile it in the first place and found the correct flag: -msse4.2.

MATLAB mex file with boost (e.g. when using CGAL)

Friday, December 7th, 2012

On my laptop I have MATLAB2011b and I was able to compile a mex function using CGAL (and by dependency boost), just fine. When I tried this code on my iMac at work, the code compiled fine, but at runtime matlab crashed somewhere deep inside Cgal and boost:

[  0] 0x00000001000e4e46 /Applications/ _ZN2fl4diag15stacktrace_base7captureERKNS0_14thread_contextEm+000150
[  1] 0x00000001000e5af1 /Applications/ fl_diag_terminate+000321
[  2] 0x00000001000e7c34 /Applications/ _ZN2fl4diag13terminate_logEPKcRKNS0_14thread_contextE+000100
[  3] 0x00000001008e125e /Applications/ mnTrapCtrlc+000254
[  4] 0x00000001008e2d24 /Applications/ _Z32mnRunPathDependentInitializationv+003492
[  5] 0x00000001008e313d /Applications/ _Z32mnRunPathDependentInitializationv+004541
[  6] 0x00000001008e37f5 /Applications/ _Z32mnRunPathDependentInitializationv+006261
[  7] 0x00000001008e3aa1 /Applications/ mnSIGABRTHandler+000129
[  8] 0x00007fff90d64cfa                  /usr/lib/system/libsystem_c.dylib+00666874 _sigtramp+000026
[  9] 0x00007fff6332b6f8                  /usr/lib/system/libsystem_c.dylib+18446744072944523000
[ 10] 0x00007fff90d03a7a                  /usr/lib/system/libsystem_c.dylib+00268922 abort+000143
[ 11] 0x0000000121634c3e              /opt/local/lib/gcc43/libgcc_s.1.dylib+00060478 uw_init_context_1+000142
[ 12] 0x0000000121635058              /opt/local/lib/gcc43/libgcc_s.1.dylib+00061528 _Unwind_Resume+000072
[ 13] 0x000000012106e2da /Users/ajx/Documents/volume/matlab/peeling/peeling.mexmaci64+00045786 mexFunction+001450
[ 14] 0x000000010550deca /Applications/ mexRunMexFile+000090
[ 15] 0x0000000105509a29 /Applications/ _ZN7Mfh_mex30runMexFileWithSignalProtectionEiPP11mxArray_tagiS2_+000137
[ 16] 0x000000010550b038 /Applications/ _ZN7Mfh_mex13dispatch_fileEiPP11mxArray_tagiS2_+000232
[ 17] 0x00000001009dab43 /Applications/ _ZN8Mfh_file11dispatch_fhEiPP11mxArray_tagiS2_+000499
[ 18] 0x0000000100d8b5b2 /Applications/ _ZN20ResolverFunctionDesc12CallFunctionEiPP11mxArray_tagiS2_+000914
[ 19] 0x0000000100d9287f /Applications/ _ZN8Resolver13CallMFunctionEiiP10_m_operandP17m_operand_storageiS1_S3_Pi+001679
[ 20] 0x0000000100d934e6 /Applications/ _Z22inResolveMFunctionCallP16_m_function_desciiP10_m_operandP17m_operand_storageiS2_S4_PiP13inMarshalTypeiPK19mpsTypeSequenceNlhsPFP11mxArray_tagiE+000598
[ 21] 0x0000000100bc9b4f /Applications/ _ZN9accelImpl13MFunctionCallEPP8_accelOp+000527
[ 22] 0x0000000100bf4b7e /Applications/ _ZN9accelImpl4ExecEv+000286
[ 23] 0x0000000100bf4c3b /Applications/ _ZNK9accelCode4CallEP13inMarshalTypePi+000091
[ 24] 0x0000000100d39f16 /Applications/ _ZN5inJit17ExecuteHotSegmentEP15_inJitAccelInfoP7opcodesPiPl+001654
[ 25] 0x0000000100b24361 /Applications/ _Z16inEnterDebugModeN5boost8functionIFvvEEEb+012273
[ 26] 0x0000000100b29c1c /Applications/ _Z18protected_inInterp12inDebugCheckii7opcodesPV15inPcodeNest_tagPl+000140
[ 27] 0x0000000100b2614e /Applications/ _Z16inEnterDebugModeN5boost8functionIFvvEEEb+019934
[ 28] 0x0000000100b27630 /Applications/ _Z26inExecuteMFunctionOrScriptP6Mfh_mpb+000688
[ 29] 0x0000000100b9482a /Applications/ _Z10inRunMfileiPP11mxArray_tagiS1_P6Mfh_mpP15inWorkSpace_tag+001530
[ 30] 0x00000001009dab43 /Applications/ _ZN8Mfh_file11dispatch_fhEiPP11mxArray_tagiS2_+000499
[ 31] 0x0000000100b76a5a /Applications/ _Z19inDispatchFromStackiPKcii+001034
[ 32] 0x0000000100b02979 /Applications/ inCallFcnFromReference+000265
[ 33] 0x0000000100b23125 /Applications/ _Z16inEnterDebugModeN5boost8functionIFvvEEEb+007605
[ 34] 0x0000000100b29c1c /Applications/ _Z18protected_inInterp12inDebugCheckii7opcodesPV15inPcodeNest_tagPl+000140
[ 35] 0x0000000100b2614e /Applications/ _Z16inEnterDebugModeN5boost8functionIFvvEEEb+019934
[ 36] 0x0000000100b27630 /Applications/ _Z26inExecuteMFunctionOrScriptP6Mfh_mpb+000688
[ 37] 0x0000000100b9482a /Applications/ _Z10inRunMfileiPP11mxArray_tagiS1_P6Mfh_mpP15inWorkSpace_tag+001530
[ 38] 0x00000001009dab43 /Applications/ _ZN8Mfh_file11dispatch_fhEiPP11mxArray_tagiS2_+000499
[ 39] 0x0000000100b62904 /Applications/ _Z23inEvalPcodeHeaderToWordP15_memory_contextiPP11mxArray_tagP12_pcodeheaderP6Mfh_mpj+000260
[ 40] 0x0000000100b1c162 /Applications/ _Z25in_local_call_with_setjmpIN5boost3_bi6bind_tIvPFvP15_memory_contextPiPP11mxArray_tagP12_pcodeheaderjENS1_5list5INS1_5valueIS4_EENS0_3argILi1EEENSG_ILi2EEENSE_ISA_EENSE_IiEEEEEEE17inExecutionStatusT_S5_S8_b+000082
[ 41] 0x0000000100b187f5 /Applications/ _ZN7EvalLog6setLogEiPP11mxArray_tagiS2_+003381
[ 42] 0x0000000100b18b75 /Applications/ _ZN7EvalLog6setLogEiPP11mxArray_tagiS2_+004277
[ 43] 0x000000010640058e /Applications/ _Z28evalCommandWithLongjmpSafetyPKc+000094
[ 44] 0x0000000106400d8b /Applications/ _Z28evalCommandWithLongjmpSafetyRKSbItSt11char_traitsItESaItEE+000043
[ 45] 0x000000010640181d /Applications/ _Z8mnParserv+001021
[ 46] 0x00000001008c4139 /Applications/ _ZN11mcrInstance30mnParser_on_interpreter_threadEv+000041
[ 47] 0x000000010089e76b /Applications/ _ZN3mcr7runtime17InterpreterThread4Impl17InvocationRequest3runEv+000523
[ 48] 0x000000010089e925 /Applications/ _ZN3mcr7runtime17InterpreterThread4Impl26invocation_request_handlerEl+000053
[ 49] 0x000000010042f574 /Applications/ _ZN10eventqueue18UserEventQueueImpl5flushEv+000756
[ 50] 0x000000010042f79a /Applications/ _ZN10eventqueue8ReadPipeEib+000026
[ 51] 0x000000010042df26 /Applications/ _ZN10eventqueue18UserEventQueueImpl9selectFcnEb+000326
[ 52] 0x0000000107d26a9d /Applications/ _ZN21uix_nodisplay_ppeHook16pollingDuringFcnEb+000045
[ 53] 0x00000001004d71b2 /Applications/ _ZSt8for_eachIN9__gnu_cxx17__normal_iteratorIPN5boost8weak_ptrIN4sysq10ws_ppeHookEEESt6vectorIS6_SaIS6_EEEENS4_8during_FIS6_NS2_10shared_ptrIS5_EEEEET0_T_SH_SG_+000162
[ 54] 0x00000001004d8dab /Applications/ _ZN4sysq12ppe_for_eachINS_8during_FIN5boost8weak_ptrINS_10ws_ppeHookEEENS2_10shared_ptrIS4_EEEEEET_RKS9_+000203
[ 55] 0x00000001004d592c /Applications/ _ZN4sysq19ppePollingDuringFcnEb+000092
[ 56] 0x00000001004d5ac7 /Applications/ _ZN4sysq11ppeMainLoopEiib+000119
[ 57] 0x00000001004d5c94 /Applications/ _ZN4sysq11ppeLoopIfOKEiib+000132
[ 58] 0x00000001004d5e34 /Applications/ _ZN4sysq20processPendingEventsEiib+000132
[ 59] 0x000000010089ea9f /Applications/ _ZN3mcr7runtime17InterpreterThread4Impl14process_eventsERKN5boost10shared_ptrIS2_EE+000223
[ 60] 0x000000010089f2ca /Applications/ _ZN3mcr7runtime17InterpreterThread4Impl3runERKN5boost10shared_ptrIS2_EEPNS2_12init_contextE+000282
[ 61] 0x0000000100897176 /Applications/ _Z26run_init_and_handle_eventsPv+000054
[ 62] 0x00007fff90d108bf                  /usr/lib/system/libsystem_c.dylib+00321727 _pthread_start+000335
[ 63] 0x00007fff90d13b75                  /usr/lib/system/libsystem_c.dylib+00334709 thread_start+000013

At first I thought it was a problem of compiling against the CGAL that came with macports rather than a version inside on matlab. But actually it seems matlab no longer contains the libCGAL libraries. I did however see the boost libraries there. When I checked the libraries of my mex file using:

otool -L myfunction.mexmaci64

I saw:

	/opt/local/lib/libCGAL.10.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libCGAL_Core.10.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libgmp.10.dylib (compatibility version 11.0.0, current version 11.5.0)
	/opt/local/lib/libmpfr.4.dylib (compatibility version 6.0.0, current version 6.1.0)
	/opt/local/lib/libboost_thread-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmx.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmat.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmex.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.17.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
	/opt/local/lib/gcc47/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

libboost_*-mt are the boost libraries that come from macports. Inside of matlab these are just libboost_* (without the -mt). After switching my make file to link against these:

-L$MATLAB/bin/maci64/ -lboost_thread -lboost_system

I used otool again and confirmed that I linked against matlab’s boost:

	/opt/local/lib/libCGAL.10.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libCGAL_Core.10.dylib (compatibility version 10.0.0, current version 10.0.0)
	@rpath/libgmp.3.dylib (compatibility version 8.0.0, current version 8.1.0)
	@rpath/libmpfr.1.dylib (compatibility version 3.0.0, current version 3.2.0)
	@rpath/libboost_thread.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmx.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmat.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmex.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.17.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
	/opt/local/lib/gcc47/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

I tried running my mex file and indeed this worked.

Update: This also happens when calling mex directly. Somehow matlab still finds the wrong boost libs.

Bash script to find best number of threads for make’s -j option

Friday, November 16th, 2012

The make command lets you specify a number of processes to run commands on using the -j option. I’ve read of a heuristic to use 1.5 times the number of cores on your machine. To find out if this is true I wrote a short script:


for i in {1..20}
  make clean &>/dev/null
  printf "$i  "
  t=`(time make -j$i &>/dev/null) 2>&1 | grep real | sed -e "s/real[^0-9]*//g"`
  echo "$t"

For my project on my iMac with an intel i7 this prints:

1  1m1.235s
2  0m32.128s
3  0m23.353s
4  0m19.989s
5  0m18.007s
6  0m16.613s
7  0m15.490s
8  0m15.644s
9  0m16.307s
10  0m16.415s
11  0m16.861s
12  0m17.535s
13  0m17.053s
14  0m17.112s
15  0m17.550s
16  0m17.267s
17  0m17.274s
18  0m17.618s
19  0m17.540s
20  0m17.653s

Obviously you could improve the accuracy of these timing by running multiple times and averaging.

Porting Marco Attene’s meshfix to mac os x

Wednesday, November 14th, 2012

Short notes on porting meshfix to mac. Follow readme.txt placing downloaded OpenNL and JMeshLib directories in the mesh fix directory [same as meshfix.cpp] When compiling JMeshLib be sure in makeconf file to change the lines:

# On 64-bit machines you need to uncomment the following line




When compiling JMeshExt I separated the predicates.cxx file from tetgen’s source to make jrs_predicates.h and jrs_predicates.c. Placing them according to readme.txt. One note is that if jrs_predicates.c is to be a .c file rather than a .cpp file then you need to extern "C"{...} encapsulate the jrs_predicates.h header file or you will get Undefined symbol linker errors. Finally in JMeshExt and meshfix.cpp there are several casts of pointers to ints. This won’t compile on 64-bit machines. This similar operation was fixed in JMeshLib by the -DIS64BITPLATFORM. Thus, I’ve fixed the following files to use the j_voidint typedef defined by IS64BITPLATFORM in j_mesh.h:


I’ve zipped up my changes and organization: download package. Then you can just issue:

cd OpenNL3.2.1/
# # You might need to do:
# export CC=`which cc`
# export CXX=`which c++`
make -C build/Darwin-Release/
cd ../JMeshLib-1.2/
cd ../JMeshExt-1.0alpha_src/
cd ..

I imagine a very similar port could be used for Linux.

Update: I started occasionally getting runtime errors:

OpenNL should not have reached this point: file:/Users/ajx/Downloads/MeshFix/OpenNL3.2.1/src/NL/nl_superlu.c, line:223
Abort trap: 6

Seems this comes from compiling OpenNL without SuperLU support. SuperLU is fairly straightforward to install and so is following the OpenNL instructions for compiling with OpenNL support.