On 01 February 2005 23:59, Peter Simons wrote:
> Simon Marlow writes:
>
> > This was due to a bug in GHC introduced a few days ago
> > and fixed yesterday. Please try again.
>
> I have tried again moments ago: same problem.
Sorry, should be fixed now.
Cheers,
Simon
__
Hello,
I'm getting this error:
Stack space overflow: current size 1048576 bytes.
Use `+RTS -Ksize' to increase it.
The application is compiled under ghc 6.2.1
I've increased it and everything works, but before I begin to look for the way
to pass an environment variable to a cgi app on apache und
On Tue, Feb 01, 2005 at 11:02:45AM -, Simon Marlow wrote:
> So the new approach is to try to build up a global table of the "best"
> destinations to link to for each entity.
Having a canonical home location for each entity might also help with
another bugbear with Haddock: determining whether
All,
I'm looking for advice on how to figure out why some piece of code is
allocating memory when I think it ought to be able to work in constant
space.
In these cases we cannot turn on traditional profiling since that would
interfere with the optimisations we are relying on to eliminate most of
Tomasz Zielonka writes:
> threadWaitRead :: Int -> IO ()
> threadWaitWrite :: Int -> IO ()
Thanks for the pointer!
Am I correct in assuming that there is no "more high-level"
mechanism for scheduling more than one file descriptor? Like
select(2) or poll(2) would do?
I guess, I could i
Simon Marlow wrote:
> I've now fixed system and rawSystem to do something more appropriate on
> POSIX systems: they now disable SIGINT and SIGQUIT in the parent, and
> reset these signals to SIG_DFL in the child. This isn't completely
> correct, but it's better than before.
Just a reminder, as
Hi!
On Wed, Feb 02, 2005 at 02:57:24PM +0100, Peter Simons wrote:
> Tomasz Zielonka writes:
>
> > threadWaitRead :: Int -> IO ()
> > threadWaitWrite :: Int -> IO ()
>
> Thanks for the pointer!
>
> Am I correct in assuming that there is no "more high-level"
> mechanism for scheduling
Hi all,
The Debian ghc6 package curently has both a build-dependency and a
normal dependency on libreadline4-dev. The former is so the readline
library (and ghci) can be built, and the latter so compiling programs
with the readline package behaves correctly.
Now I want to move over to libreadlin
On Wed, Feb 02, 2005 at 05:58:58AM -0800, Peter Simons wrote:
> Tomasz Zielonka writes:
>
> > threadWaitRead :: Int -> IO ()
> > threadWaitWrite :: Int -> IO ()
>
> Thanks for the pointer!
>
> Am I correct in assuming that there is no "more high-level"
> mechanism for scheduling more t
Tomasz Zielonka writes:
>> Like select(2) or poll(2) would do?
> You seem to what something low-level.
Well, my point is that I don't really want to deal with the
file descriptors. What I'd really like to do is to register
a call-back function; similar to the way signal handlers
work. I don't
So I guess I can't really use them in code that's supposed
to be portable among different platforms?
Maybe 'forkOS' combined with calling poll() through FFI
really is the best solution? I seem to recall reading
somewhere that the threaded RTS was more efficient for these
applications anyway?
Two mi
On 02 February 2005 13:38, Duncan Coutts wrote:
> I'm looking for advice on how to figure out why some piece of code is
> allocating memory when I think it ought to be able to work in constant
> space.
>
> In these cases we cannot turn on traditional profiling since that
> would
> interfere with
On Wed, 2005-02-02 at 17:01 +, Simon Marlow wrote:
> On 02 February 2005 13:38, Duncan Coutts wrote:
> > Would looking at the core files help? What would I be looking for?
> >
> > Here's a simple version that I would expect to run in constance space.
> >
> > pixbufSetGreen :: Pixbuf -> IO ()
Wolfgang Thaller writes:
> a) poll() is not supported on Mac OS X and (at least some
> popular versions of) BSD.
Are you certain? Just tried "man poll" on one of the MacOS X
machines the SourceForge compile farm offers, and that one
had it: "Darwin ppc-osx1 5.5 Darwin Kernel Version 5.5".
>
Duncan Coutts wrote:
All,
I'm looking for advice on how to figure out why some piece of code is
allocating memory when I think it ought to be able to work in constant
space.
In these cases we cannot turn on traditional profiling since that would
interfere with the optimisations we are relying on to
On Wed, 2005-02-02 at 13:30 -0700, Seth Kurtzberg wrote:
> Duncan Coutts wrote:
> >In these cases we cannot turn on traditional profiling since that would
> >interfere with the optimisations we are relying on to eliminate most of
> >the other memory allocations.
> >
> I don't understand why you c
16 matches
Mail list logo
