hello, world
とメモってあったのだが、はて、これを種に何を書こうとしていたのだっけ?w
ああ、思い出した。
OS X での (Objective-C で書いた) GUIプログラムの hello, world ってどんな感じになるのかなあと。
Programming Mac OS X with Cocoa for Beginners/First Cocoa program - Hello World - Wikibooks, open books for an open world
一番初めのObjective-Cプログラム - ＠IT
やら見ても断片的でよくわかんないんですよね。
Linux FreeBSD
えーと、こっちはなんだっけ。
PFDS 読書会の懇親会のときに、Linux (のコード)が企業にも使われるようになったのはなぜか
とか、FreeBSD がそうならなかったのはなぜかという話が出たのですが、
BSD が例の裁判騒ぎで足を引っ張られたからではないか。
裁判でのごたごたを嫌った開発者がLinxuに流れて…
という意見がありました。
これひとつということはないでしょうし、なんでかなあと。
んーもっと書くことあったはずなんだがw
今週の木曜日分(金曜日未明)の更新は多分ありません。
元記事は、JavaScriptでインタラクティブに答えあわせができるようになってます ;)
問題をいくつか紹介。
Will It Optimize?
See how well you know (or can anticipate) gcc's optimizer. For each question, the left
box contains some code, while the right box contains code that purports to do the same
thing, but that illustrates a particular optimization. Will gcc apply that
optimization? Put another way, will the code on the left be as fast as the code on the
right, when compiled with an optimizing gcc?
I used a pretty ancient gcc 4.2.1 for these tests. If newer versions have different
behavior, please leave a comment.
Beware: not all proposed optimizations are actually valid!
1. Recursion elimination
Can GCC replace recursive functions with a loop?
1)
int factorial(int x) {
if (x >1) return x * factorial(x-1);
else return 1;
}
2)
int factorial(int x) {
int result = 1;
while (x > 1) result *= x--;
return result;
}
2. Loop-invariant strlen()
Will GCC hoist out strlen()?
unsigned sum(const unsigned char *s) {
unsigned result = 0;
for (size_t i=0; i < strlen(s); i++) {
result += s[i];
}
return result;
}
unsigned sum(const unsigned char *s) {
unsigned result = 0;
size_t length = strlen(s);
for (size_t i=0; i < length; i++) {
result += s[i];
}
return result;
}
3. Multiplication by 2 to addition - integer
Will GCC transform an integer multiplication by 2 to addition?
int double_it(int x) {
return x * 2;
}
int double_it(int x) {
return x + x;
}
LLVM を使うのをあきらめたとかいうのをどこかで見かけたのですが
Lost in JIT: PyPy's future directions
Saturday, October 8, 2011
PyPy's future directions
The PyPy project was long criticised for being insufficiently
transparent about the direction of its development. This changed
drastically with the introduction of the PyPy blog, Twitter stream,
etc., but I think there is still a gap between the achievements
reported in the blog and our ongoing plans.
This post is an attempt to bridge that gap. Note, however, that it is
not a roadmap -- merely a personal opinion about some interesting
directions currently being pursued in the PyPy project. It is not
intended to be exhaustive.
(略)
Concurrent GC
(略)
JSON improvements
(略)
GIL removal
(略)
Minor improvements left and right
Under the radar, PyPy is constantly improving itself. Current trunk is
faster than 1.6 and has fewer bugs. We're always looking at bug
reports and improving the speed of various common constructions, such
as str % tuple, str.join(list), itertools or the filter
function. Individually, these are minor changes, but together they
speed up applications quite significantly from release to release.
All of the above is the ongoing work. Most of it will probably work out
one day, but the deadline is not given. It's however exciting to see so
many different opportunities arising within the PyPy project.
Cheers,
fijal
定期的に出る話題ですが
Differentiating between function currying and partial function application
(略)
Now, in order to get this started I'd think the best approach should be to start with
a formal definition:
In computer science, partial application (or partial function application) refers
to the process of fixing a number of arguments to a function, producing another
function of smaller arity. Given a function f:(X × Y × Z) → N , we might fix (or
'bind') the first argument, producing a function of type partial(f):(Y × Z) → N.
Evaluation of this function might be represented as fpartial(2,3). Note that the
result of partial function application in this case is a function that takes two
arguments.
Given a function f of type f:(X × Y) → Z , currying it makes a function
curry(f):X → (Y → Z). That is, curry(f) takes an argument of type X and returns a
function of type Y → Z .
Where the following definitions could be used for papply and curry:
papply : (((a × b) → c) × a) → (b → c)
curry : ((a × b) → c) → (a → (b → c))
以下略
最後の二行の比較が印象に残ったのでご紹介。
またもついったから。
Twitter / @ikemo: コンピュータ関係者がRMSみたいな人ばかりなら業界が ...
コンピュータ関係者がRMSみたいな人ばかりなら業界が死んでた。
RMSはプログラム書けるgeek以外の人のことこれっぽちも考えたことないし。
Twitter / @ikemo: 自分の母みたいにコンピュータの仕組みが全く分からない ...
自分の母みたいにコンピュータの仕組みが全く分からない人にとってRMSのいう自由がなんの意味を持つのか。
プログラマー原理主義も大概にしてくれ。
rms みたいな人ばかりという仮定は極論に過ぎると思うけれども、
それはそれとしてなぜこうも激昂しているのかなあと疑問に感じていたのですが
(前後のツイートを見ててもこれというのが見当たらなかったし)、
ひょっとしてジョブズの死に対しての rms のコメントにカチンときたんだろうか。
と思った。
