Thanks so much for making a proposal for this, Ben!! It's great to see
progress here.
I'm also glad that there is now a proposal process. I made a fairly
similar proposal almost exactly 5 years ago to the libraries list -
https://mail.haskell.org/pipermail/libraries/2015-April/025471.html - but
Cool! That's very nice that it only takes a few minutes from a clean tree.
I sometimes find it useful to also be able to run code from the repl.
Might be good to support both usage modes via hadrian. Though,
perhaps it's sufficient to have both this and
`utils/ghc-in-ghci/run.sh`
-Michael
On T
Ah, probably so, thanks!
On Sat, Mar 9, 2019 at 6:05 PM Brandon Allbery wrote:
>
> I think the public name is pointed to the staging site because the main one
> is down for the trac to github migration.
>
> On Sat, Mar 9, 2019 at 8:59 PM Michael Sloan wrote:
>>
>&g
Whoah, I can't get https://ghc.haskell.org/ to load at all - it's also
trying to use the gitlab.staging.haskell.org cert. I can't get chrome
to ignore the cert error because it's using HSTS - HTTP Strict
Transport Security.
On Sat, Mar 9, 2019 at 5:53 PM Michael Sloa
I just encountered this when doing a "git pull" on my Ubuntu 18.04.1 machine:
> fatal: unable to access 'https://gitlab.haskell.org/ghc/ghc/': server
> certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt
> CRLfile: none
Chrome also believes that the certificate of
https:
I don't have a good answer to your overall question, particularly when
reproducing the issue necessarily requires a large set of build
dependencies. However, one thing that may be helpful is to use `stack
build --cabal-verbose`. This will pass `--verbose` when running
Setup.hs, and ghc invocation
Hi Yotam,
Template Haskell expression quotes must start with either `[|` or
`[e|`, but instead these start with `[e |` - note the space. They are
list comprehensions which filter to just the elements of `es` that
match the `(dL -> L _ (Present _ e))`. Also, the `dL -> ...` portion
is a view patte
Great, I'm glad it's working well for you!
I've realized that when working on ghc-in-ghci, I didn't know about
freezing stage 1 to speed up GHC builds. For me the primary
motivation was that otherwise builds took quite long. Of course,
ghc-in-ghci is still quite useful, due to being able to use
ing
wrote:
> In practice, how much memory does this use?
>
> I find that with 4gb of memory that it is unusable and hard to kill.
> Perhaps we should add some sort of warning to the page about this.
>
> Cheers
>
> Matt
>
> On Wed, Aug 8, 2018 at 11:12 PM, Michael S
invocations.
[D5015]: https://phabricator.haskell.org/D5015
[ghcid]: https://github.com/ndmitchell/ghcid
On Mon, Aug 6, 2018 at 1:03 AM, Michael Sloan wrote:
> Thanks a bunch for updating the wiki page, Artem! It was on my todo
> list, but it's been a rather busy week. I've added an upd
>>
>> https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci
>>
>> Matt
>>
>> On Sun, Jul 29, 2018 at 6:18 AM, Michael Sloan wrote:
>> > Hello GHC developers!
>> >
>> > Now that D4904 and D4986 are merged, if you have recently built GHC
Hello GHC developers!
Now that D4904 and D4986 are merged, if you have recently built GHC
then you can use "./utils/ghc-in-ghci/run.sh -fobject-code" to load
GHC into GHCi (throwing on a "-j8" helps too). For me, this makes
development far more pleasant, as often I can make a change and try it
ou
.
-Michael
On Wed, Jun 27, 2018 at 10:48 PM Michael Sloan wrote:
>
> Wow! This is an absolute game changer for me with regards to ghc
> development. My usual workflow on large haskell projects is to use
> GHCI as much as possible for quick iterations. I'm really glad
> Cson
I asked about this on #ghc IRC and bgamari said that he's going to be
working on it tomorrow. I'm guessing that his comment of "man,
mariadb's treatment of full disks is abysmal" is related to the
problem.
I've been writing down the actions I'll take once it's back up.
On Mon, Jul 2, 2018 at 1:50
Wow! This is an absolute game changer for me with regards to ghc
development. My usual workflow on large haskell projects is to use
GHCI as much as possible for quick iterations. I'm really glad
Csongor figured this out and that you sent an email about it.
I've been messing with this for a bit
On Wed, Oct 5, 2016 at 7:05 PM, Brandon Allbery wrote:
>
> On Wed, Oct 5, 2016 at 10:02 PM, Michael Sloan wrote:
>>
>> What if instead we re-framed this as a "top-level where clause", like
>> this:
>>
>> main :: IO ()
>> main = putStrLn (&qu
It is really good to think in terms of a cleverness budget. Every
additional feature is not only implementation work, but also
maintenance, extra cognitive overhead when adding new features, an
extra thing for tooling outside of GHC to support. Personally, I'm on
the wall on this one. Here are t
On Wednesday, September 28, 2016, Eric Seidel wrote:
> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:
> > Moritz Angermann > writes:
> >
> > > All that arc essentially does is, compute the diff from an offset
> > > (e.g. master) to the current HEAD and upload that to a new or existing
> > > (-
On Wed, Sep 28, 2016 at 9:06 AM, Ben Gamari wrote:
> That being said, I ultimately decided it would be easier to just
> continue carrying out this workflow by hand considering I don't post
> large series of patches *that* often. I'm also a bit more eager to
> squash now than I used to be, in part
the integration works smoothly, I quite like this idea.
>
> Richard
>
>> On Sep 27, 2016, at 5:32 PM, Michael Sloan wrote:
>>
>> You're welcome Richard! I look forward to helping make it happen. In
>> the other thread, Alexander Vershilov mentioned that we
d they can be
reassured that it will get easier once automation is in place.
> Cheers,
> Moritz
>
>
> [1]:
> https://github.com/ghc-megacorp/ghc-proposals/blob/improved-ghc-development/proposals/-improved-ghc-development.rst
> [2]: See the contributing to ghc section in [
On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel wrote:
> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote:
>> Yes, I agree with Michael’s observations in the blog post. However, one
>> thing that’s easier about a wiki is that the editing process is much more
>> lightweight than making a PR.
>>
experience with Arcanist induced
some head-scratching. Not the fault of the tool, just a result of
lack of familiarity.
-Michael
On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg wrote:
> To sum up, this proposes the following:
>
> 1. Allow PRs on GitHub.
>
> 2. Michael Sloa
On Tue, Sep 27, 2016 at 8:20 AM, Alexander V Vershilov
wrote:
>
> About GitHub based contribution. It looks great for me for *all
> types* of the patches. But.. bot (or for some time person) should
> migrate *all* the patches to Phab, closing the threads for comments.
> Bot should write some welco
On Mon, Sep 26, 2016 at 12:40 PM, Simon Marlow wrote:
> On 26 September 2016 at 20:13, Ben Gamari wrote:
>>
>> Simon Marlow writes:
>>
>> > I would rather we *didn't* accept contributions via github, even for
>> > small
>> > patches, and instead put more effort into streamlining the Phabricator
straightforward process for shifting big patches
to Phabricator, then people who are regularly contributing via GitHub
PRs can be incrementally on-boarded to the Phabricator / Arcanist
workflow.
On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote:
> This sounds like an ideal solution, Ben! As has b
This sounds like an ideal solution, Ben! As has been discussed many
times before, GitHub has many users familiar with its interface. By
allowing GitHub PRs, the initial contribution
I think it would be acceptable for larger GitHub PRs to have some
automated boilerplate response. Ideally this wo
I like this solution a lot, Carter!
Mailing patches directly to the ghc-devs list could be intimidating
for newcomers. Having a list specific to patch review could make the
process less intimidating. From a perspective of overall contribution
intimidation, these 2 pages make it seem like a ton o
with it, but I also understand
that there is a lot of momentum and expertise around phabricator. If we
can knock down these barriers without a herculean effort, why not give it a
try?
-Michael Sloan
On Sat, Sep 24, 2016 at 6:56 PM, Brandon Allbery > wrote:
>
> On Sat, Sep 24, 2016 a
Sorry, but I see little sense in what you are bringjng to this discussion.
Chris's points sre explaining some systemic reasons WHY there is a dearth
of contributors, and attempting to make a constructive plan to address
them. Why should GHC not try to emulate a community that has fantasic
cohesion
As a side observer, I find Christopher's comments to be spot on. My
lack of familiarity with phab has definitely de-railed my in-flight
patch, adding implicit parameter and recursive do support to Template
Haskell. Certainly my own fault, but also induced by friction that
feels unnecessary.
On S
Interesting ideas!
What if #1 was implemented as a new declaration type that is allowed
in where clauses?
f x = SomeConstant where { unused x }
For #2, I would love to have a general system for declaring new types
of warnings that come with a way to dispatch the specific warning.
So, picking som
ing
that's a fairly fancy, nearly compiler-like transformation. Concerns
like the stability of Names should be handled by the TH user.
-Michael
On Wed, Jun 29, 2016 at 10:41 AM, Michael Sloan wrote:
> No, NameU and NameL both lack package key / package id.
>
> -Michael
>
> On
;PartialOrd' to
>> > > really handle these well. In that case, the ordering would be based on
>> > > everything but the NameU int, but 'Eq' would still follow it
>> > >
>> > > A few ideas for different approaches to resolving this:
>&
pealing than fixing it in the API, but still
> would
> > be good.
> >
> > 2) Remove the 'Ord' instance, and force the user to pick 'NamePartialOrd'
> > newtype (partial ord on the non-unique info), or 'UnstableNameOrd'
> newtype
> > (current beha
Right, part of the issue with having dependency solving at the core of your
workflow is that you never really know who's to blame. When running into
this circumstance, either:
1) Some maintainer made a mistake.
2) Some maintainer did not have perfect knowledge of the future and has not
yet update
re using the 'Ord' instance with 'Name's that are not 'NameU', so
this would break a lot of code that was already deterministic.
3) Some approaches like this ordering key, but I'm not sure how it will
help when comparing NameUs from different modules?
> S
+1 to solving this. Not sure about the approach, but assuming the
following concerns are addressed, I'm (+1) on it too:
This solution is clever! However, I think there is some difficulty to
determining this ordering key. Namely, what happens when I construct the
(Set Name) using results from mu
I have considered how to add this capability some in the past, it's
something I'd also like to have. Collecting the type info in the module
finalizer is an interesting idea! This may well be the cheapest way to get
the info necessary for this usecase.
As far as I understand it, currently we're i
Great! Thanks for y'all putting effort towards performance. It really is
crucial
for developer productivity.
In the particular case of haskell-src-exts, I found that removing many of
the
more complicated typeclasses from deriving (Data, Generics, etc) brought the
compilation time way down. IIRC it
I definitely think this should be considered a usage. Ideally, you should
always be able to resolve warnings, but there'd be no straightforward way
to do so if LHS-only usages cause warnings. Also, It's quite useful to use
type variables only on the LHS. Usage example:
https://hackage.haskell.or
The executable-path package wraps this up nicely with its `getScriptPath`
function:
https://hackage.haskell.org/package/executable-path-0.0.3/docs/System-Environment-Executable.html#v:getScriptPath
Probably best to use this existing function. Then, if a less fragile
solution comes along, getScri
gt;
> Try this out:
>
> https://gist.github.com/mainland/f18cf3827c4b0b64b835
>
> Have you had success generating instance declarations from top-level
> splices?
>
> Geoff
>
> On 02/11/2015 07:41 PM, Michael Sloan wrote:
>> Hi!
>>
>> I don't mean t
mented," what do you mean? What, exactly, is not
> implemented?
>
> Cheers,
> Geoff
>
> On 2/11/15 6:32 PM, Michael Sloan wrote:
>> I'd love for the implementation to be as powerful as the documentation
>> suggests it is :D
>>
>> However, yes, in the m
uel
> Chakravarty and Geoff Mainland were responsible for the implementation.
>
> Simon
>
> | -Original Message-
> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Michael
> | Sloan
> | Sent: 11 February 2015 23:19
> | To: Francesco Mazzoli
> | C
It seems like addTopDecls[1] will able to help here. Unfortunately,
the function is not well documented and not very discoverable because
it's only exported by Language.Haskell.TH.
The documentation doesn't mention that it can only be used to create
new top level functions and FFI imports[2]. I
One option for avoiding the warning without runtime overhead would be
to do something like this:
 f :: Ord a => a -> a -> Bool
f x y = True
where
_ = x < y
On Wed, Jan 7, 2015 at 7:27 AM, Johan Tibell wrote:
> I think this probably makes sense, especially since you can
47 matches
Mail list logo
