Correct.
On Feb 13, 2013, at 6:05 PM, Danny Yoo wrote:
> On Wed, Feb 6, 2013 at 5:17 PM, Danny Yoo wrote:
>>> How likely is that authors of planet2 packages use the released version
>>> rather than the git head version?
>>
>>
>> Ok, I rescind my point then, since PLaneT2 is in beta.
>
>
My apologies for letting this hang.
The current state of this bug repair is that I've got a patch on:
https://github.com/dyoo/racket/commit/compiler-hack
that addresses the issue of installing PLaneT2 packages while in DrRacket.
However, there was some parallel conversation about what the
On Wed, Feb 6, 2013 at 5:17 PM, Danny Yoo wrote:
>> How likely is that authors of planet2 packages use the released version
>> rather than the git head version?
>
>
> Ok, I rescind my point then, since PLaneT2 is in beta.
But just to confirm, the release isn't waiting for anything on my end, ri
> Could you take over as bug czar? -- Matthias
>
I can not do this at this time.
_
Racket Developers list:
http://lists.racket-lang.org/dev
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
>
Sure. I'll add that.
Robby
On Wed, Feb 13, 2013 at 10:41 AM, Pierpaolo Bernardi wrote:
> (I know how to add them, but maybe should be included out of the box?)
>
> Cheers
>
>
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
>
>
___
(I know how to add them, but maybe should be included out of the box?)
Cheers
_
Racket Developers list:
http://lists.racket-lang.org/dev
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
Hi all,
I get a reproducible segfault when I built Racket from git HEAD. This is
what I see:
raco setup: 7 making: redex/examples (Reduction Semantics examples)
reverse: contract violation
expected: list?
given: 4193052015854236082
SIGSEGV SI_KERNEL SI_CODE 128 fault on addr (nil) sent by ke
I pushed a fix to this issue.
Jay
On Tue, Feb 5, 2013 at 5:36 PM, Danny Yoo wrote:
> I tried the following:
>
>
> 128-110-72-21:ragg dyoo$ ~/local/racket/bin/raco pkg remove ragg
> raco pkg remove: cannot remove packages that are dependencies of other
> packages
> dependencies:
>ragg
>
>
13 matches
Mail list logo
