* Daniel Peebles [2011-10-11 23:18:15-0400]
> Yeah, you should absolutely mind the order of the parameters (or more
> generally, when the operation isn't commutative), the strictness of the
> function's second parameter. In this case, both (&&) and (||) are strict in
> their first parameter, but b
Hi Frodo,
If you happen to have a memory consumption graph somewhere on the screen
you can see that while testr does not need considerable amounts of
memory, testr' does. This can also be seen by ghci’s output.
The reason is that with testr we are building something like
True && [thunk]
which the
* Frodo Chao [2011-10-12 10:45:04+0800]
> Hi,
>
> I came upon this when playing with foldr and filter. Compare the two
> definitions:
>
> testr n = foldr (\x y -> x && y) True [t | (_, t) <- zip [1 .. n] [True,
> True ..]]
> testr' n = foldr (\x y -> y && x) True [t | (_, t) <- zip [1 .. n] [Tr
Did you try 7.2? As I mentioned, the issue should have gone away entirely
because there is no shared cache any more
Simon
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Jean-Marie
Gaillourdet
Sent: 12 October 2011 07:19
To: wagn
George, Thanks very much for this. I like your suggestion, which
fits the logical structure perfectly; and you've suggested a neat way
around the ugliness of 'group groupBy'. I also note that if we aren't
so worried about not introducing new keywords, that 'then group' could
become 'group'. You
Hi,
Thank you all for you replies.
I think now I understand Haskell better.
Best regards,
Frodo
2011/10/12 Frodo Chao
> Hi,
>
> I came upon this when playing with foldr and filter. Compare the two
> definitions:
>
> testr n = foldr (\x y -> x && y) True [t | (_, t) <- zip [1 .. n] [True,
> T
On 11/10/2011 18:45, David Peixotto wrote:
Ok, I have attached a set of patches to support building the GHC
runtime with llvm-gcc. The patches are based off of commit
29a97fded4010bd01aa0a17945c84258e285d421 which was last Friday's HEAD.
These patches are also available from my github repository
Roman, Jan-Willem
I'm maxed out at the moment, and will be so for at least a week.
If you think there is something mysterious and J-W agrees, could you create a
ticket, with the smallest example you can, and instructions to reproduce?
That'd be brilliant.
Of course, Jan-Willem, if you have a
On 11/10/2011 19:02, Iavor Diatchki wrote:
Hello,
Does anyone have any advice about how I might make a smallish GHC installation?
The context is that I need to make a demo VM, which has a limited
amount of space, and I'd like to have GHC installed on the system but
the default GHC installation
Jean-Marie Gaillourdet wrote:
> This is my previous program with your workaround, it is also attached as
> TypeRepEqLock.hs
>
[snip]
> Compile and execute:
>
> $ ghc-7.0.3 -threaded -rtsopts TypeRepEqLock.hs
>
> $ while true ; do ./TypeRepEqLock +RTS -N ; done
> Ok
> Ok
> Ok
> Ok
> Ok
> Ok
> Ok
Hi Simon,
On 12.10.2011, at 10:34, Simon Peyton-Jones wrote:
> Did you try 7.2? As I mentioned, the issue should have gone away entirely
> because there is no shared cache any more
Yes, I did test it with GHC 7.2. And yes, with GHC 7.2 typeOf is fine. I
continued to look into that issue bec
Hi Bertram,
On 12.10.2011, at 13:24, Bertram Felgenhauer wrote:
> This has nothing to do with Data.Typeable though - it appears to be some
> interaction between unsaferPerformIO and MVars that I do not understand.
> The following program occasionally terminates with "thread blocked
> indefinitely
Thanks Daniel for confirming this.
I suspect this is caused by some rewrite rules in vector. So I
reported it in their issue-tracker:
http://trac.haskell.org/vector/ticket/63
Regards,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@h
On Oct 12, 2011, at 5:26 AM, Simon Marlow wrote:
> On 11/10/2011 18:45, David Peixotto wrote:
>> Ok, I have attached a set of patches to support building the GHC
>> runtime with llvm-gcc. The patches are based off of commit
>> 29a97fded4010bd01aa0a17945c84258e285d421 which was last Friday's HEAD.
The only difference in generated code is in the showsPrec function for a
newtype-wrapped Int (ThreadId).
The code actually never (explicitly) uses Show instance -- it's only
needed as a dependency for Num instance.
Could it be some cache effect?
I'll see if I can reduce that code and then will f
Just FYI, Xcode 4.2 is live in the Mac App Store now, and it has some nice
goodies (i.e., many who develop for iOS and probably also OS X will probably
adopt it soon).
Manuel
PS: Sorry for not having participated in the discussion on how to solve this,
but I have too many loose ends right now.
16 matches
Mail list logo
