It seems to me that the documentation could be further refined:
An acquisition operation cannot be interrupted when the requested resource is
available; the resource is successfully acquired and the subsequent computation
can proceed. On the other hand, if the resource is unavailable, then the
I've been trying to profile my program and having some trouble. I
imagine other people have stumbled across these same issues, so
hopefully I can benefit from someone else's experience. In return, if
I can figure out some of these things, I'll put it up at
http://www.haskell.org/haskellwiki/How_t
On 14.06.10 17:25, Serge D. Mechveliani wrote:
lng [1 .. n] =
lng (1 : (list 2 n)) = 1 + (lng $ list 2 n) =
1 + (lng (2: (list 3 n))) = 1 + 1 + (lng $ list 3 n) = {- !!! -}
2 + (lng (3: (list 4 n))) -- because this "+" is of Integer
= 2 + 1 + (lng $ list 4 n) = {- !!! -}
3 + (lng $
Hello.
On 15.06.10 17:52, Denys Rtveliashvili wrote:
Please could you explain which Nums are not strict? The ones I am
aware about are all strict.
Any value of any type is not strict in Haskell.
Also, why doesn't it require building the full thunk for non-strict
Nums? Even if they are not stri
On Tue, Jun 15, 2010 at 12:41 PM, Simon Marlow wrote:
> On 15/06/2010 09:00, Bas van Dijk wrote:
>>
>> On Mon, Jun 14, 2010 at 11:20 PM, Don Stewart wrote:
>>>
>>> v.dijk.bas:
Hello,
I've a short question about interruptible operations. In the following
program is it poss
On Tuesday 15 June 2010 16:52:04, Denys Rtveliashvili wrote:
> Hi Daniel,
>
> Thank you very much for the explanation of this issue.
>
> While I understand the parts about rewrite rules and the big thunk, it
> is still not clear why it is the way it is.
>
> Please could you explain which Nums are n
Hi Daniel,
Thank you very much for the explanation of this issue.
While I understand the parts about rewrite rules and the big thunk, it
is still not clear why it is the way it is.
Please could you explain which Nums are not strict? The ones I am aware
about are all strict.
Also, why doesn't it
Dear Claus, et al.
I've already responded in more detail in another e-mail on the seemingly
inconsistent behaviour of GHCi, but I also wanted to respond to your points
here.
On Jun 10, 2010, at 4:15 PM, Claus Reinke wrote:
>> I have been experimenting some more with environments for lab work f
On Jun 11, 2010, at 5:10 AM, Brandon S. Allbery KF8NH wrote:
> This doesn't surprise me; when putting it in the module, it affects only that
> module. When using either command line version, it affects *everything*...
> and what's breaking is not your definition of Number, but the ghci
> e
On 15/06/2010 09:00, Bas van Dijk wrote:
On Mon, Jun 14, 2010 at 11:20 PM, Don Stewart wrote:
v.dijk.bas:
Hello,
I've a short question about interruptible operations. In the following
program is it possible for 'putMVar' to re-throw asynchronous
exceptions even when asynchronous exception ar
On 14/06/2010 17:00, Christian Maeder wrote:
Hi,
I've successfully compiled ghc-6.12.3 under x86 solaris.
However, for the testsuite I had to add '-lz' to the threaded1 entry of
config.way_flags in file testsuite/config/ghc:
'threaded1' : ['-lz', '-threaded', '-debug'],
Otherwise I
On 13/06/2010 07:26, austin seipp wrote:
Hello,
I am running GHC on x86_64 debian linux, and recently I have
discovered that the executables generated by my GHC segfault when the
linking step is not dynamic.
I discovered this while attempting to install haskell-src-exts, which
requires a linked
[ glasgow-haskell-users CC'd, as requested ]
Hi Hamish,
Sorry for the delay in replying, things have been busy over the last few
days with paper deadlines and suchlike.
On 05/06/2010 15:14, Hamish Mackenzie wrote:
We want to try to add Haskell to TakeoffGW (a new Windows
distribution like cy
On Mon, Jun 14, 2010 at 11:20 PM, Don Stewart wrote:
>
> v.dijk.bas:
>> Hello,
>>
>> I've a short question about interruptible operations. In the following
>> program is it possible for 'putMVar' to re-throw asynchronous
>> exceptions even when asynchronous exception are blocked/masked?
>>
>> ne
14 matches
Mail list logo
