Nevermind, I just realised I got something mixed up. Sorry to bother you.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/question-regarding-Data-Array-Accelerate-tp5476144p5476586.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
Hello,
According to the documentation (
http://hackage.haskell.org/packages/archive/base/4.5.0.0/doc/html/Foreign-StablePtr.html),
StablePtrs aims at being opaque on C-side.
But they provide functions to be casted to/from regular *void**'s.
Does that mean if for instance you have a StablePtr CInt
On Sun, Feb 12, 2012 at 8:18 AM, Yves Parès yves.pa...@gmail.com wrote:
Hello,
According to the documentation
(http://hackage.haskell.org/packages/archive/base/4.5.0.0/doc/html/Foreign-StablePtr.html),
StablePtrs aims at being opaque on C-side.
But they provide functions to be casted to/from
I added that after reading his feedback, and seeing the flaw in using
TMChans.
On Sun, Feb 12, 2012 at 1:47 AM, wren ng thornton w...@freegeek.org wrote:
On 2/9/12 2:29 PM, Felipe Almeida Lessa wrote:
Your package uses TMChans which AFAIK are unbounded. That means that
if the writer is
On 12-02-12 09:18 AM, Yves Parès wrote:
According to the documentation
(http://hackage.haskell.org/packages/archive/base/4.5.0.0/doc/html/Foreign-StablePtr.html),
StablePtrs aims at being opaque on C-side.
The doc multiply warns again and again that StablePtr, as well as
whatever Ptr you get
Yes, but from C side, a StablePtr* is **already a **void**. (See HsFFI.h
which typedefs HsStablePtr to void*)
So its sufficient for a use as an opaque pointer, no need to cast it.
So what is the use of casting it to a Ptr () if this doesn't allow to
access the memory space addressed?
2012/2/12
Thanks for your explanation Albert, it makes things clearer.
So StablePtrs are just useful so that C code can:
1) call back into Haskell (through a foreign exported function like
doSomethingWithTheObjectIGaveYou
:: StablePtr MyObjectType - Stuff - IO ())
2) store them to return them later to
On Sun, Feb 12, 2012 at 3:09 PM, Yves Parès yves.pa...@gmail.com wrote:
But then,
In use case 1), how can a Haskell function modify the data addressed?
http://hackage.haskell.org/packages/archive/base/latest/doc/html/Foreign-StablePtr.html#v:deRefStablePtr
Antoine
OK, we could implement lenses, make `tempo' a lens instead of a selector,
desugar the update syntax to call the update 'method' out of the lens, ...
And of course somehow arrange the sugar that when `tempo' appears in other
contexts we take the select 'method'.
implement lenses - Done, of
Quoth Yves Pares,
...
If StablePtrs cannot have their pointed value modified (either C or
Haskell-side), that mostly limits their interest, doesn't it?
I'm not sure I follow what's happening in the two cases you mention,
but in case it helps, I use StablePtr as a way to smuggle Haskell
values
No, you can do nothing with the pointer on the C side other than pass
it back into haskell. It may not even be a pointer, it may be an index
into an array deep within the RTS for instance. The reason they can be
cast to void *'s is so you can store them in C data structures that
don't know about
Hello,
I have just released ghc-mod v1.10.3. C-cC-t of this version was
powered by Hideyuki Tanaka.
The old implementation just show the type of the current expression on
Emacs. Howver, the new implementation first show the type of the
current expression and the expression is highlighted. If
You mean I have to use a type like StablePtr (IORef Stuff)?
Because there I can only peek (deRefStablePtr) the pointer, not poke it.
I take it I should return to C a StablePtr to the new value if I don't want
to use IORefs...
Or else I have to use regular Ptrs with Foreign.Marshall.Alloc.malloc
13 matches
Mail list logo
