#9099: Add strict fmap
-------------------------------------------+-------------------------------
Reporter: quchen | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: None | Version: 7.8.2
Keywords: | Operating System:
Architecture: Unknown/Multiple | Unknown/Multiple
Difficulty: Easy (less than 1 hour) | Type of failure:
Blocked By: | None/Unknown
Related Tickets: | Test Case:
| Blocking:
-------------------------------------------+-------------------------------
Add a strict version of fmap to the standard libraries.
{{{
infixl 4 <$!>
(<$!>) :: Monad m => (a -> b) -> m a -> m b
f <$!> m = do x <- m
return $! f x
{-# INLINE (<$!>) #-}
}}}
Libraries discussions:
Take 1:
http://www.haskell.org/pipermail/libraries/2013-November/021728.html
Take 3: http://www.haskell.org/pipermail/libraries/2014-April/022864.html
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9099>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#10066: Cross compiling from Linux to Windows fails
-------------------------------------+-------------------------------------
Reporter: erikd | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 7.12.1
Component: Compiler | Version: 7.10.1-rc2
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: Building GHC
Unknown/Multiple | failed
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Revisions: |
-------------------------------------+-------------------------------------
Building from git HEAD (daed18c35cda1) and configuring with:
{{{
./configure --target=i686-w64-mingw32
}}}
The build then fails with:
{{{
utils/hsc2hs/dist/build/Main.o: In function `c4tf_info':
(.text+0x80a): undefined reference to `GetModuleFileNameW'
}}}
but earlier on there was other suspicious output like:
{{{
utils/hsc2hs/Main.hs:234:1: Warning:
the 'stdcall' calling convention is unsupported on this platform,
treating as ccall
When checking declaration:
foreign import stdcall unsafe "static windows.h
GetModuleFileNameW" c_GetModuleFileName
:: Ptr () -> CWString -> Word32 -> IO Word32
}}}
which suggests that the cross tool chain is not being used. However, the
configure process did indeed find the right cross compilers and linkers.
From the configure output:
{{{
Building GHC version : 7.11.20150204
Git commit id : daed18c35cda114d8a5303bcb645195e1fd397e3
Build platform : x86_64-unknown-linux
Host platform : x86_64-unknown-linux
Target platform : i386-unknown-mingw32
Bootstrapping using : /usr/bin/ghc
which is version : 7.8.3
Using gcc : /usr/bin/i686-w64-mingw32-gcc
which is version : 4.9.2
Building a cross compiler : YES
cpp : /usr/bin/i686-w64-mingw32-gcc
cpp-flags : -E -undef -traditional
ld : /usr/bin/i686-w64-mingw32-ld
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10066>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#8796: -ddump-splices prints to error stream
-------------------------------------------+-------------------------------
Reporter: jstolarek | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.9
Keywords: | Operating System:
Architecture: Unknown/Multiple | Unknown/Multiple
Difficulty: Easy (less than 1 hour) | Type of failure:
Blocked By: | None/Unknown
Related Tickets: | Test Case:
| Blocking:
-------------------------------------------+-------------------------------
I just noticed that unlike other dump flags, `-ddump-splices` dumps to the
error stream. I don't think this difference in behaviour is intended.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8796>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
