Revenir à Création

Karate 1.0

Forums AmigaOS, MorphOS et AROS Création Karate 1.0

8 sujets de 16 à 23 (sur un total de 23)
  • Auteur
    Messages
  • #17408
    henes
    Participant
    • Messages : 2565

    Hum, pourtant ça ressemble à des bidules partagés.

    Qu’est ce que ce machin à linker devant alors: un bidule machin truc ?

    #17409
    krabob
    Participant
    • Messages : 1170

    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)

    #17410
    slobman
    Participant
    • Messages : 1010

    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…

    #17411
    WickedVinz
    Participant
    • Messages : 616

    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 :))

    @+

    #17412
    Polymere
    Participant
    • Messages : 436

    Moi je dis respect pour les PuresLamers. Ayant déja codé se genre de programme en rxmui je dis qu’il ont fait un sacré boulot.

    Et leurs sites, et le serveur de vote de la HP² et… mais où s’arrêteront-ils ?

    /me admiratif devant tant de talents :]

    #17413
    anonyme
    • Messages : 8165

    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

    #17414
    anonyme
    • Messages : 8165

    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

    #17415
    ACE
    Participant
    • Messages : 2312

    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 !!

    Et hop une petite ligue des champions pour le fc sion à Swos 🙂 embalé c'est pesé elle est pas belle la vie !

8 sujets de 16 à 23 (sur un total de 23)
  • Vous devez être connecté pour répondre à ce sujet.

Forums AmigaOS, MorphOS et AROS Création Karate 1.0

Do NOT follow this link or you will be banned from the site!