- ghc-devs - Haskell.org

Problem building 9.4.7 on Fedora 36 (bytestring/cbits/is-valid-utf8.c)
by Viktor Dukhovni 15 Aug '23

15 Aug '23

The build was failing, because rts/OSThreads.h via Rts.h from libraries/bytestring/cbits/is-valid-utf8.c had no definition of `clockid_t`. This type is not exposed with _POSIX_C_SOURCE is not defined to a sufficiently high value: SYNOPSIS #include <time.h> int clock_getres(clockid_t clockid, struct timespec *res); int clock_gettime(clockid_t clockid, struct timespec *tp); int clock_settime(clockid_t clockid, const struct timespec *tp); Link with -lrt (only for glibc versions before 2.17). Feature Test Macro Requirements for glibc (see feature_test_macros(7)): clock_getres(), clock_gettime(), clock_settime(): _POSIX_C_SOURCE >= 199309L I quick-and-dirty work-around was: --- a/libraries/bytestring/cbits/is-valid-utf8.c +++ b/libraries/bytestring/cbits/is-valid-utf8.c @@ -27,6 +27,10 @@ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ +#undef _POSIX_C_SOURCE +#define _POSIX_C_SOURCE 200809L +#undef _XOPEN_SOURCE +#define _XOPEN_SOURCE 700 #pragma GCC push_options #pragma GCC optimize("-O2") #include <stdbool.h> There's surely a better solution. -- Viktor.

3 3

BoxedRep UNPACK pragma
by Alan & Kim Zimmerman 12 Aug '23

12 Aug '23

I have seen the following warning on master for some time compiler/GHC/Core/TyCon.hs:1540:5: warning: • Ignoring unusable UNPACK pragma on the first argument of ‘BoxedRep’ • In the definition of data constructor ‘BoxedRep’ In the data type declaration for ‘PrimRep’ | 1540 | | BoxedRep {-# UNPACK #-} !(Maybe Levity) -- ^ Boxed, heap value | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Is it something that needs to be fixed? Can the code be updated to remove the warning? Alan

3 2

Thread on Discourse - HIE file processing
by David Christiansen 10 Aug '23

10 Aug '23

Dear GHC devs, I think that having automated security advisory warnings from build tools is important for Haskell adoption in certain industries. This can be done based on build plans, but a package is really the wrong granularity - a large, widely-used package might export a little-used definition that is the subject of an advisory, and it would be good to warn only the users of said definition (cf base and readFloat). Tristan is exploring using HIE files to do this check, but I don't know if you read Discourse, where he posted the question: https://discourse.haskell.org/t/rfc-using-hie-files-to-list-external-declar… Thanks! David

3 4

Re: GitLab approval
by cydparser 10 Aug '23

10 Aug '23

I have a GitLab account, but am unable to perform basic actions like fixing broken links on wiki pages or adding a label to a MR that I created. The GHC project overview has a link with "Withdraw Access Request" at the top, so perhaps I need access rather than approval. ---------- Forwarded message ---------- > From: Ben Gamari <ben(a)smart-cactus.org> > To: ghc-devs(a)haskell.org > Cc: > Bcc: > Date: Wed, 09 Aug 2023 03:07:37 -0400 > Subject: Re: GitLab approval > I am a bit confused. It appears that you account has been active since > 2018. > > > On August 8, 2023 11:55:01 PM EDT, cydparser <cydparser(a)gmail.com> wrote: > >> Can a GitLab admin please approve my account (@cydparser). Thanks! >> >

2 1

GitLab approval
by cydparser 09 Aug '23

09 Aug '23

Can a GitLab admin please approve my account (@cydparser). Thanks!

2 1

Request for account approval for GHC non-moving GC bug reporting
by Christian Berentsen (chrberen) 08 Aug '23

08 Aug '23

We may have encountered a bug in the non-moving GC runtime, triggering: congregat-exe: internal error: nonmovingCollect: failed to spawn mark thread: Resource temporarily unavailable (GHC version 9.2.6 for x86_64_unknown_linux) Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug Need account approval for jc.berentsen(a)gmail.com to report, if this is not a duplicate Regards, Christian

3 4

Configure errors
by Simon Peyton Jones 07 Aug '23

07 Aug '23

Rodrigo I'm getting lots of errors from ./configure, see below. Seems to be something to do with your toolchain stuff? I'm lost. Should I worry? If not, could they be made to look less alarming somehow? Simon Entering: checking for C compiler checking for -Qunused-arguments support... Entering: checking for -Qunused-arguments support Execute: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c Command failed: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c Exited with code 1 found for -Qunused-arguments support: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} checking whether Cc supports --target... Entering: checking whether Cc supports --target Execute: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c Command failed: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c Exited with code 1 found whether Cc supports --target: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} checking whether Cc works... Entering: checking whether Cc works Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c found whether Cc works: () checking for C99 support... Entering: checking for C99 support Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c found for C99 support: () checking whether cc supports extra via-c flags... Entering: checking whether cc supports extra via-c flags Execute: /usr/bin/gcc -c -fwrapv -fno-builtin -Werror -x c -o /tmp/tmp0/test.o /tmp/tmp0/test.c found whether cc supports extra via-c flags: () found for C compiler: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} checking for C++ compiler... Entering: checking for C++ compiler x86_64-unknown-linux-g++ not found in search path x86_64-unknown-linux-clang++ not found in search path x86_64-unknown-linux-c++ not found in search path checking whether C++ supports --target... Entering: checking whether C++ supports --target Execute: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp Command failed: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp Exited with code 1 found whether C++ supports --target: Cxx {cxxProgram = Program {prgPath = "/usr/bin/g++", prgFlags = []}} Execute: /usr/bin/g++ -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp found for C++ compiler: Cxx {cxxProgram = Program {prgPath = "/usr/bin/g++", prgFlags = []}} checking for C preprocessor...

2 5

Getting all variables in scope in CoreM
by Rodrigo Mesquita 06 Aug '23

06 Aug '23

Dear GHC devs, I’m trying to invoke the GHC.Core.Lint linting functions from a Core GHC plugin. These functions take a LintConfig that can m <>ostly be constructed from DynFlags, <> the exception being <> <> l_vars :: ![Var] — ^ Ids that should be treated as being in scope My question is then “How can I get all variables in scope in the module underlying this CoreM computation, to pass in the LintConfig?”. My ultimate goal is to run LintM to determine the usage environment of a given core expression. In that sense, the “Id out of scope” errors aren’t that important to me, but they do make the linting action fail. Thanks in advance! Rodrigo

2 1

Call for Lightning Talks: Haskell Implementors' Workshop 2023
by Ryan Scott 02 Aug '23

02 Aug '23

ACM SIGPLAN Haskell Implementors' Workshop https://icfp23.sigplan.org/home/hiw-2023 Seattle, Washington, United States, September 4, 2023 Co-located with ICFP 2023 https://icfp23.sigplan.org/ --------------- The 15th Haskell Implementors' Workshop is to be held alongside ICFP 2023 this year in Seattle. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure to share their work and to discuss future directions and collaborations with others. We have a number of slots for lightning talks. Lightning talks will be ~7 minutes and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Lightning talks are proposed by submitting a title and an abstract. Submissions will not be part of the peer-review process. Notification of acceptance will be continuous until slots are full. Accepted lightning talks will be posted on the workshop’s website. Submissions should be made via this Google form: https://forms.gle/2jGceompwNghbRQR9 Accepted lightning talks will be posted on the workshop’s website. Scope and target audience ------------------------- The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community are encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are especially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Contact ------- * Ryan Scott <ryan.gl.scott at gmail.com>

1 0

Something to learn from: On Telemetry in the Rust compiler
by Hécate 01 Aug '23

01 Aug '23

We should all certainly learn something from reading this post on telemetry and user trust. I know I did: https://estebank.github.io/rustc-metrics.html Cheers, Hécate -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

1 0