[Haskell-cafe] Experiences with cabal-install and Hackage
I've rather recently started to use cabal-install to install packages from Hackage. Unfortunately, so far many packages fail to install. I try to email authors/maintainers, but when I check build logs on Hackage, I discover that some of these packages have failed building for some time. Wouldn't it make sense to provide automated notification of the package author when a package fails to build? I certainly would like to know about it, but of course, I never remember to check back to see. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Experiences with cabal-install and Hackage
That sounds like a good idea. I'd like to know when my packages fail to build or show warnings about deprecated features, etc. On 22 July 2010 09:16, Ketil Malde ke...@malde.org wrote: I've rather recently started to use cabal-install to install packages from Hackage. Unfortunately, so far many packages fail to install. I try to email authors/maintainers, but when I check build logs on Hackage, I discover that some of these packages have failed building for some time. Wouldn't it make sense to provide automated notification of the package author when a package fails to build? I certainly would like to know about it, but of course, I never remember to check back to see. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ 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] Porting ELF statifier to Haskell!
Interesting tool. For my recent work I too have found a use for the elf package, but its lack of a full binary instance and no parsing of .symtab or .dynstr sections limits its usefulness. This isn't a debilitating limitation - you can use elf for basic inspection then perform mutations via objcopy and ld, which are more likely to have any oddities / corner cases accounted for anyway. Thomas On Wed, Jul 21, 2010 at 9:20 PM, C K Kashyap ckkash...@gmail.com wrote: Hi, At my work we ran into a situation where we started wishing there was a way to take a dynamically linked executable and create a statically linked bundle out of it. Little bit of googling got me to statifier - http://statifier.sourceforge.net/statifier/main.html. The project seems a little old and when I tried it out on my 32bit RHEL5 box, the statically linked file did not run. So I thought it would be a good exercise to try and use Haskell's Elf module (Data.Elf) and attempt to build a statifier. Just wanted to understand if anyone's tried this before or have any advice for me. -- Regards, Kashyap ___ 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] Experiences with cabal-install and Hackage
On Thu, Jul 22, 2010 at 9:16 AM, Ketil Malde ke...@malde.org wrote: I've rather recently started to use cabal-install to install packages from Hackage. Unfortunately, so far many packages fail to install. I try to email authors/maintainers, but when I check build logs on Hackage, I discover that some of these packages have failed building for some time. Wouldn't it make sense to provide automated notification of the package author when a package fails to build? I certainly would like to know about it, but of course, I never remember to check back to see. How about taking it one step further, actually hiding unmaintained packages after a grace period? Unless the user runs cabal with an --include-deprecated option, or something. Isak -k -- If I haven't seen further, it is by standing in the footprints of giants ___ 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] Experiences with cabal-install and Hackage
I don't know how wise that is; I tend to fix packages when I find they're broken. I'd prefer a way for there to be more than one maintainer for a package, i.e., collaborators, like on Github, so that a maintainer can add me as a collaborator. My only problem with Hackage is I feel like the maintainer is a fence I have to climb every time I want to upload a bugfix or a non-broken version of the package. I just want to fix it, upload it, and continue with my work. Also a last seen a la StackOverflow would be good, so that you can see what a maintainer was last on Hackage. That's assuming the new Hackage will support logins. On 22 July 2010 09:52, Isak Hansen isak.han...@gmail.com wrote: On Thu, Jul 22, 2010 at 9:16 AM, Ketil Malde ke...@malde.org wrote: I've rather recently started to use cabal-install to install packages from Hackage. Unfortunately, so far many packages fail to install. I try to email authors/maintainers, but when I check build logs on Hackage, I discover that some of these packages have failed building for some time. Wouldn't it make sense to provide automated notification of the package author when a package fails to build? I certainly would like to know about it, but of course, I never remember to check back to see. How about taking it one step further, actually hiding unmaintained packages after a grace period? Unless the user runs cabal with an --include-deprecated option, or something. Isak -k -- If I haven't seen further, it is by standing in the footprints of giants ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On documentation
2010/7/21 Richard O'Keefe o...@cs.otago.ac.nz: One of the really nice ideas in the R statistics system is that documentation pages can contain executable examples, and when you wrap up a package for distribution, the system checks that the examples run as advertised. The next version of Haddock will support something like this, implemented by SImon Hengel. Here's an example of how to use the new markup: -- | An example: -- -- ghci fib 10 -- 55 -- Haskell has a *perfect* fit for this idea in QuickCheck. We currently only support concrete examples (i.e. unit tests), but the plan is to add support for QuickCheck properties. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal, Setup.lhs example
On Wed, Jul 21, 2010 at 17:43, Rogan Creswick cresw...@gmail.com wrote:
On Wed, Jul 21, 2010 at 3:00 AM, Magnus Therning mag...@therning.org wrote:
I am successfully using hooks with the following in my .cabal file:
Build-Type : Simple
and my main in Setup.hs looks like this:
main = defaultMainWithHooks $ simpleUserHooks
{ cleanHook = profileClean
, runTests = runTestsBuild
}
I've been unable to reproduce this -- flipping the build type to Custom has
been necessary in every configuration I've tried. I'd like to see what I'm
doing differently -- is this used in a publicly available package I could
take a look at?
It's not ready to be made public yet, but I put together the following
example:
% cat test.cabal
Name : test
Version : 0.0.0
License : GPL
Author: Magnus Therning
Maintainer: mag...@therning.org
Copyright : Magnus Therning, 2009
Build-Type: Simple
Cabal-Version : = 1.2
Executable test
Main-Is: Main.hs
Build-Depends : base = 4.2.0 4.3
% cat Setup.hs
#! /usr/bin/env runhaskell
import Distribution.Simple
main = defaultMainWithHooks $ simpleUserHooks
{ cleanHook = profileClean
}
profileClean pd v uh cf = do
(cleanHook simpleUserHooks) pd v uh cf
putStrLn ** in hook
% ./Setup.hs configure
Configuring test-0.0.0...
% ./Setup.hs clean
cleaning...
** in hook
Could it be a difference in versions?
% ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.1
% ghc-pkg list | grep Cabal
Cabal-1.8.0.2
/M
--
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus＠therning．org Jabber: magnus＠therning．org
http://therning.org/magnus identi.ca|twitter: magthe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Experiences with cabal-install and Hackage
My only problem with Hackage is I feel like the maintainer is a fence I have to climb every time I want to upload a bugfix or a non-broken version of the package. I just want to fix it, upload it, and continue with my work. Unfortunately, experience shows that a gatekeeper is usually necessary. Otherwise random people create and apply patches that break stuff they don't care about, whilst fixing only their immediate problem. Distributed version control, like darcs and git, already lowers the barrier to participation very significantly. But having someone review patches before publishing them to the world at large is widely considered the most effective quality control known in the field of software engineering. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Experiences with cabal-install and Hackage
On Thu, Jul 22, 2010 at 10:02, Malcolm Wallace malcolm.wall...@me.com wrote: My only problem with Hackage is I feel like the maintainer is a fence I have to climb every time I want to upload a bugfix or a non-broken version of the package. I just want to fix it, upload it, and continue with my work. Unfortunately, experience shows that a gatekeeper is usually necessary. Otherwise random people create and apply patches that break stuff they don't care about, whilst fixing only their immediate problem. Distributed version control, like darcs and git, already lowers the barrier to participation very significantly. But having someone review patches before publishing them to the world at large is widely considered the most effective quality control known in the field of software engineering. An alternative would be to let people upload forks of a package, similar to how github/bitbucket supports forks on a VCS level. I'm not convinced it's a common enough situation to be worth the hassle though. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal, Setup.lhs example
On Wed, Jul 21, 2010 at 09:43:16AM -0700, Rogan Creswick wrote: On Wed, Jul 21, 2010 at 3:00 AM, Magnus Therning mag...@therning.org wrote: I am successfully using hooks with the following in my .cabal file: Build-Type : Simple I've been unable to reproduce this -- flipping the build type to Custom has been necessary in every configuration I've tried. I'd like to see what I'm doing differently -- is this used in a publicly available package I could take a look at? Magnus is building by directly running the Setup.hs himself, which ignores the Build-Type. To get cabal-install to use his Setup.hs, the Build-Type must be set to Custom. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal, Setup.lhs example
On Thu, Jul 22, 2010 at 10:59, Ross Paterson r...@soi.city.ac.uk wrote: On Wed, Jul 21, 2010 at 09:43:16AM -0700, Rogan Creswick wrote: On Wed, Jul 21, 2010 at 3:00 AM, Magnus Therning mag...@therning.org wrote: I am successfully using hooks with the following in my .cabal file: Build-Type : Simple I've been unable to reproduce this -- flipping the build type to Custom has been necessary in every configuration I've tried. I'd like to see what I'm doing differently -- is this used in a publicly available package I could take a look at? Magnus is building by directly running the Setup.hs himself, which ignores the Build-Type. To get cabal-install to use his Setup.hs, the Build-Type must be set to Custom. Oh, why*2? Why is the header there if it's not used by Cabal, and why does cabal care? Cheers, M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On documentation
David Waern wrote: 2010/7/21 Richard O'Keefe o...@cs.otago.ac.nz: One of the really nice ideas in the R statistics system is that documentation pages can contain executable examples, and when you wrap up a package for distribution, the system checks that the examples run as advertised. The next version of Haddock will support something like this, implemented by SImon Hengel. Here's an example of how to use the new markup: -- | An example: -- -- ghci fib 10 -- 55 Awesome. This is similar to Python's thing. Haskell has a *perfect* fit for this idea in QuickCheck. We currently only support concrete examples (i.e. unit tests), but the plan is to add support for QuickCheck properties. Also support SmallCheck/LazySmallCheck, pretty please? :) -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal, Setup.lhs example
On Thu, Jul 22, 2010 at 11:31:21AM +0100, Magnus Therning wrote: On Thu, Jul 22, 2010 at 10:59, Ross Paterson r...@soi.city.ac.uk wrote: Magnus is building by directly running the Setup.hs himself, which ignores the Build-Type. To get cabal-install to use his Setup.hs, the Build-Type must be set to Custom. Oh, why*2? Why is the header there if it's not used by Cabal, and why does cabal care? The field allows cabal to avoid compiling the Setup.hs in this case. It might also be used by other tools, e.g. one might only trust Simple packages. Not all fields are used by all tools, and several of them do not affect the operation of the library (e.g. Home-page). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal, Setup.lhs example
On Thu, Jul 22, 2010 at 11:52, Ross Paterson r...@soi.city.ac.uk wrote: On Thu, Jul 22, 2010 at 11:31:21AM +0100, Magnus Therning wrote: On Thu, Jul 22, 2010 at 10:59, Ross Paterson r...@soi.city.ac.uk wrote: Magnus is building by directly running the Setup.hs himself, which ignores the Build-Type. To get cabal-install to use his Setup.hs, the Build-Type must be set to Custom. Oh, why*2? Why is the header there if it's not used by Cabal, and why does cabal care? The field allows cabal to avoid compiling the Setup.hs in this case. It might also be used by other tools, e.g. one might only trust Simple packages. Not all fields are used by all tools, and several of them do not affect the operation of the library (e.g. Home-page). All right, so why would cabal want to avoid compiling the Setup.hs? Of course this behaviour of cabal's means that I in the future will use *Custom* all the time, since I otherwise have to remember this surprising feature of a tool I never use. Is there any reason *not* to do this? Cheers, M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Page rank and GHC docs directory organization
GHC docs seem to have the problem that newer versions only gradually overtake older ones in page rank, resulting in the effect that if one uses Google to find library documentation, they may accidentally look at an old version. For example, if I google Data.Data Haskell the first link brings me to: http://www.haskell.org/ghc/docs/6.10.2/html/libraries/base/Data-Data.html Oops, version 6.10.2! I'm no web expert, but I think the problem is that the latest directory isn't used consistently by others and/or the fact that latest/ redirects to a concrete version number. Thus if you go to: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Data.html It redirects immediately to 6.12.2: http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base/Data-Data.html So is the 6.12.2 target accruing pagerank rather than the latest one? Even if someone links the /latest/ URL? If that's the problem, would it fix things just to make latest/ a full directory structure in its own right (a clone rather than redirect)? Cheers, -Ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Page rank and GHC docs directory organization
On 22/07/10 15:33, Ryan Newton wrote: [snip] So is the 6.12.2 target accruing pagerank rather than the latest one? Even if someone links the /latest/ URL? If that's the problem, would it fix things just to make latest/ a full directory structure in its own right (a clone rather than redirect)? For the URLs under 'latest/' the server returns a 301 Moved Permanently response, which is used to indicate that the original URL is no longer in use and that references to it should be updated to the target URL [1]. Hence, search engines will only index the targets of the redirects and ignore the original URLs [2]. Using a 302 Found redirect instead might produce better results, at least for Google [2]. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2 [2] http://www.bigoakinc.com/blog/when-to-use-a-301-vs-302-redirect/ -- Robin KAY ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Porting ELF statifier to Haskell!
Thanks Thomas. On Thu, Jul 22, 2010 at 12:56 PM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: Interesting tool. For my recent work I too have found a use for the elf package, but its lack of a full binary instance and no parsing of .symtab or .dynstr sections limits its usefulness. This isn't a debilitating limitation - you can use elf for basic inspection then perform mutations via objcopy and ld, which are more likely to have any oddities / corner cases accounted for anyway. Thomas On Wed, Jul 21, 2010 at 9:20 PM, C K Kashyap ckkash...@gmail.com wrote: Hi, At my work we ran into a situation where we started wishing there was a way to take a dynamically linked executable and create a statically linked bundle out of it. Little bit of googling got me to statifier - http://statifier.sourceforge.net/statifier/main.html. The project seems a little old and when I tried it out on my 32bit RHEL5 box, the statically linked file did not run. So I thought it would be a good exercise to try and use Haskell's Elf module (Data.Elf) and attempt to build a statifier. Just wanted to understand if anyone's tried this before or have any advice for me. -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Page rank and GHC docs directory organization
On Thu, Jul 22, 2010 at 4:33 PM, Ryan Newton rrnew...@gmail.com wrote: GHC docs seem to have the problem that newer versions only gradually overtake older ones in page rank, resulting in the effect that if one uses Google to find library documentation, they may accidentally look at an old version. For example, if I google Data.Data Haskell the first link brings me to: http://www.haskell.org/ghc/docs/6.10.2/html/libraries/base/Data-Data.html Oops, version 6.10.2! I'm no web expert, but I think the problem is that the latest directory isn't used consistently by others and/or the fact that latest/ redirects to a concrete version number. Thus if you go to: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Data.html It redirects immediately to 6.12.2: http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base/Data-Data.html So is the 6.12.2 target accruing pagerank rather than the latest one? Even if someone links the /latest/ URL? If that's the problem, would it fix things just to make latest/ a full directory structure in its own right (a clone rather than redirect)? If we had a permanent entry page to the documentation, such as docs.haskell.org, that linked to the different kind of documentation (and was attractive enough that people would link to it) that might help. Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Experiences with cabal-install and Hackage
Not to discourage this brainstorming, but many of what people think to be new ideas are being implemented by a GsoC student [1] already. Yay! I've rather recently started to use cabal-install to install packages from Hackage. Unfortunately, so far many packages fail to install. I try to email authors/maintainers, but when I check build logs on Hackage, I discover that some of these packages have failed building for some time. The hackage build logs can be misleading - many system specific packages may or may not build on hackage because it just isn't the right OS. Still other packages require particular C libraries that the hackage server doesn't have. For these reasons the build reports will come from end developer systems (see linked blog). Wouldn't it make sense to provide automated notification of the package author when a package fails to build? I certainly would like to know about it, but of course, I never remember to check back to see. Yes, but because this comes from the cabal-installer vs hackage there was more work needing done. How about taking it one step further, actually hiding unmaintained packages after a grace period? Talk to Gracenotes and Coutts - they can be found on #hackage frequently. Cheers, Thomas [1] http://cogracenotes.wordpress.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Experiences with cabal-install and Hackage
On 22 July 2010 16:56, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: The hackage build logs can be misleading - many system specific packages may or may not build on hackage because it just isn't the right OS. Still other packages require particular C libraries that the hackage server doesn't have. For these reasons the build reports will come from end developer systems (see linked blog). Presumably you can only get false negatives - i.e. correct packages failing to build due to missing C libraries, or depending on Haskell libraries at different version numbers to the build server? Isak Hansen: How about taking it one step further, actually hiding unmaintained packages after a grace period? Hiding unmaintained libraries seems contrary to Hackage's spirit - if you want to depend on an unmaintained library why not volunteer to be the maintainer. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Experiences with cabal-install and Hackage
On Thursday 22 July 2010 18:23:32, Stephen Tetley wrote: On 22 July 2010 16:56, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: The hackage build logs can be misleading - many system specific packages may or may not build on hackage because it just isn't the right OS. Still other packages require particular C libraries that the hackage server doesn't have. For these reasons the build reports will come from end developer systems (see linked blog). Presumably you can only get false negatives - i.e. correct packages failing to build due to missing C libraries, or depending on Haskell libraries at different version numbers to the build server? Isak Hansen: How about taking it one step further, actually hiding unmaintained packages after a grace period? Hiding unmaintained libraries seems contrary to Hackage's spirit - if you want to depend on an unmaintained library why not volunteer to be the maintainer. I think it was more meant to be fails to build and not updated for (= k months) == move to packages/notshiny If it doesn't build and nobody seems to care about it anymore, why let it clutter the pkg-list, that's crowded enough even without zombies. Of course, new release that builds == back to pkg-list ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On documentation
Alexander Solla wrote: After all, the source is always structured in more-or-less the same way. Fragments of text with opaque -- unless/until you understand them -- combinators join two distinct concepts/types into functions. A chain of functions (potentially at various levels of abstraction) is a computation. You use these things by finding a chain of types (Start - A), (A - B), (B - C), ... (N - Goal) and composing, filling in additional details as necessary. Building that chain means doing depth first searches on a tree/graph of possibilities, and usually isn't so much fun. The library developer is in the best position to do exactly that, having already done it while constructing the library. In Haskell even learning to use a library has an algebraic structure. ;^) Actually, I was thinking just this afternoon... If you're writing in an OO language, you can use UML to produce diagrams that give you a kind of at-a-glance overview of the saliant parts of something. (Depending on how much detail you choose to include in the diagram.) I wander if anybody has a standardised notation that might be applicable to FP in general or Haskell specifically... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Regular Expression to Determinate Finite Automata translator
Hi, I am a Haskell newbie. I have coded a Regular Expression to Determinate Finite Automata translator. Algorithm from the Dragon Book. Would someone eyeball the code and give me suggestions please. I have not done anything on character classes yet though. And the parsing is a bit of a hack. What I am not sure about is having to have multiple versions of similar datatype, each with variations in order to enumerate and generate followPos set. Is there a better way of implementing this ? Many thanks in advance, Aaron RE2DFA.hs Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Regular Expression to Determinate Finite Automata translator
Some comments: - You can run your code thru HLint, here it gives me 27 suggestions. - Why don't you derive the Show instance for RE instead of writing it by yourself? - Note that do x do y ... is the same as do x y ... - You can parametrize RE as data RE s p = Epsilon | Leaf Char s p | Selection (RE s p) (RE s p) | Sequence (RE s p) (RE s p) | Kleene(RE s p) | Optional (RE s p) | End s deriving (Show) type RE1 = RE () () type RE2 = RE State () type RE3 = RE State Pos Cheers! =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Regular Expression to Determinate Finite Automata translator
The simplest way to make a recogniser out of a RE is to use one of the available parsing libraries: module RE where import Text.ParserCombinators.UU import Text.ParserCombinators.UU.Examples data RE = Epsilon | Leaf Char | Selection RE RE | Sequence RE RE | Kleene RE | Optional RE | End re_to_fsm :: RE - Parser String re_to_fsm re = case re of Leaf c- lift $ pSym c Selection re1 re2 - re_to_fsm re1 | re_to_fsm re2 Sequence re1 re2 - (++) $ re_to_fsm re1 * re_to_fsm re2 Kleene re - concat $ pList (re_to_fsm re) Optional re - re_to_fsm re `opt` End - pure t = re_to_fsm ((Kleene (Leaf 'a') `Sequence` Kleene (Leaf 'b')) `Selection` (Kleene (Leaf 'a') `Sequence` (Kleene (Leaf 'c') ))) t1 = run t aaabbb t2 = run t ccc t3 = run t aaddcc test = run (re_to_fsm (Kleene (Leaf 'a') `Sequence` Kleen (Left 'b')) aaabbb *RE t1 -- -- Result: aaabbb -- *RE t2 -- -- Result: ccc -- *RE t3 -- -- Result: aacc -- Correcting steps: -- Deleted 'd' at position 2 expecting one of ['a', 'c', 'a', 'b'] -- Deleted 'd' at position 3 expecting 'c' -- *RE On 22 jul 2010, at 20:51, Aaron Gray wrote: Hi, I am a Haskell newbie. I have coded a Regular Expression to Determinate Finite Automata translator. Algorithm from the Dragon Book. Would someone eyeball the code and give me suggestions please. I have not done anything on character classes yet though. And the parsing is a bit of a hack. What I am not sure about is having to have multiple versions of similar datatype, each with variations in order to enumerate and generate followPos set. Is there a better way of implementing this ? Many thanks in advance, Aaron RE2DFA.hs___ 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] bounded ranges
Hello cafe, I'm trying to do some things with bounded indices so I can carry around arrays (well, Vectors, really) without needing to refer to the bounds. For example, if I know my indices are Bool values, I can do rangeSize (minBound, maxBound :: Bool) 2 I'd like to be able to do this in general, but... :t rangeSize (minBound, maxBound) interactive:1:11: Ambiguous type variable `a' in the constraints: `Bounded a' arising from a use of `minBound' at interactive:1:11-18 `Ix a' arising from a use of `rangeSize' at interactive:1:0-29 Probable fix: add a type signature that fixes these type variable(s) I thought it might help to put it into a module and do a better job with the type, like this: bdRangeSize :: (Ix i, Bounded i) = i - Int bdRangeSize _ = rangeSize (minBound, maxBound :: i) but I still have problems: MyArray.hs:22:36: Could not deduce (Bounded i1) from the context () arising from a use of `maxBound' at MyArray.hs:22:36-43 Possible fix: add (Bounded i1) to the context of an expression type signature In the expression: maxBound :: i In the first argument of `rangeSize', namely `(minBound, maxBound :: i)' In the expression: rangeSize (minBound, maxBound :: i) I thought maybe it's an existential types problem or something, but I don't understand why it would be coming up here. Any thoughts? Oh yes, and I'm using GHC version 6.12.1. Thanks, Chad ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gd on Win32
On Fri, Jul 2, 2010 at 8:34 PM, Christopher Done chrisd...@googlemail.com wrote: That sounds like a good idea. I've setup a repo, I've merged in the latest work I did on it, and I've just updated it to be latest Prelude/base and to comply with -Wall. I'm just going to make it consistent with tibbe's style guide[1] before we start patching it for feature updates, so that we're singing from the same hymn sheet and then I'll let you you here. The Github repo is here: http://github.com/chrisdone/gd Excellent news! I submitted some patches to the maintainer a while back but never heard any response, positive or negative. My changes were a subset of what you have on github now. It's great to see it being cared for again! Cheers, D -- Dougal Stanton dou...@dougalstanton.net // http://www.dougalstanton.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bounded ranges
On Thu, 22 Jul 2010, Chad Scherrer wrote: Hello cafe, I'm trying to do some things with bounded indices so I can carry around arrays (well, Vectors, really) without needing to refer to the bounds. For example, if I know my indices are Bool values, I can do rangeSize (minBound, maxBound :: Bool) 2 I'd like to be able to do this in general, but... :t rangeSize (minBound, maxBound) interactive:1:11: Ambiguous type variable `a' in the constraints: `Bounded a' arising from a use of `minBound' at interactive:1:11-18 `Ix a' arising from a use of `rangeSize' at interactive:1:0-29 Probable fix: add a type signature that fixes these type variable(s) I thought it might help to put it into a module and do a better job with the type, like this: bdRangeSize :: (Ix i, Bounded i) = i - Int bdRangeSize _ = rangeSize (minBound, maxBound :: i) bdRangeSize x = rangeSize (minBound, maxBound `asTypeOf` x) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bounded ranges
On Friday 23 July 2010 00:21:49, Chad Scherrer wrote:
Hello cafe,
I'm trying to do some things with bounded indices so I can carry
around arrays (well, Vectors, really) without needing to refer to the
bounds.
For example, if I know my indices are Bool values, I can do
rangeSize (minBound, maxBound :: Bool)
2
I'd like to be able to do this in general, but...
:t rangeSize (minBound, maxBound)
interactive:1:11:
Ambiguous type variable `a' in the constraints:
`Bounded a'
arising from a use of `minBound' at interactive:1:11-18
`Ix a' arising from a use of `rangeSize' at interactive:1:0-29
Probable fix: add a type signature that fixes these type variable(s)
I thought it might help to put it into a module and do a better job
with the type, like this:
{-# LANGUAGE ScopedTypeVariables #-}
bdRangeSize :: forall i. (Ix i, Bounded i) = i - Int
bdRangeSize :: (Ix i, Bounded i) = i - Int
bdRangeSize _ = rangeSize (minBound, maxBound :: i)
or, H98, without ScopedTypeVariables and forall,
bdRangeSize x = rangeSize (minBound `asTypeOf` x, maxBound)
but I still have problems:
MyArray.hs:22:36:
Could not deduce (Bounded i1) from the context ()
arising from a use of `maxBound' at MyArray.hs:22:36-43
Possible fix:
add (Bounded i1) to the context of an expression type signature
In the expression: maxBound :: i
In the first argument of `rangeSize', namely
`(minBound, maxBound :: i)'
In the expression: rangeSize (minBound, maxBound :: i)
I thought maybe it's an existential types problem or something, but I
don't understand why it would be coming up here. Any thoughts?
Oh yes, and I'm using GHC version 6.12.1.
Thanks,
Chad
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: bounded ranges
On Thu, 22 Jul 2010, Chad Scherrer wrote: I thought it might help to put it into a module and do a better job with the type, like this: bdRangeSize :: (Ix i, Bounded i) = i - Int bdRangeSize _ = rangeSize (minBound, maxBound :: i) Henning Thielemann lemming at henning-thielemann.de writes: bdRangeSize x = rangeSize (minBound, maxBound `asTypeOf` x) Perfect, thank you! Chad ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bounded ranges
On Jul 23, 2010, at 12:21 AM, Chad Scherrer wrote:
bdRangeSize :: (Ix i, Bounded i) = i - Int
bdRangeSize _ = rangeSize (minBound, maxBound :: i)
Unlike intended, the `i` in the type annotation to `maxBound` is not
the same as the `i` in the signature of `bdRangeSize`. You need to
enable ScopedTypeVariables and explicitly quantify the type variable
`i` in order to refer to it in the annotation of `maxBound`:
{-# LANGUAGE ScopedTypeVariables #-}
import Data.Ix
bdRangeSize :: forall i . (Ix i, Bounded i) = i - Int
bdRangeSize _ = rangeSize (minBound, maxBound :: i)
Cheers,
Sebastian
--
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bounded ranges
On Thu, Jul 22, 2010 at 3:43 PM, Daniel Fischer
daniel.is.fisc...@web.de wrote:
{-# LANGUAGE ScopedTypeVariables #-}
bdRangeSize :: forall i. (Ix i, Bounded i) = i - Int
Ah nice, I tried a forall in that position, but I didn't know about
ScopedTypeVariables. Thanks!
Chad
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bounded ranges
An alternative to the `asTypeOf` idiom, which is also Haskell 98, is
to use a newtype instead of a dummy argument:
newtype RangeSize i = RangeSize { getRangeSize :: Int }
boundedRangeSize :: Ix i = (i,i) - RangeSize i
boundedRangeSize = RangeSize . rangeSize
bdRangeSize :: (Ix i, Bounded i) = RangeSize i
bdRangeSize = boundedRangeSize (minBound, maxBound)
Now you can call
ghci getRangeSize (bdRangeSize :: RangeSize Bool)
2
without language extensions and avoid the extra applications due to
the dummy argument and the `asTypeOf` call.
Sebastian
--
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Haskell Platform 2010.2.0.0
We're pleased to announce the fifth release of the Haskell Platform: a single, standard Haskell distribution for everyone. Download the Haskell Platform 2010.2.0.0: http://hackage.haskell.org.nyud.net/platform/ (Caching server). The specification, along with installers (including Windows, Apple and Unix installers for a full Haskell environment) are available. The Haskell Platform is a single, standard Haskell distribution for every system, in the form of a blessed library and tool suite for Haskell distilled from the thousands of libraries on Hackage, along with installers for a wide variety of systems. It saves developers work picking and choosing the best Haskell libraries and tools to use for a task. When you install the Haskell Platform, you get the latest stable compiler, an expanded set of core libraries, additional development tools, and cabal-install – so you can download anything else you need from Hackage. What you get is specified here: http://hackage.haskell.org/platform/contents.html Thanks! -- The Platform Infrastructure Team ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haskell Platform 2010.2.0.0
On Thu, Jul 22, 2010 at 9:00 PM, Don Stewart d...@galois.com wrote: We're pleased to announce the fifth release of the Haskell Platform: a single, standard Haskell distribution for everyone. That's just great, dons! Thanks a lot! Cheers, =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal, Setup.lhs example
Magnus Therning wrote: On Thu, Jul 22, 2010 at 11:52, Ross Paterson r...@soi.city.ac.uk wrote: On Thu, Jul 22, 2010 at 11:31:21AM +0100, Magnus Therning wrote: On Thu, Jul 22, 2010 at 10:59, Ross Paterson r...@soi.city.ac.uk wrote: Magnus is building by directly running the Setup.hs himself, which ignores the Build-Type. To get cabal-install to use his Setup.hs, the Build-Type must be set to Custom. Oh, why*2? Why is the header there if it's not used by Cabal, and why does cabal care? The field allows cabal to avoid compiling the Setup.hs in this case. It might also be used by other tools, e.g. one might only trust Simple packages. Not all fields are used by all tools, and several of them do not affect the operation of the library (e.g. Home-page). All right, so why would cabal want to avoid compiling the Setup.hs? Of course this behaviour of cabal's means that I in the future will use *Custom* all the time, since I otherwise have to remember this surprising feature of a tool I never use. Is there any reason *not* to do this? The main reason I could think of to avoid compiling it is for performance reasons. I'm not sure how compelling that is, but... As for why not to always use Custom, as mentioned there are cabal-aware tools out there besides cabal-install. For these other tools, there is a big difference between Simple and Custom. With Simple we (ideally) already know all the semantics of what Setup.hs does, and so we can wire that into our tools. With Custom we're forced into the position of doing Haskell source analysis since we now have to discover the semantics of an arbitrary Turing machine. That's a very high wall to climb if you're just wanting to write a simple tool for doing some kind of package analysis. (I don't think the behavior is surprising since I interpret Simple to mean that the Setup.hs file is unused/optional. Though clearly YMMV) -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Experiences with cabal-install and Hackage
On 23 July 2010 02:31, Daniel Fischer daniel.is.fisc...@web.de wrote: On Thursday 22 July 2010 18:23:32, Stephen Tetley wrote: Hiding unmaintained libraries seems contrary to Hackage's spirit - if you want to depend on an unmaintained library why not volunteer to be the maintainer. I think it was more meant to be fails to build and not updated for (= k months) == move to packages/notshiny Which doesn't help if the package doesn't build due to a missing C library, inconsistent dependencies (Hackage using two different versions of bytestring is a common problem I've come across), or is meant for a different (i.e. non-Linux) OS than the one Hackage is on. If it doesn't build and nobody seems to care about it anymore, why let it clutter the pkg-list, that's crowded enough even without zombies. Because it could be a package that builds if you install the correct C library first, and it hasn't been updated for k months because there's no need to. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On documentation
On 22 July 2010 18:33, David Waern david.wa...@gmail.com wrote: [snip] We currently only support concrete examples (i.e. unit tests), but the plan is to add support for QuickCheck properties. Would you have some kind of inbuilt time limit (similar to what mueval has) for very long/complex QC tests? I have some that take quite a while to run... David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal, Setup.lhs example
On Fri, Jul 23, 2010 at 12:33 PM, wren ng thornton w...@freegeek.org wrote: Magnus Therning wrote: On Thu, Jul 22, 2010 at 11:52, Ross Paterson r...@soi.city.ac.uk wrote: On Thu, Jul 22, 2010 at 11:31:21AM +0100, Magnus Therning wrote: On Thu, Jul 22, 2010 at 10:59, Ross Paterson r...@soi.city.ac.uk wrote: Magnus is building by directly running the Setup.hs himself, which ignores the Build-Type. To get cabal-install to use his Setup.hs, the Build-Type must be set to Custom. Oh, why*2? Why is the header there if it's not used by Cabal, and why does cabal care? The field allows cabal to avoid compiling the Setup.hs in this case. It might also be used by other tools, e.g. one might only trust Simple packages. Not all fields are used by all tools, and several of them do not affect the operation of the library (e.g. Home-page). All right, so why would cabal want to avoid compiling the Setup.hs? Of course this behaviour of cabal's means that I in the future will use *Custom* all the time, since I otherwise have to remember this surprising feature of a tool I never use. Is there any reason *not* to do this? The main reason I could think of to avoid compiling it is for performance reasons. I'm not sure how compelling that is, but... As for why not to always use Custom, as mentioned there are cabal-aware tools out there besides cabal-install. For these other tools, there is a big difference between Simple and Custom. With Simple we (ideally) already know all the semantics of what Setup.hs does, and so we can wire that into our tools. With Custom we're forced into the position of doing Haskell source analysis since we now have to discover the semantics of an arbitrary Turing machine. That's a very high wall to climb if you're just wanting to write a simple tool for doing some kind of package analysis. (I don't think the behavior is surprising since I interpret Simple to mean that the Setup.hs file is unused/optional. Though clearly YMMV) Ah, this clears up one of my bugs. Perhaps cabal should print a warning if you have a Setup.hs file, _and_ try to use Simple? It'd at least give the hint that they're unhappy together. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
