filterSet
Dear GHC team, As there exists, say,Data.mapSet, is this natural to provide also filterSet ? - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Bug in touchForeignPtr?
On 20 November 2004 23:02, Benjamin Franksen wrote: I am using Foreign.Concurrent.newForeignPtr and touchForeignPtr inside the finalizers to express liveness dependencies as hinted to by the documentation. This doesn't seem to work, though, or at least I can't see what I've done wrong. I attached a test module; compiled with ghc -fglasgow-exts --make TestForeignTouchBug.hs, ghc version 6.2.2, this gives .../foreigntouchbug ./a.out hit enter here before finalizing A after finalizing A before finalizing B after finalizing B hit enter here I expected the order of the finalizer calls be be the other way around, since the finalizer for the Bs explicitly touches the A value. The problem is that the runtime is running all outstanding finalizers at the end of execution, without regard for GC dependencies like the ones introduced by touchForeignPtr. I've been planning to remove this automatic running of finalizers for other reasons. However, then you will get absolutely no guarantee that your finalizer will ever run at all (indeed, the property isn't always true right now, but it is usually true). Let me share with you something that I've come to appreciate over the last few years: Finalizers are almost always not the right thing. Finalizers look terribly attractive, but often lead to a huge can of worms - best avoided if at all possible. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
Some thoughts on this, Whilst I agree that finalizers are best avoided, it must be possible to order the finalizers for running on exit... Perhaps a simple multi-pass algorith would do? (ie: run all finalizers that do not refer to other objects with finalizers - repeat until no objects with finalizers remain. What can be done about loops I am not sure (where A refers to B which refers to A and both have finalizers)... The alternative would seem to be writing your finilizers such that they first call the finalizers on any refered objects which haven't been finalized yet (In the case of loops if we specify running the finalizers on any objects refered to on which the finalizer has not been entered yet - it should work too) Whatever happens I think it must make sure all system resources allocated by a program are freed on exit - otherwise the machine will have a resource leak and will need rebooting eventually. Keean. Simon Marlow wrote: The problem is that the runtime is running all outstanding finalizers at the end of execution, without regard for GC dependencies like the ones introduced by touchForeignPtr. I've been planning to remove this automatic running of finalizers for other reasons. However, then you will get absolutely no guarantee that your finalizer will ever run at all (indeed, the property isn't always true right now, but it is usually true). Let me share with you something that I've come to appreciate over the last few years: Finalizers are almost always not the right thing. Finalizers look terribly attractive, but often lead to a huge can of worms - best avoided if at all possible. Cheers, Simon ___ 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: unlit/ghci does not work on DOS file
On 18 November 2004 20:31, Christian Maeder wrote: calling unlit on a DOS file fails, whereas hugs is able to process the same file (under unix). Christian Prelude readFile Test.lhs = putStrLn . show \r\n module Test where\r\n\r\n Prelude :l Test.lhs Test.lhs line 2: unlit: Program line next to comment phase `Literate pre-processor' failed (exitcode = 1) Thanks, fixed. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
User-defined operators and compound expressions using Happy
Hi there folks, once again, I've got a question related to Happy (I've got version 1.13 at the moment). Maybe, it's even more a question on formal languages, but well... How can I write a grammar that can cope with user-defined operators (of different precedences/associativities) and compound expression like function calls, if-then-else- and case-statements and the like. I tried to write it down straight forwardly, but failed terribly (alas, I didn't keep it, so I can't show you - if someone of you is versed in this issue, I can try to explain the language's constructs). Thank you so much, Frank-Andre Riess ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: proposal for ghc-pkg to use a directory of .conf files
On 21 November 2004 00:56, Isaac Jones wrote: The systems that would want to do this kind of thing, such as Debian, have other mechanisms for deciding whether packages conflict, etc. IIRC, this is the argument I just used against adding support for multiple libraries in Cabal, so I guess I agree :-D Over-all I'm kinda neutral about whether HC-pkg needs to be an opaque interface to the packaging system. What are the advantages to this? Well, for one thing it allows us flexibility in how we store the package database. In GHC, I'm using the show/read form of [InstalledPackageInfo] to store the database, but it'd be nice if I could use binary serialisation in the future. To support a directory of config files, we don't have to expose the complete format, though. As long as hc-pkg can process the InstalledPackageInfo to produce the native format into a file, then we just ship that file with the distribution. So I'm fine with this, as long as we're not specifying the contents of the *.conf file. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
Keean Schupke wrote: [...] Whatever happens I think it must make sure all system resources allocated by a program are freed on exit - otherwise the machine will have a resource leak and will need rebooting eventually. That's an OS task IMHO, not really the task of an RTS. Looks like you're working on WinDoze... (sorry, couldn't resist :-) Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
Nope there are some unix resources that c exit routines do not free like semaphores. Sven Panne wrote: Keean Schupke wrote: [...] Whatever happens I think it must make sure all system resources allocated by a program are freed on exit - otherwise the machine will have a resource leak and will need rebooting eventually. That's an OS task IMHO, not really the task of an RTS. Looks like you're working on WinDoze... (sorry, couldn't resist :-) Cheers, S. ___ 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: Bug in touchForeignPtr?
On Monday 22 November 2004 14:45, Simon Marlow wrote: On 20 November 2004 23:02, Benjamin Franksen wrote: I am using Foreign.Concurrent.newForeignPtr and touchForeignPtr inside the finalizers to express liveness dependencies as hinted to by the documentation. This doesn't seem to work, though, or at least I can't see what I've done wrong. I attached a test module; compiled with ghc -fglasgow-exts --make TestForeignTouchBug.hs, ghc version 6.2.2, this gives .../foreigntouchbug ./a.out hit enter here before finalizing A after finalizing A before finalizing B after finalizing B hit enter here I expected the order of the finalizer calls be be the other way around, since the finalizer for the Bs explicitly touches the A value. The problem is that the runtime is running all outstanding finalizers at the end of execution, without regard for GC dependencies like the ones introduced by touchForeignPtr. I understand that there are situations where finalizers cannot be guaranteed to run: First because of an unconditional termination signal (SIGKILL), second because of circular dependencies resulting in a deadlock. I don't understand why it is necessary to performGC explicitly, in order to run finalizers at *normal* program termination and without a deadlock. BTW, the sensible thing to do in this case would be to throw an exception whenever a deadlock condition is detected. (That is, if it can be detected.) However, what I don't understand is why touchForeignPtr is not honored in my example program: Note that the output text lines from the finalizers appear *before* the last action in the program (which is a second getChar). The finalizers *are* called by the GC, and still the order is wrong. I've been planning to remove this automatic running of finalizers for other reasons. However, then you will get absolutely no guarantee that your finalizer will ever run at all (indeed, the property isn't always true right now, but it is usually true). It is unclear to me what usually means, here. Wouldn't it be better to state the conditions under which they are called resp. aren't? Documenting the current state of affairs would be to say - Finalizers are *not* guaranteed to run (instead they usually are, whatever that means). - Calling touchForeignPtr does *not* guarantee that the targeted foreignPtr is not finalized before this call. This would make it obvious that finalizers are not a reliable tool (which they aren't, at the moment). Let me share with you something that I've come to appreciate over the last few years: Finalizers are almost always not the right thing. Finalizers look terribly attractive, but often lead to a huge can of worms - best avoided if at all possible. I am ready to believe this, but I am nevertheless somewhat disturbed. I use finalizers to automatically reclaim resources from a foreign library. If I don't use them, these resources must be reclaimed explicitly. This is bad for two reasons: (1) The programmer has to remember to reclaim resources. (2) Handles for such resources become invalid after reclamation. If finalizers are not the right thing, what else is? Ben -- Top level things with identity are evil.-- Lennart Augustsson ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
If finalizers are not the right thing, what else is? I've found that when writing an interface to a C library that requires resource management, it's much better to use the withX (see Control.Exception.bracket) style of function than to use finalizers - programs are much easier to reason about and debug. Abe ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
Abraham Egnor wrote: I've found that when writing an interface to a C library that requires resource management, it's much better to use the withX (see Control.Exception.bracket) style of function than to use finalizers - programs are much easier to reason about and debug. ... and have a much more deterministic behaviour regarding resource consumption. This is a very important point which is often forgotten. Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
Keean Schupke wrote: Nope there are some unix resources that c exit routines do not free like semaphores. Which library/OS calls do you mean exactly? I always thought that files are the only resources surviving process termination. Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: User-defined operators and compound expressions using Happy
On Mon, 2004-11-22 at 17:48 +0100, Frank-Andre Riess wrote: Hi there folks, once again, I've got a question related to Happy (I've got version 1.13 at the moment). Maybe, it's even more a question on formal languages, but well... How can I write a grammar that can cope with user-defined operators (of different precedences/associativities One standard solution is to parse user defined operators as if they were all one precedence/associativity and then re-associate them later once you know what the precedence and associativity of each operator is. That way the parser grammar does not need to be adjusted on the fly. So you wold parse 1+2*3 as [LiteralInt 1, Op '+', LiteralInt 2, Op '*', LiteralInt 3] and then later turn that into BinOp '+' (LiteralInt 1) (BinOp '*' (LiteralInt 2) (LiteralInt 3)) using your mapping of operators to precedence/associativity. Duncan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
Semaphores (SYSV style) are not freed automatically. Currenly I am using C's at_exit funtion (which is even called on a signal)... Perhaps this is the way to deal with foreign resources... bracket notation and at_exit to clean up on signals? Keean. Sven Panne wrote: Keean Schupke wrote: Nope there are some unix resources that c exit routines do not free like semaphores. Which library/OS calls do you mean exactly? I always thought that files are the only resources surviving process termination. Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: User-defined operators and compound expressions using Happy
On 2004 nov 22, at 17:48, Frank-Andre Riess wrote: Hi there folks, once again, I've got a question related to Happy (I've got version 1.13 at the moment). Maybe, it's even more a question on formal languages, but well... How can I write a grammar that can cope with user-defined operators (of different precedences/associativities) and compound expression like function calls, if-then-else- and case-statements and the like. I tried to write it down straight forwardly, but failed terribly (alas, I didn't keep it, so I can't show you - if someone of you is versed in this issue, I can try to explain the language's constructs). One way of doing this using combinator based parsing (where you can generate parsers dynamically) is to read the fixity declarations, and to use the result of this to build the precedence parser. This idea has been sketched in: S. D. Swierstra and P. R. Azero Alcocer. Fast, Error Correcting Parser Combinators: a Short Tutorial. In J. Pavelka, G. Tel, and M. Bartosek, editors, SOFSEM'99 Theory and Practice of Informatics, 26th Seminar on Current Trends in Theory and Practice of Informatics, volume 1725 of LNCS, pages 111--129, November 1999. If you do not have access to this I will be happy to send it to you, Doaitse Swierstra == some text (created from the pdf) from this paper As an example of what can be done we will now show how to construct parsers dynamically by writing a parser for an expression language with infix operators. An example input is: (L+R*)a+b*(c+d) and the code we want to generate is: abcd+*+ which is the reversed Polish notation of the input expressions. The text (L+R*) indicates that + is left (L) associative and has lower priority than *, which is right (R) associative. In this way an unlimited number of operators may be specified, with relative priorities depending on their position in this list. We start by defining a function that parses a single character identifier and returns as its result that identifier in the form of a string: pVar = (\c - [c]) $ pAnyOf ['a'..'z'] . The next step is to define a function that, given the name of an operator, recognizes that operator and as a result returns a function that will concatenate the two arguments of that operator and postfix it with the name of the operator, thus building the reversed Polish notation: pOp name = (\ left right - left++right++[name]) $ pSym name Note that, by using the operator $ we indicate that we are not interested in the recognized operator; we already know what this is since it was passed as a parameter. Next we de ne the function compile. For this we introduce a new combinator @, that takes as its left hand side operand a parser constructor f and as its right hand side operand a parser g. The results v of parsing a pre x of the input with g, are used in calling f; these calls, in their turn, result in new parsers which are applied to the rest of the input: (f @ g) input = [ f v rest | (v, rest) - g input ] Since our input consists of two parts, the priority declarations and the expression itself , we postulate that the function compile reads: compile = pRoot @ pPrios First we focus on the function pRoot, that should take as argument the result of recognizing the priorities. Here we will assume that this result is a function that, given how to parse an operand, parses an expression constructed out of operands and the de ned operators: pRoot prios = let pExpr = prios (pVar | pParens pExpr) in pExpr There is a difference between an operator that occurs in the declaration part of the input and one in the expression part: the former may be any operator, whereas the latter can only be an operator that has been declared before. For the priority declaration part we thus introduce a new parser that recognizes any operator, and returns a parser that compiles the just recognized operator using the function pOp defined before: pAnyOp = pOp $ pAnyOf +*/-^ just some possible operators Now suppose we have recognized a left and a right associative operator resulting in operator compilers pLeft and pRight. Out of these we can construct a function that, given the operand parser, parses infix expressions containing pLeft and pRight occurrences: pLR factor = (pChainl pLeft . pChainr pRight) factor. Generalizing this pattern to an unlimited number of operators we now deduce the definition: pPrios = pParens $ pFoldr ((.), id) (( pChainl $ pSym 'L' | pChainr $ pSym 'R' ) * pAnyOp ) Let us now compare once more this approach with the situation where we would have used a special parser generator. In the combinator approach we can freely introduce all kinds of abbreviations by defining new combinators in terms of existing ones; furthermore we may de ne higher order combinators that take arguments and return values that may be parsers. This is a property we get for free
Re: Bug in touchForeignPtr?
On Monday 22 November 2004 18:55, Sven Panne wrote: Abraham Egnor wrote: I've found that when writing an interface to a C library that requires resource management, it's much better to use the withX (see Control.Exception.bracket) style of function than to use finalizers - programs are much easier to reason about and debug. ... and have a much more deterministic behaviour regarding resource consumption. This is a very important point which is often forgotten. Ok, the 'withX' pattern solves both of the problems I mentioned and in addition is more deterministic (and, using bracket, also exception safe). Maybe I should use it instead of finalizers. However, I wonder if it is general enough to be the only method exported from a library. I doubt it, otherwise there would be no 'openFile' and 'hClose' in System.IO but only a 'withFile'. Do you recommend supplying 'newX' and 'freeX' in addition to 'withX'? Or should I rather use 'newX' plus finalizers for those (rare?) cases where 'withX' is not general enough? Ben -- Top level things with identity are evil.-- Lennart Augustsson ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
Keean Schupke wrote: C exit routines aren't responsible for freeing OS resources; the OS is. The fact that the SysV IPC objects aren't freed on exit is intentional; they are meant to be persistent. For the same reason, the OS doesn't delete upon termination any files which the process created. Right, which is why if you want to clean up temporary files, or temporary semaphores the OS doesn't do it for you, and you need to put some routine inplace to do it (using at_exit)... It seems this is the only way to guarantee something gets run when a program exits for whatever reason. There isn't any way to *guarantee* that something is run upon termination. The program may be terminated due to SIGKILL (e.g. due to a system-wide lack of virtual memory). If you run out of stack, you may not be able to call functions to perform clean-up. Also, if the program crashes, handling the resulting SIGSEGV (etc) is likely to be unreliable, as the memory containing the resource references may have been trashed. Calling remove() on a filename which might have been corrupted is inadvisable. Also, at_exit() isn't standard. atexit() is ANSI C, but that is only supposed to be called for normal termination (exit() or return from main()), not for _exit() or fatal signals. -- Glynn Clements [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
Although, this does remind me. A suitable atexit-equivalant in the haskell libraries would be much appreciated. John -- John Meacham - repetae.netjohn ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
