Hi Deniz, you're probably right, but I'm looking for a web-based solution so I could access it from different machines / desktops. I'm doing work in about half a dozen different VMs. Günther Am 18.11.2009, 18:17 Uhr, schrieb Deniz Dogan :

2009/11/18 Günther Schmidt :

...

Hi,

I'm finally about to organize myself, somewhat.

And am going to use a wiki for it. Does there a good one exist that's written in Haskell?

Günther

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

Not what you were looking for, but org-mode in Emacs is great for "organizing stuff".

From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of S. Doaitse Swierstra

How about:

http://hackage.haskell.org/package/orchid

a simple, but nice wiki produced by one of our students Sebastiaan Visser,

You can see it in action here: http://funct.org/wiki/ http://funct.org/wiki/#Building%20a%20Wiki%20in%20Haskell.html Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

On Sat, Nov 21, 2009 at 11:14 AM, Vladimir Ivanov wrote:

I decided to give orchid a try, but failed to install the latest version (0.0.8) using cabal.

The reason is that one of the dependencies (filestore) depends on parsec-2.0.* and orchid requires parsec3. I installed filestore-0.2 separately, but nothing changed.

$ cabal install orchid Resolving dependencies... cabal: cannot configure filestore-0.2. It requires parsec ==2.* For the dependency on parsec ==2.* there are these packages: parsec-2.0, parsec-2.1.0.0 and parsec-2.1.0.1. However none of them are available. parsec-2.0 was excluded because orchid-0.0.8 requires parsec ==3.0.* parsec-2.1.0.0 was excluded because orchid-0.0.8 requires parsec ==3.0.* parsec-2.1.0.1 was excluded because orchid-0.0.8 requires parsec ==3.0.*

$ ghc-pkg list filestore /usr/lib64/ghc-6.10.1/./package.conf: ~/.ghc/x86_64-linux-6.10.1/package.conf:    filestore-0.2, filestore-0.3.2, filestore-0.3.3

$ ghc-pkg list parsec /usr/lib64/ghc-6.10.1/./package.conf:    parsec-2.1.0.1, parsec-3.0.0

$ cabal --version cabal-install version 0.6.2 using version 1.6.0.2 of the Cabal library

Have you seen this before? I hope I overlooked something trivial... =)

-- vi

Apparently you can build filestore with parsec-3 if you want. Data/FileStore/Git.hs doesn't seem to use any of the functionality that changed between 2 & 3. I swapped the dep: hunk ./filestore.cabal 35 - parsec >= 2 && < 3, process, time, datetime, regex-posix, xml, split, Diff + parsec >= 3, process, time, datetime, regex-posix, xml, split, Diff Configured, noticing what parsec was being used: Dependency parsec >=3: using parsec-3.0.0 Built & installed successfully. -- gwern

On Sat, Nov 21, 2009 at 1:13 PM, John MacFarlane wrote:

+++ Gwern Branwen [Nov 21 09 11:38 ]:

...

On Sat, Nov 21, 2009 at 11:14 AM, Vladimir Ivanov wrote:

...

I decided to give orchid a try, but failed to install the latest version (0.0.8) using cabal.

The reason is that one of the dependencies (filestore) depends on parsec-2.0.* and orchid requires parsec3. I installed filestore-0.2 separately, but nothing changed.

$ cabal install orchid Resolving dependencies... cabal: cannot configure filestore-0.2. It requires parsec ==2.* For the dependency on parsec ==2.* there are these packages: parsec-2.0, parsec-2.1.0.0 and parsec-2.1.0.1. However none of them are available. parsec-2.0 was excluded because orchid-0.0.8 requires parsec ==3.0.* parsec-2.1.0.0 was excluded because orchid-0.0.8 requires parsec ==3.0.* parsec-2.1.0.1 was excluded because orchid-0.0.8 requires parsec ==3.0.*

$ ghc-pkg list filestore /usr/lib64/ghc-6.10.1/./package.conf: ~/.ghc/x86_64-linux-6.10.1/package.conf:    filestore-0.2, filestore-0.3.2, filestore-0.3.3

$ ghc-pkg list parsec /usr/lib64/ghc-6.10.1/./package.conf:    parsec-2.1.0.1, parsec-3.0.0

$ cabal --version cabal-install version 0.6.2 using version 1.6.0.2 of the Cabal library

Have you seen this before? I hope I overlooked something trivial... =)

-- vi

Apparently you can build filestore with parsec-3 if you want. Data/FileStore/Git.hs doesn't seem to use any of the functionality that changed between 2 & 3. I swapped the dep:

 hunk ./filestore.cabal 35  -                         parsec >= 2 && < 3, process, time, datetime, regex-posix, xml, split, Diff  +                         parsec >= 3, process, time, datetime, regex-posix, xml, split, Diff

Configured, noticing what parsec was being used:

 Dependency parsec >=3: using parsec-3.0.0

Built & installed successfully.

This is a bit of a problem.  gitit requires parsec >= 2 && < 3, so gitit needs filestore to depend on parsec-2.  The reason why is that pandoc depends on parsec-2, and the reason pandoc depends on parsec-2 is that parsec-2 is significantly faster than parsec-3. (I've verified this with several benchmarks, and so have others.)

John

This doesn't surprise me; but how much slower are we talking? If it's not at the point that a browser of a Gitit wiki could notice the difference, then it seems to me that the dep ought to be loosened: the parsec/quickcheck/base diamond dependency problem is one of the worst ones a user can run into, the hardest to resolve, and one that can arise in the course of ordinary safe use of Haskell. -- gwern

On Sun, Nov 22, 2009 at 11:56 AM, Antoine Latter wrote:

Running 'pandoc --strict' over the Markdown readme.text takes:

~0.09s with pandoc built against parsec-2 ~0.19s with pandoc built against parsec-3

on my machine.

I have a branch of parsec-3 which seems to brings us back to parsec-2 numbers, but also fails the rst-reader test-case in the pandoc testing suite:

http://community.haskell.org/~aslatter/code/parsec/cps

In reply to my own post, the branch of parsec posted now passes all of the pandoc test cases. If there are any other consumers of the parsec library that have tests I can run let me know. The 'many' combinator is one of those things that can look right, be wrong, yet work for almost everything. Antoine