Re: Cabal and GHC: the big picture

[Tom Ellis]

On Tue, Jul 16, 2024 at 02:51:07PM +0300, Oleg Grenrus wrote:
> package.db directory has only .conf files, but those conf files point to
> directories with interface and object files.
> I think every tool puts the interface and object files next to .conf files.

Right, but in principle I could do something different, couldn't I?  I
could take some subset of the .conf files in package.db, put them in a
directory called /tmp/mynewpackagedatabase, and *that* would be a
perfectly valid package database (as long as the files it points to
still exist), wouldn't it?

Tom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cabal and GHC: the big picture

[Tom Ellis]

Thanks Oleg.

On Tue, Jul 16, 2024 at 02:35:50PM +0300, Oleg Grenrus wrote:
> > This .cabal/store is not a package database.
> 
> .cabal/store/ **is** an ordinary package database.

The package database is the thing that contains the .conf files, isn't
it?  So perhaps you mean .cabal/store//package.db is an ordinary
package database?  If not it would be good if we can establish
precisely what is meant by "package database" and then clarify the
document.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How is account sign-up supposed to work?

[Tom Ellis]

Ah, that's good to see!  I copied the relevant information to the
Newcomers section too:

https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#newcomers-to-ghc

On Tue, Dec 12, 2023 at 01:01:42PM +0400, Andrei Borzenkov wrote:
> I think that this may be highlighted in the "newcomers" section, as you
> proposed, but
> "report a bug" wiki page already contains information about that you should
> ask for the account approval:
> 
> * https://gitlab.haskell.org/ghc/ghc/-/wikis/report-a-bug
> 
> 12.12.2023 12:50, Tom Ellis wrote:
> > Hello GHC devs,
> > 
> > It is hard for new users to understand how to get their new Gitlab
> > accounts approved by an administrator.  See, for example, these
> > messages, both in the last ten days:
> > 
> > * 
> > https://discourse.haskell.org/t/why-isalpha-can-parse-some-non-alphabetic-unicode-characters-like-chinese/8263/
> > 
> > * 
> > https://old.reddit.com/r/haskell/comments/18ge6vj/access_to_ghc_gitlab_for_reporting_ghcdebug_issues/
> > 
> > The Wiki doesn't seem to provide any guidance in the "Contributing" or
> > "Newcomers" sections.  Nor does ghc.dev.  Perhaps that's
> > understandable; GHC is not the Gitlab instance.
> > 
> > * https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing
> > 
> > * https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#newcomers-to-ghc
> > 
> > * https://ghc.dev/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

How is account sign-up supposed to work?

[Tom Ellis]

Hello GHC devs,

It is hard for new users to understand how to get their new Gitlab
accounts approved by an administrator.  See, for example, these
messages, both in the last ten days:

* 
https://discourse.haskell.org/t/why-isalpha-can-parse-some-non-alphabetic-unicode-characters-like-chinese/8263/

* 
https://old.reddit.com/r/haskell/comments/18ge6vj/access_to_ghc_gitlab_for_reporting_ghcdebug_issues/

The Wiki doesn't seem to provide any guidance in the "Contributing" or
"Newcomers" sections.  Nor does ghc.dev.  Perhaps that's
understandable; GHC is not the Gitlab instance.

* https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing

* https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#newcomers-to-ghc

* https://ghc.dev/

So how is a new user supposed to know how to get their accounts
approved?  It would be nice to make the process super clear.  This is
a longstanding issue.

Tom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Build GHC in GHC2021

[Tom Ellis]

On Thu, Dec 07, 2023 at 12:53:02PM +, Richard Eisenberg wrote:
> I think this is an excellent idea! So excellent, that we've already done it. 
> :)
> 
> When I try to compile with GHC 9.6.2 (what I have lying around), GHC2021 is 
> in effect.
> 
> Is there something different you were thinking of?

I think Arnaud meant that compilations of GHC's codebase itself should
use the GHC2021 setting.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: SSH on Gitlab

[Tom Ellis]

FWIW if I try the same command I get all the way through to a normal
exit (which I guess is expected since you're not supposed to be able
to actually obtain a shell via ssh!) so I guess the problem is
specific to you, Simon.

Tom



OpenSSH_8.4p1 Debian-5+deb11u1, OpenSSL 1.1.1n  15 Mar 2022
debug1: Reading configuration data /home/tom/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf 
matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to gitlab.haskell.org [2604:1380:61:2300::1] port 22.
debug1: Connection established.
debug1: identity file 
debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u1
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.1
debug1: match: OpenSSH_9.1 pat OpenSSH* compat 0x0400
debug1: Authenticating to gitlab.haskell.org:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-ed25519 
SHA256:/dI7zsBRZNPB+0TqskF7rSaZ/LhQw0cF4c5W+4uMlRo
debug1: Host 'gitlab.haskell.org' is known and matches the ED25519 host key.
debug1: Found key in 
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: 
server-sig-algs=
debug1: kex_input_ext_info: publickey-hostbo...@openssh.com (unrecognised)
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: 
publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: 
debug1: Authentications that can continue: 
publickey,password,keyboard-interactive
debug1: Offering public key: 
debug1: Server accepts key: 
debug1: Authentication succeeded (publickey).
Authenticated to gitlab.haskell.org ([2604:1380:61:2300::1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessi...@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys...@openssh.com want_reply 0
debug1: Remote: /var/gitlab/state/home/.ssh/authorized_keys:857: key options: 
command user-rc
debug1: Remote: /var/gitlab/state/home/.ssh/authorized_keys:857: key options: 
command user-rc
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
PTY allocation request failed on channel 0
Welcome to GitLab, @tomjaguarpaw1!
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype e...@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to gitlab.haskell.org closed.
Transferred: sent 3296, received 2832 bytes, in 0.4 seconds
Bytes per second: sent 9134.7, received 7848.7
debug1: Exit status 0



On Thu, Jun 22, 2023 at 11:15:28AM +0100, Simon Peyton Jones wrote:
> Is SSH working on gitlab.haskell.org?  I'm getting this
> 
> simonpj@CDW-8FABODHF0V5:~$ ssh -v g...@gitlab.haskell.org
> OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f  31 Mar 2020
> debug1: Reading configuration data /home/simonpj/.ssh/config
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf
> matched no files
> debug1: /etc/ssh/ssh_config line 21: Applying options for *
> debug1: Connecting to gitlab.haskell.org [145.40.64.137] port 22.
> debug1: Connection established.
> debug1: identity file /home/simonpj/.ssh/id_rsa type 0
> debug1: identity file /home/simonpj/.ssh/id_rsa-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_dsa type 1
> debug1: identity file /home/simonpj/.ssh/id_dsa-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_ecdsa type -1
> debug1: identity file /home/simonpj/.ssh/id_ecdsa-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk type -1
> debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_ed25519 type 3
> debug1: identity file /home/simonpj/.ssh/id_ed25519-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_ed25519_sk type -1
> debug1: identity file /home/simonpj/.ssh/id_ed25519_sk-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_xmss type -1
> debug1: identity file /home/simonpj/.ssh/id_xmss-cert type -1
> debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4
> 
> At this point it hangs.  Stackoverflow suggests
> a
> server fault. 

Re: help migrating a tool that uses the ghc api

[Tom Ellis]

On Thu, May 18, 2023 at 10:05:34PM +0100, Sam Halliday wrote:
> 1. some programming language communities have a "community build" that
>is periodically built by snapshots of the compiler. This allows
>unexpected regressions to be caught early in the dev cycle and would
>allow the author of refactor changes to send a courtesy patch to keep
>the broken code running if the change is intended to be kept in the
>compiler. I'd like to propose hsinspect for such a community build.

Hi Sam, there are a couple of ways something like this could work:

1. Team GHC tracks a set of packages and can send fixes ahead of time.

2. Packages track GHC and can fix themselves ahead of time.


I believe you're proposing 1, and I think it already exists:

http://ghc.gitlab.haskell.org/head.hackage/

I understood that head.hackage ran on the entirety of Hackage so
hsinspect[1] should have been picked up by it.  I lack a lot of
knowledge about head.hackage though, so perhaps someone with more
knowledge can chime in.


If you're interested in 2 then the Haskell Foundation is working on
making nightly builds of GHC accessible.  The latest I've heard is
from David Christiansen (HF Executive Director) on Discourse:


https://discourse.haskell.org/t/haskell-foundation-february-2023-update/5896#requirements-gathering-for-nightly-releases-6

If you're interested I suggest you get in touch with David (perhaps on
that thread).

Tom


[1] https://hackage.haskell.org/package/hsinspect-0.0.18
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 9.6.1 rejects previously working code

[Tom Ellis]

On Wed, Apr 12, 2023 at 02:32:43PM +0530, Harendra Kumar wrote:
> instance MonadIO m => Monad (T m) where
> return = pure
> (>>=) = undefined
> 
> instance MonadTrans T where
> lift = undefined

I guess it's nothing to do with 9.6 per se, but rather the difference
between

* 
https://hackage.haskell.org/package/transformers-0.5.6.2/docs/Control-Monad-Trans-Class.html#t:MonadTrans

* 
https://hackage.haskell.org/package/transformers-0.6.1.0/docs/Control-Monad-Trans-Class.html#t:MonadTrans

I'm not sure I can see any solution for this.  A monad transformer `T`
must give rise to a monad `T m` regardless of what `m` is.  If `T m`
is only a monad when `MonadIO m` then `T` can't be a monad transformer
(under transformers 0.6).

Tom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Deprecating Safe Haskell, or heavily investing in it?

[Tom Ellis]

On Tue, Dec 27, 2022 at 08:33:04PM -0700, Chris Smith wrote:
> This conversation reminds me of a parable I encountered somewhere, in which
> someone declares "I don't understand why this decision was ever made, and I
> we should change it", and someone responds, "No, if you don't understand
> the decision was made, then you don't know enough to change it.  If you
> learn why it was decided that way in the first place, then you will have
> the understanding to decide whether to change it."

That parable is Chesterton's fence:

https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How to exploit ./hadrian/ghci to find errors quickly?

[Tom Ellis]

On Fri, Jan 28, 2022 at 11:52:00AM -0500, Norman Ramsey wrote:
>  > My recommendation: ./hadrian/ghci. 
> 
> I'm about to change a type definition.  This change may wreak havoc in
> many parts of GHC, and this is exactly what I want: I'm looking for
> type-error messages that will tell me what code I need to fix.
> I do this work in emacs using `M-x compile` and `next-error`.  The key
> property is that `next-error` requires just a couple of keystrokes
> (C-x `) and it makes Emacs take me to the relevant source-code
> location quickly.
> 
> But telling `M-x compile` to run `./hadrian/build` is quite slow.  Is
> there a way to leverage `./hadrian/ghci` for this workflow?

Are you familiar with dante-mode for Emacs?  It relies on ghci behind
the scenes to point out type errors in Emacs Haskell buffers.  You
might find it convenient even if only for this single-purpose use
case.  I wrote up how I use dante:

http://h2.jaguarpaw.co.uk/posts/how-i-use-dante/

You will have to `M-x customize-group dante` to set the GHCi path to
`.../hadrian/ghci`.

Tom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab

[Tom Ellis]

On Thu, Oct 21, 2021 at 11:10:38AM +0200, Sam Derbyshire wrote:
> I'm also getting error 500 now.

Where?  When visiting gitlab.haskell.org in your browser or when
using git on the command line?

Tom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab

[Tom Ellis]

On Thu, Oct 21, 2021 at 08:59:48AM +, Simon Peyton Jones via ghc-devs wrote:
> Is it just me, or is Gitlab offline again?  I'm getting error code 500.

I just checked the following, which all work fine:

* Navigate to https://gitlab.haskell.org/ghc/haddock (in Firefox)

* git clone https://gitlab.haskell.org/ghc/haddock.git /tmp/haddock 

* git clone g...@gitlab.haskell.org:ghc/haddock.git /tmp/haddock-2

Simon, can you give more precise details about the problem you are
experiencing?

Tom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: gitlab.haskell.org

[Tom Ellis]

If a sponsor (perhaps the HF) could pay for GitLab to host the service
on our behalf would that be helpful?  I don't know whether GHC
development relies deeply on some aspect of our self-hosted setup.
(I suspect it does because otherwise we'd likely be using a free
GitLab tier for open source organisations, but I thought the question
was worth asking.)

Tom

On Mon, Oct 18, 2021 at 10:12:07AM +0100, Matthew Pickering wrote:
> I restarted the service and things appear to be working atm.. but I
> don't understand how the volumes are configured on the machine so will
> have to wait for Ben to fix it properly.
> 
> On Mon, Oct 18, 2021 at 9:11 AM Zubin Duggal  wrote:
> > It is not just you, Gitlab has been unstable since yesterday due to a
> > lack of disk space.
> >
> > On 21/10/18 07:29, Simon Peyton Jones via ghc-devs wrote:
> > >I'm getting "502" from gitlab.haskell.org.   Is it just me?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ghcup failed

[Tom Ellis]

On Wed, Jun 02, 2021 at 07:06:59PM +, Simon Peyton Jones via ghc-devs wrote:
> Dear devs
> I wanted to install GHC 8.10 on my WSL2 (Windows Subsystem for Linux) 
> computer.
[...]
> ghc-pkg: Couldn't open database 
> /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d for 
> modification: {handle: 
> /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d/package.cache.lock}:
>  hLock: invalid argument (Invalid argument)

Turns out it was actually WSL1 and upgrading to WSL2 resolved the
problem.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: value of documenting error messages?

[Tom Ellis]

On Wed, Jun 02, 2021 at 07:03:25PM +, Richard Eisenberg wrote:
> > To me this seems like a rare opportunity to do something where people
> > will say "Hey look, that formidable Haskell compiler is doing
> > something that's friendlier than the equivalent in any other
> > compiler!".  For such an important user-facing feature I don't
> > understand why we're not asking users what they prefer.
> 
> I agree completely here! Let's ask! (Remember that this thread,
> posted to ghc-devs, was originally about documenting the GHC source
> code, something that would not affect users.)

Yes indeed.  Let's one of us start a user-focused thread elsewhere
(whoever gets round to it first) and post a link here so interested
parties here can join in.

Tom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: value of documenting error messages?

[Tom Ellis]

On Wed, Jun 02, 2021 at 06:13:17PM +, Richard Eisenberg wrote:
> I'm in favor of short, undescriptive, quite-possibly numeric error
> codes.

These responses are so completely opposite to what I expected that I
can't help thinking I've made a fundamental error in my understanding
of what we're trying to achieve!  Since no one has suggested any
support for the idea of descriptive error codes I'm pressing on mostly
in the hope that someone will be able to see from where my
misunderstanding arises and set me straight.

Before I continue, I'd like to suggest that this is very much a
user-facing issue and I would be strongly in favour of actually asking
users about what they prefer (and allowing them to discuss for a
while) rather than taking a straw poll amongst GHC developers.

To that end, would it be inappropriate of me to link this discussion
to Haskell Reddit and/or Haskell Discourse?

> Advantages:

> Easy to sequentialize. We might have, for example, a
> "conflicting_trait_implementations" from this year, move on from
> that design, and then accidentally reintroduce it in a decade, to
> confusion. Along similar lines, it is easy to write in a comment
> somewherewhat the next error code should be, without having to
> search the codebase for a use.

I don't understand at all why it's valuable to sequentialize.  Is the
relative ordering of error codes meaningful in some way?

I don't see why deprecating an error code and reintroducing it is a
problem any more than doing the same to a function or GHC extension.

If we are *really* desperate to disambiguate then
conflicting_trait_implementations_2021 still seems better to me than
E195.

> Easy to make compositional. We can choose to have all GHC error
> codes begin with G (for GHC). Then Cabal could use C, Haddock could
> use H, and Stack could use S. This makes it easy for users to tell
> (once they've learned the scheme) where an error has come from.

Surely the same holds for descriptive error codes.  One could have
G_conflicting_trait_implementations, H_malformatted_section_header,
...

> Short.

Again I must be misunderstanding.  Why is brevity valuable?  Aren't we
expecting users to read these things and look them up?  Copy/paste is
free.

> No chance for misspellings during transcription. When I'm copying a
> terse identifier, I know I have to get every glyph correct. If I
> remember that the error code is "bad_generalizing", I might not know
> how "generalizing" is spelled. I might also forget whether it's
> "generalizing" or "generalization". And I could very easily see
> myself making either both of these mistakes as I'm switching from
> one window to another, in under a second.

Surely it's just as easy to mistype E159 as E195 as it is to misspell
"generalise".  As above, copy/paste is free and if we *really* want to
be helpful then instead of naked error codes we should give URLs whch
directly link to sections in the GHC users guide (or other appropriate
resource).

> Disadvantages:

> The code does not impart semantic meaning. But I argue this is not
> so bad, as even a more descriptive code does not impart a precise
> enough semantic meaning to be helpful.

I challenge you to name your next GHC extension X25!

> > On Jun 2, 2021, at 1:49 PM, Tom Ellis
> >  wrote:
> >
> > If we really think that non-descriptive codes are the clearest way
> > to communicate between machines and humans then I wonder if we
> > should rename `mapAccumL` to `F392` and `TypeFamilies` to `X56`.
>
> I think this is a false equivalence. The error codes are meant to be
> looked up when you see them on your screen, not remembered and then
> produced at will.

Possibly ... possibly not.

"Hey Anna, what should I do about E159?"

"Hey Anna, what should I do about conflicting_trait_implementations?"

Which would I prefer to shout to my colleague across the room?


To me this seems like a rare opportunity to do something where people
will say "Hey look, that formidable Haskell compiler is doing
something that's friendlier than the equivalent in any other
compiler!".  For such an important user-facing feature I don't
understand why we're not asking users what they prefer.

Where could I be going wrong in my understanding?

Tom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: value of documenting error messages?

[Tom Ellis]

On Wed, Jun 02, 2021 at 11:22:47AM -0400, Ruben Astudillo wrote:
> I am no GHC developer, so this is not my place to reply. Even though I
> humbly would like to put an argument in favor of numbers.

The issue of error codes impinges more on GHC users than GHC
developers (although it's also a bit tangential to Richard's original
post).

> On 02-06-21 06:46, Tom Ellis wrote:
> > On Tue, Jun 01, 2021 at 03:40:57PM -0700, Alec Theriault wrote:
> >> Rust has taken an interesting approach for this: every error message is
> >> given a unique number like "E0119"
> > 
> > Is there a particularly strong reason to use numbers as codes when we
> > have the entire space human-readable strings available to us?  Even
> > the subset of case-insensitive strings formed from alphanumeric
> > characters plus underscore seems more suitable for the encoding than
> > positive integers.
> > 
> > e.g. "conflicting_trait_implementations" seems better than "E0119"
> 
> One is SEO-optimization. A number like #0119 on a search string like "ghc
> error #0119" ought to have as a first result the GHC user docs. This is a
> great user experience for students. A more general search string can have
> more results on other languages and is difficult to say we would be first
> result.
> 
> Second one is that a number is shorter than a general string. That way we
> can highlight it on a error message on the terminal without occupying to
> much space. Current messages in GHC are already too big.

I'm surprised by the responses to the idea of descriptive error codes
(not just Ruben's response).

"ghc error #0119" seems like no better a search string than "ghc error
conflicting_trait_implementations" (and I can concoct reasons why it
would be worse).  Non-descriptive error codes risk being buried in
results about food additives[1] amongst myriad other things.

If we really think that non-descriptive codes are the clearest way to
communicate between machines and humans then I wonder if we should
rename `mapAccumL` to `F392` and `TypeFamilies` to `X56`.

Tom

[1] https://en.wikipedia.org/wiki/E_number#Full_list
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: value of documenting error messages?

[Tom Ellis]

On Tue, Jun 01, 2021 at 03:40:57PM -0700, Alec Theriault wrote:
> Rust has taken an interesting approach for this: every error message is
> given a unique number like "E0119"

Is there a particularly strong reason to use numbers as codes when we
have the entire space human-readable strings available to us?  Even
the subset of case-insensitive strings formed from alphanumeric
characters plus underscore seems more suitable for the encoding than
positive integers.

e.g. "conflicting_trait_implementations" seems better than "E0119"

Tom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Configuration documentation (Was Re: GitLab is down: urgent)

[Tom Ellis]

On Fri, Mar 19, 2021 at 07:08:35PM +, Richard Eisenberg wrote:
> > On Mar 19, 2021, at 2:21 PM, Gershom B  wrote:
> > Cc: ad...@haskell.org which remains (since it was set up over five?
> > years ago) the contact address for haskell infra admin stuff.
> 
> How would I learn of that address? Who is ad...@haskell.org?
> 
> > There's also, as there has always been, the
> > #haskell-infrastructure irc channel.
> 
> How would I learn of this?

By way of clarification, both of these contact details are mentioned
in the document that Gershom linked:

https://github.com/haskell-infra/haskell-admins#the-team-and-how-to-contact-them

Thanks for that document, Gershom, it's very helpful!

Tom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: WSL2

[Tom Ellis]

On Thu, Mar 11, 2021 at 06:19:46AM -0500, Viktor Dukhovni wrote:
> On Thu, Mar 11, 2021 at 06:05:04AM -0500, Viktor Dukhovni wrote:
> > So the question is why the lookup is failing.  To that end compiling a
> > tracing with "strace" the below C program should tell the story:
[...]
> To experiment with other group names and make sure that at least
> group "root" or similar works, a slightly extended version is:
[...]

I'm not really following the details, but is this useful to you?

% cat g.c && cc g.c -o g && ./g
#include 
#include 
#include 
#include 

int main(int argc, char **argv)
{
char buf[1024];
struct group g, *p;
int rc;

errno = 0;
rc = getgrnam_r(argc > 1 ? argv[1] : "nosuchgrouphere",
&g, buf, sizeof(buf), &p);
printf("%s(%p) %m(%d)\n", p ? g.gr_name : NULL, p, errno);
return (rc == 0 && p == NULL);
}
(null)((nil)) No such process(3)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

What type of performance regression testing does GHC go through?

[Tom Ellis]

A user posted the following to the ghc-proposals repository.  Both JB
and RAE suggested ghc-devs as a more appropriate forum.  Since I have
no idea whether the user has even ever used a mailing list before I
thought I would lower the activation energy by posting their message
for them.

https://github.com/ghc-proposals/ghc-proposals/issues/410

> Hi,
> 
> Does the GHC release or development process include regression
> testing for performance?
> 
> Is this the place to discuss ideas for implementing such a thing and
> to eventually craft a proposal?
> 
> I believe the performance impact of changes to GHC needs to be
> verified/validated before release. I also believe this would be
> feasible if we tracked metrics on building a wide variety of
> real-world packages. Using real-world packages is one of the best
> ways to see the actual impact users will experience. It's also a
> great way to broaden the scope of tests, particularly with the
> combination of language pragmas and enabled features within the
> compiler.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: WSL2

[Tom Ellis]

SPJ Wrote:
> I've just installed WSL2 and built GHC. I get this (single)
> validation failure in libraries/unix/tests/getGroupEntryForName.  It
> seems to be just an error message wibble, but I can't push a change
> to master because that'll affect everyone else.

Interesting, I've only ever built GHC on WSL and WSL2. I've seen this
error message on WSL2 during every test run, I think.  I didn't
realise that it never occurred on other platforms, let alone that it
was WSL2 specific!

Tom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Help needed: Restrictions of proc-notation with RebindableSyntax

[Tom Ellis]

On Wed, Dec 21, 2016 at 01:49:33PM -0600, amin...@gmail.com wrote:
> Additionally, Opaleye uses Arrow syntax pretty heavily iirc.

If I were writing the Opaleye tutorial today (and if I rewrite it) I will
shy away from arrows and encourage users to use applicative style.  There's
only one operator where applicative is not enough, 'restrict', and that can
be wrapped up as a different combinator so that no one knows they're ever
using arrows.

Tom

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Help needed: Restrictions of proc-notation with RebindableSyntax

[Tom Ellis]

On Wed, Dec 21, 2016 at 05:52:34PM +0100, Boespflug, Mathieu wrote:
> And Opaleye (a successor to haskellDB, for safe interaction with SQL
> databases) also uses arrow notation last I checked. As I recall do-notation
> is too powerful, whereas proc-notation provides exactly the right
> expressive power (no illegal SQL queries can be expressed). But that's not
> to say Tom (author of Opaleye) couldn't be content with a profunctor-based
> desugaring rather than an Arrow-based one?

I don't see any particular reason to oppose a profunctor-based desugaring. 
The structure of the computation would be the same, just encoded using
different classes.

Tom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Case expressions in STG

[Tom Ellis]

On Wed, Jun 18, 2014 at 07:40:26PM -0400, William Knop wrote:
> f = \x -> x
> g = \x -> (x,1)
> h = \x -> fst (g x)
> i = \x -> case f of
>   f -> True
>   _ -> False
> 
> i f => True
> i h => ?
> 
> If g isn't inlined into h and fst optimized out, wouldn't the head normal
> form of f and h be different, and the comparison fail even though it
> shouldn't?  Or should it?  I've taken function equality to be "f and g are
> equal iff f x == g x, for all x."

You mean 'i = \x -> case x of' ...

Anyway, I'm not suggesting using case to *compare* functions, simply force
their thunk before proceeding with a single default alternative.

Tom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Case expressions in STG

[Tom Ellis]

On Wed, Jun 18, 2014 at 11:04:22PM +, Simon Peyton Jones wrote:
> I've forgotten what I intended in the STG paper, but GHC's Core language
> certainly allows case on a function; all it does is to force the function
> to head normal form.

Right, that's what I imagined.  I will have a look for some more up-to-date
references to see how this works in modern GHC.

Tom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Case expressions in STG

[Tom Ellis]

I am reading SPJ's seminal work "Implementing lazy functional languages on
stock hardware: the Spinless Tagless G-machine" (1992).  The paper is
available here

http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.3729

On p62 we see "The expression scrutinised by a case expression must
eventually evaluate either to a primitive value or a constructor
application.".

This doesn't make sense to me.  Isn't the following a valid STG program? 
What am I missing?  Where is it specified that the scrutinee of a case
expression cannot be of a function type?

{x} \n {z} -> let f = \{x} \n {y} -> g x y
  in case f of f' -> f' z

Thanks,

Tom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs