On Wed, May 30, 2007 at 09:21:36PM -0700, Bryan O'Sullivan wrote:
> I notice that select is a bit of a bottleneck in the non-threaded RTS
> once lots of sockets are in play. Between kernel and userspace, many a
> cycle are wasted once we go past a few hundred clients. On some
> operating syste
I notice that select is a bit of a bottleneck in the non-threaded RTS
once lots of sockets are in play. Between kernel and userspace, many a
cycle are wasted once we go past a few hundred clients. On some
operating systems, the fixed nature of fd_set imposes a surprisingly low
ceiling on the
Ian Lynagh wrote:
>
> Hi Maxime,
>
> On Sun, May 27, 2007 at 03:58:47AM +0200, Maxime Henrion wrote:
> >
> > To be more precise, I want to know how to create the
> > ghc-$version-$arch-boot.tar.bz2 file to redistribute to users so
> > that they can build GHC easily, and that on a platform that a
Hi Simon,
On May 30, 2007, at 4:05 PM, Simon Marlow wrote:
Gregory Wright wrote:
I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64
at
http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown-
freebsd.tar.bz2
yay! Ian will supply a link from the download page in due co
Gregory Wright wrote:
I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64
at
http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown-freebsd.tar.bz2
yay! Ian will supply a link from the download page in due course, I'm sure.
No documentation or ghci. The former might b
On 5/30/07, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
| is there any plan to improve GHC's extensibility by providing a
| simpler way to integrante new backends? I worked at Haskell.NET
...
| in GHC's code! I haven't yet figured out how to call the .NET code
| generator from GHC 6.6.1's ma
| is there any plan to improve GHC's extensibility by providing a
| simpler way to integrante new backends? I worked at Haskell.NET
...
| in GHC's code! I haven't yet figured out how to call the .NET code
| generator from GHC 6.6.1's main function. Further, it would be great
| if there was a be
Hi Brian,
the documentation is available at
http://php.cin.ufpe.br/~haskell/haskelldotnet/hsharp.php?m=references
. It has nothing to do with ILX code generator. ILX codegen was an
old project run by Don Syme ([EMAIL PROTECTED]).
Thanks,
Monique
On 5/30/07, Brian Alliet <[EMAIL PROTECTED]>
| In typecheckedSource, I can only access the function definitions with
| type annotations, but not the data type declaration.
| In checkedModuleInfo, I can only access the "Names" of the exported
| entities, and but not their (inferred) types are not present.
You have easy access to the data decl
Hi Kenny,
>
> \begin{code}
>
> main = do
> session <- GHC.newSession GHC.JustTypecheck (Just "Test.hs")
>
> dflags1 <- GHC.getSessionDynFlags session
> (dflags2, packageIds) <- Packages.initPackages dflags1
> GHC.setSessionDynFlags session dflags2{GHC.hscTarget=GHC.HscNothing}
>
>
Good questions.
Fwding to GHC users, to get myself out of the inner loop
Simon
-Original Message-
From: Kenny Zhuo Ming Lu [mailto:[EMAIL PROTECTED]
Sent: 30 May 2007 12:44
To: Simon Peyton-Jones
Subject: GHC as a library
Dear Simon,
I would like to bother you with some questions regar
On Wed, May 30, 2007 at 11:45:33AM -0300, Monique Monteiro wrote:
> simpler way to integrante new backends? I worked at Haskell.NET
> project in the past, when we integrated successfully a .NET code
> generator to GHC 6.2.2.
Do you have any documentation or papers or anything about your .NET
co
Hi (this message is mainly intended to the GHC Team),
is there any plan to improve GHC's extensibility by providing a
simpler way to integrante new backends? I worked at Haskell.NET
project in the past, when we integrated successfully a .NET code
generator to GHC 6.2.2. As it wasn't stable enou
Hi,
I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64
at
http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown-
freebsd.tar.bz2
No documentation or ghci. The former might be easily remedied although
using FreeBSD's docbook chain, as suggested in the wiki, fails when
Why would lists-of-lists be faster than unboxed arrays? No indexing
arithmetic? Deforestation? I'm very curious. The first advice I got
from #haskell when trying to speed up my original code was "get rid of
all those lists."
First, I think lists-of-lists is only faster (if at all) in your spec
15 matches
Mail list logo