[Openmcl-devel] Re: compiling cl-sdl with openmcl

Matthew Danish mdanish at andrew.cmu.edu
Mon Jan 27 19:41:03 UTC 2003


On Mon, Jan 27, 2003 at 08:24:43PM +0100, nik gaffney wrote:
> ? (require :sdl)
> ;;; Please wait, recompiling library...
> ;;; Please wait, recompiling library...
> > Error: Can't create directory /usr/lib/common-lisp/openmcl/sdl-ffi/.
> > While executing: ENSURE-DIRECTORIES-EXIST
> > Type :POP to abort.
> Type :? for other options.
> 1 > 

Permissions?

> > On a side note, CL-SDL is known to compile on OpenMCL but it requires
> > some additional code to successfully open a window.  Gary Byers had that
> > much working a number of weeks ago, but I don't know if it'll work any
> > further than that.  (OSX, anyway).
> 
> is this code available somewhere?

Attached.  It was tailored to his system, though, so keep that in mind.

-- 
; Matthew Danish <mdanish at andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."

-------------- next part --------------
;;; I just moused on each of these forms in sequence and did C-M-X in
;;; an ILISP session.  Making the file LOADable would require paying
;;; some attention to EVAL-WHEN.
(in-package "CCL")                      ; some of the OBJC stuff is in CCL::.

;; I want to send an OBJC message or two.
(require "APPLE-OBJC")

;;; This assumes that
;;; "asdf.lisp"  is in /usr/local/src/asdf.losp
;;; The uffi source distribution is in /usr/local/src/uffi/
;;; cl-sdl is in /usr/local/src/cl-sdl/, and the sdlstub.dylib library
;;;   is in cl-sdl/c.
;;; The current directory is /usr/local/src/ .

(load "asdf.lisp")
(setq asdf:*central-registry* '("/usr/local/src/uffi/"))
(asdf:oos 'asdf::load-op :uffi)
(push :unix *features*)                 ;Ahem.  Whoops.
(cwd "cl-sdl/c/")                       ; so shared lib is in ./
(push "/usr/local/src/cl-sdl/" asdf:*central-registry*)
(asdf:oos 'asdf::load-op :sdl)

;;; This is supposed to allow a command-line program (e.g., something
;;; not contained in a .app bundle) to connect to the window system.
(defun enable-foreground (&optional bundle-string)
  (%stack-block ((psn 8))
    (external-call "_GetCurrentProcess" :address psn)
    (when bundle-string
      (with-cstrs ((name (car (last (pathname-directory bundle-string)))))
	(external-call "_CPSSetProcessName" :address psn :address name)))
    (external-call "_CPSEnableForegroundOperation" :address psn)))


;;; This seem to establish a window server connection.  The bundle path
;;; may not matter all that much.
(enable-foreground (native-translated-namestring
                    (merge-pathnames "OpenMCL.app/" (truename "ccl:"))))

;;; It seems to be necessary to instantiate "NSApp", the single shared
;;; instance of the NSApplication class at this time.  Sorry to screw
;;; with the readtable here, but (again) I'm lazy.
(setq *readtable* *objc-readtable*)
(defvar *NSApp* [(@class "NSApplication") "sharedApplication"])

;;; Now, let's start using that connection.
(sdl:init sdl:+init-video+)

;;; If we don't have an autorelease pool in place, we'll hear about
;;; it.  We should really create and release an autorelease pool
;;; around any ObjC calls that create short-lived (autoreleased) ObjC
;;; objects.  There are issues related to autorelease pools and
;;; OpenMCL's cooperative threads (there will be other issues related
;;; to native threads, but they're more straightforward..)

(defparameter *autorelease-pool*
  [[(@class "NSAutoreleasePool") "alloc"] "init"])

(defvar *s* (sdl:set-video-mode 640 480 16 0))

;;; There should be a window onscreen now.  Since the application layer
;;; doesn't handle events yet, it may be necessary to hide all applications
;;; and then activate "OpenMCL" in order to see the window.
;;; I think that in order to get reasonable behavior from this point on,
;;; we may need to install some sort of event loop (possibly by forking
;;; off a thread to do so.)  I'm not sure, and I'm not sure how SDL
;;; handles events in general.
;;; Things like window-update notifications are kind of a side-effect
;;; of asking for events; they're recieved via the same IPC mechanism
;;; as events are, and are handled in the Cocoa runtime.

;;; I didn't load anything that would have defined a CL-SDL package;
;;; I'm not sure where cl-sdl.lisp is.
#+notyet (cl-sdl:draw-filled-rectangle *s* 10 10 100 100 200 200 200)


More information about the Openmcl-devel mailing list