Nouvelle convention de TSR - Page 2

Flanker
: un EV_Hook au format EvHk (enfin, la version 2, quoi) aura une liste de Hook et il va les exécuter les uns après les autres. Mais lui même sera au format EvHk, donc il ne cassera pas la compatibilité.

Si, parce que tu utilises la convention obsolète qui n'est plus acceptée par UnInEvHk (et pour de bonnes raisons, vu l'utilisation que tu y as trouvée là l'utiliser pour bootstrapper une convention concurrente ).

Mais les Hooks dans la liste, eux, seront à ma convention à moi, sans aucune compatibilité avec la tienne

Donc tu essayes d'établir une convention concurrente.

Et je préfère de loin la liste chaînée de hooks au tableau de hooks comme tu le proposes là. Il y a déjà un handle par hook, donc autant en faire une liste chaînée. Et c'est nettement plus simple de faire marcher plusieurs hooks ensemble avec la liste chaînée, parce que justement on n'a pas besoin d'un gestionnaire de hooks central comme celui que tu proposes, chaque hook est responsable d'appeler son prochain. Le choix liste chaînée (gestion décentrale) vs. tableau (gestion centralisée) était un des premiers choix d'implémentation à faire pour ma convention, j'ai choisi la liste chaînée sans hésiter.

Pollux :
Elle est vraiment belle, la mentalité ^^ Si toi, tu fais le choix d'interdire les TSR kernels et de rester à un truc plus simple, je ne vois pas en quoi tu as à te plaindre que qqun choisisse de faire un truc plus vaste qui les implémente

Si. Les ajouts de Flanker ne sont pas nécessaires (on a très bien pu travailler sans pendant 3 ans), et il veut convaincre tous les programmeurs à utiliser sa convention bloatware, fragmentant ainsi le groupe déjà petit de programmeurs de hooks d'évènements sans rien d'apporter d'utile.

Encore, si Flanker avait fait exprès de tout casser pour le plaisir d'avoir 2 conventions, d'accord, mais là c'est toi qui as refusé ses ajouts

J'avais accepté son premier tour d'ajouts, mais franchement il a tout fait pour que je le retire lui aussi: Il ne m'a pas du tout parlé de ses projets pour la nouvelle convention alors qu'il a des plans depuis assez longtemps, et il voulait imposer une nouvelle série d'ajouts en me les "proposant" une fois de plus à faits complis, attitude que j'ai déjà trouvée déplorable la première fois qu'il a fait le coup. Je veux que tout changement à apporter la convention soit discuté préalablement avec moi, et quand je dis "non", c'est "non", un point c'est tout. Sa manière d'agir vise à ne pas me laisser le choix de dire "non", et je ne me ferai plus avoir par cette astuce malhonnête. (Et puis mon avis est que ma convention est très bien comme elle est.)

après soit ils sont utiles et à ce moment-là c'était une bonne idée pour la communauté que Flanker rajoute ces possibilités (qui, sans ça, n'auraient jamais vu le jour), soit ils sont inutiles/trop lourds et à ce moment-là tu n'as pas non plus à te plaindre qu'il ait fait sa propre convention.

Si, parce qu'il veut imposer un standard concurrent, et qu'il va forcément y avoir des programmeurs qui vont suivre son "standard" même s'ils n'ont pas besoin de ses ajouts (qui sont franchement peu utiles, voire totalement inutiles, à mon avis). (Il y en a déjà un: lui-même.) Cette fragmentation est néfaste pour tout le monde: programmeurs comme utilisateurs.

Dans les deux cas, c'est tout bénéf pour les utilisateurs,

Ben non, ce n'est pas bénéfique pour les utilisateurs d'avoir à se battre avec des hooks incompatibles avec UnInEvHk pour la seule raison que le programmeur a refusé de respecter le standard établi. (Et ce n'est pas une question de gérer la convention 2.00 ou pas: même si je gérais la convention 2.00, on ne pourrait pas désinstaller des hooks individuels, juste le gestionnaire.)

alors pour toi qui dis agir pour le bien de la communauté, où est le pb ?

Que ce que fait Flanker est très mauvais pour la communauté. C'est de la fragmentation de standards microsoftienne.

Tu n'as pas l'impression par moments que l'énergie que tu mets pour que tes progs soient utilisés est parfois (souvent ?) néfaste ? Parce que, si Flanker n'avait pas eu assez de motivation pour s'opposer à toi, ça aurait été encore un n-ième projet tué dans l'oeuf ^^

Et ben, ça n'aurait été que du bien! Mais malheureusement, Flanker est une personne qui n'en fait qu'à sa tête.

Bien...

Tes réponses dans ce topic se limitent à "ce que tu veux faire est stupide", "ma solution était très bien", et autres "tu ne penses pas aux utilisateurs".

Jusqu'à preuve du contraire, rien n'empeche Flanker de faire ce qu'il veut, je vais donc en profiter pour te rappeller cette petite anecdote : http://p080.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=139.topic

Je cite : "objections from anyone except Flanker will be taken into consideration".
Sur le même model, tes trolls inutiles n'ont pas leur place ici. Tu as le choix entre poster quelque chose de constructif, ou bien alors soigner ta prochaine remarque destructive qui risque d'être la dernière de ce topic. Tu es prévenu.

K² > pour toi, le monopole c'est néfaste quand il ne t'appartient pas, et quand il t'appartient, bah il ne faut pas avoir d'offres concurrentes. Faudrait te décider un jour

l'utiliser pour bootstrapper une convention concurrente

tu préfères que je casses complètement la compatibilité ? je le fais sans problème, si tu insistes

Et je préfère de loin la liste chaînée de hooks au tableau de hooks comme tu le proposes là. Il y a déjà un handle par hook, donc autant en faire une liste chaînée. Et c'est nettement plus simple de faire marcher plusieurs hooks ensemble avec la liste chaînée, parce que justement on n'a pas besoin d'un gestionnaire de hooks central comme celui que tu proposes, chaque hook est responsable d'appeler son prochain. Le choix liste chaînée (gestion décentrale) vs. tableau (gestion centralisée) était un des premiers choix d'implémentation à faire pour ma convention, j'ai choisi la liste chaînée sans hésiter.

si tu avais suivi mon truc, tu verrais que ça ne marche pas, pour la simple raison que tous les tsr ne sont pas des hook

Si. Les ajouts de Flanker ne sont pas nécessaires (on a très bien pu travailler sans pendant 3 ans)

et pendant 2000 ans on n'a pas eu d'ordi, donc ils ne sont pas nécessaires. T'en as d'autres, des arguments comme ça ?

il veut convaincre tous les programmeurs à utiliser sa convention bloatware

tu peux me citer le passage où je l'ai dit ? Je veux juste une convention qui me permette de m'amuser avec les tsr

sans rien d'apporter d'utile.

t'es lourd. C'est pas parce que ça ne te sers à rien que c'est inutile. Encore une fois, tu me donnes l'impression de ne rien comprendre à ce que je veux faire

Il ne m'a pas du tout parlé de ses projets pour la nouvelle convention alors qu'il a des plans depuis assez longtemps

et il devait servir à quoi ce topic ?

Sa manière d'agir vise à ne pas me laisser le choix de dire "non", et je ne me ferai plus avoir par cette astuce malhonnête.

tu n'as toujours pas compris que tu n'as pas à être d'accord ou non ? quoique tu dises, je le ferais

Cette fragmentation est néfaste pour tout le monde: programmeurs comme utilisateurs.

bah oué, à bas Linux qui fragmente le monde PC en 2 !

C'est de la fragmentation de standards microsoftienne.

Mais malheureusement, Flanker est une personne qui n'en fait qu'à sa tête.

Et encore, tu me connais pas

bon, j'espère maintenant que j'aurais des réactions intelligentes, genre de PpHd ou ExtendeD

Kevin Kofler
:

Pollux :
Elle est vraiment belle, la mentalité ^^ Si toi, tu fais le choix d'interdire les TSR kernels et de rester à un truc plus simple, je ne vois pas en quoi tu as à te plaindre que qqun choisisse de faire un truc plus vaste qui les implémente

Si. Les ajouts de Flanker ne sont pas nécessaires (on a très bien pu travailler sans pendant 3 ans)

Et l'humanité a très bien pu travailler sans TI-89/92 pendant bien plus de 3 ans, alors elle n'est pas nécessaire

et il veut convaincre tous les programmeurs à utiliser sa convention bloatware, fragmentant ainsi le groupe déjà petit de programmeurs de hooks d'évènements sans rien d'apporter d'utile.

Remplace "il" par "je", "bloatware" par "incompatible kernel" et "d'utile" par "du tout", et ce sera au moins aussi vrai ^^

Encore, si Flanker avait fait exprès de tout casser pour le plaisir d'avoir 2 conventions, d'accord, mais là c'est toi qui as refusé ses ajouts

J'avais accepté son premier tour d'ajouts, mais franchement il a tout fait pour que je le retire lui aussi: <snip> Je veux que tout changement à apporter la convention soit discuté préalablement avec moi, et quand je dis "non", c'est "non", un point c'est tout. <snip> (Et puis mon avis est que ma convention est très bien comme elle est.)

Non mais je ne dis pas que tu n'avais pas de raison : j'ai aucune envie de troller là-dessus. Juste que c toi qui as décidé volontairement de les refuser, et qu'après ça tu assumes les conséquences...

Si, parce qu'il veut imposer un standard concurrent, et qu'il va forcément y avoir des programmeurs qui vont suivre son "standard" même s'ils n'ont pas besoin de ses ajouts (qui sont franchement peu utiles, voire totalement inutiles, à mon avis). (Il y en a déjà un: lui-même.) Cette fragmentation est néfaste pour tout le monde: programmeurs comme utilisateurs.
Ben non, ce n'est pas bénéfique pour les utilisateurs d'avoir à se battre avec des hooks incompatibles avec UnInEvHk pour la seule raison que le programmeur a refusé de respecter le standard établi. (Et ce n'est pas une question de gérer la convention 2.00 ou pas: même si je gérais la convention 2.00, on ne pourrait pas désinstaller des hooks individuels, juste le gestionnaire.)

(mdr pour les guillemets autour de "standard" )
Excuse-moi, mais le standard établi, c'est pas UnInEvHk 3.00, c UnInEvHk 2.00. A partir de là, il se trouve que UnInEvHk 3.00 a un nom qui y ressemble bcp, mais elle n'a rien de plus établi que le standard de Flanker... (surtout qu'en plus elle est incompatible avec la version précédente)

alors pour toi qui dis agir pour le bien de la communauté, où est le pb ?

Que ce que fait Flanker est très mauvais pour la communauté. C'est de la fragmentation de standards microsoftienne.

#troll#
Le fait de supprimer les fonctions du standard v2 rien que pour faire chier Flanker, c *aussi* de la fragmentation de standards microsoftienne.

Parce que, si Flanker n'avait pas eu assez de motivation pour s'opposer à toi, ça aurait été encore un n-ième projet tué dans l'oeuf ^^

Et ben, ça n'aurait été que du bien! Mais malheureusement, Flanker est une personne qui n'en fait qu'à sa tête.

Qui ne t'obéit pas au doigt et à l'oeil tu veux dire

Ne vous montez pas la tête comme deux enfants
J'espère que je me trompe, mais à mon avis Kevin et Flanker, vous êtes trop possessifs l'un comme l'autre de 'vos' conventions.
Peu importe que ce soit un tel ou un tel qui établisse ce qu'on va utiliser, il ne l'aurait établit ni sans l'autre, ni certainement sans l'ensemble de la communauté.

Et je pense que nous serons tous d'accord pour une convention ou plusieurs du moment que la décision est prise dans le meilleur intérêt de la communauté.
Alors argumentons sur le sujet, sans entraîner cette possibilité d'évolution dans un clash dont personne ne veut... Ce serait trop bête

Kevin, sans toi, la communauté n'en serait pas où elle est... Elle serait bien en retard.

Flanker, tu lances une bonne initiative, et je suis sûr que même si Kevin n'est pas trop enchanté, il y participera quand même, comme il fait avec PreOS malgré sa légendaire _nostub-philie Me trompe-je ?

Tu connais pas bien Kevin toi...

vous êtes trop possessifs l'un comme l'autre de 'vos' conventions.

elle existe pas encore comment je pourrais être possessif ? et moi au moins, ça me dérange pas que personne d'autre ne l'utilise. Je ne cherche pas à avoir mon nom partout

Kevin, sans toi, la communauté n'en serait pas où elle est... Elle serait bien en retard.

mouais, faut pas exagérer, hein

il y participera quand même,

il a fait exprès de faire régresser sa convention pour m'emmerder, et il a pas l'air de vouloir participer.

Alors argumentons sur le sujet

bah dis-le à K²

nitro
Tu connais pas bien Kevin toi...

Sur certains points peut-être, même certainement.
Mais je ne douterai jamais de sa magnanimité, et c'est tout ce qui importe.
Enfin, c'est pas le sujet.

Flanker
elle existe pas encore comment je pourrais être possessif ? et moi au moins, ça me dérange pas que personne d'autre ne l'utilise. Je ne cherche pas à avoir mon nom partout

Bien, je suis content de m'être trompé.

Mais je ne douterai jamais de sa magnanimité, et c'est tout ce qui importe

.
je crois que tu le connais vraiment mal

Kevin est contre les kernels, pourtant voilà ce qu'écrit PpHd dans ses remerciements de PreOS:

- Kevin Kofler <kevin.kofler@chello.at> ( without him, I wouldn't have worked on PreOs ! ) for its advises and HW2TSR

Même s'il défend un peu trop les idées qu'il a, je suis sur que vous vous entendrez.

Moi pas... Je ne sais pas trop sur quoi tu le juges, mais surement pas sur les mêmes choses que nous. Et à part le readme de PreOS que tu nous cite pour la deuxième fois, je ne vois pas...

Je te conseille de faire un petit tour dans certains topics de ce forum, peut-être que tu te rendras compte par toi-même.

JM_ > ça fait combien de temps que tu es ici ?

Flanker
JM_ > ça fait combien de temps que tu es ici ?

Ca va bientôt faire 3 ans. Pfiou... ca passe vite.

@Vertyos
Je te conseille de faire un petit tour dans certains topics de ce forum, peut-être que tu te rendras compte par toi-même.

Si seulement l'ADSL arrivait dans ma montagne...

Pour ce qui est du reste, je ne chercherai certainement pas à vous faire changer d'avis sur Kevin, je ne peux que donner mon modeste point de vue.
Voilà tout.

Bon code

Kevin> Tu vraiment une pauvre mentalité : tu refuses d'accepter de mettre à jour ta convention pour suivre les évolutions proposées par Flanker, et après, tu l'accuses lui de vouloir fragmenter la communauté.
La seule chose qui t'ennuie dans la convention de Flanker, c'est qu'elle ne vient pas de toi.
C'est bien dommage.

Flanker> Je ne comprends pas trop ça (quel intérêt ? Minimiser le nombre de handles utilisés ?) :

Flanker
: - dans un seul handle il puisse avoir plusieurs types de tsr (trap, hook, auto-int)

partage de code au maximum, par exemple un kernel ou h220xstsr pourrait suivre cette convention, ce qui ne serait pas le cas autrement. Je veux un truc qui soit le plus souple possible, afin de ne pas avoir à le faire évoluer

(au passage, merci pour ce premier post dans le sujet)

Pour l'importation de fonctions, tu comptes t'y prendre comment ?

Et pourquoi penses-tu qu'une liste de handle est plus intéressante qu'une liste chainée de hooks ?

Tout d'abord, salut a tous.
Kevin, tu ne me connais pas, d'ailleurs ici personne ne me connait.
Et pourtant je suit l'évolution de la communauté TI depuis 6 ans (oui t'as bien lu, six ans.)
Je ne me suis jamais vraiment impliqué dedans pour de simples raisons personnelles.
Et sauf événement particulier je ne m'y impliquerait pas dans l'avenir.
Je resterai en mode "Ghost" comme je l'ai toujours fait.
Mais moi, je te connais. Je te connais a force de "subir" tes posts sur des sujets interressants.
Alors voilà, si j'ouvre ma gueule aujourd'hui (mais rassure toi je part de suite en vacances pour queqlues jours donc je te laisserai tranquille par la suite)
c'est simplement pour te dire ce que je pense de toi - d'apres tout ce que j'ai lu venant de toi - sans détours.
Alors voilà, je pense que t'es un qu'un "sale gros fouteur de merde" ou plus précisément - et pour rester poli :
tu es si je peut appeler ça comme ça, un 'régressiste' !
Par là j'entend que tu cherches a imposer des standards qui n'ont aucune compatibilité descendante (c'est a dire que ton standard n'a aucun espoir d'évolution mais tu m'aura compris.).
En clair : je t'aime pas.
Et n'oublie pas une chose : c'est l'utilisateur final qui est roi, pas le programmeur. Donc il faut adapter tes standards aussi souvent que l'utilisateur en a besoin.
Bon voilà, je doit y aller j'ai plus le temps, si tu veux on discutera de ça une autre fois mais là je suis vraiment pressé.
Et une derniere chose : SURTOUT, NE ME JUGES PAS. Car tu ne me connais pas alors que moi je te connais suffisament pour te dire tout ca.
Je ne dirai que ça d'ailleurs.
Sur ce, bonnes vacances a tous et que l'été soit productif a tout le monde

Et pourquoi penses-tu qu'une liste de handle est plus intéressante qu'une liste chainée de hooks ?

Une liste de handles est plus simple à gérer, surtout que je veux traiter exactement de la même façon les trap et les hooks.
En plus, ce système permet de désinstaller un TSR sans connaître le début de la liste chaînée (pratique si des TSR incompatibles sont installés) et permet également de faire facilement le lien entre les différentes fonctions (trap/hook/autoint) qui sont dans le même bloc. Si on doit parcourir toutes les listes chaînées de toutes les autoint/trap/hook à chaque fois qu'on veut désinstaller un tsr, c'est le bordel.
En plus, il faudrait regrouper pour chaque fonction du même handle un header, ce qui prendrait de la place pour rien.

Bon, je résume la situation, le TSR de Flanker est une extension de max(evhkconv2,evhkconv3), et permet donc de désinstaller tous les autres TSRs (mais évidemment Uninevhk ne peut pas [ou pas encore] désinstaller ceux qui utilisent les extensions de Flanker.

Reprise de la discussion sur IRC :

(23:13:09) <@Kevin_Kofler> Ben, maintenant, c'est TROP TARD pour faire un nouveau standard.
(23:13:13) <@Kevin_Kofler> Le mien est déjà établi.
(23:13:16) <Pollux> Kevin_Kofler » bah non
(23:13:21) <Pollux> on peut étendre le tien
(23:13:23) <Pollux> je vois pas de pb
(23:13:26) <@Kevin_Kofler> Parce que pendant 3 ans, tous les développeurs de hooks m'ont suivi!
...
(23:18:33) <Pollux> Kevin_Kofler » alors explique pourquoi on peut améliorer C89 en C99
(23:18:44) <Pollux> et pas Evhk3 en FlankerTSR
(23:19:01) <@Kevin_Kofler> Parce que le C99 est COMPATIBLE avec le C89.
(23:19:12) <Pollux> oui, de manière ascendante
(23:19:27) <Pollux> comme pour le TSR de Flanker, qui est compatible de manière ascendante
(23:19:33) <Pollux> donc je vois pas de différence
(23:19:34) <@Kevin_Kofler> Non.
(23:19:46) <@Kevin_Kofler> UnInEvHk (même la 3.00) ne voit même pas ses TSRs!
(23:19:51) <Flanker`{brownie}> et alors?
(23:19:59) <Flanker`{brownie}> ça les empêche de fonctionner ?
(23:20:04) <Flanker`{brownie}> mes TSR ?
(23:20:03) <Pollux> Kevin_Kofler » de mêm qu'un compilo C89 ne compile pas un C99
(23:20:07) <Pollux> c exactement la même chose
(23:20:15) <Pollux> tu te trompes de sens Kevin_Kofler
...
(23:21:10) <Pollux> Kevin_Kofler » awaiting reply... (23:21:31) <@Kevin_Kofler> Pollux> Rejected (request timeout).

Bon, j'espère que c'est un peu plus facile à suivre comme ça...

Donc je réitère ma question, tu te trompes de sens en disant que les TSR de Flanker sont incompatibles : oui, il n'y a pas de compatibilité descendante, mais c'est normal, c'est le principe d'une extension, et c'est pareil pour C89 -> C99... Donc en quoi les TSRs de Flanker "fragmenteraient" les utilisateurs, alors que le C99 n'a rien fragmenté du tout ?

[dsl Flanker, des remarques sans grand rapport avec ton topic vont suivre]

Les ajouts de Flanker ne sont pas nécessaires (on a très bien pu travailler sans pendant 3 ans), et il veut convaincre tous les programmeurs à utiliser sa convention bloatware

l'humanite a tres bien pu evoluer sans toi et tigcc, pourtant tu viens foutre ta merde partout. ca te fait bander d'avoir ton nom marque dans des readme et sur des sites web de ti? ca te donne l'impression d'etre quelqu'un d'important et d'indispensable? et t'aime ca? et tu serais pret a decouper a coups de tronconneuse quiconque OSERAIT © faire de l'ombre (a tes yeux) a tes creations cheries?
votre probleme est enfoui bien plus profondement cher ami, mais ou?

C'est de la fragmentation de standards microsoftienne.

tu devrais jeter ton windows ME immediatement, et tous les softs de M$ © que tu possedes, ou bien arreter de cracher dessus comme si c'etait une sombre merde d'une bete ignoble qui te repugne alors que tu l'utilise toi meme. t'es vraiment un hypocrite... reste sur ta fedora core si microsoft te degoute tant... t1 bordel cpa vrai ca..

JM_> heu c'est JM sans underscore? O_o (ca me parait tres peu 3 ans, donc je suppose que non c'est pas le meme )

EDIT: heu je viens de voir d'autres posts de JM_ dans le forum assembleur, oubliez ma derniere phrase

C'etait quoi le sujet deja ? Je suis perdu par le troll...

sBibi > nan c'est pas JM
PpHd > post1, puis ça reprend au post 46

Flanker: y aurais moyen d'avoir une forme conventionelle pour les TSR poru en faire une forme de Lib utilisable par un prog en C/ASM Kernel/nostub un peu dans le meme sens que fonctionne la F-Line (ou A-Line)

Il me semble que TI n'utilise pas le trap Illegal Instruction pour trapper des inscrutions, ça pourrait etre une idée nan ?

genre

MACRO DoLib(LibID,FuncID)
 illegal
 dc.w LibID
 dc.w FuncID
ENDM

le hookmaster recupere le LibID, retrouve la lib dans la table de hook/tsr/trap et lui fait executer une routine définie qui fait jumper a la bonne fonction (FuncID quoi)
Cela pourrait etre aussi simplement un wrapper vers des lib kernel standard

Je sais, ça ressemble fortement a des lib kernel qq pars Mais cela pourrait permettre justement l'accés a des lib en nostub sans avoir a ce faire *chier*

J'avais un tel projet en tete a une epoque, j'avais meme commencer et j'utilisait la FLine, mais ti m'a fait chier en sortant leur FLined RomCall et j'ai abandonnée mon projet de lib


Qu'en penses tu ?

c'est pas facile de distinguer entre un illegal et un appel de lib, comme ça
et ça revient à mettre un kernel light (surtout qu'il y aura des pb, vu que le kernel voudra restaurer ce vecteur). Pour les importations / exportations, je pense juste faire un relogement à l'installation du tsr, comme ça il n'y aura pas de pb (mais du coup, ça impose une lib qui fera toute l'installation, vue que du coup elle sera quand même plus complexe)

Flanker :
c'est pas facile de distinguer entre un illegal et un appel de lib, comme ça

Certe, mais ce n'était qu'un exemple, et si on va par la un FLine involontaire peut aussi provoquer des choses bizzares

Un MagicWord peut apparaitre avant les dc.w correspondants au fonction un mettre un simple octet (ou un word) correspondant a un cheksum de funcid/libid

et ça revient à mettre un kernel light (surtout qu'il y aura des pb, vu que le kernel voudra restaurer ce vecteur). Pour les importations / exportations, je pense juste faire un relogement à l'installation du tsr, comme ça il n'y aura pas de pb (mais du coup, ça impose une lib qui fera toute l'installation, vue que du coup elle sera quand même plus complexe)

Certe.. Mais si ta convention est kernel friendly le kernel sera deja présent et il pourrait faire le boulot

bon, comme j'avais un peu de temps libre pendant mes vacances, j'ai pas mal avancé - à vrai dire c'est presque fini - mais comme j'ai la flemme de tout taper faudra attendre
le sel problème, c'est que j'ai besoin d'un handle central, et je me demande si je vais pas la rendre kernel-only pour que ce handle soit fourni par le kernel (ça m'évitera d'utiliser une adresse absolu pour y mettre le handle)