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! _________________________ Racket Developers list: http://lists.racket-lang.org/dev