Matthew,
I think you have something there with the -g flag. i just compiled
racket myself. I can see gcc receiving the -g flag. Running the
produced binaries provides the stack trace.
I think I need to open a bug report against debian's racket packages.
Thanks for you help,
--
Chad
On Thu,
No, that's not the way Racket works. :)
There is something wrong and our messages are designed to figure out
what that is. Thanks for your patience. I think Matthew's message is
next on the list to answer.
Robby
On Wed, Jun 27, 2012 at 10:15 PM, Chad Albers wrote:
> Yes, intel/amd 64 bit.
>
> I
Yes, intel/amd 64 bit.
I don't have a .racketrc...I need to find out why I need that in the docs.
I did you -j and success! I got a stack trace.
So, that brings up a question. Is there a way to support stack traces
without disabling the jit compiler? I understand that stack traces add
a certa
I should have also mentioned that using -j to disable the JIT (as Robby
suggested) should also give you context independent of the platform or
the way that Racket is compiled.
At Wed, 27 Jun 2012 20:28:53 -0600, Matthew Flatt wrote:
> I wonder whether the problem could be related to compilation op
I wonder whether the problem could be related to compilation options.
Did you compile your own executable? If so, what flags were given to
`configure' and/or the C compiler?
On x86_64 Linux, Racket uses DWARF information to walk parts of the
runtime stack. It occurs to me that if you use gcc witho
By 64 bit architecture, I assume it is an intel/amd chip?
What happens if you pass -j on the command-line to racket when you try
this? (You don't have a .racketrc, right?)
Does the test suite pass? You'd run that with
racket -qr plt/collects/tests/racket/quiet.rktl
(where "plt" is the path t
Hi Eli,
Here's the file that I'm running in a gist: https://gist.github.com/3003496
In other words, it's a cut-and-paste of code that you posted earlier
in this chain:
#lang racket
(with-handlers ([void (λ (e)
(continuation-mark-set->context
(ex
Two days ago, Michael Wilber wrote:
> If I understand correctly, by default, Racket doesn't provide forms
> with stack trace information when running from the CLI by
> default.
It does (and I tried my examples on both racket and drracket).
> Does it work from within DrRacket? If so, look into th
What architecture?
Robby
On Tue, Jun 26, 2012 at 2:37 AM, Chad Albers wrote:
> I'm using Debian Linux.
> --
> Chad Albers
>
>
> On Sun, Jun 24, 2012 at 10:08 PM, Matthew Flatt wrote:
>> What platform are you using?
>>
>> If it's Win64, the problem is likely Racket's weak support for getting
>>
It doesn't produce a stack trace of DrRacket.
Also, it doesn't produce a stack trace if I include the errortrace on
the command line.
:(
--
Chad Albers
On Mon, Jun 25, 2012 at 2:29 AM, Michael Wilber wrote:
> If I understand correctly, by default, Racket doesn't provide forms with
> stack trac
I'm using Debian Linux.
--
Chad Albers
On Sun, Jun 24, 2012 at 10:08 PM, Matthew Flatt wrote:
> What platform are you using?
>
> If it's Win64, the problem is likely Racket's weak support for getting
> a backtrace on that platform (when the JIT is enabled).
>
> At Sun, 24 Jun 2012 22:01:02 +0900
If I understand correctly, by default, Racket doesn't provide forms with
stack trace information when running from the CLI by default. Does it
work from within DrRacket? If so, look into the errortrace module, or
add (require errortrace) to the top of the .rkt, or run it like this:
racket -l errort
What platform are you using?
If it's Win64, the problem is likely Racket's weak support for getting
a backtrace on that platform (when the JIT is enabled).
At Sun, 24 Jun 2012 22:01:02 +0900, Chad Albers wrote:
> Hi Eli,
>
> Thanks for you help. Unfortunately, it doesn't seem to work. I
> lite
Hi Eli,
Thanks for you help. Unfortunately, it doesn't seem to work. I
literally cut the code and pasted in a rkt file with #lang racket at
the top. I ran it with the racket CLI, and received: '()
Should I be invoking the CLI with some option? Any other ideas?
--
Chad
On Sun, Jun 24, 2012
A few minutes ago, Chad Albers wrote:
> Hi,
>
> Is there some sort of 'secret' to acquiring the stack trace of an
> exception? It is my understanding that when an exception is raised
> with the 'error' procedure in creates a exn:fail structure that has
> a message field and a continuation-marks f
Hi,
Is there some sort of 'secret' to acquiring the stack trace of an
exception? It is my understanding that when an exception is raised
with the 'error' procedure in creates a exn:fail structure that has a
message field and a continuation-marks field. Presumably the stack
trace is in the conti
16 matches
Mail list logo
