The sixth quote :
--- Michael Schuerig [EMAIL PROTECTED] wrote:
On Wednesday 25 September 2002 05:27, Edward Wilson
wrote:
The real question is: if you were a Jedi Knight,
and
you could only master *one* language as your
weapon of
choice, what would it be--Common Lisp?
Joe Buehler wrote:
Simon Marlow wrote:
For the registerised port, you really need a native code generator
(the mangler is on death row, yay). At a rough guess, I'd say porting
the NCG would take a couple of weeks or so for someone unfamiliar with
the code. Hopefully we'll improve that when
As a prerequisite for atttending is proficiency in la bella lingua del si
(also known as Italian) I think I will just write the rest of this message in
it.
Ottimi, ma non particolarmente abbondanti, haskeller italiani,
abbiamo avuto una piccola discussione su #haskell.it circa la
2008/7/25 Pasqualino 'Titto' Assini [EMAIL PROTECTED]:
As a prerequisite for atttending is proficiency in la bella lingua del si
(also known as Italian) I think I will just write the rest of this message in
it.
Ottimi, ma non particolarmente abbondanti, haskeller italiani,
snip
Come data,
On Fri, 25 Jul 2008 10:21:32 +0200, dermiste [EMAIL PROTECTED]
wrote:
The sixth quote :
--- Michael Schuerig [EMAIL PROTECTED] wrote:
On Wednesday 25 September 2002 05:27, Edward Wilson
wrote:
The real question is: if you were a Jedi Knight,
and
you could only master *one* language
Greetings, Haskell-cafe. I am interested in joining or starting a functional
programming interest group in my area. Are there any haskellers in the
Northwest Arkansas region?
Nathan Bloomfield
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Dunno about that, but I'm a NW arkansas expat.
2008/7/25 Nathan Bloomfield [EMAIL PROTECTED]:
Greetings, Haskell-cafe. I am interested in joining or starting a functional
programming interest group in my area. Are there any haskellers in the
Northwest Arkansas region?
Nathan Bloomfield
FYI: Haskell's OpenGL binding has just been dropped from GHC's
extralibs, which means that it will no longer be kept in sync with GHC
development, at least not by GHC HQ.
GHC HQ has its hands full and -generally speaking - extralibs are to
be replaced by H(L)P, the Haskell (Library) Platform:
I don't know how much I can do to keep them in sync, as I don't know
anything about the HLP, however, I'm actively using OpenGL 2.1 in
Haskell for research and prototyping and the inclusion of OpenGL in
Haskell has been central to my case for using it in my workplace. I
don't know what I can do
On Fri, 2008-07-25 at 17:57 +0100, Claus Reinke wrote:
So, if one of you wanted to step forward and offer to keep these
Haskell bindings for OpenGLco maintained, perhaps steward them
into the H(L)P, now would probably be a good time.
I fully expect the GL and AL binding libs to join the
2008/7/23 Levi Greenspan [EMAIL PROTECTED]:
I would be grateful for any advices, hints or comments. And I really
look forward to the FFI section in the Real World Haskell book.
Generally it looks pretty good. I think I'm missing some C code
(function wrapper). However, libevent is an odd choice
claus.reinke:
FYI: Haskell's OpenGL binding has just been dropped from GHC's
extralibs, which means that it will no longer be kept in sync with GHC
development, at least not by GHC HQ.
GHC HQ has its hands full and -generally speaking - extralibs are to
be replaced by H(L)P, the Haskell
Well, since HOpenGL seems to support practically all of OpenGL 2.1, I
don't see that there's much to maintain, except compatibility with
upcoming releases of GHC and possibly some optimization. Maybe I'm
missing something, though. Is there a list of outstanding bugs
somewhere? I personally know
Thanks Adam. It took me some time to realize what you recognized
immediately - xptr is useless. Instead I now bind the additional value
which might be provided on event creation in a closure since the C
code never has to deal with it.
And yes, there are many functions missing. For now I just need
2008/7/25 Levi Greenspan [EMAIL PROTECTED]:
And to not require a permanent thread for each I would
like to use something like select in C or Selector in Java. I haven't
found something like this in Haskell, hence the libevent wrapper.
As far as I know GHC's scheduler uses select() internally.
2008/7/25 Krzysztof Skrzętnicki [EMAIL PROTECTED]:
Developing a high-performance web server in Concurrent Haskell
http://www.haskell.org/~simonmar/papers/web-server-jfp.pdf (see page 15)
Perhaps you might be interested in this paper also because of its topic.
That's a good reference. Also
agl:
2008/7/25 Krzysztof Skrzętnicki [EMAIL PROTECTED]:
Developing a high-performance web server in Concurrent Haskell
http://www.haskell.org/~simonmar/papers/web-server-jfp.pdf (see page 15)
Perhaps you might be interested in this paper also because of its topic.
That's a good
Thank you (and Christopher) for the link. I have one question though -
I read this ticket in the GHC trac:
http://hackage.haskell.org/trac/ghc/ticket/635 which plans to use
epoll instead of select. The reason I thought of libevent is exactly
the support for epoll and other better-than-select
2008/7/25 Levi Greenspan [EMAIL PROTECTED]:
Regarding your remark, that the RTS multiplexes IO already I am usure
how this works out in practice. The reason I write this wrapper is
that I want a network server which can handle thousands of
connections. And to not require a permanent thread for
On Fri, Jul 25, 2008 at 1:32 PM, Levi Greenspan
[EMAIL PROTECTED] wrote:
Thank you (and Christopher) for the link. I have one question though -
I read this ticket in the GHC trac:
http://hackage.haskell.org/trac/ghc/ticket/635 which plans to use
epoll instead of select. The reason I thought of
HOpenGL is in remarkably good shape for being unmaintained for several
years. I think the quiet on the HOpenGL mailing list speaks positively
to the quality of the library.
Perhaps those of us who have an interest in HOpenGL can arrange to work as
comaintainers.
I think I could be
So, if one of you wanted to step forward and offer to keep these
Haskell bindings for OpenGLco maintained, perhaps steward them
into the H(L)P, now would probably be a good time.
Just thought I'd forward this, for those not following cvs-ghc,
Claus
Note the OpenGL are still just as maintained
claus.reinke:
But neither do I believe the rumour that OpenGL isn't much
used, and forwarding the removal notice gives those users the
opportunity to speak up now if they prefer no gaps in OpenGL
presence, or forever to hold their peace, as they say.
I for one have noticed this library *is*
Hi!
If we spend so long blocked on memory reads that we're only utilising
50% of a core's time then there's lots of room for improvements if we
can fill in that wasted time by running another thread.
How can you see how much does your program wait because of L2 misses?
I have been playing
http://valgrind.org/info/tools.html
On 26/07/2008, at 11:02 AM, Mitar wrote:
Hi!
If we spend so long blocked on memory reads that we're only utilising
50% of a core's time then there's lots of room for improvements if we
can fill in that wasted time by running another thread.
How can you
A tool originally developed to measure cache misses in GHC :)
Ben.Lippmeier:
http://valgrind.org/info/tools.html
On 26/07/2008, at 11:02 AM, Mitar wrote:
Hi!
If we spend so long blocked on memory reads that we're only utilising
50% of a core's time then there's lots of room for
On Sat, 2008-07-26 at 03:02 +0200, Mitar wrote:
Hi!
If we spend so long blocked on memory reads that we're only utilising
50% of a core's time then there's lots of room for improvements if we
can fill in that wasted time by running another thread.
How can you see how much does your
27 matches
Mail list logo
