> On Feb 6, 2020, at 02:28, Simon Marlow wrote:
>
> The issue here is that raiseAsync is destructive - it *moves* the stack to
> the heap, rather than copying it. So if you want to continue execution where
> you left off, for shift#, you would have to copy it back onto the stack
> again. That'
On Mon, 10 Feb 2020 at 08:10, Alexis King wrote:
> On Feb 6, 2020, at 02:28, Simon Marlow wrote:
>
> The issue here is that raiseAsync is destructive - it *moves* the stack to
> the heap, rather than copying it. So if you want to continue execution
> where you left off, for shift#, you would hav
On Mon, 10 Feb 2020 at 08:17, Simon Marlow wrote:
> On Mon, 10 Feb 2020 at 08:10, Alexis King wrote:
>
>> On Feb 6, 2020, at 02:28, Simon Marlow wrote:
>>
>> The issue here is that raiseAsync is destructive - it *moves* the stack
>> to the heap, rather than copying it. So if you want to continu
Folks,
I'm glad to report that I finally get GHC 8.8.2 with cabal-install
3.0.0.0 working on SmartOS x64, you can checkout detailed steps and all
the patches applied at https://gitlab.haskell.org/complyue/smart-ghc8
The only pity so far, is that the built GHC 8.6.5 has its `ghci` not
working
Does anyone know why I get so little symbols in stage 2 compiler compared to
programs built with the same stage 2 compiler?
This is the build.mk I'm using
BuildFlavour = quick
ifneq "$(BuildFlavour)" ""
include mk/flavours/$(BuildFlavour).mk
endif
GhcRtsHcOpts += -O0 -g3
If I build with hadrian using "quickest" setting I get a more reasonable number:
$ nm ./_build/stage1/bin/ghc | wc -l
102174
It'd be good to have these symbols in make-generated stage 2 executables too.
Ömer
Ömer Sinan Ağacan , 10 Şub 2020 Pzt, 11:45
tarihinde şunu yazdı:
>
> Does anyon
In make build system I can add extra C compiler arguments to any flavor using
something like
BuildFlavour = ...
ifneq "$(BuildFlavour)" ""
include mk/flavours/$(BuildFlavour).mk
endif
GhcRtsHcOpts += -O0 -g3
How do I do the same in hadrian when defining a flavor?
Thanks,
Ö
The reproducible logs and patches are done as I reported in another
email, and now I can confirm the dtrace patch is the only one eligible
to be merged, all other patches for SmartOS builds only do backporting. FYI
https://gitlab.haskell.org/complyue/smart-ghc8/blob/master/ghc-arts/ghc-8.8.2_in
Hi all,
It's my first time working on ghc (currently implementing proposal 99
[1]), and I have two issues with the ghc tests that I can't seem to
figure out:
- Running hadrian/build.sh test -j on my machine causes 78 tests to fail
with the following error:
collect2: error: ld retur
Hi,
On Mon, Feb 10, 2020 at 03:57:27PM +0300, Ömer Sinan Ağacan wrote:
> In make build system I can add extra C compiler arguments to any flavor using
> something like
>
> BuildFlavour = ...
>
> ifneq "$(BuildFlavour)" ""
> include mk/flavours/$(BuildFlavour).mk
> endif
>
>
Hi Ben,
Thanks for reminding me about that document. Has it been officially ratified as
our procedure of record? My guess is "no". What's it waiting on? That document
has been around for quite some time now.
Thanks,
Richard
> On Feb 7, 2020, at 9:32 PM, Ben Gamari wrote:
>
> Andreas Klebinge
Thanks. I'm currently editing the existing "quickest" flavor instead of adding
my own flavor. So far the changes are
diff --git a/hadrian/src/Settings/Flavours/Quickest.hs
b/hadrian/src/Settings/Flavours/Quickest.hs
index c0fd72764f..b0f490d35a 100644
--- a/hadrian/src/Settings/Flavour
You need to modify the `libraryWays` as well I think. Other flavours
build both by default.
Matt
On Mon, Feb 10, 2020 at 5:14 PM Ömer Sinan Ağacan wrote:
>
> Thanks. I'm currently editing the existing "quickest" flavor instead of adding
> my own flavor. So far the changes are
>
> diff --git
That worked, thanks.
I just discovered that dynamicGhcPrograms is not for whether to link stage 2
executable statically or dynamically (with the RTS and Haskell libs). Is there a
way to tell Hadrian to dynamically link stage 2 executable?
Ömer
Matthew Pickering , 10 Şub 2020 Pzt,
20:20 tarihinde
Hello,
Are heap stored ADT's arguments always levity (representation) monomorphic?
*(I guess they are otherwise the info table would not be a constant value
instead it would be a function that calculates the representation depending
on some runtime value.)*
Regards,
Csaba Hruska
> On Feb 10, 2020, at 8:48 PM, Csaba Hruska wrote:
>
> Hello,
>
> Are heap stored ADT's arguments always levity (representation) monomorphic?
Yes.
> (I guess they are otherwise the info table would not be a constant value
> instead it would be a function that calculates the representation d
Great, thanks!
On Mon, Feb 10, 2020 at 10:30 PM Richard Eisenberg wrote:
>
>
> On Feb 10, 2020, at 8:48 PM, Csaba Hruska wrote:
>
> Hello,
>
> Are heap stored ADT's arguments always levity (representation) monomorphic?
>
>
> Yes.
>
>
> *(I guess they are otherwise the info table would not be a
17 matches
Mail list logo