Your suggestion is feasible. Anagarika Sabbamitta is the Voice Product Owner. Perhaps you might work together to define this feature?
Thank you for the suggestion. We still have to think about how this can be implemented, but just created an issue to start with.
Thank you so much for this, @Robbie, this is a great addition!
I am linking it to this thread which is linked to the SC-Voice Wiki.
Try this! Go to settings and select Bhante Sujato’s voice. Right now we have SN 1 and SN 2.1-20, both Pali and English.
Suttas that haven’t been recorded will be played with Aditi’s voice for Pali and Amy’s for English when Bhante Sujato is selected.
Let’s continue here from this discussion:
Ah, that’s what you mean! Thank you for the suggestion.
So far we have an invitation for feedback on the accompanying website to Voice, About Voice, which is linked to if you click the “i” button in the upper right corner of Voice. The feedback invitation leads to this thread here on D&D, and for the German version there’s still an email address for feedback.
But it is rarely used, so maybe we should make it more prominent.
So, I finally installed scv-bilara and did my first
slowGrep really is living up to its name… I’ve waited for 15 minutes already… Any ideas?
Hmm … I don’t know … I don’t have very fast internet, but I’ve never waited that long.
You are running
scripts/search [search phrase], right?
Maybe @karl_lew has?
Yes. The last I tried was
scripts/search actually -ll info -tc:sutta
which stalls on
I slowGrep(translation/en) rg -c -i -e '\bactually' [...]
This gives me 14 results within a second!
There is no need to add
-tc:sutta, as this is what it does by default if no other tipitaka category is specified.
And I’ve never tried out
-ll info, which seems to give you a whole lot of information (which I normally don’t need).
What happens if you just type
scripts/search root of suffering?
Nothing. A blank screen. [Edit: followed eventually by
~ ~ ~ :...skipping... and then it hangs]
Hmm, that’s definitely not enough. I really don’t have the skills to advise you any further. Maybe something with the installation didn’t quite work out. I am lacking the background knowledge for these things. Hoping that Karl has some idea.
Wow. That is quite unexpected.
Try this and post results to this thread
git update scripts/env-info
You should see something like this:
ENVIRONMENT VERSION INFORMATION =============================== npm --version => EXPECTED:8.x.x ACTUAL:8.6.0 node --version => EXPECTED:v16.x.x ACTUAL:v16.15.0 rg --version => EXPECTED:ripgrep 12.x.x ... ACTUAL:ripgrep 12.1.1 (rev 7cb211378a) -SIMD -AVX (compiled) +SIMD +AVX (runtime) sudo lsb_release -r => EXPECTED:Release: 10 ACTUAL:Release: 10 SEARCH TIMES FOR "root of suffering" ==================================== Checking grep... real 0m1.453s user 0m0.825s sys 0m0.626s Checking ripgrep... real 0m0.029s user 0m0.003s sys 0m0.007s
Scv-bilara downloads about 1GB of data, so let’s check your data:
du -sh local/*
You should see something like this:
272K local/api 571M local/bilara-data 4.0K local/bls_edit.subl 4.0K local/bls_edit.vi 147M local/ebt-data 16K local/expansion.json 484K local/memo 648K local/suidmap-bilara-data.json 644K local/suidmap-ebt-data.json 4.0K local/suidmap-test-repo.json 192K local/test-repo 16K local/uid_expansion.json
This data must be downloaded initially for offline use. It is immense and comprises the JSON Tipitaka. Since the English version is stable, you’ll rarely need to update that information. In contrast, German uses will need to scripts/search --sync regularly. Updating or initializing Tipitaka information can be quite time consuming (with a blank screen). The messaging for data updates should be better.
I am actually using
scripts/de-search --sync. It says there’s an error, but does update nevertheless.
I’ve changed the instructions for updating scv-bilara content. The existing scv-bilara options still work, but it’s easier for me to maintain a dedicated script. The new script provides better messaging for first-time users.
Ayya @Sabbamitta, if the error bothers you we can investigate. It’s probably just a file that needs to be deleted.
Well, if it’s not a huge thing, then it would be nice. But please don’t put much effort into this. As long as it works nevertheless—who cares?
ENVIRONMENT VERSION INFORMATION =============================== npm --version => EXPECTED:8.x.x ACTUAL:8.11.0 node --version => EXPECTED:v16.x.x ACTUAL:v18.2.0 rg --version => EXPECTED:ripgrep 12.x.x ... ACTUAL:ripgrep 13.0.0 -SIMD -AVX (compiled) scripts/env-info: line 7: sudo: command not found sudo lsb_release -r => EXPECTED:Release: 10 ACTUAL: SEARCH TIMES FOR "root of suffering" ==================================== Checking grep... grep: node_modules/scv-esm/node_modules/.cache/esm/.data.blob: binary file matches real 0m16.779s user 0m0.680s sys 0m4.712s Checking ripgrep... real 0m0.041s user 0m0.017s sys 0m0.026s
I’m not on a Debian / Ubuntu flavor, so I don’t have sudo, etc and I installed the prereqs from my own distro’s package system rather than using your helpful (but incompatible) install script. I suppose I messed something up trying to follow in your footsteps… Is node v18 unsupported? I notice you’re using v16 specifically…
Bleeeeehhh… I tried to install nvm to downgrade to node v16 and completely borked my node install
[Edit: okay. It seems that I was able to restore node, but using
nvm seems out of the question on my particular distro, so I’m stuck with v18]
Okay. Was able to install an Ubuntu virtual machine on top using chroot (actually, the user-land version proot) and was able to use your install script inside the vm. Searching still doesn’t work, but your env investigating script now outputs:
ENVIRONMENT VERSION INFORMATION =============================== npm --version => EXPECTED:8.x.x ACTUAL:8.11.0 node --version => EXPECTED:v16.x.x ACTUAL:v16.15.1 rg --version => EXPECTED:ripgrep 12.x.x ... ACTUAL:ripgrep 13.0.0 -SIMD -AVX (compiled) sudo lsb_release -r => EXPECTED:Release: 10 ACTUAL:Release: 22.04 SEARCH TIMES FOR "root of suffering" ==================================== Checking grep... real 0m25.921s user 0m0.961s sys 0m7.940s Checking ripgrep... real 0m0.241s user 0m0.017s sys 0m0.102s
Thank you for all the hard work. The one thing that caught my eye is that you have ripgrep v13. Scv-bilara doesn’t work with ripgrep v13–my unit tests timed out in confirmation of your experience. That is puzzling.
Try this to get ripgrep 12 if you can:
cd /tmp curl -LO https://github.com/BurntSushi/ripgrep/releases/download/12.1.1/ripgrep_12.1.1_amd64.deb sudo dpkg -i ripgrep_12.1.1_amd64.deb
In the meantime I’ll puzzle over the rg v13 challenge.
Thanks for finding that!