$1,000 prize for Perl 6 Wiki written in Perl 6

------=_NextPart_000_0024_01C6819A.B55AC7D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

OK, I'm sold on a Perl 6 Wiki written in Perl 6-aka the (Perl 6)**2 Wiki.

 

However, I want it now!

 

So I'm offering to post a $1,000 prize (The AthenaLab "The 1st Extreme
Leverage Prize" for Perl 6), to be awarded to the person that delivers the
first (Perl 6)**2 Wiki that meets some moderate specifications. 

 

Here's what I currently have in mind.

 

The prize money would be held in escrow by The Perl Foundation (*IF* they
are willing to handle this). The Perl Foundation would decide when a prize
claimant had adequately realized the specifications. (Entries must be
announced on perl.perl6.users. To facilitate collaboration, the designated
winner may request that the prize be split up and distributed among up-to-10
cohorts or charities, with names and amounts to be publicly specified in
advance on perl.perl6.users.)

 

The specifications for the (Perl 6)**2 Wiki would be determined (and posted
to perl.perl6.users) by @Larry (*IF* they are willing to handle this). One
of the reasons for wanting @Larry to handle the specification for this prize
is my presumption that they best know what is presently (or soon will be)
"reasonable" to implement. Perl 6 means Pugs + Parrot for purposes of this
prize. (However, if @Larry recommends s/Parrot/Perl5/ for now, that's also
OK with me.) "Practically usable minimalism" and the
(http://www.perldesignpatterns.com/?TinyWiki) approach of starting with "the
simplest (working) thing possible" is fine. The aim is not to impress with
world with the first implementation, but rather to initiate a
self-sustaining chain reaction of improvement that will much later (a year
from now) impress the world with the cumulative rate of progress.

 

The license must be whatever the prevailing license was for the Pugs (Perl 6
core) svn source tree is at the time the prize is claimed. The source code
would be added to the examples or cookbook section of the Pugs source tree.
(Details to be determined by @Larry.)

 

The contestant (or contestants) are encouraged to seek help and feedback on
public forums. Just be up-front about it. Taking the initiative needed to
deliver the result is what is being rewarded, not doing it on your own. 

 

The (Perl 6)**2 Wiki must be installed and demonstrated on Feather, Juerd's
Perl 6 development server (*IF* this is OK with him, and if he can arrange
for www.perl6.nl <http://www.perl6.nl/>  to go to the new Wiki, *UNLESS* the
Perl Foundation wants to host the main Wiki, in which case Feather would
still be used for further Wiki prototyping and development.).

 

We'll need a volunteer to serve as the (Perl 6)**2 Wiki sysadmin, once it
comes online. If no one else steps forward, I'd volunteer to serve as the
(Perl 6)**2 Wiki moderator for any (hopefully very rare) cases of content
issues. (I'd prefer that the Perl Foundation or Perl Mongers took
responsibility for these things, but I don't want to ask for too much at the
outset. To minimize disputes and churning, I suspect the
eventually-high-demand home page should be restricted to moderator-only
updating.)

 

Best regards,
Conrad Schneiker

 

www.athenalab.com/ <http://www.athenalab.com/Perl_6_Users_FAQ.htm>
Perl_6_Users_FAQ.htm


www. <http://www.AthenaLab.com> AthenaLab.com (Nano-electron-beam
technology.)

 


------=_NextPart_000_0024_01C6819A.B55AC7D0--

0
conrad
5/27/2006 9:34:47 PM
perl.perl6.users 1545 articles. 0 followers. Follow

69 Replies
874 Views

Similar Articles

[PageSpeed] 24

On 27/05/06, Conrad Schneiker <conrad.schneiker@gmail.com> wrote:
> So I'm offering to post a $1,000 prize (The AthenaLab "The 1st Extreme
> Leverage Prize" for Perl 6), to be awarded to the person that delivers th=
e
> first (Perl 6)**2 Wiki that meets some moderate specifications.

Now would that be New Zealand Dollars or...?  :-)

I think this will certainly encourage activity but I hope it doesn't
make things so competitive that us average folks won't have a chance
to contribute to the work. I would love to help in whatever small ways
I can. Hopefully everyone who wants to will be able to give something
to the project. Is it too late to add a requirement that the
"solution" be architected to allow for modular expansion? I mean that
it can easily be added to with plug-ins (for example). That way even
those who don't work on the core can still add expansion code.

Also I'm volunteering now for whatever anyone needs -- I'll waive the
money if that's gonna stop you from accepting my help. :)

--michael
0
micmath
5/28/2006 7:25:08 AM
> From: Michael Mathews [mailto:micmath@gmail.com]
> Sent: Sunday, May 28, 2006 12:25 AM
[...]
> On 27/05/06, Conrad Schneiker <conrad.schneiker@gmail.com> wrote:
> > So I'm offering to post a $1,000 prize (The AthenaLab "The 1st Extreme
> > Leverage Prize" for Perl 6), to be awarded to the person that delivers
> > the
> > first (Perl 6)**2 Wiki that meets some moderate specifications.
[...]
> Now would that be New Zealand Dollars or...?  :-)

USDs. 

(Hmm. Maybe I should have checked exchange rates before answering.)

> I think this will certainly encourage activity but I hope it doesn't
> make things so competitive that us average folks won't have a chance
> to contribute to the work. 

If things do turn out to be *that* competitive, then it's likely that Perl 6
is seriously threatened by an imminent stampede of early-adapters, and is
probably inescapably doomed to an awesome future. 

> I would love to help in whatever small ways
> I can. Hopefully everyone who wants to will be able to give something
> to the project. 

I sort of hope so too, which is partly why I encouraged the use of public
forums to get assistance. However, for some people, competition is -Ofun. If
they prevail in this endeavor, that's also OK with me. 

I'm *very* much *more* interested in the *next* wave of collaborative
projects that the (Perl 6)**2 Wiki can more {readily, powerfully}
facilitate. I allude to some of these possibilities in
(www.athenalab.com/Perl_6_Users_FAQ.htm).) In case you weren't wondering
about it, "Extreme Leverage" in the name of the prize reflects this
perspective.

> Is it too late to add a requirement that the
> "solution" be architected to allow for modular expansion? I mean that
> it can easily be added to with plug-ins (for example). That way even
> those who don't work on the core can still add expansion code.

Good ideas, but I'll leave the specifications up to @Larry (or designated
proxies thereof). 

Once something useful is running, there should be endless opportunities for
{refactoring, upgrading, generalizing, customizing}. As long as there are no
external Wiki features that somehow preclude a reasonable content-migration
path, then AFAIK, the internals of the first system could be pretty kludgy
without precluding fairly rapid evolution towards increasingly {elegant,
powerful} architectural "best practices".

> Also I'm volunteering now for whatever anyone needs -- I'll waive the
> money if that's gonna stop you from accepting my help. :)

I like that attitude. Coincidentally, I'm waving the money too--as in waving
it goodbye. But if the Perl 6 Users FAQ is even half-right about the future
prospects of Perl 6, then this investment should have a wonderful long-term
ROI. Hopefully some other people will think and do likewise. 

Best regards,
Conrad Schneiker
 
www.athenalab.com/Perl_6_Users_FAQ.htm

www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam technology.)

0
conrad
5/28/2006 9:53:04 AM
Conrad Schneiker skribis 2006-05-27 14:34 (-0700):
> So I'm offering to post a $1,000 prize (The AthenaLab "The 1st Extreme
> Leverage Prize" for Perl 6), to be awarded to the person that delivers the
> first (Perl 6)**2 Wiki that meets some moderate specifications. 

Wow! Thanks for doing the world this favour.

> The specifications for the (Perl 6)**2 Wiki would be determined (and posted
> to perl.perl6.users) by @Larry (*IF* they are willing to handle this).

I !~ @Larry, but I have some specs in mind that can perhaps inspire
@Larry:

- MediaWiki-compatible syntax
  - Most \W characters can be safely used
  - Package names (CamelCase) can be used without them being transformed
    into links
- Revision support with web based diffs and rollback
  - Implement an svk frontend?
- Page hit for a moderately sized page should take no longer than 5
seconds
  - Modularity is nice, but usability is more important
  - Current Perl 6 implementations are still rather slow
  - Use mod_pugs?
- Must be packaged for CPAN

And some non-spec thoughts:

- Think about forward compatibility
  - Especially when it comes to syntax
- Implement a tagging system (better than Categories)
- Get someone with good design fu to design the graphical stuff
  - And use templates
  - Maybe just use the wikipedia layout
  - Many Perl people are bad at graphical design, without realising it.
    This wiki will be the first Perl 6 impression for many.
- Make pages cacheable
  - Prepare for slashdot (not really... :))
  - Perl 6 implementations are still slow
- Support ";" as well as "&" in URIs

> The (Perl 6)**2 Wiki must be installed and demonstrated on Feather, Juerd's
> Perl 6 development server (*IF* this is OK with him, and if he can arrange
> for www.perl6.nl <http://www.perl6.nl/>  to go to the new Wiki, ...)

Feather is of course available for this challenge. Contestants who don't
currently have an account, can request one by sending me an email (not
via the mailing list, please).

Once the wiki is finished (when the $1000 have been awarded), perl6.nl,
www.perl6.nl, is available to host the wiki.


Cheers,

Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html
0
juerd
5/28/2006 10:55:02 AM
Amir E. Aharoni skribis 2006-05-28 22:54 (+0200):
> 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. Perl6 currently needs
> documentation, community and advocacy - not a Yet Another Content
> Management System written in itself. It is unlikely that it will
> become Perl6's killer app with such a strong competition.

I disagree, for reasons detailed in perl6-language.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html
0
juerd
5/28/2006 7:26:13 PM
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
0
juerd
5/28/2006 7:31:28 PM
* Juerd <juerd@convolution.nl> [2006-05-28 19:35]:
> - MediaWiki-compatible syntax

I hate the Mediawiki syntax. Can we have something that
understands blocks, like Markdown? Just add [[foo]] as intrawiki
link syntax.

>   - Most \W characters can be safely used

Yeah, that is true for Markdown.

>   - Package names (CamelCase) can be used without them being
>     transformed into links

I find CamelCaseLinking annoying as well. However, I do like how
it seems to gently guide people into picking NounsAsPageNames,
whereas random contributors tend [[to make really stupid]]
choices when given free-form links only. Good tools (page
renaming etc.) can help steer against that, but CamelCaseLinking
makes it less necessary to take corrective action in the first
place. However, it’s also just plain damn ugly. :-/

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>
0
pagaltzis
5/28/2006 8:37:56 PM
QmVlcCBiZWVwLiBJLCBmb3IgZXhhbXBsZSwgaGF0ZSB0aGUgdmVyYm9zaXR5IG9mIGh0bWwsIGJ1
dCBpIHVzZSBpdApuZXZlcnRoZWxlc3MuIFRoZSBwb3B1bGFyaXR5IG9mIFdpa2lwZWRpYSBtYWRl
IE1lZGlhLVdpa2kgc3ludGF4IHRoZQpkZS1mYWN0byBzdGFuZGFyZC4gSXQncyBub3QgcGVyZmVj
dCwgYnV0IHBsZWFzZSBkb24ndCByZWludmVudCB0aGUKd2hlZWwgKGV2ZW4gdGhvdWdoIGl0J3Mg
YSBQSFAgd2hlZWwpLgoKSXQncyBmdW5ueSAtIGkgd2FzIHRoZSBmaXJzdCBvbmUgd2hvIHByb3Bv
c2VkIHRoZSB3aWtpIGlkZWEgYW5kIGkKZGlkbid0IHRoaW5rIHRoYXQgaXQgd2lsbCBnbyBzbyBm
YXIgKDEwMDAkJCQ/Pz8/KS4gSWYgeW91IGFzayBtZSwgdGhpcwp3aWtpIHNob3VsZCBiZSBkb25l
IEFTQVAgaW4gTWVkaWEtV2lraS4gUmV1c2luZyBjdXJyZW50IFBlcmwgd2lraXMKKEF1c3RyYWxp
YW4sIHdoYXRldmVyKSBpcyBldmVuIGJldHRlci4gUGVybDYgY3VycmVudGx5IG5lZWRzCmRvY3Vt
ZW50YXRpb24sIGNvbW11bml0eSBhbmQgYWR2b2NhY3kgLSBub3QgYSBZZXQgQW5vdGhlciBDb250
ZW50Ck1hbmFnZW1lbnQgU3lzdGVtIHdyaXR0ZW4gaW4gaXRzZWxmLiBJdCBpcyB1bmxpa2VseSB0
aGF0IGl0IHdpbGwKYmVjb21lIFBlcmw2J3Mga2lsbGVyIGFwcCB3aXRoIHN1Y2ggYSBzdHJvbmcg
Y29tcGV0aXRpb24uCgpBcyBmb3IgQ2FtZWxDYXNlIC0gaXQncyBsb25nIGRlYWQuIE5vdywgd3Jp
dGluZyBhIFBlcmw2IGFwcCB0byBmaW5kCmFuZCBleHRlcm1pbmF0ZSBbW3JhbmRvbSBsaW5rc11d
IHdvdWxkIGJlIG5lYXQgKGFsdGhvdWdoIGl0IHdvdWxkCnByb2JhYmx5IGJlIGEgb25lLWxpbmVy
KS4KCk9uIDUvMjgvMDYsIEEuIFBhZ2FsdHppcyA8cGFnYWx0emlzQGdteC5kZT4gd3JvdGU6Cj4g
KiBKdWVyZCA8anVlcmRAY29udm9sdXRpb24ubmw+IFsyMDA2LTA1LTI4IDE5OjM1XToKPiA+IC0g
TWVkaWFXaWtpLWNvbXBhdGlibGUgc3ludGF4Cj4KPiBJIGhhdGUgdGhlIE1lZGlhd2lraSBzeW50
YXguIENhbiB3ZSBoYXZlIHNvbWV0aGluZyB0aGF0Cj4gdW5kZXJzdGFuZHMgYmxvY2tzLCBsaWtl
IE1hcmtkb3duPyBKdXN0IGFkZCBbW2Zvb11dIGFzIGludHJhd2lraQo+IGxpbmsgc3ludGF4Lgo+
Cj4gPiAgIC0gTW9zdCBcVyBjaGFyYWN0ZXJzIGNhbiBiZSBzYWZlbHkgdXNlZAo+Cj4gWWVhaCwg
dGhhdCBpcyB0cnVlIGZvciBNYXJrZG93bi4KPgo+ID4gICAtIFBhY2thZ2UgbmFtZXMgKENhbWVs
Q2FzZSkgY2FuIGJlIHVzZWQgd2l0aG91dCB0aGVtIGJlaW5nCj4gPiAgICAgdHJhbnNmb3JtZWQg
aW50byBsaW5rcwo+Cj4gSSBmaW5kIENhbWVsQ2FzZUxpbmtpbmcgYW5ub3lpbmcgYXMgd2VsbC4g
SG93ZXZlciwgSSBkbyBsaWtlIGhvdwo+IGl0IHNlZW1zIHRvIGdlbnRseSBndWlkZSBwZW9wbGUg
aW50byBwaWNraW5nIE5vdW5zQXNQYWdlTmFtZXMsCj4gd2hlcmVhcyByYW5kb20gY29udHJpYnV0
b3JzIHRlbmQgW1t0byBtYWtlIHJlYWxseSBzdHVwaWRdXQo+IGNob2ljZXMgd2hlbiBnaXZlbiBm
cmVlLWZvcm0gbGlua3Mgb25seS4gR29vZCB0b29scyAocGFnZQo+IHJlbmFtaW5nIGV0Yy4pIGNh
biBoZWxwIHN0ZWVyIGFnYWluc3QgdGhhdCwgYnV0IENhbWVsQ2FzZUxpbmtpbmcKPiBtYWtlcyBp
dCBsZXNzIG5lY2Vzc2FyeSB0byB0YWtlIGNvcnJlY3RpdmUgYWN0aW9uIGluIHRoZSBmaXJzdAo+
IHBsYWNlLiBIb3dldmVyLCBpdCdzIGFsc28ganVzdCBwbGFpbiBkYW1uIHVnbHkuIDotLwo+Cj4g
UmVnYXJkcywKPiAtLQo+IEFyaXN0b3RsZSBQYWdhbHR6aXMgLy8gPGh0dHA6Ly9wbGFzbWFzdHVy
bS5vcmcvPgo+CgoKLS0gCkFtaXIgRWxpc2hhIEFoYXJvbmksIGh0dHA6Ly9haGFyb25pLmJsb2dz
cG90LmNvbS8KIldlJ3JlIGxpdmluZyBpbiBwaWVjZXMsCkkgd2FudCB0byBsaXZlIGluIHBlYWNl
LiIgLSBUaHVyc3RvbiBNb29yZQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KUGxlYXNlIGF2b2lkIHNlbmRpbmcgbWUgV29yZCBvciBQb3dlclBv
aW50IGF0dGFjaG1lbnRzCmh0dHA6Ly93d3cuZ251Lm9yZy9waGlsb3NvcGh5L25vLXdvcmQtYXR0
YWNobWVudHMuaHRtbAo=
0
amir
5/28/2006 8:54:19 PM
* Amir E. Aharoni <amir.aharoni@gmail.com> [2006-05-28 23:00]:
> The popularity of Wikipedia made Media-Wiki syntax the de-facto
> standard. It's not perfect, but please don't reinvent the wheel
> (even though it's a PHP wheel).

I plead not guilty.

Markdown is nothing new, and it has half a dozen implementations
in multiple languages already (the canonical one is written in
Perl 5, btw). It is very popular in the weblog world, but because
the implementations are not tied to a particular webapp, it gets
used in many other contexts as well. I write all of my plaintext
files in Markdown; which isn’t saying much, because the syntax
very much looks just like email.

Noone other than Mediawiki uses the Mediawiki syntax. I posit
that the reason is that that syntax blows chunks.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>
0
pagaltzis
5/28/2006 9:15:48 PM
> 
> Noone other than Mediawiki uses the Mediawiki syntax. I posit
> that the reason is that that syntax blows chunks.

Actually dokuwiki uses an almost the exact same syntax as mediawiki..
except they invert the headers (== foo == stuff).

as for a perl6 wiki.. I agree that there are already many many wiki's
outthere the ones I like most noted above (media and doku), since I
really like the syntax. but also both of them are written in php and as
far as I've seen the code.. not particulary beautiful (ok dokuwiki is
plain ugly but functional, mediawiki somewhat hard with major upgrades)
and I dislike all perl wiki's I've seen. so IMHO there still is a
market.
on top of that.. some good clear visible code like with a wiki, would do
the perl6 project good for news and momentum (and a php wiki would just
look really bad i think).

as for specs.. ofcourse I'm no [at]larry, but I'd like to see something
that is lightweight and flexible in design.

my 2ct,

Sebastian S

> 
> Regards,
> -- 
> Aristotle Pagaltzis // <http://plasmasturm.org/>

-- 
[URL: http://web.expr42.net/]
[Unique ID: Sun May 28 23:23:17 CEST 2006 (36)]
0
perl6
5/28/2006 9:31:17 PM
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
0
darren
5/28/2006 9:37:58 PM
* Darren Duncan <darren@DarrenDuncan.net> [2006-05-28 23:40]:
> 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’d think it a fine technology demonstration to show how you can
actually, *in practice*, write an application in a dynamic
language that relies on libraries in another dynamic language,
particularly when it lets you use a library for something for
which none are (yet) available in your native language.

“We had a working webapp in Perl 6 before anyone even ported a
CGI parameter parser to it!” How’s *that* for R.A.D.

> No Perl 6 RDBMS interface or implementation is ready yet, nor
> will it likely be for some time.

Use Parrot NCI to wrap SQLite? More cross-language library reuse…
:-)  I don’t know enough about the state of Pugs and Parrot to
know if this is feasible yet, though.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>
0
pagaltzis
5/28/2006 10:08:48 PM
> From: Juerd [mailto:juerd@convolution.nl]
> Sent: Sunday, May 28, 2006 3:55 AM
[...]
> Conrad Schneiker skribis 2006-05-27 14:34 (-0700):
> > So I'm offering to post a $1,000 prize (The AthenaLab "The 1st Extreme
> > Leverage Prize" for Perl 6), to be awarded to the person that delivers
> > the
> > first (Perl 6)**2 Wiki that meets some moderate specifications.
> 
> Wow! Thanks for doing the world this favour.

And thank you for bringing the idea to my attention--repeatedly. It took a
while for me to have a "revelation of the obvious", and see the many
potentially useful side-effects of such a pilot project.

Best regards,
Conrad Schneiker
 
www.athenalab.com/Perl_6_Users_FAQ.htm

www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam technology.)

0
conrad
5/28/2006 10:24:07 PM
> -----Original Message-----
> From: Amir E. Aharoni [mailto:amir.aharoni@gmail.com]
> 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.)


0
conrad
5/28/2006 11:58:01 PM
> From: Darren Duncan [mailto:darren@DarrenDuncan.net]
> Sent: Sunday, May 28, 2006 2:38 PM
[...]
> 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.

That will be up to @Larry to decide. "Non-trivial" Perl 6 content seems
obviously desirable, but it's not obvious to me what the reasonable criteria
for that might be. (That's another reason for deferring specifications to
wiser and better-informed people.)

Using legacy Perl 5 modules is an important Perl 6 capability for a great
many people, and it may actually be a very good thing to show off. 

Best regards,
Conrad Schneiker

www.athenalab.com/Perl_6_Users_FAQ.htm

www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam technology.)

0
conrad
5/29/2006 12:35:25 AM
G'day Conrad, Amir, and P6U,

Conrad Schneiker wrote:

> 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. 

Working on that now.  ;)

> 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. 

Done!  See http://perl.net.au/wiki/Perl_6_Users_FAQ .  It's still a little rough
at the moment, I'm working on fixing the remaining bits of poor mark-up, and
improving inter and intra-document linkage.  However don't let that stop you (or
any P6U members) from adjusting the FAQ as required.

Am I correct that the P6U FAQ can also be multi-licensed under the
CC-Attribution-ShareAlike license, as well as the prevailing P6/Pugs license?

Cheerio,

	Paul

-- 
Paul Fenwick <pjf@perltraining.com.au> | http://perltraining.com.au/
Director of Training                   | Ph:  +61 3 9354 6001
Perl Training Australia                | Fax: +61 3 9354 2681
0
pjf
5/29/2006 2:27:48 AM
> From: Paul Fenwick [mailto:pjf@perltraining.com.au]
> Sent: Sunday, May 28, 2006 7:28 PM
[...]

Sorry for the delay in responding. Spent much of the day fighting
windoze insanity. If not for a certain other $commitment, I probably
be shopping for a Mac about now. :-)

> Conrad Schneiker wrote:
> 
> > 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.
> 
> Working on that now.  ;)

Wonderful!

> > 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.

Page changed.

> Done!  See http://perl.net.au/wiki/Perl_6_Users_FAQ .  It's still a
> little rough
> at the moment, I'm working on fixing the remaining bits of poor
> mark-up, and
> improving inter and intra-document linkage.  However don't let that
> stop you (or
> any P6U members) from adjusting the FAQ as required.

Fantastic. That's much more readable than the original. 

Thanks much!

> Am I correct that the P6U FAQ can also be multi-licensed under the
> CC-Attribution-ShareAlike license, as well as the prevailing P6/Pugs
> license?

AFAIK. That's certainly fine with me in any case.

Best regards,

Conrad Schneiker

www.athenalab.com/Perl_6_Users_FAQ.htm

www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam
technology.)

0
conrad
5/30/2006 5:08:09 AM
A. Pagaltzis schrieb:
> * Amir E. Aharoni <amir.aharoni@gmail.com> [2006-05-28 23:00]:
>> The popularity of Wikipedia made Media-Wiki syntax the de-facto
>> standard. It's not perfect, but please don't reinvent the wheel
>> (even though it's a PHP wheel).
> [..]
> Noone other than Mediawiki uses the Mediawiki syntax. I posit
> that the reason is that that syntax blows chunks.

I have to agree. '''''bold and italic''''' is definitely not what I
understand as an intuitive syntax.

I did some work on designing an easy wiki syntax for a wiki plugin for
my (yet another...)[1] webdev framework. I looked at the syntax of
several wikis and tried to create an easy to write (and to parse)
syntax: http://gedankenkonstrukt.de/konstrukt/syntax.html

This actually has been implemented and works fine. It's not released yet
and also not intended to be a base for a perl6-wiki. I'm just posting it
to suggest a possible syntax. Interestingly it is very similar to
Markdown although I never heard about it before :)

Regards,
-Thomas

[1]: I believe everyone has to build one on its own ;)
0
mail
6/3/2006 8:24:07 PM
* Thomas Wittek <mail@gedankenkonstrukt.de> [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/>
0
pagaltzis
6/3/2006 9:38:22 PM
A. Pagaltzis schrieb:
> * Thomas Wittek <mail@gedankenkonstrukt.de> [2006-06-03 22:30]:
>> Interestingly it is very similar to Markdown although I never
>> heard about it before :)
>=20
> Hmm, it doesn=E2=80=99t look similar at all to me?

Headers (Markdown):
# This is an H1
## This is an H2
###### This is an H6

Headers (/me):
=3D This is an H1
=3D=3D This is an H2
=3D=3D=3D=3D=3D=3D This is an H6

Lists (Markdown):
*   Red
*   Green
*   Blue

Liste (/me):
*   Red
*   Green
*   Blue

Code (Markdown):
This is a normal paragraph:

    This is a code block.

Code (/me):
This is a normal paragraph:

    This is a code block.

Horizontal Rules (Markdown):
-----

Horizontal Rules (/me):
-----

Emphasis (Markdown):
e.g. *single asterisks*

Emphasis (/me):
*single asterisks*

There are of course many cases where the syntax differs, but only I said
that they are similar, not identical ;) Especially the linking differs
from my syntax.

> 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=E2=80=99t express
> that. Yours doesn=E2=80=99t look like it can either.

No, (currently) blocks cannot be nested.
Blocks are separated by >=3D1 newlines and consist of only one type of th=
e
ones listed in
http://gedankenkonstrukt.de/konstrukt/syntax.html#BLOCK_SYNTAX. I only
wanted to cover the most common formatting cases. It's far from being
feature-complete and not intended to be a full-sized wiki-system.

Bye,
-Thomas
0
mail
6/3/2006 11:36:37 PM
Woah, we are getting really far away from talking about perl6 here...


  - ask



0
ask
6/4/2006 6:08:50 AM
Thomas Wittek wrote:

>> Noone other than Mediawiki uses the Mediawiki syntax. I posit
>> that the reason is that that syntax blows chunks.
> 
> I have to agree. '''''bold and italic''''' is definitely not what I
> understand as an intuitive syntax.
 
Hi everyone, 

I'd like to mention that the mediawiki syntax is mainly borrowed from
UseModWiki, which is written in Perl and quite easy to use. I do drive my
own homepage with it (http://www.udo-guengerich.de - and sorry for all the
nasty German on it ;)) and are quite content with it, apart from some small
minor annoyances. The version I use is a patched one with some patches from
myself, it does:

* not care whether people prefer CamelCase or [[Free Links]], because you
can configure it
* execute <perl></perl> tags
(http://www.udo-guengerich.de/cgi-bin/wiki.pl?Die_Password)
* Include files (containing UseModWiki syntax:
http://www.usemod.com/cgi-bin/wiki.pl?TextFormattingRules) for enhancing
modularity
* InterWiki-Links
* diff stuff and revision control plus rollback

It is far from being perfect, but it implements some interesting ideas.
Still I found it - using it not as wiki but as mini-CMS for my homepage -
being constricting at some points.

> I did some work on designing an easy wiki syntax for a wiki plugin for
> my (yet another...)[1] webdev framework. I looked at the syntax of
> several wikis and tried to create an easy to write (and to parse)
> syntax: http://gedankenkonstrukt.de/konstrukt/syntax.html

So there came another idea to my mind which I thought you might want to
consider for a possible perl6-wiki that might push advocacy?!

Why not doing a wiki system that does NOT have a fix syntax but rather
allows defining its syntax rules in e.g. YAML and thus being entirely
flexible?
It could be distributed with a default set of rules reflecting the
UseMod/MediaWiki/Markdown syntax, but any versatile computer user could
just as easyly define another ruleset, maybe even for just a subset of
pages (e.g. a code related section where you need less common formatting
stuff and more highlighting).

It should have a proper user/groups system as well...

Another idea was formed by the problem of page renaming, typo correction,
etc., etc.

Why not give the wiki a web service API for being easily able to create bots
without being forced to use libcurl or that kind of thing? Then you could
be able to create whole sections on your website that are automatically
updated, following your rules. (And no, I would not use XML for the
webservice API, rather YAML, because it has a much better data/user data
rario)

> This actually has been implemented and works fine. It's not released yet
> and also not intended to be a base for a perl6-wiki. I'm just posting it
> to suggest a possible syntax. Interestingly it is very similar to
> Markdown although I never heard about it before :)
> 
> Regards,
> -Thomas
> 
> [1]: I believe everyone has to build one on its own ;)

I can share this believe ;)

Regards,

Udo
-- 
That which is not good for the bee-hive cannot be good for the bees.
0
post
6/6/2006 9:50:14 AM
Ask Bj=F8rn Hansen <ask@perl.org> writes:
> Woah, we are getting really far away from talking about perl6
> here...

Kind of a usenet law or corollary? "Every discussion about wikis ends
in a discussion about the best wiki syntax."

Steffen
--=20
Steffen Schwigon <schwigon@webit.de>
Dresden Perl Mongers <http://dresden-pm.org/>
0
schwigon
6/6/2006 12:23:22 PM
Udo G=FCngerich schrieb:
> Why not doing a wiki system that does NOT have a fix syntax but rather
> allows defining its syntax rules in e.g. YAML and thus being entirely
> flexible?
> [..]
> It should have a proper user/groups system as well...
> [..]
> Why not give the wiki a web service API [..]

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.

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.

But targeting such a "feature monster" will probably take too much
development time.

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
0
mail
6/6/2006 12:25:18 PM
--Signature_Tue__6_Jun_2006_13_34_10_+0100_4sjJ4CSz+59=/sRx
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

PiBBc2sgQmr4cm4gSGFuc2VuIDxhc2tAcGVybC5vcmc+IHdyaXRlczoNCj4gPiBXb2FoLCB3ZSBh
cmUgZ2V0dGluZyByZWFsbHkgZmFyIGF3YXkgZnJvbSB0YWxraW5nIGFib3V0IHBlcmw2DQo+ID4g
aGVyZS4uLg0KPiANCj4gS2luZCBvZiBhIHVzZW5ldCBsYXcgb3IgY29yb2xsYXJ5PyAiRXZlcnkg
ZGlzY3Vzc2lvbiBhYm91dCB3aWtpcyBlbmRzDQoNCllvdSdyZSBiZWluZyBhIGJpdCBvcHRpbWlz
dGljIHRoZXJlLCBhcmVuJ3QgeW91PyBUaGUgb25seSB3YXkgeW91J2QgZW5kDQphIG15LXdpa2kt
aXMtYmV0dGVyLXRoYW4teW91cnMgdGhyZWFkIHdvdWxkIGJlIHRvIG1vdmUgb3ZlciB0byBzb21l
IGxlc3MNCmNvbnRyb3ZlcnNpYWwgaXNzdWUsIGxpa2UgdGV4dCBlZGl0b3JzIG9yIHRoZSBJcmFx
IGludmFzaW9uLg0KDQo+IGluIGEgZGlzY3Vzc2lvbiBhYm91dCB0aGUgYmVzdCB3aWtpIHN5bnRh
eC4iDQoNCi0tIA0KIkFuZCBJIHNlZSBsb3NpbmcgbG92ZSBpcyBsaWtlIGEgIHdpbmRvdyBpbiB5
b3VyIGhlYXJ0OiAgZXZlcnlib2R5IHNlZXMgDQogeW91J3JlICBibG93biAgYXBhcnQ7ICBldmVy
eWJvZHkgIHNlZXMgIHRoZSAgd2luZCAgYmxvdyAgaW4gR3JhY2VsYW5kLiINCiAtLSBQYXVsIFNp
bW9uLCAxOTg2IC4uLi4uLi4gSSBhbSB0aGUgRGFuY2UgQ29tbWFuZGVyLCBhbmQgSSBvcmRlciBG
VU4hIA0KaHR0cDovL3N1cnJlYWwuaXN0aWMub3JnLyAtIEluc3RhbGxpbmcgV2luZG93cyBpbiB5
b3VyIGhlYXJ0IHNpbmNlIDIwMDMuDQo=

--Signature_Tue__6_Jun_2006_13_34_10_+0100_4sjJ4CSz+59=/sRx
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEhXZGgoQ42ohbFw0RAt21AJ9mIDO1pbV0Ei6hSKBE0mnpvNRGcgCaAjWi
It7dUCfD9bFxO4PwMwgULWc=
=iMrI
-----END PGP SIGNATURE-----

--Signature_Tue__6_Jun_2006_13_34_10_+0100_4sjJ4CSz+59=/sRx--
0
masoch
6/6/2006 12:34:10 PM
Iraq invasion indeed.... wait, shouldn't go there.

I particularly like the syntax of Textile or even Markdown (preferring
the former). In Ruby-land, these exist as RedCloth and BlueCloth. I
understand porting isn't fun, but I think that this is a viable
option, if not a great choice.

Not that this is a great example, but Instiki uses the
Textile/RedCloth syntax for textual formatting.

As an aside, I must apologize for interrupting in a conversation that
I've only been privileged to see the last four responses. I'm
extremely interested in learning Perl6 and in particular seeing this
Wiki come to fruition (if not participating myself).

Thought I'd offer up my suggestion about syntax. I'll wait on
participating more until I've read more of what's already been said.

M.T.
0
chiology
6/6/2006 2:59:46 PM
* 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.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html
0
juerd
6/6/2006 3:18:08 PM
On Tue, 2006-06-06 at 10:59 -0400, Matt Todd wrote:
<snip>
> I particularly like the syntax of Textile or even Markdown (preferring
> the former). In Ruby-land, these exist as RedCloth and BlueCloth. I
> understand porting isn't fun, but I think that this is a viable
> option, if not a great choice.
<snip>

For what it's worth, there is an existing Textile implementation in
Perl5 (Text::Textile on CPAN), and it seems reasonably functional from
my (very) limited time playing with it.  That should at least ease the
initial porting - or the module could be used as-is (hooray for P5 -> P6
interoperability!), and ported over time.

I'd also like to second the Textile suggestion.  Of the "prepackaged"
wiki syntax styles I've seen, it seems to be one of the cleanest while
still being nicely expressive.

Hez

0
hez
6/6/2006 3:41:46 PM
* Juerd <juerd@convolution.nl> [2006-06-06 17:50]:
> side-by-side layouts (extremely useful for showcasing
> differences between Perl 5 and Perl 6)

Good point.

> * Markdown does not have tables.

But it lets you embed verbatim HTML as an escape hatch for
constructs that it does not model, and although it will normally
not format the content of block-level HTML tags, you can ask it
to do so anyway by adding a `markdown="1"` attribute to a
particular tag.

There have also been several long discussions about tables and
definition lists on the Markdown mailing list, too (some started
by Gruber himself). Table and DL syntax will eventually be added.

> * Textile does not have paragraphs in table cells.

Textile does not support nesting constructs (like code blocks
within list items or the like) at all.

> * Kwiki does not have paragraphs in table cells.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>
0
pagaltzis
6/6/2006 5:14:19 PM
Quoth juerd@convolution.nl (Juerd):
> 
> * 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.

This may be a stupid suggestion, but would it not be possible to
create some minimal set of extensions to pod which will do what we need?
Preferably something <duck> rst-like?

Ben

-- 
   If you put all the prophets,   |   You'd have so much more reason
   Mystics and saints             |   Than ever was born
   In one room together,          |   Out of all of the conflicts of time.
benmorrow@tiscali.co.uk                             The Levellers, 'Believers'
0
benmorrow
6/6/2006 6:46:18 PM
There are alternatives to using tables for side-by-side using
paragraphs. Simply having one cell for each line, for instance, allows
for highlighting green the added lines and red the removed ones, etc.

Also realize that it is not necessarily the duty of Textile (et al) to
handle that aspect beyond text formatting. A diff or history-revision
view goes beyond the context of the tool.

Lastly, I'm not sure paragraphs belong in table cells. You could
certainly argue that a paragraph could full well be tabular data, but
I find it hard to believe that it fits the bill. (This is speaking on
an XHTML 1.0 Strict basis.)

So, in that regard, I don't believe that this is an issue. The real
reason to use Textile (for instance) is the natural ease of using it
for most things we need.

Just a thought.

M.T.
0
chiology
6/6/2006 8:46:08 PM
--Signature_Tue__6_Jun_2006_22_21_14_+0100_YQ28TrS0XlCJrzC0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

> Also realize that it is not necessarily the duty of Textile (et al) to
> handle that aspect beyond text formatting. A diff or history-revision
> view goes beyond the context of the tool.

I don't think Juerd was talking about tables for the purposes of showing
version diffs, but so you can give pairs of examples of equivalent Perl
5 and Perl 6 code side-by-side.

--=20
"I tried snorting coke once, but the bubbles went right up my nose and I
knocked the glass over."   -- 'Sordid Confessions of a Teenage Innocent'
http://surreal.istic.org/                                It means peace.

--Signature_Tue__6_Jun_2006_22_21_14_+0100_YQ28TrS0XlCJrzC0
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEhfHOgoQ42ohbFw0RAk1aAJ0fZ6efE/kUkpauZ3GCcJOoWap1yQCgjFv2
3V4nTc3ymf/wkFYQHeKrPYU=
=LkxT
-----END PGP SIGNATURE-----

--Signature_Tue__6_Jun_2006_22_21_14_+0100_YQ28TrS0XlCJrzC0--
0
masoch
6/6/2006 9:21:14 PM
Matt Todd skribis 2006-06-06 16:46 (-0400):
> There are alternatives to using tables for side-by-side using
> paragraphs. Simply having one cell for each line, for instance, allows
> for highlighting green the added lines and red the removed ones, etc.

Visually pleasing, but technically incorrect, and practically annoying:
selecting a block of code is no longer possible, let alone testing and
running it automatically.

> Also realize that it is not necessarily the duty of Textile (et al) to
> handle that aspect beyond text formatting. A diff or history-revision
> view goes beyond the context of the tool.

Not my point. A Perl 6 wiki needs to explain how Perl 6 differs from
Perl 5. Not with diff(1) output, obviously.

> So, in that regard, I don't believe that this is an issue.

Pity.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html
0
juerd
6/6/2006 10:29:21 PM
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.
0
post
6/6/2006 10:30:59 PM
* Ben Morrow <benmorrow@tiscali.co.uk> [2006-06-07 01:25]:
> Preferably something <duck> rst-like?

I was wondering why noone had proposed Kwid yet. Doesn’t anyone
like it?

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>
0
pagaltzis
6/6/2006 11:36:18 PM
I also agree that Object Oriented Design would work wonderfully well
here. The key here is prototyping its shape and then filling in the
details once it has taken this shape.

I like the term 'messages' for methods because it reminds me that the
objects must send requests, forms of communication, to the other
objects. That's always struck me as a great visual help (I'm a visual
learner).

With that in mind, we could full-well begin the structuring of the
project as it pertains to blocks of functionality: a component to
handle visual rendering (whether it include Textile, Markdown,
Wiki-whatever, or all three), data persistence layer (ORM, anybody?),
etc.

I'm sorry if I'm being obnoxiously obvious here, but I like to start
things out simple and I think it would be a good step towards a
product.

For what it's worth,

M.T.
0
chiology
6/7/2006 4:12:54 AM
Juerd,

My mistake: I misunderstood what you were saying (probably due to haste).

But really, then, there are alternatives to using tables, such as
DIVs, as well as simply modifying the parsing step to also parse for
this special case in addition to Textile or what-have-you.

I guess if I said anything worth-while in my last reply it is that I
think <P>s don't belong in <TABLE>s (and their children).

Sorry for the confusion (on my part).

M.T.
0
chiology
6/7/2006 4:16:23 AM
Hi,

I have never understand this "my wiki syntax is better than yours" 
thing. It's like "my templateing engine is better than yours".

I feel like which should have "wiki.conf" with :

....
 syntaxhandler = SuperbPerl6Wiki::Syntax::MediaKwikiMikiBiky
....

That shall please everyone. :)

- Fagzal
0
concept
6/7/2006 12:23:10 PM
Udo G=FCngerich schrieb:
> Thomas Wittek wrote:
>> Unfortunately you probably have to throw away/heavily modify earlier
>> increments, if you add features like a flexible syntax, which will nee=
d
>> a different internal infrastructure.
>=20
> Well, if object-oriented design has any advantage at all, here it is!
> [..]
> 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).

Of course. But I guess that the architecture/design for such a flexible
piece of software will be relatively complex. I think that creating this
architecture might even take too long to get a running wiki quickly.
Where "quickly" of course is a term still to be defined ;)

-Thomas
0
mail
6/7/2006 1:00:14 PM
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
0
mail
6/7/2006 1:15:21 PM
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/20060603202407.14284.qmail@lists.develooper.com
0
mail
6/7/2006 1:49:13 PM
* Thomas Wittek <mail@gedankenkonstrukt.de> [2006-06-07 15:05]:
> I guess that the architecture/design for such a flexible piece
> of software will be relatively complex.

All I can think of is “YAGNI”.

Defining a syntax in a configuration file doesn’t strike me as a
particularly smart move. You will either end up with a pretty
rigid parser that caters to a class of only superficially
different syntaxes, in which case diversity equals drawback
because you have to cope with documents written in incompatible
(though similar) syntaxes for no real gain (because all the
syntaxes are similar in expressiveness). Or you will end up
writing a parser interpreter whose “configuration” is really a
more or less turing complete language.

I’ve seen this sort of thing play out all too many times. And I’m
pretty sick of little languages by now. (Hey, wasn’t that why
Larry began writing Perl in the first place?)

Let’s use Perl 6 Grammars to define syntaxes. We are just about
to get this mindblowingly awesome tool for parsing; why insist on
tieing our feet together and having to hop around like that?

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>
0
pagaltzis
6/7/2006 2:29:09 PM
On 07/06/06, A. Pagaltzis <pagaltzis@gmx.de> wrote:
> Let's use Perl 6 Grammars to define syntaxes. We are just about
> to get this mindblowingly awesome tool for parsing; why insist on
> tieing our feet together and having to hop around like that?

This is the smartest suggestion I've yet seen on the subject, but, not
being all *that* familiar with Perl6 Grammars (aren't they something
like contextually-smart regexes?), can anyone give an example of Perl
6 code that uses grammars and can express some wiki-formatting?

Also, is this thread trying to define the standard for a winning wiki
(eg "to get the grand you must use perl 6 Grammars") or is this more
of a community effort to actually produce a wiki? Not sure where that
prize thread ended up.

--
Michael
0
micmath
6/8/2006 11:12:19 AM
Michael Mathews wrote:

> This is the smartest suggestion I've yet seen on the subject, but, not
> being all *that* familiar with Perl6 Grammars (aren't they something
> like contextually-smart regexes?), can anyone give an example of Perl
> 6 code that uses grammars and can express some wiki-formatting?

Yes, that'd be VERY helpful, as I am not sure whether I'd be able to produce
a Perl6 grammar without examples.

> Also, is this thread trying to define the standard for a winning wiki
> (eg "to get the grand you must use perl 6 Grammars") or is this more
> of a community effort to actually produce a wiki? Not sure where that
> prize thread ended up.

I am not sure how all others see it, but initially it is divided.

*It* meaning the specification and the tools used to meet the spec, so
probably we should just try to list up some of the features that it OUGHT
to have and then hopefully end up having ALL the features listed.

From my point of view the major aim is *getting a web-something to enable us
to document, communicate, structure and manage knowledge*. Is this so?

Then - IMO - the key features would be:

- Simple but expressive wiki-syntax providing stuff like code highlighting
        - as to the line-based vs. block-based battle: I think a combination
          of both has its advantages
- Revision control and diff stuff
- easy user interface
- easy storage backend, initially a file based thing with file locks (maybe
in YAML even?) like UseMod uses one
- File upload (for pics), maybe file inclusion mechanism to make wiki pages
modular (e.g.

include: head.p6w
include: navi.p6w
= heading =
stuff...

....stuff
include: footer.p6w
)

where head.p6w etc. could have been uploaded or so

- Link management, means to rename pages, links or even globally rename
strings (<- missed this one sometimes)
- (sitewide) search facility
- maybe hierarchical structure for subpages or sections
- oh, IMO quite important: enhanced CSS support, because everything else is
hell

Can't think of much else to get started but I guess this is enough
already ;)

Regards,

Udo

-- 
That which is not good for the bee-hive cannot be good for the bees.
0
post
6/8/2006 12:23:51 PM
* Michael Mathews <micmath@gmail.com> [2006-06-08 13:15]:
> This is the smartest suggestion I've yet seen on the subject,
> but, not being all *that* familiar with Perl6 Grammars (aren't
> they something like contextually-smart regexes?), can anyone
> give an example of Perl 6 code that uses grammars and can
> express some wiki-formatting?

Not me, at the time of writing. :-) I’ve just read the documents:

    http://dev.perl.org/perl6/doc/design/apo/A05.html
    http://dev.perl.org/perl6/doc/design/exe/E05.html
    http://dev.perl.org/perl6/doc/design/syn/S05.html

It doesn’t take more than that to see that P6 Grammars will blow
any existing way to write parsers clear out of the water, though.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
0
pagaltzis
6/8/2006 2:08:46 PM
I would recommend using a templating system as opposed to having calls
to include files in numerous pages. Even though it's minimal, it's
still duplication, and it can get rather messy.

I know that some people don't know about or don't like it, but I would
recommend setting things up in a Model-View-Controller pattern,
partially to approach the templating thing. If we sequester the
database-specific stuff from the templating-specific stuff and the
primary logic, it provides for a more orthogonal system.

However, MVC is just one solution. I'm open to others. Regardless,
though, I know we need to find a structure that inherently works well
in modular development with a big (if somewhat disparate) team.

Also, what is the best place to begin learning the Perl6 syntax? A
tutorial would be great, as a dry technical specification of the
language doesn't teach very well.

M.T.
0
chiology
6/8/2006 2:50:46 PM
To bring this back around to the implementation portion in an effort =20
to get back on topic..

There are also sample grammars (for those who like samples in =20
addition to docs) available in the parrot source tree, e.g.:

http://svn.perl.org/parrot/trunk/compilers/tge/TGE/Parser.pg
http://svn.perl.org/parrot/trunk/languages/APL/lib/APLGrammar.pg   =20
(view as utf-8)
http://svn.perl.org/parrot/trunk/languages/punie/lib/punie.pg

While these are using parrot directly, the PGE (Parrot/Perl6 Grammar =20
Engine) is already a very large subset of valid Perl6 rules =20
constructs. You could probably write the parser in parrot today, and =20
then use the same grammar to drive a perl6 (in parrot or otherwise) =20
implementation.

I would also recommend using kwid as a basis for any markup, given =20
its current status with pugs/perl6.

Regards.

On Jun 8, 2006, at 10:08 AM, A. Pagaltzis wrote:

> * Michael Mathews <micmath@gmail.com> [2006-06-08 13:15]:
>> This is the smartest suggestion I've yet seen on the subject,
>> but, not being all *that* familiar with Perl6 Grammars (aren't
>> they something like contextually-smart regexes?), can anyone
>> give an example of Perl 6 code that uses grammars and can
>> express some wiki-formatting?
>
> Not me, at the time of writing. :-) I=92ve just read the documents:
>
>     http://dev.perl.org/perl6/doc/design/apo/A05.html
>     http://dev.perl.org/perl6/doc/design/exe/E05.html
>     http://dev.perl.org/perl6/doc/design/syn/S05.html
>
> It doesn=92t take more than that to see that P6 Grammars will blow
> any existing way to write parsers clear out of the water, though.
>
> Regards,
> --=20
> #Aristotle
> *AUTOLOAD=3D*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined =20
> wantarray]/e;$1};
> &Just->another->Perl->hacker;
>

--
Will "Coke" Coleda
will@coleda.com


0
will
6/8/2006 3:04:03 PM
[...]

> Also, what is the best place to begin learning the Perl6 syntax? A
> tutorial would be great, as a dry technical specification of the
> language doesn't teach very well. 

IMHO examples teach the best. A table with "Perl5 version" versus "Perl6 
version" examples - even one-liners - would be lovely.

I don't know if this URL had already shown up in the list or not, but 
anyway, I have just come across with it:
http://cog.cognitivity.com/perl6/

There is also a PD version of the Perl5 Cookbook for Perl6 - I can't 
find the link to it :(, but IMO it is(?) included in the Pugs docs.

- Fagzal
ps: BTW, I am also in favour of MVC. :)
0
concept
6/8/2006 3:21:48 PM
I was just reading the AES referenced above and I can say now that I'm
really happy about some changes to Regexes, and that a grammar may
well be what we're looking for. However, even with this great tool, we
still have to handle the implementation. Though I can see the benefit
of using the grammar, the problem is still which syntax to use, and
then having to define the syntax in grammars.

I can definitely see it as an eventuality, possibly a necessity, but
it doesn't solve the problem at hand of _which formatting syntax to
use_.

Then again, this is only a facet of the whole thing. There still is
the persistence layer, the architecture, and a myriad of other
problems.

Maybe this would be a good time to (semi-)formalize some form of
recommendations for the project?

M.T.

P.S. -- MVC, I think, is the way to go.
0
chiology
6/8/2006 3:59:31 PM
On 08/06/06, Matt Todd <chiology@gmail.com> wrote:
> Maybe this would be a good time to (semi-)formalize some form of
> recommendations for the project?

Agreed. (We're talking about the minimal requirements to get the
thousand for a pswiki, right?) Will this work like the Perl 6
RFC-Roundup, where the community made proposals and then Larry sorted
them out? Or who shall be the judge?

--michael
0
micmath
6/8/2006 4:09:48 PM
Honestly, I'm not familiar with the Perl way of doing things, but I'm
open to learn especially because I see the Perl community going
through a (much-needed) reform. Thusly, I'm not familiar with the RFCs
(Request For Change?) but I do see the merit for something similar.

However, as far as the judge is concerned, I don't think that it could
work any other way than having a dialog on each RFC (or otherwise). A
general concensus must be reached for each proposal.

A wiki or some form thereof should be set up for everyone to have a
place to submit RFCs and also as a source to find out the decisions on
those RFCs. Indeed, depending on the Wiki used, discussion for the RFC
could be held on there, though I like using the list-serv (as
discussion is its sole purpose).

In summary, we the community will need to both make the proposals and
collectively decide (by matter of majority vote or something to that
effect).

If someone could briefly describe the aspects of an RFC, that would
help clear things up in my mind and give us some kind of standard.

As an aside, I'm coming from the PHP community which has left a very
bad taste in my mouth. The community and the project itself is stale
and not open to change (they're cheering about adding Unicode support
as their big new feature for version 6, which is great, but pathetic
at the same time). However, I'm also partly in the Ruby community, and
I feel quite at home there. I'm hoping to get into Perl again. I've
not used it since version 4!

M.T.

P.S. -- I'm working on a proposal (of sorts) for the beginning of the
architecture.
0
chiology
6/8/2006 5:24:11 PM
On 08/06/06, Matt Todd <chiology@gmail.com> wrote:
> Honestly, I'm not familiar with the Perl way of doing things, but I'm
> open to learn especially because I see the Perl community going
> through a (much-needed) reform. Thusly, I'm not familiar with the RFCs
> (Request For Change?) but I do see the merit for something similar.

Yup. That was Larry's idea for gathering everyone's opinions. Many,
many RFC documents were written and then battled over (this was a few
years back). Then The Big Guy (respectfully) distilled it all down
into A Plan. I kinda doubt that this project warrants as much process
as Perl 6 itself, but I would like to some process implemented that
involves everybody. Of course, it's not my money, so my opinion is
only just that.

> As an aside, I'm coming from the PHP community which has left a very
> bad taste in my mouth. The community and the project itself is stale
> and not open to change (they're cheering about adding Unicode support
> as their big new feature for version 6, which is great, but pathetic
> at the same time). However, I'm also partly in the Ruby community, and
> I feel quite at home there. I'm hoping to get into Perl again. I've
> not used it since version 4!

Welcome home, my brother. Hopefully the distinction between these
different communities will begin to blur as Parrot learns to speak
more languages.

--michael
0
micmath
6/8/2006 5:43:35 PM
[Sorry Michael, I didn't mean to send it you twice. :) ]

I like the RFC idea. I will read up on them and see, if it is a
particular format, how to simplify it. But, most definitely, the
community must have dialog about the requests. For each request
really.

On the architecture note, I've written up a quick article about a
possible implementation of the MVC pattern for the wiki. Indeed, it's
a very flexible implementation and really resembles a framework. (To
be honest, it's from my work on my PHP framework.)

Please take a moment to look through it and let me know what you folks
think. It's not meant to be anything other than a starting point, if
for nothing else then for discussion.

http://www.maraby.com/lang/perl6/wiki/architecture.html

Again, let me know what you think.

M.T.
0
chiology
6/9/2006 12:04:08 AM
Hello,

> From: Michael Mathews [mailto:micmath@gmail.com]
[...]
> On 08/06/06, Matt Todd <chiology@gmail.com> wrote:
> > Maybe this would be a good time to (semi-)formalize some form of
> > recommendations for the project?
> 
> Agreed. (We're talking about the minimal requirements to get the
> thousand for a pswiki, right?) Will this work like the Perl 6
> RFC-Roundup, where the community made proposals and then Larry
> sorted
> them out? Or who shall be the judge?

Good question. :-) I was originally hoping it would be The Perl
Foundation, based on a spec developed by @Larry.

FYI, here's the original post:
"$1,000 prize for Perl 6 Wiki written in Perl 6",
(http://www.nntp.perl.org/group/perl.perl6.users/127).

However, there turned out to be problems with doing a prize through
The Perl Foundation. My more recent proposal then became:
"$1,000 Grant (was: prize) for Perl 6 Wiki written in Perl 6",
(http://www.nntp.perl.org/group/perl.perl6.users/217).

I didn't get any response to that at all. So my current plan is to
offer a prize directly myself, but I'm uncomfortable being the one who
decides (1) what the (detailed) spec should be, and (2) who (person,
group) has satisfied it, and should be declared the winner.

The last link above gives my general requirements. I'd like something
that could be done sooner rather than later. Using available Perl 5
modules to get started is fine, as long as Perl 6 code plays some sort
of significant role. I'm looking for an initial "XP style" (start with
the minimum that will work) implementation that's "good enough for
initial practical use", but which leaves the door open to a subsequent
series of major improvements. The aim is not to start with a Perl 6
showcase, but to get the ball rolling on a "usable prototype" that can
*later* be incrementally transformed into a Perl 6 showcase. (Again,
please see the ".../217" link/post above for some elaboration.)

I haven't had a chance to adequately digest and think over the
preceding wiki posts from last week, but I think tables should be a
requirement. 

As a point of departure, I'm mostly favorably inclined to Juerd's
remarks on #perl6 (near the end of the log):
(http://colabti.de/irclogger/irclogger_log/perl6?date=2006-06-04,Sun).

However, I think the detailed specs are less important than getting a
usable first version of a wiki (that makes some significant use of
Perl 6) up and running on feather. If someone can produce a wiki that
others are willing to use (and, of course, that doesn't preclude
migration to nicer interfaces), that's the most important thing for
me.

So, back to answering the original question. (1) Is there is someone
else on this mailing list that most other posters would generally
support as the designated "spec pumking" or "proxy @Larry"? (The
guiding criteria are to be the sorts of considerations I've outlined
above.) Once the preliminary spec converged on something that attained
a moderate degree of consensus in this group, I'd declare it to be the
target spec. (2) Would Juerd be willing to serve as the judge of who
sufficiently fulfilled the specs?

Hopefully others would rally behind whoever steps forward to go for
the prize, which could be {demonstrated, facilitated} by making
incremental code drops in the pugs svn tree, under
".../examples/.../p6wiki/".

Best regards,
Conrad Schneiker

http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl
6 Wiki.)

www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam
technology.)


0
conrad
6/10/2006 10:37:46 PM



> -----Original Message-----
> From: A. Pagaltzis [mailto:pagaltzis@gmx.de]
> All I can think of is "YAGNI".

Good point, but I wonder how many other people recognize the
significance of that crypticism?

    http://en.wikipedia.org/wiki/YAGNI

    http://www.jera.com/techinfo/xpfaq.html

Other good guidelines to keep in mind (for purposes of this project):

    "Start with the smallest useful feature set."

    "Do the simplest thing that could possibly work."

Best regards,
Conrad Schneiker

http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl
6 Wiki.)

www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam
technology.)

0
conrad
6/11/2006 6:57:08 PM
Matt Todd wrote:
> On the architecture note, I've written up a quick article about a
> possible implementation of the MVC pattern for the wiki. Indeed,
it's
> a very flexible implementation and really resembles a framework. (To
> be honest, it's from my work on my PHP framework.)
>
> Please take a moment to look through it and let me know what you
folks
> think. It's not meant to be anything other than a starting point, if
> for nothing else then for discussion.
>
> http://www.maraby.com/lang/perl6/wiki/architecture.html
>
> Again, let me know what you think.

Well, first of all, thanks.

1) s|//|#|  # More generally, Perl 6 look and feel. :-)

2) (General comment for all discussions.) It would be nice if any
proposal included a clear separation between the long term vision and
the *minimal* subset needed to get started *now*, as noted elsewhere:
(http://www.nntp.perl.org/group/perl.perl6.users/264),
(http://www.nntp.perl.org/group/perl.perl6.users/263).

3) (Quoting from above link): "I propose that the wiki be called P6 to
signify its use of Perl6." I presently prefer something like the
"Perl++ Wikicosm". Reasons: (a) easy googling (only web hit I see
today is my previous use), (b) to avoid implying a pure Perl 6
implementation, (c) I'd like this to serve the Perl 5.8/(5.9/5.10)
community as well as Perl 6, and more generally, (d) to serve as a
common crossroads for other Parrot-related language interoperability
information, among other things.

Best regards,
Conrad Schneiker

http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl
6 Wiki.)

www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam
technology.)




0
conrad
6/11/2006 7:20:56 PM
1) Understood. I've been disconnected from Perl for a while, and this
is really the first time I've been participating in the Perl
community. Thanks for the heads-up. :)

2) I agree that it is both important and pertinent to get the general
requirements down for the project, but I do see a need and a benefit
to having the architecture forming in the meanwhile. I see how these
things can be connected, obviously, but with a fairly flexible
architecture it can be easy to expand or change it as needed. If we
have the skeletal system in place, we can add the muscle and the skin
on as needed. [Read more of my comments below.]

3) I'll be honest and say that I'm not a big fan of the 'Wikicosm'
part, but the Perl++ part works for me. I particiularly like simple
names. Maybe we could go with something distinctive, much like
'Joomla' is or 'Drupal', etc. Something different, and not nearly as
explicit.

Mainly speaking on point number 2 again, I agree that we need to be
discussing and deciding on the minimal features, but this is does not
mean that the architecture should be poorly designed. Even with a
weakly implemented yet well designed base, it would be easier to take
this minimal wiki and upgrade it into something very powerful.

I guess what my very first recommendation (before even a name) is that
we have a flexible, well-designed archiecture, preferrably with an MVC
pattern, with RESTful-like (URL) mapping, etc. I believe that this
will be integral to the successful adoption in the community because
it allows for very expansive modification.

I will be looking over some other features to recommend. Wherein shall
we officially submit our recommendations? Here? And is there a
specific way to do so? (This is more of a conversation-generating
question.)

M.T.
0
chiology
6/11/2006 9:34:54 PM
On 11/06/06, Matt Todd <chiology@gmail.com> wrote:

> 2) I agree that it is both important and pertinent to get the general
> requirements down for the project, but I do see a need and a benefit
> to having the architecture forming in the meanwhile. I see how these
> things can be connected, obviously, but with a fairly flexible
> architecture it can be easy to expand or change it as needed. If we
> have the skeletal system in place, we can add the muscle and the skin
> on as needed. [Read more of my comments below.]

Having just been away on yet /another/ training course in Agile
methodology, I'd say this is a classic disconnect of concerns. Sounds
like Conrad just want something that works, and can be available
quickly -- a rather traditional customer point-of-view. Matt, you're
talking about implementation details, which is a traditional Developer
concern, but not all that important to the Customer. You don't
disagree, you just have different roles. The real answer is "yes". Do
implement it well, but also as quickly as possible. This isn't really
a point of disagreement.

> 3) I'll be honest and say that I'm not a big fan of the 'Wikicosm'
> part, but the Perl++ part works for me. I particiularly like simple
> names. Maybe we could go with something distinctive, much like
> 'Joomla' is or 'Drupal', etc. Something different, and not nearly as
> explicit.

Well, if we can have a "blogosphere" I suppose we can also have a "wikicosm" :-)


> Mainly speaking on point number 2 again, I agree that we need to be
> discussing and deciding on the minimal features, but this is does not
> mean that the architecture should be poorly designed. Even with a
> weakly implemented yet well designed base, it would be easier to take
> this minimal wiki and upgrade it into something very powerful.

I already made this argument in an earlier post, when I suggested a
requirement that the accepted solution have a modular architecture
(plug-ins, for example). I forget the exact response, but it was
something like "whatever". Again, I think Conrad is really mainly
concerned with something that works, and quick. The rest is just icing
-- correct me if I'm wrong here.

> I guess what my very first recommendation (before even a name) is that
> we have a flexible, well-designed archiecture, preferrably with an MVC
> pattern, with RESTful-like (URL) mapping, etc. I believe that this
> will be integral to the successful adoption in the community because
> it allows for very expansive modification.

Yes. yes, yes, yes...

> I will be looking over some other features to recommend. Wherein shall
> we officially submit our recommendations? Here? And is there a
> specific way to do so? (This is more of a conversation-generating
> question.)

This gets to a point thats been niggling me, which is that because of
the prize/grant involved there is automatically an environment created
which does not reward general community collaboration. Okay, you're
talking about requirements there, and that is a bit different, but if
I were the sort who /was/ motivated by money I would likely not be
motivated to get less of it by sharing. So a prize would seem to
encourage a certain amount of go-it-alone-ed-ness, and also (because
of the "first done, first won" rule) it would also seem to encourage
the most minimal feature set possible. Hence there isn't any reward
for community discussions of desired features. That's probably an okay
thing if the goal is to get something done fast. Perhaps the community
will get involved after that, when it comes time to adding-on?

Somebody needs to run with this, but it's risky to think that one
could start work on a p6 wiki candidate, only to be pipped at the end
to some other wiki engine. So then would we carry on and have 2/more
on offer, or discard the work, or give the work to the guy who already
has a grand in his pocket?

Just some random thoughts there, this thread seems to have gone a bit quiet!

--michael
0
micmath
6/12/2006 12:44:28 PM
I'll be honest and say that I'm not too concerned with the
prize/grant, so that may be the reason I want to go beyond that
minimal ideal. I'm specifically concerned with a poorly designed (or
at least slightly clumsy to upgrade) wiki, all in for the sake of
speed, minimal functionality, and money. At least, it has the
potential to become this very quickly.

Like I said, I'm not concerned with the monies: I'd be happy to work
with the community on a well-designed, well-developed modular system.
(Therefore, it may well be more appropriate to create a new thread?)

Then again, I'm not proposing something obscenely complex, either.
I've developed an MVC framework similar to what I've described here in
PHP5 and I know implementation of the (pseduo) framework part can be
done quickly.

In retrospect, I think my biggest thought here is on going ahead and
getting the interfaces established, interconnecting the pieces. Yes,
this is definitely development-centric as my role serves best for. I'm
just having a hard time thinking that a goal like quickly-as-possible
can coexist with to-be-used-thereafter without a great deal of
(violent) refactoring. My goal in that was to keep that from
happening.

I hope I've addressed something close to what you were saying.
Hopefully we (I, really) can get back on topic! :D

Now, to the requirements talk: how important is the availability of
revision history in this bare-bones wiki? Text formatting is important
(if relatively easy to hook up), but is being discussed,
implementation-wise. What kind of authorship and administration would
you (the granter or whomever, really) prefer? Every writer must have
an account? Are there any accounts other than an administrator? I
won't even get into admins, moderators, readers, editors, etc. How
about RSS feeds (which is usually more appropriate for versioned
pages, et al, but is useful even for recently-updated pages)? Do you
want it to work with the concept of pages/topics or is there another
way you want to represent the data? What kind of categorization do you
want to support? What kind of control do you want over the visual
aspects (CSS, HTML, et al)? Did you have something in mind other than
a web administration interface? What kind of moderation privileges
would you like? What basic actions do you want to perform for a page
(or whatever)?

That's a lot to answer, I know. Think of it as a good example of the
stuff that needs to be thought about (even if not implemented).

M.T.
0
chiology
6/12/2006 1:49:57 PM
> From: Michael Mathews [mailto:micmath@gmail.com]
> Having just been away on yet /another/ training course in Agile
> methodology, I'd say this is a classic disconnect of concerns.
> Sounds
> like Conrad just want something that works, and can be available
> quickly -- a rather traditional customer point-of-view. 

With the very important condition that what is done doesn't preclude
incremental evolution to a great system. That's something that I've
mentioned numerous times, but which almost everyone seems to overlook.
I don't see these as mutually exclusive, I just didn't see any
delineation of what would be a reasonable minimal subset to use as the
initial specification. 

> Well, if we can have a "blogosphere" I suppose we can also have a
> "wikicosm" :-)

Maybe Perlcosm? :-) Since it will hopefully be a big advance over
wikis in the long run.

> > Mainly speaking on point number 2 again, I agree that we need to
> be
> > discussing and deciding on the minimal features, but this is does
> not
> > mean that the architecture should be poorly designed. Even with a
> > weakly implemented yet well designed base, it would be easier to
> take
> > this minimal wiki and upgrade it into something very powerful.

Absolutely.

> I already made this argument in an earlier post, when I suggested a
> requirement that the accepted solution have a modular architecture
> (plug-ins, for example). I forget the exact response, but it was
> something like "whatever". Again, I think Conrad is really mainly
> concerned with something that works, and quick. The rest is just
> icing
> -- correct me if I'm wrong here.

Again, subject to not unreasonably precluding great improvements.

> This gets to a point thats been niggling me, which is that because
> of
> the prize/grant involved there is automatically an environment
> created
> which does not reward general community collaboration. 

That's part of the thinking behind the recent suggestion that perhaps
entry to the "contest" should be declared by code drops to the pugs
svn in the example subtree, with the hope that people would rally
behind the first person to take the initiative and show a reasonable
record of progress.

Best regards,
Conrad Schneiker

http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl
6 Wiki.)

www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam
technology.)

0
conrad
6/12/2006 3:18:20 PM
Conrad Schneiker skribis 2006-06-10 15:37 (-0700):
> target spec. (2) Would Juerd be willing to serve as the judge of who
> sufficiently fulfilled the specs?

I would, but perhaps my personal opinions would matter too much to be an
objective judge.


Regards,

Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html
0
juerd
6/12/2006 5:53:20 PM
Matt Todd wrote:

> [Lots of stuff....]

General comment: It's much easier to comprehend posts in mail lists or
reading through the archives if you quote something of what you're
responding to. 

> Now, to the requirements talk: how important is the availability of
> revision history in this bare-bones wiki? 

Seems important to me, but I'm not a wiki expert. 

> What kind of authorship and administration
> would
> you (the granter or whomever, really) prefer? Every writer must have
> an account? Are there any accounts other than an administrator? I
> won't even get into admins, moderators, readers, editors, etc. 

IMHO, it's good social sanity check to require author accounts. 

> Text formatting is
> important
> (if relatively easy to hook up), but is being discussed,
> implementation-wise.

An extension of Perl6 POD would be interesting. As an option. And
maybe crazy.

> How
> about RSS feeds (which is usually more appropriate for versioned
> pages, et al, but is useful even for recently-updated pages)? 

Don't know. 

I like seeing Pugs svn commits on comp.perl6.language. Probably
doesn't scale well in the long run, but it seems to be a very good
idea to begin with.

> Do you
> want it to work with the concept of pages/topics or is there another
> way you want to represent the data? 

Seems to work well enough for documentation purposes. 

It would be very cool if the Pugs svn doc tree was mirrored in a
subsection of (the) Perl++ (Wiki), and could be {authored, edited}
through Perl++. I think that {simplification, convenience} would
greatly expand participation in generating Perl 6 documentation. 

Interesting side note: "perl++" on Google shows this link as the 3rd
hit: (www.nntp.perl.org/group/perl.perl6.users).

Later on, a mechanism that made it feasible for smart IDEs to find
relevant Perl 6 Cookbook descriptions in Perl++ and lift code samples
would be very cool. 

> What kind of categorization do
> you
> want to support? 

Not sure I understand question. 

> What kind of control do you want over the visual
> aspects (CSS, HTML, et al)? Did you have something in mind other
> than
> a web administration interface? 

Not at the moment.

> What kind of moderation privileges
> would you like? 

Omnipotent and clairvoyant. :-) But I'd settle for the minimum needed
to thwart religious editing wars, spamming, and so on.

> What basic actions do you want to perform for a page
> (or whatever)?

Don't know. 

How about whatever twiki does? It's perl-ish and appears to be a
pretty substantial offering:
(http://en.wikipedia.org/wiki/Comparison_of_wiki_software).

> That's a lot to answer, I know. 

I'm sure others can provide better answers.

Just $perl6.say .... # Needs work. JAPH needs to be updated. :-)

Best regards,
Conrad Schneiker

http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl
6 Wiki.)

www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam
technology.)


0
conrad
6/15/2006 5:24:54 AM
Conrad Schneiker schrieb:
> 3) (Quoting from above link): "I propose that the wiki be called P6 to
> signify its use of Perl6." I presently prefer something like the
> "Perl++ Wikicosm".

Another idea: Wiki is hawaiian for "quick, fast". Why not take another
hawaiian word? Some examples (you will find more on the web):

-Aloah: Greeting, love ;)
-K=C4=81kau: Write
-Kala: To release, free
-K=C4=81melo: Camel
-Makana: Gift
-Mana: Spiritual power
-Momi: Pearl
-Nani: Beautiful
-Pinao: Dragonfly

Maybe combine these word with "wiki": K=C4=81melo wiki =3D "Fast camel" :=
).

I'd also like "Bikini wiki", sounds sexy, doesn't it? Unfortunately,
this word does not have much in common with Hawaii, instead of both
lying in the pacific ocean.

-Thomas
0
mail
6/15/2006 8:32:05 AM
On Thu, Jun 15, 2006 at 10:32:05AM +0200, Thomas Wittek wrote:
> Another idea: Wiki is hawaiian for "quick, fast". Why not take another
> hawaiian word? Some examples (you will find more on the web):
> 
> -Aloah: Greeting, love ;)
> -Kākau: Write
> -Kala: To release, free
> -Kāmelo: Camel
> -Makana: Gift
> -Mana: Spiritual power
> -Momi: Pearl
> -Nani: Beautiful
> -Pinao: Dragonfly

parrot => pāloke, manu pāloke

0
trammell
6/15/2006 3:29:07 PM
I really like these. I think you're on to something. I'm definitely in
favor of Momi Wiki, or just Momi.

Maybe we can even be very corny and call it 'Aloha Wiki'... Hmm.

Yes, Bikini Wiki sounds sexy. I like how they both 'lie' in the
pacific ocean... as opposed to being worn... ;)

M.T.
0
chiology
6/16/2006 2:12:12 AM
On Thu, Jun 15, 2006 at 10:12:12PM -0400, Matt Todd wrote:
> I really like these. I think you're on to something. I'm definitely in
> favor of Momi Wiki, or just Momi.

Just 'Momi' sounds good, I really like it.

-Tom
0
tom
6/16/2006 2:21:09 AM
On Fri, Jun 16, 2006 at 11:51:09AM +0930, Tom Lanyon wrote:
: On Thu, Jun 15, 2006 at 10:12:12PM -0400, Matt Todd wrote:
: > I really like these. I think you're on to something. I'm definitely in
: > favor of Momi Wiki, or just Momi.
: 
: Just 'Momi' sounds good, I really like it.

Hmm, 'Momi' will be mispronounced by some English speakers as "mommy".

Also, many geeks will read foreign CV-ish names as Japanese, so it'd
be cool if it works as a bilingual pun.  In Japanese, /momi/ means
'fir tree' or 'unhulled rice'.  On the other hand /nani/ means 'what?',
which might work a little better for a wiki.

Larry
0
larry
6/16/2006 3:21:15 PM
------=_Part_86127_8869112.1150486749253
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 6/16/06, Larry Wall <larry@wall.org> wrote:

> Hmm, 'Momi' will be mispronounced by some English speakers as "mommy".
>
> Also, many geeks will read foreign CV-ish names as Japanese, so it'd
> be cool if it works as a bilingual pun.  In Japanese, /momi/ means
> 'fir tree' or 'unhulled rice'.  On the other hand /nani/ means 'what?',
> which might work a little better for a wiki.


Of course, English speakers could also mispronounce nani as "Nanny."
Probably not enough reason to throw it out, but both Momi and Nani could
easily be mispronounced as maternal figures in English.

Sage

------=_Part_86127_8869112.1150486749253--
0
sagelt
6/16/2006 7:39:09 PM
A simple, if naive fix could be to make the logo a phonetic
representation (or whatever it's called). Just a simple
pseudo-solution.

M.T.
0
chiology
6/17/2006 5:06:48 AM
> Larry Wall profounded:
> On Fri, Jun 16, 2006 at 11:51:09AM +0930, Tom Lanyon wrote:
> : On Thu, Jun 15, 2006 at 10:12:12PM -0400, Matt Todd wrote:
> : > I really like these. I think you're on to something. I'm
> definitely in
> : > favor of Momi Wiki, or just Momi.
> :
> : Just 'Momi' sounds good, I really like it.
> 
> Hmm, 'Momi' will be mispronounced by some English speakers as
> "mommy".

All that's missing is -hood and apple pi (Pugs-style).

> so it'd
> be cool if it works as a bilingual pun.

IMHO, preferably in semi-universal "languages" (such as math,
programming notation), so as not to overly discriminate against other
major natural languages (versus all of them :-).

OTOH, "Perl++" is already a multi-way pun, and is also multiply
semi-self-descriptive. 

(((((((((((-:
Along those lines, "++Lisp++" is tempting name, but would {likely,
unintentionally} offend most pro-Lispers, and less cosmopolitan
Perlers would {likely, unfortunately} not recognize this as
overwhelmingly positive comment on Perl6. 

Related claim: very roughly speaking, Lisp:AI prog <--> Perl6:NI prog,
but where Perl NI (Natural Intelligence) programming will eventually
both {subsume, exceed} traditional Lisp AI prog, due to much better
P2H (Program to Human) "cognitive impedance matching". 

Related analogy: In terms of notation, Perl6 versus modern Lisps is
analogous to "deism versus dotism" in calculus notation (Leibnitz's
"d/dx notation" versus Newton's "dot notation"). The d-notation
(especially when enhanced with "quasi-sigils" distinguishing full
derivatives, partial derivatives, loop integrals, and so on) proved
very much easier to "naturally" comprehend and use--especially for
increasingly {sophisticated, complex} applications. For decades after
the Leibnitz/Newton inventions of calculus, dogged adherence to dotism
had a considerable stultifying effect on its users, relative to the
rapidly progressing deists (for whom combinational play with the
notation suggested many {important, powerful} {applications, theorems,
proofs}), and so dotism was eventually abandoned. The main difference
here is that Perl6 came along well after modern Lisp, and had the
prior examples of {Smalltalk, Python, Ruby, Perl5, and so on} to
suggest better "human interfaces" for incorporating "Lisp's greatest
hits" (among other things).
:-)))))))))))

BTW, back to the original topic, "Perlcosm" is also semi-punish, and
s/co/ga/ is perhaps too much more so. :-)

But I still {prefer, vote for} Perl++ as the name of the primary
meta-wiki for all things Perl. 

Best regards,
Conrad Schneiker

http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl
6 Wiki.)

www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam
technology.)

0
conrad
6/17/2006 8:10:37 PM
Reply:

Similar Artilces:

NoScript 1.1.6.16 and 1.1.6.21
I received a popup for version 1.1.6.16 and updated. On the update page I was informed that 1.1.6.21 was the latest and was directed to the direct download page. Bob Vanderveen Anonymous Bob wrote: > I received a popup for version 1.1.6.16 and updated. On the update page I > was informed that 1.1.6.21 was the latest and was directed to the direct > download page. Now 1.1.6.22 http://noscript.net/getit#direct -- Dennis Windows, Linux and OS X are just device drivers for Firefox http://lists.thedatalist.com/pages/Firefox.htm "Anonymous Bob" <no....

(Question about MozillaBuild) Using Subversion 1.6.6 insted of 1.6.3
Sorry if this is the wrong place to post this. I've noticed that Subversion 1.6.3 is included in MozillaBuild 1.5. It is in: C:\mozilla-build\svn-win32-1.6.3 Also I've noticed that Subversion 1.6.6 is the latest version of Subversion. Is it safe to replace all the files in this folder with the files from latest version? Should I replace only the files in the 'bin' folder? Or should I not update Subversion? (NOTE: Getting the files for the latest version is not a problem because I already have them. I'm just asking whether it is safe to replace the files ...

upgrading from 6.5.1 to 6.5.6
I ran the patch upgrade for gw 6.5 to get us to sp6. Ran the update and rebooted. all seem to upgrade except the gwia component. It was soft abending the server. I tried re installing the gwia from the new SDD directory and it still did not work. Is there any problems with going from 6.5.1 to 6.5.6 directly? gw 6.5.1 (poa, mta, gwia, webaccess on same server). One post office. novell 6 sp 5. Normally not, but try deleting sccfilt.bin, if it exists. <rmburt@nationalindemnity.com> wrote in message news:_Z7Qh.2389$mb6.563@prv-forum2.provo.novell.com... >I r...

3.6.6 #6
Name: Ulrich Email: Jambor-Ingatt-onlinedotde Product: Firefox Summary: 3.6.6 Comments: Update 3.6.3 to 3.6.6 Fehler: Proxy server nicht gefunden ( not found ) Firefox funktioniert nicht mehr was tun ? Browser Details: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE) AppleWebKit/531.21.8 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10 From URL: http://hendrix.mozilla.org/ Note to readers: Hendrix gives no expectation of a response to this feedback but if you wish to provide one you must BCC (not CC) the sender for them to see it. ...

How do I connect PB 6.5 to Oracle 8.1.6 using Net8.1.6?
I am using PB6.5 (build 444) and I've Installed Oracle client (Net8) v8.1.6 to connect to Oracle Server 8.1.6. I can connect via SQL*Plus; however, When i try to connect thru Powerbuilder i get the following message: "Error while trying to retrieve text for error ORA-12154" Any help on this matter will be greatly appreciated. Which driver are you trying to use? The 7.x drivers require the '@' prefix, the 8.x drivers don't (and will generate such an error message if you provide it). On Wed, 07 Mar 2001 16:40:13 -0500, in powersoft.public.powerb...

6 #6
Name: levinh_1991@.com.vn Email: levinh_1991atdotcomdotvn Product: Minefield Summary: 6 Comments: hoangha Browser Details: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090816 Minefield/3.7a1pre From URL: http://hendrix.mozilla.org/ Note to readers: Hendrix gives no expectation of a response to this feedback but if you wish to provide one you must BCC (not CC) the sender for them to see it. ...

PVCS VM 6.6 and PB 6.5.1 ?
What are the things to do to migrate from VM 6.0 to VM 6.6 when using from PB 6.5.1 or PB7. What are the advantages of the new version ? Is there a specific document on that ? Thanks ...

upgrade to 1.6.13 (from 1.6.12)
Name: Product: Firefox Summary: upgrade to 1.6.13 (from 1.6.12) Comments: I clicked the update button a couple of hours ago and have had a barber pole going ever since. Can't find anything on your site which might help a non-techie like me address the problem. Browser Details: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 From URL: http://hendrix.mozilla.org/ Note to readers: Hendrix gives no expectation of a response to this feedback but if you wish to provide one you must BCC (not CC) the sender for them to see ...

From AppModeler 6.1.0 to 6.1.5
Hi, I just installed PowerDesigner AppModeler 6.1.5. I was using version 6.1.0 before. Is there any migration procedure to follow for my models created with 6.1.0 ? With 6.1.5 the comparison between the PDM and the APM seems not to work. The Menu Item �Database | Modify Database� detects changes where there are none. What could be the problem ? Simon. I think the archive created with 6.1.0 may not be 100% compatible with 6.1.5. I seem to remember them adding fields to the file somewhere in there. If you have a backup copy of the PDM, then you should open that in 6.1.5 ...

Backward Compatability 6.1
I just discovered that there are backware compatibility issues between these versions. One problem is that Invalid Characters are dropped "<Null>" in the name and code attribute properties unless you delete the default values from the invalid characters text box in the Name and Code Tabs under the Model Options drop down from File. Has anyone else had other compatability problems? Any known problems related to the 6.1.01 update? Thanks Hal Williford I had noticed this little issue a while back, when I was working on the 6.0 beta. As far as 6.1.01 ...

upgrade to gw 6.5.6 and messenger 1.0.6
Hi: How is step for upgrade from gw 6.5.1 to gw 6.5.6 and upgrado from messenger 1.0.1 to messenger 1.0.6? Regards... David Coquimbo-Chile dlagoss@manejatuvida.cl wrote: > Hi: > > How is step for upgrade from gw 6.5.1 to gw 6.5.6 and upgrado from > messenger 1.0.1 to messenger 1.0.6? Install the new agents onto your server(s). I tend to install new agents into new directories so that in case the new agents doesn't work you can roll back easily to the previous version. I don't know anything about messenger. -- Cheers, Edward ...

Problems using Data Architect 6.1.3 with MetaWorks 6.1.1
I have a MetaWorks Repository version 6.1.1. I installed Data Architect 6.1.3 on my Windows desktop, modified an old 6.1.1 CDM with that client, and consolidated it back to the same MetaWorks 6.1.1 model where the CDM came from. It seems to be corrupted after cosolidation: duplicate data items in some entities, data items detached from entities in other cases. Is there a 6.1.3 version of MetaWorks available ? Must I upgraade to that, or is there a safe method to combine 6.1.1 MetaWorks with the 6.1.3 DA client ? -- Ranko Petrovic Database Developer MDSI Mobile Data Solutions Dir...

steps to import a user in GW 6.5 c1 version 1.3.6?
Can someone help me with the steps needed to import a user (with a specific FID) in GW 6.5 with c1 1.3.6? the gwimport32 tool doesn't seem to turn on with c1 version 1.3.6. Thanks! - JD Tried rerunning the GWPort32 setup, it is working here OK against 1.3.6c Cheers Dave -- Dave Parkes [NSCS] Occasionally resident at http://support-forums.novell.com/ Hi Dave, Thanks for the feedback. I went back and reinstalled (ie re unzipped) the file, and this time did it correctly. I'm set. - Jd "Dave Parkes" <Dave@Norgren.co.uk> wrote in mes...

SOS: Sync with Oracle 8.1.6.1.0 using 8.1.6.1.0 ODBC Driver
Help! If any customer has successfully replicated bi-directionally from ASA7 to Oracle 8i (8.1.6) using the Oracle 8.1.6 Oracle ODBC Driver, we would appreciate any insight you may have concerning the small number of steps involved in implementing replication. I may be contacted directly at (206) 933-4956. Martin Douglas Senior Data Architect e-Commerce Group Food Services of America Please always specify the version and MORE importantly the BUILD number of ASA you are using with each post. If you are having problems with this Oracle driver, some of our customers hav...

Client 6.5.6 Update 1 on 6.5.4 POA
Yikes! I made the mistake of installing the 6.5.6 Update 1 client to use against a 6.5.4 Post Office. As a result, I cannot log in to the Post Office on that machine. The machine in question is a Dell PowerEdge SC1420 server that is destined to become a Blackberry Enterprise Server. The server O/S is Windows Server 2003. The GroupWise Post Office runs on a HP ProLiant ML350 with server O/S NetWare 6.5. I've uninstalled the client and Windows Messaging. However, the C:\ Drive icon has taken on the appearance of the stylistic GroupWise Globe Icon! Strange indeed! Is the...

Web resources about - $1,000 prize for Perl 6 Wiki written in Perl 6 - perl.perl6.users

Disneyland's 'Star Wars' Park Already In The Works
Earlier this year, Disneyland announced that an official Star Wars land was being created and the Southern California theme park is already getting ...

Two shot dead by Chicago cop responding to domestic violence call
A Chicago police officer shot and killed two people early on Saturday while responding to a domestic disturbance call on the city’s West Side, ...

RSS believes India, Pakistan and Bangladesh will reunite through ‘goodwill’ one day: Ram Madhav
"The RSS still believes that one day these parts, which have for historical reasons separated only 60 years ago, will again, through popular ...

Syrian rebel commander's death imperils peace process
Zahran Alloush's killing seen as undermining peace process but opposition leader says he will attend Geneva talks.

UK weather sees country hit by worst floods in decades
Huge swathes of the North of England, including parts of Manchester and Leeds and their satellite towns, were under up to 6ft of water after ...

Armie Hammer's Family Christmas Photo is Picture Perfect!
Armie Hammer and Elizabeth Chambers pose with their 12-month-old daughter Harper on their Christmas card. The couple’s dog Archie is also featured ...

'Extremely Dangerous' Tornado Reported Outside Dallas as Storm Death Toll in ...
CBS News 'Extremely Dangerous' Tornado Reported Outside Dallas as Storm Death Toll in ... ABC News Ladarren Phillips surveys tornado damage ...

Hawaii Just Can’t Seem To Name Anything After Obama, Despite Repeated Attempts
Hawaii just can’t seem to name anything after Barack Obama, the state’s only native son to become president. Supporters of the president have ...

Baby Thrown Over Bridge Hoax: Mother And Daughter Charged After Falsely Telling Police They Saw A Man ...
A mother and her daughter are facing criminal charges after Massachusetts police learned that the pair falsely filed a police report, claiming ...

Iraqi Forces Pummel ISIS In Ramadi As Battle Continues To Rage
While U.S. trained Iraqi forces have been notorious for dropping their U.S. issued weapons and running in the face of fights with ISIS, slowly ...

Resources last updated: 12/27/2015 2:49:46 AM