November 2021 - Haskell-Cafe

[ANN] cabal-clean (new tool)
by Andreas Abel 19 Aug '22

19 Aug '22

=== Wondering where your disk space goes with too many Haskell projects compiled with too many GHC versions? === https://hackage.haskell.org/package/cabal-clean https://github.com/andreasabel/cabal-clean `cabal-clean` is a small executable that removes outdated cabal build artifacts from `dist-newstyle`. A build tree is considered outdated if there is one with either - a newer version of the package you are building, or - a newer minor version of the GHC compiler. In contrast to `cabal clean`, the tool `cabal-clean` retains the latest build trees for each GHC major version. Thus, it is geared towards multi-GHC development. Example: (self-applied to cabal-clean's build directory) --- 3.7M ghc-8.8.4 /cabal-clean-0.1.20210815 --- 3.5M ghc-8.10.6/cabal-clean-0.1.20210815 --- 3.7M ghc-9.0.1 /cabal-clean-0.1.20210815 --- 3.5M ghc-8.10.6/cabal-clean-0.1.20210924 +++ 3.6M ghc-8.10.7/cabal-clean-0.1.20210924 +++ 3.7M ghc-9.0.1 /cabal-clean-0.1.20210924 The directories prefixed with --- will be deleted, the ones with +++ retained. Disclaimers: 1. cabal-clean does not check whether deletion will cause dangling references like broken symlinks etc. (Could happen if you created a symlink to an executable that resides in one of the deleted build directories.) 2. cabal-clean does not read nor utilize information from the .cabal file. 3. Calls `du` ("disk usage"), so, might not work on Windows. Enjoy, Andreas

6 6

Some Love for wxHaskell
by Tilmann 30 Jan '22

30 Jan '22

Hi cafe, I think wxHaskell needs some love :) Over the years I've written a small client for FICS (Free Internet Chess Server) and wxHaskell has served me really well. Also, wxWidgets seems solid and alive.. but today, wxHaskell is lagging behind updates and seems *sniff* dead. Is someone working on wxHaskell atm? I'd love to connect and help. If not, is there some interest to rejuvenate wxHaskell? Who is also depending on wxHaskell and wants to keep it going? Or, is it time to move on to gtk or reflex? Very much looking forward to your replies! Best, Tilmann

3 4

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

Logging
by Hilco Wijbenga 08 Dec '21

08 Dec '21

Hi all, I just started using "logging" (https://hackage.haskell.org/package/logging) which is based on "fast-logger" (https://hackage.haskell.org/package/fast-logger) It all works fine except that the timestamp in the log message is output as UTC. I would like it to use my local (i.e. system) TZ. I tried setting the TZ environment variable explicitly (before invoking my main) and by setting it in code (System.Environment.setEnv) but it doesn't make any difference. I did not find anything in either API about this so I'm out of ideas. If this is simply impossible, does anyone have a recommendation for another logging package? Cheers, Hilco

11 18

Re: [Haskell-cafe] Breaking change to Eq accepted by Core Libraries Committee
by Olaf Klinke 03 Dec '21

03 Dec '21

For what it's worth, one of the examples listed in the issue where (/=) is not simply the negation of (==) is violating the laws. It is the one in https://hackage.haskell.org/package/numbers-3000.2.0.2/docs/Data-Number-Int… That module defines two intervals to be equal if their bounds are equal, but to be unequal only if they are disjoint. In my eyes this speaks for the proposal, because the library author would have been unable to write the broken instance. (And I did look at the proposal some time ago, whence I feel it was indeed discussed or at least mentioned on this list before.) Olaf

6 7

What is Data.Vec.DataFamily.SpineStrict.Pigeonhole and why is it following me?
by Galaxy Being 01 Dec '21

01 Dec '21

Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: This <https://hackage.haskell.org/package/vec-0.4/docs/Data-Vec-DataFamily-SpineS…> in Hackage is something a rank amateur like me can't fathom. I just hit a chapter in a book that dives into the Pigeonhole Principle. Is this the "accompanying Haskell Wundercode" for the math world's PHP? I know PHP is a big deal in math. I don't see an "author," and I see no documentation. Anyone know how I can figure this mystery out, like at least find the author or someone that knows something about this? [...] Content analysis details: (5.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (borgauf[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 BAYES_40 BODY: Bayes spam probability is 20 to 40% [score: 0.3039] 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

3 2

MonadFail with type parameter for error message
by Daneel Yaitskov 30 Nov '21

30 Nov '21

Dear Cafe, MonadFail.fail takes String. I wasn't able to find MonadFail for custom error type. Is there any proposals to base? Let's say Data.Text, which gains popularity with OverloadedStrings extensions. class MonadFail m where fail :: String -> m a Why not ? class MonadFail m where fail :: (forall s. IsString s => s) -> m a class MonadFailWith m s where fail :: s -> m a -- Best regards, Daniil Iaitskov

3 3

Re: [Haskell-cafe] methods/tools for reading/presenting (time/allocation) profiling information?
by Olaf Klinke 26 Nov '21

26 Nov '21

> Dear Cafe, > > with +RTS -p -RTS, the resulting .prof file > shows (in the second part) what the expensive functions are. > (counting sections as GHC docs do - > first part gives program name and options) > > Often, that's useful, but sometimes, this info does not surprise me - > some things just don't have an easy implementation. > For those, I want to find out who calls them - > to possibly replace some of these calls > with a cheaper implementation (that is only valid > because the caller knows something that the callee does not) > > Is there some automation for getting this information? > I am not even sure how to formalize what I want. > Perhaps, for the first N heavy cost centers (SCCs), > a suitably ordered list of their callers (that inherit the cost)? > > The data is in the third (long, detailed) part of the .prof file > but I find it hard to process (in that form). It represents > the call hiearchy by indentation (first column) and adjacency (of rows) > but this goes out the window as soon as I grep or sort the rows. > > The JSON output format seems the way to go > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.h… > . > Yeah, I should probably just aeson it and then walk the tree. > I still wanted to ask for advice first, or references > to existing work. Any pointers appreciated. > > - J. > Profiteur has served me well in this regard. It shows me what top-level functions eat most of the execution times, and which sub-functions have the biggest share thereof, etc. All in a nice interactive browser interface. https://hackage.haskell.org/package/profiteur Olaf

1 0

methods/tools for reading/presenting (time/allocation) profiling information?
by Johannes Waldmann 25 Nov '21

25 Nov '21

Dear Cafe, with +RTS -p -RTS, the resulting .prof file shows (in the second part) what the expensive functions are. (counting sections as GHC docs do - first part gives program name and options) Often, that's useful, but sometimes, this info does not surprise me - some things just don't have an easy implementation. For those, I want to find out who calls them - to possibly replace some of these calls with a cheaper implementation (that is only valid because the caller knows something that the callee does not) Is there some automation for getting this information? I am not even sure how to formalize what I want. Perhaps, for the first N heavy cost centers (SCCs), a suitably ordered list of their callers (that inherit the cost)? The data is in the third (long, detailed) part of the .prof file but I find it hard to process (in that form). It represents the call hiearchy by indentation (first column) and adjacency (of rows) but this goes out the window as soon as I grep or sort the rows. The JSON output format seems the way to go https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.h… . Yeah, I should probably just aeson it and then walk the tree. I still wanted to ask for advice first, or references to existing work. Any pointers appreciated. - J.

2 1

Logging
by Olaf Klinke 22 Nov '21

22 Nov '21

Dear Hilco, attached is a module we use in production. It builds on top of the monad-logger package which is used, among other places, in Yesod. Olaf

1 0