Discussion :

[pomalo]

Bonjour

il y a deux jours, j'ai téléchargé un "snapshot" 0.9.29 fpc 3.3.1 pour win32.
je l'ai installé et continuer le portage de mon ancienne application delphi.
j'ai recompilé ZeosDbo 6.6.5

Dès que je lançait l'appli sous win32, dès l'ouverture de la table, je recevait un exception EconvertError me disant que le resultat d'une colonne contenant un float n'est pas une valeur flottante correcte et ce pour chaque ligne contenant des décimales et je n'avait que des 0 dans mes grilles
Sous linux aucun problème avec le même code et la même base.

j'ai créé une petite application contenant juste une TZConnection et une TZquery sélectionnant la colonne et la dès que je la lance sous win32, patatras elle gamelle me donnant à penser qu'il y a bien un problème du coté de Zeos ou lazarus.

je vient de réinstaller lazarus 0.9.27 et FPC 2.2.4 (snapshot) et j'ai recompilé mon appli. Plus de problème, l'appli tourne comme il faut.
Reste a savoir qui de lazarus ou de zeos est fautif?

il fraudai que j'isole le problème pour faire un report de bogue aux développeurs de l'élément responsable.

quelqu'un a il testé le premier couple?



merci
Claude

[Invité]

Bonjour,

Qui est fautif ? Vous avez des doutes ? Comme c'est Zeos qui s'adapte à FPC et non le contraire... c'est Zeos le fautif !

Non, je plaisante... et je ne voudrais pas être désagréable... Mais comme je l'écrivais récemment, il faudrait peut-être que le couple Lazarus/Free Pascal se "fixe", remette son code à l'endroit et le rende propre. Il n'y a qu'à lire le forum pour se rendre compte que des problèmes rédhibitoires traînent dans le temps : l'UFT8/Ansi sur plusieurs composants (c'est quand même dramatique sur un outil qui veut être compatible Windows et Linux), les Grids (pas que les String), les connecteurs natifs... Evidemment, avec beaucoup de bidouilles et de contournements, on arrive souvent à s'adapter... jusqu'à la prochaine release... où là, le contournement ne contourne plus, ou pire, où ce qui fonctionnait sans contournement en nécessite un : Lazarus restera toujours en beta avec de telles méthodes.

Les "autres" (Zeos par exemple), ils font ce qu'ils peuvent ! La 0.9.27 n'est pas encore "stable" sous FPC 2.2.x [normalement cela devrait être la 0.9.28], que la 0.9.29 sous FPC 3.x serait (est ?) dans "le commerce". Je suppose que c'est pour les beta-testeurs Faut être sérieux ! Lazarus 0.9.26+Zeos 6.6.4 cela fonctionne correctement. Maintenant, si à chaque évolution de FPC, tous les add-on aussi costauds que Zeos (compatible Delphi) plantent, on va où ?

Pour les StringGrids ou plus exactement à cause d'eux et leur misère, j'ai commencé modestement à "entrer" dans le code de Free Pascal. Commencé seulement mais suffisamment pour me rendre compte que par endroits, c'est un assemblage de... rustines (c'est l'image qui me vient "naturellement" à l'idée) au point que finalement, mes certitudes de programmeur ne sont plus que des hypothèses. Mais, il est plutôt facile de comprendre globalement (et évidemment pas dans le détail) pourquoi les StringGrids et leurs columns sont dans cet état... et pourquoi il est quasiment impossible de les réparer ! La propriété Visible des colonnes plante : ayez la curiosité de faire une "visite de la maison" et je suis pratiquement sûr que vous partagerez mon opinion et balayerez vos doutes ! Je me dis que c'est miraculeux que cela fonctionne "autant". Faudrait peut-être acheter une chambre à air neuve (rapport aux rustines )? C'est peut-être le cas de FPC 3 et dans ce cas, ce n'est pas grave, c'est même une chance... et les programmeurs de Zeos vont pouvoir facilement s'adapter

Cordialement. Gilles

[mittag]

...j'ai commencé modestement à "entrer" dans le code de Free Pascal. Commencé seulement mais suffisamment pour me rendre compte que par endroits, c'est un assemblage de... rustines (c'est l'image qui me vient "naturellement" à l'idée) au point que finalement, mes certitudes de programmeur ne sont plus que des hypothèses. Mais, il est plutôt facile de comprendre globalement (et évidemment pas dans le détail) pourquoi les StringGrids et leurs columns sont dans cet état... et pourquoi il est quasiment impossible de les réparer ! La propriété Visible des colonnes plante : ayez la curiosité de faire une "visite de la maison" et je suis pratiquement sûr que vous partagerez mon opinion et balayerez vos doutes ! Je me dis que c'est miraculeux que cela fonctionne "autant". Faudrait peut-être acheter une chambre à air neuve (rapport aux rustines )? ....

Je partage entièrement cet avis, cela fait bien longtemps déjà que j'ai émis un avis semblable sur quelques forums (où je me suis fait incendié ...). J'ai toujours été convaincu que l'équipe de développeurs comporte un certains de "charlots" qui causent du tort à l'évolution du produit, malheureusement l'équipe qui supporte le projet ne comprend ce discours et ne voit pas l'intérêt d'avoir une base avec les principaux composants graphiques, qui soit réellement fiable sous linux, windows et mac. Il y a à chaque version des régréssions, figurez-vous que 10 ans plus tard, les scrollbox ne sont toujours pas au point!!!!!!! Quand à la liste impressionante de bugs réparés chaque jour, c'est du pipeau pour la plupart, une fois sur deux vous avez un développeur qui répond: "chez moi ça marche", ou bien "c'est un bug de windows", et si le reporter ne répond dans un certain délai le, bug est tout simplement classé comme résolu!! Dernièrement un reporter a demandé s'il était envisageable de faire un outil qui convertirait de A à Z un projet Delphi en Lazarus (avec uniquement les unites standards), réponse d'un des développeurs: "quel est l'intérêt?" (le soit-disant convertisseur actuel est entièrement bidon ou presque, le nom des unités est inchangé).

Bref, tout ça pour dire que j'utilise quand même lazarus, pour m'amuser car on peut quand même faire des choses , mais que cela est, et restera TOUJOURS, du bricolage d'amateur, instable par ses régressions. Le seul avenir que je vois, est qu'une boîte sérieuse s'empare du projet Lazarus, le mette au point pour en faire son produit libre phare, tout en en commercialisant d'autres gammes de produit (comme avait fait Borland avec Kylix Open Source).

[chris37]

Salut les râleurs

Alors dans l'ordre :

Qui vient faire des tutos avec moi ? Personne! comme d'hab...
Qui vient faire des composants ? Personne ! comme d'hab
Qui vient aider les autres ? Toujours les mêmes
Qui participe a ce projet Lazarus ? Aucun d'entre vous
Qui fait des traductions du wiki en Français ? Merci Paul Un Français
Qui a amélioré la gestion graphique ? Merci Laurent (Wile64) Un Français
Qui a échangé avec Joost V. pour ajouter des fonctions ds les natifs ? bibi
Qui a aider Jesus R. a débugger une grid ? bibi

Personne ne prend le temps de mettre en forme et ou de rédiger...

Alcatiz a repris une partis de notre ancien forum pour aider la communauté Française en faisant un sacré travail pour la FAQ de developper.com..... Et pourquoi en retour.... Le Gaulois râle....

Un livre est dans les cartons ! et oui..... Je vais proposer à sont auteur (un garçon charmant et courageux) de le rédiger uniquement en anglais.....

Merci pour votre collaboration et bon amusement avec Lazarus

[SergioMaster]

Allons , allons un peu de modération , connaissez vous l'expression :
"La critique est facile , l'art est difficile"

OUI

• les versions se suivent et ne se ressemblent pas toujours , la compatibilité ascendante n'est pas toujours au RDV
• la réponse des développeurs n'est pas toujours elle aussi au RDV
• une grosse lacune de composant
• la gestion du projet obscure
• la documentation est parcellaire
• il faut utiliser la langue de Chatquirespire (perso ça me gène pas , la preuve) mais la programmation n'est-elle point en cette langue si délicate

MAIS

• C'est un EDI Open source qui a le mérite d'être multi plateforme (même avec quelques couacs) vous en connaissez beaucoup ?
• Cet Edi tente de ne pas nous faire perdre nos connaissances (et pire nos habitudes) Delphi vous en connaissez beaucoup ? (ne me dites pas Kylix )
• les sérieux efforts (ALCATIZ,CHRIS37) sont quand même a féliciter , ce qu'on oublie bien trop facilement
• les composants de base de Delphi n'était guère plus nombreux il y a 14 ans, ils sont venus au fil du temps et grâce a sa démocratisation , cette dernière ayant été perdue en cours de chemin.
• on râle on râle mais beaucoup sont content de l'économie de 450€ (maj Delphi pro , ou est t-il le temps de la démocratisation de Pascal si Phillipe Khan ne dormait pas sur son matelas d'oseille ......)

Quant au reste , et bien c'est une affaire de volontariat, de disponibilité , de courage et d'écriture ( pour les trois derniers je dois avouer mes lacunes) .

et enfin pour te répondre Chris :

Bien qu'ayant de nombreux projet dans les tuyaux , aucun n'étant vraiment finalisé, ce qui me bloque le plus c'est bien l'écriture (syndrôme de la page blanche ) et je l'avoue la méthode de mise en place de ce qui est écrit . Je nage aussi bien dans le Wiki que dans le bac a sable et ,sans vouloir critiquer, la pose de FAQ candidates est on ne peut plus obscure (Suggestion pourquoi n'est-ce pas aussi simple que delphi ou firebird ?)
enfin ces points sont peut être du à la sclérose de mon cerveau

Je reste persuadé que LAZARUS a un avenir (peut-être avec un Chef de projet plus 'volontaire' et 'directif' , mais là je ne suis absolument pas volontaire)

Serge

[mittag]

Qui participe a ce projet Lazarus ? Aucun d'entre vous

Bonjour Chris37,

C'est là qu'il y a malentendu! Lazarus n'est pas mon projet! J'utilise lazarus pour réaliser mes projets, pour les utilisateurs comme moi, lazarus n'est pas une fin en soi mais un outil. Les utilisateurs signalent ce qui leur semble être un dysfonctionemment de l'outil (ce qui devrait faire avancer le produit), mais n'ont pas pour projet de réparer les outils, ça c'est le projet de l'équipe lazarus.
Des utilisateurs râlent parce qu'ils doivent abandonner temporairement leur projet pour essayer de résoudre les problèmes de lazarus pour pouvoir ensuite résoudre les problèmes posés par leur projet, ça fait beaucoup, et il est clair que pour une boîte de programmation professionnelle, c'est intenable.

Par contre, j'ai eu l'occasion d'écrire des programmes sans GUI (donc sans lazarus en fait ) et je n'ai jamais eu rencontré de problèmes, cela signifie que le compilateur FPC est au point.

Je tiens également à dire que je fais partie d'une équipe de maintien de projet, et que jamais nous n'avons répondu à nos utilisateurs: c'est à vous de contribuer pour résoudre nos problèmes, notre politique est plutôt l'inverse!

[chris37]

Bonjour Mittag,

Je comprend tes motivations professionnelles et les accepte bien volontiers car elle rejoignent les miennes.

Là ou je fais des bonds, c'est que Lazarus est en évolution perpétuel (Manque de développeurs) et que mon souhait était de monter une équipe française de création de composants adaptés et plus complet pour justement lisser les problèmes dont tu parles...avec documentation, site web et tout le tralala.

Je me rend compte qu'au final, peu de personnes prennent la peine d'apporter une petite contribution.

Si on regarde la Jedi de Delphi, on peut remercier nos amis russes qui ont largement contribué à sont développement initial et que la France entière utilise

Cordialement,
Chris

[Invité]

Bonjour Chris37, SergioMaster, Mittag,

Aujourd'hui, je soutiens l'analyse de Mittag, en des termes moins "directs". On remplacera "Charlots" par "Collègues présentant une divergence de stratégie et utilisant des méthodes de développement euh...'différentes'" . Même si cela ne me fait pas vraiment plaisir, les arguments techniques sont à quelque chose près, ceux que l'entreprise dans laquelle je travaille a finalement retenus pour mettre fin au test Lazarus. Après 6 mois d'utilisation, cette plateforme sera donc abandonnée chez nous.

Il faut admettre que certains composants notamment graphiques (mais pas seulement) sont bugués au point qu'ils sont à mon avis inutilisables dans le cycle de vie d'un logiciel. Je ne connais pas le problème des ScrollBox évoqués par Mittag, mais beaucoup mieux depuis mes dernières vacances celui des StringGrids. Et je me demande (les incertitudes évoquées dans le message précédent) comment on pourrait résoudre le problème... à supposer que contrairement à Mittag dont la position correspond souvent à celle des SSII, on accepte de participer à la modification du code de la plateforme de développement.

Il y a des bugs disséminés à divers endroits dans les divers héritages nécessaires au fonctionnement du StringGrid. Héritages souvent utilisés par d'autres composants. Cela me semble être une équation sans solution tant que les héritages ne seront pas "unifiés", compatibles avec tous les composants qui les utilisent. Dans le développement de Lazarus/FPC, il faut faire un break pour harmoniser et stabiliser l'ensemble. Cette étape ne semble pas faire partie des pratiques de l'équipe de développement. Qu'ont-ils à craindre ? Pas grand chose ! De perdre des fanatiques de la nouveauté, de la release quotidienne ? C'est la fuite en avant à "l'Ubuntu"... Je suis Debian... ce n'est pas la même philosophie... Et qu'ont-ils à gagner ? Un parc plus important d'utilisateurs et de professionnels du développement engendrant ainsi un cercle vertueux et profitable à tous.

A Chris,
je vais continuer à utiliser Lazarus à titre personnel. Alors, j'avoue que notre "abandon" est décevant (mais pragmatique : ce n'est pas sa vocation ni d'ailleurs son profit que d'améliorer ou corriger la plateforme de développement) et je retiendrai l'aspect positif : je ne bénéficierai plus du temps consacré par l'entreprise mais d'un autre côté, il n'y aura pas de pression au niveau du timing.
J'avoue également ne pas aimer trop travailler avec des gens qui ont des réactions "épidermiques" sauf dans le cadre de Brainstorming libératoires...
Dans les autres cas, même si on s'investit énormément, on peut accepter les critiques des autres -sans les ramener nécessairement à soi même- d'autant qu'investissement et objectivité sont souvent inversement proportionnels : "Plus t'as le nez dans le guidon, moins t'as de recul et moins tu vois loin" si on peut dire... Donc, je suis disponible pour le StringGrid mais franchement je suis dans l'expectative... et à mon avis, vouloir s'occuper de se composant, impose d'en corriger pas mal d'autres : pendant mes vacances, j'ai essayé de tracer les diverses dépendances, héritages & co utilisés par les StringGrids. Je me demande où on attaque ? Aurais-tu une meilleure perception que moi de la "chose" ? Probablement puisque tu as déjà travaillé sur les LZcomponents. Question subsidiaire : on attaque quand, comment (à partir de quelle release de FP ?), quoi (et non qui !) ?
Je suis partisan d'une ouverture complète, claire et disponible aussi bien sur le code que sur les méthodes. Faut de l'adhésion... et de l'adhérence : va falloir s'accrocher ! Bref, on s'organise (modestement) mais efficacement...

A bientôt. Cordialement. Gilles