Help Logs Database

Undernet  |  EFnet  |  Quakenet  |  Freenode  |  Ircnet  |  Dalnet
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

Copyright © 2005 www.irclogs.ws. All rights reserved. » disclaimer » contact