Well, fewer dependencies make it much easier to test and reproduce. But
something concrete is certainly better than nothing. Please submit a Trac
ticket. (Worth checking with Roman -- perhaps he already has?)
Simon
| -Original Message-
| From: Dan Doel [mailto:dan.d...@gmail.com]
| S
On Mon, Jul 12, 2010 at 9:12 AM, Simon Peyton-Jones
wrote:
> Well, fewer dependencies make it much easier to test and reproduce. But
> something concrete is certainly better than nothing. Please submit a Trac
> ticket. (Worth checking with Roman -- perhaps he already has?)
>
I can probably coo
On Mon, Jul 12, 2010 at 10:40 AM, Bryan O'Sullivan wrote:
>
> I can probably cook up a smaller repro than Dan, since I depend on neither
> package for a standalone test case. Let me get cracking on it promptly, and
> I'll file a ticket later.
>
I filed http://hackage.haskell.org/trac/ghc/ticket/4
Thank you! I am utterly buried just now (POPL) but will get to this.
Simon
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Bryan O'Sullivan
Sent: 12 July 2010 13:58
To: Simon Peyton-Jones
Cc: glasgow-haskell-users@haskell.org
Subje
On Thu, Jul 08, 2010 at 09:30:23PM -0500, Louis Wasserman wrote:
> Consider
>
> newtype Foo = Foo Int
>
> lift :: (Int -> a) -> Foo -> a
> lift f (Foo x) = f x
>
> Now, I'd expect this to compile with -O2 down to something like
>
> lift f = f `cast` (Foo -> a)
>
> but it doesn't.
>
> It seems
So I was planning to pass a StorableVector to C. StorableVector uses
ForeignPtrs to manage its memory, so it should just be a pointer pass.
I happily wrote up a reference counting scheme so I could attach
decref to the finalizer and have haskell and C cooperate about when to
delete the pointer.
Excerpts from Evan Laforge's message of Mon Jul 12 14:56:11 -0400 2010:
> But I'm not convinced that's actually enough because the C code is
> still running outside of a withForeignPtr. I would have to do
> something really hairy like call back to C from the haskell callback,
> wrapping it in with
On Mon, Jul 12, 2010 at 12:54 PM, Edward Z. Yang wrote:
> Excerpts from Evan Laforge's message of Mon Jul 12 14:56:11 -0400 2010:
>> But I'm not convinced that's actually enough because the C code is
>> still running outside of a withForeignPtr. I would have to do
>> something really hairy like c
Excerpts from Evan Laforge's message of Mon Jul 12 16:23:39 -0400 2010:
> Well, what I'm worried about is that withForeignPtr says you should
> only use the pointer from inside it. The situation here is that I've
> passed a pointer to C. C wants to share ownership of the pointer, so
> even if all
> The easiest thing to do is copy the contents to a regular area of memory not
> managed by a Storable Vector. This'll be much less painful because it's just
> a
> normal free (not a recursive one, which can get hairy).
Yeah, that's definitely the safest and simplest. But the copying
defeats th
Excerpts from Evan Laforge's message of Mon Jul 12 16:43:45 -0400 2010:
> Yeah, that's definitely the safest and simplest. But the copying
> defeats the purpose of passing a pointer in the first place, which was
> to not have to copy the giant array just to pass it.
Well, if your C code wasn't sq
On Mon, Jul 12, 2010 at 5:23 PM, Evan Laforge wrote:
> Another hack I thought of:
>
> - store ptr in a global MVar in haskell, pass it to C
> - C does its thing, ptr stays alive because haskell still has a reference
> - now when C calls the finalize funptr, it deletes the ptr from the
> haskell MV
On Mon, Jul 12, 2010 at 1:53 PM, Edward Z. Yang wrote:
> Excerpts from Evan Laforge's message of Mon Jul 12 16:43:45 -0400 2010:
>> Yeah, that's definitely the safest and simplest. But the copying
>> defeats the purpose of passing a pointer in the first place, which was
>> to not have to copy the
Hi, is a StablePtr what you are after?
http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Foreign-StablePtr.html
you can pass a stableptr to the foreignptr to C and it won't be freed
until you explicitly get rid of the stableptr (and all haskell
references are gone)
John
On 11/07/2010, at 22:49, Bryan O'Sullivan wrote:
> On Sun, Jul 11, 2010 at 12:59 AM, Dan Doel wrote:
>
>> You're using GHC 6.12.x presumably?
>
> That's right.
>
>> There are known performance problems with
>> using abstract PrimMonads in that version (and, actually, just using IO as
>> well
On Mon, Jul 12, 2010 at 6:54 PM, John Meacham wrote:
> Hi, is a StablePtr what you are after?
Indeed, it looks like StablePtr will get me what I want. It's a
little less convenient than FunPtr because I'm already doing some
finalization of FunPtrs and I can reuse the same callback, but it
looks
16 matches
Mail list logo
