On 23 October 2004 19:25, Lauri Alanko wrote:
On Thu, Oct 21, 2004 at 09:17:20AM -0400, Robert Dockins wrote:
There is a hashtable in the IO monad:
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data.HashTabl
e.html
Why is it in IO instead of the more general ST? IMHO _all_
Sorry I should have broadcast a message about this; I mentioned it to
the *BSD guys because I knew they'd be affected, but forgot about
darwinports. Sorry about that.
Cheers,
Simon
On 23 October 2004 20:27, Gregory Wright wrote:
Hi Sven,
Yes, that would be it. The change is
On 22 October 2004 21:58, Peter Simons wrote:
I know it's a rather mundane question, but I couldn't find
an answer to it!
So what does happen when I forget to hClose a Handle? Will
the garbage collector do that for me? Or not?
Yes, a Handle will be automatically closed sometime after it
Simon Marlow writes:
BTW, I assume you have a good reason for wanting to call
terminateProcess
Yes, I have to abort the process in case of an exception in
my code. Just giving it EOF is not enough, unfortunately.
Thanks a lot for taking the time to answer, Simon. I really
appreciate it.
On 2004-10-25, Simon Marlow [EMAIL PROTECTED] wrote:
On 22 October 2004 21:58, Peter Simons wrote:
On 24 October 2004 23:37, John Goerzen wrote:
* What happens when one Handle corresponding to a socket is closed,
but another isn't?
You shouldn't have two Handles on the same socket. This
On 25 October 2004 14:24, John Goerzen wrote:
On 2004-10-25, Simon Marlow [EMAIL PROTECTED] wrote:
On 22 October 2004 21:58, Peter Simons wrote:
On 24 October 2004 23:37, John Goerzen wrote:
* What happens when one Handle corresponding to a socket is closed,
but another isn't?
You
On 2004-10-25, Simon Marlow [EMAIL PROTECTED] wrote:
If I tried that with a single Handle opened ReadWrite, then I'd get
errors about it being closed whenever I'd try to write out some data.
I wasn't able to find any other good way around it.
Hmmm, you should still be able to *write* to a
John Goerzen writes:
Now, if [I read with hGetContents h], then the first read
I try to make using it works, but subsequent ones don't,
since the first one made it half-closed already.
Maybe I misunderstood something ... but why do you need to
read from the stream multiple times after
On 2004-10-25, Peter Simons [EMAIL PROTECTED] wrote:
John Goerzen writes:
Now, if [I read with hGetContents h], then the first read
I try to make using it works, but subsequent ones don't,
since the first one made it half-closed already.
Maybe I misunderstood something ... but why do you
On Mon, Oct 25, 2004 at 09:42:13PM +, John Goerzen wrote:
Maybe I misunderstood something ... but why do you need to
read from the stream multiple times after calling
hGetContents? The function returns the _entire_ (lazily
evaluated) input stream, there is no need to read again. You
What will happen if I call getProcessExitCode for the same
process twice? Will that block? Cause an error? Or return
the same child's exit code again?
I assume the function is (under Unix) based on wait(2),
right? In that case, how does the following warning from the
manual page translate to
On 2004-10-26, Peter Simons [EMAIL PROTECTED] wrote:
What will happen if I call getProcessExitCode for the same
process twice? Will that block? Cause an error? Or return
the same child's exit code again?
Assuming it is based on wait() or one of its derivatives, and I suspect
it is, you cannot
I am writing a web application server in Haskell.
I would like to be able to modify the app on the
fly. Simplyfing the app server, it would look
like this:
appServer appMVar reqChan state =
do
req - readChan reqChan
app - readMVar appMVar
(state',resp) - return $ app
haskell:
I am writing a web application server in Haskell.
I would like to be able to modify the app on the
fly. Simplyfing the app server, it would look
like this:
appServer appMVar reqChan state =
do
req - readChan reqChan
app - readMVar appMVar
S. Alexander Jacobson [EMAIL PROTECTED] writes:
That lets you load object files. But I would
really like something that loads source files
instead
http://www.cse.unsw.edu.au/~dons/hs-plugins/index.html
hs-plugins can build and load source, and check dependencies, and lots more.
Also,
Due to popular demand, I've uploaded binary snapshots of Alex, Haddock,
Happy and Hugs for Win32 and x86 Linux to
http://aedion.de/haskell/
The corresponding sources are available there, too. Feedback is, as
always, appreciated...
Have fun,
S.
___
Hi Peter,
| I´m progarmming a parser for functional programs. Now
| I want to implement the infixL and infixR feature to increase
| the readability of the code. I would be very glad if anyone
| can send me some information about the implementation of
| this feature of the Haskell parser or where
On Fri, Oct 22, 2004 at 06:20:41PM +0200, Peter Theissen wrote:
Hi,
I want to implement the infixL and infixR feature to increase
the readability of the code. I would be very glad if anyone
can send me some information about the implementation of
this feature of the Haskell parser or where
Have you looked at Parsec.buildExpressionParser:
http://www.cs.uu.nl/~daan/download/parsec/parsec.html
(see section Expressions). This allows very concise programs,
and you don't need to install any extra library.
--
-- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 6480 --
--
Last Call for Papers for
Methods for Modalities
A Special Issue of the Journal of Applied Logic
(http://www.sciencedirect.com/science/journal/15708683)
The workshop `Methods for Modalities' (M4M) organized every two
years aims to bring
Remi Turk [EMAIL PROTECTED] writes:
IMO, [bracket] does indeed have those same drawbacks. (Although the
traditional explicit memory management model is alloc/free,
which is much worse than bracket/withFile)
Isn't bracket more like stack allocated memory? And most problems
with explicit
Cool! That goes on my list for further study.
(I have a work-in-progress of something similar for description logics.)
#g
--
At 15:01 22/10/04 -0700, Brian Beckman wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
On 24 October 2004 20:51, Sven Panne wrote:
IMHO it would be best to use explicit bracketing where possible, and
hope for the RTS/GC to try its best when one runs out of a given
resource. Admittedly the current Haskell implementations could be
improved a little bit in the last respect.
On Mon, Oct 25, 2004 at 08:46:41AM +0200, Ketil Malde wrote:
Remi Turk [EMAIL PROTECTED] writes:
IMO, [bracket] does indeed have those same drawbacks. (Although the
traditional explicit memory management model is alloc/free,
which is much worse than bracket/withFile)
Isn't bracket more
On Mon, Oct 25, 2004 at 02:14:28PM +0100, Simon Marlow wrote:
On 24 October 2004 20:51, Sven Panne wrote:
IMHO it would be best to use explicit bracketing where possible, and
hope for the RTS/GC to try its best when one runs out of a given
resource. Admittedly the current Haskell
On Mon, Oct 25, 2004 at 08:55:46PM +0200, Remi Turk wrote:
P.S. Why do so many people (including me) seem to come to Haskell
from Python? It can't be just the indentation, can it? ;)
How many? I don't.
Best regards,
Tom
--
.signature: Too many levels of symbolic links
Remi Turk [EMAIL PROTECTED] writes:
Hm, I'm not sure about the should. Garbage collection is meant
for memory, and anything making that less clear makes people
more likely to depend on incorrect assumptions.
And redefining GC to be a collection of _all_ garbage, instead of
just memory
On Mon, Oct 25, 2004 at 09:28:23PM +0200, Tomasz Zielonka wrote:
On Mon, Oct 25, 2004 at 08:55:46PM +0200, Remi Turk wrote:
P.S. Why do so many people (including me) seem to come to Haskell
from Python? It can't be just the indentation, can it? ;)
How many? I don't.
Best regards,
Tomasz Zielonka [EMAIL PROTECTED] writes:
P.S. Why do so many people (including me) seem to come to Haskell
from Python? It can't be just the indentation, can it? ;)
How many? I don't.
And I don't either.
But indeed I've seen more references to Haskell on Python lists than
on other
Marcin 'Qrczak' Kowalczyk writes:
I would not be surprised if relying on GC to close open files would
be generally considered kosher in a few years - in cases when it has
little visible effects outside, i.e. excluding network connections,
but including reading configuration files.
One of the
From: David Menendez [EMAIL PROTECTED]
Subject: Re: [Haskell-cafe] Are handles garbage-collected?
Date: Mon, 25 Oct 2004 22:51:34 -0400
Marcin 'Qrczak' Kowalczyk writes:
I would not be surprised if relying on GC to close open files would
be generally considered kosher in a few years - in
31 matches
Mail list logo
