There is a tool in quicklisp which _might_ be useful,
https://github.com/lmj/lfarm (warning: self-promotion).
;;; in the dedicated compiler process
(lfarm-server:start-server "127.0.0.1" 11111 :background t)
;;; in the main lisp process
(setf lfarm:*kernel* (lfarm:make-kernel '(("127.0.0.1" 11111))))
(defun compile-remotely (code)
(let ((channel (lfarm:make-channel)))
;; TODO: generate pathname and delete later
(out "tmp.lisp" :if-does-not-exist :create)
(with-standard-io-syntax (prin1 code out)))
;; TODO: delete fasl
(load (lfarm:receive-result channel))))
(compile-remotely '(defun foo () 99)) ;=> T
(foo) ;=> 99
There are some tricks to avoid consing (reusing buffers, sending a
task name instead of a lambda, defining a custom protocol), but these
may not be significant in comparison to compilation, which is now
gone. If not consing is an absolute imperative then you probably
expected to write everything from the ground up anyway.
As Fare mentioned it would be nice if we could compile/load to/from
arbitrary streams instead of going through files. Perhaps it could be
offered as an extension, say, COMPILE-SEQUENCE and LOAD-SEQUENCE.
On Mon, Jul 1, 2013 at 6:41 AM, Tito Latini <tito.01beta@...> wrote:
> I'm writing a music/dsp programming environment in Common Lisp called
> Incudine (http://incudine.sourceforge.net). Currently it works only
> with SBCL and the performance is really good. Thank you for the magic!
> Incudine uses different memory pools and the format for the sample is
> DOUBLE-FLOAT by default, unboxed type on the C heap (an example of the
> expansion of DEFSYNTH is here: http://incudine.sf.net/tutorial_04.html).
> Therefore there is not garbage during the synthesis in realtime of a
> well definited synth. However there is an inevitable noise if a synth
> is compiled while something is playing in realtime.
> I'm thinking about the possibility to use two instances of SBCL, one
> dedicated to the compilation:
> - SBCL-A sends to SBCL-B all the stuff to compile
> (with a possible cons-pool)
> The priority of SBCL-B is lower than SBCL-A.
> - SBCL-A loads the fasl (without to use the disk if possible)
> compiled by SBCL-B (is it considerable for gc?). The latency
> for non-synthdef things is probably not big.
> - All the standard-output is redirected to SBCL-B
> Besides, two instances of SBCL require a thorough distribution of the
> resources. To complicate the code is not my preferred sport but the
> end justifies the means. However, the possibility to stop-the-world is
> lower but yet possible.
> The alternative is to use another implementation of CL when the
> performance is not so important. To use more cores for the synthesis
> could help in this direction.
> I would like to know your advice about this problem.
> Tito Latini
> PS: about 1.1.9, tested 1656e54 without problems on x86_64
> This SF.net email is sponsored by Windows:
> Build for Windows Store.
> Sbcl-devel mailing list