 |
| Pointeur NULL en Rebol | |
| ldci | 17-Sep-2008/12:23:04+2:00 |
| Salut à tous Qui aurait une idée pour créer un pointeur NULL en rebol? En C on a #define NULL ((void*) 0) Merci d'avance | |
| guest2 | 17-Sep-2008/16:21:46+2:00 |
| En principe c'est un entier qui vaut 0. donc en REBOL, NULL: 0 | |
| ldci | 17-Sep-2008/21:31:45+2:00 |
| Merci Guest 2, mais dans mes souvenirs, le C fait en sorte que rien ne se trouve à l'adresse 0 ; un pointeur générique vers cette adresse ne pointe donc sur rien ou du moins sur aucune adresse valide.`La question est de savoir si Rebol peut faire la même chose. Imaginons une structure comme suit null: make struct! [uInt32 [integer!]] [0] qui permet de simuler un pointeur en Rebol. Sur quoi va t-elle pointer? l'adresse mémoire du 0 ? ou autre chose? J'avoue que j'y perds mon latin! | |
| guest2 | 17-Sep-2008/22:19:08+2:00 |
| voyons voir... >>s: make struct [str [string!]]["test"] >>s/str == "test" pour obtenir l'adresse du string! en mémoire on fait: >> third s == #{88F2FC00} c'est donc bien un entier 32 bits maintenant, réintialisions cette adresse à 0. >> change third s #{00000000} attention de bien faire faire un change et pas un set. >> s/str == none cool! Rebol a l'air de bien gérer le pointeur null. Ca répond à ta question ? maintenant si on met l'adresse du string à 0 | |
| ldci | 17-Sep-2008/22:49:20+2:00 |
| Cool Guest2: je vais tester ça demain. Merci du tuyau. A + | |
| guest2 | 17-Sep-2008/23:26:43+2:00 |
| En bidouillant avec les structs, j'ai découvert un nouveau truc. On peut dumper la mémoire de rebol. REBOL []
s: make struct! [str [string!]] ["première chaine"]
adr: to integer! reverse third s ;*** on récupère l'adresse de "première chaine"
s1: "créons un autre chaine" ;*** puis on crée des strings bidons
s2: "puis une autre"
b: make struct! [str [binary!]] #{00} ;*** ça c'est un struct qui va se balader dans la mémoire
loop 30 [
change third b bin: reverse debase/base to-hex adr 16
print [bin b/str]
adr: (to integer! (length? b/str) + 16 / 16) * 16 + adr
]
haltet on obtient un truc dans le genre: #{10CFF800} première chaine
#{20CFF800}
#{30CFF800} '
#{40CFF800}
#{50CFF800} créons un autre chaine
#{70CFF800} puis une autre
#{80CFF800}
#{90CFF800}
#{A0CFF800}
#{B0CFF800}
#{C0CFF800}
#{D0CFF800} créons un autre chaine
#{F0CFF800} #{10CFF800} première chaine
#{10D0F800} créons un autre chaine
#{30D0F800} créons un autre chaine
#{50D0F800} #{70CFF800} puis une autre
#{70D0F800} créons un autre chaine
#{90D0F800} #{10CFF800} première chaine
#{B0D0F800} #{10CFF800} première chaine
#{D0D0F800} créons un autre chaine
#{F0D0F800} créons un autre chaine
#{10D1F800} créons un autre chaine
#{30D1F800} créons un autre chaine
#{50D1F800} #{70CFF800} puis une autre
#{70D1F800} #{70CFF800} puis une autre
#{90D1F800} créons un autre chaine
#{B0D1F800} créons un autre chaine
#{D0D1F800} #{10CFF800} première chaine
#{F0D1F800} #{10CFF800} première chaine
#{10D2F800} #{10CFF800} première chainePourquoi ces répétitions ? Ce qu'il faut comprendre c'est que le fait d'afficher le résultat dans la console provoque la création de nouveaux strings dans la mémoire de rebol. Par contre, on voit aussi que c'est loin d'être optimisé car rebol s'amuse à recréer plusieurs fois la même chaine. On peut aussi aller dans l'autre sens, à vous de voir... | |
| shadwolf | 28-Sep-2008/12:23:54+2:00 |
| Interressant et tres parlant cet example. Tu devrais poster sur le blog de dev R3 car si y a bien un truc qui ne changera pas dans R3 c'est la gestion de la mémoire que tout le monde trouve parfaite. | |
| shadwolf | 28-Sep-2008/12:24:25+2:00 |
| Interressant et tres parlant cet example. Tu devrais poster sur le blog de dev R3 car si y a bien un truc qui ne changera pas dans R3 c'est la gestion de la mémoire que tout le monde trouve parfaite. | |
| shadwolf | 28-Sep-2008/12:34:56+2:00 |
| Moi ca fait longtemps que je dénonce l'aspect heu ... comment dire ca sans se foutre tout le monde a dos? .... l'aspect "en chantier" de rebol 2. Aspect en chantier tellement en chantier que Carl Sassenrath dans un premier temps nous a proposer une série de bug correcting il a mis en place rambo. Et devant l'afflu des messages pour dictée des bugs sur rambo a décider de tout changer et de faire R3. Oui mais voila Carl comminuque sur des aspects marginaux de R3. Force est de constaté que sur son blog les aspect fondementaux ne sont pas abordé comme la gestion de mémoire. Et quand j'essaie d'amener la discution sur les choses essentielles (comme la gestion de la mémoire dans rebol) je reçois systématique une fin de non recevoir. Le genre de réponse qu'on m'a encore faite y a pas si longtemps genre tu mets tes variables à none et tu appelles recycles ont le don de profondément m'énnerver. none/recycle n'a aucun impacte sur la gestion "interne de rebol" les copie de copie de copie que rebol crée tout seul sans nous demander notre avis comme ton example le montre si bien. Et ca c'est en partie du à l'aspect percistant des données en mémoire. | |
| shadwolf | 28-Sep-2008/12:36:20+2:00 |
| Moi ca fait longtemps que je dénonce l'aspect heu ... comment dire ca sans se foutre tout le monde a dos? .... l'aspect "en chantier" de rebol 2. Aspect en chantier tellement en chantier que Carl Sassenrath dans un premier temps nous a proposer une série de bug correcting il a mis en place rambo. Et devant l'afflu des messages pour dictée des bugs sur rambo a décider de tout changer et de faire R3. Oui mais voila Carl comminuque sur des aspects marginaux de R3. Force est de constaté que sur son blog les aspect fondementaux ne sont pas abordé comme la gestion de mémoire. Et quand j'essaie d'amener la discution sur les choses essentielles (comme la gestion de la mémoire dans rebol) je reçois systématique une fin de non recevoir. Le genre de réponse qu'on m'a encore faite y a pas si longtemps genre tu mets tes variables à none et tu appelles recycles ont le don de profondément m'énnerver. none/recycle n'a aucun impacte sur la gestion "interne de rebol" les copie de copie de copie que rebol crée tout seul sans nous demander notre avis comme ton example le montre si bien. Et ca c'est en partie du à l'aspect percistant des données en mémoire. | |
| shadwolf | 28-Sep-2008/12:37:08+2:00 |
| chrome a des problèmes avec ce forum je poste systématiquement en double. ^__^ | |
| shadwolf | 28-Sep-2008/12:55:13+2:00 |
| la réponse de Carl à ce problème c'est de faire un 3 eme type de fonction ou toute les variable qui y seront déclarées seront locales à cette fonction. Qu'en j'ai le toupet de demandé si les donnée contenues dans les dites variables seront réellement effacée de la mémoire et non les pointeurs vers les données oubliés par rebol. Pour toute réponse j'ai un truc du style appel recycle il ferra le boulot. | |
| guest2 | 29-Sep-2008/15:29:46+2:00 |
| Vaste sujet Shad. Après toutes ces années moi aussi pas mal de trucs me frustrent. Des avancées promises par Carl ou ses colistiers mais jamais implémentées, y'en a eu un paquet. Pour ce qui est de la gestion mémoire, je pense effectivement que Rebol est très (trop ?) gourmand mais c'est un choix de conception fait par Carl depuis longtemps. Rebol est un VM (machine virtuelle). Il y'a de nombreuses façons d'implémenter la taille du bytecode (la taille de l'instruction ou valeur élémentaire). En général plus le bytecode est court moins il est rapide. Mais ce n'est pas toujours vrai. Dans le cas de Rebol, Carl a fait le choix de fixer la taille de la brique élémentaire à 16 octets. C'est ennorme, On le voit quand on se met à faire du VIEW. La moindre petite fenêtre graphique fait monter l'occupation mémoire à pas moins de 10 Mo. Je comprends très bien son choix, ça simplifie beaucoup de choses on niveau de la gestion de la mémoire et de la rapidité du code d'avoir une taille de bytecode fixe la plus large possible (pour contenir tous les types de données). Et ça permet d'écrire une VM très petite et simple donc plus facilement portable. il n'en reste pas moins que ce n'est pas plus rapide que les autres langages scripts mais que ça consomme beaucoup plus de mémoire à l'usage. Avec le temps, j'en viens à douter des choix faits par Carl. A quoi sert-il d'avoir une VM super petite, si c'est pour ne pas pouvoir l'utiliser sur des système légers type téléphone parce que c'est trop gourmand en gestion mémoire. Bon et puis y'a le problème de VID2 et surement de VID3 à venir. Il y a trop de lacunes pour pouvoir faire des applications graphiques professionnelles. Le fait qu'on soit tous incapable de faire un simple Editeur de texte fonctionnel (type RTE) en pure Rebol depuis toutes ces années montre non pas que la communauté Rebolienne est nulle en dev mais plutôt que Rebol a | |
| guest2 | 29-Sep-2008/15:39:42+2:00 |
| ...montré ses limites. Et je crains que le futur VID3 n'arrange rien de ce côté. Je ne veux pas jouer les oiseaux de mauvais augure mais j'avais déjà eu raison avec la première version de VID3. J'avais dit à l'époque que c'était une usine à gaz. Carl en est venu finalement au même constat et a decidé de toute refaire lui même il y'a quelques temps. Mais je ne suis pas rassuré pour autant, il fait tous les choix seuls comme d'habitude. Ah si, il nous questionne pour choisir le futur nom de VID3, chose dont j'ai personnellement rien à foutre. Par contre pour ce qui est des choix fondamentaux à faire pour le futur VID3, on ne sait rien ou presque. Perso je suis inquiet, J'ai toujours trouvé que Carl nous questionnais via son blog sur des points de détail sans intérêt la plupart du temps alors que pour l'essentiel on est rarement consulté. | |
| guest2 | 29-Sep-2008/16:02:15+2:00 |
| ...Encore plein de choses à dire. On pourrait aussi parler des lacunes de Rebol concernant la gestion des fichiers notemment en accès direct. Après toutes ces années c'est encore buggué. Quasi impossiblité également de créer un système d'indexation pour les gros fichiers. La possiblité de gérer des index type hash non pas en mémoire mais en fichier en accès direct devrait être native en Rebol, ça résoudrait pas mal de problèmes notemment au niveau de l'occupation mémoire (tout charger en mémoire comme c'est fait actuellement par tous ceux qui développent des dialectes pour gérer de minis BDD n'est pas une solution viable). J'ai un peu bossé sur la question et j'ai faits quelques tests pour créer des listes triées dans des fichiers en accès direct de type skip-list mais ça reste quand même très lent dés qu'il faut gérer des dichiers de plusieurs dizaines de Mo. Enfin bref, trop de lacunes je vous disais... | |
| guest2 | 29-Sep-2008/16:20:46+2:00 |
| Et pour finir... Parlons un peu de l'instruction copy qui est largement employée dans nos scripts et qui est largement responsable de la consommation outrageante de mémoire. Réduire l'usage de l'instruction copy (et de reduce aussi, tiens!) dans nos scripts permet une économmie significative de mémoire. Mais dans bien des cas on a pas d'alternative au copy/part. Ce qui nous manque c'est la possiblité de pointer dans une série sur une longueur précise, un offset. Bref un copy/part qui ne copie pas vraiment mais qui permet de travailler facilement sur une portion de la série. A un momment les discussions étaient partis la dessus mais depuis on a pas eu de nouvelle et je doute que ce sera implémenté dans R3. C'est tout pour le moment  | |
| guest2 | 29-Sep-2008/17:13:48+2:00 |
| Tiens, à propos de discussions qui n'ont pas grand intérêt, on a eu ça dernierment sur le blog de Carl: >> GUI Survey - Do you want panel embedded styles? Peu importe que l'on puisse modifier un style directement dans un panel ou en dehors. Ce qui compte c'est qu'on puisse modifier les styles facilement, point. Je suis intervenu d'ailleurs en ce sens mais je n'ai pas été bien compris (mon anglais est plutôt mauvais). J'ai eu droit à un cours de la par de sieur' Brian Hawley m'expliquant le métier de développeur, bref rien à voir avec le shmilblik. /mode pleureuse activé. Mais j'ai l'habitude venant de lui, déjà à l'époque ou je tentais d'intervenir sur l'évolution de R3 en proposant des évolutions sur les fonctions standards (j'ai posté quelques scripts via RebDev) le gugus passait son temps à refuser mes modifications sous des prétextes bidons et en jouant les grand experts (quelques unes de mes modifications ont quand même été intégrées) Son ton hautain a fini par me gaver et j'ai cessé d'intervenir. /mode pleureuse désactivé. | |
| Didec | 29-Sep-2008/18:42:02+2:00 |
| Juste, SVP, évitons de discuter dans un thread sur des sujets qui ne le concerne pas vraiment. RebBB ne permet pas encore à un modo de forker les threads. Alors, un peu d'auto discipline sur ce point je vous pris. D'avance Merci | |
|
Login required to Post. | |