Discussion :

[Francois_C]

Je pense qu'il y a de bonnes choses, mais que je vais attendre avant de l'utiliser. La version actuelle me suffit.

Je suis tenté de l'essayer (ajouter des paquets sans les reconstruire, ça me plairait bien), mais je devrais peut-être attendre aussi :

1. J'ai un assez grand nombre de petits programmes qui lancent des CommandLine et dont dont la compilation sous 1.6.4 renvoie déjà un avertissement : Warning: Symbol "CommandLine" is deprecated. Est-ce que CommandLine passe encore ?
2. J'en ai aussi beaucoup qui traitent des chaînes et qui m'ont déjà coûté beaucoup de peine pour fonctionner en UTF-8, et ce que je lis dans l’article me fait froid dans le dos : « Ainsi est-il conseillé de remplacer les fonctions préfixées par UTF8 par leur équivalent Delphi préfixé par Ansi ». On ne va quand même pas nommer l'utf8 ansi ! Et Utf8toSys ne va pas devenir AnsitoSys, quand même ? Et Utf8toAnsi, ça devient quoi ??? À moins que ça concerne justement des vieux programmes Delphi écrits pour Windows ? Mais ils ne fonctionnaient déjà plus sans modifications avec les versions précédentes…

[gvasseur58]

Bonjour,

1. J'ai un assez grand nombre de petits programmes qui lancent des CommandLine et dont dont la compilation sous 1.6.4 renvoie déjà un avertissement : Warning: Symbol "CommandLine" is deprecated. Est-ce que CommandLine passe encore ?

Oui . Mais quand un élément est marqué comme deprecated, il vaut mieux faire la (petite) correction nécessaire, sinon on risque de se lier les mains pour rien. Par exemple, CommandLine est deprecated depuis au moins 2011... Ici, il faudrait utiliser Parameters à la place (attention la propriété est de type TStrings).

2. J'en ai aussi beaucoup qui traitent des chaînes et qui m'ont déjà coûté beaucoup de peine pour fonctionner en UTF-8, et ce que je lis dans l’article me fait froid dans le dos : « Ainsi est-il conseillé de remplacer les fonctions préfixées par UTF8 par leur équivalent Delphi préfixé par Ansi ». On ne va quand même pas nommer l'utf8 ansi !

Le sujet est trop vaste et difficile pour être traité ici. Je ne suis même pas sûr qu'il puisse être traité, d'ailleurs (voir, par exemple, cette discussion très récente avec un des meilleurs programmeurs Lazarus). A mon avis, le plus simple est de faire comme ceci :

• s'appuyer essentiellement sur SysUtils et LazUTF8 (donc, en particulier, oublier les routines concernant les chaînes qui avaient été rangées () dans FileUtil) ;
• utiliser les fonctions préfixées par UTF8 tant que la situation ne sera pas totalement claire (à mon avis, ce n'est pas demain ) ;
• ne pas toujours tenir compte des conseils donnés par le wiki Lazarus qui, comme tous les wikis et les FAQ, empile des informations contradictoires, vieillies ou mal étayées ;
• se dire que l'ensemble est de toute façon temporaire : l'objectif de Lazarus est de ressembler à Delphi qui utilise l'UTF16 (et non l'UTF8).

Remarques :
Lazarus (et Free Pascal) est responsable du choix de vouloir ressembler coûte que coûte à Delphi pour la raison essentielle de réutilisation du code. Je pense qu'un peu de liberté ferait du bien : par exemple, l'UTF16 choisi par Delphi n'est que le calque d'un choix très douteux de Microsoft pour Windows qui fonctionne justement en UTF16. Lorsqu'on veut travailler avec les autres OS ou pour le Web, l'UTF8 devient largement dominant (pour le Web, c'est à plus de 90%), d'où le choix, annoncé comme provisoire, de Free Pascal et Lazarus. Autrement dit, Lazarus est pris entre le désir de copier Delphi et la volonté d'offrir un produit autrement plus flexible...

Et Utf8toSys ne va pas devenir AnsitoSys, quand même ? Et Utf8toAnsi, ça devient quoi ???

Les deux fonctions sont devenues totalement inutiles : sauf dans le cas où la RTL est compilée explicitement pour ne pas utiliser l'UTF8 (pour de vraiment très anciens programmes), elles ne font que renvoyer la chaîne fournie en paramètre. Autant dire que les laisser ne fait que ralentir (un tout petit peu, certes) le programme. En fait, il s'agit de vestiges du temps où la RTL n'était pas adaptée à l'UTF8, ce qui n'est plus le cas.

Je suis tenté de l'essayer (ajouter des paquets sans les reconstruire, ça me plairait bien), mais je devrais peut-être attendre aussi

Si c'est sur Windows, il est toujours possible d'installer des Lazarus secondaires. Personnellement, je garde un Lazarus ancien sur (au moins) une machine virtuelle, mais j'installe systématiquement les nouvelles versions qui évitent de se prendre la tête avec des bogues parfois très pernicieux. Quant au code que j'écris, j'essaye de ne pas utiliser des vieilleries Delphi .

[Francois_C]

Bonjour,

Oui . Mais quand un élément est marqué comme deprecated, il vaut mieux faire la (petite) correction nécessaire, sinon on risque de se lier les mains pour rien. Par exemple, CommandLine est deprecated depuis au moins 2011... Ici, il faudrait utiliser Parameters à la place (attention la propriété est de type TStrings).

Merci pour ta réponse.

Tu as raison, bien sûr. Mais j'ai beaucoup de petits programmes à modifier, et le type TStrings de Parameters m'a déjà joué des tours quand je voulais aller trop vite.

Je n'ai pas résisté à installer 1.8 sous Ubuntu Studio, et :
1. Apparemment CommandLine passe bien en effet.
2. il y a peut-être quelque part un Dieu du Pascal qui a jugé que j'avais déjà assez galéré entre l'UTF-8 et l'ANSI pour ne pas mériter de nouvelles tribulations, parce que mes traitements de chaînes ont l'air de fonctionner sans changements ; mais c'est sous Linux. En principe, je déclarais comme String, considérant que par défaut ce serait compris comme Utf8String. Sous Windows, les pires galères viennent de l'encodage des noms de chemins de fichiers. Certains programmeurs experts n'arrivent pas à s'en dépatouiller pour peu que leur programme soit un peu vieux et long. Comme les conversions de chemins de fichiers et de paramètres effectuées par Lazarus ne marchent pas, j'ai pris l'habitude d'ajouter une petite fonction :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{$ifdef windows}
function conv(Input : String) : String;
var
 tmp : String='';
begin
  result:='';
  tmp := input;
  tmp := StringReplace (tmp, 'æ', #230, [rfReplaceAll]);
  tmp := StringReplace (tmp, 'œ', #156, [rfReplaceAll]);
  tmp := StringReplace (tmp, 'ø', #248, [rfReplaceAll]);
  tmp := StringReplace (tmp, 'å', #229, [rfReplaceAll]);
  tmp := StringReplace (tmp, 'à', #224, [rfReplaceAll]);
  tmp := StringReplace (tmp, 'á', #225, [rfReplaceAll]);
  tmp := StringReplace (tmp, 'â', #226, [rfReplaceAll]);
  tmp := StringReplace (tmp, 'ä', #228, [rfReplaceAll]);
(etc. etc ...)
  tmp := StringReplace (tmp, 'Ÿ', #159, [rfReplaceAll]);
  result := tmp;
end;
{$endif}

C'est un peu bourrin mais ça marche. Quand on doit envoyer une ligne de commande à un logiciel externe, il faut aussi tenir compte de la manière dont ce logiciel traite les caractères des lignes de commande. L'utilité de Parameters pourrait être de faire penser à l'éventualité d'avoir à convertir les paramètres d'une façon différente des chemins de fichiers. J''ai un cas d'un bidule qui envoie des lignes de commande à GhostScipt, qui fonctionne très bien sous Windows, mais n'a pas l'air de vouloir interpréter convenablement les commandes entre #34 ou #39 sous Linux.

[mm_71]

Oui . Mais quand un élément est marqué comme deprecated, il vaut mieux faire la (petite) correction nécessaire, sinon on risque de se lier les mains pour rien.

En parlant de "deprecated" les composants mentionnés comme tels disparaîtront-ils un jour ? Toute ma gestion de BDD personnelle repose sur TDBF qui est mentionné comme tel depuis une éternité et je n'ai guère envie de tout réécrire. Je pourrai toujours conserver une ancienne version de lazarus mais bof...

[der§en]

Beau boulot sur Windows mas côté MacOSX, toujours pas exploitable du fait que le debuggeur ne fonctionne pas

[Jipété]

Beau boulot sur Windows mas côté MacOSX, toujours pas exploitable du fait que le debuggeur ne fonctionne pas

[...] Sous Mac, j'ai dû recompiler gdb pour pouvoir l'intégrer à la plateforme.[...]

[der§en]

Si j’ai bien compris, il faut avoir un compte « développeur » chez Apple pour pouvoir signer le débugger, je vais pas prendre un compte chez Apple rien que pour cela…

[piGrimm]

beh moi j'aime bien freepascal parce que :
1) fraichement retraité d'une firm IT USA, je m'ennuie
2) j'écris des logiciels dont je suis sûr, si je les publie, qu'ils ne donneront aucune prise au reverse engineering, étant donné la foultitude d'outils décompilateurs pour la C familly, et l'absence pour le pascal
3) je me gauss (punaise j'ai le dos en chapeau de gendarme) des amoureux de C qui viennent ici nous baragouiner du ring 0 impossible, alors que je l'ai déjà fait en Pascal (le passage de ring vient de l'éditeur de liens, du linker pour drivers, pas du compilateur LOL faut tout reprendre depuis la maternelle pour certains)... et nous faire la promotion de leurs languages C et dérivés, prétendument spécialisés dans la prog system, alors qu'ils n'ont même pas une intrinsèque de rotation de bits MDR dans la tête de vos macros obligatoires pour si peu
4) souvent il est bon de ne pas suivre les chemins flêhés, de ne pas se vautrer dans les failles de sécurités de compilateurs que tous les bananamen promeuvent, parce qu'ils jouent le jeu des Majors bourrées de fric et surtout de merde qui ne trouve pas forcément clients
5) enfin, comme dit le proverbe ricain "Never give them what they want, give them what they need" (ne leur donnez jamais ce qu'ils veulent mais ce dont ils ont besoin) . Ce proverbe est en fait, l'une des 3 bases de la Réussite. Voilà pourquoi je me fous de la notoriété des compilateurs d'autres langages
=-=-->> plus ils ont de cette notoriété plus il y a d'outils pour le reverse engineering, et moins je m'y interresse (c'est comme les antivirus renommés LOL ils sont les Cibles favorites, méditez là dessus)
PS = je suis déjà a la version 1.8.1 depuis presque 15 jours

[Jipété]

Salut,

PS = je suis déjà a la version 1.8.1 depuis presque 15 jours

et tu as trouvé cette merveille où ?

(à moins que tu ne confondes avec la 1.8.0-1 ? Il semblerait que c'est ça qu'on peut télécharger, et rien d'autre...)

[piGrimm]

@Jipété
pour la version 1.8.1 vous utilisez fpcupdeluxe et (simple) dans les options vous demandez d'installer et de compiler sur vos machines

- la version stable compilateur
- la version "fixes" lazarus

épicétou

une fois l'opération éxécutée, au lancement de lazarus et par la suite dans la boite "à propos" vous aurez la confirmation de la version 1.8.1 qui correspond à la version stable officielle avec des corrections mineures nommées "fixes" en anglouas

[microb]

Bonjour
J'ai installé sans problème: FPC 3.1.1 et Lazarus 1.9
a partir de fpcupdeluxe

[piGrimm]

Bonjour
J'ai installé sans problème: FPC 3.1.1 et Lazarus 1.9
a partir de fpcupdeluxe

ok mais il s'agit de la version labo sur laquelle les équipes travaillent et , par conséquent, qui n'est pas exempte de beugs.
Il vaut mieux rester sage et bosser avec la version stable, à moins que de n'être membre d'une des équipes de devs (celle de FPC, ou celle de Laz)

Sinon, ne pas publier d'applications crées par la version labo! sous peine d'avoir bien des retours de flammes de clients exaspérés par les EXTERNAL SIGSEGV FAULTS!
C'est du vécu

[microb]

Je suis revenu a la version 1.8
L'avantage avec fpcdeluxe,c'est que l'on maîtrise l'installation et que l'on peut avoir plusieurs versions en même temps.

[TJ1985]

Bonjour,

J'hésite à réinstaller Lazarus sur mon Mac. J'ai fini par me décourager lorsque le debugger n'a plus été supporté, vers XCode 5 je crois.
Quelqu'un peut-il me dire à quoi nous en sommes aujourd'hui ? La doc est antédiluvienne, sans doute périmée puisqu'elle parle de la version 1.0...
Je sais qu'un programme bien réfléchi n'a pas besoin d'être debuggé, mais justement ! ;-)

[BeanzMaster]

Bonjour,

J'hésite à réinstaller Lazarus sur mon Mac. J'ai fini par me décourager lorsque le debugger n'a plus été supporté, vers XCode 5 je crois.
Quelqu'un peut-il me dire à quoi nous en sommes aujourd'hui ? La doc est antédiluvienne, sans doute périmée puisqu'elle parle de la version 1.0...
Je sais qu'un programme bien réfléchi n'a pas besoin d'être debuggé, mais justement ! ;-)

Salut,

Si j’ai bien compris, il faut avoir un compte « développeur » chez Apple pour pouvoir signer le débugger, je vais pas prendre un compte chez Apple rien que pour cela…

[TJ1985]

Ouil mais non. J'ai installé et réinstallé gdb, l'ai signé et re-signé, ça ne marche pas, en tout cas chez moi. Je pose donc la question autrement : Est-ce que quelqu'un peut debugger avec Lazarus sur MacOS ? Moi, je finissais toujours par une erreur me demandant si le debugger est signé (il l'était, vérifié, re-verifié).

Si oui je ré-essayerai. Sinon j'utiliserai une VM Ubuntu, par exemple. Mais c'est quand même ennuyeux.

[BeanzMaster]

Regarde la page d’installation du wiki (maj 09/2017)
Il te faut également d'après ce que je peux comprendre installer également xcode manuellement. Le forum anglais pourra te donner de plus amples informations.

Dans tous les cas, c'est possible. mais il semble falloir être beaucoup plus patient et méticuleux sous MacOS

[TJ1985]

D'abord merci pour ton retour.

Regarde la page d’installation du wiki (maj 09/2017)

C'est la source que j'ai utilisée la dernière fois, en vain.

Il te faut également d'après ce que je peux comprendre installer également xcode manuellement. Le forum anglais pourra te donner de plus amples informations.

En fait il s'agit des outils "ligne de commande" de XCode, fait également. C'est d'ailleurs une étape quasi forcée si on veut faire quelque chose avec XCode.

Dans tous les cas, c'est possible. mais il semble falloir être beaucoup plus patient et méticuleux sous MacOS

Je finis par douter de cette possibilité, car les sources sont trop disparates et sont toutes sur le mode yaka. Si tu regardes le lien que tu m'as donné, vers le bas, un tableau montre bien l'état actuel des compatibilités : Plus rien n'est fait depuis Yosemite, ça date vraiment...

C'est pourquoi j'essaie d'avoir un vrai retour d'expérience, de quelqu'un qui utilise couramment Lazarus sur la dernière version de OSX, ou bien une version récente, au moins.

Pour le moment, à l'ouest, rien de nouveau. Je n'ai pas la compétence nécessaire pour remplacer gdb par lldb, qui est le debugger courant sous OSX. Sinon je m'y collerais volontiers. Peut-être que quelqu'un, quelque part...