http://permalink.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/22127 <pre>Hi, Am Freitag, den 25.05.2012, 14:26 -0400 schrieb Mark Conway Wirt: in that case I suggest you run a memory checker, e.g. memtest86, and see if it find some hardware bugs. Or run the program on another machine and see if the problem appears there as well. Greetings, Joachim </pre> Joachim Breitner 2012-05-25T21:45:41 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22126 <pre> No unsafePerformIO's or IOrefs or the like. The code itself is straight-forward (I think). It uses no external libraries -- just Data and System as bundled. One of the problems is that I don't know where in the code the problem may be arising -- the code is about 1200 lines, so it's not really practical to post it! (I'm starting to think that this issue may not be related to Haskell, as the problem arises so inconsistently -- sometimes the code runs, sometimes it bombs out early. I haven't rebooted the computer in a month or so, maybe it's time.) I guess what I'm asking is: what strategies should I be employing for debugging the problem? If the problem is with an array, for example, "error in array index" doesn't give me much to go on if I don't know which array may be the problem. Should I be trying to reproduce the problem in ghci's debugger, for example? Will that give me more context? --Mark </pre> Mark Conway Wirt 2012-05-25T18:26:17 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22125 <pre>Unless you show us the code, any answers will be guesses in the dark. Does your program use unsafePerformIO unsafely perhaps? Or a version of a library that happens to have a known bug? On 25/05/2012, at 14:33, Mark Conway Wirt &lt;MarkCWirt&lt; at &gt;gmail.com&gt; wrote: </pre> Malcolm Wallace 2012-05-25T16:53:52 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/22124 <pre>Hi folks. I have a piece of Haskell code that's been laying around on my computer for about a year, and I recently decided to dust it off. The problem is that it used to work fine, but in the interim (in which I both upgraded OS versions/GHC versions and went from 32 bit to 64 bit) the code stopped working reliably. It tends to work OK for small data sets, but with larger data sets it exhibits one of three bad behaviors: 1) A segfault, 2) An "Error in array index" error, or 3) The following runtime error: internal error: evacuate: strange closure type 5060208 (GHC version 7.0.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted It complies OK, although with optimization turned on it gives me a "has one call pattern, but the limit is 0" error, but my understanding is that this shouldn't really be an issue. I'd like to figure out what this issue is, but while I understand a bit about the language itself, w</pre> Mark Conway Wirt 2012-05-25T13:33:45 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-</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 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.haskell.glasgow.user