Discussion :

[Invité]

Bonjour,

Je dispose d'un carré de 4 x 4 PCs [Lin-Win et OSX 64 bits] et de mon poste principal tous sur le même réseau Ethernet base 100. Les 16 postes du carré doivent afficher chacun leur tour une lettre de l'alphabet aléatoire pendant un temps aléatoire. L'ordre des postes est également aléatoire. La succession des affichages doit se faire avec le moins de latence possible.

J'ai pensé régler le problème de la manière suivante. Je synchronise les 17 PCs sur une horloge sur Internet. A l'aide du PC principal, je remplis une table pgSQL de manière "aléatoire" : IP du poste, ordre (N° du poste dans la séquence), durée d'affichage, une heure de départ à partir du premier poste qui sert de référence pour le calcul des autres (ordre+durée). Les 16 PCs lisent la table, stockent l'information qui les concerne en mémoire, attendent leur heure puis déclenchent l'affichage au moment désigné pendant le temps précisé. L'avantage du système et qu'une fois le chargement mémorisé par chacun des postes, compte-tenu de la synchro, il ne devrait pas y avoir de latence dans la succession des affichages. Enfin j'espère .

Je préfèrerais me dispenser de la table SQL et que le premier PC choisisse aléatoirement un second (qui lui-même définira la lettre et la durée d'affichage aléatoirement) et choisira un 3ème PC... Je redoute par contre une petite latente pendant "l'envoi" de chaque PC. Cela peut être acceptable si l'effet de rémanence des LCD le compense.

Une autre idée pour procéder en Win64 et Lin64 et OS X-64 en Lazarus ?

Merci. Gilles

[Paul TOTH]

il me semble plus simple d'interconnecter tous les PC et de gérer ça en réseau

au lancement du programme :
- mise à l'écoute d'un port UDP
- démarrage d'un serveur TCP
- lancement d'un message UDP en broadcast pour signaler sa présence

quand un PC reçoit le broadcast UDP:
- si c'est un PC qu'il ne connait, il se connecte à celui-ci.

exemple de déroulement
- lancement du programme sur PC1
- lancement du programme sur PC2
* PC1 reçoit le broadcast et se connecte à PC2
- lancement du programme sur PC3
* PC1 et 2 reçoivent le broadcast et se connectent à PC3

au final tous les PC sont interconnectés soit en client soit en serveur avec tous les autres PC

si on considère au départ que PC1 a la main et affiche une lettre, au bout d'un temps aléatoire il choisit un des autres PC et lui donne la main.

dans cette configuration, il n'est pas nécessaire d'avoir un serveur SQL

NB: si les adresses IP des 16 postes sont connues, il est plus simple de les mettre en relation, il suffit de tenter de se connecter sur chaque poste en évitant d'établir une double connexion (PC1 vers PC2 et PC2 vers PC1)

[Invité]

Bonjour,

Merci Paul... mais cela se présente mal : http://wiki.freepascal.org/Networking_libraries.
J'ai testé Synapse sur OS X 64... et cela ne fonctionne pas. Je ne connais pas la cause : il n'y a pas besoin d'installer Synapse dans l'IDE comme on pratique avec Indy. C'est même peu recommandé. Je déclare simplement le répertoire Synapse dans les sources du projet. J'ai déjà eu un mal fou à installer Lazarus sur un poste OS X 64 (et Cocoa) . Je ne sais pas si Lazarus est réellement compatible avec cet OS en 64. (i.e. il est installable mais qu'est-ce qu'on peut faire avec exactement ?) Pour mon utilisation habituelle, il est totalement à la ramasse si je le compare aux possibilités offertes en Win et Nux 64.

Il n'y a pas le feu... J'ai presque 2 mois pour réaliser cette petite animation. Je vois 3 solutions

1. trouver une bib "UDP" compatible OS X 64 en Lazarus. Je préférerais mais cela se présente fort mal.
2. utiliser un XE pour la partie Mac. Je ne dis pas non... si c'est jouable avec la cross-compilation (i.e. gestion de l'UDP). Quelqu'un peut-il me le confirmer ?
3. utiliser Qt pour les 3. C'est jouable aussi.

Sinon je retiens votre approche d'autant que les adresses IP des stations sont fixes (utilisation d'un VNC). Le concept est nettement plus intéressant car j'ai très peu pratiqué ce domaine.
Je vous tiens au courant.
Cordialement. Gilles

[Invité]

Bonjour,

Un petit CR :

• J'ai commencé par développer mon projet en Lazarus Win et Nux 64 que je maîtrise à priori le mieux. J'ai essayé les 2 méthodes (avec synapse). Elles sont toutes 2 opérationnelles pendant un laps de temps de 3 ou 4 minutes. J'avais oublié de préciser cette contrainte de durée de fonctionnement. Je n'ai pas porté le projet en OS X 64 : Lazarus ne le permet pas ou du moins, pas dans un temps raisonnable.
  
• Je n'ai pas non plus essayé en XE. Ma version de démonstration n'est plus valable.
  
• J'ai réalisé le projet sous Qt dans les 3 environnements avec plus de difficulté il est vrai... mais avec des effets graphiques sur les lettres. Effets que j'avais également obtenus d'une certaine façon avec Lazarus et les lzRichEdit. Finalement, je retiens la réalisation Qt.

La conclusion est toujours la même : quand je compare l'approche Lazarus à celle de Qt, Lazarus est exceptionnel de

• simplicité, notamment quand on compare les déploiements nécessaires à l"installation des exécutables produits, de lisibilité du code, de modélisation des concepts, de factorisation de codes... Franchement le Pascal Object est une merveille.
• d'efficacité, par exemple pour accéder (seulement accéder) aux BDD ! Le principe des composants de Delphi/Lazarus est d'une efficacité redoutable. Les ancrages Lazarus -et pas ceux de Delphi VCL qui sont moins bons et encore moins "ceux" de FMX- n'ont pas d'égal à mon sens, même si on s'en tire bien avec Qt : c'est du niveau de Delphi VCL. La vitesse des exécutables n'a pas d'égal non plus. A ce niveau, C++ est probablement inégalable -enfin c'est ce qu'on entend- mais sans Qt qui ralentit l'ensemble mais pas de manière perceptible pour l'utilisateur final.

Mais -et cela "ruine" ma programmation avec Lazarus-, malheureusement, les composants graphiques de Lazarus sont obsolètes, désuets, incomplets et en plus inexistants sous Cocoa. Comment expliquer ces insuffisances qui handicapent à ce point le développement GUI avec Lazarus ?

• Sont-elles intrinsèquement liées à la conception même de Lazarus et à une incapacité à piloter correctement les widgets natifs des OS ? Si tel est le cas, cet IDE n'a aucun avenir à mon sens.
• Sont-elles non pas liées à l'incapacité mais à la grande difficulté (nombreuses contorsions chronophages) à piloter correctement les widgets natifs des OS ? Si cette hypothèse est correcte, l'avenir de cet IDE est lié au recrutement de programmeurs capables de faire ce travail et de maintenir des "visual components" performants sur les principaux OS et les plateformes actuelles (i.e. 64 bits). Or le Pascal n'a pas le vent en poupe... Ou alors une approche à la fpGUI -si je dis comme FMX tous les Delphiens vont protester, cependant la démarche est identique- mais il (fpGUI) s'intègre très mal dans Lazarus et pour cause.
• Sont-elles une conséquence de la faiblesse de la communauté Lazarus -et donc pas du produit- et d'un manque d'intérêt et de besoins pour ces composants ? Ce manque de besoins est peu probable quand on voit la foison de composants Delphi, et la "modernité" de ceux de Qt. Reste quand même que le nombre de programmeurs dans l'équipe de développement de Lazarus est limité et qu'ils sont très occupés. Et peu d'espoir du côté de société tierces.

Objectivement, compte tenu des réalités et des tendances, cela se présente quand même "moyennement".

J'ai également essayé pendant cette période (depuis le premier message de cette discussion) d'utiliser fpGui. Très difficile en Win... et je ne vais pas bien loin. Sans perdre aussi vite pied qu'en FMX, j'ai souvent dû mal à saisir l'approche. Je n'y suis pas arrivé en Nux. Je n'ai pas essayé en Mac. A mon avis, si on veut persévérer dans ce type d'approche, il faut attendre l'évolution suivante de XE (avec Nux)... si elle finit par arriver... A la fin, on devient dubitatif. En espérant qu'une documentation à la hauteur l'accompagne. Le tuto de Serge sur la gestion des styles est un exemple de ce qui devrait être .

Avec Qt, je réalise en ce moment un traitement de texte qui produit un document HTML avec des paragraphes en accordéons (i.e. repliables) ce qui nécessite l'utilisation (l'incorporation) de code javascript dans le document : quelle richesse graphique et fonctionnelle, ce Qt... et quelle réelle portabilité !... et plus l'IDE est très bien fait. J'ai installé, je crois, tout ce qui se fait en composants Lazarus permettant d'afficher du HTML dans un composant graphique... Impossible d'obtenir le rendu... Evidemment on peut ouvrir un navigateur à côté... comme lire les champ "memo" d'une table dans un TMemo à côté d'une dbGrid... C'est d'une ergonomie...euh... ancienne.

Donc résolu... mais pas comme je l'espérais.

A bientôt. Cordialement. Gilles