gmane.comp.lang.haskell.glasgow.user

Re: ANNOUNCE: GHC 7.4.2 Release Candidate 1

Jens Petersen — 2012-05-18T09:22:48

The ARM also finished successfully:
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=838546
(with the same ARM patches as for 7.4.1).


I also tested building haskell-platform-2012.4 RC1 with ghc-7.4.2 RC1 on x86_64.

Jens

Re: ANNOUNCE: GHC 7.4.2 Release Candidate 1

Jens Petersen — 2012-05-18T01:34:46

Thanks!

I did a test scratch build on Fedora 18, which should also work on
Fedora 17 which will be released soon.

http://koji.fedoraproject.org/koji/taskinfo?taskID=4084830

If you want to try the build on Fedora the source and binary rpms can
be downloaded from:
http://kojipkgs.fedoraproject.org/scratch/petersen/task_4084830/

I also just started a test build on Fedora ARM but that will take a
little longer to finish.

Jens

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

Re: Potential GSoC proposal: Reduce the speed gap between 'ghc -c'and 'ghc --make'

Ryan Newton — 2012-05-17T14:51:12

Mikhail's original question was about loading interface files for entire
packages with mmap.

As a wild thought experiment, if GHC had a saved-heaps capability, I
believe that would avoid the Unique issues with mmap'ing individual data
structures that Simon mentioned.  How about if each whole-package interface
were then a GHC saved heap that, when booted, would become an "interface"
server that would communicate with, and be shared by, other GHC build
server processes.

  -Ryan


On Fri, Apr 27, 2012 at 4:57 AM, Simon Marlow <marlowsd< at >gmail.com> wrote:

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

Re: How to force recompilation of preprocessed files (-F -pgmF ..)

Simon Hengel — 2012-05-17T11:41:27

Hi Etienne,
thanks for your reply.


That's interesting.  But from what I've tried, it seems that it does not
work with GHCi.


I think it's amazing, that this works with ghc --make.  But it does not
work with GHCi, I created a ticket for that [1].

Cheers,
Simon

[1] http://hackage.haskell.org/trac/ghc/ticket/6105

Re: How to force recompilation of preprocessed files (-F -pgmF ..)

Etienne Laurin — 2012-05-17T09:26:02

Hello Simon,

You can use Template Haskell's addDependentFile to register a
dependency on external files.

http://hackage.haskell.org/packages/archive/template-haskell/2.7.0.0/doc/html/Language-Haskell-TH-Syntax.html#v:addDependentFile

You can also put -fforce-recomp in an OPTIONS_GHC pragma to ask GHC to
always recompile the file.

{-# OPTIONS_GHC -fforce-recomp #-}

Etienne Laurin

2012/5/17 Simon Hengel <sol< at >typeful.net>:

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

How to force recompilation of preprocessed files (-F -pgmF ..)

Simon Hengel — 2012-05-17T08:58:02

Hi,
I'm experimenting with a preprocessor to automatically generate test
drivers[1].  The result depends on the existence of other files on the
disk.  When files are added or removed, the test driver has to be
regenerated.

Ideally ghc would just always recompile that single file (akin to make's
.PHONY), and it should work with ghci's :reload and with cabal.

I tried to touch the file within the preprocessor, but this does not
work.  It seems, that GHC checks the modification time only after
preprocessing.

Any ideas how to tackle this?

Cheers,
Simon

[1] https://github.com/sol/hspec-discover

Heads up: importing the Cabal issue tracker to github next week

Bryan O'Sullivan — 2012-05-17T03:45:03

I am planning on doing this early next week, probably in two phases.

As part of the import process, github will generate a *lot* of notification
emails. I'm afraid there is nothing I can do to stem the tide, as github
does not provide a mechanism to suppress these. If you have a github
account, please brace yourself.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users< at >haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ANNOUNCE: GHC 7.4.2 Release Candidate 1

Ian Lynagh — 2012-05-16T10:05:00

We are pleased to announce the first release candidate for GHC 7.4.2:

    http://www.haskell.org/ghc/dist/7.4.2-rc1/

This includes the source tarball, installers for OS X and Windows, and
bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD.

Please test as much as possible; bugs are much cheaper if we find them
before the release!


Thanks
Ian, on behalf of the GHC team

[ANN] Accelerate version 0.12: GPU computing with Haskell

Manuel M T Chakravarty — 2012-05-14T07:50:40

We just released version 0.12 of Data.Array.Accelerate, the GPGPU[1] library for Haskell:

  http://justtesting.org/gpu-accelerated-array-computations-in-haskell

This is a beta release. The library is not perfect, but it is definitely usable, and we are looking for early adopters.

Manuel

[1] Currently only NVIDIA GPUs are supported via NVIDIA's CUDA framework.

Re[2]: Win64 support

Bulat Ziganshin — 2012-05-09T15:24:34

Hello Ian,

Wednesday, May 9, 2012, 7:12:03 PM, you wrote:


wow! what is the current state, when it planned to be released, how
it's implemented (gcc/mingw64?) ? may be this port has its own webpage
or some progress list? i would be glad to alpha-test it

http://hackage.haskell.org/trac/ghc/ticket/1884 says nothing on it
- i'm pretty sure that you will find a lot of testers here too

Re: Win64 support

Ian Lynagh — 2012-05-09T15:12:03

Hi Bulat,

On Wed, May 09, 2012 at 06:54:48PM +0400, Bulat Ziganshin wrote:

The Industrial Haskell Group has been funding work on the Win64 port. It
will be released with GHC 7.6.


Thanks
Ian

Win64 support

Bulat Ziganshin — 2012-05-09T14:54:48

Hello glasgow-haskell-users,

the one thing that users of my program asked most is the Win64
support: http://code.google.com/p/freearc/issues/list . we have waited
for a several years, but it's still not in GHC, so i want to know at
least: why it's not going forward? can we have unregisterized build at
least?

Re: Explicit calls to the garbage collector.

Simon Marlow — 2012-05-08T10:27:25

It is more likely that you are trading extra memory for better 
performance, rather than triggering the GC at a good time.  GC is 
basically a space/time tradeoff, see:

http://stackoverflow.com/questions/3171922/ghcs-rts-options-for-garbage-collection/3172704#3172704

If you think the program has points where residency is very low and it 
would be good to trigger a GC, I would first confirm the hypothesis by 
doing a heap profile.  GC can be triggered with System.Mem.performGC.

Cheers,
Simon

Re: Explicit calls to the garbage collector.

Johan Tibell — 2012-05-07T17:28:23

On Mon, May 7, 2012 at 7:00 AM, Christopher Done
<chrisdone< at >googlemail.com> wrote:

In non-GCed language people often use an arena allocator in situations
like this. However, a semi-space collector (which is what we use) we
get that behavior for free. If your request is processed in less time
than the minor GC cycle, all your data will be dead by the time the GC
run and thus collecting it is free.

Re: Explicit calls to the garbage collector.

Johan Tibell — 2012-05-07T17:26:47

Hi,

On Mon, May 7, 2012 at 6:33 AM, Jurriaan Hage <J.Hage< at >uu.nl> wrote:

You have to be very careful when benchmarking programs in garbage
collected languages. If you set the nursery size high enough the GC
might never run during your benchmark, but in a real program a big
nursery might perform worse than a smaller one. For any small GC bound
benchmark you can typically get it to run much faster by setting -A to
some ridiculous high number.

Re: Explicit calls to the garbage collector.

Joachim Breitner — 2012-05-07T14:10:13

Hi,

Am Montag, den 07.05.2012, 15:33 +0200 schrieb Jurriaan Hage:

there is performGC:
http://hackage.haskell.org/packages/archive/base/latest/doc/html/System-Mem.html#v:performGC

Greetings,
Joachim

Re: Explicit calls to the garbage collector.

Christopher Done — 2012-05-07T14:00:17

I would also be interested to know this. A web server is an example of
a Haskell program that could force garbage collection at the end of
every request reply, especially a multi-threaded server where the
memory use is localized to threads. For long-running applications, a
GC at this point would be nice.

Explicit calls to the garbage collector.

Jurriaan Hage — 2012-05-07T13:33:52

LS.

I have a very memory intensive application. It seems that the timing of my application 
depend very much on the precise setting of -H...M in the runtime system (-H2000M 
seems to work best, computation time becomes a third of what I get when I pass no
-H option).  I conjecture that this good behaviour is the result of gc happening at the right time.
So I wondered: if I can one when is the right time, is it possible then to trigger
GC explicitly from within the Haskell code? 

best,
Jur

Re: Weird behavior of the NonTermination exception

Bas van Dijk — 2012-05-04T14:18:21

Thanks Simon, I learned something new today.

Cheers,

Bas

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

Re: Weird behavior of the NonTermination exception

Simon Marlow — 2012-05-04T12:12:15

The forked thread is deadlocked, so the MVar is considered unreachable 
and the main thread is also unreachable.  Hence both threads get sent 
the exception.

The RTS does this analysis using the GC, tracing the reachable objects 
starting from the roots.  It then send an exception to any threads which 
were not reachable, which in this case is both the main thread and the 
child, since neither is reachable.

We (the user) knows that waking up the child thread will unblock the 
main thread, but the RTS doesn't know this, and it's not clear how it 
could find out easily (i.e. without multiple scans of the heap).

Cheers,
Simon

Re: trouble building ghc-7.4 on Fedora 18 (devel) ARM

Jens Petersen — 2012-05-04T09:23:03

A late followup, just to let you know, everything is good now.


It is... I hope llvm will make it the default for armv7 hardware fp.

So finally ghc-7.4.1 is built for Fedora ARM and working:
I also had to forward-port my pkgconfig libffi workaround for
non-native compiler archs to help the C compiler find libffi.h when
building prof libraries.

http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=66294

Thanks for everyone's help and particular big kudos and karma
to those who did the heavy-lifting on the ARM port for 7.4.
Maybe someone has some proper benchmarks
but roughly going by the ghc-7.4.1 build it seems over
twice as fast as 7.0.4. :-))

Jens