Recherches figées

Question

Il y a un certain nombre d'autres messages qui mentionnent le CPU, mais je ne suis pas sûr que mon problème soit directement lié, j'ai donc créé un nouveau sujet. Mes excuses si j'aurais dû répondre à un message antérieur.
J'ai toujours trouvé PT8 un peu lent, mais j'ai beaucoup de ressources qui défilent ensemble, donc j'ai supposé que c'était simplement trop tard. J'espérais que PT9 serait plus rapide, mais c'est exactement la même chose. J'ai généralement Chrome ouvert, mais même quand je ne l'ai pas, cela ne semble pas l'accélérer. Certaines recherches sont vraiment rapides même si elles ont beaucoup de résultats (par exemple, « reckon » a trouvé 275 résultats en moins d'une seconde), mais d'autres sont vraiment lentes et ne donnent en fait aucun résultat (par exemple, « . (see » a duré plusieurs minutes avant que je ne doive utiliser le gestionnaire des tâches pour fermer PT, plusieurs fois). Quand cela se produit, le CPU semble être à près de 100 %.

image666×593 27.1 KB

J'utilise Windows 10 (1903) et j'ai 16 Go de RAM. Le processeur, si cela signifie quelque chose à quelqu'un, est le suivant :

Avez-vous des idées sur la façon d'accélérer PT en général ou de faire fonctionner toutes les recherches ?

Traduit automatiquement depuis English Afficher l'original

Answer 1

Veuillez signaler ce type de problème via Help > Give feedback. Aucune recherche ne devrait prendre plus de quelques secondes sur un ordinateur correct.
Ce type de problème provient généralement du fait que nous créons une expression régulière en interne pour effectuer la recherche, et il y a eu quelques cas où l'expression régulière générée crée une boucle infinie avec un arrière-plan négatif (connu sous le nom de retour arrière catastrophique et ne se terminera jamais). Il semble que vous ayez trouvé un autre cas de ce problème.

Traduit automatiquement depuis English Afficher l'original

Comments

Signalé

Traduit automatiquement depuis English Afficher l'original

---

Vous avez lié vers la documentation du créateur de RegexBuddy. J'utilise cela tout le temps pour m'aider à construire de bonnes expressions régulières, mais je sais qu'il existe différentes variantes de RegEx qui ont une syntaxe différente. RegexBuddy permet de basculer entre les variantes appropriées, mais je ne suis pas toujours sûr de celle qu'il faut sélectionner.

Quelqu'un peut-il me dire les choix « RegexBuddy » corrects pour les variantes d'expressions régulières utilisées dans les endroits suivants :

• Paratext 9 Find/Replace
• Paratext 9 RegexPal
• Changes.txt, FinalChanges.txt, PrintDraftChanges.txt, DBLchanges.txt, etc.
• SIL Encoding Converters
• Grep Styles in InDesign

Traduit automatiquement depuis English Afficher l'original

Answer 2

Bon, vous avez certainement trouvé la meilleure expression de recherche pour que les développeurs testent. Je viens de rechercher
. (see
dans un projet de Bible complet et j'ai commencé à chronométrer. J'ai abandonné après 4 minutes et demie et j'ai annulé la recherche. J'ai un i7 de 10e génération avec 6 cœurs et 16 Go de RAM, donc cela va paralyser l'ordinateur de n'importe qui.

Je viens d'essayer 9.1 et ce n'est pas mieux.

Traduit automatiquement depuis English Afficher l'original

Comments

Si vous décochez la case « Ignorer les différences d'espacement » (sous More>>), cela fait-il une différence ?

Ce n'est pas vraiment une solution, car vous voudrez peut-être très bien correspondre à un ou plusieurs espaces, mais cela pourrait donner un indice sur ce qui cause le ralentissement.

Traduit automatiquement depuis English Afficher l'original

---

12 secondes. Il semble que nous ayons un problème avec l'option « Ignorer les différences d'espacement ».

Traduit automatiquement depuis English Afficher l'original

Answer 3

Je ne peux répondre que pour PT9 Find/Replace, RegexPal, PrintDraftChanges.txt et DBLchanges.txt. Ceux-ci utilisent tous le moteur d'expressions régulières intégré de .Net : C# (.NET 2.0–4.8 & .NET Core 1.0–3.0).

Traduit automatiquement depuis English Afficher l'original

Comments

Caché dans ce texte anodin se trouve quelque chose de très important. Dites-vous que Paratext 9 RegExPal utilise désormais la même variante d'expressions régulières que Paratext Find/Replace ? C'est énorme et très bienvenu, bien que je devrai réviser ma bibliothèque d'expressions régulières. Tout à fait la peine.

Traduit automatiquement depuis English Afficher l'original

---

Shegnada:

Dites-vous que Paratext 9 RegExPal utilise désormais la même variante d'expressions régulières que Paratext Find/Replace ?

Je pense que oui. C'est un peu compliqué.

Dans Paratext 7.x, RegExPal utilisait Python pour effectuer des recherches d'expressions régulières. Pour simplifier le code dans Paratext 8, nous avons changé pour utiliser IronPython, qui est une implémentation de Python utilisant .Net. En regardant le code source d'IronPython, il semble qu'il utilise le moteur d'expressions régulières .Net pour implémenter les expressions régulières Python.

Cependant, comme il existe de petites différences entre Python normal et les implémentations d'expressions régulières de .Net, je suppose qu'IronPython doit effectuer de petits ajustements aux expressions pour les rendre compatibles avec l'implémentation de .Net. Je ne suis pas à 100 % sûr qu'il effectue un traitement des expressions régulières pour les faire fonctionner ou si ces modifications pourraient rendre IronPython légèrement différent du .Net normal ou non.

Traduit automatiquement depuis English Afficher l'original

---

Je voudrais noter que dans Find, les retours à la ligne sont ignorés, donc vous ne pouvez pas rechercher quelque chose comme \\s .* pour trouver des titres de sections. Même si vous incluez (?-s), les nouveaux retours à la ligne sont ignorés.

Traduit automatiquement depuis English Afficher l'original

---

anon848905, la restriction que vous notez dans la boîte de dialogue Find est problématique. Ces derniers mois, beaucoup des expressions que je partage avec les utilisateurs ne fonctionnent plus (s'ils sont dans pt9) à cause de cette réalité d'« ignorer le retour à la ligne ». J'utilise souvent « jusqu'à » via des classes négatives… les plus courantes étant

• jusqu'à un nouveau retour à la ligne : [^\r]+
• jusqu'au prochain marqueur (sur la même ligne) [^\r\\]+

Ces expressions (ou cette technique) pour limiter la recherche à un contexte ne fonctionnent plus.

Je voudrais mentionner à nouveau que c'est problématique pour donner à un autre utilisateur qui ne veut pas se lancer dans RegexPal, ou à un utilisateur qui doit corriger beaucoup de problèmes un par un dans Paratext.

Traduit automatiquement depuis English Afficher l'original

---

Une chose que vous pouvez faire pour partager une recherche RegEx complexe avec d'autres utilisateurs est d'exporter la liste RegExPal, de la modifier un peu avec un éditeur de texte et de l'envoyer pour qu'ils l'ouvrent dans la fenêtre List.

Traduit automatiquement depuis English Afficher l'original