Discussion :

[Jipété]

Bonjour,

toujours dans la misère de la migration 32 --> 64 bits Laz 1.4.0 --> 2.0.12 FPC 2.6.2 --> 3.2.0, voilà ce que j'ai vécu ce matin tôt.

J'ouvre un ancien projet, F9 c'est joli tout plein pour jouer avec les couleurs, bref, ça fait des années que je développe des trucs comme ça :


Ce matin je passe tous les fichiers de code du projet dans la nouvelle machine, F9 et patatras :


Et je ne parle pas du RadioBox dont la Caption est barrée, on en ai déjà causé, va falloir que je déclare un bug (je ne sais pas comment, si qqun a une idée, merci).

Il m'aura fallu un temps dément pour trouver la solution, toute simple pourtant : dans un module complémentaire où j'ai plein de routines en rapport avec le traitement des couleurs, j'étais comme ça, en 32 bits :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
interface
uses
  LCLIntf, LCLType, // pour DrawMultiGradient
  Math,
//  Dialogs, // showmessage
//  ExtCtrls, // TImage
  Classes, SysUtils, Graphics;

alors qu'il fallait être comme ça, dans la nouvelle 64 bits :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
interface
uses
  Math,
//  Dialogs, // showmessage
//  ExtCtrls, // TImage
  Classes, SysUtils, Graphics,
  LCLIntf, LCLType; // pour DrawMultiGradient

pour que tout aille bien.

Notez-vous-le dans un coin…

[Jipété]

Bonjour,

Et je ne parle pas du RadioBox dont la Caption est barrée, on en ai déjà causé, va falloir que je déclare un bug (je ne sais pas comment, si qqun a une idée, merci).

Ce n'est pas un bug FP/Laz, j'en ai parlé ce matin dans le fil qui va bien, c'est un pb Linux (vraiment lassant).

Il m'aura fallu un temps dément pour trouver la solution, toute simple pourtant : dans un module complémentaire où j'ai plein de routines en rapport avec le traitement des couleurs, j'étais comme ça, en 32 bits :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
interface
uses
  LCLIntf, LCLType, // pour DrawMultiGradient
  Math,
//  Dialogs, // showmessage
//  ExtCtrls, // TImage
  Classes, SysUtils, Graphics;

alors qu'il fallait être comme ça, dans la nouvelle 64 bits :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
interface
uses
  Math,
//  Dialogs, // showmessage
//  ExtCtrls, // TImage
  Classes, SysUtils, Graphics,
  LCLIntf, LCLType; // pour DrawMultiGradient

pour que tout aille bien.

Notez-vous-le dans un coin…

J'ai enlevé le car dans le même projet je fais dessiner un cercle chromatique complet (du rouge au rouge en faisant tout le tour, rouge orange jaune vert cyan bleu mauve violet, et de l'extérieur noir vers l'intérieur blanc en passant par couleur au milieu) plus l'affichage dans des panneaux des valeurs rgb et hsl décodées au passage de la souris sur le cercle.
J'ai beaucoup souffert en son temps, mais depuis des années c'est tout bon en 32 bits.

Je ne change rien (à part cette histoire d'emplacement de LCLType et LCLIntf dans les uses décrite ci-dessus) et ça se vautre lamentablement en 64 bits, ça en devient à pleurer à hurler à tout casser à se recycler vendeur de frites, franchement y en a marre !
Je n'ai pas changé une virgule, rien, et les conversions rgb vers hsl foirent. Pourquoi ? Je travaille avec des byte (pour R, G et B) et des double (pour H, S et L), ça peut jouer différemment en 64 versus 32 ?
J'ai regardé le début de graphics, de LCLType et de LCLIntf sans rien trouver.
Je suis au désespoir, c'est totalement déprimant…


Sur cette magnifique image (un peu réduite) on voit le pointeur (mon curseur en forme de croix de viseur n'a pas été attrapé par l'outil de capture Linux, désolé) et dans les patches en haut à droite les valeurs rgb de la couleur survolée et de la couleur inversée (dans le sens où je me contente de transformer rgb en hsl puis de transformer les trois valeurs obtenues en suivant la règle if valeur < 0,5 then valeur := valeur + 0,5 else valeur := valeur - 0,5; (les valeurs varient de 0 à 1) et retransformation de ces valeurs vers rgb) et quand je fais la même chose en 64 bits il y a du flicker dans les panneaux et surtout, les valeurs opposées ne bougent pas.
Et je rappelle que c'est strictement le même code !
Alors comment dépanner/débogueur un code qui fonctionne bien, sauf qu'il fonctionne mal ?

Merci pour les pistes,

[BeanzMaster]

Salut JP, ton probleme viens surement de l'utilisation du type double, qui est different en 32bits et 64bits à la place remplace par des Single pour voir. Regardes egalement dans tes options de compilation si il n'y a pas un truc qui traine et qui pourrait engranger cette erreur


A+ Jérôme

[Jipété]

, Jérôme,

Salut JP, ton probleme vient surement de l'utilisation du type double, qui est différent en 32bits et 64bits à la place remplace par des Single pour voir.

différent en 32bits et 64bits : comment tu sais ça, toi ? Où se trouvent les infos ? Parce que figure-toi que j'y ai bien pensé aussi, je me suis paluché l'aide en ligne (donc à jour j'ose espérer), que j'ai comparée avec mes vieilles notes 32 bits et je ne vois aucune différence entre les deux…

Ceci étant dit, pour essayer d'avancer, j'ai créé un prog ultra simple qui reproduit à peu près ce que j'ai montré sur l'image et là, toujours en ne changeant strictement rien d'une archi à l'autre, ça fonctionne sur les deux.
Je serais donc tenté de dire que ce n'est pas ça le problème et c'est pour ça que je m'arrache les cheveux car je ne vois pas où ça peut coincer ni quoi est concerné.

J'en suis réduit à repartir du gros programme, le dupliquer et enlever le max de choses jusqu'à ce que le 'blème disparaisse. À suivre…

regarde également dans tes options de compilation si il n'y a pas un truc qui traîne et qui pourrait engranger cette erreur

Rien trouvé, et si c'est pointu, je risque de ne pas savoir le trouver -- d'un autre côté, si c'est pointu, je ne l'aurais jamais mis en place, alors tout va bien de ce côté-là.

Bon, j'y retourne une poignée d'heures et après c'est week-end, je ne pourrai rien faire.

[BeanzMaster]

Salut

, Jérôme,

différent en 32bits et 64bits : comment tu sais ça, toi ? Où se trouvent les infos ? Parce que figure-toi que j'y ai bien pensé aussi, je me suis paluché l'aide en ligne (donc à jour j'ose espérer), que j'ai comparée avec mes vieilles notes 32 bits et je ne vois aucune différence entre les deux…

Oups, non c'est moi j'ai confondu avec le type Extend

Salut

C'est le problème de typage : avant un entier était sur 32 bits, maintenant sur 64.

Je n'ai jamais eu ce probleme avec des entier

https://www.freepascal.org/docs-html/ref/refsu4.html
https://wiki.freepascal.org/Data_type
https://wiki.freepascal.org/Variables_and_Data_Types


L'ordre des classes dans le uses est important, comme tu l'a deja signalé. Et notamment pour LCLIntf, LCLType. Mais ce n'est pas nouveau ça. Donc attention aussi avec tes unités perso

JP, un truc qui m'ai déja arrivé. Lorsque je lance le prog avec F9 j'ai du des fois supprimé les fichiers de sortie créés de la précédente compilation.
Autre truc que j'ai eu lorsque je manipulait suivant le prog en le lançant depuis Lazarus celui-ci ne fonctionnait pas. La cause c'était le debugger DBG. Je faisait juste un construire et lançais le prog en dehors de Lazarus et la ca fonctionnait.

Pour les options de compilation force le mode asm en Intel, par précaution et attention à l'options d'optimisation ne le force pas au maximum. Ensuite assure toi bien que tes progs sont en mode ObjFPC. J'ai eu des soucis en mode Delphi sous Linux.

Si tu as encore un soucis dans le genre. Ca serait bien de nous faire un zip avec tout le code.
A mon avis il ne doit pas y avoir grand chose à modifier pour rendre compatible tes progs à la fois en 32bit et en 64bit

[Jipété]

Bonjour,

et merci à vous pour vos retours et les liens.

C'est le problème de typage : avant un entier était sur 32 bits, maintenant sur 64.

Typique à Delphi, non ?


@Jérôme :
ce lien est le plus intéressant des trois, àmha : https://www.freepascal.org/docs-html/ref/refsu4.html
et on y trouve

Remark In newer Delphi versions, the longint type is platform and CPU dependent. This is not so in FPC, where longint is 32-bit on all platforms.

Tout est dit et ça ne m'explique pas comment la pagaille a pu se produire chez moi.

Comment j'ai fait : dans la nouvelle machine j'ai reproduit l'arborescence des dossiers contenant les .pas communs à plusieurs programmes, puis j'ai transféré certains dossiers (j'y vais petit à petit, avec cette migration : entre le passage de 32 à 64 bits, d'un proc Intel à un AMD, la disparition dans l'OS de sysVinit au profit de [cette cochonnerie de] systemd et autres bricoles, ça va bientôt faire 14 mois que la machine neuve n'est toujours pas en prod…)
Et donc un gros dossier dont le binaire fonctionne très bien en 32 bits s'est mis à dérailler sur certains points, ceux liés aux conversions RGB --> HSL et/ou (me souviens plus très bien) HSL --> RGB, ce qui m'a psychologiquement complètement déstabilisé.
Et en même temps que je vous raconte je réalise que je n'ai toujours pas compris qu'est-ce qui se passe au juste.
Parce que d'autres programmes ont pu être migrés sans soucis.

Pour les options de compilation force le mode asm en Intel, par précaution et attention à l'option d'optimisation ne le force pas au maximum.

Je ne sais pas où se cache cette option du mode asm en Intel (ou alors c'est dans Options / Options du compilateur / Analyse / Style d'assembleur ? Dans ce genre de choses je laisse "par défaut" parce que comm' d'hab' l'aide est lamentable :

Assembler style
Sets the value of -R<x> option:

-Rdefault: use default assembler
-Ratt: use AT&T style assembler
-Rintel: use Intel style assembler

(Si l'aide se résume à nous redire ce que nous montrent déjà les textes du radiogroup, ce n'est franchement pas la peine), et pour les options d'optimisation je n'ai jamais dépassé le niveau 2 et en français on perd un niveau : en haut l'aide qu'on trouve sur le web en cliquant sur le bouton "Aide" situé en bas à gauche de la page qui nous affiche ce qu'il y a en bas de l'image…

Ensuite assure-toi bien que tes progs sont en mode ObjFPC. J'ai eu des soucis en mode Delphi sous Linux.

Étant entendu que c'est parfois la misère de passer en ObjFPC, quand il faut modifier des trucs et des machins pas toujours intuitifs, pb rencontré quand on récupère un prog écrit pour Delphi au départ.

Si tu as encore un souci dans le genre, ça serait bien de nous faire un zip avec tout le code.

C'est ce que j'avais commencé à préparer, et c'est là que je me suis rendu compte de la blagounette qui a fait disparaître le problème avec le projet minimaliste prévu pour le zip.
Va falloir que je remette le fourbi sur l'établi, j'ai pas complètement fini les coups de lime mais là c'est week-end, donc rdv lundi !

[Jipété]

J'ai trouvé où et quoi coinçait, et ça restera un mystère insondable, pour moi : dans une unité complémentaire à mon projet, il y a plein de fonctions et procédures et plein de mes programmes y font référence, comme tout le monde je suppose, et là-dedans j'ai plein de choses trifouillant les pixels, les couleurs, etc.
Et ça fait un paquet d'années que c'est stable et efficace.

Il m'est arrivé parfois d'englober des petits bouts de proc's pour en faire une plus grande, genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
procedure ijpColorToHSL(const aColor: TColor; out H,S,L: double); inline;
var // graphutil, c'est là que j'ai trouvé ColorToHLS (notez l'inversion L <> S), voir dessous 
  R,G,B: Byte;
begin
  R :=  aColor and $FF;
  G := (aColor shr  8) and $FF;
  B := (aColor shr 16) and $FF;
  ijpRGBtoHSL(R,G,B, H,S,L); // vient de easyrgb.com, attend des bytes et va en sortir des doubles
end;

inversion S <> L car si graphutil travaille avec des bytes en sortie, comme je m'appuie beaucoup sur des codes trouvés sur easyrgb.com qui travaillent en double, ben j'ai fait mes propres procs, préfixées donc par ijp, avec i comme "inline" (qui ne fonctionne pas toujours, avec des messages pas clairs), et "jp" comme ma pomme , et l'inversion S <> L pour être sûr de ne pas m'emmêler les pinceaux

En gros, je reprends le principe de graphutil :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
procedure ColorToHLS(const AColor: TColor; out H, L, S: Byte);
var
  R, G, B: Byte;
  RGB: TColorRef;
begin
  RGB := ColorToRGB(AColor);
  ExtractRGB(RGB, R,G,B); // cette proc extrait les composantes R, G et B d'un TColor
  RGBtoHLS(R,G,B, H,L,S); // et celle-la nous donne les valeurs HLS en bytes
end;

Tout ça n'est que du Meccano avec des lignes de code au lieu de plaques de ferraille, mais dans l'idée c'est la même chose.

Et je ne vois absolument pas pourquoi le fait d'avoir empaqueté des petites procs dans une grosse fait que si ça continue à fonctionner dans la machine 32 bits, ça foire lamentablement dans la 64, m'obligeant à éclater la big proc en ses petits composants pour que ça daigne tomber en marche.

[anapurna]

Salut

C'est le problème de typage : avant un entier était sur 32 bits, maintenant sur 64.

Pour éviter les problèmes de type j'ai tendance à créer les miens ; de cette manière, je les fais évoluer pour rester compatible dans le temps.
Les exemples les plus criants étant les integer et les string.

PS : Certaines données sont des valeurs système et dépendent donc de l'OS.
Voici un lien super intéressant Ici.