Flickernoise now has an ephemeral cache for patches and images: compiled patches are kept when exiting a performance and the cached copies are used when starting a new performance. The cache is lost when rebooting.
Uptodateness of the caches patches is determined by stat'ing the file in question and comparing the modification time. This isn't entirely bullet-proof since time is non-monotonous in Flickernoise, but should still catch most changes. If a patch contains images, they are cached (and checked) as well. Note that images shared by multiple patches are treated as separate. The cache is pruned after each cycle. So if you demo some large patch collection and afterwards select a much reduced set to show how performance mode works, then don't be surprised when there'll be another long compile if you try to go back to the large collection. This cache should be handy for avoiding situations like Jon's Great Embarrassment, i.e., accidently dropping out of performance and then, for a seemingly endless compilation, haveing to endure the jeers of the audience delighting in your misfortune. I also found and fixed a few minor issues while implementing the cache: - the maximum size of a patch file was hard-coded to 32 kB. They're currently about 2 kB, but since we're now stat'ing all the files anyway, we can allocate the buffer dynamically. - likewise, the number of patches was hardcoded to 64, a limit we're about to hit. This array is now a linked list of arbitrary size. - "Display titles" in simple mode didn't work. I also changed the title display such that the title keeps on getting updated when switching patches. Before, if the title display was brought up with F1 (instead of "Display titles") the original title remained on the screen even after switching to another patch. - problems when loading images were silently ignored. Now, there are some basic error messages when an image file doesn't exist or when pixbuf doesn't like its content. Plus assorted internal fixes and cleanup. Regarding the accuracy of uptodateness detection: if a patch is updated just at the same time it was previously written, then the cache will not notice the difference. Since time in Flickernoise is reset to the beginning of the epoch on each boot, this is something that can happen in real life. A few possibilities to improve the odds: - use RTEMS-specific increased file timestamp resolution instead of POSIX 1 s resolution, - bump system time each time stat() finds a date in the "future", - include the file size in the comparison. But it's probably not worth a great effort to make the heuristic better. After the first change, any further changes to a patch (within the same session) will always be detected. - Werner _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode
