Bye blogspot

You should be redirected to http://hugopl.github.io/

Embedding Ruby 2.1 into a C++ application

I'm writing this as a reminder to myself, first of all because there is no documentation about how to embedded Ruby into a C++ application despite of the Ruby interpreter source files, secondly because when you start a sentence saying "first.." you need a second sentence saying "secondly...".

The fast way to explain what you need to do:

#include <ruby.h>

int main()

{
    // Init ruby VM.
    ruby_init();
    // You need this if you plan to load some modules using require.
    ruby_init_loadpath();

    const char*  options[]  =  { "", "-enil", 0 };
    ruby_exec_node(ruby_options(2, const_cast<char>(options)));

    const char rubyCode[] = "my nice ruby code here";
    int result;
    rb_eval_string_protect(rubyCode, &result);
    if (result)
        return 1; // An exception was thrown.

    ruby_cleanup(0);
    return 0;
}

ruby_options receive argc/argv as parameters, they are used like the Ruby interpreter would do, a void pointer is returned. The void pointer returned is a Node, it represents the Ruby code compiled and ready to run.

Notice "-enil", if you don't pass any argument the Ruby VM will crash without further explanation. In my example I want to execute some Ruby code located into a string, not a separated file, so I can't pass the file path into options array because there's no file, so -enil says "Execute this code: 'nil'".

You can use the void pointer returned by ruby_options into two functions, ruby_run_node and ruby_exec_node, the difference is that ruby_run_node executes the node then clean up the VM, so any other call to the Ruby C-API will cause a crash, ruby_exec_node just execute the node and keeps the VM alive for a future use.

Now with all in place, you can call rb_eval_string_protect to execute some ruby code and all other rb_* functions found on ruby.h to do whatever do you want, at least those rb_* functions have some documentation into README.EXT file found on Ruby source code.

Dear WebKit, I can commit now!

After some months I finally got the committer rights on WebKit project :-), my first commit of course was the most traditional one, add myself on commiters.py :-P, hope to do more useful commits in a near future :-).

Iceberg!

Dear icecream users and KDE haters,

Don't include myself in this group, I'm a long time KDE user and I don't hate it despite of some annoying bugs, but I'm a heavy icecream user anyway :-).

What I have to say isn't exactly about icecream, but about icemon, the nice GUI used to monitor icecream networks. But what's wrong with it? Nothing! I'm a KDE user and the KDE dependency doesn't bother me at all, but days ago tired of listen people (non-KDE users) complaining about the KDE dependency I decided to stop with all this and strip the KDE dependency from icemon even if the final result wont provide much difference to me.

After 1 hour of work I could finally say: "Mission accomplished!" and went to tell some coworkers at INdT that they owe me some beers. Some commits later to polish the fork and done... the Qt version is identical to the KDE one but without the kdelibs dependency.

This new baby is now called Iceberg and lives happy on Git-Hub, the name was a suggestion from setanta, just a word similar to icemon, nothing special.

So if you use icecream and don't want to install kdelibs to see your icecream network, enjoy!

Meique released

By a release I mean, I tagged the git repository with some version number (0.8), so you still need to download the sources from git if you want to test it. I wont spend my free time to create a website nor distro packages very soon, because I think that for while is better to spend my time coding than creating cosmetic things for a tool not production ready yet.

Ah, I almost forgot to say, meique is a pet project of mine, result of my will to have a more than reasonable building tool for C and C++, a really good one. I'm doing it on my free time and hope to finish it some day, hehe.

Ok, back to the main subject, it's not production ready... by production ready I mean, if you want to use meique in a near future the best thing to do is to try to port your project to meique and report any bugs and wishes, so bugs can be fixed and wishes turned into reality.

So, what meique can do until now?

• Out of source builds.
• Find installed packages using pkg-config as backend.
• Support projects with multiple source directories.
• Decide if a file need to be recompiled by their contents, not by their timestamp.
• Multiple jobs at once.
• Detect the file dependencies and also use this information the decide if a file needs to be recompiled.
• Automatic creation of the following targets: all and clean (install and uninstall not done yet).
• Scopes for OS, compiler and build types, like the ones used in qmake.

What it can't do yet?

• Probably there are some (maybe many?) bugs, because I did only few tests and I'm still to lazy to convert my manual tests into automatic tests.
• There's no equivalent helper function to cmake configure_file function.
• There's no windows port yet, to create it is a matter of create an os_windows.cpp which implements the OS interface, i.e. few
functions inside a namespace (rm, mkdir, cd, pwd, etc).
• There's no install function yet, I need to think a good API for it to support Mac OSX frameworks, simple UNIX installs and the mess found in Windows systems, so I wont implement anything until I have a clear and simple API for it in my mind.
• Support for tests, something like the add_test function of cmake.
• Documentation! Currently the only documentation is the source code itself, mainly meiquescript.cpp and the meique.lua files used to compile meique itself.

How to get it and report bugs/wishes?

You can get the sources on gitorious (http://gitorious.org/meique). Compilation can be done using cmake or meique itself.

To report bugs and wishes write to hugo.pl at gmail.com.

Status report on "Save the universe" task

I'm talking about my pet project called meique, yes, this is yet another build tool.

The project is going a "bit" slow, I can summarize this situation in numbers, the project had 15 commits so far, 4 in 08/2009, 4 in 12/2009 and 7 in 04/2010. In other words, 4 commits, 4 months doing nothing, 4 commits, 4 months doing nothing, 7 commits, ...

As you can see there is a pattern in meique development, every commit represents 1 month doing nothing! But this isn't my fault, ok.. is my fault, anyway I want to break this pattern, no... no... I'm going to break this pattern!! at least I hope so.

Besides all development slow down I achieved some goals with those 15 commits:

• The basic architecture to provide the basic functionality is done, or almost done :-).
• Meique can now compile basic hello worlds \o/.

So what's missing and what's next?

Missing? A lot of things. My current implementation plan is:

• Implement the source directory structure replication, used to the separated build dir compilation feature.
• Create a very basic preprocessor, just to identify the dependencies of a C++ file on each run.
• Use md5 or a faster hash algorithm to identify when a file needs to be recompiled.
• Support multiple jobs, -jN option.
• Redo this list with four more items.

For anyone interested on meique, take a look at gitrotious project page.

Reinventing the wheel to save the universe!

I admit myself, I have a bit of the "Not written by me" syndrome, but I guess that this time this is not a side effect of this developer disease, it's just because every build tool in this planet sux in a way or another, so I decided to write my own build tool, yes... the build tool of my dreams!

Before start to talk about it, I like to answer why not X? why not Y? Ok, let's do it one by one.

Why not Autotools?

Go fuck yourself.... and GET OUT OF HERE!!!!

Why not qMake?

qMake is useful only for Qt-based projects, and IMHO, for the simple ones. Ok, Qt is a huge project and uses qMake, but did you ever found someone spreading good words about qMake? In other words, I never use qMake for my Qt projects, I use cmake instead.

Why not SCons?

SCons is somehow a good build tool, last time I used it was two years ago, I like the SCons bootstrap methodology but I dislike the python dependence, summarizing, IMHO CMake is better.

Why not CMake?

CMake is the best build tool nowadays, simple use cases remains simple and complex use cases are possible. I use it for all my projects, so I know that it's not perfect yet.

• CMake syntax is horrible and too verbose.
• CMake uses a declarative approach to describe the build process, despite of the declarative nature of the action of describe a project, many times when writing a custom target with CMake you think yourself "If I could use an imperative language, my life would be easier".
• CMake is big! 12MB is big!!
• You need cmake installed to compile a CMake project.

Why not X?

I don't know X, so X is too new or probably not so good :-), but if X is really good, just assume that what I'm doing is a side effect of the "Not written by me" syndrome.


Why not Meique?

Yes! Meique is perfect! Is the build tool of my dreams! the holy grail!! but it does not exists yet, the current source code still not useful, I'll push something to gitorious when it be able to compile the first Hello World.

Ok, so let's talk about my vapor ware, first the desired features.

• “Out of source” builds.
• Self-contained, small, no dependencies besides C++ standard library.
• Flexible, extensible and intuitive, uses Lua as scripting language, an imperative language!!
• You can bootstrap it! So you don't need it installed on your system to compile a project based on Meique.
• Integrated testing support (like ctest).

Meique isn't a meta-buildsystem like CMake, i.e. it doesn't generate files for native building tools like Makefiles, Visual Studio projects, etc. Meique itself call the compiler, take care of what should and what shouldn't be compiled, etc. This adds a bit more complexity to the project, but open the road for useful features like:

• Decides if a file needs to be compiled by their contents change, not just timestamp.
• A single behavior on all platforms.
• Update the file dependence list on-the-fly.
• I don't need to write a lot of back-ends for a lot of systems that I never used.

The Meique Lua API is almost done, I just need to think easier ways to write the equivalent of CMake FindPackages, a simple Hello World could be described as:

target = Executable:new("hello")
target:addFiles("hello.cpp")

The stupid example above shows nothing, because build tools intent to be used mainly by medium/big and sometime complex projects, so I'm trying to create a good API based on my experience with CMake, qMake and SCons and why not, my personal hate against Autotools.

P.S.: If you search about Meique, probably you will find an old website at luaforge, this was my first attempt to create a build tool, the source code reflects my understanding of building tools 5 years ago, so forget about it.