Geen verschil tussen natural_order en numerical_order

[pebbe]

Ik zie geen verschil tussen gebruik van natural_order en numerical_order

0.xml
1.xml
10.xml
100.xml
1000.xml
1001.xml
1002.xml
1003.xml
1004.xml
1005.xml
1006.xml
1007.xml
1008.xml
1009.xml
101.xml
1010.xml
1011.xml
1012.xml
1013.xml

[danieldk]

Met welke corpus reader? Uit de docu:

Note that this is currently just a hint to the iterator implementation.
Most iterators currently only support the order that is natural to the
underlying corpus.

Op het moment wordt dit alleen ondersteund door DirectoryCorpusReader. Voor bijv. DbCorpusReader is dit vrij zinloos, omdat dan bijv. eerst een query klaar moet zijn voordat je kunt gaan sorteren. Dus het idee is dat je bij het maken van een compact corpus of een DBXML corpus bijv. met alpinocorpus-create de numerieke optie gebruikt, zodat het compacte/DBXML corpus numeriek geordend is.

[pebbe]

Getest op een corpus in DbXML.

Ik kon de uitleg in de documentatie niet vinden, en ben afgegaan op capi.h voor het aanpassen van alpinocorpus-go.

Als je alle documenten in DbXML opvraagt maakt het niet uit in welke volgorde je ze hebt ingevoerd, dacht ik. Je krijgt ze in alfabetische volgorde.

Het gaat dus om een verandering die weinig effect heeft, maar waarvoor wel de C API is veranderd. En die API geeft geen versie-informatie, dus kun je in het gebruik er geen rekening mee houden.

[danieldk]

Voor compacte corpora werk het, maar het lijkt inderdaad niet voor DB XML corpora te werken. Ik meen me te herinneren dat ik het toen wel getest had op DB XML corpora, maar misschien laat m'n geheugen me in de steek.

Ik zal er weer eens naar kijken als ik tijd heb...

(Deze feature was trouwens een verzoek van een gebruiker van de bibliotheek.)

Het gaat dus om een verandering die weinig effect heeft, maar waarvoor wel de C API is veranderd.

Daarom heb ik de SOVERSION in de Ubuntu packages gebumped. Zou ook in de release-2.6 branch moeten.

[pebbe]

Als je de API verandert dan moet je dat aangeven door een nieuw versienummer in de API, in capi.h dus. Alleen zo kan een ander software schrijven die rekening houdt met verschillen in de API.

Ik kan nu alpinocorpus-go niet zo maken dat het automatisch geïnstalleerd kan worden met go get met verschillende versies van alpinocorpus. Het nummer van een Ubuntupakket is niet toegankelijk. Ik zou een configure-script moeten gebruiken om te testen hoeveel argumenten ik nodig heb voor alpinocorpus_entry_iter en zo, maar scripts worden niet ondersteund door go get.

De huidige versie van alpinocorpus-go werkt alleen met de huidige versie van alpinocorpus, niet met de vorige variant.

[danieldk]

On 22. Jun 2017, at 18:31, Peter Kleiweg ***@***.***> wrote: Als je de API verandert dan moet je dat aangeven door een nieuw versienummer in de API, in capi.h dus. Alleen zo kan een ander software schrijven die rekening houdt met verschillen in de API.

Ik weet hoe de C preprocessor werkt ;). Er was nooit een API versie omdat er geen externe software was die de bibliotheek gebruikt (buiten Dact en de Python binding) en we de builds van Dact/alpinocorpus altijd zelf deden. Sterker nog, in eerdere versies was er zelfs geen ABI stabiliteit tussen git commits, totdat ik voor vrijwel alle klassen PIMPL-varianten heb gemaakt. Als er nu behoefte aan is, heb ik niks tegen het toevoegen van een versie nummer. Pull request is welkom (de versie nummer uit CMakeLists.txt kan gebruikt worden).