Re: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
On 2009 Jan 9, at 20:51, Tim Newsham wrote: I'm suprised htonl comes up so often. You can unmarshall data directly from a byte stream to an Int type without caring about the underlying representation of your Int. Why do people want the htonl function? IP address math. (see @ipcalc in #lopsa's lambdabot) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
Don't get me wrong -- the socket support is pretty decent, but there are also some weird idiosyncrasies, for example requiring that the PortNum is specified in network byte order and lacking a function to convert host->network byte order (hton). PortNum is indeed strange, but it does allow yo to specify the value in your local endian without swapping: > print (toEnum 0x0102 :: PortNumber) 258 what is misleading you is that the obvious construction doesn't: > print (PortNum 0x0102) 513 I'm suprised htonl comes up so often. You can unmarshall data directly from a byte stream to an Int type without caring about the underlying representation of your Int. Why do people want the htonl function? Bardur Arantsson Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
Bardur Arantsson wrote: > Thanks. For some reason I hadn't thought to use > > (fromIntegral x)::PortNumber > > I guess I got stuck on the idea of constructing a PortNum directly and > didn't think beyond that. (Maybe PortNum should really be an abstract No problem. I knew exactly what your problem was because I had the exact same blinders on when I first learned the Haskell networking API. It would be helpful to have a pointer to this in the Haddock docs, because it is non-intuitive to somebody just learning it. > I guess the API isn't all that idiosyncratic after all :). Just a touch under-documented ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
On Thu, 8 Jan 2009, Bardur Arantsson wrote: Thanks. For some reason I hadn't thought to use (fromIntegral x)::PortNumber I guess I got stuck on the idea of constructing a PortNum directly and didn't think beyond that. (Maybe PortNum should really be an abstract type to force indirect construction...?) I also think that a Num instance for PortNumber is not a good idea. How shall (+) and (*) be defined? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
John Goerzen wrote: On Thu, Jan 08, 2009 at 10:37:55PM +0100, Bardur Arantsson wrote: Don't get me wrong -- the socket support is pretty decent, but there are also some weird idiosyncrasies, for example requiring that the PortNum is specified in network byte order and lacking a function to convert host->network byte order (hton). Look at Haddock for PortNumber: newtype PortNumber Constructors PortNum Word16 Instances Enum PortNumber Eq PortNumber Integral PortNumber Num PortNumber Ord PortNumber Real PortNumber Show PortNumber Typeable PortNumber Storable PortNumber Try it in ghci: Prelude Network.Socket> 15 :: PortNumber 15 Prelude Network.Socket> PortNum 15 3840 Prelude Network.Socket> (fromIntegral (15::Int))::PortNumber 15 So, in essence, there are *many* functions that let you do this. You should not be needing to construct PortNum by hand. Thanks. For some reason I hadn't thought to use (fromIntegral x)::PortNumber I guess I got stuck on the idea of constructing a PortNum directly and didn't think beyond that. (Maybe PortNum should really be an abstract type to force indirect construction...?) I guess the API isn't all that idiosyncratic after all :). Cheers, Bardur Arantsson ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
On Thu, Jan 08, 2009 at 10:37:55PM +0100, Bardur Arantsson wrote: > Don't get me wrong -- the socket support is pretty decent, but there are > also some weird idiosyncrasies, for example requiring that the PortNum > is specified in network byte order and lacking a function to convert > host->network byte order (hton). Look at Haddock for PortNumber: newtype PortNumber Constructors PortNum Word16 Instances Enum PortNumber Eq PortNumber Integral PortNumber Num PortNumber Ord PortNumber Real PortNumber Show PortNumber Typeable PortNumber Storable PortNumber Try it in ghci: Prelude Network.Socket> 15 :: PortNumber 15 Prelude Network.Socket> PortNum 15 3840 Prelude Network.Socket> (fromIntegral (15::Int))::PortNumber 15 So, in essence, there are *many* functions that let you do this. You should not be needing to construct PortNum by hand. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
> PortNum is specified in network byte order and lacking a function to convert host->network byte order (hton). Perhaps this is another argument for my thread from a while back? http://www.nabble.com/Missing-Network-Functions-td21188779.html /jve On Thu, Jan 8, 2009 at 4:37 PM, Bardur Arantsson wrote: > Manlio Perillo wrote: > >> John Goerzen ha scritto: >> >>> On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote: >>> [...] >>> >>> On the other hand, I see nothing in Haskell that would prevent its use >>> for any of your purposes. There are numerous high-level web >>> infrastructures already. Perhaps they are more or less suited to your >>> needs, but that's a library issue, not a language issue. >>> >> >> >> The question is not about Haskell language. >> I think that Haskell is far better than Erlang, and in fact I'm studying >> Haskell and not Erlang; and one of the reason I choosed Haskell is for its >> support to concurrency. >> >> The problem, IMHO, is with the availability of solid, production ready >> servers implemented in Haskell, that can be used as case study. >> >> The major web framework in Haskell is HAppS, if I'm correct, and yet in >> the HAppS code I see some things that make me worry about the robustess of >> the code. >> >> [--snip--] > > Indeed. I've been looking for a Haskell HTTP server implementation that can > actually handle file serving using strictly limited memory (for a simple > UPnP server, as of yet unreleased) and that also doesn't leak handles like a > sieve, but I haven't found anything yet. I don't know, maybe my hackage-foo > is lacking. In the end I just rolled my own implementation using the HTTP > package for parsing requests and doing all the socket I/O myself using > low-level primitives. It seemed to be the only way to guarantee reasonable > resource usage while serving multi-gigabyte files to fickle HTTP clients > that like to drop connections willy-nilly. > > Don't get me wrong -- the socket support is pretty decent, but there are > also some weird idiosyncrasies, for example requiring that the PortNum is > specified in network byte order and lacking a function to convert > host->network byte order (hton). > > Oleg's Iteratee does look very interesting though. Maybe I'll have a go at > trying to use his ideas in my UPnP server. > > Cheers, > > Bardur Arantsson > > > ___ > 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 not ready for Foo [was: Re: Hypothetical Haskell job in New York]
Manlio Perillo wrote: John Goerzen ha scritto: On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote: [...] On the other hand, I see nothing in Haskell that would prevent its use for any of your purposes. There are numerous high-level web infrastructures already. Perhaps they are more or less suited to your needs, but that's a library issue, not a language issue. The question is not about Haskell language. I think that Haskell is far better than Erlang, and in fact I'm studying Haskell and not Erlang; and one of the reason I choosed Haskell is for its support to concurrency. The problem, IMHO, is with the availability of solid, production ready servers implemented in Haskell, that can be used as case study. The major web framework in Haskell is HAppS, if I'm correct, and yet in the HAppS code I see some things that make me worry about the robustess of the code. [--snip--] Indeed. I've been looking for a Haskell HTTP server implementation that can actually handle file serving using strictly limited memory (for a simple UPnP server, as of yet unreleased) and that also doesn't leak handles like a sieve, but I haven't found anything yet. I don't know, maybe my hackage-foo is lacking. In the end I just rolled my own implementation using the HTTP package for parsing requests and doing all the socket I/O myself using low-level primitives. It seemed to be the only way to guarantee reasonable resource usage while serving multi-gigabyte files to fickle HTTP clients that like to drop connections willy-nilly. Don't get me wrong -- the socket support is pretty decent, but there are also some weird idiosyncrasies, for example requiring that the PortNum is specified in network byte order and lacking a function to convert host->network byte order (hton). Oleg's Iteratee does look very interesting though. Maybe I'll have a go at trying to use his ideas in my UPnP server. Cheers, Bardur Arantsson ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
John A. De Goes wrote: Here's hoping someone develops a native messaging framework for Haskell, which is the equal of RabbitMQ. The first thing would be to make a Haskell client library to speak AMQP (Advanced Message Queuing Protocol) on the wire. It is a very open binary standard (with defined semantics!) at http://jira.amqp.org/confluence/display/AMQP/Advanced+Message+Queuing+Protocol I would be mildly surprised if zero people were working on this. Once that is in place then the question of a Haskell Broker for AMQP arises. But I suspect that Erlang's runtime will still rule there for "production use". -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
On 2009-01-08 12:10, Achim Schneider wrote: Manlio Perillo wrote: Unfortunately Haskell is not yet ready for this task. Could you -- or someone else -- please elaborate on this? I think Haskell is ready for a lot more than most people think. How about an operating system in Haskell, for example? I think House shows that it could be done. http://programatica.cs.pdx.edu/House/ I've heard it once in the context of a webbrowser, the reason given was that ghc doesn't deallocate memory, that is, the gc heap only increases. I doubt it'd be hard to fix, Even if the GHC RTS doesn't return unused heap memory to the operating system, I don't see why this would prevent you from implementing a useful web browser in Haskell. As a comparison, my Firefox process currently uses 717MB of memory. I usually restart Firefox every day to bring the memory use down to a reasonable level. The situation would probably be the same if I used a browser implemented in Haskell. Incidentally, I did implement a web browser in Haskell back in the 90s, and it worked fine :-) But that was before JavaScript and CSS, so it would take some work to make it useful on the web of today... http://www.cs.chalmers.se/~hallgren/wwwbrowser.html Thomas Hallgren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe