Re[2]: [Haskell-cafe] Re: [Haskell] installing streams library
Hello Jacques, Wednesday, May 31, 2006, 5:33:39 PM, you wrote: encodePtr :: (Binary a, Integral size) = a - IO (ForeignPtr x, size) encodePtrLE :: (Binary a, Integral size) = a - IO (ForeignPtr x, size) encodePtrBitAligned :: (Binary a, Integral size) = a - IO (ForeignPtr x, size) encodePtrBitAlignedLE :: (Binary a, Integral size) = a - IO (ForeignPtr x, size) Am I the only one who finds this encoding-of-types in the _name_ of a function quite distateful? There is no type safety being enforced here, no ensuring one will not be encoding a Ptr one way and decoding it another. Why not use Haskell's type system to help you there? i misunderatood you when i wrote previous message. now that i can say: you are right. but on practice this means more text typing and coercion. especially when we go to ForeignPtrs. moreover, in most cases, imho, data encoded by 'encodePtr*', will go to the FFI libraries, so we can't use typechecking anyway i'm not against your idea, you absolutely right that this will be more Haskell way, but can this be implemented without additional complications for library users? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: [Haskell] installing streams library
Hello Jacques, Wednesday, May 31, 2006, 8:07:29 PM, you wrote: I am completely biased in this regard: I have spent several years maintaining ~800Kloc of legacy dynamically typed [commercial] code. A lot of this code has a life-span of roughly 20 years [ie once written, it takes an average of 20 years before it gets re-written]. That experience has converted me to a static-type fan, as well as a fan of designs that are for the long term; short-term convenience is something that is great for short-lived code ( 5 years is short-lived to me ;-) ). my own programming experience say the same - strict typing significantly simplify program writing by ensuring it's correctness. and Haskell catch many problems as early as i compile code. but in this case we will add more complexity for standard use of functions (when just Ptr required) without any improvements in reliability just to catch potential problems with unusual usage. moreover, there are also encode/encodeLE/... functions that produce String - they also don't need any special String types why i include encoding type in function name? just to simplify usage, all the 'encodePtr*' functions can be expressed via one encodePtrWith, but i don't think that many peoples want to write this himself: encodePtr = encodePtrWith put_ encodePtrLE = encodePtrLEWith put_ encodePtrBitAligned = encodePtrBitAlignedWith put_ encodePtrBitAlignedLE = encodePtrBitAlignedLEWith put_ encodePtrLEWith write = encodePtrWith (\s a- withByteAlignedLE s (`write` a)) encodePtrBitAlignedWith write = encodePtrWith (\s a- withBitAligneds (`write` a)) encodePtrBitAlignedLEWith write = encodePtrWith (\s a- withBitAlignedLE s (`write` a)) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Re: [Haskell] installing streams library
At Thu, 25 May 2006 13:42:11 +0400,
Bulat Ziganshin wrote:
Hello Jeremy,
Monday, May 22, 2006, 12:20:54 AM, you wrote:
For my own needs, I cabalized and debianized the Streams library. It
generates binary debs for ghc6 and hugs -- but I think the hugs
version is broken. In any case, it is a start, you can download the
packaging at:
http://www.n-heptane.com/nhlab/tmp/Streams_packaging.tar.gz
can i include your work in the library itself?
Absolutely.
is it better to include 'debian' directory to my archive or left
this to the debian packagers?
If someone volunteers to maintain the package -- then it is probably
better to not keep a copy of the debian directory in your archive --
because it will often be out of date and confuse people -- and debian
users will be able to get the debianized source easily by typing,
'apt-get source haskell-streams'.
On the other hand -- if there is no one officially maintaing it -- it
would be useful to provide the debian directory (with a disclaimer) so
that debian users can easily build and install the .deb, since
subverting the debian package system tends to lead to long-term
complications.
can you say how you are use my library? it's both interesting for me
and can be helpful in deciding how it should be further developed
I am using it to serialize/deserialize haskell data structures so I
can store them in a Berkeley database.
To get them into BDB I need to convert the haskell data structure into
a C structure that looks like this:
struct __db_dbt {
void *data; /* Key/data */
u_int32_t size; /* key/data length */
};
Currently I am doing it like this -- but this will clearly fail if the
serialized data structure is longer than 512 bytes...
withDBT :: (Binary a) = a - (Ptr DBT - IO b) - IO b
withDBT thedata f =
allocaBytes #{size DBT} $ \dbtPtr -
allocaBytes 512 $ \dataPtr -
do h - openMemBuf dataPtr 512
withByteAlignedLE h $ flip put_ thedata
wrote - vTell h
vClose h
#{poke DBT, data} dbtPtr (castPtr dataPtr)
#{poke DBT, size} dbtPtr ((fromIntegral wrote) :: Int)
f dbtPtr
I don't really need the file-system interface for this project -- what
would be nice is something like 'withCStringLen' and 'peekCString' for
the encode/decode functions:
type PtrLen a = (Ptr a, Int)
encodePtrLen :: (Binary a) = a - (PtrLen a - IO b) - IO b
decodePtr :: (Binary a) = Ptr a - IO a
I could simulate this by using 'encode' to convert the data structure
to a String and then use 'withCStringLen' to get the pointer and
length -- but having the intermediate String seems like it could be a
big performance hit.
Two alternative ideas are:
(1) accurately pre-calculate the size of the serialized structure and
allocate the correct amount of memory from the start
(2) start with a 'guess' and realloc the memory if the initial guess
is too small.
Both of those alternatives have their own problems -- so I think only
testing will tell what works best...
I have not looked at the library exhaustively, so if there is already
a good way to do this, let me know.
Thanks!
j.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: [Haskell] installing streams library
Hello Jeremy, Monday, May 22, 2006, 12:20:54 AM, you wrote: For my own needs, I cabalized and debianized the Streams library. It generates binary debs for ghc6 and hugs -- but I think the hugs version is broken. In any case, it is a start, you can download the packaging at: http://www.n-heptane.com/nhlab/tmp/Streams_packaging.tar.gz can i include your work in the library itself? is it better to include 'debian' directory to my archive or left this to the debian packagers? can you say how you are use my library? it's both interesting for me and can be helpful in deciding how it should be further developed -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: [Haskell] installing streams library
Hello Ross, Monday, May 22, 2006, 3:59:17 AM, you wrote: cpphs --noline -D__HUGS__ -D__HUGS_VERSION__=2005 -DSIZEOF_HSINT=4 -DSIZEOF_HSWORD=4 Cabal already adds -D__HUGS__ when building for Hugs, __HUGS_VERSION__ isn't used, and the SIZEOF's aren't universally valid. For GHC, the package gets them from MachDeps.h (an undocumented interface). Doing it portably probably requires autoconfery. but what to do if library depends on Hugs version and word size of target machine? GHC can solve such problems by providing all the necessary preprocessor symbols but Hugs can't :( -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
