Pour nos recherches le langage C convient d'avantage, car il est plus proche de la machine, alors que le langage C++ d'avantage spécialisé pour le développement orienté object d'application généraliste va finalement nous handicaper par une complexité de base qui nuit au développement fondamentaux. Les choix premiers qui ont été fait dans le développement du C++ ne sont pas obligatoirement ceux que nous voulons faire, et quant bien même nous les voudrions, il ne sont pas nécessairement à fair en premier.
Le développant en langage C est modulaire, et il laisse la possibilité d'intégrer le compilateur gcc dans le programme lui-même, de prés-compiler des fichiers écrit dans des langages symboliques, de les transformer en des fichier écrit en C, puis de les compiler, puis d'assembler ces programmes, et tous cela en utilisant des fichiers contenus exclusivement en mémoires vives, en redirigeant les entrés et sorties standarts à convenance. Puis il permet d'utiliser le calcul parallèle fait par plusieurs processus et threads dans un système réellement multitache qu'est unix/linux.
On utilise la plateforme Eclipse avec l'extension pour le langage C/C++ "Eclipse C/C++ Development Tools", ainsi que le compilateur gcc, et les outils make et gdb.
La plus part des programmes de grande capacité d'effectivité et la plus part des systèmes d'exploitation sont écrits en C et compilés par le compilateur gcc. Le langage C, proche du langage machine, n'a pas tranché de choix programmatifs ou trés peu, et laisse ainsi une grande liberté idéologique et conceptuelle au développeur-concepteur.
En cela, le compilateur gcc est une des pierres angulaires de la programmation. Son adjonction à un programme le fait passer délors à un stade au dessus, appelé métaprogramme, c'est à dire, le transforme en un programme capable de créer des programmes avec la même capacité d'effectivité, capable de se modifier en gardant la même capacité d'effectivité par le biais de la compilation exécutée au cours du programme par le compilateur gcc qui est alors lui-même une composante du programme.
Nous nous plaçons toujours dans cette démarche libertaire, qui consiste à porter les moyens, à construire les outils dans le but de donner toujours la plus grande marge de manoeuvre à ceux qui les utiliserons, et qui finalement reporte tous les choix à faire, le plus loin possible, pour ne se plier qu'aux seuls contraintes essentielles dite topologiques. Une tel approche sera dite topologique. Elle consiste à refuser de faire des choix qui ne sont pas strictement nécessaire, qui ne résultent pas de raison topologique, j'allais dire presque naturelle bien que ce mot ne conviennent pas ici. Nous parlerons plutôt de choix canoniques, de conventions qui si elles sont prisent différemment ne changent pas la nature des objects sur lesquels elles s'appliquent, et dont la seul raison d'être est de permettre la construction d'un langage, sur une base non conceptuellement arbitraire. L'arbitraire existe bien mais il ne porte pas sur le concept, et il permet de définir le langage sans lequel aucune construction n'est possible. La construction est le langage même.
L'utilisation du compilateur gcc par un programme nécessite différent outils, qui permettent comme le fait un système d'exploitation ou plutôt un linkeur, d'ordonner l'exécution de programmes, d'utiliser les disques de stockage et la mémoire vive avec des entrés et sorties spécifiques.
Les programmes de recherche ouverte ne peuvent prédire la duré de leur calcul ni leur éventuelle infinitude. Aussi chaque voie de recherche constitue une tâche qui doit être executée parallèlement au reste du programme. L'exécution parallèle est logiciel s'il n'y a qu'un seul processeur, et est en partie matériel lorsqu'il y a plusieurs processeurs. Cette exécution parallèle est simple à mettre en oeuvre dans un système d'exploitation unix/inux, car linux est un système d'exploitation réellement multitaches. La tâche est exécutée par un processus qui entretient un dialogue avec le reste du programme, et ce processus peut être priorisé différament, suspendu ou tué. C'est une description topologique du processus qu'il faut faire, établir un protocole de communication entre le processus et le reste du programme.
L'accès au disque dur est lent et ne peut égaler la vitesse de lecture/écriture de la mémoire vive du système. C'est pourquoi on utilisera des fichiers mémorisés en mémoire vive, pour transmettre rapidement des données d'un programme à une autre, d'un processus en cours d'éxecution à un autre.
Cela peut se faire en créant un système de fichiers volatiles
temporaire (type tmpfs), que l'on monte généralement dans
# mkdir /mnt/ram
# mount -t tmpfs -o size=100M none /mnt/ram
Notre système temporaire est bien monté en mémoire vive (vérifiez-le avec la commande mount)
# mount
...
none on /mnt/ram type tmpfs (rw,size=100M)
Pour le démonter assurez-vous que volume n’est pas utilisé puis tapez ceci :
# umount /mnt/ram
Les tube sont plus simples que des fichiers car il ne transporte qu'un bloc de données à la fois entre un processus émetteur et un processus recepteur. Le tube en lui-même ne contient rien, il ne transmet qu'un bloc de données écrit en une seul opération, et lu en une seul opération en même temps. Le processus émetteur, après avoir écrit un bloc de données dans le tube, reste en attente tant que le bloc de données n'a pas été lu par un processus récepteur, et reciproquement le processus recepteur reste en attente de celui-ci tant que le bloc de données n'a pas été écrit par un processus émetteur.
Un mode non bloquant est possible. Par contre, l'écriture et la lecture ne doivent pas être tous les deux en mode non-bloquant car sinon il n'y a pas de mécanisme de synchronisation faisant qu'un processus attend l'autre, et alors aucune écriture ni lecture n'est efffectué.
Des signaux peuvent être envoyés à un processus, et y déclencher l'execution d'un sous programme. Ils permettent ainsi de synchroniser des processus entre eux.
Les tubes et signaux sont plus rapides que les fichiers, mais l'usages est plus restreint. Deux types d'entré-sortie apparaissent, les tubes qui ne transportent qu'un bloc de données à la fois et de façon synchronisé et qui ne peuvent pas les accumuler, et les fichiers qui, quant à eux, peuvent les accumuler et ainsi les transmettrent de façon asynchrone.
Les segments de mémoire partagée permettent d'échanger des données de taille bornée de la façon la plus rapide possible entre plusieurs processus. Les sémaphores donne la possibilité d'en avoir un acces exclusif, et permettent de synchroniser les opérations de lecture-écriture sur cette mémoire partagée.
On peut programmer des protocoles pour utiliser un segment de mémoire partagé comme une file ou une pile avec d'éventuels tris.
Chaque type d'entré-sortie est liés
à un comportement du processus, un protocole spécifique.
Mais la technique ne s'autojustifie pas. On ne peut pas developper une approche technique sans en discuter d'abord le fond d'un problème cible. En effet le processus se définie à bien des égards selon son but. C'est pourquoi on va partir d'un exemple de recherche ouverte générales pour, à partir de la discution du fond du problème, utiliser des processus, et construire une technique.
Nous prenons pour exemple les algorithmes biomimétiques évolutionnaires (voir algo). Notre démarche est constructive et se veut universelle, et entrainera de facto une recherche théorique sur le langage.