Nicolas Oury wrote:
I don't know if what I say is pertinent, but there was another problem
that was discussed in the thread about threaded RTS.
One may want to use a finalizer in a particular thread.
For example, a finalizer that put make a rotating cube on screen must
be ran in the same thread
On Mon, Nov 18, 2002 at 04:57:50PM -, Simon Marlow wrote:
> You should be aware that -split-objs (the trick we use to build our
> libraries in lots of little bits) gets most of the benefit that you'd
> get from using -ffunction-sections. You might get slightly more
> fine-grained discarding of
I don't know if it is planned but I think it could be great to be able
to have, in the new OS thread for OpenGL, an "expressivity only"
concurrence system. I mean that to be able to fork user threads that are
executed in the new OS thread. These new threads would be blocked on
other threads in
Yes, there are several reasons for having UNSAFE in the name. :-)
-- Lennart
Ashley Yakeley wrote:
At 2002-11-18 11:05, Sven Panne wrote:
global :: a -> IORef a
global a = unsafePerformIO (newIORef a)
This is useful, you can do this with it:
ref = global Nothing
convert :: a ->
I don't know if what I say is pertinent, but there was another problem
that was discussed in the thread about threaded RTS.
One may want to use a finalizer in a particular thread.
For example, a finalizer that put make a rotating cube on screen must be
ran in the same thread as the Opengl/GLUT th
At 2002-11-18 11:05, Sven Panne wrote:
>global :: a -> IORef a
>global a = unsafePerformIO (newIORef a)
This is useful, you can do this with it:
ref = global Nothing
convert :: a -> IO b
convert a = do
writeIORef ref (Just a)
Just b <- readIORef ref
return b
--
Ashley Yakel
On Mon, Nov 18, 2002 at 10:36:05AM -0800, Hal Daume III wrote:
> You can't. CSE (common subexpression elimination) will replace any
> occurances of 'newState 0' in a function body with the same value.
>
> In short: don't use upIO :)
Sorry, cannot resist to pour a little salt onto the wound :)
[
Hal Daume III wrote:
> You can't. [...]
Well, you can, but only for CAFs. This idiom/hack is used
quite happily throughout GHC, HOpenGL, H/Direct, ...
Slightly modified stuff from GHC's sources:
-- global variables in Haskell :-)
-
You can't. CSE (common subexpression elimination) will replace any
occurances of 'newState 0' in a function body with the same value.
In short: don't use upIO :)
If I'm wrong, someone will correct me. But expect a few "what are you
trying to do" email messages or people suggesting implicit pare
I want to write something like
type State a = IORef a
newState :: a -> State a
newState v = unsafePerformIO (newIORef v)
But I don't want the compileer to inline this nor to inline any
application of this.
{#NOINLINE newState#}
But how can I stop this function to be inlined when applied for
> On Mon, Nov 18, 2002 at 11:55:27AM -, Simon Marlow wrote:
> > What exactly are you trying to use -ffunction-sections for?
> I'm pretty
> > sure it won't work as things stand currently, unless you
> can guarantee
> > to be able to find a text/data boundary symbol for the
> garbage collect
On Mon, Nov 18, 2002 at 11:55:27AM -, Simon Marlow wrote:
> What exactly are you trying to use -ffunction-sections for? I'm pretty
> sure it won't work as things stand currently, unless you can guarantee
> to be able to find a text/data boundary symbol for the garbage collector
> (currently it
> If it's not too much work, I'd like to request a "-Werror"
> option for GHC
> that would turn warnings into errors. Sometimes warnings one
> would like to catch get lost in a long make process.
We agree, it's on the TODO list.
Cheers,
Simon
___
> Now fixed in the HEAD, and will be in 5.04.2
>
> Thanks for pointing it out.
>
> Simon
Thanks :)
J.A.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
These bugs are now fixed in the HEAD. I hope the fixes will make it
into 5.04.2 as well.
Thanks for identifying them. It was all horribly bogus before.
Simon
| -Original Message-
| From: Ashley Yakeley [mailto:[EMAIL PROTECTED]]
| Sent: 13 November 2002 13:46
| To: Simon Peyton-Jones
|
Now fixed in the HEAD, and will be in 5.04.2
Thanks for pointing it out.
Simon
| -Original Message-
| From: Jorge Adriano [mailto:[EMAIL PROTECTED]]
| Sent: 14 November 2002 21:10
| To: Iavor S. Diatchki
| Cc: Haskell Cafe; [EMAIL PROTECTED]
| Subject: Bug? [was: Implicit params]
|
| On
> This could be an artifact of the -j64 (BTW, has anyone else
> noticed the
> makefiles can only keep 5 or 6 cpus busy at a time much of the time,
> and often less?).
There are probably still bugs in our build system w.r.t. make -jN. I
occasionally use it to build the compiler, but rarely any ot
> We can't currently allow several Haskell threads to really run
> simultaneosly [e.g. on two separate processors, or preemtively
> scheduled on a single processor], because they always mutate the same
> global heap. Currently, GHC switches its green threads only at times
> when the heap is in
> I'm still unconvinced that the current optional
> RTS support for mixed green/native threads is the right way
> to go. It looks to
> me like a workaround for poor OS support for really
> lightweight threads.
It is a workaround for the lack of truly lightweight threads at the OS
level. But I
> I have a silly question about IORefs and MVars.
>
> When do we have to use MVars if a var is accessed by multiple
> threads.
> In fact, I wonder why IORefs updates aren't safe :
> it seems that preemptive scheduling takes place during memory
> allocation
> and I can't see where there could
| I propose adding something like
|
| forkNativeThread :: IO () -> IO ()
I haven't talked to Simon about this, but it sounds possible. Three
thoughts.
First, before doing anything like this I'd like to ask you or someone
else, or a group, to write a clear exposition of what the problem is and
21 matches
Mail list logo
