When myougiden is in use, jplookup doens't always print the right reading

[leovilok]

Issue

When myougiden is not installed (or is not placed in /usr/bin/local/myougiden), jplookup prints the reading returned by mecab, which tends to be the right one. But when it can find myougiden, it uses (probably) the first reading found, which is often not the right reading in context.

Example

myougiden is not installed, mecab get the right reading for "人":

myougiden is installed, mecab reading for 人 is not used:

Expected behaviour

Print mocab's reading, or better: get myougiden definition matching mecab reading.

[pigoz]

Hi, I have found this is the case only for super common words. i.e.: 自分 Thus the mpv-blacklist file.

BTW: I've stopped using this project. I didn't like to write javascript that gets executed within mpv, so I had wm4 build me a scripting interface that piggie backs on the IPC protocol. That way I can develop my scripts in a decent language (Ruby), and with proper software engineering standards (TDD). My progress is here: https://github.com/pigoz/lat

Sadly no documentation yet. I can probably clean it up further so that other people can use it if there is interest.

[mikehardy]

I'm only replying to playfully suggest that the combination of typescript and jest does TDD just fine. Engineering standards are followed where you follow them..

[leovilok]

Hi @pigoz, and thanks for these scripts anyway.

My progress is here: https://github.com/pigoz/lat

I might check it out, javascript seems to slow down mpv startup, and calling myougiden on each word is very slow too (probably a python extracting itself...), so something executing externally to mpv might be a better design...

[pigoz]

I'm only replying to playfully suggest that the combination of typescript and jest does TDD just fine. Engineering standards are followed where you follow them..

Sorry, I've expressed myself badly, the problem is not TypeScript itself, I didn't intend to blame the language: I love TypeScript (and fp-ts).

But I would have had to mock all the mp. namespace to make the scripts work in a node/jest environment for automated testing. The new external scripting interface makes end-to-end testing a breeze since it's based on the IPC protocol. I could have used the new interface from node, but I preferred the available libraries in Ruby-land (the mecab one is really high-quality)

I might check it out, javascript seems to slow down mpv startup, and calling myougiden on each word is very slow too (probably a python extracting itself...), so something executing externally to mpv might be a better design...

This is another major issue, the JS virtual machine shipped with mpv is very slow, so despite me not using any libraries in these scripts to keep them small, the startup time still suffers a little. Also making shell-out operations parallel was non-trivial IIRC. In lat I've made dictionary lookups multithreaded.