freenode/#clim - IRC Chatlog
Search
7:50:55
beach
And I keep thinking of gestures on a tablet that would simplify the interaction with a score editor.
7:52:11
beach
Once when I suggested a student project, the student proposed an interface whereby all the music symbols would be displayed, and the user would drag symbols to the desired place on the score.
7:52:52
beach
I then suggested a word-processor interface to the student, whereby each letter would be displayed, and the user would drag each letter to the desired place in the text.
7:54:50
jackdaniel
sure, on tablets too, but also when typing text in alphabet which is not mapped onto the keyboard (i.e a cyrillic on western keyboard) when someone can't write without looking
7:55:15
beach
I think the absolute horrible thing with current interfaces is that, since it is rare that the same symbol is used twice in a row, the user has to alternate between the place where a symbol is entered, and the tool bar where symbols are displayed.
7:55:20
jackdaniel
not the most efficient way but as a fallback it is something which allows getting thing done
7:56:51
beach
Anyway, I'll be a but busy this morning. A physical therapist is coming to the house in order to try to fix my back that I seem to have injured a week or so ago.
7:58:44
jackdaniel
I had a project for my bachelor's degree where we were writing a tool to asses the keyboard layout efficiency (with two default metrics: typing speed and hand effort)
8:10:40
ck_
jackdaniel: that's interesting. How did you deal with the influence of training/familiarization?
8:13:28
jackdaniel
we didn't; it was all simulation where particular fingers were associated with keys and the effort was split between each finger due a course of whole text and speed was a function of time needed between pressing two keys (they might be the same hand or not, that mattered too)
8:14:37
jackdaniel
distance between keys was taken from the keyboard model created before the simulation (so different keyboard shapes were tested too)
8:15:07
jackdaniel
it is worth noting that the guts of the whole project were written in common lisp
8:17:13
jackdaniel
results of simulations were not very spectacular -- basically all except ridiculus designs had similar efficiency (I think that dvorak had negligible adventage for english text, but I might have misremembered)
8:57:30
jackdaniel
scymtym: another question: is there a risk of performance penalty from using traits abstraction you have mentioned (under sbcl and others)?
8:58:18
scymtym
jackdaniel: i had all-day project meeting yesterday and the day before. i'm just catching up now
8:59:40
scymtym
the traits thing should work without performance penalty. a higher risk could be behavior differences between MOPs and also bugs
9:00:50
scymtym
in my test, even the simple example didn't work completely reliably. i suspect a bug in SBCL's PCL implementation, but didn't investigate yet
10:08:18
jackdaniel
scymtym: yesterday I've mentioned that I've encountered sbcl bug in the compilation environment and I've asked you if you have published somewhere the C99 parser with the preprocessor
10:09:56
scymtym
jackdaniel: it doesn't seem like i published the code. i try can to work towards that today
10:10:43
jackdaniel
basically there were two slightly different atan* definitions (the second one did not coerce y to float), and the caller of atan* called the second definition while relying on type inference information from the first definition
10:17:47
jackdaniel
hm, apparently my minimal case is too simple and sbcl works correctly so you may need to load mcclim to reproduce
10:19:18
jackdaniel
put (defun atan* (x y) (let ((r (atan y x))) (if (< r 0) (+ r (* 2 pi)) r))) in region-utilities (notice that atan* is previously defined in transforms.lisp)
10:19:45
jackdaniel
quickload mcclim and invoke from climi package (bounding-rectangle (make-ellipse* 0 0 10 0 0 15 :start-angle 0 :end-angle (/ pi 2)))
10:20:51
jackdaniel
if you skip the second definition all works, likewise if you skip the first one or if you recompile untransform-angle by hand after loading
10:23:54
scymtym
i see, so the problem is related to redefinition. then why the COERCE instead of defining the function only once?
10:24:50
jackdaniel
coerce is still there because it proves to be more accurate in practice (I've mentioned that in the review discussion)
10:25:39
jackdaniel
i.e = works just fine when we use the same type as pi; when we take the type as is we have mismatches like /= 15.0 14.9999999999999999997
10:25:41
scymtym
ok, i'm probably getting ahead of myself here. i will try to read the discussion later
10:27:32
jackdaniel
n.b: I'd appreciate if you could find the time to publish the c99 thing when you have some time; no rush of course
10:28:11
scymtym
i didn't try to reproduce it yet but it seems likely that i will be able to. redefining a function after the inferred type of the previous definition has been used is something that causes problems in SBCL
10:28:43
scymtym
sure, i just have to remind myself what the state of the code is and potentially clean up a few things
13:35:40
scymtym
silly experiment: a module (mathematics) trait and an implementation for strings: (loop :for s :from 0 :to 1 :by 1/10 :collect (lerp s "Jackdanial" "Beach")) ; => ("Jackdanial" "Jackdania" "JackdaniB" "JackdanBe" "JackdaBe" "JackdBe" "JackBea" "JacBeac" "JaBeac" "JBeac" "Beach")
14:00:08
jackdaniel
we have a PiggyBea here, a pig masquotte which flies and does bzzzz (and chrm in the end), the little one likes it
14:04:50
jackdaniel
(flying and audio effects are produced by me, it is not a mechanical/electronic toy)