Posts

This week was mainly a continuation of my work during week 1. I continued work on zlib by conducting more rigorous testing, covering the relevant tests within the default CMakeLists. Overall, I think that zlib is mostly functional at the current state and should provide general compression and decompression functionality. Notes on zlib There are still some things to keep in mind on the current state of zlib; first of which is building the test application, especially since I have to use a file system like littlefs. In gzlib.c and related source files for “gz” prefixed functions, file i/o functionality is required, and I figured that littlefs would be a good fit since it is designed for use in embedded applications. However, it seems that some platforms, such as my native_sim and qemu_riscv64/32, struggle with building the application with littlefs or with interacting with the filesystem. I have found that real hardware (i.e., the ESP32) works the best for building and running the application. However, the application still fails two coverage tests (cover_wrap and cover_back) in the provided CMake tests. Therefore, I will have to look into OpenOCD so I can get a debugger running. On the other hand, I’m able to pass all the tests not involving file i/o on native_sim, likely since there are differences between the C libraries on native_sim and other platforms (e.g., I think I am able to include header files on my system but not in the Zephyr libc). Another factor to keep in mind is that I also decreased the parameters for max LZ77 window bits and default memory level to avoid a heap overflow on my ESP32. Lastly, I have a few remarks on the Kconfig option CONFIG_POSIX_API. Although this page states that the option should not be used for new Zephyr applications, the truth is that unistd.h still uses a #ifdef CONFIG_POSIX_API block around some important functions like read(), write(), etc. Therefore, I have set the option as a dependency for zlib. ...

Now that this inaugural week is done, I have some time to reflect on what I’ve learned and what did/did not go well. I’ve learned that I definitely work best at the beginning of my day, as I can basically devote my time entirely to the project for a few hours before dealing with other things and working more intermittently throughout pretty much the rest of the day. However, there are some things that can distract me from keeping up the momentum for those first few hours. Therefore, I think that starting work earlier and adapting my environment to be free of those distractions is something I should look towards. ...

About the Project Printers are a technology that we often think should “just work,” but in reality, there are often many hoops to jump through when dealing with a printer’s drivers. It is a common experience when dealing with printers to struggle to get a document printed when trying every which way on an OS like modern Windows, but then all the problems suddenly disappear when using an Apple device. This is in large part thanks to Apple’s AirPrint, which is the oldest and most widely supported driverless printing protocol. The driverless nature is important as it prevents the issue of having printer drivers that may not be updated to support the user’s current operating system. However, AirPrint is not an open standard, and only Apple operating systems are designed with it in mind. This leads us to IPP Everywhere, a driverless printing protocol that is an open standard, and its pivotal role in the modern open-source printing stack developed by OpenPrinting. This would theoretically allow any operating system that supports the printing stack to print, as long as the printer supports IPP Everywhere. ...