Re: [arch-haskell] Upgrade to 7.4.2
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 and the information about ignored breakpoint; this is interesting when you want to find out which breakpoint was ignored; it is very dirty workaround for http://hackage.haskell.org/trac/ghc/ticket/2950 I did not have time to do a proper patch. * I'm adding 0.1s delay when printing ghci prompt. Another dirty way to get proper interleaving of stderr/stdout when stderr is coloured using something like http://www.hck.sk/users/peter/pub/colorize.c I use it to get all stderr in red (stdout is default black), and still achieve proper interleaving of stderr text with stdout text. It is quite possible this patch is not needed any more but it was needed when haskeline was introduced the first time. I do not know why, ghci was the only thing which showed any issues. I have 16GiB, so if the only problem is the memory, then I'll be quick. Otherwise, I do not mind if you use ghc from [extra]. There is no special reason not to use [extra] version except extra maintainers can break our dependencies if they do unexpected recompile probably with some significant patches. Although every recompile can break dependencies, mostly it does not happen. You can just place copy of the [extra] version in [haskell] and there should not be any problem at all since you would be in charge of any ghc update. We would mirror only the ghc package in [haskell]. Peter. On 06/15/2012 09:54 PM, Magnus Therning wrote: I've been working on upgrading [haskell] to Ghc 7.4.2 for a few days now. So far no luck :( The build always fails on creating documentation. Yesterday I resorted to taking the source package from [extra], which is known to build fine... but still it failed on generating the docs. I now suspect this is due to the limited memory available on the machine I use to build (1.5GB). For the moment I've given up on building Ghc especially for use in [haskell]. In order to move on I'll instead make use of Ghc out of [extra]. If anyone has any objections to that, then please speak up. /M ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] ghc 7.4.1 in a temporary repo
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 ah-ghc74 $ cblrepo build $(cblrepo list | cut -f1 -d\ ) ,,build-order $ cblrepo pkgbuild $(cat ,,build-order) $ ./makeahpkg -x -- ghc $(cat ,,build-order) Seems it built successfully. I started with a cblrepo sync to initialize it. Here are the files/directories in my ah-ghc74 directory after running the scripts: ,,build-order cblrepo.db ghc haskell-ansi-terminal haskell-ansi-wl-pprint haskell-cereal haskell-cmdargs haskell-crypto-api haskell-darcs-beta haskell-data-default haskell-dataenc haskell-entropy haskell-hashed-storage haskell-haskeline haskell-html haskell-hunit haskell-json haskell-largeword haskell-mmap haskell-mtl haskell-parallel haskell-parsec haskell-primitive haskell-puremd5 haskell-random haskell-regex-base haskell-regex-compat haskell-regex-posix haskell-regex-tdfa haskell-semigroups haskell-split haskell-syb haskell-tagged haskell-tar haskell-text haskell-transformers haskell-unixutils haskell-utf8-string haskell-vector haskell-x11 haskell-xmonad haskell-xmonad-contrib haskell-xmonad-extras haskell-zlib i686-chroot makeahpkg patches I made a copy of it for safety, then tried to install it: sudo pacman -U ghc/ghc-7.4.1-1-i686.pkg.tar.xz Mot de passe : chargement des paquets… résolution des dépendances... recherche des conflits entre paquets... Erreur : la préparation de la transaction a échoué (la satisfaction des dépendances a échoué) :: haskell-cpphs : requiert ghc=7.0.3-2 :: haskell-ghc-paths : requiert ghc=7.0.3-2 :: haskell-haskell-src-exts : requiert ghc=7.0.3-2 :: haskell-hlint : requiert ghc=7.0.3-2 :: haskell-hscolour : requiert ghc=7.0.3-2 :: haskell-hscolour : requiert haskell-containers=0.4.0.0 :: haskell-hunit : requiert ghc=7.0.3-2 :: haskell-json : requiert ghc=7.0.3-2 :: haskell-json : requiert haskell-array=0.3.0.2 :: haskell-json : requiert haskell-bytestring=0.9.1.10 :: haskell-json : requiert haskell-containers=0.4.0.0 :: haskell-json : requiert haskell-pretty=1.0.1.2 :: haskell-mtl : requiert ghc=7.0.3-2 :: haskell-parsec : requiert ghc=7.0.3-2 :: haskell-primitive : requiert ghc=7.0.3-2 :: haskell-quickcheck : requiert ghc=7.0.3-2 :: haskell-syb : requiert ghc=7.0.3-2 :: haskell-transformers : requiert ghc=7.0.3-2 :: haskell-uniplate : requiert ghc=7.0.3-2 :: haskell-vector : requiert ghc=7.0.3-2 :: haskell-xhtml : requiert ghc=7.0.3-2 It says it cannot resolve the dependencies, namely ghc 7.0.3-2, but ghc --version gives: The Glorious Glasgow Haskell Compilation System, version 7.0.3. Any clue? I did not update my arch for a while, maybe this is why. OK, I do not know French but it looks like you have some packages installed which depend on the old version of ghc. Remove the old ghc *and all the packages which depend on it* beofre installing 7.4.1. Peter. ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] [arch-general] (for Vesa and other Arch Devs on the list) Re: GHC 7.4.1 or HP 2011.4.0.0??
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 supposedly a real stable release) or just drop it and go to 7.4.1 asap (and probably face some breakage). What do you people think? I'm not going to suggest which action Arch should take; instead, I'm going to say what I am going to do. GHC 7.4 is still to new for my production systems, and I can't develop on a different version. So, if Arch moves to 7.4 right now, I'll need to download GHC 7.0 separately and use virthualenv. If there is enough space on the server then it might be good to copy [extra]/[community] packages to [haskell] and rename it to haskell70. Then continue with 7.4.x in (new) [haskell]. Peter. ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] [arch-general] (for Vesa and other Arch Devs on the list) Re: GHC 7.4.1 or HP 2011.4.0.0??
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 most of the work on GHC as found in [extra]. We've already discussed the question of whether we should keep HP in Arch. *I* think there was clear what the favoured route ahead was, but in the end it's the Arch Devs who decide. I don't like the current situation (outdated GHC and outdated HP), so a decision would be much welcome then the work on catching up can begin. Yeah, I noticed 7.4.1's release just now. The question of HP and Arch was left in a limbo the last time, I feel. The reason I started pondering about dropping HP earlier was that there seemed to be no progress on it with regards to 7.2. Then it was pointed out that 7.2 was sort of an unstable upstream release, so that was the reason for HP not going with it. 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 supposedly a real stable release) or just drop it and go to 7.4.1 asap (and probably face some breakage). What do you people think? Drop HP. The main reason is that the goals of HP are opposite the goals of ArchLinux. Yes, so far, users of this list clearly prefer to drop HP and move to 7.4. (6 responses). One would prefer to stay with 7.0. At least 2 people of this list are OK if the upgrade to 7.4 means dropping packages provided that at least ghc itself and cabal-install are available. Peter. ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] Move to 7.4.1
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 dependencies. Ach, ok, I did not know this rule. It seems like you are missing some packages from extra/community. I'm not saying you should add them all. If you do not add them all just let us know so that we know we cannot mix new haskell with the old stuff in extra/community. Oooo, how I miss ghcDependency group in extra/haskell so that I can just ban them all with one line :) Here is the list of all packages I noticed, the ones you miss have * at the end of the line: [...] I do not have all these installed nor I'm sure they are all libraries (where the ghc version matters). I got the list by scanning the output of pacman -Ss haskell |grep -E 'community/|extra/' I deliberately skipped all the free libraries, but having your list will make it a bit easier to gauge the impact of a move to 7.4.1, so it's much appreciated. I found out (on archlinux irc channel) that pacman does not store what repository a given package was installed from. So if we install a package which has the same name in both [extra] and [haskell] there is no easy way to find out what repository it was installed from. So if we happen to use different version of ghc in [haskell] and [extra] then we should add some tag to packages coming form [haskell] (e.g. add them to some group (like e.g. fromHaskellRepository). This is to allow an easier way to identify if some package is installed from different than [haskell] respository. Since such packages would cause breakage. Peter. ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] GHC 7.4.1 or HP 2011.4.0.0??
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 anything haskell related in [extra]/[community] Peter. On 02/03/2012 04:28 PM, Magnus Therning wrote: It's been out for a day now... this would be a good time to decide whether ArchLinux should be bold and move to a haskell-platform-free state, or trudge on with HP and the ache it causes. If we're moving to 7.4.1 there's a lot of work with getting ArchHaskell in shape for it, so the longer notice the better :) If we're to trudge on with HP then we really ought to move to 2011.4.0.0, which also means a new version of GHC and a lot of work on ArchHaskell, so the longer notice the better :) Please, please, please, can we move on this soon? I'm available to help out with [extra][community] packages if need be, updating PKGBUILDs, building, verifying other's changes, etc. /M ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] Upgrading to monad-control-0.3
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 we try this technique on one case first and the text package seems to be a good example. We could package the latest version of text and upgrade some package which depend on it. I'm sorry, but what technique are you referring to here? There was a proposal (in the far past) to add -hp to the name of all packages which belong to haskell platform (HP). The different name would allow to have a HP package version and one more package version which was supposed to be the very latest stable version. HP packages could depend only on other HP packages. Non-HP packages could depend on HP packages and also on non-HP packages. Not sure whether there is some fundamental problem why this cannot work or it was only forgotten. Looks to me like it could work. Peter. ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] Upgrading to monad-control-0.3
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 wire in the package docs into the system-wide index.html file. Not impossible to solve by any stretch of the imagination, but it just goes to show that it requires more thought and work than changing the name of a package in a PKGBUILD. What would the purpose of providing two versions of some packages be? Just to tick the has-haskell-platform box, or is there more value to it? What packages should be built using the -hp packages? If any, should we try to do anything to avoid the diamond dependency problem? The purpose is wider than this. Having a second version of a package (P, V1, V2), might enable to build a whole set of packages which requires PV1 while another set requires P≤V1. It would also risk causing diamond dependency problems among the packages in [haskell]. Well, I would say this is a problem for people who not upgrade enough when their dependencies bring two different versions of the same package in. It looks like people who want newer versions may rather maintain their own habs tree and probably forget anything haskell related from [extra]/[community]/[haskell]. At least, I plan to do so if I decide to move to ghc 7.4.1 sooner than archlinux community. I'm mostly behind, but I may get ahead of archlinux this one time. It would be a bit easier if we would have ghcDependency pacman group. Is there a way to ask pacman for all locally installed packages from a given source (i.e. one of [core]/[extra]/[community]/...)? E.g. a query like get all locally installed packages which arrived from [extra] or [community] and contain string haskell in name or description. Again, as long as we can push the authors to upgrade their packages this is fine but we cannot assume this will always be the case. True. Maintainers of haskell packages in [extra] and [community] do not seem to respond here. Google search indicates that there is not much haskell related discussion in arch-dev-public (I'm not a subscriber so I do not know for sure). Is there some other list where to get reaction from [extra]/[community] haskell maintainers? Providing packages (which are old in [extra]/[community]) also in [haskell] repository would mitigate this problem a bit. Users just need to ensure they have [haskell] before [extra]/[community] in pacman.conf. Or just put everything in [haskell]. Peter. ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] [arch-general] Haskell Support Was: Xmonad version?
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 moving *all* Haskell related packages to the Haskell Arch repo? All the Haskell Platform stuff, alex, happy, etc. I'm actually in favour of this or a creation of haskell (or ghc-dependency) pacman group for anything which depends on ghc. This would allow me to postpone any ghc related update easily. That facilitates management of what haskell related package versions are installed on my machine. I'm often out of sync too. But I'm mostly behind :) Peter. ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
[arch-haskell] haskell/haskell-glade 0.12.1-1 related problems
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 renames lead to conflicts and mixing packages from [community] and [haskell]. You probably will not have any problems if you do not use haskell-glade. I solved it by just by putting [haskell] before [community] in pacman.conf. Which probably is a good thing in general. Peter. ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
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
[arch-haskell] creation of haskell (or ghc) pacman group
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 something like IgnoreGroup = haskell in /etc/pacman.conf would postpone update of any ghc dependency. Normally non-haskell packages do not need this but since haskell has no backward binary compatibility it can be really useful sometimes. 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 repositories. Not sure how trying to install whole group would behave when it hits duplicates (like e.g. gtk2hs-gtk in community and haskell-gtk2hs-gtk in haskell (well, the one in haskell is more useful since it provides glade bindings too)). Any opinions? Can we do it next time there is some big update? Peter. ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] creation of haskell (or ghc) pacman group
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 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 something like IgnoreGroup = haskell in /etc/pacman.conf would postpone update of any ghc dependency. Normally non-haskell packages do not need this but since haskell has no backward binary compatibility it can be really useful sometimes. This situation is the reason for having specific versions in all dependencies. Is there a scenario where this wouldn't be enough? Yes, I like the fact we have specific versions in dependencies ... including pkgrel which is not there always. If I understand Simon Marlow correctly here http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/20002 then it is not sure that we will have the same ABI even when compiling exactly the same code (with the same compiler). My practical experience is that when one compiles the same code with the same compiler then the result is almost always the same. Anyway, pkgrel change can also mean different compiling options which definitely can change ABI. So I think pkgrel should be in all dependencies too. In fact pacman dependencies are dependencies between binary packages so they should be exact (contrary to source code dependencies in cabal). 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 ghc itself (mostly to get collored stderr which interleaves with stdout correctly and some other details). So it is not uncommon I want to postpone ghc update and that means all haskell related update. For such a case I want to ignore everything haskell related during updates. I could put in pacman.conf only IngnorePkg=ghc but then pacman will spit a ton of warnings about what other packages cannot be updated too and whether I'm aware of it. I happened to have sometimes my own changes to gtk2hs too. This would be another case when I would like to postpone any haskell related update. For this e.g. IgnoreGroup=haskell would be really useful. So who can use this group? AFAIK only people who sometimes have modified haskell packages on their systems or because of their own development want to postpone haskell updates a bit. Well and possibly people who want to install everything haskell related as I mentioned below. 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 repositories. Not sure how trying to install whole group would behave when it hits duplicates (like e.g. gtk2hs-gtk in community and haskell-gtk2hs-gtk in haskell (well, the one in haskell is more useful since it provides glade bindings too)). The goal is to have no such overlap. The problem is to recognise when such an overlap occurs. There are two situations that ArchHaskell needs to notice: 1. A Haskell package in core/extra/community is updated to a new version 2. A Haskell package is added to core/extra/community Is there some way of (semi-)automating this already? I do not have any tool for this. It would need to follow history in core/extra/community which (in the worst case) can be obtained from the web interface or the git of package definitions. I hope there is a better way since this will not catch binary recompiles. But maybe there is a different way around it. We could just ignore e.g. community (if we have all comunity packages in habs), name packages the same (or maybe putting the community package names in provides is enough?) and put [haskell] source before [community] source in pacman.conf. There should be coordination between extra/community/haskell package sources. Who maintains extra and community? They should know more. Anyway my call to create haskell (or ghc) group was not only for [haskell] but also for community/extra. Thanks for your arch-haskell work, Peter. ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] creation of haskell (or ghc) pacman group
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 repositories. Not sure how trying to install whole group would behave when it hits duplicates (like e.g. gtk2hs-gtk in community and haskell-gtk2hs-gtk in haskell (well, the one in haskell is more useful since it provides glade bindings too)). The goal is to have no such overlap. The problem is to recognise when such an overlap occurs. There are two situations that ArchHaskell needs to notice: 1. A Haskell package in core/extra/community is updated to a new version 2. A Haskell package is added to core/extra/community Is there some way of (semi-)automating this already? I do not have any tool for this. It would need to follow history in core/extra/community which (in the worst case) can be obtained from the web interface or the git of package definitions. I hope there is a better way since this will not catch binary recompiles. But maybe there is a different way around it. We could just ignore e.g. community (if we have all comunity packages in habs), name packages the same (or maybe putting the community package names in provides is enough?) and put [haskell] source before [community] source in pacman.conf. There should be coordination between extra/community/haskell package sources. Who maintains extra and community? They should know more. Anyway my call to create haskell (or ghc) group was not only for [haskell] but also for community/extra. If there is no other channel for comunication between maintainers of different repositories then the best may be to follow what did change in core/extra/comunity package database. For this the group may be useful too, but can be (better?) done based on dependency on ghc. Again this would be a pull approach. A push approach (get notified when something needs to be done) would be better. ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] creation of haskell (or ghc) pacman group
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 ghc itself (mostly to get collored stderr which interleaves with stdout correctly and some other details). So it is not uncommon I want to postpone ghc update and that means all haskell related update. For such a case I want to ignore everything haskell related during updates. I could put in pacman.conf only IngnorePkg=ghc but then pacman will spit a ton of warnings about what other packages cannot be updated too and whether I'm aware of it. I happened to have sometimes my own changes to gtk2hs too. This would be another case when I would like to postpone any haskell related update. For this e.g. IgnoreGroup=haskell would be really useful. So who can use this group? AFAIK only people who sometimes have modified haskell packages on their systems or because of their own development want to postpone haskell updates a bit. Well and possibly people who want to install everything haskell related as I mentioned below. That's a rather specialised use-case AFAIU. The ArchHaskell team only controls the [haskell] repo, so a group would only exist there. It's just as easy to install everything from a single repo using the output from `pacman -Sl haskell` then. For the use-case of installing all Haskell packages a group only be worthwhile if it existed in the official Arch repos as well. Correct, it does not make sense if the group is not defined in extra/community too. It might be that I'm the only one who would have a use for it. Maybe other users do not need to postpone updates. In such a case the proposal is of course dead on arrival :-D We will see whether anybody else responds. Especially the maintainers of haskell packages in extra/community. Thanks, Peter. ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
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
Re: [Haskell-cafe] Is there something better than tags?
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 tags file, GHCi can
generate them, and there are two tools for it, hasktags and
hothasktags. haskellmode currently uses GHCi to generate tags.
However, the limitation seems to be inherent in the tags format
itself. AFAICS there is no way to get a fully functional
go-to-definition with that format.
Last time I checked (about a year ago), the file scope was the smallest
scope supported by vim in tag files. So you are out of luck here. You
would need to extend vim (either by extending the tag file format or by
your own scripts handling this separately) and also your favourite tags
generator.
2. Retrieve type information for local defintions ('let', 'where',
'do'), and ideally also for sub expressions (like ':t filter (== 1)'.
I believe haskellmode uses GHCi to get the type information out, but
it is only able to get it for top-level definitions.
This is because ghci shows you this information only for the top level
symbols (the ones available in :browse). Ghci would need to be extended
first. Maybe it is there in GHC 7.0?
I hope I'm wrong somewhere and it could be done somehow more easily.
Peter.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is there something better than tags?
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 may want to check
out:
Mark : Highlight several words in different colors simultaneously.
http://www.vim.org/scripts/script.php?script_id=2666
I also like showmarks to highlight interesting places:
ShowMarks : Visually shows the location of marks.
http://www.vim.org/scripts/script.php?script_id=152
2. Retrieve type information for local defintions ('let', 'where',
'do'), and ideally also for sub expressions (like ':t filter (== 1)'.
I believe haskellmode uses GHCi to get the type information out, but
I only know about scion which comes closest to what you ask for.
(http://github.com/MarcWeber/scion-backend-vim)
Is this a correct summary?
* can load cabal components (all files of the component)
* can do type checking on buffer write
* can show type of any symbol under cursor if the file type checks
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [arch-haskell] Please do not delete packages from andromeda.kiwilight.com
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 that would make it easier to maintain such a kill list? How about keeping the last two versions all the time. No need to have a kill list. And the repository is fairly small. It should not be a problem if it takes two times the size. AFAICS repo-clean can't be used then; it always keeps only the very latest version of a package. Is there some other tool that is more configurable that can be used to automate such a policy? Well, if there is a local access then (since the naming policy is rather strict) a simple script over plain text directory listing can solve it. That is the reason I proposed it. Sorry, I do not know about the tools. ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] The ArchHaskell project needs your help
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 by any archlinux user. We should support all of HP and the most used packages. We should find the most used ones based some voting (publishing a way how archlinux users can ask for including a package to habs). Maybe we can just find them based on number of downloads from aur (if such a number if available). ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] Re: [extra] haskell-parallel
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 those packages that depend on FOO? Um, sorry, I was confused for a moment. I meant to say, of course, why can't we bump the $pkgrel of FOO whenever one of its dependencies is updated? Wouldn't that remedy this problem? It would provided users would do full system update from aur (or our archhaskell or whatever the name will be). The system update would recompile all dependencies when updating them. In general, the problem with haskell libraries is that any new version of a library is not binary backward compatible with the previous versions. AFAIK, there is no clear way to tell what is part of a binary interface of a library and what is not; so there is no easy way to tell whether a new version would be binary compatible or not. ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] Re: [extra] haskell-parallel
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 find. I'm fairly sure those packages need some further tweaking, but my gut feeling tells me it *is* possible to do this and end up with a system that is convenient to use. Good work, I'm all for the haskell-hp-* versions, this is a nice tradeoff between having many versions of each package and only one per package. This is really a sitution where we have to concile the strict update policy of the Platform and the latest released ArchLinux policy. +1 I would like to have the haskell platform versions separated and available in a binary form. Then one can install the latest versions (if needed) in parallel. Aur (or something like aur, i.e. source form only) is good enough for the latest versions. Just my opinion. ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] Re: [extra] haskell-parallel
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 is being built
it's
PKGFILE is updated so that it requires haskell-http 4000.0.9 exactly.
Then
an attempt to uninstall haskell-hp-http later would require an
uninstallation of haskell-pandoc too.
Can pacman be forced to do this? We would need something like a new
option
in PKGFILE which would have meaning: fix versions of dependencies of
these
packages exactly to the versions which are currently installed (installed
during building).
Just for reference, this is basically what the Debian policy on
Haskell packages is.
Good policy, if they can have it automated. If pacman (or I should rather
say makepkg) has such a option then great. If not we should check whether we
can add it there. We want the final exact version for dependency to be fixed
during build time. The PKGBUILD files need to contain the version ranges as
the cabal files.
If we cannot have this late version fix during makepkg then I say just let
it be as it is. If a user wants to go into the troubles with the source
packages then he/she should be able to take care about knowing and obeying
the haskell quirks.
Well maybe we could try to provide a small wraper over makepkg (something
like haskell-makepkg) which should be used for haskell source packages ...
if we cannot get this fixed in the makepkg itself.
A few weeks I hacked makepkg to add this very feature, I didn't took
time to test
it exhaustively nor to propose it to the authors.
As an attachment here is a diff against the makepkg found in pacman-3.4.1-1,
it adds the --freeze-deps flag that change the package versions to be exactly
the one on the build system.
I would be glad to see this feature used here, and then proposed to the authors
on the behalf of the Arch-Haskell team.
I did not test it, but it looks like it fixes all dependencies or none.
That is not what would be good for us. We want to fix only haskell
dependencies. We typically do not want to freeze dependencies on C libs
(e.g. in the case of gtk2hs we do not want freeze our dependency on gtk
exactly).
So something like a possibility to add a line like this to PKGBUILD file
would be fine:
FREEZEDEPS=('haskell-http' 'haskell-pandoc')
or better something like:
FREEZEDEPS_REGEX=('haskel-hp-.*' 'haskell-.*')
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell
[Haskell-cafe] Re: Haskell Weekly News: Issue 155 - October 20, 2010
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 because I don't want to get two copies of everything, but in part because I'm lazy. This is my case too. As for as the amount of messages, who cares. Get it through NNTP. You will download only the headers. Bodies will be downloaded only for messages you read. You can check only the threads you consider interesting. There is not much new threads. Mark newsgroup read is a quick operation. I do not think HWN should not be posted to haskell-cafe. If you decide so I do not really care but post a message to haskell-cafe list that you are switching HWN to haskell list only (so I can subscribe there too). Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: How to browse code written by others
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 handling of qualified imports. I believe hothasktags is meant to output multiple tags per target, one for each module referencing the target. I understand it that way too. But that would rely on scoped tags. By scoped tags, I understand tags valid only in the given scope (which is a file for the sake of qualified imports) which is the same as static tags which are supposed to be valid inside a file too ... but they are not as I found out from your example later :-( I discussed this with Luke before and I sumarrized what would need to be done to imporove ghci ctags to support qualified names better. Here is the post which explains it with an example: http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/73116 The problem with that example is that all occurrences of B.x point to b.hs and C.x always points to c.hs, so it doesn't test the scoping aspect of static tags. For instance, if you are in b.hs, and try ':tag C.x', you'll still be sent to c.hs, even though that isn't in scope (see also ':help tag-priority'). Yes, but this is the way vim works. Vim jumps even when given tag is not in scope. C.x is not in scope in b.hs (not as a static nor as a global symbol) so vim gives as static tag in a different file which matches exactly. Which looks like a reasonable feature for non-hierarchical symbols (maybe one is missing an include/import). Well, maybe not so much for jumps to tags but definitely usefull in :tselect. If we would use hierarchical names for tags then this is not so good and it works poorly (if I can say it works at all) for tag completions (^X^]). If I add a file d.hs that is the same as a.hs but with the qualifiers exchanged: module D () where import qualified B as C import qualified C as B localAct = do print B.x print C.x and try to add corresponding scoped tags by hand, then I don't see the scoping being taken into account (though my Vim is old 7.2 from August 2008). Depending on sort order of the tags file, either all B.x point to b.hs or all B.x point to c.hs. So, one either gets the wrong pointers in a.hs or in d.hs. You are correct. I thought this works well. Thanks for pointing it out. It does not work for me in my vim too, version 7.2 too. This looks to me like a vim bug. Though vim developers may not think so since it is not documented anyway. So it is really questionable how much do the qualified tags make sense in vim. I'm much less of a supporter of scoped tags now :-/ Looks like it is not worth the effort. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: How to browse code written by others
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 you better location information than current ghci ctags. I discussed this with Luke before and I sumarrized what would need to be done to imporove ghci ctags to support qualified names better. Here is the post which explains it with an example: http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/73116 With this addition, I believe, ghci tags would at least as good as hothasktags. That said I do not try hothasktags. Do hothasktags do analyzes deep enough that the information provided is always correct? I did not go to add this to ghci ctags since I barely ever use qualified names so it is a non-issue for me. Also propper support for scoped tags would include some vim macro which (on ^] key-press) tries to find a qualified name first and only after a failure it would try to find plain name without qualification. So if one wants to use it well he/she needs first select the name in visual mode and only then pres ^]. (Or one should use full ex commands for navigation like :tselect.) but in Vim 7.2 the help file still says http://vimdoc.sourceforge.net/htmldoc/tagsrch.html#tags-file-format The only other field currently recognized by Vim is file: (with an empty value). It is used for a static tag. If Vim somehow started supporting that extended file:scope format without updating its docs, that would be good to know (what version of Vim? where is this documented?). I did not find it documented but it looks like a filename can be used in place of scope. If provided then the validity of the tag is limited to the filename. Your suggested use-case for such a feature is interesting, but we're getting into an area where live calls to a scope resolution tool might make more sense. Och I would like to have a vim with full incremental parser for Haskell ... with things like AST being drawn in a pane, intellisense and completion on symbols but also on grammar/syntax, re-factoring options and all the goodies this could provide. It will not be a vim any more. Probably won't happen in my lifetime either but I can dream :) Peter. PS: Thanks for your vim support. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Announce: hothasktags
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 Derive/Derive.hs98; file:Cmd/ResponderSync.hs ... [ 20 more ] ... The vim tag documentation says these are static tags, and implies they are meant to apply to symbols only valid within the same file, but this is clearly not the case. Actually, the vim doc implies that only file: is defined, and doesn't talk about scoped tags so I'm not sure what is going on. Anyway, whenever I go to a tag I have to first step through a message that says 1 of 25 or so. There's one for each reference in the tags file, even though those are references in other files. Hmm odd, I don't get that behavior. Is that with the sorted annotation? What version of vim? I get the correct behavior (no additional selection is needed). My vim version is 7.2.385. I did not use sorted annotation but I doubt it has anything to do with it. What's going on? I even checked the current docs at vim.org and they don't mention a file:xyz form either. I think I saw it documented *somewhere*, but now that I look again I can't find it anywhere. Maybe it was in a dream. I hope a newer version of vim didn't remove the support or something... Even if it is not documented it makes sense. When file: is present then it limits the tag to the file which is the argument of file:. If file: does not have any argument then the argument defaults to the file in which the tag is defined. That would mean that exported symbols should be generated without file:, non-exported symbols should be generated with file: which does not have argument. In addition to this qualified symbols should be generated with the qualification and with file:fn where fn is the file name where the symbol is imported as qualified. Ghci's :ctags does not support qualified symbols :-/ Just to clarify it for myself. That would mean that the tags file should look like this: B.xb.hs/^x = 5 :: Int$/;vfile:a.hs B.xb.hs/^x = 5 :: Int$/;vfile:c.hs C.xc.hs/^x = B.x+1$/;vfile:a.hs localActa.hs/^localAct = do$/;vfile: xb.hs/^x = 5 :: Int$/;v xc.hs/^x = B.x+1$/;v ... for these files: === file a.hs === module A () where import qualified B as B import qualified C as C localAct = do print B.x print C.x === file b.hs === module B (x) where x = 5 :: Int === file c.hs === module C (x) where import qualified B as B x = B.x+1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Announce: hothasktags
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 generates a tag for each reference to a symbol: Derive.PitchDeriver Derive/Derive.hs98;file:Cmd/Cmd.hs Derive.PitchDeriver Derive/Derive.hs98;file:Cmd/Play.hs Derive.PitchDeriver Derive/Derive.hs98; file:Cmd/ResponderSync.hs ... [ 20 more ] ... The vim tag documentation says these are static tags, and implies they are meant to apply to symbols only valid within the same file, but this is clearly not the case. Actually, the vim doc implies that only file: is defined, and doesn't talk about scoped tags so I'm not sure what is going on. Anyway, whenever I go to a tag I have to first step through a message that says 1 of 25 or so. There's one for each reference in the tags file, even though those are references in other files. What's going on? I even checked the current docs at vim.org and they don't mention a file:xyz form either. As far as I know, there is nothing like file:xyz only file:. This is to support static tags which I would not call scoped tags because they know only one scope: the file scope. Between, ghci can generate tags file for you with static tags too in ghc 6.12.1. The ticket which discusses this feature and also discusses emacs support for static tags is here: http://hackage.haskell.org/trac/ghc/ticket/3434 Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskellers hate GUIs!!
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 Haskell again for developing such an application. Out of curiosity what language did you choose instead? Some algol-like language purporting to have cross-platform GUI support, widely used by others in our department. I think the name started with J. I did not enjoy the rewrite. The Haskell code was a lot nicer (and shorter). May you tell us how much (a percentage) shorter the Haskell code was? Maybe, you can even specify the project size better. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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
location of Haskell reports
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. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
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
[Haskell-cafe] Re: Documentation design
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 HsColoured source, every identifier would link to its definition or the haddockumentation of its definition. and so forth. It would be so much easier to generate and browse this in HTML, than to get an IDE working, and it would be so much more readable than a mere text-editor (even with syntax hilighting) and quicker clicking on hyperlinks than grepping for everything. You do not need to resort to grep for navigation of your source code from your text editor. At least not with vim. It has tags and stack of tags. Generate tags for your source code and use Ctrl-] to navigate to the definition (or Ctrl-W} to open the definition in preview window). Any jump to definition done with Ctrl-] is stored in the stack of tags. You can return to the previous position in the stack with Ctrl-T or return to the last next position with :tag. You can check how the tag stack looks like with :tags. This way you can navigate the stack of tags comfortably and the stack of tags can correspond to the lexical (creation) stack as it would exist during execution. The only problem with this is that it works so nicely only for me currently since I have a patch applied to ghci which makes ghci to include also the non-exported symbols to the tags file. I would like to add the patch to ghci but so far there is only small support for it. If you (or anybody else) would like it drop me a note or comment on the glasgow haskell users list: http://www.haskell.org/pipermail/glasgow-haskell-users/2009- June/017399.html The :ctags improvement patch gives you a substitute for intellisense in vim. I have :inoremap ^] ^[^W}a in .vimrc so when I start to type a function name I can finish it with some completion, and (while still being in the insert mode) I can get help for it to the preview window with Ctrl-]. The ideal haddockumentation-formatting for this purpose isn't quite obvious though. For example, sometimes you want to think about a module in terms of its abstract interface, but sometimes you want to figure out how it's implemented (without reverting completely to text based code browsing). Maybe a compromise of some sort would be good. so... Here's a proposal, for a new mode (`haddock --all-internal`?, to be invoked by `cabal haddock --internal` rather than --internal's current effect of ignore-all-exports) : Files with no explicit export list can be treated as-is anyway. For all files that have an explicit export list, generate the synopsis-of-exports near the top, as usual. But have the index link, generally, to where functions are originally defined (modulo being from a non-internally-documented separate package, where it should link to the appropriate place), and have the fuller documentation below be a compilation of the identifiers *defined* in this module. I like it but some notes to the new synopsis part: You mean the index link for a symbol should go to the haddock help page not to the HsColour source page. Right? I would like some annotations aligned to the right which would indicate whether the symbol is defined locally or it is reexported. There should be also an annotation or different font to indicate whether the symbol in synopsis is exported or not (in addition to nonexported symbols being is a separate section). This is so that one can easily see what part of the help is shown. Actually that would need some revision because the sections and subsections -- *, -- **, etc. defined in the export-list in the .hs, actually are displayed 1. above the table of contents, linking to places in 2. the full list of definitions. Which might be defined in the module in a different order than they're listed in the export list. Why not add the sections into the synopsis? In this case, instead of adding them to the main doc section. But hmm... in ordinary non-internal documentation, would it be nice to *additionally* have the sections marked in the synopsis (in addition to in the Contents and in the main docs section)? Not sure I understand this part well. I assume by main document part you mean the part with detailed description and source code links. I want the contents preserved with the added last section with name Nonexported symbols, or something named like that. Adding the section names to synopsis seems like good idea to me. In such a case it could be removed from the main doc part but I would rather keep it there. But I do not really mind either way. I assume the main doc part would contain only the symbols defined in the given module (not the re-exported ones). But the synopsis part would contain the names of re-exported symbols with links to the appropriate location in the main doc part of
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
[Haskell-cafe] Re: GHC 6.10.2 compatible problem.
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: http://permalink.gmane.org/gmane.comp.lang.haskell.gtk2hs/1497 Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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);
[Haskell-cafe] Re: How to catch error in array index when debugging
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 -fbreak-on-error flag. It made no difference - it still exited: interactive: Error in array index interactive: interrupted interactive: warning: too many hs_exit()s IIRC, this is because you are catching exceptions at some higher level where you actually find out that this kind of an exception is not handled and give up. If your application is Gtk2Hs then this library will do the catching you do not like in this case. Try to use -fbreak-on-exception instead of -fbreak-on-error. If you try this you may need to set break-on-exception late enough in the execution (use some breakpoint) so that you are not stopping at places which are ok (are correctly handled in an exception handler). In addition to other solutions mentioned here you can also setup conditional breakpoints in GHCi because GHCi breakpoints can be scripted. This is what I mostly use. Most of my debugging is done by writing GHCi debug scripts. Some ideas how to do it are here: http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/16270 It does not work well for interactive command line applications now, but it will work well for them when GHC 6.10.2 is out (the three most critical patches were merged). This alternative may have steep learning curve for such a simple thing but once mastered it works well. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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
[Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing
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 script are OK too I think, it’s technically not possible to let your Haskell application use another library version when you just have the .o and .hi files of the new library version. The .hi files typically contain code which is inlined by the application, so you have to be able to recompile the application. Or am I misunderstanding you? You may be right. I do not know. Compiler authors would know. But if the *only* problem is the inlined functions then it may not be that bad. Depends whether the depth of inlining has some limit and whether a change of code which is not inlined any more results in failure to link correctly too. The point is that inlining itself is not a problem simply the code which is inlined represents the interface and you need to provide an option to upgrade to a newer library with the same interface only. The same problem is with shared objects in C. The header files may contains macros (which are inlined) and you are not forced to provide source code of your app despite the fact that compilation inlines some code from the LGPL library used. Simply that code is part of the interface and changing it changes the interface. The acceptable size of inlined fuctions for a C code is about 10 lines. I did not read any info how it would be for Haskell. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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
[Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing
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 license for your library Of course there is a difference and a *significant* one. * A GPL library will force commercial users of the library to release their code under GPL. * 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 version of the LGPL library. The users of the commercial program maybe be forbidden to redistribute the application source code as well as modifying the application source code e.g. to avoid licensing restrictions imposed on them by the application seller (the LGPL library user). The commercial program owner does not even need to distribute the source code with the application by default. It just needs to provide an easy way to obtain the source code for all licensed customers (those who bought it) and let them prominently know (maybe in the about box of the application) where to get the source for the purpose of recompilation with a newer version of the LGPL libs. Providing source code without any other rights than to recompile with a newer version of a LGPL lib should not be such a big deal ... that is if the commercial application author's business model does not depend on some super secret process in the code or does not have something fishy stuff to hide :) The above does not represent a difference only when you assume that all your users are crooks which will redistribute everything without a bit of hesitation. Then it is up to you whether you wan to sue them :) Am I missing something? Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing
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 version of the LGPL library. Does this also mean one can't make closed source but *free* software that uses LGPL libs? Since all users can then potentially request the source code? E.g. suppose Google would have used LGPL libraries to implement parts of their search engine... I think so. If you acknowledge them as legitimate users and you distribute the free program then you must allow them to upgrade the LGPL library. With Haskell this may mean releasing the source code. I'm vary about this part though. *.o and *.hi may be enough since: * GHC is not LGPL but some kind of BSD * only the gmp and gtk2hs are LGPL * so you do not need to make sure ghc can be upgraded * you need to make sure gmp can be upgraded and gtk2hs can be upgraded but forcing users on the same version of ghc * requirement to allow upgrade is there only while the LGPL library does not change interface The above should allow to distribute only *.o and *.hi files. If user wants to to upgrade GMP or GTK2HS they can do it and recompile with the old version of GHC (the one for which you provided *.o and *.hi files. 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 script are OK too As for as Google: That is a different case. The GPL/LGPL limitations kick in *only* when you redistribute your program. Goolge is not redistributing their search engine! They only provide you a service over internet! That is very different. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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
[Haskell-cafe] Re: Hoogle and Network.Socket
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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
[Haskell-cafe] Re: Ann: Progress with IDE
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 on tests in configure.ac. I've never been able to reproduce it and when others have helped me investigate we did not find a solution or indeed a cause. If you'd like to do some digging it'd be much appreciated. I'm cc'ing the gtk2hs-users list just in case someone else has already diagnosed this. I had such (or very similar) problem when I was building gtk2hs on windows. The reasons of not finding the version numbers were problems with carriage return character (CRLF-LF). Unfortunately I cannot verify this for you since I switched to linux. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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
[Haskell-cafe] Re: GHCi debugger question
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 but it didn't work). It does not matter you do not have main function, just start debugging whatever function you have e.g. by: :step yourFunctionName functionArg ... Setting breakpoints works too without main. Actually, I'm aware only of one thing which does not work without main. It is :main command. But that command does not seem to do much, looks like it only sets program arguments and calls main. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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
[Haskell-cafe] Re: Arch Haskell News: Jan 11 2009
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
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
[Haskell-cafe] Re: Type question in instance of a class
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 inhabits all types? Well something like lazy C# might; i.e. every value has a _|_ (nontermination) and null (termination but undefined). For that matter, Control.Exception allows you to distinguish exceptional values from each other. OK, thanks for responses. I'm not sure I understand it well so I try to summarize: Control.Exception is an extension, also it probably cannot catch error :: String - a since the report says so: http://www.haskell.org/onlinereport/exps.html#sect3.1 So Haskell'98 has only one value of all types (the bottom). But Haskell with Control.Exception extension has more values of all types since they can be thrown and later caught and investigated at that place. Maybe the last sentence of section 2.1 (_|_ Bottom) of Haskell/Denotational semantics should be clarified better. http://en.wikibooks.org/wiki/Haskell/Denotational_semantics#.E2.8A.A5_Bottom So when trying to use Curry-Howard isomorphism for something in Haskell, one sould be pretty carefull what features of are being used. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type question in instance of a class
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 only value the function can return is bottom. Is there any type system which would have more than one value which inhabits all types? Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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
