[Haskell-cafe] Re: Haskellers.com idea: strike forces

2010-10-30 Thread Heinrich Apfelmus

Michael Snoyman wrote:


In the recent discussion about the status of email support in Haskell,
the idea of strike forces to tackle these big problems came up. I
think one dilemma people face when trying to coordinate such a venture
is the logistics: where to organize, how to advertise it, where to
have discussions that can be publicly accessible.

This may be something that the Haskellers website can help address.


That's a great idea!

Concerning the details of how things should work, it's probably best if 
you simply start a SIG yourself (you mentioned web development) and code 
everything that comes up on the fly. There is no better way to ensure 
usability of an application than to write it while heavily using it (and 
aiming for a large usability / features ratio).



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] Edit Hackage

2010-10-30 Thread Daniel Fischer
On Saturday 30 October 2010 03:42:27, Ivan Lazar Miljenovic wrote:
 On 30 October 2010 12:22, Lauri Alanko l...@iki.fi wrote:
  On Thu, Oct 28, 2010 at 01:55:12PM -0700, Don Stewart wrote:
  The number of subscribers to the Haskell Reddit, for example, is
  double the -cafe@, and there are comparable numbers of questions
  being asked on the Stack Overflow [haskell] tag, as here -- so anyone
  who only reads -cafe@ is already missing a lot of stuff.
 
  A lot of the community has already voted on the efficacy of mailing
  lists for large communities, by moving their discussion elsewhere.
 
  Do you mean that people have actually unsubscribed from the list in
  favor of only following web-based media? New people who only join the
  web forums do not vote since they may not even know about the
  mailing list.
 
  I know that this is a hopeless battle, but since I feel very strongly
  about this, I'll indulge in defending the mailing list even though
  this is rather off-topic.
 
  The reasons why I prefer mailing lists (and newsgroups, rest in piece)
  over web-based discussion forums:
 
  * Usability: mail and news clients provide a consistent interface to
   all the discussions, and the customizability and diversity of
   clients ensures that everyone can access the discussions the way
   they like it. In contrast, web forums come with their built-in
   interfaces, and if you don't like them, you are SOL.
 
  * Scalability: related to the above, since mail and news provide a
   consistent interface to all the discussions, adding new lists and
   groups to be followed requires minimal effort since they just show
   up as new items whose updates get tracked automatically. In the
   worst case, adding a new web forum to be followed requires visiting
   the site frequently to check whether new messages have arrived. RSS
   and similar syndication technologies help, thankfully, but support
   for them is inconsistent, and often incomplete (they might not
   notify about new comments, only new topics). I subscribe to tens of
   mailing lists without problems. I wouldn't want to try to follow
   tens of web forums regularly.
 
  * Archivability: with mail and news, it is trivial for me to get local
   copies of the discussions (and the messages I myself have written)
   which I can peruse and search to my heart's content later without
   being dependent on the continued functioning of some external
   service. Although it is possible to save web pages locally, this
   usually very inconvenient, especially if one wants the local copies
   to be kept up to date with ongoing discussions.
 
  * Offline support: related to the above, with mail and news fetching
   and sending messages are separate from reading and writing
   them. Hence one can read and write messages even when one is for
   some reason not online. Web forums practically require an online
   connection when one wants to read the discussions.
 
  * Neutrality: newsgroups are completely distributed and not controlled
   by any single entity. Mailing lists are a centralized service, but a
   purely technical one. The haskell.org mailing lists (like the rest
   of haskell.org) are directly maintained by the community. In
   contrast, external web forums like reddit and stackoverflow are
   owned by companies, and visits to the sites bring ad revenue to the
   companies. Moreover, the contents of these sites are subject to
   deletion (or perhaps even editing) by the whims of their owners.
 
  In short, the old technologies of mail and news are technically vastly
  superior to web forums, which have required additional technologies
  (e.g. RSS) to attempt to overcome the obstacles that mail and news
  solve directly.
 
  It is true that web forums are nowadays very popular and have some
  nice features that the older technologies don't. The main reason for
  this, I suspect, is money: mail and news are from the older, more
  innocent age when internet technology was driven by the desire to
  communicate efficiently instead of making money. They are by their
  nature so neutral that they provide no financial incentive to develop
  them or support them. The web, on the other hand, provides many
  opportunites to profit by offering services, so it is no wonder that
  web technologies have flourished in the commercialized internet.
 
  Perhaps this is inevitable, and it is certainly ok for the haskell.org
  front page to provide links to reddit and stackoverflow just to inform
  visitors that these sites might be of interest.
 
  But by saying I encourage people to use the online forums: Haskell
  Reddit and Stack Overflow you are effectively saying: please let
  Condé Nast Digital and Stack Overflow Internet Services, Inc
  capitalize on your interest in and knowledge of Haskell. I most
  strongly object to this becoming the standard policy of the Haskell
  community.

 +1; that's pretty much my opinion/arguments as well.

+1; same here.

[Haskell-cafe] Re: Haddock API and .haddock interface files questions

2010-10-30 Thread David Waern
2010/10/26 Claus Reinke claus.rei...@talk21.com:
 Some questions about Haddock usage:

 1. Haddock executable and library are a single hackage package,
   but GHC seems to include only the former (haddock does not
   even appear as a hidden package anymore). Is that intended?

Yes, I think that's so that GHC maintainers don't need to worry about
API changes in Haddock when making new releases. The Haddock API is
not very stable.

 2. Naively, I'd expect Haddock processing to involve three stages:
   1. extract information for each file/package
   2. mix and match information batches for crosslinking
   3. generate output for each file/package

   I would then expect .haddock interface files to repesent the
   complete per-package information extracted in step 1, so    that packages
 with source can be used interchangeably
   with packages with .haddock files.

   However, I can't seem to use 'haddock --hoogle', say, with
   only .haddock interface files as input (No input file(s).).

Haddock currently mostly works on GHC's front-end AST, called HsSyn,
which is not stored in the .haddock files, so that's why you need
sources.

I say mostly, because the one-year old feature that we call
cross-package documentation (allowing the user to re-export
documentation from other packages), is implemented by taking
information from GHC's .hi files, converting that to HsSyn. The syntax
used in the .hi files is slightly less detailed than HsSyn so we loose
some information about the exact declaration syntax used by the
programmer (brackets in type expressions, infix/prefix declaration
styles, etc - nothing that is semantically relevant).

In theory we could continue along that road and let you build output
from a combination of .haddock and .hi files. Or we could do as you
say and just put everything in the .haddock files (in which case we
could use the HsSyn type).

 3. It would be nice if the Haddock executable was just a thin
   wrapper over the Haddock API, if only to test that the API
   exposes sufficient functionality for implementing everything
   Haddock can do.

Yes, good idea. We haven't done that yet since the API started out as
something quite experimental, and it's still in that stage although it
has gained a lot more functionality recently.

   Instead, there is an awful lot of useful code in Haddock's
   Main.hs, which is not available via the API. So when coding
   against the API, for instance, to extract information from
   .haddock files, one has to copy much of that code.

   Also, some inportant functionality isn't exported (e.g., the
   standard form of constructing URLs), so it has to be copied
   and kept in synch with the in-Haddock version of the code.

Right. We should export that.

   It might also be useful to think about the representation
   of the output of stage 2 above: currently, Haddock directly
   generates indices in XHtml form, even though much of
   the index computation should be shareable accross
   backends. That is, current backends seem to do both
   stage 2 and stage 3, with little reuse of code for stage 2.

True. The index could be factored out of the Xhtml backend and added
to the output of stage 2.

 It seems that exposing sufficient information in the API, and
 allowing .haddock interface files as first-class inputs, there
 should be less need for hardcoding external tools into Haddock
 (such as --hoogle, or haddock-leksah). Instead, clients should
 be able to code alternative backends separately, using Haddock
 to extract information from sources into .haddock files, and
 the API for processing those .haddock files.
 Are these expectations reasonable, or am I misreading the intent behind API
 and .haddock files? Is there any documentation about the role and usage of
 these two
 Haddock features, as well as the plans for their development?

No documentation yet, but yes, the long term plan is to be able to
split Haddock in parts: one program that creates data from sources,
probably resulting in a .haddock file or maybe something text based,
and backends that use those files. The API should provide a convenient
way to read the files. It's not been fleshed out in detail yet, and
the API is quite ad-hoc at the moment so we need think more about this
and write documentation on the Haddock trac.

Thanks for the input!

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


Re: [Haskell-cafe] Re: Monads and Functions sequence and sequence_

2010-10-30 Thread Ben Millwood
The actual, entire, complete definitions of sequence and sequence_ are
(or at least, could be):

 sequence [] = return []
 sequence (m:ms) = do
   x - m
   xs - sequence ms
   return (x:xs)

 -- or, equivalently:
 sequence' = foldr (liftM2 (:)) (return [])

 sequence_ [] = return ()
 sequence_ (x:xs) = do
   x
   sequence_ xs

 -- or:
 sequence'_ = foldr () (return ())

They're defined once for all monads, not once for each monad, so in
some sense they behave the 'same' in that they use the Monad instance
in the same way.

It's just like, say, sort :: Ord a = [a] - [a] might do different
computations to compare elements depending on what 'a' is, but always
produces a sorted list regardless of that detail.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] vector-space and standard API for vectors

2010-10-30 Thread Henning Thielemann
wren ng thornton schrieb:
 On 10/22/10 8:46 AM, Alexey Khudyakov wrote:
 Hello everyone!

 It's well known that Num  Co type classes are not adequate for vectors
 (I don't mean arrays). I have an idea how to address this problem.

 Conal Elliott wrote very nice set of type classes for vectors.
 (Definition below). I used them for some time and quite pleased. Code is
 concise and readable.

   class AdditiveGroup v where
   zeroV :: v
   (^+^) :: v - v - v
   negateV :: v - v
 [...]
 I'd like to know opinion of haskellers on this and specifically opinion
 of Conal Eliott as author and maintainer (I CC'ed him)

Looks like you are about to re-implement numeric-prelude. :-)

 Just my standard complaint: lack of support for semirings, modules, and
 other simple/general structures. How come everyone's in such a hurry to
 run off towards Euclidean spaces et al.?
 
 I'd rather see,
 
 class Additive v where -- or AdditiveMonoid, if preferred
 zeroV :: v
 (^+^) :: v - v - v
 
 class Additive v = AdditiveGroup v where
 negateV :: v - v
 
 type family Scalar :: * - *

Vector (Complex a) is a vector with respect to both 'a' and 'Complex a'.

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


[Haskell-cafe] Re: Haskell-Cafe Digest, Vol 86, Issue 63

2010-10-30 Thread Arnaud Bailly
Hello John,
Thanks for your detailed answer. I finally understood this behaviour
and got to the point where I need something like enumPair.
About the scala implementation, it was this same blog post that arose
my interest in iteratees :-)

Regards,
Arnaud
On Wed, Oct 27, 2010 at 5:26 PM, John Lato jwl...@gmail.com wrote:
 Hi Arnaud,


 From: Arnaud Bailly arnaud.oq...@gmail.com

 Hello,
 I am trying to wrap my head around the concept of Iteratee reading the
 article by John Lato in Monad Reader issue 16
 (http://themonadreader.files.wordpress.com/2010/05/issue16.pdf). I
 followed the advice on page 34:

 I have frequently heard reports from Haskellers (including
 highly-talented and
 experienced users) that the only way they could understand
 enumeration-based
 I/O was by re-implementing it themselves.

 and so reimplemented this code in Java which is, for better and worse,
 my current professional language (and there really is no point in
 writing my own 50th iteratee code...).

 I have a question about iteratees composition and their behaviour. I
 tried to use the throbber code to display progress while writing a
 file, without using enumeratees which are introduced later on in the
 article, but failed. I can bind the two iteratees together, but the
 writer iteratee consumes the stream of characters to write before
 handing over the control to the throbber iteratee which has nothing to
 count. Did I miss something ?

 This is the expected behavior.  When iteratees are composed with bind, the
 first will consume as much of the stream as it needs to calculate its
 result, and only then will it pass the remaining stream to the next iteratee
 in the composition.  Since streamToFile and throbber both consume an
 entire stream, they won't complete until EOF, and then will pass just that
 EOF to the next iteratee in the composition.
 The behavior you want is pretty common, and it can be accomplished by
 writing either throbber or streamToFile as an enumeratee.  Then the
 enumeratee version would do the work it's supposed to but also pass the
 stream along to another iteratee.  You could write a library function with
 type (following the types from the article)
 iterToEnum :: Monad m = Iteratee el m () - EnumerateeM el el m a
 which would do this for any data-sink type iteratee.
 A very similar approach is used in the iteratee package to define the
 enumPair function,
 enumPair :: Monad m = Iteratee s m a - Iteratee s m b - Iteratee s m
 (a,b)
 I consider enumPair to be one of the most powerful functions supplied in
 iteratee.
 Since you use Java, you may be interested in an iteratee implementation in
 Scala, http://apocalisp.wordpress.com/2010/10/17/scalaz-tutorial-enumeration-based-io-with-iteratees/
 Best,
 John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] commutativity

2010-10-30 Thread Patrick Browne
Hi,
Below are two questions on commutative operations in Haskell.

infixl 5 `com`
com :: Int - Int - Int
x `com` y  = (x + y)
commutative com a b = (a `com` b) == (b`com`a)

-- 1 + 3 == 3 + 1
-- This gives true by virtue of the value of LHS and RHS being equal
after the plus operation

-- Question 1
-- commutative com 1 3
-- This also gives true. Is it because of commutative equation or
because of the plus operation?

-- Question 2
-- In Haskell can commutativity be specified as a property of infix
operations?

This message has been scanned for content and viruses by the DIT Information 
Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Package regex-posix-0.94.2 suddenly failed to link

2010-10-30 Thread Arnaud Bailly
Hello,
All of a sudden, the package regex-posix-0.94.2 failed to link after i
installed a couple of other packages (http, json). When I try to
reinstall it, I got the folowing errors:

D:\projets\crete1941cabal install --global --reinstall
--enable-documentation regex-posix-0.94.2
Resolving dependencies...
Configuring regex-posix-0.94.2...
Preprocessing library regex-posix-0.94.2...
Text\Regex\Posix\Wrap.hsc:107:19: regex.h: No such file or directory
Text\Regex\Posix\Wrap.hsc: In function `main':
Text\Regex\Posix\Wrap.hsc:149: error: `regoff_t' undeclared (first use
in this function)
Text\Regex\Posix\Wrap.hsc:149: error: (Each undeclared identifier is
reported only once
Text\Regex\Posix\Wrap.hsc:149: error: for each function it appears in.)
Text\Regex\Posix\Wrap.hsc:149: error: syntax error before int
Text\Regex\Posix\Wrap.hsc:384: error: `REG_NOTBOL' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:385: error: `REG_NOTEOL' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:389: error: `REG_EXTENDED' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:390: error: `REG_ICASE' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:391: error: `REG_NOSUB' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:392: error: `REG_NEWLINE' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:398: error: `REG_NOMATCH' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:399: error: `REG_BADBR' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:400: error: `REG_BADPAT' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:401: error: `REG_BADRPT' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:402: error: `REG_ECOLLATE' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:403: error: `REG_ECTYPE' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:404: error: `REG_EESCAPE' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:405: error: `REG_ESUBREG' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:406: error: `REG_EBRACK' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:407: error: `REG_EPAREN' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:408: error: `REG_EBRACE' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:409: error: `REG_ERANGE' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:410: error: `REG_ESPACE' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:447: error: `regex_t' undeclared (first use
in this function)
Text\Regex\Posix\Wrap.hsc:481: error: syntax error before ')' token
Text\Regex\Posix\Wrap.hsc:484: error: `regmatch_t' undeclared (first
use in this function)
Text\Regex\Posix\Wrap.hsc:510: error: syntax error before ')' token
Text\Regex\Posix\Wrap.hsc:510: error: syntax error before int
Text\Regex\Posix\Wrap.hsc:511: error: syntax error before ')' token
Text\Regex\Posix\Wrap.hsc:511: error: syntax error before int
Text\Regex\Posix\Wrap.hsc:525: error: syntax error before ')' token
compiling dist\build\Text\Regex\Posix\Wrap_hsc_make.c failed
command was: D:\Program Files\Haskell
Platform\2010.2.0.0\mingw\bin\gcc.exe -c -D__GLASGOW_HASKELL__=612
-DHAVE_REGEX_H -DSPLIT_BASE
=1 -ID:\Program Files\Haskell
Platform\2010.2.0.0\lib\bytestring-0.9.1.7\include -ID:\Program
Files\Haskell Platform\2010.2.0.0\lib\
base-4.2.0.2\include -ID:\Program Files\Haskell
Platform\2010.2.0.0\lib/include -ID:\Program Files\Haskell
Platform\2010.2.0.0\lib/i
nclude -ID:/Program Files/Haskell Platform/2010.2.0.0/lib/include/
dist\build\Text\Regex\Posix\Wrap_hsc_make.c -o dist\build\Text\Re
gex\Posix\Wrap_hsc_make.o
cabal: Error: some packages failed to install:
regex-posix-0.94.2 failed during the building phase. The exception was:
ExitFailure 1

I am really clueless about the failure and what caused it.
Thanks for your help,

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


Re: [Haskell-cafe] vector-space and standard API for vectors

2010-10-30 Thread Stephen Tetley
On 30 October 2010 11:07, Henning Thielemann
schlepp...@henning-thielemann.de wrote:

 Looks like you are about to re-implement numeric-prelude. :-)


Ah, but Numeric-Prelude is huge though[*].

DavidA complains in the recent Cafe thread Decoupling type classes
(e.g. Applicative)? that the Num hierarchy can't be replaced due to
inertia. My own feeling is it can't be replaced because no-one can
define an acceptable middle ground between the two extremes:

miminal - Haskell currently (for discussion, we'll elide some of the
problems such as the Show superclass constriant).

huge - numeric-prelude or a mathematics system such as Aldor.


[*] This is not a criticism - just an observation.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Package regex-posix-0.94.2 suddenly failed to link

2010-10-30 Thread Stephen Tetley
Possibly related to this bug?

http://trac.haskell.org/haskell-platform/ticket/137
http://www.haskell.org/pipermail/haskell-cafe/2010-August/082141.html

I don't use cabal install, but maybe you could try just re-installing
regex-posix, then once its working reinstall the dependencies. That
seemed to be the solution in the Cafe thread.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] fundata1 -- Karmic Social Capital Benchmark and Shootout

2010-10-30 Thread Johan Tibell
On Fri, Oct 29, 2010 at 1:17 PM, Daryoush Mehrtash dmehrt...@gmail.com wrote:
 In the lessons you say:

 Haskell proved too slow with String Map, so we ended up interning strings
 and working with an IntMap and a dictionary to disintern back to strings as
 a last step.  Daniel Fisher was instrumental in bringing Haskell up to speed
 with OCaml and then beating it.  Don Stewart provided awesome leadership and
 amazing modification of Haskell's core data structured before your very
 eyes.

A quick tip for anyone who needs to work on large maps with string
keys in the future: try Milan Straka's hashmap package. String
comparison is expensive and using a size balanced tree causes O(log n)
of them. The HashMap data type uses an IntMap internally and typically
(in the absence of collisions) needs to traverse the string only once,
to compute the hash, and can then perform O(log n) cheap Int
comparisons.

I'm working on a more efficient hash function for ByteString and Text:
an implementation of MurmurHash. The HashMap data type and the need
hash function together should give us good performance for maps with
string keys.

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


Re: [Haskell-cafe] Package regex-posix-0.94.2 suddenly failed to link

2010-10-30 Thread Ben Millwood
On Sat, Oct 30, 2010 at 11:56 AM, Arnaud Bailly arnaud.oq...@gmail.com wrote:
 Hello,
 All of a sudden, the package regex-posix-0.94.2 failed to link after i
 installed a couple of other packages (http, json). When I try to
 reinstall it, I got the folowing errors:

 D:\projets\crete1941cabal install --global --reinstall
 --enable-documentation regex-posix-0.94.2
 Resolving dependencies...
 Configuring regex-posix-0.94.2...
 Preprocessing library regex-posix-0.94.2...
 Text\Regex\Posix\Wrap.hsc:107:19: regex.h: No such file or directory

This is the crucial line in this particular build failure, everything
else is fluff. I really, really wish gcc would learn to stop compiling
after a header file was missing, since it almost always results in
large amounts of nonsense errors.

It looks like cabal-install or possibly Cabal can't find your headers.
I notice you're compiling with an explicit --global option - why is
that? Is it currently installed locally or globally? You can use
'ghc-pkg list regex-posix' to check. You can also enable global
installs and documentation by default by editing your config file,
whose location is given in the output of cabal --help. You can also
specify extra-include-dirs there if you need to do that.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] ANNOUNCE: darcs 2.5

2010-10-30 Thread Reinier Lamers
Hi all,

The darcs team is proud to announce the release of darcs 2.5. Darcs 2.5 
contains many improvements over the 2.4 series. Most notable are the 
performance improvements in record and pull and the --bisect option for 
trackdown.

The easiest way to install darcs 2.5 is using the Haskell Platform [1]. If you 
have installed the Haskell Platform or cabal-install, you can install this 
beta release by doing:

  $ cabal update
  $ cabal install darcs

Alternatively, you can download the tarball from 
http://darcs.net/releases/darcs-2.5.tar.gz and build it by hand as 
explained in the README file.

What's New
--

A list of important changes since darcs 2.4.4:

   * trackdown can now do binary search with the --bisect option
   * darcs always stores patch metadata encoded with UTF-8
   * diff now supports the --index option
   * amend-record now supports the --ask-deps option
   * apply now supports the --match option
   * amend-record has a new --keep-date option
   * inventory-changing commands (like record and pull) now operate in
 constant time with respect to the number of patches in the repository
   * the push, pull, send and fetch commands no longer change the default
 repository address by default
   * the --edit-description option is now on by default for the send command

Issues resolved since darcs 2.4.4:

   * 64:   store metadata as UTF-8
   * 121:  add --ask-deps support to amend-record
   * 643:  darcs send -o outputs remote repo email address
   * 1159: avoid bogus repository cache entries
   * 1176: caches interfere with --remote-repo flag
   * 1208: add trackdown --bisect
   * 1210: global cache gets recorded in _darcs/prefs/sources
   * 1232: darcs convert copies _darcs/prefs/prefs
   * 1250: check for newlines in setpref values
   * 1277: percolate repository format errors correctly
   * 1288: the main darcs code now compiles and runs with witnesses
   * 1290: support diff --index
   * 1337: don't show unrelated patches in darcs changes on untracked path
   * 1389: change predist pref to point people to use 'cabal sdist'
   * 1427: accept gzipped patch bundles in darcs apply
   * 1456: make dist write more portable archives
   * 1473: make annotate accept '.' as argument
   * 1503: prefer local caches to remote ones
   * 1713: shorter interactive prompts
   * 1716: allow mail header lines of all whitespace in test
   * 1719: do not back up files when no conflict markers are inserted
   * 1726: don't consider all files with _darcs prefix boring
   * 1739: make ColorPrinter handle characters  255
   * 1763: use correct filename encoding in conflictors
   * 1765: refuse to remove non-tracked directories recursively
   * 1769: add support for --match 'comment ...'
   * 1784: push and pull print remote address right away
   * 1815: work around Cabal sdist permissions issue
   * 1817: fix support for external merge tools
   * 1824: avoid PACKAGE_VERSION under Windows
   * 1825: do not omit important prims in unrecordedChanges w/ files
   * 1860: (un)applying move patches doesn't corrupt pristine
   * 1861: fix typo in --no-boring help
   * 1874: recognise network tests on cabal test command line
   * 1875: avoid accidentally setting default
   * 1879: notice unexpected commute failure on merge
   * 1887: add a missing newline to --list-options output
   * 1893: move fields of conditional builds within scope of condition
   * 1898: notify user when they can use set-default
   * 1913: sort changes in treeDiff

Reporting bugs
--

If you have an issue with darcs 2.5, you can report it via the web on 
http://bugs.darcs.net/ . You can also report bugs by email to b...@darcs.net.

Kind Regards,
the darcs release manager,
Reinier Lamers

[1]: You can download the Haskell platform from
 http://hackage.haskell.org/platform/


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] Red links in the new haskell theme

2010-10-30 Thread Henning Thielemann
Victor Oliveira schrieb:
 Hi Cafe,
 
 I really liked the new colors of haskell theme, but...
 
 Is really red a good color for links?  At least for me, red links looks like 
 broken or already visited ones.
 
 And the worst is hackage docs. It is really eye tiring to read.
 
 It's just a thought. Maybe it just with me.

I'm also used to red=broken, blue=link, as in Wikipedia.

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


Re: [Haskell-cafe] type class design

2010-10-30 Thread Uwe Schmidt
Hi Ivan,

 Another possible argument: large type classes can look daunting for
 both implementors and users, even if only one or two methods need to
 be defined for a minimal instantiation (I'm tring to work out what to
 do here myself, as I have some typeclasses that for efficiency reasons
 it might be nice to have more methods in the class, but it makes it a
 little overwhelming).

But by putting just a small part of the interface into the class
does not make the live of a user any simpler.
The user usually has to know the whole interface of the module.
Or am I missing something?

Cheers,

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


Re: [Haskell-cafe] Red links in the new haskell theme

2010-10-30 Thread Henning Thielemann
Sebastian Fischer schrieb:
 Maybe we can keep at least the docs without red links.
 
 Pick the Classic style in the style menu. It will remember your choice.

I don't see a style menu. Does it require JavaScript? I find it still
strange, that the unusal style is the default.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Red links in the new haskell theme

2010-10-30 Thread Daniel Fischer
On Saturday 30 October 2010 13:51:25, Henning Thielemann wrote:
 Sebastian Fischer schrieb:
  Maybe we can keep at least the docs without red links.
 
  Pick the Classic style in the style menu. It will remember your
  choice.

 I don't see a style menu.

I do, top right, next to Index. In seamonkey, though, it's sometimes half 
hidden and displayed below the Source resp hackageDB links.

 Does it require JavaScript?

It seems so. If I disallow scripts for haskell.org, I don't see it either.

 I find it still strange, that the unusal style is the default.

Most people who responded when opinions were collected about the new theme 
preferred that.

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


Re: [Haskell-cafe] Red links in the new haskell theme

2010-10-30 Thread Henning Thielemann


On Sat, 30 Oct 2010, Daniel Fischer wrote:


I do, top right, next to Index. In seamonkey, though, it's sometimes half
hidden and displayed below the Source resp hackageDB links.


Does it require JavaScript?


It seems so. If I disallow scripts for haskell.org, I don't see it either.


If I enable JavaScript in Konqueror, I still see no style menu.

However I would like to get it without JavaScript. It can certainly be 
achieved using a cookie.


I never understood why Cascading Style Sheets were used to configure the 
appearance of a website from the server side. To me it would make more 
sense if users could configure the colors of links in their browsers, like 
they configure fonts and font sizes.



I find it still strange, that the unusal style is the default.


Most people who responded when opinions were collected about the new theme
preferred that.


Possibly when seeing, how it looks like, people change their mind. :-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Package regex-posix-0.94.2 suddenly failed to link

2010-10-30 Thread Arnaud Bailly
Hello Ben,
Thanks for your answer. What is strange is that I did not change
anything wrt include dirs or gcc or whatever...
I am using --global because I noticed ghc-pkg list gives me two
locations for regex-xxx packages. I removed everything from --user
though. I will try to reinstall regex-xxx.

Thanks
Arnaud

On Sat, Oct 30, 2010 at 1:35 PM, Ben Millwood hask...@benmachine.co.uk wrote:
 On Sat, Oct 30, 2010 at 11:56 AM, Arnaud Bailly arnaud.oq...@gmail.com 
 wrote:
 Hello,
 All of a sudden, the package regex-posix-0.94.2 failed to link after i
 installed a couple of other packages (http, json). When I try to
 reinstall it, I got the folowing errors:

 D:\projets\crete1941cabal install --global --reinstall
 --enable-documentation regex-posix-0.94.2
 Resolving dependencies...
 Configuring regex-posix-0.94.2...
 Preprocessing library regex-posix-0.94.2...
 Text\Regex\Posix\Wrap.hsc:107:19: regex.h: No such file or directory

 This is the crucial line in this particular build failure, everything
 else is fluff. I really, really wish gcc would learn to stop compiling
 after a header file was missing, since it almost always results in
 large amounts of nonsense errors.

 It looks like cabal-install or possibly Cabal can't find your headers.
 I notice you're compiling with an explicit --global option - why is
 that? Is it currently installed locally or globally? You can use
 'ghc-pkg list regex-posix' to check. You can also enable global
 installs and documentation by default by editing your config file,
 whose location is given in the output of cabal --help. You can also
 specify extra-include-dirs there if you need to do that.

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


Re: [Haskell-cafe] Package regex-posix-0.94.2 suddenly failed to link

2010-10-30 Thread Arnaud Bailly
Hello,
I managed to fix this issue reinstalling regex-posix (with a higher
version) and then reinstall regex-compat (broken through the
reinstall).

Thanks a lot for the pointer,
Arnaud

On Sat, Oct 30, 2010 at 1:08 PM, Stephen Tetley
stephen.tet...@gmail.com wrote:
 Possibly related to this bug?

 http://trac.haskell.org/haskell-platform/ticket/137
 http://www.haskell.org/pipermail/haskell-cafe/2010-August/082141.html

 I don't use cabal install, but maybe you could try just re-installing
 regex-posix, then once its working reinstall the dependencies. That
 seemed to be the solution in the Cafe thread.
 ___
 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] Red links in the new haskell theme

2010-10-30 Thread Sebastian Fischer

On Oct 30, 2010, at 9:15 PM, Henning Thielemann wrote:

To me it would make more sense if users could configure the colors  
of links in their browsers, like they configure fonts and font sizes.


Most browsers support user style sheets: google.com/search?q=user+style 
+sheet


Most people who responded when opinions were collected about the  
new theme

preferred that.


Possibly when seeing, how it looks like, people change their mind.


During the poll, the new style was shown on a demo page.

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


Re: [Haskell-cafe] Red links in the new haskell theme

2010-10-30 Thread Daniel Fischer
On Saturday 30 October 2010 14:15:58, Henning Thielemann wrote:
 On Sat, 30 Oct 2010, Daniel Fischer wrote:
  I do, top right, next to Index. In seamonkey, though, it's sometimes
  half hidden and displayed below the Source resp hackageDB links.
 
  Does it require JavaScript?
 
  It seems so. If I disallow scripts for haskell.org, I don't see it
  either.

 If I enable JavaScript in Konqueror, I still see no style menu.

In the Extras menu or in the global settings menu?
If I disable JavaScript in the global settings in Konqueror, the Style menu 
is gone and no futzing with HTML settings in the Extras menu will change 
that, while if JavaScript is enabled globally, I can turn it on/off per 
site and the Style menu will appear/disappear according to the setting 
(requires a reload, though).
I don't particularly like Konqueror's configuring behaviour, it's not easy 
to understand.


 However I would like to get it without JavaScript. It can certainly be
 achieved using a cookie.

 I never understood why Cascading Style Sheets were used to configure the
 appearance of a website from the server side. To me it would make more
 sense if users could configure the colors of links in their browsers,
 like they configure fonts and font sizes.

  I find it still strange, that the unusal style is the default.
 
  Most people who responded when opinions were collected about the new
  theme preferred that.

 Possibly when seeing, how it looks like, people change their mind. :-)

Possible. But I don't understand how people can get so worked up on such 
things so much¹. Both look fine to me.

[¹] Website design in general. Things look mostly so-so, until a 
professional designer comes in. Then, with a very few exceptions, things 
become horrible [that's not particular to _web_ design, it applies to all 
designers (post Wilhelm Wagenfeld)].

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


Re: [Haskell-cafe] Red links in the new haskell theme

2010-10-30 Thread Tillmann Rendel

Henning Thielemann wrote:

If I enable JavaScript in Konqueror, I still see no style menu.

However I would like to get it without JavaScript. It can certainly be
achieved using a cookie.


Both stylesheets are linked to from the text of the HTML files:

link href=ocean.css rel=stylesheet type=text/css title=Ocean /

link href=xhaddock.css rel=alternate stylesheet type=text/css 
title=Classic /


Firefox uses this information to populate a menu (View | Stylesheet) 
with the following choices:


 - no style
 - Ocean
 - Classic

No need for JavaScript or cookies.

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


Re: [Haskell-cafe] Red links in the new haskell theme

2010-10-30 Thread Daniel Fischer
On Saturday 30 October 2010 14:49:01, Daniel Fischer wrote:
 Both look fine to me.

Oh and btw. Regarding the topic of this thread, I don't see red links in 
the new theme, they're an orange-ish brown here.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Monads and Functions sequence and sequence_

2010-10-30 Thread Roman Cheplyaka
* Mark Spezzano mark.spezz...@chariot.net.au [2010-10-30 15:37:30+1030]
 Can somebody please explain exactly how the monad functions sequence
 and sequence_ are meant to work?

The others in this thread have already explained how these functions
work, so I'll just give an example how they are used.

Consider the following task: to read 30 lines from standard input.
For one line you would use an action

  getLine :: IO String

How to execute this 30 times? Haskell has a function

  replicate :: Int - a - [a]

which takes a number and produces a list with that number of
identical elements.

So this is close to what we need:

  replicate 30 getLine :: [IO String]

This is a list containing 30 'getLine' actions. But the list of
actions _is not_ an action itself. This is what sequence does -- it
transforms a list of actions into a single action which gathers the
results into one list. As its name suggests, it does sequencing of
actions.

  sequence $ replicate 30 getLine :: IO [String]

Exactly what we need, an action producing a list of lines read.

Now, let's consider this code:

  sequence [ putStrLn $ show i ++  green bottles standing on the wall
   | i - reverse [1..10] ] :: IO [()]

This action prints 10 lines and also returns us gathered results, i.e.
10 '()', one from each putStrLn (recall that putStrLn has type String - IO 
().

Most probably we don't care about those '()', but they still occupy
memory and introduce a space leak as explained here[1]. That's why a
version of sequence is introduced which ignores the results of actions
and simply returns (). It is called sequence_.

  sequence_ :: (Monad m) = [m a] - m ()

As a side note, we can rewrite our last example without using list
comprehension in the following way:

  let p i = putStrLn $ show i ++  green bottles standing on the wall
  in  sequence_ $ map p $ reverse [1..10]

The combinations of sequence and sequence_ with map are so common that
they have special names:

  mapM  = \f - sequence  . map f :: (Monad m) = (a - m b) - [a] - m [b]
  mapM_ = \f - sequence_ . map f :: (Monad m) = (a - m b) - [a] - m ()

[1] 
http://neilmitchell.blogspot.com/2008/12/mapm-mapm-and-monadic-statements.html

-- 
Roman I. Cheplyaka :: http://ro-che.info/
Don't let school get in the way of your education. - Mark Twain
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Red links in the new haskell theme

2010-10-30 Thread Henning Thielemann


On Sat, 30 Oct 2010, Tillmann Rendel wrote:


Both stylesheets are linked to from the text of the HTML files:

link href=ocean.css rel=stylesheet type=text/css title=Ocean /

link href=xhaddock.css rel=alternate stylesheet type=text/css 
title=Classic /


Firefox uses this information to populate a menu (View | Stylesheet) with the 
following choices:


- no style
- Ocean
- Classic

No need for JavaScript or cookies.


This would be optimal for me, if it would work this way. From the answers 
I understood that the style menu is something that is part of the 
document body, not something of the browser navigation toolset.


It seems that Konqueror does not let me choose between different styles. 
However it has a menu item for checking the CSS. :-) It forwards me to

  
http://jigsaw.w3.org/css-validator/validator?uri=http%3A//hackage.haskell.org/package/base
 and shows 7 errors.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Red links in the new haskell theme

2010-10-30 Thread Daniel Fischer
On Saturday 30 October 2010 15:09:39, Henning Thielemann wrote:
 On Sat, 30 Oct 2010, Tillmann Rendel wrote:
  Both stylesheets are linked to from the text of the HTML files:
 
  link href=ocean.css rel=stylesheet type=text/css title=Ocean
  /
 
  link href=xhaddock.css rel=alternate stylesheet type=text/css
  title=Classic /
 
  Firefox uses this information to populate a menu (View | Stylesheet)
  with the following choices:
 
  - no style
  - Ocean
  - Classic
 
  No need for JavaScript or cookies.

 This would be optimal for me, if it would work this way. From the
 answers I understood that the style menu is something that is part of
 the document body, not something of the browser navigation toolset.

 It seems that Konqueror does not let me choose between different styles.

Mine does, with JavaScript globally disabled or enabled:

Ansicht - Stilvorlage verwenden
* Autom. feststellen
* Basisstil
* Ocean
* Classic

 However it has a menu item for checking the CSS. :-)

I can't find that in mine, however.

 It forwards me to   
 http://jigsaw.w3.org/css-validator/validator?uri=http%3A//hackage.haskel
l.org/package/base and shows 7 errors.

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


[Haskell-cafe] Re: cabal mystery (#562?)

2010-10-30 Thread Maciej Piechotka
On Thu, 2010-10-28 at 15:33 +0200, Daniel Fischer wrote:
 On Thursday 28 October 2010 15:08:09, Conor McBride wrote:
  Any tips to keep the gremlins at bay gratefully appreciated.
 
 Don't feed after midnight, don't get them wet, I think were the tips.

Don't expose to bright light.

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


Re: [Haskell-cafe] Red links in the new haskell theme

2010-10-30 Thread Tillmann Rendel

Henning Thielemann wrote:

Firefox uses this information to populate a menu (View | Stylesheet)
with the following choices:

- no style
- Ocean
- Classic

No need for JavaScript or cookies.


This would be optimal for me, if it would work this way. From the
answers I understood that the style menu is something that is part of
the document body, not something of the browser navigation toolset.


Yes, the body of the document contains an additional style menu, so on 
well-behaving browsers, there are two style menus. See screenshot at


  http://www.informatik.uni-marburg.de/~rendel/style-menu.png

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


Re: [Haskell-cafe] Red links in the new haskell theme

2010-10-30 Thread Mark Lentczner
Some notes on the Haddock re-design:

1) HTML supports the concept of alternate style sheets. If present, then the 
idea was that browsers would give the user the choice, somewhere, to choose 
among them. While Firefox does this (View  Page Style), and I'm told that 
Opera (View  Style), and Konqueror (View  Use StyleSheet) do, the other 
big-name browsers, IE, Safari, Chrome, do not.

Since support is so lacking, the common thing to do, and what I implemented for 
Haddock, is to use Javascript to pull the alternate style sheet information out 
of the page and build a menu that is then placed back into the page. This is 
the Style menu in the top right of the page. If you have Javascript turned 
off, it won't appear as it is not part of the markup.

The cookie, which is set from Javascript is so that you don't to re-pick the 
style on every page load. I'm assuming that those browsers that do implement a 
style sheet menu remember this per-site, but I don't know. It is a limitation 
of cookies that it can only remember your choice per-site.


2) What styles appear depend on what was specified when Haddock was run to 
produce the pages. By default it includes just the new Ocean theme. If 
--default-themes is specified (as it is on Hackage), then both Ocean and 
Classic are included. You can build your own themes and include them with 
--theme, alone or in combination with the built-in themes.

If the resulting theme set is a singleton, then no Style menu will appear on 
the page.


3) Without really doing a tracking analysis (preferably by tracking eye 
movements, or at least mouse movements, and in all cases recording accurate 
view times and location of clicks), it isn't possible to optimize a web page 
down to the level of which menu links should be in in which order, or other 
such small changes. That isn't saying such changes won't have a big impact, 
only that it is hard to reason about them because the tracking results are 
often non-intuitive. In the absence of such things, all one can do is bring 
one's experience and design skills to bear.


4) While Haddock tries to minimize the use of Javascript, it still has some. 
There is a tension between wanting to produce pages that can be printed 
documentation, and creating a effective on-line reference. Between the theming 
ability, and the new LaTeX backend, it is now possible to achieve these two 
aims with separate Haddock outputs.

In modern browsers, Javascript is very efficient and even moderate amounts of 
Javascript can be crafted to not affect load times. Haddock still has an issue 
here that the Javascript is repeated in every directory, thus ruining caching. 
When this is fixed, we'll be able to use more Javascript, which will enable us 
to make the reference easier and faster to navigate.[1]


5) It does not make sense for users to configure colors or fonts for web sites 
any more than it would for magazines or books. Effective presentation of 
information requires design including choice of fonts, colors, graphics and 
layout - and these vary by the information and intent of the content. There is 
no choice a user an make that works best for all.

It is important for accessibility that those users that need to can override 
fonts and colors. All modern browsers allow this, and one of the major aims of 
the Haddock redesign was to output clean markup so that it worked in such 
situations, as well as with screen readers. In other words - if you want to 
override the fonts and colors you can now do so effectively.


6) Over the Summer the new style was made available on the web for people to 
look out for several months, and at one point I conducted a poll. In that poll 
only 81% preferred the newer look, and only 11% preferred the older.


  - Mark Haddock web scullion Lentczner


[1] An example of an HTML reference work that is highly usable and uses plenty 
of Javascript (700k!) to achieve it, yet works very well: 
http://developer.android.com/reference/packages.html


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


Re: [Haskell-cafe] Red links in the new haskell theme

2010-10-30 Thread Henning Thielemann


On Sat, 30 Oct 2010, Tillmann Rendel wrote:

Yes, the body of the document contains an additional style menu, so on 
well-behaving browsers, there are two style menus. See screenshot at


 http://www.informatik.uni-marburg.de/~rendel/style-menu.png


Wow, I have also such a menu item Ansicht with sub-item Stilvorlage 
and subsubitem Ocean and Classic in Konqueror! I still wonder why Ocean 
looks red, and not blue. But ok, Classic looks as I like it.

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


Re: [Haskell-cafe] Red links in the new haskell theme

2010-10-30 Thread Henning Thielemann


On Sat, 30 Oct 2010, Mark Lentczner wrote:

5) It does not make sense for users to configure colors or fonts for web 
sites any more than it would for magazines or books.


For fancy layouts we have PDF. For me, HTML is an online format that shall 
be as adaptive as possible to font size, window size, screen resolution 
and other parameters.


6) Over the Summer the new style was made available on the web for 
people to look out for several months, and at one point I conducted a 
poll. In that poll only 81% preferred the newer look, and only 11% 
preferred the older.


Somehow I missed that poll, and it seems others have, too.


Two notes on the Classic style:

The package field names like Version, Dependencies, License are centered, 
which was not the case in the original style. Also in the original style 
the table cells had a grey background, what I found quite useful for 
recognizing the table structure.

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


Re: [Haskell-cafe] Edit Hackage

2010-10-30 Thread Ketil Malde
Daniel Fischer daniel.is.fisc...@web.de writes:

 On Saturday 30 October 2010 03:42:27, Ivan Lazar Miljenovic wrote:
 On 30 October 2010 12:22, Lauri Alanko l...@iki.fi wrote:
 On Thu, Oct 28, 2010 at 01:55:12PM -0700, Don Stewart wrote:
 The number of subscribers to the Haskell Reddit, for example, is
 [...]
 In short, the old technologies of mail and news are technically vastly
 superior
 [..]
 +1; that's pretty much my opinion/arguments as well.
 +1; same here.

I agree too, but not without pointing out that on SO, you'd just be
clicking to vote up, rather than quoting the entire mail and adding one
line.  So there are some advantages.

Ivan L. M. wrote: 

 So you'd prefer to have the discussion about a blog post be made
 distinct from the blog post itself?

The problem with blog comments and other web forums is, in addition to
the hopeless interfaces they invariably are equipped with, that they are
scattered.  I very rarely check back to follow up on comments (except on
my own site :-), and I rarely bother to register to add my voice.  So,
yes, I would like discussion to take place with some central
coordinaton.

Stack Overflow and Reddit are at least improvements over the traditional
web forums, starting to acquire some of the features Usenet had twenty
years ago.  Much like Planet-style meta-blogs and RSS syndication makes
it liveable to follow blogs.

The important thing is making all the resources visible, and bringing
stuff together.  HWN is great, I don't follow Reddit, but I do click on
the links that look interesting.  Is there something going in the other
direction, pointing SO users to mailing list threads, for instance?
Most web-based email archives seem to suck - where can we point to a nice
URL to get an overview of a -cafe thread?

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


Re: [Haskell-cafe] Red links in the new haskell theme

2010-10-30 Thread Ross Paterson
On Sat, Oct 30, 2010 at 05:26:33PM +0200, Henning Thielemann wrote:
 Two notes on the Classic style:
 
 The package field names like Version, Dependencies, License are
 centered, which was not the case in the original style. Also in the
 original style the table cells had a grey background, what I found
 quite useful for recognizing the table structure.

This refers to the hackage package pages using the haddock style files,
which have no provision for two-tone tables.  The alignment is fixed
now, though.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Red links in the new haskell theme

2010-10-30 Thread Henning Thielemann


On Sat, 30 Oct 2010, Ross Paterson wrote:


On Sat, Oct 30, 2010 at 05:26:33PM +0200, Henning Thielemann wrote:

Two notes on the Classic style:

The package field names like Version, Dependencies, License are
centered, which was not the case in the original style. Also in the
original style the table cells had a grey background, what I found
quite useful for recognizing the table structure.


This refers to the hackage package pages using the haddock style files,
which have no provision for two-tone tables.


I see.


 The alignment is fixed now, though.


It's still vertically centered, which makes it difficult to see, e.g. 
where the dependency list starts and where it ends if it is several lines 
long.

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


Re: [Haskell-cafe] Edit Hackage

2010-10-30 Thread C. McCann
On Sat, Oct 30, 2010 at 11:34 AM, Ketil Malde ke...@malde.org wrote:
 Stack Overflow and Reddit are at least improvements over the traditional
 web forums, starting to acquire some of the features Usenet had twenty
 years ago.  Much like Planet-style meta-blogs and RSS syndication makes
 it liveable to follow blogs.

Very much this. I mourn Usenet's potential as much as anyone, but life
goes on. I'll also note that some private sites take reasonable
steps to promote openness. To use Stack Overflow as an example again,
all content on the site is under a Creative Commons license and they
provide torrents of raw data dumps containing everything but private
information about users. So if someone wanted, it'd be possible
(probably even easy) to do something like mirror all the content in
the [haskell] tag somewhere on haskell.org without any advertising or
extraneous SO-related stuff cluttering it up, perhaps re-organized
into a more structured FAQ format.

 The important thing is making all the resources visible, and bringing
 stuff together.  HWN is great, I don't follow Reddit, but I do click on
 the links that look interesting.  Is there something going in the other
 direction, pointing SO users to mailing list threads, for instance?
 Most web-based email archives seem to suck - where can we point to a nice
 URL to get an overview of a -cafe thread?

Well, it's always good form to provide relevant links in SO answers,
but I'm more likely to direct people to the wiki on Haskell.org, the
online Haskell report, Hackage, various blogs, or occasional research
papers. I have seen relevant -cafe threads mentioned on occasion,
typically using the archive at haskell.org/pipermail and linking to a
specific message.

As you say, most email archives leave something to be desired. As far
as I know, the best way to find anything in old -cafe threads is to do
a google search with
site:http://www.haskell.org/pipermail/haskell-cafe/;, and there's no
good way to get an overview. Especially as topic drift leads to
subject lines being uninformative (I mean, Edit Hackage? What?).

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


Re: [Haskell-cafe] Red links in the new haskell theme

2010-10-30 Thread Ross Paterson
On Sat, Oct 30, 2010 at 06:39:00PM +0200, Henning Thielemann wrote:
 It's still vertically centered, which makes it difficult to see,
 e.g. where the dependency list starts and where it ends if it is
 several lines long.

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


[Haskell-cafe] How can we make Haskell-Cafe scale? (was: Re: Edit Hackage)

2010-10-30 Thread Sterling Clover
There's been some grumbling about users migrating from -cafe to Reddit and 
Stack Overflow in particular. First, as Don has pointed out, the fact is that 
people are moving away, and that's just the trend. 

But why are people moving? One reason is that Stack Overflow, Reddit, and -cafe 
all provide *different things*, with features tailored to specific purposes. 
I'll try to explain what those things are, why they don't threaten, but augment 
-cafe, and why we need at least one new mailinglist as well.

1. When Stack Overflow is Better Than -cafe

Stack Overflow is *better* for a QA format. I can scan for questions I'm 
competent to answer or interested in answers to (and the rss feed helps with 
that), and be confident that for the most part there won't be thread derails, 
and that the title will maintain consistency with the discussion inside. If the 
title isn't informative, I can be confident that someone with sufficient rights 
(which are granted by accumulation of karma) will edit it to be informative. 
Likewise the question itself, if it evolves over time, can be edited to reflect 
what it should have been to begin with.

And most importantly, if an answer to a question is provided on -cafe, it 
quickly gets drowned in surrounding traffic. And if an answer becomes out of 
date, there's no good way to annotate the archives to indicate that. I don't 
*need* to read all s.o. questions, on the off chance than an answer might 
become relevant to me later. I know that s.o. provides the right tools so I can 
find the answer when I need it. And I know that s.o. lets users update pages 
with new posts, or edits, so that answers don't become stale over time.

A technical QA site serves different purposes than a mailinglist, and it needs 
different technology to do so. There are other, smaller, advantages to 
stackoverflow which I haven't even touched on.

2. When Reddit is Better Than -cafe

As for reddit, while some people obviously treat -cafe as an anything goes 
place to crack jokes or pursue arguments of rather narrow interest, I'm acutely 
aware that every message sent to this list lands in the mailbox of thousands 
some multiple thousands of programmers, many very talented, and almost all with 
better things to do than wade through the massive traffic of -cafe for the few 
things of interest to them.

So, generally, I tend to shy away from posting to -cafe. Reddit, on the other 
hand has (although maybe a bit too much) a bit more of the freewheeling 
atmosphere of, e.g., the #haskell irc channel. People are going to reddit 
during a long compile, or on a coffee break. There's an understanding that the 
conversation will tend to be casual, that there will be occasional trolls and 
occasional gems, and that the primary content will be in high-quality links to 
papers, blogposts, articles, etc., while the discussion threads will be a way 
to shoot the breeze about them. This distinction between content and chatter is 
in many ways a useful thing.

Again, the medium of reddit facilitates this type of content. Because messages 
are shown in their threaded context with relatively high information density, 
they don't have to quote or indicate their surrounding context. The incremental 
cost of each message, both to reader and writer, is tiny, and this facilitates 
a more free-flowing conversational style than over email. Again, upvotes and 
downvotes (the dreaded ratings and karma) make it easy to see immediately which 
points others found useful or bogus, and to register simple agreement or 
disagreement without adding more semantic noise to the mix.

3. How -cafe Can Be Better than -cafe

If Stack Overflow is better for QA and Reddit is better for link aggregation 
and casual chat, that doesn't mean that -cafe should lose subscribers, or pack 
up and go home. It means that -cafe can shed those aspects, and get on with 
what *is* better here. For example, the recent set of DSL conversations have 
been very rich and productive. And I can't think of an online fora besides 
-cafe where they could have taken place.

In one sense, because -cafe has too many posts, it in fact has too few 
subscribers. Plenty of people who do great work in Haskell, either as academics 
or commercially, don't have the time and energy to devote to -cafe, even though 
there are conversations that would be perfect for them.

-cafe has averaged about 50 posts/day for this last month. Of those, I'd say 
about 2/3 are on topic for what I'd like -cafe to be. Some followed from 
release announcements which led into discussions of some aspect of the project. 
Some were related to issues with standard libraries, widely-used packages or 
otherwise relevant to the whole of the Haskell community. Some were well served 
by taking the temperature of the Haskell community (e.g. the lambda-case 
discussion). And some were questions suited to generating a broad discussion 
rather than one or two correct single answers.

The other third, by my