http://blog.gmane.org/gmane.comp.lang.haskell.glasgow.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22123 <pre> I honestly don't think it will make much difference, because reading the files is not the bottleneck, but we'll happily accept a patch. Adding a new package dependency just for this doesn't seem worthwhile though. Cheers, Simon </pre> Simon Marlow 2012-05-24T11:35:43 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22122 <pre> Last time I tested it, mmap still offered better performance than fread on linux. In addition to improving the deserialization code it would seem like a good idea to mmap the whole file at the outset as well. It seems like readBinMem is the relevant function (readIFace -&gt; readBinIFace -&gt; readBinMem), which occurs here: https://github.com/ghc/ghc/blob/08894f96407635781a233145435a78f144accab0/compiler/utils/Binary.hs#L222 Currently it does one big hGetBuf to read the file. Since the interface files aren't changing dynamically, I think it's safe to just replace this code with an mmap. It's nice to see that we have several wrapped versions of mmap provided on hackage: http://hackage.haskell.org/package/vector-mmap http://hackage.haskell.org/package/bytestring-mmap-0.2.2 http://hackage.haskell.org/package/mmap-0.5.7 Cheers, -Ryan _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users </pre> Ryan Newton 2012-05-24T02:11:04 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22121 <pre>Hi, I am with ghc 7.4.1. For some reason I need a totally static linked compilation to my code. But it failed when linking some packages came with ghc, like unix-2.5.1.0. Trying to rebuild ghc to make all staticly, but failed to find args like this when configuring ghc. What should I do? </pre> Magicloud Magiclouds 2012-05-21T07:47:22 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22119 <pre> As a local workaround you can of course hack your Cabal library sources and reinstall the lib. Until we work out what's going on I'm a bit reluctant to chage the upstream version since that has been tested on so many systems (Linuxes, BSDs, other unixes). Duncan _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users </pre> Duncan Coutts 2012-05-18T21:37:12 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22118 <pre>Hi, right now it seems that my ADPfusion stuff works, apparently no bugs. The runtimes seem to have improved a bit, too. :-) (Could be due to other changes I currently make due to reviewers' suggestions...) If anybody has a binary package for ARM in general, I can test that, too. Unfortunately, I currently don't have the time to build ARM from source, or try fc18 or Ubuntu for ARM. I have a trimslice, running Archlinux for ARM. Gruss, Christian * Ian Lynagh &lt;igloo&lt; at &gt;earth.li&gt; [16.05.2012 12:07]: _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users </pre> Christian Höner zu Siederdissen 2012-05-18T21:07:52 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22117 <pre> The -c flag is to tell it to create the archive (so not to complain if the file is missing). You're saying it accepts "ar rc" but rejects "ar -r -c" ? I was under the impression that posix allowed the '-' on the ar command line flags. e.g. http://www.unix.com/man-page/posix/1posix/ar/ Yes. I'm very surprised it's not working on some version of Red Hat. This has worked on many varieties of linux for many years. You don't have some non-standard ar installed do you? What version of gnu binutils? (ar -V) Duncan _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users </pre> Duncan Coutts 2012-05-18T20:38:38 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22116 <pre>I built GHC 7.2.2 on a LINUX box running RHEL 3. When compiling a package using this GHC it is trying to invoke ar thus: execve("/usr/bin/ar", ["/usr/bin/ar", "-r", "-c", "dist/build/libHSregex-base-0.93."..., "dist/build/Text/Regex/Base.o", "dist/build/Text/Regex/Base/Regex"..., "dist/build/Text/Regex/Base/Conte"..., "dist/build/Text/Regex/Base/Impl."...], [/* 45 vars */]) = 0 My version of ar does not like being invoked as "/usr/bin/ar -r -c lib.a file file file...", it complains that the .a file is missing. I believe it should be "/usr/bin/ar rc lib.a file file file...". This appears to originate in Distribution.Simple.Program.Ar. Can someone tell me what is going on here? Joe Buehler </pre> Joe Buehler 2012-05-18T19:20:07 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22115 <pre> The ARM also finished successfully: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=838546 (with the same ARM patches as for 7.4.1). I also tested building haskell-platform-2012.4 RC1 with ghc-7.4.2 RC1 on x86_64. Jens </pre> Jens Petersen 2012-05-18T09:22:48 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22114 <pre> Thanks! I did a test scratch build on Fedora 18, which should also work on Fedora 17 which will be released soon. http://koji.fedoraproject.org/koji/taskinfo?taskID=4084830 If you want to try the build on Fedora the source and binary rpms can be downloaded from: http://kojipkgs.fedoraproject.org/scratch/petersen/task_4084830/ I also just started a test build on Fedora ARM but that will take a little longer to finish. Jens _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users </pre> Jens Petersen 2012-05-18T01:34:46 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22113 <pre>Mikhail's original question was about loading interface files for entire packages with mmap. As a wild thought experiment, if GHC had a saved-heaps capability, I believe that would avoid the Unique issues with mmap'ing individual data structures that Simon mentioned. How about if each whole-package interface were then a GHC saved heap that, when booted, would become an "interface" server that would communicate with, and be shared by, other GHC build server processes. -Ryan On Fri, Apr 27, 2012 at 4:57 AM, Simon Marlow &lt;marlowsd&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users </pre> Ryan Newton 2012-05-17T14:51:12 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22112 <pre>Hi Etienne, thanks for your reply. That's interesting. But from what I've tried, it seems that it does not work with GHCi. I think it's amazing, that this works with ghc --make. But it does not work with GHCi, I created a ticket for that [1]. Cheers, Simon [1] http://hackage.haskell.org/trac/ghc/ticket/6105 </pre> Simon Hengel 2012-05-17T11:41:27 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22111 <pre>Hello Simon, You can use Template Haskell's addDependentFile to register a dependency on external files. http://hackage.haskell.org/packages/archive/template-haskell/2.7.0.0/doc/html/Language-Haskell-TH-Syntax.html#v:addDependentFile You can also put -fforce-recomp in an OPTIONS_GHC pragma to ask GHC to always recompile the file. {-# OPTIONS_GHC -fforce-recomp #-} Etienne Laurin 2012/5/17 Simon Hengel &lt;sol&lt; at &gt;typeful.net&gt;: _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users </pre> Etienne Laurin 2012-05-17T09:26:02 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22110 <pre>Hi, I'm experimenting with a preprocessor to automatically generate test drivers[1]. The result depends on the existence of other files on the disk. When files are added or removed, the test driver has to be regenerated. Ideally ghc would just always recompile that single file (akin to make's .PHONY), and it should work with ghci's :reload and with cabal. I tried to touch the file within the preprocessor, but this does not work. It seems, that GHC checks the modification time only after preprocessing. Any ideas how to tackle this? Cheers, Simon [1] https://github.com/sol/hspec-discover </pre> Simon Hengel 2012-05-17T08:58:02 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22109 <pre>I am planning on doing this early next week, probably in two phases. As part of the import process, github will generate a *lot* of notification emails. I'm afraid there is nothing I can do to stem the tide, as github does not provide a mechanism to suppress these. If you have a github account, please brace yourself. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users </pre> Bryan O'Sullivan 2012-05-17T03:45:03 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22108 <pre> We are pleased to announce the first release candidate for GHC 7.4.2: http://www.haskell.org/ghc/dist/7.4.2-rc1/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team </pre> Ian Lynagh 2012-05-16T10:05:00 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22107 <pre>We just released version 0.12 of Data.Array.Accelerate, the GPGPU[1] library for Haskell: http://justtesting.org/gpu-accelerated-array-computations-in-haskell This is a beta release. The library is not perfect, but it is definitely usable, and we are looking for early adopters. Manuel [1] Currently only NVIDIA GPUs are supported via NVIDIA's CUDA framework. </pre> Manuel M T Chakravarty 2012-05-14T07:50:40 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22105 <pre>Hello Ian, Wednesday, May 9, 2012, 7:12:03 PM, you wrote: wow! what is the current state, when it planned to be released, how it's implemented (gcc/mingw64?) ? may be this port has its own webpage or some progress list? i would be glad to alpha-test it http://hackage.haskell.org/trac/ghc/ticket/1884 says nothing on it - i'm pretty sure that you will find a lot of testers here too </pre> Bulat Ziganshin 2012-05-09T15:24:34 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22104 <pre> Hi Bulat, On Wed, May 09, 2012 at 06:54:48PM +0400, Bulat Ziganshin wrote: The Industrial Haskell Group has been funding work on the Win64 port. It will be released with GHC 7.6. Thanks Ian </pre> Ian Lynagh 2012-05-09T15:12:03 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22103 <pre>Hello glasgow-haskell-users, the one thing that users of my program asked most is the Win64 support: http://code.google.com/p/freearc/issues/list . we have waited for a several years, but it's still not in GHC, so i want to know at least: why it's not going forward? can we have unregisterized build at least? </pre> Bulat Ziganshin 2012-05-09T14:54:48 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22101 <pre> It is more likely that you are trading extra memory for better performance, rather than triggering the GC at a good time. GC is basically a space/time tradeoff, see: http://stackoverflow.com/questions/3171922/ghcs-rts-options-for-garbage-collection/3172704#3172704 If you think the program has points where residency is very low and it would be good to trigger a GC, I would first confirm the hypothesis by doing a heap profile. GC can be triggered with System.Mem.performGC. Cheers, Simon </pre> Simon Marlow 2012-05-08T10:27:25 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22100 <pre>On Mon, May 7, 2012 at 7:00 AM, Christopher Done &lt;chrisdone&lt; at &gt;googlemail.com&gt; wrote: In non-GCed language people often use an arena allocator in situations like this. However, a semi-space collector (which is what we use) we get that behavior for free. If your request is processed in less time than the minor GC cycle, all your data will be dead by the time the GC run and thus collecting it is free. </pre> Johan Tibell 2012-05-07T17:28:23 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.haskell.glasgow.user