headers
Evan Martin | 3 Apr 2008 06:07

Re: building a helper binary with cabal

I got caught up in other things, so I'm also late to reply.

Here's the whole story now, so you don't have to reskim the archive.
My program has a helper executable that's built with gcc.  I want to
install it alongside my Haskell binary.  I can write a post-copy hook
like this:

> creplChildCopy :: Args -> CopyFlags -> PackageDescription
>                -> LocalBuildInfo -> IO ()
> creplChildCopy args flags desc buildinfo = do
>   print "copy hook"
>   let dirs = absoluteInstallDirs desc buildinfo (copyDest flags)
>   print ("copying child to ", libexecdir dirs </> creplChildName)
>   copyFileVerbose (copyVerbose flags) (creplChildPath buildinfo)
>                   (libexecdir dirs </> creplChildName)

And then run it like this:

$ ./Setup.lhs copy -v3
directory dist/doc/html/c-repl does exist: False
Creating /home/martine/.local/share/doc/c-repl-0.1 (and its parents)
copy LICENSE to /home/martine/.local/share/doc/c-repl-0.1/LICENSE
Installing: /home/martine/.local/bin
Creating /home/martine/.local/bin (and its parents)
copy dist/build/c-repl/c-repl to /home/martine/.local/bin/c-repl
"copy hook"
("copying child to ","/home/martine/.local/libexec/c-repl-child")
copy dist/build/c-repl-child to /home/martine/.local/libexec/c-repl-child
Setup.lhs: /home/martine/.local/libexec: copyFile: does not exist (No
such file or directory)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Evan Laforge | 3 Apr 2008 20:01
Picon

Data.Map.toDescList not exported?

It's in the source, marked as being O(n), but it's not in the export
list.  Oversight?  I'm using ghc-6.8.2.

I'm using (reverse.toAscList) but I think running 'head' on that is
going to be less efficient than on the real toDescList.

Thanks!
Permalink | Reply | 0 comments |
headers
gwern0 | 7 Apr 2008 17:50
Picon
Gravatar

darcs patch: fmt cabal (and 9 more)

Mon Apr  7 00:50:28 EDT 2008  gwern0 <at> gmail.com
  * fmt cabal

Mon Apr  7 00:50:49 EDT 2008  gwern0 <at> gmail.com
  * .cabal: +category

Mon Apr  7 00:53:00 EDT 2008  gwern0 <at> gmail.com
  * .cabal: change homepage and links
  The original listed website, <http://www.haskell.org/QuickCheck/>, seems to be quite dead. I've
replaced it with a link to the haskell wiki and to the old chalmers site.

Mon Apr  7 00:57:49 EDT 2008  gwern0 <at> gmail.com
  * improve README

Mon Apr  7 00:59:04 EDT 2008  gwern0 <at> gmail.com
  * .cabal: add a real description

Mon Apr  7 01:00:18 EDT 2008  gwern0 <at> gmail.com
  * .cabal: BSD4 -> BSD3 license change
  The 4-clause BSD includes the advertising clause, and is 4 clauses long. The provided LICENSE file doesn't
seem to have an advertising clause for anyone, and seems to have only 3 clauses. Which is good, as people
don't like the advertising BSD license - why it's deprecated.

Mon Apr  7 01:01:46 EDT 2008  gwern0 <at> gmail.com
  * .cabal: +Bringert to copyright
  Per the license file, which mentions two copyright holders.

Mon Apr  7 01:05:34 EDT 2008  gwern0 <at> gmail.com
  * -Wall Monadic.hs
(Continue reading)

Permalink | Reply | 0 comments |
headers
Don Stewart | 7 Apr 2008 22:24
Favicon
Gravatar

Re: [Haskell] making inits less strict

john.tromp:
> The standard definition of inits:
> 
>   inits []     =  [[]]
>   inits (x:xs) =  [[]] ++ map (x:) (inits xs)
> 
> is unnecessarily strict, evaluating its argument
> before yielding the initial [] of the result.
> An improved version is:
> 
>   inits l = [] : case l of []     -> []
>                            (x:xs) -> map (x:) inits xs
> 
>  This allows one to define for instance
>    nats = map length (inits nats)
>  which loops for the standard definition.
> 

Can you forward this to the libraries <at> haskell.org list,
and file a proposal to replace the current definition?

    http://haskell.org/haskellwiki/Library_submissions

We noticed this while implementing lazy bytestrings, which had
a similar issue, and fixing it is cheap enough.

-- Don
Permalink | Reply | 0 comments |
headers
Johan Tibell | 13 Apr 2008 13:59
Picon
Gravatar

RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)

Good day hackers,

The Python community have been successful in standardizing an
interface between web server and applications or frameworks resulting
in users having more control over their web stack by being able to
pick frameworks independently from web servers, and vice versa. I
propose we try to do the same for Haskell. I've written half a draft
for a Haskell version of Python's PEP 333 [1]. If you're interested in
taking part in this effort please read through the Python spec first
(as it is way more complete and you can understand this proposal
better by reading it, I've skipped some important issues in my first
draft) and then go read the Haskell spec [2]. I'm particularly
interesting in feedback regarding:

* Doing in this way won't work as it violates HTTP/CGI spec part X, Y
and Z (the Python spec takes lots of things from the CGI spec
including naming and semantics).
* My server/framework could never provide/be run under this interface.
* This interface has bad performance by design.
* Using a different set of data types would work better.

The spec needs to be extended to cover all the corners of HTTP. Some
parts need to be motivated better. It is easier for me to motivate
things if people would tell me what parts are badly motivated.

Note: I'm open to a complete rewrite if needed. I'm not wedded to the
current design and/or wording. In fact parts of the wording is
borrowed from the Python spec. The parts with bad grammar are all
mine.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manlio Perillo | 13 Apr 2008 16:21
Picon
Favicon

Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)

Johan Tibell ha scritto:
> Good day hackers,
> 
> The Python community have been successful in standardizing an
> interface between web server and applications or frameworks resulting
> in users having more control over their web stack by being able to
> pick frameworks independently from web servers, and vice versa. I
> propose we try to do the same for Haskell. I've written half a draft
> for a Haskell version of Python's PEP 333 [1]. If you're interested in
> taking part in this effort please read through the Python spec first
> (as it is way more complete and you can understand this proposal
> better by reading it, I've skipped some important issues in my first
> draft) and then go read the Haskell spec [2]. 

I'm very interested, thanks for the effort.

> I'm particularly
> interesting in feedback regarding:
> 
> * Doing in this way won't work as it violates HTTP/CGI spec part X, Y
> and Z (the Python spec takes lots of things from the CGI spec
> including naming and semantics).
> * My server/framework could never provide/be run under this interface.
> * This interface has bad performance by design.
> * Using a different set of data types would work better.
> 

I'm not yet an Haskell expert, however one of the great feature of WSGI 
is that the environ is a Python dictionary.
This means that the user can add new keys/values in it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brandon S. Allbery KF8NH | 13 Apr 2008 16:33
Picon
Favicon

Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)


On Apr 13, 2008, at 10:21 , Manlio Perillo wrote:
> I'm not yet an Haskell expert, however one of the great feature of  
> WSGI is that the environ is a Python dictionary.
> This means that the user can add new keys/values in it.
>
>
> I'm using this feature, in my WSGI implementation for Nginx (and in  
> a mini framework I'm writing) to store user configuration in the  
> environment, and to cache the result of the parsing of request  
> headers.
>
> I'm not sure if this make sense in Haskell.

Er, that's just a StateT and possibly a ReaderT.  I suspect a  
specific monad stack wrapping IO will end up being part of the  
interface anyway.

--

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery <at> kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery <at> ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH
Permalink | Reply | 0 comments |
headers
Adam Langley | 14 Apr 2008 01:06

Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)

On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell <johan.tibell <at> gmail.com> wrote:
>  * Using a different set of data types would work better.

Give that this is Haskell, I'd suggest more types ;)

HTTP headers aren't just strings and, at the risk of tooting my own
horn, I'll point to the Headers structure in [1]. Likewise, URLs have
lots of structure that should just be handled in one place [2]

[1] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;f=/Network/MiniHTTP/Marshal.hs
[2] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;f=/Network/MiniHTTP/URL.hs

AGL

--

-- 
Adam Langley agl <at> imperialviolet.org http://www.imperialviolet.org
Permalink | Reply | 0 comments |
headers
Daniel McAllansmith | 14 Apr 2008 03:08
Picon

Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)

On Mon, 14 Apr 2008 11:06:43 Adam Langley wrote:
> On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell <johan.tibell <at> gmail.com> 
wrote:
> >  * Using a different set of data types would work better.
>
> Give that this is Haskell, I'd suggest more types ;)
>
> HTTP headers aren't just strings and, at the risk of tooting my own
> horn, I'll point to the Headers structure in [1]. 

And it could go further.  The use of a given header is often valid only in 
certain requests or responses.  Perhaps sprinkling some phantom types or type 
classes around could represent that.

Daniel
Permalink | Reply | 0 comments |
headers
Chris Smith | 14 Apr 2008 03:32
Favicon

Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)

On Sun, 13 Apr 2008 16:06:43 -0700, Adam Langley wrote:
> On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell <johan.tibell <at> gmail.com>
> wrote:
>>  * Using a different set of data types would work better.
> 
> Give that this is Haskell, I'd suggest more types ;)
> 
> HTTP headers aren't just strings and, at the risk of tooting my own
> horn, I'll point to the Headers structure in [1].

Wait, I'm not sure I agree here.  How are headers not just strings?  By 
assuming that, are we guaranteeing that anything using this interface 
cannot respond gracefully to a client that writes malformed headers?

Another perspective: there is unnecessary variation there in how 
interfaces are represented.  If I'm looking for a header, and I know its 
name as a string, how do I look for it?  Well, apparently it's either a 
named field (if it's known to the interface) or in the "other" section 
(if not).  So I write a gigantic case analysis?  But then suppose the 
interface is updated later to include some headers that popped up 
unofficially but then are standardized in a future RFC.  (This is not too 
odd; lots of REST web services invent new headers every day, many of 
which do things that make sense outside of the particular application.)  
Does old code that handled these headers stop working, just because it 
was looking in the "other" section, but now needs to check a field 
dedicated to that header?

> Likewise, URLs have
> lots of structure that should just be handled in one place [2]
(Continue reading)

Permalink | Reply | 0 comments |

Gmane