- ghc-devs - Haskell.org

Re: Overlapping and incoherent instances
by Stephen Paul Weber 30 Jul '14

30 Jul '14

Somebody signing messages as Felipe Lessa wrote: >OTOH, the pragma is mostly harmless for older GHC versions, while the >keyword approach needs a preprocessor. Only if *both* the old LANGUAGE pragma and the new pragma were employed, which will generate a deprecation warning for awhile and then eventually (likely) be rejected by newer GHCs, thus requiring a prepropcessor in either case. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

1 0

Re: Overlapping and incoherent instances
by Iavor Diatchki 29 Jul '14

29 Jul '14

Hello, I have no strong feelings about what words we use, but I wanted to point out that while we are thinking of names, we may want to consider 3 (and not just 2). Currently we have: * OVERLAPPING: This instances may overlap existing instances * OVERLAPPABLE: This instance may be overlapped by existing instances * OVERLAPS: This instance is both OVERLAPPING and OVERLAPPABLE Of course, the 3rd one (OVERLAPS) could be replaced by a comma separated list of the first two, but I could not see how to make this work easily with GHC's pragmas. It would not be hard to simply allow 2 pragmas after the `instance` keyword, but both of those seem rather long. Either way, I'll keep an eye on the discussion, and would be happy to change the names if a consesus is reached. -Iavor On Tue, Jul 29, 2014 at 9:57 AM, David Thomas <davidleothomas(a)gmail.com> wrote: > Honestly, I think "OVERLAPS" and "OVERLAPPED" are perfectly clear. > > On Tue, Jul 29, 2014 at 9:52 AM, David Feuer <david.feuer(a)gmail.com> > wrote: > > CAN-OVERLAP and CAN-BE-OVERLAPPED are nice and clear. A little long, > perhaps. > > > > On Tue, Jul 29, 2014 at 12:29 PM, Simon Peyton Jones > > <simonpj(a)microsoft.com> wrote: > >> CAN_OVERLAP and CAN_BE_OVERLAPPED? > >> > >> > >> > >> (instead of OVERLAPPING and OVERLAPPABLE) > >> > >> > >> > >> Or CAN-OVERLAP, CAN-BE-OVERLAPPED > >> > >> > >> > >> That’s ok with me if that’s what you all want! > >> > >> > >> > >> Simon > >> > >> > >> > >> From: Glasgow-haskell-users > >> [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of > Krzysztof > >> Skrzetnicki > >> Sent: 29 July 2014 16:56 > >> To: Brandon Allbery > >> Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries > >> (libraries(a)haskell.org) ghc-devs > >> > >> > >> Subject: Re: Overlapping and incoherent instances > >> > >> > >> > >> How about CAN_OVERLAP? > >> > >> -- > >> Krzysztof > >> > >> 29-07-2014 15:40, "Brandon Allbery" <allbery.b(a)gmail.com> napisał(a): > >> > >> On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel <andreas.abel(a)ifi.lmu.de> > >> wrote: > >> > >> +1. I like Niklas' syntax better. Also OVERLAPPABLE is a horrible word, > >> OVERLAPPING sound less formidable (even though it might be slightly less > >> accurrate). > >> > >> > >> > >> We already get "overlap ok" in instance-related type errors, so > OVERLAP_OK > >> wouldn't be particularly alien even if it doesn't quite fit in with > existing > >> pragmas. > >> > >> > >> > >> -- > >> > >> brandon s allbery kf8nh sine nomine > associates > >> > >> allbery.b(a)gmail.com > ballbery(a)sinenomine.net > >> > >> unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > >> > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries(a)haskell.org > >> http://www.haskell.org/mailman/listinfo/libraries > >> > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries(a)haskell.org > >> http://www.haskell.org/mailman/listinfo/libraries > >> > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

1 0

Re: Overlapping and incoherent instances
by Herbert Valerio Riedel 29 Jul '14

29 Jul '14

On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote: >> instance {-# OVERLAPPABLE #-} Show a => Show [a] where … > > Is the syntax somewhat flexible in where the pragma can be placed? > For example, some might prefer > > {-# OVERLAPPING #-} > instance Show [Char] where … This variant may also be more convenient in cases where you need to CPP-guard that pragma, as it's on a separate line.

6 7

RE: Overlapping and incoherent instances
by Simon Peyton Jones 29 Jul '14

29 Jul '14

CAN_OVERLAP and CAN_BE_OVERLAPPED? (instead of OVERLAPPING and OVERLAPPABLE) Or CAN-OVERLAP, CAN-BE-OVERLAPPED That’s ok with me if that’s what you all want! Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Krzysztof Skrzetnicki Sent: 29 July 2014 16:56 To: Brandon Allbery Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries (libraries(a)haskell.org) ghc-devs Subject: Re: Overlapping and incoherent instances How about CAN_OVERLAP? -- Krzysztof 29-07-2014 15:40, "Brandon Allbery" <allbery.b(a)gmail.com<mailto:allbery.b@gmail.com>> napisał(a): On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel <andreas.abel(a)ifi.lmu.de<mailto:andreas.abel@ifi.lmu.de>> wrote: +1. I like Niklas' syntax better. Also OVERLAPPABLE is a horrible word, OVERLAPPING sound less formidable (even though it might be slightly less accurrate). We already get "overlap ok" in instance-related type errors, so OVERLAP_OK wouldn't be particularly alien even if it doesn't quite fit in with existing pragmas. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com<mailto:allbery.b@gmail.com> ballbery(a)sinenomine.net<mailto:ballbery@sinenomine.net> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ Libraries mailing list Libraries(a)haskell.org<mailto:Libraries@haskell.org> http://www.haskell.org/mailman/listinfo/libraries

1 0

Re: Haskell Platform 2014.2.0.0 Release Candidate 2
by George Colpitts 29 Jul '14

29 Jul '14

Weird that I didn't have this problem with rc1 On Tuesday, July 29, 2014, Brandon Allbery <allbery.b(a)gmail.com> wrote: > On Tue, Jul 29, 2014 at 7:45 AM, George Colpitts < > george.colpitts(a)gmail.com > <javascript:_e(%7B%7D,'cvml','george.colpitts(a)gmail.com');>> wrote: > >> Installation worked fine. However I encountered a problem that looks like >> a regression, although it may be a problem with new versions of the package >> I am trying to install: > > > It's not an H-P problem; Apple's started using their BLOCKS C extension in > system headers, and gtk2hsc2hs doesn't understand it. (And possibly is not > using cpp properly when processing headers.) You'll need to take this up > with the gtk2hs folks. > > #ifdef __BLOCKS__ > int scandir_b(const char *, struct dirent ***, > int (^)(const struct dirent *), int (^)(const struct dirent **, > const struct > dirent **)) __DARWIN_INODE64(scandir_b) > __OSX_AVAILABLE_STARTING(__MAC_10_6, __ > IPHONE_3_2); > #endif /* __BLOCKS__ */ > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b(a)gmail.com <javascript:_e(%7B%7D,'cvml','allbery.b(a)gmail.com');> > ballbery(a)sinenomine.net > <javascript:_e(%7B%7D,'cvml','ballbery(a)sinenomine.net');> > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net >

1 0

Haskell Platform 2014.2.0.0 Release Candidate 2
by Mark Lentczner 29 Jul '14

29 Jul '14

The long anticipated Haskell Platform 2014.2 release, including GHC 7.8.3, and numerous updated packages, is almost here! We have created "Release Candidate 2" installers for OS X and Windows, and believe, barring show stopper issues, creepers exploding, or other bizarre phenomenon, these will likely be blessed as the final in a few days time. If you would like to be an early adopter, please try 'em out... - source tarball: haskell-platform-2014.2.0.0-RC2.tar.gz <http://www.ozonehouse.com/mark/platform/haskell-platform-2014.2.0.0-RC2.tar…> - source repo: haskell/haskell-platform at 2014.2.0.0-RC2 <https://github.com/haskell/haskell-platform/tree/2014.2.0.0-RC2> - windows 32bit: hskellPlatform-2014.2.0.0-i386-RC2-setup.exe <http://www.ozonehouse.com/mark/platform/hskellPlatform-2014.2.0.0-i386-RC2-…> - windows 64bit:hskellPlatform-2014.2.0.0-x86_64-RC2-setup.exe <http://www.ozonehouse.com/mark/platform/hskellPlatform-2014.2.0.0-x86_64-RC…> - os x 64bit: Haskell Platform 2014.2.0.0 64bit RC2.signed.pkg <http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202014.2.0.0%206…> - travis-ci build: haskell/haskell-platform <https://travis-ci.org/haskell/haskell-platform> *Notes for RC2, since RC1:* *Windows* *Extra thanks to Randy Polen for burning the midnight-oil to get ths out* - removed unneeded python (et al) files from the GHC bindist for 64-bit Windows (referenced in GHC ticket #9014 <https://ghc.haskell.org/trac/ghc/ticket/9014>) - added HTML "view source" pages for the GHC packages that was missing from the GHC bindist for both 32- and 64-bit Windows. *Mac OS X* *If you installed RC1, you can remove first with the command *sudo uninstall-hs only 7.8.3 --remove *Run it without *--remove* to see what it will do before running, it if you like. In theory you can just install this one right on top of RC1.... but hasn't been tested.* - file layout on the Mac... improved slightly (again). In particular, executables are now installed directly in $prefix/bin dirs, rather than within the package dir - fix the bug with haddock master index not being updated correctly - works on 10.6! (and 10.7, 10.8, and 10.9) with gcc or clang based Xcodes - works on 10.10!!! (Yosemite, developer preview 4 release) *Source tarball* - missing sources in hptool now present - platform.sh improved somewhat (in particular, handles host cabal being pre-sandbox) *Timetable* - These can "soak" amongst the intreped on these lists for a few hours. - On Monday evening (PST) I'll announce to haskell-cafe and reddit - End of next week (from my vacation, I'll point out), we'll declare success and ship. — Mark *SHA-256 sums:* 62f39246ad95dd2aed6ece5138f6297f945d2b450f215d074820294310e0c48a Haskell Platform 2014.2.0.0 64bit RC2.signed.pkg 7c7d3585e89e1407461efea29dcaa9628c3be3c47d93a13b5a4978046375e4fd haskell-platform-2014.2.0.0-RC2.tar.gz 6eedd76aafb266d9a09baff80cd2973498ab59195c771f7cd64425d40be29c49 hskellPlatform-2014.2.0.0-i386-RC2-setup.exe b22115ed84d1f7e747d7f0b47e32e1489e4a24613d69c91df4ae32052f88b130 hskellPlatform-2014.2.0.0-x86_64-RC2-setup.exe

2 3

.gitignore of tests
by Dr. ERDI Gergo 29 Jul '14

29 Jul '14

Hi, Is there a good reason we have a single monolithic .gitignore file in testuiste/ instead of one per directory? It just feels so unnecessarily burdensome to maintain it compared to just putting four lines in a new .gitignore file... Bye, Gergo

3 2

redundant rts/StgPrimFloat decodeDouble?
by Herbert Valerio Riedel 29 Jul '14

29 Jul '14

Hello *, While working on integer-gmp2 I noticed that there seems to be redundant code between rts/StgPrimFloat.c and integer-gmp. Specifically, there's a void __decodeDouble_2Int (I_ *man_sign, W_ *man_high, W_ *man_low, I_ *exp, StgDouble dbl); C implementation which does some low-level bit-fiddling on the IEEE representation instead of just using the more portable standard frexp() function, like I'm doing in integer-gmp2, e.g.: HsInt integer_gmp_decode_double (const HsDouble x, HsInt64 *const mantisse) { if (x) { int exp = 0; *mantisse = (HsInt64)scalbn(frexp(x, &exp), DBL_MANT_DIG); return exp-DBL_MANT_DIG; } else { *mantisse = 0; return 0; } } A similiar operation exists in integer-gmp/cbits/float.c So here's my questions: 1) Is there any reason/value in doing low-level IEEE bit-fiddling instead of just delegating to the C99/POSIX compliant frexp(3) operations? 2) Specifically, `decodeDouble_2Int` seems to be dead-code. I'd like to instead move the HsInt integer_gmp_decode_double (const HsDouble x, HsInt64 *const mantisse); which I currently import as #if WORD_SIZE_IN_BITS == 32 foreign import prim "integer_gmp_cmm_decode_double" cmm_decode_double :: Double# -> (# Int64#, Int# #) #elif WORD_SIZE_IN_BITS == 64 foreign import prim "integer_gmp_cmm_decode_double" cmm_decode_double :: Double# -> (# Int#, Int# #) #endif based on the size of `Int#` into rts/PrimOps.cmm & rts/StgPrimFloat.c as that may allow me to avoid any C-- in integer-gmp2 altogether (as I only need to go via C-- to return an unboxed pair) Cheers, hvr

1 0

Re: Dashboard
by Alexander Pakhomov 29 Jul '14

29 Jul '14

Hi Joachim, I think automatic regression notification at least to the author is a good idea. Probably I can do it in a nearest time. Unfortunately, right now I fail to get your code up. Also I believe it is a good style to check commits for regressions before pushing them. But maybe GHC community is less performance oriented. 25.07.2014, 01:41, "Joachim Breitner" <mail(a)joachim-breitner.de>: > Hi Alexander, > > Am Donnerstag, den 24.07.2014, 19:22 +0400 schrieb Alexander Pakhomov: >> I've been informed you created http://ghcspeed-nomeata.rhcloud.com. I >> believe it is necessary for any serious perfomance work. >> Do you need some help? What have you done and what problems are >> unsolved? > thanks for your interest. > > One way to help is to monitor the page for regressions, and notify > whoever caused it. I’m doing that from time to time, relying on the > Latest Results summary. > > Then I don’t find the codespeed software to be perfect. The thread at > https://groups.google.com/forum/#!topic/codespeed/yY5-kPrcG94 discusses > some of the things I don’t like. So if you feel like hacking Python, > just hack away on it and I’ll happily accept pull requests at > https://github.com/nomeata/codespeed (branch ghc), or directly upstream. > > Eventually, the whole setup should be moved to some dedicated and > official hardware, but I’m not in a hurry with this. It’s been running > for just a week or two, and I’d like to observe how its behaving. > > Greetings, > Joachim > > PS: I prefer to discuss these things on the appropriate mailing list and > in public, if only for the archive. If you agree, simply reply to the > ghc-dev list (quoting in full) and I’ll read your reply there. > > -- > Joachim “nomeata” Breitner > mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ > Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F > Debian Developer: nomeata(a)debian.org

2 1

Status updates
by Austin Seipp 29 Jul '14

29 Jul '14

Hello *, Here are some notes on what I've done in the past week, and what I plan on doing going forward: - First and foremost, I made a bunch of improvements to Phabricator/Trac. Now, most noticeably: 1) Phabricator has a field for GHC trac tickets. You can specify this when you run 'arc diff', and it will appear on the Differential Revision. By default if you run 'arc diff', this field appears at the bottom, below 'Subscribers:'. 2) Phabricator now supports Trac markup syntax - if you say '#7602' in a trac ticket, this turns into a hyperlink with the text "Trac #7602" and links to the ticket. 3) The IRC bot on #ghc can now look up Trac tickets for you (this is mostly only relevant to those of us there) - The final piece of this whole story is actually getting Phabricator to *comment* on Trac. This is almost done, but due to the fact I'm writing PHP (and thus have absolutely no idea what I'm doing) the code still seems slightly broken somewhere since it's one of the larger parts of the Phabricator integration. Hopefully I can finish this soon. I will say though - thank you Herbert for helping me figure out the Trac XML/RPC plugin, and getting it working for me! - Another Phabricator related thing: I've begun working on a better Harbormaster build backend - it will actually report failures, support concurrent builds, and give you stderr in log results! Yay! - I took some time to further clean up the Git wiki page following last week, but only made minor progress here. - The patch queue is, in fact, being drained as we speak! I have a whole bunch of incoming patches from contributors running under ./validate as I write this, including some cleanup commits too (to detab/whitespace things). Not all of them, but a good chunk I could fit in that were low-impact and correct. - I have not finished AMP. :( This is quickly going to be my #1 priority before fixing any bugs because at this point, it's holding up other `base` improvements (Edward K, I'm sure, is getting a bit fiddly about this getting done :) This week: - Before fixing *any* new bugs myself, I'm going to finish AMP, because it's a blocker for others including Edward, Simon, and future base improvements. I'm thinking I may just do this before any more Phabricator improvements. - I will hopefully finish the Trac and Phabricator setup soon. at the very least I want to get the comment updates working. I'll probably continue with the build system shenannigans sometime after. - The wiki pages and Git stuff still need more cleanup to streamline them. This will be happening when I get a chance (Herbert already improved some things I touched last week - Thanks!) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1