2001-12-28
_ 場所
神奈川
_ クラックされたサイト一覧
先日行ったイベントでやってた講演。このときのスクリーンにここが表示されてたことに爆笑した記憶があります。
クラックされたのはボルチモアのサイト。っていうのが 10 月あたりにセキュリティホール memo ML に流れたんですが、当のサイトが今 無いんですね。で、ここを ふりすさんから教えてもらいました。感謝。
2002-12-28
_ コミケ 1 日目
* 前
大井町からりんかい線。大井町からは初めて。はじりん。
いままでは二子新地→永田町→新木場→国際展示場という経路。約 1.5 h 。今回は二子新地→二子玉→大井町→国際展示場。これで 1 h 。ビバ！ りんかい。
* コミケ
1100 ころ入場。知合いに挨拶。たくみさまがめぐ島で売子してたんだけど、えらく生気が無かった。それ、客がビビるぞ。ていうかヲレがビビった。
ちゃっぴーの買物とさとぅさんの買物してちゃきっと「うちゅーせーは」へ。ヨタヨタ。途中で身体が冷えてきたので散歩。西屋上とか行ってみた。にゃんこたんを探してみたけど今日って居ないのだっけ。うちゅーせーはの所にいのさんが来たのだけど、ヲレの隣に居たうちゅーせーはの方( 名前忘れた。すんません )がいのさんの学生時代の先生というのが面白かった。
もう終わりそうになってからゆーいちくんに挨拶。
なんだかんだでいろいろ購入して終了。
* 後
いつものたん清の予約は人数が微妙ということで、ヲレ、たくみ、佐伯くん、いのさんで別に宴会。渋谷の甘太郎。たらふく食って終了。とっとと帰宅。
2004-12-28
_ NanoSweepだ
12/30 のコミケの日かあ。
ページのサキの ayazo.net のサキに PSPナムコ リッジレーサーズ サウンドメンバーインタビュー があるのだけど
「リッジレーサーズ」コンポーザー勢ぞろい。後列左から、相原さん、佐宗さん、細江さん、中川さん、佐野さん、高橋さん。前列左から、中西さん、大久保さん、境さん、三宅さん
先日 買ったストリートファイターの CD がそうなのだけど相原さん、佐宗さん、細江さんはよく絡んでるのですね。
有名なんでしょうか。
_ 買い物
ぃゃ香水なんてそもそも使ったことがないのだけど...。
K A N O U . J P: ブルガリ オムニア クリスタリン
でも甘くなく、どちらかというと爽やか系の香りだったので男がつけてもいけるかなとか。
などということで買ってしまった。
IRC で出てきた 香水広場 で日曜夜に注文したら今日の朝に届いた。\
_ 葬儀
祖母の姉の告別式。
父上が出張中なので私が代理。
親戚一堂が集まるわけだが、ここで思った。
私は親戚の名前をほとんど知らない。
もちろん昔からの馴染みなのだが「 お久しぶりです。えーと....」 と考えてみると氏名を知らずに過ごしてきたことに気づいた。
かなり困った事態なのかもしれない。
食事のときに熱燗があったのでがんばって飲んだ。
_ 【健康ジャーナル】「笑顔に勝る化粧なし」効用は科学的に実証
( via RinRin王国 )
「どの笑いでもいいんです。笑うことが大事。笑うから楽しいということもあって、何の意味もなく大きな声で笑ってみると、それがおかしくて自分で笑いだすときがあります」
FF 10 でもユウナとティーダが「 はーっはっはっは 」と大きい声で笑うというイベントがあったけどそもそもどーしてそのイベントがあったのか忘れてしまった。
笑顔は大事っす。電車に乗っててもたまに無表情というか「 人生つまらん 」という顔をしたひとがいる。こんなの( D-Pixed で書いたヘタレ絵。ちなみに「 くにお 」で有名な「 ダウンタウン熱血物語 」に出て来る通称ダブルドラゴンの竜一、竜二がこのような目をしている )。
電車に乗っているときは当然男性の顔なんぞ見ないのでもっぱら女性の顔を見てるのだけど、このように無表情な女性を見るとたしかに魅力がないと感じる。もったいない。といいつつ私も普段はこんな顔をしているのだろう。なのでせめて↓これくらいの顔で過ごすようにしたいところである。
それはそれとして。
いつも笑っているには「 鬱だしのう 」「 人生に疲れた 」「 orz 」などと考えていては笑顔になんかならない。いつも楽しいことを考えよう。いつでも楽しもう。でも私は性根が後ろ向き指向なのである。英語でいうと Backward paradigm といったところなんでしょうか。よく分からないけど。
だから私は 先日 かみなぎせんせーに聞いたのです。
ヲレ「 かみなぎせんせー。どうやったらせんせーのように人生を楽しめるのでしょうか。」
かみなぎせんせー「 みわくん、前向きに生きろ。前倒しじゃないぞ 。前のめりはいいけど。」
倒れるときは前のめりに倒れる。前倒しは前の中のひとを倒してでも進めという試練。ぃゃしかし前の中のひとにはむしろ逆に倒されそうだ....。
＿○□＝ 前のめりに倒れてみた
今後はこれですよ！
orz はもう時代遅れですよ！
時代は前のめりですよ！
2005 年は前のめりの年ですよ！
でも辞書登録とかしないとそのまま打鍵するのはしんどい。
ぼそ
ヲレ的 2004 年流行語大賞はコレだと思っている。
- 人生に疲れた
- orz
_ Mew 4.1.53
入れたわけなんだがこんなこと言われた。
Debugger entered--Lisp error: (void-function mew-vinfo-get-thread-p)
mew-vinfo-get-thread-p()
mew-fancy-summary-enable()
run-hooks(mew-summary-mode-hook)
mew-summary-mode()
mew-summary-switch-to-folder("+inbox")
mew-summary-visit-folder("+inbox" goend)
mew(nil)
call-interactively(mew)
execute-extended-command(nil)
call-interactively(execute-extended-command)
ひとまず .mew.el なんぞをコメントアウト。
ぅぅむ。
;; fancy summary ;;(add-hook 'mew-init-hook (lambda () (require 'mew-fancy-summary)))
2005-12-28
_ 終わりのクロニクル( 7 )
完結。
厚すぎて持ち歩くには果てしなく不便なのだけどなんとか読み終えた。
一般化して考えると、過去を捨ててはならない、過去を受け入れて未来を構築しろ、ということか。
ノアによる世界の輪廻はいまいち理解できなかったのだけど、過去を知らない者たちが居れば毎回 12/25 に世界をリセットして、過去を知ろうとする者たちによって世界は 12/25 から先へ進むということかなあ。
「 ─ 3rd-G 自動人形、バイオレット。周囲援護を致します！！ 3rd-G 主力もおりますからご安心─ 」
7th-G 辺りの戦闘で破壊されたすみれたん復活したっ
言いつつ彼女は転んだ。それも、何も無い場所で。
ドジっ娘健在。
_ 自ニュF: ジェミニのCMが 20年前 なのに凄すぎる。
( いろんなところより )
中盤あたりからは私も TVCM を見た記憶がある。
すごいなあ。
ジェミニを買うとこーいうことができるようになりますよ！( 違う )
_ 仕事
0945 川崎。
おー。ここか。中学生のころによく試合で使用した みゆき球場からみえていた TOSHIBA の建物はここのことだったのだな。近所に 川崎総合科学 も見える。
話の電波棟も見れた。
仕事収めにならず。
時間が遅くなったので自社の納会には参加しなかった。
_ 本のお渡し
川崎からの帰宅途中で あいすさんから連絡があったので武蔵溝ノ口にて合流。車で来ていただいていたのでそのまま実家へ連れていってもらった。ありがとうございました。
消化しておいたマンガや小説を譲渡。
来年のツアーをちょこちょこと。
_ 買い物
発売日当日に届いた！
これがスィープレコードクオリティ。
発売日当日に届かないのが amazon クオリティ。
UNDER DEFEAT のケースでかっ
- [ CD ] NanoSweep2
- [ CD ] ハンクス・ワークショップ！OST
- [ CD ] UNDER DEFEAT -SoundTracks-
2006-12-28 :-)
_ あー あー 朝かね？
朝だね。
_ 2006 年の日記容量
まだ 12/28 だけど計測してみた。
あと数日でたぶん画像が増えるはずだから 65 MB くらいになりそう。
% du -hs ~/diary/2006 ~/public_html/images/2006 2.7M /home/rin/diary/2006 61M /home/rin/public_html/images/2006
_ [コンパイル][バイナリ][Java][Perl][コード]P-code 言語
そーいう名前があるのか。
P-code 言語というのは、ソースコードがコンパクトなバイナリコードに変換されて、それが実際に実行されるという点ではコンパイル型言語と似ていますが、変換されたコードの形態がマシンコードではないという点で異なります。
重要な p-code 言語としては、Python, Perl, および Java があります。
perl -c
かしら。
_ [クリスマスイベント][プログラマ]クは駆動のク“D is for Driven”〜Developer TestingとBDD〜 ( PDF )
( via オブジェクト倶楽部 2006クリスマスイベント 公開資料 )
見てないセッションの資料を眺める。
角谷信太郎さんとこの資料に出てきた URI つらつら。
_ ノビヨの FC イベント
申し込みどね。
2007-12-28 :-)
_ 朝ったー
0555 起床。ちょいと遅れた。
_ [悪魔城ドラキュラ]通勤ったー
悪魔城ドラキュラベスト
ゲーム未プレイ。ファミコンのディスクシステムの「悪魔城ドラキュラ」を友人がプレイしている横からちょこっと覗いたくらいです。作曲はどなたでしょう？矩形波倶楽部？もはや CD が手元にないので詳細がさっぱり分からないです。「悪魔城ドラキュラ」の音楽の原点です。アタシはホラーとかスプラッタとかサイコとかグチョグチョとかネチョネチョとかオドロオドロシイとか「 どちゃっ 」という効果音とかそーいう方面は苦手なのでゲームの画面を初めて見たとき( 小学生のころ )はビビってしまって目も耳も塞いで心をかたく閉ざしていたんですが、いま音楽を聴いてみると普通にカッコイイです。ゴシック？アルバムの冒頭 2 曲はアレンジ曲です。メドレーのような形式になっているので悪魔城ドラキュラの世界をさらっと体感するには良いです。
B00005F6F4
_ [プログラマー][人気]全力でプログラマーを「人気の職業」に押し上げたい - Attribute=51
( via tsupoのブックマーク )
問題点：裏方の仕事は知名度がない
それはプログラマーに限らない。20 年くらい前に「昼間のパパはちょっと違う♪」という TVCM があったのはそーいう状況が表れてる証拠。誰の歌だったか何の CM だったかも覚えてないのだけど。どこかの建設会社の TVCM だっけ。
かっこいいソフトウェア
昨日届いた日経 NE に「かっこいいソフトウェア」という特集がありました。
組み込みソフトウエア分野で人材不足が深刻化している。人海戦術で「3K職場」とも揶揄されるイメージをいかに改善していくか。技術者への「あこがれ」を創生することが近道となる。（進藤 智則）
日経NE でいう「技術者」はソフトウェア開発者全般のことです。ここでは呼称を統一するために Attribute=51 に合わせてプログラマーと呼ぶことにします。日経 NE の特集は「プログラマーを憧れの職業にするためにどうするか、地位を上げるためにはどうするか」というものです。第2部＜技術者像＞でインタビュー記事があって、どなたかが以下のようなことを言っていました。
- プログラマーの仕事をもっと世間へアピールする
- たとえば医師や弁護士は地位が高いとされる
- 昔から医師や弁護士が自分の仕事を世間へアピールしてきたからだ
- プログラマーも「地位が低い」と愚痴ってないでアピールしろ
「プログラマー？なにそれ？」という状態ではアピールが足りないわけです。
Attribute=51 に「スタッフロールを作れ」とか「クレジットを表示しろ」とあります。そうだよなあ。そういえば初めて仕事でプログラムを書いたときにコードに自分の名前を書いたら「消せ」と怒られました。「おいおい！名前を書いておかなかったら誰がこのコードを書いたのか分からないだろ、俺の成果物なんだとアピールできないだろ」と仕事場の上司や先輩に反発したことがあります。学生のころに Linux や Chasen や Namazu などのコードを読んで「コードには自分の名前を書いておくものだ」という認識があったので、仕事のときもその認識でいたのだけど、まあ会社にはいろいろ都合があるわけです。いろいろなというのは仕事の契約上という意味なんですけどね。
あわせて読みたい：作品をよく見せるためのお手軽なテクニック集
_ プログラマーの歴史は始まったばかり
たとえば医師と弁護士とプログラマーを比較してみます。厳密に歴史を辿ってないので「だいたいこんな感じ」というおおざっぱな比較です。
- 医師という概念は古代からあった
- 地位が高くなったのは中世ヨーロッパ以降
- 中世ヨーロッパは 476年 から15世紀末( ref. 中世 - Wikipedia )
- 中世ヨーロッパでは法律家を養成するため、各大学に法学部が設置されていた
- 史上初のプログラマは エイダ・ラブレス（ラブレース伯爵夫人オーガスタ・エイダ・キング・1815-1852）であるとされる
- ただし、それはあくまで概念的あるいは数学的なものでしかなく実質的なプログラマはコンピュータの登場からである
- 1940 年代：プログラマの登場とは回路変更を行わずにコンピュータの処理内容変更が可能となり、入出力装置が発展してからである
ということで多少前後するようですが「プログラマーは 50 年くらいの歴史」です。たったの半世紀です。医師や弁護士と比較してまだ歴史が短いことが分かります。
「人月の神話」は 1975 年に初版が出版されましたが「人月の神話」は今でも通じます。ソフトウェアプロジェクトは 30 年前から進歩してません。そしてシステムソフトウェアは 20 年前から進歩してません( ref. Systems Software Research is Irrelevant( PDF ) )。
_ コミケに行く予定
12/31 のみ。こんだけ。追加しま。
- 西あ27b Sound Online (Sound Online オリジナルアルバム 「The Clear Blue Sky」 特設ページ)
- 西あ15a XL Project
- 西か18b INSPIRE ・for-next / nanosounds （ハウス・エレクトロ）２曲入/300円予定（CD-R 約100枚頒布予定）
- 西か 09b LINEAR 「LINEAR COMPi 2007」「Spice Life EP」(LINEAR >> COMIC MARKET 73)
- 西き26a Magical Trick Society
- 西は22a 「こうさぎHACKS」
- 東シ46a シトロネット 渡部恭久 citronette x Yack.『Flaming one frame』
2008-12-28 :-)
_ 304 Not Modified: 【TB企画】あなたのブログの中でおすすめのエントリを教えてください2008
( via id:HolyGrailとid:HoryGrailの区別がつかない日記 )
おすすめというか地道に 『みわの本拠地』 の人気エントリー - はてなブックマーク を 目grep しました。人力かよ。以下 被ブックマーク数が多い順です。
Plagger で Twitter の自分宛ての reply をケータイへ送信する[ 20081111#p10 ]
@dk19810313 による Twitter:@あらったー！クローズドアルファバージョン が稼動してるので最早 Plagger のコレは使ってません。@dk19810313++
ITpro Challenge! 2008[ 20080905#p04 ]
宮川達彦さんを初めて目にしました。
劣等感溢れるエントリーです。
remedie を入れてみた[ 20081215#p09 ]
その宮川達彦さんプロダクト。
とりあえず otsune's SnakeOil - subtech をウォッチするといいかもしれませんね。
_ Firefox の検索バーを整理した
よく使う順。
FreeBSD日本語マニュアル検索がだぶっているではないか。
検索バーへの追加はこれを使っている → Add to Search Bar :: Firefox Add-ons
_ 朝ッ
1000起床
2009-12-28 :-)
_ リッジレーサー7 の進捗率をグラフにした
リッジレーサー7 を買ってからそろそろ 1 年経過するので前回[ 20090225#p08 ]からオンラインバトル勝利数を追加してグラフを作ってみた。コードは見ないで
走行距離
名声
進行度はもはや100% を超えることはないんだけどまあ名残り。
勝利数。あまり勝率が高くない。199勝目から日記に記録しはじめたのでグラフの下限が 199 になっている。たまに勝利数が跳ね上がってるのはたぶん阻止レースのときにチームで勝ったときだろう。
_ [NetBSD][pkgsrc][ruby-mode]ruby-mode を入れようとしたら怒られた
===> Installing dependencies for emacs-23.1nb2
==========================================================================
The supported build options for emacs are:
dbus gtk motif nextstep svg x11 xaw xft2
The currently selected options are:
dbus gtk svg x11 xft2
You can select which build options to use by setting PKG_DEFAULT_OPTIONS
or the following variable. Its current value is shown:
PKG_OPTIONS.emacs (not defined)
==========================================================================
==========================================================================
The following variables will affect the build process of this package,
emacs-23.1nb2. Their current value is shown below:
* GAMEDATAMODE = 444
* VARBASE = /var
Based on these variables, the following variables have been set:
* TERMCAP_TYPE = termcap
You may want to abort the process now with CTRL-C and change their value
before continuing. Be sure to run `/usr/bin/make clean' after
the changes.
==========================================================================
=> Build dependency gmake>=3.81: found gmake-3.81
=> Build dependency pkg-config>=0.19: found pkg-config-0.23nb1
=> Build dependency x11-links>=0.44: NOT found
=> Verifying reinstall for ../../pkgtools/x11-links
ERROR: This package has set PKG_FAIL_REASON:
ERROR: pkgsrc has been configured to use a system provided X11 installation
ERROR: but one could not be found. Possible solutions:
ERROR: *) install X headers and libraries in X11BASE (currently /usr/X11R6)
ERROR: *) set X11_TYPE=modular in mk.conf to use X11 from pkgsrc
ERROR: Please note that changing the value of X11_TYPE in existing
ERROR: pkgsrc installations is not supported!
*** Error code 1
Stop.
make: stopped in /usr/pkgsrc/pkgtools/x11-links
*** Error code 1
Stop.
make: stopped in /usr/pkgsrc/editors/emacs
*** Error code 1
Stop.
make: stopped in /usr/pkgsrc/devel/ruby-mode
X11 なんて使わないから！
/etc/mk.conf で手当たり次第に全部無効にしておく
PKG_OPTIONS.emacs = -dbus -gtk -svg -x11 -xft2 -xaw -motif -nextstep
再度 make
gmake[2]: ディレクトリ `/usr/pkgsrc/editors/emacs/work/emacs-23.1/leim' から出ます gmake[1]: ディレクトリ `/usr/pkgsrc/editors/emacs/work/emacs-23.1' から出ます => Unwrapping files-to-be-installed. ===> Installing for emacs-23.1nb2 ERROR: emacs-23.1nb2 conflicts with installed package(s): ERROR: emacs-nox11-22.3nb5 ERROR: emacs-nox11-22.3nb5 ERROR: They install the same files into the same place. ERROR: Please remove conflicts first with pkg_delete(1). *** Error code 1 Stop. make: stopped in /usr/pkgsrc/editors/emacs *** Error code 1 Stop. make: stopped in /usr/pkgsrc/editors/emacs *** Error code 1 Stop. make: stopped in /usr/pkgsrc/editors/emacs *** Error code 1 Stop. make: stopped in /usr/pkgsrc/devel/ruby-mode
んもう！
% cd /usr/pkgsrc/editors/emacs-nox11 % sudo pkg_delete emacs-nox11-22.3nb5
再度 devel/ruby-mode で make して ok
2010-12-28 :-)
_ 夜
1720 アニメイト川崎
1800 飯支度
1900 翻訳
2200 飯
2300 MONOMUSIK on USTREAM: 作曲家浜渦正志の番組を配信します／Masashi Hamauzu on USTREAM.
_ [翻訳][NetBSD][GCC][PCC][コンパイラ]hubertf's NetBSD blog - Article: Competition Among Open Source Compilers
オープンソースコンパイラの競争
Not exactly related to NetBSD, but definitely relevant: David Chisnall's article Competition Among Open Source Compilers talks about some alternatives to the GNU C Compiler (GCC), and why they are of interest to the operating system community (and thus NetBSD, too). Mentioned candidates include TenDRA, the Portable C Compiler (PCC), the Low Level Virtual Machine (LLVM), clang. The summary:
NetBSD 限定ではないのだが、いくらか関連する話題として David Chisnall の オープンソースコンパイラの競争 という記事がある。これは GNU C Compiler (GCC) の代替としてのいくつかの実装と、なぜオペレーティングシステムコミュニティ( もちろん NetBSD も含む )に採用されているのかを話題にしている。TenDRA { TenDRA Compiler - Wikipedia, the free encyclopedia } 、the Portable C Compiler (PCC)、the Low Level Virtual Machine (LLVM)、clang についても触れている。概要はこう:
`Not having to rely on GCC is likely to benefit the BSD family quite a lot. GCC is designed fairly closely with GNU libc in mind, so the project is hesitant to accept improvements that don?t work with glibc (and, by extension, with most Linux systems).
「多くの BSD 系 OS が GCC を利用していると思う。GCC は GNU libc 環境で使われることを前提として設計されているので、glibc が動かない環境での改良には二の足を踏んでいる。( 多くの Linux システムの拡張然り )。
Competition is usually a good thing; in open source projects, where ideas (and, ideally, code) can flow freely between the projects, everybody wins in the end. The more advanced architecture of LLVM makes it a good long-term bet for future systems, and the simple codebase of PCC makes it a good systems compiler. Both are likely to carve out a significant portion of market share in the next few years, giving developers more of choices for compiling their code.''
オープンソースプロジェクトにおいて、競争は普通 良い方向に働く。アイデアとコードはプロジェクト間を自由に行き来できるので、結局はみんなが幸せになれる。LLVM のより進んだアーキテクチャは長い目で見れば将来のシステムに有益であり、シンプルなコードをもとにした PCC は良いシステムコンパイラとなる。これらは今後数年の市場で重要な位置を占め、開発者たちがコードをコンパイルする選択肢はもっと増えるだろう。」
Those interested in trying PCC with pkgsrc can set "PKGSRC_COMPILER=pcc", see Jeremy Reed's blog entry and the the CVS commit log for more information. Also, see (hear :) bsdtalk interview with Anders "Ragge" Magnusson
pkgsrc では "PKGSRC_COMPILER=pcc" とすると PCC を使えるようになる。詳細は Jeremy Reed のブログ記事 や CVS コミットログ を参照。もちろん bsdtalk interview with Anders "Ragge" Magnusson もよろしく :)
_ [GCC][PCC][翻訳][コンパイラ]InformIT: Competition Among Open Source Compilers > The BSD Issue (1)
オープンソースコンパイラの競争 (1)
Since its creation, the C language has been tightly tied to UNIX. C was designed as a portable assembly language for reimplementing UNIX, to make it easier to port to different platforms.
プログラミング言語 C は UNIX のために作られた。C は、 UNIX を再実装するための可搬性のあるアセンブリ言語であり、これにより異なるプラットフォームへの移植を容易にした。
In 1984, Richard Stallman began the GNU (GNU's Not UNIX) Project to provide a clone of the UNIX operating system using entirely Free Software. Because a C compiler is a core component of any UNIX-like operating system, he wrote one: the GNU C Compiler (GCC).
1984 年 Richard Stallman はフリーソフトウェアのみを使った UNIX オペレーティングシステムのクローンを作るために GNU (GNU's Not UNIX) プロジェクトを開始した。C コンパイラはあらゆる UNIX ライクオペレーティングシステムのコア部分であり、それを GNU C コンパイラ( GCC )と呼んだ。
Over the years, GCC was rewritten a few times, and support for various languages was added. When it began to support more languages than just C, the name was changed to the GNU Compiler Collection, keeping the same GCC abbreviation. As with other parts of the GNU Project, GCC uses the GNU General Public License, although it has a special exception for any parts of the compiler that are embedded in the compiled output.
数年間で GCC は何度か書き直され、いくつかの言語サポートを追加した。もはやサポートする言語は C だけではないので、GNU コンパイラコレクションと名前を変更した。GCC という略称はそのままである。他の GNU プロジェクトと同様に GCC は GNU General Public License を使用する。ただし、GCC で生成された成果物には GPL は適用されない。
The BSD Issue ( BSD の場合 )
Although the GNU Project has GCC, and most proprietary UNIX systems have their own compilers, the BSD projects typically have none. In the base system of any BSD system, GCC is the largest piece of GPL'd code. Over the years, it periodically looked as though TenDRA might replace it. TenDRA, a BSD-licensed C compiler originally started by the Defence Evaluation and Research Agency (the institution that used to be the UK's equivalent of DARPA) focuses on correctness, and would be a good match for systems like OpenBSD, but progress has been slow.
GNU プロジェクトには GCC がある。多くのプロプライエタリな UNIX システムには独自のコンパイラがある。しかし BSD プロジェクトには無い。BSD のベースシステムにおいて、GCC は最大の GPL コード量を占める。TenDRA が数年かけてこれを置き換えた。TenDRA は防衛評価研究局 (DARPA が利用する機関) により始められた 正しく実装することを目標とした BSD ライセンスの C コンパイラである。これは OpenBSD にうまくマッチした。しかし進捗は遅かった。
Recently, another option appeared from an unexpected direction. Back in the 1970s, Stephen Johnson of Bell Labs wrote the Portable C Compiler (PCC). Unlike many earlier compilers, it had a clean separation between the parser and code-generation stages, allowing it to be ported to new architectures easily - a feature present in most newer compilers. This compiler was included with a lot of UNIX variants, including 4.3BSD-Reno.
最近 別の発展を遂げたコンパイラがある。1970 年 ベル研の Stephen Johnson が Portable C Compiler (PCC) を書いた。他の既存のコンパイラと違い、解析部とコード生成部が綺麗に分割されており(最新のコンパイラでも採用されている)、新しいアーキテクチャへの移植が容易だった。PCC は 4.3BSD-Reno を含む多くの UNIX に導入された。
PCC never underwent the same degree of growth as GCC, and remains a very small project. The source code is under 1 megabyte (compressed), and compiling it on a 1 GHz machine takes only a few seconds, whereas compiling GCC on the same machine takes most of an afternoon. PCC isn't as strong in terms of optimization as GCC, but its small size makes it much easier to verify that the output is correct.
PCC は GCC と別の発展を遂げ、いまだにプロジェクトは非常に小さいままである。ソースコードは 1メガバイト以下 (圧縮して) だし、1 GHzのマシンであっても数秒でコンパイルが終わる。それに比べて GCC で同じコードを同じマシンでコンパイルすると、午後が潰れる。PCC は GCC ほど最適化に力を注がない。その代わりにサイズが小さいので、成果物が正しいのか検証が容易だ。
In September 2007, PCC was imported into the OpenBSD source tree, with the aim of evaluating it as a GCC replacement for future releases. A simple compiler is very attractive to the BSD communities - particularly one that's portable. GCC has a habit of changing the interface to the back end, orphaning architectures. This behavior has resulted in some ports of NetBSD, for example, having to stick with old versions of GCC, since no one with the expertise to maintain the compiler port is willing to do so.
2007 年 9 月 PCC は OpenBSD のソースツリーに取り込まれた。将来のリリースで GCC を置き換えるために評価中である。シンプルなコンパイラは BSD コミュニティにとって非常に魅力的である(可搬性があればなおよい)。GCC はマイナーなアーキテクチャにたいしてはインターフェースをよく変更してくれる。NetBSD のいくつかの port ではこの影響を受けた。たとえば、port 用のコンパイラをメンテナンスできるひとが居ないときに古い GCC を持ってなければならなくなる。
It's difficult to overstate the relative complexity of GCC versus PCC. The codebase for GCC is almost 100 times the size of the PCC codebase. The OpenBSD team hopes that this difference in scale will make getting involved with PCC development a lot less daunting than getting involved with GCC.
GCC と PCC についてさらに深く掘り下げることは難しい。GCC のコード量は PCC 100 倍もあるのだ。OpenBSD チームは、このコード量の差異から、GCC を深追いするよりも PCC を開発するほうが楽になってくれることを期待している。
PCC began life on the VAX, and didn't support x86 until very recently. The port took one person less than a week, which makes supporting other architectures seem quite plausible; the total amount of x86-specific code comes to less than 4,000 lines.
PCC は VAX とともに生を受け、最近になるまで x86 をサポートしていなかった。移植はたった 1 人の人間が 1 週間もかからずに完了させた。他のアーキテクチャもすぐにサポートできるようになるだろう。x86 用のコードは 4000 行にも満たなかったのだから。
_ [BSDライセンス][GPL][ライセンス][GCC][LLVM][翻訳][コンパイラ]InformIT: Competition Among Open Source Compilers > An Advanced Architecture (2)
オープンソースコンパイラの競争 (2)
An Advanced Architecture ( 先端のアーキテクチャ )
The GCC design has gradually evolved since the project's creation, and adopted some more modern design principles. Static single assignment (SSA) was one of the more recent large changes, back in 2005. The principle of SSA is that each variable should hold only one value ever. This rule is enforced in the language in something like Erlang, or in the intermediate form in a C compiler. Consider some C code of the following form:
GCC は作成されてからモダンな設計を取り入れながら徐々に発展してきた。2005 年の Static single assignment (SSA) { 静的単一代入 - Wikipedia } は最近ではかなり大きな変更である。SSA の基本思想は、各変数がたった 1 つの値を持つ、というものである。これは Erlang が似たような規則を採用しており、C コンパイラでは中間状態として使われる。以下のような C コードがあるとする:
a = b; a += c;
This code doesn't conform to the SSA principle, so the compiler would replace it with something like this:
このコードは SSA の規則に当てはまらないので、コンパイラは以下のように置換する:
a1 = b; a2 = c;
All future uses of a would be replaced with references to a2, until the next assignment to a. This form allows a number of optimizations to be accomplished quite easily. Describing it as "new" is somewhat misleading, however; the original paper proposing it was published in 1985. Most modern compilers, including the newer versions of PCC, use some kind of SSA form.
これ以降 a に値が代入されるまで、置換された a2 への参照を使うことになる。これにより、最適化がかなり容易になる。このアイデアは新しいように見えるが、じつは最初の論文は 1985 年に書かれている。新しいバージョンの PCC を含み、モダンなコンパイラはほとんど SSA を利用している。
While GCC has accreted design components, another compiler was written from scratch based on the latest ideas in compiler research. The Low Level Virtual Machine (LLVM) is designed to focus heavily on optimization. Like Java and .NET, it uses a virtual machine to define an intermediate form; however (as the name suggests), this machine is quite low-level, and not tied to any particular language.
GCC が巨大化していく一方で、他のコンパイラは最新のコンパイラ研究にもとづいて 1 から書かれた。Low Level Virtual Machine (LLVM) は最適化を重要視して設計された。Java や .NET のように仮想マシンを内部に持つ。しかし (名前から分かるように) LLVM は低レベルすぎて他の言語には使いづらい。
Originally, LLVM used code taken from GCC to handle parsing. This approach changed slightly with release 2.1 in September 2007. A new, Apple-developed front end was introduced, with support for C, C++, and Objective-C, under the name clang.
もともと LLVM は、解析するために GCC からコードを受け取っていた。このアプローチは 2007 年 9 月の release 2.1 で多少変更された。C、C++、そしてObjective-C をサポートするアップルの開発用フロントエンド clang に取り込まれた。
Part of the motivation for developing clang came from a criticism often leveled at GCC: that it's difficult to separate out the front-end and back-end code. When you edit code in something like Microsoft's Visual Studio, you can use the same code for parsing the code to generate syntax-highlighting information as you use for code generation. The same is true of most LISP and Smalltalk environments. This isn't the case with something like Apple's Xcode, however, which has to implement its own parser for syntax highlighting and code completion. This setup is less than ideal for developers, because parsing errors in the IDE don't necessarily correspond to code that won't compile, and vice versa.
clang を開発するモチベーションの一部は GCC への「フロントエンドとバックエンドを分離しづらい」という批判から来ている。Microsoft の Visual Studio でコードを書くとき、コードが解析され、シンタックスハイライトにより、まるであなたがコードを書いたように見えるだろう。これは LISP や Smalltalk 環境とまったく同じである。アップルの Xcode は多少違う点があるが、Xcode 独自の解析部によりシンタックスハイライトが機能し、コードを補完する。これにより、IDE で解析エラーになるので、いちいちコンパイルする手間が省け、開発者の負担が減る。コンパイラの負担も減るのである。
Extracting the front end from GCC for this purpose is difficult for two reasons. First, GCC is released under the GNU General Public License, which means that any other program built using it is required to be under the same license. Second, GCC intentionally ties the front and back ends into the rest of the code quite closely, to avoid "semi-proprietary" forks. In contrast, LLVM is BSD-licensed and has comparatively clean separation between the various layers.
GCC からフロントエンドを分離することは、2 つの理由により難しい。1 つは、GCC の最初のリリースが GNU General Public License に基づいており、GCC でビルドだれたプログラムを使うためには同じライセンスを適用しなければならないということ。{ ????? } 2 つめは、フロントエンドとバックエンドが密結合しており、準プロプライエタリとして派生させて使えないということ。対照的に、LLVM は BSD ライセンスで、いくつかの層{ フロントエンドとバックエンドのことか ? }は比較的綺麗に分離されている。
_ [VM][仮想マシン][LLVM][翻訳][コンパイラ]InformIT: Competition Among Open Source Compilers > A Low-Level Virtual Machine? (3)
オープンソースコンパイラの競争 (3)
A Low-Level Virtual Machine? ( LLVM って? )
The concept of something that is both "low-level" and a "virtual machine" (VM) is slightly strange. Most virtual machines are either very abstract or consist of only very thin abstraction layers. Perhaps the lowest-level virtual machine is Xen, which has the same non-privileged instructions as x86, but different privileged ones.
「低レベル」と「仮想マシン(VM)」のコンセプトは多少違う。ほとんどの仮想マシンは、高度に抽象化されているか、または高度に抽象化された層を持っている。おそらく最も低レベルな仮想マシンは Xen で、Xen は 1 つの特権命令と x86 と同じ非特権命令を持っている。
At the opposite extreme is something like the Java virtual machine. Java bytecode runs on a virtual-stack-based machine (all of the real stack-based machines except x87 having died out a long time ago). This is very different from any real machine, although it has some passing similarities to old LISP machines. The Java VM makes a number of assumptions about the code running on it, making it difficult to run anything that's not a strongly typed language with a Java-esque system.
Java 仮想マシンとまったく違う点である。Java バイトコードは virtual-stack-based で走る ( x87 以外の real stack-based machines はだいぶ前に滅びた )。これは実際のマシンとは大きく異なる。むしろ昔の LISP マシンをシミュレートしていることに近い。Java VM は、Java-esque システムであればどのような言語でも走らせることを可能にするための基盤である。
The abstract machine presented by LLVM is somewhere between the two. It's close to an unlimited register machine (URM), which is a fairly common theoretical model for computing. A few things mark it as being different from a real computer:
LLVM による抽象マシンは 2 つ異なる点がある。レジスタマシン ( unlimited register machine (URM) ) に閉じたものであり、これは理論計算機のモデルである。{ ?????????? } 実際のコンピュータと異なる点をいくつか挙げる:
- Each register is typed. In most computers, registers are typed to the extent that they are integer or floating-point quantities, but the LLVM type system goes far beyond this level.
- Each register is single-assignment. As discussed earlier, this form makes it much easier to perform a number of classes of optimization.
- 型付けされたレジスタ: ほとんどのコンピュータは、レジスタは整数か浮動小数点の幅を持った型になっている。LLVM ではこのレベルを超えている { ?????? }
- レジスタは 1 つの値を持つ: 先にも書いたが、これにより最適化が容易になる
Compiling with LLVM is a two-stage process:
LLVM の 2 ステージプロセスでのコンパイル
1. The first step is to compile a program from source code to bytecode for the abstract machine. For some languages, this process may be two steps, going via a language-specific bytecode. After this, there are a few options.
1. 最初のステップでは、抽象マシン向けにソースコードをバイトコードへコンパイルする。いくつかの言語では language-specific バイトコードを生成するために 2 ステップかかるだろう。この処理のあといくつかオプション処理があったりする。
2. The LLVM bytecode can be interpreted directly. This is nice for debugging, since the entire state of the machine can be inspected, and none of the type information has yet been lost.
2. LLVM バイトコードはダイレクト割り込み可能である。これはデバッグ時に嬉しい。マシン全体の状態を調査でき、型情報をまったく損なわない。
The bytecode also can be compiled to native code, either as a single-step operation or as part of a profiling-directed optimization pass. This arrangement allows the optimizer to examine the runtime behavior of the code and compile it on the fly. Alternatively, of course, it can be distributed in bytecode form, which is hardware-agnostic, and then compiled at install time, or JIT-compiled as it runs with the additional profiling information.
バイトコードはネイティブコードとしてもコンパイルできる。1 ステップでプロファイルと最適化がおこなわれる。これにより最適部がコードを実行しながら評価したり、じかにコンパイルできる。{ ???????? } もちろん ハードウェア依存のバイトコードとしても配布できるし、インストール時にコンパイルしたり、{ ?????? } JIT コンパイルすればプロファイル情報を付加することもできる。
_ [GCC][翻訳][コンパイラ]InformIT: Competition Among Open Source Compilers > The End of GCC?
オープンソースコンパイラの競争 (4)
The End of GCC? ( GCC の終焉? )
Before predicting the end of GCC, it's important to understand the role it fills. One big reason for using GCC is that it's portable. You can use the same compiler on a wide collection of operating systems and architectures. GCC isn't bad at optimization, either, although less-portable compilers tend to do better on the specific platforms they target. Having to support only a single compiler can reduce development costs, however.
GCC の終焉を語る前に、1 つ役割を理解しておくことが重要だ。GCC を使う大きな理由として、可搬性がある。GCC は、幅広いオペレーティングシステムとアーキテクチャ上で利用できる。GCC の最適化は、可搬性に欠けたプラットフォーム上のコンパイラと比較しても悪くない。それに 1 つのコンパイラだけを使うことにより開発のコストを下げることができる。
The main reason that GCC exists is to be Free Software. The GNU Project requires a compiler that's capable of building the GNU system. Both of the compilers I've discussed in this article are Free Software, but they're available under the permissive terms of BSD-style licenses. This fact makes them less attractive to the Free Software Foundation, because these licenses permit making proprietary forks.
GCC のおもな存在意義は、フリーソフトウェアであるということだ。GNU プロジェクトは GNU システムをビルドするために有能なコンパイラを求めている。私がここで言っているコンパイラはどれもフリーソフトウェアだが、寛容な BSD ライセンスである。これらのライセンスはプロプライエタリなものを生成できるので、はフリーソフトウェア財団からはあまり宜しく思われていない。
While the Free Software Foundation is nominally in charge of GCC, a lot of development is funded by the likes of Apple and Red Hat. Making a closed-source fork of the compiler is not in the best interest of either of these companies, since they don't sell compilers - they give them away, to encourage people to write software for their platforms. (Red Hat also gives the rest of the platform away, to encourage people to pay for Red Hat support.) Apple, on the other hand, would very much like to be able to use components of the compiler combined with other, proprietary components. This desire is what attracted Apple to LLVM as a compiler for OpenGL shaders (code which is now making its way into the open source OpenGL clone Mesa), and led do development of the clang front end for LLVM.
フリーソフトウェア財団は建前上は GCC を担当しているが、実際にはアップルやレッドハットよって大部分が開発されている。これらの会社はコンパイラを売っていないので、クローズドソースなコンパイラを作ることはこれらの会社からはよく思われない。彼らのプラットフォームでコードを書くように仕向けているのだ{ ?????? }。( レッドハットはプラットフォーム以外でコートを書く場合は Red Hat にサポート料金を支払わせるようにしている )。他方、アップルは、GCC のコンポーネントとプロプライエタリなコンパイラコンポーネントをうまく組み合わせられるようにしている。これによりアップルは、 OpenGL シェイダーコンパイラのために LLVM を作った ( このコードはオープンソースとして、OpenGL クローンの Mesa になった )。LLVM のフロントエンド clang の開発を引率するようになった。
Another strength of GCC is the languages it supports. With GCC, you can compile C, C++, Objective-C, Fortran, Java, and Ada. It also has some support for Pascal, Mercury, COBOL, Modula-2, Modula-3 VHDL, PL/1, and UPC. In contrast, PCC supports only C, with experimental support for Fortran. LLVM supports C and C++, with experimental support for Objective-C and Stacker (a stack-based language).
他にも GCC の強みとして言語サポートがある。GCC を使えば C, C++, Objective-C, Fortran, Java, そしえｔ Ada をコンパイルできる。また、Pascal, Mercury, COBOL, Modula-2, Modula-3 VHDL, PL/1, そして UPC もいくらかサポートしている。対称的に PCC のサポートは C のみだ。Fortran サポートはまだ実験的である。LLVM は C、C++、そして実験的であるが Objective-C と Stacker ( スタックベースの言語 ) をサポートしている。
From my perspective, one of the most interesting things about GCC at the moment is that it's the only Objective-C compiler that works with either Apple's Cocoa or GNUstep. This situation is likely to change soon, as the clang front end becomes more mature, which is likely to benefit all Objective-C developers as a result of competition between the projects.
個人的には、GCC のもっとも面白いのは、アップルの Cocoa か GNUstep では Objective-C をサポートしているのが GCC のみであるとうことだ。clang フロントエンドが熟せばこの状況は変わるだろう。Objective-C 開発者たちにとってプロジェクト間の競争となり、よい結果をもたらすだろう。
Not having to rely on GCC is likely to benefit the BSD family quite a lot. GCC is designed fairly closely with GNU libc in mind, so the project is hesitant to accept improvements that don't work with glibc (and, by extension, with most Linux systems).
多くの BSD 系 OS が GCC を利用していると思う。GCC は GNU libc 環境で使われることを前提として設計されているので、glibc が動かない環境での改良には二の足を踏んでいる。( 多くの Linux システムの拡張然り )。
Competition is usually a good thing; in open source projects, where ideas (and, ideally, code) can flow freely between the projects, everybody wins in the end. The more advanced architecture of LLVM makes it a good long-term bet for future systems, and the simple codebase of PCC makes it a good systems compiler. Both are likely to carve out a significant portion of market share in the next few years, giving developers more of choices for compiling their code.
オープンソースプロジェクトにおいて、競争は普通 良い方向に働く。アイデアとコードはプロジェクト間を自由に行き来できるので、結局はみんなが幸せになれる。LLVM のより進んだアーキテクチャは長い目で見れば将来のシステムに有益であり、シンプルなコードをもとにした PCC は良いシステムコンパイラとなる。これらは今後数年の市場で重要な位置を占め、開発者たちがコードをコンパイルする選択肢はもっと増えるだろう。」
2011-12-28 :-(
_ 劇場版 けいおん! を見てきた
＠チネチッタ
仕事の帰りにでもイケばいいものを今更になってようやく見た。
なんというかいつもどおりの けいおんだった。
衣擦れの音がヤケに生々しかったり、メンバーが並列で会話してたりと演出が細かいんだがテレビシリーズもこうだったかどうだったか。キャリーケースに派手な色のバンド(?)を装着していたんだが、アレやっておくと手荷物を受取るときなどに自分の荷物が目立つんである。というライフハックを私も親から教わった。そういうところも描いてるとか
_ NetBSD はマイナーなので使っている。FreeBSD はメジャーだし。まあ OpenBSD はさらにマイナーだろうけど (´ω｀；)
などと思っていたんだが
NetBSD のほうがマイナーだった
(ref. Comparison of BSD operating systems - Wikipedia, the free encyclopedia )
2013-12-28 :-)
_ 午前
1030 起床 && 部屋掃除
_ ながら型巡洋艦
艦これプレイしながら meta-pkg/xfce4 とか wm/fluxbox とか www/firefox をビルドしたりなど。xfce4 は cpan XML::Parser が install できん。なんぞ
_ [艦これ]艦これ
E-2 挑戦。南ルートいくと 1 回の出撃で 600 くらい資材溶けるし、もうやだこの海域...
霧の艦隊は期間限定らしいから近代化改修やってなかったんだが、タカオは改修したほうがいいという話なので( 艦これ通信～攻略速報～ : 【艦これ】E-2はイオナ、タカオ、戦、雷、正空を適当に混ぜた編成でゴリ押しするのが正解 )、火力を MAX にして、さらにキラ付けして、あとは道中のマヤ戦、最後のボス戦で大破されないように祈るのみ。
ハイパーズが居るし夜戦まで持ち込めれば勝てるんだよなあ
2014-12-28 :-)
_ 午前
1030 起床
_ 今日は日曜日だったか
コミケ 1 日目はいつも金曜日なので調子が狂う。
_ 応答せよ、おうちサーバー
コンソールも反応しないので再起動させた。原因調査できるくらいのスキルを身につけないと。
- コンソール反応せず
- ログインできず
- 再起動後にログを見ると 12/27 21 時ころの tinydns のログが最期
- top をしばらく眺めてると定常的に ruby と python が高負荷になっている
- ruby の実行者は www なので tdiary が攻撃でも食らってるぽい。んだが、それほどの負荷なのか確証が持てん
- python の実行者はたぶん denyhosts 。つまり定期的に ssh 攻撃を食らってるぽい。んだが、それほどの負荷なのか確証が持てん
隣人(謎) のサーバーの負荷を眺めるとそんなに CPU 食ってないので、うちのがなんかアレなのか。なんだろう。アクセスされるのはどうしようもないんだけど、うーん。
2015-12-28 :-)
_ [艦これ]艦これ 間宮のお手伝い
結局ひたすら 1-4 を周回するのがコストが低くてよい。1-5 や 2-5 へ行くという手もあるけど、よく大破するのでバケツの消耗が激しい。
ぜかましねっとさんの編成をパクった編成と、潜水艦x6 の 2 編成でひたすら回していた 師走の「間宮」のお手伝い－お飾り・プレゼント箱を集めよう - ぜかましねっと艦これ！
2016-12-28 :-(
_ 労について
実機のコンソールが効かなくなったワーワーとバタバタしていたところ結局フレキシブルケーブルが抜けていただけでした。フレキが繋がっている片方はチェックしたんだけどもう片方側はチェックしてなかったので気づきませんでした。こういったハードウェアのトラブルについてカンが働くような会社人になりたいです。
今日は仕事納めというやつでした。派遣先でも自社でも納会が予定されていましたがどちらも参加していません。
_ 買い物
B00FGL9QVW
2018-12-28 :-|
_ [艦これ]艦これ 2019冬イベント 邀撃！ブイン防衛作戦 E-1「ブラケット水道/クラ湾沖」
邀撃！ブイン防衛作戦 - 艦隊これくしょん -艦これ- 攻略 Wiki*
※既に冬イベ2018があること、開催期間は2019年のほうが長くなることから本イベントは便宜上「冬イベ2019」とすることが公式に発表されています。
2019冬イベントらしい。
E1 は甲クリア。
輸送ゲージ
駆逐x4 で最短ルートとのこと。村雨に特攻があるらしいので入れます。
出撃1回目は大発動艇をガン積みしたんですが、2回目以降わりと大破するので
気休めに主砲を乗せました。まあ相変わらず大破します。
決戦支援は軽めに出しました。うちの主力艦隊の編成だと決戦支援があるほうが無難かなあという感じ。無くてもよさげ。
1回目の大発動艇ガン積みしたときの輸送量。2 回目以降は大発動艇を減らしたので、たしか 64 TP だった気がする。
戦力ゲージ
【艦これ】19冬イベ攻略情報(甲)まとめ【12/28最新】:Lambda39のブロマガ - ブロマガ
軽巡2 駆逐4 水上電探5隻以上(旗艦には必須) 村雨必須 BHCL
とのこと。
決戦支援はあるほうがよいです。うちはキツかった。
最終形態
村雨まで攻撃してやっとトドメでした。
レア艦？
2019-12-28 :-)
_ 電撃ゲーム生放送 もういくつ寝るとお正月スペシャル！ 『リリフレ」＆『ゆゆゆい』 を見ました
木曜日に生放送してたんですが見逃したので。
リリフレメンバーへの問題 第一問とか
irb(main):011:0> [19, 25, 15, 21, 7, 1, 20, 19, 21].map {|x| ('A'.ord + x - 1).chr}.join
=> "SYOUGATSU"
2020-12-28 :-|
_ 他人と会話するとカロリーを消費する
だいたいの場合 黙ってモクモク(頭痛が痛い)しているのでカレー機関へ行って艦娘遊撃隊の女性たちが居ても面倒くさくて会話しないんだがタイムラインでは積極的に艦娘遊撃隊の女性たちと会話している提督たちがチラホラ居るのでコミュ力たけえなあと想うだけでモクモクと眺めている。
_ 日誌
0620 起床
散歩
0815 出勤。在宅勤務
1715 退勤
渋谷。水瀬しあの渋谷タワレココラボでパネルにサインが追加された。
結目ユイの渋谷タワレコカフェコラボドリンクを買った。
飯。ケンタッキーフライド・チキン。28 日は「良い鳥の日」だそうで、セットが売っていたので買った。
艦これ E4-3 甲クリア。数年ぶりの甲勲章。さて Scirocco を掘らねば。
水瀬しあ。人類滅亡しような。ちなみにリスナー常連もなぜ「人類滅亡」なのか誰も知らない。水瀬しあが知るのみ。
結目ユイ。カフェというかコラボのドリンクがある。カフェ自体とコラボしているわけではないのでカフェでドリンクを飲むことはできない。なおカフェは現在 銀魂とコラボしている。
温めて飲むと美味い。
2021-12-28 :-(
_ 業務日誌
0800 出勤。在宅勤務
自社へ移動。仕事場においてある PC が反応しなくなったので。 LAN ケーブルを 2 つ刺してる (社内ネットワークのやつとプロジェクト用のやつ) んだがデフォルトゲートウエイが 2 つになっていたのでネットワークに繋がらなかったもよう。プロジェクト用のやつはいま使ってないので物理的に外しておいた。
1845 退勤
_ 水瀬しあ配信
マイクラがクラックされて荒らされたらしい。いままで作ってきたすべてが破壊されたそうだ。水瀬だけでなく、菜花ななが作ったものや結目ユイのために作ったものもすべて。酷いことをする。
2022-12-28 :-(
_ 日誌
チャッカマンのガスが尽きたので買おうとしたがイトーヨーカドーには無かった。と思う。たばこが売ってるなら隣にライターと一緒に売ってそうだけどイトーヨーカドーにたばこ売ってたっけ。結局セブンイレブンでチャッカマンを買った。
飯。ぶりの照り焼き。舞茸の炊き込みご飯
結目ユイ配信を見る。日清のカレーメシとのコラボが唐突に発表されて驚愕するリスナーたち。青天の霹靂だった。
_ さぁぶ [VB6なんかもp-codeでしたねぇ。たしか。 設定nativeコードと切替えが出来たとは思いますけど。]
_ みわ [さぁぶさん まさにいま VB6 を見てたのでした。コンパイルするときに P-Code にするかネイティブコードにする..]