| On a similar note, how about the .NET support? Can it work on a
| platform where the only .NET support is Mono?
This comes up regularly. Here's my message from Jan:
http://www.haskell.org/pipermail/glasgow-haskell-users/2005-January/0075
94.html
Simon
===
It'd make
This sounds like a good idea to me.
As far as possible, we should keep the platform-dependence restricted to
the implementation of one module (System.Posix.Internals will do, even
though this isn't really POSIX any more). So System.Posix.Internals
exports the CFilePath/CFileOffset types, and the
On 21 November 2005 22:03, Esa Ilari Vuokko wrote:
Attached small simple patch that allows using --mk-dll with --make.
Behaviour before patch was to link .exe instead .dll, as batchmode
simply called staticLink - now doMkDLL is called instead.
* Add support for using --mk-dll with --make
On 22 November 2005 17:18, Michael Marte wrote:
I am having some annoying problems with the 6.x compilers:
6.4 and 6.4.1: When repeating a build (with ghc --make) all modules
are rebuild even if nothing has changed. With earlier compilers,
only linking takes place in this setting.
On 23 November 2005 09:32, Simon Peyton-Jones wrote:
On a similar note, how about the .NET support? Can it work on a
platform where the only .NET support is Mono?
This comes up regularly. Here's my message from Jan:
http://www.haskell.org/pipermail/glasgow-haskell-users/2005-January/0075
6.4 and 6.4.1: When repeating a build (with ghc --make) all modules
are rebuild even if nothing has changed. With earlier compilers,
only linking takes place in this setting. Can I change this
behaviour? I cannot develop this way.
Should not happen, if it does there
Simon,
On Wed, 23 Nov 2005, Simon Marlow wrote:
On 22 November 2005 17:18, Michael Marte wrote:
I am having some annoying problems with the 6.x compilers:
6.4 and 6.4.1: When repeating a build (with ghc --make) all modules
are rebuild even if nothing has changed. With earlier
I would like to do a horrible naughty thing (which I promise never to
expose to the world). I would like to tell whether a term is in
WHNF, without forcing evaluation of that term. Something like:
isWHNF :: a - Bool
Is there a way of doing this? I can fake it with an IORef and much
I downloaded ghc-6.5.20051122-i386-unknown-linux.tar.bz2 and tried to use it
(as bootstrap for building Haskell at first, but building Pugs fails the
same way)
It installed fine.
My attempts to compile something with it result with a following error:
ghc-6.5.20051122: could not execute:
The appended snippet might help..
--sigbjorn
-- whnf.hs
import Foreign.StablePtr
import System.IO.Unsafe
isWHNF :: a - Bool
isWHNF a = unsafePerformIO $ do
stl - newStablePtr a
rc - isWhnf stl
freeStablePtr stl
return (rc /= 0)
foreign import ccall safe isWhnf isWhnf :: StablePtr a -
Hello Simon,
Wednesday, November 23, 2005, 2:28:26 PM, you wrote:
SM int64ToWord64# = unsafeCoerce#
SM word64ToInt64# = unsafeCoerce#
SM this should reduce the cost of the conversions to zero, which is a
SM simpler way to fix the performance bug (if it works).
SM If you confirm that this
Hello Simon,
Wednesday, November 23, 2005, 2:22:02 PM, you wrote:
SM This sounds like a good idea to me.
SM As far as possible, we should keep the platform-dependence restricted to
SM the implementation of one module (System.Posix.Internals will do, even
SM though this isn't really POSIX any
Help build the anticipation:
http://haskell.org/hawiki/GHC_206_2e6
Present text:
GHC 6.6:
Will be out before May 2006.
Included:
* Parallel GHC
* Associated types with class
Maybe:
* Impredicativity
* GADT Typeclass interaction
* Data types as kinds
No:
Jim
Bulat Ziganshin wrote:
Hello Simon,
Wednesday, November 23, 2005, 2:28:26 PM, you wrote:
int64ToWord64# = unsafeCoerce#
word64ToInt64# = unsafeCoerce#
this should reduce the cost of the conversions to zero, which is a
simpler way to fix the performance bug (if it works).
If you
14 matches
Mail list logo