I'll be compiling it myself anyway but with this patch added:
http://hackage.haskell.org/trac/ghc/ticket/3858
... if there is an interest having the patch there.
I'm typically adding two more patches (but I can skip these for you if you
do not like it):
* add breakTick id to break point list
On 02/15/2012 10:28 AM, Adrien Haxaire wrote:
On Tue, 14 Feb 2012 13:01:05 +0100, Magnus Therning wrote:
Start with cleaning up your ah-ghc74 directory (you can use `git
clean` for that) and make sure you have `cblrepo` in your path. Then
the following steps ought to do the job:
$ cd
On 02/06/2012 02:15 AM, Felipe Almeida Lessa wrote:
On Sun, Feb 5, 2012 at 6:18 PM, Vesa Kaihlavirtavpkai...@gmail.com wrote:
So now I'm not so certain anymore about dropping it. We could again
wait for a while until HP catches up (it should be relatively fast
this time, since 7.4 is
On 02/06/2012 09:45 AM, Magnus Therning wrote:
On Sun, Feb 5, 2012 at 21:18, Vesa Kaihlavirtavpkai...@gmail.com wrote:
On Sat, Feb 4, 2012 at 7:08 PM, Magnus Therningmag...@therning.org wrote:
This was mainly directed to the Arch Devs on the list, and especially
Vesa since he's putting in
On 02/06/2012 12:42 PM, Magnus Therning wrote:
darcs is currently in [community] and it has to be automatically
compilable, using packages available in [core]/[extra]/[community].
So, if darcs is to remain in [commmunity] then a move to 7.4.1 *has*
to be concerned with it and all its
my opinion:
ghc 7.4.1; forget about hp; if something does not build
with ghc 7.4.1 then drop it from repository till some
of the package users fix it and provide a patch
if [extra] and [community] do not move just put ghc
in [haskell]; I'm actually like the idea that there should
not be
On 01/03/2012 10:18 AM, Magnus Therning wrote:
On Tue, Jan 3, 2012 at 10:12, Nicolas Pouillard
nicolas.pouill...@gmail.com wrote:
Indeed but I support the concept of the haskell-platform. It is too
restrictive to only packages able to track the latest versions of
their dependencies.
I suggest
On 01/03/2012 10:50 PM, Magnus Therning wrote:
On Tue, Jan 03, 2012 at 09:19:40PM +0100, Nicolas Pouillard wrote:
[...]
cabal supports installing multiple versions of the same packages so this
should be pretty easy to do the same.
Well, one of the things that cabal doesn't do is attempt to
On 12/17/2011 11:07 PM, Ethan Schoonover wrote:
As an end user, I effectively ignore the official Arch Haskell
packages as they are so far out of date. I'm also now trying to
disregard most of the AUR since I came across that thread. Haskell is
starting to feel fragile on Arch.
What about
arch: x86_64
haskell/haskell-glade 0.12.1-1 does not seem to be rebuilt against the
latest community/haskell-gtk 0.12.1-1
There was some renamin probably so conflicts appear now. My guess would
be that community packages got haskell prefix instead of gtk2hs? Not
really sure. Anyway the
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.
Hi,
This is a call to create pacman group with name haskell (or ghc or
something similar). All packages which depend on ghc would belong to the
group. The reason why I would like to see this is to allow disabling
update of any ghc dependency easily in pacman.conf. It would be cool if
Forgot to send this to group:
On 10/20/2011 01:30 PM, Magnus Therning wrote:
On Thu, Oct 20, 2011 at 13:03, Peter Hercekpher...@gmail.com wrote:
Hi,
This is a call to create pacman group with name haskell (or ghc or
something
similar). All packages which depend on ghc would belong to the
On 10/20/2011 02:31 PM, Peter Hercek wrote:
If somebody installs everything from haskell, then this would also
allow
installing everything at once (using the group name). Although for
this to
work we might need first to make sure there are no duplicates between
extra/community/haskell
On 10/20/2011 05:38 PM, Magnus Therning wrote:
On Thu, Oct 20, 2011 at 14:29, Peter Hercekpher...@gmail.com wrote:
AFAIK, exact pacman dependencies will detect all the problems when
installing a binary package. But detection and ease of you is a bit
different. I typically have a bit modified
On 07/30/2011 10:25 PM, Ian Lynagh wrote:
On Mon, Jul 25, 2011 at 06:21:16PM +0200, Peter Hercek wrote:
Is it a bug? Should it be reported to the ghc trac database?
Please report it and we'll take a look.
Thanks
Ian
It is done:
http://hackage.haskell.org/trac/ghc/ticket/5363
Peter
Here is a test program (file name prgSrc.hs):
import Data.Array.Unboxed
main = do
let l1 = [1..10] :: [Int]
let l2 = [ map (i+) l1 | i - [1..500] ]
let l3 = map (\l - listArray (1,length l) l) l2 :: [UArray Int Int]
print $ accumulate l3 0
accumulate [] rv = rv
accumulate (h:t) rv
On 02/22/2011 11:45 AM, Magnus Therning wrote:
1. Fully functional go-to-definition. With that I mean that
go-to-definition is aware of local definitions introduced in 'let' and
'where' clauses and ideally also for names bound in 'do' clauses.
I've found there are several ways to generate a
On 02/22/2011 12:26 PM, Marc Weber wrote:
learn about gd and gD those are not perfect though.
Also keep in mind that # * start searches on words.
They all are not language aware so they are only bad replacements for
what you're looking for.
When we are talking about such simple helpers then you
On 02/03/2011 07:49 AM, Magnus Therning wrote:
On 02/02/11 22:57, Peter Hercek wrote:
On 02/02/2011 11:26 PM, Magnus Therning wrote:
A way to mitigate this would be to either keep at kill list of files
to remove and when and/or having a separate repo for these archives.
Are there any tools
On 01/10/2011 03:45 PM, Peter Simons wrote:
To get the discussion started, I'd like to offer a concrete question
that you
might want to think about: is it realistic to try and support *all* of
Hackage?
I do no think this makes sense. My guess would be that most hackages
packages are not used
On 11/12/2010 05:19 PM, Peter Simons wrote:
Once package FOO is installed, and linked to local versions of its
dependencies, there is not much we can do to prevent that an update
to FOO's dependencies breaks the *local* system if it's upgraded.
Why can't we bump $pkgrel of
On 11/11/2010 02:41 PM, Nicolas Pouillard wrote:
On Thu, 11 Nov 2010 12:23:02 +, Magnus Therningmag...@therning.org wrote:
I made an attempt at providing exactly this, at
http://linode3.kiwilight.com/~magnus.therning/archhaskell/x86_64/
Please have a look at it and let me know what you
On 11/11/2010 06:07 PM, Nicolas Pouillard wrote:
On Thu, Nov 11, 2010 at 5:59 PM, Peter Hercekpher...@gmail.com wrote:
On 11/11/2010 05:44 PM, Magnus Therning wrote:
On Thu, Nov 11, 2010 at 16:41, Peter Hercekpher...@gmail.comwrote:
Hmm, what we would need is so that when haskell-pandoc
On 10/22/2010 09:37 AM, wren ng thornton wrote:
On 10/21/10 5:38 AM, Ketil Malde wrote:
I'm always getting two copies of everything in haskell@, since
everything is cross-posted to -cafe. Are there actually people
subscribed to -cafe, but *not* to hask...@? And if so, why?
I am. In part
On 06/20/2010 11:05 AM, Claus Reinke wrote:
I think Luke means that if you use qualified names then hothasktags
can give you better location information than current ghci ctags.
GHCi :ctags doesn't output tags for qualified names (though it
probably should), but that isn't enough for proper
Hi Claus,
On 06/15/2010 05:57 PM, Claus Reinke wrote:
If you go this route, I will shamelessly promote hothasktags instead
of ghci. It generates proper tags for qualified imports.
What do you mean by proper here?
I think Luke means that if you use qualified names then hothasktags can
give
On 04/08/2010 01:09 AM, Luke Palmer wrote:
On Wed, Apr 7, 2010 at 1:23 AM, Evan Laforgeqdun...@gmail.com wrote:
Derive.PitchDeriver Derive/Derive.hs98;file:Cmd/Cmd.hs
Derive.PitchDeriver Derive/Derive.hs98;file:Cmd/Play.hs
Derive.PitchDeriver
On 04/07/2010 09:23 AM, Evan Laforge wrote:
On Thu, Apr 1, 2010 at 1:46 PM, Luke Palmerlrpal...@gmail.com wrote:
VIm only for now, since I don't know if emacs tags format supports
scoped tags. I am aware that it is not perfect -- patches and bug
reports welcome.
This program
On 04/02/2010 10:15 PM, Dominic Espinosa wrote:
On Fri, Apr 02, 2010 at 06:11:52PM +0100, Stephen Tetley wrote:
On 2 April 2010 17:53, Dominic Espinosadces...@fastmail.fm wrote:
I ended up rewriting it in another language (due to time
pressure) and I'm a little wary of attempting to use
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
Should not be there a link to Haskell 2010 report on this page?
http://haskell.org/haskellwiki/Language_and_library_specification
That is if Haskell 2010 is finalized.
Where is the standard location to find Haskel Prime reports?
Peter.
___
Simon Marlow wrote:
On 20/10/2009 14:54, Ralph Crawford wrote:
So far so good. This is what I want to see - a listing like this for
every (interpreted of course) line of haskell code that runs, all the
way to the end. Since this is a very large program, at this point I
started pasting this to
Simon Marlow wrote:
On 19/08/2009 10:18, Peter Hercek wrote:
Why is stg_nofoceIO_info added as last argument to IO actions in
unregistered mode? Do I still need to pass it in even when (I think) my
IO action does not need it? E.g. is it required for every IO action by
some stack walking code
Ian Lynagh wrote:
We are aiming to have the first release candidate out on the 14th
September 2009.
Until then, we plan to focus on the bugs in the 6.12.1 milestone, marked
high priority; they are listed here:
Hi,
I thought I may look at the :next command for GHCi debugger again. If I
do, I will not make it before 6.12.1 is out. I have few questions about
RTS in relation to :next implementation. If they is easy to answer I
would appreciate it, if not, don't bother since I'm not sure I'll do it
...
On Fri, 14 Aug 2009 14:50:48 -0400, S. Alexander Jacobson wrote:
Is there a way from GHCi to discover the path to a particular module
that you have imported or loaded?
It may not be what you wanted but in the worst case you can use ghc-pkg
list to see all the package names then for each name
On Mon, 13 Jul 2009 20:48:42 -0400, Isaac Dupree wrote:
Peter Hercek wrote:
Simon Marlow wrote:
On 10/07/2009 15:31, Peter Hercek wrote:
It would be cool if ghci debugger could grab not only the free
variables in the selected expression but in one case a bit more. The
case is when we stop
Simon Marlow wrote:
On 10/07/2009 15:31, Peter Hercek wrote:
Hi,
It would be cool if ghci debugger could grab not only the free variables
in the selected expression but in one case a bit more. The case is when
we stop at a function definition the first time (when just entering
Hi,
It would be cool if ghci debugger could grab not only the free variables
in the selected expression but in one case a bit more. The case is when
we stop at a function definition the first time (when just entering it).
In this case it should provide bindings of the function arguments. Is
I like your proposal. Few notes below.
On Sun, 05 Jul 2009 23:45:31 -0400, Isaac Dupree wrote:
My dream situation: both haddock-pages and hscolour-pages would be
super-hyperlinked and super-readable. For example, haddock would list
all a module's definitions, not just its exports. In
On Wed, 17 Jun 2009 13:59:24 +0200, Peter Hercek wrote:
* If your code happens to have definitions on lines which happen to
exist more times in one source file then it may put you at an
incorrect location. I doubt it will ever happen but if anybody thinks
it is really bad we can keep
Simon Marlow wrote:
I'm an infrequent etags user, and I never use ctags.
The problem is I do not know whether I should try to improve etags too.
So far I tried to keep them the same they were. The only difference I
know about is that if more tags happen to exist on the same source line
then
Hi GHC and VI users,
I got frustrated with vi tags not working after some unrelated code is
edited in a source file. Moreover non-exported top level declarations
were not available in vi tags file. Here is an attempt to fix it:
http://www.hck.sk/users/peter/pub/ghc/betterCTags.patch
Why
Claus Reinke wrote:
Haskell isn't like other languages. If you search on source lines of
definitions, that'll break every time you change a pattern, parameter
name, parameter order, clause order, ..
This is what I do. The whole line is searched to avoid as much of false
positives as possible.
Simon Marlow wrote:
On 28/05/2009 15:09, Claus Reinke wrote:
so for mere
traces, dynamic seems to be the choice (with an option of pseudo-cbv
or the real dynamic stack).
I don't know what pseudo-cbv is. And I claim the dynamic stack is
almost never what you want.
Ok, so there's one place
Dean Herington wrote:
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
... cut ...
Loading package mtl-1.1.0.2 ... linking ... done.
Loading package glib-0.10.0 ... can't load .so/.DLL for: intl (addDLL:
could not load DLL)
Ok, I do not use windows more than a year now exactly
Ok, I went with the preprocessor solution only. It is simple, stupid and
works well enough ... and template haskell alternative needs it anyway
not to be too unportable.
Both template haskell alternatives reported Pattern match(es) are
non-exhaustive of their own. The second alternative
...@haskell.org] On Behalf Of Peter Hercek
| Sent: 18 May 2009 10:46
| To: glasgow-haskell-users@haskell.org
| Subject: Re: Should exhaustiveness testing be on by default?
|
| Neil Mitchell wrote:
| I'm not a particular fan of exhaustiveness checking. It just
| encourages people to write:
|
| foo (Just 1
Claus Reinke wrote:
Given how long http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack
has been under discussion, it is probably time to provide a short-term
workaround in GHC, just a token to be replaced by the current source
location.
This would be the best solution.
Although
Neil Mitchell wrote:
I'm not a particular fan of exhaustiveness checking. It just
encourages people to write:
foo (Just 1) [x:xs] = important case
foo _ _ = error doh!
So now when the program crashes, instead of getting a precise and
guaranteed correct error message, I get doh! - not
Hi,
I know there were 4 unique IP addresses which checked it out. Since I do
not know who they are I just spam this list again :)
You can get it here: http://www.hck.sk/users/peter/pub/
If you decide to give it a try then read the README file before installing.
It should work with the stock
Andy Stewart wrote:
I saw GHC release new version now, and fix some bug.
I want to know below pacakges whether works fine with GHC-6.10.2 before i
upgrade it:
cabal, gtk2hs, xmonad, yi, leksah
Gtk2hs does not work with ghc 6.10.2 yet:
Simon Marlow wrote:
Peter Hercek wrote:
The proposed meaning for :next
Lets mark dynamic stack size at a breakpoint (at which we issue
:next) as breakStackSize and its selected expression as breakSpan.
Then :next would single step till any of these is true:
1) current dynamic stack size
Hi,
Maybe the code adding one Int argument to rts_breakpoint_io_action is
correct in general since when Pepe Iborra applied the patch to his ghc
trunk the test did not crash on his machine. Regardless on my machine
the test does not work even with the stock ghc 6.10.2 sources (so even
when I
Hi,
Pepe Iborra pointed out that my patch is not in the right format for gnu
patch command.
Sorry for inconvenience (I used darcs what -u instead of darcs diff -u).
Here it is attached in the correct format.
Thanks,
Peter.
diff -rN -u old-ghc/compiler/main/InteractiveEval.hs
Hi,
So I wanted to give implementing :next ghci debugger command a shot. It
looked easy and I could use it. Moreover it would give me an easy way to
implement dynamic stack in ghci (using similar approach as used for
trace) ... well if I would feel like that since I was a bit discouraged
Colin Paul Adams wrote:
Adrian == Adrian Neumann aneum...@inf.fu-berlin.de writes:
Adrian You can use the ghci debugger
http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-
Adrian debugger.html
Adrian it can set breakpoints on exceptions.
So i tried adding the
Simon Marlow wrote:
Peter Hercek wrote:
Hi GHCi users,
I would like to be able to redefine the built-in GHCi commands. The
idea is that when searching for a command the user defined commands
would be searched first and only then the built-in commands would be
searched. If user wants
Malcolm Wallace wrote:
In a lazy language, the dynamic stack rarely tells you anything of
interest for debugging. For the value at the top of the stack, you get
one of many possible _demand_ chains, rather than the creation chain.
The demanding location is pretty-much guaranteed not to be the
Simon Marlow wrote:
Peter Hercek wrote:
Sure, but the plan to maintain an approximate debugging dynamic stack
depends on one thing:
The number of items (continuations) on the return stack from the
beginning of /case tickn of {_-e}/ to the moment when we can check
the count of items
Hi GHCi users,
I would like to be able to redefine the built-in GHCi commands. The idea
is that when searching for a command the user defined commands would be
searched first and only then the built-in commands would be searched. If
user wants to invoke a built-in command regardless of user
Wolfgang Jeltsch wrote:
Am Mittwoch, 25. Februar 2009 23:38 schrieb Peter Hercek:
So my opinion (IAMNAL):
1) source code under very limiting commercial license (just to allow
recompile with a newer LGPL lib and nothing else) is OK
2) it is probable that only the *.o, *.hi files and a linking
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
Wolfgang Jeltsch wrote:
I want to repeat what I’ve said earlier on this list: For Haskell, there is no
real difference between LGPL and GPL, as far as I understand it. If you don’t
want to force the users of your library to use an open source license for
their work then use BSD3 or a similar
Peter Verswyvelen wrote:
On Wed, Feb 25, 2009 at 11:02 PM, Peter Hercek pher...@gmail.com wrote:
* An LGPL library will force commercial users to release their source code
only to the users of their program (which already bought it) and only for
the purpose of recompiling with a newer
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).
wren ng thornton wrote:
Lacking a wiki account,
~wren
From HWN:
HaskellWiki Accounts. Ashley Yakeley can [12]create a HaskellWiki
account for anyone who wants one (account creation has been disabled as
a spam-fighting measure).
http://article.gmane.org/gmane.comp.lang.haskell.general/16846
Peter Hercek wrote:
Pepe Iborra wrote:
- Regarding your :logLocal, you should rename it to :stepLocal, open a
ticket, and attach your patch. We should really try to get this into
6.10.2.
Ach, I missed I'm supposed to do this first time I read the message.
I'll get to it at worst during
Pepe Iborra wrote:
- Regarding your :logLocal, you should rename it to :stepLocal, open a
ticket, and attach your patch. We should really try to get this into
6.10.2.
Ach, I missed I'm supposed to do this first time I read the message.
I'll get to it at worst during this weekend.
pepe wrote:
Having (a kind of messy approximation of) a dynamic stack is possible
with a variant of the cost center stacks mechanism used for profiling.
But the downside is that code and libraries would need to be compiled
for debugging.
Is there any info somewhere why the approximation of the
Hi Simon,
Simon Marlow wrote:
If you felt like working on this yourself, possibly with Pepe, then
we'd be happy to support in any way we can.
Thanks. It may happen though it is not probable. I do not know the code
so anything non-trivial is a significant effort and my free weekends and
Hi users of ghci debugger,
This post is going to be a bit longer. Here are few cookies to motivate
you to go on:
* you will probably like it more than printf debugging for a lot of cases
* it can provide a way of implementing Claus Reinke's idea of
breakpoints with a list of identifiers which
Remi Turk wrote:
SPJ agreed with the idea itself, but suggested an alternative set of commands:
:info Show-- See class definition only
:instances Show -- See instances of Show
Hi Remi,
If you do not want to wait till this is implemented you can do it
yourself using ghci
If somebody managed to download it already there is a newer version.
Break point counter inside break expressions was one less than it should be.
Sorry for inconvenience. It is still very new.
Not sure there would be enough interest to put it on hackage or
something like that.
Let me know if
Pepe Iborra wrote:
Hello Peter,
Your efforts are simply outstanding. Thanks a lot for sharing your
experiences. I want to add a few comments:
- Regarding your :logLocal, you should rename it to :stepLocal, open a
ticket, and attach your patch. We should really try to get this into
6.10.2.
Claus Reinke wrote:
ghci-haskeline
This package reimplements ghci using the GHC API and the
Haskeline package for line input in command-line programs.
Just a copymodify of some of the GHCi sources, including a
Main.hs to call the modified code.
Thanks for the information.
Ok, from the
Duncan Coutts wrote:
I've seen this occasionally. If you check gtk2hs-confg.h near the bottom
of the file you'll likely find something like
#def _GLIB_MAJOR_VERSION ()
rather than
#def _GLIB_MAJOR_VERSION (2)
It is ./configure that generates the gtk2hs-confg.h from
gtk2hs-confg.h.in based
Simon Marlow wrote:
Peter Hercek wrote:
Is it possible to run ghci monad actions from ghci command line somehow?
For example: I would like to check whether it variable is of type
Bool and whether it is True using normal Haskell code (i.e. not using
ghci commands starting with colon like
Claus Reinke wrote:
If the necessary functionality is not yet exposed through
the API, it probably should be (iirc, GHCi's frontend itself
isn't part of the API, but the functionality used by it is, so GHCi
is just one of several GHC API clients; don't know how far the
debugger features you are
Simon Marlow wrote:
Peter Hercek wrote:
Is it possible to load one more module to ghci without unloading the
modules I have already loaded? The module I would like to load in
addtion is not installed and I do not want it installed. It is also
independent of any other modules
Is it possible to load one more module to ghci without unloading the
modules I have already loaded? The module I would like to load in
addtion is not installed and I do not want it installed. It is also
independent of any other modules. There is no dependency from the
modules already loaded to
Is it possible to run ghci monad actions from ghci command line somehow?
For example: I would like to check whether it variable is of type Bool
and whether it is True using normal Haskell code (i.e. not using ghci
commands starting with colon like :type :print).
Peter.
Galchin, Vasili wrote:
I have a collection of functions .. but no main function. I am
reading Step Inside the GHCi debugger from Monad.Reader Issue 10 by
Bernie Pope. If I don't have a main function can I still use the ghci
debugger? (I tried to set a breakpoint on one of my functions
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
Hi,
Any idea why ghc 6.10.1 is still in Testing repository on archlinux?
Peter.
Don Stewart wrote:
Arch Haskell News: Jan 11 2009
--cut--
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
defined ghci commands ... unless I'm missing something :-)
Thanks,
Peter.
Simon Marlow wrote:
Peter Hercek wrote:
Hi,
I expected :trace expr to always add data to the trace history but
it does not do so for CAFs (which are not reduced yet).
My point is that the command :trace z did not add
Hi,
I expected :trace expr to always add data to the trace history but it
does not do so for CAFs (which are not reduced yet).
My point is that the command :trace z did not add anything to the
trace history and I cannot check why value z is 2, because value of y is
not in the trace history.
Simon Marlow wrote:
Peter Hercek wrote:
Simon Marlow wrote:
A similar argument applies to keeping the dynamic stack. The problem
with the dynamic stack is that it doesn't look much like you expect,
due to tail-calls.
Do you think people expect the tail-calls to add a stack frame
Is there a way to redirect output of a ghci debugger command
so that I can process it with a (ghci) script before it is
displayed?
Peter.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
Simon Marlow wrote:
Claus Reinke wrote:
Perhaps someone could help me to understand how the debugger is
supposed to be used, as I tend to have this problem, too:
- when I'm at a break point, I'd really like to see the current scope
or, if that is too expensive, the next enclosing scope, in
Claus Reinke wrote:
f x y z | xy = z
| otherwise = z*y
-
$ /cygdrive/d/fptools/ghc/ghc/stage2-inplace/ghc.exe --interactive
Debug.hs -ignore-dot-ghci
GHCi, version 6.11.20081122: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking
Pepe Iborra wrote:
On Mon, Nov 24, 2008 at 2:03 PM, Peter Hercek [EMAIL PROTECTED] wrote:
Maybe what Claus means is that he would like to see the dynamic
stack and be able to traverse it and at each location in the
dynamic stack he could investigate the free variables in the
expression
Daniil Elovkov wrote:
A refinement of :tracelocal could be :tracedirect (or something) that
would save the history not anywhere within the given function but only
within parents, so to say. For example,
This looks like what I thought of as searching for values in dynamic
stack (explained in
Daniil Elovkov wrote:
I'd like to know, how do ghc developers and users feel about the debugger?
Sometimes it is better/quicker than printf debugging :)
Now I see it mess up the list of bindings in a funny way. For example,
in a previous trace session I had a variable, say, prev. It was
David Menendez wrote:
On Sun, Nov 16, 2008 at 7:09 PM, Luke Palmer [EMAIL PROTECTED] wrote:
On Sun, Nov 16, 2008 at 5:06 PM, Peter Hercek [EMAIL PROTECTED] wrote:
... and the only value the function can return is bottom.
Is there any type system which would have more than
one value which
Bulat Ziganshin wrote:
Hello J.,
Monday, November 17, 2008, 12:56:02 AM, you wrote:
class MyClass r where function :: r - s
As Bulat said, your type signature is equivalent to:
function :: forall r s. r - s
only
function :: forall s. r - s
(r is fixed in class header)
... and the
Simon Marlow wrote:
Peter Hercek wrote:
As for as the rest of the message. Those are possible bugs.
If I can reduce them to few tens of lines of a test, I'll
post the bug reports. I use Archlinux and the last (non-testing)
version of ghc there is ghc-6.8.2. Do you accept bug reports
Simon Marlow wrote:
We thought about this when working on the debugger, and the problem is
that to make the debugger retain all the variables that are in scope
rather than just free in the expression adds a lot of overhead, and it
fundamentally changes the structure of the generated code:
May be my approach to debugging with ghci is wrong
but in about half of the time I find ghci (as a
debugger) almost useless. The reason is the limited
way it can resolve identifiers. I can examine
the free variables in the selected expression and
nothing else. Well, I *think* just sometimes
1 - 100 of 158 matches
Mail list logo
