Erreurs de compilation après introduction des classes en provenance d'EiffelBuild

[Philippe Cordel]

Bonjour

éternel débutant dans la pratique d'Eiffel je viens d'intégrer les classes MAIN_WINDOW et MAIN_WINDOW_IMP et d'inclure vision2 dans un projet qui se compilait bien

J'obtiens des erreurs :

VMFN two or more features have same name.

pour des versions concurrentes de default_create et copy en provenance de EV_ANY et ANY

VTUG  type has wrong number of actual generic parameters. pour des routines de la classe MAIN_WINDOWS_IMP

Je comprends à peu près de quoi il s'agit mais comment éviter ce problème ?

Est-ce que partir des classes du projet EiffelBuild et intégrer le reste est meilleur ?

Merci d'avance

Philippe

[Philippe Laré]

Bonjour

De la part d'un autre éternel débutant, si tu fais hériter de classes que tu as toi-même construites et héritant d'ANY des classes issues d'Eiffel Vision 2 et héritant indirectement d'ANY par EV_ANY, il faut indéfinir les primitives default_create et copy dans la clause d'héritage de tes classes des classes d'EV2.

Pour le VTUG, il faudrait des précisions.

Cordialement,

Philippe

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Groupe des Eiffelistes Francophones".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse groupe_eiffelistes_francophones+unsubscribe@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Philippe Laré]

Je viens de me relire et ne suis pas très clair. Voici la traduction pratique.

class
    MAIN_WINDOW

inherit
    MAIN_WINDOW_IMP

    MA_CLASSE
        undefine
            default_create, copy
        end
...

end

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse groupe_eiffelistes_francophones+unsu...@googlegroups.com.

[Philippe Cordel]

J'avais compris le précédent message.

En fait je vois bien la solution même pour les VTUG mais je voudrais bien comprendre pourquoi, quand j'intègre dans un projet "console" un dialogue avec des fenêtres je suis obligé de me préoccuper de conflits de noms et de signatures de routines que je ne suis même pas certain d'utiliser?

A chaque fois que je recommence à faire de l'Eiffel mon arrière pensée est toujours la même : "pourquoi est-ce que ce langage n'a pas le succès qu'il mérite ?". Certes EiffelBuild est un bon candidat pour la réponse ! Mais le genre de difficultés rencontrées lors de l'opération que j'ai décrite ci-dessus est également problématique de mon point de vue

Merci pour ton aide

Philippe

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse groupe_eiffelistes_francophones+unsubscribe@googlegroups.com.

[Philippe Laré]

Pour les signatures de routine, en l'absence d'exemple, je ne saurai dire.

Pour ce qui est du problème de l'héritage répété d'ANY, il ne se produirait pas si dans les deux branches tu en héritais directement ou que les héritiers dont tu hérites ne redéfinissaient pas default_create et copy. Ceci dit il est vrai qu'il y a souvent un problème de cohérence entre Eiffel Studio et EiffelBuild pris dans une même version. Par exemple, Eiffel Studio 15.01 fonctionne très bien avec EiffelBuild 13.11 mais pas avec la 15.01. C'est cependant loin de faire d'EB un repoussoir à mon sens.

Tu as un exemple pour les VTUG ?

Philippe

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse groupe_eiffelistes_francophones+unsu...@googlegroups.com.

Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Philippe Cordel]

"Eiffel Studio 15.01 fonctionne très bien avec EiffelBuild 13.11 mais pas avec la 15.01" Alors là c'est le pompon !!!

J'ai une douzaine de VTUG
Voici la première :

Class: MAIN_WINDOW_IMP
Type: PROCEDURE [READABLE_STRING_GENERAL]
Line: 469

->  string_constant_set_procedures: ARRAYED_LIST [PROCEDURE [READABLE_STRING_GENERAL]]
    string_constant_retrieval_functions: ARRAYED_LIST [FUNCTION [STRING_32]]

Merci encore

Philippe

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse groupe_eiffelistes_francophones+unsubscribe@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Emmanuel Stapf]

Le plus simple est de passer à EiffelStudio 16.05, normalement le code généré par EiffelBuild devrait compiler avec EiffelStudio. Notez cependant qu’il est préférable de regénérer le projet EiffelBuild car l’ancien code ne compilera sans doute pas.

 

Manu

 

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse groupe_eiffelistes_fr...@googlegroups.com.

Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Groupe des Eiffelistes Francophones".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse groupe_eiffelistes_fr...@googlegroups.com.

Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Groupe des Eiffelistes Francophones".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse groupe_eiffelistes_fr...@googlegroups.com.

[Philippe Cordel]

Je suis en 16.05 EiffelStudio et EiffelBuild

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse groupe_eiffelistes_francophones+unsubscribe@googlegroups.com.

Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Groupe des Eiffelistes Francophones".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse groupe_eiffelistes_francophones+unsubscribe@googlegroups.com.

Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Groupe des Eiffelistes Francophones".

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse groupe_eiffelistes_francophones+unsubscribe@googlegroups.com.

[Philippe Cordel]

Bon ! je repasse en dialogue console !

Pas bon pour mon compte rendu d'expérience et de réponse à la question "pourquoi Eiffel n'a pas le succès qu'il mérite ?" !

[Eric Bezault]

Bonjour Philippe,

On 10/7/2016 10:27, Philippe Cordel wrote:
> Bon ! je repasse en dialogue console !
> Pas bon pour mon compte rendu d'expérience et de réponse à la question
> "pourquoi Eiffel n'a pas le succès qu'il mérite ?" !

Je pense que ca serait plus facile de t'aider pour nous si tu pouvais
nous donner acces a ton code, qu'on puisse essayer de le compiler
nous-meme.

Pour l'erreur VTUG, vu que ca a l'air d'impliquer la classe PROCEDURE,
je pense que le probleme est juste une question de configuration dans
le fichier ECF. En effet, le premier parametre generique a ete recemment
supprimer dans la classe ROUTINE et ses descendants. Pour permettre
une meilleure transition, ISE a rajoute une option dans ECF pour
permettre au code qui contient encore ce parametre generique de
pouvoir continuer a compiler.

--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com

[Philippe Cordel]

Salut Eric

je passe ci-joint un 7z de mon application

L'application principale est dans le dossier Calculs

Le dossier Interface contient le dialogue bâti avec EiffelBuild

J'ai recopié les deux classes MAIN_WINDOW et MAIN_WINDOW_IMP du répertoire Interface vers le répertoire Calculs

Pour revenir à la version console il suffit de commenter l'héritage EV_APPLICATION  et décommenter l'héritage INTERFACE et commenter la feature ecran_principal dans la classe APPLICATION

merci d'avance

[Eric Bezault]

On 10/7/2016 12:26, Philippe Cordel wrote:
> Salut Eric
> je passe ci-joint un 7z de mon application
> L'application principale est dans le dossier Calculs
> Le dossier Interface contient le dialogue bâti avec EiffelBuild
> J'ai recopié les deux classes MAIN_WINDOW et MAIN_WINDOW_IMP du
> répertoire Interface vers le répertoire Calculs
> Pour revenir à la version console il suffit de commenter l'héritage
> EV_APPLICATION et décommenter l'héritage INTERFACE et commenter la
> feature ecran_principal dans la classe APPLICATION

Pour l'instant je n'ai pas encore compile le code.
Je n'ai fait que regarder les fichiers ECFs. Ce que je peux voir
c'est que dans le repertoire "Interface", le fichier ECF ne contient
pas l'option 'is_obsolete_routine_type="true"'. Ca veut dire que
les classes generees par EiffelBuild n'ont pas le premier parametre
generique pour la classe ROUTINE et ses descendants. C'est pour ca
que dans la classe MAIN_WINDOW_IMP tu as:

PROCEDURE [READABLE_STRING_GENERAL]

et non:

PROCEDURE [ANY, READABLE_STRING_GENERAL]

Par contre, le fichier ECF dans le repertoire "Calculs" a l'option
'is_obsolete_routine_type="true"'. Du coup, quand tu as copie les
classes generees par EiffelBuild dans ce repertoire, tu as eu
un probleme de VTUG car la classe MAIN_WINDOW_IMP a ete generee
pour compiler sans l'option 'is_obsolete_routine_type="true"'.

Solution: Apparemment tu n'utilises pas de PROCEDURE ni de FUNCTION
dans les classes du repertoires "Calculs" (a part les classes
MAIN_WINDOW et MAIN_WINDOW_IMP). L'option
'is_obsolete_routine_type="true"' dans le fichier ECF n'etait donc
pas necessaire. Je te conseille donc de supprimer cette option
afin que les options dans les fichiers ECF des repertoires "Calculs"
et "Interface" soient les memes. Comme ca tu pourras copier des classes
d'un rertoire a l'autre sans te soucier de ces problemes de
configuration de compilation.

> Pas bon pour mon compte rendu d'expérience et de réponse à la question
> "pourquoi Eiffel n'a pas le succès qu'il mérite ?" !

Au moins, ce qu'il y a de bien en Eiffel c'est qu'il y a des gens
sympas prets a rendre service! :-)

Plus serieusement, je pense que ce qu'il manque a Eiffel c'est une
communaute plus importante afin de pouvoir developper plus d'outils
et de bibliotheques de classes. C'est un peu le chat qui se mord
la queue: Eiffel n'a pas le succes qu'il merite car il n'y a pas
assez de gens qui font de l'Eiffel, mais les gens ne sont pas
attires pour faire de l'Eiffel a cause de son manque de succes.
On a donc besoin de toi, et de toutes les autres bonnes volontes
afin de renverser la tendance.

[Philippe Cordel]

>Solution: Apparemment tu n'utilises pas de PROCEDURE ni de FUNCTION 
>dans les classes du repertoires "Calculs" (a part les classes 
>MAIN_WINDOW et MAIN_WINDOW_IMP). L'option 
>'is_obsolete_routine_type="true"' dans le fichier ECF n'etait donc 
>pas necessaire. Je te conseille donc de supprimer cette option 
>afin que les options dans les fichiers ECF des repertoires "Calculs" 
>et "Interface" soient les memes. Comme ca tu pourras copier des classes 
>d'un rertoire a l'autre sans te soucier de ces problemes de 
>configuration de compilation. 

ça marche plus de VTUG !

Il me reste les 2 "VMFN Error: two or more features have same name." pour default_create et copy

La aussi j'ai un peu de mal à comprendre pourquoi mais là j'ai une solution pour que ça marche. Cela dit ce genre de "détail" à de quoi décourager les "essayeurs" d'Eiffel.

Encore une fois mon idée pour "aider" Eiffel est de me mettre dans la peau du débutant et d'intégrer à un programme console : un dialogue fenêtre, des lectures de fichiers, l'utilisation de base de données .......

Par exemple pour les VMFM est-ce que le problème (si il persiste !) ne devrait pas être indiqué au moment ou l'on décide d'inclure vision2 au projet ?

>Au moins, ce qu'il y a de bien en Eiffel c'est qu'il y a des gens 
>sympas prets a rendre service! :-) 

Ah ça c'est sur ! Merci encore pour tout ce que vous faites même si (surtout que) vous n'êtes pas nombreux 

Plus serieusement, je pense que ce qu'il manque a Eiffel c'est une 
communaute plus importante afin de pouvoir developper plus d'outils 
et de bibliotheques de classes. C'est un peu le chat qui se mord 
la queue: Eiffel n'a pas le succes qu'il merite car il n'y a pas 
assez de gens qui font de l'Eiffel, mais les gens ne sont pas 
attires pour faire de l'Eiffel a cause de son manque de succes. 
On a donc besoin de toi, et de toutes les autres bonnes volontes 
afin de renverser la tendance. 

J'ai donc raison de m'attaquer à une sorte de  "Mise en oeuvre d'Eiffel pour les nuls"

Si je reviens aux VTUG, je n'ai jamais touché au .ecf. Donc quelque chose dans le comportement d'EiffelBuild et d'Eiffelstudio conduit à des .ecf incohérents

Je connais Bertrand depuis bientôt 40 ans et je peux dire qu'il m'a tout appris. J'étais ingénieur système sur mainframe IBM avec plusieurs centaines de milliers de lignes d'assembleur à mon actif (et très fier de cet actif !). Il a commencé avec persévérance à nous expliquer l'utilité de faire le plus de choses possibles en FORTRAN et à appeler l'assembleur pour les seules choses auxquelles FORTRAN ne donnait pas accès. Puis son livre "Méthodes de Programmation". Puis Eiffel bien sur. Avant ma quête était d'essayer de proposer Eiffel aux différents services de mon entreprise (en vain). Aujourd'hui à la retraite je change d'objectif !!!!

Merci encore

[Eric Bezault]

On 10/7/2016 17:32, Philippe Cordel wrote:
> Il me reste les 2 "VMFN Error: two or more features have same name."
> pour default_create et copy

Je viens de regarder vite fait la classe APPLICATION.

class
APPLICATION

inherit
ARGUMENTS
EV_APPLICATION
-- INTERFACE
DONNEES
ASTRONOMIE

Le probleme est que les routines `default_create' et `copy' venant de
la classe ANY sont redefinies dans un ancetre de EV_APPLICATION. Du
coup on se retrouve avec l'implementation originelle d'ANY qui est
heritee par les classes ARGUMENTS, DONNEES et ASTRONOMIE, et la version
redefinie heritee de EV_APPLICATION. Donc 2 implementations differentes
avec le meme nom.

En mode "console" il n'y a pas ce probleme car la classe INTERFACE
ne redefinit pas ces routines. Il n'y a donc qu'une implementation
pour ces routines dans la class APPLICATION, celle venant d'ANY.

La solution est de se dire que si ces routines ont ete redefinies
dans un ancetre de EV_APPLICATION, c'est surement pour une bonne
raison. De ce fait, dans la classe APPLICATION on va choisir de ne
garder que cette version veant d'EV_APPLICATION, et d'ignorer l'autre
implementation venant de ARGUMENTS, DONNEES et ASTRONOMIE. Pour
se faire, on utilise la clause 'undefine':

class
APPLICATION

inherit

ARGUMENTS
undefine
default_create,
copy
end

EV_APPLICATION

-- INTERFACE

DONNEES
undefine
default_create,
copy
end

ASTRONOMIE
undefine
default_create,
copy
end

Je n'ai pas essaye de compiler ton code, ni ma suggestion ci-dessus,
mais je pense que ca devrait marcher comme ca.

PS: Tu m'as battu, je ne connais Bertrand que depuis 25 ans.
La ou je te bats c'est que j'utilise Eiffel de facon professionnelle
depuis 25 ans.

[Philippe Cordel]

Suite à nos dernières discussions, j'ai un peu réfléchi et j'ai repensé à cette utilisation de l'héritage "à outrance" où les applications héritent d'une multitude de classes (de ARGUMENTS par exemple).

Je me voyais mal écrire dans un tuto pour débutants à chaque héritage "undefine copy, default_create". Ça m'a rappelé une vidéo de Bertrand (peut être un cours ETH) qui dit que si on est gêné par toutes ses classes dont on hérite (abusivement ?) on pouvait, dans chaque cas, passer par une feature "cliente" de la classe. J'ai donc "collé" à la définition de base et je n'ai laissé que l'héritage, pour mon application, de la classe EV_APPLICATION (qui, elle, respecte parfaitement le verbe être)

Évidemment comme je le pressentais, toutes les erreurs disparaissent ! Vive les concepts fondamentaux !

Dans la version où j'intègre les classes MAIN_WINDOWS et MAIN_WINDOWS_IMP au projet de calcul la compilation se passe bien mais je récupère, à l'exécution, l'erreur

Catcall detected for  argument#1 `v': expected  PROCEDURE [!TUPLE] but got PROCEDURE [TUPLE]

sur le create ecran_principal la chaine est default_create - initialize - extend (In Class EV_NOTIFY_ACTION_SEQUENCE De la Classe INTERACTIVE_LIST)

Inutile de dire que je ne sais pas corriger cette erreur !

J'ai alors fait l'inverse, à savoir intégrer à l'application VISION2_APPLICATION générée par EiffelBuild mes classes de calcul et là, miracle, tout se passe bien. La seule différence que je vois est que dans le premier cas la classe root APPLICATION hérite de EV_APPLICATION alors que dans l'application générée par EiffelBuild la classe root VISON2_APPLICATION est cliente de EV_APPLICATION

Serais-je faché avec l'héritage ?