I finally moved to GHC 7.0.3, a rather late update :)
I updated GhciExt for it and if you want to script ghci commands a bit
you can grab it as an example and use. It probably works well enough. I
was lucky and did not use debugger a lot lately, so I'm not sure.
On 07/30/2011 10:25 PM, Ian Lynagh wrote:
On Mon, Jul 25, 2011 at 06:21:16PM +0200, Peter Hercek wrote:
Is it a bug? Should it be reported to the ghc trac database?
Please report it and we'll take a look.
Thanks
Ian
It is done:
http://hackage.haskell.org/trac/ghc/ticket/5363
Peter
Here is a test program (file name prgSrc.hs):
import Data.Array.Unboxed
main = do
let l1 = [1..10] :: [Int]
let l2 = [ map (i+) l1 | i - [1..500] ]
let l3 = map (\l - listArray (1,length l) l) l2 :: [UArray Int Int]
print $ accumulate l3 0
accumulate [] rv = rv
accumulate (h:t) rv
Hi,
I got this deprecation warning:
Warning: Module `GHC.Handle' is deprecated:
use GHC.IO.Handle.Base instead
But I think it should have been:
Warning: Module `GHC.Handle' is deprecated:
use GHC.IO.Handle instead
There is no GHC.IO.Handle.BAse in my
Simon Marlow wrote:
On 20/10/2009 14:54, Ralph Crawford wrote:
So far so good. This is what I want to see - a listing like this for
every (interpreted of course) line of haskell code that runs, all the
way to the end. Since this is a very large program, at this point I
started pasting this to
Simon Marlow wrote:
On 19/08/2009 10:18, Peter Hercek wrote:
Why is stg_nofoceIO_info added as last argument to IO actions in
unregistered mode? Do I still need to pass it in even when (I think) my
IO action does not need it? E.g. is it required for every IO action by
some stack walking code
Ian Lynagh wrote:
We are aiming to have the first release candidate out on the 14th
September 2009.
Until then, we plan to focus on the bugs in the 6.12.1 milestone, marked
high priority; they are listed here:
Hi,
I thought I may look at the :next command for GHCi debugger again. If I
do, I will not make it before 6.12.1 is out. I have few questions about
RTS in relation to :next implementation. If they is easy to answer I
would appreciate it, if not, don't bother since I'm not sure I'll do it
...
On Fri, 14 Aug 2009 14:50:48 -0400, S. Alexander Jacobson wrote:
Is there a way from GHCi to discover the path to a particular module
that you have imported or loaded?
It may not be what you wanted but in the worst case you can use ghc-pkg
list to see all the package names then for each name
On Mon, 13 Jul 2009 20:48:42 -0400, Isaac Dupree wrote:
Peter Hercek wrote:
Simon Marlow wrote:
On 10/07/2009 15:31, Peter Hercek wrote:
It would be cool if ghci debugger could grab not only the free
variables in the selected expression but in one case a bit more. The
case is when we stop
Simon Marlow wrote:
On 10/07/2009 15:31, Peter Hercek wrote:
Hi,
It would be cool if ghci debugger could grab not only the free variables
in the selected expression but in one case a bit more. The case is when
we stop at a function definition the first time (when just entering
Hi,
It would be cool if ghci debugger could grab not only the free variables
in the selected expression but in one case a bit more. The case is when
we stop at a function definition the first time (when just entering it).
In this case it should provide bindings of the function arguments. Is
On Wed, 17 Jun 2009 13:59:24 +0200, Peter Hercek wrote:
* If your code happens to have definitions on lines which happen to
exist more times in one source file then it may put you at an
incorrect location. I doubt it will ever happen but if anybody thinks
it is really bad we can keep
Simon Marlow wrote:
I'm an infrequent etags user, and I never use ctags.
The problem is I do not know whether I should try to improve etags too.
So far I tried to keep them the same they were. The only difference I
know about is that if more tags happen to exist on the same source line
then
Hi GHC and VI users,
I got frustrated with vi tags not working after some unrelated code is
edited in a source file. Moreover non-exported top level declarations
were not available in vi tags file. Here is an attempt to fix it:
http://www.hck.sk/users/peter/pub/ghc/betterCTags.patch
Why
Claus Reinke wrote:
Haskell isn't like other languages. If you search on source lines of
definitions, that'll break every time you change a pattern, parameter
name, parameter order, clause order, ..
This is what I do. The whole line is searched to avoid as much of false
positives as possible.
Simon Marlow wrote:
On 28/05/2009 15:09, Claus Reinke wrote:
so for mere
traces, dynamic seems to be the choice (with an option of pseudo-cbv
or the real dynamic stack).
I don't know what pseudo-cbv is. And I claim the dynamic stack is
almost never what you want.
Ok, so there's one place
Dean Herington wrote:
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
... cut ...
Loading package mtl-1.1.0.2 ... linking ... done.
Loading package glib-0.10.0 ... can't load .so/.DLL for: intl (addDLL:
could not load DLL)
Ok, I do not use windows more than a year now exactly
Ok, I went with the preprocessor solution only. It is simple, stupid and
works well enough ... and template haskell alternative needs it anyway
not to be too unportable.
Both template haskell alternatives reported Pattern match(es) are
non-exhaustive of their own. The second alternative
...@haskell.org] On Behalf Of Peter Hercek
| Sent: 18 May 2009 10:46
| To: glasgow-haskell-users@haskell.org
| Subject: Re: Should exhaustiveness testing be on by default?
|
| Neil Mitchell wrote:
| I'm not a particular fan of exhaustiveness checking. It just
| encourages people to write:
|
| foo (Just 1
Claus Reinke wrote:
Given how long http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack
has been under discussion, it is probably time to provide a short-term
workaround in GHC, just a token to be replaced by the current source
location.
This would be the best solution.
Although
Neil Mitchell wrote:
I'm not a particular fan of exhaustiveness checking. It just
encourages people to write:
foo (Just 1) [x:xs] = important case
foo _ _ = error doh!
So now when the program crashes, instead of getting a precise and
guaranteed correct error message, I get doh! - not
Hi,
I know there were 4 unique IP addresses which checked it out. Since I do
not know who they are I just spam this list again :)
You can get it here: http://www.hck.sk/users/peter/pub/
If you decide to give it a try then read the README file before installing.
It should work with the stock
Simon Marlow wrote:
Peter Hercek wrote:
The proposed meaning for :next
Lets mark dynamic stack size at a breakpoint (at which we issue
:next) as breakStackSize and its selected expression as breakSpan.
Then :next would single step till any of these is true:
1) current dynamic stack size
Hi,
Maybe the code adding one Int argument to rts_breakpoint_io_action is
correct in general since when Pepe Iborra applied the patch to his ghc
trunk the test did not crash on his machine. Regardless on my machine
the test does not work even with the stock ghc 6.10.2 sources (so even
when I
Hi,
Pepe Iborra pointed out that my patch is not in the right format for gnu
patch command.
Sorry for inconvenience (I used darcs what -u instead of darcs diff -u).
Here it is attached in the correct format.
Thanks,
Peter.
diff -rN -u old-ghc/compiler/main/InteractiveEval.hs
Hi,
So I wanted to give implementing :next ghci debugger command a shot. It
looked easy and I could use it. Moreover it would give me an easy way to
implement dynamic stack in ghci (using similar approach as used for
trace) ... well if I would feel like that since I was a bit discouraged
Simon Marlow wrote:
Peter Hercek wrote:
Hi GHCi users,
I would like to be able to redefine the built-in GHCi commands. The
idea is that when searching for a command the user defined commands
would be searched first and only then the built-in commands would be
searched. If user wants
Malcolm Wallace wrote:
In a lazy language, the dynamic stack rarely tells you anything of
interest for debugging. For the value at the top of the stack, you get
one of many possible _demand_ chains, rather than the creation chain.
The demanding location is pretty-much guaranteed not to be the
Simon Marlow wrote:
Peter Hercek wrote:
Sure, but the plan to maintain an approximate debugging dynamic stack
depends on one thing:
The number of items (continuations) on the return stack from the
beginning of /case tickn of {_-e}/ to the moment when we can check
the count of items
Hi GHCi users,
I would like to be able to redefine the built-in GHCi commands. The idea
is that when searching for a command the user defined commands would be
searched first and only then the built-in commands would be searched. If
user wants to invoke a built-in command regardless of user
Hi GHCi users,
The example is at the end of this email.
I think it is a bug that the second part (:continue) of the command
`:cmd return rv\n:continue' is executed in a different context than
the first part (rv (request for the value of rv variable)). Notice that
we did not stop at breakpoint
Simon Marlow wrote:
Perhaps you're already aware of this wiki page, but I'll post the link
anyway:
http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack
I was writing about a way how to maintain the stack as described in
point 6 of the page (provided that point is about dynamic stack).
Peter Hercek wrote:
Pepe Iborra wrote:
- Regarding your :logLocal, you should rename it to :stepLocal, open a
ticket, and attach your patch. We should really try to get this into
6.10.2.
Ach, I missed I'm supposed to do this first time I read the message.
I'll get to it at worst during
Pepe Iborra wrote:
- Regarding your :logLocal, you should rename it to :stepLocal, open a
ticket, and attach your patch. We should really try to get this into
6.10.2.
Ach, I missed I'm supposed to do this first time I read the message.
I'll get to it at worst during this weekend.
pepe wrote:
Having (a kind of messy approximation of) a dynamic stack is possible
with a variant of the cost center stacks mechanism used for profiling.
But the downside is that code and libraries would need to be compiled
for debugging.
Is there any info somewhere why the approximation of the
Hi Simon,
Simon Marlow wrote:
If you felt like working on this yourself, possibly with Pepe, then
we'd be happy to support in any way we can.
Thanks. It may happen though it is not probable. I do not know the code
so anything non-trivial is a significant effort and my free weekends and
Hi users of ghci debugger,
This post is going to be a bit longer. Here are few cookies to motivate
you to go on:
* you will probably like it more than printf debugging for a lot of cases
* it can provide a way of implementing Claus Reinke's idea of
breakpoints with a list of identifiers which
Remi Turk wrote:
SPJ agreed with the idea itself, but suggested an alternative set of commands:
:info Show-- See class definition only
:instances Show -- See instances of Show
Hi Remi,
If you do not want to wait till this is implemented you can do it
yourself using ghci
If somebody managed to download it already there is a newer version.
Break point counter inside break expressions was one less than it should be.
Sorry for inconvenience. It is still very new.
Not sure there would be enough interest to put it on hackage or
something like that.
Let me know if
Pepe Iborra wrote:
Hello Peter,
Your efforts are simply outstanding. Thanks a lot for sharing your
experiences. I want to add a few comments:
- Regarding your :logLocal, you should rename it to :stepLocal, open a
ticket, and attach your patch. We should really try to get this into
6.10.2.
Claus Reinke wrote:
ghci-haskeline
This package reimplements ghci using the GHC API and the
Haskeline package for line input in command-line programs.
Just a copymodify of some of the GHCi sources, including a
Main.hs to call the modified code.
Thanks for the information.
Ok, from the
Simon Marlow wrote:
Peter Hercek wrote:
Is it possible to run ghci monad actions from ghci command line somehow?
For example: I would like to check whether it variable is of type
Bool and whether it is True using normal Haskell code (i.e. not using
ghci commands starting with colon like
Claus Reinke wrote:
If the necessary functionality is not yet exposed through
the API, it probably should be (iirc, GHCi's frontend itself
isn't part of the API, but the functionality used by it is, so GHCi
is just one of several GHC API clients; don't know how far the
debugger features you are
Simon Marlow wrote:
Peter Hercek wrote:
Is it possible to load one more module to ghci without unloading the
modules I have already loaded? The module I would like to load in
addtion is not installed and I do not want it installed. It is also
independent of any other modules
Is it possible to load one more module to ghci without unloading the
modules I have already loaded? The module I would like to load in
addtion is not installed and I do not want it installed. It is also
independent of any other modules. There is no dependency from the
modules already loaded to
Is it possible to run ghci monad actions from ghci command line somehow?
For example: I would like to check whether it variable is of type Bool
and whether it is True using normal Haskell code (i.e. not using ghci
commands starting with colon like :type :print).
Peter.
Simon Marlow wrote:
I agree with most of what you say - there should be a way to get access
to the history after :trace has finished. Perhaps the right way is just
to have a single global trace history.
Please submit a feature request, with a proposal for the user interface,
to the GHC bug
defined ghci commands ... unless I'm missing something :-)
Thanks,
Peter.
Simon Marlow wrote:
Peter Hercek wrote:
Hi,
I expected :trace expr to always add data to the trace history but
it does not do so for CAFs (which are not reduced yet).
My point is that the command :trace z did not add
Hi,
I expected :trace expr to always add data to the trace history but it
does not do so for CAFs (which are not reduced yet).
My point is that the command :trace z did not add anything to the
trace history and I cannot check why value z is 2, because value of y is
not in the trace history.
Simon Marlow wrote:
Peter Hercek wrote:
Simon Marlow wrote:
A similar argument applies to keeping the dynamic stack. The problem
with the dynamic stack is that it doesn't look much like you expect,
due to tail-calls.
Do you think people expect the tail-calls to add a stack frame
Is there a way to redirect output of a ghci debugger command
so that I can process it with a (ghci) script before it is
displayed?
Peter.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
Simon Marlow wrote:
Claus Reinke wrote:
Perhaps someone could help me to understand how the debugger is
supposed to be used, as I tend to have this problem, too:
- when I'm at a break point, I'd really like to see the current scope
or, if that is too expensive, the next enclosing scope, in
Claus Reinke wrote:
f x y z | xy = z
| otherwise = z*y
-
$ /cygdrive/d/fptools/ghc/ghc/stage2-inplace/ghc.exe --interactive
Debug.hs -ignore-dot-ghci
GHCi, version 6.11.20081122: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking
Pepe Iborra wrote:
On Mon, Nov 24, 2008 at 2:03 PM, Peter Hercek [EMAIL PROTECTED] wrote:
Maybe what Claus means is that he would like to see the dynamic
stack and be able to traverse it and at each location in the
dynamic stack he could investigate the free variables in the
expression
Daniil Elovkov wrote:
A refinement of :tracelocal could be :tracedirect (or something) that
would save the history not anywhere within the given function but only
within parents, so to say. For example,
This looks like what I thought of as searching for values in dynamic
stack (explained in
Daniil Elovkov wrote:
I'd like to know, how do ghc developers and users feel about the debugger?
Sometimes it is better/quicker than printf debugging :)
Now I see it mess up the list of bindings in a funny way. For example,
in a previous trace session I had a variable, say, prev. It was
Simon Marlow wrote:
Peter Hercek wrote:
As for as the rest of the message. Those are possible bugs.
If I can reduce them to few tens of lines of a test, I'll
post the bug reports. I use Archlinux and the last (non-testing)
version of ghc there is ghc-6.8.2. Do you accept bug reports
Simon Marlow wrote:
We thought about this when working on the debugger, and the problem is
that to make the debugger retain all the variables that are in scope
rather than just free in the expression adds a lot of overhead, and it
fundamentally changes the structure of the generated code:
May be my approach to debugging with ghci is wrong
but in about half of the time I find ghci (as a
debugger) almost useless. The reason is the limited
way it can resolve identifiers. I can examine
the free variables in the selected expression and
nothing else. Well, I *think* just sometimes
Hi,
I was advised to report it here ... and
maybe somebody who knows ghc better can
reproduce it or knows what is the problem.
I uninstalled all ghc, gtk, and gtk2hs
packages then installed ghc 6.8.3 and
then gtk2hs 0.9.13 on Windows XP 32bit.
This should not be because of some stalled
Christian Maeder wrote:
I understand that gmp is needed for the certain libraries like the
Prelude with Double and Integer.
Why is GMP needed for Double? Based on the online report Double is
double precision floating; it does not need to represent arbitrary
big numbers.
I thought it is there
New ghc sped up my small app (~2000 lines) by ~38%. Nice job!
Anyway, my application is a bit slower when compiled with -O2
compared to -01 only (both with ghc 6.6 and 6.8).
Is that normal?
Peter.
Lennart Augustsson wrote:
I'd like to second that. 6.8 is quite an improvement. Well done!
Each test I mention here is actually 3 or 4 application runs.
If there were 4 runs then the first one was discarded, so
there are still only 3 results available in one test. The
idea is that I discard the first test if it got significantly
higher page fault count.
Ok, it is not any more 100%
-O2 -fno-liberate-case -fno-spec-constr -fexcess-precision
real 24.500 user 19.172 system 0.359 cpu 19.531 page_faults 79337
real 26.406 user 18.938 system 0.375 cpu 19.313 page_faults 79477
real 28.891 user 19.016 system 0.391 cpu 19.406 page_faults 79357
Peter.
Bulat Ziganshin
Hi,
GHC version: win32 6.6.1
App was compiled with ghc -make -prof -auto-all files
... and run with app.exe appSpecificOptions +RTS -hc
The result is that app.exe.hp contains the sample items
in the format like
(651)/createAndRunWindows/... 180
The question is where can I find the full
Brandon Michael Moore wrote:
How hard is it to make another grammar? It would be very nice if parser
generators could make a page like this. Have you seen the program
BNFC (The BNF Converter)? It tries to generate some nicely-formatted
TeX documentation of the grammar, this could be even more
Hi,
I was improving my Haskell knowledge lately and I created a small dhtml application which allows browsing of
Haskell 98 grammar. I contains both forward and backward hyperlinks. By backward hyperlink I mean that you can
click on an a production head and you get a popup list box where you
ones who actually checked it out :-D Anyway, sending this to haskell
cafe too (as recommended). I expect a discussion (if any) will continue
there. Sorry about GHC user list abuse.
Peter Hercek.
Neil Mitchell wrote:
Hi
In addition, perhaps this should be relocated to haskell.org, if your
What is $ function good for?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
70 matches
Mail list logo
