From strandh at labri.fr Mon Feb 16 15:39:26 2004 From: strandh at labri.fr (Robert STRANDH) Date: Mon, 16 Feb 2004 16:39:26 +0100 (CET) Subject: [gsharp-devel] web page Message-ID: <20040216153926.699512B10A@serveur5.labri.fr> We have a web page: http://www.common-lisp.net/project/gsharp/ Comments are welcome. -- 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 Feb 16 21:31:57 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 16 Feb 2004 21:31:57 +0000 Subject: [gsharp-devel] Initial thoughts Message-ID: Hi, all. My first initial thought, after fixing the remaining sbcl-related buglets, was "wow, this is a lot faster!" I presume this is because of the change to the redisplay code -- is it not redisplaying some pane or other in certain cases? Anyway, that's much appreciated. My personal interest is in being able to engrave and "perform" Renaissance and Baroque music, usually but not exclusively including vocal lines. There are various obvious missing things that spring to mind that are necessary to deal with this repertoire: lyrics, figures (for figured bass and for time-signature changes), various ornaments and other glyphs, and of course beamed semiquavers... I thought a simple first project that I might look at is some way of dealing with triplets, which would hopefully be extensible to septemdecaplets and the like should our contemporary brethren find the need. I have also been spending some time recently in a computational music department (at City University in London), where I showed the 0.2 release to a couple of people. The response was promising; I think they appreciate the possibilities both of the dynamic environment and of the UI framework. One thing that came up was that it would be very nice to have something analogous to emacs' keyboard macros. As a simple example of why this would be nice: consider entering a part consisting of repeated dotted-quaver/semiquaver figures like: _____ _____ _____ _____ | _| | _| | _| | _| | | | | | | | | | | | | | | | | @ . @ @ . @ @ . @ @ . @ This is an absolute pain to enter in current state-of-the-art (and also not state-of-the-art but more academically-inclined) notation packages: after each note, the input state needs to change. One viable method for doing this with less pain would be to enter the part in straight quavers, and then record and repeat a keyboard macro to alter the elements in sequence. In case this isn't clear, try (in emacs, in a sacrificial buffer with stuff in it) the effect of C-x ( C-a ( C-e ) C-f C-x ) C-x e C-x e C-x e 100 C-x e to see the analogy. Whether this keyboard macro facility wants to record gestures (keystrokes) or commands, I don't know -- does anyone know what emacs does? Probably both in various circumstances. :-) Speaking of keystrokes, there appears to be a McCLIM issue, or at least a justified confusion, over treatment of the shift modifier. Whereas in keystrokes such as Shift-Escape it makes sense to treat the modifier key as a real modifier, it doesn't in keystrokes such as Shift-#. I cannot type Shift-# on my keyboard, because on a UK keyboard it's unshifted, just to the left of Return; on the other hand, on a US keyboard, it's shifted on the 3 key. Should we workaround by adding both shifted and unshifted versions to the command tables, or is there an easy resolution in McCLIM? Those are some of my initial ideas, anyway. Looks fun! 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 Feb 17 05:27:17 2004 From: strandh at labri.fr (Robert STRANDH) Date: Tue, 17 Feb 2004 06:27:17 +0100 Subject: [gsharp-devel] Initial thoughts In-Reply-To: References: Message-ID: <16433.42549.673288.897129@serveur5.labri.fr> Hello, Christophe Rhodes writes: > > My first initial thought, after fixing the remaining sbcl-related > buglets, was "wow, this is a lot faster!" I presume this is because > of the change to the redisplay code -- is it not redisplaying some > pane or other in certain cases? Anyway, that's much appreciated. I suspect it is because Tim made som improvements to the handling of output records in McCLIM. There is still a slight pause when displaying the entire page from "rapsoden-sjunger.gsh" that I would like to improve on at some point. > My personal interest is in being able to engrave and "perform" > Renaissance and Baroque music, usually but not exclusively including > vocal lines. There are various obvious missing things that spring to > mind that are necessary to deal with this repertoire: lyrics, figures > (for figured bass and for time-signature changes), various ornaments > and other glyphs, Right. There are literally hundreds of minor things and dozens of major things that need to be added. It is mostly just a matter of doing one at a time. Some of these things might require some discussion with regard to design, i.e. how and where to do it. > and of course beamed semiquavers... Right. > I thought a > simple first project that I might look at is some way of dealing with > triplets, which would hopefully be extensible to septemdecaplets and > the like should our contemporary brethren find the need. These are useful (and somewhat hard) things to handle. It will not be too hard to make Gsharp understand triplets and the like, but getting the display code to show them with the right spacing might be tricky. The people who developed the Lime score editor wrote something about that in an article that I can no longer find. > I have also been spending some time recently in a computational music > department (at City University in London), where I showed the 0.2 > release to a couple of people. How embarrassing. I have not dared showing it to a musician or a composer yet. Somehow, they appreciate only features and not basic design principles. > The response was promising; What a nice surprise. > I think > they appreciate the possibilities both of the dynamic environment and > of the UI framework. One thing that came up was that it would be very > nice to have something analogous to emacs' keyboard macros. Should be fairly easy to put in. > As a simple example of why this would be nice: consider entering a > part consisting of repeated dotted-quaver/semiquaver figures like: > _____ _____ _____ _____ > | _| | _| | _| | _| > | | | | | | | | > | | | | | | | | > @ . @ @ . @ @ . @ @ . @ > > This is an absolute pain to enter in current state-of-the-art (and > also not state-of-the-art but more academically-inclined) notation > packages: after each note, the input state needs to change. Well, in Gsharp, it is slightly better. I would type this as: f.]f[[f.]f[[ with the input state on a quarter note (I am sorry, I can't remember the British English equivalents of "half note", "quarter note", etc). > One > viable method for doing this with less pain would be to enter the part > in straight quavers, and then record and repeat a keyboard macro to > alter the elements in sequence. In case this isn't clear, try (in > emacs, in a sacrificial buffer with stuff in it) the effect of > C-x ( C-a ( C-e ) C-f C-x ) C-x e C-x e C-x e 100 C-x e > to see the analogy. Right! In Gsharp, it would be something like C-x ( C-f ] . C-f [ [ C-x ) and then C-u 100 C-x e > Whether this keyboard macro facility wants to > record gestures (keystrokes) or commands, I don't know -- does anyone > know what emacs does? Probably both in various circumstances. :-) I don't think it matters really. The only situation where one could see the difference would be if keyboard bindings change between the definition and the invocation of a keyboard macro. > Speaking of keystrokes, there appears to be a McCLIM issue, or at > least a justified confusion, over treatment of the shift modifier. > Whereas in keystrokes such as Shift-Escape it makes sense to treat the > modifier key as a real modifier, it doesn't in keystrokes such as > Shift-#. I cannot type Shift-# on my keyboard, because on a UK > keyboard it's unshifted, just to the left of Return; on the other > hand, on a US keyboard, it's shifted on the 3 key. Matthias has the same problem on a French keyboard. > Should we > workaround by adding both shifted and unshifted versions to the > command tables, or is there an easy resolution in McCLIM? I think that would be a reasonable workaround. I thought of it myself last night, and I think it will be fine. > Those are some of my initial ideas, anyway. Looks fun! Fun and an endless source of inspiration and work. Though, this could be one of the "Killer Apps" needed to make Common Lisp more popular, especially since there is no real equivalent at the moment in the free-software community, and that such a thing would pretty much HAVE to be written in Lisp anyway. Bonne journ?e, -- 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 andras at renyi.hu Wed Feb 18 09:33:04 2004 From: andras at renyi.hu (Andras Simon) Date: Wed, 18 Feb 2004 10:33:04 +0100 (MET) Subject: [gsharp-devel] initial problems Message-ID: gsharp promises to be very very cool! And I think it was a good idea to transfer it to a visible place like common-lisp.net. I have some problems (probably McCLIM-related), such as not being able to answer prompts for, say, file names (I can type in a name but Enter doesn't seem to send it to gsharp). Also, menus that pop up for a right click don't quite work. Anyway, here's a small patch that I found absolutely necessary to get started. Andras Index: midi.lisp =================================================================== RCS file: /project/gsharp/cvsroot/gsharp/midi.lisp,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 midi.lisp *** midi.lisp 16 Feb 2004 15:46:18 -0000 1.1.1.1 --- midi.lisp 18 Feb 2004 08:58:44 -0000 *************** *** 114,120 **** (defmacro with-midi-output (filename &body body) "execute body with *midi-output* assigned to a stream from filename" `(with-open-file (*midi-output* ,filename ! :direction :output :element-type '(unsigned-byte 8)) , at body)) (defun read-variable-length-quantity () --- 114,120 ---- (defmacro with-midi-output (filename &body body) "execute body with *midi-output* assigned to a stream from filename" `(with-open-file (*midi-output* ,filename ! :direction :output :if-exists :supersede :element-type '(unsigned-byte 8)) , at body)) (defun read-variable-length-quantity () Index: sdl.lisp =================================================================== RCS file: /project/gsharp/cvsroot/gsharp/sdl.lisp,v retrieving revision 1.2 diff -c -r1.2 sdl.lisp *** sdl.lisp 16 Feb 2004 18:50:20 -0000 1.2 --- sdl.lisp 18 Feb 2004 08:58:45 -0000 *************** *** 1,7 **** (in-package :sdl) (defvar *fonts-directory* ! (merge-pathnames (make-pathname :directory '(relative "Fonts")) (make-pathname :directory (pathname-directory *load-truename*)))) (defgeneric glyph (font glyph-no)) --- 1,7 ---- (in-package :sdl) (defvar *fonts-directory* ! (merge-pathnames (make-pathname :directory '(:relative "Fonts")) (make-pathname :directory (pathname-directory *load-truename*)))) (defgeneric glyph (font glyph-no)) From csr21 at cam.ac.uk Wed Feb 18 10:04:54 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 18 Feb 2004 10:04:54 +0000 Subject: [gsharp-devel] initial problems In-Reply-To: (Andras Simon's message of "Wed, 18 Feb 2004 10:33:04 +0100 (MET)") References: Message-ID: Andras Simon writes: > Anyway, here's a small patch that I found absolutely necessary to get started. > ! :direction :output :element-type '(unsigned-byte 8)) > ! :direction :output :if-exists :supersede :element-type '(unsigned-byte 8)) Yes. This is sbcl, right? I'm still not entirely sure what to do about this; it's a change in sbcl's behaviour that I think is justified but isn't proving entirely popular. When I get back to my laptop (currently 50 miles away :) I'll fix it one way or the other, either by making sbcl be "more like other CLs" or by including this in gsharp. 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 andras at renyi.hu Wed Feb 18 10:35:03 2004 From: andras at renyi.hu (Andras Simon) Date: Wed, 18 Feb 2004 11:35:03 +0100 (MET) Subject: [gsharp-devel] initial problems In-Reply-To: References: Message-ID: On Wed, 18 Feb 2004, Christophe Rhodes wrote: > Andras Simon writes: > > > Anyway, here's a small patch that I found absolutely necessary to get started. > > > ! :direction :output :element-type '(unsigned-byte 8)) > > ! :direction :output :if-exists :supersede :element-type '(unsigned-byte 8)) > > Yes. This is sbcl, right? I'm still not entirely sure what to do > about this; it's a change in sbcl's behaviour that I think is > justified but isn't proving entirely popular. No, it's CMUCL 18e. But I don't see why this would be a problem with the CL implementation. with-midi-output should (I guess) say explitcitly that it wants to replace the midi file with the new one. But I may be missing something. Does load/save and other operations that need some text input work for the rest of you? I'm using McCLIM from CVS, and I wonder if I should downgrade to a stable version. Andras From csr21 at cam.ac.uk Wed Feb 18 10:52:19 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 18 Feb 2004 10:52:19 +0000 Subject: [gsharp-devel] initial problems In-Reply-To: (Andras Simon's message of "Wed, 18 Feb 2004 11:35:03 +0100 (MET)") References: Message-ID: Andras Simon writes: > No, it's CMUCL 18e. But I don't see why this would be a problem with the CL > implementation. with-midi-output should (I guess) say explitcitly that it > wants to replace the midi file with the new one. But I may be missing > something. OK. > Does load/save and other operations that need some text input work for the > rest of you? I'm using McCLIM from CVS, and I wonder if I should downgrade to > a stable version. It has worked for me (with CVS McCLIM/CVS SBCL). It's possible that #\Space is the gesture for ending a command, not #\Return? I have definitely loaded and saved gsharp buffers, created new staves with names, and so on. 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 andras at renyi.hu Wed Feb 18 11:11:49 2004 From: andras at renyi.hu (Andras Simon) Date: Wed, 18 Feb 2004 12:11:49 +0100 (MET) Subject: [gsharp-devel] initial problems In-Reply-To: References: Message-ID: On Wed, 18 Feb 2004, Christophe Rhodes wrote: > > Does load/save and other operations that need some text input work for the > > rest of you? I'm using McCLIM from CVS, and I wonder if I should downgrade to > > a stable version. > > It has worked for me (with CVS McCLIM/CVS SBCL). It's possible that > #\Space is the gesture for ending a command, not #\Return? I have > definitely loaded and saved gsharp buffers, created new staves with > names, and so on. Great! If I end the command with space, I don't get a separate input field (or whatever it's called in CLIMese) with gray background and Exit/Abort options, but can continue to type 'in-line' and then send the whole thing (command + argument) with return. Thanks! Andras From andras at renyi.hu Wed Feb 18 12:08:47 2004 From: andras at renyi.hu (Andras Simon) Date: Wed, 18 Feb 2004 13:08:47 +0100 (MET) Subject: [gsharp-devel] initial problems In-Reply-To: References: Message-ID: On Wed, 18 Feb 2004, Timothy MOORE wrote: > The missing arguments dialog i.e., "the separate input field", should > work too. If there's a problem with that I'd like to know about it. What happens is that hitting Return in the input field seems to have no effect except that makes it stop accepting more input. The Exit/Abort labels are not mouse sensitive (I have the feeling they should be), and clicking with the right button pops up a menu that is only a few pixel tall. (Right click in the score pane on the other hand pops up menus where the items are hidden by random black spots.) BTW there are a few compilation problems with McCLIM, e.g. CMUCL18e (last December snapshot) complains about declaring +contrasting-colors+ special in make-contrasting-inks in design.lisp. But I guess I should report these on the McCLIM list. Andras From strandh at labri.fr Thu Feb 19 06:01:27 2004 From: strandh at labri.fr (Robert STRANDH) Date: Thu, 19 Feb 2004 07:01:27 +0100 Subject: [gsharp-devel] initial problems In-Reply-To: References: Message-ID: <16436.20791.299218.594731@serveur5.labri.fr> Andras Simon writes: > gsharp promises to be very very cool! Thanks! > And I think it was a good idea to > transfer it to a visible place like common-lisp.net. Yeah. I tried in vain to get the sysadmins to set up a pserver here. > Anyway, here's a small patch that I found absolutely necessary to get started. Thanks. This should be corrected now. -- 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 Feb 23 14:52:28 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 23 Feb 2004 14:52:28 +0000 Subject: [gsharp-devel] web page In-Reply-To: <20040216153926.699512B10A@serveur5.labri.fr> (Robert STRANDH's message of "Mon, 16 Feb 2004 16:39:26 +0100 (CET)") References: <20040216153926.699512B10A@serveur5.labri.fr> Message-ID: Robert STRANDH writes: > We have a web page: > > http://www.common-lisp.net/project/gsharp/ > > Comments are welcome. It looks good. One comment is that, despite the "Valid XHTML 1.0 Strict" claim at the bottom of the page, it's not valid XHTML 1.0 Strict. I suggest deleting the claim :-). One thing that might be worthwhile is a bibliography, either on the page or in the documentation, so that aspiring gsharp hackers can read up on current best practice for engraving, at least. I suppose it's possible that there are useful links at one remove from projects such as Lilypond, Common Lisp Music/Common Music Notation, and the like. might be a start. (On the subject of web presence, people may be interested in , and in particular the before/after screenshots, and the description of the use of the keyboard macro.) 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 Feb 23 16:52:03 2004 From: strandh at labri.fr (Robert STRANDH) Date: Mon, 23 Feb 2004 17:52:03 +0100 Subject: [gsharp-devel] web page In-Reply-To: References: <20040216153926.699512B10A@serveur5.labri.fr> Message-ID: <16442.12211.152446.408252@serveur5.labri.fr> Christophe Rhodes writes: > Robert STRANDH writes: > > > We have a web page: > > > > http://www.common-lisp.net/project/gsharp/ > > > > Comments are welcome. > > One comment is that, despite the "Valid XHTML 1.0 > Strict" claim at the bottom of the page, it's not valid XHTML 1.0 > Strict. Now it is :-) I took advantage of this update to include a paragraph on the licenses according to which Gsharp is distributed. At some point, I should add headers in the files. I do not want the clause "or any later version...", simply because I am paranoid. I fear that the FSF be taken over by some evil force and that some version n of the GPL contain clauses that makes it legal for the new FSF board to convert all software to proprietary. I therefore try always to use GPL version 2 (if I remember correctly). > One thing that might be worthwhile is a bibliography, either on the > page or in the documentation, so that aspiring gsharp hackers can read > up on current best practice for engraving, at least. I suppose it's > possible that there are useful links at one remove from projects such > as Lilypond, Common Lisp Music/Common Music Notation, and the like. > > might be a start. That is a very good idea. Several possibilities: 1. Link to the one from Lilypond 2. Steal the one from Lilypond 3. Write our own 1 and 2 are much less work than 3. Also, if we do 3, it does not seem right (this might be my scientific upbringing) to include references that nobody on the Gsharp project has read. At the moment, it would therefore be fairly short (Ross, the CMJ Lime reference, and a few others as far as I am concerned). On the other hand, we might include references to CLIM and Common Lisp. Compromise solution: write our own containing only what someone has actually read, and also link to the one from Lilypond. Opinions? Also, I would like to write it in something like Bibtex and convert it to HTML. > (On the subject of web presence, people may be interested in > , and in > particular the before/after screenshots, and the description of the > use of the keyboard macro.) Looks good (glad you liked my new feature). Shall we put it on the web site? Now we need numeric arguments. Some thoughts should be given to how Gsharp commands (in the CLIM sense) react to numeric arguments before an ad-hoc solution is implemented. My hunch is that define-gsharp-command should be modified to accept things like (:numarg :repeat), (:numarg :pass), etc. corresponding to different ways Emacs handles numeric arguments. -- 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 Feb 23 22:24:05 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 23 Feb 2004 22:24:05 +0000 Subject: [gsharp-devel] web page In-Reply-To: <16442.12211.152446.408252@serveur5.labri.fr> (Robert STRANDH's message of "Mon, 23 Feb 2004 17:52:03 +0100") References: <20040216153926.699512B10A@serveur5.labri.fr> <16442.12211.152446.408252@serveur5.labri.fr> Message-ID: Robert STRANDH writes: > > One thing that might be worthwhile is a bibliography, either on the > > page or in the documentation, so that aspiring gsharp hackers can read > > up on current best practice for engraving, at least. > > Compromise solution: write our own containing only what someone has > actually read, and also link to the one from Lilypond. > > Opinions? That's fine with me. Since I haven't yet read anything, I can't add much more :-) > Also, I would like to write it in something like Bibtex and convert it > to HTML. BibTeX is a wonderful thing, yes. > > (On the subject of web presence, people may be interested in > > , and in > > particular the before/after screenshots, and the description of the > > use of the keyboard macro.) > > Looks good (glad you liked my new feature). Shall we put it on the > web site? By all means. While it's not as compelling as seeing it happen in front of your eyes, at least it demonstrates a little of what can be done. 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 Feb 23 22:52:15 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 23 Feb 2004 22:52:15 +0000 Subject: [gsharp-devel] Problem of second gsharp Message-ID: Hi, There's a problem when running the second (and subsequent) gsharps of any given session. The problem arises, I think, because of too much state maintenance, but I'm not sure whose fault it is -- gsharp's, or the CLIM CLX backend. To reproduce the problem, (gsharp::run-gsharp) c ] d [ Quit (from menu or interactor) (gsharp::run-gsharp) c ] d [ at this point, you will hit the debugger. What's happening is that the pixmap held in *lighter-gray-progressions* and *darker-gray-progressions* is cached from the first gsharp run, and the copy-from-pixmap from the second gsharp is confused because the X display of the first gsharp (presumably associated in some way with the pixmap in question) is closed. So, firstly, whose fault is this? And secondly, if it is a problem in gsharp, where is best to deal with it? Should these caches be maintained per-frame, or per-score-pane? I guess per-frame, since that's effectively how they were treated before... 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 Feb 24 05:34:11 2004 From: strandh at labri.fr (Robert STRANDH) Date: Tue, 24 Feb 2004 06:34:11 +0100 Subject: [gsharp-devel] web page In-Reply-To: References: <20040216153926.699512B10A@serveur5.labri.fr> Message-ID: <16442.57939.773418.749208@serveur5.labri.fr> Christophe Rhodes writes: > One thing that might be worthwhile is a bibliography. Added a bibliography to the documentation. It may not be worth the effort to put such a bibliography on the web site, since Lilypond has a perfectly good one. -- 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 Feb 24 05:38:22 2004 From: strandh at labri.fr (Robert STRANDH) Date: Tue, 24 Feb 2004 06:38:22 +0100 Subject: [gsharp-devel] web page In-Reply-To: References: <20040216153926.699512B10A@serveur5.labri.fr> <16442.12211.152446.408252@serveur5.labri.fr> Message-ID: <16442.58190.138590.953659@serveur5.labri.fr> Christophe Rhodes writes: > That's fine with me. Since I haven't yet read anything, I can't add > much more :-) I do recommend the book by Ted Ross. It is very precise in some ways and wonderfully vague in others. A large part of the effort of implementing the Gsharp algorithms has been to figure out what on earth Ross might mean. > > Looks good (glad you liked my new feature). Shall we put it on the > > web site? > > By all means. While it's not as compelling as seeing it happen in > front of your eyes, at least it demonstrates a little of what can be > done. I believe you have write permission. You should just go ahead and do 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. --------------------------------------------------------------------- From strandh at labri.fr Tue Feb 24 05:48:53 2004 From: strandh at labri.fr (Robert STRANDH) Date: Tue, 24 Feb 2004 06:48:53 +0100 Subject: [gsharp-devel] Problem of second gsharp In-Reply-To: References: Message-ID: <16442.58821.372113.858347@serveur5.labri.fr> Christophe Rhodes writes: > > There's a problem when running the second (and subsequent) gsharps of > any given session. The problem arises, I think, because of too much > state maintenance, but I'm not sure whose fault it is -- gsharp's, or > the CLIM CLX backend. > > To reproduce the problem, > (gsharp::run-gsharp) > c ] d [ > Quit (from menu or interactor) > (gsharp::run-gsharp) > c ] d [ > at this point, you will hit the debugger. What's happening is that > the pixmap held in *lighter-gray-progressions* and > *darker-gray-progressions* is cached from the first gsharp run, and > the copy-from-pixmap from the second gsharp is confused because the X > display of the first gsharp (presumably associated in some way with > the pixmap in question) is closed. > > So, firstly, whose fault is this? Certainly Gsharp's. Pixmaps are per X session, so it should not hold on to those between sessions. > And secondly, if it is a problem in > gsharp, where is best to deal with it? Should these caches be > maintained per-frame, or per-score-pane? I guess per-frame, since > that's effectively how they were treated before... I would think that putting them in the frame would be bad, since technically, the frame should not know how the score pane accomplishes its task. the *xx-gray-progressions* variables are not exported from the score-pane package, indicating that their existence is not known to the outside world. I would put them in the score pane, together with the other pixmaps. This change should be fairly simple to make. -- 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 Feb 24 06:01:39 2004 From: strandh at labri.fr (Robert STRANDH) Date: Tue, 24 Feb 2004 07:01:39 +0100 Subject: [gsharp-devel] Initial thoughts In-Reply-To: <16433.42549.673288.897129@serveur5.labri.fr> References: <16433.42549.673288.897129@serveur5.labri.fr> Message-ID: <16442.59587.350253.285988@serveur5.labri.fr> Robert STRANDH writes: > > Christophe Rhodes writes: > > > > Whether this keyboard macro facility wants to > > record gestures (keystrokes) or commands, I don't know -- does anyone > > know what emacs does? Probably both in various circumstances. :-) > > I don't think it matters really. The only situation where one could > see the difference would be if keyboard bindings change between the > definition and the invocation of a keyboard macro. So, I did it by recording keystrokes, and now I know why I should probably have done it the other way. The problem is that, in the current implementation, the keystrokes that were used to invoke end-kbd-macro are on the list of recorded keys when end-kbd-macro is executed, and must be removed. But end-kbd-macro should not have to know how it was invoked. A solution that consists of finding the last keystrokes on the list of recorded keys that invoke end-kbd-macro does not seem like a good idea (what if it were invoked by using the command-line?). A better solution seems to be to record the commands that were invoked. The last command on the list is always end-kbd-macro itself, so it can be safely removed. This solution also makes it easier to record commands invoked from the command line (which currently is not done). This improved solution is still tricky in the presence of things like numeric arguments (whenever they become implemented). Probably, the recording list has to contain thunks that encapsulate numeric arguments and the way the command was invoked. Executing the macro consists of funcall-ing each thunk. -- 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 Feb 24 10:47:10 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 24 Feb 2004 10:47:10 +0000 Subject: [gsharp-devel] Problem of second gsharp In-Reply-To: <16442.58821.372113.858347@serveur5.labri.fr> (Robert STRANDH's message of "Tue, 24 Feb 2004 06:48:53 +0100") References: <16442.58821.372113.858347@serveur5.labri.fr> Message-ID: Robert STRANDH writes: > Christophe Rhodes writes: > > And secondly, if it is a problem in > > gsharp, where is best to deal with it? Should these caches be > > maintained per-frame, or per-score-pane? I guess per-frame, since > > that's effectively how they were treated before... > > I would think that putting them in the frame would be bad, since > technically, the frame should not know how the score pane accomplishes > its task. the *xx-gray-progressions* variables are not exported from > the score-pane package, indicating that their existence is not known > to the outside world. I would put them in the score pane, together > with the other pixmaps. This change should be fairly simple to make. Right-oh. Attached, for inspection; minimal testing (but I do mean minimal) didn't reveal any problems. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: progs.diff URL: -------------- next part -------------- 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 Feb 24 13:04:18 2004 From: strandh at labri.fr (Robert STRANDH) Date: Tue, 24 Feb 2004 14:04:18 +0100 Subject: [gsharp-devel] Problem of second gsharp In-Reply-To: References: <16442.58821.372113.858347@serveur5.labri.fr> Message-ID: <16443.19410.659101.959781@serveur5.labri.fr> Christophe Rhodes writes: > Right-oh. Attached, for inspection; minimal testing (but I do mean > minimal) didn't reveal any problems. Looks good to me. This solution is even thread-safe, right? -- 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 Feb 24 13:17:44 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 24 Feb 2004 13:17:44 +0000 Subject: [gsharp-devel] Problem of second gsharp In-Reply-To: (Christophe Rhodes's message of "Tue, 24 Feb 2004 10:47:10 +0000") References: <16442.58821.372113.858347@serveur5.labri.fr> Message-ID: Christophe Rhodes writes: > Right-oh. Attached, for inspection; minimal testing (but I do mean > minimal) didn't reveal any problems. (slightly more intensive testing revealed the problem that replaying output no longer works, because *foo-gray-progressions* are unbound -- there's no with-score-pane in play at that stage. Oh well.) 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 Feb 24 13:29:44 2004 From: strandh at labri.fr (Robert STRANDH) Date: Tue, 24 Feb 2004 14:29:44 +0100 Subject: [gsharp-devel] Problem of second gsharp In-Reply-To: References: <16442.58821.372113.858347@serveur5.labri.fr> Message-ID: <16443.20936.208724.741973@serveur5.labri.fr> Christophe Rhodes writes: > Christophe Rhodes writes: > > > Right-oh. Attached, for inspection; minimal testing (but I do mean > > minimal) didn't reveal any problems. > > (slightly more intensive testing revealed the problem that replaying > output no longer works, because *foo-gray-progressions* are unbound -- > there's no with-score-pane in play at that stage. Oh well.) Darn. -- 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 Wed Feb 25 17:50:35 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 25 Feb 2004 17:50:35 +0000 Subject: [gsharp-devel] Problem of second gsharp In-Reply-To: <16443.20936.208724.741973@serveur5.labri.fr> (Robert STRANDH's message of "Tue, 24 Feb 2004 14:29:44 +0100") References: <16442.58821.372113.858347@serveur5.labri.fr> <16443.20936.208724.741973@serveur5.labri.fr> Message-ID: Robert STRANDH writes: > Christophe Rhodes writes: > > (slightly more intensive testing revealed the problem that replaying > > output no longer works, because *foo-gray-progressions* are unbound -- > > there's no with-score-pane in play at that stage. Oh well.) > > Darn. OK, here's take II. It's slightly uglier than before (but is less broken :-), and I have two questions. Firstly, what does the comment in the two REPLAY-OUTPUT-RECORD methods that I've touched mean? ("we replay with the identity transformation, so we have to draw the other way"). Secondly, is the change that I've made here (specializing REPLAY-OUTPUT-RECORD on the stream argument, too) guaranteed to work? How will it interfere, if at all, with the notion of replaying all output records on a postscript medium for printing? (This fix does improve thread-safety in the sense that two separate gsharps running in the same image would not have collisions in their {dark,light}er-gray-progressions pixmaps. There remains the problem of multiple threads running the same gsharp -- say for concurrent updating of the screen, or something -- colliding when extending the arrays containing the pixmaps). -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gsharp.diff URL: -------------- next part -------------- Comments? 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 Wed Feb 25 18:09:56 2004 From: strandh at labri.fr (Robert STRANDH) Date: Wed, 25 Feb 2004 19:09:56 +0100 Subject: [gsharp-devel] Problem of second gsharp In-Reply-To: References: <16442.58821.372113.858347@serveur5.labri.fr> <16443.20936.208724.741973@serveur5.labri.fr> Message-ID: <16444.58612.681203.468639@serveur5.labri.fr> Christophe Rhodes writes: > OK, here's take II. It's slightly uglier than before (but is less > broken :-), and I have two questions. > > Firstly, what does the comment in the two REPLAY-OUTPUT-RECORD methods > that I've touched mean? ("we replay with the identity transformation, > so we have to draw the other way"). It explains why in the replay of upward-beam-output-record there is a call to draw-downward-beam and vice versa. The function draw-upward beam is called when the transformation is such that the origin is in the lower-left corner, whereas the replay is done with the identity transformation, and thus with the origin in the upper-left corner. > Secondly, is the change that I've made here (specializing > REPLAY-OUTPUT-RECORD on the stream argument, too) guaranteed to work? > How will it interfere, if at all, with the notion of replaying all > output records on a postscript medium for printing? I think what you did is right. In fact, the other draw-xx functions should probably be specialized as well, so as to allow for other types of output media, like a PostScript file. > (This fix does improve thread-safety in the sense that two separate > gsharps running in the same image would not have collisions in their > {dark,light}er-gray-progressions pixmaps. There remains the problem > of multiple threads running the same gsharp -- say for concurrent > updating of the screen, or something -- colliding when extending the > arrays containing the pixmaps). OK, that is fine for now. > =================================================================== > RCS file: /project/gsharp/cvsroot/gsharp/score-pane.lisp,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 score-pane.lisp > --- score-pane.lisp 16 Feb 2004 15:46:21 -0000 1.1.1.1 > +++ score-pane.lisp 25 Feb 2004 17:39:07 -0000 > @@ -1,7 +1,11 @@ > (in-package :score-pane) > > (defclass score-pane (application-pane) > - ((pixmaps :initform (make-hash-table :test #'eq) :reader pane-pixmaps))) > + ((pixmaps :initform (make-hash-table :test #'eq) :reader pane-pixmaps) > + (darker-gray-progressions :initform (make-array 10 :initial-element nil :adjustable t) > + :reader darker-gray-progressions) > + (lighter-gray-progressions :initform (make-array 10 :initial-element nil :adjustable t) > + :reader lighter-gray-progressions))) So far so good. > > (defmethod dispatch-event :before ((pane score-pane) (event pointer-enter-event)) > (let ((port (port pane))) > @@ -474,10 +478,8 @@ > (when (stream-drawing-p *pane*) > (medium-draw-rectangle* medium x1 y1 x2 y2 t)))) > > -(defparameter *darker-gray-progressions* > - (make-array 10 :initial-element nil :adjustable t)) > -(defparameter *lighter-gray-progressions* > - (make-array 10 :initial-element nil :adjustable t)) > +(defvar *darker-gray-progressions*) > +(defvar *lighter-gray-progressions*) OK. > > ;;; don't delete this yet, since I don't know how the other one will work out. > ;; (defun ensure-gray-progressions (index) > @@ -563,7 +565,7 @@ > (defclass upward-beam-output-record (beam-output-record) > ()) > > -(defmethod replay-output-record ((record upward-beam-output-record) stream > +(defmethod replay-output-record ((record upward-beam-output-record) (stream score-pane) Should be fine. > &optional (region +everywhere+) > (x-offset 0) (y-offset 0)) > (declare (ignore x-offset y-offset region)) > @@ -572,15 +574,17 @@ > (let ((medium (sheet-medium stream))) > (let ((*light-glyph* (not (eq ink +black+)))) > (with-drawing-options (medium :ink ink) > - ;; we replay with the identity tranformation, so > - ;; we have to draw the other way > - (draw-downward-beam medium x1 (1- y2) (1- (+ y1 thickness)) thickness > - (/ (- x2 x1) (- y2 y1 thickness))))))))) > + (let ((*lighter-gray-progressions* (lighter-gray-progressions stream)) > + (*darker-gray-progressions* (darker-gray-progressions stream))) > + ;; we replay with the identity tranformation, so While you are at it, you can fix the typo in "transformation". > + ;; we have to draw the other way > + (draw-downward-beam medium x1 (1- y2) (1- (+ y1 thickness)) thickness > + (/ (- x2 x1) (- y2 y1 thickness)))))))))) > > (defclass downward-beam-output-record (beam-output-record) > ()) > > -(defmethod replay-output-record ((record downward-beam-output-record) stream > +(defmethod replay-output-record ((record downward-beam-output-record) (stream score-pane) > &optional (region +everywhere+) > (x-offset 0) (y-offset 0)) > (declare (ignore x-offset y-offset region)) > @@ -589,10 +593,12 @@ > (let ((medium (sheet-medium stream))) > (let ((*light-glyph* (not (eq ink +black+)))) > (with-drawing-options (medium :ink ink) > - ;; we replay with the identity tranformation, so > - ;; we have to draw the other way > - (draw-upward-beam medium x1 (1- (+ y1 thickness)) (1- y2) thickness > - (/ (- x2 x1) (- y2 y1 thickness))))))))) > + (let ((*lighter-gray-progressions* (lighter-gray-progressions stream)) > + (*darker-gray-progressions* (darker-gray-progressions stream))) > + ;; we replay with the identity tranformation, so idem. > + ;; we have to draw the other way > + (draw-upward-beam medium x1 (1- (+ y1 thickness)) (1- y2) thickness > + (/ (- x2 x1) (- y2 y1 thickness)))))))))) > > (defun draw-sloped-beam (medium x1 y1 x2 y2 thickness inverse-slope) > (let ((transformation (medium-transformation *pane*))) > @@ -658,6 +664,8 @@ > (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+) > > Comments? Looks fine to me. I do not see why you find it uglier. Good work. -- 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. ---------------------------------------------------------------------