Re: $1,000 prize for Perl 6 Wiki written in Perl 6
Juerd schrieb: * Markdown does not have tables. * Textile does not have paragraphs in table cells. * Kwiki does not have paragraphs in table cells. Unless someone comes up with another way to do side-by-side layouts (extremely useful for showcasing differences between Perl 5 and Perl 6), all of these formats are not suitable. I suppose doing it the Perl-way: Stealing the best of each syntax, adding what's missing. I don't think that we have to choose an existing syntax, but can create one that combines the best features of the existing ones. Of course, this would be more work. Probably it will not be easy to get a common agreement of what's best. Additionally the mixed up syntax shouldn't look too inconsistent - but that won't be too hard I think. Also some restrictions have to be considered. E.g. if we want to allow block oriented parsing (nested blocks in other blocks), the syntax must be unambiguous on how to detect blocks (within other blocks). That's mainly what I did as stated in my first post[1]. Look at several wiki-syntaxes and combine, what _I_ think is the syntax suited best for a wiki. And I think that such a (then collaborative) process might be a good idea for the definition of the syntax of this wiki. -Thomas
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
Damn, forgot the link. Thomas Wittek schrieb: That's mainly what I did as stated in my first post[1]. [...] [1]: news://nntp.perl.org:119/[EMAIL PROTECTED]
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
Thomas Wittek wrote: Good ideas. But maybe we should start a bit smaller ;) It might be a good idea to create a list of features separated in several increments (releases) to get a running system early. Absolutely. I could imagine increments like Parsing/Converting, Storage backend/Revision control, User management, ... Unfortunately you probably have to throw away/heavily modify earlier increments, if you add features like a flexible syntax, which will need a different internal infrastructure. Well, if object-oriented design has any advantage at all, here it is! If we design this sort of wiki from the very beginning in a way that you can just load a sort of storage backend, user management, rule engine (per heritage or plugin-wise) you can start off creating the simplest storage, a nearly nonexistent usermanagement and a very simple rule engine and just swap when you've got a better one in stock ;) Only you will have to define the abstract class or plugin bay from the first minute in the right way (the only was softly ironic). But targeting such a feature monster will probably take too much development time. I agree heavily. I only propose a flexible object-oriented or otherwise modular design that enables programmers to weld stuff onto it and plug other stuff into it and after transformation use it from outside as a module to do something with it that noone has foreseen... Ok, forget about the last bit, I'll be content with welding and plugging ;) Maybe a feature complete version could be targeted as the Perl6-Wiki-Software. But before this one a Lite Version, which will be used to have a wiki quickly available, could be developed. -Thomas Maybe, just to get started, we should use as many perl5-modules as we can and then substitute them one by one (thinking of CGI, YAML, DBI, HTML::Template, etc., etc.) Regards, Udo -- That which is not good for the bee-hive cannot be good for the bees.
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
* Thomas Wittek [EMAIL PROTECTED] [2006-06-03 22:30]: Interestingly it is very similar to Markdown although I never heard about it before :) Hmm, it doesn’t look similar at all to me? Not even superficially similar, but most importantly, it looks line-based. Markdown is block-based. If you want another example of block-based, take a look at the new-style PhpWiki markup. These let you do things like put a code block inside a blockquote within a list item, or heck, even things as simple as multi-paragraph list items. Mediawiki markup, like many other wiki syntaxes, can’t express that. Yours doesn’t look like it can either. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
On Jun 1, 2006, at 6:45, Ovid wrote: In any event, if you can come up with a solid set of contest rules, TPF can consider whether or not we can officially run the contest. It sounds like a nice idea, I just don't know what's involved. I wouldn't claim to entirely comprehend the rules, but I think there's something in the 501c rules about not taking money for specific purposes too. - ask -- http://www.askbjoernhansen.com/
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
Hi, Hi Conrad, I run the grant committee for the Perl Foundation and I sit on the steering committee, so I suppose I can discuss your proposal (there are some other TPF folk here, too, so that's why this is a public email). Also, the following stuff is just off the top of my head and is in no way official. For TPF to handle something like this, we'd have to have some agreement on what the specs are, who would judge whether or not a Wiki met the specs and what to do if there were timing concerns (if we get one Wiki before another even the the later one was sent first, who wins?) Oh my, this is getting complicated :) Also, though I hate to be a spoilsport and bring this up, I'm really not sure what legal issues might be involved with running a contest, either. Would that be considered a form of gambling and possibly be illegal? I don't think so, but I'm not sure. Well, it cannot be gambling. IMHO something constitutes to gambling only if: - the outcome (who wins/loses) is mostly controlled by chance - you have to pay in order to participate Both should hold and none holds. However, there might be taxing issues... In any event, if you can come up with a solid set of contest rules, TPF can consider whether or not we can officially run the contest. It sounds like a nice idea, I just don't know what's involved. i_am_so_bad If I had some mone to spare for a contest like this, I would say: I have the money so I make the rules :) Some might not like that, but it makes things much less complicated. It's Conrad's money and his generous gesture. I would say let him decide who makes the specification and let him name the winner, according to the rules he comes up with. Those who will be unhappy with the result can always STFU, don't they? ;) /i_am_so_bad Of course if the community can make this happen is a nice and controlled way, that would be the best. I just like pragmatism :)) - Fagzal
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
Darren Duncan skribis 2006-05-28 14:37 (-0700): For one thing, I'm assuming that a prize-qualifying solution won't be able to link-in legacy Perl 5 modules using Pugs' use perl5:Foo syntax; to do so would look bad if we are wanting to show off a Wiki solution using the NEW technology. I'm assuming re-using code is okay, as long as it's pre-existing. It would be a good idea to create Perl 6 wrappers around them, so that once a Perl 6 implementation is good enough for doing it in Perl 6, code can be migrated easily. Therefore, if this Wiki is going to be made sooner rather than later, what are we going to use for a storage engine? Well, since storage needs support for revisions, I'm all for re-using open source industry standards like svk or svn. Initially, the command line tools can be wrapped around. Later, native support can be built. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
I'm wondering about some implementation logistics. For one thing, I'm assuming that a prize-qualifying solution won't be able to link-in legacy Perl 5 modules using Pugs' use perl5:Foo syntax; to do so would look bad if we are wanting to show off a Wiki solution using the NEW technology. Therefore, if this Wiki is going to be made sooner rather than later, what are we going to use for a storage engine? No Perl 6 RDBMS interface or implementation is ready yet, nor will it likely be for some time. Such is what larger scale Wikis use. So is this initial Wiki going to use a folder hierarchy of flat files, or a big YAML file, or something? This is fine for an initial version, of course, that is just showing things off, though it may be more difficult to scale. Perhaps v1 of the Wiki will use YAML or flat files, and v2 an RDBMS. Or is something more interesting on the horizon, like perhaps an RDF storage? -- Darren Duncan
RE: $1,000 prize for Perl 6 Wiki written in Perl 6
-Original Message-
From: Amir E. Aharoni [mailto:[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 1:54 PM
[...]
It's funny - i was the first one who proposed the wiki idea and i
didn't think that it will go so far (1000$$$). If you ask me, this
wiki should be done ASAP in Media-Wiki. Reusing current Perl wikis
(Australian, whatever) is even better.
I certainly agree. However, someone has to take the initiative to actually
start using (http://perl.net.au/wiki/Perl_6), and to post links back here
for others to follow up on. Will that person be you? :-) I'm all for using
that wiki to compile important Perl 6 content now, so that there will be
plenty of good material on hand for the (Perl 6)**2 Wiki.
I'm long on enthusiasm, but very low on tuits at the moment (hence the
prize), but if someone ports the contents of
(www.athenalab.com/Perl_6_Users_FAQ.htm) to the above wiki, I'll replace the
above page with a Perl 6 Users FAQ has become absorbed by a much better
Perl 6 wiki link.
Perl6 currently needs
documentation, community and advocacy - not a Yet Another Content
Management System written in itself.
I don't see these as mutually exclusive. Especially since other people
clearly regard such a prospective Perl 6 system as a powerful form of
advocacy, as an important piece of documentation for the Perl 6 Cookbook,
and as a community-building venture.
Also, it's really up to others who do the actual work to decide what they
find interesting or important enough to work on, given their interests and
motivation. It's not for me to dictate to others what they should or
shouldn't be doing. Perl 6 development has really taken off over the last
year or so in part because people were encouraged to pursue -Ofun, rather
than being told what they should be doing. Of all the crazy things, whoever
thought that what Perl 6 really needed was a pathetically primitive
prototype in some arcane language like Haskell? :-)
It is unlikely that it will
become Perl6's killer app with such a strong competition.
Near-to-medium term, you're almost certainly correct. The long term is a
different matter. But I think this is a tangential issue.
There are more important {near-to-medium term and non-competitive} roles
(pun intended) that the (Perl 6)**2 Wiki could play. (1) It can serve as a
wide-participation eat your own dog food prototype. (2) As new Perl 6
features become available, refactoring the prototype into a more pluggable
architecture (among other things) could provide many opportunities for
trying out new Perl 6 capabilities (including the use of production Perl 5
modules). (3) As the primary Perl 6 wiki, we have the option of adding
features that might be particularly useful for (say) generating Perl {user,
release, module, distribution, and so on} documentation without going
through the usual {POD editing, svn updating, HTML generating} processes,
resulting in {wider participation and greater productivity}, relative to
existing systems. (4) Eventually, this can serve as the nucleus of a
generalized Wiki-counterpart and analog of {CPAN, Perl Monks sorts of
forums, developer blogs, and so on}. Parts of it might eventually
incrementally morph into the first viable semantic web.
And again, the most important factor for many people is -Ofun. I've even
resigned myself to it. :-)
Best regards,
Conrad Schneiker
www.athenalab.com/Perl_6_Users_FAQ.htm
www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam technology.)
