Re: [Haskell-cafe] The 8 Most Important GSoC Projects
Ivan Lazar Miljenovic wrote: I've been thinking of doing something similar for a year or so now, but there's one big problem that I can think of: how to deal with functions that don't have an explicit type signature in the source. My understanding is that to derive these signatures at "checking time" would require using something like the GHC API, which immediately reduces the "niceness" and portability of such a tool/library. As a simple approximation, you could consider functions without type signatures to have changed if their implementation or any function they depend on has changed. Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FRP, arrows and loops
Hello. I'm trying to understand the FRP (by implementing FRP system on my own) and I think I'm slowly getting it. 1. How to interpret ArrowLoop? I have two possible implementations: type RunSF a = a Dynamic () data SF a b c = SF (a (Dynamic, b, RunSF, Set Unique) (c, Set Unique, SF a b c)) (...) instance ArrowLoop (SF a) where loop (SF f) = loop' f undefined where loop' g d = proc (dyn, b, r, s) -> do ((c, d'), s, g') <- g <- (dyn, (b, d), r, s) returnA -< (c, s, loop' g' d') instance ArrowLoop a => ArrowLoop (SF a) where loop (SF f) = SF $! proc (d, b, r, s) -> do rec ((c, d), s, f') <- f -< (d, (b, d), r, s) returnA -< (c, s, loop f') Since the first is not unlike ArrayCircuit from arrays I guess second one but I'm not quite sure. 2. Why there is no ArrowIO in arrows? I.e. class Arrow a => ArrowIO a where liftAIO :: Kleisli IO b c -> a b c (possibly class Arrow a => ArrowST a where liftAST :: Kleisli ST b c -> a b c ) 3. Why switch is needed? How to interpret switch with current continuation? I think switch is equivalent to ArrowChoice but do I miss something? Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (no subject)
* * * * * * * More o BigCharts o Virtual Stock Exchange o FiLife.com o WSJ Asia o WSJ Europe o WSJ Portuguese o WSJ Spanish o WSJ Chinese o WSJ Japanese o WSJ Radio o Financial News SEARCH * Wednesday, March 31, 2010 Autos o Welcome, William Halchin Logout o + My Account + My Journal + Help + Message Center ( new) * U.S. Edition WSJ.com is available in the following editions and languages: o U.S. o Asia + India + China + Japan o Europe o Americas + en Español + em Português o Login/Register to set your edition o Set my edition o Today's Paper o Video o Columns o Blogs o Topics o Journal Community Register for FREE Register for FREE Thank you for registering. We sent an email to: Please click on the link inside the email to complete your registration Please register to gain free access to WSJ tools. An account already exists for the email address entered. Forgot your username or password? This service is temporary unavailable due to system maintenance. Please try again later. The username entered is already associated with another account. Please enter a different username The email address you have entered is already in use. Please re-enter the email address. o First Name o Last Name o Email (your email address will be your login) o Confirm Email o Create a Password o Confirm Password o Company Size (Optional) From time to time, we will send you e-mail announcements on new features and special offers from The Wall Street Journal Online. Create a profile for me in the Journal Community Why Register? Privacy Policy | Terms & Conditions As a registered user of The Wall Street Journal Online, you will be able to: o Setup and manage your portfolio o Personalize your own news page o Receive and manage newsletters Log In Log In Login Password Log in Your login is either a username or an email address. Keep me logged in. Forgot your password? close window Close * Home * World * U.S. * Business * Markets * Tech * Personal Finance * Life & Style * Opinion * Careers * Real Estate * Small Business * Asia * Europe * Earnings * Economy * Health * Law * Autos * Management * Media & Marketing * expand More Industries up down o Accounting o Advertising o Airlines o Banking o Chemicals o Computer Hardware o Computer Software o Consumer Products o Defense & Aerospace o Energy o Broadcasting & Entertainment o Financial Services & Insurance o Food & Tobacco o Hospitality o Industrial Goods & Services o Marketing & Strategy o Media Agencies o Metals & Mining o Paper & Forest Products o Pharmaceutical & Biotech o Real Estate o Retail o Semiconductors o Transportation o Utilities * Columns & Blogs * * Dow Jones Reprints: This copy is for your personal, non-commercial use only. To order presentation-ready copies for distribution to your colleagues, clients or customers, use the Order Reprints tool at the bottom of any article or visit www.djreprints.com See a sample reprint in PDF format. Order a reprint of this article now * The Wall Street Journal * MARCH 31, 2010 Now, Even NASA Is Involved in Toyota Crisis * Article * Comments (2) more in Auto Industry News » * Email * Print * Save This ↓ More * o facebook facebook o Twitter Twitter o Digg Digg o StumbleUpon StumbleUpon o + More close o Yahoo! Buzz o MySpace o del.icio.us o Reddit o LinkedIn o Fark o Viadeo o Orkut * larger Text smaller By BEN WORTHEN U.S. regulators on Tuesday announced a broad investigation into automotive computer systems and software, which have come under scrutiny because of su
Re: [Haskell-cafe] GSoC: Improving Cabal's Test Support
Jason Dagit writes: > What I don't understand is how it's possible for the discrepancy to happen. > It's as if ./Setup and cabal-install use different algorithms for > dependency resolution, but as I understand it, both should be using the > Cabal library for that. My only other thought is that perhaps ./Setup uses > a different version of the Cabal library than what cabal-install uses. My understanding is that Setup.hs will use whatever libraries you already have installed; cabal-install will use the latest allowable version of libraries. -- 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] Haskell.org re-design
On Fri, Apr 2, 2010 at 4:36 AM, Ben Millwood wrote: > The > easiest thing to do on visiting the website is read about why Haskell > is so great, and where to find out how to use it. > Uhm, I meant the easiest thing *should be* reading about... Sorry about that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC: Improving Cabal's Test Support
On Thu, Apr 1, 2010 at 6:13 PM, Rogan Creswick wrote: > On Thu, Apr 1, 2010 at 3:52 PM, Thomas Tuegel wrote: > > > > At this point, the package author need only run: > > > > $ ./Setup configure > > $ ./Setup build > > $ ./Setup test > > My general feeling has been that Setup is being discouraged in favor > of using 'cabal ', but I don't have any solid evidence for that > (and I could very well be wrong!). They do do slightly different > things, so I think it's wise to figure out which idiom is most likely > to be used and work with that. > I haven't figured out how it's possible, but I'm convinced that ./Setup configure vs. cabal configure can lead to a different set of dependencies being selected. This can lead to diamond dependency problems. (I'm convinced this happen on at least one machine I know of.) What I don't understand is how it's possible for the discrepancy to happen. It's as if ./Setup and cabal-install use different algorithms for dependency resolution, but as I understand it, both should be using the Cabal library for that. My only other thought is that perhaps ./Setup uses a different version of the Cabal library than what cabal-install uses. Perhaps Duncan can comment on this. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org re-design
On Fri, Apr 2, 2010 at 12:40 AM, Christopher Done wrote: > That's true, it's a nice idea but in practice it's hard to know where > to focus. I've gone with a left nav. I've built up the HTML which is > cross-browser (ie6/7/8/opera/firefox/safari/chrome compat), still need > to add some bits but I can tomorrow import it into a wikimedia skin. > It's kind of easy to re-shuffle now that I've built it. > > http://82.33.137.16/haskell-website/ > > Feedback would be appreciated. There isn't a lot of visual separation between the nav bar and the main content. I think a border or background colour change might be nice. Also, when I let my firefox window fill the screen there's whitespace on the left and right, when I share my screen with another window the site doesn't fit horizontally - it doesn't adjust well to changing window widths. Also, in the nav bar it should be clearer when an item is linewrapping and when it is next in the list - on the left it looks like we have * The Haskell Platform * Glasgow Haskell * Compiler * ... so, bullet points or adjusted vertical spacing might help there. Also still quite grey. But I do like the focus on current events - the first impression you get visiting that page is that Haskell is alive and well, and people are using and developing it right now. The pictures of Real People smiling and huddling together really do help the friendly image we've managed to acquire (and should guard with utmost vigil, in my opinion). I think that the About and Learning sections of the original website are good section titles, and would work well on the navbar. The easiest thing to do on visiting the website is read about why Haskell is so great, and where to find out how to use it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org re-design
Christopher Done wrote: That's true, it's a nice idea but in practice it's hard to know where to focus. I've gone with a left nav. I've built up the HTML which is cross-browser (ie6/7/8/opera/firefox/safari/chrome compat), still need to add some bits but I can tomorrow import it into a wikimedia skin. It's kind of easy to re-shuffle now that I've built it. http://82.33.137.16/haskell-website/ Feedback would be appreciated. One has to think, what do I really want to see on the home page? Two important things I am missing are: * A link to the documentation. Perhaps as a button in the top row. * A link to tutorial(s) / Real World Haskell. Besides the download button, these are the important things that new users look for when they land on the home page. This design looks too much like the Haskell Community homepage, not the Haskell Programming Language home page. Some more things: * I think that the links on the left are confusing and unnecessary, since there is already a menu at the top. * Why would there be a 'links' page? All links fall either under 'community' or 'news' or 'download'. * Perhaps have a tab named 'events', and put all the event stuff there? * (minor) the buttons on the top row have a dent at the top (in Firefox 3.6 on windows) Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] replicateM over vectors
On 02/04/2010, at 13:01, Don Stewart wrote: > rl: >> replicate :: Int -> a -> New a >> replicate n x = Generic.New.unstream (Fusion.Stream.replicate n x) >> >> and then either >> >> Mutable.run (replicate n x) >> >> to get a mutable vector or >> >> new (replicate n x) > > > Hmm, but here 'a' is pure. I don't think he wants > >newWith :: (PrimMonad m, MVector v a) => Int -> a -> m (v (PrimState m) a) > > but more: > >newWithM :: (PrimMonad m, MVector v a) => Int -> m a -> m (v (PrimState m) > a) Ah. I missed that. Then your best bet is probably replicate n action = munstream v $ Fusion.Stream.Monadic.generateM n (const action) $ new n It's uglier that it should be but vector simply doesn't define the right combinators for this at the moment. >> to get an immutable one. You could also chain operations on New, including >> monadic ones: >> >> v <- Mutable.run $ Generic.New.transform (Fusion.Stream.Monadic.mapM f) >> $ replicate n x >> > > Oh, that's interesting. But what if we want to fill directly with the monadic > action? > We wouldn't > >mapM (const a) $ replicate n undefined > > So how do we best do a fusible, e.g.: > >replicateM :: G.Vector v a => Int -> IO a -> IO (v a) There are two things one would have to do. First, add a function to Generic.New which initialises a New from a Monadic.Stream and fusion rules for it. That's easy. The hard part is to generalise New to work with arbitrary monads: at the moment it is defined as: data New a = New (forall mv s. MVector mv a => ST s (mv s a)) This is because its basic reason for existence is to be passed to Vector.new which then does a runST to produce an immutable vector. It is perhaps possible to make New more general but it's quite tricky. I'll think about it after the ICFP deadline :-) Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
On Thu, Apr 1, 2010 at 7:10 PM, Ivan Lazar Miljenovic < ivan.miljeno...@gmail.com> wrote: > Don Stewart writes: > > Portability? You already have GHC on the machine, right? You don't > > necessarily need the GHC API to get something prototyped quickly. > > I meant in the sense of writing this as a tool, which will also work if > the user prefers JHC, YHC, etc. over GHC. > I would suggest in that case that JHC/YHC et al implement sufficient features to support the PVP tool :) Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
Don Stewart writes: > Portability? You already have GHC on the machine, right? You don't > necessarily need the GHC API to get something prototyped quickly. I meant in the sense of writing this as a tool, which will also work if the user prefers JHC, YHC, etc. over GHC. -- 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] The 8 Most Important GSoC Projects
ivan.miljenovic: > Don Stewart writes: > > Well, you can 'script' GHC: > > [snip] > > > To at least get the fully qualified types exported from a module. > > Which increases the portability _how_ precisely? :p > Portability? You already have GHC on the machine, right? You don't necessarily need the GHC API to get something prototyped quickly. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] replicateM over vectors
rl: > replicate :: Int -> a -> New a > replicate n x = Generic.New.unstream (Fusion.Stream.replicate n x) > > and then either > > Mutable.run (replicate n x) > > to get a mutable vector or > > new (replicate n x) Hmm, but here 'a' is pure. I don't think he wants newWith :: (PrimMonad m, MVector v a) => Int -> a -> m (v (PrimState m) a) but more: newWithM :: (PrimMonad m, MVector v a) => Int -> m a -> m (v (PrimState m) a) > to get an immutable one. You could also chain operations on New, including > monadic ones: > > v <- Mutable.run $ Generic.New.transform (Fusion.Stream.Monadic.mapM f) >$ replicate n x > Oh, that's interesting. But what if we want to fill directly with the monadic action? We wouldn't mapM (const a) $ replicate n undefined So how do we best do a fusible, e.g.: replicateM :: G.Vector v a => Int -> IO a -> IO (v a) -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
Don Stewart writes: > Well, you can 'script' GHC: [snip] > To at least get the fully qualified types exported from a module. Which increases the portability _how_ precisely? :p -- 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] The 8 Most Important GSoC Projects
ivan.miljenovic: > Stephen Tetley writes: > > I had a little experiment along the lines of "A Package Versioning > > Policy Checker" a few months ago. I got as far as using > > Haskell-src-exts to extract module export list, but didn't work out > > out a hashing scheme for the actual type signatures. > > I've been thinking of doing something similar for a year or so now, but > there's one big problem that I can think of: how to deal with functions > that don't have an explicit type signature in the source. My > understanding is that to derive these signatures at "checking time" > would require using something like the GHC API, which immediately > reduces the "niceness" and portability of such a tool/library. Well, you can 'script' GHC: $ ghc -ddump-types A.hs -fno-code TYPE SIGNATURES replicateM :: forall (v :: * -> *) a. (G.Vector v a) => Int -> IO a -> IO (v a) replicateS :: forall a (m :: * -> *) (v :: * -> * -> *). (Control.Monad.Primitive.PrimMonad m, M.MVector v a) => Int -> a -> m (v (Control.Monad.Primitive.PrimState m) a) To at least get the fully qualified types exported from a module. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] replicateM over vectors
On 02/04/2010, at 12:16, Don Stewart wrote: > Chad.Scherrer: >> Hi, >> >> I'd like to be able to do replicateM, but over a vector instead of a list. >> Right now I'm doing this: The operation you are looking for is called newWith. It probably should be called replicate. > Roman? Can we generate frozen arrays for monadic generators, and still fuse in > the current New/Mutable/MStream architecture? For monadic stuff, fusion happens on things of type New. For instance, you could write this (I'm omitting the class contexts and Data.Vector prefixes): replicate :: Int -> a -> New a replicate n x = Generic.New.unstream (Fusion.Stream.replicate n x) and then either Mutable.run (replicate n x) to get a mutable vector or new (replicate n x) to get an immutable one. You could also chain operations on New, including monadic ones: v <- Mutable.run $ Generic.New.transform (Fusion.Stream.Monadic.mapM f) $ replicate n x and this ought to fuse. Note that the New stuff is quite rough and only really intended for internal use at the moment. I wanted to get the "normal" APIs working properly first. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
Stephen Tetley writes: > I had a little experiment along the lines of "A Package Versioning > Policy Checker" a few months ago. I got as far as using > Haskell-src-exts to extract module export list, but didn't work out > out a hashing scheme for the actual type signatures. I've been thinking of doing something similar for a year or so now, but there's one big problem that I can think of: how to deal with functions that don't have an explicit type signature in the source. My understanding is that to derive these signatures at "checking time" would require using something like the GHC API, which immediately reduces the "niceness" and portability of such a tool/library. -- 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] GSoC: Improving Cabal's Test Support
Thomas Tuegel writes: > There have been two separate suggestions (of which I am aware) of ways > to integrate tests into Cabal. One is to build the tests into their > own executable which uses an error code on exit to indicate test > failure. I personally prefer this suggestion: for my graphviz library at least, I define at least one QuickCheck property that I cannot as yet actually use (as my Arbitrary instances aren't guaranteed to produce valid Dot code, so I can't run the test that attempts to pass a value through to dot/neato). > I propose to build a test suite as its own executable, but to avoid > the problem of granularity by producing an output file detailing the > success or failure of individual tests and any relevant error > messages. The format of the file would be standardized through > library routines I propose to write; these routines would run tests > with HUnit or QuickCheck and process them into a common format. > Cabal, or any other utility, could read this file to determine the > state of the test suite. Perhaps Cabal could even warn the user about > installing packages with failing tests. All well and good, but your sample code (which I've ommitted for the sake of brevity) doesn't seem to lead to much room for customisation: for graphviz's test suite, I include various comments about the purpose of the test, etc. as well as changing some of QuickCheck's paramaters; does your proposal allow the inclusion of such customisations? As an aside, I question the necessity of this kind of proposal: how many people actually run tests for packages they download from Hackage? graphviz's test suite runs for 110 minutes, and I mainly use it to test that my changes/inclusions in what it prints and parses is consistent: I don't expect a user to bother running it (and would question why anyone would). How does the inclusion of a "test" option to Cabal allow any substantial benefits to developers over building the package with a build-time flag to enable building a test suite? -- 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] replicateM over vectors
Chad.Scherrer:
> Hi,
>
> I'd like to be able to do replicateM, but over a vector instead of a list.
> Right now I'm doing this:
>
> import qualified Data.Vector.Generic as G
> import qualified Data.Vector.Unboxed.Mutable as M
> replicateM n action = do
> mu <- M.unsafeNew n
> let go !i | i < n = action >>= M.unsafeWrite mu i >> go (i+1)
> | otherwise = G.unsafeFreeze mu
> go 0
>
> I thought it might be useful to express this in terms of the available
> primitives, since this might fuse more easily, but I don't yet see a
> way to do it.
>
> Is there a better (more elegant and/or faster) way to write this?
>
The way you're writing it is fine and direct, but yes, I think the
challenge is to have have monadic generators that will fuse.
The direct style, I'd write as:
import qualified Data.Vector.Generic as G
import qualified Data.Vector.Generic.Mutable as M
import qualified Data.Vector.Generic.New as N
import qualified Data.Vector.Fusion.Stream.Monadic as S
replicateM :: (G.Vector v a) => Int -> IO a -> IO (v a)
replicateM n a = do
v <- M.new n
fill v 0
G.unsafeFreeze v
where
fill v i
| i < n = do
x <- a
M.unsafeWrite v i x
fill v (i+1)
| otherwise = return ()
But that doesn't fuse, obviously. So it seems we should be able to do something
like:
-- Almost there:
replicateS n a = {-unsafeFreeze-} (M.unstream (S.replicate n a))
Or use Data.Vector.Generic.New, but I couldn't get the monadic action to work
out, ending up in a twisty maze of PrimMonads.
Roman? Can we generate frozen arrays for monadic generators, and still fuse in
the current New/Mutable/MStream architecture?
-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC: Improving Cabal's Test Support
On Thu, Apr 1, 2010 at 3:52 PM, Thomas Tuegel wrote:
>
> I propose to build a test suite as its own executable, but to avoid
> the problem of granularity by producing an output file detailing the
> success or failure of individual tests and any relevant error
> messages. The format of the file would be standardized through
> library routines I propose to write; these routines would run tests
> with HUnit or QuickCheck and process them into a common format.
> Cabal, or any other utility, could read this file to determine the
> state of the test suite. Perhaps Cabal could even warn the user about
> installing packages with failing tests.
There are a few frameworks that provide limited degrees of this
functionality. I've recently added to test-framework so that the
results can be gathered into an xml format that complies with at least
some (maybe all?) junit xml parsers.
I specifically targeted junit xml so it would be easy to use existing
continuous integration systems as-is, but the format is not for
haskell tests. It would be nice, for example, to see how many
successful quickcheck inputs were run; and the concept of packages and
classes had to be munged to work with Haskell modules and test
groupings.
I need to clean up the code and get it over to Max for review before
it'll be widely available, but that's just a matter of finding the
time (possibly next week).
>> module Main where
>>
>> import Foo
>> import Test.QuickCheck
>> import Distribution.Test -- This module is part of the project I propose
>>
>> main = runTests
>> [ ("testBar", wrap $ testBar), ("testBaz", wrap $ testBaz) ] -- (name,
>> test)
>
> 'runTests' and 'wrap' would be provided by 'Distribution.Test'.
> 'wrap' would standardize the output of test routines. For QuickCheck
> tests, it would probably look like:
This is very similar to what test-framework (and other libs.) are
doing -- it's well worth looking into them.
>> wrap :: Testable a => a -> IO (Bool, String)
>
> where the Bool indicates success and the String can be an error
> message the test produced. 'runTests' would take the list of tests,
> format their results, and write the output to a file:
Keep in mind that there are at least two ways a test can fail --
through errors or false assertions, and it's useful to distinguish
between those. As indicated above, I think this bit of the problem
has been largely solved -- at the least, there has been a lot of work
on designing test frameworks for most languages, and we should be able
to take advantage of that here.
> The test suite would be included in the package description file with
> a stanza such as:
>
>> Test
>> main-is: Test.hs
>> build-depends: foo, QuickCheck, Cabal
I've been thinking about this as well, and I like this general idea,
but I'm not (yet) convinced it's the best. That's probably just
because I'm cautious though :)
> This would take all the same options as an 'Executable' stanza, but
> would tell Cabal to run this executable when './Setup test' is
> invoked. This of course requires Cabal to support building
> executables that depend on the library in the same package. Since
> version 1.8, Cabal supposedly supports this, but my experiments
> indicate the support is a little broken. (GHC is invoked with the
> '-package-id' option, but Cabal only gives it the package name.
> Fixing this would naturally be on the agenda for this project.)
>
> At this point, the package author need only run:
>
> $ ./Setup configure
> $ ./Setup build
> $ ./Setup test
My general feeling has been that Setup is being discouraged in favor
of using 'cabal ', but I don't have any solid evidence for that
(and I could very well be wrong!). They do do slightly different
things, so I think it's wise to figure out which idiom is most likely
to be used and work with that.
--Rogan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org re-design
On 31 March 2010 12:01, Johan Tibell wrote: > - There are several news streams going on at once. Perhaps "Headlines" > and "Events" could be merged into one stream. After watching the > Hackage RSS feed every day I don't know if it's interesting enough to > put on a front page. Perhaps in a side bar which brings me to my next > suggestions. > > - Multi column pages are tricky to scan! It works well in news papers > since the page height is limited but for web pages I really prefer one > main column. Perhaps the second column code be made more narrow? > Perhaps the footer content could be promoted into this second column > and have it be a more conventional right (or left) hand nav? > That's true, it's a nice idea but in practice it's hard to know where to focus. I've gone with a left nav. I've built up the HTML which is cross-browser (ie6/7/8/opera/firefox/safari/chrome compat), still need to add some bits but I can tomorrow import it into a wikimedia skin. It's kind of easy to re-shuffle now that I've built it. http://82.33.137.16/haskell-website/ Feedback would be appreciated. One has to think, what do I really want to see on the home page? Personally, I want to see latest events and news, that's what I look for on the current page. I'd also like to stick The Big Download Button on there and a small embedded TryHaskell, maybe with random runnable code samples. Similar to the code sample on http://ruby-lang.org/ but something you can actually try in the browser. And yes, by the way, I'm taking inspiration from Ruby's site, Python's site and Ubuntu's wiki page, and I'd forgotten about Scala so I'm looking at their site for ideas, too. > - The quick links seem a bit random where they now appear. :) Ha, yes! I popped them on last minute. I'm not entirely sure if there is a standard place for social networking icons to go. I'll have to see about that. There are lots of places the icons could go quite neatly. I was also thinking, I am told by my designer friends, that long pages are coming back, so I think we could afford another couple sections on there. Plus, I can optimise the page's download time by gzipping the HTML and caching the gzip binary result, outputting that, and refreshing that cache when the HomePage page is changed (actually Wikimedia probably already supports caching somewhat, though it is an old version, I'll have to see). Cheers! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GSoC: Improving Cabal's Test Support
Hello community!
I've been working on a proposal for Google Summer of Code 2010 to work
on improving Cabal's test support, as described on the Haskell SoC
Trac [1]. Today I'm looking for feedback to see if what I intend is
what people want/need. As you read this, I kindly ask that you
consider: 1) Would you use the facility I describe, were it available?
and 2) What additional features would you like to see?
There have been two separate suggestions (of which I am aware) of ways
to integrate tests into Cabal. One is to build the tests into their
own executable which uses an error code on exit to indicate test
failure. The second is to have package authors write modules which
Cabal will load (dynamically?) and run the tests from. The former
method has the advantage of being simpler to implement, but is
probably too granular. Although the second suggestion avoids some
security concerns, it seems to me that a malicious party could simply
put nefarious code into their Setup.hs file anyway, or even in the
library being tested.
I propose to build a test suite as its own executable, but to avoid
the problem of granularity by producing an output file detailing the
success or failure of individual tests and any relevant error
messages. The format of the file would be standardized through
library routines I propose to write; these routines would run tests
with HUnit or QuickCheck and process them into a common format.
Cabal, or any other utility, could read this file to determine the
state of the test suite. Perhaps Cabal could even warn the user about
installing packages with failing tests.
Under this proposal, a test suite would look something like this
(suppose I am writing a test suite for a module Foo, which has an
existing test suite in QuickCheck):
> module Main where
>
> import Foo
> import Test.QuickCheck
> import Distribution.Test -- This module is part of the project I propose
>
> main = runTests
> [ ("testBar", wrap $ testBar), ("testBaz", wrap $ testBaz) ] -- (name, test)
'runTests' and 'wrap' would be provided by 'Distribution.Test'.
'wrap' would standardize the output of test routines. For QuickCheck
tests, it would probably look like:
> wrap :: Testable a => a -> IO (Bool, String)
where the Bool indicates success and the String can be an error
message the test produced. 'runTests' would take the list of tests,
format their results, and write the output to a file:
> runTests :: [(String, IO (Bool, String))] -> IO ()
I would probably gather the test results into a value of type
'[(String, Bool, String)]' -- the name, status, and messages
associated with each test -- and use 'show' to produce a nice,
human-readable, machine-parsable file.
The test suite would be included in the package description file with
a stanza such as:
> Test
> main-is: Test.hs
> build-depends: foo, QuickCheck, Cabal
This would take all the same options as an 'Executable' stanza, but
would tell Cabal to run this executable when './Setup test' is
invoked. This of course requires Cabal to support building
executables that depend on the library in the same package. Since
version 1.8, Cabal supposedly supports this, but my experiments
indicate the support is a little broken. (GHC is invoked with the
'-package-id' option, but Cabal only gives it the package name.
Fixing this would naturally be on the agenda for this project.)
At this point, the package author need only run:
$ ./Setup configure
$ ./Setup build
$ ./Setup test
to produce a file detailing the results of the test suite.
I apologize for taking up your time with a such a lengthy message, and
eagerly await your feedback!
Thanks!
--
Thomas Tuegel
[1] http://hackage.haskell.org/trac/summer-of-code/ticket/1581
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSOC Haskell Project
Then I will apply to it. Thanks for this opportunity. I will get into a documentation period for the next days and will come back with a full application. -- Mihai On Thu, Apr 1, 2010 at 11:53 PM, Simon Marlow wrote: > On 01/04/10 21:41, Max Bolingbroke wrote: >> >> On 1 April 2010 18:58, Thomas Schilling wrote: >>> >>> On 1 Apr 2010, at 18:39, Mihai Maruseac wrote: >>> Hmm, interesting. If I intend to give it a try, will there be a mentor for a GSOC project? Or should I start doing it alone? >>> >>> I'm sure Simon Marlow could mentor you except maybe if there are too many >>> GHC-related GSoC projects. I could do mentor this as well. Or maybe Max. >>> I don't think finding a mentor will be a problem. >> >> I'm not the best person to mentor this project - I did bring it up in >> the hope that someone would find it tempting as a GSoC project, though >> :-). I think it's eminently practical to get this done in a summer (or >> less), and it would ameliorate one of Haskell's more embarrassing >> problems. > > I'd be happy to mentor this project. > > Cheers, > Simon > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] replicateM over vectors
Hi, I'd like to be able to do replicateM, but over a vector instead of a list. Right now I'm doing this: import qualified Data.Vector.Generic as G import qualified Data.Vector.Unboxed.Mutable as M replicateM n action = do mu <- M.unsafeNew n let go !i | i < n = action >>= M.unsafeWrite mu i >> go (i+1) | otherwise = G.unsafeFreeze mu go 0 I thought it might be useful to express this in terms of the available primitives, since this might fuse more easily, but I don't yet see a way to do it. Is there a better (more elegant and/or faster) way to write this? Thanks, Chad ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
Hello All I had a little experiment along the lines of "A Package Versioning Policy Checker" a few months ago. I got as far as using Haskell-src-exts to extract module export list, but didn't work out out a hashing scheme for the actual type signatures. The project is minimal, but it does have code to reconcile module paths from a Cabal file using the Distribution library (which was more work than I imagined). It might make a reasonable starting point if someone wants to pick it up - afraid I'm not a student nor could I commit to being a mentor. http://copperbox.googlecode.com/files/precis-0.1.0.tar.gz Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Immix GC as a Soc proposal
In my opinion the project would be worthwhile even if it's not in the Top 8. Mentors vote on the accepted projects based both on the priority of the project and the applying student, so it's probably not a bad idea to apply for other projects as well so you don't put all your stakes on just a single horse. Looking at your current proposal, however, I think that your timeline is, well, impossible. You seem to suggest to build a new allocator and garbage collector from scratch. GHC's allocator is already quite similar to Immix, so you don't really have to re-implement much. The main differences (OTTOH) are the different region sizes, the marking accuracy (Immix marks 128 byte blocks, GHC is word-accurate), and eager compaction. Therefore I'd suggest to move in small steps: Change some parameters (e.g., region size), fix the resulting bugs and benchmark each change. Then, maybe, implement eager compaction on top of the existing system. I believe this will keep you busy enough. If in the end GC is 5% faster that would be a very good outcome! I also don't know how much complexity the parallel GC and other synchronisation stuff will introduce. Maybe Simon (CC'd) can comment on that. / Thomas On 1 April 2010 22:00, Marco Túlio Gontijo e Silva wrote: > Hi. > > I've written a Google Summer of Code proposal for implementing the Immix > Garbage Collector in GHC[0]. It's not on dons list of the 8 most important > projects[1], but I only saw that list after the proposal is done. I'd like to > hear comments about it, specially about its relevance, since it's not on the > list of 8. > > 0: http://www2.dcc.ufmg.br/laboratorios/llp/wiki/doku.php?do=show&id=marco_soc > 1: > http://donsbot.wordpress.com/2010/04/01/the-8-most-important-haskell-org-gsoc-projects/ > > I'm planning to write another proposal, maybe about "LLVM Performance Study", > "LLVM Cross Compiler", "A Package Versioning Policy Checker" or "“cabal > test”", if mentors think they're more relevant than my current proposal. > Please let me know if this is the case. > > Greetings. > -- > marcot > http://wiki.debian.org/MarcoSilva > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Immix GC as a Soc proposal
Hi. I've written a Google Summer of Code proposal for implementing the Immix Garbage Collector in GHC[0]. It's not on dons list of the 8 most important projects[1], but I only saw that list after the proposal is done. I'd like to hear comments about it, specially about its relevance, since it's not on the list of 8. 0: http://www2.dcc.ufmg.br/laboratorios/llp/wiki/doku.php?do=show&id=marco_soc 1: http://donsbot.wordpress.com/2010/04/01/the-8-most-important-haskell-org-gsoc-projects/ I'm planning to write another proposal, maybe about "LLVM Performance Study", "LLVM Cross Compiler", "A Package Versioning Policy Checker" or "“cabal test”", if mentors think they're more relevant than my current proposal. Please let me know if this is the case. Greetings. -- marcot http://wiki.debian.org/MarcoSilva ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSOC Haskell Project
On 01/04/10 21:41, Max Bolingbroke wrote: On 1 April 2010 18:58, Thomas Schilling wrote: On 1 Apr 2010, at 18:39, Mihai Maruseac wrote: Hmm, interesting. If I intend to give it a try, will there be a mentor for a GSOC project? Or should I start doing it alone? I'm sure Simon Marlow could mentor you except maybe if there are too many GHC-related GSoC projects. I could do mentor this as well. Or maybe Max. I don't think finding a mentor will be a problem. I'm not the best person to mentor this project - I did bring it up in the hope that someone would find it tempting as a GSoC project, though :-). I think it's eminently practical to get this done in a summer (or less), and it would ameliorate one of Haskell's more embarrassing problems. I'd be happy to mentor this project. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Announce: hothasktags
Hi, I'd like to draw attention to a little script I wrote. I tend to use qualified imports and short names like "new" and "filter". This makes hasktags pretty much useless, since it basically just guesses which one to go to. hothasktags is a reimplementation of hasktags that uses haskell-src-exts to analyze the import structure to generate (scoped) tags pointing to the right definition. I'm pretty addicted to it, since it provides the only functionality I miss from visual studio :-). VIm only for now, since I don't know if emacs tags format supports scoped tags. I am aware that it is not perfect -- patches and bug reports welcome. http://hackage.haskell.org/package/hothasktags Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSOC Haskell Project
On 1 April 2010 18:58, Thomas Schilling wrote: > > On 1 Apr 2010, at 18:39, Mihai Maruseac wrote: > >> Hmm, interesting. If I intend to give it a try, will there be a mentor >> for a GSOC project? Or should I start doing it alone? > > I'm sure Simon Marlow could mentor you except maybe if there are too many > GHC-related GSoC projects. I could do mentor this as well. Or maybe Max. I > don't think finding a mentor will be a problem. I'm not the best person to mentor this project - I did bring it up in the hope that someone would find it tempting as a GSoC project, though :-). I think it's eminently practical to get this done in a summer (or less), and it would ameliorate one of Haskell's more embarrassing problems. Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: New wxHaskell
I've uploaded a new wx-suite, wxdirect-0.12.1.3, wxcore-0.12.1.4, wx-0.12.1.4, wx now builds with ghc-6.10 and ghc-6.12, sorry for breaking 6.10 earlier. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OT: the format checker for ICFP 2010 papers, help!
I just thought I'd pass on Stephanie's response, as she couldn't post to the list: > It looks like the SIGPLAN class file has gotten out of sync with the paper requirements and > is producing a slightly too large textblock. I just checked the template (filled out with random text) > against the format checker. It fails. > > In this situation, it seems wisest to go with the class file instead of the stated height requirement. > I've upped the format checker to a max 9.5in height to account for this discrepancy. Hope this helps, Wouter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The 8 Most Important GSoC Projects
While at ZuriHac, a few of us GSoC mentors got together to discuss what we think the most important student projects for the summer should be. Here's the list: http://donsbot.wordpress.com/2010/04/01/the-8-most-important-haskell-org-gsoc-projects/ Please consider applying to work on these tasks! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: spec2code
After 5 years of R&D, I’m proud to announce the spec2code compiler. With spec2code, developers no longer need to acknowledge the mundane details of programming, such as memory allocation, bounds-checking, byte ordering, inheritance models or performance tuning. spec2code uses the latest techniques in compiler optimization to derive a deterministic implementation from only a high-level specification. For example, an optimal quicksort is derived from the following specification. sort :: Ord a => [a] -> (b | ordered b) sort = undefined ordered :: Ord a => [a] -> Bool ordered [] = True ordered [_] = True ordered (x1:x2:xs) = x2 > x1 && ordered (x2:xs) Read as, “the function 'sort' takes a list of orderable list items, and returns a list for which each list item is greater to the one preceding it.” How does it work? By telling the compiler about the logical properties of how its output relates to its input, the compiler is sufficiently constrained to apply its genetic algorithm. It iterates over the specification with all known optimization techniques, algebraically reducing the program to an underlying machine model. The compiler uses static analysis and complexity theory in conjunction with the machine model to order implementations by their performance characteristics and choose the optimal one. Conceptually, the first phase orders algorithms by complexity, using "average case", "worst case" and "memory consumption": [MergeSort (n*log n) (n*log n) n, QuickSort (n*log n) (n*n) (log n), InsertionSort (n*n) (n*n) 1, BubbleSort (n*n) (n*n) 1 ] After choosing a high-level algorithm, spec2code does the usual low-level optimizations via LLVM to map the algorithm to optimal native code. Does it scale? Absolutely, spec2code is not confined to specifications for which optimized algorithms are already known. spec2code can be used to implement operation systems, device drivers, build systems, package management tools, and even do your shirt laundry. spec2code will change your job from programmer to specification author, giving you more time for meetings, managing email, and browsing the web. Say goodbye to those dirty Perl scripts, broken C code, and ultimately, your job. spec2code is the future of programming and the beginning of the end of mankind. Looking forward to obsoleting you soon, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSOC Haskell Project
On 1 Apr 2010, at 18:39, Mihai Maruseac wrote: > Hmm, interesting. If I intend to give it a try, will there be a mentor > for a GSOC project? Or should I start doing it alone? I'm sure Simon Marlow could mentor you except maybe if there are too many GHC-related GSoC projects. I could do mentor this as well. Or maybe Max. I don't think finding a mentor will be a problem. GHC's runtime stack actually uses the same data layout for both stack and heap objects, so you might be able to extend unpackClosure# to build something like Vacuum[1] (or extend it). [1]: http://moonpatio.com/vacuum/ > > On Thu, Apr 1, 2010 at 8:37 PM, Max Bolingbroke > wrote: >> I still believe that it would much simpler to get some stack traces >> out of GHC by just reporting what chain of thunks we are currently >> forcing when we get an error. This just requires a way of reifying the >> existing STG stack in some user-readable way. >> >> What it doesn't give you is lexical call stacks of any form, but many >> people have pursued that goal and failed. The STG stack only tells you >> the "dynamic" call stack, and will omit any frames removed due to e.g. >> tail recursion optimisation, but at least it gives you *some* >> information about where your "head []" error is coming from! >> >> For those interested, there is more discussion of the idea at >> http://hackage.haskell.org/trac/ghc/ticket/3693 >> >> Cheers, >> Max >> >> On 1 April 2010 18:22, Thomas Schilling wrote: >>> The DrScheme debugger shows backtraces as arrows in the source code. >>> It took some getting used to, but it doesn't seem like a bad idea. I >>> believe Leksah has some sort of graphical frontend for the GHCi >>> debugger, but I haven't tried it out myself yet. Maybe you can build >>> on top of that. >>> >>> Stack traces are rather difficult to implement. Tristan Allwood >>> implemented stack trace support as a GHC Core plugin (see his 2009 >>> Haskell Symposium paper) but it required quite a lot of recompilation. >>> His stack traces also didn't record any values, just source >>> locations. He also had some problems with the way mutually recursive >>> functions with type classes were desugared and, as so often, CAFs >>> (constant applicative forms). >>> So if you propose to work on that you should have a good idea how to >>> overcome such issues it in your application. >>> >>> Another problem with stack traces turned on is that they may lead to >>> space leaks. I don't know how big of an issue this is in practise, >>> but I'm pretty sure you can't just keep them turned on all the time. >>> The GHCi debugger has a tracing mode that can be turned on explicitly >>> and allows you to "go back in time" if you hit a break point or error. >>> I believe a good front-end could make this a much more widely used >>> feature. >>> >>> On 1 April 2010 17:39, Mihai Maruseac wrote: So, should I change the topic of the project to stack traces instead of visual GUI representation? If this were the case, I will have to find a way to represent those traces in a way that even a beginner can read and understand (my GUI approach was for the beginners). -- Mihai Maruseac On Wed, Mar 31, 2010 at 6:40 PM, Jason Dagit wrote: > > > On Wed, Mar 31, 2010 at 7:21 AM, Simon Marlow wrote: >> >> On 30/03/2010 20:57, Mihai Maruseac wrote: >> >>> I'd like to introduce my idea for the Haskell GSOC of this year. In >>> fact, you already know about it, since I've talked about it here on >>> the haskell-cafe, on my blog and on reddit (even on #haskell one day). >>> >>> Basically, what I'm trying to do is a new debugger for Haskell, one >>> that would be very intuitive for beginners, a graphical one. I've >>> given some examples and more details on my blog [0], [1], also linked >>> on reditt and other places. >>> >>> This is not the application, I'm posting this only to receive some >>> kind of feedback before writing it. I know that it seems to be a >>> little too ambitious but I do think that I can divide the work into >>> sessions and finish what I'll start this summer during the next year >>> and following. >>> >>> [0]: http://pgraycode.wordpress.com/2010/03/20/haskell-project-idea/ >>> [1]: >>> http://pgraycode.wordpress.com/2010/03/24/visual-haskell-debugger-part-2/ >>> >>> Thanks for your attention, >> >> My concerns would be: >> >> - it doesn't look like it would scale very well beyond small >> examples, the graphical representation would very quickly >> get unwieldy, unless you have some heavyweight UI stuff >> to make it navigable. >> >> - it's too ambitious >> >> - have you looked around to see what kind of debugging tools >> people are asking for? The most oft-requested feature is >> stack traces, and there's lots of scope for doing some
Re: [Haskell-cafe] Re: GSOC Haskell Project
Hmm, interesting. If I intend to give it a try, will there be a mentor for a GSOC project? Or should I start doing it alone? On Thu, Apr 1, 2010 at 8:37 PM, Max Bolingbroke wrote: > I still believe that it would much simpler to get some stack traces > out of GHC by just reporting what chain of thunks we are currently > forcing when we get an error. This just requires a way of reifying the > existing STG stack in some user-readable way. > > What it doesn't give you is lexical call stacks of any form, but many > people have pursued that goal and failed. The STG stack only tells you > the "dynamic" call stack, and will omit any frames removed due to e.g. > tail recursion optimisation, but at least it gives you *some* > information about where your "head []" error is coming from! > > For those interested, there is more discussion of the idea at > http://hackage.haskell.org/trac/ghc/ticket/3693 > > Cheers, > Max > > On 1 April 2010 18:22, Thomas Schilling wrote: >> The DrScheme debugger shows backtraces as arrows in the source code. >> It took some getting used to, but it doesn't seem like a bad idea. I >> believe Leksah has some sort of graphical frontend for the GHCi >> debugger, but I haven't tried it out myself yet. Maybe you can build >> on top of that. >> >> Stack traces are rather difficult to implement. Tristan Allwood >> implemented stack trace support as a GHC Core plugin (see his 2009 >> Haskell Symposium paper) but it required quite a lot of recompilation. >> His stack traces also didn't record any values, just source >> locations. He also had some problems with the way mutually recursive >> functions with type classes were desugared and, as so often, CAFs >> (constant applicative forms). >> So if you propose to work on that you should have a good idea how to >> overcome such issues it in your application. >> >> Another problem with stack traces turned on is that they may lead to >> space leaks. I don't know how big of an issue this is in practise, >> but I'm pretty sure you can't just keep them turned on all the time. >> The GHCi debugger has a tracing mode that can be turned on explicitly >> and allows you to "go back in time" if you hit a break point or error. >> I believe a good front-end could make this a much more widely used >> feature. >> >> On 1 April 2010 17:39, Mihai Maruseac wrote: >>> So, should I change the topic of the project to stack traces instead >>> of visual GUI representation? If this were the case, I will have to >>> find a way to represent those traces in a way that even a beginner can >>> read and understand (my GUI approach was for the beginners). >>> >>> -- >>> Mihai Maruseac >>> >>> On Wed, Mar 31, 2010 at 6:40 PM, Jason Dagit wrote: On Wed, Mar 31, 2010 at 7:21 AM, Simon Marlow wrote: > > On 30/03/2010 20:57, Mihai Maruseac wrote: > >> I'd like to introduce my idea for the Haskell GSOC of this year. In >> fact, you already know about it, since I've talked about it here on >> the haskell-cafe, on my blog and on reddit (even on #haskell one day). >> >> Basically, what I'm trying to do is a new debugger for Haskell, one >> that would be very intuitive for beginners, a graphical one. I've >> given some examples and more details on my blog [0], [1], also linked >> on reditt and other places. >> >> This is not the application, I'm posting this only to receive some >> kind of feedback before writing it. I know that it seems to be a >> little too ambitious but I do think that I can divide the work into >> sessions and finish what I'll start this summer during the next year >> and following. >> >> [0]: http://pgraycode.wordpress.com/2010/03/20/haskell-project-idea/ >> [1]: >> http://pgraycode.wordpress.com/2010/03/24/visual-haskell-debugger-part-2/ >> >> Thanks for your attention, > > My concerns would be: > > - it doesn't look like it would scale very well beyond small > examples, the graphical representation would very quickly > get unwieldy, unless you have some heavyweight UI stuff > to make it navigable. > > - it's too ambitious > > - have you looked around to see what kind of debugging tools > people are asking for? The most oft-requested feature is > stack traces, and there's lots of scope for doing something > there (but also many corpses littering the battlefield, > so watch out!) I would be much more interested in seeing the foundations improved than I would be in having nice things built on them. In other words, I agree with Simon that stack traces would be many times more valuable to me than graphical representations. Once the foundations are robust, then we can build nice things on top of them. Perhaps the reason you're interested in graphical representations is because you want to help people 'visualize', or understand,
Re: [Haskell-cafe] Re: GSOC Haskell Project
I still believe that it would much simpler to get some stack traces out of GHC by just reporting what chain of thunks we are currently forcing when we get an error. This just requires a way of reifying the existing STG stack in some user-readable way. What it doesn't give you is lexical call stacks of any form, but many people have pursued that goal and failed. The STG stack only tells you the "dynamic" call stack, and will omit any frames removed due to e.g. tail recursion optimisation, but at least it gives you *some* information about where your "head []" error is coming from! For those interested, there is more discussion of the idea at http://hackage.haskell.org/trac/ghc/ticket/3693 Cheers, Max On 1 April 2010 18:22, Thomas Schilling wrote: > The DrScheme debugger shows backtraces as arrows in the source code. > It took some getting used to, but it doesn't seem like a bad idea. I > believe Leksah has some sort of graphical frontend for the GHCi > debugger, but I haven't tried it out myself yet. Maybe you can build > on top of that. > > Stack traces are rather difficult to implement. Tristan Allwood > implemented stack trace support as a GHC Core plugin (see his 2009 > Haskell Symposium paper) but it required quite a lot of recompilation. > His stack traces also didn't record any values, just source > locations. He also had some problems with the way mutually recursive > functions with type classes were desugared and, as so often, CAFs > (constant applicative forms). > So if you propose to work on that you should have a good idea how to > overcome such issues it in your application. > > Another problem with stack traces turned on is that they may lead to > space leaks. I don't know how big of an issue this is in practise, > but I'm pretty sure you can't just keep them turned on all the time. > The GHCi debugger has a tracing mode that can be turned on explicitly > and allows you to "go back in time" if you hit a break point or error. > I believe a good front-end could make this a much more widely used > feature. > > On 1 April 2010 17:39, Mihai Maruseac wrote: >> So, should I change the topic of the project to stack traces instead >> of visual GUI representation? If this were the case, I will have to >> find a way to represent those traces in a way that even a beginner can >> read and understand (my GUI approach was for the beginners). >> >> -- >> Mihai Maruseac >> >> On Wed, Mar 31, 2010 at 6:40 PM, Jason Dagit wrote: >>> >>> >>> On Wed, Mar 31, 2010 at 7:21 AM, Simon Marlow wrote: On 30/03/2010 20:57, Mihai Maruseac wrote: > I'd like to introduce my idea for the Haskell GSOC of this year. In > fact, you already know about it, since I've talked about it here on > the haskell-cafe, on my blog and on reddit (even on #haskell one day). > > Basically, what I'm trying to do is a new debugger for Haskell, one > that would be very intuitive for beginners, a graphical one. I've > given some examples and more details on my blog [0], [1], also linked > on reditt and other places. > > This is not the application, I'm posting this only to receive some > kind of feedback before writing it. I know that it seems to be a > little too ambitious but I do think that I can divide the work into > sessions and finish what I'll start this summer during the next year > and following. > > [0]: http://pgraycode.wordpress.com/2010/03/20/haskell-project-idea/ > [1]: > http://pgraycode.wordpress.com/2010/03/24/visual-haskell-debugger-part-2/ > > Thanks for your attention, My concerns would be: - it doesn't look like it would scale very well beyond small examples, the graphical representation would very quickly get unwieldy, unless you have some heavyweight UI stuff to make it navigable. - it's too ambitious - have you looked around to see what kind of debugging tools people are asking for? The most oft-requested feature is stack traces, and there's lots of scope for doing something there (but also many corpses littering the battlefield, so watch out!) >>> >>> I would be much more interested in seeing the foundations improved than I >>> would be in having nice things built on them. In other words, I agree with >>> Simon that stack traces would be many times more valuable to me than >>> graphical representations. Once the foundations are robust, then we can >>> build nice things on top of them. >>> >>> Perhaps the reason you're interested in graphical representations is because >>> you want to help people 'visualize', or understand, the problem. Not all >>> visualizations need to be graphical in the GUI sense. It's really about >>> representing things in a way that helps humans reason about it. Getting the >>> right information to people as they need it is probably the best place to >>> start. >>> >>> Jason >>> >> _
Re: [Haskell-cafe] Re: GSOC Haskell Project
The DrScheme debugger shows backtraces as arrows in the source code. It took some getting used to, but it doesn't seem like a bad idea. I believe Leksah has some sort of graphical frontend for the GHCi debugger, but I haven't tried it out myself yet. Maybe you can build on top of that. Stack traces are rather difficult to implement. Tristan Allwood implemented stack trace support as a GHC Core plugin (see his 2009 Haskell Symposium paper) but it required quite a lot of recompilation. His stack traces also didn't record any values, just source locations. He also had some problems with the way mutually recursive functions with type classes were desugared and, as so often, CAFs (constant applicative forms). So if you propose to work on that you should have a good idea how to overcome such issues it in your application. Another problem with stack traces turned on is that they may lead to space leaks. I don't know how big of an issue this is in practise, but I'm pretty sure you can't just keep them turned on all the time. The GHCi debugger has a tracing mode that can be turned on explicitly and allows you to "go back in time" if you hit a break point or error. I believe a good front-end could make this a much more widely used feature. On 1 April 2010 17:39, Mihai Maruseac wrote: > So, should I change the topic of the project to stack traces instead > of visual GUI representation? If this were the case, I will have to > find a way to represent those traces in a way that even a beginner can > read and understand (my GUI approach was for the beginners). > > -- > Mihai Maruseac > > On Wed, Mar 31, 2010 at 6:40 PM, Jason Dagit wrote: >> >> >> On Wed, Mar 31, 2010 at 7:21 AM, Simon Marlow wrote: >>> >>> On 30/03/2010 20:57, Mihai Maruseac wrote: >>> I'd like to introduce my idea for the Haskell GSOC of this year. In fact, you already know about it, since I've talked about it here on the haskell-cafe, on my blog and on reddit (even on #haskell one day). Basically, what I'm trying to do is a new debugger for Haskell, one that would be very intuitive for beginners, a graphical one. I've given some examples and more details on my blog [0], [1], also linked on reditt and other places. This is not the application, I'm posting this only to receive some kind of feedback before writing it. I know that it seems to be a little too ambitious but I do think that I can divide the work into sessions and finish what I'll start this summer during the next year and following. [0]: http://pgraycode.wordpress.com/2010/03/20/haskell-project-idea/ [1]: http://pgraycode.wordpress.com/2010/03/24/visual-haskell-debugger-part-2/ Thanks for your attention, >>> >>> My concerns would be: >>> >>> - it doesn't look like it would scale very well beyond small >>> examples, the graphical representation would very quickly >>> get unwieldy, unless you have some heavyweight UI stuff >>> to make it navigable. >>> >>> - it's too ambitious >>> >>> - have you looked around to see what kind of debugging tools >>> people are asking for? The most oft-requested feature is >>> stack traces, and there's lots of scope for doing something >>> there (but also many corpses littering the battlefield, >>> so watch out!) >> >> I would be much more interested in seeing the foundations improved than I >> would be in having nice things built on them. In other words, I agree with >> Simon that stack traces would be many times more valuable to me than >> graphical representations. Once the foundations are robust, then we can >> build nice things on top of them. >> >> Perhaps the reason you're interested in graphical representations is because >> you want to help people 'visualize', or understand, the problem. Not all >> visualizations need to be graphical in the GUI sense. It's really about >> representing things in a way that helps humans reason about it. Getting the >> right information to people as they need it is probably the best place to >> start. >> >> Jason >> > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [OT?] Haskell-inspired functions for BASH
On Thu, Apr 1, 2010 at 10:59 AM, Gwern Branwen wrote: > On Thu, Apr 1, 2010 at 11:13 AM, Jeremy Shaw wrote: > > fps is what we now call bytestring. Alas, hsplugins is dead. hsplugins is > > useful, but needs to be rewritten for modern GHC :( > > - jeremy > > I never looked into hsplugins too carefully. Did it offer anything > that Hint doesn't now offer? > The ability to load and unload compiled code in a running application? Perhaps hint offers that now ? Specifically, I believe you could have a function 'foo', and you could load a new version of 'foo' while the programming was running, and the running code would start using the new version instead.. I can't quite remember the details though. 'runtime linking' might be a term to describe it.. - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [OT?] Haskell-inspired functions for BASH
On Thu, Apr 1, 2010 at 11:13 AM, Jeremy Shaw wrote: > fps is what we now call bytestring. Alas, hsplugins is dead. hsplugins is > useful, but needs to be rewritten for modern GHC :( > - jeremy I never looked into hsplugins too carefully. Did it offer anything that Hint doesn't now offer? -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OT: the format checker for ICFP 2010 papers, help!
On Thu, Apr 01, 2010 at 05:25:44PM +0100, Thomas Schilling wrote:
> Do you perhaps have some text that run into the margins? If I have
> references of the form "Longname~\emph{et~al.}~\cite{foobar}" Latex
> does not know how to split this up the text extends into the margins.
> A similar problem might occur for verbatim sections. I submitted a
> paper based on the standard stylesheet earlier today and did not
> encounter any problems.
No, it was the wrong template, as it turned out. I did check for the
"Overfull hbox" message from latex and had none.
Interesting that your paper didn't trigger the error though…
thanks,
iustin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: fastirc 0.2.0
[For some reason, my Mail to the 'haskell' list was rejected. I have contacted the mailing list owner and am posting here instead.] Hello there fellow Haskellers, I'm developing a library called 'fastirc' for fast and convenient Internet Relay Chat (IRC) software development. It uses attoparsec and ByteStrings and the latest release also includes a client framework, which you can use to write bots and user agents easily. Here is the Hackage page: http://hackage.haskell.org/package/fastirc Even though I marked the library as 'alpha' quality, it seems to work well currently. Feel free to try it out and if you find anything odd, just drop me a message (or a patch). =) If you would like to contribute, please contact me first, so I can tell you whether your ideas would be incorporated into the 'fastirc' package or whether it would be better to fork off a new project. By the way, please note that although unlikely right now the interface might change slightly from release to release. I'm planning to stabilize it by version 0.4.0. Also note that the library uses monadLib instead of mtl/transformers, where the monad transformer interface is slightly different. Particularly inside the 'Bot' monad you can run IO computations using 'inBase' instead of 'liftIO'. For more differences, just read the monadLib docs. I hope it will be useful. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSOC Haskell Project
So, should I change the topic of the project to stack traces instead of visual GUI representation? If this were the case, I will have to find a way to represent those traces in a way that even a beginner can read and understand (my GUI approach was for the beginners). -- Mihai Maruseac On Wed, Mar 31, 2010 at 6:40 PM, Jason Dagit wrote: > > > On Wed, Mar 31, 2010 at 7:21 AM, Simon Marlow wrote: >> >> On 30/03/2010 20:57, Mihai Maruseac wrote: >> >>> I'd like to introduce my idea for the Haskell GSOC of this year. In >>> fact, you already know about it, since I've talked about it here on >>> the haskell-cafe, on my blog and on reddit (even on #haskell one day). >>> >>> Basically, what I'm trying to do is a new debugger for Haskell, one >>> that would be very intuitive for beginners, a graphical one. I've >>> given some examples and more details on my blog [0], [1], also linked >>> on reditt and other places. >>> >>> This is not the application, I'm posting this only to receive some >>> kind of feedback before writing it. I know that it seems to be a >>> little too ambitious but I do think that I can divide the work into >>> sessions and finish what I'll start this summer during the next year >>> and following. >>> >>> [0]: http://pgraycode.wordpress.com/2010/03/20/haskell-project-idea/ >>> [1]: >>> http://pgraycode.wordpress.com/2010/03/24/visual-haskell-debugger-part-2/ >>> >>> Thanks for your attention, >> >> My concerns would be: >> >> - it doesn't look like it would scale very well beyond small >> examples, the graphical representation would very quickly >> get unwieldy, unless you have some heavyweight UI stuff >> to make it navigable. >> >> - it's too ambitious >> >> - have you looked around to see what kind of debugging tools >> people are asking for? The most oft-requested feature is >> stack traces, and there's lots of scope for doing something >> there (but also many corpses littering the battlefield, >> so watch out!) > > I would be much more interested in seeing the foundations improved than I > would be in having nice things built on them. In other words, I agree with > Simon that stack traces would be many times more valuable to me than > graphical representations. Once the foundations are robust, then we can > build nice things on top of them. > > Perhaps the reason you're interested in graphical representations is because > you want to help people 'visualize', or understand, the problem. Not all > visualizations need to be graphical in the GUI sense. It's really about > representing things in a way that helps humans reason about it. Getting the > right information to people as they need it is probably the best place to > start. > > Jason > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Where are the haskell elders?
>Perhaps without spewing it to thousands of readers while you're at it? Ahem. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Integers v ints
On 1 April 2010 10:53, Ivan Lazar Miljenovic wrote: > Jens Blanck writes: > > I was wondering if someone could give me some references to when and why > the > > choice was made to default integral numerical literals to Integer rather > > than to Int in Haskell. > > My guess is precision: some numeric calculations (even doing a round on > some Double values) will be too large for Int values (at least on > 32bit). Note that unlike Python, etc. Haskell doesn't allow functions > like round to choose between Int and Integer (which is equivalent to the > long type in Python, etc.). Ints have perfect precision as long as you remember that it implements modulo arithmetic for some power of 2. I was hoping that the reason would be that Integers give more users what they expect, namely integers, instead of something where you can add two positive numbers and wind up with a negative number. The type for round is (Fractional a, Integral b) => a -> b, so that can used to give Integer or Int as you like. > I'd like to use this information to make an analogous case for defaulting > > real numerical literals (well, the literals are likely to be in > scientific > > notation, i.e., floating point) to some data type of computable reals > rather > > than to floating point Double. > > The difference here is performance: under the hood, Integer values which > can be expressed as an Int _are_ stored as an Int (IIUC anyway); however > computable reals are almost always inefficient. Yes, the cost for computable reals will be an order of magnitude or possibly two for well-behaved computations. For not well-behaved problems it will be much worse, but it won't return nonsense either. Also consider that the difference between Integers and unboxed Ints is also quite big. I'll happily to take the hit. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OT: the format checker for ICFP 2010 papers, help!
Do you perhaps have some text that run into the margins? If I have
references of the form "Longname~\emph{et~al.}~\cite{foobar}" Latex
does not know how to split this up the text extends into the margins.
A similar problem might occur for verbatim sections. I submitted a
paper based on the standard stylesheet earlier today and did not
encounter any problems.
If that is not the issue try to contact Stephanie as Wouter suggested.
On 1 April 2010 10:21, Iustin Pop wrote:
> This is off-topic, apologies in advance, but I hope people here have
> experience with this.
>
> I submitted a paper for ICFP but the paper checker says: “Margins too
> small: text block bigger than maximum 7in x 9in on pages 1–6 by 4–5% in
> at least one dimension”.
>
> Now, I've used the standard class file and template, didn't alter any of
> the margins/columns spacing, my paper size is set to letter, and
> pdflatex doesn't give me any overfull hboxes. Does anyone know why the
> error happens in this case?
>
> Also, if the format checker is available somewhere for download so that
> I can pre-check my paper, that'd be great.
>
> thanks,
> iustin
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
--
Push the envelope. Watch it bend.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] new focus for Happstack
Although you are joking, I've said it before and I'll say it again: server-side web development is dead. Everything that can be pushed to the client will be. Which leaves the server mainly for low-level persistence, data analysis, and anything requiring security. Static template-driven web frameworks are obsolete. Regards, John On Apr 1, 2010, at 8:31 AM, Jeremy Shaw wrote: > Hello, > > I've been thinking a lot recently about the direction and future of the > Happstack project. > > These days we hear a lot about technologies to allow servers to push data, > such as Comet, Ajax Push, Reverse Ajax, Two-way-web, HTTP Streaming, and HTTP > server push among others. HTML 5 includes something called 'Web Sockets'. In > short, it seems that the 'stateless' web model is a complete failure. People > want sockets! > > Furthermore, the big sites of the day are 'social media' sites such as > Facebook, Twitter, Youtube, Four Square, etc. > > Well, it's clear to me where the industry is headed, and I think this is a > great chance for Haskell to be the leader. > > persistent connection + social web site == BBS > > That's right! The return of the BBS is upon us. So, without further ado, I > would like to announce the happstack-bbs project: > > darcs get http://src.seereason.com/happstack-bbs/ > > You can connect right now to the world's newest Haskell BBS. Simple open a > terminal which supports ansi & utf-8, and run: > > telnet hacketeria.com 2525 > > Patches welcome (and sorely needed!) > > - jeremy > ___ > 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] Re: new focus for Happstack
Lots of fun, thanks ;) On Thu, Apr 1, 2010 at 7:31 AM, Jeremy Shaw wrote: > Hello, > > I've been thinking a lot recently about the direction and future of the > Happstack project. > > These days we hear a lot about technologies to allow servers to push data, > such as Comet, Ajax Push, Reverse Ajax, Two-way-web, HTTP Streaming, and > HTTP server push among others. HTML 5 includes something called 'Web > Sockets'. In short, it seems that the 'stateless' web model is a complete > failure. People want sockets! > > Furthermore, the big sites of the day are 'social media' sites such as > Facebook, Twitter, Youtube, Four Square, etc. > > Well, it's clear to me where the industry is headed, and I think this is a > great chance for Haskell to be the leader. > > persistent connection + social web site == BBS > > That's right! The return of the BBS is upon us. So, without further ado, I > would like to announce the happstack-bbs project: > > darcs get http://src.seereason.com/happstack-bbs/ > > You can connect right now to the world's newest Haskell BBS. Simple open a > terminal which supports ansi & utf-8, and run: > > telnet hacketeria.com 2525 > > Patches welcome (and sorely needed!) > > - jeremy > > -- > You received this message because you are subscribed to the Google Groups > "HAppS" group. > To post to this group, send email to ha...@googlegroups.com. > To unsubscribe from this group, send email to > happs+unsubscr...@googlegroups.com . > For more options, visit this group at > http://groups.google.com/group/happs?hl=en. > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [OT?] Haskell-inspired functions for BASH
fps is what we now call bytestring. Alas, hsplugins is dead. hsplugins is useful, but needs to be rewritten for modern GHC :( - jeremy On Thu, Apr 1, 2010 at 9:02 AM, Thomas Davie wrote: > Unfortunately though, h4sh seems to be broken, for one, there's no fps > package (apparently required), and hsplugins won't build with 6.12.1. > > Bob > > On 1 Apr 2010, at 15:41, Jeremy Shaw wrote: > > How about: > > http://www.cse.unsw.edu.au/~dons/h4sh.html > > It brings a lot of familiar Haskell functions to the command-line. And *is* > actually written in Haskell ;) > > - jeremy > > On Wed, Mar 31, 2010 at 6:05 PM, Patrick LeBoutillier < > patrick.leboutill...@gmail.com> wrote: > >> Hi all, >> >> I've been studying Haskell for about a year now, and I've really come >> to like it. In my daily work I write a lot of BASH shell scripts and I >> thought I'd try add some of the haskell features and constructs to >> BASH to make my scripting life a bit easier. So I've been working on a >> small BASH function library that implements some basic functional >> programming building blocks. >> >> Note: There is no actual Haskell code involved here. >> >> I put up the full manpage here: >> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=24564 >> Source is here: >> http://svn.solucorp.qc.ca/repos/solucorp/bashkell/trunk/trunk/ >> >> All this is very prototypical, but here is an example of some of the >> stuff I've got so far (map, filter, foldr): >> >> $ ls data >> 1.txt 2.txt >> >> # basic map, argument goes on the command line >> $ ls -d data/* | map basename >> 1.txt >> 2.txt >> >> # map with lambda expression >> $ ls -d data/* | map '\f -> basename $f .txt' >> 1 >> 2 >> >> # simple filter, also works with lambda >> $ ls -d data/* | map basename | filter 'test 1.txt =' >> 1.txt >> >> # sum >> $ ls -d data/* | map '\f -> basename $f .txt' | foldr '\x acc -> echo >> $(($x + $acc))' 0 >> 3 >> >> Basically I'm looking for a bit of feedback/info: >> - Does anyone know if there are already similar projets out there? >> - Does anyone find this interesting? >> - Any other comment/suggestion/feedback >> - Where's a good place to promote such a project? >> >> >> Thanks a lot, >> >> Patrick LeBoutillier >> >> >> -- >> = >> Patrick LeBoutillier >> Rosemère, Québec, Canada >> ___ >> 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] [OT?] Haskell-inspired functions for BASH
Unfortunately though, h4sh seems to be broken, for one, there's no fps package (apparently required), and hsplugins won't build with 6.12.1. Bob On 1 Apr 2010, at 15:41, Jeremy Shaw wrote: > How about: > > http://www.cse.unsw.edu.au/~dons/h4sh.html > > It brings a lot of familiar Haskell functions to the command-line. And *is* > actually written in Haskell ;) > > - jeremy > > On Wed, Mar 31, 2010 at 6:05 PM, Patrick LeBoutillier > wrote: > Hi all, > > I've been studying Haskell for about a year now, and I've really come > to like it. In my daily work I write a lot of BASH shell scripts and I > thought I'd try add some of the haskell features and constructs to > BASH to make my scripting life a bit easier. So I've been working on a > small BASH function library that implements some basic functional > programming building blocks. > > Note: There is no actual Haskell code involved here. > > I put up the full manpage here: > http://hpaste.org/fastcgi/hpaste.fcgi/view?id=24564 > Source is here: http://svn.solucorp.qc.ca/repos/solucorp/bashkell/trunk/trunk/ > > All this is very prototypical, but here is an example of some of the > stuff I've got so far (map, filter, foldr): > > $ ls data > 1.txt 2.txt > > # basic map, argument goes on the command line > $ ls -d data/* | map basename > 1.txt > 2.txt > > # map with lambda expression > $ ls -d data/* | map '\f -> basename $f .txt' > 1 > 2 > > # simple filter, also works with lambda > $ ls -d data/* | map basename | filter 'test 1.txt =' > 1.txt > > # sum > $ ls -d data/* | map '\f -> basename $f .txt' | foldr '\x acc -> echo > $(($x + $acc))' 0 > 3 > > Basically I'm looking for a bit of feedback/info: > - Does anyone know if there are already similar projets out there? > - Does anyone find this interesting? > - Any other comment/suggestion/feedback > - Where's a good place to promote such a project? > > > Thanks a lot, > > Patrick LeBoutillier > > > -- > = > Patrick LeBoutillier > Rosemère, Québec, Canada > ___ > 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] [OT?] Haskell-inspired functions for BASH
How about: http://www.cse.unsw.edu.au/~dons/h4sh.html It brings a lot of familiar Haskell functions to the command-line. And *is* actually written in Haskell ;) - jeremy On Wed, Mar 31, 2010 at 6:05 PM, Patrick LeBoutillier < patrick.leboutill...@gmail.com> wrote: > Hi all, > > I've been studying Haskell for about a year now, and I've really come > to like it. In my daily work I write a lot of BASH shell scripts and I > thought I'd try add some of the haskell features and constructs to > BASH to make my scripting life a bit easier. So I've been working on a > small BASH function library that implements some basic functional > programming building blocks. > > Note: There is no actual Haskell code involved here. > > I put up the full manpage here: > http://hpaste.org/fastcgi/hpaste.fcgi/view?id=24564 > Source is here: > http://svn.solucorp.qc.ca/repos/solucorp/bashkell/trunk/trunk/ > > All this is very prototypical, but here is an example of some of the > stuff I've got so far (map, filter, foldr): > > $ ls data > 1.txt 2.txt > > # basic map, argument goes on the command line > $ ls -d data/* | map basename > 1.txt > 2.txt > > # map with lambda expression > $ ls -d data/* | map '\f -> basename $f .txt' > 1 > 2 > > # simple filter, also works with lambda > $ ls -d data/* | map basename | filter 'test 1.txt =' > 1.txt > > # sum > $ ls -d data/* | map '\f -> basename $f .txt' | foldr '\x acc -> echo > $(($x + $acc))' 0 > 3 > > Basically I'm looking for a bit of feedback/info: > - Does anyone know if there are already similar projets out there? > - Does anyone find this interesting? > - Any other comment/suggestion/feedback > - Where's a good place to promote such a project? > > > Thanks a lot, > > Patrick LeBoutillier > > > -- > = > Patrick LeBoutillier > Rosemère, Québec, Canada > ___ > 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] new focus for Happstack
Hello, I've been thinking a lot recently about the direction and future of the Happstack project. These days we hear a lot about technologies to allow servers to push data, such as Comet, Ajax Push, Reverse Ajax, Two-way-web, HTTP Streaming, and HTTP server push among others. HTML 5 includes something called 'Web Sockets'. In short, it seems that the 'stateless' web model is a complete failure. People want sockets! Furthermore, the big sites of the day are 'social media' sites such as Facebook, Twitter, Youtube, Four Square, etc. Well, it's clear to me where the industry is headed, and I think this is a great chance for Haskell to be the leader. persistent connection + social web site == BBS That's right! The return of the BBS is upon us. So, without further ado, I would like to announce the happstack-bbs project: darcs get http://src.seereason.com/happstack-bbs/ You can connect right now to the world's newest Haskell BBS. Simple open a terminal which supports ansi & utf-8, and run: telnet hacketeria.com 2525 Patches welcome (and sorely needed!) - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OT: the format checker for ICFP 2010 papers, help!
Hi Iustin, cc-Stephanie, > I submitted a paper for ICFP but the paper checker says: “Margins too > small: text block bigger than maximum 7in x 9in on pages 1–6 by 4–5% in > at least one dimension”. > > Now, I've used the standard class file and template, didn't alter any of > the margins/columns spacing, my paper size is set to letter, and > pdflatex doesn't give me any overfull hboxes. Does anyone know why the > error happens in this case? You may want to check with Stephanie Weirich. She is the chair of the program committee for this year's ICFP. I'm sure she can help you submit your paper. Good luck! Wouter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Where are the haskell elders?
Günther Schmidt wrote: > Is there a listing of sorts for all Haskell-relevant blogs? http://planet.haskell.org Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Where are the haskell elders?
Hi all, it could simply be because the medium has changed. I mean a lot of people now seem to have their own websites or blogs. Which would make sense when you want to present a more elaborate piece of work. Is there a listing of sorts for all Haskell-relevant blogs? Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intro to Haskell Crypto Libs
On Thu, 01 Apr 2010 14:14:42 +0200 Günther Schmidt wrote: > Hi all, > > I'm just starting with Haskells Crypto Libs. Is there a good intro to > the subject? > I intend to use it for license key generation. > Applied Cryptography http://www.schneier.com/book-applied.html Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Where are the haskell elders?
Ivan Miljenovic wrote: > 2010/3/30 Don Stewart : >>> I notice that posts from the Haskell elders are pretty rare now. Only >>> every now and then we hear from them. >>> >>> How come? >> Because there is too much noise on this list, Günther > > And they have better things to do than answer stupid questions and get > involved in petty discussions. > Or perhaps people with an overly-condescending attitude are making this list a less friendly place? Personally, I used to highly commend haskell-cafe for being such a friendly place. After catching up on it after a bit of a vacation, I'm not so sure about that anymore. Perhaps that is a price of failing to avoid success, but I wish it weren't. Couldn't you have said that in a bit of a more polite way? Perhaps without spewing it to thousands of readers while you're at it? -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Intro to Haskell Crypto Libs
Hi all, I'm just starting with Haskells Crypto Libs. Is there a good intro to the subject? I intend to use it for license key generation. Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] benchmarking pure code
Ok, thank you for all your answers. I'm going to use NFData as advised by everyone. Paul On Wed, Mar 31, 2010 at 10:38:50AM -0700, Bryan O'Sullivan wrote: > On Wed, Mar 31, 2010 at 4:12 AM, Paul Brauner wrote: > > > Thank you, I will look at that. But it seems that criterion uses NFData no? > > > > I do not know of anything wrong with NFData. What you're seeing is much more > likely to be a bug in either the benchmarking library you're using, or in > your use of it. Most of the benchmarking frameworks on Hackage are extremely > dodgy, which was why I wrote criterion. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Integers v ints
Jens Blanck writes: > I was wondering if someone could give me some references to when and why the > choice was made to default integral numerical literals to Integer rather > than to Int in Haskell. My guess is precision: some numeric calculations (even doing a round on some Double values) will be too large for Int values (at least on 32bit). Note that unlike Python, etc. Haskell doesn't allow functions like round to choose between Int and Integer (which is equivalent to the long type in Python, etc.). > I'd like to use this information to make an analogous case for defaulting > real numerical literals (well, the literals are likely to be in scientific > notation, i.e., floating point) to some data type of computable reals rather > than to floating point Double. The difference here is performance: under the hood, Integer values which can be expressed as an Int _are_ stored as an Int (IIUC anyway); however computable reals are almost always inefficient. -- 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] Re: why doesn't time allow diff of localtimes ?
> bri...@aracnet.com > > Maciej Piechotka wrote: > > > On Wed, 2010-03-31 at 19:29 -0700, bri...@aracnet.com wrote: > > > wagne...@seas.upenn.edu wrote: > > > > > > > Two values of LocalTime may well be computed with respect to > > > > different timezones, which makes the operation you ask for > > > > dangerous. First convert to UTCTime (with localTimeToUTC), then > > > > compare. > > > > > > that makes sense. unfortunately getting the current timezone to > > > convert to UTC results in the dreaded IO contamination problem... > > > > > > Brian > > > > Hmm. Where do you get the local times from in the first place? > > > > read it from a file of course :-) > > I think I've got it figured out. it's not too ugly. > > One interesting "hole" in the system is that buildTime can return a > LocalTime _or_ a UTCTime. That means the same string used to > generate a time can give you two different times. > > It seems as thought it should be restricted to always returning a > UTCTime. If it's going to return a local time it should require an > extra argument of a timezone, shouldn't it ? LocalTime is just day+time, sans TimeZone (so it could be in any timezone). ZonedTime is LocalTime with TimeZone. The functions to convert to UTCTime give a clue: zonedTimeToUTC :: ZonedTime -> UTCTime localTimeToUTC :: TimeZone -> LocalTime -> UTCTime i.e. ZonedTime can convert with no additional information (so in a sense is equivalent), but for LocalTime you need to say which TimeZone to use. If all you have in your file is day_time, you're going to have to get a TimeZone from somewhere, in order to convert to UTCTime. If all you're doing is diffing the LocalTimes, and they are all in the same TimeZone, then any TimeZone will do, I guess. Perhaps add what you learn to one or more of these pages: http://haskell.org/haskellwiki/Cookbook/Dates_And_Time http://haskell.org/haskellwiki/Libraries_and_tools/Time_library or create a new wiki page with better docs for Data.Time? (aside: do we have a policy for naming pages that augment library documentation? what about under here? http://haskell.org/haskellwiki/Library e.g. http://haskell.org/haskellwiki/Library/Time ) Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Integers v ints
I was wondering if someone could give me some references to when and why the choice was made to default integral numerical literals to Integer rather than to Int in Haskell. Also, if you are aware of similar discussions in other languages. I'd like to use this information to make an analogous case for defaulting real numerical literals (well, the literals are likely to be in scientific notation, i.e., floating point) to some data type of computable reals rather than to floating point Double. Jens ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] OT: the format checker for ICFP 2010 papers, help!
This is off-topic, apologies in advance, but I hope people here have experience with this. I submitted a paper for ICFP but the paper checker says: “Margins too small: text block bigger than maximum 7in x 9in on pages 1–6 by 4–5% in at least one dimension”. Now, I've used the standard class file and template, didn't alter any of the margins/columns spacing, my paper size is set to letter, and pdflatex doesn't give me any overfull hboxes. Does anyone know why the error happens in this case? Also, if the format checker is available somewhere for download so that I can pre-check my paper, that'd be great. thanks, iustin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [OT?] Haskell-inspired functions for BASH
Hi, Am Mittwoch, den 31.03.2010, 20:05 -0400 schrieb Patrick LeBoutillier: > Basically I'm looking for a bit of feedback/info: > - Does anyone know if there are already similar projets out there? just similar, not the same: https://www.joachim-breitner.de/blog/archives/156-Haskell-on-the-Command-Line.html Greetings, Joachim -- Joachim "nomeata" Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: building "encoding" on Windows?
> From: Andrew Coppin > >> A new version is due to be release >> pretty soon (somewhere begin april). It has Mingw and Msys included, and >> also some pre-built binaries like cabal and haddock. > > Plain GHC has included Haddock for a while now. It seems to me that > including the entirity of MinGW and MSYS is overkill, but what do I know > about the matter? I was however under the impression that to use Unix > emulators such as these, you have to run everything from a seperate > shell rather than the usual Windows shell. MSys is probably unnecessary, but mingw is necessary to to get configure scripts to run. I wholeheartedly applaud including both of these, because a lot more of hackage will really be just a "cabal install" away. MSys is the separate shell, but you can use mingw with the Windows "cmd" shell if you wish. > > My hope is that the more useful C libraries will get added to HP so that > I can start using them. (E.g., I'd love to be able to do sound synthesis > using Haskell, but there aren't any libraries for accessing the sound > hardware...) I've gotten portaudio to work on Windows. You'll probably need to build and install the C portaudio library manually. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
