2018-05-06 16:41 GMT+02:00 Andreas Klebinger :
> [...] If we only consider 16byte (DSB Buffer) and 32 Byte (Cache Lines)
> relevant this reduces the possibilities by a lot after all. [...]
>
Nitpick: Cache lines on basically all Intel/AMD processors contain 64
bytes, see e.g. http://www.agner.org
Yes: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective
I think this may be waiting for the trees-that-grow work to be completed, and
as far as I know, no one is actively working on this. But I still think it
would be a Good Thing.
Richard
> On May 7, 2018, at 12:37 AM, David
I want to be able to run the GHC parser in one of two modes, batch which
functions as now, and interactive which will (eventually) be incremental.
In addition, the hsSyn AST for each will have different TTG[1] annotations,
so that it can better support IDE usage.
I think this can be done by chang
> I think this may be waiting for the trees-that-grow work to be completed, and
> as far as I know, no one is actively working on this.
We've just got a new Google SoC project accepted to push this forward :)
/Shayan
On Mon, May 7, 2018 at 3:14 PM, Richard Eisenberg wrote:
> Yes: https://ghc.h
Currently we sometimes use special closures to mark end of lists of different
objects. Some examples:
- END_TSO_QUEUE
- END_STM_WATCH_QUEUE
- END_STM_CHUNK_LIST
But we also use NULL for the same thing, e.g. in weak pointer lists
(old_weak_ptr_list, weak_ptr_list).
I'm wondering why we need speci
Hi Ömer,
These are pointed to by objects traversed by GC. They have info tables
like any other heap object that GC can understand. I think this is a much
simpler invariant to hold then to have some heap objects point to NULL.
Ryan
On Mon, May 7, 2018 at 3:34 PM, Ömer Sinan Ağacan
wrote:
> Cu
