All the Perl that's Practical to Extract and Report

bye for a while / odd announcement

perl6doc on 2010-05-09T01:48:19

After adding all meta ops and contextualizer with associated functions and adding the escape sequences too, I'm done so far. Not with Perl 6 but I have achieved for now what I wanted and will turn to Kephra for a while. The next release just needs a hour or two and i got some fresh ideas too. With 568 entries in the Appendix A and knowing that A-C are in good shape and almost completely n'cync with german version I can leave with good feeling.

Yesterday I also updated wikipedia article about Perl. A section about 5.12 was missing and the section about current versions needed to be rewritten. So this corner is also cleared.

I use for my dayly work almost only Kephra and I really need some features to ease my doings.

But that was not the odd thing I wanted announce. attention please. The thing I'm going to propose is odd because I want it but I'm not willing to do it myself.

My dream is that the TPF wiki is run by a wikisoftware that doesnt suck and is written in perl 6. There is an attempt called november but it stuck since masak does other exciting stuff. I think parsing and rehashing data is the strength of Perl 5 and more so Perl 6. The second reason for a wiki software written in Perl 6 would be. Perl 6 needs a killer app (odd and unnecessary brutal marketing term). I have a feature set in my mind no other wiki today provides. a desirable software could be for many people the reason to install parrot/Perl 6 in the first place.

Mediawiki is not bad but its wikisyntax has still some limitations which is compensated by a lot of extention. it gone a bit like C++ plus and has no tags and other modern achievements. Socialtext sucks completely. sorry but it has so many limitantions, its hardly usable as a wiki for coding documentation. also foswiki, thewikiformerlyknownasTwiki is often a pain in the ass. what I need is a wiki where

  • tables and pre areas that aren't inherently ugly
  • tables and pre areas should contain links and all sorts of text formating
  • user can change font family and size of different elements, so that there are actually readable
  • a wiki syntax allows easily to display any character, despite its normal meta meaning
  • editable article sections
  • easy spam redo / group redos
  • readable coloured diffs / no 10 pages display when all was changes are 10 char
  • searchable history
  • links with implicit anchors, so i can set in the index a link to the alias term
  • or at least link anchors that doesn't do a implicit "\n"
  • source code highlighting
  • ... many more
Yes the third benefit would be that just my life would be easier. But i realized many of these features doesn't require much coding. Its just my dream may it will come true in this world.

ikiwiki

ptman on 2010-05-09T09:18:26

Please take a good look at ikiwiki before designing a new wiki. It has some very good ideas.

Re:ikiwiki

perl6doc on 2010-05-09T15:38:28

thanks i didn't know that one yet.

Why not overhaul Socialtext?

daxim on 2010-05-10T12:20:32

Spending time to modernise ST pays off immediately and will also be overall more beneficial in the long term compared with designing and coding a software from scratch.

Re:Why not overhaul Socialtext?

perl6doc on 2010-05-10T21:06:23

not necessarily. there is a open source version, but its also lot of effort to understand a large system. and if you work your on your own when we want to tweak the wiki syntax and the overall rendering. maybe its worth a try. i look at http://github.com/socialtext. but there is also the problem i cant find any admin.

Re:Why not overhaul Socialtext?

daxim on 2010-05-11T07:41:23

One does not need to understand every detail of the whole system in order to change smaller parts.

The homepage of the open source version is http://www.socialtext.net/open/.

What do you need an admin for?

Re:Why not overhaul Socialtext?

perl6doc on 2010-05-11T15:17:47

currently i cant reach an admin of perlfoundation.org :(

it would have the advantage to use all the existing highter modules. there is even one for perl 6 that padre uses. but on other hand the changes i need would change the wiki markup syntax. i dont believe socialtext would allow that. so we maybe need a parser for wikimedia markup and extend it. i think it would touch a lot of subsystems such as the diff module, revamp search engine, add links to the history. i dont think you need that much code to implement it. but you have to understand much of the inner workings.

Socialtext 4.0 Hosted?

audreyt on 2010-05-15T01:10:26

Hi! I agree Socialtext 2.0 really is subpar. :-)

However, I'm coincidentally working for Socialtext, and am one of the main hackers of its Wiki Syntax!

I wonder if we can set up a Free-50 hosted account for the @cpan.org domain, and import the existing Perl 6 Wiki content: See http://www.socialtext.com/products/free50.php for details.

The gist is that all writers (not readers) need to be a CPAN author, which may have the nice dual side-effect of encouraging CPAN authorship and reducing spam.

The Socialtext 4.0 version has considerably more markup, including proper table and spreadsheet support, as well as JavaScript-based per-page plugins, so if there's a JS-based highlighter we can easily use it.

If you'd be agreeable to such an arrangement, I can help importing the existing Wiki content to a hosted space just to see how it would look like, and work on lifting the 50-editor restriction if you think it makes sense.

Thoughts? :-)