Discussion :

[djibril]

salut à tous,

Pouvez vous donnez vos avis et retour lorsque vous avis conçu une application Perl/Tk distribué à un utilisateur tierce ou un client.

Supposons que vous souhaitiez créer un logiciel (payant ou non), qui aura pour but (je ne sais pas trop pour l'instant) d'effectuer certaines tâches (comme gestions de site web, analyses de fichiers de données, administrations réseaux, analyses de données biologiques, finance, ou autres).
Est il judicieux de le faire complètement en Perl?
Perl permet de faire tout (tous les traitements) et même l'interface graphique via TK. Mais d'après vous, est ce suffisant?
Certaines personnes disent que les interfaces Perl ne sont pas jolies par rapport à java par exemple, mais est ce vraiment uns raison suffisante?

Question de portabilité :
Cela pose t- il un souci du faite que le client devrait installer Perl, ainsi que les modules nécessaires?
Y a t il moyen d'automatiser l'installation de perl et les modules nécessaire au logiciel?
Par rapport à java où il est certe simple de creer des fichiers jar, en quoi java ou d'autres langages seraient ils plus utilisables que perl vu qu'il faudra toujours faire des installations préalable (en dehors de la maintabilité du code)?

Y aurait il des problemes de gestions de mémoires? est ce que cela ne dépends pas tout simplement du code bien écrit et de la machine?

En ce qui concerne la gestion des processus ou parallelisme des taches, il est souvent dit que java permet cela, mais pas perl. Mais cela dépend plus de la becanne non? car je crois qu'il existe des modules perl le faisant!!!

Question sécurité et contrainte:
Comment ensuite sécuriser son code? Car la création des exe en perl reste toujours plus ou moins evidente en fonction des modules chargées. Ce n'est pas toujours tres efficaces. en JAVa, on peut aussi également passer des .class au .java.

Avez vous rencontrés des problèmes lié à activePerl sur les machines clients?

Avez vous rencontrés des problèmes liés aux packaging de vos codes (PAR)?

Bref, en gros faut il être fou et dingue ou bien est ce logique si on le souhaite de se lancer dans la conception d'un logiciel (mini ou pas) écrit complètement en perl?
Ou bien est ce plus raisonnable de cumuler plusieurs langage comme perl et java ou autre?

Niveau interface graphique, peut on s'arrêter à TK ou gtk, ou faut il le faire en swing par exemple?

voilà tant de réflexions à votre disposition, j'attends vos raisonnement

Merci

[Jedai]

Trop de questions à la fois !!!

Déjà pour répondre à ta question sur les GUI : Tk n'est pas si laid, on peut même faire des choses assez impressionantes avec des modules comme Tk::Zinc, mais c'est sûr que ce n'est tout de même pas le plus beau GUI toolkit du monde... Néanmoins Gtk2 ou WxWidgets sont utilisables en Perl et sont nettement plus puissant, tout à fait au niveau de Swing (du Swing actuel parce que Swing a eu son lot de problème, fut un temps je n'aurais pas placé Swing au-dessus de Tk...).

Question portabilité, il est fortement recommandé si on veut avoir un marché sous Windows de créer des binaires, ou du moins des paquetages .par . Ca peut même être une bonne idée sous Unix pour s'éviter des questions de compatibilités et de versions des modules. Il est tout à fait envisageable par contre de laisser son source disponible, ainsi que de le distribuer sur le CPAN en parallèle pour ceux qui peuvent l'utiliser. Avec un binaire pour Windows, un .par et les sources, on s'assure une très bonne portabilité.

Perl est gourmand en mémoire, mais si vous l'utilisez proprement il n'y a pas trop de raisons pour que ce soit un problème, surtout vu la mémoire disponible sur les ordinateurs actuels . Si vous avez de grosses quantités de données élémentaires à manipuler, il peut être intéressant d'utiliser PDL, qui fournit d'excellentes facilités pour manipuler des matrices, faire du calcul scientifique, ... et offre des tableaux légers (pour les types numériques).

Pour ce qui est des threads (processus légers), ils sont maintenant mieux supportés par Perl, mais il reste préférable de les éviter, ne serait-ce que pour s'assurer la compatibilité avec les versions plus vieilles de Perl (encore très présentes sur le marché des serveurs et des stations de travail). L'utilisation des fork() reste une alternative privilégiée, mais selon le problème la meilleure solution pourrait bien être d'utiliser POE, un framework pour l'asynchrone très bien fait et disposant déjà d'un grand nombre de composants. A terme, avec l'avènement de machines massivement multicore, la question se reposera, mais à vrai dire pour l'instant il y a bien peu d'applications qui profitent réellement de ce surcroit de puissance (et si vous écrivez une telle application en Perl, vous avez un problème de choix du langage.... )

Question sécurité du code, franchement seule une bonne licence peut vous aider de ce côté là, avec peut-être un petit obfuscateur pour rendre douloureux tout vol de code. Côté sécurité du logiciel, il est inutile de se mettre martel en tête, le seul schéma qui assure une véritable sécurité est celui où une partie du logiciel n'est pas sur la machine utilisateur mais plutôt sur Internet, et ceci quel que soit le langage, ensuite, tout est question d'effort requis du côté du cracker.

--
Jedaï

[mobscene]

OUlala que de questions :

Question de portabilité :
Avec perl il n'y as pas trop de soucie de ce coté par contre sous bien des distrib linux perl est installé par défaut sous windows ce n'est pas le cas le meilleur moyen de faire cela avec windows est d'installer perl pour windows sur une machine puis d'y installer tout les modules néçéssaire au fonctionnement de l'appli du client et ensuite de créer un installeur , ne biensur pas oublier de refaire l' association des fichiers et l'enregistrement de perl.exe dans le path de windows, et hop sa fonctionnera je le sais car je le faisait a une époque



Question sécurité et contrainte:
Heu faut dire qu'en perl ce n'est pas vraiment possible les paquetages .par sa foire une fois sur deux.

[djibril]

merci pour vos réponses. Mais bon c'est toujours bien de se poser pleins de questions car on est tellement à la mode java, appli java j2ee qu'on se demande si perl a un quelconque intéret. Surtout quand l'appli ou logiciel doit etre envoyé chez un client par exmple.
Sinon mobscene, tu connais des logiciels ecris en perl TK.
Tu faisais quoi toi chez tes clients avec perl (juste par curiosité)?

[mobscene]

Mouarf java on nous le sort a toute les sauces tout les 4 matins il y a un nouveaux truc j2se, j2tutu, j2bobo, j2caca enfin bref moi je n'y comprend plus rien.

Je fait plutôt de la programmation en C# depuis quelques mois vue que les softs que je développe ( pour un projet perso ), sont tous multithread et que perl pèche sévèrement de ce coté.Néanmoins certains progs reste en perl.

Pour ce qui est de mon histoire d'intalleur je faisait cela pour simplifier le déploiement de perl sur plusieurs bécanes.

[Arioch]

Je vais juste donner mon avis perso car j'ai depuis quelques années dans l'idée de concevoir un logiciel à base de Perl + Tk.

Le but et l'utilité de ce programme n'ont rien à faire ici, donc je n'en parlerai pas. Je dirai juste que l'appli n'exploiterait rien qui nécessite des déviations pour certains systèmes (comme si j'utilisais certains packages spécifiques Windows ou Unix, ce qui n'est pas le cas).

Question portabilité donc, mon code serait exploitable sur les OS les plus usités.

La question se pose principalement pour Tk, ainsi que Perl. Obliger les personnes à qui je destinerais le programme d'installer Perl sur leur machine ? Hors de question ! La plupart sont habitués à double-cliquer sur une icone, le bazar s'ouvre à l'écran et basta. Hors de question de leur imposer le téléchargement de Perl, son installation et tout ça, "juste" pour un script qui l'exploite.

Et si je prend exemple sur Perl2Exe, hormis la version payante que je ne connais pas, la version shareware a ses limites. Certains codes sont mal reconnus lors de la création du soit-disant binaire, j'en ai déjà fait la triste expérience justement avec Tk. De plus, comment proposer la version binaire pour MacOS lorsqu'on n'a personne autour de soi qui utilise cet OS pourtant sympathique ?

Eh bien, le fait de ne pas pouvoir exploiter pleinement Perl2Exe (par exemple) ni de ne pas avoir envie de contraindre les futurs utilisateurs d'installer Perl = le programme reste là où il est. Nulle part.

A côté, Perl me sert quotidiennement. A la maison pour le jeu que je gère sous Linux, au travail sur AIX ou sur nos postes qui sont sous Windows 2000 ou XP. Mais en dehors, ben

[Jedai]

Arioch, il existe un certain nombre de solution, même si tu n'obliges pas l'utilisateur à installer Perl (et pourquoi pas ! Après tout il installe bien la JVM), tu peux lui faire un installeur qui contient juste perl.exe et le minimum nécessaire pour faire tourner ton programme. C'est lourd ok, mais pas tellement plus que bien d'autres programmes que l'utilisateur Lambda installe quotidiennement, il n'a pas besoin de savoir que tu lui as installé Perl (une petite partie).

--
Jedaï

[djibril]

Je ne sais pas si c'est judicieux, moi je me suis fais un test basique.
1) Creation d'un script basique qui test la présence de perl ou non sur la machine cliente et je le transforme en exe via par.
2) Dans l'installateur, j'intègre le msi d'activeperl.

Du coup, à l'install de l'outil, l'exe est lancé et test la presence de perl. Si ce dernier n'est pas present, une commande system lance le msi d'active perl. Le client n'a qu'à faire suivant suivant pour installer PERL. Et hop c ok.

J'ai également crée un autre script perl transformé aussi en exe qui test la presence des modules dont j'ai besoin pour l'appli, et si ce dernier n'est pas présent, des commandes systeme lance les commandes ppm adequate et rajoute même au préalable les repository si necessaire.
Cet exe est lancé en 2eme position pendant l'install de l'application.

Du coup, avant que l'appli soit lancée, perl et ses modules seront présent sur la machine.

Le client n'a juste qu'à suivre les instructions et faire suivant puis voir ce qui se déroule.
On peut même se faire des fichiers log et en cas de bug ou problème, demander au client de nous envoyer le fichier.

Qu'en pensez vous?
Sinon on peut toujours améliorer en testant que perl est bien supérieur à une une version donnée (si ce dernier est présent). voir si c'est un pc x64 ou x86 pour installer perl adéquat, voir si le client a internet ou non car s'il ne l'a pas, prévoir les modules packager et précompilé pour lancer les ppm en local.
Je pense que tout cela est faisable facilement.
J'attends de vos conseils et propositions

[Woufeil]

Salut,

Ce que tu fais est sympa, le seul problème est que tu vas installer des dizaines et des dizaines de modules totalement inutiles pour l'utilisateur, le msi de Perl étant très complet... Le problème ne vient pas tant de Perl que du nombre de volume. Après tout, un programme peut n'utiliser que quelques modules et avoir une conception OO (et donc demander perl5 et la fonction bless). Je crois qu'il existe des modules qui permettent de créer un exécutable qui n'installera que ce qui est strictement nécessaire pour le fonctionnement du programme.
Maintenant, cette approche à aussi ses faiblesses : si tu veux installer 3 logiciels de cette manière, tu auras 3 perl différents, tandis que ta méthode présente l'avantage de n'avoir qu'à charger les modules nécessaires si l'on possède déjà un perl...

[Jedai]

Je pense que la méthode est bonne. Il faut essayer de présenter ça comme la JVM : c'est un investissement pour le futur !
Par contre il vaut mieux télécharger le msi d'ActivePerl que de le mettre direct dans l'installateur, sinon ça va sacrément faire grossir ton installateur...

--
Jedaï

[djibril]

Je viens de faire des tests et ça marche plutôt bien.
Par contre, c'est vrai que le fait de mettre les msi d'activeperl (x86 et x64), cela fait légèrement grossir l'exe de l'installateur à environ 35 Mo.
Mais bon, c'est pas trop dérangeant.
De plus, je trouve que c'est mieux ainsi car on a une meilleure idée de la version de perl qui sera installé sur le PC client, car je viens de faire une remarque.
Il peut y avoir un bug si par exemple j'execute un exe crée par PAR de perl 5.8 820 built sur une machine ayant perl 5.8 built 822.
Je ne sais pas pourquoi, mais ça génére des messages d'erreurs et l'exe ne fonctionne plus très bien.
Je trouve que le module PAR n'est pas encore très au point, mais bon.

[astrotouf]

c'est triste à constater mais avec java le déploiement est plus simple

[Jedai]

c'est triste à constater mais avec java le déploiement est plus simple

Non, c'est juste que la JVM est plus répandue...

--
Jedaï

[rbillerey]

Bonjour à tous,

Pour packager une appli commerciale perl j'ai déjà utilisé :

PAR : http://par.perl.org/wiki/Main_Page qui scanne les dépendances d'un script et crée un exécutable contenant un zip des modules utilisés et de l'interpréteur

Cava : http://www.cava.co.uk/ qui scanne également les dépendances, sans les zipper ( c'est un choix de design ). L'interface graphique est soignée ( en wxperl ) et simple à utiliser. Le produit est gratuit mais pas open source.

Pour une interface graphique utilisant les composants natifs ( Windows, Mac, Linux ) de la plateforme, comme SWT de java, wxPerl : http://wxperl.sourceforge.net est un binding du framework wxwidgets : www.wxwidgets.org. C'est stable, rapide et bien plus joli que Tk ! Il existe des tuto dans perl.com : http://www.perl.com/pub/a/2001/09/12/wxtutorial1.html

On peut créer et distribuer des appli commerciales 100% perl : je l'ai fait pour un CRM spécialisé dans la gestion de l'actionnariat, utilisé par des sociétés côtées en bourse.

[djibril]

Post un mis à jour

Merci

[jaljal]

Bonjour,

qu'en ai t-il pour la conception d'application web avec perl, dans quel type de site web, perl est t-il recommandé ?

j'ai déjà utilisé les technologies java/j2EE et php dans diverses projets web, pourquoi pas réalisé un projet web personnel avec perl/CGI

Merci

[philouelgeek]

Perso au boulot j'utilise Cava Packager, qui est un petit utilitaire gratuit pour le déploiement de scripts perl, et ça marche nickel, pas besoin d'installer Activeperl et ses modules sur les machines des utilisateurs

[djibril]

Perso au boulot j'utilise Cava Packager, qui est un petit utilitaire gratuit pour le déploiement de scripts perl, et ça marche nickel, pas besoin d'installer Activeperl et ses modules sur les machines des utilisateurs

Je ne connaissais pas, merci pour l'information : Cava Packager

[philouelgeek]

De rien

[phoenix420]

Bonjour.

J'ai récemment posté cette discussion sur le forum http://www.developpez.net/forums/d11...xe-standalone/

J'aimerais quelques conseils pour générer mon exécutable qui contiendrait les modules Gtk2 et GD::Graph. Car pour le moment tous mes essais se sont soldés par des échecs .

En vous remerciant !