RE: Bug? [was: Implicit params]
| > this seems like a bug in GHC. Hugs is happy with it. The "s" in the | > pure2 signature is not ambiguous because it is determined when you give | > the value of the implicit parameter. in fact the way i think about | > implicit parameters is simply as a nice notation for computations in the | > environment monad, so in my mind the above two definitions are pretty | > much the same. | | Thanks Iavor! | GHC people, can you confirm this, Is it a bug? I'm using Ghc 5.0.4 SuSE rpms. | Is there a workaround? Interesting. I hadn't thought of that. Yes, I think you can consider it a bug, or at least the lack of a feature. I'll fix it next week S ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Native Threads in the RTS
Hello All, A while ago there was a discussion on the shortcomings of the threaded RTS (in short, it doesn't work with foreign APIs that use thread-local state, and that breaks HOpenGL). Back then, it was decided to just keep the threaded RTS off by default and to do something about it some time after 5.04. I believe it's time to think about it again, so I'll take the liberty of proposing an extension to the RTS that might solve the problem. I propose adding something like forkNativeThread :: IO () -> IO () which forks a new Haskell thread that has its own OS thread to execute in. Note that the fact that only one Haskell thread may execute at a time remains unchanged. Whenever the scheduler determines that a "native" haskell thread is next, it sends the OS worker thread to sleep and wakes up the OS thread corresponding to the "native" haskell thread. When the "native" haskell thread yields again, so does the corresponding OS thread. Foreign calls from "normal" (non-native) haskell threads should be handled in exactly the same way as they are currently. If a callback is entered and the current OS thread corresponds to a native haskell thread, the callback should be executed in the current OS thread. Other haskell threads continue to run in the worker thread or in their own dedicated OS thread. Programs that don't use forkNativeThread won't be affected by the change. Thread switching to and from native threads will be slower, but not painfully slow. Wrapping an entire HOpenGL program in forkNativeThread should solve the OpenGL/GLUT thread-local-state problem, for example, and who knows what else it is good for. Any comments? Opinions? Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Help: Windows ghc profiler errors
> I want to profile my Haskell program (it solves the Queens and Knights > problem stated here: > http://www.itasoftware.com/careers/programmers.php ). > I'm compiling with GHC 5.04.1 under Windows NT using the > following command > line (as per the Users Guide): > > >ghc -prof -auto-all -o queens --make Main > > > When I run the program with the following command lines I get: > > >queens > queens: fatal error: evacuate: strange closure type 1696 Profiling is broken on Windows in 5.04.1. I think we know what the problem is, and it will be working again in 5.04.2. Sorry about that. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: bug in unix/System/Posix/Files.hsc
> In local.glasgow-haskell-users, you wrote: > > readSymbolicLink is broken, it assumes that readlink(2) > null terminates its > > result when it doesn't. this causes all sorts of badness. > > This should fix it, although all my CVS trees are hosed right now > (now how did I manage to break something in the backup tree?) and I > can't actually test it: Thanks, I'll check it in. As you probably guessed, this stuff hasn't had any testing yet. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bug in unix/System/Posix/Files.hsc
In local.glasgow-haskell-users, you wrote: > readSymbolicLink is broken, it assumes that readlink(2) null terminates its > result when it doesn't. this causes all sorts of badness. This should fix it, although all my CVS trees are hosed right now (now how did I manage to break something in the backup tree?) and I can't actually test it: Index: Files.hsc === RCS file: /home/cvs/root/fptools/libraries/unix/System/Posix/Files.hsc,v retrieving revision 1.3 diff -u -r1.3 Files.hsc --- Files.hsc 2002/10/08 08:03:02 1.3 +++ Files.hsc 2002/11/15 09:02:03 @@ -352,10 +352,10 @@ readSymbolicLink :: FilePath -> IO FilePath readSymbolicLink file = allocaArray0 (#const PATH_MAX) $ \buf -> do -withCString file $ \s -> - throwErrnoIfMinus1_ "readSymbolicLink" $ +withCString file $ \s -> do + len <- throwErrnoIfMinus1 "readSymbolicLink" $ c_readlink s buf (#const PATH_MAX) -peekCString buf + peekCStringLen (buf,fromIntegral len) foreign import ccall unsafe "readlink" c_readlink :: CString -> CString -> CInt -> IO CInt -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
