Karate 1.0
8 sujets de 16 à 23 (sur un total de 23)
- 1
- 2
-
alors je vais faire l’historique du systeme de plugins pasqu’elle est particulierement interessante: (et répondre a tes questions )
avant la version 1.0 les plugins .Fx étaient des .library: chque fois qu’on lançait un karate, ils étaient chargé en memoire en temps que .library. une fonction init est lancé au départ, et avant le closelibrary, une fionction close est lancé.
le code étaient donc partagé si plus d’1 karate étaient ouvert à la fois. mais cela posait alors des problémes de dépendances: par ex, la dbm.fx ouvre la dbplayer.library,
et est sencé la fermer, mais si 2 karate sont chargé en mémoire, il y avait collision: l’intégralité du code d’une .library doit en fait etre RE-ENTRANT (construit sur sa pile uniquement.) ce qui ne pouvait pas être le cas d’un « plugins ».
il y aurait eu une solution beaucoup plus complexe en créant un espece de « serveur de structure globale dont la forme est défini par le plugins » coté appli karate, mais ça aurait rendu l’ecriture d’un plugin chiante.
le probleme ne pouvait pas non plus résolu par la fonction expunge des .library, (explication encore plus compliqué)
donc la bonne solution , c’est bien sur dos.library/LoadSeg()
qui charge du code une fois par appli lancé. (comme delitracker.) dés lors plus de probléme de dépendance de library qui se fermeront mal.
le ‘machin à linker devant’ est décrit dans KaratePluginHead.asm et sert de startup à tout les plugins (voir dans mon cours asm de gurumed: dans un linkage d’exe, les .o se linke dans l’ordre passé et c’est le premier qui s’execute.)
la forme des plugins est la meme qu’un exe normal, sauf que la il fait juste un RTS (il quitte de suite.) karate lui charge le code, puis lit des pointeurs de fonctions qui se trouve aprés le rts et les execute au besoin. le reste est décrit dans la doc.
derniére pensées a propos de plugins loadseg:
delitracker était encore plus fort, sauf erreur il regardait les format servi par les plugins, les listait mais ne les chargeait pas, et les chargeait finalement au besoin suivant le module. (pour ne pas encombrer le memoire.)
Rien a voir mais tout aussi interessant: on me bassine de temps a autre pour avoir une inutile fonction ‘compile to one file’ pasquez ça fait bien sceners. c’était impossible avec les .library, avec des loadseg()… ça devient faisable (et utile: on ne linkerait que les .Fx utilisé par le script, ce qui rendrait les exe polymorphe.)
Tu peux même te débrouiller pour que le binaire principal charge des sous bordels 68k ou PPC suivant la machine hote.
c’est finalement déjà le cas pasque j’utilise l’ ‘amigaos’: pour les datatypes par exmple, c’est du code ppc natif qui est executé (et certainement pour la mixage AHI de meme)
Hip !!
@Highlander: si Ya des screenshots de la version beta sur LightOurFire.free.fr, à côté de tout ce qu’on a déjà fait sur Karate.
@Krabob: c’est trop cool… Quoi ? Tout, Karate1.0, le devkit, le ‘compile to one file’, ton avatar, tout…
@Tex: tiens, pour rajouter des prods sur le site officiel, toutes nos démos sont téléchargeables (ou mêmes linkable directement) sur liens précédent.Allez… ‘cho
!! qiH
slob, qui retourne sur son guide Karate, parce qu’il a une version de retard maintenant…
Hip !
Exact, actuellement je bosse sur un « editeur » Karate.
D’abord en RxMUI pour apprendre MUI (et aussi parce que le Rexx est suffisaement balaise en gestion de string pour que je me casse pas trop le c*l pour faire un parseur ) et ptet ensuite en C pour faire comme les grands (et aller un peu plus vite).
Je pense bientot terminer l’editeur de KScript
Clic to enlarge (le snap hein, pas votre Pen*s )
Et y a déjà un editeur de source « basique » avec un simili-debugger (genre je retrappe les message d’erreurs de Karate.; et je vais ptet faire en sorte qu’ils soient clickables.. bref comme les grands )
@+
wickedvinz: hummm j’esperrais secretement ce genre de truc pour m’essayer secretement à karaté
trop bon
/me qui esperre maintenant secretement une version MOS de karaté puis un support tinyGL
en tout cas bravo krabob pour cette petite merveille et courage wickedvinz
/me demolooser
et est sencé la fermer, mais si 2 karate sont chargé en mémoire, il y avait collision: l’intégralité du code d’une .library doit en fait etre RE-ENTRANT (construit sur sa pile uniquement.) ce qui ne pouvait pas être le cas d’un « plugins ».
il y aurait eu une solution beaucoup plus complexe en créant un espece de « serveur de structure globale dont la forme est défini par le plugins » coté appli karate, mais ça aurait rendu l’ecriture d’un plugin chiante.
Je connais pas Karaté mais il y a plein de library qui peuvent etre ouverte par plein d’applications en même temp sans ce marcher dessus.
Pourquoi ne pas mettre toutes les infos relative a un instanciation de la library dans un handle « Plugin_Open() », en ensuite faire toutes les appels avec cette handle en parametre. et a la fin Plugin_close(). Ou quelquechose comme ca.
Aussi, pour la vorbisfile_68kgate.library. J’ai créer (avec les précieux conseilles de CISC) une library a base relative. C’est a dire avec des base différentes a chaque ouvertures, ce qui permet de sauvegarder le contexte de la library pour chaque « ouvreur de lib ». En gros, il y la base pere, des bases fils. Ca doit trainer sur mon dur quelque part, je peux te le filer si tu veux.
PS: ca a l’air sympa Karate, il faut que je test!
Bye
Merci Krabob car tu partage ta science du code avec le non errudi, tu est toujour là si on te pose une question et tu est un grand maitre de la demo !!!
C’est formidable ce que tu as fais les PureLam3rs dont je fais partie te seront eternellement reconnaissant.
Enfin un mec qui tabasse …….
Bonnes vacances !!
Le PSG qui gagne la ligue des champions c'est possible ... Que dans Swos.
Amiga Morphos Rules.
8 sujets de 16 à 23 (sur un total de 23)
- 1
- 2
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Création › Karate 1.0