このアカウントは、notestockで公開設定になっていません。

Compiling and building Palm-OS-Applications on Ubuntu 20.04 LTS (64 Bit) (07.06.2020) https://palm2000.com/projects/compilingAndBuildingPalmOsAppsOnUbuntu2004LTS.php
…なん…ですと…（やったのか……）

6502と68000はプログラマーの一般教養です、と言われているらしいけど（言われていないかも）、どっちも未経験なのです。

Palmくらいかなあ、手元にあったm68k機。実はメガドライブもMacintoshもX68000もSun3も未経験なんですよね…

うーむ、PHEMが動いていたはずなのだがなんかうちのAndroid機で動かなくなってるぞぉ…？ https://play.google.com/store/apps/details?id=com.perpendox.phem&hl=ja

イマドキの環境でgcc-2.95するのって相当難しそうな気がするんだけど、どうなんだろう。仮想マシンで動かすったって、当時のOSが仮想マシンを知らないので動きませーんというケースもあるし…

（m68kなPalmのgccって、2.95系に魔改造パッチ当ててるからあれをもう少しモダンなgccに当てるとかどう考えても労力と得るものが見合わないんじゃね？という気がしなくもなく。お金出してCodeWarrior買うにしても限界はあるだろう…出物的にも、開発環境を動かすOS的にも）

レトロコンピューティング的に生き残りやすいかどうか、という意味で解釈してほしいです…

このアカウントは、notestockで公開設定になっていません。

LeftHackが使えるという理由でVisor Platinumを買った身には、これが使えないPalmには「…」と感じてしまうのだけども。

（スタイラスは意地でも左持ち、普通の鉛筆などの筆記具は右持ちなんですけど）

やっぱり今後はARM系のPalmOSの方が生き残るかな…m68kは開発環境がかなり特殊だし…

自作キーボード沼が、口をあんぐりとあけてそこに存在してるんですが…（怖

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

もーやだーかえるー（流石にこんな面倒なのは関わりたくないからそっ閉じ）

もしかしてさあ…Juman.pmって…Cのバインディングとかそういうのじゃなく、いちいち/usr/bin/juman呼び出してその結果を受け取るとかそういう奴…？ （めんどくさ…） https://github.com/ku-nlp/juman/blob/master/perl/lib/Juman.pm

静岡県庁「やさしい日本語」の手引き(平成30年2月) https://www.moj.go.jp/isa/content/930005563.pdf ここに「日本語読解学習支援システム リーディング チュウ太」http://language.tiu.ac.jp なるサイトがあるけど繋がらない…検索エンジンだと https://chuta.cegloc.tsukuba.ac.jp/ になるけど、こちらも繋がらない。

このアカウントは、notestockで公開設定になっていません。

人手を介して構築されたコーパスだと多分「開いた口が塞がらない」→「あいたくちがふさがらない」になるんだろうけど、機械的にやるとこの辺が限界なんだろうなあ。

が が が 助詞 9 格助詞 1 * 0 * 0 NIL
塞がら ふさがら 塞がる 動詞 2 * 0 子音動詞ラ行 10 未然形 3 "代表表記:塞がる/ふさがる 自他動詞:他:塞ぐ/ふさぐ 反義:動詞:空く/あく"
ない ない ない 接尾辞 14 形容詞性述語接尾辞 5 イ形容詞アウオ段 18 基本形 2 "代表表記:ない/ない"
EOS
uaa@DESKTOP-251U0UF:~$

uaa@DESKTOP-251U0UF:~$ echo "開いた口が塞がらない" | juman
開いた あいた 開く 動詞 2 * 0 子音動詞カ行 2 タ形 10 "代表表記:開く/あく 自他動
詞:他:開ける/あける 反義:動詞:閉じる/とじる;動詞:閉まる/しまる"
@ 開いた ひらいた 開く 動詞 2 * 0 子音動詞カ行 2 タ形 10 "代表表記:開く/ひらく
自他動詞:同形 反義:動詞:閉じる/とじる"
口 くち 口 名詞 6 普通名詞 1 * 0 * 0 "代表表記:口/くち 漢字読み:訓 カテゴリ:動物-部位;抽象物;形・模様"
@ 口 こう 口 名詞 6 普通名詞 1 * 0 * 0 "代表表記:口/こう 漢字読み:音 カテゴリ:抽象物"

「開いた口が塞がらない」、これkakasiもjumanもmecabも「ひらいたくちがふさがらない」になっちゃいますね…

uaa@DESKTOP-251U0UF:~$ echo "開いた口が塞がらない" |nkf -e |kakasi -ieuc -KH -JH | nkf -w
ひらいたくちがふさがらない
uaa@DESKTOP-251U0UF:~$ echo "開いた口が塞がらない" | mecab -Oyomi
ヒライタクチガフサガラナイ
uaa@DESKTOP-251U0UF:~$

りそう/理想 を/を いえば/言えば よみがな/よみがな へんかん/変換 こうほ/候補 な/な すたいる/スタイル で/で けいたいそ/形態素 かいせき/解析 すみ/済 な/な げんご/言語 しげん/資源 を/を げんご/言語 もでる/モデル こうちく/構築 つーる/ツール を/を つかって/使って を/を つくる/作る ってのが/ってのが べすと/ベスト なんだよね/なんだよね その/その しゅほう/手法 を/を とらない/採らない とれない/採れない のは/のは たんじゅん/単純 に/に すとれーじ/ストレージ ようりょう/容量 の/の もんだい/問題

…って感じに文章が膨れ上がる（句読点及び英数は除いてます）。

理想を言えば、よみがな/変換候補 なスタイルで形態素解析済な言語資源を言語モデル構築ツールを使ってdata.arpaを作るってのがベストなんだよね。その手法を採らない（採れない）のは、単純にストレージ容量の問題。

msrlmのビルド、エラーが多いな。2007年に作られたソフトウェアでgcc-3.4.3/Cygwin, gcc-4.4.4/Linux, VS2010を想定しているというから、適当にメンテナンスをすれば使えるとは思うんだけど（GitHub辺りでやれば良いのに…）。 https://www.microsoft.com/en-us/download/details.aspx?id=52542

e-mailの信頼度って、ドメインのつよつよ度と一致するような。

（やっぱ.govとか.milとか…ぉぃ）

このアカウントは、notestockで公開設定になっていません。

jumanはkakasi/MeCabのようにお手軽には扱えそうにない感じ。放置で良いかな…？

うーん、Debianにapt-get install juman juman-dicしてjumanに文字列を食わせてはみたんだが…何食わせても変換せずにEOSだけ返すという現象に遭遇中。WSL上のUbuntuはちゃんと動くんだけどなあ。

そうなんだよあ、あの界隈は奴（鬼籍に入っている）が居るから今更とはいえ参入するのは、というのは…別に気にすることでもないし気にしたら負けなんだろうけど。

とりあえず問題点は明らかになったので明日続きやろう…

wchar_t使ってると、もうUnicodeで良くね？って気分にはなりますねー

一応kakasiってUTF-8食えるってことになってたはずなんだが…コマンドラインなら動くけどlibkakasiじゃダメとかそういう話だったりする？

日本語ウェブコーパス2010→libkkcの辞書作成は一旦終わろうと思っていたのですが、変換候補に読み仮名を振る際にkakasiではなくMeCabを使ったらどうだろう→MeCabならUTF-8で処理できるからEUC-JPへの変換テーブル要らないよね→MeCab/kakasiの比較もしたいし→あーkakasiはUTF-8食わせるとダメかー、という流れで色々面倒なことになってます。

自分の雑な理解なんですが…kakasiもMeCabも形態素解析なツールなんですが、MeCabは辞書レベルでUTF-8に対応している（のでUTF-8な文字列を食わせてもちゃんと動く）のに対し、kakasiはEUC-JPな辞書そして入出力の部分でUTF-8←→EUC-JP変換を行っているのでUTF-8→EUC-JPへ変換できない要素があるとおかしくなるとかそんな話なんだと思います。

[Kakasi-dev 236] Re: U+8535で失敗 (09-Dec-2019) https://www.mail-archive.com/kakasi-dev@namazu.org/msg00196.html

「KAKASIのUTF-8対応はかなり強引で、元の設計が古いこともあってEUC-JP, SJISにない文字については考慮していません。」

mecab同様にkakasiにUTF-8な文字列を食わせるとハングするという現象に遭遇しているんだけど（ダメそうな文字をある程度はじいていてもダメっぽい）、当初行っていたUnicode→EUC→Unicodeな処理を復活させる必要を感じている。

おお、これは良い
Gitで過去に削除したファイルを検索、復元させる方法(2017/Oct/01) https://rcmdnk.com/blog/2017/10/01/computer-git/

なんかkakasiの挙動が怪しい気がするんだけど…EUCで処理させた方が安全とか、なんかバッドノウハウあったりしませんか？

さてと、一旦kakasi→MeCab化したので、これをkakas/MeCab両対応へ持っていこう。MeCabの読み仮名も結果に癖があって、カタカナで返してくることになっている割には「ぁ」に「ぁ」を返してくる…カタカナになってないじゃん！って感じなんだよね。

そういえばなんかそんなのもありましたね…（まだ滅んでいなかったんだろうか）

このアカウントは、notestockで公開設定になっていません。

kakasiでもUTF-8が通るなら、mecab/kakasi両対応というのもちょっと考えないといけないな（とはいえ「蹴っ飛ばす」が「けっ飛ばす」になっちゃう問題への対策を復活させないといけないし…）

uaa@emeraude:~$ echo "かな 漢字 ヘンカン" |kakasi -iutf8 -KH -JH
かな かんじ へんかん
uaa@emeraude:~$

kakasi、ちゃんとUTF-8対応してるじゃん…（多分-iutfみたいに間違ってたオプション指定してたんじゃないのー？＞自分）

C++で書いている以上、うまくまとめられる箇所はまとめられそうな気がするんだけどなあ。

kakasi→mecabへの変更はしてはみたんだけど、どうなんかねえ…分からなくなってきた。

これは評価が難しいな…
遊び方、kakasiは「あそびほう」mecabは「あそびかた」
これに対して
遊び/盛り、kakasiは「あそび/さかり」mecabは「あそび/もり」
…kakasiだけ、mecabだけ、という訳にもいかないのかも。
ユーザが好みに応じてkakasi/mecab選べた方が良いのかもな…

https://github.com/ueno/libkkc/blob/master/libkkc/rom-kana-utils.vala#L41 を見るに、Unicodeにある片仮名…ヷヸヹヺは読みとして扱わない（扱えない）で良いかな。

- UTF-8であれど、EUC環境で使うこともある以上UTF-8特有というものに対しては配慮しない
- かな漢字変換である以上<unk>（読みを設定できない物）に関しては対応しない

辺りの軸は定める必要があるかね。

もう少し処理を洗って、考えないと…

候補のチェックをkakasi/EUC版と同様にするのであれば、結局「候補の文字列をEUCへ変換可能かどうか」というチェックになってしまって、Unicode→EUCテーブルを外せなくなるという問題を抱えてしまう（せっかくUTF-8化するならそんなテーブルは外したい）。

ファイルから読みだしたものはwchar_t[]で管理していて、kakasiに渡すときはEUC化(unsigned short[])したものをchar[]と見立てて渡す…MeCabの場合はmulti-byte stringなchar[]に変換して渡す…得られた結果はその逆で。

変換候補と読みのチェックをwchar_t[](Unicode)←→unsigned short[](EUC)変換時に掛けているけど、これをどう再現するかが頭の痛いところ。MeCabの読みは平仮名ではなく片仮名なので結局変換処理を入れる必要があるから…ここで引っかけることはできそうなんだけど。

wchar_t(Unicode)→mbs(UTF-8)/MeCab→wchar_t(Unicode)/カナ→wchar_t(Unicode)/かな

kakasi/EUC版の場合は候補側と読み側の両方でチェックを掛けられたけど、MeCab/UTF-8版だと読み側でしかチェック掛けられないか…？

nwc2010-libkkc、を利用したCC100-jaのlibkkc辞書化を考えてみたけど…nwc2010-libkkcの読み仮名付与に使うkakasiをMeCabに変えることはできないかというのが一つの課題になりそう。別にkakasiのままでもいいのかもしれないけど、読み仮名を振れない物は変換候補にできない以上大きな辞書を持っているMeCabの支援はやっぱり受けたいなって（形態素解析でもMeCabを使うなら読み仮名もMeCabでというのが自然だし）。

MMDVMHostで自分が手を入れた部分にat()＋try～catchなコードがあるけど、直すか放っておくか…C++0xなので放っておく、でいいのかな（find()はC++11だし）

find()だとイテレータを返してしまうし（end()のチェックをすれば良いのか）、単に存在チェックするのにat()＋try～catchだと大袈裟だ、ということでcontains()なんだけどC++20ってのがなあ。 https://cpprefjp.github.io/reference/map/map/contains.html

libkkcとしてはtext-bigram-language-model.vala中で<UNK>についての処理は入ってるけど…何か積極的に対処してるようにも見えないなあ。

まあ、難しいことは後から考えるとしてまずは辞書を作るためにどんな感じの作業が必要かなーというのを洗い出せれば良いや。細かい部分を詰めるとかそういうのは詳しい人がやることだし（と面倒な部分からは逃げる）。

変換候補にできないものは<unk>に置き換える、という手法は…確かにそうなんだけど、既にN-gram化されている物に関しては複数の「この <unk> は」みたいなエントリが出た場合にどう統合するのかを考えないといけないから厄介。

N-gramを作成する以上「この 治療法 の evidence」に対しては「この/この ちりょうほう/治療法 の/の evidence/evidence」と出力しないとダメで…「この/この ちりょうほう/治療法 の/の」（evidenceを切ってしまう）出力はできない。辞書へ含めるに相応しいかどうかの判定は形態素解析よりも後にしないといけない。

既に形態素解析済/N-gram化済というデータだったからkakasiniよる読み仮名付与と合わせて辞書データに入れるかどうかのフィルタリングをしてしまったけど…多分この部分はもう少しマシなやり方はありそう。

いやいや、元のテキストデータがUTF-8なのでUTF-8辞書入れないとダメでしょ。

DebianでMeCab(日本語形態素解析システム)を利用する (2017/09/22) http://qs.nndo.jp/2017/09/22/865/

apt-get install mecab mecab-ipadic mecab-utils
と、mecab-ipadic-utf8を敢えて入れないという方針でいくか。libmecab2は依存性により自動インストールなのでいちいち記述しなくていいし、コード書く訳じゃないからlibmecab-devも（今のところ多分）要らないし。

ChaSen形式だと処理が楽そうか…最初と二番目を見てればいいから。

MeCabの出力結果、読み仮名がカタカナというのがなあ…これは平仮名に変換しないといけないし、libkkc辞書を作るなら「よみがな/変換対象」形式にしないといけないので結局何かしらのコンバータが要るのは確かそう。

nwc-toolkitのデフォルトがMeCab分かち書きフォーマットじゃないか…

MeCabは基本的にEUCで動くが生成した辞書の文字コード次第…とにかくEUCなら変換対象はEUCで記されたものに限定されるのはkakasiを使っていた時と同様か。わかち書きモードがあるならそれは（ストレージ容量を食わずに済むので）助かるけど、読み仮名を別途用意するのがなあ… https://taku910.github.io/mecab/#format

CC100-ja、展開すると75GBのテキストになりますね…

JUMANはChaSen系の出力フォーマット https://nlp.ist.i.kyoto-u.ac.jp/?JUMAN%2B%2B
GiNZAはCoNLL-U形式 https://megagonlabs.github.io/ginza/
SudachiはMeCabっぽいけど設定次第ではChaSenっぽくもなる？（よく分からない） https://github.com/WorksApplications/Sudachi#sudachi-%E6%97%A5%E6%9C%AC%E8%AA%9Ereadme

MeCabとChaSenの出力フォーマット (2011-01-02) https://kshi-kshi.hatenadiary.org/entry/20110102/1293920002
これを見るに、JanomeもMeCab形式で出力しているという理解で良いのかな。 https://mocobeta.github.io/janome/

各種形態素解析器の出力フォーマットを見てみる必要はあるのかもしれない。その前にダウンロードしたCC100-jaを展開して、どのくらいのサイズになるかを調べる必要があるかも（空きがなければ作業はできない）。

とはいえ、nwc-toolkitの対応する形態素解析器はMeCabとchasen（ベースとなったJUMANはイケるのか？）と書いてあるのだが…それ以外でも使えるのはあるのだろうか？ https://github.com/xen/nwc-toolkit/blob/master/docs/tools/ngram-counter.html

自然言語処理の形態素解析について調べたまとめ (2020/11/15) https://zenn.dev/megane_otoko/articles/008_morphological_analysis
MeCab以外にもJanome, GiNZA, JUMAN, Sudachiがあると。

テスト文字列に「うんこ」と入れるな (2021.Sep.9) https://www.slideshare.net/ketaiorg/ss-250149770
「人類はうんこに打ち勝つことは不可能」

…確かにうんこには勝てない。<unk>をそう読んでしまう程度には。

アヒルヤキを変換してみよう(2015.Mar.1) https://www.slideshare.net/hashimom/open-manyo-ahiruyaki
あひる焼き、そういうことだったのか…

メルセンヌツイスターは知ってたけどxoroshiro128+は初耳。

xoshiro / xoroshiro generators and the PRNG shootout https://prng.di.unimi.it/

このアカウントは、notestockで公開設定になっていません。

外部からlookup()呼べれば良いじゃんとか思ったけど、class Stateの中でinternal属性付いちゃってるから手も足も出せない…（プロジェクトの中からは自由に呼べるけど、public APIとしての呼び出しはできない）

lookup()はinitial-state-handler.valaとconvert-sentence-state-handler.valaから呼んでる

トラ技の厚さは国の豊かさと国力によって変化する #あながち嘘ではないと思う

噂じゃなく事実…（CQ Ham radioに関しても薄くなっているけど）

このアカウントは、notestockで公開設定になっていません。

変換処理（辞書の優先順位）はlibkkc/state.valaのlookup()に書いてあるね。 https://github.com/ueno/libkkc/blob/master/libkkc/state.vala#L378
ユーザ辞書が最優先になる（そりゃそういうもんだけど）。lookup()はどこから呼んでるかな…

libkkc/system-segment-dictionary.valaってMappedFile()使ってるけど、これってSKK辞書の処理…？ https://github.com/ueno/libkkc/blob/master/libkkc/system-segment-dictionary.vala

過去の自分のツイート（当時）に立ち返ってみる。
https://twitter.com/uaa/status/1442001949562322947

libkkc UTと日本語入力の話(2021.1.10) https://chienomi.org/articles/linux/202101-kkc-ut.html にある、UT辞書をlibkkcに載せる話…ユーザ辞書自体の扱い、システム辞書との兼ね合いについてはコードを見ておきたいなって。大きなユーザ辞書でフリーズすること、まともに変換できなくなるというのは流石にどうなのって思う訳で。

CC100-jaのダウンロードは終わり。これからは一般家庭であっても言語資源やテキストマイニングを行える体制を有していないといけない時代なんだろうか…（んなこたない

X(ex. Twitter)の呟きをこちらでもリサイクル。
短単位自動解析用辞書を作る（４） (2023/7/15) https://note.com/teruaki_oka/n/n8b791966aa52
CC100-jaをnwc-toolkit他を使ってUniDicの改良に使用する話…でいいのかな？

HTMLパース→テキスト抽出→Unicode正規化→形態素解析（分かち書き）→N-gramコーパス作成、なんだろうけど…ただのテキストマイニングならそれで良いとして、libkkc向けに「よみがな/単語」形式にしないといけないっていうのをどうしたもんかね。

別に今と同じ、n-gramコーパス構築後にkakasiで付加、でも良いんだろうけど。

CC100-jaをnwc-toolkitで処理してコーパスを作る、というのはどうなんだろうかね。本家(https://code.google.com/archive/p/nwc-toolkit/)にtoolkitソースのアーカイブがあるけど、簡単に中身を確認するなら誰かのmirrorなのかforkなのか https://github.com/xen/nwc-toolkit を見るのが手っ取り早いか。

ミリンの焼酎割りが旨いとは思わなかった (2013.10.27) https://dailyportalz.jp/kiji/131025162167 流石デイリーポータルZ(?)、焼酎だけでなく日本酒・ビール・ウイスキー割りを試している。

Wikipediaだと「柳蔭（やなぎかげ）」ではなく「本直し（ほんなおし）」の項に記されてる。 https://ja.wikipedia.org/wiki/%E6%9C%AC%E7%9B%B4%E3%81%97

夏の終わりに、風流な和製カクテル「柳陰」で夏の余韻を。(2018.8.17) https://www.fukumitsuya.co.jp/komekara/article/1365/ 「氷を入れたロックグラスに味醂1、焼酎2の割合で注ぎ、軽く混ぜます。大切なのは、一切の調味や添加物を加えていない「本味醂」を使うこと。」
結構みりんを使う…？

このアカウントは、notestockで公開設定になっていません。

頻度750辞書(100M)→500辞書(180M)、やっぱメモリ喰うな…

このアカウントは、notestockで公開設定になっていません。

ま、多少主語がデカくてもいいかな…？

とはいえ、s3-ap-northeast-1.amazonaws.comは日本国内かと言われると分からんのだけどな…

個人で利用可能な日本語の言語資源が海外にある以上、例の「はじめに」も修正が必要だな…という訳で、「日本国内にあるものに関しては」の文言を付けて直しておくとしよう。

どれどれ…

逆に言えば、素材から一貫して自分の納得いく形に加工できるってことでもあるな…本っ当に「ナマ」の素材…

CC-100の日本語テキスト、本当に日本語テキストだこれ…MeCabで形態素解析するところから始めないといけないやつだ…（そう考えると形態素解析が終わってN-gram化してる日本語ウェブコーパス2010ってすごく便利なんじゃ）

日本語の言語資源を海外から手に入れないといけないとか、「日の丸〇〇」的にそれってどーよとか突っついてみようか。

CC-100とか扱いやすそうに見える（といってもトップページから目的とする言語へのリンクが張られているからという理由でデータの中身はこれから見る） https://data.statmt.org/cc-100/ mC4はよく分からない… https://github.com/allenai/allennlp/discussions/5056 JSONでも9.7TB(multilingual)なので、落としてから日本語だけ抜き出すとかしないといけないのかな。

OSCAR23.01にある日本語の資源(?)は181.2GBか… https://oscar-project.github.io/documentation/versions/oscar-2301/

Bing AI chatで「無料で使用可能な日本語の言語資源はありますか？」と聞いてみると、国語研はともかくとして、日本語LLMまとめ https://github.com/llm-jp/awesome-japanese-llm と【自然言語処理】フリーで使える大規模な日本語テキストコーパス(2023/01/08) https://tma15.github.io/blog/2023/01/08/%E8%87%AA%E7%84%B6%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E3%83%95%E3%83%AA%E3%83%BC%E3%81%A7%E4%BD%BF%E3%81%88%E3%82%8B%E5%A4%A7%E8%A6%8F%E6%A8%A1%E3%81%AA%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E3%82%B3%E3%83%BC%E3%83%91%E3%82%B9/ をおすすめされた

犬と同居している人は活動的でiPhoneユーザーが多い、猫と同居している人はスマホ利用時間が長くAndroidスマホユーザーが多い (2023/9/14) https://www.moba-ken.jp/project/lifestyle/20230914.html

そうなの…？

えー…

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

読みの最初が「ぁぃぅぇぉっゃゅょ」辺りの除外はとりあえず保留。なんか害があるようならその時に除外を考えることにしよう。

大判焼のことか…（解釈に５秒以上かかった）

このアカウントは、notestockで公開設定になっていません。

頻度 750辞書くらいがバランスとしては良いのかなあ（よく分かってません）

辞書のデカい影響だと思うけど、 fcitx5が600M以上もメモリ喰ってるのは流石に…

形態素解析で単語を得ているからかは分からないけど、「ぁぁぁぁ」「ぁあっしだってそんなこたぁ」「ああああああああああああああああああああああああ」ですら一単語になってしまうから、なんかうまいことやらないといけない気がする。

読みの最初が「ぁぃぅぇぉっゃゅょ」辺りは除外した方が良いのかなあ（「ー」で始まるのは除いてたんだけど、これらの文字は考えてなかった）。

canna辞書（標準）が4万語、強化して26万くらいか…
https://www.stex.phys.tohoku.ac.jp/~ohba/canna/node4.html
https://ja.osdn.net/projects/alt-cannadic/wiki/FrontPage

うーむ、頻度100辞書、できちゃったのは良いけど…これ生成するのにRAM16GBじゃ厳しそうな感じ（32GBマシンでtop見てると16GB近く使ってるとか表示される）。data.3gramが290M、data.3gram.filterが24Mと当然デカいし…

日本語ウェブコーパス2010、頻度100以上から辞書を作れるかも試してみるか…

uaa@framboise:/usr/local/lib/libkkc/models$ ls -sk sorted3.1000/
total 51172
448 data.1gram 864 data.2gram.filter 160 data.input
704 data.1gram.index 34464 data.3gram 4 metadata.json
11616 data.2gram 2912 data.3gram.filter
uaa@framboise:/usr/local/lib/libkkc/models$

uaa@framboise:/usr/local/lib/libkkc/models$ ls -sk sorted3.orig/
total 30892
736 data.1gram 672 data.2gram.filter 264 data.input
1184 data.1gram.index 17408 data.3gram 4 metadata.json
9120 data.2gram 1504 data.3gram.filter
uaa@framboise:/usr/local/lib/libkkc/models$

オリジナルの辞書だと30Mくらい、とはいえ日本語ウェブコーパスで生成した辞書と比べると1-gramの量が1.5倍くらいオリジナルの方が大きかったりするので単純に辞書の「総量」で比べてもあんまり比較にならない気がする。

頻度1000辞書載った…

うーむ、生成元のdata.arpa付きでアーカイブ作ってみるにしても、data.arpa自体がデカすぎる…出現頻度1000でバイナリは50M程度、data.arpaは260M。

LinuxでもOpenBSDでも、amd64なので生成されたlib/libkkc/models/sorted3/*の内容は同一…Linux上で、出現頻度を1000, 1800, 1500, 1250に調整して辞書を生成し、それをOpenBSD上に持っていって評価というのはできそうだな。1000で以前動かなかったけど、これが動くなら…だいぶ変わりそうな予感。

__attribute__(hogefuga)とか、使うこと多いかも…

このアカウントは、notestockで公開設定になっていません。

web上の文章とか活動とか集めるだけ集めたくせに、その成果を限られた人間にしか公開してやらねえ、という態度が非常にムカついているので「言語資源を特定の属性を持った云々しか公開しない」ということに対して激しく攻撃したくなるんですよね。ザケんなコラ💢って。

不満調査データセット、ちょっと気になる。何に対して不満を持っているのか… https://www.nii.ac.jp/dsc/idr/fuman/

（こっちでも書いちゃう）
情報学研究データリポジトリ https://nii.ac.jp/dsc/idr/ の中にあるのだと、ニコニコデータセットくらいしか個人で使えそうな言語資源が見当たらないんだけど（これですら蹴られそうな気がする）。 https://www.nii.ac.jp/dsc/idr/nico/nico-user.html

OpenBSDのportsがkakasi 2.3.4だったりするのでここはメンテしないといけないのかもしれんな…？

NetBSD/pkgsrcはjapanese/kakasi→textproc/kakasiへ引っ越してるのか。とはいえ、libkakasiは非対応なのか…？（NetBSDに詳しい方のツッコミ希望） http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/textproc/kakasi/?only_with_tag=MAIN

そういえばOpenBSDにlibkakasiのportsってあったっけ…（見当たらない？）これがあるともう少し作業が楽なんだけど…いちいちDebian上でやらないで済むし…

（出来上がっている辞書の利用については、class defaultで大丈夫なんだろうか…？という疑問があったので試してる。基本的にclass staffで使っているからよく分かんないんだよね）

libkkc-dataの生成、デフォルトユーザだとPythonのMemoryErrorで生成できないんだけど…組み合わせの出現頻度数を1800以上に絞っても生成できないっていうのはどうなんだろう（package生成時はrootで行っているので制限に引っかかってないというのはある）。

class staffでもこんなもん
bash-5.2$ ulimit -a |grep -v unlimited
data seg size (kbytes, -d) 1572864
max locked memory (kbytes, -l) 87381
max memory size (kbytes, -m) 978512
open files (-n) 512
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 4096
max user processes (-u) 256
virtual memory (kbytes, -v) 1576960
bash-5.2$

OpenBSDにおけるデフォルトのリソース（ulimit -aで表示されるやつ）って結構厳しめだな。unlimitでないのはこんな感じ。
bash-5.2$ ulimit -a |grep -v unlimited
data seg size (kbytes, -d) 1048576
max locked memory (kbytes, -l) 87381
max memory size (kbytes, -m) 978512
open files (-n) 512
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 4096
max user processes (-u) 128
virtual memory (kbytes, -v) 1052672
bash-5.2$

@trondd looks no problem...?

openbsd-current-vm$ df -i
Filesystem 512-blocks Used Avail Capacity iused ifree %iused Mounted on
/dev/sd0a 146237396 30294360 108631168 22% 1068616 8392182 12% /
openbsd-current-vm$