コグノスケ


link 未来から過去へ表示(*)  link 過去から未来へ表示

link もっと前
2020年6月12日 >>> 2020年6月3日
link もっと後

2020年6月12日

懐かしいソフトをインストール

はるか昔(2007年6月7日の日記参照)に購入したピアノ音源PMI Boesendorfer 290を現在使っているPCにインストールしました。

当時の日本代理店はクリプトンでしたが、2008年に違う会社に変わったようです。

それはさておき、ソフトは古くても(13年前!)音源自体はインストールでき、音も正常に鳴ります。Windowsの後方互換性は本当に素晴らしいなと思います。しかしアクティベーションだけがどうしてもできなくて困っています。

オンラインでアクティベートできず

Boesendorfer 290はインストール時にシリアル番号の入力が必要で、インストール後はアクティベーションが必要です。アクティベーションは各PC固有の番号と紐付いていて、別のPCにインストールしたときは再アクティベーションが必要となります。面倒くさいですね。

アクティベーションをしない状態で使い続けると、インストール後5日間に動かなくなってしまいます。


Boesendorfer 290アクティベート画面

購入当時はアクティベート画面の「REGISTER NOW」を押せば、オンラインでアクティベーションできましたが、現在このボタンを押すとエラーになります。


オンラインのアクティベーション、エラーその1


オンラインのアクティベーション、エラーその2

アクティベーション用のサイトのURLが変わったのか、ブラウザの接続警告が出ますし、転送先のサイトでは「そんなページは知らない」って言われます。これはひどい。

オフラインでもアクティベートできず

オンラインがダメならオフラインアクティベーションを試そうと思い「FILL OUT FORM」を押してみましたが、やっぱりダメでした。


オフラインのアクティベーション、エラー

エラーメッセージを見てもInternet browserの何がダメかわかりません。当然、ユーザーとしても対処しようがありません。このソフトを開発した人たちも、まさか13年後にアクティベーションする奴がいるとは思っていなかったでしょう。

これ以上どうにもならないので、サポートに連絡することにしました。Boesendorfer 290の販売はNative Instruments社、開発はEastWest社とありますが、どこに連絡すれば良いかわかりません。とりあえず販売Native Instruments社のサポートに連絡してみようと思います。

編集者:すずき(2020/06/21 14:51)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2020年6月6日

Kindle Fireの本が消える病

目次: Kindle

割と昔からですがKindle Fireがストアで買った本を認識しない(ダウンロードしない、一覧に出てこない)病気が頻発し、買ったはずの本が消えて、非常に困っています。

Kindle Fireがロストした本は、Kindle for PCだとあっさり捕捉できますから(「新しい商品」順に並べると確認しやすい)、Kindle Fireのバグだと思われます。

根本対策は不明ですが、対症療法はいくつかあります。お手軽な順に、

  • 本の一覧を表示、フィルター「すべて」「ダウンロード済み」を何度か切り替える(3割くらい成功)
  • 対象の本のタイトルを検索ウインドウに入れて検索する(8割くらい成功)
  • Kindle ストアで対象の本を探し「ダウンロード」ボタンを押す(9割9分成功)
  • ファクトリリセット(これでだめならKindle Fireのバグ)

Kindleストアも割と曲者で、複数のダウンロードボタンがある変な仕様2018年11月17日の日記参照)です。1回押してダメでも諦めず、他の種類のダウンロードボタンも押してください。どれかが成功すればラッキーです。

最終手段ファクトリリセットには1度だけお世話になりました。しかし再設定、再ダウンロードにかなり時間を浪費して辛いので、できればもう二度とやりたくありません。

Kindle Fireの困ったところ

Kindle Fireはちょっと変な挙動が多いです。仕様かバグか良くわからないものもあります。

  • 本の表示がずれて読めなくなる(再起動で直る)
  • 本がダウンロードできない病が頻発する(上述)
  • 本の一覧表示が遅い(アップデートで改悪したり、改善したり)
  • 一覧表示の分類がショボい、本が探せない
  • フィルタの「未読」「既読」の数が間違ってる

Kindleのメインであるはずの本の機能さえ、この有様なので、本以外(アプリ、ミュージック、ムービーなど)の機能は一体どうなっていることやら??

メモ: 技術系の話はFacebookから転記しておくことにした。大幅に追記。

編集者:すずき(2021/12/08 04:02)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2020年6月5日

FSF Copyright Assignment

目次: GCC

FSF (Free Software Foundation) のCopyright Assignmentにサインしてみました。とりあえずGCCとbinutilsです。ツールチェーン仲間としてはglibcもやっておけば良かったかも??まあいいか。

手続きは特に難しくなく、

  • assign@gnu.orgに特定のテンプレート(※)でメールを送る
  • 契約書が添付されたPDFが返ってくる
  • 印刷してサイン+日付を書いた後、スキャンしてPDFを送る
  • FSFのサイン+日付が入ったPDFが送られてくる

これで完了です。


送られてくる契約書の先頭部分

FSFからの返事はそれぞれ数日〜1週間程度、という感じでした。GNUのソフトウェアにパッチを送りたいときは、個人でこの契約を交わす(今回はこっち)か、会社の業務で作成している場合は、会社でこの契約を交わす(こっちのやり方は知らない)必要があります。

FSFがなぜこんな面倒なことをしているのかについては、なぜFSFは貢献者に著作権の譲渡をお願いしているのか - GNUプロジェクトに書いてあります。過去に訴えられたり何か嫌なことがあったんでしょうね。

テンプレートは Copyright Papers (Information for Maintainers of GNU Software) を見るとGNUのメンテナーに要求してくれと書いてあります。gnulibのリポジトリにも入っていて、私はこのファイルを送ったらOKでした(gnulibのgitリポジトリにあるrequest-assign.future

Copyright Assignmentを読んでみて感じたこと

FSFのCopyright Assignmentにはいろいろ書いてありますが、

契約者の書いたパッチが契約者のものだと保証せよ
これは契約者を雇っている会社がFSFに著作権を主張してくることを防ごうとしている。
業務上作成したパッチを投稿しなければ満たせる。
FSFの敵に対して協力せよ
契約者が上記の項に反した(会社のコードを投稿したなど)ときに要求されます。
FSFが裁判で勝てるような証拠集めに協力せよ。
FSFが万が一、著作権関係の訴えで負けたら「FSFの被った損害を補償せよ」

読んでいると割と怖い内容ですが、会社で書いたコードを投稿しなければ問題はないです。

契約の範囲はソフトウェア毎(GCC, binutils, glibc, などなど)に契約する必要があります。契約の種類は「1回限り(request-assign.changes)」と「今後ずっと(request-assign.future)」があります。ソフトウェアを改善し続ける場合、毎回契約するのは面倒なので「今後ずっと」を選択すると思います。

契約の種類によってFSFに送るメールのテンプレートが異なります。詳細は Copyright Papers (Information for Maintainers of GNU Software) に書いてあります。和訳ないのかなあ、これ。

編集者:すずき(2023/09/24 11:44)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2020年6月4日

GCCを調べる - その14-2 - genopinitとexpandとpats[].scode

目次: GCC

以前(2020年5月24日の日記参照)、変数の代入操作をexpandで展開する際、代入を分割するか分割しないか、を決める条件の1つとして、optab_handler() という関数が出てきました。この関数の動作に関わるgenopinitというツールの動作を調べます。

前回(2020年6月3日の日記参照)は分岐条件に関わるenum optab_tagの生成について調べました。今回はもう少し複雑なpats[].scodeの生成について調べます。

pats[].scodeって何だ?

突然pats[].scodeと言われても何だかわからないと思います。私もこんなひどい名前の変数、全く覚えられません。復習も兼ねてoptab_handler() を見直します。

分岐条件の1つoptab_handler()(再掲)

// gcc/optabs-query.h

/* Return the insn used to implement mode MODE of OP, or CODE_FOR_nothing
   if the target does not have such an insn.  */

inline enum insn_code
optab_handler (optab op, machine_mode mode)
{
  unsigned scode = (op << 16) | mode;  //★★scodeの意味はここにある通り
  gcc_assert (op > LAST_CONV_OPTAB);
  return raw_optab_handler (scode);  //★★これ
}


// build_gcc/insn-opinit.c

enum insn_code
raw_optab_handler (unsigned scode)
{
  int i = lookup_handler (scode);  //★★これ
  return (i >= 0 && this_fn_optabs->pat_enable[i]
          ? pats[i].icode : CODE_FOR_nothing);
}

static int
lookup_handler (unsigned scode)
{
  int l = 0, h = ARRAY_SIZE (pats), m;
  while (h > l)
    {
      m = (h + l) / 2;
      if (scode == pats[m].scode)  //★★これ
        return m;
      else if (scode < pats[m].scode)  //★★これ
        h = m;
      else
        l = m + 1;
    }
  return -1;
}


//★★pats[] の定義

struct optab_pat {
  unsigned scode;
  enum insn_code icode;
};

static const struct optab_pat pats[NUM_OPTAB_PATTERNS] = {
  { 0x010405, CODE_FOR_extendqihi2 },
  { 0x010406, CODE_FOR_extendqisi2 },
  { 0x010407, CODE_FOR_extendqidi2 },
  { 0x010505, CODE_FOR_extendhihi2 },

...

  { 0x021c1b, CODE_FOR_truncdfsf2 },  //★★この変な数字(scode)0x021c1bは誰が作るのか?

...

コードからscodeの意味、上位16ビットがoptabで、下位16ビットがmachine mode、は理解できると思います。patsにはscodeが無数に並んでいますが、この数字を誰が作るかというとgenopinitです。

optabsとpattern

前に見たoptabsの定義は色々ありますが、必ず2つ以上の引数を取り、1番目がname(mov_optab, trunc_optabなど)、2番目がpatternとなっており、この2つは全ての定義に存在します。

optabsの定義とname, pattern

// gcc/optabs.def

OPTAB_CL(trunc_optab, "trunc$b$a2", TRUNCATE, "trunc", gen_trunc_conv_libfunc)
         '-- name      `-- pattern

このうちnameはenum optab_tagの変数名として使っていました。その他にもcode_to_optab_[] という配列の定義にも使いますが、今はどうでもいいです。前後に文字が付くくらいで、基本的に名前がそのまま使われます。

一方2番目のpattern(例えば "mov$a", "trunc$b$a2" など)はちょっと変わっています。$aや $bという不思議な文字が入ります。

genopinitと *.mdとscode

前回説明したとおりgenopinitの入力はgcc/common.md, gcc/config/riscv/riscv.md, build_gcc/insn-conditions.mdの3つの *.mdファイルです(mdはmachine descriptorの略)。Lispっぽい記法で、define_insnやdefine_expandを追加したファイルです。

基本的なgenopinitの動作は、

  • *.mdを読む
  • optabs.defのpatternとパターンマッチを掛け、pats[].scodeを生成
  • ファイルに出力

パターンマッチのコードはこんな感じです。

genopinitパターンマッチ部分

// gcc/gensupport.h

/* Information about an .md define_* rtx.  */
class md_rtx_info {
public:
  /* The rtx itself.  */
  rtx def;

  /* The location of the first line of the rtx.  */
  file_location loc;

  /* The unique number attached to the rtx.  Currently all define_insns,
     define_expands, define_splits, define_peepholes and define_peephole2s
     share the same insn_code index space.  */
  int index;
};


// gcc/genopinit.c

int
main (int argc, const char **argv)
{

...

  if (!init_rtx_reader_args_cb (argc, argv, handle_arg))  //★★ *.mdを解析
    return (FATAL_EXIT_CODE);

...

  /* Read the machine description.  */
  md_rtx_info info;
  while (read_md_rtx (&info))  //★★RTXを1つずつ取り出す
    switch (GET_CODE (info.def))
      {
      case DEFINE_INSN:    //★★define_insn, define_expandだけ注目
      case DEFINE_EXPAND:
	gen_insn (&info);  //★★これ
	break;


static void
gen_insn (md_rtx_info *info)
{
  optab_pattern p;
  if (find_optab (&p, XSTR (info->def, 0)))  //★★これ
    patterns.safe_push (p);
}


// gcc/gensupport.c

bool
find_optab (optab_pattern *p, const char *name)
{

...

  /* See if NAME matches one of the patterns we have for the optabs
     we know about.  */
  for (unsigned int pindex = 0; pindex < ARRAY_SIZE (optabs); pindex++)  //★★全てのpatternを試す
    {
      p->m1 = p->m2 = 0;
      if (match_pattern (p, name, optabs[pindex].pattern))  //★★これ
	{
	  p->name = name;
	  p->op = optabs[pindex].op;
	  p->sort_num = (p->op << 16) | (p->m2 << 8) | p->m1;  //★★scodeを作る
	  return true;
	}


// gcc/gensupport.h

/* Information about an instruction name that matches an optab pattern.  */
struct optab_pattern
{
  /* The name of the instruction.  */
  const char *name;

  /* The matching optab.  */
  unsigned int op;

  /* The optab modes.  M2 is only significant for conversion optabs;
     it is zero otherwise.  */
  unsigned int m1, m2;

  /* An index that provides a lexicographical sort of (OP, M2, M1).
     Used by genopinit.c.  */
  unsigned int sort_num;
};

申し訳ないですが *.mdファイルの解析関数init_rtx_reader_args_cb(), read_md_rtx() 辺りは調べる予定がありません。どなたか調べてくれたら嬉しいです。

パターンマッチはnameに対して行われ、全てのpatternとマッチするか試します。マッチしなければmatch_pattern() はfalseを返しますから、次のpatternを試します。マッチしたら、結果はoptab_pattern *pに格納され、match_patter() が作り出すp->m1, p->m2という謎の数からscodeが生成されます。

なぜgenopinitではsort_numという変数名にしたんでしょうね?scodeにすればもう少しわかりやすいのに。

パターンマッチm1, m2とscode

パターンマッチのルールと、m1, m2が何者か?については、文章で説明できる気がしないので、例としてname = "truncdfsf2" を見ながら説明したいと思います。マッチするpatternは "trunc$b$a2" です。他のpatternはマッチしません。

genopinitパターンマッチの一例

// gcc/config/riscv/riscv.md

//★★nameの例

(define_insn "truncdfsf2"    ★★名前
  [(set (match_operand:SF     0 "register_operand" "=f")
	(float_truncate:SF
	    (match_operand:DF 1 "register_operand" " f")))]
  "TARGET_DOUBLE_FLOAT"
  "fcvt.s.dt%0,%1"
  [(set_attr "type" "fcvt")
   (set_attr "mode" "SF")])


// gcc/optab.def

//★★ マッチするpatternの定義部分(2番目の引数)

OPTAB_CL(trunc_optab, "trunc$b$a2", TRUNCATE, "trunc", gen_trunc_conv_libfunc)


// gcc/gensupport.c

//★★
//pは結果格納用の変数
//name = "truncdfsf2"
//pat  = "trunc$b$a2"

static bool
match_pattern (optab_pattern *p, const char *name, const char *pat)
{

...
パターンマッチしたときの各変数のダンプ
★★match_pattern() がtrueを返した後、find_optab() がreturn trueで終了する直前でダンプ

(gdb) p optabs[pindex]

$13 = {
  name = 0x4574b5 "trunc_optab",
  pattern = 0x4574c1 "trunc$b$a2",
  base = 0x4574cc ""trunc"",
  suffix = 0x457478 "'\0'",
  libcall = 0x4574d4 "gen_trunc_conv_libfunc",
  op = 2,
  fcode = TRUNCATE,
  rcode = UNKNOWN,
  kind = 1
}


(gdb) p/x *p

$15 = {
  name = 0x4dd270,
  op = 0x2,
  m1 = 0x1b,
  m2 = 0x1c,
  sort_num = 0x21c1b
}

pは結果格納用のoptab_pattern *p

この定義のpatternは2番目の引数 "trunc$b$a2" です。全部繋がっていてわかりにくいですが、下記の4つの要素から構成されます。

  • trunc
  • $b: パターンマッチ その2
  • $a: パターンマッチ その1
  • 2

このうち $aや $bはmachine modeの名前にマッチします。具体的には下記のようになります。

$a, $bパターンマッチの仕組み
nameとpatが

  name = "truncdfsf2"
  pat  = "trunc$b$a2"

の場合、

  $b -> df
  $a -> sf

にマッチします。$a, $bのマッチを調べるときはmode_nameを先頭から検索(大文字小文字の違いは無視)します。
全モードの名前はmode_name[] という配列に入っています。

  $bはmode_name[28] = "DF" と一致する。
  $aはmode_name[27] = "SF" と一致する。

match_pattern() は一致したモードの番号をm1, m2に格納します。
つまりoptab_patternのm1, m2の意味はそれぞれ

  m1: $aがマッチしたモードのインデックス、今回だと27 = 0x1b (E_SFmode)
  m2: $bがマッチしたモードのインデックス、今回だと28 = 0x1c (E_DFmode)

結果scodeはこうなります。

  p->sort_num = (p->op << 16) | (p->m2 << 8) | p->m1;
              = (2 << 16) | (28 << 8) | 27;
              = 0x21c1b

// build_gcc/insn-opinit.c

static const struct optab_pat pats[NUM_OPTAB_PATTERNS] = {
...
  { 0x021c1b, CODE_FOR_truncdfsf2 },  //★★この値が生成された

謎のpats[].scodeはこんな仕組みで生成されていたのでした。ややこしいですね。

編集者:すずき(2023/09/24 11:51)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2020年6月3日

GCCを調べる - その14-1 - genopinitとexpandとenum optab_tag

目次: GCC

以前(2020年5月24日の日記参照)、変数の代入操作をexpandで展開する際、代入を分割するか分割しないか、を決める条件の1つとして、optab_handler() という関数が出てきました。optab_handler() の動作を決めるgenopinitというツールの動作を調べます。

バイナリはbuild_gcc/build/genopinitに生成されます(以降build_gccはGCCのビルドディレクトリを指すものとします)。実行する際の引数は下記の通りです。

genopinitの使い方(再掲)

# build_gcc/Makefile

s-opinit: $(MD_DEPS) build/genopinit$(build_exeext) insn-conditions.md
	$(RUN_GEN) build/genopinit$(build_exeext) $(md_file) \
	  insn-conditions.md -htmp-opinit.h -ctmp-opinit.c


# ビルドログ

build/genopinit ./gcc/gcc/common.md ./gcc/gcc/config/riscv/riscv.md \
  insn-conditions.md -htmp-opinit.h -ctmp-opinit.c

上記のビルドログでは一時ファイルに出力していますが、最終的にはbuild_gcc/insn-opinit.h, build_gcc/insn-opinit.cの2つのファイルを生成します。

genopinitとenum optab_tagの生成

前回はoptab_handler() にブレークポイントを設定するため、enum optab_tagの値を使いました。この値はgenopinitが生成しています。

optab_handler(再掲、前半のみ)

// gcc/optabs-query.h

/* Return the insn used to implement mode MODE of OP, or CODE_FOR_nothing
   if the target does not have such an insn.  */

inline enum insn_code
optab_handler (optab op, machine_mode mode)
{
  unsigned scode = (op << 16) | mode;  //★★以前はop = mov_optab, mode = E_V64SImodeでブレークを掛けた
  gcc_assert (op > LAST_CONV_OPTAB);
  return raw_optab_handler (scode);  //★★次回以降、調べます
}


// build_gcc/insn-opinit.h

enum optab_tag {
  unknown_optab,
  sext_optab,

...

  mov_optab,  //★★この値のこと

...

};

...

typedef enum optab_tag optab;

これらの値はgensupport.cのoptab_defから生成されています。実際にoptab_defの中身を定義するのはoptabs.defファイルです。この *.defファイルは、C言語で素直に書くと重複、冗長になる情報を簡潔に表すための、いわゆるDSL(Domain Specific Language)だと思われます。

DSLっぽいものを使うとき、下記のような邪悪なincludeの使い方をします。GCC凶悪デザインパターンの1つですね。良い子は真似してはいけません。

optab_handler(再掲)

// gcc/gensupport.c

#define OPTAB_DC(o, p, c)          { #o, p, NS, ZS, NS, o, c, c, 4 },
#define OPTAB_D(o, p)  { #o, p, NS, ZS, NS, o, UNKNOWN, UNKNOWN, 4 },

...

/* An array of all optabs.  Note that the same optab can appear more
   than once, with a different pattern.  */
optab_def optabs[] = {
  { "unknown_optab", NULL, NS, ZS, NS, unknown_optab, UNKNOWN, UNKNOWN, 0 },
#include "optabs.def"  //★★上記のようにoptabs.def内で使われるマクロを、都合の良い定義に変えてからinclude
};


// gcc/optabs.def

OPTAB_DC(mov_optab, "mov$a", SET)  //★★マクロの定義はincludeされる場所によって違うので、展開後の結果は場所による
OPTAB_DC(movstrict_optab, "movstrict$a", STRICT_LOW_PART)
OPTAB_D (movmisalign_optab, "movmisalign$a")

...


// gcc/genopinit.c

int
main (int argc, const char **argv)
{

...

  /* Emit the optab enumeration for the header file.  */
  fprintf (h_file, "enum optab_tag {\n");
  for (i = j = 0; i < n; ++i)
    {
      optabs[i].op = i;
      fprintf (h_file, "  %s,\n", optabs[i].name);  //★★optabsの名前を出力
      if (optabs[i].kind != j)
	last_kind[j++] = i - 1;
    }
  fprintf (h_file, "  FIRST_CONV_OPTAB = %s,\n", optabs[last_kind[0]+1].name);

...

せっかくDSLっぽいものがあるのに、genopinitのようにコード自動生成ツールも混ぜて使うのはどうしてなんでしょう?GCCは理解不能です。

編集者:すずき(2023/09/24 11:51)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
2020年6月12日 >>> 2020年6月3日
link もっと後

管理用メニュー

link 記事を新規作成

<2020>
<<<06>>>
-123456
78910111213
14151617181920
21222324252627
282930----

最近のコメント5件

  • link 21年3月13日
    すずきさん (03/05 15:13)
    「あー、このプログラムがまずいんですね。ご...」
  • link 21年3月13日
    emkさん (03/05 12:44)
    「キャストでvolatileを外してアクセ...」
  • link 24年1月24日
    すずきさん (02/19 18:37)
    「簡単にできる方法はPowerShellの...」
  • link 24年1月24日
    KKKさん (02/19 02:30)
    「追伸です。\nネットで調べたらマイクロソ...」
  • link 24年1月24日
    KKKさん (02/19 02:25)
    「私もエラーで困ってます\n手動での回復パ...」

最近の記事20件

  • link 24年3月25日
    すずき (03/26 03:20)
    「[Might and Magic Book One TASのその後] 目次: Might and Magicファミコン版以前(...」
  • link 21年10月4日
    すずき (03/26 03:14)
    「[Might and Magicファミコン版 - まとめリンク] 目次: Might and Magicファミコン版TASに挑...」
  • link 24年3月19日
    すずき (03/20 02:52)
    「[モジュラージャックの規格] 古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタク...」
  • link 23年4月10日
    すずき (03/19 11:48)
    「[Linux - まとめリンク] 目次: Linuxカーネル、ドライバ関連。Linuxのstruct pageって何?Linu...」
  • link 24年3月18日
    すずき (03/19 11:47)
    「[画面のブランクを無効にする] 目次: LinuxROCK 3 model CのDebian bullseyeイメージは10分...」
  • link 24年3月3日
    すずき (03/19 11:07)
    「[解像度の設定を保存する] 目次: LinuxRaspberry Pi 3 Model B (以降RasPi 3B)のHDMI...」
  • link 24年3月14日
    すずき (03/16 23:03)
    「[JavaとM5Stamp C3とBluetooth LE - Bluetoothデバイスとの通信] 目次: ArduinoM...」
  • link 24年3月8日
    すずき (03/16 23:03)
    「[JavaとM5Stamp C3とBluetooth LE - BluetoothデバイスとServiceの列挙] 目次: A...」
  • link 23年6月2日
    すずき (03/16 21:11)
    「[Arduino - まとめリンク] 目次: Arduino一覧が欲しくなったので作りました。 M5Stackとesp32とA...」
  • link 23年5月15日
    すずき (03/16 00:57)
    「[車 - まとめリンク] 目次: 車三菱FTOの話。群馬県へのドライブ将来車を買い替えるとしたら?FTOのオイル交換とオイル漏...」
  • link 24年3月9日
    すずき (03/16 00:56)
    「[車のバッテリー完全に死亡で交換かと思いきや] 目次: 車またまた車のバッテリーが干上がって死にました。写真は撮っていませんが...」
  • link 24年3月10日
    すずき (03/15 03:34)
    「[誕生日] 早いもので41歳になりました。昨年の日記(2023年3月10日の日記参照)を見ると、コロナの流行を心配していました...」
  • link 24年3月6日
    すずき (03/12 01:18)
    「[Raspberry Pi 3 model Bの代わりにROCK 3 model C] 目次: Arduino最近、M5Sta...」
  • link 24年3月4日
    すずき (03/06 00:09)
    「[volatileをnon-volatileで参照してはいけない] 目次: GCC過去の日記(2021年3月13日の日記参照)...」
  • link 20年6月2日
    すずき (03/06 00:06)
    「[GCC - まとめリンク] 目次: GCCGCCについて。GCCを調べる - その1 - ビルドGCCを調べる - その2 ...」
  • link 15年5月9日
    すずき (03/05 03:00)
    「[自作ARMエミュレータ - 今さら気づいたブートローダのバグ] 目次: Linuxずっと気づいていなかった自作ARMエミュレ...」
  • link 23年6月1日
    すずき (03/05 02:59)
    「[自宅サーバー - まとめリンク] 目次: 自宅サーバーこの日記システム、Wikiの話。カウンターをPerlからPHPに移植日...」
  • link 15年5月3日
    すずき (03/05 02:59)
    「[GRUB2が起動しなくなってしまった] 目次: 自宅サーバーサーバにインストールしていたDebian 32bit版 のJes...」
  • link 15年5月2日
    すずき (03/05 02:58)
    「[systemdを使うのをあきらめた] 目次: 自宅サーバー独自ビルドのカーネルだと/sys/fs/cgroupが無いと言われ...」
  • link 15年4月30日
    すずき (03/05 02:56)
    「[Debian 8.0 Jessie] 目次: 自宅サーバーDebianのアップデートが来ていたので、試しに職場のPCをアップ...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDFファイル RSS 1.0

最終更新: 03/26 03:20