- ghc-devs - Haskell.org

Re: Fwd: Any GHC plans to adopt tf-random?
by Michał Pałka 15 Nov '13

15 Nov '13

Hello Ryan and Nicolas, I'm happy to see some interest in the tf-random package. The package has not been extensively tested. I ran it on x86-64 and x86 Linux, and on x86 Windows. It would be good to check if it gives the same results on a big-endian architecture, such as ARM, however I don't have access to such a machine. When it comes to the performance, it is good on x86-64, but significantly slower on x86, and probably on other 32-bit architectures, because the cipher's code is optimised for 64-bit arithmetic. It may be possible to use a 32-bit optimised version for the 32-bit architectures to mitigate that, but that would mean even more C code to review. Another issue is whether to change the RandomGen/Random API, which might be considered at the same time. The current Random instances are slow, suffer from the modulo bias, and work only when the range of numbers returned by the generator is (0, 2147483562). However, I am aware that the disturbance would potentially be much larger if the API is changed, so doing it may need some planning. Ideally, it would be nice if people started using the package and see how it performs in practice before any decisions are made. Best regards, Michał > Begin forwarded message: > > From: Ryan Newton <rrnewton(a)gmail.com> > > Subject: Re: Any GHC plans to adopt tf-random? > > Date: 6 november 2013 22:51:02 CET > > To: Nicolas Frisby <nicolas.frisby(a)gmail.com> > > Cc: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> > > Reply-To: rrnewton(a)gmail.com > > Hi all, > > It looks like since the paper has come out the code has been > > released to Hackage. I personally would love to replace > > System.Random with something like this. > > I think the question of whether it's time comes down to some > > due-diligence issues outside the scope of the paper. This library > > has C code, have people tested it extensively on Mac/Linux/Windows? > > Does it have any performance divots we should know about? (Though > > the performance of the legacy implementation was bad in many > > respects -- it > > is a low bar.) > > -Ryan > > > > > > On Wed, Nov 6, 2013 at 3:12 PM, Nicolas Frisby > > <nicolas.frisby(a)gmail.com> wrote: > > Adding Ryan Newton to the TO field, as the maintainer of > > random. > > > > > > On Wed, Nov 6, 2013 at 2:02 PM, Nicolas Frisby > > <nicolas.frisby(a)gmail.com> wrote: > > Bugs #3575 #3620 have to do with splitting StdGens > > yielding dependent generators. > > > > The Haskell 2013 paper Splittable Pseudorandom > > Number Generators Using Cryptographic Hashing by > > Claessen and Pałka yielded the tf-random package on > > Hackage. > > > > Are there any plans to integrate these corrections > > into System.Random? > > Thanks. > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > >

1 0

topHandler03 failing
by Joachim Breitner 15 Nov '13

15 Nov '13

Hi, I don’t trust the travis setup enough to automatically relay failures, so I do it manually. Since these patches: Changes to ghc: commit 12cdd6d Author: Duncan Coutts <duncan(a)well-typed.com> Date: Thu Nov 14 16:02:03 2013 +0000 Don translate UserInterrupt into ExitFailure 1, let it propagate It is important that if a program recieved ^C from the user, and the program terminates as a result, that it exit with SIGINT so that the parent process knows that was the case. For example cabal calling ghc will then be able to tell the difference between it failing and the user interrupting with ^C and report (or not) appropriately. So we should just let the UserInterrupt exception propagate to the top level error handler which will do the right thing. See http://www.cons.org/cracauer/sigint.html commit a987b80 Author: Duncan Coutts <duncan(a)well-typed.com> Date: Thu Nov 14 15:54:13 2013 +0000 Improve the shutdownHaskellAndSignal and add fast exit This is the RTS part of a patch to base's topHandler to handle exiting by a signal. The intended behaviour is that on Unix, throwing ExitFailure (-sig) results in the process terminating with that signal. Previously shutdownHaskellAndSignal was only used for exiting with SIGINT due to the UserInterrupt exception. Improve shutdownHaskellAndSignal to do the signal part more carefully. In particular, it (should) now reliably terminates the process one way or another. Previusly if the signal was blocked, ignored or handled then shutdownHaskellAndSignal would actually return! Also, the topHandler code has two paths a careful shutdown and a "fast exit" where it does not give finalisers a chance to run. We want to support that mode also when we want to exit by signal. So rather than the base code directly calling stg_exit as it did before, we have a fastExit bool paramater for both shutdownHaskellAnd{Exit,Signal}. Changes to base: commit dd00004 Author: Duncan Coutts <duncan(a)well-typed.com> Date: Thu Nov 14 15:16:30 2013 +0000 Add tests for the top level exception handler The top level exception handler is wrapped around main, and FFI exports. It handles exceptions that are not otherwise caught in user code. For most exception is just prints them, but handles a few specially, including ExitCode and UserInterrupt. On Unix it installs a signal handler for SIGINT to translate it into a UserInterrupt async exception. So we test that: 1. receiving SIGINT does trigger a UserInterrupt async exception 2. an unhandled UserInterrupt makes us kill ourselves with SIGINT 3. an unhandled ExitFailure (-sig) makes us kill ourselves with sig commit 6b22a6e Author: Duncan Coutts <duncan(a)well-typed.com> Date: Thu Nov 14 15:15:31 2013 +0000 Handle ExitFailure (-sig) by killing process with signal On Unix we now use negative exit codes in ExitFailure to indicate that a process exited due to a signal. This patch implements the case for when a ExitFailure exception propagates out of the top of main (and is handled by the topHandler). For a negative ExitFailure code, we try to kill the process using that signal (the details of that are handled by shutdownHaskellAndSignal from the RTS). For an exit code outside the valid ranges, we use 0xff. Changes to process: commit 3ebbe13 Author: Duncan Coutts <duncan(a)well-typed.com> Date: Thu Nov 14 13:59:57 2013 +0000 Change the unix ExitCode encoding again! Now simply -signum So rather than a bitfield encoding, covering normal exit codes, signals and core dumps, we now simply use negative numbers for signal exit codes. We thus do not report core dumps by this mechanism. This encoding is a lot simpler to explain and use. It also happens to be the same encoding as Python's subprocess package uses. Anyone who cares about core dumps can still use the unix package. I get this failure on travis: =====> topHandler03(normal) 3622 of 3821 [0, 0, 0] Actual stderr output differs from expected: --- /dev/null 2013-11-14 17:46:34.724312327 +0000 +++ ../../libraries/base/tests/topHandler03.run.stderr 2013-11-14 18:24:52.367542630 +0000 @@ -0,0 +1 @@ +Terminated *** unexpected failure for topHandler03(normal) (Full log at https://s3.amazonaws.com/archive.travis-ci.org/jobs/13982142/log.txt) Does anyone feel responsible? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

2 1

Trac formatting
by Simon Peyton-Jones 15 Nov '13

15 Nov '13

When Trac formats commit messages it is doing a terrible job. See for example: https://ghc.haskell.org/trac/ghc/ticket/5996 The commit message is nigh illegible until typeset without makup (see comment 10). Could this be done automatically? Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

4 7

Out with the new, in with the old for the vector library WAS: [commit: packages/vector] ghc-head: Snapshot of the real 0.10.0.1 release (a3a65b5)
by Geoffrey Mainland 14 Nov '13

14 Nov '13

Hi Bryan, I apologize for not bringing this issue up in a more timely fashion. I'm curious why the Bundle support that Roman added to the vector library was removed. I understand that the change in representation made it difficult for, e.g., dph to use the new vector library, but this change in representation was vital to our work on exploiting SIMD instructions. FWIW, I have been maintaining (and rebasing) a set of patches to DPH that allowed it to use Roman's new version of the vector library. If this is the path forward for the vector library, then I'm afraid anyone who wants to get any real use out of the new SIMD primops in GHC will be still stuck building their own version of the compiler using my patched primitive, vector, and dph libraries. That also requires me to maintain patched versions of these three libraries. Perhaps the roll-back in functionality was just done to get 7.8 out the door? Thanks, Geoff On 09/26/2013 05:54 AM, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/vector > > On branch : ghc-head > Link : http://git.haskell.org/packages/vector.git/commitdiff/a3a65b56a7d09e5166655… > >> --------------------------------------------------------------- > > commit a3a65b56a7d09e5166655c3877c389b7b71fb8af > Author: Bryan O'Sullivan <bos(a)serpentine.com> > Date: Wed Sep 25 10:39:32 2013 -0700 > > Snapshot of the real 0.10.0.1 release > > >> --------------------------------------------------------------- > > a3a65b56a7d09e5166655c3877c389b7b71fb8af > Data/Vector.hs | 16 +- > Data/Vector/Fusion/Bundle/Monadic.hs | 1098 ------------------------- > Data/Vector/Fusion/{Bundle.hs => Stream.hs} | 361 ++++---- > Data/Vector/Fusion/Stream/Monadic.hs | 517 +++++------- > Data/Vector/Fusion/{Bundle => Stream}/Size.hs | 4 +- > Data/Vector/Generic.hs | 463 ++++++----- > Data/Vector/Generic/Base.hs | 4 +- > Data/Vector/Generic/Mutable.hs | 273 +++--- > Data/Vector/Generic/Mutable/Base.hs | 135 --- > Data/Vector/Generic/New.hs | 103 ++- > Data/Vector/Primitive.hs | 16 +- > Data/Vector/Storable.hs | 16 +- > Data/Vector/Unboxed.hs | 16 +- > benchmarks/vector-benchmarks.cabal | 4 +- > include/vector.h | 10 +- > internal/GenUnboxTuple.hs | 4 +- > internal/unbox-tuple-instances | 30 +- > old-testsuite/Main.hs | 13 - > old-testsuite/Testsuite/Stream/AsList.hs | 134 --- > old-testsuite/Testsuite/Stream/Errors.hs | 41 - > old-testsuite/Testsuite/Utils/Generator.hs | 22 - > old-testsuite/Testsuite/Utils/List.hs | 25 - > old-testsuite/Testsuite/Utils/Property.hs | 155 ---- > old-testsuite/Testsuite/Utils/Test.hs | 123 --- > old-testsuite/Testsuite/Vector/AsList.hs | 174 ---- > old-testsuite/Testsuite/Vector/Errors.hs | 47 -- > old-testsuite/microsuite/README | 8 - > old-testsuite/microsuite/Test.hs | 200 ----- > old-testsuite/microsuite/and.hs | 3 - > old-testsuite/microsuite/append.hs | 5 - > old-testsuite/microsuite/cons.hs | 3 - > old-testsuite/microsuite/drop.hs | 4 - > old-testsuite/microsuite/elem.hs | 4 - > old-testsuite/microsuite/empty.hs | 3 - > old-testsuite/microsuite/eq.hs | 6 - > old-testsuite/microsuite/filter.hs | 4 - > old-testsuite/microsuite/find.hs | 4 - > old-testsuite/microsuite/findIndex.hs | 4 - > old-testsuite/microsuite/foldl1.hs | 4 - > old-testsuite/microsuite/from-to.hs | 2 - > old-testsuite/microsuite/head.hs | 4 - > old-testsuite/microsuite/index.hs | 3 - > old-testsuite/microsuite/init.hs | 4 - > old-testsuite/microsuite/last.hs | 4 - > old-testsuite/microsuite/length-bool.hs | 3 - > old-testsuite/microsuite/length-char.hs | 3 - > old-testsuite/microsuite/length-double.hs | 3 - > old-testsuite/microsuite/length-float.hs | 3 - > old-testsuite/microsuite/length-int16.hs | 4 - > old-testsuite/microsuite/length-int32.hs | 4 - > old-testsuite/microsuite/length-int64.hs | 4 - > old-testsuite/microsuite/length-int8.hs | 4 - > old-testsuite/microsuite/length-unit.hs | 3 - > old-testsuite/microsuite/length-word.hs | 4 - > old-testsuite/microsuite/length-word16.hs | 4 - > old-testsuite/microsuite/length-word32.hs | 4 - > old-testsuite/microsuite/length-word64.hs | 4 - > old-testsuite/microsuite/length-word8.hs | 4 - > old-testsuite/microsuite/length.hs | 3 - > old-testsuite/microsuite/lookup.hs | 5 - > old-testsuite/microsuite/map.hs | 4 - > old-testsuite/microsuite/maximum.hs | 4 - > old-testsuite/microsuite/maximumBy.hs | 4 - > old-testsuite/microsuite/minimum.hs | 4 - > old-testsuite/microsuite/minimumBy.hs | 4 - > old-testsuite/microsuite/null-ndp.hs | 3 - > old-testsuite/microsuite/null.hs | 3 - > old-testsuite/microsuite/or.hs | 3 - > old-testsuite/microsuite/product.hs | 4 - > old-testsuite/microsuite/repeat.hs | 4 - > old-testsuite/microsuite/replicate.hs | 3 - > old-testsuite/microsuite/singleton.hs | 3 - > old-testsuite/microsuite/snoc.hs | 3 - > old-testsuite/microsuite/sum-complex.hs | 5 - > old-testsuite/microsuite/sum-ratio.hs | 5 - > old-testsuite/microsuite/sum.hs | 8 - > old-testsuite/microsuite/tail.hs | 4 - > old-testsuite/microsuite/take.hs | 4 - > old-testsuite/microsuite/takeWhile.hs | 7 - > old-testsuite/microsuite/unfold.hs | 5 - > old-testsuite/microsuite/zip.hs | 6 - > old-testsuite/microsuite/zipwith.hs | 6 - > old-testsuite/microsuite/zipwith3.hs | 7 - > tests/Main.hs | 4 +- > tests/Tests/Bundle.hs | 163 ---- > tests/Tests/Stream.hs | 163 ++++ > tests/Tests/Vector.hs | 4 +- > tests/Utilities.hs | 16 +- > tests/vector-tests.cabal | 6 +- > vector.cabal | 10 +- > 90 files changed, 991 insertions(+), 3610 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc a3a65b56a7d09e5166655c3877c389b7b71fb8af > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 1

RE: [commit: ghc] master: Make type-level evaluation work with :kind! (b2fa2d4)
by Simon Peyton-Jones 14 Nov '13

14 Nov '13

That is indeed revolting. Why not make sfMatchFam :: [Type] -> Maybe (CoAxiomRule, [Type], Type) thus getting rid of the TcCoercion, and baking in the flaky assumption by construction. Then I think you can put the whole definition of TcBuiltInSynFamily (with a non-Tc name) into CoAxiom. Would that work? Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 13 November 2013 00:37 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Make type-level evaluation work with | :kind! (b2fa2d4) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/b2fa2d41032882d3cf67be083489c | bcbf9e4ec07/ghc | | >--------------------------------------------------------------- | | commit b2fa2d41032882d3cf67be083489cbcbf9e4ec07 | Author: Iavor S. Diatchki <diatchki(a)galois.com> | Date: Tue Nov 12 16:36:23 2013 -0800 | | Make type-level evaluation work with :kind! | | The main change is to add a case to `reduceTyFamApp_maybe` to | evaluate | built-in type constructors (e.g., (+), (*), and friends). | | To avoid problems with recursive modules, I moved the definition of | TcBuiltInSynFamily from `FamInst` to `FamInstEnv`. I am still not | sure if | this is the right place. | | There is also a wibble that it'd be nice to fix: | | when we evaluate a built-in type function, using`sfMatchFam`, we | get | a `TcCoercion`. However, `reduceTyFamApp_maybe` needs a | `Corecion`. | I couldn't find a nice way to convert between the two, so I | resorted to | a bit of hack (marked with `XXX`). | | The hack is that we happen to know that the built-in constructors | for | the type-nat functions always return coercions of shape | `TcAxiomRuleCo`, | with no assumptions, so it easy to convert `TcCoercion` to | `Coercion` | in this one case. This is enough to make things work, but it is | clearly | a cludge. | | | >--------------------------------------------------------------- | | b2fa2d41032882d3cf67be083489cbcbf9e4ec07 | compiler/ghc.mk | 2 +- | compiler/typecheck/FamInst.lhs | 27 +----------- | compiler/typecheck/TcInteract.lhs | 2 +- | compiler/typecheck/TcTypeNats.hs | 2 +- | compiler/types/FamInstEnv.lhs | 43 | +++++++++++++++++++- | .../FamInst.lhs-boot => types/FamInstEnv.lhs-boot} | 2 +- | compiler/types/TyCon.lhs | 2 +- | 7 files changed, 47 insertions(+), 33 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies- | harder --ignore-space-at-eol --cc | b2fa2d41032882d3cf67be083489cbcbf9e4ec07 | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

Problems building HEAD on Mac OS X Mavericks/Xcode 5
by Nick Partridge 14 Nov '13

14 Nov '13

Hi, I've hit a build failure when trying to build HEAD on Mavericks. I've logged a bug here with a lot of detail: https://ghc.haskell.org/trac/ghc/ticket/8528. When using alex 3.1.2, some of the generated files have spaces preceding preprocessor statements, while alex 3.1.0 doesn't do this. I guess this is possibly an alex bug, but this is my first time building GHC so I'm not really sure how the ecosystem works :) Huge shout-out to Carter S. for giving me a ton of help in nailing down this issue! - Nick

3 2

restrictions on Coercible
by Richard Eisenberg 14 Nov '13

14 Nov '13

Hi Simon, Joachim, and others, I'm in the midst of reimplementing GeneralizedNewtypeDeriving in terms of coerce. See #8503 for why I'm doing this. But, I've run up against a limitation of Coercible I'd like to know more about. Currently, the stage2 compiler fails to build because of the problem. In Module.lhs, there is this line: > newtype PackageId = PId FastString deriving( Eq, Typeable ) The deriving mechanism sensibly prefers to use the GND mechanism when it can, and it can (seemingly) for Eq here. But, I get this error: > compiler/basicTypes/Module.lhs:297:46: > No instance for (ghc-prim:GHC.Types.Coercible FastString PackageId) > because ‛PackageId’ is a recursive type constuctor This is curious, because PackageId is manifestly *not* recursive. A little poking around tells me that any datatype mentioned in a .hs-boot file is considered recursive. There is sense to this, but the error message sure is confusing. In any case, this opens up a broader issue: we want GND to work with recursive newtypes. For example: > class C a where > meth :: a > > instance C (Either a String) where > meth = Right "" > > newtype RecNT = MkRecNT (Either RecNT String) > deriving C The above code works just fine in 7.6.3. But, if Coercible isn't allowed over recursive newtypes, then this wouldn't work if GND is implemented in terms of coerce. So, my question is: why have this restriction? And, if there is a good reason for it, it should probably be documented somewhere. I couldn't find mention of it in the user's guide or in the haddock docs. If we do keep this restriction, what to do about GND? Seems like this may kill the idea of implementing GND in terms of coerce, but that makes me sad. Thanks, Richard

2 2

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