Static linking and linker search paths
All,
Conor's problems on OSX with libiconv reminds me of something I've been
thinking about for a little while.
So the problem is that the semantics of static linking does not at all
match what we really want. We can easily accidentally "interpose" a
wrong library in place of the one we wanted.
In the iconv case people have hit recently we've got this situation:
libHSbase-4.2.0.0.a
contains references to _iconv_open, _iconv, _iconv_close
${system}/libiconv.a
${macports}/libiconv.a
When the code for libHSbase was built, it was against the header files
for the standard system version of iconv on OSX. Thus it is intended
that we link against the system version of iconv.
No suppose by default that the system is set up such that only the
system iconv is found by default. So I am assuming there is no
LD_LIBRARY_PATH or similar set. Then when we link something then we
correctly resolve the references in base to the system iconv lib.
When we call gcc to link we're doing something like:
-L${ghclibdir} -lHSbase-4.2.0.0.a -liconv
Now suppose we build some FFI package (libHSfoo-1.0.a) that provides a
binding to a C lib installed via macports (libfoo.a). When we link a
program that depends indirectly on this FFI package then the gcc linker
line is like:
-L${ghclibdir} -L/opt/local/lib
-lHSfoo-1.0.a -lfoo -lHSbase-4.2.0.0.a -liconv
and now it all breaks.
We're asking the linker to look in /opt/local/lib first for *all the
remaining libraries* and that includes iconv, so we pick up the wrong
iconv. Our intention was just to look for -lfoo using /opt/local/lib,
but we cannot express that to the linker.
The problem is that our notion of library dependencies is hierarchical
but for the system linker it is linear. We know that package foo-1.0
needs the C library libfoo.a and that it should be found by looking
in /opt/local/lib. But we end up asking the linker to look there first
for all other libs too, including for the -liconv needed by the base
package. The registration for the base package never
mentioned /opt/local/lib of course.
What we'd really like to say is something like:
link HSfoo-1.0.a
push search path /opt/local/lib
link foo
pop search path
If we think we know enough about the behaviour of the system linker and
its search path then we could do just:
-L${ghclibdir}
-lHSfoo-1.0.a /opt/local/lib/libfoo.a -lHSbase-4.2.0.0.a -liconv
that is, specify the .a file exactly by fully resolved path and not add
anything to the linker search path. (Actually we'd do it for the
libHS*.a ones too since we know precisely where they live)
The possible danger is that how we search for the library and how the
system linker searches for it might not match exactly and we could end
up sowing confusion.
Worth thinking about anyway.
Note that some of this is different for shared libs.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re: ANN: Happstack 0.4.1
On Mon, Dec 21, 2009 at 6:31 AM, wrote:
> Hello,
>
> That sort of missing symbol error at link time is often (but not always) a
> sign that some libraries got recompiled but not others. So there are
> references to the old symbol names hanging around.
>
> I would try to ghc-pkg unregister syb-with-class and everything that depends
> on it, and then try cabal install happstack again.
>
I'm pretty well stumped at this point. I've cleared off everything and
gone up to GHC 6.12 HEAD, and a 'cabal install happstack-data' gives
me the same symbol not defined error in Happstack.Data.Xml.Base.
But here's the spooky part, if I run it by hand like so:
ghc --make src/Happstack/Data/Xml/Base.hs
src/Happstack/Data/Default.hs src/Happstack/Data/
DeriveAll.hs src/Happstack/Data/Normalize.hs src/Happstack/Data/Migrate.hs
after resolving issues due to CPP not being run, everything runs to
completion, no errors. Also, the list of things we're pulling in
during the template-haskell execution is much smaller (see bellow).
Has anyone seen this, where template-haskell behaves different when
run from cabal-install (or Setup.hs) than from ghc --make (or ghci)?
>
2 of 5] Compiling Happstack.Data.Migrate (
src/Happstack/Data/Migrate.hs, src/Happstack/Data/Migrate.o )
[3 of 5] Compiling Happstack.Data.Default (
src/Happstack/Data/Default.hs, src/Happstack/Data/Default.o )
[4 of 5] Compiling Happstack.Data.DeriveAll (
src/Happstack/Data/DeriveAll.hs, src/Happstack/Data/DeriveAll.o )
[5 of 5] Compiling Happstack.Data.Xml.Base (
src/Happstack/Data/Xml/Base.hs, src/Happstack/Data/Xml/Base.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading package array-0.3.0.0 ... linking ... done.
Loading package bytestring-0.9.1.5 ... linking ... done.
Loading package containers-0.3.0.0 ... linking ... done.
Loading package pretty-1.0.1.1 ... linking ... done.
Loading package syb-0.1.0.2 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package syb-with-class-0.6.1 ... linking ... done.
mkUsageInfo: internal name? Element{tc a4av}
<
That was the successful build, using ghc --make. The error for te
failing build is quoted bellow.
Antoine
>
>
>
> On Sun 12/20/2009 2:06 AM , Antoine Latter aslat...@gmail.com sent:
>
> 2009/12/19 Jeremy Shaw :
>> Happstack 0.4.1 STABLE is now available.
>
> At some point I was able to get happstack to build on GHC 6.12, but now I
> can't.
>
> I'm getting errors in happstack-data, specifically it looks like
> errors when I'm running TemplateHaskell during compile-time:
>
>>
> [ 7 of 16] Compiling Happstack.Data.Xml.Base (
> src/Happstack/Data/Xml/Base.hs, dist/build/Happstack/Data/Xml/Base.o )
> Loading package ghc-prim ... linking ... done.
> Loading package integer-gmp ... linking ... done.
> Loading package base ... linking ... done.
> Loading package array-0.3.0.0 ... linking ... done.
> Loading package bytestring-0.9.1.5 ... linking ... done.
> Loading package containers-0.3.0.0 ... linking ... done.
> Loading package pretty-1.0.1.1 ... linking ... done.
> Loading package template-haskell ... linking ... done.
> Loading package syb-with-class-0.6.1 ... linking ... done.
> Loading package HUnit-1.2.2.1 ... linking ... done.
> Loading package syb-0.1.0.2 ... linking ... done.
> Loading package base-3.0.3.2 ... linking ... done.
> Loading package old-locale-1.0.0.2 ... linking ... done.
> Loading package time-1.1.4 ... linking ... done.
> Loading package random-1.0.0.2 ... linking ... done.
> Loading package QuickCheck-1.2.0.0 ... linking ... done.
> Loading package extensible-exceptions-0.1.1.1 ... linking ... done.
> Loading package mtl-1.1.0.2 ... linking ... done.
> Loading package old-time-1.0.0.3 ... linking ... done.
> Loading package parsec-2.1.0.1 ... linking ... done.
> Loading package hsemail-1.3 ... linking ... done.
> Loading package network-2.2.1.5 ... linking ... done.
> Loading package SMTPClient-1.0.1 ... linking ... done.
> Loading package filepath-1.1.0.3 ... linking ... done.
> Loading package unix-2.4.0.0 ... linking ... done.
> Loading package directory-1.0.1.0 ... linking ... done.
> Loading package process-1.0.1.2 ... linking ... done.
> Loading package hslogger-1.0.7 ... linking ... done.
> Loading package deepseq-1.1.0.0 ... linking ... done.
> Loading package parallel-2.2.0.1 ... linking ... done.
> Loading package strict-concurrency-0.2.2 ... linking ... done.
> Loading package unix-compat-0.1.2.1 ... linking ... done.
> Loading package happstack-util-0.4.1 ... linking ... done.
> Loading package binary-0.5.0.2 ... linking ... done.
> Loading package haskell98 ... linking ... done.
> Loading package HaXml-1.13.3 ... linking ... done.
> Loading package ffi-1.0 ... linking ... done.
> ghc:
> unknown symbol
> `_sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_
Re: Weird warnings when using ViewPatterns
On Mon, Dec 21, 2009 at 9:03 PM, Robert Greayer wrote: > There's been some improvement at least in 6.12.1, see: > http://hackage.haskell.org/trac/ghc/ticket/2395 Thanks for pointing me to the ticket! I'm emerging ghc-6.12.1 right now to try it out (I'm on Gentoo Linux). regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Weird warnings when using ViewPatterns
On Mon, Dec 21, 2009 at 6:03 AM, Bas van Dijk wrote:
> Hello,
>
> In my usb-safe[1] library I make extensive use of the ViewPatterns[2]
> language extension. However I get strange warnings when using them.
>
> See for example the following function:
>
> resetDevice ∷ (pr `ParentOf` cr, MonadIO cr)
>⇒ RegionalDeviceHandle pr → cr ()
> resetDevice (internalHandle → DeviceHandle { internalDevHndl
> , configAlreadySetMVar
> }) = ...
>
> where:
>
> type RegionalDeviceHandle r = RegionalHandle USB.Device r
>
> internalHandle ∷ RegionalHandle resource r → Handle resource
>
> and: 'Handle' is an associated data type with the following definition:
>
> data Handle USB.Device = DeviceHandle
>{ internalDevHndl ∷ USB.DeviceHandle
>, configAlreadySetMVar ∷ MVar Bool
>}
>
> Note that I also use the NamedFieldPuns[3] language extension.
>
> When compiling the module I get lots of warnings like this:
>
> System/USB/Safe.hs:372:0:
>Warning: Pattern match(es) are overlapped
> In the definition of `resetDevice':
> resetDevice ((internalHandle -> (DeviceHandle
> {internalDevHndl,
>
> configAlreadySetMVar})))
> =
> ...
>
> System/USB/Safe.hs:372:0:
>Warning: Pattern match(es) are non-exhaustive
> In the definition of `resetDevice': Patterns not matched:
>
> I don't understand which patterns are overlapped or which patterns are
> not matched. Is this a GHC bug? Note that I'm using ghc-6.10.4 so it's
> possible that it's fixed in 6.12.1.
>
> regards,
>
> Bas
>
> [1] usb-safe:
> http://hackage.haskell.org/package/usb-safe-0.4
> or darcs get
> http://code.haskell.org/~basvandijk/code/usb-safe
>
> [2]
> http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#view-patterns
>
> [3]
> http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#record-puns
>
There's been some improvement at least in 6.12.1, see:
http://hackage.haskell.org/trac/ghc/ticket/2395
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x64 linux, x86 program and libgmp shared library
On Mon, Dec 21, 2009 at 2:49 PM, Robert Greayer wrote: > > On Mon, Dec 21, 2009 at 2:32 PM, Bulat Ziganshin < > bulat.zigans...@gmail.com> wrote: > >> Hello glasgow-haskell-users, >> >> i compile my program for linux using ghc 6.6.1 (32-bit) >> >> user of my program asks: "any plans of making a static build for >> linux? that one does not work under x86-64 due to dependencies, >> missing libgmp which it seems is not available under 64bit. i could be >> wrong tho." >> >> how this may be resolved? should libgmp be available in x64 linux, or >> i should change compile options? >> >> > Using cabal, this gets me a completely static executable: > > runhaskell Setup.hs configure --user --ghc-options="-static -optl-static > -optl-pthread" > > Which implies to me that passing '-static -optl-static -optl-pthread' would > do the trick. > (With the caveat: this works with 6.10... not sure at all about 6.6). ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x64 linux, x86 program and libgmp shared library
On Mon, Dec 21, 2009 at 2:32 PM, Bulat Ziganshin wrote: > Hello glasgow-haskell-users, > > i compile my program for linux using ghc 6.6.1 (32-bit) > > user of my program asks: "any plans of making a static build for > linux? that one does not work under x86-64 due to dependencies, > missing libgmp which it seems is not available under 64bit. i could be > wrong tho." > > how this may be resolved? should libgmp be available in x64 linux, or > i should change compile options? > > Using cabal, this gets me a completely static executable: runhaskell Setup.hs configure --user --ghc-options="-static -optl-static -optl-pthread" Which implies to me that passing '-static -optl-static -optl-pthread' would do the trick. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
x64 linux, x86 program and libgmp shared library
Hello glasgow-haskell-users, i compile my program for linux using ghc 6.6.1 (32-bit) user of my program asks: "any plans of making a static build for linux? that one does not work under x86-64 due to dependencies, missing libgmp which it seems is not available under 64bit. i could be wrong tho." how this may be resolved? should libgmp be available in x64 linux, or i should change compile options? -- Best regards, Bulat mailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Haskell @ USENIX HotPar?
Hey Haskellers, Looks like a great opportunity to talk about parallel Haskell to other communities: Second USENIX Workshop on Hot Topics in Parallelism http://gpgpu.org/2009/12/20/cfp-hotpar-2010 Following the tremendous success of HotPar ‘09, the Second USENIX Workshop on Hot Topics in Parallelism (HotPar ‘10) will once again bring together researchers and practitioners doing innovative work in the area of parallel computing. Anyone planning on submitting a position paper? It would be a real shame not to show our faces. -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: parList implementation question
Thanks Simon. Parallel 2.2.0.1 was straight forward. I just replaced rnf with rdeepseq and my original use of parMap worked like a charm giving twice the performance for my dual-core system as I original expected and now find. Thanks, - Marcus Marcus D. Gabriel wrote: > Thank you Simon, I will obtain parallel 2.2.0.1 and work with it. > Actually, the reason I asked my question was because I did not > think forceParList should yield better performance than parList > (unless it was becasue of the foldl?). > > I read the release notes for 6.12.1 about the work done on the ghc > parallel framework and did just a little bit more experimenting. > You might find this of interesting. > > ghc 6.10.4 with parallel 1.1.0.1 (as reported before): > Serial algorithm:1.00 unit of time > Parallel algorithm with parList: 0.81 units of time > Parallel algorithm with forceParList:0.58 units of time > > ghc 6.12.1 with parallel 1.1.0.1: > Serial algorithm:1.00 unit of time > Parallel algorithm with parList: 0.58 units of time* > Parallel algorithm with forceParList:0.58 units of time* > > Interesting. Well, from my perspective, 6.12.1 is certainly an > improvement here. > > Cheers, > - Marcus > > Simon Marlow wrote: > >> On 18/12/2009 18:31, Marcus D. Gabriel wrote: >> >>> Hello, >>> >>> In Control.Parallel.Strategies, parList is defined as >>> >>> parList strat [] = () >>> parList strat (x:xs) = strat x `par` (parList strat xs) >>> >>> with >>> >>> parMap strat f xs = map f xs `using` parList strat. >>> >>> I have recently found that if I define >>> >>> forceParMap strat f xs = map f xs `using` forceParList strat >>> >>> where >>> >>> forceParList strat = foldl (\done -> (done>||) . strat) () >>> >>> then to date, forceParList via forceParMap gives faster results >>> than parList via parMap. For example, in one experiment, parMap >>> with parList run at 0.81 the time of the serial solution whereas >>> forceParMap with forceParList run at 0.58 the time of the serial >>> solution. This is to say, forceParList completed in 0.72 the >>> time of parList. So, >>> >>> 1. Why is forceParList faster than parList? >>> 2. Is this generic to the ghc runtime model or a particularity >>> of the ghc implementation? >>> >> I'm not sure. Your forceParList looks equivalent to parList, unless >> I'm misreading it. >> >> I recommend trying out the new parallel package, here: >> >> http://hackage.haskell.org/package/parallel >> >> which has a new implementation of Strategies. The version of parList >> you quoted above has a space leak problem which may be affecting your >> results. >> >> Cheers, >> Simon >> ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: parList implementation question
Thank you Simon, I will obtain parallel 2.2.0.1 and work with it. Actually, the reason I asked my question was because I did not think forceParList should yield better performance than parList (unless it was becasue of the foldl?). I read the release notes for 6.12.1 about the work done on the ghc parallel framework and did just a little bit more experimenting. You might find this of interesting. ghc 6.10.4 with parallel 1.1.0.1 (as reported before): Serial algorithm:1.00 unit of time Parallel algorithm with parList: 0.81 units of time Parallel algorithm with forceParList:0.58 units of time ghc 6.12.1 with parallel 1.1.0.1: Serial algorithm:1.00 unit of time Parallel algorithm with parList: 0.58 units of time* Parallel algorithm with forceParList:0.58 units of time* Interesting. Well, from my perspective, 6.12.1 is certainly an improvement here. Cheers, - Marcus Simon Marlow wrote: > > On 18/12/2009 18:31, Marcus D. Gabriel wrote: >> Hello, >> >> In Control.Parallel.Strategies, parList is defined as >> >> parList strat [] = () >> parList strat (x:xs) = strat x `par` (parList strat xs) >> >> with >> >> parMap strat f xs = map f xs `using` parList strat. >> >> I have recently found that if I define >> >> forceParMap strat f xs = map f xs `using` forceParList strat >> >> where >> >> forceParList strat = foldl (\done -> (done>||) . strat) () >> >> then to date, forceParList via forceParMap gives faster results >> than parList via parMap. For example, in one experiment, parMap >> with parList run at 0.81 the time of the serial solution whereas >> forceParMap with forceParList run at 0.58 the time of the serial >> solution. This is to say, forceParList completed in 0.72 the >> time of parList. So, >> >> 1. Why is forceParList faster than parList? >> 2. Is this generic to the ghc runtime model or a particularity >> of the ghc implementation? > > I'm not sure. Your forceParList looks equivalent to parList, unless > I'm misreading it. > > I recommend trying out the new parallel package, here: > > http://hackage.haskell.org/package/parallel > > which has a new implementation of Strategies. The version of parList > you quoted above has a space leak problem which may be affecting your > results. > > Cheers, > Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cabal-install-0.8 final testing
On Mon, 2009-12-21 at 12:44 +, Simon Marlow wrote: > > The current Cabal code takes a slightly different approach. It says at > > the end "oh this exe isn't buildable, so its deps do not contribute to > > the deps of the package". > > > > The problem is what it was doing before that. It sees the dependency on > > HUnit and checks that it can be satisfied. It's only at the end that it > > ends up discarding it. So if it was not actually available then it fails > > earlier. > > I was following the description up until this paragraph (too many "it"s > and "that"s, I'm not sure what they all refer to). Don't worry about it > if it's hard to explain, but if you have time to elaborate a bit I'd be > interested. Sorry, I'll try again: There are essentially two stages to the resolution. The main one and a simple post-processing. The post-processing notes that some components are not buildable and so ignores the deps from those components. But that's not good enough because the first stage would already have failed if those dependencies of the non-buildable component were not available. So it's no good just doing it as a post-processing stage. We must properly express the fact that the dependencies are optional and related to whether or not the component is buildable. The solver currently does not know that "buildable" is special in any way. Indeed that it should be special is rather irksome. We had this field before we added conditionals. We would not have added "buildable" like this way after adding conditionals. Instead we should have added things with comprehensible semantics like "fail". Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cabal-install-0.8 final testing
On 20/12/2009 01:46, Duncan Coutts wrote: On Fri, 2009-12-18 at 19:44 -0800, Dave Bayer wrote: Hi Duncan, Installation was easy (I typed "cabal-install HTTP zlib cabal-install" ;-). Thanks for testing it. I've uploaded it to hackage. Overall, seems to work fine. I couldn't build darcs, but I couldn't do that by hand either; I used their binary installer. I don't think they build yet under GHC 6.12.1. One oddity, I tried to use cabal install to install mmap, and it failed because the HUnit package was missing. I then installed HUnit without incident, went back and installed mmap without incident. No idea why this didn't work in one pass, but I have "sandbox" systems if you'd like me to see if I can reliably reproduce this. Mm. This is a worse bug than I thought. It's not trivial to fix. I'll have to think about it. The problem is mmap uses: Executable mmaptest Main-is: tests/mmaptest.hs if flag(mmaptest) Buildable: True else Buildable: False Build-depends: base<5, bytestring, HUnit, directory Now the question is what does this mean exactly. The previous version of Cabal said essentially "well the executable needs HUnit thus the package needs HUnit". This despite the fact that we're not going to actually built this test executable! The current Cabal code takes a slightly different approach. It says at the end "oh this exe isn't buildable, so its deps do not contribute to the deps of the package". The problem is what it was doing before that. It sees the dependency on HUnit and checks that it can be satisfied. It's only at the end that it ends up discarding it. So if it was not actually available then it fails earlier. I was following the description up until this paragraph (too many "it"s and "that"s, I'm not sure what they all refer to). Don't worry about it if it's hard to explain, but if you have time to elaborate a bit I'd be interested. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Where did the GHC API go?
On 21/12/2009 00:18, Tom Tobin wrote: On Sun, Dec 20, 2009 at 6:17 PM, Tom Tobin wrote: On Sun, Dec 20, 2009 at 4:47 PM, Jason Dusek wrote: Maybe I missed an email about this... http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/index.html The link is down. The link from the GHC Documentation page points here, which works for me: http://www.haskell.org/ghc/docs/latest/html/libraries/index.html Sorry, read that too quickly — you're asking about the API. That is indeed a dead link for me. Ian, is this something to do with the recent redirects that were added? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How does forkIO and par interact?
On 20/12/2009 14:12, Marcus D. Gabriel wrote: Thanks Bulat. What you wrote makes perfect sense to me. However under 6.10.4 this is what I observed. Pseudo code: c = l++r `demanding` l>||r then th<- forkIO (c `seq` return ()) Run it the first time to completion and watch two cores turn at better than 95% utilisation, quite pleasing. Run it the second time and half way through the calculation use killThread th and watch one core become idle and one core turn at better than 95%. Wait until the first core finishes and then use c and watch the rest of the calculation finish. Now, what you wrote and this experiment tells me that l was sparked and then given a free thread in which to calculate. r was still in the original thread of execution of the forkIO and therefore was affected by the killThread th whereas l was not. Does this read correct to you? If so, then I understand! That's exactly right, yes. In principle we could have spark threads be garbage collected if their results aren't shared by the main program. In practice that's hard to determine, since sharing is not an all-or-nothing question. There's a fruitful line of research here, though, since it affects how well you can express speculation. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: parList implementation question
On 18/12/2009 18:31, Marcus D. Gabriel wrote: Hello, In Control.Parallel.Strategies, parList is defined as parList strat [] = () parList strat (x:xs) = strat x `par` (parList strat xs) with parMap strat f xs = map f xs `using` parList strat. I have recently found that if I define forceParMap strat f xs = map f xs `using` forceParList strat where forceParList strat = foldl (\done -> (done>||) . strat) () then to date, forceParList via forceParMap gives faster results than parList via parMap. For example, in one experiment, parMap with parList run at 0.81 the time of the serial solution whereas forceParMap with forceParList run at 0.58 the time of the serial solution. This is to say, forceParList completed in 0.72 the time of parList. So, 1. Why is forceParList faster than parList? 2. Is this generic to the ghc runtime model or a particularity of the ghc implementation? I'm not sure. Your forceParList looks equivalent to parList, unless I'm misreading it. I recommend trying out the new parallel package, here: http://hackage.haskell.org/package/parallel which has a new implementation of Strategies. The version of parList you quoted above has a space leak problem which may be affecting your results. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: openFd under -threaded gets interrupted
On 18/12/2009 17:40, Mitar wrote:
Hi!
I have written about this to Haskell cafe and they advised me to write it here.
I have a problem that I cannot open /dev/rfcomm0 device if I compile
my program with -threaded option. Like:
fd<- openFd "/dev/rfcomm0" ReadWrite Nothing OpenFileFlags { append =
False, noctty = True, exclusive = False, nonBlock = True, trunc =
False }
If I compile my program with -threaded option I always get such error:
interrupted (Interrupted system call)
But without -threaded it works flawlessly. I am using Linux 2.6.30
amd64, GHC 6.10.4. It was the same with 6.8. And I have tested it also
on 6.12.1.
It's a bug - openFd should be checking for EINTR. I'll fix it.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cabal-install-0.8 final testing
Duncan Coutts googlemail.com> writes: > if flag(test) > Buildable: True > Build-depends: base<5, bytestring, HUnit, directory > else > Buildable: False > Is this solution good for the time being? If so, I'll change it to make peace and happiness prevail among cabal users. Side question: mmaptest is meant to be devel/testing thing only that is not build during normal usage. Is there a better way to achieve such purpose? -- Gracjan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Weird warnings when using ViewPatterns
Hello,
In my usb-safe[1] library I make extensive use of the ViewPatterns[2]
language extension. However I get strange warnings when using them.
See for example the following function:
resetDevice ∷ (pr `ParentOf` cr, MonadIO cr)
⇒ RegionalDeviceHandle pr → cr ()
resetDevice (internalHandle → DeviceHandle { internalDevHndl
, configAlreadySetMVar
}) = ...
where:
type RegionalDeviceHandle r = RegionalHandle USB.Device r
internalHandle ∷ RegionalHandle resource r → Handle resource
and: 'Handle' is an associated data type with the following definition:
data Handle USB.Device = DeviceHandle
{ internalDevHndl ∷ USB.DeviceHandle
, configAlreadySetMVar ∷ MVar Bool
}
Note that I also use the NamedFieldPuns[3] language extension.
When compiling the module I get lots of warnings like this:
System/USB/Safe.hs:372:0:
Warning: Pattern match(es) are overlapped
In the definition of `resetDevice':
resetDevice ((internalHandle -> (DeviceHandle {internalDevHndl,
configAlreadySetMVar})))
=
...
System/USB/Safe.hs:372:0:
Warning: Pattern match(es) are non-exhaustive
In the definition of `resetDevice': Patterns not matched:
I don't understand which patterns are overlapped or which patterns are
not matched. Is this a GHC bug? Note that I'm using ghc-6.10.4 so it's
possible that it's fixed in 6.12.1.
regards,
Bas
[1] usb-safe:
http://hackage.haskell.org/package/usb-safe-0.4
or darcs get http://code.haskell.org/~basvandijk/code/usb-safe
[2]
http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#view-patterns
[3]
http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#record-puns
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
