From maeder at tzi.de Wed May 2 13:31:32 2007 From: maeder at tzi.de (Christian Maeder) Date: Wed, 02 May 2007 13:31:32 +0200 Subject: [Hets-devel] Candidates for Common.Utils ? In-Reply-To: <20070421154613.GA25416@cspcag2.swan.ac.uk> References: <20070421154613.GA25416@cspcag2.swan.ac.uk> Message-ID: <46387694.8040302@tzi.de> Andy Gimblett schrieb: > Hi there, > > I've written a couple of functions which, it seems to me, might be > candidates for Common.Utils since they're quite generally applicable > and don't really "belong" in the module in which they're currently > defined. However, before I modify any modules outside of my > safe & friendly CspCASL-land, I thought I'd check if > > a) this kind of thing is desirable; > > b) the functions seem reasonable. principally yes. Recently I've cleaned up that module, because it was used all over the place for various (partly disjoint) purposes. > They are: > > -- | A function inspired by python's string.split(). A list is split > -- on a separator which is itself a list (not a single element). > split :: Eq a => [a] -> [a] -> [[a]] > split tok splitme = unfoldr (sp1 tok) splitme > where sp1 _ [] = Nothing > sp1 t s = case find (t `isSuffixOf`) $ (inits s) of > Nothing -> Just (s, []) > Just p -> Just (take (length p - length t) p, > drop (length p) s) I cannot see how efficient your implementation is. Furthermore, it would be nice if "length" could be avoided. http://haskell.org/haskellwiki/ThingsToAvoid#Don.27t_ask_for_the_length_of_a_list.2C_if_you_don.27t_need_it There was also a long discussion about splitBy under: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/13580 It would be nice if "splitOn c = split [c]" and splitOn remained (almost) just as efficient. > > -- | String strip in style of python string.strip() > strip :: String -> String > strip s = dropWhile ws $ reverse $ dropWhile ws $ reverse s > where ws = (`elem` [' ', '\n', '\t', '\r']) I have a similar function in Isabelle.IsaProve that I've kept local: strip = takeWhile (not . isSpace) . dropWhile isSpace So you my decide yourself what to do. (Beware of name clashes, though). > > Examples: > > *Main> split ", " "one, two, three, four" > ["one","two","three","four"] for this "split ','" seems more appropriate (stripping spaces before or afterwards) > > *Main> split "an" "banana" > ["b","","a"] > > *Main> split [2,3] [1,2,3,4,3,2,1,2,3,4] > [[1],[4,3,2,1],[4]] Do you really need this generality? If so, then add your (or an improved) version to Common.Utils. Cheers Christian From maeder at tzi.de Thu May 3 13:33:53 2007 From: maeder at tzi.de (Christian Maeder) Date: Thu, 03 May 2007 13:33:53 +0200 Subject: [Hets-devel] hets-trac passwords Message-ID: <4639C8A1.1090008@tzi.de> Hi, due to a spam attack, I've removed the passwords for those accounts who also get this message by a blind copy (or who can no longer log in). In order to reactivate your account, please send me an encrypted password using htdigest (or htdigest2) with realm "hets-trac". See below how I created the password for user "test". Do not use your username as password! Cheers Christian maeder at denebola:~> /usr/sbin/htdigest2 Usage: htdigest [-c] passwordfile realm username The -c flag creates a new file. maeder at denebola:~> /usr/sbin/htdigest2 -c test hets-trac test Adding password for test in realm hets-trac. New password: Re-type new password: maeder at denebola:~> cat test test:hets-trac:77ec044fa920acb52260af38646c7029 (I've used test as password, too, in this example) From Till.Mossakowski at dfki.de Sun May 6 22:41:14 2007 From: Till.Mossakowski at dfki.de (Till Mossakowski) Date: Sun, 06 May 2007 22:41:14 +0200 Subject: [Hets-devel] cvs and trac server down Message-ID: <463E3D6A.1050608@dfki.de> Dear Hetters, due to a fire in our new Cartesium buildung, both the hets cvs server and the trac server are down. Hopefully, the problem will be fixed on Monday afternoon. Greetings, Till -- Till Mossakowski Office: Phone +49-421-218-64226 DFKI Lab Bremen Cartesium Fax +49-421-218-9864226 Robert-Hooke-Str. 5 Enrique-Schmidt-Str. 5 Till.Mossakowski at dfki.de D-28359 Bremen Room 2.051 http://www.dfki.de/sks/till Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH principal office, *not* the address for mail etc.!!!: Trippstadter Str. 122, D-67663 Kaiserslautern management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff supervisory board: Prof. Hans A. Aukes (chair) Amtsgericht Kaiserslautern, HRB 2313 From Till.Mossakowski at dfki.de Mon May 7 14:44:31 2007 From: Till.Mossakowski at dfki.de (Till Mossakowski) Date: Mon, 07 May 2007 14:44:31 +0200 Subject: [Hets-devel] cvs server works again Message-ID: <463F1F2F.8000701@dfki.de> Dear Hetters, the Hets cvs server works again. Trac still does not work, but I hope that this will be fixed soon as well. Greetings, Till -- Till Mossakowski Office: Phone +49-421-218-64226 DFKI Lab Bremen Cartesium Fax +49-421-218-9864226 Robert-Hooke-Str. 5 Enrique-Schmidt-Str. 5 Till.Mossakowski at dfki.de D-28359 Bremen Room 2.051 http://www.dfki.de/sks/till Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH principal office, *not* the address for mail etc.!!!: Trippstadter Str. 122, D-67663 Kaiserslautern management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff supervisory board: Prof. Hans A. Aukes (chair) Amtsgericht Kaiserslautern, HRB 2313 From Till.Mossakowski at dfki.de Mon May 7 15:50:04 2007 From: Till.Mossakowski at dfki.de (Till Mossakowski) Date: Mon, 07 May 2007 15:50:04 +0200 Subject: [Hets-devel] Trac is working again Message-ID: <463F2E8C.9040208@dfki.de> Dear Hetters, now also trac is working again as usual. Sorry for any inconvenieces caused by the temporary failures. Greetings, Till -- Till Mossakowski Office: Phone +49-421-218-64226 DFKI Lab Bremen Cartesium Fax +49-421-218-9864226 Robert-Hooke-Str. 5 Enrique-Schmidt-Str. 5 Till.Mossakowski at dfki.de D-28359 Bremen Room 2.051 http://www.dfki.de/sks/till Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH principal office, *not* the address for mail etc.!!!: Trippstadter Str. 122, D-67663 Kaiserslautern management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff supervisory board: Prof. Hans A. Aukes (chair) Amtsgericht Kaiserslautern, HRB 2313 From luecke at informatik.uni-bremen.de Mon May 7 16:12:06 2007 From: luecke at informatik.uni-bremen.de (Dominik Luecke) Date: Mon, 07 May 2007 16:12:06 +0200 Subject: [Hets-devel] MathServ Message-ID: <463F33B6.5010404@informatik.uni-bremen.de> Hello, the MathServ-Services for Hets are available again, too. Regards, Dominik -- Dominik Luecke Phone +49-421-218-64265 Dept. of Computer Science Fax +49-421-218-9864265 University of Bremen luecke at tzi.de P.O.Box 330440, D-28334 Bremen PGP-Key ID 0x2D82571B From maeder at tzi.de Tue May 8 15:19:05 2007 From: maeder at tzi.de (Christian Maeder) Date: Tue, 08 May 2007 15:19:05 +0200 Subject: [Hets-devel] problems using ghc-6.6.1 Message-ID: <464078C9.2080100@tzi.de> Dear Hets- and GHC-Developers, we have a problem using ghc-6.6.1. The created hets binary runs a couple of times slower than the one created using ghc-6.6. (see below) What might be the cause for this? Cheers Christian ghc-6.6.1: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 1979.05 secs (39581 ticks @ 50 ms) total alloc = 167,752,167,576 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc selectProofBasis Proofs.EdgeUtils 82.8 86.1 sl_sign CASL.Sublogic 5.3 3.7 compInclusion Logic.Grothendieck 3.2 3.2 getAllPathsOfTypesBetween Proofs.EdgeUtils 1.5 1.6 isSubOpMap CASL.Sign 1.2 0.9 primCoerce Logic.Coerce 0.8 1.1 ghc-6.6: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 215.25 secs (4305 ticks @ 50 ms) total alloc = 20,691,103,008 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc selectProofBasis Proofs.EdgeUtils 73.1 79.6 sl_sign CASL.Sublogic 6.8 4.2 compInclusion Logic.Grothendieck 3.7 3.8 getAllPathsOfTypesBetween Proofs.EdgeUtils 2.8 3.1 isSubOpMap CASL.Sign 1.6 1.1 sublogics_join CASL.Sublogic 1.5 1.1 primCoerce Logic.Coerce 1.3 1.4 isSameTranslation Proofs.Local 1.2 0.9 From maeder at tzi.de Tue May 8 23:33:28 2007 From: maeder at tzi.de (Christian Maeder) Date: Tue, 08 May 2007 23:33:28 +0200 Subject: [Hets-devel] problems using ghc-6.6.1 (due to fgl-5.4.1) Message-ID: <4640ECA8.5040704@tzi.de> I wrote: > Dear Hets- and GHC-Developers, > we have a problem using ghc-6.6.1. The created hets binary runs a > couple > of times slower than the one created using ghc-6.6. This problem is gone when I install and use fgl-5.3 (where "hiding (indices)" needs to be deleted in Data.Graph.Inductive.Monad.IOArray). I strongly suspect the new functions context1l' and context4l' in Data.Graph.Inductive.Graph (fgl-5.4.1) to be the reason for our drastic slow down. In fgl-5.3 the functions fst4 and fth4 have been used instead. A cyclic edge (an edge from and to the very same node) was only returned as ingoing edge and not as outgoing one. (a design decision documented elsewhere). I think, the change in fgl-5.4.1 now returns a cyclic edge also as outgoing edge (and possibly twice as ingoing one). Our application heavily uses in- and outgoing edges that may be cyclic. Christian P.S. ghc-6.6.1/libraries/fgl/Setup.hs does not compile with ghc-6.6.1 From maeder at tzi.de Wed May 9 14:26:05 2007 From: maeder at tzi.de (Christian Maeder) Date: Wed, 09 May 2007 14:26:05 +0200 Subject: [Hets-devel] fgl-5.4.1 In-Reply-To: <4640ECA8.5040704@tzi.de> References: <4640ECA8.5040704@tzi.de> Message-ID: <4641BDDD.4090006@tzi.de> I have adopted our sources now so that they also work with fgl-5.4.1. So neither ghc-6.6.1 nor fgl-5.4.1 need to change. The problem was that "inn" returns loops since fgl-5.4, that led to more edges to be processed (by our function selectProofBasis). Another problem (not relevant for our performance loss, though) is that "inn" and "out" both return the same loops, which may lead to a duplication of loops if reinserted. Further technical comments below. Christian Christian Maeder schrieb: > I wrote: >> Dear Hets- and GHC-Developers, > >> we have a problem using ghc-6.6.1. The created hets binary runs a >> couple >> of times slower than the one created using ghc-6.6. > > This problem is gone when I install and use fgl-5.3 (where "hiding > (indices)" needs to be deleted in Data.Graph.Inductive.Monad.IOArray). > > I strongly suspect the new functions context1l' and context4l' in > Data.Graph.Inductive.Graph (fgl-5.4.1) to be the reason for our drastic > slow down. > > In fgl-5.3 the functions fst4 and fth4 have been used instead. A cyclic > edge (an edge from and to the very same node) was only returned as > ingoing edge and not as outgoing one. (a design decision documented > elsewhere). > > I think, the change in fgl-5.4.1 now returns a cyclic edge also as > outgoing edge (and possibly twice as ingoing one). Exchange in- and outgoing (and cyclic edge with loop). The loops are not duplicated by a single call. Just the function matchGr (method match) from Data.Graph.Inductive.Tree returns the loops as successors only. (Therefore the filtering in context4l' might be just unnecessary for this instance) context1l' :: Context a b -> Adj b context1l' (p,v,_,s) = p++filter ((==v).snd) s context4l' :: Context a b -> Adj b context4l' (p,v,_,s) = s++filter ((==v).snd) p From maeder at tzi.de Thu May 10 12:47:03 2007 From: maeder at tzi.de (Christian Maeder) Date: Thu, 10 May 2007 12:47:03 +0200 Subject: [Hets-devel] problems using ghc-6.6.1 (due to fgl-5.4.1) In-Reply-To: References: <4640ECA8.5040704@tzi.de> Message-ID: <4642F827.90106@tzi.de> Dear Simons, your replies to my mails did not turn up on our hets-devel list (gmane.comp.lang.hets.devel). Did you get any problem report when sending to hets-devel at tzi.de (or didn't you sent to this address)? Thanks Christian Simon Peyton-Jones schrieb: > Aha! So the problem is a library change rather than a compiler change. That's a relief. > > Simon > From simonpj at microsoft.com Tue May 8 18:46:25 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue, 8 May 2007 17:46:25 +0100 Subject: [Hets-devel] problems using ghc-6.6.1 In-Reply-To: <464078C9.2080100@tzi.de> References: <464078C9.2080100@tzi.de> Message-ID: Eight times slower! That's a serious performance bug. Darn. Are you sure you compiled both with the same flags (e.g. -O)? Maybe doing -ddump-simpl and looking at the code for selectProofBasis (where most of the time goes) would be illuminating. If you can't narrow it down any more, then I suppose you'll have to send us the entire code base to reproduce it... but I hope you can Simon | -----Original Message----- | From: glasgow-haskell-users-bounces at haskell.org [mailto:glasgow-haskell-users-bounces at haskell.org] On | Behalf Of Christian Maeder | Sent: 08 May 2007 14:19 | To: hets-devel at tzi.de; GHC Users Mailing List | Subject: problems using ghc-6.6.1 | | Dear Hets- and GHC-Developers, | | we have a problem using ghc-6.6.1. The created hets binary runs a couple | of times slower than the one created using ghc-6.6. (see below) | | What might be the cause for this? | | Cheers Christian | | | ghc-6.6.1: | hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl | | total time = 1979.05 secs (39581 ticks @ 50 ms) | total alloc = 167,752,167,576 bytes (excludes profiling overheads) | | COST CENTRE MODULE %time %alloc | | selectProofBasis Proofs.EdgeUtils 82.8 86.1 | sl_sign CASL.Sublogic 5.3 3.7 | compInclusion Logic.Grothendieck 3.2 3.2 | getAllPathsOfTypesBetween Proofs.EdgeUtils 1.5 1.6 | isSubOpMap CASL.Sign 1.2 0.9 | primCoerce Logic.Coerce 0.8 1.1 | | | ghc-6.6: | hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl | | total time = 215.25 secs (4305 ticks @ 50 ms) | total alloc = 20,691,103,008 bytes (excludes profiling overheads) | | COST CENTRE MODULE %time %alloc | | selectProofBasis Proofs.EdgeUtils 73.1 79.6 | sl_sign CASL.Sublogic 6.8 4.2 | compInclusion Logic.Grothendieck 3.7 3.8 | getAllPathsOfTypesBetween Proofs.EdgeUtils 2.8 3.1 | isSubOpMap CASL.Sign 1.6 1.1 | sublogics_join CASL.Sublogic 1.5 1.1 | primCoerce Logic.Coerce 1.3 1.4 | isSameTranslation Proofs.Local 1.2 0.9 | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Wed May 9 09:13:25 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed, 9 May 2007 08:13:25 +0100 Subject: [Hets-devel] problems using ghc-6.6.1 (due to fgl-5.4.1) In-Reply-To: <4640ECA8.5040704@tzi.de> References: <4640ECA8.5040704@tzi.de> Message-ID: Aha! So the problem is a library change rather than a compiler change. That's a relief. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces at haskell.org [mailto:glasgow-haskell-users-bounces at haskell.org] On | Behalf Of Christian Maeder | Sent: 08 May 2007 22:33 | To: hets-devel at tzi.de; GHC Users Mailing List; libraries at haskell.org | Subject: problems using ghc-6.6.1 (due to fgl-5.4.1) | | I wrote: | > Dear Hets- and GHC-Developers, | | > we have a problem using ghc-6.6.1. The created hets binary runs a | > couple | > of times slower than the one created using ghc-6.6. | | This problem is gone when I install and use fgl-5.3 (where "hiding | (indices)" needs to be deleted in Data.Graph.Inductive.Monad.IOArray). | | I strongly suspect the new functions context1l' and context4l' in | Data.Graph.Inductive.Graph (fgl-5.4.1) to be the reason for our drastic | slow down. | | In fgl-5.3 the functions fst4 and fth4 have been used instead. A cyclic | edge (an edge from and to the very same node) was only returned as | ingoing edge and not as outgoing one. (a design decision documented | elsewhere). | | I think, the change in fgl-5.4.1 now returns a cyclic edge also as | outgoing edge (and possibly twice as ingoing one). | | Our application heavily uses in- and outgoing edges that may be cyclic. | | Christian | | P.S. ghc-6.6.1/libraries/fgl/Setup.hs does not compile with ghc-6.6.1 | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonmarhaskell at gmail.com Wed May 9 10:51:47 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed, 09 May 2007 09:51:47 +0100 Subject: [Hets-devel] problems using ghc-6.6.1 In-Reply-To: <464078C9.2080100@tzi.de> References: <464078C9.2080100@tzi.de> Message-ID: <46418BA3.9000100@gmail.com> Christian Maeder wrote: > Dear Hets- and GHC-Developers, > > we have a problem using ghc-6.6.1. The created hets binary runs a couple > of times slower than the one created using ghc-6.6. (see below) > > What might be the cause for this? Very strange. The performance has decreased dramatically, but the profile looks the same: that is, performance has degraded more or less consistently across the whole code. I have to ask: did you turn on -O? Cheers, Simon > Cheers Christian > > > ghc-6.6.1: > hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl > > total time = 1979.05 secs (39581 ticks @ 50 ms) > total alloc = 167,752,167,576 bytes (excludes profiling overheads) > > COST CENTRE MODULE %time %alloc > > selectProofBasis Proofs.EdgeUtils 82.8 86.1 > sl_sign CASL.Sublogic 5.3 3.7 > compInclusion Logic.Grothendieck 3.2 3.2 > getAllPathsOfTypesBetween Proofs.EdgeUtils 1.5 1.6 > isSubOpMap CASL.Sign 1.2 0.9 > primCoerce Logic.Coerce 0.8 1.1 > > > ghc-6.6: > hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl > > total time = 215.25 secs (4305 ticks @ 50 ms) > total alloc = 20,691,103,008 bytes (excludes profiling overheads) > > COST CENTRE MODULE %time %alloc > > selectProofBasis Proofs.EdgeUtils 73.1 79.6 > sl_sign CASL.Sublogic 6.8 4.2 > compInclusion Logic.Grothendieck 3.7 3.8 > getAllPathsOfTypesBetween Proofs.EdgeUtils 2.8 3.1 > isSubOpMap CASL.Sign 1.6 1.1 > sublogics_join CASL.Sublogic 1.5 1.1 > primCoerce Logic.Coerce 1.3 1.4 > isSameTranslation Proofs.Local 1.2 0.9 > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From till at tzi.de Thu May 10 14:47:34 2007 From: till at tzi.de (Till Mossakowski) Date: Thu, 10 May 2007 14:47:34 +0200 Subject: [Hets-devel] problems using ghc-6.6.1 (due to fgl-5.4.1) In-Reply-To: <4642F827.90106@tzi.de> References: <4640ECA8.5040704@tzi.de> <4642F827.90106@tzi.de> Message-ID: <46431466.9020209@tzi.de> As the mailling list admin, I got some reports because the Simons are not subscribed. However, they were caught by Spamassassin. I have now let the mails through. Till Christian Maeder schrieb: > Dear Simons, > > your replies to my mails did not turn up on our hets-devel list > (gmane.comp.lang.hets.devel). Did you get any problem report when > sending to hets-devel at tzi.de (or didn't you sent to this address)? > > Thanks Christian > > Simon Peyton-Jones schrieb: >> Aha! So the problem is a library change rather than a compiler change. That's a relief. >> >> Simon >> > From luecke at informatik.uni-bremen.de Tue May 15 16:54:17 2007 From: luecke at informatik.uni-bremen.de (Dominik Luecke) Date: Tue, 15 May 2007 16:54:17 +0200 Subject: [Hets-devel] Conservativity Checking Message-ID: <4649C999.6010801@informatik.uni-bremen.de> Hello, I have added the environment variable HETS_APROVE to Hets for calling the tool AProVE during consitency checking. This variable should diretcly point to the .jar-File of AProVE, so it should look like e.g.: export HETS_APROVE=/home/luecke/Hets/HetCATS/CASL/Termination/AProVE.jar Regards, Dominik -- Dominik Luecke Phone +49-421-218-64265 Dept. of Computer Science Fax +49-421-218-9864265 University of Bremen luecke at tzi.de P.O.Box 330440, D-28334 Bremen PGP-Key ID 0x2D82571B From maeder at tzi.de Tue May 22 12:05:35 2007 From: maeder at tzi.de (Christian Maeder) Date: Tue, 22 May 2007 12:05:35 +0200 Subject: [Hets-devel] switched to ghc-6.6.1 Message-ID: <4652C06F.6080407@tzi.de> Dear ghc users, I've switched to ghc-6.6.1 as new default compiler on our central server denebola. (mirrors may notice this change tomorrow.) For this version I've installed the packages (needed for hets) HTTP-2006.7.7, HaXml-1.13.2, Shellac-0.9, Shellac-readline-0.9, WashNGo-2.10 and hxt-7.1. HTTP-2006.7.7 is different from the official version in that it additionally exposes the module Network.HTTP.Base64. You can check this using: ghc-pkg list ghc-pkg describe HTTP Furthermore a compiled uni directory can be linked to from /home/linux-bkb/uni/linux-ghc-6.6.1/uni. I've moved it from /home/cofi/uni to /home/linux-bkb/uni to get a copy on my laptop with "update". (If "update" fails for you, I might remove ghc-6.4.2 (again).) ghc-6.6.1 has mainly bugfixes vs. ghc-6.6. ghc-6.6.1 might be a bit slower and might produce bigger binaries, though. ghc-6.6.1 has a new package "filepath" that will help to become more independent from the underlying OS. (So don't mess around with slashes in the future.) ghc-6.6.1 needs a dynamic gmp library that is usually available (under /usr/lib/libgmp.*) on our linux machines except for some math-machines. I've copied this library to /home/linux-bkb/ghc/libgmp.so.3.3.3. So if you need it, set links libgmp.so.3 and libgmp.so to it, and tell LD_LIBRARY_PATH where these links can be found, ie: export LD_LIBRARY_PATH=~/lib The old ghc-6.6 version can still be used (for a while) by setting the path (in ~/.bashrc) to it: export PATH=/home/linux-bkb/ghc/ghc-6.6/bin:$PATH happy hacking Christian P.S. our daily hets versions are already produced by ghc-6.6.1 From luecke at informatik.uni-bremen.de Fri May 25 17:21:44 2007 From: luecke at informatik.uni-bremen.de (Dominik Luecke) Date: Fri, 25 May 2007 17:21:44 +0200 Subject: [Hets-devel] Changes in UNI Message-ID: <4656FF08.5050903@informatik.uni-bremen.de> Hello, the jumpy behaviour of the goals list in the prove window has been fixed by Rainer. Unfortunately this needed some changes on uni. If you did not check out a new version of uni and compile it, please do so. Regards, Dominik -- Dominik Luecke Phone +49-421-218-64265 Dept. of Computer Science Fax +49-421-218-9864265 University of Bremen luecke at tzi.de P.O.Box 330440, D-28334 Bremen PGP-Key ID 0x2D82571B