2010/6/17 Jerome Peace <
[hidden email]>:
> "Try something. If that doesn't work. Try something else."
> --The only way I know to program. -Jer
>
>
> In response to my original post:
>
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-June/151287.html>
>>Ralph Johnson johnson at cs.uiuc.edu
> Tue Jun 15 10:13:28 UTC 2010 wrote:
>
>>So, what is wrong with the Squeak wiki? Why isn't it used as much?
>
> Ummm. That was NOT the question.
>
> In the context of the original:
>
> Problem:
> Documentation of squeak and varients is a bear to find in an organized fashion.
>
> The question I raised is who out there is willing to help solve this problem?
>
> Answering as you have I am hurt. It was both out of context, off thread, and essentially of the tone:
>
> Things are bad lets (implicitly) keep them that way.
>
> In source documentation is a good idea. I've tried lots of it. When I fixed things with change sets I wrote extensive prologs which guided me and others as long as prologs were included in the source. MC broke that. Plus the prologs got jettisoned as bath water from time to time anyway.
>
Nothing prevents the MC comment to be copied in auto-generated changeset prolog.
I think for long it would be a good thing, facilitating export to any
MC-phobia environment.
Would you mind implementing it ?
> MC allows comments. But you never see them all in one place at one time. Another loss of knowledge. You had a student who was working on making a database of previous version of methods. He finished his project and disappeared. The database for 3.9 or 3.10 never was created. You never followed up on that. So no database of versions exists. I miss that diagnostic tool because it was the only way to find out which fool introduced which bug.
>
That's one problem I have with MC: what for and in which revision did
this method change ?
Agree on the idea that having a web browsable pan-forks method history
database is a must.
The database should record which set of changes a particular revision
comes with, and for what goal (new feature, clean-up, refactoring,
...), which revision of which fork, which MC-package, etc...
But hunting the bug producers...
Errare humanum est.
He who doesn't code doesn't introduce bugs.
To me a fool is a programmer that never introduces bug (I admire fools).
A subject of greater interest is why the hell this bug didn't get noticed?
(undocumented feature, untested, etc...)
> Mediawiki's are everywhere. Swiki is in only one place. That tells several things. First off, many more people out there know how to edit a mediawiki. We could carry on this mailing list in Esperanto but we use English because we are familiar with it. Language is not a local phenomenon. Nor are flavor of wikis.
>
> So I need to ask again. In the context of the original problem is there anyone out there willing to help with a solution that includes using a Mediawiki?
>
> Yours in curiosity and service, --Jerome Peace
>
>
>
>
>
>
>
>
>
Locked
