Abuse of PR: Preview article fixing keypad #340
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Issue: typing a character not in the keyboard in use results in a fatal crash. This writeup will document in unusual detail the steps and thoughts tracking it down. It's more-or-less live - no reset changes. Normally I would only produce the final result. And likely I would never go into this level of details. So bear with me: I'm prone to err as everyone else. Beware a mess ahead.
The binary just exists like this:
$ /home/u/.cache/lambdanative/linux/calculator/calculator
Thread "primordial": (list-ref '(196) 1): (Argument 1) PAIR expected
$ echo $?
70
Gambit manual has to say in "2.4 Process exit status":
`70'
This normally indicates that an exception was raised in the
primordial thread and the exception was not handled.
Hence we shall look for `list-ref` in or down from the keyboard related code.
$ find . -type f -exec grep --color -nH --null -e list-ref \{\} +
yields among others:
keypad.scm:205: (let* ((units (keypad:rowwidth (list-ref pad mn)))
keypad.scm:207: (let loop ((xx (+ x padx))(data (list-ref pad mn)))
keypad.scm:227: (key (keypad:lookup mx my x y w h (list-ref keypad npad)))
Rationale: Hitting key results in error in list-ref -> `keypad:lookup` looks promising.
Two more list-ref turning out to be within the definition of `keypad:lookup` even more.
OK. "git branch" decide to go into details for the fun of it. Learn how to make empty
commits for the commit message itself and start the "Article" in the form of all too
frequent commits.
Looking at the definition of `keypad:lookup` I become alert even
before I counciously understand what I am looking at:
Line 205 contains: ")(". Having read a lot of Scheme code from
various sources and knowing how easy it is to change the reader,
knowing that Schemers never count parentheses and read them much like
whitespace (just two kinds of them right-associative space and
left-associative) there is one condition which is legal as an
S-expression but still forbidden to write: an S-expression followed
by an S-expression with no space or newline in between.
Before I even try to dive deeper I can't help but put s space in
between.
Document issues found so far. NB: When the editor re-formats a line, I no longer take that back. instead I take it as a hint to look deeper. In this case the `let* ((units` was moved. This catched attention; not more at this point.
The headline says it all: the editor was asked to re-format according to whatever standards. NB: If there where formatting rules attached in the file... it should follow them. Fortunately there where none. So I get the "standard" formatting I am used to. (Since I mostly follow the idea "standard is better than better" and do not customize things per-project/per-file unless forced so.)
Huston: we's got a problem. The bad news: Complexity issues are worth than load. The good news: It is small in practice. Because our keybords have only so many columns and rows and while a complexity of O(n²) is horror in principle because it does not scale, our keybords do not grow so fast as our processors become faster. The worst news so far: It's late today. The mind just does not want to try to quickly fix that. We have: 1.) code raising an exception 2.) Installing exception handler is relative expensive. Given the task there should be no need to fail in list-ref. 3.) list-ref is O(n) AND directly AND indirectly called within a loop. Question: can we understand the algorith to the extent that we can do without list-ref at all?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Just to let you know about an issue I'm trying to nail down.
Don't merge this for now!