テレワーク。早めに終了。
調べ事をして終了。
テレワーク。気持ち早めに終了。
鳥人間コンテスト。70kmに18m足りず。もう70kmで良いくらい。
60kmから70kmルールになったとき、またすぐに足りなくなるんじゃないか?と思ったのですが
意外と壁が高くて絶妙な距離設定だったのかも。
ただ、「BIRDMAN HOUSE伊賀」の 渡邊氏は今大会で引退という事なので、しばらくは
70kmに到達するチームは出ないかも知れません。
因みに以前(13年くらい前)、人力飛行の世界記録ってどれくらい?
を調べてみたのですが、現在でも1988年に記録された「ダイダロス'88」の115.11kmが世界記録みたい
(人力飛行Wikipedia)。
飛行時間は約4時間で、パイロットは何食ってたんだ?!は今でも変わらない感想。
鳥人間コンテストで2.5時間のフライトでも身体的には大分苦しい所を見ていると なおさら疑問に感じます😅。
IMEパッチでのインライン変換表示のフォント。フレームパラメータの ime-font が
指定されていた時の振舞いがイマイチだったのを直してみたり。
結局 text-scale-adjust に関係無くサイズを補正する必要がありました。
という訳で普段使いでしばらくテストしてみよう。
テレワーク。早くもなく遅くもなく終了。
Emacsの text-scale-adjust(C-x C-+, C-x C--, C-x C-0)でそのバッファだけフォントサイズを変更できますが
どういう仕組みでやってるのだろう?というのを調べていました。
フォントサイズを変えると face-remapping-alist って変数が何かしら定義されるようで、
それに従ってフォントサイズを変更して表示するという仕組みらしい。
で、IMEパッチでインライン変換時のフォントサイズを text-scaleに連動させてみたり。
なんとなくイケた気も。
ここ最近、視力の都合でフォントを大きくしないと文字が見えないという場面があったので、
text-scale-adjustを多用するようになっていたのですが、フォントサイズ変更にインライン変換表示が
追従しないのが気になって来たので対応してみたという次第。
テレワーク。気持ち早めに終了。
調べ事。よく判らず。
AM中に起床。
掃除したり洗濯したり。
そういえば Edgeの新機能に 画面を左右に2分割して2つのタブを同時表示するってのが追加された
みたいなのですが、個人的には上下に2分割も出来ないかなぁ?とは思ったりも。
ところで、Chromiumがコードベースになっているとされているけど、Chromeと Edgeとでは
地味に違いが出ているように思ったりも。
AM中に起床。
これまで変える事の無かったEmacsのテーマですが、標準で入っているもの以外に 世の中には
かなり沢山あるというのを Emacs Themes ってサイトで知りました。
前述サイトからいくつかソースコードへのリンクを見てみた感じ10年近く前のものから最近のものまで
色々あるようです。歴史的にはEmacs24から標準テーマがプリインストールされるようになっていたようですが、
TANEが Cygwinの emacs-w32 を知った時(以前の日記)には
24.2とかだったので、既に備わっていた感じだったかも(当時は試したことは無かったと思います)。
実際どうだったっけ?を確認してみようと思ったのですが、Emacs24.3のemacs-w32として野良ビルドしたバイナリはあるものの、
libtiff5とか古いDLLが見つからなくて実行できず。再コンパイルを試してみたのですが、
何故かいくつかの型が不明な型名と怒られてビルドできず。
例えば pid_tが不明な型となっているのですが、#include_next を使われていてヘッダファイルの読み込み順が
なんだかよく判らなかったり。仕方ないので Emacs24.5 の方で再ビルドを試してみたのですが、
こちらは autogen.shがエラーするようになっていてビルド以前の問題でつっかかるようになっていたり。
辛い🥺
テレワーク。気持ち早めに終了。
新しいメガネになって2週間弱経ったのですが、普段使いのEmacsはダーク系テーマ&大き目フォントに
慣れてしまったので、以前使っていたデフォルトテーマ&フォントサイズに戻るのは困難になってきたと
感じたり😓。普段使いでは起動するとしばらく終了しないのもあって、起動時に毎回フォントサイズ
変更やテーマ選択操作を行なっていたのですが、段々面倒臭くなってきたので .emacsに設定にしてみました。
ただ、テスト起動の時は適用不要なので、
こちら
のような感じで環境変数指定とaliasで切り替え対応しています。
テレワーク。気持ち早めに終了。
Web巡回して終了。
テレワーク。気持ち早めに終了。
先日 Windows11のメモ帳は文字表示が結構イケるというのを知ったのですが、そういやEmacsの
M-x view-hello-file で表示される etc/HELLO ファイルはどうなるだろうと試してみたり。
Emacsで一通り表示可能なだけのフォントをインストールして、メモ帳で HELLOファイルを開いてみたところ、
一部のフォントは豆腐になったり表示がされなかったりするみたいです。
Noto系のフォントがうまくレンダリングできていないように思ったりも。
Windows11のメモ帳の文字表示をどうやって行なっているのかは判りませんが、
表示がされないフォントと文字列を、「フォント設定」でフォントを選んでプレビューで文字列を貼り付けると
ここでは表示できるようです。「フォント設定」と「メモ帳」とでは違う仕組みで表示されているのかも?
少し調べてみるとこちらの記事を
見つけました。RichEditコントロールとやらで描画されているらしいのですが、
「通常テキストはGDIで、GDIで対応できないカラー絵文字はDirectWriteで描画」とあります。
拙作のemacs-w32のカラー絵文字パッチも同じ感じなのですが、通常テキストはharfbuzzでの表示と
なるのが違いになるのかな?と思って「emacs-w32 -xrm Emacs.fontBackend:uniscribe」で
harfbuzzを使わないようにした結果と見比べてみたところ 似た感じになっているっぽい(厳密に同じではない)。
メモ帳も全ての文字をDirectWrite描画するようになれば 恐らくHELLOファイルは問題無く表示できるようになるのかも?
(編集の方はどうなるか判りませんが)
テレワーク。気持ち早めに終了。
昼間に数秒間の停電があり、スリープしてあったデスクトップPCの電源も落ちたのですが、
電源を入れるとスリープ復帰と同じように立ち上がって驚いた😅。
電源メニュー上はスリープと休止状態は違うもので、スリープ中に電源断になるとシャットダウンせずに
電源を切ったの(例えばコンセントを抜くとか、電源ボタン長押しで止めるとか)と同じだと思っていましたが、
そうではなくなっていたらしい。
因みにPS4は スタンバイ状態での電源断はやってはいけない操作なのでダメでした。てかこちらが普通。
そういえば、先日のアラビア語の unicode文字で変わったのがあるのを知ったのですが、
こちらのブログエントリに
他にも様々なunicode文字や合字の例が記されてました。Emacsではうまく表示できないものが結構沢山あります。
で、ふと Windows11のメモ帳はカラー絵文字もイケるようになっていましたが
(以前のメモ)、前述ブログに記されているような文字や絵文字はどうなるんだろう?
と思い試してみたところ 結構イケるように思ったり。ただし、「👩👩👩👩👩👩👩👩👩👩👩👩👩👩👩👩👩👩」
のような合字は一文字扱いでバラす事はできません。因みにEmacsではうまく合字で表示されません😢。
harfbuzzが頑張ってくれればイケるようになるのだろうか?
テレワーク。気持ち早めに終了。
Web巡回して終了。
AM中に起床。
掃除したり洗濯したり。
Web散策していて Meryというテキストエディタを知ったのですが
(参考)、
「等幅半角字形」なるものがあるのを知りました。
プロポーショナルフォントの中には等幅の字形が含まれているものがあり、
プロポーショナル字形の代わりに等幅字形を選択できるようにプログラムが対応すれば
等幅表示も可能になるらしい。DirectWriteではレンダリング対応されているらしいのですが、
検索してもプログラム的な記事はほとんど出てきません。
プロポーショナルフォントは等幅フォントとは分けるしかないと思っていたのですが
そうとも限らないらしい。ほぅ....
「﷽」っていうアラビア語の文字があるのを知ったり(参考)。
U+FDFDで1文字らしいのですが我が家のEmacsでは設定が悪いのか表示できませんでした。
ブラウザでは表示できるのですが どのフォントを使っているのかが判らず。
「꧁꧂」や「꧅」とかはイケたので、設定すればイケそうなのですが....
「Noto Sans Arabic」
のサンプル描画に前述「﷽」をブラウザからコピペしてみたら表示できそうだったので、
インストールした後フォントセットを設定してみたら表示できるようになりました。ただ、
文字がめっちゃ小さいです😅.....
ブラウザ表示ともまた違うので、同じ文字として解釈できるのかはよく判らず。
AM中に起床。
ノートPCにフォントを追加したり。Windows10の1809からユーザーローカルなフォルダに
インストールされるようになったので、その分だけを持って来れば良いな....と思ったのですが、
CC2は(時期的に)システムのフォントフォルダに全部入っててなんか面倒臭い感じになっていました😓。
ただ、フォントファイルのユーザ名がシステム標準とそれ以外とで違っていたので、
システム標準以外のものだけ選択してインストール。ついでにデスクトップPCに最近入れたフォントで
使えそうなものも追加でインストール。
ファイルエクスプローラで全選択してインストールすれば良いので楽になったもんです。
Web散策していて知った Razerの新しいキーボード
(参考)。
スイッチを交換できるようになっているのか。文字入力用途だとそうでもないような気はするのですが、
ゲーミング用途だと異常に打鍵率の高いキーもありそうなので、
交換やカスタマイズできる事にニーズはあるのかも?
AM中に起床。
Cygwin 3.4.xのメモリリーク調査。
Emacsの文字列オブジェクトの割り当てを行うコード読み。sdataの件はなんとなく解ったような気も。
すぐ忘れそうですが😓。
文字列は短いものと長いものとで処理が異なるのですが(以前のメモ)、
長さ判定の閾値を変えれば1バイト以上の文字列を長いと見なして処理する事ができそうで、
試してみるもプロセス増加の様子は変わらず。文字列が長い場合の処理は短い場合の処理よりも少し直感的で、
文字列オブジェクトに1:1で紐づく文字列データの実体は、必要な長さをmalloc()で確保してポインタで
紐づけられているだけで、文字列オブジェクトが不要になったらデータの実体は未参照として、
ガベージコレクト時にfree()されるという単純な仕組みでした。しかし、それでも様子が変わらなかったのでお手上げ。
どう考えてもどこかでメモリリークしていないとこうはならないと思うのだけどなぁ?🤔
とかやっているとCygwin 3.4.8-1てのがリリースされていたのですが、
メモリリークに関係するバグ修正が含まれているようだったので試してみたところ、
再現ELISPを実行してもプロセスサイズの増加は起こらなくなりました。
多分「Fix memory leak in printf() regarding gdtoa-based _ldtoa_r().」てのが影響していた
と考えられます。数値を文字列に変換するELISP関数では、内部的に snprintf()を使っていたりするのですが、
それが関係していたと思われます。何よりもprintf()を使っただけでバグを踏むようだったので、
デバッグでprintf()を使ってしまうと状況が変わるという難しいバグだったのかも。
てか、「SVG描画可能な野良ビルドemacs-w32 + 自作ELISPアプリ」でしか再現していない所が
スタート地点だったので、原因から最も遠い所から調べていた感じなのは なかなかの無理ゲーです😓。
ともあれ助かった。これでしばらくは普段使いに専念(?)できそうです。
今回のメモリリークを調べていて、メモリの使用状況をビットマップ的なもので見られたらなぁ?
とは思いました。使用中のメモリはmalloc()ライブラリの中では管理できているハズなので、
何かしらヒープの使用状況を表示する方法は無いものだろうか?と思います。
久しぶりに Emacsのmasterブランチをgit pullしたら何故か gitコマンドが Segfaultでコアダンプしたり。
仕方ないのでリポジトリ自体をcloneし直したら大丈夫そう。何か巨大な変更でも入ったのか?
と思ったところ Androidサポートのブランチがマージされている模様。
それが原因かどうかは判りませんが。てか Emacs30で入るの確定って事か。
一時期 emacs-develのML
(参考:emacs-devel Archives)
で何やら紛糾してっぽかったけど まとまったのかな?
AM中に起床。
Cygwin 3.4.xのメモリリーク調査。
Emacsの文字列オブジェクトの割り当てを行うコードをちゃんと読んでみようと思ったり。
まだ読んでいる最中ですが、「sdata」が訳判らんという感じになってます🥺。
C99仕様に フレキシブル配列メンバ(flexible array member)というものがあって、
sdataはそれを使っているのですが フレキシブル配列メンバーを持つ構造体を入れ子に
できないという理由から 別途「struct sdata」の定義もあり、読んでいると どっちをどう使うんだっけ?
みたいな感じになっています😓
メガネ待ちだったのですが、ノートPCと一緒に液晶タブレットも買ってあったのを開封。
「Wacom Cintiq Pro 16」を買ってみました。発売から少し経っているけどあんま安くなってはいなかったのですが
散財なのでヨシ!(何が?)。CC2と違って単体の液晶タブレットなのできっとしばらく使えるに違い無い。
さておき、SAI2でのスクラブズームの設定方法をすっかり忘れてしまっていて探し回ったのは秘密😓。
ノートPCと液晶タブレットが分離してしまったので、台に置ききれないという物理的な問題をどうしたもんか考え中。
映像出力はUSB Type-Cから取っているのですが、これとは別に電源を接続する必要があります。
電源も Type-Cから取れればPCとケーブル1本で接続できるのですが、分かっていたけどやっぱり惜しい感じはします。
因みに、今月発表された新製品の「Wacom One 液晶ペンタブレット」は Type-C 1本で繋げられるらしい。ほぅ...
AM中に起床。
昼頃時点で何やら東海道新幹線が運転見合わせしているらしい。朝時点では通常運行って感じ
みたいでしたが、静岡で大雨になっている模様。そんなに?
Cygwin 3.4.xのメモリリーク調査。
Emacsに仕込みを入れたりしながら観察してみたものの原因っぽいものは解らず、少し意図的に弄ってみたりしてみるも
状況を変える事もできず。
そういやとgmallocを使う事が可能か?と思いconfigureオプションを調べてみるも意図的に使用する事はできなさげ。
AM中に起床。
掃除したり。今日は室温的には冷房で調節できているのに湿度が高くて体感的に暑い。
Cygwin 3.4.xのメモリリーク調査。
CC2に入っていた Cygwin 3.3.4 + emacs-w32(27.2野良ビルド) で strace -m malloc ... が
どんな感じになっているのか見てみようとしたのですが、何故か strace が Segfaultして観察できず。
肝心なところで調査が阻まれるのは何故だ?🤔
うーん、やっぱりmalloc()を実行した時に新しいアドレスが払い出されている感じにも見えるなぁ...🤔
AM中に起床。
メガネが仕上がったとの連絡があり雨間を縫って引き取りに。
これまで両目が同時にピントが合うポイントが無かったのでストレスマックスだったのが
とても楽になった気も。しばらく様子見。
Cygwin 3.4.xのメモリリーク調査。
これまで straceコマンドを使っても 疑いどころが絞れていなかったので良し悪しが判断できなかったのですが、
再現ELISPコードが使えるようになったので、「strace -m malloc ...」を使ってCygwinの
malloc()/free()の状況を観察してみたり。
次のような感じで malloc()で返されたアドレスと free()に指定されたアドレスが判るので、
: 56 619920 [main] emacs-w32 12969 malloc: (1024) = 0xA00276CF0, called by 0x10054750E 50 619970 [main] emacs-w32 12969 free: (0xA00276CF0), called by 0x100645185 52 620022 [main] emacs-w32 12969 malloc: (1024) = 0xA00276CF0, called by 0x10054750E 51 620073 [main] emacs-w32 12969 free: (0xA00276CF0), called by 0x100645185 : 50 623056 [main] emacs-w32 12969 free: (0xA00276CF0), called by 0x100645185 51 623107 [main] emacs-w32 12969 malloc: (1000) = 0xA00276CF0, called by 0x10054860D :
AM中に起床。
Cygwin 3.4.xのメモリリーク調査。
イマイチ尻尾がつかめず。
Cygwinの malloc()では割り当てブロックのサイズが何種類か用意してあって、
割り当てサイズを包含できる サイズのブロックを割り当てるという感じになっていそうです。
いくつかの文字列オブジェクトを割り当てたとして、生存期間に差があり free()される
ブロックがメモリ空間上連続に並ばなくても、空いた穴が 割り当てサイズに見合えば再利用はできるハズです。
なので、プロセスサイズが増え続けるというのは何かしらの理由で解放できていない
疑いが強いのではないか?と考えています。実際、Emacsでメモリリークを再現させた範囲では
malloc()で割り当てを行なった際の返されるアドレスはどんどん大きくなるのですが、
C言語コードでの再現を試みた範囲内では使用するメモリの最大容量を超える事は無く
再利用されています。
Cygwin3.3.xに戻す退路を断たれているのですが(以前のメモ)、
そういやと思い CC2にインストールしてあるCygwin64のバージョンを確認してみたら
3.3.4だったので、Emacsは27.2ですが メモリリーク再現ELISPコードを試してみたところ、
やっぱりプロセスサイズの増加現象は起こりませんでした。
条件は大分絞れてきているのに現場を押さえられない.....挫けそうになってきた🥺
AM中に起床。
Cygwin 3.4.xのメモリリーク調査。
C言語単体コードではどうにも再現できず。雰囲気的にやっぱり解放抜けの要素があるんじゃないか?
と思い、先日のELISPでの再現コードをもう少し詰められないか調べてみたり。
どうやら 関数number-to-string で数値を文字列に変換すればそれだけでもイケそう。
(let ((buf (make-list 500 1.2))) (dotimes (n 30000) (dolist (elm buf) (number-to-string elm) ) )) ;; and press C-j
(dotimes (n 30000) (make-list 500 1.2) ) ;; and press C-j
AM中に起床。
Cygwin 3.4.xのメモリリーク調査。
free()が実行されているアドレスをしばらく観察していると徐々にアドレスが大きくなっています。
見掛け上、「実はfree()できていない」か「free()はできているがmalloc()が再利用していない」
といった事が考えられるのかも。Emacsの管理上は 文字列ブロックの総量は変わらないので、
malloc()→free()を繰り返している感じにはなっていると思われます。
これまでの結果から、こうすれば再現できるんじゃね? っていうELISPコードを考えて
みたところ うまく再現できてっぽい。以下のコードをscratchバッファで実行してみると、
プロセスサイズがもりもり大きくなりました😅
(let ((buf (make-list 500 1.2))) (dotimes (n 30000) (format "%s" (mapconcat 'number-to-string buf " ")) )) ;; and press C-j
テレワーク。早めに終了。
Cygwin 3.4.xのメモリリーク調査。
Emacsの文字列管理のコードにデバッグprintを仕込みながら観察。
文字列はブロックの単位で扱われていて、小さいもの(1000byte以下)と大きいものに分類されて
それぞれリストで繋がっているようです。ガベージコレクトが行なわれるまでの間は、
未使用ブロックがあれば再利用し、未使用ブロックが無ければ新たなブロックが追加され、
未使用になれば未使用ブロックとしてリストに繋がれていて、
ガベージコレクトが実行されると未使用ブロックは解放されるという感じになっているようです。
D言語のようなガベージコレクト機能のある言語であれば言語標準のライブラリでやっている事を
自力でやっている感じかなとは思います。
sysmonを起動した状態でブロックの増減を観察している感じ、
新規に割り当てられた文字列ブロックは未使用になった分解放されてを繰り返していて、
使用中のブロックの総数は変化していないようです。
解放されたブロック数を数える時に関数free()を実行しているハズですが、
でもプロセスサイズはじわじわ増えている為、本当にfree()で解放されているのだろうか?
という感じに見えます。見るところを間違えていなければですが😓。
テレワーク。早めに終了。
Cygwin 3.4.xのメモリリーク調査。
Emacsの文字列管理のコードがなんかムズい。1024バイトの配列を一つのブロックとして扱っているっぽい
のですが、ちょいちょい 1024という値がハードコーディングされていて、
メモリ割り当てサイズに連動しそうなdefineの値を変えて様子を見ようとすると、思った感じに
動かなかったりしているような気が。
テレワーク。気持ち早めに終了。
Cygwin 3.4.xのメモリリーク調査。
Emacsの文字列データの扱いがよく判らない...🥺。
lmallocで割り当てた領域と文字列の Lisp_Objectとの対応関係がよく判りません。
テレワーク。早めに終了。
Vimの生みの親であるブラム・ムールナー(Bram Moolenaar)氏が亡くなったらしい
(参考記事)。
62歳という事で意外と若かったのだというのを知りました
(以前のメモ;今年時点で67歳前後の世代の人達)。
Cygwin 3.4.xのメモリリーク調査。
format関数を実行するとリークが発生しているような気がする。けどまだよく判らず。
format関数は C言語の組み込み関数として実装されていて、実体は editfns.c:styled_format()のようです。
コードを眺めてみると少し変わったことをしているようです。
文字列の初期バッファは 変数initial_buffer にローカル変数として定義されていて、
bufというポインタでinitial_bufferを指しているのですが、
文字列のサイズがinitial_bufferのサイズ(1000+α byte)を超える場合は xmalloc()や xrealloc()で割り当てた
ヒープ領域にサイズを大きくして initial_bufferの内容をコピーして、以後ポインタ変数bufは
ヒープ領域のバッファを使うようです。
ここで、initial_buffer領域を指しているうちは(スタックに静的に割り当てられているので)
freeする必要は無い(むしろしてはダメ)のですが、ヒープに切り替わった場合はfreeが必要になる
という感じになっているようです。加えて、ヒープに切り替わった時や xrealloc()で
領域拡張した場合(拡張時にポインタが変わる事がある)などはそのポインタを覚えておいて、
関数を終了する時にまとめて解放するような事を行なっているみたい。ファインチューニング感があります。
AM中に起床。
Emacsの srcディレクトリ下の Makefileは flymakeに対応している事になっているのですが、
チェックの為に一時生成したソースファイルをコンパイルした時のオブジェクトファイルが
大量に放置されたままになっていました。
何故かコンパイルオプションに -fsyntax-only が付いていないのですが 追加すれば大丈夫そう。
Emacs29の flymakeが何かしら変更された影響か?
Cygwin 3.4.xのメモリリーク調査。
傾向的に なんとなく少し大き目(1KiB~4KiB)のメモリ領域が解放されていない場合が多いような気も?
そしてなんとなく SVGの元データとなる文字列のサイズに連動しているような気も。
文字列操作に起因している気がするのですが、デバッグに message や format 関数を使う
だけでも文字列操作を行なってしまうのでどうにも切り分けられない...🥺
sysmonのテキスト描画の場合どのように描画を行なっているかをもう一度よく見てみたり。
ウインドウ内の「幅×高さ」の空白文字と改行で埋めた文字列バッファを最初に生成するのですが、
点をプロットする時は aset 関数で文字列領域を配列のように扱って 空白文字を点に対応する文字に
上書きしています。ここでは文字列を切ったり連結したりといった操作は無い事が判りました。
一方、SVGの場合は頂点バッファを文字列に連結する必要があるので、
「(mapconcat 'number-to-string svg-poly-list " ")」
みたいなので生成したらどうか?とか試しているのですがプロセスサイズの増加は発生しています。
逆にテキスト描画の方でもっと文字列操作を行う感じに書き換えてSVG描画と同じように
メモリリークする操作を再現できれば良いのか?🤔
テキスト描画の関数の中で 用事の無い文字列を生成するのに format関数を使ってみたのですが、
それだけでプロセスサイズが増加しているような気も?もう少し調べてみるか...
AM中に起床。
メガネを作りにお出かけ。引き取りは来週。
「Emacsの雑記」を29.1ベースに更新してみました。御参考まで。
先日の通りbinutilsパッケージの新しいのではビルドできない
可能性があるので、その場合は古いbinutilsパッケージを使用してみてください。
Cygwin 3.4.xのメモリリーク調査。
まだ全く見当が付いていないのですが、Emacsの src/alloc.c内の関数 lmalloc、lrealloc、xfree に
デバッグprintを仕込んで観察してみたり。割り当てたメモリの全てを最後にfreeしている訳では無い
ようなので(プロセス終了に委ねている)、解放し忘れているのか 意図的に解放していないのかの
区別が付きません🥺。
malloc/realloc無しで いきなりfreeしているっぽい結果が見られたりしているので、
デバッグの仕込みが合っているのかも含めてもう少し確認してみる必要がありそう。
Cygwin的にはmalloc/reallocしたアドレスじゃない領域をfreeした時はSegfaultするようになっているので、
デバッグ仕込みの問題の気がしていますが😓。
テレワーク。気持ち早めに終了。
CygwinパッケージのEmacs 29.1-1が出た模様
([ANNOUNCEMENT] emacs 29.1-1)。
29.1-1はネイティブコンパイルは無効になっています。
28の時と同じく、29.1-2はネイティブコンパイルが有効になっているけどテスト版という事になっているようです
([ANNOUNCEMENT] emacs 29.1-2 (TEST))。
Cygwinパッケージの emacs-w32 29.1-1 を入れてちょろっと立ち上げ確認をした後、
パッチ版をビルドし直してたところ、temacs.exeのリンクがいつまで経っても終了せず。
binutilsの2.41-1ってのが一緒にアップデートされたのですが、一つ前の2.40-1に戻すと
リンクで突っかかる事はなかったり。ビルドできないと用事にならないので一つ前のでしばらく様子見。
予定外の所で突っかかってしまいましたが ひとまず 29.1への移行は完了。
テレワーク。早めに終了。
POV-Rayの手持ちのシーンファイルで実行時間比較
(参考:以前のまとめ)。
POV-Rayレンダリングオプション +FN +W640 +H480 +A0.3 天空ギア |--------------------+---------+------------+---------------| | CPU | 1thread | 最大thread | 備考 | |--------------------+---------+------------+---------------| | 68030(33MHz)+68882 | 30h | - | 参考 | | PentiumIII(550MHz) | 3m36s | - | 参考 | | i7-7700k(4.20GHz) | 8.57s | 2.65s | 最大thread=8 | | i7-13620H(2.4GHz) | 5.50s | 1.30s | 最大thread=16 | |--------------------+---------+------------+---------------| TANE's |--------------------+----------+------------+---------------| | CPU | 1thread | 最大thread | 備考 | |--------------------+----------+------------+---------------| | PentiumIII(550MHz) | 6h18m03s | - | 参考 | | i7-7700k(4.20GHz) | - | 183.94s | 最大thread=8 | | i7-13620H(2.4GHz) | - | 66.33s | 最大thread=16 | |--------------------+----------+------------+---------------| さいころ |-------------------+---------+------------+---------------| | CPU | 1thread | 最大thread | 備考 | |-------------------+---------+------------+---------------| | i7-7700k(4.20GHz) | - | 425.70s | 最大thread=8 | | i7-13620H(2.4GHz) | - | 193.99s | 最大thread=16 | |-------------------+---------+------------+---------------|
テレワーク。早めに終了。
ちょろり実験。昔作ったPOV-Rayのシーンファイルで、povray3.7になったらレンダリング
結果が変になっていたのですが原因が判らずほったらかしにしていました。
重なりの誤差の問題だったようで、オブジェクトのサイズを調節する事で見た目を直す事が
できたのでベンチマークに使えるかも。
テレワーク。早めに終了。
そういえば、絵文字の 震える顔(SHAKING FACE;🫨)ですが、絵文字のデザインを見てると
「震える」ってそういう意味だろうか?と思ったりも。
「悪寒」や「ガクブル」の意味の震えるで使う絵文字だと思っていたのですが、
振動の意味で振るえているように見えるのが多いように感じます
(参考ページ)。
何気にWindows付属のテキストエディタである メモ帳
のWikipediaを
読んでいると、Windows11ではタブ機能が使えたり、Undoに制限が無くなったり、
カラー絵文字が表示できるらしいのを知りました。実際試してみるとホンマやって感じ。
ちょっとした事ならメモ帳でいいやってなりそう😅。