headers
Jeremy Shaw | 1 Jan 2010 18:16
Gravatar

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)

Permalink | Reply | 2 comments |
headers
Evan Martin | 2 Jan 2010 07:08

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
Permalink | Reply | 4 comments |
headers
Gwern Branwen | 2 Jan 2010 14:32
Picon
Gravatar

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
Permalink | Reply | 3 comments |
headers
Evan Martin | 2 Jan 2010 17:30

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)

Permalink | Reply | 2 comments |
headers
Chris Casinghino | 2 Jan 2010 22:54
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
Permalink | Reply | 2 comments |
headers
Gwern Branwen | 2 Jan 2010 23:29
Picon
Gravatar

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)

Permalink | Reply | 1 comment |
headers
Chris Casinghino | 2 Jan 2010 23:40
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)

Permalink | Reply | 0 comments |
headers
Cale Gibbard | 3 Jan 2010 01:03
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)

Permalink | Reply | 1 comment |
headers
Sebastian Fischer | 3 Jan 2010 03:07
Picon
Gravatar

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.)
Permalink | Reply | 0 comments |
headers
Chris Casinghino | 3 Jan 2010 18:14
Picon

cabal install c2hs problem

Hi all,

This looks like a cabal bug and the folks on the c2hs list haven't
responded, so hopefully this is the right place to ask.

I ran "cabal install c2hs", which seemed to conclude succesfully.
However, then running "cabal list c2hs" shows c2hs as "Not installed".
I have observed this behavior on both linux and windows.

On linux, despite the fact that cabal reports c2hs is not installed,
packages which depend on it install fine.

On windows xp, in what may or may not be a related error, cabal
installing packages which depend on c2hs causes the error:

"c2hs.exe: does not exist"

I believe I am running the latest version of cabal on both linux and
windows.

Thanks in advance for your help.

--Chris Casinghino
Permalink | Reply | 2 comments |

Gmane