Ce soir, la compilation du miniprint est devenue un peu tendu : dmd a
besoin de plus d'1.5 Go de ram pour compiler le miniprint... Autant
dire que ca swap chez moi !
Pour dire qu'il va peut-etre falloir generer le code dans un fichier
.d et ajouter les bonnes regles au makefiles. Tout faire en memoire
semble etre mal gere par dmd (pas de garbage collector et donc memory
leaks de dmd). Par ailleur c'est dommage de regenerer tout le code a
chaques fois que le fichier miniprint est importe.
/kiss
--
Alexandre Bique (bique.a...@gmail.com)
Epita 2009 - GISTR - Yaka
Port. +336 19 42 85 26
> Ce soir, la compilation du miniprint est devenue un peu tendu : dmd a
> besoin de plus d'1.5 Go de ram pour compiler le miniprint... Autant
> dire que ca swap chez moi !
Balèse !
C'est vrai que c'est inhérent a la metaprog...
Je suis pas sur que mettre ca dans un fichier règle le problème, parce
que le fichier sera reparsé et donc recharge en mémoire.
J'espère juste que c'est bien un leak de dmd.
--
Arkanosis
Je pense vraiment que c'est une faiblesse de dmd plus qu'autre choses.
Notre compilateur ne sera pas aussi faible face a la meta prog ! ^^
Bref le probleme est resolu, MiniPrint.d et BrowseVisitor.d sont
maintenant genere !
PS: Et on aura un static foreach pour iterer sur les TypeTuples dans
des DeclDef et on pourra ainsi generer du code sans mixin !
par exemple :
template AllNodes(T...)
{
alias T nodes;
}
alias AllNodes!(Node, Exp, AddExp, ...) Ast;
class DefaultVisitor : public Visitor
{
static foreach (T : Ast.nodes)
void visit(T node)
in { assert(node !is null); }
body {
Pour la petite explication, je pense que dmd leak quand il fait les
concatenation lors des appels de fonctions qui generent le code. Puis
il doit faire pleins de realloc d'assez grosse taille et ca doit bien
foutre la merde. Bref voila le probleme.