Re: regression in ghc / cabal integration in 9.2.1

2021-10-30 Thread Mikolaj Konarski
Hi George,

Have you looked at the ticket I gave you? Here's one linked from it
mentioning the topic of ghc-pkg compatibility with v2-install:
https://github.com/haskell/cabal/issues/6508

I'm afraid we don't have any systematic exposition of cabal history
with rationale for its major changes, but there's a changelog and the
commit log. If you'd like to contribute something better, please do.

Why the difference between GHC versions, I don't know, or whether
upgrading your cabal would help (I doubt it). Regarding your workflow,
perhaps ask around or look up in cabal tickets how other people do
this now? I never run ghc directly, so I don't know.

Best,
Mikolaj

On Sat, Oct 30, 2021 at 9:44 PM Brandon Allbery  wrote:
>
> Wasn't there specifically a new cabal version released to deal with
> 9.2.1? 3.4.1.0 / 3.6.2.0?
>
> On Sat, Oct 30, 2021 at 3:24 PM George Colpitts
>  wrote:
> >
> > Thanks for the quick response Mikolaj. Sorry for the confusion, with cabal 
> > install I did use --lib but accidentally omitted that in my original email. 
> > In 9.0.1 this results in a successful compilation but in 9.2.1 it does not 
> > thus I believe this is a regression.
> >
> > Here's the output I got in 9.2.1:
> >
> > bash-3.2$ cabal install vector --lib
> > Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.0.0 supports
> > 'ghc' version < 9.1): /usr/local/bin/ghc is version 9.2.1
> > Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.0.0 supports
> > 'ghc' version < 9.1): /usr/local/bin/ghc is version 9.2.1
> > Resolving dependencies...
> > Up to date
> > bash-3.2$ ghc buggc.hs
> > [1 of 1] Compiling Main ( buggc.hs, buggc.o )
> >
> >
> > buggc.hs:2:1: error:
> > Could not find module ‘Data.Vector’
> > Perhaps you meant Data.Functor (from base-4.16.0.0)
> > Use -v (or `:set -v` in ghci) to see a list of the files searched for.
> >   |
> > 2 | import Data.Vector
> >
> >
> > However I did figure out a workaround: cabal v1-install.
> >
> > As far as I can tell cabal (v2-) install breaks ghc-pkg and compilation. 
> > With cabal (v2-) install the workaround for ghc-pkg is to add the option 
> > "-f $HOME/.cabal/store/ghc-9.2.1/package.db" to the end of the command 
> > "ghc-pkg list". For compilation the workaround is to add "-package-db 
> > $HOME/.cabal/store/ghc-9.2.1/package.db" to the ghc-pkg. I don't understand 
> > why it was necessary for  cabal v2-install to be incompatible with cabal 
> > v1-install. Is there a link to any documentation and justification for 
> > these incompatible changes?
> >
> > Thanks again,
> > George
> >
> >
> >
> > On Sat, Oct 30, 2021 at 3:38 PM Mikolaj Konarski  
> > wrote:
> >>
> >> Hi George,
> >>
> >> Since many versions of cabal, `install` only installs executables, not
> >> libraries, so if that worked for you, you must have had an old version
> >> of cabal.
> >>
> >> Please see https://github.com/haskell/cabal/issues/6481 for some
> >> context and to help you find a new workflow that works for you
> >> (ideally, a standard one).
> >>
> >> Kind regards,
> >> Mikolaj
> >>
> >> On Sat, Oct 30, 2021 at 5:40 PM George Colpitts
> >>  wrote:
> >> >
> >> > Thanks Ben!
> >> >
> >> > There seems to be a regression in ghc / cabal integration in 9.2.1.
> >> >
> >> > In 9.2.1 if I do
> >> >
> >> > cabal install vector
> >> >
> >> > Compilation of a file containing
> >> >
> >> >
> >> > import Data.Vector
> >> >
> >> >
> >> > main = undefined
> >> >
> >> >
> >> > fails with
> >> >
> >> >  Could not find module ‘Data.Vector’
> >> > Perhaps you meant Data.Functor (from base-4.16.0.0)
> >> > Use -v (or `:set -v` in ghci) to see a list of the files searched 
> >> > for.
> >> >   |
> >> > 2 | import Data.Vector
> >> >   | ^^
> >> >
> >> > The preceding works on ghc 9.0.1
> >> >
> >> > Should I file a bug against Cabal?
> >> >
> >> > Thanks
> >> > George
> >> >
> >> > On Fri, Oct 29, 2021 at 12:54 PM Ben Gamari  wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> The GHC developers are

Re: regression in ghc / cabal integration in 9.2.1

2021-10-30 Thread Mikolaj Konarski
Hi George,

Since many versions of cabal, `install` only installs executables, not
libraries, so if that worked for you, you must have had an old version
of cabal.

Please see https://github.com/haskell/cabal/issues/6481 for some
context and to help you find a new workflow that works for you
(ideally, a standard one).

Kind regards,
Mikolaj

On Sat, Oct 30, 2021 at 5:40 PM George Colpitts
 wrote:
>
> Thanks Ben!
>
> There seems to be a regression in ghc / cabal integration in 9.2.1.
>
> In 9.2.1 if I do
>
> cabal install vector
>
> Compilation of a file containing
>
>
> import Data.Vector
>
>
> main = undefined
>
>
> fails with
>
>  Could not find module ‘Data.Vector’
> Perhaps you meant Data.Functor (from base-4.16.0.0)
> Use -v (or `:set -v` in ghci) to see a list of the files searched for.
>   |
> 2 | import Data.Vector
>   | ^^
>
> The preceding works on ghc 9.0.1
>
> Should I file a bug against Cabal?
>
> Thanks
> George
>
> On Fri, Oct 29, 2021 at 12:54 PM Ben Gamari  wrote:
>>
>> Hi all,
>>
>> The GHC developers are very happy to at long last announce the
>> availability of GHC 9.2.1. Binary distributions, source distributions,
>> and documentation are available at
>>
>> https://downloads.haskell.org/ghc/9.2.1
>>
>> GHC 9.2 brings a number of exciting features including:
>>
>>  * A native code generation backend for AArch64, significantly speeding
>>compilation time on ARM platforms like the Apple M1.
>>
>>  * Many changes in the area of records, including the new
>>`RecordDotSyntax` and `NoFieldSelectors` language extensions, as well
>>as Support for `DuplicateRecordFields` with `PatternSynonyms`.
>>
>>  * Introduction of the new `GHC2021` language extension set, giving
>>users convenient access to a larger set of language extensions which
>>have been long considered stable.
>>
>>  * Merging of `ghc-exactprint` into the GHC tree, providing
>>infrastructure for source-to-source program rewriting out-of-the-box.
>>
>>  * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism
>>over levity of boxed objects (#17526)
>>
>>  * Implementation of the `UnliftedDataTypes` extension, allowing users
>>to define types which do not admit lazy evaluation ([proposal])
>>
>>  * The new [`-hi` profiling] mechanism which provides significantly
>>improved insight into thunk leaks.
>>
>>  * Support for the `ghc-debug` out-of-process heap inspection library
>>[ghc-debug]
>>
>>  * Significant improvements in the bytecode interpreter, allowing more
>>programs to be efficently run in GHCi and Template Haskell splices.
>>
>>  * Support for profiling of pinned objects with the cost-centre profiler
>>(#7275)
>>
>>  * Faster compilation and a smaller memory footprint
>>
>>  * Introduction of Haddock documentation support in TemplateHaskell (#5467)
>>
>> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake
>> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
>> contributors whose on-going financial and in-kind support has
>> facilitated GHC maintenance and release management over the years.
>> Moreover, this release would not have been possible without the hundreds
>> of open-source contributors whose work comprise this release.
>>
>> As always, do open a [ticket] if you see anything amiss.
>>
>> Happy testing,
>>
>> - Ben
>>
>>
>> [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html
>> [proposal]: 
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst
>> [-hi profiling]: 
>> https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/
>> [ghc-debug]: http://ghc.gitlab.haskell.org/ghc-debug/
>> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
>> ___
>> ghc-devs mailing list
>> ghc-d...@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


Re: [ANN] Cabal-3.6.0.0

2021-08-06 Thread Mikolaj Konarski
Hi Thomas,

> The changelog (and the 3.6 branch) does not include 
> https://github.com/haskell/cabal/pull/7493.  This is just as well since HEAD 
> (with this merge) doesn't fix the related issue in my testing, but I'm 
> curious if such a fix can be part of a point release or if it must be 3.8?

Please do share, as a comment on the PR or the main issue, the results
of your testing, whether negative or positive. We are deferring the
merge to a point release, in particular, because only a few people
tested the hack.

Kind regards,
Mikolaj
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


Re: Testing that packages still compile

2018-05-31 Thread Mikolaj Konarski
You may also be interested in the "Hackage Matrix CI" links
on Hackage pages and the non-maintainer updates
of packages performed as part of the service to the community.

On Thu, May 31, 2018 at 11:32 AM, Sébastien Hinderer
 wrote:
> Dear all,
>
> I am part of the OCaml development team. As you may know, OCaml has a
> package manager a bit similar to cabal whose name is opam.
>
> One of my colleagues spends quite a lot of time trying to make sure that
> packages still compile with a new version of the compiler, when we
> release it. When a package does not compile any longer, it seems it is a
> highly non-trivial task to figure out what exactly is broken: is it the
> package itself which has been broken by a change in the compiler, or is
> it one of its dependencies.
>
> I am assuming the same kind of problems occur with Haskell and am
> wondering how they are handle.
>
> Has there been something published on this kind of problem?
>
> Any pointer, comment or contact appreciated.
>
> Best wishes,
>
> Sébastien.
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1

2014-12-13 Thread Mikolaj Konarski
On Sat, Dec 13, 2014 at 8:53 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
 Thomas and I have found some bugs in HPC on OSX, and we're in the midst of
 tracking those down,

You mean these are regressions? If they are introduced
in one of the non-blocker fixes in 7.8.4, we can probably
just revert them. Anyway, thanks a lot for testing.

Cheers,
Mikolaj
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1

2014-12-13 Thread Mikolaj Konarski
OK. In that case, let's remember to get *that* version of cabal into 7.8.4.


/me conditions himself with chocolate to help the remembering

On Sat, Dec 13, 2014 at 11:02 PM, Thomas Tuegel ttue...@gmail.com wrote:
 On Sat, Dec 13, 2014 at 3:56 PM, Mikolaj Konarski
 miko...@well-typed.com wrote:
 On Sat, Dec 13, 2014 at 8:53 PM, Carter Schonwald
 carter.schonw...@gmail.com wrote:
 Thomas and I have found some bugs in HPC on OSX, and we're in the midst of
 tracking those down,

 You mean these are regressions? If they are introduced
 in one of the non-blocker fixes in 7.8.4, we can probably
 just revert them. Anyway, thanks a lot for testing.

 Sorry, these are not regressions. It's really a bug in Cabal which
 will be fixed in 1.22. When Carter wrote this, we thought the problem
 was with the GHC side of HPC because of some very vague error
 messages.

 --
 Thomas Tuegel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: win32 GHC 7.8.3 works under Wine and i386-linux GHC 7.8.3 works under amd64-linux

2014-09-12 Thread Mikolaj Konarski
(cross-com^H^H^Hposting to glasgow-haskell-users@haskell.org)

Well, sorf-of. A few extra unobvious parameters and workarounds
are required in each case, but it's doable, (arguably) simpler
than real cross-compilation and already exhibits problems
that real cross-compilation may in some circumstances face.

Wiki pages (kudos to all previous authors):

http://www.haskell.org/haskellwiki/GHC_under_Wine

https://ghc.haskell.org/trac/ghc/wiki/Building/Compiling32on64


Examples of both kinds of binaries, for a project with gtk2hs and TH dependency:

https://github.com/LambdaHack/LambdaHack/releases/tag/v0.4.99.0


Please share your success reports here or on the wiki and let's exchange
ideas, file concrete tickets and propose patches to make the two processes
more accessible. Some tickets are mentioned in the wikis or can be traced
from there, but there may be others I'm not aware of, so let's link them
where appropriate.

Hope this helps somebody,
Mikolaj
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users