April 2015 - Glasgow-haskell-users

Discovery of source dependencies without --make
by Lars Hupel 13 Dec '15

13 Dec '15

(cross-posted from [haskell-cafe]) Hi, I've got a problem in our – admittedly complex – build process. We're running an automated grading system for student-submitted homework exercises. The compilation proceeds in stages: 1) Compile a library file, marked as trustworthy 2) Compile student submissions using Safe Haskell, able to access a whitelisted set of packages and the previously compiled library files 3) Compile the test suite 4) Link everything together into an executable The invocation is similar to this: ghc -c -outputdir "$OUT" -XTrustworthy Library.hs ghc -c -outputdir "$OUT" -i"$OUT" -XSafe "$SUBMISSION" ghc -c -outputdir "$OUT" -i"$OUT" Test_Suite.hs ghc -outputdir "$OUT" -i"$OUT" -o "$OUT/runner" The second stage works well under the assumption that there's just one single submitted file. If there's more than one, I need to specify them in topological order wrt their module dependencies. Consider two simple modules: A.hs > module A where > > import B > import Library B.hs > module B where Invoking GHC with "A.hs" "B.hs" will fail: A.hs:3:1: Failed to load interface for ‘B’ My naive attempt at solving that problem was to just insert "--make" into the compiler flags. No luck, because according to [1, §4.7.3], "--make" will only look at source files and will ignore the "Library.hi" file from the previous compilation stage. If I give the path to "Library.hs" as well, GHC insists on recompiling it with changed flags ("-XSafe" instead of "-XTrustworthy"). Reading a bit further, I discovered the '-M' flag, however, not only does it output Makefile-formatted output, it also ignores .hi files. Is there any way to get the dependency discovery of '--make' without the rest? I know I could probably make it work if I made a package out of the first build stage, but I really want to avoid that in order to not increase the build complexity even further. Cheers Lars [1] <https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/separate-com…>

8 15

Increased memory usage with GHC 7.10.1
by Jan Stolarek 04 May '15

04 May '15

Forall hi, I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed installations of GHC and this means I had to rebuild Agda and Idris because the binaries built with GHC 7.8.4 were stored inside deactivated 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due to GHC taking up all of available memory. With Idris the problematic module was Idris.ElabTerm (~2900LOC). The interesting part of the story is that when I do a clean build of Idris GHC consumes all of memory when compiling that module and I have to kill the build. But when I restart the build after killing GHC the module is compiled using a reasonable amount of memory and within reasonable time. With Agda the problematic module is Agda.TypeChecking.Serialise (~2000LOC). The trick with killing the build and restarting it didn't work in this case. I had to compile Agda with GHC 7.8.4 (which works without problems though the mentioned module still requires a lot of memory) and alter my setup so that Agda binary is not stored inside GHC sandbox. I wonder if any of you came across similar issues with GHC 7.10.1? Do we have any performance data that allows to compare memory usage and performance of GHC 7.10.1 with previous stable releases? All of the above happened on 64bit Debian Wheezy with 2GB of RAM. Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

17 35

Looking for retainers of PINNED objects
by Mitsutoshi Aoe 29 Apr '15

29 Apr '15

Hi all, I'm profiling a fairly large program which seems to have a space leak. The heap profiling (-hc) shows that PINNED objects are accumulated over time. In order to check the retainers of the objects, I ran the retainer profiling. Unfortunately it didn't output anything with -hr -hcPINNED. Also, this is just a guess though, the retainer profiling without any filters (I mean just -hr) doesn't seem to include PINNED objects at all. Is there a way to check what retains the PINNED objects? Thanks, Mitsutoshi

1 0

Re: Help wanted: working on the GHC webpage
by Austin Seipp 14 Apr '15

14 Apr '15

Hey Sergey, Sorry for the delay - thanks for all your changes! A few other people have stepped up. But we still need more help of course. :) I'm incorporating your changes into the main Git repository as we speak, and I greatly appreciate it! I'm also incorporating changes from others. Please watch the repo and let me know if you have questions! PS: As for Trac, I agree that at the minimum there should be some kind of syndication or something from the homepage to Trac... the Weekly News *is* user-focused, but the homepage has been severely lacking. I'd appreciate comments here - make an issue about it on the bug tracker! On Fri, Apr 3, 2015 at 9:08 AM, Sergey Bushnyak <sergey.bushnyak(a)sigrlami.eu> wrote: > >> Why would it be easier? What's difficult about publishing on >> https://ghc.haskell.org/trac/ghc/blog? > > I'm actually don't know how it's published on track. From my standpoint as > newcomer it's better to see what's happening from one place, with one > design, have some shared git repo where people contribute in markdown. >> >> Moreover, the GHC weekly news are intimately linked to Trac, as they >> reference Trac-tickets and Git commits, which Trac is able to annotate >> with meta-data (ticket-type, -status, and -title for Ticket references, >> as well as part of the Git commit msg for Git-commit refs). > > > Ok, it was just a suggestion. Maybe it's a bad idea, doesn't know about > annotation. > > Anyway, still can help on updating ghc home page. > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Re: SIMD
by Dominic Steinitz 13 Apr '15

13 Apr '15

Hi Geoff, Thanks for the update. I found this https://ghc.haskell.org/trac/ghc/blog/weekly20141020 > Geoff Mainland stepped up and fixed Data Parallel Haskell to work with a new version of vector and GHC. Austin had disabled DPH a few weeks prior due to its difficulty to upgrade, and divergent source trees. With 7.10, GHC will hopefully ship a more modern vector and dph to boot. From what you say this has been superseded? Also seems that this page https://ghc.haskell.org/trac/ghc/wiki/SIMD <https://ghc.haskell.org/trac/ghc/wiki/SIMD> should be updated and if I knew what it should say I would volunteer to update it. A bit of background on why I am asking these questions: I am working on a Monte Carlo simulation and performance is a key issue. We are using parallelisation to good effect (after some interesting issues with thread affinity https://ghc.haskell.org/trac/ghc/ticket/10229 <https://ghc.haskell.org/trac/ghc/ticket/10229>) but I am trying to understand what other options might be available to speed things up. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com > On 13 Apr 2015, at 13:37, Geoffrey Mainland <mainland(a)cs.drexel.edu> wrote: > > SIMD support was merged to HEAD before the 7.8 release, so any version > of GHC after 7.8 has SIMD support built-in. > > If you want a branch that compiles with DPH, I'm afraid you are out of > luck. DPH no longer builds at all, and I believe Austin actually deleted > the simd branch mentioned on the Wiki. > > Geoff > > On 04/13/2015 02:54 AM, Simon Peyton Jones wrote: >> >> Geoff Mainland is the originator of the SIMD instruction set work. >> Let’s see what he says. >> >> >> >> Simon >> >> >> >> *From:*Glasgow-haskell-users >> [mailto:glasgow-haskell-users-bounces@haskell.org] *On Behalf Of >> *Dominic Steinitz >> *Sent:* 11 April 2015 17:45 >> *To:* GHC users >> *Subject:* SIMD >> >> >> >> What’s the story with this? I tried to follow the instructions >> here: https://ghc.haskell.org/trac/ghc/wiki/SIMD but I get >> >> >> >> ~ $ git clone -b simd http://git.haskell.org/ghc.git >> <http://git.haskell.org/ghc.git <http://git.haskell.org/ghc.git>> >> >> Cloning into 'ghc'... >> >> fatal: Remote branch simd not found in upstream origin >> >> >> >> Dominic Steinitz >> >> dominic(a)steinitz.org <mailto:dominic@steinitz.org> <mailto:dominic@steinitz.org <mailto:dominic@steinitz.org>> >> >> http://idontgetoutmuch.wordpress.com <http://idontgetoutmuch.wordpress.com/>

1 0

SIMD
by Dominic Steinitz 13 Apr '15

13 Apr '15

What’s the story with this? I tried to follow the instructions here: https://ghc.haskell.org/trac/ghc/wiki/SIMD <https://ghc.haskell.org/trac/ghc/wiki/SIMD> but I get > ~ $ git clone -b simd http://git.haskell.org/ghc.git > Cloning into 'ghc'... > fatal: Remote branch simd not found in upstream origin Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

4 3

acrisciu@gmail.com has indicated you're a friend. Accept?
by acrisciu＠gmail.com 09 Apr '15

09 Apr '15

Hi, acrisciu(a)gmail.com wants to follow you. ****** Is acrisciu(a)gmail.com you friend? ****** If Yes please follow the link below: http://invites.infoaxe.net/signup_e.html?fullname=&email=glasgow-haskel… If No please follow the link below: http://invites.infoaxe.net/signup_e.html?fullname=&email=glasgow-haskel… Follow the link below to remove yourself from all such emails http://invites.infoaxe.net/uns_inviter.jsp?email=glasgow-haskell-users@hask…

1 0

Typed splices and type checking
by J. Garrett Morris 08 Apr '15

08 Apr '15

Hello, I've run into another misunderstanding with Template Haskell and typed splices. For example, I was hoping to use typed splices to generate earlier errors from Printf. Here's the world's least handy printf: > class Printf t > where printf :: String -> Q (TExp String) -> Q (TExp t) > > instance Printf String > where printf s t | '%' `notElem` s = [|| $$t ++ s ||] > | otherwise = fail ("Unexpected format %" > ++ [c]) > where (_, _:c:_) = break ('%' ==) s > > instance Printf t => Printf (Char -> t) > where printf s t > | c /= 'c' = fail ("Unexpected format %" ++ [c] ++ > " for character") > | otherwise = [|| \c -> $$(printf s'' > [|| $$t ++ s' ++ [c] ||]) > ||] > where (s', '%':c:s'') = break ('%' ==) s Now, consider these two definitions: > f :: Char -> String > f = $$(printf "foo %c" [||""||]) > h :: Char -> String > h y = $$(printf "foo %c" [||""||]) y I would have expected these to be equivalent, from a type checking perspective. However, while the first types fine, the second generates the error message: > Printing.hs:14:12: > No instance for (Printf t0) arising from a use of `printf' > The type variable `t0' is ambiguous > Note: there are several potential instances: > instance Printf t => Printf (Char -> t) > -- Defined at Printf.hs:20:10 > instance Printf String -- Defined at Printf.hs:9:10 > In the expression: printf "foo %c" [|| "" ||] > In the Template Haskell splice > $$(printf "foo %c" [|| "" ||]) > In the expression: $$(printf "foo %c" [|| "" ||]) Should I have anticipated this? Ought the interaction of typed splices and eta-expansion be problematic? /g -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

3 2

runghc and GhcWithInterpreter
by Jeremy 07 Apr '15

07 Apr '15

I've built GHC with GhcWithInterpreter = NO. runghc is built and installed, but errors out with "not built for interactive use". Is runghc supposed to work with such a build? If not, why is it built at all? -- View this message in context: http://haskell.1045720.n5.nabble.com/runghc-and-GhcWithInterpreter-tp576832… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

3 3

Binary bloat in 7.10
by Jeremy 07 Apr '15

07 Apr '15

Why do the 7.10 libraries take up so much more space than 7.8? For example, using the same build options and strip --strip-unneeded, 7.8 leaves me with 15M libHSCabal-1.18.1.5.a 17M HSCabal-1.18.1.5.o whereas 7.10 balloons to 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

8 23