Re: [Haskell-cafe] GHC.Ptr, Foreign.Storable, Data.Storable.Endian, looking for good examples of usage

From: Aaron Gray
On 9 January 2011 21:30, Henning Thielemann wrote: On Sun, 9 Jan 2011, Aaron Gray wrote:
I am trying to work out how to use GHC.Ptr, Foreign.Storable,
Data.Storable.Endian, and am looking for good examples of usage.
What do you intend to do with them?
An (ABC) ActionScript Byte Code backend for Haskell.
Basically I need to write little-endian binary to a file, and was wondering the best way to do this; I need various types including a 24bit type.
You could use my "word24" package[1] (GHC only) to provide non-aligned 24-bit word and int types with Storable instances. You should be able to write a binary instance (or whatever blaze-builder needs) fairly simply from this. Little-endian only ATM, but BE could be added if necessary. John Lato [1] http://hackage.haskell.org/package/word24

On 10 January 2011 13:49, John Lato
From: Aaron Gray
On 9 January 2011 21:30, Henning Thielemann
wrote: On Sun, 9 Jan 2011, Aaron Gray wrote:
I am trying to work out how to use GHC.Ptr, Foreign.Storable,
Data.Storable.Endian, and am looking for good examples of usage.
What do you intend to do with them?
An (ABC) ActionScript Byte Code backend for Haskell.
Basically I need to write little-endian binary to a file, and was wondering the best way to do this; I need various types including a 24bit type.
You could use my "word24" package[1] (GHC only) to provide non-aligned 24-bit word and int types with Storable instances. You should be able to write a binary instance (or whatever blaze-builder needs) fairly simply from this. Little-endian only ATM, but BE could be added if necessary.
John Lato [1] http://hackage.haskell.org/package/word24
This is interesting, what does the following line do :- data Int24 = I24# Int# deriving (Eq, Ord) regarding the I24# and Int#, are these inbuilt ? Thanks, Aaron

On Monday 10 January 2011 16:45:36, Aaron Gray wrote:
This is interesting, what does the following line do :-
data Int24 = I24# Int# deriving (Eq, Ord)
regarding the I24# and Int#, are these inbuilt ?
Int# is the raw machine int (4 or 8 bytes) and I24# is the constructor. GHC uses the magic hash '#' to denote raw unboxed types (and the constructors making ordinary boxed Haskell types from these, e.g. there's data Int = I# Int# data Word = W# Word# data Double = D# Double# and more defined in base [GHC.Types, GHC.Word]).
Thanks,
Aaron

On 10 January 2011 16:13, Daniel Fischer
On Monday 10 January 2011 16:45:36, Aaron Gray wrote:
This is interesting, what does the following line do :-
data Int24 = I24# Int# deriving (Eq, Ord)
regarding the I24# and Int#, are these inbuilt ?
Int# is the raw machine int (4 or 8 bytes) and I24# is the constructor. GHC uses the magic hash '#' to denote raw unboxed types (and the constructors making ordinary boxed Haskell types from these, e.g. there's
data Int = I# Int# data Word = W# Word# data Double = D# Double#
and more defined in base [GHC.Types, GHC.Word]).
So the 24 bit value is actually stored as a 32bit value. Meaning I will have to do my own IO reader and writer code to a ByteString. Thanks, Aaron

On Mon, Jan 10, 2011 at 10:17 AM, Aaron Gray
On 10 January 2011 16:13, Daniel Fischer
wrote: On Monday 10 January 2011 16:45:36, Aaron Gray wrote:
This is interesting, what does the following line do :-
data Int24 = I24# Int# deriving (Eq, Ord)
regarding the I24# and Int#, are these inbuilt ?
Int# is the raw machine int (4 or 8 bytes) and I24# is the constructor. GHC uses the magic hash '#' to denote raw unboxed types (and the constructors making ordinary boxed Haskell types from these, e.g. there's
data Int = I# Int# data Word = W# Word# data Double = D# Double#
and more defined in base [GHC.Types, GHC.Word]).
So the 24 bit value is actually stored as a 32bit value. Meaning I will have to do my own IO reader and writer code to a ByteString. Thanks, Aaron
I don't think so - the Storable instance provided for the Int24 type peeks and pokes 24-bit values. At least, that what I understand John's earlier message to mean.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 10 January 2011 16:36, Antoine Latter
On Mon, Jan 10, 2011 at 10:17 AM, Aaron Gray
wrote: On 10 January 2011 16:13, Daniel Fischer < daniel.is.fischer@googlemail.com> wrote:
On Monday 10 January 2011 16:45:36, Aaron Gray wrote:
This is interesting, what does the following line do :-
data Int24 = I24# Int# deriving (Eq, Ord)
regarding the I24# and Int#, are these inbuilt ?
Int# is the raw machine int (4 or 8 bytes) and I24# is the constructor. GHC uses the magic hash '#' to denote raw unboxed types (and the
constructors
making ordinary boxed Haskell types from these, e.g. there's
data Int = I# Int# data Word = W# Word# data Double = D# Double#
and more defined in base [GHC.Types, GHC.Word]).
So the 24 bit value is actually stored as a 32bit value. Meaning I will have to do my own IO reader and writer code to a ByteString. Thanks, Aaron
I don't think so - the Storable instance provided for the Int24 type peeks and pokes 24-bit values. At least, that what I understand John's earlier message to mean.
Yes looking at the code it does support 24bit peeks and pokes. Thanks, Aaron

On Mon, Jan 10, 2011 at 3:45 PM, Aaron Gray
On 10 January 2011 13:49, John Lato
wrote: From: Aaron Gray
On 9 January 2011 21:30, Henning Thielemann
wrote: On Sun, 9 Jan 2011, Aaron Gray wrote:
I am trying to work out how to use GHC.Ptr, Foreign.Storable,
Data.Storable.Endian, and am looking for good examples of usage.
What do you intend to do with them?
An (ABC) ActionScript Byte Code backend for Haskell.
Basically I need to write little-endian binary to a file, and was wondering the best way to do this; I need various types including a 24bit type.
You could use my "word24" package[1] (GHC only) to provide non-aligned 24-bit word and int types with Storable instances. You should be able to write a binary instance (or whatever blaze-builder needs) fairly simply from this. Little-endian only ATM, but BE could be added if necessary.
John Lato [1] http://hackage.haskell.org/package/word24
This is interesting, what does the following line do :-
data Int24 = I24# Int# deriving (Eq, Ord)
regarding the I24# and Int#, are these inbuilt ?
The Int# is built-in to GHC; it's an unboxed Int type (C long int, see http://www.haskell.org/ghc/docs/7.0-latest/html/users_guide/primitives.html#... ). I24# is not built-in; it's just a normal constructor. Although it has a hash suffix, that's just a convention (as documented under the MagicHash pages); it behaves exactly like any other constructor. This means that an Int24 works just like an Int, Int16, etc. It can be lazy, but will also be unboxed by GHC when appropriate. Arithmetic on the unboxed type will result in machine ops. This isn't strictly necessary; Int24 could be nearly equivalently defined as data Int24 = Int24 {-# UNPACK #-} !Int32 but using unboxed types is perhaps more efficient. The UNPACK pragma wasn't available when I wrote Int24, which is why I did it this way. I may revisit this decision in the future; unboxed types are tied closely to GHC, and the UNPACK/strict combination would be more portable and easier to maintain. John

John Lato schrieb:
You could use my "word24" package[1] (GHC only) to provide non-aligned 24-bit word and int types with Storable instances. You should be able to write a binary instance (or whatever blaze-builder needs) fairly simply from this. Little-endian only ATM, but BE could be added if necessary.
Good to know that! However, I think for the original poster the binary package is perfect. This way he does not worry about unsafe peeking and poking around in memory.

On 10 January 2011 22:30, Henning Thielemann
John Lato schrieb:
You could use my "word24" package[1] (GHC only) to provide non-aligned 24-bit word and int types with Storable instances. You should be able to write a binary instance (or whatever blaze-builder needs) fairly simply from this. Little-endian only ATM, but BE could be added if necessary.
Good to know that! However, I think for the original poster the binary package is perfect. This way he does not worry about unsafe peeking and poking around in memory.
Yes. I have came back to looking at the binary package, the only thing is I think I have to build my own primatives with it as it is big-endian, where ActionScript Byte Code format is little-endian. It does provide some little-endian functions but they are not brought to the surface. It also seems to roll its own serializations. I am maybe looking at doing my own specialized set of types and binary backend as there are drawback with each of the existing solutions. - Data.Storable.Endian - peeks and pokes rather than put/get - Data.Word24 - peeks and pokes rather than put/get - Data.Binary - big-endian ABC format may best be supported by a specific set of serialization types. On a different note thinking outside this problem, I would like IO_LE and IO_BE types if that could be make to work. Aaron

On Mon, Jan 10, 2011 at 5:23 PM, Aaron Gray
On 10 January 2011 22:30, Henning Thielemann
wrote: John Lato schrieb:
You could use my "word24" package[1] (GHC only) to provide non-aligned 24-bit word and int types with Storable instances. You should be able to write a binary instance (or whatever blaze-builder needs) fairly simply from this. Little-endian only ATM, but BE could be added if necessary.
Good to know that! However, I think for the original poster the binary package is perfect. This way he does not worry about unsafe peeking and poking around in memory.
Yes. I have came back to looking at the binary package, the only thing is I think I have to build my own primatives with it as it is big-endian, where ActionScript Byte Code format is little-endian. It does provide some little-endian functions but they are not brought to the surface. It also seems to roll its own serializations.
The 'binary' package supports big-endian, little-endian and host-endian construction in the Data.Binary.Builder module, so you hopefully won't need to reimplement too much.
I am maybe looking at doing my own specialized set of types and binary backend as there are drawback with each of the existing solutions. - Data.Storable.Endian - peeks and pokes rather than put/get - Data.Word24 - peeks and pokes rather than put/get - Data.Binary - big-endian ABC format may best be supported by a specific set of serialization types. On a different note thinking outside this problem, I would like IO_LE and IO_BE types if that could be make to work. Aaron
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 11 January 2011 00:02, Antoine Latter
On Mon, Jan 10, 2011 at 5:23 PM, Aaron Gray
wrote: On 10 January 2011 22:30, Henning Thielemann < lemming@henning-thielemann.de> wrote:
John Lato schrieb:
You could use my "word24" package[1] (GHC only) to provide non-aligned 24-bit word and int types with Storable instances. You should be able to write a binary instance (or whatever blaze-builder needs) fairly simply from this. Little-endian only ATM, but BE could be added if necessary.
Good to know that! However, I think for the original poster the binary package is perfect. This way he does not worry about unsafe peeking and poking around in memory.
Yes. I have came back to looking at the binary package, the only thing is I think I have to build my own primatives with it as it is big-endian, where ActionScript Byte Code format is little-endian. It does provide some little-endian functions but they are not brought to the surface. It also seems to roll its own serializations.
The 'binary' package supports big-endian, little-endian and host-endian construction in the Data.Binary.Builder module, so you hopefully won't need to reimplement too much.
Are there any examples of usage anywhere ? It does not seem to have 24bit values either. I am still thinking of implementing my own following the straight Data.Binary package as an example. Aaron

On Tue, Jan 11, 2011 at 10:22 AM, Aaron Gray
On 11 January 2011 00:02, Antoine Latter
wrote: On Mon, Jan 10, 2011 at 5:23 PM, Aaron Gray
wrote: On 10 January 2011 22:30, Henning Thielemann
wrote: John Lato schrieb:
You could use my "word24" package[1] (GHC only) to provide non-aligned 24-bit word and int types with Storable instances. You should be able to write a binary instance (or whatever blaze-builder needs) fairly simply from this. Little-endian only ATM, but BE could be added if necessary.
Good to know that! However, I think for the original poster the binary package is perfect. This way he does not worry about unsafe peeking and poking around in memory.
Yes. I have came back to looking at the binary package, the only thing is I think I have to build my own primatives with it as it is big-endian, where ActionScript Byte Code format is little-endian. It does provide some little-endian functions but they are not brought to the surface. It also seems to roll its own serializations.
The 'binary' package supports big-endian, little-endian and host-endian construction in the Data.Binary.Builder module, so you hopefully won't need to reimplement too much.
Are there any examples of usage anywhere ? It does not seem to have 24bit values either. I am still thinking of implementing my own following the straight Data.Binary package as an example. Aaron
I used Data.Binary.Builder in an implementation of the memcached binary protocol: http://hackage.haskell.org/packages/archive/starling/0.3.0/doc/html/Network-... I'm sure other folks can chime in with good examples if that one isn't clear - the package 'binary' is pretty popular. You'd have to write your own putWord24be/le or whatever you need out of the 'singleton :: Word8 -> Builder' function. But that seems simpler than reimplementing Data.Binary. The package blaze-builder might have primitives for converting a Storable instance into a Builder function, but I don't have any direct experience with it. Antoine

On 11 January 2011 18:54, Antoine Latter
On Tue, Jan 11, 2011 at 10:22 AM, Aaron Gray
wrote: On 11 January 2011 00:02, Antoine Latter
wrote: On Mon, Jan 10, 2011 at 5:23 PM, Aaron Gray
wrote:
On 10 January 2011 22:30, Henning Thielemann
wrote: John Lato schrieb:
You could use my "word24" package[1] (GHC only) to provide non-aligned 24-bit word and int types with Storable instances. You should be able to write a binary instance (or whatever blaze-builder needs) fairly simply from this. Little-endian only ATM, but BE could be added if necessary.
Good to know that! However, I think for the original poster the
binary
package is perfect. This way he does not worry about unsafe peeking and poking around in memory.
Yes. I have came back to looking at the binary package, the only thing is I think I have to build my own primatives with it as it is big-endian, where ActionScript Byte Code format is little-endian. It does provide some little-endian functions but they are not brought to the surface. It also seems to roll its own serializations.
The 'binary' package supports big-endian, little-endian and host-endian construction in the Data.Binary.Builder module, so you hopefully won't need to reimplement too much.
Are there any examples of usage anywhere ? It does not seem to have 24bit values either. I am still thinking of implementing my own following the straight Data.Binary package as an example. Aaron
I used Data.Binary.Builder in an implementation of the memcached binary protocol:
http://hackage.haskell.org/packages/archive/starling/0.3.0/doc/html/Network-...
Nice code, I like the Serialize and Deserialize classes. Its a shame Data.Binary does not use them.
I'm sure other folks can chime in with good examples if that one isn't clear - the package 'binary' is pretty popular.
You'd have to write your own putWord24be/le or whatever you need out of the 'singleton :: Word8 -> Builder' function. But that seems simpler than reimplementing Data.Binary.
Yes. Thanks, Aaron

On Mon, 10 Jan 2011, Aaron Gray wrote:
Yes. I have came back to looking at the binary package, the only thing is I think I have to build my own primatives with it as it is big-endian, where ActionScript Byte Code format is little-endian. It does provide some little-endian functions but they are not brought to the surface. It also seems to roll its own serializations.
Maybe the storable-endian types can be equipped with 'Binary' instances.
participants (5)
-
Aaron Gray
-
Antoine Latter
-
Daniel Fischer
-
Henning Thielemann
-
John Lato