Re: Native Threads in the RTS
Hello, I read your proposal. It's great but I have a few remarks : * I think that, if it is not too much complicated, it could be great to put many threads in the OpenGL OS thread. The goal of concurrent Haskell was to allow concurrency for expressivity. It would be a pity to lose this in part of programs for technical reason. Having this possibility would also be a pro this language : Haskell would be the only language to have safe multithreaded OpenGL programming. *Another problem can raise : if one render in two different OpenGL windows, he may want to use different threads for these rendering. However, this is impossible for the moment because it would implies that user threads know when a switch has occurred to a thread rendering in another context and swap OpenGL context. This implies a notion of either : allowing to execute arbitrary code on switch ; either introducing a notion of family of threads. When a switch occurs to a member of a family different of the last member of the family executed , some user defined code should be executed (in that case the code perform a context switch). family and members of family would be defined by user. It seems that family and OS threads are independent : it could either be multiple OS threads for a family or multiple families for an OS threads. I think a thread could be member of multiple families (even if I can't see pertinent example so far). I also think that multiple threads can be the same member of a family (multiple threads drawing in the same window). * A simple way of introducing these new notions (family, members, OS threads) would be to define them as first class value. This would ease the problem of callback : an OpenGL callback would simply be a call to an operator telling the OpenGL thread to execute really the callback. threadsafe could be a short hand for wrapping a callback in a call to the thread currently executing (at time of the call to threadsafe function) and give it to extern function. * To protect OpenGL operations, it would perhaps be useful to introduce a mechanism forbidding to switch between members of a family between a critical section. (I don't know what do a context switch between a glBegin and glEnd). I don't know if my proposal is pertinent but it addresses some problems that would arise. It's quite complicated but i think that there is no overcost for people who don't need using it. Best regards, Nicolas Oury ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: foldl' ?
On Sat, 16 Nov 2002, Hal Daume III wrote: If it appears in Data.List then you need to import Data.List. In order to do this, you will need a newer (=5.03) version of GHC, if I'm not mistaken. I find it curious that I can do: cicero:markc$ ghci -package data ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package lang ... linking ... done. Loading package concurrent ... linking ... done. Loading package posix ... linking ... done. Loading package util ... linking ... done. Loading package data ... linking ... done. Prelude :type FiniteMap.lookupFM forall key elt. (Ord key) = Data.FiniteMap.FiniteMap key elt - key - Maybe elt Prelude :type List.isSuffixOf forall a. (Eq a) = [a] - [a] - Bool Prelude :type List.foldl' interactive:1: Variable not in scope: `List.foldl'' Prelude How come I can get at lookupFM and isSuffixOf but not foldl'? (-: (Thanks to you and Richard for replies!) -- Mark ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: foldl' ?
Because List is the H98 module, Data.List is the extended one which contains foldl'. Regardless of whether you say -package data or not, you're not going to get Data.List unless you ask for it explicitly: moussor:multidoc-sum/ ghci -package data ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package lang ... linking ... done. Loading package concurrent ... linking ... done. Loading package posix ... linking ... done. Loading package util ... linking ... done. Loading package data ... linking ... done. Prelude :t List.foldl' interactive:1: Variable not in scope: `List.foldl'' Prelude :t Data.List.foldl' forall a b. (a - b - a) - a - [b] - a Prelude -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On Fri, 22 Nov 2002, Mark Carroll wrote: On Sat, 16 Nov 2002, Hal Daume III wrote: If it appears in Data.List then you need to import Data.List. In order to do this, you will need a newer (=5.03) version of GHC, if I'm not mistaken. I find it curious that I can do: cicero:markc$ ghci -package data ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package lang ... linking ... done. Loading package concurrent ... linking ... done. Loading package posix ... linking ... done. Loading package util ... linking ... done. Loading package data ... linking ... done. Prelude :type FiniteMap.lookupFM forall key elt. (Ord key) = Data.FiniteMap.FiniteMap key elt - key - Maybe elt Prelude :type List.isSuffixOf forall a. (Eq a) = [a] - [a] - Bool Prelude :type List.foldl' interactive:1: Variable not in scope: `List.foldl'' Prelude How come I can get at lookupFM and isSuffixOf but not foldl'? (-: (Thanks to you and Richard for replies!) -- Mark ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: re-opening a closed stdin?
Simon Marlow [EMAIL PROTECTED] writes: One reason, I think, is lazy I/O(*). It's to stop you accidentally [...] (*) kill it! die! die! So you want main = readFile /dev/zero return () to terminate violantly rather than terminate peacefully? :) Seriously, I understand that the IO monad is the most intuitive and robust when it is strict. But sometimes it is also nice if one could map a file to a lazy string. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
Nicolas Oury a écrit: * I think that, if it is not too much complicated, it could be great to put many threads in the OpenGL OS thread. The goal of concurrent Haskell was to allow concurrency for expressivity. It would be a pity to lose this in part of programs for technical reason. Having this possibility would also be a pro this language : Haskell would be the only language to have safe multithreaded OpenGL programming. You can safely render into two different OpenGL contexts from two different OS threads. I don't think that rendering into the same context from two green threads would work - the OpenGL interface is far too thread-based for this to be useful. *Another problem can raise : if one render in two different OpenGL windows, he may want to use different threads for these rendering. However, this is impossible for the moment because it would implies that user threads know when a switch has occurred to a thread rendering in another context and swap OpenGL context. This implies a notion of either : allowing to execute arbitrary code on switch ; [...] If we want to render into two different OpenGL windows in parallel, we can use two OS threads. OpenGL keeps a reference to its current OpenGL context on a per-OS-thread basis (some old OpenGL implementations might not support this, but I think we can ignore them). [...] some user defined code should be executed (in that case the code perform a context switch) [...] Haskell Code won't work here [after all, we're between two haskell threads...]. C code would be no problem. I actually proposed something like this as a stopgap measure for making OpenGL work with the threaded RTS in summer, but I was convinced by others on this list that this is a hackish solution that relies on internals of the RTS far too much. It seems that family and OS threads are independent : it could either be multiple OS threads for a family or multiple families for an OS threads. I think a thread could be member of multiple families (even if I can't see pertinent example so far). I also think that multiple threads can be the same member of a family (multiple threads drawing in the same window). What would it mean if a thread was a member of more than one thread families? Would it mean that it might execute in several different OS threads? Also, how would these thread groups interact with the existing threaded RTS? Would the existing features still be available without additional effort? Would they be implemented on top of these thread families? I'm not quite convinced that the thread families approach would be worth the additional complexity. What would it be used for? * To protect OpenGL operations, it would perhaps be useful to introduce a mechanism forbidding to switch between members of a family between a critical section. (I don't know what do a context switch between a glBegin and glEnd). We already have MVars, they can be used for things like that. Can anybody else think of reasons why we should need a more complicated design where threads are put into different families or groups, where each thread group executes in exactly one OS thread? This has been proposed at least twice now, but I fail to see the advantages (it looks more flexible, but what's it _for_?). Some disadvantages of a thread groups approach are: *) More complexity. *) Foreign calls will block other threads in the same group. *) It would be even less meaningful for a haskell implementation that always uses OS threads --- the native/green threads proposal could be implemented as a no-op (forkNativeThread = forkIO) without breaking programs that use it. Somebody else please fill in the advantages. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: External library infrastructure
On Tue, Nov 12, 2002 at 05:56:13PM -, Simon Marlow wrote: Absolutely. I didn't mean to sound so GHC-centric. It would be great if the same infrastructure supports multiple compilers/interpreters. Ross Paterson [EMAIL PROTECTED] writes: On the other hand, my impression is that if someone did something that worked with GHC it would be fairly easy to adapt to Hugs, probably with a script that preprocessed a tree of modules. The exception is modules that need extra command-line arguments, particularly FFI modules. For those, Hugs needs a mechanism to set options on a per-file and per-hierarchy basis. I think adding a package like mechanism to Hugs would (or, at least, could): 1) Provide a place to put those extra ffi flags. 2) Make it easier to distribute Hugs packages. Instead of editing your HUGSFLAGS environment variable you run pkg-add (or whatever). 3) By having a single file (the package description file) containing a single copy of all the information needed by any compiler, we might make it easier to maintain libraries such that they 'just work' on all compilers instead of requiring the writer or interested parties to maintain multiple copies of what is, essentially, the same information. Obviously, the 3rd reason is the one of most relevance to this thread. -- Alastair Reid [EMAIL PROTECTED] Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-O doesn't work with gcc-3.2?
ghc fails with this message: Prologue junk?: .globl __stginit_Main __stginit_Main: pushl %ebp movl%esp, %ebp It works without -O. I'm on stock Mandrake 9.0 system. How do I overcome this? tia -- anatoli ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
