I tend to use google with the extra keyword site:
gitlab.haskell.org/ghc/ghc/-/issues, as it often has better search results
than gitlab itself. It doesn't work too well for very recent tickets though
(e.g. haskeline one as you mentioned), but otherwise it works for me.
Cheers,
Cheng
On Tue, Jan
The fix just landed on d198a19ae08fec797121e3907ca93c5840db0c53 on master.
On Thu, Nov 24, 2022 at 8:11 PM Matthew Farkas-Dyck via ghc-devs <
ghc-devs@haskell.org> wrote:
> Ah, it seems i was in error earlier... i can reproduce this now. ☹
>
> +1 for CI job testing static build
>
> ---
Sorry, my oversight. I'll open an MR to fix the static configuration :/
On Thu, Nov 24, 2022 at 10:36 AM Sylvain Henry wrote:
> With devel2 only the static libs are built. Hence the RTS linker is used.
>
>
>
:
>
> Matthew pointed out that the build system already parallelizes jobs, so it's
> risky to force parallelization of any individual job. That means I should
> just revert.
>
> On Wed, Sep 28, 2022 at 2:38 PM Cheng Shao wrote:
>>
>> I believe we can either modify ci.sh t
htly-i386-linux-deb9-validate (the failing job) sets "XZ_OPT = 9".
>
> A revert would fix the problem, but presumably so would tweaking that option.
> Does anyone have information that would lead to a better decision here?
>
>
> On Wed, Sep 28, 2022 at 2:02 PM Cheng Shao
I sampled, but not all builds through all time.) Thanks for
> pointing it out!
>
> I can revert the change.
>
> On Wed, Sep 28, 2022 at 11:46 AM Cheng Shao wrote:
>>
>> Hi Bryan,
>>
>> This may be an unintended fallout of !8940. Would you try starting an
>&
Hi Bryan,
This may be an unintended fallout of !8940. Would you try starting an
i386 pipeline with it reversed to see if it solves the issue, in which
case we should revert or fix it in master?
On Wed, Sep 28, 2022 at 9:58 AM Bryan Richter via ghc-devs
wrote:
>
> Hi all,
>
> For the past week
Hi Travis,
- Do we have a type like #Addr whose loads/stores have volatile semantics?
Nope
- Do we have any primops with volatile semantics at all?
We have atomicReadIntArray#, atomicWriteIntArray# prim ops, the
read/write on MutableByteArray# will introduce proper memory barriers.
However
Simon,
I believe you can use `--docs=none`, at least it'll prevent running haddock.
On Thu, Jul 28, 2022 at 3:46 PM Simon Peyton Jones
wrote:
>
> Doing hadrian/build test
> takes absolutely ages. It seems that it is building haddock, running
> haddock, building check_exact, and other things.
d ensure that everything works with
> ghc-bignum's native backend before worrying about using gmp.
>
> Cheers,
> Sylvain
>
>
> On 20/05/2022 13:43, Cheng Shao wrote:
> > Hi all,
> >
> > The ghc wasm32-wasi build needs to patch gmp. Currently, our working
> >
Hi all,
The ghc wasm32-wasi build needs to patch gmp. Currently, our working
branch uses a fork of gmp-tarballs that includes the patch into the
tarball, but at some point we need to upstream it. What's the best way
to add these fixes?
- Send a PR to gmp-tarballs, including our patch (doesn't
Hi all,
We're planning to add WebAssembly support to GHC. This work will be
delivered by me and Norman Ramsey, the former Asterius team at Tweag.
In the past few months, we did a strategic shift and focused on
growing GHC towards Asterius, leveraging existing RTS as much as
possible. We've made
t exit.
> Then you can use hs_try_put_mvar in C thread to call the thread back.
>
> On Wed, 15 Dec 2021 at 05:07, Cheng Shao wrote:
> >
> > Hi devs,
> >
> > To invoke Haskell computation in C, we need to call one of rts_eval*
> > functions, which enters
> While the idea here sounds reasonable, I'm not sure I quite understand
> how this will be used in Asterius's case. Specifically, I would be
> worried about the lack of fairness in this scheme: no progress will be
> made on any foreign call until all Haskell evaluation has blocked.
> Is this
Hi devs,
To invoke Haskell computation in C, we need to call one of rts_eval*
functions, which enters the scheduler loop, and returns only when the
specified Haskell thread is finished or killed. We'd like to enhance
the scheduler and add async variants of the rts_eval* functions, which
take C
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 also super useful for
prototyping whole-program ghc backends, where one can just read all
the CgGuts from the .hi files, and get all codegen-related Core for
free.
Indeed STG to Cmm lowering drops the correct size information for
ccall arguments, there's even a TODO comment that has been around for
quite a few years:
https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/StgToCmm/Foreign.hs#L83
This has been an annoyance for Asterius as well. When we
oritz
>
> 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 compilation) for x86_64 for a while now; and did not (yet?)
>> run into that SQLite issue. But did h
e. There is a -dynamic flag in
> HEAD, which disables GHC even trying to load dynamic libraries and always
> assuming there is no dynamic linking facility, even if configure reports the
> existence of dlopen...
>
> On Tue, 29 Sep 2020 at 6:54 PM, Cheng Shao wrote:
>>
&g
Hi Ben,
> We will likely transition the Alpine binary distribution to be fully
statically-linked, providing a convenient, distribution-independent
packaging option for Linux users.
iirc for statically linked executables, musl doesn't even support
dlopen, so wouldn't this mean such a
ace -> Core" roundtrip I tried to perform using
the output of CorePrep. By the time we do CorePrep, the hi files
should already have been written.
On Wed, Sep 16, 2020 at 11:48 PM Ben Gamari wrote:
>
> Cheng Shao writes:
>
> > Hi all,
> >
> > Following a short
correct hi path, not the
doubled path.
On Wed, Sep 16, 2020 at 9:03 PM Brandon Allbery wrote:
>
> Without looking at the implementation, it looks to me like the filename is
> doubled for some reason. This may suggest places to look.
>
> On Wed, Sep 16, 2020 at 2:57 PM Cheng
Hi all,
Following a short chat in #ghc last week, I did a first attempt of
reusing existing Iface logic to implement serialization for
codegen-related Core. The implementation is included in the attached
patch (~100 loc). As a quick and dirty validation of whether it works,
I also modified the
Hi Ömer,
See e.g. `lowerSafeForeignCall` and `blockCode`
> which set the field with `Just`. The former seems to be related with
> foreign
> calls so perhaps try compiling a FFI package.
I tried compiling a module with a `foreign import ccall safe` declaration,
yet the output raw Cmm still
24 matches
Mail list logo
