Discussion :

[Jipété]

Pour en être certain il faut virer ou plutôt renommer ton répertoire Lnet d'origine et renommer Lnet le nouveau à essayer.

Non, mais si tu as utilisé le package .'deb' c'est dans /usr/share/lazarus/1.6.2/components ou vont les paquets officiels après l'install. Manifestement tu as créé un répertoire spécial pour les composants additionnels, alors si tu as qq. part le répertoire précité tu devrais quand même essayer d'y recopier lnet pour voir.
Voir aussi dans /etc/fpc.cfg si ton répertoire perso est bien référencé partout ou il faut.

J'ai renommé, t'inquiète, j'ai 37 ans d'informatique derrière moi...

Je le répète encore, les composants GifAnim et BGRAControls/BGRABitmap se sont bien installés de la même manière (ouvrir le .lpk qui va bien, compiler, installer) à partir du même dossier principal qui n'est ni plus ni moins qu'un partage réseau "monté" par VirtualBox et donc "vu" par Debian comme un disque comme un autre.

Et j'ai édité mon précédent post, peut-être en même temps que tu postais, alors jettes-y un œil, tout en bas.

En fait je pense que ce message d'erreur ne reflète pas la réalité, il doit se passer autre chose et ce message d'erreur stupide nous brouille la compréhension, je ne vois que ça.

[Jipété]

En fait je pense que ce message d'erreur ne reflète pas la réalité, il doit se passer autre chose et ce message d'erreur stupide nous brouille la compréhension, je ne vois que ça.

Ce matin j'ai pris le taureau par les cornes et j'ai créé un nouveau dossier d'install avec dedans un dossier src avec les .pp et .inc, j'ai modifié les 2 .lpk en conséquence, adapté les chemins toussa toussa, me suis bien inspiré de la construction du GifAnim.lpk, bref tout était parfait pour une installation réussie qui a... échoué !
Toujours de la même manière...

Un lancement en mode "log dans console" ne me disait rien de plus jusqu'à ce que je regarde tout en haut du log et là !, stupéfaction, regardez le chemin utilisé dans l'ihm après l'ouverture du .lpk (en haut, c'est correct) et dans la console (dessous, en surbrillance) :


On croit rêver, non ?
D'où est-ce que la console sort ça ? Car je suis sûr maintenant que la blague est là : je pouvais toujours m'escrimer à modifier les .lpk, s'ils ne sont pas pris en compte,

Le plus dément, c'est que comme je les modifiais avec le bloc-notes, au retour dans l'ihm Lazarus la fenêtre "Le fichier a changé voulez-vous bla bla" s'affichait, que je m'empressais d'acquiescer, sans penser un seul instant que fpc me faisait un bébé dans le dos avec son chemin foireux !
Ah lala, on vit des trucs, des fois, on s'demande...

Allez, j'y retourne.

[Jipété]

Bonsoir,

J'avais d'autres choses à faire cet aprème, donc je reviens un peu tard, et avec des mauvaises nouvelles car, malgré ce que j'ai découvert en fin de matinée, ça ne fonctionne toujours pas...

Comme je commence à en avoir franchement marre, j'ai pris le dossier lnet, je l'ai dupliqué en changeant le nom de la copie, à l'intérieur je n'ai gardé que le dossier prévu par l'auteur pour une install dans Lazarus et dans ce dossier, j'ai viré le sous-dossier src en prenant soin, avant, de recopier les fichiers qu'il contenait au même niveau que les .lpk prévus pour l'install.

En gros, ça ressemble à l'install basique d'un compo ridicule genre GifAnim, il y a juste un peu plus de fichiers, et croyez-le ou pas mais ça foire toujours

Et je sais pourquoi, enfin, oui et non -- regardez l'image : en haut le bas de la fenêtre du sous-programme d'installation d'un paquet, j'ai souligné en rouge le nom du nouveau dossier ; mais dessous, si on admet que la première ligne nous informe que la dernière compilation a échoué, je voudrais bien savoir pourquoi et comment le "working directory" est positionné sur "lnet_new", juste dessous, qui est censé ne pas être concerné !
Et pareil pour les options de recherche tout en bas.


En gros, j'aurais tendance à conclure que si un paquet ne s'installe pas du premier coup, c'est mort pour essayer ensuite, à part formater le disque et tout réinstaller depuis zéro.

"Ils" ont fait très fort sur ce coup-là...

Quand je fais une recherche de lnet_new dans /etc, là où se trouve fpc.cfg, je n'ai aucune remontée ; quand je recherche dans ~/.lazarus, là ça trouve :

Code :

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

1
2
3
4
5
6
environmentoptions.xml:        <Item1 Value="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_new/lazaruspackage/lnetbase.pas"/>
environmentoptions.xml:        <Item2 Value="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_new/lazaruspackage/lnetvisual.lpk"/>
includelinks.xml:0:/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_new/lib/sys/osunits.inc
inputhistory.xml:    <FileDialog InitialDir="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_new/lazaruspackage/">
inputhistory.xml:        <Item1 Value="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_new/lazaruspackage/"/>
packagefiles.xml:      <Filename Value="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_new/lazaruspackage/lnetbase.lpk"/>

et une recherche sur lnet_allinone en trouve aussi :

Code :

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

1
2
3
environmentoptions.xml:        <Item1 Value="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_allinone/lazaruspackage/lnetvisual.lpk"/>
environmentoptions.xml:      <LastOpenPackages Package1="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_allinone/lazaruspackage/lnetvisual.lpk"/>
packagefiles.xml:      <Filename Value="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_allinone/lazaruspackage/lnetvisual.lpk"/>

À partir de là, je ne sais plus quoi faire à part attendre un patch, une correction pour ce comportement totalement farfelu car, je le répète, si je veux installer depuis le dossier B suite à une install foirée depuis le dossier A, la gestion des paquets continue envers et contre tout à fouiller dans le dossier A.
Loufoque.

Bon, j'ai réussi à couillonner ce comportement débile en déplaçant tous les dossiers précédents des essais divers et variés vers un dossier poubelle, et voilà maintenant que le machin va un peu plus loin, c'est les fichiers dans le sous-dossier "sys/" qu'il ne trouve pas !
Regardez : en bas le message d'erreur où l'on note qu'il dit qu'il ne peut pas ouvrir et que moi je traduis par "ne trouve pas", au-dessus le .pas où l'inclusion est faite et encore au-dessus le .lpk (Gilles, ne pas trouver et ne pas pouvoir ouvrir sont deux comportements différents, il serait bon que les messages d'erreurs soient en phase avec la réalité des choses).


Allez, déplaçons les .inc un cran au-dessus pour supprimer ce dossier "sys/" et relance de la compil... Ça avance bien, cette fois, mais il y avait une mine sous-marine planquée derrière tout ça et elle vient de m'exploser à la figure :


Face à ça, je ne sais pas du tout quoi faire, car le machin est quand même défini à deux endroits : lazaruspackage/lftp.pp: {$DEFINE __front_type__ := TLFTPStatusRec} et lazaruspackage/lsmtp.pp: {$DEFINE __front_type__ := TLSMTPStatusRec}.

Allez, je vais aller lire le dernier Lucky Luke parce que franchement, l'informatique, ce soir, ras le bol !

[mm_71]

regardez le chemin utilisé dans l'ihm après l'ouverture du .lpk (en haut, c'est correct) et dans la console (dessous, en surbrillance) :

Et dans ton fichier /home/utiisateur/.lazarus/environmentoptions.xml il y-a quoi ? C'est ici que sont définis tous les chemins d'accès par défaut.
On dirait aussi que tu as 2 binaires de lazarus et que le démarrage yoyotte entre les 2 ?
As tu effacé ce ./lazarus avant de réinstaller ? Si non ça pourrait venir de là.

[Jipété]

On dirait aussi que tu as 2 binaires de lazarus et que le démarrage yoyotte entre les 2 ?

Ah !
Où vois-tu ça ?
Qu'est-ce qui te le fait dire ? Car moi je ne vois rien de tel...
Et que j'utilise l'icône dans le menu / Programmation / Lazarus ou que j'utilise la console pour avoir du log, dans les deux cas c'est startlazarus qui est activé.

Et dans ton fichier /home/utiisateur/.lazarus/environmentoptions.xml il y-a quoi ? C'est ici que sont définis tous les chemins d'accès par défaut.

Petit bout de la partie qui nous concerne :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
      <PackageFiles Count="10">
        <Item1 Value="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_allinone/lazaruspackage/lnetvisual.lpk"/>
        <Item2 Value="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_new/lazaruspackage/lnetvisual.lpk"/>
        <Item3 Value="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_1_7/lazaruspackage/lnetvisual.lpk"/>
        <Item4 Value="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_mm71/lazaruspackage/lnetvisual.lpk"/>
        <Item5 Value="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet/lazaruspackage/lnetvisual.lpk"/>
        <Item6 Value="/media/sf__share_4_VM/4_Linux/Install_Laz/bgracontrols-master/bgracontrols.lpk"/>
        <Item7 Value="/media/sf__share_4_VM/4_Linux/Install_Laz/bgrabitmap-master/bgrabitmap/bgrabitmappack.lpk"/>
        <Item8 Value="/usr/share/lazarus/1.6/components/todolist/todolistlaz.lpk"/>
        <Item9 Value="/usr/share/lazarus/1.6/components/tachart/tachartlazaruspkg.lpk"/>
        <Item10 Value="/usr/share/lazarus/1.6/components/rtticontrols/runtimetypeinfocontrols.lpk"/>
      </PackageFiles>

Du grand n'importe quoi, vis-à-vis du nom du tag ("PackageFiles"), car on y retrouve aussi bien ceux qui sont installés (en bas de la liste, les 3 derniers n'étant pas de mon fait, de plus ils remontent à l'install de la 1.6 et ce dossier n'existe plus -- c'est vraiment du n'importe quoi ! Et tu dis que C'est ici que sont définis tous les chemins d'accès par défaut., ben on est propres avec ça...), que ceux qui ont foiré (les 5 premiers)

As-tu effacé ce ./lazarus avant de réinstaller ? Si non ça pourrait venir de là.

Et puis quoi encore ?
D'abord Mme Michu n'efface pas les .xml car elle ne sait même pas ce que c'est et de toute façon elle ne risque pas de les trouver puisque le dossier est caché et enfin, c'est au programme de gérer ça proprement.
D'autant plus que si je le supprime, ce fichier, je risque de casser des trucs et des machins -- vu comment tout ça est mal foutu et tourne en eau de boudin, je préfère ne pas prendre de risques.

En fait, pour pouvoir faire des tests pointus, il me faudrait un composant avec la configuration la plus légère possible, genre juste un .lpk, un .pas, un .ico à la rigueur (ou .res ou .lrs) et rien d'autre ; t'as pas ça dans un coin ?

[mm_71]

Qu'est-ce qui te le fait dire ? Car moi je ne vois rien de tel...

Les symptomes.
Ce que je vois maintenant c'est ça:

Code :

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

1
2
3
4
5
6
 
        <Item1 Value="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_allinone/lazaruspackage/lnetvisual.lpk"/>
        <Item2 Value="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_new/lazaruspackage/lnetvisual.lpk"/>
        <Item3 Value="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_1_7/lazaruspackage/lnetvisual.lpk"/>
        <Item4 Value="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet_mm71/lazaruspackage/lnetvisual.lpk"/>
        <Item5 Value="/media/sf__share_4_VM/4_Linux/Install_Laz/lnet/lazaruspackage/lnetvisual.lpk"/>

Le même paquet référencé 5 fois dans des répertoires différents...

D'abord Mme Michu n'efface pas les .xml car elle ne sait même pas ce que c'est

Peut-être ce qui sème le dawa ?

puisque le dossier est caché

Et ?

et enfin, c'est au programme de gérer ça proprement.

Si les infos qu'il reçoit sont erronées il n'y peut rien.

D'autant plus que si je le supprime, ce fichier, je risque de casser des trucs et des machins -- vu comment tout ça est mal foutu et tourne en eau de boudin, je préfère ne pas prendre de risques.

Ce n'est pas seulement le fichier, c'est tout le répertoire qu'il faut effacer, à la recompilation de lazarus il sera recréé automatiquement dans sa version clean et il faudra réinstaller les paquets un à un.
Si après ça le problème persiste je ne vois plus que faire.
Ci dessous des extraits de mon fichier de config concernant les chemins d'accès:

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
21
22
23
24
25
26
 
La ou lazarus va chercher son exe
    <LazarusDirectory Value="/home_common/freepascal/lazarus_1.6">
      <History Count="1">
        <Item1 Value="/home_common/freepascal/lazarus_1.6/"/>
.....
Le compilateur FPC  qui lui peut se trouver dans des reps différents selon les distributions. Seul celui défini dans Lazarus est pris en compte.
    <CompilerFilename Value="fpc">
      <History Count="5">
        <Item1 Value="fpc"/>
        <Item2 Value="/usr/local/bin/fpc"/>
        <Item3 Value="/usr/bin/fpc"/>
        <Item4 Value="/opt/fpc/fpc"/>
        <Item5 Value="$(CompPath)"/>
    <FPCSourceDirectory Value="/home_common/freepascal/fpc-3.0.0">
      <History Count="1">
        <Item1 Value="/home_common/freepascal/fpc-3.0.0"/>
------
Et enfin les paquets.
      <PackageFiles Count="5">
        <Item1 Value="/home_common/freepascal/lazarus_1.6/components/lnet/lazaruspackage/lnetvisual.lpk"/>
        <Item2 Value="/home_common/freepascal/lazarus_1.6/components/lnet/lazaruspackage/lnetbase.lpk"/>
        <Item3 Value="/home_common/freepascal/lazarus_1.6/components/gifanim/pkg_gifanim.lpk"/>
        <Item4 Value="/home_common/freepascal/lazarus_1.6/components/gifanim/pkg_gifanim_dsgn.lpk"/>
        <Item5 Value="/home_common/freepascal/lazarus_1.6/components/ZEOSDBO-7.1.4-stable/packages/lazarus/zcomponent.lpk"/>
      </PackageFiles>

[Jipété]

Qu'est-ce qui te le fait dire ? Car moi je ne vois rien de tel...

Les symptomes.

Tu en as donc fait une mauvaise déduction.
Je répéte : que j'utilise l'icône dans le menu / Programmation / Lazarus ou que j'utilise la console un terminal pour avoir du log, dans les deux cas c'est le binaire startlazarus qui est activé.
Mais je ne lance qu'une seule instance, si c'était ça que tu voulais dire.

Ce que je vois maintenant c'est [...] le même paquet référencé 5 fois dans des répertoires différents...

On s'en fout, tant qu'il prend le bon, il pourrait même y en avoir 36 ! Mais le problème est bien là, et je répéte aussi : si je veux installer depuis le dossier B suite à une première install foirée depuis le dossier A, la gestion des paquets continue envers et contre tout à fouiller dans le dossier A.
As-tu attentivement regardé la copie d'écran qui le montrait noir sur blanc ?

Peut-être ce qui sème le dawa ?

Et ?

Rien compris à ces deux remarques dans la mesure où je ne sais pas si les textes auxquels elles font référence sont ceux au-dessus ou ceux au-dessous.
Mais pour le dossier caché, franchement ça aussi on s'en fout, c'est comme ça sous Linux depuis toujours et ça fonctionne puisqu'il est capable d'écrire dedans.
Le problème c'est qu'il se mélange les pinceaux à la lecture.

Si les infos qu'il reçoit sont erronées il n'y peut rien.

Ouais ben c'est quand même lui qui les écrit dans ce fucking fichier, hein ! Donc il ne sait pas ce qu'il écrit et/ou ce qu'il lit : ça fait peur pour le reste...

Ce n'est pas seulement le fichier, c'est tout le répertoire qu'il faut effacer, à la recompilation de lazarus il sera recréé automatiquement dans sa version clean et il faudra réinstaller les paquets un à un.

réinstaller les paquets un à un c'est c'la, oui...
Tout ça parce que les routines qui gèrent ce fichier sont codées avec les pieds.

Et la preuve : tout à la fin du fichier il y a une section relative aux onglets des composants installés, et comme certains ne me sont d'aucune utilité, j'ai décidé de les enlever de cette section, EDI fermé bien sûr, et à la relance les onglets que j'espérais disparus sont toujours présents donc cette section du fichier ne sert à rien.
Peut-être que c'est pareil pour d'autres sections, alors...

Si après ça le problème persiste je ne vois plus que faire.

Me dire où je peux trouver un composant ultra léger pour faire d'autres tests.

Ci dessous des extraits de mon fichier de config concernant les chemins d'accès:

Code :

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

1
2
Là où lazarus va chercher son exe
    <LazarusDirectory Value="/home_common/freepascal/lazarus_1.6">

Complètement idiot et stupide, ça : il va se chercher lui-même ? ExtractFilePath(Application.ExeName) il ne connaît pas ?
À la réflexion, je pense que c'est ton explication qui ne va pas (celle que j'ai mise en gras) : je crois plutôt que ce chemin, inscrit là, sera utilisé par exemple par fpc pour savoir où reécrire le binaire en cas de recompilation de l'EDI. Là ça du sens et de l'utilité.

Tiens, tu es toujours en 1.6 tout court ?

[yamer]

Il y a un conflit de nom entre l'unité openssl de freepascal et l'unité openssl de lnet. Ce problème a été corrigé depuis environ 1 an dans lnet mais les paquet sur lazarus-ccr n'ont pas été mis à jour. Il faut se procurer la version trunk de lnet par subversion.

Code :

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

1
2
 
svn co http://svn.freepascal.org/svn/fpcprojects/lnet/trunk lnet

[mm_71]

Rien compris à ces deux remarques dans la mesure où je ne sais pas si les textes auxquels elles font référence sont ceux au-dessus ou ceux au-dessous.

Que ce qui sème le dawa c'est peut-être d'avoir plusieurs fois le même composant référencé 5 fois dans des répertoires différents.

réinstaller les paquets un à un c'est c'la, oui...

Bon, si tu n'essaye pas les idées proposées je n'ai plus qu'a déclarer forfait. Bon courage mais prend quand même en compte le fait qu'a ma connaissance tu es le seul utilisateur à rencontrer ces problèmes avec Lnet. En désespoir de cause essaie synapse ou indy.

et à la relance les onglets que j'espérais disparus sont toujours présents donc cette section du fichier ne sert à rien.

Une fois lazarus démarré vas dans outils-Options-palette des composants > importer environnementoptions.xml et tu verras à quoi ça sert. Noter aussi que si tu as ces lignes c'est que tu as déjà plus ou moins utilisé cette section, par défaut elles ne sont pas dans le fichier et ne servent que pour la personnalisation de la palette.

il va se chercher lui-même ? ExtractFilePath(Application.ExeName) il ne connaît pas ?

Il ne connait qu'une fois actif, au démarrage il ne peut rien connaître.

Tiens, tu es toujours en 1.6 tout court ?

Non, je n'utilise pas les deb's je compile depuis les sources, dans ce cas quelque soit le nom du répertoire ça n'a aucune influence et comme je suis un gros feignant qui n'a pas envie de mettre à jour ses signets j'ai juste viré les sources de la 1.6 pour mettre celles de la 1.6.2 dans le même répertoire, de plus cette méthode permet aux fameux fichiers ./laz/ de se mettre à jour automatiquement en fonction de la version utilisée puisque aucun chemin d'accès n'a changé .

[gvasseur58]

Et Gilles qui se demande pourquoi je reste avec mon 1.4... Faut pas s'étonner, quand on vit ce que je vis. Parce que là, "ils" nous ont pondu un EDI en porcelaine, faut surtout pas y toucher sinon ça casse comme du cristal !

Bonjour Jipété !

Déjà, désolé d’intervenir un peu comme un cheveu sur la soupe et non dans le tempo de la discussion, mais j'étais très pris.
Bon, comme tu m'as cité plusieurs fois dans tes messages, j'ai ressorti mon ordi spécial Linux (Linux Mint Sarah) qui somnolait depuis quelque temps et j'ai installé la version 1.6 de Lazarus : pas de problèmes.
Pour la version 1.6.2, j'ai d'abord fait une installation sans précautions : une catastrophe...
Puis j'ai tout nettoyé, réinstallé 1.6, puis nettoyé 1.6 puis installé 1.6.2. En dehors d'un message me signalant qu'il restait un résidu de 1.6 et me demandant s'il fallait le mettre à jour (ce à quoi j'ai répondu oui), tout s'est encore une fois très bien passé.
Tu sais que je ne suis pas porté sur la magie blanche ou noire et que je conclus de ces opérations qu'il doit y avoir des raisons qui font que l'installation fonctionne ou pas avec Linux (car avec Windows, je n'ai vraiment eu aucun problème). Je crois qu'il s'agit d'une question de procédures et de choix :

• je nettoie tout avant d'installer quoi que ce soit. En particulier, je fais disparaître le(s) répertoire(s) où figurent encore des reliquats de Lazarus ;
• je ne fais aucun test de production avec des versions RCx puisqu'elles sont explicitement annoncées comme susceptibles de comporter des bogues importants ;
• pour la même raison, je n'installe pas de bibliothèques avec les versions RCx, car, à moins d'être l'auteur d'une bibliothèque, j'estime que c'est souvent une perte de temps [alors, tu me diras, pourquoi installer une telle version ? A mon avis, sauf test et retour vers la communauté, il n'y en a aucune...] ;
• pour les versions supposées stables, j'installe les bibliothèque mises à jour régulièrement, quitte à les désinstaller au moindre problème.

Je ne pense pas détenir "la" vérité, mais ces principes me soulagent de beaucoup de désagréments. Par exemple, quand tu nous montres qu'un chemin que conteste Lazarus existe pourtant bel et bien, tu fais une toute petite erreur d’interprétation du message d'erreur renvoyé par Lazarus : il ne dit pas que le chemin n'existe pas, mais affirme qu'il n'en a pas un qui lui soit propre... En fait, les versions, faute de désinstallation correcte, s'empilent et s'emmêlent les pinceaux. [Alcatîz m'a par ailleurs signalé que faire côtoyer Lazarus et CodeTyphon sur la même machine Linux conduit aussi à des salades dans les versions du compilateur FPC - 3.0.0 ou 3.1.1]

Donc, cher Jipété, je réitère mon conseil : il faut passer à la dernière version, car elle corrige des bogues et ajoute des fonctionnalités intéressantes. Ce conseil s'accompagne dorénavant au moins d'un autre : il faut bien nettoyer la version installée avant de penser installer la suivante. [Je parle toujours pour Linux, car Windows est plus souple à ce niveau]

Je te laisse digérer ces commentaires pour éventuellement les contester. Comme ce que j'ai écrit est assez long, je réserve un autre post pour aborder un autre problème récurrent : celui des paquets et de la reconstruction de l'EDI.

Cordialement,

Gilles

PS : encore une fois, mille excuses à ceux qui vont penser que ce post est décalé par rapport à la discussion

[Jipété]

Il y a un conflit de nom entre l'unité openssl de freepascal et l'unité openssl de lnet. Ce problème a été corrigé depuis environ 1 an dans lnet mais les paquet sur lazarus-ccr n'ont pas été mis à jour. Il faut se procurer la version trunk de lnet par subversion.

Ah ah !
Comme on dit toujours, il vaut mieux un qui sait que dix qui cherchent,
Merci pour cette info, je teste ASAP.

Par ailleurs, j'ai un mea culpa à faire quand je disais qu'il y avait une embrouille entre dossier A et dossier B : ça me semblait tellement bizarre que je suis parti du tuto de Gilles, je l'ai suivi à la lettre jusqu'à l'install que je n'ai pas effectuée, j'ai alors modifié le .pas pour que la compil échoue (mettre en rem le uses rajouté), j'ai lancé l'install ça a échoué, normal, j'ai fermé, créé un nouveau dossier dans lequel j'ai mis les fichiers et où j'ai corrigé l'erreur, j'ai relancé l'EDI et ouvert le paquet du nouveau dossier (toujours à partir du chemin chelou qui te pose un problème, mm ) et tout s'est bien passé !

Conclusion : l'erreur indiquée par yamer devait masquer autre chose, ou influencer le comportement général et c'est sans doute pour ça que j'en ai mal déduit cette embrouille de dossier A <> B.

Bon courage mais prends quand même en compte le fait qu'a ma connaissance tu es le seul utilisateur à rencontrer ces problèmes avec Lnet.

Ce n'est pas parce que je suis le seul à râler (ma caractéristique) que je suis le seul à avoir le problème. Peut-être que d'autres ne s'en sont pas sortis et ont installé d'autres produits. On ne sait pas, on ne saura jamais...

En désespoir de cause essaie synapse ou indy.

Vi mais je n'avais pas envie d'installer une usine à gaz juste pour un ou deux tests rapides genre "ping".
Et puis, quand il y a une blague qui n'existait pas dans mon install précédente, j'aime bien solutionner le problème.

yamer a peut-être mis le doigt dessus, la seule chose qui me chagrine, c'est que tu m'avais passé un .rar avec "svn" dans le titre, on pourrait en déduire que c'est la même chose que le lien de yamer mais j'ai regardé vit' fait pour comparer et pas du tout : dans le dossier lib, il y a des fichiers identiques mais de tailles différentes, et le trunk de yamer a des fichiers renommés et même un en plus par rapport à ton rar !
Bah, je verrai bien et je vous tiendrai au courant...

Donc, cher Jipété, je réitère mon conseil : il faut passer à la dernière version, car elle corrige des bogues et ajoute des fonctionnalités intéressantes. Ce conseil s'accompagne dorénavant au moins d'un autre : il faut bien nettoyer la version installée avant de penser installer la suivante. [Je parle toujours pour Linux, car Windows est plus souple à ce niveau]

C'est ce nettoyage qui m'effraie : quid des compos (parfois) laborieusement installés ?

PS : encore une fois, mille excuses à ceux qui vont penser que ce post est décalé par rapport à la discussion

Ah mais pas du tout, et tiens, j'ai quelque chose pour toi par rapport à ton tuto sur les composants : pourquoi faire cliquer sur la disquette de la barre principale de l'EDI quand on a un bouton "Enregistrer" dans la petite fenêtre du "gestionnaire" de paquets ?

[Jipété]

Il y a un conflit de nom entre l'unité openssl de freepascal et l'unité openssl de lnet. Ce problème a été corrigé depuis environ 1 an dans lnet mais les paquets sur lazarus-ccr n'ont pas été mis à jour. Il faut se procurer la version trunk de lnet par subversion.

Ai recopié la version svn dans mon b0rd3l de dossiers qui effraie tant mm_71 (), ai lancé l'EDI, lui ai dit "va chercher .lpk dans dossier lnet_trunk", il l'a fait, lui ai dit "compile" il l'a fait ! lui ai dit "installe" il l'a fait aussi ! ! !
Il s'est recompilé avec mon accord, il s'est redémarré et j'ai mon nouvel onglet avec les compos lNet !
PS : du coup, ça passe sa version à 0.6.6.

Au final, Lazarus (ou peut-être plutôt fpc ?) a donc un problème comme décrit par yamer, mais aussi une très mauvaise remontée des erreurs, et c'est ça qui nous a fait perdre un temps fou...

Bah, on aura appris des trucs.
Merci à tous, Gilles, j'attends quand même que tu me répondes à propos de ta notion de "nettoyage" : quid des compos installés si tu vires tous les fichiers de configuration

[mm_71]

Il y a un conflit de nom entre l'unité openssl de freepascal et l'unité openssl de lnet. Ce problème a été corrigé depuis environ 1 an dans lnet mais les paquet sur lazarus-ccr n'ont pas été mis à jour. Il faut se procurer la version trunk de lnet par subversion.

Code :

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

1
2
 
svn co http://svn.freepascal.org/svn/fpcprojects/lnet/trunk lnet

Le Lnet sur ton url serait différent de celui qui est dans

Code :

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

https://lazarus.svn.sourceforge.net/svnroot/lazarus/trunk lazarus

?
Parce que celui qui est dans dans le trunk lazarus est toujours 0.6.5 comme celui des sources lazarus 1.6.2 qui n'a pas posé de problème chez moi .
Linux Mint 18 Sarah
Free Pascal Compiler version 3.0.0 [2015/11/20] for x86_64

[yamer]

Le Lnet sur ton url serait différent de celui qui est dans

Code :

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

https://lazarus.svn.sourceforge.net/svnroot/lazarus/trunk lazarus

?
Parce que celui qui est dans dans le trunk lazarus est toujours 0.6.5 comme celui des sources lazarus 1.6.2 qui n'a pas posé de problème chez moi .

Tout ce que je peux te dire c'est que j'ai trouvé l'adresse du svn lnet dans le wiki Lazarus (http://wiki.lazarus.freepascal.org/lNet#Download) et que j'ai constaté que la version sur lazarus-ccr était en retard.

S'il y a un lnet qui fonctionne dans le trunk Lazarus et que je ne l'ai pas utilisé c'est juste par que je ne savais pas qu'il était là... Il est dans quel dossier d'ailleurs ?

[mm_71]

Tout ce que je peux te dire c'est que j'ai trouvé l'adresse du svn lnet dans le wiki Lazarus (http://wiki.lazarus.freepascal.org/lNet#Download) et que j'ai constaté que la version sur lazarus-ccr était en retard.

Oui c'est bien ça.

S'il y a un lnet qui fonctionne dans le trunk Lazarus et que je ne l'ai pas utilisé c'est juste par que je ne savais pas qu'il était là... Il est dans quel dossier d'ailleurs ?

Je me suis fort mal exprimé quand j'ai dit ça, le mot lazarus était de trop, Lnet n'est pas dans lazarus par défaut et c'est bien le lien que tu donnes ou est le bon fichier que j'utilise aussi.
La chose que je ne comprendrai sans doute jamais c'est que ça fait bien partie des fichiers que j'ai envoyé à jipété et que ça ne marchait pas. La dernière version est bien 0.6.5 mars 2011 et c'est ce que j'ai après compil. Aucune 0.6.6 n'est trouvable.
Je pense que ceci restera un grand mystère pour moi.

[Jipété]

La chose que je ne comprendrai sans doute jamais c'est que ça fait bien partie des fichiers que j'ai envoyé à jipété et que ça ne marchait pas. La dernière version est bien 0.6.5 mars 2011 et c'est ce que j'ai après compil. Aucune 0.6.6 n'est trouvable.

Extrait du lnetbase.lpk du lien de yamer :

Code :

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

    <Version Minor="6" Release="6"/>

Et à propos du fait que ton .rar ne fonctionnait pas et le lien de yamer oui, j'ai déjà répondu qu'il y avait dans son lien un fichier de plus, et le fait qu'au moins un a été renommé (peut-être plus mais flemme de chercher)

[mm_71]

Extrait du lnetbase.lpk du lien de yamer :

Ok, je viens de comprendre. Encore un problème d'information plutôt pourrie. Sur la page concernée on lit:

Download
| lNet package
SVN: http://svn.freepascal.org/svn/fpcprojects/lnet
Change Log
Version 0.6.5 completed SSL server support. Completed IPv6. Fixed DecodeURL problems and disconnect bugs

Et vu l'âge du capitaine (Dernière MAJ 2013 ) j'étais convaincu que l'archive .zip reflétait l'état du SVN ce qui n'est pas le cas, le .zip contient la version lazarus-ccr. La 0.6.5 ne me posant pas de problème j'étais convaincu que c'était la bonne.
Je ne sais pas qui s'occupe du wiki mais je crois que qq. mises à jour radicales seraient les bienvenues ! ( A cette phrase devrait suivre une rafale d'épithètes cornus mais je me retiens... )

[gvasseur58]

C'est ce nettoyage qui m'effraie : quid des compos (parfois) laborieusement installés ?

Avec un décalage persistent parce que je me suis plus occupé de Delphi ces derniers temps, je reviens aux bibliothèques et à leur réinstallation avec Lazarus. Pourquoi citer Delphi ? Eh bien, Delphi ne sait pas résoudre le même problème : pour chaque version, il faut désinstaller tout le produit et réinstaller tous les composants tiers. Ce n'est pas que personne ne travaille sur le sujet, ou que certains s'en réjouissent à cause de leurs tendances masochistes, mais c'est que l'éventuelle solution - genre patch, par exemple - est très complexe à mettre en œuvre puisque certaines modifications essentielles touchent au cœur de l'EDI. Pour Lazarus, on pense bien entendu au passage à l'Unicode, mais aussi à des bibliothèques qui font partie de Lazarus lui-même (la plus connue étant SynEdit).

De plus, si Lazarus a un avantage sur Delphi qui est d'être opensource, il a un gros inconvénient : les bibliothèques sont liées statiquement. Il faut donc recompiler Lazarus à chaque ajout d'une bibliothèque. On imagine facilement qu'il est indispensable que ces ajouts soient totalement compatibles avec la version installée (cela est vrai pour Delphi aussi, mais différemment).

Personnellement, j'en tire quelques conclusions à prendre ou à laisser :

• limitation au strict minimum des bibliothèques externes = utilisation au maximum des composants natifs ;
• abandon systématique (ou presque) des bibliothèques qui s'installent difficilement = le problème ne présage rien de bon sur la stabilité du produit ;
• installation de bibliothèques autour desquelles une activité de développement est avérée = très peu ou pas de vieilleries rafistolées par mes soins après des heures et des heures de crise.

La première conclusion était largement partagée par les présents au séminaire Delphi du 24 à Lyon : je me suis senti moins seul .
Bon, tu me diras que ma méthode fait le vide et qu'elle risque de m'interdire quelques fonctionnalités importantes. C'est vrai, mais je cherche si nécessaire des composants bien travaillés (et il y en a) ou je les fais moi-même si je ne trouve rien et si mes compétences me le permettent.

La philosophie générale sous-jacente serait donc : un EDI toujours à jour, avec un minimum d'ajouts . Sinon, pour ceux qui préfèrent des ensembles tout ficelés, il faut passer à CodeTyphon. Mais il y a alors des inconvénients : les produits proposés ne sont pas toujours bien finis ni stables .

Tiens, j'ai quelque chose pour toi par rapport à ton tuto sur les composants : pourquoi faire cliquer sur la disquette de la barre principale de l'EDI quand on a un bouton "Enregistrer" dans la petite fenêtre du "gestionnaire" de paquets ?

Merci bien En fait, ce tutoriel date déjà et il mériterait une couche de Ripolin. Le composant proposé est d'ailleurs loin d'être bien écrit... Je prévois un peu plus ambitieux puisque j'ai une série de composants déjà fonctionnels que j'inclurais volontiers dans une mini-série de tutoriels. Mais le travail est sous forme d'ébauche.

Cordialement,

Gilles

[Jipété]

Bonsoir,

et merci pour ce retour bien argumenté.

Cependant, quand je lis

limitation au strict minimum des bibliothèques externes = utilisation au maximum des composants natifs ;

je ne peux pas m'empêcher de penser que c'est quand même dommage d'avoir un outil qui permet de créer des composants avec la contrainte de ne pas pouvoir les utiliser

Tu me diras, c'est comme les bagnoles : pour ne pas avoir d'accident, suffit de la laisser au garage

Allez, c'était la plaisanterie du dimanche soir,

[gvasseur58]

je ne peux pas m'empêcher de penser que c'est quand même dommage d'avoir un outil qui permet de créer des composants avec la contrainte de ne pas pouvoir les utiliser

Je suis bien d'accord, mais tu auras compris que les principes énoncés étaient là pour être ignorés de temps en temps. Ce sont des garde-...