headers
Isaac Jones | 1 May 2006 03:51

cabal-install, cabal-setup, new world order

Greetings,

I've just pushed some recent work by Alson Kemp to the cabal
repository.  Alson has integrated the cabal-get tool (by Lemmih) and
dependencies into the cabal source tree.

This brings in a bunch of unwanted dependencies, though, and we'll be
working to trim these out in order to make it a manageable size.

Another thing is that I changed cabal-get to be called cabal-install,
and removed the (never released) old version of cabal-install from the
repo.  The reason is that the role of cabal-get will expand to include
what cabal-install was meant to do.  That is, cabal-install will be
used for installing groups of inter-dependent packages, whether they
are on hackage.haskell.org or on your local machine.  It doesn't do
that yet, though; it can only install stuff from hackage.

Also, Simon pushed his cabal-setup tool.  Cabal-setup is basically
like a boilerplate Setup.lhs, but smarter.

So the Hackage toolchain will look like this:
 * Cabal is the library / package
 * cabal-setup is for building / installing one package.  It's very
   simple
 * cabal-install is for installing a group of packages.  It's pretty
   complex.

If you grab the current darcs head of cabal, you should be able to
"sudo make install" and get each of these tools.  Then copy
etc-cabal-install to /etc/cabal-install, and "cabal-install update" to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Duncan Coutts | 2 May 2006 14:37
Picon
Picon
Favicon

Cabal 1.1.4 and a new Cabal-devel mailing list

=== Cabal 1.1.4 release ===

Cabal-1.1.4, the version shipped with GHC 6.4.2 is now available to
download as a separate tarball:

http://haskell.org/cabal/download.html
http://haskell.org/cabal/release/cabal-1.1.4/cabal-1.1.4.tar.gz

Note that there was some confusion over the version number. If you got a
darcs development snapshot in the last few months it will likely have
been marked 1.1.4, however it should have been marked 1.1.5.

1.1.4 is the version shipped with GHC 6.4.2 and available as the tarball
above. The current darcs development version is 1.1.5.

We'll try to avoid such confusion in the future.

=== New Cabal-devel mailing list ===

There is also a new cabal-devel <at> haskell.org mailing list for Cabal
development discussion including patch review. This is where patches
sent via "darcs send" will end up.

We welcome anyone to join the list and help discuss ongoing Cabal
development or just to keep an eye on what's going in. Sign up here:

http://haskell.org/mailman/listinfo/cabal-devel

We'd also like to take the opportunity to invite people to get involved
in Cabal development, either new features or squashing annoying bugs.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ashley Yakeley | 2 May 2006 22:05

Re: Non-exhaustive pattern in Socket.hsc

Dominic Steinitz wrote:

> data Family
>   = AF_UNSPEC
>     | AF_UNIX
>     | AF_INET
>     | AF_INET6
>     | AF_SNA
>     | AF_DECnet
>     | AF_APPLETALK
>     | AF_ROUTE
>     | AF_X25
>     | AF_AX25
>     | AF_IPX
>         -- Imported from Network.Socket

> What is the long term plan for Network anyway?

That's a good question. C/C++ uses this address-family-based approach to 
handle different protocols, but I think Haskell would do better with a 
static approach that typed sockets by network. For instance:

   newtype IP4Address = IP4Address Word32
   newtype IP6Address = IP6Address Word128

   openTCP4 :: IP4Address -> Word16 -> IO (TCPConnection IP4Address)
     -- or use classes

etc.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Simon Marlow | 3 May 2006 10:21
Picon

Re: Non-exhaustive pattern in Socket.hsc

Dominic Steinitz wrote:
> I'm getting
> 
> [root <at> tility pcap]# ./test
> test: Socket.hsc:(1434,17)-(1523,20): Non-exhaustive patterns in case
> 
> The problem is caused because pcap_findalldevs is returning an address family 
> value of 17
> 
> #define PF_PACKET       17      /* Packet family.  */
> 
> #define AF_PACKET       PF_PACKET
> 
> and the ghc Family datatype doesn't support it :-(
> 
> data Family
>   = AF_UNSPEC
>     | AF_UNIX
>     | AF_INET
>     | AF_INET6
>     | AF_SNA
>     | AF_DECnet
>     | AF_APPLETALK
>     | AF_ROUTE
>     | AF_X25
>     | AF_AX25
>     | AF_IPX
>         -- Imported from Network.Socket

I've now fixed this, the fix will be in GHC 6.6 and future releases of
(Continue reading)

Permalink | Reply | 1 comment |
headers
Einar Karttunen | 3 May 2006 11:34
Picon
Picon
Favicon

Re: Non-exhaustive pattern in Socket.hsc

On 02.05 13:05, Ashley Yakeley wrote:
> That's a good question. C/C++ uses this address-family-based approach to 
> handle different protocols, but I think Haskell would do better with a 
> static approach that typed sockets by network. For instance:
> 
>   newtype IP4Address = IP4Address Word32
>   newtype IP6Address = IP6Address Word128
> 
>   openTCP4 :: IP4Address -> Word16 -> IO (TCPConnection IP4Address)
>     -- or use classes

This is going to be painfull for applications that want to support
multiple protocols. Why should most applications care whether
it is an IPv4 or an IPv6 address if everything just works?

Of course one can force the app to just use a specific address family,
but is that required most of the time?

- Einar Karttunen
Permalink | Reply | 2 comments |
headers
Bulat Ziganshin | 3 May 2006 12:01
Picon

Re[2]: Non-exhaustive pattern in Socket.hsc

Hello Einar,

Wednesday, May 3, 2006, 1:34:35 PM, you wrote:

> On 02.05 13:05, Ashley Yakeley wrote:
>> That's a good question. C/C++ uses this address-family-based approach to 
>> handle different protocols, but I think Haskell would do better with a 
>> static approach that typed sockets by network. For instance:
>> 
>>   newtype IP4Address = IP4Address Word32
>>   newtype IP6Address = IP6Address Word128
>> 
>>   openTCP4 :: IP4Address -> Word16 -> IO (TCPConnection IP4Address)
>>     -- or use classes

> This is going to be painfull for applications that want to support
> multiple protocols. Why should most applications care whether
> it is an IPv4 or an IPv6 address if everything just works?

type classes?

(it's universal answer, after all :) )

--

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin <at> gmail.com
Permalink | Reply | 1 comment |
headers
Tomasz Zielonka | 3 May 2006 14:39
Picon

Re: Non-exhaustive pattern in Socket.hsc

On Wed, May 03, 2006 at 02:01:46PM +0400, Bulat Ziganshin wrote:
> > On 02.05 13:05, Ashley Yakeley wrote:
> >>   openTCP4 :: IP4Address -> Word16 -> IO (TCPConnection IP4Address)
> >>     -- or use classes
> 
> > This is going to be painfull for applications that want to support
> > multiple protocols. Why should most applications care whether
> > it is an IPv4 or an IPv6 address if everything just works?
> 
> type classes?
> 
> (it's universal answer, after all :) )

How many functions would benefit from increased type-safety?
I only see getsockname and getpeername... Not much benefit for
the added burden.

For applications dealing with many simultaneous connections
on different protocols you would probably resort to an existential
wrapper that would hide the type of protocol. It would make
more sense if Haskell's support for existential types was more
standard, lightweight and straightforward.

Best regards
Tomasz
Permalink | Reply | 0 comments |
headers
Einar Karttunen | 3 May 2006 17:51
Picon
Picon
Favicon

Cabal and fps merge into base-package

Hello

How is one supposed to handle fps being merged to the base package
in a Cabal file? Clearly GHC 6.4 will need to depend on the fps
package while with GHC 6.5 such a dependency is superfluous,
and actually having fps installed will cause conflicts.

What is the right solution?

- Einar Karttunen
Permalink | Reply | 3 comments |
headers
Donald Bruce Stewart | 4 May 2006 01:51
Picon
Picon
Favicon
Gravatar

Re: Cabal and fps merge into base-package

ekarttun:
> Hello
> 
> How is one supposed to handle fps being merged to the base package
> in a Cabal file? Clearly GHC 6.4 will need to depend on the fps
> package while with GHC 6.5 such a dependency is superfluous,
> and actually having fps installed will cause conflicts.
> 
> What is the right solution?

One solution is to provide 2 .cabal files. One default one, using
whatever the default compiler needs (i.e. -package fps). And for those
on the bleeding edge, a foo.cabal.6.5 perhaps, without the fps package
dep.  These users would then have to perform one extra step to build the
package. 

I can't think of a native Cabal way to solve this though. We don't allow
__GLASGOW_HASKELL__ or such numbers inside .cabal files, or conditionals.

-- Don
Permalink | Reply | 2 comments |
headers
Bulat Ziganshin | 4 May 2006 06:43
Picon

Re[2]: Cabal and fps merge into base-package

Hello Donald,

Thursday, May 4, 2006, 3:51:53 AM, you wrote:

>> How is one supposed to handle fps being merged to the base package
>> in a Cabal file? Clearly GHC 6.4 will need to depend on the fps
>> package while with GHC 6.5 such a dependency is superfluous,
>> and actually having fps installed will cause conflicts.
>> 
> I can't think of a native Cabal way to solve this though. We don't allow
> __GLASGOW_HASKELL__ or such numbers inside .cabal files, or conditionals.

it will be great to provide such support inside Cabal, otherwise we will need
separate installation for each compiler version

--

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin <at> gmail.com
Permalink | Reply | 1 comment |

Gmane