From judah.jacobson at gmail.com Tue Sep 1 01:37:43 2009 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Sep 1 01:17:27 2009 Subject: Proposal #3456: Add FilePath -> String decoder In-Reply-To: <87skf8h26j.fsf@malde.org> References: <6d74b0d20908230927w996fcb3m4cd0737f0a4eb9c2@mail.gmail.com> <90889fe70908260138ic8ebd0ap2627e9b5d30e6ccb@mail.gmail.com> <2608b8a80908260614m493128c9vef79c0b8a15187d3@mail.gmail.com> <1251499827.30910.15177.camel@localhost> <87skf8h26j.fsf@malde.org> Message-ID: <6d74b0d20908312237k24d20a05u7205e35da82b7495@mail.gmail.com> On Mon, Aug 31, 2009 at 12:28 AM, Ketil Malde wrote: > Duncan Coutts writes: > >> Presumably on POSIX we will follow the glib approach of using '?' >> replacement chars, since the conversion to string is aimed at human >> consumption. Doing this makes the function total but lossy. > > If the FilePath is not a valid UTF-8, there's a private area in > Unicode that can be used for encoding byte values. ?Wikipedia's UTF-8 > entry suggests "U+DCxx where xx is the byte's value". > > This would make us "non conformant" as per the bureaucracy, but on > the other hand, it would work (with some ugliness for non-ASCII-based > encodings) for any encoding, and these would be the expected identity: Taking a step back, there's (at least) three separate issues at play here: 1) The FilePath type must be able to represent arbitrary byte sequences on POSIX systems, but the current one-byte-per-Char is suboptimal. 2) Much existing code probably relies on FilePath==String. 3) We need to be able to display FilePaths in a readable form to the user. The U+DCxx method is a way to fix #1 without affecting #2. However, I don't think this will solve issue #3 (which is what my proposal is intended to address). Probably a FilePath->String display function should explicitly replace the problem bytes with either "?" or "%xx". > Can FilePath be defined differently on different systems? > > I.e. could it be: > > ? ? type FilePath = [Word8] -- Posix > ? ? type FilePath = [Word16] ?-- Windows, etc > > It'd also be nice if overloaded string literals are used (and extended > to these), so that I could use specify filenames directly with no need > for wrappers. Yes, this would solve #1 nicely; but runs into #2, so it's looking unlikely that it will happen anytime soon. >> In principle I guess it'd be ok to add versions in the >> System.FilePath.Posix module that take an extra encoding parameter > > I think these belong in Text.Encodings or some such. > > Either you use the default, simple and pure interface (which is UTF-8 > on Posix), or you'll have to do some more work, and do something like > > ?mydecoder <- filePathToStringWith =<< getLocaleEncoding Sure; though I'd expect that a TextEncoding would convert bytes to/from Chars-as-Unicode, which isn't really useful on Windows. I guess on Windows filePathToStringWith would just completely ignore the encoding parameter. (But I do think it's important to have such a function for portability.) -Judah From judah.jacobson at gmail.com Tue Sep 1 02:19:18 2009 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Sep 1 01:59:02 2009 Subject: Proposal #3456: Add FilePath -> String decoder In-Reply-To: <1251499827.30910.15177.camel@localhost> References: <6d74b0d20908230927w996fcb3m4cd0737f0a4eb9c2@mail.gmail.com> <90889fe70908260138ic8ebd0ap2627e9b5d30e6ccb@mail.gmail.com> <2608b8a80908260614m493128c9vef79c0b8a15187d3@mail.gmail.com> <1251499827.30910.15177.camel@localhost> Message-ID: <6d74b0d20908312319t346f80ema0248d45be95f5ab@mail.gmail.com> On Fri, Aug 28, 2009 at 3:50 PM, Duncan Coutts wrote: > On Wed, 2009-08-26 at 16:14 +0300, Yitzchak Gale wrote: > >> I am now beginning to lean towards Ketil's suggestion >> that on POSIX platforms we should always use >> UTF-8. We then need a prominent warning in the >> documentation that if you need something else, >> like the current locale, decode it yourself. > > That's nice in that it makes the function pure, or equivalently so that > it does not need a locale parameter. > >> Note that it is becoming increasingly rare for people >> to use non-UTF-8 locales anywhere in the world, >> and even then it's likely ignored by many UIs. >> So I'm inclined against cluttering the API with >> convenience functions for other encodings, as Johan >> is suggesting. I agree that this would make the API much simpler; but I'm wary of broad statements like the above. My (very vague) impression was that many Japanese users, for example, still use non-Unicode encodings. I think that glib is an interesting example. Its developers advocate pretty strongly for everyone to use utf-8 filenames; but even they provide a simple way for the user of any glib program to override that behavior by setting G_FILENAME_ENCODING=@locale. As another example, Python v.3, which recently redesigned its Unicode interface, also still uses the locale for filenames rather than solely utf-8. The following interview with Guido from January has a good take on why they did that (about halfway through the article): http://broadcast.oreilly.com/2009/01/the-evolution-of-python-3.html If we really want a pure FilePath->String conversion, then perhaps we could make the rts check the locale once at the start of the program, and have every subsequent conversion use that locale. This would be safe from order-of-operation changes; though it would be possible for the same pure code to behave differently in two different program runs...so I'm unsure about that solution. Best, -Judah From john at repetae.net Tue Sep 1 04:01:08 2009 From: john at repetae.net (John Meacham) Date: Tue Sep 1 03:40:34 2009 Subject: ioToST In-Reply-To: <200908242359.18474.dan.doel@gmail.com> References: <9410602916.20090825073618@gmail.com> <200908242359.18474.dan.doel@gmail.com> Message-ID: <20090901080106.GR8113@sliver.repetae.net> On Mon, Aug 24, 2009 at 11:59:18PM -0400, Dan Doel wrote: > On Monday 24 August 2009 11:36:18 pm Bulat Ziganshin wrote: > > Hello Samuel, > > > > Tuesday, August 25, 2009, 4:36:31 AM, you wrote: > > > Shouldn't Control.Monad.ST export ioToST :: IO a -> ST RealWorld a, as > > > defined in GHC.IO? > > > > no. ST is a subset of IO monad with a limited set of operators > > guaranteeing referential transparence, as a result runST is a pure > > operation. if you provide ability to run in ST monad arbitrary > > operations, this guarantee will break. there are pother way to do the > > same - use IO operations and unsafePerformIO > > The proposed ioToST yields a value of type 'ST RealWorld a', which is not > usable with runST, as it is not sufficiently polymorphic, and thus cannot be > used to write unsafePerformIO. > > The only way you can eventually do anything with a value of the above type > (short of unsafeCoerce and such) is to use stToIO to put it back into IO, and > run it from main. A useful thing you can do with this is make 'pre-fusioned' monad transformers, like if you want to combine a writer monad with the IO O monad, you could do something like newtype IOW w a = IOW (RealWorld -> (# RealWorld, w, a #) instance Monoid w => Monad (IOW w) where return x = IOW $ \w -> (# w, mempty, x #) ... then use ioToST to write your MonadIO instance. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From john at repetae.net Tue Sep 1 04:57:50 2009 From: john at repetae.net (John Meacham) Date: Tue Sep 1 04:37:13 2009 Subject: Binding to inline functions In-Reply-To: <4A99199C.40406@gmail.com> References: <1251056058.30910.4937.camel@localhost> <4A93D687.4050001@gmail.com> <1251498087.30910.15118.camel@localhost> <4A99199C.40406@gmail.com> Message-ID: <20090901085750.GT8113@sliver.repetae.net> Can't hsc2hs already do this? #def char w_some_inline_function(char foo) { return some_inline_function(foo); } foreign import ccall "w_some_inline_function" some_inline_function :: CChar -> CChar I have certainly used this idiom on several occasions to work around the issue. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From wren at community.haskell.org Wed Sep 2 02:07:50 2009 From: wren at community.haskell.org (wren ng thornton) Date: Wed Sep 2 01:47:19 2009 Subject: Proposal #3456: Add FilePath -> String decoder In-Reply-To: <6d74b0d20908312319t346f80ema0248d45be95f5ab@mail.gmail.com> References: <6d74b0d20908230927w996fcb3m4cd0737f0a4eb9c2@mail.gmail.com> <90889fe70908260138ic8ebd0ap2627e9b5d30e6ccb@mail.gmail.com> <2608b8a80908260614m493128c9vef79c0b8a15187d3@mail.gmail.com> <1251499827.30910.15177.camel@localhost> <6d74b0d20908312319t346f80ema0248d45be95f5ab@mail.gmail.com> Message-ID: <4A9E0BB6.3010101@community.haskell.org> Judah Jacobson wrote: > Duncan Coutts wrote: >>> Note that it is becoming increasingly rare for people >>> to use non-UTF-8 locales anywhere in the world, >>> and even then it's likely ignored by many UIs. >>> So I'm inclined against cluttering the API with >>> convenience functions for other encodings, as Johan >>> is suggesting. > > I agree that this would make the API much simpler; but I'm wary of > broad statements like the above. My (very vague) impression was that > many Japanese users, for example, still use non-Unicode encodings. Indeed, non-Unicode encodings are still commonplace in Japan (and, last I checked, China). FWIW. -- Live well, ~wren From jon.fairbairn at cl.cam.ac.uk Thu Sep 3 04:02:10 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu Sep 3 03:41:54 2009 Subject: darcs patch: Add justIf to Data.Maybe References: <17512.1251309503@calligramme.charmers> <1251321384.30910.10061.camel@localhost> Message-ID: Duncan Coutts writes: > On Wed, 2009-08-26 at 18:58 +0100, Jon Fairbairn wrote: > >> > It's not that hard to write >> > >> > all_spaces xs = checkA (all (isSpace xs)) xs >> > >> > if that's really what you want. >> >> Not /hard/, but it involves using xs twice, which should tell us >> something. > > I'm not sure it does tell us much, One thing it tells us is that it's going to be awkward to write in a point-free style. > given that there are also cases where we need to use it only once, and > would be forced to use \_ -> to ignore it in the predicate. The other thing it tells us is that it makes a linear (or should I be saying single-threaded here?) term look like it's not. Using const in the opposite case doesn't have that effect. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) From jon.fairbairn at cl.cam.ac.uk Thu Sep 3 04:10:28 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu Sep 3 03:50:11 2009 Subject: Proposal: add new function "check" to Control.Monad References: <17202.1251309179@calligramme.charmers> <351FDBA1-8512-457D-BA61-FC67422EAB66@informatik.uni-kiel.de> Message-ID: Sebastian Fischer writes: > On Aug 26, 2009, at 7:52 PM, Jon Fairbairn wrote: > >> When designing a library, one should choose >> the primitives so that future definitions are simple, both in >> the complexity of the terms needed to define them and in the >> thought needed to define them, rather than the simplicity of >> definition of the primitives themselves. The reason that I >> suggested check is that it seems to me that it gives both of >> those things in a way that guard doesn't > > I see. Also the type of guard is indeed unusual. > Historically, guard seems inspired by conditions in list > comprehensions but I would appreciate a sensible > refactoring. > > When designing MonadPlus combinators from scratch I would > probably implement > > filter :: MonadPlus m => (a -> Bool) -> m a -> m a > > as a generalisation of the list function with the same name. > After Davids remarks I'm not sure whether I would need > > check f = filter f . return Now that /is/ a simple definition that would argue against inclusion of check. > I agree to you reasoning to prefer check over guard but go > one step further and prefer filter over check. I would be happy with that. > I would vote for adding a generalized filter to Control.Monad. Using > the name of the Prelude function on lists is justified because it is a > generalisation just like many functions in Data.Foldable which also > reuse Prelude names. Were I designing this stuff from scratch, I'd go the same way (actually, I'd want to restore monad comprehensions too), but there is currently an explicit naming scheme in Control.Monad, under which the name would be mfilter, so I think (in the absence of renaming fmap to map, which I would also strongly prefer -- etc) we should use the name mfilter for the time being. In view of this, I reckon I should change the proposal and reset the time limit. What's the procedure for this? -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From jon.fairbairn at cl.cam.ac.uk Thu Sep 3 04:12:17 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu Sep 3 03:54:21 2009 Subject: darcs patch: Add justIf to Data.Maybe References: <1250936078.4339.3.camel@localhost> Message-ID: Joachim Breitner writes: > are you proposing that, if check is available, no justIf is needed in > the libraries? Or are you just proposing a different implementation? For the record, I am opposed to justIf on the grounds that it is a specialisation of something that should be typed at MonadPlus (and which would consequently have to have a different name). -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From martijn at van.steenbergen.nl Thu Sep 3 07:02:47 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Thu Sep 3 06:42:09 2009 Subject: Proposal: add new function "check" to Control.Monad In-Reply-To: <49a77b7a0908261203y57698896m1ceeac9abc60625a@mail.gmail.com> References: <5ab17e790908260949w30bad06ej9d5f3e8150cb43ac@mail.gmail.com> <18058.1251310063@calligramme.charmers> <49a77b7a0908261203y57698896m1ceeac9abc60625a@mail.gmail.com> Message-ID: <4A9FA257.3000507@van.steenbergen.nl> David Menendez wrote: > I'm usually opposed to adding small functions to the standard library, > but check is something I've defined for myself dozens of times. > (Although I usually call it "require".) Some languages call it "assert". Martijn. From lienmeister at gmail.com Thu Sep 3 15:08:42 2009 From: lienmeister at gmail.com (John Lien) Date: Thu Sep 3 14:47:59 2009 Subject: Request to add isBinDigit to Data.Char Message-ID: Add isBinDigit that returns true is char = 0 or char =1 so that binary digit chars are covered like hex,octal,decimal chars are. From ross at soi.city.ac.uk Sun Sep 6 19:12:29 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Sep 6 18:51:39 2009 Subject: Proposal #3456: Add FilePath -> String decoder In-Reply-To: <6d74b0d20908230927w996fcb3m4cd0737f0a4eb9c2@mail.gmail.com> References: <6d74b0d20908230927w996fcb3m4cd0737f0a4eb9c2@mail.gmail.com> Message-ID: <20090906231229.GA9507@soi.city.ac.uk> On Sun, Aug 23, 2009 at 09:27:15AM -0700, Judah Jacobson wrote: > Currently, FilePaths on POSIX systems are represented as raw bytes in > a String. When this last came up on the mailing list, the general > consensus was to make FilePath an abstract datatype representing paths > as Strings on Windows and raw bytes on POSIX systems. However, such a > change is sure to break some existing code. Indeed, it would break an enormous amount of existing code. A more feasible migration path would be to introduce a new abstract type, say NativeString, with corresponding variants of the file operations, getArgs and getEnv, beside the Haskell 98 functions. That could be done now. Using Char to hold raw bytes (as GHC is doing, and this proposal would implicitly condone) is a really bad idea. It forces the programmer to keep track of whether a particular String has been converted or not. That's a job for the type system. From marlowsd at gmail.com Tue Sep 8 08:02:42 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Sep 8 07:41:51 2009 Subject: Recommendation for the procedure to add platform packages In-Reply-To: <1250733860.9379.2142.camel@localhost> References: <1250733860.9379.2142.camel@localhost> Message-ID: <4AA647E2.9020200@gmail.com> On 20/08/2009 03:04, Duncan Coutts wrote: > All, > > The Haskell Platform steering committee have been very busy over the > past two weeks drafting, discussing and redrafting. > > The result is our recommendation to the libraries list for a procedure > for adding new packages to the Haskell Platform. > > Before you all go off and read it, we'd like to say what feedback we are > looking for and what the next steps will be. The document we've come up > with describes the procedure but only some very basic quality > requirements for packages. Our aim is to have the libraries list come to > an agreement on the procedure first and then we can discuss codifying a > more comprehensive set of package requirements and guidelines. > > The main document contains: > * the procedure itself, which is relatively short > * a rationale, cross-linked to the procedure > * a procedure to help us make decisions > > http://trac.haskell.org/haskell-platform/wiki/AddingPackages On the whole, +1. The process is quite detailed, so we shouldn't expect reviewers to be familiar with all the rules; instead it's up to the steering committee to guide the discussion and remind people of the administrative details at each stage (e.g. "you have until X to respond, or we assume you agree", or "this is the first phase, during which we are trying to reach consensus on Z"). Specific comments: "come to view on whether the package should be accepted" -> "help achieve a consensus ... " "the libraries mailing list reach consensus to accept it" -> "the reviewers reach a consensus to accept it" ? "Compile on all operating systems and compilers that the platform targets" -> ".. except where the package is compiler- or platform-specific" ? The "Interim Licesne Policy" should be one of the bullet points under Package Requirements. e.g. "The package must be distributed under an acceptable license. The only license currently acceptable is BSD3 [rationale..]" I'd like to see something about API style mentioned in the "Package Requirements". e.g.: Packages admitted to the platform should follow an API style similar to those packages already in the package. While the style guidelines for package APIs have not yet been written down, we expect that to change in the future. Cheers, Simon From marlowsd at gmail.com Tue Sep 8 08:04:19 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Sep 8 07:43:27 2009 Subject: darcs patch: Fix unportable use of sleep(1) In-Reply-To: <200908290941.n7T9fer1025948@nutty.outback.escape.de> References: <200908290941.n7T9fer1025948@nutty.outback.escape.de> Message-ID: <4AA64843.2090107@gmail.com> On 29/08/2009 10:41, Matthias Kilian wrote: > Sat Aug 29 11:37:20 CEST 2009 Matthias Kilian > * Fix unportable use of sleep(1) > `sleep 1s' is probably a GNUism; `sleep 1' should do the same in a > portable way. I'll validate and push; thanks. Simon From igloo at earth.li Thu Sep 10 11:05:10 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Sep 10 10:44:06 2009 Subject: Potential Network SIG In-Reply-To: <4A9565EB.6020402@gmail.com> References: <4c44d90b0908212149y650a3861j93352a24bdce12f1@mail.gmail.com> <90889fe70908241248g201596a8p5509020aa88bcba1@mail.gmail.com> <771B85EE-5D41-4C56-8275-6D62F67932EE@gmail.com> <4A93D3FF.4010002@gmail.com> <25151428.post@talk.nabble.com> <4A9565EB.6020402@gmail.com> Message-ID: <20090910150510.GA3440@matrix.chaos.earth.li> On Wed, Aug 26, 2009 at 05:42:19PM +0100, Simon Marlow wrote: >> >> As far as buffering goes, Handles currently couple buffering modes, which is >> potentially frustrating if one wants, e.g., no buffering on recv, but block >> buffering on send. > > Buffering is always invisible on input - if there is any input > available, you'll see it immediately. It has performance implications > only - but I can't imagine you'd want to deliberately reduce performance > by turning off buffering (in fact, I think the new I/O library doesn't > even honour NoBuffering on input Handles). So is this program supposed to not be valid (or at least, to not behave as I would expect)? import Control.Monad import System.Environment import System.IO import System.Posix.Process main :: IO () main = do [get] <- getArgs hSetBuffering stdin NoBuffering when (read get) $ do x <- hGetChar stdin putStrLn ("Got: " ++ show x) executeFile "cat" True [] Nothing With 6.8.2 I get: $ printf "foo\nbar\n" | ./q True Got: 'f' oo bar $ printf "foo\nbar\n" | ./q False foo bar as expected, but with the HEAD: $ printf "foo\nbar\n" | ./q True Got: 'f' printf "foo\nbar\n" | ./q False foo bar Thanks Ian From duncan.coutts at worc.ox.ac.uk Fri Sep 11 07:53:07 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Sep 11 07:35:23 2009 Subject: Potential Network SIG In-Reply-To: <20090910150510.GA3440@matrix.chaos.earth.li> References: <4c44d90b0908212149y650a3861j93352a24bdce12f1@mail.gmail.com> <90889fe70908241248g201596a8p5509020aa88bcba1@mail.gmail.com> <771B85EE-5D41-4C56-8275-6D62F67932EE@gmail.com> <4A93D3FF.4010002@gmail.com> <25151428.post@talk.nabble.com> <4A9565EB.6020402@gmail.com> <20090910150510.GA3440@matrix.chaos.earth.li> Message-ID: <1252669987.5266.8027.camel@localhost> On Thu, 2009-09-10 at 16:05 +0100, Ian Lynagh wrote: > On Wed, Aug 26, 2009 at 05:42:19PM +0100, Simon Marlow wrote: > >> > >> As far as buffering goes, Handles currently couple buffering modes, which is > >> potentially frustrating if one wants, e.g., no buffering on recv, but block > >> buffering on send. > > > > Buffering is always invisible on input - if there is any input > > available, you'll see it immediately. It has performance implications > > only - but I can't imagine you'd want to deliberately reduce performance > > by turning off buffering (in fact, I think the new I/O library doesn't > > even honour NoBuffering on input Handles). > > So is this program supposed to not be valid (or at least, to not behave > as I would expect)? > > import Control.Monad > import System.Environment > import System.IO > import System.Posix.Process > > main :: IO () > main = do [get] <- getArgs > hSetBuffering stdin NoBuffering > when (read get) $ do x <- hGetChar stdin > putStrLn ("Got: " ++ show x) > executeFile "cat" True [] Nothing So you're accessing the stdin file descriptor via the stdin Handle and also directly via cat. Note that there's no API in Haskell code to get at the unadorned FD while keeping the Handle open. Duncan From marlowsd at gmail.com Fri Sep 11 09:12:02 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Sep 11 08:51:01 2009 Subject: Potential Network SIG In-Reply-To: <20090910150510.GA3440@matrix.chaos.earth.li> References: <4c44d90b0908212149y650a3861j93352a24bdce12f1@mail.gmail.com> <90889fe70908241248g201596a8p5509020aa88bcba1@mail.gmail.com> <771B85EE-5D41-4C56-8275-6D62F67932EE@gmail.com> <4A93D3FF.4010002@gmail.com> <25151428.post@talk.nabble.com> <4A9565EB.6020402@gmail.com> <20090910150510.GA3440@matrix.chaos.earth.li> Message-ID: <4AAA4CA2.1070709@gmail.com> On 10/09/2009 16:05, Ian Lynagh wrote: > On Wed, Aug 26, 2009 at 05:42:19PM +0100, Simon Marlow wrote: >>> >>> As far as buffering goes, Handles currently couple buffering modes, which is >>> potentially frustrating if one wants, e.g., no buffering on recv, but block >>> buffering on send. >> >> Buffering is always invisible on input - if there is any input >> available, you'll see it immediately. It has performance implications >> only - but I can't imagine you'd want to deliberately reduce performance >> by turning off buffering (in fact, I think the new I/O library doesn't >> even honour NoBuffering on input Handles). > > So is this program supposed to not be valid (or at least, to not behave > as I would expect)? > > import Control.Monad > import System.Environment > import System.IO > import System.Posix.Process > > main :: IO () > main = do [get]<- getArgs > hSetBuffering stdin NoBuffering > when (read get) $ do x<- hGetChar stdin > putStrLn ("Got: " ++ show x) > executeFile "cat" True [] Nothing > > With 6.8.2 I get: > > $ printf "foo\nbar\n" | ./q True > Got: 'f' > oo > bar > > $ printf "foo\nbar\n" | ./q False > foo > bar > > as expected, but with the HEAD: > > $ printf "foo\nbar\n" | ./q True > Got: 'f' > > printf "foo\nbar\n" | ./q False > foo > bar I think relying on NoBuffering in this way is a little dodgy. For example, how do you implement hLookAhead, or hIsEOF? Try your example with hIsEOF, and you'll probably get something "unexpected" with 6.8.2. Let's suppose we wanted this to work, i.e. not read more bytes than are necessary to satisfy the current demand. In the case of a multibyte character, we have to read one byte, notice that it is the first byte of a multibyte sequence, and then read the rest of the bytes (into a "buffer" presumably). It would be possible, but complicated, and I'm not convinced we really need to support this kind of usage. Cheers, Simon From ekmett at gmail.com Fri Sep 11 09:54:11 2009 From: ekmett at gmail.com (Edward Kmett) Date: Fri Sep 11 09:33:04 2009 Subject: Proposal: add new function "check" to Control.Monad In-Reply-To: <351FDBA1-8512-457D-BA61-FC67422EAB66@informatik.uni-kiel.de> References: <17202.1251309179@calligramme.charmers> <351FDBA1-8512-457D-BA61-FC67422EAB66@informatik.uni-kiel.de> Message-ID: <7fb8f82f0909110654j4bea417ct3ec9f9a7b3141daa@mail.gmail.com> While I like the generic version of filter, and have written one myself, I am somewhat concerned about the fact that Control.Monad is probably the module most often imported unqualified and without an explicit import list due to the sheer number of combinators that it provides and filter is a very commonly used function in the Prelude. Adding the generic version of filter with the same name to such a module will likely break a good deal of code. Jon's suggestion of mfilter (filterM?) based on the ad hoc naming conventions in Control.Monad sounds pretty safe though. -Edward Kmett On Wed, Aug 26, 2009 at 3:44 PM, Sebastian Fischer < sebf@informatik.uni-kiel.de> wrote: > > On Aug 26, 2009, at 7:52 PM, Jon Fairbairn wrote: > > When designing a library, one should choose >> the primitives so that future definitions are simple, both in >> the complexity of the terms needed to define them and in the >> thought needed to define them, rather than the simplicity of >> definition of the primitives themselves. The reason that I >> suggested check is that it seems to me that it gives both of >> those things in a way that guard doesn't >> > > I see. Also the type of guard is indeed unusual. Historically, guard seems > inspired by conditions in list comprehensions but I would appreciate a > sensible refactoring. > > When designing MonadPlus combinators from scratch I would probably > implement > > filter :: MonadPlus m => (a -> Bool) -> m a -> m a > > as a generalisation of the list function with the same name. After Davids > remarks I'm not sure whether I would need > > check f = filter f . return > > I agree to you reasoning to prefer check over guard but go one step further > and prefer filter over check. > > I would vote for adding a generalized filter to Control.Monad. Using the > name of the Prelude function on lists is justified because it is a > generalisation just like many functions in Data.Foldable which also reuse > Prelude names. > > Cheers, > Sebastian > > -- > Underestimating the novelty of the future is a time-honored tradition. > (D.G.) > > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090911/e580c46d/attachment.html From Axel.Simon at ens.fr Fri Sep 11 14:00:25 2009 From: Axel.Simon at ens.fr (Axel Simon) Date: Fri Sep 11 13:39:26 2009 Subject: Data.IntMap: intersection function not sufficiently polymorphic Message-ID: <1252692025.2883.4.camel@aconit> Hi, the function intersectionWith :: (a -> b -> a) -> IntMap a -> IntMap b -> IntMap a in Data.IntMap creates a map of elements that occur in both maps. This function can and should return a map of an arbitrary third type: intersectionWith :: (a -> b -> c) -> IntMap a -> IntMap b -> IntMap c This also applies to Data.IntMap.intersectionWithKey. Oddly enough, this is already fixed in Data.Map. Discussion period one week?! Cheers, Axel. From igloo at earth.li Fri Sep 11 19:24:50 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Sep 11 19:03:41 2009 Subject: Data.IntMap: intersection function not sufficiently polymorphic In-Reply-To: <1252692025.2883.4.camel@aconit> References: <1252692025.2883.4.camel@aconit> Message-ID: <20090911232450.GA14364@matrix.chaos.earth.li> On Fri, Sep 11, 2009 at 08:00:25PM +0200, Axel Simon wrote: > > intersectionWith :: (a -> b -> a) -> IntMap a -> IntMap b -> IntMap a > > in Data.IntMap creates a map of elements that occur in both maps. This > function can and should return a map of an arbitrary third type: > > intersectionWith :: (a -> b -> c) -> IntMap a -> IntMap b -> IntMap c Thanks for the report; this is already fixed in the HEAD by: Thu Oct 2 15:48:28 BST 2008 sedillard@gmail.com * correct type for IntMap.intersectionWith[Key] Thanks Ian From dons at galois.com Sat Sep 12 05:24:23 2009 From: dons at galois.com (Don Stewart) Date: Sat Sep 12 05:05:31 2009 Subject: [lists@qseep.net: [Haskell-cafe] Unable to install Haskell Platform without readline] Message-ID: <20090912092423.GB19071@whirlpool.galois.com> ----- Forwarded message from Lyle Kopnicky ----- Date: Fri, 11 Sep 2009 11:46:00 -0700 From: Lyle Kopnicky To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Unable to install Haskell Platform without readline Hi folks, I just installed GHC 6.10.4 on Ubuntu 9.04 32-bit, and then tried to install the Haskell Platform from source. It built quite a bit of stuff, with many warnings but no errors, and then finally died with the error below. To install editline, I need cabal, which is of course why I installed the Platform. I read an earlier thread from May that said that editline came with GHC 6.10.2, so the Platform didn't work with 6.10.3, but was soon to be updated. Now the web site for the Platform says it comes with 6.10.4, so I assumed it should work with 6.10.4, but apparently it still has this problem of still missing editline. Am I doing something wrong? checking editline/readline.h usability... no checking editline/readline.h presence... no checking for editline/readline.h... no checking editline/editline.h usability... no checking editline/editline.h presence... no checking for editline/editline.h... no checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes checking for sign of read_history result on error... negative checking for rl_completion_matches... no checking for completion_matches... no configure: error: editline not found, so this package cannot be built See `config.log' for more details. Error: Configuring the editline-0.2.1.0 package failed make: *** [build.stamp] Error 2 - Lyle _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ----- End forwarded message ----- From sfvisser at cs.uu.nl Sun Sep 13 08:49:43 2009 From: sfvisser at cs.uu.nl (Sebastiaan Visser) Date: Sun Sep 13 08:28:32 2009 Subject: GHC bus error on Network.BSD.getHostByName Message-ID: <82A38370-4AB5-4C73-B5BF-4AC27D0EC32D@cs.uu.nl> Hello all, Before I file a bug maybe someone might recognize the following error and knows if I should blame GHC or someone at Apple. When trying to use the Network.BSD.getHostByName function ghci exits with a bus error. The same thing happens with ghc --make and runghc. > > ghci > GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Prelude> :m Network.BSD > Prelude Network.BSD> getHostByName "www.google.com" > Loading package syb ... linking ... done. > Loading package base-3.0.3.1 ... linking ... done. > Loading package parsec-2.1.0.1 ... linking ... done. > Loading package network-2.2.1.4 ... linking ... done. > zsh: bus error ghci I'm using a Mac running Snow Leopard and GHC 6.10.4 from the MacOSX platform installer together with network-2.2.1.4. Never had any problems with this function before my upgrade to Snow Leopard. All other GHC functionality seems to be ok. Should I file a bug or is this something already known? Thanks, -- Sebastiaan Visser From igloo at earth.li Sun Sep 13 09:09:43 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Sep 13 08:48:31 2009 Subject: GHC bus error on Network.BSD.getHostByName In-Reply-To: <82A38370-4AB5-4C73-B5BF-4AC27D0EC32D@cs.uu.nl> References: <82A38370-4AB5-4C73-B5BF-4AC27D0EC32D@cs.uu.nl> Message-ID: <20090913130943.GA28718@matrix.chaos.earth.li> On Sun, Sep 13, 2009 at 02:49:43PM +0200, Sebastiaan Visser wrote: > > I'm using a Mac running Snow Leopard and GHC 6.10.4 from the MacOSX > platform installer together with network-2.2.1.4. Never had any problems > with this function before my upgrade to Snow Leopard. I can't reproduce it with an earlier OS X (using the GHC installer) either. > Should I file a bug or is this something already known? If there isn't already a ticket about it, then please file a bug in the network trac: http://trac.haskell.org/network/ Thanks Ian From duncan.coutts at worc.ox.ac.uk Mon Sep 14 14:56:43 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Sep 14 14:35:57 2009 Subject: Recommendation for the procedure to add platform packages In-Reply-To: <4AA647E2.9020200@gmail.com> References: <1250733860.9379.2142.camel@localhost> <4AA647E2.9020200@gmail.com> Message-ID: <1252954603.19215.251.camel@localhost> On Tue, 2009-09-08 at 13:02 +0100, Simon Marlow wrote: > > The main document contains: > > * the procedure itself, which is relatively short > > * a rationale, cross-linked to the procedure > > * a procedure to help us make decisions > > > > http://trac.haskell.org/haskell-platform/wiki/AddingPackages > > On the whole, +1. > > The process is quite detailed, so we shouldn't expect reviewers to be > familiar with all the rules; instead it's up to the steering committee > to guide the discussion and remind people of the administrative details > at each stage (e.g. "you have until X to respond, or we assume you > agree", or "this is the first phase, during which we are trying to reach > consensus on Z"). Right. I think that's fine. We'll all get the hang of it after the first round or so. > Specific comments: > > "come to view on whether the package should be accepted" > -> "help achieve a consensus ... " Ok. > "the libraries mailing list reach consensus to accept it" > -> "the reviewers reach a consensus to accept it" ? Ok. > "Compile on all operating systems and compilers that the platform targets" > -> ".. except where the package is compiler- or platform-specific" ? Right, we want language that lets us have platform-specific stuff where it's really essential but strongly encourage portable as the default. For example we've got the win32 and unix packages because they're there to expose the native platform apis. But for example if we added file change notification I expect we'd want to provide a platform independent api rather than three packages, one for each native api (or at least we'd want to provide something portable in addition to low level native apis). > The "Interim Licesne Policy" should be one of the bullet points > under Package Requirements. e.g. > > "The package must be distributed under an acceptable license. The > only license currently acceptable is BSD3 [rationale..]" Yes and no :-). I'll say that it must comply with the license policy. I've been trying very hard to avoid writing the sentence "the only license acceptable is BSD3" because it's highly misleading to say that. > I'd like to see something about API style mentioned in the "Package > Requirements". e.g.: > > Packages admitted to the platform should follow an API style > similar to those packages already in the package. While the > style guidelines for package APIs have not yet been written down, > we expect that to change in the future. That's for the discussion after we agree on the procedure. There are plenty more package requirements that we'll want to discuss. We've deliberately started with a minimal set because we wanted to separate the two discussions. Ok, so I'll check the above with someone else on the steering committee and update the document. Duncan From greg at gregorycollins.net Mon Sep 14 15:45:49 2009 From: greg at gregorycollins.net (Gregory Collins) Date: Mon Sep 14 15:24:34 2009 Subject: GHC bus error on Network.BSD.getHostByName In-Reply-To: <82A38370-4AB5-4C73-B5BF-4AC27D0EC32D@cs.uu.nl> (Sebastiaan Visser's message of "Sun, 13 Sep 2009 14:49:43 +0200") References: <82A38370-4AB5-4C73-B5BF-4AC27D0EC32D@cs.uu.nl> Message-ID: <877hw1e2du.fsf@gregorycollins.net> Sebastiaan Visser writes: > Hello all, > > Before I file a bug maybe someone might recognize the following error and knows > if I should blame GHC or someone at Apple. When trying to use the > Network.BSD.getHostByName function ghci exits with a bus error. The same thing > happens with ghc --make and runghc. > Hey Sebastiaan! Did you try "cabal install -O2 --global --reinstall network"? I haven't tried GHC on Snow Leopard yet, but there was a thread on haskell-cafe about which files you need to hack to tell Snow Leopard's tools to build/link/etc in 32-bit mode. I suspect that might be the issue here. G -- Gregory Collins From duncan.coutts at worc.ox.ac.uk Mon Sep 14 16:22:23 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Sep 14 16:48:21 2009 Subject: Recommendation for the procedure to add platform packages In-Reply-To: <4AA647E2.9020200@gmail.com> References: <1250733860.9379.2142.camel@localhost> <4AA647E2.9020200@gmail.com> Message-ID: <1252959743.19215.381.camel@localhost> On Tue, 2009-09-08 at 13:02 +0100, Simon Marlow wrote: > Specific comments: > > "come to view on whether the package should be accepted" > -> "help achieve a consensus ... " We decided to clarify it slightly differently to make clear the distinction between forming a view and working with others to get a consensus. - * come to view on whether the package should be accepted, either as-is or with certain modifications + * come to a view on whether the package should be accepted, either as-is or with certain modifications + * work with other reviewers to try to achieve a consensus view > "the libraries mailing list reach consensus to accept it" > -> "the reviewers reach a consensus to accept it" ? Changed as you suggested. It's simpler and means the same thing since everyone one the libs mailing list is considered as a reviewer. > "Compile on all operating systems and compilers that the platform targets" > -> ".. except where the package is compiler- or platform-specific" ? We decided not to list explicit exceptions on this point but to make clear the "should" status of all the requirements: Every package should fulfil the following requirements. Any requirements that are not met must be clearly explained and justified in the proposal. So for a platform-specific package you have to point it out in the proposal, justify it and have the reviewers agree with you. > The "Interim Licesne Policy" should be one of the bullet points > under Package Requirements. e.g. > > "The package must be distributed under an acceptable license. The > only license currently acceptable is BSD3 [rationale..]" Added to the requirements list: * Be distributed under an acceptable copyright license. See the interim license policy. So the changes as a whole are: http://trac.haskell.org/haskell-platform/wiki/AddingPackages?action=diff&version=9&old_version=5 Duncan From duncan.coutts at worc.ox.ac.uk Mon Sep 14 17:54:18 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Sep 14 17:34:03 2009 Subject: Haskell Platform package additions: decision time! Message-ID: <1252965258.19215.606.camel@localhost> All, About a month ago we came up with a recommendation for a procedure for adding new packages to the Haskell Platform. Initial announcement: http://haskell.org/pipermail/libraries/2009-August/012397.html Proposed policy: http://trac.haskell.org/haskell-platform/wiki/AddingPackages If you like the video format then see 7min:15sec into this talk (from the recent Haskell implementers' workshop) http://www.vimeo.com/6572504 We would like to get this wrapped up so that we can move on to discussing more guidelines/requirements on packages and indeed to actually proposing some packages. So far we have had a few people send in comments (thanks particularly to Ian and Simon) but a few more would not go amiss, even if it's just "yes". If you were following the original thread you'll remember that Ian has a few concerns that we've not yet fully resolved. I have suggestions for how to move forward. Feedback and opinions from other people would probably help. I'll set out what the concerns are and what I suggest. Two of the complaints we can deal with fairly easily, the third would be a more radical change from what we're proposing, but we can move a bit closer. First the two simple ones: Concern 1: "The policy document itself is too long and too detailed." Quick poll: should we split the rationale into a separate page or keep it on the same page? Yes or no. * Advantages: policy document looks shorter, less intimidating * Disadvantages: slower to jump back and forth between the policy and the rationale (the two are fully cross-referenced) If we split it, then the main page would look like this: http://trac.haskell.org/haskell-platform/wiki/AddingPackagesCore and the "[rationale-x.y]" links would point to a separate page. It really doesn't matter which we pick, we just need to decide and get on with it! Concern 2: "Documentation written for the proposal will get lost." The concern here is that if people write some new intro tutorial or something for a package proposal that this might never get integrated into the package's documentation. Ian's suggested remedy is to force proposals to link to existing documentation rather than letting proposal authors make something new or make a customised variation on existing docs. The principle that the steering committee seemed to agree on is that the proposal author be given the freedom to present their argument in whatever way they see fit. The alternative that I am proposing is this: in the case that completely new documentation is written for a proposal, there be a presumption that a condition of acceptance is that the new material be republished in the appropriate place and form. For example this might mean the reviewers require that new intro docs be integrated into the haddock docs or perhaps as a separate tutorial or user guide on the package's homepage. The point is that by attaching it as a condition of the package being accepted, that we ensure that it does actually get done rather than nice docs languishing where no users will find them. The policy already has the facility for conditional acceptance so this just adds a presumed condition. Concern 3. The more major and general complaint Ian has is that he believes the criteria for acceptance should be essentially a checklist. Some checklist items would be objective, some subjective, but passing them all would be sufficient for a package to be accepted. With this approach the proposal would also essentially be a checklist, noting that each one is met (with explanation as appropriate). By contrast, the criteria that the steering committee proposes is that a package is accepted if the reviewers reach consensus. That is, ultimately it is up to the judgement of the reviewers. This approach is augmented with a list of minimum package requirements to make it clearer what level package authors have to aim for. In the limit the two approaches are the same. By adding more and more package requirements and guidelines the grey area left up to the judgement of reviewers is reduced. Also, the checklist approach allows some items to be essentially "do the reviewers agree that ...", so it's still a judgement and a consensus but broken up into categories. Related to this issue is the concern that we will find it impossible to agree on any packages before we have agreed a more comprehensive set of package requirements. My argument is that we can make progress on both simultaneously, that is we can start discussing individual package proposals while also discussing general package requirements. Indeed I think the two discussions might inform each other. In the worst case we get blocked discussing a package because we do not agree on the level of some quality requirement, in which case we move to discussing general package requirements and record the decision in the policy. So my suggestion on this complaint is that we go with the policy that the steering committee has proposed and that we move quickly afterwards to discuss more comprehensive package requirements and guidelines. Duncan From niklas.broberg at gmail.com Mon Sep 14 18:36:24 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Mon Sep 14 18:15:07 2009 Subject: Haskell Platform package additions: decision time! In-Reply-To: <1252965258.19215.606.camel@localhost> References: <1252965258.19215.606.camel@localhost> Message-ID: > So far we have had a few people send in comments (thanks particularly to > Ian and Simon) but a few more would not go amiss, even if it's just > "yes". Yes. > Concern 1: "The policy document itself is too long and too detailed." > > Quick poll: should we split the rationale into a separate page or keep > it on the same page? Yes or no. What you asked was not a yes-no question :-p But I say split it to a separate page. > Concern 2: "Documentation written for the proposal will get lost." > [...] > > The alternative that I am proposing is this: in the case that > completely new documentation is written for a proposal, there be > a presumption that a condition of acceptance is that the new material be > republished in the appropriate place and form. I agree with this view. Having documentation in the proposal itself is nicer than just links, and your proposal deals with the issue that arises. > Concern 3. The more major and general complaint Ian has is that he > believes the criteria for acceptance should be essentially a checklist. > Some checklist items would be objective, some subjective, but passing > them all would be sufficient for a package to be accepted. With this > approach the proposal would also essentially be a checklist, noting that > each one is met (with explanation as appropriate). > > By contrast, the criteria that the steering committee proposes is that a > package is accepted if the reviewers reach consensus. That is, > ultimately it is up to the judgement of the reviewers. This approach is > augmented with a list of minimum package requirements to make it clearer > what level package authors have to aim for. I'm with the steering committee on this one. We simply don't have enough experience to draw on to be able to come up with an all-encompassing checklist. It may be that such a checklist will de facto emerge when we get the process rolling, but let's not try to fixate one initially. Cheers, /Niklas From dons at galois.com Mon Sep 14 22:46:18 2009 From: dons at galois.com (Don Stewart) Date: Mon Sep 14 22:27:19 2009 Subject: Haskell Platform package additions: decision time! In-Reply-To: <1252965258.19215.606.camel@localhost> References: <1252965258.19215.606.camel@localhost> Message-ID: <20090915024618.GB989@whirlpool.galois.com> duncan.coutts: > We would like to get this wrapped up so that we can move on to > discussing more guidelines/requirements on packages and indeed to > actually proposing some packages. > > So far we have had a few people send in comments (thanks particularly to > Ian and Simon) but a few more would not go amiss, even if it's just > "yes". Yes. Let's do this. > > Concern 1: "The policy document itself is too long and too detailed." > > Quick poll: should we split the rationale into a separate page or keep > it on the same page? Yes or no. > > * Advantages: policy document looks shorter, less intimidating > * Disadvantages: slower to jump back and forth between the policy > and the rationale (the two are fully cross-referenced) > If we split it, then the main page would look like this: > http://trac.haskell.org/haskell-platform/wiki/AddingPackagesCore > and the "[rationale-x.y]" links would point to a separate page. > > It really doesn't matter which we pick, we just need to decide and get > on with it! Doesn't matter. We can proceed anyway. > Concern 2: "Documentation written for the proposal will get lost." > > The concern here is that if people write some new intro tutorial or > something for a package proposal that this might never get integrated > into the package's documentation. > > Ian's suggested remedy is to force proposals to link to existing > documentation rather than letting proposal authors make something new or > make a customised variation on existing docs. > > The principle that the steering committee seemed to agree on is that the > proposal author be given the freedom to present their argument in > whatever way they see fit. > > The alternative that I am proposing is this: in the case that > completely new documentation is written for a proposal, there be > a presumption that a condition of acceptance is that the new material be > republished in the appropriate place and form. For example this might > mean the reviewers require that new intro docs be integrated into the > haddock docs or perhaps as a separate tutorial or user guide on the > package's homepage. The point is that by attaching it as a condition of > the package being accepted, that we ensure that it does actually get > done rather than nice docs languishing where no users will find them. > The policy already has the facility for conditional acceptance so this > just adds a presumed condition. My bet is that people will polish the documentation and do new releases once under review. This will improve the package. I don't mind if it isn't required. > Concern 3. The more major and general complaint Ian has is that he > believes the criteria for acceptance should be essentially a checklist. > Some checklist items would be objective, some subjective, but passing > them all would be sufficient for a package to be accepted. With this > approach the proposal would also essentially be a checklist, noting that > each one is met (with explanation as appropriate). > Acting will reveal to what degree we need a checklist. Let's act, and work this out later. -- Don From malcolm.wallace at cs.york.ac.uk Tue Sep 15 04:34:38 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Sep 15 04:13:22 2009 Subject: Haskell Platform package additions: decision time! In-Reply-To: <1252965258.19215.606.camel@localhost> References: <1252965258.19215.606.camel@localhost> Message-ID: <60F1D511-F378-4F61-8166-5DAC013983E3@cs.york.ac.uk> > So far we have had a few people send in comments (thanks > particularly to > Ian and Simon) but a few more would not go amiss, even if it's just > "yes". Basically, yes. > Concern 1: "The policy document itself is too long and too detailed." I must admit, I too did not read it fully, because it was intimidatingly long. In fact, it made me think "phew, thank goodness I didn't want to propose any of my packages for the platform!" > Quick poll: should we split the rationale into a separate page or keep > it on the same page? Yes or no. Definitely split off the rationale, and similarly, the "how to". (Actually, the latter seems to have already been split out, but there are remaining dangling pointers to the old in-page location.) > * Disadvantages: slower to jump back and forth between the policy > and the rationale (the two are fully cross-referenced) Suggestion: can the rationale be coded to come up in a separate browser window? (Especially if the links ensure that different rationale links come through to the _same_ target window.) I would find it helpful to be able to see policy + rationale side-by-side (although not intermingled). > Concern 2: "Documentation written for the proposal will get lost." > ... by attaching it as a condition of > the package being accepted, that we ensure that it does actually get > done rather than nice docs languishing where no users will find them. My question is who enforces this, and how? > Concern 3. The more major and general complaint Ian has is that he > believes the criteria for acceptance should be essentially a > checklist. > So my suggestion on this complaint is that we go with the policy that > the steering committee has proposed and that we move quickly > afterwards > to discuss more comprehensive package requirements and guidelines. If the aim is gradually to formalise a checklist, by first examining the packages we want in the platform, then abstracting the characteristics that make them desirable, then it sounds fine. Perhaps the _goal_ of forming an incomplete checklist should be explicit in the first few rounds of package consideration. Ultimately, I think package proposers will benefit from having a clear statement of what they must do to improve their package's "fitness". Regards, Malcolm From marlowsd at gmail.com Tue Sep 15 06:33:06 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Sep 15 06:11:50 2009 Subject: Haskell Platform package additions: decision time! In-Reply-To: References: <1252965258.19215.606.camel@localhost> Message-ID: <4AAF6D62.6060301@gmail.com> On 14/09/2009 23:36, Niklas Broberg wrote: >> So far we have had a few people send in comments (thanks particularly to >> Ian and Simon) but a few more would not go amiss, even if it's just >> "yes". > > Yes. > >> Concern 1: "The policy document itself is too long and too detailed." >> >> Quick poll: should we split the rationale into a separate page or keep >> it on the same page? Yes or no. > > What you asked was not a yes-no question :-p > But I say split it to a separate page. > >> Concern 2: "Documentation written for the proposal will get lost." >> [...] >> >> The alternative that I am proposing is this: in the case that >> completely new documentation is written for a proposal, there be >> a presumption that a condition of acceptance is that the new material be >> republished in the appropriate place and form. > > I agree with this view. Having documentation in the proposal itself is > nicer than just links, and your proposal deals with the issue that > arises. > >> Concern 3. The more major and general complaint Ian has is that he >> believes the criteria for acceptance should be essentially a checklist. >> Some checklist items would be objective, some subjective, but passing >> them all would be sufficient for a package to be accepted. With this >> approach the proposal would also essentially be a checklist, noting that >> each one is met (with explanation as appropriate). >> >> By contrast, the criteria that the steering committee proposes is that a >> package is accepted if the reviewers reach consensus. That is, >> ultimately it is up to the judgement of the reviewers. This approach is >> augmented with a list of minimum package requirements to make it clearer >> what level package authors have to aim for. > > I'm with the steering committee on this one. We simply don't have > enough experience to draw on to be able to come up with an > all-encompassing checklist. It may be that such a checklist will de > facto emerge when we get the process rolling, but let's not try to > fixate one initially. Well, a first cut at the checklist could be * Do the reviewers agree that the package is suitable for inclusion in the platform? and then we can refine it later :) I basically agree with Duncan's points. The main advantages of a checklist are that it helps organise the discussion and reminds people what points are yet to be agreed upon. The problem with trying to come up with a checklist first is that we don't have a clear idea what should be in it, and we're in danger of spending too much time figuring out what the requirements should be without considering any actual proposals. So let's get started with reviewing package proposals and simultaneously refine the list of requirements. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Tue Sep 15 09:44:53 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Sep 15 09:33:56 2009 Subject: Haskell Platform package additions: decision time! In-Reply-To: <60F1D511-F378-4F61-8166-5DAC013983E3@cs.york.ac.uk> References: <1252965258.19215.606.camel@localhost> <60F1D511-F378-4F61-8166-5DAC013983E3@cs.york.ac.uk> Message-ID: <1253022293.19215.1602.camel@localhost> On Tue, 2009-09-15 at 09:34 +0100, Malcolm Wallace wrote: > > So far we have had a few people send in comments (thanks > > particularly to > > Ian and Simon) but a few more would not go amiss, even if it's just > > "yes". > > Basically, yes. > > > Concern 1: "The policy document itself is too long and too detailed." > > I must admit, I too did not read it fully, because it was > intimidatingly long. In fact, it made me think "phew, thank goodness > I didn't want to propose any of my packages for the platform!" > > > Quick poll: should we split the rationale into a separate page or keep > > it on the same page? Yes or no. > > Definitely split off the rationale, Seems like this is the majority opinion. If it is actually putting people off then that's certainly a good reason to split. The procedure is not very complicated, the policy is just fairly detailed and, I hope, fairly clear. We were trying to anticipate questions and corner cases. > and similarly, the "how to". (Actually, the latter seems to have > already been split out, but there are remaining dangling pointers to > the old in-page location.) Fixed the broken link, thanks. > > * Disadvantages: slower to jump back and forth between the policy > > and the rationale (the two are fully cross-referenced) > > Suggestion: can the rationale be coded to come up in a separate > browser window? (Especially if the links ensure that different > rationale links come through to the _same_ target window.) I would > find it helpful to be able to see policy + rationale side-by-side > (although not intermingled). I've no idea how to do that in the trac wiki markup. If anyone knows please say so. > > Concern 2: "Documentation written for the proposal will get lost." > > ... by attaching it as a condition of > > the package being accepted, that we ensure that it does actually get > > done rather than nice docs languishing where no users will find them. > > My question is who enforces this, and how? The how is by making it a condition of acceptance for the package. The policy describes conditional acceptance: A package is considered as conditionally accepted if, by the discussion deadline, the libraries mailing list reaches consensus to accept it on condition that further minor changes are made. The agreed changes must be made before the package is included in any release. If these changes are made in time for the normal package freeze dates (as set by the release team) then the package is considered as accepted. If the changes cannot be made in time for the immediate major release but are made in time for the subsequent major release then the package is considered as accepted for that subsequent major release and does not need to be re-reviewed. As for who would suggest making it a condition in any particular case, well any reviewer or member of the steering committee. If people complain that it's an unnecessary condition then we point to the section of the policy (as yet unwritten) that says it's a presumed condition. Sound like enough? > > Concern 3. The more major and general complaint Ian has is that he > > believes the criteria for acceptance should be essentially a > > checklist. > > > So my suggestion on this complaint is that we go with the policy that > > the steering committee has proposed and that we move quickly > > afterwards > > to discuss more comprehensive package requirements and guidelines. > > If the aim is gradually to formalise a checklist, by first examining > the packages we want in the platform, then abstracting the > characteristics that make them desirable, then it sounds fine. > Perhaps the _goal_ of forming an incomplete checklist should be > explicit in the first few rounds of package consideration. Sure, we can make that clear. > Ultimately, I think package proposers will benefit from having a clear > statement of what they must do to improve their package's "fitness". Indeed. We want to get to the stage where maintainers can do much of the assessment themselves before even getting to the review stage. Duncan From dilinger at collabora.co.uk Tue Sep 15 12:00:23 2009 From: dilinger at collabora.co.uk (Andres Salomon) Date: Tue Sep 15 11:43:44 2009 Subject: darcs patch: haskell-x11: add and export the list of cursors Message-ID: <20090915120023.7cf23599@mycelium.queued.net> Tue Sep 15 11:57:08 EDT 2009 Andres Salomon * haskell-x11: add and export the list of cursors Pulled in from X11/cursorfont.h, export things like xC_X_cursor and xC_left_ptr for things like createFontCursor to use. New patches: [haskell-x11: add and export the list of cursors Andres Salomon **20090915155708 Ignore-this: 995cede8cdd8830a2c0bb6c63b8229b9 Pulled in from X11/cursorfont.h, export things like xC_X_cursor and xC_left_ptr for things like createFontCursor to use. ] { addfile ./Graphics/X11/Xlib/Cursor.hsc hunk ./Graphics/X11/Xlib/Cursor.hsc 1 +----------------------------------------------------------------------------- +-- | +-- Module : Graphics.X11.Xlib.Cursor +-- Copyright : (C) Collabora Ltd 2009 +-- License : BSD-style (see the file libraries/base/LICENSE) +-- +-- Maintainer : libraries@haskell.org +-- Stability : provisional +-- Portability : portable +-- +-- A collection of cursor types defined by /usr/include/X11/cursorfont.h. +-- +----------------------------------------------------------------------------- + +module Graphics.X11.Xlib.Cursor( + + xC_X_cursor, + xC_arrow, + xC_based_arrow_down, + xC_based_arrow_up, + xC_boat, + xC_bogosity, + xC_bottom_left_corner, + xC_bottom_right_corner, + xC_bottom_side, + xC_bottom_tee, + xC_box_spiral, + xC_center_ptr, + xC_circle, + xC_clock, + xC_coffee_mug, + xC_cross, + xC_cross_reverse, + xC_crosshair, + xC_diamond_cross, + xC_dot, + xC_dotbox, + xC_double_arrow, + xC_draft_large, + xC_draft_small, + xC_draped_box, + xC_exchange, + xC_fleur, + xC_gobbler, + xC_gumby, + xC_hand1, + xC_hand2, + xC_heart, + xC_icon, + xC_iron_cross, + xC_left_ptr, + xC_left_side, + xC_left_tee, + xC_leftbutton, + xC_ll_angle, + xC_lr_angle, + xC_man, + xC_mouse, + xC_pencil, + xC_pirate, + xC_plus, + xC_question_arrow, + xC_right_ptr, + xC_right_side, + xC_right_tee, + xC_rightbutton, + xC_rtl_logo, + xC_sailboat, + xC_sb_down_arrow, + xC_sb_h_double_arrow, + xC_sb_left_arrow, + xC_sb_right_arrow, + xC_sb_up_arrow, + xC_sb_v_double_arrow, + xC_shuttle, + xC_sizing, + xC_spider, + xC_spraycan, + xC_star, + xC_target, + xC_tcross, + xC_top_left_arrow, + xC_top_left_corner, + xC_top_right_corner, + xC_top_side, + xC_top_tee, + xC_trek, + xC_ul_angle, + xC_umbrella, + xC_ur_angle, + xC_watch, + xC_xterm, + + ) where + +import Graphics.X11.Xlib.Font + +---------------------------------------------------------------- +-- Cursors +---------------------------------------------------------------- + +#include "HsXlib.h" + +xC_X_cursor :: Glyph +xC_X_cursor = #const XC_X_cursor + +xC_arrow :: Glyph +xC_arrow = #const XC_arrow + +xC_based_arrow_down :: Glyph +xC_based_arrow_down = #const XC_based_arrow_down + +xC_based_arrow_up :: Glyph +xC_based_arrow_up = #const XC_based_arrow_up + +xC_boat :: Glyph +xC_boat = #const XC_boat + +xC_bogosity :: Glyph +xC_bogosity = #const XC_bogosity + +xC_bottom_left_corner :: Glyph +xC_bottom_left_corner = #const XC_bottom_left_corner + +xC_bottom_right_corner :: Glyph +xC_bottom_right_corner = #const XC_bottom_right_corner + +xC_bottom_side :: Glyph +xC_bottom_side = #const XC_bottom_side + +xC_bottom_tee :: Glyph +xC_bottom_tee = #const XC_bottom_tee + +xC_box_spiral :: Glyph +xC_box_spiral = #const XC_box_spiral + +xC_center_ptr :: Glyph +xC_center_ptr = #const XC_center_ptr + +xC_circle :: Glyph +xC_circle = #const XC_circle + +xC_clock :: Glyph +xC_clock = #const XC_clock + +xC_coffee_mug :: Glyph +xC_coffee_mug = #const XC_coffee_mug + +xC_cross :: Glyph +xC_cross = #const XC_cross + +xC_cross_reverse :: Glyph +xC_cross_reverse = #const XC_cross_reverse + +xC_crosshair :: Glyph +xC_crosshair = #const XC_crosshair + +xC_diamond_cross :: Glyph +xC_diamond_cross = #const XC_diamond_cross + +xC_dot :: Glyph +xC_dot = #const XC_dot + +xC_dotbox :: Glyph +xC_dotbox = #const XC_dotbox + +xC_double_arrow :: Glyph +xC_double_arrow = #const XC_double_arrow + +xC_draft_large :: Glyph +xC_draft_large = #const XC_draft_large + +xC_draft_small :: Glyph +xC_draft_small = #const XC_draft_small + +xC_draped_box :: Glyph +xC_draped_box = #const XC_draped_box + +xC_exchange :: Glyph +xC_exchange = #const XC_exchange + +xC_fleur :: Glyph +xC_fleur = #const XC_fleur + +xC_gobbler :: Glyph +xC_gobbler = #const XC_gobbler + +xC_gumby :: Glyph +xC_gumby = #const XC_gumby + +xC_hand1 :: Glyph +xC_hand1 = #const XC_hand1 + +xC_hand2 :: Glyph +xC_hand2 = #const XC_hand2 + +xC_heart :: Glyph +xC_heart = #const XC_heart + +xC_icon :: Glyph +xC_icon = #const XC_icon + +xC_iron_cross :: Glyph +xC_iron_cross = #const XC_iron_cross + +xC_left_ptr :: Glyph +xC_left_ptr = #const XC_left_ptr + +xC_left_side :: Glyph +xC_left_side = #const XC_left_side + +xC_left_tee :: Glyph +xC_left_tee = #const XC_left_tee + +xC_leftbutton :: Glyph +xC_leftbutton = #const XC_leftbutton + +xC_ll_angle :: Glyph +xC_ll_angle = #const XC_ll_angle + +xC_lr_angle :: Glyph +xC_lr_angle = #const XC_lr_angle + +xC_man :: Glyph +xC_man = #const XC_man + +xC_middlebutton :: Glyph +xC_middlebutton = #const XC_middlebutton + +xC_mouse :: Glyph +xC_mouse = #const XC_mouse + +xC_pencil :: Glyph +xC_pencil = #const XC_pencil + +xC_pirate :: Glyph +xC_pirate = #const XC_pirate + +xC_plus :: Glyph +xC_plus = #const XC_plus + +xC_question_arrow :: Glyph +xC_question_arrow = #const XC_question_arrow + +xC_right_ptr :: Glyph +xC_right_ptr = #const XC_right_ptr + +xC_right_side :: Glyph +xC_right_side = #const XC_right_side + +xC_right_tee :: Glyph +xC_right_tee = #const XC_right_tee + +xC_rightbutton :: Glyph +xC_rightbutton = #const XC_rightbutton + +xC_rtl_logo :: Glyph +xC_rtl_logo = #const XC_rtl_logo + +xC_sailboat :: Glyph +xC_sailboat = #const XC_sailboat + +xC_sb_down_arrow :: Glyph +xC_sb_down_arrow = #const XC_sb_down_arrow + +xC_sb_h_double_arrow :: Glyph +xC_sb_h_double_arrow = #const XC_sb_h_double_arrow + +xC_sb_left_arrow :: Glyph +xC_sb_left_arrow = #const XC_sb_left_arrow + +xC_sb_right_arrow :: Glyph +xC_sb_right_arrow = #const XC_sb_right_arrow + +xC_sb_up_arrow :: Glyph +xC_sb_up_arrow = #const XC_sb_up_arrow + +xC_sb_v_double_arrow :: Glyph +xC_sb_v_double_arrow = #const XC_sb_v_double_arrow + +xC_shuttle :: Glyph +xC_shuttle = #const XC_shuttle + +xC_sizing :: Glyph +xC_sizing = #const XC_sizing + +xC_spider :: Glyph +xC_spider = #const XC_spider + +xC_spraycan :: Glyph +xC_spraycan = #const XC_spraycan + +xC_star :: Glyph +xC_star = #const XC_star + +xC_target :: Glyph +xC_target = #const XC_target + +xC_tcross :: Glyph +xC_tcross = #const XC_tcross + +xC_top_left_arrow :: Glyph +xC_top_left_arrow = #const XC_top_left_arrow + +xC_top_left_corner :: Glyph +xC_top_left_corner = #const XC_top_left_corner + +xC_top_right_corner :: Glyph +xC_top_right_corner = #const XC_top_right_corner + +xC_top_side :: Glyph +xC_top_side = #const XC_top_side + +xC_top_tee :: Glyph +xC_top_tee = #const XC_top_tee + +xC_trek :: Glyph +xC_trek = #const XC_trek + +xC_ul_angle :: Glyph +xC_ul_angle = #const XC_ul_angle + +xC_umbrella :: Glyph +xC_umbrella = #const XC_umbrella + +xC_ur_angle :: Glyph +xC_ur_angle = #const XC_ur_angle + +xC_watch :: Glyph +xC_watch = #const XC_watch + +xC_xterm :: Glyph +xC_xterm = #const XC_xterm + +---------------------------------------------------------------- +-- End +---------------------------------------------------------------- hunk ./Makefile.nhc98 12 Graphics/X11/Xlib/Atom.hsc \ Graphics/X11/Xlib/Color.hs \ Graphics/X11/Xlib/Context.hs \ + Graphics/X11/Xlib/Cursor.hsc \ Graphics/X11/Xlib/Display.hs \ Graphics/X11/Xlib/Event.hsc \ Graphics/X11/Xlib/Font.hsc \ hunk ./X11.cabal 31 Graphics.X11.Xlib.Atom, Graphics.X11.Xlib.Color, Graphics.X11.Xlib.Context, + Graphics.X11.Xlib.Cursor, Graphics.X11.Xlib.Display, Graphics.X11.Xlib.Event, Graphics.X11.Xlib.Font, hunk ./configure.ac 118 if ! test "$have_keysymdef" = yes; then echo "WARNING: Couldn't find for X.org keysyms" fi + + AC_CHECK_HEADERS([X11/cursorfont.h], [have_cursorfont=yes]) + if ! test "$have_cursorfont" = yes; then + AC_MSG_ERROR([X11/cursorfont.h (from libx11) is required]) + fi fi hunk ./include/HsXlib.h 40 #define XK_LATIN1 #include +#include + /* This error handler is used from FFI code. * It generates a slightly better error message than the one * that comes with Xlib. } Context: [TAG 1.4.5 Spencer Janssen **20081203050348 Ignore-this: d8112e4ff25ec56fe5ac2cdc9fa1ead ] [Bump version to 1.4.5 Spencer Janssen **20081203050251 Ignore-this: 665f8093d82bef9e6b13bf1e4db74e1d ] [Bump configure.ac to 1.4.4 as well Spencer Janssen **20081203050154 Ignore-this: ef3fabf26fc7dbfdb6dfaa92073e3c9e ] [Fix memory leak in getWMHints Spencer Janssen **20081125221512 Ignore-this: dacc19acbb60e13d945509cde0551bc8 ] [more precise X11 deps Don Stewart **20081011211930] [TAG 1.4.3 Spencer Janssen **20080921082528] [Bump version to 1.4.3 Spencer Janssen **20080921054954] [getCommand Marco T?lio Gontijo e Silva **20080712154521] [X implementation dependent keysyms from X.org zythmer@gmail.com**20080528004224 Added all of the X keysyms from X.org except the groups XK_MISCELLANY and XK_LATIN1 as well as skipped XK_VoidSymbol since it is not in any group. The above groups and symbol are already in Graphics.X11.Types ] [Make sure both --with-xinerama and --without-xinerama works Lennart Kolmodin **20080524112224 Use the builtin variable with_xinerama instead of our want_xinerama. This gives us ability to use both --with-xinerama and --without-xinerama. ] [Use -auto-all when profiling Don Stewart **20080413112039] [Update configure.ac with new version number Lennart Kolmodin **20080331184021] [Add setKeyEvent to Graphics.X11.Xlib.Extras J?r?my Bobbio **20080328214753] [TAG 1.4.2 Spencer Janssen **20080327193813] [Bump version number to 1.4.2 Spencer Janssen **20080327193755] [Handle a NULL retrun from XGetWMHints correctly, fixes a segfault bug Spencer Janssen **20080327192702] [update version info Don Stewart **20080307190921] [comments Don Stewart **20080307190910] [Remove -O2 from ghc-options Spencer Janssen **20071216001612] [TAG 1.4.1 Spencer Janssen **20071211042441] [Bump version to 1.4.1 Spencer Janssen **20071211042430] [Check the return value of XGetWindowProperty, this fixes crash bugs when the requested Window/Property does not exist Spencer Janssen **20071211041940] [Update installation instructions to use newer Cabal's --configure-option Alec Berryman **20071120214634] [Remove obsolete INSTALL file; installation instructions are in README Alec Berryman **20071120203353] [Remove redundant XIconifyWindow binding Spencer Janssen **20071208084849] [Added haddock docs to setErrorHandler; added XIconifyWindow and XMapRaised bindings hoelz@wisc.edu**20071202043806] [use a working header file for XSetErrorHandler Lukas Mai **20071129174529] [Implemented a full binding to XSetErrorHandler hoelz@wisc.edu**20071127011847] [TAG 1.4.0 Don Stewart **20071125032528] [bump X11 version to 1.4.0 Don Stewart **20071125032135] [add copyright info and year for Graphics/X11/Xlib/Extras.hsc Don Stewart **20071121024752] [bump to snapshot tag Don Stewart **20071111200531] [Fix bug in the type of functions dealing with properties Mats Jansborg **20071101190154 The documentation for XGetWindowProperty and XChangeProperty states that the data must be represented as an array of char, short and long for a format of 8, 16 and 32 respectively. Previously Word8, Word16 and Word32 were used, resulting in bugs on platforms where char is not 8 bits, short 16 bits and long 32 bits wide. ] [home instead of $USER Don Stewart **20071101212016] [space in CPPFLAGS will break .buildinfo file Don Stewart **20071031172720] [add CPPFLAGS and LDFLAGS to buildinfo file Don Stewart **20071031172436] [formatting Don Stewart **20071031171257] [license header for Xinerama Don Stewart **20071031165900] [untabify Don Stewart **20071031165743] [#!-able Setup.lhs Don Stewart *-20071030173235] [bump version Don Stewart **20071030213949] [Bump version number Ian Lynagh **20071027124814] [#!-able Setup.lhs Don Stewart **20071030173235] [TAG X11-1.3.0 Don Stewart **20071030172832] [wall police Don Stewart **20071030171430] [cabal tweaks Don Stewart **20071030171341] [wall police Don Stewart **20071029205511] [Bug fix: not storing height in XSizeHints.resize_inc Don Stewart **20071029202844] [-Wall police Don Stewart **20071029202542] [clean up warnings Don Stewart **20071029201214] [wrong header included, hidden by -fasm Don Stewart **20071029184208] [no .lhs Setup script Don Stewart **20071029183618] [Xutils.h -> Xutil.hs Don Stewart **20071029183435] [more info in readme Don Stewart **20071029182528] [more typos in the merged .cabal file Don Stewart **20071029182349] [duplicate line in .cabal file Don Stewart **20071029181942] [Merge in X11-extras package, bump to 1.3.0. Adds Xinerama and X event support. Don Stewart **20071029175855] [TAG 1.2.3 Don Stewart **20071012181748] Patch bundle hash: c2047a1dad296b9bf634a852c71d6e5002226576 From dons at galois.com Tue Sep 15 12:15:45 2009 From: dons at galois.com (Don Stewart) Date: Tue Sep 15 11:56:43 2009 Subject: darcs patch: haskell-x11: add and export the list of cursors In-Reply-To: <20090915120023.7cf23599@mycelium.queued.net> References: <20090915120023.7cf23599@mycelium.queued.net> Message-ID: <20090915161545.GA3902@whirlpool.galois.com> Applied: http://darcs.haskell.org/X11/ We can do a release if you do some testing :) dilinger: > Tue Sep 15 11:57:08 EDT 2009 Andres Salomon > * haskell-x11: add and export the list of cursors > > Pulled in from X11/cursorfont.h, export things like xC_X_cursor and > xC_left_ptr for things like createFontCursor to use. > > > New patches: > > [haskell-x11: add and export the list of cursors > Andres Salomon **20090915155708 > Ignore-this: 995cede8cdd8830a2c0bb6c63b8229b9 > > Pulled in from X11/cursorfont.h, export things like xC_X_cursor and > xC_left_ptr for things like createFontCursor to use. > > ] { > addfile ./Graphics/X11/Xlib/Cursor.hsc > hunk ./Graphics/X11/Xlib/Cursor.hsc 1 > +----------------------------------------------------------------------------- > +-- | > +-- Module : Graphics.X11.Xlib.Cursor > +-- Copyright : (C) Collabora Ltd 2009 > +-- License : BSD-style (see the file libraries/base/LICENSE) > +-- > +-- Maintainer : libraries@haskell.org > +-- Stability : provisional > +-- Portability : portable > +-- > +-- A collection of cursor types defined by /usr/include/X11/cursorfont.h. > +-- > +----------------------------------------------------------------------------- > + > +module Graphics.X11.Xlib.Cursor( > + > + xC_X_cursor, > + xC_arrow, > + xC_based_arrow_down, > + xC_based_arrow_up, > + xC_boat, > + xC_bogosity, > + xC_bottom_left_corner, > + xC_bottom_right_corner, > + xC_bottom_side, > + xC_bottom_tee, > + xC_box_spiral, > + xC_center_ptr, > + xC_circle, > + xC_clock, > + xC_coffee_mug, > + xC_cross, > + xC_cross_reverse, > + xC_crosshair, > + xC_diamond_cross, > + xC_dot, > + xC_dotbox, > + xC_double_arrow, > + xC_draft_large, > + xC_draft_small, > + xC_draped_box, > + xC_exchange, > + xC_fleur, > + xC_gobbler, > + xC_gumby, > + xC_hand1, > + xC_hand2, > + xC_heart, > + xC_icon, > + xC_iron_cross, > + xC_left_ptr, > + xC_left_side, > + xC_left_tee, > + xC_leftbutton, > + xC_ll_angle, > + xC_lr_angle, > + xC_man, > + xC_mouse, > + xC_pencil, > + xC_pirate, > + xC_plus, > + xC_question_arrow, > + xC_right_ptr, > + xC_right_side, > + xC_right_tee, > + xC_rightbutton, > + xC_rtl_logo, > + xC_sailboat, > + xC_sb_down_arrow, > + xC_sb_h_double_arrow, > + xC_sb_left_arrow, > + xC_sb_right_arrow, > + xC_sb_up_arrow, > + xC_sb_v_double_arrow, > + xC_shuttle, > + xC_sizing, > + xC_spider, > + xC_spraycan, > + xC_star, > + xC_target, > + xC_tcross, > + xC_top_left_arrow, > + xC_top_left_corner, > + xC_top_right_corner, > + xC_top_side, > + xC_top_tee, > + xC_trek, > + xC_ul_angle, > + xC_umbrella, > + xC_ur_angle, > + xC_watch, > + xC_xterm, > + > + ) where > + > +import Graphics.X11.Xlib.Font > + > +---------------------------------------------------------------- > +-- Cursors > +---------------------------------------------------------------- > + > +#include "HsXlib.h" > + > +xC_X_cursor :: Glyph > +xC_X_cursor = #const XC_X_cursor > + > +xC_arrow :: Glyph > +xC_arrow = #const XC_arrow > + > +xC_based_arrow_down :: Glyph > +xC_based_arrow_down = #const XC_based_arrow_down > + > +xC_based_arrow_up :: Glyph > +xC_based_arrow_up = #const XC_based_arrow_up > + > +xC_boat :: Glyph > +xC_boat = #const XC_boat > + > +xC_bogosity :: Glyph > +xC_bogosity = #const XC_bogosity > + > +xC_bottom_left_corner :: Glyph > +xC_bottom_left_corner = #const XC_bottom_left_corner > + > +xC_bottom_right_corner :: Glyph > +xC_bottom_right_corner = #const XC_bottom_right_corner > + > +xC_bottom_side :: Glyph > +xC_bottom_side = #const XC_bottom_side > + > +xC_bottom_tee :: Glyph > +xC_bottom_tee = #const XC_bottom_tee > + > +xC_box_spiral :: Glyph > +xC_box_spiral = #const XC_box_spiral > + > +xC_center_ptr :: Glyph > +xC_center_ptr = #const XC_center_ptr > + > +xC_circle :: Glyph > +xC_circle = #const XC_circle > + > +xC_clock :: Glyph > +xC_clock = #const XC_clock > + > +xC_coffee_mug :: Glyph > +xC_coffee_mug = #const XC_coffee_mug > + > +xC_cross :: Glyph > +xC_cross = #const XC_cross > + > +xC_cross_reverse :: Glyph > +xC_cross_reverse = #const XC_cross_reverse > + > +xC_crosshair :: Glyph > +xC_crosshair = #const XC_crosshair > + > +xC_diamond_cross :: Glyph > +xC_diamond_cross = #const XC_diamond_cross > + > +xC_dot :: Glyph > +xC_dot = #const XC_dot > + > +xC_dotbox :: Glyph > +xC_dotbox = #const XC_dotbox > + > +xC_double_arrow :: Glyph > +xC_double_arrow = #const XC_double_arrow > + > +xC_draft_large :: Glyph > +xC_draft_large = #const XC_draft_large > + > +xC_draft_small :: Glyph > +xC_draft_small = #const XC_draft_small > + > +xC_draped_box :: Glyph > +xC_draped_box = #const XC_draped_box > + > +xC_exchange :: Glyph > +xC_exchange = #const XC_exchange > + > +xC_fleur :: Glyph > +xC_fleur = #const XC_fleur > + > +xC_gobbler :: Glyph > +xC_gobbler = #const XC_gobbler > + > +xC_gumby :: Glyph > +xC_gumby = #const XC_gumby > + > +xC_hand1 :: Glyph > +xC_hand1 = #const XC_hand1 > + > +xC_hand2 :: Glyph > +xC_hand2 = #const XC_hand2 > + > +xC_heart :: Glyph > +xC_heart = #const XC_heart > + > +xC_icon :: Glyph > +xC_icon = #const XC_icon > + > +xC_iron_cross :: Glyph > +xC_iron_cross = #const XC_iron_cross > + > +xC_left_ptr :: Glyph > +xC_left_ptr = #const XC_left_ptr > + > +xC_left_side :: Glyph > +xC_left_side = #const XC_left_side > + > +xC_left_tee :: Glyph > +xC_left_tee = #const XC_left_tee > + > +xC_leftbutton :: Glyph > +xC_leftbutton = #const XC_leftbutton > + > +xC_ll_angle :: Glyph > +xC_ll_angle = #const XC_ll_angle > + > +xC_lr_angle :: Glyph > +xC_lr_angle = #const XC_lr_angle > + > +xC_man :: Glyph > +xC_man = #const XC_man > + > +xC_middlebutton :: Glyph > +xC_middlebutton = #const XC_middlebutton > + > +xC_mouse :: Glyph > +xC_mouse = #const XC_mouse > + > +xC_pencil :: Glyph > +xC_pencil = #const XC_pencil > + > +xC_pirate :: Glyph > +xC_pirate = #const XC_pirate > + > +xC_plus :: Glyph > +xC_plus = #const XC_plus > + > +xC_question_arrow :: Glyph > +xC_question_arrow = #const XC_question_arrow > + > +xC_right_ptr :: Glyph > +xC_right_ptr = #const XC_right_ptr > + > +xC_right_side :: Glyph > +xC_right_side = #const XC_right_side > + > +xC_right_tee :: Glyph > +xC_right_tee = #const XC_right_tee > + > +xC_rightbutton :: Glyph > +xC_rightbutton = #const XC_rightbutton > + > +xC_rtl_logo :: Glyph > +xC_rtl_logo = #const XC_rtl_logo > + > +xC_sailboat :: Glyph > +xC_sailboat = #const XC_sailboat > + > +xC_sb_down_arrow :: Glyph > +xC_sb_down_arrow = #const XC_sb_down_arrow > + > +xC_sb_h_double_arrow :: Glyph > +xC_sb_h_double_arrow = #const XC_sb_h_double_arrow > + > +xC_sb_left_arrow :: Glyph > +xC_sb_left_arrow = #const XC_sb_left_arrow > + > +xC_sb_right_arrow :: Glyph > +xC_sb_right_arrow = #const XC_sb_right_arrow > + > +xC_sb_up_arrow :: Glyph > +xC_sb_up_arrow = #const XC_sb_up_arrow > + > +xC_sb_v_double_arrow :: Glyph > +xC_sb_v_double_arrow = #const XC_sb_v_double_arrow > + > +xC_shuttle :: Glyph > +xC_shuttle = #const XC_shuttle > + > +xC_sizing :: Glyph > +xC_sizing = #const XC_sizing > + > +xC_spider :: Glyph > +xC_spider = #const XC_spider > + > +xC_spraycan :: Glyph > +xC_spraycan = #const XC_spraycan > + > +xC_star :: Glyph > +xC_star = #const XC_star > + > +xC_target :: Glyph > +xC_target = #const XC_target > + > +xC_tcross :: Glyph > +xC_tcross = #const XC_tcross > + > +xC_top_left_arrow :: Glyph > +xC_top_left_arrow = #const XC_top_left_arrow > + > +xC_top_left_corner :: Glyph > +xC_top_left_corner = #const XC_top_left_corner > + > +xC_top_right_corner :: Glyph > +xC_top_right_corner = #const XC_top_right_corner > + > +xC_top_side :: Glyph > +xC_top_side = #const XC_top_side > + > +xC_top_tee :: Glyph > +xC_top_tee = #const XC_top_tee > + > +xC_trek :: Glyph > +xC_trek = #const XC_trek > + > +xC_ul_angle :: Glyph > +xC_ul_angle = #const XC_ul_angle > + > +xC_umbrella :: Glyph > +xC_umbrella = #const XC_umbrella > + > +xC_ur_angle :: Glyph > +xC_ur_angle = #const XC_ur_angle > + > +xC_watch :: Glyph > +xC_watch = #const XC_watch > + > +xC_xterm :: Glyph > +xC_xterm = #const XC_xterm > + > +---------------------------------------------------------------- > +-- End > +---------------------------------------------------------------- > hunk ./Makefile.nhc98 12 > Graphics/X11/Xlib/Atom.hsc \ > Graphics/X11/Xlib/Color.hs \ > Graphics/X11/Xlib/Context.hs \ > + Graphics/X11/Xlib/Cursor.hsc \ > Graphics/X11/Xlib/Display.hs \ > Graphics/X11/Xlib/Event.hsc \ > Graphics/X11/Xlib/Font.hsc \ > hunk ./X11.cabal 31 > Graphics.X11.Xlib.Atom, > Graphics.X11.Xlib.Color, > Graphics.X11.Xlib.Context, > + Graphics.X11.Xlib.Cursor, > Graphics.X11.Xlib.Display, > Graphics.X11.Xlib.Event, > Graphics.X11.Xlib.Font, > hunk ./configure.ac 118 > if ! test "$have_keysymdef" = yes; then > echo "WARNING: Couldn't find for X.org keysyms" > fi > + > + AC_CHECK_HEADERS([X11/cursorfont.h], [have_cursorfont=yes]) > + if ! test "$have_cursorfont" = yes; then > + AC_MSG_ERROR([X11/cursorfont.h (from libx11) is required]) > + fi > fi > > > hunk ./include/HsXlib.h 40 > #define XK_LATIN1 > #include > > +#include > + > /* This error handler is used from FFI code. > * It generates a slightly better error message than the one > * that comes with Xlib. > } > > Context: > > [TAG 1.4.5 > Spencer Janssen **20081203050348 > Ignore-this: d8112e4ff25ec56fe5ac2cdc9fa1ead > ] > [Bump version to 1.4.5 > Spencer Janssen **20081203050251 > Ignore-this: 665f8093d82bef9e6b13bf1e4db74e1d > ] > [Bump configure.ac to 1.4.4 as well > Spencer Janssen **20081203050154 > Ignore-this: ef3fabf26fc7dbfdb6dfaa92073e3c9e > ] > [Fix memory leak in getWMHints > Spencer Janssen **20081125221512 > Ignore-this: dacc19acbb60e13d945509cde0551bc8 > ] > [more precise X11 deps > Don Stewart **20081011211930] > [TAG 1.4.3 > Spencer Janssen **20080921082528] > [Bump version to 1.4.3 > Spencer Janssen **20080921054954] > [getCommand > Marco T?lio Gontijo e Silva **20080712154521] > [X implementation dependent keysyms from X.org > zythmer@gmail.com**20080528004224 > > Added all of the X keysyms from X.org except the groups XK_MISCELLANY and > XK_LATIN1 as well as skipped XK_VoidSymbol since it is not in any group. > The above groups and symbol are already in Graphics.X11.Types > ] > [Make sure both --with-xinerama and --without-xinerama works > Lennart Kolmodin **20080524112224 > Use the builtin variable with_xinerama instead of our want_xinerama. > This gives us ability to use both --with-xinerama and --without-xinerama. > ] > [Use -auto-all when profiling > Don Stewart **20080413112039] > [Update configure.ac with new version number > Lennart Kolmodin **20080331184021] > [Add setKeyEvent to Graphics.X11.Xlib.Extras > J?r?my Bobbio **20080328214753] > [TAG 1.4.2 > Spencer Janssen **20080327193813] > [Bump version number to 1.4.2 > Spencer Janssen **20080327193755] > [Handle a NULL retrun from XGetWMHints correctly, fixes a segfault bug > Spencer Janssen **20080327192702] > [update version info > Don Stewart **20080307190921] > [comments > Don Stewart **20080307190910] > [Remove -O2 from ghc-options > Spencer Janssen **20071216001612] > [TAG 1.4.1 > Spencer Janssen **20071211042441] > [Bump version to 1.4.1 > Spencer Janssen **20071211042430] > [Check the return value of XGetWindowProperty, this fixes crash bugs when the requested Window/Property does not exist > Spencer Janssen **20071211041940] > [Update installation instructions to use newer Cabal's --configure-option > Alec Berryman **20071120214634] > [Remove obsolete INSTALL file; installation instructions are in README > Alec Berryman **20071120203353] > [Remove redundant XIconifyWindow binding > Spencer Janssen **20071208084849] > [Added haddock docs to setErrorHandler; added XIconifyWindow and XMapRaised bindings > hoelz@wisc.edu**20071202043806] > [use a working header file for XSetErrorHandler > Lukas Mai **20071129174529] > [Implemented a full binding to XSetErrorHandler > hoelz@wisc.edu**20071127011847] > [TAG 1.4.0 > Don Stewart **20071125032528] > [bump X11 version to 1.4.0 > Don Stewart **20071125032135] > [add copyright info and year for Graphics/X11/Xlib/Extras.hsc > Don Stewart **20071121024752] > [bump to snapshot tag > Don Stewart **20071111200531] > [Fix bug in the type of functions dealing with properties > Mats Jansborg **20071101190154 > > The documentation for XGetWindowProperty and XChangeProperty states > that the data must be represented as an array of char, short and long > for a format of 8, 16 and 32 respectively. Previously Word8, Word16 > and Word32 were used, resulting in bugs on platforms where char is not > 8 bits, short 16 bits and long 32 bits wide. > ] > [home instead of $USER > Don Stewart **20071101212016] > [space in CPPFLAGS will break .buildinfo file > Don Stewart **20071031172720] > [add CPPFLAGS and LDFLAGS to buildinfo file > Don Stewart **20071031172436] > [formatting > Don Stewart **20071031171257] > [license header for Xinerama > Don Stewart **20071031165900] > [untabify > Don Stewart **20071031165743] > [#!-able Setup.lhs > Don Stewart *-20071030173235] > [bump version > Don Stewart **20071030213949] > [Bump version number > Ian Lynagh **20071027124814] > [#!-able Setup.lhs > Don Stewart **20071030173235] > [TAG X11-1.3.0 > Don Stewart **20071030172832] > [wall police > Don Stewart **20071030171430] > [cabal tweaks > Don Stewart **20071030171341] > [wall police > Don Stewart **20071029205511] > [Bug fix: not storing height in XSizeHints.resize_inc > Don Stewart **20071029202844] > [-Wall police > Don Stewart **20071029202542] > [clean up warnings > Don Stewart **20071029201214] > [wrong header included, hidden by -fasm > Don Stewart **20071029184208] > [no .lhs Setup script > Don Stewart **20071029183618] > [Xutils.h -> Xutil.hs > Don Stewart **20071029183435] > [more info in readme > Don Stewart **20071029182528] > [more typos in the merged .cabal file > Don Stewart **20071029182349] > [duplicate line in .cabal file > Don Stewart **20071029181942] > [Merge in X11-extras package, bump to 1.3.0. Adds Xinerama and X event support. > Don Stewart **20071029175855] > [TAG 1.2.3 > Don Stewart **20071012181748] > Patch bundle hash: > c2047a1dad296b9bf634a852c71d6e5002226576 > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From dilinger at collabora.co.uk Tue Sep 15 12:31:43 2009 From: dilinger at collabora.co.uk (Andres Salomon) Date: Tue Sep 15 12:10:53 2009 Subject: darcs patch: haskell-x11: export Cursor in Xlib.hs Message-ID: <20090915123143.01472662@mycelium.queued.net> Tue Sep 15 12:23:18 EDT 2009 Andres Salomon * haskell-x11: export Cursor in Xlib.hs Whoops, I forgot to export the cursors along w/ the rest of Xlib. New patches: [haskell-x11: export Cursor in Xlib.hs Andres Salomon **20090915162318 Ignore-this: 77e1afa7994d1d0a3396dac2f7b37d27 Whoops, I forgot to export the cursors along w/ the rest of Xlib. ] { hunk ./Graphics/X11/Xlib.hs 40 module Graphics.X11.Xlib.Window, module Graphics.X11.Xlib.Context, module Graphics.X11.Xlib.Color, + module Graphics.X11.Xlib.Cursor, module Graphics.X11.Xlib.Font, module Graphics.X11.Xlib.Atom, module Graphics.X11.Xlib.Region, hunk ./Graphics/X11/Xlib.hs 57 import Graphics.X11.Xlib.Window import Graphics.X11.Xlib.Context import Graphics.X11.Xlib.Color +import Graphics.X11.Xlib.Cursor import Graphics.X11.Xlib.Font import Graphics.X11.Xlib.Atom import Graphics.X11.Xlib.Region } Context: [Some extra fields, bump the version. Don Stewart **20090915161044] [haskell-x11: add and export the list of cursors Andres Salomon **20090915155708 Ignore-this: 995cede8cdd8830a2c0bb6c63b8229b9 Pulled in from X11/cursorfont.h, export things like xC_X_cursor and xC_left_ptr for things like createFontCursor to use. ] [TAG 1.4.5 Spencer Janssen **20081203050348 Ignore-this: d8112e4ff25ec56fe5ac2cdc9fa1ead ] [Bump version to 1.4.5 Spencer Janssen **20081203050251 Ignore-this: 665f8093d82bef9e6b13bf1e4db74e1d ] [Bump configure.ac to 1.4.4 as well Spencer Janssen **20081203050154 Ignore-this: ef3fabf26fc7dbfdb6dfaa92073e3c9e ] [Fix memory leak in getWMHints Spencer Janssen **20081125221512 Ignore-this: dacc19acbb60e13d945509cde0551bc8 ] [more precise X11 deps Don Stewart **20081011211930] [TAG 1.4.3 Spencer Janssen **20080921082528] [Bump version to 1.4.3 Spencer Janssen **20080921054954] [getCommand Marco T?lio Gontijo e Silva **20080712154521] [X implementation dependent keysyms from X.org zythmer@gmail.com**20080528004224 Added all of the X keysyms from X.org except the groups XK_MISCELLANY and XK_LATIN1 as well as skipped XK_VoidSymbol since it is not in any group. The above groups and symbol are already in Graphics.X11.Types ] [Make sure both --with-xinerama and --without-xinerama works Lennart Kolmodin **20080524112224 Use the builtin variable with_xinerama instead of our want_xinerama. This gives us ability to use both --with-xinerama and --without-xinerama. ] [Use -auto-all when profiling Don Stewart **20080413112039] [Update configure.ac with new version number Lennart Kolmodin **20080331184021] [Add setKeyEvent to Graphics.X11.Xlib.Extras J?r?my Bobbio **20080328214753] [TAG 1.4.2 Spencer Janssen **20080327193813] [Bump version number to 1.4.2 Spencer Janssen **20080327193755] [Handle a NULL retrun from XGetWMHints correctly, fixes a segfault bug Spencer Janssen **20080327192702] [update version info Don Stewart **20080307190921] [comments Don Stewart **20080307190910] [Remove -O2 from ghc-options Spencer Janssen **20071216001612] [TAG 1.4.1 Spencer Janssen **20071211042441] [Bump version to 1.4.1 Spencer Janssen **20071211042430] [Check the return value of XGetWindowProperty, this fixes crash bugs when the requested Window/Property does not exist Spencer Janssen **20071211041940] [Update installation instructions to use newer Cabal's --configure-option Alec Berryman **20071120214634] [Remove obsolete INSTALL file; installation instructions are in README Alec Berryman **20071120203353] [Remove redundant XIconifyWindow binding Spencer Janssen **20071208084849] [Added haddock docs to setErrorHandler; added XIconifyWindow and XMapRaised bindings hoelz@wisc.edu**20071202043806] [use a working header file for XSetErrorHandler Lukas Mai **20071129174529] [Implemented a full binding to XSetErrorHandler hoelz@wisc.edu**20071127011847] [TAG 1.4.0 Don Stewart **20071125032528] [bump X11 version to 1.4.0 Don Stewart **20071125032135] [add copyright info and year for Graphics/X11/Xlib/Extras.hsc Don Stewart **20071121024752] [bump to snapshot tag Don Stewart **20071111200531] [Fix bug in the type of functions dealing with properties Mats Jansborg **20071101190154 The documentation for XGetWindowProperty and XChangeProperty states that the data must be represented as an array of char, short and long for a format of 8, 16 and 32 respectively. Previously Word8, Word16 and Word32 were used, resulting in bugs on platforms where char is not 8 bits, short 16 bits and long 32 bits wide. ] [home instead of $USER Don Stewart **20071101212016] [space in CPPFLAGS will break .buildinfo file Don Stewart **20071031172720] [add CPPFLAGS and LDFLAGS to buildinfo file Don Stewart **20071031172436] [formatting Don Stewart **20071031171257] [license header for Xinerama Don Stewart **20071031165900] [untabify Don Stewart **20071031165743] [#!-able Setup.lhs Don Stewart *-20071030173235] [bump version Don Stewart **20071030213949] [Bump version number Ian Lynagh **20071027124814] [#!-able Setup.lhs Don Stewart **20071030173235] [TAG X11-1.3.0 Don Stewart **20071030172832] [wall police Don Stewart **20071030171430] [cabal tweaks Don Stewart **20071030171341] [wall police Don Stewart **20071029205511] [Bug fix: not storing height in XSizeHints.resize_inc Don Stewart **20071029202844] [-Wall police Don Stewart **20071029202542] [clean up warnings Don Stewart **20071029201214] [wrong header included, hidden by -fasm Don Stewart **20071029184208] [no .lhs Setup script Don Stewart **20071029183618] [Xutils.h -> Xutil.hs Don Stewart **20071029183435] [more info in readme Don Stewart **20071029182528] [more typos in the merged .cabal file Don Stewart **20071029182349] [duplicate line in .cabal file Don Stewart **20071029181942] [Merge in X11-extras package, bump to 1.3.0. Adds Xinerama and X event support. Don Stewart **20071029175855] [TAG 1.2.3 Don Stewart **20071012181748] Patch bundle hash: c591b42158e6bb75fd901ba0b250c12d49093b88 From duncan.coutts at worc.ox.ac.uk Tue Sep 15 09:59:22 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Sep 15 12:38:42 2009 Subject: Haskell Platform package additions: decision time! In-Reply-To: <4AAF6D62.6060301@gmail.com> References: <1252965258.19215.606.camel@localhost> <4AAF6D62.6060301@gmail.com> Message-ID: <1253023162.19215.1620.camel@localhost> On Tue, 2009-09-15 at 11:33 +0100, Simon Marlow wrote: > I basically agree with Duncan's points. The main advantages of a > checklist are that it helps organise the discussion and reminds people > what points are yet to be agreed upon. Right, and we can have a "you might like to think about this" list to remind reviewers when they are making their judgements. Duncan From ryan at peerium.com Tue Sep 15 13:13:31 2009 From: ryan at peerium.com (Ryan Wisnesky) Date: Tue Sep 15 12:52:11 2009 Subject: meaing of Cabal's extra-libraries field Message-ID: <657BF20B-123B-4525-956B-A83A5F67877C@peerium.com> Hello, I have a probably very dumb question about how to use Cabal - I'm just starting out with it. If this list isn't the right place to post the question, please let me know. It seems like when I add an Extra-libraries field to a cabal source package description: Name: LibraryFoo ... Library Extra-libraries: Bar this has the effect that when loading package LibraryFoo in ghci, ghci will necessarily try to open a corresponding Bar.so/.dll/.dylib file: > ghci -package LibraryFoo Loading package LibraryFoo-0.1 ... : can't load .so/.DLL for: Bar (dlopen(Bar.dylib, 10): image not found) What I want to do is statically link LibraryFoo against Bar before Cabal installs the package, (so that, for instance, I can run ghci without a bunch of command line linking arguments and don't need to have Bar around anymore), and I have a Bar.o file for just such a purpose. Is there a way to get Cabal to do this? Thanks for your help, Ryan Wisnesky From duncan.coutts at worc.ox.ac.uk Tue Sep 15 15:49:53 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Sep 15 15:29:28 2009 Subject: meaing of Cabal's extra-libraries field In-Reply-To: <657BF20B-123B-4525-956B-A83A5F67877C@peerium.com> References: <657BF20B-123B-4525-956B-A83A5F67877C@peerium.com> Message-ID: <1253044193.19215.1998.camel@localhost> On Tue, 2009-09-15 at 13:13 -0400, Ryan Wisnesky wrote: > I have a probably very dumb question about how to use Cabal - I'm just > starting out with it. If this list isn't the right place to post the > question, please let me know. This list is fine. For Cabal development discussions we use the cabal-devel list. > It seems like when I add an Extra-libraries field to a cabal source > package description: > > Name: LibraryFoo > ... > Library > Extra-libraries: Bar > > this has the effect that when loading package LibraryFoo in ghci, ghci > will necessarily try to open a corresponding Bar.so/.dll/.dylib file: Right. > What I want to do is statically link LibraryFoo against Bar before > Cabal installs the package, Cabal's "Simple" build system does not currently provide any mechanism for adding arbitrary .o files into the static archive and similarly no way to link one static archive with another. The only builtin mechanism is to compile C code (specified by the "c-sources" field) and that gets included into the same static archive as the Haskell library. In principle it should be possible to hack in extra stuff by writing code in the Setup.hs script. I don't claim it'd be easy however. If you'd like to file a feature request then the bug tracker is here: http://hackage.haskell.org/trac/hackage/ If it's really important, there are people you can pay to get stuff done. Duncan From marlowsd at gmail.com Wed Sep 16 06:39:43 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Sep 16 06:18:24 2009 Subject: Haskell Platform package additions: decision time! In-Reply-To: <1253022293.19215.1602.camel@localhost> References: <1252965258.19215.606.camel@localhost> <60F1D511-F378-4F61-8166-5DAC013983E3@cs.york.ac.uk> <1253022293.19215.1602.camel@localhost> Message-ID: <4AB0C06F.5010709@gmail.com> On 15/09/2009 14:44, Duncan Coutts wrote: > On Tue, 2009-09-15 at 09:34 +0100, Malcolm Wallace wrote: >>> So far we have had a few people send in comments (thanks >>> particularly to >>> Ian and Simon) but a few more would not go amiss, even if it's just >>> "yes". >> >> Basically, yes. >> >>> Concern 1: "The policy document itself is too long and too detailed." >> >> I must admit, I too did not read it fully, because it was >> intimidatingly long. In fact, it made me think "phew, thank goodness >> I didn't want to propose any of my packages for the platform!" >> >>> Quick poll: should we split the rationale into a separate page or keep >>> it on the same page? Yes or no. >> >> Definitely split off the rationale, > > Seems like this is the majority opinion. If it is actually putting > people off then that's certainly a good reason to split. The procedure > is not very complicated, the policy is just fairly detailed and, I hope, > fairly clear. We were trying to anticipate questions and corner cases. I'd like to chime in in support of the current way it's done. Having it on the same page is better than separate pages because it's easier to navigate. Separate panes or similar would be even better, but that's essentially impossible without deep Trac magic, if at all. If people are worried by the length of the page, then perhaps it could be made clearer at the top of the page that only the first X% of the page is actual policy, the rest is rationale. With a diagram, even :) Cheers, Simon From duncan.coutts at worc.ox.ac.uk Wed Sep 16 11:11:16 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Sep 16 12:05:52 2009 Subject: Haskell Platform package additions: decision time! In-Reply-To: <4AB0C06F.5010709@gmail.com> References: <1252965258.19215.606.camel@localhost> <60F1D511-F378-4F61-8166-5DAC013983E3@cs.york.ac.uk> <1253022293.19215.1602.camel@localhost> <4AB0C06F.5010709@gmail.com> Message-ID: <1253113876.19215.3990.camel@localhost> On Wed, 2009-09-16 at 11:39 +0100, Simon Marlow wrote: > >>> Quick poll: should we split the rationale into a separate page or keep > >>> it on the same page? Yes or no. > >> > >> Definitely split off the rationale, > > > > Seems like this is the majority opinion. If it is actually putting > > people off then that's certainly a good reason to split. The procedure > > is not very complicated, the policy is just fairly detailed and, I hope, > > fairly clear. We were trying to anticipate questions and corner cases. > > I'd like to chime in in support of the current way it's done. Having it > on the same page is better than separate pages because it's easier to > navigate. I think we're in the minority however. > Separate panes or similar would be even better, but that's > essentially impossible without deep Trac magic, if at all. I played with inserting html and it works except that trac always wraps it in a div, so it's useless for links. > If people are worried by the length of the page, then perhaps it could > be made clearer at the top of the page that only the first X% of the > page is actual policy, the rest is rationale. With a diagram, even :) It does already :-) Who should read this: * People who want to propose a new package; * People reviewing proposed packages; * The Haskell Platform release team Only the first half of this page is essential reading. Duncan From iavor.diatchki at gmail.com Wed Sep 16 13:00:31 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Sep 16 12:39:09 2009 Subject: Haskell Platform package additions: decision time! In-Reply-To: <1253022293.19215.1602.camel@localhost> References: <1252965258.19215.606.camel@localhost> <60F1D511-F378-4F61-8166-5DAC013983E3@cs.york.ac.uk> <1253022293.19215.1602.camel@localhost> Message-ID: <5ab17e790909161000u7314e8f1lba96312fd05a0a98@mail.gmail.com> Hello, On Tue, Sep 15, 2009 at 6:44 AM, Duncan Coutts wrote: > On Tue, 2009-09-15 at 09:34 +0100, Malcolm Wallace wrote: >> Suggestion: can the rationale be coded to come up in a separate >> browser window? (Especially if the links ensure that different >> rationale links come through to the _same_ target window.) ?I would >> find it helpful to be able to see policy + rationale side-by-side >> (although not intermingled). > > I've no idea how to do that in the trac wiki markup. If anyone knows > please say so. How about putting the rationale on a separate page, in the usual way, and if people want to view it in a new window or a separate tab, then they can use the browser feature (e.g., right mouse button in Firefox). Not a perfect but simple. :-) -Iavor From ross at soi.city.ac.uk Thu Sep 17 09:37:48 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Sep 17 09:16:26 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: References: Message-ID: <20090917133748.GA20813@soi.city.ac.uk> On Tue, Jun 30, 2009 at 02:37:51PM -0700, Bryan O'Sullivan wrote: > Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339 > > From the ticket: > > This proposal was, I think, originally suggested by Jules Bean. The > idea is to add two functions to the Data.Monoid module, (+>) and (<+), > corresponding to different uses of mappend. These should not be methods > of the Monoid typeclass, but top-level functions. > > I hope (but slightly doubt) that the visual nature of the two operators > might help to counter the thought that monoids are just for gluing > things together. This proposal seems to have got stuck. Everyone wants an infix operator, but we can't agree what it should be. I prefer using a new operator instead of generalizing ++ (or +, *, && or ||), because I think that a monoid operation is so abstract that it needs a name that doesn't suggest one of the special cases. (I like <>) From jon.fairbairn at cl.cam.ac.uk Thu Sep 17 11:08:16 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu Sep 17 10:47:13 2009 Subject: Proposal (Trac ticket #3524): Add mfilter to Control.Monad Message-ID: Following on from the discussion of #3453, I propose the addition of mfilter to Control.Monad. It's just List.filter for any MonadPlus. I'd rather that we didn't have List.filter, and called this filter, but (a) I can't see that happening and (b) the naming scheme for Control.Monad is quite explicit. Time limit for discussion: 1 October. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From jon.fairbairn at cl.cam.ac.uk Thu Sep 17 11:10:51 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu Sep 17 10:53:40 2009 Subject: Proposal: add new function "check" to Control.Monad References: <17202.1251309179@calligramme.charmers> <351FDBA1-8512-457D-BA61-FC67422EAB66@informatik.uni-kiel.de> <7fb8f82f0909110654j4bea417ct3ec9f9a7b3141daa@mail.gmail.com> Message-ID: Edward Kmett writes: > While I like the generic version of filter, and have written one myself, I > am somewhat concerned about the fact that Control.Monad is probably the > module most often imported unqualified and without an explicit import list > due to the sheer number of combinators that it provides and filter is a very > commonly used function in the Prelude. > Adding the generic version of filter with the same name to such a module > will likely break a good deal of code. I don't think it would break the code as such: it does exactly the same thing. It would break the import declarations, though. > Jon's suggestion of mfilter (filterM?) Definitely mfilter. filterM is there already, and does what its name implies. See proposal #3524. J?n From jon.fairbairn at cl.cam.ac.uk Thu Sep 17 11:15:15 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu Sep 17 10:58:43 2009 Subject: Proposal: add new function "check" to Control.Monad References: Message-ID: Jon Fairbairn writes: > Trac ticket #3453. Two week time frame. > > Add check function to Control.Monad > > check :: (MonadPlus m) => (a -> Bool) -> a -> m a > check p a > | p a = return a > | otherwise = mzero My impression is that the consensus is not to add this, mostly because of the "names for small functions" argument with which I heartily concur, though I suspect that I prejudiced things by not giving a strong enough justification to begin with (eg that what I'd really like to see is check -- by whatever name -- and to deprecate guard as something that encourages imperative thinking) So I've formally proposed mfilter instead. I imagine that I should close this ticket: is the correct resolution "wontfix"? -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From ross at soi.city.ac.uk Thu Sep 17 11:28:47 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Sep 17 11:07:24 2009 Subject: Proposal: add new function "check" to Control.Monad In-Reply-To: References: Message-ID: <20090917152847.GA21564@soi.city.ac.uk> On Thu, Sep 17, 2009 at 04:15:15PM +0100, Jon Fairbairn wrote: > So I've formally proposed mfilter instead. I imagine that I should close > this ticket: is the correct resolution "wontfix"? Yes From duncan.coutts at worc.ox.ac.uk Thu Sep 17 15:35:58 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 17 15:14:37 2009 Subject: Call for consensus: Haskell Platform package additions policy In-Reply-To: <1252965258.19215.606.camel@localhost> References: <1252965258.19215.606.camel@localhost> Message-ID: <1253216158.19215.6970.camel@localhost> On Mon, 2009-09-14 at 22:54 +0100, Duncan Coutts wrote: > We would like to get this wrapped up so that we can move on to > discussing more guidelines/requirements on packages and indeed to > actually proposing some packages. > > So far we have had a few people send in comments (thanks particularly to > Ian and Simon) but a few more would not go amiss, even if it's just > "yes". Thanks to the people who responded. I hope we're done now. I've made a couple changes based on the feedback which I explain below. Are there any unresolved concerns? If not then we'll declare the policy adopted and we can move on to discuss package proposals and extra package requirements/guidelines. A quick review of the points I asked people to consider. > Concern 1: "The policy document itself is too long and too detailed." > > Quick poll: should we split the rationale into a separate page or keep > it on the same page? Yes or no. Most people thought yes split it. That's now done. http://trac.haskell.org/haskell-platform/wiki/AddingPackages http://trac.haskell.org/haskell-platform/wiki/AddingPackages/Rationale > Concern 2: "Documentation written for the proposal will get lost." I added a paragraph to the "proposal content" section: If new documentation is written for the proposal that would be useful in future for users of the package (e.g. an introduction or tutorial) then we wish to ensure that it is indeed made available to users. In the case that useful new documentation is written, reviewers are strongly encouraged to make it a condition of acceptance that the new material be republished in the appropriate place and form (e.g. on a package's homepage or integrated into API reference documentation). > Concern 3. The more major and general complaint Ian has is that he > believes the criteria for acceptance should be essentially a checklist. > So my suggestion on this complaint is that we go with the policy that > the steering committee has proposed and that we move quickly afterwards > to discuss more comprehensive package requirements and guidelines. I've not done anything here. Most people who responded seemed to agree with this suggestion. Duncan From naesten at gmail.com Thu Sep 17 16:52:17 2009 From: naesten at gmail.com (Samuel Bronson) Date: Thu Sep 17 16:30:50 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <20090917133748.GA20813@soi.city.ac.uk> References: <20090917133748.GA20813@soi.city.ac.uk> Message-ID: On Thu, Sep 17, 2009 at 9:37 AM, Ross Paterson wrote: > This proposal seems to have got stuck. ?Everyone wants an infix operator, > but we can't agree what it should be. > > I prefer using a new operator instead of generalizing ++ (or +, *, && > or ||), because I think that a monoid operation is so abstract that it > needs a name that doesn't suggest one of the special cases. ?(I like <>) I agree. <> really seems to fit well, even if it *does* reinforce the idea that Monoid is for gluing things together -- which, you know, it really is rather good for. From ross at soi.city.ac.uk Thu Sep 17 17:01:02 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Sep 17 16:39:38 2009 Subject: Haskell Platform package additions: decision time! In-Reply-To: <1252965258.19215.606.camel@localhost> References: <1252965258.19215.606.camel@localhost> Message-ID: <20090917210102.GA22997@soi.city.ac.uk> I'm generally in favour, but one thing puzzled me: if some documentation (e.g. major design decisions and examples of API use) are required to be integrated before final acceptance, and are a good idea anyway, why not expect them to be integrated when the package is proposed? From dons at galois.com Thu Sep 17 17:22:34 2009 From: dons at galois.com (Don Stewart) Date: Thu Sep 17 17:03:18 2009 Subject: Haskell Platform package additions: decision time! In-Reply-To: <20090917210102.GA22997@soi.city.ac.uk> References: <1252965258.19215.606.camel@localhost> <20090917210102.GA22997@soi.city.ac.uk> Message-ID: <20090917212234.GJ24581@whirlpool.galois.com> ross: > I'm generally in favour, but one thing puzzled me: if some documentation > (e.g. major design decisions and examples of API use) are required to be > integrated before final acceptance, and are a good idea anyway, why not > expect them to be integrated when the package is proposed? We expect review will lead to additional documentation generation. From ekmett at gmail.com Thu Sep 17 18:11:12 2009 From: ekmett at gmail.com (Edward Kmett) Date: Thu Sep 17 17:49:45 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: References: <20090917133748.GA20813@soi.city.ac.uk> Message-ID: <7fb8f82f0909171511o53fd881bp26dfc00a7a2b6bcd@mail.gmail.com> I also really like <>. On Thu, Sep 17, 2009 at 4:52 PM, Samuel Bronson wrote: > On Thu, Sep 17, 2009 at 9:37 AM, Ross Paterson > wrote: > > > This proposal seems to have got stuck. Everyone wants an infix operator, > > but we can't agree what it should be. > > > > I prefer using a new operator instead of generalizing ++ (or +, *, && > > or ||), because I think that a monoid operation is so abstract that it > > needs a name that doesn't suggest one of the special cases. (I like <>) > > I agree. <> really seems to fit well, even if it *does* reinforce the > idea that Monoid is for gluing things together -- which, you know, it > really is rather good for. > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090917/11f31af9/attachment.html From nicolas.pouillard at gmail.com Thu Sep 17 18:36:53 2009 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Thu Sep 17 18:14:14 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <7fb8f82f0909171511o53fd881bp26dfc00a7a2b6bcd@mail.gmail.com> References: <20090917133748.GA20813@soi.city.ac.uk> <7fb8f82f0909171511o53fd881bp26dfc00a7a2b6bcd@mail.gmail.com> Message-ID: <1253226995-sup-2362@peray> Excerpts from Edward Kmett's message of Fri Sep 18 00:11:12 +0200 2009: > I also really like <>. I'm also in favor of <> > > On Thu, Sep 17, 2009 at 4:52 PM, Samuel Bronson wrote: > > > On Thu, Sep 17, 2009 at 9:37 AM, Ross Paterson > > wrote: > > > > > This proposal seems to have got stuck. Everyone wants an infix operator, > > > but we can't agree what it should be. > > > > > > I prefer using a new operator instead of generalizing ++ (or +, *, && > > > or ||), because I think that a monoid operation is so abstract that it > > > needs a name that doesn't suggest one of the special cases. (I like <>) > > > > I agree. <> really seems to fit well, even if it *does* reinforce the > > idea that Monoid is for gluing things together -- which, you know, it > > really is rather good for. > > _______________________________________________ > > Libraries mailing list > > Libraries@haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > -- Nicolas Pouillard http://nicolaspouillard.fr From kr.angelov at gmail.com Fri Sep 18 02:26:01 2009 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Fri Sep 18 02:04:34 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <20090917133748.GA20813@soi.city.ac.uk> References: <20090917133748.GA20813@soi.city.ac.uk> Message-ID: On 9/17/09, Ross Paterson wrote: > I prefer using a new operator instead of generalizing ++ (or +, *, && > or ||), because I think that a monoid operation is so abstract that it > needs a name that doesn't suggest one of the special cases. (I like <>) <> collides with the same operator defined in Text.PrettyPrint. Please don't add operator that collides with something else that is already in the standard libraries. The operators looks very ugly when they are quantified. We should save at least some very often used functions and operators from collision. Krasimir From malcolm.wallace at cs.york.ac.uk Fri Sep 18 03:47:03 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Sep 18 03:25:55 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: References: <20090917133748.GA20813@soi.city.ac.uk> Message-ID: > <> collides with the same operator defined in Text.PrettyPrint. Please > don't add operator that collides with something else that is already > in the standard libraries. Is it possible that the pretty-printing <> is in fact just another instance of the Monoidal mappend? Regards, Malcolm From apfelmus at quantentunnel.de Fri Sep 18 03:51:12 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Fri Sep 18 03:30:08 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <1253226995-sup-2362@peray> References: <20090917133748.GA20813@soi.city.ac.uk> <7fb8f82f0909171511o53fd881bp26dfc00a7a2b6bcd@mail.gmail.com> <1253226995-sup-2362@peray> Message-ID: Nicolas Pouillard wrote: > Excerpts from Edward Kmett's message of Fri Sep 18 00:11:12 +0200 2009: >> I also really like <>. > > I'm also in favor of <> mappend me to the list of people who prefer <> . Regards, apfelmus -- http://apfelmus.nfshost.com From jeanphilippe.bernardy at gmail.com Fri Sep 18 03:55:09 2009 From: jeanphilippe.bernardy at gmail.com (Jean-Philippe Bernardy) Date: Fri Sep 18 03:33:42 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: References: <20090917133748.GA20813@soi.city.ac.uk> Message-ID: <953e0d250909180055j7e378b7aie9eafe1e78acfcf1@mail.gmail.com> > Is it possible that the pretty-printing <> is in fact just another instance > of the Monoidal mappend? Yes. (<>) :: Doc -> Doc -> Doc Source Beside. <> is associative, with identity empty. http://haskell.org/ghc/docs/latest/html/libraries/pretty/Text-PrettyPrint-HughesPJ.html#v%3A<> -- JP From kr.angelov at gmail.com Fri Sep 18 04:27:35 2009 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Fri Sep 18 04:06:09 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <953e0d250909180055j7e378b7aie9eafe1e78acfcf1@mail.gmail.com> References: <20090917133748.GA20813@soi.city.ac.uk> <953e0d250909180055j7e378b7aie9eafe1e78acfcf1@mail.gmail.com> Message-ID: Ok. Then this proposal should be accompanied with the proposal to generalize Text.PrettyPrint.<>. On 9/18/09, Jean-Philippe Bernardy wrote: > > Is it possible that the pretty-printing <> is in fact just another instance > > of the Monoidal mappend? > > Yes. > > (<>) :: Doc -> Doc -> Doc Source > Beside. <> is associative, with identity empty. > > http://haskell.org/ghc/docs/latest/html/libraries/pretty/Text-PrettyPrint-HughesPJ.html#v%3A<> > > -- JP > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From duncan.coutts at worc.ox.ac.uk Fri Sep 18 07:18:54 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Sep 18 07:00:52 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <20090917133748.GA20813@soi.city.ac.uk> References: <20090917133748.GA20813@soi.city.ac.uk> Message-ID: <1253272734.19215.7948.camel@localhost> On Thu, 2009-09-17 at 14:37 +0100, Ross Paterson wrote: > This proposal seems to have got stuck. Everyone wants an infix operator, > but we can't agree what it should be. > > I prefer using a new operator instead of generalizing ++ (or +, *, && > or ||), because I think that a monoid operation is so abstract that it > needs a name that doesn't suggest one of the special cases. (I like <>) Nice. For some reason I much prefer a symbol like <> to one like +>. I want to say that it's because it looks symmetric, though of course mappend, ++ are associative not symmetric, so it's not a very good argument. But I still like it! :-) So I guess we should adjust the proposal, or make a new one. * Suggest the name <> (which so far seems to have popular support) * Get rid of the suggestion for a reverse mappend operator * As Krasimir says, include in the proposal that we would deal with the existing libraries that use a local <> for their mappend operator (at least Text.PrettyPrint). One thing we've not mentioned much is operator precedence. Existing uses: infixr 5 Data.Sequence.>< infixl 6 Text.PrettyPrint.<> Existing proposal about (+>) infixl 4 +> Duncan From ekmett at gmail.com Fri Sep 18 10:04:47 2009 From: ekmett at gmail.com (Edward Kmett) Date: Fri Sep 18 09:43:19 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <1253272734.19215.7948.camel@localhost> References: <20090917133748.GA20813@soi.city.ac.uk> <1253272734.19215.7948.camel@localhost> Message-ID: <7fb8f82f0909180704r4238a97cy27aa5f2194be1839@mail.gmail.com> I'ved chewed on the associativity and precedence issue for <> a little bit. Here are my thoughts. infixl 6 <> would match the precedence of +, which is nice on paper, and how I happen to implement (+) in Data.Monoid.Sugar in the monoids library. I now believe that it is not quite right. On paper infixr vs. infixl is basically irrelevant because the result is monoidal, but in practice infixr tends to work better for a lot of real world monoids we care about like list appending. Take a look at the behavior of ((... ++ b) ++ c) vs (a ++ (b ++ ...) for a compelling justification for why infixr is probably better in practice for the poster child of the monoid lineup. Ross's infixr 5 >< in Data.Sequence is the same precedence and fixity as ++, which also seems like a good answer at first, but infixr 5 <> would change the behavior of programs that use Text.PrettyPrint.HughesPJ, which relies on the fixity of <> and <+> being higher than $$ and $+$ which are infixl 5. The original proposed infixr/l 4 is low enough that you couldn't even mix the use of <> with the various comparators from Eq and Ord, and it exacerbates all of the above issues -- by inverting the precedence of $$ and <> -- so I think it should be off the table. For similar reasons I don't like lowering the fixity off $$ and $+$ in HughesPJ to 4 to permit infixr 5 <>. So, in light of all of that, it would seem that the most compatible general change would be to set: infixr 6 <> and to change the associativity of <+> in Text.PrettyPrint.HughesPJ to match, so that they can be intermixed. Version 3.0 of the HughesPJ combinators, released back in 1997 has fixed any performance regression that would be caused by changing the associativity. I hope everyone will have upgraded by now. ;) This binds slightly tighter than ++, but retains the same asymptotic performance, works with == <=, etc. and only requires the minor associativity tweak to HughesPJ, which should be allowed just fine under the pretty printer combinator laws, so exxisting HughesPJ code should continue to run just fine, and other existing code wouldn't be using the new operator, so shouldn't require any tweaks. -Edward Kmett On Fri, Sep 18, 2009 at 7:18 AM, Duncan Coutts wrote: > On Thu, 2009-09-17 at 14:37 +0100, Ross Paterson wrote: > > > This proposal seems to have got stuck. Everyone wants an infix operator, > > but we can't agree what it should be. > > > > I prefer using a new operator instead of generalizing ++ (or +, *, && > > or ||), because I think that a monoid operation is so abstract that it > > needs a name that doesn't suggest one of the special cases. (I like <>) > > Nice. For some reason I much prefer a symbol like <> to one like +>. > > I want to say that it's because it looks symmetric, though of course > mappend, ++ are associative not symmetric, so it's not a very good > argument. But I still like it! :-) > > So I guess we should adjust the proposal, or make a new one. > * Suggest the name <> (which so far seems to have popular support) > * Get rid of the suggestion for a reverse mappend operator > * As Krasimir says, include in the proposal that we would deal > with the existing libraries that use a local <> for their > mappend operator (at least Text.PrettyPrint). > > One thing we've not mentioned much is operator precedence. Existing > uses: > infixr 5 Data.Sequence.>< > infixl 6 Text.PrettyPrint.<> > Existing proposal about (+>) > infixl 4 +> > > Duncan > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090918/de887a80/attachment.html From nicolas.pouillard at gmail.com Fri Sep 18 12:21:33 2009 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Fri Sep 18 11:58:47 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <7fb8f82f0909180704r4238a97cy27aa5f2194be1839@mail.gmail.com> References: <20090917133748.GA20813@soi.city.ac.uk> <1253272734.19215.7948.camel@localhost> <7fb8f82f0909180704r4238a97cy27aa5f2194be1839@mail.gmail.com> Message-ID: <1253290819-sup-6629@peray> Excerpts from Edward Kmett's message of Fri Sep 18 16:04:47 +0200 2009: > I'ved chewed on the associativity and precedence issue for <> a little bit. > Here are my thoughts. > > infixl 6 <> would match the precedence of +, which is nice on paper, and how > I happen to implement (+) in Data.Monoid.Sugar in the monoids library. I now > believe that it is not quite right. > > On paper infixr vs. infixl is basically irrelevant because the result is > monoidal, but in practice infixr tends to work better for a lot of real > world monoids we care about like list appending. Take a look at the behavior > of ((... ++ b) ++ c) vs (a ++ (b ++ ...) for a compelling justification for > why infixr is probably better in practice for the poster child of the monoid > lineup. > > Ross's infixr 5 >< in Data.Sequence is the same precedence and fixity as ++, > which also seems like a good answer at first, but infixr 5 <> would change > the behavior of programs that use Text.PrettyPrint.HughesPJ, which relies on > the fixity of <> and <+> being higher than $$ and $+$ which are infixl 5. > > The original proposed infixr/l 4 is low enough that you couldn't even mix > the use of <> with the various comparators from Eq and Ord, and it > exacerbates all of the above issues -- by inverting the precedence of $$ and > <> -- so I think it should be off the table. For similar reasons I don't > like lowering the fixity off $$ and $+$ in HughesPJ to 4 to permit infixr 5 > <>. > > So, in light of all of that, it would seem that the most compatible general > change would be to set: Good work. > infixr 6 <> +1 -- Nicolas Pouillard http://nicolaspouillard.fr From ross at soi.city.ac.uk Fri Sep 18 14:13:49 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Sep 18 13:52:22 2009 Subject: Haskell Platform package additions: decision time! In-Reply-To: <20090917212234.GJ24581@whirlpool.galois.com> References: <1252965258.19215.606.camel@localhost> <20090917210102.GA22997@soi.city.ac.uk> <20090917212234.GJ24581@whirlpool.galois.com> Message-ID: <20090918181349.GA4323@soi.city.ac.uk> On Thu, Sep 17, 2009 at 02:22:34PM -0700, Don Stewart wrote: > ross: > > I'm generally in favour, but one thing puzzled me: if some documentation > > (e.g. major design decisions and examples of API use) are required to be > > integrated before final acceptance, and are a good idea anyway, why not > > expect them to be integrated when the package is proposed? > > We expect review will lead to additional documentation generation. Sorry, I meant that the proposal content lists "major design decisions should be described and motivated" and "For library packages, an example of how the API is intended to be used should be given". I would have expected that these things should already be integrated into the package before it is proposed. From bos at serpentine.com Fri Sep 18 16:26:39 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Sep 18 16:05:10 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <1253290819-sup-6629@peray> References: <20090917133748.GA20813@soi.city.ac.uk> <1253272734.19215.7948.camel@localhost> <7fb8f82f0909180704r4238a97cy27aa5f2194be1839@mail.gmail.com> <1253290819-sup-6629@peray> Message-ID: On Fri, Sep 18, 2009 at 9:21 AM, Nicolas Pouillard < nicolas.pouillard@gmail.com> wrote: > > Good work. > > > infixr 6 <> > > +1 > I've updated the ticket: http://hackage.haskell.org/trac/ghc/ticket/3339 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090918/3e31f60c/attachment.html From bos at serpentine.com Fri Sep 18 16:29:39 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Sep 18 16:08:11 2009 Subject: Haskell Platform package additions: decision time! In-Reply-To: <1252965258.19215.606.camel@localhost> References: <1252965258.19215.606.camel@localhost> Message-ID: On Mon, Sep 14, 2009 at 2:54 PM, Duncan Coutts wrote: > So far we have had a few people send in comments (thanks particularly to > Ian and Simon) but a few more would not go amiss, even if it's just > "yes". > "Yes" :-) Thanks for reworking the pages to be shorter. That was part of what kept me from reading them. Concern 3. The more major and general complaint Ian has is that he > believes the criteria for acceptance should be essentially a checklist. > Some checklist items would be objective, some subjective, but passing > them all would be sufficient for a package to be accepted. A checklist divided into "MUST"/"SHOULD" sections is very valuable, independent of other considerations. That's what we use for Fedora package reviews, and it very much helps us to ensure that we don't skip anything. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090918/ee34017c/attachment.html From valery.vv at gmail.com Fri Sep 18 17:50:54 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Fri Sep 18 17:29:29 2009 Subject: [patch] #562: cabal-install update fails going through a HTTP proxy Message-ID: <87ab0rc475.fsf@gmail.com> Dear Cabal maintainers, A couple of days ago I was unable to cabal-install a library from Hackage -- 00-index.tar.gz was not downloaded completely. And if obtaining one with wget, other .tar.gz files (packages) still could not be fetched in full. This problem has been reported already (see http://hackage.haskell.org/trac/hackage/ticket/562). 06/11/09 09:49:25 changed by duncan: > Why has this started cropping up all of a sudden? Never seen this > before then 3 reports in as many days. Do we suspect HTTP-4000.0.6 -> > 7 perhaps? 06/11/09 13:02:47 changed by michaeldever: > So it's definitely a problem with the HTTP package in my opinion. I'm > not sure if it is a problem with the packages proxy handling, as it > does download some of the package, but not all of it. > > Seeing as both the Zlib library, and tar yield an end of stream error, > its something that I'm reckoning is happening during transport. 06/13/09 09:05:26 changed by michaeldever: > http://trac.haskell.org/http/ticket/8#comment:1 The bug is not in HTTP API, but in the way cabal-install uses it. The type of HTTP response body is polymorphic within `HTTP' library (rspBody :: Response a -> a) but it is specialized to Lazy.ByteString by cabal-install's `getHTTP' function (Distribution/Client/HttpUtils.hs). Once the type of response body is changed to _strict_ ByteString, files get downloaded through proxy completely. The attached module [proxy-POC.hs] makes this quite apparent (you need to be behind a proxy; HTTP >= 4000.0.8): vvv@takeshi:~/src$ time runhaskell proxy-POC.hs Content-Length: 1200593 bytes downloaded: 2408 proxy-POC.hs: user error (sizes differ) real 0m1.210s user 0m0.556s sys 0m0.052s vvv@takeshi:~/src$ time runhaskell -DSTRICT proxy-POC.hs Content-Length: 1200593 bytes downloaded: 1200593 real 0m17.956s user 0m0.620s sys 0m0.028s vvv@takeshi:~/src$ runhaskell proxy-POC.hs # repeatable Content-Length: 1200593 bytes downloaded: 2408 proxy-POC.hs: user error (sizes differ) There are only 4 lines that need to be changed (2 in HttpUtils.hs and 2 in Fetch.hs); see the accompanying patch. ...And could anyone explain me, why don't lazy ByteString cause cropped downloads in proxy-free environment? Thank you. -- vvv -------------- next part -------------- A non-text attachment was scrubbed... Name: cabal-install-0.6.2_proxy-strict-rspBody.patch Type: text/x-diff Size: 1495 bytes Desc: cabal-install-0.6.2_proxy-strict-rspBody.patch Url : http://www.haskell.org/pipermail/libraries/attachments/20090918/61b4ae92/cabal-install-0.6.2_proxy-strict-rspBody.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: proxy-POC.hs Type: text/x-haskell Size: 3627 bytes Desc: proxy-POC.hs Url : http://www.haskell.org/pipermail/libraries/attachments/20090918/61b4ae92/proxy-POC.bin From duncan.coutts at worc.ox.ac.uk Fri Sep 18 17:28:00 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Sep 18 19:48:37 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <7fb8f82f0909180704r4238a97cy27aa5f2194be1839@mail.gmail.com> References: <20090917133748.GA20813@soi.city.ac.uk> <1253272734.19215.7948.camel@localhost> <7fb8f82f0909180704r4238a97cy27aa5f2194be1839@mail.gmail.com> Message-ID: <1253309280.32005.254.camel@localhost> On Fri, 2009-09-18 at 10:04 -0400, Edward Kmett wrote: > I'ved chewed on the associativity and precedence issue for <> a little > bit. Here are my thoughts. Thanks for the analysis. There's just one bit I don't quite follow. > Ross's infixr 5 >< in Data.Sequence is the same precedence and fixity > as ++, which also seems like a good answer at first, but infixr 5 <> > would change the behavior of programs that use > Text.PrettyPrint.HughesPJ, which relies on the fixity of <> and <+> > being higher than $$ and $+$ which are infixl 5. > The original proposed infixr/l 4 is low enough that you couldn't even > mix the use of <> with the various comparators from Eq and Ord, and it > exacerbates all of the above issues -- by inverting the precedence of > $$ and <> -- so I think it should be off the table. For similar > reasons I don't like lowering the fixity off $$ and $+$ in HughesPJ to > 4 to permit infixr 5 <>. It's not clear to me why changing the fixity of $$ and $+$ would be bad. I see that using infixl/r for <> would be bad because we cannot mix >= etc with <> and there are obviously many types that can be in Monoid and Ord. On the other hand Doc is not in any type classes except Show. So I don't see that the point applies to the HughesPJ lib. > So, in light of all of that, it would seem that the most compatible > general change would be to set: > > infixr 6 <> Of course one could argue that you might want a type in Monoid and Ord and have a spare precedence level between <> and >=. But I don't see how we can claim it's necessary for compatibility reasons. If we do need a spare precedence level between <> and >= then fine, but all things being equal it seems preferable to go with the same precedence as ++. Duncan From ekmett at gmail.com Fri Sep 18 20:33:25 2009 From: ekmett at gmail.com (Edward Kmett) Date: Fri Sep 18 20:11:55 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <1253309280.32005.254.camel@localhost> References: <20090917133748.GA20813@soi.city.ac.uk> <1253272734.19215.7948.camel@localhost> <7fb8f82f0909180704r4238a97cy27aa5f2194be1839@mail.gmail.com> <1253309280.32005.254.camel@localhost> Message-ID: <7fb8f82f0909181733o5ee806b4j58f983354c18d08@mail.gmail.com> On Fri, Sep 18, 2009 at 5:28 PM, Duncan Coutts wrote: > On Fri, 2009-09-18 at 10:04 -0400, Edward Kmett wrote: > > I'ved chewed on the associativity and precedence issue for <> a little > > bit. Here are my thoughts. > > Thanks for the analysis. There's just one bit I don't quite follow. > > > Ross's infixr 5 >< in Data.Sequence is the same precedence and fixity > > as ++, which also seems like a good answer at first, but infixr 5 <> > > would change the behavior of programs that use > > Text.PrettyPrint.HughesPJ, which relies on the fixity of <> and <+> > > being higher than $$ and $+$ which are infixl 5. > > > The original proposed infixr/l 4 is low enough that you couldn't even > > mix the use of <> with the various comparators from Eq and Ord, and it > > exacerbates all of the above issues -- by inverting the precedence of > > $$ and <> -- so I think it should be off the table. For similar > > reasons I don't like lowering the fixity off $$ and $+$ in HughesPJ to > > 4 to permit infixr 5 <>. > > It's not clear to me why changing the fixity of $$ and $+$ would be bad. > I see that using infixl/r for <> would be bad because we cannot mix >= > etc with <> and there are obviously many types that can be in Monoid and > Ord. On the other hand Doc is not in any type classes except Show. So I > don't see that the point applies to the HughesPJ lib. > > > So, in light of all of that, it would seem that the most compatible > > general change would be to set: > > > > infixr 6 <> > > Of course one could argue that you might want a type in Monoid and Ord > and have a spare precedence level between <> and >=. But I don't see how we can claim it's necessary for compatibility reasons. Sorry, I didn't mean to imply that the extra level between <> and == was purely for compatibility with Eq and Ord. Perhaps those were the wrong example, but there is a case to be made for wanting to keep the number of hard-to-predict consequences of precedence changes to a minimum. If we do need a spare precedence level between <> and >= then fine, but > all things being equal it seems preferable to go with the same > precedence as ++. > I don't know, and I don't know that anyone can know what other operators people have used in code that uses HughesPJ or any of the other pretty printer combinator libraries. Most compelling, is that there is an implicit 'infixr 5 :' in the Prelude and the pretty printer combinator libraries use [Doc] all over the place. So moving one level down would break a lot of pretty printer client code. As a happy side note Text.PrettyPrint.Leijen already contains infixr 6 <> and requires no changes other than the optional cleanup of using the new operator. ;) -Edward Kmett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090918/1d0dcd11/attachment-0001.html From valery.vv at gmail.com Sat Sep 19 02:00:50 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Sat Sep 19 01:39:20 2009 Subject: [patch] #562: cabal-install update fails going through a HTTP proxy In-Reply-To: <1253319466.32005.432.camel@localhost> References: <87ab0rc475.fsf@gmail.com> <1253319466.32005.432.camel@localhost> Message-ID: On Sat, Sep 19, 2009 at 3:17 AM, Duncan Coutts wrote: > But that is exactly what makes me think it's a bug in the HTTP library. > The HTTP library provides instances for String, strict ByteString and > lazy ByteString. With one instance provided by the HTTP library your > test program fails and with the other it works. I see... > It not completely implausible that it could be the fault of the way we > use the HTTP library. For example if we were holding onto the lazy > ByteString for a long period without demanding all of it then perhaps > that could upset the network flow by causing timeouts or something, > however I don't think anything like that is going on here. The code > pretty swiftly takes the response and writes the content out to disk. > > As I mentioned in the Cabal ticket, I'd be very interested in hearing > Sigbjorn's diagnosis before considering whether we want to work around > the problem by switching to strict ByteString. If at all possible I > would prefer to stick to lazy ByteString. Okay, let's wait then. Thank you, Duncan. -- vvv From jon.fairbairn at cl.cam.ac.uk Sat Sep 19 06:14:25 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Sat Sep 19 05:53:17 2009 Subject: Proposal: add new function "check" to Control.Monad References: <20090917152847.GA21564@soi.city.ac.uk> Message-ID: Ross Paterson writes: > On Thu, Sep 17, 2009 at 04:15:15PM +0100, Jon Fairbairn wrote: >> So I've formally proposed mfilter instead. I imagine that I should close >> this ticket: is the correct resolution "wontfix"? > > Yes OK, done. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From felipe.lessa at gmail.com Sat Sep 19 08:46:49 2009 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Sat Sep 19 08:25:22 2009 Subject: [patch] #562: cabal-install update fails going through a HTTP proxy In-Reply-To: <87ab0rc475.fsf@gmail.com> References: <87ab0rc475.fsf@gmail.com> Message-ID: <20090919124649.GB18055@kira.casa> On Sat, Sep 19, 2009 at 12:50:54AM +0300, Valery V. Vorotyntsev wrote: > ...And could anyone explain me, why don't lazy ByteString cause cropped > downloads in proxy-free environment? What about a lazy ByteString with rnf as soon as possible? -- Felipe. From thomas.dubuisson at gmail.com Sat Sep 19 16:34:48 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sat Sep 19 16:13:18 2009 Subject: Fwd: Delivery Status Notification (Failure) In-Reply-To: <0016e6480644bb06e90473f42651@googlemail.com> References: <4c44d90b0909191332k21fe4b02ic7554038c74acf77@mail.gmail.com> <0016e6480644bb06e90473f42651@googlemail.com> Message-ID: <4c44d90b0909191334v76e446f0h8671ce41ff5f61c@mail.gmail.com> Ross, I'm sending this to you as the last uploader for hsc2hs. The .cabal needs some minor fixes and the maintainer e-mail seems broken. Should this be taken over by libraries@h.o? Thomas ---------- Forwarded message ---------- From: Mail Delivery Subsystem Date: Sat, Sep 19, 2009 at 1:32 PM Subject: Delivery Status Notification (Failure) To: thomas.dubuisson@gmail.com This is an automatically generated Delivery Status Notification Delivery to the following recipient failed permanently: ? ? cvs-fptools@haskell.org Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 : User unknown in local recipient table (state 14). ? ----- Original message ----- MIME-Version: 1.0 Received: by 10.220.89.158 with SMTP id e30mr3359450vcm.93.1253392364295; Sat, ? ? ? ?19 Sep 2009 13:32:44 -0700 (PDT) Date: Sat, 19 Sep 2009 13:32:44 -0700 Message-ID: <4c44d90b0909191332k21fe4b02ic7554038c74acf77@mail.gmail.com> Subject: hsc2hs .cabal change needed From: Thomas DuBuisson To: cvs-fptools@haskell.org Content-Type: text/plain; charset=ISO-8859-1 The hsc2hs package on hackage needs updated to include 'process' and 'directory' packages as deps. Thomas ? ----- End of message ----- From duncan.coutts at worc.ox.ac.uk Sat Sep 19 16:47:32 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Sep 19 16:26:01 2009 Subject: [patch] #562: cabal-install update fails going through a HTTP proxy In-Reply-To: <20090919124649.GB18055@kira.casa> References: <87ab0rc475.fsf@gmail.com> <20090919124649.GB18055@kira.casa> Message-ID: <1253393252.32005.1676.camel@localhost> On Sat, 2009-09-19 at 09:46 -0300, Felipe Lessa wrote: > On Sat, Sep 19, 2009 at 12:50:54AM +0300, Valery V. Vorotyntsev wrote: > > ...And could anyone explain me, why don't lazy ByteString cause cropped > > downloads in proxy-free environment? > > What about a lazy ByteString with rnf as soon as possible? That's essentially what we are doing by writing the result to file. Duncan From duncan.coutts at worc.ox.ac.uk Sat Sep 19 19:19:33 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Sep 19 19:00:24 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <7fb8f82f0909181733o5ee806b4j58f983354c18d08@mail.gmail.com> References: <20090917133748.GA20813@soi.city.ac.uk> <1253272734.19215.7948.camel@localhost> <7fb8f82f0909180704r4238a97cy27aa5f2194be1839@mail.gmail.com> <1253309280.32005.254.camel@localhost> <7fb8f82f0909181733o5ee806b4j58f983354c18d08@mail.gmail.com> Message-ID: <1253402373.32005.1981.camel@localhost> On Fri, 2009-09-18 at 20:33 -0400, Edward Kmett wrote: > > I don't know, and I don't know that anyone can know what other > operators people have used in code that uses HughesPJ or any of the > other pretty printer combinator libraries. Most compelling, is that > there is an implicit 'infixr 5 :' in the Prelude and the pretty > printer combinator libraries use [Doc] all over the place. So moving > one level down would break a lot of pretty printer client code. Yep, fair enough. infixr 6 <> it is then :-) Sadly it looks like we're too late to change base before ghc-6.12.1, so this will probably only make it into a released base version in a year's time. :-( Duncan From dominic at steinitz.org Sun Sep 20 03:37:37 2009 From: dominic at steinitz.org (Dominic Steinitz) Date: Sun Sep 20 02:24:44 2009 Subject: Windows Install Issues for erf (and statistics) Message-ID: <4AB5DBC1.1010802@steinitz.org> The package statistics uses the package erf. Doing cabal install statistics works fine but when I try to use anything I get: > Loading package syb ... linking ... done. > Loading package base-3.0.3.0 ... linking ... done. > Loading package erf-1.0.0.0 ... linking ... : > C:\Program Files\Haskell\erf-1.0.0.0\ghc-6.10.1\HSerf-1.0.0.0.o: unknown symbol > `_erfc' > : unable to load package `erf-1.0.0.0' I assume that erf is looking for some C functions which are available on linux but not windows. I'm not sure what the solution is. Should cabal complain? Should there be some documentation on the erf homepage telling windows users what to do? Or at least that it doesn't work on windows? Dominic. From lennart at augustsson.net Sun Sep 20 07:22:17 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun Sep 20 07:00:44 2009 Subject: Windows Install Issues for erf (and statistics) In-Reply-To: <4AB5DBC1.1010802@steinitz.org> References: <4AB5DBC1.1010802@steinitz.org> Message-ID: I complained about the very same thing, I think there's even a ghc bug report about it. It's something about how symbols are looked up and loaded in ghci. I've not been able to come up with a workaround either. -- Lennart On Sun, Sep 20, 2009 at 3:37 PM, Dominic Steinitz wrote: > The package statistics uses the package erf. Doing cabal install statistics > works fine but when I try to use anything I get: > >> Loading package syb ... linking ... done. >> Loading package base-3.0.3.0 ... linking ... done. >> Loading package erf-1.0.0.0 ... linking ... : >> C:\Program Files\Haskell\erf-1.0.0.0\ghc-6.10.1\HSerf-1.0.0.0.o: unknown >> symbol >> `_erfc' >> : unable to load package `erf-1.0.0.0' > > I assume that erf is looking for some C functions which are available on > linux but not windows. > > I'm not sure what the solution is. Should cabal complain? Should there be > some documentation on the erf homepage telling windows users what to do? Or > at least that it doesn't work on windows? > > Dominic. > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From ross at soi.city.ac.uk Sun Sep 20 10:12:03 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Sep 20 09:50:30 2009 Subject: hsc2hs In-Reply-To: <4c44d90b0909191334v76e446f0h8671ce41ff5f61c@mail.gmail.com> References: <4c44d90b0909191332k21fe4b02ic7554038c74acf77@mail.gmail.com> <0016e6480644bb06e90473f42651@googlemail.com> <4c44d90b0909191334v76e446f0h8671ce41ff5f61c@mail.gmail.com> Message-ID: <20090920141203.GA5257@soi.city.ac.uk> On Sat, Sep 19, 2009 at 01:34:48PM -0700, Thomas DuBuisson wrote: > I'm sending this to you as the last uploader for hsc2hs. The .cabal > needs some minor fixes and the maintainer e-mail seems broken. Should > this be taken over by libraries@h.o? Sure. From marlowsd at gmail.com Mon Sep 21 05:38:52 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Sep 21 05:17:23 2009 Subject: Windows Install Issues for erf (and statistics) In-Reply-To: References: <4AB5DBC1.1010802@steinitz.org> Message-ID: <4AB749AC.7090303@gmail.com> I couldn't find anything - happy to look into it if someone points me to the ticket. Cheers, Simon On 20/09/2009 12:22, Lennart Augustsson wrote: > I complained about the very same thing, I think there's even a ghc bug > report about it. > It's something about how symbols are looked up and loaded in ghci. > I've not been able to come up with a workaround either. > > -- Lennart > > On Sun, Sep 20, 2009 at 3:37 PM, Dominic Steinitz wrote: >> The package statistics uses the package erf. Doing cabal install statistics >> works fine but when I try to use anything I get: >> >>> Loading package syb ... linking ... done. >>> Loading package base-3.0.3.0 ... linking ... done. >>> Loading package erf-1.0.0.0 ... linking ...: >>> C:\Program Files\Haskell\erf-1.0.0.0\ghc-6.10.1\HSerf-1.0.0.0.o: unknown >>> symbol >>> `_erfc' >>> : unable to load package `erf-1.0.0.0' >> >> I assume that erf is looking for some C functions which are available on >> linux but not windows. >> >> I'm not sure what the solution is. Should cabal complain? Should there be >> some documentation on the erf homepage telling windows users what to do? Or >> at least that it doesn't work on windows? >> >> Dominic. >> >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From marlowsd at gmail.com Mon Sep 21 07:00:30 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Sep 21 06:38:59 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" Message-ID: <4AB75CCE.1060709@gmail.com> See http://hackage.haskell.org/trac/ghc/ticket/2034 to which I have attached a fairly simple patch. All the tests pass. The main change is that splitFileName "foo" = (".", "foo") and takeDirectory "foo" = "." and "." x = x Discussion period: 2 weeks (5 October) Cheers, Simon From dominic at steinitz.org Mon Sep 21 17:14:53 2009 From: dominic at steinitz.org (Dominic Steinitz) Date: Mon Sep 21 16:02:04 2009 Subject: Windows Install Issues for erf (and statistics) In-Reply-To: <4AB749AC.7090303@gmail.com> References: <4AB5DBC1.1010802@steinitz.org> <4AB749AC.7090303@gmail.com> Message-ID: <4AB7ECCD.90906@steinitz.org> Simon Marlow wrote: > I couldn't find anything - happy to look into it if someone points me to > the ticket. > I think this is it: http://hackage.haskell.org/trac/ghc/ticket/3513 Also this looks relevant: http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/17456 From marlowsd at gmail.com Tue Sep 22 08:43:43 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Sep 22 08:22:09 2009 Subject: Windows Install Issues for erf (and statistics) In-Reply-To: <4AB7ECCD.90906@steinitz.org> References: <4AB5DBC1.1010802@steinitz.org> <4AB749AC.7090303@gmail.com> <4AB7ECCD.90906@steinitz.org> Message-ID: <4AB8C67F.8050302@gmail.com> On 21/09/2009 22:14, Dominic Steinitz wrote: > Simon Marlow wrote: >> I couldn't find anything - happy to look into it if someone points me to >> the ticket. >> > I think this is it: > > http://hackage.haskell.org/trac/ghc/ticket/3513 The problem there seems to be that the network library is calling functions that do not exist on older versions of Windows. I don't think there's anything that GHC can do about that. > Also this looks relevant: > > http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/17456 Something C++ specific, by the looks of it. Are you sure the problem you had isn't just that the C erfc function is not available on Windows? Oh, perhaps the problem that Lennart is referring to is that when GHCi loads up a package it requires that all the symbols in the package can be resolved, whereas when you statically link a .a library we only have to resolve the symbols required by the library modules that the program actually refers to. So one workaround would be to link in a dummy erfc() function, or alternatively hack the erf pacakge so that it omits the offending parts on Windows. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Tue Sep 22 11:43:11 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Sep 22 11:21:45 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <4AB75CCE.1060709@gmail.com> References: <4AB75CCE.1060709@gmail.com> Message-ID: <1253634191.18961.3032.camel@localhost> On Mon, 2009-09-21 at 12:00 +0100, Simon Marlow wrote: > The main change is that > > splitFileName "foo" = (".", "foo") > > and > > takeDirectory "foo" = "." > > and > > "." x = x So to re-iterate the point made in the ticket, the principle here is that the representation of the current directory is "." and not "". This lets us safely use results of System.FilePath functions as arguments to system and directory functions without having to check for "". However the principle is not without exception, we also want to elide the explicit representation of the current directory when it is not needed. If these are the principles then can we look at whether we apply them elsewhere in System.FilePath consistently? What about: joinPath [".", "foo"] should it be "./foo" or "foo" ? If "./foo" then it's not the same as , if the latter then we loose the property Valid x => joinPath (splitPath x) == x it would be some kind of limited normalisation. So I'm happy with the first two changes, I'm less convinced about changing to elide "." on the left. Perhaps people who worry about leading "./" when the FilePath is displayed to the user should just use normalise. That's what they do now and we seem to get along ok. Some people have mentioned before that some systems (though not the native low level POSIX interfaces) do actually distinguish "./blah/blah" from "blah/blah". The distinction is whether a file is relative to the current directory or to some other unspecified root (eg a search path). Unix shells make this distinction for example when running "a.out" vs "./a.out". The latter is independent of the current $PATH, it really refers to the one in the current directory, not any such file on the $PATH. On a related note, when I have experimented with designing a typed version of FilePath, one of the things I wanted to distinguish in the types is exactly this thing about "relative to something specific" (eg relative to "/" or ".") vs "relative to something not yet specified". Another terminology might be "complete" and "incomplete". The OS file manipulation functions would only work on complete filepaths. Duncan From bos at serpentine.com Tue Sep 22 12:17:42 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Sep 22 11:56:01 2009 Subject: Windows Install Issues for erf (and statistics) In-Reply-To: <4AB8C67F.8050302@gmail.com> References: <4AB5DBC1.1010802@steinitz.org> <4AB749AC.7090303@gmail.com> <4AB7ECCD.90906@steinitz.org> <4AB8C67F.8050302@gmail.com> Message-ID: On Tue, Sep 22, 2009 at 5:43 AM, Simon Marlow wrote: > Are you sure the problem you had isn't just that the C erfc function is not > available on Windows? > I looked for it, and I can't find any documentation on MSDN, outside of Excel functions. I have a BSD-licensed C implementation of the function, so we can get that package working on all platforms if desired. Lennart? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090922/15c43939/attachment.html From lennart at augustsson.net Tue Sep 22 12:37:00 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Sep 22 12:15:19 2009 Subject: Windows Install Issues for erf (and statistics) In-Reply-To: References: <4AB5DBC1.1010802@steinitz.org> <4AB749AC.7090303@gmail.com> <4AB7ECCD.90906@steinitz.org> <4AB8C67F.8050302@gmail.com> Message-ID: I'll look into it at work tomorrow. The problem I had before was that it worked in ghc, but not ghci. If there's no bug report I'll file one. -- Lennart On Wed, Sep 23, 2009 at 12:17 AM, Bryan O'Sullivan wrote: > On Tue, Sep 22, 2009 at 5:43 AM, Simon Marlow wrote: >> >> Are you sure the problem you had isn't just that the C erfc function is >> not available on Windows? > > I looked for it, and I can't find any documentation on MSDN, outside of > Excel functions. > > I have a BSD-licensed C implementation of the function, so we can get that > package working on all platforms if desired. Lennart? > From marlowsd at gmail.com Wed Sep 23 04:03:54 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Sep 23 03:42:17 2009 Subject: Windows Install Issues for erf (and statistics) In-Reply-To: References: <4AB5DBC1.1010802@steinitz.org> <4AB749AC.7090303@gmail.com> <4AB7ECCD.90906@steinitz.org> <4AB8C67F.8050302@gmail.com> Message-ID: <4AB9D66A.7070303@gmail.com> On 22/09/2009 17:37, Lennart Augustsson wrote: > I'll look into it at work tomorrow. The problem I had before was that > it worked in ghc, but not ghci. > If there's no bug report I'll file one. I wouldn't say it was a bug - the function really doesn't exist, and the library really does refer to it (AIUI). The reason that ghc behaves differently from ghci is that you don't have to link all the symbols from a .a library. The same problem will occur in ghc if the package is compiled to a shared library or DLL. Cheers, Simon > -- Lennart > > On Wed, Sep 23, 2009 at 12:17 AM, Bryan O'Sullivan wrote: >> On Tue, Sep 22, 2009 at 5:43 AM, Simon Marlow wrote: >>> >>> Are you sure the problem you had isn't just that the C erfc function is >>> not available on Windows? >> >> I looked for it, and I can't find any documentation on MSDN, outside of >> Excel functions. >> >> I have a BSD-licensed C implementation of the function, so we can get that >> package working on all platforms if desired. Lennart? >> From marlowsd at gmail.com Wed Sep 23 05:51:57 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Sep 23 05:30:19 2009 Subject: Windows Install Issues for erf (and statistics) In-Reply-To: References: <4AB5DBC1.1010802@steinitz.org> <4AB749AC.7090303@gmail.com> <4AB7ECCD.90906@steinitz.org> <4AB8C67F.8050302@gmail.com> Message-ID: <4AB9EFBD.6050903@gmail.com> On 23/09/2009 10:35, Dominic.Steinitz@barclayscapital.com wrote: > > >> -----Original Message----- >> From: Simon Marlow [mailto:marlowsd@gmail.com] >> Sent: 22 September 2009 13:44 >> To: Dominic Steinitz >> Cc: Lennart Augustsson; Steinitz, Dominic: Markets (LDN); > cabal-devel@haskell.org; libraries@haskell.org >> Subject: Re: Windows Install Issues for erf (and statistics) >> >> Are you sure the problem you had isn't just that the C erfc function > is not available on Windows? >> >> Oh, perhaps the problem that Lennart is referring to is that when GHCi > loads up a package it requires that all the symbols in> the package can > be resolved, whereas when you statically link a .a library we only have > to resolve the symbols required by the> library modules that the > program actually refers to. > > That may be it. If I use ghc all works: > > C:\p4wksp\steinitd_fpf_virgin_ws\FPF_Dev.br\src>ghc > -package-conf=..\ThirdParty\ghc\ghc-6.10.1\fpf.package.conf --make > Paths.hs -o Paths.exe > > C:\p4wksp\steinitd_fpf_virgin_ws\FPF_Dev.br\src>Paths.exe > [0.0,-0.3701728565440763,-0.43078071862053197,-1.2205246923473059,-1.294 > 0085383906827] > > But if I use ghci: > > Prelude> :l Paths.hs > [1 of 1] Compiling Main ( Paths.hs, interpreted ) > Ok, modules loaded: Main. > *Main> main > Loading package syb ... linking ... done. > Loading package base-3.0.3.0 ... linking ... done. > Loading package bytestring-0.9.1.4 ... linking ... done. > Loading package Win32-2.2.0.0 ... linking ... done. > Loading package old-locale-1.0.0.1 ... linking ... done. > Loading package time-1.1.2.2 ... linking ... done. > Loading package uvector-0.1.0.4 ... linking ... done. > Loading package erf-1.0.0.0 ... linking ...: > C:/p4wksp/steinitd_fpf_virgin_ws/FPF_Dev.br/src/../thirdparty/haskell_pa > ckages\erf-1.0.0.0\ghc-6.10.1\HSerf-1.0.0.0.o: unknown symbol `_erfc' > : unable to load package `erf-1.0.0.0' > > >> So one workaround would be to link in a dummy erfc() function, or > alternatively hack the erf pacakge so that it omits the >> offending parts on Windows. > > I'll probably do the latter for the time being but is there something > that could be done to ghci to stop it complaining in the case of other > similar situations? It would mean doing some kind of lazy linking, and would be pretty tricky I think. In any case, it will only fail again when we start using shared libraries with GHCi, so I don't think it's worth tackling. (or maybe it will work with shared libraries; either way I don't think we should worry about doing anything in GHC's linker :-) Cheers, Simon From vandijk.roel at gmail.com Wed Sep 23 07:45:34 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Wed Sep 23 07:23:51 2009 Subject: Proposal #3537: Add missing NFData instances to parallel Message-ID: Control.Parallel.Strategies contains many NFData instances for types defined in base, but not all. I propose adding NFData instances for all types in base where it makes sense. The specific issue I had was with Data.Version. I wanted to 'rnf' some type which contained a Version, but it had no instance for NFData. The only solution is to add an instance in your own code, where it doesn't really belong. Therefor I checked the base package for other other types which also lacked an NFData instance. I would like some feedback on the instances for STRef and IORef. Does it make sense to have them? I used a trick to force their evaluation since their constructors are not exported. Discussion deadline: October 7 Ticket: http://hackage.haskell.org/trac/ghc/ticket/3537 Regards, Roel van Dijk From marlowsd at gmail.com Wed Sep 23 09:17:58 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Sep 23 08:56:54 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <1253634191.18961.3032.camel@localhost> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> Message-ID: <4ABA2006.7010809@gmail.com> On 22/09/2009 16:43, Duncan Coutts wrote: > On Mon, 2009-09-21 at 12:00 +0100, Simon Marlow wrote: > > >> The main change is that >> >> splitFileName "foo" = (".", "foo") >> >> and >> >> takeDirectory "foo" = "." >> >> and >> >> "." x = x > > So to re-iterate the point made in the ticket, the principle here is > that the representation of the current directory is "." and not "". This > lets us safely use results of System.FilePath functions as arguments to > system and directory functions without having to check for "". > > However the principle is not without exception, we also want to elide > the explicit representation of the current directory when it is not > needed. > > If these are the principles then can we look at whether we apply them > elsewhere in System.FilePath consistently? > > What about: > > joinPath [".", "foo"] > > should it be "./foo" or "foo" ? > > If "./foo" then it's not the same as, if the latter then we loose > the property > > Valid x => joinPath (splitPath x) == x > > it would be some kind of limited normalisation. > > So I'm happy with the first two changes, I'm less convinced about > changing to elide "." on the left. Perhaps people who worry about > leading "./" when the FilePath is displayed to the user should just use > normalise. That's what they do now and we seem to get along ok. So this subject was discussed between Ian and myself in the original thread, see e.g. http://www.haskell.org/pipermail/libraries/2007-December/008776.html The conclusion was that in the filesystem semantics "./foo" is equal to "foo", but the string passed to rawSystem (and execp()) is not a FilePath, it is something like Either FilePath String. However, there are some oddities with the current proposal. e.g. splitFileName "./foo" == ("./", "foo") "./" "foo" == "./foo" The current proposal just about hangs together because the tiny bit of normalisation that does exactly undoes the creation of "." in splitFileName, and there's no other way that splitFileName can generate ".". That's a terribly fragile property. If we "fixed" to do more normalisation, then we would no longer have the property that uncurry () (splitFileName x) == x (*1) I don't actually care about the details here as long as we have a story that is reasonably consistent. My main concern is that isValid x => isValid (takeDirectory x) the lack of which is the main problem with the current formulation, as you (Duncan) mentioned above. Perhaps we should drop the magic normalisation that does, and apply the normalise function to both sides of (*1). There would probably be a bunch more properties that would have to change too, I'm guessing that normalise would proliferate. Incedentally, I dislike the way that trailing slashes are treated in the current filepath implementation. A trailing slash is significant in POSIX: $ ls -l foo lrwxrwxrwx 1 simonmar GHC 15 2009-09-23 14:04 foo -> /does/not/exist $ ls foo foo@ $ ls foo/ ls: cannot access foo/: No such file or directory The path with the trailing slash dereferences a symbolic link, and may fail if the link points nowhere. I think trailing slashes should be dropped by splitFileName. Cheers, Simon From bulat.ziganshin at gmail.com Wed Sep 23 09:36:36 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Sep 23 09:15:01 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <4ABA2006.7010809@gmail.com> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> Message-ID: <1299617431.20090923173636@gmail.com> Hello Simon, Wednesday, September 23, 2009, 5:17:58 PM, you wrote: >>> The main change is that let me ask another question - are it's expected to raise FilePath library major version number? i ask as developer who is used copy of FilePath deep inside of my program. if i rely on hackage for providing the library, it was very unpleasant to see that program has become buggy w/o any notice with new version of FilePath incompatible with previous one from this POV, it was much better to provide one more function for doing new thing. you, GHC developers, use a lot of libraries built-in in GHC source tree. just imagine what you start using hackage and discovered that you need to fix a lot of bugs appeared in your program after every major GHC release -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From marlowsd at gmail.com Wed Sep 23 09:37:53 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Sep 23 09:16:15 2009 Subject: Windows Install Issues for erf (and statistics) In-Reply-To: <4AB9D66A.7070303@gmail.com> References: <4AB5DBC1.1010802@steinitz.org> <4AB749AC.7090303@gmail.com> <4AB7ECCD.90906@steinitz.org> <4AB8C67F.8050302@gmail.com> <4AB9D66A.7070303@gmail.com> Message-ID: <4ABA24B1.20107@gmail.com> On 23/09/2009 09:03, Simon Marlow wrote: > On 22/09/2009 17:37, Lennart Augustsson wrote: >> I'll look into it at work tomorrow. The problem I had before was that >> it worked in ghc, but not ghci. >> If there's no bug report I'll file one. > > I wouldn't say it was a bug - the function really doesn't exist, and the > library really does refer to it (AIUI). The reason that ghc behaves > differently from ghci is that you don't have to link all the symbols > from a .a library. The same problem will occur in ghc if the package is > compiled to a shared library or DLL. It seems I'm wrong - the problem is really that erf() and friends come from the static libmingwex.a library, which doesn't have a DLL equivalent and therefore aren't available under GHCi. erf and co will have to join the long list of symbols in GHCi's linker that have the same unfortunate property. This is of course not a sustainable process. If we ever do a truly native Windows port with no MinGW libraries then the problem with reoccur (but at least it will behave consistently across GHC and GHCi). Cheers, Simon From marlowsd at gmail.com Wed Sep 23 09:40:36 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Sep 23 09:18:57 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <1299617431.20090923173636@gmail.com> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> <1299617431.20090923173636@gmail.com> Message-ID: <4ABA2554.4050003@gmail.com> On 23/09/2009 14:36, Bulat Ziganshin wrote: > Hello Simon, > > Wednesday, September 23, 2009, 5:17:58 PM, you wrote: > >>>> The main change is that > > let me ask another question - are it's expected to raise FilePath > library major version number? Yes, this is an incompatible change and would therefore warrant a version number bump. OTOH, I validated GHC with this change and it worked without modification. Cheers, Simon From greg at gregorycollins.net Wed Sep 23 11:52:54 2009 From: greg at gregorycollins.net (Gregory Collins) Date: Wed Sep 23 11:31:10 2009 Subject: Proposal #3537: Add missing NFData instances to parallel In-Reply-To: (Roel van Dijk's message of "Wed, 23 Sep 2009 13:45:34 +0200") References: Message-ID: <87my4lr73d.fsf@gregorycollins.net> Roel van Dijk writes: > I would like some feedback on the instances for STRef and > IORef. Does it make sense to have them? I used a trick to force > their evaluation since their constructors are not exported. This might be "dirty" but what about this instead? instance (NFData a) => NFData (Data.IORef.IORef a) where rnf r = unsafePerformIO $ modifyIORef r (`using` rnf) G. -- Gregory Collins From vandijk.roel at gmail.com Wed Sep 23 13:46:58 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Wed Sep 23 13:25:15 2009 Subject: Proposal #3537: Add missing NFData instances to parallel In-Reply-To: <87my4lr73d.fsf@gregorycollins.net> References: <87my4lr73d.fsf@gregorycollins.net> Message-ID: > This might be "dirty" but what about this instead? > > ? ?instance (NFData a) => NFData (Data.IORef.IORef a) where > ? ? ? ?rnf r = unsafePerformIO $ modifyIORef r (`using` rnf) Hmm, I don't know. The question is whether you want to evaluate the value stored inside of the IORef. I think that any function that evaluates a value inside of an IORef should be in the IO monad. I wouldn't expect a function with the type "a -> ()" to be able to "look into" an IORef. The reason I made an NFData instance for IORef is for a situation like this: test :: IO () test = do x <- newIORef () y <- newIORef () let z | hugeConditionalExpression = x | otherwise = y rnf z `seq` doSomething You might want to force z to head normal form to force the evaluation of the hugeConditionalExpression. From wren at community.haskell.org Thu Sep 24 01:20:50 2009 From: wren at community.haskell.org (wren ng thornton) Date: Thu Sep 24 00:59:07 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <1253634191.18961.3032.camel@localhost> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> Message-ID: <4ABB01B2.9000805@community.haskell.org> Duncan Coutts wrote: > Some people have mentioned before that some systems (though not the > native low level POSIX interfaces) do actually distinguish "./blah/blah" > from "blah/blah". The distinction is whether a file is relative to the > current directory or to some other unspecified root (eg a search path). > Unix shells make this distinction for example when running "a.out" vs > "./a.out". The latter is independent of the current $PATH, it really > refers to the one in the current directory, not any such file on the > $PATH. Just for reference, this comes up with shell settings other than just $PATH as well. For instance, cd in Bash looks through $CDPATH in the same way command selection looks through $PATH (i.e. the default value is "." which is sensible, but some folks like ".:~" to make their home dir everywhere, and you can do crazier things). And various other programs have their own $*PATH variables. > On a related note, when I have experimented with designing a typed > version of FilePath, one of the things I wanted to distinguish in the > types is exactly this thing about "relative to something specific" (eg > relative to "/" or ".") vs "relative to something not yet specified". > Another terminology might be "complete" and "incomplete". The OS file > manipulation functions would only work on complete filepaths. I like this distinction. Regardless of the settlement of "" vs "./", it is helpful to distinguish "paths being built" (and therefore potentially invalid) from "real paths" anchored to the file system. -- Live well, ~wren From marlowsd at gmail.com Thu Sep 24 05:40:43 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Sep 24 05:19:02 2009 Subject: Proposal #3537: Add missing NFData instances to parallel In-Reply-To: References: <87my4lr73d.fsf@gregorycollins.net> Message-ID: <4ABB3E9B.5020700@gmail.com> On 23/09/2009 18:46, Roel van Dijk wrote: >> This might be "dirty" but what about this instead? >> >> instance (NFData a) => NFData (Data.IORef.IORef a) where >> rnf r = unsafePerformIO $ modifyIORef r (`using` rnf) > > Hmm, I don't know. The question is whether you want to evaluate the > value stored inside of the IORef. I think that any function that > evaluates a value inside of an IORef should be in the IO monad. I > wouldn't expect a function with the type "a -> ()" to be able to "look > into" an IORef. > > The reason I made an NFData instance for IORef is for a situation like this: > > test :: IO () > test = do x<- newIORef () > y<- newIORef () > let z | hugeConditionalExpression = x > | otherwise = y > rnf z `seq` doSomething > > You might want to force z to head normal form to force the evaluation > of the hugeConditionalExpression. what's wrong with instance NFData (Data.IORef.IORef a) where rnf r = r `seq` () ? Cheers, Simon From vandijk.roel at gmail.com Thu Sep 24 05:53:45 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Thu Sep 24 05:32:00 2009 Subject: Proposal #3537: Add missing NFData instances to parallel In-Reply-To: <4ABB3E9B.5020700@gmail.com> References: <87my4lr73d.fsf@gregorycollins.net> <4ABB3E9B.5020700@gmail.com> Message-ID: > what's wrong with > > instance NFData (Data.IORef.IORef a) where > ? ?rnf r = r `seq` () Ah, you are right. I was being to clever for my own good :-) Perhaps it works for all types where I used the "rnf x = rnf (x == x)" trick. Should I attach a new patch to the ticket with those definitions changed? From marlowsd at gmail.com Thu Sep 24 08:18:14 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Sep 24 07:56:32 2009 Subject: Proposal #3537: Add missing NFData instances to parallel In-Reply-To: References: <87my4lr73d.fsf@gregorycollins.net> <4ABB3E9B.5020700@gmail.com> Message-ID: <4ABB6386.9040105@gmail.com> On 24/09/2009 10:53, Roel van Dijk wrote: >> what's wrong with >> >> instance NFData (Data.IORef.IORef a) where >> rnf r = r `seq` () > > Ah, you are right. I was being to clever for my own good :-) Perhaps > it works for all types where I used the "rnf x = rnf (x == x)" > trick. Should I attach a new patch to the ticket with those > definitions changed? Sure, that would be helpful. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Thu Sep 24 13:20:08 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 24 12:58:49 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <4ABA2006.7010809@gmail.com> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> Message-ID: <1253812808.18961.6288.camel@localhost> On Wed, 2009-09-23 at 14:17 +0100, Simon Marlow wrote: > > So I'm happy with the first two changes, I'm less convinced about > > changing to elide "." on the left. Perhaps people who worry about > > leading "./" when the FilePath is displayed to the user should just use > > normalise. That's what they do now and we seem to get along ok. > > So this subject was discussed between Ian and myself in the original > thread, see e.g. > > http://www.haskell.org/pipermail/libraries/2007-December/008776.html > > The conclusion was that in the filesystem semantics "./foo" is equal to > "foo", but the string passed to rawSystem (and execp()) is not a > FilePath, it is something like Either FilePath String. Right. The file system OS calls take complete file paths, relative to "/" or implicitly relative to ".". system/rawSystem (and some other libs) take either a complete filepath, or an incomplete one which they then complete relative to some search path. In my experimental typed filepath it'd be Either CompletePath IncompletePath. So I would consider both as file paths (though different types). System.FilePath is pretty good for manipulating incomplete (relative) paths so I think it'd be a shame to declare that what rawSystem takes is not a FilePath and thus we do not need to consider functions of its ilk. > However, there are some oddities with the current proposal. e.g. > > splitFileName "./foo" == ("./", "foo") > "./" "foo" == "./foo" > > The current proposal just about hangs together because the tiny bit of > normalisation that does exactly undoes the creation of "." in > splitFileName, and there's no other way that splitFileName can generate > ".". That's a terribly fragile property. So if we take the first bit of your proposal and not the second we have: splitFileName "foo" == ("./", "foo") "./" "foo" == "./foo" and thus we do not have: uncurry () (splitFileName x) == x because we end up with "foo" an "./foo" However I think that's fine. The splitFileName function is asking for the directory part of a relative/incomplete filepath and expecting it to be a real directory. Thus we are interpreting the original filepath as a complete filepath that is relative to ".". So given that by applying splitFileName we are taking that interpretation it's ok to get back "./foo", because we in that context we really were interpreting "foo" as "./foo". > If we "fixed" to do more normalisation, then we would no longer have > the property that > > uncurry () (splitFileName x) == x (*1) > > > I don't actually care about the details here as long as we have a story > that is reasonably consistent. My main concern is that > > isValid x => isValid (takeDirectory x) > > the lack of which is the main problem with the current formulation, as > you (Duncan) mentioned above. Right. > Perhaps we should drop the magic normalisation that does, and apply > the normalise function to both sides of (*1). There would probably be a > bunch more properties that would have to change too, I'm guessing that > normalise would proliferate. We don't want full normalise, it does too much. So the interpretation I quite like is the complete/incomplete one. Under that model splitFileName can be used for both complete and incomplete paths. splitFileName :: AnyFilePath path => path -> (path, IncompletePath) For complete paths we get back a complete directory part and an incomplete relative path for the filename. For incomplete paths we get back another incomplete directory part. What you want though in the existing untyped interface is that takeDirectory gives you a complete path (so you can pass it to system function), which means the input must also have been a complete path. I think this interpretation justifies: uncurry () (splitFileName "foo") == "./foo" In a typed version we could have both interpretations depending on the type and the property would hold in both I think. Does that help or just add more mud? :-) > Incedentally, I dislike the way that trailing slashes are treated in the > current filepath implementation. A trailing slash is significant in POSIX: > > $ ls -l foo > lrwxrwxrwx 1 simonmar GHC 15 2009-09-23 14:04 foo -> /does/not/exist > $ ls foo > foo@ > $ ls foo/ > ls: cannot access foo/: No such file or directory > > The path with the trailing slash dereferences a symbolic link, and may > fail if the link points nowhere. > > I think trailing slashes should be dropped by splitFileName. I don't follow. Isn't it exactly because they are significant that they should be preserved. There are System.FilePath functions for testing for, adding and removing trailing slashes. Duncan From vandijk.roel at gmail.com Thu Sep 24 16:23:40 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Thu Sep 24 16:01:53 2009 Subject: Proposal #3537: Add missing NFData instances to parallel In-Reply-To: <4ABB6386.9040105@gmail.com> References: <87my4lr73d.fsf@gregorycollins.net> <4ABB3E9B.5020700@gmail.com> <4ABB6386.9040105@gmail.com> Message-ID: >> Ah, you are right. I was being to clever for my own good :-) Perhaps >> it works for all types where I used the "rnf x = rnf (x == x)" >> trick. Should I attach a new patch to the ticket with those >> definitions changed? > > Sure, that would be helpful. I have updated the patch attached to the ticket. From lemming at henning-thielemann.de Thu Sep 24 19:16:31 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Sep 24 18:54:45 2009 Subject: Proposal #3339: Add (+>) as a synonym for mappend In-Reply-To: <20090917133748.GA20813@soi.city.ac.uk> References: <20090917133748.GA20813@soi.city.ac.uk> Message-ID: On Thu, 17 Sep 2009, Ross Paterson wrote: > This proposal seems to have got stuck. Everyone wants an infix operator, > but we can't agree what it should be. > > I prefer using a new operator instead of generalizing ++ (or +, *, && > or ||), because I think that a monoid operation is so abstract that it > needs a name that doesn't suggest one of the special cases. (I like <>) '<>' looks like "inequality" in other languages. Apart from that, the symbol looks fine to me, too. From v.dijk.bas at gmail.com Sun Sep 27 16:51:04 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Sun Sep 27 16:29:12 2009 Subject: Add instance IsString ShowS where fromString = showString Message-ID: Hello, It would be really nice to use OverloadedStrings when constructing a ShowS, for example in a definition of showsPrec in an instance for Show. The patch attached in the ticket[3544] adds the necessary instance to base/GHC/Show.lhs: instance IsString ShowS where fromString = showString Note that this does require TypeSynonymInstances. Discussion period 2 weeks. regards, Bas [3544] http://hackage.haskell.org/trac/ghc/ticket/3544 From duncan.coutts at worc.ox.ac.uk Mon Sep 28 05:07:29 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Sep 28 04:47:14 2009 Subject: Call for consensus: Haskell Platform package additions policy In-Reply-To: <1253216158.19215.6970.camel@localhost> References: <1252965258.19215.606.camel@localhost> <1253216158.19215.6970.camel@localhost> Message-ID: <1254128849.4588.62.camel@localhost> On Thu, 2009-09-17 at 20:35 +0100, Duncan Coutts wrote: > On Mon, 2009-09-14 at 22:54 +0100, Duncan Coutts wrote: > > > We would like to get this wrapped up so that we can move on to > > discussing more guidelines/requirements on packages and indeed to > > actually proposing some packages. > > > > So far we have had a few people send in comments (thanks particularly to > > Ian and Simon) but a few more would not go amiss, even if it's just > > "yes". > > Thanks to the people who responded. I hope we're done now. I've made a > couple changes based on the feedback which I explain below. > > Are there any unresolved concerns? > > If not then we'll declare the policy adopted and we can move on to > discuss package proposals and extra package requirements/guidelines. It's been over 10 days since the call for consensus, we've had no objections and several people have been broadly supportive. I think we can declare this adopted. http://trac.haskell.org/haskell-platform/wiki/AddingPackages Duncan