June 2005 - mcclim-devel - mailman3.common-lisp.net

[mcclim-devel] [patch] bug in map-over-command-table-keystrokes?
by Daniel Barlow 15 Jun '05

15 Jun '05

I noticed this while trying to persuade climacs to give me a list of keybindings: (map-over-command-table-keystrokes (lambda (name key item) (format t "~A ~A ~A~%" name key item)) 'CLIMACS-GUI::GLOBAL-CLIMACS-TABLE) => debugger invoked on a UNBOUND-SLOT in thread 11974: The slot CLIM-INTERNALS::MENU-NAME is unbound in the object #<MENU-ITEM keystroke (- META) {9794829}>. According to the specification 27.4, "function must be a function of three arguments, the menu name (which will be nil if there is none), the keystroke accelerator, and the command menu item". I don't know if the fix below is the Right Thing, but it does the trick for me. Index: commands.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/commands.lisp,v retrieving revision 1.51 diff -u -r1.51 commands.lisp --- commands.lisp 24 Jan 2005 09:36:00 -0000 1.51 +++ commands.lisp 15 Jun 2005 17:57:40 -0000 @@ -474,7 +474,8 @@ (loop for gesture in keystroke-accelerators for item in keystroke-items do (funcall function - (command-menu-item-name item) + (and (slot-boundp item 'menu-name) + (command-menu-item-name item)) gesture item))))) -- Daniel Barlow // daniel.barlow(a)uk.clara.net // ext 3233 world domination and a whole lot of money to spend

1 0

Fwd: [mcclim-devel] Re: Beagle backend requirements?
by Duncan Rose 10 Jun '05

10 Jun '05

Begin forwarded message: > From: Duncan Rose <duncan(a)robotcat.demon.co.uk> > Date: Fri Jun 10, 2005 12:16:53 am Europe/London > To: mcclim-devel(a)common-lisp.net > Cc: Brian Mastenbrook <chandler(a)unmutual.info>, Rainer Joswig > <joswig(a)lisp.de> > Subject: Re: [mcclim-devel] Re: Beagle backend requirements? > > > Further to this, I can report no problems observed on 10.2 running > with OpenMCL 0.14.3 (from the 'distributions' link on Clozure.com, not > bleeding edge from CVS or whatever) so I suspect this may be a problem > that's specific to Tiger. > > Sorry not to be more helpful, but I don't have access to a box running > 10.4 :-( > > -Duncan > > > On Monday, June 6, 2005, at 12:06 am, Duncan Rose wrote: > >> >> Oops, didn't notice this was posted to the list as well... this is >> how I responded to Brian's chandler address: >> >> On Thursday, June 2, 2005, at 01:45 am, Brian Mastenbrook wrote: >> >>> Hi Duncan, >>> >>> What version of OpenMCL is required for running the Beagle backend? >>> Right now current CVS won't run on 0.14.3 with an error about ObjC >>> ARRAY. >>> >>> Should I get bleeding edge or current 0.14 CVS? >>> >> >> I'm currently using the outdated 0.14.1-p1 version, on 10.2 >> >> I've heard from Rainer Joswig that Beagle doesn't compile under the >> latest OpenMCL (but no more than that it fails 'with a type error'; >> presumably the same thing you're seeing); there's still quite a lot >> of discussion on the OpenMCL list regarding problems with the ObjC >> bridge under the latest OpenMCL versions (and I'm pretty sure Jaguar >> is not intended to be supported any longer by later OpenMCL versions) >> so I haven't done an upgrade (I'm seriously considering forking out >> for a new iBook though, at which point I will be upgrading ;-). >> >> Could you send me the actual error report? At the moment I'm guessing >> from your description that the problem is likely to be in >> %COCOA-IMAGE-FROM-PATTERN in OUTPUT;MEDIUM.LISP however I don't >> believe any ObjC arrays are used directly by the code (I'm classing C >> arrays (char * etc) and ObjC (NSArray) arrays differently, although >> perhaps I shouldn't in the context of this issue). >> >> -Duncan >> >>> Thanks! >>> >>> >>> -- >>> Brian Mastenbrook >>> http://www.iscblog.info/ >>> http://www.cs.indiana.edu/~bmastenb/ >>> >> >> _______________________________________________ >> mcclim-devel mailing list >> mcclim-devel(a)common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel >> >

1 0

[mcclim-devel] May/June 2005 messages missing from mcclim-devel archive
by Paolo Amoroso 10 Jun '05

10 Jun '05

It looks like the archive of the mcclim-devel mailing list: http://common-lisp.net/pipermail/mcclim-devel/ is missing all May 2005 messages and part of the June ones. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

3 2

[mcclim-devel] Beagle backend requirements?
by Brian Mastenbrook 09 Jun '05

09 Jun '05

Hi Duncan, What version of OpenMCL is required for running the Beagle backend? Right now current CVS won't run on 0.14.3 with an error about ObjC ARRAY. Should I get bleeding edge or current 0.14 CVS? Thanks! -- Brian Mastenbrook http://www.iscblog.info/ http://www.cs.indiana.edu/~bmastenb/

2 2

[mcclim-devel] Freetype for SBCL
by Brian Mastenbrook 09 Jun '05

09 Jun '05

Hello, Since I'm under the impression that code in the Experimental directory is, well, experimental, I've committed a version of the experimental freetype bindings which works on SBCL. I've optimized away the %SAP-ALIEN problems, and the end product is reasonably usable. It's a bit laggy until the glyph cache warms up, but after that it's just fine. Here's a gratuitous screenshot: http://www.unmutual.info/images/slidemacs-big.png I'm pretty sure that this doesn't work on CMUCL anymore, as CMUCL has slightly different names (DEF-ALIEN-TYPE and -ROUTINE), but a little macrology should restore CMUCL workingness if anybody's interested in giving it a try. In order to use this under SBCL, you must use the .asd file, as there's a little ASDF muckery in there to work around the fact that compiling the freetype-ffi file currently stuffs up in SBCL. After the rest of the code finishes compiling, you should see a message about setting mcclim-freetype:*freetype-font-path* - set this to a directory containing the Bitstream Vera fonts, and don't forget the final / on the pathname or else merge-pathnames is not going to be happy. Comments and patches welcome, especially from CMUCL users. -- Brian Mastenbrook "God made the natural numbers; http://www.iscblog.info/ all else is the work of man." chandler(a)unmutual.info -- Leopold Kroneker

3 2

[mcclim-devel] First native pane type in Beagle
by Duncan Rose 05 Jun '05

05 Jun '05

For anybody interested I've put a couple of screen shots of the Listener with a first-pass at native scroll bars up on my webspace: http://www.robotcat.demon.co.uk/ I realize there are few people able to run Beagle at the moment unfortunately :-( As an aside, if anybody can give me a couple of pointers as to how exactly the 'scroller-pane' decides whether to lay the vertical scroll bar out on the left side or the right side I'd be grateful. I can't see anything that obviously controls this. On a final note, does McCLIM take any notice of key event object's :key-name as opposed to :key-character? Is there a way to set up a command (for Goatee, say) that makes :LEFT behave the same as ctrl-b? Thanks, -Duncan

1 0

[mcclim-devel] New fixes for package lock errors in listener compilation/load with CMUCL 19
by Paolo Amoroso 05 Jun '05

05 Jun '05

The fix I suggested for this resolved CLIM Listener bug: Package lock errors when compiling/loading with CMUCL 19 or later http://mcclim.cliki.net/Bug#listener-cmucl-package-lock was shortsighted. I conditionalized package locking on feature cmu19a: #+cmu19a (progn (setf (ext:package-definition-lock (find-package "DEBUG")) nil) (setf (ext:package-definition-lock (find-package "COMMON-LISP")) nil) (setf (ext:package-definition-lock (find-package "EXT")) nil)) But compilation and loading of the Listener fail again with CMUCL Snapshot (19B) 2005-06, which is the first in the 19b series. A short term fix may be to conditionalize on just cmu19. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

1 1

[mcclim-devel] ASDF building problems on CMUCL
by Christian Lynbech 05 Jun '05

05 Jun '05

It seems as if there are some problems with ASDF module specification for scigraph in current versions of McCLIM CVS. When I try to build as per the instructions (using cmucl), the build stalls after loading the module specs and it does not matter whether I load system.lisp or mcclim.asd. A stacktrace is show below. Outcommenting the definition of the scigraph system removes the problem and McCLIM builds and runs without problems. It would thus appear that the scigraph system triggers an infinite loop somewhere in ASDF. The problem appears with todays CVS and the version labelled as McCLIM-0-9-1; it appears that the version McCLIM-0-9 only works with mkdefsystem enabled lisps. I am running on a Debian system with the following versions: ii common-lisp-controller 4.14 ii cmucl 19a-release-20040728-11 ii cl-asdf 1.86-4 0] backtrace 0: (ASDF::PARSE-COMPONENT-FORM NIL (:MODULE "scigraph" :PATHNAME #p"/net/daphne/usr/local/home/tedchly/Tools/ANON-CVS/mcclim/" :DEPENDS-ON ...)) 1: (ASDF::PARSE-COMPONENT-FORM 2 NIL (:MODULE "scigraph" :PATHNAME #p"/net/daphne/usr/local/home/tedchly/Tools/ANON-CVS/mcclim/" :DEPENDS-ON ...))[:EXTERNAL] 2: (LISP::SLOLOAD #<Stream for file "/net/daphne/usr/local/home/tedchly/Tools/ANON-CVS/mcclim/mcclim.asd">) 3: (LISP::INTERNAL-LOAD #p"mcclim.asd" #p"/net/daphne/usr/local/home/tedchly/Tools/ANON-CVS/mcclim/mcclim.asd" :ERROR :SOURCE) 4: (LISP::INTERNAL-LOAD #p"mcclim.asd" #p"/net/daphne/usr/local/home/tedchly/Tools/ANON-CVS/mcclim/mcclim.asd" :ERROR NIL) 5: (LOAD "mcclim.asd" :VERBOSE NIL :PRINT ...) 6: (EXTENSIONS:INTERACTIVE-EVAL (LOAD "mcclim.asd")) 7: (LISP::%TOP-LEVEL) 8: ((LABELS LISP::RESTART-LISP EXTENSIONS:SAVE-LISP)) ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic(a)hal.com (Michael A. Petonic)

5 5

[mcclim-devel] cvs access
by idurand＠labri.fr 05 Jun '05

05 Jun '05

Trying to get a cvs version of mcclim I get Ordinateur-de-IRENE-DURAND:~ idurand$ cvs -z3 -d :pserver:anonymous:anonymous@common-lisp.net:/project/mcclim/cvsroot co mcclim ? mcclim/cvsroot ? mcclim/Backends/CLX/clim-extensions.dfsl ? mcclim/Backends/CLX/frame-manager.dfsl ? mcclim/Backends/CLX/graft.dfsl ? mcclim/Backends/CLX/image.dfsl ? mcclim/Backends/CLX/keysymdef.dfsl ? mcclim/Backends/CLX/keysyms-common.dfsl ? mcclim/Backends/CLX/keysyms.dfsl ? mcclim/Backends/CLX/medium.dfsl ? mcclim/Backends/CLX/package.dfsl ? mcclim/Backends/CLX/port.dfsl ? mcclim/examples/franz ? mcclim/looks/pixie.dfsl cvs server: existing repository /project/mcclim/cvsroot/McCLIM does not match /project/mcclim/cvsroot/mcclim cvs server: ignoring module mcclim What am I doing wrong? Irene ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

1 2

[mcclim-devel] Re: Bug#310640: cl-asdf: cl-mcclim package made unusable by the latest asdf package
by Peter Van Eynde 04 Jun '05

04 Jun '05

Milan Zamazal wrote: > It seems the bug is still present in cl-asdf 1.86-5: ... It seems the problem is McClim (!) > debugger invoked on a DUPLICATE-NAMES in thread 31186: > Condition DUPLICATE-NAMES was signalled. ... > (:MODULE "scigraph" If you reproduce the problem and do: 0] (loop for (a name c d) in (nth 9 (SB-DEBUG:ARG 1)) do (format t "~&~A~%" name)) package <- NAME package feature-case macros tv draw present extensions wholine export package <- NAME package AGAIN! copy dump duplicate random menu-tools basic-classes draw mouse color basic-graph graph-mixins axis moving-object symbol graph-data legend graph-classes present annotations annotated-graph contour equation popup-accept popup-accept-methods duplicate-methods frame export demo-frame So the problem is with McCLIM, or better with the defsystem macro in McCLIM that defines system with duplicate names: 0] (in-package :mcclim.system) #<PACKAGE "MCCLIM.SYSTEM"> 0] (cl:macroexpand '(clim-defsystem (:scigraph :depends-on (:clim :clim-looks)) ;; The DWIM part of SCIGRAPH "Apps/Scigraph/dwim/package" "Apps/Scigraph/scigraph/package" )) (PROGN (DEFSYSTEM :SCIGRAPH :DEPENDS-ON (:CLIM :CLIM-LOOKS) :SERIAL T :COMPONENTS ((:FILE "package" :PATHNAME #P"/home/pvaneynd/fakeroot/McCLIM/Apps/Scigraph/dwim/package.lisp") (:FILE "package" :PATHNAME #P"/home/pvaneynd/fakeroot/McCLIM/Apps/Scigraph/scigraph/package.lisp")))) T As asdf refers internally to subsystems only by name this is "a bad thing" (TM). Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|

1 0