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<e...@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<sa...@ccs.neu.edu> wrote:
On Fri, Jan 13, 2012 at 4:46 PM, Eli Barzilay<e...@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
sa...@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
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
