rui314

# 最初になにをやるのかをコメントで書いておくとコードがぐっとわかりやすくなります。
# コードを書いているときは「ここでは〇〇をやろう」と考えながら書いているわけだけど、
# いったんコードになってしまうとそのメタな情報はなくなってしまうので、
# 読者は「結局これは何をやっているのか」というのを推測しながら読むことになってしまいます。
# コメントで意図を説明しておけば推測に頼らずにすむし、変なコードがあっても意図通り
# なのかバグなのか判別がつきやすい。
#
# なおこれはトップレベルのメソッドです。どういうレイアウトがいいかは
# 他にどんなコードがあるかによりますが、元々の例では単体のこのコードしかないので、
# 単純に引数の合計を計算するだけのものにクラスは不要でしょう。

rui314

• 中学生でもわかるベジェ曲線

• 業務としてオープンソースプロジェクトに参加するのは会社にも本人にも合理的なメリットがあるからそうなってるんだよ

• Cコンパイラをスクラッチから開発してみた（日記）

• 作りたいものを作るには結局大量のコードを書かないといけないことについて

• 難しいプログラムでは自分がいままで書いたコードやこれから書くコードが正しく動くと信じて残りのコードを書く必要がある

• 英語のネットで話題になる技術ブログ記事を書くとどういうことが起こるかということをちょっと書いてみます

rui314

 /// Compute the desired OpenMP runtime from the flags provided.
 Driver::OpenMPRuntimeKind Driver::getOpenMPRuntime(const ArgList &Args) const {
-  StringRef RuntimeName(CLANG_DEFAULT_OPENMP_RUNTIME);
+  OptValue RuntimeName = CLANG_DEFAULT_OPENMP_RUNTIME;
 
   const Arg *A = Args.getLastArg(options::OPT_fopenmp_EQ);
   if (A)
-    RuntimeName = A->getValue();
-
-  auto RT = llvm::StringSwitch<OpenMPRuntimeKind>(RuntimeName)

rui314

Apple Newtonの起動時の問題をこの方法（システムバスのノイズをラジオで聞く）でデバグしたことがある。その問題では、最新のフラッシュイメージが、開発用ハードウェアでは起動するのに実機ではまったく動かなかった（なのでLEDやGPIOなども使えなかった）。でも実機に新しいOSイメージをフラッシュすることはできた。

そこで僕は、システムバスに対してそれぞれ異なる動作をする小さなループをいくつか書いて（なのでループの実行中にバスから出るノイズをラジオで聞くとそれぞれ違う音がする）、起動時に実行されるコードの各所にそれを埋め込んで、AMラジオでバスのノイズを聞いてみた。この仕掛けを使って起動時のコードをトレースしていくことで、問題の場所を1時間ほどでみつけることができた。

多分もっとよい方法もあったのだろうけど、でも面白い方法だったと思う。

https://news.ycombinator.com/item?id=16168499

rui314

// Copyright (C) 2019 Rui Ueyama
// Licensed under the MIT license
//
// This command parses a C declaration. Here are a few examples:
//
//   $ ./cdecl 'int x'
//   x: int
//
//   $ ./cdecl 'int **const *x'
//   x: pointer to const pointer to pointer to int

rui314

FROM ubuntu:latest
RUN apt update && apt install -y gcc make git binutils libc6-dev gdb
RUN adduser --disabled-password --gecos '' user
USER user
WORKDIR /home/user