- Glasgow-haskell-users

RE: Simplifier output explanation needed
by Simon Peyton-Jones 07 Jun '05

07 Jun '05

Yes $s is for specialised versions of (usually overloaded) functions. If you are using -02 you can also get specialised versions from so-called constructor specialisation, when the function is specialised for a particular argument pattern. I don't know why the strictness annotations disappear, but the specialised function probably has a different type, and different arguments, than the un-specialised one, so that might be part of it. This stuff is not documented, I'm afraid. I'll volunteer to explain what you are seeing (if you send me a small example) if you volunteer to write some documentation. Seriously. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Jens Fisseler | Sent: 01 June 2005 13:54 | To: glasgow-haskell-users(a)haskell.org | Subject: Simplifier output explanation needed | | Hi everbody! | | I'm currently trying to optimize some code, in particular trying to make | some functions as strict as possible. To do this, I quite often look for | strictness annotations either in the interface files or the the | simplifier output. Doing this, something odd occured to me: inserting a | '$!' into a function call, trying to enforce eager evaluation, the | simplifier output changed. Ok, I should expect this, but I don't | understand the change. The function name got '$s' as a prefix and the | strictness annotation ('Str: DmdType SSL') vanished. | | So my question is what all those different prefixes mean. I've stumbled | across at least '$s' and '$w' (worker wrapper?). Why did the strictness | annotation disappear? Is there any documentation that can enlighten me? | | Regards, | | Jens | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: GHC hang
by Simon Peyton-Jones 06 Jun '05

06 Jun '05

Lots of people seem to have had problems compiling Wash with GHC 6.4. As far as we know, they are all caused by the fact that the package-configuration file format changed in 6.4, and you need to fix that before it'll compile cleanly. Maybe someone can make available a version of Wash that works, rather than have everyone duplicate effort? (In GHC's defence, the package spec is still in flux, esp with Cabal coming on-stream. I know it's inconvenient to have changes.) However, the problems other people have been having are of the form "can't find interface file definition" rather than an indefinite hang. That's undoubtedly odd. You could tar up the complete tree and send it to us to see if we can reproduce what's going on. Certainly, GHC should never just hang. But it might be easier just to fix the package spec. I think the problem is that you need to list all the modules in a package, whereas you didn't before. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of John Goerzen | Sent: 31 May 2005 21:36 | To: glasgow-haskell-users(a)haskell.org | Subject: GHC hang | | Hi, | | I'm trying to compile WashNGo 2.3.1 on my amd64 machine running GHC 6.4. | When compiling HTMLMonad98.hs, ghc hangs. It's been running over 5 | minutes now with no output or other activity. | | What can I do to help the GHC folks debug this? | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2

ANN: Wash for GHC 6.4, Cabalized
by John Goerzen 06 Jun '05

06 Jun '05

Hello, I have made an, as far as I can tell, working copy of WASH for GHC 6.4. You can get it with: darcs get http://darcs.complete.org/local-branches/WashNGo Here are the basic things I did: * Applied the GHC 6.4 compatibility patch I found on one of these lists * Converted the build system to use Cabal. auto* is GONE. * Due to a limitation of Cabal, build only one package named WASH. The default Wash, even with the above compatibility patch, doesn't actually let me build programs that use it correctly. This one seems to work for me. Also, I have noted this in the README, but I couldn't figure out a way to run wash2hs automatically. You'll need to add -F -pgmF wash2hs in the GHC options for any file that needs wash2hs treatment. Problems? Please darcs send me patches. Thanks, -- John

1 0

ghc-pkg, recompilation check
by Serge D. Mechveliani 06 Jun '05

06 Jun '05

Dear GHC developers and users, Could you, please, help with ghc-pkg ? (in ghc-6.4) The contrived testing project is of the two small modules M1.hs, M2.hs. (find enclosed the source). `Makefile' is set so that make dm should compile the modules and put *.hi, *.o modules and .a, .o libraries to $(s)/export/. It also needs to create a package dm-1.0 (in 6.2.2 it was dm ). A particular command in Makefile is ghc-pkg -f $(s)/dm-1.0.conf -u -g , which (as I recall) makes the .o library from .a one. It worked in 6.2.2 -- with dm instead of dm-1.0, with `=' instead of `:' and with package_deps = ["data"] in the package specification. And in 6.4, make dm reports ... " Reading package info from stdin... done. ghc-pkg: invalid package identifier: " Packages always were difficult. And in 6.4 they are changed again ... Question 2: recompilation ------------------------- Why does it recompile both modules when after the first make dm we remove the .a library and repeat make dm ? This recompilation bites when there are many modules. Thank you in advance for explanation. ------------------ Serge Mechveliani mechvel(a)botik.ru ------------------------------------------------------------ module M1 -- file M1.hs where tuple31 :: (a, b, c) -> a tuple31 (x, _ ,_) = x --------------------------------- file M2.hs module M2 where import qualified Data.Set as Set (Set(..), singleton) import M1 (tuple31) f :: Set.Set Bool f = Set.singleton $ tuple31 (True, False, False) -- Makefile ------------------------------------------------------ ghcBinDir = /usr/bin s = /home/mechvel/ghc/6.4/pkgTest e = $(s)/export ghc = $(ghcBinDir)/ghc ghcpkg = $(ghcBinDir)/ghc-pkg RANLIB = ar -s HCFlags = -odir $(e) -hidir $(e) -ddump-hi-diffs pack = Package {name : ["\"dm-1.0\""], \ import_dirs : ["\"$(e)\""], \ source_dirs : [], \ library_dirs : ["\"$(e)\""], \ hs_libraries : ["\"HSdm\""], \ extra_libraries : [], \ include_dirs : [], \ c_includes : [], \ package_deps : [], \ extra_ghc_opts : [], \ extra_cc_opts : [], \ extra_ld_opts : [] } # of 6.2.2: name = ["\"dm\""], \ # package_deps = [\"data\"], \ obj: if [ ! -d $(e) ]; then mkdir $(e); fi $(ghc) $(HCFlags) --make M2 -package-name dm-1.0 dm: obj rm -f $(e)/libHSdm* $(e)/HSdm* ar -qc $(e)/libHSdm.a $(wildcard $(e)/*.o) $(RANLIB) $(e)/libHSdm.a $(RANLIB) $(e)/libHSdm.a echo $(pack) | $(ghcpkg) -f $(s)/dm-1.0.conf -u -g $(ghcpkg) -f $(s)/dm-1.0.conf -l ------------------------------------------------------------------ make dm yields ----------------------------------------------------------- if [ ! -d /home/mechvel/ghc/6.4/pkgTest/export ]; then mkdir /home/mechvel/ghc/6.4/pkgTest/export; fi /usr/bin/ghc -odir /home/mechvel/ghc/6.4/pkgTest/export -hidir /home/mechvel/ghc/6.4/pkgTest/export -ddump-hi-diffs --make M2 -package-name dm-1.0 Chasing modules from: M2 Source file changed or recompilation check turned off Compiling M1 ( ./M1.hs, /home/mechvel/ghc/6.4/pkgTest/export/M1.o ) No old interface file Source file changed or recompilation check turned off Compiling M2 ( M2.hs, /home/mechvel/ghc/6.4/pkgTest/export/M2.o ) No old interface file rm -f /home/mechvel/ghc/6.4/pkgTest/export/libHSdm* /home/mechvel/ghc/6.4/pkgTest/export/HSdm* ar -qc /home/mechvel/ghc/6.4/pkgTest/export/libHSdm.a /home/mechvel/ghc/6.4/pkgTest/export/M1.o /home/mechvel/ghc/6.4/pkgTest/export/M2.o ar -s /home/mechvel/ghc/6.4/pkgTest/export/libHSdm.a ar -s /home/mechvel/ghc/6.4/pkgTest/export/libHSdm.a echo Package {name : ["\"dm-1.0\""], import_dirs : ["\"/home/mechvel/ghc/6.4/pkgTest/export\""], source_dirs : [], library_dirs : ["\"/home/mechvel/ghc/6.4/pkgTest/export\""], hs_libraries : ["\"HSdm\""], extra_libraries : [], include_dirs : [], c_includes : [], package_deps : [], extra_ghc_opts : [], extra_cc_opts : [], extra_ld_opts : [] } | /usr/bin/ghc-pkg -f /home/mechvel/ghc/6.4/pkgTest/dm-1.0.conf -u -g Reading package info from stdin... done. ghc-pkg: invalid package identifier: make: *** [dm] Error 1 ----------------------------------------------------------

1 0

RE: recompilation check in 6.4
by Simon Marlow 06 Jun '05

06 Jun '05

Hi Serge, On 05 June 2005 11:58, Serge D. Mechveliani wrote: > for the first time compiles all the modules before Foo in > 50 seconds. > Then, I fix an error in Foo.hs and repeat "make dm". > > The options are set so that ghc-6.2.2 gets to Foo.hs in less > than 1 second when doing this repeated `make'. > It does consider each module before Foo and each time decides that > there is no need in recompilation. It keeps on going this way: > -------- > Considering whether compilation is required for Prelude0: > Skipping Prelude0 ( ./Prelude0.hs, /foo/source/export/Prelude0.o ) > -------- > and so on, by the scheme > "Considering ..XX -- {Checking usages .. --} Skipping XX". > > The compiler applies this way: > -------------------- > /foo/ghc/6.2.2/inst/bin/ghc -fglasgow-exts > -fallow-undecidable-instances > -fallow-overlapping-instances -fno-warn-overlapping-patterns > -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports > -idemotest > -odir /home/mechvel/dm/1.02/dm/source/export > -hidir /home/mechvel/dm/1.02/dm/source/export > -ddump-hi-diffs > --make DExport -package-name dm > -------------------- > > Now, when ghc-6.4 does such a repeated `make', it re-compiles > all the `previous' modules under the above options: I'm afraid I don't know what the problem might be. Probably GHC is looking in the wrong place for .hi files or .o files, or both. > --------- > Chasing modules from: DExport > Source file changed or recompilation check turned off > Compiling Prelude0 ( ./Prelude0.hs, /.../source/export/Prelude0.o ^^^^^^^ in particul, that looks very strange! Did you edit that by hand, or is that the verbatim GHC output? (copying the verbatim output is usually better, to avoid confusion). Cheers, Simon

1 0

RE: Int64 and efficiency
by Simon Marlow 06 Jun '05

06 Jun '05

On 06 June 2005 12:44, Ketil Malde wrote: > Recently, Marcin 'Qrczak' Kowalczyk posted a micro-benchmark on > comp.lang.functional, illustrating performance with statically typed > Int and Integer, and Kogut's dynamically typed automatically-promoted > numbers. (Int is fastest, Kogut second, and Integer quite a bit > slower). > > For fun, I tried to use Int64, but to my surprise it is a lot slower > than the others. Marcin suggested I look at stg and hc output (which > I did without getting much wiser) and made some guesses as to what the > reasons were. > > I'm curious whether this is typical, and if so, whether there is a > theoretical reason why Int64 is so slow? (I would have expected a > factor of 2-4 worse than Int, but in reality it was about 35x slower) > > (Code attached, replace MyInt as appropriate.) In theory, you're right. I haven't investigated your example, but my guess is that some inlining isn't happening - maybe some missing INLINE pragmas somewhere. You might be able to shed more light by comparing the -ddump-stg output for the Int version with the Int64 version. Oh, also the Int64 operations are currently performed by foreign calls, rather than primitives, IIRC. That will affect speed, but not by a huge amount. Cheers, Simon

1 0

Int64 and efficiency
by Ketil Malde 06 Jun '05

06 Jun '05

Hi, Recently, Marcin 'Qrczak' Kowalczyk posted a micro-benchmark on comp.lang.functional, illustrating performance with statically typed Int and Integer, and Kogut's dynamically typed automatically-promoted numbers. (Int is fastest, Kogut second, and Integer quite a bit slower). For fun, I tried to use Int64, but to my surprise it is a lot slower than the others. Marcin suggested I look at stg and hc output (which I did without getting much wiser) and made some guesses as to what the reasons were. I'm curious whether this is typical, and if so, whether there is a theoretical reason why Int64 is so slow? (I would have expected a factor of 2-4 worse than Int, but in reality it was about 35x slower) (Code attached, replace MyInt as appropriate.) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

qualified re-export of Data.Set
by Serge D. Mechveliani 06 Jun '05

06 Jun '05

Dear GHC developers, Please, how to re-export (qualified) Data.Set, Data.Map ? In ghc-6.2.2, I used only ------------------------------------------- {-# OPTIONS -fno-warn-duplicate-exports #-} module Reexport (module Data.Set, ...) ... import Data.Set ------------------- module Main import Reexport ------------------------------------------ For ghc-6.4, I need qualified import of Data.Set, Data.Map and need to re-export it. I am trying --------------------------------------------------------------------- module Reexport (module Set, f, g) where import qualified Data.Set as Set f :: Bool f = True g :: Set.Set Bool g = Set.singleton f -------------------------- module Main import Reexport main = putStr $ shows v "\n" where v = Set.singleton f -- g --------------------------------------------------------------------- Now, v = g works. And v = Set.singleton f reports Main.hs:3:40: Not in scope: `Set.singleton' I wonder, how the needed thing can be arranged. With kind regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

RE: FFI questions
by Simon Marlow 06 Jun '05

06 Jun '05

On 06 June 2005 09:04, Gary Morris wrote: > --- begin: AccuTime.hs > > module AccuTime where > > import Foreign.C.Types > > foreign import stdcall unsafe "accutime.h accuticks" c_accuticks :: > IO CULLong > > accuticks :: IO Integer > accuticks = do ull <- c_accuticks > return (fromIntegral ull) > > --- end > > And then, after passing the correct -L and -l flags to ghci, attempted > to load that module. Unfortunately, I got: > > ___ ___ _ > / _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version 6.4, for Haskell > 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \____/\/ /_/\____/|_| Type :? for help. > > Loading package base-1.0 ... linking ... done. > Loading object (dynamic) AccuTime ... done > final link ... done > Prelude> :l AccuTime.hs > Compiling AccuTime ( AccuTime.hs, interpreted ) > ghc.exe: panic! (the `impossible' happened, GHC version 6.4): > ByteCodeFFI.mkMarshalCode_wrk(x86) L_ > > Please report it as a compiler bug to > glasgow-haskell-bugs(a)haskell.org, > or http://sourceforge.net/projects/ghc/. Yes, unfortunately it seems that long-long results from foreign functions aren't supported by GHCi (on x86) right now. Workaround is to compile the module instead of interpreting it. Cheers, Simon

1 0

FFI questions
by Gary Morris 06 Jun '05

06 Jun '05

Hello everyone, Apologies in advance if I'm asking an incredibly simple question, but I'm using GHC 6.4 on Windows XP SP2. I was recently playing with implementing the Kocher attack on RSA in Haskell, and along the way I needed a reasonable way to time operations -- the built-in Windows functions don't do such a good job. I wrote a very simple function that uses the rdtsc instruction: --- begin: AccuTime.c #include <windows.h> __declspec(dllexport) ULONGLONG accuticks() { LARGE_INTEGER i; ULONG lo, hi; __asm { rdtsc mov hi, edx mov lo, eax } i.HighPart = hi; i.LowPart = lo; return i.QuadPart; } --- end --- begin: AccuTime.h #ifndef __accutime_h #define __acutime_h #include <windows.h> ULONGLONG accuticks(); #endif /* __accutime_h */ --- end and compiled it to AccuTime.dll. I then attempted to piece together the file I'd need to import this function into Haskell: --- begin: AccuTime.hs module AccuTime where import Foreign.C.Types foreign import stdcall unsafe "accutime.h accuticks" c_accuticks :: IO CULLong accuticks :: IO Integer accuticks = do ull <- c_accuticks return (fromIntegral ull) --- end And then, after passing the correct -L and -l flags to ghci, attempted to load that module. Unfortunately, I got: ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base-1.0 ... linking ... done. Loading object (dynamic) AccuTime ... done final link ... done Prelude> :l AccuTime.hs Compiling AccuTime ( AccuTime.hs, interpreted ) ghc.exe: panic! (the `impossible' happened, GHC version 6.4): ByteCodeFFI.mkMarshalCode_wrk(x86) L_ Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, or http://sourceforge.net/projects/ghc/. > At this point, I'm quite confused. Does anyone else know what I'm doing to cause this panic? Thanks, /g

1 0