Génération de code - Page 2

Godzil (./26) :
Ho, question stupide, et

diff gcc-modifiedbykevin gcc-original | wc-l

ça donen quoi ?
500 lignes ?2000 lignes ?

9104 tigcccvs/gcc/gcc-4.1-tigcc-patch.diff
C'est un diff de 325466 octets. Et tous les patches ne sont pas de moi non plus.

ça m'étonnerais franchement que ça fasse plus de 100 000 lignes

Bah, comme tu as dit: "ou tu as potentiellement un groupe de personne qui bosse dessus..." Il est évident que je n'ai pas écrit tout GCC.

Si tu veux un projet dont la plupart du code est de moi:
wc -l ktigcc2/*.cpp ktigcc2/*.h ktigcc2/*.ui ktigcc2/*.pro
donne 28178 lignes. On n'en est pas à 100000.

Mais je sens qu'on s'éloigne du sujet. Franchement, l'intérêt de ce topic n'est pas de débattre combien de lignes ont les projets sur lesquels je travaille, si ça vous intéresse tellement, ouvrons un topic dans "J'ai rien à dire".

> Mais je sens qu'on s'éloigne du sujet.
Et tu n'y es pas pour rien
Même si d'autres ont répondu à ton post - il le faut pour qu'il puisse y avoir un troll - c'est bien toi qui as relancé ce topic en postant une opinion assez arrêtée, peu nuancée et peu consensuelle...

Et toi Lionel, tu continues de rebondir dessus...
Bref, pour répondre à Kevin, l'intérêt d'utiliser ces petits diagrammes, c'est que ça me permet de prendre du recul sur l'architecture de mon application avant même d'avoir commencé à écrire du code. Je peux ainsi modifier des structures fondamentales, sans avoir à réécrire quoi que ce soit. L'écriture du code prend un temps fou comparé à l'édition de ces diagrammes.
Et je ne cherche pas à ce que tout le code de mon application soit généré. Je crois que s'il existait un moyen de générer vraiment tout le code d'un programme à partir de diagrammes, ça me prendrait encore plus de temps d'écrire mon application, car pour certaines choses, c'est plus rapide d'écrire du code directement que de faire des jolis dessins.
Je cherche seulement un moyen d'automatiser les tâches répétitives (et inintéressantes en programmation) qui prennent 90% du temps de codage.

Bon, j'espère que votre troll n'a pas fait fuir Bruno Pagès...
./12 > Ah ? Bah j'ai du passer à côté alors...
Sinon, j'avais trouvé quelques défauts dans Bouml, la paramétrisation de la génération de code ne me convenait pas dans certains cas, et j'étais contraint de retoucher manuellement le code.
Cependant, Bouml reste le meilleur logiciel que j'ai utilisé
Est-ce que tu prévois de faire une version avec Qt 4 ?

Vu le nombre de posts de semi-off-topic (dont les miens, oui...) qu'il y a depuis le sien, tu ferais mieux de contacter Bruno Pagès en privé

qt3to4 peut faire des miracles.

Je crois qu'il utilise même Qt 2 !

Ça compile aussi avec Qt 3 d'après son site. (Je n'ai pas regardé le code, mais cette histoire de supporter en même temps Qt 2 et 3 me fait déjà peur rien qu'en la lisant. )

Le problème kevin c'est que ce que tu nous présentes c'est de la bidouille (troll pour troll, dent pour dent).
Le design est important, que ce soit pour la conception ou la maintenance d'un projet.

Sinon en ce moment je suis sur un TDD et je dois dire qu'au début c'est un peu déroutant lol

Sasume, finalement le logiciel dont tu avais parlé au post ./11 génère "vraiment" du code, ou bien juste des squelettes de classes et de méthodes à partir d'un diagramme de classe ?

Je n'ai pas encore testé.

oki; si au cours de tes recherches tu tombes sur un programme capable de faire un peu plus que de la génération de classes + attributs + prototypes de méthodes, ça m'intéresserait assez

c'est possible de faire générer du code alors qu'on seulement prévu la structure de son prog?

Oui, par exemple à partir d'une description de haut niveau de type SA/RT, on devrait pouvoir déclarer toutes les variables globales et créer toute la structure d'appel du programme avec les paramètres qui vont bien, et il ne resterait qu'à coder les PS (les feuilles de l'arbre d'appel)

OK, je vois le genre.

Et il y a aussi des programmes dédiés au traitement du signal qui marchent par "boîtes" que tu connectes entre elles, chaque boîte ayant sa fonction propre (un peu à la façon de puces électroniques), avec des bibliothèques de fonctions standards...

Ximoon (./45) :
Et il y a aussi des programmes dédiés au traitement du signal qui marchent par "boîtes" que tu connectes entre elles, chaque boîte ayant sa fonction propre (un peu à la façon de puces électroniques), avec des bibliothèques de fonctions standards...

Un peu comme les langagues graphiques dédié au son genre MaxMSP, PureData etc..

Tiens, tu connais MaxMSP ? ^^

Yep ^^

Mais j'ai une préférence sur la gratuité de PureData

J'avais fait en 2002 une initiation a PD et franchement je m'était amusé comme un fou ^^

(edit: d'ailleurs faudrait ptet que je montre un jours certaines de mes créations )
(edit2: c'est d'ailleurs pour sa que j'aime bien QuartzComposer, qui est un langage graphique basé sur le meme principe sous OS X >= 10.4)

C'est vraiment ultra intuitif comme principe

Oui enfin dès que tu commences à faire des trucs avec des pilotages d'éclairages, des interactions avec des capteurs pour avoir des filtres temps réel à un moment et pas un autre, ça devient vite lourd (mais c'est mieux que se taper un langage de script)...

Tiens, BOUML a été packagé pour Fedora:
https://www.redhat.com/archives/fedora-package-announce/2007-August/msg00207.html

Tiens, vu que ce topic est remonté...
J'avais pensé développer un genre de scaffolder (à l'instar de ce qui se fait avec ruby on rails), qui permette, à partir d'une classe modélisée en UML, et de quelques infos supplémentaires (genre quelles sont les données à "scaffolder", et éventuellement quelques précisions sur l'aspect de l'UI)de générer :
- un fichier .ui (peaufinable ensuite dans QtDesigner) contenant une sous-classe de QWidget, avec tous les composants graphiques correspondant aux données, mais sans layout ;
- un couple .cpp/.h, contenant le code définissant ce widget et faisant le lien avec le modèle.

Ainsi, l'utilisateur n'aurait plus qu'à peaufiner l'UI avec le designer, mais la part la plus importante du code, consistant à mettre à jour les données en fonction des données entrées dans les composants graphiques serait générée automatiquement.

Qu'en pensez-vous ?

Kevin Kofler (./50) :
Tiens, BOUML a été packagé pour Fedora

oui, les distributions Linux qui packagent Bouml sont donc maintenant :

- Debian
- FreeBSD
- Fedora
- Ubuntu (il semble qu'il n'y ai pas de package intermediaire entre deux versions d'Ubuntu, mais il y a arakhne.org)
- Gentoo (les downloads ne sont pas possible actuellement because probleme de securite de leur site)

je fais la version Windows et deux autres personnes font les packages pour MacOS PPC et Intel

Il manque donc principalement Suse/Novell, ce qui est un comble car je suis justement sous Suse (une veille 9.1)

Bonnes modélisations

bruno_pages (./52) :
il semble qu'il n'y ai pas de package intermediaire entre deux versions d'Ubuntu

C'est ça un des grands avantages de Fedora, les mises à jour de version pour pas mal de composants à l'intérieur d'une seule et même release.

Un truc est dommage, c'est que les releases des distributions Linux soient si rapprochées... sachant que pour faire une mise à jour propre il faut faire une réinstallation complète (au risque d'avoir des soucis dans les fichiers de conf de trucs qui ont été installés avec les sources), ça revient à faire une sérieuse interruption du système, plus la reconf qui va derrière.
A la rigueur, seule Debian ne fonctionne pas ainsi, mais il faut souvent ajouter les sources d'ubuntu pour avoir une distribution qui évolue vraiment.

Hmm d'ailleurs ça fait 1 an et demi que j'ai pas fait de mise à jour de ma Debian. Le jour où je vais le faire je sens que ça va être folklorique
Mais c'est pas pour tout de suite, pour l'instant elle répond toujours à mes besoins.

> sachant que pour faire une mise à jour propre il faut faire une réinstallation complète (au risque d'avoir des soucis dans les fichiers de conf de trucs qui ont été installés avec les sources)
-"il faut" + "il peut être plus efficace de"
Je tourne toujours sur une SimplyMEPIS 3.3.1, graduellement upgradée, y compris avec des packages de Debian unstable (maintenant etch...). Aucune réinstallation complète. Deux casses partielles d'installation résolues en quelques heures, lors des passages X.Org 6.8 -> 6.9 et 6.9 -> 7.x.

> Le jour où je vais le faire je sens que ça va être folklorique
En effet

D'ou l'interet de Gentoo et de ses version "PréBinaire" il y a des mises a jours possible tous les jours pratiquement, et gentoo est généralement une des distrib les plus a jour a un instant T

(et les "grosses maj") sont pas folklorique contrairement a des Ubuntu ou autre "Fedoca (Core)? [0-9]+"

En parlant de linux unix etc... je connais une pomme dont les maj sont tres folklorique en ce moment

Les mises à jour avec Anaconda sont officiellement "supportées" (au même titre que Fedora lui-même évidemment, pas de support au sens commercial), les mises à jour avec apt-rpm ont toujours marché chez moi aussi.

J'ai fait:
RHL 7.3 -> FC1 -> FC2 -> FC3 -> FC4 -> FC5 (FC1->FC2 avec apt-rpm parce que Anaconda boguait, avec Anaconda sinon)
après réinstallation sur un nouveau PC (j'aurais pu migrer et mettre à jour aussi, mais bon...):
FC6 -> F7

Et sur mon PC portable (PII 266 MHz):
FC2 -> FC5 (Anaconda) -> FC6 (apt-rpm) -> F7 (apt-rpm)