Re: [Haskell-cafe] Contributing to http-conduit
Just an FYI for everyone: Myles sent an (incredibly thorough) pull request to handle cookies: https://github.com/snoyberg/http-conduit/pull/13 Thanks! On Sun, Feb 5, 2012 at 8:20 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: 1. The spec defines a grammar for the attributes. They're in uppercase. 2. Yes - 1.3 is the first version that lists DiffTime as an instance of RealFrac (so I can use the 'floor' function to pull out the number of seconds to render it) 3. I'll see what I can do. --Myles On Sat, Feb 4, 2012 at 9:06 PM, Michael Snoyman mich...@snoyman.com wrote: Looks good, a few questions/requests: 1. Is there a reason to upper-case all the attributes? 2. Is the time = 1.3 a requirements? Because that can cause a lot of trouble for people. 3. Can you send the patch as a Github pull request? It's easier to track that way. Michael On Sat, Feb 4, 2012 at 1:21 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Here is the patch to Web.Cookie. I didn't modify the tests at all because they were already broken - they looked like they hadn't been updated since SetCookie only had 5 parameters. I did verify by hand that the patch works, though. Thanks, Myles On Thu, Feb 2, 2012 at 11:26 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Alright, I'll make a small patch that adds 2 fields to SetCookie: setCookieMaxAge :: Maybe DiffTime setCookieSecureOnly :: Bool I've also gotten started on those cookie functions. I'm currently writing tests for them. @Chris: The best advice I can give is that Chrome (what I'm using as a source on all this) has the data baked into a .cc file. However, they have directions in a README and a script which will parse the list and generate that source file. I recommend doing this. That way, the Haskell module would have 2 source files: one file that reads the list and generates the second file, which is a very large source file that contains each element in the list. The list should export `elem`-type queries. I'm not quite sure how to handle wildcards that appear in the list - that part is up to you. Thanks for helping out with this :] --Myles On Thu, Feb 2, 2012 at 10:53 PM, Michael Snoyman mich...@snoyman.com wrote: Looks good to me too. I agree with Aristid: let's make the change to cookie itself. Do you want to send a pull request? I'm also considering making the SetCookie constructor hidden like we have for Request, so that if in the future we realize we need to add some other settings, it doesn't break the API. Chris: I would recommend compiling it into the module. Best bet would likely being converting the source file to Haskell source. Michael On Fri, Feb 3, 2012 at 6:32 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Alright. After reading the spec, I have these questions / concerns: The spec supports the Max-Age cookie attribute, which Web.Cookies doesn't. I see two possible solutions to this. The first is to have parseSetCookie take a UTCTime as an argument which will represent the current time so it can populate the setCookieExpires field by adding the Max-Age attribute to the current time. Alternatively, that function can return an IO SetCookie so it can ask for the current time by itself (which I think is inferior to taking the current time as an argument). Note that the spec says to prefer Max-Age over Expires. Add a field to SetCookie of type Maybe DiffTime which represents the Max-Age attribute Cookie code should be aware of the Public Suffix List as a part of its domain verification. The cookie code only needs to be able to tell if a specific string is in the list (W.Ascii - Bool) I propose making an entirely unrelated package, public-suffix-list, with a module Network.PublicSuffixList, which will expose this function, as well as functions about parsing the list itself. Thoughts? Web.Cookie doesn't have a secure-only attribute. Adding one in is straightforward enough. The spec describes cookies as a property of HTTP, not of the World Wide Web. Perhaps Web.Cookie should be renamed? Just a thought; it doesn't really matter to me. As for Network.HTTP.Conduit.Cookie, the spec describes in section 5.3 Storage Model what fields a Cookie has. Here is my proposal for the functions it will expose: receiveSetCookie :: SetCookie - Req.Request m - UTCTime - Bool - CookieJar - CookieJar Runs the algorithm described in section 5.3 Storage Model The UTCTime is the current-time, the Bool is whether or not the caller is an HTTP-based API (as opposed to JavaScript or anything else) updateCookieJar :: Res.Response a - Req.Request m - UTCTime - CookieJar - (CookieJar, Res.Response a) Applies receiveSetCookie to a Response. The output
[Haskell-cafe] Problem resolving: Hangman
Though the problem I'd ask is not quiet related to haskell, I hope talent people here could provide some suggestions. The problem is not just solve the Hangman problem but solve it in sort of AI way. General idea is : 1. Randomly pick words, e.g. 20 from a predefined word list file. ( http://www.word-list.com/) 2. The application play hangman with each word till either WON or FAIL. NO human being interactive. 3. The expect result is the application be able to win the game at most of time before a certain max wrong guess, e.g. 5 Please let me where is a better place to ask such question and thank you so much in advance. -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewrite this imperative in FP way
The reason I redefined Eq is: When doing `union` over two list of MyTuple is just base on its first element. Basically it means: [(1,2), (2,2)] `union` [(1,0), (2,0), (0,0)] produce [(1,2), (2,2), (0,0)] rather than [(1,2),(2,2),(1,0),(2,0),(0,0)] by default. -Haisheng On Sun, Feb 5, 2012 at 11:37 PM, Yves Parès yves.pa...@gmail.com wrote: Concerning your first solution, I don't understand why you redefine Eq but not Ord instance. Ord will still work by comparing the tuples and not the first elements of said tuples. Plus the good news is you don't have to do this: just use regular tuples and use sort*By *or group*By *functions from Data.List with the 'on' function from Data.Function. For instance your Eq instance could have been written x == y = (==) `on` (fst . getTuple) With regular tuples you can write sortBy (compare `on` fst). Plus can you rewrite your original imperative algorithm with the right variable names? You're using a 'd' array that's not been defined. 2012/2/5 Haisheng Wu fre...@gmail.com a = [1,1,1,1] b = [0,1,2,3] d = [0,0,0,0] for i in b: for j in c: if (i+j)3: d[i+j] += a[i] My just work implementation in Haskell http://hpaste.org/57452 Another people implementation in Haskell with Monad and it turns out complex and very imperatively. http://hpaste.org/57358 Do you have any cool solution in FP way? Thanks. -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewrite this imperative in FP way
*d = [sum $ map (a !!) [i | i - b, j - c, i + j 3, i + j == dIndex] | dIndex - [0..3]] * This is cool. -Simon On Sun, Feb 5, 2012 at 5:07 PM, L Corbijn aspergesoe...@gmail.com wrote: On Sun, Feb 5, 2012 at 7:28 AM, Haisheng Wu fre...@gmail.com wrote: a = [1,1,1,1] b = [0,1,2,3] d = [0,0,0,0] for i in b: for j in c: if (i+j)3: d[i+j] += a[i] My just work implementation in Haskell http://hpaste.org/57452 Another people implementation in Haskell with Monad and it turns out complex and very imperatively. http://hpaste.org/57358 Do you have any cool solution in FP way? Thanks. -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe There are several ways to make it nicer. Without assumption on what lists a, b and c contain it can be written as d = [sum $ map (a !!) [i | i - b, j - c, i + j 3, i + j == dIndex] | dIndex - [0..3]] With the assumption that b and c are both [0..3] this can be 'improved' to d = (take 3 . map sum . tail $ inits a) ++ replicate (4 - 3) 0 This generates the first three values by the complicated expression and then adds the extra zero's by using the replicate expression. This works as the value of the i-th element of d is the sum over the first i elements in a if i 3 and 0 otherwise. A list of lists with the first i elements is generated with 'tail $ inits a' which is then summed and restricted to length 3. An alternative for this is d = (take 3 . snd $ mapAccumL (\acc ai - (acc + ai, acc + ai)) 0 a) ++ replicate (4 - 3) 0 Where the summation and tail generating is done in the mapAccumL function. Greetings, Lars P.S. Yes the replicate (4-3) 0 can be replaced by [0], but I wanted to explicitly include the length (4) of the expected list. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewrite this imperative in FP way
Okay. But that's misleading, as normally x == y = True *iff* compare x y = EQ, but there this is not verified, as you don't redefined A function like unionBy doesn't exist, so IMHO to limit ambiguity, it would be a good idea to use MyTuple *only *at the specific place where you need its Eq instance instead of that of tuple (and then remove the Ord MyTuple instance), and use regular tuples elsewhere. The following should do the job: map getTuple . (`union` c) . map MyTuple 2012/2/6 Haisheng Wu fre...@gmail.com The reason I redefined Eq is: When doing `union` over two list of MyTuple is just base on its first element. Basically it means: [(1,2), (2,2)] `union` [(1,0), (2,0), (0,0)] produce [(1,2), (2,2), (0,0)] rather than [(1,2),(2,2),(1,0),(2,0),(0,0)] by default. -Haisheng On Sun, Feb 5, 2012 at 11:37 PM, Yves Parès yves.pa...@gmail.com wrote: Concerning your first solution, I don't understand why you redefine Eq but not Ord instance. Ord will still work by comparing the tuples and not the first elements of said tuples. Plus the good news is you don't have to do this: just use regular tuples and use sort*By *or group*By *functions from Data.List with the 'on' function from Data.Function. For instance your Eq instance could have been written x == y = (==) `on` (fst . getTuple) With regular tuples you can write sortBy (compare `on` fst). Plus can you rewrite your original imperative algorithm with the right variable names? You're using a 'd' array that's not been defined. 2012/2/5 Haisheng Wu fre...@gmail.com a = [1,1,1,1] b = [0,1,2,3] d = [0,0,0,0] for i in b: for j in c: if (i+j)3: d[i+j] += a[i] My just work implementation in Haskell http://hpaste.org/57452 Another people implementation in Haskell with Monad and it turns out complex and very imperatively. http://hpaste.org/57358 Do you have any cool solution in FP way? Thanks. -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Updated OpenGL libraries
Thanks!!! On 02/05/2012 11:53 PM, Jason Dagit wrote: Hello, I'm pleased to anounce a minor bug fix release of the OpenGL libraries. This release was prompted by issues and warnings when compiling with ghc-7.4.1. The following packages have been updated: * OpenGLRaw 1.2.0.0 * OpenGL 2.5.0.0 * GLURaw 1.2.0.0 * GLUT 2.3.0.0 Thanks goes out to: * Corey O'Connor * mgajda (github id) * #haskell-game and #haskell on freenode The changes include: * Removing a data type context * Exposing the GLfoo constructors from OpenGLRaw * Deriving Typeable instead of using the now deprecated mkTyCon * Added Eq constraint, necessary now that Num doesn't have an Eq constraint * Tighten constraints in cabal files * Conservative package version bump (X.Y.Z - X.(Y+1).0) As usual, please submit pull requests and bug reports on github: https://github.com/haskell-opengl Thank you! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewrite this imperative in FP way
How about this: import Array a = [1,1,1,1] b = [0,1,2,3] c = [0,2] d = elems $ accumArray (+) 0 (0,3) [(i+j,a!!i) | i-b, j-c, i+j3] -- Thomas H On 2012-02-06 12:01 , Haisheng Wu wrote: *d = [sum $ map (a !!) [i | i - b, j - c, i + j 3, i + j == dIndex] | dIndex - [0..3]] * This is cool. -Simon On Sun, Feb 5, 2012 at 5:07 PM, L Corbijn aspergesoe...@gmail.com mailto:aspergesoe...@gmail.com wrote: On Sun, Feb 5, 2012 at 7:28 AM, Haisheng Wu fre...@gmail.com mailto:fre...@gmail.com wrote: a = [1,1,1,1] b = [0,1,2,3] d = [0,0,0,0] for i in b: for j in c: if (i+j)3: d[i+j] += a[i] My just work implementation in Haskell http://hpaste.org/57452 Another people implementation in Haskell with Monad and it turns out complex and very imperatively. http://hpaste.org/57358 Do you have any cool solution in FP way? Thanks. -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe There are several ways to make it nicer. Without assumption on what lists a, b and c contain it can be written as d = [sum $ map (a !!) [i | i - b, j - c, i + j 3, i + j == dIndex] | dIndex - [0..3]] With the assumption that b and c are both [0..3] this can be 'improved' to d = (take 3 . map sum . tail $ inits a) ++ replicate (4 - 3) 0 This generates the first three values by the complicated expression and then adds the extra zero's by using the replicate expression. This works as the value of the i-th element of d is the sum over the first i elements in a if i 3 and 0 otherwise. A list of lists with the first i elements is generated with 'tail $ inits a' which is then summed and restricted to length 3. An alternative for this is d = (take 3 . snd $ mapAccumL (\acc ai - (acc + ai, acc + ai)) 0 a) ++ replicate (4 - 3) 0 Where the summation and tail generating is done in the mapAccumL function. Greetings, Lars P.S. Yes the replicate (4-3) 0 can be replaced by [0], but I wanted to explicitly include the length (4) of the expected list. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: exists-0.1
Hi, Gábor Lehel wrote: data E = forall a. C a = E a I don't know if anyone's ever set out what the precise requirements are for a type class method to be useful with existentials. More than you seem to think. For example: data Number = forall a . Num a = Number a foo :: Number - Number foo (Number x) = Number (x * x + 3) So the binary operation (*) can be used. Note that from a type-checking perspective, the pattern match on (Number x) also extracts the type, which is then available when checking the right-hand side. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
John Millikin wrote: That was my understanding also, then QuickCheck found a counter-example. It turns out that there are cases where a valid path cannot be roundtripped in the GHC 7.2 encoding. The issue is that [238,189,178] decodes to 0xEF72, which is within the 0xEF00-0xEFFF range that GHC uses to represent un-decodable bytes. How did you deal with this in system-filepath? While no code points in the Supplementary Special-purpose Plane are currently assigned (http://www.unicode.org/roadmaps/ssp/), it is worrying that it's used, especially if filenames in a non-unicode encoding could be interpreted as containing characters really within this plane. I wonder why maxBound :: Char was not increased, and the addtional space after `\1114111' used for the un-decodable bytes? For FFI, anything that deals with a FilePath should use this withFilePath, which GHC contains but doesn't export(?), rather than the old withCString or withCAString: import GHC.IO.Encoding (getFileSystemEncoding) import GHC.Foreign as GHC withFilePath :: FilePath - (CString - IO a) - IO a withFilePath fp f = getFileSystemEncoding = \enc - GHC.withCString enc fp f If code uses either withFilePort or withCString, then the filenames withFilePath? written will depend on the user's locale. This is wrong. Filenames are either non-encoded text strings (Windows), UTF8 (OSX), or arbitrary bytes (non-OSX POSIX). They must not change depending on the locale. This is exactly how GHC 7.4 handles them. For example: openDirStream :: FilePath - IO DirStream openDirStream name = withFilePath name $ \s - do dirp - throwErrnoPathIfNullRetry openDirStream name $ c_opendir s return (DirStream dirp) removeLink :: FilePath - IO () removeLink name = withFilePath name $ \s - throwErrnoPathIfMinus1_ removeLink name (c_unlink s) I do not see any locale-dependant behavior in the filename bytes read/written. Code that reads or writes a FilePath to a Handle (including even to stdout!) must take care to set the right encoding too: fileEncoding :: Handle - IO () fileEncoding h = hSetEncoding h = getFileSystemEncoding This is also wrong. A file path cannot be written to a handle with any hope of correct behavior. If it's to be displayed to the user, a path should be converted to text first, then displayed. Sure it can. See find(1). Its output can be read as FilePaths once the Handle is set up as above. If you prefer your program not crash with an encoding error when an arbitrary FilePath is putStr, but instead perhaps output bytes that are not valid in the current encoding, that's also a valid choice. You might be writing a program, like find, that again needs to output any possible FilePath including badly encoded ones. Filesystem.Path.CurrentOS.toText is a nice option if you want validly encoded output though. Thanks for that! This is new in 7.4, and won't be backported, right? I tried compiling the new unix package in 7.2 to get proper file path support, but it failed with an error about some new language extension. The RawFilePath is just a ByteString, so your existing converters for that in system-filepath might work. -- see shy jo signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On Mon, Feb 6, 2012 at 10:05, Joey Hess j...@kitenet.net wrote: John Millikin wrote: That was my understanding also, then QuickCheck found a counter-example. It turns out that there are cases where a valid path cannot be roundtripped in the GHC 7.2 encoding. The issue is that [238,189,178] decodes to 0xEF72, which is within the 0xEF00-0xEFFF range that GHC uses to represent un-decodable bytes. How did you deal with this in system-filepath? I used 0xEF00 as an escape character, to mean the following char should be interpreted as a literal byte. A user pointed out that there is a problem with this solution also -- a path containing actual U+EF00 will be considered invalid encoding. I'm going to change things over to use the Python 3 solution -- they use part of the UTF16 surrogate pair range, so it's impossible for a valid path to contain their stand-in characters. Another user says that GHC 7.4 also changed its escape range to match Python 3, so it seems to be a pseudo-standard now. That's really good. I'm going to add a 'posix_ghc704' rule to system-filepath, which should mean that only users running GHC 7.2 will have to worry about escape chars. Unfortunately, the text package refuses to store codepoints in that range (it replaces them with a placeholder), so I have to switch things over to use [Char]. (Yak sighted! Prepare lather!) While no code points in the Supplementary Special-purpose Plane are currently assigned (http://www.unicode.org/roadmaps/ssp/), it is worrying that it's used, especially if filenames in a non-unicode encoding could be interpreted as containing characters really within this plane. I wonder why maxBound :: Char was not increased, and the addtional space after `\1114111' used for the un-decodable bytes? There's probably a lot of code out there that assumes (maxBound :: Char) is also the maximum Unicode code point. It would be difficult to update, particularly when dealing with bindings to foreign libraries (like the text-icu package). Both Python 3 and GHC 7.4 are using codepoints in the UTF16 surrogate pair range for this, and that seems like a pretty clean solution. For FFI, anything that deals with a FilePath should use this withFilePath, which GHC contains but doesn't export(?), rather than the old withCString or withCAString: import GHC.IO.Encoding (getFileSystemEncoding) import GHC.Foreign as GHC withFilePath :: FilePath - (CString - IO a) - IO a withFilePath fp f = getFileSystemEncoding = \enc - GHC.withCString enc fp f If code uses either withFilePort or withCString, then the filenames withFilePath? written will depend on the user's locale. This is wrong. Filenames are either non-encoded text strings (Windows), UTF8 (OSX), or arbitrary bytes (non-OSX POSIX). They must not change depending on the locale. This is exactly how GHC 7.4 handles them. For example: openDirStream :: FilePath - IO DirStream openDirStream name = withFilePath name $ \s - do dirp - throwErrnoPathIfNullRetry openDirStream name $ c_opendir s return (DirStream dirp) removeLink :: FilePath - IO () removeLink name = withFilePath name $ \s - throwErrnoPathIfMinus1_ removeLink name (c_unlink s) I do not see any locale-dependant behavior in the filename bytes read/written. Perhaps I'm misunderstanding, but the definition of 'withFilePath' you provided is definitely locale-dependent. Unless getFileSystemEncoding is constant? Code that reads or writes a FilePath to a Handle (including even to stdout!) must take care to set the right encoding too: fileEncoding :: Handle - IO () fileEncoding h = hSetEncoding h = getFileSystemEncoding This is also wrong. A file path cannot be written to a handle with any hope of correct behavior. If it's to be displayed to the user, a path should be converted to text first, then displayed. Sure it can. See find(1). Its output can be read as FilePaths once the Handle is set up as above. If you prefer your program not crash with an encoding error when an arbitrary FilePath is putStr, but instead perhaps output bytes that are not valid in the current encoding, that's also a valid choice. You might be writing a program, like find, that again needs to output any possible FilePath including badly encoded ones. A program like find(1) has two use cases: 1. Display paths to the user, as text. 2. Provide paths to another program, in the operating system's file path format. These two goals are in conflict. It is not possible to implement a find(1) that performs both correctly in all locales. The best solution is to choose #2, and always write in the OS format, and hope the user's shell+terminal are capable of rendering it to a reasonable-looking path. Filesystem.Path.CurrentOS.toText is a nice option if you want validly encoded output though. Thanks for that! Ah, that's not what toText is for. toText provides a human-readable representation of the path. It's
Re: [Haskell-cafe] ANN: exists-0.1
If anyone ever says, I'd really like to use your package if it weren't for the dependencies, I'll very gladly remove them. (They're used for actual instances, by the way, not just the Defaults module.) 2012/2/6 Yves Parès yves.pa...@gmail.com: That is a great initiative. I didn't know about those Kind extensions that enable you to pass a typeclass as a type parameter... However, have you considered putting the Data.Exists.Default module in a separate package? That would reduce the dependencies for those who just need Exists and Existential. 2012/2/5 Gábor Lehel illiss...@gmail.com There's a common pattern in Haskell of writing: data E where E :: C a = a - E also written data E = forall a. C a = E a I recently uploaded a package to Hackage which uses the new ConstraintKinds extension to factor this pattern out into an Exists type parameterized on the constraint, and also for an Existential type class which can encompass these kind of types: http://hackage.haskell.org/package/exists My motivation was mostly to play with my new toys, if it turns out to be useful for anything that's a happy and unexpected bonus. Some interesting things I stumbled upon while writing it: - Did you know you can write useful existentials for Functor, Foldable, and Traversable? I sure didn't beforehand. - You can even write them for various Comonad classes, though in their case I don't think it's good for anything because you have no way to run them. - Surprisingly to me, the only * kinded class in the standardish libraries I found which is useful with existentials is Show, the * - * kinded ones are more numerous. - I don't know if anyone's ever set out what the precise requirements are for a type class method to be useful with existentials. For example, any method which requires two arguments of the same type (the type in the class head) is clearly useless, because if you have two existentials there's no way to tell whether or not their contents were of the same type. I think this holds any time you have more than one value of the type among the method's parameters in any kind of way (even if it's e.g. a single parameter that's a list). If the type-from-the-class-head (is there a word for this?) is used in the method's parameters in a position where it's not the outermost type constructor of a type (i.e. it's a type argument), that's also no good, because there's no way to extract the type from the existential, you can only extract the value. On the other hand, in the method's return type it's fine if there are multiple values of the type-from-the-class-head (or if it's used as a type argument?), because (as long as the method also has an argument of the type) the type to put into the resulting existentials can be deduced to be the same as the one that was in the argument. But if the type-from-the-class-head is used *only* in the return type, then it's difficult to construct an existential out of the return value because the instance to use will be ambiguous. - There are a lot of ways you can write existentials, and the library only captures a small part of them. Multiparameter constraint? No go. More than one constraint? No go (though you can use Control.Constraint.Combine). More than one type/value stored? No go. Anything which doesn't exactly match the patterns data E where E :: C a = a - E or data E a where E :: C f = f a - E a? No go. I don't think there's any way to capture all of the possibilities in a finite amount of code. - ConstraintKinds lets you write class aliases as type synonyms, type Stringy a = (Show a, Eq a). The old way to do this is class (Show a, Eq a) = Stringy a; instance (Show a, Eq a) = Stringy a and requires UndecidableInstances. But if the alias has multiple parameters, the old way is still superior, because it can be partially applied where type synonyms can't. This is analogous to the situation with type synonyms versus newtype/data declarations, but interestingly, unlike data and newtypes, the class+instance method doesn't require you to do any manual wrapping and unwrapping, only the declaration itself is different. - One of the advantages FunctionalDependencies has over TypeFamilies is that type signatures using them tend to be more readable and concise than ones which have to write out explicit equality constraints. For example, foo :: MonadState s m = s - m () is nicer than foo :: (MonadState m, State m ~ s) = s - m (). But with equality superclass constraints (as of GHC 7.2), it's possible to translate from TF-form to FD-form (but not the reverse, as far as I know): class (MonadStateTF m, s ~ State m) = MonadStateFDish s m; instance (MonadStateTF m, s ~ State m) = MonadStateFDish s m. - PolyKinds only seems to be useful as long as there's no value-level representation of the polykinded type involved (it's only used as a phantom). As soon as you have to write 'a' for kind * and 'f a' for kind * - *,
Re: [Haskell-cafe] ANN: exists-0.1
2012/2/6 Tillmann Rendel ren...@informatik.uni-marburg.de: Hi, Gábor Lehel wrote: data E = forall a. C a = E a I don't know if anyone's ever set out what the precise requirements are for a type class method to be useful with existentials. More than you seem to think. For example: data Number = forall a . Num a = Number a foo :: Number - Number foo (Number x) = Number (x * x + 3) So the binary operation (*) can be used. Note that from a type-checking perspective, the pattern match on (Number x) also extracts the type, which is then available when checking the right-hand side. I think what I really meant to say by useful with exisentials was you can write an instance for the existential which forwards to the instance wrapped by the existential and it will be useful, but you're quite right to point out that these are not the same. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Loading a texture in OpenGL
Using the OpenGL package on Hackage, how do I load a texture from an array? In the red book[1], I see their code using glGenTextures and glBindTexture, but I can't find these in the documentation. Are there different functions I should be calling? [1] http://glprogramming.com/red/chapter09.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On Sun, Feb 05, 2012 at 07:17:32PM -0800, John Millikin wrote: That was my understanding also, then QuickCheck found a counter-example. It turns out that there are cases where a valid path cannot be roundtripped in the GHC 7.2 encoding. This is fixed in GHC 7.4.1. Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] network-2.3.0.10 compiled for ghc 7.4.1 windows
Hi, After some pains, I compiled the package Network. sa_family_t is needed in network.Socket.Internal.asc and MinGW seems that it has no such variable defined. I share here the package with the compiled binaries included: http://skydrive.live.com/?cid=2F229EB748D4CBA3id=2F229EB748D4CBA3%21105 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] network-2.3.0.10 compiled for ghc 7.4.1 windows
Hi, Someone recently contributed a fix that should make network build with 7.4: https://github.com/haskell/network/pull/25 Can you see if that works for you? I haven't yet had time to merge and release that fix (I'm on vacation.) -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Google Summer of Code 2012 Announced
Hi all, Here's a heads-up that this year's Google of Code is kicking off. My experience from the last few years is that we can maximize the output we get from GSoC by being proactive and writing down semi-detailed explanations of what kind of projects we'd like to see, instead of letting the students pick themselves*. Here's three examples of such write-ups I did last year: http://blog.johantibell.com/2011/03/summer-of-code-project-suggestions.html Concretely: 1. Write down the project suggestions somewhere (e.g. on the wiki, your blog, etc). 2. Advertise the projects on haskell-cafe, reddit, twitter, Google+ 3. Profit. * The students tend to not know what makes a good GSoC project and often aim for something too difficult, like writing a new project from scratch instead of contributing to an old one. Contributing to widely used libraries or infrastructure usually results in * a larger benefit for the community, and * the students sticking around. My guess is that the student tend to stick around after the project is done if they contribute to infrastructure projects, as they'll see their stuff get used and will get feature requests/bug reports that will make them continue working on the project. -- Johan -- Forwarded message -- From: Carol Smith car...@google.com Date: Sat, Feb 4, 2012 at 8:43 AM Subject: Google Summer of Code 2012 Announced To: Google Summer of Code Announce google-summer-of-code-annou...@googlegroups.com Hi all, We're pleased to announce that Google Summer of Code will be happening for its eighth year this year. Please check out the blog post [1] about the program and read the FAQs [2] and Timeline [3] on Melange for more information. [1] - http://google-opensource.blogspot.com/2012/02/google-summer-of-code-2012-is-on.html [2] - http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs [3] - http://www.google-melange.com/gsoc/events/google/gsoc2012 Cheers, Carol -- You received this message because you are subscribed to the Google Groups Google Summer of Code Announce group. To post to this group, send email to google-summer-of-code-annou...@googlegroups.com. To unsubscribe from this group, send email to google-summer-of-code-announce+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-summer-of-code-announce?hl=en. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
John Millikin wrote: Perhaps I'm misunderstanding, but the definition of 'withFilePath' you provided is definitely locale-dependent. Unless getFileSystemEncoding is constant? I think/hope it's locale dependent, but undecodable bytes are remapped, so as long as the system's locale doesn't change, reading a FilePath with the encoding and then writing it back out should always reproduce the same bytes. Filesystem.Path.CurrentOS.toText is a nice option if you want validly encoded output though. Thanks for that! Ah, that's not what toText is for. toText provides a human-readable representation of the path. It's used for things like file managers, where you need to show the user a label which approximates the underlying path. There's no guarantee that the output of toText can be converted back to the original path, especially if it returns a Left. Yes, that's what I meant. :) -- see shy jo signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contributing to http-conduit
After all these commits have been flying around, I have yet another question: the 'HTTP' package defines Network.Browser which is a State monad which keeps state about a browser (i.e. a cookie jar, a proxy, redirection parameters, etc.) It would be pretty straightforward to implement this kind of functionality on top of http-conduit. I was originally going to do it and release it as its own package, but it may be beneficial to add such a module to the existing http-conduit package. Should I add it in to the existing package, or release it as its own package? --Myles On Mon, Feb 6, 2012 at 12:15 AM, Michael Snoyman mich...@snoyman.comwrote: Just an FYI for everyone: Myles sent an (incredibly thorough) pull request to handle cookies: https://github.com/snoyberg/http-conduit/pull/13 Thanks! On Sun, Feb 5, 2012 at 8:20 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: 1. The spec defines a grammar for the attributes. They're in uppercase. 2. Yes - 1.3 is the first version that lists DiffTime as an instance of RealFrac (so I can use the 'floor' function to pull out the number of seconds to render it) 3. I'll see what I can do. --Myles On Sat, Feb 4, 2012 at 9:06 PM, Michael Snoyman mich...@snoyman.com wrote: Looks good, a few questions/requests: 1. Is there a reason to upper-case all the attributes? 2. Is the time = 1.3 a requirements? Because that can cause a lot of trouble for people. 3. Can you send the patch as a Github pull request? It's easier to track that way. Michael On Sat, Feb 4, 2012 at 1:21 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Here is the patch to Web.Cookie. I didn't modify the tests at all because they were already broken - they looked like they hadn't been updated since SetCookie only had 5 parameters. I did verify by hand that the patch works, though. Thanks, Myles On Thu, Feb 2, 2012 at 11:26 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Alright, I'll make a small patch that adds 2 fields to SetCookie: setCookieMaxAge :: Maybe DiffTime setCookieSecureOnly :: Bool I've also gotten started on those cookie functions. I'm currently writing tests for them. @Chris: The best advice I can give is that Chrome (what I'm using as a source on all this) has the data baked into a .cc file. However, they have directions in a README and a script which will parse the list and generate that source file. I recommend doing this. That way, the Haskell module would have 2 source files: one file that reads the list and generates the second file, which is a very large source file that contains each element in the list. The list should export `elem`-type queries. I'm not quite sure how to handle wildcards that appear in the list - that part is up to you. Thanks for helping out with this :] --Myles On Thu, Feb 2, 2012 at 10:53 PM, Michael Snoyman mich...@snoyman.com wrote: Looks good to me too. I agree with Aristid: let's make the change to cookie itself. Do you want to send a pull request? I'm also considering making the SetCookie constructor hidden like we have for Request, so that if in the future we realize we need to add some other settings, it doesn't break the API. Chris: I would recommend compiling it into the module. Best bet would likely being converting the source file to Haskell source. Michael On Fri, Feb 3, 2012 at 6:32 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Alright. After reading the spec, I have these questions / concerns: The spec supports the Max-Age cookie attribute, which Web.Cookies doesn't. I see two possible solutions to this. The first is to have parseSetCookie take a UTCTime as an argument which will represent the current time so it can populate the setCookieExpires field by adding the Max-Age attribute to the current time. Alternatively, that function can return an IO SetCookie so it can ask for the current time by itself (which I think is inferior to taking the current time as an argument). Note that the spec says to prefer Max-Age over Expires. Add a field to SetCookie of type Maybe DiffTime which represents the Max-Age attribute Cookie code should be aware of the Public Suffix List as a part of its domain verification. The cookie code only needs to be able to tell if a specific string is in the list (W.Ascii - Bool) I propose making an entirely unrelated package, public-suffix-list, with a module Network.PublicSuffixList, which will expose this function, as well as functions about parsing the list itself. Thoughts? Web.Cookie doesn't have a secure-only attribute. Adding one in is straightforward enough. The spec describes cookies as a property
Re: [Haskell-cafe] Contributing to http-conduit
I would say: if it adds no package dependencies, put it right in. Aristid Am 06.02.2012 22:09 schrieb Myles C. Maxfield myles.maxfi...@gmail.com: After all these commits have been flying around, I have yet another question: the 'HTTP' package defines Network.Browser which is a State monad which keeps state about a browser (i.e. a cookie jar, a proxy, redirection parameters, etc.) It would be pretty straightforward to implement this kind of functionality on top of http-conduit. I was originally going to do it and release it as its own package, but it may be beneficial to add such a module to the existing http-conduit package. Should I add it in to the existing package, or release it as its own package? --Myles On Mon, Feb 6, 2012 at 12:15 AM, Michael Snoyman mich...@snoyman.comwrote: Just an FYI for everyone: Myles sent an (incredibly thorough) pull request to handle cookies: https://github.com/snoyberg/http-conduit/pull/13 Thanks! On Sun, Feb 5, 2012 at 8:20 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: 1. The spec defines a grammar for the attributes. They're in uppercase. 2. Yes - 1.3 is the first version that lists DiffTime as an instance of RealFrac (so I can use the 'floor' function to pull out the number of seconds to render it) 3. I'll see what I can do. --Myles On Sat, Feb 4, 2012 at 9:06 PM, Michael Snoyman mich...@snoyman.com wrote: Looks good, a few questions/requests: 1. Is there a reason to upper-case all the attributes? 2. Is the time = 1.3 a requirements? Because that can cause a lot of trouble for people. 3. Can you send the patch as a Github pull request? It's easier to track that way. Michael On Sat, Feb 4, 2012 at 1:21 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Here is the patch to Web.Cookie. I didn't modify the tests at all because they were already broken - they looked like they hadn't been updated since SetCookie only had 5 parameters. I did verify by hand that the patch works, though. Thanks, Myles On Thu, Feb 2, 2012 at 11:26 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Alright, I'll make a small patch that adds 2 fields to SetCookie: setCookieMaxAge :: Maybe DiffTime setCookieSecureOnly :: Bool I've also gotten started on those cookie functions. I'm currently writing tests for them. @Chris: The best advice I can give is that Chrome (what I'm using as a source on all this) has the data baked into a .cc file. However, they have directions in a README and a script which will parse the list and generate that source file. I recommend doing this. That way, the Haskell module would have 2 source files: one file that reads the list and generates the second file, which is a very large source file that contains each element in the list. The list should export `elem`-type queries. I'm not quite sure how to handle wildcards that appear in the list - that part is up to you. Thanks for helping out with this :] --Myles On Thu, Feb 2, 2012 at 10:53 PM, Michael Snoyman mich...@snoyman.com wrote: Looks good to me too. I agree with Aristid: let's make the change to cookie itself. Do you want to send a pull request? I'm also considering making the SetCookie constructor hidden like we have for Request, so that if in the future we realize we need to add some other settings, it doesn't break the API. Chris: I would recommend compiling it into the module. Best bet would likely being converting the source file to Haskell source. Michael On Fri, Feb 3, 2012 at 6:32 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Alright. After reading the spec, I have these questions / concerns: The spec supports the Max-Age cookie attribute, which Web.Cookies doesn't. I see two possible solutions to this. The first is to have parseSetCookie take a UTCTime as an argument which will represent the current time so it can populate the setCookieExpires field by adding the Max-Age attribute to the current time. Alternatively, that function can return an IO SetCookie so it can ask for the current time by itself (which I think is inferior to taking the current time as an argument). Note that the spec says to prefer Max-Age over Expires. Add a field to SetCookie of type Maybe DiffTime which represents the Max-Age attribute Cookie code should be aware of the Public Suffix List as a part of its domain verification. The cookie code only needs to be able to tell if a specific string is in the list (W.Ascii - Bool) I propose making an entirely unrelated package, public-suffix-list, with a module Network.PublicSuffixList, which will expose this function, as well as functions about parsing the list
Re: [Haskell-cafe] ghc-api Static Semantics?
As a side note, buildwrapper version 0.4.0 and above follows the approach you outline. When a file is modified, we call GHC to build it, and we store the GHC AST as a JSON object in a hidden file. Then all subsequent calls that make use of the JSON data (in EclipseFP, this would be to show you a tooltip of the type of the object you're hovering over) without calling GHC again, so it's much faster, even though buildwrapper is a pure one shot executable with no concept of a session. The JSON file could also be read by another process that buildwrapper itself, so maybe Christopher could use this approach. JP On Thu, Jan 26, 2012 at 7:00 PM, Thomas Schilling nomin...@googlemail.com wrote: On 26 January 2012 16:33, JP Moresmau jpmores...@gmail.com wrote: Thomas, thank you for that explanation about the different type of identifiers in the different phases of analysis. I've never seen that information so clearly laid out before, can it be added to the wikis (in http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API or http://www.haskell.org/haskellwiki/GHC/As_a_library maybe)? I think it would be helpful to all people that want to dive into the GHC API. Will do. On a side note, I'm going to do something very similar in my BuildWrapper project (which is now the backend of the EclipseFP IDE plugins): instead of going back to the API every time the user requests to know the type of something in the AST, I'm thinking of sending the whole typed AST to the Java code. Maybe that's something Christopher could use. Both the BuildWrapper code and Thomas's scion code are available on GitHub, as they provide examples on how to use the GHC API. I really don't think you want to do much work on the front-end as that will just need to be duplicated for each front-end. That was the whole point of building Scion in the first place. I understand, of course, that Scion is not useful enough at this time. Well, I currently don't have much time to work on Scion, but the plan is as follows: - Scion becomes a multi-process architecture. It has to be since it's not safe to run multiple GHC sessions inside the same process. Even if that were possible, you wouldn't be able to, say, have a profiling compiler and a release compiler in the same process due to how static flags work. Separate processes have the additional advantage that you can kill them if they use too much memory (e.g., because you can't unload loaded interfaces). - Scion will be based on Shake and GHC will mostly be used in one-shot mode (i.e., not --make). This makes it easier to handle preprocessed files. It also allows us to generate and update meta-information on demand. I.e., instead of parsing and typechecking a file and then caching the result for the current file, Scion will simply generate meta information whenever it (re-)compiles a source file and writes that meta information to a file. Querying or caching that meta information then is completely orthogonal to generating it. The most basic meta information would be a type-annotated version of the compiled AST (possibly + warnings and errors from the last time it was compiled). Any other meta information can then be generated from that. - The GHCi debugger probably needs to be treated specially. There also should be automatic detection of files that aren't supported by the bytecode compiler (e.g., those using UnboxedTuples) and force compilation to machine code for those. - The front-end protocol should be specified somewhere. I'm thinking about using protobuf specifications and then use ways to generate custom formats from that (e.g., JSON, Lisp S-Expressions, XML?). And if the frontend supports protocol buffers, then it can use that and be fast. That also means that all serialisation code can be auto-generated. I won't have time to work on this before the ICFP deadline (and only very little afterwards), but Scion is not dead (just hibernating). JP On Thu, Jan 26, 2012 at 2:31 PM, Thomas Schilling nomin...@googlemail.com wrote: On 26 January 2012 09:24, Christopher Brown cm...@st-andrews.ac.uk wrote: Hi Thomas, By static semantics I mean use and bind locations for every name in the AST. Right, that's what the renamer does in GHC. The GHC AST is parameterised over the type of identifiers used. The three different identifier types are: RdrName: is the name as it occurred in source code. This is the output of the parser. Name: is basically RdrName + unique ID, so you can distinguish two xs bound at different locations (this is what you want). This is the output of the renamer. Id: is Name + Type information and consequently is the output of the type checker. Diagram: String --parser-- HsModule RdrName --renamer-- HsModule Name --type-checker-- HsBinds Id Since you can't hook in-between renamer and type checker, it's perhaps more
[Haskell-cafe] Evaluating parallel computations in order of finishing (approximately)
Suppose that we have a list [a] of computations that we want to evaluate in parallel. I would like to have something (probably a monad) which would return the list in order (roughly) of finishing: Say the monad is M. It would be something like the state monad, in that it would be implemented by a state transformer function. In this case the state would the set of computations to be evaluated. we might have a function include :: [a] - M a () which would say that the monad's responsibility would be to evaluate all the members of a in parallel. We might also have a function strategy :: Strategy - M a () which would indicate the parallel strategy to be used. The key thing would be function, completed, which produces a list of all the computations to be evaluated as a list roughly in order of completion. That is, if, inside the M monad we finished the do with completed then we would have a value M a [a] which would be the list in order of completion. Since everything is lazy we could ask for the head of the list, and it would be the first value whose computation finished. Does such a thing exist? Victor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Summer of Code 2012 Announced
On Mon, Feb 6, 2012 at 12:54 PM, Johan Tibell johan.tib...@gmail.com wrote: 2. Advertise the projects on haskell-cafe, reddit, twitter, Google+ Does anyone know if the GSOC trac is in use this year? (or will be?). I started advocating for an extension to cabal to specify Setup.hs build dependencies last year, with this ticket: http://hackage.haskell.org/trac/summer-of-code/ticket/1602 I think the idea still has merit :) If anyone has comments, that would be a great place to put them (to clarify anything I've overlooked, point out shortcomings, suggest implementations, etc...). --Rogan 3. Profit. * The students tend to not know what makes a good GSoC project and often aim for something too difficult, like writing a new project from scratch instead of contributing to an old one. Contributing to widely used libraries or infrastructure usually results in * a larger benefit for the community, and * the students sticking around. My guess is that the student tend to stick around after the project is done if they contribute to infrastructure projects, as they'll see their stuff get used and will get feature requests/bug reports that will make them continue working on the project. -- Johan -- Forwarded message -- From: Carol Smith car...@google.com Date: Sat, Feb 4, 2012 at 8:43 AM Subject: Google Summer of Code 2012 Announced To: Google Summer of Code Announce google-summer-of-code-annou...@googlegroups.com Hi all, We're pleased to announce that Google Summer of Code will be happening for its eighth year this year. Please check out the blog post [1] about the program and read the FAQs [2] and Timeline [3] on Melange for more information. [1] - http://google-opensource.blogspot.com/2012/02/google-summer-of-code-2012-is-on.html [2] - http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs [3] - http://www.google-melange.com/gsoc/events/google/gsoc2012 Cheers, Carol -- You received this message because you are subscribed to the Google Groups Google Summer of Code Announce group. To post to this group, send email to google-summer-of-code-annou...@googlegroups.com. To unsubscribe from this group, send email to google-summer-of-code-announce+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-summer-of-code-announce?hl=en. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Loading a texture in OpenGL
On Mon, Feb 6, 2012 at 12:00 PM, Clark Gaebel cgae...@csclub.uwaterloo.ca wrote: Using the OpenGL package on Hackage, how do I load a texture from an array? The answer will depend on a few things: * Which OpenGL package you use, for example OpenGL vs. OpenGLRaw * What type of 'array' you use. In the case of the OpenGL package you need to create a PixelData value and pass that on. You can find example code here: https://github.com/dagit/nehe-tuts/blob/447f5471f3e7fe07b44dc5d2d87c4a95be35ce75/lesson06.hs https://github.com/dagit/nehe-tuts/blob/447f5471f3e7fe07b44dc5d2d87c4a95be35ce75/Util.hs In the red book[1], I see their code using glGenTextures and glBindTexture, but I can't find these in the documentation. Are there different functions I should be calling? Yes. As you've noticed the API of the OpenGL package sometimes (often?) differs from that of the C OpenGL api. If that's what you're more familiar with then take a look at OpenGLRaw. Here is how to do the same thing as the previous two links but using OpenGLRaw: https://github.com/dagit/nehe-tuts/blob/master/lesson06.hs https://github.com/dagit/nehe-tuts/blob/master/Util.hs Instead of using Arrays as defined by Haskell98, I would recommend using something else like Data.Vector. The standard arrays must be converted to something else to work with OpenGL. Data.Vector on the other hand allows direct access to the pinned pointer and is thus suitable for use with OpenGL as is. Have you seen JuicyPixels? The version on hackage uses arrays, but the version in github uses vector. I'd recommend using the version from github. It's faster and it will be easier to pass the data to OpenGL: https://github.com/Twinside/Juicy.Pixels Good luck! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Evaluating parallel computations in order of finishing (approximately)
Conal Elliot did something like this for his FRP system in the paper Push-Pull Functional Reactive Programming [1]. It involved a hack in which unsafePerformIO was used to spawn two threads to evaluate two events for occurrences, and return whichever returned first. Recall though, that monads aren't magic (despite frequent appearances to the contrary.) They are just functional structures that have to obey all of the normal restrictions of a pure functional language, including referential transparency. The entire point of Haskell's parallelism constructs is to make the returned values independent of parallel evaluation order. You're not going to escape that by using a monad, unless its one like IO which exists to order side-effects and isolate them in the type system. [1] http://conal.net/papers/push-pull-frp/ On Mon, Feb 6, 2012 at 5:46 PM, Victor Miller victorsmil...@gmail.com wrote: Suppose that we have a list [a] of computations that we want to evaluate in parallel. I would like to have something (probably a monad) which would return the list in order (roughly) of finishing: Say the monad is M. It would be something like the state monad, in that it would be implemented by a state transformer function. In this case the state would the set of computations to be evaluated. we might have a function include :: [a] - M a () which would say that the monad's responsibility would be to evaluate all the members of a in parallel. We might also have a function strategy :: Strategy - M a () which would indicate the parallel strategy to be used. The key thing would be function, completed, which produces a list of all the computations to be evaluated as a list roughly in order of completion. That is, if, inside the M monad we finished the do with completed then we would have a value M a [a] which would be the list in order of completion. Since everything is lazy we could ask for the head of the list, and it would be the first value whose computation finished. Does such a thing exist? Victor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Edward Amsden Student Computer Science Rochester Institute of Technology www.edwardamsden.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Switching GHC Version
Hi, I wrote a simple shell function for switching GHC version on the
system. It works only under Mac OSX, and only switch GHCs installed
via .pkg installers. It's useful to experiment newer features without
worrying breaking environment.
GHC_BASE_DIR=/Library/Frameworks/GHC.framework/Versions/
ghcs () {
VERSION=$1
sudo $GHC_BASE_DIR/$VERSION/Tools/create-links . /Library/Frameworks /
}
Usage:
~/work/today 08:21 ghcs 7.4.0.20111219-x86_64
Password:
~/work/today 08:21 ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.0.20111219
~/work/today 08:21 ghcs 7.4.1-x86_64
~/work/today 08:22 ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1
Now I'm curious of better way to achieve this. This have limitations
described above. Even it requires sudo because it modified symbolic
links under `/usr`.
Suggestions?
-nwn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Switching GHC Version
Personally I prefer just using 'virthualenv' these days, which
installs copies of GHC locally that you can then activate with your
shell, similar to 'virtualenv' in python. It's how I test packages on
multiple copies of GHC.
http://hackage.haskell.org/package/virthualenv
The nicest part is that it sandboxes cabal packages, but because it
works via shell scripts, the workflow for any version of GHC remains
the same: you can invoke ghci, cabal, etc all as you would expect, but
it only takes place in the virtual environment if you have activated
it.
On Mon, Feb 6, 2012 at 5:27 PM, HASHIMOTO, Yusaku nonow...@gmail.com wrote:
Hi, I wrote a simple shell function for switching GHC version on the
system. It works only under Mac OSX, and only switch GHCs installed
via .pkg installers. It's useful to experiment newer features without
worrying breaking environment.
GHC_BASE_DIR=/Library/Frameworks/GHC.framework/Versions/
ghcs () {
VERSION=$1
sudo $GHC_BASE_DIR/$VERSION/Tools/create-links . /Library/Frameworks /
}
Usage:
~/work/today 08:21 ghcs 7.4.0.20111219-x86_64
Password:
~/work/today 08:21 ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.0.20111219
~/work/today 08:21 ghcs 7.4.1-x86_64
~/work/today 08:22 ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1
Now I'm curious of better way to achieve this. This have limitations
described above. Even it requires sudo because it modified symbolic
links under `/usr`.
Suggestions?
-nwn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Regards,
Austin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Switching GHC Version
On Mon, Feb 6, 2012 at 18:27, HASHIMOTO, Yusaku nonow...@gmail.com wrote: Hi, I wrote a simple shell function for switching GHC version on the system. It works only under Mac OSX, and only switch GHCs installed via .pkg installers. It's useful to experiment newer features without worrying breaking environment. FWIW I'd consider two alternatives: (1) forgo links entirely and use something like http://modules.sourceforge.net/ to manage $PATH; (2) instead of using the bundled create-links, have the /usr/bin scripts check a per-user symlink and fall back to a system one; running the select script as root sets the system symlink, running as user sets the per-user symlink. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
On 4/02/2012, at 12:13 AM, Gábor Lehel wrote: All of this said, record.field is still the most readable, intuitive, and familiar syntax for selecting a field from a record that I know of. Having learned COBOL and Algol 68 before Haskell was dreamed of, I regard field OF record as the most readable, intuitive, and familiar syntax. Given our background in reading natural language text, most of us probably thought once upon a time that '.' was the most readable, intuitive, and familiar syntax for terminating a statement, and in COBOL, NDL, and Smalltalk, it _is_. There's certainly nothing about a dot that suggests field selection, *unless* you happen to be familiar with a programming language that does it that way. If we are going to let compatibility with Pascal or C or the like be our guide to readability and intuition, when are we going to switch from ! and !! for indexing to _[_]? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Donn Cave donn at avvanta.com writes: Quoth AntC anthony_clayden at clear.net.nz, ... We're on the slippery slope! Where will it end? And now that I've found it, I so love: customer.lastName.tail.head.toUpper-- Yay! ... compared to present practice, with where dot is function composition only - (toUpper.head.tail.lastName) customer So two competing meanings of ., where one is literally the reverse of the other. Of course we won't be able to spell composition without spaces any more, so technically the backwards and forward sense of . are distinct, but it seems kind of unfortunate anyway. Thanks Donn. I can see we aren't going to agree on this, so I'll be brief. (I'll use my limited time to gather the proposal properly on to a wiki.) It was a surprise to me that dot without spaces around is still legal syntax for function composition. So yes, we're going to break code (and hearts, by the sound of it). I'm proposing my record fields so that selectors are just functions. Then it's independent of dot notation. (It's the semantics I'm far more concerned with.) You (Donn) can then avoid 'switching on' dot as tight-binding reverse func apply, and nothing's got broken. (On the other hand, the change in semantics is so dramatic switching it on would get compile failures in typing expressions, so I don't see any danger of running broken code.) We could use something other than dot for the purpose (# has been suggested), but the trouble is that the user-defined operator space has got used up. I see that as part of introducing tight-binding reverse func apply, I also need a loose-binding version (counterpart to ($) in the Prelude). (.$) seems most natural, but probably that's already extant in user-defined code. So the advantage of dot (aside from it being familiar from other programming paradigms) is that we know the design space isn't used up. ... If you'll consider an idea from the peanut gallery ... for me, the dot notation for fields may as well be spelling as an operator - that is, customer.lastName deploys a field named .lastName. No, I no longer think it's just spelling. (I can see my Yay example is pushing the innovation too far too fast.) Examples which might be easier to swallow: customer.fullName shape.area date.dayOfWeek name.middleInitial list.length Are all pseudo- or virtual or calculated 'fields'. (Or if not fields, then attributes or properties.) I presume you're not suggesting we have both a function `area' and a pseudo- field `.area'? Perhaps we could allow some graphic char as a prefix to field names? (perhaps # because it's already allowed as part of magic-hash names? But it would be part of the name, _not_ an operator. customer.#firstName === (#firstName customer) AntC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Loading a texture in OpenGL
Thank you both. I'll be sure to try these out. As a matter of fact, I _am_ using JuicyPixels. I didn't realize there was a version on github which uses Vector. Thanks for letting me know. Regards, - clark On Mon, Feb 6, 2012 at 5:55 PM, Jason Dagit dag...@gmail.com wrote: On Mon, Feb 6, 2012 at 12:00 PM, Clark Gaebel cgae...@csclub.uwaterloo.ca wrote: Using the OpenGL package on Hackage, how do I load a texture from an array? The answer will depend on a few things: * Which OpenGL package you use, for example OpenGL vs. OpenGLRaw * What type of 'array' you use. In the case of the OpenGL package you need to create a PixelData value and pass that on. You can find example code here: https://github.com/dagit/nehe-tuts/blob/447f5471f3e7fe07b44dc5d2d87c4a95be35ce75/lesson06.hs https://github.com/dagit/nehe-tuts/blob/447f5471f3e7fe07b44dc5d2d87c4a95be35ce75/Util.hs In the red book[1], I see their code using glGenTextures and glBindTexture, but I can't find these in the documentation. Are there different functions I should be calling? Yes. As you've noticed the API of the OpenGL package sometimes (often?) differs from that of the C OpenGL api. If that's what you're more familiar with then take a look at OpenGLRaw. Here is how to do the same thing as the previous two links but using OpenGLRaw: https://github.com/dagit/nehe-tuts/blob/master/lesson06.hs https://github.com/dagit/nehe-tuts/blob/master/Util.hs Instead of using Arrays as defined by Haskell98, I would recommend using something else like Data.Vector. The standard arrays must be converted to something else to work with OpenGL. Data.Vector on the other hand allows direct access to the pinned pointer and is thus suitable for use with OpenGL as is. Have you seen JuicyPixels? The version on hackage uses arrays, but the version in github uses vector. I'd recommend using the version from github. It's faster and it will be easier to pass the data to OpenGL: https://github.com/Twinside/Juicy.Pixels Good luck! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Switching GHC Version
Thanks for suggestions. Having /usr/bin scripts seems to work for me, Although virthualenv looks promising for package dependency management. But when run virthualenv with --ghc=tarball, it creates copy of GHC suite inside a project whose size is about 700MB. On 2012/02/07, at 8:41, Brandon Allbery allber...@gmail.com wrote: On Mon, Feb 6, 2012 at 18:27, HASHIMOTO, Yusaku nonow...@gmail.com wrote: Hi, I wrote a simple shell function for switching GHC version on the system. It works only under Mac OSX, and only switch GHCs installed via .pkg installers. It's useful to experiment newer features without worrying breaking environment. FWIW I'd consider two alternatives: (1) forgo links entirely and use something like http://modules.sourceforge.net/ to manage $PATH; (2) instead of using the bundled create-links, have the /usr/bin scripts check a per-user symlink and fall back to a system one; running the select script as root sets the system symlink, running as user sets the per-user symlink. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Richard O'Keefe ok at cs.otago.ac.nz writes: On 4/02/2012, at 12:13 AM, Gábor Lehel wrote: All of this said, record.field is still the most readable, intuitive, and familiar syntax for selecting a field from a record that I know of. Having learned COBOL and Algol 68 before Haskell was dreamed of, I regard field OF record as the most readable, intuitive, and familiar syntax. Given our background in reading natural language text, most of us probably thought once upon a time that '.' was the most readable, intuitive, and familiar syntax for terminating a statement, and in COBOL, NDL, and Smalltalk, it _is_. There's certainly nothing about a dot that suggests field selection, *unless* you happen to be familiar with a programming language that does it that way. ... Richard, now you're just being playful. Database access languages used record.field since COBOL days (well certainly before SQL in 1969). Assembler and linker languages often allowed dots within names. I presume IPv4 dot-decimal comes from this. I think the use of dot comes from section and sub-section numbering in large documents. I have no idea when that dates from, but off the top of my head: Principia Mathematica, Russell and Whitehead 1910 Tractatus Logico-Philosophicus, Wittgenstein, 1918 (Admittedly Princ Math also uses dot (infix operator) as logical product. As well, there's a dot separator between a quantifier's list of bound variables (upside-down A, backwards E) and the bound term. Church's lambda notation similarly uses a dot to separate the bound variables.) There is one 'odd man out' when it comes to dot notation: A few little-known programming languages have for some reason bucked the well- established convention of small circle for function composition. There's certainly nothing about a dot that suggests function composition, *unless* ... AntC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Quoth AntC anthony_clay...@clear.net.nz, ... It was a surprise to me that dot without spaces around is still legal syntax for function composition. It isn't even unusual. You can find stuff like fromIntegral.ord in packages downloaded to build cabal-install for example. It graphically appeals to the notion of a function composed of several functions, so the programmers in question will likely not even be repentant! It's hard to imagine this all going anywhere, really, without some way around the code breakage. Maybe a different separator, like record\field, that really doesn't occur in infix like that. Are all pseudo- or virtual or calculated 'fields'. (Or if not fields, then attributes or properties.) I presume you're not suggesting we have both a function `area' and a pseudo- field `.area'? Well - there's no conflict between those two names, if `.area' is an identifier that starts with a dot. But virtual or calculated fields would presumably not be supported. Depends on whether it's legal to define a function `.area', or `.' spelling is allowed only for declared record fields. Personally I think the latter would be the right choice there - left of the dot must be a record value, right of the dot must be a field declared for that record. I understand this is not the direction you're going. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] a variant of TDNR (was: Re: Some thoughts on Type-Directed Name Resolution)
I brought up an idea on another thread, but it was a bit off subject and I think it got buried. Anyway, I'm curious to know if there are any obvious problems with this idea, or if it could be pursued further: It could be called Tagged Type Directed Name Resolution. The idea is a # prefix for identifiers. #f is a type directed function. It requires the type of its argument to be monomorphic, and is desugared to M.f, where M is the module defining the type of 'f's argument. Everything else remains the same. Records wishing the same name must live in separate modules, but field access looks like: (#a . #b) record This works to set fields of a record as well. Let M.f be a function from a record to a lens focused on a certain field of that record. Now you can write: M.a :: M.Record - Lens M.Record M.A set :: Lens record field - record - record val = set (#a 42) record which becomes: set (M.a record) 42 Or composed 'set ((#a.#b) record) 42' becomes 'set ((M.a . N.b) record) 42' An operator with convenient fixity should be able to remove the parens. As long as the compiler can figure out a monomorphic type expected by the input of #a then it shouldn't need type annotations. The thing I'm not sure about is if the ghc typechecker can do this. It would know that '#a' is a function 'alpha - beta', then need to figure out what alpha is. Then once it has a monomorphic type for alpha, then it has to look up a symbol 'a' in the module defining that type, and only then does it know the type of beta. If #b.#a style composition is to work, then of course '#b' would have to hold off until the return type of '#a' has been resolved. I don't know how hard that would be, or it would even be possible. This idea is less powerful than other proposals because the #-decorated function must be able to statically determine a monomorphic type for its argument. So no structural types. And no records with the same field name in the same module. Personally that doesn't bother me much since I try to keep modules small, but perhaps that could be addressed in an orthogonal nested module feature. The '#' prefix would mess up people using that as an operator. I guess @ is free, right? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Donn Cave donn at avvanta.com writes: You can find stuff like fromIntegral.ord in packages downloaded to build cabal-install for example. It graphically appeals to the notion of a function composed of several functions, so the programmers in question will likely not even be repentant! Data.Char.toUpper -- a name composed of several names shape.position.xCoord -- a structure composed of several structures Here's an off-the-wall idea for the syntactics: - Where there's a block of names with dot separators (and no spaces). - The dots must be either all postfix apply or all prefix compose. - Postpone analysing until we've got some type info for the sub-names. - The types must interlock either left-to-right or right-to-left. So now we know whether we're prefix or postfix. - Then we can adjust the AST for loose-binding vs tight-binding. (As happens for operator precedence.) ?Do we call this Type-Directed Syntax Resolution ;-) (By the way, natural languages do this sort of stuff all the time. In fact they revel in it: Eighth Army Push Bottles Up German Rear. http://languagelog.ldc.upenn.edu/nll/?p=3708 ) The more I think about it, the more the pseudo-fields makes sense, the more I want field selectors to be just functions. There's an interesting example in Wadler's original paper that became View Patterns Views: A way for pattern matching to cohabit with data abstraction [1987], 4. Viewing a complex number in cartesian and polar coordinates. We may want our implementation of complex to be abstract. We provide (pseudo-) fields to select the coordinates. Then they're ever-so like methods for an (abstract) object. Also we want the (pseudo-) fields to be updatable, which means field update needs to be polymorphic (overloaded). Then all I need is a type-(or kind-) level 'peg' for the name, and an instance for Has/get/set. AntC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Loading a texture in OpenGL
On 07/02/2012, at 7:00 AM, Clark Gaebel wrote: Using the OpenGL package on Hackage, how do I load a texture from an array? In the red book[1], I see their code using glGenTextures and glBindTexture, but I can't find these in the documentation. Are there different functions I should be calling? The Gloss graphics library has texture support, and the code for drawing them is confined to this module: http://code.ouroborus.net/gloss/gloss-head/gloss/Graphics/Gloss/Internals/Render/Picture.hs Feel free to steal the code from there. Ben. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Loading a texture in OpenGL
Awesome. Thanks! As a follow up question, how do I add a finalizer to a normal variable? OpenGL returns an integer handle to your texture in graphics memory, and you have to call deleteObjectNames on it. Is there any way to have this automatically run once we lose all references to this variable (and all copies)? On Mon, Feb 6, 2012 at 10:14 PM, Ben Lippmeier b...@ouroborus.net wrote: On 07/02/2012, at 7:00 AM, Clark Gaebel wrote: Using the OpenGL package on Hackage, how do I load a texture from an array? In the red book[1], I see their code using glGenTextures and glBindTexture, but I can't find these in the documentation. Are there different functions I should be calling? The Gloss graphics library has texture support, and the code for drawing them is confined to this module: http://code.ouroborus.net/gloss/gloss-head/gloss/Graphics/Gloss/Internals/Render/Picture.hs Feel free to steal the code from there. Ben. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Loading a texture in OpenGL
On 07/02/2012, at 2:40 PM, Clark Gaebel wrote: Awesome. Thanks! As a follow up question, how do I add a finalizer to a normal variable? OpenGL returns an integer handle to your texture in graphics memory, and you have to call deleteObjectNames on it. Is there any way to have this automatically run once we lose all references to this variable (and all copies)? I don't know. I've only used ForeignPtrs with finalisers before [1]. One problem with these finalisers is that GHC provides no guarantees on when they will be run. It might be just before the program exits, instead of when the pointer actually becomes unreachable. Because texture memory is a scarce resource, I wouldn't want to rely on a finaliser to free it -- though I suppose this depends on what you're doing. Ben. [1] http://www.haskell.org/ghc/docs/latest/html/libraries/haskell2010-1.1.0.1/Foreign-ForeignPtr.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Loading a texture in OpenGL
I would be running the GC manually at key points to make sure it gets cleaned up. Mainly, before any scene changes when basically everything gets thrown out anyways. On Mon, Feb 6, 2012 at 10:49 PM, Ben Lippmeier b...@ouroborus.net wrote: On 07/02/2012, at 2:40 PM, Clark Gaebel wrote: Awesome. Thanks! As a follow up question, how do I add a finalizer to a normal variable? OpenGL returns an integer handle to your texture in graphics memory, and you have to call deleteObjectNames on it. Is there any way to have this automatically run once we lose all references to this variable (and all copies)? I don't know. I've only used ForeignPtrs with finalisers before [1]. One problem with these finalisers is that GHC provides no guarantees on when they will be run. It might be just before the program exits, instead of when the pointer actually becomes unreachable. Because texture memory is a scarce resource, I wouldn't want to rely on a finaliser to free it -- though I suppose this depends on what you're doing. Ben. [1] http://www.haskell.org/ghc/docs/latest/html/libraries/haskell2010-1.1.0.1/Foreign-ForeignPtr.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Loading a texture in OpenGL
On 07/02/2012, at 2:50 PM, Clark Gaebel wrote: I would be running the GC manually at key points to make sure it gets cleaned up. Mainly, before any scene changes when basically everything gets thrown out anyways. From the docs: newForeignPtr :: FinalizerPtr a - Ptr a - IO (ForeignPtr a)Source Turns a plain memory reference into a foreign pointer, and associates a finalizer with the reference. The finalizer will be executed after the last reference to the foreign object is dropped. There is no guarantee of promptness, however the finalizer will be executed before the program exits. No guarantee of promptness. Even if the GC knows your pointer is unreachable, it might choose not to call the finaliser. I think people have been bitten by this before. Ben. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Loading a texture in OpenGL
Is the Haskell garbage collector conservative, or precise? If it's conservative, then this will only usually work. If it's precise, it should always work. On Mon, Feb 6, 2012 at 10:56 PM, Ben Lippmeier b...@ouroborus.net wrote: On 07/02/2012, at 2:50 PM, Clark Gaebel wrote: I would be running the GC manually at key points to make sure it gets cleaned up. Mainly, before any scene changes when basically everything gets thrown out anyways. From the docs: newForeignPtr :: FinalizerPtr a - Ptr a - IO (ForeignPtr a)Source Turns a plain memory reference into a foreign pointer, and associates a finalizer with the reference. The finalizer will be executed after the last reference to the foreign object is dropped. There is no guarantee of promptness, however the finalizer will be executed before the program exits. No guarantee of promptness. Even if the GC knows your pointer is unreachable, it might choose not to call the finaliser. I think people have been bitten by this before. Ben. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Loading a texture in OpenGL
It's a precise GC of course (conservative collection would be madness considering how much memory Haskell programs chew through.) That still doesn't ensure your finalizer will run during the next GC even if all the references are gone by then. Sent from my iPhone^H^H^H^H^HPortable Turing machine On Feb 6, 2012, at 10:09 PM, Clark Gaebel cgae...@csclub.uwaterloo.ca wrote: Is the Haskell garbage collector conservative, or precise? If it's conservative, then this will only usually work. If it's precise, it should always work. On Mon, Feb 6, 2012 at 10:56 PM, Ben Lippmeier b...@ouroborus.net wrote: On 07/02/2012, at 2:50 PM, Clark Gaebel wrote: I would be running the GC manually at key points to make sure it gets cleaned up. Mainly, before any scene changes when basically everything gets thrown out anyways. From the docs: newForeignPtr :: FinalizerPtr a - Ptr a - IO (ForeignPtr a)Source Turns a plain memory reference into a foreign pointer, and associates a finalizer with the reference. The finalizer will be executed after the last reference to the foreign object is dropped. There is no guarantee of promptness, however the finalizer will be executed before the program exits. No guarantee of promptness. Even if the GC knows your pointer is unreachable, it might choose not to call the finaliser. I think people have been bitten by this before. Ben. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Loading a texture in OpenGL
Even the next major, manually triggered GC? I'm just dealing with GHC here, if that simplifies the discussion. Although important and good to know, I don't really care what the spec says here. I just want to know if, with the current implementation of GHC, finalizeres will be run if a GC is manually triggered and there are no references to the objects they point to. Also, afaik, the performGC function is a GHC extension anyways. On Mon, Feb 6, 2012 at 11:16 PM, Austin Seipp mad@gmail.com wrote: It's a precise GC of course (conservative collection would be madness considering how much memory Haskell programs chew through.) That still doesn't ensure your finalizer will run during the next GC even if all the references are gone by then. Sent from my iPhone^H^H^H^H^HPortable Turing machine On Feb 6, 2012, at 10:09 PM, Clark Gaebel cgae...@csclub.uwaterloo.ca wrote: Is the Haskell garbage collector conservative, or precise? If it's conservative, then this will only usually work. If it's precise, it should always work. On Mon, Feb 6, 2012 at 10:56 PM, Ben Lippmeier b...@ouroborus.net wrote: On 07/02/2012, at 2:50 PM, Clark Gaebel wrote: I would be running the GC manually at key points to make sure it gets cleaned up. Mainly, before any scene changes when basically everything gets thrown out anyways. From the docs: newForeignPtr :: FinalizerPtr a - Ptr a - IO (ForeignPtr a)Source Turns a plain memory reference into a foreign pointer, and associates a finalizer with the reference. The finalizer will be executed after the last reference to the foreign object is dropped. There is no guarantee of promptness, however the finalizer will be executed before the program exits. No guarantee of promptness. Even if the GC knows your pointer is unreachable, it might choose not to call the finaliser. I think people have been bitten by this before. Ben. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Loading a texture in OpenGL
Just to clarify, this guarantee possibly could be made, ghc just doesn't do it now. In the past ghc never guaranteed a finalizer would ever be run. Regardless I would be wary of trusting finalizers to clean up very scarce resources. A malloc'd buffer is probably fine to have a finalizer for, texture objects or file descriptors are a different matter. Predictability matters in those cases. Sent from my iPhone^H^H^H^H^HPortable Turing machine On Feb 6, 2012, at 10:16 PM, Austin Seipp mad@gmail.com wrote: It's a precise GC of course (conservative collection would be madness considering how much memory Haskell programs chew through.) That still doesn't ensure your finalizer will run during the next GC even if all the references are gone by then. Sent from my iPhone^H^H^H^H^HPortable Turing machine On Feb 6, 2012, at 10:09 PM, Clark Gaebel cgae...@csclub.uwaterloo.ca wrote: Is the Haskell garbage collector conservative, or precise? If it's conservative, then this will only usually work. If it's precise, it should always work. On Mon, Feb 6, 2012 at 10:56 PM, Ben Lippmeier b...@ouroborus.net wrote: On 07/02/2012, at 2:50 PM, Clark Gaebel wrote: I would be running the GC manually at key points to make sure it gets cleaned up. Mainly, before any scene changes when basically everything gets thrown out anyways. From the docs: newForeignPtr :: FinalizerPtr a - Ptr a - IO (ForeignPtr a)Source Turns a plain memory reference into a foreign pointer, and associates a finalizer with the reference. The finalizer will be executed after the last reference to the foreign object is dropped. There is no guarantee of promptness, however the finalizer will be executed before the program exits. No guarantee of promptness. Even if the GC knows your pointer is unreachable, it might choose not to call the finaliser. I think people have been bitten by this before. Ben. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contributing to http-conduit
+1 On Mon, Feb 6, 2012 at 11:16 PM, Aristid Breitkreuz arist...@googlemail.com wrote: I would say: if it adds no package dependencies, put it right in. Aristid Am 06.02.2012 22:09 schrieb Myles C. Maxfield myles.maxfi...@gmail.com: After all these commits have been flying around, I have yet another question: the 'HTTP' package defines Network.Browser which is a State monad which keeps state about a browser (i.e. a cookie jar, a proxy, redirection parameters, etc.) It would be pretty straightforward to implement this kind of functionality on top of http-conduit. I was originally going to do it and release it as its own package, but it may be beneficial to add such a module to the existing http-conduit package. Should I add it in to the existing package, or release it as its own package? --Myles On Mon, Feb 6, 2012 at 12:15 AM, Michael Snoyman mich...@snoyman.com wrote: Just an FYI for everyone: Myles sent an (incredibly thorough) pull request to handle cookies: https://github.com/snoyberg/http-conduit/pull/13 Thanks! On Sun, Feb 5, 2012 at 8:20 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: 1. The spec defines a grammar for the attributes. They're in uppercase. 2. Yes - 1.3 is the first version that lists DiffTime as an instance of RealFrac (so I can use the 'floor' function to pull out the number of seconds to render it) 3. I'll see what I can do. --Myles On Sat, Feb 4, 2012 at 9:06 PM, Michael Snoyman mich...@snoyman.com wrote: Looks good, a few questions/requests: 1. Is there a reason to upper-case all the attributes? 2. Is the time = 1.3 a requirements? Because that can cause a lot of trouble for people. 3. Can you send the patch as a Github pull request? It's easier to track that way. Michael On Sat, Feb 4, 2012 at 1:21 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Here is the patch to Web.Cookie. I didn't modify the tests at all because they were already broken - they looked like they hadn't been updated since SetCookie only had 5 parameters. I did verify by hand that the patch works, though. Thanks, Myles On Thu, Feb 2, 2012 at 11:26 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Alright, I'll make a small patch that adds 2 fields to SetCookie: setCookieMaxAge :: Maybe DiffTime setCookieSecureOnly :: Bool I've also gotten started on those cookie functions. I'm currently writing tests for them. @Chris: The best advice I can give is that Chrome (what I'm using as a source on all this) has the data baked into a .cc file. However, they have directions in a README and a script which will parse the list and generate that source file. I recommend doing this. That way, the Haskell module would have 2 source files: one file that reads the list and generates the second file, which is a very large source file that contains each element in the list. The list should export `elem`-type queries. I'm not quite sure how to handle wildcards that appear in the list - that part is up to you. Thanks for helping out with this :] --Myles On Thu, Feb 2, 2012 at 10:53 PM, Michael Snoyman mich...@snoyman.com wrote: Looks good to me too. I agree with Aristid: let's make the change to cookie itself. Do you want to send a pull request? I'm also considering making the SetCookie constructor hidden like we have for Request, so that if in the future we realize we need to add some other settings, it doesn't break the API. Chris: I would recommend compiling it into the module. Best bet would likely being converting the source file to Haskell source. Michael On Fri, Feb 3, 2012 at 6:32 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Alright. After reading the spec, I have these questions / concerns: The spec supports the Max-Age cookie attribute, which Web.Cookies doesn't. I see two possible solutions to this. The first is to have parseSetCookie take a UTCTime as an argument which will represent the current time so it can populate the setCookieExpires field by adding the Max-Age attribute to the current time. Alternatively, that function can return an IO SetCookie so it can ask for the current time by itself (which I think is inferior to taking the current time as an argument). Note that the spec says to prefer Max-Age over Expires. Add a field to SetCookie of type Maybe DiffTime which represents the Max-Age attribute Cookie code should be aware of the Public Suffix List as a part of its domain verification. The cookie code only needs to be able to tell if a specific string is in the list (W.Ascii - Bool) I propose making an entirely unrelated package,
Re: [Haskell-cafe] ANN: exists-0.1
On 02/06/2012 03:32 AM, Gábor Lehel wrote: There's a common pattern in Haskell of writing: data E where E :: C a = a - E also written data E = forall a. C a = E a I recently uploaded a package to Hackage which uses the new ConstraintKinds extension to factor this pattern out into an Exists type parameterized on the constraint, and also for an Existential type class which can encompass these kind of types: http://hackage.haskell.org/package/exists My motivation was mostly to play with my new toys, if it turns out to be useful for anything that's a happy and unexpected bonus. Some interesting things I stumbled upon while writing it: [snip] - One of the advantages FunctionalDependencies has over TypeFamilies is that type signatures using them tend to be more readable and concise than ones which have to write out explicit equality constraints. For example, foo :: MonadState s m = s - m () is nicer than foo :: (MonadState m, State m ~ s) = s - m (). But with equality superclass constraints (as of GHC 7.2), it's possible to translate from TF-form to FD-form (but not the reverse, as far as I know): class (MonadStateTF m, s ~ State m) = MonadStateFDish s m; instance (MonadStateTF m, s ~ State m) = MonadStateFDish s m. Even better, you can write type ExistentialWith c e = (Existential e, c ~ ConstraintOf e) instead of class(Existential e, c ~ ConstraintOf e) = ExistentialWith c e instance (Existential e, c ~ ConstraintOf e) = ExistentialWith c e and drop UndecidableInstances. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
