headers
Andriy Palamarchuk | 1 Mar 2008 04:36
Picon
Favicon

Re: Data.Map, Data.IntMap documentation (1611)

Could somebody please commit the patch attached to
this ticket?
Sorry about a long delay before I finalized the patch.
Thanks,
Andriy

--- Andriy Palamarchuk <apa3a <at> yahoo.com> wrote:

> Thanks everybody for the corrections and
> suggestions. 
> Finally I got back to this work.
> Sorry it took this long to respond.
> 
> Log comment:
> Improved, fixed documentation for Data.Map,
> Data.IntMap. Added examples.
> 
> Changes since the first submission:
> * Moved time complexity Big-O values back to the
> beginning of function descriptions.
> * Converted examples from interpreter session-like
> format to more compact equation-like format.
> * As per
>
http://www.haskell.org/pipermail/libraries/2007-March/007304.html
> added following information to the description of
> updateLookupWithKey:
> 
>    The function returns changed value, if it is
> updated.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Evan Martin | 1 Mar 2008 09:02

building a helper binary with cabal

[resent after subscribing to the list]

I'm working on a package that requires building a helper binary as
part of its install process.  This binary is written in C (with good
reason), and on a Debian system would be installed into a path like
/usr/lib/myproject/mybinary, because it's only used internally by the
main program binary.

My setup is up to this point:

> gccProgram :: Program
> gccProgram = simpleProgram "gcc"

> type BuildHook = PackageDescription -> LocalBuildInfo
>                -> UserHooks -> BuildFlags -> IO ()
> creplChildBuild :: BuildHook -> BuildHook
> creplChildBuild oldhook desc buildinfo hooks flags = do
>   oldhook desc buildinfo hooks flags
>   rawSystemProgramConf (buildVerbose flags) gccProgram (buildPrograms flags)
>       ["child.c", "-o", buildDir buildinfo </> "child", "-ldl"]

> buildHooks = simpleUserHooks {
>   hookedPrograms = [gccProgram],
>   buildHook = creplChildBuild (buildHook simpleUserHooks)
> }

> main = defaultMainWithHooks buildHooks

However, it's unclear to me how to set up the install rule that would
copy that binary into the appropriate place.
(Continue reading)

Permalink | Reply | 502 comments |
headers
Felix Martini | 1 Mar 2008 10:39
Picon

Re: every use of BSD4 on hackage is incorrect

Right now i cannot see a reason why the cabal license field is an
enumeration instead of a string. The purpose seems to be to direct
people to preferred licenses of the Haskell community. If so this is
the wrong approach imo. A good explanation of licensing on the
haskell.org wiki is better. Btw. the Haddock headers in the GHC source
code also use custom strings for the license field.

Felix
Permalink | Reply | 0 comments |
headers
Duncan Coutts | 1 Mar 2008 11:29
Picon
Picon
Favicon

Re: every use of BSD4 on hackage is incorrect


On Sat, 2008-03-01 at 10:39 +0100, Felix Martini wrote:
> Right now i cannot see a reason why the cabal license field is an
> enumeration instead of a string. The purpose seems to be to direct
> people to preferred licenses of the Haskell community. If so this is
> the wrong approach imo.

It's not clear that that is the intention. This has been in the spec and
the design since the very beginning. You'd have to ask someone who
helped with the original spec to be sure of the intention.

http://haskell.org/cabal/release/old/users-guide-0.1/x29.html#pkg-descr
http://haskell.org/cabal/release/cabal-1.0/doc/pkg-spec-html/

It has always allowed for using any license. I suspect the intention was
for convenience and to provide some consistency for common licenses, eg
so we don't get packages specifying "gpl", "gpl2" "gpl-2" "GPL" and we
have to wonder if those are all the same. In the common case it gives
machine recognisable information.

Duncan
Permalink | Reply | 0 comments |
headers
Duncan Coutts | 1 Mar 2008 12:21
Picon
Picon
Favicon

Re: building a helper binary with cabal


On Sat, 2008-03-01 at 00:02 -0800, Evan Martin wrote:
> [resent after subscribing to the list]
> 
> I'm working on a package that requires building a helper binary as
> part of its install process. 

I presume you mean a private binary that's needed at runtime, rather
than a program like a code-gen needed at build time but not installed.

Cabal does not have any direct support for private binaries, so you'll
have to use a custom Setup.hs.

Perhaps it should, if you can describe what you think is needed in
general, file a feature request here:
http://hackage.haskell.org/trac/hackage/

> This binary is written in C (with good
> reason), and on a Debian system would be installed into a path like
> /usr/lib/myproject/mybinary, because it's only used internally by the
> main program binary.

Cabal knows about the 'libexec' path which sounds like it might be what
you want, though that doesn't include any package subdir (though perhaps
it should - it is currently unused). Alternatively just install into the
'libdir' which does include the package subdir.

let dirs = absoluteInstallDirs pkg_descr lbi copydest
copyFileVerbose verbosity file (libdir dirs </> file)
(Continue reading)

Permalink | Reply | 502 comments |
headers
Evan Martin | 1 Mar 2008 18:17

Re: building a helper binary with cabal

On Sat, Mar 1, 2008 at 3:21 AM, Duncan Coutts
<duncan.coutts <at> worc.ox.ac.uk> wrote:
>  I presume you mean a private binary that's needed at runtime, rather
>  than a program like a code-gen needed at build time but not installed.

That's right.

>  Cabal does not have any direct support for private binaries, so you'll
>  have to use a custom Setup.hs.
>
>  Perhaps it should, if you can describe what you think is needed in
>  general, file a feature request here:
>  http://hackage.haskell.org/trac/hackage/

I can't think of many scenarios where they'd really be needed.  The
two instances I've seen are:
1) to write a simplified (commands via stdin, output via stdout)
interface to an API that I don't want to link in (or don't want to
write bindings for)
2) this particular program, which would be written in Haskell except
that it does some C libdl tricks

>  Cabal knows about the 'libexec' path which sounds like it might be what
>  you want, though that doesn't include any package subdir (though perhaps
>  it should - it is currently unused). Alternatively just install into the
>  'libdir' which does include the package subdir.
>
>  let dirs = absoluteInstallDirs pkg_descr lbi copydest
>  copyFileVerbose verbosity file (libdir dirs </> file)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Evan Martin | 1 Mar 2008 18:40

Re: building a helper binary with cabal

On Sat, Mar 1, 2008 at 9:17 AM, Evan Martin <martine <at> danga.com> wrote:
>  >  let dirs = absoluteInstallDirs pkg_descr lbi copydest
>  >  copyFileVerbose verbosity file (libdir dirs </> file)
>
>  Thanks, this is very helpful!
>  absoluteInstallDirs takes a few more args, so here's a longer example
>  for the mailing list archives.  I'm 98% of the way there, just need to
>  figure out copyDest.

I see now that there are two different absoluteInstallDirs and you
were referring to the other one.  It's much simpler now.  Though my
confusion about CopyDest remains...
(Is there a way to search Hoogle for "functions returning CopyDest"?)
Permalink | Reply | 5 comments |
headers
Bjorn Bringert | 1 Mar 2008 23:05
Gravatar

Re: every use of BSD4 on hackage is incorrect

On Fri, Feb 29, 2008 at 11:11 PM, Duncan Coutts
<duncan.coutts <at> worc.ox.ac.uk> wrote:
> The following hackage packages specify in their .cabal file:
>
>  license: BSD4
>
>  Which is the 4-clause BSD license, ie the one with the advertising
>  clause.
>
>  cabal-upload-0.3
>  Chart-0.5
>  FiniteMap-0.1
>  haxr-3000.0.1
>  haxr-th-1.0
>  hbeat-0.1
>  htar-0.1
>  pcap-0.4.2
>  tar-0.1.1.1
>  unix-compat-0.1.2.1
>
>  Inspecting the LICENSE files for every one of these packages reveals
>  that they actually use the 3-clause BSD license. Not a single hackage
>  package really uses the 4-clause BSD license. In every case that it has
>  been used it was just a confusion.
>
>  We therefore propose to deprecate BSD4 as a valid license in .cabal
>  files:
>  http://hackage.haskell.org/trac/hackage/ticket/205
>
>  In the unlikely case that anyone really wants to use the 4-clause BSD
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matti Niemenmaa | 2 Mar 2008 16:38
Picon
Picon
Favicon

Proposal: Add an instance for IArray (IOToDiffArray IOUArray) Bool (Trac #2133)

An instance for 'IArray (IOToDiffArray IOUArray) Bool' is missing from 
Data.Array.Diff. There doesn't seem to be any good reason for this: all the 
other 'IArray UArray a' instances defined in Data.Array.IArray have 
corresponding instances. Bool is the sole exception.

They cannot be added in user code without copying the entire Data.Array.Diff 
source, since the instances require internal functions which aren't exposed.

Since all the instances are defined in exactly the same way, only varying the 
second type parameter, this requires practically zero work: just copy any of the 
other instances and replace the type parameter with Bool. A Show instance should 
also be provided. Both are in the patch (attached to the ticket).

To be sure that the instances haven't been omitted because they don't work, I 
wrote a few QuickCheck properties (attached to the ticket) and it seems that it 
does work without any trouble.

Suggested deadline for discussion: 17th March 2008.
Permalink | Reply | 1 comment |
headers
Matti Niemenmaa | 2 Mar 2008 16:48
Picon
Picon
Favicon

Re: Proposal: Add an instance for IArray (IOToDiffArray IOUArray) Bool (Trac #2133)

Matti Niemenmaa wrote:
> Suggested deadline for discussion: 17th March 2008.

And the Ticket link (I had to forget something): 
http://hackage.haskell.org/trac/ghc/ticket/2133
Permalink | Reply | 0 comments |

Gmane