- Haskell-Cafe - Haskell.org

What became of James Cook? (Need package update)
by Olaf Klinke 14 Sep '22

14 Sep '22

Dear Café, does anyone happen to know what became of James Cook? (The programmer [1,2] a.k.a. mokus, not the explorer.) On github his last commit was in May. I've been trying to contact him at mokus(a)deepbondi.net three timessince March, but no luck. I'm using his package [3] which does not have a public repo. It needs minor adjustments to comply with the MonadFail change. Currently I have no intentions to properly take over the package, since James does seem to be an active developer generally, but James hasn't answered my request to become a hackage co-maintainer of [3] either. Does anyone know alternative channels to reach James? Or could such a minor adjustment [4] be made by the hackage trustees? Thanks Olaf [1] https://hackage.haskell.org/user/JamesCook [2] https://github.com/mokus0 [3] https://hackage.haskell.org/package/dbf [4] dbf-0.0.0.2 is broken by the removal of "fail" from the Monad class, as src/Database/XBase/Dbf/Structures.hs uses fail in line 61 and binary does not implement MonadFail for its PutM Monad. A quick workaround is to replace the call to fail by error. (Which should be semantically equivalent for the old Control.Monad.fail)

1 0

Build haddock documentation of a cabal project
by coot＠coot.me 12 Sep '22

12 Sep '22

Hello Haskell Cafe Next release of `cabal` and `haddock` will gain the capability of building documentation of a cabal project. A few weeks ago when the PR (https://github.com/haskell/cabal/pull/8162) was still in review I wrote a blog post about it: https://coot.me/posts/cabal-haddock-project.html Cheers, Marcin

2 1

OOPSLA 2023: Round 1 Call for Papers
by Andreea Costea 12 Sep '22

12 Sep '22

======================================================================== PACMPL Issue OOPSLA 2023 Call for Papers OOPSLA 2023 will be held as part of The ACM Conference on Systems, Programming, Languages, and Applications: Software for Humanity (SPLASH'23) October 23-27, 2023, Lisbon, Portugal https://2023.splashcon.org/track/splash-2023-oopsla ======================================================================== ### Important dates ROUND 1: Submission Deadline: Fri Oct 28, 2022 Author Response: Wed Dec 07 - Fri Dec 9 Author Notification: Thu Dec 22 Submission of Revisions: Mon Feb 13 - Fri Feb 24 ROUND 2: Submission Deadline: Fri Apr 14, 2023 Author Response: Wed Jun 14 - Fri Jun 16 Author Notification: Fri Jun 30 Submission of Revisions: Mon Aug 14 - Fri Aug 18 Camera ready: Thu Aug 31 Papers accepted at either of the rounds will be published in the 2023 volume of PACMPL(OOPSLA) and invited to be presented at the SPLASH conference in October 2023. ### Scope The OOPSLA issue of the Proceedings of the ACM on Programming Languages (PACMPL) welcomes papers focusing on all practical and theoretical investigations of programming languages, systems and environments. Papers may target any stage of software development, including requirements, modeling, prototyping, design, implementation, generation, analysis, verification, testing, evaluation, maintenance, and reuse of software systems. Contributions may include the development of new tools, techniques, principles, and evaluations. ### Review Process PACMPL(OOPSLA) has two _rounds_ of reviewing. The final outcome of each round can be one of Accept, Revise or Reject. *Accept*: Accepted papers will appear at the next PACMPL(OOPSLA). *Revise*: Papers in this category are invited to submit a revision to the _next round_ of submissions with a specific set of expectations to be met. When authors resubmit, they should clearly explain how the revisions address the comments of the reviewers. The revised paper will be re-evaluated, and either accepted or rejected. Resubmitted papers will retain the same reviewers throughout the process. *Reject*: Rejected papers will not be included in the 2023 volume of PACMPL(OOPSLA). Papers in this category are not guaranteed a review if resubmitted less than one year from the date of original submission. A paper will be judged to be a resubmission if it is substantially similar to the original submission. The judgment that a paper is a resubmission of the same work and whether, in this case, it will be reviewed or not is at the discretion of the Chair. Obviously, this same policy applies to papers that were rejected for inclusion in the 2022 volume of PACMPL(OOPSLA). Each _round_ of reviewing consists of two _phases_. The first phase evaluates the papers and results in an early notification of Reject, Revise, or Conditional Accept. During the first phase, authors will be able to read their reviews and respond to them. The second phase is restricted to conditionally accepted papers. Authors must make a set of mandatory revisions. The second phase assesses whether the required revisions have been addressed. The outcome can be Accept, Revise or Reject. ### Submissions Submitted papers must be at most **23 pages** in 10 point font. There is no page limit on references. No appendices are allowed on the main paper, instead authors can upload supplementary material with no page or content restrictions, but reviewers may choose to ignore it. Submissions must adhere to the "ACM Small" template available from [the ACM](http://www.acm.org/publications/authors/submissions). Papers are expected to use author-year citations. Author-year citations may be used as either a noun phrase, such as "The lambda calculus was originally conceived by Church (1932)", or a parenthetic phase, such as "The lambda calculus (Church 1932) was intended as a foundation for mathematics". PACMPL uses double-blind reviewing. Authors' identities are only revealed if a paper is accepted. Papers must 1. omit author names and institutions, 2. use the third person when referencing your work, 3. anonymise supplementary material. Nothing should be done in the name of anonymity that weakens the submission; see the DBR FAQ. When in doubt, contact the Review Committee Chairs. Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by [SIGPLAN's Republication Policy](http://www.sigplan.org/Resources/Policies/Republication). Submitters should also be aware of [ACM's Policy and Procedures on Plagiarism](http://www.acm.org/publications/policies/plagiarism_policy). Submissions are expected to comply with the [ACM Policies for Authorship](https://www.acm.org/publications/authors/information-for-author…. ### Artifacts Authors should indicate with their initial submission if an artifact exists, describe its nature and limitations, and indicate if it will be submitted for evaluation. Accepted papers that fail to provide an artifact will be requested to explain the reason they cannot support replication. It is understood that some papers have no artifacts. ### Publication PACMPL is a Gold Open Access journal, all papers will be freely available to the public. Authors can voluntarily cover the article processing charge ($400), but payment is not required. The official publication date is the date the journal are made available in the ACM Digital Library. The journal issue and associated papers may be published up to two weeks prior to the first day of the conference. ### Additional Information Consult FAQ in Call for Papers at: https://2023.splashcon.org/track/splash-2023-oopsla ### Review Committee PC Chair: Mira Mezini (TU Darmstadt) Derek Dreyer (MPI-SWS, DE)- Associate Chair Sophia Drosopolou (Facebook; Imperial College, UK)- Associate Chair Patrick Eugster (USI, Switzerland; Purdue U.)- Associate Chair Shriram Krishnamurthi (Brown University, USA)- Associate Chair Jonathan Aldrich (CMU, USA) Karim Ali (U. Alberta, Canada) Peter Alvaro (UC Santa Cruz, USA) Stefanie Balzer (CMU, USA) Osbert Bastani (U. Penn, USA) Annette Bieniusa (U. Kaiserslautern, Germany) Sebastian Burkhardt (MSR, Switzerland) Satish Chandra (Facebook, USA) James Cheney (University of Edinburgh; Alan Turing Institute, UK) Albert Cohen (Google, France) Wolfgang De Meuter (VUB, BE) Dominique Devriese (KU Leuven, Belgium) Dana Drachsler Cohen (Technion, Israel) Jana Dunfield (Queen’s University in Kingston, Ontario, CA) Sebastian Erdweg (U. Mainz, Germany) Matthew Flatt (U. Utah, USA) Jeremy Gibbons (U. Oxford, UK) Anitha Gollamudi (UMass, USA) Elisa Gonzalez Boix (VUB, Belgien) Andrew Gordon (MS Research, Edinburgh, UK) Dan Grossman (U. Washington, USA) Arjun Guha (Northeastern U., USA) Philipp Haller (KTH, Sweden) Görel Hedin (Lund University, Sweden) Steven Holtzen (Northeastern U., USA) Justin Hsu (Cornell University, USA) Atsushi Igarashi (Kyoto U., Japan) Ranjit Jhala (UC San Diego, USA) Gowtham Kaki (U. Colorado, USA) Neel Krishnaswami (Cambridge, UK) Burcu Kulahcioglu Ozkan (Delft University of Technology, The Netherlands) Sorin Lerner (UCSD, USA) Hongjin Liang (Nanjing University, CN) Crista Lopes (UC Irvine, USA) Kenji Maillard (Inria Nantes & University of Chile) Hidehiko Masuhara (Tokyo Institute of Technology, Japan) Ana Milanova (Rensselaer Polytechnic Institute) Heather Miller (CMU, USA) Ragnar Mogk (TU Darmstadt, DE) Anders Møller (Aarhus U,, Danemark) Fabrizio Montesi (Univ. of Southern Denmark, Denmark) Sarah Nadi (U. Alberta, Canada) James Noble (U. Wellington, New Zealand) Bruno C. d. S. Oliveira (U. Hong Kong, Hong Kong) Klaus Ostermann (U. Tübingen, Germany) Mangpo Phothilimthana (Google Brain, USA) Benjamin Pierce (UPenn, USA) Nadia Polikarpova (UC San Diego, USA) Michael Pradel (U. Stuttgart, Germany) Shaz Qadeer (Facebook, USA) Marianna Rapoport (Amazon Web Services, Canada) Cindy Rubio-González (UC Davis, USA) Sukyoung Ryu (KAIST, Korea) Guido Salvaneschi (U. St. Gallen, Switzerland) Mark Santolucito (Columbia, USA) Ilya Sergey (National University of Singapore, Singapore) Armando Solar-Lezama (MIT, USA) Manu Sridharan (University of California, USA) Charles Sutton (Google, UK) Joseph Tassarotti (New York University, USA) Ross Tate (Cornell U., USA) Peter Thiemann (U. Freiburg, Germany) Bernardo Toninho (Universidade Nova de Lisboa, Portugal) Viktor Vafeiadis (MPI, Germany) Tijs van der Storm (CWI; University of Groningen, Netherlands) Vasco Vasconcelos (U. Lisbon, Portugal) Jan Vitek (Northeastern U./Czech Technical University) Dimitrios Vytiniotis (DeepMind, UK) David Walker (Princeton, USA) Conrad Watt (U. Cambridge, UK) Pascal Weisenburger (U. St. Gallen, Switzerland) Qirun Zhang (Gatech, USA)

1 0

Combine pattern synonyms and record wild cards
by rowan goemans 12 Sep '22

12 Sep '22

Hello all, I'm playing with pattern synonyms to create a more intuitive API. Essentially what I would like is to allow a record wild card through a pattern synonym. Allow me to illustrate with an example. I have a data type. `data Foo a = Foo { unFoo :: a }` and a type `FooMaybe a = Maybe (Foo a)`. Now I have a pattern synonym `pattern FooJust x = Just (Foo x)`. This works and I can match on it no problem. But by doing this I lose the ability to use RecordWildCards. I can do this `myFun (Just Foo{..}) but not this `myFun FooJust{..}`. Is there some way to use pattern synonym while preserving the ability of using record wild cards? Best regards, Rowan Goemans

1 0

Re: [Haskell-cafe] Generic "annotations" on type definitions
by Olaf Klinke 11 Sep '22

11 Sep '22

> Hello all, > > I was recently thinking about a generic programming application > (auto-generating UI code from data definitions) that would benefit from the > ability to "annotate" data definitions. For example, let's say you have a > type > > data Foo = Foo {barred :: Boolean} > > You are (auto-)generating a UI to display and manipulate `Foo`s. Perhaps > the generic UI code defaults to making a check-box for Boolean values, but > you would rather have it be a radio button. It would be advantageous to be > able to write something like e.g. > > data Foo = Foo {barred :: Boolean # RenderMode RadioButton} > > In many languages, you have the ability to annotate data fields in a way > which has no bearing whatsoever on the first-order behavior or > representation of the type, and is only reflected via the language's > generic programming API. For example, in Java, you have > > class Foo { > @RenderMode(RadioButton) > bool barred; > } > > And in Rust, you have > struct Foo { > #[render_mode(radio_button)] > barred : bool > } > > In Haskell, I do not believe we have any such system in place for > interfacing with Generics. > > The closest I am familiar with is from the optparse-generic package, where > you write code of the form > > data Foo w = Foo {barred :: w ::: Boolean <?> RenderMode RadioButton} > > See > https://hackage.haskell.org/package/optparse-generic-1.4.8/docs/Options-Gen…:: > :: > > This is basically a clever way to sort of re-create what we have available > in Rust or Java, using type families, but with the annoying downside that > it makes interacting with your type in normal code much more cumbersome, > and is also relatively confusing to read and write. > > Compare Rust's Clap package, which is very similar to optparse-generic, but > more convenient to work with because the annotations don't impact normal > usage of the type. > > See https://docs.rs/clap/latest/clap/#example > > Would it be technically feasible to add such a thing to GHC's Generics > support? I could imagine something like updating the GHC.Generics Meta > type's MetaCons constructor to > > MetaCons Symbol FixityI Bool *[Annotation]* > > Best, > Will Why not use special syntax in comments, like we do for Haddock, doctests etc. data Foo = Foo { barred :: Boolean -- ^ #GUI[RenderMode RadioButton] } There is a functional language capable of auto-generating input forms: Clean https://clean.cs.ru.nl/Clean with the iTask library on top. It can also generate forms for recursive types. The Dutch coast guard uses it to interactively design queries to a database of marine vessel movements. It'd be cool if Haskell's Generics also could do that. Olaf

3 3

Generic "annotations" on type definitions
by William Yager 09 Sep '22

09 Sep '22

Hello all, I was recently thinking about a generic programming application (auto-generating UI code from data definitions) that would benefit from the ability to "annotate" data definitions. For example, let's say you have a type data Foo = Foo {barred :: Boolean} You are (auto-)generating a UI to display and manipulate `Foo`s. Perhaps the generic UI code defaults to making a check-box for Boolean values, but you would rather have it be a radio button. It would be advantageous to be able to write something like e.g. data Foo = Foo {barred :: Boolean # RenderMode RadioButton} In many languages, you have the ability to annotate data fields in a way which has no bearing whatsoever on the first-order behavior or representation of the type, and is only reflected via the language's generic programming API. For example, in Java, you have class Foo { @RenderMode(RadioButton) bool barred; } And in Rust, you have struct Foo { #[render_mode(radio_button)] barred : bool } In Haskell, I do not believe we have any such system in place for interfacing with Generics. The closest I am familiar with is from the optparse-generic package, where you write code of the form data Foo w = Foo {barred :: w ::: Boolean <?> RenderMode RadioButton} See https://hackage.haskell.org/package/optparse-generic-1.4.8/docs/Options-Gen…:: :: This is basically a clever way to sort of re-create what we have available in Rust or Java, using type families, but with the annoying downside that it makes interacting with your type in normal code much more cumbersome, and is also relatively confusing to read and write. Compare Rust's Clap package, which is very similar to optparse-generic, but more convenient to work with because the annotations don't impact normal usage of the type. See https://docs.rs/clap/latest/clap/#example Would it be technically feasible to add such a thing to GHC's Generics support? I could imagine something like updating the GHC.Generics Meta type's MetaCons constructor to MetaCons Symbol FixityI Bool *[Annotation]* Best, Will

3 2

[ANN] Copilot 3.11 -- hard realtime C runtime verification
by Ivan Perez 08 Sep '22

08 Sep '22

Dear all, We are very happy to announce the release of Copilot 3.11. Copilot is a runtime verification system implemented as a Haskell DSL that generates hard-realtime C99. Among others, Copilot is being used by the Safety Critical Avionics Systems Branch of NASA Langley Research Center for monitoring test flights of drones. You can learn more about it at [1]. Copilot 3.11 introduces a new library, copilot-interpreter, that isolates all functions related to simulation of Copilot specifications. The release also contains a number of bug fixes, provides a simplified API, deprecates outdated elements, removes unused code, and introduces support for GHC 9.2. A full list of changes merged is available at [2]. A substantial effort is being made to achieve NASA's Class D software classification, most notably in terms of development process (which you can partly witness in how issues and PRs are being handled on our github repo), test coverage (mostly with quickcheck), and proofs of correctness of the generated code (with what4). Copilot is being used by the Safety-Critical Avionics Systems Branch (D320) of NASA Langley Research Center to conduct experiments related to flight safety of aerial vehicles. We have also built Ogma [3], a tool that allows us to generate full monitoring applications (e.g., NASA's Core Flight System [4] and Robot Operating System [5] applications) from requirements in structured natural language. We invite you all to explore Copilot, to try it, and to extend it. If you like it, please help us draw attention to this work with a star on github or a mention online. Happy Haskelling, The Copilot Team [1] https://github.com/Copilot-Language/copilot [2] https://github.com/Copilot-Language/copilot/milestone/15?closed=1 [3] https://github.com/nasa/ogma [4] https://cfs.gsfc.nasa.gov/ [5] https://www.ros.org/

1 0

any advice for tracking down a failure to compile (it just hangs) with ghc 9.2.4?
by Doug Burke 06 Sep '22

06 Sep '22

I have noticed I can't run one of my tests when building with ghc 9.2.4 (tried via stack and nix) that doesn't happen with ghc 9.2.3 (or older versions). Is there a way to diagnose the problem (so I can look at the ghc bug tracker or try and make the code smaller for testing)? I can see this behavior with the following reproducer (it's a bit heavyweight at the moment!): % git clone https://gitlab.com/dburke/swish temp % cd temp Added to get the timings, but it's not strictly necessary: % sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal Now try to build and run the test. The following build and run the test quickly if using an older GHC (e.g. "--resolver lts" for the stack case or "--argstr compiler ghc923" for the nix case). First with stack % sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal % stack test --resolver nightly-2022-09-05 :test-rdfproof Stack has not been tested with GHC versions above 9.0, and using 9.2.4, this may fail Stack has not been tested with Cabal versions above 3.4, but version 3.6.3.0 was found, this may fail swish> configure (lib + test) Configuring swish-0.10.2.0... swish> build (lib + test) Preprocessing library for swish-0.10.2.0.. Building library for swish-0.10.2.0.. Preprocessing test suite 'test-rdfproof' for swish-0.10.2.0.. Building test suite 'test-rdfproof' for swish-0.10.2.0.. *** initializing unit database: initializing unit database: alloc=7350056 time=8.753 *** initializing unit database: initializing unit database: alloc=3999144 time=16.194 *** Chasing dependencies: *** systool:cpp: systool:cpp: alloc=271104 time=1.991 Chasing dependencies: alloc=10233768 time=8.400 [2 of 2] Compiling Main *** Parser [Main]: Parser [Main]: alloc=24346344 time=33.067 *** Renamer/typechecker [Main]: Renamer/typechecker [Main]: alloc=101896128 time=134.992 *** Desugar [Main]: Desugar [Main]: alloc=24628816 time=24.813 *** Simplifier [Main]: Simplifier [Main]: alloc=667236400 time=775.137 *** Specialise [Main]: Specialise [Main]: alloc=45057312 time=40.543 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: alloc=208806472 time=330.396 *** Simplifier [Main]: Simplifier [Main]: alloc=603245992 time=747.067 *** Simplifier [Main]: Simplifier [Main]: alloc=564322584 time=709.583 *** Simplifier [Main]: Simplifier [Main]: alloc=728039528 time=835.525 *** Float inwards [Main]: *** Called arity analysis [Main]: *** Simplifier [Main]: Float inwards [Main]: alloc=23720 time=0.017 Called arity analysis [Main]: alloc=25848 time=0.016 Progress 0/2 Now with nix % nix-shell --argstr compiler ghc924 ... wait an indeterminate amount of time % ghc --version The Glorious Glasgow Haskell Compilation System, version 9.2.4 % cabal test test-rdfproof Warning: The package list for 'hackage.haskell.org' is 19 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... Build profile: -w ghc-9.2.4 -O1 In order, the following will be built (use -v for more details): - swish-0.10.2.0 (lib) (first run) - swish-0.10.2.0 (test:test-rdfproof) (first run) Configuring library for swish-0.10.2.0.. Preprocessing library for swish-0.10.2.0.. Building library for swish-0.10.2.0.. [ 1 of 55] Compiling Data.Interned.URI [ 2 of 55] Compiling Data.Ord.Partial [ 3 of 55] Compiling Data.String.ShowLines [ 4 of 55] Compiling Network.URI.Ord [ 5 of 55] Compiling Swish.GraphClass ... ... a lot more, including some annoying non-exhaustive patterns I don't know how to fix ... but that's for a different post ... [55 of 55] Compiling Swish Configuring test suite 'test-rdfproof' for swish-0.10.2.0.. Preprocessing test suite 'test-rdfproof' for swish-0.10.2.0.. Building test suite 'test-rdfproof' for swish-0.10.2.0.. *** initializing unit database: initializing unit database: alloc=7389248 time=4.436 *** initializing unit database: initializing unit database: alloc=4001312 time=11.992 *** Chasing dependencies: *** systool:cpp: systool:cpp: alloc=319464 time=0.520 Chasing dependencies: alloc=12863280 time=6.581 [1 of 2] Compiling TestHelpers ( tests/TestHelpers.hs, /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/TestHelpers.o ) *** Parser [TestHelpers]: Parser [TestHelpers]: alloc=5469952 time=2.325 *** Renamer/typechecker [TestHelpers]: Renamer/typechecker [TestHelpers]: alloc=94049744 time=106.001 *** Desugar [TestHelpers]: Desugar [TestHelpers]: alloc=5551840 time=2.974 *** Simplifier [TestHelpers]: Simplifier [TestHelpers]: alloc=45720248 time=28.537 *** Specialise [TestHelpers]: Specialise [TestHelpers]: alloc=2198344 time=0.717 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [TestHelpers]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [TestHelpers]: alloc=6183280 time=3.109 *** Simplifier [TestHelpers]: Simplifier [TestHelpers]: alloc=27272104 time=16.042 *** Simplifier [TestHelpers]: Simplifier [TestHelpers]: alloc=20805544 time=12.332 *** Simplifier [TestHelpers]: Simplifier [TestHelpers]: alloc=6175584 time=2.825 *** Float inwards [TestHelpers]: Float inwards [TestHelpers]: alloc=26272 time=0.012 *** Called arity analysis [TestHelpers]: Called arity analysis [TestHelpers]: alloc=28392 time=0.012 *** Simplifier [TestHelpers]: Simplifier [TestHelpers]: alloc=14755744 time=7.017 *** Demand analysis [TestHelpers]: Demand analysis [TestHelpers]: alloc=2061096 time=1.296 *** Constructed Product Result analysis [TestHelpers]: Constructed Product Result analysis [TestHelpers]: alloc=466968 time=0.197 *** Worker Wrapper binds [TestHelpers]: Worker Wrapper binds [TestHelpers]: alloc=436552 time=0.201 *** Simplifier [TestHelpers]: Simplifier [TestHelpers]: alloc=31897488 time=18.652 *** Exitification transformation [TestHelpers]: Exitification transformation [TestHelpers]: alloc=29808 time=0.013 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [TestHelpers]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [TestHelpers]: alloc=5508568 time=4.009 *** Common sub-expression [TestHelpers]: Common sub-expression [TestHelpers]: alloc=27896 time=0.013 *** Float inwards [TestHelpers]: Float inwards [TestHelpers]: alloc=26272 time=0.021 *** Simplifier [TestHelpers]: Simplifier [TestHelpers]: alloc=24835440 time=15.291 *** Demand analysis [TestHelpers]: Demand analysis [TestHelpers]: alloc=2214560 time=1.044 *** CoreTidy [TestHelpers]: CoreTidy [TestHelpers]: alloc=2814672 time=1.457 *** CorePrep [TestHelpers]: CorePrep [TestHelpers]: alloc=1965920 time=2.636 *** CoreToStg [TestHelpers]: CoreToStg [TestHelpers]: alloc=3134560 time=1.484 *** CodeGen [TestHelpers]: CodeGen [TestHelpers]: alloc=80232584 time=46.410 *** WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/TestHelpers.hi]: WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/TestHelpers.hi]: alloc=1780688 time=0.766 *** systool:as: systool:as: alloc=137200 time=0.360 [2 of 2] Compiling Main ( tests/RDFProofTest.hs, /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o ) *** Parser [Main]: Parser [Main]: alloc=25235720 time=8.851 *** Renamer/typechecker [Main]: Renamer/typechecker [Main]: alloc=58415520 time=45.291 *** Desugar [Main]: Desugar [Main]: alloc=22098688 time=46.709 *** Simplifier [Main]: Simplifier [Main]: alloc=654052760 time=511.390 *** Specialise [Main]: Specialise [Main]: alloc=44439912 time=34.132 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: alloc=208317448 time=252.154 *** Simplifier [Main]: Simplifier [Main]: alloc=601002912 time=546.343 *** Simplifier [Main]: Simplifier [Main]: alloc=564371608 time=546.970 *** Simplifier [Main]: Simplifier [Main]: alloc=726902400 time=613.423 *** Float inwards [Main]: Float inwards [Main]: alloc=23720 time=0.024 *** Called arity analysis [Main]: Called arity analysis [Main]: alloc=25856 time=0.013 *** Simplifier [Main]: At this point my laptop just sits there making whooshing noises as if it's trying to become an aeroplane, but it never gets to where it's going (to mix up my metaphors). Any help would be appreciated, Doug

2 2

Getting a breakdown of time spend in compile phases
by rowan goemans 04 Sep '22

04 Sep '22

Dear Cafe, I have a Haskell Project where I have a module that quite heavily makes use of constraints and takes ages to compile per module. It also uses some type checker plugins but I'm unsure if they are causing the slowness. So what I would like to see is a breakdown of how much time GHC is spending on compilation of a module. Does something like this exist? Best regards, Rowan Goemans

5 6

[ANN] xmonad and xmonad-contrib 0.17.1 are available
by Tony Zorman 03 Sep '22

03 Sep '22

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ XMONAD AND XMONAD-CONTRIB 0.17.1 ARE AVAILABLE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ New versions of xmonad and xmonad-contrib have been released. Check out our [download page] for instructions on where to get them. About 10 months after the big release of 0.17.0, we—as promised—picked up the pace a bit and are back with a new minor version; don't let that fool you though, this one still packs a punch! Plus, we now sport a brand-new [logo], courtesy of [Hans Heintze]. As this is a minor release, we tried to keep the breaking changes to a minimum (xmonad core does not have a single one!) However, some were unavoidable for `xmonad-contrib', so be sure to at least glance at the [release notes]! For help getting started—or more info—see [our website] and [talk to us]! If you like what we do, you can support us on [Open Collective] or via [GitHub Sponsors]. Thanks! [GitHub Sponsors] <https://github.com/sponsors/xmonad> [Hans Heintze] <https://github.com/literallyunplayable> [Open Collective] <https://opencollective.com/xmonad> [download page] <https://xmonad.org/download.html> [logo] <https://xmonad.org/images/logo.svg> [our website] <https://xmonad.org/> [release notes] See section 2 [talk to us] <https://xmonad.org/community.html> 1 xmonad 0.17.1 ═══════════════ This release includes 32 non-merge commits by 6 contributors! For a full summary of all the changes, see [xmonad's CHANGES.md] file. [xmonad's CHANGES.md] <https://github.com/xmonad/xmonad/blob/v0.17.1/CHANGES.md> 1.1 Enhancements ──────────────── • Added custom cursor shapes for resizing and moving windows. 1.2 Bug Fixes ───────────── • Change the main loop to try to avoid [GHC bug 21708] on systems running GHC 9.2 up to version 9.2.3. The issue has been fixed in [GHC 9.2.4] and all later releases. • Fixed border color of windows with alpha channel. Now all windows have the same opaque border color. [GHC bug 21708] <https://gitlab.haskell.org/ghc/ghc/-/issues/21708> [GHC 9.2.4] <https://discourse.haskell.org/t/ghc-9-2-4-released/4851> 2 xmonad-contrib 0.17.1 ═══════════════════════ This release includes 212 non-merge commits by 32 contributors! For a full summary of all the changes, see [xmonad-contrib's CHANGES.md] file. [xmonad-contrib's CHANGES.md] <https://github.com/xmonad/xmonad-contrib/blob/v0.17.1/CHANGES.md> 2.1 Breaking Changes ──────────────────── • `XMonad.Config.{Arossato,Dmwit,Droundy,Monad,Prime,Saegesser,Sjanssen}': deprecated all of these modules. The user-specific configuration modules may still be found [on the website]. • `XMonad.Util.NamedScratchpad': scratchpads are now only based on the argument given to `namedScratchpadManageHook'; all other scratchpad arguments are, while still present, ignored. Users passing all of their scratchpads to functions like `namedScratchpadAction' (as is shown in the module's documentation) should /not/ notice any difference in behaviour. • `XMonad.Util.DynamicScratchpads': deprecated the module; use the new dynamic scratchpad functionality of `XMonad.Util.NamedScratchpad' instead. • `XMonad.Hooks.UrgencyHook': deprecated `urgencyConfig'; use `def' from the new `Default' instance of `UrgencyConfig' instead. [on the website] <https://xmonad.org/configurations.html> 2.2 New Modules ─────────────── • `XMonad.Hooks.Modal': a module implementing modal keybindings for XMonad. • `XMonad.Layout.SideBorderDecoration': this module allows for having a configurable border position around windows; i.e., it can move the border to either cardinal direction. • `XMonad.Actions.PerLayoutKeys': a new module for customising keybindings on a per-layout basis. • `XMonad.Actions.RepeatAction': a module for adding a keybinding to repeat the last action, similar to Vim's `.' or Emacs's `dot-mode'. 2.3 Bug Fixes and Minor Changes ─────────────────────────────── • `XMonad.Prompt' and `XMonad.Actions.TreeSelect': added xft-based font fallback support. This may be used by appending other fonts to the given string: `xft:iosevka-11,FontAwesome-9'. Note that this requires `xmonad-contrib' to be compiled with `X11-xft' version 0.3.4 or higher. • `XMonad.Util.Run': added an EDSL—particularly geared towards programs like terminals or Emacs—to spawn processes from XMonad in a compositional way. • `XMonad.Util.Hacks': added `trayerPaddingXmobarEventHook' (plus generic variants for other trays/panels) to communicate trayer resize events to xmobar so that padding space may be reserved on xmobar for the tray. Requires `xmobar' version 0.40 or higher. • `XMonad.Prompt.OrgMode': added the ability to specify alphabetic (`#A', `#B', and `#C') [priorities] at the end of the input note. • `XMonad.Actions.Submap': added `visualSubmap' to visualise the available keys and their actions when inside a submap. • `XMonad.Util.NamedScratchpad': added support for dynamic scratchpads in the form of `dynamicNSPAction' and `toggleDynamicNSP'. • `XMonad.Hooks.WindowSwallowing': fixed windows getting lost when used in conjunction with `smartBorders' and a single window. [priorities] <https://orgmode.org/manual/Priorities.html> -- Tony Zorman | https://tony-zorman.com/

1 0