Discussion :

[sjrd]

Ce thread reprend les mises à jour importantes, le plus régulièrement possible, de Sepi.

Si vous voulez tester ça, vous pouvez soit :

• Récupérer la version SVN de Sepi
• Récupérer Sepi.zip, la dernière version considérée suffisamment stable

Consultez le thread sur l'installation et la mise en marche pour plus d'infos sur comment l'utiliser.

[Bestiol]

Je suis en effet parvenu à créer une classe à l'exécution, à en instancier un objet, et à faire des actions dessus.

Je savais que t'étais fort Sébastien... mais là....

Toutes mes félicitations, c'est vraiment de la prog de très haut niveau à ce stade !!!
Je n'ai pas encore testé là j'avais plutôt dans l'idée de me coucher, mais je le ferai

[sjrd]

Je savais que t'étais fort Sébastien... mais là....

Toutes mes félicitations, c'est vraiment de la prog de très haut niveau à ce stade !!!

Merci

là j'avais plutôt dans l'idée de me coucher

Tu m'étonnes

[Giovanny Temgoua]

Je testerai dans la semaine (le dimanche est reservé au troll )

mais si ceci est vrai

Je suis en effet parvenu à créer une classe à l'exécution, à en instancier un objet, et à faire des actions dessus.

alors, je pense certains projets comme InstantObject en pourrait tirer un grand parti (ne me demande pas comment encore ).

Je me trompe / J'ai mal compris ou bien tu fait un truc qui ressemble à la méthode CreateInstance de la classe Activator (.NET) ???

[Laurent Dardenne]

ou bien tu fait un truc qui ressemble à la méthode CreateInstance de la classe Activator (.NET) ???

Il y a de grande chance que cela y ressemble sur le principe.

[sjrd]

mais si ceci est vrai

Je t'assure, c'est bien vrai. Même que si tu fais Obj.ClassName - Obj de type TObject - dans ton code Delphi, il te renvoie le nom que t'as donné à ta classe à l'exécution.

Et les méthodes virtuelles, dynamiques et de messages fonctionnent de manière tout à fait transparente dans le code Delphi, que Obj soit ou non un objet d'une classe compilée ou créée par Sepi. Voir dans le bas de NonNativeUnit.pas l'appel de DynMethod.

alors, je pense certains projets comme InstantObject en pourrait tirer un grand parti (ne me demande pas comment encore ).

Je ne suis pas sûr. Quand j'ai vu parler de InstantObject pour la première fois, j'ai cru que oui. Sans fouiller plus ma réflexion, il m'a cependant semblé que c'était très dur à envisager.
M'enfin on sait jamais...

Je me trompe / J'ai mal compris ou bien tu fait un truc qui ressemble à la méthode CreateInstance de la classe Activator (.NET) ???

D'après ce que j'ai pu en lire, ça ne me paraît pas être ça. Le lien que tu me donnes permet de créer un objet à partir d'une classe quelconque, mais compilée tout de même. Moi je crée un objet d'une classe qui n'a jamais été compilée.

[Laurent Dardenne]

Par contre pour l'installation il y a qq chose de particuliers à faire ?
La compile du projet semble s'appuyer sur une variable d'environnement %SEPI% ? (là je ne pas trop le temps de creuser).
Est-ce qu'il y a des unités externes à ajouter ?
Tu as un modéle de classe dispo ?
Cette solution est propre à une version de Delphi ?

En tous cas le code est propre et full objet et il y a longtemp que je n'avais pas vu ça, en dehors du code source de Borland.

Si tu as un peu de temps pour nous en expliquer le principe, se serait bien.

[sjrd]

Par contre pour l'installation il y a qq chose de particuliers à faire ?
La compile du projet semble s'appuyer sur une variable d'environnement %SEPI% ? (là je ne pas trop le temps de creuser).

Oui il faut renseigner les variables d'environnement SEPI et SEPISDK, comme expliqué ici. Sinon il n'y a rien d'autre à faire.

Tu as un modéle de classe dispo ?

Tu entends quoi par modèle de classe ? Il y a le projet exemple EssaisSepi.bdsproj qui est dispo en fichier joint au premier message de ce thread.

Cette solution est propre à une version de Delphi ?

Non, elle doit fonctionner sur toutes les versions >= 4 (version presque définitive des RTTI jusqu'à ce jour).

En tous cas le code est propre et full objet et il y a longtemp que je n'avais pas vu ça, en dehors du code source de Borland.

C'est l'avantage de travailler à son compte

Si tu as un peu de temps pour nous en expliquer le principe, se serait bien.

Ben là expliquer tout le principe, j'ai pas vraiment le temps ; début juillet je commencerai à rédiger une explication détaillée, accompagnée d'un dossier sur tout ce que j'ai découvert du langage Delphi.

Mais s'il y a des points particuliers sur lesquels tu veux un mot d'explication, ça je peux faire.

[Laurent Dardenne]

Mais s'il y a des points particuliers sur lesquels tu veux un mot d'explication, ça je peux faire.

Dans le documentation DCTD il y a peu d'explications notamment pour la classe MetaRoot, quelle est sa fonction ?
Qu'est-ce qui t'a incité à redéclarer des types SEPI pour chaque type Delphi ?

[sjrd]

Dans le documentation DCTD il y a peu d'explications notamment pour la classe MetaRoot, quelle est sa fonction ?

En fait toute la hiérarchie objet des meta-unités est organisée sous forme d'arbre. C'est pour ça qu'il y a dans TSepiMeta des propriétés ChildCount, Children et Owner (similaires à ComponentCount, Components et Owner de TComponent). TSepiMetaRoot est là pour être la racine de cet arbre gigantesque, et ses enfants sont toutes les unités chargées.

Elle fournit par exemple une fonction FindType pour récupérer facilement un type où qu'il soit dans les unités, par son nom ou ses RTTI.

Qu'est-ce qui t'a incité à redéclarer des types SEPI pour chaque type Delphi ?

Eh bien j'avais besoin d'accéder rapidement et facilement à un certain nombre d'informations sur les différents types, dont les communes sont reprises par les propriétés de TSepiType : NeedInit et Size.
Et comme chaque type a sa manière de calculer sa taille, ou de savoir s'il requiert une initialisation, il m'a semblé naturel de créer une classe pour chaque... type de type

Plus tard, dans les modules suivants, notamment le module de runtime du moteur de script, les variables seront attachées à des meta-variables, qui elles-mêmes sont rattachées chacune à un type. Cela permet de savoir comment traiter ces variables.

En plus, si tu regardes la structure TTypeData définie dans TypInfo.pas, c'est clairement une structure qui se réécrit beaucoup plus proprement sous forme de hiérarchie de classes : tu vas des propriétés communes (MinValue et MaxValue pour les types ordinaux) jusqu'aux noms des valeurs du type énumération.

[sjrd]

Je viens de mettre à jour les 4 pièces jointes du premier message.

Entre temps j'ai ajouté le support des field table et method table, donc les RTTI de champs publiés et méthodes publiées (voir FieldAddress et MethodAddress).

Mais surtout j'ai ajouté le support des interfaces !

Dans l'exemple, on déclare une interface native IMyIntf, que l'on importe dans Sepi. Et la classe de base TMyNative dérive de TInterfacedObject, mais n'implémente pas IMyIntf.
Par contre, TMyClass, la classe créée par Sepi, le fait. Et vous pouvez voir à la fin du code de NonNativeUnit.pas qu'on peut récupérer une référence à l'interface IMyIntf sur l'objet Sepi en ayant d'abord eu une référence à IInterface (grâce à TInterfacedObject), puis en utilisant l'opérateur as.

Là je dois dire que j'ai pas eu facile : j'ai toujours pas codé une seule ligne d'assembleur dans mon code, mais je suis tout de suite passé à l'étape suivante : génération de code compilé x86 en direct live (pour les thunks de relocalisation)

(heureusement que j'en ai fini avec la chimie )

[sjrd]

Re-mise à jour, avec support des propriétés, y compris les RTTI des propriétés publiées.

[Bestiol]

Il est parti... on le l'arrêtera plus

[sjrd]

Il est parti... on le l'arrêtera plus

Bah c'est le blocus, la période de l'année où j'ai le plus de temps libre

Et puis tout le code "barbant" est fait. Les classes sont bien agencées et tout. Maintenant je peux progresser très vite, et c'est en plus du code vraiment intéressant et passionnant.

Les deux prochaines étapes sont :

• la sauvegarde et le chargement d'unités non-natives ;
• l'implémentation des déclarations forward de classes, interfaces et pointeurs (les trois seuls possibles).

Après ça je pourrai me lancer dans les tests grandeur nature dans FunLabyrinthe

[Bestiol]

Vraiment je t'admire Sébastien

Amuse toi bien

[sjrd]

Les deux prochaines étapes sont :

• la sauvegarde et le chargement d'unités non-natives ;
• l'implémentation des déclarations forward de classes, interfaces et pointeurs (les trois seuls possibles).

Bah valà ! C'est fait Et donc remis à jour.

Il y a maintenant dans EssaisSepi.dpr une directive de compilation {$DEFINE LOAD} qui indique si elle est définie si on est en mode chargement, et si pas si on est en mode création+enregistrement.

Si y'en a qui ont pas peur de voir du code un peu... Inhabituel ils peuvent regarder comment est faite la gestion des déclarations forward :
Dans SepiMetaUnits.pas et dans SepiOrdTypes.pas par exemple

[sjrd]

Une dernière mise à jour importante avec le support de l'alignement des champs dans les record non packed et les objets.

Après ceci, sauf gros bug, je ne remettrai plus à jour aussi souvent ces fichiers joints. Si vous voulez suivre, utilisez SVN, c'est fait pour

[Bestiol]

ah voui SVN très bonne idée

J'ai toujours pas testé :\
Jvais essayer de faire ça bientôt... ça compile sous D2007 ?

[sjrd]

ça compile sous D2007 ?

Normalement oui, je ne vois pas pourquoi ça ne passerait pas. Mais je te conseille de réenregistrer les paquets sans le dossier packages\110, en changeant leurs suffixes - les paquets D2007 sont légèrement différents des D2005, au niveau .bdsproj, ça t'évitera de voir tout le temps ton repository marqué comme "modifié" pour rien .

Parce qu'actuellement, il n'y a que les paquets pour D2005.

[Bestiol]

okay ça marche, j'essaierai