On Mon, Sep 19, 2005 at 02:22:10PM +0100, Glynn Clements wrote:
>
> Frederik Eaton wrote:
>
> > In addition to the stack trace problems, I found: (1) a problem where
> > output freezes when it is being piped through 'tee' and the user
> > presses ^S and then ^Q
>
> That's the terminal driver; us
Frederik Eaton wrote:
> In addition to the stack trace problems, I found: (1) a problem where
> output freezes when it is being piped through 'tee' and the user
> presses ^S and then ^Q
That's the terminal driver; use "stty -ixon" to disable that.
If your program requires "raw" keyboard input,
On 19 September 2005 03:57, Frederik Eaton wrote:
>>> It could be a bug - can you reduce the example and report it?
>>>
>>> GHC's profiler tries to overlay a lexical call graph on to the
>>> dynamic execution of the program. It does this more or less in the
>>> way you described before: every fu
> > It could be a bug - can you reduce the example and report it?
> >
> > GHC's profiler tries to overlay a lexical call graph on to the dynamic
> > execution of the program. It does this more or less in the way you
> > described before: every function gets an extra argument describing the
> > ca
On Wed, Sep 14, 2005 at 02:44:11PM +0100, Simon Marlow wrote:
> On 10 September 2005 21:15, Frederik Eaton wrote:
>
> > On Fri, Sep 02, 2005 at 04:40:05PM +0400, Bulat Ziganshin wrote:
> >> Hello Nils,
> >>
> >> Friday, September 02, 2005, 10:47:05 AM, you wrote:
> >>
> >>> Compile your prog
On 10 September 2005 21:15, Frederik Eaton wrote:
> On Fri, Sep 02, 2005 at 04:40:05PM +0400, Bulat Ziganshin wrote:
>> Hello Nils,
>>
>> Friday, September 02, 2005, 10:47:05 AM, you wrote:
>>
>>> Compile your program with -prof -auto-all (make sure you have
>>> the
>>
>>> I tried this out
On Fri, Sep 02, 2005 at 04:40:05PM +0400, Bulat Ziganshin wrote:
> Hello Nils,
>
> Friday, September 02, 2005, 10:47:05 AM, you wrote:
>
> NAD> Compile your program with -prof -auto-all (make sure you have the
>
> NAD> I tried this out under GHC 6.4/Linux and got a segmentation fault
> NAD>
On Mon, 2005-09-05 at 11:12 +0100, Malcolm Wallace wrote:
> > Why is this a Cabal issue? Are you interested in adding Buddah
> > support to Cabal?
>
> I think what Bernie is referring to is that ghc-pkg-6.4 uses an input
> file format very similar to Cabal's file format, for registering a
> new
Isaac Jones <[EMAIL PROTECTED]> writes:
> >> 1. Hat requires users to restrict themselves to a certain small subset
> >> of the standard libraries, and to use hmake
> >
> >Also the issue of how libraries are
> > distributed in Haskell is a little bit in flux at the
Bernard Pope <[EMAIL PROTECTED]> writes:
> On Thu, 2005-09-01 at 14:48 -0700, Frederik Eaton wrote:
(snip)
>> Are the following correct?
>>
>> 1. Hat requires users to restrict themselves to a certain small subset
>> of the standard libraries, and to use hmake
>
> Depends what you mean by standar
> Just more or less as an aside, at its origin in April (!) this thread
> didn't mention any debugger - the question was just how to build ghc
> so that a stack trace would come out. A real debugger is no replacement
> for that (because you have to be on hand and know how to repeat the problem
> t
On Fri, 2 Sep 2005 [EMAIL PROTECTED] wrote:
...
> I was trying to debug a smallish program where I was getting this exact error
> and the trick with profiling did "work" on my system, but I remember it being
> almost useless for me. What what did end up working for me was:
> myhead :: [a] -> Strin
Quoting Nils Anders Danielsson <[EMAIL PROTECTED]>:
> On Thu, 01 Sep 2005, Frederik Eaton <[EMAIL PROTECTED]> wrote:
>
> > But getting a stack backtrace when there is an error should be a
> > pretty basic feature. It's very hard to debug a large program when you
> > can randomly get messages like
Hello Nils,
Friday, September 02, 2005, 10:47:05 AM, you wrote:
NAD> Compile your program with -prof -auto-all (make sure you have the
NAD> I tried this out under GHC 6.4/Linux and got a segmentation fault
NAD> instead of a stack trace. Under GHC 6.2.2 it seemed to work, though.
this error
On Fri, Sep 02, 2005 at 05:10:35PM +1000, Ben Lippmeier wrote:
>
> >>... It's very hard to debug a large program when you
> >>can randomly get messages like "*** Exception: Prelude.head: empty
> >>list" and have no idea where they came from.
> >
>
> As a purely pragmatic suggestion: don't use he
Nils Anders Danielsson <[EMAIL PROTECTED]> writes:
> My program is failing with head [], or an array bounds error, or some
> other random error, and I have no idea how to find the bug. Can you
> help?
>
> Compile your program with -prof -auto-all (make sure you have the
> profiling librari
... It's very hard to debug a large program when you
can randomly get messages like "*** Exception: Prelude.head: empty
list" and have no idea where they came from.
As a purely pragmatic suggestion: don't use head, fromJust, last, or any
other function that is likely to fail in impossible-
On Thu, 01 Sep 2005, Frederik Eaton <[EMAIL PROTECTED]> wrote:
> But getting a stack backtrace when there is an error should be a
> pretty basic feature. It's very hard to debug a large program when you
> can randomly get messages like "*** Exception: Prelude.head: empty
> list" and have no idea w
On Thu, 2005-09-01 at 14:48 -0700, Frederik Eaton wrote:
> Is it that backtraces are difficult, or just require a lot of
> overhead? It doesn't seem very hard to me, at least in principle. Add
> a "stack trace" argument to every function. Every time a function is
> called, the source location of t
On Wed, Apr 27, 2005 at 05:15:30PM +1000, Bernard Pope wrote:
> On Wed, 2005-04-27 at 07:45 +0200, Ketil Malde wrote:
> > > [I want to know] who called who all the way from "main" to "head",
> > > because the key function is going to be one somewhere in the middle.
> >
> > Perhaps. I am told stac
On Wed, 2005-04-27 at 07:45 +0200, Ketil Malde wrote:
> > [I want to know] who called who all the way from "main" to "head",
> > because the key function is going to be one somewhere in the middle.
>
> Perhaps. I am told stack backtraces are difficult with non-strict
> semantics.
This is true, a
Donn Cave <[EMAIL PROTECTED]> writes:
>> Ideally, I think something like this should be the default behavior
>> for these functions.
> But something like this should happen for any function, shouldn't
> it?
Any function where pattern match could fail, yes. (Or should that be
any partial functi
Thanks, Ketil, your suggestion really helped me ! Thanks to Claus for the tips !
On 4/26/05, Ketil Malde <[EMAIL PROTECTED]> wrote:
>
> "Claus Reinke" <[EMAIL PROTECTED]> writes:
>
> > no direct answer to your question, but a general comment on the
> > original problem (speaking from bad experie
On Tue, 26 Apr 2005, Ketil Malde wrote:
> "Claus Reinke" <[EMAIL PROTECTED]> writes:
>> no direct answer to your question, but a general comment on the
>> original problem (speaking from bad experience;-): things like
>> "head" have no place in a Haskell program of any non-trivial size,
>> because
Hi, all,
I'm developing a back end for GHC and I have the following problem:
my program is throwing an "empty list exception" due to head [] and I
need to compile GHC with -prof -auto-all in order to see the stack
trace when running it with +RTS -xc -RTS. I changed the makefile but
the option +
"Claus Reinke" <[EMAIL PROTECTED]> writes:
> no direct answer to your question, but a general comment on the
> original problem (speaking from bad experience;-): things like
> "head" have no place in a Haskell program of any non-trivial size,
> because of their useless error messages.
I must say
> I'm developing a back end for GHC and I have the following problem:
> my program is throwing an "empty list exception" due to head [] and I
> need to compile GHC with -prof -auto-all in order to see the stack
> trace when running it with +RTS -xc -RTS. I changed the makefile but
> the option +
Hi, all,
I'm developing a back end for GHC and I have the following problem:
my program is throwing an "empty list exception" due to head [] and I
need to compile GHC with -prof -auto-all in order to see the stack
trace when running it with +RTS -xc -RTS. I changed the makefile but
the option +RT
28 matches
Mail list logo
