cliki (wiki engine) sources and project
Victor
I've noticed that the information on the Cliki Wiki
engine in the Cliki.net article ( http://www.cliki.net/CLiki )
is a bit outdated:
The sources tarball is on www.telent.net which is not
responding right now.
Darcs repository is on the verisons.telent.net which is not
responding either.
Wikipedia article says that the last change timestamp is
around 2005.
Bugs list http://www.cliki.net/CLiki%20Bugs contains rather
old items (dating back several years ago).
There is a placeholder project on Common-Lisp.Net:
http://common-lisp.net/project/cliki/
But it is empty: did not find a repository or anything
else.
This all makes an impression as if CLiki is abandoned.
However one of the most important CL projects (CLiki.net)
depends on it.
Are there any chances to revive the project? Is there any
reason to try?
Happy New Year
Victor
Pascal J. Bourguignon
Did you find any bug in http://www.cliki.net/ ?
If so, do you have any patch to provide?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Victor
Technically — no, I've noticed no bugs.
Formally: the article on the http://www.cliki.net
is outdated breaking CLiki ASDF-INSTALL.
In addition, the repository with the source is not
available either, which means there is no reference
to create patches against (if anybody wanted to).
If somebody on this group knows where I can get the
"reference" repository (it was on Darcs, probably
somebody still has a clone of it) then I could ask
the CLiki project maintainers on the http://common-lisp.net
to publish this repository.
Finally, when these issues are settled I could ask
a write permission on http://www.CLiki.net to
update the relevant article.
With best regards,
Victor
D Herring
> This all makes an impression as if CLiki is abandoned.
> However one of the most important CL projects (CLiki.net)
> depends on it.
>
> Are there any chances to revive the project? Is there any
> reason to try?
Cliki is very close to being abandonware. There was a fork of cliki
which added several features; but that disappeared for various
reasons. Drew Crampsie is the current keeper of the Cliki flame; his
home directory contains a ucliki tarball, but he doesn't have time to
maintain it.
http://common-lisp.net/~dcrampsie/
With minor modifications, that code is running one or two public
wikis. However, it is not industrial strength.
cl-wiki is a related project in a similar state.
http://common-lisp.net/project/cl-wiki/
Personally, I feel no need to rewrite mediawiki in CL. To me, wikis
are commodity software and there are more interesting programs to be
written. I also dislike HTML, DOM, Ajax, etc.; they are so crufty,
they beg for somebody to develop a better open browser standard.
But if web development is your thing, by all means contact Drew and
have at it. I know several people in the lisp community who would
greatly appreciate a wiki as a flagship lisp project, but none who are
doing the lifting.
Later,
Daniel
Drew Crampsie
> Hello,
>
> I've noticed that the information on the Cliki Wiki
> engine in the Cliki.net article ( http://www.cliki.net/CLiki )
> is a bit outdated:
> This all makes an impression as if CLiki is abandoned.
> However one of the most important CL projects (CLiki.net)
> depends on it.
The codebase that runs cliki.net is effectively abandoned... it runs
araneida under SBCL serve-event and requires some hacking to run in
modern SBCL's (it does't like unicode much). I have not touched the
source code in years.
>
> Are there any chances to revive the project? Is there any
> reason to try?
As Daniel mentioned, ucliki is the continuation of the cliki project,
and i intend that it someday replace the cliki engine on the cliki sites
(sbcl-internals, mccliki and cliki.net). It contains the "good" parts of
cliki (the storage engine, the markup rendering) with rucksack to store
history and UnCommon Web to handle the front end.
Unfortunately, i have not had the time to work on it recently. If you'd
like to give it a go, let me know, i'd be happy to give you any guidance
you might need, and can provide you with resources as well.
As Daniel mentioned, ucliki is not quite up to running cliki.net yet,
but i know exactly what needs to be done... it's really a simple
matter of code. I'd welcome the help.
Cheers,
drewc
>
> Happy New Year
> Victor
Victor
Hello Drew,
Apart from having the wiki written in Common Lisp what benefits
will ucLiki have compared to other wikis?
Are there any reasons not to use some other Wiki engine?
I've been reading the Common Lisp wikibook when I thought
that some parts of it should be better placed on CLiki
(package-specific stuff and the things beyond beginner level).
Then I realized that the CLiki isn't that convenient to
write documentation as the MediaWiki is.
And now it appears that the CLiki engine itself is very
close to be abandoned.
So are there considerable benefits for having another
Wiki engine when there are plenty of them available? What if
it were possible to run MoinMoin on top of CLPython?
Thanks,
Victor
Pascal J. Bourguignon
> Apart from having the wiki written in Common Lisp what benefits
> will ucLiki have compared to other wikis?
>
> Are there any reasons not to use some other Wiki engine?
>
> I've been reading the Common Lisp wikibook when I thought
> that some parts of it should be better placed on CLiki
> (package-specific stuff and the things beyond beginner level).
> Then I realized that the CLiki isn't that convenient to
> write documentation as the MediaWiki is.
>
> And now it appears that the CLiki engine itself is very
> close to be abandoned.
>
> So are there considerable benefits for having another
> Wiki engine when there are plenty of them available? What if
> it were possible to run MoinMoin on top of CLPython?
It seems to me that having the ability to easily add features such as
:(package "http://....") to the wiki is a good thing, and easier to do
for a lisp programmer if the wiki is written lisp.
Drew Crampsie
>
> Hello Drew,
>
> Apart from having the wiki written in Common Lisp what benefits
> will ucLiki have compared to other wikis?
High performance datastore and history
Advanced control flow operators (not so important for ucliki itself, but i embed
it)
cliki-compatible syntax (including ASDF-INSTALL support)
Not written in a crappy interpreted language.
>
> Are there any reasons not to use some other Wiki engine?
Performance is one. The fact that i like common lisp is
important. Compatibility with cliki syntax is important, and no other
wiki engine will ever be behind cliki.net on my watch... it's the common
lisp wiki after all.
> I've been reading the Common Lisp wikibook when I thought
> that some parts of it should be better placed on CLiki
> (package-specific stuff and the things beyond beginner level).
> Then I realized that the CLiki isn't that convenient to
> write documentation as the MediaWiki is.
There's a common lisp wikibook? What is a wikibook?
Regardless, i have to say that the kind of information that belongs in a
book is not really what cliki is for.. cliki is for links and resources
more than for 'how to use packages' type documents.
What makes you think that documentation that belongs in a book would we
better on cliki? What features were missing from cliki that make it hard
to write documentation?
> And now it appears that the CLiki engine itself is very
> close to be abandoned.
Indeed... uCliki is the successor, but as mentioned needs a little love
before it can run cliki.net
>
> So are there considerable benefits for having another
> Wiki engine when there are plenty of them available?
Yes... i'm a lisper, i like lisp, writing in lisp, and supporting lisp
software. Are there any benifits to having another programming language
when there are plenty of them available?
> What if
> it were possible to run MoinMoin on top of CLPython?
That would be a neat application of CLPython, but would never run
cliki.net or any of the other services i support (for free), because i
am a lisp programmer who programs in lisp, and not python!
In my experience hosting wiki engines written in python (trac), i can't
afford the CPU cycles. You can write an interpreter for any language in
CL, but that does not make that language CL :).
If you want to run MoinMoin on python and create a 'wikibook' for CL
packages, nobody will stop you, but it's not going to replace cliki.net,
the sbcl-internals wiki, the mcclim wiki, the ALU wiki, the Tech.coop
homepage, and all my client sites which run various incarnations of the
cliki engine... and won't be written in Common Lisp.
If all you want to do is write a document about the package system, try
org-mode... an amazing tool for writing documents, and it contains an
automatic export to a cliki compatible syntax.
Cheers,
drewc
>
> Thanks,
> Victor
Victor
> Victor <bobbie...@uanospam.fm> writes:
>> I've been reading the Common Lisp wikibook when I thought
>> that some parts of it should be better placed on CLiki
>> (package-specific stuff and the things beyond beginner level).
>> Then I realized that the CLiki isn't that convenient to
>> write documentation as the MediaWiki is.
>
> There's a common lisp wikibook? What is a wikibook?
Here it is: http://en.wikibooks.org/wiki/Common_Lisp
I thought that this section would be better hosted
on CLiki.net: http://en.wikibooks.org/wiki/Common_Lisp/External_libraries
Could you please list some things that have to be
completed in the ucLiki to make it closer to be ready
to run CLiki.net? Are they complex/difficult?
Thanks,
Victor
Drew Crampsie
> On Mon, 04 Jan 2010 21:37:52 +0200, Drew Crampsie <dr...@tech.coop> wrote:
>
>> Victor <bobbie...@uanospam.fm> writes:
>
>>> I've been reading the Common Lisp wikibook when I thought
>>> that some parts of it should be better placed on CLiki
>>> (package-specific stuff and the things beyond beginner level).
>>> Then I realized that the CLiki isn't that convenient to
>>> write documentation as the MediaWiki is.
>>
>> There's a common lisp wikibook? What is a wikibook?
>
> Here it is: http://en.wikibooks.org/wiki/Common_Lisp
>
> I thought that this section would be better hosted
> on CLiki.net:
> http://en.wikibooks.org/wiki/Common_Lisp/External_libraries
There are already many pages listing libraries on cliki.net... what
makes this section any different?
Some odd choices in that list too... SCREAMER is there but SERIES is
not? Whose list is this? I think that should be disclosed :)
>
> Could you please list some things that have to be
> completed in the ucLiki to make it closer to be ready
> to run CLiki.net? Are they complex/difficult?
The main one right now is that the session table is not properly
cleared, so after a month of use or so it hits LDB with a OOM. This is a
trivial fix.
After that it's all gravy... none of the tasks are complex/difficult
from my POV... an experienced lisper, especially a web developer, would
not too many issues.
Unfortunately, i'm not in a position to tell if the tasks will be
complex/difficult for you, or what your definition of complex/difficult
is. I can, however, offer advice and support should you wish to help.
Cheers,
drewc
>
> Thanks,
>
> Victor
Victor
> Victor <bobbie...@uanospam.fm> writes:
>> Could you please list some things that have to be
>> completed in the ucLiki to make it closer to be ready
>> to run CLiki.net? Are they complex/difficult?
>
> The main one right now is that the session table is not properly
> cleared, so after a month of use or so it hits LDB with a OOM. This is a
> trivial fix.
After briefly grepping through the sources it looks like
the problem is in the UCW implementation since ucw-cliki does
not explicitly handle sessions.
It looks like that the UCW mailing lists are a better place
to discuss the issues.
Thanks,
Victor
Drew Crampsie
> On Tue, 05 Jan 2010 21:30:16 +0200, Drew Crampsie <dr...@tech.coop> wrote:
>
>> Victor <bobbie...@uanospam.fm> writes:
>>> Could you please list some things that have to be
>>> completed in the ucLiki to make it closer to be ready
>>> to run CLiki.net? Are they complex/difficult?
>>
>> The main one right now is that the session table is not properly
>> cleared, so after a month of use or so it hits LDB with a OOM. This is a
>> trivial fix.
>
> After briefly grepping through the sources it looks like
> the problem is in the UCW implementation since ucw-cliki does
> not explicitly handle sessions.
Not quite... the implementation itself is fine... i've been using it in
production for some 5+ years now. The problem is that ucw-cliki does not
explicitly handle sessions, so they are left to collect until OOM.
>
> It looks like that the UCW mailing lists are a better place
> to discuss the issues.
Ya, or #ucw, or just email me. I maintain UCW as well, so you're going
to end up talking with me no matter where you go :).
Cheers,
drewc
>
> Thanks,
>
> Victor