Re: [Haskell-cafe] [haskell.org Google Summer of Code] Student Applications Due Friday!

[Johan Tibell]

On Wed, Apr 7, 2010 at 12:46 AM, Edward Kmett  wrote:
> This is a friendly reminder that student applications for the summer of code
> are due to Google by Friday, April 9th.
> http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/timeline
> That is just 3 days from now!
> Keep in mind that while we've been tracking general interest in different
> projects through the trac, the application doesn't count unless you submit
> it to Google at
> http://socghop.appspot.com/gsoc/program/home/google/gsoc2010

I'd just like to repeat that it's really important that you sign up with Google.

> While all details of the application do not need to be finalized, as much of
> the information from
> http://hackage.haskell.org/trac/summer-of-code/wiki/StudApply2010
> as possible should probably be included in your application.

Several people have sent long project descriptions to this mailing
lists. Please also include these in your application.

Cheers,
Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: HXT Namespaces and XPath

[Ivan Miljenovic]

On 7 April 2010 16:41, Uwe Schmidt  wrote:
> But currently it's assumed, that getXPathTreesWithNsEnv is used only in an 
> innocent way.

I like your phrasing here... I might steal it for graphviz rather than
just saying "it's assumed that you don't do such-and-such" :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] Re: HXT Namespaces and XPath

[Uwe Schmidt]

Hi Mads,

> Replying to myself:
> 
> > I think another example will clarify my point. The code:
> > 
> > simpleXmlOne, simpleXmlTwo :: String
> > simpleXmlOne = "http://foo.org\"/>"
> > simpleXmlTwo = "http://foo.org\"/>"
> > 
> > nsEnv :: [(String, String)]
> > nsEnv = [ ("notFoo", "http://notfoo.org";) ]
> > 
> > evalXPath :: String -> [XmlTree]
> > evalXPath xml =
> >   runLA ( xread
> >   >>> propagateNamespaces
> >   >>> getXPathTreesWithNsEnv nsEnv "//a:Foo"

this line contains the problem:

getXPathTreesWithNsEnv assumes, that for all prefixes used in the XPath expr,
the nsEnv contains an entry. Furthermore the default namespace
can be given by an entry for the empty prefix "".

So you'll only get reasonable results, when nsEnv contains at least an entry 
for "a", e.g.

nsEnv = [ ("a", "http://x.y";), ... ]

when you use the XPath expr "//a:Foo".

You may argue, that in your example, an error should be raised by the XPath 
parser, instead
of accepting "//a:Foo". But currently it's assumed, that getXPathTreesWithNsEnv 
is used
only in an innocent way.
 
Cheers,

  Uwe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] GSoC: Hackage 2.0

[Matthew Gruen]

Hi Haskellers,

I'm Matt Gruen (Gracenotes in #haskell), and the Hackage 2.0 SoC
project at 
really piqued my interest. It seems doable, in a summer, to make the
new hackage-server more-than-deployment-ready as well as clearing out
some items in the hackage bug tracker[0]; so, I've been working on a
proposal. In this email I'd like to consolidate my mental notes for
haskell-cafe and formulate a roadmap towards a more social Hackage.

The most vital part is getting hackage-server
 to a state where it can be
switched in place of hackage-scripts
, and doing it properly,
organizing the code so it can be extended painlessly in the future.
Duncan Coutts, Antoine Latter, and others have done some great work on
it in the past few years. I've been using Haskell for 1.33 of those
years. I think I could become fluent in the codebases after a week of
dedicated study, although even the hackage-server and hackage-scripts
repositories don't include some components such as the current build
report script.

For putting the 2.0 in Hackage 2.0, any interface changes should help
the library users and the library writers/uploaders without hurting
either of them. Hackage should contain more of the right kind of
information. Statistics help everyone, and they're a pretty good gauge
on the direction of Hackage as a whole. Package popularity contents
are one form of this. Reverse dependencies and even dependency
graphs[1] are great, if I can integrate and expand Roel van Dijk's
work[2].

There should also be some space on package pages, or on pages a link
away from them, for users to contribute information and suggestions.
Coders can explain why or why not the package met their needs, as a
sort of informal bug/enhancement tracking service. Another helpful
flavor of information is package relationships beyond dependencies:
'Deprecated in favor of Foo', 'a fork of Foo', or 'does blah instead
of Foo's plugh functionality'. This will help people find the 'right'
package among look-alikes. There could also be links to illustrative
usage examples for getting started. Happstack's state management will
be a good match for updating and serving this information in real
time.

There's also a need for a more interactive form of package
documentation, but this should strengthen relationships with existing
tools like Haddock and Cabal, not bypass the tools. For example,
adding a changelog[3] or making Haddock's declaration-by-declaration
commentary more wiki-like[4]. Changelogs seem to be within the scope
of Hackage 2.0, integrating with Cabal; Haddock wikification might not
be, perhaps deserving a separate student-summer session of its own.
These can improve the package page and documentation subtrees.

More generally, how can library users find the package they want?
Categories themselves are great, but a tag system could identify and
group specific package functionality. There could be sorting by
ratings and reviews (4/5 lambdas!). Metadata searches, like those
Sascha Böhme implemented in SoC 2007[5], could be integrated. It's not
always obvious which ideas will help and which won't see good returns,
which makes it all the more important to bring hackage-server to a
state where future extensions can be easily written, submitted and
deployed. That's the goal here.

On the technical side, I realize I'd need to spend a not-insignificant
amount of time on a user account system, dealing with authentication
and related issues. One additional bit of functionality to manage is
the hackage build system, which is used to ensure that packages build
and to generate documentation. When building depends on FFI or
OS-specific bindings, specific versions of other packages, compiler
choice or compiler version choice, including language extensions, this
is not trivial. One of two good routes is running cabal server-side to
generate build reports and alleviate the miscompiling a smidge. Given
that cabal install dependency calculation seems to be up in the air
still, the current Setup-running script might end up staying for the
moment, with some basic integrity checking (no cycles or other
impossible dependency scenarios). The other not-mutually-exclusive
approach is accepting failed build reports from users as a web
service[6] to generate a matrix of the platforms that seem to
encounter the most trouble.

Ultimately, it's important that I, or whoever ends up doing the
project, plans for it to benefit you guys. What do you think?

—Matt Gruen

PS: how do you feel about augmenting the .cabal format to provide more
information for Hackage?

[0] Active Tickets by Component, scroll down to HackageDB.
http://hackage.haskell.org/trac/hackage/report/9?USER=anonymous&page=3
[1] Re: ANN: Reverse Dependencies in Hackage (demo).
http://www.haskell.org/pipermail/haskell-cafe/2009-October/067847.html
[2] Show reverse dependencies. I

Re: [Haskell-cafe] Re: Haskell.org re-design

[Antoine Latter]

On Tue, Apr 6, 2010 at 8:22 PM, Thomas Schilling
 wrote:
> Ok, last revision for tonight:  http://i.imgur.com/d3ARq.png

I'm no web design guru, but this is definitely better than what we
have now. Good job on it.

Antoine
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Why does Haskell not infer most general type?

[Job Vranish]

Thank you all for your replies. This is all much more clear now :)

- Job

On Tue, Apr 6, 2010 at 7:00 PM, Ross Paterson  wrote:

> On Tue, Apr 06, 2010 at 05:18:34PM -0400, Job Vranish wrote:
> > So in Haskell 98, would the added constraints result in a type error?
>
> Yes, because the types of the mutually recursive identifiers would be
> inferred together without using the type signatures, and then would
> fail to match the declared types.
>
> But then there aren't any implementations of Haskell 98 to test this on.
> ___
> 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] Re: GSoC: Improving Cabal's Test Support

[Gregory Crosswhite]

As I understand it, there is only one place in the Cabal package where *build* 
dependencies appear, in contrast to lines in the Library and Executable 
sections where the *install* dependencies appear (i.e., you might not need all 
of the build dependences around merely to use the library or programs).  So 
there would need to be a way of specifying in the .cabal file in a convenient 
way (i.e., hopefully without having the package writer manually specify 
conditionals) that some of the *build* dependencies only apply if one is 
building the test packages.

Cheers,
Greg

On Apr 6, 2010, at 6:37 PM, Thomas Tuegel wrote:

> On Tue, Apr 6, 2010 at 9:00 PM, Gregory Crosswhite
>  wrote:
>> Sounds like a good plan to me!
>> 
>> You still need some way to separate out the test dependencies from the main 
>> build dependencies, though.  Perhaps as a separate line in the main Cabal 
>> header section?
> 
> I think I can implement this inside Cabal in the conversion from
> GenericPackageDescription to PackageDescription, as if it were
> implemented all in terms of conditionals.  So, if tests are enabled,
> the test executables are in the PackageDescription and their
> dependencies get pulled in; if tests are disabled, the executables get
> cut from the PackageDescription.  Am I missing something?
> 
> -- 
> Thomas Tuegel

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Haskell.org re-design

[Gregory Crosswhite]

While I think that (d) is a valid concern, it is also important not to let the 
perfect be the enemy of the good.  If we agree that the proposed web site 
layout is sufficiently better than the current one and is "good enough" 
aesthetically, then I think we should go ahead and switch to the new layout and 
*then* start thinking about how we could make it *completely amazing* like the 
Ruby web site, because if we demand completely amazing for our *first* try then 
I fear that all that will happen is that nothing will change because the bar 
will have been set too high.

Cheers,
Greg

On Apr 6, 2010, at 6:25 PM, Jason Dagit wrote:

> 
> 
> On Tue, Apr 6, 2010 at 5:49 PM, Thomas Schilling  
> wrote:
> Ok, based on both your and Ivan's comments I modified a bit more.
> 
> http://i.imgur.com/cumLj.png
> 
> Making the top columns and the lower columns the same width looks bad,
> but I agree that the large margin between the blurb and the
> Documentation headline was too large.
> After I changed that, however, the Documentation section and the News
> sections did not line up anymore which looked even worse when the news
> section had a different background colour.  So instead the background
> colour is used for the quicklinks.  Removing any use of a background
> colour would makes things too boring, though.
> I also swapped the heading colour and the title bar colour.  So
> headings are now a very dark blue.
> 
> The italic things in the blurb are actually not links (though they
> could be).  Without any styling the blurb would look too boring, so
> I'm using the same blue that the title bar uses.
> 
> We were discussing it briefly around the office and some things I recall from 
> that:
>   a) There's only so much you can do with square boxes, flat colors, and a 
> single font.
>   b) http://www.ruby-lang.org/en/ is probably one of the best looking 
> programming language websites.
>   c) the wiki bar at the top has got to go
>   d) how do the designs look on mobile devices?
> 
> It looks like you've definitely tackled (c), so that's great.  It seems like 
> maybe we can draw on (b) to help address (a).
> 
> I wish I had more concrete suggestions.  Keep up the good work!
> 
> Jason

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Haskell.org re-design

[Gregory Crosswhite]

Ah, that looks a lot nicer.  :-)

Cheers,
Greg


On Apr 6, 2010, at 5:49 PM, Thomas Schilling wrote:

> Ok, based on both your and Ivan's comments I modified a bit more.
> 
> http://i.imgur.com/cumLj.png
> 
> Making the top columns and the lower columns the same width looks bad,
> but I agree that the large margin between the blurb and the
> Documentation headline was too large.
> After I changed that, however, the Documentation section and the News
> sections did not line up anymore which looked even worse when the news
> section had a different background colour.  So instead the background
> colour is used for the quicklinks.  Removing any use of a background
> colour would makes things too boring, though.
> I also swapped the heading colour and the title bar colour.  So
> headings are now a very dark blue.
> 
> The italic things in the blurb are actually not links (though they
> could be).  Without any styling the blurb would look too boring, so
> I'm using the same blue that the title bar uses.
> 
> 
> On 7 April 2010 01:25, Gregory Crosswhite  wrote:
>> I concur that the latest version with the softer colors looks a lot nicer, 
>> and I approve of the overall design.  I think that you should go back to 
>> using a change in the foreground color rather than the background color for 
>> the links in the main description, since at the moment it looks ugly.  I 
>> also think that it would look better if you could align the two columns in 
>> the top (i.e., the description text and the major links above the "News and 
>> Events" section) so that they align better with the two columns below;  you 
>> could probably also have the description text creep into the left margin so 
>> that it isn't exactly centered over the left column below, if that would 
>> look better.
>> 
>> Cheers,
>> Greg
>> 
>> 
>> On Apr 6, 2010, at 5:16 PM, Ivan Miljenovic wrote:
>> 
>>> On 7 April 2010 10:02, Thomas Schilling  wrote:
 On 7 April 2010 00:57, Ivan Miljenovic  wrote:
> OK, I dislike the colour scheme.  Happy now? ;-)
 
 That's still not constructive.  I.e, is it the black, the gray, the orange?
>>> 
>>> OK, it's the black; it seems a tad too strong for me (the fact that
>>> you have a black theme for your browser probably doesn't help).
>>> 
 Using more intense colours for the bar at the top becomes distracting very 
 quickly.
>>> 
>>> How about a more neutral, paler colour?
>>> 
 Anyway, here's something with a bit more colour:  
 http://i.imgur.com/LpQmH.png
>>> 
>>> Apart from the black up the top still, I think this is nicer.
>>> However, maybe the links in the description text up the top are a bit
>>> too obvious...
>>> 
>>> 
>>> --
>>> 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
>> 
>> 
> 
> 
> 
> -- 
> 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] Re: Haskell.org re-design

[Ivan Miljenovic]

On 7 April 2010 11:53, Ben Millwood  wrote:
> I've never really trusted this argument - it's not required that the
> browser window occupy the entire screen, so why not let the user
> choose how wide they want their text?

Agreed; I hate websites/blogs/etc. that only take up a fraction of the
screen width (especially since I like to increase the font size to
make it more readable, which results in only having a few words per
line and quite often weird wrapping issues).  At least it's in the
centre though; this (which my brother worked on, which is why I know
about it) abomination for some reason has everything on the left of
the screen (some argument about how people might want to overlap their
browser window with a text editor, etc.; I dont' see why they don't
just shrink and move the browser window then):
http://www.arachnoserver.org/



-- 
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: Haskell.org re-design

[Ben Millwood]

On Wed, Apr 7, 2010 at 2:22 AM, Thomas Schilling
 wrote:
> I have
> set a maximum width on purpose so that it doesn't degrade too badly on
> big screens.

I've never really trusted this argument - it's not required that the
browser window occupy the entire screen, so why not let the user
choose how wide they want their text?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

[Thomas Tuegel]

On Tue, Apr 6, 2010 at 9:00 PM, Gregory Crosswhite
 wrote:
> Sounds like a good plan to me!
>
> You still need some way to separate out the test dependencies from the main 
> build dependencies, though.  Perhaps as a separate line in the main Cabal 
> header section?

I think I can implement this inside Cabal in the conversion from
GenericPackageDescription to PackageDescription, as if it were
implemented all in terms of conditionals.  So, if tests are enabled,
the test executables are in the PackageDescription and their
dependencies get pulled in; if tests are disabled, the executables get
cut from the PackageDescription.  Am I missing something?

-- 
Thomas Tuegel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Haskell.org re-design

[Jason Dagit]

On Tue, Apr 6, 2010 at 5:49 PM, Thomas Schilling wrote:

> Ok, based on both your and Ivan's comments I modified a bit more.
>
> http://i.imgur.com/cumLj.png
>
> Making the top columns and the lower columns the same width looks bad,
> but I agree that the large margin between the blurb and the
> Documentation headline was too large.
> After I changed that, however, the Documentation section and the News
> sections did not line up anymore which looked even worse when the news
> section had a different background colour.  So instead the background
> colour is used for the quicklinks.  Removing any use of a background
> colour would makes things too boring, though.
> I also swapped the heading colour and the title bar colour.  So
> headings are now a very dark blue.
>
> The italic things in the blurb are actually not links (though they
> could be).  Without any styling the blurb would look too boring, so
> I'm using the same blue that the title bar uses.
>

We were discussing it briefly around the office and some things I recall
from that:
  a) There's only so much you can do with square boxes, flat colors, and a
single font.
  b) http://www.ruby-lang.org/en/ is probably one of the best looking
programming language websites.
  c) the wiki bar at the top has got to go
  d) how do the designs look on mobile devices?

It looks like you've definitely tackled (c), so that's great.  It seems like
maybe we can draw on (b) to help address (a).

I wish I had more concrete suggestions.  Keep up the good work!

Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

[Rogan Creswick]

On Tue, Apr 6, 2010 at 5:49 PM, Thomas Tuegel  wrote:
>
> Suppose we adopt your suggestion and let test programs be ordinary
> executables in ordinary 'Executable' sections, and make 'Test'
> sections that look like:
>
> > Test foo-1
> >     exe-is: foo
> >     options: --enable-bar --disable-baz
> >
> > Test foo-2
> >     exe-is: foo
> >     options: --enable-bar --enable-baz
> >
> > Test some-other-test
> >     exe-is: some-other-test
> >     options: --something-completely-different
>
> Now we get named sets of options but don't have to worry about parsing
> through to find the executable names!  It also solves the problem of
> running test suites with multiple sets of options at runtime.
>

Ah, I like this too, as well as Gregory's suggestion re: "Automatic" options.

--Rogan

> --
> Thomas Tuegel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Haskell.org re-design

[Thomas Schilling]

Ok, last revision for tonight:  http://i.imgur.com/d3ARq.png

I fixed the link-box hanging over and I made the logo a bit bigger
(60px, like currently on the Wiki)

Ivan, yes it's more like Slate Grey, no idea what it's called.  I have
set a maximum width on purpose so that it doesn't degrade too badly on
big screens.  It was 50em (50 x font size), now it's 55em;  For
one-column text 40em would be better (too long lines are hard to
read), but since it's a two-column layout, it's fine if it's wider.
I've seen a website that fluidly switches between 2 and 3-column
layout depending on how wide the window is (using CSS only) but I
suppose that's hard to get to work portably (well, IE).

On 7 April 2010 01:57, Gregory Crosswhite  wrote:
> Nice!  Is there any way you can enlarge the bottom section so that the box in 
> the top-right doesn't look like it is hanging over the side (i.e., having 
> whitespace directly below it and to the right of the main text)?  If 
> anything, I think that it would look better for the bottom text to extend 
> further right than the box at the top than vice versa.
>
> Cheers,
> Greg
>
> On Apr 6, 2010, at 5:49 PM, Thomas Schilling wrote:
>
>> Ok, based on both your and Ivan's comments I modified a bit more.
>>
>> http://i.imgur.com/cumLj.png
>>
>> Making the top columns and the lower columns the same width looks bad,
>> but I agree that the large margin between the blurb and the
>> Documentation headline was too large.
>> After I changed that, however, the Documentation section and the News
>> sections did not line up anymore which looked even worse when the news
>> section had a different background colour.  So instead the background
>> colour is used for the quicklinks.  Removing any use of a background
>> colour would makes things too boring, though.
>> I also swapped the heading colour and the title bar colour.  So
>> headings are now a very dark blue.
>>
>> The italic things in the blurb are actually not links (though they
>> could be).  Without any styling the blurb would look too boring, so
>> I'm using the same blue that the title bar uses.
>>
>>
>> On 7 April 2010 01:25, Gregory Crosswhite  wrote:
>>> I concur that the latest version with the softer colors looks a lot nicer, 
>>> and I approve of the overall design.  I think that you should go back to 
>>> using a change in the foreground color rather than the background color for 
>>> the links in the main description, since at the moment it looks ugly.  I 
>>> also think that it would look better if you could align the two columns in 
>>> the top (i.e., the description text and the major links above the "News and 
>>> Events" section) so that they align better with the two columns below;  you 
>>> could probably also have the description text creep into the left margin so 
>>> that it isn't exactly centered over the left column below, if that would 
>>> look better.
>>>
>>> Cheers,
>>> Greg
>>>
>>>
>>> On Apr 6, 2010, at 5:16 PM, Ivan Miljenovic wrote:
>>>
 On 7 April 2010 10:02, Thomas Schilling  wrote:
> On 7 April 2010 00:57, Ivan Miljenovic  wrote:
>> OK, I dislike the colour scheme.  Happy now? ;-)
>
> That's still not constructive.  I.e, is it the black, the gray, the 
> orange?

 OK, it's the black; it seems a tad too strong for me (the fact that
 you have a black theme for your browser probably doesn't help).

> Using more intense colours for the bar at the top becomes distracting 
> very quickly.

 How about a more neutral, paler colour?

> Anyway, here's something with a bit more colour:  
> http://i.imgur.com/LpQmH.png

 Apart from the black up the top still, I think this is nicer.
 However, maybe the links in the description text up the top are a bit
 too obvious...


 --
 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
>>>
>>>
>>
>>
>>
>> --
>> Push the envelope.  Watch it bend.
>
>



-- 
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] Re: GSoC: Improving Cabal's Test Support

[Gregory Crosswhite]

Sounds like a good plan to me!

You still need some way to separate out the test dependencies from the main 
build dependencies, though.  Perhaps as a separate line in the main Cabal 
header section?

Also, per my earlier comment, it would be good if there were also an 
"Automatic" option in each test section that defaults to True and specifies 
whether a test is included automatically in "cabal test" or whether it needs to 
be specified manually.

Cheers,
Greg


On Apr 6, 2010, at 5:49 PM, Thomas Tuegel wrote:

> I apologize for spamming, but it only just occurred to me how to get
> the best aspects of both our ideas:
> 
> On Tue, Apr 6, 2010 at 8:28 PM, Thomas Tuegel  wrote:
>> On Tue, Apr 6, 2010 at 7:43 PM, Rogan Creswick  wrote:
>>> The existing Executable sections may serve the need fine, if we could
>>> specify how to run the tests in a different way.  Perhaps a list of
>>> test commands could be specified instead, eg:
>>> 
 TestCommands: foo-test-ghc6.6,
foo-test-ghc6.8,
foo-props --all
>>> 
>>> Anyhow, just food for thought.
>> 
>> One of the reasons I prefer implementing a dedicated 'Test' stanza is
>> that it makes it easier to tell which executables to install.  There
>> may be situations where we want to install test programs, but there
>> will _always_ be situations where we _don't_ want to.  (Maybe
>> '--{en,dis}able-tests' passed to 'cabal install' should control this?)
>>  Could we take a 'TestCommands' list and parse out the options to get
>> the executable names?  Yes, but relying on that to work makes me
>> uneasy.  I think the more robust way to specify executable-specific
>> options instead would be to add a field to the 'Test' section
>> ('run-options' seems to be consistent with the naming scheme) that
>> doesn't exist in 'Executable'.
> 
> Suppose we adopt your suggestion and let test programs be ordinary
> executables in ordinary 'Executable' sections, and make 'Test'
> sections that look like:
> 
>> Test foo-1
>>exe-is: foo
>>options: --enable-bar --disable-baz
>> 
>> Test foo-2
>>exe-is: foo
>>options: --enable-bar --enable-baz
>> 
>> Test some-other-test
>>exe-is: some-other-test
>>options: --something-completely-different
> 
> Now we get named sets of options but don't have to worry about parsing
> through to find the executable names!  It also solves the problem of
> running test suites with multiple sets of options at runtime.
> 
> -- 
> Thomas Tuegel
> ___
> 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] Re: Haskell.org re-design

[Gregory Crosswhite]

Nice!  Is there any way you can enlarge the bottom section so that the box in 
the top-right doesn't look like it is hanging over the side (i.e., having 
whitespace directly below it and to the right of the main text)?  If anything, 
I think that it would look better for the bottom text to extend further right 
than the box at the top than vice versa.

Cheers,
Greg

On Apr 6, 2010, at 5:49 PM, Thomas Schilling wrote:

> Ok, based on both your and Ivan's comments I modified a bit more.
> 
> http://i.imgur.com/cumLj.png
> 
> Making the top columns and the lower columns the same width looks bad,
> but I agree that the large margin between the blurb and the
> Documentation headline was too large.
> After I changed that, however, the Documentation section and the News
> sections did not line up anymore which looked even worse when the news
> section had a different background colour.  So instead the background
> colour is used for the quicklinks.  Removing any use of a background
> colour would makes things too boring, though.
> I also swapped the heading colour and the title bar colour.  So
> headings are now a very dark blue.
> 
> The italic things in the blurb are actually not links (though they
> could be).  Without any styling the blurb would look too boring, so
> I'm using the same blue that the title bar uses.
> 
> 
> On 7 April 2010 01:25, Gregory Crosswhite  wrote:
>> I concur that the latest version with the softer colors looks a lot nicer, 
>> and I approve of the overall design.  I think that you should go back to 
>> using a change in the foreground color rather than the background color for 
>> the links in the main description, since at the moment it looks ugly.  I 
>> also think that it would look better if you could align the two columns in 
>> the top (i.e., the description text and the major links above the "News and 
>> Events" section) so that they align better with the two columns below;  you 
>> could probably also have the description text creep into the left margin so 
>> that it isn't exactly centered over the left column below, if that would 
>> look better.
>> 
>> Cheers,
>> Greg
>> 
>> 
>> On Apr 6, 2010, at 5:16 PM, Ivan Miljenovic wrote:
>> 
>>> On 7 April 2010 10:02, Thomas Schilling  wrote:
 On 7 April 2010 00:57, Ivan Miljenovic  wrote:
> OK, I dislike the colour scheme.  Happy now? ;-)
 
 That's still not constructive.  I.e, is it the black, the gray, the orange?
>>> 
>>> OK, it's the black; it seems a tad too strong for me (the fact that
>>> you have a black theme for your browser probably doesn't help).
>>> 
 Using more intense colours for the bar at the top becomes distracting very 
 quickly.
>>> 
>>> How about a more neutral, paler colour?
>>> 
 Anyway, here's something with a bit more colour:  
 http://i.imgur.com/LpQmH.png
>>> 
>>> Apart from the black up the top still, I think this is nicer.
>>> However, maybe the links in the description text up the top are a bit
>>> too obvious...
>>> 
>>> 
>>> --
>>> 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
>> 
>> 
> 
> 
> 
> -- 
> 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] Re: Haskell.org re-design

[Ivan Miljenovic]

On 7 April 2010 10:49, Thomas Schilling  wrote:
> http://i.imgur.com/cumLj.png

I wonder... is there any reason why the actual page content is so
narrow compared to the title bar (to allow for small screens)?

> [snip] So headings are now a very dark blue.
>
> The italic things in the blurb are actually not links (though they
> could be).  Without any styling the blurb would look too boring, so
> I'm using the same blue that the title bar uses.

That's _blue_ ? :O

I was thinking it looked more like Slate Gray or something...

-- 
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: Haskell.org re-design

[Thomas Schilling]

Ok, based on both your and Ivan's comments I modified a bit more.

http://i.imgur.com/cumLj.png

Making the top columns and the lower columns the same width looks bad,
but I agree that the large margin between the blurb and the
Documentation headline was too large.
After I changed that, however, the Documentation section and the News
sections did not line up anymore which looked even worse when the news
section had a different background colour.  So instead the background
colour is used for the quicklinks.  Removing any use of a background
colour would makes things too boring, though.
I also swapped the heading colour and the title bar colour.  So
headings are now a very dark blue.

The italic things in the blurb are actually not links (though they
could be).  Without any styling the blurb would look too boring, so
I'm using the same blue that the title bar uses.


On 7 April 2010 01:25, Gregory Crosswhite  wrote:
> I concur that the latest version with the softer colors looks a lot nicer, 
> and I approve of the overall design.  I think that you should go back to 
> using a change in the foreground color rather than the background color for 
> the links in the main description, since at the moment it looks ugly.  I also 
> think that it would look better if you could align the two columns in the top 
> (i.e., the description text and the major links above the "News and Events" 
> section) so that they align better with the two columns below;  you could 
> probably also have the description text creep into the left margin so that it 
> isn't exactly centered over the left column below, if that would look better.
>
> Cheers,
> Greg
>
>
> On Apr 6, 2010, at 5:16 PM, Ivan Miljenovic wrote:
>
>> On 7 April 2010 10:02, Thomas Schilling  wrote:
>>> On 7 April 2010 00:57, Ivan Miljenovic  wrote:
 OK, I dislike the colour scheme.  Happy now? ;-)
>>>
>>> That's still not constructive.  I.e, is it the black, the gray, the orange?
>>
>> OK, it's the black; it seems a tad too strong for me (the fact that
>> you have a black theme for your browser probably doesn't help).
>>
>>> Using more intense colours for the bar at the top becomes distracting very 
>>> quickly.
>>
>> How about a more neutral, paler colour?
>>
>>> Anyway, here's something with a bit more colour:  
>>> http://i.imgur.com/LpQmH.png
>>
>> Apart from the black up the top still, I think this is nicer.
>> However, maybe the links in the description text up the top are a bit
>> too obvious...
>>
>>
>> --
>> 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
>
>



-- 
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] Re: GSoC: Improving Cabal's Test Support

[Thomas Tuegel]

I apologize for spamming, but it only just occurred to me how to get
the best aspects of both our ideas:

On Tue, Apr 6, 2010 at 8:28 PM, Thomas Tuegel  wrote:
> On Tue, Apr 6, 2010 at 7:43 PM, Rogan Creswick  wrote:
>> The existing Executable sections may serve the need fine, if we could
>> specify how to run the tests in a different way.  Perhaps a list of
>> test commands could be specified instead, eg:
>>
>>> TestCommands: foo-test-ghc6.6,
>>>                            foo-test-ghc6.8,
>>>                            foo-props --all
>>
>> Anyhow, just food for thought.
>
> One of the reasons I prefer implementing a dedicated 'Test' stanza is
> that it makes it easier to tell which executables to install.  There
> may be situations where we want to install test programs, but there
> will _always_ be situations where we _don't_ want to.  (Maybe
> '--{en,dis}able-tests' passed to 'cabal install' should control this?)
>  Could we take a 'TestCommands' list and parse out the options to get
> the executable names?  Yes, but relying on that to work makes me
> uneasy.  I think the more robust way to specify executable-specific
> options instead would be to add a field to the 'Test' section
> ('run-options' seems to be consistent with the naming scheme) that
> doesn't exist in 'Executable'.

Suppose we adopt your suggestion and let test programs be ordinary
executables in ordinary 'Executable' sections, and make 'Test'
sections that look like:

> Test foo-1
> exe-is: foo
> options: --enable-bar --disable-baz
>
> Test foo-2
> exe-is: foo
> options: --enable-bar --enable-baz
>
> Test some-other-test
> exe-is: some-other-test
> options: --something-completely-different

Now we get named sets of options but don't have to worry about parsing
through to find the executable names!  It also solves the problem of
running test suites with multiple sets of options at runtime.

-- 
Thomas Tuegel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

[Ivan Miljenovic]

On 7 April 2010 10:45, Gregory Crosswhite  wrote:
> Yes, I personally think that tests which are automatically run should be 
> self-contained so that they require no additional intervention by the user.  
> However, one could conceivably flag some tests as being "manual" so that they 
> are only run when chosen specifically (i.e. if "foo" is manual then it is 
> only run with "cabal run foo").

Sounds good to me.

-- 
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: GSoC: Improving Cabal's Test Support

[Gregory Crosswhite]

On Apr 6, 2010, at 5:35 PM, Ivan Miljenovic wrote:

> On 7 April 2010 10:28, Thomas Tuegel  wrote:
>> Ok, this is the bottom-line that I didn't understand after our first
>> exchange, but I think now I do: I should entirely scrap the second
>> aspect of my proposal and focus exclusively on making Cabal build and
>> run test programs.
> 
> Just as a food for thought: how would you deal with test programs that
> deal with user input?  Should "cabal test" only run those that are
> automatic?

Yes, I personally think that tests which are automatically run should be 
self-contained so that they require no additional intervention by the user.  
However, one could conceivably flag some tests as being "manual" so that they 
are only run when chosen specifically (i.e. if "foo" is manual then it is only 
run with "cabal run foo").

Cheers,
Greg

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] what are the safety conditions for unsafeIOToST

[Gregory Crosswhite]

I would venture that the condition under which unsafeIOtoST would be safe is if 
all of the computations you are performing in the IO monad are only changing 
state that is local to the computation within the ST monad in which you are 
running.  (For example, if there were no STRef type then you could emulate it 
using IORefs, and this would be safe since the IORefs couldn't leak outside of 
the ST monad.)  It sounds like Unique doesn't satisfy this property since the 
side-effect of creating a new Unique will leak out of the ST monad.  It would 
probably be better to use some other stream of unique values that runs inside 
the ST monad.

Cheers,
Greg

On Apr 6, 2010, at 5:30 PM, Roman Leshchinskiy wrote:

> On 07/04/2010, at 07:33, Nicolas Frisby wrote:
> 
>> I haven't been able to find it via Google or Haddock. An old message
>> suggests is was just a matter of exceptions?
> 
> I don't think that's correct. You can implement unsafePerformIO in terms 
> unsafeIOToST:
> 
> unsafePerformIO :: IO a -> a
> unsafePerformIO p = runST (unsafeIOToST p)
> 
> In fact, the only safe-ish use for it I have found is to use Storable-related 
> functions in ST, hoping that the instances don't actually use any real IO 
> functionality. Arguably, this shouldn't be necessary as Storable should live 
> in ST anyway.
> 
>> I only want to use the IO for generating Data.Uniques to pair with
>> STRefs in order to make a map of them. I'm guessing this would be a
>> safe use since it's exception free (... right?).
> 
> It's hard to tell without looking at your code. But if you are generating 
> Uniques in ST then it's probably unsafe:
> 
> foo :: () -> Unique
> foo _ = runST (unsafeIOToST newUnique)
> 
> What's the value of foo ()?
> 
> Roman
> 
> 
> ___
> 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] Re: GSoC: Improving Cabal's Test Support

[Gregory Crosswhite]

On Apr 6, 2010, at 5:28 PM, Thomas Tuegel wrote:

> On Tue, Apr 6, 2010 at 7:43 PM, Rogan Creswick  wrote:
>> test-framework and test-runner both address the second problem, and
>> those solutions can be kept separate, at least for now.  Figuring out
>> the best way to specify test commands, dependencies, build/execution
>> order, etc. is going to take some substantial effort, and I think that
>> should be the first goal of the project.
> 
> Ok, this is the bottom-line that I didn't understand after our first
> exchange, but I think now I do: I should entirely scrap the second
> aspect of my proposal and focus exclusively on making Cabal build and
> run test programs.

I concur with this conclusion.

>> Cabal allows for multiple executable sections -- are multiple test
>> sections allowed? If so, how are they handled when 'cabal test' is
>> invoked?  If not, will there be any support for running multiple test
>> suites? (more on this below).
>> 
>> While the test executable could be configured to run different sets of
>> tests (at runtime? hm.. we may need more flags to 'cabal test'), there
>> are some situations it's necessary to build multiple test suites
>> because of odd library dependencies.  (for example, testing certain
>> combinations of libraries--imagine supporting multiple versions of
>> ghc.)
> 
> I had intended to allow multiple 'Executable' sections; that's what I
> meant by "this is really an 'Executable' stanza by another name".  I
> think that takes care of your concern about building multiple test
> suites with different dependencies, also.
> 
> My thinking is that 'cabal test' should run all the tests that were
> built, and 'cabal test foo' should run only the test named 'foo'.

This sounds like a good idea to me.

>> The existing Executable sections may serve the need fine, if we could
>> specify how to run the tests in a different way.  Perhaps a list of
>> test commands could be specified instead, eg:
>> 
>>> TestCommands: foo-test-ghc6.6,
>>>foo-test-ghc6.8,
>>>foo-props --all
>> 
>> Anyhow, just food for thought.
> 
> One of the reasons I prefer implementing a dedicated 'Test' stanza is
> that it makes it easier to tell which executables to install.  There
> may be situations where we want to install test programs, but there
> will _always_ be situations where we _don't_ want to.  (Maybe
> '--{en,dis}able-tests' passed to 'cabal install' should control this?)
> Could we take a 'TestCommands' list and parse out the options to get
> the executable names?  Yes, but relying on that to work makes me
> uneasy.  I think the more robust way to specify executable-specific
> options instead would be to add a field to the 'Test' section
> ('run-options' seems to be consistent with the naming scheme) that
> doesn't exist in 'Executable'.
> 
> (I've snipped some of the comments here; if forget about test
> frameworks for this proposal, it's all tangential.)

I agree with your reasoning here about having a separate Test stanza so that 
tests can be kept separate from the rest of the package.

- Greg

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

[Ivan Miljenovic]

On 7 April 2010 10:28, Thomas Tuegel  wrote:
> Ok, this is the bottom-line that I didn't understand after our first
> exchange, but I think now I do: I should entirely scrap the second
> aspect of my proposal and focus exclusively on making Cabal build and
> run test programs.

Just as a food for thought: how would you deal with test programs that
deal with user input?  Should "cabal test" only run those that are
automatic?

The reason I'm asking is that I'm developing a second test executable
for graphviz that checks if it can parse "real world" Dot files.  Now,
I could have it do a search for all .dot and .gv files on the machine
in question and try those, except not all of those might be Dot code
(just something with the same extension); as such the user has to
explicitly pass a list of filenames to the program.  This is thus more
of a guided test program rather than something that should be run
automatically.

Also, I'm not sure if this is come up yet in your proposal: what about
installation?  One thing that Sergei (aka trofi) is trying to add in
the Gentoo ebuilds for Haskell packages is something similar to this
where tests are optionally built and run; the problem is that if the
tests reside in an optional executable then the installation stage
will also install these test executables because Cabal has no way of
saying "build these but don't install them".  This is probably going
to be the case for your proposed project as well: should test
executables be installed?

-- 
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] what are the safety conditions for unsafeIOToST

[Roman Leshchinskiy]

On 07/04/2010, at 07:33, Nicolas Frisby wrote:

> I haven't been able to find it via Google or Haddock. An old message
> suggests is was just a matter of exceptions?

I don't think that's correct. You can implement unsafePerformIO in terms 
unsafeIOToST:

unsafePerformIO :: IO a -> a
unsafePerformIO p = runST (unsafeIOToST p)

In fact, the only safe-ish use for it I have found is to use Storable-related 
functions in ST, hoping that the instances don't actually use any real IO 
functionality. Arguably, this shouldn't be necessary as Storable should live in 
ST anyway.

> I only want to use the IO for generating Data.Uniques to pair with
> STRefs in order to make a map of them. I'm guessing this would be a
> safe use since it's exception free (... right?).

It's hard to tell without looking at your code. But if you are generating 
Uniques in ST then it's probably unsafe:

foo :: () -> Unique
foo _ = runST (unsafeIOToST newUnique)

What's the value of foo ()?

Roman


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

[Thomas Tuegel]

On Tue, Apr 6, 2010 at 7:43 PM, Rogan Creswick  wrote:
> test-framework and test-runner both address the second problem, and
> those solutions can be kept separate, at least for now.  Figuring out
> the best way to specify test commands, dependencies, build/execution
> order, etc. is going to take some substantial effort, and I think that
> should be the first goal of the project.

Ok, this is the bottom-line that I didn't understand after our first
exchange, but I think now I do: I should entirely scrap the second
aspect of my proposal and focus exclusively on making Cabal build and
run test programs.

> Cabal allows for multiple executable sections -- are multiple test
> sections allowed? If so, how are they handled when 'cabal test' is
> invoked?  If not, will there be any support for running multiple test
> suites? (more on this below).
>
> While the test executable could be configured to run different sets of
> tests (at runtime? hm.. we may need more flags to 'cabal test'), there
> are some situations it's necessary to build multiple test suites
> because of odd library dependencies.  (for example, testing certain
> combinations of libraries--imagine supporting multiple versions of
> ghc.)

I had intended to allow multiple 'Executable' sections; that's what I
meant by "this is really an 'Executable' stanza by another name".  I
think that takes care of your concern about building multiple test
suites with different dependencies, also.

My thinking is that 'cabal test' should run all the tests that were
built, and 'cabal test foo' should run only the test named 'foo'.

> The existing Executable sections may serve the need fine, if we could
> specify how to run the tests in a different way.  Perhaps a list of
> test commands could be specified instead, eg:
>
>> TestCommands: foo-test-ghc6.6,
>>                            foo-test-ghc6.8,
>>                            foo-props --all
>
> Anyhow, just food for thought.

One of the reasons I prefer implementing a dedicated 'Test' stanza is
that it makes it easier to tell which executables to install.  There
may be situations where we want to install test programs, but there
will _always_ be situations where we _don't_ want to.  (Maybe
'--{en,dis}able-tests' passed to 'cabal install' should control this?)
 Could we take a 'TestCommands' list and parse out the options to get
the executable names?  Yes, but relying on that to work makes me
uneasy.  I think the more robust way to specify executable-specific
options instead would be to add a field to the 'Test' section
('run-options' seems to be consistent with the naming scheme) that
doesn't exist in 'Executable'.

(I've snipped some of the comments here; if forget about test
frameworks for this proposal, it's all tangential.)

> See my comments about running multiple test suites, and parameterized
> test suites above.  I think richer parameters are necessary.
> (possibly just a --pass-through flag that hands all the subsequent
> parameters off to the test executable(s))

That is an excellent suggestion that I will definitely adopt in my
eventual proposal.

Thanks!
-- 
Thomas Tuegel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Haskell.org re-design

[Gregory Crosswhite]

I concur that the latest version with the softer colors looks a lot nicer, and 
I approve of the overall design.  I think that you should go back to using a 
change in the foreground color rather than the background color for the links 
in the main description, since at the moment it looks ugly.  I also think that 
it would look better if you could align the two columns in the top (i.e., the 
description text and the major links above the "News and Events" section) so 
that they align better with the two columns below;  you could probably also 
have the description text creep into the left margin so that it isn't exactly 
centered over the left column below, if that would look better.

Cheers,
Greg


On Apr 6, 2010, at 5:16 PM, Ivan Miljenovic wrote:

> On 7 April 2010 10:02, Thomas Schilling  wrote:
>> On 7 April 2010 00:57, Ivan Miljenovic  wrote:
>>> OK, I dislike the colour scheme.  Happy now? ;-)
>> 
>> That's still not constructive.  I.e, is it the black, the gray, the orange?
> 
> OK, it's the black; it seems a tad too strong for me (the fact that
> you have a black theme for your browser probably doesn't help).
> 
>> Using more intense colours for the bar at the top becomes distracting very 
>> quickly.
> 
> How about a more neutral, paler colour?
> 
>> Anyway, here's something with a bit more colour:  
>> http://i.imgur.com/LpQmH.png
> 
> Apart from the black up the top still, I think this is nicer.
> However, maybe the links in the description text up the top are a bit
> too obvious...
> 
> 
> -- 
> 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

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

[Gregory Crosswhite]

On Apr 6, 2010, at 4:40 PM, Thomas Tuegel wrote:

> Now, if you're telling me I'm going off in the wrong direction by
> proposing to integrate a test framework into Cabal itself, that's
> another story.  Should I pare down my proposal to only include support
> for a proper 'Test' stanza in the package description file and leave
> it at that?

Yes, I think that would be a better use of your time, and furthermore if you 
arrange this feature so that the programmer can use any test framework that 
they like, it has the advantage that you are not entrenching a particular way 
of combining tests from different modules.  If you want there to be 
communication between Cabal and the test suite, it should be something simple 
like passing in a location to where the test results should be output (or a 
flag indicating that they should be written to the screen in "verbose" mode), 
and having Cabal in return receive from the test runner a single string with a 
summary of the test results to show to the user (when in "summary" as opposed 
to "verbose" mode) and possibly a flag if there were any failures so that the 
user can be specifically alerted to this fact and pointed to the full test 
report.

Even if all you do is add systematic support for automatically building and 
running tests automatically as part of the build process, it would still be a 
major improvement;  it would be especially awesome if you made it possible to 
separate out the test framework dependencies from the package dependencies, 
since at the moment people who want to include tests with their package often 
feel the need to include dependencies on packages such as QuickCheck in order 
to make life easier for themselves, but if you could modify cabal so it would 
only pull in such packages when the user requests that tests be run it would be 
awesome!

Cheers,
Greg

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Haskell.org re-design

[Ivan Miljenovic]

On 7 April 2010 10:02, Thomas Schilling  wrote:
> On 7 April 2010 00:57, Ivan Miljenovic  wrote:
>> OK, I dislike the colour scheme.  Happy now? ;-)
>
> That's still not constructive.  I.e, is it the black, the gray, the orange?

OK, it's the black; it seems a tad too strong for me (the fact that
you have a black theme for your browser probably doesn't help).

> Using more intense colours for the bar at the top becomes distracting very 
> quickly.

How about a more neutral, paler colour?

> Anyway, here's something with a bit more colour:  http://i.imgur.com/LpQmH.png

Apart from the black up the top still, I think this is nicer.
However, maybe the links in the description text up the top are a bit
too obvious...


-- 
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: Haskell.org re-design

[Thomas Schilling]

On 7 April 2010 00:57, Ivan Miljenovic  wrote:
> On 7 April 2010 08:40, Thomas Schilling  wrote:
>> On 6 April 2010 22:39, Ivan Lazar Miljenovic  
>> wrote:
>>> I like the layout, but hate the colour scheme.
>>
>> Wow, "hate" is a very strong word.
>
> OK, I dislike the colour scheme.  Happy now? ;-)

That's still not constructive.  I.e, is it the black, the gray, the orange?

I played around with some more colours, but eg. blue link colour makes
the site feel too cold.  Using more intense colours for the bar at the
top becomes distracting very quickly.  A background other than white
is either hard to read, or highly dependent on the screen.  E.g., a
nice bright beige on one screen can look too yellowish on another
screen.

Anyway, here's something with a bit more colour:  http://i.imgur.com/LpQmH.png

/ Thomas
-- 
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] Re: Haskell.org re-design

[Ivan Miljenovic]

On 7 April 2010 08:40, Thomas Schilling  wrote:
> On 6 April 2010 22:39, Ivan Lazar Miljenovic  
> wrote:
>> I like the layout, but hate the colour scheme.
>
> Wow, "hate" is a very strong word.

OK, I dislike the colour scheme.  Happy now? ;-)

-- 
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: GSoC: Improving Cabal's Test Support

[Rogan Creswick]

On Tue, Apr 6, 2010 at 4:03 PM, Gregory Crosswhite
 wrote:
>
> Rather that starting from scratch, you should strongly consider adapting 
> something like test-framework to this task, as it already has done the heavy 
> work of creating a way to combine tests from different frameworks into a 
> single suite

I want to second this -- test-framework would be a good place to
start, and you would be able to accomplish quite a lot more during the
summer.  Your proposal addresses (at least!) two different problems:

  * updating cabal so that it can handle the build/test process; and,
  * combining HUnit / QuickCheck / etc. to present a uniform interface.

test-framework and test-runner both address the second problem, and
those solutions can be kept separate, at least for now.  Figuring out
the best way to specify test commands, dependencies, build/execution
order, etc. is going to take some substantial effort, and I think that
should be the first goal of the project.

More comments in-line below...

On Apr 6, 2010, at 3:51 PM, Thomas Tuegel wrote:
>    Package Description File Syntax
>
> The syntax for designating test executables in package description
> files will be based on the existing syntax for describing executables.
> Such a stanza in the hypothetical package's description file would
> look like:
>
>> Test foo-tests
>>    main-is: foo-tests.hs
>>    build-depends: haskell-foo, Cabal, QuickCheck
>
> This example is obviously minimal; this is really an 'Executable'
> stanza by another name, so any options recognized there would also be
> valid here.

Cabal allows for multiple executable sections -- are multiple test
sections allowed? If so, how are they handled when 'cabal test' is
invoked?  If not, will there be any support for running multiple test
suites? (more on this below).

While the test executable could be configured to run different sets of
tests (at runtime? hm.. we may need more flags to 'cabal test'), there
are some situations it's necessary to build multiple test suites
because of odd library dependencies.  (for example, testing certain
combinations of libraries--imagine supporting multiple versions of
ghc.)

The existing Executable sections may serve the need fine, if we could
specify how to run the tests in a different way.  Perhaps a list of
test commands could be specified instead, eg:

> TestCommands: foo-test-ghc6.6,
>foo-test-ghc6.8,
>foo-props --all

Anyhow, just food for thought.

> described by 'Executable' stanzas.  With tests enabled, the test
> programs will be executed and their results collected by Cabal during
> the 'test' stage.

Where are the results collected, and in what format? My preference is
to choose a sensible default (dist/test-results?) and allow it to be
overridden in the cabal file.

>> module Distribution.Test where
>>
>> type Name = String
>> type Result = Maybe Bool

I think you're reinventing the wheel a bit here, (see comments above
about test-framework).

That aside, Result is still too restrictive.  Ignored tests may well
need justification (why were they not run?).  There may also be
multiple ways to ignore tests, and it isn't clear to me what those
are, or which are important.

I also feel pretty strongly that Result should distinguish between
test failures and tests that failed due to exceptional circumstances.
I don't know of any frameworks that do this in Haskell yet, but it has
proven to be a useful distinction in other languages.

I'm not commenting on the rest of the framework proposal because I
don't think the point of this SoC project is to write another testing
framework.

> The 'cabal test' command will run tests by default, but support two
> other options:
>
>    1.  '--report [file]', which will produce a nicely formatted
> report of the test results stored in the named file, or of the last
> run of the package's test suite if no file is specified, and
>    2.  '--diff file1 file2', which will show the differences between
> the test results stored it two different files.

See my comments about running multiple test suites, and parameterized
test suites above.  I think richer parameters are necessary.
(possibly just a --pass-through flag that hands all the subsequent
parameters off to the test executable(s))

--Rogan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

[Thomas Tuegel]

On Tue, Apr 6, 2010 at 7:03 PM, Gregory Crosswhite
 wrote:
> Rather that starting from scratch, you should strongly consider adapting 
> something like test-framework to this task, as it already has done the heavy 
> work of creating a way to combine tests from different frameworks into a 
> single suite and includes such features as displaying a progress bar during 
> the QuickCheck tests.  Furthermore, it is easily extendable to support new 
> kinds of tests;  for example, I found that it was relatively straightforward 
> to add a new kind of "statistical" test to make sure that the average value 
> of a function where where it should be.
>

Thanks for the suggestion!  I've taken a hard look at test-framework
in particular already.  I like it, but the reason I haven't already
chosen to go with that is that it does a lot _more_ than I'm trying to
do here.  The way my proposal stands, whatever framework I go with
gets integrated with Cabal at least to the degree that Cabal can read
test results.  Rogan suggested that test-framework will shortly
support JUnit XML as an output format, so with the rest of my proposal
we'd be talking about adding an XML parsing library to Cabal's
dependencies.

Now, if you're telling me I'm going off in the wrong direction by
proposing to integrate a test framework into Cabal itself, that's
another story.  Should I pare down my proposal to only include support
for a proper 'Test' stanza in the package description file and leave
it at that?

Thanks!
-- 
Thomas Tuegel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Simple binary-protocol through network test

[Yves Parès]

Okay, so I turned off every buffering using hSetBuffering hdl NoBuffering on
both Client and Server, but I doesn't fix it...
BTW, I tried to do the same without your package, i.e. simply through Lazy
ByteString and Binary, but it doesn't work either, I come up against the
same issue.


Gregory Crosswhite-2 wrote:
> 
> Hmm, I am guessing it is more likely that the problem is that the I/O
> system changed from 6.10.4 to 6.12.1 somehow in a way that broke the
> package.  You could try turning off all buffering in the handle using
> hSetBuffering and seeing if that works.
> 
> Cheers,
> Greg
> 
> On Apr 6, 2010, at 3:44 PM, Yves Parès wrote:
> 
>> 
>> Weird...
>> 
>> I use GHC 6.12.1, and I run Ubuntu 9.10 (32bits version).
>> 
>> Would have I miss something? Like a flush or a close? Logically, I don't
>> see
>> where I would...
>> 
>> 
>> Gregory Crosswhite-2 wrote:
>>> 
>>> Yay, I'm glad to see someone else using my package.  :-)
>>> 
>>> Hmm, your program seems to work for me.  I compiled and ran the Server
>>> (with ghc --make), then compiled and ran the Client, and then typed
>>> 
>>> Operation 1.0 Mult 2.0
>>> 
>>> into the Client process, and the result it got was
>>> 
>>> 2.0
>>> 
>>> with the output
>>> 
>>> Just 2.0
>>> 
>>> on the Server.
>>> 
>>> I got the same results running this on Mac OSX and (Gentoo) Linux, with
>>> GHC 10.4.  What platform/GHC version are you running it on?
>>> 
>>> Cheers,
>>> Greg
>>> 
>>> On Apr 6, 2010, at 2:38 PM, Yves Parès wrote:
>>> 
 
 Hello,
 
 I'm trying to use the packages Network and Control.Monad.BinaryProtocol
 together, with a very simple program in which a client sends an
 operation
 to
 the server, which computes the result and sends it back.
 
 But the server holds when trying to receive (Server.hs, line 22),
 whereas
 the client has actually sent the data (Client.hs, line 17).
 The server stops to hold only when the client is killed with a Ctrl-C.
 
 This should be rather simple, and I can't get to know why it doesn't
 work.
 
 The files are here:
 http://old.nabble.com/file/p28157883/Client.hs Client.hs 
 http://old.nabble.com/file/p28157883/Server.hs Server.hs 
 http://old.nabble.com/file/p28157883/SharedData.hs SharedData.hs 
 
 -
 Yves Parès
 
 Live long and prosper
 -- 
 View this message in context:
 http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28157883.html
 Sent from the Haskell - Haskell-Cafe mailing list archive at
 Nabble.com.
 
 ___
 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
>>> 
>>> 
>> 
>> 
>> -
>> Yves Parès
>> 
>> Live long and prosper
>> -- 
>> View this message in context:
>> http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28158514.html
>> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
>> 
>> ___
>> 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
> 
> 


-
Yves Parès

Live long and prosper
-- 
View this message in context: 
http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28158761.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

[Gregory Crosswhite]

Rather that starting from scratch, you should strongly consider adapting 
something like test-framework to this task, as it already has done the heavy 
work of creating a way to combine tests from different frameworks into a single 
suite and includes such features as displaying a progress bar during the 
QuickCheck tests.  Furthermore, it is easily extendable to support new kinds of 
tests;  for example, I found that it was relatively straightforward to add a 
new kind of "statistical" test to make sure that the average value of a 
function where where it should be.

Cheers,
Greg

On Apr 6, 2010, at 3:51 PM, Thomas Tuegel wrote:

> Hello again!
> 
> Based on the invaluable feedback I've received, I've made some
> revisions to the proposal I made a few days ago (at the end of this
> post, after my signature).  I apologize for the length of my post, but
> I'd like once again to solicit feedback on this.  Any commentary is
> very helpful!
> 
> Thanks!
> -- 
> Thomas Tuegel
> 
> 
> Throughout this proposal, examples are given to indicate how a package
> author would utilize the features proposed here.  In all these
> examples, suppose that the programmer is the author of the
> 'haskell-foo' package, which exposes the module 'Foo' and has a single
> test executable, 'foo-tests', using the QuickCheck testing library.
> 
> 
>Package Description File Syntax
> 
> The syntax for designating test executables in package description
> files will be based on the existing syntax for describing executables.
> Such a stanza in the hypothetical package's description file would
> look like:
> 
>> Test foo-tests
>>main-is: foo-tests.hs
>>build-depends: haskell-foo, Cabal, QuickCheck
> 
> This example is obviously minimal; this is really an 'Executable'
> stanza by another name, so any options recognized there would also be
> valid here.
> 
> 
>Handling of Test Executables by Cabal
> 
> The changes proposed here will make it possible to build, test, and
> install a Cabal package with the usual sequence of commands:
> 
> $ cabal configure
> $ cabal build
> $ cabal test
> $ cabal install
> 
> Cabal will recognize two new options during the 'configure' stage:
> '--enable-tests' and '--disable-tests'.
> 
> If 'cabal configure' is invoked with the '--enable-tests' option, then
> any test executables designated in the package description file will
> be built.  For the purposes of the 'configure' and 'build' stages,
> they will be handled as if they were ordinary executables, i.e.,
> described by 'Executable' stanzas.  With tests enabled, the test
> programs will be executed and their results collected by Cabal during
> the 'test' stage.
> 
> If 'cabal configure' is invoked with the '--disable-tests' option
> (which should be the default if neither option is specified), then
> test executables designated in the package description file will be
> ignored, as if the 'Test' stanza were absent.  Any attempt to invoke
> the 'test' stage with tests disabled should remind the user of that
> fact.
> 
> Regardless of the status of tests (enabled or disabled), the 'install'
> stage will ignore any executables designated as test suites, since it
> is not desirable to install the test executables.
> 
> 
>Collection of Test Results
> 
> Cabal will provide a standard interface, residing in the module
> 'Distribution.Test', for running tests independent of the testing
> library used.  A minimal outline of this module looks like:
> 
>> module Distribution.Test where
>> 
>> type Name = String
>> type Result = Maybe Bool
>> type Info = String
>> type Output = String
>> 
>> -- 'Compiler' and 'ComponentLocalBuildInfo' are already provided by Cabal.
>> -- They are included here to aid in debugging test failures
>> type Report = (Compiler, ComponentLocalBuildInfo, [(Name, Result, Info, 
>> Output)])
>> 
>> class Test t where
>>wrap :: t -> IO (Result, Info)
>> 
>> runTests :: Test t => [(Name, t)] -> IO Report
>> 
>> writeResults :: Report -> IO ()
> 
> Instances of 'Test' will run a type of test from one of the testing
> libraries; part of this project will therefore be patching QuickCheck
> and HUnit to provide these instances.  Any other testing library
> providing this instance will also be compatible with the automated
> testing features this proposal introduces.
> 
> The type 'Maybe Bool' is used throughout this framework to indicate a
> test result: 'Nothing' indicates a test was not run, 'Just False'
> indicates a failed test, and 'Just True' indicates a successful test.
> The 'Info' string captures any information provided by the testing
> library.  However, because of the reliance of most test suites on
> standard output, Cabal will also capture the standard output produced
> during each test (when the test suite is invoked through 'cabal
> test'); the output will be included in the test result file.
> 
> The function 'writeResults' will write the test results to a file.
> The 'Show' instance for the type of its single a

Re: [Haskell-cafe] Why does Haskell not infer most general type?

[Ross Paterson]

On Tue, Apr 06, 2010 at 05:18:34PM -0400, Job Vranish wrote:
> So in Haskell 98, would the added constraints result in a type error?

Yes, because the types of the mutually recursive identifiers would be
inferred together without using the type signatures, and then would
fail to match the declared types.

But then there aren't any implementations of Haskell 98 to test this on.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Simple binary-protocol through network test

[Gregory Crosswhite]

Hmm, I am guessing it is more likely that the problem is that the I/O system 
changed from 6.10.4 to 6.12.1 somehow in a way that broke the package.  You 
could try turning off all buffering in the handle using hSetBuffering and 
seeing if that works.

Cheers,
Greg

On Apr 6, 2010, at 3:44 PM, Yves Parès wrote:

> 
> Weird...
> 
> I use GHC 6.12.1, and I run Ubuntu 9.10 (32bits version).
> 
> Would have I miss something? Like a flush or a close? Logically, I don't see
> where I would...
> 
> 
> Gregory Crosswhite-2 wrote:
>> 
>> Yay, I'm glad to see someone else using my package.  :-)
>> 
>> Hmm, your program seems to work for me.  I compiled and ran the Server
>> (with ghc --make), then compiled and ran the Client, and then typed
>> 
>>  Operation 1.0 Mult 2.0
>> 
>> into the Client process, and the result it got was
>> 
>>  2.0
>> 
>> with the output
>> 
>>  Just 2.0
>> 
>> on the Server.
>> 
>> I got the same results running this on Mac OSX and (Gentoo) Linux, with
>> GHC 10.4.  What platform/GHC version are you running it on?
>> 
>> Cheers,
>> Greg
>> 
>> On Apr 6, 2010, at 2:38 PM, Yves Parès wrote:
>> 
>>> 
>>> Hello,
>>> 
>>> I'm trying to use the packages Network and Control.Monad.BinaryProtocol
>>> together, with a very simple program in which a client sends an operation
>>> to
>>> the server, which computes the result and sends it back.
>>> 
>>> But the server holds when trying to receive (Server.hs, line 22), whereas
>>> the client has actually sent the data (Client.hs, line 17).
>>> The server stops to hold only when the client is killed with a Ctrl-C.
>>> 
>>> This should be rather simple, and I can't get to know why it doesn't
>>> work.
>>> 
>>> The files are here:
>>> http://old.nabble.com/file/p28157883/Client.hs Client.hs 
>>> http://old.nabble.com/file/p28157883/Server.hs Server.hs 
>>> http://old.nabble.com/file/p28157883/SharedData.hs SharedData.hs 
>>> 
>>> -
>>> Yves Parès
>>> 
>>> Live long and prosper
>>> -- 
>>> View this message in context:
>>> http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28157883.html
>>> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
>>> 
>>> ___
>>> 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
>> 
>> 
> 
> 
> -
> Yves Parès
> 
> Live long and prosper
> -- 
> View this message in context: 
> http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28158514.html
> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
> 
> ___
> 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: GSoC: Improving Cabal's Test Support

[Thomas Tuegel]

Hello again!

Based on the invaluable feedback I've received, I've made some
revisions to the proposal I made a few days ago (at the end of this
post, after my signature).  I apologize for the length of my post, but
I'd like once again to solicit feedback on this.  Any commentary is
very helpful!

Thanks!
-- 
Thomas Tuegel


Throughout this proposal, examples are given to indicate how a package
author would utilize the features proposed here.  In all these
examples, suppose that the programmer is the author of the
'haskell-foo' package, which exposes the module 'Foo' and has a single
test executable, 'foo-tests', using the QuickCheck testing library.


Package Description File Syntax

The syntax for designating test executables in package description
files will be based on the existing syntax for describing executables.
 Such a stanza in the hypothetical package's description file would
look like:

> Test foo-tests
> main-is: foo-tests.hs
> build-depends: haskell-foo, Cabal, QuickCheck

This example is obviously minimal; this is really an 'Executable'
stanza by another name, so any options recognized there would also be
valid here.


Handling of Test Executables by Cabal

The changes proposed here will make it possible to build, test, and
install a Cabal package with the usual sequence of commands:

$ cabal configure
$ cabal build
$ cabal test
$ cabal install

Cabal will recognize two new options during the 'configure' stage:
'--enable-tests' and '--disable-tests'.

If 'cabal configure' is invoked with the '--enable-tests' option, then
any test executables designated in the package description file will
be built.  For the purposes of the 'configure' and 'build' stages,
they will be handled as if they were ordinary executables, i.e.,
described by 'Executable' stanzas.  With tests enabled, the test
programs will be executed and their results collected by Cabal during
the 'test' stage.

If 'cabal configure' is invoked with the '--disable-tests' option
(which should be the default if neither option is specified), then
test executables designated in the package description file will be
ignored, as if the 'Test' stanza were absent.  Any attempt to invoke
the 'test' stage with tests disabled should remind the user of that
fact.

Regardless of the status of tests (enabled or disabled), the 'install'
stage will ignore any executables designated as test suites, since it
is not desirable to install the test executables.


Collection of Test Results

Cabal will provide a standard interface, residing in the module
'Distribution.Test', for running tests independent of the testing
library used.  A minimal outline of this module looks like:

> module Distribution.Test where
>
> type Name = String
> type Result = Maybe Bool
> type Info = String
> type Output = String
>
> -- 'Compiler' and 'ComponentLocalBuildInfo' are already provided by Cabal.
> -- They are included here to aid in debugging test failures
> type Report = (Compiler, ComponentLocalBuildInfo, [(Name, Result, Info, 
> Output)])
>
> class Test t where
> wrap :: t -> IO (Result, Info)
>
> runTests :: Test t => [(Name, t)] -> IO Report
>
> writeResults :: Report -> IO ()

Instances of 'Test' will run a type of test from one of the testing
libraries; part of this project will therefore be patching QuickCheck
and HUnit to provide these instances.  Any other testing library
providing this instance will also be compatible with the automated
testing features this proposal introduces.

The type 'Maybe Bool' is used throughout this framework to indicate a
test result: 'Nothing' indicates a test was not run, 'Just False'
indicates a failed test, and 'Just True' indicates a successful test.
The 'Info' string captures any information provided by the testing
library.  However, because of the reliance of most test suites on
standard output, Cabal will also capture the standard output produced
during each test (when the test suite is invoked through 'cabal
test'); the output will be included in the test result file.

The function 'writeResults' will write the test results to a file.
The 'Show' instance for the type of its single argument will therefore
constitute the standard test result file format.  This has the
advantage of being human- and machine-readable without requiring any
extra dependencies to parse the file.

With this framework, the hypothetical package's author might write a
test suite such as:

> module Main where
>
> import Distribution.Test
> import Foo
> import QuickCheck
>
> testBar :: Gen Bool
> testBar = ...
>
> testBaz :: Gen Bool
> testBaz = ...
>
> main = runTests [("testBar", testBar), ("testBaz", testBaz)] >>= writeResults


Reporting and Comparing Test Results

The 'cabal test' command will run tests by default, but support two
other options:

1.  '--report [file]', which will produce a nicely formatted
report of the test results stored in the named file, or of the last
run of the package's test suite if no file is spe

[Haskell-cafe] [haskell.org Google Summer of Code] Student Applications Due Friday!

[Edward Kmett]

This is a friendly reminder that student applications for the summer of code
are due to Google by Friday, April 9th.
http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/timeline

That is just *3 days* from now!

Keep in mind that while we've been tracking general interest in different
projects through the trac, the application doesn't count unless you submit
it to Google at
http://socghop.appspot.com/gsoc/program/home/google/gsoc2010

While all details of the application do not need to be finalized, as much of
the information from
http://hackage.haskell.org/trac/summer-of-code/wiki/StudApply2010
as possible should probably be included in your application.

If you are stuck and having a hard time thinking of ideas, I highly
recommend the excellent guide that Don Stewart posted recently:
http://donsbot.wordpress.com/2010/04/01/the-8-most-important-haskell-org-gsoc-projects/

I'd also recommend taking a look through the trac at
http://hackage.haskell.org/trac/summer-of-code/report/1
to gauge interest.

Please email me if you have any questions or concerns.

-Edward Kmett
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Simple binary-protocol through network test

[Yves Parès]

Weird...

I use GHC 6.12.1, and I run Ubuntu 9.10 (32bits version).

Would have I miss something? Like a flush or a close? Logically, I don't see
where I would...


Gregory Crosswhite-2 wrote:
> 
> Yay, I'm glad to see someone else using my package.  :-)
> 
> Hmm, your program seems to work for me.  I compiled and ran the Server
> (with ghc --make), then compiled and ran the Client, and then typed
> 
>   Operation 1.0 Mult 2.0
> 
> into the Client process, and the result it got was
> 
>   2.0
> 
> with the output
> 
>   Just 2.0
> 
> on the Server.
> 
> I got the same results running this on Mac OSX and (Gentoo) Linux, with
> GHC 10.4.  What platform/GHC version are you running it on?
> 
> Cheers,
> Greg
> 
> On Apr 6, 2010, at 2:38 PM, Yves Parès wrote:
> 
>> 
>> Hello,
>> 
>> I'm trying to use the packages Network and Control.Monad.BinaryProtocol
>> together, with a very simple program in which a client sends an operation
>> to
>> the server, which computes the result and sends it back.
>> 
>> But the server holds when trying to receive (Server.hs, line 22), whereas
>> the client has actually sent the data (Client.hs, line 17).
>> The server stops to hold only when the client is killed with a Ctrl-C.
>> 
>> This should be rather simple, and I can't get to know why it doesn't
>> work.
>> 
>> The files are here:
>> http://old.nabble.com/file/p28157883/Client.hs Client.hs 
>> http://old.nabble.com/file/p28157883/Server.hs Server.hs 
>> http://old.nabble.com/file/p28157883/SharedData.hs SharedData.hs 
>> 
>> -
>> Yves Parès
>> 
>> Live long and prosper
>> -- 
>> View this message in context:
>> http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28157883.html
>> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
>> 
>> ___
>> 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
> 
> 


-
Yves Parès

Live long and prosper
-- 
View this message in context: 
http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28158514.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Haskell.org re-design

[Thomas Schilling]

On 6 April 2010 22:39, Ivan Lazar Miljenovic  wrote:
> Thomas Schilling  writes:
>
>> Another attempt:  http://i.imgur.com/ENvl7.png
>
> I like the layout, but hate the colour scheme.

Wow, "hate" is a very strong word.  In any case, though, I'm pretty
sure it'll be impossible to please everyone.  FWIW, I used this:
http://www.colourlovers.com/palette/694737/Thought_Provoking

If we can agree on the general layout, though, I can create some
colour scheme variants.  I know this stuff is very subjective, but I
would appreciate constructive feedback.

/ Thomas
-- 
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] Simple binary-protocol through network test

[Gregory Crosswhite]

Yay, I'm glad to see someone else using my package.  :-)

Hmm, your program seems to work for me.  I compiled and ran the Server (with 
ghc --make), then compiled and ran the Client, and then typed

Operation 1.0 Mult 2.0

into the Client process, and the result it got was

2.0

with the output

Just 2.0

on the Server.

I got the same results running this on Mac OSX and (Gentoo) Linux, with GHC 
10.4.  What platform/GHC version are you running it on?

Cheers,
Greg

On Apr 6, 2010, at 2:38 PM, Yves Parès wrote:

> 
> Hello,
> 
> I'm trying to use the packages Network and Control.Monad.BinaryProtocol
> together, with a very simple program in which a client sends an operation to
> the server, which computes the result and sends it back.
> 
> But the server holds when trying to receive (Server.hs, line 22), whereas
> the client has actually sent the data (Client.hs, line 17).
> The server stops to hold only when the client is killed with a Ctrl-C.
> 
> This should be rather simple, and I can't get to know why it doesn't work.
> 
> The files are here:
> http://old.nabble.com/file/p28157883/Client.hs Client.hs 
> http://old.nabble.com/file/p28157883/Server.hs Server.hs 
> http://old.nabble.com/file/p28157883/SharedData.hs SharedData.hs 
> 
> -
> Yves Parès
> 
> Live long and prosper
> -- 
> View this message in context: 
> http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28157883.html
> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
> 
> ___
> 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] Re: Haskell.org re-design

[Ivan Lazar Miljenovic]

Thomas Schilling  writes:

> Another attempt:  http://i.imgur.com/ENvl7.png

I like the layout, but hate the colour scheme.

-- 
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

[Haskell-cafe] Simple binary-protocol through network test

[Yves Parès]

Hello,

I'm trying to use the packages Network and Control.Monad.BinaryProtocol
together, with a very simple program in which a client sends an operation to
the server, which computes the result and sends it back.

But the server holds when trying to receive (Server.hs, line 22), whereas
the client has actually sent the data (Client.hs, line 17).
The server stops to hold only when the client is killed with a Ctrl-C.

This should be rather simple, and I can't get to know why it doesn't work.

The files are here:
http://old.nabble.com/file/p28157883/Client.hs Client.hs 
http://old.nabble.com/file/p28157883/Server.hs Server.hs 
http://old.nabble.com/file/p28157883/SharedData.hs SharedData.hs 

-
Yves Parès

Live long and prosper
-- 
View this message in context: 
http://old.nabble.com/Simple-binary-protocol-through-network-test-tp28157883p28157883.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Established names for a couple of list functionals?

[Ivan Lazar Miljenovic]

Stephen Tetley  writes:
> -- first element special
> --
> anacrusisMap :: (a -> b) -> (a -> b) -> [a] -> [b]
> anacrusisMap _ _ [] = []
> anacrusisMap f g (a:as) = f a : map g as

I've done something like this, and gave it the extremely imaginative
name of firstOthers.  But it was an internal non-exported function.

-- 
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

[Haskell-cafe] what are the safety conditions for unsafeIOToST

[Nicolas Frisby]

I haven't been able to find it via Google or Haddock. An old message
suggests is was just a matter of exceptions?

I only want to use the IO for generating Data.Uniques to pair with
STRefs in order to make a map of them. I'm guessing this would be a
safe use since it's exception free (... right?).

Thanks!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Why does Haskell not infer most general type?

[John Meacham]

On Tue, Apr 06, 2010 at 03:56:32PM -0400, Job Vranish wrote:
> Why does haskell not infer the most general type for these functions? Is it
> a limitation of the algorithm? a limitation of the recursive let binding?
> 
> Any insight would be appreciated :)

This is due to when Haskell does generalizing, first, the definitions
are broken up into strongly connected components based on their
dependencies. Then, in dependency order, the components are type checked
then generalized and the result is added to the environment and made
available to further typechecking. Notably the types are set in stone at
this point and should be the most general they can be.

So what is going on here is that your two function f and y depend on
each other so are part of the same binding group and hence typecheckd
together. this causes y's unknown type to be unified with its use in f,
giving it the more specific Int -> Int type, even though it could be
assigned a more general one.

This is what should happen according to the haskell standard, however,
it was pointed out in the typing haskell in haskell paper that this is
more strict than neccessary, we can furuther split up the binding group
based on 'type dependency' as in, if g and h call each other and g has
an explicit signature, then h need not be considered to depend on it as
the explicit type for g can just be added to the envirornment. When
determining binding groups, we can ignore dependencies through explicit
types effecitively. This was proposed as an extension to haskell 98 in
the THIH paper, and is generally considederd a good idea.

What you have here is a more pathological variation on that, while y
doesn't have an explicit signature, it is used with an explicit one in
f, hence one could theoretically subdivide the binding group, typing f
alone, getting its most general type, then typing y, then going back and
verifying y's use in f is valid. It is ceratinly possible to come up
with a specification for an extended type inference algorithm such as
this, but whether it is worth it is another matter.

John


-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Why does Haskell not infer most general type?

[Thomas Schilling]

Yes, it has to do with mutually recursive bindings.  If you add a type
signature, you break the mutual recursion.  Mutually recursive
functions are type-checked together and then generalised.  Similarly,
polymorphic recursion cannot be inferred either, but is possible by
adding a type signature.

HTH

On 6 April 2010 20:56, Job Vranish  wrote:
>
> Is haskell supposed to always infer the most general type (barring
> extensions)?
>
> I found a simple case where this is not true:
>
> f _ = undefined
>   where
>     _ = y :: Int -> Int
>
> y x = undefined
>   where
>     _ = f x
>
> Haskell infers the types of 'y' and 'f' as:
> f :: Int -> a
> y :: Int -> Int
>
> This confused me at first, but after thinking about it a while it seemed to
> make sense. But then my friend John pointed out that you can add type sigs
> for 'f' and 'y':
> f :: a -> b
> y :: a -> b
> and have it still typecheck!
>
> This thoroughly confused me.
>
> Why does haskell not infer the most general type for these functions? Is it
> a limitation of the algorithm? a limitation of the recursive let binding?
>
> Any insight would be appreciated :)
>
> - Job
>
>
> ___
> 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] Why does Haskell not infer most general type?

[Job Vranish]

So in Haskell 98, would the added constraints result in a type error?

- Job

On Tue, Apr 6, 2010 at 5:12 PM, Ross Paterson  wrote:

> On Tue, Apr 06, 2010 at 03:56:32PM -0400, Job Vranish wrote:
> > f _ = undefined
> >   where
> > _ = y :: Int -> Int
> >
> > y x = undefined
> >   where
> > _ = f x
>
> Because f and y are mutually recursive, their types are inferred together,
> so y gets the type Int -> Int (as given), which forces f :: Int -> a.
>
> If you add the type signature f :: a -> b, you break the cycle: that
> type is used in inferring the type of y (namely a -> b), which is then
> used in checking the typeof f.  Ditto if you add y :: a -> b instead.
> (This is not Haskell 98, but the implementations have done this for
> years, and it will be in Haskell 2010.)
> ___
> 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] Why does Haskell not infer most general type?

[Ross Paterson]

On Tue, Apr 06, 2010 at 03:56:32PM -0400, Job Vranish wrote:
> f _ = undefined
>   where
> _ = y :: Int -> Int
> 
> y x = undefined
>   where
> _ = f x

Because f and y are mutually recursive, their types are inferred together,
so y gets the type Int -> Int (as given), which forces f :: Int -> a.

If you add the type signature f :: a -> b, you break the cycle: that
type is used in inferring the type of y (namely a -> b), which is then
used in checking the typeof f.  Ditto if you add y :: a -> b instead.
(This is not Haskell 98, but the implementations have done this for
years, and it will be in Haskell 2010.)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Announce: hothasktags

[Erlend Hamberg]

On Thursday 1. April 2010 22.46.47 Luke Palmer wrote:
> 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

Thanks for this. Seems to be working very nicely. :-)

-- 
Erlend Hamberg
“Everything will be ok in the end. If its not ok, its not the end.”
GPG/PGP:  0xAD3BCF19
45C3 E2E7 86CA ADB7 8DAD 51E7 3A1A F085 AD3B CF19
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Established names for a couple of list functionals?

[Stephen Tetley]

Hello all


Having traversals with special behaviour for the first or last element
is useful for my current work:

-- first element special
--
anacrusisMap :: (a -> b) -> (a -> b) -> [a] -> [b]
anacrusisMap _ _ [] = []
anacrusisMap f g (a:as) = f a : map g as

-- last element special
--
cabooseMap :: (a -> b) -> (a -> b) -> [a] -> [b]
cabooseMap _ _ [] = []
cabooseMap f g (a:as) = step a as where
  step x []   = [g x]
  step x (y:ys)   = f x : step y ys


*Overlay1> anacrusisMap (+1) id [1..10]
[2,2,3,4,5,6,7,8,9,10]

*Overlay1> cabooseMap id (+1) [1..10]
[1,2,3,4,5,6,7,8,9,11]

My question (trivial, but still...) - is there any prior art naming
these functions?

For the record, my name derivation is:

+ anacrusis - musical term, the pickup notes before the first bar in a score.

+ caboose - there was discussion on Haskell-Cafe a couple of months
ago about a list data type with a distinguished terminal type. Caboose
is the name I remember.



Thanks

Stephen
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Why does Haskell not infer most general type?

[Edward Z. Yang]

Excerpts from Brandon S. Allbery KF8NH's message of Tue Apr 06 16:46:28 -0400 
2010:
> On Apr 6, 2010, at 15:56 , Job Vranish wrote:
> > Is haskell supposed to always infer the most general type (barring  
> > extensions)?
> Look up the monomorphism restriction.

Hey Brandon,

I tested the code with -XNoMonomorphismRestriction and it still inferred
the specific type, so perhaps this is either a GHC bug or something
different?  wnoise also points out that both functions take arguments,
so the monomorphism restriction doesn't apply.

See: 
http://www.reddit.com/r/haskell/comments/bn9to/type_checker_trivia_what_are_the_types_of_f_and_y/

Cheers,
Edward
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Why does Haskell not infer most general type?

[John Van Enk]

I don't believe that the monomorphism restriction has anything to do with
this. Removing it does not generalize the type.

On Tue, Apr 6, 2010 at 4:46 PM, Brandon S. Allbery KF8NH <
allb...@ece.cmu.edu> wrote:

> On Apr 6, 2010, at 15:56 , Job Vranish wrote:
>
> Is haskell supposed to always infer the most general type (barring
> extensions)?
>
>
> Look up the monomorphism restriction.
>
> --
> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
> system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
> electrical and computer engineering, carnegie mellon universityKF8NH
>
>
>
> ___
> 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] Why does Haskell not infer most general type?

[Brandon S. Allbery KF8NH]

On Apr 6, 2010, at 15:56 , Job Vranish wrote:
Is haskell supposed to always infer the most general type (barring  
extensions)?



Look up the monomorphism restriction.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Haskell.org re-design

[Thomas Schilling]

Here's a matching Wiki style:  http://i.imgur.com/XkuzH.png

On 6 April 2010 20:35, Max Bolingbroke  wrote:
> This is a very nice design. However shouldn't other pages e.g. the
> wiki template be redesigning to match as well? If this is not going to
> happen, then I would almost prefer sticking to the current design for
> consistency's sake.
>
> On 6 April 2010 20:11, Thomas Schilling  wrote:
>> Another attempt:  http://i.imgur.com/ENvl7.png
>>
>> On 6 April 2010 10:36, Johan Tibell  wrote:
>>> On Tue, Apr 6, 2010 at 5:24 AM, Simon Michael  wrote:
 On 4/2/10 5:28 AM, Thomas Schilling wrote:
>
> How about something more colourful?
>
> http://i.imgur.com/7jCPq.png
>>>
>>> I really like the simplicity of the Cassandra page:
>>>
>>> http://cassandra.apache.org/
>>> ___
>>> 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
>>
>>
>



-- 
Push the envelope.  Watch it bend.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Why does Haskell not infer most general type?

[Job Vranish]

Is haskell supposed to always infer the most general type (barring
extensions)?

I found a simple case where this is not true:

f _ = undefined
  where
_ = y :: Int -> Int

y x = undefined
  where
_ = f x

Haskell infers the types of 'y' and 'f' as:
f :: Int -> a
y :: Int -> Int

This confused me at first, but after thinking about it a while it seemed to
make sense. But then my friend John pointed out that you can add type sigs
for 'f' and 'y':
f :: a -> b
y :: a -> b
and have it still typecheck!

This thoroughly confused me.

Why does haskell not infer the most general type for these functions? Is it
a limitation of the algorithm? a limitation of the recursive let binding?

Any insight would be appreciated :)

- Job
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Haskell.org re-design

[Max Bolingbroke]

This is a very nice design. However shouldn't other pages e.g. the
wiki template be redesigning to match as well? If this is not going to
happen, then I would almost prefer sticking to the current design for
consistency's sake.

On 6 April 2010 20:11, Thomas Schilling  wrote:
> Another attempt:  http://i.imgur.com/ENvl7.png
>
> On 6 April 2010 10:36, Johan Tibell  wrote:
>> On Tue, Apr 6, 2010 at 5:24 AM, Simon Michael  wrote:
>>> On 4/2/10 5:28 AM, Thomas Schilling wrote:

 How about something more colourful?

 http://i.imgur.com/7jCPq.png
>>
>> I really like the simplicity of the Cassandra page:
>>
>> http://cassandra.apache.org/
>> ___
>> 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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: GSOC Haskell Project

[Mihai Maruseac]

Oops, forgot to add the third link: my homepage is at
http://people.rosedu.org/people/mihai_maruseac

On Tue, Apr 6, 2010 at 10:11 PM, Mihai Maruseac
 wrote:
> Hello again
>
> Following a feedback (courtesy of lispy) of my proposal on #haskell, I
> come to complete it with some bits here and there.
>
> First, a short analysis on the impact that this tool will have on the
> community. I now that right now there are plenty of clever tricks for
> debugging your code, even if it involves FFI calls or Monad
> Transformers Stacks but no one trick is a silver bullet. As far as I
> know, there is no trick which works the same way both for FFI or
> Arrows. However, having a backtrace will really help in any domain,
> from DSLs to FRP and Category Theory constructs. It will help also the
> beginner average Joe starting to program in Haskell and the senior PhD
> doctor Bob from the University. The later will be helped by seeing
> what part of his code is responsible for an unexpected failure while
> the former will recognize the stack traces he saw in gdb and other
> imperative programming languages.
>
> The second completion that I want to do is to give some more details
> on the timeline. Between May 26 and first of June I will contact Simon
> Peyton Joynes and his coautors to see how I will integrate will their
> code base, what are their policies to integrating patches, what
> repository they use, etc. This is to ensure continual integration,
> such that every day there will be a version of the tool which can be
> built on any machine and used for debugging your own code. Moreover, I
> will talk to them during this timeframe to convince myself whether the
> idea of a HPC-like rewrite is good or I should stick with the existing
> one. If later, this would be all that I'll be doing during this
> period, otherwise, I'll try to refactor the existing rewrite to the
> HPC-like one during this timeframe and during one more week after that
> (that is, until 6th of June). Last but not least, this timeframe must
> be used to prove several proof of concept snapshots of the debugger,
> in both variants for public feedback and further guidance
>
> Between 1st and 14th of June I will integrate higher-order functions
> and typeclasses into the debugger. If choosing to do a HPC-like
> rewrite only the higher order functions would be integrated until 14th
> of June.
>
> However, until 1st of July I will have both higher-order functions and
> typeclasses inserted into the debugger, the period between 14th and
> 30th being a buffered period for cases where I'll get stuck and fall
> behind the timeline.
>
> In July, the first week will be dedicated to integrating CAFs while
> the second one will be for cross module debugging providing options to
> debug only certain modules while ignoring others (assuming that they
> are correct). A new buffering period will be between 14th of July and
> 1st of August, a period which will be used to ensure that all parts
> will be integrated well and will work in a non-buggy way.
>
> The month of August is dedicated to community suggested improvements.
> Through a series of stress tests or simple tests this debugger will
> show its strength and its bugs. The former will be praised while the
> later will be solved during this timeframe and after the GSoC period.
>
> Next, some details about my haskell development skills. If the code
> snippets found in my blog[1] are not so relevant, maybe a link to the
> latest project developed in Haskell will help[2]. The project was
> supposed to be a rewrite of Berkley's esspresso program allowing both
> for logic expression minimization and for automatic drawing of gates.
> Lately, we stopped working on it because we couldn't find a good
> working example of it's utility. To add more to my level of Haskell
> knowledge, I may say that I am teaching programming paradigms at my
> university as a teaching assistant (students are allowed to do so if
> they have a very solid knowledge of the subject and a very good
> extra-curricular open-source/contest activity) and one quarter of the
> course is held in Haskell (though this year will be the first when we
> will teach Monads to the students, starting from one of my ideas).
> Lastly, I've read books on Haskell and right now I am trying to grasp
> Category Theory by reading Awodey's book. Moreover, I have the full
> journal of functional programming articles downloaded on my laptop.
>
> As for the community integration, I am one of the most active ROSEdu
> members here, taking part in almost any activity that we develop. I am
> project manager for one Tech Talks activity and I intend to give a
> talk on side effects during the next month. More info can be found by
> reading my homepage[3].
>
> Thanks for the patience for reading another long email. Please, do
> give some feedback to help me create a better application.
>
> Not really useful PS: I am thinking to chose a graduation license
> software project on Haskell 

Re: [Haskell-cafe] Re: Haskell.org re-design

[Thomas Schilling]

Another attempt:  http://i.imgur.com/ENvl7.png

On 6 April 2010 10:36, Johan Tibell  wrote:
> On Tue, Apr 6, 2010 at 5:24 AM, Simon Michael  wrote:
>> On 4/2/10 5:28 AM, Thomas Schilling wrote:
>>>
>>> How about something more colourful?
>>>
>>> http://i.imgur.com/7jCPq.png
>
> I really like the simplicity of the Cassandra page:
>
> http://cassandra.apache.org/
> ___
> 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] Re: GSOC Haskell Project

[Mihai Maruseac]

Hello again

Following a feedback (courtesy of lispy) of my proposal on #haskell, I
come to complete it with some bits here and there.

First, a short analysis on the impact that this tool will have on the
community. I now that right now there are plenty of clever tricks for
debugging your code, even if it involves FFI calls or Monad
Transformers Stacks but no one trick is a silver bullet. As far as I
know, there is no trick which works the same way both for FFI or
Arrows. However, having a backtrace will really help in any domain,
from DSLs to FRP and Category Theory constructs. It will help also the
beginner average Joe starting to program in Haskell and the senior PhD
doctor Bob from the University. The later will be helped by seeing
what part of his code is responsible for an unexpected failure while
the former will recognize the stack traces he saw in gdb and other
imperative programming languages.

The second completion that I want to do is to give some more details
on the timeline. Between May 26 and first of June I will contact Simon
Peyton Joynes and his coautors to see how I will integrate will their
code base, what are their policies to integrating patches, what
repository they use, etc. This is to ensure continual integration,
such that every day there will be a version of the tool which can be
built on any machine and used for debugging your own code. Moreover, I
will talk to them during this timeframe to convince myself whether the
idea of a HPC-like rewrite is good or I should stick with the existing
one. If later, this would be all that I'll be doing during this
period, otherwise, I'll try to refactor the existing rewrite to the
HPC-like one during this timeframe and during one more week after that
(that is, until 6th of June). Last but not least, this timeframe must
be used to prove several proof of concept snapshots of the debugger,
in both variants for public feedback and further guidance

Between 1st and 14th of June I will integrate higher-order functions
and typeclasses into the debugger. If choosing to do a HPC-like
rewrite only the higher order functions would be integrated until 14th
of June.

However, until 1st of July I will have both higher-order functions and
typeclasses inserted into the debugger, the period between 14th and
30th being a buffered period for cases where I'll get stuck and fall
behind the timeline.

In July, the first week will be dedicated to integrating CAFs while
the second one will be for cross module debugging providing options to
debug only certain modules while ignoring others (assuming that they
are correct). A new buffering period will be between 14th of July and
1st of August, a period which will be used to ensure that all parts
will be integrated well and will work in a non-buggy way.

The month of August is dedicated to community suggested improvements.
Through a series of stress tests or simple tests this debugger will
show its strength and its bugs. The former will be praised while the
later will be solved during this timeframe and after the GSoC period.

Next, some details about my haskell development skills. If the code
snippets found in my blog[1] are not so relevant, maybe a link to the
latest project developed in Haskell will help[2]. The project was
supposed to be a rewrite of Berkley's esspresso program allowing both
for logic expression minimization and for automatic drawing of gates.
Lately, we stopped working on it because we couldn't find a good
working example of it's utility. To add more to my level of Haskell
knowledge, I may say that I am teaching programming paradigms at my
university as a teaching assistant (students are allowed to do so if
they have a very solid knowledge of the subject and a very good
extra-curricular open-source/contest activity) and one quarter of the
course is held in Haskell (though this year will be the first when we
will teach Monads to the students, starting from one of my ideas).
Lastly, I've read books on Haskell and right now I am trying to grasp
Category Theory by reading Awodey's book. Moreover, I have the full
journal of functional programming articles downloaded on my laptop.

As for the community integration, I am one of the most active ROSEdu
members here, taking part in almost any activity that we develop. I am
project manager for one Tech Talks activity and I intend to give a
talk on side effects during the next month. More info can be found by
reading my homepage[3].

Thanks for the patience for reading another long email. Please, do
give some feedback to help me create a better application.

Not really useful PS: I am thinking to chose a graduation license
software project on Haskell though I haven't yet selected a theme and
a domain.

[1]: http://pgraycode.wordpress.com
[2]: http://dev.rosedu.org/xpresso/browser/trunk

-- 
Mihai Maruseac

On Mon, Apr 5, 2010 at 8:26 PM, Mihai Maruseac  wrote:
> Hello haskellers (men and women)!
>
> I had an idea about a graphical debugger for Haskell but it h

Re: [Haskell-cafe] Re: HXT Namespaces and XPath

[Mads Lindstrøm]

Hi

Replying to myself:


> I think another example will clarify my point. The code:
> 
> simpleXmlOne, simpleXmlTwo :: String
> simpleXmlOne = "http://foo.org\"/>"
> simpleXmlTwo = "http://foo.org\"/>"
> 
> nsEnv :: [(String, String)]
> nsEnv = [ ("notFoo", "http://notfoo.org";) ]
> 
> evalXPath :: String -> [XmlTree]
> evalXPath xml =
>   runLA ( xread
>   >>> propagateNamespaces
>   >>> getXPathTreesWithNsEnv nsEnv "//a:Foo"
> ) xml
> 
> Now notice that simpleXmlOne and simpleXmlTwo are equivalent. Yes, they
> have a different prefix for "http://foo.org";, but the documents means
> the same. And as you write yourself, "... the prefix is no longer
> releavant ..." Yet:
> 
> evalXPath simpleXmlOne /= evalXPath simpleXmlTwo
> 

Just to clarify things. The point I am making is that:

getXPathTreesWithNsEnv nsEnv "//a:Foo"

do not only see the prefixes in 'nsEnv', but also the prefixes in the
XML it is applied to. I think that the getXPathTreesWithNsEnv function
should only see the prefixes mentioned in its first parameter.


Regards,

Mads



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: HXT error handling

[Uwe Schmidt]

Hi Mads,


> > This is a right point. Here the current XPath calling interface is too 
> > simple.
> > A separation into XPath parsing and evaluation would be more flexible.
> > The parsing (and error handling of XPath syntax errors) could be done once.
> > I will extend the interface to support this.
> 
> That would be great. Thank you.

just uploaded hxt-xpath-8.5.3 to hackage.
But haddock doc is not yet available on hackage.

Cheers,

Uwe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: HXT Namespaces and XPath

[Mads Lindstrøm]

Hi Uwe

I read your reply multiple times, but I am still confused. I think
either I misunderstand you or I did not explain myself properly in the
first mail.

> Hi Mads,
> 
> > In HXT, namespace prefixes bound by an XML document are valid in the
> > context of an XPath. How do avoid that?
> > 
> > An example program will clarify:
> > 
> > simpleXml :: String
> > simpleXml = " > xmlns:soap=\"http://www.w3.org/2003/05/soap-envelope\"/>"
> > 
> > nsEnv :: [(String, String)]
> > nsEnv = [ ("s", "http://www.w3.org/2003/05/soap-envelope";) ]
> > 
> > evalXPath :: String -> String -> [XmlTree]
> > evalXPath xpath xml =
> >   runLA ( xread
> >   >>> propagateNamespaces
> >   >>> getXPathTreesWithNsEnv nsEnv xpath
> > ) xml
> > 
> > Here:
> > 
> > evalXPath "//s:Body" simpleXml ==
> > evalXPath "//soap:Body" simpleXml
> > 
> > Even though I only mentions the prefix "s" (and not "soap") in the
> > function nsEnv.
> 
> When working with namespaces in XML, the prefixes are not longer significant.
> After namespace propagation every name in the XML document is identified
> by a qualified name. This is a pair consisting of the namespace URI and the 
> local part.
> The prefixes become irrelevant.

This is my point. Prefixes are relevant in the current implementation of
HXT.

> A namespace aware XPath expression needs a namespace environment,
> as given in the example, to construct these qualified names for the names
> in the XPath expression.
> So the results of both evalXPath calls in your example must be the same. 

Yes, but in the namespace environment I give to getXPathTreesWithNsEnv I
only mention the prefix s, yet I am still able to evaluate the xpath
"//soap:Body". Furthermore "//s:body" and "//soap:Body" gives the same
results. Why?

I think another example will clarify my point. The code:

simpleXmlOne, simpleXmlTwo :: String
simpleXmlOne = "http://foo.org\"/>"
simpleXmlTwo = "http://foo.org\"/>"

nsEnv :: [(String, String)]
nsEnv = [ ("notFoo", "http://notfoo.org";) ]

evalXPath :: String -> [XmlTree]
evalXPath xml =
  runLA ( xread
  >>> propagateNamespaces
  >>> getXPathTreesWithNsEnv nsEnv "//a:Foo"
) xml

Now notice that simpleXmlOne and simpleXmlTwo are equivalent. Yes, they
have a different prefix for "http://foo.org";, but the documents means
the same. And as you write yourself, "... the prefix is no longer
releavant ..." Yet:

evalXPath simpleXmlOne /= evalXPath simpleXmlTwo

Hope that clarifies things.


Regards,

Mads



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: HXT error handling

[Mads Lindstrøm]

Hi Uwe


> This is a right point. Here the current XPath calling interface is too simple.
> A separation into XPath parsing and evaluation would be more flexible.
> The parsing (and error handling of XPath syntax errors) could be done once.
> I will extend the interface to support this.

That would be great. Thank you.

> 
> Thanks for your comments and hints,
> 
> Uwe

/Mads


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

Re: [Haskell-cafe] [OT?] Haskell-inspired functions for BASH

[Stephen Tetley]

On 6 April 2010 16:56, Gwern Branwen  wrote:

>
> The Scsh manual is worth reading just for the introductory material.


Hi Gwern

The Scsh manual is worth reading for the Acknowledgements section -
which is somewhat famous. Looking over them both it seems most of the
material in the paper is covered in the manual.

Esther is shipped as a project with Clean2.2 although I think it only
works on Windows - the last time I looked at the code I got the
impression that it had diverged a bit from the the Famke / Esther
papers.

Best wishes

Stephen
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] hsql repository

[Daniil Elovkov]

Hello
I've looked at hsql-* packages at hackage and found that they have 
progressed to 1.8.1. However, as always there is no hsql-oracle on 
hackage. It was usually found in the repository.


But I can't find where the repository is. Places, like code.haskell.org 
and htoolkit.sourceforge.net seem to have the older 1.7 version.


Can somebody point me to the repository? Is there any chance that 
hsql-oracle compiles with new hsql?


Thanks
Daniil Elovkov
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Haskell.org re-design

[Jeff Heard]

There's colourlovers.com as well



On Apr 6, 2010, at 12:41 PM, Thomas Schilling  
 wrote:



Well, I used http://www.colorschemedesigner.com/

On 6 April 2010 16:20, Daniel Peebles  wrote:
I'm definitely not a design/color person, but has anyone considered  
using
kuler.adobe.com as a source of "nice" color schemes, since we seem  
to have

an issue coming up with attractive combinations?

On Tue, Apr 6, 2010 at 9:58 AM, Thomas Schilling >

wrote:


Well, they make the wannabe-designer mistake of using justified text
in HTML, even worse, for columns just 3 words wide.

The overall layout, is pretty nice though.  It's essentially the
standard Web 2.0 layout (compare http://basecamphq.com/,
http://www.blinksale.com/, http://www.analysis-one.com/, etc.).  The
key design elements are (IMO):

 - Put the important stuff at the top and separate it visually from
the "other stuff".  The important things are:  (1) the quick summary
of Haskell, (2) the "Get Haskell" button, (3) link to "Learn  
Haskell"

/ "Try Haskell"

 - We may have a second row/column of secondary important stuff,  
like

community, project hosting, more implementations, the top learning
materials, etc. links to Haskell users

 - News, Events, etc. can go further down

I'm not particularly attached to any particulars of my suggested
design.  I just thought I'll try to encourage to move away much
further from the current wiki-like and somewhat dull design.

On 6 April 2010 10:36, Johan Tibell  wrote:
On Tue, Apr 6, 2010 at 5:24 AM, Simon Michael   
wrote:

On 4/2/10 5:28 AM, Thomas Schilling wrote:


How about something more colourful?

http://i.imgur.com/7jCPq.png


I really like the simplicity of the Cassandra page:

http://cassandra.apache.org/
___
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







--
Push the envelope.  Watch it bend.
___
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] Re: Haskell.org re-design

[Thomas Schilling]

Well, I used http://www.colorschemedesigner.com/

On 6 April 2010 16:20, Daniel Peebles  wrote:
> I'm definitely not a design/color person, but has anyone considered using
> kuler.adobe.com as a source of "nice" color schemes, since we seem to have
> an issue coming up with attractive combinations?
>
> On Tue, Apr 6, 2010 at 9:58 AM, Thomas Schilling 
> wrote:
>>
>> Well, they make the wannabe-designer mistake of using justified text
>> in HTML, even worse, for columns just 3 words wide.
>>
>> The overall layout, is pretty nice though.  It's essentially the
>> standard Web 2.0 layout (compare http://basecamphq.com/,
>> http://www.blinksale.com/, http://www.analysis-one.com/, etc.).  The
>> key design elements are (IMO):
>>
>>  - Put the important stuff at the top and separate it visually from
>> the "other stuff".  The important things are:  (1) the quick summary
>> of Haskell, (2) the "Get Haskell" button, (3) link to "Learn Haskell"
>> / "Try Haskell"
>>
>>  - We may have a second row/column of secondary important stuff, like
>> community, project hosting, more implementations, the top learning
>> materials, etc. links to Haskell users
>>
>>  - News, Events, etc. can go further down
>>
>> I'm not particularly attached to any particulars of my suggested
>> design.  I just thought I'll try to encourage to move away much
>> further from the current wiki-like and somewhat dull design.
>>
>> On 6 April 2010 10:36, Johan Tibell  wrote:
>> > On Tue, Apr 6, 2010 at 5:24 AM, Simon Michael  wrote:
>> >> On 4/2/10 5:28 AM, Thomas Schilling wrote:
>> >>>
>> >>> How about something more colourful?
>> >>>
>> >>> http://i.imgur.com/7jCPq.png
>> >
>> > I really like the simplicity of the Cassandra page:
>> >
>> > http://cassandra.apache.org/
>> > ___
>> > 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
>
>



-- 
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] Confusions about the Haskell Platform (for Mac)

[Gregory Collins]

Sean Leather  writes:

> Too bad the installer
> still doesn't work -- I'm working on it everyone, but the Mac installer
> system is incredibly crufty and broken, and Snow Leopard broke a lot of
> stuff for me.
>
> Is it possible to build the installer on a Leopard system/virtual
> machine such that it will install on a Snow Leopard system?

I think that's the approach I'm going to have to take. I still have my
Leopard DVD sitting around, I'll try building the thing in a VirtualBox
or maybe even doing a separate Leopard edition of the platform
installer.

> > 7. Why can't I have a single .pkg file?
>
> Short answer: I can't figure out how, and not for lack of trying,
> either. What I do is take the binary installer that the GHC guys build
> as a starting point. Despite many hours of reverse-engineering I cannot
> for the life of me figure out how to extract the GHC installer package
> from the binary "metapackage".
>
> I'm completely ignorant of how the installer packages work, but is it
> possible to have one package refer to another? Thus, one installer
> could initiate another. Then, at least there is only one click needed
> for the whole thing.

I don't have a good working solution for this, so the situation will
have to remain status quo (i.e. clicking two installers) for now.


> The platform installer is supposed to erase previous platform
> editions before it installs itself.
>
> That's good. Is it possible to include an uninstaller as well?

It would be pretty easy to bundle a shell script.

G
-- 
Gregory Collins 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Confusions about the Haskell Platform (for Mac)

[Sean Leather]

Hi Gregory,

Thanks for the reply.

Gregory Collins wrote:

> Sean Leather writes:
>
> > 4. The current link for the Mac image points to
> >
> http://hackage.haskell.org/platform/2010.1.0.0/haskell-platform-2010.1.0.1-i386.dmg
> > . Note the inconsistency between the version in the directory and file
> > names.
>
> You can think of that one as the second edition of the 2010.1 beta
> version. Agree that the directories should match.


This is, of course, relatively minor. One alternative is to change the
directory name to exclude the lowest version(s), e.g
2010.1/haskell-platform-2010.1.0.1-i386.dmg, so that when new intermediate
versions are uploaded, the directory name still makes sense and doesn't need
to change.

Too bad the installer
> still doesn't work -- I'm working on it everyone, but the Mac installer
> system is incredibly crufty and broken, and Snow Leopard broke a lot of
> stuff for me.
>

Is it possible to build the installer on a Leopard system/virtual machine
such that it will install on a Snow Leopard system?

> 5. The directions on http://hackage.haskell.org/platform/mac.html say:
> >
> >   After downloading:
> > * Open the .dmg file
> > * Follow the install instructions
> >
> >   I see no "install instructions" in the .dmg file. I only see the
> following files:
> > * GHC-6.12.1-i386.pkg
> > * Haskell Platform 2010.1.0.1.pkg
> > * Uninstall GHC
>
> When you mount the .dmg file a Finder window should pop up with the
> install instructions in a background image. Let me guess: this isn't
> working in Leopard? I should put a readme in there.
>

Yes, I'm using Leopard. A README file should do the trick.

> 7. Why can't I have a single .pkg file?
>
> Short answer: I can't figure out how, and not for lack of trying,
> either. What I do is take the binary installer that the GHC guys build
> as a starting point. Despite many hours of reverse-engineering I cannot
> for the life of me figure out how to extract the GHC installer package
> from the binary "metapackage".
>

I'm completely ignorant of how the installer packages work, but is it
possible to have one package refer to another? Thus, one installer could
initiate another. Then, at least there is only one click needed for the
whole thing.

My experience has been that if you unxar the metapackage and try to copy
> the included package file into a new metapackage, the mac installer
> tools barf. Long-term, I'm planning on just building GHC from source so
> I can package a one-click installer, but I don't have infinite time for
> this project and doing psychic battle with the evil warlocks who cooked
> up the Mac installer is a challenge.
>

I see you have the source at
http://github.com/gregorycollins/haskell-platform-osx-installer . I can try
to look at it at some point.

If anyone has expertise in this area and a willingness to help, please
> contact me off-list.
>
>
> > Why do I have an "Uninstall GHC" and not an "Uninstall Haskell
> > Platform"?
>
> The platform installer is supposed to erase previous platform editions
> before it installs itself.
>

That's good. Is it possible to include an uninstaller as well?

Regards,
Sean
___
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

[Gwern Branwen]

On Tue, Apr 6, 2010 at 11:17 AM, Stephen Tetley
 wrote:
> On 6 April 2010 15:09, Mario Blažević  wrote:
>
>>        A question of my own: is there any written design (an academic paper
>> would be perfect) of a functional shell language?
>
>
> Olin Shivers has written a detailed paper on Scsh.
>
> ftp://www-swiss.ai.mit.edu/pub/su/scsh/scsh-paper.ps
>
> The link might be down permanently (it is for me at the moment), maybe
> the paper is on Citeseer or similar. There is also the Scsh manual.
>
> Best wishes
>
> Stephen

The Scsh manual is worth reading just for the introductory material.

Part of the problem is that both Clean and Scheme have relatively easy
and powerful 'eval' ability. (Esther exploits the interesting feature
of Clean that lets you serialize functions to disk.)

Haskell doesn't, so much. The GHC API isn't too great to work with
here; it's hard enough to evaluate straight Haskell fragments, and to
serve as a shell, you really need new syntax; for example, you want
literals for program names. (Who would use a shell which forces you to
write 'run "ghci" ["foo.lhs"]', instead of 'ghci foo.lhs'?) But many
filenames break in Haskell; 'ssh-agent', 'g++-4.4', 'bf_tar', etc.

-- 
gwern
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Confusions about the Haskell Platform (for Mac)

[Gregory Collins]

Sean Leather  writes:

> 4. The current link for the Mac image points to
> http://hackage.haskell.org/platform/2010.1.0.0/haskell-platform-2010.1.0.1-i386.dmg
> . Note the inconsistency between the version in the directory and file
> names.

You can think of that one as the second edition of the 2010.1 beta
version. Agree that the directories should match. Too bad the installer
still doesn't work -- I'm working on it everyone, but the Mac installer
system is incredibly crufty and broken, and Snow Leopard broke a lot of
stuff for me.


> 5. The directions on http://hackage.haskell.org/platform/mac.html say:
>
>   After downloading:
>     * Open the .dmg file
>     * Follow the install instructions
>
>   I see no "install instructions" in the .dmg file. I only see the following 
> files:
>     * GHC-6.12.1-i386.pkg
>     * Haskell Platform 2010.1.0.1.pkg
>     * Uninstall GHC

When you mount the .dmg file a Finder window should pop up with the
install instructions in a background image. Let me guess: this isn't
working in Leopard? I should put a readme in there.


> 7. Why can't I have a single .pkg file?

Short answer: I can't figure out how, and not for lack of trying,
either. What I do is take the binary installer that the GHC guys build
as a starting point. Despite many hours of reverse-engineering I cannot
for the life of me figure out how to extract the GHC installer package
from the binary "metapackage".

My experience has been that if you unxar the metapackage and try to copy
the included package file into a new metapackage, the mac installer
tools barf. Long-term, I'm planning on just building GHC from source so
I can package a one-click installer, but I don't have infinite time for
this project and doing psychic battle with the evil warlocks who cooked
up the Mac installer is a challenge.

If anyone has expertise in this area and a willingness to help, please
contact me off-list.


> Why do I have an "Uninstall GHC" and not an "Uninstall Haskell
> Platform"?

The platform installer is supposed to erase previous platform editions
before it installs itself.

G.
-- 
Gregory Collins 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage accounts and real names

[Jonas Almström Duregård]

> I think this is a bad idea as it ruins recognisability. How am I meant
> to know that anonymous1 on hackage is the same person as mrfoo on
> haskellwiki, for example?

I should not have to point out how unreliable this method of
identifying individuals is... I suppose there is no way of preventing
mrfoo from adding his nick to the Maintainer or Author fields anyway.

For those who claim that there are no advantages of real name
policy's, consider Facebook. Arguably the astonishing success of
Facebook is utterly based on a real names policy...

2010/4/6 David House :
> 2010/4/6 Jonas Almström Duregård :
>> Maybe users could choose between using a real name and being given a
>> random one (like Anonymous). This will (1) protect from data
>> mining, (2) protect from government persecution and (3) keep the
>> damned 1337 Haxxor names away from Hackage :)
>
> I think this is a bad idea as it ruins recognisability. How am I meant
> to know that anonymous1 on hackage is the same person as mrfoo on
> haskellwiki, for example?
>
> P.s. if (3) is your real reason for supporting this restriction,
> please rethink your perspective. You are supporting a policy that is
> hurting the community for mere aesthetic reasons.
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: HXT error handling

[Uwe Schmidt]

Hi Mads,


> I am trying to use HXT to evaluate XPath expressions. The XPath
> expressions are not specified by myself, but by users of my program.
> However, the idea behind HXT's error handling confuses me. Maybe
> somebody can enlighten me.
> 
> This program fragment:
> 
> evalXPath :: String -> String -> [XmlTree]
> evalXPath xpath xml =
>   runLA ( xread
>   >>> propagateNamespaces
>   >>> getXPathTrees xpath
> ) xml
> 
> seems to work fine, except when it comes to error handling. If the
> xml-string is malformed, the error is simply ignored and the
> evalXPath-function just returns an empty list. I can understand what
> happens. 'getXPathTrees xpath' tries to match the xpath to a XmlTree
> which represents a parse error, and it therefore never matches anything.

When calling evalXPath, there are 2 error situations. Both can be handled
in the same form.

1. xread is called with a string, that does not match XML contents.
 This results in a single element list containing an error message.
 Test: runLA xread ""
 The following arrows, propagateNamespaces ..., don't accept error messages,
 so they fail and the result of the whole arrow ist the empty list.
 So the result of xread must be checked before further processed.

2. getXPathTrees xpath can fail with a syntax error in xpath.
 This again results in a single element list with an error message.
 The error message can be catched in the same way as before.

Your example can be rewritten in the following way:

--

module NameSpace
where

import Text.XML.HXT.Arrow
import Text.XML.HXT.XPath

simpleXml :: String
simpleXml = "http://www.w3.org/2003/05/soap-envelope\"/>"

wrongXml :: String
wrongXml = ""

nsEnv :: [(String, String)]
nsEnv = [ ("s", "http://www.w3.org/2003/05/soap-envelope";) ]

evalXPath :: String -> String -> [XmlTree]
evalXPath xpath xml =
  runLA ( xread
  >>>
  ( ( propagateNamespaces
  >>>
  getXPathTreesWithNsEnv nsEnv xpath
)
`whenNot` isError
  )
) xml

t1 = evalXPath "//s:Body"simpleXml
t2 = evalXPath "//soap:Body" simpleXml
t3 = evalXPath "???" simpleXml
t4 = evalXPath "//soap:Body" wrongXml
t5 = runLA xread wrongXml

--

> What I really would like was functions like:
> 
> parseStr :: (Monad m) => String -> m XmlTrees
> parseStr xml =
>   case Parsec.xread xml of
> (x:xs) -> if (Dom.isError x) then fail "Could not parse tree" else
> return (x:xs)
> [] -> fail "No XML tree resultet from parsing XML"

You already do have this. Not in a monadic version but as arrow.
See above example.

> And a similar function for the XPath. This could also speed up my
> program, as I would not parse the same XPath again and again. A

This is a right point. Here the current XPath calling interface is too simple.
A separation into XPath parsing and evaluation would be more flexible.
The parsing (and error handling of XPath syntax errors) could be done once.
I will extend the interface to support this.

Thanks for your comments and hints,

Uwe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Haskell.org re-design

[Daniel Peebles]

I'm definitely not a design/color person, but has anyone considered using
kuler.adobe.com as a source of "nice" color schemes, since we seem to have
an issue coming up with attractive combinations?

On Tue, Apr 6, 2010 at 9:58 AM, Thomas Schilling wrote:

> Well, they make the wannabe-designer mistake of using justified text
> in HTML, even worse, for columns just 3 words wide.
>
> The overall layout, is pretty nice though.  It's essentially the
> standard Web 2.0 layout (compare http://basecamphq.com/,
> http://www.blinksale.com/, http://www.analysis-one.com/, etc.).  The
> key design elements are (IMO):
>
>  - Put the important stuff at the top and separate it visually from
> the "other stuff".  The important things are:  (1) the quick summary
> of Haskell, (2) the "Get Haskell" button, (3) link to "Learn Haskell"
> / "Try Haskell"
>
>  - We may have a second row/column of secondary important stuff, like
> community, project hosting, more implementations, the top learning
> materials, etc. links to Haskell users
>
>  - News, Events, etc. can go further down
>
> I'm not particularly attached to any particulars of my suggested
> design.  I just thought I'll try to encourage to move away much
> further from the current wiki-like and somewhat dull design.
>
> On 6 April 2010 10:36, Johan Tibell  wrote:
> > On Tue, Apr 6, 2010 at 5:24 AM, Simon Michael  wrote:
> >> On 4/2/10 5:28 AM, Thomas Schilling wrote:
> >>>
> >>> How about something more colourful?
> >>>
> >>> http://i.imgur.com/7jCPq.png
> >
> > I really like the simplicity of the Cassandra page:
> >
> > http://cassandra.apache.org/
> > ___
> > 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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [OT?] Haskell-inspired functions for BASH

[Stephen Tetley]

On 6 April 2010 15:09, Mario Blažević  wrote:

>        A question of my own: is there any written design (an academic paper
> would be perfect) of a functional shell language?


Olin Shivers has written a detailed paper on Scsh.

ftp://www-swiss.ai.mit.edu/pub/su/scsh/scsh-paper.ps

The link might be down permanently (it is for me at the moment), maybe
the paper is on Citeseer or similar. There is also the Scsh manual.

Best wishes

Stephen
___
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

[Sean Leather]

>A question of my own: is there any written design (an academic paper
> would be perfect) of a functional shell language?


A few: http://www.citeulike.org/user/spl/tag/shell

More resources:
http://www.cse.unsw.edu.au/~pls/thesis-topics/functionalshell.html

Regards,
Sean
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: HXT Namespaces and XPath

[Uwe Schmidt]

Hi Mads,

> In HXT, namespace prefixes bound by an XML document are valid in the
> context of an XPath. How do avoid that?
> 
> An example program will clarify:
> 
> simpleXml :: String
> simpleXml = " xmlns:soap=\"http://www.w3.org/2003/05/soap-envelope\"/>"
> 
> nsEnv :: [(String, String)]
> nsEnv = [ ("s", "http://www.w3.org/2003/05/soap-envelope";) ]
> 
> evalXPath :: String -> String -> [XmlTree]
> evalXPath xpath xml =
>   runLA ( xread
>   >>> propagateNamespaces
>   >>> getXPathTreesWithNsEnv nsEnv xpath
> ) xml
> 
> Here:
> 
> evalXPath "//s:Body" simpleXml ==
> evalXPath "//soap:Body" simpleXml
> 
> Even though I only mentions the prefix "s" (and not "soap") in the
> function nsEnv.

When working with namespaces in XML, the prefixes are not longer significant.
After namespace propagation every name in the XML document is identified
by a qualified name. This is a pair consisting of the namespace URI and the 
local part.
The prefixes become irrelevant.
A namespace aware XPath expression needs a namespace environment,
as given in the example, to construct these qualified names for the names
in the XPath expression.
So the results of both evalXPath calls in your example must be the same. 

> I do not want the XPath to see prefixes declared in the xml-document, as
> it means that two semantically similar XML documents can get different
> results when applied to the same XPath.

If you intend, that the prefixes are significant, then you should not work
with namespace propagation. If namespaces are not propagated,
all names occurring in the document are taken as they are. That means
"s:Body" is different from "soap:Body".

For solving your tasks there could be 2 ways:

1. don't use namespaces, no propagateNamespaces, no getXPathTreesWithNsEnv,
 use the prefixes instead. Disadvantage: the prefixes become significant. If
 prefixes change, the semantics changes.

2. Use propagateNamespaces and getXPathTreesWithNsEnv, but select
 all nodes via the namespace URIs, not via the prefixes. If you want to
 output the manipulated XML parts and use standard prefixes for
 the namespaces, then use the namespace manipulation functions
 in 
http://hackage.haskell.org/packages/archive/hxt/latest/doc/html/Text-XML-HXT-Arrow-Namespace.html

Cheers,

  Uwe

___
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

[Mario Blažević]

Patrick LeBoutillier wrote:

...
Basically I'm looking for a bit of feedback/info:
- Does anyone know if there are already similar projets out there?


	You've already got some references, you can also look at 
http://hackage.haskell.org/package/scc which includes a shell language.




- Does anyone find this interesting?


I do.


- Any other comment/suggestion/feedback


	It would be interesting to compare the speed of your Bash functions 
with the h4sh executables written in Haskell. Your solution has the 
source platform independence on its side, of course.


	A question of my own: is there any written design (an academic paper 
would be perfect) of a functional shell language?


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Haskell.org re-design

[Thomas Schilling]

Well, they make the wannabe-designer mistake of using justified text
in HTML, even worse, for columns just 3 words wide.

The overall layout, is pretty nice though.  It's essentially the
standard Web 2.0 layout (compare http://basecamphq.com/,
http://www.blinksale.com/, http://www.analysis-one.com/, etc.).  The
key design elements are (IMO):

  - Put the important stuff at the top and separate it visually from
the "other stuff".  The important things are:  (1) the quick summary
of Haskell, (2) the "Get Haskell" button, (3) link to "Learn Haskell"
/ "Try Haskell"

  - We may have a second row/column of secondary important stuff, like
community, project hosting, more implementations, the top learning
materials, etc. links to Haskell users

  - News, Events, etc. can go further down

I'm not particularly attached to any particulars of my suggested
design.  I just thought I'll try to encourage to move away much
further from the current wiki-like and somewhat dull design.

On 6 April 2010 10:36, Johan Tibell  wrote:
> On Tue, Apr 6, 2010 at 5:24 AM, Simon Michael  wrote:
>> On 4/2/10 5:28 AM, Thomas Schilling wrote:
>>>
>>> How about something more colourful?
>>>
>>> http://i.imgur.com/7jCPq.png
>
> I really like the simplicity of the Cassandra page:
>
> http://cassandra.apache.org/
> ___
> 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] Re: Metaprogramming in Haskell vs. Ocaml

[Nicolas Pouillard]

On Tue, 06 Apr 2010 09:37:59 -0400, Jacques Carette  wrote:
> One thing I should have mentionned - TH and camlp4 are really 
> equivalents.  And camlp4 is as-typed-as TH (or not, depending on your 
> point of view).  I am co-author of a camlp4 extension, and I must admit 
> that coding in camlp4 was not enjoyable, while coding in metaocaml 
> (eventually) is.

This is not exactly the same, TH is a bit more typed than camlp4 here is two
examples:

{-# LANGUAGE TemplateHaskell #-}
module Thtest1 (test) where
test = [d| f :: Int
   f = True |]

{-# LANGUAGE TemplateHaskell #-}
module Thtest2 (test) where
test = [e| 1 + x |]

These two files are rejected at compile time before being spliced in.
So there is a limited scope checking, and type checking (limited because
manually using the AST constructors allow to workaround the typechecker).

Second point, the Q monad allows to generate names in a rather safe way
compared to camlp4.

Third reification can be done on declarations done in other files. So
that we can easily inspect the types and definitions of previous things,
which a rather hard (near to impossible) in camlp4.

Best regards,

-- 
Nicolas Pouillard
http://nicolaspouillard.fr
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Metaprogramming in Haskell vs. Ocaml

[Jacques Carette]

One thing I should have mentionned - TH and camlp4 are really 
equivalents.  And camlp4 is as-typed-as TH (or not, depending on your 
point of view).  I am co-author of a camlp4 extension, and I must admit 
that coding in camlp4 was not enjoyable, while coding in metaocaml 
(eventually) is.


[I see that Nicolas Pouillard just answered the question about new type 
definitions, etc, as I was typing this answer]


Heinrich Apfelmus wrote:

It seems to me that metaocaml is more used as "user annotated" partial
evaluation?
  
I see most of my uses of metaocaml as code generation (building 'up' 
code from pieces by making explicit design choices) rather than 
classical partial evaluation (specializing code).  Others would argue 
that these two activities are really the same thing -- and I would not 
really disagree!  It's just that in my cases the 'specialization' is not 
driven by the partial evaluator at all, it is fully driven by the user 
[through explicit decisions of which modules/functors to use].  This 
requires a very different code organization, which is why I make the 
difference between the two approaches.


The Haskell analogy: I write tons and tons of typeclass-level 'code', 
including typeclasses for type constructors (and type constructor 
transformers and ...) but then I ensure that whenever these are used, it 
can be statically determined exactly which instance should be used, and 
100% of the dispatch overhead is eliminated AND I get full control over 
which methods get inlined in the final code.  It is that 'full control' 
aspect which gets you reliable efficiency from highly abstract code.


Jacques
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Seeking advice about monadic traversal functions

[Heinrich Apfelmus]

Darryn Reid wrote:
> Martijn van Steenbergen wrote:
>>
>> A small remark: I prefer using applicative notation for this:
>>
>>> go Next (Single x t1) = Single x <$> rewrite f t1
>>> go Next (Fork t1 t2 ) = Fork <$> rewrite f t1 <*> rewrite f t2
>>
> 
> Thanks for your comment and advice. Could you explain a little further
> your thinking? Specifically, what advantage do you find in the
> applicative notation, and when would you advise using it and when would
> you advise not using it?

The applicative notation is more general since it also applies to
applicative functors

  http://www.cs.nott.ac.uk/~ctm/IdiomLite.pdf

It's main advantage over the liftM family is that it can be used with
any number of arguments

  liftM  f m = f <$> m
  liftM2 f m n   = f <$> m <*> n
  liftM3 f m n o = f <$> m <*> n <*> o
  etc.

and that's why I prefer it as well. It's very similar to function
application, too, just think of  <*>  as a replacement for the empty
space that separates function arguments.

The only drawback is probably that you have to

  import Control.Applicative

In fact, it doesn't actually work for monads, I think you have to wrap
it in a newtype. :D The same effect can be achieved with `ap` , though:

  liftM3 f m n p = return f `ap` m `ap` n `ap` o


Regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How do I use ByteString?

[Ketil Malde]

Mads Lindstrøm  writes:

> It may seem unfair that I put byte-strings and char-strings in the
> same bucket, but libraries do use byte-strings to contain
> characters. For example, Parsec has a [Char] and a bytestring
> interface. 

It bears noting that Data.ByteString and Data.ByteString.Char8 are just
different interfaces to the same data type (same goes for the .Lazy
versions).

Once upon a time I forked bytestring to use a phantom type tag to
separate different encodings (including many other 8-bit encodings than
the Char8 one), but although I still think this is a good idea, the code
is long dead and gone now.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: libraries [was GUI haters]

[Heinrich Apfelmus]

Jean-Denis Koeck wrote:
> 
> Question to the Mac users on the list: do you find that Qt applications
> feel "native enough" on your platform ? If not, any tips ?

Well, that depends on your definition of "enough". :)

The most important thing is probably that cross platform applications
always "look buggy", so if you can make sure that everything runs
smoothly and there are no drawing bugs or thelike, that's a big plus.

Qt applications will always look odd, the relative spacing is all off.
But using the appropriate system fonts adds a lot to consistency. Avoid
colored buttons and text.

Another key feature of "native" for me is that the menu bar is at the
top of the screen. Hence, all windows share the same menu. Furthermore,
the context menu should not list commands that are not available in the
top menu.

Not as important, but still unique to native Mac applications is that
accept a lot of drag & drop. For instance, to insert a picture into a
document, you can just drag & drop it from the Finder program; no need
to intricate "open file" dialogs. If you have a list of items that can
be rearranged, do so by means of drag & drop instead of strange Up and
Down buttons.

There's probably more, but that's what I can think of right now off the
top of my hat. :)


Regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Metaprogramming in Haskell vs. Ocaml

[Nicolas Pouillard]

On Tue, 06 Apr 2010 15:08:45 +0200, Heinrich Apfelmus 
 wrote:
> Jacques Carette wrote:
> > Jason Dagit wrote:
> >> Are you implying that template haskell is not typed?
> >
> > Indeed. [...]
> >
> > Compare with metaocaml where if you can compile you meta-program (i.e.
> > code generator), then you are guaranteed that it can only ever produce
> > valid, well-typed code.  Not so with TH, where you can easily generate
> > junk -- which GHC will promptly figure out  and give you an error.
> 
> I'm curious, can metaocaml create new data type definitions, value
> declarations or type class instances? I usually use TH to get rid of
> boilerplate that I cannot get rid off in Haskell itself, for instance
> for creating functional lenses for record types
> 
> data Foo = Foo { bar_ :: Int, ...}
> 
> $(DeriveLenses Foo)
> -- bar :: Lens Foo Int

No metaocaml cannot do this. It is restricted to the expression level, and
not the declaration level. Moreover you cannot pattern match over the
generated code.

> It seems to me that metaocaml is more used as "user annotated" partial
> evaluation?

That is a way to look at it.

-- 
Nicolas Pouillard
http://nicolaspouillard.fr
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Hackage accounts and real names

[Daniel Fischer]

Am Dienstag 06 April 2010 14:57:30 schrieb Heinrich Apfelmus:
> Edward Z. Yang wrote:
> > This is a pretty terrible reason, but I'm going to throw it out there:
> > I like real names because they're much more aesthetically pleasing.
>
> I agree, and this is why I phased out "apfelmus" in favor of the
> pseudonym "Heinrich Apfelmus".

If it's a pseudonym, you should've chosen "Marcus Apfelmus" - or did you 
never read Asterix?

>
> So, a more accurate policy would be to accept not only real names, but
> also names that look like they're real, i.e. aesthetically pleasing noms
> de plumes.

I support that, with exceptions for "sufficiently well known" nicks (Gour 
spoke out; before you changed it, apfelmus fell into that category, a few 
others come to mind, but not many).

>
>
> Regards,
> Heinrich Apfelmus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: libraries [was GUI haters]

[Heinrich Apfelmus]

aditya siram wrote:
> Cocoa is probably the best GUI toolkit (open-source or otherwise) that
> I've seen. However it ties your app to the Mac (and the iPhone). And I
> don't believe there is a mature Haskell bridge.

There is hoc

  http://code.google.com/p/hoc/

but it's not on hackage and seems a bit dormant.

> And Javascript [1] is really not _that_ bad!

But it's not Haskell. :'(


Regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How do I use ByteString?

[Mads Lindstrøm]

Hi

Don Stewart wrote:
> gue.schmidt:
> > Hi all,
> >
> > I've never found an easy way to deal with ByteStrings.
> >
> > I'm using the RSA library and it en- and decodes  
> > Data.ByteString.Lazy.ByteString.
> >
> > I initially start with Strings, ie. [Char], but there is no function to  
> > convert the 2 back and forth. There is however a function which takes  
> > [Word8] to BytesString and back.
> >
> > It all wouldn't be so confusing if there weren't several versions of  
> > ByteString in several modules to choose from. And a number of libraries  
> > requiring different types of ByteString.
> >
> > I am sure the designers of the bytestring package had good reason for  
> > this design, is there also a webpage which explains which one to use and  
> > under what circumstances?

I really would like such a webpage, because I am also confused about
when to use what type of strings.

> 
> As a general rule you should never convert between String and
> bytestring. You can read bytestrings from files, or write literals using
> "pack" or the -XOverloadedStrings extension

Except that different libraries require different kind of strings. Some
use strict bytestring, some use lazy bytestring, some use [Char], some
use lazy Data.Text, ... So you really need to convert between different
representations. It may seem unfair that I put byte-strings and
char-strings in the same bucket, but libraries do use byte-strings to
contain characters. For example, Parsec has a [Char] and a bytestring
interface.

Strings are the glue that binds many libraries together, and the many
different types of strings complicate this glue. It is therefore much
more complicated to compose different libraries than it was when most
libraries used [Char]. It really would make Haskell programming easier
if we could settle on one char-string type (and one type for
byte-strings).

> 
> Converting between lazy and strict bytestrings is a representation
> change, and changes complexity - so be aware of what you're doing. You
> can do this via fromChunks or concat . toChunks.

Reading the introduction to lazy bytestring here
http://hackage.haskell.org/packages/archive/bytestring/0.9.1.5/doc/html/Data-ByteString-Lazy.html
 it seems that lazy bytestring always has at least as good complexity as strict 
bytestrings. Lazy Data.Text strings also has at least as good complexity as 
strict Data.Text strings. So, for public library interfaces it would be great 
if could settle for some lazy string type like Data.Text. Preferably a string 
type that could be efficiently converted to lazy bytestrings for libraries that 
deal with bytes and not characters. This however, requires that the community 
can settle for one char-string type and a good beginning could be a description 
of how string handling is supposed to happen in Haskell (I am thinking about a 
webpage like Günther writes about).


/Mads

> 
> -- Don
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


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: Metaprogramming in Haskell vs. Ocaml

[Heinrich Apfelmus]

Jacques Carette wrote:
> Jason Dagit wrote:
>> Are you implying that template haskell is not typed?
>
> Indeed. [...]
>
> Compare with metaocaml where if you can compile you meta-program (i.e.
> code generator), then you are guaranteed that it can only ever produce
> valid, well-typed code.  Not so with TH, where you can easily generate
> junk -- which GHC will promptly figure out  and give you an error.

I'm curious, can metaocaml create new data type definitions, value
declarations or type class instances? I usually use TH to get rid of
boilerplate that I cannot get rid off in Haskell itself, for instance
for creating functional lenses for record types

data Foo = Foo { bar_ :: Int, ...}

$(DeriveLenses Foo)
-- bar :: Lens Foo Int

It seems to me that metaocaml is more used as "user annotated" partial
evaluation?


Regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Confusions about the Haskell Platform (for Mac)

[Don Stewart]

leather:
> 1. Why can't the platform download site be hosted on www.haskell.org instead 
> of
> hackage.haskell.org? I see that there's a redirect, but (imho) it would be
> ideal to have www.haskell.org/platform be the standard URL in my browser. It 
> is
> easier to remember (for typing) and more obvious (for appearances).

It's a different server that we have better physical access to (i.e. I
can check the logs).
  
> 2. What is the difference between "Haskell" and the "Haskell Platform"? I see
> one or the other in various places. To get from www.haskell.org to downloading
> the Mac software, I go through "Download Haskell," "Get the Haskell Platform >
> Mac," and "Download Haskell for Mac OS X (intel)."
> 
> 3. By looking at http://hackage.haskell.org/platform/mac.html , I have no idea
> what I'm going to get when I click the "Download Haskell for Mac OS X (intel)"
> link. It would be nice to know what I'm getting myself into before I commit to
> waiting for this 137.9 MB file. Thanks to the wonder of deep links, one can
> also not be expected to traverse the path that I did in #2. Similarly, if I
> come to this link directly, I have no easy way of navigating to try to figure
> out what "Haskell" or "GHC" is.
> 
> 4. The current link for the Mac image points to http://hackage.haskell.org/
> platform/2010.1.0.0/haskell-platform-2010.1.0.1-i386.dmg . Note the
> inconsistency between the version in the directory and file names.
> 
> 5. The directions on http://hackage.haskell.org/platform/mac.html say:
> 
>   After downloading:
> * Open the .dmg file
> * Follow the install instructions
> 
>   I see no "install instructions" in the .dmg file. I only see the following
> files:
> * GHC-6.12.1-i386.pkg
> * Haskell Platform 2010.1.0.1.pkg
> * Uninstall GHC
> 
> 6. Since there are no "install instructions," I am not sure which .pkg to
> install first. Of course, fix #3 and you hopefully fix this one.
> 
> 7. Why can't I have a single .pkg file? Why do I have an "Uninstall GHC" and
> not an "Uninstall Haskell Platform"?
> 
> --
> 
> I don't expect all of the above to necessarily have a direct solution. They 
> are
> just my observations to share. Some of them are from the point of view of a
> newcomer, and some are from a perfectionist.
> 

Thanks! I'm about to hop on a plane, but here's the darcs repo for the
download website, if you want to address some of the issues -- e.g.
return navigation links.

http://code.haskell.org/haskell-platform

I'd love patches and improvements to address the concerns above.

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Hackage accounts and real names

[Steve Schafer]

On Tue, 06 Apr 2010 14:57:30 +0200, you wrote:

>I agree, and this is why I phased out "apfelmus" in favor of the
>pseudonym "Heinrich Apfelmus".

You mean your name isn't really "Applesauce"?

Steve Schafer
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Hackage accounts and real names

[Jake McArthur]

On Tue, Apr 6, 2010 at 6:08 AM, Serguey Zefirov  wrote:
> http://lambda-the-ultimate.org is one lovely community that has that
> restriction: http://lambda-the-ultimate.org/policies#Policies

I quote the policy in full here:

> Many of us here post with our real, full names. Anonymity and the use of 
> pseudonyms is discouraged. We recognize that there can be legitimate reasons 
> for wishing to post under a pseudonym. If you do not register using your real 
> name, then if possible, please include identifying information in your user 
> profile, such as your real name or a link to a personal home page or blog. 
> Using a pseudonym by which you are known elsewhere can also help.

This is a request, not a restriction.

- Jake
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Hackage accounts and real names

[Roel van Dijk]

On Tue, Apr 6, 2010 at 1:08 PM, Serguey Zefirov  wrote:
> http://lambda-the-ultimate.org is one lovely community that has that
> restriction: http://lambda-the-ultimate.org/policies#Policies

LtU has no restriction on user names. From LtU's policy:
> Anonymity and the use of pseudonyms is discouraged.

I'm against *requiring* the use of a "real name" for hackage accounts.
I have no problems with encouraging the use of given/everyday names.

Regards,
Roel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Hackage accounts and real names

[Heinrich Apfelmus]

Edward Z. Yang wrote:
> This is a pretty terrible reason, but I'm going to throw it out there:
> I like real names because they're much more aesthetically pleasing.

I agree, and this is why I phased out "apfelmus" in favor of the
pseudonym "Heinrich Apfelmus".

So, a more accurate policy would be to accept not only real names, but
also names that look like they're real, i.e. aesthetically pleasing noms
de plumes.


Regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage accounts and real names

[Tony Finch]

I note that in some jurisdictions there is no such thing as a "real" name.
You can change your name for legal purposes (on official documentation and
so forth) simply by asserting that this is the name you prefer to be known
by. Your legal name doesn't have to be the same as your everyday name
(mine isn't).

What matters is continuity of identity and the ability to link your
identities across the places you participate.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Hackage accounts and real names

[Ross Paterson]

On Tue, Apr 06, 2010 at 10:10:09AM +0100, David House wrote:
> 3. Privacy issues. Some people simply cannot reveal their real names.

I've already said I was prepared to make exceptions in such cases, but
perhaps you missed that.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] FRP, arrows and loops

[Maciej Piechotka]

On Fri, 2010-04-02 at 14:51 -0400, Christopher Lane Hinson wrote:
> On Fri, 2 Apr 2010, Maciej Piechotka wrote:
> 
> > 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')
> 
> Neither of these compile through my eyeball,

What I meant was:

> instance ArrowLoop a => ArrowLoop (SF a) where
>   loop (SF f) =  SF $! proc (dyn, b, r, s) -> do
> rec ((c, d), s, f') <- f -< (dyn, (b, d), r, s)
> returnA -< (c, s, loop f')


> > 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
> > )
> >
> 
> It would only be a convenience typeclass, and in that case why not just 
> have a generic ArrowKleisli with: (i -> m o) -> a i o
> 

Hmm. I guess to avoid (some) problems:

> class (Monad m, Arrow a) => ArrowKleisli m a where
> liftMonad ∷  (b -> m c) -> a c
> liftMonad = liftKleisli . Kleisli
> liftKleisli ∷  Kleisli m b c -> a b c
> liftKleisli = liftMonad . runKleisli


Given:

> instance ArrowKleisli CHP (Kleisli CHP)
> instance ArrowKleisli IO (Kleisli CHP)

And:

> someFunc = liftIO . print :: (Show b, MonadIO m) => b -> m ()

Which liftIO is run in:

> liftMonad someFunc :: Kleisli CHP String ()

ghci> :t liftMonad (someFunc) :: Kleisli CHP String ()

:1:0:
No instance for (ArrowKleisli m (Kleisli CHP))
  arising from a use of `liftMonad' at :1:0-19
Possible fix:
  add an instance declaration for (ArrowKleisli m (Kleisli CHP))
In the expression: liftMonad (someFunc) :: Kleisli CHP String ()


As IO is popular it is particularly likely to run into this problem.

Adding:

> class Arrow a ⇒  ArrowIO a where
> liftAIO ∷  (b →  IO c) →  a b c
>
> instance ArrowKleisli IO a ⇒  ArrowIO a where
> liftAIO = liftMonad

Solves problem:
ghci> :t liftAIO someFunc :: Kleisli CHP String ()
liftAIO someFunc :: Kleisli CHP String () :: Kleisli CHP String ()

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