Adrian Hey writes:
I don't see any value in problems that are
specifically designed so that they can be solved
only with a global entity.
Even if it was true that I had specifically
designed this problem, it's existance is of some
interest I think.
Perhaps my choice of words wasn't
Since I have been experimenting with Arrows quite a bit just
recently, I feel compelled to add something to the
discussion.
I too think that Arrow are a beautifully simple and elegant
concept. However, once you write production code, you notice
quickly that there is a significant difference
John Goerzen writes:
Given that the block-oriented approach has constant space
requirements, I am fairly confident it would save memory.
Perhaps a bit, but not a significant amount.
I see.
[read/processing blocks] would likely just make the
code a lot more complex. [...]
Either
John Goerzen writes:
Read and process the file in blocks:
I don't think that would really save much memory [...]
Given that the block-oriented approach has constant space
requirements, I am fairly confident it would save memory.
and in fact, would likely just make the code a lot more
Alexander N Kogan writes:
I'm newbie and I don't understand how to process large
files in haskell with constant memory requirements.
Read and process the file in blocks:
http://cryp.to/blockio/docs/tutorial.html
Peter
___
Haskell-Cafe mailing
oleg writes:
It seems you don't need to store the whole state in MVar:
it's enough to store a `clean-up' action.
Yes, that is good advice, I'll do that. Thank you, Oleg.
Peter
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
John Goerzen writes:
(progname): forkProcess: uncaught exception
Quoting from the documentation:
forkProcess :: IO () - IO ProcessID
[...] On success, forkProcess returns the child's
ProcessID to the parent process; in case of an error, an
exception is thrown.
What I assume is
Remi Turk writes:
Assuming I could _not_ use 'bracket', 'withFile',
'finally' or any of the other usual scope-guarding
techniques [...]
Refactoring comes to the mind... ;)
I wish that were possible! I use bracket-style resource
allocation wherever I can, but in this case the Handle is
Keean Schupke writes:
The _result_ of a rather complex computation
return a function that returns the handle.
The idea is good. :-) You'll find my other posting explains
that a bit more: My main driver doesn't know about the
handle; that's just one more entry in the state of the
connection
What happens when a System.IO.Handle falls out of scope
without being explicitly hClosed? Is that a resource leak?
Or will the RTS close the handle for me?
Peter
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
Ben Rudiak-Gould writes:
Must contexts be used in a single-threaded manner? If so,
I would expect this interface:
start :: IO ctx
feed :: ctx - Buffer - IO ()
commit :: ctx - IO a
'feed' cannot have this signature because it needs to update
the context.
If not, I
K P SCHUPKE writes:
This is the interface I came up with (and its fairly efficient):
data IList a i e = ICons i i (a i e) (IList a i e) | INil
Isn't that an interface for doing fast I/O rather than for
writing stream processors? If I look at the consumer:
wc :: List l Word8 = l Word8 -
K P SCHUPKE writes:
Okay, maybe I misunderstood, I thought by stream
processors you meant functions of the type:
process :: [a] - [a]
No, my stream processors currently have the API I described
in my initial posting. What I was wondering is whether there
is a more general API that I
Ben Rudiak-Gould writes:
start :: IO ctx
feed :: ctx - Buffer - IO ()
commit :: ctx - IO a
'feed' cannot have this signature because it needs to
update the context.
Sure it can -- it's just like writeIORef :: IORef a - a - IO ().
I guess it's mood to argue that
K P SCHUPKE writes:
My point was... using the IO library I posted which
abstracts the buffer management, you can treat the IO as
a simple list...
Do you happen to have a ready-to-run word-counting example
for me which is based on your library? I've tried to compile
the code you posted, but
Jeremy Shaw writes:
Here is a some code I scraped off the net a while ago,
though I can't seem to find the origin anymore.
I _think_ it is from part of Fudgets library:
http://www.cs.chalmers.se/Cs/Research/Functional/Fudgets/
Thanks for posting it, though, this implementation is rather
Ben Rudiak-Gould writes:
bar :: StreamProc ctx a - IO (a,a)
bar sp = do
ctx - start sp
(ptr1,n1) - ...
(ptr2,n2) - ...
ctx1 - feed sp ctx (ptr1,n1)
ctx2 - feed sp ctx (ptr2,n2)
val1 - commit sp ctx1
val2 - commit sp ctx2
return (val1,val2)
Sam Mason writes:
Just to muddy the water a bit. . . What happens if the
second string is infinite?
This version should do it:
isSubSeq :: (Eq a) = [a] - [a] - Bool
isSubSeq [] _= True
isSubSeq _ []= False
isSubSeq (x:xs) (y:ys)
| x == y= isSubSeq xs ys
|
Ketil Malde writes:
Couldn't readFile et al. provide the standard interface,
but use hGetBuf tricks (e.g. from your 'wc' entry) behind
the curtains?
No amount of hGetBuf'ing will speed the program up if the
problem is the algorithm. I/O comes _sequentially_, and
every program that doesn't
Keith Wansbrough writes:
Count me as a vote for the better-but-slightly-slower wc.
How about the attached program? On my machine it faster than
Tomasz's version, and I think it's still a fairly clean
source code. Using some random large file for input, I got
these results with time(1):
real
Josef Svenningsson writes:
What *is* true is that it is difficult to write good
performance I/O in any of the *implementations* that we
have.
GHC has everything you need to do fast I/O in Haskell. If
you use hGetBufNonBlocking with 'Ptr a', you have
essentially the performance of read(2).
Hi,
while polishing a small library of mine, I ended up writing
a tutorial about the use of hGetBufNonBlocking and the
related Foreign.* functions you need to do fast,
block-oriented I/O in Haskell. There is something to be said
for literate programming.
Using recent topics for inspiration, the
How can anyone stay away from such a deliciously pointless
waste of time as implementing a wc(1) derivate? :-)
Here is my attempt:
import IO
type Count = Int
data CountingState = ST !Bool !Count !Count !Count
deriving (Show)
initCST = ST True 0 0 0
John Goerzen writes:
That failed, though, because getContents closes the file
after it's been completely read (ugh -- why?).
getContents reads from standard input: you can't seek on
that stream. Just think of cat file | cat. The second
invocation reads from a pipe, not from a file on disk.
Glynn Clements writes:
About the only functions in Network.CGI which might be
useful for processing file uploads are getQueryString and
getCgiVars, neither of which are exported.
Fortunately, another reader of this list has written the
necessary parsers already and sent me a copy of the
Has anyone managed to process the results of a file upload
formular, such as
form action=input_file.htm enctype=multipart/form-data
pChoose a file: input name=foobar type=file size=50
maxlength=10 accept=text/*
/p
/form
..., with Network.CGI successfully? I
[ I'm posting this article here again, because the general ]
[ mailing list seems to be closed to non-members, and I'm ]
[ reading/posting through gmane.org. Pardon me, if you see ]
[ this on both lists, please. -peter ]
Hi,
I have a question concerning manual I/O
Graham Klyne writes:
I'm thinking in particular that a function that turned a regular
expression into a Parsec parser function could be useful, as in:
regexp.compile :: String - GenParser Char st [String]
Just curious: Why would you want something like that? I thought that
the good
Peter Gammie writes:
Haskell Report, Sec 3.15.3
Great, that's exactly what I need.
Thanks a lot to all who replied!
Peter
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Simon Marlow writes:
hGetLine should work fine, indeed that's what I used in the Haskell
Web Server.
Well, another -- and more important -- problem with hGetLine is that
it will read an arbitrarily long line. An attacker might use this to
implement an denial-of-service attack simply by
Hi,
is anyone aware of a library for Haskell, which allows to query domain
name servers for MX, A, and PTR records in a non-blocking way?
My first guess was to create an Interface to ADNS [1], but I figured,
maybe someone else has already solved this problem?
Peter
[1]
Jeff Aimt writes:
[haskell-cafe via news server]
You can access the mailing list via NNTP under the name
gmane.comp.lang.haskell.cafe on news.gmane.org. See
http://www.gmane.org/ for further details.
Peter
___
Haskell-Cafe mailing list
[EMAIL
I understand that I can mark-up code segments in a literate source
module using the syntax:
\begin{code}
...
\end{code}
But is it somehow possible to re-define this to be
haskellcode
...
/haskellcode
instead? I am asking because the latter style would enable me to write
Hi,
I have written a parser that turns an RFC2822 date and time
specification into a datatype usable in Haskell. While the parser is
working just fine so far, I have a problem with the CalendarTime
datatype. It appears that in order to construct one of those, I need
_all_ the information it
Simon Peyton-Jones writes:
I hope it's all described adequately in the GHC user manual
http://haskell.org/ghc
I'll take a look at it, thanks!
Unfortunately, before I can worry about this I have to get GHC built
at all. It appears that the available binary versions don't work an a
pure
Simon Peyton-Jones writes:
If Python uses C's calling convention, it might be easy; just use
'foreign import' and 'foreign export' (see the FFI spec at
haskell.org).
I remember reading that the main program, that wants to call Haskell
code, would have to be compiled with a special Haskell
Hi,
the Haskell language is fairly new to me, so please pardon me if this
is a frequently asked question, but I wasn't able to find an answer
myself.
I'm looking for a library that allows me to visualize data under X11
screen, for instance as a pie chart or as a bar chart. I seem to
recall that
101 - 137 of 137 matches
Mail list logo
