mcclim-devel November 2012

mcclim-devel@common-lisp.net

3 participants
3 discussions

Re: [mcclim-devel] mcclim-devel Digest, Vol 39, Issue 6
by Irene DURAND 27 Mar '13

27 Mar '13

Hello, As my paste on irc lisp, did not have any answer, I turning again to this more specialized mailing list. I have this MClim problem. The application runs fine on Linux with SBCL 1.0.13, xorg-x11-server 1.3.0.0-9.fc7, a recent version of MClim. But doesn't on my Mac (Darwin PowerPC) with MacOS 10.5 (leopard), SBCL 1.0.16, cvs version of MClim, Xquartz 2.1.5 - (xorg-server 1.3.0-apple22)(2.1.5). I have tried to create the smallest as possible application where the problems occurs (attached). Just compile the file and launch mini::(start) On Linux, I have the desired behaviour: a circle blinks (red/green/red/...) on the display pane and at the bottom of the window application, the "quit" button is displayed and works. On the Mac, the circle blinks correctly but the "Quit" button never shows up. For a while the application is killable with C-c C-c (under Slime), but after a while there is no way to kill it than to stop Lisp and restart everything (even /the/ <http://www.lispworks.com/reference/HyperSpec/Body/s_the.htm> X server). Note that this application used to work on Mac OS 10.3 (Panther) with older versions of everything. I suspect the X server to behave differently from before. But now I don't see how to make the application work. This is too bad, as I usually use a similar application for my Lisp undergraduate course. If anyone has an idea, it will be welcomed. Irène (defpackage :mini (:use :clim :clim-extensions :clim-lisp)) (in-package :mini) (let ((colors (list +red+ +green+))) (setf colors (nconc colors colors)) (defun display-function (frame pane) (draw-circle* pane 10 10 10 :ink (pop colors)) (sleep 0.5) (redisplay-frame-panes frame))) (defun quit () (frame-exit *application-frame*)) (define-application-frame mini () () (:panes (display :application :display-function 'display-function :incremental-redisplay t) (quit :push-button :label "Quit" :activate-callback (lambda (x) (declare (ignore x)) (quit)))) (:layouts (defaults (vertically () display quit)))) (defun run-test (name) (loop for port in climi::*all-ports* do (destroy-port port)) (setq climi::*all-ports* nil) (let ((frame (make-application-frame name))) (run-frame-top-level frame))) (defun start () (run-test 'mini) 0) (defmethod run-frame-top-level :before ((mini mini) &key) (let* ((frame-manager (frame-manager *application-frame*)) (port (climi::frame-manager-port frame-manager)) (display (clim-clx::clx-port-display port))) (setf (xlib:display-after-function display) g#'xlib:display-force-output)))

4 4

[mcclim-devel] how to track down apparent memory leaks in drawing?
by John Morrison 14 Nov '12

14 Nov '12

Hi All; tl:dr; slightly revised drawing-benchmark demo (attached) from quicklisp mcclim shows increased (leaked?) memory usage. I am using McCLIM to deal with PostGIS (FC16, x86_64). It appeared that drawing vector GIS data using draw-line* leaked memory. After doing the obvious things (see below), I slightly modified the clim-demo::drawing-benchmark app to try and produce the smallest code that exhibits the behavior: 1. draw lines instead of either rectangles or text 2. for 20 seconds rather than 1 3. print SBCL's (room) into the window (make your mapped window tall) 4. run a (sb-ext:gc) 5. print (room) again lather, rinse, and repeat, by hitting the "Run" button. I obviously didn't use the presentation system in my program (as I presumed it would hold onto output records, etc.). I commented out the single draw-line* form, and that enabled my program to traverse the entire (rather large) GIS vector dataset with no perceptible increase in memory usage (according to the "top" UNIX utility rather than (room). I updated to today's SBCL (maybe it's a bug that's been fixed), but I still observed the increasing memory usage. Questions: (a) Should I try any of the several forked McCLIMs mentioned recently? Has any of them had significant work in the simple drawing area? (b) Can anybody tell me anything that might shorten the hunt? Thanks!!! -jm -- --- John Morrison --- john.nmi.morrison(a)gmail.com

1 1

[mcclim-devel] Official repository lagging?
by Manuel Giraud 14 Nov '12

14 Nov '12

Hi mcclimers, I wanted to (re)try to do some hacking on mcclim. So I have checkout the official CVS repository (from which the quicklisp package seems to be made of) and (slowly) start working on it. Then it occured to me there are many public fork of mcclim on github, for instance: https://github.com/onixie/mcclim https://github.com/slyrus/mcclim https://github.com/mmontone/mcclim https://github.com/timoore/mcclim All of them were active in the last 4 months and have their own set of improvements while the official CVS last patch dates back to july 2011. So my question is, can someone with enough credential collects (and maybe selects) those patches and apply them to the official repository? (I know I can 'git clone' one of those repo, cherry pick what I want and add my patches but then it will be yet another unofficial repo). Best, -- Manuel Giraud

6 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel November 2012