November 2013 - ghc-devs

RE: [commit: ghc] master: Make the fields in NameCache strict (bed118a)
by Simon Peyton-Jones 13 Nov '13

13 Nov '13

Patrick, does this have any effect on the performance of the compiler (runtime, allocation)? Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 13 November 2013 03:40 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Make the fields in NameCache strict | (bed118a) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/bed118a43019e02ca0bc763fa6e418 | 45b1deb21f/ghc | | >--------------------------------------------------------------- | | commit bed118a43019e02ca0bc763fa6e41845b1deb21f | Author: Patrick Palka <patrick(a)parcs.ath.cx> | Date: Sat Nov 9 14:23:46 2013 -0500 | | Make the fields in NameCache strict | | We've already been making sure to strictly modify the global name | cache | in order to avoid space leaks. However, that does us little good if | the | fields of the name cache are not made strict as well. | | | >--------------------------------------------------------------- | | bed118a43019e02ca0bc763fa6e41845b1deb21f | compiler/main/HscTypes.lhs | 4 ++-- | 1 file changed, 2 insertions(+), 2 deletions(-) | | diff --git a/compiler/main/HscTypes.lhs b/compiler/main/HscTypes.lhs | index 1004a6b..a3c6a65 100644 | --- a/compiler/main/HscTypes.lhs | +++ b/compiler/main/HscTypes.lhs | @@ -2033,9 +2033,9 @@ its binding site, we fix it up. | -- each original name; i.e. (module-name, occ-name) pair and provides | -- something of a lookup mechanism for those names. | data NameCache | - = NameCache { nsUniqs :: UniqSupply, | + = NameCache { nsUniqs :: !UniqSupply, | -- ^ Supply of uniques | - nsNames :: OrigNameCache | + nsNames :: !OrigNameCache | -- ^ Ensures that one original name gets one unique | } | | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

Re: Adding new library dependencies to GHC
by Carter Schonwald 13 Nov '13

13 Nov '13

Hey Alex, very very cool! a few thoughts: ghc stage1 has no GHCI, and thus can't build / use a lib that has template haskell. LLVM-General uses template haskell pretty heavily to generate the FFI code! see https://github.com/bscarlet/llvm-general/blob/master/llvm-general/src/LLVM/… example and https://github.com/bscarlet/llvm-general/blob/master/llvm-general/src/LLVM/… for another so your choices are: figure out how to support TH in stage 1 ghc, OR use llvm-general-pure, and cope with just having llvm pretty printing and parsing. Alternatively, you could treat the "llvm-general" way as being an alternative to the -fasm and -fllvm backends, and have it only be built / supported in the stage2 backend. point being: start with getting -flllvm working just using llvm-general-pure then once you've got that working, having an llvm alternative that can ghc can enable in stage2 (when ghci/th is a thing) can be made to work. either way, very cool! it gives a path towards bundling llvm with ghc, or at least is a decent experiment towards that. one thing you may want to consider is how to remove the TH deps from llvm general. This would make it possible use it in stage1 GHC, which would make it much more likely to be actually merged into GHC proper. again, props for getting this experimentation started! -Carter On Tue, Nov 12, 2013 at 2:53 PM, Alex Ford <alexander.r.ford(a)gmail.com>wrote: > Hi, > > I've made some changes to the LLVM backend of GHC to make it use > llvm-general to output bitcode rather than pretty printing human readable > LLVM assembly. However, I've been having trouble linking the required > libraries (llvm-general and its transitive dependencies). The steps I've > taken so far are to put the required libraries in the build tree under > libraries, and added them to the packages file, to PACKAGES_STAGE0 and > PACKAGES_STAGE1 in ghc.mk, and to the build depends section in compiler/ > ghc.cabal.in. > > The build fails in phase 1 when trying to link utf8-string (a dependency > of llvm-general) during the build of llvm-general, with: > Loading package utf8-string-0.3.7 ... <command line>: can't load .so/.DLL > for: libHSutf8-string-0.3.7.so (libHSutf8-string-0.3.7.so: cannot open > shared object file: No such file or directory) > > The problem seems to be that with pre-existing library dependencies, the > system-wide libraries at /usr/lib/ghc-7.6.3/<libname>/ are pulled in, > whereas with the new dependencies, versions within the build tree (e.g. at > libraries/utf8-string/dist-install/build/) are tried instead, despite these > new libraries being installed globally within the same parent directory and > being listed by ghc-pkg (no errors upon ghc-pkg check either). > > For example, in compiler/stage1/package-data.mk, > compiler_stage1_DEP_LIB_DIRS_SEARCHPATH > specifies /usr/lib/ghc-7.6.3/bytestring-0.10.0.2, and bytestring links > successfully, but for utf8-string specifies > <ghc-base-dir>/libraries/utf8-string/dist-boot/build. > > I've read through the documentation on libraries for GHC but can't figure > out how to make this work. Could anyone suggest how I could go about fixing > this? > > As a slightly related question, llvm-general depends on template-haskell. > Will this cause problems when building GHC normally, since the stage 1 > compiler does not support TH? If so is there any way to compile stage 2 > directly using the stage 0 compiler? > > Many thanks, > Alex > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >

1 0

RE: Windows build
by Simon Peyton-Jones 12 Nov '13

12 Nov '13

Great...that works. I also had to edit mk/boilerplate.mk to comment out these lines # ifeq "$(shell $(SHELL) -c 'python2 -c 0' 2> /dev/null && echo exists)" "exists" # PYTHON = python2 # endif Because msys2 has python2.exe as well as python.exe. (Or I could have moved that out of the way too.) Thanks Austin please note for the msys2 instructions you are writing Simon From: kyra [mailto:kyrab@mail.ru] Sent: 12 November 2013 09:53 To: Simon Peyton-Jones Subject: Re: Windows build http://www.python.org/download/ This is what is recommended at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows I think you already has it installed, because this is required for msys build. Hence all you should do is: 1. make your edit (MINGW32 -> MINGW) 2. disable msys2 python On 11/12/2013 13:44, Simon Peyton-Jones wrote: OK... where did you get native python from? From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of kyra Sent: 12 November 2013 09:39 To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: Re: Windows build It looks the second option (native win32 python) works. I've installed native win32 python, reverted my edit, leaving only *your* edit in place, *and* disabled msys2 python simply moving all msys2 python executables out of the path. It seems, all works now (I didn't wait the finish of tests, though). Cheers, Kyra On 11/12/2013 12:58, Simon Peyton-Jones wrote: Thanks Kyra, you are a star. Yes, msys2 has been updated to fix the ctypes bug. I have the version from 20131022. With your edit I now get this: Traceback (most recent call last): File "../driver/runtests.py", line 164, in <module> if mydll.kernel32.SetConsoleCP(65001) == 0: File "/usr/lib/python2.7/ctypes/__init__.py", line 435, in __getattr__ dll = self._dlltype(name) File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__ self._handle = _dlopen(self._name, mode) OSError: No such file or directory Any ideas about what to do now? I guess you can reproduce if you install the later msys2. thanks Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of kyra Sent: 12 November 2013 06:45 To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: Re: Windows build I've looked into this. Current test script picks msys2-compiled python, which, after your modification, can't find 'windll', because msys2-compiled python is cygwin-like and it's 'ctypes' has no 'windll'. If we rewrite the relevant part of script thus: config.msys2 = False .... elif v.startswith("MINGW"): config.msys2 = True .... # Try to use UTF8 if windows: import ctypes if config.cygwin or config.msys2: # Is this actually right? Which calling convention does it use? # As of the time of writing, ctypes.windll doesn't exist in the # cygwin python, anyway. mydll = ctypes.cdll else: mydll = ctypes.windll then we go slightly further and fail with: Traceback (most recent call last): File "../driver/runtests.py", line 151, in <module> import ctypes File "/usr/lib/python2.7/ctypes/__init__.py", line 451, in <module> pythonapi = PyDLL("libpython%d.%d.dll" % _sys.version_info[:2]) File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__ self._handle = _dlopen(self._name, mode) OSError: No such file or directory And this is definitely a bug in msys2 python, because there is no such a file ("libpython*.dll) anywhere in msys2 distribution. What could be possible solutions? 1. I'm seeing a new version of Msys2 appearing right now here http://sourceforge.net/projects/msys2/files/REPOS/MSYS2/i686/. It is now a bunch of separate packages, I've looked into python 2.7.5 package and found ctypes-related things definitely changed. Thus we could wait a couple of days until Msys2 release process is finished and installation information is available, hoping it's python is working properly. 2. Another approach is to modify testing infrastructure to use some pure win32/mingw based python distribution. But I'm in no way an expert here, sorry. Cheers, Kyra On 11/12/2013 02:10, Simon Peyton-Jones wrote: Austin, or others, It would be SO GREAT if it was possible to validate on Windows again. Currently I'm using msys2, which builds GHC fine, but things fail badly in the testsuite. Traceback (most recent call last): File "../driver/runtests.py", line 144, in <module> raise Exception("Can't detect Windows terminal type") Exception: Can't detect Windows terminal type uname -s returns MINGW_NT-6.2 Changing the test from elif v.startswith("MINGW32"): to elif v.startswith("MINGW"): just produces a new error Traceback (most recent call last): File "../driver/runtests.py", line 155, in <module> mydll = ctypes.windll AttributeError: 'module' object has no attribute 'windll' ../mk/test.mk:242: recipe for target 'test' failed It's all very frustrating because I can't validate. Can anyone help? Simon _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs

1 0

Restrictions on polytypes with type families
by Richard Eisenberg 12 Nov '13

12 Nov '13

Hi all, GHC doesn't allow type families to be used with polytypes: 1) The right-hand side of a type family instance cannot have a "forall". 2) A type family cannot be applied to a type containing a "forall". 3) A pattern in a type family instance is (oddly) allowed to contain "forall", but this is silly because of (2). Do these restrictions have known reasons for their existence? Or, are there any that are restricted because someone needs to think hard before lifting it, and no one has yet done that thinking? I know, for example, that the unify function in types/Unify.lhs will have to be completed to work with foralls, but this doesn't seem hard. I've run into two separate cases where I've hit this restriction, so this isn't just idle thought. Thanks, Richard

8 15

Finding & assembling class dictionaries from GHC plugins?
by Conal Elliott 12 Nov '13

12 Nov '13

I'm working on a GHC plugin (for compiling Haskell to hardware), and I need to synthesize Typeable (and maybe other) class dictionaries for a wide range of types, including composite types (functions, pairs, lists, etc). Can it be done, and how? I think I'm mainly looking for mechanics of finding existing class instances (however they're defined) and assembling them (for parametrized/composite dictionaries), rather than mechanisms specific to Typeable. Thanks, -- Conal

3 12

Pattern match failure in StgCmmExpr.hs when adding new out-of-line primop
by Edsko de Vries 12 Nov '13

12 Nov '13

Hi guys, I'm trying to add a new primop; as a starting point I just copied the definition of "catch#" in primops.txt.pp and renamed "catch#" to "catchRethrow#", and added the corresponding declarations following https://ghc.haskell.org/trac/ghc/wiki/Commentary/PrimOps#AddinganewPrimOp ; however, when I do this, I get ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.7.20131108 for x86_64-apple-darwin): compiler/codeGen/StgCmmExpr.hs:508:15-48: Irrefutable pattern failed for pattern (CoreSyn.DEFAULT, deflt) I can't quite figure out why that is happening and how I should address it. Any suggestions? Thanks! -E

1 1

Re: Pattern match failure in StgCmmExpr.hs when adding new out-of-line primop
by Edsko de Vries 12 Nov '13

12 Nov '13

Hi Arash, On Tue, Nov 12, 2013 at 10:44 AM, Arash Rouhani <rarash(a)student.chalmers.se> wrote: > I'm really curious why you want a "catchRethrow". I'm tempted to add such > a primop myself since I'm working on problems with stack traces. I'm really > interested in what use-case you had in mind. > I'm working on dealing with problems with re-throwing asynchronous exceptions, especially in the context of using unsafePerformIO (see #8006 and the other tickets I reference there at the top). The catchRethrow I'm playing with is supposed to be used something like threadCode :: IO () threadCode = catch (print notReallyPure) outerHandler where outerHandler :: SomeException -> IO () outerHandler e = logMsg $ "Outer handler: " ++ show e notReallyPure :: Integer notReallyPure = unsafePerformIO $ catchRethrow (go 10) innerHandler where go :: Integer -> IO Integer go 0 = return 1234 go n = do logMsg (show n) threadDelay 100000 go (n - 1) innerHandler :: SomeException -> IO Integer -> IO Integer innerHandler e rethrow = do logMsg $ "Inner handler: " ++ show e rethrow logMsg :: String -> IO () logMsg str = do tid <- myThreadId putStrLn $ show tid ++ ": " ++ str Given this main: main :: IO () main = do a1 <- async threadCode a2 <- async threadCode threadDelay 500000 cancel a1 wait a2 return () It should be the case that when thread a1 gets interrupted, thread a2 can continue evaluating the notReallyPure thunk without getting either an exception and without redoing any work. In other words, the output of this main should look like ThreadId 2: 10 ThreadId 2: 9 ThreadId 2: 8 ThreadId 2: 7 ThreadId 2: 6 ThreadId 2: Inner handler: thread killed ThreadId 2: Outer handler: thread killed ThreadId 3: 5 ThreadId 3: 4 ThreadId 3: 3 ThreadId 3: 2 ThreadId 3: 1 1234 -E

1 0

Windows build
by Simon Peyton-Jones 12 Nov '13

12 Nov '13

Austin, or others, It would be SO GREAT if it was possible to validate on Windows again. Currently I'm using msys2, which builds GHC fine, but things fail badly in the testsuite. Traceback (most recent call last): File "../driver/runtests.py", line 144, in <module> raise Exception("Can't detect Windows terminal type") Exception: Can't detect Windows terminal type uname -s returns MINGW_NT-6.2 Changing the test from elif v.startswith("MINGW32"): to elif v.startswith("MINGW"): just produces a new error Traceback (most recent call last): File "../driver/runtests.py", line 155, in <module> mydll = ctypes.windll AttributeError: 'module' object has no attribute 'windll' ../mk/test.mk:242: recipe for target 'test' failed It's all very frustrating because I can't validate. Can anyone help? Simon

2 3

Things stopping pure Haskell code from having a cross-platform single semantics?
by Ryan Newton 12 Nov '13

12 Nov '13

Haskell isn't like Java byte code in having a single semantics for a program irrespective of where it is run. In particular, "Int" has a platform-defined width -- so the same (pure) code can yield different answers on different machines. numCapabilities was also a "leak" of platform information, which did not require IO. But, happily, now it does not appear in the [Trustworthy] module, Control.Concurrent. Ok, what else? What other holes are there that allow my pure functions to change their answer on different machines? I'm making a list of these in a paper and I want to make sure I give a full account. Thanks, -Ryan

2 1

Annotations
by Simon Peyton-Jones 08 Nov '13

08 Nov '13

I've just noticed that there is no GHC language extension for annotations http://www.haskell.org/ghc/docs/latest/html/users_guide/extending-ghc.html#… That feels like an oversight. Yes, they are in a pragma, but you may get an error message if you compile with a stage-1 compiler, for example. Plus, the language extensions should truthfully report what extra stuff you are using. I'm inclined to add a language extension "Annotations". * Without it {-# ANN ... #-} pragmas are ignored as comments * With it, they are treated as annotations Do you agree? I don't know whether this can (or even should) land in 7.8.1. Do you care either way? Guidance welcome Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

5 7