ANN: GhciExt 0.7
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. http://www.hck.sk/users/peter/pub/ghciext-0.7.tar.gz It redefines some standard commands (like e.g. :break to output hit count) and adds some new commands (the most useful are probably :grep and :watch (conditional breakpoint)). Here is the list of the added commands: Prelude :defs long :. file -- source commands from file :* count cmd... -- run cmd count times :x cmd... -- run cmd with stdout suppressed :output -- restore ghci output (stdout and stderr) back Restores stdout and stderr of ghci as it was during startup. You should not ever need this command. It is here only if something would go wrong in ghciExt and you need to recover (console) manually. :redir var cmd... -- execute cmd redirecting stdout to var :grep args cmd... -- run grep args on cmd output Runs grep from your OS on the output of cmd. This means all the options of your OS grep are available. '' separates grep options from the command. :find cmd [-]var -- step with cmd until var is found Prepend variable name with '-' to disable printing of its value. :locate cmd bpArgs -- step with cmd until location bpArgs is hit :repeat cmd cond -- repeat cmd until cond is true :inject cc c sc b -- at location b run c if cc and stop if sc There are two special identifiers which can be used in the breakpoint code (c) and the breakpoint stop condition (sc); but which are not usable in the breakpoint code condition (cc). These are: - ġė_BpId - macro name; translates to breakpoint id - ġė_HitCnt - macro name; translates to breakpoint hit count :strobe [c] b -- at location b show hit count if c :monitor [c] e b -- :force expression e at location b if c :watch cond bpArgs -- break at location bpArgs when cond is True :count [R]N [bp] -- count/stop execution at bp or query bp hits There are four ways how to use this command: - :count 0 bp - never stops; counts hits and extends trace history - :count N bp - stops when location bp is hit N-th time - :count RN bp - stops when hitCount@bp is in Ord relation R with N - :count N - shows hit count of a ghciExt breakpoint with number N. :class classId -- show class methods :defs [long] -- list user commands (possibly with long help) General information for all GhciExt commands: - Most arguments may be in quotation marks (to allow spaces in them). - Instead of a regular quotation mark, @x can be used to start a string argument too. In such a case the argument is finished when character x appears again after `@x' string. Use any character in place of x. - Most commands can have an end-line comment. The comment starts with this sequence: d--, where d is the argument delimiter; i.e. it is '', the x after '@' or whitespace based on the previous argument. - GhciExt calls :init any time GHCi may have cleared your top level symbols. Redefine :init to reintroduce the symbols you want always available. Prelude ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: possible strictness bug in profiled version of a program
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
possible strictness bug in profiled version of a program
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 = let nextRv = (rv + sum (elems h)) in accumulate t $! nextRv I used ghc 7.0.3-2 on archlinux, 64 bit version. I created it only to check how much memory short unboxed arrays consume. Thanks to the $! call at the last line of the accumulate function there should not be any stack overflow. When I compile with these options: --make prgSrc.hs -O2 --make prgSrc.hs -prof -auto-all -caf-all --make prgSrc.hs then there is no problem. But when I compile with these options: -O2 -prof -auto-all -caf-all --make prgSrc.hs then program runs out of stack. This indicates that there is a bug while compiling $! in an optimized profiling version of this program. Is it a bug? Should it be reported to the ghc trac database? Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
incorrect deprecation warning
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 installation of GHC 6.12.1.
The problem (it it was not intended) is there in the current head too:
~/haskell/ghc.head/libraries/base 836 darcs what -u
hunk ./GHC/Handle.hs 18
-- #hide
-module GHC.Handle {-# DEPRECATED use GHC.IO.Handle.Base instead #-} (
+module GHC.Handle {-# DEPRECATED use GHC.IO.Handle instead #-} (
withHandle, withHandle', withHandle_,
wantWritableHandle, wantReadableHandle, wantSeekableHandle,
~/haskell/ghc.head/libraries/base 837
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how can I get a listing of everything that's done in a program
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 the terminal - 4 steps at a time...
:step
:step
:step
:step
This gave me the listing I wanted. But after a certain point, it
inevitably fails with a core dump, and what I capture from the screen is
garbled up to that point anyway. I'm hoping there's a simpler way to do
this. Thanks for taking the time to read this.
If you get a core dump, that's obviously a bug. If you can supply us
with a small program that illustrates the bug, please submit a bug
report at
http://hackage.haskell.org/trac/ghc/wiki/ReportABug
As for getting a list of the evaluation steps, we don't have anything
that does exactly what you want at the moment, but it probably
wouldn't be hard to implement on top of the existing debugging
functionality.
If you want to execute one command more times you can do it by scripting
ghci. Add something like this to your ~/.ghci file:
:{
let
{ cmdHlp _ msg longMsg --help =
let fullMsg = if null longMsg then msg++\n else msg ++
('\n':longMsg) in
return $ putStr ++show fullMsg
; cmdHlp _ msg _ -h = return $ putStrLn ++show msg
; cmdHlp action _ _ args = action args }
:}
:{
:def * cmdHlp
( \cntCmd -
case break Data.Char.isSpace cntCmd of {
( cnt, _:cmd ) - return $unlines $replicate (read cnt) cmd ;
_ - return putStrLn \usage: :* count cmd...\ } )
:* count cmd... -- run cmd count times
:}
Then you can use it like this:
% ghci
GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude :* -h
:* count cmd... -- run cmd count times
Prelude :* --help
:* count cmd... -- run cmd count times
Prelude :* 3 :type sqrt 2
sqrt 2 :: (Floating t) = t
sqrt 2 :: (Floating t) = t
sqrt 2 :: (Floating t) = t
Prelude :quit
Leaving GHCi.
%
More information about ghci scripting:
http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html
More examples of how can you script ghci:
http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/16912
Peter.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: few questions about GHC RTS
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 or something? The comment in Interpreter.c says // Note [unreg]: in unregisterised mode, the return // convention for IO is different. The // stg_noForceIO_info stack frame is necessary to // account for this difference. However, the return convention for IO is now the same under both registerised and unregisterised builds (I made the change becuase of the proliferation of obscure conditional RTS code like the above), so I'm guessing the stg_noforceIO_info hack, and the above comment, are now redundant. It needs testing though. Just for your information. I was curious and tried to remove the additional stg_noforceIO_info argument. Breakpoints stopped to be called but otherwise ghci seemed to work fine. It was surprising. It looked like the call to rts_breakpoint_io_action was somehow optimized away but I would not expect any optimizations at this level. Maybe I did not do it correctly. The patch I used is at the end of this email. Thanks, Peter. hunk ./rts/Interpreter.c 879 // in a reasonable state for the GC and so that // execution of this BCO can continue when we resume ioAction = (StgClosure *) deRefStablePtr (rts_breakpoint_io_action); - Sp -= 9; - Sp[8] = (W_)obj; $ - Sp[7] = (W_)stg_apply_interp_info; - Sp[6] = (W_)stg_noforceIO_info; // see [unreg] below + Sp -= 8; + Sp[7] = (W_)obj; $ + Sp[6] = (W_)stg_apply_interp_info; Sp[5] = (W_)new_aps; // the AP_STACK Sp[4] = (W_)BCO_PTR(arg3_freeVars); // the info about local vars of the breakpoint Sp[3] = (W_)False_closure;// True = a breakpoint hunk ./rts/Interpreter.c 885 - Sp[2] = (W_)stg_ap_pppv_info; + Sp[2] = (W_)stg_ap_ppp_info; Sp[1] = (W_)ioAction;// apply the IO action to its two arguments above Sp[0] = (W_)stg_enter_info; // get ready to run the IO action hunk ./rts/Interpreter.c 888 - // Note [unreg]: in unregisterised mode, the return - // convention for IO is different. The - // stg_noForceIO_info stack frame is necessary to - // account for this difference. // set the flag in the TSO to say that we are now // stopping at a breakpoint so that when we resume ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Plans for GHC 6.12.1: release candidate 14 September 2009
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: http://hackage.haskell.org/trac/ghc/query?status=newstatus=assignedstatus=reopenedpriority=highestpriority=highmilestone=6.12.1order=priority If there is a bug not in that list that is important to you, please let us know. Could you please merge ticket #3084: allow macros to redefine builtin GHCi commands http://hackage.haskell.org/trac/ghc/ticket/3084 It was agreed for 6.12.1 and the solution is attached. The solution did not result in any merge conflicts when I updated ghc.head a week ago. It did not cause any new errors in the validate script. I use it locally from the time the ticket was opened and I'm not aware of any problems. You might also consider ticket #3434: improve vi tags (add non-exported symbols, add tag kinds, add regex tags) http://hackage.haskell.org/trac/ghc/ticket/3434 There is a link to the solution from the ticket but this one is not approved. It does not result in any new errors in the validate script. But the solution may have impact on emacs tag generation and I tested the tags for emacs only in vim (vim recognizes them too). Thanks, Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
few questions about GHC RTS
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 ... and If I decide to do it I may just figure it out myself or fail again :) 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 or something? Are there any Cmm functions in RTS with signature (IO()) or signature (Int-IO()) which I could check out as examples to see how they are done? ... and ideally also how they are called from the stack. Are there any special things to do when adding a new field (e.g. simulated stack size) to StgTSO? Thanks, Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: what is the path to a particular module?
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 you can do ghc-pkg describe to see there it is installed and what modules it does expose. All the information is in ghc-install-dir/package.conf which just seems to be a list of InstalledPackageInfo (Distribution.InstalledPackageInfo). So it should be possible to write a function you want easily. Surprisingly when I tried to read the list of InstalledPackageInfo from my package.conf it failed despite ghc-pkg working well. I did not investigate why. Maybe there is a better way. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci debugger: showing function argumetns when stopped at its definition
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 at a function definition the first time (when just entering it). The problem is that functions can be defined with multiple equations, each giving different names for the arguments. e.g. in f x 0 = x f 0 x = x when we stop at f, what do you want to see? Right, I did not realize this problem. But your idea of using _arxN naming in case of more equations seems best to me. I would still like to have it available. Even in one equation, pattern match can make it undesirable. Say, in fromJust (Just x) = ... doesn't allow you access to the argument directly. Can _argN be provided in *all* cases (possibly in addition to other bindings)? I was thinking about adding _argN always too. If it is done in addition to other binding (which are not ambiguous) then even better. Regardless I'm fine with any solution which allows me to access arguments more easily (i.e. without tracing on (to manually search for call site) or without trying to mark all first usages). Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci debugger: showing function argumetns when stopped at its definition
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 it). The problem is that functions can be defined with multiple equations, each giving different names for the arguments. e.g. in f x 0 = x f 0 x = x when we stop at f, what do you want to see? Right, I did not realize this problem. But your idea of using _arxN naming in case of more equations seems best to me. I would still like to have it available. So it looks doable without bad consequences. Now, the question is: Is there any support for it except me? Thanks, Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghci debugger: showing function argumetns when stopped at its definition
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 it doable without bad consequences? Looks to me like it should not result in some memory leak problems though I do not have idea whether it is hard to do. The reason I want it is that if it would be available I could put a break point which never stops and only continues at the start of a function I'm interested in. Then If I later stop somewhere in the function I have a pretty good chance that the correct arguments are stored in the trace history and I could retrieve them. E.g. with my GhciExt it would be as simple as: -- to strobe function arguments :count 0 QualifiedFncName -- and to look them up later when stopped somewhere -- in the function I could just use :locate :back QualifiedFncName -- ... or for a specific argument value :find :back ArgumentName If you are interested GhciExt is available here: http://www.hck.sk/users/peter/pub/ But other users could do it too in a bit more complicated way (e.g. by stopping at the function start manually and then continuing and then searching the trace history manually again). Of course I can make sure the function arguments get to the history even now but in much more complicated way (by putting a non-stopping break point at each first use of each argument). The problem with this approach is that: * one must look up all the places in the source code * some of the places may not be hit before we stop at some interesting place in the function so some arguments would not be visible yet Thanks, Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: better generation of vi ctags in ghci
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 the original format of vim tags too. Then e.g. :ctags would generate tags with line numbers and :ctags! would generate tags with search expressions. See above for other things that can go wrong with search-based tags, so I'd prefer to have both options. Ok, I can add it. Generating line numbers instead of search patterns will be quicker too. For big projects, the time difference may be noticeable. So what about UI? :ctags would generate tags with line numbers and :ctags! would generate tags with search patterns? Or will we add an argument to :ctags to specify what kind of tags we want? This option would break ghci UI backward compatibility. Bump! Looks like nobody cares enough to respond. Do we have at least a general agreement of two for :ctags[!] user interface? Is general agreement of two and nobody caring enough to respond good enough for a merge? If nobody responds to this I'll assume there is no general agreement and I'll maintain the patch only for myself. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghci etags for emacs (was: better generation of vi ctags in ghci)
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 they may have different order (but only within the group of the symbols on the line). This is probably because different GHC interface is used and the symbols are coming in different order. Vim can accept emacs tags too and they work fine as they are generated by the new code. So the questions for emacs users are: * Should the non-exported top level symbols be added to emacs TAGS file? As far as I could find on the internet, emacs does not have notion of static symbols as vim has so it may not be a good idea. But if emacs prefers jump to a symbol in the local file to symbols in the other files it may work well enough to be worth it. * The last data field of the tag definition is byte_offset. But in past (and I kept it as it was so even when the patch is applied) this was actually byteOffset-numberOfLines*sizeOfLineDelimiter. The size of newLine delimiters was ignored (and moreover it is system dependent). This does not matter that much since based on Claus information emacs allows some fuzz in the position information. The question is whether to keep this as it was or add 1 for each line or somehow try to detect platform and add the correct number of bytes for each line? If no answers come I just keep it as it is and hope for the support of the vim related ctags changes only :) Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
better generation of vi ctags in ghci
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 would you want the new implementation of :ctags ghci command? * Tags are searched based on the line content. This is what Exuberant Ctags do for other languages and it is the other posix way to do it. This makes the positioning to work well even when the source code was edited (on places unrelated to the tag location). More complicated Ex statements can be used to improve it even more but then it does not work well with :tselect (it screws up tag kinds, at least with my version of vim 7.2.65). * All top level symbols defined in a module are added to the tags file. Even the non-exported ones. These are marked as static (file:) so the default tag selection (Ctrl-]) works fine based on the file you started the search from. * Tags get kinds added so you can select whether you want to get to a type constructor or a data constructor (that is if you share names between the two). * In general it is a nice addition to vim haskellmode. If you search for help on symbols in libraries then opening haddock is cool. If you search for help on a symbol in your project then opening the tag in a preview window (Ctrl-W} or ptselect) is cool. Problems: * It needs somebody to check that emacs tags were not broken. I'm not an emacs user but some tag generation code is shared for vim and emacs. I tried to keep emacs tags exactly the way they were (only the exported symbols, original file format). * 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 the original format of vim tags too. Then e.g. :ctags would generate tags with line numbers and :ctags! would generate tags with search expressions. If there is any support for this and ghc team decides to merge it I can provide darcs patch. I can do changes needed to get it merged. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: better generation of vi ctags in ghci
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. So far I did not get any false positive in my
code with this approach.
; if you search on less than the full line, you get additional
misleading matches, especially because you
can only search forward or backward, not both (also, the fallback of
/^tag/ won't work for infix operators, classes, data, ..).
Ideally, one (well, I at least;-) would like a mixed approach: start with
source line, figure out if the line is right, if yes, done, if not,
then search
(starting from the old position). But that seemed to be beyond posix
tags, so I stuck with line numbers.
I tried some form of that (set position before the expected loction
before searching). It could be done better but then the tag file would
get big (inline all the code for each tag, or we would need some
functions defined outside of the tags file). Anyway the reason I dropped
this was that my vim did not parse this file correctly and tag kinds (as
defined in the vim tags file) were not shown in the :tselect list. So I
decided it is not worth it for now. It would be cool to have something
better but I do not know whether it is possible aside from just writing
an interactive compiler (something like yi people are trying - I do not
know how far did they get).
* All top level symbols defined in a module are added to the tags
file. Even the non-exported ones. These are marked as static (file:)
so the default tag selection (Ctrl-]) works fine based on the file
you started the search from.
Thanks, I had meant to do this, don't know why I didn't (you use the new
static tag format, not the old, I assume?).
I use the latest format:
{tagname} {TAB} {tagfile} {TAB} {tagaddress} {term} {field} ..
Where {tagaddress} is a search expression looking for whole lines.
* Tags get kinds added so you can select whether you want to get to a
type constructor or a data constructor (that is if you share names
between the two).
You mean 'kind' in the tags file sense, using it to record namespace,
similar to haddock's t/v distinction?
I mean kind in the tags file sense. I do not know about haddock's t/v
distinction so I cannot compare to it.
So far I use:
* v (varId),
* t (typeCon),
* d (dataCon),
* c (class).
* In general it is a nice addition to vim haskellmode. If you search
for help on symbols in libraries then opening haddock is cool. If you
search for help on a symbol in your project then opening the tag in a
preview window (Ctrl-W} or ptselect) is cool.
That's why I suggested the addition in the first place!-) Thanks for
taking it further.
NP, it is great! I did not know there is at least one more person
wanting better tags. I did not even know about ghctags. Otherwise I
would probably just use them if they are any good (generate non-exported
symbols too and use search patterns instead of the line numbers ... so
they are at least a bit useful after some edits). Ok, the reason I care
about tags to be useful after some edits is that for some of my files it
takes some time to compile them in ghci. And I don't want to think
about regenerating them regularly. Now I need to regenerate them only
when the tag cannot be located or it found an incorrect place (which did
not happen to me yet).
for GHC's sources, which GHCi :ctags couldn't, last time I tried). A
secondary issue was what to do with non-interpreted modules
(probably: just skip, and rely on them having their own tags files).
Skipping is fine with me.
* 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 the original format of vim tags too.
Then e.g. :ctags would generate tags with line numbers and :ctags!
would generate tags with search expressions.
See above for other things that can go wrong with search-based tags,
so I'd prefer to have both options.
Ok, I can add it. Generating line numbers instead of search patterns
will be quicker too. For big projects, the time difference may be
noticeable.
So what about UI? :ctags would generate tags with line numbers and
:ctags! would generate tags with search patterns? Or will we add an
argument to :ctags to specify what kind of tags we want? This option
would break ghci UI backward compatibility.
Peter.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Should exhaustiveness testing be on by default?
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 you might want to see the dynamic stack: when catching exceptions raised by pure code. Would it not help also when finding out why some code is not as lazy as it is hoped for? Now, I do not know how often this problem happens, I did not have it yet, but it looks like it would help. I remember I also wanted it when I was trying to understand how uulib works. I would expect it to be useful anytime laziness is critical for efficient program execution. If the stacks do not come with variables in the scope available then both are useful about the same from my rather unexperienced point of view. Anyway, after I'd learned to use GhciExt (thank you both for helping me out with it), the next command became more important to me than the stack. That is for my code, if/when I get to uulib again I may change my mind quickly :-D Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: can't run Grapefruit
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 because of problems like these, but this bug was often because of incorrect or missing value in extra-ghci-libraries attribute. Run this: ghc-pkg describe glib and then check whether attribute extra-ghci-libraries contains something sensible. Now, I do not know what it needs to be exactly now (do not use windows any more so I cannot look it up) but I recall that I was adding value libcairo-2 to extra-ghci-libraries for the cairo package. The point is that the dll name containing the C implementation of the given package must correspond to the string in extra-ghci-libraries. IIRC, sometimes, I was also adding the path to the library (something like -Lpath) in ld-option attribute. But that was probably for compiling and not for ghci. Hope it helps, Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Should exhaustiveness testing be on by default?
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 moreover needs a
change of '$ case True of False - srcloc' to '$ case True of False -
undefined' to be usable.
The warning problem is critical by its own since the goal of using it is
to selectively disable the very same warning for a specific case
statement. Although the warning can be eliminated probably in the first
template haskell alternative. Not sure since I do not know template
haskell. As well as I still do not know how to write a haskell function
in C-- which is the reason there is no :next command in ghci yet :)
Thanks,
Peter.
Claus Reinke wrote:
The second solution requires QuasiQuotes, so I do not know. If I
would want to compile with a different compiler it would break. If
srcloc can be defined as a simple token (not requiring special
extensions at places where it is used) then I could define it to an
empty string in some low level module if trying to compile with a
different haskell compiler which does not know srcloc.
You can do better than that, if you combine the QuasiQuotes hack with
the CPP hack (I've also simplified the srcloc handling by adding a
version
of error that adds source location info, moving the exception
manipulation
out into SrcLocQQ, avoiding the need for Debug.Trace alltogether).
The portable version does get a bit uglier because you need macros,
not functions (you'll probably want to check for GHC version or
-better, but not supported- QuasiQuotes availability). Also, CPP only
gives you the line number, not the position, but that is better than
nothing, and often sufficient.
Still, it would be much nicer if GHC inserted the location info at the
call sites if a pragma at the definition site asked it to do so. Then
this
{-# SRCLOC f #-}
f Nothing = okay
f _ = error f applied to not-Nothing in:
could be equivalent to the code below, without QuasiQuotes or CPP
or ERRORSRC all over the place. But such niceties are on hold while
the discussion of even nicer help is ongoing.. (which is partly justified
because we cannot easily build nicer abstractions over a barebones
solution, due to the macro vs function issue, so the design does need
thought). Perhaps the code below is sufficient as an interim workaround.
Claus
-
{-# LANGUAGE CPP #-}
{-# LANGUAGE QuasiQuotes #-}
#ifdef __GLASGOW_HASKELL__
#define SRCLOC [$srcloc||]
#define ERRORSRC [$errorSrc||]
#else
#define SRCLOC (show (__FILE__,__LINE__))
#define ERRORSRC (\msg-error $ msg++SRCLOC)
#endif
import SrcLocQQ
f errorSrc Nothing = okay
f errorSrc _ = errorSrc f applied to not-Nothing in:
main = do
print $ f ERRORSRC Nothing
print $ f ERRORSRC (Just ())
print $ SRCLOC
-
{-# LANGUAGE TemplateHaskell #-}
module SrcLocQQ where
import Language.Haskell.TH.Quote
import Language.Haskell.TH
import Control.Exception
srcloc = QuasiQuoter (\_-[| mapException (\(PatternMatchFail fail)-
let srcloc = reverse (dropWhile (/=':')
(reverse fail))
in PatternMatchFail srcloc)
$ case True of False - srcloc |])
(error pattern srclocs not supported)
errorSrc = QuasiQuoter
(\_-[| \msg-mapException (\(PatternMatchFail fail)-
let srcloc = reverse (dropWhile (/=':')
(reverse fail))
in PatternMatchFail (msg++srcloc))
$ case True of False - srcloc |])
(error pattern srclocs not supported)
-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Should exhaustiveness testing be on by default?
I was looking for something which works in optimized builds too. I know I could do it with preprocessor or (I think) template haskell too but these tools seem to heavy for such a simple goal. The point is the exhaustiveness check saves me from some errors sometimes, but I often need to switch it off for a specific case statement too. Adding an catch all alternative and an error call would be cool way to do it if there is a way to automatically add source code location. This way I could get the best error telling me where it happend and also why I thought the other alternatives should not happen (the error call argument). Thanks, Peter. Simon Peyton-Jones wrote: Yes indeed http://www.haskell.org/ghc/docs/latest/html/users_guide/assertions.html Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users- | boun...@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) [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 particularly | helpful for debugging | Is there some compile option to automatically annotate error call with | its source | code location (so that one dos not need to mention it in the string | argument)? | | Peter. | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Should exhaustiveness testing be on by default?
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 -fno-ignore-asserts is acceptable till I do not need asserts for what they are actually supposed to be used for. The second solution requires QuasiQuotes, so I do not know. If I would want to compile with a different compiler it would break. If srcloc can be defined as a simple token (not requiring special extensions at places where it is used) then I could define it to an empty string in some low level module if trying to compile with a different haskell compiler which does not know srcloc. Thanks for the tips, Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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) [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 particularly helpful for debugging Is there some compile option to automatically annotate error call with its source code location (so that one dos not need to mention it in the string argument)? Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANN: GhciExt 0.6 for GHC 6.10.3
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 GHC 6.10.2 and higher, but I only tried briefly with GHC 6.10.3 (as it was released) and I use it without any problem with my customized GHC 6.10.3 (dirty support for ansi escape sequences in ':set prompt' for color highlighting of the prompt, patch for ticket http://hackage.haskell.org/trac/ghc/ticket/3084 (allow macros to redefine builtin GHCi commands), and few more details). Here is what it does: Prelude :defs long :. file -- source commands from file :* count cmd... -- run cmd count times :x cmd... -- run cmd with stdout suppressed :out -- redirect ghci stdout back to console :redir var cmd... -- execute cmd redirecting stdout to var :grep args cmd... -- run grep args on cmd output Runs grep from your OS on the output of cmd. This means all the options of your OS grep are available. '' separates grep options from the command. :find cmd [-]var -- step with cmd until var is found Prepend variable name with '-' to disable printing of its value. :locate cmd bpArgs-- step with cmd until location bpArgs is hit :bp bpArgs -- put breakpoint at bpArgs (adds hit count) :inject cc c sc b -- at location b run c if cc and stop if sc There are two special identifiers which can be used in the breakpoint code (c) and the breakpoint stop condition (sc); but which are not usable in the breakpoint code condition (cc). These are: - ghciExt_BpId - macro name; translates to breakpoint id - ghciExt_HitCnt - macro name; translates to breakpoint hit count :strobe [c] b -- at location b show hit count if c :monitor [c] vs b -- show comma-sep. variables at location b if c :watch cond bpArgs-- break at location bpArgs when cond is True :count N [bpArgs] -- count/stop execution at bpArgs or query bp hits There are three ways how to use this command: - :count 0 bpArgs - never stops; counts hits and extends trace history - :count N bpArgs - stops when location bpArgs is hit N-th time - :count N - shows hit count of a ghciExt breakpoint with number N. :hl cmd... -- highlight the output of cmd :defs [long] -- list user commands (possibly with long help) General information for all GhciExt commands: - Most arguments may be in quotation marks (to allow spaces in them). - Instead of a regular quotation mark, @x can be used to start a string argument too. In such a case the argument is finished when character x appears again after `...@x' string. Use any character in place of x. This was added so that one does not need to escape quotation marks and back-slashes in arguments (especially those representing code). Prelude Not so much obsolete description of how it works (and how to use it) is here: http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/16270 Notable changes are: * much better :grep command (you can even get color highlighted output) * you do not need to prefix commands :main, :continute, :step, and :trace with :x any more * :findex replaced with much better :locate It works on linux. The only reason I recall it would not work on windows is the use of '/dev/null'. But I never tried on windows. Enjoy, Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: failure implementing :next command in ghci
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 is smaller than breakStackSize 2) current dynamic stack size is equal to breakStackSize and the current selected expression is not a subset of breakSpan So what happens if the stack shrinks and then grows again between two breakpoints? Presumably :next wouldn't notice. Yes, if there is no breakpoint in between I would not notice. I did not expect this can happen though. I thought that to add a frame on the stack this must be done within an expression (which is going to be forced) and the expression should be a breakpoint location. If it is so negligible that it does not have a breakpoint location associated then even the things it is calling should be negligible. Where is an error in this? I think you'd be better off implementing this with a special stack frame, so that you can guarantee to notice when the current context has been exited. This would be robust but I do not have knowledge to do it yet. If I understand you correctly this means that before executing a BCO which we are going to break at, we must prepare for a possible :next. So regardless whether :next is going to be issued by the user or not we would add a frame which represents a return to a function which: a) if user issued :next it enables all breakpoints so that we stop at the next breakpoint b) if user did not issue a break it would not do anything (just return) We could decide not to insert the frame when we are only tracing. But if I would want to track a simulated dynamic stack I would need to insert this stack frame at the start of each breakpoint (when dynamic stack tracing would be on). Does not sound that good. I hope the above would make good sense but I do not really know since maybe rts does some funny things with stack sometimes. If you think the proposed behavior is garbage let me know why so that I do not waste more time with this :) Yes the RTS does do funny thing with the stack sometimes. The stack can shrink as a result of adjacent update frames being coalesced (stack squeezing). OK, so it looks like either switching off the squeezing (if shrinking and growing stack between breakpoints/ticks is not such an issue), or inserting a stack frame. Does the stack squeezing happen during garbage collection? Thanks, Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: failure implementing :next command in ghci
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 do not have the patch applied). Here is how I did the test on my 32 bit archlinux: * downloaded ghc-6.10.2-src.tar.bz2 from http://haskell.org/ghc/download_ghc_6_10_2.html#sources (I did not download the extralibs tarball) * unpacked ghc-6.10.2-src.tar.bz2 and did this in the ghc-6.10.2 directory: ./boot ./configure make * then I did this test: status:0 pe...@metod [892] ~/haskell/ghc-6.10.2 % cat a.hs f :: Int - Int f x = x + 1 a = f 1 status:0 pe...@metod [893] ~/haskell/ghc-6.10.2 % ghc/stage2-inplace/ghc --interactive a.hs GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( a.hs, interpreted ) Ok, modules loaded: Main. *Main :break f Breakpoint 0 activated at a.hs:2:0-10 *Main :force a zsh: segmentation fault ghc/stage2-inplace/ghc --interactive a.hs status:139 pe...@metod [894] ~/haskell/ghc-6.10.2 % The test works ok when I do it with the ghc-custom I have installed (6.10.1 with few of my patches). The same behavior is on my laptop which has only stock uptodate archlinux, and stock ghc 6.10.1 installed (so I think it cannot be because of my few patches in ghc 6.10.1). I did the clean build and the test there too. Well to be precise, it works worse on my laptop since when I try to run ghci 6.10.1 (as distributed by archlinux) I'll get a crash too: status:0 pe...@dwarf [852] ~/haskell/ghc-6.10.2 % ghci a.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( a.hs, interpreted ) Ok, modules loaded: Main. *Main :break f Breakpoint 0 activated at a.hs:2:0-10 *Main :force a% status:139 pe...@dwarf [853] ~/haskell/ghc-6.10.2 % The question is: Is the test supposed to work with ghc 6.10.2 without installing it? I hope I'm doing some stupid mistake and that archlinux is not borked. What is the platform (distribution and it's version) ghc HQ uses for ghc development (on which the test I presented works)? Thanks, Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: failure implementing :next command in ghci
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 new-ghc/compiler/main/InteractiveEval.hs
--- old-ghc/compiler/main/InteractiveEval.hs 2009-04-14 11:51:34.768662881 +0200
+++ new-ghc/compiler/main/InteractiveEval.hs 2009-04-14 11:51:35.135331181 +0200
@@ -345,7 +345,7 @@
-- this points to the IO action that is executed when a breakpoint is hit
foreign import ccall rts_breakpoint_io_action
- breakPointIOAction :: Ptr (StablePtr (Bool - BreakInfo - HValue - IO ()))
+ breakPointIOAction :: Ptr (StablePtr (Bool - BreakInfo - HValue - Int - IO ()))
-- When running a computation, we redirect ^C exceptions to the running
-- thread. ToDo: we might want a way to continue even if the target
@@ -413,7 +413,7 @@
-- might be a bit surprising. The exception flag is turned off
-- as soon as it is hit, or in resetBreakAction below.
- onBreak is_exception info apStack = do
+ onBreak is_exception info apStack _ = do
tid - myThreadId
putMVar statusMVar (Break is_exception apStack info tid)
takeMVar breakMVar
@@ -424,12 +424,12 @@
resetStepFlag
freeStablePtr stablePtr
-noBreakStablePtr :: StablePtr (Bool - BreakInfo - HValue - IO ())
+noBreakStablePtr :: StablePtr (Bool - BreakInfo - HValue - Int - IO ())
noBreakStablePtr = unsafePerformIO $ newStablePtr noBreakAction
-noBreakAction :: Bool - BreakInfo - HValue - IO ()
-noBreakAction False _ _ = putStrLn *** Ignoring breakpoint
-noBreakAction True _ _ = return () -- exception: just continue
+noBreakAction :: Bool - BreakInfo - HValue - Int - IO ()
+noBreakAction False _ _ x = putStrLn $ *** Ignoring breakpoint ++ show x
+noBreakAction True _ _ _ = return () -- exception: just continue
resume :: GhcMonad m = (SrcSpan-Bool) - SingleStep - m RunResult
resume canLogSpan step
diff -rN -u old-ghc/includes/StgMiscClosures.h new-ghc/includes/StgMiscClosures.h
--- old-ghc/includes/StgMiscClosures.h 2009-04-14 11:51:34.971997946 +0200
+++ new-ghc/includes/StgMiscClosures.h 2009-04-14 11:51:35.358664627 +0200
@@ -377,6 +377,7 @@
RTS_RET_INFO(stg_ap_ppp_info);
RTS_RET_INFO(stg_ap_pppv_info);
RTS_RET_INFO(stg_ap__info);
+RTS_RET_INFO(stg_ap_v_info);
RTS_RET_INFO(stg_ap_p_info);
RTS_RET_INFO(stg_ap_pp_info);
diff -rN -u old-ghc/rts/Exception.cmm new-ghc/rts/Exception.cmm
--- old-ghc/rts/Exception.cmm 2009-04-14 11:51:34.878663864 +0200
+++ new-ghc/rts/Exception.cmm 2009-04-14 11:51:35.391997906 +0200
@@ -402,15 +402,16 @@
// be per-thread.
W_[rts_stop_on_exception] = 0;
(ptr ioAction) = foreign C deRefStablePtr (W_[rts_breakpoint_io_action] ptr) [];
-Sp = Sp - WDS(7);
-Sp(6) = exception;
-Sp(5) = stg_raise_ret_info;
-Sp(4) = stg_noforceIO_info;// required for unregisterised
+Sp = Sp - WDS(8);
+Sp(7) = exception;
+Sp(6) = stg_raise_ret_info;
+Sp(5) = stg_noforceIO_info;// required for unregisterised
+Sp(4) = 0;
Sp(3) = exception; // the AP_STACK
Sp(2) = ghczmprim_GHCziBool_True_closure; // dummy breakpoint info
Sp(1) = ghczmprim_GHCziBool_True_closure; // True = a breakpoint
R1 = ioAction;
-jump RET_LBL(stg_ap_pppv);
+jump RET_LBL(stg_ap_v);
}
}
diff -rN -u old-ghc/rts/Interpreter.c new-ghc/rts/Interpreter.c
--- old-ghc/rts/Interpreter.c 2009-04-14 11:51:34.861997785 +0200
+++ new-ghc/rts/Interpreter.c 2009-04-14 11:51:35.395331066 +0200
@@ -815,14 +815,8 @@
case bci_BRK_FUN:
{
int arg1_brk_array, arg2_array_index, arg3_freeVars;
-StgArrWords *breakPoints;
int returning_from_break; // are we resuming execution from a breakpoint?
// if yes, then don't break this time around
-StgClosure *ioAction; // the io action to run at a breakpoint
-
-StgAP_STACK *new_aps; // a closure to save the top stack frame on the heap
-int i;
-int size_words;
arg1_brk_array = BCO_NEXT; // 1st arg of break instruction
arg2_array_index= BCO_NEXT; // 2nd arg of break instruction
@@ -836,6 +830,7 @@
// and continue executing
if (!returning_from_break)
{
+ StgArrWords *breakPoints;
breakPoints = (StgArrWords *) BCO_PTR(arg1_brk_array);
// stop the current thread if either the
@@ -845,6 +840,12 @@
if (rts_stop_next_breakpoint == rtsTrue ||
breakPoints-payload[arg2_array_index] == rtsTrue)
failure implementing :next command in ghci
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 about it. The problem is I failed miserably. I still think it is easy to do. I just do not know how to create correct arguments for rts_breakpoint_io_action and I have given up finding up myself for now. 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 is smaller than breakStackSize 2) current dynamic stack size is equal to breakStackSize and the current selected expression is not a subset of breakSpan I hope the above would make good sense but I do not really know since maybe rts does some funny things with stack sometimes. If you think the proposed behavior is garbage let me know why so that I do not waste more time with this :) Ok, lets get back to why I failed. I think anybody who knows rts well could probably tell me what's wrong in few minutes. The patch representing my attempt is attached. It is done against the latest ghc (head branch). I want to add stack size as the last argument of rts_breakpoint_io_action so its signature would change from: Bool - BreakInfo - HValue - IO () to: Bool - BreakInfo - HValue - Int - IO () Since dynamic stack is continuous I can find out stack size easily. I did not implemented this yet, as well I did not implement this at all for exceptions. The only thing I cared for now is passing one more integer to rts_breakpoint_io_action. The argument contains only zero now but that should be enough to see if I can add one more argument. I tested it by loading this source code to ghci: f :: Int - Int f x = x + 1 a = f 1 ... then I used :break f and :force a in ghci to see whether I can pass the new argument correctly. This test works since I added printing of the last argument (the wanna be stack size) in noBreakAction :: Bool - BreakInfo - HValue - Int - IO () noBreakAction False _ _ x = putStrLn $ *** Ignoring breakpoint ++ show x noBreakAction True _ _ _ = return () -- exception: just continue The noBreakAction implementation is just a test for now. Unfortunately when I force the last argument it crashes. I think it is because I do not create the closure for it correctly in the code for bci_BRK_FUN in rts/Interpreter.c. Can somebody tell me what is wrong there or where to find more information about how to fill in the stack with rts_breakpoint_io_action arguments correctly? Also, any information somewhere about where to use allocate and where to use allocateLocal? I was surprised a bit that interpretBCO uses allocate much but no allocateLocal which is supposed to be quicker for a single thread. I skimmed all of ghc commentary and read the pages which looked related carefully but either it is not there or I missed it :-( Thanks, Peter. hunk ./compiler/main/InteractiveEval.hs 348 -- this points to the IO action that is executed when a breakpoint is hit foreign import ccall rts_breakpoint_io_action [_$_] - breakPointIOAction :: Ptr (StablePtr (Bool - BreakInfo - HValue - IO ())) [_$_] + breakPointIOAction :: Ptr (StablePtr (Bool - BreakInfo - HValue - Int - IO ())) -- When running a computation, we redirect ^C exceptions to the running -- thread. ToDo: we might want a way to continue even if the target hunk ./compiler/main/InteractiveEval.hs 416 -- might be a bit surprising. The exception flag is turned off -- as soon as it is hit, or in resetBreakAction below. - onBreak is_exception info apStack = do + onBreak is_exception info apStack _ = do tid - myThreadId putMVar statusMVar (Break is_exception apStack info tid) takeMVar breakMVar hunk ./compiler/main/InteractiveEval.hs 427 resetStepFlag freeStablePtr stablePtr -noBreakStablePtr :: StablePtr (Bool - BreakInfo - HValue - IO ()) +noBreakStablePtr :: StablePtr (Bool - BreakInfo - HValue - Int - IO ()) noBreakStablePtr = unsafePerformIO $ newStablePtr noBreakAction hunk ./compiler/main/InteractiveEval.hs 430 -noBreakAction :: Bool - BreakInfo - HValue - IO () -noBreakAction False _ _ = putStrLn *** Ignoring breakpoint -noBreakAction True _ _ = return () -- exception: just continue +noBreakAction :: Bool - BreakInfo - HValue - Int - IO () +noBreakAction False _ _ x = putStrLn $ *** Ignoring breakpoint ++ show x +noBreakAction True _ _ _ = return () -- exception: just continue resume :: GhcMonad m = (SrcSpan-Bool) - SingleStep - m RunResult resume canLogSpan step hunk ./includes/StgMiscClosures.h 380 RTS_RET_INFO(stg_ap_ppp_info); RTS_RET_INFO(stg_ap_pppv_info); RTS_RET_INFO(stg_ap__info);
Re: a possibility to redefine built-in GHCi commands
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 to invoke a built-in command regardless of user defined commands he/she would need to start it with two colons (instead of one). It is an user interface change which may break some scripts, but it would allow to provide different default behavior. For example: * when I use GhciExt I want all my :continue commands to be actually :x :continue * it would allow to specify different order of searching for abbreviated commands as the default one * it would allow to specify different default switches for builtin commands Would such a change be merged upstream if I would provide a patch? Seems reasonable to me. OK, I created a ticket for it and attached the implementation to the ticket. http://hackage.haskell.org/trac/ghc/ticket/3084 Thanks, Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how dynamic stack approximation works
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 site of the bug. But you can think of the lexical call stack as what _would_ have been the dynamic call stack, if only the language were completely strict rather than lazy. Most people find the latter notion more intuitive for the purposes of finding program errors. OK, maybe I understand it. If the lexical stack would give me access to local variables for all its frames it would be probably better. In the current situation where I have only access to the free vars in the current expression it is not that useful. I mean for my code I know what is the creation chain. This may be different if I would debug somebody else's code. But when debugging my code I sometimes lose track what demand chain I'm in or why the hell I'm at the given location at all. Dynamic stack would help here a lot and it would help me to better understand lazy behavior of my code. The creation behavior is rather clear to me because it is explicit in the code. The lazy behavior may be more tough because it is implicit. Sure, but the plan to maintain an approximate debugging dynamic stack depends on one thing: There is no need to approximate the dynamic stack. It is directly available to the RTS, in full detail. Well, but this would be the exact stack. It would be great to see how ghci works but I'm not sure how much helpful it would be for debugging. I'm afraid it would have the same problem as _return binding (bug #1531). In my code _return is mostly wrong. I'm not even checking it out any more. Thanks, Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how dynamic stack approximation works
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 in the return stack inside /tickn/ is constant
and known for a given runtime version of ghc. Or variable but known
for each call individually. This is important to find out the number
of return addresses on the return stack just before the execution of
/case tickn of {_-e}/.
I don't fully understand what it is you mean. e.g. I don't know what
from the beginning of /case tickn of {_-e}/ means.
Let me try to explain a couple of things that might (or might not!) help
clarify. We don't normally see
case tickn of { _ - e }
because the byte-code generator turns this into
let
z = case tickn of { _ - e }
in
z
the debugger paper explains why we do this. Anyway, the byte code for
the closure for z does this:
- if the breakpoint at n is enabled then stop,
- otherwise, evaluate e
i.e. it doesn't push any stack frames.
Does that help frame your question?
I reread the paper and together with this it actually answered my question.
I thought that tickn represents a call to the debugger. But it is only
a byte code which is checked by interpreter and if the debugging
location is enabled then the interpreter breaks.
Also I have found out that what I originally intended would not work
because the interpreter can beak only at the beginning of a BCO. But
maybe there are other almost as good solutions. I'm aiming at these
features:
* :next command with the meaning: Break at the next source span which
has the same or smaller number of addresses on the return stack and
which is not a subset of the current source span.
* :stepout command with the meaning: Break at the next source span which
has smaller number of addresses on the return stack.
* build dynamic stack (more or less entirely in GHCi so if it is not
used it should not slow down GHC code interpretation; well doing it in
GHCi would mean it would be painfully slow because of thread switches
but if it proves useful it can be moved to GHC)
* ... and maybe also something like the last one (or the last few)
frames of lexical stack for the current source span; this one may not be
even that interesting if options to filter trace log are fine enough;
the problem with trace log is anything which is executed in a loop (so
e.g. even some stupid lambda in a map cal)
I'm not aiming at full lexical stack. This is not a promise I'll
implement the above things. I would like just some more information:
* what would be a good way (if any) to implement a new kind of break
point: Break at any tick (source span) if number of addresses on the
return stack is less than given number. Actually the ability to count
number of return addresses (although useful) is not that important. It
is important to find out whether the current return stack has more,
less, or the same number of return adresses than it had in a given
moment in past. Any good paper / web page where I could find how the
return stack is actually implemented?
* any good paper / web page where I can find how GHC profiler derives
lexical call stack approximation?
Thanks,
Peter.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
a possibility to redefine built-in GHCi commands
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 defined commands he/she would need to start it with two colons (instead of one). It is an user interface change which may break some scripts, but it would allow to provide different default behavior. For example: * when I use GhciExt I want all my :continue commands to be actually :x :continue * it would allow to specify different order of searching for abbreviated commands as the default one * it would allow to specify different default switches for builtin commands Would such a change be merged upstream if I would provide a patch? Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
queued GHCi commands are not context specific; a bug?
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 1 (line 7). Well, the stop happened but it continued immediately because of queued :continue command. But the command was queued in the context of breakpoint 0 and not breakpoint 1. Is it a feature or a bug? If it is a feature it is not good for scripting breakpoints :-/ ... and I do not see an easy way to work around it. Thanks, Peter. PS: I owe responses to some of you on this list, but I must check some docs or do some tests first so I hope I'll answer during weekend at worst. *status:0 pe...@metod [716] ~/tmp %* grep -n '^' b.hs 1:fn :: Int - Int 2:fn x = 3: let rv = add x 1 in 4: rv 5: 6:add :: Int - Int - Int 7:add a b = a + b *status:0 pe...@metod [717] ~/tmp %* ghci b.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( b.hs, interpreted ) Ok, modules loaded: Main. *Main :set stop :list *Main :break 4 Breakpoint 0 activated at b.hs:4:2-3 *Main :break 7 Breakpoint 1 activated at b.hs:7:0-14 *Main fn 100 Stopped at b.hs:4:2-3 _result :: Int = _ rv :: Int = _ 3let rv = add x 1 in 4*rv* 5 [b.hs:4:2-3] *Main :cmd return rv\n:continue Stopped at b.hs:7:0-14 _result :: Int = _ 6 add :: Int - Int - Int 7 *add a b = a + b* 8 101 [b.hs:4:2-3] *Main :continue 101 *Main :q Leaving GHCi. *status:0 pe...@metod [718] ~/tmp % * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how dynamic stack approximation works
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). The
point only says it would be fine to have stack without hints how to do it.
The dynamic call stack is already present, in the form of the runtime
execution stack. For debugging you might want to track more
information than we store on this stack, however.
Does GHC have the same stack for both return addresses and arguments or
are they separated? I assumed separated but I'm in doubt now. Do you
have enough (debug) information there already to at least match
arguments to function calls?
My point is that having an exact stack is probably better if it is not
too hard to do. On the other side if there is not enough debug
information already present, it may be easier to to maintain an
approximate debugging stack because most of the information needed for
it is already in there.
As I already said in other emails, I would rather choose dynamic stack
over lexical one if I was forced to choose only one of them. Actually, I
almost do not care about lexical stack and still do not understand why
people want it. Even for profiling it looks fishy because at least in
some cases it behaves like a dynamic stack (time is attributed where
expression is forced not where the expression looks to be in the lexical
stack).
You seem to have a plan for maintaining a dynamic stack for debugging,
perhaps you could flesh out the details in a wiki page, mainly to
ensure that we're discussing the same thing?
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 in the return stack inside /tickn/ is constant and
known for a given runtime version of ghc. Or variable but known for each
call individually. This is important to find out the number of return
addresses on the return stack just before the execution of /case tickn
of {_-e}/.
This looks achievable to me, but maybe it is not.
Do you think the condition can be satisfied without too much work?
If yes, I'll go on to write the page. If not it would be waste of time.
Thanks,
Peter.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: my experience with ghci debugger extensions
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 this weekend. http://hackage.haskell.org/trac/ghc/ticket/3035 It is there with a patch attached. Maybe you can still validate and add it to 6.10.2. Sorry for not noticing that you wanted me to do it. For me it is not important, I already run a custom ghc anyway because of other things so one more patch does not change much. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: my experience with ghci debugger extensions
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. Finallly, please do not forget to add a link to this in the GHCi Debugger wiki page at http://haskell.org/haskellwiki/GHC/GHCi_debugger and/or at the debugging page at http://haskell.org/haskellwiki/Debugging Ok, I found a note in HWN that Ashley Yakeley can create a wiki account. He kindly did it for me so I updated the second page. Also there does not seem to be a demand for ghciext package so I'm not going to advertise it any more but I'll keep the latest version here (if anybody would be interested): http://www.hck.sk/users/peter/pub/ Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
how dynamic stack approximation works
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 dynamic stack
needs libraries to be recompiled for debugging? I thought about it but I
could not figure out why it would be needed. Here is what I thought is
the way it works:
* the ticks only inform about the approximate start of the selected
expression; this is acceptable provided it makes it much easier to implement
* 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 in the return stack inside /tickn/ is constant and
known for a given runtime version of ghc
Provided the above is true then we can find out the number of items on
the return stack which was valid just before /case tickn of {_-e}/
was entered. Lets mark this number as tick_stack_sizen. Then the only
thing we need to build the approximation of the dynamic stack is to get
a callback from the runtime just before the number of items in the
return stack gets below tick_stack_sizen for the corresponding /case
tickn of {_-e}/ expression. That is the moment of step out from the
selected expression and that is the moment when we can pop an item from
our dynamic stack approximation. (Each entering of /tickn/ pushes one
item to the dynamic stack approximation.)
All the requirements to implement the above way seem to be easy to do
and they do not look like having too bad speed consequences. Just one
indirect memory access and a conditional jump more for each pop of a
continuation address from the return stack. And the most important thing
is that it does not matter whether a library you use is strobed with
ticks or not. If a library is not strobed it would just look like one
item in the approximation of the dynamic stack. If a library is not
interpreted (it is not being debugged) we do not want to be bugged with
its stack frames anyway ... probably. It looks to me better this way
without any experience with it yet. Some of the conditional jumps would
happen and would result in more work (maintaining the approximation of
the dynamic stack), but all non-tagged value accesses would not as well
as all expressions which are not annotated with ticks (like e.g. list
creation).
Anyway, since the libs would be needed to be compiled for debugging
something in the above is wrong. I would like to know what is wrong or
some pointer to some web page or paper which describes how the
approximation of the dynamic stack works for profiler. I cannot think of
other way the profiler dynamic stack approximation would work :-/
Thanks,
Peter.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: my experience with ghci debugger extensions
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 evenings are sparse :-( If I would do anything, should it be posted here, sent to Pepe, or attached to the ticket? Is it a habit to indicate in the ticket that somebody started coding it actually (especially if it takes longer to implement)? So #1531 is tricky to fix, unfortunately. The implementation of _result is a bit of a hack in the first place. The fundamental problem is that a tick expression looks like this case tickn of _ - e where 'e' is not necessarily exactly the same as the expression that was originally inside the tick. We are careful to maintian the property that the tick is evaluated iff the original expression is evaluated, but that's all. _result is bound to e, which may or may not be what you wanted. One way to fix it would be to add extra constraints on what the simplifier can do with tick expressions. I don't like the sound of that because (a) I doni't know exactly what restrictions we'd have to add and (b) this amounts to changing the semantics of Core (i.e. changing which transformations are valid). Ok, I did not understand this part a bit till I did not skim over http://www.haskell.org/~simonmar/papers/ghci-debug.pdf Maybe that paper should be mentioned on the wiki pages about debugger. Something like: If you do not understand why ghci debugger is limited in such a strange way read this. A breakpoint condition on _result: My guess is that in about half of the cases I can just put them on a free variable on some other location just as comfortably. In other cases I'm out of luck :) As for as /:next/ command: Like Pepe indicated, I do not have idea how to do it without working _result and without dynamic stack. Though dynamic stack should not be that hard since how otherwise could profiler count ticks for cost centers. And dynamic stack would be great. It would create new options where to store lists of free variables of selected expressions :) Maybe there's another way to fix it, but I can't think of one right now. If by simplifier you did not mean straight translation to core, then I assume you wanted to try to just skip over all the optimizations (simplifications?). Was it hard to do it or was the performance impact so bad that it was not worth the addition of a command line switch? Thanks for reading the post about debugging, now there is at least a chance that it will be better once. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
my experience with ghci debugger extensions
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 should be available at breakpoint location and doing it without recompilation; here is the link to Claus' message: http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15900 * it gives some idea to ghc team about importance of ghci debugger related tickets (and whether to implement them just the way they were proposed) A note to ghc developers: Stepping program in ghci debugger sometimes purges top level bindings and sometimes not. Not sure this is a bug or feature (whether there is some logic in it). I do not have a simple example when it purges the bindings. But I did not really look for one. I would probably post later, but some ghci bugs and missing features are badly limiting my progress. There is not much more I can think of to investigate. Maybe somebody will have better ideas how to solve the obstacles I'm hitting. I'm also posting with hope that people will find this interesting and ghc team will fix some of the critical bugs and adds the most critical features, especially if somebody will not have better debugging tips. You can get my extensions here: http://www.hck.sk/users/peter/pub/ghciext-0.1.tar.gz The extensions are not in a single .ghci file now. The new .ghci file needs to install a library. The reason is that without the library it is not manageable any more. And here are arch linux packaging instructions for my custom ghc (if you are an arch linux user just download and run makepkg :) ): http://www.hck.sk/users/peter/pub/ghc-custom-6.10.1.tar.gz The custom ghc is just the same one as ghc 6.10.1 with two more patches: t2740.patch and loglocal.patch. The first one fixes ticket 2740 and you will get it in 6.10.2. The second one adds :loglocal command to ghci. You can extract the patches from the tar file. If you already read ghci scripting tutorial from Claus Reinke then you will know how to customize ghciext (that is if you would feel like doing so). The tutorial is here: http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html Here is the list of custom commands in ghciext package: :defs -- list user-defined commands :. file -- source commands from file :redir var cmd... -- execute cmd redirecting stdout to var :grep pat cmd... -- filter lines matching pat from cmd output :* count cmd... -- run cmd count times :x cmd... -- run cmd with stdout suppressed :bp bpArgs -- put breakpoint at location bpArgs (adds hit count) :inject cc c sc b -- at location b execute c if cc, and stop if sc :monitor [c] vs b -- show comma separated variables at location b if c :watch cond bpArgs-- break at location bpArgs when cond is True :count (_|N) [bpArgs] -- count/query/stop execution at location bpArgs :find var cmd... -- step with cmd until var is found :findex str cmd...-- step with cmd until str is found :next [lazy] -- step over; lazy version forces only the top constructor :xout -- redirect ghci stdout to /dev/null :out -- redirect ghci stdout back to console :defs, :., :redir, :grep, are the same as the commands in Claus' tutorial. The only differences I recall now are: * grep pattern can be in quotation marks (easier search for spaces) * grep merges :browse output more nicely * redir can accept :step, :steplocal etc; i.e. also the commands which sometimes remove top level bindings * the commands do not pollute top level bindings so much The rest will describe my custom commands and now they relate to tickets in ghci track. If you want to check the tickets mentioned here then the most easy way is probably selecting them from this list: http://hackage.haskell.org/trac/ghc/search?q=pherceknoquickjump=1ticket=on The initial big problem was how to limit the amount of information ghci debugger spits at you when breakpoints with custom scripts are used. This is also mentioned in forth point of the unknown section of ticket #1377: /We can disable a breakpoint with :set stop N :continue, but this still prints out the breakpoint info when we stop. Should we print the info only if there were no commands?/ So I say: yes do it! Just disable any ghci output related to a breakpoint when the breakpoint has a custom code attached. We can disable the output ourselves, but then we disable all the output (including the output of the debugged program). People who are debugging console applications are busted (especially if the applications are interactive). This is not an issue for me since my application is not using console almost at all. I'm solving the problem by prefixing commands like
Re: :info features
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 scripting. Details how to do it are in tutorial from Claus Reinke: http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html Understanding all the possibilities and limitations of ghci scripting may take a day or maybe even more. But once you are done with it you can implement your :instances command and and something like :infoWithoutInstances withing an hour at most. And it is more interesting that you could do much more extensions like this easily if you need them in the future. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
fix for :count command of ghciext package
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 you want it. http://www.hck.sk/users/peter/pub/ghciext-0.2.tar.gz Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: my experience with ghci debugger extensions
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. :stepLocal is broken right now, as you say it traces a lot of garbage. I implemented it and shortly later noticed the problem you mention, but never got around to fixing it. Thanks for shouting. (unless you think it makes sense to keep two versions of this command, :logLocal and :stepLocal) I do no think it makes sense to keep two versions (both /:steplocal/ and /:loglocal/). I'm aware the name loglocal is bad. I named it that way since it was a way for me to fill in trace log with the right stuff using /:findex/. I kind of did not really intended to release this but I noticed that there was some activity on my ghci debugger related tickets and wanted to get it out till anybody starts to code. Yeah and I'm getting limited by bugs and missing features too. Back to the /:loglocal/ and /:steplocal/. I think there should be only /:steplocal/, but I think the interface for tracing is bad. There should not be /:trace/ command at all. Instead (if the proposal with /:set trace/ is accepted (also mentioned in ticket #2946)) when /:set trace/ is set to True then /:steplocal/ would behave like now; if it is set to False it would behave like /:loglocal/. Of course setting trace to True is just a special case; in my opinion almost useless. The useful cases are when you can set it to scopes either denying them or allowing them. The idea is user should specify filter what is traced. With filter switched off nothing is traced and this case should not have any significant performance impact. When tracing filter is set up into something more complicated it may have some performance impact, but in that case we are not after speed. - Your idea of forcing _result to implement step over is very nice. A while ago I tried and failed at implementing :next. The conclusion was it cannot be done without a lexical call stack. Your idea could be useful as a pseudo :next, as long as the user of the debugger is ok with changing the evaluation semantics of the program. However, I don't know if there is a fix for the _result bug at hand's reach. As for as the /:next/ semantics. I actually do not know what it should be in a lazy language. The trick with _result is close sometimes. I could really use it. Especially in my /if/ conditions. They are often simple in my code just some simple arithmetics and record accessors. Stepping over them individually is a pain. It would be also good to step over a function containing a loop when using /:loglocal/ otherwise (so that the loop does not pollute trace log). I look forward to playing this. Your custom ghc tar.gz file contains an additional patch, network.patch, but there are no instructions about it. I assume it is ok to ignore it. It is a patch from arch linux upstream. I do not have idea why it is there. It has license whatever arch linux has. You probably can find out more on arch-haskell mailing list. Finallly, please do not forget to add a link to this in the GHCi Debugger wiki page at http://haskell.org/haskellwiki/GHC/GHCi_debugger and/or at the debugging page at http://haskell.org/haskellwiki/Debugging Hmmm, I do not have wiki account and cannot create it. Create an account or log in page has a note: new account creation has been disabled as an anti-spam measure. So I guess it is up to somebody who has a wiki account :-D Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how can I run ghci monad actions from ghci command line
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 example, it looks like ghci is significantly smaller than the source in ghc-6.10.1/compiler/ghci directory. Hopefully my next changes (if any at all) will not need more than a custom ghci. The test I did needed also ghc change. The type of function GHC.resume changed from: /resume :: GhcMonad m = SingleStep - m RunResult/ to: /resume :: GhcMonad m = (SrcSpan-Bool) - SingleStep - m RunResult/ ... plus the corresponding implementation change. The added argument is a filtering function to limit source spans which can recorded in the trace history. I'll post more when I know how it changes my debugging experience. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how can I run ghci monad actions from ghci command line
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 :type :print). There's no way to do that right now, although you can play tricks with :define to pipe the output of GHCi commands into Haskell code. Look up Claus Reinke's example macros - they're on one of the wikis somewhere, but I don't seem to be able to find them with Google right now. Yes, I know about Claus' tutorial, it was great and I already use his techniques a lot. I even did a small change to ghc source code to try out some stuff for easier debugging. I'm hoping to post about my experience here (maybe in a week or two). What I was searching for in this post was a possibility to write full fledged plugins or something like that. Never mind, I already went through the initial pain of my custom change to ghc so if I ever need something more complicated again I can do my tests directly in the source code. Thanks, Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how can I run ghci monad actions from ghci command line
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 interested in are tied to the frontend or available for all GHC API sessions). As usual, there is the design question of what to expose and how, on which GHC HQ would like user input. Nothing is as helpful for that as an actual use case!-) So, yes, please do report on your experiments. Actually, I do not think I want much. I just want to have something significantly better than printf debugging for my application. GHC/GHCi hacking is not my primary goal. Even now I think I'm better off with ghci and my extensions than with printf debugging. It will improve much when 6.10.2 is out (fixing ticket #2740 you helped to pin down). This mostly means adding some ghci commands which automate what I'm doing manually when debugging. Most of my expriments are related to the tickets I filled in: checking whether I can have some cheap workarourd till they are implemented or whether they actually help as much as I hope. That means that for anything more complicated I need access directly to the representation of the same code which is just being debugged. From your response it looks that if I needed something more again I'll just need to create my own version of GHCi driver and reuse the rest through GHC API. If there is some tutorial how to build custom GHCi driver or something else at a higher level (i.e. not the GHC API docs directly), please, let me know. I'll post when I have my first round of enhancements done and will be able at least guess how much they are helping. It may even help GHC team to decide whether to scrap my tickets or implement them :-D Thanks, Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how to load an additional file to ghci
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. There is no dependency from the modules already loaded to the one I would like to add. How to achieve something like load a module in this file in addition to what I have already loaded and do not modify the the context for expression evaluation (:module) ... just make the exported functions in the file available through fully qualified names. :add ? Aaaach right that works, I'm ashamed :-D Thanks, Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
how to load an additional file to ghci
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 the one I would like to add. How to achieve something like load a module in this file in addition to what I have already loaded and do not modify the the context for expression evaluation (:module) ... just make the exported functions in the file available through fully qualified names. It would be handy for some helper stuff I have which is project independent and too often modified to be installed. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
how can I run ghci monad actions from ghci command line
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci debugger :trace command does not always extend trace history
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 tracker: http://hackage.haskell.org/trac/ghc/newticket?type=feature+request Trace history should not be context/resume specific but global: http://hackage.haskell.org/trac/ghc/ticket/2945 Tracing should be controlled by a global flag (it should not be resume context specific): http://hackage.haskell.org/trac/ghc/ticket/2946 If anybody cares about ghci user interface then he/she should comment on the two tickets since they propose ghci UI changes. I doubt there would be complains about the first ticket but the second one may be more controversial. Thanks, Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci debugger :trace command does not always extend trace history
:-( If you are interested you can find :find and :monitor implementations here: http://www.hck.sk/users/peter/pub/.ghci It looks to me that the way tracing is done is unfortunate from the point of view of scripting custom ghci commands. It would be better to have a global trace history which would be activated/deactivated with command like :trace on/off and this would modify the behavior of the rest of the ghci commands appropriately. E.g. :continue would behave like :trace (without arguments) when tracing is on. It would be probably interesting to have more tracing buffers (but I did not think about this much). Now, it is done in a cool functional way which means more complicated user 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 anything to the trace history and I cannot check why value z is 2, because value of y is not in the trace history. Is this the expected behavior? If it is, how can I make ghci to extend the trace history when forcing variables? Peter. Here is the example: status:0 pe...@metod [765] ~/tmp % cat a.hs test :: Int - Int test x = let y = x+1 in let z = y+1 in z status:0 pe...@metod [766] ~/tmp % ghci a.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( a.hs, interpreted ) Ok, modules loaded: Main. *Main :break Main 5 Breakpoint 0 activated at a.hs:5:2 *Main :trace test 0 Stopped at a.hs:5:2 _result :: Int = _ z :: Int = _ 4let z = y+1 in 5z 6 [a.hs:5:2] *Main :back Logged breakpoint at a.hs:(2,0)-(5,2) _result :: Int 1 test :: Int - Int 2 test x = 3let y = x+1 in 4let z = y+1 in 5z 6 [-1: a.hs:(2,0)-(5,2)] *Main :back no more logged breakpoints ok so far - y and z have not been evaluated. [-1: a.hs:(2,0)-(5,2)] *Main :forward Stopped at a.hs:5:2 _result :: Int z :: Int 4let z = y+1 in 5z 6 [a.hs:5:2] *Main :trace z 2 this evaluates z. [a.hs:5:2] *Main :back Logged breakpoint at a.hs:(2,0)-(5,2) _result :: Int 1 test :: Int - Int 2 test x = 3let y = x+1 in 4let z = y+1 in 5z 6 You are going back in the original context, but I presume you were expecting to go back in the evaluation of z. You can only go back in the context of the current evaluation, however. Try this: *Main :break 3 Breakpoint 4 activated at trace.hs:3:10-12 *Main :trace test 0 Stopped at trace.hs:3:10-12 _result :: Int = _ x :: Int = 90 2 test x = 3let y = x+1 in 4let z = y+1 in [trace.hs:3:10-12] *Main :history -1 : test (trace.hs:4:10-12) -2 : test (trace.hs:5:2) -3 : test (trace.hs:(2,0)-(5,2)) end of history [trace.hs:3:10-12] *Main :back Logged breakpoint at trace.hs:4:10-12 _result :: Int y :: Int 3let y = x+1 in 4let z = y+1 in 5z [-1: trace.hs:4:10-12] *Main :back Logged breakpoint at trace.hs:5:2 _result :: Int z :: Int 4let z = y+1 in 5z 6 Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghci debugger :trace command does not always extend trace history
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. Is this the expected behavior? If it is, how can I make ghci to extend the trace history when forcing variables? Peter. Here is the example: status:0 pe...@metod [765] ~/tmp % cat a.hs test :: Int - Int test x = let y = x+1 in let z = y+1 in z status:0 pe...@metod [766] ~/tmp % ghci a.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( a.hs, interpreted ) Ok, modules loaded: Main. *Main :break Main 5 Breakpoint 0 activated at a.hs:5:2 *Main :trace test 0 Stopped at a.hs:5:2 _result :: Int = _ z :: Int = _ 4let z = y+1 in 5z 6 [a.hs:5:2] *Main :back Logged breakpoint at a.hs:(2,0)-(5,2) _result :: Int 1 test :: Int - Int 2 test x = 3let y = x+1 in 4let z = y+1 in 5z 6 [-1: a.hs:(2,0)-(5,2)] *Main :back no more logged breakpoints [-1: a.hs:(2,0)-(5,2)] *Main :forward Stopped at a.hs:5:2 _result :: Int z :: Int 4let z = y+1 in 5z 6 [a.hs:5:2] *Main :trace z 2 [a.hs:5:2] *Main :back Logged breakpoint at a.hs:(2,0)-(5,2) _result :: Int 1 test :: Int - Int 2 test x = 3let y = x+1 in 4let z = y+1 in 5z 6 [-1: a.hs:(2,0)-(5,2)] *Main y interactive:1:0: Not in scope: `y' [-1: a.hs:(2,0)-(5,2)] *Main :back no more logged breakpoints [-1: a.hs:(2,0)-(5,2)] *Main :forward Stopped at a.hs:5:2 _result :: Int z :: Int 4let z = y+1 in 5z 6 [a.hs:5:2] *Main z 2 [a.hs:5:2] *Main y interactive:1:0: Not in scope: `y' [a.hs:5:2] *Main :quit Leaving GHCi. status:0 pe...@metod [767] ~/tmp % ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi debugger status
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 to the dynamic stack or is there something more complicated? Right, I think they expect exactly that, and it'll confuse people that some stack frames are missing. Often it's not clear which calls are tail-calls and which are not. Mind you, I think the fact that it's a dynamic call stack rather than a lexical call stack is likely to confuse the same set of users even more. That is a good point, I might not see at the first look whether it is a tail call or not. Which reminds me that if it is implemented the way I expected then stack frames which are tail calls should be marked that way so that it is possible to see at the first look whether the given stack frame is a tail-call or not. If it will be a lexical call stack I'm curious how the pruning will be done so that we do not miss stack frames when we return from some code which corresponds to an imperative loop. Maybe a top limit on the number of stored lexical frames in one imperative (call-recursive) frame? From my point of view this could work well enough if it can print something like and here there were some lexical frames pruned and we are going one dynamic frame higher. My reasons why I want to see it with tail-calls collapsed into one stack frame is that I need debugger to figure out why something does not work so I should see what it looks like close to the execution model where the bugs actually present themselves. I believe that collapsed tail-calls is not such a big deal if there is a way to filter trace history (like tracelocal idea or something similar) or maybe having a really long trace history. Hmmm, maybe it would be even possible to recover last part of the lexical stack from the dynamic stack and the trace history. I discussed a bit with Pepe Iborra about how to build the dynamic (lazy) stack from a trace on the fly. Something like whenever we reduce an expression we would prune the corresponding node in the trace. Such a pruned trace should correspond to the dynamic stack. (If I do not miss something which I probably do.) And moreover if we record the expressions (their source code range) we just pruned and the result they reduced to then we can show it with some command like :showexpressionresults. This would provide access to unnamed values which could have been sent to a lower level calls as inputs. And that is part of the problem we discussed in this thread. Anyway thank you, Clause Reinke and Pepe Iborra for all the great help with ghci ... I'm still learning how to script ghci debugger better. I hope I can make it better than printf debugging with the scripts :-) Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
simple ghci debugger question
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 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi debugger status
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 full (not only would that tell me what instantiation of my code I'm in, it would also seem necessary if I want to reconstruct what the current expression is) I don't understand what you mean here - surely in order to reconstruct what the current expression is you only need to know the values of the free variables of that expression? Also I don't understand what you mean by the next enclosing scope. Could you give an example? 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 (corresponding to the dynamic stack slot). I actually considered this as a feature request but I decided that I would like to have this implemented sooner: http://hackage.haskell.org/trac/ghc/ticket/2737 Currently, I only use the debugger rarely, and almost always have to switch to trace/etc to pin down what it is hinting at. What is the intended usage pattern that makes the debugger more effective/ convenient than trace/etc, and usable without resorting to the latter? Set a breakpoint on an expression that has the variable you're interested in free, and display its value. If your variable isn't free in the expression you want to set a breakpoint on, then you can add a dummy reference to it. Actually I use it a bit differently mostly because I know (or I'm guessing) where the bug is located and set a breakpoint at a place which is hit just after the wrong decision happens. The just after wrong decision requirement is there so that I do not need to have too complicated expressions in the conditional breakpoint. Then I count how many times the breakpoint is hit of find some other expression which is true just before the hit I'm interested in (the hit with bug). I modify the script of the breakpoint so that it stops just before the hit I'm iterested in and restart. After restart the debugger stops at the modified breakpoint and I continue with either :steplocal or :trace. This is so that I have values of previous expressions in the trace history. Then (If I used :trace) I check the values in the trace history to find out why I got at the wrong place. The procedure is quite complicated but I do not know about quicker way to position the debugger at the right place and with the right variable values caught in the trace history. If I would not know the approximate location of the bug then hpc can help. For more simple things printf debugging is just enough. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi debugger status
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 ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. [1 of 1] Compiling Main ( Debug.hs, interpreted ) Ok, modules loaded: Main. *Main :break f Breakpoint 0 activated at Debug.hs:(1,0)-(2,24) *Main f 3 2 1 Stopped at Debug.hs:(1,0)-(2,24) _result :: a = _ [Debug.hs:(1,0)-(2,24)] *Main :list vv 1 f x y z | xy = z 2 | otherwise = z*y ^^ 3 [Debug.hs:(1,0)-(2,24)] *Main :step Stopped at Debug.hs:1:10-12 _result :: a = _ [Debug.hs:1:10-12] *Main :list 1 f x y z | xy = z ^^^ 2 | otherwise = z*y [Debug.hs:1:10-12] *Main Looks like a bug to me, At this location the x a y should be observable and cought in trace history. It actually looks very similar to bug I reported here: http://hackage.haskell.org/trac/ghc/ticket/2740 Notice that if you write your function like this (as I mostly do): f x y z = if xy then z else z*y then x and y are observable when if xy then z else z*y is selected but not when xz is selected! I see that you use windows, I did in past to but switches to linus since there were too much problems on windows with ghc, expecially libraries. Anyway here are some tips you might like: * you can avoid /cygdrive prefix in cygwin if you set cygdrive-prefix to /; see man mount and search for -c option * you can get nicer selection of expression if you set TERM=linux and launch ghci as ansicon ghc --interarctive * you can get ansicon from http://www.geocities.com/jadoxa/ansicon/index.html and a patch for it here: http://www.hck.sk/users/peter/pub/ Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi debugger status
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 (corresponding to the dynamic stack slot). I actually considered this as a feature request but I decided that I would like to have this implemented sooner: http://hackage.haskell.org/trac/ghc/ticket/2737 As long as you start with :trace, you can see the dynamic stack with :history, and traverse it with :back. At any point in the stack the free variables are available, or so I believe. What is the missing feature you would like to request in this case? Hmmm, I believe that dynamic stack is not the same as :trace history. The point is that the trace history shows all the evalueated expressions as they occure in time. But dynamic stack shows only the expressions which evaluation did not finish yet. Example: 1 let fn a = 2 let f x = x + 1 in 3 case f a of 4 1 - one 5 _ - When selected expression is one then the trace will contain something like this (just doing it from the top of my head): line 1-5 fn a = ... line 3-5 case f a of ... line 3 f a line 2 let f x = x + 1 in line 2 x + 1 possibly something from outside which forces x and consequently a line 4 one But the dynamic stack would contain: line 1-5 fn a = ... line 3-5 case f a of ... line 4 one The difference is that the dynamic stack contains only the items which computation is not finished yet. The stuff which was already reduced to a final value is not there any more. This way you could trace the dynamic stack back to see what arguments was your function called with since the arguments must be free variables in the expression which called your function of interest. Of course the same information is in the trace too ... that is if your trace history is long enough and you are willing to search it manually. That is the rason for ticket 2737. I do not want to search it manually! Maybe trace is the dynamic stack and I did not realize what trace contains till now. That would be kind of a shame :-D Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi debugger status
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 my response to Pepe Iborra in this thread). I just did not ask for it with a new ticket since: * I think it is already requested by some other ticket * if you compile with -Wall then :tracelocal should have the same information and only rarely name collision happens so automatic tracelocal trace search should return what you are looking for too and when needed it reruns more ... that is if the function is short enough to fit in the tracelocal history queue The ticket actually has two almost independent parts: * Adding tracelocal trace. * Adding the automatic search for symbols in the trace and the trace in the search could be also some other kind of trace like (e.g. dynamic stack). This would not be that useful though since the names at higher levels in stack are typically different. So to make it good it would require matching formal arguments to expressions on higher level and evaluating them, not that easy to do as simple tracelocal search which is just based on stupid string comparison. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi debugger status
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 bound during pattern matching in a function, say, prevFunc. Now I'm having another trace session, actually stepping from the very beginning. A couple of steps after the beginning, prev suddenly appears in the bindings where prevFunc absolutely has not yet been invoked. It's completely unrelated. In 'show bindings' prev has a wrong type - SomeType (it's ADT). Its real type (when in scope) is [t]. I ask 'length prev' and get 0 :) It is supposed to show only free variables in the selected expression. I'm sure I had cases when I was able to access variables which were not free in the selected expression but which would have been in scope if used in the selected expression. The values available seemed correct (contrary to your case). I thought it was a step to get all the variables in scope to be visible but later I learned it is not feasible and my lucky experience was probably a bug. If I encounter it again should I fill a bug report? I mean: is it really a bug? Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: could ghci debugger search for free variables better?
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 against it or do you need them against 6.10.1rc1 only? Bug reports against 6.8.2 are fine, but if you can test against 6.10.1 that's even better (it might weed out bugs that have been already fixed and thus save us some time). Here it is (against 6.8.2): http://hackage.haskell.org/trac/ghc/ticket/2740 Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: could ghci debugger search for free variables better?
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: everything
becomes recursive, for one thing. Well, perhaps you could omit all the
recursive references (except the ones that are also free?), but there
would still be a lot of overhead due to having to retain all those extra
references.
It also risks creating serious space leaks, by retaining references to
things that the program would normally discard.
Fortunately it's usually easy to work around the limitation, just by
adding extra references to your code, e.g. in a let expression that
isn't used.
Yes, Pepe pointed this to me too along with the Step inside
GHCi debugger paper in monad reader. The problem is that
I mostly can find out what is wrong when I look at values of
some important variables when some important place in my code
is hit. Using the trick with const function to manually add
references is not that much better than simple printf
debugging (adding Debug.Trace.trace calls to the code).
Tracing the execution history is nice too but it provides
much more than what is needed and obscures the important parts.
OK, It is frustrating that I find printf debugging often more
productive than ghci debugger.
I see that it is not a good idea to keep references to all the
variables in scope but maybe few improvements are possible:
1) As there is :steplocal, there should be also :tracelocal.
It would keep history of evaluations within given function
then when user asks for a variable it would be searched
first in the selected expression and if not found in the
expressions from the tracelocal history. If the result
would be printed from tracelocal history it should be indicated
so in the output. This would avoid the tedious task of
searching the trace history manually and moreover it would
limit the history to the interesting parts (so hopefully
the depth of 50 would be enough). The results from the
tracelocal history may not be from the expected scope
sometimes but the same problem is with printf debugging.
2) I noticed only now that I do not know how to script
breakpoints. I tried
:set stop if myFreeVar == 666 then :list else :continue
... and it did not work. My goal was to create a conditional
breakpoint. I also wanted to use it instead of printf
debugging using something like
:set stop { :force myFreeVar; :continue }
Ideally it should be possible to attach
different script for each breakpoint and the functions
for controlling debugger should be available in the
Haskell. I would expect this is already partially possible
now (using :set stop) and possibly some functions from
ghci api which correspond to ghci commands (like :set etc.).
But I do not know how, any pointers from experienced ghci
debugger users?
Ghci debugger did not know some functions in my code which
I would expect it to know; e.g. field selection functions
from a record which is not exported from the module but
which are available withing module. Is this expected?
(I did not have any *.hi *.o files around when ghci did run
the code.)
Och and sometimes it did not recognize a free variable in
the selected expression. The code looked like
let myFn x = x `div` getDivisor state 100 in
if myFn xxx then ...
the expression myFn xxx was selected while browsing trace
history but xxx was not recognized, but when I browsed into
myFn definition in the trace log the x (which represented
the same value) was recognized. Is this expected?
Thanks,
Peter.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
could ghci debugger search for free variables better?
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 I can examine few more variables. But if it happens at all it is rare. Is there a way to make ghci recognize all the variables which could be visible in the selected expression? By could be visible I mean they are in scope and can be used in the expression if I would edit the source code. ... well I would like to see the stack too but this does not annoy me that much. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc.exe: panic! (the 'impossible' happened)
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 files from previous ghc as it was suggested to me. And I was told there is nothing strange in gtk2hs 0.9.13 to cause this. A version of gtk2hs 0.9.12.1 I compiled myself works with ghc 6.8.3. I did not try to compile 0.9.13. Any ideas? Peter. status:0 [EMAIL PROTECTED] [764] /c/tools/Gtk2Hs/demos/hello % ls Makefile World.hs status:0 [EMAIL PROTECTED] [765] /c/tools/Gtk2Hs/demos/hello % ghcii.sh World.hs GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( World.hs, interpreted ) Ok, modules loaded: Main. *Main main Loading package array-0.1.0.0 ... linking ... done. Loading package bytestring-0.9.0.1.1 ... linking ... done. Loading package mtl-1.1.0.1 ... linking ... done. Loading package glib-0.9.13 ... interactive: Unknown PEi386 section name `.reloc' (while processing: C:/tools/Gtk2Hs/HSglib.o) ghc.exe: panic! (the 'impossible' happened) (GHC version 6.8.3 for i386-unknown-mingw32): loadObj: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *Main :quit Leaving GHCi. status:0 [EMAIL PROTECTED] [766] /c/tools/Gtk2Hs/demos/hello % ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: gmp
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 only for Integers and Rationals. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 is impressive!
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! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 is impressive!
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% probability that -O2 is slower than -O with my application. I rerun the tests I was running before again 3 times and in one case the -O2 variant was quicker. Before I did the comparisons about 3 times, so that would indicate that -O2 is slower with about 83% probability :-) The time differences are minuscule, but they do not seem to be a result of a bad/good luck only. I did optimize the code only once to reduce memory consumption. Speed was always good enough for me. It is a Gtk2Hs application which draws charts. Data are read from a text file, preprocessed, and a chart is shown. Ignore real times in the results since I need to fill in one edit box to run it for a longer time (to process more input data) and differences in my typing speed are most of the real time differences. Before each compile the project was cleaned. Options were always like this: --make -Wall theOptimizationOptions fileList The machine: Windows XP 64bit (running 32 bit Haskell and the app.) 2GiB DDR400 RAM Athlon XP64 X2 4800+ CQ disabled (but it does not seem to have impact) -O -fexcess-precision real 25.391 user 19.109 system 0.359 cpu 19.469 page_faults 79315 real 25.188 user 19.141 system 0.453 cpu 19.594 page_faults 79314 real 25.000 user 19.031 system 0.375 cpu 19.406 page_faults 79302 -O2 -fexcess-precision real 24.922 user 19.141 system 0.438 cpu 19.578 page_faults 78550 real 25.266 user 18.984 system 0.484 cpu 19.469 page_faults 78538 real 25.000 user 19.109 system 0.563 cpu 19.672 page_faults 78539 -O2 -fno-liberate-case -fexcess-precision real 24.516 user 18.844 system 0.453 cpu 19.297 page_faults 79310 real 24.219 user 18.875 system 0.438 cpu 19.313 page_faults 78203 real 24.375 user 18.656 system 0.516 cpu 19.172 page_faults 79305 -O2 -fno-spec-constr -fexcess-precision real 24.203 user 18.641 system 0.719 cpu 19.359 page_faults 78543 real 24.719 user 18.781 system 0.625 cpu 19.406 page_faults 78536 real 24.688 user 19.000 system 0.500 cpu 19.500 page_faults 78536 So it looks like liberate-case hurts my app a bit and something else in -O2 is helping a bit. But I do not mind since it is quick enough. I just found it interesting that -O2 is not helping. If you would like some more tests let me know. Peter. Simon Peyton-Jones wrote: O2 mainly switches on two transformations: liberate case and call-pattern specialisation. (I think it also gets passed on to gcc.) Trying -O2 -fno-liberate-case, and -O2 -fno-spec-constr might tell which was making the difference. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 is impressive!
-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 wrote: Hello Peter, Friday, November 9, 2007, 8:47:21 PM, you wrote: -O2 -fno-liberate-case -fexcess-precision -O2 -fno-spec-constr -fexcess-precision test also with -O2 -fno-spec-constr -fno-liberate-case -fexcess-precision ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
where is the full stack trace assigned to its id
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 stack trace corresponding to 651 identification number? I expected it to be in app.exe.prof (as it is with -hr option), but that file is empty. Do I miss some other RTS option? Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
hyperlinked GHC v6.6 grammar (just syntax part)
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 useful. It is not complicated provided that I have a nicely formated EBNF grammar to start with. I agree it would be great if parser generators do this, but there may not be enough interest and I do not have time to do it all myself. I can provide assistance and some code to start with though. Could be worth a license change too. ANTLR generated a hyperlinked grammar description when generating a parser but it does not contain the backward links. When I contacted the authors there was not really an interest there. I checked out the BNFC report. Looks interesting. Though, it was not clear from it whether one can generate hyperlinked html version of the grammar from the TeX source. Do you know it? No worries there, if there's anything to be sorry about it's depriving people not on ghc-users of such a nifty. If you really want to apologize you could make another with the grammar of GHC Haskell :) I added GHC v6.6 grammar. Only the syntax. Check http://www.hck.sk/users/peter/ and the notes at the end of the grammar to see what was changed. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
hyperlinked haskell 98 grammar
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 can navigate to any production using the nonterminal. If you like it please save and use your local copy since the server cannot handle much load. http://www.hck.sk/users/peter/ Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hyperlinked haskell 98 grammar
Hi Neil, For haskell-cafe members: This is what we are talking about: http://www.hck.sk/users/peter/ I'm glad somebody liked it. I do not understand what you mean by the extension request. Would you want to see the number of references of a production head even without opening the popup list box? If you meant that the pop-up list box should always display all backward links directly (without a scroll bar) then it would not work for a very big number of such links (in theory there can be hundreds there). If you do not like the default of 5 then change the nMaxRowCount constant. Anyway, if it is complicated to describe, let it be. I do not expect to play with the java script code much. Only the most trivial things have a chance to be implemented by me. I have written the java script code few years ago and I do not really like java script ... Just wanted to give back something to the community - so I added the Haskell specific data. As for as putting it on the Haskell org I do not mind if somebody else does it. Although I'm not that sure if it would require license change. If I would believe giving it into public domain would make more grammars browsable like this one then I would do it. I do not really expect heavy loads. From my experience most language users never ever look at the grammar nor they care about it. And those who consult it a lot will take a local copy and tweak it anyway. Looking at the munin server loads, looks like you and Esa are the only 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 server is not suitable for a large volume of users. I think it should also be integrated somewhere (perhaps a link from the HTML report, and certainly on the wiki) Thanks Neil On 8/16/07, Neil Mitchell [EMAIL PROTECTED] wrote: Hi Peter, A nice application. One suggestion: I would have implemented it so that a maximum on one backward hyperlink menu could be visible at once - try clicking on two RHS's and you'll get too menus visible at the same time. You also might want to mail this out on haskell-cafe - which is more appropriate for general haskell things, ghc-users is more for direct issues with GHC (although haskell-cafe can also be used for those) Thanks Neil On 8/16/07, Peter Hercek [EMAIL PROTECTED] wrote: 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 can navigate to any production using the nonterminal. If you like it please save and use your local copy since the server cannot handle much load. http://www.hck.sk/users/peter/ Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
simple question
What is $ function good for? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
