Re: Haskell Platform Update?

On Friday 30 May 2014, 23:42:57, Caitlin wrote: > Hi all. > > I was just wondering if an updated release for the Haskell Platform was > planned in the neat future? The current schedule lists November of last > year as being the time for release candidates.. > > Thanks, > > ~Caitlin Yes, the pre

Re: installing random-1.0.1.1

On Tuesday 22 April 2014, 22:53:36, Sergei Meshveliani wrote: > People, > > can you, please, explain me how to make the `random' package visible for > GHC ? It is visible to GHC, but `cabal install random` installed the package into the user database: > and now ghc-pkg list > shows > > --

Re: 7.8.1 cabal install of vector package (dependent on primitive package) fails

On Wednesday 09 April 2014, 23:42:26, Carter Schonwald wrote: > i bet you have cabal --version reply with 1.16 > > 1) cabal update > 2) cabal install cabal-install > 3) rm ~/.cabal/config # old pre 1.18 config should go! > 4) cabal update # also probably add ~/.cabal/bin to path There should be

Re: Need workaround for lack of fromIntegral/Int->Word rules in 7.4.2

On Montag, 17. Dezember 2012, 07:07:21, Johan Tibell wrote: > This compiles badly in 7.4.2: > > f :: Int -> Word > f = fromIntegral > > I need a workaround. Mine produces (with optimisations, of course) Convert.f :: GHC.Types.Int -> GHC.Word.Word [GblId, Arity=1, Caf=NoCafRefs, Str=D

Re: ghci 7.4.1 no longer loading .o files?

On Monday 27 February 2012, 18:56:47, Yitzchak Gale wrote: > It's nice if there is a way for experts to load .o files > in GHCi, e.g., for the rare case where the performance > difference for some specific module is so great that you > can't work effectively interactively in some other module > tha

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2

On Wednesday 01 February 2012, 19:08:16, Evan Laforge wrote: > On Wed, Feb 1, 2012 at 8:16 AM, Simon Hengel wrote: > > Are you referring to the classical pattern, that allows you to add a > > shebang? > > > >#!/usr/bin/env runhaskell > > > >> import Distribution.Simple > >> main = de

Re: Runtime performance degradation for multi-threaded C FFI callback

On Monday 23 January 2012, 14:26:13, Simon Marlow wrote: > Another possibility is a difference in OS scheduling behaviour between > yours and Daniel Fischer's setup. In microbenchmarks like this, it's > easy for a difference in OS scheduling behaviour to make a large > difference in performance

Re: GHC HEAD build error

On Wednesday 07 December 2011, 16:45:31, Bas van Dijk wrote: > Hello, > > I'm trying to build GHC HEAD but get the following error: > > "inplace/bin/ghc-stage1" -H64m -O0 -fasm -Iincludes -Irts > -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i > -irts -irts/dist/build -ir

Re: heads up: GHC gets a new constraint solver (again)

On Wednesday 16 November 2011, 19:22:53, Dimitrios Vytiniotis wrote: > Friends, > > After a very busy period of hard work with Simon, we've re-engineered > GHCs constraint solver and I just pushed a big patch on master along > with modifications in the testsuite. > > The new constraint solver is

Re: Should GHC default to -O1 ?

On Tuesday 08 November 2011, 17:16:27, Simon Marlow wrote: > most people know about 1, but I think 2 is probably less well-known. > When in the edit-compile-debug cycle it really helps to have -O off, > because your compiles will be so much quicker due to both factors 1 & 2. Of course. So defaulti

Should GHC default to -O1 ?

On the haskell-cafe as well as the beginners mailing lists, there frequently (for some value of frequent) are posts where the author inquires about a badly performing programme, in the form of stack overflows, space leaks or slowness. Often this is because they compiled their programme without

Re: GHC infinite loop when building vector program

On Tuesday 11 October 2011, 21:11:30, Bas van Dijk wrote: > Hello, > > When benchmarking my new vector-bytestring[1] package I discovered > that building the following program causes GHC to go into, what seems > to be, an infinite loop: > > > I use vector-0.9 and ghc-7.2.1. Replicated with vec

Re: Is this a concurrency bug in base?

On Sunday 09 October 2011, 17:51:06, Jean-Marie Gaillourdet wrote: > > That sounds plausible. Do you see any workaround? Perhaps repeatedly > > evaluating typeOf? > > typeOf' seems to be a working workaround: > > typeOf' val > | t1 == t2 = t1 > | otherwise = typeOf' val > where > t

Re: Is this a concurrency bug in base?

Jean-Marie Gaillourdet: > the Eq instance of TypeRep shows the same non-deterministic behavior: Of course, equality on TypeReps is implemented by comparison of the Keys. On Sunday 09 October 2011, 16:40:13, Jean-Marie Gaillourdet wrote: > Hi Daniel, > I've been chasing the source of the non-dete

Re: Is this a concurrency bug in base?

On Sunday 09 October 2011, 15:30:20, Jean-Marie Gaillourdet wrote: > Hi Daniel, > > On 09.10.2011, at 14:45, Daniel Fischer wrote: > > On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote: > >> This seems to be a Heisenbug as it is extremely fragile, when add

Re: Is this a concurrency bug in base?

On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote: > This seems to be a Heisenbug as it is extremely fragile, when adding a > "| grep 1" to the while loop it seems to disappears. At least on my > computers. Still produces 1s here with a grep. > > All this was done on several Mac

Re: Evaluating type expressions in GHCi

On Wednesday 21 September 2011, 01:02:52, wagne...@seas.upenn.edu wrote: > Would it be possible to have no command at all? Types are > distinguished by upper-case letters, so it should be possible to tell > whether a given expression is a value-level or a type-level expression. Unless I'm misu

Re: Windows build problems

On Thursday 15 September 2011, 21:41:10, Bill Tutt wrote: > From Daniel Fischer: > > I'm trying to set up a build/test environment on Windows. > > > > Building ghc (sh validate) fails after a while due to flex and bison > > crashing. Those two come with git and e

Windows build problems

I'm trying to set up a build/test environment on Windows. Building ghc (sh validate) fails after a while due to flex and bison crashing. Those two come with git and even $ flex --version (or bison) crashes, so they seem truly hosed. Do I need flex/bison at all to build ghc? It seems they're not

Re: With every new GHC release, also released any new versions of libraries

On Thursday 25 August 2011, 10:39:29, Johan Tibell wrote: > P.S. Could someone please remind me why containers ships with GHC? Some other packages shipped with GHC depend on containers, e.g. hoopl, template-haskell, haskeline, binary. And via haskeline, ghci depends on containers too. __

Re: Can't find interface-file declaration for type constructor or class integer-gmp:GHC.Integer.Type.Integer

On Thursday 18 August 2011, 19:13:45, Johan Tibell wrote: > On Thu, Aug 18, 2011 at 7:07 PM, Simon Peyton-Jones > > wrote: > > | I shouldn't have to modify PrelNames since I kept GHC.Integer.Type, > > | no? Or does PrelNames have to contain the name of the module that > > | originally defined the

Re: integer-simple

On Friday 29 July 2011, 18:51:23, Chris Dornan wrote: > Hi All, > > > > I am still having difficulty getting a plain GHC build with > INTEGER_LIBRARY = integer-simple. (I outlined my problem here yesterday > .htm l> .) >

Re: Profile: zero total time

On Thursday 07 July 2011, 20:44:57, Matthew Farkas-Dyck wrote: > I am trying to take a profile of a program, but when I run it, the > total time (as given in the profiling report file) is zero! If you're on a Mac, it could be http://hackage.haskell.org/trac/ghc/ticket/5282 __

Re: GHC HEAD broken on OS X

On Monday 27 June 2011, 05:52:42, austin seipp wrote: > After doing a 'git pull origin master && ./sync-all pull origin > master', I get the following build failure when stage1 attempts to > compile the RTS code: > > http://paste.debian.net/121097/ > > A quick glance at the errors seem to indicat

Testsuite failures and some easy fixes

ould be adjusted. Cheers, Daniel From 92dbf9a5b4516d27fc0d389f842e21b4d3df5e5e Mon Sep 17 00:00:00 2001 From: Daniel Fischer Date: Tue, 21 Jun 2011 14:32:13 +0200 Subject: [PATCH 1/7] DatatypeContexts for tcrun006 --- tests/ghc-regress/typecheck/should_run/tcrun006.hs |5 +++-- 1 file

Re: GHC and Haskell 98

On Friday 17 June 2011, 17:11:39, Jacques Carette wrote: > I favour Plan A. +1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: URL for GHC 7.0.3

On Wednesday 15 June 2011, 16:53:37, Antoine Latter wrote: > Does this page help? > > http://www.haskell.org/ghc/download_ghc_7_0_3 > > Take care, > Antoine I would, however, recommend going for the new http://www.haskell.org/ghc/download_ghc_7_0_4 which fixes a couple of bugs in 7.0.3 __

Re: testsuite, failures galore

ple fix. Cheers, Daniel From b7170be4f9d62e695316a70435919cc2769334d1 Mon Sep 17 00:00:00 2001 From: Daniel Fischer Date: Wed, 1 Jun 2011 03:42:11 +0200 Subject: [PATCH] new test for libbfd --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index

Re: testsuite, failures galore

On Tuesday 31 May 2011 16:39:19, Donn Cave wrote: > Quoth Daniel Fischer , > ... > > > calling bfd_openr alone produces tons of undefined references, I've no > > idea what libraries I'd have to link with also :( > > Try -lbfd -liberty -lz ? > >

Re: testsuite, failures galore

On Tuesday 31 May 2011 16:04:28, Simon Marlow wrote: > On 31/05/2011 14:53, Daniel Fischer wrote: > > Well, compiling and running a simple test programme that calls > > bfd_init() works here without linking in libz, so I guess that test > > wouldn't detect the dependenc

Re: testsuite, failures galore

On Tuesday 31 May 2011 14:44:58, Simon Marlow wrote: > > What you need is libbfd.so, which is a symbolic link to the versioned > library (libbfd-2.20.0.20100122-6.so). This is normally installed by > the development version of the library (e.g. libbfd-dev on > Debian-derived distros). Couldn't f

Re: testsuite, failures galore

On Tuesday 31 May 2011 12:31:36, Simon Marlow wrote: > > The ticket has low priority, but if anybody has an idea how to check > > whether libbfd depends on libz in the configure script, I'd appreciate > > it. > > Could you install a shared version of libbfd? I have one, $ locate libbfd /home/daf

testsuite, failures galore

So my last testsuite run (validate --slow) with a new HEAD produced 651 unexpected failures :( Okay, the thing is that I forgot to add EXTRA_HC_OPTS=-optl-lz, see http://hackage.haskell.org/trac/ghc/ticket/3756 So, unless I miscounted, 611 of those were in way threaded1 due to: > Linking arrowr

Re: testsuite results

Continuing with today's HEAD's results: 7506 expected passes 235 expected failures 0 unexpected passes 9 unexpected failures More failures than Friday, with fewer tests run (no profiling). But what's the actual difference? We have our old acquaintances T3064(normal) T

Re: Linking in Dead Code

On Saturday 14 May 2011 21:06:50, Guy wrote: > On 14/05/2011 21:12, Don Stewart wrote: > > When compiled with "split objs" GHC makes it possible for the linker > > to do dead code stripping. Make sure your GHC has split-objs on. > > Thank you, I hadn't realised that the imported library could be b

Re: Linking in Dead Code

On Friday 13 May 2011 13:04:14, Guy wrote: > If only 1% of an imported module is used, GHC will link in the entire > module. With split-objs, as far as I know, GHC only links in what you use (plus the module initialiser). split-objs was disabled for some GHC/OS X combinations recently, http://ha

Re: testsuite results

On Thursday 12 May 2011 17:49:16, Simon Peyton-Jones wrote: > |hpc_markup_multi_001(normal) > |hpc_markup_multi_002(normal) > |hpc_markup_multi_003(normal) > | > | Unexpected passes: > |mc01(hpc,ghci) > |mc06(hpc,ghci) > |mc08(hpc,ghci) > |mc11(hpc) > |mc16(hpc) > |

testsuite results

Running the testsuite with today's HEAD (perf build, but without profiling to keep time bearable) resulted in: OVERALL SUMMARY for test run started at Do 12. Mai 13:34:13 CEST 2011 2765 total tests, which gave rise to 9300 test cases, of which 0 caused framewor

Re: Broken ghc-7.0.3/vector combination?

On Thursday 21 April 2011 13:08:22, Simon Marlow wrote: > On 20/04/2011 18:28, Ian Lynagh wrote: > > On Wed, Apr 20, 2011 at 05:02:50PM +0200, Daniel Fischer wrote: > >> So, is it possible that some change in ghc-7.0.3 vs. the previous > >> versions > > > >

Re: Broken ghc-7.0.3/vector combination?

On Thursday 21 April 2011 17:18:47, Chris Kuklewicz wrote: > I tried "ghc --make -fforce-recomp simpleTest.hs" with -O0 and -O1 and > -O2 on OS X with 64-bit ghc-7.0.3 > > All versions ran without printing errors. I seem to recall that GHC produces sse2 code on x86_64. If that's correct, the eff

Re: Broken ghc-7.0.3/vector combination?

On Wednesday 20 April 2011 21:55:51, Dan Doel wrote: > > It's not a statistics bug. I'm reproducing it here using just > vector-algorithms. Yep. Attached a simple testcasewhich reproduces it and uses only vector and vector-algorithms. > > Fill a vector of size N with [N..1], and (intro) sort i

Re: Broken ghc-7.0.3/vector combination?

On Wednesday 20 April 2011 20:25:34, Bryan O'Sullivan wrote: > On Wed, Apr 20, 2011 at 10:44 AM, Daniel Fischer < > > daniel.is.fisc...@googlemail.com> wrote: > > I'll prepare a bundle, I'm afraid it won't be small, though. And it > > might be archit

Re: Broken ghc-7.0.3/vector combination?

On Wednesday 20 April 2011 19:11:07, Roman Leshchinskiy wrote: > Daniel Fischer wrote: > > Further investigation of the sorting code in vector-algorithms > > revealed no bugs there, and if the runtime was forced to keep a keen > > eye on the indices, by replacing unsafeRead/

Broken ghc-7.0.3/vector combination?

Investigating the appearance of NaN in criterion's output, I found that NaNs were frequently introduced into the resample vectors when the resamples were sorted. Further investigation of the sorting code in vector-algorithms revealed no bugs there, and if the runtime was forced to keep a keen e

Re: Changing language options in ghci at runtime

On Saturday 09 April 2011 13:50:03, Simon Hengel wrote: > Hello, > does anyone know whether you can somehow change the currently active > language flags during a ghci session (say change what `:show languages' > outputs)? :set -Xlanguage I suppose some languages wouldn't work/make sense (CPP, TH)

T3738 allocation figures for 32-bit

Hit send too soon: > Apparently the allocation figures drastically vary by arch and OS, it > would probably be necessary to test on several such and be more > generous with the limits. The same holds for other tests, of course. I had unexpected failures due to allocation figures also for space_

T3738 allocation figures for 32-bit

In 7.0.3's testsuite, allT in perf/should_run says: test('T3738', [stats_num_field('peak_megabytes_allocated', 1, 1), # expected value: 1 (amd64/Linux) # expected value: 12800 (x86/OS X): if_word

Re: memory slop (was: Using the GHC heap profiler)

On Wednesday 23 March 2011 03:32:16, Tim Docker wrote: > On Mon, Mar 21, 2011 at 9:59 AM, I wrote: > > My question on the ghc heap profiler on stack overflow: > > > > http://stackoverflow.com/questions/5306717/how-should-i-interpret-the- > > output-of-the-ghc-heap-profiler > > > > remains unanswe

Re: Documentation build failure

On Sunday 06 March 2011 02:03:12, Ian Lynagh wrote: > On Sat, Mar 05, 2011 at 11:27:40AM +0100, Daniel Fischer wrote: > > > > > > $ dblatex --version > > /usr/lib/python2.6/site-packages/dbtexmf/dblatex/grubber/util.py:8: > > DeprecationWarning: the md5 module i

Documentation build failure

make-ing 7.0.2 failed with: -- everything fine up to here, users guide html okay Build users_guide.ps This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/openSUSE) entering extended mode latex failed users_guide_tmp.tex:1631: Undefined control sequence \Documents. users_guide_tmp.tex:1631: l

Re: my RULES don't fire

On Wednesday 09 February 2011 16:23:15, Sebastian Fischer wrote: > Why don't the rules fire, Because the 'match' is at the wrong type. In main, idGen appears as idGen_anJ :: ([()] -> [[()]]) -> [[()]] -> [[()]] at some point (yay for ghc -v4), so it doesn't match g's polymorphic type. > what ca

Re: my RULES don't fire

On Wednesday 09 February 2011 16:23:15, Sebastian Fischer wrote: > Why don't the rules fire, what can I change such that they do, and what > to get rid of the warning for the second rule (which I think is the one > I should use)? Didn't spot that, sorry. > > Best regards, > Sebastian > > Here is

Re: How to #include into .lhs files?

On Thursday 03 February 2011 10:33:23, Conal Elliott wrote: > Does anyone have a working example of #include'ing Haskell code into a > bird-tracks-style .lhs file with GHC? Every way I try leads to parsing > errors. Is there documentation about how it's supposed to work? > > Help much appreciated.

Re: Type system compiler flags

On Tuesday 01 February 2011 11:45:58, Julian Bean wrote: > > It indeed does, even though I doubted it at first. As far as I > > remember the type in > > > >getnArrayST n bs :: ST s (Maybe (UArray Int Word8, [Word8])) = > > > > used to be necessary to bind the type variable s. Apparently thing

Re: Type system compiler flags

On Tuesday 01 February 2011 10:20:26, Carsten Schultz wrote: > Hello everyone, > > I am trying to compile some code that I have written a long time ago > (might have been for ghc 6.3), and I have not done much Haskell in the > meantime. I have trouble compiling the code, maybe only because I do >

Re: Stack overflow weirdness

On Friday 28 January 2011 11:40:33, Simon Marlow wrote: > I think you may have had an encounter with this bug: > >    http://hackage.haskell.org/trac/ghc/ticket/4924 > That seems not unlikely. the offending Main contained a couple of near- identical loops, and that bug doesn't reliably occur (I co

Stack overflow weirdness

While tuning some code, the test programme suddenly started producing stack overflows. Reverting the code to a previous version did not revert that behaviour, code that previously produced a well-behaved binary now produced stack overflowing ones. But only with ghc-7.0.1, not with ghc-6.12.3 and

Re: Oversized libraries

On Tuesday 14 December 2010 17:50:30, Simon Marlow wrote: > This particular example seems to be fixed, at least with the current > HEAD: Also with 7.0.1. On my 32-bit system, -O increases the Types.o size from 37K to 45K which is reasonable, while with 6.12.3 it goes from 38K to 543K. __

Re: GHC.Types consturctors with #

On Monday 01 November 2010 18:40:00, Larry Evans wrote: > http://www.haskell.org/ghc/docs/6.10.2/html/libraries/ghc-prim/GHC-Types >.html > > contains: > > data Int = I# Int# > > What does I# Int# mean? I've tried a simple interpretation: > > Prelude GHC.Types> I# 5# > > :1:5: parse error (pos

Re: Cabal constraint solver

On Sunday 03 October 2010 02:10:11, Felipe Lessa wrote: > On Sat, Oct 2, 2010 at 8:29 PM, Daniel Fischer wrote: > > Yes, cabal looks at the package-index to find out the required > > dependencies, it doesn't know where you have local source files. > > Actually, this

Re: Cabal constraint solver

On Sunday 03 October 2010 00:07:24, Christian Höner zu Siederdissen wrote: > Hi, > > does the Cabal constraint solver always try to solve the complete graph? > > example: (ghc-7.0.0-rc1) > > $ cabal install parsec-3.1.0 > cabal: cannot configure syb-0.2.1. It requires base >=4.0 && <4.3 > > cd syb-

Re: ANNOUNCE: GHC 7.0.1 Release Candidate 1

On Wednesday 29 September 2010 16:51:35, Antoine Latter wrote: > Here's a boiled-down equivalent to what the issue is in uvector: > > http://hpaste.org/40213/doesnt_work_in_ghc_7 > > In GHC 6.12, this would have type-checked. In GHC 7, I need to add a > type-signature to the 'helper' function, exce

Re: ANNOUNCE: GHC 7.0.1 Release Candidate 1

On Monday 27 September 2010 13:44:07, Christian Maeder wrote: > The HTTP.cabal file is not correct! >   Build-depends: base >= 2 && < 4, network, parsec, mtl > > (an additional constraint does not help) > > Cheers Christian In that case, change the local .cabal file as an immediate measure and no

Re: ANNOUNCE: GHC 7.0.1 Release Candidate 1

On Monday 27 September 2010 12:58:08, Christian Maeder wrote: > > I've tried to install HTTP (for cabal-install) and get the following > error: > > Configuring HTTP-4000.0.9... > Setup: At least the following dependencies are missing: > base ==3.* > > What is the problem? The Build-depends of HTTP'

Re: unicode characters in operator name

On Saturday 11 September 2010 03:12:11, Greg wrote: > > If I read the Haskell Report correctly, operators are named by (symbol > {symbol | : }), where symbol is either an ascii symbol (including *) or > a unicode symbol (defined as any Unicode symbol or punctuation).  I'm > pretty sure º is a unico

Re: HEAD: Deterioration in ByteString I/O

On Thursday 09 September 2010 13:19:23, Simon Marlow wrote: > I think I've found the problem, GHC.IO.Handle.Text: > > bufReadNBEmpty :: Handle__ -> Buffer Word8 -> Ptr Word8 -> Int -> Int -> > IO Int > bufReadNBEmpty   h...@handle__{..} >                   b...@buffer{ bufRaw=raw, bufR=w, bufL=r, b

Re: HEAD: Deterioration in ByteString I/O

On Thursday 09 September 2010 01:28:04, Daniel Fischer wrote: > Maybe the following observation helps: > > ghc-6.13.20100831 reads lazy ByteStrings in chunks of 8192 bytes. > > If I understand correctly, that means (since defaultChunkSize = 32760) > - bytestring allocates a 32K b

Re: HEAD: Deterioration in ByteString I/O

On Wednesday 08 September 2010 23:55:35, Don Stewart wrote: > simonpj: > > | > ghc-6.12.3: > > | > 89,330,672 bytes allocated in the heap > > | > 15,092 bytes copied during GC > > | > 35,980 bytes maximum residency (1 sample(s)) > > | > 29,556 bytes maximum

Re: HEAD: Deterioration in ByteString I/O

On Wednesday 08 September 2010 18:10:26, Don Stewart wrote: > Can you put your benchmark code somewhere? Boiled down to the bare minimum, module Main (main) where import System.Environment (getArgs) import qualified Data.ByteString.Lazy as L main :: IO () main = do (file : _) <- getArgs

HEAD: Deterioration in ByteString I/O

Trying out HEAD (specifically, ghc-6.13.20100831-src.tar.bz2 built with 6.12.3) investigating an issue with the text package, I found that I/O of ByteStrings has become significantly slower (on my machine at least: $ uname -a Linux linux-mkk1 2.6.27.48-0.2-pae #1 SMP 2010-07-29 20:06:52 +0200 i6

Re: GADT related bug in GHC type checker

On Wednesday 14 July 2010 00:11:00, George Giorgidze wrote: > Hi, > > I have encountered a bug in GHC type checker. I have stripped down my > code to small manageable example that illustrates the bug: > > {-# LANGUAGE GADTs #-} > {-# OPTIONS -Wall #-} > > module StrangeGADT where > > data Q a where

Re: unsafeCoerce# between integral and floating point types

On Thursday 08 July 2010 18:15:44, Ian Lynagh wrote: > On Thu, Jul 08, 2010 at 04:49:00PM +0200, Daniel Fischer wrote: > > unsafeCoerce# :: Word64# -> Double# ? > > > > By the docs, that isn't supposed to work. Is it not supposed to work > > only because it'

unsafeCoerce# between integral and floating point types

The docs for unsafeCoerce# say: "The following uses of unsafeCoerce# are supposed to work (i.e. not lead to spurious compile-time or run-time crashes): # Casting any lifted type to Any # Casting Any back to the real type # Casting an unboxed type to another unboxed type of the same size (but not

Re: laziness in `length'

On Tuesday 15 June 2010 16:52:04, Denys Rtveliashvili wrote: > Hi Daniel, > > Thank you very much for the explanation of this issue. > > While I understand the parts about rewrite rules and the big thunk, it > is still not clear why it is the way it is. > > Please could you explain which Nums are n

Re: laziness in `length'

On Monday 14 June 2010 16:25:06, Serge D. Mechveliani wrote: > Dear people and GHC team, > > I have a naive question about the compiler and library of ghc-6.12.3. > Consider the program > > import List (genericLength) > main = putStr $ shows (genericLength [1 .. n]) "\n" > where >

Re: Unexpected NoImplicitPrelude behaviour in GHCi (bug?)

On Thursday 10 June 2010 14:02:10, Philip K.F. Hölzenspies wrote: > Dear GHCers, > > > > Shouldn't the expected behaviour of GHCi be that the "entry module" > determines the entire context? In other words, if module X in > > ghci X > > or in > > ghci > > > :l X > > contains the LANGUAGE-pragma NoI

Re: three dots of :browse

Am Samstag 24 April 2010 07:07:15 schrieb Kazu Yamamoto: > Hello, > > If I use :browse a module with GHC 6.12, it sometimes displays > garbage. Here is an example: > > Prelude> :browse Data.IP > data AddrRange a > = iproute-0.2.0:Data.IP.Range.AddrRange {addr :: a, >

Re: [Haskell-cafe] Different behavior of GHC 6.10.1 and Hugs (Sep 2006)

Am Samstag 03 April 2010 15:40:03 schrieb Vladimir Reshetnikov: > Hi list, > > GHC 6.10.1: > > Prelude> :t let f x y = return x == return y in f > let f x y = return x == return y in f :: (Eq (m a), Monad m) => a -> a > -> Bool > > Hugs (Sep 2006): > > Hugs> :t let f x y = return x == return y in f

Re: Issue with type families

Am Donnerstag 04 März 2010 02:39:30 schrieb Tyson Whitehead: > On March 3, 2010 18:35:26 Daniel Fischer wrote: > > Because: > > > > instance Applicative ((->) a) -- Defined in Control.Applicative > > > > so, from the instance Z (a -> b), with b == c ->

Re: Issue with type families

Am Donnerstag 04 März 2010 00:17:09 schrieb Tyson Whitehead: > The following code > > {-# LANGUAGE FlexibleInstances, TypeFamilies #-} > > import Control.Applicative > > class Z t where > type W t > z :: t -> W t > > instance Z (a -> b) where > type W (a -> b) = a -> b >

Re: integer-simple by default

Am Sonntag 21 Februar 2010 19:56:54 schrieb Isaac Dupree: > We could try to find out how large Integers get, in practice, in > existing Haskell code (this may be difficult to find out). Just as a data-point, my code rarely exceeds 128 bits (at least, beyond that performance isn't so important any

Re: Removing/deprecating -fvia-c

Am Mittwoch 17 Februar 2010 15:19:33 schrieb Simon Marlow: > I should point out that for most Haskell programs, the NCG is already as > fast (in some cases faster) than via C.  The benchmarks showing a > difference are all of the small tight loop kind - which are important to > some people, I don't

Re: Removing/deprecating -fvia-c

Am Montag 15 Februar 2010 17:37:55 schrieb Simon Marlow: > On 14/02/2010 17:58, Don Stewart wrote: > > igloo: > >> Hi all, > >> > >> We are planning to remove the -fvia-c way of compiling code > >> (unregisterised compilers will continue to compile via C only, but > >> registerised compilers will o

Re: forgetting SCC

Am Sonntag 07 Februar 2010 14:05:48 schrieb Serge D. Mechveliani: > On Sun, Feb 07, 2010 at 01:22:07PM +0100, Daniel Fischer wrote: > > Am Sonntag 07 Februar 2010 13:06:14 schrieb Serge D. Mechveliani: > > > I am sorry, > > > indeed,  ghc-6.12.1  warns of  Unreco

Re: forgetting SCC

Am Sonntag 07 Februar 2010 13:06:14 schrieb Serge D. Mechveliani: > I am sorry, > indeed,  ghc-6.12.1  warns of  Unrecognised pragma  on  {-# "foo" #-}. > I have just missed this warning. > > The next question is:  why it is a warning and not an error break? Because it might be a valid pragma for

Re: profiling,-O in 6.12.1

S -M400m -pT -RTS > > > For this key, the profiling report Main.prof looks natural and shows > > >eLoop -- 97%. > > > > > > But forghc $dmCpOpt -O -prof --make Make, > > > > > > it

Re: profiling,-O in 6.12.1

Am Mittwoch 03 Februar 2010 16:44:31 schrieb Serge D. Mechveliani: > Dear GHC team, > > It looks like ghc-6.12.1 reports erroneous time profiling -- > when the Main module of the project is made under -O. > > This is for ghc-6.12.1 made from source for Debian Linux and > i386-like. > > Main.ma

Re: Type families and type inference - a question

Am Montag 11 Januar 2010 05:08:30 schrieb Dmitry Tsygankov: > 2010/1/10 Yitzchak Gale > > > IMHO, the monomorphism restriction does not make sense at the > > GHCi prompt in any case, no matter what you have or haven't > > loaded, and no matter what your opinion of MR in general. > > Looks reasonabl

Re: Type families and type inference - a question

Am Sonntag 10 Januar 2010 17:09:33 schrieb Dmitry Tsygankov: > Dear all, > > I was playing around recently with translating the dependency injection > idea (http://martinfowler.com/articles/injection.html) into Haskell, and > got to the following code: > > > {-# LANGUAGE TypeFamilies, FlexibleConte

Re: ANNOUNCE: GHC version 6.12.1

Am Dienstag 15 Dezember 2009 10:43:10 schrieb Simon Marlow: > > Please submit a bug report. Presumably we need a configure test for -lz > somewhere. http://hackage.haskell.org/trac/ghc/ticket/3756 Yes, passing -optl-lz to all tests gave only 3 unexpected failures for threaded1. > > Cheers, >

Re: ANNOUNCE: GHC version 6.12.1

Oh great, that's not what I expected: $ cabal install cabal-install cabal: This version of the cabal program is too old to work with ghc-6.12+. You will need to install the 'cabal-install' package version 0.8 or higher. If you still have an older ghc installed (eg 6.10.4), run: $ cabal install -w

Re: ANNOUNCE: GHC version 6.12.1

Am Montag 14 Dezember 2009 14:36:14 schrieb Ian Lynagh: >== > The (Interactive) Glasgow Haskell Compiler -- version 6.12.1 >== Hooray! Built from source on $ uname -a

Re: ANNOUNCE: GHC version 6.12.1

Am Montag 14 Dezember 2009 17:47:35 schrieb Luca Ciciriello: > Installed 6.12.1 on MacOS X 10.6Now I'm unable to load in GHCi of that > modules containing "import Control.Parallel"I'm missing something? Luca cabal install parallel Control.Parallel is now in the parallel package. _

Re: inferred type doesn't type-check (using type families)

Am Dienstag 03 November 2009 19:28:55 schrieb Roland Zumkeller: > Hi, > > Compiling > > > class WithT a where > > type T a > > > > f :: T a -> a -> T a > > f = undefined > > > > g x = f x 42 > > with -XTypeFamilies -fwarn-missing-signatures gives: > > Inferred type: g :: forall a. (N

Re: Type checker's expected and inferred types (reformatted)

Am Samstag 24 Oktober 2009 21:21:51 schrieb Albert Y. C. Lai: > For the record, and to speak up as part of a possible silent majority, > > I completely understand the type error messages. Mostly, I do, too. But I can't get why IO () is *expected* and Maybe () is *inferred* for bar in fun2. Can y

Re: Type checker's expected and inferred types

Am Samstag 24 Oktober 2009 03:12:14 schrieb C Rodrigues: > I came across a type error that misled me for quite a while, because the > expected and inferred types were backwards (from my point of view). A > simplified example is below. Can someone explain how GHC's type checker > creates the error

Re: beginner question

Am Mittwoch 14 Oktober 2009 08:26:10 schrieb Luca Ciciriello: > Just a Haskell beginner question. This sort of generic question has a higher probability of receiving a quick answer on haskell-c...@haskell.org or beginn...@haskell.org, where more people are reading. > > If I load in GHCi the co

Re: Snow Leopard GHC

Am Freitag 25 September 2009 11:56:54 schrieb Barney Stratford: > As you can see, it doesn't even attempt to tell gcc where to find   > libgmp. > > This has the feeling of an RTM question, and if it is then I   > apologise. I've not seen anything about this in the M, though. > > Cheers, > Barney.

Re: Data.List permutations

Am Dienstag 04 August 2009 20:30:58 schrieb Slavomir Kaslev: > On Tue, Aug 4, 2009 at 9:23 PM, Daniel Fischer > wrote: > > Which version of ghc are you testing on? I guess, it's more recent than > mine. 6.10.3. But I think if you compiled it with 6.8.*, the library code wo

Re: Data.List permutations

Am Dienstag 04 August 2009 19:48:25 schrieb Slavomir Kaslev: > A friend mine, new to functional programming, was entertaining himself by > writing different combinatorial algorithms in Haskell. He asked me for some > help so I sent him my quick and dirty solutions for generating variations > and >

  1   2   >