Chapter 8. Further Information

Table of Contents
Coping With Scilab
Local Documents

FIXME: need text here

Coping With Scilab

Scilab is a large package no doubt about that. The source for version 2.5 comprises of more than 48 MB, and builds to over 88 MB on a i386-Linux system.

Distribution Size

We use several tools to cope with Scilab's size and complexity. The most important ones are introduced in the following section.


The locate(1) command is the fast brother of the find(1) command. More precisely, locate accesses a precomputed database of filenames (usually /var/lib/locatedb; for its structure see locatedb(5)). The database is generated by updatedb(1) with a find / -print and then mangled for faster access.

We have found a local filename database very useful for the work with large projects. Therefore, we setup two aliases that create and access a project-specific list of filenames.

    alias upd='updatedb --output=./.locatedb --localpaths=.'
    alias loc='locate --database=./.locatedb'

The upd sequence is typically run after a CVS checkout, add, or remove in the directory SCI.

We run loc whenever we are looking for a file in the Scilab distribution. This is much faster than running find every time, especially when working with a slow file server. The only inconvenience remaining is that loc must be executed in the directory where the database resides, here: SCI. However this is more than compensated by the fact that locate does a substring search, i.e. given the filename fpat it returns all file- and directory names matching *fpat*.

If we want to scan the complete database and postprocess the output with our tools-of-choice, issuing a loc . and piping the output through the desired filters does the job.


What the updatedb/locate pair is for filenames the glimpseindex/glimpse pair is for file contents. glimpseindex(1) generates a database that is accessed by the user via glimpse(1). So,

    glimpse pattern

corresponds to a non-database backed command namely a recursive grep over a set of directories like

    find . -print | xargs grep pattern

assuming that the database has been generated for ".". Again the fast version is so helpful that we have defined two aliases.

    alias glidx='if test -f .glimpse_index; then 
                     glimpseindex -H . -o -f -B .;
                     glimpseindex -H . -o -B .;
    alias gl='glimpse -H .'

The first alias, glidx, is one line. It has been broken into several lines only to make its workings clear; namely if an index file already exists it is updated (-f option), otherwise it is generated from scratch.

Like our locate aliases everything is happening in the current directory which means that glidx should be called from SCI.

Glimpse is not part of the standard Linux distribution (at least not SuSE-6.2 and RedHat-6.1, the ones we checked). The University of Arizona currently hosts the Glimpse home page, and Glimpse can also be downloaded from SC0's software archive, which is mirrored by Sunsite UK.

Bug Hunting

In preparation of this document (lvd), and in our daily work (cls) we have found it very useful to have more than one Scilab. What? More than one running process? No, more than one binary of scilex. In fact three different versions all come in handy depending on the task.

scilex binaries

Optimized Code

The common name is "production quality code", but Scilab is so far away from production quality that we refrain from using that term.

This scilex is built with all compiler optimizations enabled. Furthermore all compiler switches and options are specifically tuned for the machine the code will run on in the future (see also the section called Building an Optimized Scilab in Chapter 6). Maximum performance is the only goal and no attempt is made to retain any debugging information.

Debugging Code

This scilex is not optimized, instead it carries complete debug information. Thus, it is ideally suited for interactive debugging sessions, and single-line tracing.

Profiling Code

The third variant is a profiling version of scilex that is not optimized for speed either.

Profiling is the first step of any optimization. But during our work with and on Scilab we have found it very helpful to be able to answer the notorious question: "Where is it burin' the cycles?" Profiling – done right – is much faster than timing individual "suspects", although analyzing the profiler output requires some skill.