On Fri, Sep 07, 2012 at 03:54:08PM +0100, Erik Hesselink wrote:
> Hmm, apparently I can't add labels. It's issue 1028. I don't think
> it's important to fix before migrating, but it would be nice if
> someone with privileges could label it.
The issue there is mishandling unknown repository types,
On Thu, Sep 06, 2012 at 08:52:28PM +0100, Ian Lynagh wrote:
> On Thu, Sep 06, 2012 at 08:32:38PM +0100, Duncan Coutts wrote:
> >
> > From the point of view of an existing user, they will go to the new
> > site, go to a special page, enter their username and their old
> > password and a new passwor
On Thu, Sep 06, 2012 at 06:49:36PM +0100, Matthew Gruen wrote:
> To my knowledge, It's technically possible to import the old accounts.
Why is that? I think that's worth exploring, as you'd be losing
associations between 1150 users and 24456 uploads of 4442 packages.
(Not entirely, because the ol
The User accounts page, echoing the Hackage 1 version, says "Passwords
are stored encrypted, so if you forget yours we can't recover it, but
will need to assign a new one. Just ask."
But the account registration page doesn't even ask for an email address,
so it would be difficult for administrator
On Wed, Sep 05, 2012 at 01:15:09PM +0100, Leon Smith wrote:
> I have a question for Ross Paterson, namely do you decline an account
> request, and if so, what reasons do you have for declining an account
> request?
I haven't refused any requests, but occasionally I ask for more i
On Tue, Sep 04, 2012 at 07:22:04PM +0100, Ian Lynagh wrote:
> Hackage2 will currently complain about anything that doesn't start with
> one of:
> Algebra, Codec, Control, Data, Database, Debug, Distribution,
> DotNet, Foreign, Graphics, Language, Network, Numeric, Prelude,
> Sound, Syst
On Tue, Sep 04, 2012 at 06:32:48PM +0100, Leon Smith wrote:
> Ok, when I upload a package it warns me about unallocated names? How are
> names allocated, and who makes the decisions here?
It's complaining if the first component of a hierarchical module name
doesn't come from a certain set. Th
On Mon, Sep 03, 2012 at 03:52:32PM +0100, Erik Hesselink wrote:
> On Mon, Sep 3, 2012 at 4:38 PM, Ross Paterson wrote:
> > In Hackage 1 packages can be deprecated, optionally indicating a
> > recommended replacement (the "deprecated" and "superseded by" fields
A few minor issues:
In Hackage 1 packages can be deprecated, optionally indicating a
recommended replacement (the "deprecated" and "superseded by" fields of
the per-package "tags" file), e.g. partial-lens and binary-strict-0.3.1.
These don't seem to be in Hackage 2.
Several packages lack document
On Wed, Dec 21, 2011 at 05:34:33AM +, Levent Erkok wrote:
> I'm suffering from the issue reported in here:
> http://hackage.haskell.org/trac/hackage/ticket/656. In brief, cabal
> had a bug that prevented it from running haddock successfully if a
> package contained both a library and an executa
On Wed, Apr 27, 2011 at 02:02:25PM +0100, Ian Lynagh wrote:
> On Wed, Apr 27, 2011 at 01:16:12PM +0100, Duncan Coutts wrote:
> >
> > The generated paths module has to compile with the target
> > compiler, including older ghc
>
> Why? People who really are stuck with GHC 6.8 already have a Cabal t
On Sun, Nov 21, 2010 at 04:07:32PM -0600, Antoine Latter wrote:
> The per-package overview pages on Hackage have recently received a
> makeover to match the style of Haddock 2.8. Which code generates these
> pages? I had though it was the following two modules:
>
> http://darcs.haskell.org/hackage
On Thu, Nov 18, 2010 at 07:46:33PM -0600, Antoine Latter wrote:
> The index tar-ball on Hackage has an odd naming convention. Package
> descriptions are given paths of the form:
>
> ./$pkg/$version/$pkg.cabal
>
> including the leading "./".
> I'm guessing that this is done as a method of distingu
On Tue, Jun 01, 2010 at 06:52:56PM +0100, Duncan Coutts wrote:
> Ross, next time you have a moment for hackage work, we should probably
> try building the hackage scripts using the latest Cabal HEAD.
Done.
___
cabal-devel mailing list
cabal-devel@haskel
On Sun, May 16, 2010 at 08:30:25PM +0100, Ian Lynagh wrote:
> On Sun, May 16, 2010 at 08:17:26PM +0200, Matthias Kilian wrote:
> >
> > - ++ quote path ++ concatMap (\arg -> ' ':quote arg) args ]
> > + ++ unwords (map quote $ path : args) ++ " \"$...@\""]
>
> This looks liks it oug
On Fri, Aug 28, 2009 at 09:44:53PM +0100, Duncan Coutts wrote:
> One thing I noticed when importing data into it is that there are a
> small handful of packages that have no entry in the upload log. The new
> server expects to find such an entry so that it knows when the package
> was added.
>
> R
On Tue, Jul 07, 2009 at 06:38:44PM +0100, Duncan Coutts wrote:
> I think we can do it with something like the following in a
> suitable .htaccess file:
>
> RewriteRule
> ^/package/([A-Za-z0-9-]*)-([0-9.]*)\.tar\.gz$
> /packages/archive/$1/$2/$1-$2.tar.gz
I guess it can be done, but it feels
On Tue, Jul 07, 2009 at 12:57:16PM +0100, Duncan Coutts wrote:
> Currently in the cabal-install config file we use:
> remote-repo:
> hackage.haskell.org:http://hackage.haskell.org/packages/archive
>
> and then lookup the 00-index.tar.gz and all the package tarballs
> relative to that. So if we try
On Sat, Jul 04, 2009 at 06:01:13PM +0100, Duncan Coutts wrote:
> This made me recall that one place we do still have a special case for
> the current central hackage server is when we specify the upload and
> check POST URLs. Currently hackage uses:
>
> /cgi-bin/hackage-scripts/check-pkg
> /cgi-bi
Wed Jun 10 10:46:19 PDT 2009 Ross Paterson
* use Haskell 98 import syntax
Ignore-this: 26774087968e247b41d69350c015bc30
M ./Distribution/Simple/Program/Ld.hs -1
View patch online:
http://darcs.haskell.org/cabal/_darcs/patches/20090610174619-b47d3
Wed Jun 10 10:45:41 PDT 2009 Ross Paterson
* fix typo of exitcode
Ignore-this: e21da0e6178e69694011e5286b382d72
M ./Distribution/Simple/Utils.hs -1 +1
View patch online:
http://darcs.haskell.org/cabal/_darcs/patches/20090610174541-b47d3-19c0c01be7807218636b8356f0b24acd99cb1c01.gz
On Wed, Jun 03, 2009 at 11:36:56AM +0100, Duncan Coutts wrote:
> On Tue, 2009-06-02 at 11:35 +0100, Ross Paterson wrote:
> > Would you like to send your announcement first?
>
> Sent.
OK, I've updated the scripts.
___
cabal-deve
On Tue, Jun 02, 2009 at 08:53:19PM +0100, Ian Lynagh wrote:
> I don't think the base split made much difference.
It forced the exposure of a lot more GHC.* modules, I think.
But I think my question is answered: just use base < 5 or base == 4.*
___
caba
On Tue, Jun 02, 2009 at 01:27:48PM +0100, Ian Lynagh wrote:
> The reason base's version was bumped from 4.0 to 4.1 is that there were
> some changes that required it, according to the PvP, e.g.
> GHC.Conc.signalHandlerLock
> was removed.
>
> I don't know if there were any such changes in non-G
On Tue, Jun 02, 2009 at 10:26:34AM +0100, Duncan Coutts wrote:
> I'd like to get Hackage using the new check for base being bounded
> above. I think it'll make a big difference when it comes to future
> ghc/base upgrades. The last one was papered over by cabal-install
> defaulting to base 3 when th
On Thu, May 14, 2009 at 10:52:36AM +0100, Alistair Bayley wrote:
> I've uploaded Takusen-0.8.5 to hackage, and it's visible at
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Takusen
>
> but "cabal install Takusen" still tries to get 0.8.4. Is there a
> separate database/file for ca
On Wed, Feb 25, 2009 at 01:09:38PM +, Duncan Coutts wrote:
> Generally the user guide needs some attention from
> someone. It could probably do with being divided into user and author
> sections / perspectives. People want to know how to install packages,
> all the various user interface to usi
Sat Feb 21 08:49:39 PST 2009 Ross Paterson
* fix imports for non-GHC
Ignore-this: 12756e3863e312352d5f6c69bba63b92
M ./Distribution/Compat/TempFile.hs -1 +2
View patch online:
http://darcs.haskell.org/cabal/_darcs/patches/20090221164939-b47d3-5a6afd1080fee47116151e7648d422dcca6ed9b3.gz
Fri Jan 30 07:35:05 PST 2009 Ross Paterson
* move imports outside ifdef GHC
M ./Distribution/Compat/CopyFile.hs -3 +2
View patch online:
http://darcs.haskell.org/cabal/_darcs/patches/20090130153505-b47d3-6f196a881f5c4391401affe469d660ebd3f11e19.gz
On Tue, Nov 11, 2008 at 12:12:09PM +, Malcolm Wallace wrote:
> HackageDB documentation links for the "latest" version of packages
> appears to be missing. For instance, the haskell.org wiki at
>
> http://www.haskell.org/haskellwiki/Opengl
>
> points to Haddock'ed API documentation at
>
On Sat, Nov 01, 2008 at 03:30:24PM +, Duncan Coutts wrote:
> Sat Nov 1 15:24:48 GMT 2008 Duncan Coutts <[EMAIL PROTECTED]>
> * Read the .cabal file as UTF8 when unpacking
> Currently the upload check preview displays incorrect encoding of
> peoples names and does not validate incorrect
On Thu, Oct 09, 2008 at 01:28:31PM -0700, Duncan Coutts wrote:
> What needs to happen next is that these preferences be included into the
> hackage index that cabal-install and other clients download. This should
> be completely backwards compatible. The format allows for adding other
> files with
On Tue, Oct 07, 2008 at 02:56:29PM -0700, Duncan Coutts wrote:
> Tue Oct 7 14:41:20 PDT 2008 Duncan Coutts <[EMAIL PROTECTED]>
> * Add a few type sigs to help hugs and as documentation
Thanks. I wasn't going to ask you to work around this Hugs bug (#86),
because it really ought to be fixed.
On Sun, Sep 28, 2008 at 12:27:17AM -0700, Clifford Beshers wrote:
> The stb-image package on hackage has carriage returns (^M) at the end of some
> lines. This confused hlibrary.mk from the Debian haskell-devscripts. Are
> these characters legal in a .cabal file?
They are whitespace, and so allo
On Thu, Sep 18, 2008 at 12:30:42AM +0100, Claus Reinke wrote:
> So far, I had assumed that every tool defined its own macro,
> but it seems that __GLASGOW_HASKELL__ is defined by
> ghc and by cabal, while __HADDOCK__ is defined only by
> the latter. Is that right?
Yes, Cabal defines __HADDOCK__ on
On Wed, Aug 27, 2008 at 10:54:02AM +0100, Neil Mitchell wrote:
> Just remove the package (its mine), I don't think it will build anyway
> (and I guess it probably never did :-( ).
It's now gone (as is 0.1, which had the same bug).
___
cabal-devel mailin
On Wed, Aug 27, 2008 at 03:29:48AM +0100, Duncan Coutts wrote:
> I think Cabal is right. Both 1.4 and HEAD parse hoogle.cabal without
> complaint. I suspect that the fix is to recompile the hackage scripts
> against a more recent Cabal version (ideally the latest stable 1.4.x
> release).
I've reco
On Wed, Aug 13, 2008 at 11:14:34PM +0100, Duncan Coutts wrote:
> A user noticed that gentoo's HAppS package was broken because the
> upstream .tar.gz package had disappeared. Checking the hackage archive
> it does indeed seem to have gone (except for some log files).
>
> Is this intentional or som
Sat Jul 5 03:50:48 PDT 2008 Ross Paterson <[EMAIL PROTECTED]>
* fix #if __GLASGOW_HASKELL__ test
The problem is that
#if __GLASGOW_HASKELL__ < NNN
is also true for non-GHC. It should be
#if __GLASGOW_HASKELL__ && __GLASGOW_HASKELL__ < NNN
M .
Sat Jun 14 09:07:07 PDT 2008 Ross Paterson <[EMAIL PROTECTED]>
* force results inside withHaskellFile
withUTF8FileContents now closes the file, so we need to force what we're
computing from the contents before it's gone.
M ./Distribution/Simple/Hugs.hs -2 +2
View pa
On Wed, May 14, 2008 at 10:54:00AM +0100, Duncan Coutts wrote:
> On Fri, 2008-05-09 at 19:02 +0100, Ross Paterson wrote:
> > On Fri, May 09, 2008 at 10:12:06AM +0100, Duncan Coutts wrote:
> > > I'm planning on changing the equivalent of showVersion in Cabal to not
On Fri, May 09, 2008 at 10:12:06AM +0100, Duncan Coutts wrote:
> I'm planning on changing the equivalent of showVersion in Cabal to not
> display the tags.
The hackageDB upload script rejects packages for which show of parse is
not the original string (in the .cabal file, the directory name and th
On Fri, May 09, 2008 at 10:12:06AM +0100, Duncan Coutts wrote:
> It's clear we should drop the check on the tags from the == test but I'm
> not sure if we should also change the showVersion or parseVersion
> functions.
>
> I'm planning on changing the equivalent of showVersion in Cabal to not
> di
On Thu, May 01, 2008 at 03:51:13PM +0100, Malcolm Wallace wrote:
> nhc98 has a performance hack to avoid dumping large numbers of instance
> decls into .hi interface files. For any given instance, if both the
> class and the type are defined in the Prelude, then the instance can be
> omitted from
On Thu, May 01, 2008 at 04:01:31AM -0700, Malcolm Wallace wrote:
> Thu May 1 04:00:06 PDT 2008 [EMAIL PROTECTED]
> * Revert the other `fmap` to (.)
> To avoid needing a non-H'98 instance of Functor for (->).
>
> M ./Distribution/Simple/Command.hs -1 +1
I'm puzzled as to why nhc98 lacks
On Tue, Apr 22, 2008 at 08:07:31AM -0700, Duncan Coutts wrote:
> Tue Apr 22 07:15:39 PDT 2008 Duncan Coutts <[EMAIL PROTECTED]>
> * Update UTF8 code
> Some code and test cases taken from the utf8-string package.
Can you push this to 1.4? I've been using a custom hacked version
for hackageDB
On Fri, Mar 28, 2008 at 01:53:04PM +, Duncan Coutts wrote:
> Is that patch pushed to the repo? I don't see it yet. I've got a patch to
> update
> generally to the latest Cabal api, though if you've got the utf warnings form
> the latest cabal then have you had to make all those changes already
On Thu, Mar 27, 2008 at 04:39:17PM +, Duncan Coutts wrote:
> So I think hackage should reject them with a suitable error message. I
> can send a patch. On that topic in fact, I think all parser warnings
> should be fatal errors as far as hackage is concerned.
OK, parser warnings (including UTF
Fri Mar 28 04:56:12 PDT 2008 Ross Paterson <[EMAIL PROTECTED]>
* factor out showPWarning function
M ./Distribution/PackageDescription/Parse.hs -7 +1
M ./Distribution/ParseUtils.hs -1 +6
View patch online:
http://darcs.haskell.org/cabal/_darcs/patches/20080328115612
On Thu, Mar 27, 2008 at 04:39:17PM +, Duncan Coutts wrote:
> Can't we just reject them with the error message and ask people to fix the
> latin-1 sequences and re-upload using proper UTF-8?
The problem is that there are packages there now with .cabal files
assuming Latin-1. Stopping more of t
On Thu, Mar 27, 2008 at 08:45:29AM -0700, Duncan Coutts wrote:
> Wed Mar 26 20:17:40 PDT 2008 Duncan Coutts <[EMAIL PROTECTED]>
> * Make UTF-8 decoding errors in .cabal files non-fatal
> Previously we checked for invalid UTF-8 in the first phase of the
> parser, which splitting the file up i
Wed Mar 26 09:59:12 PDT 2008 Ross Paterson <[EMAIL PROTECTED]>
* allow underscores in arch names
Stops it barfing on arch(x86_64).
M ./Distribution/System.hs -1 +2
View patch online:
http://darcs.haskell.org/cabal/_darcs/patches/20080326165912
On Tue, Mar 18, 2008 at 01:15:21PM +, Duncan Coutts wrote:
> Can someone remind me why we have the --scratchdir flag for hugs.
>
> As far as I can see all it does is specify where some temporary files go
> after being preprocessed but before being installed. The default is
> dist/scratch.
>
>
On Mon, Mar 10, 2008 at 05:23:06PM -0700, Duncan Coutts wrote:
> Mon Mar 10 12:14:22 PDT 2008 Duncan Coutts <[EMAIL PROTECTED]>
> * Use the same ReadP for all compilers, remove CPP hacks
> If we're bundling a whole copy of ReadP then why bother trying to use
> the version from the base packa
On Tue, Feb 26, 2008 at 09:30:41AM +, Duncan Coutts wrote:
> So if we use files opened in binary mode and account for line end
> differences then this is portable and doesn't make it harder for GHC to
> switch text handles to use a more sensible encoding.
Yes. We have to handle line-endings i
On Tue, Feb 26, 2008 at 12:28:56AM -0800, Don Stewart wrote:
L johan.tibell:
> > On Tue, Feb 26, 2008 at 12:09 AM, Don Stewart <[EMAIL PROTECTED]> wrote:
> > > Add System.IO.UTF8.{readFile,writeFile} to the base library?
> >
> > I'd rather see that we add a more general solution for reading and
>
On Mon, Feb 25, 2008 at 09:07:08PM +, Duncan Coutts wrote:
> It's no use pretending that readFile returns Unicode, it just doesn't
> (except on Hugs which does it properly). GHC is not going to catch up on
> this any time soon.
On the contrary, it's the only way to stay sane. readFile does re
On Sun, Feb 24, 2008 at 05:46:35PM +, Duncan Coutts wrote:
> I've added readTextFile and writeTextFile to the Utils module and
> checked all other uses of readFile and writeFile.
>
> I've also switched the rawSystemStdout to assume UTF8 output format.
The read and write functions ought to ope
On Mon, Feb 25, 2008 at 09:35:58AM +, Duncan Coutts wrote:
> On Mon, 2008-02-25 at 00:52 +0000, Ross Paterson wrote:
> > The tags stuff was just a quick hack, but in general my preference is
> > to keep the additional data outside of the package, so that what one
> &
On Sun, Feb 24, 2008 at 08:49:04PM +, Duncan Coutts wrote:
> On Sun, 2008-02-24 at 18:28 +0000, Ross Paterson wrote:
> > text/plain output (used by cabal upload) will need some work, though.
> > I'm not sure what the deal is with charset negotiation.
>
> Yeah, me nei
On Sun, Feb 24, 2008 at 05:46:35PM +, Duncan Coutts wrote:
> So what about hackage? It now has to assume the Strings in the package
> description etc are proper Haskell Unicode Strings and convert to UFT8
> output. Distribution.Simple.Utils exports toUTF8 for this purpose.
XHTML output should
On Sat, Feb 23, 2008 at 10:49:59AM -0800, Duncan Coutts wrote:
> Sat Feb 23 10:40:25 PST 2008 Duncan Coutts <[EMAIL PROTECTED]>
> * First pass at parsing .cabal files as UTF8
> Also print output and error messages etc in UTF8.
On the input side, wouldn't it be better to do this on the boundar
On Wed, Feb 20, 2008 at 05:16:22PM +0100, Henning Thielemann wrote:
> I have upgraded to Cabal 1.2 while still using GHC-6.4.1. In the Haskore
> project there is the module NewResolutions.lhs which let GHC run into
> extensive swapping (certainly due to excessive memory consumption) on
> comp
On Thu, Jan 31, 2008 at 03:41:59PM +, Duncan Coutts wrote:
> On Thu, 2008-01-31 at 14:37 +, Alistair Bayley wrote:
> > On 31/01/2008, Duncan Coutts <[EMAIL PROTECTED]> wrote:
> > OK. Ian voted for '.' as empty line, so I went with that as it was the
> > only comment, and was a positive one.
On Sun, Jan 20, 2008 at 04:39:11PM -0800, Duncan Coutts wrote:
> Thu Jan 17 14:36:10 PST 2008 Lennart Kolmodin <[EMAIL PROTECTED]>
> * Implement QA for PackageDescription
> Addresses #191 (QA) and #180 (QA for missing license).
> This patch only adds a new exposed module, it's not yet used a
Mon Jan 28 16:51:05 PST 2008 Ross Paterson <[EMAIL PROTECTED]>
* fix build for Hugs and nhc98
M ./Distribution/Compat/TempFile.hs -1 +1
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
On Tue, Jan 29, 2008 at 12:12:44AM +, Duncan Coutts wrote:
> There are 26 versions of 16 distinct packages that use build-type:
> Configure. [...] Of those 5 have no configure file:
>
> directory-1.0.0.0
> mersenne-random-0.1
> old-time-1.0.0.0
> process-1.0.0.0
> Win32-2.1.0.0
>
> So all th
On Mon, Jan 28, 2008 at 10:18:25AM -0800, Don Stewart wrote:
> Spotted that this morning. You're running the latest cabal on hackage?
Have to. People keep uploading packages that use the latest features.
It's supposed to be safe for old packages unless they have non-trivial
Setup scripts.
__
On Mon, Jan 21, 2008 at 08:38:49AM -0800, Duncan Coutts wrote:
> Mon Jan 21 08:34:11 PST 2008 Duncan Coutts <[EMAIL PROTECTED]>
> * Deprecate defaultUserHooks, export autoconfUserHooks. Fix ticket #165
> Setup scripts should switch to simpleUserHooks or autoconfUserHooks.
> autoconfUserHooks
Fri Jan 25 02:20:53 PST 2008 Ross Paterson <[EMAIL PROTECTED]>
* flush stdout before running subprograms
This is needed to separate Cabal and subprogram output if stdout is
buffered (e.g. a file), especially if stdout and stderr are the same.
M ./Distribution/Simple/Utils
On Wed, Jan 09, 2008 at 01:39:21PM +, Duncan Coutts wrote:
> I've only seen one package that actually uses tests integrated into the
> Setup.hs. So it seems everyone just runs tests manually. This is a
> fairly large hole in the Cabal story at the moment imho.
>
> Part of the problem is that w
On Fri, Nov 23, 2007 at 02:34:43AM +, Duncan Coutts wrote:
> On Fri, 2007-11-23 at 01:42 +0000, Ross Paterson wrote:
> > I guess you could indicate that a package won't build in some
> > configuration using the buildable field. Hackage ought to learn
> > to use tha
On Fri, Nov 23, 2007 at 01:05:42AM -, Claus Reinke wrote:
> how is portability (meant to be) documented in .cabal files?
> the only thing i can find in Cabal/authors.html are 'os()' and
> 'arch()', but those are tests, rather than dependency fields.
>
> should .cabal files for non-portable pac
On Tue, Oct 16, 2007 at 11:15:14PM +0100, Duncan Coutts wrote:
> Here's my suggestion:
>
> library
> build-depends: base
> if package(base >= 3)
> build-depends: pretty, directory, etc
>
> and it is syntactic sugar for:
>
> flag _unnamed1
>
> library
> build-depends: base
> if flag(
Fri Oct 26 01:41:24 PDT 2007 Ross Paterson <[EMAIL PROTECTED]>
* no longer need to pass --allow-missing-html to haddock
This option only affects Haddock if it is invoked with --use-package,
and Cabal no longer uses that option, as it now gets the arguments for
--read-interface fr
Fri Oct 26 00:31:26 PDT 2007 Ross Paterson <[EMAIL PROTECTED]>
* no longer need to pass --ghc-pkg to haddock
Haddock only runs ghc-pkg if invoked with --use-package, and Cabal no
longer uses that option, as it now gets the arguments for --read-interface
from ghc-pkg directly (cf
Thu Oct 25 17:10:45 PDT 2007 Ross Paterson <[EMAIL PROTECTED]>
* fix help text (--PROG-arg is now --PROG-option)
M ./Distribution/Simple/Setup.hs -1 +1
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/li
On Thu, Oct 25, 2007 at 02:02:22PM +0200, Thomas Schilling wrote:
> The point is, that flags like "old-base" or "bytestring-in-base" (as,
> for example, in [1]) are used solely to dispatch on the version of the
> base package. It should not be necessary for the user to invent flag
> names for such
On Thu, Oct 25, 2007 at 01:17:43PM +0200, Thomas Schilling wrote:
> I presume the final interface should be to give the user a simple way to
> query the dependenies by giving assignments for OS, arch,
> implementation, etc. and then dynamically (yes, using JavaScript)
> updating the dependency list
Dependencies between packages are obviously more complex now that we
have configurations.
The web interface now has an experimental presentation of these
dependencies transformed into disjunctive normal form, with the atoms
being simple version ranges. It lacks tests of os, arch and impl,
which w
Tue Oct 23 11:42:10 PDT 2007 Ross Paterson <[EMAIL PROTECTED]>
* pass cpp-options to cpphs
M ./Distribution/Simple/PreProcess.hs -1 +1
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Mon Oct 22 02:12:35 PDT 2007 Ross Paterson <[EMAIL PROTECTED]>
* typo in comment
M ./Cabal.cabal -1 +1
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Thu Oct 18 09:42:45 PDT 2007 Ross Paterson <[EMAIL PROTECTED]>
* don't fail if xxx_hsc_make.c is gone
The non-GHC hsc2hs deletes it even if the compilation fails.
M ./Distribution/Simple/Program.hs -1 +2
___
cabal-devel mailing
On Wed, Oct 17, 2007 at 12:54:12PM +0100, Simon Marlow wrote:
> I've written down the proposed policy for versioning here:
>
> http://haskell.org/haskellwiki/Package_versioning_policy
>
> It turned out there was a previous page written by Bulat that contained
> essentially this policy, but it wa
On Tue, Oct 16, 2007 at 01:08:49PM +0100, Simon Marlow wrote:
> So rather than keep replying to individual points, I'd like to make some
> concrete proposals so we can make progress.
>
> 1. Document the version numbering policy.
>
> We should have done this earlier, but we didn't. The proposed po
On Mon, Oct 15, 2007 at 10:10:40PM +0100, Duncan Coutts wrote:
> What do you reckon we should do? We could change:
>
> #if __GLASGOW_HASKELL__ >= 603 || __HUGS__
>
> import Text.ParserCombinators.ReadP hiding (ReadP)
> import qualified Text.ParserCombinators.ReadP as ReadP
> ...
>
> to drop t
On Mon, Sep 24, 2007 at 10:02:28PM +0100, Ian Lynagh wrote:
> On Mon, Sep 24, 2007 at 09:53:16PM +0200, Thomas Schilling wrote:
> > I'd like include this into Cabal-1.2 which is scheduled with the next
> > ghc release, so it can fearlessly be used when getting packages ready
> > for GC 6.8.1.
>
>
On Tue, Sep 18, 2007 at 10:02:52AM +0100, Ross Paterson wrote:
> Could we not just replace
>
> (deps, libfs1) = partition ((`elem` constraintFieldNames) . fName)
> libfs0
> libfs = if null libfs1 && not (null deps)
> then [F (line
On Sun, Sep 09, 2007 at 03:18:43PM +0200, Thomas Schilling wrote:
> On Sun, 2007-09-09 at 10:21 +0100, Ross Paterson wrote:
> > The build-depends field has been moved from the package level to the
> > individual library and executable components. (And the new build-tools
> >
On Fri, Sep 14, 2007 at 06:38:41PM +0100, Duncan Coutts wrote:
> In message <[EMAIL PROTECTED]> [EMAIL PROTECTED],
> cabal-devel@haskell.org writes:
> > Thanks. Now we have a conundrum: should Cabal 1.2 use the new option,
> > and thus require the latest cpphs, or stick with the old option and be
On Fri, Sep 14, 2007 at 04:39:05PM +0100, Malcolm Wallace wrote:
> > > Would you like to have separate option flags in cpphs for stripping
> > > the different kinds of C comment? e.g. --strip and --stripAnsi?
> >
> > Separate options would resuscitate the Hugs build, so yes please.
> > How about
On Sun, Sep 09, 2007 at 05:37:32PM +0200, Thomas Schilling wrote:
> Note that it does not rewrite the _external_ package description. Cabal
> now internally uses the section-based syntax, so we have to rewrite old
> flat package descriptions to the section-based format _internally_.
> I.e., the ac
On Sun, Sep 09, 2007 at 03:18:43PM +0200, Thomas Schilling wrote:
> (1) was easier at the time. (2) should be relatively easy to implement
> now, but since the current implementation works, I didn't bother so far.
> I know that (1) is a rather hackish solution, but why is it "just
> wrong"? (Afte
The build-depends field has been moved from the package level to the
individual library and executable components. (And the new build-tools
and pkgconfig-depends fields are similarly attached to components.)
I'm not sure whether this is a good idea, but more specifically I
came across this in the
On Thu, Sep 06, 2007 at 06:52:47PM +, Duncan Coutts wrote:
> Note that, at the moment hackage probably will not accept packages using
> configurations since it will not be able to parse them.
It should accept them now. But people adding new packages should specify
their dependencies properly.
On Sun, Sep 02, 2007 at 01:56:45PM +0100, Duncan Coutts wrote:
> On Sun, 2007-09-02 at 01:53 +0100, Ross Paterson wrote:
> > On Sat, Sep 01, 2007 at 05:33:26PM -0700, Duncan Coutts wrote:
> > > Sat Sep 1 17:33:34 PDT 2007 Duncan Coutts <[EMAIL PROTECTED]>
> > >
On Sat, Sep 01, 2007 at 05:33:26PM -0700, Duncan Coutts wrote:
> Sat Sep 1 17:33:34 PDT 2007 Duncan Coutts <[EMAIL PROTECTED]>
> * Change --configure-option= to --configure-arg=
> For consitency with other flags.
Also --ghc-option for build and makefile. These are used by GHC only;
I wonder
On Sat, Sep 01, 2007 at 10:32:09AM -0700, Duncan Coutts wrote:
> Sat Sep 1 10:31:47 PDT 2007 Duncan Coutts <[EMAIL PROTECTED]>
> * Pass --configure-option= options to configure in the right order
> in the same order as they were passed to cabal configure on the command line
Can we standardi
Sat Sep 1 07:09:21 PDT 2007 Ross Paterson <[EMAIL PROTECTED]>
* Maintainer is now cabal-devel@haskell.org
M ./Cabal.cabal -1 +1
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Fri Aug 31 01:24:38 PDT 2007 Ross Paterson <[EMAIL PROTECTED]>
* fix 'Make checking program versions not produce error spew' for non-GHC
M ./Distribution/Simple/Utils.hs -1 +1
___
cabal-devel mailing list
cabal-devel@
1 - 100 of 155 matches
Mail list logo
