From dcsarpi at nus.edu.sg Fri Jul 1 11:54:54 2022 From: dcsarpi at nus.edu.sg (Arpita Dutta) Date: Fri, 1 Jul 2022 11:54:54 +0000 Subject: [Haskell-cafe] Call for Reviewers APLAS 2022 Artifact Evaluation Committee Message-ID: Dear all, The /20th Asian Symposium on Programming Languages and Systems/ (APLAS'22) is going to be holding its first /Artifact Evaluation Committee/ (AEC). The artifact evaluation process aims to promote, share, and catalogue the research artifacts of papers accepted to the APLAS research track. We are looking for motivated researchers at all academic stages (Ph.D. Students, Researchers, Lecturers, & Professors) to join us on the inaugural APLAS'22 AEC. The self-nomination form is available at: https://forms.gle/rJREG9DiFQHegZmD9 To nominate other people please use the following form: https://forms.gle/KFiQYLjELMsEjGLp8 ​ As a committee member, your primary responsibility will be to review artifacts submitted by authors of accepted papers and ensure that the artifact is a faithful representation of the accepted paper's results. This will involve interacting with some tooling provided by the authors, check if the results of the main paper are consistent with the claims in the paper, and are also reproducible for researchers to come. APLAS will use a three-phase artifact review process: Kick-The-Tyres; Review the Artifact; and Iron-out-the-Wrinkles. Reviewing guidance for committee members will be made available once the committee has been formed. We will close nominations on: Friday 08 July 2022 (AOE) and notify the selected committee members on: Friday 15 July 2022 (AOE) We expect most of the reviewing process to be performed between 22nd August 2022 and 19th September 2022. We expect each artifact to take around eight hours to review and we will look to assign each reviewer three to four reviews. For each artifact, we will assign a Lead Reviewer to lead the reviewing process. Salient information about the reviewing process can be found online: ​ https://2022.splashcon.o​rg/tr​ack/aplas-2022-aec#Reviewer-Information Come join us to improve the quality of research in our field! Thanks​ Arpita Dutta and Jan de Muijnck-Hughes APLAS'22 AEC Co-Chairs. This call was adapted from the PLDI'22 AEC Call for Nominations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anandc at mcmaster.ca Mon Jul 11 20:40:54 2022 From: anandc at mcmaster.ca (Anand, Christopher) Date: Mon, 11 Jul 2022 20:40:54 +0000 Subject: [Haskell-cafe] mastered Haskell and need a new challenge??? Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1657552180820.jpeg Type: image/jpeg Size: 41979 bytes Desc: 1657552180820.jpeg URL: From ivanperezdominguez at gmail.com Tue Jul 12 11:09:47 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Tue, 12 Jul 2022 07:09:47 -0400 Subject: [Haskell-cafe] Folding nested foldables -- Known pattern? Message-ID: 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: Hi café TL;DR: In Copilot, we have an ad-hoc notion of a nestable data structure that can be folded into a list. I'm trying to rely on standard classes as much as possible. Is there a known class to capture the idea of folding nested data structures (e.g., transitive foldable?) [...] 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 (ivanperezdominguez[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.2680] 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. -------------- next part -------------- An embedded message was scrubbed... From: Ivan Perez Subject: Folding nested foldables -- Known pattern? Date: Tue, 12 Jul 2022 07:09:47 -0400 Size: 19358 URL: From ivanperezdominguez at gmail.com Tue Jul 12 11:43:32 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Tue, 12 Jul 2022 07:43:32 -0400 Subject: [Haskell-cafe] ANN: Copilot 3.10 Message-ID: Dear all, We are very happy to announce the release of Copilot 3.10. Copilot is a runtime verification system implemented as a Haskell DSL that generates hard-realtime C99. You can learn more about it at [1]. This new version of Copilot contains a small but important change in how structs are handled in C functions invoked by the monitors when property violations are detected. This change is API-breaking, so users of Copilot may need to adapt their systems accordingly. The release also contains a number of bug fixes, provides a simplified API, deprecates outdated elements, removes unused code, and relaxes version constraints for dependencies. 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] applications) from requirements in structured natural language. We'd like to take this opportunity to welcome Will Pogge to the team with his first commit, and thank the Galois team for their contributions. We also want to thank everyone who uses and helps promote Copilot; we are seeing increased attention, and gave three talks in the last two months at JPL, USC, and VCU, with two more taking place this month. 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/14?closed=1 [3] https://github.com/nasa/ogma [4] https://cfs.gsfc.nasa.gov/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Tue Jul 12 12:36:22 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 12 Jul 2022 13:36:22 +0100 Subject: [Haskell-cafe] Folding nested foldables -- Known pattern? In-Reply-To: References: Message-ID: Does this help? (Foldable f, Foldable g) => Foldable (Compose f g) https://www.stackage.org/haddock/lts-19.15/base-4.15.1.0/Data-Functor-Compose.html#t:Compose On Tue, Jul 12, 2022 at 07:09:47AM -0400, Ivan Perez wrote: > TL;DR: In Copilot, we have an ad-hoc notion of a nestable data structure > that can be folded into a list. I'm trying to rely on standard classes as > much as possible. Is there a known class to capture the idea of folding > nested data structures (e.g., transitive foldable?) From lemming at henning-thielemann.de Fri Jul 15 07:21:36 2022 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 15 Jul 2022 09:21:36 +0200 (CEST) Subject: [Haskell-cafe] stack and package candidates Message-ID: <66cb1417-83c-9f4f-4f9a-4cc71ef224c2@henning-thielemann.de> In a project my stack.yaml contains this line: - url: https://hackage.haskell.org/package/foobar-0.0/candidate/foobar-0.0.tar.gz This works, but if I update the foobar release candidate then Stack will not notice and stick to the old version. How can I invalidate or remove the cached foobar version? From johannes.riecken at gmail.com Fri Jul 15 08:49:45 2022 From: johannes.riecken at gmail.com (Johannes Riecken) Date: Fri, 15 Jul 2022 10:49:45 +0200 Subject: [Haskell-cafe] What is the exponential version of dependently-typed Vector and Tensor? Message-ID: I noticed that the definitions of Vector and Tensor have a parallel structure. Vector is an ornamentation of the Peano natural numbers, and Tensor is the parallel construction with multiplication and the multiplicative identity, except that the factors are stored in a list instead of directly multiplying, so that the dependent typing can ensure that the number of elements in the tensor is indeed equal to the product of these factors. (To make it more parallel, the Nat in Vector could be replaced with a list of ones.) ```haskell {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} import GHC.TypeLits import Data.Kind import Numeric.Natural import Data.Proxy data Vector (n :: Nat) a where Nil :: Vector 0 a Cons :: a -> Vector n a -> Vector (n + 1) a data Tensor :: forall n. Vector n Nat -> Type -> Type where Scalar :: a -> Tensor Nil a Dimension :: Vector n (Tensor d a) -> Tensor (Cons n d) a ``` That made me wonder what the exponential version with functions would look like and if that is a useful concept, too, or one that also exists in maths? As going from Vector to Tensor isn't completely mechanical, I had trouble figuring out myself how to go from Tensor to the next higher data structure. Cheers, Johannes -------------- next part -------------- An HTML attachment was scrubbed... URL: From ifl21.publicity at gmail.com Fri Jul 15 09:38:46 2022 From: ifl21.publicity at gmail.com (Pieter Koopman) Date: Fri, 15 Jul 2022 02:38:46 -0700 Subject: [Haskell-cafe] 2nd CFP - IFL22 - The 34th Symposium on Implementation and Application of Functional Languages Message-ID: *CALL FOR PAPERS: * The 34th Symposium on Implementation and Application of Functional Languages (IFL 2022) *Submission and registration are open.* See https://ifl22.github.io/. Copenhagen, August 31st-September 2nd, 2022 *Important dates * Draft paper submission: August 7th, 2022 Draft paper notification: August 9th, 2022 Early registration deadline: August 12th, 2022 Late registration deadline: September 2nd, 2022 Symposium: August 31st-September 2nd, 2022 (3 days) *Scope * The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2022 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: * language concepts * type systems, type checking, type inferencing * compilation techniques * staged compilation * run-time function specialization * run-time code generation * partial evaluation * abstract interpretation * metaprogramming * generic programming * automatic program generation * array processing * concurrent/parallel programming * concurrent/parallel program execution * embedded systems * web applications * embedded domain specific languages * security * novel memory management techniques * run-time profiling performance measurements * debugging and tracing * virtual/abstract machine architectures * validation, verification of functional programs * tools and programming techniques * industrial applications *Submissions and peer-review * Following IFL tradition, IFL 2022 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chair to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. Notice that it is a requirement that accepted draft papers are presented physically at the symposium. After the symposium, a formal review process will take place, conducted by the program committee. Reviewing is single blind. There will be at least 3 reviews per paper. The reviewers have 6 weeks to write their reviews. For the camera-ready version the authors can make minor revisions which are accepted without further reviewing. Contributions submitted for the draft paper deadline must be between two and twelve pages long. For submission details, please consult the IFL 2022 website at https://ifl22.github.io/. *Where * IFL 2022 will be held physically in Copenhagen, Denmark, arranged by DIKU at the University of Copenhagen. See the IFL 2022 website at https://ifl22.github.io/ for more information. [image: beacon] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Sat Jul 16 09:49:35 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sat, 16 Jul 2022 05:49:35 -0400 Subject: [Haskell-cafe] ANN: Copilot 3.10 In-Reply-To: References: Message-ID: > We also want to thank everyone who uses and helps promote > Copilot By the way, I'd like to give a shoutout to Joey Hess, who has built arduino-copilot and zephyr-copilot . Joey updated both projects immediately after our release so that they work with Copilot 3.10. I've just found out that he also gave a talk on his work, which I think does an amazing job at showing how easy it is to get it running on arduinos. Cheers, Ivan On Tue, 12 Jul 2022 at 07:43, Ivan Perez wrote: > Dear all, > > We are very happy to announce the release of Copilot 3.10. Copilot is a > runtime verification system implemented as a Haskell DSL that generates > hard-realtime C99. You can learn more about it at [1]. > > This new version of Copilot contains a small but important change in how > structs are handled in C functions invoked by the monitors when property > violations are detected. This change is API-breaking, so users of > Copilot may need to adapt their systems accordingly. The release also > contains a number of bug fixes, provides a simplified API, deprecates > outdated elements, removes unused code, and relaxes version constraints > for dependencies. 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] applications) from requirements in structured > natural language. > > We'd like to take this opportunity to welcome Will Pogge to the team > with his first commit, and thank the Galois team for their > contributions. We also want to thank everyone who uses and helps promote > Copilot; we are seeing increased attention, and gave three talks in the > last two months at JPL, USC, and VCU, with two more taking place this > month. > > 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/14?closed=1 > [3] https://github.com/nasa/ogma > [4] https://cfs.gsfc.nasa.gov/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From id at joeyh.name Sat Jul 16 15:44:30 2022 From: id at joeyh.name (Joey Hess) Date: Sat, 16 Jul 2022 11:44:30 -0400 Subject: [Haskell-cafe] ANN: Copilot 3.10 In-Reply-To: References: Message-ID: Ivan Perez wrote: > > We also want to thank everyone who uses and helps promote > > Copilot > > By the way, I'd like to give a shoutout to Joey Hess, who has built > arduino-copilot and zephyr-copilot. Joey updated both projects immediately > after our release so that they work with Copilot 3.10. > > I've just found out that he also gave a talk on his work, which I think does an > amazing job at showing how easy it is to get it running on arduinos. Thanks Ivan. The talk was at Houston PFUG and is here: https://www.youtube.com/watch?v=l-luyVRgWVU I would love to see a talk explaining programming the Copilot DSL from someone who understands it better. :-) -- see shy jo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From karel.gardas at centrum.cz Sat Jul 16 21:03:07 2022 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sat, 16 Jul 2022 23:03:07 +0200 Subject: [Haskell-cafe] ANN: Copilot 3.10 In-Reply-To: References: Message-ID: <5198a579-66b3-822e-c91a-2289e2b8b4b5@centrum.cz> On 7/16/22 17:44, Joey Hess wrote: > Ivan Perez wrote: >>> We also want to thank everyone who uses and helps promote >>> Copilot >> >> By the way, I'd like to give a shoutout to Joey Hess, who has built >> arduino-copilot and zephyr-copilot. Joey updated both projects immediately >> after our release so that they work with Copilot 3.10. >> >> I've just found out that he also gave a talk on his work, which I think does an >> amazing job at showing how easy it is to get it running on arduinos. > > Thanks Ivan. The talk was at Houston PFUG and is here: > https://www.youtube.com/watch?v=l-luyVRgWVU Thanks for the talk and for the arduino and zephyr support. However seen this I can't resist to think that you basically turn copilot upside down and make that a real "pilot". E.g. you turn all the sampling of system variables and comparing with the spec idea to let's make it a real C code and run that instead. Am I right or still not getting whole idea behind the Copilot? > I would love to see a talk explaining programming the Copilot DSL from > someone who understands it better. :-) Me too. :-) Thanks a lot! Karel From raoknz at gmail.com Sun Jul 17 13:13:26 2022 From: raoknz at gmail.com (Richard O'Keefe) Date: Mon, 18 Jul 2022 01:13:26 +1200 Subject: [Haskell-cafe] ANN: Copilot 3.10 In-Reply-To: References: Message-ID: How hard would it be to use Copilot with ESP32 boards, using their C SDK libraries for I/O? The RPi Pico is also a candidate for the project we've just submitted a grant proposal for. The Pico has "PIO" and the ESP32 chips have "ULP" and they are both basically very low power finite state machines that can handle basic I/O while the main CPU(s) is(are) dead to the world. On Sat, 16 Jul 2022 at 21:50, Ivan Perez wrote: > > We also want to thank everyone who uses and helps promote > > Copilot > > By the way, I'd like to give a shoutout to Joey Hess, who has built > arduino-copilot and > zephyr-copilot . Joey > updated both projects immediately after our release so that they work with > Copilot 3.10. > > I've just found out that he also gave a talk > on his work, which I think > does an amazing job at showing how easy it is to get it running on arduinos. > > Cheers, > > Ivan > > On Tue, 12 Jul 2022 at 07:43, Ivan Perez > wrote: > >> Dear all, >> >> We are very happy to announce the release of Copilot 3.10. Copilot is a >> runtime verification system implemented as a Haskell DSL that generates >> hard-realtime C99. You can learn more about it at [1]. >> >> This new version of Copilot contains a small but important change in how >> structs are handled in C functions invoked by the monitors when property >> violations are detected. This change is API-breaking, so users of >> Copilot may need to adapt their systems accordingly. The release also >> contains a number of bug fixes, provides a simplified API, deprecates >> outdated elements, removes unused code, and relaxes version constraints >> for dependencies. 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] applications) from requirements in structured >> natural language. >> >> We'd like to take this opportunity to welcome Will Pogge to the team >> with his first commit, and thank the Galois team for their >> contributions. We also want to thank everyone who uses and helps promote >> Copilot; we are seeing increased attention, and gave three talks in the >> last two months at JPL, USC, and VCU, with two more taking place this >> month. >> >> 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/14?closed=1 >> [3] https://github.com/nasa/ogma >> [4] https://cfs.gsfc.nasa.gov/ >> > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From id at ypei.org Mon Jul 18 12:02:06 2022 From: id at ypei.org (Yuchen Pei) Date: Mon, 18 Jul 2022 22:02:06 +1000 Subject: [Haskell-cafe] An org backend to Haddock Message-ID: <87k08azl1d.fsf@ypei.me> Hello, I decided to write an Org backend to Haddock[1], so that haskell library documentation can be generated in org mode markup. Compared to the existing backends (html, latex and hoogle), the org format allows utilising features like the infinite levels of heading hierarchy, flexible folding / unfolding, cross-package linking, jumping to any declaration with org-goto and the endless potentials of emacs customisation. It seems to me most information and haskell language features one can find on displayed on hackage are supported by the org backend and included in the output org files, though there are still some rough edges and unsupported language features (like infix declarations and linear types) which I aim to fix. Some example output can be found at [2] (I will need to rename the "assets" part of the url as it is not accurate), including base[4], ghc-prim[5] and ghc-lib-parser[6] (I use it for reference of the GHC API as it is easier to build than GHC). For more information, check out the README file[3]. Given this is not the official version of haddock and my changes are in haddock-api, I'm calling it haddorg-api, for lack of a better name / approach. I'll be happy to contribute my changes upstream if a different license covering my contribution (AGPLv3+) is accepted. Let me know what you think. [1] https://g.ypei.me/haddock.git/tree/haddock-api [2] https://ypei.org/assets/haddorg-output/ [3] https://g.ypei.me/haddock.git/tree/haddock-api/README.org [4] https://ypei.org/assets/haddorg-output/base-4.16.1.0.org.gz [5] https://ypei.org/assets/haddorg-output/ghc-prim-0.8.0.org.gz [6] https://ypei.org/assets/haddorg-output/ghc-lib-parser-9.2.2.20220307.org.gz Best, Yuchen -- PGP Key: 47F9 D050 1E11 8879 9040 4941 2126 7E93 EF86 DFD0 From id at joeyh.name Mon Jul 18 21:12:37 2022 From: id at joeyh.name (Joey Hess) Date: Mon, 18 Jul 2022 17:12:37 -0400 Subject: [Haskell-cafe] ANN: Copilot 3.10 In-Reply-To: <5198a579-66b3-822e-c91a-2289e2b8b4b5@centrum.cz> References: <5198a579-66b3-822e-c91a-2289e2b8b4b5@centrum.cz> Message-ID: Karel Gardas wrote: > Thanks for the talk and for the arduino and zephyr support. However seen > this I can't resist to think that you basically turn copilot upside down and > make that a real "pilot". E.g. you turn all the sampling of system variables > and comparing with the spec idea to let's make it a real C code and run that > instead. Am I right or still not getting whole idea behind the Copilot? Yes, the Arduino is being piloted without anyone in the other seat, as it were. arduino-copilot generates just enough C code to make that work, relying heavily on the arduino libraries. -- see shy jo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ivanperezdominguez at gmail.com Tue Jul 19 10:28:10 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Tue, 19 Jul 2022 06:28:10 -0400 Subject: [Haskell-cafe] ANN: Copilot 3.10 In-Reply-To: References: <5198a579-66b3-822e-c91a-2289e2b8b4b5@centrum.cz> Message-ID: On Mon, 18 Jul 2022 at 17:12, Joey Hess wrote: > Karel Gardas wrote: > > Thanks for the talk and for the arduino and zephyr support. However seen > > this I can't resist to think that you basically turn copilot upside down > and > > make that a real "pilot". E.g. you turn all the sampling of system > variables > > and comparing with the spec idea to let's make it a real C code and run > that > > instead. Am I right or still not getting whole idea behind the Copilot? > > Yes, the Arduino is being piloted without anyone in the other seat, as it > were. I've seen other people do this too (that is, using Copilot as a stream processing or dataflow language to control systems, not monitor them). It's something that likely has not been explored enough in the context of Copilot. In the domain where Copilot is applied, there are other languages that I expect might be more expressive (Scade comes to mind). I'd be interested in seeing more examples, and the plumbing necessary in each case. If "piloting", as you call it, is a use case we ever decide to support, that'll help us design the language right. Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From id at ypei.org Tue Jul 19 14:41:10 2022 From: id at ypei.org (Yuchen Pei) Date: Wed, 20 Jul 2022 00:41:10 +1000 Subject: [Haskell-cafe] An org backend to Haddock In-Reply-To: <87sfmx4325.fsf@localhost> (Ihor Radchenko's message of "Tue, 19 Jul 2022 21:58:26 +0800") References: <87k08azl1d.fsf@ypei.me> <87sfmx4325.fsf@localhost> Message-ID: <87pmi1w4ft.fsf@ypei.me> On Tue 2022-07-19 21:58:26 +0800, Ihor Radchenko wrote: > Yuchen Pei writes: > >> Given this is not the official version of haddock and my changes are in >> haddock-api, I'm calling it haddorg-api, for lack of a better name / >> approach. I'll be happy to contribute my changes upstream if a >> different license covering my contribution (AGPLv3+) is accepted. >> >> Let me know what you think. > > I am pretty sure that you are asking the Haskell people for upstreaming > ;) Yes - I sent the email to both haskell-cafe and emacs-orgmode, but upstream here means haddock / haddock-api indeed, thanks for clarifying. > > From Org side, it is always welcome when other Free software projects > are making use of Org. > > Also, I looked into > https://g.ypei.me/haddock.git/tree/haddock-api/src/Haddock/Backends/Org/Types.hs > > Beware of possible edge cases with "*/~|" in formatting. I am not > sure if text containing such symbols is possible as an input for your > library, but if it is, things may get formatted wrongly. > > For example, text containing "|" anywhere inside a table field must have > "|" escaped using \vert entity. The markup can be escaped using > zero-width space. True. I have not addressed these edge cases in my code, except a quick hack to prepend a space whenever any line a src block / result block has a leading star. Tables on the other hand are extremely rare in Haskell package documentation strings, and having a | in them is even rarer. I do wonder what is the best way to handle cross-package links. Currently I'm using CUSTOM_ID in the format of package-name-x.y.z.Module.Name.IdentifierName, as well as Module.Name.IdentifierName. But this is a "one big org file" approach, and can make navigation slow when say the org file reaches 15+MB in size. Ideally one should be able to navigate the a hackage worth of documentations easily, with working cross-package links and low latency org-goto to jump to any identifier or module, but I don't see how to achieve that. To be further investigated. > > Best, > Ihor Best, Yuchen -- PGP Key: 47F9 D050 1E11 8879 9040 4941 2126 7E93 EF86 DFD0 From cmb21 at st-andrews.ac.uk Wed Jul 20 09:12:08 2022 From: cmb21 at st-andrews.ac.uk (Christopher Brown) Date: Wed, 20 Jul 2022 09:12:08 +0000 Subject: [Haskell-cafe] Postdoc Vacancy at St Andrews Message-ID: The Programming Languages Group at the University of St Andrews seeks a post-doctoral research fellow for a fixed 12-month position. Details of the position can be found here: https://www.vacancies.st-andrews.ac.uk/Vacancies/W/4238/0/352367/889/research-fellow-ar2699gb Vacancy Description School of Computer Science Salary: £34,304 per annum Start date: 1 October 2022 or as soon as possible thereafter Fixed-term: 12 months Applications are sought for a committed Post-doctoral Research Fellow to work with Dr Chris Brown conducting research for a EPSRC funded project entitled Energise: Refactorings and Skeletons for Energy-Aware Applications on High-Performance Embedded Systems. The primary duties will be to implementing refactorings for target languages such as C; proving general soundness of the refactorings using e.g. dependent types; developing new programming abstractions (skeletons) for abstracting common energy-reducing programming patterns; running experiments; writing proofs of correctness. The successful applicant will have (or be near to completion of) a PhD in Programming Languages with expertise in formal semantics of programming languages, compilers, program transformation, lightweight formal methods (including, e.g. dependent types) and/or knowledge of parallelism and non-functional properties, including energy. The post is available on a fixed-term basis for 12 months starting 1st October or as soon as possible thereafter. Further details of the project can be found by contacting Dr Christopher Brown (cmb21 at st-andrews.ac.uk). Applications are particularly welcome from women, people from the Black, Asian and Minority Ethnic (BAME) community, and other protected characteristics who are under-represented in research posts at the University. Equality, diversity and inclusion are at the heart of the St Andrews experience. We strive to create a fair and inclusive culture demonstrated through our commitment to diversity awards (Athena Swan, Carer Positive, LGBT Charter, Race Charters and Stonewall). We celebrate diversity by promoting profiles of BAME, LGBTIQ+ staff and supporting networks including the Staff BAME Network; Staff with Disabilities Network; Staff LGBTIQ+ Network; and the Staff Parents & Carers Network. Full details available online: https://www.st-andrews.ac.uk/hr/edi/ Closing Date: 29 July 2022 Interview Date: 23 August 2022 Please quote ref:AR2699GB School of Computer Science Salary: £34,304 per annum Start date: 1 October 2022 or as soon as possible thereafter Fixed-term: 12 months -------------- next part -------------- An HTML attachment was scrubbed... URL: From id at ypei.org Thu Jul 21 06:09:12 2022 From: id at ypei.org (Yuchen Pei) Date: Thu, 21 Jul 2022 16:09:12 +1000 Subject: [Haskell-cafe] An org backend to Haddock In-Reply-To: <87k08azl1d.fsf@ypei.me> (Yuchen Pei's message of "Mon, 18 Jul 2022 22:02:06 +1000") References: <87k08azl1d.fsf@ypei.me> Message-ID: <87y1wnhu9j.fsf@ypei.me> Hello again, I added instructions on how to build org documentation for ghc libraries using hadrian[1] to the readme, and with that I present you Haskell Libraries Hierarchy module (like [2] but version 9.5) docs in one big org file[3], as well as the real GHC API[4] and more accurate ghc-prim[5] docs. [1] https://g.ypei.me/haddock.git/about/ [2] https://downloads.haskell.org/ghc/9.2.2/docs/html/libraries/ [3] https://ypei.org/assets/haddorg-output/hierarchy-e2f0094c.org.gz [4] https://ypei.org/assets/haddorg-output/ghc-9.5-e2f0094c.org.gz [5] https://ypei.org/assets/haddorg-output/hierarchy-e2f0094c/ghc-prim.org.gz Best, Yuchen -- PGP Key: 47F9 D050 1E11 8879 9040 4941 2126 7E93 EF86 DFD0 From ben at well-typed.com Fri Jul 22 13:05:15 2022 From: ben at well-typed.com (Ben Gamari) Date: Fri, 22 Jul 2022 09:05:15 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available Message-ID: <87o7xhz4ax.fsf@smart-cactus.org> The GHC developers are happy to announce the availability of the first (and likely last) release candidate of GHC 9.4.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org]. This major release will include: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This provides informative profiles while interfering significantly less with GHC's aggressive optimisations, making it easier to understand the performance of programs which depend upon simplification.. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302] - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions. - Reintroduction of deep subsumption (which was previously dropped with the *simplified subsumption* change) as a language extension. - ... and much more. See the [release notes] for a full accounting. Note that, as 9.4.1 is the first release for which the released artifacts will all be generated by our Hadrian build system, it is possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. We will be publishing a blog post describing the migration process to Hadrian in the coming weeks. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy testing, - Ben [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.4.1-rc1/ [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian [release notes]: https://downloads.haskell.org/~ghc/9.4.1-rc1/docs/users_guide/9.4.1-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Sat Jul 23 03:30:28 2022 From: ben at well-typed.com (Ben Gamari) Date: Fri, 22 Jul 2022 23:30:28 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: References: <87o7xhz4ax.fsf@smart-cactus.org> Message-ID: <87edyczeti.fsf@smart-cactus.org> George Colpitts writes: > Hi Ben, > > I expected https://gitlab.haskell.org/ghc/ghc/-/issues/21506 (ghc-9.4.1-alpha1 > does not install on macos: ghc-pkg-9.4.0-20220501 cannot be opened because > the developer cannot be verified) to be fixed in rc1 but it is not. Are my > expectations wrong? What is the ETA for fixing it? > Thanks for letting us know, George. The fix that we have [1] is present in 9.4.1-rc1. If that commit doesn't resolve the issue then there is something that we don't understand. Does `/usr/bin/xattr` exist? Running `xattr -rc` manually on the binary distribution allow you to run the compiler? Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/commit/641972d65b476aac11424bde6c3bcfda1c65aef5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Sat Jul 23 13:03:53 2022 From: ben at well-typed.com (Ben Gamari) Date: Sat, 23 Jul 2022 09:03:53 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: References: <87o7xhz4ax.fsf@smart-cactus.org> <87edyczeti.fsf@smart-cactus.org> Message-ID: <87bktgyo9s.fsf@smart-cactus.org> George Colpitts writes: > Hi Ben > > /ust/bin/xattr exists on my machine. Running "xattr -rc ." manually does > not fix the bug as noted at the start of 21506. It was sufficient in the > past but no longer fixes this error. As noted farther down in 21506 > > the workaround given in #17418 no longer works. > It did not work in 9.2.2 either. The current workaround is similar to what > Kazu explained in > https://twitter.com/kazu_yamamoto/status/1500643489985761282 > > sudo xattr -rc . > > sudo spctl --global-disable > > ./configure > > sudo make install > > sudo spctl --global-enable > > It seems there are files created during sudo make install that have an > issue as xattr -rc . was never run on them. Perhaps this is related to > using Hadrian. Is it possible that the fix that was made was never tested? > I tested the change both manually and via CI on the hardware that I have access to; in both cases installing the binary distribution resulted in a functional compiler. However, given how the effects of SIP are essentially undocumented, it is very hard to know what variables may be at play here. Running spctl --status on the machine on which I tested claims: > spctl --status objc[48908]: Class SPExecutionPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapper is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapperPolicyResult is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapperPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPLog is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class MIS is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPExecutionHistoryItem is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPExecutionPolicyItem is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPDeveloperPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class GKScanResult is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. assessments enabled Which to me suggests that SIP (which, I imagine, is responsible for #21506) is enabled. However, the lack of comprehensive documentation here makes it very hard to say with certainty what might differ between your machine and mine. Without more information I don't know how to proceed here. Perhaps someone (Moritz or Simon, perhaps) with more familiarity with macOS has some insight? Thanks for your help in testing, George! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Sun Jul 24 14:33:29 2022 From: ben at well-typed.com (Ben Gamari) Date: Sun, 24 Jul 2022 10:33:29 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: References: <87o7xhz4ax.fsf@smart-cactus.org> <87edyczeti.fsf@smart-cactus.org> <87bktgyo9s.fsf@smart-cactus.org> Message-ID: <878roizilc.fsf@smart-cactus.org> George Colpitts writes: > +Kazu Yamamoto > > Hi Ben > > My 2 machines also have: > > $ spctl --status > assessments enabled > Hmm, interesting. Then I am truly perplexed. > Speculations: > > /usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib > is created after xattr -rc . was run so it doesn't have the necessary > attributes. Is it possible that ghc developers and/or the test machines > have this file on another of the paths in the error message and that is why > it works for them? > I'm not sure where this would be but at this point anything is possible. What happens if you try to install to do something like (in the extracted binary distribution), $ ./configure --prefix=`pwd`/tmp $ make install # this will fail $ xattr -rc . $ make install # perhaps this will finish successfully? # tmp/bin/ghc --version # GHC should be usable > I hope I didn't offend you by asking if the fix had been tested; I assume > it had been but I thought it was important to rule that out. > Not to worry; it's a very reasonable question to ask given the circumstances. > More than happy to test. I really appreciate all the work you and others > have put into GHC ! > Ultimately I think we may just need to bite the bullet and start properly notarising/codesigning releases (resolving #17418). At this point we have spent more time trying to avoid the notarisation requirement than it would likely take to satisfy it. Unfortunately, this will require that I find an Apple device somewhere which may take a few weeks. I'm afraid I am on holiday next week but I would quite grateful if we could arrange for a chat after I return such that we can debug this in realtime. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From kazu at iij.ad.jp Mon Jul 25 04:23:17 2022 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Mon, 25 Jul 2022 13:23:17 +0900 (JST) Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: References: <87bktgyo9s.fsf@smart-cactus.org> Message-ID: <20220725.132317.759628945463268605.kazu@iij.ad.jp> Hi George, > I've duplicated the issue on both of my machines. It would be good to know > if anybody else is seeing it. Kazu, I know you have seen this in the past. > Do you get the same error installing rc1? > When I run sudo make install I get a popup that says: I had no problem on 9.4.1-rc1. "xattr -rc ." and "make install" worked perfectly. macOS Monterey v12.4 Xcode 13.4.1 --Kazu From leah at vuxu.org Mon Jul 25 14:40:53 2022 From: leah at vuxu.org (Leah Neukirchen) Date: Mon, 25 Jul 2022 16:40:53 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2022-07-28 @ 19:30 Message-ID: <87k0815k7e.fsf@vuxu.org> Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, July 28 at Hirschgarten (Biergarten, self-service area) at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html Please sign up here if you are coming so we'll look out for you. https://dudle.inf.tu-dresden.de/haskell-munich-jul-2022/ Everybody is welcome! cu, -- Leah Neukirchen https://leahneukirchen.org/ From id at joeyh.name Tue Jul 26 13:53:02 2022 From: id at joeyh.name (Joey Hess) Date: Tue, 26 Jul 2022 09:53:02 -0400 Subject: [Haskell-cafe] ANN: Copilot 3.10 In-Reply-To: References: Message-ID: Richard O'Keefe wrote: > How hard would it be to use Copilot with ESP32 boards, > using their C SDK libraries for I/O? > > The RPi Pico is also a candidate for the project we've just > submitted a grant proposal for.  The Pico has "PIO" and the > ESP32 chips have "ULP" and they are both basically very low > power finite state machines that can handle basic I/O while > the main CPU(s) is(are) dead to the world. zephyr-copilot can be used to program both ESP32 and RPI Pico, since the Zephyr project supports both. I've only spent a few weeks developing zephyr-copilot so far, and so it only supports a very small subset of what Zepyhr can do with these boards. Zephyr does not appear to support PIO/ULP yet though. The disadvantage of using a general-purpose RTOS rather than board-specific SDKs. Seems that it's possible to use Arduino to program ULP, via https://github.com/duff2013/ulptool so I do think it would be possible to use arduino-copilot or something like it to program these coprocessors. -- see shy jo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From carter.schonwald at gmail.com Wed Jul 27 13:25:39 2022 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 27 Jul 2022 09:25:39 -0400 Subject: [Haskell-cafe] success on a slightly modified version of your suggestion for 21506 In-Reply-To: References: <87o7xhz4ax.fsf@smart-cactus.org> <87edyczeti.fsf@smart-cactus.org> <87bktgyo9s.fsf@smart-cactus.org> <878roizilc.fsf@smart-cactus.org> Message-ID: that matches my experience, namely that i've successfully installed ghc 9.2.2 on osx 12.4 aka monterey a few times On Sun, Jul 24, 2022 at 12:59 PM George Colpitts wrote: > Hi Ben > > Thanks for the quick responses particularly on the weekend before your > vacation. > > you wrote: > > What happens > if you try to install to do something like (in the extracted binary > distribution), > > > $ ./configure --prefix=`pwd`/tmp > $ make install # this will fail > $ xattr -rc . > $ make install # perhaps this will finish successfully? > # tmp/bin/ghc --version # GHC should be usable > > > success on both my machines using a slightly modified version of your > suggestion above for 21506: > > ./configure --prefix=`pwd`/tmp # specifying ./tmp seems to be critical > > xattr -rc . # seems to be necessary > also > > sudo make install # seems to works , output ends > with "recache" > > ./tmp/bin/ghc --version # success , although admittedly > the smallest smoke test possible > > You wrote: > > > > Ultimately I think we may just need to bite the bullet and start > properly notarising/codesigning releases (resolving #17418). At this point > we have > spent more time trying to avoid the notarisation requirement than > it would likely take to satisfy it. Unfortunately, this will require > that I find an Apple device somewhere which may take a few weeks. > > > I'm afraid I am on holiday next week but I would quite grateful if we > could arrange for a chat after I return such that we can debug this in > realtime. > > > Sure, we can chat when you return from your vacation. > > Not sure if it is worth trying to fix the release on the basis of what I > write above. My opinion is: it is if we can get reports of at least one > other person having this issue. I am fine with not doing this for 9.4.1 > > I agree that we should raise the priority of "notarising/codesigning > releases (resolving #17418)". My opinion is that it is not worth delaying > 9.4.1 for this. > > Have a great vacation. > > Cheers > George > > > > > > > On Sun, Jul 24, 2022 at 11:33 AM Ben Gamari wrote: > >> George Colpitts writes: >> >> > +Kazu Yamamoto >> > >> > Hi Ben >> > >> > My 2 machines also have: >> > >> > $ spctl --status >> > assessments enabled >> > >> Hmm, interesting. Then I am truly perplexed. >> >> > Speculations: >> > >> > >> /usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib >> > is created after xattr -rc . was run so it doesn't have the necessary >> > attributes. Is it possible that ghc developers and/or the test machines >> > have this file on another of the paths in the error message and that is >> why >> > it works for them? >> > >> I'm not sure where this would be but at this point anything is possible. >> What happens >> if you try to install to do something like (in the extracted binary >> distribution), >> >> $ ./configure --prefix=`pwd`/tmp >> $ make install # this will fail >> $ xattr -rc . >> $ make install # perhaps this will finish successfully? >> # tmp/bin/ghc --version # GHC should be usable >> >> > I hope I didn't offend you by asking if the fix had been tested; I >> assume >> > it had been but I thought it was important to rule that out. >> > >> Not to worry; it's a very reasonable question to ask given the >> circumstances. >> >> > More than happy to test. I really appreciate all the work you and others >> > have put into GHC ! >> > >> Ultimately I think we may just need to bite the bullet and start >> properly notarising/codesigning releases (resolving #17418). At this >> point we have >> spent more time trying to avoid the notarisation requirement than >> it would likely take to satisfy it. Unfortunately, this will require >> that I find an Apple device somewhere which may take a few weeks. >> >> I'm afraid I am on holiday next week but I would quite grateful if we >> could arrange for a chat after I return such that we can debug this in >> realtime. >> >> Cheers, >> >> - Ben >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Thu Jul 28 11:17:13 2022 From: zubin at well-typed.com (Zubin Duggal) Date: Thu, 28 Jul 2022 16:47:13 +0530 Subject: [Haskell-cafe] [Haskell] [ANNOUNCE] GHC 9.2.4 released Message-ID: <20220728111713.owpnsu43zwq2klhn@zubin-msi> The GHC developers are very happy to at announce the availability of GHC 9.2.4. Binary distributions, source distributions, and documentation are available at [`downloads.haskell.org`](https://downloads.haskell.org/ghc/9.2.4). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_4.html Blog Post: https://www.haskell.org/ghc/blog/20220728-ghc-9.2.4-released.html This release will include: - The new `DeepSubsumption` language extension which reverses the effects of the [Simplified Subsumption Proposal] introduced in GHC 9.0. This is an attempt to make GHC 9.2.4 more backwards compatible with GHC 8.10 and eases migration for users who depended on this feature. This extension is enabled by default with the `Haskell2010` and `Haskell98` languages but disabled with the `GHC2021` language originally introduced in GHC 9.2.1. See the [Deep Subsumption Proposal] for more details. - Fixes for segfaults that may arise due to a bug in the implementation of the `keepAlive#` primop. This may regress performance for certain programs which use this primop or functions which use the primop, such as `withForeignPtr`. These regressions are mostly small, but can be larger in certain edge cases. Judicious use of `unsafeWithForeignPtr` when its argument is known not to statically diverge can mitigate these in many cases. It is our judgment that the critical correctness issues justify the regression in performance and that it is important to get a release out with the fix while we work on a better approach which will improve performance for future releases (#21708). We have a [wiki page](https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/with-combinator) that tracks possible solutions to this problem, and Ben wrote a [blog post](https://www.haskell.org/ghc/blog/20210607-the-keepAlive-story.html) detailing the introduction of the `keepAlive#` primop and its history. - Fixes for a number of miscompilations on AArch64 and other platforms (#21624, #21773, #20735, #21685). - Fixes for segfaults due to bugs in the RTS and GC (#21708, #21880, #21885). - Fixing the behaviour of Ctrl-C with GHCi on Windows (#21889). - ... and much more. See the [release notes] for a full accounting. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.2.4/docs/users_guide/9.2.4-notes.html [Simplified Subsumption Proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst [Deep Subsumption Proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0511-deep-subsumption.rst -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From lemming at henning-thielemann.de Thu Jul 28 16:26:28 2022 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 28 Jul 2022 18:26:28 +0200 (CEST) Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: <87o7xhz4ax.fsf@smart-cactus.org> References: <87o7xhz4ax.fsf@smart-cactus.org> Message-ID: On Fri, 22 Jul 2022, Ben Gamari wrote: > The GHC developers are happy to announce the availability of the first > (and likely last) release candidate of GHC 9.4.1. Binary distributions, source > distributions, and documentation are available at [downloads.haskell.org]. I try https://downloads.haskell.org/ghc/9.4.1-rc1/ghc-9.4.0.20220721-x86_64-deb11-linux.tar.lz on Debian 11. $ /usr/local/ghc-9.4.0/bin/ghc --version /usr/local/ghc-9.4.0/lib/ghc-9.4.0.20220721/bin/ghc-9.4.0.20220721: error while loading shared libraries: libffi.so.8: cannot open shared object file: No such file or directory Debian 11 seems to support only libffi7: $ dpkg --list "*libffi*" ii libffi-dev:amd64 3.3-6 amd64 Foreign Function Interface library (development files) un libffi4-dev (keine Beschreibung vorhanden) ii libffi7:amd64 3.3-6 amd64 Foreign Function Interface library runtime ii libffi7:i386 3.3-6 i386 Foreign Function Interface library runtime I think this dependency is new and was not present in the Alpha releases. Also many directories have no read and cd permissions for 'other' users. From kazu at iij.ad.jp Fri Jul 29 02:10:54 2022 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Fri, 29 Jul 2022 11:10:54 +0900 (JST) Subject: [Haskell-cafe] [Haskell] [ANNOUNCE] GHC 9.2.4 released In-Reply-To: References: <20220728111713.owpnsu43zwq2klhn@zubin-msi> Message-ID: <20220729.111054.1976367299003263525.kazu@iij.ad.jp> Hi, > On a Mac it is still necessary to do > > xattr -rc . > > before doing > > sudo make install For 9.2.4, "xattr -rc ." is not good enough on my Mac (upgraded to v12.5 today). "sudo spctl --global-disable" is necessary, sigh. --Kazu From nadine.and.henry at pobox.com Sat Jul 30 18:53:29 2022 From: nadine.and.henry at pobox.com (Henry Laxen) Date: Sat, 30 Jul 2022 11:53:29 -0700 Subject: [Haskell-cafe] Why do I see the escape chars in Emacs with haskell-mode Message-ID: <87r122v3di.fsf@pobox.com> Dear Cafe, Greeting Gentle Haskellers, I know this may really be a question for the emacs guys, but I thought for sure someone here has encoutered the same thing and would recognize the problem right away. Here is my progam: module Main where main = xprint "hi" Yes, xprint is intensional, I want an error. I am in haskell mode in emacs. I type C-c C-l running haskell-process-load-file, and get: Hours of hacking await! If I break, you can: 1. Restart: M-x haskell-process-restart 2. Configure logging: C-h v haskell-process-log (useful for debugging) 3. General config: M-x customize-mode 4. Hide these tips: C-h v haskell-process-show-debug-tips .[;1m/home/henry/a.hs:2:8-13: .[;1m.[31merror:.[0m.[0m.[;1m.[0m.[0m.[;1m … • Variable not in scope: xprint :: [Char] -> t • Perhaps you meant ‘print’ (imported from Prelude).[0m.[0m .[;1m/home/henry/a.hs:2:8-13: .[;1m.[31merror:.[0m.[0m.[;1m.[0m.[0m.[;1m … • Variable not in scope: xprint :: [Char] -> t • Perhaps you meant ‘print’ (imported from Prelude).[0m.[0m Compilation failed. but when I swich to the *haskell* buffer and type :r, I get the beautiful, colorized message: [1 of 1] Compiling Main ( /home/henry/a.hs, interpreted ) /home/henry/a.hs:2:8-13: error: • Variable not in scope: xprint :: [Char] -> t • Perhaps you meant ‘print’ (imported from Prelude) | 2 | main = xprint "hi" | ^^^^^^ Failed, no modules loaded. Where the escape sequences have been interpreted correctly. What do I have misconfigured? Please point me in a direction. Thanks in advance. Best wishes, Henry Laxen -- Nadine and Henry Laxen The rest is silence Gral. Manuel Márquez de León 1301 Onix #2302 Zona Urban Rio Never try to teach a pig to sing; Tijuana It wastes your time +52 (333) 667-8633 And it annoys the pig From alan.zimm at gmail.com Sat Jul 30 19:04:47 2022 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Sat, 30 Jul 2022 20:04:47 +0100 Subject: [Haskell-cafe] Why do I see the escape chars in Emacs with haskell-mode In-Reply-To: <87r122v3di.fsf@pobox.com> References: <87r122v3di.fsf@pobox.com> Message-ID: Sort-of related, I have this setting to honour the escape sequences in my *compile* buffer ``` ;;---------------------------------------------------------------------- ;; Enable ansi colours in the compile buffer. ;; See https://stackoverflow.com/questions/3072648/cucumbers-ansi-colors-messing-up-emacs-compilation-buffer#3072831 (ignore-errors (require 'ansi-color) (defun my-colorize-compilation-buffer () (when (eq major-mode 'compilation-mode) (ansi-color-apply-on-region compilation-filter-start (point-max)))) (add-hook 'compilation-filter-hook 'my-colorize-compilation-buffer)) ``` On Sat, 30 Jul 2022 at 19:54, Henry Laxen wrote: > Dear Cafe, > > Greeting Gentle Haskellers, > > I know this may really be a question for the emacs guys, but I thought > for sure someone here has encoutered the same thing and would > recognize the problem right away. > > Here is my progam: > > module Main where > main = xprint "hi" > > Yes, xprint is intensional, I want an error. > > I am in haskell mode in emacs. I type C-c C-l running > haskell-process-load-file, and get: > > Hours of hacking await! > If I break, you can: > 1. Restart: M-x haskell-process-restart > 2. Configure logging: C-h v haskell-process-log (useful for debugging) > 3. General config: M-x customize-mode > 4. Hide these tips: C-h v haskell-process-show-debug-tips > .[;1m/home/henry/a.hs:2:8-13: .[;1m.[31merror:.[0m.[0m.[;1m.[0m.[0m.[;1m … > • Variable not in scope: xprint :: [Char] -> t > • Perhaps you meant ‘print’ (imported from Prelude).[0m.[0m > .[;1m/home/henry/a.hs:2:8-13: .[;1m.[31merror:.[0m.[0m.[;1m.[0m.[0m.[;1m … > • Variable not in scope: xprint :: [Char] -> t > • Perhaps you meant ‘print’ (imported from Prelude).[0m.[0m > Compilation failed. > > but when I swich to the *haskell* buffer and type :r, I get the > beautiful, colorized message: > > [1 of 1] Compiling Main ( /home/henry/a.hs, interpreted ) > > /home/henry/a.hs:2:8-13: error: > • Variable not in scope: xprint :: [Char] -> t > • Perhaps you meant ‘print’ (imported from Prelude) > | > 2 | main = xprint "hi" > | ^^^^^^ > Failed, no modules loaded. > > Where the escape sequences have been interpreted correctly. What do I > have misconfigured? Please point me in a direction. Thanks in > advance. > > Best wishes, > Henry Laxen > > -- > Nadine and Henry Laxen The rest is silence > Gral. Manuel Márquez de León 1301 > Onix #2302 > Zona Urban Rio Never try to teach a pig to sing; > Tijuana It wastes your time > +52 (333) 667-8633 And it annoys the pig > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: