Doctrinal Statements
This week's videos deals with a popular doctrinal statement. The TT and BRB were both updated. Also, I'm onto manuscript recovery code.
Chicago Statement on Biblical Inerrancy
When we have conversation with people about our work they often turn to their church doctrinal statement for cover. So, this week I take a long, popular, doctrinal statement about biblical inerrancy, and go through it point by point.
I've wanted to do this talk for awhile because this is a good way to flush out points of conversation. I had fun making this video, getting a little more emotional than I normally do. I hope you enjoy watching it.
BRB and TT Updates
BRB and TT were both updated this week. Changes are in the Assembly of Jerusalem, which comes from the first half of acts. Many of the section headings in this area have been adjusted.
We also found a few more subtle bugs in the underlying code that has been running fine for years. Apparently related to Chrome 73, though it wasn't clear to me the source of the problem. If you notice anything strange using either of these apps please let me know. There may be more fresh bugs than I've not yet noticed.
Manuscript Recovery
I've spent the past week working steadily on the code for manuscript recovery. As with most programming problems like this most of the work goes into marshalling the raw data in and out of the computer.
Most of the inbound marshalling is done, expressed in a Makefile and a bunch of file conversion utilities. These convert inbound files so they can be analyzed in detail.
At the heart of this work is a routine that sifts through individual verses and checks for the inspired pattern of text.
I was able to get a Javascript version of that routine coded, and it ran through a first verse early this week. I considered it quite a milestone, though I neglected to capture the output...
Javascript is not the proper language for this type of work. Javascript is very programmer efficient, and is tuned for the sorts of workloads seen in web pages and interactive servers. Given that design, it was no surprise to me that this first draft basically blew out memory and took a day to complete.
For any given verse the code has millions of cases to check in order to not miss anything. Uninspired verses are harder, and take more time, because the code must weed through more gibberish.
With the Javascript prototype done, I turned to a rewrite in the C programming language. That language is by far the best language for this sort of problem.
Years ago I was paid quite well to be an expert in C... But it has been many years since I touched any C code. So this has been a week of relearning. The language has subtly changed for the better and I am remembering it, thankfully.
The first draft of the C version handily nailed the memory problem. The same basic design as the Javascript was 1/30th of the memory, better than I had expected. It also brought the memory use down low enough that we won't need to upgrade main memory in our big computer to balance cores to main memory, the ratio is good enough as it is. We'll eventually turn on all the cores and all will be fine.
That first draft in the C language, though, had run-time problems. It was just a little better than Javascript, but not much. I stopped its first run at 4 hours so I could go to bed.
Unlike Javascript C has many more avenues for code optimization, it can be tuned to the precise problem at hand. Just about every morning this week I've awoken with insights as to how to optimize this task in order to speed it up. In fact I've seen design issues this week that I've never noticed in the 2 years I've had to think about it.
As a language, C gets a lot of its speed from a weak memory management system. As I end this week I've got much faster code but with memory related problems. It runs about half way through a verse rendering cycle and then crashes.
Unfortunately the crash I'm dealing with would have been hard to debug even in the days when I was using the language full time. The GUI debugger I'm using can easily show where the crash is happening, but the source of the crash is at some unknown other place. So, I am not a happy programmer at the end of this week.
I will return to debugging when I get back to this problem next week. Time for a Sabbath so I can clear my head and come back to it fresh.
More Later,
Phil