[racket-dev] Caching rendered icons

10 minutes ago, Neil Toronto wrote:
> I agree with everybody, especially Sam. :)
> 
> We're supposed to have a rich compiler extension API, in which
> programs evaluated at expansion time are just as capable as runtime
> programs.  Further, "building Racket" means "expanding Racket code
> fully" which means "running Racket code," so the build environment
> should be the same as the runtime.

This is confusing details.  Yes, in Racket you can do at compile time
everything that you can do at run time, but that's true for *every*
language.  It would take more work, of course, but code that renders
png files or whatever as part of your build process is nothing new.


> Ideally, we would get these servers up to snuff.

It might be possible, but I don't want to do so for several reasons,
in increasing order of importance: (1) I don't want to add
administration of an (ancient) OSX machine to my pile; (2) I don't
want to put conditions up for people who volunteer servers (I still
hope to get a *BSD machine at some point, and it's extremely popular
to find these in a no-gui setup); (3) most importantly, I imagine that
such errors would strongly discourage people with such setups from
using Racket.  The last point was actually relevant for a long time,
with the GL stuff causing errors -- the answer to that was always
simple: you won't be able to use only the stuff that depends on GL,
which is a few games -- but when you deal with "the masses" there is
no magical collective memory and this came up again and again, and
people *did* worry about those warnings even when their intention was
to run a web server.


> I can see how we might need to make concessions, though, so I'm
> willing to toss my elegant solution (*sniff*) and go with runtime
> rendering and caching.

I don't see why give up the compiled form completely, especially when
you already have that code in working shape.  It's true that ideally
you'd have caching on top of dynamic renderers and pre-compiled ones,
but losing the cached ones doesn't seem like a big deal.  Even more:
having all icons cached means that the interface should include a way
to disable caching, for cases where I dynamically create lots of
one-time icons.  If instead the interface is simplified to a simple
API which can under some conditions pre-compile the icons then the
whole thing doesn't lose much.


> Eli, when you wrote
> 
>  > The temp directory is a bad idea because it's shared.  The
>  > preferences would be much better, but you'd need to worry about
>  > locking too.
> 
> did you mean locking the preferences file, or the preferences
> directory?  If I used a subdirectory of the preferences directory
> and MD5 sums in filenames, why would I need to lock anything?

Locking the directory where you write the caches to, in case two drrs
try to write to the same file.  (But I really prefer the above.)
-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!