December 2020 - Haskell-Cafe

Do something about Cabal?
by Ignat Insarov 03 Jan '22

03 Jan '22

# Do something about Cabal? Hello. Cabal is the second most used tool in Haskell after GHC. It has many problems. It may be noticed that there is one and a half developers working on it. This is clearly not enough to address these problems. I propose that this is a good place to invest in. ### Problems I have in mind: * Poor communication, lack of open source development process. The whole Cabal–Stack schism appears to be an outcome of poor communication. One of the leading developers of Cabal is even banned from participation somewhere in Stack circles.[1] Personally, I reported several issues to Cabal and every single time it resulted in sadness. Observe a vicious circle: core developers are overworked ⇒ they are being unfriendly ⇒ there are fewer contributors ⇒ core developers are overworked. I have no hard evidence but it appears that presently, more people that strive to improve the Haskell build experience are outside the Cabal cabal than are inside. * User experience is an afterthought. Cabal's user experience is horrifying. A collection of complaints is being compiled elsewhere.[2] There are also bugs being opened to Cabal because of this, requiring triage and therefore wasting the precious time of the few overworked developers. Stack is much more friendly — this shows by example that the user experience problem is not inherent and may be solved. It is ordinary to receive output like this: ``` % cabal run example-executable Warning: The package list for 'hackage.haskell.org' is 84 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... cabal: Could not resolve dependencies: [__0] trying: example-0.1.0.6 (user goal) [__1] next goal: opaleye (dependency of example) [__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project config TODO requires ==0.6.7006.1) [__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7) [__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2, opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1, opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0, opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0, opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0, opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3, opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0, opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the previous version to fail: excluded by constraint '^>=0.7' from example) [__1] fail (backjumping, conflict set: example, opaleye) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: opaleye, example ``` There are so many things that are wrong here. Even a sneaky _«to do»_ remark. If you wonder, in this case the solution is to remove and re-generate `cabal.project.freeze`. Even the name of the program — it is actually _«cabal-install»_ — is incomprehensible, it should be re-branded to Cabal, which is how everyone calls it anyway. * Features are not being introduced. There is no reason for two build tools to exist. The killer feature of Stack — snapshots — should be supported by Cabal. Possibly Cabal itself should be refactored and split so that there are separate tools for packaging, version resolution and human interaction — I do not know. But certainly the way things are presently is a waste of developer effort and a source of confusion for everyone. ### My proposition, in particular. * Ask all the people that show compassion to the cause of a great Haskell build tool to unite and work together on a better Cabal. This includes the developers of Stack and everyone that expressed unhappiness with the current state of Cabal. These people should be seen as a blessing, not as an obstacle. * Put in place a clear process for contributing and decision making, so that it does not come down to the privileged opinion of one of the core developers. * Make a model of user experience that Cabal should conform to, and make conformance a priority. Surely there are among us people that know a thing or two about user experience — call for them to step forward. Every issue that stems from misunderstanding, re-assign to the model instead of closing. * Merge the support of Stackage snapshots into Cabal. Ask the core developers of Stack to join the effort. Transition from Stack to Cabal should be one well discoverable command that just works. I realize that this letter is largely an opinion piece. You can also see it as an _«ideal piece»_. Without an ideal, without a vision, we are stuck with the present. I do not insist that my vision is the best. But the present reality is not the best vision either. I propose, foremost, that we work and fight for a better future. [1]: https://github.com/commercialhaskell/stackage/issues/4472 [2]: https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal

23 39

[ANN] fp-ieee v0.1
by ARATA Mizuki 02 Jan '21

02 Jan '21

Hi all, I'd like to announce the first release of fp-ieee. https://hackage.haskell.org/package/fp-ieee This library aims to provide IEEE 754-2019 compliant operations, including * fusedMultiplyAdd * correctly-rounding versions of fromInteger (GHC's fromInteger for Float and Double do not round correctly; see https://gitlab.haskell.org/ghc/ghc/-/issues/17231) * realFloatToFrac: an alternative of realToFrac with well-defined semantics. Other notes: * Most of the functions are generic, and any RealFloat instance can be used. However, manipulation of NaN's sign and payload requires an additional constraint (RealFloatNaN, provided by this library). * Access to floating-point environment is not provided. If you want to control rounding direction, look at my another library: https://hackage.haskell.org/package/rounded-hw * Decimal-specific operations (like quantize, quantum) are not provided, and the preferred exponent is not honored. * Use of FFI can be disabled via a package flag (maybe useful when using non-native targets). Mizuki

2 3

ghc/cabal problems - mystery?
by Gregory Guthrie 30 Dec '20

30 Dec '20

I reported several odd and inconsistent results that I can't understand, and after some further trials, a few more data points, but still confused. A directory of files, cabal build runs fine, then trying to execute; I get three different results; Linking D:\CS\Courses\long path\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl.exe ... Seems fine. Then; from that same shell (PS) in the same directory - >From cabal run: Fails PS D:\CS\Courses\long path\All Solutions> cabal run Up to date D:\CS\Courses\long path\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl: createProcess: invalid argument (Invalid argument) >From using the explicit path: Fails PS D:\CS\Courses\long path\All Solutions> dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl.exe Program 'apl.exe' failed to run: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detailAt line:1 char:1 + dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~. At line:1 char:1 + dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ResourceUnavailable: (:) [], ApplicationFailedException + FullyQualifiedErrorId : NativeCommandFailed >From going to the dist folder: runs fine. PS D:\CS\Courses\long path\All Solutions> cd dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl PS D:\CS\Courses\long path\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl> apl.exe "APL: Examples and labs" I get a few other errors & results sometimes; copy the full directory to somewhere else, "cabal clean", And it won't build, "no target specified", even though the entire folder is identical. Again; every time just copying the entire directory, no editing of any files, just running cabal as above. Any hints or ideas why I am getting these issues & errors? GHC 8.10.2 Cabal 3.2.0.0 (Windows 10) ------------------------------------------------------------------------ PS: One more... I (again) copied the entire directory to another place and retested, in that case "cabal run" did run, but gave results from a different file in the directory (multiple tests there, only one run from Main.hs, same .cabal file), and can run it by explicit path or "cabal run". All results should be "DSem_imp", one is from a different file, "DSem_impc" ?? Certainly looks like they should all be running the same apl.exe. ?? Output"" PS G:\Testing\All Solutions> cabal clean PS G:\Testing\All Solutions> cabal run Resolving dependencies... Build profile: -w ghc-8.10.2 -O1 In order, the following will be built (use -v for more details): - apl-0.0.1 (exe:apl) (first run) Configuring apl-0.0.1... Preprocessing executable 'apl' for apl-0.0.1.. Building executable 'apl' for apl-0.0.1.. ... Linking G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl\apl.exe ... "APL: Examples and labs" "======================" "------ APL:: DSem_imp" PS G:\Testing\All Solutions> dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl\apl.exe "APL: Examples and labs" "======================" "------ APL:: DSem_imp" PS G:\Testing\All Solutions> cd dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl PS G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl> ls Directory: G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl Mode LastWriteTime Length Name ---- ------------- ------ ---- d----- 12/30/2020 12:18 PM apl-tmp d----- 12/30/2020 12:17 PM autogen -a---- 12/30/2020 12:18 PM 11230184 apl.exe PS G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl> apl.exe "APL: Examples and labs" "======================" "------ APL:: DSem_impc" Gregory Guthrie Maharishi International University ----------------------------------------------------------------

2 3

cabal errors
by Gregory Guthrie 28 Dec '20

28 Dec '20

I'm having some issues with Cabal , wonder if they are known issues. 1) I had a previously working installation of files, hadn't used them for some time, did Haskell upgrades (chocolatey), and tried to recompile. I got a weird error on running the build - Program 'apl.exe' failed to run: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detailAt line:1 char:1 + ./apl + ~~~~~. At line:1 char:1 + ./apl + ~~~~~ + CategoryInfo : ResourceUnavailable: (:) [], ApplicationFailedException + FullyQualifiedErrorId : NativeCommandFailed Chasing this all around - no solutions so I started over, in a new location, adding one file at a time. Worked fine. 2) So I then has a current working build in some top level xTest temporary directory. (Just a direct copy of all the files, and "cabal v2-build") 3) So I then just copied all the source files back to a desired installation place, with a longer path name. 4) But there it fails to build: PS D:\CS\Courses\long path\Solns\All Solutions> cabal v2-install Wrote tarball sdist to D:\CS\Courses\long path\Solns\All Solutions\dist-newstyle\sdist\apl-0.0.1.tar.gz Resolving dependencies... Build profile: -w ghc-8.10.1 -O1 In order, the following will be built (use -v for more details): - apl-0.0.1 (exe:apl) (requires build) cabal.exe: Failed to unpack apl-0.0.1. The exception was: dieVerbatim: user error (cabal.exe: Package .cabal file not found in the tarball: C:\Users\guthrie\AppData\Local\Temp\cabal-install.-2584\dist-newstyle\tmp\src-2584\apl-0.0.1\apl.cabal) 5) Just copying (again) the same folder of files which is failing to a top level new folder (yTest), deleting the dist-newstyle folder, And running "cabal v2-buld" again, all works fine, no errors, executable built. Three directories, all with the same files - one fails. ?? The only difference I can see is the long path name with blanks in it - is that an issue? Dr. Gregory Guthrie Maharishi International University ----------------------------------------------------------------

1 1

Re: [Haskell-cafe] [Ann] group-theory
by Olaf Klinke 26 Dec '20

26 Dec '20

Koji Miyazato wrote: > > You can use `MonoidNull`. from monoid-subclasses to avoid an `Eq` > constraint. > > For groups, there is no difference between `MonoidNull` and `Eq`, as > you can define `x == y` be > `null (x <> inv y)`. There are monoids which `==` is not even > decidable but `null` is (e.g. context-free grammars > with equality defined by the language it defines), but such monoid > necessarily has no `Group` instance. A beautiful example of topological groups: Their topology is completely determined by the neighbourhoods of the identity element. If the identity element is isolated, the entire group is discrete. Olaf

1 0

[Ann] group-theory
by Emily Pillmore 26 Dec '20

26 Dec '20

Hello all, I am pleased to announce the release of the group-theory ( https://hackage.haskell.org/package/group-theory ) package: a package aimed at implementing the theory of finite groups in a reasonably ergonomic, well-documented, and featureful way. It's hardly finished, but my co-maintainer, Reed Mullanix (@totbwf) and I thought this was a good mvp with which we could announce. Contributions are very welcome, and I hope everyone enjoys. Cheers, Emily Pillmore

7 12

Haskell-language-server is looking for a logo
by Alan & Kim Zimmerman 24 Dec '20

24 Dec '20

Hi all, The haskell language server is coming up for its first birthday in January. To celebrate we would like to collectively choose a logo. So if you have a creative streak and would like to donate a lasting contribution to the project, please submit for consideration at [1]. We will aim to close the judging on 25 Jan 2021, being the anniversary of the Bristol Hackathon[2] where HLS was born. Alan [1] https://github.com/haskell/haskell-language-server/issues/694 [2] https://mpickering.github.io/bristol2020.html

5 5

Supporting Haskell.org
by Rebecca Skinner 23 Dec '20

23 Dec '20

Hi everyone. Apologies for the second email here. I originally sent this message with an incorrect subject, and I wanted to re-post here with a correct subject for visibility. This has been an eventful year for many of us, and haskell.org is no different. This year we've continued to support a significant part of the Haskell community infrastructure- including haskell.org, Hackage, Hoogle, and GHC build infrastructure. We're able to do this thanks to the support of the Haskell community. In addition to our ongoing work maintaining Haskell community infrastructure, we once again participated in the Google Summer of Code this year, supporting 12 projects. You can read more about the projects here: https://summer.haskell.org/news/2020-10-12-final-results.html As many of you are likely aware, this year also saw some of our community successfully launch a new initiative, the Haskell Foundation. We are thrilled for the Haskell Foundation and congratulate them on their successful launch. Haskell.org is an independent organization, and while we welcome any opportunities to collaborate with the Haskell Foundation, we will continue to pursue our mission of managing and supporting Haskell community infrastructure. If you would like to support Haskell.org in our mission, you can donate via several method, including PayPay and check: https://www.haskell.org/donations/ Haskell.org can also accept donations through employers via Benevity using the unique ID 475236502. Haskell.org is a 501(c)(3) non-profit, so donations may be tax-deductible in your jurisdiction. Another way to help haskell.org is to serve on the committee. We have three positions opening in 2021, and our call for nominations is open through Jan 7th 2021. Please email the committee at committee(a)haskell.org if you would like to nominate yourself or someone else for a position. We look forward to continuing this work with your support in 2021 as well as exploring new projects to improve the Haskell community infrastructure. Best wishes, Rebecca Skinner on behalf of the haskell.org committee.

1 0

Supporting The Haskell Foundation
by Rebecca Skinner 23 Dec '20

23 Dec '20

This has been an eventful year for many of us, and haskell.org is no different. This year we've continued to support a significant part of the Haskell community infrastructure- including haskell.org, Hackage, Hoogle, and GHC build infrastructure. We're able to do this thanks to the support of the Haskell community. In addition to our ongoing work maintaining Haskell community infrastructure, we once again participated in the Google Summer of Code this year, supporting 12 projects. You can read more about the projects here: https://summer.haskell.org/news/2020-10-12-final-results.html As many of you are likely aware, this year also saw some of our community successfully launch a new initiative, the Haskell Foundation. We are thrilled for the Haskell Foundation and congratulate them on their successful launch. Haskell.org is an independent organization, and while we welcome any opportunities to collaborate with the Haskell Foundation, we will continue to pursue our mission of managing and supporting Haskell community infrastructure. If you would like to support Haskell.org in our mission, you can donate via several method, including PayPay and check: https://www.haskell.org/donations/ Haskell.org can also accept donations through employers via Benevity using the unique ID 475236502. Haskell.org is a 501(c)(3) non-profit, so donations may be tax-deductible in your jurisdiction. Another way to help haskell.org is to serve on the committee. We have three positions opening in 2021, and our call for nominations is open through Jan 7th 2021. Please email the committee at committee(a)haskell.org if you would like to nominate yourself or someone else for a position. We look forward to continuing this work with your support in 2021 as well as exploring new projects to improve the Haskell community infrastructure. Best wishes, Rebecca Skinner on behalf of the haskell.org committee.

1 1

cabal build fails: sidebyside
by Gregory Guthrie 22 Dec '20

22 Dec '20

I have a fairly simple Haskell program which I build with cabal, which ends up seemingly successful with an executable (apl.exe). (but what a path(!): . \dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl.exe Running that gives an error: Program 'apl.exe' failed to run: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detailAt line:1 char:1 + ./apl + ~~~~~. At line:1 char:1 + ./apl + ~~~~~ + CategoryInfo : ResourceUnavailable: (:) [], ApplicationFailedException + FullyQualifiedErrorId : NativeCommandFailed Looking in the Windows event viewer, it reports: Activation context generation failed for "...\apl.exe". Error in manifest or policy file "...apl.exe" on line 2. Invalid Xml syntax. Sxstrace did not seem to give any additional information: Begin Activation Context Generation. Input Parameter: Flags = 0 ProcessorArchitecture = AMD64 CultureFallBacks = en-US;en ManifestPath = D:\CS\Courses\CS505 -APL\Labs & Hmwks\Dsem Labs -Haskell Solns\dist-newstyle\build\x86_64-windows\ghc-8.10.1\APL-0.0.1\build\APL\apl.exe AssemblyDirectory = D:\CS\Courses\CS505 -APL\Labs & Hmwks\Dsem Labs -Haskell Solns\dist-newstyle\build\x86_64-windows\ghc-8.10.1\APL-0.0.1\build\APL\ Application Config File = ----------------- INFO: Parsing Manifest File D:\CS\Courses\CS505 -APL\Labs & Hmwks\Dsem Labs -Haskell Solns\dist-newstyle\build\x86_64-windows\ghc-8.10.1\APL-0.0.1\build\APL\apl.exe. INFO: Manifest Definition Identity is (null). ERROR: Line 2: XML Syntax error. ERROR: Activation Context generation failed. End Activation Context Generation. Online some posts suggest installing a current VC_redist - I did that, no relief. Any suggestions on what is causing this, and a fix? Running GCH: 8.10.1 Cabal: 3.2.0.0 Windows 10 Dr. Gregory Guthrie

1 0