Zadanie #5457
Uporządkować mechanizm ładowania modeli i konfiguracji
Status: | Zamknięty | Start date: | 27 May 2014 | |
---|---|---|---|---|
Priority: | Normalny | Due date: | ||
Assignee: | Adam Radziszewski | % Done: | 0% | |
Category: | - | |||
Target version: | c++ |
Description
Mechanizm ładowania modelu i konfiguracji jest teraz mało przejrzysty i widzę kilka potencjalnych problemów. Część z tego wynika zapewne ze słabego projektu oryginalnego kodu pythonowego.
Uprzątnę to i będę stopniowo komitował, dodaję Cię jako obserwatora, byś wiedział, co się dzieje.
- trochę mylące nazwy w klasie Tagger (jest np.
config_path
, choć w typowym scenariuszu użytkownik podaje tylko nazwę pliku a nie pełną ścieżkę), - singleton w module
pathsearcher
nie spełnia swojej funkcji, bo trzyma stan tagera; jeśli ktoś utworzy dwie instancje tagera na bazie różnych configów, to czeka go przykra niespodzianka — drugi tager nadpisze pierwszemu nazwę configa itp. - skoro jest moduł
pathsearcher
, to funkcjęget_model_filename
przeniosę tam zcorpusio
; - implementacja funkcji
resolve_config_path
jest nieładna, zakłada, że platformą zawsze będzie UNIX (na sztywno w kodzie separator "/"), poza tym ta funkcja robi dwie rzeczy na raz (też pobiera nazwę modelu) - sklejanie ścieżki źle działa, dokleja się ścieżka dwa razy:
~/proj/wcrft/bin$ wcrft-app/wcrft-app ../libwcrft/config/nkjp_s2.ini xces-kawa.xml -d ~/corp/model_nkjp10_wcrft_s2/ terminate called after throwing an instance of 'Wccl::FileNotFound' what(): File not found: ./../libwcrft/config/../libwcrft/config/nkjp_s2.ccl
History
#1 Updated by Adam Radziszewski over 9 years ago
- Status changed from Nowy to Zamknięty