It wasn't that I forgot to implement pieces, after all. The problem was
a bug in the byte compiler's handling of `#%variable-reference` when
inlining. I've pushed a repair.
At Mon, 12 Jan 2015 19:24:56 -0700, Matthew Flatt wrote:
> It's supposed to be safe; the behavior in this example is definite
It's supposed to be safe; the behavior in this example is definitely a
bug.
The `#%variable-reference` form used to work only on top-level and
module variables. It seems that I forgot to fill in some pieces when I
made `#%variable-reference` work on local bindings (several years ago,
mainly for us
aha! That fixed it. Thanks.
On Thu Jan 08 2015 at 6:18:12 AM Matthew Flatt wrote:
> Do you have the latest "images-doc" and/or "gui-lib" packages?
>
> Recently, there was a problem with the "images" documentation where it
> tried to use `racket/gui` at document-build time. At the same time,
> th
Do you have the latest "images-doc" and/or "gui-lib" packages?
Recently, there was a problem with the "images" documentation where it
tried to use `racket/gui` at document-build time. At the same time,
there was also a problem in `racket/gui` that could cause a crash
(mainly on Mac OS X) after `ra
Thanks for the report! This information looks consistent with a bug
that I recently fixed in the development version, and I've recommended
a back-ported repair to be included in v5.3.6.
At Thu, 25 Jul 2013 18:31:13 +0700 (NOVT), "oev" wrote:
> It seems like the problem is kind of described at
> ht
The latest commit d408ba4 fixes this for me.
On 02/13/2013 10:14 AM, Asumu Takikawa wrote:
> On 2013-02-13 10:36:09 -0600, Robby Findler wrote:
>>I don't know what would help, but one thing that usually does is a stack
>>trace. You can probably get it from a coredump file or by something l
On 2013-02-13 10:36:09 -0600, Robby Findler wrote:
>I don't know what would help, but one thing that usually does is a stack
>trace. You can probably get it from a coredump file or by something like
>this:
>$ gdb `which racket`
> [... stuff ...]
>(gdb) set args -l setup
>
I'm trying a clean build now, and maybe the problem will be obvious.
At Wed, 13 Feb 2013 10:36:09 -0600, Robby Findler wrote:
> I don't know what would help, but one thing that usually does is a stack
> trace. You can probably get it from a coredump file or by something like
> this:
>
> $ gdb `wh
I don't know what would help, but one thing that usually does is a stack
trace. You can probably get it from a coredump file or by something like
this:
$ gdb `which racket`
[... stuff ...]
(gdb) set args -l setup
(gdb) run
On Wed, Feb 13, 2013 at 10:24 AM, Asumu Takikawa wrote:
> Hi all,
On 2013-02-13 11:24:35 -0500, Asumu Takikawa wrote:
> I get a reproducible segfault when I built Racket from git HEAD. This is
> what I see:
A git bisect seems to pinpoint the segfault to commit
4a0adb6a74630f4afc7fd85275ffca76836037b4.
Cheers,
Asumu
_
Racket Developers
10 matches
Mail list logo
