今年のヤマザキ春のパン祭りは、2枚もゲットできました。
去年は品川勤務かつコンビニ昼飯がメインだったので、ヤマザキパンを買う機会がほぼなく、お皿をもらえるほど点がたまりませんでした。今年はCOVID-19による在宅勤務で、近所のスーパーでパンを買う機会が大幅に増えたため、2枚も手に入ったわけです。在宅勤務の意外な効果です。
コンビニに行かない人にとっては意外かもしれませんが、コンビニはヤマザキパンをほとんど置いていません。自社のプライベートブランドのパンばかりです。10年位前は他社のパンも置いていたんですが、今やコンビニは9割方がプライベートブランドのパンです。
コンビニのプライベートブランドのパンは、大手メーカー(ヤマザキパン、敷島製パン、フジパンなど)が作っていますが、コストの都合か何だか知りませんが、味に劣る気がします。好みの問題なのかな……?
パン祭りのお皿、裏側に何か書いてるなーと思って写真を撮ってみました。
ちょっと見づらいので文字に起こすと、
ARTICLE YAMAZAKI
MADE IN FRANCE
ZENMEN
BUTSURIKYOUKA
GARASU
「全面物理強化ガラス」ってローマ字で書いてありますね。フランス製なのに何でローマ字?フランス語で書かれても読めないから?
見ていて素朴な疑問が沸きました。あえて「全面」と強調する理由はなんでしょうね?皿のように厚みのない製品で「片面」物理強化ガラスにすることは可能?可能だったとしてもやる意味がある?
Pythonの文字列置換は "string".replace() ですが、正規表現ライブラリreだと、なぜかre.sub() です。同じ機能なのに、APIの名前も、引数の指定順序も違います。どうしてこうなった。
改定の度に魔界化するC/C++ に比べると、Pythonは明瞭に思えます。とはいえPythonも何だかんだ長い歴史ですし、祓いきれない闇があるんでしょうねえ。
メモ: 技術系の話はFacebookから転記しておくことにした。
目次: Kindle
KindleのアプリはKindle Fire版、Android版、PC版など、いくつか種類があります。普段使っているのはKindle FireとKindle for PCです。どうもKindle for PCのダウンロードが遅い気がします。
Kindle Fireも決して速いとは思いませんが、大抵はマンガ1冊が1〜2分でダウンロードできているので、5Mbpsくらいは出ているんじゃないかと思います。
Kindle for PCはかなり遅い(1〜2Mbpsくらい、日によって違う)です。同じネットワークを使っているのに、差が出るものですかね?PC向けだけ帯域ケチるとか、そんな面倒なことしないよなあ?うーん?
Kindle Fire HDのアプリはたまにアップデートされて動きが変わります。今年の頭くらいだったか?覚えてないですけど、また動作が変わりました。
新たなバグは再現率100%です。再現方法も簡単です。
この順に操作したとき、本来は本の一覧が出なければなりませんが、グループ化された本が再表示されてしまいます。明らかにバグってます。
このバグは、ユーザー側の操作で回避可能です。
ユーザーの操作に影響が出るバグですし、テスターに触らせたら数分で見つけそうなのにね?KindleってUIのテストしてないのかなあ??
目次: RISC-V
マクロの名前にTypoと思しきものがあったので、riscv-binutils-gdb(サイトへのリンク)にPull Requestをしてみました。
RISC-V向けのgasの実装では、命令に対応した名前のマクロがあります。
//opcodes/riscv-opc.c
//通常は命令の名前からドットを除いて、大文字にした名前
// vadd.vv -> MATCH_VADDVV
{"vadd.vv", 0, INSN_CLASS_V, "Vd,Vt,VsVm", MATCH_VADDVV, MASK_VADDVV, match_opcode, 0 },
{"vadd.vx", 0, INSN_CLASS_V, "Vd,Vt,sVm", MATCH_VADDVX, MASK_VADDVX, match_opcode, 0 },
{"vadd.vi", 0, INSN_CLASS_V, "Vd,Vt,ViVm", MATCH_VADDVI, MASK_VADDVI, match_opcode, 0 },
//Reduce系の命令だけ名前が違う
// vredsum.vs -> MATCH_VREDSUMV"S" のはずなのに、MATCH_VREDSUMV"V" になっている
{"vredsum.vs", 0, INSN_CLASS_V, "Vd,Vt,VsVm", MATCH_VREDSUMVV, MASK_VREDSUMVV, match_opcode, 0},
パッチの中身は簡単で、ベクトル命令の一部で、命令の名前とマクロの名前が違っていたので修正しただけです。この手の間違いがいくつあるか分からなかったので、ちょっとしたPythonスクリプトを書いてチェックしました。
#!/usr/bin/python
import re
import sys
fname = sys.argv[1]
f = open(fname, 'r')
line = f.readline()
while line:
if not line.startswith('{"'):
line = f.readline()
continue;
line = line.strip().replace('}', '')
line = re.sub('\{"([^,]*)",', r'\1,', line)
line = re.sub('".*",', '', line)
line = re.sub(' *', '', line)
items = line.split(',')
insnOrg = items[0]
insn = items[0].upper()
classInsn = items[2]
matchInsn = items[3]
maskInsn = items[4]
aliasInsn = items[6]
if not classInsn.startswith('INSN_CLASS_V'):
line = f.readline()
continue;
if not matchInsn.startswith('MATCH_') or not maskInsn.startswith('MASK_'):
line = f.readline()
continue;
if aliasInsn.startswith('INSN_ALIAS'):
line = f.readline()
continue;
insn = insn.replace('.', '')
matchInsn = matchInsn.replace('MATCH_', '')
maskInsn = maskInsn.replace('MASK_', '')
if matchInsn != maskInsn:
print("MATCH != MASK: {:s} != {:s}".format(matchInsn, maskInsn))
if insn != matchInsn:
print("INSN != MATCH: {:s} != {:s}".format(insnOrg, matchInsn))
line = f.readline()
条件を適当に継ぎ足して書いたのと、Pythonの経験値が低いのが相まって、エレガントさの欠片もないですね。仕方ない。実行結果はこんな感じです。
$ ../checker.py opcodes/riscv-opc.c INSN != MATCH: vzext.vf2 != VZEXT_VF2 INSN != MATCH: vsext.vf2 != VSEXT_VF2 INSN != MATCH: vzext.vf4 != VZEXT_VF4 INSN != MATCH: vsext.vf4 != VSEXT_VF4 INSN != MATCH: vzext.vf8 != VZEXT_VF8 INSN != MATCH: vsext.vf8 != VSEXT_VF8 INSN != MATCH: vredsum.vs != VREDSUMVV INSN != MATCH: vredmaxu.vs != VREDMAXUVV INSN != MATCH: vredmax.vs != VREDMAXVV INSN != MATCH: vredminu.vs != VREDMINUVV INSN != MATCH: vredmin.vs != VREDMINVV INSN != MATCH: vredand.vs != VREDANDVV INSN != MATCH: vredor.vs != VREDORVV INSN != MATCH: vredxor.vs != VREDXORVV INSN != MATCH: vwredsumu.vs != VWREDSUMUVV INSN != MATCH: vwredsum.vs != VWREDSUMVV INSN != MATCH: vfredosum.vs != VFREDOSUMV INSN != MATCH: vfredsum.vs != VFREDSUMV INSN != MATCH: vfredmax.vs != VFREDMAXV INSN != MATCH: vfredmin.vs != VFREDMINV INSN != MATCH: vfwredosum.vs != VFWREDOSUMV INSN != MATCH: vfwredsum.vs != VFWREDSUMV INSN != MATCH: vcompress.vm != VCOMPRESSV
明らかにTypoに見えるのはvred/vfred/vcompress系の命令で、vsとvvを取り違えています。
微妙なところなのはvzextです。他はドットを除いた名前なのに、vzextだけドットをアンダースコアに置換した名前です。ルールに一貫性が無いだけか、Typoか、どちらとも言い難いため、今回出したPull Requestでは修正していません。
リポジトリを見ていてちょっと気になったのはSiFiveの人以外、変更がほとんどないことです。著名プロジェクトでは珍しいです。もしかするとGitHubでPull Requestを受け付けてない(※1)可能性があります。
変更を提案するのはここじゃないとか、そもそも変更は受け付けてませんとか、何でも良いので反応があると嬉しいですね、週明けまで待ちましょうかね……。
(※1)本家および開発の場がGitHub以外に存在していて、GitHubをミラーにしているプロジェクトの場合、GitHub上で何か言っても無視されることがあるようです。
Splatoon 2のガチマッチ(Cランク)の難易度が下がった気がします。
1〜2か月前は、20kill対0killで負けたり、1分でノックアウトされたり、超フルボッコで負けまくるのが当たり前で、すっかりやる気がなくなっていましたが、今日久しぶりにやったら一度も負けず、あっさりC+ ランクになりました。
アクションゲームの腕は1か月やそこらで急に上達しないので、私が上達したというよりも、絶対勝てないおかしいレベルのプレーヤーとマッチする割合が減った、そんな感じです。
Stay Homeとかゴールデンウイークとかで、Splatoon 2のプレーヤー人口が盛り返して、初心者クラス(C-〜C+ ランクあたり)に合う人が増えたんじゃないかと推測しています。
最初からこのくらいの難易度だったら、ガチマッチ嫌いにならずに済んだんですけど、すっかりガチマッチ嫌いになってしまった(レギュラーマッチは好き)ので、もう遅いんだよな〜……。
目次: C言語とlibc
C言語のマクロによる置換を、循環参照させたらどうなるでしょう?
A B C D
#define A B
A B C D
#define B C
A B C D
#define C A
A B C D
結論から言うと問題ありません。下記のような結果になります。
A B C D
B B C D
C C C D
A B C D
4つ目の結果は、置換前のA B C Dと何も変わっていないように見えますが、実はそうではありません。下記のように定義するとわかります。
A B C D
#define A 1 B
A B C D
#define B 2 C
A B C D
#define C 3 A
A B C D
A B C D
1 B B C D
1 2 C 2 C C D
1 2 3 A 2 3 1 B 3 1 2 C D
4つ目の結果の「A」を例にとると、A -> B -> C -> Aと3回のマクロの置換が行われた結果、Aに戻っているわけです。#define A Bのマクロは1度しか適用されないようです。
C言語の仕様(C11 final draft (N1570) - 6.10.3.4 Rescanning and further replacementの第2項)を見ると、
2
If the name of the macro being replaced is found during this scan of the replacement list (not including the rest of the source file's preprocessing tokens), it is not replaced. Furthermore, if any nested replacements encounter the name of the macro being replaced, it is not replaced. These nonreplaced macro name preprocessing tokens are no longer available for further replacement even if they are later (re)examined in contexts in which that macro name preprocessing token would otherwise have been replaced.
(直訳)
2
置換されるマクロの名前がreplacement listのスキャン中に見つかった場合(ソースファイルの残りの前処理トークンは含まれません)、そのマクロは置換されません。 さらに、入れ子になった置換が、置換されているマクロの名前に遭遇した場合、それは置換されません。 後にそのマクロ名の前処理トークンが置換されていたであろうコンテキストで(再)検査されても、これらの置換されていないマクロ名の前処理トークンはそれ以上の置換はできなくなります。
正直言って何言ってんだお前……?って感じがしますけども、平たく言うと同じマクロを2回適用しない、ように読めます。
下記のように同じマクロで何度も置換できそうなマクロを定義してみます。
#define A B C
#define B C A
#define C A B
A B C D
A B A A C A B C B B A B C A C C B C D
1つ1つのトークンがどのマクロで展開されているか図示します。
複雑に見えますが、どのトークンを見ても同じマクロを2回適用されたものはないことがわかります。
しかし関数型マクロの場合は、不思議な挙動を示します。
#define F(a) a G
#define G(a) a F(a)
F(7)(8)(9)
7 8 8 G(9)
展開の様子は下記のようになると思われますが、
どうして7 8 8 G(9) で展開が終わるのかが良くわかりません……。マクロF(a) を2回適用しない、というルールならば、7 8 F(8)(9) で止まらなければおかしいように思いますが、結果を見るとなぜかF(8) も展開されています。
今、使ってるノートPC(ThinkPad E480カスタムオーダー)には、Intelのグラフィクスと、Radeon RX 550が搭載されています。
Radeon RX 550はモバイル用としては結構強力で、主にゲームの時に助かっているのですが、Radeonを使ってゲームをしばらくやっていると、本体が触れないくらい熱くなり、しまいに熱暴走でクラッシュしてしまいます。
せっかくカスタムオーダーで追加したのに微妙な奴だな〜。
このGPUはもうひとつ変なところがあって、デバイスマネージャでRadeon RX 550を「無効」にしてPCを再起動すると、冷却ファンが唸り続けます。
CPU利用率は極めて低いままにも関わらず、冷却ファンが全力稼働しているので、ファンの制御がおかしくなっているように思います。GPUの負荷を勘違いしているのだろうか?
プロセスを片っ端から終了させても収まらなかったところをみると、恐らくドライバが変なところにハマっている?のでしょうか。
デバイスを有効にするか、有効にしたあとに再度無効にすれば、CPUファンは静かになりますが、なんだか挙動不審ですよね……。
< | 2020 | > | ||||
<< | < | 05 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | - | 1 | 2 |
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 | - | - | - | - | - | - |
合計:
本日:
管理者: Katsuhiro Suzuki(katsuhiro( a t )katsuster.net)
This is Simple Diary 1.0
Copyright(C) Katsuhiro Suzuki 2006-2023.
Powered by PHP 8.2.15.
using GD bundled (2.1.0 compatible)(png support.)