February 2007 - Glasgow-haskell-users

size of snapshot archive
by Bulat Ziganshin 19 Feb '07

19 Feb '07

Hello glasgow-haskell-users, i'm tried to download newer snapshot of 6.6 and found that now it's 74 mb! why it is so large and why it's so enlarged after 6.6 release? isn't it possible to reduce size of this package? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

4 4

bad interface file - how to track error down?
by Marc Weber 19 Feb '07

19 Feb '07

How to track this error down? When not using cabal adding OldNew.hs to the include path everything is fine --- command run ------ $ rm -fr dist; cWC; cat MW/OldNew.hs; ghc --show-iface dist/build/MW/OldNew.hi; cd testapp/; cat test.hs; ghc -package mwutil --make test.hs' &> /tmp/f cWC does ./setup configure, build, install notice the cd testapp to ensure OldNew.hs is not in include path. -- output annotated in haskell style -------------- {- configuring and instaling succesfully: -} setup: No command given (try --help) setup: Warning: No license-file field. Configuring mwutil-0.1... configure: Dependency base-any: using base-2.0 configure: Dependency haskell98-any: using haskell98-1.0 configure: Using install prefix: /usr/local configure: Binaries installed in: /usr/local/bin configure: Libraries installed in: /usr/local/lib/mwutil-0.1/ghc-6.6 configure: Private binaries installed in: /usr/local/libexec configure: Data files installed in: /usr/local/share/mwutil-0.1 configure: Using compiler: /usr/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.6 configure: Using package tool: /usr/bin/ghc-pkg configure: Using ar found on system at: /usr/bin/ar configure: Using haddock found on system at: /usr/local/bin/haddock configure: No pfesetup found configure: Using ranlib found on system at: /usr/bin/ranlib configure: Using runghc found on system at: /usr/bin/runghc configure: Using runhugs found on system at: /usr/bin/runhugs configure: Using happy: /usr/bin/happy configure: Using alex: /usr/bin/alex configure: Using hsc2hs: /usr/bin/hsc2hs configure: Using c2hs: /usr/bin/c2hs configure: No cpphs found configure: Using greencard: /usr/local/bin/greencard Preprocessing library mwutil-0.1... Building mwutil-0.1... [1 of 1] Compiling MW.OldNew ( MW/OldNew.hs, dist/build/MW/OldNew.o ) /usr/bin/ar: creating dist/build/libHSmwutil-0.1.a Installing: /usr/local/lib/mwutil-0.1/ghc-6.6 & /usr/local/bin mwutil-0.1... Registering mwutil-0.1... Reading package info from ".installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. {- the file causing the error -} module MW.OldNew where data Old a = Old a data New a = New a data OldNew a = OldNew a a; unOld :: Old a -> a unOld (Old o) = o unNew :: New n -> n unNew (New n) = n a=a+1 {- output of --show-iface -} interface mwutil:MW.OldNew 1 6060 where export mwutil:MW.OldNew OldNew|{OldNew OldNew} a Old|{Old Old} New|{New New} unOld unNew module dependencies: package dependencies: base orphans: base:GHC.Base base:GHC.ForeignPtr data OldNew a Variances [(True, False)] RecFlag NonRecursive Generics: no = OldNew a a Stricts: _ _ data New a Variances [(True, False)] RecFlag NonRecursive Generics: no = New a Stricts: _ data Old a Variances [(True, False)] RecFlag NonRecursive Generics: no = Old a Stricts: _ unOld :: Old a -> a unNew :: New n -> n a :: base:GHC.Num.Integer {- the test app -} module Main where import MW.OldNew main = do print "test" {- compiling test app with -package mwutil -} [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:2:0: Bad interface file: /usr/local/lib/mwutil-0.1/ghc-6.6/MW/OldNew.hi Something is amiss; requested module mwutil-0.1:MW.OldNew differs from name found in the interface file mwutil:MW.OldNew Marc

2 1

Re: hasktags - small patch
by Lennart Kolmodin 19 Feb '07

19 Feb '07

Marc Weber wrote: > This small patch introduces a now mywords function which recognizes a::b as words a,::,b > which is what we need here (?) It does work in the above example. > > Here is the diff. Is it worth applying? > > 154c154 > < let wordlines = map words aslines > --- >> let wordlines = map mywords aslines > 161a162,174 >> -- my words is mainly copied from Data.List. >> -- difference abc::def is split into three words instead of one. >> mywords :: String -> [String] >> mywords (':':':':xs) = "::" : mywords xs >> mywords s = case dropWhile {-partain:Char.-}isSpace s of >> "" -> [] >> s' -> w : mywords s'' >> where (w, s'') = myBreak s' >> myBreak [] = ([],[]) >> myBreak (':':':':xs) = ([], "::"++xs) >> myBreak (' ':xs) = ([],xs); >> myBreak (x:xs) = let (a,b) = myBreak xs >> in (x:a,b) Without really knowing in which context this function is going to be used, expected results and so on, I've cooked up another alternative. Naturally it's possible to remove the spaces too if it's really required. let wordlines = map (groupBy (\a b -> isVarChar a == isVarChar b)) aslines isVarChar x = any ($ x) [isDigit, isAlpha, (== '_'), (== '\'')] It parses data LogInController = LogInController {rLoggedIn::R Bool, rwUserName::RWE String, rwPasswd::RWE String} as ["data"," ","LogInController"," = ","LogInController"," {","rLoggedIn","::","R"," ","Bool",", ","rwUserName","::","RWE"," ","String",", ","rwPasswd","::","RWE"," ","String","}"] Cheers, Lennart K

2 2

RFC: termination detection for STM
by Michael Stahl 16 Feb '07

16 Feb '07

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

3 6

Re: [Haskell-cafe] Strange memory consumption problems in something that should be tail-recursive
by Kirsten Chevalier 14 Feb '07

14 Feb '07

On 2/13/07, Jefferson Heard <jeff(a)renci.org> 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(a)alum.wellesley.edu *Often in error, never in doubt "Everyone's too stupid." -- _Ghost World_

1 0

Re: [Haskell-cafe] Strange memory consumption problems in something that should be tail-recursive
by Kirsten Chevalier 14 Feb '07

14 Feb '07

[redirecting to ghc-users since this is a GHC question] On 2/13/07, Jefferson Heard <jeff(a)renci.org> 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(a)alum.wellesley.edu *Often in error, never in doubt "Relax. I'm weird, not violent."--Brad Boesen, _Disturbed_

1 0

Re: [Haskell] Problem compiling happy 1.15
by Kirsten Chevalier 14 Feb '07

14 Feb '07

[redirecting to ghc-users] On 2/13/07, Rob Hoelz <hoelz(a)wisc.edu> 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(a)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

1 0

Re: [Haskell-cafe] External Core
by Kirsten Chevalier 10 Feb '07

10 Feb '07

On 2/6/07, Ricky Barefield <aca03rdb(a)sheffield.ac.uk> 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(a)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

3 7

Problem exporting Haskell to C via a DLL in GHC 6.6
by SevenThunders 09 Feb '07

09 Feb '07

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 <stdio.h> __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 <windows.h> #include <Rts.h> 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-t… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

4 9

Res: (no subject)
by Tays Soares 08 Feb '07

08 Feb '07

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 <cperfumo(a)gmail.com> Para: Seth Kurtzberg <seth(a)cql.com> Cc: Tays Soares <tayscristina(a)yahoo.com.br>; glasgow-haskell-users(a)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 <seth(a)cql.com> 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(a)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(a)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/

1 0