- Glasgow-haskell-users

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Malcolm Wallace 08 May '15

08 May '15

Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: > That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). > > On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace <malcolm.wallace(a)me.com> wrote: > I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. > > Regards, > Malcolm > > On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: > > > On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: > > > > [...] > > > >> Regarding licensing issues: perhaps we should simply ask Malcolm > >> Wallace if he would consider changing the license for the sake of GHC? > >> Or perhaps he could grant a custom-tailored license to the GHC > >> project? After all, the project page [1] says: " If that's a problem > >> for you, contact me to make other arrangements." > > > > Fyi, Neil talked to him[1]: > > > > | I talked to Malcolm. His contention is that it doesn't actually change > > | the license of the ghc package. As such, it's just a single extra > > | license to add to a directory full of licenses, which is no big deal. > > > > > > [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_pro… > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

1 0

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by wren romano 08 May '15

08 May '15

On Wed, May 6, 2015 at 9:05 AM, Alan & Kim Zimmerman <alan.zimm(a)gmail.com> wrote: > Perhaps it makes sense to scan hackage to find all the different CPP idioms > that are actually used in Haskell code, if it is a small/well-defined set it > may be worth writing a simple custom preprocessor. Conditional imports are far and away the most commonly used idiom. Second most common, I'd say, is specifying GHC-specific vs compiler-generic implementations of top-level functions (e.g., using GHC.Exts.build or not). For both of these it's sufficient to have the #if construction plus everything needed for the conditional expressions. However, while the #if construction covers the vast majority of use cases, it doesn't cover all of them. Macros are also important. For example, a number of low-level libraries will use macros for things like having assertions which are either compiled as runtime checks, or as nothing, depending on a Cabal flag. Of course, there are plenty of other places where we want to use macros in low-level code, either to force inlining, or to have conditional compilation of (non-top-level) expressions that show up over and over. That these idioms aren't more common is just because there aren't more people working on such low-level code. In theory TH should be able to handle this stuff, but TH is a verbose sledgehammer for these sorts of problems, and using TH means restricting yourself to being GHC-only. -- Live well, ~wren

1 0

Re: RFC: "Native -XCPP" Proposal
by Herbert Valerio Riedel 07 May '15

07 May '15

On 2015-05-06 at 18:53:08 +0200, Howard B. Golden wrote: > At the risk of antagonizing some (most? all?) of you, how about... > > -XCPP stands for the native CPP > -XGNUCPP stands for GNU's GCC CPP > -XClangCPP stands for Clang's CPP > -XCPPHS stands for CPPHS Assuming this was a serious suggestion, the benefit is that you could clearly mark what CPP you want to develop against, but OTOH, we'd lose backward compat w/ Haskell compilers only knowing about the old -XCPP but not the other new variants of the language-pragma. Moreover, there can now be packages that require clang-cpp, while others require gcc-cpp, and I don't think it can be assumed that both are available on every GHC installation. So it could cause packages to fail compiling simply because the respective CPP-flavor is missing. On the bright side, this would maybe give us the opportunity to coin the new term "CPP Hell" =) Cheers, hvr

1 0

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

06 May '15

On Wed, May 6, 2015 at 11:27 AM, Kosyrev Serge <_deepfire(a)feelingofgreen.ru> wrote: > Why *shouldn't* TH fill that role? What can be done about it? For one, it's difficult to make it available in cross compilers (granted, work is being done on this) and not available on some platforms (ARM has been a problem, dunno if it currently is). For another, I don't think you can currently control things like imports or LANGUAGE pragmas --- and as TH is currently constructed it's not clear that you could do so, or that you could do so in a way that is sane for users. This is not to say that I like cpp --- I'd like it a lot more if it weren't actually using a C preprocessor that is not actually under our control or guaranteed to be compatible with Haskell --- but it does provide a "meta" in a different dimension than TH does. -- 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 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