mcclim-devel May 2008

mcclim-devel@common-lisp.net

10 participants
7 discussions

[mcclim-devel] [bug] Asynchronous ID-CHOICE-ERROR -- CLX or McCLIM?
by Nikodemus Siivola 23 Aug '08

23 Aug '08

This may be a CLX issue, or a problem in the CLX backend -- I would not know, but the test-case is pure CLIM. After the error future attempts to RUN-FRAME-TOP-LEVEL result in similar errors. Backtrace follows, self contained test-case attached (RUN-FRAME-TOP-LEVEL, then "Stress" -- it may take a while, but eventually it breaks for me.) This is CVS McCLIM, Christophe's CLX, and SBCL 1.0.13.45, on a MacBook running Tiger. $ uname -a Darwin manic.local 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 X is the Apple packaged one: X11 1.1.3 - XFree86 4.4.0 Cheers, -- Nikodemus Asynchronous ID-CHOICE-ERROR in request 10265 (last request was 10266) Code 55.0 [CreateGC] ID #x600002 [Condition of type XLIB:ID-CHOICE-ERROR] Restarts: 0: [CONTINUE] Ignore 1: [ABORT] Return to application command loop 2: [ABORT] Return to SLIME's top level. 3: [ABORT] Exit debugger, returning to top level. Backtrace: 0: (XLIB::X-CERROR "Ignore" XLIB:ID-CHOICE-ERROR) 1: (XLIB:DEFAULT-ERROR-HANDLER #<XLIB:DISPLAY :0 (The XFree86 Project, Inc R40400000)> XLIB:ID-CHOICE-ERROR) 2: (XLIB::REPORT-ERROR #<XLIB:DISPLAY :0 (The XFree86 Project, Inc R40400000)> 14 XLIB:ID-CHOICE-ERROR) 3: (XLIB::READ-ERROR-INPUT #<XLIB:DISPLAY :0 (The XFree86 Project, Inc R40400000)> 10265 #S(XLIB::REPLY-BUFFER :SIZE 32 :IBUF8 #(0 14 25 40 2 0 ...) :NEXT NIL :DATA-SIZE 32) #<SB-THREAD:THREAD "initial thread" {116920A9}>) 4: (XLIB::READ-INPUT #<XLIB:DISPLAY :0 (The XFree86 Project, Inc R40400000)> NIL NIL #<FUNCTION (LAMBDA (XLIB::PENDING-COMMAND)) {13969ECD}>) 5: (XLIB::READ-REPLY #<unavailable argument> #<unavailable argument>) 6: (XLIB:ALLOC-COLOR #<XLIB:COLORMAP TRUE-COLOR :0 32> #<XLIB:COLOR 0.641639 0.52443945 0.84608877>) 7: ((SB-PCL::FAST-METHOD CLIM-CLX::X-PIXEL (CLIM-CLX::CLX-PORT T)) #(17 NIL) #<unavailable argument> #<CLIM-CLX::CLX-PORT :HOST "" :DISPLAY-ID 0 {122D0AC1}> #<CLIM-INTERNALS::NAMED-COLOR "Unnamed color">) 8: ((SB-PCL::FAST-METHOD CLIM-CLX::MEDIUM-GCONTEXT (CLIM-CLX::CLX-MEDIUM COLOR)) #(9 NIL) #<unused argument> #<CLIM-CLX::CLX-MEDIUM {13F67CE1}> #<CLIM-INTERNALS::NAMED-COLOR "Unnamed color">) 9: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument> #<CLIM-CLX::CLX-MEDIUM {13F67CE1}> #<CLIM-INTERNALS::NAMED-COLOR "Unnamed color">) 10: ((SB-PCL::FAST-METHOD MEDIUM-DRAW-POINT* (CLIM-CLX::CLX-MEDIUM T T)) #<unavailable argument> #<unavailable argument> #<CLIM-CLX::CLX-MEDIUM {13F67CE1}> 290 142) 11: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS-INTERNAL (MEDIUM T T)) #<unavailable argument> #<unavailable argument> #<CLIM-CLX::CLX-MEDIUM {13F67CE1}> #<CLIM-CLX::CLX-MEDIUM {13F67CE1}> #<CLOSURE (FLET CLIM-INTERNALS::GRAPHICS-OP) {13F67CC5}>) 12: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS (CLIM-INTERNALS::PIXMAP T)) #<unavailable argument> #<unavailable argument> #<CLIM-INTERNALS::MIRRORED-PIXMAP {117385F9}> #<CLOSURE (FLET CLIM-INTERNALS::GRAPHICS-OP) {13F67CC5}>) 13: ((LAMBDA (COLOR X Y)) #(0.641639 0.52443945 0.84608877) 290 142) 14: (RANDOM-RENDER 400 300 #<CLOSURE (LAMBDA (COLOR X Y)) {11738895}>) 15: (RENDER-SCENE #<APPLICATION-PANE CANVAS {11F91F99}>) 16: (COM-STRESS) 17: ((SB-PCL::FAST-METHOD DEFAULT-FRAME-TOP-LEVEL (APPLICATION-FRAME)) #<unavailable argument> #<unavailable argument> #<TEST-FRAME {1381E9F1}>) 18: ((SB-PCL::FAST-METHOD RUN-FRAME-TOP-LEVEL (APPLICATION-FRAME)) #<unavailable argument> #<unavailable argument> #<TEST-FRAME {1381E9F1}>) 19: ((SB-PCL::FAST-METHOD RUN-FRAME-TOP-LEVEL :AROUND (APPLICATION-FRAME)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION (SB-C::&OPTIONAL-DISPATCH #) {131373FD}> :PV NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<TEST-FRAME {1381E9F1}>) 20: (SB-INT:SIMPLE-EVAL-IN-LEXENV (RUN-FRAME-TOP-LEVEL (MAKE-APPLICATION-FRAME (QUOTE TEST-FRAME))) #<NULL-LEXENV>)

3 12

[mcclim-devel] Gadget based accepting-values
by Clinton Ebadi 04 Jul '08

04 Jul '08

Greetings, Attached is a patch, accepting-values-gadgets-1, that makes accepting-values capable of working of with gadget based views. The (probably) uncontroversal part is exporting the CLIM 2.2 (from the Franz user guide) gadget views and the related constants. I added view-gadget-initargs support to gadget-view so gadgets can be created properly. The code merely stashes all the provided initargs into a slot and does no sanity checking. Should this somehow verify that the initargs are valid for the related gadget class? If so, what would be the cleanest way? I also caught the lack of a +check-box-view+ and added it. To the frame-manager protocol class I added the CLIM 2.2 frame-manager-dialog-view method which (for now) defaults to a textual rather than gadget based view. I noticed the XXX comment attached so I am unsure if this is an OK place to add it. accepting-values-stream now returns the frame manager dialog view as its stream-default-view. The Franz user guide says that this ought to be setfable; to which class should I add the slot and accessor? To accepting-values itself I moved the final cleanup of the input editor records into a generic, finally-finalize-query-record, so that accept-present-default methods that don't contain a text editing field can actually work. There are a few quick hackish methods for accepting from a text-field-view/gadget-dialog-view (the assumption being that they contain an input editing record so just calling them with +textual-dialog-view+ will work). I also reworked the accept-present-default for text-field-view to always call the textual-dialog-view method even if the width is not set. Also attached is avg.lisp which is a work in progress I'd like someone a bit more knowledgeable about CLIM to look at which implements gadget based accepting-values methods as per the Franz user guide. This is loosely based upon the public domain code found in [1]. If it looks ok I can split it up into the appropriate files in McCLIM and submit a patch. It seems to work well enough, but I am unsure if I have implemented things well. The most suspect bit is line 225 where I set the cache-test of the updating-output-record to return t always. I was having problems with a new gadget being created every time the value changed. gui.lisp contains a small test frame for testing whether the gadgets actually work. [1] http://osdir.com/ml/lisp.mcclim.devel/2006-04/msg00069.html -- Jessie: but today i was a nerd Jessie: i even read slashdot.

3 14

[mcclim-devel] McClim up and running
by christopher melen 12 Jun '08

12 Jun '08

OK so I have McClim up and running on my Mac (PPC with OS X 10.4.9). I've tried it with two Lisps so far, OpenMCL (now Clozure CL) and SBCL. Some observations - 1. SBCL works best. I had some problems with the listener under OpenMCL, especially when I tried to change the path (complained that it was 'not of type LIST'). 2. I have to run it with Apple's X11 - which is not a problem for me, as I use it frequently, but I was wondering if anyone's got it running without it. I had to set the DISPLAY environment variable in my .bash_profile to 127.0.0.1:0.0. So I have to run it from the terminal or an xterm, not from Emacs Slime (my preferred set-up). 3. When an app starts (for instance, the listener, or Gsharp) it takes a while to 'come alive'. Menus aren't usable for about a minute. After that it's OK, though, and I can restart an app (in the same Lisp session) without issue. I think I've only encountered this problem with SBCL. 4. I have also tried to get McClim running on my Windows box. I can compile it for Clisp (native Cygwin version, haven't tried the Win32 port), but when I try and run the Listener or any of the demos it just hangs (even with Cygwin's X11 running). I have also tried using the Win32 port of SBCL, but for some reason CLX won't compile on that. Might give ACL a go, if I can get ASDF to work properly with it. 4. I am hoping to use McClim to build the gui for my current project. I am keen to use it because of the fact that it's Lisp all the way through, unlike other Lisp-based gui kits (Ltk, cells-gtk, lispbuilder, for example) which, while perhaps slicker, feel a bit superficial (just wrappers for Tcl/Tk, Gtk, etc.). I have been tempted to fork out for ACL or LispWorks, but then there are licensing issues when it comes to redistributing my application. So I really want to stick with McClim. Any thoughts/comments much appreciated. Thanks, Chris __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

6 5

[mcclim-devel] "Recent news" typo
by Scott L. Burson 24 May '08

24 May '08

Hi, On http://common-lisp.net/project/mcclim/, under "Recent News", the recent "St. George's Day" release is shown as having occurred in 2007 rather than 2008. -- Scott

2 1

Re: [mcclim-devel] McClim up and running
by christopher melen 18 May '08

18 May '08

> It's no surprise that SBCL works best - it's what most McCLIM hackers > use. Also, it has good performance and implements CLOS well, which is > important to McCLIM. Clozure CL is also supposed to be good, so I'd be > interested in hearing the specifics of the error you got (backtrace?). With Clozure CL the only command that works in the listener's Filesystem menu is 'Up Directory'; everything else gives me this - Error: value PATHNAME is not of the expected type LIST. While executing: CCL::FRAME-SUPPLIED-ARGS, in process repl-thread. > You can set the environment variable for Emacs (M-x setenv)... I'd tried that, but it still errored, asking if I wanted to use the local unix display. > It is normal for McCLIM apps to be slightly sluggish at first, because > the CLOS caches need to be filled the first time generic functions are > called. Successive invocations of the program should start up > faster. A pause of an entire minute is highly unusual, however. Which > version of SBCL is that? When I run it with Clozure CL there's no delay at all. Only with SBCL. I'm running version 1.0.2. > How does it hang? Does it take up all available CPU time or block? > McCLIM works on CLISP on Unix, so the implementation itself should > not be a problem. Yes, CPU on the Windows machine is 100% at that point. I'll have a go on my laptop, which runs Vista, see if that's any better. Thanks, Chris __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

1 0

[mcclim-devel] cl-jpeg dependency with ASDF-install (bug?)
by christopher melen 13 May '08

13 May '08

When I try to ASDF-install McClim (on Mac OS X) it complains that it can't install a dependency, cl-jpeg. This library appears to be no longer available. __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

3 2

[mcclim-devel] Small patch for pixie look sliders
by Clinton Ebadi 06 May '08

06 May '08

Greetings, When testing a small program I noticed that the value-changed callbacks in pixie look sliders were not being called. I compared the handle-event methods for the concrete gadget and pixie looks, and I think the attached patch is the correct fix (and just copied from (handle-event <slider-pane> <pointer-button-release-event>)). -- Jessie: i thought your beard took the oxygen from the air and made it breathable for you

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel May 2008