Duncan Coutts [EMAIL PROTECTED] writes:
Because I'm writing the Unicode-friendly ByteString =p
He's designing a proper Unicode type along the lines of ByteString.
So - storing 22.5 bit code points instead of 8-bit quantities? Or
storing whatever representation from the input, and providing a
Hello Ketil,
Friday, May 30, 2008, 11:00:10 AM, you wrote:
I guess this is where I don't follow: why would you need more short
strings for Unicode text than for ASCII or 8-bit latin text?
BS package require too much memory for storing short strings.
alternative package that minimizes memory
On Fri, May 30, 2008 at 9:00 AM, Ketil Malde [EMAIL PROTECTED] wrote:
Duncan Coutts [EMAIL PROTECTED] writes:
The reason we do not want to re-use ByteString as the underlying
representation is because they're not good for short strings and we
expect that for Unicode text (more than arbitrary
Johan Tibell [EMAIL PROTECTED] writes:
I guess this is where I don't follow: why would you need more short
strings for Unicode text than for ASCII or 8-bit latin text?
But ByteStrings are neither ASCII nor 8-bit Latin text!
[...]
The intent of the not-yet-existing Unicode string is to
Hi!
On Fri, May 30, 2008 at 10:38 AM, Ketil Malde [EMAIL PROTECTED] wrote:
Johan Tibell [EMAIL PROTECTED] writes:
The intent of the not-yet-existing Unicode string is to represent
text not bytes.
Right, so this will replace the .Char8 modules as well? What confused
me was my
On Fri, 2008-05-30 at 10:38 +0200, Ketil Malde wrote:
Johan Tibell [EMAIL PROTECTED] writes:
I guess this is where I don't follow: why would you need more short
strings for Unicode text than for ASCII or 8-bit latin text?
But ByteStrings are neither ASCII nor 8-bit Latin text!
it makes me wonder: can we support concatenation with sharing (e.g. the
rope data structure)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Johan Tibell [EMAIL PROTECTED] writes:
Lazy I/O comes with a penalty in terms of correctness!
Is there a page describing this in more detail? I believe my programs
to be correct, but would like to know if there are additional
pitfalls, beyond hClosing a handle with outstanding (unevaluated)
Ketil Malde wrote:
I guess this is where I don't follow: why would you need more short
strings for Unicode text than for ASCII or 8-bit latin text?
Because ByteString is optimised for dealing with big blobs of binary
data, its performance when you split a big ByteString into a pile of
words is
I'm trying to implement some file I/O where I can read in a file to an
array, but do so without having to know how much space I will need.
(Before you suggest it, lists are too slow/space consuming.) I was
thinking that one possible solution is to use a strategy used in
dynamic arrays, where
Define too slow, time-consuming? I've dealt with this problem a lot
at this point, and I've been able to slurp up CSV files of several
gigabytes in the same amount of time as I generally do in C. I have a
feeling an array solution is just going to bog you down more, however
if you insist, I
Hello Tom,
Thursday, May 29, 2008, 8:21:25 PM, you wrote:
Are there any low-level array types (MutableByteArray#, for example)
that support a memcpy-like function
yes, MBA# allows to use memcpy. you can find examples of its
usage right in the array package, for example:
thawSTUArray :: Ix i
Isn't fast IO what ByteStrings where invented for?
Adrian
Tom Harper schrieb:
I'm trying to implement some file I/O where I can read in a file to an
array, but do so without having to know how much space I will need.
(Before you suggest it, lists are too slow/space consuming.) I was
thinking
Exactly. Someone on the list gave me this example awhile back for
reading CSV files. I can process a gigabyte (simple unpack and print
to dev/null for IO testing purposes) in about two and a half seconds
using this code.
import Data.ByteString.Lazy.Char8 as C
-- | Read a datafile and turn it
Tom Harper wrote:
I'm trying to implement some file I/O where I can read in a file to an
array, but do so without having to know how much space I will need.
Why not just read it into a lazy ByteString? Are you looking to use an
array with elements of a different type? You could then convert
Why not just read it into a lazy ByteString? Are you looking to use an
array with elements of a different type? You could then convert it to a
strict ByteString.
b
Because I'm writing the Unicode-friendly ByteString =p
--
Tom Harper
MSc Computer Science '08
University of Oxford
Tom Harper wrote:
Because I'm writing the Unicode-friendly ByteString =p
Perhaps I'm not understanding. Why wouldn't you use ByteString for I/O,
even if you're writing a different library? After all, ByteString's own
internals use memcpy.
b
On Thu 2008-05-29 19:19, Tom Harper wrote:
Why not just read it into a lazy ByteString? Are you looking to use an
array with elements of a different type? You could then convert it to a
strict ByteString.
Because I'm writing the Unicode-friendly ByteString =p
Uh, ByteString is
On Thu, 2008-05-29 at 11:25 -0700, Bryan O'Sullivan wrote:
Tom Harper wrote:
Because I'm writing the Unicode-friendly ByteString =p
Perhaps I'm not understanding. Why wouldn't you use ByteString for I/O,
even if you're writing a different library? After all, ByteString's own
internals
Hello Duncan,
Thursday, May 29, 2008, 10:57:02 PM, you wrote:
We cannot use memcpy because it operates on raw pointers but that's no
good for a movable heap object like a ByteArr#.
it's false assumption - memcpy is used for copying non-pinned arrays
as in the code from Data.Array.Base i've
duncan.coutts:
On Thu, 2008-05-29 at 11:25 -0700, Bryan O'Sullivan wrote:
Tom Harper wrote:
Because I'm writing the Unicode-friendly ByteString =p
Perhaps I'm not understanding. Why wouldn't you use ByteString for I/O,
even if you're writing a different library? After all,
21 matches
Mail list logo
