Older blog entries for aleix (starting at number 50)

SCEW 1.1.1 released

Finally, character escaping has been added to SCEW. This new release only features this and fixes output on Windows console for UTF-16 characters.

Stay tuned, major BitPacket updates come next!

Happy hacking!

Syndicated 2009-12-11 19:43:35 from axelio

SCEW 1.1.0 released

I’m pleased to announce SCEW 1.1.0. This is a minor release including two minor bug fixes and improvements for XML tree and element comparisons. Users can now provide their own XML tree and element comparison hooks.

Check out the release notes.

Happy hacking!

Syndicated 2009-11-30 20:29:35 from axelio

SCEW 1.0.0 released

I’m pleased to announce SCEW 1.0.0. It has been a long time since the last release in May 2004.

This new release includes a lot of improvements: unit tests, homogenized API, a lot of new functions, support for custom I/O sources, documentation updates, Windows support improved and many others.

Please, have a look at the changes for more details.

Savannah mirrors are being updated, so until then use the no-redirected download.

As usual, bugs, comments, criticisms, etc. are more than welcome.

Happy hacking!

Syndicated 2009-10-30 17:08:10 from axelio

Handling external dependencies with Mercurial

In order to add external repository dependencies in Mercurial, I have created an extension similar to the multi-project management feature of GNU arch. This can be probably done with other existent extensions, but I have not been able to found one that exactly met my needs (the Forest extension can be used for non-versioned Mercurial dependencies, and, in fact, they could be used together, but it is not exactly the same). So please, if anyone knows similar extensions, I would happy to know it. My friend Lluís gave me the idea to also handle non-Mercurial dependencies, so thanks from here!

To download it just type:

hg clone http://hg.hacks-galore.org/aleix/hgdeps/

You can also browse it online.

The extension consists of two commands: deps and depsclone. Below, I am pasting the help of the deps command.

This extension is useful when a repository might depend on some external dependencies: other repositories (Mercurial, CVS, Subversion…), files not handled by a SCM tool or some other dependencies.

To enable this extension, add this to your global .hgrc file (or to your repository .hg/hgrc file):

hgext.deps =
# or, if deps.py is not in the hgext dir:
# deps = /path/to/deps.py

In order to define these external dependencies, you need to add a section [deps] in your repository .hg/hgrc file (or in the global .hgrc) where you will define how to find them. As an example, let’s say that our repository depends on two external libraries managed by different SCM tools: ‘libfoo’ managed by Mercurial and ‘libbar’ managed by CVS.

aliases = libfoo, libbar
alias.libfoo = /path/to/libfoo
alias.libbar = :pserver:anonymous@cvs.server.org:/sources/bar
alias.libbar.command = cvs -z3 -d$source co -r $rev -d $dest bar

Two aliases have been defined, one for each library, and also the sources where the libraries can be obtained. ‘libbar’ has two options: the library location and the CVS command to use in order to get the library. For ‘libfoo’ only a path to the Mercurial repository has been specified. $rev, $source, and $dest are substitution placeholders and will be explained later.

Once the location of the depedencies have been defined, dependency lists can be created. A depedency list has an associated name. Following the example above, two depedency lists will be created, one for version 0.9.1 of our repository and another for version 1.0. 0.9.1 and 1.0 will be used as the name of the lists.

f24139319bdb    libfoo    lib/foo
v0r8_0          libbar    lib/bar

3a9b061bada1    libfoo    lib/foo
v0r7_8          libbar    lib/bar

A dependency is defined by three fields: a revision name, the alias of the external dependency and a destination directory. The alias must be one of the aliases defined in the [deps] section (see above). The revision name will be substituted for the placeholder $rev also seen before. For Mercurial, the revision name will just be a Mercurial revision of the external repository. Finally, the destination directory will be substituted for $dest.

To facilitate version control, distribution, and merging of dependencies, they are stored as a file named ‘.hgdeps’ which is managed similarly to other project files and can be hand-edited if necessary.

Syndicated 2008-03-17 18:08:51 from axelio

31 Jan 2008 (updated 20 Mar 2008 at 10:31 UTC) »

From GNU Arch to Mercurial

gnuarch.pngOver the last two and a half years we (at work) have been using baz as our distributed version control system. Baz is based on tla, the original GNU arch implementation by Tom Lord. After all this time we have applied more than two thousand patches (distributed in various projects). xtla.pngWe also have been using Xtla (a wonderful Emacs front-end to GNU Arch) and lately DVC (its successor, which handles GNU Arch, Bazaar, git, Mercurial and Monotone). After some months thinking about it, I decided that it was time for a change, baz was too slow working with this magnitude of patches and even slower in my PowerBook. I also wanted a fast web interface and ArchZoom was not an option as it took ages to show changes between two revisions and mostly in any operation. So, I watched the Mercurial Google TechTalk and I also read some blog entries about git and Bazaar. dvc.png I decided to give Mercurial a try as it also had complete DVC support and a great web interface (like the darcs one).

One of the things I needed was a tool to convert our baz repositories to Mercurial. As far as I knew, there was no such a tool, so I thought I could use arch2darcs to convert the repositories to darcs and then use the Mercurial convert extension to convert them to Mercurial. I tried it but it didn’t work. The Mercurial convert extension worked really well with darcs for my personal projects, so, why not write a GNU Arch converter?

After some days trying it, I have posted an issue to Mercurial BTS with a GNU Arch converter. It currently does not support directory renaming, but all other things I have tried work well. mercurial.png The converter is slow as I didn’t know how to compute a complete changeset between patches easily (any help?). The log files might not provide all the information needed (added, removed, modified files), so I decided to use the delta command which computes all this information, and this takes a bit of time.

To use the converter (in 0.9.5) copy it to the convert extension directory (hgext/convert) and edit the __init__.py file following, for example, the darcs converter (you’ll easily see how to add it). Use the converter at your own risk, as I am sure it needs more work. I would appreciate any comments and bug reports until it is included in Mercurial (if ever).

Syndicated 2008-01-31 13:51:31 from axelio

Baz 1.4.2 in Fink

Yes, Baz is deprecated, but we are still using it at work, so to make my life easier I have created the Fink package for the latest version (probably there won’t be more). Download this file and, as usual, type:

$ tar zxvf baz-1.4.2-fink.tar.gz
$ sudo cp baz-1.4.2-fink/*
$ fink index; fink rebuild baz; fink install baz

Baz depends on some cryptographic libraries (gpgme, libgcrypt and libgpg-error). The updated packages are also included (until updated in Fink) in the provided file.

Please, note that when the official Baz Fink package is updated you will have to remove your local copy (from /sw/fink/dists/local/main/finkinfo/).

Syndicated 2008-01-03 14:03:50 from axelio

ECL 0.9j in Fink

ECL has a new release, and thus a new Fink package update. It is still under validation, so until it is committed you can use this file. To install it, just type:

$ tar zxvf ecl-0.9j-fink.tar.gz
$ sudo cp ecl-0.9j-fink/*
$ fink index; fink rebuild ecl; fink install ecl

Please, note that when the official ECL Fink package is updated you will have to remove your local copy (from /sw/fink/dists/local/main/finkinfo/).

Syndicated 2008-01-03 07:27:50 from axelio

Screen Sharing with Mac OS X and GNU/Linux

Today, I discovered how to share my Mac OS X (Leopard) screen with another non-Mac OS X computer. Not a big deal, as it is almost automatic, but I’m posting it here as I did a search and I didn’t find how to do it.

What you need to do in your Mac OS X box is enabling the Screen Sharing service from the Sharing options in the System Preferences.


Before establishing the connection you need to setup a password. This is done in the “Computer settings…” button, just like this:


Do not avoid the password step, if you do it the connection will not be established.

Finally, you only need a VNC client in your GNU/Linux box. Not all the clients work, one that it does is the TightVNC viewer. In Debian, you can just type:

apt-get install xtightvncviewer

Once installed, you only need to run it and supply the IP address of your Mac OS X box and the password you configured.


Enjoy it!

Syndicated 2007-12-12 10:24:08 from axelio

Erlang R12B-0 in Fink

Erlang has a new release, and thus a new Fink package update. It is still under validation, so until it is committed you can use this file. To install it, just type:

$ tar zxvf erlang-otp-R12B-0-fink.tar.gz
$ sudo cp erlang-otp-R12B-0-fink/*
$ fink index; fink rebuild erlang-otp; fink install erlang-otp

Syndicated 2007-12-11 11:45:36 from axelio

Building applications for ERC32

A while ago, I answered a message, in the RTEMS users mailing list, about how to build raw applications for the ERC32 architecture. With raw applications I mean applications that are not dependent of RTEMS, which is the usual RTOS for this architecture. I am now writing about it just to make it easier for people to find it and to add some information to the explanation.

Before starting with the process, you need to get and build the RTEMS toolchain in order to compile your future applications (I used RTEMS 4.6.1). This is because the specific toolchain for ERC32 non-RTEMS applications is no longer maintained. Note, that you don’t need to install RTEMS itself, but you will need the source code. This video shows, step by step, how to download and build these tools for the i386 BSP, which should be almost identical for ERC32.

I’m not sure if what I’m going to explain is the best way to do it, but it has worked for me, and I have ran programs generated this way in a real board for a long time. I also think this may be useful for other architectures as well.

1. You need to get the following source files from the ERC32 BSP and copy them to your application’s directory:


2. Modify start.S so it does not call any RTEMS code, that is, commenting these lines:

    call    __bsp_board_init

    set     (SYM(rdb_start)), %g6   ! End of work-space area
    st      %sp, [%g6]

    set     (SYM(Configuration)), %l1
    ld      [%l1+4], %l3            ! work_space_size
    sub     %sp, %l3, %sp           ! set %sp to area below work_space
    andn    %sp, 0x0f, %sp          ! align stack on 16-byte boundary

3. Compile start.S, window.S and syscall.S. You can remove many things from the header files, but that’s up to you.

sparc-rtems4.6.1-gcc -DASM -c -o start.o start.S

4. Compile your C files (e.g. test.c).

sparc-rtems4.6.1-gcc -O4 -Wall -mcpu=cypress -c -o test.o test.c

5. Link your program. It will not work right now, as you need to generate two final files, my_bsp_specs and linkcmds.

sparc-rtems4.6.1-gcc -mcpu=cypress -Betc -specs my_bsp_specs -o test
window.o syscall.o test.o

Note the arguments -B and -specs. -specs is used to specify a file with options to override the default switches passed to cc1, cc1plus, as, ld… By default, RTEMS uses the file bsp_specs (found in c/src/lib/libbsp/sparc/erc32). You can edit it and see that it automaticaly links with the RTEMS libraries and adds its own start.S object file. The -B flag specifies where to find the executables, libraries, include files, and data files of the compiler itself. I have used an etc directory where I have stored my_bsp_specs. If any of the needed files is not found by the compiler it will automatically search its own paths.

So, what we need to do is to create our own file, my_bsp_specs, which will not use any RTEMS library and which will point to our compiled start.S object file.


crtend.o%s crtn.o%s

-T linkcmds

start.o crti.o%s crtbegin.o%s

-dc -dp -N -e start

The %s indicates to search the file in the compiler specific directories. I have removed the %s from start.o so it will search for it in the current directory.

Another important thing to note in this file is the -T linkcmds option. This indicates the linker script, which describes where the code and data for the application will reside in memory, to be used by the GNU linker. Fortunately, we can use the one that comes with RTEMS (found in c/src/lib/libbsp/sparc/erc32/startup), so copy it to the etc directory.

Finally, note that when linking, we have not specified the start.o file as it is already done in the my_bsp_specs file.

You might also find more information in the RTEMS BSP and Device Driver Development Guide.

Syndicated 2007-10-02 19:36:01 from axelio

41 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!