On 9 September 2010 22:10, Mathew de Detrich dete...@gmail.com wrote:
It should also hopefully make using Haskell packages on windows that use C
sources less painful
Clang could also make using FFI with C++ much easier (for reasons stated
above)
Thoughts?
I don't think it would make it any
2010/9/10 kyra ky...@mail.ru:
I wonder if llvm-gcc supports it's own (gcc) extensions. If it supports then
there is no need to stuck in clang right now.
It doesn't support the one I mentioned before of global register
variables. I haven't looked for a while so maybe this has changed but
On 13 September 2010 20:41, Vo Minh Thu not...@gmail.com wrote:
... the post is from 2008. No LLVM goodness. So I thought GHC 6.12.1
(not the latest and greatest HEAD) would be enough.
I compiled the two programs myself out of curiosity and got the following times.
Linux, 64bit, Ubuntu 10.10:
Here is a more manual way to do it, hopefully this shows the approach
required. You don't need to store anything, just keep removing the
head of the list until its of the size you want.
n_lastn :: Int - [a] - [a]
n_lastn n xs =
let len = length xs - n
drp = if len 0 then 0 else len
I by pure coincidence was fixing a bug in some code in GHC that
involved converting a Haskell float into a hex IEEE form, this is how
its done in the code, just to add another way :)
castDoubleToWord8Array :: STUArray s Int Double - ST s (STUArray s Int Word8)
castDoubleToWord8Array =
Good chance you've already read this but if not here is a good post by
Linus about his take on the problems with darcs:
http://markmail.org/message/vk3gf7ap5auxcxnb
I personally think he is right on the money here. The other problem
with Darcs is performance. While it has improved a lot its
Hi All,
I have made some improvements to the syntax highlighting file for
Haskell included with Vim. I'd like to push them upstream. The
haskell.vim syntax file included with Vim lists this mailing list as
the maintainer. I take that to mean no one. Is this right or does
someone actually have
There is also:
https://github.com/haskell
where a bunch of us are hosting librari
On 10 January 2012 12:01, Erik de Castro Lopo mle...@mega-nerd.com wrote:
Simon Michael wrote:
- the repo will be moved to github, under my account since I don't
think there's a haskell community one
On 19 April 2012 08:12, Ryan Newton rrnew...@gmail.com wrote:
Hello all,
Right now I'm trying to answer a simple question:
Would the current Haskell.org / hackage infrastructure benefit from the
donation of a dedicated VM with good bandwidth/uptime?
Whoever already knows how to do this
Oh yes, it's hackage2... not hackage1.
On 19 April 2012 11:50, David Terei dave.te...@gmail.com wrote:
On 19 April 2012 08:12, Ryan Newton rrnew...@gmail.com wrote:
Hello all,
Right now I'm trying to answer a simple question:
Would the current Haskell.org / hackage infrastructure benefit
Hi all,
I've updated the old hackage-test tool and renamed to hackager.
http://hackage.haskell.org/package/hackager
Hackager is a tool to automate the compiling of all packages on
Hackage. It builds each package on hackage in isolation and records
the results. The purpose being to catch
On 17 May 2012 23:50, Ryan Newton rrnew...@gmail.com wrote:
Thanks David.
I'm glad to see it was discussed in the wiki. (Btw, my 2 cents is that I
like the comment pragmas more than new keywords.)
Sure, the proposed syntax wasn't a serious proposal as it has
backwards compatibility issues so
So this is a good question, sorry for the late reply. It's tricky as
the way typeclasses are imported and exported in Haskell is confusing.
Basically, instances are hard to control access to as they aren't part
of import or export statements. Importing a module that defines an
instances gives you
think it needs a
paragraph like the one of yours above but I don't know if it does
right now.
On Sat, Jun 2, 2012 at 2:28 AM, David Terei dave.te...@gmail.com wrote:
So this is a good question, sorry for the late reply. It's tricky as
the way typeclasses are imported and exported in Haskell
14 matches
Mail list logo
