ソースコードを皆でマッタリ読もう会(初心者歓迎){}

今の時代にxlibつかうのか…。

http://sartak.katron.org/nh/src/monst.c.txt
ローグライク崇め奉ってる連中は↑読んで
さっさとUNIX板のNethackスレから撤退して欲しいよ

あのbourne shellの悪名高きソースか
気付かなかった

.c はC言語のソースファイル
.h はそのヘッダファイル
.adと.manは何でしょうか。

BSDは、パクリ放題。Appleにもええようにされて
それでも耐えてるドSって感じ。まあ、それと
ソースは関係ないので、読んでもいいんじゃない?

でも一番は自分の興味があったり、使ってたりする
ソースコード。読むんじゃなくて眺める所から始めても
いい。ただし毎日すること。

オープンソースとは言っても作成者以外に誰も読んでいないコードが大半なんでしょ？
でも、誰かが読んでくれているとは思っている。思い込んでいるだけかも。

>>67
どうもです

今日図書館行って借りてきた
毎日興味ある所から少しずつよんでこ

ねぇねぇ、マジレスだがパッチ送るとかそういうのって具体的にはどうするの?
とあるアプリに機能追加してみたら、人も使うかなって感じになったんだけど
MLにも参加してないし、だいたいOSSのそこらの流儀ってよくわからんのですよ。
英語のコミュニケーションも自信ないしなぁ。

ソース　コード　2804
http://quote.yahoo.co.jp/q?s=2804.t&d=c&k=c3&h=on&z=m

まあ使わんけどね。

struct hoge {
unsigned hilo:4;
unsigned lohi:4;
} val;

val.hilo = 1;

でビット並びが 00010000/00000001/10000000/00001000 のどれなのか
コンパイラ依存では使いにくい（ビットフィールドは並び順規定がなくて
詰め込みの都合で前後入れ替わったりもOKだったはず）。結局自分で
unsigned 8bitなフィールドでビット演算すればいいや、みたいなことになる。

>>33
Linux kernelの参考書(特に日本語のやつ)はほとんど参考にならん。
なので>>30にはきついと思う。

読むなら自分で使っていると思われるGNUツールとかかな。

>>33
Linux kernelの参考書(特に日本語のやつ)はほとんど参考にならん。
なので>>30にはきついと思う。

読むなら自分で使っていると思われるGNUツールとかかな。

ボードゲームの考察に使う時間をなくして
再びsource codeの読みふけに参戦する

http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/sh/mac.h.html

>>13
お前、センスないな。

>>61-64
CodeGolfみたいなノリで、コードサイズまで縮めようとしたのかなこれ…それはそれで中途半端だが

#define or else if

とか最初見たとき自分の#defineについての知識を疑ったｗ
なんだコレは、最近のプリプロセッサには俺の知らない機能があるのか？と

>>4
その手を使えば簡単に新種のプログラミング言語をつくれたんだww

オライリーの本って内容濃くて面白いんだけど、実際値段表示を見ると萎えるな。。。
中古で買うと割と安いんだが

ソースコードなんてごくごく僅かな人（ごく一部のハッカー）にしか読まれていないよね。

>>45
何故ベストを尽くさないのか

つ TinierMe

>>19
サンクス。理解した。
ビットフィールドって本でチラっとだけ読んだ事あったけど忘れてたよ。

コンパイラ依存だということさえ頭の片隅にあればおk

>>62
それ(QuarkWM)本気で言っているのか？…！！
こいつは初心者のやってしまうパターンだらけなんだが…

– なにこの腐ったmain()関数は？
– マジックナンバー乱用しすぎ。なに、その11ってのは？
– unsigned intに型定義してIなんかハンガリアン風の命名を普通やらない。
やられると解析やりづらい上に構文強調表示効かなくなる。そんなことするならエディタの補完機能を使う。
– それ以前に命名規約がおかしいし、不必要なマクロ定義がいくつかある。
– includeの使い方が変というか勉強不足。関数とかexternでやるでしょ普通。
– 関数プロトタイプ宣言？なにそれおいしいの？
– 三項演算子の使い方がおかしい。というか三項演算死亡遊戯に酔っている。可読性下げているでしょ。
– カンマの後に半角スペース入れろよ。環境やフォントによっては区別付かないんだぜ。

etc…

ソースコードは書くより読むほうが時間がかかるわけで…。
これのひどさを自覚できないのであれば、まずdwmを読んだほうがいいです。

>>36
cmdutil.cだけちょっと眺めたら、hoge_hoge_or_dieとかいう関数がいくつかあって
「これ何てPerl？」と思ったわw

>>49
この前はOBPagerをビルドするのにエラー箇所を調べていたり、
さらにその前はpiewmのビルドが通らなくてエラー箇所を調べ…。

ビルドでエラー起きたらエラーメッセージを検索して修正方法を
見つけてとか普通にやってる。Quick Hack程度だけどね。
たまにMakefileなんかも修正するね(autoconf使ってないものとか)。

>>53
内容を理解するだけに限定するのであれば英語は勉強するものではないと思うよ。
同じ文章ばかり読んで検証で触り続ける→自然と読めるようになる。

>>43
サンキュー！！！！！！

https://github.com/torvalds
https://github.com/torvalds/linux
https://github.com/torvalds/linux/blob/master/Documentation/ja_JP/HOWTO

>>4
なんつーキモいヘッダーファイルだ。

こんな過疎スレがまだ生き残っていたのかwwww

>>10
そのコード、C99で書き直すとすっきりする予感。

1の努力が試されるとき。

>>30
ffmpegのソース。あれは見といて損は無い。

>59
おまえの(ry
日本だと、そういうのは見えないだけで意外と読まれていると思うよ。
つか、ブログに掲載されているコードなんか毎日読んでいるよな？

たとえばブログ作ってソース書き込んでおけば外出先でも参照できる。
それにHighlightあるからhtml化して読んだら？
ttp://www.andre-simon.de/

読みたいのであればi3とかはお勧めかと思われる。
(コメントやドキュメント丁寧かつ豊富)
ttp://i3.zekjur.net/

読み方はPGやFLOSS関係者でもない限り方法は知られてないのがオチ。
(理解できるかどうかは除いて)ソースコードを読むのは意外と難しいことではないんだけどね。
時間かかるから自分との戦い。

一日で理解できないから一気に読まないとか、誰も教えないしな。

>>32
変な先入観持ってないか？

Understanding the linux kernel

Hoshu Linux

既存のツールキットがどれも気に入らなくて

使ってる環境全て制覇したいけど
まったくはかどらない
集中力が続かないな
印刷して寝ながら見たほうがいいかも

数学と英語の勉強のし直してる
なんか毎日勉強ばっか
それにしても英語ってほんと苦手
英語は日本語の感覚から遠すぎるな
あまりに手応えを感じられないので
息抜きにほかの言語の学習したりしてる

>>71
俺スタイルを貫いた結果だろう
そこはかとなく漂うPerl臭

オーライリーの 詳解Linuxカーネル を読んだ事ある人、感想お願いします

>>1
うせろ

>>49
ハッカーじゃないけど困ったら読むよ。

>>27
BTSがあればそこにでもたたき送れば?
なければメンテナのメールアドレスに送る。

英語は Please apply this patch. でええやん。
内容説明はちゃんとしたほうがいいが、最初は簡単。
patchがrejectされると返答に困ったりするが。

マッタリ

で、どれを読むの？

cp mkdir ls rm…
これらのソースコードを見るはどのパッケージを落とせばいいの？

てっきり音読するスレかと……

>>19
できるよ。
以上。
はい次の方。

>>30
> プログラミング文法（C言語&Perl）の基礎を習いたての人は

まずソースを読むより教科書の写経でいいからガリガリ書いた方がいい。
古典だがK&R(プログラミング言語C)とラクダ本(プログラミングperl)は必修。
人のソース読むのはその後でいいよ。