This page contains an uploaded file:
This page contains an uploaded file:
Good tip there, buddy!
Another thing, ur site is a veritable goldmine of great tips :)
And, What's this thing about Novell's webmail client. I'd think
unless u r employed by them u'll not be accessing it. So am I right
to think that u have changed job? :)
-- gparmar 2006-12-02 13:26 UTC
Note that the latest version of Apache that comes with Slackware 10.2 is 1.3.37 (published as a security patch) and that using earlier versions opens you up to known security risks. See:
It is also not necessary to recompile or reinstall Apache in order to compile mod_perl. All that's needed is having the virginal Apache 1.3.37 source code available in some directory.
mod_perl is also available in CPAN. Combined with the 'cpan2tgz' utility available from http://software.jaos.org/ it is trivial to make a Slackware package out of mod_perl: simply type "cpan2tgz mod_perl" as root, and follow directions. When it asks you whether to build httpd, you can say no.
-- McDutchie 2006-10-03 19:37 UTC
Thanks a lot. Instead of the whole shebang in the original entry, the idiot's guide to installing mod_perl under Slackware (10.2) then becomes:
# wget http://software.jaos.org/slackpacks/10.2/cpan2tgz-0.6-noarch-1.tgz # installpkg cpan2tgz-0.6-noarch-1.tgz # cpan2tgz mod_perl
Accept the defaults, but answer 'no' when it asks to build httpd.
Add the following lines to /etc/apache/httpd.conf, at the end of the LoadModule list:
LoadModule perl_module libexec/apache/libperl.so
At the end of the AddModule list, add:
# /etc/rc.d/rc.httpd restart
Check Apache log file:
# tail /var/log/apache/error_log
It should show something like (emphasis mine):
[Tue Oct 3 10:38:52 2006] [notice] SIGHUP received. Attempting to restart [Tue Oct 3 10:38:54 2006] [notice] Apache/1.3.33 (Unix) PHP/4.4.0 mod_perl/1.29 configured -- resuming normal operations [Tue Oct 3 10:38:54 2006] [notice] Accept mutex: sysvsem (Default: sysvsem)
-- Bvankuik 2006-10-04 08:42 UTC
A little extra comment; after some testing, it seems to run but continually segfaults:
[Tue Oct 3 11:17:26 2006] [notice] child pid 3740 exit signal Segmentation fault (11)
I'm constrained by time but if anyone has an idea, please make a comment :-/
-- bvankuik 2006-10-04 09:19 UTC
When I want to read out the settings from the electronics boards of the Telis project, I have multiple choices.
That last option actually involves querying the "func" board. This board has ID number 0. It's loaded into the server upon startup and actually runs some Perl code that's defined in the database. The Perl code mostly just maps straight through to settings on other boards, however, this can be used to create a simple interface to the more involved settings.
It's a very flexible setup to control a piece of custom hardware.
What's a bit of a shame is that there are some settings which actually need to be combined. All settings are 16 bits. However, one ADC returns 20-bit values and these need to be retrieved using two settings.
The database with parameters however, maps one-to-one. So, we work around this using a parameter on the "func" board. You query the func parameter, which runs some Perl to actually query two parameters, combines them and returns the result.
When you're creating dynamic web pages with forms on them, you'll probably not forget to validate the values that the user sent in a text box. Will you check which values come in from a selection box?
You probably wouldn't. After all, the user can't edit the values. Novell certainly doesn't. Novell has a piece of software called Webmail, so users can read their mail using their favorite browser instead of the Novell client.
That's useful. Using Webmail, users can also define server side e-mail rules, for instance to automatically move incoming e-mails from an mailing list to a specific folder. Most mailinglists put a specific piece of text in the subject, but others can be recognized by the e-mail address of the list, which is in the To: or CC: field.
Except... with webmail, the only fields you can enter, are the "From", "To", "Subject" and "Message" (body) fields. This is a non-editable select box.
Except it's editable. This can be done with any programmable web client, such as the libwww-perl module. Luckily, Firefox has the webdeveloper extension, which can turn select fields into text fields.
Novell's Webmail application luckily doesn't validate these fields. So all of a sudden, we have an extra feature where we can sort out e-mails according to the contents of the CC: field.
Useful when you're on a dating site and you're not looking for the (boring) choices of Male or Female, but -- say -- Muppet.
On a serious note, your framework for web development should provide automatic checks for this. For instance, PHP's PEAR classes contain the HTML_QuickForm class which programmatically can build HTML forms and (amongst hundreds of other features) nicely checks whether the entered values don't deviate from the possible selections.
When developing, you often want to keep an eye on several logs at a time. gnome-terminal is ideal for this, with its multiple tabs. To fire up one terminal with several named tabs at once, adapt the following shellscript and save it to a file called 'logwatch' or something.
#!/bin/sh gnome-terminal \ --window --title "Apache log" \ -e "ssh sron0311 tail -f /var/log/apache/error_log" \ --tab -title="messages" \ -e "ssh sron0311 tail -f /var/log/messages" \ --tab -title="Apache mod_perl log" \ -e "ssh sron0311 tail -f /home/apache_mod_perl/apache/logs/error_log"
Basically, each tab consists of a line where the title is set and a line where the command is set to view the logfile. Of course, the first tab to be opened is a complete window, not a tab.
Instead of --window or --tab, it's possible to use the --window-with-profile=... or --tab-with-profile=... option to set a particular profile for logging. You could give these windows/tabs a special background color to set them apart from the other terminals.
The electronics man of the Telis project came up with a script to measure any offsets in the DAC and ADC that sets input and reads measurements on the FFO (Flux Flow Oscillator).
The ADC that's used has many possibilities. It has four channels and for each of those, has a register to which an offset can be written.
The script measures the offsets in four steps (noted in red on the schema):
Note that the ADC has possibilities to measure the offsets itself, but in this case that can't be used: there are amplifiers just outside of the ADC that are not drawn in the schema above. These can have an offset as well and this is taken into account by the above-mentioned scripts.
At work, Tiemen Schut tested the performance under Linux for two Gigabit network cards, a D-Link DGE-550SX (optical) and an Intel Pro/1000 GT (standard Cat5e).
While the throughput is the same, the CPU usage is a major difference. Both Linux drivers allow setting some parameters for generating as little interrupts as possible. The difference:
|Number of interrupts
|Intel Pro/1000 GT
To recreate the test:
Today, I received an e-mail from Amazon:
From: "Amazon.co.uk" <firstname.lastname@example.org> Subject: Your Amazon.co.uk order has dispatched Content-Type: text/plain; charset=ASCII MIME-Version: 1.0 Greetings from Amazon.co.uk, We thought you would like to know that the following item has been sent to: <<< cut out some uninteresting parts >>> Ordered Title Price Dispatched Subtotal --------------------------------------------------------------------- Amazon.co.uk items (Sold by Amazon.com Int'l Sales, Inc.): 1 Salsa [Box set] £8.09 1 £8.09
My Mozilla mail program was showing the pound sign as follows:
Now why does it show the pound sign as a funny question mark? It's because the e-mail header says it should do so (emphasis mine):
Content-Type: text/plain; charset=ASCII
That's right, ASCII. Which is a seven-bit character encoding, which does not include the pound sign. Solution? Go to menu View -> Character Encoding -> Western (Windows-1252) (or ISO 8859-1). And the pound sign is shown.
Another fine example of a programmer who didn't understand what a character encoding was and basically just tried to ignore the whole issue and stick with ASCII. It's even spelled the wrong way (the standard prefers US-ASCII).
Q&A probably didn't caught this because they test on a Windows machine with Outlook or Outlook Express, completely forgetting about Apple's, Linux boxes, and Windows machines which don't have the character set by default set to Windows-1252 but to some other language like Russian.
This whole post sounds a bit pedantic however I find it strange that in the 21st century, someone can afford to stick his head in the sand and pretend that the whole world still uses ASCII.
The previous day, I thought I had Apache with mod_perl working on Slackware 10.2, but alas, funny segfaults all over the place. This time, I installed mod_perl in a completely separate user account and it works.
As root, create a user:
# useradd -g users -m -s /bin/bash apache_mod_perl # passwd apache_mod_perl
Login as the new user, then:
$ mkdir bin lib perl_modules $ wget http://search.cpan.org/CPAN/authors/id/L/LD/LDS/CGI.pm-3.25.tar.gz $ tar xfz CGI.pm-3.25.tar.gz $ cd CGI.pm-3.25/ $ perl Makefile.PL PREFIX=$HOME $ make && make install
Add the following line to .bash_profile:
export PERLLIB=$PERLLIB:$HOME/lib/perl5/5.8.6:\ $HOME/lib/perl5/site_perl/5.8.6"
$ mkdir -p $HOME/.cpan/CPAN $ cp /usr/lib/perl5/5.8.6/CPAN/Config.pm .cpan/CPAN/ $ vi .cpan/CPAN/Config.pm
Edit the file and change all paths with 'home' in them to the home directory of the current user (apache_mod_perl). Also change line:
'makepl_arg' => q,
'makepl_arg' => q[PREFIX=/home/apache_mod_perl],
Save and exit, and install any additional Perl modules your application needs. In our case, we typed:
perl -MCPAN -e shell cpan> install XML::Simple IPC::Cache Exit the cpan shell.
$ mkdir ~/src $ cd ~/src $ wget http://ftp.bit.nl/mirror/slackware/slackware-10.2/source/n/apache/apache_1.3.33.tar.gz $ wget http://perl.apache.org/dist/mod_perl-1.0-current.tar.gz $ tar xfz apache* $ tar xfz mod* $ cd mod* $ perl Makefile.PL PREFIX=$HOME APACHE_PREFIX=$HOME/apache \ APACHE_SRC=../apache_1.3.33/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 $ make && make install && cd ../apache_1.3.33/ && make install
Now edit /home/apache_mod_perl/apache/conf/httpd.conf and:
Save, exit and edit ~/.bash_profile. Add the following line:
Logout and login. Type:
$ apachectl start $ cat apache/logs/error_log
It should say something like:
"Apache/1.3.33 (Unix) mod_perl/1.29 configured"
You want users to be able to execute Perl scripts. Edit ~/apache/conf/httpd.conf and add the following lines at the end (only do this if you know each and every option below and understand the security risks):
# Line below checks all modules for changes, only necessary for development PerlModule Apache::StatINC <Directory /home/*/public_html> Options MultiViews Indexes FollowSymlinks ExecCGI <Files *pl> SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI FollowSymLinks allow from all PerlSendHeader On # Line below checks all modules for changes, only necessary for development PerlInitHandler Apache::StatINC </Files> </Directory>
To set the directory for modules:
<Directory /home/someuser/public_html> PerlSetEnv "PERL5LIB" "/home/someuser/src/project/perl/lib" </Directory>
Restart apache with:
$ apachectl restart
Go to http://localhost:8080/someuser/thescript.pl and be astounded.
Note: these steps are obsolete. In the comments, McDutchy points out a much easier way. This is much less work and also doesn't require any packages to be reinstalled.
Slackware 10.2 doesn't include mod_perl. To install this package while staying as close to the original Slackware installation, we're going to compile mod_perl using the patched Apache that's particular to Slackware.
Edit the Slackware build script apache.SlackBuild. Add the following line after line 26:
tar xvzf $CWD/mod_perl-1.0-current.tar.gz
Before the comment line that says "# build apache", insert the following lines:
# build mod_perl cd $TMP/mod_perl-1.29 perl Makefile.PL \ APACHE_SRC=../apache_1.3.33/src \ NO_HTTPD=1 \ USE_APACI=1 \ PREP_HTTPD=1 \ EVERYTHING=1 \ make make install
Finally add the following line after the ./configure options of Apache:
As root, execute the Slackware build script. When it's done, install the resulting package:
# sh ./apache.SlackBuild # installpkg /tmp/apache-1.3.33-i486-1.tgz
If any question comes up, accept the default. After installation, you may also need to add the following lines to the file /etc/apache/httpd.conf:
LoadModule perl_module libexec/apache/libperl.so AddModule mod_perl.c
The electronics man of the Telis project has created a new macro (set of instructions in the flash memory of the Telis FPGA). The macro repeatedly steps up the harmonic mixer bias voltage and then varies (sweeps) the power of the LSU, the Local Source Unit.
I'm busy making a 3D plot of the result of this macro. It should look like this:
LSU power (dBm) | | | 15|--------------- | 10|--------------- | 5|--------------- |_____________________ 0 Harmonic Mixer Bias Voltage
The lines at 5, 10 and 15 dB must be colorized to indicate the PLL IF level. This is an output of the PLL, a voltage to indicate
Working in the lab in Groningen until 21:15 yesterday, my colleague got his macro working (a 3Mb movie):
These macros are quite interesting: they're stored in on-board flash and run on the FPGA. This FPGA has grown and grown in functionality until it could run lists of instructions which can be nested and have loops in them.
If you've seen the previously posted video, you might wonder what happened. What was shown, was a spectrometer displaying a 100 MHz wide spectrum of the output of the PLL. The Y-axis displays the intensity. The center was set to 400 MHz. The arc is noise, and you can see a spike travel from right to left, see below:
The travelling is caused by changing the FFO (flux flow oscillator) control line. When we find the FFO control line setting where the power of the PLL signal is at the maximum, we remember that setting.
As I explained in 2006-04-25 SIR acronym, the FFO is a voltage-controlled oscillator. If you keep the complete schema in your mind (hm ffo pll schema.png), then you'll see that the signal that the FFO sends, is mixed by the harmonic mixer (HM) and ends up in the PLL again.
Below, a little schematic is shown which basically highlights the upper part of the complete schema hm ffo pll schema.png. The LSU (Local Source Unit) sends a signal of about 20 GHz into the harmonic mixer and it's possible to regulate with which power this is done. This influences the harmonic frequencies at the right. The length of the spikes says something about the power; altering the LSU power influences the length of particular spikes.
Another knob which we can fiddle with, is the bias of the HM. The bias is important, because this controls the way how the HM mixes the signals from the LSU and FFO. If you'd draw an I/V curve of the HM, it would be something like this:
You don't want to set the bias voltage so high that the line is linear, because then it would act as a resistor and resistors don't mix signals. Instead, the bend in the lower-right is the best setting (at around 2.5 mV).
The schematic below highlights the lowerleft part of the schema hm ffo pll schema.png. We get the phase difference as a voltage which the electronics can read out. We need this because we want it to be 0 volts before we turn the PLL gain higher.
For your viewing pleasure, a camera was aimed at a spectrum analyzer. It shows a macro that's being run which does finetuning of the FFO and then locking with the PLL. It's about 3.5 Mb.
Quote of the day:
Ed: "In theory, nothing works and we know why. In practice, it works and we don't know why."
Pavel: "Yeah and we're working in between: in practice, it doesn't work and we don't know why."
We want to make an I/V curve of the flux flow oscillator (FFO), including a third dimension to express the power with which the FFO is beaming. See below for an example plot.
A (Dutch) article on SRON appeared in AD/Utrechts Nieuwsblad: sron ad jun 2006.pdf
Suppose you have a bunch of Perl scripts and modules. Those modules have differing versions and you don't want to hardcode the path in the scripts. And a few of the scripts also run through CGI.
The solution is to set the PERLLIB environment variable for the scripts that are run on the commandline. Point the variable to the directory where you install the particular version of the modules. You could add the following lines in $HOME/.bash_profile:
# separate multiple directories with a colon. export PERLLIB="$HOME/lib/mymodules-rev316"
This can be done for different users on one Unix machine, i.e. if you're testing under user "test-rev316", you'll use the above line. If you're a developer, set it to the directory containing the checked-out source.
For the CGI scripts, the same can be done. Put a line like this in Apache's httpd.conf file:
# separate multiple directories with a colon. SetEnv PERLLIB "/home/bartvk/lib/mymodules-rev316"
This variable can be placed between <Directory> tags, so again different users on one Unix machine can have different values:
<Directory /home/test-rev316/public_html/cgi-bin> SetEnv PERLLIB "/home/test-rev316/lib/mymodules-rev316" Options ExecCGI SetHandler cgi-script </Directory>
<Directory /home/bartvk/public_html/projectWorldDomination/cgi-bin> SetEnv PERLLIB "/home/bartvk/src/projWorldDom/client/perl/lib" Options ExecCGI SetHandler cgi-script </Directory>
You could even do fancy things with the SetEnvIf directive, where you set PERLLIB according to the URL that comes in. Generally, the above will be OK though.
Don't fall into the trap of delaying the hassle! Sooner or later, another developer will take over the project and will want to leave the current code as is, and continue in another account. If all scripts and modules assume a particular directory layout, this will mean a fair bit of coding and testing before the new developer is up-to-speed.
In the previous entry, I told that the acronym SIR stands for Superconducting Integrated Receiver. What I didn't explain, is what it actually means.
First the superconducting part: when you want to measure a very weak signal, at some point the electronic noise will interfere with your measurement. This noise is caused by small variations in temperature. The lower the temperature, the lower the electronic noise. Hence very sensitive instruments need to be supercooled.
Now the receiver part: the signal which is measured is between 500 to 750 GHz. This frequency sits between radio signals and light. You can use optics as well as antennas. The SIR chip uses a very tiny double dipole antenna which is etched onto the chip. A silicium lens is used along with mirrors to guide the signal onto the chip its antenna. Note that although the signal can be put on the wire, it will fade out very quickly. That's why right below the antenna, the SIR mixer is located.
Finally, the "integrated" part of the acronym. This chip contains a SIS mixer as well as beforementioned antenna. However, two signals are mixed, the one from the antenna and another one from the FFO, the flux flow oscillator. This is a voltage-controlled oscillator.
This FFO is also integrated on the SIR chip, and generates a set signal between 500 and 650 GHz, the frequency we want to measure on. The fourth and final part on the SIR is the Harmonic Mixer (HM), which receives the FFO-generated signal and mixes it along with a 20 GHz signal to get a signal which looks like the one black one below:
On 2006-02-23 Pictures from TELIS Project, I showed the boards, of which the most right one is the LSU board. This board generates a number of signals. It contains an ultra-stable 10 MHz oscillator which uses a crystal, sitting in a nice warm little oven to keep it happy.
One LSU signal has a frequency 20 to 22 GHz with a certain power, which is fed into the Harmonic Mixer. This is called the pumping of the mixer. It is mixed together with the FFO signal by the HM to get what you see above: a signal with a frequency of, say, 650 GHz together with one that's 4 GHz above it -- that's the red signal in the picture above.
The resulting signal from the HM is sent into the SIS mixer as the F1 signal shown in the sketch of the previous entry 2006-04-24 SIRs for dummies. It's called a harmonic mixer because whatever signal f you put in, out comes a signal 2f, 3f, 4f, et cetera. The LSU input signal is chosen to get the required frequency of around 650 GHz or whatever the spectrum is that we want to view. We use the 30th harmonic for this, so the LSU signal would be set to around 21.8 GHz.
Below is a bigger schematic picture of what's happening.
The upper part of the schema I've explained. On to the middle left. The FFO is happily radiating away and the frequency drifts. To keep the FFO from drifting, you want to lock it. An external (meaning outside of the cryogenic flask) piece of electronics creates a phase-locked loop (PLL). This keeps the FFO on its set frequency. It operates using a 400 MHz reference frequency generated by the LSU board, as well as the output of the HM, which is run through a mixer first. This frequency is in the MHz range for practical reasons.
Note that the FFO is extremely sensitive. You put a bias voltage on it and for every millivolt, it changes by 484 GHz. Since we want to work with steps of 0.5 MHz, this would mean that we would have to change in nanovolts.
Like the SIR, the Telis PLL is a Russian product. It has an analog output with which you can check the quality of the phase locking.
If you take a step back, you can see that the LSU, Harmonic Mixer, FFO and PLL work together to get a steady signal of, say, 656 GHz. It also is possible to control this signal in steps of 0.5 MHz. This is then used to feed into and read out the SIS mixer.
Previously, I showed some pictures on the electronics that are controlled by the software I maintain and enhance. Now I'll explain what exactly is controlled.
We're basically commandeering a SIR, which stands for Superconducting Integrated Receiver. It's a tiny (4 by 4 mm) chip with which signals are measured in the 500 to 650 GHz range. The chip is set behind a silicon lens, is put in a container which is supercooled to about 2 to 4 kelvin.
Below is a picture of the SIR chip, a Russian product from the Institute of Radio-engineering and Electronics of RAS:
Legend: between the zero and one, the flux flow oscillator (FFO) is located. The Harmonic Mixer is located below that. More about these in a later entry. Right in the middle, a SIS mixer is etched (superconductor-insulator-superconductor). If you look at the SIS mixer from the side, you could sketch it (very badly) as follows:
The F2 signal comes in from the atmosphere, which is a very weak signal. The F1 signal comes from the FFO, which generates a very steady known signal. Out comes a signal which basically is F1 minus F2 and which can be amplified enough to read out. When a signal hits the SIS mixer, the resistance changes slightly and you can read this out using the current.
The base as well as the edges left and right are conducting. When the chip is supercooled, they become superconducting. The edges are separated from the base by an insulation (hence the name SIS). A constant voltage bias is put on the edges (denoted in the sketch by Bias) and the current I is varying to keep the voltage constant. Below this construction, another conducting line is etched, the Control Line (denoted by CL), about which I'll tell more below.
We can draw a curve with the values of current C and V, which is called an I/V curve:
If you want to get a clear signal, your curve should be like the thick red line. (Note that the derivative of the curve is the resistance of the SIS mixer.) However, that is not the case: we get the grey line. It wiggles a bit, even goes down a bit before it rises and with a bend continues in a linear fashion. To get the thick curve, we need the control line on the SIR chip.
More about the control line. This line is conducting and etched below the SIS mixer. It must generate a magnetic field, drawn as the small circle around the control line and extending over the base. To generate a magnetic field, the current must be kept constant.
Besides the control line, the FFO is operated (more about that later). The FFO generates a clean signal with a certain power, which lifts the grey line up.
When combined we get the red line, but it still can go a bit down like the grey line. We need to find a couple of values to get a clear signal: the current and the bias voltage on the SIS, and the current on the control line. So what do we do: we set a certain current on the control line, then for that current, vary the bias voltage on the SIS from, say 1 to 10 mV.
In the meantime, we read out the current on the SIS. We can then draw the I/V curves as shown above and see whether we get a nice straight curve.
Note: to keep the voltage constant on the SIS mixer, we need some kind of circuit:
The left circuit is a voltage source. If the current changes due to radiation hitting the SIS mixer, this circuit measures the change and with some filtering adjusts for this so the voltage stays equal. The right circuit is an alternative, an adjustment of the left circuit so it delivers a constant current instad of a voltage.
What is eventually done with the resulting signal? Well, when the signal comes in from the atmosphere, you want to analyze the spectrum (Spectroscopy) and see what kind of gases are there.
Check, as most test frameworks, has the following hierarchy:
main() |-- Suite1 | |--TestCase1 | | |--TestA | | |--TestB | | |--TestC | | |--TestD | | `--TestE | `--TestCase2 | |--TestF | `--TestG `-- Suite2 `--TestCase1 |--TestA |--TestB |--TestC |--TestD |--TestE |--TestF `--TestG
It's notable that the author choose to have a lot of Suites named after whatever it's testing (say, logging), with each having one TestCase named "Core". Sometimes there's a second or a third TestCase. Each testcase has multiple tests, mostly a dozen or so.
The author has a src and a tests directory. In the tests directory, there is one main file called check_check_main.c which contains one main() function. This function adds all suites and runs them. It knows about the suites because there is a header file called check_check.h contains all the test suites. Then there is a separate file for each suite, for example, check_check_msg.c contains one test suite and a dozen tests. It has the header file check_check.h and all necessary header files to test project code.
Notable differences with JUnit are:
Check can also output XML, which is useful for reporting on nightly builds. I've created an XSLT to convert to HTML: check unittest.xslt. It's very basic -- adjust to your needs. You can generate such a report on the commandline with a quick
$ xsltproc check_unittest.xslt check_output.xml > report.html
Some time ago, I translated an article called Evolutionary Database Design Dutch, originally written by Martin Fowler and Pramod Sadalage. Now it seems that this article has been fleshed out into a book! On O'Reilly's online library Safari, the book is mentioned as being published on March 6th, 2006. Here is the link: http://safari.oreilly.com/?XmlId=0321293533&a=102682
Some pictures from work, all related to the TELIS project.
These are most of the boards that will be aboard the Telis balloon. From left to right:
The power supplies on the backgrond are set to about 6 volts and are connected to the backplane at the far left (hard to see). This backplane provides besides power also communications.
The whole package, including batteries (see image below), will be enclosed in a casing, which will be put aboard the gondola.
The boards need to be powered on the balloon and this is why a battery pack will be connected to the backplane in the space in the middle (see first picture). SRON built a custom charger for the also custom made battery pack.
Note: I've expanded this entry in article Configuration.
In a non-trivial project, several programming languages will often be used. Keeping a common configuration file can become something of a nuisance. While it's easy enough to decide on one format, things like variables aren't easily used. For instance, you want to be able to have stuff like this:
Which will work fine for a file that you include in a Makefile. But for a PHP script, this is a pain. This is where m4 comes into play.
Just create a file called Config.m4 and put all your variables there in the following format:
Then create a basic configuration in a file called Config.template as follows:
user=_USER_ group=_GROUP_ bindir=/home/_USER_/bin
As part of your Makefile or Ant's build.xml, run m4 as follows:
m4 Config.m4 Config.template > Config.h
Voilà, problems solved!
I've been working with Subversion, especially from within Eclipse using the Subclipse plugin. I had earlier experience with the CVS plugin that comes with Eclipse. This is with Eclipse 3.1.1, Subclipse 3.0.1 and Subversion server version "SVN/1.1.4".
Some bad differences:
Some differences I'm neutral about:
All in all, I have the feeling there are a few minor bugs (or not-so-fantastic features) to be ironed out in Subclipse. However, if you're fed up with CVS then starting small with one project is worth it.