ific.
>
> Now I am truly baffled! If they don't do anything, why would they be a
> module at all! Surely they do something?
>
> Simon
>
> On Mon, 4 Dec 2023 at 11:58, Moritz Angermann
> wrote:
>
>> I don’t think they do anything specific. They just function as
recognised-pragmas.
>>
> which mentions HLINT pragmas but says nothing about what they do.
>
> Simon
>
> On Mon, 4 Dec 2023 at 09:05, Moritz Angermann
> wrote:
>
>> Any ANN annotation triggers the TH pipeline and makes them really painful
>> to work with,
Any ANN annotation triggers the TH pipeline and makes them really painful
to work with, in non-stage2 settings. Lots of Hlint annotations use ANN and
then you have iserv be triggered for each module that has an ANN annotation.
Luckily Hlint also support HLINT instead which removed the TH
said originally about marking patches for
> backport ASAP still applies.
>
> On 23/11/24 20:26, Moritz Angermann wrote:
> >Can I suggest the release to be pushed into 2024?
> >
> >Releasing it on the 15th or a few days later will put significant burden
> >
Can I suggest the release to be pushed into 2024?
Releasing it on the 15th or a few days later will put significant burden
onto integrators, and distributors. To react to the ghc release. Especially
right before the holiday season for quite some.
Cheers,
Moritz
On Fri, 24 Nov 2023 at 8:17 PM,
Something I haven’t gotten around to but only preliminary experiments with
is dynamically built iserv binaries.
Using -fexternal-interpreter can decouple the symbols the interpreter sees
and those the compiler sees (They can even be of different architectures).
iserv could be linked against the
I usually end up looking at the source I’m actually compiling and checking
if the expected changes are in the source or not. If not, I end up
backporting stuff to the source at hand. As this is often for compilers
that are way past their end of life cycle (e.g. 8.10), there seems little
point in
//gitlab.haskell.org/ghc/ghc/-/merge_requests/10367). So we have
>> some prior experience
>> with RISC-V.
>>
>> I understand you want to have support for RV32 in ghc? Are you looking
>> for _native_ RV32 support GHC the compiler running natively on RISC-V 32
>> hardwar
Hi George,
while I personally haven’t tried. I’d encourage you to just try. Unless
they changed their textual IR (they don’t do that often anymore), it could
just work.
Whether or not you run into bugs for the specific target you are looking
at, is hard to say without knowing the target.
My
The zw3rk runners should be back.
On Thu, 24 Nov 2022 at 17:41, Bryan Richter via ghc-devs <
ghc-devs@haskell.org> wrote:
> Hello again,
>
> After a few surprises, I have finished my migration.
>
> Unfortunately, CI IS STILL BROKEN.
>
> All CI runners disabled themselves while GitLab was in
Hi,
Does anyone know how to build a 9.2.4 windows cross compiler? Hadrian seems
to get in
the way a lot?
This is the essence of what we tried to get working:
./configure --enable-bootstrap-with-devel-snapshot
--build=x86_64-apple-darwin --host=x86_64-apple-darwin
--target=x86_64-w64-mingw32
Thanks Ben!
Just FYI: We do have folks actively deploying to iOS and Android at
simplex chat.
I do agree that we want this to be in the user guide though; as it’s quite
version dependent.
Cheers,
Moritz
On Fri, 23 Sep 2022 at 3:22 AM, Ben Gamari wrote:
> Simon Peyton Jones writes:
>
> >
Hi Hecate,
I don't think this is entirely fair in either direction. So sharing my
personal experience
might shed some light. I've often worked on GHC on fairly weak machines.
However
the ability to use HLS on GHC or even the ability to load GHC into GHCi are
fairly
recent additions.
I don't
Hi Alexis,
let me try to provide the high up view. I'm sorry if I'm going a bit
overboard on details you already know. But let's
start with clearing up a misconception first. No, GHCi does not always
require dynamic linking.
At the very abstract level we have a compiler that knows how to turn
The second one is an issue if it consumes CI Ressource. Ideally we’d have
only “blessed” repos allowed to consume CI. The issue with this is that
(random) new users can’t fork GHC and have CI run against their change.
I’d still very much like to see a solution to this; it is a security
concern.
Just to add to this. I think we should *optimize* for people not working
full time on GHC.
Anything that's going to be smooth for people working only a few hours a
week on GHC
will implicitly improve the situation for those working more hours on GHC
as well. As in
what is pleasant for someone with
pping through a program a tad more
> annoying, I think the “setting the yield timer to zero” is the work around
>
> D) the “source” you step through is essentially the c— z-encoded code? So
> you still need to do some puzzling out of stuff
>
>
> On Wed, Nov 17, 2021 at 7:
Hi Richard,
I’m not sure using platform native AND the term DWARF would help rather
than add to confusion. Let me still try to
help a bit with context here.
For Linux and most BSDs, we have settled on the Executable and Linking
Format (ELF) as the container format for
your machine code. And
(1), I would hope so. If not, that's a bug.
(2), hadrian supports --build-root=, such that you can have different build
product trees based from one source. One of the nice features of hadrian
is, that it finally is able to separate build and source directories, there
are still the inplace files,
Those errors in both logs seem fairly odd. The first one appears to be
mostly a missing libgmp, the second one looks like hsc2hs's template file
is missing, however hadrian should have a rule for that.
You can try to clean your tree and rebuild.
git clean -xfd
git submodule foreach git clean
to get into.
> So often my colleagues look to me whenever there's a new alpha or RC out
> to upgrade the plugins.
> But Sam's changes for solving type family constraints certainly give the
> impression that things will easier going forward!
> So now is probably the best time to hand over th
Hi Richard,
I believe that this is mostly due to plugin development happening to
satisfy a plugin need. I doubt there is a grand unified vision for
plugins. And I don't have one either. I've dabbled with codegen plugins a
long time ago, these days I'm primarily concerned with plugins having a
You can safely ignore the x86_64-darwin failure. I can get you the juicy
details over a beverage some time. It boils down to some odd behavior using
rosetta2 on AArch64 Mac mini’s to build x86_64 GHCs. There is a fix
somewhere from Ben, so it’s just a question of time until it’s properly
fixed.
Hi there!
You might have seen failed or stuck or pending darwin builds. Our CI
builders we got generously donated have ~250GB of disk space (which should
be absolutely adequat for what we do), and macOS BigSur does some odd
reservation of 200GB in /System/Volumes/Data, this is despite automatic
Fair point. From a view over the last few days, I’d say it’s closer to 100%
on libera. Lots of people just switched. Quite surprising.
On Fri, 21 May 2021 at 7:14 PM, Jens Petersen wrote:
> My vote goes for Matrix.
>
> I am not a heavy user yet, but I hope this episode helps to drive more
>
Matt has access to the M1 builder in my closet now. The darwin performance
issue
is mainly there since BigSur, and (afaik) primarily due to the amount of
DYLD_LIBRARY_PATH's
we pass to GHC invocations. The system linker spends the majority of the
time in the
kernel stat'ing and getelements (or
>
>* Upstream changes into Cabal to make your new compiler a first-class
> citizen. This is what GHCJS did.
Just a word of caution, please don't do this. It leads to non-negligible
maintainence burden on your and on the cabal side. Rather try as hard as
you can to make your compiler
I believe there is a bit of misconception about what requires a new backend
or not. GHC is a bunch of different intermediate representations from which
one can take off to build backends. The STG, or Cmm ones are the most
popular. All our Native Code Generators and the LLVM code gen take off from
Yes, this is exactly one of the issues that marge might run into as well,
the aggregate ends up performing differently from the individual ones. Now
we have marge to ensure that at least the aggregate builds together, which
is the whole point of these merge trains. Not to end up in a situation
ems you already backported this?
> See https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5263
>
> Cheers
> Andreas
> Am 22/03/2021 um 07:02 schrieb Moritz Angermann:
>
> The commit message from
> https://gitlab.haskell.org/ghc/ghc/-/commit/f10d11fa49fa9a7a506c4fdbdf86521c2a8d349
or backports but don't know if it was done or not.
>
> Thanks,
> Tamar
>
> Sent from my Mobile
>
> On Mon, Mar 22, 2021, 04:33 Moritz Angermann
> wrote:
>
>> Hi there!
>>
>> Does anyone have any backports they'd like to see
The commit message from
https://gitlab.haskell.org/ghc/ghc/-/commit/f10d11fa49fa9a7a506c4fdbdf86521c2a8d3495
,
makes the changes to string seem required. Applying the commit on its own
doesn't apply cleanly and pulls in quite a
bit of extra dependent commits. Just applying the elem rules appears
Davean has resurrected gitlab for now.
On Mon, Mar 22, 2021 at 12:31 PM Moritz Angermann <
moritz.angerm...@gmail.com> wrote:
> It appears as if gitlab went down again, this time since around 4AM UTC on
> Monday.
>
> On Sun, Mar 21, 2021 at 9:49 PM Ben Gamari wrote:
>
Hi there!
Does anyone have any backports they'd like to see for consideration for
8.10.5?
Cheers,
Moritz
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
It appears as if gitlab went down again, this time since around 4AM UTC on
Monday.
On Sun, Mar 21, 2021 at 9:49 PM Ben Gamari wrote:
> Moritz Angermann writes:
>
> > Just a heads up everyone. Gitlab appears down again. This seemed to have
> > happened around Sunday, 4AM UTC
gement and engineering.
>
> Best,
>
> Giorgio Marinelli
> https://marinelli.dev/cv
>
> On Sat, 20 Mar 2021 at 00:31, Moritz Angermann
> wrote:
> >
> > I can try to step up and be backup on the other side of the planet. Ben
> and I are almost 12hs apart exactly.
&g
I can try to step up and be backup on the other side of the planet. Ben and
I are almost 12hs apart exactly.
On Sat, 20 Mar 2021 at 1:32 AM, Richard Eisenberg wrote:
>
>
> On Mar 19, 2021, at 12:44 PM, howard.b.gol...@gmail.com wrote:
>
> I would like to help however I can. I already maintain
thy performance. But flagging
> performance regressions in MRs, while not making them block batched merges
> sounds like a reasonable compromise.
>
>
> On Wed, Mar 17, 2021 at 9:34 AM Moritz Angermann <
> moritz.angerm...@gmail.com> wrote:
>
>> *why* is a very good
1 at 9:22 AM Moritz Angermann <
> moritz.angerm...@gmail.com> wrote:
>
>> No it wasn't. It was about the stat failures described in the next
>> paragraph. I could have been more clear about that. My apologies!
>>
>> On Wed, Mar 17, 2021 at 4:14 PM Spiwack, Arnaud
>&
No it wasn't. It was about the stat failures described in the next
paragraph. I could have been more clear about that. My apologies!
On Wed, Mar 17, 2021 at 4:14 PM Spiwack, Arnaud
wrote:
>
> and if either of both (see below) failed, marge's merge would fail as well.
>>
>
> Re: “see below” is
Hi there!
Just a quick update on our CI situation. Ben, John, Davean and I have been
discussion on CI yesterday, and what we can do about it, as well as some
minor notes on why we are frustrated with it. This is an open invitation to
anyone who in earnest wants to work on CI. Please come forward
Hi Viktor,
- I believe the "test spaces" part is important and would need to be fixed,
if spaces break this is not desirable.
- For the Relocations part, I'm happy to offer guidance and help for anyone
who wants to take a stab at it, right
now I'm not in a position where I could take this on
things with no
> singular large goal. Or maybe we can involve a student with efforts to
> improve CI, attacking the root cause for why it's so hard to land things in
> the first place .
>
> John
> On 3/12/21 7:11 PM, Moritz Angermann wrote:
>
> Yes there is also John res
Yes there is also John resumable compilation ideas. And the current
performance work obsidian systems does.
On Sat, 13 Mar 2021 at 6:21 AM, Cheng Shao wrote:
> I believe Josh has already been working on 2 some time ago? cc'ing him
> to this thread.
>
> I'm personally in favor of 2 since it's
Moritz Angermann
wrote:
> At this point I believe we have ample Linux build capacity. Darwin looks
> pretty good as well the ~4 M1s we have should in principle also be able to
> build x86_64-darwin at acceptable speeds. Although on Big Sur only.
>
> The aarch64-Linux story is a
fails or succeeds, both of which require at least some attention from
> me: Failed 2 times => Make sure it was spurious, Succeeds => Rebase next
> change.
>
> Maybe we can also learn from other projects like Rust, GCC or clang, which
> I haven't had a look at yet.
>
>
Friends,
I've been looking at CI recently again, as I was facing CI turnaround times
of 9-12hs; and this just keeps dragging out and making progress hard.
The pending pipeline currently has 2 darwin, and 15 windows builds waiting.
Windows builds on average take ~220minutes. We have five
Tamar,
thanks so much for the backstory and the tickets. I’ll go dig down this
path a bit more.
Cheers,
Moritz
On Thu, 11 Feb 2021 at 5:31 PM, Phyx wrote:
> Hi, Just leaving my two cents feel free to ignore..
>
> > I almost suggested that this had to be the reason for the back-compat
>
and away from `make`.
>
> Richard
>
> > On Feb 10, 2021, at 8:05 AM, Moritz Angermann <
> moritz.angerm...@gmail.com> wrote:
> >
> > Hi,
> >
> > so we've finally run into a case where we need to bump the rts version.
> This has a great ripple effe
Hi,
so we've finally run into a case where we need to bump the rts version.
This has a great ripple effect. There is some implicit assumption that
rts-1.0 will always be true. Of course that was a lie, but a lie we lived
with for a long time.
Now, hadrian tries *really* hard to replicate some
Thanks for flagging this. This would be the opposite direction of what I’ve
been advocating for. That we get bindists for Linux and macOS that work by
simply unpacking them.
On Mon, 8 Feb 2021 at 10:05 PM, Takenobu Tani wrote:
> Hi devs,
>
> The ghc-binary for windows needs to `make install`
if we preserve correct argument
> size in Cmm (or at least enrich the hints to include it), we won't
> need such a hack.
>
> On Tue, Oct 20, 2020 at 4:05 PM Moritz Angermann
> wrote:
> >
> > Yes, that's right. I'm not sure it's in core though, as the width
> information sti
all unfoldings, no?
>
>
>
> Simon
>
>
>
> *From:* ghc-devs *On Behalf Of *Moritz
> Angermann
> *Sent:* 21 October 2020 10:36
> *To:* Ben Gamari
> *Cc:* Edward Yang (ezy...@cs.stanford.edu) ;
> ghc-devs@haskell.org
> *Subject:* Re: Fat interface files?
&g
Just to make sure we are aware of all the ongoing efforts. We've been
working on ebedding Core into interface files as well.
Josh has updated the Wiki page here
https://gitlab.haskell.org/ghc/ghc/-/wikis/Extensible-Interface-Files.
Cheers,
Moritz
On Wed, Oct 21, 2020 at 12:06 AM Ben Gamari
ndle cint being 32bit in this context ?
>
>
> On Tue, Oct 20, 2020 at 5:49 AM Moritz Angermann <
> moritz.angerm...@gmail.com> wrote:
>
>> Alright, let me expand a bit. I've been looking at aarch64 NCG for ghc.
>> The Linux side of things is looking really good,
>> so
don’t understand any of this. Not your fault, but I just
> don’t have enough context to know what you mean.
>
>
>
> Is there a current bug? If so, can you demonstrate it? If not, what is
> the problem you want to solve? Examples are always helpful.
>
>
>
> Maybe it
Hi there!
So there is a procedure calling convention that for reasons I did not fully
understand, but seem to be historically grown, uses packed arguments for
those that are spilled onto the stack. On top of that, CInt is 32bit, Word
is 64bits. This provides the following spectacle:
While we
I
wonder if there is something we got right by accident, that makes this work
smoothly for us. Warrants more investigation.
Cheers,
Moritz
On Tue, Sep 29, 2020 at 7:45 PM Moritz Angermann
wrote:
> Happy to give this a try later today. Been using fully static musl builds
> (including cross compila
LD_NOW);
>
> char *f = dlsym(h, "sqlite3_version");
>
> printf("%s\n", f);
>
> return 0;
>
> }
>
>
>
> On Tue, Sep 29, 2020 at 1:04 PM Moritz Angermann
>
> wrote:
>
> >
>
> > No. Not necessarily. We can perfect
No. Not necessarily. We can perfectly fine load archives and the pre-linked
ghci objects. However dlopen with musl on x86 seems fine. On arm it’s not
implemented, and just throws an error message. There is a -dynamic flag in
HEAD, which disables GHC even trying to load dynamic libraries and always
I think as long as it's bounded it's ok.
On Sat, Sep 26, 2020 at 8:52 PM Ben Gamari wrote:
> I think it would be worth trying to add tuples up to width 64. The only
> real cost here is the interface file size of GHC.Tuple and if adding a
> 63-wide tuple really does induce a crash then that is a
Luite is currently working on unboxed tuple support in the interpreter.
This will also be limited, as getting a generic solution for arbitrary
sized tuples raises a lot of complications.
Thus form a practical point of view, I’d go for (1) ;-)
We’ll need to rethink and get SIMD proper support at
Hi there!
As some may know I've been working on a native code generation backend for
aarch64[1]. When Ben initially wrote about The state of GHC on ARM[2], I
was quite skeptical if a native code generator would really be what we
should be doing. And the claim it would take a week or two, might
p 18, 2020 at 5:52 PM Adam Gundry wrote:
> On 14/09/2020 13:02, Moritz Angermann wrote:
> > I believe this to already be broken in HEAD. DynFlags already got quite
> > an overhaul/break. I'd rather we drop supporting DynFlagPlugins. And
> > offer alternative stable interfaces.
I believe this to already be broken in HEAD. DynFlags already got quite an
overhaul/break. I'd rather we drop supporting DynFlagPlugins. And
offer alternative stable interfaces. Though to be honest, I believe our
Plugin story is rather poor so far.
Do you happen to know of DynFlagPlugins, Adam?
Hi there!
in the non-threaded rts we use itimer to do light weight scheduling of
threads via SIGALRM signals. I'm seeing quite a bit of heap corruption on
aarch64, and it appears that I also see a lot of signal handling in the GC,
for example during evacuate.
Is there a fundamental reason why
ap into file during GC traversal or taking the whole
>>>> allocated area. hmm, maybe this is the same as core dump.
>>>>
>>>> On Mon, Aug 31, 2020 at 11:00 AM Ben Lippmeier
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>
Hi there!
as some of you may know, I've been working on an aarch64 native code
generator. Now I've hit a situation where my stage2 compiler somehow
corrupts my heap. Initially I thought this would likely be missing memory
barriers, however they are emitted. This doesn't mean it can't be, but
cross
compilation
and wine based) setup.
Cheers,
Moritz
On Sat, Aug 15, 2020 at 3:31 PM Moritz Angermann
wrote:
> Hi there!
>
> Thanks everyone for showing interest. I've started a wiki page here:
> https://gitlab.haskell.org/ghc/ghc/-/wikis/ghc-maintainers
> Please add yourself
an infinite loop. I don’t know if
> that’s what’s happening here, but it seems reasonable in principle.
>
>
>
> I’m unsure about what you are proposing to change.
>
>
> Simon
>
>
>
> From: Moritz Angermann
> Sent: 17 August 2020 13:28
> To: Simon Peyton Jon
ant to generate this code.
Once _cCO is entered, there is no way out for the application.
Cheers,
Moritz
>
>
>
> S
>
>
>
> | -Original Message-
>
> | From: Moritz Angermann
>
> | Sent: 17 August 2020 10:30
>
> | To: Simon Peyton Jones
re
> what role it plays in your thinking.
>
> Simon
>
>
> | -Original Message-
> | From: ghc-devs On Behalf Of Moritz
> | Angermann
> | Sent: 17 August 2020 09:40
> | To: ghc-devs
> | Subject: The curious case of #367: Infinite loops can hang Concurre
Hi there!
While working on a NCG, I eventually came across #367[0], which make GHC produce
code that looks similar to this:
```
label:
[non-branch-instructions]*
brach-instruction label
```
so essentially an uninterruptible loop. The solution for GHC to
produce code that
can be interrupted
Thanks,
> Hemanth
>
> On Tue, 11 Aug 2020, 07:40 Moritz Angermann,
> wrote:
>>
>> Hi there!
>>
>> As it stands right now, Ben is the one who works tirelessly trying to
>> cut releases. Not just for the most recent version, but also for
>> previous ve
Hi there!
As it stands right now, Ben is the one who works tirelessly trying to
cut releases. Not just for the most recent version, but also for
previous versions. Most recently 8.10.2, but we have 9.0 coming up as
well.
I know that there are some people who deeply care for personal or
Hi Mathieu,
you can! See http://hackage.mobilehaskell.org/; it's been one of the
design goals I had when I was hacking on hadrian. The whole configure
&& make install shenanigans were just too much.
Initially I wanted to drop that outright, but was convinced that
configure and make install is
This dependency on alex and happy to boot ghc has been annoying, but
wasn't that terrible until a while ago when some
ghc versions needed happy <= 1.19.11 and others happy >= 1.19.12. If
happy was part of ghc, this would not have been an issue.
As such I'd be on board with adding happy *and* alex
I think this is the core issue here:
> What should GHC’s extensibility interface be like? Plugins and all that.
> What is a good design for (say) extensible interface files? What “hooks”
> should the GHC API afford? This is more than just “what arguments should
> this function take”… it’s
10:45:37 +0800
> Moritz Angermann wrote:
>
> > Well, we actually *do* test for __SSP__ in HEAD:
> > https://github.com/ghc/ghc/blob/master/rts/RtsSymbols.c#L1170
> > Which currently lists:
> > #if !defined(mingw32_HOST_OS) && !defined(DYNAMIC) &&
&
880268dd6858eadd8c320f09e97#diff-03f5bc5a50fd8ae13e902782c4392c38R1157
>
> shouldn't it just be checking for defined(__SSP__) instead? This check is
> currently only correct if the distro has turned stack protector on by default.
>
>
> Regards,
> Tamar
>
> On Thu, Jul 16,
applying a fix, but then NOT committing that to
> master by mistake
>
>
>
> Thanks
>
> s
>
>
>
> *From:* Moritz Angermann
> *Sent:* 14 July 2020 12:14
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: HEAD doesn't build. Totally
anks. What specifically do I comment out?
>
>
>
> *From:* Moritz Angermann
> *Sent:* 14 July 2020 12:00
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: HEAD doesn't build. Totally stalled.
>
>
>
> This was my fault. Not sure why this wa
This was my fault. Not sure why this wasn’t caught in CI.
It’s due to the addition of the symbols here
https://github.com/ghc/ghc/commit/686e72253aed3880268dd6858eadd8c320f09e97#diff-03f5bc5a50fd8ae13e902782c4392c38R1159
You should be able to just comment them out. I’ll prepare a proper fix.
The performance of GH is still better than GL. Reading the code on GH is
faster and easier to navigate than GL. This might be an artifact of my
location? The GL UI feels a lot more sluggish. Though GH is doing their
part with service downtimes recently as well.
Making a small change on GH to a
Hi there!
so this comes up periodically, and I think we need to discuss this. This is not
related to anything right now, so if you wonder if I'm writing this because of
something that just happened that I'm involved and you might have missed
something, you probably did not. It came up on the
I have a few aarch64 linker patches I'll need to open MRs for. They
are mostly 5-10
line changes, but will give us a working linker :-)
On Wed, May 6, 2020 at 2:13 AM Ben Gamari wrote:
>
> Hi everyone,
>
> The time is again upon us to start thinking about release planning for
> the next major
It can run TH using iserv; which depends on lib:ghci iirc.
On Fri, 18 Oct 2019 at 7:24 PM, Ömer Sinan Ağacan
wrote:
> Stage 1 compiler doesn't have interpreter, and doesn't run plugins or TH,
> so I
> think GHCi stuff should not be used by stage 1 compiler, but for some
> reason the
> "ghci"
Hi Michael,
any reason you want to build specifically 8.4.3? And any specific
reason you want to use 8.0.2 to build it? Anyway, you likely don't
want to build unregistered, but use the llvm backend.
You want to set the BuildFlavour to quick-cross, e.g. with
sed -E "s/^#BuildFlavour[ ]+=
nt
frequency
you'll likely find quite a lot of further discussion about not making configure
and
boot the default.
>
> On Fri, Mar 15, 2019 at 3:10 AM Moritz Angermann
> wrote:
> It's magically conflating two different phases with `-c`. The configure phase
> and
> the bu
> On Mar 15, 2019, at 2:19 AM, Herbert Valerio Riedel
> wrote:
> On Thu, Mar 14, 2019 at 4:20 PM Spiwack, Arnaud
> wrote:
> • The -c option should be the default.
> Very strong -1 from me on this one; I've been quite vocal on the Hadrian
> issue tracker early on and multiple times
Hi Ryan, hi Richard,
> My (limited) understanding is that template-haskell is not reinstallable for
> the same reasons that base and ghc-prim aren't reinstallable: the GHC
> codebase directly wires in several definitions several functions, types, and
> data constructors from template-haskell.
Dear friends,
as I'm working on making lib:ghc re-installable [1][2].
Ideally I'd prefer we only had to freeze rts + ghc-prim
and maybe base (which would implicate the integer library).
However, we apparently can't re-install Template Haskell
I'm told. Not just not upgrade it, but not even
Dear friends,
the other day I've run into an issue where I could not build a package. It
turned out that
the underlying reason was that the packages ghc ships with are not necessarily
the same
as they are on hackage. Ryan was kind enough to open Ticket 16199[1].
My use case is that I reduce
I wonder if gitlab could have a feature like what bors offers. Validate and
merge or [rebase and validate and merge]+. Thus eventually merging it or
rejecting it due to conflict or validation failure.
Sent from my iPhone
> On 16 Jan 2019, at 10:55 PM, Matthew Pickering
> wrote:
>
> There is
free to push branches to ghc/ghc.
> >
> > This is sometimes not ideal as it wastes GHC's CI resources. For example I
> > make
> > a lot of WIP commits to my work branches, and I don't want to keep CI
> > machines
> > busy for those.
> >
> > Ömer
>
Can’t we have absolute submodule paths? Wouldn’t that elevate the issue?
When we all had branches on ghc/ghc this
was not an issue.
Sent from my iPhone
> On 8 Jan 2019, at 5:24 AM, Ben Gamari wrote:
>
> Simon Peyton Jones via ghc-devs writes:
>
>> Would it be worth describing this workflow
Hi *,
so what do we do with submodules? If you point someone to a fork of ghc, say:
gitlab.haskell.org/foo/ghc
and they try to check it out, they will run into issues because foo didn't
clone all the
submodules. So how is one supposed to clone a forked ghc repository?
Cheers,
Moritz
Does this need to be *this* hardcoded? Or could we just parse the pragma and
compare it to a list of known pragmas to be parsed from a file (or settings
value?).
The change in question does:
-pragmas = options_pragmas ++ ["cfiles", "contract"]
+pragmas
A long time ago, I’ve tried to inject plugin logic to allows some control over
the driver pipeline (phase ordering) and hooking various code gen related
functions.
See https://phabricator.haskell.org/D535
At that time I ran into issues that might simply not exist with plugins anymore
today,
Dear friends,
we have a set of non-reinstallable packages with GHC, these
include iirc template-haskell, and some other. I've got
a few questions concerning those:
- do we have a complete up-to-date list of those?
- why can't we reinstall them (let's assume we use the
identical version for
1 - 100 of 191 matches
Mail list logo
