何の記事? CommonLispで自作モジュールを作ります。 モジュールのロードにQuicklispと、 モジュールの雛型を作るためにcl-projectを使用します。 Quicklispで自作モジュールを使用するという記事をみて、 すごく助かった+cl-project使うと楽かも?とおもったので書いてみました。 基本的にはcl-project使って雛形を作ることを楽にするということと、 Quicklispあたりの使い方の説明も含めてかいてみたいと思います。 対象とする人 SBCL(Steel Bank Common Lisp)でLisp始めたはいいけどモジュールのつくり方がわからん。 なんかASDFとかいうの出てきたけどよくわからん。 って人たち 環境 OS : Windows 10 x64 処理系 : Steel Bank Common Lisp 1.2.15 準備 ※SBCLがインス
この記事は、David Vázquezさんの記事 How to write a modern Lisp library with ASDF3 and Package Inferred Systemの日本語訳です。Davidさんに許可をいただき、日本語訳を共有させていただけることになりました。 はじめに 最近よく見かけるパッケージの使い方は、package.lispかpackages.lispを加える手法です。多くの場合、このファイル(package.lispかpackages.lisp)は、最初に読み込まれるファイルで、他のファイルが使うパッケージを定義します。この手法は、多くのプロジェクトで用いられています。しかし、パッケージ群が大きくなるにつれて、複数のファイル間での依存関係を管理する規則が必要になります。 パッケージ群を定義するための代替策として、1ファイル1パッケージ(one pa
これまでのあらすじ package-inferred-systemは、pakageのinferred-systemである。 なんだか体がだるい感じのぼくはこころに学びを沁みわたらせるため、ライブラリのパッケージをすっきりと書くことはできないか考えてみようと思った。Common Lispを書いていてディレクトリ構成とパッケージ構造を同じにしたいとき、以下の2点が面倒だ: パッケージ名をわざわざパッケージ定義に書くこと パッケージ名とディレクトリ名を一致させること パッケージ構造を変えたとき、変更が漏れやすい そこでぼくは、1ファイル1パッケージのスタイルでプログラミングできるらしいpackage-inferred-systemを試してみようと考えたのだった── TL;DR package-inferred-systemは、ディレクトリ構造からパッケージ名を決定するためのものではない。 pac
その筋では有名な usocket も使う機会がなかったため、どんなものか試したときのお話。 以下にある、cl-tcpip.lisp をサーバとクライアントに分け、チョットだけ手を入れて実行してみた。 https://gist.github.com/shortsightedsid/71cf34282dfae0dd2528 サーバ側 create-server.lisp ⇒ ;;; Server Test ;;; Step1 <Define Packages> <Create Server> ;; ----------------------------------------------------------------------------------------------- ;; Step1 <Define Package> ;; -------------------------
この記事はLisp Advent Calendar 2016の4日目の内容です. 「Common Lispで配布するアプリケーションの書きかた」について誰も書かないようなので,拙書「Common Lispと人工知能プログラミング」の第20章,パッケージとモジュールの内容をここに公開します.本文中に他の章の内容への引用があることを,お断りしておきます.なお,この電子本はこちらから入手できます. プログラムを配布するときには,通常ファイル構造を一定に保つようにして,アプリをどこにおいても動くようにするが,そのためには最初にロードするプログラムのロード時のファイルパスネームを取りだして,それとのファイル構造的な相対的関係でプログラムをロードするようにする.そのとき,処理系依存性をなるべく少なくするには,ファイル関係についてpathnameを駆使することも重要となる.パスネームについては上記電子本
これは fukamachi products advent calendar 2016 の4日目の記事です。 今日はcl-projectについて話します。 コーディングスタイルの提唱 前回の記事のCavemanからは話が前後します。 Clackの思想は疎結合性と再利用性を高めることでした。それはClackを使ったアプリケーションだけでなくClack自身についても同様であり、つまりは一般的なCommon Lispアプリケーション自体の疎結合性を高めることも目指したものでした。 Common Lispにはアプリケーションの分割単位として「パッケージ」と「システム」があります。「システム」はプロジェクトの一つの読み込み単位であり、複数のファイルと複数のパッケージを含みます。 他のプログラム言語に親しんだ人には違和感があるかもしれませんが、Common Lispのパッケージはファイル単位と結びつい
This is just a draft. Package One package per one file Strangely enough, in case of legacy CL programs, their packages are declared in one file (maybe named "package.lisp"). In other hand, we recommend to declare each packages in each files. You should always put like following code at the top of each Lisp files. (in-package :cl-user) (defpackage style-guide.core (:use :cl)) (in-package :style-gui
κeenです。最近のCommon Lispのパッケージ管理はql:quickloadしか知らないという方も多いのではないでしょうか。しかしそれだけでは機能が足りないこともあります。Common Lispには様々な管理システムがあるので整理しましょう。 provide, require 同じファイルを読み込まないための原始的なシステムです。Common Lispの標準の機能です。(require 'foo)がファイルをロードし、ロードされたファイル内で(provide 'foo)しておくと2回目以降の(require 'foo')はファイルを読まずにすぐさま返ります。 ここで問題なのがrequireがどこのファイルを捜しにいくかは処理系依存なところですね。なので生のrequireは使えないと思っておいた方が良いでしょう。 ASDF 3 Another System Definition Fa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く