This page contains several little things I hacked together at some point, and then abandoned at some point. I should probably let them disappear from the Internet altogether, but I keep them as souvenir. I doubt you'll find anything useful there, but you are welcome in my little museum These things are thus provided As Is, with the guarantee that they will not work for you. The things I developed myself are GPL, the things I patched remain under the license chosen by their main authors. If you have comment, questions or remarks, I'd be glad.

Blank mode Debian package: Minor emacs mode to visualize whitechars (SPACE and TAB)
NWS related: I used the Network Weather Service quite extensively during my PhD, and developed several associated tools. Too bad that NWS eventually died...
AutoConf Interactive: Interactively searched for libraries in autotools
libgtk3dcanvas: A tentative 3D counterpart of the libgnomecanvas. Kinda working last time I checked. Maybe 5 years ago.

Blank mode Debian package

This package contains an Emacs-Lisp files, that provide to Emacs the possibility of visualizing the whitechars (to differentiate between space, tabs and unbreakable spaces). It works well for me, but I didn't update the packaging since ages. And I have the feeling that it got superseded by something in emacs, even if I can't remember what. If you know, please drop me an email.

Binary package: blank-mode 4.0-1 all.deb
Source package: blank-mode 4.0-1.dsc blank-mode 4.0-1.diff.gz blank-mode 4.0.orig.tar.gz

NWS related

NWS was a neat research project intending to monitor and predict the network conditions on a platform. A large body of my PhD research was using or extending this project. I thus came up with several pet projects around NWS. Too bad that NWS eventually died. I should revive it at some point. For now, the things listed here are like in a museum...

nws_vizu: a vizualisation tool for nws. Get it here: nws vizu-020701.tar.bz2
nws_log and nws_dc: a set of functions which would be helpfull to improve NWS. These are a new logging system, and a data container. Get it here: nws-ng-020701.tar.bz2
- nws_log allows to declare a new logging channel per module of your code, and afterward, to control each channel separately.
- nws_datacontainer (or nws_dc for short) allows you to manage data collections. Garbage collecting is handled by the library. You can specify several indexes on the data collections. They can be plain array, red/black tree, linked list and so on.

AutoConf Interactive

That's a set of autoconf macros to let the user search some installed libraries interactively. I developed them back in the age for my FAST library. They are not maintained anymore.. If you are new to the AutoTools world, you should read the [[autobook|http://sources.redhat.com/autobook/autobook/autobook_toc.html], which explains all the AutoTools family.

The two main concepts in the ACI macros are packages, which are external set of program, and modules, which are parts of your project. For each package, you specify how to test if they are present on this machine; For each module, you specify on which package or other module they depend.

To work well, the modules must be organized in a tree, and their code must be in several subdirectories following the same tree.

A typical configure.ac file using ACI must contain the following parts (in this order):

Declaration of modules: In this part, you tell ACI how your project is split in modules, and give their dependencies on other modules or external packages.
Declaration of packages: Here, you tell ACI about the external packages your program depends on, and how to find them.
(other checks)
Call to ACI_MODULES_VERIFY: This macro computes which module can be build, based on if its dependencies are satisfied.
(call to AC_CONFIG_FILES to output the Makefile and so on)
At the end of the configure, you can summarize what will be built and what won't to the user using one of the ACI_MODULES_SUMMARY_* macros. There is two versions: ACI_MODULES_SUMMARY, which works always, and ACI_MODULES_SUMMARY_FANCY, which need gnu sed but produce fancier results.

This set of macros can also save the testing result from one run to the other. Contrary to what is normally done in AutoConf, it is saved in an external script, so that it is available in other packages as well. That the approach used in Gnome sources, and in pkgconfig. Sadly, it does not use pkgconfig yet.

From there, you may want to read further, to know about the different macros, jump directly to the defined options added to the ./configure script, or go to the FAST library to see how I use them. You may even want to help me, and check the known bugs to see what remains to do.

You can download this stuff.

ACI macros

List of declaration macros
List of action macros

ACI_PACKAGE (declaration macro)

Purpose: Declare a new package (ie, an external program).
Arguments:

First: Package (name of the package)
Second: Description (human readable, for documentation)
Third: Function (the main function to search)
Fourth: Library list (where to search). It is space separated list of group of LDFLAGS. each LDFLAGS is ! separated.
example: "-lldap -lldap!-llber"
warning: can't contain tabs nor newlines
Fifth: Header to check
Sixth: What to do if found
Seventh: What to do if not found (default: AC_MSG_ERROR(approriate text))

Note: It is possible to change any of the exported values in $6 or $7.
Actions:

try to find the function in each part of LDFLAGS.
try to find the header.
AC_SUBST (ie, define in the output Makefiles and related) the following values: HAVE<PKGNAME> ('yes' or 'no'); CFLAGS<PKGNAME> (CFLAGS to acces to this package); LIBS_<PKGNAME> (LDFLAGS to acces to this package).
define the arguments to ./configure explained here

Example:

    ACI_PACKAGE([LDAP],[LDAP v2],
                [ldap_bind],
                [-lopenldap!-llber-openldap\
                 -lldap\
                 -lldap!-llber],
                [ldap.h])

It declares a package called LDAP, which will be declared present if the function ldap_bind can be found with either "-lopenldap -llber-openldap", "-lldap" or "-lldap -llber" added to LDFLAGS and if the header file ldap.h can be found.

ACI_PACKAGE_SAVED (declaration macro)

Purpose: Same as ACI_PACKAGE, but with an external cache like the gnome-config program.
Arguments:

First: Package (name of the package)
Second: Description (human readable, for documentation)
Third: Cache program. Should accept --libs and --cflags (like gnome-config and pkg-config do)
Fourth: Extra arg to pass to this prog (like a name of library)
Fifth: What to do if found
Sixth: What to do if not found (default: AC_MSG_ERROR(approriate text))

Actions:

try to find the cache program.
AC_SUBST (ie, define in the output Makefiles and related) the following values: HAVE<PKGNAME> ('yes' or 'no'); CFLAGS<PKGNAME> (CFLAGS to acces to this package); LIBS_<PKGNAME> (LDFLAGS to acces to this package).

Example:

     ACI_PACKAGE_SAVED(XML,[XML library (version XML2)],
                       xml2-config,,,
                       AC_MSG_WARN(Cannot find the XML2 libs. Is xml2-config in your path ?)
                      )

Note: The action if failed could be a ACI_PACKAGE to search a package using the regular way...

ACI_MODULE (declaration macro)

Purpose: Declare a module, ie a part of your program, which may depend on other modules or packages.
Arguments:

First: abbrev (must be unique)
Second: human readable description
Third: Dependencies (space separated list of abbrev)
Fourth: Optional submodules (space separated list of abbrev). This is to connect modules together, in the directory hierarchy. Ie, if you have 3 optional modules A, B and C, and organized in 3 directories A, A/B and A/C (ie, B and C are subdirs of A), the fourth argument to ACI_MODULE must be [B C].
you must list B and C as fourth argument. It is a space separated list of modules directories which may be builded if the corresponding module is enabled. I use it in automake to do such rule:
```
 SUBDIRS= Utils Interpolate \@MODULES_FAST\@
 DIST_SUBDIRS= $(SUBDIRS) \@DIST_MODULES_FAST\@
 
```
So, automake will descend in the subdirs corresponding to the submodules of FAST only if the ACI macros decided they should be builded.
Fifth: Default ([yes]/no) (if not given, yes is assumed)
Sixth: Extra childs, which are listed under it in tree, without being a module. It is to build the tree structure used by ACI, and build the corresponding subdir in automake in all case. It is useful for subdirs containing themselves subdir which are not optional to the project.

Note: All modules MUST be organized in a tree-like manner. The ACI_MODULE macro build a sort of tree structure, and all action macros below need the name of the root module to do their job.

Actions:

Define an internal struct for the action macros, which is used by ACI_MODULES_VERIFY
Add the options described here to the configure script.

Examples:

    ACI_MODULE([FAST],[The library you are trying to use ;)],
               [],[Benchs Extract],,[Utils XP])
    ACI_MODULE([Benchs],
               [The module to collect benched about the current host.],
               [DB2],[BenchBlas])
    ACI_MODULE([BenchBlas],
               [What is needed to bench some basic BLAS functions],
               [Benchs BLAS])

ACI_MODULES_VERIFY (action macro)

Purpose: Check that the dependencies of each module are met.
Arguments: The name of the main module.
Note: It does not actually check for the packages and assumes the tests where done before. It just look the result of previous checks in internal data.
Note: This macro must be called before AC_OUTPUT and before ACI_MODULES_SUMMARY (fancy or not).

ACI_MODULES_SUMMARY (action macro)

Purpose: Display a summary of which modules will be compiled and which dependencies where not met.
Arguments: The name of the main module.
Note: This version is less fancy than the next, but it uses only very portable and quick stuff.
Output example:

The following modules will be builded:
  - FAST: The library you are trying to use ;)
    submodules: Benchs Extract
  - Benchs: The module to collect benched about the current host.
    submodules:
  - BufferedBench: Dummy module indicating if we're able to buffer through DB2
    submodules:
  - Extract: The module to get forecasts about this or other hosts.
    submodules:
  - Utils: Placeholder, ignore it
    submodules:
  - XP: All the experiments for beaaautifull coucourbes in papers
    submodules: nws_collaboration nws_response_time
  - nws_collaboration: XP: collaboration between NWS and scheduler is good
    submodules:
  - nws_response_time: XP: Fast cache speedup NWS very well
    submodules:

The following modules are disabled, either by you or by default. - Xml: Stuff to read XML files (EXPERIMENTAL)

The following modules have BROKEN dependencies: - BenchBlas: What is needed to bench some basic BLAS functions Depends on: BLAS - Prototype: A sample implementation of scheduler (experiment purpose) Depends on: BLAS - quality_fore_one: XP: Fast forecast are accurate for one operation Depends on: BLAS

ACI_MODULES_SUMMARY_FANCY (action macro)

Purpose: Display a summary of which modules will be compiled and which dependencies where not met.
Arguments: The name of the main module.
Note: This version is fancier than the previous, but it may be longer to execute and the portability is not guaranteed. In case of failure, please use ACI_MODULES_SUMMARY
Output example:

Summary of the configuration for FAST

FAST(OK): The library you are trying to use ;)
     Optional submodules to build: Benchs Extract
Benchs(OK): The module to collect benched about the current host.
       Optional submodules to build: BenchBlas
    > BenchBlas(OK): What is needed to bench some basic BLAS functions
Extract(OK): The module to get forecasts about this or other hosts.
       Optional submodules to build: Prototype
    > Prototype(OK): A sample implementation of scheduler (experiment purpose)
Utils(OK): Placeholder, ignore it
       Optional submodules to build: Xml
    > Xml(OK): Stuff to read XML files
         Packages and modules it depends on:
          o XML(FOUND): XML library (version XML2)
              LIBS:   -lxml2
              CFLAGS: -I/usr/include/libxml2/libxml -I/usr/include/libxml2 -I/include
XP(OK): All the experiments for beaaautifull coucourbes in papers
       Optional submodules to build: nws_collaboration nws_response_time quality_fore_one
    > nws_collaboration(OK): XP: collaboration between NWS and scheduler is good
    > nws_response_time(OK): XP: Fast cache speedup NWS very well
    > quality_fore_one(OK): XP: Fast forecast are accurate for one operation

Everything went well. Note: The result is printed on screen, and also in config.log for further debugging.

Options added to the ./configure script

For each package, a set of options is added to the configure script so that the user can specify where to search them. The options are:

--with-<PKG>=DIR root directory of <PKG>. The script will check for the subdirectories lib and include.
--with-<PKG>-includes=DIR specify exact include dir for <PKG>
--with-<PKG>-libdir=DIR specify exact library dir for <PKG>
--with-<PKG>-extra=ARG specify extra args to pass to the linker to get <PKG>. any argument will be added to the linker command line without further processing.

For each module enable by default, an option --disable-<MODULE> is added, so that the user can disable it even if all its dependencies are met. For disabled modules, the --enable--<MODULE> option is added to re-enable it.

Open issues and known bugs

This set of macro is not perfect, and here are the known open issues. Drop me a mail if you want to help me about one of these points.

We should use pkgconfig. For now, the ability to save the result of package search using fast-config is highly manual, and somehow broken. I would prefer use pkgconfig to do that cleanly. The idea would be that ACI can be used to generate automatically the .pc files used by this program, even for [external] packages.

We should implement the interactivity. ACI means AutoConf Interactive, but I didn't do the interactive part yet. It should take place in ACI_MODULES_VERIFY and allow user to change things to react to not found parts and so on. To manage that, I guess I'll have to split the configure script in sub-scripts to simulate function calls. For example, it would be possible to move all the tests for packages in a config.tests scripts which would take some args like the --with* ones and report if (and where) the packages where found. Then, it would be trivial to make the ACI_MODULES_VERIFY macro call this sub-script with different arguments (based on user input) until all packages are found.

ACI_MODULES_SUMMARY_FANCY shouldn't exist. It should test itself if it can run (ie, head tail sort and sed all exist, and accept all the options I use ; for and while loops are allowed in the current shell) and if not, fall back on what is now ACI_MODULES_SUMMARY.

Handle multiple incarnations of the same module. Ie, handle the fact that a given module can be implemented in several ways, depending on what is available in the environment or on user's input. For example in FAST, I have a buffering module which depends on BerkleyDB. But if this package is not available, I have another "buffering" module which implements exactly the same API than the first module, but don't buffers anything. I could also want to design a buffering module based on MySQL...
Help ! My optional sub-modules are never built !
This is a known bug. I can't manage to AC_SUBST(MODULES$1) and AC_SUBST(DIST_MODULES$1), because the name of the symbol is built and not constant. So, for now, you have to AC_SUBST them yourself after the call to ACI_MODULES_VERIFY and before the AC_CONFIG_FILES.

libgtk3dcanvas

Back in the ages, I began the developpement of a 3d counterpart to the great libgnomecanvas, hosted on sourceforge. Even if already usable, it is still incomplete. And I've lost any incitative to work on it. Please download it and do whatever you want with it...