-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12-01-12 18:27, Gregory Cooper wrote:
Hi Marijn,
The value-now/sync procedure waits for propagation to complete
before reading a signal's value. Would something like the
following suit your purposes?
(define a (event-receiver)) (define b
IMO there's no conceptual difference between what Neil implemented and
other kinds of constant foldings, and having a separate `foo' and
`compile-foo' sounds bad in being too low-level, in the same way that
using `#define' in C to get inlining leads to bogus code.
Yesterday, Robby Findler wrote:
Yesterday, Neil Toronto wrote:
Here's an example that bakes a list of stickman animation frames into a
compiled module:
(begin-for-syntax
(require images/icons/stickman)
(define stickman-height 18)
(define num-running-frames 12))
(define running-frames
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
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
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
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
An hour and a half ago, 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).
What I suggested would lead to having that delay at startup, but other
than that it would work fine.
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
On Fri, Jan 13, 2012 at 7:09 PM, Neil Toronto neil.toro...@gmail.com 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
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
On 01/13/2012 06:16 PM, Robby Findler wrote:
On Fri, Jan 13, 2012 at 7:09 PM, Neil Torontoneil.toro...@gmail.com 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
40 minutes ago, Neil Toronto wrote:
I have two problems with this. One of them I also have with Eli's
suggestion: we'd end up with Racket distributions that have
different performance characteristics depending on where they were
compiled.
Our distributions would not. For compilation, you
At Fri, 13 Jan 2012 18:01:22 -0500, Eli Barzilay wrote:
We don't own some of them,
LD_LIBRARY_PATH
and some have no maintainer.
Let's drop them. While we may lose some testing benefit, it's not worth
trying to create builds for systems that have almost no users.
The first is
also an
14 matches
Mail list logo
