Re: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]

2009-01-09 Thread Brandon S. Allbery KF8NH

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]

2009-01-09 Thread Tim Newsham
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]

2009-01-08 Thread John Goerzen
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]

2009-01-08 Thread Henning Thielemann


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]

2009-01-08 Thread Bardur Arantsson

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]

2009-01-08 Thread John Goerzen
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]

2009-01-08 Thread John Van Enk
> 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]

2009-01-08 Thread Bardur Arantsson

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]

2009-01-08 Thread ChrisK

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]

2009-01-08 Thread Thomas Hallgren

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