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

[mcclim-devel] cvs problem?
by Paul Werkowski 16 Jan '05

16 Jan '05

Tried to do a cvs update, got cvs server: cannot open directory /project/mcclim/cvsroot/mcclim/images: No such file or directory cvs server: skipping directory images Paul

4 4

[mcclim-devel] Running McCLIM and CL-SDL together: is it possible?
by Paolo Amoroso 08 Jan '05

08 Jan '05

Is it possible to run a McCLIM and a CL-SDL (cl-sdl.sourceforge.net) application within the same Lisp image? When I try this with CMUCL, only the CL-SDL application runs and the McCLIM one--say, the CLIM Listener--is frozen, i.e. the window is not refreshed and does not process input events. Things do not change if I start the CLIM Listener with :new-process t. I understand that the OpenGL/SDL event loop is a bit "pervasive", but I wonder whether there are any workarounds. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

1 1

Re: [mcclim-devel] question about display functions and control apps
by rpgoldman＠real-time.com 08 Jan '05

08 Jan '05

I'm afraid I'm restarting an old discussion, but I've had it on the backburner, and now that I'm moving forward, I'm not quite sure how to finish out the solution. >>>>> "AH" == Andy Hefner <ahefner(a)gmail.com> writes: AH> What I might do is run a separate thread from the GUI that monitors AH> external conditions. It can close over your frame event queue, and AH> communicate changes to the GUI via events as necessary. Just define AH> your own event subclasses and write handle-event methods for them, AH> which will run in the GUI thread and can perform the necessary AH> updates. McCLIM itself already works in this fashion on threaded AH> platforms, events are collected from CLX in a background thread which AH> queues them up for the applications to handle. I think this is the right solution for control applications. One has a second thread, which gets status updates and latches them into slots in the application frame, and then we queue up an event. Here are a couple of follow-ons, though: 1. Do I just make an event that will translate into setting frame-needs-redisplay? 2. How do I ensure that the slots that I'm latching into are stable over the redisplay? I imagine I make a clim-sys:lock object to make the update process and the redisplay process mutually exclusive, but can anyone give me a little guidance about what to protect in the CLIM code? I have been thinking that I should make a method for redisplay-frame-pane for my application that will hold the lock and (call-next-method). Is this the right level of granularity? Thanks! Robert

3 4

[mcclim-devel] Spam at McCLIM CLiki
by Paolo Amoroso 05 Jan '05

05 Jan '05

The first spammed page at McCLIM CLiki: http://mcclim.cliki.net/Recent%20Changes shows that spammers have found also the site. An uphill battle starts... Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

1 0

[mcclim-devel] problem with Goatee
by Matley 05 Jan '05

05 Jan '05

I am using mcclim (from cvs) and i am playing with goatee and his test (goatee-test.lisp) If i change the :initial-contents to a string with a newline inside, like (format nil "The fox jumped ~% over the goatee") i get corrupted output ([] characters). Bigger the string i put in it, more corrupted i get the output. I tried to debug it, without success because i didnt understand all the protocol (buffer, dblhead, etc.) inside it. So my questions are: Is it a bug or is there another mechanism to insert more line? Is goatee the standard text editing tool (usable as an enhanced gadget)?

1 0

[mcclim-devel] running clim apps over ssh -X fails
by Timmy Douglas 03 Jan '05

03 Jan '05

the following fixes it: 16:01 < dan_b> I would hazard that if you replace the call to xlib:open-display with xlib:oipen-default-display (and no arguments) it'd probably work fine 16:01 < timmyd> and the other error message is echod to the terminal 16:01 < dan_b> but open-default-display is not part of standard CLX 16:02 < dan_b> (that's in the initialize-clx method in Backends/CLX/port.lisp, around line 236 in my copy) (defmethod initialize-clx ((port clx-port)) (let ((options (cdr (port-server-path port)))) (setf (clx-port-display port) (xlib:open-default-display)) (progn (setf (xlib:display-error-handler (clx-port-display port)) #'clx-error-handler)

1 0

[mcclim-devel] CPU usage > 95% when running McCLIM apps
by Paolo Amoroso 03 Jan '05

03 Jan '05

When I run a McCLIM application, according to `top' CPU usage is constantly above 95% or so, and the KDE System Monitor reports about 50% for CPU 1. Here is a typical `top' entry when running the CLIM Listener: top - 09:52:31 up 3 min, 1 user, load average: 0.37, 0.23, 0.10 Tasks: 78 total, 2 running, 76 sleeping, 0 stopped, 0 zombie Cpu(s): 14.3% us, 36.0% sy, 0.0% ni, 49.7% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 2075012k total, 301272k used, 1773740k free, 11244k buffers Swap: 2004420k total, 0k used, 2004420k free, 165556k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2728 paolo 25 0 1284m 37m 45m S 99.9 1.8 0:18.87 cmucl [...] When only the CMUCL toplevel is running, it is below 1%. Why is CPU usage so high with McCLIM applications? Is it real or some sort of measuring artifact? I use the latest McCLIM CVS sources with CMUCL Snapshot 2004-12 under Slackware Linux 10.0. My PC is a 2.8 GHz Pentium IV with 2 GB of RAM. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

3 7

[mcclim-devel] Bug list page at McCLIM CLiki: new resource
by Paolo Amoroso 03 Jan '05

03 Jan '05

I have created a simple McCLIM bug list at: http://mcclim.cliki.net/Bug It is meant as a useful, lightweight resource for both users and developers. Usage, as described in the short instructions at the top, should be straightforward. The only non obvious issue is the use of a NAME HTML tag, such as `my-bug', for each entry, This makes it possible to have URLs such as: http://mcclim.cliki.net/Bug#my-bug do the right thing and point the browser to the appropriate entry. Of course, I hope the page will not get long enough to make this feature useful :) Since the mcclim-devel list is archived, I will repost old bug reports of mine, and add links from the bug list, so that they can now be permanently archived. If this is an inconvenience for you, just let me know and I will not do it. Your feedback--better yet, your edits--is welcome. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

4 7

[mcclim-devel] deftype coordinate
by Christophe Rhodes 03 Jan '05

03 Jan '05

Hi, A little bit of empirical measurement by Juho Snellman reveals that in certain circumstances, such as waving the mouse over the gsharp window, mcclim under sbcl spends 70% or so of its time in bignum operations related to converting floating point numbers to rational ones. I believe that this is an artifact of the "permissive" coordinate type (currently set to real, apparently after a version of cmucl started doing some kind of type checking or inference). Attached is a patch which restores the double-float coordinate type, along with at least some of the necessary coercions here and there. I'd probably not merge this directly, because I'm still confused over when something is a coordinate and when it isn't. I believe that bounding-rectangles and regions are coordinate-based, and that output-records are rational-based, at least in terms of their position. If this is the case, I'd suggest adding completely separate slots for the two "worlds"; rather than having coercions on accesses, there would be coupled setter methods. In this patch, I've instead been somewhat conservative: anywhere where I was uncertain what was happening, I inserted a call to the COORDINATE function. This version has survived a certain amount of rudimentary testing in the listener and gsharp. I'd be interested to know if there is any perceptual speed change, and also whether there are coordinate-related bugs remaining. [ this patch was driven by a branch of SBCL in CVS tagged as clos-typechecking-branch, which includes type checks for most (setf slot-value), (setf accessor) and make-instance calls ] Cheers, Christophe

1 0

[mcclim-devel] GCL and mcclim
by root 31 Dec '04

31 Dec '04

Is there any effort to port mcclim to GCL? Is there any effort to support mcclim on Windows? I ask because I'd like to rewrite the graphics for Axiom (http://axiom.axiom-developer.org) in lisp in a portable way. Tim Daly daly(a)idsi.net

8 13