Re: Advice wanted on parallel processing

[Colin Paul Adams]

  == j waldmann waldm...@imn.htwk-leipzig.de writes:

 (I am not updating in place).  The move generator produces a
 new board for each move.

 Well, this is sound design, but current memory managers may not
 be up to it.  If you check the (board) game programming
 literature, you'll find that engine authors take great efforts
 to bypass automatic memory management (do all updates on the
 current board in-place, and write their own malloc/free for
 game tree nodes).

I know it.
In fact I wrote a program for this game about 10 years ago, in C++,
which did all updates in place.
It wasn't very good (although being the only one that implemented the
rules correctly - as far as I could tell - they are very complicated 
- was necessarily the best).
Now I want to have another go in Haskell. Reading about DPH inspired
me to give it a try, although I'm not attempting to use DPH
yet. Probably I was too naive thinking I was going to be able to
exploit parallelism without pain.

 This becomes even more important when trying to exploit
 concurrency.  In theory, that's all very nice (you can evaluate
 independent branches of the game tree in parallel) but in
 practice, you're doomed if your memory allocator/collector is
 still essentially single-threaded (that is, blocks all
 threads).

OK, that's interesting. GHC's collector is still stop-the-world at the
moment, right? I read in the recent paper that it is intended to try
to remedy that soon, in which case I can try again to see if that
improves matters.
-- 
Colin Adams
Preston Lancashire
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Loop unrolling + fusion ?

[Max Bolingbroke]

2009/3/19 Claus Reinke claus.rei...@talk21.com:
 If the map, filter, fold, etc can be unrolled, then the unrolled
 definitions would be fused, right? So what is missing is fine
 control (how much to unroll this particular call to map here).

The issues is that In stream fusion the combinators like map are all
non-recursive and so unrolling/peeling doesn't make any sense. In
fact, their being non-recursive is almost the whole point, because it
lets GHC inline them like crazy and hence build a nice efficient fused
pipeline of combinators eventually. The recursion is introduced purely
in one place - unstream - and even then it doesn't go through unstream
but through a locally recursive wrapper (so GHC can see the structure
of the stream).

So, it might be sufficient if:
1) You changed stream fusion so unstream was directly recursive, but
added an INLINE PEEL 1 annotation to it, so if the call site doesn't
do any unrollling at least you will still be able to spot the
structure of the stream
2) You could, at the call site, add an INLINE PEEL 1 UNROLL n
annotation that took the /original/ RHS for unstream and unrolled it
however many times the user specifies (you still need a PEEL 1 so you
can spot the stream structure in the unrolled loop)

Unfortunately, this all feels quite fragile :-(

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

RE: ANNOUNCE: GHC 6.10.2 Release Candidate 1

[Simon Marlow]

 I've tried the 6.10.2 RC with some performance-sensitive work code.
 The code uses the non-threaded runtime, and makes extensive use of
 signals. The results look very good.

 The slightly funny (but useful to us) benchmark measures bandwidth
 communicating between multiple unix processes. Here's a graph of how
 much better 6.10.2 is doing:

 http://galois.com/~dons/images/bandwidth.png

 Note we're over a 1G/s bandwidth now with 6.10.2 for the first time :)
 Thanks guys!

 (Note also we use a slightly modified runtime that has thread deadlock
 detection disabled).

 There have been quite a few runtime patches, enough that 6.10.2 is
 really quite a different runtime now:

 http://galois.com/~dons/rts.patches
 http://galois.com/~dons/6101-6102.diff

 Anyway, all those signal and thread handling changes are looking good.

Looking back through what has gone into 6.10.2, I think the credit probably 
goes to the patch below.  It's nice to hear this improves performance too - 
that was an unexpected benefit.

If you're able to test with the HEAD, I'd be very interested to see your 
results there too.

Cheers,
Simon

Fri Feb 20 14:32:00 GMT 2009  Ian Lynagh ig...@earth.li
  * MERGED: Rewrite of signal-handling (ghc patch; see also base and unix 
patches)
  Simon Marlow marlo...@gmail.com**20090219103142
   Ignore-this: aca7c3e258224fadc6f0f2fee86b2971

   The API is the same (for now).  The new implementation has the
   capability to define signal handlers that have access to the siginfo
   of the signal (#592), but this functionality is not exposed in this
   patch.

   #2451 is the ticket for the new API.

   The main purpose of bringing this in now is to fix race conditions in
   the old signal handling code (#2858).  Later we can enable the new
   API in the HEAD.

   Implementation differences:

- More of the signal-handling is moved into Haskell.  We store the
  table of signal handlers in an MVar, rather than having a table of
  StablePtrs in the RTS.

- In the threaded RTS, the siginfo of the signal is passed down the
  pipe to the IO manager thread, which manages the business of
  starting up new signal handler threads.  In the non-threaded RTS,
  the siginfo of caught signals is stored in the RTS, and the
  scheduler starts new signal handler threads.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Loop unrolling + fusion ?

[Max Bolingbroke]

2009/3/19 Claus Reinke claus.rei...@talk21.com:
 Recursion unfolding spec, 2nd attempt.

 

 If this is an improvement on the first version, and after correcting any
 obvious issues, I should put it on the ghc trac wiki somewhere, and create a
 feature request ticket.

I can't see any issues with this version of the spec.

I think in the implementation it makes most sense to do this as a
core2core pass at an early stage in the pipeline, probably via plugins
(so will have to wait until I get those into HEAD). In the case of
PEEL, we don't want to identify all call sites directly and do the
substitution in the pass so we should just output some bindings which
will certainly be inlined into call sites later on. So, the
transformation should be bottom up on the Core syntax tree and when it
meets a recursive group of bindings we should do something like this:

{-# INLINE f g PEEL 3 UNROLL 2 #-}
f = ... g ... f ... h ...
g = ... g ... f ... h ...
h = ... g ... f ... h ...

=(my pass)=

-- Temporary copies of f and g - dead code
f_old = ... g_old ... f_old ... h ...
g_old = ... g_old ... f_old ... h ...
-- H unchanged for now, might get PEELed stuff inlined later
h = ... g .. f ... h ...

-- Top level unrolled definiiton - if we weren't doing peeling, these
would be the new f and g
f_unrolled = ... g_unrolled_1 ... f_unrolled_1 ... h ...
g_unrolled = ... g_unrolled_1 ... f_unrolled_1 ... h ...

-- Unrolled iteration. Will get inlined into f_unrolled / g_unrolled soon
{-# INLINE f_unrolled_1 g_unrolled_1 #-}
f_unrolled_1 = ... g_unrolled ... f_unrolled ... h ...
g_unrolled_1 = ... g_unrolled ... f_unrolled ... h ...

-- One level of peeling
{-# INLINE f_1 g_1 #-}
f_1 = ... g_unrolled ... f_unrolled ... h ...
g_1 = ... g_unrolled ... f_unrolled ... h ...

-- Second level of peeling
{-# INLINE f_2 g_2 #-}
f_2 = ... g_1 ... f_1 ... h ...
g_2 = ... g_1 ... f_1 ... h ...

-- Final level of peeling and new definitions for f and g. Inline pragmas
-- make sure all of this gets inlined at the call site
{-# INLINE f g #-}
f = ... g_2 ... f_2 ... h ...
g = ... g_2 ... f_2 ... h ...

=(after the simplifier has run - effectively - there are a few
harmless lies here)=

-- NB: I haven't shown inlining of the new f and g here, but it /will/ happen
h = ... g .. f ... h ...

-- I've inlined the inner unrolled iteration at every /call site/
within the top level unrolled iteration, as per
-- the pragmas. Noone actualy calls this unrolled thing directly
though, since we used PEEL as well
f_unrolled = ... (... g_unrolled ... f_unrolled ... h ...) ... (...
g_unrolled ... f_unrolled ... h ...) ... h ...
g_unrolled = ... (... g_unrolled ... f_unrolled ... h ...) ... (...
g_unrolled ... f_unrolled ... h ...) ... h ...

-- This huge chunk of code gets inlined at every call site, which in
turn call through to the unrolled bodies
{-# INLINE f g #-}
f = ... (... (... g_unrolled ... f_unrolled ... h ...) ... (...
g_unrolled ... f_unrolled ... h ...) ... h ...) ... (... (...
g_unrolled ... f_unrolled ... h ...) ... (... g_unrolled ...
f_unrolled ... h ...) ... h ...) ... h ...
g = ... (... (... g_unrolled ... f_unrolled ... h ...) ... (...
g_unrolled ... f_unrolled ... h ...) ... h ...) ... (... (...
g_unrolled ... f_unrolled ... h ...) ... (... g_unrolled ...
f_unrolled ... h ...) ... h ...) ... h ...


By ensuring that f and g are tagged INLINE we get the existing INLINE
restrictions automatically in later Core passes.

I think that this example transformation matches your spec - am I right?

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

Re: Loop unrolling + fusion ?

[Claus Reinke]

Dear Simon*,

thanks for answering my concerns about -fvia-C replacement. Are these 
answers somewhere in the ghc wiki, or perhaps they'd make a good basis

for a useful ghc blog post?

So, -fasm will soon be up to speed with -fvia-C in all cases, new native
backends are not more difficult than more mangler branches, and tools
for generating wrappers for CPP-based APIs should be provided.

Just one additional point re:
We haven't had a single new registerised port of GHC in many years now. 


Interest in new platforms is increasing again, though. People have been
talking about PS3, internet tablets, multicore machines, .. Personally,
I'd like to be able to use GHC on, or at least for, coming smartphone 
generations, etc. (I don't see myself looking at native backends there,

but probably I wouldn't have braved the mangler, either; still, someone
else might prefer one over the other). And I don't understand how 
people can be happy with unregisterised GHC ports for long, given

how many optimizations GHC is not doing even in best form!-)

Thanks again,
Claus

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

Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1

[Simon Marlow]

jutaro wrote:

I've installed a GUI application based on gtk2hs.

It frequently crashes with the error: 
leksah: error: a C finalizer called back into Haskell.

use Foreign.Concurrent.newForeignPtr for Haskell finalizers.

This error did never occur with the 6.10 released version. It was verified
that this happens on different machines. I've no idea how to isolate this
bug.


This will need to be fixed in gtk2hs.  Previously GHC allowed finalizers to 
call back into Haskell, but this was never officially supported.  Now it is 
officially unsupported, because finalizers created via Foreign.mkForeignPtr 
are run directly by the garbage collector.


See

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

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

Re: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1

[Simon Marlow]

Thorkil Naur wrote:

Hello Thomas,

On Wednesday 18 March 2009 15:03, Thomas Schilling wrote:
There should be a file called testlog somewhere, either at the  
toplevel or within the tests directory.  Could you search for  
apirecomp001 and send me the test output from running that test.  I  
can't reproduce this failure when running it manually even though I'm  
on OS X, too.


Several of the buildbot slaves fail the apirecomp001(normal) test as well. For 
eaxmple, here is the output from 


http://darcs.haskell.org/buildbot/all/builders/tnaur%20x86%20Linux%20head/builds/333/steps/runtestsuite/logs/unexpected

for that test:

= apirecomp001(normal)
cd ./ghc-api/apirecomp001  $MAKE -s --no-print-directory apirecomp001
/dev/null apirecomp001.run.stdout 2apirecomp001.run.stderr

Wrong exit code (expected 0 , actual 2 )
Stdout:

Stderr:
make[1]: myghc: Command not found
make[1]: *** [apirecomp001] Error 127


I suspect Thomas has . in his PATH.  Naughty :-)

This fixes it:

-   @myghc $(TOP)/..
+   @./myghc $(TOP)/..

I'll validate and push.

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

Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1

[Karel Gardas]

Hi Ian,

Ian Lynagh wrote:

 The buildbot is putting SplitObjs=NO in mk/build.mk. The above log has
 object splitting enabled, which means that there are a lot more .o
 files, which is presumably causing some problem with your ar.
 
 If you have both a GNU ar and a Solaris ar then it might be worth seeing
 if the other one works. Otherwise, putting SplitObjs=NO in mk/build.mk
 will work, but at the expense of larger binaries.

I put just GNU ar into my PATH, so GHC build is using Sun ld and GNU ar
and the build runs for much longer and breaks on:

Building hsc2hs-0.67...
[1 of 2] Compiling Paths_hsc2hs (
dist-install/build/autogen/Paths_hsc2hs.hs,
dist-install/build/hsc2hs/hsc2hs-tmp/Paths_hsc2hs.o )
[2 of 2] Compiling Main ( Main.hs,
dist-install/build/hsc2hs/hsc2hs-tmp/Main.o )
Linking dist-install/build/hsc2hs/hsc2hs ...
gmake[3]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/utils/hsc2hs'
gmake -C haddock install-inplace
gmake[3]: Entering directory `/var/tmp/ghc-6.10.1.20090314/utils/haddock'
/var/tmp/ghc-6.10.1.20090314/utils/installPackage/install-inplace/bin/installPackage
install
'/var/tmp/ghc-6.10.1.20090314/utils/ghc-pkg/install-inplace/bin/ghc-pkg'
'/var/tmp/ghc-6.10.1.20090314/inplace-datadir/package.conf' ''  \
'/var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace' \
'/var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace' \
'$prefix/bin' \
'$prefix/lib' \
'$prefix/libexec' \
'$prefix/dynlib'  \
'$prefix/share' \
'$prefix/doc' \
'$prefix/html'\
'$prefix/haddock' \
--distpref dist-install\
--enable-shell-wrappers
Installing library in
/var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace/lib/haddock-2.4.2
Installing executable(s) in
/var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace/bin
internal error: error_message(28)
gmake[3]: *** [install-inplace] Error 100
gmake[3]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/utils/haddock'
gmake[2]: *** [with-stage-2] Error 2
gmake[2]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/utils'
gmake[1]: *** [stage2] Error 2
gmake[1]: Leaving directory `/var/tmp/ghc-6.10.1.20090314'
gmake: *** [bootstrap2] Error 2


The message `internal error: error_message(28)' looks suspiciously, is
there any Sun ar invoked behind the scene? Or isn't this message from
the AR but coming from something else?

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

Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1

[Ian Lynagh]

On Thu, Mar 19, 2009 at 11:31:33AM +0100, Karel Gardas wrote:
 
 /var/tmp/ghc-6.10.1.20090314/utils/installPackage/install-inplace/bin/installPackage
 install
 '/var/tmp/ghc-6.10.1.20090314/utils/ghc-pkg/install-inplace/bin/ghc-pkg'
 '/var/tmp/ghc-6.10.1.20090314/inplace-datadir/package.conf' ''  \
 '/var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace' \
 '/var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace' \
 '$prefix/bin' \
 '$prefix/lib' \
 '$prefix/libexec' \
 '$prefix/dynlib'  \
 '$prefix/share' \
 '$prefix/doc' \
 '$prefix/html'\
 '$prefix/haddock' \
 --distpref dist-install\
 --enable-shell-wrappers
 
 The message `internal error: error_message(28)' looks suspiciously, is
 there any Sun ar invoked behind the scene? Or isn't this message from
 the AR but coming from something else?

Try running the above command but with -v2 or -v3 appended, and it
should show you what is being run. Looks like strip is probably the
culprit.


Thanks
Ian

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

Adding DPH to HEAD

[Colin Paul Adams]

I tried following the advice on the DPH wiki:

./sync-all --dph get

This wouldn't run because of permissions, so I tried putting sh in
front of the command. This produced a lot of error messages:

./sync-all: line 3: use: command not found
./sync-all: line 4: use: command not found
./sync-all: line 8: git: command not found
./sync-all: line 8: my: command not found
./sync-all: line 8: chomp: command not found
./sync-all: line 9: git: command not found
./sync-all: line 9: my: command not found
./sync-all: line 9: chomp: command not found
./sync-all: line 10: git: command not found
./sync-all: line 10: my: command not found
./sync-all: line 10: chomp: command not found
./sync-all: line 12: my: command not found
./sync-all: line 13: my: command not found
./sync-all: line 15: syntax error near unexpected token `{'
./sync-all: line 15: `if ($defaultrepo =~ /^...*:/) {'

Following a suggestion from Simon Marlow, I instead tried:

./darcs-all --dph get

which was more successful. Does the wiki page need updating?

But when I then typed

make

I got:

snip
   --constraint=Cabal == 1.7.0
Configuring installPackage-1.0...
cabal-bin: The following installed packages are broken because other packages
they depend on are missing. These broken packages must be rebuilt before they
can be used.
package Cabal-1.7.0 is broken due to missing package array-0.2.0.0,
containers-0.2.0.0, process-1.0.1.0
make[2]: *** [with-bootstrapping-compiler] Error 1
make[2]: Leaving directory `/home/colin/ghc/utils/installPackage'
make[1]: *** [with-bootstrapping-compiler.installPackage] Error 2
make[1]: Leaving directory `/home/colin/ghc/utils'
make: *** [stage1] Error 2

What do I do in such circumstances? I tried a

cabal install Cabal --rebuild

which seemed to work OK, but when i type 

make

again i get the same error as before.
-- 
Colin Adams
Preston Lancashire
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1

[Ian Lynagh]

On Wed, Mar 18, 2009 at 12:35:01PM +0100, Thorkil Naur wrote:
 
 I have tried the Intel Mac installer and the source package on both FreeBSD 
 and PPC Mac OS X. Some comments follow

Thanks!

 1. An important property of such installers is that you are told, right from 
 the start, that all the information you are presented with during the 
 installation process can be accessed at any time, after completion of the 
 installation, and you are told how. In case of GHC, something like a 
 reference to a suitable spot, given as part of the output from ghc --help. I 
 don't see any trace of such a facility on the introduction screen. (I know 
 that other installers don't do this either, which is part of the reason why I 
 try to avoid them.)

I didn't follow that; can you say exactly what text you want where,
please?

 2. The introduction screen says This package must be installed on the system 
 volume which seems to imply that there is some kind of choice involved at a 
 later stage. But I don't recall having to perform any choice that related to 
 this. So perhaps this should be This package will be installed on the system 
 volume instead.

Good point, done.

 3. I can copy and paste the text of the introduction screen, excellent. I 
 cannot copy and paste the header.

I don't think there's anything we can do about this.

 4. On the License screen, GMP is denoted GNU MP Bignum Library in two 
 places. I suggest using GNU Multiple Precision Arithmetic Library (from 
 http://gmplib.org/) instead.

The title of that page is The GNU MP Bignum Library, and the docs seem
to be mostly consistent in calling it the GNU MP Library, so I'm going
to leave it as it is unless there's consensus for a change.

 5. On the License screen, replace licence by license, twice.

Thanks, changed to make it consistent.

 6. The License screen explains that by default the GMP will be statically 
 linked into any binary produced by GHC. Software with a non-GPL compatible 
 licence [sic] will have to ensure that the conditions of the LGPL are met; 
 for example, by forcing GMP to link dynamically instead. Some details or a 
 reference to an explanation of how to do this would be nice.

I don't think we want details in the installer, but we should have
something in the docs somewhere.

 Also, shouldn't non-GPL compatible be plain non-GPL?

No, I believe (IANAL etc) any license that provides the appropriate
freedoms is OK.

 7. I may very well be wrong, but as far as I have been able to tell, the ghc 
 executable itself that is distributed 
 (/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1.20090314/ghc)
  
 contains GMP, statically linked. For example:
 
  thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 
 thorkilnaur$ DYLD_PRINT_LIBRARIES=YES /usr/bin/ghc --version
  dyld: loaded: /bin/sh
  dyld: loaded: /usr/lib/libncurses.5.4.dylib
  dyld: loaded: /usr/lib/libiconv.2.dylib
  dyld: loaded: /usr/lib/libSystem.B.dylib
  dyld: loaded: /usr/lib/libgcc_s.1.dylib
  dyld: loaded: /usr/lib/system/libmathCommon.A.dylib
  dyld: 
 loaded: 
 /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1.20090314/ghc
  dyld: loaded: /usr/lib/libedit.2.dylib
  dyld: loaded: /usr/lib/libncurses.5.4.dylib
  dyld: loaded: /usr/lib/libSystem.B.dylib
  dyld: loaded: /usr/lib/libgcc_s.1.dylib
  dyld: loaded: /usr/lib/system/libmathCommon.A.dylib
  The Glorious Glasgow Haskell Compilation System, version 6.10.1.20090314
  thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 
 thorkilnaur$
 
 where I fail to observe anything that seems to relate to GMP. This is in 
 contrast to the corresponding information for an earlier GHC installation
 
  thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 
 thorkilnaur$ DYLD_PRINT_LIBRARIES=YES ghc --version
  dyld: loaded: /bin/sh
  dyld: loaded: /usr/lib/libncurses.5.4.dylib
  dyld: loaded: /usr/lib/libiconv.2.dylib
  dyld: loaded: /usr/lib/libSystem.B.dylib
  dyld: loaded: /usr/lib/libgcc_s.1.dylib
  dyld: loaded: /usr/lib/system/libmathCommon.A.dylib
  dyld: 
 loaded: /Users/thorkilnaur/tn/install/ghc-6.8.3/lib/ghc-6.8.3/ghc-6.8.3
  dyld: loaded: /opt/local/lib/libreadline.5.2.dylib
  dyld: loaded: /opt/local/lib/libncurses.5.dylib
  dyld: loaded: /usr/lib/libSystem.B.dylib
  dyld: loaded: /opt/local/lib/libgmp.3.dylib
  dyld: loaded: /usr/lib/libgcc_s.1.dylib
  dyld: loaded: /usr/lib/system/libmathCommon.A.dylib
  The Glorious Glasgow Haskell Compilation System, version 6.8.3
  thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 
 thorkilnaur$
 
 where one observes the presence of dyld: 
 loaded: /opt/local/lib/libgmp.3.dylib that loads the separately installed 
 dynamic GMP library.

Hmm, I'm note sure why that changed. Manuel, do you know?

 9. I cannot copy and paste the text or the header of the Installation Type 
 screen, the one that says This will take 448 MB of space on your computer.  
 Click Install to perform a standard 

Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1

[Ian Lynagh]

On Mon, Mar 16, 2009 at 04:00:09PM +0100, Christian Maeder wrote:
 
 Under Solaris grep does not understand -q in configure:
 
 checkMake380() {
 if $1 --version 21 | head -1 | grep -q 'GNU Make 3\.80'
 
 it fails with:
 
 grep: illegal option -- q
 Usage: grep -hblcnsviw pattern file . . .
 grep: illegal option -- q
 Usage: grep -hblcnsviw pattern file . . .

OK, I'll just redirect stdout to /dev/null then.

Presumably these print 0 and 1 respectively?

echo foo | grep foo  /dev/null; echo $?
echo foo | grep bar  /dev/null; echo $?


Thanks
Ian

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

Re: Under Solaris: GHC 6.10.2 Release Candidate 1

[Ian Lynagh]

On Tue, Mar 17, 2009 at 12:51:23PM +0100, Karel Gardas wrote:
 Christian Maeder wrote:
  Testsuite results are bad for ghc-6.10.1.20090314, see
  http://hackage.haskell.org/trac/ghc/ticket/3106
 
 Patch for the cygpath not found issue is attached to the ticket. Please
 (Windows/Cygwin/Mingw users especially) test it.

Thanks; I'll apply one of the fixes and test on Windows platforms.


Thanks
Ian

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

Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1

[Christian Maeder]

Ian Lynagh wrote:
 On Mon, Mar 16, 2009 at 04:00:09PM +0100, Christian Maeder wrote:
 Under Solaris grep does not understand -q in configure:

 checkMake380() {
 if $1 --version 21 | head -1 | grep -q 'GNU Make 3\.80'

 it fails with:

 grep: illegal option -- q
 Usage: grep -hblcnsviw pattern file . . .
 grep: illegal option -- q
 Usage: grep -hblcnsviw pattern file . . .
 
 OK, I'll just redirect stdout to /dev/null then.
 
 Presumably these print 0 and 1 respectively?
 
 echo foo | grep foo  /dev/null; echo $?
 echo foo | grep bar  /dev/null; echo $?

Yes, Christian

-bash-3.00$ echo foo | grep foo  /dev/null; echo $?
0
-bash-3.00$ echo foo | grep bar  /dev/null; echo $?
1

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

Re: Adding DPH to HEAD

[Ian Lynagh]

Hi Colin,

On Thu, Mar 19, 2009 at 02:53:23PM +, Colin Paul Adams wrote:
 I tried following the advice on the DPH wiki:
 
 ./sync-all --dph get

I would recommend starting with a clean tree by untarring
http://darcs.haskell.org/ghc-HEAD-2009-01-09-ghc-corelibs-testsuite.tar.bz2
and then doing
./darcs-all pull -a
./darcs-all --dph get

For now, avoid any instructions that tell you to use git or sync-all.


Thanks
Ian

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

Re: [Haskell] Re: indirectly recursive dictionaries

[Martin Sulzmann]

On Wed, Mar 18, 2009 at 9:45 AM, Simon Peyton-Jones
simo...@microsoft.comwrote:

 [Redirecting to GHC users.]

 | Tom Schrijvers wrote:
 |  The cyclic dictionaries approach is a bit fragile. The problem appears
 to
 |  be here that GHC alternates exhaustive phases of constraint reduction
 and
 |  functional dependency improvement. The problem is that in your example
 you
 |  need both for detecting a cycle.

 The whole thing relies on spotting a loop, and that's inherently a bit
 fragile. I don't know of any formal work on the subject, although I bet
 there is some.


Satish R. Thatte: Semantics of Type Classes Revisited
http://portal.acm.org/citation.cfm?id=182459

The first reference I'm aware of which discusses co-induction in the type
class context. There are no recursive dictionaries because Thatte's type
class semantics uses run-time type passing (plus method lookup) instead of
dictionary-passing.

Recursive dictionaries are formalized here

Martin Sulzmann: Extracting programs from type class proofs
http://portal.acm.org/citation.cfm?id=1140348

There's no work I know of which discusses type inference in the presence of
co-inductive type classes (and its subtle consequences as pointed out by
Tom's earlier email). Chameleon has supported them using the strategy to
apply first improvement before considering co-induction.

-Martin



 GHC's current algorithm does not run functional dependencies sufficiently
 aggressively, because it treats fundeps a different kind of thing to class
 constraints.  Our new solver, long promised but still in the works, fully
 integrates type classes with type equalities (fundeps, type functions etc),
 and so should do a better job here.  Roughly speaking, the idea is to
 combine our ICFP'08 paper [1] with a type-class solver.  Since writing the
 ICFP'08 paper we have found some very useful simplifications; and we also
 have a new plan for the solving strategy OutsideIn [2].

 That said, solving recursive problems is not our primary focus right now --
 getting it working is -- so I can't promise that it'll do a better job, but
 I think it will.

 | It seems we can convince GHC to do constraint reduction and
 | improvement in the order we desire. The key is to use the
 | continuation-passing style -- which forces things to happen in the
 | right order, both at the run-time and at the compile time.

 Oleg you are a master at persuading GHC's somewhat ad-hoc implementation to
 dance to your tune.  But it'd be better just to make the implementation more
 complete in the solutions it finds.  That's what we are working on now.

 Simon

 [1] 
 http://research.microsoft.com/~simonpj/papers/assoc-types/index.htmhttp://research.microsoft.com/%7Esimonpj/papers/assoc-types/index.htm
 [2] 
 http://research.microsoft.com/~simonpj/papers/gadthttp://research.microsoft.com/%7Esimonpj/papers/gadt
 ___
 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

Another victim of the state hack

[Jules Bean]

I have the impression that it's useful to you to see how often the state 
hack trips people up, so I've added some more comments to


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

...about how it bit me.

This is a real headache. To be frank, controlling lazy evaluation and 
sharing to get the right complexity for your code can be hard enough at 
the best of times, without the compiler sometimes ignoring the sharing 
you try to ask for...


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

Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1

[jutaro]

Hello Simon,
I've put a request about the issue on the gtk2hs users mailing list:

 I've tried a gtk2hs app on ghc 6.10.2 release candidate.
 It crashes frequently and Simon (as you can read down here) assumes it
 is gtk2hs problem.
 My question is:
Is this problem known to gtk2hs developers?
Is it really a gtk2hs problem?
How difficult is it to fix the problem?
When will we have a patch to use gtk2hs with 6.10.2, 
is it already in the repo?  

However, I'm a little surprised that a little version upgrade from 6.10.1 to
6.10.2 may break all gui apps based on gtk2hs. May it be that many more apps
are affected because of this change? What's about wxhaskell e.g.? Well,
maybe we have only few Haskell applications around, but usually I
wouldn't expect such a dramatic effect from such a moderate upgrade. Is this
fix so important to introduce it now? What does it help when it was never
officially supported if it causes such troubles?

Jürgen  
 


Simon Marlow-7 wrote:
 
 jutaro wrote:
 I've installed a GUI application based on gtk2hs.
 
 It frequently crashes with the error: 
 leksah: error: a C finalizer called back into Haskell.
 use Foreign.Concurrent.newForeignPtr for Haskell finalizers.
 
 This error did never occur with the 6.10 released version. It was
 verified
 that this happens on different machines. I've no idea how to isolate this
 bug.
 
 This will need to be fixed in gtk2hs.  Previously GHC allowed finalizers
 to 
 call back into Haskell, but this was never officially supported.  Now it
 is 
 officially unsupported, because finalizers created via
 Foreign.mkForeignPtr 
 are run directly by the garbage collector.
 
 See
 
   http://hackage.haskell.org/trac/ghc/ticket/1364
 
 Cheers,
   Simon
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
 
 

-- 
View this message in context: 
http://www.nabble.com/ANNOUNCE%3A-GHC-6.10.2-Release-Candidate-1-tp22524567p22608413.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at 
Nabble.com.

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

Re: Adding DPH to HEAD

[Colin Paul Adams]

 Ian == Ian Lynagh ig...@earth.li writes:

Ian Hi Colin,

Ian On Thu, Mar 19, 2009 at 02:53:23PM +, Colin Paul Adams wrote:
 I tried following the advice on the DPH wiki:
 
 ./sync-all --dph get

Ian I would recommend starting with a clean tree by untarring
Ian 
http://darcs.haskell.org/ghc-HEAD-2009-01-09-ghc-corelibs-testsuite.tar.bz2
Ian and then doing ./darcs-all pull -a ./darcs-all --dph get

Ian For now, avoid any instructions that tell you to use git or
Ian sync-all.


OK.

That seems to work. Everything up to make install went fine.

After the re-install, I need to re-install various packages using
Cabal in order to compile my program afresh.

So I then went back to the ghc directory, and typed

make

again - just to see.

I get this:

Configuring installPackage-1.0...
/home/colin/ghc/libraries/cabal-bin ghc 
/home/colin/ghc/libraries/bootstrapping.conf 1.7.0 build --distpref 
dist-inplace --ghc-option=-H32m --ghc-option=-O --ghc-option=-Wall
Preprocessing executables for installPackage-1.0...
Building installPackage-1.0...
[1 of 1] Compiling Main ( installPackage.hs, 
dist-inplace/build/installPackage/installPackage-tmp/Main.o )

installPackage.hs:4:0:
Bad interface file: 
/home/colin/ghc/libraries/Cabal/dist-bootstrapping/build/Distribution/PackageDescription.hi
mismatched interface file versions (wanted 61120090319, got 
61120090317)
make[2]: *** [with-bootstrapping-compiler] Error 1
make[2]: Leaving directory `/home/colin/ghc/utils/installPackage'
make[1]: *** [with-bootstrapping-compiler.installPackage] Error 2
make[1]: Leaving directory `/home/colin/ghc/utils'
make: *** [stage1] Error 2

I have no idea what is going on.
-- 
Colin Adams
Preston Lancashire
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1

[Don Stewart]

We must have the gtk2hs team invovled in this discussion. They were
using an undocumented feature. It may be trivial to fix.

--Don

jnf:
 
 Hello Simon,
 I've put a request about the issue on the gtk2hs users mailing list:
 
  I've tried a gtk2hs app on ghc 6.10.2 release candidate.
  It crashes frequently and Simon (as you can read down here) assumes it
  is gtk2hs problem.
  My question is:
 Is this problem known to gtk2hs developers?
 Is it really a gtk2hs problem?
 How difficult is it to fix the problem?
 When will we have a patch to use gtk2hs with 6.10.2, 
 is it already in the repo?  
 
 However, I'm a little surprised that a little version upgrade from 6.10.1 to
 6.10.2 may break all gui apps based on gtk2hs. May it be that many more apps
 are affected because of this change? What's about wxhaskell e.g.? Well,
 maybe we have only few Haskell applications around, but usually I
 wouldn't expect such a dramatic effect from such a moderate upgrade. Is this
 fix so important to introduce it now? What does it help when it was never
 officially supported if it causes such troubles?
 
 Jürgen  
  
 
 
 Simon Marlow-7 wrote:
  
  jutaro wrote:
  I've installed a GUI application based on gtk2hs.
  
  It frequently crashes with the error: 
  leksah: error: a C finalizer called back into Haskell.
  use Foreign.Concurrent.newForeignPtr for Haskell finalizers.
  
  This error did never occur with the 6.10 released version. It was
  verified
  that this happens on different machines. I've no idea how to isolate this
  bug.
  
  This will need to be fixed in gtk2hs.  Previously GHC allowed finalizers
  to 
  call back into Haskell, but this was never officially supported.  Now it
  is 
  officially unsupported, because finalizers created via
  Foreign.mkForeignPtr 
  are run directly by the garbage collector.
  
  See
  
http://hackage.haskell.org/trac/ghc/ticket/1364
  
  Cheers,
  Simon
  ___
  Glasgow-haskell-users mailing list
  Glasgow-haskell-users@haskell.org
  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
  
  
 
 -- 
 View this message in context: 
 http://www.nabble.com/ANNOUNCE%3A-GHC-6.10.2-Release-Candidate-1-tp22524567p22608413.html
 Sent from the Haskell - Glasgow-haskell-users mailing list archive at 
 Nabble.com.
 
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://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: ANNOUNCE: GHC 6.10.2 Release Candidate 1

[Duncan Coutts]

On Thu, 2009-03-19 at 16:34 -0700, Don Stewart wrote:
 We must have the gtk2hs team invovled in this discussion. They were
 using an undocumented feature. It may be trivial to fix.

   This will need to be fixed in gtk2hs.  Previously GHC allowed finalizers
   to call back into Haskell, but this was never officially supported.  Now 
   it
   is officially unsupported, because finalizers created via
   Foreign.mkForeignPtr are run directly by the garbage collector.

I had a quick look but so far I cannot see where any callback into
Haskell is happening. The only interesting case I've found is one
finaliser which is implemented in C and uses hs_free_stable_ptr.

Duncan

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

Re: Adding DPH to HEAD

[Manuel M T Chakravarty]

Colin Paul Adams:

I tried following the advice on the DPH wiki:

./sync-all --dph get

This wouldn't run because of permissions, so I tried putting sh in
front of the command. This produced a lot of error messages:


Some guy by the handle of Megacz added this to the page.  No idea  
why.  I'll change that.


Manuel

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