タグ

ブックマーク / ympbyc.hatenablog.com (25)

  • LispマシンMirai - 標高+1m

    この記事は lisp Advent Calendar 2018 の25日目に書かれました。 メリークリスマス! 一月ほど前に、ワイヤードを漂っていたMiraiのバイナリをうっかり手に入れてしまったので、 環境を作って少し遊んでみました。*1 CG制作統合開発環境Miraiのコードベースは、1980年代のSymbolicsで作られたS-Graphicsに端を発します。S-Graphicsは92年にニチメングラフィックス(旧:日シンボリクス,現:NGC)に売却され、IRIXとWindows NTに移植されてN-Worldになり、これを下敷きにしてMiraiが作られました。現在はIzWareが権利を保有しています。Miraiのリリースが1999年なので、20年前のソフトウェアということになります。 嗚呼憧れのSymbolics ここら辺の事情は、Practical Scheme WiLikiの

    LispマシンMirai - 標高+1m
    ympbyc
    ympbyc 2023/01/27
  • Sigmarion 3をRasPiの端末にする - 標高+1m

    Sigmarion III acting as a terminal for raspberry pi これは今年4月に成功した試みの話。父のお下がりのsigmarion 3を実家から掘り出してきた。 sig3はWindows CE時代のハンドヘルドPC(H/PC)と呼ばれるカテゴリーの端末で、2003年の発売。 私は当は白黒(グレイスケール)液晶のH/PCが電池が長持ちで目も疲れなくて大好きなんだけど、それは無くしてしまった。 sig3はSD (not SDHC) が入って、USBの親にも子にもなれるという、今も生き残っている規格が使える点は便利。 H/PCの時代は、コンパクトフラッシュスロットに入るAir H''カードとか、LANケーブルアダプタとか、Wifiカードとかを使ってネットを使っていたのだけれど、WifiカードがWEPにしか対応していなかったりして、今ネットに繋ぐのはひと工

    Sigmarion 3をRasPiの端末にする - 標高+1m
    ympbyc
    ympbyc 2022/11/24
    こんなの好きな人いそうだけど誰もブクマしてくれないよ
  • 人間が計算資源になる日 - 標高+1m

    US291464337 Fig. 1 マイクロソフトの特許部門がPCT出願した特許PCT/US2019/038084に、WIPOのWO/2020/060606と言う公開番号が付いた。*1 暗号通貨のマイニングに、ユーザーの生体活動データ(e.g. 体温、脳波)を利用するシステムに付いての特許だ。 この公開番号がWorld Order(新世界秩序)2020(年)666(獣の数字)だと言う話が回ってきた。 獣の数字666と言うのはヨハネの黙示録13章18節に記されたもので*2、16~18節を抜粋すると、 16 また、小さき者にも、大いなる者にも、富める者にも、貧しき者にも、自由人にも、奴隷にも、すべての人々に、その右の手あるいは額に刻印を押させ、 17 この刻印のない者はみな、物を買うことも売ることもできないようにした。この刻印は、その獣の名、または、その名の数字のことである。 18 ここに、

    人間が計算資源になる日 - 標高+1m
    ympbyc
    ympbyc 2020/05/16
  • 『なぜ全ては崩壊するのか』翻訳 『Why everything will collapse』Japanese translation - 標高+1m

    去年11月に観た動画『Why everything will collapse 』 その頃は絶望しか感じられなかったけど、COVID-19による緊急事態宣言下の今なら、響く人がいるかもしれないと思って、昨晩翻訳した。 YouTubeのCCで今レビューの申請中。 鼻水垂らしながら勢いで翻訳を仕上げてから、機械翻訳を見てみたらほぼ完璧に訳されていてなんだよと思ってしまった。 でもせっかくなので、訳注をつけて全文をブログにあげる事にした。 文章になっている方が良いことがあるかもしれない。 動画はこれ。 youtu.be 以下翻訳全文。 なぜ全てが崩壊するのか - Julien Woz これは私達を何が待ち受けるのか知りたい人に向けたものだ。 私は私達が困難のただ中にあると述べるだけではなく、 代わりに、気候変動について私が知っていることの要約と、 それが私達全員にどう影響するかを説明しよう。 説

    『なぜ全ては崩壊するのか』翻訳 『Why everything will collapse』Japanese translation - 標高+1m
  • biwascheme call/cc 非同期処理と大域脱出 - 標高+1m

    引き続きbiwaschemeで呪文を唱えております。 ;;treasure hunt (let ((data (<o> 'data (fetch-json "treasure-map.json")))) (begin (listen-click "button") (console-log (<o> 'treasure (fetch-json (<o> 'treasure-url data)))))) #0: 宝探し call/ccで非同期処理を書くと、あらゆるところから処理が湧き出して流れていく、不思議なコードが書ける。 書けるのは良いが、実行すると、最初にcall/cc自体の値が継続の流れの中で引っかかってしまう。 (define (fetch-json%% url) (call/cc (lambda (k) (ajaxy-fetchy-thing (lambda (data) (k

    biwascheme call/cc 非同期処理と大域脱出 - 標高+1m
    ympbyc
    ympbyc 2020/04/02
  • 2018年トーキョー - 標高+1m

    注: この記事では、東京に住んでいる人を批判するつもりはありません。 半年ぶりに東京に行ってきた。みんな黒っぽいコート着てた。 超大雑把に言うと、 みんなと同じように考えて暮らしていれば、お金に困らなくて、ビッグデータの機械学習によってパーソナライズされた広告の中から、服でも美容でも好きなもの買えるし、世間と合わないなと感じたらADHDの診断受けてコンサータを飲めば適合できる。っていう社会だった。 スマートスピーカー見たけど、あれが「OK Google」に反応できるってことは、家庭の音をずっと撮ってて、音声認識のためにサーバに照会しに行ってて、音を文字越ししてビッグデータにして、それをAIわせて広告出したりできるわけじゃんか!ほんとにどこまでやってるのか知らんけど、これが無規制ってやばいよ。 わかりやすい論文というか書評: ci.nii.ac.jp ニトリのペッパーはいつセネパルハイバ

    2018年トーキョー - 標高+1m
    ympbyc
    ympbyc 2018/03/21
    書いた。
  • 社会と世界と地球と宇宙について - 宇宙APIシリーズ - 標高+1m

    ympbyc
    ympbyc 2017/08/12
    書いた
  • We Need More Space! - 標高+1m

    「この宇宙」と書くとき、これは観測可能な宇宙を表す。 「宇宙」と書くときは、数学的に可能な宇宙を表す。 モノの抽象間のコミュニケーションを扱うプログラミングパラダイムについて研究している。既存の例としてはオブジェクト指向が有名であるが、オブジェクトはモデリングの失敗例である。オブジェクト指向は間違ったモデルの上に組み立てられた宇宙であり、僕らの住むこの宇宙のアナログであるとは言い難い。*1 そこで、今回はモノの抽象とそれらのコミュニケーションとして、より適切なモデルを模索してみよう。 まずは既存のモデルを物理的に解釈してみる。モノの抽象を扱う仮想のパラダイムxを使って記述する宇宙は以下の特性をもつとしよう。 時間発展が実時間に依存している。 (スレッド内では)同期プログラミング。つまりモノAからモノBに、メッセージはゼロタイムで伝わる。 メッセージは宛先を知っている。 上記の3点は、この宇

    We Need More Space! - 標高+1m
    ympbyc
    ympbyc 2015/12/03
    書いた
  • 場を使った相対論的オブジェクト間コミュニケーション - 標高+1m

    アクターやオブジェクトにおいて採用されているメッセージング機構(つまり宛先アドレスを持ったメッセージ)は、自然界のシミュレーションやIoTデバイス間コミュニケーションに適さないのではないか、という仮説のもと、メッセージングに依らないオブジェクト間コミュニケーションについて考えています。ここまでの経緯は、以下2つの記事を参照してください。 IoTの意味がわかった - 標高+1m VOCの拡張 - 場の導入 - 標高+1m VOC (Vision Oriented Communication)の中心にあるコミュニケーション機構は、以下の2点に集約できる。 情報は自身を中心に波状に拡散する だれでも視野の中にある情報は読める 前回は、場(場 - Wikipedia)を使った機構を紹介し、同時にこの方法のパフォーマンス上の問題点について示唆した。現状の問題点は以下の3点。 全てのオブジェクトが絶対

    場を使った相対論的オブジェクト間コミュニケーション - 標高+1m
    ympbyc
    ympbyc 2015/11/13
    書きました。
  • VOCの拡張 - 場の導入 - 標高+1m

    昨日の記事でちらっと出てきた、VOCについて。1年半前にこんな記事を書いた。 ympbyc.hatenablog.com VOC(Vision Oriented Communication)を初めて紹介した記事だが、それ以来VOCについてたまに考えていて、よりわかりやすい説明を思いついたことと、IoTへの応用を見据えた再定義を行いたいので、この記事をもってVOCの定義を改訂する。 メッセージは波であり、宛先は持たない 電話やメールと言ったテクノロジーの助けがないプリミティブな世界では、真に1対1のコミュニケーションは(接触以外に)あり得ない。 眼はおおまかに400nm~800nmの波長の電磁波を受信して検波する。電磁波は波であり、ある程度の指向性こそ持たせられても特定の宛先を持つものではない。 耳も音波について同様である。 口はAM+FM変調した音波を送信する。 身振りは可視光線を反射する

    VOCの拡張 - 場の導入 - 標高+1m
    ympbyc
    ympbyc 2015/11/12
    メッセージングではないオブジェクト間コミュニケーションについて
  • IoTの意味がわかった - 標高+1m

    注) IoTの定義は知らないので、この記事で言うIoTは、「僕が考えるIoT」です。 最近まで気にしてこなかったけど、電子工作を始めてから興味が湧いてきたIoTについて。 現状はビーコンとかセンサーとかRFIDとかの弱いコンピュータ群とインターネットが作るネットワークを指してIoTと言っているように見える。 これでも十分面白いんだけど、今は過渡期の初期段階で、実はもっと面白いことが起ころうとしてるはずだ。 僕らにはどうしてもコンピュータは高価なものっていう固定観念があって、やっとビーコンやArduinoを惜しげも無くばらまけるようになってきたかどうかといったところだ。 当は全てのノードが強いコンピュータになって初めて面白くなってくる。IoTは、「安いマイコンをばら撒こう」ってことじゃなくて、「汎用チップやモジュールがどんどん安くなるよ」って話なんだ。 強いコンピュータ、弱いコンピュータと

    IoTの意味がわかった - 標高+1m
    ympbyc
    ympbyc 2015/11/11
    わかったので書きました。
  • Lispから可変長引数を引き算したらできること - 標高+1m

    Schemeから可変長引数を引き算したら -- Island Life Shiroさんが面白い記事書かれてたので、前に実際に可変長引数をなくしたLispを作って発見したことを紹介します。*1 実装者とは全く別の、遊ぶ人の視点からの記事です。 この記事では意図的にマクロを一切使わないという制約のもと、いわばラムダ計算パズルをします。 左結合のカッコを省略する 少々恣意的ですが、 ((compose f g) x) ;;こう書ける (compose f g x) こういうこと、引数の数が固定なのでカッコを省略しても一意に評価できます。関数を返す高階関数を使うときに便利。以下の例では全てこの仕組みを存分に活用します。 list関数もクオートも使わずにリストを作る Shiroさんの記事で言及されていたように、可変長引数がないと (list 1 2 3 4) ができなくて不便です。これも一工夫でうま

    Lispから可変長引数を引き算したらできること - 標高+1m
    ympbyc
    ympbyc 2015/09/07
    書いた
  • 燃え尽きプログラマと動的開発について - 標高+1m

    徳島の山奥でフロントエンドJSのための動的開発環境を作っている。関連して、会社の技術ブログでチラッと動的開発について触れた。こっちではもう少し突っ込んで書いてみる。 この記事の後半ではBirdについて触れるけれど、この記事の目的はBirdの宣伝ではなく問題提起と解決策の示唆です。一緒に開発環境について真剣に考えてみたい。 mechanic.pilotz.jp 高等言語の発明から60余年、数え切れないほどのプログラミング言語があって、みんなそれぞれ気に入った言語を使ってソフトウェアを記述しているけれど、一部の例外*1を除くと、どの言語を使っても質的な開発スタイルは一緒なのが現状だろう。ドキュメントを参照しながらエディタないしIDEでソースコードを記述し、実行して動作確認をする(テスト含む)。静的言語と動的言語の違いはソースコードの記述と実行の間にコンパイルが挟まるか否かだけだ。 これが悪い

    燃え尽きプログラマと動的開発について - 標高+1m
    ympbyc
    ympbyc 2015/08/11
  • 玲音はBeOSユーザーだった!? lainのLisp開発環境を発掘! - 標高+1m

    こんばんは。アマチュアLisp考古学者の山下です。先週弊社でピザを焼きながら唐突に話題に上った、lainのHandiNAVIにLispのソースコードが表示されているシーンについて検証していきます。 幻のLisp開発環境を手に入れてコネクトワイヤードしたい! まずは先人たちの研究によって判明している事項のまとめ: HandiNAVIのハードウェアのモデルはApple Newton OSはCopland OS Enterprise。これはMacのSystem 8の候補で、結局ヴェイパーウェアになったCopland Projectではないか ソースコードはCMU AIのリポジトリにある、ライフゲームのコード 言語はCommon Lisp 以上のことはwikipedia英語版のSerial Experiments Lainの記事にまとまっています。 ちなみに、このライフゲーム、お好みのCommon

    玲音はBeOSユーザーだった!? lainのLisp開発環境を発掘! - 標高+1m
    ympbyc
    ympbyc 2015/06/12
    書いた
  • 高次元立方体を描く - 標高+1m

    先日の記事で触れたように、次元数の軸が、どれかの次元の軸についての方程式になっていた場合どんな挙動になるのかの実験のためにn次元単位立体を描画するプログラムを書いています。プログラマだと実験の道具を自分の指先でちょちょいと作れてとても便利。 今日の夕方にJSFiddleで暇つぶしに書いていたら、n次元(0含む)の立方体の辺を描画するものが呆気ないほど簡単にできてしまいました。 超立方体 - Wikipedia 正八胞体 - Wikipedia 5次元立方体のワイヤフレーム。コード末尾の方のstateのdが次元数(軸の数)。"Edit in JSFiddle"から、この数値を変えたりして実験できます。 gistはココ: gist: Draw n-dimentional cube on canvas. あくまでスクリプト的なコードで、効率などは無視していますが、わりかしシンプルに表現できました

    高次元立方体を描く - 標高+1m
    ympbyc
    ympbyc 2015/04/13
    描いた
  • 高次元宇宙に移行する - 標高+1m

    n個の要素を持った配列、n次元ベクトルで表された座標を考える。 *1 n次元ベクトルを与えられた時には、普通n次元空間について考えるけれど、このベクトルをよく見ると、もう一暗黙の軸があるように見えてくる。ベクトルの要素数の軸だ。ベクトルに詳しくない僕が知っているベクトルの要素数は自然数(n)個っていう離散的な値しか取らないけれど、これも軸にできることは間違い無いと思う。 3トーラスの表面のxyz座標を計算したいけどなかなか上手くいかない図 数学を全然知らないのに幾何にハマってしまった。ベクトルも集合も高校数学のそれも触りのところしか覚えてないからやり直す必要がある。 というわけでこのテキストで書くことの数学的裏付けを取ることが今の僕には出来ないし、これらはほぼ*2確実に既に数学の言葉で研究されてることなので、このテキストに意味があるのかはよくわからない。「どうやら幾何学ってめちゃくちゃ面

    高次元宇宙に移行する - 標高+1m
    ympbyc
    ympbyc 2015/04/09
    書いた。
  • 夏の夜中に起きるバグ - 標高+1m

    または代々木の12階に出る妖怪について。 某P社では、Android入りの巨大モニタに入れた簡単なアプリを勤怠管理のインターフェースに使っているんだけど、夏が近づいてきたある日から、このアプリに不思議な現象が起き始めた。夜中の11時頃から朝方に掛けて、サーバにランダムな複数の社員の出勤/退勤のリクエストが高速に続々と送られて来るんだ。 ログに残っているUAもIPも例のモニタのものだから、リクエストがあのアプリから送られているのはほぼ間違いない。アプリのバグじゃないかってことでそれを作った張人であるところの僕に調査依頼が来たんだけど、僕は夜中の11時になにかするようなコードを書いた覚えはない。ソースを見ても特に問題の動作を引き起こしそうな記述はなかった。 リクエストの回数も不自然だった。高速に何百回も叩かれているのを見れば、当然ソース上で無限ループが発生している可能性を疑うんだけど、それに

    夏の夜中に起きるバグ - 標高+1m
    ympbyc
    ympbyc 2014/07/15
    書いた
  • VOC.js作った。 視覚と見た目に基づいた非同期コミュニケーションができるよ - 標高+1m

    昨日の記事で書いたVOC (Vision Oriented Communication) の実装を支援するライブラリを作った。 https://github.com/ympbyc/VOC READMEを英語で書いたのでここに日語版を書いとく。 VOCのコンセプト オブジェクト指向やアクターはpushベースだけど、実世界のコミュニケーションの多くはpullベースだ。 僕らはレシーバを指定したメッセージを送らない。 僕らは自分の見た目(e.g. 表情)や自分の周りの状態(e.g. 声)を変える能力を持っている。 僕らは自分の周りの景色を見て、情報を引き出して、それに基づいて行動する。 僕らはそれぞれバラバラに勝手に非同期に行動している 僕らは赤信号が見えたらブレーキを踏むわけで、赤信号が僕らのbrakeメソッドを呼んでくれるわけじゃない。 実装 VOC.Visual(state)は見た目を作

    VOC.js作った。 視覚と見た目に基づいた非同期コミュニケーションができるよ - 標高+1m
    ympbyc
    ympbyc 2014/06/13
    書いた
  • 宇宙API Part2 - 標高+1m

    Part 1からずいぶんと時間を置いてしまった。みんな覚えてるかな。前回はごたまぜだったけど、今日はとくに時空についてに絞って書いてみる。前半は2013年の12月にSmalltalk忘年会で話した事の焼き直しだけど、文章にしたことがなかったからもう一度やってみることにした。 念のため断っておくと、このシリーズで扱っているのは学説的な裏付けがある理論でも、仮説ですらなくて、僕がこの宇宙と同じような宇宙をプログラムとして記述するとしたらどうするかという思考実験だ。でもあなたがこのシリーズの中に実際の宇宙の物理法則との明らかな矛盾を見つけたら是非教えてほしい。 ミュータビリティが因果律を壊す 関数型が持ち上げられオブジェクト指向*1が貶められる大きな理由には、手続きをいくつも持ったものを作っておいてコードの再利用がどうとか言ってるのが馬鹿らしいということの他に、オブジェクトが伝統的に内部状態の書

    宇宙API Part2 - 標高+1m
    ympbyc
    ympbyc 2014/03/16
    書いた。
  • 宇宙API Part1 - 標高+1m

    僕は今頭がhyperactiveになってるからとっておきの考えを書く。これは僕が暇なときにいつも考えてることで、これからも何回か書くことになると思う。 宇宙というソフトウェアのコードを、なるべく簡潔に記述するとしたらどんな風になるのか考えてみる。この宇宙にはオッカムの剃刀という便利なカミソリがあって、同じ結果を説明するのに、簡潔な解法と複雑な解法があったら、複雑な方は無視してもいいことになっている。この宇宙が当はPerlで書かれたなら、それは明らかにLispで書かれたんだ!*1 先に断っておくと、この記事ではあなたが信じている言語やパラダイムがある状況で優位だ不利だという話が頻繁に出てくる。僕はHaskellもLispもSmalltalkも大好きだからある程度中立的な立場を取れると思う。でも一番好きなのはLispだし、C++Javaは嫌いだからやはりそれなりにバイアスはかかる。もしあな

    宇宙API Part1 - 標高+1m
    ympbyc
    ympbyc 2014/02/03
    書いた。読んでほしい。