From spam at scientician.net  Mon Nov  9 04:29:48 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Mon, 9 Nov 2015 05:29:48 +0100
Subject: Anybody using the "top-down" solver?
Message-ID: <n1p7fs$pku$1@ger.gmane.org>

Hi all,

Just to get input from as many people as possible: I was pondering a
plan for modularizing the solver[1] and wanted to reach as many people
as possible with my question:

   Is anybody is still using the top-down solver?

Please respond to this list if you are, especially if you're doing so
because there's no other way to get the modular solver to do what you
want. (Obviously, I'm not promising to fix any problems you may have
with the modular solver, but it would be valuable information since it
could affect the decision of whether we have to keep the top-down solver
around.)

Regards,

--
[1] https://github.com/haskell/cabal/pull/2768#issuecomment-154917165


From ky3 at atamo.com  Mon Nov  9 04:57:53 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Mon, 9 Nov 2015 11:57:53 +0700
Subject: Anybody using the "top-down" solver?
In-Reply-To: <n1p7fs$pku$1@ger.gmane.org>
References: <n1p7fs$pku$1@ger.gmane.org>
Message-ID: <CAPY+ZdRrpk_7XPun6WrD=WB4curc9QpBDs6JiRa55CNSr+6fTA@mail.gmail.com>

On Mon, Nov 9, 2015 at 11:29 AM, Bardur Arantsson <spam at scientician.net>
wrote:

> Just to get input from as many people as possible: I was pondering a
> plan for modularizing the solver[1] and wanted to reach as many people
> as possible with my question:
>
>    Is anybody is still using the top-down solver?
>

Cabal-devel isn't the best place for such a question is it?

Lots of folks might be using cabal in unique ways. But they simply can't be
expected to subscribe to each and every dev mailing list of each and every
software they use.

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20151109/af42dfe0/attachment.html>

From spam at scientician.net  Mon Nov  9 05:07:57 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Mon, 9 Nov 2015 06:07:57 +0100
Subject: Anybody using the "top-down" solver?
In-Reply-To: <CAPY+ZdRrpk_7XPun6WrD=WB4curc9QpBDs6JiRa55CNSr+6fTA@mail.gmail.com>
References: <n1p7fs$pku$1@ger.gmane.org>
 <CAPY+ZdRrpk_7XPun6WrD=WB4curc9QpBDs6JiRa55CNSr+6fTA@mail.gmail.com>
Message-ID: <n1p9nd$lmu$1@ger.gmane.org>

On 11/09/2015 05:57 AM, Kim-Ee Yeoh wrote:
> On Mon, Nov 9, 2015 at 11:29 AM, Bardur Arantsson <spam at scientician.net>
> wrote:
> 
>> Just to get input from as many people as possible: I was pondering a
>> plan for modularizing the solver[1] and wanted to reach as many people
>> as possible with my question:
>>
>>    Is anybody is still using the top-down solver?
>>
> 
> Cabal-devel isn't the best place for such a question is it?
> 
> Lots of folks might be using cabal in unique ways. But they simply can't be
> expected to subscribe to each and every dev mailing list of each and every
> software they use.
> 
>

It's *a* place.

If you have any suggestions for other places, I'd be happy to hear it :).

Regards,


From spam at scientician.net  Mon Nov  9 05:20:36 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Mon, 9 Nov 2015 06:20:36 +0100
Subject: Anybody using the "top-down" solver?
In-Reply-To: <CAPY+ZdRrpk_7XPun6WrD=WB4curc9QpBDs6JiRa55CNSr+6fTA@mail.gmail.com>
References: <n1p7fs$pku$1@ger.gmane.org>
 <CAPY+ZdRrpk_7XPun6WrD=WB4curc9QpBDs6JiRa55CNSr+6fTA@mail.gmail.com>
Message-ID: <n1paf4$tko$2@ger.gmane.org>

On 11/09/2015 05:57 AM, Kim-Ee Yeoh wrote:
> On Mon, Nov 9, 2015 at 11:29 AM, Bardur Arantsson <spam at scientician.net>
> wrote:
> 
>> Just to get input from as many people as possible: I was pondering a
>> plan for modularizing the solver[1] and wanted to reach as many people
>> as possible with my question:
>>
>>    Is anybody is still using the top-down solver?
>>
> 
> Cabal-devel isn't the best place for such a question is it?
> 
> Lots of folks might be using cabal in unique ways. But they simply can't be
> expected to subscribe to each and every dev mailing list of each and every
> software they use.
> 
> 

Alright, I've at least "cross-posted" to -cafe. I don't really do reddit
and such, so if you (or anybody else for that matter) could also post a
link to my original post there, I'd appreciate it.

Regards,



From oleg.grenrus at iki.fi  Mon Nov  9 05:43:59 2015
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Mon, 9 Nov 2015 07:43:59 +0200
Subject: Anybody using the "top-down" solver?
In-Reply-To: <n1p7fs$pku$1@ger.gmane.org>
References: <n1p7fs$pku$1@ger.gmane.org>
Message-ID: <A0BC7DEC-E29F-4FB5-B84A-29CE3600B60F@iki.fi>

I doubt this list has good coverage. You probably should try haskell-cafe?

Another way to put this question:

  Is anybody is still using GHC 6.x?

Cheers,
Oleg

> On 09 Nov 2015, at 06:29, Bardur Arantsson <spam at scientician.net> wrote:
> 
> Hi all,
> 
> Just to get input from as many people as possible: I was pondering a
> plan for modularizing the solver[1] and wanted to reach as many people
> as possible with my question:
> 
>   Is anybody is still using the top-down solver?
> 
> Please respond to this list if you are, especially if you're doing so
> because there's no other way to get the modular solver to do what you
> want. (Obviously, I'm not promising to fix any problems you may have
> with the modular solver, but it would be valuable information since it
> could affect the decision of whether we have to keep the top-down solver
> around.)
> 
> Regards,
> 
> --
> [1] https://github.com/haskell/cabal/pull/2768#issuecomment-154917165
> 
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20151109/a1f3c8fa/attachment.sig>

From mietek at bak.io  Tue Nov 10 05:33:20 2015
From: mietek at bak.io (=?utf-8?Q?Mi=C3=ABtek_Bak?=)
Date: Tue, 10 Nov 2015 05:33:20 +0000
Subject: ANN: cabal-install-1.22.6.0 has been released
In-Reply-To: <64E078D3-786C-4613-B726-24CFDF6D143D@bak.io>
References: <CAJCpNroaMEwSgcn5bKHySZKYbAP2GTo3-UkOcEGD9PCJ8HBjzw@mail.gmail.com>
 <64E078D3-786C-4613-B726-24CFDF6D143D@bak.io>
Message-ID: <4DECA8DB-C4CE-4CDD-8E1C-C3059A1EBD55@bak.io>

Dear Ryan,

The Cabal download page hasn?t been updated for a while.
https://www.haskell.org/cabal/download.html

I think it?d make sense to remove the exhaustive list of platforms supported by Halcyon from this page, and make the links to official Cabal binaries more prominent.

If any mention of Halcyon should be kept on the page at all, perhaps it could be a short note at the very end of the cabal-install section, saying something to the effect of ?cabal-install can also be installed with Halcyon?.

Regards,

-- 
Mi?tek
https://mietek.io




> On 2015-06-18, at 01:32, Mi?tek Bak <mietek at bak.io> wrote:
> 
> Thanks.  cabal-install 1.22.6.0 (and 1.22.5.0) can now be installed with Halcyon:
> 
>       halcyon install --cabal-version=1.22.6.0
> 
> Supported platforms include:
> 
> - Amazon Linux 2014.09
> - Arch Linux
> - CentOS 6, 7
> - Debian 6, 7, 8
> - Gentoo Linux
> - openSUSE 13.2
> - OS X 10.8, 10.9, 10.10
> - Red Hat Enterprise Linux 6, 7
> - Slackware 14.1
> - SUSE Linux Enterprise Server 12
> - Ubuntu 12.04 LTS, 14.04 LTS, 14.10, 15.04
> - Fedora 20, 21
> 
> 
> -- 
> Mi?tek
> https://mietek.io
> 
> 
> 
> 
> On 2015-06-17, at 09:21, Ryan Thomas <ryan at ryant.org> wrote:
> 
>> Hi all,
>> 
>> A new minor release of cabal-install has been released, this is to
>> pick up a fix for @ezyang's fix for #2502.
>> 
>> This is now available on hackage and the downloads page and the
>> sha1sum is listed below.
>> 
>> Cheers,
>> 
>> ryan
>> 
>> 
>> d474b0eef6944af1abef92419cea13cee50993f3 cabal-install-1.22.6.0.tar.gz
>> _______________________________________________
>> cabal-devel mailing list
>> cabal-devel at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20151110/fc845108/attachment.bin>

From gershomb at gmail.com  Tue Nov 10 05:37:37 2015
From: gershomb at gmail.com (Gershom B)
Date: Tue, 10 Nov 2015 00:37:37 -0500
Subject: ANN: cabal-install-1.22.6.0 has been released
In-Reply-To: <4DECA8DB-C4CE-4CDD-8E1C-C3059A1EBD55@bak.io>
References: <CAJCpNroaMEwSgcn5bKHySZKYbAP2GTo3-UkOcEGD9PCJ8HBjzw@mail.gmail.com>
 <64E078D3-786C-4613-B726-24CFDF6D143D@bak.io>
 <4DECA8DB-C4CE-4CDD-8E1C-C3059A1EBD55@bak.io>
Message-ID: <etPan.564182de.39878788.145@mbp.local>

Well, it?s worse than that. The recent releases haven?t come with any official binaries at all. So if we wanted to make the official Cabal binaries more prominent (good idea) then we should actually generate and link to those binaries (which takes work).

This relates to the discussion I?ve been kicking off about getting some unified and shared build infrastructure so we can crank those binaries out with less work.

Until that point though, we should maybe raid halcyon?s builds to actually provide some binaries for the latest releases :-)

?gershom


On November 10, 2015 at 12:33:24 AM, Mi?tek Bak (mietek at bak.io) wrote:
> Dear Ryan,
>  
> The Cabal download page hasn?t been updated for a while.
> https://www.haskell.org/cabal/download.html
>  
> I think it?d make sense to remove the exhaustive list of platforms supported by Halcyon  
> from this page, and make the links to official Cabal binaries more prominent.
>  
> If any mention of Halcyon should be kept on the page at all, perhaps it could be a short note  
> at the very end of the cabal-install section, saying something to the effect of ?cabal-install  
> can also be installed with Halcyon?.
>  
> Regards,
>  
> --
> Mi?tek
> https://mietek.io
>  
>  
>  
>  
> > On 2015-06-18, at 01:32, Mi?tek Bak wrote:
> >
> > Thanks. cabal-install 1.22.6.0 (and 1.22.5.0) can now be installed with Halcyon:  
> >
> > halcyon install --cabal-version=1.22.6.0
> >
> > Supported platforms include:
> >
> > - Amazon Linux 2014.09
> > - Arch Linux
> > - CentOS 6, 7
> > - Debian 6, 7, 8
> > - Gentoo Linux
> > - openSUSE 13.2
> > - OS X 10.8, 10.9, 10.10
> > - Red Hat Enterprise Linux 6, 7
> > - Slackware 14.1
> > - SUSE Linux Enterprise Server 12
> > - Ubuntu 12.04 LTS, 14.04 LTS, 14.10, 15.04
> > - Fedora 20, 21
> >
> >
> > --
> > Mi?tek
> > https://mietek.io
> >
> >
> >
> >
> > On 2015-06-17, at 09:21, Ryan Thomas wrote:
> >
> >> Hi all,
> >>
> >> A new minor release of cabal-install has been released, this is to
> >> pick up a fix for @ezyang's fix for #2502.
> >>
> >> This is now available on hackage and the downloads page and the
> >> sha1sum is listed below.
> >>
> >> Cheers,
> >>
> >> ryan
> >>
> >>
> >> d474b0eef6944af1abef92419cea13cee50993f3 cabal-install-1.22.6.0.tar.gz  
> >> _______________________________________________
> >> cabal-devel mailing list
> >> cabal-devel at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
> >
>  
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>  


From stegeman at gmail.com  Tue Nov 10 21:27:48 2015
From: stegeman at gmail.com (Luite Stegeman)
Date: Tue, 10 Nov 2015 21:27:48 +0000
Subject: Anybody using the "top-down" solver?
In-Reply-To: <n1p7fs$pku$1@ger.gmane.org>
References: <n1p7fs$pku$1@ger.gmane.org>
Message-ID: <CALqQuoiNJ3t_M+CkTCtVL3hX=NZJ9dk2UtZZM=oAz=zcJUptvA@mail.gmail.com>

On Mon, Nov 9, 2015 at 4:30 AM Bardur Arantsson <spam at scientician.net>
wrote:

> Hi all,
>
> Just to get input from as many people as possible: I was pondering a
> plan for modularizing the solver[1] and wanted to reach as many people
> as possible with my question:
>
>    Is anybody is still using the top-down solver?
>
>
We use it for ghcjs-boot, which uses cabal-install to install the GHCJS
boot libraries in the global package db (ghc-prim, template-haskell, base,
ghcjs-prim, ghcjs-base and a bunch of other packages).

There is no fundamental reason that the topdown solver is required. We only
use it because the modular solver blacklists some packages that are risky
to install (like base, template-haskell). I'd be happy to switch to the
modular solver if there's a way to disable the blacklist.

https://github.com/ghcjs/ghcjs/blob/561365ba1667053b5dc5846e2a8edb33eaa3f6dd/src-bin/Boot.hs#L1030-L1056


luite
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20151110/13565db4/attachment.html>

From echo at echonolan.net  Wed Nov 11 06:17:25 2015
From: echo at echonolan.net (Echo Nolan)
Date: Wed, 11 Nov 2015 06:17:25 +0000
Subject: Baffled by Distribution.Simple.BuildTarget.checkTargetExistsAsFile
Message-ID: <CABZ9hJWNnrjM6m5HiQe0Ww_dan7ggw8_VfwHBBg_nSF9Em=iaA@mail.gmail.com>

I'm finding this function very confusing. I think it's supposed to
determine if a user build target is a file, and whether that file exists,
but it does some real weird stuff. I'm not sure if I've found a bug or I
just don't understand what it's supposed to do. Here's the source:

checkTargetExistsAsFile :: UserBuildTarget -> IO (UserBuildTarget, Bool)
checkTargetExistsAsFile t = do
    fexists <- existsAsFile (fileComponentOfTarget t)
    return (t, fexists)

  where
    existsAsFile f = do
      exists <- doesFileExist f
      case splitPath f of
        (d:_)   | hasTrailingPathSeparator d -> doesDirectoryExist d
        (d:_:_) | not exists                 -> doesDirectoryExist d
        _                                    -> return exists

    fileComponentOfTarget (UserBuildTargetSingle     s1) = s1
    fileComponentOfTarget (UserBuildTargetDouble _   s2) = s2
    fileComponentOfTarget (UserBuildTargetTriple _ _ s3) = s3

So... UserBuildTargets can be components, modules or files and can be
qualified at three levels of specificity. It takes the last part of the
qualified build target - which is either a module (Main), a component
(cabal), or a file (Main.hs), then runs the existsAsFile function on it. It
returns a 2-tuple of its input and the result of existsAsFile.

existsAsFile checks whether its parameter is an existing file, then splits
its parameter on directory separators i.e. / or \. If the resulting list is
nonempty and first element ends in a directory separator it returns whether
that first element is an existing directory. This case is entered any time
the parameter begins with a directory, e.g. "foo/bar.hs" but not "bar.hs".
Shouldn't we just return exists here?

existsAsFile's second case is where the split path has at least two
elements and the parameter is not an existing file. It returns whether the
first component of the split path is an existing directory. I have no idea.

The last case is where splitPath f is []. This can only be true if f is [].
In that case we return whether the file named "" exists. This is
impossible, so it's always false.

I can't imagine what happened to make this function this way. From my
perspective, existsAsFile should equal doesFileExist. I must be missing
something right?

Best regards,
Echo Nolan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20151111/6523b86b/attachment.html>

From gershomb at gmail.com  Fri Nov 13 05:02:22 2015
From: gershomb at gmail.com (Gershom B)
Date: Fri, 13 Nov 2015 00:02:22 -0500
Subject: Fwd: Haskell Platform Plans
In-Reply-To: <CAM8RHpGtRNg100f-xzBsqPUjwcFvLseDwWZCnAc4HdwFE7Q1yg@mail.gmail.com>
References: <CAM8RHpGtRNg100f-xzBsqPUjwcFvLseDwWZCnAc4HdwFE7Q1yg@mail.gmail.com>
Message-ID: <CAM8RHpHUj-86AaCkc_g69oQu6ZXS5FxE=AUBGWwARqFxMiqr2Q@mail.gmail.com>

Dear all,

As you know, Mark has passed on the Haskell Platform maintainer hat to me.

I wanted to give a heads-up on current plans to keep folks in the
loop. This message has three sections, first the 7.10.3 release, next
the 8.0 release, and finally some general musings on fiddly details
and future plans.

1) 7.10.3

The 7.10.3 release candidates have been out for windows and unix for a
bit. As I understand it there is still work underway on the mac build,
but that will hopefully be coming shortly. The plan is to release a
new platform roughly simultaneously. This platform will work
essentially as in the past, for two reasons. First, because it is the
last release in the 7.10 series and should be seen like the 7.10.3
compiler as just incorporating some necessary patches rather than any
serious changes. Furthermore, the future plans underway rely on a few
patches to cabal which have been merged, but are not yet in any
existing cabal-install release. A few packages have received minor
version bumps, as follows:

PACKAGE           7.10.2-a   latest
-------------------------------------------
case-insensitive  1.2.0.4   1.2.0.5
fgl               5.5.2.0   5.5.2.3
GLUT              2.7.0.1   2.7.0.3
GLURaw            1.5.0.1   1.5.0.2
HUnit             1.2.5.2   1.3.0.0
OpenGL            2.12.0.1  2.13.1.0
OpenGLRaw         2.5.1.0   2.6.0.0
primitive         0.6       0.6.1.0
syb               0.5.1     0.6
scientific        0.3.3.8   0.3.4.2
StateVar          1.1.0.0   1.1.0.1

A few packages were held back due to dependency issues (notably zlib)
and additionally, packages shipped with ghc were held back to the
versions that will be shipped with 7.10.3.

2) 8.0

We also plan to ship a new platform concurrently with the ghc 8.0 that
should be released early next year.

That platform will implement some long-discussed and requested
changes. First, the platform already ships with msys on windows.
However, it does not do so in a way that lets you, as with minGHC,
install the network library directly, or for that matter install
directly other libraries that use build-type configure. This is
because the msys binaries don't get placed into the path, by design.
The new platform will ship with a newer cabal, incorporating a patch
(pull request #2480) that uses the extra-prog-path setting for
build-type: configure. This should allow network and other things
reliant on build-type: configure to directly cabal install. The goal
for the platform on windows will be that any packages binding to msys
libraries _should_ be cabal installable without hassle. If you
maintain a library that you think would be a good test-case for this,
please drop a line so we can work together towards this goal.

Second, the default platform will be _minimal_. That is to say that it
will _only_ install into the global package database those packages
that are directly shipped with ghc, and not any additional platform
packages.

"Blessed" platform packages will however still be shipped as a
"default user cabal.config" file, so in a setting where users want to
work unsandboxed, their versions of platform libs will remain pegged
to those chosen by the platform, should they not choose to alter their
settings. In a sandboxed setting, or in the presence of a local
cabal.config generated by a freeze, those constraints will be
disregarded.

Furthermore, it is likely but not certain that the "nix-like cabal" or
"no-reinstall cabal" will be available for the 8.0 release. If this is
the case, users will be able to operate in an unsandboxed environment
without conflicts, as multiple instances of the same version of a
package, with different dependency choices, will be able to live
side-by-side.

Third, the platform will ship not only with cabal-install, but also
with the stack tool, so that users can choose either workflow,
depending on their project or preferences. A number of people have
adopted the stack tool, and many beginners have reported success with
it as well, so it will be good to provide that functionality out of
the box with every platform install.

Time and resources permitting we would also like to ship a platform
version _with_ the platform libraries prebuilt and included, as that
is also a use case that some people continue to like. However, this is
a secondary priority, and contingent on us getting our build
infrastructure into a good enough shape to make this not too much
extra hassle.

I'm excited about these changes, and confident we can get their in a
timespan that matches the 8.0 release of ghc.

3) Generalities

As I mentioned, it would be good to have a more uniform build
infrastructure. Generally, I have put out some feelers and am working
towards extending the ghc nightly buildbot infrastructure to both
cover more platforms and also cover more tools -- not only ghc, but
cabal, the platform, perhaps haddock, ghcjs, etc. This way we can get
an economy of scale and many of our core tools will be able to all
share regular automated builds across many platforms. If you like
CI/buildbot systems and would like to help out with this project,
please reach out.

Also, once we've modernized and fixed up the core platform installer
tech, it would be nice to move back to the process of making the
platform a good set of blessed libraries -- taking more proposals for
additions to it, looking to cull libraries that are no longer widely
used, etc. As part of this I intend to move the haskell-platform list
off our deprecated community.haskell.org infrastructure and onto
mail.haskell.org with our other active lists.

Finally, I'm happy to be maintainer of the platform through this
period of change and transition, but at some future point, as things
get sorted out and the release process becomes more standard and
mechanical, I would very much like to pass this responsibility on. I
have had some nibbles of offers, but if other people want to begin to
get involved, please let me know and we can start to get small
contributions from you so that you can become familiar with the
various tech and systems involved.

The Haskell ecosystem is a team effort, a collective project, and
volunteer driven. In my modest experience hacking on the various
systems involved (cabal, cabal-install, hackage, the platform build,
etc.) some are a bit confusing, but I have always found helpful
contributors willing to explain things and review patches, and to help
think about and diagnose problems. And none of the code has been as
confusing as things I've had to wade through for employment-related
purposes :-). So when this stuff doesn't work as well as we'd like, we
can investigate together, and then put our heads together and figure
out how to improve it together. Furthermore, it can be very satisfying
to do so, because the impact of those improvements makes itself widely
felt. I look forward to more people joining in!

Best,
Gershom

From martin at vlkk.cz  Tue Nov 17 16:05:42 2015
From: martin at vlkk.cz (Martin Vlk)
Date: Tue, 17 Nov 2015 16:05:42 +0000
Subject: Contributing to Cabal (fix to #2155)
Message-ID: <564B5056.6000007@vlkk.cz>

Hi, I have a fix to https://github.com/haskell/cabal/issues/2155
including tests almost ready locally and I would like to look at how to
propose a pull request on GitHub. Do I fork the cabal repo or do I have
to get commit rights for the main repo?

How does a review process work?

Mind you I am a Haskell beginner and likewise this is my first time
contributing to some other repo on GitHub so I ask for patience. :-)

Martin Vlk

From adam at bergmark.nl  Tue Nov 17 16:30:12 2015
From: adam at bergmark.nl (Adam Bergmark)
Date: Tue, 17 Nov 2015 17:30:12 +0100
Subject: Contributing to Cabal (fix to #2155)
In-Reply-To: <564B5056.6000007@vlkk.cz>
References: <564B5056.6000007@vlkk.cz>
Message-ID: <CACnqJZbNAeBaUKHNp6fNEUNWTEtPUEoho4xMSdxaOa-2RmvpZQ@mail.gmail.com>

On Tue, Nov 17, 2015 at 5:05 PM, Martin Vlk <martin at vlkk.cz> wrote:

> Hi, I have a fix to https://github.com/haskell/cabal/issues/2155
> including tests almost ready locally and I would like to look at how to
> propose a pull request on GitHub. Do I fork the cabal repo or do I have
> to get commit rights for the main repo?
>

You fork the project and send a pull request.


>
> How does a review process work?
>

I can't really answer this since I'm not involved in Cabal, but roughly:
Someone will review the PR and decide how to proceed, be it requesting some
more changes or merge it right away.

HTH,
Adam



> Mind you I am a Haskell beginner and likewise this is my first time
> contributing to some other repo on GitHub so I ask for patience. :-)
>
> Martin Vlk
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20151117/b94f6aaa/attachment.html>

From spam at scientician.net  Tue Nov 17 16:31:58 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Tue, 17 Nov 2015 17:31:58 +0100
Subject: Contributing to Cabal (fix to #2155)
In-Reply-To: <564B5056.6000007@vlkk.cz>
References: <564B5056.6000007@vlkk.cz>
Message-ID: <n2fkpv$epc$1@ger.gmane.org>

On 11/17/2015 05:05 PM, Martin Vlk wrote:
> Hi, I have a fix to https://github.com/haskell/cabal/issues/2155
> including tests almost ready locally and I would like to look at how to
> propose a pull request on GitHub. Do I fork the cabal repo or do I have
> to get commit rights for the main repo?
> 

You do a fork and then push a branch to your clone of the repository. If
you go to the Web UI soon afterwards you'll see a little message pop up
about creating a pull request. (You can also just go to the branch
"manually" in the Web UI and create the pull request.)

> How does a review process work?
> 

Seems pretty ad-hoc, unfortunately. It's probably a case of people being
busy and/or not feeling that they have the necessary "authority" to
approve/reject PRs.

I think there may need to be some "reform" around this.

Regards,


From martin at vlkk.cz  Sat Nov 28 09:20:49 2015
From: martin at vlkk.cz (Martin Vlk)
Date: Sat, 28 Nov 2015 09:20:49 +0000
Subject: Hints on fixing #2645: Properly merge preferences (dependency
 resolution)
Message-ID: <565971F1.7080805@vlkk.cz>

Hi folks,
I am a beginner cabal hacker and I have been picking issues to fix,
labeled with "easy".

My next one is https://github.com/haskell/cabal/issues/2645.

I've been trying to read and feel my way through the code and find where
this issue is rooted, but so far I haven't succeeded.

To save me unnecessary effort, could somebody point me at the right
modules/functions where soft constraints/preferences are handled and
also where the corresponding merging functionality is implemented for
hard constraints.

I'll then take it from there, read the code and fix the issue,
potentially asking more questions here.

Many Thanks
Martin

From martin at vlkk.cz  Sat Nov 28 09:59:32 2015
From: martin at vlkk.cz (Martin Vlk)
Date: Sat, 28 Nov 2015 09:59:32 +0000
Subject: Hints on fixing #2645: Properly merge preferences (dependency
 resolution)
In-Reply-To: <565971F1.7080805@vlkk.cz>
References: <565971F1.7080805@vlkk.cz>
Message-ID: <56597B04.4000507@vlkk.cz>

Oh, and a primer on the overall cabal design would be also very useful!

M.

Martin Vlk:
> Hi folks,
> I am a beginner cabal hacker and I have been picking issues to fix,
> labeled with "easy".
> 
> My next one is https://github.com/haskell/cabal/issues/2645.
> 
> I've been trying to read and feel my way through the code and find where
> this issue is rooted, but so far I haven't succeeded.
> 
> To save me unnecessary effort, could somebody point me at the right
> modules/functions where soft constraints/preferences are handled and
> also where the corresponding merging functionality is implemented for
> hard constraints.
> 
> I'll then take it from there, read the code and fix the issue,
> potentially asking more questions here.
> 
> Many Thanks
> Martin
> 

From tom.lippincott at gmail.com  Sat Nov 28 15:23:54 2015
From: tom.lippincott at gmail.com (Thomas Lippincott)
Date: Sat, 28 Nov 2015 10:23:54 -0500
Subject: issue with cabal behavior with a custom Setup.hs
Message-ID: <5659C70A.9090501@gmail.com>

Hello,

I'm seeing what I think is some strange (or at least, non-intuitive) 
behavior in a custom package, and was wondering if someone could point 
me in the right direction.  Basically, I need the build process to 
generate some additional exposed modules, i.e. add them to the 
"exposed-modules" variable, and create the corresponding source files. 
It's easy to get the list of modules and produce the source files at any 
point in the build process (I know this is a questionable design, trying 
to do this as part of Cabal, but suffice it to say there are good 
arguments on both sides for our particular situation).

I'm *so* close to having it working perfectly: in fact, if I run "cabal 
repl", I get a shell with all the right modules compiled and exposed, 
so, it should work the same way if it's installed and imported in ghci, 
right?  Well, when I do that, the auto-generated modules are *not* 
exposed.  It's clearly generating the source files and compiling them, 
maybe "cabal install" isn't getting the updated module list or 
something?  Here's what I'm doing:

I override "confHook" to call the original configure function, but then 
get the list of auto-generated modules and add them to the 
exposedModules field in the Library structure nested in the 
LocalBuildInfo structure before returning it.  The idea is that I've 
intercepted the list of exposed modules as early as possible, and so 
it's as though the Cabal file had the auto-generated modules listed from 
the start.  I generate the actual source files by overriding "preBuild". 
  Nothing else is modified from the default simpleUserHooks.

This probably isn't the place for "how do I..." questions, so I'll frame 
it as: why would "cabal repl" work, and "cabal install" and ghci+import 
not work?  I apologize if this is an inappropriate place to ask, but 
there aren't exactly a ton of Cabal experts floating around!

Thanks for any help,

-Tom

From adam at bergmark.nl  Sat Nov 28 16:14:10 2015
From: adam at bergmark.nl (Adam Bergmark)
Date: Sat, 28 Nov 2015 17:14:10 +0100
Subject: issue with cabal behavior with a custom Setup.hs
In-Reply-To: <5659C70A.9090501@gmail.com>
References: <5659C70A.9090501@gmail.com>
Message-ID: <CACnqJZY1xhh+_YFrWjys4eCPp8tbwBp_ZyU26SvxVTfy6FZs3Q@mail.gmail.com>

I believe this does the same thing as what you want:
https://github.com/hvr/base-noprelude/blob/pre-ghc710/Setup.hs

HTH,
Adam


On Sat, Nov 28, 2015 at 4:23 PM, Thomas Lippincott <tom.lippincott at gmail.com
> wrote:

> Hello,
>
> I'm seeing what I think is some strange (or at least, non-intuitive)
> behavior in a custom package, and was wondering if someone could point me
> in the right direction.  Basically, I need the build process to generate
> some additional exposed modules, i.e. add them to the "exposed-modules"
> variable, and create the corresponding source files. It's easy to get the
> list of modules and produce the source files at any point in the build
> process (I know this is a questionable design, trying to do this as part of
> Cabal, but suffice it to say there are good arguments on both sides for our
> particular situation).
>
> I'm *so* close to having it working perfectly: in fact, if I run "cabal
> repl", I get a shell with all the right modules compiled and exposed, so,
> it should work the same way if it's installed and imported in ghci, right?
> Well, when I do that, the auto-generated modules are *not* exposed.  It's
> clearly generating the source files and compiling them, maybe "cabal
> install" isn't getting the updated module list or something?  Here's what
> I'm doing:
>
> I override "confHook" to call the original configure function, but then
> get the list of auto-generated modules and add them to the exposedModules
> field in the Library structure nested in the LocalBuildInfo structure
> before returning it.  The idea is that I've intercepted the list of exposed
> modules as early as possible, and so it's as though the Cabal file had the
> auto-generated modules listed from the start.  I generate the actual source
> files by overriding "preBuild".  Nothing else is modified from the default
> simpleUserHooks.
>
> This probably isn't the place for "how do I..." questions, so I'll frame
> it as: why would "cabal repl" work, and "cabal install" and ghci+import not
> work?  I apologize if this is an inappropriate place to ask, but there
> aren't exactly a ton of Cabal experts floating around!
>
> Thanks for any help,
>
> -Tom
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20151128/74840b65/attachment.html>

From mikhail.glushenkov at gmail.com  Sat Nov 28 18:24:16 2015
From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov)
Date: Sat, 28 Nov 2015 19:24:16 +0100
Subject: Hints on fixing #2645: Properly merge preferences (dependency
 resolution)
In-Reply-To: <56597B04.4000507@vlkk.cz>
References: <565971F1.7080805@vlkk.cz>
	<56597B04.4000507@vlkk.cz>
Message-ID: <CA+tcxkDN9AJY-WCwYXd55bfVSbU+Z2imx6cm6rtbGTuTkJAt7w@mail.gmail.com>

Hi,

On 28 November 2015 at 10:59, Martin Vlk <martin at vlkk.cz> wrote:
> Oh, and a primer on the overall cabal design would be also very useful!

Take a look at https://github.com/haskell/cabal/wiki/Source-Guide

From tom.lippincott at gmail.com  Mon Nov 30 00:53:33 2015
From: tom.lippincott at gmail.com (Thomas Lippincott)
Date: Sun, 29 Nov 2015 19:53:33 -0500
Subject: issue with cabal behavior with a custom Setup.hs
In-Reply-To: <CACnqJZY1xhh+_YFrWjys4eCPp8tbwBp_ZyU26SvxVTfy6FZs3Q@mail.gmail.com>
References: <5659C70A.9090501@gmail.com>
 <CACnqJZY1xhh+_YFrWjys4eCPp8tbwBp_ZyU26SvxVTfy6FZs3Q@mail.gmail.com>
Message-ID: <565B9E0D.8070505@gmail.com>

Hmmm, it does appear to aim at a very similar goal, but that branch only 
builds with old cabal versions, and even though I've made my code 
override the same functions, it still doesn't expose the 
dynamically-generated modules on normal import, only on "cabal repl". 
But I also noticed that "cabal repl" also exposes all the hidden 
modules, so maybe that isn't a good indication...anyways, I'm stumped 
for the moment on why modifying the exposed modules list at the confHook 
stage doesn't get propagated to the later stages.  Like I said, the 
modules do get compiled, just not exposed.
-Tom

On 11/28/2015 11:14 AM, Adam Bergmark wrote:
> I believe this does the same thing as what you want:
> https://github.com/hvr/base-noprelude/blob/pre-ghc710/Setup.hs
>
> HTH,
> Adam
>
>
> On Sat, Nov 28, 2015 at 4:23 PM, Thomas Lippincott
> <tom.lippincott at gmail.com <mailto:tom.lippincott at gmail.com>> wrote:
>
>     Hello,
>
>     I'm seeing what I think is some strange (or at least, non-intuitive)
>     behavior in a custom package, and was wondering if someone could
>     point me in the right direction.  Basically, I need the build
>     process to generate some additional exposed modules, i.e. add them
>     to the "exposed-modules" variable, and create the corresponding
>     source files. It's easy to get the list of modules and produce the
>     source files at any point in the build process (I know this is a
>     questionable design, trying to do this as part of Cabal, but suffice
>     it to say there are good arguments on both sides for our particular
>     situation).
>
>     I'm *so* close to having it working perfectly: in fact, if I run
>     "cabal repl", I get a shell with all the right modules compiled and
>     exposed, so, it should work the same way if it's installed and
>     imported in ghci, right?  Well, when I do that, the auto-generated
>     modules are *not* exposed.  It's clearly generating the source files
>     and compiling them, maybe "cabal install" isn't getting the updated
>     module list or something?  Here's what I'm doing:
>
>     I override "confHook" to call the original configure function, but
>     then get the list of auto-generated modules and add them to the
>     exposedModules field in the Library structure nested in the
>     LocalBuildInfo structure before returning it.  The idea is that I've
>     intercepted the list of exposed modules as early as possible, and so
>     it's as though the Cabal file had the auto-generated modules listed
>     from the start.  I generate the actual source files by overriding
>     "preBuild".  Nothing else is modified from the default simpleUserHooks.
>
>     This probably isn't the place for "how do I..." questions, so I'll
>     frame it as: why would "cabal repl" work, and "cabal install" and
>     ghci+import not work?  I apologize if this is an inappropriate place
>     to ask, but there aren't exactly a ton of Cabal experts floating around!
>
>     Thanks for any help,
>
>     -Tom
>     _______________________________________________
>     cabal-devel mailing list
>     cabal-devel at haskell.org <mailto:cabal-devel at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>
>

From ryan at ryant.org  Mon Nov 30 21:31:49 2015
From: ryan at ryant.org (Ryan Thomas)
Date: Mon, 30 Nov 2015 21:31:49 +0000
Subject: ANN: Cabal-1.22.5.0 has been released
Message-ID: <CAJCpNrrzVy+i2R2U5xfChQDcVU0hDa++QahoMJx++Mbzx6j6Cw@mail.gmail.com>

Cabal 1.22.5.0 has been released and pushed to hackage with the following
changes:

- Don't recompile C sources unless needed (#2601). (Luke Iannini)
- Support Haddock response files.
- Add frameworks when linking a dynamic library.

As well as to facilitate the GHC 7.10.3 release.

Cheers,

ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20151130/0ac6649e/attachment.html>