Discussion :

[Ph. B.]

Sortie officielle de Lazarus version 1.0
Une étape cruciale dans le développement du clone open source et multiplateforme de Delphi, démarré en 1999

Cet article reprend la communication de l'équipe de développement de Lazarus publiée hier soir dont la version originale est accessible ici

L'équipe de Lazarus est heureuse d'annoncer la disponibilité de Lazarus 1.0.

Lors de cette étape importante, l'équipe actuelle tient à remercier les personnes passées et présentes qui se sont impliqués dans ce projet et ont permis d'en arriver là.
Merci aussi à l'équipe de FPC qui fournit le compilateur qui permet tout cela.
Merci tout spécial aux fondateurs du projet Lazarus il y a plus d'une décennie en 1999: Cliff Baeseman, Shane Miller et Michael A. Hess.
Une histoire des développeurs impliqués peut être consultée à cette adresse. Et une liste des nombreux contributeurs est fournie avec la distribution.

Cette version est disponible sur la page de téléchargement du site SourceForge.

Sélectionnez d'abord votre processeur, SE, distribution, puis le répertoire «Lazarus 1.0».

Configuration minimale:
Windows: 98, 2k, XP, Vista, 7, 32 ou 64 bits
FreeBSD / Linux: gtk 2.8 ou qt4.5, 32 ou 64 bits
Mac OS X: 10.4, LCL seulement 32 bits, 64 bits possible pour les applications non LCL.

Cette version s'appuie sur le compilateur fpc 2.6.0 (comme la version 0.9.30.4 précédente).

Le dépôt svn.
La liste des changements.

Pour les personnes qui sont bloquées par SF, les versions de Lazarus mirrorés depuis sourceforge sont accessibles sur cette page et plus tard à (après un certain délai du à la synchronisation) sur le site de l'université de Halle-Wittenberg et ici

Et vous ?

Que pensez-vous de cette évolution d'une éternelle version beta vers une version stable ?
Pensez-vous que ce Lazarus 1.0 soit enfin assez mature pour le développement professionnel ?

[Nexavi]

Que pensez-vous de cette évolution d'une éternelle version beta vers une version stable ?

Lazarus a fait une énorme progression ces deux dernière années. juste hallucinant !
Puisque c'est un IDE:

- on est passé du texte aliasé à anti-aliasé (même s'il faut toujours l'activer manuellement).
- l'éclairage dynamique de l'identifieur qui a le scope (genre si tu cliques un "GetMem" dans le code, tous les "GetMem" sont alors être encadrés.
- la vitesse des dispositifs automatiques: autocomplétion, menu de proposition, etc...est maintenant normale, dans le passé cela avait l'air d'un truc merdique fait avec un pauvre timer et son callback.

Par contre, on peut se demander pourquoi l'interface dockée n'a pas été plus développée (il est toujours possible de l'installer, un lpk est fourni dans les composants), certes cela se discute: quand on travaille sur plusieurs écrans, le docking peut s'avérer être gênant.
Par contre sous Ubuntu et avec le système de menu unifié balancé sur la toolbar de Gnome c'est juste une catastrophe qui déssert Laz...
(alors que sous Fedora...nickel)

Pensez-vous que ce Lazarus 1.0 soit enfin assez mature pour le développement professionnel ?

Oui et non.

-non: le débogage est assez pénible sur Lazarus. En tant que développeur de composant (entre autres), je préfère toujours déboguer sous delphi. L'inspection de l'object incriminé sous Laz. n'est pas possible. Dans un sens cela encourage un développement de qualité mais peux s'avérer être extrêmement pénible pour quelqu'un qui programme des choses complexes.
- oui: avec de bonne pratiques, de bons tutos sur comment configurer le compilo, les optimisations, etc.
- oui et non: ca dépend de ce que l'on fait...il ya aussi la question des BDD qui mérite une appréciation plus spécialisée...

Lazarus + FPC c'est presque au niveau de Delphi 2007 en confort d'utilisation...
vraiment, mais vraiment pas loin.

C’est juste énorme ce qui a été fait depuis 2 ans.

[Invité]

Malgré le mot "beta" cet environnement s'est toujours montré d'une grande stabilité chez moi et je suis tout à fait convaincu qu'il peut être utilisé pour des projets sérieux. Les développeurs utilisant "Delphi" devraient songer à y migrer selon moi : Lazarus a évolué plus vite que ce dernier depuis son abandon par Borland.

[Serguei_TARASSOV]

Il y a longtemps que j'utilise Lazarus et je vois qu'il devient de plus en plus stable et riche fonctionnellement.
Par contre, le gros problème est ce que sur le site comme monsters.fr vous ne trouverez rien par le mot clé "Lazarus"...

[Invité]

Il y a longtemps que j'utilise Lazarus et je vois qu'il devient de plus en plus stable et riche fonctionnellement.
Par contre, le gros problème est ce que sur le site comme monsters.fr vous ne trouverez rien par le mot clé "Lazarus"...

Ca prendra un bout de temps avant que les entreprises qui ont déjà utilisé Delphi et développent depuis des années avec migrent vers Lazarus qui malgré ses progrès reste encore jeune par rapport Delphi. De plus, même s'il y a des avantages certains à Lazarus comme la portabilité, il y a aussi tout ce qu'il ne sait pas encore faire facilement, comme par exemple glisser un contrôle ActiveX sur un formulaire.

Par contre, si une entreprise doit démarrer un tout nouveau projet demain, elle pourrait se poser la question : "Est-ce que Lazarus ne permettrait pas de faire l'application?". Mais ça demande une grosse réflexion car ça implique que le projet soit clairement défini depuis le début et qu'on ne risque pas de se trouver en cours de route limité par Lazarus.

[Michel]

Lazarus s'est installé sans problème sous Ubuntu 12.04 mais j'ai un gros souci avec mysql.

TMySQL50Connection can not work with the installed MySQL client version: Expected (5.0), got (5.5.24).

voilà, tout est là.
Avant j'ai créé un lien pour retrouver libmysqlclient.so qui est renomé et en plus déplacé dans cette version de linux.
Dans /usr/lib/ lazarus s'attend à trouver libmysqlclient.so ; donc j'ai ajouté

libmysqlclient.so -> i386-linux-gnu/libmysqlclient.so.18.0.0

Un lien qui pointe vers le client réel placé dans le sous-répertoire i386-linux-gnu
et c'est ce client qu'il n'aime pas.
Je précise que sous Debian, j'arrivais à faire tourner une anciènne version de Lazarus avec Mysql mais c'était une autre époque

[Gouyon]

Pour ma part j'utilise les composants Zeos et ça marche du tonnerre.
Ma machine linux était dans les cartons depuis 6 mois j'avais oublié le mot de passe administrateur du coups j'ai tout installé.
Pour ce qui est de l'installation MySQL j'utilise la logithèque et ça pose moins de problème que de télécharger les .deb (ou rpm)

[Michel]

Pour ma part j'utilise les composants Zeos et ça marche du tonnerre.
Pour ce qui est de l'installation MySQL j'utilise la logithèque et ça pose moins de problème que de télécharger les .deb (ou rpm)

Merci pour l'info, je n'ai jamais utilisé ce composant; par contre, je n'ai aucun problème avec mysql dans d'autres applications et donc je pense que le problème viens bien de Lazarus.

[Ph. B.]

Bonjour,

Merci pour l'info, je n'ai jamais utilisé ce composant; par contre, je n'ai aucun problème avec mysql dans d'autres applications et donc je pense que le problème viens bien de Lazarus.

Vous avez presque raison , ce sont les sources FPC relatives à MySql et plus particulièrement l'unité mysqlconn.inc où se trouve la procédure de connexion qui sont en cause. Le test sur les versions se font de manière très stricte : un client ne peut se connecter qu'en utilisant une bibliothèque de même version (les 2 premiers blocs : 5.0, 5.1, etc). Voici ci le code pour FPC 2.6.0 (ligne 408):

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
procedure TConnectionName.DoInternalConnect;
var
  FullVersion, 
  ClientVerStr: string;
begin
  InitialiseMysql;
  Fullversion:=strpas(mysql_get_client_info());
  ClientVerStr := copy(FullVersion,1,3);
  If (ClientVerStr<>MySQLVersion) then // ICI !!!
    Raise EInOutError.CreateFmt(SErrVersionMisMatch,[ClassName,MySQLVersion,FullVersion]);
  inherited DoInternalConnect;
  ConnectToServer;
  SelectDatabase;
end;
// MySQLVersion = '5.0' si on utilise TMySQL50Connection
// Fullversion = '5.5.16' dans mon cas

S'il y a compatibilité ascendante au niveau de la bibliothèque, ils auraient pu écrire :

Code :

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

If (ClientVerStr >= MySQLVersion) then

Petit problème : si j'ai recompilé et déplacé les fichiers avec FPC, je n'ai pas réussi à le tester avec Lazarus : j'ai loupé quelque chose, mais je ne sais pas quoi !

[Ph. B.]

Bonjour à tous,

La version 1.02 est disponible en téléchargement ICI

Les corrections et améliorations ICI

[Gouyon]

Après quelques hésitations je suis passé à la nouvelle version. Ce qui m'a fait plaisir dans un premier temps c'est que ça c'est fait sans trop de bobo aussi bien sous windows que sous linux.
Pour ce qui est de la question à 1 million d'euros

Pensez-vous que ce Lazarus 1.0 soit enfin assez mature pour le développement professionnel ?

Je dirais oui. Mais il y a quelques manque comme un support technique digne de ce nom. Pour le reste c'est un EDI formidable avec son point fort principal qui est de pouvoir compiler, exécuter et tester le code sur différents OS. A part Java je ne connais pas d'autres langages qui le fasse. RAD Studio Xe2 le permet je crois mais je demande à voir car l'EDI ne tourne pas sur les autres OS que windows ce qui me laisse dubitatif en ce qui concerne la portabilité.

[Jipété]

Bonjour,

(...)
Pensez-vous que ce Lazarus 1.0 soit enfin assez mature pour le développement professionnel ?

Ben moi je dirais non.

J'ai installé, et pour un test rapide j'avais besoin d'installer un paquet (lazdbexport.lpk).

Alors déjà, en passant par le menu "Paquet / Installer-Désinstaller les paquets" ça n'est pas du tout intuitif, et on a peur de tout casser
Autre option, passer par "Paquet / Ouvrir un fichier paquet..." et ça roule bien jusqu'à la compilation de l'IDE, et là c'est le drame !
Cette bouze (pas d'autre mot, désolé) n'est pas foutue de trouver ses propres composants !

..\ideintf\objectinspector.pp(47,3) Fatal: Can't find unit ComponentTreeView used by ObjectInspector

Alors il faut jouer avec les chemins, en rajouter, en enlever, tout en se demandant comment une chose pareille est possible, et au final nada !

Si quelqu'un a une idée pour que je puisse reconstruire l'IDE et accessoirement installer ce paquet, il m’ôtera une grosse épine du pied...
Merci et bonne journée,

[EDIT] Alors pour recompiler l'IDE, " Exécuter / Nettoyer les fichiers de compilation... " et après ça roule. Ça ne s'invente pas... [/EDIT]

[Gouyon]

Si quelqu'un a une idée pour que je puisse reconstruire l'IDE et accessoirement installer ce paquet, il m’ôtera une grosse épine du pied...

Normalement c'est relativement simple

1. Menu Paquet ouvrir un fichier paquet
2. Charger le .lpk
3. Le compiler histoire de voire si tout va bien. Si ça ce passe mal à ce stade inutile d'aller plus loin.
4. Cliquer sur le bouton utiliser et choisir installer pour que le composant soit disponible dans la palette.
5. Lazarus se recompile car il n'intègre des composants que de manière statique.

Il est vrai que parfois ça entraine des problèmes en fonction du composant.

Pour en revenir au produit "professionnel" je ne suis pas d'accord avec vous j'ai essayer d'installer un composant sous RAD Studio Xe (Delphi) produit professionnel (surtout vu son prix) et ça n'a pas été immédiat loin s'en faut. En tenant le même raisonnement que vous j'aurais jeté Delphi à la poubelle qui est pourtant un produit professionnel.

Petite anecdote. Je développe une application base de donnée sous Lazarus car je veux pouvoir la distribuer sous Windows, Mac et Linux. Parallèlement j'en développe une autre sous delphi qui ne fonctionne que sous Windows. Quand j'ai voulu porter cette dernière sur une machine win7 j'ai eu les pires problèmes avec le connecteur ODBC de la base . Tandis qu'avec l'application développé avec Lazarus je n'ai jamais eu aucun souci de portage .
Comme quoi les outils professionnels ne sont pas synonyme de facilité d’emploi

[ovni76]

Bonjour Remi,
Je ne suis pas un spécialiste, je trouve très bien lazarus qui permet le passage assez facile d'une petite application de gestion de données sous sqlite3 développée sous linux vers windows, mais comment expliquer que les événements de TForm est un comportement différent d'un système à l'autre.
Un exemple l'événement activate.
Sous linux fedora 16, qui est mon système de base j'utilise cet événement à l'affichage de ma fiche principale pour lire le contenu d'une table qui est en situation active via le datamodule associé et sous windows j'ai droit à un beau défaut j'ai contourné le problème sous windows en ajoutant un bouton d'activation qui commande l'affichage des éléments utiles de cette fiche principale et en même temps je lis la table sans défaut.
Etrange et il y en a d'autres différences comme celle-là par exemple je peux copier une base dont les tables sont actives sous linux mais pas sous windows mais là c'est peut-être lié aux bibliothèques

[Paul TOTH]

Bonjour Remi,
Je ne suis pas un spécialiste, je trouve très bien lazarus qui permet le passage assez facile d'une petite application de gestion de données sous sqlite3 développée sous linux vers windows, mais comment expliquer que les événements de TForm est un comportement différent d'un système à l'autre.
Un exemple l'événement activate.
Sous linux fedora 16, qui est mon système de base j'utilise cet événement à l'affichage de ma fiche principale pour lire le contenu d'une table qui est en situation active via le datamodule associé et sous windows j'ai droit à un beau défaut j'ai contourné le problème sous windows en ajoutant un bouton d'activation qui commande l'affichage des éléments utiles de cette fiche principale et en même temps je lis la table sans défaut.
Etrange et il y en a d'autres différences comme celle-là par exemple je peux copier une base dont les tables sont actives sous linux mais pas sous windows mais là c'est peut-être lié aux bibliothèques

je ne connais pas le détail de la LCL mais il est certain que les évènements sont déclenchés par le système, il est donc possible que l'ordre naturel des évènements ne soit pas le même sous Linux et Windows...dommage cependant que Lazarus ne gomme pas ces différences.

Concernant la copie de la base je pense que c'est tout simplement lié à l'OS et la gestion des verrous qui n'est pas le même sous Linux et Windows.

[Invité]

je ne connais pas le détail de la LCL mais il est certain que les évènements sont déclenchés par le système, il est donc possible que l'ordre naturel des évènements ne soit pas le même sous Linux et Windows...dommage cependant que Lazarus ne gomme pas ces différences.

Bonjour, ce n'est pas si évident que cela et même souvent impossible. Je suppose que Jean fait référence à l'ouverture des Forms. Lazarus "pilote" les widget sets des OS... comme beaucoup d'autres langages... Souvent il manque des fonctions dans ces widgets. Par exemple récemment, j'ai découvert que sous gtk2, le EndEllipsis (tronquage avec points de suspension) n'était pas dispo dans les canvas. Dans les StringGrids lazarusiennes le goCellEndEllipsis et le DT_END_Ellipsis sont bien implantés mais ne commandent rien sous gtk2 puisque le widget concerné ne possède pas cette capacité. Enfin semble-t-il.

Pour l'ouverture des Forms, si sous Windows le Widget gère l'évènement A puis l'évènement B alors que sous Nux c'est d'abord B puis A, que peut y faire Lazarus ? Inverser le nom de ses propres fonctions ? Pour le déclenchement à l'ouverture des Forms, il y l'override possible de la méthode Update qui est relativement indépendante et permet certaines corrections... On ne peut pas non plus demander à tous les OS de se ressembler. Il faut donc faire avec.

Ceci dit, cela m'amène à une conclusion que je n'arrivais pas à formuler faute de disposer du matériel et des logiciels nécessaires. Mais maintenant, après avoir testé, ma "suspicion" et mon aversion "naturelle" pour la cross-compilation en sortent renforcées. Face à ce genre de problématique (l'utilisation des Widget sets de l'OS), la cross-compilation est une perte de temps infinie dès qu'on utilise un environnement graphique. Et je pense que Lazarus est LA solution actuelle en Pascal parce qu'avec son EDI sous Mac, on peut tester et corriger immédiatement... C'est un énorme plus, un confort inestimable... et quoi qu'on en dise, Lazarus 1.0/FPC 2.6.x est solide et fonctionnel, en 32 et 64 bits, sous Win, Nux et Mac...

Cordialement. Gilles

[Gouyon]

Et je pense que Lazarus est LA solution actuelle en Pascal parce qu'avec son EDI sous Mac, on peut tester et corriger immédiatement... C'est un énorme plus, un confort inestimable... et quoi qu'on en dise, Lazarus est solide et fonctionnel, en 32 et 64 bits, sous Win, Nux et Mac...

J'approuve à 100%

Je ne suis pas un spécialiste, je trouve très bien lazarus qui permet le passage assez facile d'une petite application de gestion de données sous sqlite3 développée sous linux vers windows, mais comment expliquer que les événements de TForm est un comportement différent d'un système à l'autre.

Je ne sais pas répondre à ça et j'ai expérimenté moi aussi quelques mauvaises surprise de ce genre. L’intérêt de Lazarus c'est qu'il est facile de corriger ces problèmes puisqu'on peut modifier et compiler le projet sur l'OS en question. Contrairement à un EDI qui disposerait de plusieurs compilateurs mais qui ne permettrait que des modification sur un OS donné

[Paul TOTH]

...
Pour l'ouverture des Forms, si sous Windows le Widget gère l'évènement A puis l'évènement B alors que sous Nux c'est d'abord B puis A, que peut y faire Lazarus ? Inverser le nom de ses propres fonctions ? Pour le déclenchement à l'ouverture des Forms, il y l'override possible de la méthode Update qui est relativement indépendante et permet certaines corrections... On ne peut pas non plus demander à tous les OS de se ressembler. Il faut donc faire avec.
...

j'ai toujours pensé que la VCL (celle de Delphi), bien que fortement liée à Windows gagnerait a lâcher quelques spécificités de Windows pour devenir un standard de développement. C'est à dire que peu importe si l'OS gère ou pas un évènement, la VCL (ou la LCL) se doit de proposer une série d'évènements clairement identifiés sans rapport avec l'OS sous jasent. C'est ni plus ni moins ce que nous propose HTML

J'ai d'ailleurs commencé à faire des CrossControls sous Delphi XE2 qui fonctionnent à l'identique sous Windows et OSX tout en utilisant le control natif de l'OS (on retrouve tout de même un bon nombre de choses en commun). J'ai découvert à cet occasion que OSX n'a pas d'état "Idle" car il n'y a pas explicitement de message ou d'absence de message (= idle)...mais on peut recréer ce principe en postant un message qui se déclenche "NSPostWhenIdle", c'est à dire en gros quand il n'y en a plus J'ai cependant encore un bug puisque ce message n'est pas traité entre un MouseDown et un MouseUp sur un bouton... comme quoi reproduire à l'identique n'est pas simple, mais je pense que c'est faisable

Un exemple notable aussi c'est TPageControl, en fait ce composant n'existe pas sous Windows ! c'est juste un TTabControl dans lequel on vient placer des TTabSheet (TWinControl) et Delphi se charge des les afficher ou de les masquer en fonction de l'onglet actif. Sous OSX il existe par contre NSTabView et ses NSTabViewItem qui fonctionne directement comme un TPageControl...et bien cette différence peut très bien être gommée dans la VCL

[Invité]

Bonjour Paul,

Hum... Je ne suis vraiment pas un spécialiste VCL D'autant que souvent les codes que j'ai étudiés font appel aux API. Je me refuse à utiliser ShellApi au maximum avec Lazarus.

Lazarus propose une autre solution pour les composants graphiques indépendemment des widgets des OS. Elle n'est pas aboutie et je ne sais pas si elle est viable, ni même nécessaire : FpGUI.

Mais je le répète. La situation de Jean -si j'ai bien compris- me semble être celle du portage d'un projet Windows vers Linux. Mais dans ce cas (celui d'un portage de Windows vers Linux), le développement Windows est de fait la référence et la plateforme méthodologique de départ. C'est la différence de méthode qu'il y a entre un "cross-compilateur" (un cross-compileur ?) Delphien et un utilisateur de Lazarus. Je suis autant de temps sur Nux que sur Windows et bientôt -faut rattraper le temps- sous Mac. Je n'initie pas spécialement mes projets sous Win, plutôt en général d'ailleurs sous Nux...

Donc je prends les OS tels qu'ils sont. Je me moque de savoir si l'évènement A et avant B sous Nux et inversement sous Win. Je teste mes projets avec mon IDE dans chaque environnement. S'il y a un problème sous Nux, j'ouvre mon IDE sous Nux : il est en général facilement identifiable puisque je dispose de toutes les ressources associées à l'IDE dans l'OS où il apparaît et s'il le faut, je différencie et/ou permute le code avec un {$IFDEF linux ou windows} et c'est fini...

L'exemple que vous prenez est typique. Vous utilisez cette méthode parce que vous êtes obligé de cross-compiler. Sinon cela devient invivable, je m'en suis rendu compte car je n'ai pas votre savoir-faire sur Delphi. D'un autre côté, s'il faut réaliser le travail que vous me détaillez (les CrossControls) avant de commencer à programmer, bien qu'amoureux du Pascal, je risque de m'en détacher. Voila pourquoi actuellement ma préférence va à Lazarus...

Et "philosophiquement' je me demande pourquoi vous voulez faire "exactement marcher" un Linux comme un Windows ou un Mac. Je crois que la bonne approche, c'est le tour de force équilibré qu'est en train de réussir Lazarus... Beaucoup de codes communs, tout en respectant la "liberté" et la spécificité de chaque OS, et en les considérant tous comme égaux et indispensables. Je l'ai écrit de nombreuses fois : c'est un challenge ambitieux et une approche intellectuellement très satisfaisante, brillante même. La difficulté, c'est le respect des points d'équilibre et donc la cohésion des approches et méthodes de développements. Là des fois, il y a quelques errances... dont nous subissons les conséquences. Mais en ce moment, "on" se porte plutôt bien. Alors il est vrai que quand un "habitué à Delphi" teste un Lazarus, il ne voit que par le prisme de Windows et on peut reconnaître que Lazarus est moins spécialisé que Delphi pour cet OS. Mais, inversement, quand "j'approche" Delphi (IDE purement Win 32) pour un développement Mac OS64... alors là, le Lazarusien est aussi déçu que son Collègue habitué à Delphi... et je ne parle pas du Linuxien.

Je suis donc de l'avis de Rémi : pour un programmeur qui développe pour les 3 environnements sans en privilégier aucun, il y a Java et Lazarus (peut-être C++/QT)... et pour avoir testé les 2 premiers, j'estime qu'avec le second -tel qu'il est actuellement- on peut faire aussi bien dans de nombreux cas -on va rester modeste- qu'avec le premier, la référence en la matière. C'est une chance, je trouve, quand on est un Pascalien "natif".

Il est vrai -je le constate comme les différences des OS- que Lazarus et Delphi divergent de plus en plus... et j'en reviens à votre constat premier : qu'il eût été souhaitable d'écarter un peu VCL de Windows... j'en suis certain. Mais tel ne fut pas le cas et tel ne le sera-t-elle probablement jamais, car FMX et VCL, c'est... sans rapport... et Win32 ne semble plus être l'avenir de Windows.

Cordialement. Gilles

[ovni76]

Salut Gilles,
Petite précision, mon environnement de base est Linux Fedora 16 actuellement et je recompile pour de la famille ou des amis sous windows avec les adaptations de chemins etc..et là j'ai trouvé des différences de comportement.
A+ Jean