MonoLocalBinds and darcs
Hi, 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. Also, NoMonoLocalBinds didn't help at all, which surprised me a bit - I thought it might at least make some of the signatures unnecessary. Finally, is NoMonoLocalBinds supposed to imply NPlusKPatterns? The only changes I was able to revert when I enabled it were a couple of those! 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
Re: Unicode windows console output.
This is evidence for the broken Unicode support in the Windows terminal and not a problem with GHC. I experienced the same many times. 2010/11/2 David Sankel cam...@gmail.com: On Mon, Nov 1, 2010 at 10:20 PM, David Sankel cam...@gmail.com wrote: Hello all, I'm attempting to output some Unicode on the windows console. I set my windows console code page to utf-8 using chcp 65001. The program: -- Test.hs main = putStr λ.x→x The output of `runghc Test.hs`: λ.x→ From within ghci, typing `main`: λ*** Exception: stdout: hPutChar: permission denied (Permission denied) I suspect both of these outputs are evidence of bugs. Might I be doing something wrong? (aside from using windows ;)) I forgot to mention that I'm using Windows XP with ghc 6.12.3. -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office) ___ 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
Loop optimisation with identical counters
Hi,
is the following problem a job for ghc or the code generation backend
(llvm)?
We are given this program:
{-# LANGUAGE BangPatterns #-}
module Main where
f :: Int - Int - Int - Int - Int
f !i !j !s !m
| i == 0= s+m
| otherwise = f (i-1) (j-1) (s + i+1) (m + j*5)
g :: Int - Int
g !k = f k k 0 0
ff :: Int - Int - Int - Int
ff !i !s !m
| i == 0= s+m
| otherwise = ff (i-1) (s + i+1) (m + i*5)
gg :: Int - Int
gg !k = ff k 0 0
main = do
print $ g 20
print $ gg 20
Here, 'f' and 'g' are a representation of the code I have. Both counters
'i' and 'j' in 'f' count from the same value with the same step size and
terminate at the same time but are not reduced to just one counter. Can
I reasonably expect this to be done by the code generator?
'ff' represents what I would like to see.
Btw. look at the core, to see that indeed 'f' keep four arguments.
Functions like 'f' are a result of vector-fusion at work but can be
written by oneself as well. The point is that if 'f' gets reduced to
'ff' then I can have this:
fun k = zipWith (+) (map f1 $ mkIdxs k) (map f2 $ mkIdxs k)
which makes for nicer code sometimes; but before rewriting I wanted to
ask if that kills performance.
Thanks,
Christian
pgpmeFwIBNFcB.pgp
Description: PGP signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wadler space leak
On 01/11/2010 16:52, Jan Christiansen wrote: On 01.11.2010, at 10:38, Simon Marlow wrote: On 28/10/2010 14:21, Bertram Felgenhauer wrote: Right. The optimization works by producing special thunks for tuple selectors which the garbage collector can recognize and evaluate during GC. However the implementation in GHC is quite brittle. See http://hackage.haskell.org/trac/ghc/ticket/2607 I suspect your program is another instance of this behaviour. Yes, that's exactly what happens. Thanks very much for the explanation. It seems to me that this bug is not considered as high priority. Is this correct? So it is not likely that this will be fixed in one of the next ghc releases, is it? It's not really a question of priority, rather that we don't know of a good way to fix it! Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
link problem under macosx
Hi, after installing http://lambda.galois.com/hp-tmp/2010.2.0.0/haskell-platform-2010.2.0.0.i386.dmg and various more libraries using cabal, we get the following linker error below. A simple hello program compiles and links fine and uses /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) as shown by otool -L. Does someone have an explanation or solution? Cheers Christian Linking dist/build/hets/hets ... Undefined symbols: _iconv_close, referenced from: _hs_iconv_close in libHSbase-4.2.0.2.a(iconv.o) _iconv_open, referenced from: _hs_iconv_open in libHSbase-4.2.0.2.a(iconv.o) _iconv, referenced from: _hs_iconv in libHSbase-4.2.0.2.a(iconv.o) ld: symbol(s) not found collect2: ld returned 1 exit status ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: link problem under macosx
Am 02.11.2010 11:48, schrieb Christian Maeder: Hi, after installing http://lambda.galois.com/hp-tmp/2010.2.0.0/haskell-platform-2010.2.0.0.i386.dmg and various more libraries using cabal, we get the following linker error below. A simple hello program compiles and links fine and uses /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) as shown by otool -L. Does someone have an explanation or solution? adding -L/usr/lib as first argument to ghc solved the problem. Another cabal-package (gtk and friends) used /opt/local/lib under library-dirs:. Are there better workarounds? C. Cheers Christian Linking dist/build/hets/hets ... Undefined symbols: _iconv_close, referenced from: _hs_iconv_close in libHSbase-4.2.0.2.a(iconv.o) _iconv_open, referenced from: _hs_iconv_open in libHSbase-4.2.0.2.a(iconv.o) _iconv, referenced from: _hs_iconv in libHSbase-4.2.0.2.a(iconv.o) ld: symbol(s) not found collect2: ld returned 1 exit status ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MonoLocalBinds and darcs
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 :-) 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. I'm not sure what (if anything) we should do about this. 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. Cheers, Simon 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: Loop optimisation with identical counters
On 02/11/2010 08:17, Christian Höner zu Siederdissen wrote:
Hi,
is the following problem a job for ghc or the code generation backend
(llvm)?
We are given this program:
{-# LANGUAGE BangPatterns #-}
module Main where
f :: Int - Int - Int - Int - Int
f !i !j !s !m
| i == 0= s+m
| otherwise = f (i-1) (j-1) (s + i+1) (m + j*5)
g :: Int - Int
g !k = f k k 0 0
ff :: Int - Int - Int - Int
ff !i !s !m
| i == 0= s+m
| otherwise = ff (i-1) (s + i+1) (m + i*5)
gg :: Int - Int
gg !k = ff k 0 0
main = do
print $ g 20
print $ gg 20
Here, 'f' and 'g' are a representation of the code I have. Both counters
'i' and 'j' in 'f' count from the same value with the same step size and
terminate at the same time but are not reduced to just one counter. Can
I reasonably expect this to be done by the code generator?
'ff' represents what I would like to see.
GHC doesn't have any optimisations that would do this currently,
although it's possible that LLVM's loop optimisations might do this on
the generated code for f.
Cheers,
Simon
Btw. look at the core, to see that indeed 'f' keep four arguments.
Functions like 'f' are a result of vector-fusion at work but can be
written by oneself as well. The point is that if 'f' gets reduced to
'ff' then I can have this:
fun k = zipWith (+) (map f1 $ mkIdxs k) (map f2 $ mkIdxs k)
which makes for nicer code sometimes; but before rewriting I wanted to
ask if that kills performance.
Thanks,
Christian
___
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: MonoLocalBinds and darcs
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
Re: Local evidence and type class instances
Hello, Now that the Glorious New type checker can handle local evidence seamlessly, is it a big implementation burden to extend it to deal with local *type class instances* in addition to local *equality constraints*? For example, you could write this: f :: Bool f = id id where instance Ord (a - b) where _ `compare` _ = LT I dislike the fact that you can produce incoherent instances with that extension. How about a restricted version that only works on fresh types? f :: Bool - Bool f b = N id N id where -- N is a fresh type, unique to a particular application of f. newtype N = N (a - b) instance Ord N where _ `compare` _ = LT This is sufficient for implicit configurations, and avoids the overlap of the new instances with existing instances. I don't know how much extra burden local type definitions like these would add. Bertram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fixing LDAP lib compilation on OpenBSD
On Sat, Oct 30, 2010 at 07:28:40PM +0200, Julien Dessaux wrote: I'm using the LDAP lib for one of my projects and I found a problem while building it on an OpenBSD system. It wouldn't compile because there is a macro named differently in the ldap.h include file. Under linux, this macro is named LDAP_X_PROXY_AUTHZ_FAILURE but on OpenBSD (and probably other BSD flavours), it's named LDAP_PROXY_AUTHZ_FAILURE. I attached the diff I wrote in order to compile the lib on OpenBSD, but it's not a patch I can submit cause it now won't compile on Linux. How can I amend this in order to have a code that would compile on both systems? How is it possible to specify such conditional system dependent stuff for a C binding? You can use different CC-Options in LDAP.cabal depending on the OS. For example if os(openbsd) CC-Options: -DLDAP_X_PROXY_AUTHZ_FAILURE=LDAP_PROXY_AUTHZ_FAILURE else CC-Options: -DLDAP_DEPRECATED=1 Or, if LDAP_X_PROXY_AUTHZ_FAILURE is only used on Linux, just do it reverse, i.e. patch the sources to use LDAP_PROXY_AUTHZ_FAILURE and conditionally define it as LDAP_X_PROXY_AUTHZ_FAILURE on Linux; whatever fits better. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: link problem under macosx
Hello, On Tue, Nov 02, 2010 at 01:03:04PM +0100, Christian Maeder wrote: ... Are there better workarounds? I am not sure about that, I assume that you have looked at http://hackage.haskell.org/trac/ghc/ticket/4068? ... Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: link problem under macosx
From: Christian Maeder christian.mae...@dfki.de Am 02.11.2010 11:48, schrieb Christian Maeder: Hi, after installing http://lambda.galois.com/hp-tmp/2010.2.0.0/haskell-platform-2010.2.0.0.i386.dmg and various more libraries using cabal, we get the following linker error below. A simple hello program compiles and links fine and uses /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) as shown by otool -L. Does someone have an explanation or solution? adding -L/usr/lib as first argument to ghc solved the problem. Another cabal-package (gtk and friends) used /opt/local/lib under library-dirs:. Are there better workarounds? Judging from the /opt/*, it looks like you're using macports for gtk. The libiconv provided by macports is incompatible with the system libiconv, and trying to mix the two is a doomed effort. If you're using a gtk2hs from macports (or gtk+ from macports) it will link to /opt/local/lib/libiconv, but HP and ghc core libraries will link to /usr/lib/libiconv. This means that various haskell packages will be entirely incompatible with each other, and problems will manifest as these linker errors. Since Apple seems disinclined to fix the system's libiconv, and macports projects refuse to use it, the only real solution is to use either HP without macports or the macports GHC without HP. Personally I chose to use the HP and built gtk+ using http://gtk-osx.sourceforge.net/ , which is moderately painful but has been stable once it's built. John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode windows console output.
Is there a ghc wontfix bug ticket for this? Perhaps we can make a small C test case and send it to the Microsoft people. Some[1] are reporting success with Unicode console output. David [1] http://www.codeproject.com/KB/cpp/unicode_console_output.aspx On Tue, Nov 2, 2010 at 3:49 AM, Krasimir Angelov kr.ange...@gmail.comwrote: This is evidence for the broken Unicode support in the Windows terminal and not a problem with GHC. I experienced the same many times. 2010/11/2 David Sankel cam...@gmail.com: On Mon, Nov 1, 2010 at 10:20 PM, David Sankel cam...@gmail.com wrote: Hello all, I'm attempting to output some Unicode on the windows console. I set my windows console code page to utf-8 using chcp 65001. The program: -- Test.hs main = putStr λ.x→x The output of `runghc Test.hs`: λ.x→ From within ghci, typing `main`: λ*** Exception: stdout: hPutChar: permission denied (Permission denied) I suspect both of these outputs are evidence of bugs. Might I be doing something wrong? (aside from using windows ;)) I forgot to mention that I'm using Windows XP with ghc 6.12.3. -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: link problem under macosx
On 11/2/10 10:20 AM, John Lato wrote: Since Apple seems disinclined to fix the system's libiconv, and macports projects refuse to use it, the only real solution is to use either HP without macports or the macports GHC without HP. Personally I chose to use the HP and Not so, as mentioned you just need to make sure /usr/lib is in the link path before /opt/local/lib. Add -L/usr/lib to your build flags for ghc --make, and put: extra-lib-dirs: /usr/lib extra-lib-dirs: /opt/local/lib in that order in ~/.cabal/config for cabal build. This is a very FAQ and needs to be documented somewhere more obvious, I wonder where. cabal-install and GHC release notes ? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: making 7.01-pre
On Sat, Oct 30, 2010 at 03:43:42PM +0400, Serge D. Mechveliani wrote: Then, making it from source by itself reports /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Irts -DGEN_HASKELL -c includes/mkDerivedConstants.c -o includes/dist-ghcconstants/build/mkDerivedConstants.o ... ... ... utils/genprimopcode/dist/build/Lexer.o: In function `s2yT_info': (.text+0x1e1d): undefined reference to `__stginit_arrayzm0zi3zi0zi2_DataziArray_' Thanks for the report. Now fixed. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MonoLocalBinds and darcs
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 ganesh.sittampa...@credit-suisse.com 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: MonoLocalBinds and darcs
Hi Neil, On Tue, 2 Nov 2010, Neil Mitchell wrote: 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. I was using RC2. But darcs uses GADTs globally so MonoLocalBinds is always on. I've now retested with NoMonoLocalBinds properly enabled and I just needed one extra signature. That's quite compelling, but I'm aware it's not considered a reliable feature so I'm not quite sure which way to go. The NPlusKPatterns thing seems to have been a red herring btw, I can't reproduce it now. Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
