At Thu, 7 Oct 2010 16:23:33 -0700, John Clements wrote:
> Here's the student's backtrace. And yes, I now see that it *does* look like
> the font issue that Matthew mentioned.
Actually, this looks more like an OpenGL issue. I don't have any
immediate ideas, but that's a new lead.
> #4 0x7f
On Oct 7, 2010, at 3:25 PM, Kevin Tew wrote:
> I should have added that the student also needs to type
> gdb> backtrace
> to get a full backtrace.
>
> a full backtrace will be more informative.
Duh, yes.
Here's the student's backtrace. And yes, I now see that it *does* look like
the font i
I should have added that the student also needs to type
gdb> backtrace
to get a full backtrace.
a full backtrace will be more informative.
racket segfaults always end in with a SIGABRT due to our custom use of
the SIGSEGV handler.
So the stack below is typical of segfaults.
On 10/07/2010 04
On Oct 5, 2010, at 10:37 AM, Kevin Tew wrote:
> I build on 64bit ubuntu every day.
> a gdb backtrace would be helpful.
>
> gdb> handle SIGSEGV nostop noprint
> gdb> run
>
> Kevin
I finally got a reply from the student. Here's what he said:
> Ok, sorry this took so long, but I had to do the ri
> I don't think we ever found a workaround, but you could double-check
> this thread:
>
> http://lists.racket-lang.org/dev/archive/2010-July/003692.html
Thanks. I played around with enabling/disabling debugging and
profiling options like Doug did and now the error is gone (regardless
of what butt
> I don't suppose you get a stacktrace with the error?
No, it's just the error message. Although it seems to only happen in
drracket. I cant recreate the error from the command line.
> On Thu, Oct 7, 2010 at 3:35 PM, Stephen Chang wrote:
>> Has anyone seen an error like this before:
>>
>> st
I don't suppose you get a stacktrace with the error?
Robby
On Thu, Oct 7, 2010 at 3:35 PM, Stephen Chang wrote:
> Has anyone seen an error like this before:
>
> string as 1st argument, given: #f; other
> arguments were: "dcdf0433aca16ea2f5db9a003821f56a718d2da5"
>
> I'm using an older version of
At Thu, 7 Oct 2010 16:35:48 -0400, Stephen Chang wrote:
> Has anyone seen an error like this before:
>
> string as 1st argument, given: #f; other
> arguments were: "dcdf0433aca16ea2f5db9a003821f56a718d2da5"
>
> I'm using an older version of racket, 5.0.0.6, but I havent seen the
> error until rec
Has anyone seen an error like this before:
string as 1st argument, given: #f; other
arguments were: "dcdf0433aca16ea2f5db9a003821f56a718d2da5"
I'm using an older version of racket, 5.0.0.6, but I havent seen the
error until recently. I get the error when I run certain files in
drracket. I started
Neil Van Dyke wrote:
For testing, I think you need not just the target processor but also
various OS and chipset/firmware stuff.
Indeed. It's a thorny issue. The Openmoko phone, for instance, had a
custom configuration of qemu that simulated the GSM radio, the GPS, the
sound chip etc etc.
Q
I've found "qemu" to be a godsend for systems work, though very slow
compared to real metal, unless you're using virtualization extensions
like KVM. I don't know how ARM "qemu" hosted on fast non-ARM hardware
compares to native on typical ARM hardware, but I'm not too optimistic
about that unt
Noel Welsh wrote:
Also, if someone had an accessible ARM device any crazy people who
were developing, e.g., assemblers, on Racket would be able to target
that platform (and hence iPhone, iPad, and Android devices).
You know qemu's ARM emulation is fairly complete, right?
Tony
Some time ago Jay asked if anyone had a hardware suggestion for an ARM
PC. I don't think anyone answered; in my case that was because there
wasn't a capable device that I knew of. The Pandaboard --
http://pandaboard.org/ -- which is supposed to start shipping this
month looks like it might be viabl
13 matches
Mail list logo
