Planet Squeak jp

私がSqueak仲間に入れてもらったきっかけの一つは、ビットマップのテキストしかなかったSqueakを改良して、TrueTypeフォントを使ったテキストが使えるようにしたことではないかと思っているわけではあります。

最近は3Dグラフィックスのプログラミングをしているのですが、我々のシステムでも、読みやすいテキストが必要ということで、世の中の人が使っているMultichannel Signed Distance Fieldというやつに基づくテキストを実装して見ました。

ところで、この手法は文字サイズが小さくなると読みにくくなるという問題が知られています。他の人もアダプティブにレンダリング方法を切り替えて、サイズが小さい時はあらかじめ作っておいたビットマップをテクスチャとして使う方法に切り替えているわけなのですが、具体的にその情報をどこにしまっておこうかなと思っていたところ、例によって賢い同僚が「MSDFはRGBしかつかっていないのだから、Aチャネルにしまっておいて、shaderで切り替えて使えば良い」と言ってくれました。なんとシンプルで賢いのか。

というわけで、早速その手法を実装すると、期待通りにズームインしてもズームアウトしても読みやすいテキスト部品が作れました。これで心置きなくスクリプティングシステムを作っていけます。めでたしめでたし。

by squeaker at November 16, 2018 08:08 PM

近況

旧同僚とやってきたスタートアップの準備もようやく形になってきました。

by squeaker at October 04, 2018 05:01 PM

Eminaさんは、KodkodというSATソルバーを作ったり、ソルバーを使ったDSLを作るためのフレームワークRosetteというものを作ったりししている研究者の人です。Onward 2013!で発表が前後したりした関係で(同僚のHesamは前からDagstuhlセミナーに一緒に参加したりしていたので既知でしたし)、Viewpointsに一度来て話をしてもらうということになりました。

Alanの斜め上からの質問にも動じずに、かつ分からないことは分からない、ということもはっきりと言える落ち着いた人でした。

by squeaker at October 03, 2018 11:09 PM

Kickstarterに出資したBertに送ってもらいました。

http://www.robotturtles.com/
コンセプトとしては阿部さん他の「にんげんプログラミングhttp://www.canvas.ws/kenkyujo/scratch/index.html」のようなものですが、きれいにパッケージして製品化しているところがすごいです。ルールはあってもないようなもので、子供と一緒にルールを作りながら遊べます。なかなかよし。

by squeaker at October 03, 2018 11:09 PM

まさかEmacsにバグがあるとは。

http://apple.stackexchange.com/questions/111197/runaway-distnoted-process

by squeaker at October 03, 2018 11:09 PM

日本ではそういう時期なのですね。

http://keigomi29.hatenablog.com/entry/2014/02/11/140251

とか、基本線として分かりやすいです。

まず「訊かれたことに答える」ことです。

そんなんあたりまえやろ、と思うでしょ。それが全然当たり前じゃないんですよ。みんな普通に訊かれたことじゃないこと答えてます。まじで。何が、で訊かれたら「何」を答えましょう。「〜なのか」と訊かれたら答えはYesかNoです。

のあたり、日本の人が英語で発表しているときにも悪い例を良く見かけますね。"Is this XYZ?"という質問に対して、あるいは"Did you do XYZ?"という質問に対しても。"It is difficult."という返事を聞くのが結構定番な気がします。「難しい質問ですが」という前置きが訳されているのか、「やるべきだったのだけど技術的に難しかったのでやりませんでした。すみません」というのが訳されているのか、とは想像しますが、不慣れなときはまずはYes/Noで答えておかないと。

5年もすればネタになるでしょうし、20年後には思い出すことさえほとんどなくなっているでしょう。

これは(笑)。世の中には20年後にも卒論発表で失敗した夢を見て夜中にぱっと飛び起きている人もいるに違いない。

by squeaker at October 03, 2018 11:09 PM

2048ゲームがちょっと流行ったところで、

http://gabrielecirulli.github.io/2048/

今更ながらソルバーを作ったりするのも芸がないので、オリジナルのサイトのコンテンツをよそからリモートコントロールできるようにしてみました。

http://lively-web.org/users/ohshima/lively-2-webpage.html

を開け、Generate connect codeのボタンを押した後でdrag this to your bookmark barのリンクをブックマークバーにドラッグします。その後http://gabrielecirulli.github.io/2048/を別のタブで開き、そのタブが表示されているところで先ほどブックマークに登録したブックマークレットを押します。これでLivelyの方に戻るとしばらくして右にあるラベルが"connected"に変わるので、open remote workspaceのボタンを押します。

後は左上の"2"を押すたびに、ゲームの画面が更新されるようになる、はずです。少なくともChromeであれば。

LivelyはSmalltalkみたいな環境なので、リモートコントローラ側の機能をどんどん拡張していけるところが面白いところですし、Robert Krahnの作ったlively2livelyという仕組みがあるので、複数のウェブサイトを自由につないで遊ぶ、ということができるわけなのです。

難しかったところは、KeyboardEventを作った後でそのフィールドに正しい値をセットするところでした。whichプロパティなどはリードオンリーなので、簡単には変えられません。結局のところsetterとgetterを定義してかわす、というのが定番のようで、私のコードは

(function() {var v = document.createEvent("KeyboardEvent"); Object.defineProperty(v, "keyCode", {get: function() {return parseInt(this.keyIdentityfer.slice(2), 16)}}); Object.defineProperty(v, "which", {get: function() {return parseInt(this.keyIdentifier.slice(2), 16)}}); v.initKeyboardEvent("keydown", true, true, window, ' + k + ', 0); document.getElementsByClassName("container")[0].dispatchEvent(v)})()

みたいになっています。おそろしや。

by squeaker at October 03, 2018 11:09 PM

http://www.future-programming.org/call.html

です。最近はときどきいろいろなプログラム委員になっている気がしますが、これは結構楽しみです。

"Communications Design Group SAP Labs"というのはAlan Kayが音頭取りをして新たに設立した研究グループです。Viewpointsそのものもほぼ飲み込まれた、というかCDGがViewpointsの拡張というか、事実上一体化して活動しています。いろいろと有名な人が入っているのでこれからが本当に楽しみです。

by squeaker at October 03, 2018 11:09 PM

２週間にわたってドイツとイギリスに出張してきました。ドイツはStuttgartとTübingenに近いGäufeldenという街というか村で、共同開発者とハイキングをしながら設計会議をみっちりと。イギリスの方はAPL系配列言語の開発者達が密かに集まってこれまたみっちりとAPLについて語ったり実装をしたりするというCambridgeのTrinity HallでもたれたIverson Collegeなる集まりでした。

Iverson Collegeのほうはさすがにとっても濃い感じでした。中でも、Kという言語とkOSというOS、kDB+というデータベースをやっているArthur Whitneyの書くコードには、その徹底的なminimalismに驚かされました。

私も片手間ながらちょっとしたJもどき言語のパーザーとインタープリタを作り始めました。まあ本格的なものにはなりませんが、ちょっとした遊びに使えるようにはしたいと思っています。

「スノッブなイギリス人」のステレオタイプとして、何気ない会話の中で、突如日本文化に関する質問をし、話すに足る人間かどうかを調べる、というものがあります。今回は「侘び寂びは英語に訳すときはなんと言えば良いのだろう」と聞かれました。これは探りを入れてきたというよりは純粋に思いついた質問、と言う様子ではありましたが。とっさに(というかどこかで聞いたことのある)"beauty in imperfection"と答えてその後マクロスの話で盛り上がったりもしてまあ良かったのですが、アウェイでの戦い方はそれなりい経験したなあと思ったりもする旅でもありました。

by squeaker at October 03, 2018 11:09 PM

APLの集まりに参加した関係上、私も処理系の1つぐらいは作らなくてはな、ということで雑用に追われる中(実は転職しました)ちょっと作ってみました。

実装の都合上、シンボルはAPLのシンボルではなく、ASCIIベースでやっているJ言語のものを使っています。

実装に使う言語はOMeta2/Squeakで、パーザーとインタープリターをそれぞれ別のクラスとします。あ、ちなみに世界に蓄積された「効率の良いAPL処理系を作る」ためのノウハウ(http://www.slac.stanford.edu/pubs/slacreports/reports07/slac-r-114.pdf にある"drag-along and beating"とか)とは距離を置き、とにかく簡単な実装とすることを目標とします。

パーザーはJParserというOMeta2クラスのサブクラスとして作ります。

Jの実行単位は「文」と呼ばれているもので、それは簡単に言ってしまえば、「要素」の1つ以上の列です。ですので、文を認識する構文規則は以下のようになります。

sentence =
        element+

ですが、一応認識したもののリストを結果として取り出し、よけいな余白などがあっても動くようにするわけなので、実際の規則は

sentence =
        element+:s spaces -> [{#sentence}, s reversed]

のようになっています。認識した結果は逆順にひっくり返された後、#sentenceというキーワードをあたまにつけたリストになります。

ここで使われている要素を認識するためのelementという構文規則は以下のような感じです。

element =
        "(" sentence ")" | number number+ | number | primitive | name

文を括弧でくくったもの、数字の2つ以上の並び、一つだけの数字、記号、そしてアルファベットで始まる普通の名前のどれか、ということになっています。elementも認識したものを結果としての粉作手は行けないので、実際には

element =
        "(" sentence:s ")"      -> [s]

    

    
       number:f number+:s      -> [{#array. f}, s]
    
    

    
       number
    
    

    
       primitive:p             -> [{#primitive. p}]
    
    

    
       name:n                  -> [{#name. n}]
    
    

    

    
のようになっています。それぞれ結果はあたまに適切なキーワードをつけたリストです。
まあnumberとかprimitiveとかの規則も定義はしなくてはいけないのですが、それらはまあ簡単なのでここでは省きます。と

いうわけで、sentenceとelementという規則を定義することによって、Jのパーザーが完成しました。このパーザーは例えば
(2 3 $ 1 2 3) +/ 4 4 4 
のような入力を食わせると
{#sentence.
  {#array. {#number. 4}. {#number. 4}. {#number. 4}}.
  {#primitive. #/}.
  {#primitive. #+}.
  {#sentence.
     {#array. {#number. 1}. {#number. 2}. {#number. 3}}.
     {#primitive. #'$'}.
     {#array. {#number. 2}. {#number. 3}}}}
という構文解析の結果を出力します。

次はインタープリターです。インタープリターの基本的な動作は http://www.jsoftware.com/help/dictionary/dicte.htm に記述されています。要するに入力を後ろからスタックに積んでいき、スタックトップの近くで還元できる要素があれば還元する、ということになります。OMeta2は要素の後ろの方を処理するという機能がないので、パーザーの方で順序をひっくり返していたのでした。

インタープリターはJInterpreterというOMeta2クラスのサブクラスとして作ります。

JInterpreterはスタックを状態として持ち、入力要素を見るたびにスタックに「シフト」し、還元できるようなら「リデュース」するという動作になるので、これをそのまま書き下して
sentence =
        {#sentence (shift | reduce(false. stack))+} reduce(true. stack)*
                -> [stack last]
と書きます。sentenceキーワードで始まるリストの要素を全部見終わった後にもスタック上に還元すべき要素がまだ残っているかもしれないので、最後には還元できる間ループして(クリーネ閉包*を使う)、スタックトップを結果とします。

shift規則の骨子は
shift =
        ({(#array 
                ({#number anything:n} [n])+:nn
                [JArray new: {nn size} data: nn offset: 0]
        |       #number anything:n [n]):n
        } [n]
        | anything):n
        [stack addLast: n]
というくらいのもののはずです。#arrayキーワードで始まる配列が来た場合は、JArrayというJの配列を表すオブジェクトを作ります。数値やシンボルなどは構文解析の結果そのもので良いです。

ですが、上記のページを見ると副詞(adverb)や接続詞(conjunction)の結合規則について何やら書いてあります。構文解析時にバラバラのままにしておいた+や/のシンボルはどこかの段階で結合させなくてはならないようです。ですので、シフトしようとしたものが副詞や接続詞だった場合には、その時点で読めるだけ読んで結合したものを動詞としてシフトするようにします。 さらに、もともと丸括弧で囲まれていた副文であった場合にはそれを評価しなくてはならないので、それもシフト時にやってしまうことにします。
shift =
        (
          parseVerb
        | {
            (#array 
                ({#number anything:n} [n])+:nn
                [JArray new: {nn size} data: nn offset: 0]
           | #number anything:n [n]):n
        } [n]
        | anything):n
        (
        isInnerSentence(n)
        | [stack addLast: n])
例によってparseVerbやisInnerSentenceの定義は省きます。

還元を表すreduce規則はだいたい

reduce :last =
        {(
                arg:n conjunctions:c
                -> [self pop: 4 andPush: c andPush: n]
        |       arg:r dyadOp:o ~verb arg:l 
                -> [self pop: 3 andPush: (o value: l value: r)]
        |       arg:r monadOp:o (?[last] | (~arg ~conjunction anything))
                -> [self pop: 2 andPush: (o value: r)]
        ):n _*}
        [n]
のようなものです。

というわけで、後は必要となるヘルパーを書いて、パーザーとインタープリターの完成です。

ただ、実際に計算を行う演算子の実装にはまだ手間がかかります。+や-といった2項演算子であっても、引数となっている配列の次元の組み合わせ、そしてランクオペレータの指定するランクによって振る舞いが変わってくるので、その辺に対処したものをSqueakのコードとして書きます。Jの場合は演算子の動作の定義を、JArrayのメソッドとして書いて、左辺と右辺を非対称にするのは気が進まないので、JInterpreterの暮らすメソッドとして "doDyad: op with: l with: r lRank: lr rRank: rr"のようなシグネチャのものとして書きます。

さらには、このような演算子は副詞や接続詞によって際限なく修飾されうるので、Squeakのクロージャーを活用して、組み合わせることにします。例えば、+が使われたときに適用される関数は
        Dyad at: #'+' put: [:a :b :ar :br | self doDyad: [:x :y | x + y] with: a with: b lRank: ar rRank: br].
のようにDyadという辞書にしまっておきます。4つ引数があるのは、２つの引数およびそれぞれの引数のランク情報を渡すためです。

そして、例えば一般化された外積を表す2項演算子の'/'は、
        DAdverb at: #'/' put: [:v |
                [:l :r :lr :rr | self outerProduct: v with: l with: r lRank: lr rRank: rr]].
のようにDAdverbという辞書にしまっておきます。入力として"+/"のような組み合わせが現れた場合には、

(DAdverb at: #'/') value: (Dyad at: #'+')
のようにすると、再び4引数のブロックが結果として返るので、それを2項演算子として使うことができるわけです。

で、せっかくSqueakで作った以上、対話的な環境を作らねばなりませぬ。というわけで、Workspaceのサブクラスを作って2,3のメソッドをオーバーライドし、入力したものがJの式として評価されるようなものを作ります。



さらなる発展があるかどうかはかなり謎ですが、まあ記録までに日記にしてみました。

by squeaker at October 03, 2018 11:09 PM

4年ぶりにScratch@MITに参加しています。以前ののんびりした感じよりも、大人がまじめな事をしている集まりの用でもありますが、それぞれの人は本当に元気で面白い事を考えているので、素晴らしいです。

日記を検索したら、私が書いたScratchに関する最初のエントリは2004年4月でした。時は流れます。

http://d.hatena.ne.jp/squeaker/20040417#p1

by squeaker at October 03, 2018 11:09 PM

"A 15 Year Perspective on Automatic Programming" by Robert Balzer

http://www.cs.utexas.edu/~idbaxter/cs395T/papers/Balzer85AutomatedProgramming_01701945.pdf

Robert (Bob) Balzerは"history-playback debugger"とか"Dataless Programming"とかに関する先駆的で興味深いアイディアを多数打ち出した人なのですが、なぜかあまり注目度が高くないという人です。後から出てきた同種のアイディアについた名前が人口に膾炙しているわけです。

それはともかく、"Automatic Programming"に関してもいろいろと仕事をしていたわけです。コンパイラではなく仕様からプログラムを作る事、そして仕様を作る事を支援する環境に関しての考察です。

"Papers on Automatic Programming for Numerically Controlled Machines" by Douglas Ross

http://bitsavers.informatik.uni-stuttgart.de/pdf/mit/whirlwind/apt/APT_Reports_Jan58.pdf

Automatic ProgrammingはもともとFortranなどもそう呼ばれていたわけですが、こちらはNC工作機械への入力を生成するという1958年の論文。古いです。

"What's wrong with APL?" by Phil Abrams

http://dl.acm.org/citation.cfm?id=803777

まあ的確な指摘でしょうな。

"Artificial Intelligence Meets Natural Stupidity" by Drew McDermott

http://www.inf.ed.ac.uk/teaching/courses/irm/mcdermott.pdf

私はそれほどAIの話は知らないので(特にこの記事が書かれた当時の文脈など)十分理解できたわけではないですが、タイトルだけでもお腹いっぱいです。

by squeaker at October 03, 2018 11:09 PM

European Smalltalk Users Group Conference に10年ぶりに参加してきました。フレンドリーで、かつ激しい議論を戦わせるだけでの共通認識があるので、楽しい会議である事には違いないです。新しいVMがぽろぽろ出てきていたり、ベンダーも多数来てプロダクトのアップデートをしたり、学生達が発表したりと活気もあります。

帰り道ロンドンで一晩空きがあったので、Gielgud Theatreでやっていた"The Curious Incident of the Dog in the Night-Time"の劇をDan とKatとDanのお姉さんと見てきました。舞台装置がとても創造的で、かつ原作が提示する「少年の成長物語」を余すところなく伝えていてなかなか素晴らしい舞台でした。

The Curious Incident of the Dog in the Night-Time: A Novel

• 作者: Mark Haddon
• 出版社/メーカー: Vintage
• 発売日: 2004/04/01
• メディア: ペーパーバック
• この商品を含むブログを見る

by squeaker at October 03, 2018 11:09 PM

My Years with Xerox: The billions Nobody Wanted
Alanが以前に行った講演の中で勧めていた"My Years with Xerox: The billions Nobody Wanted"という本です。これは1900年代から40年代、50年代、60年代にXerox (と前身のHaloidという会社)がいかに奇跡的な急成長をして、またいかに素晴らしい企業風土を持っているか、ということを、Haloid時代からずっとR＆Dの重役だったJohn H. Dessauerという人が1970年というXeroxのまさに絶頂期にまとめたものです。社員やxerography発明者のChester Carlsonたちがいかに個人的な借金までして研究資金を作り、他社が見向きもしなかった発明を世界を変える商品にまでしたかということが書かれています。印画紙という安定していたビジネスを持っていたものの、未来のために本業を変えてまでコピー機に乗り込んで大成功したXeroxは、コンピュータこそが次の主戦場であるということを理解していろいろな行動をとったものの、結局のところコピー機の成功が仇となってXerox PARCの成果を生かすことができなかった、という経緯につながります。ただ、Xeroxは今でもちゃんとした会社として順調にやっているんですよね。ただ、逃したものが大きかったために実態以上に印象が悪くなっているという面があります。おそるべし。

Reality Is Broken: Why Games Make Us Better and How They Can Change the World

• 作者: Jane McGonigal
• 出版社/メーカー: Penguin Books
• 発売日: 2011/12/27
• メディア: ペーパーバック
• この商品を含むブログを見る

こちらは脇田さんに勧められて読みました。最初の方は、なぜゲームが人を惹きつけるのか、ということを多くの側面から解説し、最後はalternate realityとしてのゲームを通じて実世界を変えていこうというビジョンを、彼女自身が関わった幾つかのゲーム(北京オリンピックの"Olympic the Lost Game"や、Institute of The Futureの活動)を例に打ち出しています。gamificationを適用する分野として誰しも考えるのがプログラミングの分野であり、その手の試みも幾つかあるのですが、やはりslow processであるプログラミングを、リアルタイム性のある枠組みに押し込んでいるものでうまくっているものが見当たらない、という問題は大いにあります。

[isbn: 0679761063:title=The Master of Go]

川端康成による「名人」の英訳です。San Franciscoオフィスの同僚Chaimが読んだと言っていたので私も読んでみました。「封じ手で主戦場とは違うところに一手打ち、それを見た本因坊が感情的になってミスをした」という話なのですが、どうなのでしょうか。

話は変わりますが、13年間乗ったToyota Corollaはついに後進に道を譲ることとなり、我が家は新しい車を導入しました。7年前に2台体制にしなくてはいけなくなったときにも、電気自動車の夢はあったものの断念してプリウスを導入した、という経緯があり、2年前に引っ越すときも充電器を設置できるように自前のガレージがあるところ、という方針だったので、満を持してというところではあります。とはいうものの、今回も危うく日和ってChevy Voltになりそうだった気持ちを振り切り、Nissan Leafに決定しました。勤務地が新しくなってここ5ヶ月ほど、私が運転するのは片道13マイルの通勤と、そのまわりのちょっとした行き来に限られているといるのだという認識があり、Voltでも電池のみの航続距離には入っているとは言えるのですが、それならばなおのこと純粋電気自動車でもよいはず、という判断だったわけです。

といっても、やはり電池切れで止まるかもしれない、と心配になる"range anxiety"問題は確実にあって、購入した当日の夜、まだ実際の通勤でどのくらい電池が消費されるのかについての経験がない時点ではかなり心配になって眠れなくなるくらいでした。「往復26マイルとは言っても405の山越えがあるから予想以上に消費するかもしれないし、安全係数をとって52マイル相当、さらに混雑や他の事情で2倍かかるかもしれないので104マイル相当、さらには子供の送り迎えやらで寄り道をしたりすることを思うと、公称値の84マイルなどあっという間に超えてしまうではないか！もしかして往復さえもできないのでは！」と思ったりしていたのです。が、実際には山越えでも回生ブレーキがあるので結局のところ平地を行くのとそれほど大きくは変わらない電力消費で済みますので、今日の往復は電池容量の30%程度の消費量で行けました。かつ、オフィスのすぐそばのパーキングには4つほどチャージャーもあって無料で使えることがわかりましたし(全部塞がっていることも多いみたいですが)。まあどうやら今の生活パターンにおいては電池の心配はあまりしなくても良さそうです。よかったよかった。

標高の高いところから低いところに通勤する場合には、往路の下り坂の時に電池が満タンになってしまって位置エネルギーが無駄になり、復路は上り坂で過剰に電池を酷使する、というパターンになることがありえます(私の場合もそれほどではないですがややそういう傾向があります)。オフィスで確実に充電できる、というのであれば、慣れてきてそれほど無駄に心配することがなくなってくれば、充電はオフィスのみですることにするということが良いのかもしれません。

LAにおいては家族でもう一台ガソリンを使える車を所有しているという前提は事実上必須ではありますが、その条件がクリアされてさえいれば、他の人にとっても現実味のある選択肢だと思います。

そうそう、ガレージに導入される充電器を作っているのはあのPaul MacCready創設のAeroVironment社です。これを聞いたときにぐっとLeafに心惹かれるものがあったわけで、ブランド力というのは大事。(AreoVironment社はドローンなども作っているのですが、車内で「戦争に手を貸すような仕事はしたくない、ということができ、その場合は電気自動車や他の事業に専念できる、というようなことが以前新聞に載っていました。)

by squeaker at October 03, 2018 11:09 PM

仕事の方は某言語の為にベクターグラフィックスバインディングを書くという十年一日のような作業をしていてちょっと盛り上がらないのですが、今はThanksgiving休暇中ということで余裕もあったので、初めて「出先で充電を確実にしない限り帰投できない」というドライブに出てみました。

PlugShareをはじめとする種々のモバイルアプリによって充電器の所在は確認でき、またそれらが使用中かどうかもわかる、はずなのですが、それでもかなりの不確定要素が状況を左右する世界でした。一番の問題は"ICE'ed"と呼ばれるもので、内燃機関車(Internal Combustion Engine Cars)が我が物顔に電気自動車用のスポットに停めてしまうために("The parking spot was ICE'ed!"というように言う)、使用可能なはずの充電器が使えないというものです。端的に言ってこれは完全な駐車違反なのですが、充電器を設置しやすい箇所が駐車場の出入り口に近い便利なところでもあることが多いということもあり、ズルをすることに躊躇しないタイプの人にとっては格好のスポットということになってしまっています。駐車場の係員が違反切符を切れるわけでもないので、結局ところ野放しになってしまっていることがおおいのです(PlugShareのコメントによれば北カリフォルニアの方はもうちょっと民度が高いようですが、これがLAクオリティと言わざるを得なません)。身体障碍者スポットにも平気で止める人々もある程度はいるものの、電気自動車スポットはまだ新しいためかわかってないでやってしまっている人がいるという面もありますし。さらにがっかりなのは、電気自動車でも充電する必要も意思もないのに電気自動車スポットに停めてしまう人がいるという問題もあるのですよね。

今日使用した駐車場はLong Beachの水族館前のところですが、案の定ICEで2スポット、接続されていないLEAFが2スポットで4台あるはずの充電器前のスポットが全部埋まっていました。駐車料金を払った後でこういう状況を発見するというのはもうやるせないです。ただ、ある充電器の裏側が「コーンで塞がれていたものの駐車スポットと言えなくもない」という場所だったので、得意の交渉術を発揮してコーンを動かしてもらい、なんとか充電器を使用することができました。

PlugShareで日本、特に都市圏の地図を見ると、CHAdeMO充電器がかなり密に整備されているようで、これだけあれば後顧の憂いなくあちこちを回るというような乗り方も大いにできそうに見えるのですが、LAではやはりまだ不確定要素が強すぎです。充電器の総数を増やすのも大事ですが、オンラインで調べて使用可能となっている充電器であっても、実際には使えなくて当たり前という現状では、遠乗りどころか日帰りでもあっという間に冒険になってしまいます。電気自動車の普及を妨げている一要因として"range anxiety"がしばしば挙げられますが、本質的には「航続距離が十分かどうか」という不確定性ではなく、「予定している充電設備が本当に使えるのかどうかわからない」というのが問題だということを実感しました。

現在ある充電設備でも稼働率を上げられるように、ICEの違法駐車は強く取り締まっていただくとともに、社会的に電気自動車が存在しているのだ、ということをもうちょっと認知してもらえるようにしていきたいところです。

by squeaker at October 03, 2018 11:09 PM

Tucson(なんで「つーそん」なのだ？)に一週間ほど行ってきました。2012年のSPLASHが行われた所だったのですが、いろいろなアトラクションに感心したので、暇ができたら子供連れで行ってやろうと思っていたのでした。メトロポリタンエリア総計でもおよそ100万人程度の人口のようですが、その割にはかなり毛色の変わったものがいろいろとあるという印象です。

今回は国立公園もばっちりと歩き、Desert Museumにも行き、ストリートカーにも乗ってダウンタウン気分を味わい、Biosphere 2も再訪したわけですが、私にとっての山場はPima Air and Space Museumでした。かなり充実です。とはいうものの、残念ながらAMARGと呼ばれる空軍基地のバスツアーには参加できず、Titan Missile Museumや後は複数の天文台など行きそびれたところもあるので、またいつか戻りたいものです。

ただ、食の面からは日本人にはちょっと住みづらいようにも思いました。和食レストランを銘打ったところでも"Sansai"レベルというかなかなか厳しいです。後はやはり日常的な運転距離が長くなりがちで、電気自動車で暮らすのもちょっと難しい感じではあります。今回は冬の最中で雪がサボテンの上に降ったりする気候でしたが、夏は40度越えも当たり前という極端な砂漠気候でもありますし、時期を見て訪れるのが良いところではあるでしょう。

by squeaker at October 03, 2018 11:09 PM

I've been digitizing some analog tapes with EyeTV on Mac. When I try to upload a resulting file, occasionally uploading stops at "95% processing". My solution is to convert the file with VLC. The script I came up with is:

/Applications/VLC.app/Contents/MacOS/VLC -I rc input.mp4 --sout='#transcode{vcodec=mp1v,scale=1,acodec=mpga,samplerate=44100}:std{access=file,mux=mpeg1,dst=output.mp4}'

The resulting file cannot be viewed with QuickTime Player, but once you upload it to YouTube, you can view it. I needed to do this quite a few times, but so far it's been working reliably.

by squeaker at October 03, 2018 11:09 PM

EyeTVでビデオテープからデジタイズしたものをYoutubeにアップロードしていると、時々「処理中 95%」という表示が出たまま止まってしまうことがあります。これはYoutubeフォーラムにも、私も含めて時々報告されていたりするのですが、なぜか解決できていないようです。MacのQuickTimeでは再生できるのに。

私の解決法は、VLCを使って以下のようなパラメータでエンコードしなおすというものです。

/Applications/VLC.app/Contents/MacOS/VLC -I rc input.mp4 --sout='#transcode{vcodec=mp1v,scale=1,acodec=mpga,samplerate=44100}:std{access=file,mux=mpeg1,dst=output.mp4}'

これはコマンドラインから実行して一気にできるのでなかなか便利です。(変換の結果作られたファイルはMac上では再生できませんが、YouTubeにアップロードするとみられます。)今までのところは、このパラメータで失敗したものはないので、まあまずまず安定して機能するようです(ちなみに、VLCは最新版でないとダメです)。

by squeaker at October 03, 2018 11:09 PM

というタイトルのビデオで紹介されていたサーチエンジン。

http://home.netscape.com/escapes/search/
http://www.classroom.net/classroom/search.html
http://www.webplaces.com
http://www.hotbot.com
http://www.altavista.digital.com
http://www.webcrawler.com
http://index.opentext.com
http://www.excite.com
http://www.lycos.com
http://www.gnn.com/search/
http://www.infoseek.com
http://www.yahoo.com
http://www.yahooligans.com
http://looksmart.com
http://www.mckinley.com
http://www.metacrawler.com
http://search.com
http://www.dejanews.com
http://www.shareware.com

by squeaker at October 03, 2018 11:09 PM

https://ccle.ucla.edu/course/view/15W-COMSCIC137A-1

というクラスが進んでいます。ページにはToddの名前しかないようですが、実はAlexとAlanも共同で教えるというクラスになっています。主眼は、将来のプログラミング言語デザイナーのために、実際に素早く言語を作ってみるという経験をすることによって、自分のツールを変更、改良することを恐れずにできるようになってもらうというコースで、１０週間のコースのうちに関数型、論理型、オブジェクト指向という３種類の言語を作ってみるというものです。どうやら大学側の手違いもあり、１００人以上が受講するということになっています。Alexはかなり準備に時間を使っていたのでクラスの進め方は比較的しっかりしている、のですがそれでも私なぞが時々顔を出しているのは、Alanが時折放つ混ぜっ返しや薀蓄があるからではあります。先週私がいない時にはどうやらAlanとToddが静的型と動的型の言語のメリットとデメリットについてかなり熱くやり取りをしたようです。以前似たようなクラスをやっていた時にも、Alanは「静的型と言っても何かがStringであるとかNumberであるとかいうことがわかったところでどうということはない。sin関数を型から探せたりしないものなのか」というようなことを言っていたのですが、Toddは「言うこともわかるけど...」という姿勢ではありました。でも、今回はどうやらToddも本気で反撃するつもりになったようで、Toddも「いやいや、それは静的型というものをまったく理解していない人がいうことだ」と言ったり、そこでAlexがさらにToddにいろいろと言ったりといろいろ楽しくやっていたようです。

学生にとっては、大家に対してもどんどん物をいうものの、フレンドリーなところを決して失わないで議論を戦わせる姿をみせ、かつ言語設計に関しての見方をいろいろ知ることによってドグマに陥らないということで、とても有意義なクラスだと思います。

by squeaker at October 03, 2018 11:09 PM

なんだってー！！

http://lists.squeakfoundation.org/pipermail/squeak-dev/2015-January/181556.html

前のプロジェクトでSqueakを使っていた頃は結構QSystemProfiler(改名されてAndreasSystemProfierとなった)の結果を当てにしていたのですが、まさか抜けがあったとは。バグ逃げされたー。

by squeaker at October 03, 2018 11:09 PM

子供達が日常触れる日本語の歌は、童謡か中島みゆき、ということになっています。私がみゆきばっかり車中で聞いているものですので。

というわけで、彼らもお気に入りの歌があるわけなのですが、その理由が私とはだいぶん違うということに気がついてきました。以下は彼らの人気ランキングとその理由(推定)です。

• No. 5 真っ直ぐな線。真っ直ぐな線やまんまるの円を描くのは難しいから。
• No. 4 本日、未熟者。自分たちも未熟者だと認識しているからか？
• No. 3 パラダイスカフェ。「テーブルの向こうに見る甘い夢」の甘い夢は、甘いものをたくさん食べる夢だから。
• No. 2 あぶな坂。ハイキングのとき急な坂を登ったりするのが楽しいから。
• No. 1 トラックに乗せて。トラックに乗りたいから。

by squeaker at October 03, 2018 11:09 PM

なぜかSFが多かったです。

The Swarm:

The Swarm: A Novel

• 作者: Frank Schatzing
• 出版社/メーカー: William Morrow
• 発売日: 2006/06/01
• メディア: ハードカバー
• この商品を含むブログを見る

文明崩壊もので、深海に哺乳類以前から住んでいた生物が人類を狙って蜂起するという話です。充実のリサーチに基づいている、ということもあるのでしょうがなにしろ長い。テクニカルな話だけではなくロシア文学のように、登場人物の内省が延々と10ページ以上続いたりします。それに前半は大崩壊の予兆があちこちで起こっているという話で、なかなか辛い面もありますが、後半までたどり着くと大いに盛り上がってきます。映画化決定、という話もあるようなのでどう料理されてくるのかやや興味深いところです。

Ready Player One:

Ready Player One: A Novel

• 作者: Ernest Cline
• 出版社/メーカー: Broadway Books
• 発売日: 2012/06/05
• メディア: ペーパーバック
• この商品を含むブログを見る

主人公が東映スパイダーマンに出てくるレオパルドンをゲットしたりウルトラマンに変身してメカゴジラと戦ったりするという場面も出てくるのですが、こちらもリサーチが充実していて楽しめます。(でも、レオパルドンが出てきた以上、その最強伝説ネタがストーリーに絡むのかと期待していましたが、そういうわけではありませんでしたが。)

ハリーポッターとスーパーロボット大戦がサイバーパンクの世界にあり、可愛らしいラブストーリーも絡んでいて、かなりオススメです。映画化決定のようですが、こちらはもう映画向きの話なので結構期待しています。

Being Mortal:

Being Mortal: Medicine and What Matters in the End

• 作者: Atul Gawande
• 出版社/メーカー: Metropolitan Books
• 発売日: 2014/10/07
• メディア: ハードカバー
• この商品を含むブログを見る

この本は終末医療に特化して書かれたものですが、医療の目的が「1日、1秒でも長く生存させれば良い」と言わんばかりのようになっている現状を憂い、死は必ず訪れるものであって人が死ぬのは医療の失敗ではない、という前提から、人々のQuality of Lifeが重要であるということを強く述べている本です。映画化はされないとは思いますが、自分や家族の死に際について考えさせられる本です。

by squeaker at October 03, 2018 11:09 PM

ほとんど内輪の集まりという感じのBlocks and Beyond Workshopで"work in progress"のものを発表しました。

http://www.vpri.org/pdf/tr2015003_modsys.pdf

他の発表者が「どうやって初学者をブロック言語からテキストベースの言語に移行させるか」というような話をしている中で、「未来のブロック言語なら自分自身を編集できるようになって当然だろう」というテーマの話なのである意味浮いていたかもしれませんが、まあいずれ歴史が証明してくれて私も学会に復讐ができるというものでしょう。(いや、ワークショップの次の日はインフォーマルな集まりということで時間があったのですが、討議の中である程度のアイディアの種はやり取りできたような気はします)。

読んだ本は、いまさらながらSchoolhouse Politics。

Schoolhouse Politics: Lessons from the Sputnik Era

• 作者: Peter Dow
• 出版社/メーカー: Harvard University Press
• 発売日: 1991/09/01
• メディア: ハードカバー
• この商品を含むブログを見る

Jerome BrunerのM.A.C.O.Sがいかにして作られ、いかにして政治の波に巻き込まれて消えていったのか、ということをまさに渦中にいた第一人者がまとめた本です。「新しいカリキュラム作りということは、必然的に政治的である」ということが一番の教訓ですが、これは現在のコンピュータ教育にも当てはまるわけではあります。

by squeaker at October 03, 2018 11:09 PM

以前からVPRIにある千本くらいのビデオをデジタイズしています。中にはいろいろ面白いものもあります。

例えば、Stanford AI Labが67年に作ったこのビデオ。プロデューサーにはJohn McCarthyとGary Feldmanの名が上がっています。

話によれば当時は研究成果が出て予算が余ったらコメディービデオを作っても良かったという良い時代で、このビデオもインタラクティブデバッガーをロマンスがらみで紹介しています。Brian HarveyによればStanfordでももうテープが失われている、ということで、VPRIにあるコピーはたぶん世界でも数少ないものでしょう。Lisper系や古いコンピュータ好きな方は必見です。

あるいは、今日はMIT Media Lab 30周年のイベントがありましたが、こちらはMIT Media Lab 5周年の時のNegroponteの講演です。

by squeaker at October 03, 2018 11:09 PM

I once had a short chat with Marvin. At our Glendale office several years ago, he was taking a break from his meeting and ventured into our office area. I was playing with a puzzle (see pictures above) and told him that there are to solutions for this puzzle (one in which two heads are aligned, and one in which they are not). As I said "this is like entangled electrons' spin", he immediately responded with a meta question (to the effect of): "Why do these things always come in twos, and not threes or more?, positive, negative, up down?" I could not say much except something like "well, a line has two directions, and..." but that question lingers on in my brain as a sort of question that is philosophical and gives a hint of the world since then. I don't think that he meant this question to be profound, but an answer for a "why" question sometimes leads to more questions.

Alan said that Marvin was a stereo typical "mad scientist"; this short conversation was enough for me to see why he said that.

by squeaker at October 03, 2018 11:09 PM

Marvinがとあるミーティングに参加するためにApplied Mindsのオフィスに来ていて、休憩を取るためにViewpointsのエリアでちょっと時間をつぶしていたことがあります。私はごく簡単な知恵の輪で遊んでいたのですが、実はそのパズルにはふた通りの解があるということに気がついて(写真のように、頭が同じほうを向いている場合と反対を向いている場合)、Marvinにそれを見せつつ、「このパズルにはふた通りのやりかたがあるんだよね。上向きと下向きで電子のスピンみたい」と言ってみたのです。

すると彼は間髪入れずに「こういうものって大抵2つ組だよね。3とかそれ以上じゃなくて。上と下、正と負みたいに。なぜだろうね」と答えてきました。私は「...ええ、一次元の線には向きが二つあるし,むにゃむにゃ」と返す程度で話を進めることはできなかったのですが、その後もこの簡単な質問は世界観と哲学的な匂いをまとって私の頭の中に残っています。本人はそれほどビックリさせるようなことを言ったつもりはなかったかもしれませんが、「なぜ」という質問はしばしばひとつの答えがさらなる答えを要求しますし。

Alan曰く、"Mad Scientistの代表"という彼ですが、こんなやりとりでも「そうだな」と思わされることでした。

by squeaker at October 03, 2018 11:09 PM

視覚化やプレゼンテーションに関するアイディアや著書で有名なEdward Tufteは、1日セミナーを全国で開催しているのですが、今回は近場で開かれるということで参加してきました。立派なホテルのホールに200人くらい受講者が来ているのでなかなかのものです。最初の1時間は彼の著書を読むという時間に充てられています。(が、Tufteがその間に歩き回って本にサインをしてくれます(頼まなくてもしてくれたりします)。同僚の意見によれば、講演後に後でサインを求める人の列ができるよりも時間短縮になるのでは、ということで、まあそうなのかのとも思ったりします。

講演は(本と同様に)いくつかの実例を表示して、良い点、悪い点を指摘するところからはじまります。話の中でひとつ強調されていたのは「いったい何個の数字・データが見る人に提供されているのか」ということでした。ダッシュボードでは、たかだか5つくらいの数を表示するためにありとあらゆる飾りやデザインを使ってしまいますが、グラフやアイコン、そして必要に応じて文字で数値を表示することにより、数千の数値を伝えることはできますし、現代の5kや8kディスプレイはP.A.P.E.R.テクノロジーの半分くらいの解像度までは来ているので、情報を簡略化するというよりは、一覧性を高めることを考慮するべきという話でした。

espn.comの野球のページなども、box scoreに多数の数値が表としてまとめられたあとで、ホームランなどの稀な出来事は言葉で別のところに書くというスタイルになっています。espnのサイトのコメント欄を読めばどのくらいの知性の人が見ているかが見当がつくが、そういう人でさえもこれだけの数値を咀嚼できる、という話でした。

New York Timesにも悪い例があるということで、数値やグラフを使ってもっともらしい議論をしていても、未来予測のグラフがあまりにも正確すぎたり、情報元として示されている組織が中立ではなかったりするということに着目すると、信ぴょう性のない情報がわかる、という話でした。

午後のセッションでは、プレゼンテーションをする時のスタイル、そして心構えという類の話が多くなりました。Jeff BezosやSteve BallmerやSteve JobsがPowerPointを嫌っているという話をし、Amazonではプレゼンターは6ページほどの文書を事前に作成し、会議に集まったところで各自がそれを読んで、そこから質疑をするというスタイルにしているそうです。スライドプレゼンテーションでは多くの時間が要点が話されるのを待つことに費やされてしまいますし、一覧性のある文書であれば各自が自分の早さでじっくりと読めますし、発表者も手塩にかけた文章が実際に読まれているというところを見られるのでやりがいがあるという話でした。

彼はしばしば「アホな上役に対してプレゼンテーションをしなくてはならないが、数値をどのようにまとめて視覚化すれば良いか」という質問を受けるそうです。が、彼の回答は「もし上役のことをアホだと思っているようならまずはあなたはプレゼンをしない方が良いかもしれない。」というところから始まるそうです。発表者の心構えとしては、まずは「同僚に対する信頼」に立脚していなくてはならず、批判を受けても、その動機について邪推をする必要はなく、真摯に受け止めるべきだと言います。大概のグループは似たような人が集まっている中で、意見の相違があった場合にはあなたが常に正しい側にいるという可能性は低いのですから。

後は、発表は内容で勝負するべきであって、あなたがどれだけ準備に時間をかけたかとか、スライドの枚数を何間に減らした、とかそういう話には触れるべきではないという話もありました。

Sparklineは1単語程度のスペースに数千の数値を表現できるし、名詞ではなく動詞としてのアノテーション付きの矢印を上手に使うのが良いという話もありました。

彼自身の講演スタイルで面白かったのは、皆から見えるところに助手の人がいて、話の内容に応じてウェブページをズームしたり、例としてあげるアニメーションを進めたりしているのですが、ときどき流れの都合上、助手の人がTufteにシナリオを指し示して「次はこの話をしてください」とひそひそ言っていたりするところでした。まあそういうこともあるでしょう。

というわけで、1日のセミナーとしては私も1日分以上に賢くなれたような気がします。

by squeaker at October 03, 2018 11:09 PM

BjorkさんというUCLA心理学の教授が、UCLAで一番頑張っている教授に任される"UCLA Faculty Research Lecture"をするというので、ちょっともぐりこんで聴講してきました。どういうスケジュールで学習をし、学習後の試験がどのくらい間をおいて行われるかによりどのような結果がでるか、ということをみっちりと研究してきた人です。(参考: http://bjorklab.psych.ucla.edu/research.html)

例えば、"massed learning"という、同じ問題を短期間に連続的に勉強する群と、トータルの勉強時間は同じでも間に間をおいて勉強する群(spaced learning)を比較した時に、勉強期間の直後(1日後など)に試験した場合はmassed learningのほうが良い結果を出すが、1ヶ月後に試験した場合はspaced learningのほうがよいという研究結果があるそうです。

子供がお手玉を3 feet先の箱に投げ入れるという練習をする時も、箱を常に3 feet先において練習した群と、2 feetと4 feet先をターゲットとして練習した群を比べた時に、時間をおいてから3 feet 先の箱を使ったテストをすると後者のほうがよい結果をだすというのもありました。

面白いのは、学習中の被験者にアンケートをとると、massed learningをしている最中の被験者のほうが、「テストでよい結果が出る」と返答するのに対し、実際にはspaced learningをした被験者のほうがよい結果をだすということで、講演のタイトルでもあった"How we learn versus how we think we learn"という話が出てきます。

心理学の実験なのでいろいろと講演だけでは語られなかった付帯条件などもあるとは思いますが、こういうことを実際に実験して、直感には反する結果をじっくりと出し続けていたのだなあということが驚きでした。

by squeaker at October 03, 2018 11:09 PM

https://blog.ycombinator.com/harc

諸般の事情により所属先が変わりました。といっても過去にあった所属先変更と同様に、同じグループで、同様のビジョンに基づいた研究・開発をしています。

新しい職場はY Combinator Researchというところで、グループの名前は HARC "Human Advancement Research Community"ということになっています。象徴的ボスはAlan Kayです。彼もまだまだ元気です。

YCRができたきっかけは、Sam AltmanというY Combinatorの社長が「利益追求のスタートアップとは別に、長期的な研究をして社会に還元する組織を作りたい」ということで、大きな研究組織作りに一家言あるAlanに相談したことです。元々は一般論としてARPA内でどのような研究者たちがどのような人間関係で研究を行っていたのかという話でしたが、1年ほどのうちに、「本当に組織を作るならこのグループから始めたら良い」という話になったわけです。

多分数週間のうちに、わたしが同僚とやろうとしていることのアウトラインに関するメモも公開することになると思います。

というわけで、これからもよろしくお願いします。

by squeaker at October 03, 2018 11:09 PM