
Evening all... I appear to have broken hat-trans... Stephan Kahrs sent me this program to try hat-delta on, but it appears that hat barfs before I even get that far... lappybob:~/Documents/Work/Hat test cases/Hell Sort tatd2$ hmake -hat hellSort hat-trans hellSort.hs Creating directories Hat Wrote Hat/hellSort.hs ghc -c -package hat -o Hat/hellSort.o Hat/hellSort.hs ghc -package hat -o hellSort Hat/hellSort.o lappybob:~/Documents/Work/Hat test cases/Hell Sort tatd2$ ./hellSort [6,4,2,9,10,9,3]
[2,3,4,6,9,10,9] ^CKilled lappybob:~/Documents/Work/Hat test cases/Hell Sort tatd2$ hat-detect hellSort hat-detect (error): file hellSort.hat is too short lappybob:~/Documents/Work/Hat test cases/Hell Sort tatd2$ hat-check hellSort hat-check (error): file hellSort.hat is too short
Begin forwarded message:
From: "S.M.Kahrs"
Date: 16 September 2005 15:34:07 BDT To: tatd2@kent.ac.uk Cc: S.M.Kahrs@kent.ac.uk Subject: buggy sorting function The sorting function is called 'treesort'.
module Main where {- Ulrich Furbach, Lothar Schmitz -}
treesort :: Ord a => [a] -> [a] treesort = sort . establish
establish f = eaux (length f) ((0,[1]),f)
eaux n a@((u,ss),f) = let sm = head ss sm1 = ss !! 1 sm2 = ss !! 2 in if u==n-1 then ((u,ss),siftav a) else if u>=sm && sm == pre sm1 then eaux n ((u+1,((sm+sm1 +1):drop 2 ss)),siftbin((u,sm),f)) else if n-u>=pre sm then eaux n((u+1,1:ss),siftbin((u,sm),f)) else eaux n((u+1,1:ss), siftav((u,ss),f))
sort ((u,ss),f) = if u==0 then take 1 f else sort (rearrange((u,ss),f)) ++ [f !! u]
rearrange((u,sm:ss),f) = if sm==1 then ((u-1,ss),f) else ((u-1,tt),siftsp((u-1,tt),siftsp((u-1-tlast,tt0),f))) where tt0 = t1: ss tt = tlast: tt0 (tlast,t1)=preaux sm 0 1 1 sm1 = ss !! 0 sm2 = ss !! 1
siftsp ((u,ss),f) = let sm = head ss sm1 = ss !! 1 sm2 = ss !! 2 m = length ss in if m==1 || (f !! (u-sm)) <= (f !! u) then f else siftav ((u-sm,tail ss),swap f (u-sm)u)
siftav((u,ss),f) = if u
siftbin ((u,s),f) = if s==1 || (f !! g)<=(f!! u) then f else siftbin((g,sg),swap f g u) where (p2,p1)=preaux s 0 1 1 (g,sg)= if (f !! (u-1))<= (f !!(u-1-p2)) then (u-1-p2,p1) else (u-1,p2)
swap :: [a] -> Int -> Int -> [a] swap xs i j = if i>j then swap' xs j i else swap' xs i j swap' :: [a] -> Int -> Int -> [a] swap' xs i j = {- i
pre n = snd (preaux n 0 1 1)
preaux n a b c = if n<=c then (a,b) else preaux n b c (b+c+1)
tsort :: [Int] -> [Int] tsort = treesort
main = do putStr "> " xs <- getLine if null xs then return () else ( print (tsort (read xs))) >> main

Thomas Davie wrote:
$ ./hellSort [6,4,2,9,10,9,3]
[2,3,4,6,9,10,9] ^CKilled lappybob:~/Documents/Work/Hat test cases/Hell Sort tatd2$ hat-detect hellSort hat-detect (error): file hellSort.hat is too short
When you hit ^C (once?) did you wait for the .hat file to be patched up after the signal was caught? Colin

On 16 Sep 2005, at 16:01, Colin Runciman wrote:
Thomas Davie wrote:
$ ./hellSort [6,4,2,9,10,9,3]
[2,3,4,6,9,10,9]
^CKilled lappybob:~/Documents/Work/Hat test cases/Hell Sort tatd2$ hat-detect hellSort hat-detect (error): file hellSort.hat is too short
When you hit ^C (once?) did you wait for the .hat file to be patched up after the signal was caught?
I didn't, this is a ghc on Mac bug -- ctrl-C doesn't work, you have to send it a kill -9 from elsewhere... I just forgot that. So is the likely cause that the file had not been flushed to disk? Bob

Bob,
When you hit ^C (once?) did you wait for the .hat file to be patched up after the signal was caught?
I didn't, this is a ghc on Mac bug -- ctrl-C doesn't work, you have to send it a kill -9 from elsewhere... I just forgot that. So is the likely cause that the file had not been flushed to disk?
It is more than just flushing an ordinary file buffer. Hat has its own fancy buffering system to minimise the number of updates to the trace file. Further, the trace has to be updated so that all expressions in mid-evaluation have "interrupted" as their result, and the trace must record the point of interruption. None of this can happen after a violent "kill -9". The program just stops dead. So does the trace. Hence the complaint from the trace-processing tools. Colin

Thomas Davie
lappybob$ ./hellSort [6,4,2,9,10,9,3]
[2,3,4,6,9,10,9] ^CKilled
This looks like a problem straight-away. The "Killed" message indicates that your OS is killing the program and truncating the trace file, whereas the ^C signal ought to be caught nicely, allowing the program to finish flushing the trace file to disc.
hat-detect (error): file hellSort.hat is too short
Yup, looks like the trace file was incompletely written to disc. In the given example program, you don't actually need to ^C it - just give it a blank line as input and it should terminate normally. Given that, I was able to use hat-observe and hat-trail successfully, but the current CVS versions of hat-detect and hat-check are slightly broken (they don't deal correctly with DoLambda 0x5). Regards, Malcolm

On 16 Sep 2005, at 16:09, Malcolm Wallace wrote:
Thomas Davie
writes: lappybob$ ./hellSort [6,4,2,9,10,9,3]
[2,3,4,6,9,10,9]
^CKilled
This looks like a problem straight-away. The "Killed" message indicates that your OS is killing the program and truncating the trace file, whereas the ^C signal ought to be caught nicely, allowing the program to finish flushing the trace file to disc.
hat-detect (error): file hellSort.hat is too short
Yup, looks like the trace file was incompletely written to disc.
In the given example program, you don't actually need to ^C it - just give it a blank line as input and it should terminate normally. Oops... dumb bob...
Given that, I was able to use hat-observe and hat-trail successfully, but the current CVS versions of hat-detect and hat-check are slightly broken (they don't deal correctly with DoLambda 0x5).
I'm working with my new version of hat-detect (although not of hat- check). I knew it would be something obvious, thanks people :) Bob

Given that, I was able to use hat-observe and hat-trail successfully, but the current CVS versions of hat-detect and hat-check are slightly broken (they don't deal correctly with DoLambda 0x5).
Can you tell me what the structure of DoLambda is so that I can update NodeExp.hs to deal with it... hat-check says it has no pointers except for source position, and parent... But I'm guessing that's rubbish as you said hat-check doesn't deal with it right, and there doesn't appear to be any way to get to the rest of the trace if that is true. Bob

Thomas Davie
but the current CVS versions of hat-detect and hat-check are slightly broken (they don't deal correctly with DoLambda 0x5).
Can you tell me what the structure of DoLambda is so that I can update NodeExp.hs to deal with it... hat-check says it has no pointers except for source position, and parent...
'DoLambda' is not an expression. It is a specially distinguished kind of FileNode like so: Root 0x0 Unevaluated 0x1 Entered 0x2 Interrupted 0x3 Lambda 0x4 DoLambda 0x5 See include/art.h and src/hattools/LowLevel.hs. I think it can appear anywhere a "Ref Atom" would be valid, e.g. as the 'value' field of an ExpValueUse. Regards, Malcolm
participants (4)
-
Colin Runciman
-
Malcolm Wallace
-
Thomas Davie
-
Thomas Davie