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

[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