mcclim-devel

mcclim-devel@common-lisp.net

820 discussions

[mcclim-devel] Presentation Translator Utilities
by daniel＠bigwalter.net 14 May '07

14 May '07

I began writing the functions in 27.5 "Presentation Translator Utilities", since they are missing in McCLIM, but I'm having trouble reading the spec. The spec does not go into detail on how translators are implemented. The description for define-presentation-translator mentions that they have names and are stored in command tables. The McCLIM implementation is a reasonable interpretation of this. The problem lies with add-presentation-translator-to-command-table. Here it is very clear that the name is used outside command tables too: add-presentation-translator-to-command-table command-table translator-name &key (errorp t) [Function] Adds the translator named by translator-name to command-table. The translator must have been previously defined with define-presentation-translator or define-presentation-to-command-translator. It is not possible to write this function without changing more stuff. I guess it calls for a global translator table (i.e., a hash table.) What do you think? I don't really get it. I would much rather like to change the definition of add-presentation-translator-to-command-table. It makes more sense to me to do it like this: add-presentation-translator-to-command-table command-table translator &key (errorp t) [Function] Adds a presentation translator to command-table. The translator must have been previously defined with define-presentation-translator or define-presentation-to-command-translator. This removes the only usage of the global name. It is more consistent with the other translator functions. I attach a file with the functions from 27.5. See if you like it. It might be an idea to refactor them together with the rest of the translator code, because I copied a lot from there.

1 0

[mcclim-devel] clim-debugger update; keyboard navigation and an .asd file
by Jeremy Rayman 11 May '07

11 May '07

Hi there, Peter Mechlenborg has a copy of clim-debugger.lisp on his webspace with mostly-working keyboard navigation. He was the original author of the clim-debugger. I cleaned up the rough edges, added some other keyboard shortcuts, and made an .asd file for it. The patches against today's CVS are here: http://jlr.freeshell.org/data/mcclim/patches/clim-debugger.asd.patch http://jlr.freeshell.org/data/mcclim/patches/clim-debugger-keyboard-navigat… You can also find the full .asd and clim-debugger.lisp in that dir, in case the patches don't work for you. clim-debugger.asd.patch: * Add an ASDF system for the clim-debugger. clim-debugger-keyboard-navigation.patch: * Keyboard navigation: - Arrow keys move up and down stack frames, space expands current frame - Enter key inspects current object - Select restart by number (0-10) - Shortcuts: #\a abort, #\q quit, #\c continue Thanks so much for McCLIM. - Jeremy Rayman jeremy.rayman @ gmail.com p.s. Peter's original copy is at http://www.daimi.au.dk/~metch/lisp/clim-debugger.lisp .

1 0

[mcclim-devel] com-beginning-of-buffer keybinding
by Thomas Persson 08 May '07

08 May '07

Hi When playing around a bit with climacs I noticed that com-beginning-of-buffer in Drei is bound to: (#\< :shift :meta) which at least on my keyboard is physically impossible to type.

2 1

[mcclim-devel] McCLIM on the Mac
by Christian Lynbech 07 May '07

07 May '07

I could use some pointers on the status of McCLIM on the Mac. In particular, I am interested in how to run against the native graphics system rather than having to run the X11 server. I have looked a bit on the beagle backend but I cannot get it to work. A few fixes is needed just to get it to compile. Once that is done, it does compile and load but once an application (such as the calculator demo) is started, the lisp process freezes with output to the effect of: ? 2007-04-22 20:07:30.708 dppccl[2492] *** Assertion failure in -[NSWindowGraphicsContext reenableDisplayPosting], GraphicsContext.subproj/NSWindowGraphicsContext.m:117 2007-04-22 20:07:30.708 dppccl[2492] *** Assertion failure in -[NSViewHierarchyLock unlockTopMostReader], AppKit.subproj/NSViewHierarchyLock.m:444 2007-04-22 20:07:30.710 dppccl[2492] Error in event loop: Objective-C runtime exception: Invalid parameter not satisfying: th suggesting something going wrong deep down below the lisp level. This was with the latest mcclim CVS, OpenMCL 1.0 and PPC OSX 10.4.9. Before diving in I would like to know if the beagle backend is considered dead beyond repair (or at least if others than myself has any interest in it). Are there alternatives, can the gtkairo or opengl backends be brought to fly without X11? ------------------------+----------------------------------------------------- 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)

4 8

[mcclim-devel] Test suites and code coverage
by Christophe Rhodes 07 May '07

07 May '07

Hi, Some people may know that Juho Snellman committed a nice new tool to SBCL recently: a tool to measure code coverage[1]. For laughs, I thought I'd try it out on McCLIM and its test suite... To do so, I first loaded clx, spatial-trees and flexichain. Then (require :sb-cover) (declaim (optimize sb-cover:store-coverage-data)) (asdf:oos 'asdf:load-op :mcclim) (sb-cover:reset-coverage) ; debatable. See below. (defpackage :clim-tests (:use :clim :clim-lisp)) (mapcar #'load (directory "/path/to/mcclim/Tests/*.lisp")) The results I got are available at <http://doc.gold.ac.uk/~mas01cr/tmp/mcclim-tests/>. So, firstly, this is clearly not automated enough; I plan to spend a little time making running tests easier. The point about clearing coverage before running the tests is to remove all the uses of internal code (such as macros) in the building of mcclim itself. I don't know whether that's fair or not, but in doing so I noticed that there are some load-time tests (in e.g. bezier.lisp) which might be better placed in a test suite. I also am aware that I didn't run Drei or automaton test suites in the process of doing this; running those should be a simple matter. What does this show? Well, even though it's difficult to test a UI library in an automated fashion, I'm pretty sure that there are large swathes of things that /are/ testable in an automated fashion that aren't being so tested -- and that maybe by making these statistics available people could find bits that interest them and write tests to exercise those bits. There's also the obvious possibility of collecting the coverage statistics while running demodemo -- which will exercise backend functions and some of the UI code, and show us where some gaps are. (There's also my long-standing idea of using the Null backend to test UI in an automated fashion, but I'm sure more work needs to be done to make that possible.) Anyway. Comments, ideas? Cheers, Christophe [1] Weblog entry at <http://jsnell.iki.fi/blog/archive/2007-05-03-code-coverage-tool-for-sbcl.ht…>; some details at <http://www.sbcl.org/manual/sb_002dcover.html>.

2 2

[mcclim-devel] C syntax patch
by John Q. Splittist 27 Apr '07

27 Apr '07

Folks, A patch implementing the beginnings of a C syntax for McClim/climacs can be found at http://common-lisp.net/~dmurray/mcclim-c.tar.gz . It is quite ugly at the moment, but I thought it best to make it available now than watch it rot. The file contains a diff and 3 additional files: c-syntax.lisp, c-syntax-commands.lisp and lr-syntax.lisp. This last contains code that is now common to the C and Lisp syntaxes. Have fun! JQS

1 0

[mcclim-devel] clim-demo::demodemo fails with some kind of font problem
by Larry Clapp 06 Apr '07

06 Apr '07

Hello, McClimmers, I run Debian GNU/Linux, mostly "stable", some "testing". I'm using SBCL. I followed the instructions here (http://mcclim.cliki.net/GettingStarted) and got clean compiles on everything. (Well, I never got the debugger, at least, so I assume they were clean. :) The clim demo fails with some kind of font problem: > * (clim-demo::run-test 'clim-demo::demodemo) > Received CLX NAME-ERROR in process "#<CLIM-CLX::CLX-PORT :HOST \"localhost\" :DISPLAY-ID 0 > {C8B6749}>'s event process." > > debugger invoked on a XLIB:NAME-ERROR in thread #<THREAD "#<CLIM-CLX::CLX-PORT :HOST \"loc > alhost\" :DISPLAY-ID 0 {C8B6749}>'s event process." {BAE9961}>: > Asynchronous NAME-ERROR in request 36 (last request was 37) Code 45.0 [OpenFont] > Received CLX FONT-ERROR in process "initial process" > > debugger invoked on a XLIB:FONT-ERROR in thread #<THREAD "initial thread" {A7BD4A1}>: > FONT-ERROR in current request Code 47.0 [QueryFont] ID #x5E00019 > > Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. > > restarts (invokable by number or by possibly-abbreviated name): > 0: [ABORT] Exit debugger, returning to top level. > > (XLIB::X-ERROR XLIB:FONT-ERROR > :DISPLAY #<XLIB:DISPLAY localhost:0 (The X.Org Foundation R70101000)> > :ERROR-KEY XLIB:FONT-ERROR > :ASYNCHRONOUS NIL > :CURRENT-SEQUENCE 37 > :RESOURCE-ID 98566169 > :MAJOR 47 > :MINOR 0 > :SEQUENCE 37) > 0] 0 I *think* this is the relevant part of the backtrace: > 3: (XLIB::REPORT-ERROR > #<XLIB:DISPLAY localhost:0 (The X.Org Foundation R70101000)> > 7 > XLIB:FONT-ERROR > :ASYNCHRONOUS NIL > :CURRENT-SEQUENCE 400 > :RESOURCE-ID 98566169 > :MAJOR 47 > :MINOR 0 > :SEQUENCE 400) > 4: (XLIB::READ-REPLY #<unavailable argument> #<unavailable argument>) > 5: (XLIB::QUERY-FONT > #<XLIB:FONT -adobe-helvetica-medium-r-normal--24-173-100-100-p-0-iso8859-1 localhost:0 98566169>) > 6: (XLIB:OPEN-FONT > #<XLIB:DISPLAY localhost:0 (The X.Org Foundation R70101000)> > "-adobe-helvetica-medium-r-normal--24-173-100-100-p-0-iso8859-1") > 7: ((SB-PCL::FAST-METHOD CLIM:TEXT-STYLE-MAPPING (CLIM-CLX::CLX-PORT T)) > #<unavailable argument> > #<unavailable argument> > #<CLIM-CLX::CLX-PORT :HOST "localhost" :DISPLAY-ID 0 {C8B6749}> > #<CLIM:STANDARD-TEXT-STYLE :SANS-SERIF :ROMAN :HUGE> > NIL) > 8: (CLIM-CLX::TEXT-STYLE-TO-X-FONT > #<CLIM-CLX::CLX-PORT :HOST "localhost" :DISPLAY-ID 0 {C8B6749}> > #<CLIM:STANDARD-TEXT-STYLE :SANS-SERIF :ROMAN :HUGE>) So I guess #<CLIM:STANDARD-TEXT-STYLE :SANS-SERIF :ROMAN :HUGE> gets transformed into -adobe-helvetica-medium-r-normal--24-173-100-100-p-0-iso8859-1 but I don't actually have that font on my system: % xlsfonts | grep -e -adobe-helvetica-medium-r-normal--24-173-100-100-p-0-iso8859-1 % Any advice? (Hopefully other than "install -adobe-helvetica-medium-r-normal--24-173-100-100-p-0-iso8859-1". :) Thanks! -- Larry Clapp

5 5

[mcclim-devel] delivery failed
by Returned mail 25 Mar '07

25 Mar '07

Your message was not delivered due to the following reason(s): Your message could not be delivered because the destination computer was unreachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 5 days: Host 114.2.70.165 is not responding. The following recipients could not receive this message: <mcclim-devel(a)common-lisp.net> Please reply to postmaster(a)common-lisp.net if you feel this message to be in error.

1 0

[mcclim-devel] Re: cvs commit access to mcclim for junrue
by Jack Unrue 17 Mar '07

17 Mar '07

Andreas Fuchs wrote: > > Jack D. Unrue (junrue) is working on the clim-graphics-forms backend to > mcclim, so we think he should be able to commit to it. > > Project: mcclim, user name: junrue. Thanks Andreas, et. al. -- Jack Unrue

1 0

[mcclim-devel] Installing problem
by Tuomas Räsänen 15 Mar '07

15 Mar '07

I have succesfully installed mcclim and then I tried to install climacs with asdf. At first all went just ok but then the following debugger message appeared: ; compiling file "/home/tujojura/.sbcl/site/climacs/packages.lisp" (written 12 NOV 2006 11:07:59 PM): ; compiling (IN-PACKAGE :CL-USER) ; compiling (DEFPACKAGE :CLIMACS-GUI ...) debugger invoked on a SB-KERNEL:SIMPLE-PACKAGE-ERROR in thread #<THREAD "initial thread" {A7B9299}>: The name "DREI-BUFFER" does not designate any package. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Retry performing #<ASDF:COMPILE-OP NIL {B84A881}> on #<ASDF:CL-SOURCE-FILE "packages" {D010EF9}>. 1: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {B84A881}> on #<ASDF:CL-SOURCE-FILE "packages" {D010EF9}> as having been successful. 2: [ABORT ] Exit debugger, returning to top level. (SB-INT:%FIND-PACKAGE-OR-LOSE "DREI-BUFFER") 0] mcclims version is the latest asd-package and climacs is from cvs-repository. I have tried to re-install everything but that error keeps occuring. Any suggestions? Thanks, Tuomas

3 3

← Newer
1
...
28
29
30
31
32
33
34
...
82
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel