Re: [Haskell-cafe] Re: Strange HTTP module behavior [PATCH]
John Goerzen wrote: > It turns out that Network.Socket.recv raises an EOF error when it gets > back 0 bytes of data. As it should... recv(2) returns zero bytes precisely when it reaches EOF; this is the standard sockets-API EOF indicator. See any sockets tutorial. > HTTP is expecting it to return an empty list for > some reason. That is odd; HTTP must be broken. --KW 8-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with building GCJNI 1.2
Hi, Sorry for not jumping in on this discussion sooner. I am the author of GCJNI. GCJNI was developed back when Hugs was the dominant Haskell implementation and GreenCard was the easiest/best way to do foreign language bindings for Haskell because the FFI proposal was still in the formative stages. These days, the Haskell FFI addendum is stable and widely implemented, ghc has become much more widely available and easy to install and use, and (without wishing to sound harsh), GreenCard's FFI code generator was broken and useless the last time I tried to use it (a few years ago). I actually ported GCJNI to the Haskell FFI a few years ago, getting rid of ALL use of GreenCard. I used ghc's 'hsc2hs' tool to help with the marshalling, and made no attempt to port to hugs. I called this newer system 'hsjni', but never released it due simply to lack of time while finishing my thesis. I invested a little effort in trying to test hsjni with the latest JDK and get a release together in December, but it got snagged on a silly little bug in hsc2hs's handling of paths which have embedded spaces. Simon Marlow has since fixed this bug in CVS head; I'm just waiting for the next release of ghc with this fix available before I try again. If you think you'd be interested in having a shot at building 'hsjni' (or you are interested in maintaining it), let me know, and I'll make the sources available for you. Caveat is that I haven't tested it since JDK 1.3, because of this hsc2hs issue. One can easily work around the hsc2hs path handling issue by installing the latest JDK in a location without a space in the filename; but since the default install location under Windows is under "C:\Program Files", I wasn't interested in shipping a release that wouldn't work with the most common default case. Please accept my sincere appology for not mentioning any of the above on the GCJNI web page. Hopefully it will just all be replaced with hsjni in the near future. Kind Regards, -Antony On Fri, 18 Feb 2005 20:45:14 +0100, Lemmih <[EMAIL PROTECTED]> wrote: > On Fri, 18 Feb 2005 20:37:35 +0100, Dmitri Pissarenko > <[EMAIL PROTECTED]> wrote: > > >>>Did you import Foreign.GreenCard? > > > > Now, I replaced "import StdDIS" by "import Foreign.GreenCard". > > The library apparently wasn't designed for newer versions of GreenCard > and it may be too old to fix easily. > > -- > Friendly, > Lemmih > ___ > 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
[Haskell-cafe] [darcs #222] performance problem with massive changes in a single file
I'm cc'ing haskell-cafe on this darcs bug, since I imagine there might be a student (or professor) hanging around there who might be interested in the implementation of an efficient LCS algorithm in haskell. [markjugg - Sun Feb 20 09:15:57 2005]: > Typically in software, 1000's of line aren't changed at the time, which > is why this hasn't been an big issue before. Indeed. The issue here is that darcs uses the exact Hunt-Szymanski LCS algorithm when it computes the diff, while GNU diff uses an approximate --but faster--algorithm, which works "almost" as well. The approximate algorithm is reasonably well-documented, but more complex to implement than the exact one, just because it's harder to understand. This would be a reasonable project for an interested haskell CS student. The LCS is implemented in pure haskell 98, and is of signature lcs :: Ord a => [a] -> [a] -> [a] It's an interesting problem that's easily testable, and has different scaling behavior in different limits (finite alphabet, infinite alphabet, permutations of unique objects). David (ever optimistic for new contributors to darcs!) http://darcs.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Parsec online resource
HI Guys, i'm trying to use parsec to do some data creation for me. was reading the online user documentation and all seems well. however, i can't dig how i can use the result of the parsing. any ideas/resources you can point out would be of very big help. just in case you're interested. i'm trying to implement a YAML parser. that is: 1) read a YAML file containing data (say a list of names) 2) parse the YAML file (this is where parsec comes in) 3) come out with a list (int haskell) after parsing the YAML source. kind regards, eyan -- http://www.eyan.org Object-oriented programming offers a sustainable way to write spaghetti code. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Strange HTTP module behavior [PATCH]
On Mon, Feb 21, 2005 at 10:43:33AM +, Keith Wansbrough wrote: > John Goerzen wrote: > > > It turns out that Network.Socket.recv raises an EOF error when it gets > > back 0 bytes of data. > > As it should... recv(2) returns zero bytes precisely when it reaches > EOF; this is the standard sockets-API EOF indicator. See any sockets > tutorial. Of course. That's why I'm saying the exception is unexpected. recv() doesn't return -1 (indicating an error); it just returns an empty list. For what seems like a direct binding to a low-level call, this action is surprising. If it were documented in the fptools haddock docs, it probably wouldn't surprise me. But as someone that is used to the C API, that behavior is surprising. > > HTTP is expecting it to return an empty list for > > some reason. > > That is odd; HTTP must be broken. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec online resource
On Mon, 21 Feb 2005, Edwin Eyan Moragas wrote: however, i can't dig how i can use the result of the parsing. There's a group of functions runParser, parse, parseFromFile and parseTest all of which 'run' Parsec parsers on input given by one of their parameters and return the result of parsing. -- [EMAIL PROTECTED] Performance anxiety leads to premature optimisation ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec online resource
On Mon, 21 Feb 2005 14:36:34 + (GMT Standard Time), Philippa Cowderoy <[EMAIL PROTECTED]> wrote: > On Mon, 21 Feb 2005, Edwin Eyan Moragas wrote: > > > however, i can't dig how i can use the result > > of the parsing. > > > > There's a group of functions runParser, parse, parseFromFile and parseTest > all of which 'run' Parsec parsers on input given by one of their > parameters and return the result of parsing. > thanks for this. will get back you when i've got some running code. -- http://www.eyan.org Object-oriented programming offers a sustainable way to write spaghetti code. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Strange HTTP module behavior [PATCH]
Hmmm... FWIW, I've been using a lightly modified version of Bjorn's version of HTTP in a modified HaXml parser, and it worked fine for accessing external entities. But that almost certainly did not involve receiving zero bytes. #g -- At 16:58 18/02/05 -0600, John Goerzen wrote: On Fri, Feb 18, 2005 at 11:36:57PM +0100, Bjorn Bringert wrote: > John Goerzen wrote: > >It turns out that Network.Socket.recv raises an EOF error when it gets > >back 0 bytes of data. HTTP is expecting it to return an empty list for > >some reason. > > > >The below patch fixed it for me. > > [...] > > Hmm, strange. Is that recv behavior a bug or a feature? I don't know, but it's explicitly there whatever it is. From ghc 6.2.2: let len' = fromIntegral len if len' == 0 then ioError (mkEOFError "Network.Socket.recv") else peekCStringLen (ptr,len') It appears this change was committed to fptools in version 1.26 of Socket.hsc on July 15, 2002. http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/network/Network/Socket.hsc.diff?r1=1.25;r2=1.26;f=h Which arguably is not what one would expect recv to do, and in any case is undocumented at http://www.haskell.org/ghc/docs/latest/html/libraries/network/Network.Socket.html#v%3Arecv Still, 2002 was awhile back, so I'm still surprised nobody else noticed. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New to haskell: unresolved overloading question
Blair Fraser wrote: I'm new to haskell and I'm working through the class section of the gentle tutorial. I decided to implement an ApproxEq class (just for fun), but have run into problems. The code below works fine for units and bools, but gives an unresolved overloading error for Floats and Doubles. What's going on here? What does the error message mean and what did I do wrong? (I'm in Hugs.) -- ApproxEq: My first class. class (Eq a) => ApproxEq a where (~=) :: a -> a -> Bool x ~= y = x == y -- By default, check equality -- These two override default with same, just checking if it works instance ApproxEq () where () ~= () = True instance ApproxEq Bool where x ~= y = x == y -- These two override default with different -- consider floating points equal if they differ by one or less instance ApproxEq Float where x ~= y = (abs (x-y) <= 1) instance ApproxEq Double where x ~= y = (abs (x-y) <= 1) More elegant seems to be: instance (Ord a, Num a) => ApproxEq a where x ~= y = (abs (x-y) < 1) However, this requires extensions to "Allow unsafe overlapping instances": hugs -98 +O ghci -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -fallow-incoherent-instances -- This one dosn't work either, but it just depends on the other two instance ApproxEq a => ApproxEq [a] where [] ~= [] = True (x:xs) ~= (y:ys) = x ~= y && xs ~= ys _ ~= _ = False Thanks, Blair ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec online resource
There's a very simple example of using Parsec, complete with some test cases, here: http://www.ninebynine.org/Software/HaskellUtils/RegexParser.hs #g -- At 22:07 21/02/05 +0800, Edwin Eyan Moragas wrote: HI Guys, i'm trying to use parsec to do some data creation for me. was reading the online user documentation and all seems well. however, i can't dig how i can use the result of the parsing. any ideas/resources you can point out would be of very big help. just in case you're interested. i'm trying to implement a YAML parser. that is: 1) read a YAML file containing data (say a list of names) 2) parse the YAML file (this is where parsec comes in) 3) come out with a list (int haskell) after parsing the YAML source. kind regards, eyan -- http://www.eyan.org Object-oriented programming offers a sustainable way to write spaghetti code. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New to haskell: unresolved overloading question
There are problems with this approach... Instance heads are only chosen by the pattern not the constraints, so: instance (Ord a, Num a) => ApproxEq a where x ~= y = (abs (x-y) < 1) Will match any type at all (whether a member of Ord or Num or not) and then will fail if the particular type is not an instance of Ord or Num. Using incoherent-instances is almost certainly broken as it just stops the compiler complaining is a generic instance (like above) overlaps with a specific instance in the wrong way. Using the flag just makes GHC silently choose the _most_generic_instance_. Almost alwaysApproxEq we want the opposite behaviour and want GHC to choose the most specific instance in the case of overlap. However it should do what you want with just -foverlapping-instances -fundecidable-instances. Keean. Christian Maeder wrote Blair Fraser wrote: I'm new to haskell and I'm working through the class section of the gentle tutorial. I decided to implement an ApproxEq class (just for fun), but have run into problems. The code below works fine for units and bools, but gives an unresolved overloading error for Floats and Doubles. What's going on here? What does the error message mean and what did I do wrong? (I'm in Hugs.) -- ApproxEq: My first class. class (Eq a) => ApproxEq a where (~=) :: a -> a -> Bool x ~= y = x == y -- By default, check equality -- These two override default with same, just checking if it works instance ApproxEq () where () ~= () = Trueinstance ApproxEq Bool where x ~= y = x == y -- These two override default with different -- consider floating points equal if they differ by one or less instance ApproxEq Float where x ~= y = (abs (x-y) <= 1) instance ApproxEq Double where x ~= y = (abs (x-y) <= 1) More elegant seems to be: instance (Ord a, Num a) => ApproxEq a where x ~= y = (abs (x-y) < 1) However, this requires extensions to "Allow unsafe overlapping instances": hugs -98 +O ghci -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -fallow-incoherent-instances -- This one dosn't work either, but it just depends on the other two instance ApproxEq a => ApproxEq [a] where [] ~= [] = True (x:xs) ~= (y:ys) = x ~= y && xs ~= ys _ ~= _ = False Thanks, Blair ___ 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] Literate Haskell
On Saturday 19 February 2005 01:38, Mark Carroll wrote: > On Fri, 18 Feb 2005, Dmitri Pissarenko wrote: > > It seems to me like a good idea, since during coding it often helps > > to write down one's thoughts (often, I find a solution to a > > complicated problem in this way). > > > > What are your experiences with using literate Haskell? > > I used to use it - I also like to note things in among the code. > Now I tend to use Haddock documentation more. From my point of view, there is two different questions that some documentation might answer: "How does this work?" This documentation should describe the implementation design, issues, tricks, etc. I think that Literate Haskell is well suited to write documentation answering this question. By printing and reading a whole module, it is easy to follow the implementor thoughts. "How should I use this?" This documentation should describe how to use a module (let's say "its API") without understanding more than needed how it works under the hood. It should be indexed and hyperlinked when one needs to quickly lookup the behaviour for some function. Haddock was designed to write this kind of documentation. I really see Literate Haskell and Haddock as two orthogonal tools, and that help me to focus when writing docs. Cheers, Jérémy. pgpW7yJyQgniY.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative lambda syntax (not entirely serious)
On Fri, Feb 18, 2005 at 03:41:59PM -0800, Fritz Ruehr wrote: > So, since a lambda abstraction denotes an anonymous function, the > underscore signifies anonymous things, and given that "->" of the > current syntax connotes a type than a value, I thought "why not this > syntax instead?": > > (_ x = x)-- the identity function > > (_ (x,y) = x)-- the fst function > > (_ f g x = f (g x)) -- composition > > In other words, at a lexical level we simply write "_" in place of "\" > and "=" in place of "->". The use and placement of the "_" nicely > indicates that what we are denoting is both anonymous and a function, > and the use of the "=" makes it more parallel to the definition of a > named function. There would be an additional confusion if you couldn't replace _ with a named variable. If you could, it would be interesting, as it would allow to succintly define anonymous recursive functions (without let, where or fix). Unfortunately, it looks like parsing nightmare, both for humans and compilers. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Haskell news/community site
Hi, I'm setting up a Haskell news & community site. Check it out at: http://sequence.complete.org/ It supports aggregation of Haskell blogs and discussion from various sources (including this list). Any registered user can submit content for the front page, and all registered users can vote to approve or reject such submissions. The first thing to do is pick a real name. I hope that eventually this can be a *.haskell.org site. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [darcs #222] performance problem with massive changes in a single file
G'day all. Quoting David Roundy via RT <[EMAIL PROTECTED]>: > Indeed. The issue here is that darcs uses the exact Hunt-Szymanski LCS > algorithm when it computes the diff, while GNU diff uses an approximate > --but faster--algorithm, which works "almost" as well. The approximate > algorithm is reasonably well-documented, but more complex to implement > than the exact one, just because it's harder to understand. This isn't entirely true. The Myers algorithm used in GNU diff is exact. However, it's also designed to adapt (if allowed) in the case where it seems to be taking too long. GNU diff also goes to some trouble to help the Myers algorithm along. A common case in real-life diffing is that you have a "block" of adjacent lines in one file, none of which appear in the other file. In that case, the block can be combined into one "virtual line", which reduces the effective length of the diff, making most LCS algorithms go faster. A problem with the Myers algorithm is that the diff that it produces is less "pretty" than that produced by most other means. > This would be a reasonable project for an interested haskell CS student. > The LCS is implemented in pure haskell 98, and is of signature > > lcs :: Ord a => [a] -> [a] -> [a] The returned list is proportional to the length of the smaller of the input lists, which is, in general, quite large compared with the size of the patch. It's probably more efficient to produce a list of edits: data Source = LeftFile | RightFile diff :: (Ord a) => [a] -> [a] -> [(SourceFile, Int)] Where each tuple represents a line which has no correspondence in the other file. If anyone is curious, I did a pretty complete implementation of diff for Mercury: http://www.mercury.cs.mu.oz.au/ It should be fairly directly translatable into Haskell if someone doesn't feel like thinking. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with building GCJNI 1.2
Hi, Sorry for not jumping in on this discussion sooner. I am the author of GCJNI. GCJNI was developed back when Hugs was the dominant Haskell implementation and GreenCard was the easiest/best way to do foreign language bindings for Haskell because the FFI proposal was still in the formative stages. These days, the Haskell FFI addendum is stable and widely implemented, ghc has become much more widely available and easy to install and use, and (without wishing to sound harsh), GreenCard's FFI code generator was broken and useless the last time I tried to use it (a few years ago). I actually ported GCJNI to the Haskell FFI a few years ago, getting rid of ALL use of GreenCard. I used ghc's 'hsc2hs' tool to help with the marshalling, and made no attempt to port to hugs. I called this newer system 'hsjni'. It worked very well for my needs (using the Java2D rendering engine as the back-end for a prototype Haskell GUI system). I never released hsjni simply due to lack of time while finishing my thesis. I invested a little effort in trying to test hsjni with the latest JDK and get a release together in December, but it got snagged on a silly little bug in hsc2hs's handling of paths which have embedded spaces. A minor bug, to be sure, but since the default installation location for the JDK under Windows is under "C:\Program Files", the bug meant hsjni couldn't work out-of-the-box for the most common installation of the prerequisites. Simon Marlow has since fixed this bug in CVS head; I'm just waiting for the next release of ghc with this fix available before I try again. If you think you'd be interested in having a shot at building 'hsjni' (or you are interested in maintaining it), let me know, and I'll make the sources available for you. Caveat is that I haven't tested it since JDK 1.3, because of this hsc2hs issue. My appologies for not mentioning any of the above on the GCJNI web page. Hopefully the whole GCJNI release and web pages can be deprecated soon, with hsjni offered in its place. Kind Regards, -Antony -- Antony Courtneyemail: [EMAIL PROTECTED] New York, NY WWW: http://www.apocalypse.org/~antony ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New to haskell: unresolved overloading question
Am Montag, 21. Februar 2005 17:32 schrieb Christian Maeder: > Blair Fraser wrote: > > I'm new to haskell and I'm working through the class section of the > > gentle tutorial. I decided to implement an ApproxEq class (just for > > fun), but have run into problems. The code below works fine for units > > and bools, but gives an unresolved overloading error for Floats and > > Doubles. What's going on here? What does the error message mean and > > what did I do wrong? (I'm in Hugs.) > > > > -- ApproxEq: My first class. > > class (Eq a) => ApproxEq a where > > (~=) :: a -> a -> Bool > > x ~= y = x == y -- By default, check equality > > > > -- These two override default with same, just checking if it works > > instance ApproxEq () where () ~= () = True > > instance ApproxEq Bool where x ~= y = x == y > > > > -- These two override default with different > > -- consider floating points equal if they differ by one or less > > instance ApproxEq Float where x ~= y = (abs (x-y) <= 1) > > instance ApproxEq Double where x ~= y = (abs (x-y) <= 1) > > More elegant seems to be: > > instance (Ord a, Num a) => ApproxEq a where x ~= y = (abs (x-y) < 1) > > However, this requires extensions to "Allow unsafe overlapping instances": > > hugs -98 +O > > ghci -fglasgow-exts -fallow-overlapping-instances > -fallow-undecidable-instances -fallow-incoherent-instances > > > -- This one dosn't work either, but it just depends on the other two > > instance ApproxEq a => ApproxEq [a] where > > [] ~= [] = True > > (x:xs) ~= (y:ys) = x ~= y && xs ~= ys > > _ ~= _ = False > > > > Thanks, > > Blair > For the original code, no extensions are necessary (and neither hugs nor ghc does complain). Probably something like ApproxEq> 1.5 ~= 2.4 ERROR - Unresolved overloading *** Type : (Fractional a, ApproxEq a) => Bool *** Expression : 1.5 ~= 2.4 happened, that doesn't mean there is any problem with the code, only that the interpreter doesn't know what type 1.5 and 2.4 have. Adding a type to either resolves: ApproxEq> 1.5 ~= (2.4::Double) True ApproxEq> [1,2,3] ~= [1.6,2.8,3.] ERROR - Unresolved overloading *** Type : (Fractional a, ApproxEq a) => Bool *** Expression : [1,2,3] ~= [1.6,2.8,3.] ApproxEq> [1,2,3] ~= ([1.6,2.8,3.]::[Float]) True That's a very common problem for newbies, so don't panic. In older versions of hugs (November 2002, e.g.), you would have got an unresolved overloading also from entering [] to the prompt (this is no longer so). If such things happen, add an explicit typing, if that doesn't help, then you have a problem. To deepen the confusion, hugs has no problems with Prelude> 1.5 == 1.5 True I'm not quite sure why this works, must be due to type defaulting, however, including default (Double) doesn't help ApproxEq, so there must be more to it in the (==) case. BTW, if you add Christian's instance, for hugs, -98 +o (lower case o, allow overlapping instances) suffices, for ghci, -fallow-incoherent-instances is not necessary. Stay with Haskell, it's great (though not perfect)! Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
