Migration 32 --> 64 bits, toujours la misère

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 :
Pièce jointe 601671

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

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:

---

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:

---

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…

Bonjour,

Citation:

---

Envoyé par Jipété

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

Citation:

---

Envoyé par Jipété

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:

---

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:

---

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 :resolu: 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…

Pièce jointe 602408
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,

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

:coucou:, Jérôme,

Citation:

---

Envoyé par BeanzMaster

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. :weird:
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…

Citation:

---

Envoyé par BeanzMaster

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à. :mrgreen:

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

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:

---

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 :zoubi:, 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:

---

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.

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.

Salut

Citation:

---

Envoyé par Jipété

:coucou:, 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

Citation:

---

Envoyé par anapurna

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

Bonjour,

et merci à vous pour vos retours et les liens.

Citation:

---

Envoyé par anapurna

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

Citation:

---

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.

Citation:

---

Envoyé par BeanzMaster

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 :

Citation:

---

Envoyé par aide minable de Lazarus 1.4

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

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

---

Pièce jointe 602520
(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…
Pièce jointe 602521

Citation:

---

Envoyé par BeanzMaster

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.

Citation:

---

Envoyé par BeanzMaster

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

Bonjour à tous,

Citation:

---

Envoyé par Jipété

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 !

---

et donc je fais le point :
en 32 bits, cette suite d'appels fonctionne très bien et est très fluide ("opp" pour couleur opposée) :

Code:

---

1 2 3 4

begin CurColor := img.Canvas.Pixels[X,Y]; ijpColorToHSL(CurColor, hopp,sopp,lopp); // suite du code pour l'inversion des valeurs h s l

---

avec

Code:

---

1 2 3 4 5 6 7 8 9

procedure ijpColorToHSL(const aColor: TColor; out H,Sh,L: double); inline; var 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,Sh,L); // proc compliquée venant de chez easyRGB.com end;

---

En 64 bits la suite d'appels précédente cafouille (erreurs de couleurs, cahots au déplacement de la souris, etc.) et il me faut faire ainsi :

Code:

---

1 2 3 4 5

begin CurColor := img.Canvas.Pixels[X,Y]; RedGreenBlue(CurColor, rcur,gcur,bcur); // ajout pour 64 bits ijpRGBToHSL(rcur,gcur,bcur, hopp,sopp,lopp); // OK //ijpColorToHSL(CurColor, hopp,sopp,lopp); // KC !

---

Le gag c'est qu'ici RedGreenBlue vient de graphics.pp et contient simplement

Code:

---

1 2 3 4 5 6

procedure RedGreenBlue(rgb: TColorRef; out Red, Green, Blue: Byte); begin Red := rgb and $000000ff; Green := (rgb shr 8) and $000000ff; Blue := (rgb shr 16) and $000000ff; end;

---

(c'est la même chose qu'on trouve dans graphutil.pp :

Code:

---

1 2 3 4 5 6

procedure ExtractRGB(RGB: TColorRef; var R, G, B: Byte); inline; begin R := RGB and $FF; G := (RGB shr 8) and $FF; B := (RGB shr 16) and $FF; end;

---

), ce qui correspond aux premières lignes de ma ijpColorToHSL.

Donc en gros je suis obligé de dépaqueter pour 64 bits ce que j'avais pu empaqueter pour 32 bits.
:koi:

Note : on trouve ça dans graphutil.pp, pas utilisable directement car sort sur des byte au lieu de double :

Code:

---

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); RGBtoHLS(R, G, B, H, L, S); end;

---

mais c'est de ça dont je me suis inspiré.

Pourquoi ça cafouille en 64 bits alors que les uses sont identiques restera un mystère total à dépatouiller pour les générations futures, :P

Salut la difference c'est le TColor dans graphUtil, c'est TColorRef. Les fonctions de easyRGB.com proviennent de Delphi (et il y a longtemp) .
L'ordre des composant n'est pas la même.
Avant FPC 3.2.0 sous Linux le TColor sous linux l'ordre des couleurs etaient RGBA et BGRA sous Windows. Maintenant que l'on soit sous Linux ou Windows TColor est au format BGR

Citation:

---

Since FPC 3.2.0, Free Pascal defines TColor and TColorRec as well as the 140 standard Color names in the Delphi compatible System.UItypes unit, to allow non visual code to use the same type as visual code. Lazarus hasn't caught on yet, because the current Lazarus versions still support 3.0.x.

In the LCL TColor is the standard color type. It is compatible with Delphi's TColor. TColor can represent either an RGB (3x8bit) value, or a system color like clDefault. The LCL can also work with the fpImage system which uses the TFPColor type (which is RGBA (4x16bit), not RGB (3x8bit) like TColor).

---

https://wiki.freepascal.org/Colors

dans FPC, TColor est en 24bits. Et par exemple clRed = TColor($0000FF). C'est pour cela que

Code:

---

1 2 3 4

R := aColor and $FF; //= $FF0000 au lieu de $0000FF G := (aColor shr 8) and $FF; B := (aColor shr 16) and $FF;

---

ne peut pas fonctionner correctement tes bitMasks ne sont pas correcte

TColorRef lui de type cardinal (32 bits) et donc au format ABGR

J'avoue quand même que sur ce point la doc n'est pas très explicite.

Depuis ta version 1.4 il est certain que certaine chose comme ici la gestion des couleurs du TColor a changé.

A+

Bonjour Jérôme,

et merci pour ces précisions qui me (nous !) seront d'une valeur inestimable :
(légèrement édité pour plus de clarté)

Citation:

---

Envoyé par BeanzMaster

L'ordre des composant n'est pas la même.
Avant FPC 3.2.0 pour le TColor l'ordre des couleurs était RGB(A) sous Linux et BGR(A) sous Windows. Maintenant que l'on soit sous Linux ou Windows TColor est au format BGR

---

Mais il y a un truc bizarre dans la traduc' : j'ai suivi ton lien, et on y trouve

Citation:

---

Envoyé par english

Overview

Since FPC 3.2.0, Free Pascal defines TColor and TColorRec as well as the 140 standard Color names in the Delphi compatible System.UItypes unit, to allow non visual code to use the same type as visual code. Lazarus hasn't caught on yet, because the current Lazarus versions still support 3.0.x.

In the LCL TColor is the standard color type. It is compatible with Delphi's TColor. TColor can represent either an RGB (3x8bit) value, or a system color like clDefault. The LCL can also work with the fpImage system which uses the TFPColor type (which is RGBA (4x16bit), not RGB (3x8bit) like TColor).

---

Citation:

---

Envoyé par français

Vue d'ensemble

Dans la LCL, TColor est le type couleur standard. Il est compatible avec le TColor de Delphi. TColor peut représenter soit une valeur RGB (3x8bits), soit une couleur système comme crDefault. La LCL peut aussi travailler avec le système fpImage qui emploie le type TFPColor qui est du RGBA (4x16bits), et non du RGB (3x8bits comme TColor).

---

Donc la traduc' française fait sauter le 1^er § où l'on trouve notamment la phrase :

Citation:

---

Lazarus hasn't caught on yet, because the current Lazarus versions still support 3.0.x

---

et une traduc' ggl donne

Citation:

---

Lazarus n'a pas encore compris, car les versions actuelles de Lazarus prennent toujours en charge 3.0.x

---

On n'est pas sorti de l'auberge, àmha !

Bonne journée,