- Glasgow-haskell-users

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Brandon Allbery 06 May '15

06 May '15

On Wed, May 6, 2015 at 10:59 AM, Bardur Arantsson <spam(a)scientician.net> wrote: > (I'm not going to be doing any of the work, so this is just armchairing, > but this seems like an 80/20 solution would be warranted.) > Only if you're convinced it will remain 80/20 for the foreseeable future. I do not want to bet on Linux always being gcc (and dislike the One True Platform-ism that line of thought encourages). -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Sven Panne 06 May '15

06 May '15

2015-05-06 16:21 GMT+02:00 Bardur Arantsson <spam(a)scientician.net>: > +1, I'll wager that the vast majority of usages are just for version > range checks. The OpenGL-related packages used macros to generate some binding magic (a "foreign import" plus some helper functions for each API entry), not just range checks. I had serious trouble when Apple switched to clang, so as a quick fix, the macro-expanded (via GCC's CPP) sources had been checked in. :-P Nowadays the binding is generated from the OpenGL XML registry file, so this is not an issue anymore. > If there are packages that require more, they could just keep using the > system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd > want to see real evidence that that's actually worth the > effort/complication. Simply relying on the system CPP doesn't work due to the various differences between GCC's CPP and the one from clang, see e.g. https://github.com/haskell-opengl/OpenGLRaw/issues/18#issuecomment-31428380. Ignoring the problem doesn't make it go away... ;-) Note that we still need CPP to handle the various calling conventions on the different platforms when the FFI is used, so it's not only range checks, see e.g. https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L588.

1 0

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