Re: re-opening a closed stdin?
Simon Marlow writes: > I've been thinking about duplicating/replacing Handles for a while. > Here's a possible interface: > > -- |Returns a duplicate of the original handle, with its own buffer > -- and file pointer. The original handle's buffer is flushed, > including > -- discarding any input data, before the handle is duplicated. > hDuplicate :: Handle -> IO Handle > -- |Makes the second handle a duplicate of the first handle. The > -- second handle will be closed first, if it is not already. > hDuplicateTo :: Handle -> Handle -> IO () I'm not too sure of the issues here. Some examples that use them would be helpful. The only suggestion I'd make is that the names be something with handle in them: huDupHandle, hDupHandleTo > The remaining questions are: > - Should you be allowed to duplicate a Handle which refers >to a file opened in WriteMode? Haskell 98 forbids having >two Handles pointing to the same file opened for writing, >but IMHO it's quite a reasonable thing to do. If we don't allow >this, then there needs to be another version of hDuplicateTo >which invalidates the original Handle. Why does Haskell 98 make this restriction (I don't think that the library report says why)? Thanks, Bernie. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: re-opening a closed stdin?
> You can call 'System.Posix.IO.dup stdin' and save this value. > However, I think you then need to explicitely read from this fd as > it is not possible to reset what GHC thinks stdin is currently to > this new fd (I'll dig into this and maybe we'll get a >setStdin :: Fd -> IO () > from this, IIRC somebody else was asking for this, too). How does this interact with Simon's proposal for hDuplicate? Thanks for your help, Bernie. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Request: suppress specific warnings at specific places
GHC's excellent warnings are very helpful. They would be somewhat
more so if it were possible to suppress a warning about a specific bit
of code. One possible syntax (to which I gave no commitment) would be
{-# WOFF "non-exhaustive pattern matches" #-}
{-# WON "non-exhaustive pattern matches" #-}
. Another would be
{-# WOFF 523 #-}
{-# WON 523 #-}
where 523 is a warning number emitted with the warning message.
This would be particularly useful with the recently granted wish for
-Werror.
mike
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: adding new primitives to ghci...
> I am trying to add a new primitive to ghc (5.04.1) ... > I followed > the instructions in primops.txt.pp: > > --- or, for an out-of-line primop: > -- ghc/includes/PrimOps.h (just add the declaration) > -- ghc/rts/PrimOps.hc (define it here) > -- ghc/rts/Linker.c (declare the symbol for GHCi) > -- > > My new primitive works fine when I compile the programs that > use it but when I try to load ghci I get: > > lxdsg[137](2.05)> ./ghc-inplace --interactive >___ ___ _ > / _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version 5.04.1, > for Haskell > 98. > / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \/\/ /_/\/|_| Type :? for help. > > Loading package base ... linking ... > /data/dubois/ghc-5.04.1/libraries/base/HSbase.o: unknown symbol > `packcczh_fast' > ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1): > can't load package `base' > > Please report it as a compiler bug to > [EMAIL PROTECTED], > or http://sourceforge.net/projects/ghc/. You need to bootstrap GHCi with the compiler that contains the new primitive. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: re-opening a closed stdin?
> There's probably a really obvious answer to this, but I can't find it. > > Is there any way in GHC to reopen stdin if it has been closed? There's no way to do this at present, except in GHCi where you can revert CAFs to their unevaluated state. > You may wonder why I'd want this. Well I'm writing a debugger > for Haskell 98 (*) and my debugger wants to do some > interaction on the terminal > _after_ the user's program has run. If the user's program > puts stdin into > a closed or semi-closed state then that causes trouble for my > debugger. > > What I'd like to do is close stdin after the end of the > user's program, > flush any input waiting in the buffer, then reopen it fresh > for reading. > > If this can't be easily done perhaps there is another > solution you can think of. I've been thinking about duplicating/replacing Handles for a while. Here's a possible interface: -- |Returns a duplicate of the original handle, with its own buffer -- and file pointer. The original handle's buffer is flushed, including -- discarding any input data, before the handle is duplicated. hDuplicate :: Handle -> IO Handle -- |Makes the second handle a duplicate of the first handle. The -- second handle will be closed first, if it is not already. hDuplicateTo :: Handle -> Handle -> IO () These are fairly straightforward to implement in GHC (I've got a working prototype), and given these primitives you can implement the other interfaces that have been talked about in the past (withStdin/withStdout/withStderr, for example). The remaining questions are: - Should you be allowed to duplicate a Handle which refers to a file opened in WriteMode? Haskell 98 forbids having two Handles pointing to the same file opened for writing, but IMHO it's quite a reasonable thing to do. If we don't allow this, then there needs to be another version of hDuplicateTo which invalidates the original Handle. - Should these be exported by System.IO? Are there any fundamental problems which would make these hard or impossible to implement in Hugs or NHC? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: re-opening a closed stdin?
In local.glasgow-haskell-users, you wrote: > Is there any way in GHC to reopen stdin if it has been closed? You can call 'System.Posix.IO.dup stdin' and save this value. However, I think you then need to explicitely read from this fd as it is not possible to reset what GHC thinks stdin is currently to this new fd (I'll dig into this and maybe we'll get a setStdin :: Fd -> IO () from this, IIRC somebody else was asking for this, too). The other way involves opening /dev/stdin on hosts that support this (with the same limitation as above), including that that's currently not possible! base/GHC/Handle.hs needs a little bit of convincing (which I'm currently doing) for this to work. Volker -- 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
adding new primitives to ghci...
Hello! I am trying to add a new primitive to ghc (5.04.1) ... I followed the instructions in primops.txt.pp: -- - or, for an out-of-line primop: -- ghc/includes/PrimOps.h (just add the declaration) -- ghc/rts/PrimOps.hc (define it here) -- ghc/rts/Linker.c (declare the symbol for GHCi) -- My new primitive works fine when I compile the programs that use it but when I try to load ghci I get: lxdsg[137](2.05)> ./ghc-inplace --interactive ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... /data/dubois/ghc-5.04.1/libraries/base/HSbase.o: unknown symbol `packcczh_fast' ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1): can't load package `base' Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. So, is there any other file that I have to change to have my new primitive working with ghci? Cheers, Andre. -- - André Rauber Du Bois dubois at macs.hw.ac.uk http://www.macs.hw.ac.uk/~dubois/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
Great, thanks. I hope you'll keep it up to date so that by the time the discussion converges it can serve as a specification and rationale. We can put it in CVS too... Simon will think of where! Until then, I'll play the role of a "human CVS server". Ultimately it'd be worth integrating with http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/rts-libs/multi- thread. html Of course. Some parts should be part of the user documentation, while others should probably be considered implentation details. | A foreign exported | callback that is called from C code executing in that OS thread is | executed in the native haskell thread. This is the bit I don't understand. Is the only scenario you have in mind here native Haskell thread calls C which calls Haskell and you want all that in the same native thread? Yes, exactly. What about this? native Haskell thread calls C which installs a pointer to a foreign-exported Haskell function in some C data structure Later... some other Haskell thread calls C which waits for an event which calls the callback So the callback was installed by a native thread, but won't be executed by it. Is that ok? Definitely. It's the same way it works in C. What thread some code executes in depends on what thread the code is called from. Anyway I think it would be worth explaining what is guaranteed a bit more clearly. I'm not sure how... to me it looks like I already specified this exactly ;-). Anyway, I've added some examples to the proposal to clarify what I mean. | If a "green" haskell thread enters a foreign imported function marked | as "safe", all other green threads are blocked. Native haskell threads | continue to run in their own OS threads. No, I don't think so. The reason that 'safe' is cheaper than 'threadsafe' is that the current worker OS thread does not need to release the Big Lock it holds on the Haskell heap, thereby allowing other green threads to run. Instead, it holds the lock, executes the call, and returns. At least I think this is the idea, but it's all jolly slippery. I thought that was "unsafe"? The "safe" version still does quite a lot (after all, a callbacks are allowed, so is GC). In addition, "threadsafe" may start a new OS thread in order to keep executing green threads. On the other hand, we might simply leave it unspecified: If people want to know what happens to other threads, they should use "threadsafe" or "unsafe". The exact behaviour of "safe" seems to be an implementation detail. | Other things I'm not sure about: Presumably if a native thread spawns a thread using forkIO, it gets just a green thread? If it used forkNativeThread it gets a distinct native thread. Better say this. "The main program and all haskell threads forked using forkIO are green threads. Threads forked using forkNativeThread :: IO () -> IO () are native threads." I thought that was clear enough... I've added a note. Cheers, Wolfgang * Native Threads Proposal, version 2 Some "foreign" libraries (for example OpenGL) rely on a mechanism called thread-local storage. The meaning of an OpenGL call therefore usually depends on which OS thread it is called from. Therefore, some kind of direct mapping from Haskell threads to OS threads is necessary in order to use the affected foreign libraries. Executing every haskell thread in its own OS thread is not feasible for performance reasons. However, perfomance of native OS threads is not too bad as long as there aren't too many, so I propose that some threads get their own OS threads, and some don't: Every Haskell Thread can be either a "green" thread or a "native" thread. For each "native" thread, there is exactly one OS thread created by the RTS. For a green thread, it is unspecified which OS thread it is executed in. The main program and all haskell threads forked using forkIO are green threads. Threads forked using forkNativeThread :: IO () -> IO () are native threads. (Note: The type of the current haskell thread does _not_ matter when forking new threads) Execution of a green thread might move from one OS thread to another at any time. A "green" thread is never executed in an OS thread that is reserved for a "native" thread. A "native" haskell thread and all foreign imported functions that it calls are executed in its associated OS thread. A foreign exported callback that is called from C code executing in that OS thread is executed in the native haskell thread. A foreign exported callback that is called from C code executing in an OS thread that is not associated with a "native" haskell thread is executed in a new green haskell thread. Only one OS thread can execute Haskell code at any given time. If a "native" haskell thread enters a foreign imported function that is marked as "safe" or "threadsafe", all other Haskell threads keep running. If the imported function is marked as "unsafe", no other
RE: -Werror Request
Done! SImon | -Original Message- | From: Ashley Yakeley [mailto:[EMAIL PROTECTED]] | Sent: 14 November 2002 02:25 | To: GHC List | Subject: -Werror Request | | 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. | | Thanks... | | -- | Ashley Yakeley, Seattle WA | | ___ | 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: Native Threads in the RTS
| I've now written up a slightly more formal proposal for native threads. | (OK, it's only a tiny bit more formal...) | I doubt I have explained everything clearly, please tell me which | points are unclear. And of course please tell me what you like/don't | like about it. Great, thanks. I hope you'll keep it up to date so that by the time the discussion converges it can serve as a specification and rationale. We can put it in CVS too... Simon will think of where! Ultimately it'd be worth integrating with http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/rts-libs/multi-thread. html Simon | A "native" haskell thread and all foreign imported functions that it | calls are executed in its associated OS thread. This part is ok | A foreign exported | callback that is called from C code executing in that OS thread is | executed in the native haskell thread. This is the bit I don't understand. Is the only scenario you have in mind here native Haskell thread calls C which calls Haskell and you want all that in the same native thread? What about this? native Haskell thread calls C which installs a pointer to a foreign-exported Haskell function in some C data structure Later... some other Haskell thread calls C which waits for an event which calls the callback So the callback was installed by a native thread, but won't be executed by it. Is that ok? Anyway I think it would be worth explaining what is guaranteed a bit more clearly. | If a "green" haskell thread enters a foreign imported function marked | as "safe", all other green threads are blocked. Native haskell threads | continue to run in their own OS threads. No, I don't think so. The reason that 'safe' is cheaper than 'threadsafe' is that the current worker OS thread does not need to release the Big Lock it holds on the Haskell heap, thereby allowing other green threads to run. Instead, it holds the lock, executes the call, and returns. At least I think this is the idea, but it's all jolly slippery. | Other things I'm not sure about: Presumably if a native thread spawns a thread using forkIO, it gets just a green thread? If it used forkNativeThread it gets a distinct native thread. Better say this. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
