Re: [Haskell-cafe] [Off-topic] Loss of humour
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? Probably. In particular, considering that the Jedi seem to be somewhat conservative and CL beautifully captures the anachronistic elegance and power of a programming lightsaber. Future Jedi generations might choose more modern weapons; Haskell, OCaml and Oz being among the contenders. http://www.xkcd.com/297/ xD I love this guy On Wed, Jul 23, 2008 at 10:57 PM, Jeremy Shaw [EMAIL PROTECTED] wrote: At Wed, 23 Jul 2008 19:45:56 +0100, Andrew Coppin wrote: A while back I found a page somewhere containing some rather amusing IRC quotes. Unfortunately it seems to have vanished. I can't remember where on earth I found it, but I've scoured the Internet trying to track it down. (In particular, it contained a quote of somebody impersonating a typical Haskell newbie - lots of enthusiasm and no attention span! Well it amused *me* anyway...) Anybody have any ideas where this has gone? http://web.archive.org/web/20070609061216/http://www.haskell.org/hawiki/QuotesPage j. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell on ARM (was Re: ANN: Topkata)
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 we refactor the NCG as part of the backend overhaul. Is there any documentation on the NCG? I ported 6.6 to HPUX 11 some time ago and looked at the NCG but didn't do it for PA-RISC because it was going to take too much time to understand. I was leaning towards the approach of trying to translate the code generator for another processor into PA-RISC. There's some old documentation, some of it is still relevant but probably much of it is out of date now: http://darcs.haskell.org/ghc/docs/comm/the-beast/ncg.html the best doc is the code, I'm afraid (but it has lot of illuminating comments and you can get a long way with cut-and-paste). Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Italian Haskellers Summer Meeting?
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 possibilita' di organizzare un incontro estivo. Non credo che ne sia stato mai organizzato uno e quindi vorrei intanto che mi faceste sapere: - se vi interessa - dove siete/sarete d'agosto - che formato debba avere l'incontro Riguardo quest'ultimo punto, direi che ci sono almeno tre possibilita' : a) Ritiro spirituale. Luogo: rifugio di montagna, monastero benedettino. Gli adepti giungono al luogo designato dopo un lungo percorso a piedi attraverso regioni desertiche. Hanno barbe lunghe ed occhi severi ma in cui brilla la luce di una pura fede monoidale. Riunitisi davanti ad un semplice pasto gli adepti spezzano il pane e bevono il vino e si scambiano parabole illuminanti circa la vera natura del Monoide, della Monade e del Funtore Applicativo. Un neofita, che non sa spiegare la differenza fra left e right fold, viene giudicato impuro e ritualmente lapidato. b) Scampagnata fuori porta Luogo: ridente localita' marina od agreste. Gli haskeller arrivano alla spicciolata su una spiaggia animata. Hanno costumi colorati e capelli rasta. Qualcuno ha portato i bambini, tutti hanno portato la paletta ed il secchiello. Si fanno castelli di sabbia, qualcuno passa una canna, si divide una pizza e si chiacchiera' in liberta di haskell, zen e viaggi in motocicletta. L'atmosfera si rabbuia pero' improvvisamente quando viene scoperto un infiltrato provocatore che non sa spiegare la differenza fra left e right fold. Sommariamente giudicato da un tribunale del popolo, l'infelice viene affogato ed abbandonato sulla spiaggia, nell'indifferenza dei bagnanti che continuano a giocare a solitario sui telefonini. c) Seminario accademico Luogo: tetra aula universitaria. Serie presentazioni accademiche si susseguono senza posa. Per ragioni di principio nessuno dei relatori usa power point e riempiono le lavagne nere con suggestivi ma incomprensibili sgorbi. Si suda copiosamente nel caldo estivo e l'olezzo di accademici poco lavati riempie la stanza. Un dottorando dell'universita' di Pisa emoziona l'auditorio, dimostrando in maniera inconfutabile la mirabile corrispondenza fra monoidi destrorsi e logica lineare. Un addottorato del politecnico di Torino, geloso, cerca di staccargli un occhio con un gessetto. Un neofita, che non sa spiegare la differenza fra left e right fold, russa in un angolo. Personalmente, vista la stagione, suggerirei di: - Se c'e' disponibilita' a passare un paio di giorni insieme optare per l'opzione a. Paolino ha proposto a questo proposito di riunirci in un rifugio delle Apuane. - Se invece vogliamo fare una cosa in giornata allora andrei per l'opzione b e suggerirei di vederci sulla spiaggia di Monterosso (5 Terre). Come data, suggerirei l'11 agosto (o 11-12 in caso di opzione a). Per registrarsi, proporre date/luoghi etc, proporrei di utilizzare la pagina wiki dedicata: http://www.haskell.org/haskellwiki/ItaloHaskell/Summer_2008 A presto, titto P.S. Io saro' offline per una settimana a partire da domenica. Pasqualino Titto Assini PhD 25 Heath Road - Wivenhoe CO79PT - Colchester - U.K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Italian Haskellers Summer Meeting?
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, suggerirei l'11 agosto (o 11-12 in caso di opzione a). Che peccato, mi sarebbe piaciuto tornare in Italia (ed il mare a Monterosso e' un bel posto effettivamente) per partecipare al summer meeting, ma in quel periodo sono in vacanza (Copenhagen, prima della conferenza YAPC dei perlisti :-) Purtroppo perdo anche Anglohaskell per la stessa ragione... comunque, sarei interessato a partecipare a futuri meeting di questo genere. Saluti, Hakim (osfameron) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Off-topic] Loss of humour
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 as your weapon of choice, what would it be--Common Lisp? Probably. In particular, considering that the Jedi seem to be somewhat conservative and CL beautifully captures the anachronistic elegance and power of a programming lightsaber. Future Jedi generations might choose more modern weapons; Haskell, OCaml and Oz being among the contenders. http://www.xkcd.com/297/ But you missed the punchline: seen on The Pragmatic Programmer's yahoo mailing list: From: Ronald Legere [EMAIL PROTECTED] Subject: Re: Jedi Programming (was: [pragprog] Common List or Dylan?) To: [EMAIL PROTECTED] Date: Wed, 25 Sep 2002 03:29:01 -0700 (PDT) Reply-To: [EMAIL PROTECTED] No no no, a jedi master must fashion his OWN language. *grin* --- 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? Probably. In particular, considering that the Jedi seem to be somewhat conservative and CL beautifully captures the anachronistic elegance and power of a programming lightsaber. Future Jedi generations might choose more modern weapons; Haskell, OCaml and Oz being among the contenders. -- Benjamin L. Russell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FPers in Northwest Arkansas?
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 http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FPers in Northwest Arkansas?
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fw: patch applied (ghc): Remove the OpenGL family of libraries fromextralibs
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: http://haskell.org/haskellwiki/Haskell_Platform so this part is understandable. But OpenGL has been dropped before H(L)P is ready to take over from extralibs, and at the recent GHC Irc meeting on the topic http://hackage.haskell.org/trac/ghc/attachment/wiki/IRC_Meetings/ghc-2008-07-16.log the mood seemed to favour not including OpenGLco in the initial versions of H(L)P. Sven put a lot of good work into these libraries, but he is often not around for a long time, and it would be a shame if these gems were orphaned and went out of sync in the meantime. While I haven't used OpenGL in a while, I've always hoped to come back to that, not to mention Sven's spatial audio binding additions. And if I'm not mistaken, there are other community members who are using these libs right now for research, possibly even prototyping in connection with a startup? 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 - Original Message - From: Ian Lynagh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 25, 2008 12:11 AM Subject: patch applied (ghc): Remove the OpenGL family of libraries fromextralibs Thu Jul 24 03:27:36 PDT 2008 Ian Lynagh [EMAIL PROTECTED] * Remove the OpenGL family of libraries from extralibs M ./libraries/Makefile -4 M ./libraries/extra-packages -4 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080724102736-3fd76-f5601cb7a290661124c44e9ec6c113812c12d08d.gz ___ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [HOpenGL] Fw: patch applied (ghc): Remove the OpenGL family of libraries fromextralibs
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 to help, but if anyone will point me in the right direction, I'll try to throw some inertia at it... -- Jeff On Fri, Jul 25, 2008 at 12:57 PM, Claus Reinke [EMAIL PROTECTED] wrote: 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: http://haskell.org/haskellwiki/Haskell_Platform so this part is understandable. But OpenGL has been dropped before H(L)P is ready to take over from extralibs, and at the recent GHC Irc meeting on the topic http://hackage.haskell.org/trac/ghc/attachment/wiki/IRC_Meetings/ghc-2008-07-16.log the mood seemed to favour not including OpenGLco in the initial versions of H(L)P. Sven put a lot of good work into these libraries, but he is often not around for a long time, and it would be a shame if these gems were orphaned and went out of sync in the meantime. While I haven't used OpenGL in a while, I've always hoped to come back to that, not to mention Sven's spatial audio binding additions. And if I'm not mistaken, there are other community members who are using these libs right now for research, possibly even prototyping in connection with a startup? 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 - Original Message - From: Ian Lynagh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 25, 2008 12:11 AM Subject: patch applied (ghc): Remove the OpenGL family of libraries fromextralibs Thu Jul 24 03:27:36 PDT 2008 Ian Lynagh [EMAIL PROTECTED] * Remove the OpenGL family of libraries from extralibs M ./libraries/Makefile -4 M ./libraries/extra-packages -4 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080724102736-3fd76-f5601cb7a290661124c44e9ec6c113812c12d08d.gz ___ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc ___ HOpenGL mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/hopengl -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fw: patch applied (ghc): Remove the OpenGL family of libraries fromextralibs
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 Haskell platform set on a subsequent iteration (along with many other popular high quality libs). The intention is to not give ourselves too large a workload on the first iteration. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Libevent FFI problems
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 to wrap. The RTS already multiplexes IO for Haskell programs. In order not to block the RTS, the libevent using code would have to be in its own kernel thread. Really, the RTS needs to be ported to libevent rather than an FFI wrapping. For your specific problem, I see you're allocating xptr, but I don't see that you're ever poking a value into it. Indeed, I can't see that createEvent ever uses 'x'. Hope that helps. AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fw: patch applied (ghc): Remove the OpenGL family of libraries fromextralibs
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 (Library) Platform: http://haskell.org/haskellwiki/Haskell_Platform so this part is understandable. But OpenGL has been dropped before H(L)P is ready to take over from extralibs, and at the recent GHC Irc meeting on the topic http://hackage.haskell.org/trac/ghc/attachment/wiki/IRC_Meetings/ghc-2008-07-16.log the mood seemed to favour not including OpenGLco in the initial versions of H(L)P. Sven put a lot of good work into these libraries, but he is often not around for a long time, and it would be a shame if these gems were orphaned and went out of sync in the meantime. While I haven't used OpenGL in a while, I've always hoped to come back to that, not to mention Sven's spatial audio binding additions. And if I'm not mistaken, there are other community members who are using these libs right now for research, possibly even prototyping in connection with a startup? 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 as they used to be -- that is, it hasn't had a maintainer for several years. The only change is that the GHC developers don't put them in a tarball on haskell.org/ghc prior to releasing GHC itself. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fw: patch applied (ghc): Remove the OpenGL family of libraries fromextralibs
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 of one bug that I found some time ago, which I simply worked around, but a comprehensive list, I'm not aware of. -- Jeff On Fri, Jul 25, 2008 at 1:27 PM, Don Stewart [EMAIL PROTECTED] wrote: 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 (Library) Platform: http://haskell.org/haskellwiki/Haskell_Platform so this part is understandable. But OpenGL has been dropped before H(L)P is ready to take over from extralibs, and at the recent GHC Irc meeting on the topic http://hackage.haskell.org/trac/ghc/attachment/wiki/IRC_Meetings/ghc-2008-07-16.log the mood seemed to favour not including OpenGLco in the initial versions of H(L)P. Sven put a lot of good work into these libraries, but he is often not around for a long time, and it would be a shame if these gems were orphaned and went out of sync in the meantime. While I haven't used OpenGL in a while, I've always hoped to come back to that, not to mention Sven's spatial audio binding additions. And if I'm not mistaken, there are other community members who are using these libs right now for research, possibly even prototyping in connection with a startup? 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 as they used to be -- that is, it hasn't had a maintainer for several years. The only change is that the GHC developers don't put them in a tarball on haskell.org/ghc prior to releasing GHC itself. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Libevent FFI problems
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 the event notification to detect file descritor (or socket) changes. 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 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. If you have any information how to write something like this without this wrapper I would be more than happy. Finally the code still leaks FunPtrs as so far I never free them and honestly I don't know when to do this. Any ideas? For reference I have attached a newer version of the wrapper code (removed the TimeVal stuff since I don't need it). Thanks again, Levi On Fri, Jul 25, 2008 at 7:21 PM, Adam Langley [EMAIL PROTECTED] wrote: 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 to wrap. The RTS already multiplexes IO for Haskell programs. In order not to block the RTS, the libevent using code would have to be in its own kernel thread. Really, the RTS needs to be ported to libevent rather than an FFI wrapping. For your specific problem, I see you're allocating xptr, but I don't see that you're ever poking a value into it. Indeed, I can't see that createEvent ever uses 'x'. Hope that helps. AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org hsevent.hsc Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Libevent FFI problems
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. At least it was using at the time of writing this paper: 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. Christopher Skrzętnicki ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Libevent FFI problems
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 note that the paper is 6 years old and GHC has come a long way since then. I'd suspect that the graph on page 15 would look much more favourable to Haskell these days. AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Libevent FFI problems
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 reference. Also note that the paper is 6 years old and GHC has come a long way since then. I'd suspect that the graph on page 15 would look much more favourable to Haskell these days. Ask Johan about the minimum 5k/sec web server using heavy concurrency he's hacking on. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Libevent FFI problems
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 mechanisms. Is there progress in GHC with regard to this? This is very important for me since I awill not write a web-server, but rather want to play with Comet (i.e. having thousands of open connections as it is common for long-polling in addition to many relatively short request/response based connections). However it seems no quite attractive to go with what is offered by GHC currently instead of writing the libevent wrapper. Just for the sake of completeness - any insights into the freeFunPtr issue I wrote about? ;-) Many thanks to all of you. - Levi On Fri, Jul 25, 2008 at 10:05 PM, Adam Langley [EMAIL PROTECTED] wrote: 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 note that the paper is 6 years old and GHC has come a long way since then. I'd suspect that the graph on page 15 would look much more favourable to Haskell these days. AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Libevent FFI problems
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 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. If you have any information how to write something like this without this wrapper I would be more than happy. The current model for concurrency in Haskell is m lightweight user-threads working on n kernel threads, thus the threads are very cheap in Haskell and take advantage of a multicore. I think with the current model, the right choice for a web server in Haskell is a multi-threaded model. As a point of comparison, I remember that blog post which noted that its FastCGI was able to withstand more than 3000 hits by second (on a quite normal setting). -- Jedaï ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Libevent FFI problems
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 libevent is exactly the support for epoll and other better-than-select mechanisms. Is there progress in GHC with regard to this? This is very important for me since I awill not write a web-server, but rather want to play with Comet (i.e. having thousands of open connections as it is common for long-polling in addition to many relatively short request/response based connections). Bryan O'Sullivan make an off-the-cuff remark about doing this work at a talk a few months back, however I haven't heard anything about him starting. I think it's safe to assume that no one has taken it up yet. Personally, some of my other projects are higher priorities at the moment. I'd suggest that you write your server on the select() based system as-is for now. Then, when you need epoll you'll be sufficiently motivated to hack up the RTS to include it ;) AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [HOpenGL] Fw: patch applied (ghc): Remove the OpenGL family of libraries fromextralibs
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 bothered to do weekly builds against GHC to make sure we stay up to date. I'll set that up in the next month or so. Jeff, please point me to your bug. I'd like to take a look. --Lane On Fri, 25 Jul 2008, Jefferson Heard wrote: 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 to help, but if anyone will point me in the right direction, I'll try to throw some inertia at it... -- Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fw: patch applied (ghc): Remove the OpenGL familyof libraries fromextralibs
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 as they used to be -- that is, it hasn't had a maintainer for several years. Some people post the funniest rumours as if they were facts. $ ghc-pkg field OpenGL maintainer maintainer: [EMAIL PROTECTED] At the end of this message, I also append the output of darcs changes since OpenGL 2.1 was supported, for those interested in what might be involved in maintainance: Fri Nov 10 10:14:54 GMT Standard Time 2006 [EMAIL PROTECTED] * Updated Haddock module headers (now OpenGL 2.1 support, API is stable) It just so happens that the library is very stable (unlike other libraries I could think of;-) - Sven's last bug-fix patch was in March 2007, the patches since then have been build system evolution/maintainance. So the problem is not with the library, but with the environment - since its creation, the library has seen FFI tools appear and disappear, FFI spec and library hierarchy take shape, darcs appear and be taken on, Cabal appear and be taken on, packages and tools move on, split up, change their API, etc. - thanks to Sven and others, the binding has weathered all that, without making a lot of noise. And now, there is another enviroment change, with extralibs going and the Haskell Platform aiming to improve the Haskell installation experience. And new quality criteria will be prescribed that this old library will have to meet to be allowed in with the new kids on the block. The only change is that the GHC developers don't put them in a tarball on haskell.org/ghc prior to releasing GHC itself. It isn't the tarballing, it is (a) whether the library is run in the HEAD buildbots to flush out breaking changes to the environment early (b) whether enviroment changes are reflected in the library to unbreak its build before user installations are affected (c) whether the library can be relied on as being available on default Haskell installations (this would seem to be less of a problem with Cabal/hackage and user installs, but not all clients have install privileges/tools - OpenGL building uses configure, which in itself might not be installed on Windows; and in some University contexts, installation for public PCs is on a centralised, yearly basis, not per student; etc.; adding the GLUT dll has been a popular request ever since GHC had Windows installers, meaning that every single time someone forgets to put that dll in the installer, someone has reported it as a bug/feature request) I'm not aware of any urgent breakage in the OpenGL binding, nor is the current source going away, and as Duncan says, he expects OpenGL to reappear in the Haskell Platform later on. 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. Unless Sven wants to do the job himself, a maintainer would mainly have to adapt the library to the Haskell Platform criteria, keep up with the forever changing build environments, and counter rumours about the OpenGL binding being unmaintained or unused. Claus $ darcs changes --from-patch=stable Thu Jun 19 13:43:50 GMT Daylight Time 2008 Ian Lynagh iglooearth.li tagged GHC 6.8.3 release Fri Jun 6 00:56:57 GMT Daylight Time 2008 Ian Lynagh iglooearth.li tagged 2008-06-06 Sat Nov 10 01:11:04 GMT Standard Time 2007 Ian Lynagh iglooearth.li tagged GHC 6.8.1 release Sat Nov 10 01:09:54 GMT Standard Time 2007 Ian Lynagh iglooearth.li tagged 2.2.1.1 release Sat Oct 27 13:48:05 GMT Daylight Time 2007 Ian Lynagh iglooearth.li * Bump version number Thu Oct 18 18:31:37 GMT Daylight Time 2007 Duncan Coutts duncanhaskell.org * Specify build-type: Configure Mon Jun 4 12:59:36 GMT Daylight Time 2007 Ross Paterson rosssoi.city.ac.uk * --configure-option and --ghc-option are now provided by Cabal Thu May 24 15:56:14 GMT Daylight Time 2007 Ian Lynagh iglooearth.li * Remove Makefile and package.conf.in (used in the old GHC build system) Thu May 17 10:49:12 GMT Daylight Time 2007 Simon Marlow simonmarmicrosoft.com * add includes: field Mon Apr 30 12:17:32 GMT Daylight Time 2007 Ian Lynagh iglooearth.li * Make configure fail if the package cannot be built Sat Apr 28 20:58:51 GMT Daylight Time 2007 Ian Lynagh iglooearth.li tagged GHC 6.6.1 release Sat Apr 28 20:56:55 GMT Daylight Time 2007 Ian Lynagh iglooearth.li tagged 2.2.1 release Tue Apr 24 12:39:29 GMT Daylight Time 2007 Ian Lynagh iglooearth.li tagged GHC 6.6.1 release Tue Apr 24 12:38:31 GMT Daylight Time 2007 Ian Lynagh iglooearth.li tagged Version 2.2.1 Sun
Re: [Haskell-cafe] Fw: patch applied (ghc): Remove the OpenGL familyof libraries fromextralibs
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* actively used. Many of the fun new games that have appeared are using it, in particular. Such as: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/frag http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Monadius http://hackage.haskell.org/cgi-bin/hackage-scripts/package/roguestar-gl http://hackage.haskell.org/cgi-bin/hackage-scripts/package/rsagl http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shu-thing http://hackage.haskell.org/cgi-bin/hackage-scripts/package/topkata The tutorial was also translated to the wiki last week, http://haskell.org/haskellwiki/Opengl It's a good, reliable package, in active use, widely ported. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Sun Microsystems and Haskell.org joint project on OpenSPARC
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 lately with dual Quad-Core Intel Xeon Mac Pros with 12 MB L2 cache per CPU and 1.6 GHz bus speed and it would be interesting to check this things there. Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Sun Microsystems and Haskell.org joint project on OpenSPARC
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 see how much does your program wait because of L2 misses? I have been playing lately with dual Quad-Core Intel Xeon Mac Pros with 12 MB L2 cache per CPU and 1.6 GHz bus speed and it would be interesting to check this things there. Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Sun Microsystems and Haskell.org joint project on OpenSPARC
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 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 lately with dual Quad-Core Intel Xeon Mac Pros with 12 MB L2 cache per CPU and 1.6 GHz bus speed and it would be interesting to check this things there. Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Sun Microsystems and Haskell.org joint project on OpenSPARC
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 program wait because of L2 misses? I have been playing lately with dual Quad-Core Intel Xeon Mac Pros with 12 MB L2 cache per CPU and 1.6 GHz bus speed and it would be interesting to check this things there. Take a look at the paper that Ben referred to http://www.cl.cam.ac.uk/~am21/papers/msp02.ps.gz They use hardware performance counters. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
