| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11
<Xof> this is a staging post, because it essentially allows us to change the command table we look gestures up in <Xof> and the command table in which mouse gestures are interpreted <beach> Xof: sounds good. Are you hesitating with the commit? <beach> Xof: what do you think about my suggested fix for the pixmap focus? <salex> Xof: did you see my query? <Xach> hmm <Xof> beach: I haven't seen your proposed fix for the pixmap focus :-/ <Xof> salex: nope <Xof> salex: oh, lute tablature -> score? That's "future work" :-) <Xof> there are two interesting problems there, both of which we think we know how to solve <Xof> pitch spelling (is midi 63 a c-sharp or a d-flat?) and voicing (does this note belong next to that one or the other one?) <Xof> beach: oh, the one just above. Hold on <Xof> beach: I'm afraid I don't know. It sounds plausible, as long as it's transparent to the application writer. <beach> Xof: my proposed fix is about 50 lines ^ thataway <Xof> yeah, sorry <Xof> I have to say that I didn't understand some of the code that I mutilated to produce my diff to esa.lisp <Xof> bits of code accumulating gestures for some reason <beach> Xof: it should be transparent. Plus, it has the advantage of not influencing an application that does not use the double-buffering <Xof> so I may have broken something in the process <salex> Xof: gotcha <Xof> salex: it's definitely of interest, though; Dave Meredith (a Research Fellow in the group) is basically the world expert on pitch spelling <Xof> and Tim Crawford has at least a partial solution to voicing <Xof> we do need extra hackers, though :-/ <salex> Xof: by the way, do you know if lute tablature has a standard way of notating chord position? (as notes alone are not sufficient for these sorts of instruments) <Xof> salex: how do you mean? <Xof> lute tablature is pretty deterministic <salex> (de-facto standard) guitar tab isnt <Xof> right <Xof> lute tablature tells you which fret is sounded on each string <salex> yeah, erm, i'm getting ahead of myself <salex> a lot of guitar tab is too, except where it shorthands chords <federico> Xof: which program is this? <Xof> federico: an editor for lute tablature <Xof> written to support a library / research project here at Goldsmiths <federico> Xof: oooh, do you have a web page or something? <Xof> let's see if I can find you a screenshot <Xof> http://www-jcsu.jesus.cam.ac.uk/~csr21/tabedit-pretty.png <salex> Xof: of course, it isn't injectivly mapped to a score, unless you can also note exactly how it will be voiced <salex> otoh, that sort of detail is often best left to musician. <Xof> salex: right, so you need a processor with musical knowledge <Xof> fortunately, we are overflowing with musicians around here ;-) <salex> true! <Xof> for the lute repertoire, it's not such a big deal, because the variation over the corpus isn't huge <Xof> guitar tab is harder <Xach> what are lute players called? <salex> Xof: that makes sense <Xof> http://www-jcsu.jesus.cam.ac.uk/~csr21/tabedit-barley.png <Xof> Xach: lutenists <Xof> federico: I'm afraid it's a bit hard to wrap as a gtk widget ;-) <salex> Xof: and we'd need a full AI to solve the problem of the vast amounts of guitar tab floating around that are just, well, incorrect. <Xach> that's luticrous. <dan_b> as opposed to people who live near easyjet's hub airport <dan_b> who are lutonistas <salex> dan_b: ouch <xan_> hi <Xof> _london_ lutonists <Xof> that's very important! You wouldn't want to get the impression that you were landing in the middle of nowhere <salex> heh <dan_b> as opposed to somewhere nice and central like brighton gatwick, you mean? <federico> Xof: hard to do in gtk? why? <Xof> federico: hard to wrap all our current code in gtk :-) <federico> ah <Xof> (it's all in lisp) <federico> aren't there lisp bindings for gtk? <federico> (cairo seems well-suited for that kind of display, btw) <Xof> we have a partial cairo backend to mcclim <Xof> we're not currently using it much; using a mixture of freetype and X instead <Xof> it would be nice to have someone who knew what was going on hacking the backends, though <Xof> speaking of "what's going on", what is _GTK_LOAD_ICONTHEMES meant to be? <Xof> I'm getting a load of those client messages <Xof> and there's precisely one web reference to that string <federico> Xof: it tells you when the icon theme has changed and you need to update yourself <federico> Xof: ummmm, when are you getting those messages? I smell a bug somewhere <salex> ok, back to fighting with latex. have fun all. <Xof> federico: on various events on my regular lispy X windows <Xof> things like exposure and the like <Xof> federico: I'll be back soon; I'm going home <Jabberwockey> The emacs has no problems with converting the file. Does anyone of you have a good documentation on how to write an Emacs macro that loads an UTF8 file and converts it into a Latin1 one? <Thas> Jabberwockey : the set-buffer-file-coding-system function is probably a good place to start. <Thas> So probably something like (defun convert-buffer (file) (interactive "something") (with-temp-buffer (load-file) (set-coding) (write-buffer)) <Jabberwockey> Thas: Thanks. So from the command line I could do a -load somefile.lisp -eval (convert-buffer) - and then I just have to include something like "exit" in the function? <Thas> I've almost got it written. One second while I test. <lichtblau> from that command line, you could do a "recode" <lichtblau> and if that doesn't work, your file is garbage <Thas> Ok, that works. Pasting. <Jabberwockey> lichtblau: My file IS garbage. <Thas> lisppaste: url <Jabberwockey> lichtblau: recode doesn't work, but the emacs can parse it fairly well. <lisppaste> To use the lisppaste bot, visit http://paste.lisp.org/new/lisp and enter your paste. <lichtblau> that doesn't make it on-topic <Thas> (BTW, in preference I'd probably use sb-ext:octets-to-string and string-to-octets <-- this makes it on-topic :)) <lisppaste> Thas pasted "convert-file in emacs" at http://paste.lisp.org/display/12895 <Jabberwockey> Thas: Thanks :) and from the command-line the stuff mentioned above should do the trick? <Thas> I have no idea what that'll do to a file that contains non-Latin-1 characters, but it works for valid ones at least. <Thas> Yep, probably. <Jabberwockey> Thas: Well, it has to load a UTF8 file... shouldn't I tell Emacs about that beforehand? <Thas> Jabberwockey : Hm, yes. I've got my default-coding-system set to 'utf-8, it's probably just an additional SETQ away. <Jabberwockey> Ok, I'll give it a try... <Jabberwockey> Mpf. Doesn't work :( <Jabberwockey> Emacs is complaining that it can't safely encode the text into latin1 <Thas> Have you sbcl? <Jabberwockey> Yes. But a phoney Debian version <Thas> No problem <lisppaste> Thas annotated #12895 with "recode-to-latin1 (sbcl)" at http://paste.lisp.org/display/12895#1 <Thas> The first "?" is what invalid UTF-8 is replaced by when reading the input file; the second is what valid characters that aren't in latin-1 are replaced by when writing the output file. Customize to taste. <jsnell> Thas: probably not. debian stale ships 0.8.16 <mgr> uh, there is a bug in mcclim: menu items of disabled commands are not "greyed out" if they are not in a sub-menu (i.e. they are themselves directly in the menu-bar). It is even possible to fire them up! <Thas> Gah. That's what I get for running unstable, I guess. :/ <Jabberwockey> debugger invoked on a SIMPLE-ERROR in thread 3989: <Jabberwockey> unknown type specifier: SB-EXT::CHARACTER-DECODING-ERROR <mgr> (yeah, and it is enough to mention such things in this forum.) <Jabberwockey> Thas: Obviously not. <Thas> Ok then... <Jabberwockey> Thas: Thanks for your help, though... <Thas> yw <NightBird> hm... there is no lisp for the ti89... *looks into implementing it...* <NightBird> however, first I must go to cl*** <Xach> NightBird: for future reference, there's not really a need to share your internal dialogue with #lisp *all* the time <Xach> 13% is typical <michaelw> and i thought #lisp is 90% sharing internal dialogue. the other 10% is minion and the gang reconnecting. <Xach> awt is graciously shifting that to #lisp-newbies <chandler`> minion: could you share your internal dialogue with us? <minion> you speak nonsense <sieni> minion: chant <minion> MORE PLAYERS <chandler`> Is #lisp-newbies where lisp newbies hang out and misinform each other? <Xach> between sharing their internal dialogue, yes. <awt> I was unaware of lisp newbies. aparantly the only guy there came over to beginners, though <lichtblau> jsnell: "debian stale" is nice ;-) <therp> is anyone using CFFI here? its project page says it's new and probably not ready for prime time.. <antifuchs> bwaha pfdietz's cll messages are great (-: <ths> Hm, I tried to find (in SBCL) a way to unbind a dynamic variable explicitly. Am I right that there is none and I have to unbind a binding made from C also via a C function? <antifuchs> "One may want to go with nybble or bit pair arrays; that is, arrays of element type (integer 0 15) or (integer 0 3). Many CL implementations have specialized arrays with these element types (and many had bugs in them :).)" <Xach> therp: i think luis uses it. <nyef> clhs makunbound <specbot> http://www.lispworks.com/reference/HyperSpec/Body/f_makunb.htm <Xach> duane's followups are interesting too <ths> lichtblau: It is "stale, rusting, and broken". :-) <therp> xach ;) he seems to be the author <nyef> ths: Perhaps you are looking for makunbound? <antifuchs> Xach: correct, they are (: <ths> nyef: Probably, I'm not sure what a dynamic binding actually is. :-) <nyef> ths: Don't turn to the spec to figure out what a dynamic binding is. For the sake of your sanity. <ths> nyef: I turned to the code and still don't fully understand it. <mega1> ths: did you get how the binding stack and symbol-value works? <ths> mega1: Probably not. <ths> I don't see why the old value is saved, it could as well just be an increment/decrement of a global (or TLS) variable.
Return to lisp or Go to some related
logs:
chatzone define chode
|
|