~theo/temp/anies.cc
la compilation ci-dessous correspond à ce que fait olena-0.10 :
g++ -finline-limit-1000 -O3 anies.cc
tegucigalpa% time ./a.out
./a.out 0,96s user 0,01s system 100% cpu 0,961 total
tegucigalpa% time ./a.out
./a.out 0,96s user 0,01s system 100% cpu 0,961 total
tegucigalpa% time ./a.out
./a.out 0,96s user 0,01s system 101% cpu 0,955 total
et le futur :
g++ -finline-limit-1000 -O3 anies.cc -DFUTURE
tegucigalpa% time ./a.out
./a.out 0,62s user 0,01s system 100% cpu 0,626 total
tegucigalpa% time ./a.out
./a.out 0,62s user 0,01s system 101% cpu 0,624 total
tegucigalpa% time ./a.out
./a.out 0,63s user 0,00s system 101% cpu 0,621 total
suite à une discussion rapide hier soir, il semble que le fait
que je n'utilise pas la dernière version d'olena pour la prestation
SWT ait un effet (psychologique) négatif sur le labo. De plus,
on m'a répété des propos que je ne revendique pas.
je préfère donc *écrire* ce que j'ai déjà dit plusieurs fois.
les deux raisons principales pour lesquelles je tourne la
version 0.5 :
- étant complètement à la bourre, le portage (pas énorme) est
d'une priorité ridicule par rapport aux livraisons que j'ai en
retard (comprendre : nuisible à mon planning)
- comme j'effectue bcp de couple compilation/test, le temps de
compilation est critique pour mon avancement
le détail maintenant :
- la version 0.5 compile avec g++-2.95
- les versions plus récentes ne compilent pas avec g++-2.95
- les temps de compilation avec g++-2.95 sont inférieurs à ceux
de des g++-3*
pour preuve :
...........................................................
olena-0.5
2.95.4 (2.95.4 opt) 3.3.3 (3.3.3 opt)
...........................................
compilation 5,74s 10,90s 6,97s 13,25s
exécution 1,15s 1,08s
...........................................................
olena-0.10
3.3.3 (3.3.3 opt)
...........................................
compilation 12,26s 23,28s
exécution 1,91s
...........................................................
mes soi-disant propos (que je déclare n'avoir jamais dit) :
(1) << je n'utilise pas des versions d'olena récentes parce qu'elles
se trainent >>
en corrolaire, on m'a donc rapporté :
(2a) << olena, c'est lent >>
et
(2b) << en voulant être générique et rapide, on n'est ni l'un ni
l'autre ; d'ailleurs SCOOP ne marche pas >>
MISES AU POINT :
(1) regardez les tableaux ci-dessus, ce n'est pas le temps d'exécution
qui me pénalise dans l'utilisation d'olena ; rappel : je fais du
"1 compilation puis 1 test" à répétition !
(2) que les personnes qui ont dit ça en parlent ouvertement et non pas
dans mon dos, qu'elles donnent des chiffres, des arguments (pas des
impressions)
comme vous l'aurez peut-être deviné, le code swt tourne maintenant avec
la version 0.10 d'olena.
Théo souhaite (depuis des années) que Olena soit construite en petite:
la bibliothèque seulement par défaut : pas la doc, pas les tools
etc...
Il faudrait changer configure.ac en conséquence, ainsi que README bien
sûr !
+@c ------------------------------------------------------------
+
+@node Reviewing Patches
+@section Reviewing Patches
+
+Once the commitment message posted (@pxref{Checking in a Revision}), it
+must be reviewed: @emph{every single patch should be reviewed}.
+
+The purpose of the review is of course to look for errors, typos,
+unclear documentation or ChangeLog, incorrect coding style, or even
+better implementation suggestion and so forth.
+
+If there is nothing to report about the patch, just reply ``Ok'',
+quoting only the ChangeLog. Usually the thread ends there.
+
+If there are issues to report, quote only relevant portions of the
+patch. If you have several big issues to report, you might want to make
+separate replies to split the thread. The author of the patch must
+answer to these comments, and if subsequent commits address some of
+these issues, the reply should refer to them (e.g., by giving the
+revision number).
+
+Anybody is welcome to comment a patch, nevertheless, this responsibility
+typically falls upon the shoulders of the project maintainer, or the
+code-review peer of the author of the patch.
----------------------------------------------------------------------
Index: ChangeLog
from Akim Demaille <akim(a)epita.fr>
* Makefile.am (.texi.txt, MAKEINFOTEXT, AM_MAKEINFOTEXTFLAGS):
New.
* maintain.texi (Maintaining ChangeLog): Now section of...
(Maintaining Projects): this new chapter.
(Checking in a Revision, Reviewing Patches): New.
Index: Makefile.am
--- Makefile.am Wed, 21 Apr 2004 11:37:53 +0200 akim (lrde-maintain/5_Makefile.a 1.1 644)
+++ Makefile.am Thu, 29 Apr 2004 14:35:59 +0200 akim (lrde-maintain/5_Makefile.a 1.1 644)
@@ -26,10 +26,43 @@
--fill-column=76 \
--no-split
+# Work around makeinfo's lack of I18n support.
+MAKEINFO = LC_ALL=C @MAKEINFO@
+
+
+## ----------------- ##
+## Texinfo -> Text. ##
+## ----------------- ##
+
TXTS = maintain.txt
CLEANFILES = *.txt
+MAKEINFOTEXT = $(MAKEINFO) --plaintext
+AM_MAKEINFOTEXTFLAGS = $(AM_MAKEINFOFLAGS)
+
+# Shamelessly stolen from Automake's .texi.info
+.texi.txt:
+ restore=: && \
+ backup="$(am__leading_dot)am$$$$" && \
+ if test -f $@; then \
+ mv $@ $$backup; \
+ restore=mv; \
+ fi; \
+ if $(MAKEINFOTEXT) $(AM_MAKEINFOTEXTFLAGS) $(MAKEINFOTEXTFLAGS) -I $(srcdir) \
+ -o $@ $<; \
+ then \
+ rc=0; \
+ cd $(srcdir); \
+ else \
+ rc=$$?; \
+ cd $(srcdir) && \
+ $$restore $$backup `echo "./$@" | sed 's|[^/]*$$||'`; \
+ fi; \
+ rm -f $$backup; \
+ exit $$rc
+
+
## ---------------- ##
## Building diffs. ##
@@ -42,7 +75,7 @@
-I '(line'
diff diffs: diffs.patch
-diffs.patch: assignments.txt tiger.txt
+diffs.patch: maintain.txt
-diff -u -w $(IGNORES) --from=$(DESTDIR)$(wwwdir) $(TXTS) >$@
cat $@
Index: maintain.texi
--- maintain.texi Wed, 21 Apr 2004 12:20:31 +0200 akim (lrde-maintain/6_maintain.t 1.2 644)
+++ maintain.texi Thu, 29 Apr 2004 14:20:10 +0200 akim (lrde-maintain/6_maintain.t 1.2 644)
@@ -4,7 +4,7 @@
@settitle Maintaining LRDE Projects
@c This date is auto-magically updated when you save this file:
-@set lastupdate April 21, 2004
+@set lastupdate April 29, 2004
@set gccversion 3.2
@c $Format: "@set version $ProjectVersion$"$
@@ -61,13 +61,19 @@
@contents
@menu
-* Introduction::
-* Maintaining ChangeLog::
-* Appendices::
+* Introduction:: About this document
+* Maintaining Projects:: Coding styles, guidelines etc.
+* Appendices:: Copying this document, Indices
@detailmenu
--- The Detailed Node Listing ---
+Maintaining Projects
+
+* Maintaining ChangeLog:: Recording the history of changes
+* Checking in a Revision:: Recording a revision of a project
+* Reviewing Patches:: Controlling the quality of patches
+
Maintaining @file{ChangeLog}
* What and How:: What are ChangeLogs
@@ -88,11 +94,21 @@
@node Introduction
@chapter Introduction
-
@c ======================================================================
+@node Maintaining Projects
+@chapter Maintaining Projects
+
+@menu
+* Maintaining ChangeLog:: Recording the history of changes
+* Checking in a Revision:: Recording a revision of a project
+* Reviewing Patches:: Controlling the quality of patches
+@end menu
+
+@c ------------------------------------------------------------
+
@node Maintaining ChangeLog
-@chapter Maintaining @file{ChangeLog}
+@section Maintaining @file{ChangeLog}
This page contains a summary of the most important things to know about
the Change Log entries. The main source of information remains the
@@ -107,7 +123,7 @@
@end menu
@node What and How
-@section What and How
+@subsection What and How
Document @emph{any} change you have made. This will make bug hunting
easier, and this will help other people to follow the development.
@@ -124,7 +140,7 @@
@end example
@node ChangeLog Do
-@section ChangeLog Do
+@subsection ChangeLog Do
@itemize @minus
@item
@@ -155,7 +171,7 @@
@node ChangeLog Don't
-@section ChangeLog Don't
+@subsection ChangeLog Don't
@itemize @minus
@item
@@ -185,7 +201,7 @@
@end itemize
@node Emacs and ChangeLog
-@section Emacs and ChangeLog
+@subsection Emacs and ChangeLog
@itemize @minus
@item
@@ -203,6 +219,40 @@
@key{RET}}.
@end itemize
+@c ------------------------------------------------------------
+
+@node Checking in a Revision
+@section Checking in a Revision
+
+@c ------------------------------------------------------------
+
+@node Reviewing Patches
+@section Reviewing Patches
+
+Once the commitment message posted (@pxref{Checking in a Revision}), it
+must be reviewed: @emph{every single patch should be reviewed}.
+
+The purpose of the review is of course to look for errors, typos,
+unclear documentation or ChangeLog, incorrect coding style, or even
+better implementation suggestion and so forth.
+
+If there is nothing to report about the patch, just reply ``Ok'',
+quoting only the ChangeLog. Usually the thread ends there.
+
+If there are issues to report, quote only relevant portions of the
+patch. If you have several big issues to report, you might want to make
+separate replies to split the thread. The author of the patch must
+answer to these comments, and if subsequent commits address some of
+these issues, the reply should refer to them (e.g., by giving the
+revision number).
+
+Anybody is welcome to comment a patch, nevertheless, this responsibility
+typically falls upon the shoulders of the project maintainer, or the
+code-review peer of the author of the patch.
+
+
+
+
@c ========================================================== Appendices
@node Appendices
Bonjour à tous,
Comme prévu la version 0.10 d'Olena est sortie hier soir. Vous pouvez la
télécharger sur le wiki:
http://www.lrde.epita.fr/cgi-bin/twiki/view/Projects/OlenaReleases
ou bien directement avec PRCS.
============================================
olena-0.10 archives ready for distribution:
olena-0.10.tar.gz
olena-0.10.tar.bz2
============================================
--
Damien Thivolle
damien.thivolle(a)lrde.epita.fr
Je ne sais pas pq, mais :
/home/akim/src/oln/olena/oln/convert/value_to_point.hh:122: Warning: Member doit(const argument_type &input) const of class oln::convert::value_to_point< ntg::color< 3, Qbits, S >, Exact > is not documented.
Generating docs for namespace oln::convert::abstract
Generating docs for compound oln::convert::abstract::color_conversion...
Generating docs for compound oln::convert::abstract::conversion...
Error: /limitcheck in --setpagedevice--
Operand stack:
--dict:1/1(L)--
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 1 3 %oparray_pop --nostringval-- --nostringval-- --nostringval--
Dictionary stack:
--dict:1062/1123(ro)(G)-- --dict:0/20(G)-- --dict:68/200(L)--
Current allocation mode is local
Last OS error: 22
GNU Ghostscript 7.07: Unrecoverable error, exit code 1
Error: Problems running epstopdf. Check your TeX installation!
/home/akim/src/oln/olena/oln/convert/abstract/conversion.hh:92: Warning: Member name() of class oln::convert::abstract::conversion is not documented.
Generating docs for compound oln::convert::abstract::conversion_to_type...
Le pire, c'est que c,a continue sans se rendre compte qu'il y a des
erreurs !
dit à une réunion : "on cherche des logos sexy
pour les projets du labo"
pour olena : Cf. ~theo/temp/logolena/*
l'auteur est alexis (déjà auteur du logo du labo
entre autres)
Nous venons de créer le projet prcs color_morpho.
Ce dernier vise à rassembler le travail que je fais avec Gioavanni sur
la segmentation d'images couleurs. Ce n'est pas propre (c'est plus un
joli goinfre qu'un projet). Pour l'instant il n'y a évidemment pas
grand chose.
Pour Théo et Giovanni:
0) [prcs checkout oln]
1) prcs checkout color_morpho
2) ./configure.sh
3) make
4) // pause café
5) cd scripts
6) ./for_all_full_process.sh < lst_img.conf
7) // pause clope
8) gqview ../data/out
[Heu, il me semble qu'il y a un bug dans l'attribut min_value,
je regarde ça]
--
Niels
