You always could find deep niche where any high-level technology is not suitable.
I don't think you will program such device in C, rather in assembly, right? When you have like memory for 500 commands, it is easier to go directly to assembler, anyway, with such hardware as a target you don't need portability, this code is 100% hardware-dependable, at it is perfectly Ok.
BTW, which uC your have in mind when you talk about single-digit nA draw (in running state? in deep sleep?), because old 8-bit architectures typically are designed for older node processes and not as energy effective as new one, and draw in sleep doesn't depend much on RAM or FLASH size or architecture, it is more design philosophy.
Anyway, PIC16LF (20nA in deep sleep) or 8051 clone (50nA in deep sleep) or STM8 (~0.30 uA in halt) or ATtinys (100nA in deep sleep), which are covered by "768 bytes of flash and 64 bytes of RAM" description are comparable with EFM32 ARM32-M0+ (20nA in deep sleep), same with uA/Mhz, but ARM32-M0+ will do much more work for each Mhz, so it will be more efficient in the end (faster does all work and go to sleep again).
> Because the last time I looked it appeared to need some godawful slow bytecode interpreter that took up thousands of kilobytes of RAM.
Did you looked at java 1.2 at 1998 last time? Because after that there is compiler which produce some very efficient profile-guide-optimized code and do tricks like de-virtualization which is not possible with static compiler with support of multiple compilation units (like C++).
Really, there was time in history when HotSpot-compiled JVM bytecode was faster than everything that gcc could produce for comparable tasks. Yes, now this gap is reversed again, as both gcc and clang become much more clever, but still gap is not very wide now.
> Their slicer is open source but it downloads a plugin once you launch it if you choose to which is closed sourced that interacts with their APIs.
It is very dubious way to subvert GPL, even GPL2, not to mention [A]GPL3.
It was discussed many times that you cannot have close-sourced plugin for GPL host program, as loading plugin is linkage and it is covered by full GPL (only LGPL has linkage exclusion).
This extension piggyback SQLite native transactions. For example, queueing data will be rolled back if transaction is rolled back due to some constrains violations.
It is possible to achieve with external IPC, but require a lot of very careful programming.
honestly I used those types of extensions so little I didn't even consider notifications being transactional and firing only when transaction completes
I wish Thunderbird fix their plain text editor (it is at level of old Notepad, and chrome for it looks ugly, and line wrapping is a mess, especially with in-line quotation), add ability to store Folder properties (including Identity used for this folder, retention period and such) as IMAP properties and not locally to have same settings on different devices.
And, yes, proper support for Sieve, including per-folder Sieve. Sieve is a pain after they changed something and 3rd party Sieve plugin died (become Electorn Application).
Now Thunderbird has so many rough edges (I named only my top-3, but I'm sure anybody can add others!), but still one and only usable cross-platform e-mail client.
Oh, yes, development pace is unbearable slow: after killing "Manually sort folders" plugin it takes more than year (!) to add this as "core" feature with huge help from aforementioned plugun's author. Very slow process of review, integrating, releasing which takes MONTHS to integrate ready feature. It should be very discouraging for contributors.
Thunderbird now provide like 10% of features of old and almost forgotten (but still alive) windows-only client "The Bat!" from end of 1990s, beginning of 2000s and was written by team of like 5 people.
The breaking changes, broken extensions and other bugs stopped me from using it altogether... I still have it on my phone (that version is based on K9 though), but long ago stopped using the shared dropbox profile. The profile rolled forward a version and I could no longer revert to an older version because of bugs in the app itself.
I used to love Thunderbird... I also used it a lot with BBS centric NNTP hosts... at some point those features largely broke as well, and extensions to correct the behavior fell farther and farther behind as well.
The lack of a good calendar/contacts server solution is also a massive pain point imo.
> write with release semantic cannot be reordered with any other writes, dependent or not.
To quibble a little bit: later program-order writes CAN be reordered before release writes. But earlier program-order writes may not be reordered after release writes.
> Relaxed atomic writes can be reordered in any way.
To quibble a little bit: they can't be reordered with other operations on the same variable.
Perhaps I can place the monitor on my scanner and take a “screenshot” that way xD
Re: refresh rates I can’t find a good stat with a brief googling but it’s a Boox Mira, E Ink VB3300-NCD
You can tolerably watch video so somewhere north of 20fps but there’s ghosting. A friendly button on the front of the display is there to do a hard refresh if the artifacts build up too much. But yes I should do a comparison on how different desktop environments do, with animations turned off etc, scrolling that jumps line by line like vim or eMacs will work better than smooth scrolling for instance.
I've tried smartphone with e-Ink (mostly for motorcycle and hiking navigation, not as daily driver) and know this problem — it is impossible to share this experience via screenshots or screen recordings :)
I don't think you will program such device in C, rather in assembly, right? When you have like memory for 500 commands, it is easier to go directly to assembler, anyway, with such hardware as a target you don't need portability, this code is 100% hardware-dependable, at it is perfectly Ok.
BTW, which uC your have in mind when you talk about single-digit nA draw (in running state? in deep sleep?), because old 8-bit architectures typically are designed for older node processes and not as energy effective as new one, and draw in sleep doesn't depend much on RAM or FLASH size or architecture, it is more design philosophy.
Anyway, PIC16LF (20nA in deep sleep) or 8051 clone (50nA in deep sleep) or STM8 (~0.30 uA in halt) or ATtinys (100nA in deep sleep), which are covered by "768 bytes of flash and 64 bytes of RAM" description are comparable with EFM32 ARM32-M0+ (20nA in deep sleep), same with uA/Mhz, but ARM32-M0+ will do much more work for each Mhz, so it will be more efficient in the end (faster does all work and go to sleep again).
reply