GHC label conventions

[Ben Gamari]

Hello everyone,

I have documented our current conventions regarding GitLab label usage
on the Wiki [1]. Please do keep this up-to-date if you create, remove,
or rename a label.

As always, feedback is welcome

Cheers,

- Ben


[1] https://gitlab.haskell.org/ghc/ghc/wikis/GitLab-Labels/


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

Re: Proposal: Don't read environment files by default

[Brandon Allbery]

Nix instead of system, but roughly yes.

On Fri, Mar 29, 2019 at 5:46 AM Oleg Grenrus  wrote:

> To clarify: You mean different installations of same-version GHC? E.g.
> /opt/ghc/8.4.4/bin/ghc (HVR's) and /usr/bin/ghc (System default) which
> both happen to be 8.4.4 (so some other version)?
>
> - Oleg
>
> On 29.3.2019 5.44, Brandon Allbery wrote:
> > FWIW I've run into this one myself, and use (clones, if necessary, of)
> > v1 sandboxes for it currently.
> >
> > I've also been both bitten by, and helped by, environment files. The
> > former is somewhat nastier, especially if you have multiple versions
> > of ghc around and a given environment file was generated by a
> > different ghc.
> >
> > I also have a somewhat weird setup, because of how I ended up cobbling
> > this machine together: the global and user package dbs for my default
> > ghc are more or less "owned" by xmonad development, anything else is
> > in v2, a sandbox, or otherwise a different ghc version. Including nix,
> > also operating as a sandbox (that is, I use an alias to set up nix
> > within specific shells, rather than unconditionally loading its
> > config). Plus that "default ghc" is via wrappers around hvr's ghc
> > repos for Ubuntu. Which means I have lots of different ghcs around,
> > depending on which shell window I'm in. Not that I'm expecting anyone
> > to directly support this mess, but environment files seem to play
> > especially badly with multiple ghc versions with different packages
> > installed.
> >
> > On Thu, Mar 28, 2019 at 11:33 PM  > > wrote:
> >
> >
> > > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg
> >  escribió:
> > >
> >
> > [...]
> >
> > > 2. I get pilloried every time I say it, but I vastly prefer
> > global package databases to local ones.
> >
> > I'll second this in one specific context. v2-build has been
> > amazing at work and in general for project-based development, but
> > – and maybe simply because I don't know the right incantations – a
> > step backwards for impromptu coding where I don't want to set up a
> > whole project to start messing with an idea.
> >
> > I've actually fallen back to v1-install for this specific usecase:
> > I have a set of ~15 packages, all installed from local git repos,
> > some of which depend on others, that I *always* want when I'm in
> > GHCi. It's basically my base. I may simply be doing it wrong but
> > I've been unable to use the "global ghc.env file" trick successfully.
> >
> > Tom
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org 
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
> >
> > --
> > brandon s allbery kf8nh
> > allber...@gmail.com 
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Iavor Diatchki]

Hi Richard,

For use case 1)  we should probably make GHCi be more robust, and make it
notice that an environment file has become unusable, say so, and ignore it,
rather than refusing to work.  It is a bit of an odd way to synchronize
build artifacts though.

For 2), I like global databases too, and I think that this system is very
compatible with it---you can think of the "global" environment as a default
project that GHCi uses when there is no other project around.  I believe
something like that is already being developed.  In the mean-time, however,
I've just been using one "sand-box" cabal project that has just a cabal
file, and no source files---when I want to try stuff out, I just go to that
project and fire up `ghci`.  It avoids cabal hell as you can easily control
the versions of the libraries you need, if you care.  It is also cool, in
that you can put it on github, and be able to easily recreate the same
environment on different machines.  And having used that for a while, I've
noticed that perhaps I don't really want a global project, as I've evolved
a couple of different "sand-boxes" for different topics that I commonly
play around with.

As for your relevant scenario:  couldn't you just add the packages you want
to use to your cabal file and ask it to build them for you?  Then you'd
know what version of the package you are actually experimenting with.  I
haven't actually run into this issue much, so I can't recall what GHCi says
if you try to use a module from a package that is not part of the current
context, but it sounds like we may want to improve its message, if the
current situation is confusing.




On Thu, Mar 28, 2019 at 12:26 PM Richard Eisenberg  wrote:

>
>
> On Mar 28, 2019, at 3:09 PM, Herbert Valerio Riedel 
> wrote:
>
> That being said, I'd be more interested to know the actual problems
> people are having
>
>
> I've run into two problems. I don't expect others to run into these
> particular problems, as my workflows are likely different than others', but
> both of these bit me independently.
>
> 1. I use two different machines regularly. I keep my files in sync between
> them using Dropbox. Yet, the Haskell installations between are not
> identical. Even if the GHC version is the same, it's quite likely that some
> library, etc., has been installed at a different version on the two
> machines. (Sometimes, even the GHC is different.) I did some work on a
> project on machine 1; this produced an environment file. Then, machine 2's
> window happened to be in the project directory. I wanted to spin up GHCi to
> check the type of, e.g., traverse. But GHCi wouldn't launch! This is
> because machine 1's work produced the environment file which invisibly got
> copied to machine 2 (via Dropbox) and then GHCi tried to respect the
> environment file, even though I had no interest in interacting with that
> particular project at the moment. Frustration and confusion ensued.
>
> 2. I get pilloried every time I say it, but I vastly prefer global package
> databases to local ones. This is because, usually, I'm compiling individual
> Haskell files and not projects. These Haskell files are snippets of code I
> look at in order to spot a GHC bug and files students email me seeking help
> on. I therefore like to build up a healthy set of libraries in my global
> package database so I can just test-drive these files, without worrying
> about managing dependencies. (It is true that I sometimes run into
> old-style "cabal hell", but I also accept that this is an unavoidable
> consequence of using the global package database. By the time this happens,
> a new GHC has been released anyway, and I use the outdated package database
> as an excuse to upgrade.)
>
>   The actual relevant scenario is this: I open GHCi to load some files
> from a project, and I want to experiment with them. But I realize that I
> want to import a few modules from packages not otherwise used in the
> project (e.g., the 'extra' package) in order to conduct my experiments. But
> I can't do this, because the env file tells me I can't. Frustration and
> confusion ensued.
>
> I have a better understanding of all this now -- and the knowledge to
> disable these features -- but this is how I came to dislike these env
> files. In both cases, it was because I wanted to interact with Haskell in a
> way that wasn't fully encapsulated within a project. Perhaps in a "real
> company", this wouldn't happen, but many Haskellers are not in real
> companies. :)
>
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: gitlab.haskell.org is down

[Alp Mestanogullari]

GitLab should be back now, seems to be working fine for me (both using 
the web UI and fetching from ghc/ghc.git).


On 29/03/2019 09:46, Simon Peyton Jones via ghc-devs wrote:

Yes, I'm getting 500 too.

Simon

|  -Original Message-
|  From: ghc-devs  On Behalf Of Ömer Sinan
|  Agacan
|  Sent: 29 March 2019 06:20
|  To: Ben Gamari 
|  Cc: GHC developers 
|  Subject: Re: gitlab.haskell.org is down
|
|  I'm still getting 500.
|
|  Ömer
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


--
Alp Mestanogullari, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England and Wales, OC335890
118 Wymering Mansions, Wymering Road, London, W9 2NF, England

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

Re: Proposal: Don't read environment files by default

[Oleg Grenrus]

To clarify: You mean different installations of same-version GHC? E.g.
/opt/ghc/8.4.4/bin/ghc (HVR's) and /usr/bin/ghc (System default) which
both happen to be 8.4.4 (so some other version)?

- Oleg

On 29.3.2019 5.44, Brandon Allbery wrote:
> FWIW I've run into this one myself, and use (clones, if necessary, of)
> v1 sandboxes for it currently.
>
> I've also been both bitten by, and helped by, environment files. The
> former is somewhat nastier, especially if you have multiple versions
> of ghc around and a given environment file was generated by a
> different ghc.
>
> I also have a somewhat weird setup, because of how I ended up cobbling
> this machine together: the global and user package dbs for my default
> ghc are more or less "owned" by xmonad development, anything else is
> in v2, a sandbox, or otherwise a different ghc version. Including nix,
> also operating as a sandbox (that is, I use an alias to set up nix
> within specific shells, rather than unconditionally loading its
> config). Plus that "default ghc" is via wrappers around hvr's ghc
> repos for Ubuntu. Which means I have lots of different ghcs around,
> depending on which shell window I'm in. Not that I'm expecting anyone
> to directly support this mess, but environment files seem to play
> especially badly with multiple ghc versions with different packages
> installed.
>
> On Thu, Mar 28, 2019 at 11:33 PM  > wrote:
>
>
> > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg
>  escribió:
> >
>
> [...]
>
> > 2. I get pilloried every time I say it, but I vastly prefer
> global package databases to local ones.
>
> I'll second this in one specific context. v2-build has been
> amazing at work and in general for project-based development, but
> – and maybe simply because I don't know the right incantations – a
> step backwards for impromptu coding where I don't want to set up a
> whole project to start messing with an idea.
>
> I've actually fallen back to v1-install for this specific usecase:
> I have a set of ~15 packages, all installed from local git repos,
> some of which depend on others, that I *always* want when I'm in
> GHCi. It's basically my base. I may simply be doing it wrong but
> I've been unable to use the "global ghc.env file" trick successfully.
>
> Tom
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> -- 
> brandon s allbery kf8nh
> allber...@gmail.com 
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



signature.asc
Description: OpenPGP digital signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Daniel Trstenjak]

Hi Herbert,

On Thu, Mar 28, 2019 at 08:33:41PM +0100, Herbert Valerio Riedel wrote:
> I'm a programmer. I'm very used to devel tooling I'm expected to invoke
> as a programmer to be affected by what's in scope as a function of the CWD,
> e.g. `cabal`, `git`, `make` to name a few.

I think the difference here is, that tools like 'git' create and use the
environment by themselves. So it's IMHO a lot easier to get an intuition
about the behaviour of these tools.

That's not the case for 'cabal' creating an environment and 'ghc' using it.

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

RE: gitlab.haskell.org is down

[Simon Peyton Jones via ghc-devs]

Yes, I'm getting 500 too.

Simon

|  -Original Message-
|  From: ghc-devs  On Behalf Of Ömer Sinan
|  Agacan
|  Sent: 29 March 2019 06:20
|  To: Ben Gamari 
|  Cc: GHC developers 
|  Subject: Re: gitlab.haskell.org is down
|  
|  I'm still getting 500.
|  
|  Ömer
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: gitlab.haskell.org is down

[Ömer Sinan Ağacan]

I'm still getting 500.

Ömer

Ben Gamari , 29 Mar 2019 Cum, 00:46 tarihinde şunu yazdı:
>
> Ben Gamari  writes:
>
> > Shayne Fletcher via ghc-devs  writes:
> >
> >> Hi,
> >>
> >> It seems gitlab.haskell.org has been down since around 17:30 GMT. Outage?
> >>
> > Yes, I just sent notification of this. A routine service restart ended
> > up going wrong. In touch with our infrastructure company's support team.
> > More updates coming soon.
> >
> Gitlab.haskell.org is back up.
>
> Cheers,
>
> - Ben
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs