mcclim-devel September 2006

mcclim-devel@common-lisp.net

11 participants
9 discussions

Re: Fwd: Re: [mcclim-devel] Severe performance regression with latest CVS sources?
by Christophe Rhodes 22 Nov '06

22 Nov '06

Paolo Amoroso <amoroso(a)mclink.it> writes: >> twice that many hash tables with (make-hash-table)? The other thing > > CL-USER> (time (dotimes (i (* 2 824)) > (make-hash-table))) > ; Compiling LAMBDA NIL: > ; Compiling Top-Level Form: > > ; Evaluation took: > ; 6,648 CPU cycles It's elided the creation, I'm afraid. Can you do (defvar *foo*) (time (dotimes (i (* 2 824)) (setq *foo* (make-hash-table)))) ? > ; > NIL > CL-USER> > > >> to look at is for collisions in your hash tables; check the EDGES-FROM >> slot of something with a lot of direct subclasses, say STRUCTURE-CLASS >> or CONDITION or NUMBER, and see if all of the entries are in the same >> bucket of the hash table) > > I'm not sure I understand what you mean. I used the SLIME inspector > to inspect the output of, say, (find-class 'structure-class). I > include the output below, which does not seem to have any EDGES-FROM > slot. I think the edges-from should be in the graph node output record. I'm not entirely sure how to get at one of those, but you could start by inspecting clim:*application-frame* from the slime inspector, finding the listener interactor pane, finding its output history, and looking at the output records in there. > 588,259,376 | 1,111 | 15.158 | 0.01364 | 529,486 | CLIM-INTERNALS::LAYOUT-EDGE-1 > 1,111: #<Code Object "LAMBDA (FWRAPPER)" {5A58260F}> > 1,470,608 | 2,222 | 0.056 | 0.00003 | 662 | CLIM-INTERNALS::ENSURE-EDGE-RECORD > 1,111: #<Code Object "DEFUN LAYOUT-EDGE" {59718A4F}> > 1,111: #<Code Object "DEFUN LAYOUT-EDGE-1" {5A75B007}> Well, that's moderately conclusive: the cost seems to be in LAYOUT-EDGE-1, not in ENSURE-EDGE-RECORD. Which is weird, because I can't really see what LAYOUT-EDGE-1 is doing that is so ludicrously expensive. Can you do the same thing, but with the CLIM package profiled additionally? (And then maybe one with CLIM but not CLIM-INTERNALS profiled?) The first 10 or so entries in each profile will probably suffice. (Maybe CLEAR-OUTPUT-RECORD is expensive?) Cheers, Christophe

3 3

[mcclim-devel] stupid newbie question re: initializing text-field
by John Morrison 11 Nov '06

11 Nov '06

Sorry for what might be either a Stupid Newbie Question or Pilot Error: I am trying to implement a frame that allows "form-like" pop-editing of a CL data structure which include strings. How can I initialize the text fields and text editors? If I do what seems like the recommended thing according to the Harlequin CLIM manual -- a :before method on run-frame-top-level, it seems like maybe some goatee buffer pointer is not initialized until after the primary run-frame-top-level method gets called. (I made my own :around run-frame-top-level method, and the setf gadget-value, in fact, succeeds after the (call-next-method) has run -- but of course that's a little late for me.) The attached lisp program seems to exhibit the symptoms: the "test1" command works as expected and sets the value, but the :before method does not seem to. I only tried this under Linux (CentOS 4.4) on a relatively recent SBCL (0.9.14 RPM), using a relatively recent McCLIM (CVS updated approx Sept 15th). If anybody would please suggest further experiments, I would carry them out post-haste. Sorry if this is a stupid mechanical question: also, is there a stylistically better way to do this? Thanks, -jm -- ==== John Morrison ==== MAK Technologies Inc. ==== 68 Moulton Street, Cambridge, MA 02138 ==== http://www.mak.com/ ==== vox:617-876-8085 x115 ==== fax:617-876-9208 ==== jm(a)mak.com

4 5

[mcclim-devel] draw-arrow with transformation, freetype with fix(ed) fonts
by Luigi Panzeri 14 Oct '06

14 Oct '06

Hi all (and good holiday if you are in vacation), i noted two strange behavior, but I am not a clim expert but so sorry if i miss something. 1) draw-arrow* use the line-style-thickness to calculate distances in order to draw the head, but that thickness is not transformed with the current user transformation. So for example: (in-package :clim-user) (define-application-frame foo () () (:panes (app :application :width 1000 :height 1000 :display-function #'display)) (:layouts (default (vertically () app)))) (defun display (frame stream) (declare (ignore frame)) (with-first-quadrant-coordinates (stream 0 1000) (with-scaling (stream 250 250) ;; so now it is 4x4 (draw-line* stream 2 1 2 2.5) (draw-arrow* stream 1 1 1 2.5 :head-length 0.1 :head-width 0.1)))) (run-frame-top-level (make-application-frame 'foo)) i draw a 4x4 grid drawing a line and a parallel arrow (of the same length), but the two drawing is not of the same length. I tried to fix that (see first attachment). 2) in make-text-style i can specify the font family with :fix or :fixed for fixed fonts, but the freetype experimental extension accept only :fix (that is standard-compliant afaik). Do you have suggestion for the delivery of mcclim application (e.g. to avoid the debugger et similia)?

2 1

[mcclim-devel] Debugging tips
by John Connors 15 Sep '06

15 Sep '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 How do I maximise the debuggability of mcclim? I'm going back to my mcclim texture generator app, this time using the gtk backend, hoping to stress it a bit. I'm using sbcl-0.9.16. & SLIME Does anyone have any debugging tips? Is there a strategic point in the code where I can proclaim (debug 3) and get the whole of mcclim compiled with debug info...? - -- +--------------------------------------------------------+ |Cyborg Animation Programmer | johnc(a)yagc.ndo.co.uk| |http://badbyteblues.blogspot.com -----------------------| +--------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFCc3ktiwrK5pscc0RAg07AJ4t+OIm3YAY0GzwOfRsZulTsOK71ACgxLEu btFeA7H6tCwSh5b+1H3kbNc= =+ZQj -----END PGP SIGNATURE-----

2 1

[mcclim-devel] Creation of a library of presentation type definitions
by Troels Henriksen 14 Sep '06

14 Sep '06

When hacking on CLIM applications, it often/always becomes necessary to define new presentation types - some of these are very specialized to the application, while others are very general concepts (such as URLs). Having to reimplement these presentation types in every application is pointless and impairs application integration (not very much right now, since McCLIM doesn't support input contexts across multiple frames). Therefore, I propose the creation of a portable library of general-purpose presentation type definitions containing definitions of widely useful presentations such as `url' or `package', and whatever else is not too specialized to specific applications. I think this library should be bundled with McCLIM, yet not be dependent on the of McCLIM as the underlying CLIM implementation, because most users of free CLIM applications will be using McCLIM already, and bundling the library with McCLIM will free them from having to hunt down new dependencies. What do you think? -- \ Troels "Athas" /\ Henriksen

2 1

[mcclim-devel] Does toward-x key in draw-text* work in McCLIM?
by Daniel Katz 12 Sep '06

12 Sep '06

Hi, I was looking at the CLIM spec and noticed that draw-text* exposes the possibility of changing the direction of the text drawn (e.g., having the text go right-to-left or top-to-bottom), but I don't seem to be able to get it to work in McCLIM (latest CVS running with CLX against the Mac OS X X11.app system). In detail, I tried the following code (modified slightly from the "hello world" example from the "Guided Tour" paper: ------------------------------------------------------------------------ (define-application-frame hello-world () ((greeting :initform "Hello World" :accessor greeting)) (:pane (make-pane 'hello-world-pane))) (defclass hello-world-pane (clim-stream-pane) ()) (defmethod handle-repaint ((pane hello-world-pane) region) (let ((w (bounding-rectangle-width pane)) (h (bounding-rectangle-height pane))) ;; Blank the pane out (draw-rectangle* pane 0 0 w h :filled t :ink (pane-background pane)) ;; Draw greeting in center of pane (draw-text* pane (greeting *application-frame*) (floor w 2) (floor h 2) :toward-x 0))) ; I expect to get "dlroW olleH" (defun make-and-run-hello-world () (run-frame-top-level (make-application-frame 'hello-world :height 300 :width 300))) ------------------------------------------------------------------------ and given the "toward-x" key given in the call to draw-text* (in handle-repaint), I'd expect to get a window with "dlroW olleH" printed; instead, I still get "Hello World". I tried a few other values for the toward-x key (e.g. (1- (floor w 2)), 1, -1), but saw no difference. Grepping through the McCLIM source, I find that "toward-x" is mostly ignore'd in the various back ends (e.g., Backends/CLX/medium.lisp), so I am taking that as an indication that this functionality is not yet implemented. Is this correct? Or am I just using the facility incorrectly? I'm sorry if this is a FAQ, but I looked at the "known bugs" page at http://mcclim.cliki.net/Bug, but didn't see anything there about draw-text* or its features... Thanks! Dan

2 1

[mcclim-devel] Repainting of shrinking windows?
by Daniel Katz 11 Sep '06

11 Sep '06

Hi, I've been reading the "Guided Tour" paper included in mcclim/Doc, and I've found a peculiar behavior for the "Hello World" example on my system (latest mcclim from CVS, sbcl 0.9.13, Mac OS X 10.4.7 on PPC running X11.app) and I'm not sure if it's - a bug in mcclim, or - a bug in X11.app, or - a bug in my understanding of how CLIM works, or - a feature! In any event, the issue is as follows. I run the following code (taken verbatim from the paper) in the CLIM-USER package at the REPL: ------------------------------------------------------------------------ (define-application-frame hello-world () ((greeting :initform "Hello World" :accessor greeting)) (:pane (make-pane 'hello-world-pane))) (defclass hello-world-pane (clim-stream-pane) ()) (defmethod handle-repaint ((pane hello-world-pane) region) (let ((w (bounding-rectangle-width pane)) (h (bounding-rectangle-height pane))) ;; Blank the pane out (draw-rectangle* pane 0 0 w h :filled t :ink (pane-background pane)) ;; Draw greeting in center of pane (draw-text* pane (greeting *application-frame*) (floor w 2) (floor h 2) :align-x :center :align-y :center))) (defun make-and-run-hello-world () (run-frame-top-level (make-application-frame 'hello-world))) (make-and-run-hello-world) ------------------------------------------------------------------------ and I do indeed get a very small window popping up with "Hello World" in it. (The window is so tiny, in fact, that it only shows about 5 letters, and that only thanks to the window manager requirement to make the window large enough to accomodate the usual "expand, hide, kill" buttons of the Mac OS X window manager.) I then grab the manual "resizing" corner of the window and make it bigger, and things are fine, with the text of "Hello World" dynamically readjusting itself to stay centered in the window. The problem comes when I try to use the same mechanism to make the window smaller. Whenever dragging the corner of the window is used to reduce the size of the window, the text does not automatically recenter but rather stays in the same absolute position on the screen. (I am attaching a PNG which shows the effect of expanding a window and then shrinking it again using the "resizer" in the lower right corner of the window -- the text is clearly no longer centered.) Any attempt to enlarge the window (in either or both dimensions) will instantly recenter the text again. Clearly, the "shrink window" event is not being acted on for recentering purposes. But is this a bug in McClim (i.e., it should be repainting on shrink but is not), or is it a bug in the Mac OS X X11.app (i.e., it should be sending some sort of message on shrink but is not) or is it my misunderstanding (i.e., I should be adding some code to get the repaint to activate on shrink, and I have not done so)? Thanks for any insight you can provide! Dan

2 2

[mcclim-devel] Edit form in the clim listener
by Philippe Brochard 04 Sep '06

04 Sep '06

Hi all, In cl-wav-synth, I use the code below to edit a form previously evaluated in the listener. It works very well for me but is this an acceptable way to do it and is there something planed to add the editing capability in the listener ? (I've looked in the source and found something about history but I doesn't found how to use it). Best regards, Philippe ---------------------------------------------------------------------- (define-command (com-eval :menu t :command-table lisp-commands) ((form 'clim:form :prompt "Form")) (let ((values (multiple-value-list (handler-case (eval form) (error (condition) (format nil "~A" condition)))))) (fresh-line) (shuffle-specials form values) (display-evalues values) (fresh-line))) (define-command (com-edit-form :name t :menu t :command-table lisp-commands) ((form 'form :prompt "Form")) (multiple-value-bind (x1 y1) (stream-cursor-position *standard-input*) (let ((new-form (accept 'clim:form :stream (frame-standard-input *application-frame*) :prompt "New form" :default form :insert-default t))) (multiple-value-bind (x2 y2) (stream-cursor-position *standard-input*) (declare (ignore x2)) (let* ((interactor (find-pane-named *application-frame* 'cl-wav-synth-clim::interactor)) (output-history (stream-output-history interactor)) (width (bounding-rectangle-width interactor))) (decf y1 (stream-line-height interactor)) (map-over-output-records-overlapping-region #'(lambda (rec) (delete-output-record rec output-history)) output-history (make-rectangle* 0 y1 width y2)) (draw-rectangle* interactor 0 y1 width y2 :ink (pane-background interactor)) (setf (stream-cursor-position *standard-input*) (values x1 y1)) (print-listener-prompt interactor *application-frame*) (present new-form 'form) (fresh-line) (force-output) (execute-frame-command *application-frame* `(com-eval ,new-form))))))) (define-presentation-to-command-translator edit-form (clim:command com-edit-form lisp-commands :gesture :describe :echo t :documentation ((object stream) (format stream "Edit ~A" (second object))) :pointer-documentation ((object stream) (format stream "Edit ~A" (second object))) :tester ((object) (eql (car object) 'com-eval))) (object) (list (second object))) (define-presentation-to-command-translator edit-form-form (clim:form com-edit-form lisp-commands :gesture :describe :echo t :documentation ((object stream) (format stream "Edit ~A" object)) :pointer-documentation ((object stream) (format stream "Edit ~A" object))) (object) (list object)) (define-presentation-to-command-translator eval-form (clim:form com-eval lisp-commands :gesture :select :echo t :documentation ((object stream) (format stream "Eval ~A" object)) :pointer-documentation ((object stream) (format stream "Eval ~A" object))) (object) (list object)) ---------------------------------------------------------------------- -- Philippe Brochard <hocwp(a)free.fr> http://hocwp.free.fr -=-= http://www.gnu.org/home.fr.html =-=-

1 0

[mcclim-devel] [ANN] cl-wav-synth - express noises as you think V2006-08-26
by Philippe Brochard 04 Sep '06

04 Sep '06

Hi everybody, I'm glad to announce the last public release of cl-wav-synth. cl-wav-synth is a wav sample editor. It comes in two parts, the main library for manipulating wav files and a (Mc)CLIM interface with a full lisp listener, a sample pane editor, a spectrum pane editor and a song pane editor. The wav sample editor is driven from the lisp REPL: you can watch immediately the result of each applied functions. cl-wav-synth comes with some effects as echo, delay, pitch... The spectrum editor is here just for educational purpose. It show the effect of adding sinus together. But it can load spectrum from the sharc project and can be used to produce instruments sounds (the sample amplitude need to be modified to have a real sound). The song editor is a way to express a song. A song is just a list of events to write on a wav file. cl-wav-synth traverses the song list and evaluates the form of each song-sample, if the result is a wav sample, it is merged in the song wav file. Since the last release, there have been many enhancements For samples: - Sample flags (or multiselections) - Sample tones - To produce all the musical range (do, ré, mi... or a, b, c...) from a single sample. - Envelope manipulation (drawing mode) - Players choices (tested under Unix/MacOS/Windows) For songs: - Mouse rectangular selection (move/delete/copy selection) - Undo/Redo system - Grid and snap And some bug fixes (in particular a double redisplay which divided the performances by two (sorry for the bad pub)). You can find more here: http://common-lisp.net/project/cl-wav-synth/ Have fun, and thanks all for your great work with McCLIM ! I'm really amazed how easy it is to make graphical things with clim (once your accustomed to it). Regards, Philippe -- Philippe Brochard <hocwp(a)free.fr> http://hocwp.free.fr -=-= http://www.gnu.org/home.fr.html =-=-

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel September 2006