John Wiegley writes:
>> "BG" == Ben Gamari writes:
>
> BG> Note that under this scheme it will still be possible to link against the
> BG> system's libffi installation using ./configure's --enable-system-libffi
> BG> flag.
>
> Will distributions of GHC be using a system libffi which still ha
> "BG" == Ben Gamari writes:
BG> Note that under this scheme it will still be possible to link against the
BG> system's libffi installation using ./configure's --enable-system-libffi
BG> flag.
Will distributions of GHC be using a system libffi which still has the bugs
you mentioned?
--
Joh
Hello everyone,
As you may know, GHC carries a dependency on the libffi library. Libffi
is used on most platforms (notably not x86 and x86-64) for foreign
function invocation (see rts/Adjustor.c for details).
While libffi works well, it is unfortunately not particularly actively
maintained. In f
> I, too, have wished for the ability to have a separator in large number
> literals.
>
> So a strong +1 from me.
more +1 here
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Hey Ben,
Looks good to me for the most part! I think that you should include a link to
the Newcomers page [1] as a whole, even though it has some overlap with the
quick start guide and you’ve included a link to the ‘Finding a Ticket’
subsection therein.
I also think that a few more pointers o
Hello everyone,
Today I sat down and wrote a CONTRIBUTORS.md document for the ghc
repository. This is recommended by GitHub to ensure that contributors
can easily discover the first steps to contributing to the project.
Moreover, it provided a nice blank slate to summarize the existing
contributor
On Sun, Aug 27, 2017 at 7:49 PM Michal Terepeta
wrote:
> > On Thu, Aug 3, 2017 at 2:28 AM Sylvain Henry wrote:
> > Hi,
> >
> > I also think we should do this but it has a lot of ramifications:
> contant folding in Core, codegen, TH, etc.
> >
> > Also it will break codes that use primitive types
Bardur Arantsson writes:
> I may be missing something since I have only quickly skimmed the thread,
> but...: Why not track all of these things and correlate them with
> individual runs? The Linux 'perf' tool can retrieve a *lot* of
> interesting numbers, esp. around cache hit rates, branch predi
Dear all,
Thank you very much for the response and kind explanation.
After studying, I will submit to ghc-proposals :)
Regards,
Takenobu
2017-09-26 22:56 GMT+09:00 Merijn Verstraaten :
> I, too, have wished for the ability to have a separator in large number
> literals.
>
> So a strong +1 fro
I, too, have wished for the ability to have a separator in large number
literals.
So a strong +1 from me.
Cheers,
Merijn
> On 26 Sep 2017, at 15:43, Ben Gamari wrote:
>
> Takenobu Tani writes:
>
>> Hi Rahul,
>>
>> Thanks for the explanation.
>> Hmm, Is not there much need...
>>
>> Thank y
Takenobu Tani writes:
> Hi Rahul,
>
> Thanks for the explanation.
> Hmm, Is not there much need...
>
> Thank you code example.
> I will also look at lexer for my study [1].
>
If you do want to try pursuing a language change do feel free to submit
a proposal [1]. I would also like the ability to b
I'd find that quite useful for hex and binary.
It's useful for distinguishing e.g. 0x and 0xfff which when
confused accidentally and lead to big bugs.
Rust has exactly this feature for all numeric literals:
https://rustbyexample.com/primitives/literals.html
On 26/09/17 14:40, Take
Hi,
I for one, would like to have this in more than just BinaryLiterals (which I
find rather useful as well!)
I’d like to see `_` in any numeric literal being simply ignored, as I find it
makes writing and reading
numbers in source code much easier.
let i = 1_000_000 :: Int
f = 1_123.45
Hi Rahul,
Thanks for the explanation.
Hmm, Is not there much need...
Thank you code example.
I will also look at lexer for my study [1].
[1]: https://phabricator.haskell.org/D22
Thank you :) ,
Takenobu
2017-09-26 21:58 GMT+09:00 Rahul Muttineni :
> Implementation-wise, it's no so difficult t
Implementation-wise, it's no so difficult to include - the lexer needs to
be tweaked. But it seems like a specialised use-case that will only affect
a minority of users is probably not worthwhile as an extension to the
language/compiler.
Maybe you can try using OverloadedStrings and implement this
Dear devs,
GHC's BinaryLiterals extension is useful.
(For example, x = 0b110111000101)
Is it difficult to include underscore(_) in the format like Verilog-HDL[1] ?
(For example, x = 0b1101_1100_0101)
[1]:
https://inst.eecs.berkeley.edu/~cs150/fa06/Labs/verilog-ieee.pdf#page=20
Regards,
Takenobu
16 matches
Mail list logo