mcclim-devel

mcclim-devel@common-lisp.net

820 discussions

[mcclim-devel] McCLIM/CLX on MacOS X
by Christopher Johnson 18 Jun '06

18 Jun '06

Working through the hello-world example in "A guided tour of CLIM 2006", I get an error. I think I need to do more CLX setup for MacOS X, but I'm unsure how to proceed. The error is below. Any help would be appreciated. The value NIL is not of type NUMBER. [Condition of type TYPE-ERROR] Restarts: 0: [ABORT-REQUEST] Abort handling SLIME request. 1: [ABORT] Exit debugger, returning to top level. Backtrace: 0: (CLIM-CLX::PARSE-CLX-SERVER-PATH #<unavailable argument>) 1: (FIND-PORT :SERVER-PATH NIL) 2: (FIND-FRAME-MANAGER) 3: ((SB-PCL::FAST-METHOD RUN-FRAME-TOP-LEVEL :AROUND (APPLICATION-FRAME)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION (SB-PCL::FAST-METHOD RUN-FRAME-TOP-LEVEL #)> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<HELLO-WORLD {1387D819}> NIL) 4: (SB-INT:EVAL-IN-LEXENV (RUN-FRAME-TOP-LEVEL (MAKE-APPLICATION-FRAME (QUOTE HELLO-WORLD))) -- Chris Johnson Christopher.A.Johnson(a)gmail.com

4 3

[mcclim-devel] pointer-butt missing (mcclim 0.9.2)
by Eric Y. Kow 09 Jun '06

09 Jun '06

Dear McClim developers, While trying to install McClim on clisp/Mac OS X, I get two errors which might interest you. I send you this bug report upon #lisp/antifuchs' advice. Thanks! Summary ------- package gray is locked DEFMETHOD POINTER-BUTT: missing lambda list Context ------- I'm just a user, really. All I want to do is run the software KPML (http://www.purl.org/net/kpml) which claims to want a CLIM. Attached -------- my .clisprc the error log Platform -------- Mac OS X 10.4.6 (powerpc) clisp 2.38 asdf revision 1.98 spatial-trees 0.2 mcclim 0.9.2 My (darwinports) CLISP ---------------------- GNU CLISP 2.38 (2006-01-24) (built 3358753487) (memory 3358754081) Software: GNU C 4.0.0 20041026 (Apple Computer, Inc. build 4061) gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -DUNIX_BINARY_DISTRIB -DUNICODE -I. -L/opt/local/lib -L/opt/local/lib -x none -lintl -liconv -lc -Wl,-framework -Wl,CoreFoundation libcharset.a -lreadline -lncurses -liconv -L/opt/local/lib -lsigsegv -lc -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES STANDARD_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY libiconv 1.10 libreadline 5.0 Features: (REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN GETTEXT UNICODE BASE-CHAR=CHARACTER UNIX MACOS) C Modules: (clisp i18n syscalls regexp) Installation directory: /opt/local/lib/clisp/ User language: ENGLISH Machine: POWER MACINTOSH (POWER MACINTOSH) -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français.

2 1

[mcclim-devel] coordinate-epsilon defined twice
by Robert Strandh 07 Jun '06

07 Jun '06

Hello, In coordinates.lisp, the function coordinate-epsilon is first defined to return a value greater than 0, and then redefined to return 0 (and to be inlined). Having that function return 0 causes a lot of problem in my Bezier region code, and it is surely not what was intended. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------

1 0

[mcclim-devel] "bug" report: old style eval-when causes warnings in SBCL
by Robert Strandh 07 Jun '06

07 Jun '06

Hello, I have found two occurrences in McCLIM of old-style EVAL-WHEN: 1. In graphics.lisp, line 871 in a macro body, which means that everyone using that macro will get the warning message 2. In design.lisp, line 274 in a format control string, which I guess is less serious. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------

1 0

[mcclim-devel] freeze period for Trinity Sunday mcclim starts now.
by Andreas Fuchs 06 Jun '06

06 Jun '06

Hi, This mail marks the start of the freeze period for the Trinity Sunday release. Please test things (freetype-cffi comes to mind), and report any bugs that you find. As always, improvements to documentations and fixes for reported bugs are very welcome; I ask you to hold off other commits until after the release on next sunday. Let's make this as good as the last release (: -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

1 0

[mcclim-devel] reminder: freeze period starts tomorrow!
by Andreas Fuchs 06 Jun '06

06 Jun '06

Hi there, just thought it would be good to post a little reminder: if you want to get any patches in before the release next sunday, you should post your patch to this list. The freeze period starts tomorrow evening (CEST), so you have a bit more than 24 hours. Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

2 1

[mcclim-devel] execute-frame-command
by Christophe Rhodes 03 Jun '06

03 Jun '06

Hi, Is (defun foo () (let ((frame (make-application-frame 'climacs))) (clim-sys:make-process (lambda () (run-frame-top-level frame))) (execute-frame-command frame `(com-find-file "/tmp/foo.txt")))) expected to be "safe"? At present, this is subject to a race condition, because the frame need not have been adopted properly by the time the execute-frame-command runs, and so it need not have a top-level sheet. Would it be reasonable to guard against this in the branch of execute-frame-command, and if so, how? There's a symmetric case (which is probably less common) where the frame command is executed just after the top-level sheet is disowned. Any ideas? It would be nice to support something along the lines of my FOO function above -- it seems like a natural expression of a response to user action. Cheers, Christophe

2 1

[mcclim-devel] clipping regions, replay, handle-repaint
by Christophe Rhodes 28 May '06

28 May '06

Hi, I think that CLIM underspecifies how clipping regions (and text-styles and line-styles) are handled for output records. For REPLAY-OUTPUT-RECORD, it says "The current user transformation, line style, text style, ink, and clipping region of stream are all ignored during the replay operation. Instead, these are gotten from the output record." which is good, but unfortunately it doesn't specify /how/ they are gotten, which means that implementing one's own output record class is tricky. Why does this matter? In gsharp, we implement sloped beams with our own kind of output record; as of this morning, I taught that output record, and the replay-output-record methods, about the medium clipping region, so that sloped short beams (as in <http://www-jcsu.jesus.cam.ac.uk/~csr21/sloped-short-beams.png>) survive repainting; previously the output record had no record of the clipping region, and so a repaint would cause the entire width, rather than just the short segment, to be drawn. So this now works acceptably. However, we implement horizontal beams with an ordinary rectangle, and short ones with an ordinary rectangle and clipping region. Before a repaint, this works fine: see <http://www-jcsu.jesus.cam.ac.uk/~csr21/horizontal-beams.png>. However, obscuring and uncovering the window, triggering a repaint, results in <http://www-jcsu.jesus.cam.ac.uk/~csr21/horizontal-beams-after-repaint.png>. This happens because the replay-output-record methods for the clim internal graphics things (such as rectangles) set the medium clipping region while they're replaying, but don't set it back; they simply rely on a method on replay. In fact, in McCLIM itself as distributed the set-medium-graphics-state :after method on gs-clip-mixin is essentially disabled, though I'm not entirely sure why; gsharp re-enables it, presumably in an attempt to get some of this working, but disabling it again simply means that replaying horizontal beams (i.e. rectangles) which have been clipped ignores the previous clipping region. What is one to do? Well, I think with the standard as it is there's no way of writing output record classes. However, the case of changing ink can be handled in the spec, as CLIM specifies a function displayed-output-record-ink; using that, dealing with the ink looks like (defmethod replay-output-record :around ((record displayed-output-record) stream ...) (let ((medium (sheet-medium stream))) (with-drawing-options (medium :ink (displayed-output-record-ink record)) (call-next-method)))) and this will work, given that all displayed-output-record objects obey the displayed-output-record protocol. If we were to extend the protocol to require displayed-output-record-clipping-region, displayed-output-record-text-style and displayed-output-record-line-style, then I think this would cover the difficult cases, most of the set-medium-graphics-state methods could go away, and gsharp could have horizontal short beams. Comments? Cheers, Christophe

1 1

[mcclim-devel] Towards a 0.9.3 "Trinity Sunday" release
by Andreas Fuchs 26 May '06

26 May '06

Hi, this is going to be the first (or third, if you count Laetare Sunday) release in a time-boxed series! The plan is to release on Trinity Sunday, which is on the 11th of June this year. The freeze period will start on June 6, that is the tuesday after Pentecost. Seeing as the last freeze announcement prompted a lot of fixes and patches to come in, I'd like to urge all contributors to send your patches before the start of the freeze period this time. You've got a long weekend to do so, too. (-: Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

1 0

[mcclim-devel] Debugger, ESA, mcclim-freetype
by Christophe Rhodes 26 May '06

26 May '06

Hi, Today I observed a rather nasty interaction that I'm at a loss to explain. If I wrap the CLIM Debugger around an Emacs-Style Application which uses mcclim-freetype, and provoke an entry into that debugger, I get X Length Errors. I think I need all three of those elements: the clim debugger and listener work fine together; gsharp and the clim debugger without freetype work fine; and of course the applications work acceptably using freetype in normal operation and with slime. I am not sure whether this is specific to SBCL; nor am I sure whether it is specific to threaded lisps; I haven't tried it with a non-threaded system. The event queue process has a backtrace that looks like Backtrace: (BACKTRACE-AS-LIST 200) (DEBUGGER-HOOK #<XLIB:LENGTH-ERROR {10060EA641}> #) (INVOKE-DEBUGGER #<XLIB:LENGTH-ERROR {10060EA641}>) (CERROR "Ignore" XLIB:LENGTH-ERROR) (XLIB::X-CERROR "Ignore" XLIB:LENGTH-ERROR :DISPLAY #<XLIB:DISPLAY :0 (The X.Org Foundation R60802000)> :ERROR-KEY XLIB:LENGTH-ERROR :ASYNCHRONOUS T :CURRENT-SEQUENCE 1913 :MAJOR 154 :MINOR 25 :SEQUENCE 1563) [...] (XLIB:PROCESS-EVENT #<XLIB:DISPLAY :0 (The X.Org Foundation R60802000)> :HANDLER # :TIMEOUT NIL :PEEK-P NIL :DISCARD-P T :FORCE-OUTPUT-P T) ((SB-PCL::FAST-METHOD CLIM-BACKEND:GET-NEXT-EVENT #) #<unavailable argument> #<unavailable argument> #<CLIM-CLX::CLX-PORT :HOST "" :DISPLAY-ID 0 {10059661F1}> (:WAIT-FUNCTION NIL :TIMEOUT NIL)) while the application thread (which /also/ gets a length error) has a backtrace involving HANDLE-REPAINT on the menu-button-pane of the CLIM Debugger, CLIM-CLX::FONT-DRAW-GLYPHS (MCCLIM-FREETYPE::FREETYPE-FACE ...), and a call to XLIB::DRAWABLE-DEPTH and XLIB::READ-REPLY. Any ideas? Can anyone replicate any of this? Is there something in the toplevel loop of ESA (or attendant methods) which could cause this problem? Cheers, Christophe

2 3

← Newer
1
...
40
41
42
43
44
45
46
...
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