Re: [Haskell-cafe] problems installing Takusen-0.6
2007/7/29, Rahul Kapoor [EMAIL PROTECTED]: I am having problems installing Takusen-0.6 (ghc 6.6.1 on FreeBSD) The configure and build works fine. running ./setup install fails with: Installing: /usr/local/lib/Takusen-0.6/ghc-6.6.1 /usr/local/bin Takusen-0.6... setup: Error: Could not find module: Database.Oracle.Enumerator with any suffix: [hi] Hi Rahul, just edit the file takusen.cabal and comment (with --) all the lines that begin with Database.Oracle or Database.PostgreSQL. Salvatore ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] View patterns in GHC: Request?for?feedback
And the readability is destroyed because you cannot do any type inference in
your head.
If you see
{
Matrix m = ;
Matrix x = m * y;
...;
}
Then you know very little about the possible types of y since can only conclude
that:
Matrix can be multiplied by one or more types 'sometype' becuase it has one or
more (operator *(sometype x)) methods defined.
And 'y' is either one of these sometypes's or _any_ other class that matches
_any_ single argument constructor of any of those sometypes (except for those
constructors are marked 'explicit').
Now you need to read the header definitions for Matrix and the headers for every
type that can multiply Matrix. Only after that can you say what set of types
the 'y' might be.
Now do this for every argument of every method call and every operator in the
code.
This is part of the reason that shops that use C++ often have a long list of
features that must never be used. This is part of the reason that new people
who use C++ are notorious because they produce code that uses too many of C++
features. Code written in arbitrary C++ is unreadable.
Aaron Denney wrote:
On 2007-07-27, David Roundy [EMAIL PROTECTED] wrote:
The solution is to add explicit to the constructor for all single-argument
constructors (except perhaps occasionally when you actually want explicit
construction of objects).
The reasoning behind this, of course, is to allow nice interactions of
home-made classes such as complex numbers, or string classes (which you
might want to be automatically constructed from string constants).
I'd have thought that adding an implicit keyword would make more
sense, and only do conversions then. But I forget, C++.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Text.XHtml Documentation
Hello: I was just looking into using Text.XHtml for a project. The Haddock documentation points to an introduction by Andy Gill, but the link is broken. Can anyone point me to the correct location of the introduction? Thanks. Cheers, David ___ (---o---o-o-o---o-o-o( David F. Place mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Using GADTs
{-# OPTIONS -fglasgow-exts #-}
module NNF where
The way I would do this would be to encode as much of the value as I
cared to in the constructors for concepts, rather than just encoding
the top-level constructor.
data Named
data Equal a b
data Negation a
data Top
data Concept t where
CNamed :: String - Concept Named
CEqual :: Concept a - Concept b - Concept (Equal a b)
CNegation:: Concept a - Concept (Negation a)
CTop :: Concept Top
Then, I could form a datatype that does not contain a Concept, but
merely certifies that all Concepts of a certain type are in NNF.
data NNF x where
NNFnamed :: NNF Named
NNFequal :: NNF a - NNF b - NNF (Equal a b)
NNFnegateName :: NNF (Negation Named)
NNFnegateTop :: NNF (Negation Top)
Now I have a generic constructor for some Concept of NNF, value
unknown, that encodes a concept and a proof of its NNF-ness.
data NNFConcept = forall t . NNFConcept (Concept t) (NNF t)
And I take a Concept with some value, transform its value somehow, and
get an NNF concept.
nnf :: Concept t - NNFConcept
nnf (CNamed x) = NNFConcept (CNamed x) NNFnamed
nnf (CEqual x y) =
case (nnf x, nnf y) of
(NNFConcept a a', NNFConcept b b') -
NNFConcept (CEqual a b) (NNFequal a' b')
nnf (CNegation (CEqual x y)) =
case (nnf (CNegation x), nnf (CNegation y)) of
(NNFConcept a a', NNFConcept b b') -
NNFConcept (CEqual a b) (NNFequal a' b')
The above function is not total, even for the limited subset of
Concepts discussed above.
By the way, the code you included last time did not compile. I think
you'll probably get a quicker response than my lazy two-day turnaround
if you make sure to run your posted code through Your Favorite
Compiler first.
Hope this helps,
Jim
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Text.XHtml Documentation
You can often find old webpages at web.archive.org: http://web.archive.org/web/20070406145557/http://www.cse.ogi.edu/~andy/html/intro.htm Searching, with part of the text, revealed that you can also find this page at: http://search.cpan.org/src/AUTRIJUS/Language-Haskell-0.01/hugs98-Nov2003/fptools/hslibs/text/html/doc/doc.htm -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- On Sat, 28 Jul 2007 08:01:35 +0200, Dean Herington [EMAIL PROTECTED] wrote: The Haddock documentation for Text.XHtml (at http://www.haskell.org/ghc/docs/latest/html/libraries/xhtml/Text-XHtml.html) refers to http://www.cse.ogi.edu/~andy/html/intro.htm, but that link is broken. Does anyone know where to find the intended document? On Sun, 29 Jul 2007 17:14:24 +0200, David F. Place [EMAIL PROTECTED] wrote: Hello: I was just looking into using Text.XHtml for a project. The Haddock documentation points to an introduction by Andy Gill, but the link is broken. Can anyone point me to the correct location of the introduction? Thanks. Cheers, David ___ (---o---o-o-o---o-o-o( David F. Place mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Strange behavior of executeFile
Fellow Haskellers, I wrote a small script that intercepts arguments and exec's the pstops program. The intention was to center and scale pages in a document before processing it by psnup. So far so good, I've ended up with something like: runPstops :: [Flag] - IO () runPstops flags = do let args = mkArgs flags when (isVerbose flags) $ do hPutStrLn stderr $ pstops ++ unwords (map show args) executeFile pstops True args Nothing main = do (opts, _) - getOptions = getArgs runPstops opts This works for files, but randomly fails when stdin is connected to a pipe (pstops complains that it can't seek input). I've tested raw pstops with pipes, files and /dev/null and it never fails, so I guess there is something wrong with my code. Can anyone enlighten me in this matter? :) Regards, -- Krzysztof Kościuszkiewicz Skype: dr.vee, Gadu: 111851, Jabber: [EMAIL PROTECTED] Phone IRL: +353851383329, Phone PL: +48783303040 Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange behavior of executeFile
Krzysztof Kościuszkiewicz wrote: This works for files, but randomly fails when stdin is connected to a pipe (pstops complains that it can't seek input). GHC's file handles are backed by non-blocking file descriptors. The child process run by executeFile inherits the stdin, stdout and stderr file descriptors of your Haskell process, so they're unexpectedly (from its perspective) in non-blocking mode. Due to POSIX sharing semantics, you can't simply switch those file descriptors to blocking in the child, because they'll then become blocking in the parent, too. Anything involving sharing file descriptors between processes becomes similarly broken if the GHC runtime starts using a file descriptor as a Handle. You're not the only one to be surprised by this behaviour, but unfortunately it's not trivial to work around. Simon Marlow was going to look into this problem a few months ago, but I don't know if he's had a chance to. b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange behavior of executeFile
On Sun, Jul 29, 2007 at 10:34:10AM -0700, Bryan O'Sullivan wrote: GHC's file handles are backed by non-blocking file descriptors. The child process run by executeFile inherits the stdin, stdout and stderr file descriptors of your Haskell process, so they're unexpectedly (from its perspective) in non-blocking mode. Due to POSIX sharing semantics, you can't simply switch those file descriptors to blocking in the child, because they'll then become blocking in the parent, too. Yes, this would explain the behavior I'm seeing. My script neither forks nor reads stdin, so I could hack around this problem by clearing the O_NONBLOCK flag: setFdOption stdInput NonBlockingRead False Thanks for your help! Regards, -- Krzysztof Kościuszkiewicz Skype: dr.vee, Gadu: 111851, Jabber: [EMAIL PROTECTED] Mobile IRL: +353851383329, Mobile PL: +48783303040 Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Finance.Quote.Yahoo 0.1 on hackage
This is totally off-topic, but... how could I go about getting hold of the information on per-country exports and imports of specific types of things? (lets say for example, a thing could be: coffee ,but also a computer program, so not just physical commodities, but also services and somewhat intangible services). Ideally I'd like to feed in decades of data into a a support vector machine and see what comes out (probably out of memory :-D ). I've never done anything like this before, and have no idea what to do, but in the tradition of jump in and see what happens figure it's as good a way to start as any. (Or, in other news, I like Haskell, it's fun, and I'm looking for something to use it for, and apparently financial analysis is a big market for it). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange behavior of executeFile
On Sun, Jul 29, 2007 at 10:34:10AM -0700, Bryan O'Sullivan wrote: Simon Marlow was going to look into this problem a few months ago, but I don't know if he's had a chance to. It's fixed in the HEAD: http://hackage.haskell.org/trac/ghc/ticket/724 Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Using GADTs
On Sunday 29 July 2007, Jim Apple wrote: The way I would do this would be to encode as much of the value as I cared to in the constructors for concepts, rather than just encoding the top-level constructor. data Named data Equal a b data Negation a data Top data Concept t where CNamed :: String - Concept Named CEqual :: Concept a - Concept b - Concept (Equal a b) CNegation:: Concept a - Concept (Negation a) CTop :: Concept Top Ah, great. That was the first trick I'd missed. Then, I could form a datatype that does not contain a Concept, but merely certifies that all Concepts of a certain type are in NNF. This turns out not to be needed if you describe what nnf is in terms of those parameterised datatypes above. You can re-use the same datatype! I had to move the nnf function into a class to get it to compile, which makes the code more verbose, but appart from that I'm quite pleased with the result. By the way, the code you included last time did not compile. I think you'll probably get a quicker response than my lazy two-day turnaround if you make sure to run your posted code through Your Favorite Compiler first. Yeah, sorry about that. It was a late-at-night thing. I've pasted in my (compiling and working) code below, for anyone that's interested. I think I like GADTs quite a lot :) Pitty I can't get deriving clauses to work with them... Thanks Matthew data Named data Equal a b data Conjunction a b data Disjunction a b data Negation a data Existential a data Universal a data Top data Bottom data Concept t where CNamed :: String - Concept Named CEqual :: Concept a - Concept b - Concept (Equal a b) CConjunction :: Concept a - Concept b - Concept (Conjunction a b) CDisjunction :: Concept a - Concept b - Concept (Disjunction a b) CNegation:: Concept a - Concept (Negation a) CExistential :: Role Named - Concept a - Concept (Existential a) CUniversal :: Role Named - Concept a - Concept (Universal a) CTop :: Concept Top CBottom :: Concept Bottom data Role t where RNamed :: String - Role Named class InNNF nnf instance InNNF Named instance InNNF Top instance InNNF Bottom instance InNNF (Negation Named) instance InNNF (Negation Top) instance InNNF (Negation Bottom) instance (InNNF a, InNNF b) = InNNF (Equal a b) instance (InNNF a, InNNF b) = InNNF (Conjunction a b) instance (InNNF a, InNNF b) = InNNF (Disjunction a b) instance (InNNF a) = InNNF (Existential a) instance (InNNF a) = InNNF (Universal a) class ( InNNF u ) = ToNNF t u | t - u where nnf :: Concept t - Concept u instance ToNNF Named Named where nnf = id instance (ToNNF a c, ToNNF b d) = ToNNF (Equal a b) (Equal c d) where nnf (CEqual lhs rhs) = CEqual (nnf lhs) (nnf rhs) instance (ToNNF a c, ToNNF b d) = ToNNF (Conjunction a b) (Conjunction c d) where nnf (CConjunction lhs rhs) = CConjunction (nnf lhs) (nnf rhs) instance (ToNNF a c, ToNNF b d) = ToNNF (Disjunction a b) (Disjunction c d) where nnf (CDisjunction lhs rhs) = CDisjunction (nnf lhs) (nnf rhs) instance (ToNNF a b) = ToNNF (Existential a) (Existential b) where nnf (CExistential r c) = CExistential r (nnf c) instance (ToNNF a b) = ToNNF (Universal a) (Universal b) where nnf (CUniversal r c) = CUniversal r (nnf c) instance ToNNF (Negation Named) (Negation Named) where nnf = id instance (ToNNF (Negation a) c, ToNNF (Negation b) d) = ToNNF (Negation (Equal a b)) (Equal c d) where nnf (CNegation (CEqual lhs rhs)) = CEqual (nnf $ CNegation lhs) (nnf $ CNegation rhs) instance (ToNNF (Negation a) c, ToNNF (Negation b) d) = ToNNF (Negation (Conjunction a b)) (Disjunction c d) where nnf (CNegation (CConjunction lhs rhs)) = CDisjunction (nnf $ CNegation lhs) (nnf $ CNegation rhs) instance (ToNNF (Negation a) c, ToNNF (Negation b) d) = ToNNF (Negation (Disjunction a b)) (Conjunction c d) where nnf (CNegation (CDisjunction lhs rhs)) = CConjunction (nnf $ CNegation lhs) (nnf $ CNegation rhs) instance (ToNNF a b) = ToNNF (Negation (Negation a)) b where nnf (CNegation (CNegation c)) = nnf c instance(ToNNF (Negation a) b) = ToNNF (Negation (Existential a)) (Universal b) where nnf (CNegation (CExistential r c)) = CUniversal r (nnf $ CNegation c) instance (ToNNF (Negation a) b) = ToNNF (Negation (Universal a)) (Existential b) where nnf (CNegation (CUniversal r c)) = CExistential r (nnf $ CNegation c) instance ToNNF (Negation Top) (Negation Top) where nnf (CNegation CTop) = CNegation CTop instance ToNNF (Negation Bottom) (Negation Bottom) where nnf (CNegation CBottom) = CNegation CBottom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Questions about threads
Hi everyone, I have been confused by some things about threads for a long time. I'm hoping someone out there can help clear this up. I'll clean up and document on the wiki if we get conclusive answers. So it seems there are four scenarios for firing off threads: A) Threaded RTS, forkIO B) Threaded RTS, forkOS C) Non-threaded RTS, forkIO D) Non-threaded RTS, forkOS So the questions, for each of the four models, are: 1) What is the impact of firing off a thread to execute a pure (non-IO) computation under each model? Will multiple pure computations be allowed to run in parallel, or will only one run at a time? (While the computation may be outside the IO monad, of course at the end it will have to use IO to communicate the result back.) 2) What is the impact of IO under each model? Will GHC internally use select/poll/whatever? Or will each thread get a dedicated OS thread that uses synchronous I/O? 3) When signals are received, which thread receives them? 4) When forkProcess is executed, which thread(s) are duplicated to the forked process? 5) What does an FFI import safe mean under each model? 6) What does an FFI import unsafe mean under each model? 7) What is the expected future level of support for each model? This is of significant concern to me, as it appears that the threaded RTS is only supported on an extremely limited set of architectures (most programs won't even link on Debian's autobuilders if I use -threaded). Also I have heard comments that the non-threaded RTS may be dropped in the future. 8) What is the expected level of support for STM in combination with each threaded model? 9) How does par mix with each threaded model? Is it equivolent to forkOS or forkIO? Thanks, -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: HDBC or HSQL
On 2007-07-25, George Moschovitis [EMAIL PROTECTED] wrote: I am a Haskell newbie and I would like to hear your suggestions regarding a Database conectivity library: HSQL or HDBC ? which one is better / more actively supported? I am the author of HDBC, so take this for what you will. There were several things that bugged me about HSQL, if memory serves: 1) It segfaulted periodically, at least with PostgreSQL 2) It had memory leaks 3) It couldn't read the result set incrementally. That means that if you have a 2GB result set, you better have 8GB of RAM to hold it. 4) It couldn't reference colums in the result set by position, only by name 5) It didn't support pre-compiled queries (replacable parameters) 6) Its transaction handling didn't permit enough flexibility I initially looked at fixing HSQL, but decided it would be easier to actually write my own interface from scratch. HDBC is patterned loosely after Perl's DBI, with a few thoughts from Java's JDBC, Python's DB-API, and HSQL mixed in. I believe it has fixed all of the above issues. The HDBC backends that I've written (Sqlite3, PostgreSQL, and ODBC) all use Haskell's C memory management tools, which *should* ensure that there is no memory leakage. I use it for production purposes in various applications at work, connecting to both Free and proprietary databases. I also use it in my personal projects. hpodder, for instance, stores podcast information in a Sqlite3 database accessed via HDBC. I have found HDBC+Sqlite3 to be a particularly potent combination for a number of smaller projects. http://software.complete.org/hdbc/wiki/HdbcUsers has a list of some programs that are known to use HDBC. Feel free to add yours to it. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HDBC Laziness (was Re: HDBC or HSQL)
On 2007-07-26, jeff p [EMAIL PROTECTED] wrote: to lazily retrieve query results. While this can be very convenient, it can also easily lead to very frustrating errors and/or resource leaks (just like any lazy IO operation); I eventually had to remove all trace of this function from my code base. I have heard from a number of people that this behavior is not very newbie-friendly. I can see how that is true. I have an API revision coming anyway, so perhaps this is the time to referse the default laziness of HDBC calls (there would be a '-version of everything with laziness enabled, still). Thoughts? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: HDBC or HSQL
On 2007-07-25, david48 [EMAIL PROTECTED] wrote: On 7/25/07, George Moschovitis [EMAIL PROTECTED] wrote: I am a Haskell newbie and I would like to hear your suggestions regarding a Database conectivity library: HSQL or HDBC ? which one is better / more actively supported? HDBC Supports Mysql only through ODBC :( This is true, unless some MySQL hacker would like to contribute a native module. I don't use MySQL myself and haven't had the time to write an interface to it. That said, HDBC supports unixODBC quite nicely... ;-) -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Questions about threads
On Sun, Jul 29, 2007 at 05:35:26PM -0500, John Goerzen wrote: Hi everyone, I have been confused by some things about threads for a long time. I'm hoping someone out there can help clear this up. I'll clean up and document on the wiki if we get conclusive answers. So it seems there are four scenarios for firing off threads: A) Threaded RTS, forkIO B) Threaded RTS, forkOS C) Non-threaded RTS, forkIO D) Non-threaded RTS, forkOS So the questions, for each of the four models, are: 1) What is the impact of firing off a thread to execute a pure (non-IO) computation under each model? Will multiple pure computations be allowed to run in parallel, or will only one run at a time? (While the computation may be outside the IO monad, of course at the end it will have to use IO to communicate the result back.) A) B) Parallel C) D) Sequential 2) What is the impact of IO under each model? Will GHC internally use select/poll/whatever? Or will each thread get a dedicated OS thread that uses synchronous I/O? GHC uses select/poll/whatever under all four models. 3) When signals are received, which thread receives them? GHC never sends signals to threads. Signals are handled by creating a brand new thread to run your handler. 4) When forkProcess is executed, which thread(s) are duplicated to the forked process? A) B) errorBelch(forking not supported with +RTS -Nn greater than 1); stg_exit(EXIT_FAILURE) C) D) Only the current thread (note, this means that the thread which serves Handle IO won't exist and said functions will lock) 5) What does an FFI import safe mean under each model? A) C) A new OS-level thread is forked from a pool and the code is executed in it. B) D) A dedicated OS-level thread is forked *at forkOS time*, and used for all safe foreign calles in the thread. This is of course much more expensive, but makes TLS-using libraries like OpenGL work. 6) What does an FFI import unsafe mean under each model? A) B) C) D) The code is executed inline (after saving caller-saves registers, of course) 7) What is the expected future level of support for each model? This is of significant concern to me, as it appears that the threaded RTS is only supported on an extremely limited set of architectures (most programs won't even link on Debian's autobuilders if I use -threaded). Also I have heard comments that the non-threaded RTS may be dropped in the future. A) B) High. C) D) Unknown. It depends on whether the threaded RTS can be made to interact in a remotely sane way with low level Unix programming (cf HSH). 8) What is the expected level of support for STM in combination with each threaded model? A) B) Good. Atomic instructions are used, along with a traditionally greedy-transactions model. C) D) Very good. No atomic instructions are needed, since the system simply refrains from preeemting during individual primops, including the commit. 9) How does par mix with each threaded model? Is it equivolent to forkOS or forkIO? A) B) Neither, it's a very low level operation which adds the node to a pool of things which should be executed. The spark pool is read from when the runqueue is empty, and will not grow without bound since it's circular (old sparks are discarded) C) D) newSpark is a noop Thanks, John Notice that A/B and C/D are virtually equivalent. forkOS has *no effect* on anything but safe foreign calls. Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Questions about threads
On Sun, 2007-07-29 at 17:35 -0500, John Goerzen wrote: Hi everyone, I have been confused by some things about threads for a long time. I'm hoping someone out there can help clear this up. I'll clean up and document on the wiki if we get conclusive answers. So it seems there are four scenarios for firing off threads: A) Threaded RTS, forkIO B) Threaded RTS, forkOS C) Non-threaded RTS, forkIO D) Non-threaded RTS, forkOS If I recall correctly, D throws a runtime error because the guarantees that forkOS is supposed to provide are impossible without the threaded rts. (I think) You generally do not want forkOS. It's really only for wierd foreign libs that require that they be called from the same OS thread every time eg because they keep thread local state (like OpenGL). Using forkOS will get you no extra parallelism. You get parallelism linking with the threaded rts and running your program using multiple capabilities. http://haskell.org/ghc/docs/latest/html/users_guide/sec-using-smp.html So the questions, for each of the four models, are: 1) What is the impact of firing off a thread to execute a pure (non-IO) computation under each model? Will multiple pure computations be allowed to run in parallel, or will only one run at a time? (While the computation may be outside the IO monad, of course at the end it will have to use IO to communicate the result back.) You only get parallelism (as opposed to concurrency) of pure code when using the threaded rts, and then only when running the program using more than one capability (+RTS -N2 -RTS). 2) What is the impact of IO under each model? Will GHC internally use select/poll/whatever? Or will each thread get a dedicated OS thread that uses synchronous I/O? In both ghc only uses on OS thread for IO. In the threaded rts it's an *additional* OS thread but it's still only one. In the single threaded rts, it's the rts that does the select/poll. In the threaded rts it's a Haskell IO manager thread that uses select/poll on behalf of other Haskell threads that need to block until the completion of I/O. 3) When signals are received, which thread receives them? Each signal gets handled by a new unbound Haskell thread. 4) When forkProcess is executed, which thread(s) are duplicated to the forked process? Only the calling one. All other Haskell threads disappear. 5) What does an FFI import safe mean under each model? single-threaded: all Haskell threads block until the foreign call returns. multi-threaded: other Haskell threads continue in parallel. 6) What does an FFI import unsafe mean under each model? single-threaded: all Haskell threads block until the foreign call returns. multi-threaded: other Haskell threads in the same 'capability' block until the foreign call returns. If the program is using more than one capability then Haskell threads in the other capabilities should continue to run. In both cases, unsafe should only be used for short-running, non-blocking foreign calls that do not make callbacks into Haskell. 7) What is the expected future level of support for each model? This is of significant concern to me, as it appears that the threaded RTS is only supported on an extremely limited set of architectures (most programs won't even link on Debian's autobuilders if I use -threaded). Also I have heard comments that the non-threaded RTS may be dropped in the future. The non-threaded rts is not going to get many improvements though it probably will not be dropped while the threaded rts doesn't work on those other arches. The threaded rts will probably become the default in some upcoming release. 8) What is the expected level of support for STM in combination with each threaded model? No idea, but bear in mind the threaded rts is where the attention is going. 9) How does par mix with each threaded model? Is it equivolent to forkOS or forkIO? forkIO. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HDBC Laziness (was Re: HDBC or HSQL)
Hello, I have heard from a number of people that this behavior is not very newbie-friendly. I can see how that is true. I have an API revision coming anyway, so perhaps this is the time to referse the default laziness of HDBC calls (there would be a '-version of everything with laziness enabled, still). Thoughts? I think this is a good idea. In general, I think effort should be made to remind people that lazy IO operations break Haskell's type abstractions and can thus lead to unexpected/dangerous behavior. -Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HDBC Laziness (was Re: HDBC or HSQL)
mutjida: Hello, I have heard from a number of people that this behavior is not very newbie-friendly. I can see how that is true. I have an API revision coming anyway, so perhaps this is the time to referse the default laziness of HDBC calls (there would be a '-version of everything with laziness enabled, still). Thoughts? I think this is a good idea. In general, I think effort should be made to remind people that lazy IO operations break Haskell's type abstractions and can thus lead to unexpected/dangerous behavior. More generally, I think it should be at least obvious how to get hold of a System.IO.Strict. We should provide that option (perhaps as part of the 'strict' package on hackage.haskell.org). -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
