Discussion :

[naute]

Bonjour jurassic pork, bonjour Jérôme .

Tout d'abord, merci infiniment pour l'aide que vous m'apportez. Si je pouvais mettre plein de , je le ferais à coup sûr.

Je vais d'abord répondre à jurassic porc, après quoi je testerai le composant de Jérôme (pas tout faire à la fois pour pas me mélanger les crayons ).

Code python :

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

1
2
3
 
from functools import partial
print = partial(print, flush=True)

Cette astuce m'intéresse bien : il suffit donc d'incorporer ces deux lignes au code juste avant de l'exécuter, sans toucher au fichier. C'est transparent.

A noter que j'ai changé le dernier print par rapport au script initial car l'échappement n'était pas bon : ' suivi de ' ne fonctionne pas .

Bizarre . Chez moi, ça fonctionne (Debian 9, Python 3.5).

J'ai donc installé Python4Lazarus puis j'ai lancé ton projet avec les paramètres suivants :

Code pascal :

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

1
2
3
4
 
PyhtonEngine1.DllName := 'libpython3.5m.so';
PyhtonEngine1.DllPath := '/usr/lib/python3.5/config-3.5m-x86_64-linux-gnu';
FProcessEx.Executable := 'python3';

et tout fonctionne parfaitement dans mon environnement, à savoir :

• Debian stretch 9.13 ;
• Lazarus 2.0.10 ;
• FPC 3.2 ;
• Python 3.5.

Par contre, je ne comprends pas exactement le sens de :

La partie TProcessEx ne gère pas pour l'instant le scrolling automatique (visualisation du bas du texte affiché).

Le scrolling du TMemo fonctionne sans problème.

Amicalement,
Hervé

[Roland Chastain]

Salut à tous, j'ai passé une bonne partie de mon après-midi et de ma soirée à confectionner un nouveau composant basé sur TProcessEx, de la nouvelle unité "processutil" disponible dans FPCUpDeluxe et de diverses lecture sur le sujet sur le web.

Bonjour Jérôme (et les autres) ! Ça m'a l'air très intéressant cette affaire.

Premier essai de compilation chez moi (Linux).

Compilation du projet - Mode : Debug - Cible : NewProcessEx : Code de sortie 1 - Erreurs : 4
BZProcessEx.pas(487,9) Error: Control flow statements are not allowed in a finally block
BZProcessEx.pas(682,3) Error: Identifier not found "FProcessStringType"
BZProcessEx.pas(682,25) Error: Identifier not found "pstWinCodePage"
BZProcessEx.pas(749,42) Error: Identifier not found "poRunIdle"

J'attends la version corrigée avec impatience.

[jurassic pork]

hello Hervé,

Par contre, je ne comprends pas exactement le sens de :

Le scrolling du TMemo fonctionne sans problème
Hervé

Rajoute plein de print à la fin de ton script (où fait un compte à rebours à 20) tu vas comprendre ce que je veux dire. Quand le nombre de lignes écrites dépasse la hauteur du Tmemo, on ne vois pas les dernières lignes mais toujours les premières lignes en go tprocessex. On est obligé d'utiliser la barre de scroll pour voir les dernières lignes.
Ami calmant, J.P

[naute]

Oui, oui, pigé : comme dans la console.

[naute]

@Jérôme .

Comme Roland, j'ai des misères à la compilation, mais un petit peu moins. Je n'ai que :

• BZProcessEx.pas(487,9) Error: Control flow statements are not allowed in a finally block
• BZProcessEx.pas(682,3) Error: Identifier not found "FProcessStringType"
• BZProcessEx.pas(682,25) Error: Identifier not found "pstWinCodePage"

ce que je trouve bizarre en soi .

Et tout comme lui, j'ai hâte d'avoir la version corrigée. Mais surtout, prends ton temps : il n'y a aucune urgence .

En tout cas, merci .

Amicalement,
Hervé

[jurassic pork]

même souci chez moi avec BZProcessEx. Peut être un souci de version de fpc (moi je suis en 3.0.4).

Ami calmant, J.P

EDIT : Oops ! Naute est en 3.2

[BeanzMaster]

Salut, merci de vos retours.

Après un petit passage dans le monde de Linux.

Je reviens avec une version corrigée.

Ce passage de Windows à Linux, m'a rappelé quelques notions oubliées du langage pascal, notamment sur l'utilisation des blocs try..except..finallyMa première surprise, fut de voir ce message :

Error: Control flow statements are not allowed in a finally block

De quoi s'agit-il ? simplement que des méthodes tel que EXIT sont prohibées à l'intérieur de bloc try..except..finally. Ce qui est surprenant, c'est que sous Windows ce message n’apparaît pas, alors qu'il le devrait. Donc petite note à garder sous le coude.

En deux, j'avais complètement oublié (2^éme petite note à conserver) c'est que sous Linux lorsque l'on utilise un thread, pour plus de sécurité, il faut le créer en mode "suspended" (ne me demandez pas pourquoi)

Après quelques modifications, ajout de {$IFDEF WINDOWS} oubliés et une ou deux erreurs corrigées. Ca fonctionne



Le seul truc, c'est que lorsque l'on compile dans l'EDI. Ca fonctionne deux fois sur trois. Et quand cela plante, ça renvois des erreurs aléatoires, un coup c'est SIGSEGV, provenant de GTK, un coup SIGABRT. (notamment avec l'utilisation de "ShowMessage" dans la demo , du moins chez moi sous Manjaro)

Bref je pense que c'est GDB qui ne suit pas et qui est complètement perdu entre le thread de TProcess et celui de TBZProcessEx.

La méthode à surveiller, si jamais, c'est TBZProcessExThread.Execute et les méthodes externes qui interagissent dedans. Il reste peut-être (surement une ou deux petites erreurs de conception). Il faut également surveiller les méthodes utilisant les sections critiques avec le couple Lock et UnLock.


Bref j'attend vos retours de tests sous Linux (dans L'EDI et en dehors, en mode Release et Debug, avec impatience.


Note : J'utilise Lazarus 2.0.10 avec FPC 3.2 à la fois sous Windows et Linux

Prochaine étape de test. Le Mac !!!
A+

Jérôme

EDIT : Je viens de mettre à jour le zip, j'avais fait 2 erreurs de frappes désolé

[jurassic pork]

hello Jérôme,
je viens d'essayer ta nouvelle mouture. Effectivement je n'ai plus l'erreur de bloc mais j'ai une nouvelle erreur :

BZProcessEx.pas(1032,15) Error: Identifier not found "pesAborded"

Je suis sous Windows 10 Lazarus 2.0.8 Fpc 3.0.4

EDIT : Ok avec la nouvelle version l'unité se compile

Ami calmant, J.P

[naute]

Salut, merci de vos retours.

Tu plaisantes : c'est la moindre des choses .

J'essaie la nouvelle version et je te dis ce que ça donne.

[naute]

Voilà les résultats pour les quatre fichiers Python que tu as fournis comme exemples :

test.py :



Le programme tourne mais n'affiche pas les résultats intermédiaires.

test2.py :



L'exécution est aléatoire. Exemples de ce que j'ai eu :

• le programme fonctionne bien ;
• le programme démarre bien mais plante avant la fin ;
• le programme démarre mais se ferme avant la fin ;
• le programme va jusqu'à la fin mais provoque une exception ;
• ...

test4.py :



Le programme plante au démarrage.

test5.py :



Le programme fonctionne correctement. L'arrêt du processus fonctionne également.


Je n'ai testé que l'exécution des scripts Python. Je ne vois pas trop ce que tu entends par "Commande", ni pourquoi le bouton "Envoyer commande" n'est activé qu'après l'appui sur le bouton "Exécuter".

Amicalement,
Hervé

[BeanzMaster]

Voilà les résultats pour les quatre fichiers Python que tu as fournis comme exemples :

test.py :

Le programme tourne mais n'affiche pas les résultats intermédiaires.

Heu ! ben la, c'est peut-être ta version de python qui ne prend pas en charge correctement le script. Bizarre car chez moi ça fonctionne (c'est d'ailleurs le script utilisé lors de ma capture d'écran)

test2.py :

L'exécution est aléatoire. Exemples de ce que j'ai eu :

• le programme fonctionne bien ;
• le programme démarre bien mais plante avant la fin ;
• le programme démarre mais se ferme avant la fin ;
• le programme va jusqu'à la fin mais provoque une exception ;
• ...

C'est ce que je disais dans mon message précédent, c'est aléatoire des fois ça fonctionne pas du tout, d'autre fois à moitié et d'autre fois sans problème.
Ce qui m'embête le plus, c'est que je ne vois pas ce qui provoque les exceptions, surtout que celles-ci ne sont pas levées dans mon code.
Mis à part une ou deux erreurs dans la fonction "execute" du thread je ne vois pas. Ou, sinon c'est lors de l'arrêt/destruction de mon thread que quelque chose cloche.
Et le plus chelou c'est que sous Windows, c'est stable

test4.py :



Le programme plante au démarrage.

Vraiment bizarre, le code d'erreur de sortie 1 correspond à "une opération non permise" sous Linux. Ici c'est comme pour le script "test2.py". Aléatoire.

test5.py :

Le programme fonctionne correctement. L'arrêt du processus fonctionne également.

C'es drôle que celui la fonctionne correctement et pas les autres, surtout que les différences sont vraiment mineurs entre les quatre scripts python

Je n'ai testé que l'exécution des scripts Python. Je ne vois pas trop ce que tu entends par "Commande", ni pourquoi le bouton "Envoyer commande" n'est activé qu'après l'appui sur le bouton "Exécuter".

Pa exemple, compile le petit fichier "TestInput" puis exécutes dans la demo, réponds à la question dans le champ commande puis envoyer



Autre exemple avec CMD et la commande "dir" sous Windows (attention ici, faut passer les chaines en mode "console", sinon les accents ne sont pas correctement affichés)



Voila, bref sous Linux, y a encore du débogage à venir dans l'air.

Si vous avez des pistes, je suis preneur

Bonne soirée

Jérôme

[naute]

Heu ! ben la, c'est peut-être ta version de python qui ne prend pas en charge correctement le script.

Bien vu .
Désolé de t'avoir mis le doute : c'est encore moi qui suis à côté de la plaque. Je n'avais pas fait attention que l'exécutable entré était python. Dans ma configuration, python invoque Python 2.7. Pour invoquer Python 3.x, il faut entrer python3, et là ça marche beaucoup mieux. Donc, je te rassure, à ce niveau tout fonctionne .

Par contre, l'exécution de testinput, compilé au préalable, bien sûr, ne donne rien. Voici ce que j'obtiens :



Cela dit, ne t'inquiète pas trop, apparemment quand ça ne fonctionne pas, c'est plutôt de mon côté que ça se passe.

Quant à exécuter "cmd" pour faire un "dir", pas possible sous Linux bien sûr. Je remplace donc "cmd" par "bash" et "dir" par "ls" et bingo : ça fonctionne .

Bon, ça avance !
Allez ! on va faire dormir les yeux, demain il fera jour .

Bonne nuit,
amicalement,
Hervé

[jurassic pork]

hello Jérôme,
bravo pour ta nouvelle classe ! J'ai quelques soucis avec le projet demo NewProcessEx sous windows . Ce qui me paraît bizarre c'est que tu n'as pas l'air d'avoir ces problèmes.
1 - Pour les test 1,2 , 4 et 5 la première ligne ne s'affiche pas (Compte à rebours)
2 - Pour les test 4 et 5 j'ai une ligne vide en plus après chaque print.

J'ai fait le test avec une version 3.8 de python.
J'ai le même problème sous Lazarus 2.0.8 fpc 3.0.4 et Lazarus 2.0.10 fpc 3.2
Je suis sous windows 10.
Il est à noter que le test4.py fonctionne correctement dans mon projet avec python4Lazarus et aussi TProcessEx (affichage de compte à rebours et pas d'espace en plus entre ligne).
Ami calmant, J.P

[BeanzMaster]

Salut à tous

Après une petite session de débogage sous Linux, ou j'ai quand même réussis à faire planter deux fois Linux en beauté (MD ! MD ! MD !...j'ai du redémarrer mon PC avec le bouton physique).
Je reviens vers vous avec une nouvelle version corrigée, fonctionnel sous WINDOWS et LINUX

Ce que j'ai fait :
1) J'ai revu un peu le code dans la méthode Execute du thread. Les blocs Try..Except..Finaly sont plus cohérents.
2) J'ai corrigé les erreurs d'affichage (cités plus haut par JP)
3) J'ai rajouté trois événements au composant: OnExecute, OnInitialize et OnFilterOutput. J'ai également étendu la gestion des formats de caractères (prise en charge du format "Système" pour Windows et Linux
4) J'ai corrigé deux trois autres petits bugs

Ce qu'il en ressort avec Linux :

1) Il y a un temps de latence lorsque le thread/le processus prend fin.
Ce qui rend impossible par exemple l'utilisation de ShowMessage/MessageDlg dans les méthodes d’événements car le Thread est séparé de celui du thread principal de l'application et ce à cause de ce temps de latence et dont la façon dont les threads sont gérés par Linux.
La solution "rustine", passer par un Timer dans l'application, pour tester l'état du composant et pour afficher les messages.
2) Je n'ai pas réussi à faire fonctionner l'envoie de commande. Est ce du à mon "TestInput" qui est mauvais, ou doit-on configurer la propriété XTermProgram du TProcess ? je ne sais pas, je ne pas cherché plus loin.
3) Une exception de type SIGABRT est lévé par moment et je ne n'ai pas trouvé pourquoi et ou.
4) Il vaut mieux compiler et exécuter l'application SANS DEBOGAGE. Effectivement j'ai l'impression que GDB cause des soucis par moment.
5)Le mode "console visible" ne fonctionne pas. Il faut que je test en direct avec TProcess pour voir si ça fonctionne avec ce dernier.

Voici maintenant quelques capture d'écran sous Windows et Linux

Test.py



Test2.py



Test4.py avec l'événement OnFilterOutput.



Test5.py Je n'ai pas fais de capture, mais il fonctionne également et l'annulation du processus ce fait sans problème dans les deux OS.

Test interception d'erreur



SIGABRT Levé sous Linux chaotiquement de temps à autres. et à divers endroit du processus, sans savoir pourquoi. Heureusement, ce n'ai pas systématique et souvent



Amélioration futures :
- Ajouté une propriété "DeferredOutput" de type boolean, qui permettrait d'envoyer les données interceptés par bloc de lignes (comme c'est le cas ici) ou en temps réel (on pourra ainsi voir tous les "print" du script "test2.py" car dans ce cas il n'y a pas de retour à la ligne)
- Prendre en compte le "carriage return" si celui-ci est en début de ligne comme dans le script "test.py"

Lancez, ces deux scripts dans un terminal, vous comprendrez.

Voila, c'est tout pour le moment

J'attend vos retours, sur cette nouvelle version

A+

Jérôme

[jurassic pork]

hello Jérôme,
Merci pour tes corrections. Je viens de tester sous windows :
ça se passe plûtot mal chez moi.

Pour le test2 voilà ce qui est affiché :


tout s'affiche en même temps ! et toujours pas de compte à rebours.


et pour le test4 :


Pas de compte à rebours mais pas de lignes en trop et l'affichage se fait au fur et à mesure de l'exécution du script.

En plus, tu risques d'avoir des soucis avec Jipété avec tes messages d'erreurs, lui qui est à cheval sur l'orthographe :

Processus terminer.

Ami calmant, J.P (sans T)

[BeanzMaster]

hello Jérôme,
Merci pour tes corrections. Je viens de tester sous windows :
ça se passe plûtot mal chez moi.

Pour le test2 voilà ce qui est affiché :

tout s'affiche en même temps ! et toujours pas de compte à rebours.

La c'est normal que tout s'affiche en même temps car il n'y a pas de retours à la ligne entre chaque nombre. Et les 2 dernières ligne sont trop rapide.
Par compte que la première ligne ne s'affiche pas, c'est un problème

et pour le test4 :
Pas de compte à rebours mais pas de lignes en trop et l'affichage se fait au fur et à mesure de l'exécution du script.

C'est super bizarre que dans les deux tests, la première ligne "Compte à rebours" ne s'affiche pas chez toi et chez moi oui La seule différence c'est la version de nos FPC.
Bizarre

Et avec "test.py" et "test5.py" tu vois la première ligne ?

En plus, tu risques d'avoir des soucis avec Jipété avec tes messages d'erreurs, lui qui est à cheval sur l'orthographe :


Ami calmant, J.P (sans T)

A ben oui, manque un E


EDIT : Je viens de tester avec Lazarus 2.0.6 et FPC 3.0.4 pas de soucis, je vois bien la première ligne "Compte à rebours"
Tes captures sont plus grandes que les miennes, c'est normal ? serait-ce du que ta police par défaut sous Windows est une taille supérieur à la mienne ? et ça serai ça le gag ?

[jurassic pork]

L
C'est super bizarre que dans les deux tests, la première ligne "Compte à rebours" ne s'affiche pas chez toi et chez moi oui La seule différence c'est la version de nos FPC.
Et avec "test.py" et "test5.py" tu vois la première ligne ?

non je ne vois pas compte à rebours avec test.py et test5.py et je suis en version 2.0.10 fpc 3.2 . Pour l'affichage il est plus gros que l'original
et le compte à rebours apparaît dans le test de python4lazarus.

[BeanzMaster]

Pff que l'on est bête

EDIT : Je viens de tester avec Lazarus 2.0.6 et FPC 3.0.4 pas de soucis, je vois bien la première ligne "Compte à rebours"
Tes captures sont plus grandes que les miennes, c'est normal ? serait-ce du que ta police par défaut sous Windows est une taille supérieur à la mienne ? et ça serai ça le gag ?

Le memo est dessous les autres compos, le redimensionnement DPI, c'est pas encore ça avec Lazarus, c'est comme les antibiotique, c'est pas automatique

En redimensionnant le memo la première ligne devrait être visible

[jurassic pork]

Pff que l'on est bête
Le memo est dessous les autres compos, le redimensionnement DPI, c'est pas encore ça avec Lazarus, c'est comme les antibiotique, c'est pas automatique

En redimensionnant le memo la première ligne devrait être visible

Effectivement en redimensionnant le TMemo cela fonctionne beaucoup mieux :



Edit :
Pour éviter ce genre de problème on peut par exemple ancrer le Tmemo en bas du TlabeledEdit command :

[jurassic pork]

hello,
après quelques tests sous linux , peut-être une solution à :

Une exception de type SIGABRT est lévé par moment et je ne n'ai pas trouvé pourquoi et ou.

Dans le code de BZProcessEx à la ligne 581 il y a :

Code :

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

   if (FLinesOutput.Count > 0) then DoEventOutput;

alors que cela devrait être :

Code :

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

   if (FLinesOutput.Count > 0) then Synchronize(@DoEventOutput);

et pour GDB on peut utiliser sous linux et windows à la place FpDebug internal Dwarf debugger : paquet LazDebuggerFP status
par contre avec ce debugger on est obligé d'inclure les symboles de debug dans l'exécutable et utiliser dwarf.

p

Ami calmant, J.P