Re: ANNOUNCE: GHC 7.10.1 Release Candidate 3

[Neil Mitchell]

Confirmed, thanks a lot!

On Tue, Mar 17, 2015 at 1:47 PM, Austin Seipp  wrote:
> Neil, this has been fixed.
>
> On Tue, Mar 17, 2015 at 7:52 AM, Neil Mitchell  wrote:
>> All of the mingw links give me 403 forbidden errors. Do they have
>> permission issues?
>>
>> Thanks, Neil
>>
>>
>> On Mon, Mar 16, 2015 at 8:30 PM, Austin Seipp  wrote:
>>> We are pleased to announce the third release candidate for GHC 7.10.1:
>>>
>>> https://downloads.haskell.org/~ghc/7.10.1-rc3
>>> https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/
>>>
>>> This includes the source tarball and bindists for Windows and Debian
>>> Linux. FreeBSD, CentOS and Mac OS X binary distributions will follow
>>> soon. These binaries and tarballs have an accompanying
>>> SHA256SUMS file signed by my GPG key id (0x3B58D86F).
>>>
>>> We plan to make the 7.10.1 final release at the end of this week - so
>>> please test as much as possible; bugs are much cheaper if we find them
>>> before the release!
>>>
>>> The list of issues we plan on fixing can always be found in an
>>> up-to-date form here:
>>> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1
>>>
>>> --
>>> Regards,
>>>
>>> Austin Seipp, Haskell Consultant
>>> Well-Typed LLP, http://www.well-typed.com/
>>> ___
>>> ghc-devs mailing list
>>> ghc-d...@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 3

[Neil Mitchell]

All of the mingw links give me 403 forbidden errors. Do they have
permission issues?

Thanks, Neil


On Mon, Mar 16, 2015 at 8:30 PM, Austin Seipp  wrote:
> We are pleased to announce the third release candidate for GHC 7.10.1:
>
> https://downloads.haskell.org/~ghc/7.10.1-rc3
> https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/
>
> This includes the source tarball and bindists for Windows and Debian
> Linux. FreeBSD, CentOS and Mac OS X binary distributions will follow
> soon. These binaries and tarballs have an accompanying
> SHA256SUMS file signed by my GPG key id (0x3B58D86F).
>
> We plan to make the 7.10.1 final release at the end of this week - so
> please test as much as possible; bugs are much cheaper if we find them
> before the release!
>
> The list of issues we plan on fixing can always be found in an
> up-to-date form here:
> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Error while installing new packages with GHC 7.4.1

[Neil Mitchell]

Hi Antoras,

My suspicion is you've ended up with corrupted packages in your
package database - nothing to do with Hoogle. I suspect trying to
install parsec-3.1.2 directly would give the same error message. Can
you try ghc-pkg list, and at the bottom it will probably say something
like:

The following packages are broken, either because they have a problem
listed above, or because they depend on a broken package.
warp-1.1.0

I often find ghc-pkg unregister  --force on all the packages
cleans them up enough, but someone else may have a better suggestion.

Thanks, Neil

On Fri, Mar 2, 2012 at 12:02 AM, Antoras  wrote:
> Hi Neil,
>
> thanks for your effort. But it still does not work. The old errors
> disappeared, but new ones occur.
>
> Maybe I have not yet the most current versions:
>
>
> $ ghc --version
> The Glorious Glasgow Haskell Compilation System, version 7.4.1
>
> $ cabal --version
> cabal-install version 0.10.2
> using version 1.10.1.0 of the Cabal library
>
> This seems to be the most current version of Cabal. The command 'cabal info
> cabal' brings: "Versions installed: 1.14.0" but not 1.15
>
> An extract of the error messages:
>
> [...]
> Configuring parsec-3.1.2...
> Preprocessing library parsec-3.1.2...
> Building parsec-3.1.2...
> : cannot satisfy -package-id
> text-0.11.1.13-9b63b6813ed4eef16b7793151cdbba4d:
> text-0.11.1.13-9b63b6813ed4eef16b7793151cdbba4d is unusable due to missing
> or recursive dependencies:
> deepseq-1.3.0.0-a73ec930018135e0dc0a1a3d29c74c88
>
> (use -v for more information)
> : cannot satisfy -package Cabal-1.14.0:
> Cabal-1.14.0-5875475606fe70ef919bbc055077d744 is unusable due to missing or
> recursive dependencies:
> array-0.4.0.0-59d1cc0e7979167b002f021942d60f46
> containers-0.4.2.1-cfc6420ecc2194c9ed977b06bdfd9e69
> directory-1.1.0.2-07820857642f1427d8b3bb49f93f97b0
> process-1.1.0.1-18dadd8ad5fc640f55a7afdc7aace500
> (use -v for more information)
> [...]
>
>
> On Thu 01 Mar 2012 11:06:43 PM CET, Neil Mitchell wrote:
>>
>> Hi Antoras,
>>
>> I've just released Hoogle 4.2.9, which allows Cabal 1.15, so hopefully
>> will install correctly for you.
>>
>> Thanks, Neil
>>
>> On Thu, Mar 1, 2012 at 5:02 PM, Neil Mitchell
>>  wrote:
>>>
>>> Hi Antoras,
>>>
>>> The darcs version of Hoogle has had a more permissive dependency for a
>>> few
>>> weeks. Had I realised the dependency caused problems I'd have released a
>>> new
>>> version immediately! As it stands, I'll release a new version in about 4
>>> hours. If you can't wait that long, try darcs get
>>> http://code.haskell.org/hoogle
>>>
>>> Thanks, Neil
>>>
>>>
>>> On Thursday, March 1, 2012, Antoras wrote:
>>>>
>>>>
>>>> Ok, interesting info. But how to solve the problem now? Should I contact
>>>> the author of Hoogle and ask him about how solving this?
>>>>
>>>>
>>>> On 03/01/2012 02:02 AM, Albert Y. C. Lai wrote:
>>>>>
>>>>>
>>>>> On 12-02-29 06:04 AM, Antoras wrote:
>>>>>>
>>>>>>
>>>>>> I don't know where the dependency to array-0.3.0.3 comes from. Is it
>>>>>> possible to get more info from cabal than -v?
>>>>>
>>>>>
>>>>>
>>>>> hoogle-4.2.8 has "Cabal>= 1.8&&  <  1.13", this brings in Cabal-1.12.0.
>>>>>
>>>>> Cabal-1.12.0 has "array>= 0.1&&  <  0.4", this brings in array-0.3.0.3.
>>>>>
>>>>>
>>>>> It is a mess to have 2nd instances of libraries that already come with
>>>>> GHC, unless you are an expert in knowing and avoiding the treacherous
>>>>> consequences. See my
>>>>> http://www.vex.net/~trebla/haskell/sicp.xhtml
>>>>>
>>>>> It is possible to fish the output of "cabal install --dry-run -v3
>>>>> hoogle"
>>>>> for why array-0.3.0.3 is brought in. It really is fishing, since the
>>>>> output
>>>>> is copious and of low information density. Chinese idiom: needle in
>>>>> ocean
>>>>> (haystack is too easy). Example:
>>>>>
>>>>> "selecting hoogle-4.2.8 (hackage) and discarding Cabal-1.1.6, 1.2.1,
>>>>> 1.2.2.0,
>>>>> 1.2.3.0, 1.2.4.0, 1.4.0.0, 1.4.0.1, 1.4.0.2, 1.6.0.1, 1.6.0.2, 1.6.0.3,
>>>>> 1.14.0, blaze-builder-0.1, case-insensitive-0.1,"
>>>>>
>>>>> We see that selecting hoogle-4.2.8 causes ruling out Cabal 1.14.0
>>>>>
>>>>> Similarly, the line for "selecting Cabal-1.12.0" mentions ruling out
>>>>> array-0.4.0.0
>>>>>
>>>>> ___
>>>>> Glasgow-haskell-users mailing list
>>>>> Glasgow-haskell-users@haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>>
>>>>>
>>>>
>>>> ___
>>>> Glasgow-haskell-users mailing list
>>>> Glasgow-haskell-users@haskell.org
>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>>
>

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

Re: Error while installing new packages with GHC 7.4.1

[Neil Mitchell]

Hi Antoras,

I've just released Hoogle 4.2.9, which allows Cabal 1.15, so hopefully
will install correctly for you.

Thanks, Neil

On Thu, Mar 1, 2012 at 5:02 PM, Neil Mitchell  wrote:
> Hi Antoras,
>
> The darcs version of Hoogle has had a more permissive dependency for a few
> weeks. Had I realised the dependency caused problems I'd have released a new
> version immediately! As it stands, I'll release a new version in about 4
> hours. If you can't wait that long, try darcs get
> http://code.haskell.org/hoogle
>
> Thanks, Neil
>
>
> On Thursday, March 1, 2012, Antoras wrote:
>>
>> Ok, interesting info. But how to solve the problem now? Should I contact
>> the author of Hoogle and ask him about how solving this?
>>
>>
>> On 03/01/2012 02:02 AM, Albert Y. C. Lai wrote:
>>>
>>> On 12-02-29 06:04 AM, Antoras wrote:
>>>>
>>>> I don't know where the dependency to array-0.3.0.3 comes from. Is it
>>>> possible to get more info from cabal than -v?
>>>
>>>
>>> hoogle-4.2.8 has "Cabal >= 1.8 && < 1.13", this brings in Cabal-1.12.0.
>>>
>>> Cabal-1.12.0 has "array >= 0.1 && < 0.4", this brings in array-0.3.0.3.
>>>
>>> It is a mess to have 2nd instances of libraries that already come with
>>> GHC, unless you are an expert in knowing and avoiding the treacherous
>>> consequences. See my
>>> http://www.vex.net/~trebla/haskell/sicp.xhtml
>>>
>>> It is possible to fish the output of "cabal install --dry-run -v3 hoogle"
>>> for why array-0.3.0.3 is brought in. It really is fishing, since the output
>>> is copious and of low information density. Chinese idiom: needle in ocean
>>> (haystack is too easy). Example:
>>>
>>> "selecting hoogle-4.2.8 (hackage) and discarding Cabal-1.1.6, 1.2.1,
>>> 1.2.2.0,
>>> 1.2.3.0, 1.2.4.0, 1.4.0.0, 1.4.0.1, 1.4.0.2, 1.6.0.1, 1.6.0.2, 1.6.0.3,
>>> 1.14.0, blaze-builder-0.1, case-insensitive-0.1,"
>>>
>>> We see that selecting hoogle-4.2.8 causes ruling out Cabal 1.14.0
>>>
>>> Similarly, the line for "selecting Cabal-1.12.0" mentions ruling out
>>> array-0.4.0.0
>>>
>>> ___
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users@haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>>
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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

Re: Error while installing new packages with GHC 7.4.1

[Neil Mitchell]

Hi Antoras,

The darcs version of Hoogle has had a more permissive dependency for a few
weeks. Had I realised the dependency caused problems I'd have released a
new version immediately! As it stands, I'll release a new version in about
4 hours. If you can't wait that long, try darcs get
http://code.haskell.org/hoogle

Thanks, Neil

On Thursday, March 1, 2012, Antoras wrote:

> Ok, interesting info. But how to solve the problem now? Should I contact
> the author of Hoogle and ask him about how solving this?
>
>
> On 03/01/2012 02:02 AM, Albert Y. C. Lai wrote:
>
>> On 12-02-29 06:04 AM, Antoras wrote:
>>
>>> I don't know where the dependency to array-0.3.0.3 comes from. Is it
>>> possible to get more info from cabal than -v?
>>>
>>
>> hoogle-4.2.8 has "Cabal >= 1.8 && < 1.13", this brings in Cabal-1.12.0.
>>
>> Cabal-1.12.0 has "array >= 0.1 && < 0.4", this brings in array-0.3.0.3.
>>
>> It is a mess to have 2nd instances of libraries that already come with
>> GHC, unless you are an expert in knowing and avoiding the treacherous
>> consequences. See my
>> http://www.vex.net/~trebla/**haskell/sicp.xhtml
>>
>> It is possible to fish the output of "cabal install --dry-run -v3 hoogle"
>> for why array-0.3.0.3 is brought in. It really is fishing, since the output
>> is copious and of low information density. Chinese idiom: needle in ocean
>> (haystack is too easy). Example:
>>
>> "selecting hoogle-4.2.8 (hackage) and discarding Cabal-1.1.6, 1.2.1,
>> 1.2.2.0,
>> 1.2.3.0, 1.2.4.0, 1.4.0.0, 1.4.0.1, 1.4.0.2, 1.6.0.1, 1.6.0.2, 1.6.0.3,
>> 1.14.0, blaze-builder-0.1, case-insensitive-0.1,"
>>
>> We see that selecting hoogle-4.2.8 causes ruling out Cabal 1.14.0
>>
>> Similarly, the line for "selecting Cabal-1.12.0" mentions ruling out
>> array-0.4.0.0
>>
>> __**_
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-users
>>
>>
>>
> __**_
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: parallelizing ghc

[Neil Mitchell]

Hi Simon,

I have found that a factor of 2 parallelism is required on Linux to
draw with ghc --make. In particular:

GHC --make = 7.688
Shake -j1 = 11.828 (of which 11.702 is spent running system commands)
Shake full -j4 = 7.414 (of which 12.906 is spent running system commands)

This is for a Haskell program which has several bottlenecks, you can
see graph of spawned processes here:
http://community.haskell.org/~ndm/darcs/shake/academic/icfp2012/profile.eps
- everything above the 1 mark is more than one process in parallel, so
it gets to 4 processes, but not all the time - roughly an average of ~
x2 parallelism.

On Windows the story is much worse. If you -j4 then the time spent
executing system commands shoots up from ~15s to around ~25s, since
even on a 4 core machine the contention in the processes is high. I
tried investigating this, checking for things like a locked file (none
I can find), or disk/CPU/memory contention (its basically taking no
system resources), but couldn't find anything.

If you specify -O2 then the parallel performance also goes down - I
suspect because each ghc process needs to read inline information for
packages that are imported multiple times, and ghc --make gets away
with doing that once?

> This looks a bit suspicious.  The Shake build is doing nearly twice as much
> work as the --make build, in terms of CPU time, but because it is getting
> nearly 2x parallelism it comes in a close second.  How many processes is the
> Shake build using?

Shake uses a maximum of the number of processes you specify, it never
exceeds the -j flag - so in the above example it caps out at 4. It is
very good at getting parallelism (I believe it to be perfect, but the
code is 150 lines of IORef twiddling, so I wouldn't guarantee it), and
very safe about never exceeding the cap you specify (I think I can
even prove that, for some value of proof). The profiling makes it easy
to verify these claims after the fact.

Thanks, Neil

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

Re: hoogling GHC

[Neil Mitchell]

Hi Ranjit,

> Is there a command line option that allows one to change the default prefix 
> for the
> URL returned by searches?

No command line option, but you can change the .txt file itself by doing:

@url http://www.haskell.org/ghc/docs/7.0.1/html/libraries/ghc-7.0.1/
@package ghc

That should cause all the URL's in the GHC package that aren't
explicit to have the above URL prepended to them. If there's demand, I
can add a flag.

Thanks, Neil

>
> On Mar 9, 2011, at 1:59 PM, Neil Mitchell wrote:
>
>> Hi Ranjit,
>>
>> It sounds like you've got quite far. Sadly the manual is a bit out of
>> date with respect to generating databases, but generally you need to
>> produce ghc.txt on your own (using tools such as GHC's make system),
>> then you can do:
>>
>> hoogle convert ghc.txt default.hoo
>>
>> Then you can run the local server with:
>>
>> hoogle server --databases=.
>>
>> That will find databases from the current directory, and serve them.
>> Alternatively, if you put ghc.hoo (or default.hoo) in
>> $DATADIR/databases it will pick them up automatically (where $DATADIR
>> is whatever Cabal configured it to be). If you name the database as
>> default.hoo it will be searched by default, if you name it ghc.hoo
>> then "foo +ghc" will search for foo in the GHC database.
>>
>> If a copy of ghc.txt was publicly available somewhere (and updated on
>> some schedule), I'd be happy to make the official Hoogle server search
>> it. Usually I just grab databases off Hackage, but I'll happily make
>> an exception for GHC.
>>
>> Thanks, Neil
>>
>> On Sun, Mar 6, 2011 at 7:52 AM, Malcolm Wallace  
>> wrote:
>>>> The final stumbling block is getting the local webserver (hoogle server)
>>>> to also search the above database. I'm sure there must be some simple way
>>>> I
>>>> can pass the name of the database as an argument when I boot up the
>>>> server,
>>>> but I can't seem to find it...
>>>
>>> Have you found the various versions of the web deployment procedure yet?
>>>
>>> deploy.txt:  instructions to follow manually (seems to be up-to-date)
>>> deploy.sh:   a shell script version to run locally (may be old)
>>> Deploy.hs:   a haskell version to run remotely (may also be old)
>>>
>>> Obviously those scripts are tailored to the official installation, but there
>>> are some clues in there, for instance the steps
>>>
>>>    cabal configure --datadir=/srv/web/haskell.org/hoogle/
>>> --datasubdir=datadir -O2
>>>
>>> and
>>>
>>>    Upload datadir/resources to /srv/web/haskell.org/hoogle/datadir/resources
>>>    Upload datadir/databases/* to
>>> /srv/web/haskell.org/hoogle/datadir/databases
>>>
>>> Regards,
>>>    Malcolm
>>>
>>> ___
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users@haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>
>

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

Re: hoogling GHC

[Neil Mitchell]

Hi Ranjit,

It sounds like you've got quite far. Sadly the manual is a bit out of
date with respect to generating databases, but generally you need to
produce ghc.txt on your own (using tools such as GHC's make system),
then you can do:

hoogle convert ghc.txt default.hoo

Then you can run the local server with:

hoogle server --databases=.

That will find databases from the current directory, and serve them.
Alternatively, if you put ghc.hoo (or default.hoo) in
$DATADIR/databases it will pick them up automatically (where $DATADIR
is whatever Cabal configured it to be). If you name the database as
default.hoo it will be searched by default, if you name it ghc.hoo
then "foo +ghc" will search for foo in the GHC database.

If a copy of ghc.txt was publicly available somewhere (and updated on
some schedule), I'd be happy to make the official Hoogle server search
it. Usually I just grab databases off Hackage, but I'll happily make
an exception for GHC.

Thanks, Neil

On Sun, Mar 6, 2011 at 7:52 AM, Malcolm Wallace  wrote:
>> The final stumbling block is getting the local webserver (hoogle server)
>> to also search the above database. I'm sure there must be some simple way
>> I
>> can pass the name of the database as an argument when I boot up the
>> server,
>> but I can't seem to find it...
>
> Have you found the various versions of the web deployment procedure yet?
>
> deploy.txt:  instructions to follow manually (seems to be up-to-date)
> deploy.sh:   a shell script version to run locally (may be old)
> Deploy.hs:   a haskell version to run remotely (may also be old)
>
> Obviously those scripts are tailored to the official installation, but there
> are some clues in there, for instance the steps
>
>    cabal configure --datadir=/srv/web/haskell.org/hoogle/
> --datasubdir=datadir -O2
>
> and
>
>    Upload datadir/resources to /srv/web/haskell.org/hoogle/datadir/resources
>    Upload datadir/databases/* to
> /srv/web/haskell.org/hoogle/datadir/databases
>
> Regards,
>    Malcolm
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

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

Re: Release/git plans

[Neil Mitchell]

Hi Austin,

The compiler plugins work is a great, and I'd be a likely user. The
original version wasn't supported on Windows, because GHC on Windows
lacked various forms of dynamic linking. Does the current patch you've
prepared work on Windows?

Thanks, Neil

On Sat, Jan 22, 2011 at 10:29 AM, Max Bolingbroke
 wrote:
> On 21 January 2011 23:59, austin seipp  wrote:
>> Perhaps Max can
>> elaborate on why this design was rejected in favor of the current one,
>> so we can see how and where it falls down, and what we really want.
>
> The only reason really is that it added a lot of mechanism. From the
> top of my head:
>  * Parsing etc for PHASE pragmas that declared phase objects
>  * A new namespace for phases
>  * Stuff to gather declared phases from all imported modules during 
> compilation
>  * A built-in phase for each core pass
>  * A solver that ordered core passes and plugin passes according to the phases
>
> So it was a lot of trouble for relatively little gain. In an effort to
> keep the delta against GHC small I threw it out in favour of the much,
> much simpler design we have today.
>
>> Thomas pointed out the Scala compiler plugin design document, so I'll
>> be sure to read over it this weekend when I get the chance to cook up
>> ideas.
>
> The Scala plugins project was just starting when I was working on GHC
> plugins so there was no design doc I could refer to at that time.
> Shame :-(
>
> Thanks for taking the lead on resurrecting plugins, Austin!
>
> Cheers,
> Max
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

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

Re: RFC: migrating to git

[Neil Mitchell]

> As another non-GHC contributor, my opinion should probably also count for
> little, but my experience with git has been poor.
>
> I have used git daily in my job for the last year.  Like Simon PJ, I
> struggle to understand the underlying model of git, despite reading quite a
> few tutorials.  I have a high failure rate with attempting anything beyond
> the equivalents of darcs record, push, and pull.

I'm in exactly the same camp as Malcolm. I don't understand git, and I
end up deleting the entire repo and starting again every time I try
and do anything clever - something I've never needed to do with darcs.
I consider the git equivalent of "darcs unrecord" to be "rm -rf", but
I'm sure that's a lack of knowledge/intuition on my part.

All my git dislike aside, I wouldn't worry about git and Windows. GHC
on Windows already drags in plenty of dependencies from Cygwin or
Mingw, both of which provide workable git binaries, and none of which
ever seem to have caused a problem. The standard gui's (gitk and git
gui) both work on Windows, and I certainly miss them when using darcs.

Thanks, Neil

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

Re: MonoLocalBinds and darcs

[Neil Mitchell]

Hi Ganesh,

Make sure you are using RC2 of the compiler, from what I remember RC1
required signatures it shouldn't have, or enabled MonoLocalBinds more
than it should - RC2 required less signatures. However, your code
could well just be heavily using the relevant features.

Thanks, Neil


On Tue, Nov 2, 2010 at 1:28 PM, Sittampalam, Ganesh
 wrote:
> Simon Marlow wrote:
>> On 02/11/2010 07:37, Sittampalam, Ganesh wrote:
>>> I've just been updating darcs 2.5 for GHC 7.0. I had to add about 40
>>> signatures for MonoLocalBinds in about 140 files/30K LOC. Is that
>>> about normal? darcs does make fairly heavy use of rank 2 polymorphism
>>> which leads to quite a lot of local definitions needing to be
>>> polymorphic.
>>
>> Sounds about right given my experience so far, but as you say it
>> depends a lot on the style of code involved.  Some people tend to
>> write a lot more polymorphic local bindings than others :-)
>
> In the case of darcs much of the fundamental structure of the code
> pushes us that way; code that works on repositories is written as
> "withRepository (some polymorphic function)" so that it's generic on the
> specific repository type, and since where clauses generally scope
> outside the withRepository they get bitten. Similarly our witnesses
> lists of patches have map operations with rank-2 types.
>
>>> Also, NoMonoLocalBinds didn't help at all, which surprised me a bit -
>>> I thought it might at least make some of the signatures unnecessary.
>>
>> I suspect MonoLocalBinds is being turned on again by an option later
>> in the ordering.  I had this problem a lot when trying to use
>> NoMonoLocalBinds, it's actually quite hard to make it stick. e.g. if
>> you have LANGUAGE GADTs in the source file, that will override
>> NoMonoLocalBinds on the command line.
>
> Ahh. I'd put it as the first option!
>
>>  I'm not sure what (if anything) we should do about this.
>
> It intuitively feels like language specifiers should be
> order-independent, but when you have positive and negative extensions
> like we do that's not trivial to achieve. Perhaps we could do better if
> more combinations were errors instead of taking the last selection.
> Also, perhaps options that imply other options could be decomposed into
> the underlying pieces, with the high-level options being aliases for
> baskets of the lower-level ones. So GADTs = GADTsCore + MonoLocalBinds,
> and then GADTS + NoMonoLocalBinds (in any order) = GADTsCore +
> MonoLocalBinds + NoMonoLocalBinds = an error.
>
>>> Finally, is NoMonoLocalBinds supposed to imply NPlusKPatterns? The
>>> only changes I was able to revert when I enabled it were a couple of
>>> those!
>>
>> It certainly is not, if you have evidence to the contrary please
>> submit a bug report.
>
> OK, I'll check.
>
> Cheers,
>
> Ganesh
>
> ===
> Please access the attached hyperlink for an important electronic 
> communications disclaimer:
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ===
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: un-used record wildcards

[Neil Mitchell]

Hi Simon,

I've seen this issue with GHC 6.12.3 (and assumed it was by design).
It occurs with a slight modification of your example:

{-# LANGUAGE RecordWildCards #-}

module Test where

data T = MkT { f,g :: Int }

p x = let MkT{..} = x in f

This example warns about "Defined but not used: `g'" on the line
defining p. I've raised a GHC bug:
http://hackage.haskell.org/trac/ghc/ticket/4411 about this warning.

Thanks, Neil

> Which version of GHC are you using?  GHC 6.12 does not complain about unused 
> variables bound by "..".  Try this, which complains about y, but not g.
>
> Simon
>
> {-# LANGUAGE RecordWildCards #-}
> module Test where
>
> data T = MkT { f,g :: Int }
>
> p (MkT { .. }) y = f
>
>
> |  -Original Message-
> |  From: glasgow-haskell-users-boun...@haskell.org 
> [mailto:glasgow-haskell-users-
> |  boun...@haskell.org] On Behalf Of Serge D. Mechveliani
> |  Sent: 14 October 2010 11:01
> |  To: Antoine Latter
> |  Cc: glasgow-haskell-users@haskell.org
> |  Subject: Re: un-used record wildcards
> |
> |  On Wed, Oct 13, 2010 at 01:47:11PM -0500, Antoine Latter wrote:
> |  > On Wed, Oct 13, 2010 at 1:02 PM, Serge D. Mechveliani 
> |  wrote:
> |  > > Dear GHC developers,
> |  > >
> |  > > I use the language extension of RecordWildcards, for example,
> |  > >                                f (Foo {foo1 = n, foo2 = m, ..}) = ...
> |  > >
> |  > > But the complier warns about un-used values of  foo3, foo4,
> |  > > probably, due to the extension of
> |  > >                     Foo {foo1 = n, foo2 = m, foo3 = foo3, foo4 = foo4}.
> |  > >
> |  > > In such cases, these warnings look as unneeded.
> |  > > Is it possible to have an un-used binding warnings with exception for
> |  > > wildcards in records?
> |  > > If not, then has it sense to introduce an option?
> |  > >
> |  >
> |  > If you're not using foo3 and foo4, can you not put it the ellipsis?
> |  > that won't cover every case (such as where you're using foo3 but not
> |  > foo4).
> |  >
> |  > Antoine
> |  >
> |
> |  Indeed, thank you.
> |  It occurs that under RecordWildcards the compiler allows to skip some
> |  record fields in a pattern.
> |  ___
> |  Glasgow-haskell-users mailing list
> |  glasgow-haskell-us...@haskell.org
> |  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: BlockedIndefinitelyOnMVar exception

[Neil Mitchell]

>> I wrote my Chan around the abstraction:
>>
>> data Chan a = Chan (MVar (Either [a] [MVar a]))
>>
>> The Chan either has elements in it (Left), or has readers waiting for
>> elements (Right). To get the fairness properties on Chan you might
>> want to make these two lists Queue's, but I think the basic principle
>> still works. By using this abstraction my Chan was a lot simpler. With
>> this scheme implementing isEmpyChan or unGetChan would both work
>> nicely. My Chan was not designed for performance. (In truth I replaced
>> the Left with IntMap a, and inserted elements with a randomly chosen
>> key, but the basic idea is the same.)
>
> I like the idea.  But what happens if one of the blocked threads gets killed
> by a killThread (e.g. a timeout) while it is waiting?  Won't we still give
> it an element of the Chan sometime in the future?  Perhaps this doesn't
> happen in your scenario, but it seems to throw a spanner in the works for
> using this as a general-purpose implementation.

I hadn't thought of that at all - my scenario doesn't have any threads
being killed. With the thought of threads dying concurrency
abstractions become significantly harder - I hadn't quite realised how
hard that must make it.

Thanks, Neil
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: BlockedIndefinitelyOnMVar exception

[Neil Mitchell]

>> http://hackage.haskell.org/trac/ghc/ticket/4154
>
> Yup, that's a bug.  Not clear if it's fixable.
>
>> http://hackage.haskell.org/trac/ghc/ticket/3527
>
> That too.  A very similar bug in fact, if there is a fix it will probably
> fix both of them.  The problem is that readChan holds a lock on the read end
> of the Chan, so neither isEmptyChan nor unGetChan can work when a reader is
> blocked.

I wrote my Chan around the abstraction:

data Chan a = Chan (MVar (Either [a] [MVar a]))

The Chan either has elements in it (Left), or has readers waiting for
elements (Right). To get the fairness properties on Chan you might
want to make these two lists Queue's, but I think the basic principle
still works. By using this abstraction my Chan was a lot simpler. With
this scheme implementing isEmpyChan or unGetChan would both work
nicely. My Chan was not designed for performance. (In truth I replaced
the Left with IntMap a, and inserted elements with a randomly chosen
key, but the basic idea is the same.)

>> own Chan implementation worked. My Chan had different properties (it
>> queues items randomly) and a subset of the Chan functions, so it still
>> doesn't prove any issue with Chan - but I am now sceptical.
>
> It's surprising how difficult it is to get these MVar-based abstractions
> right.  Some thorough testing of Chan is probably in order.

Agreed! In this project I wrote 8 different concurrency abstractions.
I had bugs in most. MVar is a great building block on which to put
higher layered abstractions, but using it correctly is tricky. I found
that I used MVar's in four ways:

1) MVar's which are always full, and are just locks around data for
consistency. Created with newMVar, used with modifyMVar.

2) MVar's which contain unit and are used for locking something other
than data (i.e. a file on disk). Created with newMVar, used with
withMVar.

3) MVar's which are used to signal computation can begin, created with
newMVarEmpty, given to someone who calls putMVar (), and waited on by
the person who created them.

4) MVar's which go in a higher-level concurrency operation - CountVars
(variables which wait until they have been signaled N times), RandChan
(Chan but with randomness), Pool (thread pool) etc.

Thanks, Neil
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: BlockedIndefinitelyOnMVar exception

[Neil Mitchell]

Hi Simon,

>> My suspicion for the root cause of the problem is that Concurrent.Chan
>> is incorrect. In the course of debugging this problem we found 2 bugs
>> in Chan, and while I never tracked down any other bugs in Chan, I no
>> longer trust it. By rewriting parts of the program, including avoiding
>> Chan, the bugs disappeared.I don't think I'll be using Chan again
>> until after someone has proven in correct.
>
> Considering Chan is <150 lines of code and has been around for many years,
> that's amazing!  Did you report the bugs?  Is it anything to do with
> asynchronous exceptions?

Nothing to do with async exceptions. I found:

http://hackage.haskell.org/trac/ghc/ticket/4154
http://hackage.haskell.org/trac/ghc/ticket/3527

Of course, there's also the async exceptions bug still around:

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

However, even after having a program with no async exceptions (I never
used them), and eliminating unGetChan and isEmpyChan, I still got
bugs. I have no proof they came from the Chan module, and no minimal
test case was ever able to recreate them, but the same program with my
own Chan implementation worked. My Chan had different properties (it
queues items randomly) and a subset of the Chan functions, so it still
doesn't prove any issue with Chan - but I am now sceptical.

> You should have more luck with Control.Concurrent.STM.TChan, incedentally.
>  It's much easier to get right, and when we benchmarked it, performance was
> about the same (all those withMVar/modifyMVars in Chan are quite expensive),
> plus you get to compose it easily: reading from either of 2 TChans is
> trivial.

The performance of the Haskell is irrelevant - the program spends all
its time invoking system calls. Looking at the implementation I am
indeed much more trusting of TChan, I'll be using that in future if
there is ever a need.

Thanks, Neil
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: BlockedIndefinitelyOnMVar exception

[Neil Mitchell]

Hi Simon,

Thanks for the excellent information. I've now debugged my problem,
and think I've got the last of the MVar blocking problems out.

>> * How confident are people that this exception does really mean that
>> it is in a blocked state? Is there any chance the error could be
>> raised incorrectly?
>
> There have been one or two bugs in the past that could lead to this
> exception being raised incorrectly, but I'm not aware of any right now.
>  It's not inconceivable of course.

I have no reason to think it's broken. I found at least 3 separate
concurrency bugs in various parts (one added the day before, one over
a year old, one of which had been introduced while trying to work
around the MVar problem).

My suspicion for the root cause of the problem is that Concurrent.Chan
is incorrect. In the course of debugging this problem we found 2 bugs
in Chan, and while I never tracked down any other bugs in Chan, I no
longer trust it. By rewriting parts of the program, including avoiding
Chan, the bugs disappeared.I don't think I'll be using Chan again
until after someone has proven in correct.

>> * Any debugging tips for this problem?
>
> I'd use the event log: compile with -debug, run with +RTS -Ds -l, and dump
> the event log with show-ghc-events (cabal install ghc-events).  Or just dump
> it to stderr with +RTS -Ds, if the log isn't too large.  Use
> GHC.Exts.traceEvent to add your own events to the trace.

The event log is fantastic!

Thanks, Neil
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: BlockedIndefinitelyOnMVar exception

[Neil Mitchell]

> My understanding was that this error occurred when one thread was blocked,
> waiting on an MVar, and no other thread in the program has a reference to
> that MVar (this can be detected during GC).  Ergo, the blocked thread will
> end up waiting forever because no-one can ever wake it up again.

That certainly seems a sensible rule - I'll see if that can help me
debug my problem.

> Do you actually have use of MVars in your program directly, or are they
> being used via a library?  And do you at least know which thread is
> throwing this exception?  It should be catchable so you can probably wrap
> the arguments to your forkIO calls with a catcher than indicates which
> thread blew up.

I use MVar's directly, use Chan/QSem, and have about 5 concurrency
data types built on top of MVar's - they're everywhere.

I also have a thread pool structure, so tasks move between threads
regularly - knowing which thread got blocked isn't very interesting.

Thanks for the information,

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

BlockedIndefinitelyOnMVar exception

[Neil Mitchell]

Hi,

I have a very big and highly threaded program that generates a
BlockedIndefinitelyOnMVar exception when run. I have spent a
reasonable amount of time pouring over the source code, as has Max
Bolingbroke. Neither of us have the slightest idea why it raises the
exception.

Some questions:

* Does anyone know the exact sequence of actions that causes this
exception to be thrown? I couldn't find it written down.
* How confident are people that this exception does really mean that
it is in a blocked state? Is there any chance the error could be
raised incorrectly?
* Any debugging tips for this problem?

Thanks, Neil
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Plans for GHC 6.12.2

[Neil Mitchell]

Hi,

Could this bug please be added: http://hackage.haskell.org/trac/ghc/ticket/3893

It's a regression against GHC 6.10.4, entirely a packaging issue, and
most likely an oversight to remove the file.

Thanks, Neil

On Tue, Mar 23, 2010 at 6:38 PM, Ian Lynagh  wrote:
>
> Hi all,
>
> This is a summary of our plans for GHC 6.12.2.
>
> We plan to put out a release candidate 6.12.2-rc1 shortly and, assuming
> there are no serious regressions found, 6.12.2 will follow soon after.
>
> The bugs that we're planning to fix for 6.12.2 are the high priority
> tickets in the 6.12.2 milestone:
>
> http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&priority=highest&priority=high&milestone=6.12.2&order=priority
>
> If there is a bug not in that list that is important to you, please let
> us know.
>
>
> Thanks
> Ian
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Easily generating efficient instances for classes

[Neil Mitchell]

Hi Christian,

No good examples I'm afraid. There are a few notes in README.txt (I
just pushed a few more notes). If you follow the process I'd welcome
any improvements to the documentation.

Thanks, Neil

On Tue, Mar 2, 2010 at 1:50 PM, Christian Hoener zu Siederdissen
 wrote:
> Thanks everybody for the answers.
>
> Right now, it looks like this:
> the indextype is abstracted out and I plan for Data.Ix and my own Data.FastIx 
> (or however to call it).
>
> As I don't plan on creating all instances myself, Neils derive package looks 
> good -- once I
> understand it completely; which I need to as I need instances of my own 
> class. Is there a tutorial
> on creating instances for own stuff, or should I go by the examples like 
> Functor?
>
> The code in AdaptiveTuple has one advantage: it looks easier to get started 
> producing instances. (No
> need to get to know another package).
>
> Btw. it is a bit disappointing (for me) that Data.Ix is almost as fast as my 
> FastIx ;-) (as in: most
> people don't care about the difference)
>
>
>
> Something else: was there a resource about library naming? otherwise it is 
> going to be
> vector-ixtables (someone a better idea?)
>
>
> Thanks again,
> Christian
>
>
> On 03/02/2010 02:30 PM, Neil Mitchell wrote:
>> Hi
>>
>> Derive generates declarations - they can be instances, classes, data
>> types, functions, type synonyms etc.
>>
>> Thanks, Neil
>>
>> On Mon, Mar 1, 2010 at 10:32 AM, John Lato  wrote:
>>>> From: Christian H?ner zu Siederdissen
>>>>
>>>> Hi,
>>>>
>>>> I am thinking about how to easily generate instances for a class. Each
>>>> instance is a tuple with 1 or more elements. In addition there is a
>>>> second tuple with the same number of elements but different type. This
>>>> means getting longer and longer chains of something like (...,x3*x2,x2,0).
>>>>
>>>> - template haskell?
>>>> - CPP and macros?
>>>>
>>>> Consider arrays with fast access like Data.Vector, but with higher
>>>> dimensionality. Basically, I want (!) to fuse when used in Data.Vector
>>>> code.
>>>
>>> (shameless plug) You may want to look at my AdaptiveTuple package,
>>> which does something very similar to this.  I used Template Haskell
>>> because AFAIK neither generic approaches nor DrIFT/Derive will
>>> generate data decls.
>>>
>>> If all you need are the instances, then DrIFT or Derive would be my
>>> recommendations.
>>>
>>> Cheers,
>>> John
>>> ___
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users@haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Easily generating efficient instances for classes

[Neil Mitchell]

Hi

Derive generates declarations - they can be instances, classes, data
types, functions, type synonyms etc.

Thanks, Neil

On Mon, Mar 1, 2010 at 10:32 AM, John Lato  wrote:
>> From: Christian H?ner zu Siederdissen
>>
>> Hi,
>>
>> I am thinking about how to easily generate instances for a class. Each
>> instance is a tuple with 1 or more elements. In addition there is a
>> second tuple with the same number of elements but different type. This
>> means getting longer and longer chains of something like (...,x3*x2,x2,0).
>>
>> - template haskell?
>> - CPP and macros?
>>
>> Consider arrays with fast access like Data.Vector, but with higher
>> dimensionality. Basically, I want (!) to fuse when used in Data.Vector
>> code.
>
> (shameless plug) You may want to look at my AdaptiveTuple package,
> which does something very similar to this.  I used Template Haskell
> because AFAIK neither generic approaches nor DrIFT/Derive will
> generate data decls.
>
> If all you need are the instances, then DrIFT or Derive would be my
> recommendations.
>
> Cheers,
> John
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Easily generating efficient instances for classes

[Neil Mitchell]

As Bulat says, the Derive package might be a good way to go. I am
happy to accept any new derivations, and you get lots of things for
free - including writing your code using the nice haskell-src-exts
library, preprocessor support, TH support etc.

Thanks, Neil

On Thu, Feb 25, 2010 at 8:57 AM, Bulat Ziganshin
 wrote:
> Hello Christian,
>
> Thursday, February 25, 2010, 3:57:44 AM, you wrote:
>
>> I am thinking about how to easily generate instances for a class. Each
>
> it's called generic programing. just a few overviews on this topic:
>
> Libraries for Generic Programming in Haskell
> http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-025.pdf
>
> Comparing Approaches to Generic Programming in Haskell
> http://www.cs.uu.nl/~johanj/publications/ComparingGP.pdf
>
> Derive package is probably the easiest way
>
> Template Haskell is also good although a bit too complex. my own pets:
> http://www.haskell.org/bz/th3.htm
> http://www.haskell.org/bz/thdoc.htm
>
> --
> Best regards,
>  Bulat                            mailto:bulat.zigans...@gmail.com
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Where did the GHC API go?

[Neil Mitchell]

Hi,

As a suggestion to stop this issue repeating, why not have the latest
URL be an automatic and visible forward to the stable and guaranteed
URL? (I can't remember the HTTP code, but I think it's permanent
redirect) That way people are less likely to see these "unstable"
URL's in their web browser, copy them, and have them end up all over
the place. I think Google will also avoid indexing them at the latest
URL.

As it happens, I've put in another timebomb into Hoogle by linking to
http://haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Prelude.html#v:filter
- the very URL Ian said the docs had moved to (but is again unstable
and not guaranteed in the long term). Having the URL redirection would
have avoided that mistake. (I'll fix Hoogle as well though)

Thanks, Neil

2009/12/30 Simon Marlow :
> 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
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Where did the GHC API go?

[Neil Mitchell]

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
 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
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Where did the GHC API go?

[Neil Mitchell]

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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Where did the GHC API go?

[Neil Mitchell]

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  wrote:
> On 21/12/2009 00:18, Tom Tobin wrote:
>>
>> On Sun, Dec 20, 2009 at 6:17 PM, Tom Tobin  wrote:
>>>
>>> On Sun, Dec 20, 2009 at 4:47 PM, Jason Dusek
>>>  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
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: group keyword with TransformListComp

[Neil Mitchell]

Hi,

The question of syntax is always something that provokes intense
discussion. My interest (and concern) with the choice of syntax in
this case is three-fold:

1) I want HLint to turn on as many Haskell extensions as possible when
parsing, with the trade off that they don't break a massive number of
existing programs. For each extension I have weighed up the number of
programs that will get broken (because the extension steals previously
valid syntax), vs the number that will be parsed (how popular the
extension is). I've erred on the side of enabling extensions, so am
happy to accept changes in meaning for a!b and $(a). Almost all
extensions get turned on, with the exception of TransformListComp,
which even breaks the source code to HLint itself - something no other
extension does. It seems the syntax stolen is far too much, especially
when compared to other extensions.

2) I want to use TransformListComp in HLint. In particular, I have a
nested pile of group/sort surrounding a list comp that would be
perfect for TransformListComp. However, as it stands, I can't even
enable the extension without that file breaking. I could qualify all
the uses of group, but that seems too much hassle. I'd really like to
enable the extension (without modification), and then start converting
each group-like list-comp one at a time.

3) We'll never be able to make TransformListComp enabled in future
versions of Haskell' since we break too many programs. It's an
extension that is destined forever to remain only an extension. That
seems like a lonely life for an extension.

Thanks

Neil

On Sat, Jun 27, 2009 at 11:52 AM, Max Bolingbroke wrote:
> Hi,
>
> I agree this is annoying. It was hard to find syntax which was both
> meaningful and currently unused, so we settled on this instead. As
> Simon says, suggestions are welcome!
>
> Note that group *should* be parsed as a special id, so you can still
> import D.L qualified and then use dot notation to access the function.
>
> Cheers,
> Max
>
>
> 2009/6/21 Neil Mitchell :
>> Hi,
>>
>> The TransformListComp extension makes group a keyword. Unfortunately
>> group is a useful function, and is even in Data.List. Thus,
>> Data.List.group and TransformListComp are incompatible. This seems a
>> very painful concession to give up a nice function name for a new
>> extension. Is this intentional? Here's an example:
>>
>>> $ cat GroupKeyword.hs
>>> {-# LANGUAGE TransformListComp #-}
>>> module GroupKeyword where
>>>
>>> a = map head $ group $ sort [1..100]
>>> $ ghci GroupKeyword.hs
>>> GHCi, version 6.10.2: http://www.haskell.org/ghc/  :? for help
>>> Loading package ghc-prim ... linking ... done.
>>> Loading package integer ... linking ... done.
>>> Loading package base ... linking ... done.
>>> [1 of 1] Compiling GroupKeyword     ( GroupKeyword.hs, interpreted )
>>>
>>> GroupKeyword.hs:4:15: parse error on input `group'
>>> Failed, modules loaded: none.
>>> Prelude>
>>
>> There are some places I'd like to use TransformListComp, but I often
>> want to use group in the same module.
>>
>> Thanks
>>
>> Neil
>>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

group keyword with TransformListComp

[Neil Mitchell]

Hi,

The TransformListComp extension makes group a keyword. Unfortunately
group is a useful function, and is even in Data.List. Thus,
Data.List.group and TransformListComp are incompatible. This seems a
very painful concession to give up a nice function name for a new
extension. Is this intentional? Here's an example:

> $ cat GroupKeyword.hs
> {-# LANGUAGE TransformListComp #-}
> module GroupKeyword where
>
> a = map head $ group $ sort [1..100]
> $ ghci GroupKeyword.hs
> GHCi, version 6.10.2: http://www.haskell.org/ghc/  :? for help
> Loading package ghc-prim ... linking ... done.
> Loading package integer ... linking ... done.
> Loading package base ... linking ... done.
> [1 of 1] Compiling GroupKeyword ( GroupKeyword.hs, interpreted )
>
> GroupKeyword.hs:4:15: parse error on input `group'
> Failed, modules loaded: none.
> Prelude>

There are some places I'd like to use TransformListComp, but I often
want to use group in the same module.

Thanks

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

Re: --out-implib when linking shared libraries

[Neil Mitchell]

Hi

Following up on a slightly old thread, it seems that the use of
--out-implib is unnecessary for my purposes and generates 50Mb of
.dll.a files. I'm also concerned that the generation of these .dll.a
files may be taking considerable time (in the range of minutes).

I'd like to disable the flags, using things such as -optl, but can't
figure out how. The best I've come up with is:

-optl=-Wl,--opt-implib=nul

When doing this is generates the implib to nul, instead of to a file.
That saves me 10 seconds and 50Mb of disk space, but I suspect if I
could properly eliminate the opt-implib flag I'd save a significant
chunk more time. Is there any way to override implib so it doesn't
even try to generate it? Given Krasimir's comments, could this bug
changed in a future version of GHC?

Thanks, Neil

On Sat, May 16, 2009 at 1:22 PM, Krasimir Angelov wrote:
> I remember that the .dll.a libraries that GCC produces are not always
> compatible with MSVC. Sometimes it works if you rename them to .lib
> but sometimes it doesn't. It is much more realiable to create .lib
> from .def file via some of the MS tools. If GCC can link dynamic
> libraries without using the static library then it might be good idea
> not to build the import libraries at all.
>
> Regards,
>  Krasimir
>
>
> On Sat, May 16, 2009 at 1:26 PM, Duncan Coutts
>  wrote:
>> On Sat, 2009-05-16 at 11:07 +0100, Neil Mitchell wrote:
>>
>>> I don't, although having that option wouldn't be a bad thing - having
>>> a minimal .lib is perfectly reasonable as a default. Having a massive
>>> .lib seems crazy. (The fact that .lib is named .dll.a isn't too much
>>> of an issue)
>>
>> It's possible to create a minimal import lib via a .def file (which
>> lists the exports). I think the dlltool helps with that.
>>
>>> > So my suggestion is remove it, if you're linking using gcc it should
>>> > work.
>>>
>>> I'm not linking the .dll at all, only using dynamic linking, which
>>> works without the .lib. But I don't really want to start removing
>>> files - doing that in a build system seems like a bad idea.
>>
>> Sure, so at least you don't have to install them.
>>
>> Duncan
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: mtl and network packages in GHC 6.10.3.*

[Neil Mitchell]

Works perfectly, thanks a lot Johan!

Neil

On Wed, May 27, 2009 at 9:50 PM, Johan Tibell  wrote:
> On Wed, May 27, 2009 at 9:53 PM, Johan Tibell 
> wrote:
>>
>> On Wed, May 27, 2009 at 3:33 AM, Neil Mitchell 
>> wrote:
>>>
>>> In addition, I can't install network under Cygwin, Mingw, or the
>>> Windows command line. Here are the errors from Cygwin:
>>
>> I've filed a bug: http://trac.haskell.org/network/ticket/14
>>
>> In the meantime try 2.2.1.1
>
> The latest HEAD from darcs works fine for me on Windows XP.
>
> Cheers,
>
> Johan
>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: mtl and network packages in GHC 6.10.3.*

[Neil Mitchell]

Hi

The GHC 6.10.3 installer is 100% useless to me (and my colleagues) -
GHC 6.10.4 has two critical fixes in, for fatal problems which we're
hitting on an at least an hourly basis.

The Haskell platform can be a convenient way to get a standardised set
of packages, but if cabal install  doesn't work for Core
libraries I'm in deep trouble.

> I'll look into it later today when I have access to a Windows install.

Thanks Johan. My personal feeling is if Core packages can't be
installed with "cabal install foo" on the standard command line with a
standard Windows+GHC install then they MUST be shipped in with GHC. If
the platform effort wants to fix up the packages then that's great,
but if the platform becomes the only way to get critical libraries
with a massive lag, then I'm in serious trouble.

Given this is a minor bug fix release, and that removing time in a
minor bug fix release seems like it was a massive mistake, shouldn't
these packages be reinstated at least until GHC 6.12?

Thanks

Neil

On Wed, May 27, 2009 at 8:57 AM, Johan Tibell  wrote:
>
> On May 27, 2009 3:33 AM, "Neil Mitchell"  wrote:
>
> Hi,
>
> I just downloaded the Windows snapshot of 6.10.3.20090526, and found
> that mtl and network don't seem to be included.
>
> $ ghc-pkg list
> c:/ghc/ghc-6.10.3.20090526\package.conf:
>    Cabal-1.6.0.1, Cabal-1.6.0.3, Win32-2.2.0.0, array-0.2.0.0,
>    base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1,
>    directory-1.0.0.3, extensible-exceptions-0.1.1.0, filepath-1.1.0.2,
>    (ghc-6.10.3.20090526), ghc-prim-0.1.0.0, haddock-2.4.2,
>    haskell98-1.0.1.0, hpc-0.5.0.3, integer-0.1.0.1,
>    old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1,
>    pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0,
>    syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4
>
> In addition, I can't install network under Cygwin, Mingw, or the
> Windows command line. Here are the errors from Cygwin:
>
> Preprocessing library network-2.2.1.2...
> In file included from Network\BSD.hsc:17:
> include/HsNet.h:78:22: sys/uio.h: No such file or directory
> include/HsNet.h:81:25: sys/socket.h: No such file or directory
> include/HsNet.h:84:26: netinet/tcp.h: No such file or directory
> include/HsNet.h:87:25: netinet/in.h: No such file or directory
> include/HsNet.h:90:21: sys/un.h: No such file or directory
> include/HsNet.h:93:24: arpa/inet.h: No such file or directory
> include/HsNet.h:96:19: netdb.h: No such file or directory
> In file included from Network\BSD.hsc:17:
> include/HsNet.h:138: error: syntax error before "addr"
> include/HsNet.h: In function `my_inet_ntoa':
> include/HsNet.h:146: error: storage size of 'a' isn't known
> include/HsNet.h:147: error: `addr' undeclared (first use in this function)
> include/HsNet.h:147: error: (Each undeclared identifier is reported only
> once
> include/HsNet.h:147: error: for each function it appears in.)
> include/HsNet.h:148: warning: return makes pointer from integer without a
> cast
> Network\BSD.hsc: In function `main':
> Network\BSD.hsc:145: error: invalid application of `sizeof' to incomplete
> type `
> servent'
>
> And Mingw:
>
> * Missing header file: HsNet.h
> This problem can usually be solved by installing the system package that
> provides this library (you may need the "-dev" version). If the library is
> already installed but in a non-standard location then you can use the flags
> --extra-include-dirs= and --extra-lib-dirs= to specify where it is.
> cabal.exe: Error: some packages failed to install:
> network-2.2.1.2 failed during the configure step. The exception was:
> exit: ExitFailure 1
>
> And Windows command line:
>
> Resolving dependencies...
> Configuring network-2.2.1.2...
> cabal: Error: some packages failed to install:
> network-2.2.1.2 failed during the configure step. The exception was:
> sh: runProcess: does not exist (No such file or directory)
>
> Was removal of these packages on the stable branch was an oversight?
> Could network at the very least be reinstated soon? I'd love to report
> back whether the GHC 6.10.4 fixes  work or not in practice.
>
> Thanks
>
> Neil
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

mtl and network packages in GHC 6.10.3.*

[Neil Mitchell]

Hi,

I just downloaded the Windows snapshot of 6.10.3.20090526, and found
that mtl and network don't seem to be included.

$ ghc-pkg list
c:/ghc/ghc-6.10.3.20090526\package.conf:
Cabal-1.6.0.1, Cabal-1.6.0.3, Win32-2.2.0.0, array-0.2.0.0,
base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1,
directory-1.0.0.3, extensible-exceptions-0.1.1.0, filepath-1.1.0.2,
(ghc-6.10.3.20090526), ghc-prim-0.1.0.0, haddock-2.4.2,
haskell98-1.0.1.0, hpc-0.5.0.3, integer-0.1.0.1,
old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1,
pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0,
syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4

In addition, I can't install network under Cygwin, Mingw, or the
Windows command line. Here are the errors from Cygwin:

Preprocessing library network-2.2.1.2...
In file included from Network\BSD.hsc:17:
include/HsNet.h:78:22: sys/uio.h: No such file or directory
include/HsNet.h:81:25: sys/socket.h: No such file or directory
include/HsNet.h:84:26: netinet/tcp.h: No such file or directory
include/HsNet.h:87:25: netinet/in.h: No such file or directory
include/HsNet.h:90:21: sys/un.h: No such file or directory
include/HsNet.h:93:24: arpa/inet.h: No such file or directory
include/HsNet.h:96:19: netdb.h: No such file or directory
In file included from Network\BSD.hsc:17:
include/HsNet.h:138: error: syntax error before "addr"
include/HsNet.h: In function `my_inet_ntoa':
include/HsNet.h:146: error: storage size of 'a' isn't known
include/HsNet.h:147: error: `addr' undeclared (first use in this function)
include/HsNet.h:147: error: (Each undeclared identifier is reported only once
include/HsNet.h:147: error: for each function it appears in.)
include/HsNet.h:148: warning: return makes pointer from integer without a cast
Network\BSD.hsc: In function `main':
Network\BSD.hsc:145: error: invalid application of `sizeof' to incomplete type `
servent'

And Mingw:

* Missing header file: HsNet.h
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
cabal.exe: Error: some packages failed to install:
network-2.2.1.2 failed during the configure step. The exception was:
exit: ExitFailure 1

And Windows command line:

Resolving dependencies...
Configuring network-2.2.1.2...
cabal: Error: some packages failed to install:
network-2.2.1.2 failed during the configure step. The exception was:
sh: runProcess: does not exist (No such file or directory)

Was removal of these packages on the stable branch was an oversight?
Could network at the very least be reinstated soon? I'd love to report
back whether the GHC 6.10.4 fixes  work or not in practice.

Thanks

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

Re: Should exhaustiveness testing be on by default?

[Neil Mitchell]

> OK. i'm just trying to get an intuition for the analysis.

Catch is defined by a small Haskell program. You can write a small
Haskell evaluation for a Core language. The idea is to write the
QuickCheck style property, then proceed using Haskell style proof
steps. The checker is recursive - it assigns a precondition to an
expression based on the precondition of subexpressions, therefore I
just induct upwards proving that each step is correct individually.
There wasn't an intention of trying to move partiality around, but
perhaps it has worked out that way.

> What is the nature of the preconditions generated?

A precondition is a proposition of pairs of (expression, constraint),
where an pair is satisfied if the expression satisfies the constraint.
I prove that given a couple of lemmas about the constraint language,
the analysis is correct. I then prove that 2 particular constraint
languages have these necessary lemmas.

As a side note, I'm pretty certain that the constraint languages I
give aren't the best choice. The second one (MP constraints) is good,
but lacks an obvious normal form, which makes the fixed point stuff a
little more fragile/slow. I'm sure someone could come up with
something better, and providing it meets a few simple lemmas, it's
suitable for Catch.

> In order for them to
> cancel out the calls to error, are they constructed from information in
> the caller (as I speculated) about how the function under analysis is used?

Yes, information from case branches add to the constraint, so:

case xs of
[] -> []
_:_ -> head xs

becomes:
xs == []\/safe (head xs)
xs == []\/xs == _:_
True

> Obviously, you're also using a restricted notion of "bottom".

For my purposes, bottom = call to error. Things such as missing case
branches and asserts are translated to error. I actually consider
non-termination to be a safe outcome, for example Catch says:

assert (last xs) True

This is safe if all elements of the list are True (Catch approximates
here), or if the list xs is infinite.

Thanks

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

Re: Should exhaustiveness testing be on by default?

[Neil Mitchell]

>> If Catch says your program will not crash, then it will not crash. I
>> even gave an argument for correctness in the final appendix of my
>> thesis http://community.haskell.org/~ndm/thesis/ (pages 175-207). Of
>> course, there are engineering concerns (perhaps your Haskell compiler
>> will mis-translate the program to Core, perhaps the libraries will be
>> wrong, perhaps a bit in RAM will flip due to electrical interference),
>> but Catch has a formal basis.
>
> Oh, very good! I wasn't aware you'd tried this. I imagine you do
> something like:
>
>    * identify all partial functions
>    * bubble that information outwards, crossing off partial functions
>      that are actually total due to tests in callers that effectively
>      reduce the possible inhabitants of the types passed to the partial
>      function
>    * and you have some argument for why your travesal doesn't miss, or
>      mislabel constraints.

Nope, not at all. I assume all missing case branches are replaced with
calls to error (as both GHC and Yhc Core do), then prove that:

satE $ pre e ==> not $ isBottom $ eval e

If the preconditions generated by Catch on an expression are a
tautology, that implies the evaluation of e won't contain any _|_
terms at any level. If the precondition Catch generates is const True,
then that implies the evaluation is never bottom. I then proceed by
induction with a few lemmas, and fusing things - the "proof" is all at
the level of Haskell equational reasoning.

> Is it possible for Catch to print out its reasoning for why some
> function 'f' is total, such that I could check it (with another tool)?

It already does. My plan was always to output the reasoning into an
ESC/Haskell file, and then have the "Catch" process run the Catch
algorithm, and then check the results with ESC/Haskell - this way I
hoped to avoid writing a proof for Catch...

Things didn't quite turn out that way, as I needed to submit my
thesis, I didn't have a copy of ESC/Haskell good enough to do what I
wanted, and every thesis needs a nice proof in the appendix.

Thanks, Neil
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Should exhaustiveness testing be on by default?

[Neil Mitchell]

>> Catch already does assertion checking (1). Its runtime on moderate to
>> small programs (HsColour in particular) is far less than the time GHC
>> takes to compile them, and I still have no idea what its runtime is on
>> enormous programs (2). An analysis can be whole program and can be
>> slow, one does not imply the other.
>
> But the primary problem with Catch is that its analysis not well
> defined. I have no guarantee regarding the existence or not of false
> positives or false negatives, as Catch has no underlying formal logic to
> guide such reasoning.

If Catch says your program will not crash, then it will not crash. I
even gave an argument for correctness in the final appendix of my
thesis http://community.haskell.org/~ndm/thesis/ (pages 175-207). Of
course, there are engineering concerns (perhaps your Haskell compiler
will mis-translate the program to Core, perhaps the libraries will be
wrong, perhaps a bit in RAM will flip due to electrical interference),
but Catch has a formal basis.

I guarantee that there are safe programs Catch can't prove safe, for a
proof see Turing 1937 :-)

Thanks

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

Re: Should exhaustiveness testing be on by default?

[Neil Mitchell]

>  > Do you really want exhaustiveness, or is what you actually want safety?
>
> I want both.  Exhaustiveness checking now and forever, because it's a
> modular property.  Safety when somebody gets around to implementing
> whole-program analysis in the compiler I use, when I feel like waiting
> around for a whole-program analysis to complete, and when I'm not
> making local modifications to somebody else's enormous, unsafe Haskell
> program.

Exhaustiveness is handy if every function is exhaustive, then it's a
local property contributing to global safety. If you have functions
like head floating around, then local exhaustiveness does not equal
global safety. I can see why some people want it, but I'm not one of
them (which in my mind makes it perfect for a flag).

> Needless to say, safety analysis should identify 'assert False' and
> confirm at compile time that there are no assertion failures.

Catch already does assertion checking (1). Its runtime on moderate to
small programs (HsColour in particular) is far less than the time GHC
takes to compile them, and I still have no idea what its runtime is on
enormous programs (2). An analysis can be whole program and can be
slow, one does not imply the other.

Thanks

Neil

1) To the extent that it can It certainly tries to prove the
assertions can't fail, and reports each one it fails to prove.

2) I think HsColour was fairly near to the largest program Yhc ever compiled...
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Should exhaustiveness testing be on by default?

[Neil Mitchell]

> Excellent, is there a -fuse-catch flag for ghc? :)

No, but there is for Yhc. If you write to the Haskell standard (minus
a little bit), don't like libraries and can get Yhc to compile (good
luck!) then it's just a few command lines away.

If GHC (or GHC + some scripts) could produce a single Core file
representing a whole program, including all necessary libraries, then
implementing Catch would be a weekends work.

Thanks

Neil

>
> On Tue, May 19, 2009 at 12:01 PM, Neil Mitchell  wrote:
>>>  > ... exhaustive pattern checking might well help out a lot of
>>>  > people coming from untyped backgrounds...
>>>
>>> Or even people from typed backgrounds.  I worship at the altar of
>>> exhaustiveness checking.
>>
>> Do you really want exhaustiveness, or is what you actually want safety?
>>
>> With -fwarn-incomplete-patterns:
>>
>> test1 = head []
>>
>> test2 = x where (x:xs) = []
>>
>> test3 = (\(x:xs) -> 1) []
>>
>> test4 = f [] where f [] = 1
>>
>> GHC reports that test4 has incomplete patterns, but the others don't.
>> However, test4 is safe, but the others aren't. Exhaustiveness is a
>> poor approximation of safety. GHC's exhaustiveness checker is a poor
>> approximation of exhaustiveness. 2 is a poor approximation of pi :-)
>>
>> Using Catch, it reports that test1..3 were faulty, but test4 is safe.
>>
>> Thanks
>>
>> Neil
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Should exhaustiveness testing be on by default?

[Neil Mitchell]

>  > ... exhaustive pattern checking might well help out a lot of
>  > people coming from untyped backgrounds...
>
> Or even people from typed backgrounds.  I worship at the altar of
> exhaustiveness checking.

Do you really want exhaustiveness, or is what you actually want safety?

With -fwarn-incomplete-patterns:

test1 = head []

test2 = x where (x:xs) = []

test3 = (\(x:xs) -> 1) []

test4 = f [] where f [] = 1

GHC reports that test4 has incomplete patterns, but the others don't.
However, test4 is safe, but the others aren't. Exhaustiveness is a
poor approximation of safety. GHC's exhaustiveness checker is a poor
approximation of exhaustiveness. 2 is a poor approximation of pi :-)

Using Catch, it reports that test1..3 were faulty, but test4 is safe.

Thanks

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

Re: strictness of interpreted haskell implementations

[Neil Mitchell]

Hi

>>       data S = S { a :: Int, b :: ! Int }
>>
>>       Main> a (S { a = 0, b = 1 })
>>       0
>>       Main> a (S { a = 0, b = undefined })
>>       0
>>
>> Ho hum.  Is this a "known difference"?

I've submitted a bug: http://hackage.haskell.org/trac/hugs/ticket/92

> As an ex teaching assistant my recommendation is "Use ghci!".

I helped to teach using WinHugs, which was quite nice. Auto reload
cuts out one very frequent source of problems.

Thanks

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

Re: Should exhaustiveness testing be on by default?

[Neil Mitchell]

I'm not a particular fan of exhaustiveness checking. It just
encourages people to write:

foo (Just 1) [x:xs] = important case
foo _ _ = error "doh!"

So now when the program crashes, instead of getting a precise and
guaranteed correct error message, I get "doh!" - not particularly
helpful for debugging.

I think it's not that useful for writing personal code, but for
writing production code (which you're going to ship off) it's probably
important that you cover all cases. However, for that it would be much
better to use a tool such as Catch
(http://community.haskell.org/~ndm/catch), which actually guarantees
you won't crash, rather than a simple syntactic check. As such, I
think it's perfect to be included in a set of warnings, but not great
to be a default. I also think that if we change our policies every
time someone writes a critical blog we'll be going round in circles
:-)

I'm also not a fan of the overlapping patterns warning being on by
default, as I often write:

foo (Case1 x y z) = ...
foo (Bar x) = ...
foo x = error $ show ("Unhandled in foo",x)

This is overlapping, and for a very good reason.

Thanks

Neil

On Mon, May 18, 2009 at 2:18 AM, Lennart Augustsson
 wrote:
> The exhaustiveness checker in ghc is not good.  It reports
> non-exhaustive matching a bit too often and also the error messages
> are often not in terms of the original source but some desugared
> version.
>
> If those things were improved I think it should be always on.
>
> On Mon, May 18, 2009 at 12:53 AM, Don Stewart  wrote:
>>
>> I'm not sure I'd want -Wall on by default (though being -Wall clean is
>> very good). But exhaustive pattern checking might well help out a lot of
>> people coming from untyped backgrounds.
>>
>>    http://ocaml.janestreet.com/?q=node/64
>>
>> Ron's also wondering why exhaustive pattern checking isn't on ?
>>
>> Anyone know why it isn't the default?
>>
>> -- Don
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: --out-implib when linking shared libraries

[Neil Mitchell]

>> I've just built a Haskell dll on Windows. As part of the process it
>> generated an 14Mb foo.dll, and a 40Mb foo.dll.a. Looking at the flags
>> passed to ld I see --out-implib=foo.dll.a. What is the purpose of the
>> .a file? What might it be needed for? Is it possible to suppress it?
>
> It looks like what you're getting is an import lib that also contains a
> full copy of all the code.

Yes, that seems likely. My guess is it's just a cat of the .o's, with
header tables etc.

> I think it's possible to have minimal .lib files that do not contain any
> code and only refer to the corresponding dll. Further, I think recent
> gnu ld versions can link directly against dlls without using an import
> lib (though you may still need the import lib if you want to use MSVC to
> link to your dll).

I don't, although having that option wouldn't be a bad thing - having
a minimal .lib is perfectly reasonable as a default. Having a massive
.lib seems crazy. (The fact that .lib is named .dll.a isn't too much
of an issue)

> So my suggestion is remove it, if you're linking using gcc it should
> work.

I'm not linking the .dll at all, only using dynamic linking, which
works without the .lib. But I don't really want to start removing
files - doing that in a build system seems like a bad idea.

Thanks

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

--out-implib when linking shared libraries

[Neil Mitchell]

Hi,

I've just built a Haskell dll on Windows. As part of the process it
generated an 14Mb foo.dll, and a 40Mb foo.dll.a. Looking at the flags
passed to ld I see --out-implib=foo.dll.a. What is the purpose of the
.a file? What might it be needed for? Is it possible to suppress it?

I could easily be building 100 of these things and 4Gb of disk for
unused files is a little painful.

Thanks

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

Re: runhaskell a parallel program

[Neil Mitchell]

Hi

>> Isn't ghc -e using the byte-code interpreter?
>
> Yes; apparently it "works", though we still haven't stress-tested it running
> real parallel programs using GHCi with +RTS -N2.

It seemed perfectly stable when I tried, on a few examples I had
knocking around.

>
>>> Still, parallelism
>>> is about performance, and if you want performance you should start by
>>> compiling your program.
>>
>> This is a test framework that spawns system commands. My guess is the
>> Haskell accounts for a few milliseconds of execution per hour. Running
>> two system commands in parallel gives a massive boost.
>
> That still doesn't explain why you need +RTS -N2.  You can spawn multiple
> processes by making multiple calls to runProcess or whatever. If you want to
> wait for multiple processes simultaneously, compile with -threaded and use
> forkIO.

I do need to wait for them - so I don't end up firing too many at
once. I was hoping to avoid the compile, which the ghc -e will give
me.

>> A related question I wanted to ask. Is there any way to have my
>> Haskell program support -j3, which is equivalent to +RTS -N3 -RTS. At
>> the moment I've set this up with a shell script to translate the -j3,
>> but a nicer method would be preferable. Even something as sledgehammer
>> like as restartWithNProcessors :: Int ->  IO (), which aborted the
>> program entirely and restarted main with a completely fresh heap but a
>> given number of processors.
>
> We don't have anything like that right now.  Personally I think the shell
> script method is quite reasonable.

My shell script also does -g1, so for the moment it's not too bad. But
for example I added parallel execution to HLint over the weekend - I
don't want to add a shell script to invoke it, and I'm not entirely
comfortable with documenting +RTS -N2 -RTS as the way to -j3 it. If a
nicer way ever turned out to be relatively pain free to implement, it
would be nice. I'll raise a feature request bug.

Thanks

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

Re: Re[2]: runhaskell a parallel program

[Neil Mitchell]

Hi Bulat,

> Neil, you can implement it by yourself - convert -j3 in cmdline to
> +RTS -N3 -RTS and run program itself. alternatively, you can use
> defaultsHook() although i'm not sure that it can change number of
> Capabilities

Can I run a program itself? getProgName doesn't give me enough to
invoke myself (unfortunately)

I don't want to write any C - that's just more hassle than a shell
script wrapping the command.

Thanks

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

Re: runhaskell a parallel program

[Neil Mitchell]

Hi

>> If however I run it with runhaskell Test.hs +RTS -N2 I get told the
>> -N2 flag isn't supported. Is there a way to runhaskell a program on
>> multiple cores? Is this a bug that it doesn't work, a feature request
>> I'm making, or is there some trick to getting it working I haven't
>> thought of? I'll raise a bug report if that turns out to be the right
>> thing.
>
> As a workaround you could use 'ghc -e main foo.hs +RTS -N2'.

That works great :-) Perhaps this trick should be documented? I
thought runhaskell was just sugar over ghc -e, so couldn't it share
the same mechanism?

> What's interesting to me is whether the byte-code interpreter will work right 
> with +RTS -N2

Isn't ghc -e using the byte-code interpreter?

> Still, parallelism
> is about performance, and if you want performance you should start by
> compiling your program.

This is a test framework that spawns system commands. My guess is the
Haskell accounts for a few milliseconds of execution per hour. Running
two system commands in parallel gives a massive boost.

A related question I wanted to ask. Is there any way to have my
Haskell program support -j3, which is equivalent to +RTS -N3 -RTS. At
the moment I've set this up with a shell script to translate the -j3,
but a nicer method would be preferable. Even something as sledgehammer
like as restartWithNProcessors :: Int -> IO (), which aborted the
program entirely and restarted main with a completely fresh heap but a
given number of processors.

Thanks

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

runhaskell a parallel program

[Neil Mitchell]

Hi,

I've got a program which I'd like to run on multiple threads. If I
compile it with ghc --make -threaded, then run with +RTS -N2 it runs
on 2 cores very nicely.

If however I run it with runhaskell Test.hs +RTS -N2 I get told the
-N2 flag isn't supported. Is there a way to runhaskell a program on
multiple cores? Is this a bug that it doesn't work, a feature request
I'm making, or is there some trick to getting it working I haven't
thought of? I'll raise a bug report if that turns out to be the right
thing.

Thanks

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

Re: writeFile/readFile on multiple threads leads to error

[Neil Mitchell]

>> I have many threads, which read and write files. Every so often one
>> thread will write a file, then another thread will read the same file
>> - but fail during the open call. There are locks to ensure that the
>> write call finishes before the read call begins. I modified the code
>> to give:
>>
>> The writeFile/readFile are happening in different threads, and they
>> usually succeed - but not always. The bug seems to go away when I add
>> performGC just after writeFile. My guess is that something in the
>> openFile/hClose pair isn't really closed until a garbage collection
>> happens. All this is using GHC 6.10.2 on XP through Cygwin.
>
> The hClose really does close the file descriptor.  The only thing left
> is the finalizer, but it is just a no-op on an already-closed Handle.
>
> I can't think of anything we're doing that could possibly cause this,
> but I have seen rogue "permission denied" errors on Windows from time
> to time, they're quite annoying.  Here's a possibly-related ticket:
>
> http://hackage.haskell.org/trac/ghc/ticket/2924

I've added information from this thread to that ticket. It looks
suspiciously similar, and I have a feeling that some combination of
writeFile/readFile in a similar pattern might invoke the same issue -
it's certainly quite close to the behaviour of my application.

> You might want to run the process under ProcMon and see if you can
> figure out what's going on (if you can bear to use ProcMon, it's a
> very poor replacement for strace IMO).

I tried and the bug goes away, plus the computer grinds to a crunching
halt. The bug is very sensitive, and with the speed loss associated
with ProcMon probably disappears on its own. No useful information can
be obtained there.

Thanks

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

Re: writeFile/readFile on multiple threads leads to error

[Neil Mitchell]

Bulat: I haven't tried moving to Posix calls, I'll try that next -
although I was hoping the application wouldn't be posix dependent.

>> readFile calls openFile >>= hGetContents. It's the openFile that
>> causes the problem, so READ START happens before openFile and READ
>> STOP happens after openFile. The lazy semantics of the actual reading
>> don't seem to have an effect.
>
> Just want to make sure that it isn't the latent hClose from readFile.

Yeah, I've done that before! It seems to be the writeFile that isn't
closing, not the readFile - hence my surprise.

>> I did try changing to the strict bytestring file read, and that gave
>> exactly the same error - apart from openBinaryFile was crashing rather
>> than openFile.
>
> Weren't there versions of bytestring that didn't close the file early
> enough?

I only used bytestring for reading, so it shouldn't have made any difference.

Thanks

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

Re: writeFile/readFile on multiple threads leads to error

[Neil Mitchell]

Hi Claus,

>> do print ("READ START",x) ; res <- readFile x ; print ("READ STOP",x)
>> ; return res
>
> Unless you've defined your own version of 'readFile', to mean read
> entire file now, the first 'print' is optimistic and the second 'print' is a
> lie.

readFile calls openFile >>= hGetContents. It's the openFile that
causes the problem, so READ START happens before openFile and READ
STOP happens after openFile. The lazy semantics of the actual reading
don't seem to have an effect.

I did try changing to the strict bytestring file read, and that gave
exactly the same error - apart from openBinaryFile was crashing rather
than openFile.

Thanks

Neil

>> do print ("WRITE START",x); writeFile x src ; print ("WRITE STOP",x)
>>
>> I then get on the console:
>>
>> WRITE START foo
>> WRITE STOP foo
>> READ START foo
>> openFile doesn't have permission to open foo.
>>
>> The writeFile/readFile are happening in different threads, and they
>> usually succeed - but not always. The bug seems to go away when I add
>> performGC just after writeFile. My guess is that something in the
>> openFile/hClose pair isn't really closed until a garbage collection
>> happens. All this is using GHC 6.10.2 on XP through Cygwin.
>>
>> I'm happy to supply more details if you can think of anything that will
>> help,
>>
>> Thanks
>>
>> Neil
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: writeFile/readFile on multiple threads leads to error

[Neil Mitchell]

>  Is it too difficult to try this on Linux or Mac, just to see
>  if it shows up there as well?

Yes ;-)

I might be able to try it on Linux next week, but that's as far as I'm
likely to be able to go. If I get any results I'll email them in.

Thanks

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

writeFile/readFile on multiple threads leads to error

[Neil Mitchell]

Hi,

I've got a multi-threaded application which occasionally generates
failures in openFile. I haven't been able to reproduce the errors
reliably, the code is way too large to send over, and any small
attempts at invoking the same problem don't seem to work. Despite the
uselessness of the bug report, I thought I'd share what I've seen and
how I fixed it.

I have many threads, which read and write files. Every so often one
thread will write a file, then another thread will read the same file
- but fail during the open call. There are locks to ensure that the
write call finishes before the read call begins. I modified the code
to give:

do print ("READ START",x) ; res <- readFile x ; print ("READ STOP",x)
; return res

do print ("WRITE START",x); writeFile x src ; print ("WRITE STOP",x)

I then get on the console:

WRITE START foo
WRITE STOP foo
READ START foo
openFile doesn't have permission to open foo.

The writeFile/readFile are happening in different threads, and they
usually succeed - but not always. The bug seems to go away when I add
performGC just after writeFile. My guess is that something in the
openFile/hClose pair isn't really closed until a garbage collection
happens. All this is using GHC 6.10.2 on XP through Cygwin.

I'm happy to supply more details if you can think of anything that will help,

Thanks

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

Re: Parallel performance drops off a cliff

[Neil Mitchell]

>> > Yes, what's happening is this: GHC 6.10.2 contains some slightly bogus
>> > heuristics about when to turn on the parallel GC, and it just so
>> > happens that 8 processors tips it over the point where the parallel GC
>> > is enabled for young-generation collections.  In 6.10.2 the parallel
>> > GC really didn't help most of the time, but it has undergone a lot of
>> > tuning since then, and in the HEAD things are much better (see the
>> > results from our ICFP submission).
>>
>> Fantastic! I'll disable parallel garbage collection (I'm fairly
>> certain it won't have any effect for this application).
>
> How many cores are you planning to use? ...

16 on the best machine we've got. This particular application is a bit
weird, I suspect it will be spending very little time actually
executing Haskell and most of the time waiting for shell commands. As
such, the efficiency of Haskell isn't a problem - parallel garbage
collection shouldn't make any difference.

Thanks

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

Re: Parallel performance drops off a cliff

[Neil Mitchell]

Hi

>> This is using GHC 6.10.2 on Windows XP, 2 processors. Is this a known
>> bug, or should I try and replicate it? (benchmark is fairly big and
>> very dependent on internal things, but I suspect the dramatic
>> performance slowdown is unlikely to be related to these bits).
>
> Yes, what's happening is this: GHC 6.10.2 contains some slightly bogus
> heuristics about when to turn on the parallel GC, and it just so
> happens that 8 processors tips it over the point where the parallel GC
> is enabled for young-generation collections.  In 6.10.2 the parallel
> GC really didn't help most of the time, but it has undergone a lot of
> tuning since then, and in the HEAD things are much better (see the
> results from our ICFP submission).

Fantastic! I'll disable parallel garbage collection (I'm fairly
certain it won't have any effect for this application).

Thanks

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

Parallel performance drops off a cliff

[Neil Mitchell]

Hi,

Using one benchmark I have, which doesn't create any threads, I have:

$ benchmark +RTS -Nx

x time (Seconds)
1  2
2  2
3  2
4  3
5  3
6  3
7  3
8  aborted after 2 minutes

This is using GHC 6.10.2 on Windows XP, 2 processors. Is this a known
bug, or should I try and replicate it? (benchmark is fairly big and
very dependent on internal things, but I suspect the dramatic
performance slowdown is unlikely to be related to these bits).

Thanks

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

Re: GHC threading bug in QSem

[Neil Mitchell]

I've now raised a ticket to track this issue:
http://hackage.haskell.org/trac/ghc/ticket/3159

Thanks, Neil

On Wed, Apr 8, 2009 at 11:26 AM, Neil Mitchell  wrote:
> Hi
>
> I believe the following program should always print 100:
>
> import Data.IORef
> import Control.Concurrent
>
> main = do
>    sem <- newQSem (-99)
>    r <- newIORef 0
>    let incRef = atomicModifyIORef r (\a -> (a+1,a))
>    sequence_ $ replicate 100 $ forkIO $ incRef >> signalQSem sem
>    waitQSem sem
>    v <- readIORef r
>    print v
>
> Unfortunately, it doesn't seem to. Running on a 2 processor machine,
> with +RTS -N3 I usually get 100, but have got answers such as 49, 82,
> 95. With +RTS -N2 it doesn't seem to fail, but it does with -N4. This
> is using GHC 6.10.2 on Windows. Using GHC 6.8.3, I get answers /= 100
> roughly every other time.
>
> From reading the implementation of QSem, it doesn't seem that negative
> availability was considered. I think it would be need to be changed
> as:
>
> -- Invariant: avail >= 1 ==> null blocked
>
> waitQSem :: QSem -> IO ()
> waitQSem (QSem sem) = do
>   (avail,blocked) <- takeMVar sem  -- gain ex. access
>   if avail > 0 then
>     putMVar sem (avail-1,[])
>    else do
>     block <- newEmptyMVar
>     putMVar sem (avail, blocked++[block])   -- changed line
>     takeMVar block
>
> signalQSem :: QSem -> IO ()
> signalQSem (QSem sem) = do
>   (avail,blocked) <- takeMVar sem
>   -- changed below
>   if null blocked || avail < 0 then
>      putMVar sem (avail+1,blocked)
>   else
>      putMVar sem (avail, tail blocked)
>      putMVar (head blocked) ()
>
> Writing parallel code is hard, so I could have easily got this wrong.
> I haven't looked at QSemN, which may need similar fixes (or may
> already deal with this)
>
> Thanks
>
> Neil
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

GHC threading bug in QSem

[Neil Mitchell]

Hi

I believe the following program should always print 100:

import Data.IORef
import Control.Concurrent

main = do
sem <- newQSem (-99)
r <- newIORef 0
let incRef = atomicModifyIORef r (\a -> (a+1,a))
sequence_ $ replicate 100 $ forkIO $ incRef >> signalQSem sem
waitQSem sem
v <- readIORef r
print v

Unfortunately, it doesn't seem to. Running on a 2 processor machine,
with +RTS -N3 I usually get 100, but have got answers such as 49, 82,
95. With +RTS -N2 it doesn't seem to fail, but it does with -N4. This
is using GHC 6.10.2 on Windows. Using GHC 6.8.3, I get answers /= 100
roughly every other time.

>From reading the implementation of QSem, it doesn't seem that negative
availability was considered. I think it would be need to be changed
as:

-- Invariant: avail >= 1 ==> null blocked

waitQSem :: QSem -> IO ()
waitQSem (QSem sem) = do
   (avail,blocked) <- takeMVar sem  -- gain ex. access
   if avail > 0 then
 putMVar sem (avail-1,[])
else do
 block <- newEmptyMVar
 putMVar sem (avail, blocked++[block])   -- changed line
 takeMVar block

signalQSem :: QSem -> IO ()
signalQSem (QSem sem) = do
   (avail,blocked) <- takeMVar sem
   -- changed below
   if null blocked || avail < 0 then
  putMVar sem (avail+1,blocked)
   else
  putMVar sem (avail, tail blocked)
  putMVar (head blocked) ()

Writing parallel code is hard, so I could have easily got this wrong.
I haven't looked at QSemN, which may need similar fixes (or may
already deal with this)

Thanks

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

copyFile and thread safety

[Neil Mitchell]

Hi,

Using GHC 6.8.3, the copyFile routine isn't thread safe - it crashes
when two threads try and open the same file. I think that improvements
were made to avoid security race conditions in GHC 6.10.1 (or the base
library associated with it), and as a nice side effect they seem to
have fixed the copyFile issues. However, it would be nice if someone
could assure me that the copyFile issues were real but are now fixed.
Replicating them is hard, but they randomly occur during a 1-hour
build on my laptop, but not my desktop.

I also note that copyFile starts with the process id and increments
looking for a free filename. While that's fantastic if you are
avoiding races with other processes (as I think the improvements were
intended to address), it's not so great for avoiding races within the
same process when different threads attempt to copy lots of files at
once. In doing this, I suspect I've suffered lots of retries in the
temporary name creation algorithm - should I be concerned about the
performance aspect of this? Would an atomicModifyIORef and global temp
file counter be a good idea?

For now, I've got no immediate problems as I simply shell out to "cp"
to do the copying - but it would be nice if the Haskell worked too.

Thanks

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

Re: Really bad code for single method dictionaries?

[Neil Mitchell]

Hi Jason,

While experimenting with Uniplate I found that 1-member dictionaries
were faster than N element dictionaries - which seems to run against
what you see in the comment. 1-member dictionaries being cheaper does
make sense as then instead of passing a tuple containing functions,
you can pass the direct function, and save yourself a (cheap) selector
call at every use.

Thanks

Neil

On Thu, Mar 26, 2009 at 11:29 PM, Jason Dusek  wrote:
>  I was reading the stream fusion code today and came across a comment stating
>  that single element dictionaries interacted poorly with GHC's optimizer:
>
>    class Unlifted a where
>
>      [...]
>      expose [...]
>
>      -- | This makes GHC's optimiser happier; it sometimes produces really bad
>      -- code for single-method dictionaries
>      --
>      unlifted_dummy [...]
>
>  A cursory search on GHC's Trac shows no corresponding bug; is this no longer
>  a problem? A small problem? I would like to know more about it.
>
> --
> Jason Dusek
>
>
>
>  |...stream fusion code...|
>  http://www.cse.unsw.edu.au/~dons/code/streams/list/Data/Stream.hs
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: compilation of pattern-matching?

[Neil Mitchell]

Hi

> Your idea of simply ordering patterns is certainly appealing from the 
> programming point of view.  I don't yet see how to propagate that information 
> through the pattern compilation algorithm, retain the resulting information 
> in the optimizer, and exploit it in a code generator.  But it might well be 
> possible. Maybe you can write a Haskell workshop paper about it?

I don't find ordering of patterns appealing, I find it scary! I order
my patterns according to the semantics I desire, and then additionally
by what looks pretty. I'd like it if whatever cleverness GHC can work
is used rather than requiring me to think. If the order of patterns is
to become important, it has to be with an explicit "look, I know
something you don't" pragma rather than by default.

As an example, I suspect that the "hot-path" on most list pattern
matches is in the (:) case. I don't want to ever teach a user that (:)
comes before [] because ... long spiel about branch prediction ...

Controlling branch prediction will only ever be a niche activity, so
the defaults should reflect that.

Thanks

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

Re: Windows building instructions

[Neil Mitchell]

Hi Simon,

I got a brand new Vista machine yesterday (and a brand new monitor
this morning), running Vista. I'll try out these instructions as soon
as its all plugged together.

When I had my last stab at compiling GHC I ended up creating a little
script to automate some of the common bits and provide basic sanity
checking. I've attached the script in case anyone finds it useful.

Thanks

Neil

On Tue, Mar 10, 2009 at 12:45 PM, Simon Marlow  wrote:
> I've made a start on sanitising the Windows building instructions, and
> generally reoganising the Windows-related stuff in the wiki.  Basicalliy my
> plan is to:
>
>  - Simplify the instructions.  In lots of places we have stuff like "if you
>   get the following bizarre error message ... then do this ...".  I'd
>   rather have a set of simple instructions that just work, with a separate
>   (searchable) page for troubleshooting advice.  So now we have
>
>   http://hackage.haskell.org/trac/ghc/wiki/Building/Troubleshooting
>
>   which is just a list of error messages and solutions, collected from
>   various other places in the docs.  If you encounter an error that isn't
>   listed on that page, please add it (guidelines for adding stuff are at
>   the top).
>
>  - Merge the Windows-specific instructions with the rest of the docs, so
>   we can avoid repetition.  So now the instructions for how to set
>   up your Windows system for building GHC are on the main "prerequisites"
>   page:
>
>   http://hackage.haskell.org/trac/ghc/wiki/Building/Prerequisites
>
>  - I've uploaded a set of build tools that work (just MSYS for now) to
>   haskell.org, and linked them from the wiki.  This morning I started
>   from a fresh Vista system, installed these tools, and managed to
>   do a complete validate of the GHC HEAD, with 1 test failure.
>
>
> What we still need to do:
>
>  - Expand the instructions to include Cygwin.  I've linked to the
>   existing Cygwin instructions for now, but I think they need
>   simplifying.
>
>  - Add more common failures and troubleshooting tips.
>
>  - Merge in contrib docs, e.g.
>
>   http://hackage.haskell.org/trac/ghc/wiki/ProblemsCompilingGhc
>
> I'd be grateful for any help with this - just edit away!
>
> Cheers,
>        Simon
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>


winbuild.hs
Description: Binary data
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: finally part run twice on Ctrl-C

[Neil Mitchell]

Hi

I have filed bug http://hackage.haskell.org/trac/ghc/ticket/3081 to
track this issue, marking it as effecting Windows only.

Thanks

Neil

On Fri, Feb 27, 2009 at 8:45 AM, Philip K.F. Hölzenspies
 wrote:
> On Friday 27 February 2009 09:39:14 Neil Mitchell wrote:
>> It looks like you are running in GHCi, which I think works. It's only
>> when the program is compiled and run from the command line (Cygwin or
>> DOS) that I get the above problem.
>
> Dear Neil,
>
> You were right. When I do compile it, though, I get the same (correct)
> behaviour (now I pressed Ctrl-C the first run and let it be for the second):
>
> holze...@ewi1043:~/tmp> ghc Test.hs
> holze...@ewi1043:~/tmp> ./a.out
> goodbye
> holze...@ewi1043:~/tmp> ./a.out
> goodbye
> holze...@ewi1043:~/tmp>
>
> This is on Linux, though, so it may also be OS-dependent.
>
> Regards,
> Philip
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: finally part run twice on Ctrl-C

[Neil Mitchell]

Hi Philip,

> Just to let you know; I tried it on the release version of 6.10.1 and it
> worked as expected (first run, I waited; second I pressed Ctrl-C):
>
> *Test> main
> goodbye
> ExitSuccess
> *Test> main
> goodbye
> ExitFailure 2
> *Test>

It looks like you are running in GHCi, which I think works. It's only
when the program is compiled and run from the command line (Cygwin or
DOS) that I get the above problem.

Thanks

Neil;
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

finally part run twice on Ctrl-C

[Neil Mitchell]

Hi,

I've got the following code:

import Control.Exception
import System.Cmd
main = system "sleep 1m" `finally` putStrLn "goodbye"

When compiled with GHC 6.10.1.20090225, if I hit Ctrl-C during the
sleep, I get the goodbye printed twice. If I leave evaluation to
finish normally I get goodbye once. Is this a bug?

Thanks

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

Re: DLL support with GHC

[Neil Mitchell]

>> What is the current status of shared object support within GHC? Using
>> GHC 6.10.2 (or the branch for it) I can create DLL's under Windows,
>> following these instructions:
>> http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html
>> .Can a similar thing be done under Linux? If so, where is this
>> documented?
>
> No, you can't do that yet.  Here's the ticket:
>
> http://hackage.haskell.org/trac/ghc/ticket/1876

Thanks, I've added myself to the CC.

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

Users guide missing

[Neil Mitchell]

Hi

The web page: http://haskell.org/haskellwiki/GHC

Links to the latest users guide as a PDF, unfortunately the file is missing:
http://www.haskell.org/ghc/docs/latest/users_guide.pdf

Thanks

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

Re: [Haskell-cafe] createProcess shutting file handles

[Neil Mitchell]

> However the createProcess command structure has the close_fds flag,
> which seems like it should override that behaviour, and therefore this
> seems like a bug in createProcess.

close_fds :: Bool

Close all file descriptors except stdin, stdout and stderr in
the new process

 This refers to inheriting open unix file descriptors (or Win32 HANDLEs)
 in the child process. It's not the same as closing the Haskell98 Handles
 in the parent process that you pass to the child process.
>>>
>>> So lets not talk about if the current behaviour is a bug or not. It's
>>> reasonably clear (if not brilliantly well documented) that it's the
>>> intended behaviour.
>>>
>>> The thing we want to talk about is what reason is there for the current
>>> behaviour, if that's necessary and if it is the sensible default
>>> behaviour. As I said before I don't know why it is the way it is. I'm
>>> cc'ing the ghc users list in the hope that someone there might know.
>>
>> One guiding principle of resource management is that whoever
>> opens/allocates something should release/free it. i.e. if you did the
>> malloc you do the free. For that reason it seems weird that I call
>> openFile but someone else calls hClose on my behalf.
>>
>> Plus, in my particular application, the above behaviour is necessary
>> or I'm going to have to write to a file, open that file, and copy it
>> over to my intended file (which is what I will end up doing, no
>> doubt!)
>
> I don't remember exactly why it's done this way, but it might have something
> to do with trying to maintain the (possibly ill-conceived) Haskell98
> file-locking principle.  System.Posix.handleToFd also closes the Handle,
> FWIW.
>
> There's nothing stopping you from re-opening the file and seeking to the
> end, as a workaround.

"openFile file AppendMode" is how I ended up doing it, which saves
writing a seek in there. It works just fine, merely at the cost of
closing/opening handles more than necessary.

> I could probably be convinced without much difficulty that we should stop
> closing these Handles; however I do have a vague feeling that I'm forgetting
> something!

Documenting it more clearly would be helpful. As for changing the
behaviour - while I think the other way round would be much better, it
brings up loads of reverse compatibility headaches, so I'm not sure
its worth it.

Thanks

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

Re: [Haskell-cafe] createProcess shutting file handles

[Neil Mitchell]

Hi

>> > However the createProcess command structure has the close_fds flag,
>> > which seems like it should override that behaviour, and therefore this
>> > seems like a bug in createProcess.
>>
>> close_fds :: Bool
>>
>> Close all file descriptors except stdin, stdout and stderr in
>> the new process
>>
>> This refers to inheriting open unix file descriptors (or Win32 HANDLEs)
>> in the child process. It's not the same as closing the Haskell98 Handles
>> in the parent process that you pass to the child process.
>
> So lets not talk about if the current behaviour is a bug or not. It's
> reasonably clear (if not brilliantly well documented) that it's the
> intended behaviour.
>
> The thing we want to talk about is what reason is there for the current
> behaviour, if that's necessary and if it is the sensible default
> behaviour. As I said before I don't know why it is the way it is. I'm
> cc'ing the ghc users list in the hope that someone there might know.

One guiding principle of resource management is that whoever
opens/allocates something should release/free it. i.e. if you did the
malloc you do the free. For that reason it seems weird that I call
openFile but someone else calls hClose on my behalf.

Plus, in my particular application, the above behaviour is necessary
or I'm going to have to write to a file, open that file, and copy it
over to my intended file (which is what I will end up doing, no
doubt!)

Thanks

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

DLL thread safety

[Neil Mitchell]

Hi,

I'm building a DLL using the instructions here:
http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html

I must call startupHaskell before I make any calls to Haskell
functions. However, that page doesn't detail any thread safety rules.
In particular:

* If I call startupHaskell on Thread 1, can I make Haskell calls from Thread 2.

* Can I make Haskell calls from both Thread 1 and Thread 2 simultaneously.

Many thanks

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

DLL support with GHC

[Neil Mitchell]

Hi,

What is the current status of shared object support within GHC? Using
GHC 6.10.2 (or the branch for it) I can create DLL's under Windows,
following these instructions:
http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html
.Can a similar thing be done under Linux? If so, where is this
documented?

Many thanks

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

Re: Pragma not recognised when wrapped in #ifdef

[Neil Mitchell]

Hi

> Is there still a need for CPP now that Template Haskell exists?

Yes. For a start you might need CPP to switch between Haskell
compilers that do and don't support Template Haskell! Both
technologies do different things, CPP is great for conditional
compilation based on compiler version/features - i.e. using either
deriving (Eq) or deriving (Data,Typeable,Eq) where the latter is
supported. Also for doing imports which have changed between versions,
i.e. import Data.Data or Data.Generics depending on version.

Using the CPP textual replacement/macro substitution facilities is
more debatable, and in many of these cases Template Haskell is a
better choice.

Thanks

Neil

>
> 2009/2/11 Simon Peyton-Jones :
>> | Perhaps CPP shouldn't be a pragma, just a command-line flag? It seems
>> | to be the only one that affects/involves preprocessor(s). AFAICT, the
>> | others all affect the haskell compiler stage.
>>
>> Yes, it does seem anomalous.  I suppose the motivation is that some modules 
>> might need CPP and some not, and it's convenient for the module itself to 
>> announce that fact.
>>
>> Simon
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type signature inside an instance declaration

[Neil Mitchell]

Hi

> You want to use `asTypeOf`, with a lazy pattern to name a value of type 'a'.
>
>pr xs = "[" ++ pr (undefined `asTypeOf` x) ++ "]"
>where (x:_) = xs

I prefer:

pr xs = "[" ++ pr (undefined `asTypeOf` head x) ++ "]"

Or even more simply:

pr xs = "[" ++ pr (head x) ++ "]"

I do believe there is some GHC extension that can be turned on to
refer to variables like you did, but its not standard Haskell.

Thanks

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

Re: length of module name affecting performance??

[Neil Mitchell]

Hi

>> I'm using GHC 6.10.1 on OS X. Any ideas on what may be going on?
>
> Wow. Awesome bug! Got lots of discussion at Galois :)
>
> I can confirm a difference in running time, we also tested with 6.8.x and 
> 6.10,
> with similar results.

Is -O2 implying -fvia-C? If so, could it be the evil mangler? Is there
a non-alpha rename difference in the Core?

Very cool bug :-)

Thanks

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

Re: cross module optimization issues

[Neil Mitchell]

Hi

>> instance Monad m => Monad (IterateeGM el m) where
>>   {-# SPECIALISE instance Monad (IterateeGM el IO) #-}
>>
>> does that help?

Yes. With that specialise line in, we get identical performance
between the two results.

So, in summary:

The print_lines function uses the IterateeGM with IO as the underlying
monad, which causes GHC to specialise IterateeGM with IO. If
print_lines is not exported, then it is deleted as dead code, and the
specialisation is never generated. The specialisation is crucial for
performance later on. In this way, by keeping unused code reachable,
GHC does better optimisation.

> Once Simon and Neil dig the issue and analyze it, the reason seems evident.
> But this thread reminds of why writing high performance Haskell code is
> regarded as a black art outside the community (well, and sometimes inside
> too).
>
> Wouldn't a JIT version of GHC be a great thing to have?
> Or would a backend for LLVM be already beneficial enough?

I don't think either would have the benefits offered by
specialisation. If GHC exported more information about instances, it
could do more specialisations later, but it is a trade off. If you ran
GHC in some whole-program mode, then you wouldn't have the problem,
but would gain additional problems.

I always hoped Supero (http://www-users.cs.york.ac.uk/~ndm/supero/)
would remove some of the black art associated with program
optimisation - there are no specialise pragmas, and I'm pretty sure in
the above example it would have done the correct thing. In some ways,
whole-program and fewer special cases gives a much better mental model
of how optimisation might effect a program. Of course, its still a
research prototype, but perhaps one day...

Thanks

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

Re: cross module optimization issues

[Neil Mitchell]

Hi

I've talked to John a bit, and discussed test cases etc. I've tracked
this down a little way.

Given the attached file, compiling witih SHORT_EXPORT_LIST makes the
code go _slower_. By exporting the "print_lines" function the code
doubles in speed. This runs against everything I was expecting, and
that Simon has described.

Taking a look at the .hi files for the two alternatives, there are two
differences:

1) In the faster .hi file, the body of print_lines is exported. This
is reasonable and expected.

2) In the faster .hi file, there are additional specialisations, which
seemingly have little/nothing to do with print_lines, but are omitted
if it is not exported:

"SPEC >>= [GHC.IOBase.IO]" ALWAYS forall @ el
 $dMonad :: GHC.Base.Monad GHC.IOBase.IO
  Sound.IterateeM.>>= @ GHC.IOBase.IO @ el $dMonad
  = Sound.IterateeM.a
  `cast`
(forall el1 a b.
 Sound.IterateeM.IterateeGM el1 GHC.IOBase.IO a
 -> (a -> Sound.IterateeM.IterateeGM el1 GHC.IOBase.IO b)
 -> trans
(sym ((GHC.IOBase.:CoIO)
  (Sound.IterateeM.IterateeG el1 GHC.IOBase.IO b)))
(sym ((Sound.IterateeM.:CoIterateeGM) el1 GHC.IOBase.IO b)))
  @ el
"SPEC Sound.IterateeM.$f2 [GHC.IOBase.IO]" ALWAYS forall @ el
 $dMonad ::
GHC.Base.Monad GHC.IOBase.IO
  Sound.IterateeM.$f2 @ GHC.IOBase.IO @ el $dMonad
  = Sound.IterateeM.$s$f2 @ el
"SPEC Sound.IterateeM.$f2 [GHC.IOBase.IO]" ALWAYS forall @ el
 $dMonad ::
GHC.Base.Monad GHC.IOBase.IO
  Sound.IterateeM.$f2 @ GHC.IOBase.IO @ el $dMonad
  = Sound.IterateeM.$s$f21 @ el
"SPEC Sound.IterateeM.liftI [GHC.IOBase.IO]" ALWAYS forall @ el
   @ a
   $dMonad ::
GHC.Base.Monad GHC.IOBase.IO
  Sound.IterateeM.liftI @ GHC.IOBase.IO @ el @ a $dMonad
  = Sound.IterateeM.$sliftI @ el @ a
"SPEC return [GHC.IOBase.IO]" ALWAYS forall @ el
$dMonad :: GHC.Base.Monad
GHC.IOBase.IO
  Sound.IterateeM.return @ GHC.IOBase.IO @ el $dMonad
  = Sound.IterateeM.a7
  `cast`
(forall el1 a.
 a
 -> trans
(sym ((GHC.IOBase.:CoIO)
  (Sound.IterateeM.IterateeG el1 GHC.IOBase.IO a)))
(sym ((Sound.IterateeM.:CoIterateeGM) el1 GHC.IOBase.IO a)))
  @ el

My guess is that these cause the slowdown - but is there any reason
that print_lines not being exported should cause them to be omitted?

All these tests were run on GHC 6.10.1 with -O2.

Thanks

Neil


On Fri, Nov 21, 2008 at 10:33 AM, Simon Peyton-Jones
<[EMAIL PROTECTED]> wrote:
> | This project is based on Oleg's Iteratee code; I started using his
> | IterateeM.hs and Enumerator.hs files and added my own stuff to
> | Enumerator.hs (thanks Oleg, great work as always).  When I started
> | cleaning up by moving my functions from Enumerator.hs to MyEnum.hs, my
> | minimal test case increased from 19s to 43s.
> |
> | I've found two factors that contributed.  When I was cleaning up, I
> | also removed a bunch of unused functions from IterateeM.hs (some of
> | the test functions and functions specific to his running example of
> | HTTP encoding).  When I added those functions back in, and added
> | INLINE pragmas to the exported functions in MyEnum.hs, I got the
> | performance back.
> |
> | In general I hadn't added export lists to the modules yet, so all
> | functions should have been exported.
>
> I'm totally snowed under with backlog from my recent absence, so I can't look 
> at this myself, but if anyone else wants to I'd be happy to support with 
> advice and suggestions.
>
> In general, having an explicit export list is good for performance. I typed 
> an extra section in the GHC performance resource 
> http://haskell.org/haskellwiki/Performance/GHC to explain why.  In general 
> that page is where we should document user advice for performance in GHC.
>
> I can't explain why *adding* unused functions would change performance though!
>
> Simon
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
{-# LANGUAGE CPP #-}

{- This file was originally take from http://okmij.org/ftp/Haskell/Iteratee/,
and modified to suit this project
-}

-- #define SHORT_EXPORT_LIST 1

module Sound.IterateeM (
  StreamG (..),
  IterateeG (..),
  IterateeGM (..),
  liftI,
  (>>==),
  (==<<),
  stream2list,
  sbreak,
  sdropWhile,
  snext,
  speek,
  skip_till_eof,
  sdrop,
  stake,
  map_stream,
  EnumeratorGM,
  enum_eof,
  enum_err,
  (>.),
  enum_pure_1chunk,
  enum_pure_nchunk,
  enum_h,
  enum_file,
#ifdef SHORT_EXPORT_LIST
#else
  print_lines,
#endif
)

{-
-- #ifdef SHORT_EXPORT_LIST
-- #else 
--   Iteratee,
--   IterateeM,
--   Stream,
--

Re: #ghc connection issue

[Neil Mitchell]

Hi Claus,

> I seem to be unable to join the ghc chatroom at irc.freenode.net
> at the moment (using Opera). Is that an issue with my irc client or a
> general problem?

I have joined just fine, using mibbit.com (from in Opera)

Thanks

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

Re: Version control systems

[Neil Mitchell]

Hi

> So I suggest we propose moving all the core packages to git, and we
> translate all those for which nobody objects to the change.  For the others,
> we'll keep them in darcs and live with the pain.

Does this mean my (now the communities) FilePath library is going to
get moved over to git?

I personally don't know Git, and while I'm sure I'll be learning at
some point, I'm always nervous about learning a VCS on something I
care about, as mistakes can go quite wrong. In addition, things like
the Yhc build scripts already check out the darcs version, so will
have to be modified*.

If it really makes the life easier for people who are having lots of
VCS pain at the moment, then its hard to object. But many of the
comments in this discussion, about how everyone is going to flock to
GHC just as soon as it switches to Git, seem overly optimistic. I
think GHC is a few years off becoming drive-by hacker friendly, for
many other reasons.

The halfway house of switching the compiler, and leaving the libraries
in darcs, seems desirable. If Git turns out to be wonderful, as people
claim, moving the whole way over is fairly easy and a simple choice.

Thanks

Neil

* Modifying the Yhc build scripts is much harder than modifying the
GHC build script, as they are 10,000 lines of Python (a language I
don't know) in a very complex framework (which I also don't know)! Of
course, this is something for the Yhc team to deal with...
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANN: prof2dot, version 0.4.1

[Neil Mitchell]

Hi Gregory,

Sounds fantastic. I'd love to see a single example of the resultant
.dot file, so I can figure out just how useful this might be to me.

Thanks

Neil

On Tue, Aug 5, 2008 at 8:50 PM, Gregory Wright <[EMAIL PROTECTED]> wrote:
>
> I am pleased to announce the release of prof2dot version 0.4.1,
> a graphical profiling tool for use with GHC.
>
> The program is a filter that takes the profiling output generated by running
> a GHC-compiled program with the "+RTS -px -RTS" option and turns it into
> a dot file.  (The "dot" format is a textual representation of a directed or
> undirected graph.)
> The dot file can rendered in any format supported by Graphviz's
> dot program, and the file itself can be post-processed or edited to adjust
> the
> layout.
>
> The new release fixes a number of bugs and has some significant
> improvements in its internal organization over the previous 0.3.1
> ("Premature Optimizations 'r' Us") release.
>
> Version 0.4.1 ("Triumph of Hope Over Experience") defaults to generating
> a call graph colored by number of entries into each call center.  There
> is now an option to annotate the graph edges with the triple of
> (cost center entries, ticks, allocations).  Module names are also given
> in each cost center.
>
> The latest version has been tested on the profiling output of some
> moderately
> large programs, e.g., the profile produced by a "darcs get" of the entire
> ghc repository:
>
>$ darcs get http://darcs.haskell.org/ghc +RTS -px -RTS
>
> There is also better error reporting of parser errors and consistency
> checking
> of the internal graph data structure.  If anyone comes across a parse
> failure
> or an assertion failure, please report it to the author.
>
> The "dot" program from the graphviz tools is required to render the output
> of prof2dot.
> Very large graphs, or graphs with extensive annotations, can exceed the
> capabilities of dot.
>
> Prof2dot is available from Hackage in the "development" category.
>
> -Greg
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Weekly IRC meeting?

[Neil Mitchell]

Hi

>  > Another option is a conference call, but personally I prefer the IRC medium
>  > for this kind of meeting.  A conference call could work too, though.
>
> i propose to sent every meeting log into cvs-ghc

I second this. The mibbit.com IRC client is currently blocked by
freenode.net, so I am unable to participate, and would like to see a
log :-)

Thanks

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

Re: -optc-O2 considered useful

[Neil Mitchell]

Hi

> As for the specific issue of whether we should turn on -fstrictness with
> -O0, I suspect the answer is that the compile-time cost would be too high.

There would also be the issue that it would increase the amount of
Haskell code which works only in GHC, which is probably a bad thing.
Would the strictness still recover the loop if they turned on
hpc/profiling? I can see many reasons why making things faster is
good, but making things asymptotically faster/less space in -O0 could
bite later.

One ticket that probably makes a big difference in -O0 is:
http://hackage.haskell.org/trac/ghc/ticket/2207

Thanks

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

Re: Performance: Faster to define a function writing out all arguments?

[Neil Mitchell]

Hi

>  And strangely enough on my machine 1) is faster by a few percent than

Consider a few percent to be "noise". It may not really be a faster
result, and it may not have anything to do with what you wrote.

> A few percent might seem unimportant, but I am
> currently developing my Haskell style. And I want to write efficient code by
> default, if that doesn't lead to obfuscation.

Write clear code by default - GHC can usually make the leap between
clear and efficient. You may want to read
http://haskell.org/haskellwiki/Performance - but if you are developing
your Haskell style I'd not bother yet.

Thanks

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

Re: Unexpected lack of optimisation

[Neil Mitchell]

Hi

> > Yes, something like that is exactly what I'd like to do. I'm somewhat
> hopeful that we might manage this as part of Max Bolingbroke's SoC project,
> if it's approved.
> >
>
>  Hmmm, I thought it had been approved. Was I mistaken?

Yes, it has been approved.

http://code.google.com/soc/2008/haskell/about.html

Thanks

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

Re: Unexpected lack of optimisation

[Neil Mitchell]

Hi

> | {-# INLINE foo #-}
>  | foo = large
>  |
>  | bar x = if x then res else res
>  | where res = foo
>  |
>  | By putting an INLINE on foo I am able to persuade it to be inlined
>  | into the binding of bar, but I can't then persuade it to be inlined at
>  | the let expression.
>
>
> I'm not certain what you mean here.  I think you mean that in the above code 
> you end up with
> bar x = let res = large in if x then res else res
>  whereas what you wanted was
> bar x = if x then large else large

Yes, that is exactly it.

>  In your example, you want 'res' to inline "first".  You can get that by 
> explicit control:
>
>  {-# NOINLINE [0] foo #-}
>
>  That says "don't inline foo before phase 0", which in turn gives time for 
> 'res' to get inlined first.  I'm not certain whether that'll help in your 
> actual example.

It worked, with:

{-# INLINE [1] begin1 #-}
{-# INLINE begin2 #-}

I don't think this approach will compose particularly well, and in the
real case I was trying (not this reduced example) I don't think it
will work because there is some recursion and RULES involved. I'll
have another go with the full example in future.

I did however notice an issue while doing this work - in GHC 6.8.2 and
HEAD from Christmas.

{-# INLINE begin2
#-}
Temp.hs:7:1: lexical error at character '}'

In particular if you use the RULES example from the manual, then it
doesn't work.

Thanks

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

Re: Optimisation of unpackCString#

[Neil Mitchell]

Hi

>  > Cons: Makes the simplifier slightly more complex - but I hope not by much!
>
> And it doesn't work for my case -- I'd really want length as a compile
>  time constant.
>
>  Could you elaborate on what kind of rules you think we could write with
>  the ability to get the head?

One of my ideas was some RULES that expand:

test x | "neil" `isPrefixOf` x = ...
  | "ned" `isPrefixOf` x = ...

And obtains direct pattern-matching code. I have a lazy
continuation-based parsing library which could use this extensively.
See my other ongoing thread on this mailing list for more details of
where this is going.

>  The rule I'd like to write is:
>
> "pack/packAddress" pack (unpackCString addr) = ByteString (length# xs) 0 
> addr

That requires Proposal 2, so needs to have an API defined -- including
length# and some others. Out of curiosity, how much performance boost
would this give in ByteString?

> That sounds great!  Please let's have a chat before you sail in -- I have a 
> good idea where to put this.

Simon: I will email you in a couple of weeks to discuss it.

Thanks

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

Re: Optimisation of unpackCString#

[Neil Mitchell]

Hi

> PROPOSAL 1: Add the following rules to the simplifier:
>
>  > case unpackCString# "" of  ==> case [] of
>  > case unpackCString# "xyz" of ==> case (C# 'x': unpackCString# "yz") of

I've been wanting to have a go at hacking GHC for a while, and this
seems like a good candidate to start with. If there is no obvious
reason this is a bad idea, I'll try and provide a patch and some
benchmarks/measurements in about a month.

Thanks

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

Re: Optimisation of unpackCString#

[Neil Mitchell]

Hi

> what is general purpose stuff.  I don't think there is anything wrong with 
> magic for primitive
> types, but if there is a useful general-purpose mechanism trying to get out, 
> let's liberate it.

I think the tension comes from representing String's as CString's, not
actual lists of Char and (:). If the simple representation was used,
then things like case on a known constructor would deal with a lot of
these cases. However, for String, its probably too expensive in terms
of compile time and compile memory to keep the unpacked
representation.

> But I'd like a clear spec first.

PROPOSAL 1: Add the following rules to the simplifier:

> case unpackCString# "" of  ==> case [] of
> case unpackCString# "xyz" of ==> case (C# 'x': unpackCString# "yz") of

Pros: Doesn't introduce any new API or other long-term maintenance
issues. A necessity for certain optimisations.

Cons: Makes the simplifier slightly more complex - but I hope not by much!

PROPOSAL 2: Add some primitives and hard-coded simplifications:

(I'm giving an example with length#, but I imagine head#, tail#, null#
and some others would also be handy)

Add the following in GHC.

length# :: CString -> Int
{-# RULE "length/string" forall xs . length (unpackCString xs) = length# xs #-}

Add the rules to the simplifier:

length# "string" = 

Pros: length "haskell" becomes a compile-time constant. Very useful
for the ByteString people. Makes RULES and CString interact better,
with better optimisation possibilities.

Cons: Requires defining a small API and maintaining it. Requires more
work to the simplifier, but still should be fairly self-contained.
Cries out for a generalisation (but I don't think there is a good
one).

SUMMARY:

I think Proposal 1 is a really good idea, with a little effort and a
lot of return. I think Proposal 2 is more effort than proposal 1, with
probably less return - but may still be worth it. I think Don will
really want Proposal 2.

Thanks

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

Re: Unexpected lack of optimisation

[Neil Mitchell]

Hi Tim,

> Did you try comparing the results if you pass the -fno-state-hack flag?

No effect at all.

Thanks

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

Re: Unexpected lack of optimisation

[Neil Mitchell]

Hi

>  * As you say, if 'retry' was inlined, all would be fine.  But what if 
> 'retry' was big? Then we'd get lots of code duplication, in exchange for 
> fewer tests.
>
>  * Presumably it's not inlined because it's over the inline size threshold.  
> (You did use -O?)

I used -O2. I also added {-# INLINE #-} pragmas to both begin1 and
begin2. In this case, I know that after inlining the let expression
things will merge and become smaller afterwards (although can't see
any reasonable way the compiler could know this).

I realise that there is a limit on the size of inlining, and I can
reduce the perceived cost of inlining begin1/begin2 with pragmas.
However, once they have been inlined into a local let expression, it
doesn't seem like there is much I can do to persuade the compiler to
inline the let binding. I'm thinking of a situation something like:

{-# INLINE foo #-}
foo = large

bar x = if x then res else res
where res = foo

By putting an INLINE on foo I am able to persuade it to be inlined
into the binding of bar, but I can't then persuade it to be inlined at
the let expression.

(I tried to come up with a small example representing this situation,
but the original begin1/begin2 example is as short as I can get)

>  * The 'state' argument is just there to make sure that 'retry' is a 
> *function* not a *thunk*, to avoid the overheads of unnecessary thunk update.

OK. That seems perfectly reasonable. Does the introduction of the
state argument either remove the inline annotation, or substantially
increase the cost of inlining the let binding? Otherwise, I don't
think its relevant to my particular case.

Thanks

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

Re: Optimisation of unpackCString#

[Neil Mitchell]

Hi

> You'd have to conditionally use overloaded strings in GHC only.
>  I'm not sure it would work ( can you quantify the cost of not being able
>  to take head at compile time? )

The cost of not having this is probably ~10x slower for the tagsoup
library :-( - i.e. pretty huge. I'm looking at other ways of doing
this, perhaps using a preprocessor or something - which would be more
robust than RULES and perhaps generalise in other nice ways.

Thanks

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

Re: Optimisation of unpackCString#

[Neil Mitchell]

Hi

> Optimisation and ghci don't go together, so I don't know what your point
>  is there.

It's very worth having the application work in both Hugs and GHCi, and
its not always GHC=faster, only if you compile it - so you trade your
compile time for your run time. A delicate balance, with more than one
local optima.

>  Anyway, its the same with ByteString -- we have it work in ghci or hugs
>  or nhc, but its only worth actually optimising for GHC.

Can you use overloaded Strings with Hugs? I am not aware of how to. I
am happy to use RULES's and pragmas etc, but I can't see a way of
doing overloaded strings this way, as by the time I've got to RULES
I've gained the unpackCString, which just won't go away!

Thanks

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

Unexpected lack of optimisation

[Neil Mitchell]

Hi

Using GHC 6.9.20071226:

The following code:

---

test s | begin2 'n' 'a' s = "test"
   | begin2 'n' 'b' s = "test2"


begin2 :: Char -> Char -> String -> Bool
begin2 x1 x2 (y:ys) | x1 == y = begin1 x2 ys
begin2 _ _ _ = False

begin1 :: Char -> String -> Bool
begin1 x1 (y:ys) | x1 == y = True

---

You might expect the head of the list s to be tested for equality with
'n' only once. Something like:

test s = case s of
s1:ss -> case s1 of
  'n' ->  choose 'a' or 'b' 
  _ -> fail

Unfortunately, GHC can't common up these two tests. It inserts a
State# RealWorld in the middle, giving a result of:

test s = case s of
   s1:ss -> case s1 of
   'n' -> case ss of
 s2:ss -> case s2 of
 'a' -> 
 _ ->
retry state
   _ -> retry state

retry dummy = case s of
s1:ss -> case s1 of
   'n' -> 

If GHC was to inline the "retry" (which is a local let-bound lambda)
it should have no problem merging these two cases. I'm not entirely
sure why the State# gets inserted, but was wondering if it is
necessary?

The complete -ddump-simpl is at the end of this message.

Thanks

Neil

--

Text.HTML.TagSoup.Development.Sample.test :: GHC.Base.String -> [GHC.Base.Char]
[GlobalId]
[Arity 1]
Text.HTML.TagSoup.Development.Sample.test =
  \ (s_a6g :: GHC.Base.String) ->
let {
  $j_s7l :: GHC.Prim.State# GHC.Prim.RealWorld -> [GHC.Base.Char]
  [Arity 1]
  $j_s7l =
\ (w_s7m :: GHC.Prim.State# GHC.Prim.RealWorld) ->
  let {
$j1_s7d :: GHC.Prim.State# GHC.Prim.RealWorld -> [GHC.Base.Char]
[Arity 1]
$j1_s7d =
  \ (w1_s7e :: GHC.Prim.State# GHC.Prim.RealWorld) ->
GHC.Err.patError
  @ [GHC.Base.Char]

"Text/HTML/TagSoup/Development/Sample.hs:(48,0)-(49,34)|function test"
} in
  case s_a6g of wild_Xl {
[] -> $j1_s7d GHC.Prim.realWorld#;
: y_a6o ys_a6q ->
  case GHC.Base.$f4 of tpl_Xr { GHC.Base.:DEq tpl1_B2 tpl2_B3 ->
  case tpl1_B2 (GHC.Base.C# 'n') y_a6o of wild1_Xp {
GHC.Base.False -> $j1_s7d GHC.Prim.realWorld#;
GHC.Base.True ->
  let {
fail_d6S :: GHC.Base.Bool
[]
fail_d6S =
  GHC.Err.patError
@ GHC.Base.Bool

"Text/HTML/TagSoup/Development/Sample.hs:57:0-32|function begin1" } in
  case ys_a6q of wild2_XB {
[] ->
  case fail_d6S of wild3_Xj {
GHC.Base.False -> $j1_s7d GHC.Prim.realWorld#;
GHC.Base.True -> GHC.Base.unpackCString# "test2"
  };
: y1_a6y ys1_a6A ->
  case GHC.Base.$f4 of tpl3_XH { GHC.Base.:DEq
tpl4_XL tpl5_XN ->
  case tpl4_XL (GHC.Base.C# 'b') y1_a6y of wild3_Xo {
GHC.Base.False ->
  case fail_d6S of wild4_Xj {
GHC.Base.False -> $j1_s7d GHC.Prim.realWorld#;
GHC.Base.True -> GHC.Base.unpackCString# "test2"
  };
GHC.Base.True -> GHC.Base.unpackCString# "test2"
  }
  }
  }
  }
  }
  } } in
case s_a6g of wild_B1 {
  [] -> $j_s7l GHC.Prim.realWorld#;
  : y_a6o ys_a6q ->
case GHC.Base.$f4 of tpl_Xp { GHC.Base.:DEq tpl1_B2 tpl2_B3 ->
case tpl1_B2 (GHC.Base.C# 'n') y_a6o of wild1_XT {
  GHC.Base.False -> $j_s7l GHC.Prim.realWorld#;
  GHC.Base.True ->
let {
  fail_d6S :: GHC.Base.Bool
  []
  fail_d6S =
GHC.Err.patError
  @ GHC.Base.Bool

"Text/HTML/TagSoup/Development/Sample.hs:57:0-32|function begin1" } in
case ys_a6q of wild2_Xz {
  [] ->
case fail_d6S of wild3_XD {
  GHC.Base.False -> $j_s7l GHC.Prim.realWorld#;
  GHC.Base.True -> GHC.Base.unpackCString# "test"
};
  : y1_a6y ys1_a6A ->
case GHC.Base.$f4 of tpl3_XF { GHC.Base.:DEq tpl4_XJ tpl5_XL ->
case tpl4_XJ (GHC.Base.C# 'a') y1_a6y of wild3_Xo {
  GHC.Base.False ->
case fail_d6S of wild4_XN {
  GHC.Base.False -> $j_s7l GHC.Prim.realWorld#;
  GHC.

Re: Optimisation of unpackCString#

[Neil Mitchell]

Hi

>  > That would work on GHC, but not on Hugs.
>
> Optimisation and Hugs don't go together anyway.

I want the code to work on Hugs, and perform fast on GHC. As it turns
out, for this particular application, Hugs is faster than GHCi by
about 25%.

Thanks

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

Re: Optimisation of unpackCString#

[Neil Mitchell]

Hi

> This goes back to an old gripe of mine actually -- we can't get
>  at the length of a C string literal at compile time either, which
>  would be super useful in rules.

I was about to complain about this next, as soon as I got the previous
part working :-)

>  If we had some light primitives for this, that GHC new about (head#,
>  length#), that accessed the internal data about what strings are up to,
>  that could be useful.

If we had the two simplification rules I suggested, and RULES, I think
you can write length# yourself. Of course, its not necessarily going
to be pleasant, and may require N rules iterations, where N is the
length of the string.

Thanks

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

Re: Optimisation of unpackCString#

[Neil Mitchell]

Hi

> The first case makes sense, and is just a RULE. Though it seems GHC already
>  does this?
>
> g = head ""
>
>  goes to:
>
> M.g = badHead @ Char
>
>  without prompting.

Nope, as far as I can tell "" gets translated to [], not
unpackCString# "" - hence the unpack never gets in the way. If you had
the second rule, you'd soon want the first.


>  So I wondered if I could write a rule for head/unpackCString
>
>  Urgh. not what we want though. GHC won't index the string at compile time,
>  and I can't write a RULE for it.

Yeah, I tried that too...

>  Perhaps you can newtype Char and use string overloading to work around the
>  packing issue?

That would work on GHC, but not on Hugs.

Thanks

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

Optimisation of unpackCString#

[Neil Mitchell]

Hi

(All these results are from GHC 6.9.20071226, but suspect they hold
for 6.9.* and 6.8)

The following code:

test = head "neil"

Produces (with -O2):

Text.HTML.TagSoup.Development.Sample.test =
  case GHC.Base.unpackCString# "neil" of wild_aaU {
[] -> GHC.List.badHead @ GHC.Base.Char; : x_aaY ds1_aaZ -> x_aaY
  }

However:

test = head ['n','e','i','l']

Produces:

Text.HTML.TagSoup.Development.Sample.test = GHC.Base.C# 'n'

The packing of the string has damaged the optimisation. Is there
anyway to mitigate this? I ideally want to do this in RULES to derive
an efficient parser from a set of parser combinators, and the
unpackCString# really gets in the way of future optimisations.

I could imagine adding two rules to the simplifier:

case unpackCString# "" of  ==> case [] of
case unpackCString# "xyz" of ==> case (C# 'x': unpackCString# "yz") of

Then the simplifier could recover the optimised version.

Thanks

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

Unexpected lack of optimisation in -O0

[Neil Mitchell]

Hi,

I just tried compiling the following program:

foo = (1 :: Int) == (2 :: Int)

with ghc --ddump-simpl, and no optimisation flags, in GHC 6.6.1

The resultant code is:

Test.foo =
  case GHC.Base.$f2 of tpl_X8 { GHC.Base.:DEq tpl1_B2 tpl2_B3 ->
  tpl1_B2 (GHC.Base.I# 1) (GHC.Base.I# 2)
  }

GHC has introduced dictionaries in this example. In comparison, Yhc
and nhc wouldn't introduce dictionaries here, as the type class
desugaring knows the type of the item is fixed, and makes a direct
call to the appropriate function.

If the desugaring was changed, it would make programs in GHCi run
faster, would reduce the size of programs, and would speed up the
optimiser, as it would have less to do. I am not sure how much
additional work this would require in the simplifier, but if it was
minimal, the gains would probably be worth it.

I was just reading the Monad.Reader, where a Yhc based Haskell
Interpreter states that comparisons against GHCi are "unfair", because
Yhc gains too  much benefit from this desguaring.

Thanks

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

Re: swap (x, y)

[Neil Mitchell]

Hi Serge,

> I define and use   swap (x, y) = (y, x)
>
>  because do not find such in the standard library.

You can search for it in the standard libraries using Hoogle:

http://haskell.org/hoogle/?q=(a,b)->(b,a)

>  Please, can people point at it, in the standard library, or at least
>  in GHC?

And as it turns out, it isn't anywhere in the standard libraries. I
think this would be a useful function to add to Data.Tuple, so feel
free to propose it for addition.

Thanks

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

Re: Release plans

[Neil Mitchell]

Hi

>  You could still have a cabal-install binary in the Windows installer and
>  not include the Cabal-1.4.x library that you built it against.

That sounds easiest, and should give all the cabal-install benefits to
Windows users.

>  Alternatively it'd be possible to include Cabal-1.4.x too and have it
>  not exposed by default. That'd enable cabal-install to use it for any
>  packages that use a custom Setup.hs without it being picked up by
>  default by ghc --make or ghci.

Unless the API 100% stable, I'd be wary of supporting a not quite
finished release on Cabal in something as major as GHC. Upgrading
Cabal is fairly easy, if people want to do it themselves.

If Cabal supported darcs links, you could even imagine upgrading cabal
with "cabal install cabal --from-darcs" - that would be wonderful!

Thanks

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

Re: Release plans

[Neil Mitchell]

Hi

>  First, we intend to release the next version of GHC from the current
>  stable branch, 6.8.3, around the end of May 2008. This will probably be
>  the last release from this branch.

Is it possible to include the cabal-install tool with this release, in
the Windows installer?

The cabal-install tool provides very useful functionality, and is
currently rather tricky to install. If cabal-install was already
installed, then installing cabal-install would be trivial (note how
cabal-install causes a mental black hole).

Thanks

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

Re: ghc-6.8.1 on WinXP: windres: can't open font file `for'

[Neil Mitchell]

Alistair,

>  Bummer. I was hoping to be able to use 6.8.1 with gtk2hs (AFAIUI, gtk2hs
>  doesn't work with/hasn't been compiled against 6.8.2 yet). Is there a
>  workaround or something I can tweak in my 6.8.1 installation?

It's much easier to gently prod Duncan until he gives in and releases
a new gtk2hs version.

Thanks

Neil

/me commences the prodding
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: gmp

[Neil Mitchell]

Hi

> What is the situation on Windows? Does the standard
> GHC binary on Windows have dynamically linked gmp
> for binaries produced by ghc?

No, they are statically linked. (Please, can no one start discussing
licensing, people already know there are issues with it, and I get
plenty of traffic already!)

Thanks

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