Caractères spéciaux dans le débugger
Caractères spéciaux dans le débugger
Bonjour, si quelqu'un à une explication pour ce comportement je suis preneur :
Re: Caractères spéciaux dans le débugger
Ce n'est pas simple d'apporter une réponse si la question est trop générale. Et l'image n'aide pas des masses : elle est partielle et un peu pèle-mêle. Aussi, si on ne sait pas ce que tu connais déjà, ben on ne sait pas par où démarrer un argumentaire pour rester assez concis.
Une réponse serait de dire que l'éditeur a sa propre fonte dans un format de caractère et que, déjà, le programmeur peut choisir une fonte.
Et le débogueur a une fonte qui peut aussi être choisie mais plusieurs format de caractères sont disponibles.
L'EditorGadget suit la même logique d'affichage que le débogueur. Donc il y a une prise en charge par la GUI de l'OS qui diffère selon l'OS.
Mais ça, c'est une réponse dans les grandes lignes. Je ne peux pas beaucoup plus précis sans un peu plus de précisions dans la question (pour ma part en tout cas, car des formats de caractères, il y en a peut-être 2000...).
Une réponse serait de dire que l'éditeur a sa propre fonte dans un format de caractère et que, déjà, le programmeur peut choisir une fonte.
Et le débogueur a une fonte qui peut aussi être choisie mais plusieurs format de caractères sont disponibles.
L'EditorGadget suit la même logique d'affichage que le débogueur. Donc il y a une prise en charge par la GUI de l'OS qui diffère selon l'OS.
Mais ça, c'est une réponse dans les grandes lignes. Je ne peux pas beaucoup plus précis sans un peu plus de précisions dans la question (pour ma part en tout cas, car des formats de caractères, il y en a peut-être 2000...).
Re: Caractères spéciaux dans le débugger
Je pensait que c'était assez explicite sur le gif mais visiblement non.
Pourquoi est-ce que le caractère "␜" (U+241c Symbol for File Separator) apparaît, selon l'amplitude et la position de la sélection, tantôt normalement, tantôt comme un caractère non géré par la police de caractère utilisée ?
S'il peut être affiché dès fois, il devrait bien pouvoir être affiché tout le temps non ?
Pourquoi est-ce que le caractère "␜" (U+241c Symbol for File Separator) apparaît, selon l'amplitude et la position de la sélection, tantôt normalement, tantôt comme un caractère non géré par la police de caractère utilisée ?
S'il peut être affiché dès fois, il devrait bien pouvoir être affiché tout le temps non ?
Re: Caractères spéciaux dans le débugger
Il faut que ce soit quelqu'un qui peut voir les GIF qui te réponde. Je suis l'une des rares personnes à ne pas pouvoir voir GIF mais pouvoir communiquer quand même : ça a le maigre avantage de pouvoir informer que je ne vois pas les GIFs.
Re: Caractères spéciaux dans le débugger
Qu'est-ce que «Visual Ascii»? GIF n'affiche pas toutes les valeurs hexadécimales.
Je soupçonne que cela a à voir avec le mélange de l'encodage UTF8 avec l'encodage Unicode16.
Je soupçonne que cela a à voir avec le mélange de l'encodage UTF8 avec l'encodage Unicode16.
Re: Caractères spéciaux dans le débugger
@Demivec : En fait j'essaye de faire un pseudo visualiseur hexadécimal qui expliquerait à quoi correspond chaque groupe d'octet en fonction du format de fichier concerné. (Un peut comme le détail des packets dans Wireshark)
Le code dans le débugueur au moment ou j'ai fait le gif était le test (réussi) des fonctions permettant d'avoir l'affichage en hexa décimal et en pseudo-ascii du contenu du fichier. (Pour le test, j'utilisai randomdata() pour générer les données.) "Visual Ascii" correspond à l'affichage visuel du contenu comme si c'était de l'ascii (d'où les caractères spéciaux pour représenter les caractères de contrôle).
Le code dans le débugueur au moment ou j'ai fait le gif était le test (réussi) des fonctions permettant d'avoir l'affichage en hexa décimal et en pseudo-ascii du contenu du fichier. (Pour le test, j'utilisai randomdata() pour générer les données.) "Visual Ascii" correspond à l'affichage visuel du contenu comme si c'était de l'ascii (d'où les caractères spéciaux pour représenter les caractères de contrôle).
Re: Caractères spéciaux dans le débugger
D'après ce que tu expliques, je pense que le mieux est d'activer l'Unicode et de choisir une police stable dans les préférences de l'IDE.
Mesa (et d'autres, bien avant) avait proposé "Consolas" ou "Lucida", police cross-plateforme qui est stable de 32 à 255 - 32.
Si tu veux mieux (255 caractères standard) ça tombe bien pour 2 raisons :
1) Les sprites, ce langage c'est son dada, 1 caractère par sprite, c'est très performant, même sur les vieilles config. Et si tu veux mieux, Ogre a cette force d'être exécutable aussi sur de vieilles config : 1 caractère par quad de 4 sommets.
2) Si on exclut les sprites et la 3D, et qu'on se restreint à la GUI de l'OS, moyennant un tableau fixe de 256 cellules, la plupart des polices activent bien les 256 symboles de la page de code 437 sous Windows, 1ère des tables ASCII 8 bits ou 1278 sous Windows, successeur de la 437. Pour Linux, je botte en touche.Tu lui envoies un ASCII et il te fournit l'Unicode à afficher avec Debug ou autre.
Un 3 : OpenGL sur le principe du 1 avec une table pré-enregistrée.
Le débogueur c'est une rustine ou un échafaudage. L'idéal c'est la bonne vieille grille de caractères.
@Demivec
Effectivement, c'est un problème de format de caractères. Seulement, si je n'ai pas la même table qui s'affiche, c'est impossible d'avancer. Pas simple les devinettes sans code ! Et... Autant, je suis un cauchemar pour me faire comprendre en anglais, autant ton phrasé devient irréprochable !
Code : Tout sélectionner
; Active l'Unicode par un préfixe UTF-8 qui active une plage de 2^16 caractères
Define.U U = $3000
Debug PeekS(@U, 1)Si tu veux mieux (255 caractères standard) ça tombe bien pour 2 raisons :
1) Les sprites, ce langage c'est son dada, 1 caractère par sprite, c'est très performant, même sur les vieilles config. Et si tu veux mieux, Ogre a cette force d'être exécutable aussi sur de vieilles config : 1 caractère par quad de 4 sommets.
2) Si on exclut les sprites et la 3D, et qu'on se restreint à la GUI de l'OS, moyennant un tableau fixe de 256 cellules, la plupart des polices activent bien les 256 symboles de la page de code 437 sous Windows, 1ère des tables ASCII 8 bits ou 1278 sous Windows, successeur de la 437. Pour Linux, je botte en touche.
Code : Tout sélectionner
Structure CP
U.U[256]
EndStructureUn 3 : OpenGL sur le principe du 1 avec une table pré-enregistrée.
Le débogueur c'est une rustine ou un échafaudage. L'idéal c'est la bonne vieille grille de caractères.
@Demivec
Effectivement, c'est un problème de format de caractères. Seulement, si je n'ai pas la même table qui s'affiche, c'est impossible d'avancer. Pas simple les devinettes sans code ! Et... Autant, je suis un cauchemar pour me faire comprendre en anglais, autant ton phrasé devient irréprochable !
Re: Caractères spéciaux dans le débugger
Euh... Ça marche Naheulf ?
Une autre piste à vérifier : la taille de la police. Peut-être que l'anomalie est "cross-plateforme". Sous Linux, une sélection fait aussi des artefacts d'effacement. J'augmente l'échelle : tout va bien...
Une autre piste à vérifier : la taille de la police. Peut-être que l'anomalie est "cross-plateforme". Sous Linux, une sélection fait aussi des artefacts d'effacement. J'augmente l'échelle : tout va bien...
Re: Caractères spéciaux dans le débugger
Le problème, c'est que remplace les caractères de contrôles de la plage 0-255 par le caractère correspondant du bloc unicode "Control picture" https://en.wikipedia.org/wiki/Control_Pictures#Block. Or, le glyphe de ces caractères n'est pas inclus dans un certain nombre de polices... Donc le choix et limité.