A cause des problemes avec libdryad au labo et du retard pris avec
l'atelier c++, nous beneficions d'une deadline extension pour PT3. Je n'ai
donc rendu aucune tarball. La nouvelle deadline est fixee a mardi 28 afin
de ne pas accumuler de retard sur les assignments suivant.
Pour ce qui est du probleme avec dryad, il faut que les roots des machines
ou nix est installe ajoutent aterm dans nix-env:
# nix-env -i aterm
a l'heure actuelle, aterm est installe car c'est une dependance cela dit
il ne fait pas parti de l'environnement de nix directement accessible aux
utilisateurs.
Workaround pour regler le probleme sans passer par nix-env -i aterm:
$ ldd ~/.nix-profile/bin/strc | grep libATerm
libATerm.so => /nix/store/<HASH>-aterm-2.4.2/lib/libATerm.so
(0x400df000)
export $ export
PKG_CONFIG_PATH=$HOME/.nix-profile/lib/pkgconfig:/nix/store/<HASH>-aterm-2.4.2/lib/pkgconfig
$ <ca marche>
Pour ce qui est de dryad, il y a des slides qui sont apparues a ce sujet
sur http://www.cs.uu.nl/wiki/Pt/CourseSlides (dans la 1ere section:
Introduction), Martin nous recommande de les lire avant de s'attaquer a
des exos utilisant dryad
NOTE: le prochain assignment consiste en un mini-interpreteur de Java en
Stratego, donc finissez vite PT3 pour ne pas prendre de retard!
--
SIGOURE Benoit aka Tsuna
EPITA Promo 2008, LRDE
---------------------------- Original Message ----------------------------
Subject: Re: [PT2][pt-submit] 3 groups of the LRDE
From: "Martin Bravenboer" <martin.bravenboer(a)gmail.com>
Date: Sat, February 25, 2006 20:49
To: "Tsuna" <sigoure(a)lrde.epita.fr>
--------------------------------------------------------------------------
Hi Tsuna,
> Thank you for the deadline extension. We really needed it ;)
Ok :)
Btw, we discuss the assignments in the lecture, but I don't want to put
the slides of that online to avoid leaking solutions to the course of next
year.
I've attached the slides of the discussion for the first assignment, can
you distribute it to your fellow students?
Cheers,
--
Martin Bravenboer
---------------------------------------------------------------------
Center for Software Technology
Institute of Information and Computing Sciences
Utrecht University
--
SIGOURE Benoit aka Tsuna
EPITA Promo 2008, LRDE
Je me souviens avoir vu il y a qq mois une page d'un PhD (de nom
d'origine asiatique je crois) qui avait travaillé sur une extension du
C++ pour exprimer des règles de transformation. Est-ce que ça dit
qqch à qq'1 ? Je me souviens qu'il disait avoir arrêté ce projet,
mais je le cherche qd même. Pour l'instant aucune chance avec Google...
Did we decide not to use "avoid"? If it is not the case, then I'm not
sure I understand why the following amb is not dealt with from the
parser itself.
"sizeof" "(" TypeName ")" -> UnaryExpression {cons("sizeof1")}
"sizeof" UnaryExpression -> UnaryExpression {cons("sizeof")}
Je me promenais sur comp.lan.c++.moderated quand je suis tombé sur
ce thread (cf ci-dessous) qui devrait intéressé quelques
Transformeux. Je n'ai jamais entendu parler de Semantic Designs
auparavant, mais ce n'était peut-être pas votre cas...
Malheureusement ce n'est pas du libre, mais je me demande quand même
si ils font réellement tout ce qu'ils annoncent ?
> ==============================================================================
> TOPIC: C++ to XML parser - does one exist?
> http:°groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/9c0c41421249f04d
> ==============================================================================
>
> == 1 of 1 ==
> Date: Sun 30 Oct 2005 08:21
> From: Ïra Baxter"
>
>
> "John Nagle"<nagle(a)animats.com> wrote in message
> news:aj86f.17908$6e1.13627@newssvr14.news.prodigy.com...
>> I'm looking for a tool to simplify program manipulation.
>> I need something that parses C++ into a tree format,
>> INCLUDING the comments and line breaks, and which can
>> also turn that tree format back into source text.
>> The parse tree must identify the syntatic elements of C++,
>> with function calls and type declarations correctly parsed.
>>
>> Ideally, the parser would generate the tree as an XML
>> file, for ease of handling. But that's optional.
>>
>> The idea is to allow writing simple tools that check
>> or modify declarations and function calls to add some
>> safety checks.
>>
>> Does anything like this exist?
>
> See http:°www.semdesigns.com/Products/FrontEnds/CppFrontEnd.html
>
> This is a C++ front end built on top of DMS,
> general-purpose program transformation machinery,
> and is offered as an industrial strength
> commercial product.
>
> It has a full C++ preprocessor and parser (for most commonly
> used dialects including ANSI, GNU, and the various MS dialects),
> automatically builds trees as it parses, capturing comments
> and lexical formats (indentation, number radix, ...)
> and builds a full symbol table.
> It makes those trees/symbol table available to custom code
> you write to accomplish your task, including arbitrary analysis
> and or serious automated transformation of the code.
> You can regenerate complete source text from the trees,
> including preprocessor directives (with some limitations)
> the comments and other lexical formats as undisturbed,
> or programmatically change that lexical information.
>
> A trivial custom task is to call the XML export
> function in the supplied AST management API
> to dump out the tree as XML ;-}. While you
> can do this, when you discover how big trees
> are, you may find this isn't the best option,
> especially considering that DMS provides
> extremely good facilities for transforming trees.
>
> This tool has been used for massive C++ source-to-source
> transformations. See the DoD Crosstalk article on
> automate C++ component reengineering at
> http:°www.semdesigns.com/Company/Publications/CrosstalkArticle/Crosstalk-05-2005.html
>
>
>--
>Ira D. Baxter, Ph.D., CTO 512-250-1018
>Semantic Designs, Inc. www.semdesigns.com
--
Johan
Lunsford's Rule of Scientific Endeavor: The simple explanation always
follows the complex solution.
Please, use consistent name conventions. For instance I read
`c-condition', and then ContractC.sdf, and then, prepost.str etc.
I suggest to rename everything as ContractC (contractc) consistently
with the paper.
>>> "Nicolas" == Nicolas Desprès <nicolas.despres(a)gmail.com> writes:
> On 9/20/05, Akim Demaille <akim(a)lrde.epita.fr> wrote:
>> - Ne pas utiliser argv[0] dans les messages d'erreur.
>> Ne surtout *jamais* coder un nom en dur, du genre SdfChecker,
>> dans les messages d'erreur, les logs, etc., mais bel et bien
>> argv[0]. Sinon, ceux qui debuggent vous maudissent !
> Je ne comprend ce point. Tu dis d'abord de "ne pas utiliser argv[0]
> dans les message d'erreur". Ensuite, tu dis de "ne surtout *jamais*
> coder un nom en dur [...] dans les messages d'erreur [...], mais bel
> bien argv[0]". J'ai l'impression que ces deux phrases sont
> contradictoires. Peux-tu m'aider, car c'est une question pour laquelle
> je n'ai toujours pas trouvé de réponse: "argv[0] ou pas" ?
> PS: Peut-être suis-je stupide et ai-je mal interprété ton post...
Oui, il te manque la tête de l'énumération, que je reproduis ici :
| Il y a deux choses *interdites* qui ont l'air d'être faites très
| souvent dans Tfers :
|
| - Utiliser @ pour cacher les commandes dans un Makefile.
|
| - Ne pas utiliser argv[0] dans les messages d'erreur.
Il y a deux choses *interdites* qui ont l'air d'être faites très
souvent dans Tfers :
- Utiliser @ pour cacher les commandes dans un Makefile.
C'est une erreur grave !
- Ne pas utiliser argv[0] dans les messages d'erreur.
Ne surtout *jamais* coder un nom en dur, du genre SdfChecker,
dans les messages d'erreur, les logs, etc., mais bel et bien
argv[0]. Sinon, ceux qui debuggent vous maudissent !
Merci d'en tenir compte et de réparer tous les endroits malades de Tfers.
Je trouve que c'est une erreur d'avoir autant de paquets dans notre
arbre. C'est une contrainte, quelque chose qui nuit à la
productivité. Si un jour il faut rendre un paquet autonome, ce serait
facile de l'arnacher, mais entre temps, je propose la suppression de
tous les configure.ac intermédiaires. Seul le bundle compte.
Quand je fais un make dans c-condition/src/syn :
SdfChecker:warning: unused sort definitions in /tmp/StrategoXT5Sm1zB, line 662, col 8: ExpressionList
SdfChecker:warning: unused sort definitions in /tmp/StrategoXT5Sm1zB, line 268, col 8: TypeSpecifierSeq
