🐇 It may be useful, though. It looks like syntactic sugar for a const pointer plus malloc, but implicitness is usually not ideal. It also appears to use the stack.

🐢 I haven’t looked into the details, but it may be useful in some cases. I don’t think it can replace pointer usage if it uses the stack, though. Stack sizes are usually small, and having arrays that can fill them up is not a good approach. Another feature is complex number support. It seems from the lecture that this is also a bit of a half-baked feature.

🐇 What is the difference between this and using a struct with two float fields?

🐢 There are operators (+, -, *, or ==) that support these. Since there is no operator overloading in C, having a separate complex number type may be useful.

🐇 The example looks like double complex cx = 1.0 + 3.0*I; and yes, this may be useful if you’re frequently using complex numbers in your code. But I think it’s unnecessary in most cases. There shouldn’t be such a frequent need for complex numbers, right?

🐢 A good complex number library will probably provide more than the built-in type, such as vectors for these numbers. A dedicated library will still be needed in most cases, I believe.

🐇 Another feature added to C is that struct members can now be initialized by name or index. You can initialize an array like int a[6] = { [3] = 29, [2] = 14 };, and it will initialize only those specific members.

🐢 Ah, this is much more useful than complex numbers for the general case.

🐇 There is also a span syntax: int a[10] = {1, 2, [2 ... 4] = 3, [5] = 30};.

🐢 That is really neat.

🐇 It’s also possible to omit the initial length, so the initializer values determine the size of the array. For example, int a[] = {1, 3, [30] = 55, [9090] = 1010}; will result in an array of length 9091.

🐢 How is this used with structs?

🐇 Instead of [], in struct initializers, we use the dot notation, like struct Point p1 = { .x=0, .y=10 };.

🐢 This is really useful and would keep much of the initialization code simpler.

🐇 There is also a way to initialize arrays of structs, like:

struct points pts[5] = { [0].x = 10, [0].y = 20, [3].x = 100 };

🐢 This feature is a nice addition to C; I really like it.

Another problem we face is establishing a connection between an executable file or library and its source code. We normally don’t add executable files to version control, as they are produced from code files. A common solution to this is writing version information to an “About” page or something similar.

When I was using Subversion some 15 years ago, I would create hooks to change the code files for the necessary versioning info, but this is not a recommended approach in Git because of its distributed nature. I have never tried it, but it would likely create more problems than it solves. The recommended way is to use the build system’s facilities to retrieve the versioning information and add it to the necessary places.

While developing the C library for dervaze, I wanted to add descriptive versioning information, as the library will also contain wordlists, and more words will be added over time.

In CMake, it’s possible to set versioning information and supply it through compiler options. It’s also possible to replace strings formatted as @CHANGE_THIS@ in source files. To supply version information to the executable, you can use these facilities:

set (DERVAZE_VERSION_MAJOR 1)
set (DERVAZE_VERSION_MINOR 0)
string(TIMESTAMP DERVAZE_TIMESTAMP "%y%m%d%H%M%S")
# current branch
execute_process(
  COMMAND git rev-parse --abbrev-ref HEAD
  WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
  OUTPUT_VARIABLE DERVAZE_GIT_BRANCH
  OUTPUT_STRIP_TRAILING_WHITESPACE
)

# abbreviated commit hash
execute_process(
  COMMAND git log -1 --format=%h
  WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
  OUTPUT_VARIABLE DERVAZE_GIT_COMMIT_HASH
  OUTPUT_STRIP_TRAILING_WHITESPACE
)

This information can be supplied to the C files by creating a header file that will be used as a template.

#define DERVAZE_VERSION_MAJOR       "@DERVAZE_VERSION_MAJOR@"
#define DERVAZE_VERSION_MINOR       "@DERVAZE_VERSION_MINOR@"
#define DERVAZE_TIMESTAMP           "@DERVAZE_TIMESTAMP@"
#define DERVAZE_LIB_GIT_BRANCH      "@DERVAZE_GIT_BRANCH@"
#define DERVAZE_LIB_GIT_COMMIT_HASH "@DERVAZE_GIT_COMMIT_HASH@"

Suppose this file is named version.h.in; the following command creates the actual version.h for each build.

# configure a header file to pass some of the CMake settings
# to the source code
configure_file (
  "${PROJECT_SOURCE_DIR}/version.h.in"
  "${PROJECT_SOURCE_DIR}/version.h"
  )

It’s also possible to write this file only during the build by using ${PROJECT_BINARY_DIR}/version.h as the second argument, but in my experience, keeping such a file in the source directory is sometimes needed by build tools. When you keep it in the source directory, it’s better to ignore the generated version.h by adding it to .gitignore.

In Android, one needs to put unit test files in the app/src/test/*module-name* directory. I spent a few hours yesterday writing tests to check that the conversion between visenc and Unicode is correct in Android. After those hours, however, I learned that NDK support for tests is limited, and the error I received means that I need to write instrumentation tests instead, which use an emulator or a real device.

Instrumentation tests are user tests that check whether the user-facing aspects of the app run correctly. Unit tests, instead, check whether data flow, calculations, etc., are working as expected. The former is slow; it needs to be run in an emulator and should mimic user behavior. Just checking whether e converted correctly to ا should not require an emulator.

The technology for Ottoman OCR was mostly ready before my family obligations interrupted the project. I need to re-evaluate what is currently available, but a more pressing problem for me is the speed of translation; currently, it is so slow that it’s barely usable.

I have written the dictionary as a C library without any database dependencies and integrated it into the Android version. I’m currently updating the search functionality in the mobile app to use this library instead of a web service. It will be orders of magnitude faster than the current version because it’s offline and uses a trie to store the words—making it both small and fast.

In my experience, having a single data structure with dedicated functions for transforming and indexing is much simpler than managing multiple data structures. In my case, the core structure is:

typedef struct _dervaze_lexical_item {
  int index;
  bstr latin_search_key;
  bstr latin;
  bstr visenc_search_key;
  bstr visenc_dotless_search_key;
  bstr visenc;
  bstr annotation;
  bstr meaning;
  bstr abjad;
  lexical_role role;
  int last_vowel;
  int props;
} dervaze_lexical_item;

visenc is our abbreviation for visual encoding, which is used to represent Arabic/Ottoman/Farsi words using basic ASCII letters. It is documented on its own page.

index is a unique identifier assigned to each word. Search keys for Latin, Visenc, and Dotless Visenc (e.g., searching for ﺥ using letters like ح, چ, or ج) are used to locate these lexical items via the tries mentioned earlier.

I’m intentionally avoiding UTF-8 or other Unicode encodings because terminal output is often not well-suited for displaying Arabic text correctly.

When I began writing this software, one of my goals was to enable searching for words by their traditional numeric values (Abjad). These are often used in classical Ottoman poetry to encode a date within a verse. For example, the letter Alif corresponds to 1, Ba (ب) to 2, and so on. To search for words by these numerals—for instance, typing 246 to find words with that total value—we store the value here as well.

The lexical_role is used during translation; currently, we use two roles to distinguish between noun and verb suffixes in Turkish.

last_vowel, as the name implies, represents the last vowel of the word. Since vowel harmony in Turkish is not always reflected in Ottoman spelling, we check the last vowel when converting an Ottoman word to its Latin Turkish equivalent to ensure the correct suffix is added (e.g., gemiler instead of gemilar).

props is a bit field used to represent various properties of the lexical item, such as:

#define HAS_FINAL_VOWEL 0x01
#define HAS_SINGLE_VOWEL 0x02
#define IS_LAST_VOWEL_HARD 0x04
#define IS_FINAL_CONSONANT_HARD 0x08
#define HAS_CONSONANT_SOFTENING 0x10

These properties are particularly important when converting Ottoman text to modern Turkish.

The current version of the translation engine is written in Python, but I plan to rewrite it in C this week. As this is the third rewrite, I don’t expect it to pose a major algorithmic challenge, although debugging the C version may be more demanding.