Re: What does interruptibility mean exactly?
On Mon, Jun 14, 2010 at 11:20 PM, Don Stewart d...@galois.com 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? newEmptyMVar = \mv - block $ putMVar mv x The documentation in Control.Exception about interruptible operations[1] confused me: Some operations are interruptible, which means that they can receive asynchronous exceptions even in the scope of a block. Any function which may itself block is defined as interruptible... I think the best definition of interruptible is in this paper: www.haskell.org/~simonmar/papers/async.pdf Section 5.3 Thanks for the link Don! Next time I will re-read the paper before asking ;-) The definition makes it clear indeed: Any operation which may need to wait indefinitely for a resource (e.g., takeMVar) may receive asynchronous exceptions even within an enclosing block, BUT ONLY WHILE THE RESOURCE IS UNAVAILABLE So I guess I can update my threads package to use MVars again. Nice! because they were a bit faster in an informal benchmark I performed some time ago. A later quote from 5.3 emphasizes the definition even more: ...an interruptible operation cannot be interrupted if the resource it is attempting to acquire is always available... The following darcs patch makes the definition of interruptibility in the documentation in Control.Exception a bit clearer in this regard: http://bifunctor.homelinux.net/~bas/doc-interruptibility.dpatch Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How easy is it to build a GHC cross compiler targeting Windows?
[ 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 cygwin, but using MinGW). TakeoffGW is built using SUSE's mingw32 cross compiling system, so I figured the first step would be to add GHC to that if possible. I figure we will need to two new GHC packages * mingw32-cross-ghc (GHC cross compiler for building Haskell packages) * mingw32-ghc (Windows GHC compiler to install on users machines) I am a bit concerned that making a cross compiler to build the Haskell packages might not be practical. So before we spend to much time on this I thought I should ask how hard it is to build a cross compiler like this? Is it just a matter of setting the correct configure flags? We will have the SUSE's mingw32 available (including binutils and gcc cross compiler), but will this be enough? First of all, I think TakeoffGW is a great idea, I've been hoping that something like this would emerge. In principle cross-compiling GHC ought to be possible, but actually making it work could be difficult. It's hard to predict without trying. Much of our build system is structured to make cross-compiling work: we have separate build/host/target platforms and generally try to check the correct one, but we almost never actually cross-compile GHC, only when porting GHC to a new platform and there it's a fairly involved manual process. If I had to guess, I'd say you'll probably run into quite a few things that need fixing in the build system to make this work. Probably nothing fatal, but lots of fiddling around. It would be worth doing, and we'll help as much as we can along the way if you want to try. If we can build the cross compiler will we be able to use it to build the Windows ghc with it? If there are parts that can't be done we may need to resort to using Wine or a Windows machine. I wanted to CC the GHC developers mailing list, but haskell.org is down. Could you please CC the appropriate list in your reply? Done! Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Segmentation fault in non-dynamically linked binaries?
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 version of Setup.hs when cabal builds it (and which would fail inexplicably until I did further investigation.) Example: link ~/t » cat hi.hs main :: IO () main = putStrLn hi link ~/t » ghc -dynamic hi.hs link ~/t » file ./a.out ./a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped link ~/t » ldd ./a.out linux-vdso.so.1 = (0x7fffbadff000) libHShaskell98-1.0.1.1-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/haskell98-1.0.1.1/libHShaskell98-1.0.1.1-ghc6.12.3.so (0x7fab3a4c4000) libHSrandom-1.0.0.2-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/random-1.0.0.2/libHSrandom-1.0.0.2-ghc6.12.3.so (0x7fab3a2af000) libHStime-1.1.4-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/time-1.1.4/libHStime-1.1.4-ghc6.12.3.so (0x7fab39fad000) libHSprocess-1.0.1.3-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/process-1.0.1.3/libHSprocess-1.0.1.3-ghc6.12.3.so (0x7fab39d93000) libHSdirectory-1.0.1.1-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/directory-1.0.1.1/libHSdirectory-1.0.1.1-ghc6.12.3.so (0x7fab39b77000) libHSunix-2.4.0.2-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/unix-2.4.0.2/libHSunix-2.4.0.2-ghc6.12.3.so (0x7fab398c6000) librt.so.1 = /lib/librt.so.1 (0x7fab396a2000) libutil.so.1 = /lib/libutil.so.1 (0x7fab3949f000) libdl.so.2 = /lib/libdl.so.2 (0x7fab3929b000) libHSold-time-1.0.0.5-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/old-time-1.0.0.5/libHSold-time-1.0.0.5-ghc6.12.3.so (0x7fab3903c000) libHSold-locale-1.0.0.2-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/old-locale-1.0.0.2/libHSold-locale-1.0.0.2-ghc6.12.3.so (0x7fab38e28000) libHSfilepath-1.1.0.4-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/filepath-1.1.0.4/libHSfilepath-1.1.0.4-ghc6.12.3.so (0x7fab38c07000) libHSarray-0.3.0.1-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/array-0.3.0.1/libHSarray-0.3.0.1-ghc6.12.3.so (0x7fab38992000) libHSbase-4.2.0.2-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/base-4.2.0.2/libHSbase-4.2.0.2-ghc6.12.3.so (0x7fab381f2000) libHSinteger-gmp-0.2.0.1-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/integer-gmp-0.2.0.1/libHSinteger-gmp-0.2.0.1-ghc6.12.3.so (0x7fab37fe1000) libgmp.so.3 = /usr/lib/libgmp.so.3 (0x7fab37da1000) libHSghc-prim-0.2.0.0-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/ghc-prim-0.2.0.0/libHSghc-prim-0.2.0.0-ghc6.12.3.so (0x7fab37b1c000) libHSrts-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/libHSrts-ghc6.12.3.so (0x7fab378ba000) libm.so.6 = /lib/libm.so.6 (0x7fab37637000) libHSffi-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/libHSffi-ghc6.12.3.so (0x7fab3742a000) libc.so.6 = /lib/libc.so.6 (0x7fab370c9000) libpthread.so.0 = /lib/libpthread.so.0 (0x7fab36eac000) /lib64/ld-linux-x86-64.so.2 (0x7fab3a6cb000) link ~/t » ./a.out hi link ~/t » rm ./a.out *.hi *.o link ~/t » ghc hi.hs link ~/t » file ./a.out ./a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped link ~/t » ldd ./a.out linux-vdso.so.1 = (0x7fffaafff000) librt.so.1 = /lib/librt.so.1 (0x7fdf83d77000) libutil.so.1 = /lib/libutil.so.1 (0x7fdf83b74000) libdl.so.2 = /lib/libdl.so.2 (0x7fdf8396f000) libgmp.so.3 = /usr/lib/libgmp.so.3 (0x7fdf8373) libm.so.6 = /lib/libm.so.6 (0x7fdf834ae000) libc.so.6 = /lib/libc.so.6 (0x7fdf8314c000) libpthread.so.0 = /lib/libpthread.so.0 (0x7fdf82f3) /lib64/ld-linux-x86-64.so.2 (0x7fdf83f9c000) link ~/t » ./a.out [1]7850 segmentation fault ./a.out link ~/t » gdb7.0 ./a.out 139 ↵ GNU gdb (GDB) 7.0 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or laterhttp://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/a/t/a.out...done. (gdb) r Starting program: /home/a/t/a.out [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x0067b3c0 in strlen@@GLIBC_2.2.5 () (gdb) bt #0 0x0067b3c0 in strlen@@GLIBC_2.2.5 () #1 0x00432dd7 in setFullProgArgv () #2
Re: ANNOUNCE: GHC version 6.12.3
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 got many link failures of the kind: Compile failed (status 256) errors were: Undefiniertes erstmals referenziert Symbol in Datei inflate /opt/csw/lib/libbfd.a(compress.o) inflateEnd /opt/csw/lib/libbfd.a(compress.o) inflateInit_/opt/csw/lib/libbfd.a(compress.o) inflateReset/opt/csw/lib/libbfd.a(compress.o) ld: Schwerer Fehler: Symbolreferenzierungsfehler. Keine Ausgabe in tcrun001 geschrieben *** unexpected failure for tcrun001(threaded1) See: http://hackage.haskell.org/trac/ghc/ticket/3756 the conclusion was we need to add something to the configure script. If you could help us out that would be great. Cheers, Simon Cheers Christian Ian Lynagh schrieb: == The (Interactive) Glasgow Haskell Compiler -- version 6.12.3 == The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.12.2, so we recommend upgrading. Release notes are here: http://darcs.haskell.org/download/docs/6.12.3/html/users_guide/release-6-12-3.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://darcs.haskell.org/download/download_ghc_6_12_3.html 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: What does interruptibility mean exactly?
On 15/06/2010 09:00, Bas van Dijk wrote: On Mon, Jun 14, 2010 at 11:20 PM, Don Stewartd...@galois.com 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? newEmptyMVar= \mv - block $ putMVar mv x The documentation in Control.Exception about interruptible operations[1] confused me: Some operations are interruptible, which means that they can receive asynchronous exceptions even in the scope of a block. Any function which may itself block is defined as interruptible... I think the best definition of interruptible is in this paper: www.haskell.org/~simonmar/papers/async.pdf Section 5.3 Thanks for the link Don! Next time I will re-read the paper before asking ;-) The definition makes it clear indeed: Any operation which may need to wait indefinitely for a resource (e.g., takeMVar) may receive asynchronous exceptions even within an enclosing block, BUT ONLY WHILE THE RESOURCE IS UNAVAILABLE So I guess I can update my threads package to use MVars again. Nice! because they were a bit faster in an informal benchmark I performed some time ago. This is currently true for takeMVar/putMVar but it is no longer true for throwTo (in 6.14+). I'll update the docs to make that clear. The reason is that throwTo now works by message passing when the target is on another CPU, and we consider a thread that is waiting for a response to a message to be blocked - even if the throwTo can in fact proceed immediately because the target is interruptible. Cheers, Simon A later quote from 5.3 emphasizes the definition even more: ...an interruptible operation cannot be interrupted if the resource it is attempting to acquire is always available... The following darcs patch makes the definition of interruptibility in the documentation in Control.Exception a bit clearer in this regard: http://bifunctor.homelinux.net/~bas/doc-interruptibility.dpatch Regards, Bas ___ 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: Unexpected NoImplicitPrelude behaviour in GHCi (bug?)
On Jun 11, 2010, at 5:10 AM, Brandon S. Allbery KF8NH wrote:
snip
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
expression printer (which, being in IO, is doing something like (print it
putStr \n). Since the command line option has global effect, the Prelude's
() isn't defined for ghci's guts either.
Your explanation would make perfect sense to me; pragma's in the module effect
only the module. This is, however, nog GHCi's behaviour. If I have a module
that's only this:
{-# LANGUAGE NoImplicitPrelude #-}
module Foo where
and I open this in GHCi, I get the following session:
Ok, modules loaded: Foo.
*Foo 42
42
*Foo 42.0
42.0
*Foo :t 42
42 :: (GHC.Num.Num t) = t
*Foo 40 + 2
interactive:1:3: Not in scope: `+'
*Foo :t fromRational
interactive:1:0: Not in scope: `fromRational'
*Foo
This means that there is *some* definition of fromInteger, fromRational and
(), but it's not accessible for me at the prompt. Types and typeclasses seem
to be imported fully qualified. I would either expect GHCi to start complaining
when I type 42, or to not complain about any of these above commands.
Any thoughts?
Regards,
Philip___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unexpected NoImplicitPrelude behaviour in GHCi (bug?)
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 for an FP intro course. One thing students tend to have difficulty with in the initial labs are the error messages including type classes, or any kind of more general type than they expected. I am trying to work around this, by supplying a Number type for the first lab and gradually increasing the complexity over the next few labs. To let all error messages be in terms of my type, I use the NoImplicitPrelude option in a LANGUAGE pragma. Wasn't that the rationale for developing / using Helium? http://www.cs.uu.nl/wiki/bin/view/Helium/Features This is true. Having said that, I find GHC's error messages to be reasonably good and I find GHC as a compiler to be better. Also, I don't believe very much in their philosophy. I don't think teaching aides that tell a student precisely what to do are necessarily better. The only downside (from a teaching point of view) of GHC's error messages, is that you have to know and understand so much of Haskell to read them. I want GHC's error messages, but just restricted to non-typeclass issues. I'm hoping this will stimulate students to actually read the error messages. Once they're confident that they're actually really informative, I don't mind when they get a little messy ;) There are some oddities in the handling of options/pragmas wrt GHCi, as discussed in this ticket: http://hackage.haskell.org/trac/ghc/ticket/3217 Thanks for the pointer. At the moment, and as far as options/pragmas are concerned, the GHCi prompt can be seen as an importer of the modules loaded. So it needs its own option settings, even if you load *Main and the Main.hs source code has language pragmas. This can be confusing (eg, *Main otherwise means treat expressions at GHCi prompt as if it was in the Main module). I agree; I would like *Main to mean it's as if you're now inside the Main module. The consensus in that ticket was that the separation of commandline options, GHCi session options, and source pragmas could be clearer, and there was a concrete proposal for a pragmatic implementation plan to improve consistency (just waiting for an implementer;-). Mmm... time :( Regards, Philip___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: laziness in `length'
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 require building the full thunk for non-strict
Nums? Even if they are not strict, an addition requires both parts to be
evaluated. This means the thunk will have to be pre-built, doesn't it?
With kind regards,
Denys
On Monday 14 June 2010 16:25:06, Serge D. Mechveliani wrote:
Dear people and GHC team,
I have a naive question about the compiler and library of ghc-6.12.3.
Consider the program
import List (genericLength)
main = putStr $ shows (genericLength [1 .. n]) \n
where
n = -- 10^6, 10^7, 10^8 ...
(1) When it is compiled under -O, it runs in a small constant space
in n and in a time approximately proportional to n.
(2) When it is compiled without -O, it takes at the run-time the
stack proportional to n, and it takes enormousely large time
for n = 10^7.
(3) In the interpreter mode ghci, `genericLength [1 .. n]'
takes as much resource as (2).
Are the points (2) and (3) natural for an Haskell implementation?
Independently on whether lng is inlined or not, its lazy evaluation
is, probably, like this:
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 $ list 4 n)
...
And this takes a small constant space.
Unfortunately, it would be
lng [1 .. n]
~ 1 + (lng [2 .. n])
~ 1 + (1 + (lng [3 .. n]))
~ 1 + (1 + (1 + (lng [4 .. n])))
~
and that builds a thunk of size O(n).
The thing is, genericLength is written so that for lazy number types, the
construction of the result can begin before the entire list has been
traversed. This means however, that for strict number types, like Int or
Integer, it is woefully inefficient.
In the code above, the result type of generic length (and the type of list
elements) is defaulted to Integer.
When you compile with optimisations, a rewrite-rule fires:
-- | The 'genericLength' function is an overloaded version of 'length'. In
-- particular, instead of returning an 'Int', it returns any type which is
-- an instance of 'Num'. It is, however, less efficient than 'length'.
genericLength :: (Num i) = [b] - i
genericLength []= 0
genericLength (_:l) = 1 + genericLength l
{-# RULES
genericLengthInt genericLength = (strictGenericLength :: [a] -
Int);
genericLengthInteger genericLength = (strictGenericLength :: [a] -
Integer);
#-}
strictGenericLength :: (Num i) = [b] - i
strictGenericLength l = gl l 0
where
gl [] a = a
gl (_:xs) a = let a' = a + 1 in a' `seq` gl xs a'
which gives a reasonabley efficient constant space calculation.
Without optimisations and in ghci, you get the generic code, which is slow
and thakes O(n) space.
Thank you in advance for your explanation,
-
Serge Mechveliani
mech...@botik.ru
___
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: laziness in `length'
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 not strict? The ones I am aware about are all strict. There are several implementations of lazy (to different degrees) Peano numbers on hackage. The point is that it's possible to have lazy Num types, and the decision was apparently to write genericLength so that lazy Num types may profit from it. Arguably, one should have lazyGenericLength for lazy number types and strictGenericLength for strict number types (Integer, Int64, Word, Word64, ...). On the other hand, fromIntegral . length works fine in practice (calling length on a list exceeding the Int range would be doubtful on 32-bit systems and plain madness on 64-bit systems). Also, why doesn't it require building the full thunk for non-strict Nums? Even if they are not strict, an addition requires both parts to be evaluated. Not necessarily for lazy numbers. This means the thunk will have to be pre-built, doesn't it? For illustration, the very simple-minded lazy Peano numbers: data Peano = Zero | Succ Peano deriving (Show, Eq) instance Ord Peano where compare Zero Zero = EQ compare Zero _= LT compare _Zero = GT compare (Succ m) (Succ n) = compare m n min Zero _ = Zero min _ Zero = Zero min (Succ m) (Succ n) = Succ (min m n) max Zero n = n max m Zero = m max (Succ m) (Succ n) = Succ (max m n) instance Num Peano where Zero + n = n (Succ m) + n = Succ (m + n) -- omitted other methods due to laziness (mine, not Haskell's) fromInteger n | n 0 = error Peano.fromInteger: negative argument | n == 0 = Zero | otherwise = Succ (fromInteger (n-1)) one, two, three, four :: Peano one = Succ Zero two = Succ one three = Succ two four = Succ three min two (genericLength [1 .. ]) ~ min (Succ one) (genericLength [1 .. ]) ~ min (Succ one) (1 + (genericLength [2 .. ])) ~ min (Succ one) ((Succ Zero) + (genericLength [2 .. ])) ~ min (Succ one) (Succ (Zero + (genericLength [2 .. ]))) ~ Succ (min one (Zero + (genericLength [2 .. ]))) ~ Succ (min (Succ Zero) (Zero + (genericLength [2 .. ]))) ~ Succ (min (Succ Zero) (genericLength [2 .. ])) ~ Succ (min (Succ Zero) (1 + (genericLength [3 .. ]))) ~ Succ (min (Succ Zero) ((Succ Zero) + (genericLength [3 ..]))) ~ Succ (min (Succ Zero) (Succ (Zero + (genericLength [3 .. ] ~ Succ (Succ (min Zero (Zero + (genericLength [3 .. ] ~ Succ (Succ Zero) With kind regards, Denys ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: What does interruptibility mean exactly?
On Tue, Jun 15, 2010 at 12:41 PM, Simon Marlow marlo...@gmail.com wrote: On 15/06/2010 09:00, Bas van Dijk wrote: On Mon, Jun 14, 2010 at 11:20 PM, Don Stewartd...@galois.com 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? newEmptyMVar= \mv - block $ putMVar mv x The documentation in Control.Exception about interruptible operations[1] confused me: Some operations are interruptible, which means that they can receive asynchronous exceptions even in the scope of a block. Any function which may itself block is defined as interruptible... I think the best definition of interruptible is in this paper: www.haskell.org/~simonmar/papers/async.pdf Section 5.3 Thanks for the link Don! Next time I will re-read the paper before asking ;-) The definition makes it clear indeed: Any operation which may need to wait indefinitely for a resource (e.g., takeMVar) may receive asynchronous exceptions even within an enclosing block, BUT ONLY WHILE THE RESOURCE IS UNAVAILABLE So I guess I can update my threads package to use MVars again. Nice! because they were a bit faster in an informal benchmark I performed some time ago. This is currently true for takeMVar/putMVar but it is no longer true for throwTo (in 6.14+). I'll update the docs to make that clear. The reason is that throwTo now works by message passing when the target is on another CPU, and we consider a thread that is waiting for a response to a message to be blocked - even if the throwTo can in fact proceed immediately because the target is interruptible. Thanks for the heads-up. BTW I just released threads-0.3 which, among other things, uses MVars again for waiting for the termination of a thread: http://hackage.haskell.org/package/threads-0.3 Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: laziness in `length'
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 $ list 4 n)
Actually matters are more complicated. In the highlighted steps you
implicitly used associativity of (+). Of course, Haskell can not do
this. Also 'lng' and 'genericLength' *are not tail recursive*. This
explains stack overflow. If you compute length with 'foldl'
(tail-recursively) and without -O flag, than you will see excessive
heap usage. Also, GHC's 'length' and 'foldl'' are tail recursive and
eagerly computes length/accumulator, so they are effective without -O
flag. See for explanation
http://www.haskell.org/haskellwiki/Stack_overflow
--
Best regards,
Roman Beslik.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
heap profiling
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_to_profile_a_Haskell_program or maybe make make a heap profiling page linked from that. Firstly a few miscellaneous questions: When running '-hc -hblag,drag' it works for a little while and then stops. The app is still hung, but cpu has gone to 0%. The disk is also idle, so I don't think it's swapping. According to -S, all garbage collection has stopped too. It's apparently due to something about this particular profile, since reducing the amount of data it handles just results in a sooner hang. This same combination works with other profiles, so apparently something the code is doing is locking up. Has anyone else seen this? Any tips on how to troubleshoot where it's getting stuck, doing what? If it sounds like a ghc bug I can try to trim down the size and submit a ticket. GHC 6.12.1 on OSX. The image link from http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/profiling.html is broken, which makes it a little harder to understand the documentation. -s stats say GC time is 46%, productivity is 32%. That's pretty bad, right? And where is the remaining 22% going? The ghc manual says lag is time between creation and first use and drag is time between last use and last reference is dropped. I think I understand drag: it means you haven't touched the data for a while before it goes out of scope or its retainer goes out of scope. So for instance: stuff = do st - get x1 st x2 Does this mean that 'st' will be dragging through 'x2' as it would in an imperative language? I gather the usual haskell use is when combined with laziness: 'Map.insertWith (+) a 42' will keep the old value of a around until you look a up and force it, since the (+) won't be applied until then. Same with foldl. Are there some other classic examples of drag? Searching for haskell dragging problem doesn't yield much to do with memory use. Lag I'm not so sure about. How is something created before it's used? And... what's INHERENT_USE? And what about VOID? How can an object be created but never used? What triggered its creation? So, the main question: I have a program that runs some computation in a monad stack before extracting the final result, a list, and passing it on. When run under the heap profiler, there's a huge spike in that phase, which I think should be mostly bogus usage, since the final output is so relatively small. When I run under -hb I see big bands for LAG and DRAG. According to -hd the top 3 users are: mtl-1.1.0.2:Control.Monad.Writer.Lazy.sat_sltc (,) D:Monad This is kind of puzzling to me... first of all I've never seen an explanation for sat_* closure descriptors, and second of all, why does it not show up in the .prof file at all? I switched to Writer.Strict and the drag disappeared, which helped, but the lag is still there, and the top -hd is now mtl-1.1.0.2:Control.Monad.Writer.Strict.sat_soa1 State stg_ap_2_upd_info (the top -hy is *, which I gather means don't know). And what's stg_ap_2_upd_info? The top item accounts for 70% of the memory usage. One obvious candidate for the lag is Writer's data (DList Log.Msg) is collecting and only being forced at the end of the computation, but there is no logging in this section and in any case should never be 30M of it! -hc is not helpful since every monadic operation is charged a little bit, -hr is similarly unhelpful (top retainer is MANY... hah). So what exactly is this sat_*? Where is the memory going? I guess it doesn't have an SCC since it doesn't show up in the .prof output. Is there some place I can manually put an SCC? I was able to fix the drag just by guessing at a strict writer, but the lag is still around. Is there another spot in Writer's = that could be accumulating? What's *in* that giant mountain of lag? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: What does interruptibility mean exactly?
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 acquisition operation is in a blocked state and can be interrupted. I'm not sure that this is the exact phrasing, but it does convey the meaning a bit more clearly. Also missing is that interruptable implies restartable. Sent from my Verizon Wireless BlackBerry -Original Message- From: Bas van Dijk v.dijk@gmail.com Date: Tue, 15 Jun 2010 20:36:44 To: Simon Marlowmarlo...@gmail.com Cc: glasgow-haskell-users@haskell.org; Don Stewartd...@galois.com Subject: Re: What does interruptibility mean exactly? On Tue, Jun 15, 2010 at 12:41 PM, Simon Marlow marlo...@gmail.com wrote: On 15/06/2010 09:00, Bas van Dijk wrote: On Mon, Jun 14, 2010 at 11:20 PM, Don Stewartd...@galois.com 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? newEmptyMVar= \mv - block $ putMVar mv x The documentation in Control.Exception about interruptible operations[1] confused me: Some operations are interruptible, which means that they can receive asynchronous exceptions even in the scope of a block. Any function which may itself block is defined as interruptible... I think the best definition of interruptible is in this paper: www.haskell.org/~simonmar/papers/async.pdf Section 5.3 Thanks for the link Don! Next time I will re-read the paper before asking ;-) The definition makes it clear indeed: Any operation which may need to wait indefinitely for a resource (e.g., takeMVar) may receive asynchronous exceptions even within an enclosing block, BUT ONLY WHILE THE RESOURCE IS UNAVAILABLE So I guess I can update my threads package to use MVars again. Nice! because they were a bit faster in an informal benchmark I performed some time ago. This is currently true for takeMVar/putMVar but it is no longer true for throwTo (in 6.14+). I'll update the docs to make that clear. The reason is that throwTo now works by message passing when the target is on another CPU, and we consider a thread that is waiting for a response to a message to be blocked - even if the throwTo can in fact proceed immediately because the target is interruptible. Thanks for the heads-up. BTW I just released threads-0.3 which, among other things, uses MVars again for waiting for the termination of a thread: http://hackage.haskell.org/package/threads-0.3 Regards, Bas ___ 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
