TProcess : redirection d'un flux Python vers un TMemo

Salut à tous

Citation:

---

Envoyé par jurassic pork

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

---

Je n'y pense jamais à cet outils, qui est pourtant hyper pratique surtout quand on fait de la cross-compilation
pour l'ajustement automatique des contrôles :plusser:

Citation:

---

Envoyé par jurassic pork

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

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

Code:

---

if (FLinesOutput.Count > 0) then DoEventOutput;

---

alors que cela devrait être :

Code:

---

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

---

---

Justement j'y viens :zoubi:

Citation:

---

Envoyé par jurassic pork

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.

Ami calmant, J.P

---

Oui j'ai déja lu, deux trois truc sur le sujet, mais je ne me suis jamais laissé tenter de l'utiliser

Revenons, en en à nos moutons.

J'ai continué mon débogage sous Linux et j'ai trouvé pourquoi des exceptions étaient levées. JP le synchronize justement fait partie de la solution.

Pour que cela fonctionne sous Linux tous les évènements reliés au TBZProcessEx (processError, processStopped...) doivent être appelés avec synchronize, contrairement à Windows (linux n'est pas fan des threads imbriqués les un aux autres. Comme c'est le cas ici, avec celui du TProcess)

Après quelques modifications, tout semble correcte sous Linux.

Après un petit nettoyage du code, j'ai rajouté l'options "mode différé" dont je parlais. Plus deux méthodes, en plus de la méthode Send, SendLn pour envoyer une commande avec le retour à la ligne et la méthode SendKey tirée de "UnTerminal" pour simuler l'appuis des touches du clavier.

J'ai également modifié la façon dont sont récupérées les données.
Effectivement pour solutionner les problèmes de réceptions que JP avait mentionné, j'avais eu la mauvaise bonne idée de faire comme FPCUpDeluxe. C'est à dire tenir compte des caractères de fin ligne.

Après plusieurs test je me suis donc rendu compte que cela pouvait occasionner des problèmes pour récupérer les dernières données et qu'il fallait mieux laisser à l'utilisateur de gérer lui même les fins de ligne avec l'événement OnFilterOutput. Ce qui est plus logique, au final pour ce type de composant.

J'ai également rajouté un petit script python (de JP trouvé chez les anglais) pour tester l'envoie de chaines de caractères

Pièce jointe 578326

Vous pouvez aussi tester avec "Python" et comme paramètre "-i"

Pièce jointe 578327

Tout comme CMD sous Windows, bash fonctionne et on peut lui envoyer des commandes.

Par contre je n'ai pas réussi, je ne sais pas comment faire pour que la petite application "testinput" fonctionne.
Et impossible de la lancer, en exécutant "bash". Donc si vous avez une idée, n'hésitez pas.

Voilà d'après mes tests, le composant TBZProcessEx est fiable et stable sous les deux OS

Avec TBZProcessEx et CmdLine (disponible aussi depuis OPM) Il devrait être aisé de réaliser un émulateur de terminal (comme UnTerminal, mais en mieux) ou tout autre interfaçage avec un logiciel en ligne de commande (image magick par exemple)

J'attend vos retours sur cette version "finale"

A+

Jérôme

hello,
Good job Jérôme ! :bravo:

Citation:

---

Envoyé par BeanzMaster

Par contre je n'ai pas réussi, je ne sais pas comment faire pour que la petite application "testinput" fonctionne.
Et impossible de la lancer, en exécutant "bash". Donc si vous avez une idée, n'hésitez pas.

---

l'application testinput j'arrive à la faire fonctionner dans le projet de démo en mettant le chemin complet pour l'exécutable et en modifiant l'application pour "flusher les sorties" comme ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

procedure TMyApplication.DoRun; var s : String; begin Writeln('Process Input test'); Writeln('Entrez votre nom : '); flush(output); while not EOF do begin ReadLn(s); if s = 'quit' then Break else WriteLn(UpperCase(s)); flush(output); end; // stop program loop Terminate; end;

---

cela fonctionne chez moi sous Centos 8
Pour le script python test4 j'ai changé le code du filtre de sortie dans le code car ça me faisait n'importe quoi en affichage voici le code qui fonctionne chez moi :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

procedure TMainForm.ProcessExFilterOutput(Sender: TObject; var Line: String); Var I : Integer; S : String; begin S := ''; for i := 1 to Length(Line) do begin if (Line[i] <> #10) or (Line[i] <> #13) then S := S + Line[i]; end; Line := Trim(S); if TryStrToInt(Line,I) then begin if odd(I) then Line := Line + ' est Impair' ; End; end;

---

Ami calmant, J.P

Citation:

---

Envoyé par jurassic pork

hello,
Good job Jérôme ! :bravo:

---

Merci :zoubi::D

Citation:

---

Envoyé par jurassic pork

l'application testinput j'arrive à la faire fonctionner dans le projet de démo en mettant le chemin complet pour l'exécutable et en modifiant l'application pour "flusher les sorties" comme ceci :

---

Je testerai, mais bizarre, qu'il faille "flusher" alors que sous Windows pas besoin :weird:

Citation:

---

Envoyé par jurassic pork

Pour le script python test4 j'ai changé le code du filtre de sortie dans le code car ça me faisait n'importe quoi en affichage voici le code qui fonctionne chez moi :

---

Bien vu ! :ccool: C'est ce que je disais les fins de ligne doivent être gérées par l'utilisateur. Ce qui me semble plus logique, ou sinon je pourrais rajouter une options supplémentaire, qui permettrai l'envoi que des lignes se finissant par CR et/ou LF. A voir.

A+

Jérôme

hello,

Citation:

---

Envoyé par BeanzMaster

Merci :zoubi::D
Je testerai, mais bizarre, qu'il faille "flusher" alors que sous Windows pas besoin :weird:

---

En fait le souci c'est que sous linux quand il y a une redirection, un buffer est utilisé. c'est pour cela qu'on est obligé de vider le buffer par un flush si l'on veut voir ce qui se passe en temps réel. On a pas ce problème quand on envoie directement la sortie vers la console.
dans un programme free pascal pour désactiver le buffer on peut utiliser ttextrec comme ceci par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

procedure TMyApplication.DoRun; var s : String; begin ttextrec(output).flushfunc := ttextrec(output).inoutfunc; Writeln('Process Input test'); Writeln('Entrez votre nom : '); while not EOF do begin ReadLn(s); if s = 'quit' then Break else WriteLn(UpperCase(s)); end; // stop program loop Terminate; end;

---

Autre chose , le code du filtre de sortie du projet demo peut être simplifié comme ceci dans notre cas :

Code:

---

1 2 3 4 5 6 7 8

procedure TMainForm.ProcessExFilterOutput(Sender: TObject; var Line: String); begin Line := Trim(Line); if TryStrToInt(Line,I) then begin if odd(I) then Line := Line + ' est Impair' ; End; end;

---

troisième point . Dans le projet Demo lorsque l'on met plusieurs paramètres dans le champ paramètres cela ne semble pas fonctionner :
Pièce jointe 578370

ami calmant, J.P

Bonjour,

Citation:

---

Envoyé par jurassic pork

hello,

En fait le souci c'est que sous linux quand il y a une redirection, un buffer est utilisé. c'est pour cela qu'on est obligé de vider le buffer par un flush si l'on veut voir ce qui se passe en temps réel. On a pas ce problème quand on envoie directement la sortie vers la console.
dans un programme free pascal pour désactiver le buffer on peut utiliser ttextrec comme ceci par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

procedure TMyApplication.DoRun; var s : String; begin ttextrec(output).flushfunc := ttextrec(output).inoutfunc; Writeln('Process Input test'); Writeln('Entrez votre nom : '); while not EOF do begin ReadLn(s); if s = 'quit' then Break else WriteLn(UpperCase(s)); end; // stop program loop Terminate; end;

---

---

Je ne connaissais pas, c'est bon à savoir comme astuce. Merci pur les explications :plusser:

Citation:

---

Envoyé par jurassic pork

troisième point . Dans le projet Demo lorsque l'on met plusieurs paramètres dans le champ paramètres cela ne semble pas fonctionner :
ami calmant, J.P

---

Dans la démo dans le "btnExecuteClick"

il faut remplacer

Code:

---

FProcessEx.Params.Add(edtParams.Text);

---

par

Code:

---

1 2 3

FProcessEx.Params.Delimiter := ' '; FProcessEx.Params.DelimitedText := edtParams.Text;

---

Sinon je suis entrain de corriger un ou deux bugs qui traînaient et j'ai remis l'event "OnStdErrOutput", mais je ne sais pas si cela fonctionne réellement.

Je poste la mise à jour d'ici la fin de journée.

A+

Jérôme

Salut à tous

Je reviens vers vous avec (encore une version modifiée)

J'ai fait quelques changements, j'ai élargie les "états" du composants. J'ai rajouté des méthodes de détection du "prompt" inspiré de unTerminal mais ce n'ai pas encore le top, même si c'est pas mal fonctionnel. L'utilisation d'expressions régulières pour la détection du prompt serait surement mieux, mais les "RegEx" ne sont pas mon fort. Et j'ai corrigé quelques bugs mineurs.

Il y a encore quelques "bugs" si je peux les appelé ainsi, car c'est aléatoire et je pense que cela est du au fait que tout est "threadé".

J'ai rajouté une petite démo utilisant le composant "cmdBox" (pas besoin d'installer) il est inclus et il est créé en "runtime". (Il contient quand même quelques bugs d'affichage, surtout avec le prompt)
Je ne l'ai pas testé sous Linux mais cela devrait fonctionner normalement.

Pièce jointe 578468

Il y a encore quelques soucis avec la méthode "Send" à peaufiner et la méthode "SendKey" ne fonctionne pas comme ça devrait. Par exemple envoyer la combinaison "Ctrl-C" ne fonctionne pas.

Bref voilà

Je vous laisse jeter un œil aux sources. Si vous découvrez des bugs ou des comportements bizarres, j'attend vos retours

A+

Merci

Jérôme

hello Jérôme,

Citation:

---

Envoyé par BeanzMaster

J'ai rajouté des méthodes de détection du "prompt" inspiré de unTerminal mais ce n'ai pas encore le top, même si c'est pas mal fonctionnel. L'utilisation d'expressions régulières pour la détection du prompt serait surement mieux, mais les "RegEx" ne sont pas mon fort. Et j'ai corrigé quelques bugs mineurs.

---

Peux-tu expliquer exactement ce que tu veux faire (avec des exemples d'entrée) car en lisant le code je suis un peu perdu :koi:

Ami calmant, Jurassic Pork

Citation:

---

Envoyé par jurassic pork

hello Jérôme,

Peux-tu expliquer exactement ce que tu veux faire (avec des exemples d'entrée) car en lisant le code je suis un peu perdu :koi:

Ami calmant, Jurassic Pork

---

Hello JP,

D'abord pour la détection de prompt on définit un début et une fin de caractères à rechercher. Ce sont les propriétés PromptStart et PromptEndSi la propriété DetectPrompt est à TRUE alors pour chaque sortie (output) détecté, l'événement OnDetectPrompt est levée.

En fonction de la propriété AutoDetectPrompt si elle est à "TRUE" alors on lance la méthode de recherche automatique du prompt.
On va alors, prendre les 2 premiers caractères de la chaines et on va rechercher d'abord si c'est un prompt (re)connu (>>, >>>, SQL>,...) sinon on cherche si le dernier caractère est un caractère spécial ($>\#). Ensuite on prend les un ou deux derniers caractères de la chaîne (output) et on regardes si c'est un espace, ou un caractère spécial. Si on ne trouve rien, les paramètres PromptStart et FPromptEnd reste inchangés.

Ou effectue directement la recherche en fonction de PromptStart et PromptEnd ainsi que la propriété DetectPromptMatch qui indique la condition pour que le prompt soit valide par rapport au "output"
1) Au début : devra obligatoirement commencé par PromptStart.
2) A la fin : devra obligatoirement terminé par PromptEnd.
3) Exactement : devra obligatoirement commencé par PromptStart et terminé par PromptEnd.
4) N'importe ou : PromptStart pourra être à n'importe quelle position et suivie de PromptEnd à n'importe quelle position

Exemples :

Avec Windows Command :

AutoDetectPrompt est à "True"
DetectPromptMatch est à "dpmAtEnd"

La dernière ligne détecté est mon chemin d'accès et il est reconnu comme un prompt (en jaune)

Pièce jointe 578556

Avec Python -i :
AutoDetectPrompt est à "True"
DetectPromptMatch : "dpmAtAnyPos" mais peut importe sa valeur (car ce type de prompt est particulier et recherché directement en dur)

Pièce jointe 578557

Avec Sqlite3 -interactive :
AutoDetectPrompt est à "True"
DetectPromptMatch : "dpmAtAnyPos"

Pièce jointe 578558
Normalement ici, le prompt "sqlite>" n'est pas détecté alors qu'il le devrait (vu que c'est en dur, comme pour le prompt de Python plus haut).
Même si la dernière sortie ('output') est vide les propriétés PromptStart et PromptEnd devraient être correctement rempli.

Les méthodes à vérifier et à regarder sont procedure TBZProcessEx.AutoSetupPrompt;, function TBZProcessEx.IsPrompt(Line: String; var prompt : String): Boolean;, function TBZProcessEx.ContainsPrompt(const LastLine: string; var pos1, pos2: integer; StartPos: integer): boolean;, procedure TBZProcessEx.ProcessCheckPrompt(Line: String); et procedure TBZProcessExThread.DoCheckPrompt; C'est dans ces 5 méthodes que tout se joue.

Vu que tout est dans un thread, j'ai l'impression que l’exécution est trop rapide et que certaines chaînes de sortie passe à la trappe. Il faudrait que je rajoute un temporisateur pour voir (comme je l'ai fait dans procedure TBZProcessEx.Abort; et procedure TBZProcessEx.Terminate; en effet je me suis rendu compte que les changements d'états n'avaient pas le temps d'être traités car on repasse, un coup d'en le thread avant d'en sortir définitivement)

Les méthodes pour la détection du prompt procedure TBZProcessEx.AutoSetupPrompt; et function TBZProcessEx.ContainsPrompt(const LastLine: string; var pos1, pos2: integer; StartPos: integer): boolean; sont un peu chaotiques, c'est plus du bricolage, qu'une vrai solution fiable et stable.
C'est pour cela que je pense qu'une recherche avec les expressions régulières devrait être plus appropriée.

Voilà en espérant avoir bien compris ce que tu me demandais.

A+

Jérôme

Salut,

je squatte cette discussion deux secondes, ça va intéresser tout le monde :

Citation:

---

Envoyé par BeanzMaster

Y'a eu de la mise à jour du côté de FPCUpDeluxe

---

du côté de FPC, du côté de Lazarus, ou interne à FPCUpDeluxe ?

Et qu'est-ce qu'il faut faire ? Cliquer sur quoi ?

Merci, :zoubi:

Salut Jipété :D .

J'ai actuellement la version "1.8.0e", à priori la plus récente. Par rapport à ma version précédente, qui ne mentionne que sa date de "construction", à savoir "build-date: 2018-03-19" , il y a eu un remaniement de l'interface, laquelle propose, entre autres, plus de choix dans les versions.
À part ça, les fonctionnalités semblent similaires et je ne sais pas s'il y a des changements plus "profonds".

Jérôme a peut-être plus de données la-dessus.

À tout hasard, la dernière version est ici.

Hello

Citation:

---

Envoyé par Jipété

Salut,

je squatte cette discussion deux secondes, ça va intéresser tout le monde :


du côté de FPC, du côté de Lazarus, ou interne à FPCUpDeluxe ?

Et qu'est-ce qu'il faut faire ? Cliquer sur quoi ?

Merci, :zoubi:

---

Je parlais des sources de FPCUpDeluxe. Qui ont changé. Depuis la première divulgation de son unité "ProcessUtils", rien avoir avec Lazarus et FPC :P:zoubi:

A+

Jérôme

hello Jérome,

Citation:

---

Envoyé par BeanzMaster

Normalement ici, le prompt "sqlite>" n'est pas détecté alors qu'il le devrait (vu que c'est en dur, comme pour le prompt de Python plus haut).
Même si la dernière sortie ('output') est vide les propriétés PromptStart et PromptEnd devraient être correctement rempli.

---

Tu devrais surveiller le LineStr du readoutput et tu verrais que suivant l'interpréteur demandé ce n'est pas la même chose. Dans le cas du sqlite il y a plusieurs lignes qui arrivent en une seule fois si bien que le LastLine plus tard n'est pas bon. Et dans le cas de l'interpréteur python le séparateur de ligne est chez moi seulement #0A ( #0D0A pour sqlite).

Ami calmant, J.P