From d9jh00502 at sneakemail.com Sun Oct 1 15:52:28 2006 From: d9jh00502 at sneakemail.com (Yang) Date: Sun Oct 1 14:58:24 2006 Subject: [Hat] Errors building hat 2.04 Message-ID: <29773-09107@sneakemail.com> hi all, after running configure on the latest release of hat, 'make' gives me: >>> /export/home/yang/tmp/pkg/hat-2.04/lib/ix86-Linux/config:11: *** missing separator. Stop. >>> that config file contains: >>> BUILDWITH=ghc BUILDOPTS="" INSTALLVER="2.04" INSTALLINFO="config: ix86-Linux/ by yang@harvard.csail.mit.edu on 1 Oct 2006" BUILDBASEDIR=/home/yang/tmp/pkg/hat-2.04/targets LIBCOMPAT="" EXE= CC=gcc GHCSYM= 604 TRUE=/bin/true GLIB=glib >>> i thought maybe the whitespace before 604 needed to be removed. doing that, 'make' continues fine, until... >>> ... ghc -package-name hat -fglasgow-exts -package base -package parsec -package mtl -fno-warn-overlapping-patterns -fno-warn-missing-methods -fno-warn-duplicate-exports -i/home/yang/tmp/pkg/hat-2.04/targets/ix86-Linux/obj/hatlib/ghc -I. -I/export/home/yang/tmp/pkg/hat-2.04/include '-#include "hat-c.h"' -cpp -c -o /home/yang/tmp/pkg/hat-2.04/targets/ix86-Linux/obj/hatlib/ghc/Hat/Hack.o Hat/Hack.hs mv Hat/Hack.hi /home/yang/tmp/pkg/hat-2.04/targets/ix86-Linux/obj/hatlib/ghc/Hat/Hack.hi ghc -package-name hat -fglasgow-exts -package base -package parsec -package mtl -fno-warn-overlapping-patterns -fno-warn-missing-methods -fno-warn-duplicate-exports -i/home/yang/tmp/pkg/hat-2.04/targets/ix86-Linux/obj/hatlib/ghc -I. -I/export/home/yang/tmp/pkg/hat-2.04/include '-#include "hat-c.h"' -cpp -c -o /home/yang/tmp/pkg/hat-2.04/targets/ix86-Linux/obj/hatlib/ghc/Hat/PreludeBuiltinTypes.o Hat/PreludeBuiltinTypes.hs mv Hat/PreludeBuiltinTypes.hi /home/yang/tmp/pkg/hat-2.04/targets/ix86-Linux/obj/hatlib/ghc/Hat/PreludeBuiltinTypes.hi /export/home/yang/tmp/pkg/hat-2.04/script/hat-trans -P. -I. -trusted -prelude -D__GLASGOW_HASKELL__= 604 PreludeBuiltin.hs Can't open 604 make[1]: *** [/home/yang/tmp/pkg/hat-2.04/targets/ix86-Linux/obj/hatlib/ghc/Hat/PreludeBuiltin.o] Error 1 make[1]: Leaving directory `/export/home/yang/tmp/pkg/hat-2.04/src/hatlib' make: *** [targets/ix86-Linux/hat-lib-ghc] Error 2 >>> how do i fix this build problem? i read this thread: http://www.haskell.org/pipermail/hat/2006-February/000256.html but that patch was already applied in the release i downloaded. thanks in advance for any help. From Malcolm.Wallace at cs.york.ac.uk Mon Oct 2 07:12:33 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Oct 2 06:24:25 2006 Subject: [Hat] Errors building hat 2.04 In-Reply-To: <29773-09107@sneakemail.com> References: <29773-09107@sneakemail.com> Message-ID: <20061002121233.24ad77d2.Malcolm.Wallace@cs.york.ac.uk> "Yang" wrote: > hi all, after running configure on the latest release of hat, 'make' > gives me: > > >>> missing separator. Stop. Yes, this seems to be the same error as in the mail thread you quoted. > GHCSYM= > > 604 > > i thought maybe the whitespace before 604 needed to be removed. doing > that, 'make' continues fine, until... > > hat-trans ... -D__GLASGOW_HASKELL__= 604 Ensure that there is no whitespace at all, i.e. GHCSYM=604 If the patch to the 'configure' script did not work, then you may also need to make a similar change in the file targets/`harch`/ghcsym Regards, Malcolm From tatd2 at kent.ac.uk Mon Oct 2 07:52:29 2006 From: tatd2 at kent.ac.uk (Thomas Davie) Date: Mon Oct 2 08:10:01 2006 Subject: [Hat] Errors building hat 2.04 In-Reply-To: <20061002121233.24ad77d2.Malcolm.Wallace@cs.york.ac.uk> References: <29773-09107@sneakemail.com> <20061002121233.24ad77d2.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <1057CB05-708A-43F4-9B21-069979006A47@kent.ac.uk> Malcolm, This seems to be a recurring problem. Do we have a list of what ghc produces on each platform? If we had that, I guess we could find a regexp that works on all known systems. Bob On 2 Oct 2006, at 12:12, Malcolm Wallace wrote: > "Yang" wrote: > >> hi all, after running configure on the latest release of hat, 'make' >> gives me: >> >>>>> missing separator. Stop. > > Yes, this seems to be the same error as in the mail thread you quoted. > >> GHCSYM= >> >> 604 >> >> i thought maybe the whitespace before 604 needed to be removed. doing >> that, 'make' continues fine, until... >> >> hat-trans ... -D__GLASGOW_HASKELL__= 604 > > Ensure that there is no whitespace at all, i.e. > GHCSYM=604 > > If the patch to the 'configure' script did not work, then you may also > need to make a similar change in the file targets/`harch`/ghcsym > > Regards, > Malcolm > _______________________________________________ > Hat mailing list > Hat@haskell.org > http://www.haskell.org/mailman/listinfo/hat From Malcolm.Wallace at cs.york.ac.uk Mon Oct 2 09:47:17 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Oct 2 08:55:39 2006 Subject: [Hat] Errors building hat 2.04 In-Reply-To: <1057CB05-708A-43F4-9B21-069979006A47@kent.ac.uk> References: <29773-09107@sneakemail.com> <20061002121233.24ad77d2.Malcolm.Wallace@cs.york.ac.uk> <1057CB05-708A-43F4-9B21-069979006A47@kent.ac.uk> Message-ID: <20061002144717.269975a5.Malcolm.Wallace@cs.york.ac.uk> Thomas Davie wrote: > This seems to be a recurring problem. Do we have a list of what > ghc produces on each platform? If we had that, I guess we could find > a regexp that works on all known systems. It's not so much ghc, as _gcc_, because the extra whitespace/#pragmas are inserted by the C preprocessor. I believe the regexp currently in CVS is correct (not "^#" and not "^$"), but perhaps an alternative which actually searches for numbers on a line of their own (e.g. "^[0-9]*$") might be better. Regards, Malcolm From d9jh00502 at sneakemail.com Tue Oct 3 21:26:17 2006 From: d9jh00502 at sneakemail.com (Yang) Date: Tue Oct 3 20:32:05 2006 Subject: [Hat] Errors building hat 2.04 In-Reply-To: <20061002144717.269975a5.Malcolm.Wallace@cs.york.ac.uk> References: <29773-09107@sneakemail.com> <20061002121233.24ad77d2.Malcolm.Wallace@cs.york.ac.uk> <1057CB05-708A-43F4-9B21-069979006A47@kent.ac.uk> <20061002144717.269975a5.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <32212-01586@sneakemail.com> to be honest, as much as i'd love contributing, i often don't have the time to go in and debug software that i'm trying/evaluating. (as i said, the patch was already applied in the tarball i downloaded.) such pursuits almost always turn into much deeper time sinks than how they're initially presented to me. when will the next version be available that fixes this? i'll wait for that. thanks. On 10/2/06, Malcolm Wallace Malcolm.Wallace-at-cs.york.ac.uk |hat| <...> wrote: > Thomas Davie wrote: > > > This seems to be a recurring problem. Do we have a list of what > > ghc produces on each platform? If we had that, I guess we could find > > a regexp that works on all known systems. > > It's not so much ghc, as _gcc_, because the extra whitespace/#pragmas > are inserted by the C preprocessor. I believe the regexp currently in > CVS is correct (not "^#" and not "^$"), but perhaps an alternative which > actually searches for numbers on a line of their own (e.g. "^[0-9]*$") > might be better. > > Regards, > Malcolm > _______________________________________________ > Hat mailing list > Hat@haskell.org > http://www.haskell.org/mailman/listinfo/hat > From mcdermott.michaelj at gmail.com Fri Oct 6 16:36:05 2006 From: mcdermott.michaelj at gmail.com (Michael McDermott) Date: Sat Oct 7 05:01:30 2006 Subject: [Hat] Re: Packages & hat-trans output Message-ID: <2844ee050610061336u3a222a44y9b9f33ce882495cb@mail.gmail.com> I have been working on a Gentoo ebuild for Hat and ran across a few issues. First, it is the cabal package (not hat-package.conf) that needs to be piped to ghc-pgk register - to register the package (which is easy enough to work around). Futhermore, the file is somewhat incomplete. For example, if the import-dirs field is not added, then GHC is unable to find Hat's classes. Secondly, once I was able to get past that issue, the output from hat-trans fails to compile. Here is a sample of the output: ghc -package hat -o Insert Hat/Insert.o Hat/Insert.o: In function `r2iZ_info': : undefined reference to `HatziHat_mkModule_closure' Hat/Insert.o: In function `HatziInsert_asort_info': : undefined reference to `HatziHat_mkVariable_closure' Hat/Insert.o: In function `HatziInsert_ainsert_info': .... I am presuming that HatziInsert_ainsert_info, etc. are functions in libraries or headers that should be linked to the program, but, if so, where are they? Since I don't know, it has been hard to add this to the Cabal package or GHC's config files. The output was virtually the same for both programs I tried to run hat on. The first was Insert.hs, the example on the tutorial page and the second was a basic hello world: module Main where main = do putStrLn "Hello, world" Both programs appear to work 100% when run through GHC vanilla. If you could give me some insight into these errors, it would be greatly appreciated. Sincerely, Michael McDermott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/hat/attachments/20061006/f0f65438/attachment.htm From Malcolm.Wallace at cs.york.ac.uk Sat Oct 7 06:08:14 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Sat Oct 7 05:14:12 2006 Subject: [Hat] Re: Packages & hat-trans output In-Reply-To: <2844ee050610061336u3a222a44y9b9f33ce882495cb@mail.gmail.com> References: <2844ee050610061336u3a222a44y9b9f33ce882495cb@mail.gmail.com> Message-ID: <20061007110814.716003ab.Malcolm.Wallace@cs.york.ac.uk> "Michael McDermott" writes: > I have been working on a Gentoo ebuild for Hat and ran across a few issues. > First, it is the cabal package (not hat-package.conf) that needs to be piped > to ghc-pgk register - to register the package (which is easy enough to work > around). Futhermore, the file is somewhat incomplete. For example, if the > import-dirs field is not added, then GHC is unable to find Hat's classes. Thanks for these reports. We will look into fixing those. > ghc -package hat -o Insert Hat/Insert.o > Hat/Insert.o: In function `r2iZ_info': > : undefined reference to `HatziHat_mkModule_closure' > Hat/Insert.o: In function `HatziInsert_asort_info': > : undefined reference to `HatziHat_mkVariable_closure' > Hat/Insert.o: In function `HatziInsert_ainsert_info': > .... > > I am presuming that HatziInsert_ainsert_info, etc. are functions in > libraries or headers that should be linked to the program, but, if so, where > are they? "HatziInsert_ainsert_info" is the (traced) function Insert.ainsert in the program you are trying to compile. The error is that this function uses (by reference) the functions Hat.Hat.mkModule and Hat.Hat.mkVariable. Both of those are defined in the hat library Hat.Hat, and should be available to the compiler by the "-package hat" flag. I don't know why this is failing. What version of ghc? Were there any linking errors when the hat package was built? Regards, Malcolm From ndmitchell at gmail.com Sat Oct 7 10:06:59 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Oct 7 09:12:35 2006 Subject: [Hat] Proposal, Heirarchical module structure for tools Message-ID: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> Hi, The current hattools directory has 38 Haskell files in it, and 34 .h/.c files. It would be nice if these were split so it was easy to determine the files in one program, and what is a tool versus what is a library. The following is a draft proposal: Hat - global module in which all Hat stuff resides (this clashes with the hat-trans output, does this matter?) Hat.Lib - directory for libraries, which export a nice API for using in the tools - for example HatCover as Hat.Lib.Cover. Hat.Tool - directory for the tools, for example HatCoverText, as Hat.Tool.Cover Hat.Common - Common functions which are unrelated to Hat tracing, but are used by the Tools, for example HighlightStyle as Hat.Common.HighlightStyle Within Hat.Tool, I would expect some simpler (one module) tools to be Hat.Tool.ToolName, but more complex tools would be Hat.Tool.ToolName.Modules, with a single Hat.Tool.ToolName module which imports the others. To keep the structure of having a Main module at the root which is the tool for each given tool, for each tool a file would be created: -- file HatCover.hs import Hat.Tool.Cover This file gives an easy module Main to be located for each tool. The advantages of this scheme: * Easier to differentiate between libraries and tools * Easier to find a particular tool and all its given code * Clearer separation of Hat code vs general Haskell Thanks Neil From mcdermott.michaelj at gmail.com Sat Oct 7 20:18:18 2006 From: mcdermott.michaelj at gmail.com (Michael McDermott) Date: Sat Oct 7 19:23:54 2006 Subject: [Hat] Re: Packages & hat-trans output Message-ID: <2844ee050610071718r55e6bd0ds69c56d9daf8f4175@mail.gmail.com> What version of ghc? Were there any linking errors when the hat package was built? GHC 6.4.2 and no linking errors that I know of. GHC gave a few compilation warnings, but that is all. The output from ghc-pkg describe hat shows the following: exposed: True exposed-modules: [list of hat modules...] hidden-modules: import-dirs: /usr/lib/ghc-6.4.2/imports/hat library-dirs: /usr/lib/ghc-6.4.2 No other directory settings are set. Is this correct? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/hat/attachments/20061007/2403c226/attachment.htm From ndmitchell at gmail.com Sun Oct 8 12:18:15 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Oct 8 11:23:48 2006 Subject: [Hat] Broken hat mirror Message-ID: <404396ef0610080918j4aea65e5x2319b4173fb2e67a@mail.gmail.com> Hi, I got told about this site by a person: http://mathematik.htwm.de/cgi-bin/dwww?type=file&location=/usr/share/doc/hat/html/index.html They found this with the google search: http://www.google.com/search?q=hat-stack%20haskell They were deeply confused, because all the documentation links were broken, so they didn't have a clue how to generate a .hat file. It would be best if this mirror site was removed, turned into a redirect to the main Haskell site, or fixed to be a complete mirror. Thanks Neil From katerinab at gmail.com Sun Oct 8 12:49:07 2006 From: katerinab at gmail.com (Katerina Barone-Adesi) Date: Sun Oct 8 11:54:37 2006 Subject: [Hat] Using Hat with HUnit Message-ID: I'm trying to run hat on some unit tests. They use HUnit-1.0, which I have under the tests directory, in tests/HUnit-1.0/; I've been interpreting the tests using runhaskell. When I run hmake -package parsec -i.. -iHUnit-1.0 RunTests; ./RunTests, everything works exactly as it does when I'm interpreting. When I add a -hat to the options, I get the following error: hat-trans -i.. -iHUnit-1.0 HUnit-1.0/HUnitLang.lhs Wrote Hat/HUnit-1.0/HUnitLang.hs /usr/bin/ghc -package parsec -i.. -iHUnit-1.0 -c -package hat -o HUnit-1.0/Hat/HUnitLang.o HUnit-1.0/Hat/HUnitLang.hs ghc-6.4.2: error: directory portion of "HUnit-1.0/Hat/HUnitLang.o" does not exist (used with "-o" option.) If I manually create HUnit-1.0/Hat: hat-trans -i.. -iHUnit-1.0 HUnit-1.0/HUnitLang.lhs Wrote Hat/HUnit-1.0/HUnitLang.hs /usr/bin/ghc -package parsec -i.. -iHUnit-1.0 -c -package hat -o HUnit-1.0/Hat/HUnitLang.o HUnit-1.0/Hat/HUnitLang.hs ghc-6.4.2: file `HUnit-1.0/Hat/HUnitLang.hs' does not exist If I switch into the HUnit-1.0 directory and run "hmake -hat HUnitLang.lhs": hmake -hat HUnitLang.lhs hat-trans HUnitLang.lhs Wrote Hat/HUnitLang.hs /usr/bin/ghc -c -package hat -o Hat/HUnitLang.o Hat/HUnitLang.hs Hat/HUnitLang.hs:52:38: Could not find module `Hat.PreludeBuiltin': use -v to see a list of the files searched for In the fourth argument of `Hat.Hat.uapp1', namely `aioError' In the definition of `hassertFailure': hassertFailure fmsg p = Hat.Hat.uapp1 p59v23v59v60 p59v23v59v29 p aioError hioError (Hat.Hat.uapp1 p59v32v59v60 p59v32v59v40 p auserError huserError (Hat.Hat.uapp2 p59v43v59v60 p59v55v59v56 p (+++) (*++) (ghunitPrefix p59v43v59v53 p) fmsg)) I'd like to be able to trace my code; I'm indifferent to whether or not I trace the code within HUnit. Any suggestions on how I can do this? Katerina Barone-Adesi From tatd2 at kent.ac.uk Mon Oct 9 07:20:15 2006 From: tatd2 at kent.ac.uk (T.A.T.Davie) Date: Mon Oct 9 06:25:50 2006 Subject: [Hat] Proposal, Heirarchical module structure for tools In-Reply-To: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> References: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> Message-ID: <20061009112015.GA26559@myrtle.kent.ac.uk> Interesting. Okay, so my question then is, where would something like EDT.hs or SExp.hs go? They aren't libraries for one tool, they aren't commonly used and they aren't one tool. Bob From ndmitchell at gmail.com Mon Oct 9 07:26:34 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Oct 9 06:32:06 2006 Subject: [Hat] Proposal, Heirarchical module structure for tools In-Reply-To: <20061009112015.GA26559@myrtle.kent.ac.uk> References: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> <20061009112015.GA26559@myrtle.kent.ac.uk> Message-ID: <404396ef0610090426h45d439bfr240c78c527dfdf49@mail.gmail.com> Hi, > Interesting. Okay, so my question then is, where would something like EDT.hs or SExp.hs go? They aren't libraries for one tool, they aren't commonly used and they aren't one tool. Hat.Lib.SExp and Hat.Lib.EDT, they are libraries - things in Hat.Lib don't have to be for one tool, they just have to be libraries. Part of the hope of this exercise would be that the one tool - one library model goes away slowly, as the tools start to share more and more library code. Thanks Neil From tom.davie at gmail.com Tue Oct 10 05:01:11 2006 From: tom.davie at gmail.com (Thomas Davie) Date: Tue Oct 10 04:13:39 2006 Subject: [Hat] CVS is broken Message-ID: Having just done a CVS update, I got the following error compiling hat: ../compiler98/OsOnly.hs:46:28: Not in scope: `isPrefixOf' make[1]: *** [/Users/tatd2/Documents/Work/hat/lib/ix86-Darwin8/hat- trans] Error 1 I don't really want to fix it and check in, because some of my copy is equally broken at the moment. Would love it if someone fixed it. Thanks Bob From Malcolm.Wallace at cs.york.ac.uk Tue Oct 10 10:45:29 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Oct 10 09:54:22 2006 Subject: [Hat] Move from CVS to darcs. Message-ID: <20061010154529.0287ad24.Malcolm.Wallace@cs.york.ac.uk> Dear Hat developers, I have now successfully converted the entire repository for Hat from CVS to darcs. For those with commit access, it is now at darcs get --partial darcs.haskell.org:/home/darcs/hat and for those without commit access, it is available read-only at darcs get --partial http:/darcs.haskell.org/hat The first thing to do after downloading a copy is sh start to make various scripts executable, then ./configure make as normal. For those who still have uncommitted changes in CVS, don't panic. You can continue to commit to CVS for a short time, several weeks perhaps, and I will copy the patches across to the main darcs repo. Regards, Malcolm P.S. For those of you on the cvs-nhc98 mailing list, I apologise again for the spam of 1396 old commit messages ever since the history of the world, but I believe the problem is now fixed. From ndmitchell at gmail.com Tue Oct 10 10:52:47 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Oct 10 09:58:14 2006 Subject: [Hat] Move from CVS to darcs. In-Reply-To: <20061010154529.0287ad24.Malcolm.Wallace@cs.york.ac.uk> References: <20061010154529.0287ad24.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <404396ef0610100752s6744d9f3hcc5a362f9073649b@mail.gmail.com> Hi > to darcs. For those with commit access, it is now at > darcs get --partial darcs.haskell.org:/home/darcs/hat > and for those without commit access, it is available read-only at > darcs get --partial http:/darcs.haskell.org/hat darcs get --partial http://darcs.haskell.org/hat I would recommend everyone uses the second link (as repeated above, noting the missing /), since it will go much much faster. If you do need to push then "darcs push --no-set-default darcs.haskell.org:/home/darcs/hat" A blank darcs pull over SSH for me takes roughly 1 minute Thanks Neil From Malcolm.Wallace at cs.york.ac.uk Tue Oct 10 10:52:09 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Oct 10 09:59:20 2006 Subject: [Hat] CVS is broken In-Reply-To: References: Message-ID: <20061010155209.375f33cc.Malcolm.Wallace@cs.york.ac.uk> Thomas Davie wrote: > Having just done a CVS update, I got the following error compiling > hat: > > ../compiler98/OsOnly.hs:46:28: Not in scope: `isPrefixOf' OK, I have backed out this change in the new darcs repo. > I don't really want to fix it and check in, because some of my copy > is equally broken at the moment. Would love it if someone fixed it. It is easy to fix yourself, if you need to stay with CVS. Just delete the entire definition of 'findRootDir' in src/compiler98/OsOnly.hs. Regards, Malcolm From Malcolm.Wallace at cs.york.ac.uk Tue Oct 10 11:05:47 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Oct 10 10:14:37 2006 Subject: [Hat] Proposal, Heirarchical module structure for tools In-Reply-To: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> References: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> Message-ID: <20061010160547.004c7a72.Malcolm.Wallace@cs.york.ac.uk> "Neil Mitchell" wrote: > The current hattools directory has 38 Haskell files in it, and 34 > .h/.c files. It would be nice if these were split so it was easy to > determine the files in one program, and what is a tool versus what is > a library. In principle, I agree that using the hierarchical namespace to separate concerns would be nice. > Hat - global module in which all Hat stuff resides > (this clashes with the hat-trans output, does this matter?) Yes, it matters a great deal. We have reserved the 'Hat' top-level namespace for the exclusive use of trace-transformed programs. No-one should ever use that namespace intentionally for anything else. My suggestion is to reserve Tracing.Hat as the root of a hierarchy for Hat-related trace-viewing (or transforming?) libraries. > Hat.Lib - directory for libraries, which export a nice API for using > in the tools - for example HatCover as Hat.Lib.Cover. > > Hat.Tool - directory for the tools, for example HatCoverText, as > Hat.Tool.Cover I don't like this division much. How should I decide whether I'm looking for a Lib or a Tool, or a Common? In principle, everything can be treated more or less as a library. Lib/Tool/Common is a meta-category, not a name chosen to reflect the underlying functionality. My suggestion would be just to drop that part. So, e.g. Tracing.Hat.Observe Tracing.Hat.Trail Tracing.Hat.SExp Tracing.Hat.HighlightStyle Then, other modules used exclusively by a single "tool" (or style of interaction I suppose) would be placed directly under the relevant category, e.g. Tracing.Hat.Observe.FileAccess Tracing.Hat.Observe.TextUI Tracing.Hat.Observe.GUI Tracing.Hat.Trail.Navigation Regards, Malcolm From ndmitchell at gmail.com Tue Oct 10 11:32:43 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Oct 10 10:38:10 2006 Subject: [Hat] Proposal, Heirarchical module structure for tools In-Reply-To: <20061010160547.004c7a72.Malcolm.Wallace@cs.york.ac.uk> References: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> <20061010160547.004c7a72.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <404396ef0610100832y33f1052cq46fdee632854f3f@mail.gmail.com> Hi > Yes, it matters a great deal. We have reserved the 'Hat' top-level > namespace for the exclusive use of trace-transformed programs. No-one > should ever use that namespace intentionally for anything else. Fair enough, seems reasonable. Although then I wonder if we need the "Hat" part, just Tracing.Observe should be enough, since its just as unique, and its in the Hat repo so makes it clear enough. > My suggestion would be just to drop that part. So, e.g. > > Tracing.Hat.Observe > Tracing.Hat.Trail > Tracing.Hat.SExp > Tracing.Hat.HighlightStyle It would be nice to indicate in some way "this exports some gunk that happened to be useful", and "this exports a nice clean API that I expect to be used" - although I guess that can go in the documentation. I still think its nice to have a some sort of classification as to what libaries are "general Haskell libraries" and which are "Hat Tracing stuff" - for example Tracing.Hat.HighlightStyle isn't really anything to do with Hat or Tracing. However, what you propose is close enough that I'm not overly fussed and would happily accept it. Thanks Neil From tom.davie at gmail.com Tue Oct 10 11:42:56 2006 From: tom.davie at gmail.com (Thomas Davie) Date: Tue Oct 10 10:55:18 2006 Subject: [Hat] CVS is broken In-Reply-To: <20061010155209.375f33cc.Malcolm.Wallace@cs.york.ac.uk> References: <20061010155209.375f33cc.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <9DDF3F93-AA2A-4DA1-A95E-52F1B0F6CD72@gmail.com> Yeh, I fixed it locally - I just wanted someone to fix the CVS version, because if I do as you say and then check in, I get two logical patches included in one single commit. I guess it's all the more reason to make the darcs move -- I could just fix it and record two seperate patches. Bob On 10 Oct 2006, at 15:52, Malcolm Wallace wrote: > Thomas Davie wrote: > >> Having just done a CVS update, I got the following error compiling >> hat: >> >> ../compiler98/OsOnly.hs:46:28: Not in scope: `isPrefixOf' > > OK, I have backed out this change in the new darcs repo. > >> I don't really want to fix it and check in, because some of my copy >> is equally broken at the moment. Would love it if someone fixed it. > > It is easy to fix yourself, if you need to stay with CVS. Just delete > the entire definition of 'findRootDir' in src/compiler98/OsOnly.hs. > > Regards, > Malcolm > _______________________________________________ > Hat mailing list > Hat@haskell.org > http://www.haskell.org/mailman/listinfo/hat From tom.davie at gmail.com Tue Oct 10 11:46:02 2006 From: tom.davie at gmail.com (Thomas Davie) Date: Tue Oct 10 10:58:23 2006 Subject: [Hat] Proposal, Heirarchical module structure for tools In-Reply-To: <404396ef0610100832y33f1052cq46fdee632854f3f@mail.gmail.com> References: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> <20061010160547.004c7a72.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610100832y33f1052cq46fdee632854f3f@mail.gmail.com> Message-ID: <389E47F1-412A-45F0-875F-32FEB4D81795@gmail.com> I have a feeling I'm about to get shouted down because Hat is not just a debugger... But... The Debug. namespace already exists, why not Debug.Hat? Directly in response to Neil - we do need Hat in the structure whichever we choose - what if there's another Debugging/Tracing tool with an Observe module? Bob On 10 Oct 2006, at 16:32, Neil Mitchell wrote: > Hi > >> Yes, it matters a great deal. We have reserved the 'Hat' top-level >> namespace for the exclusive use of trace-transformed programs. No- >> one >> should ever use that namespace intentionally for anything else. > > Fair enough, seems reasonable. Although then I wonder if we need the > "Hat" part, just Tracing.Observe should be enough, since its just as > unique, and its in the Hat repo so makes it clear enough. > >> My suggestion would be just to drop that part. So, e.g. >> >> Tracing.Hat.Observe >> Tracing.Hat.Trail >> Tracing.Hat.SExp >> Tracing.Hat.HighlightStyle From colin at cs.york.ac.uk Wed Oct 11 04:06:57 2006 From: colin at cs.york.ac.uk (Colin Runciman) Date: Wed Oct 11 03:14:22 2006 Subject: [Hat] Proposal, Heirarchical module structure for tools In-Reply-To: <389E47F1-412A-45F0-875F-32FEB4D81795@gmail.com> References: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> <20061010160547.004c7a72.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610100832y33f1052cq46fdee632854f3f@mail.gmail.com> <389E47F1-412A-45F0-875F-32FEB4D81795@gmail.com> Message-ID: <452CA621.3030601@cs.york.ac.uk> Bob, > I have a feeling I'm about to get shouted down because Hat is not > just a debugger... But... > > The Debug. namespace already exists, why not Debug.Hat? Shout! Shout! Shout! :-) Tracing -- or Trace if you prefer. Please. Colin R From ndmitchell at gmail.com Wed Oct 11 04:13:51 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Oct 11 03:19:16 2006 Subject: [Hat] Proposal, Heirarchical module structure for tools In-Reply-To: <20061010160547.004c7a72.Malcolm.Wallace@cs.york.ac.uk> References: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> <20061010160547.004c7a72.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <404396ef0610110113p154b538bn237a05ea05649a81@mail.gmail.com> Hi, > > Hat.Lib - directory for libraries, which export a nice API for using > > in the tools - for example HatCover as Hat.Lib.Cover. > > > > Hat.Tool - directory for the tools, for example HatCoverText, as > > Hat.Tool.Cover > > I don't like this division much. How should I decide whether I'm > looking for a Lib or a Tool, or a Common? In principle, everything can > be treated more or less as a library. Lib/Tool/Common is a > meta-category, not a name chosen to reflect the underlying > functionality. So where would the library half of HatCover vs the program half of HatCover go? Thanks Neil PS. Debug.Trace is already a module, perhaps we could put things under that ;) From Malcolm.Wallace at cs.york.ac.uk Wed Oct 11 06:27:18 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Oct 11 05:43:25 2006 Subject: [Hat] Proposal, Heirarchical module structure for tools In-Reply-To: <404396ef0610110113p154b538bn237a05ea05649a81@mail.gmail.com> References: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> <20061010160547.004c7a72.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110113p154b538bn237a05ea05649a81@mail.gmail.com> Message-ID: <20061011112718.3250bd3b.Malcolm.Wallace@cs.york.ac.uk> "Neil Mitchell" wrote: > > I don't like this division much. How should I decide whether I'm > > looking for a Lib or a Tool, or a Common? > > So where would the library half of HatCover vs the program half of > HatCover go? HatCover -> Tracing.Hat.Coverage HatCoverText -> Tracing.Hat.Coverage.Textual hypothetical -> Tracing.Hat.Coverage.HTML hypothetical -> Tracing.Hat.Coverage.Gtk Regards, Malcolm From ndmitchell at gmail.com Wed Oct 11 06:44:12 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Oct 11 05:49:36 2006 Subject: [Hat] Proposal, Heirarchical module structure for tools In-Reply-To: <20061011112718.3250bd3b.Malcolm.Wallace@cs.york.ac.uk> References: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> <20061010160547.004c7a72.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110113p154b538bn237a05ea05649a81@mail.gmail.com> <20061011112718.3250bd3b.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <404396ef0610110344s37daeed7p36b4c81c42455f77@mail.gmail.com> > > So where would the library half of HatCover vs the program half of > > HatCover go? > > HatCover -> Tracing.Hat.Coverage > HatCoverText -> Tracing.Hat.Coverage.Textual > hypothetical -> Tracing.Hat.Coverage.HTML > hypothetical -> Tracing.Hat.Coverage.Gtk Hmm, I don't like that much. I'm not entirely sure about this whole calling console programs "Textual", they aren't, they are Console programs (I object to HatCoverText as well). It also obscures the fact that HTML should be an API (so the Console and Gui can use it), but Gtk will probably be a viewer. Thanks Neil From Malcolm.Wallace at cs.york.ac.uk Wed Oct 11 07:06:58 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Oct 11 06:41:17 2006 Subject: [Hat] Proposal, Hierarchical module structure for tools In-Reply-To: <404396ef0610110344s37daeed7p36b4c81c42455f77@mail.gmail.com> References: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> <20061010160547.004c7a72.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110113p154b538bn237a05ea05649a81@mail.gmail.com> <20061011112718.3250bd3b.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110344s37daeed7p36b4c81c42455f77@mail.gmail.com> Message-ID: <20061011120658.39f3d966.Malcolm.Wallace@cs.york.ac.uk> "Neil Mitchell" wrote: > > > So where would the library half of HatCover vs the program half of > > > HatCover go? > > > > HatCover -> Tracing.Hat.Coverage > > HatCoverText -> Tracing.Hat.Coverage.Textual > > hypothetical -> Tracing.Hat.Coverage.HTML > > hypothetical -> Tracing.Hat.Coverage.Gtk > > Hmm, I don't like that much. I'm not entirely sure about this whole > calling console programs "Textual", they aren't, they are Console > programs (I object to HatCoverText as well). Well, "console" is the wrong word as well. On a unix machine, there is only one console, but there may be many textual terminals or terminal emulators. I intended the word "textual" to indicate an API that produces Strings, not something that interacts per se with a terminal. However, I now realise that your objection is probably that the text strings produced are not pure - they have ANSI terminal colour codes. Fair enough. HatCoverText -> Tracing.Hat.Coverage.ANSIterm > It also obscures the fact > that HTML should be an API (so the Console and Gui can use it), but > Gtk will probably be a viewer. Well, I intended that all of these should be APIs, the ANSI coloured text as much as the HTML. As you say, the actual rendering of these belongs elsewhere. So if there is no particular role for a GTK API for hat-cover, it should not exist as a module Tracing.Hat.Coverage.Gtk. The rendering might therefore belong in something like Tracing.Hat.GtkGUI which might use APIs from Tracing.Hat.Coverage as well as Tracing.Hat.Observe, and numerous others as well. Regards, Malcolm From ndmitchell at gmail.com Wed Oct 11 08:40:26 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Oct 11 07:45:50 2006 Subject: [Hat] Proposal, Hierarchical module structure for tools In-Reply-To: <20061011120658.39f3d966.Malcolm.Wallace@cs.york.ac.uk> References: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> <20061010160547.004c7a72.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110113p154b538bn237a05ea05649a81@mail.gmail.com> <20061011112718.3250bd3b.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110344s37daeed7p36b4c81c42455f77@mail.gmail.com> <20061011120658.39f3d966.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <404396ef0610110540w57e2b2f8p7a15a0237343bb94@mail.gmail.com> Hi > I intended the word "textual" to indicate an API that produces Strings, > not something that interacts per se with a terminal. However, I now > realise that your objection is probably that the text strings produced > are not pure - they have ANSI terminal colour codes. Fair enough. Ah, I thought your intention was to export a "main" from this - returning Strings (coloured strings at that) is a perfectly reasonable thing to have as an API. The way I do terminal codes in Hoogle is to define a type, TagStr: data TagStr = Str String | Tags [TagStr] | Underline TagStr | Bold TagStr | Color Int TagStr Now instead of dumping out escape codes, I dump out TagStr's, and then have a routine that converts from TagStr -> String with escape codes. This has the massive advantage that on OS's that don't support escape codes, I can use exactly the same generation code, and then drop the escape codes very simply. Perhaps thats a better way to go instead of having an API that works in very low level escape code terms. > HatCoverText -> Tracing.Hat.Coverage.ANSIterm The name ANSIterm makes me uneasy, Terminal perhaps? ANSIterm just looks ugly, and the case of it is weird compared to the rest of Haskell. In general we now seem to be pretty much in agreement about the proposed structure. Thanks Neil From tom.davie at gmail.com Wed Oct 11 09:32:00 2006 From: tom.davie at gmail.com (Thomas Davie) Date: Wed Oct 11 08:44:21 2006 Subject: [Hat] Proposal, Hierarchical module structure for tools In-Reply-To: <404396ef0610110540w57e2b2f8p7a15a0237343bb94@mail.gmail.com> References: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> <20061010160547.004c7a72.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110113p154b538bn237a05ea05649a81@mail.gmail.com> <20061011112718.3250bd3b.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110344s37daeed7p36b4c81c42455f77@mail.gmail.com> <20061011120658.39f3d966.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110540w57e2b2f8p7a15a0237343bb94@mail.gmail.com> Message-ID: > > The way I do terminal codes in Hoogle is to define a type, TagStr: > > data TagStr = Str String | Tags [TagStr] | Underline TagStr | Bold > TagStr | Color Int TagStr > > Now instead of dumping out escape codes, I dump out TagStr's, and then > have a routine that converts from TagStr -> String with escape codes. > This has the massive advantage that on OS's that don't support escape > codes, I can use exactly the same generation code, and then drop the > escape codes very simply. You should note that this is in large part what hat already does. Look at the Highlight Module. Bob >> HatCoverText -> Tracing.Hat.Coverage.ANSIterm > > The name ANSIterm makes me uneasy, Terminal perhaps? ANSIterm just > looks ugly, and the case of it is weird compared to the rest of > Haskell. > > In general we now seem to be pretty much in agreement about the > proposed structure. I can't see any major problems with it. Bob From ndmitchell at gmail.com Wed Oct 11 10:04:55 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Oct 11 09:10:19 2006 Subject: [Hat] Proposal, Hierarchical module structure for tools In-Reply-To: References: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> <20061010160547.004c7a72.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110113p154b538bn237a05ea05649a81@mail.gmail.com> <20061011112718.3250bd3b.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110344s37daeed7p36b4c81c42455f77@mail.gmail.com> <20061011120658.39f3d966.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110540w57e2b2f8p7a15a0237343bb94@mail.gmail.com> Message-ID: <404396ef0610110704n36eb482fg4819ca1687712c17@mail.gmail.com> Hi, > You should note that this is in large part what hat already does. > Look at the Highlight Module. > > >> HatCoverText -> Tracing.Hat.Coverage.ANSIterm > > > > The name ANSIterm makes me uneasy, Terminal perhaps? ANSIterm just > > looks ugly, and the case of it is weird compared to the rest of > > Haskell. In that case how about Tracing.Hat.Coverage.Highlight, exporting a data structure one step above the low level escape coded strings. Saves us the issue of making an ugly name, and makes it more useful. Thanks Neil From Malcolm.Wallace at cs.york.ac.uk Wed Oct 11 10:23:30 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Oct 11 09:32:14 2006 Subject: [Hat] Proposal, Hierarchical module structure for tools In-Reply-To: <404396ef0610110704n36eb482fg4819ca1687712c17@mail.gmail.com> References: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> <20061010160547.004c7a72.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110113p154b538bn237a05ea05649a81@mail.gmail.com> <20061011112718.3250bd3b.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110344s37daeed7p36b4c81c42455f77@mail.gmail.com> <20061011120658.39f3d966.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110540w57e2b2f8p7a15a0237343bb94@mail.gmail.com> <404396ef0610110704n36eb482fg4819ca1687712c17@mail.gmail.com> Message-ID: <20061011152330.14e22432.Malcolm.Wallace@cs.york.ac.uk> "Neil Mitchell" wrote: > > You should note that this is in large part what hat already does. > > Look at the Highlight Module. > > In that case how about Tracing.Hat.Coverage.Highlight, exporting a > data structure one step above the low level escape coded strings. Yeah. Or Tracing.Hat.Coverage.Highlighted or Tracing.Hat.Coverage.Highlit to make it even clearer. Regards, Malcolm From tom.davie at gmail.com Wed Oct 11 10:22:43 2006 From: tom.davie at gmail.com (Thomas Davie) Date: Wed Oct 11 09:35:16 2006 Subject: [Hat] Proposal, Hierarchical module structure for tools In-Reply-To: <404396ef0610110704n36eb482fg4819ca1687712c17@mail.gmail.com> References: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> <20061010160547.004c7a72.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110113p154b538bn237a05ea05649a81@mail.gmail.com> <20061011112718.3250bd3b.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110344s37daeed7p36b4c81c42455f77@mail.gmail.com> <20061011120658.39f3d966.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110540w57e2b2f8p7a15a0237343bb94@mail.gmail.com> <404396ef0610110704n36eb482fg4819ca1687712c17@mail.gmail.com> Message-ID: Highlight is used by all the tools though, so Tracing.Hat.Highlight would make much more sense. Bob On 11 Oct 2006, at 15:04, Neil Mitchell wrote: > Hi, > >> You should note that this is in large part what hat already does. >> Look at the Highlight Module. >> >> >> HatCoverText -> Tracing.Hat.Coverage.ANSIterm >> > >> > The name ANSIterm makes me uneasy, Terminal perhaps? ANSIterm just >> > looks ugly, and the case of it is weird compared to the rest of >> > Haskell. > > In that case how about Tracing.Hat.Coverage.Highlight, exporting a > data structure one step above the low level escape coded strings. > Saves us the issue of making an ugly name, and makes it more useful. > > Thanks > > Neil > _______________________________________________ > Hat mailing list > Hat@haskell.org > http://www.haskell.org/mailman/listinfo/hat From ndmitchell at gmail.com Wed Oct 11 10:41:15 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Oct 11 09:46:40 2006 Subject: [Hat] Proposal, Hierarchical module structure for tools In-Reply-To: References: <404396ef0610070706u19a6e593vf391237893603fbc@mail.gmail.com> <20061010160547.004c7a72.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110113p154b538bn237a05ea05649a81@mail.gmail.com> <20061011112718.3250bd3b.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110344s37daeed7p36b4c81c42455f77@mail.gmail.com> <20061011120658.39f3d966.Malcolm.Wallace@cs.york.ac.uk> <404396ef0610110540w57e2b2f8p7a15a0237343bb94@mail.gmail.com> <404396ef0610110704n36eb482fg4819ca1687712c17@mail.gmail.com> Message-ID: <404396ef0610110741r3d6b7d86n160a85c5385f44a7@mail.gmail.com> Hi > Highlight is used by all the tools though, so Tracing.Hat.Highlight > would make much more sense. For the module that gives an abstract data structure for a "Highlighted expression" > > In that case how about Tracing.Hat.Coverage.Highlight For the module that generates coverage data in a highlighted data structure. I think everyone agrees pretty much now :) Thanks Neil From Malcolm.Wallace at cs.york.ac.uk Wed Oct 11 11:00:34 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Oct 11 10:25:20 2006 Subject: [Hat] Using Hat with HUnit In-Reply-To: References: Message-ID: <20061011160034.6c6863fc.Malcolm.Wallace@cs.york.ac.uk> "Katerina Barone-Adesi" wrote: > hat-trans -i.. -iHUnit-1.0 HUnit-1.0/HUnitLang.lhs > Wrote Hat/HUnit-1.0/HUnitLang.hs > /usr/bin/ghc ... > HUnit-1.0/Hat/HUnitLang.hs As I think you can see, hat-trans and hmake are disagreeing about where the Hat-translated versions of the source-code should live. hat-trans thinks Hat/HUnit-1.0/HUnitLang.hs whilst hmake thinks HUnit-1.0/Hat/HUnitLang.hs (the inital portion is swapped around). The main reason for this is a differing interpretation of the -i flag (giving a directory where extra source files live). One workaround is to move all the HUnit code to the current directory, rather than a separate directory. Another workaround is to change the name of the HUnit directory, so it no longer begins with upper-case, e.g. hunit-1.0. I know this is somewhat fragile, but the only way some tools know how to distinguish between the filename of a simple module, and the pathname of a hierarchical module, is on the case of the first letter of the directory part. > I'd like to be able to trace my code; I'm indifferent to whether or > not I trace the code within HUnit. Any suggestions on how I can do > this? I hope one of these suggestions is useful. If not, please post again! Regards, Malcolm From barzille at googlemail.com Fri Oct 13 09:02:46 2006 From: barzille at googlemail.com (Barzille) Date: Fri Oct 13 10:41:59 2006 Subject: [Hat] hat-trail: attempt to read beyond end of file Message-ID: <6795165.post@talk.nabble.com> Hi there, I just started to use HAT. After Installation, which was hell ^^, I tried Tutorial Part 1. After compiling $ hmake -hat Insort the output is >hat-trans Insort.hs >Creating directories Hat >Wrote Hat/Insort.hs >ghc -c -package hat -o Hat/Insort.o Hat/Insort.hs > >Hat/Insort.hs:16:0: > Warning: Pattern match(es) are overlapped > In the definition of `hsort': hsort _ p = ... > >Hat/Insort.hs:30:0: > Warning: Pattern match(es) are overlapped > In the definition of `hinsert': hinsert _ _ p = ... >ghc -package hat -o Insort Hat/Insort.o After that I run: $ ./Insort >agmoprr Thats nice, I think. But when I start hat-trail $ hat-trail Insort the output is: >hat-trail: attempt to read beyond end of file >hat-trail: offset = 0x9012cc02, filesize = 0x2008 >hat-trail: errno = 0 (Success) I don't think that this is nice, is it? Has anybody some hints for me? Thanks in advance -- View this message in context: http://www.nabble.com/hat-trail%3A-attempt-to-read-beyond-end-of-file-tf2436896.html#a6795165 Sent from the Haskell - Hat mailing list archive at Nabble.com. From tom.davie at gmail.com Fri Oct 13 11:52:22 2006 From: tom.davie at gmail.com (Thomas Davie) Date: Fri Oct 13 11:04:41 2006 Subject: [Hat] hat-trail: attempt to read beyond end of file In-Reply-To: <6795165.post@talk.nabble.com> References: <6795165.post@talk.nabble.com> Message-ID: Could you run 'hat-check Insort', to check that a correct hat file has been generated? Thanks Tom Davie On 13 Oct 2006, at 14:02, Barzille wrote: > > Hi there, > I just started to use HAT. After Installation, which was hell ^^, I > tried > Tutorial Part 1. After compiling > > $ hmake -hat Insort > > the output is > >> hat-trans Insort.hs >> Creating directories Hat >> Wrote Hat/Insort.hs >> ghc -c -package hat -o Hat/Insort.o Hat/Insort.hs >> >> Hat/Insort.hs:16:0: >> Warning: Pattern match(es) are overlapped >> In the definition of `hsort': hsort _ p = ... >> >> Hat/Insort.hs:30:0: >> Warning: Pattern match(es) are overlapped >> In the definition of `hinsert': hinsert _ _ p = ... >> ghc -package hat -o Insort Hat/Insort.o > > After that I run: > > $ ./Insort > >> agmoprr > > Thats nice, I think. But when I start hat-trail > > $ hat-trail Insort > > the output is: > >> hat-trail: attempt to read beyond end of file >> hat-trail: offset = 0x9012cc02, filesize = 0x2008 >> hat-trail: errno = 0 (Success) > > I don't think that this is nice, is it? Has anybody some hints for me? > > Thanks in advance > > -- > View this message in context: http://www.nabble.com/hat-trail%3A- > attempt-to-read-beyond-end-of-file-tf2436896.html#a6795165 > Sent from the Haskell - Hat mailing list archive at Nabble.com. > > _______________________________________________ > Hat mailing list > Hat@haskell.org > http://www.haskell.org/mailman/listinfo/hat From Malcolm.Wallace at cs.york.ac.uk Fri Oct 13 12:32:35 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Oct 13 11:39:13 2006 Subject: [Hat] hat-trail: attempt to read beyond end of file In-Reply-To: References: <6795165.post@talk.nabble.com> Message-ID: <20061013173235.0a99e9d5.Malcolm.Wallace@cs.york.ac.uk> Thomas Davie wrote: > Could you run 'hat-check Insort', to check that a correct hat file > has been generated? Furthermore, if hat-check reports an error in the Insort.hat file, please send the file, so we can examine it. > > $ hat-trail Insort > > > > the output is: > > > >> hat-trail: attempt to read beyond end of file > >> hat-trail: offset = 0x9012cc02, filesize = 0x2008 > >> hat-trail: errno = 0 (Success) Regards, Malcolm From barzille at googlemail.com Sat Oct 14 08:40:22 2006 From: barzille at googlemail.com (Barzille) Date: Sat Oct 14 07:45:36 2006 Subject: [Hat] hat-trail: attempt to read beyond end of file In-Reply-To: References: <6795165.post@talk.nabble.com> Message-ID: <6810240.post@talk.nabble.com> Hi, hat-check Insort returns the following message: > strange tag 24 at byte offset 0x42e -- View this message in context: http://www.nabble.com/hat-trail%3A-attempt-to-read-beyond-end-of-file-tf2436896.html#a6810240 Sent from the Haskell - Hat mailing list archive at Nabble.com. From barzille at googlemail.com Sat Oct 14 08:41:53 2006 From: barzille at googlemail.com (Barzille) Date: Sat Oct 14 07:47:05 2006 Subject: [Hat] hat-trail: attempt to read beyond end of file In-Reply-To: <20061013173235.0a99e9d5.Malcolm.Wallace@cs.york.ac.uk> References: <6795165.post@talk.nabble.com> <20061013173235.0a99e9d5.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <6810250.post@talk.nabble.com> I added my Insort.hs. I hope that's the file you're thinking of... hat-check returns this message: > strange tag 24 at byte offset 0x42e http://www.nabble.com/file/3631/Insort.hs Insort.hs -- View this message in context: http://www.nabble.com/hat-trail%3A-attempt-to-read-beyond-end-of-file-tf2436896.html#a6810250 Sent from the Haskell - Hat mailing list archive at Nabble.com. From Malcolm.Wallace at cs.york.ac.uk Sat Oct 14 09:22:09 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Sat Oct 14 08:27:39 2006 Subject: [Hat] hat-trail: attempt to read beyond end of file In-Reply-To: <6810250.post@talk.nabble.com> References: <6795165.post@talk.nabble.com> <20061013173235.0a99e9d5.Malcolm.Wallace@cs.york.ac.uk> <6810250.post@talk.nabble.com> Message-ID: <20061014142209.0cda8823.Malcolm.Wallace@cs.york.ac.uk> Barzille writes: > > strange tag 24 at byte offset 0x42e > I added my Insort.hs. I hope that's the file you're thinking of... No, we need the binary file Insort.hat. Regards, Malcolm From barzille at googlemail.com Sat Oct 14 09:23:43 2006 From: barzille at googlemail.com (Barzille) Date: Sat Oct 14 08:28:54 2006 Subject: [Hat] hat-trail: attempt to read beyond end of file In-Reply-To: <20061014142209.0cda8823.Malcolm.Wallace@cs.york.ac.uk> References: <6795165.post@talk.nabble.com> <20061013173235.0a99e9d5.Malcolm.Wallace@cs.york.ac.uk> <6810250.post@talk.nabble.com> <20061014142209.0cda8823.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <6810593.post@talk.nabble.com> Ok, here it is: http://www.nabble.com/file/3632/Insort.hat Insort.hat -- View this message in context: http://www.nabble.com/hat-trail%3A-attempt-to-read-beyond-end-of-file-tf2436896.html#a6810593 Sent from the Haskell - Hat mailing list archive at Nabble.com. From Malcolm.Wallace at cs.york.ac.uk Sat Oct 14 11:55:02 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Sat Oct 14 11:00:30 2006 Subject: [Hat] hat-trail: attempt to read beyond end of file In-Reply-To: <6810593.post@talk.nabble.com> References: <6795165.post@talk.nabble.com> <20061013173235.0a99e9d5.Malcolm.Wallace@cs.york.ac.uk> <6810250.post@talk.nabble.com> <20061014142209.0cda8823.Malcolm.Wallace@cs.york.ac.uk> <6810593.post@talk.nabble.com> Message-ID: <20061014165502.2c23ebeb.Malcolm.Wallace@cs.york.ac.uk> Barzille writes: > http://www.nabble.com/file/3632/Insort.hat Insort.hat Ah, yes I can reproduce the errors you saw. As best I can tell, the generated .hat file has machine words stored in the wrong byte-order. This means all the internal file pointers are wrong. They are supposed to be stored in network (big-endian) order, but your .hat file has them stored in little-endian order. The likeliest cause is that your platform does not implement the C-level htonl() and ntohl() macros/functions correctly. Can you tell us what machine architecture and operating system you are using? You mentioned that installation was difficult. What did you need to do that was unusual? Regards, Malcolm From dcmorse at gmail.com Fri Oct 13 14:17:48 2006 From: dcmorse at gmail.com (David Morse) Date: Sun Oct 15 09:42:06 2006 Subject: [Hat] Failed to load interface for `Hat.PreludeBasic' Message-ID: <11f192740610131117g12346a1dr8215928833d927d4@mail.gmail.com> This appears to be a Hat installation problem. Running the command "hmake -v -hat Test" yields the results: ------------------------------------------------------------------------------------ hat-trans DoublyLinked.hs Wrote Hat/DoublyLinked.hs /usr/bin/haskell-compiler -v -c -package hat -o Hat/DoublyLinked.o Hat/Doub lyLinked.hs Glasgow Haskell Compiler, Version 6.4.1, for Haskell 98, compiled by GHC version 6.4.1 Using package config file: /usr/lib/ghc-6.4.1/package.conf Hsc static flags: -static -funregisterised *** Checking old interface for Hat.DoublyLinked: *** Parser: *** Renamer/typechecker: Hat/DoublyLinked.hs:11:0: Failed to load interface for `Hat.PreludeBasic': Could not find module `Hat.PreludeBasic': locations searched: Hat/PreludeBasic.hi Hat/PreludeBasic.hi-boot *** Deleting temp files Deleting: /tmp/ghc7184.hc Warning: deleting non-existent /tmp/ghc7184.hc ------------------------------------------------------------------------------------- I have explicitly enabled hat via ghc-pkg -l lists "hat" not in parenthesis, so I think the package is enabled. ---------------------------------------------------------------- When apt-getting hat for ubuntu 6.06, note the troubling output of the package manager "ghc-pkg: cannot find package hat" - this was before the hat package was enabled -- could this be the problem? If so, should I more properly ask the package maintainers about this? Setting up hmake (3.10-1.1) ... Setting up hat (2.04-0ubuntu2) ... Setting up hat-ghc6 (2.04-0ubuntu2) ... ghc-pkg: cannot find package hat Reading package info from stdin ... done. Saving old package config file... done. Writing new package config file... done. ------------------------------------------------------------------------------------ Possibly related: "[Hat] hat installation problem" http://www.haskell.org/pipermail/hat/2006-February/000255.html ------------------------------------------------------------------------------------- Any idea what the problem could be? CC me in the reply please, I don't subscribe. From barzille at googlemail.com Sun Oct 15 13:06:54 2006 From: barzille at googlemail.com (Barzille) Date: Sun Oct 15 12:12:05 2006 Subject: [Hat] hat-trail: attempt to read beyond end of file In-Reply-To: <20061014165502.2c23ebeb.Malcolm.Wallace@cs.york.ac.uk> References: <6795165.post@talk.nabble.com> <20061013173235.0a99e9d5.Malcolm.Wallace@cs.york.ac.uk> <6810250.post@talk.nabble.com> <20061014142209.0cda8823.Malcolm.Wallace@cs.york.ac.uk> <6810593.post@talk.nabble.com> <20061014165502.2c23ebeb.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <6822570.post@talk.nabble.com> >Can you tell us what machine architecture and operating system you are using? I am using 64 Bit syYou mentioned that installation was difficult. What did you need to do that was unusual? I only had some problems with the correct installation paths of hmake and hat. And it did not work unless using the config patch for hat. Regards, Malcolm _______________________________________________ Hat mailing list Hat@haskell.org http://www.haskell.org/mailman/listinfo/hat -- View this message in context: http://www.nabble.com/hat-trail%3A-attempt-to-read-beyond-end-of-file-tf2436896.html#a6822570 Sent from the Haskell - Hat mailing list archive at Nabble.com. From roconnor at theorem.ca Mon Oct 16 14:24:00 2006 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Mon Oct 16 14:18:16 2006 Subject: [Hat] using Hat with unsafeCoerce Message-ID: I have a program that is standalone expect for a dependency on unsafeCoerce. Is it possible to use Hat to trace through this program? -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From Malcolm.Wallace at cs.york.ac.uk Mon Oct 16 16:15:24 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Oct 16 15:20:44 2006 Subject: [Hat] using Hat with unsafeCoerce In-Reply-To: References: Message-ID: <20061016211524.6437aa43.Malcolm.Wallace@cs.york.ac.uk> roconnor@theorem.ca writes: > I have a program that is standalone expect for a dependency on > unsafeCoerce. Is it possible to use Hat to trace through this program? Yes, it should be (with a little work). The current set of libraries available within Hat does not include unsafeCoerce, but not for any good reason other than that the portable subset of the base libraries does not define it either. To add unsafeCoerce into Hat, you would need to write a short wrapper module something like this: module Somewhere.Unsafe where import qualified TraceOrigSomewhere.Unsafe foreign import haskell "Somewhere.Unsafe.unsafeCoerce" :: a -> b replacing Somewhere.Unsafe by the real location where the original function is found, of course. Add your new module to the source tree in src/hatlib, and also add it to the definition of TRANSSRCS in src/hatlib/Makefile. Build (or rebuild) and install the Hat package. That should be all that is needed. Regards, Malcolm From barzille at googlemail.com Tue Oct 17 06:57:57 2006 From: barzille at googlemail.com (Barzille) Date: Tue Oct 17 06:03:00 2006 Subject: [Hat] hat-trail: attempt to read beyond end of file In-Reply-To: <20061014165502.2c23ebeb.Malcolm.Wallace@cs.york.ac.uk> References: <6795165.post@talk.nabble.com> <20061013173235.0a99e9d5.Malcolm.Wallace@cs.york.ac.uk> <6810250.post@talk.nabble.com> <20061014142209.0cda8823.Malcolm.Wallace@cs.york.ac.uk> <6810593.post@talk.nabble.com> <20061014165502.2c23ebeb.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <6852690.post@talk.nabble.com> Malcolm, did you find out out anything new? Maik -- View this message in context: http://www.nabble.com/hat-trail%3A-attempt-to-read-beyond-end-of-file-tf2436896.html#a6852690 Sent from the Haskell - Hat mailing list archive at Nabble.com. From O.Chitil at kent.ac.uk Tue Oct 17 07:05:33 2006 From: O.Chitil at kent.ac.uk (Olaf Chitil) Date: Tue Oct 17 06:10:44 2006 Subject: [Hat] hat-trail: attempt to read beyond end of file In-Reply-To: <6852690.post@talk.nabble.com> References: <6795165.post@talk.nabble.com> <20061013173235.0a99e9d5.Malcolm.Wallace@cs.york.ac.uk> <6810250.post@talk.nabble.com> <20061014142209.0cda8823.Malcolm.Wallace@cs.york.ac.uk> <6810593.post@talk.nabble.com> <20061014165502.2c23ebeb.Malcolm.Wallace@cs.york.ac.uk> <6852690.post@talk.nabble.com> Message-ID: <4534B8FD.607@kent.ac.uk> I guess the source of the problem is the 64bit system. Last time I looked at the Hat code a couple of months ago I noticed that for storing node references it sometimes uses C ints, sometimes an explicit 4 byte type. It assumes these are equivalent... It should systematically use a 4 byte type. I was too lazy to systematically clean all source code. Ciao, Olaf From Malcolm.Wallace at cs.york.ac.uk Tue Oct 17 07:27:10 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Oct 17 06:36:46 2006 Subject: [Hat] hat-trail: attempt to read beyond end of file In-Reply-To: <6822570.post@talk.nabble.com> References: <6795165.post@talk.nabble.com> <20061013173235.0a99e9d5.Malcolm.Wallace@cs.york.ac.uk> <6810250.post@talk.nabble.com> <20061014142209.0cda8823.Malcolm.Wallace@cs.york.ac.uk> <6810593.post@talk.nabble.com> <20061014165502.2c23ebeb.Malcolm.Wallace@cs.york.ac.uk> <6822570.post@talk.nabble.com> Message-ID: <20061017122710.78121380.Malcolm.Wallace@cs.york.ac.uk> Barzille wrote: > I am using 64 Bit sy