Hello Bulat,
Sunday, May 28, 2006, 2:44:37 PM, you wrote:
type PtrLen a = (Ptr a, Int)
encodePtrLen :: (Binary a) = a - (PtrLen a - IO b) - IO b
decodePtr :: (Binary a) = Ptr a - IO a
Finally i've implemented the following (you then would use
'withForeignPtr' to work with contents of
[See comments at bottom]
Bulat Ziganshin wrote:
Finally i've implemented the following (you then would use
'withForeignPtr' to work with contents of ForeignPtr):
-- -
-- Encode/decode contents of memory buffer
You would need to define a type class
(Binary a) = EncodedPtr a b
where the 'a' is as you have it currently, and the b would be an
enumerated type which tracks the memory representation.
I agree they are different concepts - that is why an EncodedPtr would
require 2 type parameters. Of
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
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?
When marshalling
I have no problems with marshalling/unmarshalling (and even with the
implicit casting going on). What I dislike is having a bunch of
functions which are the same but with different names, where the
difference boils down to enumerated types that end up being encoded in
the function name.
Bulat Ziganshin wrote:
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?
C is a language which pushes the boundaries of no complications (ie
convenience) quite far (and yet
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
Hello Jeremy,
Sunday, May 28, 2006, 1:29:02 AM, you wrote:
can i include your work in the library itself?
Absolutely.
thanks
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
On Sun, 2006-05-28 at 14:44 +0400, Bulat Ziganshin wrote:
Hello Jeremy,
Sunday, May 28, 2006, 1:29:02 AM, you wrote:
Two alternative ideas are:
(1) accurately pre-calculate the size of the serialized structure and
allocate the correct amount of memory from the start
it's good
On Sun, 2006-05-28 at 20:40 +0400, Bulat Ziganshin wrote:
Hello Duncan,
Sunday, May 28, 2006, 3:05:53 PM, you wrote:
createMemBuf does exactly this :)
One of the areas where we found that Data.ByteString.Lazy was performing
better than the ordinary Data.ByteString is cases like this
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,
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:
On Sat, 2006-05-20 at 00:00 -0700, Chad Scherrer wrote:
Thanks, Bulat. I'm looking forward to trying it out this weekend.
Is there any indication what fast IO approach might work its way into
the standard libraries? It would be nice for idiomatic Haskell to be
really fast by default, and
As a haskell beginner, I saw the lack of a simple and fast standard
library as THE major dificulty.
Yes, more than monads and lazy programming and all other stuff.
This happened because I simply could not create simple programs to
simple task as I needed then in production work.
I work at
On 5/20/06, Brian Hulley [EMAIL PROTECTED] wrote:
It's strange that with the most advanced programming language in existence
we're still unable to automate the task of having to manually type a
sequence of 3 commands at an ancient UNIX command prompt!!! :-)
No, it's not strange. What appears
On 5/20/06, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
Data.ByteString is in the base libraries now.For a bit of the flavour, see:http://haskell.org/haskellwiki/Wc
In this message
http://article.gmane.org/gmane.comp.lang.haskell.general/13625
Bulat says,
i foresee that Streams + Fast Packed
Hello,
I really wanted to respond to the parent thread, but I deleted it
already, so this message will be a bit out of context.
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
On Sun, May 21, 2006 at 01:20:54PM -0700, Jeremy Shaw wrote:
Cabal Question:
The streams library uses cpphs to do some preprocessing. There is a
hugs specific Makefile that invokes cpphs with the command-line:
cpphs --noline -D__HUGS__ -D__HUGS_VERSION__=2005 -DSIZEOF_HSINT=4
chad.scherrer:
On 5/20/06, Donald Bruce Stewart [EMAIL PROTECTED]
wrote:
Data.ByteString is in the base libraries now.
For a bit of the flavour, see:
[2]http://haskell.org/haskellwiki/Wc
In this message
Hello Donald,
Monday, May 22, 2006, 4:19:59 AM, you wrote:
i foresee that Streams + Fast Packed Strings together will yield a
breakthrough in GHC I/O speed, and this can be implemented even
without waiting for GHC 6.6
Before reading this I had thought it might be an XOR
situation,
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
Hello Chad,
Friday, May 19, 2006, 10:40:56 PM, you wrote:
It sounds like Bulat has gotten some impressive I/O speedups with
his Streams library. I'd like to try this out, but I'm having some
trouble installing it. I'm using GHC on Linux.
yes, and current (still unpublished) version is even
Thanks, Bulat. I'm looking forward to trying it out this weekend.
Is there any indication what fast IO approach might work its way into
the standard libraries? It would be nice for idiomatic Haskell to be
really fast by default, and I'd love to be able to show off the language
shootout
On 5/20/06, Chad Scherrer [EMAIL PROTECTED] wrote:
Thanks, Bulat. I'm looking forward to trying it out this weekend.
Is there any indication what fast IO approach might work its way into
the standard libraries? It would be nice for idiomatic Haskell to be
really fast by default, and I'd love to
On 2006-05-20 at 12:00+0200 Sebastian Sylvan wrote:
A quick sales pitch: usually you, the library user, can just type:
./runhaskell Setup.hs configure
./runhaskell Setup.hs build
./runhaskell Setup.hs install
And it will Do The Right Thing(TM), which is nice.
This is something I've never
On Saturday 20 May 2006 06:53 am, Jon Fairbairn wrote:
On 2006-05-20 at 12:00+0200 Sebastian Sylvan wrote:
A quick sales pitch: usually you, the library user, can just type:
./runhaskell Setup.hs configure
./runhaskell Setup.hs build
./runhaskell Setup.hs install
And it will Do The
Hi
FWIW, it's almost identical to the incantation necessary for projects based on
autotools, where it usually reads something like:
./configure
make
make install
But sadly compared to Windows tools, where its just a case of double
click this sounds a bit too complex.
I am hoping that I can
On 2006-05-20 at 11:58EDT Robert Dockins wrote:
On Saturday 20 May 2006 06:53 am, Jon Fairbairn wrote:
Make allows one to set up rules about what depends
on what, so why can't we just arrange it so that someone who
wants to install the thing just hast to type
./runhaskell Setup.hs
Neil Mitchell wrote:
Hi
FWIW, it's almost identical to the incantation necessary for
projects based on autotools, where it usually reads something like:
./configure
make
make install
But sadly compared to Windows tools, where its just a case of double
click this sounds a bit too complex.
I
It sounds like Bulat has gotten some impressive I/O speedups with his Streams library. I'd like to try this out, but I'm having some trouble installing it. I'm using GHC on Linux.My first attempt was looking around on this page:
http://www.haskell.org/haskellwiki/Library/StreamsThere's a really
I found this in an old post (gotta love GMail search):
You can find further information about the library at the
page http://haskell.org/haskellwiki/Library/Streams and
download it as http://freearc.narod.ru/Streams.tar.gz
from a thread in February entitled:
Streams: the extensible I/O
Thanks Jared, but already tried those. I was able to download the Streams library, but I have know idea how to install it.On 5/19/06, Jared Updike
[EMAIL PROTECTED] wrote:I found this in an old post (gotta love GMail search):
You can find further information about the library at the page
33 matches
Mail list logo
