Re: TDNR without new operators or syntax changes
Bertram Felgenhauer-2 wrote >> 1. If the compiler encounters a term f a, and there is more than one >> definition for f in scope (after following all of the usual rules for >> qualified imports); >> >> 2. And exactly one of these definitions matches the type of a (or the >> expected type of f if given); >> >> 3. Then this is the definition to use. > > I now find that Anthony's concerns are justified. The question is, what > exactly does the type matching in step 2 involve? If it is a recursive > call to the type-checker then you'll have a huge performance problem. I was concerned about this, but not knowing anything about how type-checking/inference is implemented, I wouldn't know if this is actually a problem or not. > If, on the other hand, you only take into account what is known about > the type of a at a given time, then you need special treatment for > unambiguous names or even trivial programs will fail to type-check, just > as Anthony said. Why special treatment for unambiguous names? They shouldn't be effected at all by this. -- View this message in context: http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes-tp5835927p5836393.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: TDNR without new operators or syntax changes
Henning Thielemann wrote > I know people are unhappy with Haskell's records and module system, but I > still think that's because these language features are not used properly. > Type classes are the tool to write generic code and reduce combinatoric > explosion of functions and modules are a way to collect functions per > type. Following this principle you give function names that make sense > together with the module name like File.write or Channel.write. Then there > is no need for the compiler to disambiguate unqualified identifiers and > you keep the type and the module issues separated. The issue is with importing third-party modules, where you can't combine them into sensible type classes without writing you own abstraction layer. And in some cases, the similarities are in name only, so type classes wouldn't work in any case. -- View this message in context: http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes-tp5835927p5836376.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: TDNR without new operators or syntax changes
Yes, that it indeed was I meant. AntC seems to be replying to a much more complicated/invasive proposal than what I had intended, apologies if I wasn't clear. (I see in retrospect that I may have misunderstood the original TDNR proposal, understandably leading to confusion.) 1. If the compiler encounters a term f a, and there is more than one definition for f in scope (after following all of the usual rules for qualified imports); 2. And exactly one of these definitions matches the type of a (or the expected type of f if given); 3. Then this is the definition to use. That is all, although point 2 could be extended to consider the return type of f or other arguments as well. Even with the extension on, it would have no effect on programs which compile without it. This has nothing to do with ORF, which relies on magic type classes (although there is some overlap in what it can achieve). The primary use-case I had in mind is disambiguating name clashes between local and/or unqualified imports. Cross-posting to cafe and libraries as this doesn't seem to have attracted a lot of interest in users. Maybe it's just a boring proposal, maybe I didn't post it to the right list. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: TDNR without new operators or syntax changes
AntC wrote > I think you'll find rather a lot of those in existing code. > So this is a code-breaking change. Could you give an example of existing code that would break? This certainly wasn't what I had in mind. -- View this message in context: http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes-tp5835927p5836060.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: TDNR without new operators or syntax changes
AntC wrote
> No. For TDNR GHC needs some syntactic signal to trigger disambiguation.
> ...
> I suspect that if you took the syntax away from TDNR, you'd have very
> little left.
To copy an example from the TDNR wiki page:
module Foo where
import Button( Button, reset ) as B
import Canvas( Canvas, reset ) as C
f :: Button -> Canvas -> IO ()
f b c = do { B.reset b; C.reset c }
With syntaxless TDNR enabled, the last line could be:
f b c = do { reset b; reset c }
This requires no syntactic signal. The compiler will see two candidate
definitions for reset, and in each case, pick the one which matches its
argument.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes-tp5835927p5835978.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
TDNR without new operators or syntax changes
Previous attempts to propose TDNR [1] have met with opposition over the accompanying proposal to change the syntax of the dot or add a new operator for postfix application. However, nothing about TDNR - other than certain motivating examples - actually requires changes to the syntax of Haskell or new operators. TDNR could be implemented as an extension which just give GHC a new way of disambiguating function names, and nothing else. This would still have some advantages: - Redundant module qualification no longer required. - Unqualified imports could be changed to a different module with the same interface (a very poor-man's backpack) without any other code changes. - People who want TDNR with postfix function application will only need to define a simple postfix operator. I would therefore like to propose TNDR without any syntax/prelude changes. [1] https://prime.haskell.org/wiki/TypeDirectedNameResolution -- View this message in context: http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes-tp5835927.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
Towards the end of http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide//release-7-10-3.html: 1.7.3. Known bugs At the time of release there is a fix in the Cabal upstream respository, although it is not yet present in a release. "fix" is hyperlinked to itself, and it doesn't say what the fix is for. -- View this message in context: http://haskell.1045720.n5.nabble.com/ANNOUNCE-Glasgow-Haskell-Compiler-version-7-10-3-tp5823925p5823933.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: build ghc without ghci libraries?
Thanks, that worked great. -- View this message in context: http://haskell.1045720.n5.nabble.com/build-ghc-without-ghci-libraries-tp5823292p5823721.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
build ghc without ghci libraries?
I'm currently removing *.o after building ghc to save space (I don't need them for what I'm doing). Is there a straightforward way to tell GHC not to build them in the first place, such as --disable-library-for-ghci does for cabal, instead of deleting them after the fact? (I do need ghci support for template haskell.) To clarify, I'm building GHC itself, not using GHC to build a package. -- View this message in context: http://haskell.1045720.n5.nabble.com/build-ghc-without-ghci-libraries-tp5823292.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: SRC_HC_OPTS in perf build
Edward Z. Yang wrote Sounds like an oversight to me! Submit a fix? Excerpts from Jeremy's message of 2015-05-25 06:44:10 -0700: build.mk.sample contains the lines: # perf matches the default settings, repeated here for comparison: SRC_HC_OPTS = -O -H64m However, in config.mk.in this is: SRC_HC_OPTS += -H32m -O What actually is the default for SRC_HC_OPTS? Why does config.mk.in seem to set it to -H32m, then every profile in build.mk.sample sets -H64m? Which should it be? -- View this message in context: http://haskell.1045720.n5.nabble.com/SRC-HC-OPTS-in-perf-build-tp5809863p5809930.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
SRC_HC_OPTS in perf build
build.mk.sample contains the lines: # perf matches the default settings, repeated here for comparison: SRC_HC_OPTS = -O -H64m However, in config.mk.in this is: SRC_HC_OPTS += -H32m -O What actually is the default for SRC_HC_OPTS? Why does config.mk.in seem to set it to -H32m, then every profile in build.mk.sample sets -H64m? -- View this message in context: http://haskell.1045720.n5.nabble.com/SRC-HC-OPTS-in-perf-build-tp5809863.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
Thomas Miedema wrote It was all due to a missing -split-objs in Jeremy's 7.8 build. For the record, this appears to have been a bug in the 7.8 build system, as SplitObjs is supposed to be on by default. I only noticed when building 7.10, where the default was correct, and didn't understand why the GHC libraries has ballooned. -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768377.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: runghc and GhcWithInterpreter
Edward Z. Yang wrote runghc itself is just a little shell script which calls GHC proper with the -f flag, so I suppose the build system was just not set up to not create this link in that case. I have a binary called runghc under /usr/local/lib/ghc-7.10.1/bin in addition to the shell script under /usr/local/bin that references it. -- View this message in context: http://haskell.1045720.n5.nabble.com/runghc-and-GhcWithInterpreter-tp5768326p5768346.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
runghc and GhcWithInterpreter
I've built GHC with GhcWithInterpreter = NO. runghc is built and installed, but errors out with not built for interactive use. Is runghc supposed to work with such a build? If not, why is it built at all? -- View this message in context: http://haskell.1045720.n5.nabble.com/runghc-and-GhcWithInterpreter-tp5768326.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
skip hpc during build
I'm deleting hpc after building ghc for a vm to save space. Is there an easy way to skip building it in the first place? -- View this message in context: http://haskell.1045720.n5.nabble.com/skip-hpc-during-build-tp5768327.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
Thomas Miedema wrote That suggestion was completely misguided. Compiling with `-split-objs` makes a library _grow_ in size, but makes executables that link against it _smaller_. All these numbers are not far off from the ones you were getting. I think you have been comparing a 7.8.4 build of Cabal without split objects, with a 7.10.1 build of Cabal with split objects. I don't think there is a bug here. My GHC build is now back to the 7.8-era size. Thank you! I was wondering why programs compiled with my GHC 7.8 build were bigger than if I used an official build. Perhaps a bug in the 7.8 build system had turned off SplitObjs. -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768274.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
Very strange. If I download Cabal from hackage and build it with 'cabal build' the bloat disappears. cabal build: 18M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 21M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a /usr/local/lib/ghc-7.10.1: 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a This is my build.mk: SRC_HC_OPTS = -O -H64m GhcRTSWays = thr HADDOCK_DOCS = NO GhcHcOpts = GhcLibWays = v DYNAMIC_GHC_PROGRAMS = NO This is the same as I used for 7.8 without issue, except the addition of GhcHcOpts (because 7.8 ignored the default). -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768133.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
Building with https://downloads.haskell.org/~ghc/7.10.1/ghc-7.10.1-src.tar.xz -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768156.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
Thomas Miedema wrote: Maybe `split-objs` is not applied? * Stray `SplitObjs = NO` in your build.mk? Tried adding SplitObjs = YES, didn't help * You're on an old OS X with XCode 3.2? Debian Jessie -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768155.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Binary bloat in 7.10
Why do the 7.10 libraries take up so much more space than 7.8? For example, using the same build options and strip --strip-unneeded, 7.8 leaves me with 15M libHSCabal-1.18.1.5.a 17M HSCabal-1.18.1.5.o whereas 7.10 balloons to 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
Roman Cheplyaka-2 wrote I'm not denying (or confirming) your claim, but it would look more legitimate if you compared the same version of Cabal compiled with different versions of GHC. At least some of this bloat could be because Cabal simply gained more code. Tricky to test that because of dependencies and global package db. I haven't measured the amount of code in Cabal, but I doubt it's increased that much, and there has been a big jump in the installed size of every library. -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768080.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
It's not just binaries, even hi files have ballooned. (I should note that (stripped) executables appear to be unaffected.) -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768072.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
Karel Gardas wrote 7.10.1 should IIRC support some kind of DWARF debugging information and IIRC it was mentioned and decided on ghc devel that the libraries will ship with some DWARF to easy debugging -- but takes me lightly on it and verify if this is the case since I may be completely off and this may apply to GHC HEAD and not to 7.10.x Stripped all debugging, didn't help. -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768077.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
Roman Cheplyaka-2 wrote I'm not denying (or confirming) your claim, but it would look more legitimate if you compared the same version of Cabal compiled with different versions of GHC. At least some of this bloat could be because Cabal simply gained more code. I was going to prove you wrong by identifying packages which have barely changed for 7.10 ... and found that those packages were a similar size to their 7.8 versions. However, the size increase in other packages is huge, and simply gained more code doesn't seem like an adequate explanation, with some package more than doubling. Here are the full results: 7.8: 34M Cabal-1.18.1.5 3.8Marray-0.5.0.0 50M base-4.7.0.2 52M bin 368Kbin-package-db-0.0.0.0 2.7Mbinary-0.7.1.0 5.4Mbytestring-0.10.4.0 9.4Mcontainers-0.5.5.1 196Kdeepseq-1.3.0.2 608Kdirectory-1.2.1.0 740Kfilepath-1.3.0.2 105Mghc-7.8.4 2.7Mghc-prim-0.3.1.0 8.7Mhaskeline-0.7.1.2 3.4Mhoopl-3.10.0.1 1020K hpc-0.6.0.1 556Kinteger-gmp-0.5.1.0 680Kpretty-1.1.1.1 684Kprocess-1.2.0.0 1.6Mrts-1.0 13M template-haskell-2.9.0.0 1.4Mterminfo-0.4.0.0 6.1Mtime-1.4.2 4.4Mtransformers-0.3.0.0 5.2Munix-2.7.0.1 7.10: 83M Cabal_HWT8QvVfJLn2ubvobpycJY 3.7Marray_FaHmcBFfuRM8kmZLEY8D5S 52M base_I5BErHzyOm07EBNpKBEeUv 56M bin 2.9Mbinar_EKE3c9Lmxb3DQpU0fPtru6 832Kbinpa_JNoexmBMuO8C771QaIy3YN 5.7Mbytes_6vj5EoliHgNHISHCVCb069 11M conta_47ajk3tbda43DFWyeF3oHQ 432Kdeeps_FpR4obOZALU1lutWnrBldi 912Kdirec_3TcTyYedch32o1zTH2MR00 796Kfilep_5HhyRonfEZoDO205Wm9E4h 113Mghc_EMlWrQ42XY0BNVbSrKixqY 2.9Mghcpr_8TmvWUcS1U1IKHT0levwg3 8.9Mhaske_IlDhIe25uAn0WJY379Nu1M 3.4Mhoopl_JxODiSRz1e84NbH6nnZuUk 1.1Mhpc_CmUUQl5bURfBueJrdYfNs3 1.3Minteg_2aU3IZNMF9a7mQ0OzsZ0dS 1.8Mprett_7jIfj8VCGFf1WS0tIQ1XSZ 764Kproce_0hwN3CTKynhHQqQkChnSdH 1.7Mrts 19M templ_BVMCZyLwIlfGfcqqzyUAI8 1.4Mtermi_7qZwBlx3clR8sTBilJl253 6.2Mtime_Hh2clZW6in4HpYHx5bLtb7 7.3Mtrans_ALYlebOVzVI4kxbFX5SGhm 5.4Munix_G4Yo1pNtYrk8nCq1cx8P9d -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768083.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
Carter Schonwald wrote How much of this might be attributable to longer linker symbol names? Ghc 7.10 object code does have larger symbols! Is there a way to easily tabulate that? That would explain why the hi files have also increased many-fold. Is there any way to avoid the larger symbols? -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768095.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.10.1 Release Candidate 3
I haven't been able to test my build scripts with RC2 or RC3 because cabal-install won't install automatically from Hackage. Please release the fixed version. -- View this message in context: http://haskell.1045720.n5.nabble.com/ANNOUNCE-GHC-7-10-1-Release-Candidate-3-tp5767071p5767158.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Dynamic only GHC
I'm trying to build a minimal GHC 7.8.3 on Debian Wheezy with only dynamic libraries (this is for a system where disc space is scarce). I'm using this build.mk: GhcRTSWays = thr GhcLibWays = dyn HADDOCK_DOCS = NO DYNAMIC_BY_DEFAULT = YES GhcDynamic = YES Tried with and without GhcDynamic (asked on beginners how it's different to DYNAMIC_GHC_PROGRAMS but still waiting for an answer). It gets near the end of the build, then fails with: HC [stage 1] ghc/stage2/build/Main.dyn_o HC [stage 1] ghc/stage2/build/tmp/ghc-stage2 /usr/bin/ld: cannot find -lHSrts_thr-ghc7.8.3 collect2: error: ld returned 1 exit status make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1 make: *** [all] Error 2 If I build with only static libraries, everything seems to work OK. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic only GHC
Austin Seipp austin at well-typed.com writes: As far as I'm aware, Dynamic-by-default GHC is actually broken, and I don't know for how long this has been the case. For some history: originally when all this was being decided to try and fix the linker issues in GHC, dynamic by default was considered an option, but was rejected in favor of DynamicGhcPrograms. Why was it rejected? Well, dynamic by default particularly hurts 32bit x86, which suffers from a very pathetic set of registers, and dynamic programs steal one of these for the GOT (%ebx IIRC). On the other hand, DynamicGhcPrograms instead means GHC builds everything statically, *except itself*, which it builds as a dynamically linked executable. The idea is you dynamically link GHC itself to fix linker issues, and end-user programs remain static, which is the expected mode of operation. Thank you for the detailed explanation (although I still don't understand why DYNAMIC_BY_DEFAULT by default wasn't kept for x64.) Where does GhcDynamic fit into this? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic only GHC
So out of GhcDynamic, DYNAMIC_GHC_PROGRAMS, and DYNAMIC_BY_DEFAULT, which is broken, and what's the difference between GhcDynamic and DYNAMIC_GHC_PROGRAMS? This is getting somewhat confusing. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Does GHC 7.8 make targeting bare metal ARM any easier?
There have been at least a couple projects, such as hOp and HaLVM which attempt to run GHC on the bare metal or something similar. Both these projects required a substantial set of patches against GHC to remove dependencies things like POSIX/libc. Due to the highly invasive nature, they are also highly prone to bitrot. With GHC 7.8, I believe we will be able to cross-compile to the Raspberry Pi platform. But, what really appeals to me is going that extra step and avoiding the OS entirely and running on the bare metal. Obviously, you give up a lot -- such as drivers, network stacks, etc. But, there is also a lot of potential to do neat things, and not have to worry about properly shutting down an embedded linux box. Also, since the raspberry pi is a very limited, uniform platform, (compared to general purpose PCs) it is feasible to create network drivers, etc, because only one chipset needs to be supported. (Ignoring issues regarding binary blobs, undocumented chipsets, usb WIFI, etc). I'm wondering if things are any easier with cross-compilation support improving. My thought is that less of GHC needs to be tweaked? - jeremy ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error building ghc on raspberry pi.
My random guess is that /tmp is mounted using tmpfs (aka a RAM drive) and it got full. Try remounting /tmp to use the sdcard instead ? On Wed, Jan 2, 2013 at 7:32 PM, rocon...@theorem.ca wrote: I'm trying to build ghc-7.4.1 using ghc-7.4.1 on my raspberry pi (armv6l) and I get the following error: inplace/bin/ghc-stage1 -H32m -O-package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -no-user-package-conf -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o Stack dump: 0. Program arguments: llc -O3 -relocation-model=static /tmp/ghc6324_0/ghc6324_0.bc -o /tmp/ghc6324_0/ghc6324_0.lm_s 1. Running pass 'Function Pass Manager' on module '/tmp/ghc6324_0/ghc6324_0.bc'. 2. Running pass 'ARM Instruction Selection' on function '@ghczmprim_GHCziTypes_Czh_info' /tmp/ghc6324_0/ghc6324_0.lm_s: openBinaryFile: does not exist (No such file or directory) make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 make: *** [all] Error 2 Anyone have any thoughts on what might be the matter and what I can do to fix it. (If only openBinaryFile said which file doesn't exist.) -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
I have often wished for something like:
{-# LANGUAGE StringLiteralsAs Text #-}
where all string literals like:
f = foo
would be translated to:
f = (fromString foo :: Text)
I find that OverloadedStrings is too general and causes ambiguous type
errors. Additionally, I seldom find that I have more than one type of
string literal per file. Things tend to be all String, all Text, etc.
So, if I could just pick a concrete type for all the string literals
in my file, I would be happy.
- jeremy
On Sat, Apr 21, 2012 at 7:20 PM, Greg Weber g...@gregweber.info wrote:
I would like to default IsString to use the Text instance to avoid
ambiguous type errors.
I see defaulting capability is available for Num. Is there any way to
do this for IsString?
Thanks,
Greg Weber
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Template-haskell] change in [d| |] and creating instances in template-haskell 2.7
On Sep 8, 2011, at 4:00 AM, Simon Peyton-Jones wrote:
[Redireting to ghc users; the TH list is pretty dormant and I keep
thinking I should close it down altogether.]
Jeremy
Actually this is by design. See the long thread at
http://hackage.haskell.org/trac/ghc/ticket/5375
When you say
| inferBar typeName =
|do s - [d| bar _ = sucker
| |]
you are asking for a *new* definition bar _ = sucker. But in an
instance declaration you have to mention the *existing* method name.
Right. That makes sense.
To put it another way, do you expect this to work?
do { bar_nm - newName bar
; return (InstanceD [] type [FunD bar_nm rhs]) }
where you make up a *fresh name* (whose string-name is bar) and
use it in an instance declaration binding.
no.
I suppose you could argue that for the odd case of instance decls,
TH should ignore the exact identity of the method name, and just use
its string name. It would be convenient; but another weirdness too.
Yeah. I would expect this to work:
inferBar2 :: Name - Q [Dec]
inferBar2 typeName =
[d| instance Bar $(conT typeName) where
bar _ = sucker
|]
But I get the same error:
inferBar2 'Bool
==
show-test.hs:4:3-18
instance Bar Bool where
{ bar_aTK _ = sucker }
show-test.hs:4:3:
Warning: No explicit method nor default method for `bar'
In the instance declaration for `Bar Bool'
Presumably because bar is still being created as a *fresh name*. I
think in that version, it is more surprising that it does not work
because the whole instance declaration is inside the [d| |].
Additionally, it is not obvious (to me) how to work around the issue
and keep the code pretty / easily readable.
But, as you point out, making bar not be a fresh name there creates a
'special case'. So, that is not great either..
When you saw inferBar2, did you find it somewhat 'surprising' that it
didn't work ?
- jeremy
User advice welcome!
Simon
| -Original Message-
| From: template-haskell-boun...@haskell.org [mailto:template-haskell-
| boun...@haskell.org] On Behalf Of Jeremy Shaw
| Sent: 07 September 2011 20:50
| To: template-hask...@haskell.org
| Subject: [Template-haskell] change in [d| |] and creating
instances in template-
| haskell 2.7
|
| Hello,
|
| I have some code that likes like this, which works in template-
haskell
| 2.5 / GHC 7.0.3:
|
| ---
| {-# Language TemplateHaskell, TypeFamilies #-}
| module Show where
|
| import Language.Haskell.TH
|
| class Bar a where
|bar :: a - String
|
| inferBar :: Name - Q [Dec]
| inferBar typeName =
|do s - [d| bar _ = sucker
| |]
| d - instanceD (return []) (appT (conT ''Bar) (conT typeName))
| (map return s)
| return [d]
|
| -
|
| $(inferBar ''Bool)
|
| But, in template-haskell 2.6 / GHC 7.2.1, I get an error,
|
| Warning: No explicit method nor default method for `bar'
| In the instance declaration for `Bar Bool'
|
| Comparing the output of -ddump-splices we see in GHC 7.0.3/ TH
2.5, we
| have:
|
| bar-test.hs:1:1: Splicing declarations
| inferBar 'Bool
|==
| bar-test.hs:4:3-17
| instance Bar Bool where
| { bar _ = sucker }
|
| But in GHC 7.2.1 / TH 2.6 we have:
|
| bar-test.hs:1:1: Splicing declarations
| inferBar 'Bool
|==
| bar-test.hs:4:3-17
| instance Bar Bool where
| { bar_acAU _ = sucker }
|
| The difference being that instead 'bar' we have 'bar_acAU'. So
maybe
| that is why it can't find the method 'bar' in the instance
| declaration? Though, I would kind of expect an error like,
|
| `bar_acAU' is not a (visible) method of class `Bar'.
|
| Am I doing something wrong? Should I file a bug ?
|
| Thanks!
|
| - jeremy
|
|
|
| ___
| template-haskell mailing list
| template-hask...@haskell.org
| http://www.haskell.org/mailman/listinfo/template-haskell
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Template-haskell] change in [d| |] and creating instances in template-haskell 2.7
Ah cool.
I just patched the code so that it uses mkName explicitly for now
since it is Happstack related code and I want it to work the most
places possible.
Thanks!
- jeremy
On Sep 8, 2011, at 12:07 PM, Simon Peyton-Jones wrote:
| Yeah. I would expect this to work:
|
| inferBar2 :: Name - Q [Dec]
| inferBar2 typeName =
|[d| instance Bar $(conT typeName) where
| bar _ = sucker
| |]
|
| But I get the same error:
|
| inferBar2 'Bool
|==
| show-test.hs:4:3-18
| instance Bar Bool where
| { bar_aTK _ = sucker }
Yes that should work. And it does with HEAD. I fixed a bunch of
stuff in the ticket I cited. Maybe try a snapshot distribution?
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: handleToFd without closing of the file descriptor
At line 206 of this file there is a withFd function that might suit your needs,
https://patch-tag.com/r/mae/sendfile/snapshot/current/content/pretty/src/Network/Socket/SendFile/Internal.hs
-- The Fd should not be used after the action returns because the
-- Handler may be garbage collected and than will cause the finalizer
-- to close the fd.
withFd :: Handle - (Fd - IO a) - IO a
#ifdef __GLASGOW_HASKELL__
#if __GLASGOW_HASKELL__ = 611
withFd h f = withHandle_ withFd h $ \ Handle__{..} - do
case cast haDevice of
Nothing - ioError (ioeSetErrorString (mkIOError IllegalOperation
withFd (Just h) Nothing)
handle is not a file descriptor)
Just fd - f (Fd (fromIntegral (FD.fdFD fd)))
#else
withFd h f =
withHandle_ withFd h $ \ h_ -
f (Fd (fromIntegral (haFD h_)))
#endif
#endif
It uses GHC internals stuff, so it could easily break someday.
On Thu, Jan 27, 2011 at 2:00 PM, Volker Wysk p...@volker-wysk.de wrote:
Hello
I need to get the file descriptor, which is encapsulated inside a handle.
handleToFd gets it, but the fd is closed. Is it possible to extract the fd
from the handle, without modifying the handle?
Greetings,
Volker
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.0.1 (or very strange dimensional-0.8.0.1) bug
There is a weird type-checking bug in 7.0.1 that causes loopy behavior: http://hackage.haskell.org/trac/ghc/ticket/4809 Not sure if that is what is happening to you or not. Though in my experience it did not actually print loop, it just hung. - jeremy On Jan 25, 2011, at 10:48 AM, Pavel Perikov wrote: On 25.01.2011, at 18:37, Bjorn Buckwalter wrote: (I suspect the type inferencer is looping), but maybe you've figured out something workable for you already. I told you I'm exhausted right now, didn't I? :) This is definitely not type inferencer. The bug causes compiled program looping. And I have at least one case when let-trick fixes the behavior in compiled program. Pavel. Thanks, Bjorn (Sorry for the re-repost, Pavel, my incompetence is matched only by my perseverance.) On Tue, Jan 25, 2011 at 22:02, Pavel Perikov peri...@gmail.com wrote: in ghci: Prelude import Numeric.Units.Dimensional.Prelude as D Prelude Numeric.Units.Dimensional.Prelude D.sqrt $ let s = 9 *~ (meter D.* meter) in s 3.0 m Prelude Numeric.Units.Dimensional.Prelude D.sqrt $ 9 *~ (meter D.* meter) ghci hangs. complied and optimized code detects loop and let-trick from the above does not help. Here's the complete ghci -v session which contains all package versions ghci -v GHCi, version 7.0.1: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 7.0.1, for Haskell 98, stage 2 booted by GHC version 6.12.3 Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.0.1-i386/usr/lib/ ghc-7.0.1/package.conf.d/package.cache Using binary package database: /Users/pavel/.ghc/i386-darwin-7.0.1/package.conf.d/package.cache hiding package containers-0.3.0.0 to avoid conflict with later version containers-0.4.0.0 hiding package QuickCheck-2.3.0.2 to avoid conflict with later version QuickCheck-2.4.0.1 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-0713122c5f9038c6f0355a37e294e054 wired-in package integer-gmp mapped to integer-gmp-0.2.0.2-bfb191b8468e4d812a2bb92622cb246e wired-in package base mapped to base-4.3.0.0-1ea085b64a078bd9d5eaa9d8d525e35e wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.5.0.0-f262af1f92a427f5cf4133bff041044f wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: -static Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude import Numeric.Units.Dimensional.Prelude as D hiding package containers-0.3.0.0 to avoid conflict with later version containers-0.4.0.0 hiding package QuickCheck-2.3.0.2 to avoid conflict with later version QuickCheck-2.4.0.1 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-0713122c5f9038c6f0355a37e294e054 wired-in package integer-gmp mapped to integer-gmp-0.2.0.2-bfb191b8468e4d812a2bb92622cb246e wired-in package base mapped to base-4.3.0.0-1ea085b64a078bd9d5eaa9d8d525e35e wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.5.0.0-f262af1f92a427f5cf4133bff041044f wired-in package dph-seq not found. wired-in package dph-par not found. *** Parser: hiding package containers-0.3.0.0 to avoid conflict with later version containers-0.4.0.0 hiding package QuickCheck-2.3.0.2 to avoid conflict with later version QuickCheck-2.4.0.1 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-0713122c5f9038c6f0355a37e294e054 wired-in package integer-gmp mapped to integer-gmp-0.2.0.2-bfb191b8468e4d812a2bb92622cb246e wired-in package base mapped to base-4.3.0.0-1ea085b64a078bd9d5eaa9d8d525e35e wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.5.0.0-f262af1f92a427f5cf4133bff041044f wired-in package dph-seq not found. wired-in package dph-par not found. Prelude Numeric.Units.Dimensional.Prelude D.sqrt $ let s = 9 *~ (meter D.* meter) in s hiding package containers-0.3.0.0 to avoid conflict with later version containers-0.4.0.0 hiding package QuickCheck-2.3.0.2 to avoid conflict with later version QuickCheck-2.4.0.1 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-0713122c5f9038c6f0355a37e294e054 wired-in package integer-gmp mapped to integer-gmp-0.2.0.2-bfb191b8468e4d812a2bb92622cb246e wired-in package base mapped to base-4.3.0.0-1ea085b64a078bd9d5eaa9d8d525e35e wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.5.0.0-f262af1f92a427f5cf4133bff041044f wired-in package dph-seq not found. wired-in package dph-par not found. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package old-locale-1.0.0.2 ... linking ... done. Loading package time-1.2.0.3 ... linking ... done. Loading package numtype-1.0 ... linking ... done. Loading package dimensional-0.8.0.1 ... linking ... done. 3.0 m
Re: change in overlapping instance behavior between GHC 6.12 and GHC 7 causes compilation failure
Hello,
I have narrowed this down further to a single file. And created a trac
bug for it:
http://hackage.haskell.org/trac/ghc/ticket/4485
This is (the only thing?) holding up HSP and happstack moving to GHC 7.
- jeremy
On Tue, Nov 2, 2010 at 5:36 PM, Jeremy Shaw jer...@n-heptane.com wrote:
Hello,
I have a module, XMLGenerator, which has some overlapping instances.
I have a second module, Test, which imports that module and also adds
some more overlapping instances.
Both modules contain {-# LANGUAGE OverlappingInstances #-} at the top.
Under some old version of 6.13 (and probably 6.12), if I put both
modules in the same directory and try to load Test.hs, it gets the
error:
Test.hs:16:15:
  Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m))
   arising from a use of `asChild' at Test.hs:16:15-21
  Matching instances:
   instance (m1 ~ m, EmbedAsChild m c) =
       EmbedAsChild m (XMLGenT m1 c)
    -- Defined at XMLGenerator.hs:16:10-68
   instance (XML m ~ x, XMLGen m) = EmbedAsChild m x
    -- Defined at XMLGenerator.hs:19:10-51
  In the first argument of `($)', namely `asChild'
  In the expression: asChild $ (genElement foo)
  In the definition of `asChild':
    asChild b = asChild $ (genElement foo)
If I put the XMLGenerator module in a separate package, dummy-hsx, and
the Test modules links against it, I still get the error.
*but* if I add:
 Extensions:    OverlappingInstances
to the dummy-hsx.cabal file, then Test.hs compiles just fine! So, for
starters, I do not understand why that happens.
Under GHC 7.0rc1, modifying the .cabal file has no effect. Instead I
always get the error:
Test.hs:16:15:
  Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m))
   arising from a use of `asChild'
  Matching instances:
   instance [overlap ok] (m1 ~ m, EmbedAsChild m c) =
              EmbedAsChild m (XMLGenT m1 c)
    -- Defined in XMLGenerator
  (The choice depends on the instantiation of `m'
  To pick the first instance above, use -XIncoherentInstances
  when compiling the other instance declarations)
Adding the IncoherentInstances flag does make it compile -- but I have
never enabled that flag and not regretted it.
What changed between GHC 6.12 and GHC 7.0? Is there a some solution
besides using IncoherentInstances in every module that imports
XMLGenerator?
I have attached XMLGenerator.hs, Test.hs, and dummy-hsx.cabal.
thanks!
- jeremy
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ClockTime closure linking issue
My first guess is that it is another instance of this bug: http://hackage.haskell.org/trac/ghc/ticket/3799 You might be able to use this option: --haddockdir=DIRinstallation directory for haddock interfaces though perhaps that flag is only in the latest version of cabal / ghc. - jeremy On Apr 5, 2010, at 4:43 AM, Gracjan Polak wrote: Hi all, Probable bug in GHC, I want to inquire before I report it proper. Did anybody see something like this: c:\Sources\happstack\happstack\templates\projectcabal build [1 of 1] Compiling Main ( Setup.hs, dist\setup\Main.o ) Linking .\dist\setup\setup.exe ... Preprocessing executables for guestbook-1.0... Building guestbook-1.0... [11 of 11] Compiling Main ( src\Main.hs, dist\build \guestbook-server \guestbook-server-tmp\Main.o ) Linking dist\build\guestbook-server\guestbook-server.exe ... dist\build\guestbook-server\guestbook-server-tmp\GuestBook \State2.o:fake:(.text+ 0x6d89): undefined reference to `happstackzm0zi4zi3_HappstackziStateziClockTime_ constrZMabmKZN_closure' dist\build\guestbook-server\guestbook-server-tmp\GuestBook \State2.o:fake:(.text+ 0x6dd1): undefined reference to `happstackzm0zi4zi3_HappstackziStateziClockTime_ dataTypeZMabmJZN_closure' [...lots of same messages skipped...] collect2: ld returned 1 exit status Application is from http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack/templates/project The Glorious Glasgow Haskell Compilation System, version 6.12.1 System Windows Vista 32bit. Help! -- Gracjan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: I accidentally the Prelude
I would still vote for that error in the 'worst ghc error message contest'. I got it just last night with 6.13 when I tried to run the Setup.hs function in base: ~/n-heptane/projects/haskell/darcs/base-3.0.3.2 $ rm Setup.o Setup.hi ~/n-heptane/projects/haskell/darcs/base-3.0.3.2 $ ghc --make -O2 Setup.hs -o s [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Setup.hs:1:1: attempting to use module `Prelude' (./Prelude.hs) which is not loaded ~/n-heptane/projects/haskell/darcs/base-3.0.3.2 $ runhaskell Setup.hs configure Setup.hs:1:1: attempting to use module `Prelude' (./Prelude.hs) which is not loaded ~/n-heptane/projects/haskell/darcs/base-3.0.3.2 $ In this case it does at least mention the path to the troublesome file. But I still have no idea why it is not loaded** (In this particular case I don't want it loaded. Though I believe there are other similar situations where I do..) ** well, from experience I know that it is 'not loaded' because it can't decide if it should load the source, or use the version installed in the package library. But the first time I saw the message, I was quite confused. But, perhaps there are other cases when this error can occur? - jeremy On Tue, Mar 2, 2010 at 5:21 AM, Simon Marlow marlo...@gmail.com wrote: On 02/03/2010 08:59, Josef Svenningsson wrote: On Mon, Mar 1, 2010 at 11:54 PM, Jeremy Shawjer...@n-heptane.com wrote: is there, by chance, a file named Prelude.hs in the working directory? (the directory you are in when you type ghci?) - jeremy Ah. Thanks! That was indeed the problem. Though I think ghci:s response could be a little bit more transparent. Sure, how about this: $ touch Prelude.hs $ ghci GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude ie. with 6.12.1 it just works. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Installing syb(-0.1.03) package in head version of Haskell
On Tue, Feb 23, 2010 at 10:12 AM, Ross Paterson r...@soi.city.ac.uk wrote: On Tue, Feb 23, 2010 at 03:05:56PM -, Bayley, Alistair wrote: Just a wild guess, but the package description has this non-ascii text: author: Ralf Lämmel, Simon Peyton Jones It could well be Latin-1 encoded, rather than UTF8. No, syb-0.1.0.3/syb.cabal is UTF-8-encoded (conforming to the Cabal docs). I had similar issues when attempting to install a new version of syb over an old version[1]. I had to open this file in emacs: /usr/lib/ghc-6.13/package.conf.d/syb-0.1.0.3.conf and the do: M-x set-buffer-file-coding-system utf-8 I think there was a point in time where something wrote contains to that file as latin1 instead of utf-8 or something. - jeremy [1] it might have actually been the same version of syb, but rebuilt with a different version of the compiler or something.. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to get the file descriptor of a handle?
Hello, In GHC 6.12 there is no guarantee that a Handle is backed up by a file descriptor. That said, check out the handleToFd defined on line 141 here: http://patch-tag.com/r/mae/sendfile/snapshot/current/content/pretty/src/Network/Socket/SendFile/Internal.hs A better type might be: handleToFd :: Handle - IO (Maybe Fd) instead of raising an exception. Having a Handle not backed by a Fd is not really an 'exceptional' condition after all. - jeremy On Feb 13, 2010, at 6:23 AM, Volker Wysk wrote: Hello I'd like to know how you get the file descriptor, which is incapsulated in a handle. The libraries GHC.IO.Handle/ GHC.IO.Handle.FD only provide for the other direction. The function haFD, which I've used before I've updated to the current version of GHC (6.12), appears to be in use two times in the libraries. But there isn't a definition anywhere. Any help would be appreciated. Cheers, Volker -- Volker Wysk p...@volker-wysk.de ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: Happstack 0.4.1
Hello Simon,
I have seen several manifestations of this issue now. I filed a report
here:
http://hackage.haskell.org/trac/ghc/ticket/3799
- jeremy
On Dec 30, 2009, at 5:37 AM, Simon Marlow wrote:
On 22/12/09 03:33, Antoine Latter wrote:
On Mon, Dec 21, 2009 at 6:31 AM,jer...@n-heptane.com wrote:
Hello,
That sort of missing symbol error at link time is often (but not
always) a
sign that some libraries got recompiled but not others. So there are
references to the old symbol names hanging around.
I would try to ghc-pkg unregister syb-with-class and everything
that depends
on it, and then try cabal install happstack again.
I'm pretty well stumped at this point. I've cleared off everything
and
gone up to GHC 6.12 HEAD, and a 'cabal install happstack-data' gives
me the same symbol not defined error in Happstack.Data.Xml.Base.
But here's the spooky part, if I run it by hand like so:
ghc --make src/Happstack/Data/Xml/Base.hs
src/Happstack/Data/Default.hs src/Happstack/Data/
DeriveAll.hs src/Happstack/Data/Normalize.hs src/Happstack/Data/
Migrate.hs
after resolving issues due to CPP not being run, everything runs to
completion, no errors. Also, the list of things we're pulling in
during the template-haskell execution is much smaller (see bellow).
Has anyone seen this, where template-haskell behaves different when
run from cabal-install (or Setup.hs) than from ghc --make (or ghci)?
2 of 5] Compiling Happstack.Data.Migrate (
src/Happstack/Data/Migrate.hs, src/Happstack/Data/Migrate.o )
[3 of 5] Compiling Happstack.Data.Default (
src/Happstack/Data/Default.hs, src/Happstack/Data/Default.o )
[4 of 5] Compiling Happstack.Data.DeriveAll (
src/Happstack/Data/DeriveAll.hs, src/Happstack/Data/DeriveAll.o )
[5 of 5] Compiling Happstack.Data.Xml.Base (
src/Happstack/Data/Xml/Base.hs, src/Happstack/Data/Xml/Base.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading package array-0.3.0.0 ... linking ... done.
Loading package bytestring-0.9.1.5 ... linking ... done.
Loading package containers-0.3.0.0 ... linking ... done.
Loading package pretty-1.0.1.1 ... linking ... done.
Loading package syb-0.1.0.2 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package syb-with-class-0.6.1 ... linking ... done.
mkUsageInfo: internal name? Element{tc a4av}
Did you submit a ticket for this? I don't recall seeing one.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Missing Data.Map library? GHC 6.8.2 under OS X
At Mon, 9 Jun 2008 15:42:40 -0400, Thomas Krauss wrote: I seem to be having trouble using GHC 6.8.2 and OS X (10.5). It seems that any use of anything from Data.Map results in a link error like Undefined symbols: ___stginit_containerszm0zi1zi0zi1_DataziMap_, referenced from: ___stginit_Main_ in tst_parse.o ld: symbol(s) not found In my experience, you will get this error if you have some libraries which were built against an older version of Data.Map and then you upgraded to the new Data.Map without rebuilding those libraries. Or, if you just have some .o/.hi files in your local directory that were built against the old Data.Map. Have you tried creating a very simple new project like: module Main where import Data.Map main = print (empty :: Map Int Int) $ ghc --make Main.hs -o test If that fails, then the problem is likely with your GHC 6 installation itself, not some stale third party library. Have you previously installed GHC 6 on this machine? If so, perhaps the old version was not completely removed and the compiler is getting mixed up. Alternatively, perhaps the new version requires you to install some extra package to get all the libraries, instead of just the core libraries ? Looking at the binary distribution page, that does not appear to be the case. j. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: State of parallel GC?
Hello, Is real-time, parallel garbage collection at all feasible? My thinking is, real-time garbage collection requires the garbage collector to be able to work on the problem in small, predictable, pieces. That seems like something which would also be useful for scaling up GC to multiple cores? I am curious, because I have a project in mind that would benefit greatly from real-time, parallel garbage collection :) j. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.8.1 Release Candidate
At Thu, 13 Sep 2007 13:26:05 +0100, Ian Lynagh wrote: Hi Stefan, On Thu, Sep 13, 2007 at 07:55:21AM +0200, Stefan Holdermans wrote: We are pleased to announce the Release Candidate phase for GHC 6.8.1. That's 6.8, right? Or have I missed something? No, it's 6.8.1: http://www.haskell.org/ghc/dist/current/docs/users_guide/version-numbering.html Seems like something is wrong with this version number though: Snapshots beginning with 6.8.20070909 are release candidates for 6.8.1 In many version numbering schemes, 6.8.20070909 would be a higher version than 6.8.1. According to policy: Stable snapshot releases are named x.y.z.MMDD. where MMDD is the date of the sources from which the snapshot was built, and x.y.z+1 is the next release to be made on that branch. For example, 6.8.1.20040225 would be a snapshot of the 6.8 branch during the development of 6.8.2. *Main let version (x,y,z+1) date = concat [ show x, ., show y, ., show z, ., date] *Main version (6,8,1) 20070909 6.8.0.20070909 ;) j. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
At Thu, 1 Mar 2007 11:38:54 -0600, John Goerzen wrote: On Thu, Mar 01, 2007 at 04:21:45PM +, Simon Marlow wrote: Between that and the lack of support for forkProcess in Hugs, this renders anything that needs to fork and then do I/O as being usable only in GHC-compiled code. Which is sub-optimal, but livable anyway. I guess I'm really wondering why you need to fork and do I/O at all. Can you describe the problem at a higher level? I am, for all intents and purposes, writing what amounts to a simple shell. The neat thing about the library is that external commands and haskell code can be freely intermixed, and are uniformly handled. For example, in this pipeline, r - runS (ls -l -|- grep i -|- wcL ) wcL is a simple haskell function: wcL :: [String] - [String] wcL inp = [show $ genericLength inp] The HSH library just creates some pipes to hook the processes together, and then forks of ls, grep, and wcL as seperate processes. The advantage of this scheme is that once the pipeline is started, everything behaves the same way it would if you had run the bash command: $ ls -l | grep i | wcL So, you get very familiar behaviour/performance from a shell scripting point of view. But, you also get to easily stick haskell functions in your pipeline. Poking around with the full HSH code, I *think* I got pipelines that *only* called external commands working fine[1]. This seems logical, since the external commands do not care about the Haskell I/O manager at all. So, perhaps you can have an alternate version of 'instance ShellCommand (String - IO String)' that gets used for -threaded that uses forkOS instead of forkProcess. All of the external commands would still be forked into seperate processes, but all of the haskell commands would run in the same threaded process. Obviously, you would have to fake the return code, but it looks like that should be feasible. Some open questions are: a) how do you detect that you are running in the threaded RTS b) can you have the linker pick the correct version at link time, so that you do not have to have a compile-time check. Of course, a compile time check might only have to be done once, so the overhead would not be significant. j. [1] In fact, they may work fine out of the box, I haven't tested that. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
At Wed, 28 Feb 2007 11:15:04 -0600, John Goerzen wrote: You can see my test case with: darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh ghc -fglasgow-exts --make -o test2 test2.hs I get an erro when I use that darcs command-line, and test2.hs does not appear to be in the directory afterwards. Am I doing something wrong ? $ darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh Copying patch 54 of 54... done! Applying patch 54 of 54... done. darcs: Couldn't find a tag matching tag-name glasgow ml $ dpkg -l darcs Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii darcs 1.0.9~rc1-0.1 an advanced revision control system j. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Hello, Your first problem is just a line buffering issue. You need to explicitly set the line buffer inside the child processes: redir fstdin stdInput hSetBuffering stdin LineBuffering redir fstdout stdOutput hSetBuffering stdout LineBuffering This is because the forked child process in not hooked up to a tty, so GHC decides that block buffering would be a good choice. Once you fix that you will encounter some new race condition type bugs. These bugs will show up, even *without* the -threaded flag. hth, j. At Wed, 28 Feb 2007 13:29:17 -0600, John Goerzen wrote: On Wed, Feb 28, 2007 at 10:40:18AM -0800, Jeremy Shaw wrote: At Wed, 28 Feb 2007 11:15:04 -0600, John Goerzen wrote: You can see my test case with: darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh ghc -fglasgow-exts --make -o test2 test2.hs I get an erro when I use that darcs command-line, and test2.hs does not appear to be in the directory afterwards. Am I doing something wrong ? Oops. I hadn't pushed out that tag yet. It's there now. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Hello, Hrm, setting the LineBuffering mode had the side-effect of setting the underlying file description to non-blocking mode. When the executeFile process took over, it would die with an error about 'standard input temporarily unavailable'. So, ignore that. j. At Wed, 28 Feb 2007 15:23:53 -0600, John Goerzen wrote: On Wed, Feb 28, 2007 at 01:06:25PM -0800, Jeremy Shaw wrote: Hello, Your first problem is just a line buffering issue. You need to explicitly set the line buffer inside the child processes: redir fstdin stdInput hSetBuffering stdin LineBuffering redir fstdout stdOutput hSetBuffering stdout LineBuffering Hi Jeremy, First, many thanks for looking into this. That doesn't make sense to me, since these aren't used for anything in Haskell prior to the call to executeFile. The Haskell buffers should just disappear, since the Haskell process disappears, right? Once you fix that you will encounter some new race condition type bugs. These bugs will show up, even *without* the -threaded flag. Hrm, could you point out a couple? I'm developing as many unit tests as I can, and haven't had any problem running them under a non-threaded GHC. I am aware that the debug statements can write over each other at some cases, or even get inserted into the pipeline in a few situations, but these are only used in exceptional cases and will generally be removed from the code before too long. Other than that, I think I've got it OK. My unit tests are covering singleton commands and 2-4 commands in a pipe, including various permutations of calls to external programs and Haskell functions. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Hello, Here is a simplified example that seems to exhibit the same behaviour, unless I screwed up: --- module Main where import System.Posix import System.IO import System.Exit main = do putStrLn running... (stdinr, stdinw) - createPipe (stdoutr, stdoutw) - createPipe pid - forkProcess $ do hw - fdToHandle stdoutw hr - fdToHandle stdinr closeFd stdinw hGetContents hr = hPutStr hw hClose hr hClose hw exitImmediately ExitSuccess closeFd stdoutw closeFd stdinw hr2 - fdToHandle stdoutr hGetContents hr2 = putStr getProcessStatus True False pid = print --- Compiling with: ghc --make -no-recomp test3.hs -o test3 ./test3 works. But compiling with: ghc --make -no-recomp -threaded test3.hs -o test3 ./test3 results in a hang. If you comment out the hGetContents hr = and change 'hPutStr hw' to 'hPutStr hw hi', then it seems to work ok. As you suggested, it seems that hGetContents is not ever seeing the EOF when -threaded is enabled. I think it gets 'Resource temporarily unavailable' instead. So, it keeps retrying. Assuming I have recreated the same bug, we at least have a simpiler test case now... j. At Wed, 28 Feb 2007 11:15:04 -0600, John Goerzen wrote: Hi, I've been hitting my head against a wall for the past couple of days trying to figure out why my shell-like pipeline code kept hanging. I found fd leakage (file descriptors not being closed), which disrupts EOF detection and can lead to deadlocks. I just couldn't find the problem. I finally tried compiling my test with ghc instead of running it in ghci. And poof, it worked fine the first time. I tried asking on #haskell, and got the suggestion that ghci uses -threaded. I tried compiling my test program with ghc -threaded, and again, same deadlock. My program never calls forkIO or forkOS or any other threading code. You can see my test case with: darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh ghc -fglasgow-exts --make -o test2 test2.hs That'll run fine. If you add -threaded, it will hang. Ideas? Thanks, -- John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bignums, gmp, bytestring, .. ?
At Sun, 19 Nov 2006 13:46:10 -0500, Peter Tanski wrote: What is the problem building GMP for PalmOS? According to the GMP install documentation, it supports ARM and Motorola's m68k processors, so you would not be using generic C code. You are probably also using PRC-Tools, correct? Yes. I can not get past the configure step. I tried to build gmp 4.2.1 with prc tools 2.3. I ran configure with these options: ./configure --build=i386-linux-gnu --host=m68k-palmos But, all the test programs (conftest.c) fail to link because they use 'main ()', but palmos expects 'PilotMain ()'. I hack the configure script and changed all occurances of 'main ()' to 'PilotMain ()', but then it failed beacuse the test programs could not find MemoryMgr.h. So I invoked configure with: CFLAGS=-I=/root/n-heptane/projects/haskell/palmos/sdk-5r3/include/ ./configure --build=i386-linux-gnu --host=m68k-palmos But now it fails to find working compiler with this error (from config.log): configure:7756: checking build system compiler m68k-palmos-gcc -I=/root/n-heptane/projects/haskell/palmos/sdk-5r3/include/ configure:7769: m68k-palmos-gcc -I=/root/n-heptane/projects/haskell/palmos/sdk-5r3/include/ conftest.c /usr/lib/gcc-lib/m68k-palmos/2.95.3-kgpd/libgcc.a(_exit.o)(.text+0x10): In function `exit': libgcc2.c: undefined reference to `_cleanup' /usr/lib/gcc-lib/m68k-palmos/2.95.3-kgpd/libgcc.a(_exit.o)(.text+0x16):libgcc2.c: undefined reference to `_exit' collect2: ld returned 1 exit status And, around this time, my interest in running yhi on PalmOS starts to wane. j. Using autoconf is like playing chess from 20 feet away by flicking a rope to move the pieces -mbp ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bignums, gmp, bytestring, .. ?
At Sat, 18 Nov 2006 00:44:32 +, Neil Mitchell wrote One advantage you probably haven't thought of is the size of the binary. Currently GMP adds about 50Kb on to the Yhc runtime, for what in the most cases is probably an occasional addition. If the bytecode for a bignum library was less than this then there could be a substantial size saving. On a related note -- dropping the gmp requirement would also make it easier to port yhc to non-unix platforms. I have tried on a few occasions to compile the yhc runtime for PalmOS, but I can never get gmp built for PalmOS. So, a byte-code version could be advantageous there too. I don't plan to do a lot of bignum intensive computation, so it would not be a problem if the byte-code version was 10 or 100 times slower. j. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Help with unregisterised build
Hello GHC users, I've attempted to build an installation of GHC which uses unregisterised libraries, but have not had much success. I am new to GHC's build system and would be grateful for some advice. I'm trying to build the 6.4.2 source distribution on an x86 linux machine, using GHC 6.4.2 (the Generic Linux with glibc2.3 version on the download page.) The target is the same machine. I've created a mk/build.mk file containing just the line: GhcUnregisterised = YES which, according to the comment in mk/config.mk, ought to build the unregisterised libraries that I'm after (and use them by default.) I run configure as follows: ./configure --prefix=$HOME/ghc_u and then simply make. After some time, the build fails with the following: ==fptools== make all -wr; in /mnt/raid/home/jeremyrw/src/src/ghc-6.4.2/libraries/base ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -ignore-package base -O -Rghc-timing -fgenerics -fgenerics -split-objs-c GHC/Err.lhs-boot -o GHC/Err.o-boot -ohi GHC/Err. hi-boot ghc: 13862608 bytes, 4 GCs, 102828/102828 avg/max bytes residency (1 samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.03 MUT (0.03 elapsed), 0.00 GC (0.02 elapsed) :ghc rm -f GHC/Base.o; if [ ! -d GHC/Base_split ]; then mkdir GHC/Base_split; else /usr/bin/find GHC/Base_split -name '*.o' -print | xargs rm -f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -ignore-package base -O Rghc-timing -fgenerics -fgenerics -split-objs-c GHC/Base.lhs -o GHC/Base.o -ohi GHC/Base.hi /tmp/ghc4237.s: Assembler messages: /tmp/ghc4237.s:17: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:29: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:41: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:53: Error: symbol `__stg_split_marker' is already defined This goes on for a while ... /tmp/ghc4237.s:16568: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:16614: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:16660: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:16706: Error: symbol `__stg_split_marker' is already defined ghc: 124912780 bytes, 12 GCs, 808164/1513632 avg/max bytes residency (2 samples), 19M in use, 0.00 INIT (0.00 elapsed), 0.59 MUT (2.39 elapsed), 0.10 GC (0.09 elapsed) :ghc make[2]: *** [GHC/Base.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/mnt/raid/home/jeremyrw/src/src/ghc-6.4.2/libraries' make: *** [build] Error 1 I've also tried with the following build.mk (I was guessing the -fvia-C might avoid the above assembler problem.): GhcUnregisterised = YES GhcLibHcOpts = -O -fvia-C but it fails in the same way. I'm not sure what to do at this point. Am I missing something in the build.mk? My ultimate goal is to link a Haskell object, which exports one of its functions via the FFI, with some other objects, into a single shared object. To do this I will need to compile everything with gcc's -fPIC flag, hence the need for unregisterised libraries. To go that extra step (to get relocatable GHC libraries), I'm guessing that I'll need to extend the GhcLibHcOpts line in build.mk with: -optc -fPIC. Will I need to do that for the run-time system as well? i.e. adding a line like: GhcRtsHcOpts = -fvia-C -optc '-fPIC' Is there likely to be anything else that needs to be tweaked? Has anybody had any success with this sort of thing before? Regards, Jeremy On Yahoo!7 Answers: 25 million answers and counting. Learn something new today http://www.yahoo7.com.au/answers ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building NewBinary with ghc 6.5
Hrm, Odd. The cabal code looks like it should be outputting the command-line that it uses to invoke ghc-pkg, but it does not work here either. Perhaps that is a cabal bug. In any case, I think it is just running: ghc-pkg update .installed-pkg-config If you run that command, does it generate the same error ? Can you paste the contents of your .installed-pkg-config? Thanks. j. At Wed, 26 Jul 2006 01:07:54 +0100, Joel Reymont wrote: Close but no cigar! sudo runhaskell Setup.lhs install -v5 directory dist/doc/html does exist: False Installing: /usr/local/lib/NewBinary-0.1/ghc-6.5 /usr/local/bin NewBinary-0.1... copy dist/build/NewBinary/FastMutInt.hi to /usr/local/lib/ NewBinary-0.1/ghc-6.5/NewBinary/FastMutInt.hi copy dist/build/NewBinary/Binary.hi to /usr/local/lib/NewBinary-0.1/ ghc-6.5/NewBinary/Binary.hi copy dist/build/libHSNewBinary-0.1.a to /usr/local/lib/NewBinary-0.1/ ghc-6.5/libHSNewBinary-0.1.a copy dist/build/HSNewBinary-0.1.o to /usr/local/lib/NewBinary-0.1/ ghc-6.5/HSNewBinary-0.1.o /usr/bin/ranlib /usr/local/lib/NewBinary-0.1/ghc-6.5/ libHSNewBinary-0.1.a Registering NewBinary-0.1... Reading package info from .installed-pkg-config ... done. ghc-pkg: invalid package identifier: It's not showing me the ghc-pkg that's being invoked. On Jul 26, 2006, at 12:56 AM, Jeremy Shaw wrote: At Wed, 26 Jul 2006 00:40:33 +0100, Joel Reymont wrote: Is there something that looks particularly wrong below? Can you try the install with verbosity turned up: $ sudo runhaskell Setup.lhs install -v or perhaps even $ sudo runhaskell Setup.lhs install -v5 I believe this will show the actually invocation of ghc-pkg that is being used. You can then try running ghc-pkg by hand and see if it gives you the same result. That should at least yield some useful data. Thanks. j. -- http://wagerlabs.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building NewBinary with ghc 6.5
At Wed, 26 Jul 2006 00:40:33 +0100, Joel Reymont wrote: Is there something that looks particularly wrong below? Can you try the install with verbosity turned up: $ sudo runhaskell Setup.lhs install -v or perhaps even $ sudo runhaskell Setup.lhs install -v5 I believe this will show the actually invocation of ghc-pkg that is being used. You can then try running ghc-pkg by hand and see if it gives you the same result. That should at least yield some useful data. Thanks. j. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unregisterised GHC 6.4.2 on the ARM success -- now what?
Update Summary -- The testsuite indicates that the first-pass ghc arm build is in pretty good shape -- I think it now does everything that can be expected without porting the rts, etc. I have uploaded a tarball for anyone who wants to try it: http://www.n-heptane.com/nhlab/projects/ghc-arm/ghc-6.4.2-arm-unknown-linux-bin.tar.bz2 I built it with --prefix=/opt/ghc-6.4.2, so I think it has to be installed there. I only had to make a one-bit hack to get floating point (mostly) working. I can submit a patch -- but I need a question answered below first. So, I think the next step is to start the Registerising process. Are there any wiki pages or documents about this yet? Testsuite Results - Running 'make fast' for the testsuite only returns these unexpected failures: cg034(normal) cg044(normal) fed001(normal) ffi006(normal) ffi007(normal) ffi008(normal) ffi010(normal) ffi011(normal) ffi013(normal) ffi014(threaded) I believe all the ffi/fed failures are because Adjustor.c has not been ported, so wrapper and export dynamic do not work. The cg034/cg044 failures seem to be related to non-IEEE floating point conformance at extremes: Actual stdout output differs from expected: *** ./should_run/cg034.stdout Wed Jun 20 08:11:18 2001 --- ./should_run/cg034.run.stdout Tue May 9 12:11:48 2006 *** *** 4,11 3.4028235e38 2.2250738585072014e-308 2.2250738585072014e-308 ! 1.7976931348623157e308 ! 1.7976931348623157e308 0.0 1.821736912876398e-300 0.0 --- 4,11 3.4028235e38 2.2250738585072014e-308 2.2250738585072014e-308 ! NaN ! NaN 0.0 1.821736912876398e-300 0.0 *** unexpected failure for cg034(normal) Floating Point on the Nokia 770 --- The maemo distribution (aka, the linux distro on the nokia 770), uses the in-kernel netwinder floating point emulation to emulate the arm floating point unit (FPA11). This is the 'standard' way of doing things on arm-linux. The NWPFE seems to be *mostly* IEEE compliant. As the above tests indicate -- there appear to be some errors at the extremes. I think this is probably a nwfpe bug, not a ghc bug. The other difference is the word order for doubles (and extended precision doubles -- but I do not think ghc uses those). The nokia 770 is a little-endian system -- but in, ghc/rts/StgPrimFloat.c, I had to hack this #ifdef: #ifdef WORDS_BIGENDIAN #define L 1 #define H 0 #else #define L 0 #define H 1 #endif so that it used the WORDS_BIGENDIAN defines. I think that NWFPE always uses the WORDS_BIGENDIAN ordering for doubles, so on a big-endian arm system, it probably works ok out-of-the-box -- but I do not have a way to test that. What would be a suitable way to patch this in the source? I think the only other place that WORDS_BIGENDIAN is used to manipulate a double is in the testsuite in the cg044 test. Should we define a new variable, such as DOUBLES_WORD_ORDER? Or just hack the existing #defines to something like, #ifdef WORDS_BIGENDIAN || NWFPE I think the first option is better, because then people do not have to know about architecture specific hacks. j. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unregisterised GHC 6.4.2 on the ARM success -- now what?
At Wed, 03 May 2006 22:06:05 -0700, Jeremy Shaw wrote: Hello, I believe I have successfully got an unregisterised version of ghc 6.4.2 compiled for arm/linux. Updates: --- 1) I turns out I only had a in-place build of ghc, I have now got a real build 'working'. 2) I have started putting my notes in the Wiki I added a section to the end of this page: http://hackage.haskell.org/trac/ghc/wiki/Platforms And started this page: http://hackage.haskell.org/trac/ghc/wiki/ArmLinuxGhc I will add the information about getting from an inplace .hc build to a normal build tomorrow. 3) It would appear that the floating point problem is still a problem. It did not cause any compile time errors. But ghc generates bogus answers, the one liner: main = print 1.0 prints: 5.299808824e-315 I found this thread from the last time it came up: http://www.haskell.org/pipermail/glasgow-haskell-users/2005-January/007688.html According to this page: http://wiki.tcl.tk/15408 The nokia 770 uses middle endian for floating point: http://www.catb.org/jargon/html/M/middle-endian.html I will do more research tomorrow and see what needs to be done. j. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Unregisterised GHC 6.4.2 on the ARM success -- now what?
Hello, I believe I have successfully got an unregisterised version of ghc 6.4.2 compiled for arm/linux. Details: --- I only had to do a minor bit of hacking -- this bug contains the details of what went wrong: http://hackage.haskell.org/trac/ghc/ticket/762 My target platform is the nokia 770 which runs linux and has an arm9 processor. I compiled ghc using the standard nokia 770 cross-development tools. These consist of a debian-based distro named maemo running inside scratchbox using QEMU to emulate the ARM processor. I have successfully compiled a hello, world! program and run the executable on the real nokia 770 device. What Next? -- The next step appears to be to registerise the build. I found a document that describes the C calling conventions for the ARM: http://www.arm.com/miscPDFs/8031.pdf I think the next step is to add an ARM section to: ghc/includes/MachRegs.h Is there some sensible method for doing this and testing it before I tackle the other pieces ? Thanks! j. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] factoring `if'
On Mon, 11 Oct 2004, Serge D. Mechveliani wrote: How do you think, is the program (1) equivalent to (2) in the meaning of Haskell-98 ? Not at all. If foo is non-strict and p partial, (2) may yield a result where (1) would not. You identify the possibility yourself: (2) is lazier. (1) (\ x - (if p x then foo (g x) else foo (h x)) where p ... g ... h ... foo ... ) (2) (\ x - foo ((if p x then g x else h x) where p ... g ... h ... foo ... ) ) If it is equivalent, then does it make sense for a compiler to convert (1) to (2): to separate a common `factor' of the if-branches ? The reason for this may be, for example, that the result printing of (f x) is more `lazy' in (2) than in (1): the part of foo may print immediately and (g x) or (h x) may print long after. This is a difference in behavior, it does not effect the computation meaning. I have a large program which is easily written in the style of (1), (and in many places it sets `case' instead of `if'). Annoyingly, it prints out in a not a lazy manner. It can be rewritten in the form of (2), but with effort, and it will look less plain. So, maybe, this is a business of a compiler? [EMAIL PROTECTED] Oxford University Computing Laboratory,TEL: +44 1865 283508 Wolfson Building, Parks Road, FAX: +44 1865 273839 Oxford OX1 3QD, UK. URL: http://www.comlab.ox.ac.uk/oucl/people/jeremy.gibbons.html ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc and signal processing
Hrm, I am going to do some new test tonight. I think my test environment may have been bad... Jeremy Shaw. At Mon, 23 Feb 2004 13:37:45 -0800, Mike Gunter wrote: Hmmm. With -O2 on GHC 6.2, I get 0.177s, 0.217s, and 0.348s for your three Haskell examples and 0.187s (with gcc -O2) for your C example. The output of -ddump-simpl for the looks perfect for the second Haskell example. My GHC seems to be doing a bang-up job here. What's wrong with yours? (For the third example GHC's code could be improved by additional inlining or hoisting of a constant array outside of the loop.) mike ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc and signal processing
Hrm, Okay, it seems that my problems maybe be due to using ghc 6.3. Here are the results of running test under different compiler versions (see end of message for code): Athlon 600MHz + FreeBSD + GHC 6.0.1 real0m0.414s user0m0.361s sys 0m0.016s Athlon 600MHz + FreeBSD + GHC 6.3 (built from CVS HEAD on Feb 15, 2004) real0m2.517s user0m2.289s sys 0m0.069s Pentium III 1.13GHz + Debian + GHC 6.2 real0m0.305s user0m0.196s sys 0m0.027s Pentium III 1.13GHz + Debian + GHC 6.3 (built from CVS HEAD on Feb 1, 2004) real0m1.302s user0m1.196s sys 0m0.044s So it seems like maybe GHC 6.3's performance for this particular test is around 3-5 slower? Jeremy Shaw. module Main where import Data.Array import Data.Array.IO import System.IO main = do h - openFile test.b WriteMode a - newArray_ (1,180) b - mapArray id a c - mapArray id b hPutArray h c 180 At Mon, 23 Feb 2004 13:37:45 -0800, Mike Gunter wrote: Hmmm. With -O2 on GHC 6.2, I get 0.177s, 0.217s, and 0.348s for your three Haskell examples and 0.187s (with gcc -O2) for your C example. The output of -ddump-simpl for the looks perfect for the second Haskell example. My GHC seems to be doing a bang-up job here. What's wrong with yours? (For the third example GHC's code could be improved by additional inlining or hoisting of a constant array outside of the loop.) mike ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc and signal processing
Hello,
I was thinking about using haskell to do some 'realtime' audio signal
processing, and am trying to figure out how close to the holy grail of
C code I can get when it comes to speed. Currently, it looks like I
might be looking at running 10 times slower. Is there stuff I could do
to get better performance out of haskell?
In example 1, I create an unitialized 1.8MB array of type 'IOUArray
Int Word8', and write it to a file. This takes a mere 0.056 seconds
(on an Athlon 600).
module Main where
import Data.Array
import Data.Array.IO
import System.IO
main = do h - openBinaryFile test.b WriteMode
a - newArray_ (1,180)
hPutArray h a 180
In example 2, I apply a filter to the array (in this case, the filter
is just the id function). This takes around 1.06 seconds.
main = do h - openBinaryFile test.b WriteMode
a - newArray_ (1,180)
b - mapArray id a
hPutArray h b 180
If I apply the 'filter' twice, the time increases to 2.58 seconds:
main = do h - openBinaryFile test.b WriteMode
a - newArray_ (1,180)
b - mapArray id a
c - mapArray id b
hPutArray h c 180
By comparison, the following c program runs in 0.10 seconds:
#include stdio.h
int main (int argc, char *argv[])
{
FILE *fp;
char *a;
char *b;
int i;
a = (char *)malloc (180);
b = (char *)malloc (180);
for (i = 0; i 180; i++) {
b[i] = a[i];
}
fp = fopen(test.b,w);
fwrite(b, 1, 180, fp);
fclose(fp);
free(b);
free(a);
return 0;
}
I compile using ghc from cvs as follows:
ghc -O2 -fvia-C Test.hs -o test
I also tried just -O, and no -fvia-C, and the performance was the
same. Without -O, it was about 5 times slower.
I compiled the c code with:
gcc -O2 test.c -o test.
I am using ghc from cvs head and gcc 2.95 on FreeBSD.
Are there secret options I should enable on the compiler? Or perhaps
there is a faster way than using mapArray and unboxed arrays?
Thanks!
Jeremy Shaw.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: classes and template haskell (bug?)
Hello,
No dice. Using cvs head from 12/31, I get the same behavior, (plus a
new bug). Using the same test as before (after updating the import
line):
*Main runQ [d| instance Test (a,b) |] = putStrLn . show
ghc-6.3: panic! (the `impossible' happened, GHC version 6.3):
Failed binder lookup: a{tv} {- tv a2jx -}
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
Also, a new bug has appeared (then again, it is cvs head) -- If I
start ghci, and then do this:
Prelude let n = 1
Prelude n
*** Exception: basicTypes/Var.lhs:226:32-58: Non-exhaustive patterns in record update
Prelude b
*** Exception: basicTypes/Var.lhs:226:32-58: Non-exhaustive patterns in record update
Prelude a
*** Exception: basicTypes/Var.lhs:226:32-58: Non-exhaustive patterns in record update
Prelude 3 + 4
*** Exception: basicTypes/Var.lhs:226:32-58: Non-exhaustive patterns in record update
Or similarily:
*Main runQ [d| instance Test (Int,Int) |] = putStrLn . show
Loading package haskell98 ... linking ... done.
Loading package haskell-src ... linking ... done.
[InstanceD [] (AppT (ConT Main.Test) (AppT (AppT (TupleT 2) (ConT GHC.Base.Int)) (ConT
GHC.Base.Int))) []]
*Main runQ [d| instance Test (a,b) |] = putStrLn . show
*** Exception: basicTypes/Var.lhs:226:32-58: Non-exhaustive patterns in record update
Jeremy Shaw.
At Wed, 31 Dec 2003 08:11:47 -,
Simon Peyton-Jones wrote:
In GHC 6.2, Template Haskell has various bugs. I think they are all
fixed in the HEAD, so you can either build from source or grab a
development snapshot from the GHC site.
The HEAD version of TH has a slightly different programming interface
too -- see
http://research.microsoft.com/~simonpj/tmp/notes2.ps
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Jeremy Shaw
| Sent: 31 December 2003 02:19
| To: [EMAIL PROTECTED]
| Subject: classes and template haskell (bug?)
|
| Hello,
|
| I have loaded the following from a file into ghci 6.2:
|
| module Main where
|
| import Language.Haskell.THSyntax
|
| class Test a where
| test :: a - a
|
| instance Test (a,b,c) where
| test x = x
|
| main = putStrLn Hello, World!
|
| This works for me:
|
| *Main runQ [d| instance Test (Int,Int) |] = putStrLn . show
| [InstanceD [] (AppT (ConT Main:Test) (AppT (AppT (TupleT 2) (ConT
GHC.Base:Int)) (ConT
| GHC.Base:Int))) []]
|
| But this doesn't:
|
| *Main runQ [d| instance Test (a,b) |] = putStrLn . show
| ghc-6.2: panic! (the `impossible' happened, GHC version 6.2):
| Failed binder lookup: a {- tv a20x -}
|
| Please report it as a compiler bug to
[EMAIL PROTECTED],
| or http://sourceforge.net/projects/ghc/.
|
|
| Am I doing something wrong, or is this a bug?
|
| Thanks!
| Jeremy Shaw.
| ___
| Glasgow-haskell-users mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Existential Datatypes
Hello,
I have a question regarding named fields and existential data types.
I want to extend this example from the User's guide to use named fields:
data Foo = forall a. MkFoo a (a-Bool)
| Nil
foo = MkFoo 'g' isUpper
I tried:
data Foo2 = forall a. MkFoo2 { val2 :: a
, func2 :: a - Bool
}
But the compiler said:
Can't combine named fields with locally-quantified type variables
In the declaration of data constructor MkFoo2
In the data type declaration for `Foo2'
Then I tried:
data Foo3 = MkFoo3 { val3 :: forall a. a
, func3 :: forall a. (a - Bool)
}
foo3 = MkFoo3 'g' isUpper
And the compiler said:
Inferred type is less polymorphic than expected
Quantified type variable `a' is unified with `Char'
Signature type: forall a. a
Type to generalise: Char
When checking an expression type signature
In the first argument of `MkFoo3', namely 'g'
In the definition of `foo3': MkFoo3 'g' isUpper
Am I doing something wrong, or can GHC just not do what I want yet?
From what I gathered looking through the mailing list, existential
types are still a bit hacked up?
Thanks!
Jeremy Shaw.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Having to use -static flag under Win32 with 4.08 Cygwin 1.1.6
Hi,
I've been perusing the documentation looking for what I've done wrong...
1. I got the latest versions of both Cygwin and GHC.
2. I installed Cygwin on a clean partition, F:
3. I installed GHC in /usr/share/ghc/ (on F:, of course)
4. I copied the Perl binary over to /bin, and pointed the bang in the ghc
script to the location of the binary (I found this a necessary step).
5. I got a little test program from the web:
{--}
module Main where
main = putStrLn "Hello, World!"
{--}
6. Tried to compile said program:
$ ghc main.hs
Output file not specified, defaulting to "main.exe"
gcc: F:/usr/share/ghc/lib/Main.dll_o: No such file or directory
gcc: F:/usr/share/ghc/lib/PrelMain.dll_o: No such file or directory
7. Confirmed that these files exist nowhere on the partition. Messed
around some more to no avail, came across static flag and tried that:
$ rm Main.hi main.o
$ ghc -static main.hs
Output file not specified, defaulting to "main.exe"
$ ./main.exe
Hello, World!
8. Think I'm onto something so look around for an additional installation
step I perhaps did not take, such as building libraries from source shipped
with the distro. Nope, can't find any. I can't imagine why that would even
be necessary, to support Win32 on Alphas maybe?
So alas, here I sit frustrated, waiting for comp.lang.functional, and I
figured I'd try you guys. Has anyone else had this problem? If not,
perhaps you still have an idea of what's going on? This would be much
appreciated...
Jeremy Shute
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
