I share here some “recipes„, inteded as reminders for myself, in the hope they will be usefull to others. Discretion is advised, I cannot be held responsible for yaddi yadda… Since I'm a lazy bum, I might not translate all of them in french or english. To keep things tidy, I hide the lenghty texts. You can unfold them using the buttons.
Les informations que j'archive ici ont été glannées lors de mon propre parcours. Ne pas s'y fier aveuglément mais se référer aux textes de loi et demander l'avis de gens qui s'y connaissent (directeurs de thèse, école doctorale, etc.)
Pour pouvoir candidater à un poste de Maître de Conférences (MdC), il convient d'être qualifié. Pour ce faire, il faut envoyer un dossier de qualification avant la date limite de la session de qualification de l'année en cours (le calendrier est disponible sur le site du ministère). Les deux points importants sont (i) le respect du calendrier et (ii) la constitution du dossier. Le tout est régi par le texte de loi en vigueur pour l'année en cours. Pour 2010, c'était celui-ci mais attention, il est mis à jour tous les ans. Il y a plusieurs étapes dans le calendrier:
Pour ce qui est du dossier, les pièces absolument nécessaires sont données sur le site du ministère. Attention, pour certaines sections il faut fournir des pièces supplémentaires qui ne sont pas mentionnées dans le texte de loi (il n'y en a pas pour la section 27-Informatique). Il faut au minimum mettre dans le dossier:
Il est conseillé de prendre contact avec ses rapporteurs avant d'envoyer le dossier pour voir si la liste ci-dessus est satisfaisante. En particulier, il n'est souvent pas nécessaire de mettre un exemplaire de la thèse dans le dossier mais la laisser à disposition en ligne (avec l'url figurant dans le dossier papier). Même si seul le dossier papier compte, il est aussi recommandé d'envoyer le dossier sous forme éléctronique aux rapporteurs. Dernier point, la qualification est valable 4 ans. Il est aussi possible d'obtenir communication du rapport en cas de non-qualification et de faire un recours après le deuxième échec.
These are various tricks I learned (often the hard way) about hardware I owned or used to work/play with.
The Sony VAIO TZ150 is a nifty laptop (or at least that was the case at the time I bought it). Its reasonably fast (and I switched the CD-RW drive with an SSD), slick, battery life is amazing (the original battery can get me around 4 to 5 hours without wireless, 3 hours with despite being 3 years old). The real problem however is in the software. While the BIOS is a standard phoenix bios, sony added a proprietary menu giving only access to a handfull of options (boot device order, activate TCPA, alarm, password protect bios and so on). In particular, switching the VT-x bit of the CPU is disabled by default and not accessible through the menu. Ditto for the AHCI hard drive settings. With the VT-x bit disabled, you can kiss goodbye to running virtual box/kvm/xen at a decent speed. After hours (days) of playing around, I found not only a way to activate it but found a dump of all the settings available. To change a setting, you can proceed as follows.
SYMCMOS.EXE program. It's a
small utility by Phoenix (and I think it is only
semi-official, most of the flags are undocumented). Copy it on
the usb stick.SYMCMOS.EXE program as so:
SYMCMOS -v2 -lnvram.txt
( SYMBOLIC CMOS EDITOR - Version 643710-035 )
CRC = 250F
(0000) [0001]
(0003) [0000]
(0006) [0001]
(0009) [0000]
(000C) [0001]
(000F) [0001]
(0018) [0000]
(001B) [0001]
...
SYMCMOS.EXE -v2 -unvram.exe
[0001] at the
offset 0x363 enables the VT-x feature.
SYMCMOS.EXE to dump the symbolic table
of a Phoenix BiosThis is just a small tutorial explaining how to obtain the
symbolic table of a Phoenix bios, even though the settings might
be hidden by the computer manufacturer (in my case Sony). First
things first, you need to get ahold of the ROM file. Usually it
is hidden inside a self extracting/patching windows
executable. In my case the file is
called R0052N7.WPH and it was conveninently left in
the temp directory of the windows installation (I ran the
installer with wine) once the installer bailed realized it was
not being run on the original Windows of the sony vaio. We need
to use a small unix utility called phnxdeco. The
project seem dead but the program is available through the
Debian/Ubuntu repositories. As a side note, the program is buggy
if compiled for 64bit architectures (the author used long
instead of int in a few places). No worries, just
get the 32bit executable which will run like a charm on an amd64
(Linux) system. First, let's check that the file is indeed a
Phoenix Bios:
phnxdeco R005N7.WPH -l
This should printout some general information (offset of the start of the BIOS, size, …) as well as a list of the different modules/sections wihtin this BIOS file. Now it is time to extract the modules that we want:
phnxdeco R005N7.WPH -xs
This will create a bunch of .rom files
containing the code of various sections. We are interested in
two of them: STRINGS0.rom
and TEMPLATE0.rom. STRINGS0.rom
contains all the strings used in the stock BIOS menu (the one
from Phoenix). TEMPLATE0.rom contains the
menu structure (top-level menu, submenu) and pointers to the
text labels in STRINGS0.rom. Copy these files on
your FreeDOS usb stick, renaming TEMPLATE0.rom
to NODES.rom and STRING0.rom
to STRINGS.rom (since it's a FAT16 filesystem,
case does not matter). Reboot under
FreeDOS. Run SYMCMOS.EXE from the same directory as
the .rom files:
SYMCMOS.EXE -V2 -C
This creates a file COMBINE.rom which can then
be used to create a symbolic dump of the bios structure and
current settings:
SYMCMOS.EXE -V2 -FCOMBINE.ROM -SSYMBOLS.TXT
(note that there is no space between
the -F/-S options and the filenames).
If everything goes as planned, you get a nice symbolic dump of
your bios settings, similar
to this one. You can now use it
to change various settings using the usual method and brick and
destroy your computer to your heart's content.
To create bold small capitals (small capitals are used to typeset surnames in French for instance, and Section titles are in bold in default latex styles), you can do the following:
% in the preamble
...
\usepackage{extra-bold}
...
\begin{document}
...
\textsc{\textbf{Foo}}
...
When dealing with arrays, typical code might look like this:
int * tab = malloc(sizeof(int)*10000);
int i;
for(i = 0; i < 10000; i++)
tab[i] = 0;
// do something with the array
This linear initialization might be prohibitive (either from a theoretical
point of view, when computing the complexity of an algorithm or from a practical
point of view, if few cells of the array end up being used in the end).
A folklore technique to deal with this (at the cost of 3 times the memory use),
documented in:
is the following:
typedef struct _array {
int * data; // the actual data
unsigned int * set; // auxiliary array 1
unsigned int * back; // auxiliary array 2
unsigned int current; // number of initialized cells
unsigned int length; // total length
} array;
// we don't check the return value of malloc for clarity
array * create(unsigned int length) {
array * a = malloc(sizeof(array));
a->data = malloc(sizeof(int) * length);
a->set = malloc(sizeof(unsigned int) * length);
a->back = malloc(sizeof(unsigned int) * length);
a->current = 0;
a->length = length;
return a;
}
//assumes 0 <= idx < a->length
int get(array * a, unsigned int idx, int * found){
int bidx = a->set[idx];
if (bidx >= a->current || a->back[bidx] != idx) {
*found = 0;
return 0;
} else {
*found = 1;
return a->data[idx];
};
}
//assumes 0 <= idx < a->length
void set(array * a, unsigned int idx, int val){
int bidx = a->set[idx];
if (bidx > a->current || a->back[bidx] != idx) {
//cell has never been set, intialize it:
a->set[idx] = a->current;
a->back[a->current] = idx;
a->current++;
};
a->data[idx] = val;
return;
}
What's going on here ? Initially, the three arrays
(data, set and back)
contain some garbage, that is, random integers. First let's see what happens if we
try to read one cell of this array structure, say cell 100.
a->set[100] which is some random value xx is an unsigned int, it is larger than a->current
(which is 0) and therefore we return, without accessing any data.
Now let's put something in cell 100:
100 is not initialized, so we put a->current (which is 0) in
a->set[100]100 in a->back[0]a->currenta->data[100] to some valueNow, when we access again cell 100 to get its content, the condition
a->set[100] >= a->current does not hold, since a->set[100] is 0
and a->current is 1. The second also does not hold since
a->back[0] points back to cell 100. We know therefore that cell 100
has already been set to some value and that it is safe to read it.
Now if we try to read cell 101 (which is uninitialized) two things may occur:
0, in which case it is >= a->current0. We then read a->back[0] but then we see that it points back to 100
and not 101, and therefore we know that the 0 in a->set[101] is just garbage