We are done with our tour through Scilab, but we are not done with sci-BOT! A few things outside the Scilab application have to be mentioned. First, the sheer size of the sources requires some tools to handle it efficiently. We address this topic in Section 8.1. Moreover, we should not forget that Scilab is shipped with a lot of helpful documentation. Section 8.2 gives an overview of this part of the documentation. We wrap up the chapter with Section 8.3, a small collection of hyper links connected to 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 an IA32 GNU/Linux system.
We use several tools to cope with Scilab's size and complexity. The most important ones are introduced in the following section.
CVS is one of the most commonly used version control systems. A set of source files (which can be binary) is put under revision control by "checking it in". The important difference to an older version control system, RCS is the notion of a module which refers to the complete set of sources. Usually the set consists of a whole directory tree, as e.g. all Scilab sources.
Also check out Pascal Molli's information and FAQ on CVS. In larger development environments CVS with its relaxed rules might not be the adequate tool. In these cases Aegis could be used.
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 processed for faster access.
We have found a local filename database very useful for the work with large projects. Therefore, we have set up 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 the regulat expression .*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 the 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 .; else glimpseindex -H . -o -B .; fi' 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 most of the standard GNU/Linux distributions (at least not SuSE , and RedHat , the ones we checked). The University of Arizona currently hosts the Glimpse home page , and Glimpse can also be downloaded from SCO's software archive , which is mirrored by Sunsite UK .
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
The common name is "production quality code", but Scilab is so far away from production quality that we shall not use 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 Section 6.3). Maximum performance is the only goal and no attempt is made to retain any debugging information.
This scilex is not optimized, instead it carries complete debug information. Thus, it is ideally suited for interactive debugging sessions, and single-line tracing.
The third variant is a profiling version of scilex. It is not optimized for speed either.
Profiling is the first step of any tuning. Furhtermore, during our work with and on Scilab we have found it very helpful to be able to answer the notorious question: "Where is it buring the cycles?" Profiling – done right – is much faster than timing individual "suspects", although analyzing the profiler output requires some skill.
See also Section 4.6.2.