今年後半に発表されるというWindows11ですが、実行要件としてTPM(Trusted Platform Module)2.0が必須となるようです。
これはCPUに搭載された機能のようですが、別途ハードウェアモジュールとしても提供されるようです。うちではAsrockのマザーボードを使用しており、メインは Core i9-9900K を搭載した Asrock Z390 Extreme4 ですが、これはBIOSで対応しているようです。一方、サブとして使っているのは Core i7-4990K の Z97 Extreme4 で、こちらはTPM2.0に対応していません。
Windows11がサポートしているIntelのCPUはこちら、AMDのCPUはこちらにリストがあります。
これだと4990Kのサブ機は非対応ということになるのですが、AsrockからはハードウェアTPMモジュールが提供されているようです。チップ製造元はNuvotonやInfineonとなっています。こちらのものはマザーボード上のTPMヘッダーに装着して使用するようですが、Z97 Extreme4にもTPMヘッダーは実装されています。また、TPM-SPIというモジュールもあるようで、こちらは非常に小型です。SPIインタフェースというのが気になりますが、対応マザーボードリストも掲示されていません。さらには暗号化の輸出規制の関係か、販売される国が限定されているようです。
TPM-sモジュールについては、過去にAmazonで1500円程度で販売されていたこともあるようですから、市場に流れてくれば買いやすい値段になるかもしれません。現状では2~3万円しているようですから、様子見ですね。
さて、TPM2.0は9900Kではサポートしているということで、BIOSの設定を見ると、右の方に項目がありました。"Security"タブの一番下の項目が "Intel(R) Platform Trust Technology"で、デフォルトでは"Disabled"されています。
この状態では TPM.msc の画面は以下のようになっています。
これを"Enabled"にして再起動してみると、以下のように変わります。
使い方はわからないし、とりあえずユーザがいじるものではない、みたいな記述もあるのでとりあえずここまでにしておきます。
pyls_msがなくなった。
deopleteのソースをJediからLSPに変更する。で、Microsoft Python Language ServerをNeovimから使えるようにしてみたんだけれど、
え、もしや、と思って検索すると、https://github.com/neovim/nvim-lspconfig/issues/1073で、Python3で使っていると Error 134を出してクラッシュする、というようなことが書いてあります。
それに対して、pyls_msはpylance/pyrightに引き継がれていてMicrosoftはメンテナンスを放棄しているので、pyrightかpylspに切り替えることを推奨します、とのこと。
pylspことPython LSP ServerはJediをエンジンとして利用しているので、せっかくJediを離れてpyls_msにしたのにまた戻ることになります。補完速度的にも若干遅い気がしますし。
pyrightはpyls_msと同じMicrosoftから提供されていますが、使用するためにはNode.jsを別途インストールする必要があるようです。
仕方ないので、Node.jsの現行推奨版である14.17.3-x64 LTSをインストールします。ただ、Chocolateyを含むビルドツールも必要に応じてインストールする、というオプションはチェックをしないでおきます。PythonもVisual Studio 2019もインストールしてあるし。
インストールが終了したら、新規にコマンドプロンプトを開いて動作を確認します。
それはさておき。
Neovim側では、これまで使用していたpyls_msの設定を削除して、pyrightの設定をdein.tomlに追加します。
dein.tomlを保存してからNeovimを起動し直すと、こころなしかpyls_msのときよりも起動が早いようです。遅延発火(lazy)はしていないので、これはNode.jsをインストールしてまで導入したかいがあったかもしれません。
:call dein#update()してみたら、エラーが出てしまいました。:messageしてみると以下のような出力が。
[dein] Error occurred while executing hook: nvim-lspconfig [dein] Vim(lua):E5108: Error executing lua [string ":lua"]:3: attempt to index field 'pyls_ms' (a nil value)Lua が pyls_ms を読み込もうとしたんだけれど値が nil でした、ってことです。
え、もしや、と思って検索すると、https://github.com/neovim/nvim-lspconfig/issues/1073で、Python3で使っていると Error 134を出してクラッシュする、というようなことが書いてあります。
それに対して、pyls_msはpylance/pyrightに引き継がれていてMicrosoftはメンテナンスを放棄しているので、pyrightかpylspに切り替えることを推奨します、とのこと。
pyls_ms is borderline abandoned by microsoft (in favor of pylance/pyright), I would recommend switching to pyright or pylsp (`pyls is also abandoned) I'll probably remove pyls_ms shortly. It's not a bug in the built-in client (which this repo is not, this repo is just the basic settings we send to the language servers), it's likely a bug in pyls_ms that will never be fixedということで、pyls_ms.luaはすでに削除されてしまっていたのでした。実際、たしかに時々LSPによる補完が効かないことがあって、なんでかなぁと思ったり、NeovimはおろかChromeとか起動しているすべてのアプリを巻き込んでクラッシュしたりということもあったので、潮時なのかもしれません。ということで候補なのですが…。
pylspことPython LSP ServerはJediをエンジンとして利用しているので、せっかくJediを離れてpyls_msにしたのにまた戻ることになります。補完速度的にも若干遅い気がしますし。
pyrightはpyls_msと同じMicrosoftから提供されていますが、使用するためにはNode.jsを別途インストールする必要があるようです。
仕方ないので、Node.jsの現行推奨版である14.17.3-x64 LTSをインストールします。ただ、Chocolateyを含むビルドツールも必要に応じてインストールする、というオプションはチェックをしないでおきます。PythonもVisual Studio 2019もインストールしてあるし。
インストールが終了したら、新規にコマンドプロンプトを開いて動作を確認します。
C:\Users\kats$ node --version v14.17.3 C:\Users\kats$ npm --version 6.14.13動くようなのでpyrightをインストールします。
C:\Users\kats$ npm install -g pyright C:\Users\kats\AppData\Roaming\npm\pyright -> C:\Users\kats\AppData\Roaming\npm\node_modules\pyright\index.js C:\Users\kats\AppData\Roaming\npm\pyright-langserver -> C:\Users\kats\AppData\Roaming\npm\node_modules\pyright\langserver.index.js + pyright@1.1.158 added 1 package from 1 contributor in 1.015spyrightを起動してみると、
C:\Users\kats$ pyright No configuration file found. No pyproject.toml file found. stubPath C:\Users\kats\typings is not a valid directory. Assuming Python platform Windows Searching for source files Auto-excluding C:\Users\kats\.cache\dein\.cache\init.vim\.dein\test\test-files\python\with_virtualenv\env Auto-excluding C:\Users\kats\.cache\dein\repos\github.com\dense-analysis\ale\test\test-files\python\with_virtualenv\env Skipping recursive symlink "C:\Users\kats\AppData\Local\Application Data" -> "C:\Users\kats\AppData\Local" Skipping broken link "C:\Users\kats\AppData\Local\ElevatedDiagnostics" Auto-excluding C:\Users\kats\Projects\JupyterLab Auto-excluding C:\Users\kats\work Found 11346 source files Emptying type cache to avoid heap overflow. Heap size used: 1537MB Emptying type cache to avoid heap overflow. Heap size used: 1823MB Emptying type cache to avoid heap overflow. Heap size used: 2108MB Emptying type cache to avoid heap overflow. Heap size used: 2381MB Emptying type cache to avoid heap overflow. Heap size used: 1538MB Emptying type cache to avoid heap overflow. Heap size used: 1734MBなにやらカレントディレクトリ以下のすべての*.pyファイルを検索してキャッシュしているようです。
それはさておき。
Neovim側では、これまで使用していたpyls_msの設定を削除して、pyrightの設定をdein.tomlに追加します。
nvim_lsp.pyright.setup{
}
ここに記入する設定は、CONFIG.md#pyrightに説明されています。が、基本的にはパスさえ通っていれば特に設定の必要はなさそうです。
dein.tomlを保存してからNeovimを起動し直すと、こころなしかpyls_msのときよりも起動が早いようです。遅延発火(lazy)はしていないので、これはNode.jsをインストールしてまで導入したかいがあったかもしれません。
日本語検索を「かな漢字変換」を通さずにやる。その3
日本語検索を「かな漢字変換」を通さずにやる。その2を受けて…。
検索文字列に "class" を指定したのに "分類" などが引っかかってくる(かつ "クラス" などが含まれない)と、「一体何でキミはここにいるのかね?」な状況になって困惑してしまいます。そこで、"ripgrep" や "The Platinum Searcher" の出力のように、マッチした文字列をエスケープシーケンスで強調するようにしてみました。
こんな感じです。
例にしてあげるとこんな感じ。
引数の
ところがこれをコマンドプロンプトでやると、指定したエスケープシーケンスが文字のママ出力されてしまい、一層困惑することになります。
そこでPython Windows10 において Console 出力に色を付けるを参考にコマンドプロンプトをVT互換のエスケープシーケンスを処理するように設定することで、一致した文字列を強調できるようになりました。Microsoftによる日本語の解説はコンソールの仮想ターミナル シーケンスにあります。
自画自賛なんですがめちゃくちゃ便利。
検索文字列に "class" を指定したのに "分類" などが引っかかってくる(かつ "クラス" などが含まれない)と、「一体何でキミはここにいるのかね?」な状況になって困惑してしまいます。そこで、"ripgrep" や "The Platinum Searcher" の出力のように、マッチした文字列をエスケープシーケンスで強調するようにしてみました。
こんな感じです。
BRIGHT_RED = "\033[91m"
BRIGHT_GREEN = "\033[92m"
BRIGHT_YELLOW = "\033[93m"
BRIGHT_BLUE = "\033[94m"
BRIGHT_MAGENTA = "\033[95m"
BRIGHT_CYAN = "\033[96m"
BRIGHT_WHITE = "\033[97m"
DEFAULT = "\033[39m"
def search_in_lsr(pat, dirs):
"""search pat in ls-R files"""
for target in dirs:
logger.debug("finding in %s", target)
try:
with open(target + "/ls-R", "r", encoding="utf-8") as f:
lines = f.readlines()
for line in lines:
if res := pat.search(line):
line = pat.sub(BRIGHT_CYAN + res.group() + DEFAULT, line)
print(target + line, end="")
except FileNotFoundError as e:
print(e)
print(f'run "mp4lsr.py {target}" to generate ls-R files.')
sys.exit(1)
ファイル名のリストは、mktexlsrの作成する "ls-R" ファイルのように、「このディレクトリ以下のファイルリスト」という形で、いくつかのディレクトリに散らばっています。
例にしてあげるとこんな感じ。
M: -+- 自然科学 -+- 物理学
| +- 化学
| +- ・・・
| +- ls-R
|
+- 文化芸術 -+- 音楽 -+- クラシック
| +- 雅楽
| +- 民謡
| +- ・・・
| +- ls-R
+- 美術
+- ・・・
言ってみれば、ジャンルごとにそのディレクトリツリーの "ls-R" ファイルを作成するわけです。
引数の
patはCMigemoが出力してきた正規表現をre.compileした正規表現オブジェクト、dirsは "ls-R" が置いてあるディレクトリのリストです。
pat.search(line)がNullでなければ、マッチした文字列をすべてエスケープシーケンスで囲むように置換する、という処理をしています。
ところがこれをコマンドプロンプトでやると、指定したエスケープシーケンスが文字のママ出力されてしまい、一層困惑することになります。
そこでPython Windows10 において Console 出力に色を付けるを参考にコマンドプロンプトをVT互換のエスケープシーケンスを処理するように設定することで、一致した文字列を強調できるようになりました。Microsoftによる日本語の解説はコンソールの仮想ターミナル シーケンスにあります。
自画自賛なんですがめちゃくちゃ便利。
日本語検索を「かな漢字変換」を通さずにやる。その2
それではPythonからC/Migemoを使ってみます。
CMigemo.exeの出力をsubprocessで取り込んで使おうかと思ったのですが、出力形式がVimスタイルやEmacsスタイルはあっても、今ひとつPythonのreに丁度いいような形ではなくてうまく引っかかってこなかったので、なにかないかとぐぐってみるとcmigemo 0.1.6というパッケージがありました。ctypesを使ってmigemo.dllをロードするようです。
CMigemo.exeの出力をsubprocessで取り込んで使おうかと思ったのですが、出力形式がVimスタイルやEmacsスタイルはあっても、今ひとつPythonのreに丁度いいような形ではなくてうまく引っかかってこなかったので、なにかないかとぐぐってみるとcmigemo 0.1.6というパッケージがありました。ctypesを使ってmigemo.dllをロードするようです。
Githubのプロジェクトページはこちら。moozさんという方が作られたようです。
ということで早速これを
pip install python-cmigemoして、組み込んでみました。
import cmigemo
migemo_dict = "c:/Apps/bin/dict/base-dict"
def compile_pattern(S):
"""return compiled pattern"""
logger.debug(S)
migemo = cmigemo.Migemo(migemo_dict)
ret = migemo.query(S)
logger.debug("regex=%s", ret)
return re.compile(ret, re.IGNORECASE)
なのですが、どうにもmigemo.dllをロードしてくれません。
ソースを追いかけてみると、
def _load_libmigemo(self, lib_name="migemo"):
import platform
if platform.system() == u"Windows":
libmigemo = windll.migemo
のところでエラーになっています。ということで、この部分を
def _load_libmigemo(self, lib_name="migemo"):
import platform
if platform.system() == u"Windows":
libmigemo = windll.LoadLibrary(find_library("migemo"))
として、find_library()に探させてみたら、migemo.dllをPATHの通ったところに置いておけば見つけてくれるようです。これで、C/Migemoが出力してきた正規表現を検索パターンにして
re.compile()してやればいろいろとできそうです。でもって結果ですが…。
もちろん辞書にもよると思いますが、思った以上に強力です。
"class" で検索をかけると、"Class" や "クラス" はもちろんのこと、"クラシック" とか "分類" などまでも引っかかってきます。検索時に
re.IGNORECASEを指定してやると、"CLASS" も "class" も "ClaSS" も引っかかってくるし、日本語もちゃんと受け取って、その場合にはちゃんと日本語での検索結果が上がってきます。 これは思った以上に快適です。Pythonのshutil.copyが異常に遅い件。
前から気付いていて、Pythonも3.9になったので改善しているかしら?と試してみましたがやっぱり未だに異常に遅いようです。
すべて1GBのファイルを別のSSDドライブに10回コピーしたのに要した時間です。圧倒的にsubprocessが早いです。
1のsubprocessは、
2はshutil.copyfile()、3はコピー先にファイルを、4はコピー先にディレクトリを指定したshutil.copy()です。
5、6、7はそれぞれ、buffer_sizeに16MB、128MB、-1を指定したshutil.copyfileobj()です。-1の場合にはファイルを一度に全部読み込むだけのバッファを確保する、という説明がありましたので、計測してみました。
8と9は、Faster Python File CopyにあるcopyFile()を使用してみました。処理手的にはshutil.copyfileobj()を使っていますので、5と同程度になります。
Linuxなどの場合にはここまでの差は出ないようで、ほとんど1と同じ時間だということですが、shutil.copy()は"cmd /c copy"の約20倍の時間がかかっています。本来ならば外部コマンドを呼び出すオーバーヘッドなどを考えると、subprocessのほうが遅いはずなのですが、ことWindows上での大きいファイルのコピーに関してはsubprocessに軍配が上がるようです。
なぜかこれはWindowsプラットフォームだけのようですが。
1GBのファイルをSSDの2台のドライブの間でコピーする速度を計測してみました。
| 1 | Subprocess copy to dir | 0.3177815 |
|---|---|---|
| 2 | shutil.copyfile | 5.799549600000001 |
| 3 | shutil.copy to dir | 6.2538441 |
| 4 | shutil.copy to file | 5.642608300000001 |
| 5 | shutil.copyfileobj (16MB) | 9.0621711 |
| 6 | shutil.copyfileobj (128MB) | 20.3517843 |
| 7 | shutil.copyfileobj (-1) | 21.7088837 |
| 8 | copyFile to file (default) | 9.210321199999996 |
| 9 | copyFile to file (16MB) | 8.914450500000001 |
for i in range(10):
subprocess.run('cmd /c copy "{0}" {1} > nul'.format(fname, dest_dir), check=False)
というコードです。2はshutil.copyfile()、3はコピー先にファイルを、4はコピー先にディレクトリを指定したshutil.copy()です。
5、6、7はそれぞれ、buffer_sizeに16MB、128MB、-1を指定したshutil.copyfileobj()です。-1の場合にはファイルを一度に全部読み込むだけのバッファを確保する、という説明がありましたので、計測してみました。
8と9は、Faster Python File CopyにあるcopyFile()を使用してみました。処理手的にはshutil.copyfileobj()を使っていますので、5と同程度になります。
Linuxなどの場合にはここまでの差は出ないようで、ほとんど1と同じ時間だということですが、shutil.copy()は"cmd /c copy"の約20倍の時間がかかっています。本来ならば外部コマンドを呼び出すオーバーヘッドなどを考えると、subprocessのほうが遅いはずなのですが、ことWindows上での大きいファイルのコピーに関してはsubprocessに軍配が上がるようです。
追記(2022年6月26日):
前から気づいてたんですが、ここに書いてなかったので追記しておきます。
Changed in version 3.8: Platform-specific fast-copy syscalls may be used internally in order to copy the file more efficiently. See Platform-dependent efficient copy operations section.
https://docs.python.org/3/library/shutil.htmlに記載されてますが、Python 3.8からコピーが劇的に速くなっています。
日本語検索を「かな漢字変換」を通さずにやる。
ローカルなライブラリの検索で、日本語ファイル名が数千になってきているのです。
そうなるとあいうえお順で(というかエクスプローラーの一覧から)目視で探すのは限界だし、ディレクトリツリーを順番に見ていくのも大変なので、
検索文字列はreモジュールで正規表現検索するので、一部だけでも適当に検索してくれます。ものすごく便利で自画自賛なんですが、検索したいファイル名(の一部)を入力するときにいちいち「かな漢字変換」をオン・オフするのは面倒だな、と思って、そういえばローマ字入力で日本語文書を検索できるヤツがあったな、と思い出し……。
NamazuじゃなくてKakasiじゃなくてMeCabじゃなくてなんだっけ……とグーグル先生にお尋ねして。
名前が思い出せなかったので、そういえばVimを2chブラウザにするヤツを作っていた人がいて、その人がなんかやってたような、なんだっけ、としばらく考えて検索して、"Chalice"をようやく思い出して。そこから "Migemo" にやっとたどり着きました。
Migemo自体はRubyで記述されているようで、かつすでにメンテされていないようです。もったいない。でも自分はRubyはわからないので、KaoriYaのKoronさんがCに移植されたC/Migemoを見てみようか、と。
Cで実装されてDLLにされているなら、Pythonから呼び出すのもできそうだし、Neovimにも組み込むことができそうです。まあ、後者は追々というとこで、とりあえずPythonから呼び出してローマ字で日本語検索!をやれれば楽ができるかなということで、ぼちぼちいじってみようと思います。
C/MigemoはGitHubで公開されていましたので、これをクローンして作業開始です。
README_j.txtには以下のようにVisualC++でのビルド方法が書かれています。
幸い
そのままF6キーでビルドすると、
ぐぐってみると、
お次は辞書ファイルの生成ですが、Makefileを追いかけるとnkfではなくiconvやqkcを使っていました。qkcは今どうしてるんだろう…。
それはさておき。
現状ではnkfを使っているので、nmakeと同じことをコマンドプロンプトからそのままやりました。
早速テストしてみます。cmigemoディレクトリに移動して、
これは結構使えるのでは……。 辞書の指定とかエンコードとか出力形式とかはどうなんだろうと見てみると、
そうなるとあいうえお順で(というかエクスプローラーの一覧から)目視で探すのは限界だし、ディレクトリツリーを順番に見ていくのも大変なので、
mktexlsrのようにファイル名のデータベースを作っておいてそのデータベースから探すのが早そう、ということでPythonでls-R作成スクリプトと検索スクリプトを作りました。検索文字列はreモジュールで正規表現検索するので、一部だけでも適当に検索してくれます。ものすごく便利で自画自賛なんですが、検索したいファイル名(の一部)を入力するときにいちいち「かな漢字変換」をオン・オフするのは面倒だな、と思って、そういえばローマ字入力で日本語文書を検索できるヤツがあったな、と思い出し……。
NamazuじゃなくてKakasiじゃなくてMeCabじゃなくてなんだっけ……とグーグル先生にお尋ねして。
名前が思い出せなかったので、そういえばVimを2chブラウザにするヤツを作っていた人がいて、その人がなんかやってたような、なんだっけ、としばらく考えて検索して、"Chalice"をようやく思い出して。そこから "Migemo" にやっとたどり着きました。
Migemo自体はRubyで記述されているようで、かつすでにメンテされていないようです。もったいない。でも自分はRubyはわからないので、KaoriYaのKoronさんがCに移植されたC/Migemoを見てみようか、と。
Cで実装されてDLLにされているなら、Pythonから呼び出すのもできそうだし、Neovimにも組み込むことができそうです。まあ、後者は追々というとこで、とりあえずPythonから呼び出してローマ字で日本語検索!をやれれば楽ができるかなということで、ぼちぼちいじってみようと思います。
C/MigemoはGitHubで公開されていましたので、これをクローンして作業開始です。
README_j.txtには以下のようにVisualC++でのビルド方法が書かれています。
(Windows + VisualC++)
次のコマンドでRelease/内にmigemo.dllとcmigemo.exeが作成されます。
> nmake msvc
必要な外部プログラム、ネットワーク接続が揃っていれば
> nmake msvc-dict
で辞書ファイルをビルドできます。migemo.dswをVC++6.0で開き、ビルドする方法も
あります。以上が終了すれば次のコマンドでテストプログラムが動作します。
> .\build\cmigemo -d dict/migemo-dict
現在の環境はVisualC++を含んだVisualStudio 2019なので、そのままビルドと思いきややっぱりエラーが出ました。幸い
\compile\vs2003に.slnファイルがあったので、それをVS2019で開くとそのままソリューションを変換してくれて一応プロジェクトは開けました。そのままF6キーでビルドすると、
"afxres.h"がインクルードできない、というエラーが出てビルドできません。ぐぐってみると、
"winres.h"に書き換えるといいよ、ということだったので仰せに従い無事ビルド終了。ついでにプロジェクトにx64ビルドも追加してこちらもビルド。一応どちらもDebugビルドにしておきました。お次は辞書ファイルの生成ですが、Makefileを追いかけるとnkfではなくiconvやqkcを使っていました。qkcは今どうしてるんだろう…。
それはさておき。
現状ではnkfを使っているので、nmakeと同じことをコマンドプロンプトからそのままやりました。
dictディレクトリで、$ for %i in (base-dict,SKK-JISYO.L,*.dat) do ( More? nkf -w %i > utf-8.d\%i More? ) $ for %i in (base-dict,SKK-JISYO.L,*.dat) do ( More? nkf -e %i > euc-jp.d\%i More? )で辞書の文字コード変換は終了。
早速テストしてみます。cmigemoディレクトリに移動して、
$ compile\vs2003\x64\Debug\CMigemo.exe
migemo_open("./dict/migemo-dict")=000002AB8059C640
clock()=0.128000
QUERY: aho
PATTERN: (アホ|アホ|信天翁|阿[房呆]|あほ|aho|aho)
QUERY: clean
PATTERN: (clean|ク(レン(ザー|ジング)|リ(ンナップ|ー(ン|ナー|ニング)))|c(ェア[ンノネヌニナ]|ェア[ンノネヌニナ]|ぇあ[んのねぬにな]|lean))
QUERY: nihongo
PATTERN: (ニホンゴ|ニホンゴ|日本(語|極道史|合成ゴム)|にほんご|nihongo|nihongo)
QUERY: 日本語
PATTERN: 日本語
QUERY:
QUERY:
おお、返り値がそのまま正規表現として利用できるようなパターンになっています。なにげに信天翁(アホウドリ)が混じっているのが点数高いです。そして、かな漢字変換で日本語を食わせるとそのまま返ってきます。これは結構使えるのでは……。 辞書の指定とかエンコードとか出力形式とかはどうなんだろうと見てみると、
$ compile\vs2003\x64\Debug\CMigemo.exe -h cmigemo - C/Migemo Library 1.3 Driver USAGE: compile\vs2003\x64\Debug\CMigemo.exe [OPTIONS] OPTIONS: -d --dict <dict> Use a file <dict> for dictionary. -s --subdict <dict> Sub dictionary files. (MAX 8 times) -q --quiet Show no message except results. -v --vim Use vim style regexp. -e --emacs Use emacs style regexp. -n --nonewline Don't use newline match. -w --word <word> Expand a <word> and soon exit. -h --help Show this message.また、辞書を指定するとそのエンコードで結果が返ってくるようです。
$ compile\vs2003\x64\Debug\CMigemo.exe -w aho (アホ|アホ|信天翁|阿[房呆]|あほ|aho|aho) $ compile\vs2003\x64\Debug\CMigemo.exe -d dict\utf-8.d\base-dict -w aho (繧「繝斈菫。螟ゥ鄙-髦ソ[謌ソ蜻・|縺ゅ⊇|・・ス茨ス楯aho) $ compile\vs2003\x64\Debug\CMigemo.exe -d dict\utf-8.d\base-dict -w aho | nkf -s (アホ|信天翁|阿[房呆]|あほ|aho|aho) $ compile\vs2003\x64\Debug\CMigemo.exe -d dict\euc-jp.d\base-dict -w aho (・「・ロ|ソョナキイァ|ー、[ヒシハ|、「、ロ|」皀陬・aho) $ compile\vs2003\x64\Debug\CMigemo.exe -d dict\euc-jp.d\base-dict -w aho | nkf -s (アホ|信天翁|阿[房呆]|あほ|aho|aho)受け取り側に都合のよいエンコードの辞書を使えば良さそうです。
pipじゃなくてpacmanを使う。
ArchLinux系ではパッケージマネージャのpacmanを使いますが、Pythonの外部モジュールをインストールするときには
回答はいつも明確で、システムワイドで使うなら
ところがそういう方針でやっていても、ついうっかり
出力で先頭に'local'が付いてるのは、
pipを使うのかpacmanを使うのか、どっちがいいのか、という質問がいろいろなフォーラムでたびたび出てきます。 回答はいつも明確で、システムワイドで使うなら
pacmanを使え、pipを使うなら'--user' オプションを必ず指定しろ、venvなどの仮想環境で使うならpipを使え、です。ところがそういう方針でやっていても、ついうっかり
pip使っちゃったりすることもあります。
ということで、あるモジュールをインストールしたのがpipなのかpacmanなのかを表示するための1ライナーです。
$ for i in `pip list | tail -n +3 | awk '{print $1}'`; do pacman -Qs $i ; done
local/python-appdirs 1.4.4-3
A small Python module for determining appropriate platform-specific dirs, e.g. a "user data dir".
local/python-black 21.6b0-3
Uncompromising Python code formatter
local/python-cachecontrol 0.12.6-3
httplib2 caching for requests
pacmanでローカルにインストールされてますよ、ということです。
めでたしめでたし。
登録:
投稿 (Atom)
SWDなら3線でいいとはいうものの。
安価で優秀なデバッグプローブはないかしら、と探したら、 Raspberry Pi Debug Probe というのがあったんですが、これは3線がにゅるんと出てるだけです。 もちろんSWDなら3線を繋げばいいのではありますが、汎用的に考えるなら5x2のリボンケーブルコネクタが欲し...
-
ノートPCでMP4動画を再生するのに、VLCメディアプレーヤーは使いやすいし何も設定しなくてもインストールしただけで使えるので便利ですが、画質・再生品質的には今一つの印象があります。印象なので、ここから先は単なる自己満足の世界で、定量的な評価などはありません。動画を見ていて、再生...
-
年明け早々あれですが。 昨年末から、うちのLIXILのシャワートイレの電源ランプが、チカチカと鬱陶しい点滅を始めました。型番はDV-E116Hで2015年製。LIXILの取説では点検サービスを受けてくださいと書いてあり、この電源ランプの点滅をやめさせる方法はありません。ちなみに出...
-
現在のメインPCはCore i9-9900Kなので、すでにWindows11にアップグレード済なのですが、以前使っていた2台のPCはどちらもCore i7-4790Kで、Windows11の対象外になってしまっています。 2015年に購入したものですが、4790Kは今でも十分に...

