最終更新: 2010-05-07T20:37+0900
回生ブレーキ作動中に ABSの効きが遅れるだとか、濡れた路面でブレーキを踏んだときにふらつくだとか、そういうクレームをつけられてしまうトヨタは「負け」なんだろうと思う。そんなこと言ってったら最大のリスク因子はドライバーじゃないか。ドライバーがコントロールできない安全な(だけの)車。そんな車だったら俺はいらん。
YouTubeは見逃したのでここの最初の部分に反応してみる。勝間さんは投稿者の名前が「名無し」だったときと「伊藤 大介」というそれらしい名前だったときに何か違いがあると期待している。「伊藤 大介」という一つの名前で投稿された一連の発言に関連があるかのような期待もしてしまう人なんだろうか。
2chでの、投稿者が自由に入力できる文字列に過ぎないものと同じに扱われてしまっている「名前」という単語じゃなく、OpenIDって言っとけば良かったのに……。実在の個人までは特定できなくても、同一性は(ある程度、認証サーバによるのかもしれないけど)保証できるだろうし、セキニンある議論にはそれで十分でしょうに。
最終更新: 2010-05-11T23:07+0900
見た目が英語っぽくなるのが嬉しいだけなのかと思ったら然にあらず。
その結果、A.instanceof(B)を A instanceof Bと書くことができる、ということらしい。
で、ですね、Scalaでも &&や ||を真偽値を返す演算子として使えて、右のオペランドを評価しない短絡評価も期待できる。でも、さっき書いたようにこれは演算子に見えて、あるクラスに属すメソッドの呼び出しとして定義されていると。その実現方法は wota.jpで紹介されているのでおいといて。面白い。収拾のつくなかで、最小限のルールで最大限の一般化を図ったような仕様。バランスのとり方にすごく興味がある。
最終更新: 2010-05-21T11:58+0900
【Q3】電子書籍についてどう思いますか？
- 積極的に読みたい…5%
- 少しは読みたい…13%
- 読みたい作品が電子書籍でしか出てなければ読む…35%
- できれば読みたくない…27%
- まったく読みたくない…16%
- わからない…4%
5%とは。若干の興味がある人を足しても 18%。講談社のメールマガジンを購読する層にはほとんど支持されていない。作品本位で読みたい本のためなら手を出してもいい人と、積極的に遠ざけようとしている人がそれぞれ 3分の1超。なんでだよー。電子書籍の利点は
これらのメリットのためなら、バッテリーが必要、初期コスト(端末代)が必要、書籍フォーマットの端末間での互換性に対する不安、DPI(画面の大きさと細かさ)の不足、耐湿性に対する不安(風呂に持ち込むのを躊躇する)なんて問題は、現在のデバイス(※携帯電話と iPadは含まれません)の水準でも目をつぶれる。必要なのは印刷物に対する 100%に近い(超えてもいい)カバー率だけ。
最終更新: 2010-05-19T16:21+0900
348 nobodyさん 2008/07/27(日) 01:11:32 ID:sEx2Pn85
質問させてください。
サクラエディタに鬼車5.9.1を搭載して正規表現の勉強をしているのですが、手元にある詳説正規表現には
(<)?\w+(?(1)>)
このような例があり、<があれば>のマッチを試みる?ということができるみたいです。
ただ、鬼車はこの表現をサポートしていないみたいです。
http://www.geocities.jp/kosako3/oniguruma/doc/RE.ja.txt
同様のことを鬼車でも実現する方法ってあるのでしょうか？
鬼車は条件付き選択をサポートしていないのが玉に瑕だと、以前から思っている。なんとかできないかと上の例で考えてみたら、こうなった。
(<|)\w+(\1{100}|>)
せこい。姑息だ。100ってなんだよ。こんなの( <abc<<<...(94個の<を省略)...<<<> )にもマッチするじゃねーか。
最終更新: 2011-04-12T20:54+0900
Googleの検索は英字の大文字小文字、ひらがなカタカナの区別だけでなく、カタカナ英語と本物の英単語の違いも無視して検索結果を表示してくれるんだけど、キャッシュのハイライトがそれに追随できていないのが残念。「このページへのリンクにだけ含まれているキーワード」っていうのは要するに「このページの中にこのキーワードは発見できませんでした」っていうことなんだと、うすうす気付いてきた。多いんだもん最近。
キャッシュを使うのは、オリジナルがなくなってる場合、オリジナルの反応が遅い場合、ページが長大でマッチ箇所を見つけられない場合。ハイライトは 3番目のときに役立つ。検索語にジャンプするツールバーボタンがあいまい検索の結果からマッチ箇所を見つけられないのは仕方ないかな、と思えるけど、キャッシュは検索の主体(google)が返してるものだからハイライトされてないとがっかりだよ。
最終更新: 2010-05-29T12:31+0900
Scalaの match-caseが Rubyの case-whenと同等のものにしか見えなくて、Cの switch-case的な使い方しか思いつかない俺は手続き脳？
いいタイミングでパターンマッチの章に到着。途中まで読んだ。caseに書けるパターンの種類は「定数パターン(Cなどでおなじみ)」「ワイルドカードパターン(いわゆる default)」「変数パターン(名前付きワイルドカード。変数はコンストラクターパターンの構成要素を束縛(？)したり、型付きパターンの一部として使ったりもする。必ず？小文字で始める)」「コンストラクターパターン」「シーケンスパターン」「タプルパターン」「型付きパターン(型テスト+型キャスト)」があり、「パターンガード(パターンで表現できない追加の条件)」が付けられる。※(かっこ)内は個人的な解釈であって引用ではない。
コンストラクターパターンに使えるのはケースクラスだけだと思う(試してないけど)。ケースクラスのイメージは const struct。コンストラクタに与えられた全引数を constメンバとして持つ。だからコンストラクタの逆、match式に与えられたオブジェクトを構成要素に分解してマッチング(深いパターンマッチ、らしい)を行えるんじゃないかと。
パターンを書けるのは caseだけではない。変数定義や for式にも書ける。caseが書けるのは match-caseだけではない。部分関数として caseの並びを書ける。コンストラクターパターンに使えるのはケースクラスだけではない。24章で説明される extractors(抽出子)を使えば一般のクラスも使用できる(らしい)。
？ 必ずかどうかは不明。書かれていたのは、1.大文字で始まる定数名はそのままその名前が定数パターン。2.小文字の名前は変数パターン。3.小文字で始まる定数名が存在していてもその名前は変数パターン。3.`バッククォート`で囲った小文字の名前は例外的に定数パターン。=>大文字で始まる名前があって、その名前の定数が存在しないときは？
最終更新: 2010-05-24T13:30+0900
はじめこの人は、殺される牛を TVなどで見てかわいそうと無責任な感想を口にする消費者を批判しているのかと思ったがどうもそうではなさそう。
私は「自分の手で殺せる生き物」しか食べないことにしています。釣った魚は自分で殺せるから食べます。でも猫や犬を殺せないように牛や豚や鶏も殺せないので食べません。「命を食べる」ということは「命を奪う」という現場にまで自分が責任を持つことだと思っています。
という考え方には敬意を表するし、
鶏でも豚でも牛でも「食べたいから」という理由で自分の手で殺せる人は食べれば良いのです。私はかわいそうで殺せないから食べないだけですよ。
これももっとも。(あ、「自分の手で」か。俺はできないけど気にせず食べるよ。肉を食べるという行為が意味することを「想像する」ことは必要だと思うけどそれだけで満足もしてる) でも現場の人間を非難する次の二つは疑問。
残酷な殺戮が嫌なら転職すればよいでしょう。生き物の命を奪って現金に換えるという罪深い生き方を選択しているのはご本人でしょう。
いったいどこが侮辱なのですか？今まで数え切れないほどの牛や豚を殺してきた人たちが、こんな時だけ殺すことを「かわいそう」だなんて、こんな詭弁は前代未聞ではありませんか。
ちょっと動物に同情しすぎているのではないか。
俺は、動物を食用などのために殺す人間は消費者の代理で殺している、と認識している。お金を払って髪を切ってもらう、野菜を買う、そんなときと同じように、対価を払っているとはいえ自分にない技術・価値を提供してもらうことに感謝こそすれ、罪深い生き方だという見かたは微塵もわいてこない。ともすれば傲慢な考えということになるのかもしれないけれど、その行為は自分が行っている・望んでいると考えるのだ。だからこそ最初に引用した部分には大きく同意した。
それと、何が「かわいそう」なのか想像してみると、人間の血肉になることもない無益な殺生だからかわいそうなんだろう。伝染病の蔓延というマイナスを、ゼロにする益のようなものがないとはいえないけれど、それで納得できるはずもなし。
最終更新: 2010-05-29T18:05+0900
だれかやってないかなー
コマンドラインクライアントでのやり方を考える。
svn ann で目的の行が最後に変更されたリビジョンNを知る。svn diff -r N で目的の行がその変更以前は何行目(から何行目)だったのかを知る。(新規追加行であれば終了)svn annの回数を最小にできるし、処理したそばから逐次ログを表示していける。コピーとかペグ・リビジョン(「現在のファイルがrevision Nのときそうだったもの」と「revision Nのときに現在のファイル名だったもの」を区別するためのもの)とか考えるの面倒くさそう。
最終更新: 2010-07-10T01:01+0900
hitEnd
public boolean hitEnd()
このマッチャーが行なった最前のマッチング操作によって、入力シーケンスの終わりに達していたら、trueを返します。
このメソッドがtrueを返したときは、さらに新たな入力を加えると最後のマッチの結果が変わる可能性があります。
requireEnd
public boolean requireEnd()
入力を新たに増やすことによって、それまでのマッチが不成功に変わるならtrueを返します。
マッチが見つかっていたときにこのメソッドがtrueを返したら、さら入力を増やすとそのマッチがなくなることを意味します。マッチが見つかっていたときにこのメソッドがfalseを返したら、さらに入力を増やすとマッチが変わるかもしれないが、マッチがなくなることはないことを意味します。マッチが見つかっていないときにrequireEndを呼ぶことは、無意味です。
まず 1.5 で導入された hitEnd メソッドと requireEnd メソッドですが、 hitEnd メソッドはドキュメントでは入力の末尾がヒットした場合にtrueを返すとありますが、入力というのは領域を指しているようなのですが、末尾というのが最後の文字なのか末尾の位置なのかよく分かりませんでした。例えば aa をマッチング対象の入力シーケンスとして正規表現 aa でマッチングを行った場合、入力シーケンス全体にマッチしますが、この場合に hitEnd は false を返します。つまり最後の文字がマッチしていても true にはならないようです。ところが正規表現 a+ や a* でマッチングを行うと aa と同様に入力シーケンス全体にマッチしますが、この場合は hitEnd は true となります。つまりマッチした部分だけでなく正規表現パターン自体も hitEnd の返す値に影響するようです。
どちらも入力が一つの文字列におさまっていないときに役に立つメソッド。
hitEnd()について想像するなら、
search engineが遷移先を残したまま入力を消費し尽くしたときに hitEnd()が trueになる。それの意味することは、直前のマッチが成功していたのなら、さらなる入力によりマッチの範囲が延長される可能性があるということ。直前のマッチが失敗していたのなら、さらなる入力によりマッチが成功するかもしれないということ。
ところで、hitEnd()が trueかつ requireEnd()が trueの場合って存在するだろうか。あるとして、どんな入力とパターンになるだろう。
requireEnd()はなくても困りはしない。マッチの範囲が入力の末尾まで続いていれば無条件に入力を増やしてリトライすることで requireEnd()が trueだったのか falseだったのかは確かめられる。
hitEnd()も、マッチが成功していたときは重要ではない。真価は、マッチが不成功だったときに hitEnd()が falseを返した場合は、さらなる入力をつなげてもマッチが成功に変わることがないと確かにいえること。hitEnd()がなければすべての入力を連結せずにはマッチが存在しないことを断定できない。
そうそうこれこれ。>http://www.mail-archive.com/classpath-patches@gnu.org/msg08501.html
さらに、こっちのドキュメントは詳細だしバグにも触れてある。上のスレッドで報告されてるのとは別のバグみたいだけど。
boolean hitEnd()
(This method is unreliable in Java 1.5; a workaround is presented on page 392.)
This method indicates whether the regex engine tried to inspect beyond the trailing end of the input during the previous match attempt (regardless of whether that attempt was ultimately successful). This includes the inspection done by boundaries such as \b and $.
If hitEnd returns true, more input could have changed the result (changed failure to success, changed success to failure, or changed the span of text matched). On the other hand, false means that the results from the previous attempt were derived solely from the input the regex engine had to work with, and, as such, appending additional text could not have changed the result.
The common application is that if you have a successful match after which hitEnd is true, you need to wait for more input before committing to a decision. If you have a failed match attempt and hitEnd is true, you'll want to allow more input to come in, rather than aborting with a syntax error.
♭ ds14050>ところで、hitEnd()が trueかつ requireEnd()が trueの場合って存在するだろうか。 a..
♭ ds14050なぜだか上のコメントがスパム扱い。@data_path/log/debug.logを見た。 >I, [2012-0..
♭ ds14050>[\/url] ではなく \[\/url] が正しい。 正真正銘正しいのは \[\/url\] だった。 しかし..
♭ ds14050>requireEnd()はなくても困りはしない。マッチの範囲が入力の末尾まで続いていれば無条件に入力を増やしてリト..