マイコン向け処理系の実装戦略を調べる会 - .mjtの日記復帰計画
追記: mruby/c 1.1にはGCが有るらしい http://www.s-itoc.jp/news/notice/726 C向けにヒープ実装を用意するにあたって、まぁ富豪的にガツンとやってしまえば良いんじゃないかと適当に考えていたけど、営業上どうしても32KiBヒープで動くアプリを用意する必要が出てきたので比較的真面目にROM化やポインタの圧縮等を考える必要が出てきた。というわけでいくつか処理系を見てまわることにする。 PICOBIT (R4RS Scheme) https://github.com/stamourv/picobit 本家 http://users.eecs.northwestern.edu/~stamourv/slides/picobit-ifl09.pdf スライド https://github.com/stamourv/sixpic SIXPIC: Schemeで
多値を扱えるシンプルなVMが欲しい会 - .mjtの日記復帰計画
というわけで、前回( http://d.hatena.ne.jp/mjt/20170321/p1 )見たSECDRマシンをベースに、多値を扱えるVM(SECDVマシン?)を考えていく。 多値を直接的に扱うことで、メモリ効率が改善できるのではないかと考えている。SECDRマシンでは環境(Environment)を表現するためにリストを使っており、フレーム内のformal、つまり手続きの引数1つごとにCONSセルを1つ消費することになっている。通常のシチュエーションではSchemeの手続きの引数は2つ以上あるため、ちょっともったいない気がする。 手続きが2つ以上の引数を取ることを前提にするということは、手続きが多値を取ることが多いということになる。常識的なシチュエーションでは手続きの引数は固定長個であるため、環境フレームをlistの替わりにvectorで表現することに近い。 listではなくv
SECDRマシンのコンパイラを読む - .mjtの日記復帰計画
コンパクトなVMベースのScheme処理系としてはSECDR Schemeが有る。というわけで、SECDR Schemeのコンパイラを読んでみる。 http://www.maroon.dti.ne.jp/nagar17/mulasame/ SECDR-Scheme https://gist.github.com/okuoku/3f2e469497bbf12575e8 SECDR schemeから抜き出してきたコンパイラ本体 http://storage.osdev.info/pub/idmjt/diaryimage/1204/secdrscm.pdf SECDR schemeのドキュメント (アーカイブの.texをlatexに掛けたもの) コンパイラは非常にコンパクトで、VMの命令も19種類しか無い。SECDRマシンの重要な特徴は末尾再帰を直接的にサポートしている点と言える。なのでコンパイ
めくるめくギリギリCPUの世界 - .mjtの日記復帰計画
追記 : ↓のmcpuがネタ元にしているmprozは拡張され、SCSIインターフェースやビデオ出力、マルチタスクOSさえ備えたxprozになっている。http://www.bitlib.de/pub/xproz/ 詳細はドイツ語PDFしかないが、アーキテクチャは英語txtで読める。 prev: http://d.hatena.ne.jp/mjt/20100912/p2 世間には、MISC - Minimal Instruction Set Computerと呼ばれるジャンルのCPUが有る。RISCのRはReducedなので、Minimalというくらいならどれくらい少いのか。 まず、OISC - One Instruction Set Computerが有る。 http://en.wikipedia.org/wiki/One_instruction_set_computer コンピュータを構
すごい勢いでSchemeコンパイラを作りたい の2 - CPS変換 - .mjtの日記復帰計画
2010年書き初め。 moshをconfigureする度に完成に近づいていくコンパイラの第2回*1はCPS変換の実装。 90 minutes〜のPDF( http://www.iro.umontreal.ca/~boucherd/mslug/meetings/20041020/90-min-scc/90-min-scc.pdf )を先に読むべき。 ノーマライズ http://github.com/okuoku/yunilibs/blob/0b3182f10e84270dae6c3e673eaffb87cd7aaeb3/lib/yuni/yunicomp.ss#L132 変換時に考えることを減らすために、以下のノーマライズを行う。 lambdaが複数の式を持たないように、bodyをbeginで包む beginが1つの式しか持たない場合はbeginを外す。 変換の対象はquote以外の全体とな
DockerのAlpine化に向けて / Guile対応と実装WARの管理 - .mjtの日記復帰計画
Cygwin64ビルドのためのパッチをBoehmGCに投げました( https://github.com/ivmai/bdwgc/commit/4e24d219d29abb2b111bb9a9ccb13c3f149a855a )。Gauche由来のパッチが溜っていくね。。(e.g. https://github.com/ivmai/bdwgc/pull/91 ) 基本的にアンダースコアを付けるだけ。Gauche等のパッチと違うのはGC_wordにキャストする点だけか。 Musl libc対応 で、今やっているのはDockerのAlpine化に向けたMusl libc対応で、後動いていないのはincremental collectionだけ。Issueに書いた( https://github.com/ivmai/bdwgc/issues/73#issuecomment-179080943 )
Dockerでも再現できない環境 / gauche-packageに対応 / Windows対応 - .mjtの日記復帰計画
というわけでDockerベースのテスト環境をTravisCIで始めた。基本的にはライブラリのbootstrapやFFIライブラリのビルドも含んだ完全なビルド過程の再現を含んでいる。もっとも、まだFFIテストは統合していない(まだ事故ったときにコアダンプとか回収できないし)。 Docker上でも"手元で成功するのにリモートで失敗するテスト" せっかくDockerにしたのに、一発目から"手元で成功するのにリモートで失敗するテスト"が表われてしまった。ある種の魔物がおるね。。 3/6 Test #3: RACKET-_sanity.sps ...............***Failed 0.78 sec lib-stub/racket/r7b-util/features.mzscheme.sls:6:4: import: cannot find suitable library install
yuniのChicken-schemeサポート / AppVeyorでCI - .mjtの日記復帰計画
- よく有るやつ OSS側を触るのはなんか普通に半年ぶりになってしまった。。 今年はちょっと計画立てられるような状況でもないので、まぁノンビリと。。 Chicken-scheme上のsyntax-rulesの制限 諸般の事情でyuniから(yuni shorten)ライブラリを外すことにしたので、Chickenのような実装もサポートできるようになった。というのも、Chickenはマクロ内部で定義したマクロをexportできないという制約が有って( https://github.com/okuoku/yuni/issues/10 )、合成された、つまり、ソースコード上に無い名前を持つマクロをエクスポートするための良い手段が無い。 というわけでyuniは基本的にR5RS syntax-rulesの範囲で全てのライブラリを書くことにした。ただし、これでもChickenにしかない制約に当たることに
Schemeファンのための『ゲームエンジン・アーキテクチャ』立ち読みガイド - .mjtの日記復帰計画
(本文p292。) ゲームエンジン・アーキテクチャはノーティドッグ(NDI)のエンジニアが書いたゲーム開発のかなり広範なトピックを扱った書籍の日本語訳。 http://www.sbcr.jp/products/4797377484.html http://minahito.hatenablog.com/entry/2015/03/28/183822 https://timagire.wordpress.com/2015/04/02/ NDIにはかなり深刻なLisp文化が有る: http://d.hatena.ne.jp/mjt/20131027/p1 RacketCon 2013でのプレゼン https://twitter.com/okonomiyonda/status/479429000842850304 GOAL(彼らの歴史的なLispバリアント言語)のドキュメント表紙画像 この本はか
.mjtの日記復帰計画
サブモニタに使っていたFlexScan S170が 45747時間の使用の末画素欠け等出てきたので。。 Amazonのタイムセールで3万円だった。 商品説明が変 https://www.amazon.co.jp/gp/product/B07SCZ5STT/ 商品URL http://e7e.co/Vc0r0 説明書への短縮URL (Dropbox上のPDF) 【ミニHDMIポート二つ搭載】普通のHDMI出力設備全て対応できます、パソコン、ノートPC、プレゼン用、一眼レフカメラ、 PS3/PS4/Xbox One/Nintendo Switchゲーム機、デスクトップPCなど ミニHDMI→HDMIケーブルは付属しております。 商品説明ではmini-HDMIが付いているように書かれているが、これは間違いで、結局のところ説明書が正しかった。実際には標準HDMI(2.0) + mini-DP +
NUONのUIフレームワークとScheme - .mjtの日記復帰計画
惜しまれつつ更新終了となった( http://www.drdobbs.com/architecture-and-design/farewell-dr-dobbs/240169421 )DDJに、NUON SDKのUI フレームワークに関する記事が掲載されている。 http://www.drdobbs.com/jvm/bob-meets-nuon/184404973 http://terrainformatica.com/org/bob_article.htm テキストのみの転載 NUONは独自のVLIWプロセサ( http://d.hatena.ne.jp/mjt/20110131/p2 )を搭載したゲーム機兼DVDプレーヤで、ATARI Jaguarとの関係が深い(開発者の一部が重複している)。NUONのUIフレームワークに基いたアプリケーションは、HTML風のUI定義言語とBobと呼ば
ライセンスの諸問題 - .mjtの日記復帰計画
ちょっとnmoshの手が止まっていた。今日から再開予定。 nmoshは一応MIT/BSDライセンスということで方々で使ってきた。一度は( http://d.hatena.ne.jp/mjt/20111204/p2 )legalの方も入れて、使うコンポーネントについてはクリアランスもしている。 しかし今回別の機関で使う案件があって、配布物としてはNG判定が有って結局C++ / Cで諸々書き直す事態になった。 (経験上機関が異なればlegalの見解もそれぞれになる。これは仕方ないと個人的には考えている。) もっとも、今回のNG判定でnmosh自体が違法な状況にあると判定されたとは考えていない。単に僕がスーツを着て偉い人のハンコを集めに出向く程でも無いと考えて取り下げただけで、プロトタイプをSchemeでやったあとC++にするのは寧ろよくある事と言える。 修正を要求されたもの いくつかの点は修正
Precise GCへの道 - .mjtの日記復帰計画
nmoshはBoehmGCをGCに使っている。BoehmGCはそれなりに高速だし移植性もあるのだけれど、エクストリームな状況ではやっぱり使いづらい。 BoehmGCから自前のGCにスイッチしたケースとしては、Chibi SchemeやMono、Racketがある。 Chibiの場合はちゃんと個々のオブジェクトについてマーク/スイープコードを書いている(= BoehmGCを使わなかった場合と同様の手間を書けている)。 Monoはsgen GCに乗り換えているが、sgenはそもそもスタックは保守的にマークする(Linux除く: http://www.mono-project.com/Working_With_SGen )のでBoehmGCを使っていたのと事実上はあまり違わない。もちろん、Precise GCとするためのAPIの追加などは行なっている。 GCの無い言語でどうGCの有る処理系を書く
伝説の68kエミュレータsyn68kはScheme風マクロ言語で生成される - .mjtの日記復帰計画
(prev: http://d.hatena.ne.jp/mjt/20100912/p2 ) https://github.com/ctm/syn68k/tree/master/syngen https://github.com/ctm/syn68k/blob/master/runtime/68k.scm - 実際の記述 当時としては異様に高速で微妙な精度を誇ったMacOSエミュレータのExecutorは、ちょっと前(2008)にソースコードがGitHubで公開された。 Executorの絶妙なポイントは: 現在ゲームの移植等に使われているlibSDL ( http://www.libsdl.org/ ) はもともとExecutorのために書かれた[要出典] Executorよりも早くにLokiのゲームが有るらしい。といっても最初のWin32 ExecutorからSDLを使用していて、今で
古くて新しい"フロー"UI - .mjtの日記復帰計画
nmoshの新しいREPLを設計する上で一番参考にしているのはMathematicaのノートブックUI。 これは素晴らしいNeXT文化でありながらWWWのようには影響を与えることが出来なかったように思う。WWWの操作性 - "進む"/"戻る" - はNeXTからの遺伝で、これはかなりの広がりを見せている。MathematicaのノートブックUI、つまり"触れる情報"が世界中に影響を与えていたら今とは違ったコンピュータインタラクションの世界があったかもしれない。(もちろんいわゆるDHTMLとかで実現している部分は大いに有るが。。) MathematicaのREPLはnotebookと呼ばれる。様々なインタラクション可能なオブジェクトをノートブック中には出力できる。 Schemeの場合DrRacketのような図形等を扱えるREPLは既にある。 フローUI 上から下に流れる対話式のUIを"フロー
Cannon catとFORTHプログラムによるアプリケーション - .mjtの日記復帰計画
prev: http://d.hatena.ne.jp/mjt/20120704/p1 Catは基本的にFORTHで書かれている。このFORTHのマニュアルはbitsaversで公開されている: http://www.bitsavers.org/pdf/informationAppliance/ http://www.bitsavers.org/pdf/informationAppliance/cat/Canon_Cat_How-to_Guide_1987.pdf - Catの操作マニュアル http://www.bitsavers.org/pdf/informationAppliance/cat/tForth_Manual_Sep88.pdf - FORTH言語のマニュアル http://www.bitsavers.org/pdf/informationAppliance/cat/Tec
楽天Kobo Touch - .mjtの日記復帰計画
もちろん楽天Kobo Touchを買った。ビックカメラのポイントで購入。 Kobo Touchは現在日本でサービスインしている電子書籍ビューアとしては最高なものと言える。 ファームウェアアップデートは.tgzを展開するだけで、一切の認証は無い GPLコードはGitHubで配布 : https://github.com/kobolabs/Kobo-Reader プラグイン(アプリ)のサンプルコードまである。現状のファームウェアでは利用できない気がするが。。 U-bootで起動し、シリアルポートにも容易にアクセスできる 素晴らしい。欠点は楽天しかない。 前回のKindle2( http://d.hatena.ne.jp/mjt/20110501/p2 )のようにnmoshも移植したい。 罠 Koboは起動にアクティベーションを必要とする。つまり、WindowsかMacのどちらかを持っていないと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
