Thursday, 20 August 2009

Matlab: Mex example in C way

There is a yprime.c for mex in Matlab. Here I translate to C, in order to understand mex better.

#include <math.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
static void yprime(
double* yp,
double* y
double r1,r2;

double mu = 1/82.45;
double mus = 1 - 1/82.45;

r1 = sqrt((y[0]+mu)*(y[0]+mu) + y[2]*y[2]);
r2 = sqrt((y[0]-mus)*(y[0]-mus) + y[2]*y[2]);

yp[0] = y[1];
yp[1] = 2*y[3]+y[0]-mus*(y[0]+mu)/(r1*r1*r1)-mu*(y[0]-mus)/(r2*r2*r2);
yp[2] = y[3];
yp[3] = -2*y[1] + y[2] - mus*y[2]/(r1*r1*r1) - mu*y[2]/(r2*r2*r2);

int main(){
double yo[4];
double yi[4] = {100, 2, 3, 4};

yprime(yo, yi);
printf("print out %f",yo[0]);

// some conversion practice
double a = yi[0];
char t1[7],t2[8],t3[8];

*t1= (char) a;

printf(strcat(t1, t2));


// i = sprintf(str, "%d", 15); //for interger to string

return 0;

Sunday, 16 August 2009

HOWTO: compile objective-c using gcc in Linux

to compile these examples of objective-c (install libobjc first) from objective-c on

1) traditional:
gcc -c XX.m XXX.m -Wno-import
gcc -o prog XX.o XXX.o -lobjc -Wno-import

2) gcc *.m -lojbc -Wno-import

-Wno-import is because the maintainer of gcc doesn't like 'import';

-lobjc: -l(library) -L(libaray directory) -lobjc(for GNU objective-c libraray)

For those examples using GNUstep, most of the header files need to be changed from ' #import ' to '#import ' to suit the GNU objective-c library.

More details:

Monday, 3 August 2009

HOWTO: Version control using BZR vs RCS

No matter programming or documents editing, BZR will work for you to provide easier and better version control.

Here are some simple steps for docs processing:

  1. bzr init
    create a folder, 'text', then create a file, 'test1.txt', in which we type in a paragraph. Then 'bzr init' to let bzr know this is the folder where bzr should monitor.
  2. bzr add
    'bzr add test1.txt'. Now bzr knows where and what to monitor.
  3. bzr diff
    add more text into the test1.txt, then run 'bzr diff' to test whether there is any changes.
  4. bzr commit -m 'description'
    if there are some changes, and you want to create another version for that for the current version backup. run 'bzr commint -m "some description"'.
  5. bzr log
    to check verisons.
    more changes and more commits here.
  6. bzr branch -r
    For example we just want to retrive the first version, run 'bzr branch `pwd` -r 1'. A new folder with the name of current folder 'text' will be created, in which our text1.txt 1st version is there.
RCS: (same procedure)
  1. create folder RCS
    this step can be ignored, the rcs information will be saved in the same folder with the file you are editing. Otherwise, the file info file will be saved in the RCS folder.
  2. ci -u test1.txt
    ver 1.1 is created. RCS uses the concept of 'lock'. -l -r -u are similar, to keep the text file locked when new version is registered.
  3. co -l test1.txt
    (if without this step, new version can not be registered. because 'no lock', prompted by 'ci', is this for synchronization?) So to lock the text file to make it writable (very weird concept, locked == writable???). Then add more text in it.
  4. rcsdiff test1.txt
    To check what's different from the registered version.
  5. ci -u test1.txt (same with step2)
    The version number increment with 0.1.'ci -r2 -u test1.txt' to make the version increment by 1.0.
    more changes and more commits here.
  6. co -l1.1 test1.txt
    Retrive version 1.1 to replace the current editing file. -l -r -u are similar, just -u makes the file non-writeable, while -l make the file writeable. Good practice is 'ci -u' and 'co -l', so that when the new version is registered by ci, the file will become 'non-writable'='can not modify'='No lock'. (weired)
Note: no space between '-r2' and '-u1.1'.

BZR is more user friendly, and Ubuntu uses it on
RCS is quite mature (old), LYX uses it as version control. So even I don't like it, but I have to still use it, because I love Lyx.

Sunday, 2 August 2009

HOWTO: autoconf & automake HELLO WORLD

1) Create sources, “”
2) `autoscan`:create configure.scan
3) Rename “configure.scan” to “”
4) `autoheader`:create for automake
5) Add AM_INIT_AUTOMAKE to “”, just after AC_INIT()
6) `aclocal`:create necessary macros in aclocal.m4 for automake.
7) `automake ­­--add-­missing --­­copy`: create from
8) `autoconf`:create configure
9) `./configure`:check and create Makefile
10) `make`
11) `make install`

if you modify your source...
1) Run `autoscan` again
2) Compare configure.scan with
* Update
3) Run `autoreconf`

# for hello.c

To simplify it:
1) c/cc files,
2) autoscan => mv configure.scan => add Add AM_INIT_AUTOMAKE after AC_INIT

3) autoheader
4) aclocal
5) automake

6) autoconf <=> autoscan,(compare,autoreconf

7) ./configure && make && make install

Simplest 'make'

int main(int argc, char* argv[])
printf("Hello, world!\n");
return 0;

# Makefile: A standard Makefile for hello.c
all: hello
clean: rm -f hello
Run: make, to create executable bin file.

HOWTO: autoconf & automake

  1. Write templates.
  2. Write
    2.1 Use autoscan to generate a template.
    2.2 Specialize the generated configure.scan to suit your project.
    2.3 Rename configure.scan to
  3. Run automake to generate from (automake scans to find out more about the project).
  4. Run aclocal to make local copies of all autoconf macros. These macros are then included in the project.
  5. Run autoconf to generate configure.


automake, when used in conjunction with autoconf, makes creating Makefiles easy. automake operates on a to generate . is then processed by the configure script to generate Makefile. has macros that are processed by automake. A sample is shown below. Variables surrounded by @'s are automatically propagated without change to The configure script, when parsing into Makefile, makes the necessary substitutions (for example, @LDFLAGS@ may get expanded to "-lm -lthread).
        bin_PROGRAMS = gpstat
        gpstat_SOURCES = about.c interface.c multi-plot.c attach_process.c
        gpstat_LDFLAGS = @LDFLAGS@ @GTK_LIBS@ -lgthread

automake knows the rules to create object files and executables for the platform it is running on. The above sets of macros tell automake that:
1. The final executable is to be named gpstat. 
2. The sources for gpstat are the value of gpstat_SOURCES. 
3. Add @LDFLAGS@, @GTK_LIBS@, and -lgthread to the link line. (The configure script will replace LD_FLAGS and GTK_LIBS with their proper values.) 
4. Include the variable $INCLUDES in the compilation line.



The configure script is generated from using autoconf. is a normal text file that contains several autoconf macros. These macros specify what tests to carry out. General uses of the configure script include:
1. Find machine information (Hostname, version...). 
2. Find the path to a particular program (bison, lex, ...). 
3. Find out if a tool supports a feature (for example, if the compiler supports bool). 
4. Check if the required libraries are available on your system. 
5. Process to generate Makefile.


automake also provides autoscan, a utility script that will help you create a template autoscan scans the program sources and adds suitable macros to It creates configure.scan, which then should be renamed, after making suitable modifications.
automake also provides a program called aclocal. aclocal makes local copies of all autoconf macros, so that other developers can modify the file.

You can combine the invocation of automake, aclocal, and autoconf as follows:
foo@pastwatch$ aclocal&& automake && autoconf

Comments can either begin with dnl or a #. The following is a small, well-documented, self-explanatory file.
dnl Process this file with autoconf to produce a configure script.
dnl notice how comments are preceded by "dnl"
# comments can also begin with a #
dnl This macro is a must, and this tests if the configure
dnl script is running in the correct directory
dnl This macro tells the configure script to put
dnl "defines" in a file rather than the command line.
dnl get the flags
dnl this macro is used to get the arguments supplied
dnl to the configure script (./configure --enable-debug)
dnl Check if we have enable debug support.
AC_MSG_CHECKING(whether to enable debugging)
AC_ARG_ENABLE(debug, [ --enable-debug=[no/yes] turn on debugging
[default=$debug_default]],, enable_debug=$debug_default)
dnl Yes, shell scripts can be used
if test "x$enable_debug" = "xyes"; then
CFLAGS="$CFLAGS -O3 -ffast-math -mcpu=v8 -mtune=ultrasparc"
dnl tells us that we require autoconf with version greater than
dnl 2.12 to generate configure
dnl get system information
dnl Since foo is currently untested on any os other
dnl than solaris, so check the os and quit if not solaris.
UNSUPPORTED_OS="FOO is currently unsupported on your platform.
If you are interested in making it work on your platform, you are
more than *welcome*. Contact for details."
case "${target_os}" in
echo ===========================================================
echo Setting up build environment for ${target_cpu}${target_os}
echo ===========================================================

# Build time sanity check...
dnl get path to install program
dnl initialize automake
dnl Checks for c compiler.
dnl check for standard c headers
dnl export these variable (so Makefile substitutions
dnl can be made.
dnl Checks for libraries.
dnl AC_CHECK_LIB(gthread, g_thread_init)
dnl AC_CHECK_LIB(pthread, pthread_create)
dnl Check for /proc
find /proc. See the file 'README' for help.))
dnl check for procfs.h
find procfs.h. See the file 'README' for help.))
dnl Checks for header files.
dnl Checks for typedefs, structures, and compiler characteristics.
dnl Create these files, making substitutions if necessary

My photo
London, United Kingdom

Facebook & Twitter