2016-04-25 9 views
13

Questo problema è stato risolto in Perl 5.22.1. Ne scrivo nel Perl v5.22 adds fancy Unicode word boundaries.Perché Perl v5.22 non trova tutti i limiti della frase?


Perl v5.22 aggiunto le affermazioni Unicode da TR #29. Ho giocato con l'affermazione sentenza confine, ma sembra solo per trovare l'inizio e la fine del testo:

use v5.22; 

$_ = "See Spot. (Spot is a dog.) See Spot run. Run Spot, run!\x{2029}New paragraph."; 

while(m/\b{sb}/g) { 
    say "Sentence boundary at ", pos; 
    } 

Le note di uscita limiti della frase all'inizio e alla fine del testo, ma non dopo che i punti fermi , le terminazioni frase o le parentesi:

Sentence boundary at 0 
Sentence boundary at 70 

Il Unicode breaks tester li mostra per lo più li aspettano sulla base di TR #29.

Non sono riuscito a trovare test non banali nella sorgente perl per questa funzione. Sto digerendo il rapporto tecnico per creare casi di test appropriati, ma finora sembra un'altra funzionalità non testata e rotta.

+6

Quale versione Perl esatta stai usando? La manpage perldelta menziona parecchie correzioni per \ b {sb} in 5.22.1, e quando eseguo il codice di test con quella versione ottengo i limiti di frase riportati nelle posizioni 0, 10, 27, 41, 56 e 70. –

+0

@Calle Dybedahl : Rendi quel commento una risposta. Ho avuto alcuni problemi nella compilazione di Perls 5.22.1 e dei RCs per 5.24 la scorsa notte. –

risposta

4

Il commento di Calle Dybedahl ha ragione (e quando lo trasformano in una risposta, lo accetto). Questa era una funzionalità non funzionante nella v5.22.0 e, per quanto posso dire, non testata. Ho avuto un problema per compilare gli ultimi perls la scorsa notte e ho concluso la giornata con la domanda.

Il perl5.22.1 perldelta non menziona i cambiamenti particolari (e "menzione" potrebbe essere troppo forte in quanto allude semplicemente a possibili cose che erano sbagliate senza enumerarle). Cita come una modifica incompatibile con 5.20.0 (un errore di copia e incolla?), Un'eccezione "singola", quindi più di un problema. Il riferimento a "sano di mente" mi ha fatto pensare che tutte le modifiche fossero correlate al problema di panico nella prossima sottosezione. La menzione di "diversi bug" con un solo riferimento a rt.perl.org mi ha fatto pensare che questi bug fossero correlati al problema del panico.

= head1 incompatibile Modifiche

Non ci sono cambiamenti intenzionalmente incompatibili con 5.20.0 diverso da quello seguenti unica eccezione, che si considera un cambiamento sensibile per fare in fine di ottenere la nuova C < \ b {wb}> e (in particolare) C < \ b {sb}> caratteristiche sane prima che le persone decidessero di non avere alcun valore a causa di errori nella loro implementazione Perl 5.22.0 e li evitassero in futuro. Se esistono altri, sono bug e ti chiediamo di inviare un rapporto. Vedere L sotto.

= head2 controllo dei limiti costrutti

vari bug, tra cui un errore di segmentazione, sono stati risolti con i limiti costrutti di controllo (introdotte in Perl 5.22) C < \ b {GCB}>, C < \ b { sb}>, C < \ b {wb}>, C < \ B {gcb}>, C < \ B {sb}> e C < \ B {wb}>. Tutti i C < \ B {}> ora corrispondono a una stringa vuota ; nessuno dei C < \ b {}> fa. L < [perl # 126319] | https://rt.perl.org/Ticket/Display.html?id=126319>

Inoltre, perlrebackslash, in cui sono documentati i nuovi confini, non dice che non funzionano in v5.22.0.

ho violato una possibile soluzione a causa delle incongruenze nei perldelta e la precedente esperienza che ho avuto che le nuove caratteristiche non sono adeguatamente (o anche a tutti) testati nella sorgente perl. Ho interrotto prematuramente quella linea di indagine e avrei potuto risparmiarmi un paio d'ore. È sicuramente colpa mia se non ho eseguito il codice sugli ultimi binari, ma mi ero fissato pensando che stavo facendo qualcosa di sbagliato e che il mio codice era il problema. Nonostante le numerose esperienze passate in senso contrario, non mi sono mai intrattenuto pensieri (a parte un aggiornamento dell'UCD) che perl era errato.

Ora che sono su una macchina diversa e ho un perl-5.22.1 funzionante, vedo che il mio programma funziona come previsto nel rilascio del punto. Il perldelta avrebbe potuto essere molto meglio qui.

1

Sono principalmente da incolpare per questa situazione, ma c'erano altri coinvolti, quindi userò la prima persona plurale nei luoghi sottostanti.

Innanzitutto, è un errore di battitura che il perldelta per 5.22.1 dice 5.20.0 quando significa 5.22.0. Menziona solo un problema, perché nella nostra mente erano solo una cosa, i confini di rottura di Unicode.

Questi sono stati aggiunti in ritardo in 5.22 e non ci siamo resi conto che c'erano problemi fino a dopo 5.22 spedito. E quando i problemi iniziarono a comparire, alcuni di essi si rivelarono bug nell'algoritmo specificato da Unicode, e presumemmo che fossero tutti tali.

Ma tutto è stato testato, e ho pensato, abbastanza estensivamente. Le versioni recenti di Unicode hanno incluso test di pubblicazione per varie funzionalità e 5.22.0 ha superato tutti i test. Li puoi trovare in lib/unicore/TestProp.pl, che viene eseguito ogni volta che "make test" viene eseguito, eseguito da t/re/uniprops.t. Quelli in questione sono chiamati da Test_SB() (oltre 500) e Test_WB() (quasi 1500), e ogni test consiste in diversi sottotest. Questi erano più test di quanti ne avrei ricavati.

In modo indipendente, qualcuno ha segnalato il segfault all'inizio del processo di sviluppo 5.23. Nell'indagare ciò, ho visto, attraverso la lettura del codice, che c'erano altri problemi nel codice appena spedito. Le interazioni sono complesse e non facilmente riassumibili, quindi il perldelta non ci ha nemmeno provato. Entrambe queste condizioni al contorno richiedono di tenere traccia del contesto in cui possono verificarsi i confini, spesso facendo look-ahead e/o look-behind. Quando il codice analizza la stringa di destinazione, salva il contesto corrente per l'iterazione successiva, dove sarà il contesto look-behind e non dovrà essere ricalcolato. Questo era rotto e il contesto non veniva sempre salvato correttamente. Questo è il motivo per cui sono stati superati tutti i test forniti da Unicode. Erano per brevi input, dove la rottura del contesto non aveva importanza. Quando tutto questo è stato risolto, sono rimasto piacevolmente sorpreso dal fatto che \ b {sb} stesse dando risultati che erano più di quanto si aspettasse un umano.

I bug Unicode sono programmati per essere corretti nella prossima versione di UAX # 29, e penso che abbiamo preso la decisione giusta nel far funzionare \ b {wb} e \ b {sb} in 5.22.1.