Discussion :

[BeanzMaster]

Salut à tous

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

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

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);

Justement j'y viens

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



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



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

[jurassic pork]

hello,
Good job Jérôme !

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 :

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
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 :

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

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

[BeanzMaster]

hello,
Good job Jérôme !

Merci

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

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 ! 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

[jurassic pork]

hello,

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

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 :

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
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 :

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

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 :


ami calmant, J.P

[BeanzMaster]

Bonjour,

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 :

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
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

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 :

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

  FProcessEx.Params.Add(edtParams.Text);

par

Code :

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

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

[BeanzMaster]

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.



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

[jurassic pork]

hello Jérôme,

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

Ami calmant, Jurassic Pork

[BeanzMaster]

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

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)



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)



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


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

[Jipété]

Salut,

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

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,

[naute]

Salut Jipété .

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.

[BeanzMaster]

Hello

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,

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

A+

Jérôme

[jurassic pork]

hello Jérome,

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