On Tue, Feb 1, 2011 at 6:26 PM, Roman Leshchinskiy wrote:
> No, the operation is still impure. Suppose we had
>
> thawArray# :: Array# a -> Int# -> Int# -> MutableArray# s a
>
> Then, we write
>
> f xs = let ys = thawArray# xs 0 n#
> zs = thawArray# xs 0 n#
> in e
>
> Do ys and zs
Johan Tibell wrote:
> On Tue, Feb 1, 2011 at 4:24 PM, Roman Leshchinskiy
> wrote:
>
>> Johan Tibell wrote:
>>
>>>
>>> Does cloneArray# really have to take and return a `State# s`?
>>>
>>
>> Oops, no, it doesn't. This was purely a case of mindless copy-pasting.
>>
>
> Does this apply to any of the
On Tue, Feb 1, 2011 at 4:40 PM, Johan Tibell wrote:
> On Tue, Feb 1, 2011 at 4:24 PM, Roman Leshchinskiy
> wrote:
>>> Does cloneArray# really have to take and return a `State# s`?
>>
>> Oops, no, it doesn't. This was purely a case of mindless copy-pasting.
>
> Does this apply to any of the other
On Tue, Feb 1, 2011 at 4:24 PM, Roman Leshchinskiy wrote:
> Johan Tibell wrote:
>>
>> Something struck me today. Look at the type signature for cloneArray#
>>
>>
>> cloneArray# :: Array# a -> Int# -> Int# -> State# s -> (# State# s,
>> Array# a #)
>>
>>
>> Does cloneArray# really have to take an
On 31 January 2011 09:14, Simon Marlow wrote:
> On 30/01/2011 00:42, Daniel Peebles wrote:
>>
>> In a slightly related proposal on the same topic, what do people think of:
>>
>> newArrayWith# :: (Int# -> a) -> Int# -> State# s -> (# State# s,
>> MutableArray# s a #)
>>
>> that would do the obvious
Johan Tibell wrote:
>
> Something struck me today. Look at the type signature for cloneArray#
>
>
> cloneArray# :: Array# a -> Int# -> Int# -> State# s -> (# State# s,
> Array# a #)
>
>
> Does cloneArray# really have to take and return a `State# s`?
Oops, no, it doesn't. This was purely a case o
Hi,
Something struck me today. Look at the type signature for cloneArray#
cloneArray# :: Array# a -> Int# -> Int# -> State# s -> (# State#
s, Array# a #)
Does cloneArray# really have to take and return a `State# s`? It seems
perfectly fine to float this expression around. It needs to be ma
On 30/01/2011 00:42, Daniel Peebles wrote:
In a slightly related proposal on the same topic, what do people think of:
newArrayWith# :: (Int# -> a) -> Int# -> State# s -> (# State# s,
MutableArray# s a #)
that would do the obvious thing, by allocating an array of the size
specified by the Int#,
On Sun, Jan 30, 2011 at 1:42 AM, Daniel Peebles wrote:
> In a slightly related proposal on the same topic, what do people think of:
> newArrayWith# :: (Int# -> a) -> Int# -> State# s -> (# State# s,
> MutableArray# s a #)
>
> that would do the obvious thing, by allocating an array of the size
> sp
Oh, and obviously it could replace newArray#, which would just be using (\_
-> k) as the function. Is the optimization machinery clever enough to see
the constant function on a primop boundary and fold it in?
On Sat, Jan 29, 2011 at 7:42 PM, Daniel Peebles wrote:
> In a slightly related proposal
In a slightly related proposal on the same topic, what do people think of:
newArrayWith# :: (Int# -> a) -> Int# -> State# s -> (# State# s,
MutableArray# s a #)
that would do the obvious thing, by allocating an array of the size
specified by the Int#, and then pass indices into the function to ge
On 01/26/11 06:22, Simon Marlow wrote:
No - as soon as the thread enters foreign code via a safe foreign call,
GC can happen at any time.
(Which is a very good thing: if you *want* to call a long-running, or
running forever, piece of foreign code, there is a way to do it without
breaking the
Simon Marlow wrote:
>
> No - as soon as the thread enters foreign code via a safe foreign call,
> GC can happen at any time.
Ah, ok. Thanks for setting me straight!
Roman
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/li
On 26/01/2011 11:15, Roman Leshchinskiy wrote:
Simon Peyton-Jones wrote:
| AFAIK, the GC never runs during foreign calls. This, combine with the
fact that GHC can | pass ByteArray# directly to FFI calls, should make
memcpy safe even for unpinned | byte arrays. At least that's how I
unders
Simon Peyton-Jones wrote:
>
> | AFAIK, the GC never runs during foreign calls. This, combine with the
> fact that GHC can | pass ByteArray# directly to FFI calls, should make
> memcpy safe even for unpinned | byte arrays. At least that's how I
> understand it.
>
> Unless I am much mistaken, GC
On Wed, Jan 26, 2011 at 11:57 AM, Simon Peyton-Jones
wrote:
>
> | AFAIK, the GC never runs during foreign calls. This, combine with the fact
> that GHC can
> | pass ByteArray# directly to FFI calls, should make memcpy safe even for
> unpinned
> | byte arrays. At least that's how I understand
| AFAIK, the GC never runs during foreign calls. This, combine with the fact
that GHC can
| pass ByteArray# directly to FFI calls, should make memcpy safe even for
unpinned
| byte arrays. At least that's how I understand it.
Unless I am much mistaken, GC absolutely does run during *safe* for
Johan Tibell wrote:
>
> OK. So we can implement copyByteArray# by FFI importing memcpy and
> using the automatic conversion of ByteArray#s into pointers in the FFI. For
> MutableByteArray#s we need to use an unsafeCoerce# as well.
No. Both ByteArray# and MutableByteArray# can be passed to FFI call
On Tue, Jan 25, 2011 at 11:22 PM, Roman Leshchinskiy
wrote:
> On 25/01/2011, at 22:05, Daniel Peebles wrote:
>
>> Roman: I'm thinking that even in the absence of GC during foreign calls, it
>> still seems worthwhile to provide the plain copying primitives, if only to
>> save "user" code from ha
Simon Marlow wrote:
>
> I don't think Cabal supports .cmm files, so if you went that route it
> would be limited to being a GHC boot package, like integer-gmp.
I was thinking about ghc-prim.
Roman
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://
On 26/01/2011 09:52, Roman Leshchinskiy wrote:
Daniel Peebles wrote:
On Tue, Jan 25, 2011 at 5:22 PM, Roman Leshchinskiy
Hmm, come to think of it, could they perhaps be written in Cmm (calling
memcpy etc. internally) and imported using the (rather obscure) "prim"
calling convention?
http
Daniel Peebles wrote:
> On Tue, Jan 25, 2011 at 5:22 PM, Roman Leshchinskiy
>>
>> Hmm, come to think of it, could they perhaps be written in Cmm (calling
>> memcpy etc. internally) and imported using the (rather obscure) "prim"
>> calling convention?
>>
>>
>> http://www.haskell.org/ghc/docs/7.0-l
On 25/01/2011 21:30, Roman Leshchinskiy wrote:
On 25/01/2011, at 20:57, Johan Tibell wrote:
On Tue, Jan 25, 2011 at 9:47 PM, Roman
Leshchinskiy wrote:
On 25/01/2011, at 20:26, Johan Tibell wrote: AFAIK, the GC never
runs during foreign calls. This, combine with the fact that GHC
can pass Byte
On Tue, Jan 25, 2011 at 5:22 PM, Roman Leshchinskiy wrote:
> On 25/01/2011, at 22:05, Daniel Peebles wrote:
>
> > Roman: I'm thinking that even in the absence of GC during foreign calls,
> it still seems worthwhile to provide the plain copying primitives, if only
> to save "user" code from having
On 25/01/2011, at 22:05, Daniel Peebles wrote:
> Roman: I'm thinking that even in the absence of GC during foreign calls, it
> still seems worthwhile to provide the plain copying primitives, if only to
> save "user" code from having to know a) the structure of a (Byte)Array# and
> where the "da
On Tue, Jan 25, 2011 at 11:06 PM, Roman Leshchinskiy
wrote:
> Yes. See, for instance,
> http://hackage.haskell.org/packages/archive/vector/0.7.0.1/doc/html/Data-Vector.html#v:force
That's exactly the operation I had in mind. I have read your vector
code with enthusiasm. :)
Johan
_
On 25/01/2011, at 21:50, Johan Tibell wrote:
> On Tue, Jan 25, 2011 at 10:30 PM, Roman Leshchinskiy
> wrote:
>> thawArray# (which creates a mutable copy), update the element, then
>> unsafeFreeze#. I thought that's what you wanted (modulo names). In theory,
>> since both unsafeFreeze# and unsa
So, to summarize what you guys have been talking about, it's looking like
the primops would become:
copyArray#::Array# a -> Int# -> MutableArray# s a -> Int# ->
Int# -> State# s -> State# s
copyMutableArray# :: MutableArray# a -> Int# -> MutableArray# s a -> Int# ->
Int# -> State#
On Tue, Jan 25, 2011 at 10:30 PM, Roman Leshchinskiy
wrote:
> thawArray# (which creates a mutable copy), update the element, then
> unsafeFreeze#. I thought that's what you wanted (modulo names). In theory,
> since both unsafeFreeze# and unsafeThaw# do some work we might want 4
> different var
On 25/01/2011, at 20:57, Johan Tibell wrote:
> On Tue, Jan 25, 2011 at 9:47 PM, Roman Leshchinskiy
> wrote:
>> On 25/01/2011, at 20:26, Johan Tibell wrote:
>> AFAIK, the GC never runs during foreign calls. This, combine with the fact
>> that GHC can pass ByteArray# directly to FFI calls, should
On Tue, Jan 25, 2011 at 9:47 PM, Roman Leshchinskiy
wrote:
> On 25/01/2011, at 20:26, Johan Tibell wrote:
> AFAIK, the GC never runs during foreign calls. This, combine with the fact
> that GHC can pass ByteArray# directly to FFI calls, should make memcpy safe
> even for unpinned byte arrays. A
On 25/01/2011, at 20:26, Johan Tibell wrote:
> On Tue, Jan 25, 2011 at 6:35 PM, Roman Leshchinskiy
> wrote:
>> Daniel Peebles wrote:
>>>
>>> Johan Tibell and I have been working on some new primops for GHC that
>>> would allow people to use fast optimized memcpys on unpinned memory.
>>
>> Why
Hi Roman,
On Tue, Jan 25, 2011 at 6:35 PM, Roman Leshchinskiy
wrote:
> Daniel Peebles wrote:
>>
>> Johan Tibell and I have been working on some new primops for GHC that
>> would allow people to use fast optimized memcpys on unpinned memory.
>
> Why not just use memcpy?
I'm working with unpinned
Daniel Peebles wrote:
>
> Johan Tibell and I have been working on some new primops for GHC that
> would allow people to use fast optimized memcpys on unpinned memory.
Why not just use memcpy?
> The use
> cases I can think of would be in the vector package (possibly the New
> stuff in there, but a
34 matches
Mail list logo
