From csr21 at cam.ac.uk Fri Jul 16 10:19:43 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 16 Jul 2004 11:19:43 +0100 Subject: [gsharp-devel] package locks and other stuff Message-ID: Hi, Two quick things. Firstly, modern (by which I of course mean "bleeding edge" sbcl has discovered some non-compliances in gsharp's code: defining CL:REST as a class, and CL:NUMBER as a generic function. Since, at a guess, I am the only user with bleeding edge sbcl I shall endeavour to fix this. Secondly, does the accept presentation-method on completable-pathname belong in gsharp or in McCLIM itself? (Shouldn't McCLIM's pathname acceptor do completion in an ideal world?) If so, I don't mind forgoing a little convenience for now: would (lambda (so-far mode) (complete-from-possibilities so-far #+cmu (ext:ambiguous-files so-far) #-cmu nil '() :action mode :predicate (lambda (obj) (declare (ignore obj)) t) :name-key #'namestring :value-key #'identity)) be an acceptable implementation in CLIM terms? Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From csr21 at cam.ac.uk Fri Jul 16 11:47:58 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 16 Jul 2004 12:47:58 +0100 Subject: [gsharp-devel] redraw buglets Message-ID: Hi, The new redrawing behaviour is very noticeably much better -- for those who haven't tried it yet, my understanding is that it means much less needs to be redrawn for each keystroke. There is still visible flicker in the two right-hand panes, though. As I understand it, the top right hand pane (the input state) should only need to be redrawn if the input state changes, but apparently it's being redrawn on every command. Similarly, the current element pane is redrawn rather often; admittedly the current element changes more often than the input state, but maybe the staff lines don't need to be redrawn each time? In addition, there seems to be an unrelated bug there: the red dot representing the notehead is not redrawn if the gsharp window is covered up and reexposed. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From strandh at labri.fr Fri Jul 16 12:21:26 2004 From: strandh at labri.fr (Robert Strandh) Date: Fri, 16 Jul 2004 14:21:26 +0200 Subject: [gsharp-devel] redraw buglets In-Reply-To: References: Message-ID: <16631.51270.435861.734391@serveur5.labri.fr> Christophe Rhodes writes: > > The new redrawing behaviour is very noticeably much better -- for > those who haven't tried it yet, my understanding is that it means much > less needs to be redrawn for each keystroke. I think it is the same. It is just that everything is drawn in a pixmap before sent to the pane. > There is still visible flicker in the two right-hand panes, though. Ah yes. Those should be done the same way. > As I understand it, the top right hand pane (the input state) should > only need to be redrawn if the input state changes, but apparently > it's being redrawn on every command. True. It does not cost very much to always redraw it (in case the command was one to change the input state), but yes, it could be optimized by using pane-needs-redisplay (or something like that). > Similarly, the current element pane is redrawn rather often; > admittedly the current element changes more often than the input > state, but maybe the staff lines don't need to be redrawn each time? I am sure there are many optimizations to implement, but I am not sure it will make a big difference. I would like to know what makes redrawing an entire page of the score around a second. Once I find that, I could try to figure out how to speed up the entire thing. At this point, I do not know whether it has to do with Gsharp, McCLIM, or CLX. > In addition, there seems to be an unrelated bug there: the red dot > representing the notehead is not redrawn if the gsharp window is > covered up and reexposed. OK, that's strange. I'll try to look into that. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From csr21 at cam.ac.uk Mon Jul 19 15:10:17 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 19 Jul 2004 16:10:17 +0100 Subject: [gsharp-devel] redraw buglets In-Reply-To: <16631.51270.435861.734391@serveur5.labri.fr> (Robert Strandh's message of "Fri, 16 Jul 2004 14:21:26 +0200") References: <16631.51270.435861.734391@serveur5.labri.fr> Message-ID: Robert Strandh writes: > Christophe Rhodes writes: > > There is still visible flicker in the two right-hand panes, though. > > Ah yes. Those should be done the same way. > > > As I understand it, the top right hand pane (the input state) should > > only need to be redrawn if the input state changes, but apparently > > it's being redrawn on every command. > > True. It does not cost very much to always redraw it (in case the > command was one to change the input state), but yes, it could be > optimized by using pane-needs-redisplay (or something like that). > > > Similarly, the current element pane is redrawn rather often; > > admittedly the current element changes more often than the input > > state, but maybe the staff lines don't need to be redrawn each time? > > I am sure there are many optimizations to implement, but I am not sure > it will make a big difference. Right. The major optimization, from a look-and-feel point of view, is I think the double-buffering, eliminating the flickery feel which catches the attention of the user. > I would like to know what makes redrawing an entire page of the > score around a second. Once I find that, I could try to figure out > how to speed up the entire thing. At this point, I do not know > whether it has to do with Gsharp, McCLIM, or CLX. Can you give me instructions on what you're doing to trigger the redraw? Alternatively, you may wish to try this running under the statistical profiler provided by sbcl -- loaded with (require :sb-sprof). Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From csr21 at cam.ac.uk Mon Jul 19 16:10:31 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 19 Jul 2004 17:10:31 +0100 Subject: [gsharp-devel] redraw buglets In-Reply-To: (Christophe Rhodes's message of "Mon, 19 Jul 2004 16:10:17 +0100") References: <16631.51270.435861.734391@serveur5.labri.fr> Message-ID: Christophe Rhodes writes: > Can you give me instructions on what you're doing to trigger the > redraw? Alternatively, you may wish to try this running under the > statistical profiler provided by sbcl -- loaded with (require > :sb-sprof). I've played around with this idea a little, and have some slightly surprising results. Apparently, at least for sbcl, the bottleneck is bignum gcd. The top 20 functions (statistically sampled by loading rapsoden-sjunger.gsh into gsharp and then leaning on C-f) are 1 231 6.2 231 6.2 SB-BIGNUM:BIGNUM-GCD 2 177 4.8 408 11.0 "&MORE processing" 3 164 4.4 572 15.5 SB-BIGNUM::MAKE-GCD-BIGNUM-ODD 4 140 3.8 712 19.3 "#'(LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. ...) (DECLARE #) ...)" 5 129 3.5 841 22.8 SB-BIGNUM::SUBTRACT-BIGNUM-BUFFERS 6 116 3.1 957 25.9 "#'(SB-KERNEL:INSTANCE-LAMBDA (SB-PCL::.ARG0.) (LET NIL # ...))" 7 116 3.1 1073 29.0 SB-KERNEL:TWO-ARG-+ 8 99 2.7 1172 31.7 SB-BIGNUM::BIGNUM-BUFFER-ASHIFT-RIGHT 9 91 2.5 1263 34.2 ASH 10 83 2.2 1346 36.4 "#'(SB-KERNEL:INSTANCE-LAMBDA (SB-PCL::.ARG0. SB-PCL::.ARG1.) (LET NIL # ...))" 11 80 2.2 1426 38.6 SB-BIGNUM::BIGNUM-GCD-ORDER-AND-SUBTRACT 12 77 2.1 1503 40.7 SB-KERNEL:CLASSOID-TYPEP 13 77 2.1 1580 42.7 SB-KERNEL::%%TYPEP 14 63 1.7 1643 44.5 SB-VM::GENERIC-+ 15 56 1.5 1699 46.0 SB-BIGNUM::BIGNUM-TRUNCATE-SINGLE-DIGIT 16 54 1.5 1753 47.4 SB-KERNEL::INTEGER-/-INTEGER 17 53 1.4 1806 48.9 SB-BIGNUM::%NORMALIZE-BIGNUM-BUFFER 18 53 1.4 1859 50.3 "hairy arg processor for top level local call SB!BIGNUM::BIGNUM-ASHIFT-LEFT-UNALIGNED" 19 52 1.4 1911 51.7 GETHASH 20 51 1.4 1962 53.1 TRUNCATE Unfortunately, this isn't yielding information about why it's spending so much time in GCD, though my suspicion would land on integer or ratio division. [ No, I don't know what "&MORE processing" is doing quite so high: it seems to be connected to certain methods, particuarly MAP-OVER-OUTPUT-RECORDS-CONTAINING-POSITION ] Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From strandh at labri.fr Mon Jul 19 16:23:07 2004 From: strandh at labri.fr (Robert Strandh) Date: Mon, 19 Jul 2004 18:23:07 +0200 Subject: [gsharp-devel] redraw buglets In-Reply-To: References: <16631.51270.435861.734391@serveur5.labri.fr> Message-ID: <16635.62827.384667.549080@serveur5.labri.fr> Christophe Rhodes writes: > > I would like to know what makes redrawing an entire page of the > > score around a second. Once I find that, I could try to figure out > > how to speed up the entire thing. At this point, I do not know > > whether it has to do with Gsharp, McCLIM, or CLX. > > Can you give me instructions on what you're doing to trigger the > redraw? My test case is control-f, which does nothing to the buffer, but the entire score gets redrawn anyway right now. On my machine, it takes about a second for the cursor to move forward. > Alternatively, you may wish to try this running under the > statistical profiler provided by sbcl -- loaded with (require > :sb-sprof). That's an idea. I have only tried the CMUCL profile package so far. I kind of suspect that the profiling itself is messing up the figures. In that case the statistical profiles might be better. I probably will not do that immediately, though, since I would have to start by installing a more recent version of SBCL, and then compile McCLIM for it, etc, etc. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Mon Jul 19 16:37:28 2004 From: strandh at labri.fr (Robert Strandh) Date: Mon, 19 Jul 2004 18:37:28 +0200 Subject: [gsharp-devel] Architecture question Message-ID: <16635.63688.209513.391256@serveur5.labri.fr> Hello, I have an architecture-related question, or rather, I have some thoughts that I would like to bounce on the members of this list, probably mostly Tim and Christophe. Here are my thoughts. Please comment on them and correct me if I am wrong. The score-pane is supposed to be reusable in other programs that need to display scores. For that reason, the score pane should not know about the internal data structures of Gsharp, nor about its GUI. On the other hand, it would be handy for other clients of the score pane to have ready-made presentation types that allow them to present a clef, a notehead, etc without having to write all that from scratch. At first, I thought that was impossible, because the presentation types for these objects would typically be the classes of the internal data structure of Gsharp. But then I realized (from reading the CLIM specification more thoroughly) that the presentation types could be disjoint from the classes of the internal data structure. The score pane module could then contain definitions of presentation types for most music objects, including how they are highlighted when the mouse passes over them etc. But, the symbols that are used as names of presentation types (presumable `clef', `notehead', `staff', etc.) would likely clash with symbols in the package that is used for the internal data structures of the client. The best solution to that problem would perhaps be to have the score pane not be `use'd by clients code, and to have a short abbreviation for the score pane package, such as `spn'. If I am right, I should start migrating all the presentation types of musical symbols to the score pane. Thoughts? -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Mon Jul 19 16:47:03 2004 From: strandh at labri.fr (Robert Strandh) Date: Mon, 19 Jul 2004 18:47:03 +0200 Subject: [gsharp-devel] redraw buglets In-Reply-To: References: <16631.51270.435861.734391@serveur5.labri.fr> Message-ID: <16635.64263.922685.150911@serveur5.labri.fr> Christophe Rhodes writes: > Christophe Rhodes writes: > > > Can you give me instructions on what you're doing to trigger the > > redraw? Alternatively, you may wish to try this running under the > > statistical profiler provided by sbcl -- loaded with (require > > :sb-sprof). > > I've played around with this idea a little, and have some slightly > surprising results. Apparently, at least for sbcl, the bottleneck is > bignum gcd. The top 20 functions (statistically sampled by loading > rapsoden-sjunger.gsh into gsharp and then leaning on C-f) are > > 1 231 6.2 231 6.2 SB-BIGNUM:BIGNUM-GCD > 2 177 4.8 408 11.0 "&MORE processing" > 3 164 4.4 572 15.5 SB-BIGNUM::MAKE-GCD-BIGNUM-ODD > 4 140 3.8 712 19.3 "#'(LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. ...) (DECLARE #) ...)" > 5 129 3.5 841 22.8 SB-BIGNUM::SUBTRACT-BIGNUM-BUFFERS > 6 116 3.1 957 25.9 "#'(SB-KERNEL:INSTANCE-LAMBDA (SB-PCL::.ARG0.) (LET NIL # ...))" > 7 116 3.1 1073 29.0 SB-KERNEL:TWO-ARG-+ > 8 99 2.7 1172 31.7 SB-BIGNUM::BIGNUM-BUFFER-ASHIFT-RIGHT > 9 91 2.5 1263 34.2 ASH > 10 83 2.2 1346 36.4 "#'(SB-KERNEL:INSTANCE-LAMBDA (SB-PCL::.ARG0. SB-PCL::.ARG1.) (LET NIL # ...))" > 11 80 2.2 1426 38.6 SB-BIGNUM::BIGNUM-GCD-ORDER-AND-SUBTRACT > 12 77 2.1 1503 40.7 SB-KERNEL:CLASSOID-TYPEP > 13 77 2.1 1580 42.7 SB-KERNEL::%%TYPEP > 14 63 1.7 1643 44.5 SB-VM::GENERIC-+ > 15 56 1.5 1699 46.0 SB-BIGNUM::BIGNUM-TRUNCATE-SINGLE-DIGIT > 16 54 1.5 1753 47.4 SB-KERNEL::INTEGER-/-INTEGER > 17 53 1.4 1806 48.9 SB-BIGNUM::%NORMALIZE-BIGNUM-BUFFER > 18 53 1.4 1859 50.3 "hairy arg processor for top level local call SB!BIGNUM::BIGNUM-ASHIFT-LEFT-UNALIGNED" > 19 52 1.4 1911 51.7 GETHASH > 20 51 1.4 1962 53.1 TRUNCATE > > Unfortunately, this isn't yielding information about why it's spending > so much time in GCD, though my suspicion would land on integer or > ratio division. I suspect you are right. I use fractions alot, and the GCD would be called not only for division, but also for additions, multiplications, etc. > [ No, I don't know what "&MORE processing" is doing quite so high: it > seems to be connected to certain methods, particuarly > MAP-OVER-OUTPUT-RECORDS-CONTAINING-POSITION ] I am willing to believe that. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Mon Jul 19 16:59:02 2004 From: strandh at labri.fr (Robert Strandh) Date: Mon, 19 Jul 2004 18:59:02 +0200 Subject: [gsharp-devel] redraw buglets In-Reply-To: References: <16631.51270.435861.734391@serveur5.labri.fr> Message-ID: <16635.64982.142427.402721@serveur5.labri.fr> Christophe Rhodes writes: > Unfortunately, this isn't yielding information about why it's spending > so much time in GCD, though my suspicion would land on integer or > ratio division. > > [ No, I don't know what "&MORE processing" is doing quite so high: it > seems to be connected to certain methods, particuarly > MAP-OVER-OUTPUT-RECORDS-CONTAINING-POSITION ] Actually, this might not have anything at all with Gsharp's main task, but could instead have something to do with McCLIM (perhaps inadvertently) using ratios instead of floats for some processing. It would be enough that we missed a coercion to coordinate or something like that. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From csr21 at cam.ac.uk Mon Jul 19 17:17:57 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 19 Jul 2004 18:17:57 +0100 Subject: [gsharp-devel] redraw buglets In-Reply-To: <16635.64263.922685.150911@serveur5.labri.fr> (Robert Strandh's message of "Mon, 19 Jul 2004 18:47:03 +0200") References: <16631.51270.435861.734391@serveur5.labri.fr> <16635.64263.922685.150911@serveur5.labri.fr> Message-ID: Robert Strandh writes: > Christophe Rhodes writes: > > Unfortunately, this isn't yielding information about why it's spending > > so much time in GCD, though my suspicion would land on integer or > > ratio division. > > I suspect you are right. I use fractions alot, and the GCD would be > called not only for division, but also for additions, multiplications, > etc. I had a look at sbcl's own routines, and it turns out that there is currently (and probably in sbcl-0.8.13, due out soon, but probably not in sbcl-0.8.13.1) a large avoidable inefficiency in SBCL's (and I believe also CMUCL's) BIGNUM-GCD. I'm working on patching the system, and I'll report back once I have some numbers. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From csr21 at cam.ac.uk Mon Jul 19 17:52:58 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 19 Jul 2004 18:52:58 +0100 Subject: [gsharp-devel] redraw buglets In-Reply-To: (Christophe Rhodes's message of "Mon, 19 Jul 2004 18:17:57 +0100") References: <16631.51270.435861.734391@serveur5.labri.fr> <16635.64263.922685.150911@serveur5.labri.fr> Message-ID: Christophe Rhodes writes: > I had a look at sbcl's own routines, and it turns out that there is > currently (and probably in sbcl-0.8.13, due out soon, but probably not > in sbcl-0.8.13.1) a large avoidable inefficiency in SBCL's (and I > believe also CMUCL's) BIGNUM-GCD. I'm working on patching the system, > and I'll report back once I have some numbers. 1 213 5.9 213 5.9 SB-BIGNUM:BIGNUM-GCD 2 171 4.8 384 10.7 SB-BIGNUM::SUBTRACT-BIGNUM-BUFFERS 3 139 3.9 523 14.5 "XEP for #'(SB-KERNEL:INSTANCE-LAMBDA (SB-PCL::.ARG0.) (LET NIL # ...))" 4 122 3.4 645 17.9 SB-BIGNUM::MAKE-GCD-BIGNUM-ODD 5 100 2.8 745 20.7 SB-BIGNUM::BIGNUM-GCD-ORDER-AND-SUBTRACT 6 96 2.7 841 23.4 "XEP for #'(SB-KERNEL:INSTANCE-LAMBDA (SB-PCL::.ARG0. SB-PCL::.ARG1. SB-PCL::.ARG2. ...) (LET NIL # ...))" 7 95 2.6 936 26.0 SB-KERNEL::%%TYPEP 8 89 2.5 1025 28.5 SB-BIGNUM::BIGNUM-BUFFER-ASHIFT-RIGHT 9 88 2.4 1113 31.0 SB-KERNEL:TWO-ARG-+ 10 81 2.3 1194 33.2 SB-KERNEL:CLASSOID-TYPEP Still really bignum-gcd dominated, I'm afraid. Your hypothesis about McCLIM coordinates is certainly possible... Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From csr21 at cam.ac.uk Mon Jul 19 20:25:49 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 19 Jul 2004 21:25:49 +0100 Subject: [gsharp-devel] redraw buglets In-Reply-To: (Christophe Rhodes's message of "Mon, 19 Jul 2004 18:52:58 +0100") References: <16631.51270.435861.734391@serveur5.labri.fr> <16635.64263.922685.150911@serveur5.labri.fr> Message-ID: Christophe Rhodes writes: > 1 213 5.9 213 5.9 SB-BIGNUM:BIGNUM-GCD > 2 171 4.8 384 10.7 SB-BIGNUM::SUBTRACT-BIGNUM-BUFFERS > 3 139 3.9 523 14.5 "XEP for #'(SB-KERNEL:INSTANCE-LAMBDA (SB-PCL::.ARG0.) (LET NIL # ...))" > 4 122 3.4 645 17.9 SB-BIGNUM::MAKE-GCD-BIGNUM-ODD > 5 100 2.8 745 20.7 SB-BIGNUM::BIGNUM-GCD-ORDER-AND-SUBTRACT > 6 96 2.7 841 23.4 "XEP for #'(SB-KERNEL:INSTANCE-LAMBDA (SB-PCL::.ARG0. SB-PCL::.ARG1. SB-PCL::.ARG2. ...) (LET NIL # ...))" > 7 95 2.6 936 26.0 SB-KERNEL::%%TYPEP > 8 89 2.5 1025 28.5 SB-BIGNUM::BIGNUM-BUFFER-ASHIFT-RIGHT > 9 88 2.4 1113 31.0 SB-KERNEL:TWO-ARG-+ > 10 81 2.3 1194 33.2 SB-KERNEL:CLASSOID-TYPEP Here are some more numbers, from profiling (with the regular profiler) all functions in gsharp's own packages (but not CLIM or X-related ones). seconds | consed | calls | sec/call | name ------------------------------------------------------------- 39.229 | 550,292,048 | 1 | 39.229393 | GSHARP::RUN-GSHARP 17.950 | 42,999,328 | 23,237 | 0.000772 | SCORE-PANE::MAKE-PIXMAP-RECORD 16.849 | 36,449,032 | 21,135 | 0.000797 | SCORE-PANE::MAKE-RECTANGLE-RECORD 7.168 | 32,446,368 | 21,135 | 0.000339 | SCORE-PANE::ADD-NEW-RECTANGLE-RECORD 6.644 | 8,482,896 | 32,962 | 0.000202 | SCORE-PANE::MEDIUM-DRAW-NOTEHEAD 6.269 | 11,886,152 | 10,366 | 0.000605 | SCORE-PANE::DRAW-SEGMENT 5.188 | 8,387,400 | 25,310 | 0.000205 | SCORE-PANE::MEDIUM-DRAW-STEM 4.645 | 6,632,224 | 23,237 | 0.000200 | SCORE-PANE::ADD-NEW-PIXMAP-RECORD Some of the blame might lie in gsharp's MAKE-PIXMAP-RECORD and MAKE-RECTANGLE-RECORD: the way they're written inhibits a CLOS optimization: if make-instance sees a constant class name and constant initargs, and there are no applicable methods on (setf slot-value-using-class), then a certain amount of heavyweight dispatch can be avoided. However, given the statistical profiling results indicating that bignums or ratios were the bottleneck, this is likely only to be a side issue. I think I'd investigate the medium transformation, and the various coordinates associated with pixmaps and rectangles, and see if any of those are overly precise... Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From csr21 at cam.ac.uk Mon Jul 19 21:19:49 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 19 Jul 2004 22:19:49 +0100 Subject: [gsharp-devel] redraw buglets In-Reply-To: (Christophe Rhodes's message of "Mon, 19 Jul 2004 21:25:49 +0100") References: <16631.51270.435861.734391@serveur5.labri.fr> <16635.64263.922685.150911@serveur5.labri.fr> Message-ID: Christophe Rhodes writes: > I think I'd investigate the medium transformation, and the various > coordinates associated with pixmaps and rectangles, and see if any of > those are overly precise... Just to complete the numbers game, here are the corresponding numbers from profiling the CLIM package. seconds | consed | calls | sec/call | name ---------------------------------------------------------- 8.523 | 133,017,776 | 7,759 | 0.001098 | CLIM:MAP-OVER-OUTPUT-RECORDS-CONTAINING-POSITION 6.803 | 44,869,448 | 43,507 | 0.000156 | CLIM:MEDIUM-COPY-AREA 5.506 | 39,841,728 | 34,718 | 0.000159 | CLIM:MEDIUM-DRAW-RECTANGLE* 3.884 | 19,107,904 | 1,176,740 | 0.000003 | CLIM:BOUNDING-RECTANGLE* 3.242 | 10,677,496 | 38,690 | 0.000084 | CLIM:RECOMPUTE-EXTENT-FOR-NEW-CHILD 2.508 | 22,934,944 | 1,578 | 0.001589 | CLIM:MAP-OVER-OUTPUT-RECORDS 2.117 | 22,808,984 | 23,576 | 0.000090 | CLIM:MEDIUM-DRAW-POLYGON* 1.959 | 6,110,184 | 318,672 | 0.000006 | CLIM:TRANSFORM-POSITION 1.863 | 20,153,984 | 853,925 | 0.000002 | CLIM:OUTPUT-RECORD-HIT-DETECTION-RECTANGLE* 1.559 | 16,228,992 | 65,700 | 0.000024 | CLIM:MAKE-POINT 1.320 | 7,892,200 | 41,145 | 0.000032 | CLIM:MAKE-TRANSFORMATION 1.198 | 4,285,880 | 39,637 | 0.000030 | CLIM:MAKE-TRANSLATION-TRANSFORMATION 1.148 | 2,364,112 | 94,554 | 0.000012 | CLIM:REGION-SET-REGIONS 1.114 | 5,448,184 | 38,690 | 0.000029 | CLIM:ADD-OUTPUT-RECORD All the best, Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From strandh at labri.fr Tue Jul 20 05:55:21 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 20 Jul 2004 07:55:21 +0200 Subject: [gsharp-devel] redraw buglets In-Reply-To: References: <16631.51270.435861.734391@serveur5.labri.fr> <16635.64263.922685.150911@serveur5.labri.fr> Message-ID: <16636.46025.365078.272276@serveur5.labri.fr> Christophe Rhodes writes: > I had a look at sbcl's own routines, and it turns out that there is > currently (and probably in sbcl-0.8.13, due out soon, but probably not > in sbcl-0.8.13.1) a large avoidable inefficiency in SBCL's (and I > believe also CMUCL's) BIGNUM-GCD. Please tell me more. I had a look at the code, and at least it seems that you are using the fast algorithm that only needs shifts and subtractions. > I'm working on patching the system, > and I'll report back once I have some numbers. Thanks. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Tue Jul 20 06:07:01 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 20 Jul 2004 08:07:01 +0200 Subject: [gsharp-devel] redraw buglets In-Reply-To: References: <16631.51270.435861.734391@serveur5.labri.fr> <16635.64263.922685.150911@serveur5.labri.fr> Message-ID: <16636.46725.101460.225782@serveur5.labri.fr> Christophe Rhodes writes: > > Still really bignum-gcd dominated, I'm afraid. Your hypothesis about > McCLIM coordinates is certainly possible... I took a better look at this, and found that it is not at all the Gsharp measure computation that takes time. In fact, for C-f and C-b, it is not even invoked, and even when it is, it is very fast. So that is good news. The time spent in drawing routines. Looking at the low-level CLIM code, a lot of time is, as you pointed out, spent in map-over-output-records-containing-position. In fact, on my machine, doing C-f 50 times, gives almost 10 seconds in this function, for a total of 3000 calls or so. Tim will correct me if I am wrong, but I suspect this is because compound output records are only sequential at the moment. The Gsharp score pane should have a smarter organization of output records that takes into account the layout of printed music on a page. In other words, it may not be worth more time (as far as Gsharp is concerned) optimizing GCD, even though that is a good thing in general, since the solution is to do something smarter in the score pane. It seems more and more plausible to me that getting the score pane right is high priority: it is needed to get better performance, it is crucial in terms of modularity, and it is needed by others (the OpenMusic project at IRCAM). -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Tue Jul 20 06:16:43 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 20 Jul 2004 08:16:43 +0200 Subject: [gsharp-devel] redraw buglets In-Reply-To: References: <16631.51270.435861.734391@serveur5.labri.fr> <16635.64263.922685.150911@serveur5.labri.fr> Message-ID: <16636.47307.28119.835152@serveur5.labri.fr> Christophe Rhodes writes: > Some of the blame might lie in gsharp's MAKE-PIXMAP-RECORD and > MAKE-RECTANGLE-RECORD: I see. Again, the problem is in the score pane. These should be fairly easy to fix, I think. > However, given the statistical profiling > results indicating that bignums or ratios were the bottleneck, this is > likely only to be a side issue. Perhaps. In any case, if the output recording of the score pane avoids linear behavior, I think the problem will go away. > I think I'd investigate the medium transformation, and the various > coordinates associated with pixmaps and rectangles, and see if any of > those are overly precise... That might improve things, but (as is often the case) improving the high-level algorithm is going to be an order of magnitude more spectacular. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Tue Jul 20 06:24:42 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 20 Jul 2004 08:24:42 +0200 Subject: [gsharp-devel] redraw buglets In-Reply-To: References: <16631.51270.435861.734391@serveur5.labri.fr> <16635.64263.922685.150911@serveur5.labri.fr> Message-ID: <16636.47786.338577.445921@serveur5.labri.fr> Christophe Rhodes writes: > Christophe Rhodes writes: > > Just to complete the numbers game, here are the corresponding numbers > from profiling the CLIM package. > > 6.803 | 44,869,448 | 43,507 | 0.000156 | CLIM:MEDIUM-COPY-AREA > 5.506 | 39,841,728 | 34,718 | 0.000159 | CLIM:MEDIUM-DRAW-RECTANGLE* Those would be hard to avoid, other than with incremental redisplay, since they are the ones that put the various music symbols where they should go. > 3.884 | 19,107,904 | 1,176,740 | 0.000003 | CLIM:BOUNDING-RECTANGLE* > 3.242 | 10,677,496 | 38,690 | 0.000084 | CLIM:RECOMPUTE-EXTENT-FOR-NEW-CHILD > 2.508 | 22,934,944 | 1,578 | 0.001589 | CLIM:MAP-OVER-OUTPUT-RECORDS These will likely disappear if output recording is done better. > 2.117 | 22,808,984 | 23,576 | 0.000090 | CLIM:MEDIUM-DRAW-POLYGON* This has to do with beam drawing, I think. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Tue Jul 20 06:41:55 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 20 Jul 2004 08:41:55 +0200 Subject: [gsharp-devel] redraw buglets In-Reply-To: <16636.47307.28119.835152@serveur5.labri.fr> References: <16631.51270.435861.734391@serveur5.labri.fr> <16635.64263.922685.150911@serveur5.labri.fr> <16636.47307.28119.835152@serveur5.labri.fr> Message-ID: <16636.48819.477837.35242@serveur5.labri.fr> Robert Strandh writes: > Christophe Rhodes writes: > > Some of the blame might lie in gsharp's MAKE-PIXMAP-RECORD and > > MAKE-RECTANGLE-RECORD: > > I see. Again, the problem is in the score pane. These should be > fairly easy to fix, I think. > > > However, given the statistical profiling > > results indicating that bignums or ratios were the bottleneck, this is > > likely only to be a side issue. > > Perhaps. In any case, if the output recording of the score pane > avoids linear behavior, I think the problem will go away. I take that back. These will be called the same number of times independently of the organization of output records. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From csr21 at cam.ac.uk Tue Jul 20 08:21:24 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 20 Jul 2004 09:21:24 +0100 Subject: [gsharp-devel] redraw buglets In-Reply-To: <16636.46025.365078.272276@serveur5.labri.fr> (Robert Strandh's message of "Tue, 20 Jul 2004 07:55:21 +0200") References: <16631.51270.435861.734391@serveur5.labri.fr> <16635.64263.922685.150911@serveur5.labri.fr> <16636.46025.365078.272276@serveur5.labri.fr> Message-ID: Robert Strandh writes: > Christophe Rhodes writes: > > I had a look at sbcl's own routines, and it turns out that there is > > currently (and probably in sbcl-0.8.13, due out soon, but probably not > > in sbcl-0.8.13.1) a large avoidable inefficiency in SBCL's (and I > > believe also CMUCL's) BIGNUM-GCD. > > Please tell me more. I had a look at the code, and at least it seems > that you are using the fast algorithm that only needs shifts and > subtractions. Yes. It wasn't an algorithmic issue, but a type issue: the definition of the bignum-index type (a number that is a word-index into a bignum) was wrong: its upper bound was 2^29-1 rather than 2^24-1. This then caused efficiency problems when computing a bit index: since we have to multiply by 32, the compiler had to use generic arithmetic as the upper bound becomes 2^34-32. (This is clearly nonsense, because the machine only has 2^32 bits of addressable memory, so has no way of representing a bignum with 2^34 bits :-). However, as I say, the improvement is fairly negligible. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From strandh at labri.fr Tue Jul 20 09:57:47 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 20 Jul 2004 11:57:47 +0200 Subject: [gsharp-devel] Architecture question In-Reply-To: <6C31E2FC-DA31-11D8-AACB-000A959839F8@labri.fr> References: <16635.63688.209513.391256@serveur5.labri.fr> <6C31E2FC-DA31-11D8-AACB-000A959839F8@labri.fr> Message-ID: <16636.60571.505337.391089@serveur5.labri.fr> Timothy MOORE writes: > > Presumably the score pane knows how to render scores. A score is a > collection of objects that follow a "score protocol" that is, have some > semantics for functions that "do stuff" with scores. I kind of don't think so. The reason is that a real score is much more than what is visible in a score pane. It is therefore convenient to define what is visible in a score pane as a different kind of object from that which is managed by the score editor. Also, you do not want to put too much semantics into a score pane object, because different applications might want to do different things with it. > Right, but these seem a bit more like protocol classes than > presentation types to me. That is, the score pane will handle the > rendering of the entire score and do the right thing when it finds > clefs, noteheads, etc. Again, I am not sure. If you build all that into the score pane, you no longer have a free choice of which application you want to write. > I don't imagine that a "client" of a score pane > would write (present x 'notehead). Why not? > On the other hand, the presentation > type 'notehead does make sense for input; if the score pane rendering > code has recorded the presentation type of each interesting object with > with-output-as-presentation, then these types will be available to the > commands of the client code. Yes. > You can make these types disjoint from Gsharp types if you want but, I have the feeling that that is what I want, but I am not sure. > like I said, these make sense to me as protocol superclasses inherited > by the concrete Gsharp classes. Hmmm. That would mean that the internal data structure assumes the existence of a GUI. I am not sure that is a good idea. > Right; use-package should never be mandatory for a client. I wouldn't > worry too much about choosing a short package nickname for your > package; after all, that might conflict with a nickname in the client's > system, which is a far more painful problem to work around than > individual symbol conflicts. Good point. > The client should be free to use a package > if they want, import individual symbols, use the package name > explicitly, or "adopt" the external symbols into a package of their own > with a short nickname, if they really want that. Agreed. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From csr21 at cam.ac.uk Tue Jul 20 10:07:22 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 20 Jul 2004 11:07:22 +0100 Subject: [gsharp-devel] Architecture question In-Reply-To: <16635.63688.209513.391256@serveur5.labri.fr> (Robert Strandh's message of "Mon, 19 Jul 2004 18:37:28 +0200") References: <16635.63688.209513.391256@serveur5.labri.fr> Message-ID: Robert Strandh writes: > The score-pane is supposed to be reusable in other programs that need > to display scores. For that reason, the score pane should not know > about the internal data structures of Gsharp, nor about its GUI. It may not need to know about the internal data structures of Gsharp, but it will in that case have to have some internal data structures of its own. There is, as far as I can tell, no way of having a score pane in any meaningful sense without some understanding of what a musical score is and how one would lay one out. Whether this is achieved by a score-pane datastructure, into which clients of the pane should force their own data for display, or by defining protocols (so that, say, one defines a read-sequence or equivalent operation on some stream, say a stream of midi events, and various functions are responsible for constructing a data structure), is unclear: but if you don't have any knowledge of what a score is in a score-pane then a score-pane doesn't look terribly different from just a blank canvas. In other words, I think that if a score-pane is to be useful it must make some assumptions, have some representation, for what it's going to display. I can't see any viable alternatives (a sequence of PRESENT commands on individual atoms fails immediately because music is not one-dimensional). Does OpenMusic (or any non-Gsharp project) have a use case yet? It's hard to build the right kind of generality without any kind of use case at all... Cheers, Christophe [ What /is/ the status of the OpenMusic work? I've been trying to find out... ] -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From strandh at labri.fr Tue Jul 20 11:39:18 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 20 Jul 2004 13:39:18 +0200 Subject: [gsharp-devel] Architecture question In-Reply-To: References: <16635.63688.209513.391256@serveur5.labri.fr> Message-ID: <16637.1126.951778.549834@serveur5.labri.fr> Christophe Rhodes writes: > Robert Strandh writes: > > > The score-pane is supposed to be reusable in other programs that need > > to display scores. For that reason, the score pane should not know > > about the internal data structures of Gsharp, nor about its GUI. > > It may not need to know about the internal data structures of Gsharp, > but it will in that case have to have some internal data structures of > its own. Right, but that internal structure could be entirely dedicated to the way things are drawn. > There is, as far as I can tell, no way of having a score pane in any > meaningful sense without some understanding of what a musical score is > and how one would lay one out. Whether this is achieved by a > score-pane datastructure, into which clients of the pane should force > their own data for display, or by defining protocols (so that, say, > one defines a read-sequence or equivalent operation on some stream, > say a stream of midi events, and various functions are responsible for > constructing a data structure), is unclear: but if you don't have any > knowledge of what a score is in a score-pane then a score-pane doesn't > look terribly different from just a blank canvas. I think you need an idea of what a PRINTED score is. You need to know about where and how various music signs are presented (nu pun intended). I just do not think it is a good idea to force into the score pane the fact that music is structured in layers, segments, etc., the way Gsharp does it. > In other words, I think that if a score-pane is to be useful it must > make some assumptions, have some representation, for what it's going > to display. I can't see any viable alternatives (a sequence of > PRESENT commands on individual atoms fails immediately because music > is not one-dimensional). I am not so convinced that it fails. For one thing, I think it would be the job of the score pane to know in which order things should be redisplayed, to know about staff steps, to know how to beam one stem to the other perhaps, etc. > Does OpenMusic (or any non-Gsharp project) have a use case yet? It's > hard to build the right kind of generality without any kind of use > case at all... I don't know about OpenMusic or any other project. I am just imagining the protocol to be used by a different application that would like to display music. > [ What /is/ the status of the OpenMusic work? I've been trying to > find out... ] I don't know. I was supposed to meet one of the authors at the last notation meeting in Lyon, but he did not show up, supposedly for lack of funding. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Wed Jul 21 10:16:21 2004 From: strandh at labri.fr (Robert Strandh) Date: Wed, 21 Jul 2004 12:16:21 +0200 Subject: [gsharp-devel] Architecture question In-Reply-To: <16637.1126.951778.549834@serveur5.labri.fr> References: <16635.63688.209513.391256@serveur5.labri.fr> <16637.1126.951778.549834@serveur5.labri.fr> Message-ID: <16638.17013.827278.195129@serveur5.labri.fr> I think I see more clearly now. It seems feasible for the score pane to define a bunch of presentation types, such as this: (define-presentation-type clef () :options (name x staff-step)) (define-presentation-method present (object (type clef) stream (view score-view) &key acceptably for-context-type) (declare (ignore acceptably for-context-type)) (with-output-as-presentation (stream object 'clef) (draw-clef stream name x staff-step))) (define-presentation-method present (object (type clef) stream (view textual-view) &key acceptably for-context-type) (declare (ignore acceptably for-context-type)) (format stream "[~a clef on staff step ~a]" name staff-step)) and for client code to draw using calls such as this: (present (clef staff) `((score-pane:clef) :name ,(name (clef staff)) :x ,(+ x1 10) :staff-step ,(lineno (clef staff))) :stream pane) It would also be nice to define a hierarchy of presentations. For instance, there might be a presentation type `staff' and the presentation types like `clef' would accept an argument that indicates to which staff the objects belong. Client code would look like this: (present 1 ((score-pane:system) :x 100 :y 100) :stream pane) (present mystaff `((score-pane:staff :system 1 :y 10 ;relative to the top of the system :type :fiveline)) :stream pane) (present (clef staff) `((score-pane:clef) :staff mystaff :name :bass :x 10 ; relative to the left edge of the staff :staff-step 6) :stream pane) The score pane would compare client objects using (say) eql (so as to allow for integers) and establish relationships Question: would it be necessary for client code to sometimes just draw things without presenting them? I kind of think so. It would then be nice to be able to reuse the presentation types in a draw function as opposed to the current system with draw-??? functions. In that case, could that be a different presentation generic function, which would have the strange behavior of not creating presentations. Or should it just be a different view for present, say draw-view that has draws without presenting: (present mystaff `((score-pane:staff :system 1 :y 10 ;relative to the top of the system :type :fiveline)) :stream pane :view score-pane:draw-view) Comments? -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Wed Jul 21 11:36:40 2004 From: strandh at labri.fr (Robert Strandh) Date: Wed, 21 Jul 2004 13:36:40 +0200 Subject: [gsharp-devel] Architecture question In-Reply-To: <16638.17013.827278.195129@serveur5.labri.fr> References: <16635.63688.209513.391256@serveur5.labri.fr> <16637.1126.951778.549834@serveur5.labri.fr> <16638.17013.827278.195129@serveur5.labri.fr> Message-ID: <16638.21832.188442.684053@serveur5.labri.fr> Robert Strandh writes: > (define-presentation-method present (object > (type clef) > stream > (view textual-view) > &key acceptably for-context-type) > (declare (ignore acceptably for-context-type)) > (format stream "[~a clef on staff step ~a]" name staff-step)) The presentation method for textual view should probably go in the client. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Sat Jul 24 07:34:04 2004 From: strandh at labri.fr (Robert Strandh) Date: Sat, 24 Jul 2004 09:34:04 +0200 Subject: [gsharp-devel] The good, the bad, and the truly ugly Message-ID: <16642.4332.578494.508769@serveur5.labri.fr> Hello, I figured I should write down my impression with regard to my latest updates of Gsharp before I forget. My concept of what the score pane should do seems to become clearer. The latest modifications seem to confirm this. The score pane should define drawing functions and presentation types for visual music material. It should also define presentation methods for `present' on those types, but only for the `score-view'. The textual view should be done by the application. Ultimately, it should organize output records so that they can be redisplayed in the right order, substitute glyphs in stacks of notes, etc. I tried making note heads into presentations, but that slowed it down by a factor 2-3, which quickly became intolerable for an entire page of music such as rapsoden-sjunger.gsh. When and if this gets faster, I will attempt it again. Highlighting staves does not change its appearance, because the bounding box is already black on display. It would be nice to be able to alter the highlighting. It would also be nice to have pointer documentation (perhaps this already works) in the form of pop-up windows that appear when the pointer is over a presentation (name of the staff). The new keyboard command structure seems to work pretty well. Now, we can use a list of sequence dictionaries in which to search for associated commands of a sequence of keys or to determine whether the sequence of keys is a prefix of an existing command. This will allow us to have lists of `modes', each reflected by a sequence dictionary. The order of the dictionaries reflect a priority, so that dictionaries early in the list override the following ones. I am planning to use this to factor out key sequences such as #\a, #\b, etc to insert characters in lyrics mode and clusters in melody mode. Ultimately, it seems like this stuff should be part of McCLIM, since many applications will need it (Goatee, Phemlock, Gsharp, etc.). That would require some additional thinking about appropriate protocols. The drawing part (drawing.lisp) held up pretty well, even though there is some ugliness in the dynamic mixin classes to get the x coordinates right. Some refactoring would be good. The abstract data type (buffer.lisp) is a mess. I am sure there is some design pattern in there that I did not respect, because there is now tons of code duplication. There are now two different kinds of layers, of slices, of bars, and of elements (lyrics and melody). Many, but not all of the operations are common, so should be factored. Creation is a mess though (use a factory?). There is duplication for each type. Before adding percussion (another layer type), the current code must be improved. I figured lyrics should be Unicode (I am reading up on this, but I am still a novice) strings (which I now represent as arrays of fixnums). Of course, that is a huge topic in itself. I just put in whatever was needed as proof of concepts. The entire thing should probably be factored out anyway (and again be part of McCLIM, I guess) since many applications will need it. In the immediate future, there would be some joint work with Phemlock, since I imaging its buffers containing Unicode (as some of us discussed at the LSM/RMLL). Unicode support also raises the question of input methods, i.e., what does one type on the keyboard in order to produce a certain Unicode character. This is another issue not directly related to Gsharp. For the rendering part, there must be some existing stuff out there, though perhaps not in Common Lisp. GNU Emacs regularly shows me email with oriental characters in it. As I wrote, currently, I represent Unicode strings as arrays of fixnums. These arrays should be encapsulated in CLOS classes with their own protocols so that the representation can change in the future. There is some code duplication in the `accept' presentation methods for the textual view, but I am not too worried about it, since I suspect it is a simple matter of writing a few function and macros to factor out the entire thing. There are some patterns that are repeated frequently: choose (and complete) from list, and it has to be in the list (clef type, staff type); choose (and complete) from list, but anything is acceptable (file names, create a new file if it is an unknown file); choose a string that must not be a member of a given set (creating unique layer names and buffer names). Those patterns could probably be captured in functions or macros. At some point, I need to read up some more on the `accept' presentation method. I would like to be able to type `return' at the prompt asking for a layer, and automatically get the current one. There are probably some similar situation to occur in the future. Slime failed on me several times. In some cases, it (correctly) reported errors that were very hard to get out of, and once I got out, I got a different family of errors relating to X11, again hard to get out of. I found myself frequently having to quit Emacs, and restart the entire process. Perhaps it had to do with the particular kind of problems that occurred, but at this point I am not sure I can characterize them. Have a nice weekend, -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From csr21 at cam.ac.uk Mon Jul 26 12:17:55 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 26 Jul 2004 13:17:55 +0100 Subject: [gsharp-devel] Occasional type errors from CLX Message-ID: Hi, I'm not certain that this is a uniquely gsharp error... however: On starting up I sometimes get a type error of the form: debugger invoked on a TYPE-ERROR in thread 5361: The value # is not of type (OR (MEMBER :POINTER-ROOT :NONE) XLIB:WINDOW). from XLIB:SET-INPUT-FOCUS called, I think, from the (:EXPOSURE :DISPLAY) clause of McCLIM's CLX backend EVENT-HANDLER. My suspicion lands on gsharp rather than general McCLIM because of the following detail in WITH-SCORE-PANE: (defmacro with-score-pane (pane &body body) (let ((pixmap (gensym)) (mirror (gensym))) `(let* ((*pane* ,pane) (*lighter-gray-progressions* (lighter-gray-progressions pane)) (*darker-gray-progressions* (darker-gray-progressions pane)) (,pixmap (allocate-pixmap *pane* 800 900)) (,mirror (sheet-direct-mirror *pane*))) (draw-rectangle* ,pixmap 0 0 800 900 :filled t :ink +white+) (setf (sheet-direct-mirror *pane*) (climi::pixmap-mirror ,pixmap)) (clear-output-record (stream-output-history *pane*)) (with-translation (pane 0 900) (with-scaling (pane 1 -1) , at body)) (setf (sheet-direct-mirror *pane*) ,mirror) (copy-from-pixmap ,pixmap 0 0 800 900 *pane* 0 0) (deallocate-pixmap ,pixmap)))) During the body of this, we appear to have set the mirror of *pane* to something which is a CLX pixmap: which isn't (I guess: I do not speak from authority here) a window. Since we're using climi::pixmap-mirror, my suspicion is that this is a no-no. I have to ask, though, what was this for? Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From strandh at labri.fr Mon Jul 26 12:44:52 2004 From: strandh at labri.fr (Robert Strandh) Date: Mon, 26 Jul 2004 14:44:52 +0200 Subject: [gsharp-devel] Occasional type errors from CLX In-Reply-To: References: Message-ID: <16644.64708.691708.515007@serveur5.labri.fr> Christophe Rhodes writes: > Hi, > > I'm not certain that this is a uniquely gsharp error... however: > > On starting up I sometimes get a type error of the form: > debugger invoked on a TYPE-ERROR in thread 5361: > The value # > is not of type > (OR (MEMBER :POINTER-ROOT :NONE) XLIB:WINDOW). > from XLIB:SET-INPUT-FOCUS called, I think, from the (:EXPOSURE > :DISPLAY) clause of McCLIM's CLX backend EVENT-HANDLER. > > My suspicion lands on gsharp rather than general McCLIM because of the > following detail in WITH-SCORE-PANE: > (defmacro with-score-pane (pane &body body) > (let ((pixmap (gensym)) > (mirror (gensym))) > `(let* ((*pane* ,pane) > (*lighter-gray-progressions* (lighter-gray-progressions pane)) > (*darker-gray-progressions* (darker-gray-progressions pane)) > (,pixmap (allocate-pixmap *pane* 800 900)) > (,mirror (sheet-direct-mirror *pane*))) > (draw-rectangle* ,pixmap 0 0 800 900 :filled t :ink +white+) > (setf (sheet-direct-mirror *pane*) (climi::pixmap-mirror ,pixmap)) > (clear-output-record (stream-output-history *pane*)) > (with-translation (pane 0 900) > (with-scaling (pane 1 -1) > , at body)) > (setf (sheet-direct-mirror *pane*) ,mirror) > (copy-from-pixmap ,pixmap 0 0 800 900 *pane* 0 0) > (deallocate-pixmap ,pixmap)))) > During the body of this, we appear to have set the mirror of *pane* to > something which is a CLX pixmap: which isn't (I guess: I do not speak > from authority here) a window. Since we're using > climi::pixmap-mirror, my suspicion is that this is a no-no. I have to > ask, though, what was this for? This is the double buffering that avoids flickering. As you have noticed, this solution is not quite kosher (or "catholic" depending on the country you are in). Do you know a better way of doing it? -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------