Thomas Bevan wrote:
The lircLoop should never terminate. Unfortunately it does. Worse, no
error messages are generated.
Not even the final line "Closing down" is printed.
How is this possible?
Probably SIGPIPE.
Catch it and ignore it.
___
Haskel
Manuel M T Chakravarty wrote:
PS: Moreover, binaries produced by the above compiler will run on any
Leopard box.
That's great news.
Can you add a note about how you achieved that to
http://hackage.haskell.org/trac/ghc/ticket/1540
please?
My previous attempts to distribute ghc-compiled softr
On 21 Mar 2005, at 12:12, Marcin 'Qrczak' Kowalczyk wrote:
Sven Moritz Hallberg <[EMAIL PROTECTED]> writes:
1. In addition to the backslash, accept "mathematical * small
lamda" (U+1D6CC, U+1D706, U+1D740, U+1D77A, and U+1D7B4) for lambda
abstractions. Leave "greek small letter lamda" as a r
On 11 Feb 2005, at 14:31, Javier García-Vivó Albors wrote:
Does anybody know how to fix it?? I'm getting crazy with this problem!!
From section 8.1 of the hs-plugins manual:
It is also possible to load the plugins or eval libraries in GHC. A
couple of recent patches to the linker have made this p
On 18 Jan 2005, at 16:12, Ben Rudiak-Gould wrote:
I'm not strongly convinced by this argument. I don't think you can
tell me which particular Char value you mean by the expression
(maxBound :: Char) either, yet you probably wouldn't argue for
changing maxBound's type. I think Jim's claim is that
On 18 Jan 2005, at 06:31, Jim Apple wrote:
Tomasz Zielonka wrote:
I like to think that pure functions don't change between executions.
I'd like to think they wouldn't change within executions. Is there a
pure haskell way to check the value of a function between exections?
In principle, a haskell
On 6 Dec 2004, at 15:24, Michael Walter wrote:
Hi,
is there a way to force the "full" evaluation of a value (unless seq,
which only brings the term to WHNF)?
In my case, I have an algebraic data type Foo,
and I would like to catch the exceptions that will occur during the
evaluation of a value of F
On 3 Dec 2004, at 19:22, Duncan Coutts wrote:
I can't immediately think of a collection data structure combining O(1)
lookup with a sparse key space however - that sounds quite tricky.
Hashtable, surely?
Jules
___
Haskell mailing list
[EMAIL PROTECTED]
ht
On 25 Nov 2004, at 19:24, Tomasz Zielonka wrote:
On Thu, Nov 25, 2004 at 07:52:43PM +0100, Lennart Augustsson wrote:
As I'm sure you have gathered from all the answers you can't have the
latter and keep Haskell pure. But there is an interesting alternative
(at least theoretically). You could have
On 24 Nov 2004, at 19:16, Scott Turner wrote:
Each error type is an instance of Hierarchical, so that its errors may
be
considered part of a larger category of errors. In the instance
definition,
'parent' specifies how the error appears if it is caught by a handler
expecting then next more gener
On 24 Nov 2004, at 18:28, John Goerzen wrote:
I note, though, that "making an Either into a Monad" doesn't do
anything
to deal with asynchronous exceptions.
We may be talking at cross purposes here. If, by 'asynchronous
exceptions' you mean that exceptions may lurk arbitrarily deeply within
use
On 24 Nov 2004, at 16:21, Scott Turner wrote:
On 2004 November 23 Tuesday 10:51, John Goerzen wrote:
The way to deal with those kinds of details is to use Either in a
monad. I'm
skeptical of the need for dynamic scope in conventional exception
handling,
so I took a shot at this problem, with s
On 23 Nov 2004, at 15:51, John Goerzen wrote:
On Tue, Nov 23, 2004 at 04:30:21PM +, Keean Schupke wrote:
I am sure this discussion has happened before, but I think for pure
functions, returning Either Error Result is the way to go.
That's certainly possible, but extremely tedious.
It sounds to
On 23 Nov 2004, at 11:53, George Russell wrote:
I wrote (snipped):
> 3) It needs no extensions to the Haskell language, and only fairly
> standard hierarchical libraries like Data.IORef.
Lennart Augustsson wrote (snipped):
> It uses unsafePerformIO which is very much an extension to Haskell.
:)
B
On 8 Nov 2004, at 12:23, Lennart Augustsson wrote:
Adrian Hey wrote:
4- They already exist (stdin,stout,stderr) and I don't
recall anybody ever complaining about this.
stdin, stdout, and stderr are not global variables.
They are just handles. One possible implementation
of handles is as an Int.
On 6 Nov 2004, at 13:07, Keean Schupke wrote:
Just been reading arround. According to ghc docs, the noinline
pragma is in the Haskell98 report. On that basis what is wrong
with using the following to initialise these top-level constants?
{-# NOINLINE newref #-}
newref :: IORef Int
newref =
On 5 Nov 2004, at 19:03, MR K P SCHUPKE wrote:
You don't want stdin/stdout/stderr?
Also these are only available in the IO monad...
without breaking referential transparency
by use of unsafePerformIO hack.
I don't understand this still... how can it not break referntial
transparancy.
For example c
On 13 Oct 2004, at 13:14, MR K P SCHUPKE wrote:
its almost commutative
Does that have something to do with splitting the supply?
That is an approach to getting unique values, I think.
newIORef
why not use 'newSTRef' and use the ST monad...
In the context of my original question, the answer is that
On 12 Oct 2004, at 22:49, MR K P SCHUPKE wrote:
All we really need is a 'unique value monad' to give us unique values
This sounds a lot like Clean's unique-types?
No, that's a confusion of terminology.
'Unique types' are type which have only one member. 'RealWorld' in
haskell is rather like one of
On 13 Oct 2004, at 00:04, Greg Buchholz wrote:
John Meacham wrote:
I have put some thought, some time ago, into the 'global
initializers' problem in haskell but for various reasons never wrote
up my conclusions.
I'm not really qualified to answer, but does anyone think that this
paper might ha
On 12 Oct 2004, at 23:33, John Meacham wrote:
and via the FFI just a
foreign import "&global_var" :: Ptr Int
note that we do not need any foregin code, just an object which
allocates the space in the bss for global_var, the fact we can access
and work with such space from haskell, but have no
On 12 Oct 2004, at 20:25, Adrian Hey wrote:
On Tuesday 12 Oct 2004 6:28 pm, Jules Bean wrote:
On 12 Oct 2004, at 14:08, Adrian Hey wrote:
x <- someAction
y <- someAction(x)
I would say keep things as they currently are with the
unsafePerformIO
solution, I.E. Order unspecified, the actio
On 12 Oct 2004, at 18:59, Marcin 'Qrczak' Kowalczyk wrote:
Jules Bean <[EMAIL PROTECTED]> writes:
I think what people are trying to suggest is an 'initialization
phase' in the IO monad, which takes place "before" the pure
functions are defined.
If it was done b
On 12 Oct 2004, at 14:08, Adrian Hey wrote:
x <- someAction
y <- someAction(x)
I would say keep things as they currently are with the unsafePerformIO
solution, I.E. Order unspecified, the action that creates a particular
top level thing is executed only once, when the value of thing is
demanded (pe
On 7 Oct 2004, at 22:14, Amadeo Casas Cuadrado wrote:
Hello,
Could anyone tell me where can i find a webpage or a paper about how
lazy
implementation is done is Haskell?
For much more than you could ever want to know about haskell, look in
Simon Peyton Jones's page:
http://research.microsoft.co
[snip oleg's paper which looks interesting, and which I will read]
On 8 Oct 2004, at 02:44, [EMAIL PROTECTED] wrote:
The example is writing JNI functions in Haskell. Incidentally, the
example illustrates passing of the implicit state (JNIEnv pointer)
_around_ the exception handler. The problem is t
Hi,
I've been playing with some haskell bindings which basically bind C
procedures in the IO monad. To write 'interesting' programs, you often
need to manage your own state in addition to the implicit IO state.
I have been allocating references with newIORef and then passing them
around all my
27 matches
Mail list logo
