Hello,
My point was that in many cases we can simply avoid run-time code
generation, rather then trying to work around the system's SE Linux
policy. While I believe that using the foreign "export" gives us the
same functional behavior, the generated code is certainly not the
same. I wrote a smal
On March 16, 2010 20:01:32 Iavor Diatchki wrote:
> Optionally disabling executable heap blocks would be a separate patch.
> As far as I know, the only reason that the heap is executable is to
> support the adjustor thunks used to implement "wrapper" imports. The
> "static_wrapper" patch provides
On 17/03/2010, at 03:16, Louis Wasserman wrote:
> I'm not willing to do this sort of typeclass wrapper thing, primarily because
> nothing else in containers does -- even though we might have a Mapping type
> class that handles both IntMap and Map, we don't.
>
> I'm inclined to let that design c
On 17/03/2010 00:17, Louis Wasserman wrote:
I tested, and this implementation actually performs better if the spine
is maintained lazily, so we'll test that version.
May I request that, unless there's a significant speedup from using a
strict spine, that you use a lazy spine where possible.
On 16/03/10 23:38, Iavor Diatchki wrote:
Hello,
On Tue, Mar 16, 2010 at 3:22 PM, Simon Marlow wrote:
It seems hard to justify adding this to GHC, since it's really just
syntactic convenience for a particular case. Traditionally syntactic sugar
for FFI declarations has been implemented in the
