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
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/gitit
Not what you were looking for, but org-mode in Emacs is great for
"organizing stuff".
--
Deniz Dogan
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 <deniz.a...@gmail.com>:
> 2009/11/18 Gᅵnther Schmidt <gue.s...@web.de>:
>> 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
http://hackage.haskell.org/package/orchid
a simple, but nice wiki produced by one of our students Sebastiaan
Visser,
Doaitse Swierstra
On 18 nov 2009, at 18:14, G�nther Schmidt wrote:
> 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
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.
*****************************************************************
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
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
> And am going to use a wiki for it. Does there a good one exist that's written in Haskell?
Not Haskell, but here is a simple one in Lua, Nanoki:
http://svr225.stepx.com:3388/nanoki
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
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
Antoine
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.