March 2006 - mcclim-devel - mailman3.common-lisp.net

[mcclim-devel] Patch: freetype support for SCL and CMUCL.
by Douglas Crosher 14 Mar '06

14 Mar '06

* Experimental/freetype/: Add support for the Scieneer CL, and also attempt to support CMUCL. Regards Douglas Crosher Index: Experimental/freetype/freetype-ffi.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Experimental/freetype/freetype-ffi.lisp,v retrieving revision 1.3 diff -c -r1.3 freetype-ffi.lisp *** Experimental/freetype/freetype-ffi.lisp 22 Aug 2005 09:28:34 -0000 1.3 --- Experimental/freetype/freetype-ffi.lisp 14 Mar 2006 00:18:37 -0000 *************** *** 3,9 **** (DEFPACKAGE :FREETYPE (:USE :cl #+sbcl :sb-alien ! #+cmucl :alien #+cmucl :c-call) (:EXPORT "MEMORY-BASE" "DESCENDER" "LINEAR-VERT-ADVANCE" "YX" "XX" "FREE" "AVAILABLE-SIZES" "COVERAGE" "METRICS" "RASTER-FLAG" "GLYPH" "GET-CHAR-INDEX" "LIMIT" "STRING" "SHIFT" "LEN" "UNDERLINE-POSITION" "RASTER-NEW-FUNC" "POINTS" "TAG" "SIZE-INTERNAL" "NUM-SUBGLYPHS" "UNITS-PER-EM" "LIBRARY" "ALLOC" "OPEN-FACE" "ATTACH-FILE" --- 3,9 ---- (DEFPACKAGE :FREETYPE (:USE :cl #+sbcl :sb-alien ! #+(or cmu scl) :alien #+(or cmu scl) :c-call) (:EXPORT "MEMORY-BASE" "DESCENDER" "LINEAR-VERT-ADVANCE" "YX" "XX" "FREE" "AVAILABLE-SIZES" "COVERAGE" "METRICS" "RASTER-FLAG" "GLYPH" "GET-CHAR-INDEX" "LIMIT" "STRING" "SHIFT" "LEN" "UNDERLINE-POSITION" "RASTER-NEW-FUNC" "POINTS" "TAG" "SIZE-INTERNAL" "NUM-SUBGLYPHS" "UNITS-PER-EM" "LIBRARY" "ALLOC" "OPEN-FACE" "ATTACH-FILE" *************** *** 42,50 **** (in-package :freetype) ! #+cmucl (alien:load-foreign "/usr/lib/libfreetype.so.6") #+sbcl (load-shared-object #+darwin "/usr/X11R6/lib/libfreetype.dylib" #-darwin "libfreetype.so") --- 42,61 ---- (in-package :freetype) ! #+cmu (alien:load-foreign "/usr/lib/libfreetype.so.6") + #+scl + (alien:load-dynamic-object #+64bit "/usr/lib64/libfreetype.so.6" + #-64bit "/usr/lib/libfreetype.so.6") + + #+(or scl cmu) + (defmacro define-alien-type (&rest rest) + `(def-alien-type ,@rest)) + #+(or scl cmu) + (defmacro define-alien-routine (&rest rest) + `(def-alien-routine ,@rest)) + #+sbcl (load-shared-object #+darwin "/usr/X11R6/lib/libfreetype.dylib" #-darwin "libfreetype.so") *************** *** 373,379 **** (freetype:driver freetype:module) (freetype:num-params freetype:int) (freetype:params (* freetype:parameter)))) (define-alien-routine ("FT_New_Face" freetype:new-face) freetype:error (freetype:library freetype:library) ! (freetype::filepathname #+cmucl c-call:c-string #+sbcl c-string) (freetype::face_index freetype:long) (freetype::aface (* (* freetype:face-rec)))) (define-alien-routine ("FT_New_Memory_Face" freetype:new-memory-face) freetype:error (freetype:library freetype:library) (freetype::file_base (* freetype:byte)) (freetype::file_size freetype:long) (freetype::face_index freetype:long) --- 384,390 ---- (freetype:driver freetype:module) (freetype:num-params freetype:int) (freetype:params (* freetype:parameter)))) (define-alien-routine ("FT_New_Face" freetype:new-face) freetype:error (freetype:library freetype:library) ! (freetype::filepathname #+(or cmu scl) c-call:c-string #+sbcl c-string) (freetype::face_index freetype:long) (freetype::aface (* (* freetype:face-rec)))) (define-alien-routine ("FT_New_Memory_Face" freetype:new-memory-face) freetype:error (freetype:library freetype:library) (freetype::file_base (* freetype:byte)) (freetype::file_size freetype:long) (freetype::face_index freetype:long) *************** *** 403,409 **** (define-alien-routine ("FT_Load_Char" freetype:load-char) freetype:error (freetype:face freetype:face) (freetype::char_code freetype:ulong) (freetype::load_flags freetype:int)) ! (define-alien-routine ("FT_Set_Transform" freetype:set-transform) #+cmucl c-call:void #+sbcl void (freetype:face freetype:face) (freetype:matrix (* freetype:matrix)) (freetype:delta (* freetype:vector))) (define-alien-type freetype:render-mode (enum freetype::render-mode- (:ft-render-mode-normal #.#o0) (:ft-render-mode-mono #.1))) --- 414,420 ---- (define-alien-routine ("FT_Load_Char" freetype:load-char) freetype:error (freetype:face freetype:face) (freetype::char_code freetype:ulong) (freetype::load_flags freetype:int)) ! (define-alien-routine ("FT_Set_Transform" freetype:set-transform) #+(or cmu scl) c-call:void #+sbcl void (freetype:face freetype:face) (freetype:matrix (* freetype:matrix)) (freetype:delta (* freetype:vector))) (define-alien-type freetype:render-mode (enum freetype::render-mode- (:ft-render-mode-normal #.#o0) (:ft-render-mode-mono #.1))) *************** *** 437,443 **** (define-alien-routine ("FT_FloorFix" freetype:floor-fix) freetype:fixed (freetype::a freetype:fixed)) ! (define-alien-routine ("FT_Vector_Transform" freetype:vector-transform) #+cmucl c-call:void #+sbcl void (freetype::vec (* freetype:vector)) (freetype:matrix (* freetype:matrix))) (define-alien-type freetype:encoding --- 448,454 ---- (define-alien-routine ("FT_FloorFix" freetype:floor-fix) freetype:fixed (freetype::a freetype:fixed)) ! (define-alien-routine ("FT_Vector_Transform" freetype:vector-transform) #+(or cmu scl) c-call:void #+sbcl void (freetype::vec (* freetype:vector)) (freetype:matrix (* freetype:matrix))) (define-alien-type freetype:encoding Index: Experimental/freetype/freetype-package.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Experimental/freetype/freetype-package.lisp,v retrieving revision 1.2 diff -c -r1.2 freetype-package.lisp *** Experimental/freetype/freetype-package.lisp 5 Jun 2005 20:50:29 -0000 1.2 --- Experimental/freetype/freetype-package.lisp 14 Mar 2006 00:18:37 -0000 *************** *** 1,6 **** (defpackage :mcclim-freetype (:use :climi :clim :clim-lisp) (:export :*freetype-font-path*) ! (:import-from #+cmucl :alien #+sbcl :sb-alien :slot :make-alien :alien :deref)) --- 1,6 ---- (defpackage :mcclim-freetype (:use :climi :clim :clim-lisp) (:export :*freetype-font-path*) ! (:import-from #+(or cmu scl) :alien #+sbcl :sb-alien :slot :make-alien :alien :deref))

1 0

[mcclim-devel] Patch: Define x-lisp-fasl extensions for CMUCL and SCL.
by Douglas Crosher 14 Mar '06

14 Mar '06

* Apps/Listener/file-types.lisp: Define x-lisp-fasl extensions for CMUCL and SCL. Regards Douglas Crosher Index: Apps/Listener/file-types.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Apps/Listener/file-types.lisp,v retrieving revision 1.8 diff -c -r1.8 file-types.lisp *** Apps/Listener/file-types.lisp 31 Aug 2005 05:50:37 -0000 1.8 --- Apps/Listener/file-types.lisp 14 Mar 2006 00:00:21 -0000 *************** *** 181,187 **** (:icon (standard-icon "design.xpm"))) (define-mime-type (application x-lisp-fasl) ! (:extensions "x86f" "fasl" "ibin" "dfsl" "ufsl") ; MORE! (:icon (standard-icon "object.xpm"))) (define-mime-type (text x-shellscript) --- 181,188 ---- (:icon (standard-icon "design.xpm"))) (define-mime-type (application x-lisp-fasl) ! (:extensions "x86f" "amd64f" "sparcf" "sparc64f" "hpf" "hp64f" "lbytef" ! "fasl" "ibin" "dfsl" "ufsl") ; MORE! (:icon (standard-icon "object.xpm"))) (define-mime-type (text x-shellscript)

1 0

[mcclim-devel] Patch: add 'stream-clear-input methods.
by Douglas Crosher 14 Mar '06

14 Mar '06

* stream-input.lisp: add 'stream-clear-input methods for 'standard-input-stream, and 'standard-extended-input-stream. Regards Douglas Crosher Index: stream-input.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/stream-input.lisp,v retrieving revision 1.44 diff -c -r1.44 stream-input.lisp *** stream-input.lisp 10 Mar 2006 21:58:13 -0000 1.44 --- stream-input.lisp 14 Mar 2006 00:00:20 -0000 *************** *** 117,122 **** --- 117,131 ---- else do (handle-event (event-sheet event) event)))) + (defmethod stream-clear-input ((pane standard-input-stream)) + (setf (stream-unread-chars pane) nil) + (loop for event = (event-read-no-hang pane) + if (null event) + return nil + else + do (handle-event (event-sheet event) event)) + nil) + ;;; XXX The should be moved to protocol-classes.lisp and the ;;; standard-sheet-input-mixin superclass should be removed. (define-protocol-class extended-input-stream (fundamental-character-input-stream ;Gray stream *************** *** 384,389 **** --- 393,410 ---- do (stream-read-gesture estream) ; consume pointer gesture finally (return (characterp char))))) + (defmethod stream-clear-input ((stream standard-extended-input-stream)) + (with-encapsulating-stream (estream stream) + (loop + with char and reason + do (setf (values char reason) (stream-read-gesture estream + :timeout 0 + :peek-p t)) + until (or (eq reason :eof) (eq reason :timeout)) + do (stream-read-gesture estream) ; consume pointer gesture + )) + nil) + ;;; stream-read-line returns a second value of t if terminated by eof. (defmethod stream-read-line ((stream standard-extended-input-stream)) (with-encapsulating-stream (estream stream)

1 0

[mcclim-devel] Patch: Printing port objects with a 'nil display.
by Douglas Crosher 14 Mar '06

14 Mar '06

* Backends/CLX/port.lisp, print-object (clx-port): handle the 'display slot being 'nil. Regards Douglas Crosher Index: Backends/CLX/port.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Backends/CLX/port.lisp,v retrieving revision 1.120 diff -c -r1.120 port.lisp *** Backends/CLX/port.lisp 6 Feb 2006 08:51:02 -0000 1.120 --- Backends/CLX/port.lisp 14 Mar 2006 00:18:37 -0000 *************** *** 210,218 **** (defmethod print-object ((object clx-port) stream) (print-unreadable-object (object stream :identity t :type t) (when (slot-boundp object 'display) ! (format stream "~S ~S ~S ~S" ! :host (xlib:display-host (slot-value object 'display)) ! :display-id (xlib:display-display (slot-value object 'display)))))) (defun clx-error-handler (display error-name &rest args &key major &allow-other-keys) (unless (and (eql major 42) ; 42 is SetInputFocus, we ignore match-errors from that --- 210,220 ---- (defmethod print-object ((object clx-port) stream) (print-unreadable-object (object stream :identity t :type t) (when (slot-boundp object 'display) ! (let ((display (slot-value object 'display))) ! (when display ! (format stream "~S ~S ~S ~S" ! :host (xlib:display-host display) ! :display-id (xlib:display-display display))))))) (defun clx-error-handler (display error-name &rest args &key major &allow-other-keys) (unless (and (eql major 42) ; 42 is SetInputFocus, we ignore match-errors from that

1 0

[mcclim-devel] Scigraph's DWIM layer
by Clemens Fruhwirth 13 Mar '06

13 Mar '06

I'm interested in using Scigraph for generating histograms, but atm scigraph isn't in a good shape. The compatiblity layer for DWIM generates about 5-8 compile warnings (depends whether one is compiling to a fresh image or an image already containing dwim). I would like to ask what's the future of the compatiblity layer. We have a lot read-time conditionals for genera or clim 0.9/1 in the dwim files. I'm pondering to remove these conditionals, as mcclim isn't clim-0.9 nor clim-1. Also there are some hacks for non-ansi CL environments. I'm temped to remove them too as I would have to wrap those things in #-ansi-cl. But that's not really useful anyway, as mcclim is ansi-cl. So what about that: DWIM as contained in the mcclim repository is a compatiblity layer for running dynamic window code on mcclim (and only on mcclim) in an ANSI CL environment. With a definition as above I could kick out ~25% of the DWIM code. Opinions? -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap(a)endorphin.org

2 1

[mcclim-devel] [CfP] 3rd European Lisp Workshop
by Christophe Rhodes 13 Mar '06

13 Mar '06

[ Apologies for the circular; no doubt most people have already seen this -- though note that this Call for Papers contains important information about a financial incentive! With nothing to do for now but test and fix bugs, there should be loads of spare energy for writing papers... ] +----------------------------------------------------------------------+ | 3rd European Lisp Workshop | | July 3 & 4 - Nantes, Frances - co-located with ECOOP 2006 | | Supported by ALU and Ravenbrook Limited | +----------------------------------------------------------------------+ Important News * Nick Levine will be giving a keynote presentation at the workshop. He has been a professional Lisp consultant for over two decades and is the organizer of the upcoming International Lisp Conference in Cambridge, UK. We are grateful to Ravenbrook Limited for sponsoring the keynote presentation. * The Association of Lisp Users has kindly sponsored a $500 prize fund for exceptional papers submitted to this year's workshop. Both the ALU and the workshop organizers are looking forward to your submissions. Important Dates Submission deadline (papers & breakout groups): April 1, 2006 Notification of acceptance: May 1, 2006 ECOOP early registration deadline: May 23, 2006 For more information visit http://lisp-ecoop06.bknr.net/ Contact: Pascal Costanza, pc(a)p-cos.net Organizers ********** Pascal Costanza, Programming Technology Lab, Vrije Universiteit Brussel Theo D'Hondt, Programming Technology Lab, Vrije Universiteit Brussel Arthur Lemmens, Independent Consultant, Amsterdam Christophe Rhodes, Goldsmiths College, University of London Overview ******** "...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." -- Kent Pitman Lisp is one of the oldest computer languages still in use today. In the decades of its existence, Lisp has been a fruitful basis for language design experiments as well as the preferred implementation language for applications in diverse fields. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Common Lisp, with the Common Lisp Object System (CLOS), was the first object-oriented programming language to receive an ANSI standard and retains the most complete and advanced object system of any programming language, while influencing many other object-oriented programming languages that followed. It is clear that Lisp is gaining momentum: there is a steadily growing interest in Lisp itself, with numerous user groups in existence worldwide, and in Lisp's metaprogramming notions which are being transferred to other languages, as for example in Aspect-Oriented Programming, support for Domain-Specific Languages, and so on. This two-day workshop will address the near-future role of Lisp-based languages in research, industry and education. We solicit papers and suggestions for breakout groups that discuss the opportunities Lisp provides to capture and enhance the possibilities in software engineering. We want to promote lively discussion between researchers proposing new approaches and practitioners reporting on their experience with the strengths and limitations of current Lisp technologies. The workshop will have two components on separate days; there will be a day for formally-presented talks, and a day for breakout groups discussing or working on particular topics. Additionally, there will be opportunities for short, informal talks and demonstrations on experience reports, underappreciated results, software under development, or other topics of interest. Papers ****** Formal presentations in the workshop should take between 20 minutes and half an hour; additional time will be given for questions and answers. We encourage that papers be published on the website in order to provide background information in advance. Suggested Topics New language features or abstractions Experience reports or case studies Protocol Metaprogramming and Libraries Educational approaches Software Evolution Development Aids Persistent Systems Dynamic Optimization Implementation techniques Innovative Applications Hardware Support for Lisp systems Macro-, reflective-, meta- and/or rule-based development approaches Aspect-Oriented, Domain-Oriented and Generative Programming Breakout Groups *************** The workshop will provide for the opportunity to meet face to face and work on focused topics. We will organize these breakout groups and provide for rooms and infrastructure. Suggested Topics for Breakout Groups Lisp Infrastructure Development and Distribution Language Features (e.g. Predicate Dispatching) Environments for creating web applications Brainstorming sessions for new or existing open source projects Persistence Systems Compiler technology Lisp on bare metal / Lisp hardware / Lisp operating systems Compare and enhance curricula for computer science education Submission Guidelines ********************* Potential attendees are encouraged to submit * a long paper (10 pages) presenting scientific and/or empirical results about Lisp-based uses or new approaches for software engineering purposes; * a short essay (5 pages) defending a position about where research, practice or education based on Lisp should be heading in the near future; * a proposal for a breakout group (1-2 pages) describing the theme, an agenda and/or expected results. Submissions should be mailed as PDF to Pascal Costanza (pc(a)p-cos.net) before the submission deadline.

1 0

[mcclim-devel] Plans for McCLIM 0.9.2 "Laetare Sunday" release
by Andreas Fuchs 11 Mar '06

11 Mar '06

hi all, I (and a few others, hi Clemens and Christophe) would like to see a new McCLIM release. As Mothering Sunday is on the 26th of March, and we wanted to do time-slot releases anyway ((-;), I suggest we go for that date. Proposed schedule: * Heavy McCLIM hacking until 19th March. Then, freeze. * test test test, * Release McCLIM 0.9.2, "Laetare Sunday" on Sunday, 26th March (-: Is everybody happy with that? I'll take silence (until say, the 12th) as a "yes" (-: -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

4 3

[mcclim-devel] device font text styles
by Christophe Rhodes 08 Mar '06

08 Mar '06

Hi, I attach a patch for discussion and review, reworking the support for device fonts; in particular, one can do things like (with-text-style (s (make-device-font-text-style port (make-postscript-device-font-name :font-file "Dingbats.pfb" :metrics-file "Dingbats.afm" :size 14))) (write-line "Hello, World!" s)) We use this patch to draw lute tablature, using home-designed fonts for the tab glyphs, in both TrueType and Postscript formats (TrueType for display, Postscript for printing). I don't know whether this patch breaks the ordinary CLX backend's support for device fonts; is anyone in a position to test this? I also suspect that there are bits and pieces of the postscript code which are not entirely right, though I can say that Examples/postscript-test.lisp seems to be about right. This bit of CLIM is almost completely unspecified; all that we know about MAKE-DEVICE-FONT-TEXT-STYLE is that it takes a port and a "font name" and returns some kind of TEXT-STYLE object. The reasoning I've applied in this implementation is that since device-font-text-styles are defined not to merge (in the MERGE-TEXT-STYLE sense) with any other text style, a device-font-text-style-name needs to have all the information required to identify uniquely a font that we can use in the backend. Under X, calling this a "name" makes a certain amount of sense, because X fonts are in fact uniquely identified by their X name: something like "-adobe-courier-medium-r-normal-and-so-on-". I don't think this is true for any other backend :-) so I think it's reasonable to define names as structures, rather than attempting to parse some ad-hoc string representation. I also don't want to present this patch as a final interface; it is fairly ugly to have to specify the port type when making a name. Ultimately, we may want to move back to string names: something like (define-font "Varietie3" :freetype (:font-file "fonts/Varietie3.ttf" :size 14) :postscript (:font-file "fonts/Varietie3.pfa" :metrics-file "fonts/Varietie3.afm" :size 12)) but I certainly think that designing something like that is out of scope in the next three weeks... Anyway, with all that, the patch (which is by far the majority of my diff with HEAD) attached. Cheers, Christophe

1 0

[mcclim-devel] standard-tree-output-records using spatial-trees
by Andreas Fuchs 08 Mar '06

08 Mar '06

Hi all, As this is the first weekend of my holidays, I hacked on mcclim a little. So, I implemented standard-tree-output-records as per Tim Moore's suggestion, using R-trees from Christophe's excellent spatial-trees library. This one didn't take as long as I expected: about 4 hours. Props to Xof (-: I tested the change against beirc, which seems to be working. No performance measurements yet. I'll just sit on #lisp and wait for the scrollback buffer to grow (-: Here's the patch: Comments and testers (both for correctness and for performance improvements/degradation) welcome! Have fun, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

2 4

Re: [mcclim-devel] Infinite loop in McCLIM
by pw＠snoopy.mv.com 07 Mar '06

07 Mar '06

> "Paul Werkowski" <pw(a)snoopy.mv.com> writes: > > > The attached program works the same in McCLIM and Lispworks CLIM, > > except McCLIM gets into an infinite loop (CMUCL latest) unless > > incremental-redisplay > > is enabled. > > [ Belatedly ] Um, I didn't see an attachment to your original > mail... did you forget to attach it? Is this still a problem? > > Cheers, > > Christophe > > I think that problem went away - probably some cockpit trouble in my environment. Paul

1 0