From simonpj at microsoft.com  Tue Dec  1 03:17:29 2009
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Tue Dec  1 02:52:15 2009
Subject: Formal semantics for Core?
In-Reply-To: <20091130192816.GQ13955@katherina.student.utwente.nl>
References: <20091130192816.GQ13955@katherina.student.utwente.nl>
Message-ID: <59543203684B2244980D7E4057D5FBC108503DB7@DB3EX14MBXC310.europe.corp.microsoft.com>

The paper on System FC [1] has an operational semantics.  Would that do?  

Simon

[1] http://research.microsoft.com/~simonpj/papers/ext-f

| -----Original Message-----
| From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-
| bounces@haskell.org] On Behalf Of Matthijs Kooijman
| Sent: 30 November 2009 19:28
| To: GHC-users
| Subject: Formal semantics for Core?
| 
| Hi All,
| 
| I was wondering if there are any formal semantics defined for GHC's core
| language? I'm working with some core to core rewriting passes for which I'd
| like to verify the soundness, but that would require some formal definition of
| the Core semantics of sorts...
| 
| Gr.
| 
| Matthijs
From igloo at earth.li  Tue Dec  1 15:20:11 2009
From: igloo at earth.li (Ian Lynagh)
Date: Tue Dec  1 14:54:57 2009
Subject: A few small points about GHCi command documentation in section
	2.7
In-Reply-To: <2608b8a80911120640s2ca0ed50jf987fa85fff2b3f1@mail.gmail.com>
References: <2608b8a80911120640s2ca0ed50jf987fa85fff2b3f1@mail.gmail.com>
Message-ID: <20091201202011.GA17696@matrix.chaos.earth.li>

On Thu, Nov 12, 2009 at 04:40:48PM +0200, Yitzchak Gale wrote:
> Please add to the documentation for :set prompt:
> 
> If you enclose \i{prompt} in quotes, you can use Haskell
> syntax for String literals.
> 
> Actually, :set prompt is nearly useless without quotes, because
> GHCi strips off trailing spaces from commands. We should either
> add a space at the end of a prompt entered without quotes,
> or just require quotes. Or at least change the help text
> to be:
> 
> :set prompt \"<prompt>\"      set the prompt used in GHCi\n
> 
> so that people will know the right thing to do. Perhaps add
> a few more words of explanation to the docs in section 2.7
> once we decide which of these to do.
> 
> The :run command is not documented in section 2.7 - the
> only mention of it is buried within the documentation for
> the :main command. It is also not mentioned in helpText.

Thanks for the report; this is now all fixed in 6.12.


Thanks
Ian

From divisortheory at gmail.com  Thu Dec  3 12:09:08 2009
From: divisortheory at gmail.com (Zachary Turner)
Date: Thu Dec  3 11:43:47 2009
Subject: GHC on Win x64
Message-ID: <478231340912030909l374ecc09h4b5bcdb235b99dd2@mail.gmail.com>

I've been out of the loop for quite some time.  Has there been any progress
on the ability to build a native x64 version of GHC for windows?   the
supported platforms page on the web does not even list this as a Tier 1, 2,
or 3 platform and last time I tried this (quite a while ago, admittedly) I
could not get it to work.

Thanks,
Zach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091203/56dc416b/attachment.html
From greenrd at greenrd.org  Wed Dec  2 06:38:45 2009
From: greenrd at greenrd.org (Robin Green)
Date: Thu Dec  3 11:58:28 2009
Subject: GHC 6.12.1 release note suggestion
Message-ID: <m31vjda9mi.wl%greenrd@greenrd.org>

Could I suggest that the following short text be included in the GHC
6.12.1 final release notes, in some form?


-- cut here --

Updating third-party packages
-----------------------------

A number of packages will need modifying to build on GHC 6.12.1 (in
some cases, just modifying the dependencies in the .cabal file will suffice). 
If you fix someone else's open source Haskell library or application
so that it builds or works correctly on GHC 6.12.1, please help the Haskell
community by:

(a) publishing your changes as a patch or a repository, and adding a link
to them on this wiki page:
http://haskell.org/haskellwiki/Patches_and_forks_for_GHC_6.12
(You can email updates for that page to Robin Green
<greenrd@greenrd.org> if you don't want to create a wiki account.)

(b) notifying the package's current maintainer/author (this information
may be found on the package's Hackage page, if it has one), specifying
where your changes may be found.

(c) removing your changes from the wiki page if/when they get included upstream

This will help to avoid duplicating our efforts.

-- cut here --


-- 
Robin
From info at goetz-isenmann.de  Fri Dec  4 16:49:03 2009
From: info at goetz-isenmann.de (Goetz Isenmann)
Date: Fri Dec  4 16:24:07 2009
Subject: Porting to DragonFly BSD
In-Reply-To: <39376c217b35f024afc41049f419b8bb@imap.core.gen.tr>
References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com>
	<m3ws1t9j45.fsf@colina.demon.co.uk>
	<20091115124246.GA98551@horse.gocht-isenmann.de>
	<200911161732.12660.twhitehead@gmail.com>
	<39376c217b35f024afc41049f419b8bb@imap.core.gen.tr>
Message-ID: <20091204214903.GB2104@horse.gocht-isenmann.de>

On Thu, Nov 26, 2009 at 08:38:35PM +0200, Aycan iRiCAN wrote:
> Sorry, are there any advancements in dragonflybsd port of ghc?

I am still using the patches and the errno access wrapper, that were
attached to my last message.

If you need a bootstrap compiler, you can download
http://www.goetz-isenmann.de/dfly/ghc-6.10.4-dfly-5.tar.bz2, extract
this into /var/tmp, download
http://www.goetz-isenmann.de/dfly/liberrno_ptr.so, and put this into
/usr/pkg/lib.

Have not noticed any problems with this configuration so far.
And since this works for me, I currently prefer to learn haskell.

As time permits, I also like (a) to read about the upcoming ghc shared
library support, (b) to read the tls documentation, and (c) to get
something into pkgsrc, that will give use a working ghc for dragonfly
But I fear, that this will not happen during the next few weeks.
From patl at cpan.org  Sat Dec  5 08:53:44 2009
From: patl at cpan.org (Patrick LeBoutillier)
Date: Sat Dec  5 08:28:17 2009
Subject: Fwd: FFI and ghci
In-Reply-To: <b217a64f0912050550r41f625fbkd339d857bf92dde@mail.gmail.com>
References: <b217a64f0912041109u617b3506jb5e7e902d6700ed@mail.gmail.com>
	<b217a64f0912050550r41f625fbkd339d857bf92dde@mail.gmail.com>
Message-ID: <b217a64f0912050553h39009cf3p425cf1882aeb7efa@mail.gmail.com>

Hi,

I sent this question to haskell-cafe, realizing later that perhaps
this list is a better place for it.

Patrick

---------- Forwarded message ----------
From: Patrick LeBoutillier <patrick.leboutillier@gmail.com>
Date: Fri, Dec 4, 2009 at 2:09 PM
Subject: FFI and ghci
To: Haskell Cafe <haskell-cafe@haskell.org>


Hi all,

I have a small FFI-based library that I like to test like this:

?$ ghci -I../c -L../c/.libs -lmlp t.hs
?GHCi, version 6.10.1: http://www.haskell.org/ghc/ ?:? for help
?Loading package ghc-prim ... linking ... done.
?Loading package integer ... linking ... done.
?Loading package base ... linking ... done.
?Loading object (dynamic) mlp ... done
?final link ... done
?[1 of 9] Compiling MLP ? ? ? ? ? ? ?( MLP.hs, interpreted )
?[2 of 9] Compiling MLP.Error ? ? ? ?( MLP/Error.hs, interpreted )
?[3 of 9] Compiling MLP.Context ? ? ?( MLP/Context.hs, interpreted )
?[4 of 9] Compiling MLP.Runtime ? ? ?( MLP/Runtime.hs, interpreted )
?[5 of 9] Compiling MLP.Object ? ? ? ( MLP/Object.hs, interpreted )
?[6 of 9] Compiling MLP.Type ? ? ? ? ( MLP/Type.hs, interpreted )
?[7 of 9] Compiling MLP.Value ? ? ? ?( MLP/Value.hs, interpreted )
?[8 of 9] Compiling MLP.Language ? ? ( MLP/Language.hs, interpreted )
?[9 of 9] Compiling Main ? ? ? ? ? ? ( t.hs, interpreted )
?Ok, modules loaded: MLP, MLP.Object, Main, MLP.Runtime, MLP.Context,
MLP.Error, MLP.Value, MLP.Type, MLP.Language.
?*Main> main

Note: Inside libmlp.so, another shared object is loaded using dlopen().

When running this test program I get some sporadic segmentation
faults, which seem to always occur at entrypoint to the
shared object that is loaded with dlopen().


But when I compile it with ghc, i.e.

$ ghc --make -I../c -L../c/.libs -lmlp t.hs

I can't reproduce crash.

Can anyone see why this could be happening? It's quite possible that
there is really a bug in the C code,
but if someone knows about a bug or something in ghci that can cause
this behaviour I can stop looking...


Thanks a lot,

Patrick

--
=====================
Patrick LeBoutillier
Rosem?re, Qu?bec, Canada
From matthijs at stdin.nl  Sun Dec  6 15:12:21 2009
From: matthijs at stdin.nl (Matthijs Kooijman)
Date: Sun Dec  6 14:46:49 2009
Subject: Formal semantics for Core?
In-Reply-To: <59543203684B2244980D7E4057D5FBC108503DB7@DB3EX14MBXC310.europe.corp.microsoft.com>
References: <20091130192816.GQ13955@katherina.student.utwente.nl>
	<59543203684B2244980D7E4057D5FBC108503DB7@DB3EX14MBXC310.europe.corp.microsoft.com>
Message-ID: <20091206201220.GU13955@katherina.student.utwente.nl>

Hi Simon,

> The paper on System FC [1] has an operational semantics.  Would that do?  
It seems like a start. It doesn't matter much, since I don't have any time
left to actually work on this, but I wanted to verify my claim in my report
that no directly usable semantics are available :-)

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091206/3db4cf02/attachment.bin
From divisortheory at gmail.com  Sun Dec  6 23:57:58 2009
From: divisortheory at gmail.com (Zachary Turner)
Date: Sun Dec  6 23:32:26 2009
Subject: GHC Bug or User Error?
Message-ID: <478231340912062057h720d74c6h6d1f6e8f24f3962@mail.gmail.com>

GHCi, version 6.10.4: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude> let f x = x*x
Prelude> let g x y = x+y
Prelude> let q x y = (f . g) x y
Prelude> :t q
q :: (Num (a -> a), Num a) => a -> a -> a


I'm somewhat of a beginner so the error could definitely be my own, but it
seems to me like the third line should be rejected by GHCi.  As for the 4th
line, the type of q seems nonsensical to me.  I can't figure out any
possible valid meaning of 'Num (a -> a) '.

Can anyone shed some light on this?

Zach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091206/5a1032e2/attachment-0001.html
From byorgey at seas.upenn.edu  Mon Dec  7 01:10:27 2009
From: byorgey at seas.upenn.edu (Brent Yorgey)
Date: Mon Dec  7 00:44:54 2009
Subject: GHC Bug or User Error?
In-Reply-To: <478231340912062057h720d74c6h6d1f6e8f24f3962@mail.gmail.com>
References: <478231340912062057h720d74c6h6d1f6e8f24f3962@mail.gmail.com>
Message-ID: <20091207061027.GA14616@seas.upenn.edu>

On Sun, Dec 06, 2009 at 10:57:58PM -0600, Zachary Turner wrote:
> GHCi, version 6.10.4: http://www.haskell.org/ghc/  :? for help
> Loading package ghc-prim ... linking ... done.
> Loading package integer ... linking ... done.
> Loading package base ... linking ... done.
> Prelude> let f x = x*x
> Prelude> let g x y = x+y
> Prelude> let q x y = (f . g) x y
> Prelude> :t q
> q :: (Num (a -> a), Num a) => a -> a -> a
> 
> 
> I'm somewhat of a beginner so the error could definitely be my own, but it
> seems to me like the third line should be rejected by GHCi.  As for the 4th
> line, the type of q seems nonsensical to me.  I can't figure out any
> possible valid meaning of 'Num (a -> a) '.

The last line is the key: all this code is perfectly valid, *as long
as* there is an instance of Num for the type a -> a.  (If you want
more careful explanation of how this works, let me know.)  There is no
such instance in the standard libraries, but type classes are open, so
you could always add such an instance yourself (although you are right
that this probably wouldn't make much sense); hence GHC cannot reject
the code.

GHC isn't perfect, but it's fairly polished and you're not likely to
stumble across a bug so easily. =) In the future you'll probably have
more luck sending questions to beginners@haskell.org or
haskell-cafe@haskell.org; or come by the #haskell IRC channel on
freenode.net.

-Brent
From marlowsd at gmail.com  Mon Dec  7 04:11:17 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon Dec  7 03:46:13 2009
Subject: GHC on Win x64
In-Reply-To: <478231340912030909l374ecc09h4b5bcdb235b99dd2@mail.gmail.com>
References: <478231340912030909l374ecc09h4b5bcdb235b99dd2@mail.gmail.com>
Message-ID: <4B1CC6B5.9060003@gmail.com>

On 03/12/2009 17:09, Zachary Turner wrote:
> I've been out of the loop for quite some time.  Has there been any
> progress on the ability to build a native x64 version of GHC for
> windows?   the supported platforms page on the web does not even list
> this as a Tier 1, 2, or 3 platform and last time I tried this (quite a
> while ago, admittedly) I could not get it to work.

No progress at all so far.  According to the ticket there is a working 
mingw port now:

http://hackage.haskell.org/trac/ghc/ticket/1884

There is apparently support for Win64 in libffi (not sure if this patch 
has been merged or not):

http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00782.html

So the main remaining difficulty would be implementing the Win64 C call 
ABI in the native code generator.

Cheers,
	Simon
From marlowsd at gmail.com  Mon Dec  7 04:14:11 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon Dec  7 03:48:57 2009
Subject: Fwd: FFI and ghci
In-Reply-To: <b217a64f0912050553h39009cf3p425cf1882aeb7efa@mail.gmail.com>
References: <b217a64f0912041109u617b3506jb5e7e902d6700ed@mail.gmail.com>	<b217a64f0912050550r41f625fbkd339d857bf92dde@mail.gmail.com>
	<b217a64f0912050553h39009cf3p425cf1882aeb7efa@mail.gmail.com>
Message-ID: <4B1CC763.9010703@gmail.com>

On 05/12/2009 13:53, Patrick LeBoutillier wrote:
> Hi,
>
> I sent this question to haskell-cafe, realizing later that perhaps
> this list is a better place for it.
>
> Patrick
>
> ---------- Forwarded message ----------
> From: Patrick LeBoutillier<patrick.leboutillier@gmail.com>
> Date: Fri, Dec 4, 2009 at 2:09 PM
> Subject: FFI and ghci
> To: Haskell Cafe<haskell-cafe@haskell.org>
>
>
> Hi all,
>
> I have a small FFI-based library that I like to test like this:
>
>   $ ghci -I../c -L../c/.libs -lmlp t.hs
>   GHCi, version 6.10.1: http://www.haskell.org/ghc/  :? for help

Please upgrade to 6.10.4, lots of bugs were fixed.

>   Loading package ghc-prim ... linking ... done.
>   Loading package integer ... linking ... done.
>   Loading package base ... linking ... done.
>   Loading object (dynamic) mlp ... done
>   final link ... done
>   [1 of 9] Compiling MLP              ( MLP.hs, interpreted )
>   [2 of 9] Compiling MLP.Error        ( MLP/Error.hs, interpreted )
>   [3 of 9] Compiling MLP.Context      ( MLP/Context.hs, interpreted )
>   [4 of 9] Compiling MLP.Runtime      ( MLP/Runtime.hs, interpreted )
>   [5 of 9] Compiling MLP.Object       ( MLP/Object.hs, interpreted )
>   [6 of 9] Compiling MLP.Type         ( MLP/Type.hs, interpreted )
>   [7 of 9] Compiling MLP.Value        ( MLP/Value.hs, interpreted )
>   [8 of 9] Compiling MLP.Language     ( MLP/Language.hs, interpreted )
>   [9 of 9] Compiling Main             ( t.hs, interpreted )
>   Ok, modules loaded: MLP, MLP.Object, Main, MLP.Runtime, MLP.Context,
> MLP.Error, MLP.Value, MLP.Type, MLP.Language.
>   *Main>  main
>
> Note: Inside libmlp.so, another shared object is loaded using dlopen().
>
> When running this test program I get some sporadic segmentation
> faults, which seem to always occur at entrypoint to the
> shared object that is loaded with dlopen().
>
>
> But when I compile it with ghc, i.e.
>
> $ ghc --make -I../c -L../c/.libs -lmlp t.hs
>
> I can't reproduce crash.
>
> Can anyone see why this could be happening? It's quite possible that
> there is really a bug in the C code,
> but if someone knows about a bug or something in ghci that can cause
> this behaviour I can stop looking...

This one might apply if you're on x86-64:

http://hackage.haskell.org/trac/ghc/ticket/781

other than that, nothing springs to mind.  If you can narrow it down to 
a small(er) test case and submit a bug report, we'll try to take a look.

Cheers,
	Simon
From catamorphism at gmail.com  Thu Dec 10 17:00:42 2009
From: catamorphism at gmail.com (Tim Chevalier)
Date: Thu Dec 10 16:34:58 2009
Subject: Formal semantics for Core?
In-Reply-To: <20091130192816.GQ13955@katherina.student.utwente.nl>
References: <20091130192816.GQ13955@katherina.student.utwente.nl>
Message-ID: <4683d9370912101400r34460d8xa4af500c9f2f7c75@mail.gmail.com>

On 11/30/09, Matthijs Kooijman <matthijs@stdin.nl> wrote:
> Hi All,
>
>  I was wondering if there are any formal semantics defined for GHC's core
>  language? I'm working with some core to core rewriting passes for which I'd
>  like to verify the soundness, but that would require some formal definition of
>  the Core semantics of sorts...
>

It may not be exactly what you're looking for, but the extcore package
includes a typechecker and interpreter that provide an executable
static and dynamic semantics for External Core (which is similar to
the Core language that GHC uses externally, but not quite the same):
http://hackage.haskell.org/package/extcore

Cheers,
Tim


-- 
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"Do we learn from our mistakes? I surely hope not / Takes all the fun
out of making them again." -- Trout Fishing In America
From dons at galois.com  Thu Dec 10 17:01:46 2009
From: dons at galois.com (Don Stewart)
Date: Thu Dec 10 16:36:08 2009
Subject: Formal semantics for Core?
In-Reply-To: <4683d9370912101400r34460d8xa4af500c9f2f7c75@mail.gmail.com>
References: <20091130192816.GQ13955@katherina.student.utwente.nl>
	<4683d9370912101400r34460d8xa4af500c9f2f7c75@mail.gmail.com>
Message-ID: <20091210220146.GL20967@whirlpool.galois.com>

catamorphism:
> On 11/30/09, Matthijs Kooijman <matthijs@stdin.nl> wrote:
> > Hi All,
> >
> >  I was wondering if there are any formal semantics defined for GHC's core
> >  language? I'm working with some core to core rewriting passes for which I'd
> >  like to verify the soundness, but that would require some formal definition of
> >  the Core semantics of sorts...
> >
> 
> It may not be exactly what you're looking for, but the extcore package
> includes a typechecker and interpreter that provide an executable
> static and dynamic semantics for External Core (which is similar to
> the Core language that GHC uses externally, but not quite the same):
> http://hackage.haskell.org/package/extcore

Note also, Simon Winwood's prototype executable semantics for Core in the
Twelf theorem prover:

    http://www.cse.unsw.edu.au/~sjw/non-cvs/code/coreLF.tar.gz

-- Don 
From thanos at sians.org  Fri Dec 11 22:30:44 2009
From: thanos at sians.org (Thanos Tsouanas)
Date: Fri Dec 11 22:04:56 2009
Subject: Running GHC 6.10.* on OpenBSD
Message-ID: <1727208b0912111930s1a89da72t92583f19d970866d@mail.gmail.com>

Hello list.

Up to now I've only used binary versions of GHC, but since
my operating system's (OpenBSD) version of GHC is
lagging behind (currently at 6.6.1), I need to update it.
I tried using my system's ghc-6.6.1 to compile ghc-6.10.4
but it failed due to haskeline not being installed (and trying
to install it also failed).

I managed (woohoo!) to compile 6.8.3 using 6.6.1, but I
could still not use 6.8.3 to compile 6.10.4.  Even though I
have installed haskeline using cabal in 6.8.3, the making
of 6.10.4 breaks with the (weird?) message:
cabal-bin: At least the following dependencies are missing:
haskeline -any

On the same machine (it's a laptop), I also have a partition
with ubuntu linux installed (which has ghc-6.10.4 installed).
So I thought I should try cross compiling, following the
instrucions at the Porting wiki page. But this also failed at
the first steps, with the complaint:
GHC configuration does not support differing host/target
(i.e. cross-compiling).

Any suggestions / website links?

Also, I understand what --host and --target are supposed to
be, but I'm not clear on --build.  Is there a more detailed
document on building GHC, other than the Porting wiki?

Thanks.

P.S.  I don't really use the ubuntu linux partition, so if
there is an easier alternative that needs to install another
system, I can do it over ubuntu's partition.

-- 
Thanos Tsouanas
http://mpla.math.uoa.gr/~thanos/
From karel.gardas at centrum.cz  Sat Dec 12 03:22:56 2009
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Sat Dec 12 02:57:11 2009
Subject: Running GHC 6.10.* on OpenBSD
In-Reply-To: <1727208b0912111930s1a89da72t92583f19d970866d@mail.gmail.com>
References: <1727208b0912111930s1a89da72t92583f19d970866d@mail.gmail.com>
Message-ID: <4B2352E0.6040408@centrum.cz>

Thanos Tsouanas wrote:
> Hello list.
> 
> Up to now I've only used binary versions of GHC, but since
> my operating system's (OpenBSD) version of GHC is
> lagging behind (currently at 6.6.1), I need to update it.
> I tried using my system's ghc-6.6.1 to compile ghc-6.10.4
> but it failed due to haskeline not being installed (and trying
> to install it also failed).

Hello,

it's already a long time since I installed ghc-6.10.3.20090530 on my
OpenBSD/amd64, but IIRC I really used system provided compiler and IIRC
I somehow managed to first install everything what's required on system
provided 6.6.1 to compile 6.10. I'm not sure if I went step by step
6.6.1->6.8.3->6.10.3 as you try. Anyway I'm writing just to let you know
that it was somehow possible in the past and that you shall perhaps
concentrate on why it fails on your box. IMHO cross-compilation is no go
in this case since I hope I'm right assuming this is not supported in
6.10, but was fixed in 6.12 again.

In the worst case I can provide you my binary if your platform is the
same, but it's 300MB unpacked tree so it'll take some time to pack and
upload somewhere for you.

Good luck!
Karel
From kili at outback.escape.de  Sat Dec 12 04:18:28 2009
From: kili at outback.escape.de (Matthias Kilian)
Date: Sat Dec 12 03:53:15 2009
Subject: Running GHC 6.10.* on OpenBSD
In-Reply-To: <1727208b0912111930s1a89da72t92583f19d970866d@mail.gmail.com>
References: <1727208b0912111930s1a89da72t92583f19d970866d@mail.gmail.com>
Message-ID: <20091212091828.GA7769@nutty.outback.escape.de>

On Sat, Dec 12, 2009 at 05:30:44AM +0200, Thanos Tsouanas wrote:
> Up to now I've only used binary versions of GHC, but since
> my operating system's (OpenBSD) version of GHC is
> lagging behind (currently at 6.6.1), I need to update it.
> I tried using my system's ghc-6.6.1 to compile ghc-6.10.4
> but it failed due to haskeline not being installed (and trying
> to install it also failed).

I don't know wether the release tarball contains haskeline, but you
could always download the sources via darcs and use the darcs-all
script from the ghc tree to fetch all necessary libraries.

Here are some scripts I'm using to build all kinds of ghc versions
(6.10, 6.12, head, bootstrapping stuff etc.):

http://darcs.volkswurst.de/build/

You may have to edit the scripts for your purposes.

Or just wait for an update of the port ;-)

Ciao,
	Kili
From kili at outback.escape.de  Sat Dec 12 04:23:56 2009
From: kili at outback.escape.de (Matthias Kilian)
Date: Sat Dec 12 03:58:18 2009
Subject: Running GHC 6.10.* on OpenBSD
In-Reply-To: <4B2352E0.6040408@centrum.cz>
References: <1727208b0912111930s1a89da72t92583f19d970866d@mail.gmail.com>
	<4B2352E0.6040408@centrum.cz>
Message-ID: <20091212092356.GB7769@nutty.outback.escape.de>

On Sat, Dec 12, 2009 at 09:22:56AM +0100, Karel Gardas wrote:
> I somehow managed to first install everything what's required on system
> provided 6.6.1 to compile 6.10. I'm not sure if I went step by step
> 6.6.1->6.8.3->6.10.3 as you try.

No need for 6.8, you can build 6.10 straight with 6.6.

> IMHO cross-compilation is no go
> in this case since I hope I'm right assuming this is not supported in
> 6.10, but was fixed in 6.12 again.

Kind of. There are still issues with *real* porting to other platforms
(#3472, probably more), but it's possible to create hc bootstrapping
filesets and use them to bootstrap on the same platform. Even if
this sounds kind of useless, it'll help a lot updating the OpenBSD
port.

Ciao,
	Kili
From thanos at sians.org  Sat Dec 12 08:14:50 2009
From: thanos at sians.org (Thanos Tsouanas)
Date: Sat Dec 12 07:49:02 2009
Subject: Running GHC 6.10.* on OpenBSD
In-Reply-To: <1727208b0912120510h1a6d4a48p75e70f41e4ab67ec@mail.gmail.com>
References: <1727208b0912111930s1a89da72t92583f19d970866d@mail.gmail.com>
	<4B2352E0.6040408@centrum.cz>
	<1727208b0912120510h1a6d4a48p75e70f41e4ab67ec@mail.gmail.com>
Message-ID: <1727208b0912120514n5813e742u72b78b24ecf3acba@mail.gmail.com>

On Sat, Dec 12, 2009 at 10:22 AM, Karel Gardas <karel.gardas@centrum.cz> wrote:
> Thanos Tsouanas wrote:
>> Hello list.
>>
>> Up to now I've only used binary versions of GHC, but since
>> my operating system's (OpenBSD) version of GHC is
>> lagging behind (currently at 6.6.1), I need to update it.
>> I tried using my system's ghc-6.6.1 to compile ghc-6.10.4
>> but it failed due to haskeline not being installed (and trying
>> to install it also failed).
>
> Hello,
>
> it's already a long time since I installed ghc-6.10.3.20090530 on my
> OpenBSD/amd64, but IIRC I really used system provided compiler and IIRC
> I somehow managed to first install everything what's required on system
> provided 6.6.1 to compile 6.10. I'm not sure if I went step by step
> 6.6.1->6.8.3->6.10.3 as you try. Anyway I'm writing just to let you know
> that it was somehow possible in the past and that you shall perhaps
> concentrate on why it fails on your box. IMHO cross-compilation is no go
> in this case since I hope I'm right assuming this is not supported in
> 6.10, but was fixed in 6.12 again.

Perhaps you are right, I should stay on my system instead of cross
compiling. ?In any case, I could wait to crosscompile 6.12 once it's
officially out.

> In the worst case I can provide you my binary if your platform is the
> same, but it's 300MB unpacked tree so it'll take some time to pack and
> upload somewhere for you.

Thanks a lot, but unfortunately I'm on OpenBSD/i386.

Cheers.

-- 
Thanos Tsouanas
http://mpla.math.uoa.gr/~thanos/
From thanos at sians.org  Sat Dec 12 08:29:09 2009
From: thanos at sians.org (Thanos Tsouanas)
Date: Sat Dec 12 08:03:20 2009
Subject: Running GHC 6.10.* on OpenBSD
In-Reply-To: <20091212092356.GB7769@nutty.outback.escape.de>
References: <1727208b0912111930s1a89da72t92583f19d970866d@mail.gmail.com>
	<4B2352E0.6040408@centrum.cz>
	<20091212092356.GB7769@nutty.outback.escape.de>
Message-ID: <1727208b0912120529o373d5417g1abccd1cdc1d6704@mail.gmail.com>

On Sat, Dec 12, 2009 at 11:23 AM, Matthias Kilian
<kili@outback.escape.de> wrote:
> On Sat, Dec 12, 2009 at 09:22:56AM +0100, Karel Gardas wrote:
>> I somehow managed to first install everything what's required on system
>> provided 6.6.1 to compile 6.10. I'm not sure if I went step by step
>> 6.6.1->6.8.3->6.10.3 as you try.
>
> No need for 6.8, you can build 6.10 straight with 6.6.

Ok, I guess I didn't try hard enough..

>> IMHO cross-compilation is no go
>> in this case since I hope I'm right assuming this is not supported in
>> 6.10, but was fixed in 6.12 again.
>
> Kind of. There are still issues with *real* porting to other platforms
> (#3472, probably more), but it's possible to create hc bootstrapping
> filesets and use them to bootstrap on the same platform. Even if
> this sounds kind of useless, it'll help a lot updating the OpenBSD
> port.

Then it's worth a shot.  How would I create those hc bootstrapping
filesets?  Using the system's ghc-6.6.1?

P.S.  Thanks for the scripts and for mentioning darcs-all in your other
mail.  They sure are helpful :)

-- 
Thanos Tsouanas
http://mpla.math.uoa.gr/~thanos/
From kili at outback.escape.de  Sat Dec 12 09:03:17 2009
From: kili at outback.escape.de (Matthias Kilian)
Date: Sat Dec 12 08:38:16 2009
Subject: Running GHC 6.10.* on OpenBSD
In-Reply-To: <1727208b0912120529o373d5417g1abccd1cdc1d6704@mail.gmail.com>
References: <1727208b0912111930s1a89da72t92583f19d970866d@mail.gmail.com>
	<4B2352E0.6040408@centrum.cz>
	<20091212092356.GB7769@nutty.outback.escape.de>
	<1727208b0912120529o373d5417g1abccd1cdc1d6704@mail.gmail.com>
Message-ID: <20091212140317.GA25592@nutty.outback.escape.de>

On Sat, Dec 12, 2009 at 03:29:09PM +0200, Thanos Tsouanas wrote:
> > No need for 6.8, you can build 6.10 straight with 6.6.
> 
> Ok, I guess I didn't try hard enough..

Probably just

	--with-iconv-includes=/usr/local/include \
	--with-iconv-libraries=/usr/local/lib

missing to ./configure. Everything else should work fine nowadays.

> >> IMHO cross-compilation is no go
> >> in this case since I hope I'm right assuming this is not supported in
> >> 6.10, but was fixed in 6.12 again.
> >
> > Kind of. There are still issues with *real* porting to other platforms
> > (#3472, probably more), but it's possible to create hc bootstrapping
> > filesets and use them to bootstrap on the same platform. Even if
> > this sounds kind of useless, it'll help a lot updating the OpenBSD
> > port.
> 
> Then it's worth a shot.  How would I create those hc bootstrapping
> filesets?  Using the system's ghc-6.6.1?

If all you want is a working ghc-6.10, please don't waste your time
with bootstrapping filesets. Just use ghc-6.6.1 and build ghc-6.10
from it (and, if you want to, build ghc-6.12 from ghc-6.10).


BTW: if you're using my scripts, you'll probably also have to install
(apart from ghc-6.6.1) alex, darcs, gmake, haddock, happy, hscolour
and python (version  2.5). All available as precompiled packages
for OpenBSD (amd64 and i386).

Ciao,
	Kili
From thanos at sians.org  Sat Dec 12 09:36:04 2009
From: thanos at sians.org (Thanos Tsouanas)
Date: Sat Dec 12 09:10:16 2009
Subject: Running GHC 6.10.* on OpenBSD
In-Reply-To: <20091212140317.GA25592@nutty.outback.escape.de>
References: <1727208b0912111930s1a89da72t92583f19d970866d@mail.gmail.com>
	<4B2352E0.6040408@centrum.cz>
	<20091212092356.GB7769@nutty.outback.escape.de>
	<1727208b0912120529o373d5417g1abccd1cdc1d6704@mail.gmail.com>
	<20091212140317.GA25592@nutty.outback.escape.de>
Message-ID: <1727208b0912120636v5d4a12d3i43f6c55c02c69058@mail.gmail.com>

On Sat, Dec 12, 2009 at 4:03 PM, Matthias Kilian <kili@outback.escape.de> wrote:
> On Sat, Dec 12, 2009 at 03:29:09PM +0200, Thanos Tsouanas wrote:
>> > No need for 6.8, you can build 6.10 straight with 6.6.
>>
>> Ok, I guess I didn't try hard enough..
>
> Probably just
> ? ? ? ?--with-iconv-includes=/usr/local/include \
> ? ? ? ?--with-iconv-libraries=/usr/local/lib
> missing to ./configure. Everything else should work fine nowadays.

[..snip..]

> If all you want is a working ghc-6.10, please don't waste your time
> with bootstrapping filesets. Just use ghc-6.6.1 and build ghc-6.10
> from it (and, if you want to, build ghc-6.12 from ghc-6.10).

I had added these options to ./configure indeed, but still had
problems.  I think the problem was haskeline.  Anyway, I'll try
again, and post more details.

> BTW: if you're using my scripts, you'll probably also have to install
> (apart from ghc-6.6.1) alex, darcs, gmake, haddock, happy, hscolour
> and python (version ?2.5). All available as precompiled packages
> for OpenBSD (amd64 and i386).

Yeap, have them all installed already :)

-- 
Thanos Tsouanas
http://mpla.math.uoa.gr/~thanos/
From kahl at cas.mcmaster.ca  Sat Dec 12 15:39:39 2009
From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca)
Date: Sat Dec 12 15:13:56 2009
Subject: Running GHC 6.10.* on OpenBSD
In-Reply-To: <20091212091828.GA7769@nutty.outback.escape.de> (message from
	Matthias Kilian on Sat, 12 Dec 2009 10:18:28 +0100)
References: <1727208b0912111930s1a89da72t92583f19d970866d@mail.gmail.com>
	<20091212091828.GA7769@nutty.outback.escape.de>
Message-ID: <20091212203939.23157.qmail@schroeder.cas.mcmaster.ca>


On Sat, Dec 12, 2009 at 05:30:44AM +0200, Thanos Tsouanas wrote:
> Up to now I've only used binary versions of GHC, but since
> my operating system's (OpenBSD) version of GHC is
> lagging behind (currently at 6.6.1), I need to update it.
> I tried using my system's ghc-6.6.1 to compile ghc-6.10.4
> but it failed due to haskeline not being installed (and trying
> to install it also failed).

If Haskeline continues to make trouble
(it seems to at least contribute to the crashing of GHCi on PowerPC),
you could try to do a build without GHCi first ---
Haskeline is not needed for the compiler.

(I haven't tried that yet myself, since it only crashes at runtime.)


Wolfram

From dgorin at dc.uba.ar  Sat Dec 12 18:24:20 2009
From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=)
Date: Sat Dec 12 17:58:37 2009
Subject: [Haskell-cafe] Hint causes GHCi linker error under Windows
In-Reply-To: <1260525854.3934.9.camel@ios.cogsys.wiai.uni-bamberg.de>
References: <1260525854.3934.9.camel@ios.cogsys.wiai.uni-bamberg.de>
Message-ID: <07D4E191-06E7-49ED-A391-0DA7A31AF97D@dc.uba.ar>

Hi, Martin

Do you have a complete example one can use to reproduce this behavior?  
(preferably a short one! :P)

In any case, I'm resending your message to the glasgow-haskell-users  
list to see if a ghc guru recognize the error message. It is strange  
that the problem only manifests on Windows....

Daniel


On Dec 11, 2009, at 7:04 AM, Martin Hofmann wrote:

> The following hint code causes GHCi to crash under Windows:
>
>> runInterpreter $ loadModules ["SomeModule.hs"]
>
> The error message is:
>
> GHCi runtime linker: fatal error: I found a duplicate definition for
> symbol _hs_gtWord64 whilst processing object file
>   C:\Programme\Haskell Platform\2009.2.0.2\ghc-prim-0.1.0.0
> HSghc-prim-0.1.0.o
> This could be caused by:
>   * Loading two different object files which export the same symbol
>   * Specifying the same object file twice on the GHCi command line
>   * An incorrect `package.conf' entry, causing some object to be
>     loaded twice.
> GHCi cannot safely continue in this situation.  Exiting now.  Sorry.
>
> The problem does not occur under Unix or with a compiled program. IMHO
> hint tries to start a second instance of GHCi which is not
> allowed/possible under Windows. If this is the case a more telling  
> error
> message would be helpful.
>
> I used the Haskell Platform, version 2009.2.0.2 under Windows XP. My
> package.conf is:
>
> C:/Programme/Haskell Platform/2009.2.0.2\package.conf:
>    Cabal-1.6.0.3, GHood-0.0.3, GLUT-2.1.1.2, HTTP-4000.0.6,
>    HUnit-1.2.0.3, MonadCatchIO-mtl-0.2.0.0, OpenGL-2.2.1.1,
>    QuickCheck-1.2.0.0, Win32-2.2.0.0, ansi-terminal-0.5.0,
>    ansi-wl-pprint-0.5.1, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0,
>    bimap-0.2.4, bytestring-0.9.1.4, cgi-3001.1.7.1,
>    containers-0.2.0.1, cpphs-1.9, directory-1.0.0.3, (dph-base-0.3),
>    (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3),
>    (dph-prim-seq-0.3), (dph-seq-0.3), extensible-exceptions-0.1.1.0,
>    fgl-5.4.2.2, filepath-1.1.0.2, (ghc-6.10.4), ghc-mtl-1.0.1.0,
>    ghc-paths-0.1.0.6, ghc-prim-0.1.0.0, haddock-2.4.2,
>    haskeline-0.6.2.2, haskell-src-1.0.1.3, haskell-src-exts-1.3.4,
>    haskell98-1.0.1.0, hint-0.3.2.1, hpc-0.5.0.3, html-1.0.1.2,
>    integer-0.1.0.1, mtl-1.1.0.2, network-2.2.1.4, old-locale-1.0.0.1,
>    old-time-1.0.0.2, packedstring-0.1.0.1, parallel-1.1.0.1,
>    parsec-2.1.0.1, pointless-haskell-0.0.1, pretty-1.0.1.0,
>    process-1.0.1.1, random-1.0.0.1, regex-base-0.72.0.2,
>    regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.2,
>    syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4,
>    utf8-string-0.3.6, xhtml-3000.2.0.1, zlib-0.5.0.0
>
> Thanks,
>
> Martin
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From martin.hofmann at uni-bamberg.de  Mon Dec 14 03:34:17 2009
From: martin.hofmann at uni-bamberg.de (Martin Hofmann)
Date: Mon Dec 14 03:07:05 2009
Subject: [Haskell-cafe] Hint causes GHCi linker error under Windows
In-Reply-To: <07D4E191-06E7-49ED-A391-0DA7A31AF97D@dc.uba.ar>
References: <1260525854.3934.9.camel@ios.cogsys.wiai.uni-bamberg.de>
	<07D4E191-06E7-49ED-A391-0DA7A31AF97D@dc.uba.ar>
Message-ID: <1260779657.3942.5.camel@ios.cogsys.wiai.uni-bamberg.de>

Hi Daniel,

> Do you have a complete example one can use to reproduce this behavior?  
> (preferably a short one! :P)

With this code I could reproduce it in ghci.

> >> runInterpreter $ loadModules [("SomeModule.hs", Nothing)]

Currently I am not on a Windows machine, so I can't tell you if this
only occured when trying to load a specific module. I'll try it later
and if so, I'll tell you.

If you need more information, just let me know.

Martin

> > The error message is:
> >
> > GHCi runtime linker: fatal error: I found a duplicate definition for
> > symbol _hs_gtWord64 whilst processing object file
> >   C:\Programme\Haskell Platform\2009.2.0.2\ghc-prim-0.1.0.0
> > HSghc-prim-0.1.0.o
> > This could be caused by:
> >   * Loading two different object files which export the same symbol
> >   * Specifying the same object file twice on the GHCi command line
> >   * An incorrect `package.conf' entry, causing some object to be
> >     loaded twice.
> > GHCi cannot safely continue in this situation.  Exiting now.  Sorry.
> >
> > The problem does not occur under Unix or with a compiled program. IMHO
> > hint tries to start a second instance of GHCi which is not
> > allowed/possible under Windows. If this is the case a more telling  
> > error
> > message would be helpful.
> >
> > I used the Haskell Platform, version 2009.2.0.2 under Windows XP. My
> > package.conf is:
> >
> > C:/Programme/Haskell Platform/2009.2.0.2\package.conf:
> >    Cabal-1.6.0.3, GHood-0.0.3, GLUT-2.1.1.2, HTTP-4000.0.6,
> >    HUnit-1.2.0.3, MonadCatchIO-mtl-0.2.0.0, OpenGL-2.2.1.1,
> >    QuickCheck-1.2.0.0, Win32-2.2.0.0, ansi-terminal-0.5.0,
> >    ansi-wl-pprint-0.5.1, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0,
> >    bimap-0.2.4, bytestring-0.9.1.4, cgi-3001.1.7.1,
> >    containers-0.2.0.1, cpphs-1.9, directory-1.0.0.3, (dph-base-0.3),
> >    (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3),
> >    (dph-prim-seq-0.3), (dph-seq-0.3), extensible-exceptions-0.1.1.0,
> >    fgl-5.4.2.2, filepath-1.1.0.2, (ghc-6.10.4), ghc-mtl-1.0.1.0,
> >    ghc-paths-0.1.0.6, ghc-prim-0.1.0.0, haddock-2.4.2,
> >    haskeline-0.6.2.2, haskell-src-1.0.1.3, haskell-src-exts-1.3.4,
> >    haskell98-1.0.1.0, hint-0.3.2.1, hpc-0.5.0.3, html-1.0.1.2,
> >    integer-0.1.0.1, mtl-1.1.0.2, network-2.2.1.4, old-locale-1.0.0.1,
> >    old-time-1.0.0.2, packedstring-0.1.0.1, parallel-1.1.0.1,
> >    parsec-2.1.0.1, pointless-haskell-0.0.1, pretty-1.0.1.0,
> >    process-1.0.1.1, random-1.0.0.1, regex-base-0.72.0.2,
> >    regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.2,
> >    syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4,
> >    utf8-string-0.3.6, xhtml-3000.2.0.1, zlib-0.5.0.0
> >
> > Thanks,
> >
> > Martin
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
-- 
---------------------------------------------------------------
Dipl.-Wirtsch.Inf. (E.M.B.Sc.) Martin Hofmann?
Cognitive Systems Group
Faculty Information Systems and Applied Computer Science
University of Bamberg
http://www.cogsys.wiai.uni-bamberg.de/members/hofmann 
http://www.inductive-programming.org
   

From martin.hofmann at uni-bamberg.de  Mon Dec 14 06:22:20 2009
From: martin.hofmann at uni-bamberg.de (Martin Hofmann)
Date: Mon Dec 14 05:55:12 2009
Subject: [Haskell-cafe] Hint causes GHCi linker error under Windows
In-Reply-To: <07D4E191-06E7-49ED-A391-0DA7A31AF97D@dc.uba.ar>
References: <1260525854.3934.9.camel@ios.cogsys.wiai.uni-bamberg.de>
	<07D4E191-06E7-49ED-A391-0DA7A31AF97D@dc.uba.ar>
Message-ID: <1260789740.4819.17.camel@ios.cogsys.wiai.uni-bamberg.de>

The following module reproduces the error when loaded into ghci and main
is executed under Windows. It works fine when compiled.

\begin{code}

module Main where
 
import Language.Haskell.Interpreter

main = putStrLn "File to load: " >> getLine >>= erroneousLoad

erroneousLoad :: FilePath -> IO ()
erroneousLoad f = do
    ok <- runInterpreter $ loadModules [f]
    case ok of
        Right _  -> return ()
        Left e   -> fail (show e)

\end{code}
 
However in my current program I also encounter strange behaviour when
executing compiled code. I use 'haskeline' for a REP-loop. The user
input is parsed and passed to a function similar to 'erroneousLoad'.

When I type the path character by character, or when start with an empty
line by pressing return, again everything works fine. When I use the
completion function of 'haskeline' the program crashes with a
segmentation fault.

Changing the runInterpreter line to

        trace ("XXX " ++ (show f)) $ runInterpreter $ trace "YYY" $ loadModules $ trace "ZZZ" [f]

I get the following output:
        
        XXX "expl\\\\Examples.hs"
        Igor2.exe: internal error: evacuate(static): strange closure type 1094
            (GHC version 6.10.4 for i386_unknown_mingw32)
            Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
        
        This application has requested the Runtime to terminate it in an unusual way,
        Please contact the application's support team for more information.

Sometimes I get different types of the 'strange closure', e.g. 17408 or others.

I was not able to reproduce those errors on a smaller example than my
whole program. Under Linux none of those errors occurs.

Cheers,

Martin

From duncan.coutts at googlemail.com  Mon Dec 14 06:38:40 2009
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Mon Dec 14 06:12:48 2009
Subject: Initial ghc-6.12 + hackage build results
Message-ID: <1260790720.9220.24784.camel@localhost>

All,

I've tried building 1324 out of the ~1700 packages from hackage using
ghc-6.10.4 and ghc-6.12.0. This is the subset of packages that I could
build in one go.

Compared to the subset that I could build with ghc-6.10.4, I had to
chuck out 125 packages because their build dependency constraints
precluded them from building with ghc-6.12.

Of the remaining 1324 packages, 113 packages that built OK previously
now do not build.

Amongst that 113, the ones that cause most knock-on failures are:
(16,"packedstring-0.1.0.1")
(12,"MissingH-1.1.0.1")
(11,"syb-with-class-0.5.1")
(6,"uvector-0.1.0.5")
(3,"stringtable-atom-0.0.6")
(3,"bindings-common-1.3.4")
(3,"binary-strict-0.4.6")
(3,"base64-string-0.1")

packedstring fails because it needs base 4, but only says
"build-depends: base", so cabal uses its compatibility tricks and builds
it against base 3. It should specify "build-depends: base == 4.*".

I need to investigate MissingH further. It failed because a dependency
of its non-buildable test program was not found. That should not have
been a problem.

syb-with-class has type errors, I'm guessing due to changes in
template-haskell package

uvector does not compile because of the changes in GHC's Handle
implementation.

stringtable-atom now fails with a type error for reasons I don't quite
understand:
src/StringTable/AtomMap.hs:320:0:
    Occurs check: cannot construct the infinite type: a = (Int, a)
    When generalising the type(s) for `findMax'
Perhaps some change in a containers function?

bindings-common and c2hs fail because the CLDouble FFI type has been
removed.

binary-strict fails because the export of Control.Applicative.many now
clashes with a local definition.

base64-string fails because it sets -Werror in it's .cabal file (a
practise which has been banned for some time for just this reason).


Of the remaining 113:

2 failed at the configure step:
MissingH-1.1.0.1  -- this needs investigation, I smell a cabal bug
lax-0.1.0.0

52 failed at the build step (including those singled out above):
ArrayRef-0.1.3.1	-- ghc Handle changes
Boolean-0.0.0		-- name clash with Control.Applicative.<*
CCA-0.1.1		-- TH changes, missing Lift instances
ChasingBottoms-1.2.4	-- name clash with Data.Sequence.partition
ChristmasTree-0.1.2	-- TH changes (Name vs TyVarBndr)
HCodecs-0.1		-- Data.Array.Diff disappeared 
HList-0.2		-- change in GADT syntax (context)
MonadLab-0.0.2		-- Some API change, not immediately obvious
base64-string-0.1	-- described above
binary-strict-0.4.6	-- described above
bindings-common-1.3.4	-- described above
bindings-gsl-0.1.1.6	-- CLDouble
bloomfilter-1.2.6	-- declaration of a type or class operator `:*'
bytestringparser-0.3	-- -Werror
c2hs-0.16.0		-- CLDouble
cabal2arch-0.6		-- Cabal API changes
cabal2doap-0.2		-- Cabal API changes
compact-map-2008.11.9	-- GHC Handle changes
conjure-0.1		-- Data.Array.Diff disappeared
flock-0.1		-- -Werror fail
gtk2hs-cast-gtk-0.10.1.2-- type error, not immediately obvious
hask-home-2009.3.18	-- Cabal lib API changes
hgalib-0.2		-- Data.Array.Diff disappeared
hircules-0.3.92		-- ambiguity GHC.IO.liftIO vs C.M.State.liftIO
hnop-0.1		-- -Werror fail
hommage-0.0.5		-- GHC.IO changes
hxt-filter-8.3.0	-- name clash System.IO.utf8 and local name
ideas-0.5.8		-- A pattern match on a GADT requires -XGADT
ieee-0.6		-- CLDouble
ivor-0.1.9		-- 'rec' now a keyword
loch-0.2		-- -Werror fail
nano-hmac-0.2.0		-- -Werror fail
nanocurses-1.5.2	-- package specifies non-existant config.h (which used
to accidentally pick up ghc's config.h) this happens because the package
needs to run ./configure but does not say so.
network-fancy-0.1.4	-- GHC Handle changes
pkggraph-0.1		-- Cabal lib API changes
plugins-1.4.1		-- Cabal lib API changes
posix-realtime-0.0.0.1	-- type of internal IOError constructor
printf-mauke-0.3	-- CLDouble
pugs-HsSyck-0.41	-- mdo syntax removed?
random-fu-0.0.3		-- type error, not immediately obvious
rdtsc-1.1.1		-- -Werror fail
repr-0.3.1		-- same as random-fu
safe-lazy-io-0.1	-- GHC Handle changes
sendfile-0.5		-- GHC Handle changes
sessions-2008.7.18	-- needs -XTypeOperators
stringtable-atom-0.0.6	-- described above
syb-with-class-0.5.1	-- described above
type-settheory-0.1.2	-- TH lib API changes
uu-parsinglib-2.3.0	-- scoped type var changes?
uuagc-0.9.12		-- 'rec' now a keyword
uvector-0.1.0.5		-- GHC Handle changes
word24-0.1.0		-- Not in scope: `divZeroError'

The remaining 59 are knock-on failures, ie packages that depended on one
of the failed packages.

Duncan

From igloo at earth.li  Mon Dec 14 08:36:14 2009
From: igloo at earth.li (Ian Lynagh)
Date: Mon Dec 14 08:10:19 2009
Subject: ANNOUNCE: GHC version 6.12.1
Message-ID: <20091214133614.GA11826@matrix.chaos.earth.li>


   ==============================================================
    The (Interactive) Glasgow Haskell Compiler -- version 6.12.1
   ==============================================================

The GHC Team is pleased to announce a new major release of GHC. There
have been a number of significant changes since the last major release,
including:

* Considerably improved support for parallel execution. GHC 6.10 would
  execute parallel Haskell programs, but performance was often not very
  good. Simon Marlow has done lots of performance tuning in 6.12,
  removing many of the accidental (and largely invisible) gotchas that
  made parallel programs run slowly.

* As part of this parallel-performance tuning, Satnam Singh and Simon
  Marlow have developed ThreadScope, a GUI that lets you see what is
  going on inside your parallel program. It's a huge step forward from
  "It takes 4 seconds with 1 processor, and 3 seconds with 8 processors;
  now what?". ThreadScope will be released separately from GHC, but at
  more or less the same time as GHC 6.12.

* Dynamic linking is now supported on Linux, and support for other
  platforms will follow. Thanks for this most recently go to the
  Industrial Haskell Group who pushed it into a fully-working state;
  dynamic linking is the culmination of the work of several people over
  recent years. One effect of dynamic linking is that binaries shrink
  dramatically, because the run-time system and libraries are shared.
  Perhaps more importantly, it is possible to make dynamic plugins from
  Haskell code that can be used from other applications.

* The I/O libraries are now Unicode-aware, so your Haskell programs
  should now handle text files containing non-ascii characters, without
  special effort.

* The package system has been made more robust, by associating each
  installed package with a unique identifier based on its exposed ABI.
  Now, cases where the user re-installs a package without recompiling
  packages that depend on it will be detected, and the packages with
  broken dependencies will be disabled. Previously, this would lead to
  obscure compilation errors, or worse, segfaulting programs.

  This change involved a lot of internal restructuring, but it paves the
  way for future improvements to the way packages are handled. For
  instance, in the future we expect to track profiled packages
  independently of non-profiled ones, and we hope to make it possible to
  upgrade a package in an ABI-compatible way, without recompiling the
  packages that depend on it. This latter facility will be especially
  important as we move towards using more shared libraries.

* There are a variety of small language changes, including
  * Some improvements to data types: record punning, declaring
    constructors with class constraints, GADT syntax for type families
    etc.
  * You can omit the "$" in a top-level Template Haskell splice, which
    makes the TH call look more like an ordinary top-level declaration
    with a new keyword.
  * We're are deprecating mdo for recursive do-notation, in favour of
    the more expressive rec statement.
  * We've concluded that the implementation of impredicative polymorphism
    is unsustainably complicated, so we are re-trenching. It'll be
    deprecated in 6.12 (but will still work), and will be either removed
    or replaced with something simpler in 6.14.


The full release notes are here:

  http://haskell.org/ghc/docs/6.12.1/html/users_guide/release-6-12-1.html

How to get it
~~~~~~~~~~~~~

The easy way is to go to the web page, which should be self-explanatory:

        http://www.haskell.org/ghc/

We supply binary builds in the native package format for many
platforms, and the source distribution is available from the same
place.

Packages will appear as they are built - if the package for your
system isn't available yet, please try again later.


Background
~~~~~~~~~~

Haskell is a standard lazy functional programming language; the
current language version is Haskell 98, agreed in December 1998 and
revised December 2002.

GHC is a state-of-the-art programming suite for Haskell.  Included is
an optimising compiler generating good code for a variety of
platforms, together with an interactive system for convenient, quick
development.  The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces (C, whatever).  GHC is distributed under a
BSD-style open source license.

A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page (see below).


On-line GHC-related resources
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Relevant URLs on the World-Wide Web:

GHC home page              http://www.haskell.org/ghc/
GHC developers' home page  http://hackage.haskell.org/trac/ghc/
Haskell home page          http://www.haskell.org/


Supported Platforms
~~~~~~~~~~~~~~~~~~~

The list of platforms we support, and the people responsible for them,
is here:

   http://hackage.haskell.org/trac/ghc/wiki/Contributors

Ports to other platforms are possible with varying degrees of
difficulty.  The Building Guide describes how to go about porting to a
new platform:

    http://hackage.haskell.org/trac/ghc/wiki/Building


Developers
~~~~~~~~~~

We welcome new contributors.  Instructions on accessing our source
code repository, and getting started with hacking on GHC, are
available from the GHC's developer's site run by Trac:

  http://hackage.haskell.org/trac/ghc/


Mailing lists
~~~~~~~~~~~~~

We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at

    http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
    http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see

    http://www.haskell.org/mailman/listinfo/

Some GHC developers hang out on #haskell on IRC, too:

    http://www.haskell.org/haskellwiki/IRC_channel

Please report bugs using our bug tracking system.  Instructions on
reporting bugs can be found here:

    http://www.haskell.org/ghc/reportabug

From luca_ciciriello at hotmail.com  Mon Dec 14 09:12:45 2009
From: luca_ciciriello at hotmail.com (Luca Ciciriello)
Date: Mon Dec 14 08:46:52 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <20091214133614.GA11826@matrix.chaos.earth.li>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
Message-ID: <SNT128-W2929BB6876A43985DBAD5D9A890@phx.gbl>


I've the 6.10.4 version installed on my MacOS X 10.6 OS. Have I to uninstall this version of GHC before installing the Mac .pkg for the 6.12.1?

 

Luca.
 
> Date: Mon, 14 Dec 2009 13:36:14 +0000
> From: igloo@earth.li
> To: glasgow-haskell-users@haskell.org; haskell@haskell.org
> CC: 
> Subject: ANNOUNCE: GHC version 6.12.1
> 
> 
> ==============================================================
> The (Interactive) Glasgow Haskell Compiler -- version 6.12.1
> ==============================================================
> 
> The GHC Team is pleased to announce a new major release of GHC. There
> have been a number of significant changes since the last major release,
> including:
> 
> * Considerably improved support for parallel execution. GHC 6.10 would
> execute parallel Haskell programs, but performance was often not very
> good. Simon Marlow has done lots of performance tuning in 6.12,
> removing many of the accidental (and largely invisible) gotchas that
> made parallel programs run slowly.
> 
> * As part of this parallel-performance tuning, Satnam Singh and Simon
> Marlow have developed ThreadScope, a GUI that lets you see what is
> going on inside your parallel program. It's a huge step forward from
> "It takes 4 seconds with 1 processor, and 3 seconds with 8 processors;
> now what?". ThreadScope will be released separately from GHC, but at
> more or less the same time as GHC 6.12.
> 
> * Dynamic linking is now supported on Linux, and support for other
> platforms will follow. Thanks for this most recently go to the
> Industrial Haskell Group who pushed it into a fully-working state;
> dynamic linking is the culmination of the work of several people over
> recent years. One effect of dynamic linking is that binaries shrink
> dramatically, because the run-time system and libraries are shared.
> Perhaps more importantly, it is possible to make dynamic plugins from
> Haskell code that can be used from other applications.
> 
> * The I/O libraries are now Unicode-aware, so your Haskell programs
> should now handle text files containing non-ascii characters, without
> special effort.
> 
> * The package system has been made more robust, by associating each
> installed package with a unique identifier based on its exposed ABI.
> Now, cases where the user re-installs a package without recompiling
> packages that depend on it will be detected, and the packages with
> broken dependencies will be disabled. Previously, this would lead to
> obscure compilation errors, or worse, segfaulting programs.
> 
> This change involved a lot of internal restructuring, but it paves the
> way for future improvements to the way packages are handled. For
> instance, in the future we expect to track profiled packages
> independently of non-profiled ones, and we hope to make it possible to
> upgrade a package in an ABI-compatible way, without recompiling the
> packages that depend on it. This latter facility will be especially
> important as we move towards using more shared libraries.
> 
> * There are a variety of small language changes, including
> * Some improvements to data types: record punning, declaring
> constructors with class constraints, GADT syntax for type families
> etc.
> * You can omit the "$" in a top-level Template Haskell splice, which
> makes the TH call look more like an ordinary top-level declaration
> with a new keyword.
> * We're are deprecating mdo for recursive do-notation, in favour of
> the more expressive rec statement.
> * We've concluded that the implementation of impredicative polymorphism
> is unsustainably complicated, so we are re-trenching. It'll be
> deprecated in 6.12 (but will still work), and will be either removed
> or replaced with something simpler in 6.14.
> 
> 
> The full release notes are here:
> 
> http://haskell.org/ghc/docs/6.12.1/html/users_guide/release-6-12-1.html
> 
> How to get it
> ~~~~~~~~~~~~~
> 
> The easy way is to go to the web page, which should be self-explanatory:
> 
> http://www.haskell.org/ghc/
> 
> We supply binary builds in the native package format for many
> platforms, and the source distribution is available from the same
> place.
> 
> Packages will appear as they are built - if the package for your
> system isn't available yet, please try again later.
> 
> 
> Background
> ~~~~~~~~~~
> 
> Haskell is a standard lazy functional programming language; the
> current language version is Haskell 98, agreed in December 1998 and
> revised December 2002.
> 
> GHC is a state-of-the-art programming suite for Haskell. Included is
> an optimising compiler generating good code for a variety of
> platforms, together with an interactive system for convenient, quick
> development. The distribution includes space and time profiling
> facilities, a large collection of libraries, and support for various
> language extensions, including concurrency, exceptions, and foreign
> language interfaces (C, whatever). GHC is distributed under a
> BSD-style open source license.
> 
> A wide variety of Haskell related resources (tutorials, libraries,
> specifications, documentation, compilers, interpreters, references,
> contact information, links to research groups) are available from the
> Haskell home page (see below).
> 
> 
> On-line GHC-related resources
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Relevant URLs on the World-Wide Web:
> 
> GHC home page http://www.haskell.org/ghc/
> GHC developers' home page http://hackage.haskell.org/trac/ghc/
> Haskell home page http://www.haskell.org/
> 
> 
> Supported Platforms
> ~~~~~~~~~~~~~~~~~~~
> 
> The list of platforms we support, and the people responsible for them,
> is here:
> 
> http://hackage.haskell.org/trac/ghc/wiki/Contributors
> 
> Ports to other platforms are possible with varying degrees of
> difficulty. The Building Guide describes how to go about porting to a
> new platform:
> 
> http://hackage.haskell.org/trac/ghc/wiki/Building
> 
> 
> Developers
> ~~~~~~~~~~
> 
> We welcome new contributors. Instructions on accessing our source
> code repository, and getting started with hacking on GHC, are
> available from the GHC's developer's site run by Trac:
> 
> http://hackage.haskell.org/trac/ghc/
> 
> 
> Mailing lists
> ~~~~~~~~~~~~~
> 
> We run mailing lists for GHC users and bug reports; to subscribe, use
> the web interfaces at
> 
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
> 
> There are several other haskell and ghc-related mailing lists on
> www.haskell.org; for the full list, see
> 
> http://www.haskell.org/mailman/listinfo/
> 
> Some GHC developers hang out on #haskell on IRC, too:
> 
> http://www.haskell.org/haskellwiki/IRC_channel
> 
> Please report bugs using our bug tracking system. Instructions on
> reporting bugs can be found here:
> 
> http://www.haskell.org/ghc/reportabug
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
 		 	   		  
_________________________________________________________________
Got more than one Hotmail account? Save time by linking them together
 http://clk.atdmt.com/UKM/go/186394591/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091214/9192cb84/attachment-0001.html
From luca_ciciriello at hotmail.com  Mon Dec 14 09:16:19 2009
From: luca_ciciriello at hotmail.com (Luca Ciciriello)
Date: Mon Dec 14 08:50:25 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <SNT128-W2929BB6876A43985DBAD5D9A890@phx.gbl>
References: <20091214133614.GA11826@matrix.chaos.earth.li>,
	<SNT128-W2929BB6876A43985DBAD5D9A890@phx.gbl>
Message-ID: <SNT128-W391B6ADCC8FE1A4585D67C9A890@phx.gbl>


I've the 6.10.4 version installed on my MacOS X 10.6 OS. Have I to uninstall this version of GHC before installing the Mac .pkg for the 6.12.1?
 
Luca.
 
> Date: Mon, 14 Dec 2009 13:36:14 +0000
> From: igloo@earth.li
> To: glasgow-haskell-users@haskell.org; haskell@haskell.org
> CC: 
> Subject: ANNOUNCE: GHC version 6.12.1
> 
> 
> ==============================================================
> The (Interactive) Glasgow Haskell Compiler -- version 6.12.1
> ==============================================================
> 
> The GHC Team is pleased to announce a new major release of GHC. There
> have been a number of significant changes since the last major release,
> including:
> 
> * Considerably improved support for parallel execution. GHC 6.10 would
> execute parallel Haskell programs, but performance was often not very
> good. Simon Marlow has done lots of performance tuning in 6.12,
> removing many of the accidental (and largely invisible) gotchas that
> made parallel programs run slowly.
> 
> * As part of this parallel-performance tuning, Satnam Singh and Simon
> Marlow have developed ThreadScope, a GUI that lets you see what is
> going on inside your parallel program. It's a huge step forward from
> "It takes 4 seconds with 1 processor, and 3 seconds with 8 processors;
> now what?". ThreadScope will be released separately from GHC, but at
> more or less the same time as GHC 6.12.
> 
> * Dynamic linking is now supported on Linux, and support for other
> platforms will follow. Thanks for this most recently go to the
> Industrial Haskell Group who pushed it into a fully-working state;
> dynamic linking is the culmination of the work of several people over
> recent years. One effect of dynamic linking is that binaries shrink
> dramatically, because the run-time system and libraries are shared.
> Perhaps more importantly, it is possible to make dynamic plugins from
> Haskell code that can be used from other applications.
> 
> * The I/O libraries are now Unicode-aware, so your Haskell programs
> should now handle text files containing non-ascii characters, without
> special effort.
> 
> * The package system has been made more robust, by associating each
> installed package with a unique identifier based on its exposed ABI.
> Now, cases where the user re-installs a package without recompiling
> packages that depend on it will be detected, and the packages with
> broken dependencies will be disabled. Previously, this would lead to
> obscure compilation errors, or worse, segfaulting programs.
> 
> This change involved a lot of internal restructuring, but it paves the
> way for future improvements to the way packages are handled. For
> instance, in the future we expect to track profiled packages
> independently of non-profiled ones, and we hope to make it possible to
> upgrade a package in an ABI-compatible way, without recompiling the
> packages that depend on it. This latter facility will be especially
> important as we move towards using more shared libraries.
> 
> * There are a variety of small language changes, including
> * Some improvements to data types: record punning, declaring
> constructors with class constraints, GADT syntax for type families
> etc.
> * You can omit the "$" in a top-level Template Haskell splice, which
> makes the TH call look more like an ordinary top-level declaration
> with a new keyword.
> * We're are deprecating mdo for recursive do-notation, in favour of
> the more expressive rec statement.
> * We've concluded that the implementation of impredicative polymorphism
> is unsustainably complicated, so we are re-trenching. It'll be
> deprecated in 6.12 (but will still work), and will be either removed
> or replaced with something simpler in 6.14.
> 
> 
> The full release notes are here:
> 
> http://haskell.org/ghc/docs/6.12.1/html/users_guide/release-6-12-1.html
> 
> How to get it
> ~~~~~~~~~~~~~
> 
> The easy way is to go to the web page, which should be self-explanatory:
> 
> http://www.haskell.org/ghc/
> 
> We supply binary builds in the native package format for many
> platforms, and the source distribution is available from the same
> place.
> 
> Packages will appear as they are built - if the package for your
> system isn't available yet, please try again later.
> 
> 
> Background
> ~~~~~~~~~~
> 
> Haskell is a standard lazy functional programming language; the
> current language version is Haskell 98, agreed in December 1998 and
> revised December 2002.
> 
> GHC is a state-of-the-art programming suite for Haskell. Included is
> an optimising compiler generating good code for a variety of
> platforms, together with an interactive system for convenient, quick
> development. The distribution includes space and time profiling
> facilities, a large collection of libraries, and support for various
> language extensions, including concurrency, exceptions, and foreign
> language interfaces (C, whatever). GHC is distributed under a
> BSD-style open source license.
> 
> A wide variety of Haskell related resources (tutorials, libraries,
> specifications, documentation, compilers, interpreters, references,
> contact information, links to research groups) are available from the
> Haskell home page (see below).
> 
> 
> On-line GHC-related resources
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Relevant URLs on the World-Wide Web:
> 
> GHC home page http://www.haskell.org/ghc/
> GHC developers' home page http://hackage.haskell.org/trac/ghc/
> Haskell home page http://www.haskell.org/
> 
> 
> Supported Platforms
> ~~~~~~~~~~~~~~~~~~~
> 
> The list of platforms we support, and the people responsible for them,
> is here:
> 
> http://hackage.haskell.org/trac/ghc/wiki/Contributors
> 
> Ports to other platforms are possible with varying degrees of
> difficulty. The Building Guide describes how to go about porting to a
> new platform:
> 
> http://hackage.haskell.org/trac/ghc/wiki/Building
> 
> 
> Developers
> ~~~~~~~~~~
> 
> We welcome new contributors. Instructions on accessing our source
> code repository, and getting started with hacking on GHC, are
> available from the GHC's developer's site run by Trac:
> 
> http://hackage.haskell.org/trac/ghc/
> 
> 
> Mailing lists
> ~~~~~~~~~~~~~
> 
> We run mailing lists for GHC users and bug reports; to subscribe, use
> the web interfaces at
> 
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
> 
> There are several other haskell and ghc-related mailing lists on
> www.haskell.org; for the full list, see
> 
> http://www.haskell.org/mailman/listinfo/
> 
> Some GHC developers hang out on #haskell on IRC, too:
> 
> http://www.haskell.org/haskellwiki/IRC_channel
> 
> Please report bugs using our bug tracking system. Instructions on
> reporting bugs can be found here:
> 
> http://www.haskell.org/ghc/reportabug
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



New! Receive and respond to mail from other email accounts from within Hotmail Find out how. 		 	   		  
_________________________________________________________________
Have more than one Hotmail account? Link them together to easily access both
 http://clk.atdmt.com/UKM/go/186394591/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091214/55a2b3dc/attachment.html
From v.dijk.bas at gmail.com  Mon Dec 14 09:24:05 2009
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Mon Dec 14 08:58:12 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <20091214133614.GA11826@matrix.chaos.earth.li>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
Message-ID: <f73f66150912140624s634a5742kde32483ab12cadbe@mail.gmail.com>

There's a broken link to the Haskell Platform in:

http://haskell.org/ghc/docs/6.12.1/html/users_guide/release-6-12-1.html#id2890234

Bas
From marco-oweber at gmx.de  Mon Dec 14 09:24:48 2009
From: marco-oweber at gmx.de (Marc Weber)
Date: Mon Dec 14 08:59:17 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <SNT128-W2929BB6876A43985DBAD5D9A890@phx.gbl>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
	<SNT128-W2929BB6876A43985DBAD5D9A890@phx.gbl>
Message-ID: <1260800682-sup-1666@nixos>

Excerpts from Luca Ciciriello's message of Mon Dec 14 15:12:45 +0100 2009:
> I've the 6.10.4 version installed on my MacOS X 10.6 OS. Have I to uninstall
> this version of GHC before installing the Mac .pkg for the 6.12.1?

Hi Luca,

You should be able to get some hints by looking at where ghc is installed.

By default ghc puts its libraries into directory which contains the ghc
release name. So libs can be installed at the same time.
There are also ghc(i)-pkg-$GHC_VERSION executables.
So it should be possible. However I don't know about Mac details.

But maybe someone else can give you a more accurate answer.

Sincerly
Marc Weber
From greenrd at greenrd.org  Sun Dec 13 13:06:26 2009
From: greenrd at greenrd.org (Robin Green)
Date: Mon Dec 14 09:45:46 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <20091214133614.GA11826@matrix.chaos.earth.li>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
Message-ID: <m3y6l6n3z1.wl%greenrd@greenrd.org>

I have been using GHC 6.12.1 from
http://www.haskell.org/ghc/dist/6.12.1-pre/ (which doesn't exist any
more). Do I need to upgrade, or is it exactly the same? Do I need to
recompile packages?
-- 
Robin
From malcolm.wallace at cs.york.ac.uk  Mon Dec 14 10:11:46 2009
From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace)
Date: Mon Dec 14 09:45:52 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <SNT128-W391B6ADCC8FE1A4585D67C9A890@phx.gbl>
References: <20091214133614.GA11826@matrix.chaos.earth.li>,
	<SNT128-W2929BB6876A43985DBAD5D9A890@phx.gbl>
	<SNT128-W391B6ADCC8FE1A4585D67C9A890@phx.gbl>
Message-ID: <32E604F9-D791-484E-9400-232E91668B19@cs.york.ac.uk>

> I've the 6.10.4 version installed on my MacOS X 10.6 OS. Have I to  
> uninstall this version of GHC before installing the Mac .pkg for the  
> 6.12.1?

Most installer packages (_except_ for MacOS) allow you to have  
multiple previous versions of ghc - they are simply left in place (but  
must now be accessed as e.g. ghc-6.10.4 rather than plan ghc, which  
now points to the new version).

However, there is an unfortunate feature/bug of the MacOS installer  
packages that they forceably delete any previous versions of ghc that  
you had on your machine.  This is undesirable for many reasons, but as  
far as I know, it has not yet been fixed.

Regards,
     Malcolm

From luca_ciciriello at hotmail.com  Mon Dec 14 11:47:35 2009
From: luca_ciciriello at hotmail.com (Luca Ciciriello)
Date: Mon Dec 14 11:21:42 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <1260800682-sup-1666@nixos>
References: <20091214133614.GA11826@matrix.chaos.earth.li>,
	<SNT128-W2929BB6876A43985DBAD5D9A890@phx.gbl>,
	<1260800682-sup-1666@nixos>
Message-ID: <SNT128-W3217F8C02C7EAA2723E4339A890@phx.gbl>


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

> From: marco-oweber@gmx.de
> To: glasgow-haskell-users@haskell.org
> Date: Mon, 14 Dec 2009 15:24:48 +0100
> Subject: RE: ANNOUNCE: GHC version 6.12.1
> 
> Excerpts from Luca Ciciriello's message of Mon Dec 14 15:12:45 +0100 2009:
> > I've the 6.10.4 version installed on my MacOS X 10.6 OS. Have I to uninstall
> > this version of GHC before installing the Mac .pkg for the 6.12.1?
> 
> Hi Luca,
> 
> You should be able to get some hints by looking at where ghc is installed.
> 
> By default ghc puts its libraries into directory which contains the ghc
> release name. So libs can be installed at the same time.
> There are also ghc(i)-pkg-$GHC_VERSION executables.
> So it should be possible. However I don't know about Mac details.
> 
> But maybe someone else can give you a more accurate answer.
> 
> Sincerly
> Marc Weber
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
 		 	   		  
_________________________________________________________________
Use Hotmail to send and receive mail from your different email accounts
http://clk.atdmt.com/UKM/go/186394592/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091214/7282c105/attachment-0001.html
From daniel.is.fischer at web.de  Mon Dec 14 12:15:46 2009
From: daniel.is.fischer at web.de (Daniel Fischer)
Date: Mon Dec 14 11:51:20 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <SNT128-W3217F8C02C7EAA2723E4339A890@phx.gbl>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
	<1260800682-sup-1666@nixos>
	<SNT128-W3217F8C02C7EAA2723E4339A890@phx.gbl>
Message-ID: <200912141815.46920.daniel.is.fischer@web.de>

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.
From berthold at Mathematik.Uni-Marburg.de  Mon Dec 14 14:04:02 2009
From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold)
Date: Mon Dec 14 13:38:15 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <20091214162147.68B2E3246EB@www.haskell.org>
References: <20091214162147.68B2E3246EB@www.haskell.org>
Message-ID: <4B268C22.5070006@mathematik.uni-marburg.de>

Luca,

to use Control.Parallel, you need to download and install two packages, 
deepseq and parallel, from hackage.haskell.org.
Most likely this will work with cabal, or you just download the two 
tarballs .

The reason is, when packaging "parallel", this package has been removed 
from the GHC core libraries. BTW I am unsure whether this is at all 
clever, since it needs specific GHC support (at least for now - am I 
right here?)

In addition, be informed that Control.Parallel.Strategies has been 
heavily restructured just last month (splitting it into deepseq and 
parallel is one of the changes, but not the most fundamental).
If you want to try examples from GpH publications, you will certainly 
have some problems. parallel-1.x versions containing the original 
definitions are on hackage as well and should work for experiments.

Cheers
Jost Berthold

PS: Loading Control.Parallel into ghci is a handy debugging procedure 
for the sequential parts of your program without any hassle, but if you 
do not compile and link your program, it will not use any parallelism 
(and run slow anyway).

> From: Luca Ciciriello <luca_ciciriello@hotmail.com>
> Subject: RE: ANNOUNCE: GHC version 6.12.1
> To: <marco-oweber@gmx.de>, <glasgow-haskell-users@haskell.org>
> Message-ID: <SNT128-W3217F8C02C7EAA2723E4339A890@phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> 
> 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
> 
>> From: marco-oweber@gmx.de
>> To: glasgow-haskell-users@haskell.org
>> Date: Mon, 14 Dec 2009 15:24:48 +0100
>> Subject: RE: ANNOUNCE: GHC version 6.12.1
>>
>> Excerpts from Luca Ciciriello's message of Mon Dec 14 15:12:45 +0100 
>> 2009:
>> > I've the 6.10.4 version installed on my MacOS X 10.6 OS. Have I to 
>> uninstall
>> > this version of GHC before installing the Mac .pkg for the 6.12.1?
>>
>> Hi Luca,
>>
>> You should be able to get some hints by looking at where ghc is 
>> installed.
>>
>> By default ghc puts its libraries into directory which contains the ghc
>> release name. So libs can be installed at the same time.
>> There are also ghc(i)-pkg-$GHC_VERSION executables.
>> So it should be possible. However I don't know about Mac details.
>>
>> But maybe someone else can give you a more accurate answer.
>>
>> Sincerly
>> Marc Weber

From allbery at ece.cmu.edu  Mon Dec 14 14:25:21 2009
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Mon Dec 14 13:59:38 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <4B268C22.5070006@mathematik.uni-marburg.de>
References: <20091214162147.68B2E3246EB@www.haskell.org>
	<4B268C22.5070006@mathematik.uni-marburg.de>
Message-ID: <78CF5903-8F3D-4A78-96F3-3D565C96B266@ece.cmu.edu>

On Dec 14, 2009, at 14:04 , Jost Berthold wrote:
> The reason is, when packaging "parallel", this package has been  
> removed from the GHC core libraries. BTW I am unsure whether this is  
> at all clever, since it needs specific GHC support (at least for now  
> - am I right here?)


Only to the extent that the (standardized) primitives are only in GHC;  
the packages were released and tested with 6.10.x.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091214/80b4b8bf/PGP.bin
From daniel.is.fischer at web.de  Mon Dec 14 16:16:14 2009
From: daniel.is.fischer at web.de (Daniel Fischer)
Date: Mon Dec 14 15:51:57 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <20091214133614.GA11826@matrix.chaos.earth.li>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
Message-ID: <200912142216.14919.daniel.is.fischer@web.de>

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
Linux linux-mkk1 2.6.27.39-0.2-pae #1 SMP 2009-11-23 12:57:38 +0100 i686 i686 i386 
GNU/Linux
(openSuse 11.1)

Running the testsuit gave

OVERALL SUMMARY for test run started at Mo 14. Dez 18:06:00 CET 2009
    2352 total tests, which gave rise to                            
   13034 test cases, of which                                       
       0 caused framework failures                                  
    2760 were skipped                                               

    9471 expected passes
     328 expected failures
       0 unexpected passes
     475 unexpected failures

Is that good or bad?
Almost all unexpected failures are with threaded1, the vast majority of them due to

/usr/src/packages/BUILD/binutils-2.19/build-dir/bfd/../../bfd/compress.c:96:0:
     undefined reference to `inflateInit_'                                    

/usr/src/packages/BUILD/binutils-2.19/build-dir/bfd/../../bfd/compress.c:103:0:
     undefined reference to `inflate'                                          

/usr/src/packages/BUILD/binutils-2.19/build-dir/bfd/../../bfd/compress.c:106:0:
     undefined reference to `inflateReset'                                     

/usr/src/packages/BUILD/binutils-2.19/build-dir/bfd/../../bfd/compress.c:108:0:
     undefined reference to `inflateEnd'                                       
collect2: ld returned 1 exit status                                            

*** unexpected failure for fileStatus(threaded1)

Missing -lz option for the linker?

Unexpected failures:
   10queens(threaded1)
   1185(threaded1)    
   1548(threaded1)    
   1679(threaded1)    
   1744(threaded1)    
   1852(threaded1)    
   1861(threaded1)    
   1980(threaded1)    
   2047(threaded1)    
   2080(threaded1)    
   2122(threaded1)    
   2469(threaded1)    
   2594(threaded1)    
   2783(threaded1)    
   2838(threaded1)    
   2910(threaded1)    
   2917a(threaded1)   
   3207(threaded1)    
   3236(threaded1)    
   3279(threaded1)    
   3424(threaded1)    
   3429(threaded1)    
   3561(threaded1)    
   3677(threaded1)    
   CPUTime001(threaded1)
   IOError001(threaded1)
   IOError002(threaded1)
   OldException001(threaded1)
   T1624(threaded1)          
   T1735(threaded1)          
   T246(threaded1)           
   T2529(threaded1)          
   T3087(threaded1)          
   T3126(threaded1)          
   T3382(threaded1)          
   ThreadDelay001(threaded1) 
   addr001(threaded1)        
   andre_monad(threaded1)    
   andy_cherry(threaded1)    
   annrun01(threaded1,dyn)   
   arith001(threaded1)       
   arith002(threaded1)       
   arith003(threaded1)       
   arith004(threaded1)       
   arith005(threaded1)       
   arith006(threaded1)       
   arith007(threaded1)       
   arith008(threaded1)       
   arith009(threaded1)       
   arith010(threaded1)       
   arith011(threaded1)       
   arith012(threaded1)       
   arith013(threaded1)       
   arith014(threaded1)       
   arith015(threaded1)       
   arith016(threaded1)       
   arith017(threaded1)       
   arith018(threaded1)       
   arith019(threaded1)       
   arr001(threaded1)         
   arr002(threaded1)         
   arr003(threaded1)         
   arr004(threaded1)         
   arr005(threaded1)         
   arr006(threaded1)         
   arr007(threaded1)         
   arr008(threaded1)         
   arr009(threaded1)         
   arr010(threaded1)         
   arr011(threaded1)         
   arr012(threaded1)         
   arr013(threaded1)         
   arr014(threaded1)         
   arr015(threaded1)         
   arr016(threaded1)         
   arr017(threaded1)         
   arr018(threaded1)         
   arr019(threaded1)         
   arrowrun001(threaded1)    
   arrowrun002(threaded1)    
   arrowrun003(threaded1)    
   arrowrun004(threaded1)    
   barton-mangler-bug(profc,threaded1)
   break024(ghci)                     
   bug1010(threaded1)                 
   bytestring002(threaded1)           
   bytestring003(threaded1)           
   bytestring006(threaded1)           
   cg001(threaded1)                   
   cg002(threaded1)                   
   cg003(threaded1)                   
   cg004(threaded1)                   
   cg005(threaded1)                   
   cg006(threaded1)                   
   cg007(threaded1)                   
   cg008(threaded1)                   
   cg009(threaded1)                   
   cg010(threaded1)                   
   cg011(threaded1)                   
   cg012(threaded1)                   
   cg013(threaded1)                   
   cg014(threaded1)                   
   cg015(threaded1)                   
   cg016(threaded1)                   
   cg017(threaded1)                   
   cg018(threaded1)                   
   cg019(threaded1)                   
   cg020(threaded1)                   
   cg021(threaded1)                   
   cg022(threaded1)                   
   cg024(threaded1)                   
   cg026(threaded1)                   
   cg027(threaded1)                   
   cg028(threaded1)                   
   cg031(threaded1)                   
   cg032(threaded1)                   
   cg033(threaded1)                   
   cg034(threaded1)                   
   cg035(threaded1)                   
   cg036(threaded1)                   
   cg037(threaded1)                   
   cg038(threaded1)                   
   cg039(threaded1)                   
   cg040(threaded1)                   
   cg043(threaded1)                   
   cg044(threaded1)                   
   cg045(threaded1)                   
   cg046(threaded1)                   
   cg047(threaded1)                   
   cg048(threaded1)                   
   cg049(threaded1)                   
   cg050(threaded1)                   
   cg051(threaded1)                   
   cg053(threaded1)                   
   cg054(threaded1)                   
   cg055(threaded1)                   
   cg056(threaded1)                   
   cg058(threaded1)                   
   cg059(threaded1)                   
   cg060(threaded1)                   
   cg061(threaded1)                   
   cg062(threaded1)                   
   cg063(threaded1)                   
   char001(threaded1)                 
   char002(threaded1)                 
   cholewo-eval(threaded1)            
   church(threaded1)                  
   conc001(threaded1)                 
   conc002(threaded1)                 
   conc003(threaded1)                 
   conc004(threaded1)                 
   conc006(threaded1)                 
   conc007(threaded1)                 
   conc008(threaded1)                 
   conc009(threaded1)                 
   conc010(threaded1)                 
   conc012(ghci,threaded1)            
   conc013(threaded1)                 
   conc014(threaded1)                 
   conc015(threaded1)                 
   conc016(threaded1)                 
   conc017(threaded1)                 
   conc018(threaded1)                 
   conc019(threaded1)                 
   conc020(threaded1)                 
   conc021(threaded1)                 
   conc022(threaded1)                 
   conc023(threaded1)                 
   conc024(threaded1)                 
   conc025(threaded1)                 
   conc026(threaded1)                 
   conc027(threaded1)                 
   conc028(threaded1)                 
   conc029(threaded1)                 
   conc030(threaded1)                 
   conc031(threaded1)                 
   conc032(threaded1)                 
   conc033(threaded1)                 
   conc034(threaded1)                 
   conc035(threaded1)                 
   conc036(threaded1)                 
   conc037(threaded1)                 
   conc038(threaded1)                 
   conc040(threaded1)                 
   conc041(threaded1)                 
   conc042(threaded1)                 
   conc043(threaded1)                 
   conc044(threaded1)                 
   conc045(threaded1)                 
   conc051(threaded1)                 
   conc058(threaded1)                 
   conc059(threaded1)                 
   conc064(threaded1)                 
   conc065(threaded1)                 
   conc066(threaded1)                 
   conc067(threaded1)                 
   conc068(threaded1)                 
   conc069(threaded1)                 
   conc070(threaded1)                 
   concio002(threaded1)               
   concprog001(ghci,threaded1)        
   countReaders001(threaded1)         
   cvh_unboxing(threaded1)            
   decodingerror001(threaded1)        
   derefnull(threaded1)               
   divbyzero(threaded1)               
   drvrun-foldable1(threaded1)        
   drvrun-functor1(threaded1)         
   drvrun001(threaded1)               
   drvrun002(threaded1)               
   drvrun003(threaded1)               
   drvrun004(threaded1)               
   drvrun005(threaded1)               
   drvrun006(threaded1)               
   drvrun007(threaded1)               
   drvrun008(threaded1)               
   drvrun009(threaded1)               
   drvrun010(threaded1)               
   drvrun011(threaded1)               
   drvrun012(threaded1)               
   drvrun013(threaded1)               
   drvrun014(threaded1)               
   drvrun015(threaded1)               
   drvrun016(threaded1)               
   drvrun017(threaded1)               
   drvrun018(threaded1)               
   drvrun019(threaded1)               
   drvrun020(threaded1)               
   drvrun021(threaded1)               
   drvrun022(threaded1)               
   dsrun001(threaded1)                
   dsrun002(threaded1)                
   dsrun003(threaded1)                
   dsrun004(threaded1)                
   dsrun005(threaded1)                
   dsrun006(threaded1)                
   dsrun007(threaded1)                
   dsrun008(threaded1)                
   dsrun009(threaded1)                
   dsrun010(threaded1)                
   dsrun011(threaded1)                
   dsrun012(threaded1)                
   dsrun013(threaded1)                
   dsrun014(threaded1)                
   dsrun016(threaded1)                
   dsrun017(threaded1)                
   dsrun018(threaded1)                
   dsrun019(threaded1)                
   dsrun020(threaded1)                
   dsrun021(threaded1)                
   dsrun022(threaded1)                
   dsrun023(threaded1)                
   dynamic001(threaded1)              
   echo001(threaded1)                 
   encoding001(threaded1)             
   enum01(threaded1)                  
   enum02(threaded1)                  
   enum03(threaded1)                  
   exceptions001(threaded1,threaded1) 
   exceptions002(threaded1)           
   exitWith001(threaded1)             
   expfloat(threaded1)                
   fast2haskell(threaded1)            
   fdReadBuf001(threaded1)            
   fed001(threaded1)                  
   ffi001(threaded1)                  
   ffi002(threaded1)                  
   ffi003(threaded1)                  
   ffi006(threaded1)                  
   ffi007(threaded1)                  
   ffi008(threaded1)                  
   ffi010(threaded1)                  
   ffi011(threaded1)                  
   ffi013(threaded1)                  
   ffi014(threaded1)                  
   ffi015(threaded1)                  
   ffi016(threaded1)                  
   ffi017(threaded1)                  
   ffi018(threaded1)                  
   ffi019(threaded1)                  
   ffi020(threaded1)                  
   ffi021(threaded1)                  
   fileStatus(threaded1)              
   fileexist01(threaded1)             
   finalization001(threaded1)         
   forkprocess01(threaded1)           
   fptr01(threaded1)                  
   fptrfail01(threaded1)              
   fun_insts(threaded1)               
   genericNegative001(threaded1)      
   getArgs001(threaded1)              
   getEnv001(threaded1)               
   getEnvironment01(threaded1)        
   hClose001(threaded1)               
   hClose002(threaded1)               
   hClose003(threaded1)               
   hDuplicateTo001(threaded1)         
   hFileSize001(threaded1)            
   hFileSize002(threaded1)            
   hFlush001(threaded1)               
   hGetBuf001(threaded1)              
   hGetBuf002(threaded1)              
   hGetBuf003(threaded1)              
   hGetBuffering001(threaded1)        
   hGetChar001(threaded1)             
   hGetLine001(threaded1)             
   hGetLine002(threaded1)             
   hGetLine003(threaded1)             
   hGetPosn001(threaded1)             
   hIsEOF001(threaded1)               
   hIsEOF002(threaded1)               
   hPutBuf001(threaded1)              
   hPutBuf002(threaded1)              
   hReady001(threaded1)               
   hSeek001(threaded1)                
   hSeek002(threaded1)                
   hSeek003(threaded1)                
   hSeek004(threaded1)                
   hSetBuffering002(threaded1)        
   hSetBuffering003(threaded1)        
   hSetBuffering004(threaded1)        
   hSetEncoding001(threaded1)         
   hTell001(threaded1)                
   hTell002(threaded1)                
   hash001(threaded1)                 
   integerBits(threaded1)             
   integerConversions(threaded1)      
   ioeGetErrorString001(threaded1)    
   ioeGetFileName001(threaded1)       
   ioeGetHandle001(threaded1)         
   ioref001(threaded1)                
   isEOF001(threaded1)                
   ix001(threaded1)                   
   jl_defaults(threaded1)             
   joao-circular(threaded1)           
   jq_readsPrec(threaded1)            
   jtod_circint(threaded1)            
   jules_xref(threaded1)              
   jules_xref2(threaded1)             
   launchbury(threaded1)              
   lennart_range(threaded1)           
   lex(threaded1)                     
   lexNum(threaded1)                  
   life_space_leak(threaded1)         
   list001(threaded1)                 
   list002(threaded1)                 
   list003(threaded1)                 
   memo001(threaded1)                 
   memo002(threaded1)                 
   misc001(threaded1)                 
   newline001(threaded1)              
   north_array(threaded1)             
   num001(threaded1)                  
   num002(threaded1)                  
   num003(threaded1)                  
   num004(threaded1)                  
   num005(threaded1)                  
   num006(threaded1)                  
   num007(threaded1)                  
   num008(threaded1)                  
   num009(threaded1,threaded1)        
   num010(threaded1,threaded1)        
   num011(threaded1)                  
   num012(threaded1)                  
   num013(threaded1)                  
   num014(threaded1)                  
   openFile001(threaded1)             
   openFile002(threaded1)             
   openFile003(threaded1)             
   openFile004(threaded1)             
   openFile005(threaded1)             
   openFile006(threaded1)             
   openFile007(threaded1)             
   openFile008(threaded1)             
   performGC001(threaded1)            
   putStr001(threaded1)               
   queryfdoption01(threaded1)         
   rand001(threaded1)                 
   ratio001(threaded1)                
   read001(threaded1,threaded1)       
   read002(threaded1)                 
   read003(threaded1)                 
   read004(threaded1)                 
   readFile001(threaded1)             
   readLitChar(threaded1)             
   readwrite001(threaded1)            
   readwrite002(threaded1)            
   readwrite003(threaded1)            
   record_upd(threaded1)              
   resourceLimit(threaded1)           
   rittri(threaded1)                  
   rtsflags001(normal)                
   sanders_array(threaded1)           
   seward-space-leak(threaded1)       
   show001(threaded1)                 
   showDouble(threaded1)              
   signals001(threaded1)              
   signals002(threaded1,threaded2,profthreaded)
   signals004(threaded1)                       
   stableptr001(threaded1)                     
   stableptr003(threaded1)                     
   stableptr004(threaded1)                     
   stableptr005(threaded1)                     
   stack001(threaded1)                         
   stack002(threaded1)                         
   strict_anns(threaded1)                      
   system001(threaded1)                        
   take001(threaded1)                          
   tcrun001(threaded1)                         
   tcrun002(threaded1)                         
   tcrun003(threaded1)                         
   tcrun004(threaded1)                         
   tcrun005(threaded1)                         
   tcrun006(threaded1)                         
   tcrun007(threaded1)                         
   tcrun008(threaded1)                         
   tcrun009(threaded1)                         
   tcrun010(threaded1)                         
   tcrun011(threaded1)                         
   tcrun012(threaded1)                         
   tcrun013(threaded1)                         
   tcrun014(threaded1)                         
   tcrun015(threaded1)                         
   tcrun016(threaded1)                         
   tcrun017(threaded1)                         
   tcrun018(threaded1)                         
   tcrun019(threaded1)                         
   tcrun020(threaded1)                         
   tcrun021(threaded1)                         
   tcrun022(threaded1)                         
   tcrun023(threaded1)                         
   tcrun024(threaded1)                         
   tcrun025(threaded1)                         
   tcrun027(threaded1)                         
   tcrun028(threaded1)                         
   tcrun029(threaded1)                         
   tcrun030(threaded1)                         
   tcrun031(threaded1)                         
   tcrun032(threaded1)                         
   tcrun033(threaded1)                         
   tcrun034(threaded1)                         
   tcrun035(threaded1)
   tcrun036(threaded1)
   tcrun037(threaded1)
   tcrun038(threaded1)
   tcrun039(threaded1)
   tcrun040(threaded1)
   tcrun041(threaded1)
   tcrun042(threaded1)
   testblockalloc(threaded1)
   testeq2(threaded1)
   testwsdeque(threaded1)
   text001(threaded1)
   thurston-modular-arith(threaded1)
   time002(threaded1)
   time003(threaded1)
   time004(threaded1)
   trace001(threaded1)
   tup001(threaded1)
   typecheck.testeq1(threaded1)
   unicode001(threaded1,threaded1)
   unicode002(threaded1)
   user001(threaded1)
   weak001(threaded1)


From daniel.is.fischer at web.de  Mon Dec 14 16:49:51 2009
From: daniel.is.fischer at web.de (Daniel Fischer)
Date: Mon Dec 14 16:25:26 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <20091214133614.GA11826@matrix.chaos.earth.li>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
Message-ID: <200912142249.52489.daniel.is.fischer@web.de>

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 ghc-6.10.4 'cabal-install >= 0.8'
$ cabal install -w ghc-6.10.3 'cabal-install >= 0.8'
Resolving dependencies...
cabal: There is no available version of cabal-install that satisfies >=0.8

Oops, nothing higher than 0.6.4 on Hackage, even darcs.haskell.org/cabal-install is only 
version 0.7.5. 
That seems to work, though, but I needed to manually install network, mtl and parsec 
before bootstrap.sh ran.
From duncan.coutts at googlemail.com  Mon Dec 14 18:42:14 2009
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Mon Dec 14 18:16:24 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <200912142249.52489.daniel.is.fischer@web.de>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
	<200912142249.52489.daniel.is.fischer@web.de>
Message-ID: <1260834134.9220.28404.camel@localhost>

On Mon, 2009-12-14 at 22:49 +0100, Daniel Fischer wrote:
> 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 ghc-6.10.4 'cabal-install >= 0.8'
> $ cabal install -w ghc-6.10.3 'cabal-install >= 0.8'
> Resolving dependencies...
> cabal: There is no available version of cabal-install that satisfies >=0.8
> 
> Oops, nothing higher than 0.6.4 on Hackage, even
> darcs.haskell.org/cabal-install is only version 0.7.5. 

Right, the cabal-install 0.8.x release will appear in due course.

It shouldn't be too long since I've already been using it for Hackage
regression testing of ghc-6.12.

> That seems to work, though, but I needed to manually install network, mtl and parsec 
> before bootstrap.sh ran.

Yes, the bootstrap needs updating to take account of the fact that those
packages are no longer shipped with ghc-6.12.

Duncan

From bos at serpentine.com  Tue Dec 15 01:09:45 2009
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Tue Dec 15 00:43:48 2009
Subject: ByteString-backed Handles, and another couple of questions
Message-ID: <c290c4f20912142209l1ed611c0s913cca6a71f6acb5@mail.gmail.com>

Hi, Simon -

I just added support to Data.Text for your new Unicode-based Handle
implementation, and I'd like to write some tests. The natural way to do this
would be to create Handles that will write to, and read from, ByteStrings.
Does any such code exist at the moment? I don't see it in base or
bytestring, though all the necessary abstractions appear to be present.

Also, the place I hooked into the new I/O machinery was at the next level up
from CharBuffer. Because the implementation of CharBuffer isn't abstract, I
had no opportunity to put a text array in there, so there's an extra amount
of copying that happens when going from byte buffer to char buffer to Text.
It's a bit of a shame, but I don't see a way around it at the moment. Would
you be interested in trying to remove that extra copy, or is the current
interface set in stone?

Many thanks for your great work on this,
Bryan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091215/e80220fe/attachment.html
From luca_ciciriello at hotmail.com  Tue Dec 15 01:41:06 2009
From: luca_ciciriello at hotmail.com (Luca Ciciriello)
Date: Tue Dec 15 01:15:09 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <78CF5903-8F3D-4A78-96F3-3D565C96B266@ece.cmu.edu>
References: <20091214162147.68B2E3246EB@www.haskell.org>
	<4B268C22.5070006@mathematik.uni-marburg.de>,
	<78CF5903-8F3D-4A78-96F3-3D565C96B266@ece.cmu.edu>
Message-ID: <SNT128-W515E37BD087C672776E0A09A880@phx.gbl>


Thanks to all.

BTW, reading the new wiki library page I've noticed that I can use atomically, pseq, par, forkIO, etc, simply importing GHC.Conc

 

Luca
 
> CC: allbery@ece.cmu.edu; luca_ciciriello@hotmail.com; glasgow-haskell-users@haskell.org
> From: allbery@ece.cmu.edu
> To: berthold@Mathematik.Uni-Marburg.de
> Subject: Re: ANNOUNCE: GHC version 6.12.1
> Date: Mon, 14 Dec 2009 14:25:21 -0500
> 
> On Dec 14, 2009, at 14:04 , Jost Berthold wrote:
> > The reason is, when packaging "parallel", this package has been 
> > removed from the GHC core libraries. BTW I am unsure whether this is 
> > at all clever, since it needs specific GHC support (at least for now 
> > - am I right here?)
> 
> 
> Only to the extent that the (standardized) primitives are only in GHC; 
> the packages were released and tested with 6.10.x.
> 
> -- 
> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
> system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
> electrical and computer engineering, carnegie mellon university KF8NH
> 
> 
 		 	   		  
_________________________________________________________________
View your other email accounts from your Hotmail inbox. Add them now.
http://clk.atdmt.com/UKM/go/186394592/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091215/8dcc5508/attachment.html
From su2admin at gmail.com  Tue Dec 15 03:20:08 2009
From: su2admin at gmail.com (flw)
Date: Tue Dec 15 02:54:10 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <SNT128-W515E37BD087C672776E0A09A880@phx.gbl>
References: <20091214162147.68B2E3246EB@www.haskell.org>
	<4B268C22.5070006@mathematik.uni-marburg.de>
	<78CF5903-8F3D-4A78-96F3-3D565C96B266@ece.cmu.edu>
	<SNT128-W515E37BD087C672776E0A09A880@phx.gbl>
Message-ID: <e9907a700912150020y650ee45q19e6328a029abfcc@mail.gmail.com>

After I installed GHC-6.12.1, the cabal-install program could not works
normally.

$ sudo cabal install
cabal: failed to parse output of 'ghc-pkg dump'
$

please help me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091215/43cb6948/attachment.html
From marlowsd at gmail.com  Tue Dec 15 04:39:59 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue Dec 15 04:14:09 2009
Subject: ByteString-backed Handles, and another couple of questions
In-Reply-To: <c290c4f20912142209l1ed611c0s913cca6a71f6acb5@mail.gmail.com>
References: <c290c4f20912142209l1ed611c0s913cca6a71f6acb5@mail.gmail.com>
Message-ID: <4B27596F.5010501@gmail.com>

On 15/12/09 06:09, Bryan O'Sullivan wrote:

> I just added support to Data.Text for your new Unicode-based Handle
> implementation, and I'd like to write some tests. The natural way to do
> this would be to create Handles that will write to, and read from,
> ByteStrings. Does any such code exist at the moment? I don't see it in
> base or bytestring, though all the necessary abstractions appear to be
> present.

I haven't implemented a bytestring-backed Handle, but as you say all the 
abstractions should be present.  It would be a great thing to have on 
Hackage.

A good starting point would be the mmap-backed Handle code that I wrote 
for my talk at the Haskell Implementors Workshop last year.  I'd 
intended to polish this up and upload to Hackage, but never got around 
to it.  I've put the code here for now:

http://www.haskell.org/~simonmar/mmap-handle.tar.gz

> Also, the place I hooked into the new I/O machinery was at the next
> level up from CharBuffer. Because the implementation of CharBuffer isn't
> abstract, I had no opportunity to put a text array in there, so there's
> an extra amount of copying that happens when going from byte buffer to
> char buffer to Text. It's a bit of a shame, but I don't see a way around
> it at the moment. Would you be interested in trying to remove that extra
> copy, or is the current interface set in stone?

Yes, you may remember we talked about this in Edinburgh (the conversion 
would probably make more sense to you now than it did then :-).

One thing I experimented with is making CharBuffers use UTF-16.  You'll 
see some instances of #ifdef CHARBUF_UTF16 in the code - it partially 
works, I believe the main missing piece is support in the built-in 
codecs.  I don't think it would be too hard to fix them, they just need 
to more abstract about offsets in the CharBuffer; 
writeCharBuffer/readCharBuffer already handle the UTF-16 encoding/decoding.

So one possibility is to get this working and then avoid the extra copy 
by just taking out the ByteArray# inside a CharBuffer and turning it 
into a text buffer. I'm not sure of the details here, but I imagine 
something along those lines would work.  We would then have to allocate 
a new CharBuffer for the Handle.

Another possibility is (as you suggested) to make Handles independent of 
the representation of the CharBuffer, making it completely abstract.  I 
haven't put much thought into that, it might well be a better approach. 
  It would presumably involve a new existential class constraint in the 
Handle for the CharBuffer operations, and we'd have to be careful about 
performance: currently I think the CharBuffer operations get inlined nicely.

Cheers,
	Simon
From marlowsd at gmail.com  Tue Dec 15 04:43:10 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue Dec 15 04:17:20 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <200912142216.14919.daniel.is.fischer@web.de>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
	<200912142216.14919.daniel.is.fischer@web.de>
Message-ID: <4B275A2E.2020703@gmail.com>

On 14/12/09 21:16, Daniel Fischer wrote:
> 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
> Linux linux-mkk1 2.6.27.39-0.2-pae #1 SMP 2009-11-23 12:57:38 +0100 i686 i686 i386
> GNU/Linux
> (openSuse 11.1)
>
> Running the testsuit gave
>
> OVERALL SUMMARY for test run started at Mo 14. Dez 18:06:00 CET 2009
>      2352 total tests, which gave rise to
>     13034 test cases, of which
>         0 caused framework failures
>      2760 were skipped
>
>      9471 expected passes
>       328 expected failures
>         0 unexpected passes
>       475 unexpected failures
>
> Is that good or bad?
> Almost all unexpected failures are with threaded1, the vast majority of them due to
>
> /usr/src/packages/BUILD/binutils-2.19/build-dir/bfd/../../bfd/compress.c:96:0:
>       undefined reference to `inflateInit_'

Please submit a bug report.  Presumably we need a configure test for -lz 
somewhere.

Cheers,
	Simon
From marlowsd at gmail.com  Tue Dec 15 04:48:43 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue Dec 15 04:22:49 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <e9907a700912150020y650ee45q19e6328a029abfcc@mail.gmail.com>
References: <20091214162147.68B2E3246EB@www.haskell.org>	<4B268C22.5070006@mathematik.uni-marburg.de>	<78CF5903-8F3D-4A78-96F3-3D565C96B266@ece.cmu.edu>	<SNT128-W515E37BD087C672776E0A09A880@phx.gbl>
	<e9907a700912150020y650ee45q19e6328a029abfcc@mail.gmail.com>
Message-ID: <4B275B7B.4030304@gmail.com>

On 15/12/09 08:20, flw wrote:
> After I installed GHC-6.12.1, the cabal-install program could not works
> normally.
>
> $ sudo cabal install
> cabal: failed to parse output of 'ghc-pkg dump'
> $

You need an updated version of cabal-install.  As I understand it, 
version 0.8 has not been released yet, but you can get it from the darcs 
repository:

darcs get http://darcs.haskell.org/cabal-install
cd cabal-install
./bootstrap.sh

Cheers,
	Simon
From marlowsd at gmail.com  Tue Dec 15 04:57:46 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue Dec 15 04:31:51 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <4B268C22.5070006@mathematik.uni-marburg.de>
References: <20091214162147.68B2E3246EB@www.haskell.org>
	<4B268C22.5070006@mathematik.uni-marburg.de>
Message-ID: <4B275D9A.2000709@gmail.com>

On 14/12/09 19:04, Jost Berthold wrote:
> Luca,
>
> to use Control.Parallel, you need to download and install two packages,
> deepseq and parallel, from hackage.haskell.org.
> Most likely this will work with cabal, or you just download the two
> tarballs .

cabal install parallel

(assuming you have a working cabal-install)

> The reason is, when packaging "parallel", this package has been removed
> from the GHC core libraries. BTW I am unsure whether this is at all
> clever, since it needs specific GHC support (at least for now - am I
> right here?)
>
> In addition, be informed that Control.Parallel.Strategies has been
> heavily restructured just last month (splitting it into deepseq and
> parallel is one of the changes, but not the most fundamental).
> If you want to try examples from GpH publications, you will certainly
> have some problems. parallel-1.x versions containing the original
> definitions are on hackage as well and should work for experiments.

I think it would be a good idea to have a wiki page describing the 
differences between the API used in those papers and the current API. 
Off the top of my head, the main differences are:

  * import Control.Parallel.Strategies, not import Strategies
  * seq is now pseq
  * rnf is now rdeepseq
  * don't use demanding, sparking

Better still would be a selection of recipes or patterns for 
parallelising Haskell code.

Anyone feel like tackling this? (I realise I'm the obvious person to do 
it, but I'm deep in mid-hack on the parallel GC and don't want to get 
too distracted right now).

Cheers,
	Simon
From colin at colina.demon.co.uk  Tue Dec 15 05:53:06 2009
From: colin at colina.demon.co.uk (Colin Paul Adams)
Date: Tue Dec 15 05:27:10 2009
Subject: Porting to DragonFly BSD
In-Reply-To: <20091115124246.GA98551@horse.gocht-isenmann.de> (Goetz
	Isenmann's message of "Sun\, 15 Nov 2009 13\:42\:46 +0100")
References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com>
	<20091106232522.GA35866@horse.gocht-isenmann.de>
	<m3ws1t9j45.fsf@colina.demon.co.uk>
	<20091115124246.GA98551@horse.gocht-isenmann.de>
Message-ID: <m3r5qwy0dp.fsf@colina.demon.co.uk>

>>>>> "Goetz" == Goetz Isenmann <info@goetz-isenmann.de> writes:

    Goetz> My current strategie is, to avoid the problem in a first
    Goetz> step.

    Goetz> With the attached errno_ptr.{h,c} I create a shared
    Goetz> library, that encapsulates the errno access, install the
    Goetz> header file as /usr/pkg/include/errno_ptr.h and the shared
    Goetz> lib as /usr/pkg/lib/liberrno_ptr.so

    Goetz> Building ghc-6.10.4 with the attached patch (only a quick
    Goetz> hack, to check the idea) I get a result, that looks much
    Goetz> better.

    Goetz> @Colin: Maybe you can test and use this hack.

I've finally got round to trying this. I'm having a problem which
maybe has a simple known solution.

What I have done so far:

1) Built and deployed the shared library as detailed above
2) Applied the diff with patch <diff-name
3) cd chc-6.10.4
4) ./configure
5) make

Make immediately fails with:

"./mk/boilerplate.mk", line 41: Need an operator
"./mk/boilerplate.mk", line 44: Need an operator
"./mk/config.mk", line 29: Need an operator
"./mk/config.mk", line 30: Need an operator
"./mk/config.mk", line 31: Need an operator
"./mk/config.mk", line 32: Need an operator
"./mk/config.mk", line 33: Need an operator
"./mk/config.mk", line 169: Need an operator
"./mk/config.mk", line 171: Need an operator
"./mk/config.mk", line 173: Need an operator
"./mk/config.mk", line 196: Need an operator
"./mk/config.mk", line 210: Need an operator
"./mk/config.mk", line 268: Need an operator
"./mk/config.mk", line 270: Need an operator
"./mk/config.mk", line 272: Need an operator
Error expanding embedded variable.

I'm not exactly familiar with makefile syntax, so I could see anything
that rang alarm bells. Line 41 looks like:

ifneq "$(way)" ""


-- 
Colin Adams
Preston Lancashire
From thanos at sians.org  Tue Dec 15 06:47:41 2009
From: thanos at sians.org (Thanos Tsouanas)
Date: Tue Dec 15 06:21:44 2009
Subject: Porting to DragonFly BSD
In-Reply-To: <m3r5qwy0dp.fsf@colina.demon.co.uk>
References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com>
	<20091106232522.GA35866@horse.gocht-isenmann.de>
	<m3ws1t9j45.fsf@colina.demon.co.uk>
	<20091115124246.GA98551@horse.gocht-isenmann.de>
	<m3r5qwy0dp.fsf@colina.demon.co.uk>
Message-ID: <1727208b0912150347m10ce3deen3ff69bb610d65bd@mail.gmail.com>

On Tue, Dec 15, 2009 at 12:53 PM, Colin Paul Adams
<colin@colina.demon.co.uk> wrote:
>
> [..snip..]
>
> I've finally got round to trying this. I'm having a problem which
> maybe has a simple known solution.
>
> What I have done so far:
>
> 1) Built and deployed the shared library as detailed above
> 2) Applied the diff with patch <diff-name
> 3) cd chc-6.10.4
> 4) ./configure
> 5) make

You should use gmake instead of make.

> Make immediately fails with:
>
> "./mk/boilerplate.mk", line 41: Need an operator
> "./mk/boilerplate.mk", line 44: Need an operator
>
> [..snip..]

-- 
Thanos Tsouanas
http://mpla.math.uoa.gr/~thanos/
From colin at colina.demon.co.uk  Tue Dec 15 06:53:15 2009
From: colin at colina.demon.co.uk (Colin Paul Adams)
Date: Tue Dec 15 06:27:18 2009
Subject: Porting to DragonFly BSD
In-Reply-To: <4B276F90.1000209@centrum.cz> (Karel Gardas's message of "Tue\,
	15 Dec 2009 12\:14\:24 +0100")
References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com>
	<20091106232522.GA35866@horse.gocht-isenmann.de>
	<m3ws1t9j45.fsf@colina.demon.co.uk>
	<20091115124246.GA98551@horse.gocht-isenmann.de>
	<m3r5qwy0dp.fsf@colina.demon.co.uk> <4B276F90.1000209@centrum.cz>
Message-ID: <m3my1kxxlg.fsf@colina.demon.co.uk>

>>>>> "Karel" == Karel Gardas <karel.gardas@centrum.cz> writes:

    Karel> Seeing DragonFly BSD and `make' together with your make
    Karel> error messages rings an alarm here with a suggestion to use
    Karel> GNU make.

That's a good alarm you have :-)

gmake works much better. Thanks.
-- 
Colin Adams
Preston Lancashire
From igloo at earth.li  Tue Dec 15 06:53:58 2009
From: igloo at earth.li (Ian Lynagh)
Date: Tue Dec 15 06:28:04 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <SNT128-W515E37BD087C672776E0A09A880@phx.gbl>
References: <20091214162147.68B2E3246EB@www.haskell.org>
	<78CF5903-8F3D-4A78-96F3-3D565C96B266@ece.cmu.edu>
	<SNT128-W515E37BD087C672776E0A09A880@phx.gbl>
Message-ID: <20091215115358.GA3875@matrix.chaos.earth.li>

On Tue, Dec 15, 2009 at 06:41:06AM +0000, Luca Ciciriello wrote:
> 
> BTW, reading the new wiki library page I've noticed that I can use atomically, pseq, par, forkIO, etc, simply importing GHC.Conc

Note that that is not a supported interface, and may break in future
releases.


Thanks
Ian

From daniel.is.fischer at web.de  Tue Dec 15 06:53:10 2009
From: daniel.is.fischer at web.de (Daniel Fischer)
Date: Tue Dec 15 06:28:44 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <4B275A2E.2020703@gmail.com>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
	<200912142216.14919.daniel.is.fischer@web.de>
	<4B275A2E.2020703@gmail.com>
Message-ID: <200912151253.10997.daniel.is.fischer@web.de>

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,
> 	Simon

Thanks,
Daniel
From igloo at earth.li  Tue Dec 15 06:56:54 2009
From: igloo at earth.li (Ian Lynagh)
Date: Tue Dec 15 06:30:56 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <m3y6l6n3z1.wl%greenrd@greenrd.org>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
	<m3y6l6n3z1.wl%greenrd@greenrd.org>
Message-ID: <20091215115654.GB3875@matrix.chaos.earth.li>

On Sun, Dec 13, 2009 at 06:06:26PM +0000, Robin Green wrote:
> I have been using GHC 6.12.1 from
> http://www.haskell.org/ghc/dist/6.12.1-pre/ (which doesn't exist any
> more). Do I need to upgrade, or is it exactly the same? Do I need to
> recompile packages?

I wouldn't recommend using unannounced binaries from the website, but in
this case it's exactly the same as the 6.12.1 release.


Thanks
Ian

From igloo at earth.li  Tue Dec 15 06:57:43 2009
From: igloo at earth.li (Ian Lynagh)
Date: Tue Dec 15 06:31:45 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <f73f66150912140624s634a5742kde32483ab12cadbe@mail.gmail.com>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
	<f73f66150912140624s634a5742kde32483ab12cadbe@mail.gmail.com>
Message-ID: <20091215115743.GC3875@matrix.chaos.earth.li>

On Mon, Dec 14, 2009 at 03:24:05PM +0100, Bas van Dijk wrote:
> There's a broken link to the Haskell Platform in:
> 
> http://haskell.org/ghc/docs/6.12.1/html/users_guide/release-6-12-1.html#id2890234

Thanks; fixed with a redirect.


Thanks
Ian

From colin at colina.demon.co.uk  Tue Dec 15 08:19:26 2009
From: colin at colina.demon.co.uk (Colin Paul Adams)
Date: Tue Dec 15 07:53:33 2009
Subject: Porting to DragonFly BSD
In-Reply-To: <20091115124246.GA98551@horse.gocht-isenmann.de> (Goetz
	Isenmann's message of "Sun\, 15 Nov 2009 13\:42\:46 +0100")
References: <1afdeaec0911040708k3304ae2fuadf9221a8f5cd719@mail.gmail.com>
	<20091106232522.GA35866@horse.gocht-isenmann.de>
	<m3ws1t9j45.fsf@colina.demon.co.uk>
	<20091115124246.GA98551@horse.gocht-isenmann.de>
Message-ID: <m3hbrsxtlt.fsf@colina.demon.co.uk>

>>>>> "Goetz" == Goetz Isenmann <info@goetz-isenmann.de> writes:

    Goetz> With the attached errno_ptr.{h,c} I create a shared
    Goetz> library, that encapsulates the errno access, install the
    Goetz> header file as /usr/pkg/include/errno_ptr.h and the shared
    Goetz> lib as /usr/pkg/lib/liberrno_ptr.so

    Goetz> Building ghc-6.10.4 with the attached patch (only a quick
    Goetz> hack, to check the idea) I get a result, that looks much
    Goetz> better.

    Goetz> @Colin: Maybe you can test and use this hack.

It seems to work alright.
-- 
Colin Adams
Preston Lancashire
From bos at serpentine.com  Tue Dec 15 15:48:56 2009
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Tue Dec 15 15:22:59 2009
Subject: ByteString-backed Handles, and another couple of questions
In-Reply-To: <4B27596F.5010501@gmail.com>
References: <c290c4f20912142209l1ed611c0s913cca6a71f6acb5@mail.gmail.com>
	<4B27596F.5010501@gmail.com>
Message-ID: <c290c4f20912151248qc73ff81n44e607eadbabbb1@mail.gmail.com>

On Tue, Dec 15, 2009 at 1:39 AM, Simon Marlow <marlowsd@gmail.com> wrote:

>
> I haven't implemented a bytestring-backed Handle, but as you say all the
> abstractions should be present.  It would be a great thing to have on
> Hackage.
>
> A good starting point would be the mmap-backed Handle code that I wrote for
> my talk at the Haskell Implementors Workshop last year.  I'd intended to
> polish this up and upload to Hackage, but never got around to it.  I've put
> the code here for now:
>
> http://www.haskell.org/~simonmar/mmap-handle.tar.gz


Ooh, thanks! I'll take a look-see.


> Yes, you may remember we talked about this in Edinburgh (the conversion
> would probably make more sense to you now than it did then :-).
>

I do indeed remember :-)

One thing I experimented with is making CharBuffers use UTF-16.  You'll see
> some instances of #ifdef CHARBUF_UTF16 in the code - it partially works, I
> believe the main missing piece is support in the built-in codecs.  I don't
> think it would be too hard to fix them, they just need to more abstract
> about offsets in the CharBuffer; writeCharBuffer/readCharBuffer already
> handle the UTF-16 encoding/decoding.
>

> So one possibility is to get this working and then avoid the extra copy by
> just taking out the ByteArray# inside a CharBuffer and turning it into a
> text buffer. I'm not sure of the details here, but I imagine something along
> those lines would work.  We would then have to allocate a new CharBuffer for
> the Handle.
>

Yes, that would amount to double-buffering, and would work nicely, only the
current buffers go through foreign pointers while text uses an unpinned
array. I can see why this is (so iconv can actually work), but it does
introduce a fly into the ointment :-)


> Another possibility is (as you suggested) to make Handles independent of
> the representation of the CharBuffer, making it completely abstract.  I
> haven't put much thought into that, it might well be a better approach.  It
> would presumably involve a new existential class constraint in the Handle
> for the CharBuffer operations, and we'd have to be careful about
> performance: currently I think the CharBuffer operations get inlined nicely.
>

Aye. I think this would have the same problem with foreign transcoding code
that wants a reliable pointer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091215/833db00d/attachment-0001.html
From duncan.coutts at googlemail.com  Tue Dec 15 22:02:07 2009
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Tue Dec 15 21:36:09 2009
Subject: ByteString-backed Handles, and another couple of questions
In-Reply-To: <c290c4f20912151248qc73ff81n44e607eadbabbb1@mail.gmail.com>
References: <c290c4f20912142209l1ed611c0s913cca6a71f6acb5@mail.gmail.com>
	<4B27596F.5010501@gmail.com>
	<c290c4f20912151248qc73ff81n44e607eadbabbb1@mail.gmail.com>
Message-ID: <1260932527.9220.36732.camel@localhost>

On Tue, 2009-12-15 at 12:48 -0800, Bryan O'Sullivan wrote:

> 
> Yes, that would amount to double-buffering, and would work nicely,
> only the current buffers go through foreign pointers while text uses
> an unpinned array. I can see why this is (so iconv can actually work),
> but it does introduce a fly into the ointment :-)

It should not be strictly necessary to use a ForeignPtr in this case. If
the IO buffers use pinned ByteArray#s then they can still be passed to
iconv for it to write into.

It should also be possible for Text to be constructed from a pinned
ByteArray#.

Duncan

From marlowsd at gmail.com  Wed Dec 16 04:26:40 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed Dec 16 04:00:52 2009
Subject: ByteString-backed Handles, and another couple of questions
In-Reply-To: <1260932527.9220.36732.camel@localhost>
References: <c290c4f20912142209l1ed611c0s913cca6a71f6acb5@mail.gmail.com>	
	<4B27596F.5010501@gmail.com>	
	<c290c4f20912151248qc73ff81n44e607eadbabbb1@mail.gmail.com>
	<1260932527.9220.36732.camel@localhost>
Message-ID: <4B28A7D0.7040600@gmail.com>

On 16/12/09 03:02, Duncan Coutts wrote:
> On Tue, 2009-12-15 at 12:48 -0800, Bryan O'Sullivan wrote:
>
>>
>> Yes, that would amount to double-buffering, and would work nicely,
>> only the current buffers go through foreign pointers while text uses
>> an unpinned array. I can see why this is (so iconv can actually work),
>> but it does introduce a fly into the ointment :-)
>
> It should not be strictly necessary to use a ForeignPtr in this case. If
> the IO buffers use pinned ByteArray#s then they can still be passed to
> iconv for it to write into.
>
> It should also be possible for Text to be constructed from a pinned
> ByteArray#.

I don't think there's any real difficulty here.  The IO buffers are 
ForeignPtrs because we want the flexibility of being able to use mmap'd 
memory - the mmap-backed Handle implementation uses that.  But in normal 
operation these ForeignPtrs have pinned ByteArray#s inside.

We could provide a function of type ForeignPtr -> IO (Maybe ByteArray), 
and the text package can turn that into a chunk of Text.  It would even 
be able to support reading Text from mmaped memory, because only the 
byte buffer needs to be mmaped, not the Char buffer.

Cheers,
	Simon
From bayer at cpw.math.columbia.edu  Thu Dec 17 08:12:51 2009
From: bayer at cpw.math.columbia.edu (Dave Bayer)
Date: Thu Dec 17 07:46:48 2009
Subject: ANNOUNCE: GHC version 6.12.1
In-Reply-To: <1260800682-sup-1666@nixos>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
	<SNT128-W2929BB6876A43985DBAD5D9A890@phx.gbl>
	<1260800682-sup-1666@nixos>
Message-ID: <E74BFCEE-1C6E-4D81-B2F4-46E11E77ACE4@math.columbia.edu>

On Dec 14, 2009, at 6:24 AM, Marc Weber wrote:

> You should be able to get some hints by looking at where ghc is installed.

For any install of this sort, I like to record where the changes were made.

Before an install, I execute the shell command

	echo >timestamp

Then I install, then I execute the shell command (OS X 10.6; adapt for other Unix)

	sudo find -x / -newer timestamp -print >snapshot.txt

If I leave scripts "before-snapshot.sh" and "after-snapshot.sh" near my install source, of the form

	#!/bin/bash

	# cd to directory of this script
	cd "`echo $0 | sed 's/[^/]*$//'`"

	sudo find -x / -newer timestamp -print >snapshot.txt

then in OS X 10.6 I can drag each script in turn to a terminal window, with the results automatically ending up in their directory.

Editing out the noise, I recorded the following on OS X 10.6 for GHC 6.12.1:

	/Library/Frameworks/GHC.framework
	/Library/Frameworks/GHC.framework/Resources
	/Library/Frameworks/GHC.framework/Tools
	/Library/Frameworks/GHC.framework/Versions
	/Library/Frameworks/GHC.framework/Versions/612/usr/bin
	/Library/Frameworks/GHC.framework/Versions/612/usr/bin/ghc
	/Library/Frameworks/GHC.framework/Versions/612/usr/bin/ghc-pkg
	/Library/Frameworks/GHC.framework/Versions/612/usr/bin/ghci
	/Library/Frameworks/GHC.framework/Versions/612/usr/bin/runhaskell
	/Library/Frameworks/GHC.framework/Versions/Current
	/private/var/db/receipts/org.haskell.glasgowHaskellCompiler.ghc.pkg.bom
	/private/var/db/receipts/org.haskell.glasgowHaskellCompiler.ghc.pkg.plist
	/usr/bin
	/usr/bin/ghc
	/usr/bin/ghc-6.12.1
	/usr/bin/ghc-pkg
	/usr/bin/ghc-pkg-6.12.1
	/usr/bin/ghci
	/usr/bin/ghci-6.12.1
	/usr/bin/haddock
	/usr/bin/hp2ps
	/usr/bin/hpc
	/usr/bin/hsc2hs
	/usr/bin/runghc
	/usr/bin/runhaskell
	/usr/share/doc
	/usr/share/doc/ghc
	/usr/share/man/man1
	/usr/share/man/man1/ghc.1

From kaol at iki.fi  Thu Dec 17 09:38:29 2009
From: kaol at iki.fi (Kari Pahula)
Date: Thu Dec 17 09:12:40 2009
Subject: GPG signature for GHC 6.12.1?
In-Reply-To: <20091214133614.GA11826@matrix.chaos.earth.li>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
Message-ID: <20091217143829.GA27178@piperka.net>

On Mon, Dec 14, 2009 at 01:36:14PM +0000, Ian Lynagh wrote:
>    ==============================================================
>     The (Interactive) Glasgow Haskell Compiler -- version 6.12.1
>    ==============================================================

Cheers.

It's not a small diff from 6.10.4.  Bigger than what I'd like to eye
through myself.  As the ghc package maintainer in Debian, I'd feel
better about pushing it forward if I could see some authentication
about the tar ball's contents.  Could you please provide a GPG
signature for the release?

Linux kernels customarily sign their tarballs.  As an example.

Thank you.
From bayer at cpw.math.columbia.edu  Thu Dec 17 17:00:22 2009
From: bayer at cpw.math.columbia.edu (Dave Bayer)
Date: Thu Dec 17 16:34:18 2009
Subject: (alpha) "stick shift" cabal install for GHC 6.12.1
In-Reply-To: <1260800682-sup-1666@nixos>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
	<SNT128-W2929BB6876A43985DBAD5D9A890@phx.gbl>
	<1260800682-sup-1666@nixos>
Message-ID: <C5BBEA11-0C5E-42A0-AE5F-9DBFBC7BC779@math.columbia.edu>

I wrote the barest possible python script this morning as a poor-man's replacement for "cabal install".

Here is the script "cabal-install.py" and a sample use, "GLUT-2.2.2.0-install.sh" :

	http://hpaste.org/fastcgi/hpaste.fcgi/view?id=14367
	http://hpaste.org/fastcgi/hpaste.fcgi/view?id=14368

I copy "cabal-install.py" to "/usr/local/bin/cabal-install", and set the environment variable $CABAL to a directory of package sources which I manually download and maintain. For example, on my Mac OS X 10.6,

% echo $CABAL; cd $CABAL; ls -l GLUT-2.2.2.0

/Global/Code/Haskell/__Cabal/Packages/

total 1296
drwxr-xr-x  11 dave  admin     374 Dec 17 12:47 GLUT-2.2.2.0
-rwxr-xr-x@  1 dave  admin     165 Dec 17 12:20 GLUT-2.2.2.0-install.sh
-rw-r--r--   1 dave  admin  650235 Oct 26 14:12 GLUT-2.2.2.0.tar.gz
-rw-r--r--@  1 dave  admin      92 Dec 17 13:33 HackageDB- GLUT-2.2.2.0.webloc

"cabal-install.py" looks for package directories by exact name, including version numbers. It skips packages that are already installed, and stops on any error. My typical workflow is to edit the corresponding "install.sh" until I get the list and order of dependent packages right.

This is an alpha version; the code itself is clearer than my documentation here. If you thought about writing this and didn't yet, and can read my code, then you may want to experiment with this script. It surely got me unstuck on getting my projects to run under GHC 6.12.1. Any comments are welcome, as are suggestions for how to better share this script.

====

Background: I never got "cabal install" to work on OS X 10.5 with GHC 6.10.4, basically because zlib wouldn't work. Odd, because a perfectly good version of gunzip already exists on most platforms, and the code doesn't fall back to this version if needed.

Back when a bunch of libraries came with GHC, I didn't mind manually adding the few extra libraries I needed. Nevertheless, I tried to get "cabal install" working with OS X 10.6 and GHC 6.10.4, and again hit the zlib issue. Realizing I was a bad boy for not reporting the bug, I set up some Apple Software Restore images so I could quickly create sandbox development startup volumes, in hopes of isolating the problem.

Meanwhile, GHC 6.12.1 was released. Far fewer standard libraries made "cabal install" more critical, yet a compatible version hadn't been released. I darc'd the development head, but ran into other troubles.

There's clearly something wrong with this picture. A Rorschach blot test as to what's wrong, but I see people overreaching, if I have to wait weeks for a simple install tool, then months for the Haskell Platform to be ready. So I wrote something simpler. Not automatic, but a lot faster than installing by hand. Now I've made my peace with the GHC team's decision to get out of the library business.


From bayer at cpw.math.columbia.edu  Thu Dec 17 22:33:54 2009
From: bayer at cpw.math.columbia.edu (Dave Bayer)
Date: Thu Dec 17 22:07:49 2009
Subject: (alpha) "stick shift" cabal install for GHC 6.12.1
In-Reply-To: <C5BBEA11-0C5E-42A0-AE5F-9DBFBC7BC779@math.columbia.edu>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
	<SNT128-W2929BB6876A43985DBAD5D9A890@phx.gbl>
	<1260800682-sup-1666@nixos>
	<C5BBEA11-0C5E-42A0-AE5F-9DBFBC7BC779@math.columbia.edu>
Message-ID: <168633E1-2DD2-4DD6-ABC4-7533352477AA@math.columbia.edu>

I put up a web page with better directions, after some good experiences testing this script for my own use:

http://www.math.columbia.edu/~bayer/Haskell/cabal-install/

On Dec 17, 2009, at 2:00 PM, Dave Bayer wrote:

> I wrote the barest possible python script this morning as a poor-man's replacement for "cabal install".

From ganesh.sittampalam at credit-suisse.com  Fri Dec 18 03:09:15 2009
From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh)
Date: Fri Dec 18 02:43:19 2009
Subject: (alpha) "stick shift" cabal install for GHC 6.12.1
In-Reply-To: <C5BBEA11-0C5E-42A0-AE5F-9DBFBC7BC779@math.columbia.edu>
References: <20091214133614.GA11826@matrix.chaos.earth.li><SNT128-W2929BB6876A43985DBAD5D9A890@phx.gbl><1260800682-sup-1666@nixos>
	<C5BBEA11-0C5E-42A0-AE5F-9DBFBC7BC779@math.columbia.edu>
Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9FDF0@ELON17P32001A.csfb.cs-group.com>

Dave Bayer wrote:

> There's clearly something wrong with this picture. A Rorschach blot
> test as to what's wrong, but I see people overreaching, if I have to
> wait weeks for a simple install tool, then months for the Haskell
> Platform to be ready.

Hopefully future GHC releases will go more smoothly as far as having
cabal-install ready is concerned. But generally I think it's right to
have a gap between a GHC major release and the corresponding HP release,
in which to plan and manage any migration required. In that gap only
library authors and users who don't mind some breakage would be expected
to use the new GHC.

Cheers,

Ganesh

=============================================================================== 
 Please access the attached hyperlink for an important electronic communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 =============================================================================== 
 
From aslatter at gmail.com  Fri Dec 18 08:27:55 2009
From: aslatter at gmail.com (Antoine Latter)
Date: Fri Dec 18 08:01:47 2009
Subject: (alpha) "stick shift" cabal install for GHC 6.12.1
In-Reply-To: <C5BBEA11-0C5E-42A0-AE5F-9DBFBC7BC779@math.columbia.edu>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
	<SNT128-W2929BB6876A43985DBAD5D9A890@phx.gbl>
	<1260800682-sup-1666@nixos>
	<C5BBEA11-0C5E-42A0-AE5F-9DBFBC7BC779@math.columbia.edu>
Message-ID: <694519c50912180527w1324ed5dhc0ae3ba9e0e9b8b7@mail.gmail.com>

On Thu, Dec 17, 2009 at 4:00 PM, Dave Bayer <bayer@cpw.math.columbia.edu> wrote:
>
> Background: I never got "cabal install" to work on OS X 10.5 with GHC 6.10.4, basically because zlib wouldn't work. Odd, because a perfectly good version of gunzip already exists on most platforms, and the code doesn't fall back to this version if needed.
>

Do you have any more information about this failure? It seems like it
would be easier to get zlib to work than to replicate cabal-install.

My painful story of getting zlib to work on 10.6 is chronicled here:
http://www.haskell.org/pipermail/glasgow-haskell-users/2009-November/018068.html

But my problem should only have been an issue on OS X 10.6, not any
version lower.

Antoine
From duncan.coutts at googlemail.com  Fri Dec 18 10:57:59 2009
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Fri Dec 18 10:31:58 2009
Subject: (alpha) "stick shift" cabal install for GHC 6.12.1
In-Reply-To: <C5BBEA11-0C5E-42A0-AE5F-9DBFBC7BC779@math.columbia.edu>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
	<SNT128-W2929BB6876A43985DBAD5D9A890@phx.gbl>
	<1260800682-sup-1666@nixos>
	<C5BBEA11-0C5E-42A0-AE5F-9DBFBC7BC779@math.columbia.edu>
Message-ID: <1261151879.9220.52076.camel@localhost>

On Thu, 2009-12-17 at 14:00 -0800, Dave Bayer wrote:

> Background: I never got "cabal install" to work on OS X 10.5 with GHC
> 6.10.4, basically because zlib wouldn't work. Odd, because a perfectly
> good version of gunzip already exists on most platforms, and the code
> doesn't fall back to this version if needed.

Do you mean OSX 10.5 or 10.6. I've never heard of major problems on 10.5
and lots of problems on 10.6. The latter are all fixable.

The issue on 10.6 was that gcc defaults to compiling 64bit, but ghc
expects 32bit. The hack for ghc-6.10.4 was to change the wrapper script
to pass -optc-m32 -optl-m32. That's enough to get ghc working, but for
other packages that bind to foreign libs you also need to apply the same
trick to hsc2hs.

That's why so many people bumped into zlib not working, it was because
their hsc2hs was thinking it should be using 64bit when everything else
was expecting 32bit. That manifested in a zlib initialisation error
(because the structure size check fails).

So in short, the problems are not with cabal or zlib, you just need a
fully working ghc installation.

Duncan

From bayer at cpw.math.columbia.edu  Fri Dec 18 11:51:48 2009
From: bayer at cpw.math.columbia.edu (Dave Bayer)
Date: Fri Dec 18 11:25:49 2009
Subject: (alpha) "stick shift" cabal install for GHC 6.12.1
In-Reply-To: <694519c50912180527w1324ed5dhc0ae3ba9e0e9b8b7@mail.gmail.com>
References: <20091214133614.GA11826@matrix.chaos.earth.li>
	<SNT128-W2929BB6876A43985DBAD5D9A890@phx.gbl>
	<1260800682-sup-1666@nixos>
	<C5BBEA11-0C5E-42A0-AE5F-9DBFBC7BC779@math.columbia.edu>
	<694519c50912180527w1324ed5dhc0ae3ba9e0e9b8b7@mail.gmail.com>
Message-ID: <F5532FCC-44FE-45E0-B4AA-FBB105BBDE2B@math.columbia.edu>

On Dec 18, 2009, at 5:27 AM, Antoine Latter wrote:

> Do you have any more information about this failure? It seems like it
> would be easier to get zlib to work than to replicate cabal-install.

From http://www.reddit.com/r/haskell/comments/afz6n/cabalinstallpy/ :

dcoutts

BTW, the reason you could not get cabal-install working on your OSX 10.6 is because you did not have a fully working GHC installation and zlib (a dep of cabal-install) was the first thing to trip over this.

Since GHC-6.10.4 does not work "out of the box" on OSX 10.6 you followed some hints to modify the ghc wrapper script to pass the gcc flags -m32. The bit you missed is that you need to do the same for hsc2hs. Otherwise hsc2hs generates code that assumes you're targeting the 64bit ABI. That's why the zlib initialisation check fails, because the code calling zlib has been compiled for the wrong size of everything.

Syzygies

Bingo, that sounds right, it's a relief to know what happened.

There's plenty of advice on the web to just modify the ghc script itself for GHC-6.10.4 on OSX 10.6. I knew to modify more scripts, but I missed hsc2hs. I had gotten as far as figuring out that zlib itself was broken, and I had set up some "sandbox" clean development volume images for testing, when I noticed that GHC-6.12.1 was out. And that cabal-install wasn't ready yet.
From mmitar at gmail.com  Fri Dec 18 12:40:48 2009
From: mmitar at gmail.com (Mitar)
Date: Fri Dec 18 12:14:41 2009
Subject: openFd under -threaded gets interrupted
In-Reply-To: <f63c4b2d0912172217q36868026r2a1e6baa5ce45efe@mail.gmail.com>
References: <f63c4b2d0912160618r4f664b8cgf476f4f3fe8cf7c3@mail.gmail.com>
	<f63c4b2d0912172217q36868026r2a1e6baa5ce45efe@mail.gmail.com>
Message-ID: <f63c4b2d0912180940i1d7f2549oe24298e71d1ac151@mail.gmail.com>

Hi!

I have written about this to Haskell cafe and they advised me to write it here.

I have a problem that I cannot open /dev/rfcomm0 device if I compile
my program with -threaded option. Like:

fd <- openFd "/dev/rfcomm0" ReadWrite Nothing OpenFileFlags { append =
False, noctty = True, exclusive = False, nonBlock = True, trunc =
False }

If I compile my program with -threaded option I always get such error:

interrupted (Interrupted system call)

But without -threaded it works flawlessly. I am using Linux 2.6.30
amd64, GHC 6.10.4. It was the same with 6.8. And I have tested it also
on 6.12.1.

After some testing I have discovered that the problem is only with
/dev/rfcomm0 as a device, that is with Bluetooth serial connection.
The problem is that rfcomm Linux kernel code contains:

if (signal_pending(current)) {
? ?err = -EINTR;
? ?break;
}

So if during open call some signal comes it returns EINTR. As it has
to open a connection to a Bluetooth device opening a /dev/rfcomm0 file
requires some time and during that time obviously there is some signal
sent by GHC with -threaded option which is not sent without it.

So please tell me what is the difference between open with and without
-threaded option in GHC as I would like to make a simple C test case.
I am not really sure if this is a feature or a bug in Linux Bluetooth
kernel implementation. But in combination with threaded GHC it makes
not working.

Also is there any workaround possible in Haskell/GHC? For example
making time while openFd is in progress without interrupts?

I have found very similar bug reported here:

https://bugzilla.redhat.com/show_bug.cgi?id=161314

but code from the patch does not seem to be included in official
kernel source code (but it is also a long time ago so many things have
probably changed). But the workaround mentioned there is working also
here. If I open /dev/rfcomm0 with some other program (so that
Bluetooth connection is made) before I run Haskell program then it
works in both cases, with or without -threaded option. Of course this
is not really useful workaround in my case, I would like to make a
stand-alone Haskell program. So if it is similar to that bug then
maybe it is a bug in Linux kernel.

So please help me solve this problem.


Mitar
From duncan.coutts at googlemail.com  Fri Dec 18 12:45:18 2009
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Fri Dec 18 12:19:12 2009
Subject: cabal-install-0.8 final testing
Message-ID: <1261158318.9220.52521.camel@localhost>

All,

If you'd like to help test the new cabal-install-0.8 release then grab
it here:

http://haskell.org/cabal/release/cabal-install-0.8.0/

It should work with ghc-6.10 and 6.12 (and indeed 6.8 and 6.6).

If nobody reports any major show stoppers then I'll upload this to
hackage.

Duncan

From donn at avvanta.com  Fri Dec 18 13:15:31 2009
From: donn at avvanta.com (Donn Cave)
Date: Fri Dec 18 12:49:24 2009
Subject: openFd under -threaded gets interrupted
References: <f63c4b2d0912160618r4f664b8cgf476f4f3fe8cf7c3@mail.gmail.com>
	<f63c4b2d0912172217q36868026r2a1e6baa5ce45efe@mail.gmail.com><f63c4b2d0912180940i1d7f2549oe24298e71d1ac151@mail.gmail.com>
Message-ID: <20091218181531.9A454276C41@mail.avvanta.com>

Quoth Mitar <mmitar@gmail.com>,

> Also is there any workaround possible in Haskell/GHC? For example
> making time while openFd is in progress without interrupts?

You might try something like this:

    import System.Posix.Signals

    ...
        setSignalMask fullSignalSet
        fd <- openFd ...
        setSignalMask emptySignalSet

I'm not in a position to try it in exactly the same situation, but
I see that when I run with all signals blocked as above, after a while
I have a SIGALRM pending (with -threaded or not), so I reckon that might
be the signal used by the runtime thread manager.  If it works, I would
recommend blocking only that signal during the openFd, so for example
you'll be able to abort normally with SIGINT if the device is stuck.

	Donn

From marcus at gabriel.name  Fri Dec 18 13:31:03 2009
From: marcus at gabriel.name (Marcus D. Gabriel)
Date: Fri Dec 18 13:04:56 2009
Subject: parList implementation question
Message-ID: <4B2BCA67.3040903@gabriel.name>

Hello,

In Control.Parallel.Strategies, parList is defined as

    parList strat []     = ()
    parList strat (x:xs) = strat x `par` (parList strat xs)

with

    parMap strat f xs = map f xs `using` parList strat.

I have recently found that if I define

    forceParMap strat f xs = map f xs `using` forceParList strat

where

    forceParList strat = foldl (\done -> (done>||) . strat) ()

then to date, forceParList via forceParMap gives faster results
than parList via parMap.  For example, in one experiment, parMap
with parList run at 0.81 the time of the serial solution whereas
forceParMap with forceParList run at 0.58 the time of the serial
solution.  This is to say, forceParList completed in 0.72 the
time of parList.  So,

1. Why is forceParList faster than parList?
2. Is this generic to the ghc runtime model or a particularity
   of the ghc implementation?

Thanks in advance for the clarification,
- Marcus



From mmitar at gmail.com  Fri Dec 18 16:54:11 2009
From: mmitar at gmail.com (Mitar)
Date: Fri Dec 18 16:28:02 2009
Subject: openFd under -threaded gets interrupted
In-Reply-To: <20091218181531.9A454276C41@mail.avvanta.com>
References: <f63c4b2d0912160618r4f664b8cgf476f4f3fe8cf7c3@mail.gmail.com>
	<f63c4b2d0912172217q36868026r2a1e6baa5ce45efe@mail.gmail.com>
	<f63c4b2d0912180940i1d7f2549oe24298e71d1ac151@mail.gmail.com>
	<20091218181531.9A454276C41@mail.avvanta.com>
Message-ID: <f63c4b2d0912181354h704d7508wb824c843df26cdd@mail.gmail.com>

Hi!

On Fri, Dec 18, 2009 at 7:15 PM, Donn Cave <donn@avvanta.com> wrote:
> ? ? ? ?setSignalMask fullSignalSet
> ? ? ? ?fd <- openFd ...
> ? ? ? ?setSignalMask emptySignalSet

Thanks! This did it. At the end it is enough to block just
virtualTimerExpired signal and it works. Probably it is something RTS
is using internally?


Mitar
From dbueno at gmail.com  Fri Dec 18 19:20:36 2009
From: dbueno at gmail.com (Denis Bueno)
Date: Fri Dec 18 18:54:27 2009
Subject: parList implementation question
In-Reply-To: <4B2BCA67.3040903@gabriel.name>
References: <4B2BCA67.3040903@gabriel.name>
Message-ID: <6dbd4d000912181620y64207179rbe5148a48383015d@mail.gmail.com>

On Fri, Dec 18, 2009 at 11:31, Marcus D. Gabriel <marcus@gabriel.name> wrote:
> than parList via parMap. ?For example, in one experiment, parMap
> with parList run at 0.81 the time of the serial solution whereas
> forceParMap with forceParList run at 0.58 the time of the serial
> solution. ?This is to say, forceParList completed in 0.72 the
> time of parList. ?So,

I don't know your application, so it's hard to interpret your numbers.

Are you sure those measurements are statistically significant?

-- 
                              Denis
From kirill at shutemov.name  Fri Dec 18 21:37:33 2009
From: kirill at shutemov.name (Kirill A. Shutemov)
Date: Fri Dec 18 21:11:23 2009
Subject: GHC-6.12.1: broken configure
Message-ID: <cc557aab0912181837u6829a3edp6d4901794ec80923@mail.gmail.com>

I want to build ghc for i586-alt-linux-gnu.

> ./configure --host=i586-alt-linux-gnu --build=i586-alt-linux-gnu
checking for gfind... no
checking for find... /bin/find
checking for sort... /bin/sort
checking for ghc... /usr/bin/ghc
checking version of ghc... 6.10.1
Target platform inferred as: i386-unknown-linux
Unknown arch i586

Why i586 is unknown? It's a valid architecture.
Why does it check vendor? Many of distribution define own vendor.
Why do not use config.guess to guess correct host/target/build
instead of reinvent wheel?

Please fix it. It will simplify packaging GHC for distributions.
From marcus at gabriel.name  Sat Dec 19 04:26:20 2009
From: marcus at gabriel.name (Marcus D. Gabriel)
Date: Sat Dec 19 04:00:12 2009
Subject: parList implementation question
In-Reply-To: <6dbd4d000912181620y64207179rbe5148a48383015d@mail.gmail.com>
References: <4B2BCA67.3040903@gabriel.name>
	<6dbd4d000912181620y64207179rbe5148a48383015d@mail.gmail.com>
Message-ID: <4B2C9C3C.7090107@gabriel.name>

Denis Bueno wrote:
> On Fri, Dec 18, 2009 at 11:31, Marcus D. Gabriel <marcus@gabriel.name> wrote:
>> than parList via parMap.  For example, in one experiment, parMap
>> with parList run at 0.81 the time of the serial solution whereas
>> forceParMap with forceParList run at 0.58 the time of the serial
>> solution.  This is to say, forceParList completed in 0.72 the
>> time of parList.  So,
>
> I don't know your application, so it's hard to interpret your numbers.
>
> Are you sure those measurements are statistically significant?

The particular example that I gave was a straightforward
searchDepthFirst(1) algorithm. To parallelise it, I choose the
initial, simple approach to determine the first list of successor
nodes from an initial node and use parMap to apply the serial
algorithm searchDepthFirst to this list and then reduce (concat)
the list.

With some RTS tuning and using a dedicated dual-core system, I was
able for the problem above to reproduce the numbers that I cite
above consistently to within about plus or minus a factor of 0.01.

I have played with variations of this class of problem but not
generally compared parList with forceParList across a broader class
of problems.

I like your question above.  It helped me formulate this question:

Is what I observed above significant or random?  I hope it is not
random.

I guess the deeper question is how does one determine with
confidence that

  parallised serial algorithm + startegy1 works for problem class1

and

  parallised serial algorithm + startegy2 works for problem class2


where both are better than the serial case for their respective
class of problems across a given range of operating environments,
e.g., -N2 to -N8 for 2 to 8 cores.

- Marcus

(1) "Algorithms, A Functional Programming Approach" by Fethi Rabhi
and Guy Laplame.  ISBN 0201-59604-0.


From duncan.coutts at googlemail.com  Sat Dec 19 20:46:11 2009
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Sat Dec 19 20:20:03 2009
Subject: cabal-install-0.8 final testing
In-Reply-To: <0C9F4B9F-1F71-45C2-9924-4737D54138D4@math.columbia.edu>
References: <1261158318.9220.52521.camel@localhost>
	<0C9F4B9F-1F71-45C2-9924-4737D54138D4@math.columbia.edu>
Message-ID: <1261273571.9220.60167.camel@localhost>

On Fri, 2009-12-18 at 19:44 -0800, Dave Bayer wrote:
> Hi Duncan,
> 
> Installation was easy (I typed "cabal-install HTTP zlib
> cabal-install" ;-).

Thanks for testing it. I've uploaded it to hackage.

> Overall, seems to work fine. I couldn't build darcs, but I couldn't do
> that by hand either; I used their binary installer. I don't think they
> build yet under GHC 6.12.1.
> 
> One oddity, I tried to use cabal install to install mmap, and it
> failed because the HUnit package was missing. I then installed HUnit
> without incident, went back and installed mmap without incident. No
> idea why this didn't work in one pass, but I have "sandbox" systems if
> you'd like me to see if I can reliably reproduce this.

Mm. This is a worse bug than I thought. It's not trivial to fix. I'll
have to think about it.

The problem is mmap uses:

Executable mmaptest
  Main-is: tests/mmaptest.hs
  if flag(mmaptest)
      Buildable: True
  else
      Buildable: False
  Build-depends: base<5, bytestring, HUnit, directory

Now the question is what does this mean exactly. The previous version of
Cabal said essentially "well the executable needs HUnit thus the package
needs HUnit". This despite the fact that we're not going to actually
built this test executable!

The current Cabal code takes a slightly different approach. It says at
the end "oh this exe isn't buildable, so its deps do not contribute to
the deps of the package".

The problem is what it was doing before that. It sees the dependency on
HUnit and checks that it can be satisfied. It's only at the end that it
ends up discarding it. So if it was not actually available then it fails
earlier.

The reason it's then inconsistent between configuring a package and what
the cabal install planner is doing is that the planner assumes all the
packages on hackage are available (sort of) while when we get to
actually configuring a package to install it, only the other installed
packages are available. So that's why the same solver gives us different
answers, because we're making different assumptions about the available
packages.

So the issue is we need to treat "Buildable: False" specially in the
solver because if we end up picking a configuration with "Buildable:
False" for a component then have to have not already required the
dependencies for that component.

Essentially we want to reinterpret it as something like:

  if flag(test)
      Buildable: True
      Build-depends: base<5, bytestring, HUnit, directory
  else
      Buildable: False

So that the dependencies themselves are conditional on the component
being buildable. Then the solver would do the right thing.

In general I guess the transformation would look like:

  if A1
    Buildable: False
  if A2
    Buildable: False
  ...

  if B1
    Build-depends: blah
  if B2 
    Build-depends: blah

where A1,A2,... and B1,B2,... are arbitrary conditions (including none)

then this becomes:

  if A1
    Buildable: False 
  if A2
    Buildable: False
  ...

  if B1 && ! (A1 || A2 || ...)
    Build-depends: blah 
  if B2 && ! (A1 || A2 || ...) 
    Build-depends: blah
  ...

I don't especially like this though. It makes the meaning of buildable
rather magic. In the short term I may have to revert the change in
behaviour so that these dependencies become unconditional again, even
though they're not used. Sigh.

Duncan

From marcus at gabriel.name  Sun Dec 20 08:17:26 2009
From: marcus at gabriel.name (Marcus D. Gabriel)
Date: Sun Dec 20 07:51:12 2009
Subject: How does forkIO and par interact?
Message-ID: <4B2E23E6.3010008@gabriel.name>

Hello,

How does forkIO (forkOS) and par interact with one another?  Here is
why I ask.

I have a GUI application that has something like this:

    th <- forkIO (guiCode + longRunningPureSerialCode)

Later, a user interaction invokes

    killThread th

and the guiCode plus the longRunningPureSerialCode suspends quite
nicely.  Now I have

    th <- forkIO (guiCode + longRunningPureParallelCode)

Later a user interaction invokes killThread th again but I have
observed under 6.10.4 that not all is suspended.  From what I have
observed, I believe that if

    longRunningPureParallelCode = ... 1stPart `par` 2ndPart ...

the 2ndPart is suspended by killThread th along with the guiCode, and
the 1stPart happily continues calcualting.  (I believe this is correct
but it could be the other way around.)

For my little application, having everything suspend would have been
nice, but that's my app.

So, under ghc, how is forkIO (forkOS) and par supposed to operationally
interact with one another?

Cheers,
- Marcus


From bulat.ziganshin at gmail.com  Sun Dec 20 08:24:05 2009
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Sun Dec 20 07:58:03 2009
Subject: How does forkIO and par interact?
In-Reply-To: <4B2E23E6.3010008@gabriel.name>
References: <4B2E23E6.3010008@gabriel.name>
Message-ID: <18485329.20091220162405@gmail.com>

Hello Marcus,

Sunday, December 20, 2009, 4:17:26 PM, you wrote:

par adds so-called spark to the queue of calculations to proceed. once
RTS has free thread, this thread starts to calculate the spark. it has
no communication with thread that created the spark. when calculation
is completed, its thunk will be updated with result of calculation (as
usual in lazy calculations). so killing originator thread doesn't
affect all the sparks it has created, it only prevents generation of
new sparks


> Hello,

> How does forkIO (forkOS) and par interact with one another?  Here is
> why I ask.

> I have a GUI application that has something like this:

>     th <- forkIO (guiCode + longRunningPureSerialCode)

> Later, a user interaction invokes

>     killThread th

> and the guiCode plus the longRunningPureSerialCode suspends quite
> nicely.  Now I have

>     th <- forkIO (guiCode + longRunningPureParallelCode)

> Later a user interaction invokes killThread th again but I have
> observed under 6.10.4 that not all is suspended.  From what I have
> observed, I believe that if

>     longRunningPureParallelCode = ... 1stPart `par` 2ndPart ...

> the 2ndPart is suspended by killThread th along with the guiCode, and
> the 1stPart happily continues calcualting.  (I believe this is correct
> but it could be the other way around.)

> For my little application, having everything suspend would have been
> nice, but that's my app.

> So, under ghc, how is forkIO (forkOS) and par supposed to operationally
> interact with one another?

> Cheers,
> - Marcus


> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From marcus at gabriel.name  Sun Dec 20 08:57:52 2009
From: marcus at gabriel.name (Marcus D. Gabriel)
Date: Sun Dec 20 08:31:41 2009
Subject: parList implementation question
In-Reply-To: <4B2C9C3C.7090107@gabriel.name>
References: <4B2BCA67.3040903@gabriel.name>	<6dbd4d000912181620y64207179rbe5148a48383015d@mail.gmail.com>
	<4B2C9C3C.7090107@gabriel.name>
Message-ID: <4B2E2D60.1060804@gabriel.name>

Well, I finally put in place 6.12.1 and read the documentation for
Control.Parallel.Strategies.  All of my code for the application described
below uses Done, demanding, sparking, (>|), and (>||) which are deprecated
and which is what I used.  Additionally, I need to understand Eval first
to change my code.

No point in responding until I determine what this means.

Thanks nevertheless,
- Marcus

Marcus D. Gabriel wrote:
> Denis Bueno wrote:
>> On Fri, Dec 18, 2009 at 11:31, Marcus D. Gabriel <marcus@gabriel.name> wrote:
>>> than parList via parMap.  For example, in one experiment, parMap
>>> with parList run at 0.81 the time of the serial solution whereas
>>> forceParMap with forceParList run at 0.58 the time of the serial
>>> solution.  This is to say, forceParList completed in 0.72 the
>>> time of parList.  So,
>> I don't know your application, so it's hard to interpret your numbers.
>>
>> Are you sure those measurements are statistically significant?
>
> The particular example that I gave was a straightforward
> searchDepthFirst(1) algorithm. To parallelise it, I choose the
> initial, simple approach to determine the first list of successor
> nodes from an initial node and use parMap to apply the serial
> algorithm searchDepthFirst to this list and then reduce (concat)
> the list.
>
> With some RTS tuning and using a dedicated dual-core system, I was
> able for the problem above to reproduce the numbers that I cite
> above consistently to within about plus or minus a factor of 0.01.
>
> I have played with variations of this class of problem but not
> generally compared parList with forceParList across a broader class
> of problems.
>
> I like your question above.  It helped me formulate this question:
>
> Is what I observed above significant or random?  I hope it is not
> random.
>
> I guess the deeper question is how does one determine with
> confidence that
>
>   parallised serial algorithm + startegy1 works for problem class1
>
> and
>
>   parallised serial algorithm + startegy2 works for problem class2
>
>
> where both are better than the serial case for their respective
> class of problems across a given range of operating environments,
> e.g., -N2 to -N8 for 2 to 8 cores.
>
> - Marcus
>
> (1) "Algorithms, A Functional Programming Approach" by Fethi Rabhi
> and Guy Laplame.  ISBN 0201-59604-0.
-- 
  Marcus D. Gabriel, Ph.D.                         Saint Louis, FRANCE
  http://www.marcus.gabriel.name            mailto:marcus@gabriel.name
  Tel: +33.3.89.69.05.06                   Portable: +33.6.34.56.07.75


From marcus at gabriel.name  Sun Dec 20 09:12:03 2009
From: marcus at gabriel.name (Marcus D. Gabriel)
Date: Sun Dec 20 08:45:50 2009
Subject: How does forkIO and par interact?
In-Reply-To: <18485329.20091220162405@gmail.com>
References: <4B2E23E6.3010008@gabriel.name> <18485329.20091220162405@gmail.com>
Message-ID: <4B2E30B3.5050509@gabriel.name>

Thanks Bulat.  What you wrote makes perfect sense to me.  However under
6.10.4
this is what I observed.  Pseudo code:

    c = l++r `demanding` l>||r

then

    th <- forkIO (c `seq` return ())

Run it the first time to completion and watch two cores turn at better
than 95% utilisation, quite pleasing.  Run it the second time and half
way through the calculation use

    killThread th

and watch one core become idle and one core turn at better than 95%.
Wait until the first core finishes and then use c and watch the rest
of the calculation finish.

Now, what you wrote and this experiment tells me that l was sparked
and then given a free thread in which to calculate.  r was still in the
original thread of execution of the forkIO and therefore was affected by
the killThread th whereas l was not.

Does this read correct to you?  If so, then I understand!

Thanks,
- Marcus

Bulat Ziganshin wrote:
> Hello Marcus,
>
> Sunday, December 20, 2009, 4:17:26 PM, you wrote:
>
> par adds so-called spark to the queue of calculations to proceed. once
> RTS has free thread, this thread starts to calculate the spark. it has
> no communication with thread that created the spark. when calculation
> is completed, its thunk will be updated with result of calculation (as
> usual in lazy calculations). so killing originator thread doesn't
> affect all the sparks it has created, it only prevents generation of
> new sparks.
-- 
  Marcus D. Gabriel, Ph.D.                         Saint Louis, FRANCE
  http://www.marcus.gabriel.name            mailto:marcus@gabriel.name
  Tel: +33.3.89.69.05.06                   Portable: +33.6.34.56.07.75


From jason.dusek at gmail.com  Sun Dec 20 17:47:30 2009
From: jason.dusek at gmail.com (Jason Dusek)
Date: Sun Dec 20 17:21:15 2009
Subject: Where did the GHC API go?
Message-ID: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>

  Maybe I missed an email about this...

    http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/index.html

  The link is down.

--
Jason Dusek
From korpios at korpios.com  Sun Dec 20 19:17:50 2009
From: korpios at korpios.com (Tom Tobin)
Date: Sun Dec 20 18:51:36 2009
Subject: Where did the GHC API go?
In-Reply-To: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>
Message-ID: <bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>

On Sun, Dec 20, 2009 at 4:47 PM, Jason Dusek <jason.dusek@gmail.com> wrote:
> ?Maybe I missed an email about this...
>
> ? ?http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/index.html
>
> ?The link is down.

The link from the GHC Documentation page points here, which works for me:

http://www.haskell.org/ghc/docs/latest/html/libraries/index.html
From korpios at korpios.com  Sun Dec 20 19:18:24 2009
From: korpios at korpios.com (Tom Tobin)
Date: Sun Dec 20 18:52:09 2009
Subject: Where did the GHC API go?
In-Reply-To: <bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>
	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>
Message-ID: <bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com>

On Sun, Dec 20, 2009 at 6:17 PM, Tom Tobin <korpios@korpios.com> wrote:
> On Sun, Dec 20, 2009 at 4:47 PM, Jason Dusek <jason.dusek@gmail.com> wrote:
>> ?Maybe I missed an email about this...
>>
>> ? ?http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/index.html
>>
>> ?The link is down.
>
> The link from the GHC Documentation page points here, which works for me:
>
> http://www.haskell.org/ghc/docs/latest/html/libraries/index.html

Sorry, read that too quickly ? you're asking about the API.  That is
indeed a dead link for me.
From v.dijk.bas at gmail.com  Mon Dec 21 06:03:32 2009
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Mon Dec 21 05:37:37 2009
Subject: Weird warnings when using ViewPatterns
Message-ID: <f73f66150912210303h59b02656qead5988ccd9e782f@mail.gmail.com>

Hello,

In my usb-safe[1] library I make extensive use of the ViewPatterns[2]
language extension. However I get strange warnings when using them.

See for example the following function:

resetDevice ? (pr `ParentOf` cr, MonadIO cr)
            ? RegionalDeviceHandle pr ? cr ()
resetDevice (internalHandle ? DeviceHandle { internalDevHndl
                                           , configAlreadySetMVar
                                           }) = ...

where:

type RegionalDeviceHandle r = RegionalHandle USB.Device r

internalHandle ? RegionalHandle resource r ? Handle resource

and: 'Handle' is an associated data type with the following definition:

data Handle USB.Device = DeviceHandle
    { internalDevHndl ? USB.DeviceHandle
    , configAlreadySetMVar ? MVar Bool
    }

Note that I also use the NamedFieldPuns[3] language extension.

When compiling the module I get lots of warnings like this:

System/USB/Safe.hs:372:0:
    Warning: Pattern match(es) are overlapped
             In the definition of `resetDevice':
                 resetDevice ((internalHandle -> (DeviceHandle {internalDevHndl,

configAlreadySetMVar})))
                             =
                             ...

System/USB/Safe.hs:372:0:
    Warning: Pattern match(es) are non-exhaustive
             In the definition of `resetDevice': Patterns not matched:

I don't understand which patterns are overlapped or which patterns are
not matched. Is this a GHC bug? Note that I'm using ghc-6.10.4 so it's
possible that it's fixed in 6.12.1.

regards,

Bas

[1] usb-safe:
http://hackage.haskell.org/package/usb-safe-0.4
or darcs get http://code.haskell.org/~basvandijk/code/usb-safe

[2] http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#view-patterns

[3] http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#record-puns
From gracjanpolak at gmail.com  Mon Dec 21 06:34:02 2009
From: gracjanpolak at gmail.com (Gracjan Polak)
Date: Mon Dec 21 06:13:54 2009
Subject: cabal-install-0.8 final testing
References: <1261158318.9220.52521.camel@localhost>
	<0C9F4B9F-1F71-45C2-9924-4737D54138D4@math.columbia.edu>
	<1261273571.9220.60167.camel@localhost>
Message-ID: <loom.20091221T123130-351@post.gmane.org>

Duncan Coutts <duncan.coutts <at> googlemail.com> writes:

>   if flag(test)
>       Buildable: True
>       Build-depends: base<5, bytestring, HUnit, directory
>   else
>       Buildable: False
> 

Is this solution good for the time being? If so, I'll change it to make peace
and happiness prevail among cabal users.

Side question: mmaptest is meant to be devel/testing thing only that is not
build during normal usage. Is there a better way to achieve such purpose?

-- 
Gracjan


From marlowsd at gmail.com  Mon Dec 21 07:23:07 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon Dec 21 06:57:20 2009
Subject: openFd under -threaded gets interrupted
In-Reply-To: <f63c4b2d0912180940i1d7f2549oe24298e71d1ac151@mail.gmail.com>
References: <f63c4b2d0912160618r4f664b8cgf476f4f3fe8cf7c3@mail.gmail.com>	<f63c4b2d0912172217q36868026r2a1e6baa5ce45efe@mail.gmail.com>
	<f63c4b2d0912180940i1d7f2549oe24298e71d1ac151@mail.gmail.com>
Message-ID: <4B2F68AB.9080208@gmail.com>

On 18/12/2009 17:40, Mitar wrote:
> Hi!
>
> I have written about this to Haskell cafe and they advised me to write it here.
>
> I have a problem that I cannot open /dev/rfcomm0 device if I compile
> my program with -threaded option. Like:
>
> fd<- openFd "/dev/rfcomm0" ReadWrite Nothing OpenFileFlags { append =
> False, noctty = True, exclusive = False, nonBlock = True, trunc =
> False }
>
> If I compile my program with -threaded option I always get such error:
>
> interrupted (Interrupted system call)
>
> But without -threaded it works flawlessly. I am using Linux 2.6.30
> amd64, GHC 6.10.4. It was the same with 6.8. And I have tested it also
> on 6.12.1.

It's a bug - openFd should be checking for EINTR.  I'll fix it.

Cheers,
	Simon
From marlowsd at gmail.com  Mon Dec 21 07:28:06 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon Dec 21 07:02:13 2009
Subject: parList implementation question
In-Reply-To: <4B2BCA67.3040903@gabriel.name>
References: <4B2BCA67.3040903@gabriel.name>
Message-ID: <4B2F69D6.10402@gmail.com>

On 18/12/2009 18:31, Marcus D. Gabriel wrote:
> Hello,
>
> In Control.Parallel.Strategies, parList is defined as
>
>      parList strat []     = ()
>      parList strat (x:xs) = strat x `par` (parList strat xs)
>
> with
>
>      parMap strat f xs = map f xs `using` parList strat.
>
> I have recently found that if I define
>
>      forceParMap strat f xs = map f xs `using` forceParList strat
>
> where
>
>      forceParList strat = foldl (\done ->  (done>||) . strat) ()
>
> then to date, forceParList via forceParMap gives faster results
> than parList via parMap.  For example, in one experiment, parMap
> with parList run at 0.81 the time of the serial solution whereas
> forceParMap with forceParList run at 0.58 the time of the serial
> solution.  This is to say, forceParList completed in 0.72 the
> time of parList.  So,
>
> 1. Why is forceParList faster than parList?
> 2. Is this generic to the ghc runtime model or a particularity
>     of the ghc implementation?

I'm not sure.  Your forceParList looks equivalent to parList, unless I'm 
misreading it.

I recommend trying out the new parallel package, here:

   http://hackage.haskell.org/package/parallel

which has a new implementation of Strategies.  The version of parList 
you quoted above has a space leak problem which may be affecting your 
results.

Cheers,
	Simon
From marlowsd at gmail.com  Mon Dec 21 07:34:06 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon Dec 21 07:08:06 2009
Subject: How does forkIO and par interact?
In-Reply-To: <4B2E30B3.5050509@gabriel.name>
References: <4B2E23E6.3010008@gabriel.name> <18485329.20091220162405@gmail.com>
	<4B2E30B3.5050509@gabriel.name>
Message-ID: <4B2F6B3E.9090205@gmail.com>

On 20/12/2009 14:12, Marcus D. Gabriel wrote:
> Thanks Bulat.  What you wrote makes perfect sense to me.  However under
> 6.10.4
> this is what I observed.  Pseudo code:
>
>      c = l++r `demanding` l>||r
>
> then
>
>      th<- forkIO (c `seq` return ())
>
> Run it the first time to completion and watch two cores turn at better
> than 95% utilisation, quite pleasing.  Run it the second time and half
> way through the calculation use
>
>      killThread th
>
> and watch one core become idle and one core turn at better than 95%.
> Wait until the first core finishes and then use c and watch the rest
> of the calculation finish.
>
> Now, what you wrote and this experiment tells me that l was sparked
> and then given a free thread in which to calculate.  r was still in the
> original thread of execution of the forkIO and therefore was affected by
> the killThread th whereas l was not.
>
> Does this read correct to you?  If so, then I understand!

That's exactly right, yes.

In principle we could have spark threads be garbage collected if their 
results aren't shared by the main program.  In practice that's hard to 
determine, since sharing is not an all-or-nothing question.  There's a 
fruitful line of research here, though, since it affects how well you 
can express speculation.

Cheers,
	Simon
From marlowsd at gmail.com  Mon Dec 21 07:38:08 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon Dec 21 07:12:11 2009
Subject: Where did the GHC API go?
In-Reply-To: <bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>
	<bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com>
Message-ID: <4B2F6C30.3080705@gmail.com>

On 21/12/2009 00:18, Tom Tobin wrote:
> On Sun, Dec 20, 2009 at 6:17 PM, Tom Tobin<korpios@korpios.com>  wrote:
>> On Sun, Dec 20, 2009 at 4:47 PM, Jason Dusek<jason.dusek@gmail.com>  wrote:
>>>   Maybe I missed an email about this...
>>>
>>>     http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/index.html
>>>
>>>   The link is down.
>>
>> The link from the GHC Documentation page points here, which works for me:
>>
>> http://www.haskell.org/ghc/docs/latest/html/libraries/index.html
>
> Sorry, read that too quickly ? you're asking about the API.  That is
> indeed a dead link for me.

Ian, is this something to do with the recent redirects that were added?

Cheers,
	Simon
From marlowsd at gmail.com  Mon Dec 21 07:44:26 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon Dec 21 07:18:28 2009
Subject: cabal-install-0.8 final testing
In-Reply-To: <1261273571.9220.60167.camel@localhost>
References: <1261158318.9220.52521.camel@localhost>	<0C9F4B9F-1F71-45C2-9924-4737D54138D4@math.columbia.edu>
	<1261273571.9220.60167.camel@localhost>
Message-ID: <4B2F6DAA.10104@gmail.com>

On 20/12/2009 01:46, Duncan Coutts wrote:
> On Fri, 2009-12-18 at 19:44 -0800, Dave Bayer wrote:
>> Hi Duncan,
>>
>> Installation was easy (I typed "cabal-install HTTP zlib
>> cabal-install" ;-).
>
> Thanks for testing it. I've uploaded it to hackage.
>
>> Overall, seems to work fine. I couldn't build darcs, but I couldn't do
>> that by hand either; I used their binary installer. I don't think they
>> build yet under GHC 6.12.1.
>>
>> One oddity, I tried to use cabal install to install mmap, and it
>> failed because the HUnit package was missing. I then installed HUnit
>> without incident, went back and installed mmap without incident. No
>> idea why this didn't work in one pass, but I have "sandbox" systems if
>> you'd like me to see if I can reliably reproduce this.
>
> Mm. This is a worse bug than I thought. It's not trivial to fix. I'll
> have to think about it.
>
> The problem is mmap uses:
>
> Executable mmaptest
>    Main-is: tests/mmaptest.hs
>    if flag(mmaptest)
>        Buildable: True
>    else
>        Buildable: False
>    Build-depends: base<5, bytestring, HUnit, directory
>
> Now the question is what does this mean exactly. The previous version of
> Cabal said essentially "well the executable needs HUnit thus the package
> needs HUnit". This despite the fact that we're not going to actually
> built this test executable!
>
> The current Cabal code takes a slightly different approach. It says at
> the end "oh this exe isn't buildable, so its deps do not contribute to
> the deps of the package".
>
> The problem is what it was doing before that. It sees the dependency on
> HUnit and checks that it can be satisfied. It's only at the end that it
> ends up discarding it. So if it was not actually available then it fails
> earlier.

I was following the description up until this paragraph (too many "it"s 
and "that"s, I'm not sure what they all refer to). Don't worry about it 
if it's hard to explain, but if you have time to elaborate a bit I'd be 
interested.

Cheers,
	Simon
From duncan.coutts at googlemail.com  Mon Dec 21 09:47:02 2009
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Mon Dec 21 09:20:48 2009
Subject: cabal-install-0.8 final testing
In-Reply-To: <4B2F6DAA.10104@gmail.com>
References: <1261158318.9220.52521.camel@localhost>
	<0C9F4B9F-1F71-45C2-9924-4737D54138D4@math.columbia.edu>
	<1261273571.9220.60167.camel@localhost>  <4B2F6DAA.10104@gmail.com>
Message-ID: <1261406822.9220.69096.camel@localhost>

On Mon, 2009-12-21 at 12:44 +0000, Simon Marlow wrote:

> > The current Cabal code takes a slightly different approach. It says at
> > the end "oh this exe isn't buildable, so its deps do not contribute to
> > the deps of the package".
> >
> > The problem is what it was doing before that. It sees the dependency on
> > HUnit and checks that it can be satisfied. It's only at the end that it
> > ends up discarding it. So if it was not actually available then it fails
> > earlier.
> 
> I was following the description up until this paragraph (too many "it"s 
> and "that"s, I'm not sure what they all refer to). Don't worry about it 
> if it's hard to explain, but if you have time to elaborate a bit I'd be 
> interested.

Sorry, I'll try again:

There are essentially two stages to the resolution. The main one and a
simple post-processing. The post-processing notes that some components
are not buildable and so ignores the deps from those components.

But that's not good enough because the first stage would already have
failed if those dependencies of the non-buildable component were not
available. So it's no good just doing it as a post-processing stage. We
must properly express the fact that the dependencies are optional and
related to whether or not the component is buildable.

The solver currently does not know that "buildable" is special in any
way. Indeed that it should be special is rather irksome. We had this
field before we added conditionals. We would not have added "buildable"
like this way after adding conditionals. Instead we should have added
things with comprehensible semantics like "fail".

Duncan

From marcus at gabriel.name  Mon Dec 21 11:43:43 2009
From: marcus at gabriel.name (Marcus D. Gabriel)
Date: Mon Dec 21 11:17:27 2009
Subject: parList implementation question
In-Reply-To: <4B2F69D6.10402@gmail.com>
References: <4B2BCA67.3040903@gabriel.name> <4B2F69D6.10402@gmail.com>
Message-ID: <4B2FA5BF.9000309@gabriel.name>

Thank you Simon, I will obtain parallel 2.2.0.1 and work with it.
Actually, the reason I asked my question was because I did not
think forceParList should yield better performance than parList
(unless it was becasue of the foldl?).

I read the release notes for 6.12.1 about the work done on the ghc
parallel framework and did just a little bit more experimenting.
You might find this of interesting.

ghc 6.10.4 with parallel 1.1.0.1 (as reported before):
    Serial algorithm:                        1.00 unit of time
    Parallel algorithm with parList:         0.81 units of time
    Parallel algorithm with forceParList:    0.58 units of time

ghc 6.12.1 with parallel 1.1.0.1:
    Serial algorithm:                        1.00 unit of time
    Parallel algorithm with parList:         0.58 units of time*
    Parallel algorithm with forceParList:    0.58 units of time*

Interesting.  Well, from my perspective, 6.12.1 is certainly an
improvement here.

Cheers,
- Marcus
 
Simon Marlow wrote:
>
> On 18/12/2009 18:31, Marcus D. Gabriel wrote:
>> Hello,
>>
>> In Control.Parallel.Strategies, parList is defined as
>>
>>      parList strat []     = ()
>>      parList strat (x:xs) = strat x `par` (parList strat xs)
>>
>> with
>>
>>      parMap strat f xs = map f xs `using` parList strat.
>>
>> I have recently found that if I define
>>
>>      forceParMap strat f xs = map f xs `using` forceParList strat
>>
>> where
>>
>>      forceParList strat = foldl (\done ->  (done>||) . strat) ()
>>
>> then to date, forceParList via forceParMap gives faster results
>> than parList via parMap.  For example, in one experiment, parMap
>> with parList run at 0.81 the time of the serial solution whereas
>> forceParMap with forceParList run at 0.58 the time of the serial
>> solution.  This is to say, forceParList completed in 0.72 the
>> time of parList.  So,
>>
>> 1. Why is forceParList faster than parList?
>> 2. Is this generic to the ghc runtime model or a particularity
>>     of the ghc implementation?
>
> I'm not sure.  Your forceParList looks equivalent to parList, unless
> I'm misreading it.
>
> I recommend trying out the new parallel package, here:
>
>   http://hackage.haskell.org/package/parallel
>
> which has a new implementation of Strategies.  The version of parList
> you quoted above has a space leak problem which may be affecting your
> results.
>
> Cheers,
>     Simon

From marcus at gabriel.name  Mon Dec 21 13:01:18 2009
From: marcus at gabriel.name (Marcus D. Gabriel)
Date: Mon Dec 21 12:35:08 2009
Subject: parList implementation question
In-Reply-To: <4B2FA5BF.9000309@gabriel.name>
References: <4B2BCA67.3040903@gabriel.name> <4B2F69D6.10402@gmail.com>
	<4B2FA5BF.9000309@gabriel.name>
Message-ID: <4B2FB7EE.2010202@gabriel.name>

Thanks Simon.  Parallel 2.2.0.1 was straight forward.  I just replaced rnf
with rdeepseq and my original use of parMap worked like a charm giving
twice the performance for my dual-core system as I original expected and
now find.

Thanks,
- Marcus

Marcus D. Gabriel wrote:
> Thank you Simon, I will obtain parallel 2.2.0.1 and work with it.
> Actually, the reason I asked my question was because I did not
> think forceParList should yield better performance than parList
> (unless it was becasue of the foldl?).
>
> I read the release notes for 6.12.1 about the work done on the ghc
> parallel framework and did just a little bit more experimenting.
> You might find this of interesting.
>
> ghc 6.10.4 with parallel 1.1.0.1 (as reported before):
>     Serial algorithm:                        1.00 unit of time
>     Parallel algorithm with parList:         0.81 units of time
>     Parallel algorithm with forceParList:    0.58 units of time
>
> ghc 6.12.1 with parallel 1.1.0.1:
>     Serial algorithm:                        1.00 unit of time
>     Parallel algorithm with parList:         0.58 units of time*
>     Parallel algorithm with forceParList:    0.58 units of time*
>
> Interesting.  Well, from my perspective, 6.12.1 is certainly an
> improvement here.
>
> Cheers,
> - Marcus
>  
> Simon Marlow wrote:
>   
>> On 18/12/2009 18:31, Marcus D. Gabriel wrote:
>>     
>>> Hello,
>>>
>>> In Control.Parallel.Strategies, parList is defined as
>>>
>>>      parList strat []     = ()
>>>      parList strat (x:xs) = strat x `par` (parList strat xs)
>>>
>>> with
>>>
>>>      parMap strat f xs = map f xs `using` parList strat.
>>>
>>> I have recently found that if I define
>>>
>>>      forceParMap strat f xs = map f xs `using` forceParList strat
>>>
>>> where
>>>
>>>      forceParList strat = foldl (\done ->  (done>||) . strat) ()
>>>
>>> then to date, forceParList via forceParMap gives faster results
>>> than parList via parMap.  For example, in one experiment, parMap
>>> with parList run at 0.81 the time of the serial solution whereas
>>> forceParMap with forceParList run at 0.58 the time of the serial
>>> solution.  This is to say, forceParList completed in 0.72 the
>>> time of parList.  So,
>>>
>>> 1. Why is forceParList faster than parList?
>>> 2. Is this generic to the ghc runtime model or a particularity
>>>     of the ghc implementation?
>>>       
>> I'm not sure.  Your forceParList looks equivalent to parList, unless
>> I'm misreading it.
>>
>> I recommend trying out the new parallel package, here:
>>
>>   http://hackage.haskell.org/package/parallel
>>
>> which has a new implementation of Strategies.  The version of parList
>> you quoted above has a space leak problem which may be affecting your
>> results.
>>
>> Cheers,
>>     Simon
>>     

From dons at galois.com  Mon Dec 21 14:19:42 2009
From: dons at galois.com (Don Stewart)
Date: Mon Dec 21 13:53:33 2009
Subject: Haskell @ USENIX HotPar?
Message-ID: <20091221191942.GE9499@whirlpool.galois.com>

Hey Haskellers,

Looks like a great opportunity to talk about parallel Haskell to other
communities:

    Second USENIX Workshop on Hot Topics in Parallelism

    http://gpgpu.org/2009/12/20/cfp-hotpar-2010

    Following the tremendous success of HotPar ?09, the Second USENIX
    Workshop on Hot Topics in Parallelism (HotPar ?10) will once again bring
    together researchers and practitioners doing innovative work in the area
    of parallel computing. 

Anyone planning on submitting a position paper?

It would be a real shame not to show our faces.

-- Don
From bulat.ziganshin at gmail.com  Mon Dec 21 14:32:47 2009
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Mon Dec 21 14:15:35 2009
Subject: x64 linux, x86 program and libgmp shared library
Message-ID: <1272007829.20091221223247@gmail.com>

Hello glasgow-haskell-users,

i compile my program for linux using ghc 6.6.1 (32-bit)

user of my program asks: "any plans of making a static build for
linux? that one does not work under x86-64 due to dependencies,
missing libgmp which it seems is not available under 64bit. i could be
wrong tho."

how this may be resolved? should libgmp be available in x64 linux, or
i should change compile options?

-- 
Best regards,
 Bulat                          mailto:Bulat.Ziganshin@gmail.com

From robgreayer at gmail.com  Mon Dec 21 14:49:49 2009
From: robgreayer at gmail.com (Robert Greayer)
Date: Mon Dec 21 14:23:32 2009
Subject: x64 linux, x86 program and libgmp shared library
In-Reply-To: <1272007829.20091221223247@gmail.com>
References: <1272007829.20091221223247@gmail.com>
Message-ID: <4ec472cb0912211149p3f45490cjf69b90dcd9beaa9c@mail.gmail.com>

On Mon, Dec 21, 2009 at 2:32 PM, Bulat Ziganshin
<bulat.ziganshin@gmail.com>wrote:

> Hello glasgow-haskell-users,
>
> i compile my program for linux using ghc 6.6.1 (32-bit)
>
> user of my program asks: "any plans of making a static build for
> linux? that one does not work under x86-64 due to dependencies,
> missing libgmp which it seems is not available under 64bit. i could be
> wrong tho."
>
> how this may be resolved? should libgmp be available in x64 linux, or
> i should change compile options?
>
>
Using cabal, this gets me a completely static executable:

runhaskell Setup.hs configure --user --ghc-options="-static -optl-static
-optl-pthread"

Which implies to me that passing '-static -optl-static -optl-pthread' would
do the trick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091221/1b40b131/attachment.html
From robgreayer at gmail.com  Mon Dec 21 14:50:50 2009
From: robgreayer at gmail.com (Robert Greayer)
Date: Mon Dec 21 14:24:33 2009
Subject: x64 linux, x86 program and libgmp shared library
In-Reply-To: <4ec472cb0912211149p3f45490cjf69b90dcd9beaa9c@mail.gmail.com>
References: <1272007829.20091221223247@gmail.com>
	<4ec472cb0912211149p3f45490cjf69b90dcd9beaa9c@mail.gmail.com>
Message-ID: <4ec472cb0912211150t19b47738n270262888f434004@mail.gmail.com>

On Mon, Dec 21, 2009 at 2:49 PM, Robert Greayer <robgreayer@gmail.com>wrote:

>
> On Mon, Dec 21, 2009 at 2:32 PM, Bulat Ziganshin <
> bulat.ziganshin@gmail.com> wrote:
>
>> Hello glasgow-haskell-users,
>>
>> i compile my program for linux using ghc 6.6.1 (32-bit)
>>
>> user of my program asks: "any plans of making a static build for
>> linux? that one does not work under x86-64 due to dependencies,
>> missing libgmp which it seems is not available under 64bit. i could be
>> wrong tho."
>>
>> how this may be resolved? should libgmp be available in x64 linux, or
>> i should change compile options?
>>
>>
> Using cabal, this gets me a completely static executable:
>
> runhaskell Setup.hs configure --user --ghc-options="-static -optl-static
> -optl-pthread"
>
> Which implies to me that passing '-static -optl-static -optl-pthread' would
> do the trick.
>

(With the caveat: this works with 6.10... not sure at all about 6.6).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091221/8250a3f3/attachment.html
From robgreayer at gmail.com  Mon Dec 21 15:03:55 2009
From: robgreayer at gmail.com (Robert Greayer)
Date: Mon Dec 21 14:37:41 2009
Subject: Weird warnings when using ViewPatterns
In-Reply-To: <f73f66150912210303h59b02656qead5988ccd9e782f@mail.gmail.com>
References: <f73f66150912210303h59b02656qead5988ccd9e782f@mail.gmail.com>
Message-ID: <4ec472cb0912211203i6c0728f6t16f153dac2a4a14d@mail.gmail.com>

On Mon, Dec 21, 2009 at 6:03 AM, Bas van Dijk <v.dijk.bas@gmail.com> wrote:

> Hello,
>
> In my usb-safe[1] library I make extensive use of the ViewPatterns[2]
> language extension. However I get strange warnings when using them.
>
> See for example the following function:
>
> resetDevice ? (pr `ParentOf` cr, MonadIO cr)
>            ? RegionalDeviceHandle pr ? cr ()
> resetDevice (internalHandle ? DeviceHandle { internalDevHndl
>                                           , configAlreadySetMVar
>                                           }) = ...
>
> where:
>
> type RegionalDeviceHandle r = RegionalHandle USB.Device r
>
> internalHandle ? RegionalHandle resource r ? Handle resource
>
> and: 'Handle' is an associated data type with the following definition:
>
> data Handle USB.Device = DeviceHandle
>    { internalDevHndl ? USB.DeviceHandle
>    , configAlreadySetMVar ? MVar Bool
>    }
>
> Note that I also use the NamedFieldPuns[3] language extension.
>
> When compiling the module I get lots of warnings like this:
>
> System/USB/Safe.hs:372:0:
>    Warning: Pattern match(es) are overlapped
>             In the definition of `resetDevice':
>                 resetDevice ((internalHandle -> (DeviceHandle
> {internalDevHndl,
>
> configAlreadySetMVar})))
>                             =
>                             ...
>
> System/USB/Safe.hs:372:0:
>    Warning: Pattern match(es) are non-exhaustive
>             In the definition of `resetDevice': Patterns not matched:
>
> I don't understand which patterns are overlapped or which patterns are
> not matched. Is this a GHC bug? Note that I'm using ghc-6.10.4 so it's
> possible that it's fixed in 6.12.1.
>
> regards,
>
> Bas
>
> [1] usb-safe:
> http://hackage.haskell.org/package/usb-safe-0.4
> or darcs get http://code.haskell.org/~basvandijk/code/usb-safe<http://code.haskell.org/%7Ebasvandijk/code/usb-safe>
>
> [2]
> http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#view-patterns
>
> [3]
> http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#record-puns
>

There's been some improvement at least in 6.12.1, see:

http://hackage.haskell.org/trac/ghc/ticket/2395
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091221/5a8e83a8/attachment.html
From v.dijk.bas at gmail.com  Mon Dec 21 16:17:23 2009
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Mon Dec 21 15:51:26 2009
Subject: Weird warnings when using ViewPatterns
In-Reply-To: <4ec472cb0912211203i6c0728f6t16f153dac2a4a14d@mail.gmail.com>
References: <f73f66150912210303h59b02656qead5988ccd9e782f@mail.gmail.com> 
	<4ec472cb0912211203i6c0728f6t16f153dac2a4a14d@mail.gmail.com>
Message-ID: <f73f66150912211317j288f39bek38551e1301a3d62e@mail.gmail.com>

On Mon, Dec 21, 2009 at 9:03 PM, Robert Greayer <robgreayer@gmail.com> wrote:
> There's been some improvement at least in 6.12.1, see:
> http://hackage.haskell.org/trac/ghc/ticket/2395

Thanks for pointing me to the ticket!

I'm emerging ghc-6.12.1 right now to try it out (I'm on Gentoo Linux).

regards,

Bas
From aslatter at gmail.com  Mon Dec 21 22:33:05 2009
From: aslatter at gmail.com (Antoine Latter)
Date: Mon Dec 21 22:06:48 2009
Subject: ANN: Happstack 0.4.1
In-Reply-To: <54342.1261377119@n-heptane.com>
References: <54342.1261377119@n-heptane.com>
Message-ID: <694519c50912211933p257746abgca00c46a443264ac@mail.gmail.com>

On Mon, Dec 21, 2009 at 6:31 AM,  <jeremy@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}
<<<<<

That was the successful build, using ghc --make. The error for te
failing build is quoted bellow.

Antoine

>
>
>
> On Sun 12/20/2009 2:06 AM , Antoine Latter aslatter@gmail.com sent:
>
> 2009/12/19 Jeremy Shaw <jeremy@n-heptane.com>:
>> Happstack 0.4.1 STABLE is now available.
>
> At some point I was able to get happstack to build on GHC 6.12, but now I
> can't.
>
> I'm getting errors in happstack-data, specifically it looks like
> errors when I'm running TemplateHaskell during compile-time:
>
>>>>>>
> [ 7 of 16] Compiling Happstack.Data.Xml.Base (
> src/Happstack/Data/Xml/Base.hs, dist/build/Happstack/Data/Xml/Base.o )
> Loading package ghc-prim ... linking ... done.
> Loading package integer-gmp ... linking ... done.
> Loading package base ... 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 template-haskell ... linking ... done.
> Loading package syb-with-class-0.6.1 ... linking ... done.
> Loading package HUnit-1.2.2.1 ... linking ... done.
> Loading package syb-0.1.0.2 ... linking ... done.
> Loading package base-3.0.3.2 ... linking ... done.
> Loading package old-locale-1.0.0.2 ... linking ... done.
> Loading package time-1.1.4 ... linking ... done.
> Loading package random-1.0.0.2 ... linking ... done.
> Loading package QuickCheck-1.2.0.0 ... linking ... done.
> Loading package extensible-exceptions-0.1.1.1 ... linking ... done.
> Loading package mtl-1.1.0.2 ... linking ... done.
> Loading package old-time-1.0.0.3 ... linking ... done.
> Loading package parsec-2.1.0.1 ... linking ... done.
> Loading package hsemail-1.3 ... linking ... done.
> Loading package network-2.2.1.5 ... linking ... done.
> Loading package SMTPClient-1.0.1 ... linking ... done.
> Loading package filepath-1.1.0.3 ... linking ... done.
> Loading package unix-2.4.0.0 ... linking ... done.
> Loading package directory-1.0.1.0 ... linking ... done.
> Loading package process-1.0.1.2 ... linking ... done.
> Loading package hslogger-1.0.7 ... linking ... done.
> Loading package deepseq-1.1.0.0 ... linking ... done.
> Loading package parallel-2.2.0.1 ... linking ... done.
> Loading package strict-concurrency-0.2.2 ... linking ... done.
> Loading package unix-compat-0.1.2.1 ... linking ... done.
> Loading package happstack-util-0.4.1 ... linking ... done.
> Loading package binary-0.5.0.2 ... linking ... done.
> Loading package haskell98 ... linking ... done.
> Loading package HaXml-1.13.3 ... linking ... done.
> Loading package ffi-1.0 ... linking ... done.
> ghc:
> unknown symbol
> `_sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
> <<<<<
>
> If you check the load-list, we are loading syb-with-class.
>
> This is on Mac OS X 10.6 on a 64-bit intel chip, if that makes any
> difference.
>
> Has anyone seen anything like this? Is it likely I've screwed up my
> GHC install somehow?
>
> Antoine
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "HAppS" group.
> To post to this group, send email to happs@googlegroups.com.
> To unsubscribe from this group, send email to
> happs+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/happs?hl=en.
>
>
>
>
From duncan.coutts at googlemail.com  Tue Dec 22 02:20:48 2009
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Tue Dec 22 01:54:31 2009
Subject: Static linking and linker search paths
Message-ID: <1261466448.9220.74126.camel@localhost>

All,

Conor's problems on OSX with libiconv reminds me of something I've been
thinking about for a little while.

So the problem is that the semantics of static linking does not at all
match what we really want. We can easily accidentally "interpose" a
wrong library in place of the one we wanted.

In the iconv case people have hit recently we've got this situation:

libHSbase-4.2.0.0.a
contains references to _iconv_open, _iconv, _iconv_close

${system}/libiconv.a

${macports}/libiconv.a

When the code for libHSbase was built, it was against the header files
for the standard system version of iconv on OSX. Thus it is intended
that we link against the system version of iconv.

No suppose by default that the system is set up such that only the
system iconv is found by default. So I am assuming there is no
LD_LIBRARY_PATH or similar set. Then when we link something then we
correctly resolve the references in base to the system iconv lib.

When we call gcc to link we're doing something like:

-L${ghclibdir} -lHSbase-4.2.0.0.a -liconv

Now suppose we build some FFI package (libHSfoo-1.0.a) that provides a
binding to a C lib installed via macports (libfoo.a). When we link a
program that depends indirectly on this FFI package then the gcc linker
line is like:

-L${ghclibdir} -L/opt/local/lib
-lHSfoo-1.0.a -lfoo -lHSbase-4.2.0.0.a -liconv

and now it all breaks.

We're asking the linker to look in /opt/local/lib first for *all the
remaining libraries* and that includes iconv, so we pick up the wrong
iconv. Our intention was just to look for -lfoo using /opt/local/lib,
but we cannot express that to the linker.

The problem is that our notion of library dependencies is hierarchical
but for the system linker it is linear. We know that package foo-1.0
needs the C library libfoo.a and that it should be found by looking
in /opt/local/lib. But we end up asking the linker to look there first
for all other libs too, including for the -liconv needed by the base
package. The registration for the base package never
mentioned /opt/local/lib of course.

What we'd really like to say is something like:

link HSfoo-1.0.a
push search path /opt/local/lib
link foo
pop search path

If we think we know enough about the behaviour of the system linker and
its search path then we could do just:

-L${ghclibdir}
-lHSfoo-1.0.a /opt/local/lib/libfoo.a -lHSbase-4.2.0.0.a -liconv

that is, specify the .a file exactly by fully resolved path and not add
anything to the linker search path. (Actually we'd do it for the
libHS*.a ones too since we know precisely where they live)

The possible danger is that how we search for the library and how the
system linker searches for it might not match exactly and we could end
up sowing confusion.

Worth thinking about anyway.

Note that some of this is different for shared libs.

Duncan

From duncan.coutts at googlemail.com  Tue Dec 22 03:21:06 2009
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Tue Dec 22 02:54:52 2009
Subject: cabal-install-0.8 final testing
In-Reply-To: <loom.20091221T123130-351@post.gmane.org>
References: <1261158318.9220.52521.camel@localhost>
	<0C9F4B9F-1F71-45C2-9924-4737D54138D4@math.columbia.edu>
	<1261273571.9220.60167.camel@localhost>
	<loom.20091221T123130-351@post.gmane.org>
Message-ID: <1261470066.9220.74405.camel@localhost>

On Mon, 2009-12-21 at 11:34 +0000, Gracjan Polak wrote:
> Duncan Coutts <duncan.coutts <at> googlemail.com> writes:
> 
> >   if flag(test)
> >       Buildable: True
> >       Build-depends: base<5, bytestring, HUnit, directory
> >   else
> >       Buildable: False
> > 
> 
> Is this solution good for the time being? If so, I'll change it to make peace
> and happiness prevail among cabal users.

I suggest you don't change anything until we decide what the semantics
are supposed to be in this case.

> Side question: mmaptest is meant to be devel/testing thing only that is not
> build during normal usage. Is there a better way to achieve such purpose?

Not something purpose designed at the moment.

Duncan

From Christian.Maeder at dfki.de  Tue Dec 22 04:50:30 2009
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Tue Dec 22 04:24:14 2009
Subject: x64 linux, x86 program and libgmp shared library
In-Reply-To: <1272007829.20091221223247@gmail.com>
References: <1272007829.20091221223247@gmail.com>
Message-ID: <4B309666.6090508@dfki.de>

I think, libgmp.so* should be available under /usr/lib64/ if you use ghc.

There are rpm packages, i.e. SuSE
  gmp-4.2.1-58
  gmp-devel-4.2.1-58

In order to create binaries with libgmp being statically linked in, it
is possible to copy libgmp.a into ghc'c libdir so that those binaries
can run on systems with libgmp.so.

HTH Christian

Bulat Ziganshin schrieb:
> Hello glasgow-haskell-users,
> 
> i compile my program for linux using ghc 6.6.1 (32-bit)
> 
> user of my program asks: "any plans of making a static build for
> linux? that one does not work under x86-64 due to dependencies,
> missing libgmp which it seems is not available under 64bit. i could be
> wrong tho."
> 
> how this may be resolved? should libgmp be available in x64 linux, or
> i should change compile options?
> 
From Christian.Maeder at dfki.de  Tue Dec 22 05:09:10 2009
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Tue Dec 22 04:42:52 2009
Subject: x64 linux, x86 program and libgmp shared library
In-Reply-To: <4B309666.6090508@dfki.de>
References: <1272007829.20091221223247@gmail.com> <4B309666.6090508@dfki.de>
Message-ID: <4B309AC6.1000606@dfki.de>

Christian Maeder schrieb:
> I think, libgmp.so* should be available under /usr/lib64/ if you use ghc.
> 
> There are rpm packages, i.e. SuSE
>   gmp-4.2.1-58
>   gmp-devel-4.2.1-58
> 
> In order to create binaries with libgmp being statically linked in, it
> is possible to copy libgmp.a into ghc'c libdir so that those binaries
> can run on systems with libgmp.so.
                     ^^^^ without the shared library.
> 
> HTH Christian
> 
> Bulat Ziganshin schrieb:
>> Hello glasgow-haskell-users,
>>
>> i compile my program for linux using ghc 6.6.1 (32-bit)
>>
>> user of my program asks: "any plans of making a static build for
>> linux? that one does not work under x86-64 due to dependencies,
>> missing libgmp which it seems is not available under 64bit. i could be
>> wrong tho."
>>
>> how this may be resolved? should libgmp be available in x64 linux, or
>> i should change compile options?
>>
From petersen at haskell.org  Tue Dec 22 07:59:34 2009
From: petersen at haskell.org (Jens Petersen)
Date: Tue Dec 22 07:33:15 2009
Subject: GHC-6.12.1: broken configure
In-Reply-To: <cc557aab0912181837u6829a3edp6d4901794ec80923@mail.gmail.com>
References: <cc557aab0912181837u6829a3edp6d4901794ec80923@mail.gmail.com>
Message-ID: <9436bffe0912220459m3150a3bbjbecb2940e9e222d6@mail.gmail.com>

2009/12/19 Kirill A. Shutemov <kirill@shutemov.name>:
> I want to build ghc for i586-alt-linux-gnu.

Why? :)

> Why do not use config.guess to guess correct host/target/build
> instead of reinvent wheel?

While I sympathize (I gave up long ago trying to use  host/target/build
with ghc - we use them by default in Fedora) - I guess the short answer
is something like cross-compiling is not supported or the effort
to support host/target/build is more than the win?  But those
are just my assumptions - I leave a real answer to a ghc buildsystem
expert.

If you really want a fix searching trac and opening a ticket would be
more effective probably.
From v.dijk.bas at gmail.com  Tue Dec 22 19:05:12 2009
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Tue Dec 22 18:39:12 2009
Subject: Weird warnings when using ViewPatterns
In-Reply-To: <f73f66150912211317j288f39bek38551e1301a3d62e@mail.gmail.com>
References: <f73f66150912210303h59b02656qead5988ccd9e782f@mail.gmail.com> 
	<4ec472cb0912211203i6c0728f6t16f153dac2a4a14d@mail.gmail.com> 
	<f73f66150912211317j288f39bek38551e1301a3d62e@mail.gmail.com>
Message-ID: <f73f66150912221605u6804c493rd5bf8d5e83df7f9@mail.gmail.com>

On Mon, Dec 21, 2009 at 10:17 PM, Bas van Dijk <v.dijk.bas@gmail.com> wrote:
> On Mon, Dec 21, 2009 at 9:03 PM, Robert Greayer <robgreayer@gmail.com> wrote:
>> There's been some improvement at least in 6.12.1, see:
>> http://hackage.haskell.org/trac/ghc/ticket/2395
>
> Thanks for pointing me to the ticket!
>
> I'm emerging ghc-6.12.1 right now to try it out (I'm on Gentoo Linux).

All weird warnings that I got when using ViewPatterns are gone when
using 6.12.1.

Thanks,

Bas
From robert.van.herk at philips.com  Wed Dec 23 02:55:51 2009
From: robert.van.herk at philips.com (Herk, Robert van)
Date: Wed Dec 23 02:29:38 2009
Subject: Poor array behaviour
Message-ID: <35AD6BF061932E4291356D05B7078057402851F32F@NLCLUEXM04.connect1.local>

Hi all,

I stumbled upon something odd with respect to arrays. I know about GHC not doing card marking and traversing whole arrays one each GC for each array with alterations, but still I don't understand the behaviour.

The situation is like this. I am building a compiler. This compiler manipulates a large graph (for optimizations, etc.). This graph is in memory. As the graph is vast, we did a lot of effort to optimize access to it. The nodes in the graph are IORefs to some data structure, and this data structure contains its edges.

Each node stores its edges in buckets. This is because edges have different types (some are control flow links, others are other types of dependencies). Most of the graph manipulations only traverse over one type of edge, so we figured it would be faster to store the edges in buckets to support such queries. Inside the buckets, there are Data.Maps containing the actual edges for that bucket. The keys in this map are the target nodes of that edges, which are IORefsOrds, which are pairs of a unique integers and a IORef, such that they can be ordered and used as keys in a Map. The values are lists of edges to that target.

The weird thing is in the buckets. Per node, all buckets are stored in an array.  We gave each edge type an integer key.

And we use that key as array index to determine the bucket. I've tried implementing this array in two ways:

1) Each node contains a immutable array with IORefs. The IORefs contain the actual Data.Maps for the buckets. So, for instance, initializing a node looks something like

import Data.Array

uBucket = 8 //There are 8 buckets because there are 8 types of edges.

emptyEdges =
  do  buckets <- sequence ( take uBucket $ repeat (newIORef Map.empty) )
        let myArray = listArray (0, 7) buckets
        return myArray

So in this solution we have an extra layer of indirection, namely the IORefs, but the array is immutable. Because when the edges change for a particular node, we can write directly into the IORef and leave the array untouched.

2) Each node contains a mutable array that contains the Data.Maps directly. So, for instance, initializing a node looks something like:

import Data.Array.IO

emptyEdges =
   do myArray <- newArray (0, 7) Map.empty
        return $! myArray

Of course, one expect 2 to be quickest. However, it turns out that for 2, the application is spending much more time in GC, and __even without GC__ the application is still slower! I find both things rather weird: I know that for huge arrays I am expected to suffer from the missing card-marking "bug", but my array sizes are only 8.

Yet the difference I get in GC time are huge:

Solution 1
-------------
  13,476,008,560 bytes allocated in the heap
   1,714,767,712 bytes copied during GC
     151,518,528 bytes maximum residency (23 sample(s))
       1,743,176 bytes maximum slop
             325 MB total memory in use (2 MB lost due to fragmentation)

  Generation 0: 25689 collections,     0 parallel,  2.43s,  2.53s elapsed
  Generation 1:    23 collections,     0 parallel,  1.89s,  2.05s elapsed

  INIT  time    0.00s  (  0.00s elapsed)
  MUT   time   20.58s  ( 20.80s elapsed)
  GC    time    4.32s  (  4.58s elapsed)
  RP    time    0.00s  (  0.00s elapsed)
  PROF  time    0.00s  (  0.00s elapsed)
  EXIT  time    0.00s  (  0.00s elapsed)
  Total time   24.90s  ( 25.38s elapsed)

  %GC time      17.4%  (18.0% elapsed)

  Alloc rate    654,751,131 bytes per MUT second

  Productivity  82.6% of total user, 81.1% of total elapsed

Solution 2
------------

  15,901,133,296 bytes allocated in the heap
   9,083,063,848 bytes copied during GC
     117,501,208 bytes maximum residency (23 sample(s))
       1,902,568 bytes maximum slop
             265 MB total memory in use (2 MB lost due to fragmentation)

  Generation 0: 30315 collections,     0 parallel, 44.73s, 44.89s elapsed
  Generation 1:    23 collections,     0 parallel,  1.78s,  1.91s elapsed

  INIT  time    0.00s  (  0.00s elapsed)
  MUT   time   25.93s  ( 26.31s elapsed)
  GC    time   46.51s  ( 46.80s elapsed)
  RP    time    0.00s  (  0.00s elapsed)
  PROF  time    0.00s  (  0.00s elapsed)
  EXIT  time    0.00s  (  0.00s elapsed)
  Total time   72.43s  ( 73.11s elapsed)

  %GC time      64.2%  (64.0% elapsed)

  Alloc rate    613,325,569 bytes per MUT second

  Productivity  35.8% of total user, 35.5% of total elapsed

Is the behaviour I am seeing to be expected? And if so, wouldn't it make more sense to implement Data.Array.IO internally such that it contains an immutable array of IORefs? I also saw that in the next GHC, card marking will be done per 128 array items. Yet this behaviour seems to point out that at least for my application problems can already occur with array size 8. And is it expected that solution 1), that has an extra layer of indirection, still outperforms solution 2) even with GC times substracted?

Regards,
Robert

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
From ndmitchell at gmail.com  Wed Dec 23 16:34:58 2009
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Wed Dec 23 16:08:35 2009
Subject: Where did the GHC API go?
In-Reply-To: <4B2F6C30.3080705@gmail.com>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>
	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>
	<bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com>
	<4B2F6C30.3080705@gmail.com>
Message-ID: <404396ef0912231334p37435e89q6e245841844b24fa@mail.gmail.com>

Note that other links have gone broken recently:

http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:filter

These links are relied upon by Hoogle and Google. I suspect they have
the same cause.

Thanks, Neil

On Mon, Dec 21, 2009 at 12:38 PM, Simon Marlow <marlowsd@gmail.com> wrote:
> On 21/12/2009 00:18, Tom Tobin wrote:
>>
>> On Sun, Dec 20, 2009 at 6:17 PM, Tom Tobin<korpios@korpios.com> ?wrote:
>>>
>>> On Sun, Dec 20, 2009 at 4:47 PM, Jason Dusek<jason.dusek@gmail.com>
>>> ?wrote:
>>>>
>>>> ?Maybe I missed an email about this...
>>>>
>>>> ? ?http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/index.html
>>>>
>>>> ?The link is down.
>>>
>>> The link from the GHC Documentation page points here, which works for me:
>>>
>>> http://www.haskell.org/ghc/docs/latest/html/libraries/index.html
>>
>> Sorry, read that too quickly ? you're asking about the API. ?That is
>> indeed a dead link for me.
>
> Ian, is this something to do with the recent redirects that were added?
>
> Cheers,
> ? ? ? ?Simon
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
From marlowsd at gmail.com  Wed Dec 23 16:49:40 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed Dec 23 16:23:20 2009
Subject: GHC-6.12.1: broken configure
In-Reply-To: <9436bffe0912220459m3150a3bbjbecb2940e9e222d6@mail.gmail.com>
References: <cc557aab0912181837u6829a3edp6d4901794ec80923@mail.gmail.com>
	<9436bffe0912220459m3150a3bbjbecb2940e9e222d6@mail.gmail.com>
Message-ID: <4B329074.7020106@gmail.com>

On 22/12/09 12:59, Jens Petersen wrote:
> 2009/12/19 Kirill A. Shutemov<kirill@shutemov.name>:
>> I want to build ghc for i586-alt-linux-gnu.
>
> Why? :)
>
>> Why do not use config.guess to guess correct host/target/build
>> instead of reinvent wheel?
>
> While I sympathize (I gave up long ago trying to use  host/target/build
> with ghc - we use them by default in Fedora) - I guess the short answer
> is something like cross-compiling is not supported or the effort
> to support host/target/build is more than the win?  But those
> are just my assumptions - I leave a real answer to a ghc buildsystem
> expert.
>
> If you really want a fix searching trac and opening a ticket would be
> more effective probably.

I personally think we should revert to using the standard config.guess 
and normalising the result as we used to.  It was changed due to this:

http://hackage.haskell.org/trac/ghc/ticket/1717

so we should find another way around that.

Cheers,
	Simon
From marlowsd at gmail.com  Wed Dec 23 17:07:58 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed Dec 23 16:41:37 2009
Subject: Poor array behaviour
In-Reply-To: <35AD6BF061932E4291356D05B7078057402851F32F@NLCLUEXM04.connect1.local>
References: <35AD6BF061932E4291356D05B7078057402851F32F@NLCLUEXM04.connect1.local>
Message-ID: <4B3294BE.30304@gmail.com>

On 23/12/09 07:55, Herk, Robert van wrote:
> Hi all,
>
> I stumbled upon something odd with respect to arrays. I know about GHC not doing card marking and traversing whole arrays one each GC for each array with alterations, but still I don't understand the behaviour.
>
> The situation is like this. I am building a compiler. This compiler manipulates a large graph (for optimizations, etc.). This graph is in memory. As the graph is vast, we did a lot of effort to optimize access to it. The nodes in the graph are IORefs to some data structure, and this data structure contains its edges.
>
> Each node stores its edges in buckets. This is because edges have different types (some are control flow links, others are other types of dependencies). Most of the graph manipulations only traverse over one type of edge, so we figured it would be faster to store the edges in buckets to support such queries. Inside the buckets, there are Data.Maps containing the actual edges for that bucket. The keys in this map are the target nodes of that edges, which are IORefsOrds, which are pairs of a unique integers and a IORef, such that they can be ordered and used as keys in a Map. The values are lists of edges to that target.
>
> The weird thing is in the buckets. Per node, all buckets are stored in an array.  We gave each edge type an integer key.
>
> And we use that key as array index to determine the bucket. I've tried implementing this array in two ways:
>
> 1) Each node contains a immutable array with IORefs. The IORefs contain the actual Data.Maps for the buckets. So, for instance, initializing a node looks something like
>
> import Data.Array
>
> uBucket = 8 //There are 8 buckets because there are 8 types of edges.
>
> emptyEdges =
>    do  buckets<- sequence ( take uBucket $ repeat (newIORef Map.empty) )
>          let myArray = listArray (0, 7) buckets
>          return myArray
>
> So in this solution we have an extra layer of indirection, namely the IORefs, but the array is immutable. Because when the edges change for a particular node, we can write directly into the IORef and leave the array untouched.
>
> 2) Each node contains a mutable array that contains the Data.Maps directly. So, for instance, initializing a node looks something like:
>
> import Data.Array.IO
>
> emptyEdges =
>     do myArray<- newArray (0, 7) Map.empty
>          return $! myArray
>
> Of course, one expect 2 to be quickest. However, it turns out that for 2, the application is spending much more time in GC, and __even without GC__ the application is still slower! I find both things rather weird: I know that for huge arrays I am expected to suffer from the missing card-marking "bug", but my array sizes are only 8.

If you have lots of small mutable arrays, that could be a problem.  We 
implement the write barrier differently for arrays vs. IORefs: an IORef 
is only placed in the remembered set (and hence scanned during minor GC) 
if it is modified.  Mutable arrays on the other hand are always in the 
remembered set, but they are marked either clean or dirty.  There's a 
tradeoff here: the approach we take for arrays means that writes are 
quicker, but each array has to be checked in a minor GC.  It works well 
when arrays are few and large, but less well when they are numerous and 
small.

Incedentally, I recently committed changes to add card marking to 
mutable arrays.  In your case it will probably hurt performance rather 
than improve it, though, since you won't benefit from the card table and 
the write barrier is more expensive.

One solution would be to have a new array type optimised for this case. 
  Alternatively we could experiment with the more expensive write 
barrier and see how much it hurts the large-array cases.

I'd like to verify that this is really the problem - any chance you can 
give us a self-contained snapshot of your code that we can use as a 
benchmark?

Cheers,
	Simon
From duncan.coutts at googlemail.com  Wed Dec 23 18:03:23 2009
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Wed Dec 23 17:37:03 2009
Subject: GHC-6.12.1: broken configure
In-Reply-To: <4B329074.7020106@gmail.com>
References: <cc557aab0912181837u6829a3edp6d4901794ec80923@mail.gmail.com>
	<9436bffe0912220459m3150a3bbjbecb2940e9e222d6@mail.gmail.com>
	<4B329074.7020106@gmail.com>
Message-ID: <1261609403.9220.83723.camel@localhost>

On Wed, 2009-12-23 at 21:49 +0000, Simon Marlow wrote:

> I personally think we should revert to using the standard config.guess 
> and normalising the result as we used to.

Aye.

> It was changed due to this:
> 
> http://hackage.haskell.org/trac/ghc/ticket/1717
> 
> so we should find another way around that.

I think we should just tell the ppc linux people to get their change to
config.guess pushed upstream. They cannot expect to change every package
instead.

Duncan

From igloo at earth.li  Thu Dec 24 09:01:41 2009
From: igloo at earth.li (Ian Lynagh)
Date: Thu Dec 24 08:35:16 2009
Subject: GHC-6.12.1: broken configure
In-Reply-To: <4B329074.7020106@gmail.com>
References: <cc557aab0912181837u6829a3edp6d4901794ec80923@mail.gmail.com>
	<9436bffe0912220459m3150a3bbjbecb2940e9e222d6@mail.gmail.com>
	<4B329074.7020106@gmail.com>
Message-ID: <20091224140141.GA5781@matrix.chaos.earth.li>

On Wed, Dec 23, 2009 at 09:49:40PM +0000, Simon Marlow wrote:
> On 22/12/09 12:59, Jens Petersen wrote:
>> 2009/12/19 Kirill A. Shutemov<kirill@shutemov.name>:
>>> I want to build ghc for i586-alt-linux-gnu.
>>
>> Why? :)
>>
>>> Why do not use config.guess to guess correct host/target/build
>>> instead of reinvent wheel?
>>
>> While I sympathize (I gave up long ago trying to use  host/target/build
>> with ghc - we use them by default in Fedora) - I guess the short answer
>> is something like cross-compiling is not supported or the effort
>> to support host/target/build is more than the win?  But those
>> are just my assumptions - I leave a real answer to a ghc buildsystem
>> expert.
>>
>> If you really want a fix searching trac and opening a ticket would be
>> more effective probably.
>
> I personally think we should revert to using the standard config.guess  
> and normalising the result as we used to.

I don't see the advantage. Before we had 484 lines of case expression in
configure.ac, which now and again needed tweaking to keep up with
changes in configure.

Now we don't need to be told the platform that we are building for, as
we just ask the bootstrapping compiler what platform it builds for, and
we only support building for that platform anyway. If you specify a
different platform then the build will break. I don't know if the
original poster means that he wants i586 as opposed to e.g. i386 (to
make use of newer instructions or to optimise differently), but if so we
don't do anything different for different subarches.

As far as I can see, the only reason we would need to support all the
platform values that configure supports is if/when we are going to
support cross-compilation.


Thanks
Ian

From igloo at earth.li  Thu Dec 24 09:15:49 2009
From: igloo at earth.li (Ian Lynagh)
Date: Thu Dec 24 08:49:23 2009
Subject: Where did the GHC API go?
In-Reply-To: <4B2F6C30.3080705@gmail.com>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>
	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>
	<bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com>
	<4B2F6C30.3080705@gmail.com>
Message-ID: <20091224141549.GB5781@matrix.chaos.earth.li>

On Mon, Dec 21, 2009 at 12:38:08PM +0000, Simon Marlow wrote:
> On 21/12/2009 00:18, Tom Tobin wrote:
>> On Sun, Dec 20, 2009 at 6:17 PM, Tom Tobin<korpios@korpios.com>  wrote:
>>> On Sun, Dec 20, 2009 at 4:47 PM, Jason Dusek<jason.dusek@gmail.com>  wrote:
>>>>   Maybe I missed an email about this...
>>>>
>>>>     http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/index.html
>>>>
>>>>   The link is down.
>>>
>>> The link from the GHC Documentation page points here, which works for me:
>>>
>>> http://www.haskell.org/ghc/docs/latest/html/libraries/index.html
>>
>> Sorry, read that too quickly ? you're asking about the API.  That is
>> indeed a dead link for me.
>
> Ian, is this something to do with the recent redirects that were added?

It's fallout from #3532 (put library docs in versioned directories so
that we can have multiple versions installed).

I've fixed the online 6.12.1 docs, and filed #3785 to remind myself to
fix it properly for 6.12.2.


Thanks
Ian

From igloo at earth.li  Thu Dec 24 09:18:15 2009
From: igloo at earth.li (Ian Lynagh)
Date: Thu Dec 24 08:51:50 2009
Subject: Where did the GHC API go?
In-Reply-To: <404396ef0912231334p37435e89q6e245841844b24fa@mail.gmail.com>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>
	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>
	<bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com>
	<4B2F6C30.3080705@gmail.com>
	<404396ef0912231334p37435e89q6e245841844b24fa@mail.gmail.com>
Message-ID: <20091224141815.GC5781@matrix.chaos.earth.li>

On Wed, Dec 23, 2009 at 09:34:58PM +0000, Neil Mitchell wrote:
> Note that other links have gone broken recently:
> 
> http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:filter
> 
> These links are relied upon by Hoogle and Google. I suspect they have
> the same cause.

Yes, this is now

http://haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Prelude.html#v:filter
                                                  ~~~~~~~~~~~~

I'd suggest that Hoogle shold probably use its own copy of the docs, so
that it stays in sync with them. Also, you probably want to index the
set of libraries that come with the Haskell Platform, rather than just
those that come with GHC.


Thanks
Ian

From andres.sicard.ramirez at gmail.com  Thu Dec 24 09:57:58 2009
From: andres.sicard.ramirez at gmail.com (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Thu Dec 24 09:31:55 2009
Subject: Where did the GHC API go?
In-Reply-To: <20091224141549.GB5781@matrix.chaos.earth.li>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com> 
	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com> 
	<bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com> 
	<4B2F6C30.3080705@gmail.com>
	<20091224141549.GB5781@matrix.chaos.earth.li>
Message-ID: <3e78550a0912240657p24e9e2b1sab8ec5bdf91b269@mail.gmail.com>

On Thu, Dec 24, 2009 at 9:15 AM, Ian Lynagh <igloo@earth.li> wrote:

>
> I've fixed the online 6.12.1 docs,
>

The link is down for me:

http://www.haskell.org/ghc/docs/6.12.1/html/libraries/ghc/index.html

-- 
Andr?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091224/1be249fa/attachment.html
From igloo at earth.li  Thu Dec 24 10:06:12 2009
From: igloo at earth.li (Ian Lynagh)
Date: Thu Dec 24 09:39:47 2009
Subject: Where did the GHC API go?
In-Reply-To: <3e78550a0912240657p24e9e2b1sab8ec5bdf91b269@mail.gmail.com>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>
	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>
	<bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com>
	<4B2F6C30.3080705@gmail.com>
	<20091224141549.GB5781@matrix.chaos.earth.li>
	<3e78550a0912240657p24e9e2b1sab8ec5bdf91b269@mail.gmail.com>
Message-ID: <20091224150612.GA6573@matrix.chaos.earth.li>

On Thu, Dec 24, 2009 at 09:57:58AM -0500, Andr?s Sicard-Ram?rez wrote:
> On Thu, Dec 24, 2009 at 9:15 AM, Ian Lynagh <igloo@earth.li> wrote:
> 
> >
> > I've fixed the online 6.12.1 docs,
> 
> The link is down for me:
> 
> http://www.haskell.org/ghc/docs/6.12.1/html/libraries/ghc/index.html

Which page is linking to there?


Thanks
Ian

From ml at isaac.cedarswampstudios.org  Thu Dec 24 10:08:36 2009
From: ml at isaac.cedarswampstudios.org (Isaac Dupree)
Date: Thu Dec 24 09:42:20 2009
Subject: Where did the GHC API go?
In-Reply-To: <20091224141815.GC5781@matrix.chaos.earth.li>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>	<bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com>	<4B2F6C30.3080705@gmail.com>	<404396ef0912231334p37435e89q6e245841844b24fa@mail.gmail.com>
	<20091224141815.GC5781@matrix.chaos.earth.li>
Message-ID: <4B3383F4.50201@isaac.cedarswampstudios.org>

Ian Lynagh wrote:
> On Wed, Dec 23, 2009 at 09:34:58PM +0000, Neil Mitchell wrote:
>> Note that other links have gone broken recently:
>>
>> http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:filter
>>
>> These links are relied upon by Hoogle and Google. I suspect they have
>> the same cause.
> 
> Yes, this is now
> 
> http://haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Prelude.html#v:filter
>                                                   ~~~~~~~~~~~~

I'm tempted to say: the older URL was better, because I could bookmark 
it once and go look anytime at a fairly up-to-date ("latest" a la the 
URL) version of base.

But GHC includes multiple versions of base currently, so this wish 
doesn't even make as much sense as it could...

-Isaac
From andres.sicard.ramirez at gmail.com  Thu Dec 24 10:11:55 2009
From: andres.sicard.ramirez at gmail.com (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Thu Dec 24 09:45:50 2009
Subject: Where did the GHC API go?
In-Reply-To: <20091224150612.GA6573@matrix.chaos.earth.li>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com> 
	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com> 
	<bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com> 
	<4B2F6C30.3080705@gmail.com>
	<20091224141549.GB5781@matrix.chaos.earth.li> 
	<3e78550a0912240657p24e9e2b1sab8ec5bdf91b269@mail.gmail.com> 
	<20091224150612.GA6573@matrix.chaos.earth.li>
Message-ID: <3e78550a0912240711r557bdc04w5cbf11ef1f5d8b22@mail.gmail.com>

2009/12/24 Ian Lynagh <igloo@earth.li>

> On Thu, Dec 24, 2009 at 09:57:58AM -0500, Andr?s Sicard-Ram?rez wrote:
> > On Thu, Dec 24, 2009 at 9:15 AM, Ian Lynagh <igloo@earth.li> wrote:
> >
> > >
> > > I've fixed the online 6.12.1 docs,
> >
> > The link is down for me:
> >
> > http://www.haskell.org/ghc/docs/6.12.1/html/libraries/ghc/index.html
>
> Which page is linking to there?
>
>
http://www.haskell.org/ghc/docs/6.12.1/html/

-- 
Andr?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091224/f321d47e/attachment.html
From igloo at earth.li  Thu Dec 24 10:23:01 2009
From: igloo at earth.li (Ian Lynagh)
Date: Thu Dec 24 09:56:38 2009
Subject: Where did the GHC API go?
In-Reply-To: <3e78550a0912240711r557bdc04w5cbf11ef1f5d8b22@mail.gmail.com>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>
	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>
	<bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com>
	<4B2F6C30.3080705@gmail.com>
	<20091224141549.GB5781@matrix.chaos.earth.li>
	<3e78550a0912240657p24e9e2b1sab8ec5bdf91b269@mail.gmail.com>
	<20091224150612.GA6573@matrix.chaos.earth.li>
	<3e78550a0912240711r557bdc04w5cbf11ef1f5d8b22@mail.gmail.com>
Message-ID: <20091224152301.GA6860@matrix.chaos.earth.li>

On Thu, Dec 24, 2009 at 10:11:55AM -0500, Andr?s Sicard-Ram?rez wrote:
> 2009/12/24 Ian Lynagh <igloo@earth.li>
> 
> > On Thu, Dec 24, 2009 at 09:57:58AM -0500, Andr?s Sicard-Ram?rez wrote:
> > > On Thu, Dec 24, 2009 at 9:15 AM, Ian Lynagh <igloo@earth.li> wrote:
> > >
> > > >
> > > > I've fixed the online 6.12.1 docs,
> > >
> > > The link is down for me:
> > >
> > > http://www.haskell.org/ghc/docs/6.12.1/html/libraries/ghc/index.html
> >
> > Which page is linking to there?
> >
> >
> http://www.haskell.org/ghc/docs/6.12.1/html/

Thanks, fixed.


Thanks
Ian

From aslatter at gmail.com  Thu Dec 24 18:18:36 2009
From: aslatter at gmail.com (Antoine Latter)
Date: Thu Dec 24 17:52:09 2009
Subject: GHC.Prim.ByteArray# - confusing documentation
Message-ID: <694519c50912241518p3ab50470m5d544fd5235abf1@mail.gmail.com>

Folks,

I found some of the documentation in GHC.Prim confusing - so I thought
I'd share. The documentation for the ByteArray# type[1] explains
that's it's a raw region in memory that also remembers it's size.

Consequently I expected sizeOfByteArray# to return the same number
that I passed in to newByteArray#. But it doesn't - It returned
however much it decided to allocate, which on my platform is always a
multiple of four bytes.

This is something which could be clarified in the documentation.

So it turns out I need to carry my own length around in something like
(Int, ByteArray#).

(I tested all of this with the primitive[2] package, which is a thin
wrapper around GHC.Prim)

Antoine

1: http://hackage.haskell.org/packages/archive/ghc-prim/0.1.0.0/doc/html/GHC-Prim.html#t%3AByteArray%23
2: http://hackage.haskell.org/package/primitive
From duncan.coutts at googlemail.com  Sat Dec 26 12:50:25 2009
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Sat Dec 26 12:23:56 2009
Subject: GHC.Prim.ByteArray# - confusing documentation
In-Reply-To: <694519c50912241518p3ab50470m5d544fd5235abf1@mail.gmail.com>
References: <694519c50912241518p3ab50470m5d544fd5235abf1@mail.gmail.com>
Message-ID: <1261849825.9220.99826.camel@localhost>

On Thu, 2009-12-24 at 18:18 -0500, Antoine Latter wrote:
> Folks,
> 
> I found some of the documentation in GHC.Prim confusing - so I thought
> I'd share. The documentation for the ByteArray# type[1] explains
> that's it's a raw region in memory that also remembers it's size.
> 
> Consequently I expected sizeOfByteArray# to return the same number
> that I passed in to newByteArray#. But it doesn't - It returned
> however much it decided to allocate, which on my platform is always a
> multiple of four bytes.

Yes, this is an artefact of the fact that ghc measures heap stuff in
units of words.

> This is something which could be clarified in the documentation.

It would be jolly useful for making short strings for GHC's ByteArray#
to to use a byte length rather than a word length. It'd mean a little
more bit twiddling in the GC code that looks at ByteArray#s, however
it'd save an extra 2 words in a short string type (or allow us to store
'\0' characters in short strings).

It's been on my TODO list for some time to design a portable low level
ByteArray module that could be implemented by hugs, nhc, ghc, etc. The
aim would be to be similar to ForeignPtr + Storable but using native
heap allocated memory blocks.

In turn this would be the right portable layer on which to build
ByteString, Text and probably IO buffers too.

Duncan

From aslatter at gmail.com  Sat Dec 26 17:25:27 2009
From: aslatter at gmail.com (Antoine Latter)
Date: Sat Dec 26 16:58:54 2009
Subject: GHC.Prim.ByteArray# - confusing documentation
In-Reply-To: <1261849825.9220.99826.camel@localhost>
References: <694519c50912241518p3ab50470m5d544fd5235abf1@mail.gmail.com>
	<1261849825.9220.99826.camel@localhost>
Message-ID: <694519c50912261425j6c77025fy76d296a21cfc160e@mail.gmail.com>

On Sat, Dec 26, 2009 at 12:50 PM, Duncan Coutts
<duncan.coutts@googlemail.com> wrote:
>
> It's been on my TODO list for some time to design a portable low level
> ByteArray module that could be implemented by hugs, nhc, ghc, etc. The
> aim would be to be similar to ForeignPtr + Storable but using native
> heap allocated memory blocks.
>

It looks like Data.Text.Array has a bit of a head-start on this,
although it sounds like you're looking for something even simpler.
Currently it only apears to build on GHC and Hugs, but we could have
an FFI fall-back case.

I prefer the interface to Data.Primitive.ByteArray, though.

> In turn this would be the right portable layer on which to build
> ByteString, Text and probably IO buffers too.

It looks like ByteString is aggressive about calling C code to perform
a few operations - which is something we'd only be able to do for
pined arrays.

Antoine
From ndmitchell at gmail.com  Sun Dec 27 13:24:35 2009
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Sun Dec 27 12:58:01 2009
Subject: Where did the GHC API go?
In-Reply-To: <20091224141815.GC5781@matrix.chaos.earth.li>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>
	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>
	<bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com>
	<4B2F6C30.3080705@gmail.com>
	<404396ef0912231334p37435e89q6e245841844b24fa@mail.gmail.com>
	<20091224141815.GC5781@matrix.chaos.earth.li>
Message-ID: <404396ef0912271024v498b3dbo8d47b42bbdc4b323@mail.gmail.com>

Hi Ian,

> Yes, this is now
>
> http://haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Prelude.html#v:filter
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?~~~~~~~~~~~~
>
> I'd suggest that Hoogle shold probably use its own copy of the docs, so
> that it stays in sync with them. Also, you probably want to index the
> set of libraries that come with the Haskell Platform, rather than just
> those that come with GHC.

Too late. We had a stable link, I used it, Google used it, blog posts
were written that linked to it, I've emailed my wife links to it, I've
put them in Word documents, I've posted them on internal intranets.
You can't create a link, put content behind it, then move the content
- it just breaks the whole web.

I can fix Hoogle, but I can't fix the rest of the web... I recommend
putting in a permanent redirect from where the old docs used to be to
base 4.0, and then never moving it forward. Or perhaps symlinking
latest to always the latest version. Either way, I think breaking a
huge set of links is a really bad idea. I also think it's a bad idea
for Hoogle to link off to different documentation from the rest of
Haskell, it's just not a good idea to fragment the Hoogle universe
from the rest of the docs.

Thanks, Neil
From bos at serpentine.com  Sun Dec 27 13:55:48 2009
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Sun Dec 27 13:29:13 2009
Subject: hsc2hs and base
Message-ID: <c290c4f20912271055n5193bb6dl2eb03bd736b9b7cb@mail.gmail.com>

Hi, Simon ?

Is it licit to have source files in base depend on preprocessing by hsc2hs?
My suspicion is "no", but I want to be sure.

Thanks,
Bryan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091227/22e07b72/attachment.html
From bos at serpentine.com  Sun Dec 27 15:59:12 2009
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Sun Dec 27 15:32:37 2009
Subject: hsc2hs and base
In-Reply-To: <c290c4f20912271055n5193bb6dl2eb03bd736b9b7cb@mail.gmail.com>
References: <c290c4f20912271055n5193bb6dl2eb03bd736b9b7cb@mail.gmail.com>
Message-ID: <c290c4f20912271259t490cd014wb9d6ccc13744fa93@mail.gmail.com>

On Sun, Dec 27, 2009 at 10:55 AM, Bryan O'Sullivan <bos@serpentine.com>wrote:

> Is it licit to have source files in base depend on preprocessing by hsc2hs?
> My suspicion is "no", but I want to be sure.
>

Never mind, I found a ".hsc" source file in base, so it must be okay after
all :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091227/9312c991/attachment.html
From donn at avvanta.com  Sun Dec 27 18:28:24 2009
From: donn at avvanta.com (Donn Cave)
Date: Sun Dec 27 18:01:48 2009
Subject: hsc2hs and base
References: <c290c4f20912271055n5193bb6dl2eb03bd736b9b7cb@mail.gmail.com><c290c4f20912271259t490cd014wb9d6ccc13744fa93@mail.gmail.com>
Message-ID: <20091227232824.1229A276C43@mail.avvanta.com>

Quoth "Bryan O'Sullivan" <bos@serpentine.com>,
> On Sun, Dec 27, 2009 at 10:55 AM, Bryan O'Sullivan <bos@serpentine.com>wrote:
>
>> Is it licit to have source files in base depend on preprocessing by hsc2hs?
>> My suspicion is "no", but I want to be sure.
>>
>
> Never mind, I found a ".hsc" source file in base, so it must be okay after
> all :-)

I guess it depends on your definition of "okay".  It's awkward for
the `unregisterised' port process, where you build .hc files on a
supported host with similar hardware, because the .hc files will have
been hsc2hs processed on the wrong platform when you compile them.
So just for example if 1) the layout of struct rusage is different
between the two hosts, and 2) the initial bootstrap ghc uses those
functions in System/CPUTime.hsc while trying to build itself, there's
going to be trouble.

Strictly speaking, though, that isn't so much a problem with hsc2hs
per se, rather with .hsc files that include platform-dependent
C definitions.  If you provide the C source also, and hsc2hs sees
only platform-independent definitions from your source, then I don't
see how that would be a problem.  In the above example I suppose that
would mean a `struct ghc_rusage' or something.

	Donn Cave, donn@avvanta.com

From malcolm.wallace at cs.york.ac.uk  Mon Dec 28 06:06:29 2009
From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace)
Date: Mon Dec 28 05:39:52 2009
Subject: Where did the GHC API go?
In-Reply-To: <404396ef0912271024v498b3dbo8d47b42bbdc4b323@mail.gmail.com>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>
	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>
	<bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com>
	<4B2F6C30.3080705@gmail.com>
	<404396ef0912231334p37435e89q6e245841844b24fa@mail.gmail.com>
	<20091224141815.GC5781@matrix.chaos.earth.li>
	<404396ef0912271024v498b3dbo8d47b42bbdc4b323@mail.gmail.com>
Message-ID: <3B417606-D9E7-4775-938C-C41EACBF3575@cs.york.ac.uk>

> Too late. We had a stable link, I used it, Google used it, blog posts
> were written that linked to it, I've emailed my wife links to it, I've
> put them in Word documents, I've posted them on internal intranets.
> You can't create a link, put content behind it, then move the content
> - it just breaks the whole web.

And incidentally, the _ghc_docs_ themselves continue to use these  
stable links to library docs, most of which are currently broken.

All of the following links from documentation for ghc-6.12.1 give a  
404 Not Found.  (I do not claim the list is exhaustive.)

from http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html
section 4.8 links to
     http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-Simple.html
section 4.8.8 links to
     http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-InstalledPackageInfo.html# 
%tInstalledPackageInfo
     http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-License.html#t 
:License

from http://www.haskell.org/ghc/docs/latest/html/users_guide/using-concurrent.html
section 4.12 links to
     http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html

from http://www.haskell.org/ghc/docs/latest/html/users_guide/primitives.html
section 7.2 links to
     http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-prim/GHC-Prim.html

from http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html
section 7.3.10 links to
     http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-Exts.html

from http://www.haskell.org/ghc/docs/latest/html/users_guide/arrow-notation.html
section 7.10 links twice to
     http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html

from http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html
section 7.13.1 links to
     http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Language-Haskell-Extension.html

from http://www.haskell.org/ghc/docs/latest/html/users_guide/special-ids.html
section 7.15 links to
     http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-prim/GHC-Prim.html

from http://www.haskell.org/ghc/docs/latest/html/users_guide/lang-parallel.html
section 7.18.1 links to
     http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html
section 7.18.2 links to
     http://www.haskell.org/ghc/docs/latest/html/libraries/stm/Control-Concurrent-STM.html
section 7.18.4 links to
     http://www.haskell.org/ghc/docs/latest/html/libraries/parallel/Control-Parallel.html
     http://www.haskell.org/ghc/docs/latest/html/libraries/parallel/Control-Parallel-Strategies.html

from http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi.html
section 8 incorrectly links to
     http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html
where the real link ought to be
     http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign.html

from http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html
section 8.2.4.2 links to
     http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html

from http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-windows.html
section 11.2 links to
     http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-ConsoleHandler.html


Regards,
     Malcolm

From niklas.broberg at gmail.com  Mon Dec 28 07:26:22 2009
From: niklas.broberg at gmail.com (Niklas Broberg)
Date: Mon Dec 28 06:59:43 2009
Subject: Qualified names in import lists
Message-ID: <a49071280912280426m4ae9bbc8h9d3394dc1a6d17a9@mail.gmail.com>

Hi all,

I have a bug report [1] for haskell-src-exts pertaining to the use of
qualified names in import specifications, e.g.

  module Main where
  import Foo (Bar.bar)

GHC apparently accepts this code, but I can find no mention of such a
feature in the GHC docs.

Personally I don't see why this should be allowed at all, as it breaks
the abstraction layer w.r.t. re-exporting names from other, possibly
internal, modules. If there's some reasonable use for it, it should at
the very least be tied to a documented and registered extension.

I've submitted a ticket for GHC [2] to either remove this feature, or
properly document it. I'd be curious to hear what the reasoning behind
it is, if any.

Cheers,

/Niklas

ps. Why is there no "GHC accepts invalid program" option for "Type of
failure"? Too few cases? I set this ticket to Other.

[1] http://trac.haskell.org/haskell-src-exts/ticket/57
[2] http://hackage.haskell.org/trac/ghc/ticket/3792
From gale at sefer.org  Mon Dec 28 07:56:17 2009
From: gale at sefer.org (Yitzchak Gale)
Date: Mon Dec 28 07:29:40 2009
Subject: [Haskell-beginners] Performance of parallel mergesort
In-Reply-To: <200912280319.58918.jon@ffconsultancy.com>
References: <200912232114.24493.jon@ffconsultancy.com>
	<200912261956.11617.jon@ffconsultancy.com>
	<4B37CA13.7050807@blacksapphire.com>
	<200912280319.58918.jon@ffconsultancy.com>
Message-ID: <2608b8a80912280456y56d89b8tdc3b9e0ddcc0c556@mail.gmail.com>

This discussion definitely does not belong on the
Haskell-Beginners list. Besides not being a topic
for beginners, being there is keeping it under the
radar of many or most of the people who work on
these things in Haskell.

I am moving the discussion to the GHC users list,
as suggested by Antoine. For those joining us in
progress, the first part of the thread starts here:

http://www.haskell.org/pipermail/beginners/2009-December/003045.html

On Mon, Dec 28, 2009 at 5:19 AM, Jon Harrop wrote:
> On Sunday 27 December 2009 20:56:51 Stephen Blackheath wrote:
>> Jon Harrop wrote:
>> > This is something that concerns me. Lots of discussions of parallelism,
>> > including the Haskell literature I have read, neglect this critical
>> > problem
>> > of making sure that more time is spent doing useful work than spawning
>> > tasks
>> > (sparks). How is this solved in Haskell? Do you just put magic numbers in
>> > that work on the machine you're currently using?
>>
>> It is simply not true that Haskell literature neglects the question of
>> spark granularity - this is very basic and is always covered. Read
>> "Real World Haskell" (available free online). ?There's no 'magic
>> number'. You must explicitly write your code to give the right granule
>> size.
>
> There is no "right granule" size. That's the whole point: the optimum is a
> function of the machine. If you hardcode the granularity then your code isn't
> future proof and isn't portable.
>
> From chapter 24 of Real World Haskell on sorting:
>
> ?"At this fine granularity, the cost of using par outweighs any possible
> usefulness. To reduce this effect, we switch to our non-parallel sort after
> passing some threshold."
>
> From the Sorting.hs file, parSort2 accepts a threshold "d":
>
> ?parSort2 :: (Ord a) => Int -> [a] -> [a]
> ?parSort2 d list@(x:xs)
> ? ?| d <= 0 ? ? = sort list
> ? ?| otherwise = force greater `par` (force lesser `pseq`
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(lesser ++ x:greater))
> ? ? ? ?where lesser ? ? ?= parSort2 d' [y | y <- xs, y < ?x]
> ? ? ? ? ? ? ?greater ? ? = parSort2 d' [y | y <- xs, y >= x]
> ? ? ? ? ? ? ?d' = d - 1
> ?parSort2 _ _ ? ? ? ? ? ? ?= []
>
> From the SortMain.hs file, it is always invoked with the magic number "2":
>
> ?testFunction = parSort2 2
>
> Moreover, their approach of subdividing a fixed number of times is suboptimal
> because it inhibits load balancing.
>
> Later, about parallelized IO, they give the code:
>
> ?chunkedReadWith :: (NFData a) =>
> ? ? ? ? ? ? ? ? ? ?([LB.ByteString] -> a) -> FilePath -> IO a
> ?chunkedReadWith func path =
> ? ? ?withChunks (lineChunks (numCapabilities * 4)) func path
>
> where "4" is one magic number that gets multiplied by the magic number the
> user supplied via the +RTS -N<n> command-line option.
>
> They make no attempt to adapt the granularity to the machine at all and rely
> entirely upon magic numbers. Consequently, their parallel sort that got a 25%
> speedup on two cores achieves a 30% slowdown on my 8 core.
>
>> I don't know the exact cost of sparking, but in my experience it
>> is quite small - so - as long as your granule is doing *some* real work,
>> it should speed up.
>
> Can you quantify it, e.g. How many FLOPS?
>
>> Jon Harrop wrote:
>> > The parallelism is obviously not obtaining any real speedup so something
>> > is wrong. But can anyone fix it?
>>
>> I've spent a bit of time measuring parallel speedup on real commercial
>> projects, and this is what I've found:
>>
>> 1. ghc-6.12 performs significantly better than ghc-6.10, and has now
>> been released, therefore don't use ghc-6.10.
>
> Ok.
>
>> 2. The defaults generally work better than giving huge heap sizes. ?Your
>> -K100000000 - maximum heap size per thread - will either do nothing or
>> cause an artificial slowdown (I have observed this with the minimum heap
>> size option). ?Don't use it, unless experimentation proves it makes
>> things better.
>
> On the contrary, the Haskell program dies without it:
>
> $ time ./mergesort +RTS -N8
> Stack space overflow: current size 8388608 bytes.
> Use `+RTS -Ksize' to increase it.
> [1]+ ?Done ? ? ? ? ? ? ? ? ? ?kwrite mergesort.hs
>
> real ? ?0m33.320s
> user ? ?3m29.397s
> sys ? ? 0m0.592s
>
> I had to add that -K command line option just to get the program to run to
> completion.
>
>> 3. +RTS -s is well worth using. It breaks the time down into MUT
>> (mutator) and GC (garbage collector).
>
> Its says 78.5% GC time (with GHC 6.10).
>
>> 4. MUT parallelization is excellent, but the parallel GC is not so good.
>> ?If your code is GC-heavy it can spend around half of its time garbage
>> collecting, which doesn't parallelize so well, and this eats into the
>> speedup.
>
> Ok.
>
>> 5. There seems to be a scalability problem with the parallel gc for
>> larger numbers of cores (namely 8). ?I am guessing somewhat, but my
>> experiments tend to confirm the issue raised in Simon Marlow's (the
>> implementor of GHC parallelization) recent paper that it's to do with
>> "stopping the world" for gc.
>
> Do you mean this bug:
>
> ?http://hackage.haskell.org/trac/ghc/ticket/3553
>
>> If GHC's lack of perfection at this point in time makes Haskell "look
>> bad" I don't mind. ?I am not selling anything, so the reader at least
>> knows they're getting the truth. ?I see this as one of the great
>> advantages of open source.
>
> I'm sure we'd all rather see speedups. :-)
>
>> Progress on GHC has been very rapid in the last couple of years, and so
>> I know we'll continue to see the speed of GHC's parallelism improving in
>> leaps and bounds. ?It's actually still quite a new area, considering the
>> difficulty of some of the technical issues and how recent it is that
>> multicores are widely available on consumer hardware.
>
> My original intent was to test a claim someone made: that mergesort in Haskell
> is competitively performant and trivially parallelized.
>
>> I know you OCaml/F# guys are making great progress too.
>
> F# is production ready but OCaml is dead in the water when it comes to
> multicore. I'm working on an OCaml replacement called HLVM but it is early
> days yet.
>
> --
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
From malcolm.wallace at cs.york.ac.uk  Mon Dec 28 12:43:17 2009
From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace)
Date: Mon Dec 28 12:16:39 2009
Subject: Qualified names in import lists
In-Reply-To: <a49071280912280426m4ae9bbc8h9d3394dc1a6d17a9@mail.gmail.com>
References: <a49071280912280426m4ae9bbc8h9d3394dc1a6d17a9@mail.gmail.com>
Message-ID: <18DAB487-150B-4BD2-94BB-5F08AA4A9FA4@cs.york.ac.uk>

>  module Main where
>  import Foo (Bar.bar)
>
> GHC apparently accepts this code, but I can find no mention of such a
> feature in the GHC docs.

It certainly is an extension beyond Haskell'98 and Haskell 2010, which  
do not permit qualified names in import lists.  I cannot think for any  
use for such a feature, never mind a good one.

If ghc really does accept the example given, I would like to know what  
entity Bar.bar refers to, since it cannot possibly be exported by Foo.

Regards,
     Malcolm

From jon at ffconsultancy.com  Mon Dec 28 14:01:29 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Mon Dec 28 12:20:32 2009
Subject: [Haskell-beginners] Performance of parallel mergesort
In-Reply-To: <2608b8a80912280456y56d89b8tdc3b9e0ddcc0c556@mail.gmail.com>
References: <200912232114.24493.jon@ffconsultancy.com>
	<200912280319.58918.jon@ffconsultancy.com>
	<2608b8a80912280456y56d89b8tdc3b9e0ddcc0c556@mail.gmail.com>
Message-ID: <200912281901.29328.jon@ffconsultancy.com>

On Monday 28 December 2009 12:56:17 Yitzchak Gale wrote:
> This discussion definitely does not belong on the
> Haskell-Beginners list. Besides not being a topic
> for beginners, being there is keeping it under the
> radar of many or most of the people who work on
> these things in Haskell.
>
> I am moving the discussion to the GHC users list,
> as suggested by Antoine. For those joining us in
> progress, the first part of the thread starts here:
>
> http://www.haskell.org/pipermail/beginners/2009-December/003045.html

I am not familiar with the GHC users list but is this discussion about basic 
parallelism really more relevant here? The interesting bits aren't GHC 
specific...

Also, is this list censored like the Haskell Cafe or is it open?

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
From niklas.broberg at gmail.com  Mon Dec 28 12:57:39 2009
From: niklas.broberg at gmail.com (Niklas Broberg)
Date: Mon Dec 28 12:31:01 2009
Subject: Qualified names in import lists
In-Reply-To: <18DAB487-150B-4BD2-94BB-5F08AA4A9FA4@cs.york.ac.uk>
References: <a49071280912280426m4ae9bbc8h9d3394dc1a6d17a9@mail.gmail.com>
	<18DAB487-150B-4BD2-94BB-5F08AA4A9FA4@cs.york.ac.uk>
Message-ID: <a49071280912280957o54858740x7ca7b6a1f9c5677e@mail.gmail.com>

> If ghc really does accept the example given, I would like to know what
> entity Bar.bar refers to, since it cannot possibly be exported by Foo.

In this example Bar exports bar, and Foo re-exports module Bar.

/Niklas
From aslatter at gmail.com  Mon Dec 28 14:18:20 2009
From: aslatter at gmail.com (Antoine Latter)
Date: Mon Dec 28 13:51:41 2009
Subject: [Haskell-beginners] Performance of parallel mergesort
In-Reply-To: <200912281901.29328.jon@ffconsultancy.com>
References: <200912232114.24493.jon@ffconsultancy.com>
	<200912280319.58918.jon@ffconsultancy.com>
	<2608b8a80912280456y56d89b8tdc3b9e0ddcc0c556@mail.gmail.com>
	<200912281901.29328.jon@ffconsultancy.com>
Message-ID: <694519c50912281118o5044bb3bt87d706211106433c@mail.gmail.com>

On Mon, Dec 28, 2009 at 2:01 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> On Monday 28 December 2009 12:56:17 Yitzchak Gale wrote:
>> This discussion definitely does not belong on the
>> Haskell-Beginners list. Besides not being a topic
>> for beginners, being there is keeping it under the
>> radar of many or most of the people who work on
>> these things in Haskell.
>>
>> I am moving the discussion to the GHC users list,
>> as suggested by Antoine. For those joining us in
>> progress, the first part of the thread starts here:
>>
>> http://www.haskell.org/pipermail/beginners/2009-December/003045.html
>
> I am not familiar with the GHC users list but is this discussion about basic
> parallelism really more relevant here? The interesting bits aren't GHC
> specific...

I don't think that any other implementation has support for the 'par'
operator, but I could see a case for either haskell-cafe or ghc-users
being a good spot for discussion. The beginers list is targeted at
raw-recruits or students overcoming their first encounter with
Haskell.

>
> Also, is this list censored like the Haskell Cafe or is it open?
>

I've never had any messages removed or moderated in any of the
@haskell.org lists, but maybe I'm not saying the right things :-)

Antoine
From ndmitchell at gmail.com  Mon Dec 28 17:04:56 2009
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Mon Dec 28 16:38:20 2009
Subject: Where did the GHC API go?
In-Reply-To: <3B417606-D9E7-4775-938C-C41EACBF3575@cs.york.ac.uk>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>
	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>
	<bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com>
	<4B2F6C30.3080705@gmail.com>
	<404396ef0912231334p37435e89q6e245841844b24fa@mail.gmail.com>
	<20091224141815.GC5781@matrix.chaos.earth.li>
	<404396ef0912271024v498b3dbo8d47b42bbdc4b323@mail.gmail.com>
	<3B417606-D9E7-4775-938C-C41EACBF3575@cs.york.ac.uk>
Message-ID: <404396ef0912281404n1e558aa6l6ba022d768427c5@mail.gmail.com>

I've now updated Hoogle to point at the new links. I still think the
old link's should be restored (perhaps as a permanent redirect code?),
but at least it doesn't break Hoogle now.

Thanks, Neil

On Mon, Dec 28, 2009 at 11:06 AM, Malcolm Wallace
<malcolm.wallace@cs.york.ac.uk> wrote:
>> Too late. We had a stable link, I used it, Google used it, blog posts
>> were written that linked to it, I've emailed my wife links to it, I've
>> put them in Word documents, I've posted them on internal intranets.
>> You can't create a link, put content behind it, then move the content
>> - it just breaks the whole web.
>
> And incidentally, the _ghc_docs_ themselves continue to use these stable
> links to library docs, most of which are currently broken.
>
> All of the following links from documentation for ghc-6.12.1 give a 404 Not
> Found. ?(I do not claim the list is exhaustive.)
>
> from http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html
> section 4.8 links to
>
> ?http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-Simple.html
> section 4.8.8 links to
>
> ?http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-InstalledPackageInfo.html#%tInstalledPackageInfo
>
> ?http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-License.html#t:License
>
> from
> http://www.haskell.org/ghc/docs/latest/html/users_guide/using-concurrent.html
> section 4.12 links to
>
> ?http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html
>
> from http://www.haskell.org/ghc/docs/latest/html/users_guide/primitives.html
> section 7.2 links to
>
> ?http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-prim/GHC-Prim.html
>
> from
> http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html
> section 7.3.10 links to
> ? ?http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-Exts.html
>
> from
> http://www.haskell.org/ghc/docs/latest/html/users_guide/arrow-notation.html
> section 7.10 links twice to
>
> ?http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html
>
> from http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html
> section 7.13.1 links to
>
> ?http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Language-Haskell-Extension.html
>
> from
> http://www.haskell.org/ghc/docs/latest/html/users_guide/special-ids.html
> section 7.15 links to
>
> ?http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-prim/GHC-Prim.html
>
> from
> http://www.haskell.org/ghc/docs/latest/html/users_guide/lang-parallel.html
> section 7.18.1 links to
>
> ?http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html
> section 7.18.2 links to
>
> ?http://www.haskell.org/ghc/docs/latest/html/libraries/stm/Control-Concurrent-STM.html
> section 7.18.4 links to
>
> ?http://www.haskell.org/ghc/docs/latest/html/libraries/parallel/Control-Parallel.html
>
> ?http://www.haskell.org/ghc/docs/latest/html/libraries/parallel/Control-Parallel-Strategies.html
>
> from http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi.html
> section 8 incorrectly links to
>
> ?http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html
> where the real link ought to be
> ? ?http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign.html
>
> from http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html
> section 8.2.4.2 links to
>
> ?http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html
>
> from
> http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-windows.html
> section 11.2 links to
>
> ?http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-ConsoleHandler.html
>
>
> Regards,
> ? ?Malcolm
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
From mmitar at gmail.com  Mon Dec 28 17:55:28 2009
From: mmitar at gmail.com (Mitar)
Date: Mon Dec 28 17:28:50 2009
Subject: Where did the GHC API go?
In-Reply-To: <404396ef0912281404n1e558aa6l6ba022d768427c5@mail.gmail.com>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>
	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>
	<bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com>
	<4B2F6C30.3080705@gmail.com>
	<404396ef0912231334p37435e89q6e245841844b24fa@mail.gmail.com>
	<20091224141815.GC5781@matrix.chaos.earth.li>
	<404396ef0912271024v498b3dbo8d47b42bbdc4b323@mail.gmail.com>
	<3B417606-D9E7-4775-938C-C41EACBF3575@cs.york.ac.uk>
	<404396ef0912281404n1e558aa6l6ba022d768427c5@mail.gmail.com>
Message-ID: <f63c4b2d0912281455j5205d3efv9cc4857daf672655@mail.gmail.com>

Hi!

On Mon, Dec 28, 2009 at 11:04 PM, Neil Mitchell <ndmitchell@gmail.com> wrote:
> I've now updated Hoogle to point at the new links. I still think the
> old link's should be restored (perhaps as a permanent redirect code?),
> but at least it doesn't break Hoogle now.

+1

I all the time get to 404 errors nowadays while trying to access documentation.


Mitar
From igloo at earth.li  Tue Dec 29 06:43:17 2009
From: igloo at earth.li (Ian Lynagh)
Date: Tue Dec 29 06:16:36 2009
Subject: Where did the GHC API go?
In-Reply-To: <404396ef0912271024v498b3dbo8d47b42bbdc4b323@mail.gmail.com>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>
	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>
	<bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com>
	<4B2F6C30.3080705@gmail.com>
	<404396ef0912231334p37435e89q6e245841844b24fa@mail.gmail.com>
	<20091224141815.GC5781@matrix.chaos.earth.li>
	<404396ef0912271024v498b3dbo8d47b42bbdc4b323@mail.gmail.com>
Message-ID: <20091229114317.GA14270@matrix.chaos.earth.li>


Hi Neil,

On Sun, Dec 27, 2009 at 06:24:35PM +0000, Neil Mitchell wrote:
> 
> > Yes, this is now
> >
> > http://haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Prelude.html#v:filter
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?~~~~~~~~~~~~
> >
> > I'd suggest that Hoogle shold probably use its own copy of the docs, so
> > that it stays in sync with them. Also, you probably want to index the
> > set of libraries that come with the Haskell Platform, rather than just
> > those that come with GHC.
> 
> Too late. We had a stable link, I used it, Google used it, blog posts
> were written that linked to it, I've emailed my wife links to it, I've
> put them in Word documents, I've posted them on internal intranets.
> You can't create a link, put content behind it, then move the content
> - it just breaks the whole web.

The .../latest/... URLs have always been unstable, by definition.
Functions might move between modules, modules might appear and
disappear, entire libraries might be added or removed, the format of
internal anchor names might change, etc. I don't think it makes sense
for hoogle to point to them.

We could add redirects base/* -> base-4.2.0.0/* etc now, but we'd have
to keep it up-to-date after each release. We could probably make a small
shell script to do so, so maybe that would be the best plan.

On the other hand, we might be better off just removing the latest/
link. People looking for library docs would be better served by a
Haskell Platform doc page anyway. We'd need to work out what to do with
the links in the GHC docs, though.

> I also think it's a bad idea
> for Hoogle to link off to different documentation from the rest of
> Haskell, it's just not a good idea to fragment the Hoogle universe
> from the rest of the docs.

You could also use e.g. the
    http://haskell.org/ghc/docs/6.12.1/html/libraries/index.html
docs, which are stable.


Thanks
Ian

From marlowsd at gmail.com  Tue Dec 29 16:38:32 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue Dec 29 16:11:56 2009
Subject: hsc2hs and base
In-Reply-To: <c290c4f20912271259t490cd014wb9d6ccc13744fa93@mail.gmail.com>
References: <c290c4f20912271055n5193bb6dl2eb03bd736b9b7cb@mail.gmail.com>
	<c290c4f20912271259t490cd014wb9d6ccc13744fa93@mail.gmail.com>
Message-ID: <4B3A76D8.4050806@gmail.com>

On 27/12/09 20:59, Bryan O'Sullivan wrote:
> On Sun, Dec 27, 2009 at 10:55 AM, Bryan O'Sullivan <bos@serpentine.com
> <mailto:bos@serpentine.com>> wrote:
>
>     Is it licit to have source files in base depend on preprocessing by
>     hsc2hs? My suspicion is "no", but I want to be sure.
>
> Never mind, I found a ".hsc" source file in base, so it must be okay
> after all :-)

hsc2hs in base leads to problems with bootstrapping from HC files, so in 
the past we've tried to avoid it.  However, there are .hsc files in 
other packages that also cause problems, so we really need to solve this 
problem another way (probably by processing .hsc files on the target 
system when bootstrapping).

Upshot: don't worry about adding more .hsc files to base.

Cheers,
	Simon
From marlowsd at gmail.com  Tue Dec 29 16:55:54 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue Dec 29 16:29:14 2009
Subject: [Haskell-beginners] Performance of parallel mergesort
In-Reply-To: <200912281901.29328.jon@ffconsultancy.com>
References: <200912232114.24493.jon@ffconsultancy.com>	<200912280319.58918.jon@ffconsultancy.com>	<2608b8a80912280456y56d89b8tdc3b9e0ddcc0c556@mail.gmail.com>
	<200912281901.29328.jon@ffconsultancy.com>
Message-ID: <4B3A7AEA.4020307@gmail.com>

On 28/12/09 19:01, Jon Harrop wrote:
> On Monday 28 December 2009 12:56:17 Yitzchak Gale wrote:
>> This discussion definitely does not belong on the
>> Haskell-Beginners list. Besides not being a topic
>> for beginners, being there is keeping it under the
>> radar of many or most of the people who work on
>> these things in Haskell.
>>
>> I am moving the discussion to the GHC users list,
>> as suggested by Antoine. For those joining us in
>> progress, the first part of the thread starts here:
>>
>> http://www.haskell.org/pipermail/beginners/2009-December/003045.html
>
> I am not familiar with the GHC users list but is this discussion about basic
> parallelism really more relevant here? The interesting bits aren't GHC
> specific...

Discussion about support for parallelism in GHC is very on-topic here. 
Parallelism is not part of the Haskell language per se, and although the 
basic par/pseq are not implementation-specific, using them effectively 
may require knowing something about the implementation.  For instance, 
in GHC 6.12 we reduced some overheads and made it possible to 
parallelise some fine-grained parallel problems that previously resulted 
in slowdown on a multicore.

(I'll respond to the particular issues raised in the earlier message 
later, I'm still on holiday right now)

> Also, is this list censored like the Haskell Cafe or is it open?

Haskell lists are only ever moderated on an ad-hoc basis as necessary. 
We've never used moderation on this particular list.

Cheers,
	Simon
From marlowsd at gmail.com  Tue Dec 29 17:01:45 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue Dec 29 16:35:06 2009
Subject: Where did the GHC API go?
In-Reply-To: <3B417606-D9E7-4775-938C-C41EACBF3575@cs.york.ac.uk>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>	<bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com>	<4B2F6C30.3080705@gmail.com>	<404396ef0912231334p37435e89q6e245841844b24fa@mail.gmail.com>	<20091224141815.GC5781@matrix.chaos.earth.li>	<404396ef0912271024v498b3dbo8d47b42bbdc4b323@mail.gmail.com>
	<3B417606-D9E7-4775-938C-C41EACBF3575@cs.york.ac.uk>
Message-ID: <4B3A7C49.6000701@gmail.com>

On 28/12/09 11:06, Malcolm Wallace wrote:
>> Too late. We had a stable link, I used it, Google used it, blog posts
>> were written that linked to it, I've emailed my wife links to it, I've
>> put them in Word documents, I've posted them on internal intranets.
>> You can't create a link, put content behind it, then move the content
>> - it just breaks the whole web.
>
> And incidentally, the _ghc_docs_ themselves continue to use these stable
> links to library docs, most of which are currently broken.
>
> All of the following links from documentation for ghc-6.12.1 give a 404
> Not Found. (I do not claim the list is exhaustive.)

This is a good point.  These links are relative (unless I'm mistaken). 
they aren't pointing to the "latest" docs specifically.  It would be 
onerous to have to update these links every time we bump a library 
version number.

Ian - I think we should use the symlinks you suggested in your other 
message.

I agree that linking to "latest" is/was a bad idea.  The fact remains 
that it's done all over the place, and we can't fix that now.  We should 
probably stop Google from indexing those pages, as that is probably the 
source of most of the links.

Cheers,
	Simon
From marlowsd at gmail.com  Wed Dec 30 05:44:54 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed Dec 30 05:18:16 2009
Subject: GHC.Prim.ByteArray# - confusing documentation
In-Reply-To: <694519c50912241518p3ab50470m5d544fd5235abf1@mail.gmail.com>
References: <694519c50912241518p3ab50470m5d544fd5235abf1@mail.gmail.com>
Message-ID: <4B3B2F26.3010504@gmail.com>

On 24/12/09 23:18, Antoine Latter wrote:
> Folks,
>
> I found some of the documentation in GHC.Prim confusing - so I thought
> I'd share. The documentation for the ByteArray# type[1] explains
> that's it's a raw region in memory that also remembers it's size.
>
> Consequently I expected sizeOfByteArray# to return the same number
> that I passed in to newByteArray#. But it doesn't - It returned
> however much it decided to allocate, which on my platform is always a
> multiple of four bytes.
>
> This is something which could be clarified in the documentation.

Thanks, I'll fix the docs.

Cheers,
	Simon
From bulat.ziganshin at gmail.com  Wed Dec 30 06:09:28 2009
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Wed Dec 30 05:42:52 2009
Subject: GHC.Prim.ByteArray# - confusing documentation
In-Reply-To: <4B3B2F26.3010504@gmail.com>
References: <694519c50912241518p3ab50470m5d544fd5235abf1@mail.gmail.com>
	<4B3B2F26.3010504@gmail.com>
Message-ID: <101998021.20091230140928@gmail.com>

Hello Simon,

Wednesday, December 30, 2009, 1:44:54 PM, you wrote:

>> Consequently I expected sizeOfByteArray# to return the same number
>> that I passed in to newByteArray#. But it doesn't - It returned
>> however much it decided to allocate, which on my platform is always a
>> multiple of four bytes.
>>
>> This is something which could be clarified in the documentation.

> Thanks, I'll fix the docs.

btw, is it possible to fix the behavior? it will reduce overhead for
storing small strings 


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From marlowsd at gmail.com  Wed Dec 30 06:34:08 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed Dec 30 06:07:27 2009
Subject: [Haskell-beginners] Performance of parallel mergesort
In-Reply-To: <2608b8a80912280456y56d89b8tdc3b9e0ddcc0c556@mail.gmail.com>
References: <200912232114.24493.jon@ffconsultancy.com>	<200912261956.11617.jon@ffconsultancy.com>	<4B37CA13.7050807@blacksapphire.com>	<200912280319.58918.jon@ffconsultancy.com>
	<2608b8a80912280456y56d89b8tdc3b9e0ddcc0c556@mail.gmail.com>
Message-ID: <4B3B3AB0.5070004@gmail.com>

On 28/12/09 12:56, Yitzchak Gale wrote:

> On Mon, Dec 28, 2009 at 5:19 AM, Jon Harrop wrote:
>> On Sunday 27 December 2009 20:56:51 Stephen Blackheath wrote:
>>> Jon Harrop wrote:
>>>> This is something that concerns me. Lots of discussions of parallelism,
>>>> including the Haskell literature I have read, neglect this critical
>>>> problem
>>>> of making sure that more time is spent doing useful work than spawning
>>>> tasks
>>>> (sparks). How is this solved in Haskell? Do you just put magic numbers in
>>>> that work on the machine you're currently using?
>>>
>>> It is simply not true that Haskell literature neglects the question of
>>> spark granularity - this is very basic and is always covered. Read
>>> "Real World Haskell" (available free online).  There's no 'magic
>>> number'. You must explicitly write your code to give the right granule
>>> size.
>>
>> There is no "right granule" size. That's the whole point: the optimum is a
>> function of the machine. If you hardcode the granularity then your code isn't
>> future proof and isn't portable.

While that's true, in practice it's often not a problem.

Sometimes you can pick a granularity that is small enough to give you 
thousands of parallel tasks, each of which is plenty big enough to 
outweight the overheads of task creation (which are very low in GHC 
anyway).  Scaling to thousands of cores is likely to be good enough for 
quite a while.

You can always pick a granularity based on the number of cores (GHC 
gives you access to that as GHC.Conc.numCapabilities).

Or, the program might have a natural granularity, which leaves you 
little room for parallelising it in a different way.

>> Moreover, their approach of subdividing a fixed number of times is suboptimal
>> because it inhibits load balancing.

If you create enough tasks, then load balancing works just fine.  GHC 
(in 6.12.1) uses work-stealing for load balancing, incedentally.

>> Later, about parallelized IO, they give the code:
>>
>>   chunkedReadWith :: (NFData a) =>
>>                     ([LB.ByteString] ->  a) ->  FilePath ->  IO a
>>   chunkedReadWith func path =
>>       withChunks (lineChunks (numCapabilities * 4)) func path
>>
>> where "4" is one magic number that gets multiplied by the magic number the
>> user supplied via the +RTS -N<n>  command-line option.
>>
>> They make no attempt to adapt the granularity to the machine at all and rely
>> entirely upon magic numbers. Consequently, their parallel sort that got a 25%
>> speedup on two cores achieves a 30% slowdown on my 8 core.

I'd recommend trying againn with 6.12.1.  You might also want to 
experiment with the parallel GC settings - the defaults settings aren't 
perfect for every program.

>>> I don't know the exact cost of sparking, but in my experience it
>>> is quite small - so - as long as your granule is doing *some* real work,
>>> it should speed up.
>>
>> Can you quantify it, e.g. How many FLOPS?

you can't measure time in FLOPS.  But my guess is that a spark could be 
as low as 20 cycles if everything is in the L1 cache and the branches 
are predicted correctly (there are 2 function calls, 2 branches, and 
about 3 memory references, we could inline to remove the function 
calls). It's just a push onto a lock-free work-stealing queue, and 
involves no atomic instructions.

>>> 2. The defaults generally work better than giving huge heap sizes.  Your
>>> -K100000000 - maximum heap size per thread - will either do nothing or
>>> cause an artificial slowdown (I have observed this with the minimum heap
>>> size option).  Don't use it, unless experimentation proves it makes
>>> things better.

Yes, this is because cache use and locality become more important with 
multicore execution.  The default GC settings use a 512KB young 
generation and we use locality-optimised parallel GC in 6.12.1.

>> On the contrary, the Haskell program dies without it:
>>
>> $ time ./mergesort +RTS -N8
>> Stack space overflow: current size 8388608 bytes.

Don't confuse stack size (-K) with heap size (-H or -M).  The stack size 
is just a limit and shouldn't have any effect on performance; the stack 
itself grows dynamically.

>> Its says 78.5% GC time (with GHC 6.10).

A clear sign that there's a problem.  I haven't tried parallelising 
merge sort recently, but it has been a tricky one to parallelise with 
GHC in the past due to the amount of GC going on.

>>> 5. There seems to be a scalability problem with the parallel gc for
>>> larger numbers of cores (namely 8).  I am guessing somewhat, but my
>>> experiments tend to confirm the issue raised in Simon Marlow's (the
>>> implementor of GHC parallelization) recent paper that it's to do with
>>> "stopping the world" for gc.
>>
>> Do you mean this bug:
>>
>>   http://hackage.haskell.org/trac/ghc/ticket/3553

Probably, yes.  I'm working on indepdendent young-generation collection 
at the moment which will fix that bug properly.  For now, make sure your 
cores are all available (nice and +RTS -qa are useful here), and on 8 
core machines I usually drop back to -N7.

>>> If GHC's lack of perfection at this point in time makes Haskell "look
>>> bad" I don't mind.  I am not selling anything, so the reader at least
>>> knows they're getting the truth.  I see this as one of the great
>>> advantages of open source.

Quite, and I'm interested in looking at parallel programs that don't 
speed up, particularly if the lack of speedup is due to a bottleneck in 
the runtime or GC.

>> My original intent was to test a claim someone made: that mergesort in Haskell
>> is competitively performant and trivially parallelized.

I wouldn't claim that list sorting is trivially parallelized at this 
stage.  There are problems that are: often you can insert a parList or a 
parBuffer and get a speedup, and lots of people have had good 
experiences using concurrency to get parallel speedup.

The problem with list sorting is that you have to be careful to get the 
forcing and sparking right, and even then you have to be careful that 
the forcing itself hasn't added too much overhead (people often forget 
to compare against the sequential version, not the parallel version 
running on one CPU).  I think I would try to rewrite it so that the 
subtasks only return when their results are fully evaluated, to avoid 
the extra forcing.

I wonder if it would be possible to write some kind of generic "divide 
and conquer" Strategy that would help for this kind of problem.

Cheers,
	Simon
From marlowsd at gmail.com  Wed Dec 30 06:37:15 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed Dec 30 06:10:35 2009
Subject: ANN: Happstack 0.4.1
In-Reply-To: <694519c50912211933p257746abgca00c46a443264ac@mail.gmail.com>
References: <54342.1261377119@n-heptane.com>
	<694519c50912211933p257746abgca00c46a443264ac@mail.gmail.com>
Message-ID: <4B3B3B6B.3010102@gmail.com>

On 22/12/09 03:33, Antoine Latter wrote:
> On Mon, Dec 21, 2009 at 6:31 AM,<jeremy@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
From marlowsd at gmail.com  Wed Dec 30 06:47:13 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed Dec 30 06:20:32 2009
Subject: GHC.Prim.ByteArray# - confusing documentation
In-Reply-To: <101998021.20091230140928@gmail.com>
References: <694519c50912241518p3ab50470m5d544fd5235abf1@mail.gmail.com>
	<4B3B2F26.3010504@gmail.com> <101998021.20091230140928@gmail.com>
Message-ID: <4B3B3DC1.4040409@gmail.com>

On 30/12/09 11:09, Bulat Ziganshin wrote:
> Hello Simon,
>
> Wednesday, December 30, 2009, 1:44:54 PM, you wrote:
>
>>> Consequently I expected sizeOfByteArray# to return the same number
>>> that I passed in to newByteArray#. But it doesn't - It returned
>>> however much it decided to allocate, which on my platform is always a
>>> multiple of four bytes.
>>>
>>> This is something which could be clarified in the documentation.
>
>> Thanks, I'll fix the docs.
>
> btw, is it possible to fix the behavior? it will reduce overhead for
> storing small strings

It would be possible yes.  When the RTS needs to know the size of the 
array in words it would have to do a calculation, so you'd have to find 
all the places in the RTS that do this (probably only a handful, as most 
of them go through the arr_words_sizeW() inline function).

I don't plan to do this right now.  If someone else wants to tackle it 
then please go ahead, it'd be a fun afternoon hack.

Cheers,
	Simon
From marlowsd at gmail.com  Wed Dec 30 06:57:26 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed Dec 30 06:30:45 2009
Subject: GHC-6.12.1: broken configure
In-Reply-To: <20091224140141.GA5781@matrix.chaos.earth.li>
References: <cc557aab0912181837u6829a3edp6d4901794ec80923@mail.gmail.com>
	<9436bffe0912220459m3150a3bbjbecb2940e9e222d6@mail.gmail.com>
	<4B329074.7020106@gmail.com>
	<20091224140141.GA5781@matrix.chaos.earth.li>
Message-ID: <4B3B4026.1030700@gmail.com>

On 24/12/09 14:01, Ian Lynagh wrote:
> On Wed, Dec 23, 2009 at 09:49:40PM +0000, Simon Marlow wrote:
>> On 22/12/09 12:59, Jens Petersen wrote:
>>> 2009/12/19 Kirill A. Shutemov<kirill@shutemov.name>:
>>>> I want to build ghc for i586-alt-linux-gnu.
>>>
>>> Why? :)
>>>
>>>> Why do not use config.guess to guess correct host/target/build
>>>> instead of reinvent wheel?
>>>
>>> While I sympathize (I gave up long ago trying to use  host/target/build
>>> with ghc - we use them by default in Fedora) - I guess the short answer
>>> is something like cross-compiling is not supported or the effort
>>> to support host/target/build is more than the win?  But those
>>> are just my assumptions - I leave a real answer to a ghc buildsystem
>>> expert.
>>>
>>> If you really want a fix searching trac and opening a ticket would be
>>> more effective probably.
>>
>> I personally think we should revert to using the standard config.guess
>> and normalising the result as we used to.
>
> I don't see the advantage. Before we had 484 lines of case expression in
> configure.ac, which now and again needed tweaking to keep up with
> changes in configure.
>
> Now we don't need to be told the platform that we are building for, as
> we just ask the bootstrapping compiler what platform it builds for, and
> we only support building for that platform anyway. If you specify a
> different platform then the build will break. I don't know if the
> original poster means that he wants i586 as opposed to e.g. i386 (to
> make use of newer instructions or to optimise differently), but if so we
> don't do anything different for different subarches.
>
> As far as I can see, the only reason we would need to support all the
> platform values that configure supports is if/when we are going to
> support cross-compilation.

Yes, that's the main reason. Eventually we will want to do 
cross-compilation, so I think it makes sense to retain the possibility. 
There's also the reason that people are building GHC in environments 
that expect to be able to pass GNU-standard --host options to configure.

The normalisation doesn't necessarily need to be as long or complicated 
as it was before: we could normalise the machine and os separately, and 
ignore the vendor.  We should check that the bootstrapping GHC agrees 
with the build platform.

Cheers,
	Simon
From marlowsd at gmail.com  Wed Dec 30 09:38:56 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed Dec 30 09:12:14 2009
Subject: Where did the GHC API go?
In-Reply-To: <20091229114317.GA14270@matrix.chaos.earth.li>
References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com>	<bf0b20a90912201617g1d3ed127kd89c09f5bdd9ddb7@mail.gmail.com>	<bf0b20a90912201618y1d9c9be0k98c678724593f234@mail.gmail.com>	<4B2F6C30.3080705@gmail.com>	<404396ef0912231334p37435e89q6e245841844b24fa@mail.gmail.com>	<20091224141815.GC5781@matrix.chaos.earth.li>	<404396ef0912271024v498b3dbo8d47b42bbdc4b323@mail.gmail.com>
	<20091229114317.GA14270@matrix.chaos.earth.li>
Message-ID: <4B3B6600.2000107@gmail.com>

On 29/12/09 11:43, Ian Lynagh wrote:

> You could also use e.g. the
>      http://haskell.org/ghc/docs/6.12.1/html/libraries/index.html
> docs, which are stable.

I've added symlinks for now.

Cheers,
	Simon
From aslatter at gmail.com  Thu Dec 31 10:19:36 2009
From: aslatter at gmail.com (Antoine Latter)
Date: Thu Dec 31 09:52:49 2009
Subject: Building GHC 6.12 with GHC 6.12 + alex
Message-ID: <694519c50912310719v7d27943do81fdc970da2bd5fe@mail.gmail.com>

Folks,

I've run into trouble building GHC 6.12 with alex built from GHC 6.12:

"/Users/alatter/usr/bin/alex"  -g compiler/parser/Lexer.x -o
compiler/stage1/build/Lexer.hs
alex: compiler/parser/Lexer.x: hGetContents: invalid argument (Illegal
byte sequence)

however things like:

ghci> readFile "compiler/parser/Lexer.x"

apear to work just fine. Has anyone else seen this? Has anyone else
succeeded in this?

This is on Mac OS X 10.6, running on Intel Core 2 Duo. I'm trying to
compile a recent pull of the 6.12 branch.

Thanks,
Antoine
From aslatter at gmail.com  Thu Dec 31 13:26:44 2009
From: aslatter at gmail.com (Antoine Latter)
Date: Thu Dec 31 12:59:58 2009
Subject: Building GHC 6.12 with GHC 6.12 + alex
In-Reply-To: <694519c50912310719v7d27943do81fdc970da2bd5fe@mail.gmail.com>
References: <694519c50912310719v7d27943do81fdc970da2bd5fe@mail.gmail.com>
Message-ID: <694519c50912311026i3c94fa5av8e22cd4cdb57b92@mail.gmail.com>

On Thu, Dec 31, 2009 at 9:19 AM, Antoine Latter <aslatter@gmail.com> wrote:
> Folks,
>
> I've run into trouble building GHC 6.12 with alex built from GHC 6.12:
>
> "/Users/alatter/usr/bin/alex" ?-g compiler/parser/Lexer.x -o
> compiler/stage1/build/Lexer.hs
> alex: compiler/parser/Lexer.x: hGetContents: invalid argument (Illegal
> byte sequence)
>
> however things like:
>
> ghci> readFile "compiler/parser/Lexer.x"
>
> apear to work just fine. Has anyone else seen this? Has anyone else
> succeeded in this?
>
> This is on Mac OS X 10.6, running on Intel Core 2 Duo. I'm trying to
> compile a recent pull of the 6.12 branch.
>

I've progressed to an advanced state of disfunction. I've patched alex
src/Main.hs to use the following:

#if __GLASGOW_HASKELL__ >= 612
readFile :: FilePath -> IO String
readFile file = do
  h <- openFile file ReadMode
  hSetEncoding h utf8
  hGetContents h
#endif

Now, I get the following error on the same file:

$ ~/src/alex/dist/build/alex/alex -g compiler/parser/Lexer.x -o compiler/stage1/
build/Lexer.hs
alex: compiler/stage1/build/Lexer.hs: commitAndReleaseBuffer: invalid
argument (Illegal byte sequence)
From aslatter at gmail.com  Thu Dec 31 13:35:46 2009
From: aslatter at gmail.com (Antoine Latter)
Date: Thu Dec 31 13:08:58 2009
Subject: Building GHC 6.12 with GHC 6.12 + alex
In-Reply-To: <694519c50912311026i3c94fa5av8e22cd4cdb57b92@mail.gmail.com>
References: <694519c50912310719v7d27943do81fdc970da2bd5fe@mail.gmail.com>
	<694519c50912311026i3c94fa5av8e22cd4cdb57b92@mail.gmail.com>
Message-ID: <694519c50912311035u202556f8jfb71cbf2cab308fc@mail.gmail.com>

On Thu, Dec 31, 2009 at 12:26 PM, Antoine Latter <aslatter@gmail.com> wrote:
> On Thu, Dec 31, 2009 at 9:19 AM, Antoine Latter <aslatter@gmail.com> wrote:
>> Folks,
>>
>> I've run into trouble building GHC 6.12 with alex built from GHC 6.12:
>>
>> "/Users/alatter/usr/bin/alex" ?-g compiler/parser/Lexer.x -o
>> compiler/stage1/build/Lexer.hs
>> alex: compiler/parser/Lexer.x: hGetContents: invalid argument (Illegal
>> byte sequence)
>>
>> however things like:
>>
>> ghci> readFile "compiler/parser/Lexer.x"
>>
>> apear to work just fine. Has anyone else seen this? Has anyone else
>> succeeded in this?
>>
>> This is on Mac OS X 10.6, running on Intel Core 2 Duo. I'm trying to
>> compile a recent pull of the 6.12 branch.
>>
>
> I've progressed to an advanced state of disfunction. I've patched alex
> src/Main.hs to use the following:
>
> #if __GLASGOW_HASKELL__ >= 612
> readFile :: FilePath -> IO String
> readFile file = do
> ?h <- openFile file ReadMode
> ?hSetEncoding h utf8
> ?hGetContents h
> #endif
>
> Now, I get the following error on the same file:
>
> $ ~/src/alex/dist/build/alex/alex -g compiler/parser/Lexer.x -o compiler/stage1/
> build/Lexer.hs
> alex: compiler/stage1/build/Lexer.hs: commitAndReleaseBuffer: invalid
> argument (Illegal byte sequence)
>

Further details:

If I patch alex to explicitly set the encoding whenever it reads from
or writes to a file, all of these problems go away. I'm not really
sure why alex needs this and nothing else does, but so it goes.

Is there a separate bug tracker for alex, or should this just be a GHC bug?

Antoine
From marlowsd at gmail.com  Thu Dec 31 14:47:37 2009
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu Dec 31 14:20:53 2009
Subject: Building GHC 6.12 with GHC 6.12 + alex
In-Reply-To: <694519c50912311035u202556f8jfb71cbf2cab308fc@mail.gmail.com>
References: <694519c50912310719v7d27943do81fdc970da2bd5fe@mail.gmail.com>	
	<694519c50912311026i3c94fa5av8e22cd4cdb57b92@mail.gmail.com>
	<694519c50912311035u202556f8jfb71cbf2cab308fc@mail.gmail.com>
Message-ID: <4B3CFFD9.2050205@gmail.com>

On 31/12/09 18:35, Antoine Latter wrote:
> On Thu, Dec 31, 2009 at 12:26 PM, Antoine Latter<aslatter@gmail.com>  wrote:
>> On Thu, Dec 31, 2009 at 9:19 AM, Antoine Latter<aslatter@gmail.com>  wrote:
>>> Folks,
>>>
>>> I've run into trouble building GHC 6.12 with alex built from GHC 6.12:
>>>
>>> "/Users/alatter/usr/bin/alex"  -g compiler/parser/Lexer.x -o
>>> compiler/stage1/build/Lexer.hs
>>> alex: compiler/parser/Lexer.x: hGetContents: invalid argument (Illegal
>>> byte sequence)
>>>
>>> however things like:
>>>
>>> ghci>  readFile "compiler/parser/Lexer.x"
>>>
>>> apear to work just fine. Has anyone else seen this? Has anyone else
>>> succeeded in this?
>>>
>>> This is on Mac OS X 10.6, running on Intel Core 2 Duo. I'm trying to
>>> compile a recent pull of the 6.12 branch.
>>>
>>
>> I've progressed to an advanced state of disfunction. I've patched alex
>> src/Main.hs to use the following:
>>
>> #if __GLASGOW_HASKELL__>= 612
>> readFile :: FilePath ->  IO String
>> readFile file = do
>>   h<- openFile file ReadMode
>>   hSetEncoding h utf8
>>   hGetContents h
>> #endif
>>
>> Now, I get the following error on the same file:
>>
>> $ ~/src/alex/dist/build/alex/alex -g compiler/parser/Lexer.x -o compiler/stage1/
>> build/Lexer.hs
>> alex: compiler/stage1/build/Lexer.hs: commitAndReleaseBuffer: invalid
>> argument (Illegal byte sequence)
>>
>
> Further details:
>
> If I patch alex to explicitly set the encoding whenever it reads from
> or writes to a file, all of these problems go away. I'm not really
> sure why alex needs this and nothing else does, but so it goes.
>
> Is there a separate bug tracker for alex, or should this just be a GHC bug?

Thanks for looking into this - yes Alex needs to explicitly use utf8 for 
reading and writing files.  Those of us using a utf-8 locale probably 
wouldn't have noticed the problem, what's your locale set to?

If you can send me the patch, that will save me time figuring it out for 
myself. Alex doesn't have a bug tracker, but you're welcome to use GHC's 
if you want.

Cheers,
	Simon
From aslatter at gmail.com  Thu Dec 31 15:08:08 2009
From: aslatter at gmail.com (Antoine Latter)
Date: Thu Dec 31 14:41:21 2009
Subject: Building GHC 6.12 with GHC 6.12 + alex
In-Reply-To: <4B3CFFD9.2050205@gmail.com>
References: <694519c50912310719v7d27943do81fdc970da2bd5fe@mail.gmail.com>
	<694519c50912311026i3c94fa5av8e22cd4cdb57b92@mail.gmail.com>
	<694519c50912311035u202556f8jfb71cbf2cab308fc@mail.gmail.com>
	<4B3CFFD9.2050205@gmail.com>
Message-ID: <694519c50912311208j57c86ec0mf5ed7edff7d4e65a@mail.gmail.com>

On Thu, Dec 31, 2009 at 1:47 PM, Simon Marlow <marlowsd@gmail.com> wrote:
> On 31/12/09 18:35, Antoine Latter wrote:
>>
>>
>> Further details:
>>
>> If I patch alex to explicitly set the encoding whenever it reads from
>> or writes to a file, all of these problems go away. I'm not really
>> sure why alex needs this and nothing else does, but so it goes.
>>
>> Is there a separate bug tracker for alex, or should this just be a GHC
>> bug?
>
> Thanks for looking into this - yes Alex needs to explicitly use utf8 for
> reading and writing files. ?Those of us using a utf-8 locale probably
> wouldn't have noticed the problem, what's your locale set to?
>
> If you can send me the patch, that will save me time figuring it out for
> myself. Alex doesn't have a bug tracker, but you're welcome to use GHC's if
> you want.
>
> Cheers,
> ? ? ? ?Simon
>

I have the following environment variable set:

__CF_USER_TEXT_ENCODING=0x1F5:0:0

But I have no idea what that means. Presumably something other than utf8.

The alex patch is attached, but I have not tested it on anything other
than GHC 6.12.

Antoine
-------------- next part --------------
A non-text attachment was scrubbed...
Name: utf8_ghc612.dpatch
Type: application/octet-stream
Size: 5019 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091231/8e70f779/utf8_ghc612.obj