From elliot.cameron at covenanteyes.com Wed Jul 1 03:19:40 2015 From: elliot.cameron at covenanteyes.com (Elliot Cameron) Date: Wed, 1 Jul 2015 03:19:40 +0000 Subject: Help Building GHC on Windows to avoid LGPL Message-ID: <4a04d738f1954cbe87f00dacc1b76d2b@HQWS-EXMB-01.main.covenanteyes.com> Hi all, I'm very new to GHC's source, but I'm trying to build a version of GHC for Windows that uses integer-simple instead of integer-gmp. My goal is to provide builds for MinGHC and stack to help alleviate the LGPL concerns on Windows: https://github.com/commercialhaskell/stack/issues/399 So far I have not met with much success. I'm following this rather well-written tutorial: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows Following those instructions exactly (I think) has brought me to a failing build. Some variables that the instructions don't pin down are as follows: I'm using the mingw64_shell on a Windows 8.1 64-bit machine. I'm trying to build the code at tag ghc-7.10.1-release and I'm using GHC 7.8.4 64-bit to do it. I've updated everything to the latest with pacman. I did not configure a mk/build.mk file. I have tried copying the sample configuration but got the same result. Is there anyone who'd be willing to help me troubleshoot? Or if you have a working setup, a stop-gap measure would be to build 32- and 64-bit versions of the last few most recent versions of GHC with integer-simple so we can use them for MinGHC and stack. Here's the last bit of what I'm seeing. Configuring base-4.8.0.0... configure: WARNING: unrecognized options: --with-compiler, --with-gcc checking build system type... x86_64-pc-mingw64 checking host system type... x86_64-pc-mingw64 checking target system type... x86_64-pc-mingw64 checking for gcc... C:/msys64/tmp/ghc/inplace/mingw/bin/gcc.exe checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether C:/msys64/tmp/ghc/inplace/mingw/bin/gcc.exe accepts -g... yes checking for C:/msys64/tmp/ghc/inplace/mingw/bin/gcc.exe option to accept ISO C89... none needed checking for WINDOWS platform... YES checking how to run the C preprocessor... C:/msys64/tmp/ghc/inplace/mingw/bin/gcc.exe -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for long long... yes checking for ANSI C header files... (cached) yes checking ctype.h usability... yes checking ctype.h presence... yes checking for ctype.h... yes checking errno.h usability... yes checking errno.h presence... yes checking for errno.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for inttypes.h... (cached) yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking sys/resource.h usability... no checking sys/resource.h presence... no checking for sys/resource.h... no checking sys/select.h usability... no checking sys/select.h presence... no checking for sys/select.h... no checking for sys/stat.h... (cached) yes checking sys/syscall.h usability... no checking sys/syscall.h presence... no checking for sys/syscall.h... no checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/timeb.h usability... yes checking sys/timeb.h presence... yes checking for sys/timeb.h... yes checking sys/timers.h usability... no checking sys/timers.h presence... no checking for sys/timers.h... no checking sys/times.h usability... no checking sys/times.h presence... no checking for sys/times.h... no checking for sys/types.h... (cached) yes checking sys/utsname.h usability... no checking sys/utsname.h presence... no checking for sys/utsname.h... no checking sys/wait.h usability... no checking sys/wait.h presence... no checking for sys/wait.h... no checking termios.h usability... no checking termios.h presence... no checking for termios.h... no checking time.h usability... yes checking time.h presence... yes checking for time.h... yes checking for unistd.h... (cached) yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking windows.h usability... yes checking windows.h presence... yes checking for windows.h... yes checking winsock.h usability... yes checking winsock.h presence... yes checking for winsock.h... yes checking langinfo.h usability... no checking langinfo.h presence... no checking for langinfo.h... no checking poll.h usability... no checking poll.h presence... no checking for poll.h... no checking sys/epoll.h usability... no checking sys/epoll.h presence... no checking for sys/epoll.h... no checking sys/event.h usability... no checking sys/event.h presence... no checking for sys/event.h... no checking sys/eventfd.h usability... no checking sys/eventfd.h presence... no checking for sys/eventfd.h... no checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... 64 checking wctype.h usability... yes checking wctype.h presence... yes checking for wctype.h... yes checking for iswspace... yes checking for lstat... no checking for clock_gettime in -lrt... no checking for clock_gettime... no checking for getclock... no checking for getrusage... no checking for times... no checking for _chsize... yes checking for ftruncate... yes checking for epoll_ctl... no checking for eventfd... no checking for kevent... no checking for kevent64... no checking for kqueue... no checking for poll... no checking for unsetenv... no checking return type of unsetenv... int checking Haskell type for char... Int8 checking Haskell type for signed char... Int8 checking Haskell type for unsigned char... Word8 checking Haskell type for short... Int16 checking Haskell type for unsigned short... Word16 checking Haskell type for int... Int32 checking Haskell type for unsigned int... Word32 checking Haskell type for long... Int32 checking Haskell type for unsigned long... Word32 checking Haskell type for long long... Int64 checking Haskell type for unsigned long long... Word64 checking Haskell type for float... Float checking Haskell type for double... Double checking Haskell type for ptrdiff_t... Int64 checking Haskell type for size_t... Word64 checking Haskell type for wchar_t... Word16 checking Haskell type for sig_atomic_t... Int32 checking Haskell type for clock_t... Int32 checking Haskell type for time_t... Int64 checking Haskell type for useconds_t... Word32 checking Haskell type for suseconds_t... Int32 checking Haskell type for dev_t... Word32 checking Haskell type for ino_t... Word16 checking Haskell type for mode_t... Word16 checking Haskell type for off_t... Int64 checking Haskell type for pid_t... Int64 checking Haskell type for gid_t... not supported checking Haskell type for uid_t... not supported checking Haskell type for cc_t... not supported checking Haskell type for speed_t... not supported checking Haskell type for tcflag_t... not supported checking Haskell type for nlink_t... not supported checking Haskell type for ssize_t... Int64 checking Haskell type for rlim_t... not supported checking Haskell type for intptr_t... Int64 checking Haskell type for uintptr_t... Word64 checking Haskell type for intmax_t... Int64 checking Haskell type for uintmax_t... Word64 checking value of E2BIG... 7 checking value of EACCES... 13 checking value of EADDRINUSE... -1 checking value of EADDRNOTAVAIL... -1 checking value of EADV... -1 checking value of EAFNOSUPPORT... -1 checking value of EAGAIN... 11 checking value of EALREADY... -1 checking value of EBADF... 9 checking value of EBADMSG... -1 checking value of EBADRPC... -1 checking value of EBUSY... 16 checking value of ECHILD... 10 checking value of ECOMM... -1 checking value of ECONNABORTED... -1 checking value of ECONNREFUSED... -1 checking value of ECONNRESET... -1 checking value of EDEADLK... 36 checking value of EDESTADDRREQ... -1 checking value of EDIRTY... -1 checking value of EDOM... 33 checking value of EDQUOT... -1 checking value of EEXIST... 17 checking value of EFAULT... 14 checking value of EFBIG... 27 checking value of EFTYPE... -1 checking value of EHOSTDOWN... -1 checking value of EHOSTUNREACH... -1 checking value of EIDRM... -1 checking value of EILSEQ... 42 checking value of EINPROGRESS... -1 checking value of EINTR... 4 checking value of EINVAL... 22 checking value of EIO... 5 checking value of EISCONN... -1 checking value of EISDIR... 21 checking value of ELOOP... -1 checking value of EMFILE... 24 checking value of EMLINK... 31 checking value of EMSGSIZE... -1 checking value of EMULTIHOP... -1 checking value of ENAMETOOLONG... 38 checking value of ENETDOWN... -1 checking value of ENETRESET... -1 checking value of ENETUNREACH... -1 checking value of ENFILE... 23 checking value of ENOBUFS... -1 checking value of ENODATA... -1 checking value of ENODEV... 19 checking value of ENOENT... 2 checking value of ENOEXEC... 8 checking value of ENOLCK... 39 checking value of ENOLINK... -1 checking value of ENOMEM... 12 checking value of ENOMSG... -1 checking value of ENONET... -1 checking value of ENOPROTOOPT... -1 checking value of ENOSPC... 28 checking value of ENOSR... -1 checking value of ENOSTR... -1 checking value of ENOSYS... 40 checking value of ENOTBLK... -1 checking value of ENOTCONN... -1 checking value of ENOTDIR... 20 checking value of ENOTEMPTY... 41 checking value of ENOTSOCK... -1 checking value of ENOTTY... 25 checking value of ENXIO... 6 checking value of EOPNOTSUPP... -1 checking value of EPERM... 1 checking value of EPFNOSUPPORT... -1 checking value of EPIPE... 32 checking value of EPROCLIM... -1 checking value of EPROCUNAVAIL... -1 checking value of EPROGMISMATCH... -1 checking value of EPROGUNAVAIL... -1 checking value of EPROTO... -1 checking value of EPROTONOSUPPORT... -1 checking value of EPROTOTYPE... -1 checking value of ERANGE... 34 checking value of EREMCHG... -1 checking value of EREMOTE... -1 checking value of EROFS... 30 checking value of ERPCMISMATCH... -1 checking value of ERREMOTE... -1 checking value of ESHUTDOWN... -1 checking value of ESOCKTNOSUPPORT... -1 checking value of ESPIPE... 29 checking value of ESRCH... 3 checking value of ESRMNT... -1 checking value of ESTALE... -1 checking value of ETIME... -1 checking value of ETIMEDOUT... -1 checking value of ETOOMANYREFS... -1 checking value of ETXTBSY... -1 checking value of EUSERS... -1 checking value of EWOULDBLOCK... -1 checking value of EXDEV... 18 checking value of ENOCIGAR... -1 checking value of ENOTSUP... -1 checking value of SIGINT... 2 checking value of O_BINARY... 32768 checking size of struct MD5Context... 88 configure: creating ./config.status config.status: creating base.buildinfo config.status: creating include/HsBaseConfig.h config.status: creating include/EventConfig.h configure: WARNING: unrecognized options: --with-compiler, --with-gcc "C:/msys64/tmp/ghc/inplace/bin/ghc-pkg.exe" update --force libraries/base/dist-install/inplace-pkg-config Reading package info from "libraries/base/dist-install/inplace-pkg-config" ... done. base-4.8.0.0: Warning: haddock-interfaces: C:\msys64\tmp\ghc\libraries\base\dist-install\doc\html\base\base.haddock doesn't exist or isn't a file base-4.8.0.0: cannot find any of ["Control\\Applicative.hi","Control\\Applicative.p_hi","Control\\Applicative.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Arrow.hi","Control\\Arrow.p_hi","Control\\Arrow.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Category.hi","Control\\Category.p_hi","Control\\Category.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Concurrent.hi","Control\\Concurrent.p_hi","Control\\Concurrent.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Concurrent\\Chan.hi","Control\\Concurrent\\Chan.p_hi","Control\\Concurrent\\Chan.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Concurrent\\MVar.hi","Control\\Concurrent\\MVar.p_hi","Control\\Concurrent\\MVar.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Concurrent\\QSem.hi","Control\\Concurrent\\QSem.p_hi","Control\\Concurrent\\QSem.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Concurrent\\QSemN.hi","Control\\Concurrent\\QSemN.p_hi","Control\\Concurrent\\QSemN.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Exception.hi","Control\\Exception.p_hi","Control\\Exception.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Exception\\Base.hi","Control\\Exception\\Base.p_hi","Control\\Exception\\Base.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Monad.hi","Control\\Monad.p_hi","Control\\Monad.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Monad\\Fix.hi","Control\\Monad\\Fix.p_hi","Control\\Monad\\Fix.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Monad\\Instances.hi","Control\\Monad\\Instances.p_hi","Control\\Monad\\Instances.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Monad\\ST.hi","Control\\Monad\\ST.p_hi","Control\\Monad\\ST.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Monad\\ST\\Lazy.hi","Control\\Monad\\ST\\Lazy.p_hi","Control\\Monad\\ST\\Lazy.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Monad\\ST\\Lazy\\Safe.hi","Control\\Monad\\ST\\Lazy\\Safe.p_hi","Control\\Monad\\ST\\Lazy\\Safe.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Monad\\ST\\Lazy\\Unsafe.hi","Control\\Monad\\ST\\Lazy\\Unsafe.p_hi","Control\\Monad\\ST\\Lazy\\Unsafe.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Monad\\ST\\Safe.hi","Control\\Monad\\ST\\Safe.p_hi","Control\\Monad\\ST\\Safe.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Monad\\ST\\Strict.hi","Control\\Monad\\ST\\Strict.p_hi","Control\\Monad\\ST\\Strict.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Monad\\ST\\Unsafe.hi","Control\\Monad\\ST\\Unsafe.p_hi","Control\\Monad\\ST\\Unsafe.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Monad\\Zip.hi","Control\\Monad\\Zip.p_hi","Control\\Monad\\Zip.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Bifunctor.hi","Data\\Bifunctor.p_hi","Data\\Bifunctor.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Bits.hi","Data\\Bits.p_hi","Data\\Bits.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Bool.hi","Data\\Bool.p_hi","Data\\Bool.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Char.hi","Data\\Char.p_hi","Data\\Char.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Coerce.hi","Data\\Coerce.p_hi","Data\\Coerce.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Complex.hi","Data\\Complex.p_hi","Data\\Complex.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Data.hi","Data\\Data.p_hi","Data\\Data.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Dynamic.hi","Data\\Dynamic.p_hi","Data\\Dynamic.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Either.hi","Data\\Either.p_hi","Data\\Either.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Eq.hi","Data\\Eq.p_hi","Data\\Eq.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Fixed.hi","Data\\Fixed.p_hi","Data\\Fixed.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Foldable.hi","Data\\Foldable.p_hi","Data\\Foldable.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Function.hi","Data\\Function.p_hi","Data\\Function.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Functor.hi","Data\\Functor.p_hi","Data\\Functor.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Functor\\Identity.hi","Data\\Functor\\Identity.p_hi","Data\\Functor\\Identity.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\IORef.hi","Data\\IORef.p_hi","Data\\IORef.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Int.hi","Data\\Int.p_hi","Data\\Int.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Ix.hi","Data\\Ix.p_hi","Data\\Ix.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\List.hi","Data\\List.p_hi","Data\\List.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Maybe.hi","Data\\Maybe.p_hi","Data\\Maybe.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Monoid.hi","Data\\Monoid.p_hi","Data\\Monoid.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Ord.hi","Data\\Ord.p_hi","Data\\Ord.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Proxy.hi","Data\\Proxy.p_hi","Data\\Proxy.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Ratio.hi","Data\\Ratio.p_hi","Data\\Ratio.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\STRef.hi","Data\\STRef.p_hi","Data\\STRef.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\STRef\\Lazy.hi","Data\\STRef\\Lazy.p_hi","Data\\STRef\\Lazy.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\STRef\\Strict.hi","Data\\STRef\\Strict.p_hi","Data\\STRef\\Strict.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\String.hi","Data\\String.p_hi","Data\\String.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Traversable.hi","Data\\Traversable.p_hi","Data\\Traversable.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Tuple.hi","Data\\Tuple.p_hi","Data\\Tuple.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Type\\Bool.hi","Data\\Type\\Bool.p_hi","Data\\Type\\Bool.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Type\\Coercion.hi","Data\\Type\\Coercion.p_hi","Data\\Type\\Coercion.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Type\\Equality.hi","Data\\Type\\Equality.p_hi","Data\\Type\\Equality.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Typeable.hi","Data\\Typeable.p_hi","Data\\Typeable.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Typeable\\Internal.hi","Data\\Typeable\\Internal.p_hi","Data\\Typeable\\Internal.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Unique.hi","Data\\Unique.p_hi","Data\\Unique.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Version.hi","Data\\Version.p_hi","Data\\Version.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Void.hi","Data\\Void.p_hi","Data\\Void.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\Word.hi","Data\\Word.p_hi","Data\\Word.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Debug\\Trace.hi","Debug\\Trace.p_hi","Debug\\Trace.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign.hi","Foreign.p_hi","Foreign.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\C.hi","Foreign\\C.p_hi","Foreign\\C.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\C\\Error.hi","Foreign\\C\\Error.p_hi","Foreign\\C\\Error.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\C\\String.hi","Foreign\\C\\String.p_hi","Foreign\\C\\String.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\C\\Types.hi","Foreign\\C\\Types.p_hi","Foreign\\C\\Types.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\Concurrent.hi","Foreign\\Concurrent.p_hi","Foreign\\Concurrent.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\ForeignPtr.hi","Foreign\\ForeignPtr.p_hi","Foreign\\ForeignPtr.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\ForeignPtr\\Safe.hi","Foreign\\ForeignPtr\\Safe.p_hi","Foreign\\ForeignPtr\\Safe.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\ForeignPtr\\Unsafe.hi","Foreign\\ForeignPtr\\Unsafe.p_hi","Foreign\\ForeignPtr\\Unsafe.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\Marshal.hi","Foreign\\Marshal.p_hi","Foreign\\Marshal.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\Marshal\\Alloc.hi","Foreign\\Marshal\\Alloc.p_hi","Foreign\\Marshal\\Alloc.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\Marshal\\Array.hi","Foreign\\Marshal\\Array.p_hi","Foreign\\Marshal\\Array.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\Marshal\\Error.hi","Foreign\\Marshal\\Error.p_hi","Foreign\\Marshal\\Error.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\Marshal\\Pool.hi","Foreign\\Marshal\\Pool.p_hi","Foreign\\Marshal\\Pool.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\Marshal\\Safe.hi","Foreign\\Marshal\\Safe.p_hi","Foreign\\Marshal\\Safe.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\Marshal\\Unsafe.hi","Foreign\\Marshal\\Unsafe.p_hi","Foreign\\Marshal\\Unsafe.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\Marshal\\Utils.hi","Foreign\\Marshal\\Utils.p_hi","Foreign\\Marshal\\Utils.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\Ptr.hi","Foreign\\Ptr.p_hi","Foreign\\Ptr.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\Safe.hi","Foreign\\Safe.p_hi","Foreign\\Safe.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\StablePtr.hi","Foreign\\StablePtr.p_hi","Foreign\\StablePtr.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\Storable.hi","Foreign\\Storable.p_hi","Foreign\\Storable.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Arr.hi","GHC\\Arr.p_hi","GHC\\Arr.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Base.hi","GHC\\Base.p_hi","GHC\\Base.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Char.hi","GHC\\Char.p_hi","GHC\\Char.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Conc.hi","GHC\\Conc.p_hi","GHC\\Conc.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Conc\\IO.hi","GHC\\Conc\\IO.p_hi","GHC\\Conc\\IO.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Conc\\Signal.hi","GHC\\Conc\\Signal.p_hi","GHC\\Conc\\Signal.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Conc\\Sync.hi","GHC\\Conc\\Sync.p_hi","GHC\\Conc\\Sync.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\ConsoleHandler.hi","GHC\\ConsoleHandler.p_hi","GHC\\ConsoleHandler.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Constants.hi","GHC\\Constants.p_hi","GHC\\Constants.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Desugar.hi","GHC\\Desugar.p_hi","GHC\\Desugar.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Enum.hi","GHC\\Enum.p_hi","GHC\\Enum.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Environment.hi","GHC\\Environment.p_hi","GHC\\Environment.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Err.hi","GHC\\Err.p_hi","GHC\\Err.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Exception.hi","GHC\\Exception.p_hi","GHC\\Exception.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Exts.hi","GHC\\Exts.p_hi","GHC\\Exts.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Fingerprint.hi","GHC\\Fingerprint.p_hi","GHC\\Fingerprint.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Fingerprint\\Type.hi","GHC\\Fingerprint\\Type.p_hi","GHC\\Fingerprint\\Type.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Float.hi","GHC\\Float.p_hi","GHC\\Float.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Float\\ConversionUtils.hi","GHC\\Float\\ConversionUtils.p_hi","GHC\\Float\\ConversionUtils.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Float\\RealFracMethods.hi","GHC\\Float\\RealFracMethods.p_hi","GHC\\Float\\RealFracMethods.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Foreign.hi","GHC\\Foreign.p_hi","GHC\\Foreign.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\ForeignPtr.hi","GHC\\ForeignPtr.p_hi","GHC\\ForeignPtr.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\GHCi.hi","GHC\\GHCi.p_hi","GHC\\GHCi.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Generics.hi","GHC\\Generics.p_hi","GHC\\Generics.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO.hi","GHC\\IO.p_hi","GHC\\IO.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Buffer.hi","GHC\\IO\\Buffer.p_hi","GHC\\IO\\Buffer.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\BufferedIO.hi","GHC\\IO\\BufferedIO.p_hi","GHC\\IO\\BufferedIO.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Device.hi","GHC\\IO\\Device.p_hi","GHC\\IO\\Device.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Encoding.hi","GHC\\IO\\Encoding.p_hi","GHC\\IO\\Encoding.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Encoding\\CodePage.hi","GHC\\IO\\Encoding\\CodePage.p_hi","GHC\\IO\\Encoding\\CodePage.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Encoding\\Failure.hi","GHC\\IO\\Encoding\\Failure.p_hi","GHC\\IO\\Encoding\\Failure.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Encoding\\Iconv.hi","GHC\\IO\\Encoding\\Iconv.p_hi","GHC\\IO\\Encoding\\Iconv.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Encoding\\Latin1.hi","GHC\\IO\\Encoding\\Latin1.p_hi","GHC\\IO\\Encoding\\Latin1.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Encoding\\Types.hi","GHC\\IO\\Encoding\\Types.p_hi","GHC\\IO\\Encoding\\Types.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Encoding\\UTF16.hi","GHC\\IO\\Encoding\\UTF16.p_hi","GHC\\IO\\Encoding\\UTF16.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Encoding\\UTF32.hi","GHC\\IO\\Encoding\\UTF32.p_hi","GHC\\IO\\Encoding\\UTF32.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Encoding\\UTF8.hi","GHC\\IO\\Encoding\\UTF8.p_hi","GHC\\IO\\Encoding\\UTF8.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Exception.hi","GHC\\IO\\Exception.p_hi","GHC\\IO\\Exception.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\FD.hi","GHC\\IO\\FD.p_hi","GHC\\IO\\FD.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Handle.hi","GHC\\IO\\Handle.p_hi","GHC\\IO\\Handle.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Handle\\FD.hi","GHC\\IO\\Handle\\FD.p_hi","GHC\\IO\\Handle\\FD.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Handle\\Internals.hi","GHC\\IO\\Handle\\Internals.p_hi","GHC\\IO\\Handle\\Internals.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Handle\\Text.hi","GHC\\IO\\Handle\\Text.p_hi","GHC\\IO\\Handle\\Text.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Handle\\Types.hi","GHC\\IO\\Handle\\Types.p_hi","GHC\\IO\\Handle\\Types.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\IOMode.hi","GHC\\IO\\IOMode.p_hi","GHC\\IO\\IOMode.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IOArray.hi","GHC\\IOArray.p_hi","GHC\\IOArray.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IORef.hi","GHC\\IORef.p_hi","GHC\\IORef.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IP.hi","GHC\\IP.p_hi","GHC\\IP.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Int.hi","GHC\\Int.p_hi","GHC\\Int.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\List.hi","GHC\\List.p_hi","GHC\\List.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\MVar.hi","GHC\\MVar.p_hi","GHC\\MVar.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Natural.hi","GHC\\Natural.p_hi","GHC\\Natural.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Num.hi","GHC\\Num.p_hi","GHC\\Num.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\OldList.hi","GHC\\OldList.p_hi","GHC\\OldList.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\PArr.hi","GHC\\PArr.p_hi","GHC\\PArr.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Pack.hi","GHC\\Pack.p_hi","GHC\\Pack.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Profiling.hi","GHC\\Profiling.p_hi","GHC\\Profiling.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Ptr.hi","GHC\\Ptr.p_hi","GHC\\Ptr.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Read.hi","GHC\\Read.p_hi","GHC\\Read.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Real.hi","GHC\\Real.p_hi","GHC\\Real.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\RTS\\Flags.hi","GHC\\RTS\\Flags.p_hi","GHC\\RTS\\Flags.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\ST.hi","GHC\\ST.p_hi","GHC\\ST.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\StaticPtr.hi","GHC\\StaticPtr.p_hi","GHC\\StaticPtr.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\STRef.hi","GHC\\STRef.p_hi","GHC\\STRef.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Show.hi","GHC\\Show.p_hi","GHC\\Show.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Stable.hi","GHC\\Stable.p_hi","GHC\\Stable.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Stack.hi","GHC\\Stack.p_hi","GHC\\Stack.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Stats.hi","GHC\\Stats.p_hi","GHC\\Stats.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Storable.hi","GHC\\Storable.p_hi","GHC\\Storable.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\TopHandler.hi","GHC\\TopHandler.p_hi","GHC\\TopHandler.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\TypeLits.hi","GHC\\TypeLits.p_hi","GHC\\TypeLits.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Unicode.hi","GHC\\Unicode.p_hi","GHC\\Unicode.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Weak.hi","GHC\\Weak.p_hi","GHC\\Weak.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Word.hi","GHC\\Word.p_hi","GHC\\Word.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Numeric.hi","Numeric.p_hi","Numeric.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Numeric\\Natural.hi","Numeric\\Natural.p_hi","Numeric\\Natural.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Prelude.hi","Prelude.p_hi","Prelude.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["System\\CPUTime.hi","System\\CPUTime.p_hi","System\\CPUTime.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["System\\Console\\GetOpt.hi","System\\Console\\GetOpt.p_hi","System\\Console\\GetOpt.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["System\\Environment.hi","System\\Environment.p_hi","System\\Environment.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["System\\Exit.hi","System\\Exit.p_hi","System\\Exit.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["System\\IO.hi","System\\IO.p_hi","System\\IO.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["System\\IO\\Error.hi","System\\IO\\Error.p_hi","System\\IO\\Error.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["System\\IO\\Unsafe.hi","System\\IO\\Unsafe.p_hi","System\\IO\\Unsafe.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["System\\Info.hi","System\\Info.p_hi","System\\Info.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["System\\Mem.hi","System\\Mem.p_hi","System\\Mem.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["System\\Mem\\StableName.hi","System\\Mem\\StableName.p_hi","System\\Mem\\StableName.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["System\\Mem\\Weak.hi","System\\Mem\\Weak.p_hi","System\\Mem\\Weak.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["System\\Posix\\Internals.hi","System\\Posix\\Internals.p_hi","System\\Posix\\Internals.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["System\\Posix\\Types.hi","System\\Posix\\Types.p_hi","System\\Posix\\Types.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["System\\Timeout.hi","System\\Timeout.p_hi","System\\Timeout.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Text\\ParserCombinators\\ReadP.hi","Text\\ParserCombinators\\ReadP.p_hi","Text\\ParserCombinators\\ReadP.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Text\\ParserCombinators\\ReadPrec.hi","Text\\ParserCombinators\\ReadPrec.p_hi","Text\\ParserCombinators\\ReadPrec.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Text\\Printf.hi","Text\\Printf.p_hi","Text\\Printf.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Text\\Read.hi","Text\\Read.p_hi","Text\\Read.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Text\\Read\\Lex.hi","Text\\Read\\Lex.p_hi","Text\\Read\\Lex.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Text\\Show.hi","Text\\Show.p_hi","Text\\Show.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Text\\Show\\Functions.hi","Text\\Show\\Functions.p_hi","Text\\Show\\Functions.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Unsafe\\Coerce.hi","Unsafe\\Coerce.p_hi","Unsafe\\Coerce.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Encoding\\CodePage\\API.hi","GHC\\IO\\Encoding\\CodePage\\API.p_hi","GHC\\IO\\Encoding\\CodePage\\API.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\IO\\Encoding\\CodePage\\Table.hi","GHC\\IO\\Encoding\\CodePage\\Table.p_hi","GHC\\IO\\Encoding\\CodePage\\Table.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Conc\\Windows.hi","GHC\\Conc\\Windows.p_hi","GHC\\Conc\\Windows.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["GHC\\Windows.hi","GHC\\Windows.p_hi","GHC\\Windows.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Monad\\ST\\Imp.hi","Control\\Monad\\ST\\Imp.p_hi","Control\\Monad\\ST\\Imp.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Control\\Monad\\ST\\Lazy\\Imp.hi","Control\\Monad\\ST\\Lazy\\Imp.p_hi","Control\\Monad\\ST\\Lazy\\Imp.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Data\\OldList.hi","Data\\OldList.p_hi","Data\\OldList.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["Foreign\\ForeignPtr\\Imp.hi","Foreign\\ForeignPtr\\Imp.p_hi","Foreign\\ForeignPtr\\Imp.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["System\\Environment\\ExecutablePath.hi","System\\Environment\\ExecutablePath.p_hi","System\\Environment\\ExecutablePath.dyn_hi"] (ignoring) base-4.8.0.0: cannot find any of ["libHSbase-4.8.0.0-I5BErHzyOm07EBNpKBEeUv.a","libHSbase-4.8.0.0-I5BErHzyOm07EBNpKBEeUv.p_a","libHSbase-4.8.0.0-I5BErHzyOm07EBNpKBEeUv-ghc7.10.1.so","libHSbase-4.8.0.0-I5BErHzyOm07EBNpKBEeUv-ghc7.10.1.dylib","HSbase-4.8.0.0-I5BErHzyOm07EBNpKBEeUv-ghc7.10.1.dll"] on library path (ignoring) "inplace/bin/ghc-cabal.exe" check libraries/filepath "inplace/bin/ghc-cabal.exe" configure libraries/filepath dist-install "" --with-ghc="C:/msys64/tmp/ghc/inplace/bin/ghc-stage1.exe" --with-ghc-pkg="C:/msys64/tmp/ghc/inplace/bin/ghc-pkg.exe" --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --enable-library-profiling --disable-shared --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -fno-stack-protector " --with-gcc="C:/msys64/tmp/ghc/inplace/mingw/bin/gcc.exe" --with-ld="C:/msys64/tmp/ghc/inplace/mingw/bin/ld.exe" --configure-option=--with-cc="C:/msys64/tmp/ghc/inplace/mingw/bin/gcc.exe" --with-ar="/usr/bin/ar" --with-alex="/usr/local/bin/alex" --with-happy="/usr/local/bin/happy" Configuring filepath-1.4.0.0... "C:/msys64/tmp/ghc/inplace/bin/ghc-pkg.exe" update --force libraries/filepath/dist-install/inplace-pkg-config Reading package info from "libraries/filepath/dist-install/inplace-pkg-config" ... done. filepath-1.4.0.0: Warning: haddock-interfaces: C:\msys64\tmp\ghc\libraries\filepath\dist-install\doc\html\filepath\filepath.haddock doesn't exist or isn't a file filepath-1.4.0.0: cannot find any of ["System\\FilePath.hi","System\\FilePath.p_hi","System\\FilePath.dyn_hi"] (ignoring) filepath-1.4.0.0: cannot find any of ["System\\FilePath\\Posix.hi","System\\FilePath\\Posix.p_hi","System\\FilePath\\Posix.dyn_hi"] (ignoring) filepath-1.4.0.0: cannot find any of ["System\\FilePath\\Windows.hi","System\\FilePath\\Windows.p_hi","System\\FilePath\\Windows.dyn_hi"] (ignoring) filepath-1.4.0.0: cannot find any of ["libHSfilepath-1.4.0.0-5HhyRonfEZoDO205Wm9E4h.a","libHSfilepath-1.4.0.0-5HhyRonfEZoDO205Wm9E4h.p_a","libHSfilepath-1.4.0.0-5HhyRonfEZoDO205Wm9E4h-ghc7.10.1.so","libHSfilepath-1.4.0.0-5HhyRonfEZoDO205Wm9E4h-ghc7.10.1.dylib","HSfilepath-1.4.0.0-5HhyRonfEZoDO205Wm9E4h-ghc7.10.1.dll"] on library path (ignoring) "inplace/bin/ghc-cabal.exe" check libraries/array "inplace/bin/ghc-cabal.exe" configure libraries/array dist-install "" --with-ghc="C:/msys64/tmp/ghc/inplace/bin/ghc-stage1.exe" --with-ghc-pkg="C:/msys64/tmp/ghc/inplace/bin/ghc-pkg.exe" --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --enable-library-profiling --disable-shared --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -fno-stack-protector " --with-gcc="C:/msys64/tmp/ghc/inplace/mingw/bin/gcc.exe" --with-ld="C:/msys64/tmp/ghc/inplace/mingw/bin/ld.exe" --configure-option=--with-cc="C:/msys64/tmp/ghc/inplace/mingw/bin/gcc.exe" --with-ar="/usr/bin/ar" --with-alex="/usr/local/bin/alex" --with-happy="/usr/local/bin/happy" Configuring array-0.5.1.0... "C:/msys64/tmp/ghc/inplace/bin/ghc-pkg.exe" update --force libraries/array/dist-install/inplace-pkg-config Reading package info from "libraries/array/dist-install/inplace-pkg-config" ... done. array-0.5.1.0: Warning: haddock-interfaces: C:\msys64\tmp\ghc\libraries\array\dist-install\doc\html\array\array.haddock doesn't exist or isn't a file array-0.5.1.0: cannot find any of ["Data\\Array.hi","Data\\Array.p_hi","Data\\Array.dyn_hi"] (ignoring) array-0.5.1.0: cannot find any of ["Data\\Array\\Base.hi","Data\\Array\\Base.p_hi","Data\\Array\\Base.dyn_hi"] (ignoring) array-0.5.1.0: cannot find any of ["Data\\Array\\IArray.hi","Data\\Array\\IArray.p_hi","Data\\Array\\IArray.dyn_hi"] (ignoring) array-0.5.1.0: cannot find any of ["Data\\Array\\IO.hi","Data\\Array\\IO.p_hi","Data\\Array\\IO.dyn_hi"] (ignoring) array-0.5.1.0: cannot find any of ["Data\\Array\\IO\\Safe.hi","Data\\Array\\IO\\Safe.p_hi","Data\\Array\\IO\\Safe.dyn_hi"] (ignoring) array-0.5.1.0: cannot find any of ["Data\\Array\\IO\\Internals.hi","Data\\Array\\IO\\Internals.p_hi","Data\\Array\\IO\\Internals.dyn_hi"] (ignoring) array-0.5.1.0: cannot find any of ["Data\\Array\\MArray.hi","Data\\Array\\MArray.p_hi","Data\\Array\\MArray.dyn_hi"] (ignoring) array-0.5.1.0: cannot find any of ["Data\\Array\\MArray\\Safe.hi","Data\\Array\\MArray\\Safe.p_hi","Data\\Array\\MArray\\Safe.dyn_hi"] (ignoring) array-0.5.1.0: cannot find any of ["Data\\Array\\ST.hi","Data\\Array\\ST.p_hi","Data\\Array\\ST.dyn_hi"] (ignoring) array-0.5.1.0: cannot find any of ["Data\\Array\\ST\\Safe.hi","Data\\Array\\ST\\Safe.p_hi","Data\\Array\\ST\\Safe.dyn_hi"] (ignoring) array-0.5.1.0: cannot find any of ["Data\\Array\\Storable.hi","Data\\Array\\Storable.p_hi","Data\\Array\\Storable.dyn_hi"] (ignoring) array-0.5.1.0: cannot find any of ["Data\\Array\\Storable\\Safe.hi","Data\\Array\\Storable\\Safe.p_hi","Data\\Array\\Storable\\Safe.dyn_hi"] (ignoring) array-0.5.1.0: cannot find any of ["Data\\Array\\Storable\\Internals.hi","Data\\Array\\Storable\\Internals.p_hi","Data\\Array\\Storable\\Internals.dyn_hi"] (ignoring) array-0.5.1.0: cannot find any of ["Data\\Array\\Unboxed.hi","Data\\Array\\Unboxed.p_hi","Data\\Array\\Unboxed.dyn_hi"] (ignoring) array-0.5.1.0: cannot find any of ["Data\\Array\\Unsafe.hi","Data\\Array\\Unsafe.p_hi","Data\\Array\\Unsafe.dyn_hi"] (ignoring) array-0.5.1.0: cannot find any of ["libHSarray-0.5.1.0-FaHmcBFfuRM8kmZLEY8D5S.a","libHSarray-0.5.1.0-FaHmcBFfuRM8kmZLEY8D5S.p_a","libHSarray-0.5.1.0-FaHmcBFfuRM8kmZLEY8D5S-ghc7.10.1.so","libHSarray-0.5.1.0-FaHmcBFfuRM8kmZLEY8D5S-ghc7.10.1.dylib","HSarray-0.5.1.0-FaHmcBFfuRM8kmZLEY8D5S-ghc7.10.1.dll"] on library path (ignoring) "inplace/bin/ghc-cabal.exe" check libraries/deepseq "inplace/bin/ghc-cabal.exe" configure libraries/deepseq dist-install "" --with-ghc="C:/msys64/tmp/ghc/inplace/bin/ghc-stage1.exe" --with-ghc-pkg="C:/msys64/tmp/ghc/inplace/bin/ghc-pkg.exe" --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --enable-library-profiling --disable-shared --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -fno-stack-protector " --with-gcc="C:/msys64/tmp/ghc/inplace/mingw/bin/gcc.exe" --with-ld="C:/msys64/tmp/ghc/inplace/mingw/bin/ld.exe" --configure-option=--with-cc="C:/msys64/tmp/ghc/inplace/mingw/bin/gcc.exe" --with-ar="/usr/bin/ar" --with-alex="/usr/local/bin/alex" --with-happy="/usr/local/bin/happy" Configuring deepseq-1.4.1.1... "C:/msys64/tmp/ghc/inplace/bin/ghc-pkg.exe" update --force libraries/deepseq/dist-install/inplace-pkg-config Reading package info from "libraries/deepseq/dist-install/inplace-pkg-config" ... done. deepseq-1.4.1.1: Warning: haddock-interfaces: C:\msys64\tmp\ghc\libraries\deepseq\dist-install\doc\html\deepseq\deepseq.haddock doesn't exist or isn't a file deepseq-1.4.1.1: cannot find any of ["Control\\DeepSeq.hi","Control\\DeepSeq.p_hi","Control\\DeepSeq.dyn_hi"] (ignoring) deepseq-1.4.1.1: cannot find any of ["libHSdeepseq-1.4.1.1-FpR4obOZALU1lutWnrBldi.a","libHSdeepseq-1.4.1.1-FpR4obOZALU1lutWnrBldi.p_a","libHSdeepseq-1.4.1.1-FpR4obOZALU1lutWnrBldi-ghc7.10.1.so","libHSdeepseq-1.4.1.1-FpR4obOZALU1lutWnrBldi-ghc7.10.1.dylib","HSdeepseq-1.4.1.1-FpR4obOZALU1lutWnrBldi-ghc7.10.1.dll"] on library path (ignoring) "inplace/bin/ghc-cabal.exe" check libraries/bytestring 'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit and not just imposing longer compile times on your users. libraries/bytestring/ghc.mk:4: recipe for target 'libraries/bytestring/dist-install/package-data.mk' failed make[1]: *** [libraries/bytestring/dist-install/package-data.mk] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Wed Jul 1 04:51:31 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 30 Jun 2015 21:51:31 -0700 Subject: Help Building GHC on Windows to avoid LGPL In-Reply-To: <4a04d738f1954cbe87f00dacc1b76d2b@HQWS-EXMB-01.main.covenanteyes.com> References: <4a04d738f1954cbe87f00dacc1b76d2b@HQWS-EXMB-01.main.covenanteyes.com> Message-ID: <1435726123-sup-877@sabre> Excerpts from Elliot Cameron's message of 2015-06-30 20:19:40 -0700: > "inplace/bin/ghc-cabal.exe" check libraries/bytestring > 'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit and not just imposing longer compile times on your users. > libraries/bytestring/ghc.mk:4: recipe for target 'libraries/bytestring/dist-install/package-data.mk' failed > make[1]: *** [libraries/bytestring/dist-install/package-data.mk] Error 1 > Makefile:71: recipe for target 'all' failed > make: *** [all] Error 2 We fixed this error (it was ghc-cabal not being sufficiently updated to handle some new Cabal behavior) but I'm surprised your build is failing because of it, because 7.10.1's shipped Cabal should not be tickling this bug. You have a few options: 1. Try again with a source distribution, since I suspect your submodules are not in order, or 2. Cherry pick 14652b519eca12411e92c28cd06de32612b0973a onto your branch, which fixes the bug. Edward From jakzale at gmail.com Wed Jul 1 22:14:29 2015 From: jakzale at gmail.com (Jakub Zalewski) Date: Wed, 01 Jul 2015 22:14:29 +0000 Subject: RTS dependency on POSIX signals Message-ID: Dear all, I am working on porting GHC to [native client]( https://developer.chrome.com/native-client) and I am currently trying to figure out how to port the RTS. On POSIX systems RTS seems to depend on two POSIX signals: timer signal and interrupt signal; while native client has very limited POSIX signal support --- for instance it does not define *siginfo_t* (which is referenced in the base package). So far, I know how to deal with the dependency on the timer signal, as while browsing the source code in rts/posix/Itimer.c, I noticed that on iOS the timer is not using POSIX signals to implement the timer signal. I wanted to ask if there are any other POSIX signal dependencies in the RTS, and would it safe to disable any signal handling in the RTS if I know that there will be no interrupt signals sent to the RTS? Best wishes, Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: From elliot.cameron at covenanteyes.com Wed Jul 1 22:41:04 2015 From: elliot.cameron at covenanteyes.com (Elliot Cameron) Date: Wed, 1 Jul 2015 22:41:04 +0000 Subject: Help Building GHC on Windows to avoid LGPL In-Reply-To: <1435726123-sup-877@sabre> References: <4a04d738f1954cbe87f00dacc1b76d2b@HQWS-EXMB-01.main.covenanteyes.com> <1435726123-sup-877@sabre> Message-ID: Thank you very much for the help. So far I have been able to get a 32-bit build to finish, but it is unable to compile anything (I get incorrect register errors). I'll try option #2 that you suggested. In the meantime, would anyone be willing to build 32-bit versions of 7.8.4 and 7.10.1 using integer-simple (for Windows, of course)? Someone has already provided 64-bit builds for both of those releases. It will take me some time to get the hang of this. Once I do, I can start building older and newer versions, although it seems (hopefully!) that the next release might not need this special treatment to get away from integer-gmp. Elliot Cameron -----Original Message----- From: Edward Z. Yang [mailto:ezyang at mit.edu] Sent: Wednesday, July 1, 2015 12:52 AM To: Elliot Cameron Cc: ghc-devs at haskell.org Subject: Re: Help Building GHC on Windows to avoid LGPL Excerpts from Elliot Cameron's message of 2015-06-30 20:19:40 -0700: > "inplace/bin/ghc-cabal.exe" check libraries/bytestring > 'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit and not just imposing longer compile times on your users. > libraries/bytestring/ghc.mk:4: recipe for target > 'libraries/bytestring/dist-install/package-data.mk' failed > make[1]: *** [libraries/bytestring/dist-install/package-data.mk] Error > 1 > Makefile:71: recipe for target 'all' failed > make: *** [all] Error 2 We fixed this error (it was ghc-cabal not being sufficiently updated to handle some new Cabal behavior) but I'm surprised your build is failing because of it, because 7.10.1's shipped Cabal should not be tickling this bug. You have a few options: 1. Try again with a source distribution, since I suspect your submodules are not in order, or 2. Cherry pick 14652b519eca12411e92c28cd06de32612b0973a onto your branch, which fixes the bug. Edward From dagitj at gmail.com Thu Jul 2 03:38:30 2015 From: dagitj at gmail.com (Jason Dagit) Date: Wed, 1 Jul 2015 20:38:30 -0700 Subject: RTS dependency on POSIX signals In-Reply-To: References: Message-ID: On Wed, Jul 1, 2015 at 3:14 PM, Jakub Zalewski wrote: > Dear all, > > I am working on porting GHC to [native client]( > https://developer.chrome.com/native-client) and I am currently trying to > figure out how to port the RTS. > > On POSIX systems RTS seems to depend on two POSIX signals: timer signal > and interrupt signal; while native client has very limited POSIX signal > support --- for instance it does not define *siginfo_t* (which is > referenced in the base package). > > So far, I know how to deal with the dependency on the timer signal, as > while browsing the source code in rts/posix/Itimer.c, I noticed that on iOS > the timer is not using POSIX signals to implement the timer signal. > > I wanted to ask if there are any other POSIX signal dependencies in the > RTS, and would it safe to disable any signal handling in the RTS if I know > that there will be no interrupt signals sent to the RTS? > I don't know the answer to your question, but for an additional data point you might look at the HalVM: https://github.com/galoisinc/halvm For the specific case of timers it may not be helpful (for all I know it uses some xen magic to get a timer interrupt), but it should be similar to native-client support in that the HalVM provides the RTS with a stripped down libc. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakzale at gmail.com Thu Jul 2 20:20:49 2015 From: jakzale at gmail.com (Jakub Zalewski) Date: Thu, 02 Jul 2015 20:20:49 +0000 Subject: Building a minimal/essential GHC Message-ID: Dear all, I am working on porting GHC to [native client]( https://developer.chrome.com/native-client), which has some degree of POSIX-compliance. I was thinking about building just the minimal/most essential parts of GHC that is enough to compile simple Haskell programs. I wanted to ask which parts of GHC are the most essential and sufficient enough to compile a simple Haskell program, for instance to compile `main = putStrLn "Hello, world!"`? I also wanted to ask how to force a GHC build without a particular package that comes by default, for instance how to build GHC without the `unix` package? Best wishes, Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: From awick at galois.com Thu Jul 2 23:07:27 2015 From: awick at galois.com (Adam Wick) Date: Thu, 2 Jul 2015 16:07:27 -0700 Subject: Building a minimal/essential GHC In-Reply-To: References: Message-ID: <635B6500-D9DF-4208-9647-67003B7DD623@galois.com> Hi Jakub - You will find that many of these questions are things we?ve had to address in the HaLVM (http://github.com/GaloisInc/HaLVM ). You may want to look in that code base for information on what we considered minimal and how we got around some of the build system and other issues a minimal build requires. - Adam On Jul 2, 2015, at 1:20 PM, Jakub Zalewski wrote: > > Dear all, > I am working on porting GHC to [native client](https://developer.chrome.com/native-client ), which has some degree of POSIX-compliance. > > I was thinking about building just the minimal/most essential parts of GHC that is enough to compile simple Haskell programs. > > I wanted to ask which parts of GHC are the most essential and sufficient enough to compile a simple Haskell program, for instance to compile `main = putStrLn "Hello, world!"`? > > I also wanted to ask how to force a GHC build without a particular package that comes by default, for instance how to build GHC without the `unix` package? > > Best wishes, > Jakub > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2199 bytes Desc: not available URL: From greg at gregweber.info Fri Jul 3 03:26:44 2015 From: greg at gregweber.info (Greg Weber) Date: Thu, 2 Jul 2015 20:26:44 -0700 Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 1 In-Reply-To: References: Message-ID: Is the 7.10.2 hvr ppa using this RC? We just reported a 7.10 regression that I am hoping will be fixed before the release that I was trying to verify https://ghc.haskell.org/trac/ghc/ticket/10599 On Sun, Jun 14, 2015 at 5:16 PM, Austin Seipp wrote: > We are pleased to announce the first release candidate for GHC 7.10.2: > > https://downloads.haskell.org/~ghc/7.10.2-rc1 > https://downloads.haskell.org/~ghc/7.10.2-rc1/docs/html/ > > This includes the source tarball and bindists for Windows, Mac OS X, > and Debian Linux. FreeBSD and Solaris binaries will follow soon. These > binaries and tarballs have an accompanying SHA256SUMS file signed by > my GPG key id (0x3B58D86F). > > We plan to make the 7.10.2 final release at the end of this coming > week - so please test as much as possible; bugs are much cheaper if we > find them before the release! > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Fri Jul 3 06:49:52 2015 From: austin at well-typed.com (Austin Seipp) Date: Fri, 3 Jul 2015 01:49:52 -0500 Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2 Message-ID: We are pleased to announce the first release candidate for GHC 7.10.2: https://downloads.haskell.org/~ghc/7.10.2-rc2 https://downloads.haskell.org/~ghc/7.10.2-rc2/docs/html/ This includes the source tarball and bindists for Windows, and Debian Linux. FreeBSD, OS X and Solaris binaries will follow soon. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.2 final release in a week or two - so please test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Fri Jul 3 08:09:04 2015 From: austin at well-typed.com (Austin Seipp) Date: Fri, 3 Jul 2015 03:09:04 -0500 Subject: NOTE: Going on a vacation for a while... Message-ID: Hi *, A few weeks ago, as the close of the 7.10.2 release came closer, I decided to take a vacation; one I've needed for a little while now. Well, it's been a bit long in the tooth with the last RC (and my terrible home internet has blocked me for the past day at least) - but that time has come! After the release of 7.10.2 RC2 today, I'm provisionally be "gone" until the end of August. This week is basically done, so I'm mostly going to be gone. I plan on making my return at ICFP 2015, more or less (end of August in Vancouver). I say "gone" with finger quotes, because I will still be around - but not doing GHC stuff every day for work. I am still part of the Haskell.org Infrastructure team, so I'm still going to be around every week. You can still catch me on IRC, email, or elsewhere. I'll just have a higher latency. My laptop will be around. If you have a problem with Phabricator, emails seem to not get delivered, or server instability - please do CC me directly in an email! That'll make sure it hits my inbox so I can at least respond by the next day. I hope to actually fix some infrastructure issues, so again, please do contact me if something is wrong. But for GHC? In particular, for the interim, Ben Gamari, who has recently joined us at Well-Typed, will be filling in for me. Ben has a lot of experience working on GHC and we're happy to have him - he'll be doing the final 7.10.2 release here in a week or two I think, and I'm sure things will go just fine in the mean time after that. Ben is already subscribed to every GHC patch that comes in on Phabricator, so he'll be doing a lot of code review for the things that come through Phabricator. You can keep me on the reviewer list as a habit - you don't need to change anything here. In the aftermath of this after August, I'll return, and Ben and I plan to keep doing our thing together, and we'll all move towards 7.12.1. But in the mean time, I'll be relaxing. I might find some time for a recreational patch or two as well, but we'll see! Thanks * -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From alan.zimm at gmail.com Fri Jul 3 08:15:03 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 3 Jul 2015 10:15:03 +0200 Subject: NOTE: Going on a vacation for a while... In-Reply-To: References: Message-ID: Enjoy the break, I think you've earned it. Alan On Fri, Jul 3, 2015 at 10:09 AM, Austin Seipp wrote: > Hi *, > > A few weeks ago, as the close of the 7.10.2 release came closer, I > decided to take a vacation; one I've needed for a little while now. > Well, it's been a bit long in the tooth with the last RC (and my > terrible home internet has blocked me for the past day at least) - but > that time has come! > > After the release of 7.10.2 RC2 today, I'm provisionally be "gone" > until the end of August. This week is basically done, so I'm mostly > going to be gone. I plan on making my return at ICFP 2015, more or > less (end of August in Vancouver). > > I say "gone" with finger quotes, because I will still be around - but > not doing GHC stuff every day for work. I am still part of the > Haskell.org Infrastructure team, so I'm still going to be around every > week. You can still catch me on IRC, email, or elsewhere. I'll just > have a higher latency. My laptop will be around. > > If you have a problem with Phabricator, emails seem to not get > delivered, or server instability - please do CC me directly in an > email! That'll make sure it hits my inbox so I can at least respond by > the next day. I hope to actually fix some infrastructure issues, so > again, please do contact me if something is wrong. > > But for GHC? In particular, for the interim, Ben Gamari, who has > recently joined us at Well-Typed, will be filling in for me. Ben has a > lot of experience working on GHC and we're happy to have him - he'll > be doing the final 7.10.2 release here in a week or two I think, and > I'm sure things will go just fine in the mean time after that. > > Ben is already subscribed to every GHC patch that comes in on > Phabricator, so he'll be doing a lot of code review for the things > that come through Phabricator. You can keep me on the reviewer list as > a habit - you don't need to change anything here. > > In the aftermath of this after August, I'll return, and Ben and I plan > to keep doing our thing together, and we'll all move towards 7.12.1. > > But in the mean time, I'll be relaxing. I might find some time for a > recreational patch or two as well, but we'll see! > > Thanks * > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Fri Jul 3 16:16:44 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 3 Jul 2015 17:16:44 +0100 Subject: Purely using the parser entry points Message-ID: I've been working with the new parser entry points - they have been very useful. Ostensibly the new parser entry points are pure functions but they require a copy of DynFlags. As far as I can work out there's no pure way to reliably construct DynFlags but it also seems that the Parser doesn't use any of the impure mutable parts of it. This makes it tricky to write pure functions such as "parseExprFromString :: String -> LHsExpr RdrName" which would use some sort of dummy configuration. So far I've tried using "unsafeGlobalDynFlags" which (expectedly) fails occasionally. I've found a more reliable method to be the following which relies on unsafePerformIO. getDynFlags = unsafePerformIO $ GHC.defaultErrorHandler GHC.defaultFatalMessager GHC.defaultFlushOut $ GHC.runGhc (Just libdir) GHC.getSessionDynFlags The question is - is this use of unsafePerformIO safe? Is there a better way to purely initialise a copy of DynFlags? Thanks, Matt From mark.lentczner at gmail.com Fri Jul 3 22:58:18 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Fri, 3 Jul 2015 15:58:18 -0700 Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2 In-Reply-To: References: Message-ID: In concert, Haskell Platform 7.10.2 RC2 is out (for OS X and Linux - Windows on its way). You can find it here: http://www.ozonehouse.com/mark/platform/ Only minor changes since RC1: - version bumps to hashable, HTTP, OpenGLRaw, and cabal-install - closed issues #160 (typography), #157 (add --hoogle flag), #151 (OS X installer issue) sha256 sums: 326e933feb71acc0485c9fa63708505dd78322fbf009712286c5b65ee2374cdf ghc-7.10.1.20150630-x86_64-apple-darwin.tar.bz2 606d458a0809f64933bdf132af42979e4b44209900eea6649caf2927cd449835 haskell-platform-7.10.1.20150630-src.tar.gz 4c25593e04d55e742b60f82c9d8fe2e03490efb6381792198de42789ee817300 haskell-platform-7.10.1.20150630-x86_64-unknown-linux-deb7.tar.gz 1a08b041731a02004eeb21811b83ecca212cd8e2587fe97b472abf8789aef83e Haskell Platform 7.10.1.20150630 64bit-signed.pkg ?? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Fri Jul 3 23:28:40 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Fri, 3 Jul 2015 16:28:40 -0700 Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2 In-Reply-To: References: Message-ID: OS X GHC build has these test failures: Unexpected failures: cabal/sigcabal01 sigcabal01 [bad stderr] (normal) driver/retc001 retc001 [bad stderr] (normal) ffi/should_run T2276_ghci [bad exit code] (ghci) rts linker_unload [bad exit code] (normal) th T10019 [bad stdout] (ghci) th T10279 [stderr mismatch] (normal) typecheck/should_fail T10534 [stderr mismatch] (normal) sigcabal01 looks like tests that depend on generated names or offsets that are just different under OS X retc001 - test looks busted to me: Does GHC now exit with a process error code of non-zero when compilation fails? If so, the Makefile needs fixing. T2276_ghci - looks like -Wignored-attributes broke this test? linker_unload - malloc.h is in malloc/malloc.h under OS X (!) T10019 - magic generated symbol in "golden" test out is wrong: 'a_1627391544' vs. 'a_1627391540' T10279 - panic! (the 'impossible' happened) gual_pkg rts-1.0 T10534 - text message punctation change There were also a bunch of performance deviations - but they were mostly just out of bounds or wildly different (over by 100%.... under by 50%!) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Sat Jul 4 00:24:06 2015 From: jwlato at gmail.com (John Lato) Date: Sat, 04 Jul 2015 00:24:06 +0000 Subject: Abstract FilePath Proposal In-Reply-To: References: <874mlu8nae.fsf@gnu.org> Message-ID: In an ideal world, FilePath would be an abstract type. I think nearly everyone can agree on that. However, it seems every major ghc release includes some major breaking changes. I've spent a lot of time fixing the fallout from them, and this looks much more significant than any we've had in years. In particular, I'm quite scared that people attempted to gauge the fallout by building hackage, but it was too much work. Also consider that private codebases are likely to be impacted significantly (at least the ones I've seen will be). I think it's likely this will cause a major break in the ecosystem, with most packages only supporting old or new style FilePath. I guess my point is, I don't think this proposal should go ahead unless there's significant buy-in from the community (not merely silence or a small majority in favor). I'm not doing much Haskell these days so I'm pretty neutral on it. John L. On Tue, Jun 30, 2015, 2:25 AM Neil Mitchell wrote: > Hi David, > > > One tiny amendment to a comment(!) in the non-normative(!) code in Phase > 3: > > > > data WindowsFilePath = WFP ByteArray# -- UTF16 data > > > > If a Windows file path is valid UTF-16 then it is displayed as such in > the > > GUI, but if not it's still a legal file path. It really is just wchar_t[] > > data. > > Thanks for bringing this up. It's tricky - I think in practice: > > toFilePath x = WPF (encodeStringAsUTF16 x) > > But the data in WPF will be treated as UCS2 (aka wchar_t) when passing > to the API calls, so it's really both. While on Windows NT it really > was UCS2, but Win 7 it's always treated as UTF16 in the GUI, so that > seems to be consistent with what people expect and ensures we don't > throw away information when converting to/from FilePath. Given it > seems you are quite knowledgeable in this area, please shout if that > seems misguided! > > To all the people who are worried about breakage, I can guarantee this > will cause breakage. It's a sad fact, and certainly the main negative > to this proposal. I was on the fence initially when hvr suggested this > change to me, but was convinced by performance and correctness. > Whether the Haskell community as a whole thinks that makes it worth it > is why it's a proposal. If anything, I'm concerned by the lack of > people saying -1, please don't break my code... > > Thanks, Neil > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Sat Jul 4 02:26:17 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 3 Jul 2015 22:26:17 -0400 Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2 In-Reply-To: References: Message-ID: Fixes for the T10019 and T10534 issues are in D1036. Edward Y, the issue around T10279 looks like your territory... And the first four have been failing for me on Mac for a long time (months, at least). I don't know anything about them. Richard On Jul 3, 2015, at 7:28 PM, Mark Lentczner wrote: > OS X GHC build has these test failures: > > Unexpected failures: > cabal/sigcabal01 sigcabal01 [bad stderr] (normal) > driver/retc001 retc001 [bad stderr] (normal) > ffi/should_run T2276_ghci [bad exit code] (ghci) > rts linker_unload [bad exit code] (normal) > th T10019 [bad stdout] (ghci) > th T10279 [stderr mismatch] (normal) > typecheck/should_fail T10534 [stderr mismatch] (normal) > > sigcabal01 looks like tests that depend on generated names or offsets that are just different under OS X > > retc001 - test looks busted to me: Does GHC now exit with a process error code of non-zero when compilation fails? If so, the Makefile needs fixing. > > T2276_ghci - looks like -Wignored-attributes broke this test? > > linker_unload - malloc.h is in malloc/malloc.h under OS X (!) > > T10019 - magic generated symbol in "golden" test out is wrong: 'a_1627391544' vs. 'a_1627391540' > > T10279 - panic! (the 'impossible' happened) gual_pkg rts-1.0 > > T10534 - text message punctation change > > There were also a bunch of performance deviations - but they were mostly just out of bounds or wildly different (over by 100%.... under by 50%!) > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Jul 4 02:28:29 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 3 Jul 2015 22:28:29 -0400 Subject: Abstract FilePath Proposal In-Reply-To: References: <874mlu8nae.fsf@gnu.org> Message-ID: So this goes back to a valid question: What fraction of currently build able hackage breaks with such an Api change, and how complex will fixing those breaks. This should be evaluated. And to what extent can the appropriate migrations be mechanically assisted. Would some of this breakage be mitigated by changing ++ to be monoid or semigroup merge? On Friday, July 3, 2015, John Lato wrote: > In an ideal world, FilePath would be an abstract type. I think nearly > everyone can agree on that. > > However, it seems every major ghc release includes some major breaking > changes. I've spent a lot of time fixing the fallout from them, and this > looks much more significant than any we've had in years. > > In particular, I'm quite scared that people attempted to gauge the fallout > by building hackage, but it was too much work. Also consider that private > codebases are likely to be impacted significantly (at least the ones I've > seen will be). > > I think it's likely this will cause a major break in the ecosystem, with > most packages only supporting old or new style FilePath. > > I guess my point is, I don't think this proposal should go ahead unless > there's significant buy-in from the community (not merely silence or a > small majority in favor). I'm not doing much Haskell these days so I'm > pretty neutral on it. > > John L. > > On Tue, Jun 30, 2015, 2:25 AM Neil Mitchell > wrote: > >> Hi David, >> >> > One tiny amendment to a comment(!) in the non-normative(!) code in >> Phase 3: >> > >> > data WindowsFilePath = WFP ByteArray# -- UTF16 data >> > >> > If a Windows file path is valid UTF-16 then it is displayed as such in >> the >> > GUI, but if not it's still a legal file path. It really is just >> wchar_t[] >> > data. >> >> Thanks for bringing this up. It's tricky - I think in practice: >> >> toFilePath x = WPF (encodeStringAsUTF16 x) >> >> But the data in WPF will be treated as UCS2 (aka wchar_t) when passing >> to the API calls, so it's really both. While on Windows NT it really >> was UCS2, but Win 7 it's always treated as UTF16 in the GUI, so that >> seems to be consistent with what people expect and ensures we don't >> throw away information when converting to/from FilePath. Given it >> seems you are quite knowledgeable in this area, please shout if that >> seems misguided! >> >> To all the people who are worried about breakage, I can guarantee this >> will cause breakage. It's a sad fact, and certainly the main negative >> to this proposal. I was on the fence initially when hvr suggested this >> change to me, but was convinced by performance and correctness. >> Whether the Haskell community as a whole thinks that makes it worth it >> is why it's a proposal. If anything, I'm concerned by the lack of >> people saying -1, please don't break my code... >> >> Thanks, Neil >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sat Jul 4 08:47:09 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 04 Jul 2015 10:47:09 +0200 Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2 In-Reply-To: References: Message-ID: <1435999629.1344.8.camel@joachim-breitner.de> Hi, Am Freitag, den 03.07.2015, 16:28 -0700 schrieb Mark Lentczner: > There were also a bunch of performance deviations - but they were > mostly just out of bounds or wildly different (over by 100%.... under > by 50%!) these have to be ignored for release builds: The expected numbers are to mach the settings of ./validate, which validates with different flags than a release build. There was either a trac ticket or a mailing list thread about this with more details and rationales, and Simon Marlow was participating, but despite this data I cannot find it right now. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Sat Jul 4 09:36:35 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 04 Jul 2015 11:36:35 +0200 Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2 In-Reply-To: <1435999629.1344.8.camel@joachim-breitner.de> References: <1435999629.1344.8.camel@joachim-breitner.de> Message-ID: <1436002595.1344.9.camel@joachim-breitner.de> Hi, Am Samstag, den 04.07.2015, 10:47 +0200 schrieb Joachim Breitner: > these have to be ignored for release builds: The expected numbers are > to mach the settings of ./validate, which validates with different > flags than a release build. > > There was either a trac ticket or a mailing list thread about this > with > more details and rationales, and Simon Marlow was participating, but > despite this data I cannot find it right now. > Thomas found it: https://mail.haskell.org/pipermail/ghc-devs/2014-July/005600.html https://ghc.haskell.org/trac/ghc/ticket/9315#comment:5 Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From izgzhen at gmail.com Sat Jul 4 10:25:14 2015 From: izgzhen at gmail.com (Zhen Zhang) Date: Sat, 4 Jul 2015 18:25:14 +0800 Subject: How to stop the thread from yielding per 20ms? Message-ID: Hi, I am trying to stop the GHC thread scheduler from atomically do round-robin scheduling. It might be strange that I am asking for that, in fact, my intention is to implement the ?Lightweight Concurrency? on top of current RTS system. I am trying to use `GHC.Event`?s timeout mechanism to interfere with the scheduling behavior and it seems working a bit. But the automatic scheduling at the same time by RTS renders this effort invalid. For this part, I have tried to modify `rts/Scheduler.c`, masked some `startTimer` in `schedule()`, change the `appendToQueue` to `pushOnQueue` in `scheduleHandleYield` but nothing really works. (The GHC is still doing RR scheduling, even I changed some key code I thought) So I am curious if anyone familiar with the RTS could give me some suggestions on this problem. Thanks a lot! Zhen -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Sat Jul 4 12:49:40 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sat, 04 Jul 2015 14:49:40 +0200 Subject: Querying the git commit id of GHC snapshots (was: ANNOUNCE: GHC 7.10.2 Release Candidate 1) In-Reply-To: (Greg Weber's message of "Thu, 2 Jul 2015 20:26:44 -0700") References: Message-ID: <87y4iww0ij.fsf_-_@gnu.org> On 2015-07-03 at 05:26:44 +0200, Greg Weber wrote: > Is the 7.10.2 hvr ppa using this RC? ...it's easy to check, as since 7.10 we embed the Git commit id into the source-tarball as well as into the generated ghc binary: $ /opt/ghc/7.10.2/bin/ghc --info | grep Git ,("Project Git commit id","5560861e4562a2e270e6610e6ef3cf120253bb16") or more useful for scripting, i.e. in buildbots (but harder to remember): $ /opt/ghc/7.10.2/bin/ghc --print-project-git-commit-id 5560861e4562a2e270e6610e6ef3cf120253bb16 and if you compare that with the git repo that id *currently* matches the commit pointed to by the lightweight 'ghc-7.10.2-rc2' tag: http://git.haskell.org/ghc.git/shortlog/refs/tags/ghc-7.10.2-rc2 Cheers, hvr From fryguybob at gmail.com Sat Jul 4 14:08:42 2015 From: fryguybob at gmail.com (Ryan Yates) Date: Sat, 4 Jul 2015 10:08:42 -0400 Subject: How to stop the thread from yielding per 20ms? In-Reply-To: References: Message-ID: Hi Zhen, The RTS flag -V sets the tick interval (setting to 0 disables). If you grep for `RtsFlags.MiscFlags.tickInterval` you can find where it gets used. Hope this helps. Ryan On Sat, Jul 4, 2015 at 6:25 AM, Zhen Zhang wrote: > Hi, > > I am trying to stop the GHC thread scheduler from atomically do > round-robin scheduling. It might be strange that I am asking for that, in > fact, my intention is to implement the ?Lightweight Concurrency? on top of > current RTS system. I am trying to use `GHC.Event`?s timeout mechanism to > interfere with the scheduling behavior and it seems working a bit. But the > automatic scheduling at the same time by RTS renders this effort invalid. > > For this part, I have tried to modify `rts/Scheduler.c`, masked some > `startTimer` in `schedule()`, change the `appendToQueue` to `pushOnQueue` > in `scheduleHandleYield` but nothing really works. (The GHC is still doing > RR scheduling, even I changed some key code I thought) > > So I am curious if anyone familiar with the RTS could give me some > suggestions on this problem. > > Thanks a lot! > > Zhen > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Sat Jul 4 17:04:07 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Sat, 04 Jul 2015 10:04:07 -0700 Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2 In-Reply-To: References: Message-ID: <1436029287-sup-7676@sabre> T10279 and sigcabal01 should be harmless; if you want to make the testsuite stop bleating about them you can mark them as failing but please open a bug so we can eventually fix it. I'm currently on vacation and cannot immediately offer fixes. (T10279 ought to work on Mac but I guess something platform specific is poking a non-failable lookup too early so we don't get to give a good error message. Hard to debug without a Mac.) Edward Excerpts from Richard Eisenberg's message of 2015-07-03 19:26:17 -0700: > Fixes for the T10019 and T10534 issues are in D1036. > > Edward Y, the issue around T10279 looks like your territory... > > And the first four have been failing for me on Mac for a long time (months, at least). I don't know anything about them. > > Richard > > On Jul 3, 2015, at 7:28 PM, Mark Lentczner wrote: > > > OS X GHC build has these test failures: > > > > Unexpected failures: > > cabal/sigcabal01 sigcabal01 [bad stderr] (normal) > > driver/retc001 retc001 [bad stderr] (normal) > > ffi/should_run T2276_ghci [bad exit code] (ghci) > > rts linker_unload [bad exit code] (normal) > > th T10019 [bad stdout] (ghci) > > th T10279 [stderr mismatch] (normal) > > typecheck/should_fail T10534 [stderr mismatch] (normal) > > > > sigcabal01 looks like tests that depend on generated names or offsets that are just different under OS X > > > > retc001 - test looks busted to me: Does GHC now exit with a process error code of non-zero when compilation fails? If so, the Makefile needs fixing. > > > > T2276_ghci - looks like -Wignored-attributes broke this test? > > > > linker_unload - malloc.h is in malloc/malloc.h under OS X (!) > > > > T10019 - magic generated symbol in "golden" test out is wrong: 'a_1627391544' vs. 'a_1627391540' > > > > T10279 - panic! (the 'impossible' happened) gual_pkg rts-1.0 > > > > T10534 - text message punctation change > > > > There were also a bunch of performance deviations - but they were mostly just out of bounds or wildly different (over by 100%.... under by 50%!) > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From svenpanne at gmail.com Sat Jul 4 19:26:31 2015 From: svenpanne at gmail.com (Sven Panne) Date: Sat, 4 Jul 2015 21:26:31 +0200 Subject: Abstract FilePath Proposal In-Reply-To: References: <874mlu8nae.fsf@gnu.org> Message-ID: 2015-07-04 4:28 GMT+02:00 Carter Schonwald : > [...] What fraction of currently build able hackage breaks with such an > Api change, and how complex will fixing those breaks. [...] > I think it is highly irrelevant how complex fixing the breakage is, it will probably almost always be trivial, but that's not the point: Think e.g. about a package which didn't really need any update for a few years, its maintainer is inactive (nothing to recently, so that's OK), and which is a transitive dependency of a number of other packages. This will effectively mean lots of broken packages for weeks or even longer. Fixing breakage from the AMP or FTP proposals was trivial, too, but nevertheless a bit painful. This should be evaluated. And to what extent can the appropriate > migrations be mechanically assisted. > Would some of this breakage be mitigated by changing ++ to be monoid or > semigroup merge? > To me the fundamental question which should be answered before any detail question is: Should we go on and continuously break minor things (i.e. basically give up any stability guarantees) or should we collect a bunch of changes first (leaving vital things untouched for that time) and release all those changes together, in longer intervals? That's IMHO a tough question which we somehow avoided to answer up to now. I would like to see a broader discussion like this first, both approaches have their pros and cons, and whatever we do, there should be some kind of consensus behind it. Cheers, S. P.S.: Just for the record: I'm leaning towards the "lots-of-changes-after-a-longer-time" approach, otherwise I see a flood of #ifdefs and tons of failing builds coming our way... :-P -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Jul 4 19:38:25 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 4 Jul 2015 15:38:25 -0400 Subject: Abstract FilePath Proposal In-Reply-To: References: <874mlu8nae.fsf@gnu.org> Message-ID: On Sat, Jul 4, 2015 at 3:26 PM, Sven Panne wrote: > To me the fundamental question which should be answered before any detail > question is: Should we go on and continuously break minor things (i.e. > basically give up any stability guarantees) or should we collect a bunch of > changes first (leaving vital things untouched for that time) and release > all those changes together, in longer intervals? That's IMHO a tough > question which we somehow avoided to answer up to now. I would like to see > a broader discussion like this first, both approaches have their pros and > cons, and whatever we do, there should be some kind of consensus behind it. I recall suggesting something along the lines of stable vs. research ghc releases a few months back. This seems like it would fit in fairly well; the problem is getting buy-in from certain parts of the ecosystem that seem to prefer to build production-oriented packages from research/"unstable" releases. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Sat Jul 4 21:16:53 2015 From: svenpanne at gmail.com (Sven Panne) Date: Sat, 4 Jul 2015 23:16:53 +0200 Subject: Abstract FilePath Proposal In-Reply-To: References: <874mlu8nae.fsf@gnu.org> Message-ID: 2015-07-04 22:48 GMT+02:00 : > I'd argue that Haskell and GHC's history clearly shows we've answered that > question and that overalll we value frequent small breaking changes over > giant change roadblocks like Perl's or Python's. [...] > I'm not sure that "value" is the right word. My impression is more that this somehow happened accidentally and was not the result of careful planning or broad consensus. And even if in the past this might have been the right thing, I consider today's state of affairs as something totally different: In the past it was only GHC, small parts of the language or a handful of packages (or even just a few modules, in the pre-package times). Today every change resonates through thousands of packages on Hackage and elsewhere. IMHO some approach similar to e.g. C++03 => C++11 => C++14 makes more sense in world like this than a constantly fluctuating base, but others might see this differently. My fear is that this will inevitably lead to the necessity of having an autoconf-like feature detection machinery to compile a package, and looking at a few packages, we are already halfway there. :-/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Sat Jul 4 22:17:24 2015 From: spam at scientician.net (Bardur Arantsson) Date: Sun, 5 Jul 2015 00:17:24 +0200 Subject: Abstract FilePath Proposal In-Reply-To: References: <874mlu8nae.fsf@gnu.org> Message-ID: On 07/04/2015 09:38 PM, Brandon Allbery wrote: > On Sat, Jul 4, 2015 at 3:26 PM, Sven Panne wrote: > >> To me the fundamental question which should be answered before any detail >> question is: Should we go on and continuously break minor things (i.e. >> basically give up any stability guarantees) or should we collect a bunch of >> changes first (leaving vital things untouched for that time) and release >> all those changes together, in longer intervals? That's IMHO a tough >> question which we somehow avoided to answer up to now. I would like to see >> a broader discussion like this first, both approaches have their pros and >> cons, and whatever we do, there should be some kind of consensus behind it. > > > I recall suggesting something along the lines of stable vs. research ghc > releases a few months back. This seems like it would fit in fairly well; > the problem is getting buy-in from certain parts of the ecosystem that seem > to prefer to build production-oriented packages from research/"unstable" > releases. > But isn't that effectively just the same as saying: "In our organization we'll be staying with GHC 7.8.x until GHC 7.12.x comes out"? (Or similar, I'm sure you get the point.) Yes, the rest of the ecosystem may move along and use the latest new shiny, but then you can always use the packages that worked with GHC 7.8.x thanks to version ranges. Am I missing something? Regards, From allbery.b at gmail.com Sat Jul 4 22:27:01 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 4 Jul 2015 18:27:01 -0400 Subject: Abstract FilePath Proposal In-Reply-To: References: <874mlu8nae.fsf@gnu.org> Message-ID: On Sat, Jul 4, 2015 at 6:17 PM, Bardur Arantsson wrote: > Yes, the rest of the ecosystem may move along and use the latest new > shiny, but then you can always use the packages that worked with GHC > 7.8.x thanks to version ranges. > > Am I missing something? > Updates needed to fix e.g. security issues, which otherwise might not be backported if others are staying close to current. This is why Stackage has both LTS and Nightly; LTS only works if there's a *commitment* to it, at the level of the community for a community resource or at the level of the provider for something like ghc or Stackage. Note that GHC HQ's response was that they have had problems finding people to keep multiple versions active at the same time; it's a significant job given that backporting (say) a fix to a type system issue allowing unexpectedly unsafe code (say, https://ghc.haskell.org/trac/ghc/ticket/9858) can mean a complete redesign of the patch, if the one in HEAD relies on other changes that can't be sensibly backported. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From izgzhen at gmail.com Sun Jul 5 05:10:26 2015 From: izgzhen at gmail.com (Zhen Zhang) Date: Sun, 5 Jul 2015 13:10:26 +0800 Subject: How to stop the thread from yielding per 20ms? In-Reply-To: References: Message-ID: Hi Ryan, Thank for your help. But it turned out to be not working for me. I even commented out the `startTimer` and `stopTimer` in `rts/Timer.c`, but it seems not working as well. For example. this program: main = do forkIO $ forever $ print ?a? forkIO $ forever $ print ?b? threadDelay 100000 When I added the `-threaded`, it will schedule normally, despite whether I commented out some code or add `-V0`. When I dropped ?`-threaded`, the `timerManager` stopped working as well, so it doesn?t make sense to me. Bad luck, but thank you all the way. Zhen --? Zhen Zhang USTC, China On July 4, 2015 at 10:08:44 PM, Ryan Yates (fryguybob at gmail.com) wrote: Hi Zhen, The RTS flag -V sets the tick interval (setting to 0 disables).? If you grep for `RtsFlags.MiscFlags.tickInterval` you can find where it gets used.? Hope this helps. Ryan On Sat, Jul 4, 2015 at 6:25 AM, Zhen Zhang wrote: Hi, I am trying to stop the GHC thread scheduler from atomically do round-robin scheduling. It might be strange that I am asking for that, in fact, my intention is to implement the ?Lightweight Concurrency? on top of current RTS system. I am trying to use `GHC.Event`?s timeout mechanism to interfere with the scheduling behavior and it seems working a bit. But the automatic scheduling at the same time by RTS renders this effort invalid. For this part, I have tried to modify `rts/Scheduler.c`, masked some `startTimer` in `schedule()`, change the `appendToQueue` to `pushOnQueue` in `scheduleHandleYield` but nothing really works. (The GHC is still doing RR scheduling, even I changed some key code I thought) So I am curious if anyone familiar with the RTS could give me some suggestions on this problem. Thanks a lot! Zhen _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From strake888 at gmail.com Sun Jul 5 18:26:51 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Sun, 5 Jul 2015 10:26:51 -0800 Subject: Abstract FilePath Proposal In-Reply-To: References: <874mlu8nae.fsf@gnu.org> Message-ID: <55997395.441a460a.382c6.ffff9900@mx.google.com> On 04/07/2015 at 21:26:31 +0200, Sven Panne wrote: > To me the fundamental question which should be answered before any detail > question is: Should we go on and continuously break minor things (i.e. > basically give up any stability guarantees) or should we collect a bunch of > changes first (leaving vital things untouched for that time) and release > all those changes together, in longer intervals? That's IMHO a tough > question which we somehow avoided to answer up to now. I would like to see > a broader discussion like this first, both approaches have their pros and > cons, and whatever we do, there should be some kind of consensus behind it. Potentially we ought to await Backpack [0], which should make such transitions easier. [0] http://plv.mpi-sws.org/backpack/ From spam at scientician.net Sun Jul 5 18:25:28 2015 From: spam at scientician.net (Bardur Arantsson) Date: Sun, 5 Jul 2015 20:25:28 +0200 Subject: Abstract FilePath Proposal In-Reply-To: References: <874mlu8nae.fsf@gnu.org> Message-ID: On 07/05/2015 12:27 AM, Brandon Allbery wrote: > On Sat, Jul 4, 2015 at 6:17 PM, Bardur Arantsson > wrote: > >> Yes, the rest of the ecosystem may move along and use the latest new >> shiny, but then you can always use the packages that worked with GHC >> 7.8.x thanks to version ranges. >> >> Am I missing something? >> > > Updates needed to fix e.g. security issues, which otherwise might not be > backported if others are staying close to current. This is why Stackage has > both LTS and Nightly; LTS only works if there's a *commitment* to it, at > the level of the community for a community resource or at the level of the > provider for something like ghc or Stackage. > How often have security issues with GHC (or the base libraries) itself been a problem? (In practice, I mean.) In my hypothetical scenario, there's nothing to prevent a release of GHC 7.8.(x+1) while GHC 7.12. is the new thing. Nor does anything prevent library releases of my-library-1.2.x (security patch) while my-library-1.6.x is the hot new thing. > Note that GHC HQ's response was that they have had problems finding people > to keep multiple versions active at the same time; it's a significant job > given that backporting (say) a fix to a type system issue allowing > unexpectedly unsafe code (say, https://ghc.haskell.org/trac/ghc/ticket/9858) > can mean a complete redesign of the patch, if the one in HEAD relies on > other changes that can't be sensibly backported. > Yes, there's a man-power problem... but that isn't going to be solved unless some people/companies step up to the plate. Preferably the people who are actually using/relying on those old versions. This is no different from e.g. RHEL/Ubuntu LTS/Debian in the Linux world. (Well, except RHEL actually has a revenue stream that means that they can and do support old versions of various things.) Regards, From allbery.b at gmail.com Sun Jul 5 18:40:56 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 5 Jul 2015 14:40:56 -0400 Subject: Abstract FilePath Proposal In-Reply-To: References: <874mlu8nae.fsf@gnu.org> Message-ID: On Sun, Jul 5, 2015 at 2:25 PM, Bardur Arantsson wrote: > How often have security issues with GHC (or the base libraries) itself > been a problem? (In practice, I mean.) > Not that often, but consider one real example: aeson was found to have a DDoS bug which was fixed by making it depend on a package which IIRC needed a newer base, so the fix couldn't be backported to versions of aeson compatible with older base. The necessary fix for those would have been substantially more complicated. (There are other examples, but the primary one that actually involves something shipped with ghc is never going to be fixed until it destroys someone's system, and I bet even then we'll get another load of HOMG MUST NEVER CHANGE API ONLY DOCUMENT AS BAD from the maintainer. I'm still waiting for one of the Linux distributions to notice and CVE it.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Sun Jul 5 19:27:37 2015 From: spam at scientician.net (Bardur Arantsson) Date: Sun, 5 Jul 2015 21:27:37 +0200 Subject: Abstract FilePath Proposal In-Reply-To: References: <874mlu8nae.fsf@gnu.org> Message-ID: On 07/05/2015 08:40 PM, Brandon Allbery wrote: > On Sun, Jul 5, 2015 at 2:25 PM, Bardur Arantsson > wrote: > >> How often have security issues with GHC (or the base libraries) itself >> been a problem? (In practice, I mean.) >> > > Not that often, but consider one real example: aeson was found to have a > DDoS bug which was fixed by making it depend on a package which IIRC needed > a newer base, so the fix couldn't be backported to versions of aeson > compatible with older base. The necessary fix for those would have been > substantially more complicated. > > (There are other examples, but the primary one that actually involves > something shipped with ghc is never going to be fixed until it destroys > someone's system, and I bet even then we'll get another load of HOMG MUST > NEVER CHANGE API ONLY DOCUMENT AS BAD from the maintainer. I'm still > waiting for one of the Linux distributions to notice and CVE it.) > Oh, yeah, that's a valid point... but is this something that should drive design? Further, I don't think the aeson DDoS problem was predicated on an old/obsolete "base" library? Maybe I'm wrong about that, and I'm sure y'all will be happy to point out where and why. :) Regards, From allbery.b at gmail.com Sun Jul 5 19:34:05 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 5 Jul 2015 15:34:05 -0400 Subject: Abstract FilePath Proposal In-Reply-To: References: <874mlu8nae.fsf@gnu.org> Message-ID: On Sun, Jul 5, 2015 at 3:27 PM, Bardur Arantsson wrote: > Further, I don't think the aeson DDoS problem was predicated on an > old/obsolete "base" library? Maybe I'm wrong about that, and I'm sure > y'all will be happy to point out where and why. :) > I may be misremembering, but I thought one of the complaints about aeson adding scientific to its dependencies (to fix the DDoS) was that it required a newer ghc? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Jul 6 09:02:07 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 6 Jul 2015 09:02:07 +0000 Subject: [commit: ghc] master: Use -fno-warn-unused-imports instead of hiding `ord` (c875b08) In-Reply-To: <20150704224355.DBB183A300@ghc.haskell.org> References: <20150704224355.DBB183A300@ghc.haskell.org> Message-ID: <52473ddc591440aaaa8fd74fcb893ee6@DB4PR30MB030.064d.mgd.msft.net> Add a comment, please, I beg you! In five years time no one will have a clue why that `-fno-warn-unused-imports` flag is there. It's a small thing I know, but the principle is: whenever adding a line of code whose purpose is not locally obvious, explain by adding a comment, or Note, or Trac reference, or all three. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf | Of git at git.haskell.org | Sent: 04 July 2015 23:44 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: Use -fno-warn-unused-imports instead of | hiding `ord` (c875b08) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/c875b085d95377771a5b3cf0f44b | b2910dbfe966/ghc | | >--------------------------------------------------------------- | | commit c875b085d95377771a5b3cf0f44bb2910dbfe966 | Author: Thomas Miedema | Date: Sat Jul 4 18:20:06 2015 +0200 | | Use -fno-warn-unused-imports instead of hiding `ord` | | This is more future proof. Maybe later versions of Alex won't | `import | Data.Char (ord)` anymore. | | | >--------------------------------------------------------------- | | c875b085d95377771a5b3cf0f44bb2910dbfe966 | compiler/cmm/CmmLex.x | 3 ++- | compiler/parser/Lexer.x | 3 ++- | 2 files changed, 4 insertions(+), 2 deletions(-) | | diff --git a/compiler/cmm/CmmLex.x b/compiler/cmm/CmmLex.x index | cb71c7d..fca5a1e 100644 | --- a/compiler/cmm/CmmLex.x | +++ b/compiler/cmm/CmmLex.x | @@ -13,6 +13,7 @@ | { | {-# OPTIONS_GHC -fno-warn-unused-matches #-} {-# OPTIONS_GHC -fno- | warn-unused-binds #-} | +{-# OPTIONS_GHC -fno-warn-unused-imports #-} | {-# OPTIONS_GHC -fno-warn-tabs #-} | {-# OPTIONS_GHC -fno-warn-missing-signatures #-} | -- The above warning suppression flags are a temporary kludge. | @@ -37,7 +38,7 @@ import Util | --import TRACE | | import Data.Word | -import Data.Char hiding (ord) | +import Data.Char | } | | $whitechar = [\ \t\n\r\f\v\xa0] -- \xa0 is Unicode no-break space | diff --git a/compiler/parser/Lexer.x b/compiler/parser/Lexer.x index | 8e6e67d..df7347e 100644 | --- a/compiler/parser/Lexer.x | +++ b/compiler/parser/Lexer.x | @@ -45,6 +45,7 @@ | {-# LANGUAGE BangPatterns #-} | {-# OPTIONS_GHC -fno-warn-unused-matches #-} {-# OPTIONS_GHC -fno- | warn-unused-binds #-} | +{-# OPTIONS_GHC -fno-warn-unused-imports #-} | {-# OPTIONS_GHC -fno-warn-tabs #-} | {-# OPTIONS_GHC -fno-warn-missing-signatures #-} {-# OPTIONS_GHC - | fno-warn-overlapping-patterns #-} @@ -84,7 +85,7 @@ import | Control.Applicative #endif import Control.Monad import Data.Bits - | import Data.Char hiding (ord) | +import Data.Char | import Data.List | import Data.Maybe | import Data.Word | | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits From fuuzetsu at fuuzetsu.co.uk Mon Jul 6 16:39:51 2015 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Mon, 06 Jul 2015 17:39:51 +0100 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> Message-ID: <559AAF57.6090305@fuuzetsu.co.uk> On 04/20/2015 05:29 PM, Niklas Hamb?chen wrote: > Hello everybody, > > I'm glad to announce that I performed the suggested backporting as part of > my work for FP Complete! > > With the help of Eric (thanks for your support in #ghc!) we now have this > patch for 7.10 and 7.8. > > As promised, here are the commits: > > * https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip > * https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip > > You can see in the history that I only needed to cherry-pick "Make the > location in TcLclEnv and CtLoc into a RealSrcSpan" as a dependent commit, > so the changes beyond the actual feature are fairly minimal. > > For 7.8, I had to do a little more cleanup, see the "Use wrapIPTc instead > of coercionToTcCoercion on wrapIP" commit. > > Regarding the commit of the feature itself, I had to do quite some merge > resolution, especially due to the (lack of) the -fwarn-redundant- > constraints patch https://github.com/nh2/ghc/commit/32973bf3 (alias "but it > was Christmas, so I did some recreational programming that went much > further"). > However, the type checker had a strong opinion of what the right merge > decision was, at least for the 7.10 backport; for 7.8 there was an > ambiguity (whether to return `Nothing` or `Just` in `interactDict`), which > was resolved with Eric's help. > > Please be invited to review the two commits. > > We would like to make 7.8 and 7.10 binaries with this feature available as > well, and will do so after getting a review! > > Niklas > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > Hi all, In light of how small the actual backported changes are, I wonder if it would be possible to include it in 7.10.2 (or .3 if we're doing that). I know that at first it was rejected but it was rejected before the diff existed. In practice, the only API change was two SrcSpans changing into RealSrcSpans inside the typechecker. Seems like a small price, considering two commercial companies that use Haskell (FP Complete and I'm here on behalf of Zalora's internal team) would love to see it. I know SPJ suggested perhaps lobbying for early 7.12 instead but how early could we possibly lobby for it considering 7.10.2 is not even out of the door yet? Niklas, do you also have a diff on top of 7.10.2 (rc-1/2)? I'd be interested in seeing that too. -- Mateusz K. From mark.lentczner at gmail.com Tue Jul 7 05:26:27 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 6 Jul 2015 22:26:27 -0700 Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2 In-Reply-To: References: Message-ID: And now Windows RC2 for Haksell Platform is also here: http://www.ozonehouse.com/mark/platform/ [1008] : sha256sum HaskellPlatform-7.10.1.20150630-x86_64-setup.exe 6157bbb50de63c1af068f83c4b7888f12b6f29d258bf33dbefb56dd6ea717021 HaskellPlatform-7.10.1.20150630-x86_64-setup.exe? -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Tue Jul 7 08:54:11 2015 From: svenpanne at gmail.com (Sven Panne) Date: Tue, 7 Jul 2015 10:54:11 +0200 Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2 In-Reply-To: References: Message-ID: 2015-07-07 7:26 GMT+02:00 Mark Lentczner : > And now Windows RC2 for Haksell Platform is also here: > > http://www.ozonehouse.com/mark/platform/ > > [...] > I noticed 2 problems so far: * The package cache is still always out of date (I thought there was a fix for that): ---------------------------------------------------------------------- Sven at SCOTTY /d/Repositories/ObjectName (master) $ ghc-pkg list WARNING: cache is out of date: c:/Program Files/Haskell Platform/7.10.2\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. c:/Program Files/Haskell Platform/7.10.2\lib\package.conf.d: Cabal-1.22.4.0 GLURaw-1.5.0.1 GLUT-2.7.0.1 [...] ---------------------------------------------------------------------- * Something is missing/misconfigured for Haddock (note the funny non-local path in the error message): ---------------------------------------------------------------------- Sven at SCOTTY /d/Repositories/ObjectName (master) $ cabal sandbox init Writing a default package environment file to d:\Repositories\ObjectName\cabal.sandbox.config Creating a new sandbox at D:\Repositories\ObjectName\.cabal-sandbox Sven at SCOTTY /d/Repositories/ObjectName (master) $ cabal configure Resolving dependencies... Configuring ObjectName-1.1.0.0... Sven at SCOTTY /d/Repositories/ObjectName (master) $ cabal haddock Running Haddock for ObjectName-1.1.0.0... Preprocessing library ObjectName-1.1.0.0... Haddock coverage: 100% ( 3 / 3) in 'Data.ObjectName' Haddock's resource directory (G:\GitHub\haddock\.cabal-sandbox\x86_64-windows-ghc-7.10.1.20150630\haddock-api-2.16.1) does not exist! ---------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Tue Jul 7 10:55:16 2015 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Tue, 7 Jul 2015 12:55:16 +0200 Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2 In-Reply-To: References: Message-ID: 2015-07-03 8:49 GMT+02:00 Austin Seipp : > We are pleased to announce the first release candidate for GHC 7.10.2: > [..] FreeBSD [..] binaries will follow soon. There you can find the FreeBSD builds, together with their checksums (and sorry for the delay): http://haskell.inf.elte.hu/ghc/ghc-7.10.1.20150630-i386-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/ghc-7.10.1.20150630-i386-portbld-freebsd.tar.xz http://haskell.inf.elte.hu/ghc/ghc-7.10.1.20150630-x86_64-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/ghc-7.10.1.20150630-x86_64-portbld-freebsd.tar.xz http://haskell.inf.elte.hu/ghc/SHA256SUMS And there you can find information on how to use them: http://haskell.inf.elte.hu/ghc/README.html From thomasmiedema at gmail.com Tue Jul 7 10:57:22 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Tue, 7 Jul 2015 12:57:22 +0200 Subject: Right way to turn off dynamic linking in build.mk In-Reply-To: References: Message-ID: On Thu, Dec 18, 2014 at 9:52 AM, Johan Tibell wrote: > > Could someone please give an authoritative answer to how to turn off > dynamic linking? > You set `DYNAMIC_GHC_PROGRAMS = NO` in build.mk. It doesn't matter where you put it. See https://ghc.haskell.org/trac/ghc/ticket/10536 for details. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Tue Jul 7 11:30:15 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Tue, 7 Jul 2015 13:30:15 +0200 Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2 In-Reply-To: References: Message-ID: On Tue, Jul 7, 2015 at 10:54 AM, Sven Panne wrote: > > * The package cache is still always out of date (I thought there was a fix > for that): > Please reopen https://ghc.haskell.org/trac/ghc/ticket/10205 with the output of `which ghc-pkg` and `ghc-pkg list -v`. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Tue Jul 7 11:42:26 2015 From: svenpanne at gmail.com (Sven Panne) Date: Tue, 7 Jul 2015 13:42:26 +0200 Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2 In-Reply-To: References: Message-ID: 2015-07-07 13:30 GMT+02:00 Thomas Miedema : > > > On Tue, Jul 7, 2015 at 10:54 AM, Sven Panne wrote: >> >> * The package cache is still always out of date (I thought there was a >> fix for that): >> > > Please reopen https://ghc.haskell.org/trac/ghc/ticket/10205 with the > output of `which ghc-pkg` and `ghc-pkg list -v`. > Done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakzale at gmail.com Tue Jul 7 14:06:28 2015 From: jakzale at gmail.com (Jakub Zalewski) Date: Tue, 07 Jul 2015 14:06:28 +0000 Subject: Building a minimal/essential GHC In-Reply-To: <635B6500-D9DF-4208-9647-67003B7DD623@galois.com> References: <635B6500-D9DF-4208-9647-67003B7DD623@galois.com> Message-ID: Hi Adam, thank you for your reply; I've looked into HaLVM code and it is really helpful. After disabling some incompatible packages (in a similar fashion to HaLVM) from ghc.mk I got to an issue that configure for ghc stage2 requires those packages. How did you solve that problem in HaLVM? Is it solved by calling parts of the ghc build system from within the top Makefile in the HaLVM repository? Best wishes, Jakub On Fri, Jul 3, 2015 at 12:07 AM Adam Wick wrote: > Hi Jakub - > > You will find that many of these questions are things we?ve had to address > in the HaLVM (http://github.com/GaloisInc/HaLVM). You may want to look in > that code base for information on what we considered minimal and how we got > around some of the build system and other issues a minimal build requires. > > > - Adam > > On Jul 2, 2015, at 1:20 PM, Jakub Zalewski wrote: > > Dear all, > I am working on porting GHC to [native client]( > https://developer.chrome.com/native-client), which has some degree of > POSIX-compliance. > > I was thinking about building just the minimal/most essential parts of GHC > that is enough to compile simple Haskell programs. > > I wanted to ask which parts of GHC are the most essential and sufficient > enough to compile a simple Haskell program, for instance to compile `main = > putStrLn "Hello, world!"`? > > I also wanted to ask how to force a GHC build without a particular package > that comes by default, for instance how to build GHC without the `unix` > package? > > Best wishes, > Jakub > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Jul 8 10:23:29 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 8 Jul 2015 10:23:29 +0000 Subject: Windows broken -- again Message-ID: I get this breakage on Windows. I have no idea who is responsible. Can someone fix? It looks as if throwIOIO really is always unused. Simon utils\ghc-pkg\Main.hs:1982:1: Warning: Defined but not used: 'throwIOIO' -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Jul 8 16:44:32 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 8 Jul 2015 16:44:32 +0000 Subject: 10527/5113 Message-ID: <3bf2ed4b455e4189a275b45c80983d8a@DB4PR30MB030.064d.mgd.msft.net> Ben I have pushed a new fix to the 7.10 branch, onto branch wip/T10572-2. (Don't apply this to HEAD.) Can you try it. I get validate failures as below, but I am hard pressed to see how they could be related. (The perf changes may be.) Simon Unexpected failures: codeGen/should_run T10414 [exit code non-0] (threaded2) driver T8959a [bad stderr] (normal) ghci/scripts T9878b [bad stderr] (ghci) simplCore/should_compile T4945 [bad stdout] (normal) th T10279 [stderr mismatch] (normal) Unexpected stat failures: perf/compiler T9961 [stat too good] (normal) perf/should_run T4830 [stat not good enough] (normal) perf/should_run T7436 [stat not good enough] (normal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Jul 8 22:32:05 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 8 Jul 2015 22:32:05 +0000 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: <559AAF57.6090305@fuuzetsu.co.uk> References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> <559AAF57.6090305@fuuzetsu.co.uk> Message-ID: <8a3d7c92eaea42c49f858c687c1f0639@DB4PR30MB030.064d.mgd.msft.net> I don't have a strong opinion here. I believe that you are saying that: * There is some change you want to make to 7.10.2. I'm not sure precisely what it is. I followed the link and got a github repo with a ton of commits on it. * The change is an API change, which we do not normally make. But you argue that it will harm no one (why are you so sure?), and you are confident that it will not break anything (why?) * FP Complete and Zalora specifically want this change. Zalora = you? Who at FP Complete wants the change? Ben and Herbert are the guys you have to persuade if you really want this. I suspect it'll be more effective to open a ticket, milestoned for 7.10.2, with specifics on it. Email gets lost; tickets don't. Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Mateusz | Kowalczyk | Sent: 06 July 2015 17:40 | To: ghc-devs at haskell.org | Subject: Re: Backporting srcLoc to the GHC 7.10 branch | | On 04/20/2015 05:29 PM, Niklas Hamb?chen wrote: | > Hello everybody, | > | > I'm glad to announce that I performed the suggested backporting as part | of | > my work for FP Complete! | > | > With the help of Eric (thanks for your support in #ghc!) we now have | this | > patch for 7.10 and 7.8. | > | > As promised, here are the commits: | > | > * https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip | > * https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip | > | > You can see in the history that I only needed to cherry-pick "Make the | > location in TcLclEnv and CtLoc into a RealSrcSpan" as a dependent | commit, | > so the changes beyond the actual feature are fairly minimal. | > | > For 7.8, I had to do a little more cleanup, see the "Use wrapIPTc | instead | > of coercionToTcCoercion on wrapIP" commit. | > | > Regarding the commit of the feature itself, I had to do quite some | merge | > resolution, especially due to the (lack of) the -fwarn-redundant- | > constraints patch https://github.com/nh2/ghc/commit/32973bf3 (alias | "but it | > was Christmas, so I did some recreational programming that went much | > further"). | > However, the type checker had a strong opinion of what the right merge | > decision was, at least for the 7.10 backport; for 7.8 there was an | > ambiguity (whether to return `Nothing` or `Just` in `interactDict`), | which | > was resolved with Eric's help. | > | > Please be invited to review the two commits. | > | > We would like to make 7.8 and 7.10 binaries with this feature available | as | > well, and will do so after getting a review! | > | > Niklas | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > | | Hi all, | | In light of how small the actual backported changes are, I wonder if it | would be possible to include it in 7.10.2 (or .3 if we're doing that). I | know that at first it was rejected but it was rejected before the diff | existed. In practice, the only API change was two SrcSpans changing into | RealSrcSpans inside the typechecker. Seems like a small price, | considering two commercial companies that use Haskell (FP Complete and | I'm here on behalf of Zalora's internal team) would love to see it. | | I know SPJ suggested perhaps lobbying for early 7.12 instead but how | early could we possibly lobby for it considering 7.10.2 is not even out | of the door yet? | | Niklas, do you also have a diff on top of 7.10.2 (rc-1/2)? I'd be | interested in seeing that too. | | -- | Mateusz K. | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From awick at galois.com Thu Jul 9 00:32:09 2015 From: awick at galois.com (Adam Wick) Date: Wed, 8 Jul 2015 17:32:09 -0700 Subject: Building a minimal/essential GHC In-Reply-To: References: <635B6500-D9DF-4208-9647-67003B7DD623@galois.com> Message-ID: <1FBB1260-CCFA-42FC-BD9A-8EABD0DA6039@galois.com> Well, for the HaLVM (and maybe native client), a stage2 compiler doesn?t really make sense. So the HaLVM?s compiler is simply a stage1 compiler, somewhat extended. We do some tricks via the top level Makefile, yes, but it?s mostly a standard build for a different target, stopped at the end of the stage1 process. - Adam > On Jul 7, 2015, at 7:06 AM, Jakub Zalewski wrote: > > Hi Adam, > thank you for your reply; I've looked into HaLVM code and it is really helpful. > > After disabling some incompatible packages (in a similar fashion to HaLVM) from ghc.mk I got to an issue that configure for ghc stage2 requires those packages. > > How did you solve that problem in HaLVM? Is it solved by calling parts of the ghc build system from within the top Makefile in the HaLVM repository? > > Best wishes, > Jakub > > > On Fri, Jul 3, 2015 at 12:07 AM Adam Wick > wrote: > Hi Jakub - > > You will find that many of these questions are things we?ve had to address in the HaLVM (http://github.com/GaloisInc/HaLVM ). You may want to look in that code base for information on what we considered minimal and how we got around some of the build system and other issues a minimal build requires. > > > - Adam > > On Jul 2, 2015, at 1:20 PM, Jakub Zalewski > wrote: >> Dear all, >> I am working on porting GHC to [native client](https://developer.chrome.com/native-client ), which has some degree of POSIX-compliance. >> >> I was thinking about building just the minimal/most essential parts of GHC that is enough to compile simple Haskell programs. >> >> I wanted to ask which parts of GHC are the most essential and sufficient enough to compile a simple Haskell program, for instance to compile `main = putStrLn "Hello, world!"`? >> >> I also wanted to ask how to force a GHC build without a particular package that comes by default, for instance how to build GHC without the `unix` package? >> >> Best wishes, >> Jakub > >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2199 bytes Desc: not available URL: From carter.schonwald at gmail.com Fri Jul 10 16:40:33 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 10 Jul 2015 12:40:33 -0400 Subject: validate slow failures on os x 7.10 branch Message-ID: hey all, I ran ./validate on 7.10 branch commit 51de9342b915688f1222760c74b9a63e44c533d3 earlier today heres the summary at the end, are these the expected test failures ? Unexpected results from: TEST="setnumcapabilities001 allocLimit4 conc012 conc034 joao-circular T7861 tcrun023 TH_StaticPointers sigcabal01 readRun004 CgStaticPointers StaticArraySize ghci024 mul2 quotRem2 add2 array001 retc001 dsrun014 DsStaticPointers GcStaticPointers linker_unload ListStaticPointers T7919 retc002 T3245 T2497 T10489 T2276_ghci topHandler03 haddock.Cabal" OVERALL SUMMARY for test run started at Fri Jul 10 12:04:03 2015 EDT 0:27:43 spent to go through 4451 total tests, which gave rise to 17100 test cases, of which 3620 were skipped 306 had missing libraries 12957 expected passes 165 expected failures 0 caused framework failures 0 unexpected passes 51 unexpected failures 1 unexpected stat failures Unexpected failures: ../../libraries/array/tests array001 [exit code non-0] (hpc,optasm,threaded2,dyn,optllvm) ../../libraries/base/tests topHandler03 [bad exit code] (ghci) cabal/sigcabal01 sigcabal01 [bad stderr] (normal) codeGen/should_run CgStaticPointers [bad exit code] (ghci) codeGen/should_run StaticArraySize [bad stdout or stderr] (ghci) concurrent/should_run allocLimit4 [bad exit code] (ghci) concurrent/should_run conc012 [bad exit code] (ghci) concurrent/should_run conc034 [exit code non-0] (optasm,threaded2,dyn,optllvm) concurrent/should_run setnumcapabilities001 [bad stderr] (threaded2) deSugar/should_run DsStaticPointers [bad exit code] (ghci) deSugar/should_run dsrun014 [bad exit code] (ghci) driver/retc001 retc001 [bad exit code] (normal) driver/retc002 retc002 [bad exit code] (normal) ffi/should_run T2276_ghci [bad exit code] (ghci) ghci/scripts ghci024 [bad stdout] (normal) numeric/should_run add2 [bad exit code] (ghci) numeric/should_run mul2 [bad exit code] (ghci) numeric/should_run quotRem2 [bad exit code] (ghci) parser/should_run readRun004 [bad exit code] (ghci) perf/should_run T3245 [bad stdout or stderr] (ghci) programs/joao-circular joao-circular [bad stdout or stderr] (ghci) rts GcStaticPointers [bad exit code] (ghci) rts ListStaticPointers [bad exit code] (ghci) rts T7919 [bad exit code] (optasm,threaded1,dyn,optllvm) rts linker_unload [bad exit code] (normal) th TH_StaticPointers [bad exit code] (ghci) typecheck/should_compile T10489 [exit code non-0] (normal,hpc,optasm,optllvm) typecheck/should_compile T2497 [exit code non-0] (optasm,optllvm) typecheck/should_run T7861 [bad exit code] (normal,hpc,optasm,ghci,threaded1,threaded2,dyn,optllvm) typecheck/should_run tcrun023 [bad stdout or stderr] (ghci) Unexpected stat failures: perf/haddock haddock.Cabal [stat not good enough] (normal) == Start post-testsuite package check Timestamp 2015-07-10 16:04:01 UTC for /Users/v645736/ghc-7.10.2/bindisttest/install dir/lib/ghc-7.10.1.20150710/package.conf.d/package.cache Timestamp 2015-07-10 16:04:01 UTC for /Users/v645736/ghc-7.10.2/bindisttest/install dir/lib/ghc-7.10.1.20150710/package.conf.d (same as cache) using cache: /Users/v645736/ghc-7.10.2/bindisttest/install dir/lib/ghc-7.10.1.20150710/package.conf.d/package.cache db stack: ["/Users/v645736/.ghc/x86_64-darwin-7.10.1.20150710/package.conf.d","/Users/v645736/ghc-7.10.2/bindisttest/install dir/lib/ghc-7.10.1.20150710/package.conf.d"] modifying: Nothing flag db stack: ["/Users/v645736/.ghc/x86_64-darwin-7.10.1.20150710/package.conf.d","/Users/v645736/ghc-7.10.2/bindisttest/install dir/lib/ghc-7.10.1.20150710/package.conf.d"] == End post-testsuite package check -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Fri Jul 10 20:14:46 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Fri, 10 Jul 2015 22:14:46 +0200 Subject: GHC 7.10.2 plans In-Reply-To: <87oajk2hqj.fsf@smart-cactus.org> References: <87oajk2hqj.fsf@smart-cactus.org> Message-ID: <55A027B6.3030405@centrum.cz> Hi Ben, count with me. I always thought it may be a good idea to allow some time to builders to do their job. For me this means few hours for i386/amd64 solaris build and test and unfortunately about a day (~10 hours) of noisy run for sparc solaris build but I'll do it last time since I hope 7.12 will have fixed SPARC NCG which should cut the time to half or I'll buy faster sparc gear. :-) Generally speaking Monday morning is the best time for me. Then Wednesday. Cheers, Karel On 07/10/15 04:46 PM, Ben Gamari wrote: > Hi GHCers, > > So 7.10.2 is, believe it or not, slowly converging. After finding and > fixing a number of regressions since 7.10.1 (including, unfortunately, a > few only found this week), I think we finally have a source tree that > could possibly be called 7.10.2. > > I have been in communication with Herbert, who has built .debs from a > snapshot of the ghc-7.10 branch. They are currently available on his > PPA [1] (see the ghc-7.10.2-7.10.1.20150710-0 debs). Michael will be > using these to do a trial-build of Stackage. Hopefully by Monday we > will have a pretty good idea of whether the tree is fit for release. > > When all of this happens we will be ready to cut the release. As usual, > I will be doing binary builds for 32- and 64-bit Linux and Windows. As I > understand it, a subset of you have in the past offered binary builds > for other platforms, > > * Mark: Mac OS X, some Haskell Platform platforms > * Pali: FreeBSD > * Karel: Solaris > > Would you be willing to do this again? Ideally we would have these > packages available the day of the release. Assuming we can get a final, > Stackage-validated source tarball by Monday, when do you think we could > have all of these prepared? > > I'm willing to hold off announcing the release until late next week or > all of these releases are available, whichever happens first (unless > there is widespread agreement within this group that this is not enough > time). > > Cheers, > > - Ben > > > [1] https://launchpad.net/~hvr/+archive/ubuntu/ghc/ > From george.colpitts at gmail.com Fri Jul 10 20:59:25 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Fri, 10 Jul 2015 17:59:25 -0300 Subject: [GHC] #10627: Regression: cabal install of numeric-prelude hangs In-Reply-To: <060.5e261bea798533ea65f54a65ddac72bd@haskell.org> References: <045.b2e2159c9432fe62a0670e01c485d997@haskell.org> <060.5e261bea798533ea65f54a65ddac72bd@haskell.org> Message-ID: Hello Henning, Brent Do you think you could advance this bug by coming up with a smaller example? I wish I could do it but I think I would be pretty slow at that. Sorry. It would be good if others could see if they can compile numeric-prelude using 7.10.2 on other platforms, i.e. it would be good to know if this bug is specific to the Mac platform. Thanks George On Fri, Jul 10, 2015 at 5:51 PM, GHC wrote: > #10627: Regression: cabal install of numeric-prelude hangs > -------------------------------------+------------------------------------- > Reporter: George | Owner: > Type: bug | Status: new > Priority: high | Milestone: 7.10.2 > Component: Compiler | Version: 7.10.2-rc2 > Resolution: | Keywords: > Operating System: MacOS X | Architecture: > Type of failure: Compile-time | Unknown/Multiple > crash | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Revisions: > -------------------------------------+------------------------------------- > > Comment (by George): > > Sorry, I don't think I can, I will however send mail to the package > maintainer, Henning Thielemann and cc Brent Yorgey whose species package > depends on numeric prelude. I set the priority as high as it seems that > shipping a release that can't compile a package it could previously is not > a good thing. The impact of the bug is not clear. However, I personally > don't need this fix. > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Fri Jul 10 22:47:42 2015 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sat, 11 Jul 2015 07:47:42 +0900 Subject: How to stop the thread from yielding per 20ms? In-Reply-To: References: Message-ID: Hi Zhen, Although you might be resolved, there are some information. In your example code, threads are waiting a MVar for each IO(print). (thread switch by self yield rather than timer-based(preemptive) scheduling) Maybe, these information would be helpful. Parallel and Concurrent Programming in Haskell Chapter 7. Basic Concurrency: Threads and MVars http://chimera.labs.oreilly.com/books/1230000000929/ch07.html The GHC scheduler http://blog.ezyang.com/2013/01/the-ghc-scheduler/ Runtime Support for Multicore Haskell http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/multicore-ghc.pdf Extending the Haskell Foreign Function Interface with Concurrency http://community.haskell.org/~simonmar/papers/conc-ffi.pdf And, ThreadScope and eventlog are here. Parallel and Concurrent Programming in Haskell 15. Debugging, Tuning, and Interfacing with Foreign Code Event Logging and ThreadScope http://chimera.labs.oreilly.com/books/1230000000929/ch15.html#sec_conc_eventlogging ThreadScope https://wiki.haskell.org/ThreadScope So, few image. http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=82 http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=47 Cheers, Takenobu 2015-07-05 14:10 GMT+09:00 Zhen Zhang : > Hi Ryan, > > Thank for your help. But it turned out to be not working for me. I even > commented out the `startTimer` and `stopTimer` in `rts/Timer.c`, but it > seems not working as well. > > For example. this program: > > main = do > forkIO $ forever $ print ?a? > forkIO $ forever $ print ?b? > threadDelay 100000 > > When I added the `-threaded`, it will schedule normally, despite whether I > commented out some code or add `-V0`. When I dropped `-threaded`, the > `timerManager` stopped working as well, so it doesn?t make sense to me. Bad > luck, but thank you all the way. > > Zhen > > -- > Zhen Zhang > USTC, China > > On July 4, 2015 at 10:08:44 PM, Ryan Yates (fryguybob at gmail.com) wrote: > > Hi Zhen, > > The RTS flag -V sets the tick interval (setting to 0 disables). If you > grep for `RtsFlags.MiscFlags.tickInterval` you can find where it gets > used. Hope this helps. > > Ryan > > On Sat, Jul 4, 2015 at 6:25 AM, Zhen Zhang wrote: > >> Hi, >> >> I am trying to stop the GHC thread scheduler from atomically do >> round-robin scheduling. It might be strange that I am asking for that, in >> fact, my intention is to implement the ?Lightweight Concurrency? on top of >> current RTS system. I am trying to use `GHC.Event`?s timeout mechanism to >> interfere with the scheduling behavior and it seems working a bit. But the >> automatic scheduling at the same time by RTS renders this effort invalid. >> >> For this part, I have tried to modify `rts/Scheduler.c`, masked some >> `startTimer` in `schedule()`, change the `appendToQueue` to `pushOnQueue` >> in `scheduleHandleYield` but nothing really works. (The GHC is still doing >> RR scheduling, even I changed some key code I thought) >> >> So I am curious if anyone familiar with the RTS could give me some >> suggestions on this problem. >> >> Thanks a lot! >> >> Zhen >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Sat Jul 11 15:44:41 2015 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Sat, 11 Jul 2015 17:44:41 +0200 Subject: GHC 7.10.2 plans In-Reply-To: <87oajk2hqj.fsf@smart-cactus.org> References: <87oajk2hqj.fsf@smart-cactus.org> Message-ID: Hello Ben, 2015-07-10 16:46 GMT+02:00 Ben Gamari : > Hopefully by Monday we > will have a pretty good idea of whether the tree is fit for release. [..] > As I understand it, a subset of you have in the past offered binary builds > for other platforms [..] > > Would you be willing to do this again? [..] Assuming we can get a final, > Stackage-validated source tarball by Monday, when do you think we could > have all of these prepared? Sure, I can do that for FreeBSD/i386 and FreeBSD/amd64, like I did in the past. Thanks, G?bor From fuuzetsu at fuuzetsu.co.uk Sat Jul 11 18:43:58 2015 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sat, 11 Jul 2015 19:43:58 +0100 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: <8a3d7c92eaea42c49f858c687c1f0639@DB4PR30MB030.064d.mgd.msft.net> References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> <559AAF57.6090305@fuuzetsu.co.uk> <8a3d7c92eaea42c49f858c687c1f0639@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <55A163EE.8000400@fuuzetsu.co.uk> On 07/08/2015 11:32 PM, Simon Peyton Jones wrote: > I don't have a strong opinion here. I believe that you are saying that: > > * There is some change you want to make to 7.10.2. > I'm not sure precisely what it is. I followed the link > and got a github repo with a ton of commits on it. The change would be to put the latest two commits from https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip on top of 7.10 branch. > * The change is an API change, which we do not normally make. > But you argue that it will harm no one (why are you so sure?), > and you are confident that it will not break anything (why?) The API change is precisely at this commit. https://github.com/nh2/ghc/commit/d4e476817a7df449b71a2acc515b4d0fa6f89b6b I never said that it will not harm anyone or that it will not break anything. I only said that it is a small price to pay. The change is your own in the typechecker, a two SrcSpans turning into RealSrcSpans. I think we can agree at least that it is not a large change. I understand if it gets rejected on this basis regardless, I am merely trying my chances. > * FP Complete and Zalora specifically want this change. > Zalora = you? Who at FP Complete wants the change? Some of us at Zalora, yes. This thread of messages was created my FP Complete and they did the backport. They even say that they'll include the changes into their custom build of GHC and ship that to their customers. So it seems like they'd want the change. The very first message in this thread is Michael Snoyman asking if such backport could make it into 7.10. > Ben and Herbert are the guys you have to persuade if you really want this. > I suspect it'll be more effective to open a ticket, milestoned for 7.10.2, > with specifics on it. Email gets lost; tickets don't. Noted, thanks. > Thanks > > Simon > > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Mateusz > | Kowalczyk > | Sent: 06 July 2015 17:40 > | To: ghc-devs at haskell.org > | Subject: Re: Backporting srcLoc to the GHC 7.10 branch > | > | On 04/20/2015 05:29 PM, Niklas Hamb?chen wrote: > | > Hello everybody, > | > > | > I'm glad to announce that I performed the suggested backporting as part > | of > | > my work for FP Complete! > | > > | > With the help of Eric (thanks for your support in #ghc!) we now have > | this > | > patch for 7.10 and 7.8. > | > > | > As promised, here are the commits: > | > > | > * https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip > | > * https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip > | > > | > You can see in the history that I only needed to cherry-pick "Make the > | > location in TcLclEnv and CtLoc into a RealSrcSpan" as a dependent > | commit, > | > so the changes beyond the actual feature are fairly minimal. > | > > | > For 7.8, I had to do a little more cleanup, see the "Use wrapIPTc > | instead > | > of coercionToTcCoercion on wrapIP" commit. > | > > | > Regarding the commit of the feature itself, I had to do quite some > | merge > | > resolution, especially due to the (lack of) the -fwarn-redundant- > | > constraints patch https://github.com/nh2/ghc/commit/32973bf3 (alias > | "but it > | > was Christmas, so I did some recreational programming that went much > | > further"). > | > However, the type checker had a strong opinion of what the right merge > | > decision was, at least for the 7.10 backport; for 7.8 there was an > | > ambiguity (whether to return `Nothing` or `Just` in `interactDict`), > | which > | > was resolved with Eric's help. > | > > | > Please be invited to review the two commits. > | > > | > We would like to make 7.8 and 7.10 binaries with this feature available > | as > | > well, and will do so after getting a review! > | > > | > Niklas > | > > | > _______________________________________________ > | > ghc-devs mailing list > | > ghc-devs at haskell.org > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | > > | > | Hi all, > | > | In light of how small the actual backported changes are, I wonder if it > | would be possible to include it in 7.10.2 (or .3 if we're doing that). I > | know that at first it was rejected but it was rejected before the diff > | existed. In practice, the only API change was two SrcSpans changing into > | RealSrcSpans inside the typechecker. Seems like a small price, > | considering two commercial companies that use Haskell (FP Complete and > | I'm here on behalf of Zalora's internal team) would love to see it. > | > | I know SPJ suggested perhaps lobbying for early 7.12 instead but how > | early could we possibly lobby for it considering 7.10.2 is not even out > | of the door yet? > | > | Niklas, do you also have a diff on top of 7.10.2 (rc-1/2)? I'd be > | interested in seeing that too. > | > | -- > | Mateusz K. > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Mateusz K. From mark.lentczner at gmail.com Sun Jul 12 16:03:53 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 12 Jul 2015 09:03:53 -0700 Subject: Improving the "Get Haskell Experience" Message-ID: *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop shipping pre-built packages, so we banish cabal hell, and have a single common way to 'get Haskell' that just works.* At ICFP '14, there were several long group discussions of the state of "getting Haskell", including Haskell Platform, Stackage, and other approaches. Over the last year, there have been a few more public discussions and evolution on the ideas, and other installer developments. In particular, Stackage's LTS package sets are a direct development from this work, and the release of stack has offered new options. Today, drawing from all this good work and ideas from so many, we'd would like to propose a concrete plan: - Haskell Platform becomes the standard way to get *GHC* and related tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a user-friendly, cross-platform installer that gives a standard way to "get Haskell" for most users. - Use the *stack* model for package installation: - The global db has only the GHC packages - There is a package db for each curated set, Haskell Platform becomes one such set - Projects each have their own package db, much like sandboxes. - Haskell Platform's installer will no longer include pre-built, pre-installed packages other than GHC's set. Instead, it is configured so that *stack* can be used to build and install, on as needed, the corresponding Haskell Platform release packages. We think this plan solves many different community needs: - We have a clear way to "get Haskell" that works for a wide variety of use cases. - HP installer gets much smaller, and about as minimal as a working installation can get. - By leaving most packages out of the global database, users of cabal-install, will now have far fewer problems. Sandbox builds should now never give users "cabal hell" like warnings. - By building and installing the Platform packages into it's own package db, users get the benefit of building and installing these common packages only once per system, yet can easily bypass them for any given project if desired. - Since the Platform packages are now built and installed as needed, installing on smaller systems or servers without OpenGL will work. To do this, we have a bit of work ahead of us: We need to settle on installation layout for each OS (including getting msys into the Windows installer); decide on the naming and versioning of the Platform package set (is it just LTS? does it have a different life cycle? etc...); getting *stack* ready such a distribution; and configuring (or updating) *cabal-install* to support the three-layer package db scheme. We think we can do this in short order. We recognize this represents a significant change for the Platform, and will require buy-in from the various parts, especially *ghc*, *cabal*, and *stack*. We'd like to get your input. - Michael & Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Sun Jul 12 16:19:19 2015 From: gershomb at gmail.com (Gershom B) Date: Sun, 12 Jul 2015 12:19:19 -0400 Subject: Improving the "Get Haskell Experience" In-Reply-To: References: Message-ID: I?m ccing cabal-devel, as that list seems pertinent to this discussion too. In general I?m in favor of unifying efforts such as this. For windows, I?d still like the _option_ to get prebuilt library binaries for the full platform db. The modularity means that they can be just downloaded in a separate folder now, rather than installed into e.g. the global db? If so, that?s a nice win. Here is my motivation ? I tried the minghc installer and it mainly worked, but it played terribly with cygwin, which I use pervasively. So I found myself in a situation where one set of paths worked with cygwin, and the other set of paths let me build the network library. I still have some anxieties about those sorts of issues, and being able to ?just download the binaries? would make me feel a bit safer about at least one workaround should things get too muddled up. If we synchronize LTS and ?platform libs,? then I would like A) some way of distinguishing ?blessed platform libs? from ?other libs in LTS? (to solve the ?curation problem? which has always been a goal of the platform) and B) a standardized release schedule for LTS. (And, of course, I assume this will _not_ be for the platform release upcoming, which is due very shortly, but we?ll have a longer lead time to integrate and shake out all the various issues and test, etc.) ?Gershom On July 12, 2015 at 12:04:22 PM, Mark Lentczner (mark.lentczner at gmail.com) wrote: > *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop > shipping pre-built packages, so we banish cabal hell, and have a single > common way to 'get Haskell' that just works.* > > At ICFP '14, there were several long group discussions of the state of > "getting Haskell", including Haskell Platform, Stackage, and other > approaches. Over the last year, there have been a few more public > discussions and evolution on the ideas, and other installer developments. > In particular, Stackage's LTS package sets are a direct development from > this work, and the release of stack has offered new options. > > Today, drawing from all this good work and ideas from so many, we'd would > like to propose a concrete plan: > > - Haskell Platform becomes the standard way to get *GHC* and related > tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a > user-friendly, cross-platform installer that gives a standard way to "get > Haskell" for most users. > - Use the *stack* model for package installation: > - The global db has only the GHC packages > - There is a package db for each curated set, Haskell Platform > becomes one such set > - Projects each have their own package db, much like sandboxes. > - Haskell Platform's installer will no longer include pre-built, > pre-installed packages other than GHC's set. Instead, it is configured so > that *stack* can be used to build and install, on as needed, the > corresponding Haskell Platform release packages. > > We think this plan solves many different community needs: > > - We have a clear way to "get Haskell" that works for a wide variety of > use cases. > - HP installer gets much smaller, and about as minimal as a working > installation can get. > - By leaving most packages out of the global database, users of > cabal-install, will now have far fewer problems. Sandbox builds should now > never give users "cabal hell" like warnings. > - By building and installing the Platform packages into it's own package > db, users get the benefit of building and installing these common packages > only once per system, yet can easily bypass them for any given project if > desired. > - Since the Platform packages are now built and installed as needed, > installing on smaller systems or servers without OpenGL will work. > > To do this, we have a bit of work ahead of us: We need to settle on > installation layout for each OS (including getting msys into the Windows > installer); decide on the naming and versioning of the Platform package set > (is it just LTS? does it have a different life cycle? etc...); getting > *stack* ready such a distribution; and configuring (or updating) > *cabal-install* to support the three-layer package db scheme. We think we > can do this in short order. > > We recognize this represents a significant change for the Platform, and > will require buy-in from the various parts, especially *ghc*, *cabal*, and > *stack*. We'd like to get your input. > > - Michael & Mark > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From mark.lentczner at gmail.com Sun Jul 12 16:25:48 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 12 Jul 2015 09:25:48 -0700 Subject: Improving the "Get Haskell Experience" In-Reply-To: References: Message-ID: No - we are not talking about the upcoming, 7.10.2 HP release. It would for the next major release after that. Yes, stack has only been out ~1 month, but it has already shown traction in the community, and it has a clear working solution for managing "curated" pacakge sets, like Haskell Platform. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Sun Jul 12 16:26:57 2015 From: michael at snoyman.com (Michael Snoyman) Date: Sun, 12 Jul 2015 16:26:57 +0000 Subject: Improving the "Get Haskell Experience" In-Reply-To: References: Message-ID: I'm +1 on nailing down an LTS release cycle, I've been pushing for it, and planning that it would happen after the first few releases. I'm fine with doing it starting with the next release if that's desired. The cygwin/msys conflict is a problematic one. stack has more flexibility addressing this than MinGHC did, since stack can control the PATH more directly. What we do now is, by default, add msys to the beginning of the PATH, and provide a command line option to not use msys at all. I believe this combination has addressed the bug reports we've received in the past. That's not to say I'm opposed to generating binary databases; I'm actually in favor of having that option for all platforms at some point (there's an open stack issue about it[1]). But it's a significant amount of work, and I think if possible we should defer it until we've figured out initial integration points. [1] https://github.com/commercialhaskell/stack/issues/117 On Sun, Jul 12, 2015 at 9:20 AM Gershom B wrote: > I?m ccing cabal-devel, as that list seems pertinent to this discussion > too. In general I?m in favor of unifying efforts such as this. > > For windows, I?d still like the _option_ to get prebuilt library binaries > for the full platform db. The modularity means that they can be just > downloaded in a separate folder now, rather than installed into e.g. the > global db? If so, that?s a nice win. Here is my motivation ? I tried the > minghc installer and it mainly worked, but it played terribly with cygwin, > which I use pervasively. So I found myself in a situation where one set of > paths worked with cygwin, and the other set of paths let me build the > network library. I still have some anxieties about those sorts of issues, > and being able to ?just download the binaries? would make me feel a bit > safer about at least one workaround should things get too muddled up. > > If we synchronize LTS and ?platform libs,? then I would like A) some way > of distinguishing ?blessed platform libs? from ?other libs in LTS? (to > solve the ?curation problem? which has always been a goal of the platform) > and B) a standardized release schedule for LTS. > > (And, of course, I assume this will _not_ be for the platform release > upcoming, which is due very shortly, but we?ll have a longer lead time to > integrate and shake out all the various issues and test, etc.) > > ?Gershom > > > On July 12, 2015 at 12:04:22 PM, Mark Lentczner (mark.lentczner at gmail.com) > wrote: > > *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop > > shipping pre-built packages, so we banish cabal hell, and have a single > > common way to 'get Haskell' that just works.* > > > > At ICFP '14, there were several long group discussions of the state of > > "getting Haskell", including Haskell Platform, Stackage, and other > > approaches. Over the last year, there have been a few more public > > discussions and evolution on the ideas, and other installer developments. > > In particular, Stackage's LTS package sets are a direct development from > > this work, and the release of stack has offered new options. > > > > Today, drawing from all this good work and ideas from so many, we'd would > > like to propose a concrete plan: > > > > - Haskell Platform becomes the standard way to get *GHC* and related > > tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a > > user-friendly, cross-platform installer that gives a standard way to "get > > Haskell" for most users. > > - Use the *stack* model for package installation: > > - The global db has only the GHC packages > > - There is a package db for each curated set, Haskell Platform > > becomes one such set > > - Projects each have their own package db, much like sandboxes. > > - Haskell Platform's installer will no longer include pre-built, > > pre-installed packages other than GHC's set. Instead, it is configured so > > that *stack* can be used to build and install, on as needed, the > > corresponding Haskell Platform release packages. > > > > We think this plan solves many different community needs: > > > > - We have a clear way to "get Haskell" that works for a wide variety of > > use cases. > > - HP installer gets much smaller, and about as minimal as a working > > installation can get. > > - By leaving most packages out of the global database, users of > > cabal-install, will now have far fewer problems. Sandbox builds should > now > > never give users "cabal hell" like warnings. > > - By building and installing the Platform packages into it's own package > > db, users get the benefit of building and installing these common > packages > > only once per system, yet can easily bypass them for any given project if > > desired. > > - Since the Platform packages are now built and installed as needed, > > installing on smaller systems or servers without OpenGL will work. > > > > To do this, we have a bit of work ahead of us: We need to settle on > > installation layout for each OS (including getting msys into the Windows > > installer); decide on the naming and versioning of the Platform package > set > > (is it just LTS? does it have a different life cycle? etc...); getting > > *stack* ready such a distribution; and configuring (or updating) > > *cabal-install* to support the three-layer package db scheme. We think we > > can do this in short order. > > > > We recognize this represents a significant change for the Platform, and > > will require buy-in from the various parts, especially *ghc*, *cabal*, > and > > *stack*. We'd like to get your input. > > > > - Michael & Mark > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Sun Jul 12 17:13:37 2015 From: michael at snoyman.com (Michael Snoyman) Date: Sun, 12 Jul 2015 17:13:37 +0000 Subject: Improving the "Get Haskell Experience" In-Reply-To: References: Message-ID: I think it depends somewhat on operating system, since there are permissions issues to be dealt with regarding user vs global installation. In principle though: I think the HP installers would install to a non-stack-specific location, and then stack would simply use that GHC based on its inclusion in the PATH. (I'm also guessing this will tie in nicely with Linux distro packages, which would likely want ghc to live in /usr/bin). On Sun, Jul 12, 2015 at 10:11 AM Dan Burton wrote: > Stack has the capability of downloading and installing GHC on demand, as > well as auto-updating itself. Both of these features, by default, occur in > subdirectories of the user's home directory. (Slightly different on Windows > but same idea.) Would the Platform install GHC to the stack location > directly, or install it system-wide as previously? (Stack can still make > use of GHC anywhere on your path.) > > On Sunday, July 12, 2015, Michael Snoyman wrote: > >> I'm +1 on nailing down an LTS release cycle, I've been pushing for it, >> and planning that it would happen after the first few releases. I'm fine >> with doing it starting with the next release if that's desired. >> >> The cygwin/msys conflict is a problematic one. stack has more flexibility >> addressing this than MinGHC did, since stack can control the PATH more >> directly. What we do now is, by default, add msys to the beginning of the >> PATH, and provide a command line option to not use msys at all. I believe >> this combination has addressed the bug reports we've received in the past. >> >> That's not to say I'm opposed to generating binary databases; I'm >> actually in favor of having that option for all platforms at some point >> (there's an open stack issue about it[1]). But it's a significant amount of >> work, and I think if possible we should defer it until we've figured out >> initial integration points. >> >> [1] https://github.com/commercialhaskell/stack/issues/117 >> >> On Sun, Jul 12, 2015 at 9:20 AM Gershom B wrote: >> >>> I?m ccing cabal-devel, as that list seems pertinent to this discussion >>> too. In general I?m in favor of unifying efforts such as this. >>> >>> For windows, I?d still like the _option_ to get prebuilt library >>> binaries for the full platform db. The modularity means that they can be >>> just downloaded in a separate folder now, rather than installed into e.g. >>> the global db? If so, that?s a nice win. Here is my motivation ? I tried >>> the minghc installer and it mainly worked, but it played terribly with >>> cygwin, which I use pervasively. So I found myself in a situation where one >>> set of paths worked with cygwin, and the other set of paths let me build >>> the network library. I still have some anxieties about those sorts of >>> issues, and being able to ?just download the binaries? would make me feel a >>> bit safer about at least one workaround should things get too muddled up. >>> >>> If we synchronize LTS and ?platform libs,? then I would like A) some way >>> of distinguishing ?blessed platform libs? from ?other libs in LTS? (to >>> solve the ?curation problem? which has always been a goal of the platform) >>> and B) a standardized release schedule for LTS. >>> >>> (And, of course, I assume this will _not_ be for the platform release >>> upcoming, which is due very shortly, but we?ll have a longer lead time to >>> integrate and shake out all the various issues and test, etc.) >>> >>> ?Gershom >>> >>> >>> On July 12, 2015 at 12:04:22 PM, Mark Lentczner ( >>> mark.lentczner at gmail.com) wrote: >>> > *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop >>> > shipping pre-built packages, so we banish cabal hell, and have a single >>> > common way to 'get Haskell' that just works.* >>> > >>> > At ICFP '14, there were several long group discussions of the state of >>> > "getting Haskell", including Haskell Platform, Stackage, and other >>> > approaches. Over the last year, there have been a few more public >>> > discussions and evolution on the ideas, and other installer >>> developments. >>> > In particular, Stackage's LTS package sets are a direct development >>> from >>> > this work, and the release of stack has offered new options. >>> > >>> > Today, drawing from all this good work and ideas from so many, we'd >>> would >>> > like to propose a concrete plan: >>> > >>> > - Haskell Platform becomes the standard way to get *GHC* and related >>> > tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a >>> > user-friendly, cross-platform installer that gives a standard way to >>> "get >>> > Haskell" for most users. >>> > - Use the *stack* model for package installation: >>> > - The global db has only the GHC packages >>> > - There is a package db for each curated set, Haskell Platform >>> > becomes one such set >>> > - Projects each have their own package db, much like sandboxes. >>> > - Haskell Platform's installer will no longer include pre-built, >>> > pre-installed packages other than GHC's set. Instead, it is configured >>> so >>> > that *stack* can be used to build and install, on as needed, the >>> > corresponding Haskell Platform release packages. >>> > >>> > We think this plan solves many different community needs: >>> > >>> > - We have a clear way to "get Haskell" that works for a wide variety of >>> > use cases. >>> > - HP installer gets much smaller, and about as minimal as a working >>> > installation can get. >>> > - By leaving most packages out of the global database, users of >>> > cabal-install, will now have far fewer problems. Sandbox builds should >>> now >>> > never give users "cabal hell" like warnings. >>> > - By building and installing the Platform packages into it's own >>> package >>> > db, users get the benefit of building and installing these common >>> packages >>> > only once per system, yet can easily bypass them for any given project >>> if >>> > desired. >>> > - Since the Platform packages are now built and installed as needed, >>> > installing on smaller systems or servers without OpenGL will work. >>> > >>> > To do this, we have a bit of work ahead of us: We need to settle on >>> > installation layout for each OS (including getting msys into the >>> Windows >>> > installer); decide on the naming and versioning of the Platform >>> package set >>> > (is it just LTS? does it have a different life cycle? etc...); getting >>> > *stack* ready such a distribution; and configuring (or updating) >>> > *cabal-install* to support the three-layer package db scheme. We think >>> we >>> > can do this in short order. >>> > >>> > We recognize this represents a significant change for the Platform, and >>> > will require buy-in from the various parts, especially *ghc*, *cabal*, >>> and >>> > *stack*. We'd like to get your input. >>> > >>> > - Michael & Mark >>> > _______________________________________________ >>> > Libraries mailing list >>> > Libraries at haskell.org >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> > >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> -- >> > You received this message because you are subscribed to the Google Groups >> "haskell-stack" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to haskell-stack+unsubscribe at googlegroups.com. >> To post to this group, send email to haskell-stack at googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/haskell-stack/CAKA2JgKYuBMU5wtbjGV72dDKvSJePWbhoZeRCuJYR9SFoV8EDw%40mail.gmail.com >> >> . > > >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > -- Dan Burton > > -- > You received this message because you are subscribed to the Google Groups > "haskell-stack" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-stack+unsubscribe at googlegroups.com. > To post to this group, send email to haskell-stack at googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/haskell-stack/CALSygwfNjyxWFL0y4-_5aSyZZVQSeb5705MzZnaM4Q7GA2MLBg%40mail.gmail.com > > . > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Sun Jul 12 19:08:07 2015 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 12 Jul 2015 21:08:07 +0200 Subject: Improving the "Get Haskell Experience" In-Reply-To: References: Message-ID: 2015-07-12 18:03 GMT+02:00 Mark Lentczner : > > - [...] Haskell Platform becomes the standard way to get *GHC* and > related tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. [...] > > What about haddock? I guess "GHC" implicitly means "haddock", too. Apart from that +1, modulo some minor details which have already been mentioned. -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Sun Jul 12 22:41:05 2015 From: greg at gregweber.info (Greg Weber) Date: Sun, 12 Jul 2015 15:41:05 -0700 Subject: Improving the "Get Haskell Experience" In-Reply-To: <71F7182C-A7DB-47A6-AA1B-940BDDE14F35@gmail.com> References: <71F7182C-A7DB-47A6-AA1B-940BDDE14F35@gmail.com> Message-ID: The main reason I am using stack is for its support for building a project containing multiple packages. There aren't any other tools that make this a first-class concept that is easy to use and not buggy. In addition, stack has a first-class concept of curated package sets. All of these are required to have smooth installs in real world projects, and they aren't likely to appear in cabal-install in a short time frame. On the other hand, stack already has good package distribution. But providing both cabal-install and stack is the right choice that helps keep the Haskell platform relevant and avoid new users having to go through multiple installation steps. On Sun, Jul 12, 2015 at 12:07 PM, wrote: > The HP is a place for tools which have stabilized. A few reasons why I > don't think stack is ready: > > - stack has initial interest from the community, but so did ghc-dev and > hsenv. It's still (imo) in proof of concept stage, and we don't know where > its lessons will ultimately end up. In those other two cases, they ended up > being folded into cabal, which is one likely scenario with stack. > > - There are other solutions on the horizon! There's a GSOC project that > will add nix-style package management to cabal. This should eliminate most > (all?) the cabal hell we know and love, and that's why most stack users are > trying it, no? > > - The HP is for stable apis for users, too -- we provide tools that users > won't have to unlearn or re-learn. Most languages don't have two package > managers! We're clearly in an unstable state, which isn't when we should > add to the HP. > > If 9 months from now stack is clearly the right tool for the job (i.e. > we're considering deprecating cabal), then I'd definitely consider > supporting adding it to the HP but otherwise i'm strongly -1. (If it needs > saying, I don't think stack is a bad tool). > > tl;dr: The dust hasn't settled. Please don't add tools to the HP which we > don't know will be in common use (in their current form) a year from now. > > Tom > > > El Jul 12, 2015, a las 12:25, Mark Lentczner > escribi?: > > > No - we are not talking about the upcoming, 7.10.2 HP release. It would > for the next major release after that. > > > > Yes, stack has only been out ~1 month, but it has already shown traction > in the community, and it has a clear working solution for managing > "curated" pacakge sets, like Haskell Platform. > > ? > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From _deepfire at feelingofgreen.ru Mon Jul 13 07:34:56 2015 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Mon, 13 Jul 2015 10:34:56 +0300 Subject: Improving the "Get Haskell Experience" In-Reply-To: (sfid-20150713_025906_089807_74007A47) (Greg Weber's message of "Sun, 12 Jul 2015 15:41:05 -0700") References: <71F7182C-A7DB-47A6-AA1B-940BDDE14F35@gmail.com> Message-ID: <878uakpl27.fsf@andromedae.feelingofgreen.ru> Greg Weber writes: > The main reason I am using stack is for its support for building a project > containing multiple packages. There aren't any other tools that make this a > first-class concept that is easy to use and not buggy. > In addition, stack has a first-class concept of curated package sets. All of these > are required to have smooth installs in real world projects, and they aren't > likely to appear in cabal-install in a short time frame. The problem that I'm personally facing all too often, is exploratory development, where the modus operandi is to try using versions/branches that are not yet released on Hackage. Things like this happen especially during GHC version transitions, where ghc-new buildability of libraries/tools is often in flux, and so you /have/ to chase the tail (or is it HEAD?). As an example, the version of ghc-mod that works with 7.10 is still unreleased on Cabal -- months passed, the prospects still indefinite. But it also happens out of plain curiosity and willingness to try out how new things could affect the way of problem expression. For an example of that, let's take the 'nokinds' branch of GHC, where Richard Eisenberg does research on formulating GHC with dependent types. Another situation where these things matter especially is collaborative development -- trying to help with bugs, for example. All these things ring of the same, actually.. ..where Hackage puts a mild barrier to sharing small contributions with the world, Stack puts a wall. Which is a good thing. But also a bad one. ..and unless I'm wrong, and we're indeed moving to a world where people would increasingly use Stack, this dichotomy is /bound/ to become more pressing. Curiously, there's a technology to solve to both sides of the story -- Nix, which was mentioned before, but I think its salient point applies especially well to this dichotomy: 1. use the existing curated releases, but also can 2. override packages with a Github fork URL, commit id and the physical checkout hash -- and have everything pick it up in a transparent, fixpoint way. Admittedly it's not been made as trivial to use -- there's more moving parts to factor, and up until now there just wasn't any party seriously interested in doing the user-facing parts. ..And so, I can't help but wonder.. what if the Stack authors would have applied their expertise to provide the same user experience they achieved.. ..but with Nix as an underlying technology? -- respectfully, ??????? ?????? From simonpj at microsoft.com Mon Jul 13 10:15:52 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 13 Jul 2015 10:15:52 +0000 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: <55A163EE.8000400@fuuzetsu.co.uk> References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> <559AAF57.6090305@fuuzetsu.co.uk> <8a3d7c92eaea42c49f858c687c1f0639@DB4PR30MB030.064d.mgd.msft.net> <55A163EE.8000400@fuuzetsu.co.uk> Message-ID: <6960f972d16b4f89adde53c0a83d43a1@DB4PR30MB030.064d.mgd.msft.net> > * There is some change you want to make to 7.10.2. > I'm not sure precisely what it is. | The change would be to put the latest two commits from | | https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip | | on top of 7.10 branch. Aha. Now you say "the top two commits" I can see what you are talking about, namely the entire CallStack feature. Specifically https://github.com/nh2/ghc/commit/5cd10eb4b6eef06f53bbdcfae4b9f8f505ea522c | > * The change is an API change, which we do not normally make. | > But you argue that it will harm no one (why are you so sure?), | > and you are confident that it will not break anything (why?) | | The API change is precisely at this commit. | | https://github.com/nh2/ghc/commit/d4e476817a7df449b71a2acc515b4d0fa6f8 | 9b6b It's much more than that! The main commit (the one you want) adds `CallStack`, `getCallStack` etc, as well as special treatment for implicit parameters of that type. That widens the API, which is certainly less disruptive than changing it. Let's see what Ben and Herbert have to say. Do any other ghc-devs, or Mark or Michael, have an opinion? Simon | | I never said that it will not harm anyone or that it will not break | anything. I only said that it is a small price to pay. | | The change is your own in the typechecker, a two SrcSpans turning into | RealSrcSpans. I think we can agree at least that it is not a large | change. I understand if it gets rejected on this basis regardless, I | am merely trying my chances. | | > * FP Complete and Zalora specifically want this change. | > Zalora = you? Who at FP Complete wants the change? | | Some of us at Zalora, yes. This thread of messages was created my FP | Complete and they did the backport. They even say that they'll include | the changes into their custom build of GHC and ship that to their | customers. So it seems like they'd want the change. The very first | message in this thread is Michael Snoyman asking if such backport | could make it into 7.10. | | > Ben and Herbert are the guys you have to persuade if you really want | this. | > I suspect it'll be more effective to open a ticket, milestoned for | > 7.10.2, with specifics on it. Email gets lost; tickets don't. | | Noted, thanks. | | > Thanks | > | > Simon | > | > | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | > | Mateusz Kowalczyk | > | Sent: 06 July 2015 17:40 | > | To: ghc-devs at haskell.org | > | Subject: Re: Backporting srcLoc to the GHC 7.10 branch | > | | > | On 04/20/2015 05:29 PM, Niklas Hamb?chen wrote: | > | > Hello everybody, | > | > | > | > I'm glad to announce that I performed the suggested backporting | as | > | > part | > | of | > | > my work for FP Complete! | > | > | > | > With the help of Eric (thanks for your support in #ghc!) we now | > | > have | > | this | > | > patch for 7.10 and 7.8. | > | > | > | > As promised, here are the commits: | > | > | > | > * https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc- | ip | > | > * https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip | > | > | > | > You can see in the history that I only needed to cherry-pick | "Make | > | > the location in TcLclEnv and CtLoc into a RealSrcSpan" as a | > | > dependent | > | commit, | > | > so the changes beyond the actual feature are fairly minimal. | > | > | > | > For 7.8, I had to do a little more cleanup, see the "Use | wrapIPTc | > | instead | > | > of coercionToTcCoercion on wrapIP" commit. | > | > | > | > Regarding the commit of the feature itself, I had to do quite | some | > | merge | > | > resolution, especially due to the (lack of) the -fwarn- | redundant- | > | > constraints patch https://github.com/nh2/ghc/commit/32973bf3 | > | > (alias | > | "but it | > | > was Christmas, so I did some recreational programming that went | > | > much further"). | > | > However, the type checker had a strong opinion of what the right | > | > merge decision was, at least for the 7.10 backport; for 7.8 | there | > | > was an ambiguity (whether to return `Nothing` or `Just` in | > | > `interactDict`), | > | which | > | > was resolved with Eric's help. | > | > | > | > Please be invited to review the two commits. | > | > | > | > We would like to make 7.8 and 7.10 binaries with this feature | > | > available | > | as | > | > well, and will do so after getting a review! | > | > | > | > Niklas | > | > | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs at haskell.org | > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > | > | > | | > | Hi all, | > | | > | In light of how small the actual backported changes are, I wonder | if | > | it would be possible to include it in 7.10.2 (or .3 if we're doing | > | that). I know that at first it was rejected but it was rejected | > | before the diff existed. In practice, the only API change was two | > | SrcSpans changing into RealSrcSpans inside the typechecker. Seems | > | like a small price, considering two commercial companies that use | > | Haskell (FP Complete and I'm here on behalf of Zalora's internal | team) would love to see it. | > | | > | I know SPJ suggested perhaps lobbying for early 7.12 instead but | how | > | early could we possibly lobby for it considering 7.10.2 is not | even | > | out of the door yet? | > | | > | Niklas, do you also have a diff on top of 7.10.2 (rc-1/2)? I'd be | > | interested in seeing that too. | > | | > | -- | > | Mateusz K. | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs at haskell.org | > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > | | | -- | Mateusz K. From juhpetersen at gmail.com Mon Jul 13 11:09:29 2015 From: juhpetersen at gmail.com (Jens Petersen) Date: Mon, 13 Jul 2015 20:09:29 +0900 Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2 In-Reply-To: References: Message-ID: On 3 July 2015 at 15:49, Austin Seipp wrote: > We are pleased to announce the first release candidate for GHC 7.10.2: Thanks! I have updated my Fedora Copr 7.10.2 repo to RC2: https://copr.fedoraproject.org/coprs/petersen/ghc-7.10.2 There are builds for Fedora 22 (release) and 23 (devel). Cheers, Jens From allbery.b at gmail.com Mon Jul 13 12:49:58 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 13 Jul 2015 08:49:58 -0400 Subject: Improving the "Get Haskell Experience" In-Reply-To: <878uakpl27.fsf@andromedae.feelingofgreen.ru> References: <71F7182C-A7DB-47A6-AA1B-940BDDE14F35@gmail.com> <878uakpl27.fsf@andromedae.feelingofgreen.ru> Message-ID: On Mon, Jul 13, 2015 at 3:34 AM, Kosyrev Serge <_deepfire at feelingofgreen.ru> wrote: > ..And so, I can't help but wonder.. what if the Stack authors would have > applied their expertise to provide the same user experience they > achieved.. > > ..but with Nix as an underlying technology? > Backpack (very roughly, a Nix-like Cabal package mechanism) is still in development. Once it's out there, perhaps FPComplete will look into using it with Stack? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Mon Jul 13 13:34:58 2015 From: greg at gregweber.info (Greg Weber) Date: Mon, 13 Jul 2015 06:34:58 -0700 Subject: Improving the "Get Haskell Experience" In-Reply-To: <878uakpl27.fsf@andromedae.feelingofgreen.ru> References: <71F7182C-A7DB-47A6-AA1B-940BDDE14F35@gmail.com> <878uakpl27.fsf@andromedae.feelingofgreen.ru> Message-ID: On Mon, Jul 13, 2015 at 12:34 AM, Kosyrev Serge <_deepfire at feelingofgreen.ru > wrote: > Greg Weber writes: > > The main reason I am using stack is for its support for building a > project > > containing multiple packages. There aren't any other tools that make > this a > > first-class concept that is easy to use and not buggy. > > In addition, stack has a first-class concept of curated package sets. > All of these > > are required to have smooth installs in real world projects, and they > aren't > > likely to appear in cabal-install in a short time frame. > > The problem that I'm personally facing all too often, is exploratory > development, where the modus operandi is to try using versions/branches > that are not yet released on Hackage. > > Things like this happen especially during GHC version transitions, where > ghc-new buildability of libraries/tools is often in flux, and so you > /have/ to chase the tail (or is it HEAD?). > > As an example, the version of ghc-mod that works with 7.10 is still > unreleased on Cabal -- months passed, the prospects still indefinite. > > But it also happens out of plain curiosity and willingness to try out > how new things could affect the way of problem expression. > > For an example of that, let's take the 'nokinds' branch of GHC, where > Richard Eisenberg does research on formulating GHC with dependent types. > > Another situation where these things matter especially is collaborative > development -- trying to help with bugs, for example. > > All these things ring of the same, actually.. > > ..where Hackage puts a mild barrier to sharing small contributions with > the world, Stack puts a wall. > I think you are using the wrong terminology. You probably mean to compare "stackage" with "Hackage". But your replly is supposed to be about "stack", which has first-class support for building packages that are not on Hackage as part of your project, including fetching the package from github for you. https://github.com/commercialhaskell/stack/wiki/stack.yaml#project-config > Which is a good thing. > > But also a bad one. > > ..and unless I'm wrong, and we're indeed moving to a world where people > would > increasingly use Stack, this dichotomy is /bound/ to become more pressing. > > Curiously, there's a technology to solve to both sides of the story -- Nix, > which was mentioned before, but I think its salient point applies > especially > well to this dichotomy: > > 1. use the existing curated releases, but also can > 2. override packages with a Github fork URL, commit id and the physical > checkout hash -- and have everything pick it up in a transparent, > fixpoint way. > Again, there is already support for this in stack. Give it a try. > Admittedly it's not been made as trivial to use -- there's more moving > parts to factor, and up until now there just wasn't any party seriously > interested in doing the user-facing parts. > > ..And so, I can't help but wonder.. what if the Stack authors would have > applied their expertise to provide the same user experience they > achieved.. > > ..but with Nix as an underlying technology? > Then stack would be forcing Windows users to use cygwin > > -- > respectfully, > ??????? ?????? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Jul 13 17:32:59 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 13 Jul 2015 17:32:59 +0000 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: <6960f972d16b4f89adde53c0a83d43a1@DB4PR30MB030.064d.mgd.msft.net> References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> <559AAF57.6090305@fuuzetsu.co.uk> <8a3d7c92eaea42c49f858c687c1f0639@DB4PR30MB030.064d.mgd.msft.net> <55A163EE.8000400@fuuzetsu.co.uk> <6960f972d16b4f89adde53c0a83d43a1@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Hi Simon, We had a small pow-wow over here. We're already providing relevant customers with a custom-built GHC, and only using this feature internally to their codebases, so it's not a necessity to get this into upstream GHC 7.10. It would be nice if the library ecosystem could start to add in support for this feature, but on the other hand having it out in the wild ties everyone's hands with improving the feature before the 7.12 release. So put FP Complete down as somewhat ambivalent on whether it should go out. On Mon, Jul 13, 2015 at 3:16 AM Simon Peyton Jones wrote: > > > * There is some change you want to make to 7.10.2. > > I'm not sure precisely what it is. > > | The change would be to put the latest two commits from > | > | https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip > | > | on top of 7.10 branch. > > Aha. Now you say "the top two commits" I can see what you are talking > about, namely the entire CallStack feature. Specifically > https://github.com/nh2/ghc/commit/5cd10eb4b6eef06f53bbdcfae4b9f8f505ea522c > > > | > * The change is an API change, which we do not normally make. > | > But you argue that it will harm no one (why are you so sure?), > | > and you are confident that it will not break anything (why?) > | > | The API change is precisely at this commit. > | > | https://github.com/nh2/ghc/commit/d4e476817a7df449b71a2acc515b4d0fa6f8 > | 9b6b > > It's much more than that! The main commit (the one you want) adds > `CallStack`, `getCallStack` etc, as well as special treatment for implicit > parameters of that type. > > That widens the API, which is certainly less disruptive than changing it. > > > Let's see what Ben and Herbert have to say. > > Do any other ghc-devs, or Mark or Michael, have an opinion? > > Simon > > | > | I never said that it will not harm anyone or that it will not break > | anything. I only said that it is a small price to pay. > | > | The change is your own in the typechecker, a two SrcSpans turning into > | RealSrcSpans. I think we can agree at least that it is not a large > | change. I understand if it gets rejected on this basis regardless, I > | am merely trying my chances. > | > | > * FP Complete and Zalora specifically want this change. > | > Zalora = you? Who at FP Complete wants the change? > | > | Some of us at Zalora, yes. This thread of messages was created my FP > | Complete and they did the backport. They even say that they'll include > | the changes into their custom build of GHC and ship that to their > | customers. So it seems like they'd want the change. The very first > | message in this thread is Michael Snoyman asking if such backport > | could make it into 7.10. > | > | > Ben and Herbert are the guys you have to persuade if you really want > | this. > | > I suspect it'll be more effective to open a ticket, milestoned for > | > 7.10.2, with specifics on it. Email gets lost; tickets don't. > | > | Noted, thanks. > | > | > Thanks > | > > | > Simon > | > > | > > | > | -----Original Message----- > | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | > | Mateusz Kowalczyk > | > | Sent: 06 July 2015 17:40 > | > | To: ghc-devs at haskell.org > | > | Subject: Re: Backporting srcLoc to the GHC 7.10 branch > | > | > | > | On 04/20/2015 05:29 PM, Niklas Hamb?chen wrote: > | > | > Hello everybody, > | > | > > | > | > I'm glad to announce that I performed the suggested backporting > | as > | > | > part > | > | of > | > | > my work for FP Complete! > | > | > > | > | > With the help of Eric (thanks for your support in #ghc!) we now > | > | > have > | > | this > | > | > patch for 7.10 and 7.8. > | > | > > | > | > As promised, here are the commits: > | > | > > | > | > * https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc- > | ip > | > | > * https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip > | > | > > | > | > You can see in the history that I only needed to cherry-pick > | "Make > | > | > the location in TcLclEnv and CtLoc into a RealSrcSpan" as a > | > | > dependent > | > | commit, > | > | > so the changes beyond the actual feature are fairly minimal. > | > | > > | > | > For 7.8, I had to do a little more cleanup, see the "Use > | wrapIPTc > | > | instead > | > | > of coercionToTcCoercion on wrapIP" commit. > | > | > > | > | > Regarding the commit of the feature itself, I had to do quite > | some > | > | merge > | > | > resolution, especially due to the (lack of) the -fwarn- > | redundant- > | > | > constraints patch https://github.com/nh2/ghc/commit/32973bf3 > | > | > (alias > | > | "but it > | > | > was Christmas, so I did some recreational programming that went > | > | > much further"). > | > | > However, the type checker had a strong opinion of what the right > | > | > merge decision was, at least for the 7.10 backport; for 7.8 > | there > | > | > was an ambiguity (whether to return `Nothing` or `Just` in > | > | > `interactDict`), > | > | which > | > | > was resolved with Eric's help. > | > | > > | > | > Please be invited to review the two commits. > | > | > > | > | > We would like to make 7.8 and 7.10 binaries with this feature > | > | > available > | > | as > | > | > well, and will do so after getting a review! > | > | > > | > | > Niklas > | > | > > | > | > _______________________________________________ > | > | > ghc-devs mailing list > | > | > ghc-devs at haskell.org > | > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | > | > > | > | > | > | Hi all, > | > | > | > | In light of how small the actual backported changes are, I wonder > | if > | > | it would be possible to include it in 7.10.2 (or .3 if we're doing > | > | that). I know that at first it was rejected but it was rejected > | > | before the diff existed. In practice, the only API change was two > | > | SrcSpans changing into RealSrcSpans inside the typechecker. Seems > | > | like a small price, considering two commercial companies that use > | > | Haskell (FP Complete and I'm here on behalf of Zalora's internal > | team) would love to see it. > | > | > | > | I know SPJ suggested perhaps lobbying for early 7.12 instead but > | how > | > | early could we possibly lobby for it considering 7.10.2 is not > | even > | > | out of the door yet? > | > | > | > | Niklas, do you also have a diff on top of 7.10.2 (rc-1/2)? I'd be > | > | interested in seeing that too. > | > | > | > | -- > | > | Mateusz K. > | > | _______________________________________________ > | > | ghc-devs mailing list > | > | ghc-devs at haskell.org > | > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | > > | > | > | -- > | Mateusz K. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Jul 13 22:17:07 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 13 Jul 2015 22:17:07 +0000 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> <559AAF57.6090305@fuuzetsu.co.uk> <8a3d7c92eaea42c49f858c687c1f0639@DB4PR30MB030.064d.mgd.msft.net> <55A163EE.8000400@fuuzetsu.co.uk> <6960f972d16b4f89adde53c0a83d43a1@DB4PR30MB030.064d.mgd.msft.net> Message-ID: We (Ben/Herbert/myself/Simon) had a pow-wow too. ? We have a strong bias against making changes late in the release cycle ? And especially ones that change the API at all But on the other hand ? Mateusz did first float this back in mid-April and we didn?t pay enough attention at the time which is making us feel guilty. ? Although nothing is risk free, it seems unlikely to break anything because the changes only have an effect if you import the new module. ? Stackage gives us a pretty good smoke-test for if we?ve broken anything. ? Zalora want this strongly; and FP Complete do mildly. As to the stability of the feature itself, I?ll feel no compunction about changing it a bit in 7.12, say. We often change new features in the light of feedback, and putting it in a release is a way to get people to actually use it and thereby get that feedback. So we decided, strictly without setting a precedent, to try applying the patch to 7.10.2, validating with the usual test suite and Stackage. I hope that?s ok with everyone. Simon From: Michael Snoyman [mailto:michael at snoyman.com] Sent: 13 July 2015 18:33 To: Simon Peyton Jones; Mateusz Kowalczyk; ghc-devs at haskell.org Cc: Mark Lentczner Subject: Re: Backporting srcLoc to the GHC 7.10 branch Hi Simon, We had a small pow-wow over here. We're already providing relevant customers with a custom-built GHC, and only using this feature internally to their codebases, so it's not a necessity to get this into upstream GHC 7.10. It would be nice if the library ecosystem could start to add in support for this feature, but on the other hand having it out in the wild ties everyone's hands with improving the feature before the 7.12 release. So put FP Complete down as somewhat ambivalent on whether it should go out. On Mon, Jul 13, 2015 at 3:16 AM Simon Peyton Jones > wrote: > * There is some change you want to make to 7.10.2. > I'm not sure precisely what it is. | The change would be to put the latest two commits from | | https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip | | on top of 7.10 branch. Aha. Now you say "the top two commits" I can see what you are talking about, namely the entire CallStack feature. Specifically https://github.com/nh2/ghc/commit/5cd10eb4b6eef06f53bbdcfae4b9f8f505ea522c | > * The change is an API change, which we do not normally make. | > But you argue that it will harm no one (why are you so sure?), | > and you are confident that it will not break anything (why?) | | The API change is precisely at this commit. | | https://github.com/nh2/ghc/commit/d4e476817a7df449b71a2acc515b4d0fa6f8 | 9b6b It's much more than that! The main commit (the one you want) adds `CallStack`, `getCallStack` etc, as well as special treatment for implicit parameters of that type. That widens the API, which is certainly less disruptive than changing it. Let's see what Ben and Herbert have to say. Do any other ghc-devs, or Mark or Michael, have an opinion? Simon | | I never said that it will not harm anyone or that it will not break | anything. I only said that it is a small price to pay. | | The change is your own in the typechecker, a two SrcSpans turning into | RealSrcSpans. I think we can agree at least that it is not a large | change. I understand if it gets rejected on this basis regardless, I | am merely trying my chances. | | > * FP Complete and Zalora specifically want this change. | > Zalora = you? Who at FP Complete wants the change? | | Some of us at Zalora, yes. This thread of messages was created my FP | Complete and they did the backport. They even say that they'll include | the changes into their custom build of GHC and ship that to their | customers. So it seems like they'd want the change. The very first | message in this thread is Michael Snoyman asking if such backport | could make it into 7.10. | | > Ben and Herbert are the guys you have to persuade if you really want | this. | > I suspect it'll be more effective to open a ticket, milestoned for | > 7.10.2, with specifics on it. Email gets lost; tickets don't. | | Noted, thanks. | | > Thanks | > | > Simon | > | > | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | > | Mateusz Kowalczyk | > | Sent: 06 July 2015 17:40 | > | To: ghc-devs at haskell.org | > | Subject: Re: Backporting srcLoc to the GHC 7.10 branch | > | | > | On 04/20/2015 05:29 PM, Niklas Hamb?chen wrote: | > | > Hello everybody, | > | > | > | > I'm glad to announce that I performed the suggested backporting | as | > | > part | > | of | > | > my work for FP Complete! | > | > | > | > With the help of Eric (thanks for your support in #ghc!) we now | > | > have | > | this | > | > patch for 7.10 and 7.8. | > | > | > | > As promised, here are the commits: | > | > | > | > * https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc- | ip | > | > * https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip | > | > | > | > You can see in the history that I only needed to cherry-pick | "Make | > | > the location in TcLclEnv and CtLoc into a RealSrcSpan" as a | > | > dependent | > | commit, | > | > so the changes beyond the actual feature are fairly minimal. | > | > | > | > For 7.8, I had to do a little more cleanup, see the "Use | wrapIPTc | > | instead | > | > of coercionToTcCoercion on wrapIP" commit. | > | > | > | > Regarding the commit of the feature itself, I had to do quite | some | > | merge | > | > resolution, especially due to the (lack of) the -fwarn- | redundant- | > | > constraints patch https://github.com/nh2/ghc/commit/32973bf3 | > | > (alias | > | "but it | > | > was Christmas, so I did some recreational programming that went | > | > much further"). | > | > However, the type checker had a strong opinion of what the right | > | > merge decision was, at least for the 7.10 backport; for 7.8 | there | > | > was an ambiguity (whether to return `Nothing` or `Just` in | > | > `interactDict`), | > | which | > | > was resolved with Eric's help. | > | > | > | > Please be invited to review the two commits. | > | > | > | > We would like to make 7.8 and 7.10 binaries with this feature | > | > available | > | as | > | > well, and will do so after getting a review! | > | > | > | > Niklas | > | > | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs at haskell.org | > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > | > | > | | > | Hi all, | > | | > | In light of how small the actual backported changes are, I wonder | if | > | it would be possible to include it in 7.10.2 (or .3 if we're doing | > | that). I know that at first it was rejected but it was rejected | > | before the diff existed. In practice, the only API change was two | > | SrcSpans changing into RealSrcSpans inside the typechecker. Seems | > | like a small price, considering two commercial companies that use | > | Haskell (FP Complete and I'm here on behalf of Zalora's internal | team) would love to see it. | > | | > | I know SPJ suggested perhaps lobbying for early 7.12 instead but | how | > | early could we possibly lobby for it considering 7.10.2 is not | even | > | out of the door yet? | > | | > | Niklas, do you also have a diff on top of 7.10.2 (rc-1/2)? I'd be | > | interested in seeing that too. | > | | > | -- | > | Mateusz K. | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs at haskell.org | > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > | | | -- | Mateusz K. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Tue Jul 14 00:09:52 2015 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 14 Jul 2015 00:09:52 +0000 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> <559AAF57.6090305@fuuzetsu.co.uk> <8a3d7c92eaea42c49f858c687c1f0639@DB4PR30MB030.064d.mgd.msft.net> <55A163EE.8000400@fuuzetsu.co.uk> <6960f972d16b4f89adde53c0a83d43a1@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I'm on board with that, and as always am happy to run as many Stackage builds as necessary, preferably using Herbert's PPAs (which make the process so darn easy). On Mon, Jul 13, 2015 at 3:17 PM Simon Peyton Jones wrote: > We (Ben/Herbert/myself/Simon) had a pow-wow too. > > ? We have a *strong* bias against making changes late in the > release cycle > > ? And especially ones that change the API at all > > But on the other hand > > ? Mateusz did first float this back in mid-April and we didn?t pay > enough attention at the time which is making us feel guilty. > > ? Although nothing is risk free, it seems unlikely to break > anything because the changes only have an effect if you import the new > module. > > ? Stackage gives us a pretty good smoke-test for if we?ve broken > anything. > > ? Zalora want this strongly; and FP Complete do mildly. > > > > As to the stability of the feature itself, I?ll feel no compunction about > changing it a bit in 7.12, say. We often change new features in the light > of feedback, and putting it in a release is a way to get people to actually > use it and thereby get that feedback. > > > > So we decided, *strictly without setting a precedent*, to try applying > the patch to 7.10.2, validating with the usual test suite and Stackage. > > > > I hope that?s ok with everyone. > > > > Simon > > > > *From:* Michael Snoyman [mailto:michael at snoyman.com] > *Sent:* 13 July 2015 18:33 > *To:* Simon Peyton Jones; Mateusz Kowalczyk; ghc-devs at haskell.org > *Cc:* Mark Lentczner > > > *Subject:* Re: Backporting srcLoc to the GHC 7.10 branch > > > > Hi Simon, > > We had a small pow-wow over here. We're already providing relevant > customers with a custom-built GHC, and only using this feature internally > to their codebases, so it's not a necessity to get this into upstream GHC > 7.10. It would be nice if the library ecosystem could start to add in > support for this feature, but on the other hand having it out in the wild > ties everyone's hands with improving the feature before the 7.12 release. > > So put FP Complete down as somewhat ambivalent on whether it should go out. > > > > On Mon, Jul 13, 2015 at 3:16 AM Simon Peyton Jones > wrote: > > > > * There is some change you want to make to 7.10.2. > > I'm not sure precisely what it is. > > | The change would be to put the latest two commits from > | > | https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip > | > | on top of 7.10 branch. > > Aha. Now you say "the top two commits" I can see what you are talking > about, namely the entire CallStack feature. Specifically > https://github.com/nh2/ghc/commit/5cd10eb4b6eef06f53bbdcfae4b9f8f505ea522c > > > | > * The change is an API change, which we do not normally make. > | > But you argue that it will harm no one (why are you so sure?), > | > and you are confident that it will not break anything (why?) > | > | The API change is precisely at this commit. > | > | https://github.com/nh2/ghc/commit/d4e476817a7df449b71a2acc515b4d0fa6f8 > | 9b6b > > It's much more than that! The main commit (the one you want) adds > `CallStack`, `getCallStack` etc, as well as special treatment for implicit > parameters of that type. > > That widens the API, which is certainly less disruptive than changing it. > > > Let's see what Ben and Herbert have to say. > > Do any other ghc-devs, or Mark or Michael, have an opinion? > > Simon > > | > | I never said that it will not harm anyone or that it will not break > | anything. I only said that it is a small price to pay. > | > | The change is your own in the typechecker, a two SrcSpans turning into > | RealSrcSpans. I think we can agree at least that it is not a large > | change. I understand if it gets rejected on this basis regardless, I > | am merely trying my chances. > | > | > * FP Complete and Zalora specifically want this change. > | > Zalora = you? Who at FP Complete wants the change? > | > | Some of us at Zalora, yes. This thread of messages was created my FP > | Complete and they did the backport. They even say that they'll include > | the changes into their custom build of GHC and ship that to their > | customers. So it seems like they'd want the change. The very first > | message in this thread is Michael Snoyman asking if such backport > | could make it into 7.10. > | > | > Ben and Herbert are the guys you have to persuade if you really want > | this. > | > I suspect it'll be more effective to open a ticket, milestoned for > | > 7.10.2, with specifics on it. Email gets lost; tickets don't. > | > | Noted, thanks. > | > | > Thanks > | > > | > Simon > | > > | > > | > | -----Original Message----- > | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | > | Mateusz Kowalczyk > | > | Sent: 06 July 2015 17:40 > | > | To: ghc-devs at haskell.org > | > | Subject: Re: Backporting srcLoc to the GHC 7.10 branch > | > | > | > | On 04/20/2015 05:29 PM, Niklas Hamb?chen wrote: > | > | > Hello everybody, > | > | > > | > | > I'm glad to announce that I performed the suggested backporting > | as > | > | > part > | > | of > | > | > my work for FP Complete! > | > | > > | > | > With the help of Eric (thanks for your support in #ghc!) we now > | > | > have > | > | this > | > | > patch for 7.10 and 7.8. > | > | > > | > | > As promised, here are the commits: > | > | > > | > | > * https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc- > | ip > | > | > * https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip > | > | > > | > | > You can see in the history that I only needed to cherry-pick > | "Make > | > | > the location in TcLclEnv and CtLoc into a RealSrcSpan" as a > | > | > dependent > | > | commit, > | > | > so the changes beyond the actual feature are fairly minimal. > | > | > > | > | > For 7.8, I had to do a little more cleanup, see the "Use > | wrapIPTc > | > | instead > | > | > of coercionToTcCoercion on wrapIP" commit. > | > | > > | > | > Regarding the commit of the feature itself, I had to do quite > | some > | > | merge > | > | > resolution, especially due to the (lack of) the -fwarn- > | redundant- > | > | > constraints patch https://github.com/nh2/ghc/commit/32973bf3 > | > | > (alias > | > | "but it > | > | > was Christmas, so I did some recreational programming that went > | > | > much further"). > | > | > However, the type checker had a strong opinion of what the right > | > | > merge decision was, at least for the 7.10 backport; for 7.8 > | there > | > | > was an ambiguity (whether to return `Nothing` or `Just` in > | > | > `interactDict`), > | > | which > | > | > was resolved with Eric's help. > | > | > > | > | > Please be invited to review the two commits. > | > | > > | > | > We would like to make 7.8 and 7.10 binaries with this feature > | > | > available > | > | as > | > | > well, and will do so after getting a review! > | > | > > | > | > Niklas > | > | > > | > | > _______________________________________________ > | > | > ghc-devs mailing list > | > | > ghc-devs at haskell.org > | > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | > | > > | > | > | > | Hi all, > | > | > | > | In light of how small the actual backported changes are, I wonder > | if > | > | it would be possible to include it in 7.10.2 (or .3 if we're doing > | > | that). I know that at first it was rejected but it was rejected > | > | before the diff existed. In practice, the only API change was two > | > | SrcSpans changing into RealSrcSpans inside the typechecker. Seems > | > | like a small price, considering two commercial companies that use > | > | Haskell (FP Complete and I'm here on behalf of Zalora's internal > | team) would love to see it. > | > | > | > | I know SPJ suggested perhaps lobbying for early 7.12 instead but > | how > | > | early could we possibly lobby for it considering 7.10.2 is not > | even > | > | out of the door yet? > | > | > | > | Niklas, do you also have a diff on top of 7.10.2 (rc-1/2)? I'd be > | > | interested in seeing that too. > | > | > | > | -- > | > | Mateusz K. > | > | _______________________________________________ > | > | ghc-devs mailing list > | > | ghc-devs at haskell.org > | > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | > > | > | > | -- > | Mateusz K. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Jul 14 08:00:44 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 14 Jul 2015 10:00:44 +0200 Subject: Travis failures Message-ID: <1436860844.1390.16.camel@joachim-breitner.de> Hi, I don?t recall when it was the last time that we had a passing build on travis, so I had a look what?s wrong, and to my surprise the problem was not a build timeout, but rather two failing test cases: Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150713 for x86_64-unknown-linux): Static flags have not been initialised! Please call GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[3]: *** [T10294] Error 1 *** unexpected failure for T10294(normal) and: Actual stderr output differs from expected: --- ./th/T10596.stderr.normalised 2015-07-13 19:47:37.667428464 +0000 +++ ./th/T10596.comp.stderr.normalised 2015-07-13 19:47:37.667428464 +0000 @@ -1 +0,0 @@ -Just 100 \ No newline at end of file *** unexpected failure for T10596(normal) Full log at https://s3.amazonaws.com/archive.travis-ci.org/jobs/70789702/log.txt Does anyone have any idea about these? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Tue Jul 14 21:01:21 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 14 Jul 2015 21:01:21 +0000 Subject: Can't build on Windows Message-ID: I've just cloned GHC, on Windows and typed "sh validate". But it dies as below. And indeed the directory ghc-tarballs doesn't exist. Should it? How do I get it? Thanks Simon Target platform inferred as: i386-unknown-mingw32 GHC build : i386-unknown-mingw32 GHC host : i386-unknown-mingw32 GHC target : i386-unknown-mingw32 configure: Building in-tree ghc-pwd checking for path to top of build tree... C:/code/ghc-injective configure: Making in-tree mingw tree tar (child): ../../ghc-tarballs/mingw/binutils*.tar.lzma: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now ./configure: line 4217: inplace/mingw/bin/realgcc.exe: No such file or directory configure: In-tree mingw tree created -------------- next part -------------- An HTML attachment was scrubbed... URL: From stegeman at gmail.com Tue Jul 14 22:29:41 2015 From: stegeman at gmail.com (Luite Stegeman) Date: Tue, 14 Jul 2015 22:29:41 +0000 Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2 In-Reply-To: References: Message-ID: On Fri, Jul 3, 2015 at 8:49 AM Austin Seipp wrote: > We are pleased to announce the first release candidate for GHC 7.10.2: > > I found out earlier today that Template Haskell support for the prim and javascript calling conventions (new in 7.10) was still missing a few cases, mainly breaking JS imports by treating/checking them as C identifiers. Trac #10638 (attached patch backported to 7.10), Phab D1070 (master). Also see: https://github.com/ghcjs/ghcjs/issues/364 I hope it's still in time to make it into the final. luite -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Tue Jul 14 23:07:22 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Wed, 15 Jul 2015 01:07:22 +0200 Subject: Can't build on Windows In-Reply-To: References: Message-ID: I?ve just cloned GHC, on Windows and typed ?sh validate?. But it dies as > below. And indeed the directory ghc-tarballs doesn?t exist. Should it? > How do I get it? > git clone git://git.haskell.org/ghc-tarballs.git As described on the wiki: https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#CloningHEAD There is an unfinished patch to make that step unnecessary: https://phabricator.haskell.org/D339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Jul 15 08:29:39 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 15 Jul 2015 08:29:39 +0000 Subject: Can't build on Windows In-Reply-To: References: Message-ID: <6d7c5148d54c4b31a6d8f4c824f00a01@DB4PR30MB030.064d.mgd.msft.net> Ah, thank you! Simon From: Thomas Miedema [mailto:thomasmiedema at gmail.com] Sent: 15 July 2015 00:07 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: Can't build on Windows I?ve just cloned GHC, on Windows and typed ?sh validate?. But it dies as below. And indeed the directory ghc-tarballs doesn?t exist. Should it? How do I get it? git clone git://git.haskell.org/ghc-tarballs.git As described on the wiki: https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#CloningHEAD There is an unfinished patch to make that step unnecessary: https://phabricator.haskell.org/D339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Wed Jul 15 09:41:47 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 15 Jul 2015 11:41:47 +0200 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> <559AAF57.6090305@fuuzetsu.co.uk> <8a3d7c92eaea42c49f858c687c1f0639@DB4PR30MB030.064d.mgd.msft.net> <55A163EE.8000400@fuuzetsu.co.uk> <6960f972d16b4f89adde53c0a83d43a1@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87oajd69lw.fsf@smart-cactus.org> Michael Snoyman writes: > Hi Simon, > > We had a small pow-wow over here. We're already providing relevant > customers with a custom-built GHC, and only using this feature internally > to their codebases, so it's not a necessity to get this into upstream GHC > 7.10. It would be nice if the library ecosystem could start to add in > support for this feature, but on the other hand having it out in the wild > ties everyone's hands with improving the feature before the 7.12 release. > > So put FP Complete down as somewhat ambivalent on whether it should go out. > Hi Michael, We also had a pow-wow yesterday and decided that it would be fairly harmless to merge the change for 7.10.2 (but reserve the right to vehemently enforce the usual no-new-features-or-interfaces-in-minor-releases policy in the future). However, do you suppose it would be possible to run one more Stackage build just to ensure that this (and a couple of other straggling patches that were recently merged) doesn't break anything? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at smart-cactus.org Wed Jul 15 09:46:01 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 15 Jul 2015 11:46:01 +0200 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: <87oajd69lw.fsf@smart-cactus.org> References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> <559AAF57.6090305@fuuzetsu.co.uk> <8a3d7c92eaea42c49f858c687c1f0639@DB4PR30MB030.064d.mgd.msft.net> <55A163EE.8000400@fuuzetsu.co.uk> <6960f972d16b4f89adde53c0a83d43a1@DB4PR30MB030.064d.mgd.msft.net> <87oajd69lw.fsf@smart-cactus.org> Message-ID: <87k2u169eu.fsf@smart-cactus.org> Ben Gamari writes: > Michael Snoyman writes: > >> Hi Simon, >> >> We had a small pow-wow over here. We're already providing relevant >> customers with a custom-built GHC, and only using this feature internally >> to their codebases, so it's not a necessity to get this into upstream GHC >> 7.10. It would be nice if the library ecosystem could start to add in >> support for this feature, but on the other hand having it out in the wild >> ties everyone's hands with improving the feature before the 7.12 release. >> >> So put FP Complete down as somewhat ambivalent on whether it should go out. >> Ahh, I just saw the messages sent yesterday. Michael, thanks for the offer of further Stackage smoke-tests. Herbert, do you suppose you could let Michael know when the PPA builds are available. I'll be preparing a source distribution for limited release to the packagers soon. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mail at joachim-breitner.de Wed Jul 15 14:52:00 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 15 Jul 2015 16:52:00 +0200 Subject: Travis failures In-Reply-To: <1436860844.1390.16.camel@joachim-breitner.de> References: <1436860844.1390.16.camel@joachim-breitner.de> Message-ID: <1436971920.1327.2.camel@joachim-breitner.de> Hi, Am Dienstag, den 14.07.2015, 10:00 +0200 schrieb Joachim Breitner: > I don?t recall when it was the last time that we had a passing build > on travis, so I had a look what?s wrong, and to my surprise the problem > was not a build timeout, but rather two failing test cases: > > *** unexpected failure for T10294(normal) known bug (#10301) marked known_broken on that (with help from thomie, thanks). > *** unexpected failure for T10596(normal) just a missing hFlush stdout. So travis is green again, and I can start complaining at people that make it red again. Greetings, Joachim -- -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ml9951 at rit.edu Wed Jul 15 17:53:06 2015 From: ml9951 at rit.edu (Matthew Le (RIT Student)) Date: Wed, 15 Jul 2015 13:53:06 -0400 Subject: Cabal Include-Dirs link to RTS Message-ID: I am currently working on an alternative implementation of the STM monad and would like to keep my work as isolated as possible. To that end, I have tried to keep all my files separate in a confined package. The package consists of haskell files which are exported to the programmer, a C-- file which is used by the haskell functions, and a C file, which is called from some of the C-- primitives. Inside my C file, I need to call a couple of functions that exist in the RTS, such as "dirty_TVAR" from (rts/sm/Storage.h). Is there a good way to include this header file in my C file? I would like to be able to list rts/sm in my cabal file under Include-Dirs. I'm wondering if there is something analogous to an environment variable or anchor names (from SML/NJ compilation manager) that can tell me where the GHC source directory root is. As an example, I would like to do something to the effect of: library Include-Dirs: $GHC_ROOT/rts, $GHC_ROOT/rts/sm where $GHC_ROOT would tell cabal where to find the ghc source directory in the file system. I tried giving a relative path (which as expected does not work), giving the following warning: Warning: 'include-dirs: ../../rts' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. I can give an absolute path for my machine and everything compiles just fine, but this is obviously not portable. Any help would be much appreciated. -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Fri Jul 17 05:19:06 2015 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Fri, 17 Jul 2015 08:19:06 +0300 Subject: New release of GHC 7.8 to support OS X El Capitan Message-ID: <550AC623-0CB9-4680-B189-A2CCB63B01A2@iki.fi> Hi, first some background: there is an issue with having Haskell on the next OS X ?El Capitan?: [1] caused by security updates in the operating system. The cause is too old `unix` package, the same issue as in [2] Could someone verify that my understanding of the issue is correct, i.e. how Cabal-the-tool and Cabal-the-library interoperate. For me it seems, that one of the easiest ways to fix the issue (for the users), is to have a new release in 7.8 branch, with updated `unix` dependency. Or is it there too might hassle to be possible? Related issues: [3] [4] [1] https://github.com/haskell/cabal/issues/2653 [2] https://github.com/haskell/unix/pull/18 [3] https://github.com/commercialhaskell/stack/issues/563 [4] https://github.com/ghcformacosx/ghc-dot-app/issues/39#issuecomment-122088535 Greetings, Oleg P.S. hopefully Windows 10 doesn?t pose similar surprises. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ben at well-typed.com Sat Jul 18 11:39:37 2015 From: ben at well-typed.com (Ben Gamari) Date: Sat, 18 Jul 2015 13:39:37 +0200 Subject: New release of GHC 7.8 to support OS X El Capitan In-Reply-To: <550AC623-0CB9-4680-B189-A2CCB63B01A2@iki.fi> References: <550AC623-0CB9-4680-B189-A2CCB63B01A2@iki.fi> Message-ID: <87egk57kzq.fsf@smart-cactus.org> Oleg Grenrus writes: > Hi, > > first some background: there is an issue with having Haskell on the > next OS X ?El Capitan?: [1] caused by security updates in the > operating system. The cause is too old `unix` package, the same issue > as in [2] > I would like to understand the root-cause of the issue. It seems that OS X will now raise EPERM instead of EACCES when certain files are accessed. That being said, it's not at all clear to me which system call is failing or why. Could someone familiar with El Capitan describe what exactly is going on here? > Could someone verify that my understanding of the issue is correct, > i.e. how Cabal-the-tool and Cabal-the-library interoperate. > > For me it seems, that one of the easiest ways to fix the issue (for > the users), is to have a new release in 7.8 branch, with updated > `unix` dependency. Or is it there too might hassle to be possible? > I will bring this up in next week's GHC meeting. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at smart-cactus.org Sat Jul 18 12:00:33 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 18 Jul 2015 14:00:33 +0200 Subject: New release of GHC 7.8 to support OS X El Capitan In-Reply-To: <550AC623-0CB9-4680-B189-A2CCB63B01A2@iki.fi> References: <550AC623-0CB9-4680-B189-A2CCB63B01A2@iki.fi> Message-ID: <87bnf97k0u.fsf@smart-cactus.org> Oleg Grenrus writes: > Hi, > first some background: there is an issue with having Haskell on the > next OS X ?El Capitan?: [1] caused by security updates in the > operating system. The cause is too old `unix` package, the same issue > as in [2] I would like to understand the root-cause of the issue. It seems that OS X will now raise EPERM instead of EACCES when certain files are accessed. That being said, it's not at all clear to me which system call is failing or why. Could someone familiar with El Capitan describe what exactly is going on here? > Could someone verify that my understanding of the issue is correct, > i.e. how Cabal-the-tool and Cabal-the-library interoperate. > > For me it seems, that one of the easiest ways to fix the issue (for > the users), is to have a new release in 7.8 branch, with updated > `unix` dependency. Or is it there too might hassle to be possible? I will bring this up in next week's GHC meeting. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From allbery.b at gmail.com Sat Jul 18 13:11:25 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 18 Jul 2015 09:11:25 -0400 Subject: New release of GHC 7.8 to support OS X El Capitan In-Reply-To: <87egk57kzq.fsf@smart-cactus.org> References: <550AC623-0CB9-4680-B189-A2CCB63B01A2@iki.fi> <87egk57kzq.fsf@smart-cactus.org> Message-ID: On Sat, Jul 18, 2015 at 7:39 AM, Ben Gamari wrote: > I would like to understand the root-cause of the issue. It seems that > OS X will now raise EPERM instead of EACCES when certain files are > accessed. That being said, it's not at all clear to me which system call > is failing or why. Could someone familiar with El Capitan describe what > exactly is going on here? > The trace showed access("/usr/bin/ar", 2) => -1/EPERM (instead of -1/EACCES). http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really appears relevant. Sounds to me like they automatically set a bunch of stuff immutable (chflags(1) schg flag; also see chflags(2), the underlying syscall) and bump the (equivalent of) securelevel so it can't be altered even by root after system boot. (Sadly, Apple did not bother to update the manpages to reflect launchd.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sun Jul 19 11:46:57 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 19 Jul 2015 07:46:57 -0400 Subject: Improving the "Get Haskell Experience" In-Reply-To: References: <71F7182C-A7DB-47A6-AA1B-940BDDE14F35@gmail.com> <878uakpl27.fsf@andromedae.feelingofgreen.ru> Message-ID: I'm glad to read the variety of response, and want to summarize and respond to the most common points: *stack is too new *& *having two package managers will confuse* ? It is indeed new, though it has arrived very well formed, and has gained a lot of users in short order. There are two reasons why I think we should be including it (or rather, including the version a few months down the road when we do the next major HP): 1) It's approach to package db organization is very good, 2) I would be better for all that stack were part of the suite of tools, rather than an alternative suite. Too be clear: I don't anticipate stack replacing cabal - different tasks will need one or the other. But I would like to see them unified in package db management. *nix-like package management* ? I'll be honest: I don't think nix-style package management is all that useful. Enabling the package machinery to be able to support all those different package builds is fine. But it seems the devil is in the user experience of the tools that manage it. Until we see what use cases those tools support, I really have no way to evaluate what extending package dbs this way will add. *possible change to cabal sandbox handling of the global db* ? Of course this will improve more complex builds for people who download the HP - but does so by reducing the HP install to a minimal install. This is fine, but I think what we proposed goes further. *pre-built package binaries are good* ? Yes, especially on Windows, but I'd like to see a way that users can get those binaries, easily, and securely, without bloating the HP download. At present, users have to download 150MB ~ 230MB of installer - it is heavy! If we can make it so that users only have to compile a package the first time they use it in any project, for many this is ideal: you start minimal, incur cost is only once on first use, and build exactly in your system environment. If we augment this with a "binary repository" then we can let users decide to trade the compile cost for the download cost. - Mark Sorry for slow, group response, I'm still on vacation! -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Sun Jul 19 14:46:13 2015 From: lonetiger at gmail.com (=?utf-8?Q?Tamar_Christina?=) Date: Sun, 19 Jul 2015 14:46:13 +0000 Subject: =?utf-8?Q?build_system_question_build-prog_and_bindisttest?= Message-ID: <55abb867.c7b0c20a.3a7c4.ffffcc8f@mx.google.com> Hi All, In my ghc.mk I have declared: $(eval $(call build-prog,driver/ghc-split,dist,0)) $(eval $(call bindist,driver/ghc-split,ghc.mk)) compilation is fine but during testing I get this error: ===--- building final phase Bad GHC version '7.8.3' for 'bindisttest/a/b/c/ghc-7.11.20150719/bin/ghc-split.exe' bindisttest/ghc.mk:21: recipe for target 'test_bindist' failed I assume this is because I tell it to build ghc-split at stage 0, so it's using the bootstrapping compiler which in my case is 7.8.3. Now it's perfectly fine to build this at stage 1 or 2, but when I change it to either of those building fails telling me that ghc-stage1 or ghc-stage2 cannot be found... Could the dependency check me wrong? How do I go about fixing this? Regards, Tamar ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Sun Jul 19 15:52:41 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Sun, 19 Jul 2015 17:52:41 +0200 Subject: build system question build-prog and bindisttest In-Reply-To: <55abb867.c7b0c20a.3a7c4.ffffcc8f@mx.google.com> References: <55abb867.c7b0c20a.3a7c4.ffffcc8f@mx.google.com> Message-ID: > In my ghc.mk I have declared: > > $(eval $(call build-prog,driver/ghc-split,dist,0)) > $(eval $(call bindist,driver/ghc-split,ghc.mk)) > That second line isn't needed. I think you are trying to follow https://ghc.haskell.org/trac/ghc/wiki/Building/Modifying#Addingaprogram, but that information is outdated. Take a look at some ghc.mk files in the utils directory, for example `utils/hpc/ghc.mk`. Now it's perfectly fine to build this at stage 1 or 2 > Use stage1 to build it, or stage2 if you need access to the ghc api. , but when I change it to either of those building fails telling me that > ghc-stage1 or ghc-stage2 cannot be found... > You are probably missing an entry like the following in the toplevel ghc.mk: utils/hpc/dist-install/package-data.mk: compiler/stage2/package-data.mk -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Sun Jul 19 19:08:50 2015 From: lonetiger at gmail.com (=?utf-8?Q?Tamar_Christina?=) Date: Sun, 19 Jul 2015 19:08:50 +0000 Subject: =?utf-8?Q?Re:_build_system_question_build-prog_and_bindisttest?= In-Reply-To: References: <55abb867.c7b0c20a.3a7c4.ffffcc8f@mx.google.com>, Message-ID: <55abf660.53b6b40a.304a2.ffffaa97@mx.google.com> Hi Thomas, Thanks for the help! I have removed the call to bindist and I was indeed missing a similar line in the main GHC.mk Unfortunately I still get the same error: HC [stage 2] driver/ghc-split/dist/build/tmp/ghc-split.exe /bin/sh: inplace/bin/ghc-stage2.exe: No such file or directory driver/ghc-split/ghc.mk:21: recipe for target 'driver/ghc-split/dist/build/tmp/ghc-split.exe' failed make[1]: *** [driver/ghc-split/dist/build/tmp/ghc-split.exe] Error 127 Though not quite sure why it?s looking in inplace/bin.. I was indeed following that page, but haven't been able to consult the wiki today as Trac has been throwing an error all day. The line I added was: driver/ghc-split/dist/package-data.mk: compiler/stage2/package-data.mk Any ideas? Regards, Tamar From: Thomas Miedema Sent: ?Sunday?, ?July? ?19?, ?2015 ?17?:?52 To: Tamar Christina Cc: GHC In my ghc.mk I have declared: $(eval $(call build-prog,driver/ghc-split,dist,0)) $(eval $(call bindist,driver/ghc-split,ghc.mk)) That second line isn't needed. I think you are trying to follow https://ghc.haskell.org/trac/ghc/wiki/Building/Modifying#Addingaprogram, but that information is outdated. Take a look at some ghc.mk files in the utils directory, for example `utils/hpc/ghc.mk`. Now it's perfectly fine to build this at stage 1 or 2 Use stage1 to build it, or stage2 if you need access to the ghc api. , but when I change it to either of those building fails telling me that ghc-stage1 or ghc-stage2 cannot be found... You are probably missing an entry like the following in the toplevel ghc.mk: utils/hpc/dist-install/package-data.mk: compiler/stage2/package-data.mk -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Sun Jul 19 19:30:56 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Sun, 19 Jul 2015 21:30:56 +0200 Subject: build system question build-prog and bindisttest In-Reply-To: <55abf660.53b6b40a.304a2.ffffaa97@mx.google.com> References: <55abb867.c7b0c20a.3a7c4.ffffcc8f@mx.google.com> <55abf660.53b6b40a.304a2.ffffaa97@mx.google.com> Message-ID: Please upload your code somewhere, and I can take a look. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Sun Jul 19 19:43:53 2015 From: lonetiger at gmail.com (=?utf-8?Q?Tamar_Christina?=) Date: Sun, 19 Jul 2015 19:43:53 +0000 Subject: =?utf-8?Q?Re:_build_system_question_build-prog_and_bindisttest?= In-Reply-To: References: <55abb867.c7b0c20a.3a7c4.ffffcc8f@mx.google.com> <55abf660.53b6b40a.304a2.ffffaa97@mx.google.com>, Message-ID: <55abfe06.040bc20a.124d.1a86@mx.google.com> I?ve pushed the code to https://github.com/Mistuke/ghc/tree/trac-9832-replace-split-perl-script-with-haskell From: Thomas Miedema Sent: ?Sunday?, ?July? ?19?, ?2015 ?21?:?30 To: Tamar Christina Cc: GHC Please upload your code somewhere, and I can take a look. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Mon Jul 20 16:54:39 2015 From: lonetiger at gmail.com (=?utf-8?Q?Tamar_Christina?=) Date: Mon, 20 Jul 2015 16:54:39 +0000 Subject: =?utf-8?Q?Trac_error?= Message-ID: <55ad286a.0679c20a.44483.ffffba3a@mx.google.com> Hi All, Did something change with Trac recently? I am able to browse it fine when not logged in, but when I log in I get presented with: Oops? Trac detected an internal error: AttributeError: 'FakeSession' object has no attribute 'authenticated' There was an internal error in Trac. It is recommended that you notify your local Trac administrator with the information needed to reproduce the issue. on basically any page I try going to and directly after the login action. I have tried multiple devices and browsers. Regards, Tamar -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Tue Jul 21 10:45:14 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Tue, 21 Jul 2015 12:45:14 +0200 Subject: Deleting sync-all Message-ID: Hello ghc-devs, I would like to delete the file sync-all from the GHC repository. It should not have been necessary to use it for about a year now. To get the sources : git clone --recursive git://git.haskell.org/ghc.git cd ghc git clone git://git.haskell.org/ghc-tarballs.git # Windows only To update an existing tree : git pull --rebase git submodule update --init To update an existing tree , without the possibility to forget to run `git submodule update --init`: git config --global alias.pullall '!f(){ git pull --ff-only "$@" && git submodule update --init --recursive; }; f' # Run once git pullall --rebase Please speak up if you want those 1000 lines of buggy Perl a.k.a. sync-all to stay for some reason, or if you have questions about a certain git submodules workflow. The source code (./boot no longer suggests it) and the wiki are already sync-all free, except for a few historical pages. Discussion period: 1 month. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Jul 21 16:01:45 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 21 Jul 2015 18:01:45 +0200 Subject: Building GHC master with GHC 7.6 Message-ID: <87615da49i.fsf@smart-cactus.org> Hello everyone, Earlier today I merged a clean-up [1] to the master branch which removed some #ifdefs which ensured that the tree could be built with GHC 7.6 Thomas Miedema correctly pointed out that some nightly builders may not be on GHC 7.8 yet. Do any of the nightly builders call in this category? If so, would it be possible to upgrade? Cheers, - Ben [1] https://phabricator.haskell.org/D904 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From omeragacan at gmail.com Tue Jul 21 16:06:56 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 21 Jul 2015 12:06:56 -0400 Subject: Deleting sync-all In-Reply-To: References: Message-ID: +1 from me. I only use it for `get` command after changing branches, and I think I can just as easily do same thing with `git submodule update --checkout`. (is that right?) 2015-07-21 6:45 GMT-04:00 Thomas Miedema : > Hello ghc-devs, > > I would like to delete the file sync-all from the GHC repository. It should > not have been necessary to use it for about a year now. > > To get the sources: > > git clone --recursive git://git.haskell.org/ghc.git > cd ghc > git clone git://git.haskell.org/ghc-tarballs.git # Windows only > > > To update an existing tree: > git pull --rebase > > git submodule update --init > > > To update an existing tree, without the possibility to forget to run `git > submodule update --init`: > git config --global alias.pullall '!f(){ git pull --ff-only "$@" && git > submodule update --init --recursive; }; f' # Run once > git pullall --rebase > > > Please speak up if you want those 1000 lines of buggy Perl a.k.a. sync-all > to stay for some reason, or if you have questions about a certain git > submodules workflow. > > > The source code (./boot no longer suggests it) and the wiki are already > sync-all free, except for a few historical pages. > > Discussion period: 1 month. > > > Thomas > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From alan.zimm at gmail.com Tue Jul 21 19:35:33 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 21 Jul 2015 21:35:33 +0200 Subject: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images In-Reply-To: <059.0c58a99c0d41d87c1aee093646664583@haskell.org> References: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> <059.0c58a99c0d41d87c1aee093646664583@haskell.org> Message-ID: Ok. But it may be worth manually fixing the version on the official web site once 7.10.2 comes out On Tue, Jul 21, 2015 at 9:19 PM, GHC wrote: > #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: > Type: bug | Status: new > Priority: normal | Milestone: 7.10.3 > Component: Documentation | Version: 7.10.1 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Revisions: Phab:D958, > | Phab:D970 > -------------------------------------+------------------------------------- > Changes (by bgamari): > > * milestone: 7.10.2 => 7.10.3 > > > Comment: > > I think we may need to punt on this for 7.10.2. I spent several hours on > this today and have been entirely unable to get even the an `` tag to > be produced in the HTML, much less a rendered image. Sadly DocBook appears > to be an antiquated disaster. > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jul 21 20:21:06 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 21 Jul 2015 20:21:06 +0000 Subject: build system Message-ID: <489c0c6efee94ef39f4cb9971fdcf54a@DB4PR30MB030.064d.mgd.msft.net> Friends With the new build system I get this kind of output HC [stage 1] compiler/stage2/build/SPARC/AddrMode.o HC [stage 1] compiler/stage2/build/CmmContFlowOpt.o HC [stage 1] compiler/stage2/build/CmmImplementSwitchPlans.o AR libraries/Cabal/Cabal/dist-install/build/libHSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.a C:\fp\HP-2014-2.0.0.0\mingw\bin\ar.exe: creating libraries/Cabal/Cabal/dist-install/build/libHSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.a LD libraries/Cabal/Cabal/dist-install/build/HSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.o HC [stage 1] utils/ghc-cabal/dist-install/build/Main.o WARNING: file compiler\specialise\Specialise.hs, line 724 But I have no idea which module caused the WARNING, nor do I have a command-line to copy/paste to reproduce it. (With the old module-at-a-time system I could copy/paste the command line for the specific module.) Is there a way to * make things sequential so I can tell which warnings from which module * get a command line to copy/paste to compile that module? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwbarton at gmail.com Tue Jul 21 21:16:23 2015 From: rwbarton at gmail.com (Reid Barton) Date: Tue, 21 Jul 2015 17:16:23 -0400 Subject: build system In-Reply-To: <489c0c6efee94ef39f4cb9971fdcf54a@DB4PR30MB030.064d.mgd.msft.net> References: <489c0c6efee94ef39f4cb9971fdcf54a@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Tue, Jul 21, 2015 at 4:21 PM, Simon Peyton Jones wrote: > Friends > > With the new build system I get this kind of output > > HC [stage 1] compiler/stage2/build/SPARC/AddrMode.o > > HC [stage 1] compiler/stage2/build/CmmContFlowOpt.o > > HC [stage 1] compiler/stage2/build/CmmImplementSwitchPlans.o > > AR > libraries/Cabal/Cabal/dist-install/build/libHSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.a > > C:\fp\HP-2014-2.0.0.0\mingw\bin\ar.exe: creating > libraries/Cabal/Cabal/dist-install/build/libHSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.a > > LD > libraries/Cabal/Cabal/dist-install/build/HSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.o > > HC [stage 1] utils/ghc-cabal/dist-install/build/Main.o > > *WARNING*: file compiler\specialise\Specialise.hs, line 724 > I assume this is when you run validate? > But I have no idea which module caused the WARNING, nor do I have a > command-line to copy/paste to reproduce it. (With the old module-at-a-time > system I could copy/paste the command line for the specific module.) > > Is there a way to > > ? make things sequential so I can tell which warnings from which > module > make -j1, which is make's default, but validate invokes make with -j2 or higher (depending on how many CPUs it thinks your system has). > ? get a command line to copy/paste to compile that module? > validate sets the GHC build system variable V=0 in mk/are-validating.mk. You can override it from the make command line with make V=1. So, you can run "make V=1" to restart the build serially and with the command to build each file displayed. Note that serial make may build modules in a different order than parallel make, so it may take a while for make to get around to building the module that failed. Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Tue Jul 21 21:32:55 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Tue, 21 Jul 2015 23:32:55 +0200 Subject: build system In-Reply-To: References: <489c0c6efee94ef39f4cb9971fdcf54a@DB4PR30MB030.064d.mgd.msft.net> Message-ID: What Reid said is correct. I just changed validate back to use V=1 though, since it seems like a better default. From https://ghc.haskell.org/trac/ghc/wiki/Design/BuildSystem: "The build system should clearly report what it's doing (and sometimes why), without being too verbose. It should emit actual command lines as much as possible, so that they can be inspected and cut & pasted. " You can run `./validate --quiet` to get the previous behavior. To make things sequential: you can use `CPUS=1 ./validate`. On Tue, Jul 21, 2015 at 11:16 PM, Reid Barton wrote: > On Tue, Jul 21, 2015 at 4:21 PM, Simon Peyton Jones > wrote: > >> Friends >> >> With the new build system I get this kind of output >> >> HC [stage 1] compiler/stage2/build/SPARC/AddrMode.o >> >> HC [stage 1] compiler/stage2/build/CmmContFlowOpt.o >> >> HC [stage 1] compiler/stage2/build/CmmImplementSwitchPlans.o >> >> AR >> libraries/Cabal/Cabal/dist-install/build/libHSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.a >> >> C:\fp\HP-2014-2.0.0.0\mingw\bin\ar.exe: creating >> libraries/Cabal/Cabal/dist-install/build/libHSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.a >> >> LD >> libraries/Cabal/Cabal/dist-install/build/HSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.o >> >> HC [stage 1] utils/ghc-cabal/dist-install/build/Main.o >> >> *WARNING*: file compiler\specialise\Specialise.hs, line 724 >> > I assume this is when you run validate? > >> But I have no idea which module caused the WARNING, nor do I have a >> command-line to copy/paste to reproduce it. (With the old module-at-a-time >> system I could copy/paste the command line for the specific module.) >> >> Is there a way to >> >> ? make things sequential so I can tell which warnings from which >> module >> > make -j1, which is make's default, but validate invokes make with -j2 or > higher (depending on how many CPUs it thinks your system has). > >> ? get a command line to copy/paste to compile that module? >> > validate sets the GHC build system variable V=0 in mk/are-validating.mk. > You can override it from the make command line with make V=1. > > So, you can run "make V=1" to restart the build serially and with the > command to build each file displayed. Note that serial make may build > modules in a different order than parallel make, so it may take a while for > make to get around to building the module that failed. > > Regards, > Reid Barton > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jul 21 21:36:42 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 21 Jul 2015 21:36:42 +0000 Subject: build system In-Reply-To: References: <489c0c6efee94ef39f4cb9971fdcf54a@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <42948cced9e24fa7ac302d712caea000@DB4PR30MB030.064d.mgd.msft.net> Fantastic, thanks. Might you add info on what ?validate? understands to https://ghc.haskell.org/trac/ghc/wiki/TestingPatches? And ditto the V flags to https://ghc.haskell.org/trac/ghc/wiki/Building/Hacking Simon From: Thomas Miedema [mailto:thomasmiedema at gmail.com] Sent: 21 July 2015 22:33 To: Reid Barton Cc: Simon Peyton Jones; ghc-devs at haskell.org Subject: Re: build system What Reid said is correct. I just changed validate back to use V=1 though, since it seems like a better default. From https://ghc.haskell.org/trac/ghc/wiki/Design/BuildSystem: "The build system should clearly report what it's doing (and sometimes why), without being too verbose. It should emit actual command lines as much as possible, so that they can be inspected and cut & pasted. " You can run `./validate --quiet` to get the previous behavior. To make things sequential: you can use `CPUS=1 ./validate`. On Tue, Jul 21, 2015 at 11:16 PM, Reid Barton > wrote: On Tue, Jul 21, 2015 at 4:21 PM, Simon Peyton Jones > wrote: Friends With the new build system I get this kind of output HC [stage 1] compiler/stage2/build/SPARC/AddrMode.o HC [stage 1] compiler/stage2/build/CmmContFlowOpt.o HC [stage 1] compiler/stage2/build/CmmImplementSwitchPlans.o AR libraries/Cabal/Cabal/dist-install/build/libHSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.a C:\fp\HP-2014-2.0.0.0\mingw\bin\ar.exe: creating libraries/Cabal/Cabal/dist-install/build/libHSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.a LD libraries/Cabal/Cabal/dist-install/build/HSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.o HC [stage 1] utils/ghc-cabal/dist-install/build/Main.o WARNING: file compiler\specialise\Specialise.hs, line 724 I assume this is when you run validate? But I have no idea which module caused the WARNING, nor do I have a command-line to copy/paste to reproduce it. (With the old module-at-a-time system I could copy/paste the command line for the specific module.) Is there a way to ? make things sequential so I can tell which warnings from which module make -j1, which is make's default, but validate invokes make with -j2 or higher (depending on how many CPUs it thinks your system has). ? get a command line to copy/paste to compile that module? validate sets the GHC build system variable V=0 in mk/are-validating.mk. You can override it from the make command line with make V=1. So, you can run "make V=1" to restart the build serially and with the command to build each file displayed. Note that serial make may build modules in a different order than parallel make, so it may take a while for make to get around to building the module that failed. Regards, Reid Barton _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Tue Jul 21 22:04:29 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Wed, 22 Jul 2015 00:04:29 +0200 Subject: build system In-Reply-To: <42948cced9e24fa7ac302d712caea000@DB4PR30MB030.064d.mgd.msft.net> References: <489c0c6efee94ef39f4cb9971fdcf54a@DB4PR30MB030.064d.mgd.msft.net> <42948cced9e24fa7ac302d712caea000@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Tue, Jul 21, 2015 at 11:36 PM, Simon Peyton Jones wrote: > Fantastic, thanks. > > > > Might you add info on what ?validate? understands to > https://ghc.haskell.org/trac/ghc/wiki/TestingPatches? > Done. There is also `./validate --help`. > > > And ditto the V flags to > > https://ghc.haskell.org/trac/ghc/wiki/Building/Hacking > Ok, but I put it on this page instead: https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Buildconfiguration https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Verbosebuild The `V=0` option is also discoverable from the `mk/build.mk.sample` file. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jul 21 22:10:50 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 21 Jul 2015 22:10:50 +0000 Subject: build system In-Reply-To: References: <489c0c6efee94ef39f4cb9971fdcf54a@DB4PR30MB030.064d.mgd.msft.net> <42948cced9e24fa7ac302d712caea000@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <07b9a4b31a9042159722b88263ff6eb7@DB4PR30MB030.064d.mgd.msft.net> Thank you! From: Thomas Miedema [mailto:thomasmiedema at gmail.com] Sent: 21 July 2015 23:04 To: Simon Peyton Jones Cc: Reid Barton; ghc-devs at haskell.org Subject: Re: build system On Tue, Jul 21, 2015 at 11:36 PM, Simon Peyton Jones > wrote: Fantastic, thanks. Might you add info on what ?validate? understands to https://ghc.haskell.org/trac/ghc/wiki/TestingPatches? Done. There is also `./validate --help`. And ditto the V flags to https://ghc.haskell.org/trac/ghc/wiki/Building/Hacking Ok, but I put it on this page instead: https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Buildconfiguration https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Verbosebuild The `V=0` option is also discoverable from the `mk/build.mk.sample` file. -------------- next part -------------- An HTML attachment was scrubbed... URL: From igloo at earth.li Tue Jul 21 22:14:05 2015 From: igloo at earth.li (Ian Lynagh) Date: Tue, 21 Jul 2015 23:14:05 +0100 Subject: build system In-Reply-To: References: <489c0c6efee94ef39f4cb9971fdcf54a@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <20150721221405.GA4905@matrix.chaos.earth.li> On Tue, Jul 21, 2015 at 11:32:55PM +0200, Thomas Miedema wrote: > > To make things sequential: you can use `CPUS=1 ./validate`. You need "THREADS=1 ./validate". CPUS=1 would use 2 threads. Thanks Ian From thomasmiedema at gmail.com Tue Jul 21 22:27:39 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Wed, 22 Jul 2015 00:27:39 +0200 Subject: build system In-Reply-To: <20150721221405.GA4905@matrix.chaos.earth.li> References: <489c0c6efee94ef39f4cb9971fdcf54a@DB4PR30MB030.064d.mgd.msft.net> <20150721221405.GA4905@matrix.chaos.earth.li> Message-ID: Oh yes, I keep forgetting that. So many variables.. How about we remove the possibility to set CPUS, and only keep THREADS (but still set it to the number of processors+1 by default). On Wed, Jul 22, 2015 at 12:14 AM, Ian Lynagh wrote: > On Tue, Jul 21, 2015 at 11:32:55PM +0200, Thomas Miedema wrote: > > > > To make things sequential: you can use `CPUS=1 ./validate`. > > You need "THREADS=1 ./validate". > > CPUS=1 would use 2 threads. > > > Thanks > Ian > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Wed Jul 22 08:48:02 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Wed, 22 Jul 2015 10:48:02 +0200 Subject: Test failures: T4945 and haddock.base Message-ID: Simon, Allocation for haddock.base is now 9466142208 bytes according to [1]. Before your changes yesterday it was 9385186792, according to [2]. Thomas [1] https://phabricator.haskell.org/harbormaster/build/5076/?l=0 [2] https://perf.haskell.org/ghc/#revision/9ade087108afe2eec2698b6ce41146df02524810 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Jul 22 09:06:06 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 22 Jul 2015 11:06:06 +0200 Subject: Test failures: T4945 and haddock.base In-Reply-To: References: Message-ID: <1437555966.13433.14.camel@joachim-breitner.de> Hi, Am Mittwoch, den 22.07.2015, 10:48 +0200 schrieb Thomas Miedema: > Allocation for haddock.base is now 9466142208 bytes according to [1]. > Before your changes yesterday it was 9385186792, according to [2]. > > Thomas > > [1] https://phabricator.haskell.org/harbormaster/build/5076/?l=0 > [2] https://perf.haskell.org/ghc/#revision/9ade087108afe2eec2698b6ce41146df02524810 note that I am currently upgrading the perf builder to GHC-7.8, so expect numbers for the recent patches within the next hours. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From thomasmiedema at gmail.com Wed Jul 22 10:39:07 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Wed, 22 Jul 2015 12:39:07 +0200 Subject: Deleting sync-all In-Reply-To: References: Message-ID: On Tue, Jul 21, 2015 at 6:06 PM, ?mer Sinan A?acan wrote: > +1 from me. I only use it for `get` command after changing branches, > and I think I can just as easily do same thing with `git submodule > update --checkout`. (is that right?) > That is correct, although `--checkout` is I the default, so just `git submodule update` also works. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at barrucadu.co.uk Wed Jul 22 13:46:14 2015 From: mike at barrucadu.co.uk (Michael Walker) Date: Wed, 22 Jul 2015 14:46:14 +0100 Subject: Question about inliner behaviour with a small function Message-ID: <20150722134614.GB10473@arkham.barrucadu.barrucadu.uk0.bigv.io> Hello, I managed to shrink a bizarre memory issue down to this (probably minimal) example: module Main where f :: [Int] -> Int f xs = length is where is = [ i | (_, i) <- pairs ys ] :: [(Int,Int)] ys = zip [0..] xs :: [(Int, Int)] {-# INLINE pairs #-} pairs xs = zip xs $ tail xs main :: IO () main = print $ f xs where xs = replicate 1000000 0 With the INLINE pragma, this allocates 264,049,584 bytes (compiled with `ghc -O2 -prof -fprof-auto inline.hs), without the pragma it allocates 336,049,512 bytes. Dropping the `main` definition (and renaming the module to "Foo") and examining the core, the key difference seems to be in how the list comprehension is compiled. With the INLINE pragma: Rec { Foo.f_go [Occ=LoopBreaker] :: [(Int, Int)] -> [(Int, Int)] -> [(Int, Int)] [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType ] Foo.f_go = \ (ds_a14a :: [(Int, Int)]) (_ys_a14b :: [(Int, Int)]) -> case ds_a14a of _ [Occ=Dead] { [] -> GHC.Types.[] @ (Int, Int); : ipv_a14g ipv1_a14h -> case _ys_a14b of _ [Occ=Dead] { [] -> GHC.Types.[] @ (Int, Int); : ipv2_a14n ipv3_a14o -> GHC.Types.: @ (Int, Int) ipv2_a14n (Foo.f_go ipv1_a14h ipv3_a14o) } } end Rec } And without: Rec { Foo.f_go [Occ=LoopBreaker] :: [((Int, Int), (Int, Int))] -> [(Int, Int)] [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType ] Foo.f_go = \ (ds_a13o :: [((Int, Int), (Int, Int))]) -> case ds_a13o of _ [Occ=Dead] { [] -> GHC.Types.[] @ (Int, Int); : y_a13t ys_a13u -> case y_a13t of _ [Occ=Dead] { (ds1_d12V, i_an2) -> GHC.Types.: @ (Int, Int) i_an2 (Foo.f_go ys_a13u) } } end Rec } Full core is available at https://gist.github.com/barrucadu/a59df62cd16074559e35 In the no-INLINE case, the list comprehension is compiled much like I would expect, it's walking down a zipped list of pairs and producing the result. The INLINE case is rather different, it looks like the `zip` has been inlined and deforestation has happened. This explains the difference in memory usage, a whole intermediary list has been skipped! I assume that GHC's analysis is determining `pairs` is too expensive to inline early enough to allow the further optimisation without the pragma, but the pragma forces it to happen earlier by marking it as really cheap. But `pairs` is a really small definition, syntactically. Why does the analysis consider it expensive? It is simply because it uses its argument multiple times in its body? And if it's not some sort of cost analysis, what's really going on? Thank for your time. -- Michael Walker (http://www.barrucadu.co.uk) From mail at joachim-breitner.de Wed Jul 22 15:14:11 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 22 Jul 2015 17:14:11 +0200 Subject: Test failures: T4945 and haddock.base In-Reply-To: <1437555966.13433.14.camel@joachim-breitner.de> References: <1437555966.13433.14.camel@joachim-breitner.de> Message-ID: <1437578051.2293.2.camel@joachim-breitner.de> Hi, Am Mittwoch, den 22.07.2015, 11:06 +0200 schrieb Joachim Breitner: > Am Mittwoch, den 22.07.2015, 10:48 +0200 schrieb Thomas Miedema: > > Allocation for haddock.base is now 9466142208 bytes according to > > [1]. > > Before your changes yesterday it was 9385186792, according to [2]. I cannot fully reproduce this change on the perf builder. There is a change caused by ?Improve strictness analysis for exceptions?: https://perf.haskell.org/ghc/#revision/7c0fff41789669450b02dc1db7f5d7ba bba5dee6 But here, the change is smaller: tests/alloc/haddock.base 9372256848 + 0.50% 9418857192 But both are off the expected value of 9014511528, so maybe you can simply re-center the numbers. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Wed Jul 22 16:35:34 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 22 Jul 2015 16:35:34 +0000 Subject: [commit: ghc] master: Testsuite: recenter haddock.base allocation numbers (1b76997) In-Reply-To: <20150722163304.4D8713A300@ghc.haskell.org> References: <20150722163304.4D8713A300@ghc.haskell.org> Message-ID: Could it be creeping up because Haddock is doing more than before? Ie not just because GHC is being bad? S | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf | Of git at git.haskell.org | Sent: 22 July 2015 17:33 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: Testsuite: recenter haddock.base | allocation numbers (1b76997) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/1b76997dba5c35ee956960e1948e | e247dc57c500/ghc | | >--------------------------------------------------------------- | | commit 1b76997dba5c35ee956960e1948ee247dc57c500 | Author: Thomas Miedema | Date: Wed Jul 22 18:21:44 2015 +0200 | | Testsuite: recenter haddock.base allocation numbers | | | >--------------------------------------------------------------- | | 1b76997dba5c35ee956960e1948ee247dc57c500 | testsuite/tests/perf/haddock/all.T | 3 ++- | 1 file changed, 2 insertions(+), 1 deletion(-) | | diff --git a/testsuite/tests/perf/haddock/all.T | b/testsuite/tests/perf/haddock/all.T | index 94f7cbd..1e5a16c 100644 | --- a/testsuite/tests/perf/haddock/all.T | +++ b/testsuite/tests/perf/haddock/all.T | @@ -5,7 +5,7 @@ | test('haddock.base', | [unless(in_tree_compiler(), skip), req_haddock | ,stats_num_field('bytes allocated', | - [(wordsize(64), 9014511528, 5) | + [(wordsize(64), 9418857192, 5) | # 2012-08-14: 5920822352 (amd64/Linux) | # 2012-09-20: 5829972376 (amd64/Linux) | # 2012-10-08: 5902601224 (amd64/Linux) @@ -23,6 +23,7 @@ | test('haddock.base', | # 2014-10-07: 8322584616 (x86_64/Linux) | # 2014-12-14: 9502647104 (x86_64/Linux) - Update to | Haddock 2.16 | # 2014-01-08: 9014511528 (x86_64/Linux) - Eliminate so- | called "silent superclass parameters" (and others) | + # 2015-07-22: 9418857192 (x86_64/Linux) - Just slowly | creeping up. | | ,(platform('i386-unknown-mingw32'), 4434804940, 5) | # 2013-02-10: 3358693084 | (x86/Windows) | | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits From fuuzetsu at fuuzetsu.co.uk Thu Jul 23 08:06:56 2015 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Thu, 23 Jul 2015 09:06:56 +0100 Subject: [commit: ghc] master: Testsuite: recenter haddock.base allocation numbers (1b76997) In-Reply-To: References: <20150722163304.4D8713A300@ghc.haskell.org> Message-ID: <55B0A0A0.1070801@fuuzetsu.co.uk> On 07/22/2015 05:35 PM, Simon Peyton Jones wrote: > Could it be creeping up because Haddock is doing more than before? Ie not just because GHC is being bad? > > S Yes, it very much could be. Haddock is a moving target so it's not too weird that the numbers change. I want to say that the perf test should just be removed but it's still useful: if you're GHC hacking and not changing Haddock and numbers go awry then it serves its purpose. Ideally GHC would have more perf tests so the Haddock perf test is just not necessary but it's not easy to tell when that would be. > | -----Original Message----- > | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf > | Of git at git.haskell.org > | Sent: 22 July 2015 17:33 > | To: ghc-commits at haskell.org > | Subject: [commit: ghc] master: Testsuite: recenter haddock.base > | allocation numbers (1b76997) > | > | Repository : ssh://git at git.haskell.org/ghc > | > | On branch : master > | Link : > | http://ghc.haskell.org/trac/ghc/changeset/1b76997dba5c35ee956960e1948e > | e247dc57c500/ghc > | > | >--------------------------------------------------------------- > | > | commit 1b76997dba5c35ee956960e1948ee247dc57c500 > | Author: Thomas Miedema > | Date: Wed Jul 22 18:21:44 2015 +0200 > | > | Testsuite: recenter haddock.base allocation numbers > | > | > | >--------------------------------------------------------------- > | > | 1b76997dba5c35ee956960e1948ee247dc57c500 > | testsuite/tests/perf/haddock/all.T | 3 ++- > | 1 file changed, 2 insertions(+), 1 deletion(-) > | > | diff --git a/testsuite/tests/perf/haddock/all.T > | b/testsuite/tests/perf/haddock/all.T > | index 94f7cbd..1e5a16c 100644 > | --- a/testsuite/tests/perf/haddock/all.T > | +++ b/testsuite/tests/perf/haddock/all.T > | @@ -5,7 +5,7 @@ > | test('haddock.base', > | [unless(in_tree_compiler(), skip), req_haddock > | ,stats_num_field('bytes allocated', > | - [(wordsize(64), 9014511528, 5) > | + [(wordsize(64), 9418857192, 5) > | # 2012-08-14: 5920822352 (amd64/Linux) > | # 2012-09-20: 5829972376 (amd64/Linux) > | # 2012-10-08: 5902601224 (amd64/Linux) @@ -23,6 +23,7 @@ > | test('haddock.base', > | # 2014-10-07: 8322584616 (x86_64/Linux) > | # 2014-12-14: 9502647104 (x86_64/Linux) - Update to > | Haddock 2.16 > | # 2014-01-08: 9014511528 (x86_64/Linux) - Eliminate so- > | called "silent superclass parameters" (and others) > | + # 2015-07-22: 9418857192 (x86_64/Linux) - Just slowly > | creeping up. > | > | ,(platform('i386-unknown-mingw32'), 4434804940, 5) > | # 2013-02-10: 3358693084 > | (x86/Windows) > | > | _______________________________________________ > | ghc-commits mailing list > | ghc-commits at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Mateusz K. From apfelmus at quantentunnel.de Thu Jul 23 08:15:46 2015 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Thu, 23 Jul 2015 10:15:46 +0200 Subject: Improving the "Get Haskell Experience" In-Reply-To: References: Message-ID: Mark Lentczner wrote: > *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop > shipping pre-built packages, so we banish cabal hell, and have a single > common way to 'get Haskell' that just works.* > > [..] > > We think this plan solves many different community needs: > > - We have a clear way to "get Haskell" that works for a wide variety of > use cases. > - HP installer gets much smaller, and about as minimal as a working > installation can get. > - By leaving most packages out of the global database, users of > cabal-install, will now have far fewer problems. Sandbox builds should now > never give users "cabal hell" like warnings. > - By building and installing the Platform packages into it's own package > db, users get the benefit of building and installing these common packages > only once per system, yet can easily bypass them for any given project if > desired. > - Since the Platform packages are now built and installed as needed, > installing on smaller systems or servers without OpenGL will work. Sounds great to me! Personally, I do not mind how the Haskell Platform achieves these goals; I will simply adapt to whatever tools the platform happens to install on my machine. Hopefully, they come with suitable documentation. For instance, one thing I don't understand about stack yet is in which location it "magically" installs GHC and packages, and how I can invoke `ghci` from these locations. Somehow, I was unable to understand this from the FAQ. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From simonpj at microsoft.com Thu Jul 23 11:20:48 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 23 Jul 2015 11:20:48 +0000 Subject: [commit: ghc] master: Testsuite: recenter haddock.base allocation numbers (1b76997) In-Reply-To: <55B0A0A0.1070801@fuuzetsu.co.uk> References: <20150722163304.4D8713A300@ghc.haskell.org> <55B0A0A0.1070801@fuuzetsu.co.uk> Message-ID: OK, so I won't lose sleep over it! | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Mateusz Kowalczyk | Sent: 23 July 2015 09:07 | To: ghc-devs at haskell.org | Subject: Re: [commit: ghc] master: Testsuite: recenter haddock.base | allocation numbers (1b76997) | | On 07/22/2015 05:35 PM, Simon Peyton Jones wrote: | > Could it be creeping up because Haddock is doing more than before? | Ie not just because GHC is being bad? | > | > S | | Yes, it very much could be. Haddock is a moving target so it's not too | weird that the numbers change. I want to say that the perf test should | just be removed but it's still useful: if you're GHC hacking and not | changing Haddock and numbers go awry then it serves its purpose. | | Ideally GHC would have more perf tests so the Haddock perf test is | just not necessary but it's not easy to tell when that would be. | | | > | -----Original Message----- | > | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On | > | Behalf Of git at git.haskell.org | > | Sent: 22 July 2015 17:33 | > | To: ghc-commits at haskell.org | > | Subject: [commit: ghc] master: Testsuite: recenter haddock.base | > | allocation numbers (1b76997) | > | | > | Repository : ssh://git at git.haskell.org/ghc | > | | > | On branch : master | > | Link : | > | | > | | http://ghc.haskell.org/trac/ghc/changeset/1b76997dba5c35ee956960e194 | > | 8e | > | e247dc57c500/ghc | > | | > | >--------------------------------------------------------------- | > | | > | commit 1b76997dba5c35ee956960e1948ee247dc57c500 | > | Author: Thomas Miedema | > | Date: Wed Jul 22 18:21:44 2015 +0200 | > | | > | Testsuite: recenter haddock.base allocation numbers | > | | > | | > | >--------------------------------------------------------------- | > | | > | 1b76997dba5c35ee956960e1948ee247dc57c500 | > | testsuite/tests/perf/haddock/all.T | 3 ++- | > | 1 file changed, 2 insertions(+), 1 deletion(-) | > | | > | diff --git a/testsuite/tests/perf/haddock/all.T | > | b/testsuite/tests/perf/haddock/all.T | > | index 94f7cbd..1e5a16c 100644 | > | --- a/testsuite/tests/perf/haddock/all.T | > | +++ b/testsuite/tests/perf/haddock/all.T | > | @@ -5,7 +5,7 @@ | > | test('haddock.base', | > | [unless(in_tree_compiler(), skip), req_haddock | > | ,stats_num_field('bytes allocated', | > | - [(wordsize(64), 9014511528, 5) | > | + [(wordsize(64), 9418857192, 5) | > | # 2012-08-14: 5920822352 (amd64/Linux) | > | # 2012-09-20: 5829972376 (amd64/Linux) | > | # 2012-10-08: 5902601224 (amd64/Linux) @@ -23,6 | +23,7 | > | @@ test('haddock.base', | > | # 2014-10-07: 8322584616 (x86_64/Linux) | > | # 2014-12-14: 9502647104 (x86_64/Linux) - Update to | > | Haddock 2.16 | > | # 2014-01-08: 9014511528 (x86_64/Linux) - Eliminate | > | so- called "silent superclass parameters" (and others) | > | + # 2015-07-22: 9418857192 (x86_64/Linux) - Just | slowly | > | creeping up. | > | | > | ,(platform('i386-unknown-mingw32'), 4434804940, 5) | > | # 2013-02-10: 3358693084 | > | (x86/Windows) | > | | > | _______________________________________________ | > | ghc-commits mailing list | > | ghc-commits at haskell.org | > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > | | | -- | Mateusz K. | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From michael at snoyman.com Thu Jul 23 13:42:52 2015 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 23 Jul 2015 13:42:52 +0000 Subject: Improving the "Get Haskell Experience" In-Reply-To: References: Message-ID: On Thu, Jul 23, 2015 at 1:15 AM Heinrich Apfelmus wrote: > Mark Lentczner wrote: > > *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop > > shipping pre-built packages, so we banish cabal hell, and have a single > > common way to 'get Haskell' that just works.* > > > > [..] > > > > We think this plan solves many different community needs: > > > > - We have a clear way to "get Haskell" that works for a wide variety > of > > use cases. > > - HP installer gets much smaller, and about as minimal as a working > > installation can get. > > - By leaving most packages out of the global database, users of > > cabal-install, will now have far fewer problems. Sandbox builds > should now > > never give users "cabal hell" like warnings. > > - By building and installing the Platform packages into it's own > package > > db, users get the benefit of building and installing these common > packages > > only once per system, yet can easily bypass them for any given > project if > > desired. > > - Since the Platform packages are now built and installed as needed, > > installing on smaller systems or servers without OpenGL will work. > > Sounds great to me! Personally, I do not mind how the Haskell Platform > achieves these goals; I will simply adapt to whatever tools the platform > happens to install on my machine. > > Hopefully, they come with suitable documentation. For instance, one > thing I don't understand about stack yet is in which location it > "magically" installs GHC and packages, and how I can invoke `ghci` from > these locations. Somehow, I was unable to understand this from the FAQ. > > > > I think this FAQ entry should help[1] on the first question: > Note that stack setup installs GHC into ~/.stack/programs/$platform/ghc-$version/ and not a global location. For the second question: either `stack ghci` or `stack exec ghci` should achieve what you're looking for. The former is a bit more experimental, and does more intelligent stuff at the project level as far as loading up your code. The latter simply runs the ghci command with appropriate PATH and GHC_PACKAGE_PATH environment variables set. [1] https://github.com/commercialhaskell/stack/wiki/FAQ#i-already-have-ghc-installed-can-i-still-use-stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukexipd at gmail.com Fri Jul 24 07:40:40 2015 From: lukexipd at gmail.com (Luke Iannini) Date: Fri, 24 Jul 2015 00:40:40 -0700 Subject: GHC crashing in checkProddableBlock during linking Message-ID: Hi all, I'm encountering a crash in GHC 7.10.1 and 7.8.4 on Windows when I attempt to use Template Haskell in anything that relies on a package that contains C++; in my case, bindings to the Bullet physics engine. This is a pretty big blocker for me as I haven't found any good workarounds, so it would be awesome to get a fix in (I guess I just missed 7.10.2) I've made some progress here and a minimal reproduction if anyone can help: https://ghc.haskell.org/trac/ghc/ticket/10672 Cheers Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Jul 24 11:44:04 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 24 Jul 2015 11:44:04 +0000 Subject: RULES in binary Message-ID: Lennart In the binary library I'm seeing lots of these warnings: libraries/binary/src/Data/Binary/Get.hs:420:1: warning: Rule "getWord16le/readN" may never fire because 'getWord16le' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on this function libraries/binary/src/Data/Binary/Builder/Base.hs:510:1: warning: Rule "flush/flush" may never fire because 'flush' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on this function The warnings look right to me: currently everything is very fragile and may not work as you intend. You may want to look into this? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggreif at gmail.com Fri Jul 24 15:01:55 2015 From: ggreif at gmail.com (Gabor Greif) Date: Fri, 24 Jul 2015 17:01:55 +0200 Subject: TypeLits and type families wrt. equality Message-ID: Hi all! I have a problem with following disconnect: equalities for types as detectable by type families, while I am missing a convincing technique to do the same at the value level. (convincing means here: without resorting to unsafeCoerce) Here is a demo snippet illustrating the issue. Try to get the commented line to compile without using unsafeCoerce. ############################################################## {-# LANGUAGE DataKinds, GADTs, TypeOperators , KindSignatures, ScopedTypeVariables, TypeFamilies #-} import Data.Type.Equality import GHC.TypeLits import Data.Proxy data Path (names :: [Symbol]) where Empty :: Path '[] Longer :: KnownSymbol name => Proxy name -> Path names -> Path (name ': names) type family StripOut (name :: Symbol) (path :: [Symbol]) where StripOut name '[] = '[] StripOut name (name ': ns) = StripOut name ns StripOut n (name ': ns) = n ': StripOut name ns stripOut :: KnownSymbol name => Proxy name -> Path names -> Path (StripOut name names) stripOut _ Empty = Empty stripOut n (Longer n' path) | Just Refl <- n `sameSymbol` n' = stripOut n path --stripOut n (Longer n' path) = Longer n' (stripOut n path) ############################################################## I get the error reproduced at the end of this message. My suspicion is that we need to model type inequality (with a new built-in eliminator, perhaps?) that helps us to skip the equation "StripOut name (name ': ns) = StripOut name ns" in the case when sameSymbol would return Nothing. Any ideas? Cheers and thanks Gabor ----------------------------------------------------- Lits.hs:20:31: error: Could not deduce: StripOut name (name1 : names1) ~ (name1 : StripOut name names1) from the context: (names ~ (name1 : names1), KnownSymbol name1) bound by a pattern with constructor: Longer :: forall (name :: Symbol) (names :: [Symbol]). KnownSymbol name => Proxy name -> Path names -> Path (name : names), in an equation for stripOut at Lits.hs:20:13-26 Expected type: Path (StripOut name names) Actual type: Path (name1 : StripOut name names1) Relevant bindings include path :: Path names1 (bound at Lits.hs:20:23) n' :: Proxy name1 (bound at Lits.hs:20:20) n :: Proxy name (bound at Lits.hs:20:10) stripOut :: Proxy name -> Path names -> Path (StripOut name names) (bound at Lits.hs:18:1) In the expression: Longer n' (stripOut n path) In an equation for stripOut : stripOut n (Longer n' path) = Longer n' (stripOut n path) Failed, modules loaded: none. From acowley at gmail.com Fri Jul 24 16:31:31 2015 From: acowley at gmail.com (Anthony Cowley) Date: Fri, 24 Jul 2015 12:31:31 -0400 Subject: TypeLits and type families wrt. equality In-Reply-To: References: Message-ID: I think you are already very familiar with what I'll show here, but I figured I'd offer this alternative approach just in case. It does not directly address your type error, but does show one way of loosely steering values from the type level. https://gist.github.com/acowley/57724b6facd6a39a196f Anthony Gabor Greif writes: > Hi all! > > I have a problem with following disconnect: equalities for types as > detectable by type families, while I am missing a convincing technique > to do the same at the value level. (convincing means here: without > resorting to unsafeCoerce) > > Here is a demo snippet illustrating the issue. Try to get the > commented line to compile without using unsafeCoerce. > > ############################################################## > {-# LANGUAGE DataKinds, GADTs, TypeOperators > , KindSignatures, ScopedTypeVariables, TypeFamilies #-} > > import Data.Type.Equality > import GHC.TypeLits > import Data.Proxy > > data Path (names :: [Symbol]) where > Empty :: Path '[] > Longer :: KnownSymbol name => Proxy name -> Path names -> Path (name ': names) > > type family StripOut (name :: Symbol) (path :: [Symbol]) where > StripOut name '[] = '[] > StripOut name (name ': ns) = StripOut name ns > StripOut n (name ': ns) = n ': StripOut name ns > > stripOut :: KnownSymbol name => Proxy name -> Path names -> Path > (StripOut name names) > stripOut _ Empty = Empty > stripOut n (Longer n' path) | Just Refl <- n `sameSymbol` n' = stripOut n path > --stripOut n (Longer n' path) = Longer n' (stripOut n path) > ############################################################## > > I get the error reproduced at the end of this message. > > My suspicion is that we need to model type inequality (with a new > built-in eliminator, perhaps?) that helps us to skip the equation > "StripOut name (name ': ns) = StripOut name ns" in the case when > sameSymbol would return Nothing. > > Any ideas? > > Cheers and thanks > > Gabor > > > ----------------------------------------------------- > > > Lits.hs:20:31: error: > Could not deduce: StripOut name (name1 : names1) > ~ (name1 : StripOut name names1) > from the context: (names ~ (name1 : names1), KnownSymbol name1) > bound by a pattern with constructor: > Longer :: forall (name :: Symbol) (names :: [Symbol]). > KnownSymbol name => > Proxy name -> Path names -> Path (name : names), > in an equation for stripOut > at Lits.hs:20:13-26 > Expected type: Path (StripOut name names) > Actual type: Path (name1 : StripOut name names1) > Relevant bindings include > path :: Path names1 > (bound at Lits.hs:20:23) > n' :: Proxy name1 > (bound at Lits.hs:20:20) > n :: Proxy name > (bound at Lits.hs:20:10) > stripOut :: Proxy name -> Path names -> Path (StripOut name names) > (bound at Lits.hs:18:1) > In the expression: Longer n' (stripOut n path) > In an equation for stripOut : > stripOut n (Longer n' path) = Longer n' (stripOut n path) > Failed, modules loaded: none. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From michael at snoyman.com Fri Jul 24 18:27:00 2015 From: michael at snoyman.com (Michael Snoyman) Date: Fri, 24 Jul 2015 18:27:00 +0000 Subject: Improving the "Get Haskell Experience" In-Reply-To: References: Message-ID: On Fri, Jul 24, 2015 at 11:16 AM Heinrich Apfelmus < apfelmus at quantentunnel.de> wrote: > Michael Snoyman wrote: > > > >> Hopefully, they come with suitable documentation. For instance, one > >> thing I don't understand about stack yet is in which location it > >> "magically" installs GHC and packages, and how I can invoke `ghci` from > >> these locations. Somehow, I was unable to understand this from the FAQ. > >> > >> > > I think this FAQ entry should help[1] on the first question: > > > > [1]: https://github.com/commercialhaskell/stack/wiki/FAQ [..] > > > >> Note that stack setup installs GHC into > > ~/.stack/programs/$platform/ghc-$version/ and not a global location. > > Ah, ok. Can I assume that the non-sandboxed packages are also installed > in the ~/.stack directory? That's the other part I didn't understand. > > I'm not sure what "non-sandboxed packages" means. Do you mean snapshot-level packages? If so, yes. If you mean project-specific packages: they're all stored in the .stack-work directory of the project itself. My recommendation overall is: build a project with `stack`, and run `stack path` to get information on all of the different paths it's using for various things. > > For the second question: either `stack ghci` or `stack exec ghci` should > > achieve what you're looking for. The former is a bit more experimental, > and > > does more intelligent stuff at the project level as far as loading up > your > > code. The latter simply runs the ghci command with appropriate PATH and > > GHC_PACKAGE_PATH environment variables set. > > `stack ghci` sounds good to me, then. I really like the short startup > times of ghci and never use `cabal exec ghci` for that reason. > > I think `stack exec ghci` is what you mean, correct? > > Best regards, > Heinrich Apfelmus > > -- > http://apfelmus.nfshost.com > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From snailandmail at gmail.com Fri Jul 24 20:49:16 2015 From: snailandmail at gmail.com (Nikita Kartashov) Date: Fri, 24 Jul 2015 23:49:16 +0300 Subject: Ideas for research Message-ID: Hello ghc-devs, I?m starting a PhD program in September and in need of a topic. Could you point me to some projects that still need to be implemented or even general areas which need to be explored? https://ghc.haskell.org/trac/ghc/wiki/ProjectSuggestions page is old and probably not up-to-date. I?m not shy of coding or math, and will be able to spend time reading papers to familiarise myself with the arising problems. With regards, Nikita Kartashov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ggreif at gmail.com Sat Jul 25 10:08:35 2015 From: ggreif at gmail.com (Gabor Greif) Date: Sat, 25 Jul 2015 12:08:35 +0200 Subject: TypeLits and type families wrt. equality In-Reply-To: References: Message-ID: Hi Anthony, while I suspected that one would need to go the "value inference" route (i.e. type classes), I had no idea how to get started. So thanks for your snippet, it is very helpful. Otoh, it only strips one segment ``` haskell *GaborTEq> showPath $ stripOut (Proxy :: Proxy "Hey") (Longer (Proxy :: Proxy "Du") $ Longer (Proxy :: Proxy "Hey") $ Longer (Proxy :: Proxy "Bee") $ Longer (Proxy :: Proxy "Hey") $ Longer (Proxy :: Proxy "Hey") $ Empty) "Du -> Bee -> Hey -> Hey" ``` I'll play around a bit with FDs and see what I can figure out to make this work. Cheers, Gabor On 7/24/15, Anthony Cowley wrote: > > I think you are already very familiar with what I'll show here, but I > figured I'd offer this alternative approach just in case. It does not > directly address your type error, but does show one way of loosely steering > values from the type level. > > https://gist.github.com/acowley/57724b6facd6a39a196f > > Anthony > > Gabor Greif writes: > >> Hi all! >> >> I have a problem with following disconnect: equalities for types as >> detectable by type families, while I am missing a convincing technique >> to do the same at the value level. (convincing means here: without >> resorting to unsafeCoerce) >> >> Here is a demo snippet illustrating the issue. Try to get the >> commented line to compile without using unsafeCoerce. >> >> ############################################################## >> {-# LANGUAGE DataKinds, GADTs, TypeOperators >> , KindSignatures, ScopedTypeVariables, TypeFamilies #-} >> >> import Data.Type.Equality >> import GHC.TypeLits >> import Data.Proxy >> >> data Path (names :: [Symbol]) where >> Empty :: Path '[] >> Longer :: KnownSymbol name => Proxy name -> Path names -> Path (name ': >> names) >> >> type family StripOut (name :: Symbol) (path :: [Symbol]) where >> StripOut name '[] = '[] >> StripOut name (name ': ns) = StripOut name ns >> StripOut n (name ': ns) = n ': StripOut name ns >> >> stripOut :: KnownSymbol name => Proxy name -> Path names -> Path >> (StripOut name names) >> stripOut _ Empty = Empty >> stripOut n (Longer n' path) | Just Refl <- n `sameSymbol` n' = stripOut n >> path >> --stripOut n (Longer n' path) = Longer n' (stripOut n path) >> ############################################################## >> >> I get the error reproduced at the end of this message. >> >> My suspicion is that we need to model type inequality (with a new >> built-in eliminator, perhaps?) that helps us to skip the equation >> "StripOut name (name ': ns) = StripOut name ns" in the case when >> sameSymbol would return Nothing. >> >> Any ideas? >> >> Cheers and thanks >> >> Gabor >> >> >> ----------------------------------------------------- >> >> >> Lits.hs:20:31: error: >> Could not deduce: StripOut name (name1 : names1) >> ~ (name1 : StripOut name names1) >> from the context: (names ~ (name1 : names1), KnownSymbol name1) >> bound by a pattern with constructor: >> Longer :: forall (name :: Symbol) (names :: [Symbol]). >> KnownSymbol name => >> Proxy name -> Path names -> Path (name : >> names), >> in an equation for stripOut >> at Lits.hs:20:13-26 >> Expected type: Path (StripOut name names) >> Actual type: Path (name1 : StripOut name names1) >> Relevant bindings include >> path :: Path names1 >> (bound at Lits.hs:20:23) >> n' :: Proxy name1 >> (bound at Lits.hs:20:20) >> n :: Proxy name >> (bound at Lits.hs:20:10) >> stripOut :: Proxy name -> Path names -> Path (StripOut name names) >> (bound at Lits.hs:18:1) >> In the expression: Longer n' (stripOut n path) >> In an equation for stripOut : >> stripOut n (Longer n' path) = Longer n' (stripOut n path) >> Failed, modules loaded: none. >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From nikita at karetnikov.org Sat Jul 25 17:46:46 2015 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Sat, 25 Jul 2015 20:46:46 +0300 Subject: Handling overflow and division by zero In-Reply-To: <0b59f46065264e4f8d244feed3a1b34b@DB4PR30MB030.064d.mgd.msft.net> (Simon Peyton Jones's message of "Mon, 29 Jun 2015 07:00:53 +0000") References: <87wpyn4h00.fsf@karetnikov.org> <0b59f46065264e4f8d244feed3a1b34b@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87k2toruyh.fsf@karetnikov.org> > I'm no expert on arithmetic, but I'd have thought that a well-designed > and well-documented plan for handling arithmetic exceptions (as > values) would be good. > > Start a wiki page on the GHC Trac! > > Are there primops for Int, so the only issue is making ones for other types? I've just put my notes here: https://ghc.haskell.org/trac/ghc/wiki/ImprovedArithmeticPrimops Let me know if this page doesn't answer your question. Do I need to create a ticket, too? In the testsuite, primops live in files like this: testsuite/tests/primops/should_run/T7689.hs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From pali.gabor at gmail.com Sun Jul 26 18:36:47 2015 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Sun, 26 Jul 2015 20:36:47 +0200 Subject: Deleting sync-all In-Reply-To: References: Message-ID: Hi Thomas, 2015-07-21 12:45 GMT+02:00 Thomas Miedema : > To get the sources: > > git clone --recursive git://git.haskell.org/ghc.git > cd ghc > git clone git://git.haskell.org/ghc-tarballs.git # Windows only Apparently, that last line is also needed even on non-Windows systems when one wants to make the "sdist" target, at least as I have observed on my builders, e.g. [1]. So I have put together a small patch that aims to fix this -- mind you, I have not tested it on Windows, but theoretically it shall just work: --- a/ghc.mk +++ b/ghc.mk @@ -1183,9 +1183,14 @@ sdist-windows-tarballs: sdist-windows-tarballs-prep sdist-testsuite: sdist-testsuite-prep cd $(SRC_DIST_TESTSUITE_ROOT) && "$(TAR_CMD)" chf - $(SRC_DIST_BASE_NAME) 2> testsuite_log | $(TAR_COMP_CMD) -c > $(TOP)/$(SRC_DIST_TESTSUITE_TARBALL) +SDIST_TARGETS= sdist-ghc sdist-testsuite + +ifeq "$(Windows_Host)" "YES" +SDIST_TARGETS+= sdist-windows-tarballs +endif .PHONY: sdist -sdist : sdist-ghc sdist-windows-tarballs sdist-testsuite +sdist : $(SDIST_TARGETS) sdist-manifest : $(SRC_DIST_GHC_TARBALL) tar tjf $(SRC_DIST_GHC_TARBALL) | sed "s|^ghc-$(ProjectVersion)/||" | sort >sdist-manifest diff --git a/utils/haddock b/utils/haddock Are there any objections to commit this? Thanks, G?bor [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-head/700/15.html From kolmodin at gmail.com Sun Jul 26 20:50:16 2015 From: kolmodin at gmail.com (Lennart Kolmodin) Date: Sun, 26 Jul 2015 22:50:16 +0200 Subject: RULES in binary In-Reply-To: References: Message-ID: Yes, this has been on my todo for a long time :) Essentially all inlinings/rules in binary should be gone through and confirmed whether they're still needed. I had a look now to get some insight. Since a few versions GHC warns in this way when something might not go the way it was intended, a great way to learn more about how inlining and rules work and to avoid surprises. All these warnings are proof of my poor understanding when I implemented it. Naturally it should all be fixed. Here's how I reasoned when implementing it; In Data.Binary.Get we have functions we always want to inline, even if GHC doesn't think it's a good idea. Therefore there are both INLINE pragmas as well as RULES to achieve this. GHC now warns that the function might get inlined before the rule triggers, which is ok since they do the same thing. We should probably re-evaluate whether always inlining still is a good idea. If it is, we can keep the RULES to inline, and change the INLINE to NOINLINE and let the RULES do their job. In Data.Binary.Internal.Get we attempt a trick where applicative code can become more efficient. It tries to rewrite the components of an expression "f <*> g <*> h" into something that does f, g and h with a single bounds check (the check for "do we have enough input bytes to continue?"). This trick relies so much on that the user's code has been inlined properly that it probably very rarely fires in a real application. It does wonders in the unrealistic micro benchmark, though :) Probably those rules can be removed without any real code suffering. I'd like to add some more real world benchmarks, and finally test with the changes proposed above. Lennart 2015-07-24 13:44 GMT+02:00 Simon Peyton Jones : > Lennart > > In the binary library I?m seeing lots of these warnings: > > libraries/binary/src/Data/Binary/Get.hs:420:1: warning: > > Rule "getWord16le/readN" may never fire > > because ?getWord16le? might inline first > > Probable fix: add an INLINE[n] or NOINLINE[n] pragma on this function > > > > libraries/binary/src/Data/Binary/Builder/Base.hs:510:1: warning: > > Rule "flush/flush" may never fire > > because ?flush? might inline first > > Probable fix: add an INLINE[n] or NOINLINE[n] pragma on this function > > The warnings look right to me: currently everything is very fragile and > may not work as you intend. > > You may want to look into this? > > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Jul 26 21:06:15 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 26 Jul 2015 23:06:15 +0200 Subject: RULES in binary In-Reply-To: References: Message-ID: <1437944775.1314.4.camel@joachim-breitner.de> Hi, Am Sonntag, den 26.07.2015, 22:50 +0200 schrieb Lennart Kolmodin: > This trick relies so much on that the user's code has been inlined > properly that it probably very rarely fires in a real application. It > does wonders in the unrealistic micro benchmark, though :) what is the name of the rule? Can you find it on this list: https://gist.github.com/nomeata/071c1f87450cf668bbeb Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Mon Jul 27 08:02:32 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 27 Jul 2015 08:02:32 +0000 Subject: RULES in binary In-Reply-To: References: Message-ID: Terrific. If a RULE and an inlining ?do the same thing?, the RULE is usually to be preferred because it duplicates less code. Simon From: Lennart Kolmodin [mailto:kolmodin at gmail.com] Sent: 26 July 2015 21:50 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: RULES in binary Yes, this has been on my todo for a long time :) Essentially all inlinings/rules in binary should be gone through and confirmed whether they're still needed. I had a look now to get some insight. Since a few versions GHC warns in this way when something might not go the way it was intended, a great way to learn more about how inlining and rules work and to avoid surprises. All these warnings are proof of my poor understanding when I implemented it. Naturally it should all be fixed. Here's how I reasoned when implementing it; In Data.Binary.Get we have functions we always want to inline, even if GHC doesn't think it's a good idea. Therefore there are both INLINE pragmas as well as RULES to achieve this. GHC now warns that the function might get inlined before the rule triggers, which is ok since they do the same thing. We should probably re-evaluate whether always inlining still is a good idea. If it is, we can keep the RULES to inline, and change the INLINE to NOINLINE and let the RULES do their job. In Data.Binary.Internal.Get we attempt a trick where applicative code can become more efficient. It tries to rewrite the components of an expression "f <*> g <*> h" into something that does f, g and h with a single bounds check (the check for "do we have enough input bytes to continue?"). This trick relies so much on that the user's code has been inlined properly that it probably very rarely fires in a real application. It does wonders in the unrealistic micro benchmark, though :) Probably those rules can be removed without any real code suffering. I'd like to add some more real world benchmarks, and finally test with the changes proposed above. Lennart 2015-07-24 13:44 GMT+02:00 Simon Peyton Jones >: Lennart In the binary library I?m seeing lots of these warnings: libraries/binary/src/Data/Binary/Get.hs:420:1: warning: Rule "getWord16le/readN" may never fire because ?getWord16le? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on this function libraries/binary/src/Data/Binary/Builder/Base.hs:510:1: warning: Rule "flush/flush" may never fire because ?flush? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on this function The warnings look right to me: currently everything is very fragile and may not work as you intend. You may want to look into this? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Jul 27 08:11:26 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 27 Jul 2015 08:11:26 +0000 Subject: Handling overflow and division by zero In-Reply-To: <87k2toruyh.fsf@karetnikov.org> References: <87wpyn4h00.fsf@karetnikov.org> <0b59f46065264e4f8d244feed3a1b34b@DB4PR30MB030.064d.mgd.msft.net> <87k2toruyh.fsf@karetnikov.org> Message-ID: <720d9b09dc7644b5a6f6452cde7fac94@DB4PR30MB030.064d.mgd.msft.net> | Do I need to create a ticket, too? Yes, it's always a good idea to create a ticket to say what you are doing track progress give an opportunity for others to comment Simon | -----Original Message----- | From: Nikita Karetnikov [mailto:nikita at karetnikov.org] | Sent: 25 July 2015 18:47 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: Handling overflow and division by zero | | > I'm no expert on arithmetic, but I'd have thought that a well- | designed | > and well-documented plan for handling arithmetic exceptions (as | > values) would be good. | > | > Start a wiki page on the GHC Trac! | > | > Are there primops for Int, so the only issue is making ones for | other types? | | I've just put my notes here: | https://ghc.haskell.org/trac/ghc/wiki/ImprovedArithmeticPrimops | | Let me know if this page doesn't answer your question. | | Do I need to create a ticket, too? In the testsuite, primops live in | files like this: testsuite/tests/primops/should_run/T7689.hs From thomasmiedema at gmail.com Mon Jul 27 08:41:26 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Mon, 27 Jul 2015 10:41:26 +0200 Subject: Deleting sync-all In-Reply-To: References: Message-ID: Hi G?bor, instead of changing `ghc.mk`, please change the builder script to also run `git clone git://git.haskell.org/ghc-tarballs.git`. (Edit: while typing this, I saw you just did so) The benefits are: * the windows specific part of creating a source distribution also gets tested * the release manager can run `make sdist` on any platform, and they'll get a complete source distribution they can upload Thomas On Sun, Jul 26, 2015 at 8:36 PM, P?li G?bor J?nos wrote: > Hi Thomas, > > 2015-07-21 12:45 GMT+02:00 Thomas Miedema : > > To get the sources: > > > > git clone --recursive git://git.haskell.org/ghc.git > > cd ghc > > git clone git://git.haskell.org/ghc-tarballs.git # Windows only > > Apparently, that last line is also needed even on non-Windows systems > when one wants to make the "sdist" target, at least as I have observed > on my builders, e.g. [1]. > > So I have put together a small patch that aims to fix this -- mind > you, I have not tested it on Windows, but theoretically it shall just > work: > > --- a/ghc.mk > +++ b/ghc.mk > @@ -1183,9 +1183,14 @@ sdist-windows-tarballs: sdist-windows-tarballs-prep > sdist-testsuite: sdist-testsuite-prep > cd $(SRC_DIST_TESTSUITE_ROOT) && "$(TAR_CMD)" chf - > $(SRC_DIST_BASE_NAME) 2> testsuite_log | $(TAR_COMP_CMD) > -c > $(TOP)/$(SRC_DIST_TESTSUITE_TARBALL) > > +SDIST_TARGETS= sdist-ghc sdist-testsuite > + > +ifeq "$(Windows_Host)" "YES" > +SDIST_TARGETS+= sdist-windows-tarballs > +endif > > .PHONY: sdist > -sdist : sdist-ghc sdist-windows-tarballs sdist-testsuite > +sdist : $(SDIST_TARGETS) > > sdist-manifest : $(SRC_DIST_GHC_TARBALL) > tar tjf $(SRC_DIST_GHC_TARBALL) | sed > "s|^ghc-$(ProjectVersion)/||" | sort >sdist-manifest > diff --git a/utils/haddock b/utils/haddock > > Are there any objections to commit this? > > Thanks, > G?bor > > [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-head/700/15.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kolmodin at gmail.com Mon Jul 27 09:47:56 2015 From: kolmodin at gmail.com (Lennart Kolmodin) Date: Mon, 27 Jul 2015 11:47:56 +0200 Subject: RULES in binary In-Reply-To: <1437944775.1314.4.camel@joachim-breitner.de> References: <1437944775.1314.4.camel@joachim-breitner.de> Message-ID: 2015-07-26 23:06 GMT+02:00 Joachim Breitner : > Hi, > > Am Sonntag, den 26.07.2015, 22:50 +0200 schrieb Lennart Kolmodin: > > This trick relies so much on that the user's code has been inlined > > properly that it probably very rarely fires in a real application. It > > does wonders in the unrealistic micro benchmark, though :) > > what is the name of the rule? Can you find it on this list: > https://gist.github.com/nomeata/071c1f87450cf668bbeb The rules; {-# RULES "<$> to <*>" forall f g. (<$>) f g = returnG f <*> g "readN/readN merge" forall n m f g. apG (readN n f) (readN m g) = readN (n+m) (\bs -> f bs $ g (B.unsafeDrop n bs)) "returnG/readN swap" [~1] forall f. returnG f = readN 0 (const f) "readN 0/returnG swapback" [1] forall f. readN 0 f = returnG (f B.empty) #-} >From your list (all of stackage with -ddump-rule-firings? brilliant! :)); 399 Rule fired: <$> to <*> 106 Rule fired: readN/readN merge 1373 Rule fired: returnG/readN swap 2351 Rule fired: readN 0/returnG swapback The "readN/readN merge" rule is what gives the speedup, the other rules are needed just to get the code lined up for the merge rule to fire. So it fired 106 times. That's not a lot. When compiling one of the binary benchmarks it fires 33 times. It might fire less often than it could, because the "<$> to <*>" rule might not get to fire as often as it wants (just like the warning says). But, I can't slap a INLINE or NOINLINE on <$> though, since it's not part of the binary library. So even if it does fire for some program out there, I'm still inclined to remove the rules. It's a little bit too much black magic. Lennart > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kolmodin at gmail.com Mon Jul 27 10:02:26 2015 From: kolmodin at gmail.com (Lennart Kolmodin) Date: Mon, 27 Jul 2015 12:02:26 +0200 Subject: RULES in binary In-Reply-To: References: Message-ID: 2015-07-27 10:02 GMT+02:00 Simon Peyton Jones : > Terrific. > > > > If a RULE and an inlining ?do the same thing?, the RULE is usually to be > preferred because it duplicates less code. > As I've understood it, I'll still need an (NO)INLINE pragma. GHC will warn that the RULE might not fire since the function might get inlined, and GHC might inline without me explicitly annotating with the INLINE pragma. I could change the INLINE to NOINLINE and always let the RULE do the job. Right? > > > Simon > > > > *From:* Lennart Kolmodin [mailto:kolmodin at gmail.com] > *Sent:* 26 July 2015 21:50 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: RULES in binary > > > > Yes, this has been on my todo for a long time :) > > Essentially all inlinings/rules in binary should be gone through and > confirmed whether they're still needed. > > I had a look now to get some insight. > > > > Since a few versions GHC warns in this way when something might not go the > way it was intended, a great way to learn more about how inlining and rules > work and to avoid surprises. > > All these warnings are proof of my poor understanding when I implemented > it. Naturally it should all be fixed. > > > > Here's how I reasoned when implementing it; > > In Data.Binary.Get we have functions we always want to inline, even if GHC > doesn't think it's a good idea. Therefore there are both INLINE pragmas as > well as RULES to achieve this. GHC now warns that the function might get > inlined before the rule triggers, which is ok since they do the same thing. > > We should probably re-evaluate whether always inlining still is a good > idea. If it is, we can keep the RULES to inline, and change the INLINE to > NOINLINE and let the RULES do their job. > > > > In Data.Binary.Internal.Get we attempt a trick where applicative code can > become more efficient. It tries to rewrite the components of an expression > "f <*> g <*> h" into something that does f, g and h with a single bounds > check (the check for "do we have enough input bytes to continue?"). > > This trick relies so much on that the user's code has been inlined > properly that it probably very rarely fires in a real application. It does > wonders in the unrealistic micro benchmark, though :) > > Probably those rules can be removed without any real code suffering. I'd > like to add some more real world benchmarks, and finally test with the > changes proposed above. > > > > Lennart > > > > > > 2015-07-24 13:44 GMT+02:00 Simon Peyton Jones : > > Lennart > > In the binary library I?m seeing lots of these warnings: > > libraries/binary/src/Data/Binary/Get.hs:420:1: warning: > > Rule "getWord16le/readN" may never fire > > because ?getWord16le? might inline first > > Probable fix: add an INLINE[n] or NOINLINE[n] pragma on this function > > > > libraries/binary/src/Data/Binary/Builder/Base.hs:510:1: warning: > > Rule "flush/flush" may never fire > > because ?flush? might inline first > > Probable fix: add an INLINE[n] or NOINLINE[n] pragma on this function > > The warnings look right to me: currently everything is very fragile and > may not work as you intend. > > You may want to look into this? > > Simon > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Jul 27 10:43:44 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 27 Jul 2015 10:43:44 +0000 Subject: RULES in binary In-Reply-To: References: Message-ID: <63a298f4113c460ebe335726d2aeb8e8@DB4PR30MB030.064d.mgd.msft.net> Correct. Or if you want the inlning, you can delay it by saying INLINE [n], or indeed NOINLINE [n], which will ensure that the inlining does not happen until phase n S From: Lennart Kolmodin [mailto:kolmodin at gmail.com] Sent: 27 July 2015 11:02 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: RULES in binary 2015-07-27 10:02 GMT+02:00 Simon Peyton Jones >: Terrific. If a RULE and an inlining ?do the same thing?, the RULE is usually to be preferred because it duplicates less code. As I've understood it, I'll still need an (NO)INLINE pragma. GHC will warn that the RULE might not fire since the function might get inlined, and GHC might inline without me explicitly annotating with the INLINE pragma. I could change the INLINE to NOINLINE and always let the RULE do the job. Right? Simon From: Lennart Kolmodin [mailto:kolmodin at gmail.com] Sent: 26 July 2015 21:50 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: RULES in binary Yes, this has been on my todo for a long time :) Essentially all inlinings/rules in binary should be gone through and confirmed whether they're still needed. I had a look now to get some insight. Since a few versions GHC warns in this way when something might not go the way it was intended, a great way to learn more about how inlining and rules work and to avoid surprises. All these warnings are proof of my poor understanding when I implemented it. Naturally it should all be fixed. Here's how I reasoned when implementing it; In Data.Binary.Get we have functions we always want to inline, even if GHC doesn't think it's a good idea. Therefore there are both INLINE pragmas as well as RULES to achieve this. GHC now warns that the function might get inlined before the rule triggers, which is ok since they do the same thing. We should probably re-evaluate whether always inlining still is a good idea. If it is, we can keep the RULES to inline, and change the INLINE to NOINLINE and let the RULES do their job. In Data.Binary.Internal.Get we attempt a trick where applicative code can become more efficient. It tries to rewrite the components of an expression "f <*> g <*> h" into something that does f, g and h with a single bounds check (the check for "do we have enough input bytes to continue?"). This trick relies so much on that the user's code has been inlined properly that it probably very rarely fires in a real application. It does wonders in the unrealistic micro benchmark, though :) Probably those rules can be removed without any real code suffering. I'd like to add some more real world benchmarks, and finally test with the changes proposed above. Lennart 2015-07-24 13:44 GMT+02:00 Simon Peyton Jones >: Lennart In the binary library I?m seeing lots of these warnings: libraries/binary/src/Data/Binary/Get.hs:420:1: warning: Rule "getWord16le/readN" may never fire because ?getWord16le? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on this function libraries/binary/src/Data/Binary/Builder/Base.hs:510:1: warning: Rule "flush/flush" may never fire because ?flush? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on this function The warnings look right to me: currently everything is very fragile and may not work as you intend. You may want to look into this? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Mon Jul 27 12:34:25 2015 From: lonetiger at gmail.com (Tamar Christina) Date: Mon, 27 Jul 2015 05:34:25 -0700 Subject: Deleting sync-all Message-ID: <-1434353498914242025@unknownmsgid> Hi There is a sorta in limbo differential from gintas that would have solved this by doing it in the configure script. I liked that solution. As far as I know the patch was delayed because the reviewers suggested we get rid of the perl dependency first. Regards, Tamar ------------------------------ From: Thomas Miedema Sent: ?7/?27/?2015 10:41 To: P?li G?bor J?nos Cc: ghc-devs at haskell.org Subject: Re: Deleting sync-all Hi G?bor, instead of changing `ghc.mk`, please change the builder script to also run `git clone git://git.haskell.org/ghc-tarballs.git`. (Edit: while typing this, I saw you just did so) The benefits are: * the windows specific part of creating a source distribution also gets tested * the release manager can run `make sdist` on any platform, and they'll get a complete source distribution they can upload Thomas On Sun, Jul 26, 2015 at 8:36 PM, P?li G?bor J?nos wrote: > Hi Thomas, > > 2015-07-21 12:45 GMT+02:00 Thomas Miedema : > > To get the sources: > > > > git clone --recursive git://git.haskell.org/ghc.git > > cd ghc > > git clone git://git.haskell.org/ghc-tarballs.git # Windows only > > Apparently, that last line is also needed even on non-Windows systems > when one wants to make the "sdist" target, at least as I have observed > on my builders, e.g. [1]. > > So I have put together a small patch that aims to fix this -- mind > you, I have not tested it on Windows, but theoretically it shall just > work: > > --- a/ghc.mk > +++ b/ghc.mk > @@ -1183,9 +1183,14 @@ sdist-windows-tarballs: sdist-windows-tarballs-prep > sdist-testsuite: sdist-testsuite-prep > cd $(SRC_DIST_TESTSUITE_ROOT) && "$(TAR_CMD)" chf - > $(SRC_DIST_BASE_NAME) 2> testsuite_log | $(TAR_COMP_CMD) > -c > $(TOP)/$(SRC_DIST_TESTSUITE_TARBALL) > > +SDIST_TARGETS= sdist-ghc sdist-testsuite > + > +ifeq "$(Windows_Host)" "YES" > +SDIST_TARGETS+= sdist-windows-tarballs > +endif > > .PHONY: sdist > -sdist : sdist-ghc sdist-windows-tarballs sdist-testsuite > +sdist : $(SDIST_TARGETS) > > sdist-manifest : $(SRC_DIST_GHC_TARBALL) > tar tjf $(SRC_DIST_GHC_TARBALL) | sed > "s|^ghc-$(ProjectVersion)/||" | sort >sdist-manifest > diff --git a/utils/haddock b/utils/haddock > > Are there any objections to commit this? > > Thanks, > G?bor > > [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-head/700/15.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon Jul 27 13:48:44 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 27 Jul 2015 13:48:44 +0000 Subject: TypeLits and type families wrt. equality In-Reply-To: References: Message-ID: Yes. Here's a simpler example: ===================================== type family Equal a b where Equal a a = 'True Equal a b = 'False foo :: Proxy 'True -> Bool foo x = True f :: forall a b. Maybe (a :~: b) -> Bool f x = case x of Just Refl -> True Nothing -> foo (undefined :: Proxy (Equal a b)) ===================================== In the 'Nothing' branch of the case, we know that a is not equal to b; but we don't exploit that negative information when trying to reduce (Equal a b). Making type inference (and system FC) exploit negative info would be a Big Deal, I think. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Gabor Greif | Sent: 24 July 2015 16:02 | To: ghc-devs; Richard Eisenberg | Subject: TypeLits and type families wrt. equality | | Hi all! | | I have a problem with following disconnect: equalities for types as | detectable by type families, while I am missing a convincing technique | to do the same at the value level. (convincing means here: without | resorting to unsafeCoerce) | | Here is a demo snippet illustrating the issue. Try to get the | commented line to compile without using unsafeCoerce. | | ############################################################## | {-# LANGUAGE DataKinds, GADTs, TypeOperators | , KindSignatures, ScopedTypeVariables, TypeFamilies #-} | | import Data.Type.Equality | import GHC.TypeLits | import Data.Proxy | | data Path (names :: [Symbol]) where | Empty :: Path '[] | Longer :: KnownSymbol name => Proxy name -> Path names -> Path (name | ': names) | | type family StripOut (name :: Symbol) (path :: [Symbol]) where | StripOut name '[] = '[] | StripOut name (name ': ns) = StripOut name ns | StripOut n (name ': ns) = n ': StripOut name ns | | stripOut :: KnownSymbol name => Proxy name -> Path names -> Path | (StripOut name names) | stripOut _ Empty = Empty | stripOut n (Longer n' path) | Just Refl <- n `sameSymbol` n' = | stripOut n path | --stripOut n (Longer n' path) = Longer n' (stripOut n path) | ############################################################## | | I get the error reproduced at the end of this message. | | My suspicion is that we need to model type inequality (with a new | built-in eliminator, perhaps?) that helps us to skip the equation | "StripOut name (name ': ns) = StripOut name ns" in the case when | sameSymbol would return Nothing. | | Any ideas? | | Cheers and thanks | | Gabor | | | ----------------------------------------------------- | | | Lits.hs:20:31: error: | Could not deduce: StripOut name (name1 : names1) | ~ (name1 : StripOut name names1) | from the context: (names ~ (name1 : names1), KnownSymbol name1) | bound by a pattern with constructor: | Longer :: forall (name :: Symbol) (names :: | [Symbol]). | KnownSymbol name => | Proxy name -> Path names -> Path (name : | names), | in an equation for stripOut | at Lits.hs:20:13-26 | Expected type: Path (StripOut name names) | Actual type: Path (name1 : StripOut name names1) | Relevant bindings include | path :: Path names1 | (bound at Lits.hs:20:23) | n' :: Proxy name1 | (bound at Lits.hs:20:20) | n :: Proxy name | (bound at Lits.hs:20:10) | stripOut :: Proxy name -> Path names -> Path (StripOut name | names) | (bound at Lits.hs:18:1) | In the expression: Longer n' (stripOut n path) | In an equation for stripOut : | stripOut n (Longer n' path) = Longer n' (stripOut n path) | Failed, modules loaded: none. | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ggreif at gmail.com Mon Jul 27 14:36:16 2015 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 27 Jul 2015 16:36:16 +0200 Subject: TypeLits and type families wrt. equality In-Reply-To: References: Message-ID: Simon, yes, this is the the same problem. You probably meant: ===================================== type family Equal a b where Equal a a = 'True Equal a b = 'False foo :: Proxy 'False -> Bool foo x = False f :: forall a b. Maybe (a :~: b) -> Bool f x = case x of Just Refl -> True Nothing -> foo (undefined :: Proxy (Equal a b)) ===================================== When saying "Big Deal" did you mean - highly desirable and somebody should go for it - or a terrible amount of work, and who tackles it is probably a fool on a hubris trip? (I still have my problems deciphering British irony.) I guess a full-blown solution is too much work for now (also considering previous comments from Richard). But what about a simpler construct decideRefl :: Proxy (a :: Symbol) -> Proxy b -> Proxy (Equal a b :~: 'False) -> Either (Equal a b :~: 'False) (a :~: b) The Right case is just rewrapping the Refl from a `sameSymbol`, while the Left injection would suppress the clause "Equal a a = 'True" from the type family, knowing that it cannot contribute to an outcome, arriving at the 'False result. (I have no idea how this could be represented in Core, though.) What do you think? Cheers, Gabor On 7/27/15, Simon Peyton Jones wrote: > Yes. Here's a simpler example: > > ===================================== > type family Equal a b where > Equal a a = 'True > Equal a b = 'False > > foo :: Proxy 'True -> Bool > foo x = True > > f :: forall a b. Maybe (a :~: b) -> Bool > f x = case x of > Just Refl -> True > Nothing -> foo (undefined :: Proxy (Equal a b)) > ===================================== > > In the 'Nothing' branch of the case, we know that a is not equal to b; but > we don't exploit that negative information when trying to reduce (Equal a > b). > > Making type inference (and system FC) exploit negative info would be a Big > Deal, I think. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Gabor Greif > | Sent: 24 July 2015 16:02 > | To: ghc-devs; Richard Eisenberg > | Subject: TypeLits and type families wrt. equality > | > | Hi all! > | > | I have a problem with following disconnect: equalities for types as > | detectable by type families, while I am missing a convincing technique > | to do the same at the value level. (convincing means here: without > | resorting to unsafeCoerce) > | > | Here is a demo snippet illustrating the issue. Try to get the > | commented line to compile without using unsafeCoerce. > | > | ############################################################## > | {-# LANGUAGE DataKinds, GADTs, TypeOperators > | , KindSignatures, ScopedTypeVariables, TypeFamilies #-} > | > | import Data.Type.Equality > | import GHC.TypeLits > | import Data.Proxy > | > | data Path (names :: [Symbol]) where > | Empty :: Path '[] > | Longer :: KnownSymbol name => Proxy name -> Path names -> Path (name > | ': names) > | > | type family StripOut (name :: Symbol) (path :: [Symbol]) where > | StripOut name '[] = '[] > | StripOut name (name ': ns) = StripOut name ns > | StripOut n (name ': ns) = n ': StripOut name ns > | > | stripOut :: KnownSymbol name => Proxy name -> Path names -> Path > | (StripOut name names) > | stripOut _ Empty = Empty > | stripOut n (Longer n' path) | Just Refl <- n `sameSymbol` n' = > | stripOut n path > | --stripOut n (Longer n' path) = Longer n' (stripOut n path) > | ############################################################## > | > | I get the error reproduced at the end of this message. > | > | My suspicion is that we need to model type inequality (with a new > | built-in eliminator, perhaps?) that helps us to skip the equation > | "StripOut name (name ': ns) = StripOut name ns" in the case when > | sameSymbol would return Nothing. > | > | Any ideas? > | > | Cheers and thanks > | > | Gabor > | > | > | ----------------------------------------------------- > | > | > | Lits.hs:20:31: error: > | Could not deduce: StripOut name (name1 : names1) > | ~ (name1 : StripOut name names1) > | from the context: (names ~ (name1 : names1), KnownSymbol name1) > | bound by a pattern with constructor: > | Longer :: forall (name :: Symbol) (names :: > | [Symbol]). > | KnownSymbol name => > | Proxy name -> Path names -> Path (name : > | names), > | in an equation for stripOut > | at Lits.hs:20:13-26 > | Expected type: Path (StripOut name names) > | Actual type: Path (name1 : StripOut name names1) > | Relevant bindings include > | path :: Path names1 > | (bound at Lits.hs:20:23) > | n' :: Proxy name1 > | (bound at Lits.hs:20:20) > | n :: Proxy name > | (bound at Lits.hs:20:10) > | stripOut :: Proxy name -> Path names -> Path (StripOut name > | names) > | (bound at Lits.hs:18:1) > | In the expression: Longer n' (stripOut n path) > | In an equation for stripOut : > | stripOut n (Longer n' path) = Longer n' (stripOut n path) > | Failed, modules loaded: none. > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From eir at cis.upenn.edu Mon Jul 27 14:38:10 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 27 Jul 2015 10:38:10 -0400 Subject: TypeLits and type families wrt. equality In-Reply-To: References: Message-ID: <032932E9-A521-42EB-89F9-7812AC827895@cis.upenn.edu> On Jul 27, 2015, at 9:48 AM, Simon Peyton Jones wrote: > > Making type inference (and system FC) exploit negative info would be a Big Deal, I think. Yes. Gabor points out a known infelicity with the interaction between closed type families and GADTs. But I agree with Simon that fixing it would indeed be a Big Deal, and not yet worth the very considerable effort required. Richard From eir at cis.upenn.edu Mon Jul 27 14:44:41 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 27 Jul 2015 10:44:41 -0400 Subject: TypeLits and type families wrt. equality In-Reply-To: References: Message-ID: <90033B89-063A-413B-B5FD-4BAD25A07B54@cis.upenn.edu> On Jul 27, 2015, at 10:36 AM, Gabor Greif wrote: > When saying "Big Deal" did you mean > - highly desirable and somebody should go for it > - or a terrible amount of work, and who tackles it is probably a > fool on a hubris trip? > > (I still have my problems deciphering British irony.) My use of Big Deal here is more your second option, but without so much negativity. :) I'm sure the person who tackled this problem would learn a ton and contribute to programming language research. It's just that we haven't yet found a great motivation for doing so. > > I guess a full-blown solution is too much work for now (also considering > previous comments from Richard). But what about a simpler construct > > decideRefl :: Proxy (a :: Symbol) -> Proxy b > -> Proxy (Equal a b :~: 'False) > -> Either (Equal a b :~: 'False) (a :~: b) I believe that this function could be written only with the help of unsafeCoerce. Indeed, the `singletons` package provides an `SDecide` instance for the type-lits (which accomplishes a similar, though not identical, goal) via unsafeCoerce. Richard From ggreif at gmail.com Mon Jul 27 14:56:36 2015 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 27 Jul 2015 16:56:36 +0200 Subject: TypeLits and type families wrt. equality In-Reply-To: <90033B89-063A-413B-B5FD-4BAD25A07B54@cis.upenn.edu> References: <90033B89-063A-413B-B5FD-4BAD25A07B54@cis.upenn.edu> Message-ID: On 7/27/15, Richard Eisenberg wrote: > > On Jul 27, 2015, at 10:36 AM, Gabor Greif wrote: > >> When saying "Big Deal" did you mean >> - highly desirable and somebody should go for it >> - or a terrible amount of work, and who tackles it is probably a >> fool on a hubris trip? >> >> (I still have my problems deciphering British irony.) > > My use of Big Deal here is more your second option, but without so much > negativity. :) I'm sure the person who tackled this problem would learn a > ton and contribute to programming language research. It's just that we > haven't yet found a great motivation for doing so. > Okay, agreed. >> >> I guess a full-blown solution is too much work for now (also considering >> previous comments from Richard). But what about a simpler construct >> >> decideRefl :: Proxy (a :: Symbol) -> Proxy b >> -> Proxy (Equal a b :~: 'False) >> -> Either (Equal a b :~: 'False) (a :~: b) > > I believe that this function could be written only with the help of > unsafeCoerce. Indeed, the `singletons` package provides an `SDecide` > instance for the type-lits (which accomplishes a similar, though not > identical, goal) via unsafeCoerce. I doubt it could even be written with unsafeCoerce. It would need some magic sauce from the compiler, tapping into the type family normalizer. Consider: > decideRefl (Proxy :: Proxy "a") (Proxy :: Proxy "b") (Proxy :: Proxy (Equal a b :~: 'True) This should give a type error (we shouldn't fabricate false evidence!), while > decideRefl (Proxy :: Proxy "a") (Proxy :: Proxy "b") (Proxy :: Proxy (Equal a b :~: 'False) should pass the type checker and give Left Refl. Cheers, Gabor > > Richard > > From eir at cis.upenn.edu Mon Jul 27 15:08:13 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 27 Jul 2015 11:08:13 -0400 Subject: TypeLits and type families wrt. equality In-Reply-To: References: <90033B89-063A-413B-B5FD-4BAD25A07B54@cis.upenn.edu> Message-ID: On Jul 27, 2015, at 10:56 AM, Gabor Greif wrote: >>> >>> decideRefl :: Proxy (a :: Symbol) -> Proxy b >>> -> Proxy (Equal a b :~: 'False) >>> -> Either (Equal a b :~: 'False) (a :~: b) What's the point of the third Proxy argument? I don't think it adds anything. Perhaps without that the way forward (albeit still with unsafeCoerce) will become clear. Richard From ggreif at gmail.com Mon Jul 27 15:22:32 2015 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 27 Jul 2015 17:22:32 +0200 Subject: TypeLits and type families wrt. equality In-Reply-To: References: <90033B89-063A-413B-B5FD-4BAD25A07B54@cis.upenn.edu> Message-ID: On 7/27/15, Richard Eisenberg wrote: > > On Jul 27, 2015, at 10:56 AM, Gabor Greif wrote: >>>> >>>> decideRefl :: Proxy (a :: Symbol) -> Proxy b >>>> -> Proxy (Equal a b :~: 'False) >>>> -> Either (Equal a b :~: 'False) (a :~: b) > > What's the point of the third Proxy argument? I don't think it adds > anything. Perhaps without that the way forward (albeit still with > unsafeCoerce) will become clear. Proxy (Equal a b :~: 'False) is just the specialised version to the general issue I'd like to crack: Proxy a -> Proxy b -> Proxy ( :~: ) -> Either ( :~: ) (a :~: b) Somehow one has to communicate the equation to the compiler that should be proved under the assumption that a is not unifiable with b. Is this clearer? Sorry for the sloppy definition! Cheers, Gabor > > Richard From eir at cis.upenn.edu Mon Jul 27 15:39:54 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 27 Jul 2015 11:39:54 -0400 Subject: TypeLits and type families wrt. equality In-Reply-To: References: <90033B89-063A-413B-B5FD-4BAD25A07B54@cis.upenn.edu> Message-ID: <6F228439-1F6B-4C0A-8BF2-DE59A9157DF0@cis.upenn.edu> This works for me (with ScopedTypeVariables): > gabor :: forall a b lhs rhs. > (KnownSymbol a, KnownSymbol b) > => Proxy a -> Proxy b -> Proxy (lhs :~: rhs) > -> Either (lhs :~: rhs) (a :~: b) > gabor a b _ = case sameSymbol a b of > Just refl -> Right refl > Nothing -> Left (unsafeCoerce Refl) > Does this do what you want? Richard On Jul 27, 2015, at 11:22 AM, Gabor Greif wrote: > On 7/27/15, Richard Eisenberg wrote: >> >> On Jul 27, 2015, at 10:56 AM, Gabor Greif wrote: >>>>> >>>>> decideRefl :: Proxy (a :: Symbol) -> Proxy b >>>>> -> Proxy (Equal a b :~: 'False) >>>>> -> Either (Equal a b :~: 'False) (a :~: b) >> >> What's the point of the third Proxy argument? I don't think it adds >> anything. Perhaps without that the way forward (albeit still with >> unsafeCoerce) will become clear. > > Proxy (Equal a b :~: 'False) is just the specialised version to the > general issue I'd like to crack: > > Proxy a -> Proxy b > -> Proxy ( > :~: ) > -> Either ( > :~: ) > (a :~: b) > > Somehow one has to communicate the equation to the compiler that > should be proved under the assumption that a is not unifiable with b. > > Is this clearer? Sorry for the sloppy definition! > > Cheers, > > Gabor > > >> >> Richard From ggreif at gmail.com Mon Jul 27 16:04:58 2015 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 27 Jul 2015 18:04:58 +0200 Subject: TypeLits and type families wrt. equality In-Reply-To: <6F228439-1F6B-4C0A-8BF2-DE59A9157DF0@cis.upenn.edu> References: <90033B89-063A-413B-B5FD-4BAD25A07B54@cis.upenn.edu> <6F228439-1F6B-4C0A-8BF2-DE59A9157DF0@cis.upenn.edu> Message-ID: On 7/27/15, Richard Eisenberg wrote: > This works for me (with ScopedTypeVariables): > >> gabor :: forall a b lhs rhs. >> (KnownSymbol a, KnownSymbol b) >> => Proxy a -> Proxy b -> Proxy (lhs :~: rhs) >> -> Either (lhs :~: rhs) (a :~: b) >> gabor a b _ = case sameSymbol a b of >> Just refl -> Right refl >> Nothing -> Left (unsafeCoerce Refl) >> > This is basically what I am doing now. Namely using unsafeCoerce. But this is not what I am after. Namely a safe way to exploit negative evidence coming from sameSymbol. I want a (weak form of) decidable type-level equality, where I either get a witness that a and b are equal (just like sameSymbol works now) or alternatively a different witness that a type function evaluates to some type under the assumption that a is not b. This is the interesting part, as the type family could get stuck without this knowledge as my original example illustrates (and also Simon's). The goal is not only to obtain *some* witness, but to never obtain a bad witness this way (i.e. never get something like 'True :~: 'False). Cheers, Gabor > > Does this do what you want? > > Richard > > On Jul 27, 2015, at 11:22 AM, Gabor Greif wrote: > >> On 7/27/15, Richard Eisenberg wrote: >>> >>> On Jul 27, 2015, at 10:56 AM, Gabor Greif wrote: >>>>>> >>>>>> decideRefl :: Proxy (a :: Symbol) -> Proxy b >>>>>> -> Proxy (Equal a b :~: 'False) >>>>>> -> Either (Equal a b :~: 'False) (a :~: b) >>> >>> What's the point of the third Proxy argument? I don't think it adds >>> anything. Perhaps without that the way forward (albeit still with >>> unsafeCoerce) will become clear. >> >> Proxy (Equal a b :~: 'False) is just the specialised version to the >> general issue I'd like to crack: >> >> Proxy a -> Proxy b >> -> Proxy ( >> :~: ) >> -> Either ( >> :~: ) >> (a :~: b) >> >> Somehow one has to communicate the equation to the compiler that >> should be proved under the assumption that a is not unifiable with b. >> >> Is this clearer? Sorry for the sloppy definition! >> >> Cheers, >> >> Gabor >> >> >>> >>> Richard > > From thomasmiedema at gmail.com Mon Jul 27 16:25:41 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Mon, 27 Jul 2015 18:25:41 +0200 Subject: Deleting sync-all In-Reply-To: <-1434353498914242025@unknownmsgid> References: <-1434353498914242025@unknownmsgid> Message-ID: Hi Tamar, feel free to take over that patch , or extract the parts you like. It currently does (too) many things, which is part of the reason why it stalled. See my comments in #9218 . Do not wait to get rid of the perl dependency first, because it is yet unclear how to proceed (#9832 ). Thomas On Mon, Jul 27, 2015 at 2:34 PM, Tamar Christina wrote: > Hi > > There is a sorta in limbo differential from gintas that would have solved > this by doing it in the configure script. > > I liked that solution. As far as I know the patch was delayed because the > reviewers suggested we get rid of the perl dependency first. > > Regards, > Tamar > ------------------------------ > From: Thomas Miedema > Sent: ?7/?27/?2015 10:41 > To: P?li G?bor J?nos > Cc: ghc-devs at haskell.org > Subject: Re: Deleting sync-all > > Hi G?bor, > > instead of changing `ghc.mk`, please change the builder script to also > run `git clone git://git.haskell.org/ghc-tarballs.git`. > > (Edit: while typing this, I saw you just did so) > > The benefits are: > * the windows specific part of creating a source distribution also gets > tested > * the release manager can run `make sdist` on any platform, and they'll > get a complete source distribution they can upload > > Thomas > > On Sun, Jul 26, 2015 at 8:36 PM, P?li G?bor J?nos > wrote: > >> Hi Thomas, >> >> 2015-07-21 12:45 GMT+02:00 Thomas Miedema : >> > To get the sources: >> > >> > git clone --recursive git://git.haskell.org/ghc.git >> > cd ghc >> > git clone git://git.haskell.org/ghc-tarballs.git # Windows only >> >> Apparently, that last line is also needed even on non-Windows systems >> when one wants to make the "sdist" target, at least as I have observed >> on my builders, e.g. [1]. >> >> So I have put together a small patch that aims to fix this -- mind >> you, I have not tested it on Windows, but theoretically it shall just >> work: >> >> --- a/ghc.mk >> +++ b/ghc.mk >> @@ -1183,9 +1183,14 @@ sdist-windows-tarballs: sdist-windows-tarballs-prep >> sdist-testsuite: sdist-testsuite-prep >> cd $(SRC_DIST_TESTSUITE_ROOT) && "$(TAR_CMD)" chf - >> $(SRC_DIST_BASE_NAME) 2> testsuite_log | $(TAR_COMP_CMD) >> -c > $(TOP)/$(SRC_DIST_TESTSUITE_TARBALL) >> >> +SDIST_TARGETS= sdist-ghc sdist-testsuite >> + >> +ifeq "$(Windows_Host)" "YES" >> +SDIST_TARGETS+= sdist-windows-tarballs >> +endif >> >> .PHONY: sdist >> -sdist : sdist-ghc sdist-windows-tarballs sdist-testsuite >> +sdist : $(SDIST_TARGETS) >> >> sdist-manifest : $(SRC_DIST_GHC_TARBALL) >> tar tjf $(SRC_DIST_GHC_TARBALL) | sed >> "s|^ghc-$(ProjectVersion)/||" | sort >sdist-manifest >> diff --git a/utils/haddock b/utils/haddock >> >> Are there any objections to commit this? >> >> Thanks, >> G?bor >> >> [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-head/700/15.html >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Jul 27 16:53:08 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 27 Jul 2015 12:53:08 -0400 Subject: TypeLits and type families wrt. equality In-Reply-To: References: <90033B89-063A-413B-B5FD-4BAD25A07B54@cis.upenn.edu> <6F228439-1F6B-4C0A-8BF2-DE59A9157DF0@cis.upenn.edu> Message-ID: <5364DA57-5C2E-418A-AD70-F0FC3594A71E@cis.upenn.edu> It sounds like you want this, then: > gabor :: forall a b. > (KnownSymbol a, KnownSymbol b) > => Proxy a -> Proxy b > -> Either (Equal a b :~: 'False) (a :~: b) > gabor a b = case sameSymbol a b of > Just refl -> Right refl > Nothing -> Left (unsafeCoerce Refl) > It still uses unsafeCoerce, of course. There isn't really any advantage to baking the use of unsafeCoerce into GHC, as the GHC core would still use unsafeCoerce here. So, I think that -- barring the Big Deal of inventing proper inequality witnesses -- you're a little tied to unsafeCoerce. Richard On Jul 27, 2015, at 12:04 PM, Gabor Greif wrote: > On 7/27/15, Richard Eisenberg wrote: >> This works for me (with ScopedTypeVariables): >> >>> gabor :: forall a b lhs rhs. >>> (KnownSymbol a, KnownSymbol b) >>> => Proxy a -> Proxy b -> Proxy (lhs :~: rhs) >>> -> Either (lhs :~: rhs) (a :~: b) >>> gabor a b _ = case sameSymbol a b of >>> Just refl -> Right refl >>> Nothing -> Left (unsafeCoerce Refl) >>> >> > > This is basically what I am doing now. Namely using unsafeCoerce. > > But this is not what I am after. Namely a safe way to exploit negative > evidence coming from sameSymbol. I want a (weak form of) decidable > type-level equality, where I either get a witness that a and b are equal > (just like sameSymbol works now) or alternatively a different witness > that a type function evaluates to some type under the assumption that > a is not b. This is the interesting part, as the type family could get stuck > without this knowledge as my original example illustrates (and also Simon's). > > The goal is not only to obtain *some* witness, but to never obtain a bad > witness this way (i.e. never get something like 'True :~: 'False). > > Cheers, > > Gabor > > >> >> Does this do what you want? >> >> Richard >> >> On Jul 27, 2015, at 11:22 AM, Gabor Greif wrote: >> >>> On 7/27/15, Richard Eisenberg wrote: >>>> >>>> On Jul 27, 2015, at 10:56 AM, Gabor Greif wrote: >>>>>>> >>>>>>> decideRefl :: Proxy (a :: Symbol) -> Proxy b >>>>>>> -> Proxy (Equal a b :~: 'False) >>>>>>> -> Either (Equal a b :~: 'False) (a :~: b) >>>> >>>> What's the point of the third Proxy argument? I don't think it adds >>>> anything. Perhaps without that the way forward (albeit still with >>>> unsafeCoerce) will become clear. >>> >>> Proxy (Equal a b :~: 'False) is just the specialised version to the >>> general issue I'd like to crack: >>> >>> Proxy a -> Proxy b >>> -> Proxy ( >>> :~: ) >>> -> Either ( >>> :~: ) >>> (a :~: b) >>> >>> Somehow one has to communicate the equation to the compiler that >>> should be proved under the assumption that a is not unifiable with b. >>> >>> Is this clearer? Sorry for the sloppy definition! >>> >>> Cheers, >>> >>> Gabor >>> >>> >>>> >>>> Richard >> >> From simonpj at microsoft.com Mon Jul 27 16:04:37 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 27 Jul 2015 16:04:37 +0000 Subject: TypeLits and type families wrt. equality In-Reply-To: References: Message-ID: <5378b01ff6634b11bfd2fb5ff320e7e7@DB4PR30MB030.064d.mgd.msft.net> | When saying "Big Deal" did you mean | - highly desirable and somebody should go for it | - or a terrible amount of work, and who tackles it is probably a | fool on a hubris trip? I meant - a lot of work, including changes to the core System FC language - we lack enough compelling cases to justify that work But it would certainly be interesting. In short, a research exercise, not an engineering one. Simon From simonpj at microsoft.com Mon Jul 27 16:07:57 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 27 Jul 2015 16:07:57 +0000 Subject: warnings Message-ID: <787e3215ec8b4a889cbc9a95300b6bfd@DB4PR30MB030.064d.mgd.msft.net> Yurgh. I committed a patch but my validate had -Wwarn by mistake. So there are warnings in base (and binary actually). I will sort them out tomorrow. Could revert and re-apply but doesn't seem worth it. Sorry Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Tue Jul 28 03:48:35 2015 From: lonetiger at gmail.com (Tamar Christina) Date: Mon, 27 Jul 2015 20:48:35 -0700 Subject: Deleting sync-all Message-ID: <-9000163711460808430@unknownmsgid> Hi Thomas, Sure I can take care of that part. I'll make a separate issue for it. I also think we should do the first part as well eventually (using mingw-w for for both x64 and x86_64) as that solves #10435 . Regards, Tamar ------------------------------ From: Thomas Miedema Sent: ?7/?27/?2015 18:25 To: Tamar Christina Cc: P?li G?bor J?nos ; ghc-devs at haskell.org Subject: Re: Deleting sync-all Hi Tamar, feel free to take over that patch , or extract the parts you like. It currently does (too) many things, which is part of the reason why it stalled. See my comments in #9218 . Do not wait to get rid of the perl dependency first, because it is yet unclear how to proceed (#9832 ). Thomas On Mon, Jul 27, 2015 at 2:34 PM, Tamar Christina wrote: > Hi > > There is a sorta in limbo differential from gintas that would have solved > this by doing it in the configure script. > > I liked that solution. As far as I know the patch was delayed because the > reviewers suggested we get rid of the perl dependency first. > > Regards, > Tamar > ------------------------------ > From: Thomas Miedema > Sent: ?7/?27/?2015 10:41 > To: P?li G?bor J?nos > Cc: ghc-devs at haskell.org > Subject: Re: Deleting sync-all > > Hi G?bor, > > instead of changing `ghc.mk`, please change the builder script to also > run `git clone git://git.haskell.org/ghc-tarballs.git`. > > (Edit: while typing this, I saw you just did so) > > The benefits are: > * the windows specific part of creating a source distribution also gets > tested > * the release manager can run `make sdist` on any platform, and they'll > get a complete source distribution they can upload > > Thomas > > On Sun, Jul 26, 2015 at 8:36 PM, P?li G?bor J?nos > wrote: > >> Hi Thomas, >> >> 2015-07-21 12:45 GMT+02:00 Thomas Miedema : >> > To get the sources: >> > >> > git clone --recursive git://git.haskell.org/ghc.git >> > cd ghc >> > git clone git://git.haskell.org/ghc-tarballs.git # Windows only >> >> Apparently, that last line is also needed even on non-Windows systems >> when one wants to make the "sdist" target, at least as I have observed >> on my builders, e.g. [1]. >> >> So I have put together a small patch that aims to fix this -- mind >> you, I have not tested it on Windows, but theoretically it shall just >> work: >> >> --- a/ghc.mk >> +++ b/ghc.mk >> @@ -1183,9 +1183,14 @@ sdist-windows-tarballs: sdist-windows-tarballs-prep >> sdist-testsuite: sdist-testsuite-prep >> cd $(SRC_DIST_TESTSUITE_ROOT) && "$(TAR_CMD)" chf - >> $(SRC_DIST_BASE_NAME) 2> testsuite_log | $(TAR_COMP_CMD) >> -c > $(TOP)/$(SRC_DIST_TESTSUITE_TARBALL) >> >> +SDIST_TARGETS= sdist-ghc sdist-testsuite >> + >> +ifeq "$(Windows_Host)" "YES" >> +SDIST_TARGETS+= sdist-windows-tarballs >> +endif >> >> .PHONY: sdist >> -sdist : sdist-ghc sdist-windows-tarballs sdist-testsuite >> +sdist : $(SDIST_TARGETS) >> >> sdist-manifest : $(SRC_DIST_GHC_TARBALL) >> tar tjf $(SRC_DIST_GHC_TARBALL) | sed >> "s|^ghc-$(ProjectVersion)/||" | sort >sdist-manifest >> diff --git a/utils/haddock b/utils/haddock >> >> Are there any objections to commit this? >> >> Thanks, >> G?bor >> >> [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-head/700/15.html >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jul 28 07:54:41 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 28 Jul 2015 07:54:41 +0000 Subject: Trac is slow Message-ID: <9fd949e419134cf3b4e419696b49bd35@DB4PR30MB030.064d.mgd.msft.net> Trac is terribly slow today. More than 60 seconds to load a single page. Help! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jul 28 10:00:42 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 28 Jul 2015 10:00:42 +0000 Subject: warnings Message-ID: <6e0d4559d954471495f28d59b07ddc94@DB4PR30MB030.064d.mgd.msft.net> Validating now, but have to go to London for a few hrs. Meanwhile use -Wwarn! From: Simon Peyton Jones Sent: 27 July 2015 17:08 To: ghc-devs Subject: warnings Yurgh. I committed a patch but my validate had -Wwarn by mistake. So there are warnings in base (and binary actually). I will sort them out tomorrow. Could revert and re-apply but doesn't seem worth it. Sorry Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Tue Jul 28 15:14:39 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 28 Jul 2015 11:14:39 -0400 Subject: A GHC Library Message-ID: <0A0C5419-2D74-446F-BF6F-7866B1BFE52C@cis.upenn.edu> Hi devs, It has struck me that we have a vast trove of documentation about GHC in the form of academic papers, but little organization to this trove. The papers are scattered across authors' websites, and sometimes it is hard to remember what a paper is titled when searching for it. I have thus started a wiki page here: https://ghc.haskell.org/trac/ghc/wiki/Library I would love for this page to be the Definitive List of GHC-related papers. The list I've included is, of course, woefully short, but it is a starting point. Please add to it! Have you written a GHC paper? If so, make sure it's included. Thanks, Richard From eir at cis.upenn.edu Tue Jul 28 15:17:03 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 28 Jul 2015 11:17:03 -0400 Subject: Ideas for research In-Reply-To: References: Message-ID: Hi Nikita, Thanks for asking! My own interest is deeply into the type system end of the operation, so my suggestions will naturally be in that area. Ask others (perhaps authors on https://ghc.haskell.org/trac/ghc/wiki/Library) if you want other ideas. The wiki page https://ghc.haskell.org/trac/ghc/wiki/Status/RAE-Tickets lists tickets I care about. Check out the Hard and Rocket Science sections for some inspiration. Out of curiosity, where will you be starting? Do you know who your advisor will be? Richard On Jul 24, 2015, at 4:49 PM, Nikita Kartashov wrote: > Hello ghc-devs, > > I?m starting a PhD program in September and in need of a topic. Could you point me to some projects that still need to be implemented or even general areas which need to be explored? > https://ghc.haskell.org/trac/ghc/wiki/ProjectSuggestions page is old and probably not up-to-date. > I?m not shy of coding or math, and will be able to spend time reading papers to familiarise myself with the arising problems. > > With regards, > Nikita Kartashov > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From michael at snoyman.com Tue Jul 28 15:17:00 2015 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 28 Jul 2015 08:17:00 -0700 Subject: A GHC Library In-Reply-To: <0A0C5419-2D74-446F-BF6F-7866B1BFE52C@cis.upenn.edu> References: <0A0C5419-2D74-446F-BF6F-7866B1BFE52C@cis.upenn.edu> Message-ID: Hey Richard, Just a layman's bit of input: when I read "GHC Library," I immediately think of "calling the GHC API from Haskell code," not "a collection of writings about GHC organized properly." The terminology overload may cause confusion. Michael On Tue, Jul 28, 2015 at 8:14 AM, Richard Eisenberg wrote: > Hi devs, > > It has struck me that we have a vast trove of documentation about GHC in the form of academic papers, but little organization to this trove. The papers are scattered across authors' websites, and sometimes it is hard to remember what a paper is titled when searching for it. > > I have thus started a wiki page here: https://ghc.haskell.org/trac/ghc/wiki/Library > > I would love for this page to be the Definitive List of GHC-related papers. The list I've included is, of course, woefully short, but it is a starting point. Please add to it! > > Have you written a GHC paper? If so, make sure it's included. > > Thanks, > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From jan.stolarek at p.lodz.pl Tue Jul 28 15:19:17 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 28 Jul 2015 17:19:17 +0200 Subject: A GHC Library In-Reply-To: <0A0C5419-2D74-446F-BF6F-7866B1BFE52C@cis.upenn.edu> References: <0A0C5419-2D74-446F-BF6F-7866B1BFE52C@cis.upenn.edu> Message-ID: <201507281719.18068.jan.stolarek@p.lodz.pl> > I have thus started a wiki page here: > https://ghc.haskell.org/trac/ghc/wiki/Library Oh no... we aleady have such a page: https://ghc.haskell.org/trac/ghc/wiki/ReadingList And, actually, we used to have two: https://ghc.haskell.org/trac/ghc/wiki/GhcPapers But I made an effort last year and merged the contents of these two pages into one. 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. From thomasmiedema at gmail.com Tue Jul 28 15:40:50 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Tue, 28 Jul 2015 17:40:50 +0200 Subject: A GHC Library In-Reply-To: <201507281719.18068.jan.stolarek@p.lodz.pl> References: <0A0C5419-2D74-446F-BF6F-7866B1BFE52C@cis.upenn.edu> <201507281719.18068.jan.stolarek@p.lodz.pl> Message-ID: > Oh no... we aleady have such a page: > > https://ghc.haskell.org/trac/ghc/wiki/ReadingList And it's linked straight from the Commentary page: https://ghc.haskell.org/trac/ghc/wiki/Commentary There's also ?another reading list from Stephen Diehl. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jul 28 16:47:48 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 28 Jul 2015 16:47:48 +0000 Subject: warnings Message-ID: <560756a97e9447bfb19894a3afc6516d@DB4PR30MB030.064d.mgd.msft.net> Hopefully done now. Sorry about this -- really busy day S From: Simon Peyton Jones Sent: 28 July 2015 11:01 To: 'ghc-devs' Subject: RE: warnings Validating now, but have to go to London for a few hrs. Meanwhile use -Wwarn! From: Simon Peyton Jones Sent: 27 July 2015 17:08 To: ghc-devs Subject: warnings Yurgh. I committed a patch but my validate had -Wwarn by mistake. So there are warnings in base (and binary actually). I will sort them out tomorrow. Could revert and re-apply but doesn't seem worth it. Sorry Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Tue Jul 28 17:54:13 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Tue, 28 Jul 2015 19:54:13 +0200 Subject: warnings In-Reply-To: <560756a97e9447bfb19894a3afc6516d@DB4PR30MB030.064d.mgd.msft.net> References: <560756a97e9447bfb19894a3afc6516d@DB4PR30MB030.064d.mgd.msft.net> Message-ID: It is still failing, but now on the parallel and stm libraries. Note that `validate --fast` skips those packages, but plain `./validate` doesn't, and Phabricator/Harbormaster runs plain `./validate`. parallel and stm are 'extra' packages, and the build system no longer builds those by default. To build them, set `BUILD_EXTRA_PKGS=YES` in mk/ build.mk. I'm sorry if this caused confusion. It's explained on the wiki now: https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Buildconfiguration https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Flags On Tue, Jul 28, 2015 at 6:47 PM, Simon Peyton Jones wrote: > Hopefully done now. Sorry about this -- really busy day > > S > > > > *From:* Simon Peyton Jones > *Sent:* 28 July 2015 11:01 > *To:* 'ghc-devs' > *Subject:* RE: warnings > > > > Validating now, but have to go to London for a few hrs. Meanwhile use > ?Wwarn! > > > > *From:* Simon Peyton Jones > *Sent:* 27 July 2015 17:08 > *To:* ghc-devs > *Subject:* warnings > > > > Yurgh. I committed a patch but my validate had ?Wwarn by mistake. So > there are warnings in base (and binary actually). I will sort them out > tomorrow. > > Could revert and re-apply but doesn?t seem worth it. > > > Sorry > > Simon > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jul 28 21:04:32 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 28 Jul 2015 21:04:32 +0000 Subject: warnings In-Reply-To: References: <560756a97e9447bfb19894a3afc6516d@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <33a649af25a44ff3beced37d434e807b@DB4PR30MB030.064d.mgd.msft.net> OK would someone like to add the same warning-suppression to ghc.mk as I did for bytestring? Simon From: Thomas Miedema [mailto:thomasmiedema at gmail.com] Sent: 28 July 2015 18:54 To: Simon Peyton Jones Cc: ghc-devs Subject: Re: warnings It is still failing, but now on the parallel and stm libraries. Note that `validate --fast` skips those packages, but plain `./validate` doesn't, and Phabricator/Harbormaster runs plain `./validate`. parallel and stm are 'extra' packages, and the build system no longer builds those by default. To build them, set `BUILD_EXTRA_PKGS=YES` in mk/build.mk. I'm sorry if this caused confusion. It's explained on the wiki now: https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Buildconfiguration https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Flags On Tue, Jul 28, 2015 at 6:47 PM, Simon Peyton Jones > wrote: Hopefully done now. Sorry about this -- really busy day S From: Simon Peyton Jones Sent: 28 July 2015 11:01 To: 'ghc-devs' Subject: RE: warnings Validating now, but have to go to London for a few hrs. Meanwhile use ?Wwarn! From: Simon Peyton Jones Sent: 27 July 2015 17:08 To: ghc-devs Subject: warnings Yurgh. I committed a patch but my validate had ?Wwarn by mistake. So there are warnings in base (and binary actually). I will sort them out tomorrow. Could revert and re-apply but doesn?t seem worth it. Sorry Simon _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jul 28 21:23:03 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 28 Jul 2015 21:23:03 +0000 Subject: A GHC Library In-Reply-To: <0A0C5419-2D74-446F-BF6F-7866B1BFE52C@cis.upenn.edu> References: <0A0C5419-2D74-446F-BF6F-7866B1BFE52C@cis.upenn.edu> Message-ID: Good plan; maybe you can merge your list into the existing Reading List that Jan pointed you to? I think there would be merit in actually snapshotting the bits into one safe place. Links go dead etc, and having a single archive location might be a very good thing. If anyone feels like doing that. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard | Eisenberg | Sent: 28 July 2015 16:15 | To: ghc-devs Devs | Subject: A GHC Library | | Hi devs, | | It has struck me that we have a vast trove of documentation about GHC in | the form of academic papers, but little organization to this trove. The | papers are scattered across authors' websites, and sometimes it is hard | to remember what a paper is titled when searching for it. | | I have thus started a wiki page here: | https://ghc.haskell.org/trac/ghc/wiki/Library | | I would love for this page to be the Definitive List of GHC-related | papers. The list I've included is, of course, woefully short, but it is a | starting point. Please add to it! | | Have you written a GHC paper? If so, make sure it's included. | | Thanks, | Richard | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From eir at cis.upenn.edu Wed Jul 29 01:39:34 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 28 Jul 2015 21:39:34 -0400 Subject: A GHC Library In-Reply-To: References: <0A0C5419-2D74-446F-BF6F-7866B1BFE52C@cis.upenn.edu> Message-ID: On Jul 28, 2015, at 5:23 PM, Simon Peyton Jones wrote: > Good plan; maybe you can merge your list into the existing Reading List that Jan pointed you to? > > I think there would be merit in actually snapshotting the bits into one safe place. Links go dead etc, and having a single archive location might be a very good thing. If anyone feels like doing that. That was actually my original intent. But then I worried about copyright issues. So instead I just pointed to doi.org links, which should at least give our future selves a fighting shot at getting the original resource. Will merge with the other page (which I was clearly unaware of) tomorrow. I actually think most of my entries are distinct from those on the other page, so my work wasn't wasted. Richard > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard > | Eisenberg > | Sent: 28 July 2015 16:15 > | To: ghc-devs Devs > | Subject: A GHC Library > | > | Hi devs, > | > | It has struck me that we have a vast trove of documentation about GHC in > | the form of academic papers, but little organization to this trove. The > | papers are scattered across authors' websites, and sometimes it is hard > | to remember what a paper is titled when searching for it. > | > | I have thus started a wiki page here: > | https://ghc.haskell.org/trac/ghc/wiki/Library > | > | I would love for this page to be the Definitive List of GHC-related > | papers. The list I've included is, of course, woefully short, but it is a > | starting point. Please add to it! > | > | Have you written a GHC paper? If so, make sure it's included. > | > | Thanks, > | Richard > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Wed Jul 29 14:51:12 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 29 Jul 2015 14:51:12 +0000 Subject: Question about inliner behaviour with a small function In-Reply-To: <20150722134614.GB10473@arkham.barrucadu.barrucadu.uk0.bigv.io> References: <20150722134614.GB10473@arkham.barrucadu.barrucadu.uk0.bigv.io> Message-ID: <22003c60a19549d6b7b88bd5a7093361@DB4PR30MB030.064d.mgd.msft.net> Hmm. With HEAD, and without profiling, the program allocates the same 104M, both with and without the INLINE. The same deforestation happens in both cases. It's quite possible that profiling interferes with deforestation. Simon c:/code/HEAD/inplace/bin/ghc-stage1 Michael.hs -O -o Michael-no-inline ./Michael-no-inline.exe +RTS -s 999999 104,045,052 bytes allocated in the heap 171,752 bytes copied during GC 41,756 bytes maximum residency (2 sample(s)) 36,800 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Michael | Walker | Sent: 22 July 2015 14:46 | To: ghc-devs at haskell.org | Subject: Question about inliner behaviour with a small function | | Hello, | | I managed to shrink a bizarre memory issue down to this (probably | minimal) | example: | | module Main where | | f :: [Int] -> Int | f xs = length is where | is = [ i | (_, i) <- pairs ys ] :: [(Int,Int)] | | ys = zip [0..] xs :: [(Int, Int)] | | {-# INLINE pairs #-} | pairs xs = zip xs $ tail xs | | main :: IO () | main = print $ f xs where | xs = replicate 1000000 0 | | With the INLINE pragma, this allocates 264,049,584 bytes (compiled with | `ghc -O2 | -prof -fprof-auto inline.hs), without the pragma it allocates 336,049,512 | bytes. | | Dropping the `main` definition (and renaming the module to "Foo") and | examining | the core, the key difference seems to be in how the list comprehension is | compiled. | | With the INLINE pragma: | | Rec { | Foo.f_go [Occ=LoopBreaker] | :: [(Int, Int)] -> [(Int, Int)] -> [(Int, Int)] | [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType ] | Foo.f_go = | \ (ds_a14a :: [(Int, Int)]) (_ys_a14b :: [(Int, Int)]) -> | case ds_a14a of _ [Occ=Dead] { | [] -> GHC.Types.[] @ (Int, Int); | : ipv_a14g ipv1_a14h -> | case _ys_a14b of _ [Occ=Dead] { | [] -> GHC.Types.[] @ (Int, Int); | : ipv2_a14n ipv3_a14o -> | GHC.Types.: @ (Int, Int) ipv2_a14n (Foo.f_go ipv1_a14h | ipv3_a14o) | } | } | end Rec } | | And without: | | Rec { | Foo.f_go [Occ=LoopBreaker] | :: [((Int, Int), (Int, Int))] -> [(Int, Int)] | [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType ] | Foo.f_go = | \ (ds_a13o :: [((Int, Int), (Int, Int))]) -> | case ds_a13o of _ [Occ=Dead] { | [] -> GHC.Types.[] @ (Int, Int); | : y_a13t ys_a13u -> | case y_a13t of _ [Occ=Dead] { (ds1_d12V, i_an2) -> | GHC.Types.: @ (Int, Int) i_an2 (Foo.f_go ys_a13u) | } | } | end Rec } | | Full core is available at | https://gist.github.com/barrucadu/a59df62cd16074559e35 | | In the no-INLINE case, the list comprehension is compiled much like I | would | expect, it's walking down a zipped list of pairs and producing the | result. The | INLINE case is rather different, it looks like the `zip` has been inlined | and | deforestation has happened. | | This explains the difference in memory usage, a whole intermediary list | has been | skipped! | | I assume that GHC's analysis is determining `pairs` is too expensive to | inline | early enough to allow the further optimisation without the pragma, but | the | pragma forces it to happen earlier by marking it as really cheap. But | `pairs` is | a really small definition, syntactically. Why does the analysis consider | it | expensive? It is simply because it uses its argument multiple times in | its body? | | And if it's not some sort of cost analysis, what's really going on? | | Thank for your time. | | -- | Michael Walker (http://www.barrucadu.co.uk) | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at well-typed.com Wed Jul 29 15:26:58 2015 From: ben at well-typed.com (Ben Gamari) Date: Wed, 29 Jul 2015 17:26:58 +0200 Subject: ANNOUNCE: GHC version 7.10.2 Message-ID: <8761533ry5.fsf@smart-cactus.org> ===================================================================== The (Interactive) Glasgow Haskell Compiler -- version 7.10.2 ===================================================================== The GHC Team is pleased to announce a new bug-fix release of GHC, 7.10.2. There have been a number of significant bug fixes since the 7.10.1 (with over 70 defects fixed). These include fixes affecting type-checker correctness, runtime stability, and compiler performance. For this reason we highly recommend that users of 7.10.1 upgrade quickly. Note that due to changes made in this release to GHC's optimizer, previously fragile-but-working rewrite rules may fail to fire. One example of this was found in the widely-used `text` package late in the release cycle, which manifested in long compilation times and poor code generation for `Text` literals (see [Trac #10528]). Users are advised to use text >=1.2.1.2 which includes more robust rewrite rules. The full release notes including a complete listing of the changes in this release can be found here, https://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/release-7-10-2.html [Trac #10528]: https://ghc.haskell.org/trac/ghc/ticket/10528 How to get it ~~~~~~~~~~~~~ Both binary and source tarballs of GHC itself are available on the release download page, https://www.haskell.org/ghc/download_ghc_7_10_2 For a more smoother, better integrated experience users are encouraged to find a Haskell distribution. While these alternatives may not yet include 7.10.2, they offer tools and libraries to quickly get users up and running, as well as potentially better integration with the host operating system and package manager. See, https://www.haskell.org/downloads for more details. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below), https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms supported by GHC and the people responsible for them can be found here, https://ghc.haskell.org/trac/ghc/wiki/Platforms https://ghc.haskell.org/trac/ghc/wiki/CodeOwners Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ If you enjoy using GHC, you will likely also enjoy contributing to it! We are always looking for new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC developer site, https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://www.haskell.org/mailman/listinfo/glasgow-haskell-users https://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug Hashes & Signatures ~~~~~~~~~~~~~~~~~ In https://downloads.haskell.org/~ghc/7.10.2/ you will find a signed copy of the SHA256 hashes for the tarballs, using my GPG key, Benjamin Gamari Fingerprint: FFEB 7CE8 1E16 A36B 3E2D ED6F 2DE0 4D4E 97DB 64AD -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From eir at cis.upenn.edu Wed Jul 29 15:47:35 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 29 Jul 2015 11:47:35 -0400 Subject: A GHC Library In-Reply-To: References: <0A0C5419-2D74-446F-BF6F-7866B1BFE52C@cis.upenn.edu> Message-ID: <1DB21525-8AE6-40F8-A20D-03A7DC0F3451@cis.upenn.edu> Done -- merged into ReadingList. On Jul 28, 2015, at 9:39 PM, Richard Eisenberg wrote: > > On Jul 28, 2015, at 5:23 PM, Simon Peyton Jones wrote: > >> Good plan; maybe you can merge your list into the existing Reading List that Jan pointed you to? >> >> I think there would be merit in actually snapshotting the bits into one safe place. Links go dead etc, and having a single archive location might be a very good thing. If anyone feels like doing that. > > That was actually my original intent. But then I worried about copyright issues. So instead I just pointed to doi.org links, which should at least give our future selves a fighting shot at getting the original resource. > > Will merge with the other page (which I was clearly unaware of) tomorrow. I actually think most of my entries are distinct from those on the other page, so my work wasn't wasted. > > Richard > >> >> Simon >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard >> | Eisenberg >> | Sent: 28 July 2015 16:15 >> | To: ghc-devs Devs >> | Subject: A GHC Library >> | >> | Hi devs, >> | >> | It has struck me that we have a vast trove of documentation about GHC in >> | the form of academic papers, but little organization to this trove. The >> | papers are scattered across authors' websites, and sometimes it is hard >> | to remember what a paper is titled when searching for it. >> | >> | I have thus started a wiki page here: >> | https://ghc.haskell.org/trac/ghc/wiki/Library >> | >> | I would love for this page to be the Definitive List of GHC-related >> | papers. The list I've included is, of course, woefully short, but it is a >> | starting point. Please add to it! >> | >> | Have you written a GHC paper? If so, make sure it's included. >> | >> | Thanks, >> | Richard >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs at haskell.org >> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From asr at eafit.edu.co Wed Jul 29 15:53:29 2015 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Wed, 29 Jul 2015 10:53:29 -0500 Subject: [Haskell] ANNOUNCE: GHC version 7.10.2 In-Reply-To: <8761533ry5.fsf@smart-cactus.org> References: <8761533ry5.fsf@smart-cactus.org> Message-ID: Hi, On 29 July 2015 at 10:26, Ben Gamari wrote: > The GHC Team is pleased to announce a new bug-fix release of GHC, > 7.10.2. Thanks for the release! FYI, there are various missing *.tar.xz files in the SHA256SUMS file in http://downloads.haskell.org/~ghc/7.10.2/ Best regards, -- Andr?s From ben at well-typed.com Wed Jul 29 16:28:52 2015 From: ben at well-typed.com (Ben Gamari) Date: Wed, 29 Jul 2015 18:28:52 +0200 Subject: [Haskell] ANNOUNCE: GHC version 7.10.2 In-Reply-To: References: <8761533ry5.fsf@smart-cactus.org> Message-ID: <87vbd32aij.fsf@smart-cactus.org> Andr?s Sicard-Ram?rez writes: > Hi, > > On 29 July 2015 at 10:26, Ben Gamari wrote: >> The GHC Team is pleased to announce a new bug-fix release of GHC, >> 7.10.2. > > Thanks for the release! > > FYI, there are various missing *.tar.xz files in the SHA256SUMS file in > > http://downloads.haskell.org/~ghc/7.10.2/ > I suspect this may be due to the (Content Delivery Network (CDN) caches being stale. Unfortunately this seems to be a persistent issue. You can likely fool the CDN by inserting superfluous / characters in the URL (thanks to Herbert for the tip). For instance, http://downloads.haskell.org/~ghc/7.10.2///SHA256SUMS Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From asr at eafit.edu.co Wed Jul 29 18:15:56 2015 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Wed, 29 Jul 2015 13:15:56 -0500 Subject: [Haskell] ANNOUNCE: GHC version 7.10.2 In-Reply-To: <87vbd32aij.fsf@smart-cactus.org> References: <8761533ry5.fsf@smart-cactus.org> <87vbd32aij.fsf@smart-cactus.org> Message-ID: On 29 July 2015 at 11:28, Ben Gamari wrote: >> FYI, there are various missing *.tar.xz files in the SHA256SUMS file in >> >> http://downloads.haskell.org/~ghc/7.10.2/ >> > I suspect this may be due to the (Content Delivery Network (CDN) caches > being stale. Unfortunately this seems to be a persistent issue. You can > likely fool the CDN by inserting superfluous / characters in the URL > (thanks to Herbert for the tip). For instance, > > http://downloads.haskell.org/~ghc/7.10.2///SHA256SUMS This fixed the issue. Thanks! -- Andr?s From the.dead.shall.rise at gmail.com Thu Jul 30 07:11:07 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Thu, 30 Jul 2015 09:11:07 +0200 Subject: ANNOUNCE: GHC version 7.10.2 In-Reply-To: <8761533ry5.fsf@smart-cactus.org> References: <8761533ry5.fsf@smart-cactus.org> Message-ID: Hi, On 29 July 2015 at 17:26, Ben Gamari wrote: > [...] > The full release notes including a complete listing of the changes in > this release can be found here, > > https://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/release-7-10-2.html This gives me error 404. From simonpj at microsoft.com Thu Jul 30 07:39:37 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 30 Jul 2015 07:39:37 +0000 Subject: Parallel library Message-ID: Simon Are you the maintainer of the 'parallel' library? The core libraries wiki page says yes: https://wiki.haskell.org/Library_submissions#The_Core_Libraries But parallel.cabal says "Maintainer: libraries at haskell.org", which I thought we'd gotten rid of entirely. I ask because some should fix this: libraries/parallel/Control/Parallel/Strategies.hs:513:2: warning: Rule "parList/rseq" may never fire because 'rseq' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for 'rseq' We need a pragma on 'rseq'. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu Jul 30 08:18:29 2015 From: ben at well-typed.com (Ben Gamari) Date: Thu, 30 Jul 2015 10:18:29 +0200 Subject: [Haskell-cafe] ANNOUNCE: GHC version 7.10.2 In-Reply-To: References: <8761533ry5.fsf@smart-cactus.org> Message-ID: <87lhdy2h4a.fsf@smart-cactus.org> Mikhail Glushenkov writes: > Hi, > > On 29 July 2015 at 17:26, Ben Gamari wrote: >> [...] >> The full release notes including a complete listing of the changes in >> this release can be found here, >> >> https://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/release-7-10-2.html > > This gives me error 404. > I'm not sure what else to say other than to suggest adding superfluous `/` characters to the URL as mentioned previously. The document is there, the CDN just still hasn't realized it. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From marlowsd at gmail.com Thu Jul 30 08:36:33 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 30 Jul 2015 09:36:33 +0100 Subject: Parallel library In-Reply-To: References: Message-ID: <55B9E211.5090801@gmail.com> On 30/07/2015 08:39, Simon Peyton Jones wrote: > Are you the maintainer of the ?parallel? library? > > The core libraries wiki page says yes: > https://wiki.haskell.org/Library_submissions#The_Core_Libraries > > But parallel.cabal says ?Maintainer: libraries at haskell.org > ?, which I thought we?d gotten rid of > entirely. > > I ask because some should fix this: > > libraries/parallel/Control/Parallel/Strategies.hs:513:2: warning: > > Rule "parList/rseq" may never fire > > because ?rseq? might inline first > > Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?rseq? > > We need a pragma on ?rseq?. Ok, should it be INLINE[n] or NOINLINE[n], and what is the right value of n? (I always have to look up the documentation for these, just a suggestion but maybe it would be better to call them INLINEAFTER[n] and INLINEBEFORE[n], or something?) Cheers Simon From simonpj at microsoft.com Thu Jul 30 10:14:00 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 30 Jul 2015 10:14:00 +0000 Subject: Parallel library In-Reply-To: <55B9E211.5090801@gmail.com> References: <55B9E211.5090801@gmail.com> Message-ID: | Ok, should it be INLINE[n] or NOINLINE[n], and what is the right value | of n? Well it depends on the rules. The offending ones are below libraries/parallel/Control/Parallel/Strategies.hs:513:2: warning: Rule "parList/rseq" may never fire because 'rseq' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for 'rseq' libraries/parallel/Control/Parallel/Strategies.hs:582:1: warning: Rule "evalBuffer/rseq" may never fire because 'rseq' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for 'rseq' libraries/parallel/Control/Parallel/Strategies.hs:583:1: warning: Rule "parBuffer/rseq" may never fire because 'rseq' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for 'rseq' All three appear to be always-active, and hence will run in the first phase (2). So delaying inlining rseq to phase 1 (phases count downwards) would do. So INLINE[1] or NOINLINE[1] | (I always have to look up the documentation for these, just a | suggestion but maybe it would be better to call them INLINEAFTER[n] | and INLINEBEFORE[n], or something?) Maybe. But NOINLINE[n] means "do not inline until phase n; and you are free to do what you like thereafter" So it would have to be NOINLINEUNTIL[n]. But yes, that'd be quite do-able. Simon | | Cheers | Simon From mail at joachim-breitner.de Thu Jul 30 10:24:09 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 30 Jul 2015 12:24:09 +0200 Subject: INLINE pragmas In-Reply-To: References: <55B9E211.5090801@gmail.com> Message-ID: <1438251849.1335.16.camel@joachim-breitner.de> Hi, Am Donnerstag, den 30.07.2015, 10:14 +0000 schrieb Simon Peyton Jones: > | (I always have to look up the documentation for these, just a > | suggestion but maybe it would be better to call them INLINEAFTER[n] > | and INLINEBEFORE[n], or something?) > > Maybe. But NOINLINE[n] means "do not inline until phase n; and you > are free to do what you like thereafter" So it would have to be > NOINLINEUNTIL[n]. But yes, that'd be quite do-able. I support that suggestion, as I also always have to look it up as well, and things like NONLINE[~n] are really non-self-explanatory. Although "NOINLINEUNTIL[n]" is (to me, non-native-speaker) not as clear as it could be about what happens in phase n; the same with INLINEAFTER. How about this, using ?from? and ?before?, which (to me) make it clearer what happens at n: INLINE[n] becomes INLINEFROM[n] NOINLINE[n] becomes NOINLINEBEFORE[n] INLINE[~n] becomes INLINEBEFORE[n] NOINLINE[~n] becomes NOINLINEFROM[n] BTW, the docs say about NOINLINE ?You shouldn't ever need to do this, unless you're very cautious about code size.? ? should this also mention that NOINLINE are often necessary with RULES? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Thu Jul 30 10:28:47 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 30 Jul 2015 10:28:47 +0000 Subject: INLINE pragmas In-Reply-To: <1438251849.1335.16.camel@joachim-breitner.de> References: <55B9E211.5090801@gmail.com> <1438251849.1335.16.camel@joachim-breitner.de> Message-ID: <5964d5e89e4b4edb8a196c76c673c68d@DB4PR30MB030.064d.mgd.msft.net> | INLINE[n] becomes INLINEFROM[n] | NOINLINE[n] becomes NOINLINEBEFORE[n] | INLINE[~n] becomes INLINEBEFORE[n] | NOINLINE[~n] becomes NOINLINEFROM[n] I'd be fine with these. Maybe INLINE_FROM etc to split the words. If someone wants to - make a ticket - make a proposal and get feedback - implement, as synonyms for the existing things that'd be great. | BTW, the docs say about NOINLINE ?You shouldn't ever need to do this, | unless you're very cautious about code size.? ? should this also | mention that NOINLINE are often necessary with RULES? Good idea Simon From roma at ro-che.info Thu Jul 30 10:30:52 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 30 Jul 2015 13:30:52 +0300 Subject: INLINE pragmas In-Reply-To: <1438251849.1335.16.camel@joachim-breitner.de> References: <55B9E211.5090801@gmail.com> <1438251849.1335.16.camel@joachim-breitner.de> Message-ID: <55B9FCDC.50700@ro-che.info> On 30/07/15 13:24, Joachim Breitner wrote: > BTW, the docs say about NOINLINE ?You shouldn't ever need to do this, > unless you're very cautious about code size.? ? should this also > mention that NOINLINE are often necessary with RULES? unsafePerformIO is another popular and valid usecase for NOINLINE. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mail at joachim-breitner.de Thu Jul 30 11:06:43 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 30 Jul 2015 13:06:43 +0200 Subject: INLINE pragmas In-Reply-To: <5964d5e89e4b4edb8a196c76c673c68d@DB4PR30MB030.064d.mgd.msft.net> References: <55B9E211.5090801@gmail.com> <1438251849.1335.16.camel@joachim-breitner.de> <5964d5e89e4b4edb8a196c76c673c68d@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <1438254403.1335.17.camel@joachim-breitner.de> Hi, Am Donnerstag, den 30.07.2015, 10:28 +0000 schrieb Simon Peyton Jones: > If someone wants to > - make a ticket > - make a proposal and get feedback > - implement, as synonyms for the existing things > that'd be great. https://ghc.haskell.org/trac/ghc/wiki/Proposal/SelfExplinatoryInlinePra gmas https://ghc.haskell.org/trac/ghc/ticket/10710 Feedback welcome! Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From thomasmiedema at gmail.com Thu Jul 30 11:10:16 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Thu, 30 Jul 2015 13:10:16 +0200 Subject: INLINE pragmas In-Reply-To: <1438251849.1335.16.camel@joachim-breitner.de> References: <55B9E211.5090801@gmail.com> <1438251849.1335.16.camel@joachim-breitner.de> Message-ID: > > INLINE[n] becomes INLINEFROM[n] > NOINLINE[n] becomes NOINLINEBEFORE[n] INLINE[~n] becomes INLINEBEFORE[n] > NOINLINE[~n] becomes NOINLINEFROM[n] Still not great, because INLINE[n] doesn't inline before phase n either. Maybe we should make that explicit, and use 2 separate pragmas: INLINE[n] becomes NO_INLINE_BEFORE[n], INLINE_FROM[n] NOINLINE[n] becomes NO_INLINE_BEFORE[n] INLINE[~n] becomes NO_INLINE_FROM[n], INLINE_BEFORE[n] NOINLINE[~n] becomes NO_INLINE_FROM[n] (a combination of NO_INLINE_BEFORE[n] and INLINE_BEFORE[n], or NO_INLINE_FROM[n] and INLINE_FROM[n], would be an error) If that is too verbose, we could make the 'no inline' part implicit: INLINE[n] becomes INLINE_FROM[n] NOINLINE[n] becomes INLINEABLE_FROM[n] INLINE[~n] becomes INLINE_BEFORE[n] NOINLINE[~n] becomes INLINEABLE_BEFORE[n] -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Jul 30 11:22:51 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 30 Jul 2015 13:22:51 +0200 Subject: INLINE pragmas In-Reply-To: References: <55B9E211.5090801@gmail.com> <1438251849.1335.16.camel@joachim-breitner.de> Message-ID: <1438255371.1335.23.camel@joachim-breitner.de> Hi, Am Donnerstag, den 30.07.2015, 13:10 +0200 schrieb Thomas Miedema: > > INLINE[n] becomes INLINEFROM[n] > > NOINLINE[n] becomes NOINLINEBEFORE[n] > > INLINE[~n] becomes INLINEBEFORE[n] > > NOINLINE[~n] becomes NOINLINEFROM[n] > > Still not great, because INLINE[n] doesn't inline before phase n > either. Maybe we should make that explicit, and use 2 separate > pragmas: > > INLINE[n] becomes NO_INLINE_BEFORE[n], INLINE_FROM[n] > NOINLINE[n] becomes NO_INLINE_BEFORE[n] > INLINE[~n] becomes NO_INLINE_FROM[n], INLINE_BEFORE[n] > NOINLINE[~n] becomes NO_INLINE_FROM[n] > > (a combination of NO_INLINE_BEFORE[n] and INLINE_BEFORE[n], or > NO_INLINE_FROM[n] and INLINE_FROM[n], would be an error) I thought about that as well, but I can only fight it with more verbosity: INLINE[n] becomes ONLY_INLINE_FROM[n] NOINLINE[n] becomes ONLY_NOINLINE_BEFORE[n] INLINE[~n] becomes INLINE_BEFORE[n] NOINLINE[~n] becomes NOINLINE_FROM[n] And I am not even sure if ONLY_INLINE_FROM has the connotation of definite inlining to every reader... > If that is too verbose, we could make the 'no inline' part implicit: > > INLINE[n] becomes INLINE_FROM[n] > NOINLINE[n] becomes INLINEABLE_FROM[n] > INLINE[~n] becomes INLINE_BEFORE[n] > NOINLINE[~n] becomes INLINEABLE_BEFORE[n] But INLINABLE has its own semantics (i.e. ?do retain a copy of the RHS?), and NOINLNE does, as far as I know, not imply this. But maybe your idea works with NOINLINE[n] becomes MAY_INLINE_FROM[n] NOINLINE[~n] becomes MAY_INLINE_BEFORE[n] and if we have that, how about INLINE[n] becomes MUST_INLINE_FROM[n] INLINE[~n] becomes MUST_INLINE_BEFORE[n] for symmetry as well? We?ll get a nice bikeshed out of this! Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ben at well-typed.com Thu Jul 30 12:07:07 2015 From: ben at well-typed.com (Ben Gamari) Date: Thu, 30 Jul 2015 14:07:07 +0200 Subject: ANNOUNCE: GHC version 7.10.2 In-Reply-To: <8761533ry5.fsf@smart-cactus.org> References: <8761533ry5.fsf@smart-cactus.org> Message-ID: <877fph3l3o.fsf@smart-cactus.org> Hello again! See below for an important announcement regarding the `text` issue described earlier. Ben Gamari writes: > ===================================================================== > The (Interactive) Glasgow Haskell Compiler -- version 7.10.2 > ===================================================================== > > The GHC Team is pleased to announce a new bug-fix release of GHC, > 7.10.2. > > There have been a number of significant bug fixes since the 7.10.1 (with > over 70 defects fixed). These include fixes affecting type-checker > correctness, runtime stability, and compiler performance. For this > reason we highly recommend that users of 7.10.1 upgrade quickly. > > Note that due to changes made in this release to GHC's optimizer, > previously fragile-but-working rewrite rules may fail to fire. One > example of this was found in the widely-used `text` package late in the > release cycle, which manifested in long compilation times and poor code > generation for `Text` literals (see [Trac #10528]). Users are advised to > use text >=1.2.1.2 which includes more robust rewrite rules. > It has been brought to my attention that the fix included in text-1.2.1.2 does not in fact fix the rule issues triggered by GHC 7.10.2 (see the later comments on #10528 for details). I have pushed text-1.2.1.3 to Hackage which finally resolves this issue. Users of GHC 7.10.2 should upgrade to text >=1.2.1.3 at their earliest convenience. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From thomasmiedema at gmail.com Thu Jul 30 12:25:19 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Thu, 30 Jul 2015 14:25:19 +0200 Subject: INLINE pragmas In-Reply-To: <1438255371.1335.23.camel@joachim-breitner.de> References: <55B9E211.5090801@gmail.com> <1438251849.1335.16.camel@joachim-breitner.de> <1438255371.1335.23.camel@joachim-breitner.de> Message-ID: > INLINE[n] becomes ONLY_INLINE_FROM[n] > NOINLINE[n] becomes ONLY_NOINLINE_BEFORE[n] > ... > And I am not even sure if ONLY_INLINE_FROM has the connotation of > definite inlining to every reader... > ONLY_INLINE_FROM is problematic indeed, because it could just as well mean the same as MAY_INLINE_FROM. I still think we should consider splitting up the original INLINE[n] pragma into two simpler pragmas (it currently does two things, whereas NOINLINE[n] does only one thing). Here' another suggestion (note that phases count down): INLINE[2] becomes NO_INLINE > 2, INLINE <= 2 NOINLINE[2] becomes NO_INLINE > 2 Or, if we don't want two separate pragmas: INLINE[2] becomes INLINE_IFF <= 2 NOINLINE[2] becomes NOINLINE > 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Jul 30 14:58:21 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 30 Jul 2015 14:58:21 +0000 Subject: [Diffusion] [Committed] rGHC24afe6d3aae1: Fix missing files In-Reply-To: <20150730145250.17719.76804@phabricator.haskell.org> References: <20150730145250.17719.76804@phabricator.haskell.org> Message-ID: <805ce76abd4042a085e85f8a75b11ec5@DB4PR30MB030.064d.mgd.msft.net> Sorry for all the noise recently from me. I _think_ we should be back to clean validation now Simon | -----Original Message----- | From: noreply at phabricator.haskell.org | [mailto:noreply at phabricator.haskell.org] | Sent: 30 July 2015 15:53 | To: Simon Peyton Jones | Subject: [Diffusion] [Committed] rGHC24afe6d3aae1: Fix missing files | | simonpj committed rGHC24afe6d3aae1: Fix missing files (authored by | simonpj). | | Fix missing files | | These two testsuite files were correct in my build tree but not in my | source tree; apologies. | | | BRANCHES | master | | AFFECTED FILES | /testsuite/tests/simplCore/should_compile/T7287.stderr | /testsuite/tests/stranal/should_compile/T10694.stdout | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC24afe6d3aae1 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite | Cc: thomie From thomasmiedema at gmail.com Thu Jul 30 15:47:55 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Thu, 30 Jul 2015 17:47:55 +0200 Subject: INLINE pragmas In-Reply-To: <1438255371.1335.23.camel@joachim-breitner.de> References: <55B9E211.5090801@gmail.com> <1438251849.1335.16.camel@joachim-breitner.de> <1438255371.1335.23.camel@joachim-breitner.de> Message-ID: Hi, On Thu, Jul 30, 2015 at 1:22 PM, Joachim Breitner wrote: > > But INLINABLE has its own semantics (i.e. ?do retain a copy of the > RHS?), and NOINLNE does, as far as I know, not imply this. Ok. > But maybe your idea works with > > NOINLINE[n] becomes MAY_INLINE_FROM[n] > NOINLINE[~n] becomes MAY_INLINE_BEFORE[n] Even better. INLINE[n] becomes MUST_INLINE_FROM[n] > INLINE[~n] becomes MUST_INLINE_BEFORE[n] > I added this option, without the `MUST_` (it doesn't add much in my opinion), as proposal 3 to https://ghc.haskell.org/trac/ghc/wiki/Proposal/SelfExplinatoryInlinePragmas .. Anyone have other suggestions? Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Jul 30 16:55:35 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 30 Jul 2015 12:55:35 -0400 Subject: [Haskell-cafe] ANNOUNCE: GHC version 7.10.2 In-Reply-To: References: <8761533ry5.fsf@smart-cactus.org> <877fph3l3o.fsf@smart-cactus.org> Message-ID: On Thu, Jul 30, 2015 at 12:52 PM, James M wrote: > There was talk from an earlier email thread of releasing the Haskell > Platform at the same time as 7.10.2. I think the right place to ask this is libraries at haskell.org. I would imagine they're in final testing and/or getting release packages in place. (Note as previously mentioned that "text" was just updated, and the Platform needs that; this presumably means they had to start over making release packages.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu Jul 30 17:04:33 2015 From: ben at well-typed.com (Ben Gamari) Date: Thu, 30 Jul 2015 19:04:33 +0200 Subject: [Haskell-cafe] ANNOUNCE: GHC version 7.10.2 In-Reply-To: References: <8761533ry5.fsf@smart-cactus.org> <877fph3l3o.fsf@smart-cactus.org> Message-ID: <87mvyd1sri.fsf@smart-cactus.org> James M writes: > There was talk from an earlier email thread of releasing the Haskell > Platform at the same time as 7.10.2. > > I am referring to the weekly news of 2015/05/11: > https://ghc.haskell.org/trac/ghc/blog/weekly20150511 > > and this email thread: > https://mail.haskell.org/pipermail/ghc-devs/2015-May/008911.html > > > Was this plan abandoned? Or was there something unexpected that is delaying > it? > Not at all! There ended up being a bit of timing skew between the Platform and GHC releases but an approximately concurrent release is still the plan. The Platform folks are hard at work as we speak, in the final stages of pushing out their release. I expect it will be announced shortly. Unfortunately due to the late notice of the text issue, the initial release will ship with text-1.2.1.1, which is still affected by the rewrite issue. That being said, the impact of this issue is mostly on compile time, in most cases you shouldn't see much impact on runtime performance. Moreover, they will be working to push out another release with text-1.2.1.3 in the coming days. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mgoremeier at gmail.com Thu Jul 30 21:04:51 2015 From: mgoremeier at gmail.com (Michael Karg) Date: Thu, 30 Jul 2015 23:04:51 +0200 Subject: Typechecker / OverloadedStrings question 7.8 vs. 7.10 Message-ID: Hi devs, in the followin snippet: {-# LANGUAGE OverloadedStrings #-} import Data.Char (isAlphaNum) import Data.ByteString.Char8 as BS (all) main = print $ check str where check = BS.all (\x -> x `elem` valid || isAlphaNum x) -- Line 7 valid = "$_-" -- :: String -- Line 8 str = "foo_bar123" GHC 7.10 fails with the following errors (whereas 7.8 compiles without complaining): ghc --make "Testcase.hs" [1 of 1] Compiling Main ( Testcase.hs, Testcase.o ) Testcase.hs:7:31: No instance for (Foldable t0) arising from a use of ?elem? The type variable ?t0? is ambiguous (...) Testcase.hs:8:15: No instance for (Data.String.IsString (t0 Char)) arising from the literal ?"$_-"? The type variable ?t0? is ambiguous (...) Uncommenting the -- :: String type annotation (line 8) makes the snippet acceptable to the typechecker however. So Foldable [] and [Char] should be possible to infer, given the evidence of 'isAlphaNum x', as obviously happens with GHC 7.8. My question is, how or why does the 7.10 typechecker behave differently? Is this intentional, or does this qualify for a trac ticket? Thanks for looking into this, Michael PS: The ByteString part is just there since the snippet is taken out of one of my projects. The following (modified) code only typechecks on 7.10 with both type annotations uncommented: {-# LANGUAGE OverloadedStrings #-} import Data.Char (isAlphaNum) main = print $ check str where check = all (\x -> x `elem` valid || isAlphaNum x) valid = "$_-" -- :: String str = "foo_bar123" -- :: String The errors here are (1) no instances for Foldable and (2) no instances for IsString. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Jul 30 21:24:18 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 30 Jul 2015 21:24:18 +0000 Subject: Typechecker / OverloadedStrings question 7.8 vs. 7.10 In-Reply-To: References: Message-ID: <841f2790eb8b4bb99541e241c0009924@DB4PR30MB030.064d.mgd.msft.net> I think it?s because of the newly generalised Foldable stuff. In 7.10, after huge discussion (https://ghc.haskell.org/trac/ghc/wiki/Prelude710) we have elem :: (Eq a, Foldable t) => a -> t a -> Bool all :: Foldable t => (a -> Bool) -> t a -> Bool And there is no way to tell what ?t? you mean. Lists? Trees? Who knows! Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Michael Karg Sent: 30 July 2015 22:05 To: ghc-devs Subject: Typechecker / OverloadedStrings question 7.8 vs. 7.10 Hi devs, in the followin snippet: {-# LANGUAGE OverloadedStrings #-} import Data.Char (isAlphaNum) import Data.ByteString.Char8 as BS (all) main = print $ check str where check = BS.all (\x -> x `elem` valid || isAlphaNum x) -- Line 7 valid = "$_-" -- :: String -- Line 8 str = "foo_bar123" GHC 7.10 fails with the following errors (whereas 7.8 compiles without complaining): ghc --make "Testcase.hs" [1 of 1] Compiling Main ( Testcase.hs, Testcase.o ) Testcase.hs:7:31: No instance for (Foldable t0) arising from a use of ?elem? The type variable ?t0? is ambiguous (...) Testcase.hs:8:15: No instance for (Data.String.IsString (t0 Char)) arising from the literal ?"$_-"? The type variable ?t0? is ambiguous (...) Uncommenting the -- :: String type annotation (line 8) makes the snippet acceptable to the typechecker however. So Foldable [] and [Char] should be possible to infer, given the evidence of 'isAlphaNum x', as obviously happens with GHC 7.8. My question is, how or why does the 7.10 typechecker behave differently? Is this intentional, or does this qualify for a trac ticket? Thanks for looking into this, Michael PS: The ByteString part is just there since the snippet is taken out of one of my projects. The following (modified) code only typechecks on 7.10 with both type annotations uncommented: {-# LANGUAGE OverloadedStrings #-} import Data.Char (isAlphaNum) main = print $ check str where check = all (\x -> x `elem` valid || isAlphaNum x) valid = "$_-" -- :: String str = "foo_bar123" -- :: String The errors here are (1) no instances for Foldable and (2) no instances for IsString. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgoremeier at gmail.com Thu Jul 30 21:39:33 2015 From: mgoremeier at gmail.com (Michael Karg) Date: Thu, 30 Jul 2015 23:39:33 +0200 Subject: Typechecker / OverloadedStrings question 7.8 vs. 7.10 In-Reply-To: <841f2790eb8b4bb99541e241c0009924@DB4PR30MB030.064d.mgd.msft.net> References: <841f2790eb8b4bb99541e241c0009924@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Hi Simon and all, thanks for the quick response. I somehow suspected it was connected to that... The mildly surprising effect of adding/leaving out the OverloadedString pragma however made me scratch my head a little, since the following code (w/o pragma) does typecheck just fine (without annotating :: String): import Data.Char (isAlphaNum) main = print $ check str where check = all (\x -> x `elem` valid || isAlphaNum x) valid = "$_-" -- :: String str = "foo_bar123" -- :: String I guess without that pragma, the string literals already imply t ~ [] for Foldable t. Thanks again for the answer, the behaviour I described is to be expected then. Michael 2015-07-30 23:24 GMT+02:00 Simon Peyton Jones : > I think it?s because of the newly generalised Foldable stuff. In 7.10, > after huge discussion (https://ghc.haskell.org/trac/ghc/wiki/Prelude710) > we have > > elem :: (Eq a, Foldable t) => a -> t a -> Bool > > all :: Foldable t => (a -> Bool) -> t a -> Bool > > > > And there is no way to tell what ?t? you mean. Lists? Trees? Who knows! > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Michael > Karg > *Sent:* 30 July 2015 22:05 > *To:* ghc-devs > *Subject:* Typechecker / OverloadedStrings question 7.8 vs. 7.10 > > > > Hi devs, > > in the followin snippet: > > {-# LANGUAGE OverloadedStrings #-} > import Data.Char (isAlphaNum) > import Data.ByteString.Char8 as BS (all) > main = > print $ check str > where > check = BS.all (\x -> x `elem` valid || isAlphaNum x) -- Line 7 > valid = "$_-" -- :: String > -- Line 8 > str = "foo_bar123" > > GHC 7.10 fails with the following errors (whereas 7.8 compiles without > complaining): > > > ghc --make "Testcase.hs" > [1 of 1] Compiling Main ( Testcase.hs, Testcase.o ) > Testcase.hs:7:31: > No instance for (Foldable t0) arising from a use of ?elem? > The type variable ?t0? is ambiguous > (...) > > Testcase.hs:8:15: > No instance for (Data.String.IsString (t0 Char)) > arising from the literal ?"$_-"? > The type variable ?t0? is ambiguous > (...) > > Uncommenting the -- :: String type annotation (line 8) makes the snippet > acceptable to the typechecker however. > > > > So Foldable [] and [Char] should be possible to infer, given the evidence > of 'isAlphaNum x', as obviously happens with GHC 7.8. My question is, how > or why does the 7.10 typechecker behave differently? Is this intentional, > or does this qualify for a trac ticket? > > Thanks for looking into this, > > Michael > > > > PS: The ByteString part is just there since the snippet is taken out of > one of my projects. The following (modified) code only typechecks on 7.10 > with both type annotations uncommented: > > {-# LANGUAGE OverloadedStrings #-} > import Data.Char (isAlphaNum) > main = > print $ check str > where > check = all (\x -> x `elem` valid || isAlphaNum x) > valid = "$_-" -- :: String > str = "foo_bar123" -- :: String > > > > The errors here are (1) no instances for Foldable and (2) no instances for > IsString. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Jul 30 21:40:57 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 30 Jul 2015 21:40:57 +0000 Subject: [Diffusion] [Build Failed] rGHC24afe6d3aae1: Fix missing files In-Reply-To: <20150730161354.29414.53729@phabricator.haskell.org> References: <20150730161354.29414.53729@phabricator.haskell.org> Message-ID: <577db4e7fc714fc5b16127060b7f45c0@DB4PR30MB030.064d.mgd.msft.net> Apparently it still doesn't validate, but I don't understand Harbourmaster's failure report. Seems to be something to do with Haddock though. Anyone able to help? Simon | -----Original Message----- | From: noreply at phabricator.haskell.org | [mailto:noreply at phabricator.haskell.org] | Sent: 30 July 2015 17:14 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC24afe6d3aae1: Fix missing files | | Harbormaster failed to build B5072: rGHC24afe6d3aae1: Fix missing files! | | BRANCHES | master | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC24afe6d3aae1 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite From thomasmiedema at gmail.com Thu Jul 30 21:46:18 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Thu, 30 Jul 2015 23:46:18 +0200 Subject: [Diffusion] [Build Failed] rGHC24afe6d3aae1: Fix missing files In-Reply-To: <577db4e7fc714fc5b16127060b7f45c0@DB4PR30MB030.064d.mgd.msft.net> References: <20150730161354.29414.53729@phabricator.haskell.org> <577db4e7fc714fc5b16127060b7f45c0@DB4PR30MB030.064d.mgd.msft.net> Message-ID: We should be good now, the build is green: https://phabricator.haskell.org/diffusion/GHC/history/ On Thu, Jul 30, 2015 at 11:40 PM, Simon Peyton Jones wrote: > Apparently it still doesn't validate, but I don't understand > Harbourmaster's failure report. Seems to be something to do with Haddock > though. Anyone able to help? > > Simon > > | -----Original Message----- > | From: noreply at phabricator.haskell.org > | [mailto:noreply at phabricator.haskell.org] > | Sent: 30 July 2015 17:14 > | To: Simon Peyton Jones > | Subject: [Diffusion] [Build Failed] rGHC24afe6d3aae1: Fix missing files > | > | Harbormaster failed to build B5072: rGHC24afe6d3aae1: Fix missing files! > | > | BRANCHES > | master > | > | USERS > | simonpj (Author) > | GHC - Testsuite (Auditor) > | > | COMMIT > | https://phabricator.haskell.org/rGHC24afe6d3aae1 > | > | EMAIL PREFERENCES > | https://phabricator.haskell.org/settings/panel/emailpreferences/ > | > | To: simonpj, GHC - Testsuite > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bergey at teallabs.org Fri Jul 31 01:23:18 2015 From: bergey at teallabs.org (Daniel Bergey) Date: Fri, 31 Jul 2015 01:23:18 +0000 Subject: Typechecker / OverloadedStrings question 7.8 vs. 7.10 In-Reply-To: References: <841f2790eb8b4bb99541e241c0009924@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87y4hxce7t.fsf@chladni.home> On 2015-07-30 at 21:39, Michael Karg wrote: > I guess without that pragma, the string literals already imply t ~ [] for > Foldable t. You're basically right. Without OverloadedStrings, a string literal ("foo") is always a String. With OverloadedStrings, it's free to be any t such that IsString t. (But it's expected to have a monomorphic type, not the polymorphic "foo" :: forall t. IsString t => t) Hence the second error below - GHC tries to pick a type that is both Foldable and IsString, but that's not a unique combination. >> GHC 7.10 fails with the following errors (whereas 7.8 compiles without >> complaining): >> >> >> ghc --make "Testcase.hs" >> [1 of 1] Compiling Main ( Testcase.hs, Testcase.o ) >> Testcase.hs:7:31: >> No instance for (Foldable t0) arising from a use of ?elem? >> The type variable ?t0? is ambiguous >> (...) >> >> Testcase.hs:8:15: >> No instance for (Data.String.IsString (t0 Char)) >> arising from the literal ?"$_-"? >> The type variable ?t0? is ambiguous >> (...) Question for GHC devs: How hard would it be to give a different error message instead of "No instance ..." when the type variable is ambiguous? I always find this error slightly misleading, since it seems to me that there are multiple valid instances, not that there is "no instance". bergey From kazu at iij.ad.jp Fri Jul 31 07:55:32 2015 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Fri, 31 Jul 2015 16:55:32 +0900 (JST) Subject: behavior change of the pretty printer Message-ID: <20150731.165532.1283553748702997939.kazu@iij.ad.jp> Hi, Testing a package with GHC head on Travis CI, I got the following error: ---- expected: Just (HTTPDate {hdYear = 1994, hdMonth = 11, hdDay = 15, hdHour = 8, hdMinute = 12, hdSecond = 31, hdWkday = 2}) but got: Just HTTPDate {hdYear = 1994, hdMonth = 11, hdDay = 15, hdHour = 8, hdMinute = 12, hdSecond = 31, hdWkday = 2} ---- That is, parentheses are not printed. Is this an intentional change of GHC head? --Kazu From thomasmiedema at gmail.com Fri Jul 31 08:15:12 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Fri, 31 Jul 2015 10:15:12 +0200 Subject: behavior change of the pretty printer In-Reply-To: <20150731.165532.1283553748702997939.kazu@iij.ad.jp> References: <20150731.165532.1283553748702997939.kazu@iij.ad.jp> Message-ID: Yes, it is intentional. See https://ghc.haskell.org/trac/ghc/ticket/2530 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Jul 31 08:59:55 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 31 Jul 2015 08:59:55 +0000 Subject: Typechecker / OverloadedStrings question 7.8 vs. 7.10 In-Reply-To: <87y4hxce7t.fsf@chladni.home> References: <841f2790eb8b4bb99541e241c0009924@DB4PR30MB030.064d.mgd.msft.net> <87y4hxce7t.fsf@chladni.home> Message-ID: <02d94e2366ab49aaaaf079fc9fb729a6@DB4PR30MB030.064d.mgd.msft.net> | How hard would it be to give a different error message instead of "No | instance ..." when the type variable is ambiguous? I always find this | error slightly misleading, since it seems to me that there are | multiple valid instances, not that there is "no instance". What would you like it to say? I think it likely we could make it say that! S | -----Original Message----- | From: Daniel Bergey [mailto:bergey at teallabs.org] | Sent: 31 July 2015 02:23 | To: Michael Karg; Simon Peyton Jones | Cc: ghc-devs | Subject: Re: Typechecker / OverloadedStrings question 7.8 vs. 7.10 | | On 2015-07-30 at 21:39, Michael Karg wrote: | > I guess without that pragma, the string literals already imply t ~ | [] | > for Foldable t. | | You're basically right. Without OverloadedStrings, a string literal | ("foo") is always a String. With OverloadedStrings, it's free to be | any t such that IsString t. (But it's expected to have a monomorphic | type, not the polymorphic "foo" :: forall t. IsString t => t) | | Hence the second error below - GHC tries to pick a type that is both | Foldable and IsString, but that's not a unique combination. | | >> GHC 7.10 fails with the following errors (whereas 7.8 compiles | >> without | >> complaining): | >> | >> | >> ghc --make "Testcase.hs" | >> [1 of 1] Compiling Main ( Testcase.hs, Testcase.o ) | >> Testcase.hs:7:31: | >> No instance for (Foldable t0) arising from a use of ?elem? | >> The type variable ?t0? is ambiguous | >> (...) | >> | >> Testcase.hs:8:15: | >> No instance for (Data.String.IsString (t0 Char)) | >> arising from the literal ?"$_-"? | >> The type variable ?t0? is ambiguous | >> (...) | | Question for GHC devs: | | How hard would it be to give a different error message instead of "No | instance ..." when the type variable is ambiguous? I always find this | error slightly misleading, since it seems to me that there are | multiple valid instances, not that there is "no instance". | | bergey From alan.zimm at gmail.com Fri Jul 31 11:09:30 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 31 Jul 2015 13:09:30 +0200 Subject: [GHC] #10250: API Annotations : add Locations in hsSyn were layout occurs In-Reply-To: <059.21a379a81b4c78e24094107cee359072@haskell.org> References: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> <059.21a379a81b4c78e24094107cee359072@haskell.org> Message-ID: Oops, my mistake, Sorry On Fri, Jul 31, 2015 at 12:59 PM, GHC wrote: > #10250: API Annotations : add Locations in hsSyn were layout occurs > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: task | Status: closed > Priority: normal | Milestone: 7.12.1 > Component: Compiler | Version: 7.10.1 > Resolution: fixed | Keywords: > | ApiAnnotations > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Revisions: Phab:D815 > -------------------------------------+------------------------------------- > > Comment (by thomie): > > Phab:D815 was landed on master already, so I'm confused by your message. > > If you're requesting for this to be merged to 7.10.3: just reopen, set the > right milestone, and set it to status=merge. Otherwise it gets lost. > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Fri Jul 31 13:55:45 2015 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Fri, 31 Jul 2015 22:55:45 +0900 (JST) Subject: behavior change of the pretty printer In-Reply-To: References: <20150731.165532.1283553748702997939.kazu@iij.ad.jp> Message-ID: <20150731.225545.428017271838841873.kazu@iij.ad.jp> Thomas, > Yes, it is intentional. See https://ghc.haskell.org/trac/ghc/ticket/2530 Thank you for this information. --Kazu From ggreif at gmail.com Fri Jul 31 13:54:44 2015 From: ggreif at gmail.com (Gabor Greif) Date: Fri, 31 Jul 2015 15:54:44 +0200 Subject: Fundep question Message-ID: Hi all, say I want to instantiate class Dep (a :: k) b | a -> b as instance Dep x y => Dep (Just x) (Maybe y) Is this supposed to work? I get "The coverage condition fails" errors. For simple cases like instance Dep True Bool etc. it seems to work fine. Thanks and cheers, Gabor From eir at cis.upenn.edu Fri Jul 31 15:10:19 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 31 Jul 2015 11:10:19 -0400 Subject: Fundep question In-Reply-To: References: Message-ID: Let's rewrite with explicit kind variables, noting that b is also poly-kinded: class Dep k k2 (a :: k) (b :: k2) | a -> b k2 -- if a determines b, it surely determines k2 instance Dep k * x y => Dep (Maybe k) * (Just x) (Maybe y) Actually, even with the kinds explicit, it still looks valid to me. Post a bug report? Richard On Jul 31, 2015, at 9:54 AM, Gabor Greif wrote: > Hi all, > > say I want to instantiate > > class Dep (a :: k) b | a -> b > > as > > instance Dep x y => Dep (Just x) (Maybe y) > > Is this supposed to work? I get "The coverage condition fails" errors. > > For simple cases like > > instance Dep True Bool > > etc. it seems to work fine. > > Thanks and cheers, > > Gabor > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Fri Jul 31 15:29:55 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 31 Jul 2015 15:29:55 +0000 Subject: Fundep question In-Reply-To: References: Message-ID: <8097cb62673b4720bacc9272ae4a86aa@DB4PR30MB030.064d.mgd.msft.net> you need "liberal coverage checking", so UndecidableInstances. Are you doing that? | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Richard Eisenberg | Sent: 31 July 2015 16:10 | To: Gabor Greif | Cc: ghc-devs | Subject: Re: Fundep question | | Let's rewrite with explicit kind variables, noting that b is also | poly-kinded: | | class Dep k k2 (a :: k) (b :: k2) | a -> b k2 | -- if a determines b, it surely determines k2 | | instance Dep k * x y => Dep (Maybe k) * (Just x) (Maybe y) | | Actually, even with the kinds explicit, it still looks valid to me. | Post a bug report? | | Richard | | On Jul 31, 2015, at 9:54 AM, Gabor Greif wrote: | | > Hi all, | > | > say I want to instantiate | > | > class Dep (a :: k) b | a -> b | > | > as | > | > instance Dep x y => Dep (Just x) (Maybe y) | > | > Is this supposed to work? I get "The coverage condition fails" | errors. | > | > For simple cases like | > | > instance Dep True Bool | > | > etc. it seems to work fine. | > | > Thanks and cheers, | > | > Gabor | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ggreif at gmail.com Fri Jul 31 16:56:05 2015 From: ggreif at gmail.com (Gabor Greif) Date: Fri, 31 Jul 2015 18:56:05 +0200 Subject: Fundep question In-Reply-To: <8097cb62673b4720bacc9272ae4a86aa@DB4PR30MB030.064d.mgd.msft.net> References: <8097cb62673b4720bacc9272ae4a86aa@DB4PR30MB030.064d.mgd.msft.net> Message-ID: No. I'll switch that on and report back. Thanks, Gabor Em sexta-feira, 31 de julho de 2015, Simon Peyton Jones < simonpj at microsoft.com> escreveu: > you need "liberal coverage checking", so UndecidableInstances. Are you > doing that? > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org ] On > Behalf Of > | Richard Eisenberg > | Sent: 31 July 2015 16:10 > | To: Gabor Greif > | Cc: ghc-devs > | Subject: Re: Fundep question > | > | Let's rewrite with explicit kind variables, noting that b is also > | poly-kinded: > | > | class Dep k k2 (a :: k) (b :: k2) | a -> b k2 > | -- if a determines b, it surely determines k2 > | > | instance Dep k * x y => Dep (Maybe k) * (Just x) (Maybe y) > | > | Actually, even with the kinds explicit, it still looks valid to me. > | Post a bug report? > | > | Richard > | > | On Jul 31, 2015, at 9:54 AM, Gabor Greif > wrote: > | > | > Hi all, > | > > | > say I want to instantiate > | > > | > class Dep (a :: k) b | a -> b > | > > | > as > | > > | > instance Dep x y => Dep (Just x) (Maybe y) > | > > | > Is this supposed to work? I get "The coverage condition fails" > | errors. > | > > | > For simple cases like > | > > | > instance Dep True Bool > | > > | > etc. it seems to work fine. > | > > | > Thanks and cheers, > | > > | > Gabor > | > _______________________________________________ > | > ghc-devs mailing list > | > ghc-devs at haskell.org > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Fri Jul 31 17:01:41 2015 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 31 Jul 2015 10:01:41 -0700 Subject: Fundep question In-Reply-To: References: <8097cb62673b4720bacc9272ae4a86aa@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Yeah, this should work with UndecidableInstances. The reason you need that extension is that if we consider the context, then there are some pathological examples that can make GHC's instance checking algorithm go forever. On Fri, Jul 31, 2015 at 9:56 AM, Gabor Greif wrote: > No. I'll switch that on and report back. > > Thanks, > > Gabor > > > Em sexta-feira, 31 de julho de 2015, Simon Peyton Jones < > simonpj at microsoft.com> escreveu: > >> you need "liberal coverage checking", so UndecidableInstances. Are you >> doing that? >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of >> | Richard Eisenberg >> | Sent: 31 July 2015 16:10 >> | To: Gabor Greif >> | Cc: ghc-devs >> | Subject: Re: Fundep question >> | >> | Let's rewrite with explicit kind variables, noting that b is also >> | poly-kinded: >> | >> | class Dep k k2 (a :: k) (b :: k2) | a -> b k2 >> | -- if a determines b, it surely determines k2 >> | >> | instance Dep k * x y => Dep (Maybe k) * (Just x) (Maybe y) >> | >> | Actually, even with the kinds explicit, it still looks valid to me. >> | Post a bug report? >> | >> | Richard >> | >> | On Jul 31, 2015, at 9:54 AM, Gabor Greif wrote: >> | >> | > Hi all, >> | > >> | > say I want to instantiate >> | > >> | > class Dep (a :: k) b | a -> b >> | > >> | > as >> | > >> | > instance Dep x y => Dep (Just x) (Maybe y) >> | > >> | > Is this supposed to work? I get "The coverage condition fails" >> | errors. >> | > >> | > For simple cases like >> | > >> | > instance Dep True Bool >> | > >> | > etc. it seems to work fine. >> | > >> | > Thanks and cheers, >> | > >> | > Gabor >> | > _______________________________________________ >> | > ghc-devs mailing list >> | > ghc-devs at haskell.org >> | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> | >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs at haskell.org >> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggreif at gmail.com Fri Jul 31 19:41:55 2015 From: ggreif at gmail.com (Gabor Greif) Date: Fri, 31 Jul 2015 21:41:55 +0200 Subject: Fundep question In-Reply-To: References: <8097cb62673b4720bacc9272ae4a86aa@DB4PR30MB030.064d.mgd.msft.net> Message-ID: With *UndecidableInstances* switchd on it seems to work :-) Thanks for the help! Gabor Em sexta-feira, 31 de julho de 2015, Gabor Greif escreveu: > No. I'll switch that on and report back. > > Thanks, > > Gabor > > Em sexta-feira, 31 de julho de 2015, Simon Peyton Jones < > simonpj at microsoft.com > > escreveu: > >> you need "liberal coverage checking", so UndecidableInstances. Are you >> doing that? >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of >> | Richard Eisenberg >> | Sent: 31 July 2015 16:10 >> | To: Gabor Greif >> | Cc: ghc-devs >> | Subject: Re: Fundep question >> | >> | Let's rewrite with explicit kind variables, noting that b is also >> | poly-kinded: >> | >> | class Dep k k2 (a :: k) (b :: k2) | a -> b k2 >> | -- if a determines b, it surely determines k2 >> | >> | instance Dep k * x y => Dep (Maybe k) * (Just x) (Maybe y) >> | >> | Actually, even with the kinds explicit, it still looks valid to me. >> | Post a bug report? >> | >> | Richard >> | >> | On Jul 31, 2015, at 9:54 AM, Gabor Greif wrote: >> | >> | > Hi all, >> | > >> | > say I want to instantiate >> | > >> | > class Dep (a :: k) b | a -> b >> | > >> | > as >> | > >> | > instance Dep x y => Dep (Just x) (Maybe y) >> | > >> | > Is this supposed to work? I get "The coverage condition fails" >> | errors. >> | > >> | > For simple cases like >> | > >> | > instance Dep True Bool >> | > >> | > etc. it seems to work fine. >> | > >> | > Thanks and cheers, >> | > >> | > Gabor >> | > _______________________________________________ >> | > ghc-devs mailing list >> | > ghc-devs at haskell.org >> | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> | >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs at haskell.org >> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: