Re: [GHC] #1741: Threaded RTS must use processor affinity and processor information
#1741: Threaded RTS must use processor affinity and processor information +--- Reporter: guest | Owner: Type: task| Status: new Priority: normal | Milestone: 6.8 branch Component: Runtime System |Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple| +--- Comment (by guest): Replying to [comment:2 simonmar]: One problem with setting `-N` to something other than 1 by default is that `System.Posix.forkProcess` only works with `-N1`, so if you use that function then you need to fix `-N1` somehow (probably with a hook). I'm not sure I want to contemplate making `forkProcess` work for larger values of N. I suspect `forkProcess` is rare, and we might want to deprecate it anyway. Does anyone have opinion about it? I think that if someone want to use -threaded option, he want to use more than 2-core normally. So setting -N to 1 by default isn't good solution. I think that writing about this problem on Haddock System.Posix.forkProcess document, and then deprecating `forkProcess` is better solution. Because if someone can't find `forkProcess` problem in document, he cann't decide to use `forkProcess` or not. His program works well with default -N1, but he suddenly encounts problem when setting option -N to parallelize his program. That isn't good. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1741#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1824: Make an extension flag for postfix operators
#1824: Make an extension flag for postfix operators
--+-
Reporter: igloo | Owner:
Type: bug| Status: new
Priority: normal | Milestone: 6.10 branch
Component: Compiler (Parser) | Version: 6.8.1
Severity: normal |Keywords:
Difficulty: Unknown|Testcase:
Architecture: Unknown| Os: Unknown
--+-
From this thread: http://www.haskell.org/pipermail/cvs-
ghc/2007-November/039289.html
{{{
2 while looking up 8.3.7, i saw this note in 8.3.6, on
postfix operators:
(No Haskell 98 programs change their behaviour, of course.)
like so many of course notes, this is wrong, of course;-)
haskell98 has seq, and that makes eta-expansion observable.
$ /cygdrive/c/ghc/ghc-6.4.1/bin/ghc -e
'let (!) a = undefined in (undefined !) `seq` True'
True
$ /cygdrive/c/ghc/ghc-6.6.1/bin/ghc -e
'let (!) a = undefined in (undefined !) `seq` True'
*** Exception: Prelude.undefined
Good point. We probably ought to make it an extension and give it a -X
flag anyway; I don't think (without having looked at the code) it should
be hard.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1824
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1824: Make an extension flag for postfix operators
#1824: Make an extension flag for postfix operators ---+ Reporter: igloo | Owner: Type: bug| Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Parser) |Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown| ---+ Comment (by guest): actually, since this has been default behaviour in 6.6.1, and in hugs for quite a bit longer, it doesn't seem to have bitten anyone, so i was just asking for the docs to be amended. claus -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1824#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ANNOUNCE: GHC version 6.8.1
= The (Interactive) Glasgow Haskell Compiler -- version 6.8.1 = The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Haskell Program Coverage (hpc) support has been added to the compiler * GHCi now includes a debugger * The first phase of the base package split has been done * The code generator now uses pointer tagging (which should mean most code improves by 10-15%, and as a result the compiler is also faster). The full release notes are here: http://haskell.org/ghc/docs/6.8.1/html/users_guide/release-6-8-1.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Too many local registers...
| I never found a satisfactory answer. On IA64 we just hope that ghc | generates C code that does not turn into object code that uses too many | variables. We tried playing with gcc flags to make it only use the | limited number of registers but could not make it work. The only | workarounds I know of are to use less aggressive optimisation, both in | ghc and gcc, so try with -optc-O rather than -optc-O2 and try -O0 rather | than -O. | | Duncan Thank you all for the answers, specially to Duncan... -optc-O did the trick :) Best Cristian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Generalized newtype deriving 6.6 vs. 6.8
Hello,
I noticed there is a difference in generalized newtype deriving between
6.6 and 6.8. In GHC 6.4.1 the following:
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
import Control.Monad.Error
newtype MyMonad m a = MyMonad (m a)
deriving (Monad, MonadError String)
correctly gives a derived instance
MonadError String m = MonadError String (MyMonad m)
The new GHC 6.8.1 complains with:
No instance for (MonadError String m)
arising from the 'deriving' clause of a data type declaration
at DeriveTest.hs:(5,0)-(6,36)
Possible fix: add an instance declaration for (MonadError String m)
When deriving the instance for (MonadError String (MyMonad m))
Generalizing the instance to
MonadError e m = MonadError e (MyMonad m)
works in both versions.
Twan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
6.6.1 installlers
Hello glasgow-haskell-users, i've found that 6.6.1 downloading page ( http://haskell.org/ghc/download_ghc_661.html ) doesn't contain info about availability of Debian, Fedora and SUSE packages. is it possible to add it there? (also for other unices where such packages exist) the reason is that i distribute sources of my program and point users to this page for instructions on installing GHC. but it suggests to use generic linux package and don't tell anything about OS-specific packages. my users are not haskellers so they will be unable to find and install GHC package without knowing its exact name -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.6.1 installlers
Hi Bulat, On Sun, Nov 04, 2007 at 01:54:19AM +0300, Bulat Ziganshin wrote: i've found that 6.6.1 downloading page ( http://haskell.org/ghc/download_ghc_661.html ) doesn't contain info about availability of Debian, Fedora and SUSE packages. is it possible to add it there? (also for other unices where such packages exist) I've added a paragraph and a link to the distribution packages page from the 6.6.1 and 6.8.1 download pages. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] ANNOUNCE: GHC version 6.8.1
= The (Interactive) Glasgow Haskell Compiler -- version 6.8.1 = The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Haskell Program Coverage (hpc) support has been added to the compiler * GHCi now includes a debugger * The first phase of the base package split has been done * The code generator now uses pointer tagging (which should mean most code improves by 10-15%, and as a result the compiler is also faster). The full release notes are here: http://haskell.org/ghc/docs/6.8.1/html/users_guide/release-6-8-1.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] The question of ByteString
Duncan Coutts wrote: On Fri, 2007-11-02 at 21:35 +, Andrew Coppin wrote: Well OK, maybe I was a little vague. Let me be a bit more specific... If you do text processing using ByteString rather than String, you get dramatically better performance in time and space. For me, this raises a number of questions: 1. Why do I have to type ByteString in my code? Why isn't the compiler automatically performing this optimisation for me? (I.e., is there some observable property that is changed? Yes, the semantics are different. ByteString is stricter. In some circumstances you could discover that some list is being used sufficiently strictly (spine and element strict) that you could do a representation change to use strict arrays. It is something I have pondered occasionally and I think that is an interesting avenue for research. OK. So I'm not the first person to wonder about this then... ;-) One approach might be to do a more sophisticated strictness analysis However this is likely to be quite fragile. I usually think that it's better to declare the strictness you want up front in one place Yeah, I can imagine. And I guess then you'd be forever wondering hey, did the compiler do that optimisation or not? like with certain current optimisations now. (E.g., did that type get unboxed?) Currently the answer is yes: the ByteString interface only provides trancated Unicode characters. But, in principle, that could be changed.) Indeed it could, we could provide a proper Unicode string type. Likely to happen in the near term? (Not that I imagine this is a huge issue for anybody...) 2. ByteString makes text strings faster. But what about other kinds of collections? Can't we do something similar to them that makes them go faster? There is much less benefit for other collections since the overheads of generic structures are smaller for other types. Note that the NDP parallel arrays stuff uses type functions to calculate optimised data representations for arrays of types. Type... functions...? That sounds pretty scary. :-} I was thinking more immediately about lists in general, but also perhaps binary trees and things. (Although it's probably hard to optimise a general binary tree; you would probably optimise a tree designed for a specific *purpose* instead...) As I understand it, ByteString is faster due to several factors. First of all, it's stricter. So that's the semantic difference. Secondly, it's an unboxed structure. Which is the representation optimisation allowed by the semantic change of making it stricter. Indeed. Third, it's implemented as an array that looks like a linked list. Given how ubiquitous lists are in Haskell, array that looks like a linked list sounds like one seriously useful data type! Yet ByteString seems to be the only implementation of this concept - and only for lists on unboxed bytes. (Not even unboxed Word16 or anything else, *only* Word8.) If I understand this correctly, a ByteString is actually a linked list of large array chunks. (This presumably yields fastER random access than a plain linked list?) Also, it seems to be possible to create a new array which is merely a subrange of an existing one, without any copying; the standard array API doesn't seem to provide this, yet it sounds damn useful. I think the NDP project should get us most of this stuff actually. Cool. So in summary, these kinds of things are on the way, they're just not here quite yet? (BTW, anybody have any clue what's happening with stream fusion? I remember reading the paper saying hey, this is how it works and it's cool and we're going to try to replace the whole list library with new stream implementations, but that's the last I heard...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why does GHC limit stack size?
Hello all, Why is there a limitation on the stack size in GHC? Like heap where we can limit the size by -M RTS option but the default is unlimited, why not let the program use as big a stack as required? If not by default, then by a separate option? Some of the functions that we write in recursive fashion will usually cause a stack overflow, but will work fine if there is more stack (suppose we are not worried about efficiency). And these functions generally look nicer and compact than their tail recursive versions. Is this is a technical hurdle, or just a checkpoint for runaway programs? Can we have an RTS flag allowing unlimited stack size? Thanks, Abhay ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does GHC limit stack size?
Hello, Why is there a limitation on the stack size in GHC? Like heap where we can limit the size by -M RTS option but the default is unlimited, why not let the program use as big a stack as required? If not by default, then by a separate option? Some of the functions that we write in recursive fashion will usually cause a stack overflow, but will work fine if there is more stack (suppose we are not worried about efficiency). And these functions generally look nicer and compact than their tail recursive versions. Is this is a technical hurdle, or just a checkpoint for runaway programs? This was discussed a while ago on the ghc users mailing list. I think there was general agreement that this was bad, but that doing something better meant a lot of work for someone (who could be trusted to get it right :-) http://www.haskell.org/pipermail/glasgow-haskell-users/2007-May/012467.html Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does GHC limit stack size?
Bulat Ziganshin wrote: because program that require 8mb stack, will probably require 8gb when processing more data :) So.. what? You could say the same about heap, which was rather the point of the earlier thread. Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The question of ByteString
Andrew Coppin wrote: Duncan Coutts wrote: Yes, the semantics are different. ByteString is stricter. In some circumstances you could discover that some list is being used sufficiently strictly (spine and element strict) that you could do a representation change to use strict arrays. It is something I have pondered occasionally and I think that is an interesting avenue for research. Also important is the fact that String = [Char], and a Char can hold any Unicode character, whereas a ByteString is a sequence of Word8 elements (i.e. integers from 0-255). If you want to store a Char in a ByteString then you have to convert it to UTF-8 or something similar. The Encoding package (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/encoding-0.2) has the functions for this kind of thing. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why can't Haskell be faster?
On Nov 3, 2007 5:00 AM, Ryan Dickie [EMAIL PROTECTED] wrote: Lossless File compression, AKA entropy coding, attempts to maximize the amount of information per bit (or byte) to be as close to the entropy as possible. Basically, gzip is measuring (approximating) the amount of information contained in the code. Hmmm, interesting idea. I think it would be interesting to compare the ratios between raw file size its entropy (we can come up with a precise metric later). This would show us how concise the language and code actually is. Yeah, let's all write in bytecode using a hex editor :-D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compile-time evaluation
Hi Nicholas, compileTimeEval :: Data a = a - ExpQ compileTimeEval = return . toExp You're telling me all that horrendous pain in implementing toExp and it already exists?!? Yes unfortunately, compileTimeEval already exists in TH, it's called lift compileTimeEval :: Lift a = a - ExpQ compileTimeEval = lift But don't be so hard on yourself. Your approach has one advantage. GHC supports automatic derivation of Data whereas Lift instances have to be created manually. Note, however, that Lift instances can also be generated using Igloo's th-lift package[1]. Cheers, Fons [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/th-lift-0.2 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The question of ByteString
On Nov 3, 2007, at 5:34 , Andrew Coppin wrote: (BTW, anybody have any clue what's happening with stream fusion? I remember reading the paper saying hey, this is how it works and it's cool and we're going to try to replace the whole list library with new stream implementations, but that's the last I heard...) dons and I have both mentioned Data.Stream recently; I think it's on hackage. It's still a work in progress though, I believe. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Rose Tree
Hello, I need help... I am having trouble with rose trees. 1 2 3 4 5 6 7 8910 11 That is the rose tree that I seek. Data Tree a = Empty | Leaf a | Node a [(Tree a)] example :: Tree (String, String) example = Node (a,b) -- root node [ ] -- end of tree What I want to do is create two functions that return either the children or parents of a given input, here a String. String - Tree - [String] I think _ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] torrent for 6.8.1?
do torrents exist for 6.8.1? my experience is that people will use torrents if they are offered and they really do lift the pressure from the origin domain (haskell.org) pgpTQvjxj07Kq.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
