From simonmarhaskell at gmail.com Fri Feb 2 04:53:43 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 2 04:48:34 2007 Subject: Request for help: 6.6.1 bugs Message-ID: <45C30A27.6090903@gmail.com> Hi Folks, To give you a rough idea of how GHC activity is ramping up, take a look at the number of tickets assigned to recent milestones: 6.4.2: 27 tickets 6.6: 48 tickets 6.6.1: 107 tickets (61 open) 6.8: 134 tickets (117 open) We're focussed on getting 6.6.1 out of the door at the moment. We still have 61 open tickets though, so this message is a plea for help: if you have some time to spare, and would like to help out, please get involved! Here is a query that gives you the list of bugs milestoned for 6.6.1 with no current owner: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&group=milestone&milestone=6.6.1&owner=&order=priority I've also listed the bugs at the end of this message. Some of the bugs we've marked as low priority (blue background), those are the ones we consider would be "nice to fix" but not essential for 6.6.1 (some of these are quite easy, incedentally). The protocol is, if you start working on a bug then claim it by setting yourself as the owner. Other guidelines for working on GHC can be found here: http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions in particular see the section at the end of that page about use of the bug tracker. If you need permission to modify tickets, please ask either myself or Ian. Cheers, Simon open tickets for 6.6.1 with no owner: 742 Graphics.SOE runs very slowly under win32. 804 Signal handlers always installed, evem in a DLL 933 Separate compilation fails with existential records 955 more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization) 957 No way to use -lgmp from a non-standard location 970 GHCi crashes under Windows Millenium 976 GHCi crashes on Windows 98 987 X11: foreign declarations use Haskell types instead of C ones 1010 ghci crashes when running out of heap. 1014 Mangled module name in __stginit_Module symbol 1025 -ddump-minimal-imports works wrongly 1035 Win32 package doesn't appear in the online library docs 1044 library docs on web have broken link 1075 ghci unhandled exception on startup (memory access violation) 1076 runhaskell crash with .hi/.o files in the directory 1082 Documentation missing from MacOS PPC binary 1093 Windows: haddock-html fields are wrong in package.conf 1109 lockFile: fd out of range 1110 Setting PATH needed in Windows Vista 1128 The impossible happened, code commented 604 Windows installer: use WiX 609 Useful optimisation for set-cost-centre 831 GHCi user interface bug 839 Generate documentation for built-in types and primitve operations 850 threaded RTS uses SIGALRM 956 improving error messages #1 998 Tab-completion of filenames does not work in GHCi 6.6 1077 documentation error and omission 1095 make boot under includes/ doesn't run make depend 1096 More make boot / make depend problems 1098 Broken link in the User's Guide 1117 [2,4..10] is not a good list producer 1119 openBinaryFile: does not exist (No such file or directory) i386-unknown-linux 629 IO library locking doesn't count readers From simonpj at microsoft.com Fri Feb 2 09:05:26 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 2 09:00:18 2007 Subject: Request for help: 6.6.1 bugs In-Reply-To: <45C30A27.6090903@gmail.com> References: <45C30A27.6090903@gmail.com> Message-ID: | -----Original Message----- | From: Simon Marlow | Sent: 02 February 2007 09:54 | | We're focussed on getting 6.6.1 out of the door at the moment. We still have 61 | open tickets though, so this message is a plea for help: if you have some time | to spare, and would like to help out, please get involved! Just to reinforce what Simon's message said.... We think that the reason GHC 6.6.1 has such a lot of open bugs is not because quality has fallen, but rather because more and more people are using GHC, in more and more interesting ways. That's good news. And hopefully it also means that there are more and more people who are well-qualified to help find and fix these corner cases. GHC is not our compiler, it's *your* compiler. The more you join in and help us, the better GHC will become. This is quite important, because what may seem like a corner case to us can be a show-stopper for the person who trips over it; and if that happens too much, they just switch languages. 61 open bugs is 61 too many. So do please lend us a hand. Even characterising a bug, narrowing down just what the problem is, can be a huge help. Simon and I and Ian, and others, are ready to help with specific information, the Commentary is an increasingly useful resource. (Please to add material there too, as you find it out.) Thanks; and a big thank-you to those who have already contributed. Simon PS: even if you are looking at a 6.6.1 bug, the usual place to start is with the HEAD; fix and patch the HEAD, and Ian will merge the patch to the branch. Only if the bug is branch-specific should you work on the branch. See http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions From simonmarhaskell at gmail.com Fri Feb 2 11:37:41 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 2 11:32:32 2007 Subject: Become a GHC build slave! Message-ID: <45C368D5.5040706@gmail.com> Thanks largely to Ian Lynagh, GHC now has a BuildBot infrastructure to automate nightly builds on multiple platforms. This replaces the old set of shell scripts that we used to run nightly builds; now adding new clients to the setup is relatively easy, instructions are here: http://hackage.haskell.org/trac/ghc/wiki/BuildBot So far we have various Windows builds running, and I'll be moving over the existing Linux nightly builds in due course. If you have a spare machine or a machine that is idle overnight, and you'd like to use it to run automated GHC builds, then please take a look at the above page for how to get started. We especially need platforms that we don't use regularly (i.e. not Windows or Linux/x86/x86_64). Cheers, Simon From ndmitchell at gmail.com Fri Feb 2 11:43:42 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Feb 2 11:38:30 2007 Subject: [Haskell-cafe] Become a GHC build slave! In-Reply-To: <45C368D5.5040706@gmail.com> References: <45C368D5.5040706@gmail.com> Message-ID: <404396ef0702020843u3efc6738pc3b01738c6d172bf@mail.gmail.com> Hi Simon, > Thanks largely to Ian Lynagh, GHC now has a BuildBot infrastructure to automate > nightly builds on multiple platforms. This replaces the old set of shell > scripts that we used to run nightly builds; now adding new clients to the setup > is relatively easy, instructions are here: > > http://hackage.haskell.org/trac/ghc/wiki/BuildBot Good news! Do you have any idea of how much time a build might take roughly? As a second point, the Yhc team do a variety of builds - some from clean, some from fullclean, some from delete the directory and a completely fresh darcs pull etc. We've found that can help catch things like interface changes, dependancies etc earlier. If you have (or can find) too many Windows/Linux machines etc that might be worth doing - and is pretty easy with buildbot. Thanks Neil From ndmitchell at gmail.com Fri Feb 2 14:59:24 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Feb 2 14:54:16 2007 Subject: [Haskell-cafe] Become a GHC build slave! In-Reply-To: <404396ef0702020843u3efc6738pc3b01738c6d172bf@mail.gmail.com> References: <45C368D5.5040706@gmail.com> <404396ef0702020843u3efc6738pc3b01738c6d172bf@mail.gmail.com> Message-ID: <404396ef0702021159r3dafd343wfeba1255917ffd5d@mail.gmail.com> Hi > As a second point, the Yhc team do a variety of builds - some from > clean, some from fullclean, some from delete the directory and a > completely fresh darcs pull etc. We've found that can help catch > things like interface changes, dependancies etc earlier. If you have > (or can find) too many Windows/Linux machines etc that might be worth > doing - and is pretty easy with buildbot. As a side point, if you are considering becoming a GHC buildbot slave, and are going to go to the (admitedly pretty small) trouble of installing buildbot etc, you might want to consider becoming a Yhc buildbot. Being a Yhc buildbot takes very little processor power and time - builds take between 3 and 15 mins. Our existing list of buildbots is http://www.indiegigs.co.uk:8010/ , and our details on being a buildbot are http://haskell.org/haskellwiki/Yhc/Buildbot . If you do want to be a Yhc buildbot please drop yhc@haskell.org a quick email (cc'ing me, since we've been having some issues of posts bouncing from non-members) Thanks (and appologies for being so off-topic on GHC-users!) Neil From richardg at richardg.name Sat Feb 3 19:43:56 2007 From: richardg at richardg.name (Richard Giraud) Date: Sat Feb 3 19:38:48 2007 Subject: Become a GHC build slave! In-Reply-To: <45C368D5.5040706@gmail.com> References: <45C368D5.5040706@gmail.com> Message-ID: <45C52C4C.5070001@richardg.name> Hello I have a G4 PowerPC Mac Mini and an AMD 64 bit box that I can "donate" to the cause. What OS would be the most useful on the G4? Mac OS X? Linux? BSD? QNX (not sure if it's supported)? What OS would be the most useful on the AMD box? BSD? QNX? Or something else? Richard Simon Marlow wrote: > Thanks largely to Ian Lynagh, GHC now has a BuildBot infrastructure to > automate nightly builds on multiple platforms. This replaces the old > set of shell scripts that we used to run nightly builds; now adding new > clients to the setup is relatively easy, instructions are here: > > http://hackage.haskell.org/trac/ghc/wiki/BuildBot > > So far we have various Windows builds running, and I'll be moving over > the existing Linux nightly builds in due course. > > If you have a spare machine or a machine that is idle overnight, and > you'd like to use it to run automated GHC builds, then please take a > look at the above page for how to get started. We especially need > platforms that we don't use regularly (i.e. not Windows or > Linux/x86/x86_64). > > Cheers, > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > From wss at Cs.Nott.AC.UK Sun Feb 4 08:49:44 2007 From: wss at Cs.Nott.AC.UK (Wouter Swierstra) Date: Sun Feb 4 08:44:29 2007 Subject: GHC appears to loop Message-ID: <3C2CE974-F786-4D70-BB10-7F5E5A73ADAA@Cs.Nott.AC.UK> When I try to compile to the following program, GHC seems to loop: data Evil = Evil (Evil -> Evil) instance Show Evil where show _ = "t" apply :: Evil -> Evil -> Evil apply (Evil f) x = f x delta :: Evil delta = Evil (\x -> x `apply` x) omega :: Evil omega = delta `apply` delta main = print omega The program codes up a non-terminating term omega - very similar to (\x -> x x) (\x -> x x) - without using recursion. The trick is to define an Evil data type which has a negative occurrence of Evil. I realize it's a contrived example, but I wasn't sure if it's a known issue. In case it matters, I'm using GHC 6.6 on a PowerPC Mac. All the best, Wouter From duncan.coutts at worc.ox.ac.uk Sun Feb 4 09:12:23 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 4 09:06:57 2007 Subject: GHC appears to loop In-Reply-To: <3C2CE974-F786-4D70-BB10-7F5E5A73ADAA@Cs.Nott.AC.UK> References: <3C2CE974-F786-4D70-BB10-7F5E5A73ADAA@Cs.Nott.AC.UK> Message-ID: <1170598343.29376.190.camel@localhost> Would you say this the same as the one described in the user guide? http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs-ghc GHC's inliner can be persuaded into non-termination using the standard way to encode recursion via a data type: data U = MkU (U -> Bool) russel :: U -> Bool russel u@(MkU p) = not $ p u x :: Bool x = russel (MkU russel) We have never found another class of programs, other than this contrived one, that makes GHC diverge, and fixing the problem would impose an extra overhead on every compilation. So the bug remains un-fixed. There is more background in Secrets of the GHC inliner. Duncan On Sun, 2007-02-04 at 13:49 +0000, Wouter Swierstra wrote: > When I try to compile to the following program, GHC seems to loop: > > data Evil = Evil (Evil -> Evil) > > instance Show Evil where > show _ = "t" > > apply :: Evil -> Evil -> Evil > apply (Evil f) x = f x > > delta :: Evil > delta = Evil (\x -> x `apply` x) > > omega :: Evil > omega = delta `apply` delta > > main = print omega > > The program codes up a non-terminating term omega - very similar to > (\x -> x x) (\x -> x x) - without using recursion. The trick is to > define an Evil data type which has a negative occurrence of Evil. > > I realize it's a contrived example, but I wasn't sure if it's a known > issue. In case it matters, I'm using GHC 6.6 on a PowerPC Mac. > > All the best, > > Wouter From wss at cs.nott.ac.uk Sun Feb 4 09:37:39 2007 From: wss at cs.nott.ac.uk (Wouter Swierstra) Date: Sun Feb 4 09:32:24 2007 Subject: GHC appears to loop Message-ID: <6FAA1BE2-052A-4392-8B30-CFDBBE5B47A1@cs.nott.ac.uk> On 4 Feb 2007, at 14:12, Duncan Coutts wrote: > Would you say this the same as the one described in the user guide? > > http://www.haskell.org/ghc/docs/latest/html/users_guide/ > bugs.html#bugs-ghc You're right of course. I checked Trac before hitting send, but didn't think to look any further. Thanks for the link, Wouter From wmacgyver at gmail.com Sun Feb 4 12:36:45 2007 From: wmacgyver at gmail.com (Wilson MacGyver) Date: Sun Feb 4 12:31:27 2007 Subject: Become a GHC build slave! In-Reply-To: <45C52C4C.5070001@richardg.name> References: <45C368D5.5040706@gmail.com> <45C52C4C.5070001@richardg.name> Message-ID: <1bc35aa0702040936jb84b14cn11055db275bcb7fd@mail.gmail.com> I'm in the processing of setting up a OSX powerpc buildbot on my end. Maybe we can split the effort to increase powerpc coverage? On 2/3/07, Richard Giraud wrote: > > Hello > > I have a G4 PowerPC Mac Mini and an AMD 64 bit box that I can "donate" > to the cause. > > What OS would be the most useful on the G4? Mac OS X? Linux? BSD? > QNX (not sure if it's supported)? > > What OS would be the most useful on the AMD box? BSD? QNX? Or > something else? > > Richard > > Simon Marlow wrote: > > Thanks largely to Ian Lynagh, GHC now has a BuildBot infrastructure to > > automate nightly builds on multiple platforms. This replaces the old > > set of shell scripts that we used to run nightly builds; now adding new > > clients to the setup is relatively easy, instructions are here: > > > > http://hackage.haskell.org/trac/ghc/wiki/BuildBot > > > > So far we have various Windows builds running, and I'll be moving over > > the existing Linux nightly builds in due course. > > > > If you have a spare machine or a machine that is idle overnight, and > > you'd like to use it to run automated GHC builds, then please take a > > look at the above page for how to get started. We especially need > > platforms that we don't use regularly (i.e. not Windows or > > Linux/x86/x86_64). > > > > Cheers, > > Simon > > _______________________________________________ > > 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 > -- Omnem crede diem tibi diluxisse supremum. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070204/54c0a119/attachment.htm From richardg at richardg.name Sun Feb 4 14:17:23 2007 From: richardg at richardg.name (Richard Giraud) Date: Sun Feb 4 14:12:09 2007 Subject: Become a GHC build slave! In-Reply-To: <1bc35aa0702040936jb84b14cn11055db275bcb7fd@mail.gmail.com> References: <45C368D5.5040706@gmail.com> <45C52C4C.5070001@richardg.name> <1bc35aa0702040936jb84b14cn11055db275bcb7fd@mail.gmail.com> Message-ID: <45C63143.5090703@richardg.name> Thanks for the info; I'll set up the following: - Gentoo Linux on the G4 PPC - OpenBSD for AMD64 for the AMD box. It would be nifty to have an easy-to-view list showing which platforms are covered and which platforms are desired. Richard Wilson MacGyver wrote: > I'm in the processing of setting up a OSX powerpc buildbot on my end. > Maybe we can split the effort to increase powerpc coverage? From wmacgyver at gmail.com Sun Feb 4 22:05:14 2007 From: wmacgyver at gmail.com (Wilson MacGyver) Date: Sun Feb 4 21:59:56 2007 Subject: Become a GHC build slave! In-Reply-To: <45C63143.5090703@richardg.name> References: <45C368D5.5040706@gmail.com> <45C52C4C.5070001@richardg.name> <1bc35aa0702040936jb84b14cn11055db275bcb7fd@mail.gmail.com> <45C63143.5090703@richardg.name> Message-ID: <1bc35aa0702041905o655b5e22o673072e26997329@mail.gmail.com> You can see that here. http://darcs.haskell.org:8010/ and it looks like Thomas Davie already has both OSX PPC and OSX intel covered. there is no reason for multiple build-bot for the same platform is there? On 2/4/07, Richard Giraud wrote: > > Thanks for the info; I'll set up the following: > - Gentoo Linux on the G4 PPC > - OpenBSD for AMD64 for the AMD box. > > It would be nifty to have an easy-to-view list showing which platforms > are covered and which platforms are desired. > -- Omnem crede diem tibi diluxisse supremum. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070204/8d14f20d/attachment.htm From apostoli at cs.utexas.edu Mon Feb 5 01:22:31 2007 From: apostoli at cs.utexas.edu (Ariel Apostoli) Date: Mon Feb 5 01:17:23 2007 Subject: ghc 6.6 for mac os x (intel) Message-ID: <45C6CD27.2050003@cs.utexas.edu> Hello, I tried to install ghc 6.6 but apparently I have done something wrong since whenever I type ghc I obtain: $ /usr/local/bin/ghc dyld: Library not loaded: /opt/local/lib/libreadline.5.1.dylib Referenced from: /usr/local/lib/ghc-6.6/ghc-6.6 Reason: image not found Trace/BPT trap can anyone help please? From catamorphism at gmail.com Mon Feb 5 02:59:11 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Mon Feb 5 02:53:52 2007 Subject: ghc 6.6 for mac os x (intel) In-Reply-To: <45C6CD27.2050003@cs.utexas.edu> References: <45C6CD27.2050003@cs.utexas.edu> Message-ID: <4683d9370702042359q1115ea4ch38bb812f1fbed688@mail.gmail.com> On 2/4/07, Ariel Apostoli wrote: > Hello, > > I tried to install ghc 6.6 but apparently I have done something wrong > since whenever I type ghc I obtain: > > $ /usr/local/bin/ghc > dyld: Library not loaded: /opt/local/lib/libreadline.5.1.dylib > Referenced from: /usr/local/lib/ghc-6.6/ghc-6.6 > Reason: image not found > Trace/BPT trap > Hi, Ariel-- Have you seen the page on building GHC on Mac OS X? http://cvs.haskell.org/trac/ghc/wiki/Building/MacOSX In particular, it explains how to set up the readline library so that GHC can find it. If you try the instructions there and something still doesn't work, feel free to post here again. Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "The astonishment of life is the absence of any appearance of reconciliation between the theory and practice of life."--Emerson From richardg at richardg.name Mon Feb 5 04:04:39 2007 From: richardg at richardg.name (Richard Giraud) Date: Mon Feb 5 03:59:24 2007 Subject: Become a GHC build slave! In-Reply-To: <1bc35aa0702041905o655b5e22o673072e26997329@mail.gmail.com> References: <45C368D5.5040706@gmail.com> <45C52C4C.5070001@richardg.name> <1bc35aa0702040936jb84b14cn11055db275bcb7fd@mail.gmail.com> <45C63143.5090703@richardg.name> <1bc35aa0702041905o655b5e22o673072e26997329@mail.gmail.com> Message-ID: <45C6F327.1090807@richardg.name> I believe that there is value in having multiple BuildBots for the same platform. More value is provided when differences are maximized between BuildBots but there is value in having similar BuildBots (particularly, if the similar BuildBots are popular). Even in the relatively monoculture world of Apple, there is a lot of variation: - The G4 and Core chips are 32-bit and the G5, Core 2, and Core 2 Xeon chips are 64-bit. - The G4 chips have some endianess instructions that are not present in the G5s. - The G5 and Core chips may have 1 or 2 cores in them. - The G5 and Core 2 Xeon chips may come in 1 or 2 CPU variations. - The Core 2 Xeon chips will soon come in 2 or 4 core versions. - The PPC chips support 2 major versions of Mac OS X (10.3 and 10.4). - Third party libraries and applications can come from from: - Apple. - darwinports. - fink. - manually installation. - The libraries may have multiple versions. Creating a bunch of similar BuildBots will help improve coverage of these differences. Wilson MacGyver wrote: > You can see that here. > > http://darcs.haskell.org:8010/ > > and it looks like Thomas Davie already has both OSX PPC and OSX intel > covered. > there is no reason for multiple build-bot for the same platform is there? From Malcolm.Wallace at cs.york.ac.uk Mon Feb 5 08:12:13 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Feb 5 08:10:19 2007 Subject: Become a GHC build slave! In-Reply-To: <1bc35aa0702041905o655b5e22o673072e26997329@mail.gmail.com> References: <45C368D5.5040706@gmail.com> <45C52C4C.5070001@richardg.name> <1bc35aa0702040936jb84b14cn11055db275bcb7fd@mail.gmail.com> <45C63143.5090703@richardg.name> <1bc35aa0702041905o655b5e22o673072e26997329@mail.gmail.com> Message-ID: <20070205131213.49c09071.Malcolm.Wallace@cs.york.ac.uk> "Wilson MacGyver" wrote: > there is no reason for multiple build-bot for the same platform is > there? If you have two or three slaves for each platform, then the buildbot is robustified against downtime of any of the machines (intentional, like going on holiday for a couple of weeks, or unintentional when the machine just dies). Regards, Malcolm From ndmitchell at gmail.com Mon Feb 5 08:23:43 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Feb 5 08:18:23 2007 Subject: Become a GHC build slave! In-Reply-To: <20070205131213.49c09071.Malcolm.Wallace@cs.york.ac.uk> References: <45C368D5.5040706@gmail.com> <45C52C4C.5070001@richardg.name> <1bc35aa0702040936jb84b14cn11055db275bcb7fd@mail.gmail.com> <45C63143.5090703@richardg.name> <1bc35aa0702041905o655b5e22o673072e26997329@mail.gmail.com> <20070205131213.49c09071.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <404396ef0702050523o327d2a78x355b52f15d80b434@mail.gmail.com> Hi, One of the issues the Yhc people had with Mac buildbots is that no one figured out how to get the buildbot slaves to run on startup with a Mac. If one of the Mac people does figure that out, adding it to the wiki would be most appreciated. Thanks Neil On 2/5/07, Malcolm Wallace wrote: > "Wilson MacGyver" wrote: > > > there is no reason for multiple build-bot for the same platform is > > there? > > If you have two or three slaves for each platform, then the buildbot is > robustified against downtime of any of the machines (intentional, like > going on holiday for a couple of weeks, or unintentional when the > machine just dies). > > Regards, > Malcolm > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From simonmarhaskell at gmail.com Mon Feb 5 10:28:15 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Feb 5 10:22:57 2007 Subject: [Haskell-cafe] Become a GHC build slave! In-Reply-To: <404396ef0702020843u3efc6738pc3b01738c6d172bf@mail.gmail.com> References: <45C368D5.5040706@gmail.com> <404396ef0702020843u3efc6738pc3b01738c6d172bf@mail.gmail.com> Message-ID: <45C74D0F.7000102@gmail.com> Neil Mitchell wrote: > Hi Simon, > >> Thanks largely to Ian Lynagh, GHC now has a BuildBot infrastructure to >> automate >> nightly builds on multiple platforms. This replaces the old set of shell >> scripts that we used to run nightly builds; now adding new clients to >> the setup >> is relatively easy, instructions are here: >> >> http://hackage.haskell.org/trac/ghc/wiki/BuildBot > > Good news! Do you have any idea of how much time a build might take > roughly? It depends how much you want to do: as a rough guide, our really-do-everything builds take about 8 hours on a fast machine, that includes - 3 compiler stages (only 2 are necessary, the 3rd is a sanity check) - the "extra libraries" - all libraries built for profiling and "unregisterised" - split objects - a full testsuite run, in all the supported ways - 5 runs of the nofib benchmark suite, with various flag settings - build & upload distributions We can do a "fast" build in much less time: probably about 1 hour for - 2 compiler stages - core libraries only - no profiled libraries - no split objects - a "fast" testsuite run - no benchmarks You tell us how much time you have, we can keep your machine busy :-) > As a second point, the Yhc team do a variety of builds - some from > clean, some from fullclean, some from delete the directory and a > completely fresh darcs pull etc. We've found that can help catch > things like interface changes, dependancies etc earlier. If you have > (or can find) too many Windows/Linux machines etc that might be worth > doing - and is pretty easy with buildbot. All our builds start with a fresh checkout right now. There are certainly things that can go wrong if you don't fully clean the tree and re-configure after updates (e.g. modifications to the configure.ac files), so I'm not sure it would be useful to start from an partially-clean tree. Cheers, Simon From tayscristina at yahoo.com.br Mon Feb 5 14:28:03 2007 From: tayscristina at yahoo.com.br (Tays Soares) Date: Mon Feb 5 14:22:42 2007 Subject: (no subject) Message-ID: <894423.75661.qm@web50601.mail.yahoo.com> Hello everyone, I did at my master thesis a compiler that generates Haskell code. Now I need to measure the execution time of my generated code and I've been searched and I don't know if I'm looking with the wrong keywords but I could not find anything. I just need to measure the time of simple functions, like Ackermann and Fibonacci. Does anyone know how to measure the execution time of a Haskell program or function? Thank you, Tays __________________________________________________ Fale com seus amigos de gra?a com o novo Yahoo! Messenger http://br.messenger.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070205/f7732512/attachment.htm From tayscristina at yahoo.com.br Mon Feb 5 14:28:03 2007 From: tayscristina at yahoo.com.br (Tays Soares) Date: Mon Feb 5 14:22:42 2007 Subject: (no subject) Message-ID: <894423.75661.qm@web50601.mail.yahoo.com> Hello everyone, I did at my master thesis a compiler that generates Haskell code. Now I need to measure the execution time of my generated code and I've been searched and I don't know if I'm looking with the wrong keywords but I could not find anything. I just need to measure the time of simple functions, like Ackermann and Fibonacci. Does anyone know how to measure the execution time of a Haskell program or function? Thank you, Tays __________________________________________________ Fale com seus amigos de gra?a com o novo Yahoo! Messenger http://br.messenger.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070205/f7732512/attachment-0001.htm From catamorphism at gmail.com Mon Feb 5 14:55:55 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Mon Feb 5 14:50:33 2007 Subject: time profiling (was: (no subject)) Message-ID: <4683d9370702051155j2c09f151oe445bba37603897f@mail.gmail.com> On 2/5/07, Tays Soares wrote: > > > > Hello everyone, > > I did at my master thesis a compiler that generates Haskell code. Now I need to measure the execution time of my generated code and I've been searched and I don't know if I'm looking with the wrong keywords but I could not find anything. I just need to measure the time of simple functions, like Ackermann and Fibonacci. Does anyone know how to measure the execution time of a Haskell program or function? If you just want wallclock time, then use the standard Unix "time" command. If you want more specific data, look at the Profiling section of the GHC manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/profiling.html and also at the Profiling section of the Commentary, though it's very incomplete: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Profiling And feel free to ask again on this list after looking at those pages, if you still have more questions. Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "the faith that is so easy to forget / in moment after moment of distraction" -- Ilene Weiss From chad.scherrer at gmail.com Mon Feb 5 14:57:44 2007 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Mon Feb 5 14:52:27 2007 Subject: No instance for (Monad ((->) Integer)) Message-ID: I'm getting this error in ghci, and I think it should typecheck just fine. Prelude> let fs = [(+2), (*4)] Prelude> :t fs fs :: [Integer -> Integer] Prelude> :t sequence fs :1:0: No instance for (Monad ((->) Integer)) arising from use of `sequence' at :1:0-10 Possible fix: add an instance declaration for (Monad ((->) Integer)) I'm using ghc-6.6-3 on Ubuntu edgy, installed as described on Pupeno's web site (http://pupeno.com/2006/12/17/unstable-packages-on-ubuntu/) Could something be installed incorrectly, or am I just misreading the type info? Thanks, Chad From ndmitchell at gmail.com Mon Feb 5 14:58:14 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Feb 5 14:53:00 2007 Subject: (no subject) In-Reply-To: <894423.75661.qm@web50601.mail.yahoo.com> References: <894423.75661.qm@web50601.mail.yahoo.com> Message-ID: <404396ef0702051158v77aee6d4l6218e5773640ab8b@mail.gmail.com> Hi Tays, > I did at my master thesis a compiler that generates Haskell code. Now I need > to measure the execution time of my generated code and I've been searched > and I don't know if I'm looking with the wrong keywords but I could not find > anything. I just need to measure the time of simple functions, like > Ackermann and Fibonacci. Does anyone know how to measure the execution time > of a Haskell program or function? Does the unix command "time" not work? (if you are on windows I have a variant from Bulat that does the same on Windows) The CPUTime module also has some useful bits. Thanks Neil From ndmitchell at gmail.com Mon Feb 5 15:03:02 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Feb 5 14:57:41 2007 Subject: No instance for (Monad ((->) Integer)) In-Reply-To: References: Message-ID: <404396ef0702051203y780e87f8vabc8a69ade1042ad@mail.gmail.com> Hi Chad, > Prelude> let fs = [(+2), (*4)] > Prelude> :t fs > fs :: [Integer -> Integer] > Prelude> :t sequence fs I think you need to import Control.Monad.Instances to get the appropriate instance in scope. Thanks Neil From chad.scherrer at gmail.com Mon Feb 5 15:10:48 2007 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Mon Feb 5 15:05:27 2007 Subject: No instance for (Monad ((->) Integer)) In-Reply-To: <404396ef0702051203y780e87f8vabc8a69ade1042ad@mail.gmail.com> References: <404396ef0702051203y780e87f8vabc8a69ade1042ad@mail.gmail.com> Message-ID: On 2/5/07, Neil Mitchell wrote: > Hi Chad, > > > Prelude> let fs = [(+2), (*4)] > > Prelude> :t fs > > fs :: [Integer -> Integer] > > Prelude> :t sequence fs > > I think you need to import Control.Monad.Instances to get the > appropriate instance in scope. > Hmm, that's weird. The instance Monad ((->) r) is mentioned in Control.Monad, so I thought importing it might be enough. From seth at cql.com Mon Feb 5 18:55:00 2007 From: seth at cql.com (Seth Kurtzberg) Date: Mon Feb 5 18:53:13 2007 Subject: [Haskell-cafe] Become a GHC build slave! In-Reply-To: <45C74D0F.7000102@gmail.com> References: <45C368D5.5040706@gmail.com> <404396ef0702020843u3efc6738pc3b01738c6d172bf@mail.gmail.com> <45C74D0F.7000102@gmail.com> Message-ID: <20070205185500.24bc16dc.seth@cql.com> I'm joining this discussion a bit late, but ... I can provide a build machines for netbsd and freebsd. I didn't see those on the URL cited below. They are fairly common, so perhaps I just missed them. In any event, if netbsd and/or freebsd will be helpful, please let me know. Seth Kurtzberg On Mon, 05 Feb 2007 15:28:15 +0000 Simon Marlow wrote: > Neil Mitchell wrote: > > Hi Simon, > > > >> Thanks largely to Ian Lynagh, GHC now has a BuildBot infrastructure to > >> automate > >> nightly builds on multiple platforms. This replaces the old set of shell > >> scripts that we used to run nightly builds; now adding new clients to > >> the setup > >> is relatively easy, instructions are here: > >> > >> http://hackage.haskell.org/trac/ghc/wiki/BuildBot > > > > Good news! Do you have any idea of how much time a build might take > > roughly? > > It depends how much you want to do: as a rough guide, our really-do-everything > builds take about 8 hours on a fast machine, that includes > > - 3 compiler stages (only 2 are necessary, the 3rd is a sanity check) > - the "extra libraries" > - all libraries built for profiling and "unregisterised" > - split objects > - a full testsuite run, in all the supported ways > - 5 runs of the nofib benchmark suite, with various flag settings > - build & upload distributions > > We can do a "fast" build in much less time: probably about 1 hour for > > - 2 compiler stages > - core libraries only > - no profiled libraries > - no split objects > - a "fast" testsuite run > - no benchmarks > > You tell us how much time you have, we can keep your machine busy :-) > > > As a second point, the Yhc team do a variety of builds - some from > > clean, some from fullclean, some from delete the directory and a > > completely fresh darcs pull etc. We've found that can help catch > > things like interface changes, dependancies etc earlier. If you have > > (or can find) too many Windows/Linux machines etc that might be worth > > doing - and is pretty easy with buildbot. > > All our builds start with a fresh checkout right now. There are certainly > things that can go wrong if you don't fully clean the tree and re-configure > after updates (e.g. modifications to the configure.ac files), so I'm not sure it > would be useful to start from an partially-clean tree. > > Cheers, > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From seth at cql.com Mon Feb 5 19:10:38 2007 From: seth at cql.com (Seth Kurtzberg) Date: Mon Feb 5 19:08:50 2007 Subject: (no subject) In-Reply-To: <894423.75661.qm@web50601.mail.yahoo.com> References: <894423.75661.qm@web50601.mail.yahoo.com> Message-ID: <20070205191038.1a09460b.seth@cql.com> GHC has profiling support. (By the way, many mail servers these days discard mail with no subject.) I've seen a number of papers comparing the speed of Haskell code to code of other functional languages; there is a periodic "shoot out" with ocaml. Some probably have comparisons with imperative languages, and, even if they do not, the methodology should help you. Seth Kurtzberg On Mon, 5 Feb 2007 11:28:03 -0800 (PST) Tays Soares wrote: > Hello everyone, > > I did at my master thesis a compiler that generates Haskell code. Now I need to measure the execution time of my generated code and I've been searched and I don't know if I'm looking with the wrong keywords but I could not find anything. I just need to measure the time of simple functions, like Ackermann and Fibonacci. Does anyone know how to measure the execution time of a Haskell program or function? > > Thank you, > Tays > > > > __________________________________________________ > Fale com seus amigos de gra?a com o novo Yahoo! Messenger > http://br.messenger.yahoo.com/ From catamorphism at gmail.com Mon Feb 5 20:19:04 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Mon Feb 5 20:13:45 2007 Subject: time profiling (was: (no subject)) In-Reply-To: <4683d9370702051155j2c09f151oe445bba37603897f@mail.gmail.com> References: <4683d9370702051155j2c09f151oe445bba37603897f@mail.gmail.com> Message-ID: <4683d9370702051719v288972l27dfa5adca7b2987@mail.gmail.com> On 2/5/07, Kirsten Chevalier wrote: > On 2/5/07, Tays Soares wrote: > > > > > > > > Hello everyone, > > > > I did at my master thesis a compiler that generates Haskell code. Now I need to measure the execution time of my generated code and I've been searched and I don't know if I'm looking with the wrong keywords but I could not find anything. I just need to measure the time of simple functions, like Ackermann and Fibonacci. Does anyone know how to measure the execution time of a Haskell program or function? Another post (where someone didn't change the subject line) mentioned looking at existing research in order to get an idea of what methodology people used for profiling, so while we're at it, I might as well plug my own master's thesis, where, in chapter 4, I wrote about how I measured the performance of a Haskell optimization I implemented externally to GHC: http://lafalafu.com/krc/Writing/chevalier_ms_2004_type_inference.pdf Maybe it'll be helpful to you. Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "What doesn't kill you makes you look really, really bad."--Carrie Fisher From mattcbro at earthlink.net Tue Feb 6 02:35:19 2007 From: mattcbro at earthlink.net (SevenThunders) Date: Tue Feb 6 02:29:57 2007 Subject: Problem exporting Haskell to C via a DLL in GHC 6.6 Message-ID: <8821647.post@talk.nabble.com> Before I post this as a bug, I thought I'd check to make sure I'm not doing something wrong. For this test case, on my windows XP machine I create a simple Haskell routine that counts the characters in a file, create a DLL for that routine and call it from C. The C code gives the correct answer (I think) but then proceeds to hang and never terminate. If the readFile call is removed from this code, and a constant output is assigned to the variable ll, the code works fine and terminates correctly. Thus the bug may possibly be some kind of interaction with the file IO routine, if it's a bug at all. First the Haskell code: baddll.hs: module Bad where import Foreign.Ptr import Foreign.C.String import Foreign.C.Types (CInt, CDouble ) foreign export stdcall badfunc :: CString -> IO (CInt) -- -- | Conversion from Int to CInt mkCInt :: Int -> CInt mkCInt n = fromIntegral n badfunc fstr = do file <- peekCAString fstr sstr <- readFile file let ll = length sstr return $ mkCInt ll The C code: #include __declspec(dllimport) int __stdcall badfunc(char *outfile) ; int main(int argc, char *argv) { int ll ; ll = badfunc("bad.txt") ; printf("ll = %d\n", ll) ; return(1) ; } The .bat file used to compile everything. (Assumes ghc and MS VC++ 6.0 is in my path) baddll.bat: ghc -O2 -static -c baddll.hs -fglasgow-exts ghc -c dllBad.c ghc --mk-dll -static -fglasgow-exts -o baddll.dll dllBad.o baddll.o baddll_stub.o -L"." -L"." -optdll--def -optdllbaddll.def lib /def:baddll.def /MACHINE:X86 cl baddll.c baddll.lib The .def file used to create the dll export symbols. baddll.def LIBRARY baddll.dll EXPORTS badfunc@4 badfunc = badfunc@4 The boilerplate code to load and unload the Haskell runtime inside the DLL. dllBad.c #include #include extern void __stginit_Bad(void); static char* args[] = { "ghcDll", NULL }; /* N.B. argv arrays must end with NULL */ BOOL STDCALL DllMain ( HANDLE hModule , DWORD reason , void* reserved ) { if (reason == DLL_PROCESS_ATTACH) { /* By now, the RTS DLL should have been hoisted in, but we need to start it up. */ startupHaskell(1, args, __stginit_Bad); return TRUE; } if (reason == DLL_PROCESS_DETACH) { shutdownHaskell(); return TRUE; } return TRUE; } The text file I read in. bad.txt: Greetings Earthlings If I recall correctly, from another piece of test code, this seemed to work OK in GHC 6.4. However, I'll have to resurrect my GHC 6.4 installation to verify this. If anyone sees an obvious problem with my code I'd love to be informed about this. -- View this message in context: http://www.nabble.com/Problem-exporting-Haskell-to-C-via-a-DLL-in-GHC-6.6-tf3179123.html#a8821647 Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From catamorphism at gmail.com Tue Feb 6 02:50:36 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Tue Feb 6 02:45:14 2007 Subject: ghc 6.6 for mac os x (intel) In-Reply-To: <45C7E028.7000907@cs.utexas.edu> References: <45C6CD27.2050003@cs.utexas.edu> <4683d9370702042359q1115ea4ch38bb812f1fbed688@mail.gmail.com> <45C7E028.7000907@cs.utexas.edu> Message-ID: <4683d9370702052350j56b25dabt6de6df09953f34b4@mail.gmail.com> [redirecting to the list] On 2/5/07, Ariel Apostoli wrote: > Hello Kirsten, > > Thanks so much for your time and help so far. However, I am still stuck > on the issue when I try to do this: > > ./configure --with-readline-includes=/usr/local \ > --with-readline-libraries=/usr/local > > I get: > checking build system type... i686-apple-darwin8.8.1 > checking host system type... i686-apple-darwin8.8.1 > checking target system type... i686-apple-darwin8.8.1 > Canonicalised to: i386-apple-darwin > checking for path to top of build tree... /Users/ariel/work/ghc/ghc-6.6 > checking for ghc... no > checking for ghc-pkg matching ... no > checking for ghc-pkg... no > checking whether ghc has readline package... no > checking for nhc... no > checking for nhc98... no > checking for hbc... no > configure: error: GHC is required unless bootstrapping from .hc files. > > Do you know what should I do to avoid this? > Do you already have a binary version of GHC installed? If you want to build GHC from source, you need a binary of GHC installed already, like the error message suggests. (Unless you want to bootstrap from .hc files, but I've never done that, so I don't know.) See: http://haskell.org/ghc/download_ghc_66.html#macosxintel You didn't say what version of Mac OS X you were using; if it's anything older than 10.3, you're probably SOL. Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "just thinking of a series of dreams" -- Bob Dylan From alistair at abayley.org Tue Feb 6 04:00:17 2007 From: alistair at abayley.org (Alistair Bayley) Date: Tue Feb 6 03:54:55 2007 Subject: Compiling module using Data.Time with -O fails; can't find HsTime.h Message-ID: <79d7c4980702060100s56079703mc990134a2898bb4@mail.gmail.com> If I try to compile this Main.hs: module Main where import Data.Time main = getCurrentTime >>= print with this ghc-6.6 command: ghc --make Main -o test -O ... I get this error: C:\DOCUME~1\bayleya\LOCALS~1\Temp\ghc728_0\ghc728_0.hc:8:20: HsTime.h: No such file or directory Is this me doing something I shouldn't, or is there something wrong with the way the library has been distributed? Alistair From brianh at metamilk.com Tue Feb 6 04:31:19 2007 From: brianh at metamilk.com (Brian Hulley) Date: Tue Feb 6 04:26:05 2007 Subject: Problem exporting Haskell to C via a DLL in GHC 6.6 References: <8821647.post@talk.nabble.com> Message-ID: <000301c749d1$95e761b0$0bce2950@osmet> SevenThunders wrote: > Before I post this as a bug, I thought I'd check to make sure I'm not > doing something wrong. > BOOL > STDCALL > DllMain > ( HANDLE hModule > , DWORD reason > , void* reserved > ) > { > if (reason == DLL_PROCESS_ATTACH) { > /* By now, the RTS DLL should have been hoisted in, but we need > to start it up. */ > startupHaskell(1, args, __stginit_Bad); > return TRUE; > } > > if (reason == DLL_PROCESS_DETACH) { > shutdownHaskell(); > return TRUE; > } > > return TRUE; > } The above *may* be the problem: it is unsafe to do anything in DllMain that may involve loading a DLL, (which therefore includes a lot of the standard platform sdk functions, some of which Haskell may need to use to start/sthurdown) because the order in which DllMain is called when Windows loads/unloads DLLs is undefined - see platform sdk docs for more info. Instead of trying to start/shutdown Haskell from DllMain, I'd export a Begin() and End() function from the DLL and explicitly call these from your application's main(). Hope this helps, Brian. -- http://www.metamilk.com From simonmarhaskell at gmail.com Tue Feb 6 04:47:47 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Feb 6 04:42:36 2007 Subject: [Haskell-cafe] Become a GHC build slave! In-Reply-To: <20070205185500.24bc16dc.seth@cql.com> References: <45C368D5.5040706@gmail.com> <404396ef0702020843u3efc6738pc3b01738c6d172bf@mail.gmail.com> <45C74D0F.7000102@gmail.com> <20070205185500.24bc16dc.seth@cql.com> Message-ID: <45C84EC3.6040504@gmail.com> Seth Kurtzberg wrote: > I'm joining this discussion a bit late, but ... > > I can provide a build machines for netbsd and freebsd. I didn't see those on the URL cited below. They are fairly common, so perhaps I just missed them. > > In any event, if netbsd and/or freebsd will be helpful, please let me know. Yes please! Follow the instructions for setting up your client at http://hackage.haskell.org/trac/ghc/wiki/BuildBot and let either myself or Ian know your username/password, and what time you want your build(s) to run. Cheers, Simon From simonmarhaskell at gmail.com Tue Feb 6 04:51:45 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Feb 6 04:46:24 2007 Subject: [Haskell-cafe] Become a GHC build slave! In-Reply-To: <20070202195057.GE11074@ISAAnybody.cs.uiuc.edu> References: <45C368D5.5040706@gmail.com> <20070202195057.GE11074@ISAAnybody.cs.uiuc.edu> Message-ID: <45C84FB1.7020309@gmail.com> dgriffi3@uiuc.edu wrote: > Here at ACM@UIUC we have the following that we could use: > AIX on PPC > Linux on PPC > Mac OSX on PPC > Mac OSX on x86 > OpenVMS on Alpha > Solaris on Sparc > > If needed we could also set up the following: > Solaris on x86 > BeOS on BeBox > IRIX on MIPS > Linux on Sparc > something on Itanium (Preproduciton-caliber Float support) Thanks - all of these would be useful; only the two Mac OS X builds would be duplicates, but duplicates are useful (as redundancy). Please let us know when you've set up your clients and we'll add you to the setup. Cheers, Simon From simonmarhaskell at gmail.com Tue Feb 6 05:01:43 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Feb 6 04:56:23 2007 Subject: Problem exporting Haskell to C via a DLL in GHC 6.6 In-Reply-To: <8821647.post@talk.nabble.com> References: <8821647.post@talk.nabble.com> Message-ID: <45C85207.9080702@gmail.com> SevenThunders wrote: > Before I post this as a bug, I thought I'd check to make sure I'm not doing > something wrong. > For this test case, on my windows XP machine I create a simple Haskell > routine that counts the characters in a file, > create a DLL for that routine and call it from C. The C code gives the > correct answer (I think) but then > proceeds to hang and never terminate. I wonder if you're hitting this bug: http://hackage.haskell.org/trac/ghc/ticket/926 if so, it's slightly worrying that the same thing happens if you just link your program directly to the DLL, rather than loading it explicitly. Cheers, Simon > If the readFile call is removed from > this code, and a constant output is assigned to the variable ll, the code > works fine and terminates correctly. Thus the bug may possibly be some kind > of interaction with the file IO routine, if it's a bug at all. > > First the Haskell code: > > baddll.hs: > > module Bad > where > import Foreign.Ptr > import Foreign.C.String > import Foreign.C.Types (CInt, CDouble ) > > foreign export stdcall badfunc :: CString -> IO (CInt) > -- > -- | Conversion from Int to CInt > mkCInt :: Int -> CInt > mkCInt n = fromIntegral n > > badfunc fstr = do > file <- peekCAString fstr > sstr <- readFile file > let ll = length sstr > return $ mkCInt ll > > The C code: > #include > __declspec(dllimport) int __stdcall badfunc(char *outfile) ; > > > int main(int argc, char *argv) > { > int ll ; > ll = badfunc("bad.txt") ; > printf("ll = %d\n", ll) ; > return(1) ; > } > > The .bat file used to compile everything. (Assumes ghc and MS VC++ 6.0 is > in my path) > baddll.bat: > > ghc -O2 -static -c baddll.hs -fglasgow-exts > ghc -c dllBad.c > ghc --mk-dll -static -fglasgow-exts -o baddll.dll dllBad.o baddll.o > baddll_stub.o -L"." -L"." -optdll--def -optdllbaddll.def > lib /def:baddll.def /MACHINE:X86 > cl baddll.c baddll.lib > > The .def file used to create the dll export symbols. > baddll.def > LIBRARY baddll.dll > EXPORTS > badfunc@4 > badfunc = badfunc@4 > > The boilerplate code to load and unload the Haskell runtime inside the DLL. > dllBad.c > #include > #include > > extern void __stginit_Bad(void); > > static char* args[] = { "ghcDll", NULL }; > /* N.B. argv arrays must end with NULL */ > BOOL > STDCALL > DllMain > ( HANDLE hModule > , DWORD reason > , void* reserved > ) > { > if (reason == DLL_PROCESS_ATTACH) { > /* By now, the RTS DLL should have been hoisted in, but we need to > start it up. */ > startupHaskell(1, args, __stginit_Bad); > return TRUE; > } > > if (reason == DLL_PROCESS_DETACH) { > shutdownHaskell(); > return TRUE; > } > > return TRUE; > } > > > The text file I read in. > bad.txt: > > Greetings Earthlings > > > If I recall correctly, from another piece of test code, this seemed to work > OK in GHC 6.4. However, I'll have to resurrect my GHC 6.4 installation to > verify this. If anyone sees an obvious problem with my code I'd love to be > informed about this. From cperfumo at gmail.com Tue Feb 6 05:21:23 2007 From: cperfumo at gmail.com (Cristian Perfumo) Date: Tue Feb 6 05:17:06 2007 Subject: (no subject) In-Reply-To: <20070205191038.1a09460b.seth@cql.com> References: <894423.75661.qm@web50601.mail.yahoo.com> <20070205191038.1a09460b.seth@cql.com> Message-ID: Hi Tays, If I understood correctly, if your compiler generates Haskell code, then later on you should compile this code (with GHC, for example) and running it implies a main function that is of the tipe IO() (i.e. IO Monad). What you can do is to add (it could be, for example, in debugging mode in your compiler) the code i paste below at the beginning and in the end of your main function. Well, I don't know exactly if this answers your question. If it doesn't, my apologies. Cheers Cristian import System.Time import Text.Printf { ; timeStart <- getClockTime ... your process ; timeEnd <- getClockTime ; let diff = (normalizeTimeDiff (diffClockTimes timeEnd timeStart)) ; print ((((fromIntegral(tdPicosec diff))/(10^12))) + (fromIntegral((tdSec diff) + (60 * (tdMin diff)) + (3600 * (tdHour diff))))) ; return () } On 2/6/07, Seth Kurtzberg wrote: > > GHC has profiling support. > > (By the way, many mail servers these days discard mail with no subject.) > > I've seen a number of papers comparing the speed of Haskell code to code > of other functional languages; there is a periodic "shoot out" with ocaml. > > Some probably have comparisons with imperative languages, and, even if > they do not, the methodology should help you. > > Seth Kurtzberg > > On Mon, 5 Feb 2007 11:28:03 -0800 (PST) > Tays Soares wrote: > > > Hello everyone, > > > > I did at my master thesis a compiler that generates Haskell code. Now I > need to measure the execution time of my generated code and I've been > searched and I don't know if I'm looking with the wrong keywords but I could > not find anything. I just need to measure the time of simple functions, like > Ackermann and Fibonacci. Does anyone know how to measure the execution time > of a Haskell program or function? > > > > Thank you, > > Tays > > > > > > > > __________________________________________________ > > Fale com seus amigos de gra?a com o novo Yahoo! Messenger > > http://br.messenger.yahoo.com/ > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070206/74166e42/attachment-0001.htm From igloo at earth.li Tue Feb 6 10:12:25 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue Feb 6 10:07:02 2007 Subject: Compiling module using Data.Time with -O fails; can't find HsTime.h In-Reply-To: <79d7c4980702060100s56079703mc990134a2898bb4@mail.gmail.com> References: <79d7c4980702060100s56079703mc990134a2898bb4@mail.gmail.com> Message-ID: <20070206151225.GA18707@matrix.chaos.earth.li> Hi Alistair, On Tue, Feb 06, 2007 at 09:00:17AM +0000, Alistair Bayley wrote: > > C:\DOCUME~1\bayleya\LOCALS~1\Temp\ghc728_0\ghc728_0.hc:8:20: HsTime.h: > No such file or directory > > Is this me doing something I shouldn't, No, this should work. > or is there something wrong > with the way the library has been distributed? I can reproduce this with my installation by the Windows installer, but not the Debian packages which build time as a standalone cabal package. I've made a ticket for it: http://hackage.haskell.org/trac/ghc/ticket/1135 Thanks Ian From apostoli at cs.utexas.edu Tue Feb 6 10:15:32 2007 From: apostoli at cs.utexas.edu (Ariel Apostoli) Date: Tue Feb 6 10:10:22 2007 Subject: ghc 6.6 for mac os x (intel) In-Reply-To: <4683d9370702052350j56b25dabt6de6df09953f34b4@mail.gmail.com> References: <45C6CD27.2050003@cs.utexas.edu> <4683d9370702042359q1115ea4ch38bb812f1fbed688@mail.gmail.com> <45C7E028.7000907@cs.utexas.edu> <4683d9370702052350j56b25dabt6de6df09953f34b4@mail.gmail.com> Message-ID: <45C89B94.3050307@cs.utexas.edu> but when I try installing ghc from that page it seems to install fine but when I invoke /usr/local/bin/ghc i get: dyld: Library not loaded: /opt/local/lib/libreadline.5.1.dylib Referenced from: /usr/local/lib/ghc-6.6/ghc-6.6 Reason: image not found Trace/BPT trap My version of mac os x is 10.4.8 Again thanks for your time and help so far! Ariel Kirsten Chevalier wrote: > [redirecting to the list] > On 2/5/07, Ariel Apostoli wrote: >> Hello Kirsten, >> >> Thanks so much for your time and help so far. However, I am still stuck >> on the issue when I try to do this: >> >> ./configure --with-readline-includes=/usr/local \ >> --with-readline-libraries=/usr/local >> >> I get: >> checking build system type... i686-apple-darwin8.8.1 >> checking host system type... i686-apple-darwin8.8.1 >> checking target system type... i686-apple-darwin8.8.1 >> Canonicalised to: i386-apple-darwin >> checking for path to top of build tree... /Users/ariel/work/ghc/ghc-6.6 >> checking for ghc... no >> checking for ghc-pkg matching ... no >> checking for ghc-pkg... no >> checking whether ghc has readline package... no >> checking for nhc... no >> checking for nhc98... no >> checking for hbc... no >> configure: error: GHC is required unless bootstrapping from .hc files. >> >> Do you know what should I do to avoid this? >> > > Do you already have a binary version of GHC installed? If you want to > build GHC from source, you need a binary of GHC installed already, > like the error message suggests. (Unless you want to bootstrap from > .hc files, but I've never done that, so I don't know.) > See: > http://haskell.org/ghc/download_ghc_66.html#macosxintel > > You didn't say what version of Mac OS X you were using; if it's > anything older than 10.3, you're probably SOL. > > Cheers, > Kirsten > From igloo at earth.li Tue Feb 6 10:54:47 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue Feb 6 10:49:24 2007 Subject: ghc: out of memory error while compiling huge "let" In-Reply-To: <11f192740701120932jc4518f0o7e60f618f65a190b@mail.gmail.com> References: <11f192740701120932jc4518f0o7e60f618f65a190b@mail.gmail.com> Message-ID: <20070206155447.GA19160@matrix.chaos.earth.li> On Fri, Jan 12, 2007 at 12:32:47PM -0500, David Morse wrote: > I have a machine-generated source-code file that brings my computer to > its knees with ghc-6.6. After an hour or so of rummaging around, ghc > dies with: "ghc-6.6: out of memory (requested 1048576 bytes)". I've made a bug report at http://hackage.haskell.org/trac/ghc/ticket/1136 which is hopefully similar enough that it will cover your case too. If it's not confidential, you might like to add your example to the report too so that we can check it is really fixed when look into it. Thanks Ian From igloo at earth.li Tue Feb 6 11:35:05 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue Feb 6 11:29:51 2007 Subject: ghc 6.6 for mac os x (intel) In-Reply-To: <45C89B94.3050307@cs.utexas.edu> References: <45C6CD27.2050003@cs.utexas.edu> <4683d9370702042359q1115ea4ch38bb812f1fbed688@mail.gmail.com> <45C7E028.7000907@cs.utexas.edu> <4683d9370702052350j56b25dabt6de6df09953f34b4@mail.gmail.com> <45C89B94.3050307@cs.utexas.edu> Message-ID: <20070206163505.GB19160@matrix.chaos.earth.li> On Tue, Feb 06, 2007 at 09:15:32AM -0600, Ariel Apostoli wrote: > Kirsten Chevalier wrote: > >http://haskell.org/ghc/download_ghc_66.html#macosxintel > > but when I try installing ghc from that page it seems to install fine > but when I invoke /usr/local/bin/ghc i get: > > dyld: Library not loaded: /opt/local/lib/libreadline.5.1.dylib > Referenced from: /usr/local/lib/ghc-6.6/ghc-6.6 > Reason: image not found > Trace/BPT trap Are you using http://haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin.tar.bz2 ? I've just downloaded it, and it looks like the Makefile should run post-install-script to put readline/* in the right place. Can you check if that is happening correctly? Thanks Ian From mnislaih at gmail.com Tue Feb 6 11:45:37 2007 From: mnislaih at gmail.com (Pepe Iborra) Date: Tue Feb 6 11:40:18 2007 Subject: ghc 6.6 for mac os x (intel) In-Reply-To: <20070206163505.GB19160@matrix.chaos.earth.li> References: <45C6CD27.2050003@cs.utexas.edu> <4683d9370702042359q1115ea4ch38bb812f1fbed688@mail.gmail.com> <45C7E028.7000907@cs.utexas.edu> <4683d9370702052350j56b25dabt6de6df09953f34b4@mail.gmail.com> <45C89B94.3050307@cs.utexas.edu> <20070206163505.GB19160@matrix.chaos.earth.li> Message-ID: <8E64ADDD-2AA0-40A7-873C-1552EA212F2F@gmail.com> I can confirm that the version of ghc in MacPorts installs perfectly (on a clean system): $ sudo port install ghc On 06/02/2007, at 17:35, Ian Lynagh wrote: > On Tue, Feb 06, 2007 at 09:15:32AM -0600, Ariel Apostoli wrote: >> Kirsten Chevalier wrote: >>> http://haskell.org/ghc/download_ghc_66.html#macosxintel >> >> but when I try installing ghc from that page it seems to install fine >> but when I invoke /usr/local/bin/ghc i get: >> >> dyld: Library not loaded: /opt/local/lib/libreadline.5.1.dylib >> Referenced from: /usr/local/lib/ghc-6.6/ghc-6.6 >> Reason: image not found >> Trace/BPT trap > > Are you using > http://haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin.tar.bz2 > ? > > I've just downloaded it, and it looks like the Makefile should run > post-install-script to put readline/* in the right place. Can you > check > if that is happening correctly? > > > Thanks > Ian > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From naur at post11.tele.dk Tue Feb 6 12:15:18 2007 From: naur at post11.tele.dk (Thorkil Naur) Date: Tue Feb 6 12:10:24 2007 Subject: ghc 6.6 for mac os x (intel) In-Reply-To: <45C89B94.3050307@cs.utexas.edu> References: <45C6CD27.2050003@cs.utexas.edu> <4683d9370702052350j56b25dabt6de6df09953f34b4@mail.gmail.com> <45C89B94.3050307@cs.utexas.edu> Message-ID: <200702061815.18446.naur@post11.tele.dk> Hello, On Tuesday 06 February 2007 16:15, Ariel Apostoli wrote: > but when I try installing ghc from that page it seems to install fine > but when I invoke /usr/local/bin/ghc i get: > > dyld: Library not loaded: /opt/local/lib/libreadline.5.1.dylib > Referenced from: /usr/local/lib/ghc-6.6/ghc-6.6 > Reason: image not found > Trace/BPT trap > ... On my Mac OS X 10.4, I get the same reaction when the readline that I installed from darwin ports is deactivated. So perhaps readline isn't installed? Or is deactivated? In that case, the suggested cure is sudo port install readline (The readline that comes with Mac OS X 10.4 is no good, as noted by several.) Best regards Thorkil From apostoli at cs.utexas.edu Tue Feb 6 13:07:46 2007 From: apostoli at cs.utexas.edu (Ariel Apostoli) Date: Tue Feb 6 13:02:34 2007 Subject: ghc 6.6 for mac os x (intel) In-Reply-To: <20070206163505.GB19160@matrix.chaos.earth.li> References: <45C6CD27.2050003@cs.utexas.edu> <4683d9370702042359q1115ea4ch38bb812f1fbed688@mail.gmail.com> <45C7E028.7000907@cs.utexas.edu> <4683d9370702052350j56b25dabt6de6df09953f34b4@mail.gmail.com> <45C89B94.3050307@cs.utexas.edu> <20070206163505.GB19160@matrix.chaos.earth.li> Message-ID: <45C8C3F2.5060507@cs.utexas.edu> Hello Ian, Ian Lynagh wrote: > Are you using > http://haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin.tar.bz2 > ? > Yes. > I've just downloaded it, and it looks like the Makefile should run > post-install-script to put readline/* in the right place. Can you check > if that is happening correctly? > the post-install script is not exactly happy; here is what i get when it starts running: Running project-specific post-install script ... ==> Regenerating library archive headers... ranlib: file: /usr/local/lib/ghc-6.6/libHSX11.a(Types_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11.a(Atom_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11.a(Event_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11.a(Font_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11.a(Misc_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11.a(Types_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11_p.a(Types_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11_p.a(Atom_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11_p.a(Event_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11_p.a(Font_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11_p.a(Misc_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSX11_p.a(Types_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSbase.a(CPUTime_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSbase.a(Time_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSbase_cbits.a(timeUtils.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSbase_p.a(CPUTime_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSbase_p.a(Time_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSnetwork.a(BSD_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSnetwork.a(Socket_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSnetwork_p.a(BSD_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSnetwork_p.a(Socket_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSreadline.a(Readline_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSreadline_p.a(Readline_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSregex-posix.a(Wrap_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSregex-posix_p.a(Wrap_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Disassembler.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(FrontPanel.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(LdvProfile.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(ProfHeap.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Profiling.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Proftimer.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(RetainerProfile.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(RetainerSet.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Sanity.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(ThreadLabels.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Ticky.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(InitEachPE.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(ShutdownEachPEHook.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(0Hash.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(0Unpack.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Dist.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Global.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(GranSim.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(HLComms.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(LLComms.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Pack.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(ParInit.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(ParTicky.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(Parallel.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(ParallelDebug.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts.a(RBH.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(Disassembler.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(FrontPanel.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(Sanity.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(ThreadLabels.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(Ticky.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(InitEachPE.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(ShutdownEachPEHook.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(0Hash.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(0Unpack.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(Dist.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(Global.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(GranSim.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(HLComms.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(LLComms.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(Pack.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(ParInit.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(ParTicky.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(Parallel.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(ParallelDebug.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_p.a(RBH.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(Disassembler.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(FrontPanel.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(LdvProfile.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(ProfHeap.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(Profiling.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(Proftimer.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(RetainerProfile.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(RetainerSet.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(Sanity.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(ThreadLabels.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(Ticky.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(InitEachPE.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(ShutdownEachPEHook.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(0Hash.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(0Unpack.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(Dist.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(Global.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(GranSim.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(HLComms.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(LLComms.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(Pack.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(ParInit.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(ParTicky.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(Parallel.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(ParallelDebug.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(RBH.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr.a(Select.thr_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(Disassembler.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(FrontPanel.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(Sanity.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(ThreadLabels.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(Ticky.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(InitEachPE.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(ShutdownEachPEHook.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(0Hash.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(0Unpack.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(Dist.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(Global.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(GranSim.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(HLComms.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(LLComms.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(Pack.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(ParInit.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(ParTicky.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(Parallel.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(ParallelDebug.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(RBH.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSrts_thr_p.a(Select.thr_p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix.a(Directory_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix.a(Module_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix.a(Prim_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix.a(DynamicLinker_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix.a(Env_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix.a(Files_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix.a(IO_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix.a(Process_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix.a(Resource_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix.a(Exts_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix.a(Temp_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix.a(Terminal_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix.a(Time_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix.a(Unistd_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix.a(User_hsc.o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix_p.a(Directory_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix_p.a(Module_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix_p.a(Prim_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix_p.a(DynamicLinker_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix_p.a(Env_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix_p.a(Files_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix_p.a(IO_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix_p.a(Process_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix_p.a(Resource_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix_p.a(Exts_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix_p.a(Temp_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix_p.a(Terminal_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix_p.a(Time_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix_p.a(Unistd_hsc.p_o) has no symbols ranlib: file: /usr/local/lib/ghc-6.6/libHSunix_p.a(User_hsc.p_o) has no symbols ==> Done! Done ======================================================================= Installation of ghc-6.6 was successful. To use, add /usr/local/bin to your PATH. Warning: this binary distribution does NOT contain documentation! ======================================================================= Any ideas? Thanks again! Ariel From mattcbro at earthlink.net Tue Feb 6 13:52:05 2007 From: mattcbro at earthlink.net (SevenThunders) Date: Tue Feb 6 13:46:40 2007 Subject: Problem exporting Haskell to C via a DLL in GHC 6.6 In-Reply-To: <000301c749d1$95e761b0$0bce2950@osmet> References: <8821647.post@talk.nabble.com> <000301c749d1$95e761b0$0bce2950@osmet> Message-ID: <8831862.post@talk.nabble.com> Brian Hulley wrote: > > SevenThunders wrote: >> Before I post this as a bug, I thought I'd check to make sure I'm not >> doing something wrong. >> BOOL >> STDCALL >> DllMain >> ( HANDLE hModule >> , DWORD reason >> , void* reserved >> ) >> { >> if (reason == DLL_PROCESS_ATTACH) { >> /* By now, the RTS DLL should have been hoisted in, but we need >> to start it up. */ >> startupHaskell(1, args, __stginit_Bad); >> return TRUE; >> } >> >> if (reason == DLL_PROCESS_DETACH) { >> shutdownHaskell(); >> return TRUE; >> } >> >> return TRUE; >> } > > The above *may* be the problem: it is unsafe to do anything in DllMain > that > may involve loading a DLL, (which therefore includes a lot of the standard > platform sdk functions, some of which Haskell may need to use to > start/sthurdown) because the order in which DllMain is called when Windows > loads/unloads DLLs is undefined - see platform sdk docs for more info. > > Instead of trying to start/shutdown Haskell from DllMain, I'd export a > Begin() and End() function from the DLL and explicitly call these from > your > application's main(). > > Hope this helps, > Brian. > -- > http://www.metamilk.com > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > Interesting. Perhaps I should try that. The problem is that I found I had to add the explicit shutdown in the Dll when calling Haskell from Matlab! Apparently it would cause Matlab to crash after using the DLL. So in your scheme the Begin() would call the startupHaskell function and the End() call the shutdown Haskell? Or would the Begin initiate the linking to the specific DLL using LoadLibrary? and then End specifically unload the library; or both? Another question I have is, is it possible to create a statically linked Haskell library that can be linked using MS VC tools? Also I must say I am a bit confused about the use of the routine __stginit_Bad. Suppose I had multiple Haskell modules each with their own functions to export. Which __stginit_??? routine do I use? Thanks for the help. -- View this message in context: http://www.nabble.com/Problem-exporting-Haskell-to-C-via-a-DLL-in-GHC-6.6-tf3179123.html#a8831862 Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From catamorphism at gmail.com Tue Feb 6 14:09:30 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Tue Feb 6 14:04:06 2007 Subject: [Haskell-cafe] External Core In-Reply-To: <004b01c74a1e$2494e300$0201a8c0@4d24terminal> References: <004b01c74a1e$2494e300$0201a8c0@4d24terminal> Message-ID: <4683d9370702061109q5bae6479ofded92a8187fd15a@mail.gmail.com> On 2/6/07, Ricky Barefield wrote: > > I've tried running Happy on these files but get the error `Not enough type arguments for the type synonym "P"' when I try to run the resultant Parser.hs in Hugs and similar errors when run in GHC. > > > > What I'm trying to achieve is to read the hcr files into a Haskell data type which I could work with, if anyone could give me any help with using the files for manipulating Core I would be very grateful. > External Core isn't currently working correctly in the HEAD. Aaron Tomb was working on this, I know (as per mailing lists posts on cvs-ghc from November and December), but I don't know if he still is. glasgow-haskell-users is a better place to discuss this. Your best bet if you want to be able to use External Core may be to fix it yourself. I know that's what I had to do! But, people on glasgow-haskell-users and cvs-ghc will probably be happy to discuss it with you. Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "I saw no reason then why hell should not have, so to speak, visible branch establishments throughout the earth, and I have visited quite a few of them since."--Robertson Davies From mattcbro at earthlink.net Tue Feb 6 14:23:07 2007 From: mattcbro at earthlink.net (SevenThunders) Date: Tue Feb 6 14:17:42 2007 Subject: Problem exporting Haskell to C via a DLL in GHC 6.6 In-Reply-To: <45C85207.9080702@gmail.com> References: <8821647.post@talk.nabble.com> <45C85207.9080702@gmail.com> Message-ID: <8832467.post@talk.nabble.com> Simon Marlow-5 wrote: > > > I wonder if you're hitting this bug: > > http://hackage.haskell.org/trac/ghc/ticket/926 > > if so, it's slightly worrying that the same thing happens if you just link > your > program directly to the DLL, rather than loading it explicitly. > > Cheers, > Simon > > > No doubt it is the same bug. Moreover I think even a 'direct' link to a DLL has to call some interface code that loads the DLL in the standard way during initialization. Interestingly if I follow Brian's advice and remove the shutdownHaskell call in the dllMain routine, the 'hang' goes away. Unfortunately, however, if I do this, then whenever I use the code inside Matlab and decide to clear the mex function, the dll gets unloaded and Matlab crashes. Perhaps I can expose the unloadHaskell function in some form for use in Matlab, or perhaps I should go with the Begin() and End() approach suggested earlier. I'll have to give this some thought since I use my library both inside and outside the Matlab environment. -- View this message in context: http://www.nabble.com/Problem-exporting-Haskell-to-C-via-a-DLL-in-GHC-6.6-tf3179123.html#a8832467 Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From brianh at metamilk.com Tue Feb 6 17:39:44 2007 From: brianh at metamilk.com (Brian Hulley) Date: Tue Feb 6 17:34:23 2007 Subject: Problem exporting Haskell to C via a DLL in GHC 6.6 References: <8821647.post@talk.nabble.com><000301c749d1$95e761b0$0bce2950@osmet> <8831862.post@talk.nabble.com> Message-ID: <000901c74a3f$b86ffad0$1ede2950@osmet> SevenThunders wrote: > Brian Hulley wrote: >> SevenThunders wrote: >>> DllMain >>> if (reason == DLL_PROCESS_DETACH) { >>> shutdownHaskell(); >>> return TRUE; >>> } >> The above *may* be the problem: it is unsafe to do anything in >> DllMain that... >> >> Instead of trying to start/shutdown Haskell from DllMain, I'd export >> a Begin() and End() function from the DLL and explicitly call these >> from your application's main(). > > So in your scheme the Begin() would call the startupHaskell function > and the End() call the shutdown Haskell? Yes. > Or would the Begin initiate > the linking to the specific DLL using LoadLibrary? Since Begin would be a function exported by the DLL, Windows would ensure that the DLL was loaded when it is first called from your application if it was not already loaded so there would be no need for an explicit call to LoadLibrary. > and then End > specifically unload the library; or both? I wouldn't bother explicitly unloading the library - I'd leave this up to Windows. The importance of using an End function is that you can ensure that the call to shutdown Haskell happens at a time when all DLLs needed by Haskell are still available, whereas using DllMain to do the shutdown call is dangerous because DllMain may be invoked when some DLL necessary for Haskell to shutdown has already been unloaded by Windows. Ideally there would also be some way to call Begin/End when using the DLL from Matlab but I don't know anything about Matlab so can't help with this. A quick hack to enable you to use the DLL safely from your application (using Begin/End) as well as unsafely from Matlab (relying on DllMain to shutdown Haskell), would just be to have a flag in the DLL to keep track of whether you've already shut Haskell down. Then in the case for process_detach you could just check this so that shutdown would only be called from DllMain as a last resort. > > Another question I have is, is it possible to create a statically > linked Haskell library that can be linked using MS VC tools? Also I > must say I am a bit confused about the use of the routine > __stginit_Bad. Suppose I had multiple Haskell modules each with > their own functions to export. Which __stginit_??? routine do I use? I don't know - hopefully someone else may be able to answer this question. Best regards, Brian. -- http://www.metamilk.com From atomb at soe.ucsc.edu Tue Feb 6 19:52:01 2007 From: atomb at soe.ucsc.edu (Aaron Tomb) Date: Tue Feb 6 19:44:58 2007 Subject: [Haskell-cafe] External Core In-Reply-To: <4683d9370702061109q5bae6479ofded92a8187fd15a@mail.gmail.com> References: <004b01c74a1e$2494e300$0201a8c0@4d24terminal> <4683d9370702061109q5bae6479ofded92a8187fd15a@mail.gmail.com> Message-ID: I am still working on it. Some external events have slowed me down a little (research, classes, appendicitis), and it has involved more changes to the innards of GHC than anticipated, but it is still moving along. If you can wait a little while, it should be possible to use GHC. A slight extension of what I'm doing, which would probably be very useful, would be to export functions for working with external core from the GHC API. Aaron On Feb 6, 2007, at 11:09 AM, Kirsten Chevalier wrote: > On 2/6/07, Ricky Barefield wrote: >> >> I've tried running Happy on these files but get the error `Not >> enough type arguments for the type synonym "P"' when I try to run >> the resultant Parser.hs in Hugs and similar errors when run in GHC. >> >> >> >> What I'm trying to achieve is to read the hcr files into a Haskell >> data type which I could work with, if anyone could give me any >> help with using the files for manipulating Core I would be very >> grateful. >> > > External Core isn't currently working correctly in the HEAD. Aaron > Tomb was working on this, I know (as per mailing lists posts on > cvs-ghc from November and December), but I don't know if he still is. > > glasgow-haskell-users is a better place to discuss this. > > Your best bet if you want to be able to use External Core may be to > fix it yourself. I know that's what I had to do! But, people on > glasgow-haskell-users and cvs-ghc will probably be happy to discuss it > with you. > > Cheers, > Kirsten > > -- > Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, > never in doubt > "I saw no reason then why hell should not have, so to speak, > visible branch > establishments throughout the earth, and I have visited quite a few > of them > since."--Robertson Davies > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From rfh at reillyhayes.com Tue Feb 6 11:53:14 2007 From: rfh at reillyhayes.com (Reilly Hayes) Date: Tue Feb 6 20:30:49 2007 Subject: ghc 6.6 for mac os x (intel) In-Reply-To: <45C89B94.3050307@cs.utexas.edu> References: <45C6CD27.2050003@cs.utexas.edu> <4683d9370702042359q1115ea4ch38bb812f1fbed688@mail.gmail.com> <45C7E028.7000907@cs.utexas.edu> <4683d9370702052350j56b25dabt6de6df09953f34b4@mail.gmail.com> <45C89B94.3050307@cs.utexas.edu> Message-ID: I installed the darwin ports readline and created the following soft link: /usr/local/lib/libreadline.5.1.dylib -> /opt/local/lib/libreadline. 5.1.dylib Alternatively, you could install the darwin ports readline and set the DYLD_LIBRARY_PATH variable. I prefer not to use DYLD_LIBRARY_PATH. -reilly On Feb 6, 2007, at 7:15 AM, Ariel Apostoli wrote: > but when I try installing ghc from that page it seems to install > fine but when I invoke /usr/local/bin/ghc i get: > > dyld: Library not loaded: /opt/local/lib/libreadline.5.1.dylib > Referenced from: /usr/local/lib/ghc-6.6/ghc-6.6 > Reason: image not found > Trace/BPT trap > > > My version of mac os x is 10.4.8 > > Again thanks for your time and help so far! > > Ariel > > Kirsten Chevalier wrote: >> [redirecting to the list] >> On 2/5/07, Ariel Apostoli wrote: >>> Hello Kirsten, >>> >>> Thanks so much for your time and help so far. However, I am still >>> stuck >>> on the issue when I try to do this: >>> >>> ./configure --with-readline-includes=/usr/local \ >>> --with-readline-libraries=/usr/local >>> >>> I get: >>> checking build system type... i686-apple-darwin8.8.1 >>> checking host system type... i686-apple-darwin8.8.1 >>> checking target system type... i686-apple-darwin8.8.1 >>> Canonicalised to: i386-apple-darwin >>> checking for path to top of build tree... /Users/ariel/work/ghc/ >>> ghc-6.6 >>> checking for ghc... no >>> checking for ghc-pkg matching ... no >>> checking for ghc-pkg... no >>> checking whether ghc has readline package... no >>> checking for nhc... no >>> checking for nhc98... no >>> checking for hbc... no >>> configure: error: GHC is required unless bootstrapping from .hc >>> files. >>> >>> Do you know what should I do to avoid this? >>> >> >> Do you already have a binary version of GHC installed? If you want to >> build GHC from source, you need a binary of GHC installed already, >> like the error message suggests. (Unless you want to bootstrap from >> .hc files, but I've never done that, so I don't know.) >> See: >> http://haskell.org/ghc/download_ghc_66.html#macosxintel >> >> You didn't say what version of Mac OS X you were using; if it's >> anything older than 10.3, you're probably SOL. >> >> Cheers, >> Kirsten >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From mattcbro at earthlink.net Tue Feb 6 22:23:36 2007 From: mattcbro at earthlink.net (SevenThunders) Date: Tue Feb 6 22:18:11 2007 Subject: Problem exporting Haskell to C via a DLL in GHC 6.6 In-Reply-To: <000901c74a3f$b86ffad0$1ede2950@osmet> References: <8821647.post@talk.nabble.com> <000301c749d1$95e761b0$0bce2950@osmet> <8831862.post@talk.nabble.com> <000901c74a3f$b86ffad0$1ede2950@osmet> Message-ID: <8839209.post@talk.nabble.com> Brian Hulley wrote: > > > > Since Begin would be a function exported by the DLL, Windows would ensure > that the DLL was loaded when it is first called from your application if > it > was not already loaded so there would be no need for an explicit call to > LoadLibrary. > >> and then End >> specifically unload the library; or both? > > I wouldn't bother explicitly unloading the library - I'd leave this up to > Windows. The importance of using an End function is that you can ensure > that > the call to shutdown Haskell happens at a time when all DLLs needed by > Haskell are still available, whereas using DllMain to do the shutdown call > is dangerous because DllMain may be invoked when some DLL necessary for > Haskell to shutdown has already been unloaded by Windows. > > Ideally there would also be some way to call Begin/End when using the DLL > from Matlab but I don't know anything about Matlab so can't help with > this. > A quick hack to enable you to use the DLL safely from your application > (using Begin/End) as well as unsafely from Matlab (relying on DllMain to > shutdown Haskell), would just be to have a flag in the DLL to keep track > of > whether you've already shut Haskell down. Then in the case for > process_detach you could just check this so that shutdown would only be > called from DllMain as a last resort. > >> >> Another question I have is, is it possible to create a statically >> linked Haskell library that can be linked using MS VC tools? Also I >> must say I am a bit confused about the use of the routine >> __stginit_Bad. Suppose I had multiple Haskell modules each with >> their own functions to export. Which __stginit_??? routine do I use? > > I don't know - hopefully someone else may be able to answer this question. > > Best regards, Brian. > -- > http://www.metamilk.com > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > In the final analysis this seems to work fairly well. I export an End() function to Matlab that calls shutdownHaskell(). I then create a Matlab script that calls End() prior to clearing the DLL out of the namespace. Since it appears that shutdownHaskell() can be called again, even after it's already shut down without incident (at least from a few simple experiments) it works fairly robustly. All that needs to be done is to remember to use the Matlab script as needed. Meanwhile, it also appears I can call the same routines from inside C, letting windows do the DLL linkage, provided that shutdownHaskell() is NOT called when the DLL unloads as you indicated earlier. Thanks again for the help. -- View this message in context: http://www.nabble.com/Problem-exporting-Haskell-to-C-via-a-DLL-in-GHC-6.6-tf3179123.html#a8839209 Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From simonpj at microsoft.com Wed Feb 7 03:29:51 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Feb 7 03:24:30 2007 Subject: [Haskell-cafe] External Core In-Reply-To: References: <004b01c74a1e$2494e300$0201a8c0@4d24terminal> <4683d9370702061109q5bae6479ofded92a8187fd15a@mail.gmail.com> Message-ID: | I am still working on it. Some external events have slowed me down a | little (research, classes, appendicitis), and it has involved more | changes to the innards of GHC than anticipated, but it is still | moving along. If you can wait a little while, it should be possible | to use GHC. I'm delighted to hear it; thank you. Maybe there are others who'd like to join in? Keep me posted about those "changes to the innards" you mention! | A slight extension of what I'm doing, which would probably be very | useful, would be to export functions for working with external core | from the GHC API. Indeed, that'd be a fine thing. Simon From simonpj at microsoft.com Wed Feb 7 03:35:16 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Feb 7 03:29:55 2007 Subject: Problem exporting Haskell to C via a DLL in GHC 6.6 In-Reply-To: <8839209.post@talk.nabble.com> References: <8821647.post@talk.nabble.com> <000301c749d1$95e761b0$0bce2950@osmet> <8831862.post@talk.nabble.com> <000901c74a3f$b86ffad0$1ede2950@osmet> <8839209.post@talk.nabble.com> Message-ID: Brian, Matt | In the final analysis this seems to work fairly well. I export an End() | function to Matlab that calls | shutdownHaskell(). I then create a Matlab script that calls End() prior to | clearing the DLL out of the namespace. | Since it appears that shutdownHaskell() can be called again, even after | it's already shut down without incident (at least from a few simple | experiments) it works fairly robustly. All that needs to be done is to | remember to use the Matlab script as needed. I don't think there is any reason in principle why GHC can't generate DLLs that "just work", but plainly it's deficient at the moment. If you have now figured out what is going on, and can tell us how to improve it, do tell us. The other thing is that we could do with more "how to" documentation about GHC and DLLs. We have a bit here: http://haskell.org/haskellwiki/GHC/Using_the_FFI Could you expand it in the light of your experience? Even "here's how to make GHC play with MatLab" might be useful. Might be worth pulling out a sub-page about DLLs. I'm just keen to capture your knowledge while it's fresh! thanks Simon From simonmarhaskell at gmail.com Wed Feb 7 06:56:45 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Feb 7 06:51:32 2007 Subject: Problem exporting Haskell to C via a DLL in GHC 6.6 In-Reply-To: <8831862.post@talk.nabble.com> References: <8821647.post@talk.nabble.com> <000301c749d1$95e761b0$0bce2950@osmet> <8831862.post@talk.nabble.com> Message-ID: <45C9BE7D.6060108@gmail.com> SevenThunders wrote: > Another question I have is, is it possible to create a statically linked > Haskell library that can be linked using MS VC tools? Also I must say I am > a bit confused about the use of the routine __stginit_Bad. Suppose I had > multiple Haskell modules each with their own functions to export. Which > __stginit_??? routine do I use? For each module, you invoke this function: void hs_add_root (void (*init_root)(void)); which you can get from HsFFI.h. eg. hs_add_root(__stginit_Foo); hs_add_root(__stginit_Bar); and you do this after calling hs_init(). Cheers, Simon From atomb at soe.ucsc.edu Wed Feb 7 23:38:36 2007 From: atomb at soe.ucsc.edu (Aaron Tomb) Date: Wed Feb 7 23:31:19 2007 Subject: [Haskell-cafe] External Core In-Reply-To: References: <004b01c74a1e$2494e300$0201a8c0@4d24terminal> <4683d9370702061109q5bae6479ofded92a8187fd15a@mail.gmail.com> Message-ID: <5FD80CDD-D819-44FA-9120-C3F5259C836A@soe.ucsc.edu> On Feb 7, 2007, at 12:29 AM, Simon Peyton-Jones wrote: > | I am still working on it. Some external events have slowed me down a > | little (research, classes, appendicitis), and it has involved more > | changes to the innards of GHC than anticipated, but it is still > | moving along. If you can wait a little while, it should be possible > | to use GHC. > > I'm delighted to hear it; thank you. Maybe there are others who'd > like to join in? > > Keep me posted about those "changes to the innards" you mention! I think I made that sound scarier than it really is. :-) We talked earlier about replacing the Kind in HsTyVarBndr with a new HsKind which is to HsType as Kind is to Type. Making that change has caused ripples throughout the system, which have taken me a while to track down and fix. All of the changes are superficial (often as simple as changing type signatures), but they touch more modules than I had expected. And that means I've had to figure out the workings of a number of modules that are essentially unrelated to External Core. That, along with many distractions, has made it take me a while. I'll get the wiki page updated in the near future with the current status. Aaron From tayscristina at yahoo.com.br Thu Feb 8 07:49:03 2007 From: tayscristina at yahoo.com.br (Tays Soares) Date: Thu Feb 8 07:43:34 2007 Subject: Res: (no subject) Message-ID: <68484.1414.qm@web50602.mail.yahoo.com> Thank you everyone. I measuring my program using time unix an I going to try to use the GHC profiling too. Tays Cristina do Amaral Pales Soares ----- Mensagem original ---- De: Cristian Perfumo Para: Seth Kurtzberg Cc: Tays Soares ; glasgow-haskell-users@haskell.org Enviadas: Ter?a-feira, 6 de Fevereiro de 2007 8:21:23 Assunto: Re: (no subject) Hi Tays, If I understood correctly, if your compiler generates Haskell code, then later on you should compile this code (with GHC, for example) and running it implies a main function that is of the tipe IO() (i.e. IO Monad). What you can do is to add (it could be, for example, in debugging mode in your compiler) the code i paste below at the beginning and in the end of your main function. Well, I don't know exactly if this answers your question. If it doesn't, my apologies. Cheers Cristian import System.Time import Text.Printf { ; timeStart <- getClockTime ... your process ; timeEnd <- getClockTime ; let diff = (normalizeTimeDiff (diffClockTimes timeEnd timeStart)) ; print ((((fromIntegral(tdPicosec diff))/(10^12))) + (fromIntegral((tdSec diff) + (60 * (tdMin diff)) + (3600 * (tdHour diff))))) ; return () } On 2/6/07, Seth Kurtzberg wrote: GHC has profiling support. (By the way, many mail servers these days discard mail with no subject.) I've seen a number of papers comparing the speed of Haskell code to code of other functional languages; there is a periodic "shoot out" with ocaml. Some probably have comparisons with imperative languages, and, even if they do not, the methodology should help you. Seth Kurtzberg On Mon, 5 Feb 2007 11:28:03 -0800 (PST) Tays Soares < tayscristina@yahoo.com.br> wrote: > Hello everyone, > > I did at my master thesis a compiler that generates Haskell code. Now I need to measure the execution time of my generated code and I've been searched and I don't know if I'm looking with the wrong keywords but I could not find anything. I just need to measure the time of simple functions, like Ackermann and Fibonacci. Does anyone know how to measure the execution time of a Haskell program or function? > > Thank you, > Tays > > > > __________________________________________________ > Fale com seus amigos de gra?a com o novo Yahoo! Messenger > http://br.messenger.yahoo.com/ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users __________________________________________________ Fale com seus amigos de gra?a com o novo Yahoo! Messenger http://br.messenger.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070208/9cc10187/attachment.htm From atomb at soe.ucsc.edu Thu Feb 8 16:24:52 2007 From: atomb at soe.ucsc.edu (Aaron Tomb) Date: Thu Feb 8 16:39:12 2007 Subject: [Haskell-cafe] External Core In-Reply-To: References: <004b01c74a1e$2494e300$0201a8c0@4d24terminal> <4683d9370702061109q5bae6479ofded92a8187fd15a@mail.gmail.com> Message-ID: <3CF34527-CC31-4B44-9A64-35F63B3F3291@soe.ucsc.edu> On Feb 7, 2007, at 12:29 AM, Simon Peyton-Jones wrote: > | I am still working on it. Some external events have slowed me down a > | little (research, classes, appendicitis), and it has involved more > | changes to the innards of GHC than anticipated, but it is still > | moving along. If you can wait a little while, it should be possible > | to use GHC. > > I'm delighted to hear it; thank you. Maybe there are others who'd > like to join in? > > Keep me posted about those "changes to the innards" you mention! Now that I've had a chance to revisit this code for the first time in a while, I think I'm stuck. The difficulty comes from the change I mentioned in my previous reply: the KindedTyVar constructor in the HsTyVarBndr type used to associate a variable with a Kind. This was a quick shortcut in the past, because Haskell source doesn't contain complex kinds with variables that must be renamed and so forth. With External Core and FC's coercions, this assumption no longer holds. So, with the hope of sharing as much code as possible, I've made KindedTyVar associate each variable with an HsType (which encodes kinds similarly to how Type does in later stages). Unfortunately, some code seems to depend on kinds being in the same form throughout much of the compilation pipeline. In particular, the code for type checking type and class declarations (typecheck/ TcTyClsDecls.lhs) maintains a kind environment which I believe is constrained to contain TcTyThings (though I'm not sure about this). At the very least, this environment seems to be intended to map variables to "processed" types or kinds (Type rather than HsType, etc.). Anyway, some of the functions in TcTyClsDecls.lhs, such as kcTyClDecl, take (variable, kind) pairs out of the environment and stick them back into HsSyn things, such as the tcdTyVars field of a ClassDecl. I suspect it's possible to rewrite the type checking code to not do this, but I don't currently feel like I know enough about the intricacies of type checking full Haskell to do this. It might involve some serious changes. The only real alternative I see is to write a function that can convert fully-processed Kinds back into an HsType encoding. This seems like a nasty hack, though. Does anyone with more experience with this area of the code have any suggestions? Thanks, Aaron From atomb at soe.ucsc.edu Thu Feb 8 16:46:47 2007 From: atomb at soe.ucsc.edu (Aaron Tomb) Date: Thu Feb 8 16:39:24 2007 Subject: [Haskell-cafe] External Core In-Reply-To: References: <004b01c74a1e$2494e300$0201a8c0@4d24terminal> <4683d9370702061109q5bae6479ofded92a8187fd15a@mail.gmail.com> Message-ID: On Feb 7, 2007, at 12:29 AM, Simon Peyton-Jones wrote: > | I am still working on it. Some external events have slowed me down a > | little (research, classes, appendicitis), and it has involved more > | changes to the innards of GHC than anticipated, but it is still > | moving along. If you can wait a little while, it should be possible > | to use GHC. > > I'm delighted to hear it; thank you. Maybe there are others who'd > like to join in? > > Keep me posted about those "changes to the innards" you mention! Now that I've had a chance to revisit this code for the first time in a while, I think I'm stuck. The difficulty comes from the change I mentioned in my previous reply: the KindedTyVar constructor in the HsTyVarBndr type used to associate a variable with a Kind. This was a quick shortcut in the past, because Haskell source doesn't contain complex kinds with variables that must be renamed and so forth. With External Core and FC's coercions, this assumption no longer holds. So, with the hope of sharing as much code as possible, I've made KindedTyVar associate each variable with an HsType (which encodes kinds similarly to how Type does in later stages). Unfortunately, some code seems to depend on kinds being in the same form throughout much of the compilation pipeline. In particular, the code for type checking type and class declarations (typecheck/ TcTyClsDecls.lhs) maintains a kind environment which I believe is constrained to contain TcTyThings (though I'm not sure about this). At the very least, this environment seems to be intended to map variables to "processed" types or kinds (Type rather than HsType, etc.). Anyway, some of the functions in TcTyClsDecls.lhs, such as kcTyClDecl, take (variable, kind) pairs out of the environment and stick them back into HsSyn things, such as the tcdTyVars field of a ClassDecl. I suspect it's possible to rewrite the type checking code to not do this, but I don't currently feel like I know enough about the intricacies of type checking full Haskell to do this. It might involve some serious changes. The only real alternative I see is to write a function that can convert fully-processed Kinds back into an HsType encoding. This seems like a nasty hack, though. Does anyone with more experience with this area of the code have any suggestions? Thanks, Aaron From brianh at metamilk.com Thu Feb 8 18:07:54 2007 From: brianh at metamilk.com (Brian Hulley) Date: Thu Feb 8 18:02:13 2007 Subject: Problem exporting Haskell to C via a DLL in GHC 6.6 References: <8821647.post@talk.nabble.com><000301c749d1$95e761b0$0bce2950@osmet> <8831862.post@talk.nabble.com><000901c74a3f$b86ffad0$1ede2950@osmet> <8839209.post@talk.nabble.com> Message-ID: <000201c74bd5$f7b3a010$86e62950@osmet> Simon Peyton-Jones wrote: > I don't think there is any reason in principle why GHC can't generate > DLLs that "just work", but plainly it's deficient at the moment. The fundamental reason is that the DLL mechanism itself doesn't allow initialization/ shutdown do be hidden from the user of a DLL, because the order of loading/unloading DLLs is unspecified by the MS Windows operating system. Therefore it's not a GHC problem - it's just a fact of life with DLLs... > The other thing is that we could do with more "how to" documentation > about GHC and DLLs. We have a bit here: > http://haskell.org/haskellwiki/GHC/Using_the_FFI > Could you expand it in the light of your experience? I've added a section http://haskell.org/haskellwiki/GHC/Using_the_FFI#Beware_of_DllMain.28.29.21 which attempts to explain why init/exit code can't be put in DllMain, as well as an *untested* example to show what I meant by putting init/exit code in Begin/End functions instead. I've put a note next to the example to say that it's untested, and to appeal to anyone with more knowledge of static linking between Haskell and C to fix anything I've missed or replace with a better example. (Apologies for not testing it but static linking to stubs generated by GHC seems to require the DLL to be compiled by gcc and use of gcc on Windows seems to require Cygwin since gcc doesn't seem to understand Windows paths and I don't have Cygwin installed - unfortunately at the moment I don't have time to pursue this further.) Best regards, Brian. -- http://www.metamilk.com From simonpj at microsoft.com Fri Feb 9 04:02:18 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 9 03:56:47 2007 Subject: [Haskell-cafe] External Core In-Reply-To: References: <004b01c74a1e$2494e300$0201a8c0@4d24terminal> <4683d9370702061109q5bae6479ofded92a8187fd15a@mail.gmail.com> Message-ID: Aaron At the moment, on the way *out* of GHC, it goes like this: Core --> converted to ExternalCore --> printed to file On the way *in* we see file --> parsed to a mixture of HsSyn and IfaceSyn --> typechecked to Core This is all a bit of a (historically-derived) nonsense, as I think we discussed. And it gives rise to the problems you are seeing, because the HsSyn part has this HsTyVarBndr etc. The same intermediate data type should be used in both directions. I forget, but I think we discussed these alternatives a) using IfaceSyn in both directions b) or defining a new data type The advantage of (b) is that you can use a purpose-designed data type. But the disadvantage is that you need to write a type checker. I'd be inclined to try (a). After all, that's the way that much of the input side works already. And IfaceSyn has stuff for expressing data type declarations etc. The advantage is that all the typechecking part is already done. Does this ring any bells? Simon | -----Original Message----- | From: Aaron Tomb [mailto:atomb@soe.ucsc.edu] | Sent: 08 February 2007 21:47 | To: Simon Peyton-Jones | Cc: GHC Users Mailing List | Subject: Re: [Haskell-cafe] External Core | | | On Feb 7, 2007, at 12:29 AM, Simon Peyton-Jones wrote: | | > | I am still working on it. Some external events have slowed me down a | > | little (research, classes, appendicitis), and it has involved more | > | changes to the innards of GHC than anticipated, but it is still | > | moving along. If you can wait a little while, it should be possible | > | to use GHC. | > | > I'm delighted to hear it; thank you. Maybe there are others who'd | > like to join in? | > | > Keep me posted about those "changes to the innards" you mention! | | Now that I've had a chance to revisit this code for the first time in | a while, I think I'm stuck. From atomb at soe.ucsc.edu Fri Feb 9 12:35:06 2007 From: atomb at soe.ucsc.edu (Aaron Tomb) Date: Fri Feb 9 12:27:43 2007 Subject: [Haskell-cafe] External Core In-Reply-To: References: <004b01c74a1e$2494e300$0201a8c0@4d24terminal> <4683d9370702061109q5bae6479ofded92a8187fd15a@mail.gmail.com> Message-ID: <84F17EBA-C312-498F-8D4B-22C70FBB0930@soe.ucsc.edu> Hi, On more careful re-reading of the following email, which you sent at the beginning of December, I think perhaps you meant to say IfaceSyn where you said HsSyn? That's what got me going down the path of implementing external core with HsSyn (and a special type for external core expressions distinct from HsExpr). It seemed like a great idea at the time, but it's definitely getting hairy now that I delve into it. I think I also remember someone saying (though I can't find the email anymore) that it would be best to move away from using IfaceSyn on input, because its typechecker expects well-typed input and doesn't deal with errors nicely. Is there any intrinsic reason why it can't deal with errors better? Perhaps the best strategy is to use IfaceSyn, as before, and later, once it's working, improve the error handling in its typechecker. Anyway, using IfaceSyn in both directions (your alternative (a)) is sounding better to me at this point. I'll get to work on it. Thanks for all of the hand-holding. It's been quite helpful. Aaron > The present situation is very strange > - On output we generate a program of type ExternalCore.Module > - On input we generate a program of type HsSyn.Module > The two data types are different in almost every respect. This > seems to be asking for trouble. > > The reason we use HsSyn on input is so that we can share > typechecking code. That is a good reason in my view. > > My suggestion (without a great deal of thought) would be > > * Dump the ExternalCore datatype entirely, or at least move it to a > reference implementation in a completely separate Darcs project. > (The reference impl could read the module, perform a no-op > transformation, and print it out again.) The data type makes sense > as a way to define what ExtCore is, but it does not make sense as > part of GHC's implementation thereof, I think. > > * Use HsSyn for the output side, so that (parse (print p)) is the > identity. That means that MkExternalCore would generate HsSyn; and > PprExternalCore would print the appropriate subset of HsSyn in > ExtCore syntax. > > * It also means we'd need to add a new constructor to > HsBinds.HsBind for ExtCore bindings of form x=e; plus of course a > supporting data type HsCoreExpr for the RHS. We'd need new > typechecking code for HsCoreExpr; but the code in TcIface is really > the Wrong Thing for this -- it does not expect to find errors. > > * Be careful to specify the sub-language of HsSyn that is ExtCore > > Simon On Feb 9, 2007, at 1:02 AM, Simon Peyton-Jones wrote: > Aaron > > At the moment, on the way *out* of GHC, it goes like this: > Core --> converted to ExternalCore > --> printed to file > > On the way *in* we see > file --> parsed to a mixture of HsSyn and IfaceSyn > --> typechecked to Core > > This is all a bit of a (historically-derived) nonsense, as I think > we discussed. And it gives rise to the problems you are seeing, > because the HsSyn part has this HsTyVarBndr etc. > > The same intermediate data type should be used in both directions. > I forget, but I think we discussed these alternatives > a) using IfaceSyn in both directions > b) or defining a new data type > > The advantage of (b) is that you can use a purpose-designed data > type. But the disadvantage is that you need to write a type checker. > > I'd be inclined to try (a). After all, that's the way that much of > the input side works already. And IfaceSyn has stuff for > expressing data type declarations etc. The advantage is that all > the typechecking part is already done. > > > Does this ring any bells? > From catamorphism at gmail.com Tue Feb 13 15:15:51 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Tue Feb 13 15:10:05 2007 Subject: [Haskell] Problem compiling happy 1.15 In-Reply-To: <20070213141054.49e340ca@TheRing> References: <20070213141054.49e340ca@TheRing> Message-ID: <4683d9370702131215y18614ebfma237e18ba600774f@mail.gmail.com> [redirecting to ghc-users] On 2/13/07, Rob Hoelz wrote: > I downloaded the source for happy 1.15, and when I run make, this pops > up: > > /usr/bin/ghc -H16m -O -cpp -fglasgow-exts -O -c LALR.lhs -o LALR.o > -ohi LALR.hi > > LALR.lhs:626:34: Not in scope: `bounds' > make[3]: *** [LALR.o] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all] Error 1 > make[1]: Leaving directory `/home/rob/downloads/happy-1.15/happy' > make: *** [/home/rob/downloads/happy-1.15/happy/src/happy-inplace] > Error 2 > > After erasing hiding (bounds) in these lines: > > import Data.Array hiding (bounds) > import Array hiding (bounds) > > it does some more work, then this error pops up: > > /usr/bin/ghc -H16m -O -cpp -fglasgow-exts -O -c ProduceCode.lhs -o > ProduceCode.o -ohi ProduceCode.hi > > ProduceCode.lhs:31:20: Not in scope: `Data.Array.MArray.indices' > make[3]: *** [ProduceCode.o] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all] Error 1 > make[1]: Leaving directory `/home/rob/downloads/happy-1.15/happy' > make: *** [/home/rob/downloads/happy-1.15/happy/src/happy-inplace] > Error 2 > > Is my configuration messed up or something? > What version of ghc are you using? (/usr/bin/ghc --version) Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "I don't care too much for money/Money can't buy me TeX." -- Jason Reed From ms43 at users.sourceforge.net Tue Feb 13 15:21:31 2007 From: ms43 at users.sourceforge.net (Michael Stahl) Date: Tue Feb 13 15:29:19 2007 Subject: RFC: termination detection for STM Message-ID: <3804388.Sl1kbtWrzG@osiris> hello! last week i have implemented termination detection for the ghc runtime. my motivation was a parallel interpreter for a concurrent constraint language which i have implemented using STM. this interpreter has reached its successful final state iff none the stm transactions it has spawned make progress anymore, i.e. all threads are in state BlockedOnSTM. well, it turned out that this state is rather difficult to detect. it could be possible to use unsafePerformIO from within an atomically block with an idempotent io action such that there is some thread which counts the number of threads which are blocked on stm, but i could not come up with something that is free of race conditions. mainly this is because with stm, it is impossible to know (in haskell code) which threads are woken up by a committed stm transaction. well, there is something that would work: a wave-based distributed termination algorithm. but that would be very inefficient: every thread needs to be woken up, and there is still the issue of finding the right time to send out a detection wave: too late, and the user gets bored; too early, and there is even more overhead. of course, the ghc runtime knows which threads are woken up, so i thought it should be possible to implement the termination detection there. and also, this should be more reliable than the ugly hack i had before (a master thread with a timeout that is reset on every stm commit, by throwing an exception). so how can the ghc runtime detect termination? it is quite simple: we need to add a counter somewhere that is incremented every time a thread that is BlockedOnSTM is woken up, and decremented every time a thread goes into the BlockedOnSTM state (via retry). but just having a single counter has a drawback: it might become a scalability bottleneck. so i have extended the StgTSO struct with two fields: a counter, and a parent pointer. the parent pointer points to the TSO that spawned the thread. the counter field of a TSO counts the threads which are children of this thread (non-transitively!) and have not terminated yet. invariant: the counter is always >= 0, and == 0 iff the subtree rooted at this thread has terminated. conceptually, we have to modify the counter at the following events: - fork: the forking thread's counter is incremented the forked thread's counter is initialized to 1 - exit: the exiting thread's counter is decremented - retry: the retrying thread's counter is decremented - wakeup (stm): the counter of the woken thread is incremented increment means: add 1; if new value is 1: recursively increment parent decrement means: sub 1; if new value is 0: recursively decrement parent if there is no parent, signal termination of course, it has to be guaranteed that increments always arrive at the root before the corresponding decrements, otherwise termination may be detected prematurely. note that termination can only be signalled for a thread which has already exited, or which has called GHC.Conc.awaitTermination (described below). there are two added primitive operations: - counterDec# decrements the calling thread's counter and also sets the parent pointer to NULL (so the calling thread becomes the root of a thread tree for which termination will be detected) - counterInc# just increments the calling thread's counter (cancels the effect of counterDec) these primitives are meant to be called from a single place: awaitTermination, which is in GHC.Conc. it calls counterDec#, then waits for the exception with a delay. afterwards, it just calls counterInc#. the termination is signalled by throwing a Deadlock exception to the root of the thread tree. actually, i believe the termination condition is a livelock, but there is no constructor for that. note that there may be several independent subcomputations within a single haskell process for which termination can be detected with this approach. the main drawbacks of this code: - the locking overhead (counter updates) - because of the parent pointers, non-leaf threads will never be garbage collected if any child thread is still alive. this could be alleviated by only enabling the termination detection if the program specifically requests it, e.g. some global flag variable which is set by another primitive operation. i would welcome a review of the code; this is the first time i have hacked on ghc (and also the first non-trivial C code i have written in years), so there may be issues and interactions with other parts of the runtime that i have not anticipated. so far, i have tested it only with -threaded -debug, but it seems to work with -N32 (on a single processor, that is all i have). do you think that others might be interested in this functionality? could it be included in ghc? also, something that i really do not understand: in the counterDec# primitive, the stack_size field of the StgTSO struct is corrupted for no apparent reason, so i save it onto the stack and then restore it. none of the other primitive ops seem to do something similar. what am i doing wrong? patch is against ghc 6.6 (actually the debian package 6.6-3, but i hope those weird arm floating point endianness patches don't matter much :) ). michael stahl -- "I don't feel we did wrong in taking this great country away from them. There were great numbers of people who needed new land, and the Indians were selfishly trying to keep it for themselves." -- John Wayne -------------- next part -------------- A non-text attachment was scrubbed... Name: ghc6.6-termination-detection.patch Type: text/x-diff Size: 14594 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070213/5c8bda90/ghc6.6-termination-detection-0001.bin From catamorphism at gmail.com Tue Feb 13 15:36:10 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Tue Feb 13 15:30:26 2007 Subject: [Haskell-cafe] Strange memory consumption problems in something that should be tail-recursive In-Reply-To: <200702131527.48729.jeff@renci.org> References: <200702131527.48729.jeff@renci.org> Message-ID: <4683d9370702131236u7785b330n5e0fd1a69ff53e7e@mail.gmail.com> [redirecting to ghc-users since this is a GHC question] On 2/13/07, Jefferson Heard wrote: > Hi, I am running the following code against a 210 MB file in an attempt to > determine whether I should use alex or whether, since my needs are very > performance oriented, I should write a lexer of my own. I thought that > everything I'd written here was tail-recursive, but after compiling this with > GHC 2.4.6, and running it, I eat up 2GB of RAM in less than a second. So > far, I have tried token and character oriented Parsec parsers and alex and > alex is winning by a factor of 2. I would like to be able to tokenize the > entirety of a 1TB collection in less than 36 hours on my current machine, > which is where alex has gotten me so far. Thanks in advance! > > -- Jeff > > --- > > module Main > where > > > import qualified FileReader > import qualified Data.Set as Set > > punct = foldl (flip Set.insert) Set.empty "<,>.?/:;\"'{[}]|\\_-+=) > (*&^%$##@!~`" > > stripTagOrComment [] = [] > stripTagOrComment ('>':rest) = rest > stripTagOrCOmment (c:rest) = stripTagOrComment rest > > pass1 :: String -> String -> String > pass1 left [] = left > pass1 left ('<':right) = pass1 left (stripTagOrComment right) > pass1 left (' ':right) = pass1 left right > pass1 left (c:right) > | Set.member c punct = pass1 (' ':c:' ':left) right > | otherwise = pass1 (c:left) right > > > pass2 :: [String] -> String -> Char -> String -> [String] > pass2 left word ' ' [] = word:left > pass2 left word c [] = (c:word):left > pass2 left word ' ' (' ':right) = pass2 left word ' ' right > pass2 left word ' ' (c:right) = pass2 (word:left) "" c right > pass2 left word l (c:right) = pass2 left (l:word) c right > > tokenize = (pass2 [] "" ' ') . (pass1 []) > > main = do > file <- do FileReader.trecReadFile "trecfile" > print (tokenize (head (tail file))) > > > -- print (length (map (runParser tokenizeDoc [] "") file)) Have you tried profiling? (see section 5 of the GHC manual.) What's your GHC command line? Tail-recursion in Haskell doesn't always work the way you'd expect, but without profiling it's pretty hard to tell what the problem is. Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "Relax. I'm weird, not violent."--Brad Boesen, _Disturbed_ From catamorphism at gmail.com Tue Feb 13 17:03:43 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Tue Feb 13 16:57:56 2007 Subject: [Haskell-cafe] Strange memory consumption problems in something that should be tail-recursive In-Reply-To: <200702131551.03409.jeff@renci.org> References: <200702131527.48729.jeff@renci.org> <4683d9370702131236u7785b330n5e0fd1a69ff53e7e@mail.gmail.com> <200702131551.03409.jeff@renci.org> Message-ID: <4683d9370702131403l603d3505uf37596d456a6db1e@mail.gmail.com> On 2/13/07, Jefferson Heard wrote: > Thanks for the redirect. I haven't tried profiling yet, as I was hoping it > was obvious to the more seasoned user. In reference to your comment about > tail-recursion not working as you'd always expect, is there some document > somewhere that tells the wherefores of that? I'm using fully qualified types > and fully uncurried functions, so I wouldn't think that I should really see > this kind of recursion, coming from languages like Scheme and OCaml. Seasoned users know that nothing is obvious until you run the profiler. With that said, the discussion on haskell-cafe is good when it comes to the reasoning behind tail-recursion not working the way users of strict languages might expect. Perhaps it should be written up somewhere more permanent. But that's a point about Haskell in general. Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "Everyone's too stupid." -- _Ghost World_ From simonmarhaskell at gmail.com Wed Feb 14 05:04:32 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Feb 14 04:58:47 2007 Subject: RFC: termination detection for STM In-Reply-To: <3804388.Sl1kbtWrzG@osiris> References: <3804388.Sl1kbtWrzG@osiris> Message-ID: <45D2DEB0.2010707@gmail.com> Perhaps I'm missing something, but doesn't GHC already detect the kind of deadlock you're talking about here? When a thread is blocked and cannot be woken up, it is sent the BlockedOnDeadMVar exception. It's more precise than the extensio