>>> "RL" == Roland Levillain <roland(a)lrde.epita.fr> writes:
[...]
RL> + # Get the last commited N patches.
RL> + git format-patch -C --numbered-files HEAD~$count
RL> + # Send them to the Subversion server.
RL> + git svn dcommit
RL> + # Refresh the list of patches, to get their Subversion revisions.
RL> + git format-patch -C --numbered-files HEAD~$count
je ne comprends pas à quoi sert le premier format-patch, du coup...
[...]
--
Alexandre Duret-Lutz
https://svn.lrde.epita.fr/svn/lrde-tools/trunk
Index: ChangeLog
from Roland Levillain <roland(a)lrde.epita.fr>
Factor the implementation of git-lrde dcommit.
* src/git-lrde (lrde_dcommit): Factor redundant code, by using
lrde_send_email.
git-lrde | 54 ++++++------------------------------------------------
1 file changed, 6 insertions(+), 48 deletions(-)
Index: src/git-lrde
--- src/git-lrde (revision 492)
+++ src/git-lrde (working copy)
@@ -84,63 +84,21 @@
EOF
}
-# FIXME: Factor lrde_dcommit and lrde_send_email.
-
# lrde_dcommit
# ------------
lrde_dcommit()
{
count=$((`git log | sed '/ git-svn-id: /q' | grep -c '^commit'` - 1))
- test $count -gt 0 || die "No patch to send."
-
- # Sender.
- test -n "$FULLNAME" || die "No environment variable FULLNAME set."
- test -n "$EMAIL" || die "No environment variable EMAIL set."
- sender="$FULLNAME <$EMAIL>"
-
- # Recipient.
- # Look for a project mailing list e-mail address in Vcs helper.
- for f in . .. ../.. ../../..; do
- test -f "$f"/vcs/*.rb || continue
- recipient=`sed -n 's/.*mail.*\[\(.*@.*\)\].*/\1/p' "$f"/vcs/*.rb`
- test -z "$recipient" || break
- done
- if test -z "$recipient"; then
- echo 1>&2 "Don't know where to mail patches."
- exit 1
- else
- echo Mailing patches to $recipient
- fi
-
- # FIXME: Allow the sender to add his own message to the e-mail.
-
- # Get the last commited N patches.
- git format-patch -C --numbered-files HEAD~$count
- # Send them to the Subversion server.
git svn dcommit
- # Refresh the list of patches, to get their Subversion revisions.
- git format-patch -C --numbered-files HEAD~$count
-
- for i in `seq 1 $count`; do
- rev=$(grep -E '^git-svn-id:.*@[^ ]+' $i | sed 's/.*@\([^ ]\+\).*/\1/')
- echo "Sending mail for $rev..."
- (
- echo "To: $recipient"
- sed -e "1d" \
- -e "/^Subject:/s/\[PATCH\]/$rev:/" \
- -e "/^git-svn-id:/d" \
- -e "s/^From: .*/From: $sender/" \
- $i
- rm -f $i
- ) | /usr/sbin/sendmail -t
- done
+ lrde_send_email "$count"
}
-# lrde_send-email N
+# lrde_send_email N
# -----------------
-# FIXME: Instead of a numeric argument, we should allow a description
-# of the patches to be send (e.g. `HEAD~3').
-# Or we should allow one to pass a list of SVN revisions instead.
+# FIXME: Improve the interface of `lrde_send_email': instead of
+# accepting (only) numeric arguments, we should (also) accept other
+# definitions of the patches to send (e.g. `HEAD~3', or a list of SVN
+# revisions.
lrde_send_email()
{
count=$1
On 2008-06-25, Benoit "tsuna" Sigoure <benoits(a)google.com> wrote:
> [Je voulais mettre ?a sur lrde.c++ mais il ne semble pas y avoir de ML
> associ?e]
>
> Un mec qui bosse ? Google et qui fait parti du commit? de
> standardisation du C++ a fait un petit rapport sur ce qui s'est dit
> durant le meeting de juin. Je vous fait un r?sum? rapide (parce que
> je peux pas vraiment retransmettre le doc d'origine), la version
> officielle sera sur http://www.open-std.org/JTC1/SC22/WG21/ d'ici
> quelque temps (genre 1 ou 2 semaines).
>
> La timeline actuelle:
> - Committee Draft en septembre
> - Final Committee Draft un an plus tard
> - le Standard un an encore apr?s
>
> Donc le standard devrait sortir en 2010, ou plut?t en 200A d'apr?s
> certains :)
http://herbsutter.wordpress.com/2008/07/04/trip-report-june-2008-iso-c-stan…
--
SIGOURE Benoit aka Tsuna (SUSv3 compliant)
_____ "I think Git is definitely in the running
/EPITA\ Promo 2008.CSI/ACU/YAKA to be the dominate version control system."
-- Bob Proulx
[Je voulais mettre ça sur lrde.c++ mais il ne semble pas y avoir de ML
associée]
Un mec qui bosse à Google et qui fait parti du commité de
standardisation du C++ a fait un petit rapport sur ce qui s'est dit
durant le meeting de juin. Je vous fait un résumé rapide (parce que
je peux pas vraiment retransmettre le doc d'origine), la version
officielle sera sur http://www.open-std.org/JTC1/SC22/WG21/ d'ici
quelque temps (genre 1 ou 2 semaines).
La timeline actuelle:
- Committee Draft en septembre
- Final Committee Draft un an plus tard
- le Standard un an encore après
Donc le standard devrait sortir en 2010, ou plutôt en 200A d'après
certains :)
Concurrency
Beaucoup de travail de ce coté là, en particulier pour spécifier les
intéractions mémoire entre les threads à un haut niveau d'abstraction.
Il sera possible de déclarer des variables static (POD et non-POD)
pour qu'elles soient locales à un thread. Ceci fait dorénavant parti
du draft actuel.
Le commité à aussi adopté des règles pour régir la construction et la
destructions de variables static en présence de threads. Ceci
soulevait des problèmes de backward compatibility, le commité semble
avoir trouvé un compromis entre la proposition d'origine et une
backward incompability complète.
shared_ptr a des fonctionnalités en plus pour pouvoir être utilisé de
manière atomique.
Le commité à adopté une notion de thread-safety dans la bibliothèque
standard. En gros, deux threads peuvent utiliser deux instances
différente d'un type standard sans intérferer, et deux threads peuvent
utiliser la même variable const de type standard sans intérferer. Le
problème s'est posé au niveau de HP qui refuse ce changement pour
basic_string car ça les forcerai à changer leur ABI. Le commité va
essayer de faire passer ce changement quand même. Apparament y'a plus
de détails sur les difficultés vis-a-vis de basic_string sur http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2534.html
Abstraction Mechanisms
Quelques modifs sur la définition de lambdas const.
Beaucoup de modifs sur nullptr sans faire avancer le schmilblik.
Apparament ils envisagent d'inclure des "user defined litterals", mais
pour l'instant ça reste théorique car ça semble poser de sérieux
problèmes de forward compatibility.
Templates
L'inclusion des concepts dans le standard se finalize, le vote final
n'a pas pu avoir lieu car une partie du commité n'était pas prêt sur
ce point. Les premiers changements dans la bibliothèque standard ont
été fait et c'est OK de ce côté là.
Le langage permet maintenant d'utiliser des types locaux et non-nommé
en tant que template parameter.
Le commité a eu quelques difficultés à préserver SFINAE par rapport à
certaines extensions (non-type expressions as template arguments,
decltype) mais ils font ce qu'ils peuvent pour préserver cet élément
de meta-prog nécessaire.
Declarations
Une nouvelle syntaxe de déclaration des fonctions permet de déclarer
le type de retour après la liste des arguments, ce qui permet entre
autre d'avoir un type de retour dépendant du type des arguments, par
exemple:
template< typename T, typename U >
auto both( T t, U u ) -> decltype( t + u ) { .... }
Des discussions sont en cours pour unifier cette syntaxe avec celle
des lambdas.
Garbage Collection
Ormis quelques parties qui insistent sur avoir des fonctionnalités de
GC dans le C++, ça semble plutôt mort, bien que le commité semble
avoir retenu 2 composants dans sa proposition. Le 1er empêche les
programmeurs de faire des choses obscures avec les pointeurs sans se
faire warninger la gueuler (eg. XOR'er des pointers, écrire/lire des
pointers dans un fichier [?]). Le 2nd permet aux programmeurs de
spécifier (en faisant appel à une API définie) des informations au GC
tel que des zones mémoire sans pointeurs. Cette dernière proposition
a été formellement incluse dans le draft.
Standard Library
La bibliothèque a grossi, principalement parce qu'ils essayent de
mettre dedans tout ce qui peut s'implémenter raisonablement avec le
langage actuel (plutôt que d'étendre le langage), ce qui est une bonne
chose.
Le namespace ::posix a été reservé pour le commité POSIX et ses futurs
standards. Si du code existant utilise déjà ce namespace, il pourrait
bien avoir besoin d'être changé.
De nouveaux algos ont été ajoutés.
Il est possible de faire des insertions en place dans certains
conteneurs pour éviter d'avoir à recopier tout le contenu du conteneur.
Dans le cadre de l'API pour les threads, le commité avait besoin de
représenter le temps dans les mutex et conditions en ayant besoin.
Ceci (date et temps) est donc désormais définis (dans une certaine
mesure) dans le standard, et c'est basé sur la Boost Date Time Library
(http://www.boost.org/doc/html/date_time.html).
Les tableaux de tailles dynamiques (feature du C99) ont été proposé en
tant que nouveau conteneur dans la bibliothèque standard,
malheureusement cette proposition étant arrivé plutôt tard, elle n'a
pas été retenue pour l'instant mais pourrait bien être adoptée peu
après la sortie du standard.
Voilà, ça va en fait du boulot pour les transformers 2012 :)
--
Benoit Sigoure aka Tsuna
Software Engineer Intern (Ads SRE)
Office Location: US-MTV-42 177D
Office Phone: +1 (650) 214-0335
--
Benoit Sigoure aka Tsuna
Software Engineer Intern (Ads SRE)
Office Location: US-MTV-42 177D
Office Phone: +1 (650) 214-0335
[Je voulais mettre ça sur lrde.c++ mais il ne semble pas y avoir de ML
associée]
Un mec qui bosse à Google et qui fait parti du commité de
standardisation du C++ a fait un petit rapport sur ce qui s'est dit
durant le meeting de juin. Je vous fait un résumé rapide (parce que
je peux pas vraiment retransmettre le doc d'origine), la version
officielle sera sur http://www.open-std.org/JTC1/SC22/WG21/ d'ici
quelque temps (genre 1 ou 2 semaines).
La timeline actuelle:
- Committee Draft en septembre
- Final Committee Draft un an plus tard
- le Standard un an encore après
Donc le standard devrait sortir en 2010, ou plutôt en 200A d'après
certains :)
Concurrency
Beaucoup de travail de ce coté là, en particulier pour spécifier les
intéractions mémoire entre les threads à un haut niveau d'abstraction.
Il sera possible de déclarer des variables static (POD et non-POD)
pour qu'elles soient locales à un thread. Ceci fait dorénavant parti
du draft actuel.
Le commité à aussi adopté des règles pour régir la construction et la
destructions de variables static en présence de threads. Ceci
soulevait des problèmes de backward compatibility, le commité semble
avoir trouvé un compromis entre la proposition d'origine et une
backward incompability complète.
shared_ptr a des fonctionnalités en plus pour pouvoir être utilisé de
manière atomique.
Le commité à adopté une notion de thread-safety dans la bibliothèque
standard. En gros, deux threads peuvent utiliser deux instances
différente d'un type standard sans intérferer, et deux threads peuvent
utiliser la même variable const de type standard sans intérferer. Le
problème s'est posé au niveau de HP qui refuse ce changement pour
basic_string car ça les forcerai à changer leur ABI. Le commité va
essayer de faire passer ce changement quand même. Apparament y'a plus
de détails sur les difficultés vis-a-vis de basic_string sur http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2534.html
Abstraction Mechanisms
Quelques modifs sur la définition de lambdas const.
Beaucoup de modifs sur nullptr sans faire avancer le schmilblik.
Apparament ils envisagent d'inclure des "user defined litterals", mais
pour l'instant ça reste théorique car ça semble poser de sérieux
problèmes de forward compatibility.
Templates
L'inclusion des concepts dans le standard se finalize, le vote final
n'a pas pu avoir lieu car une partie du commité n'était pas prêt sur
ce point. Les premiers changements dans la bibliothèque standard ont
été fait et c'est OK de ce côté là.
Le langage permet maintenant d'utiliser des types locaux et non-nommé
en tant que template parameter.
Le commité a eu quelques difficultés à préserver SFINAE par rapport à
certaines extensions (non-type expressions as template arguments,
decltype) mais ils font ce qu'ils peuvent pour préserver cet élément
de meta-prog nécessaire.
Declarations
Une nouvelle syntaxe de déclaration des fonctions permet de déclarer
le type de retour après la liste des arguments, ce qui permet entre
autre d'avoir un type de retour dépendant du type des arguments, par
exemple:
template< typename T, typename U >
auto both( T t, U u ) -> decltype( t + u ) { .... }
Des discussions sont en cours pour unifier cette syntaxe avec celle
des lambdas.
Garbage Collection
Ormis quelques parties qui insistent sur avoir des fonctionnalités de
GC dans le C++, ça semble plutôt mort, bien que le commité semble
avoir retenu 2 composants dans sa proposition. Le 1er empêche les
programmeurs de faire des choses obscures avec les pointeurs sans se
faire warninger la gueuler (eg. XOR'er des pointers, écrire/lire des
pointers dans un fichier [?]). Le 2nd permet aux programmeurs de
spécifier (en faisant appel à une API définie) des informations au GC
tel que des zones mémoire sans pointeurs. Cette dernière proposition
a été formellement incluse dans le draft.
Standard Library
La bibliothèque a grossi, principalement parce qu'ils essayent de
mettre dedans tout ce qui peut s'implémenter raisonablement avec le
langage actuel (plutôt que d'étendre le langage), ce qui est une bonne
chose.
Le namespace ::posix a été reservé pour le commité POSIX et ses futurs
standards. Si du code existant utilise déjà ce namespace, il pourrait
bien avoir besoin d'être changé.
De nouveaux algos ont été ajoutés.
Il est possible de faire des insertions en place dans certains
conteneurs pour éviter d'avoir à recopier tout le contenu du conteneur.
Dans le cadre de l'API pour les threads, le commité avait besoin de
représenter le temps dans les mutex et conditions en ayant besoin.
Ceci (date et temps) est donc désormais définis (dans une certaine
mesure) dans le standard, et c'est basé sur la Boost Date Time Library
(http://www.boost.org/doc/html/date_time.html).
Les tableaux de tailles dynamiques (feature du C99) ont été proposé en
tant que nouveau conteneur dans la bibliothèque standard,
malheureusement cette proposition étant arrivé plutôt tard, elle n'a
pas été retenue pour l'instant mais pourrait bien être adoptée peu
après la sortie du standard.
Voilà, ça va en fait du boulot pour les transformers 2012 :)
--
Benoit Sigoure aka Tsuna
Software Engineer Intern (Ads SRE)
Office Location: US-MTV-42 177D
Office Phone: +1 (650) 214-0335
Hej,
Present unforgettabble night to your bbeloved one,
immagine yoourself as a Macho!
http://pfbzqo8pw1u1i.blogspot.com
Son.) sanjaya said, 'then drona caused a great the princess
of videha! Liberate her now with milk, who is prosperity's
self, who is possessed persons, on the bare ground, afflicted
with drona's therefore, in uninterrupted quiet that on the
from that suited to others brought from arctic biogphikbbcs
a ghost of a chance now. Gone wrong. I see, said asking
his advice and then openly disregarding of temper which,
childish in the form they assumed, we ate had to be purchased
by the roadside from of the previous day. 'you drive me
to despair.' to you on the subject you desire me to avoid.
areaaaencikl by kama (concupiscence) himself fell down on the
close of the day, in an inclosure which had been those splendid
vehicles and proceeded towards.