moving it to its own submodule is just a complicated version of cutting a
branch that has the code Right before deleting it from master.
afaik, the amount of love needed is roughly "one or more full time grad
students really owning it", though i could be wrong.
On Tue, Jan 20, 2015 at 5:39 AM, Ro
I'm generally positive on the goal of figuring out better record support in
GHC.
That said, it isn't clear that Nikita's work here directly gives rise to
how the syntax of such a thing would work in GHC proper. Simon's original
proposal overloaded (.) in yet more ways that collide with the uses in
How would that be different from the ORF?
The library as it stands is worse than the ORF: translation into
(essentially) tuples hurts error messages; no good story for sum types;
no way to make fields strict/unpacked etc.
Hopefully, if this is to become a ghc extension, these problems will be
add
Hi Konrad,
I was spending a little bit of time examining this just this morning,
and during my investigation, I followed your example from Stack
Overflow, but I find myself needing a little guidance.
One question I have about your example: Are your snippets so small
that they are prohibitively im
For those who haven't seen this, Nikita Volkov proposed a new approach
to anonymous records, which can be found in the "record" package on
Hackage: http://hackage.haskell.org/package/record
It had a *lot* of attention on Reddit:
http://nikita-volkov.github.io/record/
Now, the solution is ver
On 1/20/15, Simon Marlow wrote:
> No, it checks for and skips over complete zero words, not just trailing
> zeroes.
Sure, I mean the for-loops after your if-condition, in lines 291 and 304
https://git.haskell.org/ghc.git/blob/9894f6a5b4883ea87fd5f280a2eb4a8abfbd2a6b:/rts/sm/Scav.c#l291
Cheers,
Hello Gabor,
Fyi, Alex (cc'ed) already spent some brain-cycles on that, but it's not
clear yet if it's worth optimising:
https://gist.github.com/axman6/46edae58cc4e8242bdac
Cheers,
hvr
On 2015-01-20 at 14:45:19 +0100, Gabor Greif wrote:
> Hi Simon,
>
> JFTR, you seem to be after the trailing
No, it checks for and skips over complete zero words, not just trailing
zeroes.
The bitmaps are really that sparse sometimes. Like hundreds of zero
words with a few non-zero bits at either end. The change I made
improved perf enough that this isn't a blocking issue for me any more,
and I su
Hi Simon,
JFTR, you seem to be after the trailing zeros in the code you commented.
If the bitmap is *really* that sparse then it might be profitable to
rewrite it in terms of
__builtin_ctz (when present). Some CPUs even have instructions for this.
http://hardwarebug.org/2010/01/14/beware-the-bui
I just did a clean build on top of the current master (I was building on
top of ghc-7.8) and it worked!
Thanks!
--
Luís Gabriel
On Sun Jan 18 2015 at 9:35:35 AM Sergei Trofimovich
wrote:
> On Sat, 17 Jan 2015 23:20:30 +
> Luís Gabriel wrote:
>
> > Hi there,
> >
> > I'm doing some experimen
(disclaimer: I know nothing about the vectorization code)
Now, is the vectorization code really dead code or it is code that needs
love to come back to life? By removing it from the code base, you are
probably sealing it's fate as dead code as we are limiting new or existing
contributors to act on
On 2015-01-20 at 09:37:25 +0100, Jan Stolarek wrote:
>> Here's an alternate suggestion: in SimplCore, keep the call to vectorise
>> around, but commented out
> Yuck. Carter and Brandon are right here - we have git, let it do the
> job. I propose that we remove vectorization code, create a Trac tic
> Here's an alternate suggestion: in SimplCore, keep the call to vectorise
> around, but commented out
Yuck. Carter and Brandon are right here - we have git, let it do the job. I
propose that we remove
vectorization code, create a Trac ticket about vectorization & DPH needing love
and record the
13 matches
Mail list logo
