[racket-dev] Caching rendered icons

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. Ideally, we would get these servers up to snuff.

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.

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?

Neil T


On 01/13/2012 04:09 PM, Robby Findler wrote:
> I don't think we want to actually deploy _that_ DrRacket on a desktop
> (one where the construction of the rendered images happens during
> startup).
>
> (But I don't see a good solution to this problem.)
>
> Robby
>
> On Fri, Jan 13, 2012 at 5:01 PM, Eli Barzilay<eli at barzilay.org>  wrote:
>> We don't own some of them, and some have no maintainer.  The first is
>> also an indication of a lost feature: being able to compile racket on
>> a typical server and deploy on a desktop.
>>
>> On 2012-01-13, Sam Tobin-Hochstadt<samth at ccs.neu.edu>  wrote:
>>> On Fri, Jan 13, 2012 at 4:46 PM, Eli Barzilay<eli at barzilay.org>  wrote:
>>>> Yesterday, Neil Toronto wrote:
>>>>> On 01/12/2012 12:22 PM, Eli Barzilay wrote:
>>>>>>> Is there a way to reliably get the "compiled" directory path during
>>>>>>> expansion, and then load files from it at runtime? Can I ensure that
>>>>>>> .PNG files are distributed automatically?
>>>>>>
>>>>>> Putting other stuff in compiled directories would probably complicate
>>>>>> distributions (of both kinds), so the compile-to-bytestring is really
>>>>>> better.  (One possible thing to keep in mind is to avoid compilation
>>>>>> relying on having a display.)
>>>>>
>>>>> Just to double-check: ever since the big GUI rewrite, I can use
>>>>> racket/draw without needing a display, right?
>>>>
>>>> And this broke the build on three machines -- two of them are servers,
>>>> and one is a PPC machine that wasn't for anything except for the
>>>> builds in a long time.
>>>>
>>>>   raco setup:  in images
>>>>   ffi-lib: couldn't open "libcairo.so.2" (libcairo.so.2: cannot open
>>>>   shared object file: No such file or directory)
>>>>
>>>> One possible way out: make it fall back to the dynamic case when
>>>> there's no cairo present.  The zo files in the distribution are all
>>>> from the main machine which does have cairo installed.  (That would
>>>> further bogosify a `compiled-' prefix though.)
>>>
>>> I think we should just install cairo on these machines -- we shouldn't
>>> be building on machines where we couldn't run Racket effectively.
>>> --
>>> sam th
>>> samth at ccs.neu.edu
>>>
>>
>>
>> --
>>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>>                   http://www.barzilay.org/                 Maze is Life!
>>
>> _________________________
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev