possibly maybel...
possibly maybel...
ClamAV 1.0.0 Release candiate available
https://blog.clamav.net/2022/10/clamav-100-release-candidate-now.html
ClamAV というフリーのアンチウィルスソフトがついに バージョン 1.0.0 RC に到達したとのこと。それまでは 0.100.x のようなバージョンになっていたのでもう1.0.0 にはいかないのかなと個人的には考えていた。
Linux intel 486 プロセッサのサポートを止めるって
https://www.phoronix.com/news/Intel-i486-Linux-Possible-Drop
Linus が 486 プロセッサのサポートをとめるといいだしたとのこと。まだサポートされていたんだ。すごいな。
Bug was fixed !
Bug was fixed !
昨日報告した指摘は修正されたもよう
Libreoffice 7.4.2 MacOSX Language pack does not recognize on intel mac は解決した模様。よかった。よかった。
Is LibreOffice_7.4.2_MacOS_x86-64_langpack_ja.dmg broken ?
Is LibreOffice_7.4.2_MacOS_x86-64_langpack_ja.dmg broken ?
- LibreOffice の 7.4.2 がリリースされたときいて intel macOS でやってみた。
LibreOffice の 7.4.2 がリリースされたときいたので intel macOS でインストールしてみたらうまくいかなかった。
正確には、 LibreOffice 7.4.2 を intel Macにインストールすることはできた。問題は翻訳されたユーザーインターフェースの日本語の dmg ファイルがうまくいかない。
LibreOffice_7.4.2_MacOS_x86-64_langpack_ja.dmg をダウンロードしてみるもののダブルクリックするとmacOSが「接続したディスクは、このコンピュータで読み取れないディスクでした。」と表示してしまう。
このときの選択肢は3つ。
- 取り出す
- 無視
- 初期化...
どれを得らんでもマウントされないので、インターフェースを日本語にできない。
以前の 7.3 系の翻訳されたユーザーインターフェースの日本語のdmgファイルは開くことができたので、7.4.2 の方が間違っているんじゃないのかなと思っている。
とりあえずバグ報告した。そして英語インターフェースの LibreOffice が残された。
iOS16 and macOS Monterey 12.6
iOS 16 and macOS Monterey 12.6
macOS 12.6 へ更新
intel macのmac Book には更新が来ていたので、適用して、macOS 12.6 に更新してみた。
macOS に更新した。そうすると、なぜか Emacs 29.50.0 が起動時にエラーがでてしまうようになった。
エラーを見て、それから
それでもEmacs 29.50.0 でエラーがでるので別のバージョンのEmacsを起動してみた。だめだった。
しかたがないので、
sudo port install emacs-app-devel -nativecomp
してみた。ワーニングがでるので、ダメかなと思ったんだけど無事に起動した。
Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled: re_search: found in emacs-20220907/config.log re_compile_pattern: found in emacs-20220907/config.log re_set_syntax: found in emacs-20220907/config.log MIN: found in emacs-20220907/config.log malloc: found in emacs-20220907/config.log __fpending: found in emacs-20220907/config.log
というわけで、Emacs の hatena-blog-writer でブログを更新した。
ジャンプの紙質
週刊少年ジャンプの紙変ったのかやけにつるつるしている気がするけどなんなんだろう。前からなんだろうか。
Cookie Clickerで Hand-made coockies: 1.16e+55 に到達した
777倍のときに666倍が出たので、一気に増えた。 マジでこれ以上あがるの？という気がした。
開始11日でCookies baked(this ascension): 2.42e+55 は何かがおかしいとしか思えない。
merge --allow-unrelated-histories
merge --allow-unrelated-histories
自分たちの local の git に OSS のソースコードだけをtarball だけ持ちこんで開発しておいてあとから、やっぱり、オリジナルのgitの履歴も見たいっていいだすのってあるあるですよね
ないよそんなこと、あったらこんな記事書かないよ
git ってあとからそんな 馬鹿な ことできるんですよ、そう merge --allow-unreleated-historiesを使えばね
TLDR;
git checkout -b remote-xxxx-yyy $(git log --pretty=%H | tail -1) git merge --allow-unrelated-histories remotes/xxxx/yyyy
やり方
まず最初に、ローカル環境にある開発中のリポジトリに オリジナルの git を登録します
<original-oss-url> は オリジナルのgitリポジトリのURLで、xxxx は適当な名前、例えば base でもいいです
git remote add xxxx <original-oss-url>
それから、xxxx の情報をfetchで取得してからリモートも含めてブランチを全部表示させます。そこで git のログを取得したいブランチを探します。例えば、remotes/xxxx/main のような名前のはずです。
git fetch xxxx git branch -a
そこで、安全のために今の開発リポジトリの一番古い HASH $(git log --pretty=%H | tail -1) から適当な名前のブランチを追加させてそこに 先程選んだ ブランチをマージしましょう。ここで --allow-unrelated-histories は履歴関係のないもののマージを許可させるという意味です。
git checkout -b remote-xxxx-yyy $(git log --pretty=%H | tail -1) git merge --allow-unrelated-histories remotes/xxxx/yyyy
あとは、git log --graph でも行なって確認してみましょう。
そう、あとはこんなことをしなくて済むように最初からltarball でソースコードを持ち込むなんてことはしないようにお願いします。
Pythonが速度改善に本気を出すと聞いたので恒例のたらい回しベンチをとるらしいから、Common Lisp(Clozure CL)でチャレンジしたら爆速な話
Python が速度改善に本気を出すと聞いたので恒例のたらい回しベンチをとるらしいから、Common Lisp(Clozure CL)でチャレンジしたら爆速な話
この記事はジョーク記事です。
Pythonが速度改善に本気出すと聞いたので恒例のたらい回しベンチをとってみたら、RubyがYJITですごく速くなっていて驚いた話 に Common Lisp がなかったのでClozure CLで勝手にエントリーしてみる。
なお、Mac Book Pro 2020 13inch というとりたてて普通のIntel Macである。
たらい回し関数 はこれでいこう。本来なら 最適化をしてもよいが いけるだろう。
(defun tak (x y z) (if (<= x y) y (tak (tak (1- x) y z) (tak (1- y) z x) (tak (1- z) x y))))
さて実行して計測してみよう。
ほら、たったの 3 マイクロ秒で完了である。やったね。C言語が1秒だからむっちゃ早い。Common Lisp は神の言語である。たらい回し関数なんか普通に最適化されてしまうのである。さあ、神の速度のCommon Lisp を使おうじゃないか。
CL-USER> (time #.(tak 14 7 0))
14
took 3 microseconds (0.000003 seconds) to run.
During that period, and with 8 available CPU cores,
6 microseconds (0.000006 seconds) were spent in user mode
5 microseconds (0.000005 seconds) were spent in system mode
14
種あかし。
賢明な読者はとっくに気がついているだろう、(time (tak 14 7 0)) ではないことに。そうなんである。実際には1.5秒かかっているのであった。
CL-USER> (time (tak 14 7 0))
(TAK 14 7 0)
took 1,515,945 microseconds (1.515945 seconds) to run.
During that period, and with 8 available CPU cores,
1,470,043 microseconds (1.470043 seconds) were spent in user mode
16,862 microseconds (0.016862 seconds) were spent in system mode
14
#. によって、(tak 14 7 0) が評価されたあとに(time <tak 14 7 0 の結果>) が評価されているのであった。 つまり (time 14)にかかる時間を測っていることになる。
