Accueil Ma page Projets Échantillons de code Postes ouverts du projet Aevol
Résumé Activité Forums Outil de suivi Tâches Documents Sondages Annonces Code source Fichiers

Remarques sur les révisions

Nom de version : aevol-4.2

Notes de version
New in 4.2

* Post-treatment executables are now prefixed with aevol_misc_ and are installed into ${prefix}/libexec rather than ${prefix}/bin

Bugs fixed in 4.2 

* Bugs #281 and #282: Bug in gene position

  This bug happenned whenever a promoter at the end of the genome on the LEADING
  strand transcribed a gene that was at the beginning of the genome (or a
  promoter at the beginning on the LAGGING strand transcribed a gene that was at
  the end of the genome)

  The position of the protein was then out of the genome bound
  (> genome len when LEADING or < 0 when LAGGING)
  If this gene was also transcribed on another rna that didn't satisfy the above
  constraint, it wasn't recognized as the same gene.

  Either bugs had no effect whatsoever on the fitness and hence on the outcome
  of evolution.
  It could however lead to erroneous statistics regarding the number of RNAs a
  gene is transcribed onto.

* Bug #284: Undefined behavior when there is no terminator in the genome

  After a big deletion, it can happen that a genetic unit does not contain any
  teminator anymore. There can however be a promoter somewhere. The behavior of
  the program was different depending on the strand where the promoter was. If
  it was on the lagging strand, the RNA was supposed to be as long as the whole
  genetic unit, and could carry coding sequences. If the promoter was on the
  leading strand, the length of the RNA was left as is, that is, either to -1
  for generation 0, or to the length  inherited from the parent, which made no
  sense anymore once the terminator has disappeared.

  We decided that it is best that no RNA is produced in this case
  (no terminator = incomplete gene, assumed to be non-functional).

* Bug #285: "Barrier" events logged twice

  When a deletion would cause the genetic unit to be smaller than the size of a
  promoter, the mutation was not performed and (if the BARRIER option was chosen
  in the logs), and the event was logged twice.
  This kind of mutations is now performed normally (and hence no log entry
  should be issued) as long as it doesn't make the genetic unit smaller than the
  minimum length specified (which is independent of the promoter size).

* Bug #286: Log files incorrectly regenerated when resuming a run

  When resuming a run, log files are regenerated by copying the header of the
  former log file and its entries until the generation chosen to resume the run.
  During this copy, (1) the first entry was skipped, and (2) the entries for the
  resuming generation were copied, and thus ended up duplicated.