Cale Gibbard | 1 Jan 01:35 2010
Picon

nubBy, groupBy specification

Hello,

I've recently been irritated with (what I consider to be) broken
versions of nubBy in GHC 6.10.4 and 6.12.1. For a while, groupBy was
broken in the same way, but it seems to be fixed at least in 6.10.4.

The problem is roughly caused by nubBy being specified only for
symmetric relations, where this is actually a rather silly constraint,
given that it captures a very common pattern of sieving (that at least
I'd personally not want to have to write recursively every time).

My most common usage of nubBy is actually probably nubBy (>=), (which
has to be changed to nubBy (<=) for recent GHCs), and variations on
it. This is extremely useful as a kind of lazier approximation of
maximum or minimum. I occasionally use nubBy with equivalence
relations (after these, I'd say (==) `on` foo is probably my next most
common use case), but it's surprising how often that's actually not
quite the right thing. Of course, there's also the inefficient but
pretty example of constructing the list of primes using the
divisibility relation and nubBy, which getting this wrong also breaks.

What do people think of the following spec?

nubBy f xs produces a subsequence ys of xs which satisfies:
1) f x y is False whenever x occurs before y in ys.
2) ys is maximal with respect to containment subject to condition 1.
3) The sequence of indices of selected elements is lexicographically
minimal subject to conditions 1 and 2. (That is, the selections are
made greedily.)

(Continue reading)

Jeremy Shaw | 1 Jan 18:16 2010

Re: ANN: Happstack 0.4.1

Hello Simon,

I have seen several manifestations of this issue now. I filed a report  
here:

http://hackage.haskell.org/trac/ghc/ticket/3799

- jeremy

On Dec 30, 2009, at 5:37 AM, Simon Marlow wrote:

> On 22/12/09 03:33, Antoine Latter wrote:
>> On Mon, Dec 21, 2009 at 6:31 AM,<jeremy <at> n-heptane.com>  wrote:
>>> Hello,
>>>
>>> That sort of missing symbol error at link time is often (but not  
>>> always) a
>>> sign that some libraries got recompiled but not others. So there are
>>> references to the old symbol names hanging around.
>>>
>>> I would try to ghc-pkg unregister syb-with-class and everything  
>>> that depends
>>> on it, and then try cabal install happstack again.
>>>
>>
>> I'm pretty well stumped at this point. I've cleared off everything  
>> and
>> gone up to GHC 6.12 HEAD, and a 'cabal install happstack-data' gives
>> me the same symbol not defined error in Happstack.Data.Xml.Base.
>>
(Continue reading)

Evan Martin | 2 Jan 07:08 2010

X11 missing source repo(?)

I'd like to make a patch for the X11 package.

I found http://hackage.haskell.org/package/X11 , which references
http://code.haskell.org/X11/ , which appears to be empty.  Did
something go wrong?

If it helps any, the change is trivial (just want to get at the Visual
pointer from another package, much in the way Display and Screen are
exposed).
I'd be happy to make a Darcs format patch if you'd prefer that.

diff -ur X11-1.5.0.0/Graphics/X11/Xlib/Types.hsc
myX11/Graphics/X11/Xlib/Types.hsc
--- X11-1.5.0.0/Graphics/X11/Xlib/Types.hsc	2009-12-15 16:40:09.000000000 -0800
+++ myX11/Graphics/X11/Xlib/Types.hsc	2010-01-01 21:56:24.285089794 -0800
 <at>  <at>  -15,7 +15,7  <at>  <at> 

 -- #hide
 module Graphics.X11.Xlib.Types(
-        Display(..), Screen(..), Visual, GC, GCValues, SetWindowAttributes,
+        Display(..), Screen(..), Visual(..), GC, GCValues, SetWindowAttributes,
         Image(..), Point(..), Rectangle(..), Arc(..), Segment(..), Color(..),
         Pixel, Position, Dimension, Angle, ScreenNumber, Buffer
         ) where
Gwern Branwen | 2 Jan 14:32 2010
Picon

Re: X11 missing source repo(?)

On Sat, Jan 2, 2010 at 1:08 AM, Evan Martin <martine <at> danga.com> wrote:
> I'd like to make a patch for the X11 package.
>
> I found http://hackage.haskell.org/package/X11 , which references
> http://code.haskell.org/X11/ , which appears to be empty.  Did
> something go wrong?
>
> If it helps any, the change is trivial (just want to get at the Visual
> pointer from another package, much in the way Display and Screen are
> exposed).
> I'd be happy to make a Darcs format patch if you'd prefer that.

The old repo is at *darcs*.haskell.org; it's apparently being moved to
c.h.o (so as to be able to give more people the commit-bit), but
hasn't yet been actually moved.

--

-- 
gwern
Evan Martin | 2 Jan 17:30 2010

Re: X11 missing source repo(?)

On Sat, Jan 2, 2010 at 5:32 AM, Gwern Branwen <gwern0 <at> gmail.com> wrote:
> On Sat, Jan 2, 2010 at 1:08 AM, Evan Martin <martine <at> danga.com> wrote:
>> I'd like to make a patch for the X11 package.
>>
>> I found http://hackage.haskell.org/package/X11 , which references
>> http://code.haskell.org/X11/ , which appears to be empty.  Did
>> something go wrong?
>>
>> If it helps any, the change is trivial (just want to get at the Visual
>> pointer from another package, much in the way Display and Screen are
>> exposed).
>> I'd be happy to make a Darcs format patch if you'd prefer that.
>
> The old repo is at *darcs*.haskell.org; it's apparently being moved to
> c.h.o (so as to be able to give more people the commit-bit), but
> hasn't yet been actually moved.

Thanks.  Same patch now attached.

Having written this, what would probably be even cleaner is to have
 - Graphics.X11.Xlib.Types expose abstract Display, Visual etc and
their typeclass instances
 - an extra Graphics.X11.Xlib.Internals that provides functions to go
from Display -> Ptr Display, etc

However, this would be both a non-backwards-compatible change
(currently Display is exposed as a newtype) and I lack the Haskell-fu
to write such a change (like, the newtype would need to go into
.Internals but then the deriving declaration should be in .Types?).
(Continue reading)

Chris Casinghino | 2 Jan 22:54 2010
Picon

cabal sdist doesn't include c headers

Hi all,

I have a cabal package which includes some C code.  In the library
description I have the two fields:

  include-dirs:      contrib/libpuz/include
  includes:          contrib/libpuz/include/puz.h

But the file contrib/libpuz/include/puz.h is missing from the tarball
generated by running "cabal sdist".  There are C sources (mentioned
using a "c-sources" line) which depend on this header.

I'm not sure if this is a bug or the desired behavior.  What is the
recommended way to get this file into the sdist tarball?  For now,
I've added the header to the "extra-source-files" field.  This works
fine.

cabal --version reports:

cabal-install version 0.6.2
using version 1.6.0.3 of the Cabal library

Thanks for your help!

--Chris Casinghino
Gwern Branwen | 2 Jan 23:29 2010
Picon

Re: cabal sdist doesn't include c headers

On Sat, Jan 2, 2010 at 4:54 PM, Chris Casinghino
<chris.casinghino <at> gmail.com> wrote:
> Hi all,
>
> I have a cabal package which includes some C code.  In the library
> description I have the two fields:
>
>  include-dirs:      contrib/libpuz/include
>  includes:          contrib/libpuz/include/puz.h
>
> But the file contrib/libpuz/include/puz.h is missing from the tarball
> generated by running "cabal sdist".  There are C sources (mentioned
> using a "c-sources" line) which depend on this header.
>
> I'm not sure if this is a bug or the desired behavior.  What is the
> recommended way to get this file into the sdist tarball?  For now,
> I've added the header to the "extra-source-files" field.  This works
> fine.
>
> cabal --version reports:
>
> cabal-install version 0.6.2
> using version 1.6.0.3 of the Cabal library
>
> Thanks for your help!
>
> --Chris Casinghino

Perhaps http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.html#pkg-descr
helps?
(Continue reading)

Chris Casinghino | 2 Jan 23:40 2010
Picon

Re: cabal sdist doesn't include c headers

Hi Gwern,

Thanks for the reply.  I did see this field in the documentation, but
I don't want the header file to be installed on the user's computer -
it's only for internal use.  I need it to show up in the sdist tarball
because it's used for building the package.

--Chris Casinghino

On Sat, Jan 2, 2010 at 5:29 PM, Gwern Branwen <gwern0 <at> gmail.com> wrote:
> On Sat, Jan 2, 2010 at 4:54 PM, Chris Casinghino
> <chris.casinghino <at> gmail.com> wrote:
>> Hi all,
>>
>> I have a cabal package which includes some C code.  In the library
>> description I have the two fields:
>>
>>  include-dirs:      contrib/libpuz/include
>>  includes:          contrib/libpuz/include/puz.h
>>
>> But the file contrib/libpuz/include/puz.h is missing from the tarball
>> generated by running "cabal sdist".  There are C sources (mentioned
>> using a "c-sources" line) which depend on this header.
>>
>> I'm not sure if this is a bug or the desired behavior.  What is the
>> recommended way to get this file into the sdist tarball?  For now,
>> I've added the header to the "extra-source-files" field.  This works
>> fine.
>>
>> cabal --version reports:
(Continue reading)

Cale Gibbard | 3 Jan 01:03 2010
Picon

Re: nubBy, groupBy specification

2010/1/2  <a.biurvOir4 <at> asuhan.com>:
> I'm inclined to agree with you. Could you please post the sources to both nubBy
> and groupBy to see what has changed?
>
> Thanks,
> Kim-Ee
> yeoh <at> cs.wisc.edu

Sure thing,

Here is the report's implementation of nubBy:

-------------------
  nubBy            :: (a -> a -> Bool) -> [a] -> [a]
  nubBy eq []      =  []
  nubBy eq (x:xs)  =  x : nubBy eq (filter (\y -> not (eq x y)) xs)
-------------------

And here is the implementation in GHC 6.10.4 and GHC 6.12.1:

-------------------
nubBy eq l              = nubBy' l []
  where
    nubBy' [] _         = []
    nubBy' (y:ys) xs
       | elem_by eq y xs = nubBy' ys xs
       | otherwise       = y : nubBy' ys (y:xs)

-- Not exported:
-- Note that we keep the call to `eq` with arguments in the
(Continue reading)

Sebastian Fischer | 3 Jan 03:07 2010
Picon

Re: nubBy, groupBy specification


On Jan 3, 2010, at 1:03 AM, Cale Gibbard wrote:

>    nubBy' (y:ys) xs
>       | elem_by eq y xs = nubBy' ys xs

I wonder why the author of this code did not use "any (eq y)" instead  
of "elem_by eq y" as "elem_by" is not exported anyway. Does "elem_by"  
compile to more efficient code?

The version with "any" could be "fixed" (made equivalent to the report  
version) easily by using "any (`eq` y)".

The comment on "elem_by" gives me the impression that the semantics of  
"nubBy" was changed by accident in the new version and I agree that it  
should be fixed.

Or maybe the semantics was changed on purpose in order to annoy people  
that ignore the precondition that Cale proposes to relax (;

+1 for the relaxation.

Cheers,
Sebastian

--

-- 
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)

Gmane