.gitignore of tests
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Dashboard
Dear Alexander, Am Dienstag, den 29.07.2014, 03:27 +0400 schrieb Alexander Pakhomov: 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. we don’t even enforce that the code compiles and the test suite passes before pushing, but we are doing ok. Having things checked and reported after the fact is already a good step forward. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: .gitignore of tests
Hello! On 2014-07-29 at 08:25:15 +0200, Dr. ERDI Gergo wrote: 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... That's a good question I've been wondering about as well. I recently merged a few single .gitignore files I found in testsuite/ sub-folders into the main testsuite/.gitignore file it was rather inconsistent to have most stuff listed in the monolithic testsuite/.gitignore file and just a few deliberate .gitignores in a few sub-folders: http://git.haskell.org/ghc.git/commitdiff/767b9ddf7d2ea2bb99d49372c79be129fc2058ce The other issue is tooling. Some Git front-ends such as http://magit.github.io/ don't even recognize non-top-level .gitignore files (yet), and certainly don't offer to create one if they don't find it in the current sub-folder (instead magit just adds it to the top-level gitignore file) Also, I'm not sure if having .gitignore files sprinkled all over the source-tree instead of having just a few .gitignore files would be so much better, as in order to compute the effective .gitignore, you have to consider the union of all existing .gitignore files up to the top-level folder (while not crossing Git repo boundaries). However, we *can* switch to a scheme where we use many little per-folder .gitignore files, but everyone would have to agree to follow that new scheme, or we'll end up with a mess of confusing possibly overlapping .gitignore files. Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
redundant rts/StgPrimFloat decodeDouble?
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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Overlapping and incoherent instances
Friends
One of GHC's more widely-used features is overlapping (and sometimes
incoherent) instances. The user-manual documentation is
herehttp://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-overlap.
The use of overlapping/incoherent instances is controlled by LANGUAGE pragmas:
OverlappingInstances and IncoherentInstances respectively.
However the overlap/incoherent-ness is a property of the *instance declaration*
itself, and has been for a long time. Using LANGUAGE OverlappingInstances
simply sets the I am an overlapping instance flag for every instance
declaration in that module.
This is a Big Hammer. It give no clue about *which* particular instances the
programmer is expecting to be overlapped, nor which are doing the overlapping.
It brutally applies to every instance in the module. Moreover, when looking
at an instance declaration, there is no nearby clue that it might be
overlapped. The clue might be in the command line that compiles that module!
Iavor has recently implemented per-instance-declaration pragmas, so you can say
instance {-# OVERLAPPABLE #-} Show a = Show [a] where ...
instance {-# OVERLAPPING #-} Show [Char] where ...
This is much more precise (it affects only those specific instances) and it is
much clearer (you see it when you see the instance declaration).
This new feature will be in GHC 7.10 and I'm sure you will be happy about that.
But I propose also to deprecate the LANGUAGE pragmas OverlappingInstances and
IncoherentInstances, as way to encourage everyone to use the new feature
instead of the old big hammer. The old LANGUAGE pragmas will continue to work,
of course, for at least another complete release cycle. We could make that two
cycles if it was helpful.
However, if you want deprecation-free libraries, it will entail a wave of
library updates.
This email is just to warn you, and to let you yell if you think this is a bad
idea. It would actually not be difficult to retain the old LANGUAGE pragmas
indefinitely - it just seems wrong not to actively push authors in the right
direction.
These deprecations of course popped up in the test suite, so I've been
replacing them with per-instance pragmas there too. Interestingly in some
cases, when looking for which instances needed the pragmas, I found...none. So
OverlappingInstances was entirely unnecessary. Maybe library authors will find
that too!
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Overlapping and incoherent instances
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.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Overlapping and incoherent instances
On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel h...@gnu.org wrote:
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.
Agreed, and if we remove the old pragma (even with a deprecation
cycle) you'll see quite a few of those as many library authors try to
have their libraries compile with the last 3 major GHC versions.
P.S. For e.g. INLINABLE we require that you mention the function name
next to the pragma (which means that you can e.g. put the pragma after
the declaration). What's the rationale to not require
{-# OVERLAPPING Show [Char] #-}
here? Perhaps it's too annoying to have to repeat the types?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: .gitignore of tests
My 2 cents: I don't really care what we do, as long as (1) it's obvious where to put new gitignore entries, and (2) the gitignore list is accurate. Perhaps the testsuite should learn about Git and offer to add the files it creates to gitignore? Cheers, Edward Excerpts from Herbert Valerio Riedel's message of 2014-07-29 08:34:40 +0100: Hello! On 2014-07-29 at 08:25:15 +0200, Dr. ERDI Gergo wrote: 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... That's a good question I've been wondering about as well. I recently merged a few single .gitignore files I found in testsuite/ sub-folders into the main testsuite/.gitignore file it was rather inconsistent to have most stuff listed in the monolithic testsuite/.gitignore file and just a few deliberate .gitignores in a few sub-folders: http://git.haskell.org/ghc.git/commitdiff/767b9ddf7d2ea2bb99d49372c79be129fc2058ce The other issue is tooling. Some Git front-ends such as http://magit.github.io/ don't even recognize non-top-level .gitignore files (yet), and certainly don't offer to create one if they don't find it in the current sub-folder (instead magit just adds it to the top-level gitignore file) Also, I'm not sure if having .gitignore files sprinkled all over the source-tree instead of having just a few .gitignore files would be so much better, as in order to compute the effective .gitignore, you have to consider the union of all existing .gitignore files up to the top-level folder (while not crossing Git repo boundaries). However, we *can* switch to a scheme where we use many little per-folder .gitignore files, but everyone would have to agree to follow that new scheme, or we'll end up with a mess of confusing possibly overlapping .gitignore files. Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Overlapping and incoherent instances
On Tue, Jul 29, 2014 at 12:02:19PM +0200, Johan Tibell wrote:
What's the rationale to not require
{-# OVERLAPPING Show [Char] #-}
here? Perhaps it's too annoying to have to repeat the types?
This one might be written at the top of the file, so it would be easier
to overlook it, than having it directly at the instance declaration,
which seems to be one of the major points for OVERLAPPING and OVERLAPPABLE.
Greetings,
Daniel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Overlapping and incoherent instances
The current implementation requires the pragma exactly where showed it.
I'm not keen on allowing it to be separated.
I suppose with some more parser jiggery pokery it could be allowed immediately
before (or, better, after).
But cpp would let you say
instance
#if blah
{-# OVERLAPPABLE #-}
#endif
Show a = Show [a] where ...
Simon
| -Original Message-
| From: Johan Tibell [mailto:johan.tib...@gmail.com]
| Sent: 29 July 2014 11:02
| To: Herbert Valerio Riedel
| Cc: Niklas Hambüchen; Haskell Libraries (librar...@haskell.org); GHC
| users; Simon Peyton Jones; ghc-devs
| Subject: Re: Overlapping and incoherent instances
|
| On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel h...@gnu.org
| wrote:
| 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.
|
| Agreed, and if we remove the old pragma (even with a deprecation
| cycle) you'll see quite a few of those as many library authors try to
| have their libraries compile with the last 3 major GHC versions.
|
| P.S. For e.g. INLINABLE we require that you mention the function name
| next to the pragma (which means that you can e.g. put the pragma after
| the declaration). What's the rationale to not require
|
| {-# OVERLAPPING Show [Char] #-}
|
| here? Perhaps it's too annoying to have to repeat the types?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Haskell Platform 2014.2.0.0 Release Candidate 2
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: cabal install -j3 glib Resolving dependencies... Configuring glib-0.12.5.4... Building glib-0.12.5.4... Failed to install glib-0.12.5.4 Build log ( /Users/gcolpitts/.cabal/logs/glib-0.12.5.4.log ): [1 of 2] Compiling SetupWrapper ( /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv0gn/T/glib-0.12.5.4-27489/glib-0.12.5.4/SetupWrapper.hs, /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv0gn/T/glib-0.12.5.4-27489/glib-0.12.5.4/dist/setup/SetupWrapper.o ) [2 of 2] Compiling Main ( /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv0gn/T/glib-0.12.5.4-27489/glib-0.12.5.4/dist/setup/setup.hs, /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv0gn/T/glib-0.12.5.4-27489/glib-0.12.5.4/dist/setup/Main.o ) Linking /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv0gn/T/glib-0.12.5.4-27489/glib-0.12.5.4/dist/setup/setup ... [1 of 2] Compiling Gtk2HsSetup ( Gtk2HsSetup.hs, dist/setup-wrapper/Gtk2HsSetup.o ) [2 of 2] Compiling Main ( SetupMain.hs, dist/setup-wrapper/Main.o ) Linking dist/setup-wrapper/setup ... Configuring glib-0.12.5.4... Building glib-0.12.5.4... Preprocessing library glib-0.12.5.4... gtk2hsC2hs: Error in C header file. /usr/include/dirent.h:147: (column 10) [FATAL] Syntax error! The symbol `^' does not fit here. cabal: Error: some packages failed to install: glib-0.12.5.4 failed during the building phase. The exception was: ExitFailure 1 On Mon, Jul 28, 2014 at 11:40 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: 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.gz - 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-setup.exe - 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-RC2-setup.exe - 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%2064bit%20RC2.signed.pkg - 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 ___ ghc-devs mailing list
Re: Haskell Platform 2014.2.0.0 Release Candidate 2
apologies, for lack of detail, the following was on a Mac running 10.9.4 On Tue, Jul 29, 2014 at 8:45 AM, George Colpitts george.colpi...@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: cabal install -j3 glib Resolving dependencies... Configuring glib-0.12.5.4... Building glib-0.12.5.4... Failed to install glib-0.12.5.4 Build log ( /Users/gcolpitts/.cabal/logs/glib-0.12.5.4.log ): [1 of 2] Compiling SetupWrapper ( /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv0gn/T/glib-0.12.5.4-27489/glib-0.12.5.4/SetupWrapper.hs, /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv0gn/T/glib-0.12.5.4-27489/glib-0.12.5.4/dist/setup/SetupWrapper.o ) [2 of 2] Compiling Main ( /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv0gn/T/glib-0.12.5.4-27489/glib-0.12.5.4/dist/setup/setup.hs, /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv0gn/T/glib-0.12.5.4-27489/glib-0.12.5.4/dist/setup/Main.o ) Linking /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv0gn/T/glib-0.12.5.4-27489/glib-0.12.5.4/dist/setup/setup ... [1 of 2] Compiling Gtk2HsSetup ( Gtk2HsSetup.hs, dist/setup-wrapper/Gtk2HsSetup.o ) [2 of 2] Compiling Main ( SetupMain.hs, dist/setup-wrapper/Main.o ) Linking dist/setup-wrapper/setup ... Configuring glib-0.12.5.4... Building glib-0.12.5.4... Preprocessing library glib-0.12.5.4... gtk2hsC2hs: Error in C header file. /usr/include/dirent.h:147: (column 10) [FATAL] Syntax error! The symbol `^' does not fit here. cabal: Error: some packages failed to install: glib-0.12.5.4 failed during the building phase. The exception was: ExitFailure 1 On Mon, Jul 28, 2014 at 11:40 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: 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.gz - 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-setup.exe - 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-RC2-setup.exe - 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%2064bit%20RC2.signed.pkg - 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
Re: Haskell Platform 2014.2.0.0 Release Candidate 2
rc2 fixes the problem with ghc-pkg check I saw on rc1. Independently it is clear that the hmatrix package has a problem: ghc-pkg check bash-3.2$ cabal install -j3 hmatrix Resolving dependencies... Configuring storable-complex-0.2.1... Building storable-complex-0.2.1... Installed storable-complex-0.2.1 Configuring hmatrix-0.16.0.4... Building hmatrix-0.16.0.4... Installed hmatrix-0.16.0.4 Updating documentation index /Users/gcolpitts/Library/Haskell/share/doc/index.html bash-3.2$ ghc-pkg check Warning: library-dirs: /opt/local/lib/ doesn't exist or isn't a directory Warning: include-dirs: /opt/local/include/ doesn't exist or isn't a directory On Mon, Jul 28, 2014 at 11:40 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: 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.gz - 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-setup.exe - 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-RC2-setup.exe - 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%2064bit%20RC2.signed.pkg - 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Overlapping and incoherent instances
On 2014-07-29 at 14:13:22 +0200, Richard Eisenberg wrote: Are folks very keen to have *warning-free* compilation on several GHC versions? Personally, I would aim for warning-free compilation on a most recent version, and otherwise successful compilation on older versions. IMO: In typical build-bot configurations where you test against multiple GHC versions you often the warnings to be turned into errors via -Werror, as otherwise you wouldn't notice them. After all, warnings are hints about something that may need to be looked at, and if they turn out to be harmless, the specific warning can be turned off on a case-by-case basis (which alas, in GHC's case is a bit difficult, as for instance, you can't turn off a specific warning for a single declaration only, but only for a whole module) Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Haskell Platform 2014.2.0.0 Release Candidate 2
Weird that I didn't have this problem with rc1 On Tuesday, July 29, 2014, Brandon Allbery allber...@gmail.com wrote: On Tue, Jul 29, 2014 at 7:45 AM, George Colpitts george.colpi...@gmail.com javascript:_e(%7B%7D,'cvml','george.colpi...@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 allber...@gmail.com javascript:_e(%7B%7D,'cvml','allber...@gmail.com'); ballb...@sinenomine.net javascript:_e(%7B%7D,'cvml','ballb...@sinenomine.net'); unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Overlapping and incoherent instances
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-boun...@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 (librar...@haskell.org); ghc-devs Subject: Re: Overlapping and incoherent instances How about CAN_OVERLAP? -- Krzysztof 29-07-2014 15:40, Brandon Allbery allber...@gmail.commailto:allber...@gmail.com napisał(a): On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel andreas.a...@ifi.lmu.demailto:andreas.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 allber...@gmail.commailto:allber...@gmail.com ballb...@sinenomine.netmailto:ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Libraries mailing list librar...@haskell.orgmailto:librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Overlapping and incoherent instances
| One other issue this brings up: how does this all interact with -XSafe?
| Right now, Safety can be inferred by looking at the set of LANGUAGE
| pragmas and the import list. (Right?) With the change as implemented,
| Safe inference would require looking at all instance declarations. Is
| this OK?
I'm honestly not sure, but I do know that, in the implementation, each instance
declaration keeps track of (a) whether it is
OVERLAPPABLE/OVERLAPPING/INCOHERENT, and (b) the setting of -XSafe in the
module where the instance declaration is given.
This doesn't change. So I can't answer your question directly, but I think
that the behaviour is unchanged from that at present.
Simon
|
| Richard
|
| On Jul 29, 2014, at 7:02 AM, Simon Peyton Jones simo...@microsoft.com
| wrote:
|
| The current implementation requires the pragma exactly where showed
| it.
|
| I'm not keen on allowing it to be separated.
|
| I suppose with some more parser jiggery pokery it could be allowed
| immediately before (or, better, after).
|
| But cpp would let you say
|
| instance
| #if blah
| {-# OVERLAPPABLE #-}
| #endif
| Show a = Show [a] where ...
|
| Simon
|
| | -Original Message-
| | From: Johan Tibell [mailto:johan.tib...@gmail.com]
| | Sent: 29 July 2014 11:02
| | To: Herbert Valerio Riedel
| | Cc: Niklas Hambüchen; Haskell Libraries (librar...@haskell.org);
| GHC
| | users; Simon Peyton Jones; ghc-devs
| | Subject: Re: Overlapping and incoherent instances
| |
| | On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel
| | h...@gnu.org
| | wrote:
| | 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.
| |
| | Agreed, and if we remove the old pragma (even with a deprecation
| | cycle) you'll see quite a few of those as many library authors try
| | to have their libraries compile with the last 3 major GHC versions.
| |
| | P.S. For e.g. INLINABLE we require that you mention the function
| | name next to the pragma (which means that you can e.g. put the
| | pragma after the declaration). What's the rationale to not require
| |
| | {-# OVERLAPPING Show [Char] #-}
| |
| | here? Perhaps it's too annoying to have to repeat the types?
| ___
| Glasgow-haskell-users mailing list
| glasgow-haskell-us...@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Windows build broken -- again!
Aaargh! My windows build is, once again, broken. The error is below. Could whoever broke it please fix it? Something to do with blocking_queue_hd perhaps? Please. Thanks Simon rts\win32\AsyncIO.c: In function 'awaitRequests': rts\win32\AsyncIO.c:289:23: error: 'blocking_queue_hd' undeclared (first use in this function) rts\win32\AsyncIO.c:289:23: note: each undeclared identifier is reported only once for each function it appears in ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Overlapping and incoherent instances
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows build broken -- again!
Thanks Niklas - this was an utter failure on my part. I'm not even sure how this slipped in, but it was definitely my fault. Fixed in 6640635e6e2654f0acd8f10e0d02a8bd1c8296ff On Tue, Jul 29, 2014 at 8:53 PM, Niklas Larsson metanik...@gmail.com wrote: Hi! Seems like it is the detabbing in commit 3021fb that has gone awry, blocked_queue_hd was renamed blocking_queue_hd in one place. I have attached a patch. I really need to set up a buildbot. Maybe if the weather gets worse. Niklas 2014-07-30 0:37 GMT+02:00 Simon Peyton Jones simo...@microsoft.com: Aaargh! My windows build is, once again, broken. The error is below. Could whoever broke it please fix it? Something to do with “blocking_queue_hd” perhaps? Please. Thanks Simon rts\win32\AsyncIO.c: In function 'awaitRequests': rts\win32\AsyncIO.c:289:23: error: 'blocking_queue_hd' undeclared (first use in this function) rts\win32\AsyncIO.c:289:23: note: each undeclared identifier is reported only once for each function it appears in ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
