性格的に Scheme よりも Common Lisp の方が向いてるということが、ここ数日で分かった。
Scheme はその単純さから、基礎を勉強するには本当に役に立った。
すべてがリストであって、quote されていないリストにおいては、先頭の要素が手続きになる。
この至ってシンプルな大原則だけど、他の命令型言語でプログラミングを覚えてしまった者にはシンプルすぎるが故になかなか馴染めないルール。
これを徹底的に身体で覚えるには、特殊形式の多い Common Lisp よりも Scheme の方が適している。
ただ、Scheme は、なんていうか・・・キレイすぎる(と、個人的には思った)。
目の前のやるべきことを、汚くともまずはできるようにする(片付けると言ってもよい)には、Common Lisp の方が仕事が早い。
それに僕のずぼらな性格からしても、性に合ってる気がする。
#Lisp #memo
SN 2013/07/20 23:51:37
Archives > 20130720_memo.html
$ /usr/bin/llvm-gcc-4.2 -std=gnu99 '-L/opt/local/lib/gauche-0.9/0.9.3.3/x86_64-apple-darwin12.2.0' '-L/opt/local/lib' -bundle -flat_namespace -undefined suppress -o dbd_sqlite3.so 'dbd_sqlite3.o' 'dbd_sqlite3lib.o' -lgauche-0.9 -lm -lpthread -lsqlite3
duplicate symbol _Sqlite3StmtClass in:
dbd_sqlite3.o
dbd_sqlite3lib.o
duplicate symbol _Sqlite3DbClass in:
dbd_sqlite3.o
dbd_sqlite3lib.o
ld: 2 duplicate symbols for architecture x86_64
collect2: ld returned 1 exit status
#Error
SN 2013/07/19 08:28:46
Archives > 20130719_gauche_dbd_sqlite3_install_error_memo.html
Mac OS X (Mountain Lion) 環境で Gauche の SQLite3 ドライバーを入れる所でちょっとつまずいているのでメモ。
まずもって、 GitHub の mhayashi1120/Gauche-dbd-sqlite3 から、武蔵の日記さんのこちらの記事のやり方で試してみても、make の段階でエラーが出てしまい断念(勉強せいって話なんですが・・・)。
なので、こちらから gauche-dbd.sqlite3.080412b.tar.gz をダウンロードして gauche-package install で入れてみました。ここでもちょっとコツがあった。
# gauche-dbd.sqlite3.080412b.tar.gz を
# ダウンロードしたディレクトリに移動した上で
# リネーム
$ mv gauche-dbd.sqlite3.080412b.tar.gz gauche-dbd.sqlite3.tar.gz
# リネーム済みの圧縮ファイルを指定する形で install
$ sudo gauche-package install gauche-dbd.sqlite3.tar.gz
これで SQLite3 ドライバーのインストール自体はうまく行きました。
ただ、プログラミングGauche のP.368 前後に載ってる relation-accessor などは、SQLite には通用しないようで、発行した SELECT 文の各要素(カラムのデータ)にアクセスするには、dbi-get-value を使って番号でカラムのデータを取得するようです(ちょっと不便・・・)。
(use dbi)
(use util.match)
(use util.relation)
(use gauche.sequence)
(use gauche.parameter)
(define *db-name* "dbi:sqlite3:./schedule.db")
(define db (make-parameter #f))
;; ・・・
;; メモのため抜粋。いろいろ省略
(define (list-sch)
(let* ((result (dbi-do (db) "SELECT day, plan FROM plans"))
;; (getter (relation-accessor result)) ;; この子が動いてくれない
(plan-list (map
(lambda (row) (cons (dbi-get-value row 0) ;; "day"
(dbi-get-value row 1))) ;; "plan"
result)))
(for-each
(lambda (p)
(sch-print (car p) (cdr p)))
plan-list)))
また時間見つけてもうちょっと調べてみる。
#Gauche #MacOSX #SQLite #dbd #dbi #relation-accessor #dbi-get-value #Scheme #Lisp
SN 2013/07/17 19:18:23
Archives > Gauche_sqlite3_dbd_install_MacOSX.html
Beyond Interaction[改訂第2版] -クリエイティブ・コーディングのためのopenFrameworks実践ガイド
Beyond Interaction の第2版がいつの間にか出てましたね。気付きませんでした。
この前、下北の Village Vanguard に行ったらひょっこり置いてあった。
openFrameworks の基本を学ぶ上では、書籍の版は特に関係ないと思いますが、移り変わりの激しいオープンソースの現在を知るという視点からすると、今から買うなら第2版の方が良いんだろうなと思います。
上記と双璧をなす Built with Processing[Ver. 1.x対応版] -デザイン/アートのためのプログラミング入門 もとても良書なので、使用言語は違いますが併せて読むといいと思います。
Processing に関してはクロスプラットフォームで、且つ、スクリプト形式でバンバン書けるという利点からか、一般に利用されている範囲も広いようですし、書籍も多いです。
言語設計者自身が著した ビジュアライジング・データ ―Processingによる情報視覚化手法 とか、最近だと ジェネラティブ・アート -Processingによる実践ガイド とか。
個人的に、Processing は HTML5 の Canvas を使ってそのままのソースコードを JavaScript で動かすことができる processingjs の存在が大きいと思います。
話を openFrameworks に戻すと、汎用性という点ではどうしても Processing には及びませんが、C++ で実装されていることによる処理能力の高さはやっぱり魅力です。
ハードウェアの持つポテンシャルを最大限に活かすような(またはそれが必須条件のような)作品を制作するのであれば openFrameworks を選択するほうが懸命でしょう。
できることのレシピは、書籍などでトピックを眺めているうちは openFrameworks も Processing もさして変わらないように見えますが、いざ自分でコードを書いて走らせてみると、その違いは歴然です。
書籍にも書いてあった記憶がありますが、できることのレシピにそれほど差がないことを利用して、スケッチは Processing で書いて、実装(清書)は openFrameworks という開発スタイルも全然有りだと思います。
(その名の通り Processing のスクリプトは「Sketch」と呼ばれるプロジェクトファイルに保存して行きます。)
僕個人は初め openFrameworks に惹かれてひと通り勉強してたんですが、Ben Fly さんの ビジュアライジング・データ ―Processingによる情報視覚化手法 の存在が大きく、また、そこまで大掛かりなビジュアルアート作品を制作したりするわけではないこともあって、今では Processing 方を好んで書きます。
#Visualizing #Processing #openFrameworks #Books
SN 2013/07/14 18:20:50
Archives > Beyond_Interaction_press2.html
© 2008-2013 Basic Werk