Re: [Haskell-cafe] question regarding Data.Array.Accelerate

2012-02-12 Thread Philipp
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.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Stable pointers: use of cast to/from Ptr

2012-02-12 Thread Yves Parès
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 you can cast it to Ptr
() and alter it on C-side?

void alter(void* data)
{
int* x = (int*)data;
*x = 42;
}

--

-- using 'unsafe' doesn't change anything.
foreign import ccall safe alter
alter :: Ptr () - IO ()

main = do
sptr - newStablePtr (0 :: CInt)
deRefStablePtr sptr = print
alter (castStablePtrToPtr sptr)  -- SEGFAULTS!
deRefStablePtr sptr = print
freeStablePtr sptr


But I tried it, and it doesn't work: I got a segfault when 'alter' is
called.

Is it normal? Does this mean I can only use my pointer as opaque? (Which I
know to be working, as I already got a C function call back into Haskell
and pass it the StablePtr via a 'foreign export')
But in that case, what is the use of castStablePtrToPtr/castPtrToStablePtr,
as you can already pass StablePtrs to and from C code?

Thanks!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Stable pointers: use of cast to/from Ptr

2012-02-12 Thread Antoine Latter
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 regular void*'s.
 Does that mean if for instance you have a StablePtr CInt you can cast it to
 Ptr () and alter it on C-side?

 void alter(void* data)
 {
     int* x = (int*)data;
     *x = 42;
 }

 --

 -- using 'unsafe' doesn't change anything.
 foreign import ccall safe alter
     alter :: Ptr () - IO ()

 main = do
     sptr - newStablePtr (0 :: CInt)
     deRefStablePtr sptr = print
     alter (castStablePtrToPtr sptr)  -- SEGFAULTS!
     deRefStablePtr sptr = print
     freeStablePtr sptr


 But I tried it, and it doesn't work: I got a segfault when 'alter' is
 called.


I think that 'castStablePtrToPtr' exists because many C APIs use
'void*' to mean 'opaque lump of data', and these exist to conform to
that sort of API.

Antoine

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] ANN: stm-conduit-0.2.1

2012-02-12 Thread Clark Gaebel
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 faster than the reader, then everything will be kept
 into memory.  This means that using TMChans you may no longer say that
 your program uses a constant amount of memory.  Actually, you lose a
 lot of your space reasoning since, being concurrent processes, you
 can't guarantee almost anything wrt. progress of the reader.


 Of course, you're free to use TBMChans instead, which are bounded :)

 --
 Live well,
 ~wren

 __**_
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Stable pointers: use of cast to/from Ptr

2012-02-12 Thread Albert Y. C. Lai

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 from castStablePtrToPtr, are opague (meaningless) 
to the C side. This is sanctioned by Haskell 2010, and GHC certainly 
exploits it to the fullest. The following example shows what kind of 
pointer values the C side receives for real (I deliberately do not 
free anything to show you more possible values):


#include stdio.h
void expose(void *p, void *q)
{
  printf(%p %p\n, p, q);
}

import Foreign.StablePtr
import Foreign.Ptr
main = do
  printout (0 :: Int)
  printout (let x = not x in x)
  printout ([] :: [Integer])
printout :: a - IO ()
printout thunk = do
  p - newStablePtr thunk
  expose p (castStablePtrToPtr p)
  -- I deliberately do not free
foreign import ccall expose :: StablePtr a - Ptr b - IO ()

Typically the output is like
0xf 0xf
0x10 0x10
0x11 0x11
Looks more like keys of a lookup table than pointers.

I do not know what good is castStablePtrToPtr for, given that StablePtr 
is already translated to C side void*, so that no intermediate Ptr step 
is necessary. Perhaps there is a story from a historical perspective.



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Stable pointers: use of cast to/from Ptr

2012-02-12 Thread Yves Parès
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 Antoine Latter aslat...@gmail.com

 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 regular void*'s.
  Does that mean if for instance you have a StablePtr CInt you can cast it
 to
  Ptr () and alter it on C-side?
 
  void alter(void* data)
  {
  int* x = (int*)data;
  *x = 42;
  }
 
  --
 
  -- using 'unsafe' doesn't change anything.
  foreign import ccall safe alter
  alter :: Ptr () - IO ()
 
  main = do
  sptr - newStablePtr (0 :: CInt)
  deRefStablePtr sptr = print
  alter (castStablePtrToPtr sptr)  -- SEGFAULTS!
  deRefStablePtr sptr = print
  freeStablePtr sptr
 
 
  But I tried it, and it doesn't work: I got a segfault when 'alter' is
  called.
 

 I think that 'castStablePtrToPtr' exists because many C APIs use
 'void*' to mean 'opaque lump of data', and these exist to conform to
 that sort of API.

 Antoine

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Stable pointers: use of cast to/from Ptr

2012-02-12 Thread Yves Parès
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 Haskell when prompted (through a
foreign imported function like getObject :: Stuff - IO (StablePtr
MyObjectType))
That's it?

But then,
In use case 1), how can a Haskell function modify the data addressed?

If StablePtrs cannot have their pointed value modified (either C or
Haskell-side), that mostly limits their interest, doesn't it?


2012/2/12 Albert Y. C. Lai tre...@vex.net

 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.**htmlhttp://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 from castStablePtrToPtr, are opague (meaningless) to the C
 side. This is sanctioned by Haskell 2010, and GHC certainly exploits it to
 the fullest. The following example shows what kind of pointer values the
 C side receives for real (I deliberately do not free anything to show you
 more possible values):

 #include stdio.h
 void expose(void *p, void *q)
 {
  printf(%p %p\n, p, q);
 }

 import Foreign.StablePtr
 import Foreign.Ptr
 main = do
  printout (0 :: Int)
  printout (let x = not x in x)
  printout ([] :: [Integer])
 printout :: a - IO ()
 printout thunk = do
  p - newStablePtr thunk
  expose p (castStablePtrToPtr p)
  -- I deliberately do not free
 foreign import ccall expose :: StablePtr a - Ptr b - IO ()

 Typically the output is like
 0xf 0xf
 0x10 0x10
 0x11 0x11
 Looks more like keys of a lookup table than pointers.

 I do not know what good is castStablePtrToPtr for, given that StablePtr is
 already translated to C side void*, so that no intermediate Ptr step is
 necessary. Perhaps there is a story from a historical perspective.


 __**_
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Stable pointers: use of cast to/from Ptr

2012-02-12 Thread Antoine Latter
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

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution -record update

2012-02-12 Thread Evan Laforge
 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 course.

make 'tempo' a lens instead of a selector - Done, but with TH.

desugar the update syntax - Not necessary, and normal function syntax
is more flexible than special update syntax.

arrange for 'tempo' in other contexts to be the select method - If I'm
understanding correctly, then this is also not necessary.  If we are
using normal function syntax then there are no other contexts.

 You write up the proposal, and think through all the changes it would involve
 over Haskell/GHC as is, and then we can compare it to all those other
 proposals.

So no proposal is necessary, because it's already implemented.  However:

 Now in return for me answering that, please answer the questions in my earlier
 post about what limitations on update you'd like:
 * record-type changing?
 * Higher-ranked fields?
 * How many forall'd variables?
 * Constrained forall'd variables?

If record update is a normal function then all of these questions are
moot.  However, if it uses lenses then, focusing on type changing
first, you raise a good point.  All the lens libraries I know of have
a 'set' function like 'Lens a b - b - a - a', and so can't change
the type of the record the way record update syntax can.  That's a
serious weakness, and you're right that a real proposal shouldn't go
forward without a solution for it.

I don't understand enough about the issue yet to know from where
exactly this weakness arises, and what would be needed to solve it in
the context of lenses, e.g. in a data structure that can be passed to
a normal function rather than as special syntax.  If I understood it
better then perhaps I could suggest something to address exactly that
weakness in an orthogonal way.  I'll have to think about it more.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Stable pointers: use of cast to/from Ptr

2012-02-12 Thread Donn Cave
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 through a non-Haskell layer.  On the other side, they are
just things - not really pointers, so while void* is all right as
long as it's the right size, it is a little misleading.  Tag might
be a better word.

castStablePtrToPtr doesn't change that - you still get a tag, not
a memory address.  I can think of no use for it, unless you want
to call a function that happens to use a Ptr () without expecting
it to point somewhere in the memory address sense.

Since they're Haskell values, it would be perverse to modify them.
I just want them back, in a Haskell function dispatched by the
other layer.  If I want to pass data per se to the other side,
I have to marshal it to be readable CInts and such, and then pass
it as a Ptr.  And/or if the data is to be modified by the other
side, same deal, I have to un-marshal it back into Haskell.

I actually use them with a C++ layer, where of course the dispatch
happens through C++ object member functions.  That allows me to
map Haskell functions to the C++ API in a C++ derived class that
just maintains a table of the actual Haskell `member functions',
and a StablePtr for the actual Haskell data.

Donn

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Stable pointers: use of cast to/from Ptr

2012-02-12 Thread John Meacham
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 haskell, which tend to take void *s.

John

On Sun, Feb 12, 2012 at 6: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 regular void*'s.
 Does that mean if for instance you have a StablePtr CInt you can cast it to
 Ptr () and alter it on C-side?

 void alter(void* data)
 {
     int* x = (int*)data;
     *x = 42;
 }

 --

 -- using 'unsafe' doesn't change anything.
 foreign import ccall safe alter
     alter :: Ptr () - IO ()

 main = do
     sptr - newStablePtr (0 :: CInt)
     deRefStablePtr sptr = print
     alter (castStablePtrToPtr sptr)  -- SEGFAULTS!
     deRefStablePtr sptr = print
     freeStablePtr sptr


 But I tried it, and it doesn't work: I got a segfault when 'alter' is
 called.

 Is it normal? Does this mean I can only use my pointer as opaque? (Which I
 know to be working, as I already got a C function call back into Haskell and
 pass it the StablePtr via a 'foreign export')
 But in that case, what is the use of castStablePtrToPtr/castPtrToStablePtr,
 as you can already pass StablePtrs to and from C code?

 Thanks!

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] ghc-mod v1.10.3

2012-02-12 Thread 山本和彦
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 type
C-cC-t again, the region is enlarged to its upper expression, and its
type is displayed.

# I don't know well but this is called annot in the OCaml community

Enjoy!

--Kazu

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Stable pointers: use of cast to/from Ptr

2012-02-12 Thread Yves Parès
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

2012/2/12 Antoine Latter aslat...@gmail.com

 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

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe