2018/12/08

[win10]なぜかGitHubのフォントが太い

うちでは、デスクトップPCとノートPCがあり、どっちもWindows10を使っている(バージョンは違うが)。

なぜか、ノートPCでGitHubを見たときのフォントが太いのだ。


たとえば、ここ。
https://github.com/hirokuma/leveldb-c-example


Firefox


デスクトップPC

image  


ノートPC

image



chrome


デスクトップPC

image


ノートPC

image


横に並べたいのだが、ブログエディタの設定がうまく行かん・・・。



chromeはあからさまに違うな。

firefoxは同じかも、という気がしたが、横に並べると違った。
というか、フォントの種類が違うな。

左がデスクトップPC、右がノートPCだが、右はドットフォントになっている。
私がドットフォントの方が好きなのでいいんだけど、同じ設定のつもりなのに違うというのが気にくわない。


image



デスクトップPCのバージョンは1803、ノートPCのほうは1809だ。
ノートPCの方を先にアップデートして様子を見ていたのだが、アップデート直後からそうなのか、しばらくして変わったのか、そもそも何か設定を変更してしまったのかがよくわからん。

フォントキャッシュを削除してみたが変わらんので、そういう問題ではないようだ。
フォントの種類に詳しければ何か分かったのかもしれんが、うん、私には分からん。


結論は何も出ないが、メモとして残しておこう。

2018/11/30

[linux][pthread]pthread_cond_wait()を勘違いしていた (2)

前回、けっこうがんばったつもりだったので、このタイトルで2回目の記事は書きたくなかった。。。
つまり、まだあれではダメだった、ということだ。


前回の一番最後の図で、左側に要求を出すスレッドが2つ、右側に要求を処理するスレッドが1つあった。

  1. 右側が先にmutex_lock()してcond_wait()によってロック解除
  2. 左側がmutex_lock()して、リソースを書き換えてcond_signal()
  3. 右側はcond_signal()を受けて動き出したいけど、内部でmutex_lock()をするため、左側がmutex_lock()していることにより動けない
  4. 左側がmutex_unlock()
  5. 右側が動き始める

こういうシナリオだった。


が、左側には要求を出すスレッドが複数あるので、こんなことが起きているようなのだ。

  1. 右側が先にmutex_lock()してcond_wait()によってロック解除
  2. 左側Aがmutex_lock()して、リソースを書き換えてcond_signal()
  3. 左側Bがmutex_lock()して、動けない
  4. 右側はcond_signal()を受けて動き出したいけど、内部でmutex_lock()をするため、左側Aがmutex_lock()していることにより動けない
  5. 左側Aがmutex_unlock()
  6. 左側Bが動き始めて、左側Aが書き換えたリソースを上書きしてしまう

たぶん、こうなっている。
はぁ。


この記事の真ん中から下にも書いてあるが、順番に処理したいならキューイングするしかなかろう。
(まったく読んでなかった。。。)

IBM: 一般的なスレッド: POSIX スレッドの説明: 第3回

やりたいことは異なるのでソースをまねするかは分からないけど、キューイングみたいなことはいるな。


リンク先のworkcrew.cで、L.49でmutex_unlock()、L.53でmutex_lock()しているけど、これはいるんだろうか?
cond_wait()を抜けたときには内部でmutex_lock()して、cond_wait()を呼ぶときには内部でmutex_unlock()されるということだったので、私のコードからは削除したのだ。

全体で何をやっているコードなのか見ていないので何とも言えんな。
隙を見せる(一瞬unlockする)ことで、何か利点があるのかもしれん。

2018/11/23

[win10]ウインドウの枠を太くしたい2018年秋 (3)

なぜか3回目だが、見た目の問題は使い勝手に影響するので、長引くのもしかたあるまい。


今回は、記事の修正だ。

1回目で、色の選択はすべてできるわけではないと書いたけど、そんなことはなかった。
「サポートしない」というメッセージだけで、完了ボタンを押して確定することができたのだった。

image

まあ、見づらいのだけどね。。。


今日は、このくらいの色にした。

image

image


うーん・・・悪くはないのだが、黒文字に合わせる背景色ってのは選択肢が少ない気分になってしまう。
私のセンスの問題のような気もするが、そこは忘れよう。



そもそも、最近はウィンドウを結合して文字が見えない方がデフォルトだったと思うので、気にしないものかもしれん。

image

これに慣れてしまえばいいのだろうが・・・ダメだった。
新しいものについていけない年齢なのかもしれんし、そういうのをずっとサポートするのもメーカーとしては大変なのだろう。

2018/11/18

[win10]ウインドウの枠を太くしたい2018年秋 (2)

このサイトはGoogleの「Blogger」を使ってるのだけど、貼っている画像は「フォト」と同じ扱いなのに気付いてなかった。
もうブログに貼ったから削除して良かろう、とゴミ箱に入れていたら、画像がなくなっているではないか。。。

私は、けっこうバサバサと削除してしまう方なのだ(そして、元に戻せなくて後悔することもしばしば)。
きっと、過去のブログでは画像がなくなっていることだろう。


幸い、気付くことができたので、過去のこと(画像がなくなっているだろうこと)は忘れて、前向きに生きていこう。


さて、ウインドウの枠を太くする記事の2回目。

前回は、Windows10 Homeの1809(2018年秋バージョン)で枠を太くしたのだった。
今回は、1803(2018年春バージョン)にその設定を持っていった話をしよう。


枠を太くするのに使ったのは、AeroLiteという隠しテーマらしい。
1803がインストールされているPCはWindows10 Proで、この子も以前はAeroLiteにして試していて、元に戻したのだった。


テーマファイルはエクスポートできるようだったので、1809で作った設定ファイルを、そのまま1803で開いた。
開いた、というのは、ダブルクリックした、という意味だ。
拡張子は「deskthemepack」で、cabファイルで圧縮されていた。
展開すると「theme」ファイルが入っていただけだった。まあ、壁紙も何もないからね。


image

1803の方は、それだけでインポートしてくれた。
まあ、AeroLiteを以前に有効にしていたのが効いていたのかもしれんな。



非アクティブなウィンドウタイトルの色は、ものによって違うようだ。

こちらは、TeraTerm。
非アクティブなことがちょっと分かりづらいが、文字は読みやすい。
なお、文字が太文字になっているのは、Tweakerで変更したからだ。

image


こちらは、Explorer。
私には非アクティブがちょっと見づらいが、アクティブな方はこっちの方がよいかも。
枠の色は、変化がないように見える。

image


これはChrome。
非アクティブが緑色なのは、Tweakerで設定しているため。
Tweakerの設定項目にあるのに、これが有効なアプリがどれかわからんのだ。

image


ストアアプリの電卓。
Microsoftのストアアプリは、タイトルバーのところに色が付かないようだ。
文字の色でも区別が付かないので、太くした枠が見分けるのに役立つ。

image



とまあ、こんな感じで、色のルールがよくわかっていない。

なんとなく、Microsoftはタイトルバーを嫌がっているような気がするのだが、「Windows」なのだからウィンドウは見やすくしてほしいものだ。


さて、枠を太くしてみたものの、それが何か役立っているかというと、よくわからん。

劇的に何か変わったというわけではないが、精神的には多少良くなった気がする。
まあ、Windows8になったときは「うおっ、枠が太い!」と思った気がするのだが、枠がなくなってほしいわけではなかったので、ないよりはあるほうが助かるのだ。


とはいえ、この辺は慣れとか作業環境とかあると思うので、私は枠がほしかった、というだけのことだな。

2018/11/17

[c]LevelDB C (3)

11月になって寒くなってきたので、コタツ上のPCに移動。
こちらにはleveldbの環境が無いので、せっかくだからaptでinstallできるか試しておこう。

apt install libleveldb-dev
git clone https://github.com/hirokuma/leveldb-c-example.git
cd leveldb-c-example
gcc -Wall leveldb_example.c -lleveldb
./a.out

コンパイルも通って、実行もできた。


ライブラリやincludeのディレクトリも一緒にcommitしていたけど、それを削除してもビルドできたので大丈夫だろう。


さて、このサンプルだが、実行しても後に何も残らない。
DELETEしているところと、DESTROYしているところをコメントアウトすると、ディレクトリが残った。

「testdb」というフォルダ名で、これはleveldb_open()した名前と一致している。
実行はWindows10のWSLで行ったのだが、ディレクトリの中はこうなっていた。

image

Windowsの人としては、拡張子が付いている「000003.log」がテキスト形式であってほしかったが、テキスト形式らしきものは「CURRENT」と「LOG」だった。


CURRENT

01: MANIFEST-000002
02: 


LOG

01: 2018/11/17-22:09:16.387552 7f3d2e040740 Delete type=3 #1
02: 


000003.log

image


MANIFEST-000002

image


データらしきものは、拡張子がlogのファイルに残っているようだ。
LOGの、時間とコメントの間にある数字はデータのハッシュ値かと考えたが、"testdb"を削除して実行しても値が変わるし、変わるのは一部だけだから、何か時間の要素を使っているか、乱数を使っているだろうし、固定値の意味合いもあるのだろう。
いまだと「7f...」で始まるので時間かと思ったが、7fの次が変わるので単純な時間表現でもなさそうだ。


削除しないようにしてもう一度実行すると、LOGはLOG.oldにリネームして、新しく作り直すようだ。
つまり、1世代前のLOGまで残っている。

MANIFESTの番号も増えるし、拡張子がldbのファイルも増えたりしているので、作ったファイルの中身を知りたければ実装を読むか、解説記事を読んだ方がいいだろう。


私はそういうつもりがないので、今回はここまで。