On 11/13/2012 6:51 AM, Andrei Alexandrescu wrote:
> I think that's a great idea. I'm not a frequent user of our Wiki, but e.g. for
> DIPs it's nice to have a better engine. I don't see why Walter would oppose a
> change.

I don't oppose a change.

But would mediawiki be better (the one used by Wikipedia)?

On 11/13/2012 11:26 AM, David Nadlinger wrote:
> The only question raised by my suggestion is hosting. I don't know what
> infrastructure dlang.org is hosted on right now, and if running a MediaWiki
> instance on it would be possible. Given the moderate amounts of traffic to
> expect, I don't think this should be an insurmountable problem, though – heck,
> if it wouldn't occasionally be unstable, I would even offer my own VPS (1 GB
> RAM, reasonably fast CPU/disk).

Brad Roberts is experienced at hosting mediawiki.

On Tue, 13 Nov 2012, Walter Bright wrote:

> On 11/13/2012 11:26 AM, David Nadlinger wrote:
> > The only question raised by my suggestion is hosting. I don't know what
> > infrastructure dlang.org is hosted on right now, and if running a MediaWiki
> > instance on it would be possible. Given the moderate amounts of traffic to
> > expect, I don't think this should be an insurmountable problem, though ?
> > heck,
> > if it wouldn't occasionally be unstable, I would even offer my own VPS (1 GB
> > RAM, reasonably fast CPU/disk).
> 
> Brad Roberts is experienced at hosting mediawiki.

Minimally.  I'm not prepared to host one for a wide audience where I need to be prepared to deal with the internet masses.

On 11/13/12 1:23 PM, Walter Bright wrote:
> On 11/13/2012 11:26 AM, David Nadlinger wrote:
>> The only question raised by my suggestion is hosting. I don't know what
>> infrastructure dlang.org is hosted on right now, and if running a
>> MediaWiki
>> instance on it would be possible. Given the moderate amounts of
>> traffic to
>> expect, I don't think this should be an insurmountable problem, though
>> – heck,
>> if it wouldn't occasionally be unstable, I would even offer my own VPS
>> (1 GB
>> RAM, reasonably fast CPU/disk).
>
> Brad Roberts is experienced at hosting mediawiki.

htp://wiki.dlang.org would be yum.

Andrei

On 11/13/12 1:55 PM, Andrei Alexandrescu wrote:
> On 11/13/12 1:23 PM, Walter Bright wrote:
>> On 11/13/2012 11:26 AM, David Nadlinger wrote:
>>> The only question raised by my suggestion is hosting. I don't know what
>>> infrastructure dlang.org is hosted on right now, and if running a
>>> MediaWiki
>>> instance on it would be possible. Given the moderate amounts of
>>> traffic to
>>> expect, I don't think this should be an insurmountable problem, though
>>> – heck,
>>> if it wouldn't occasionally be unstable, I would even offer my own VPS
>>> (1 GB
>>> RAM, reasonably fast CPU/disk).
>>
>> Brad Roberts is experienced at hosting mediawiki.
>
> htp://wiki.dlang.org would be yum.
>
> Andrei
>

s/htp/http/

> I'd say, let's move to http://wiki.dlang.org/GuiLibraries, and then work on keeping that.

+1

Le 13/11/2012 20:13, Jonathan M Davis a écrit :
> On Tuesday, November 13, 2012 09:45:17 H. S. Teoh wrote:
>> Unfortunately, using ranges in their most general sense
>> is looking like a pipe dream to me right now, and I'm ready to just move
>> on.
>
> The reality of the matter is that there are limits to any abstraction. In
> order to make it take more use cases and situations into account, it must
> become increasingly complicated, and eventually the abstraction becomes
> complicated enough that it's hard to use for even basic cases.

Let me disagree. As stated before, I never used moveXXX in my code. That doesn't mean it is useless, but that you can definitively work with an abstraction without messing around with all possible « extensions ».

I'd argue that this is the key to successful abstraction : a solid core, a possibility for extension and knowledge of such extension being optional.

> So, trying to
> make an abstraction work for everything comes at a definite cost. Rather, it
> should probably try and strike a good balance. It needs to be powerful enough
> to handle the majority of cases but still be simple enough to use in the
> average case. And ranges currently risk being too complicated to use in the
> average case without screwing them up somehow.
>

On 11/13/12 20:28 , David Nadlinger wrote:
> The MediaWiki extension used by Wikipedia for syntax highlighting [1]
> also supports D.
>
> David
>
>
> [1] http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi

Good stuff!

I hope we go for something feature-rich and capable like MediaWiki. I've just browsed the Extensions library and here are some other interesting extensions:

- Bugzilla integration. Have a handy summary page showing Regressions, Blockers etc.?
http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports

- Link to Amazon books by ISBN. Easily link to books and also have partner links.
http://www.mediawiki.org/wiki/Extension:Amazon-Linker
http://www.mediawiki.org/wiki/Extension:AmazonPartnerLink

- Revision Approval. Allow admins to mark a page rev. as "approved". Good for DIPs, Tutorials, Articles etc.?
http://www.mediawiki.org/wiki/Extension:Approved_Revs

- Rating. Allow users to rate pages.
http://www.mediawiki.org/wiki/Extension:ArticleRatings

- MarkAsHelpful. Allows a user to mark a resource as helpful.
http://www.mediawiki.org/wiki/Extension:MarkAsHelpful

- PDF Book. Gathers all pages in a category and renders them into a downloadable PDF. Imagine having all those D articles in a handy PDF.
http://www.mediawiki.org/wiki/Extension:Book

- Bucket voting. Allows a voting system where the user can distribute an allocated number of votes freely amongst a set of candidates. Bureaucracy galore.
http://www.mediawiki.org/wiki/Extension:BucketVoting

- Countdown. Shows JavaScript countdown to some date. DConf teaser etc.
http://www.mediawiki.org/wiki/Extension:Countdown

- Discussion. Allows to post comments on any page. Supports hierarchical structure of messages.
http://www.mediawiki.org/wiki/Extension:Discussion

- DoxyWiki. Integrates doxygen into MediaWiki.
http://www.mediawiki.org/wiki/Extension:DoxyWiki

- EmailToWiki. Allows emails and their attachments to be sent to a wiki as articles and uploaded files.
http://www.mediawiki.org/wiki/Extension:EmailToWiki

- EmbedVideo. For showing those D talks right in the wiki.
http://www.mediawiki.org/wiki/Extension:EmbedVideo

- Freenode IRC Chat. We already have a chat channel on Freenode. Users who just want to check it out can do so right in the wiki.
http://www.mediawiki.org/wiki/Extension:Freenode_Chat

- GitHub. Allows adding github gists into your articles easily. Perhaps a D Cookbook backed by github?
http://www.mediawiki.org/wiki/Extension:GitHub

- Graph. Takes a textual graph description between <graph> </graph> tags and turns it into a pretty flowchart diagram. For finally explaining those ranges to mere mortals ; )
http://www.mediawiki.org/wiki/Extension:Graph

- Math Formulas. We could finally formally show that ranges are insane too : P
http://www.mediawiki.org/wiki/Extension:Math

- MarkdownSyntax
http://www.mediawiki.org/wiki/Extension:MarkdownSyntax

- Progress. Easy way to see the progress of several tasks.
http://www.mediawiki.org/wiki/Extension:Progress

- ShareThis. Provides links to popular social bookmarking and news sources.
http://www.mediawiki.org/wiki/Extension:ShareThis

- Terminology. Enable a Glossary or define Terminology within MediaWiki using tooltips. Imagine a beginner reading "..and this is very useful in CTFE and UFCS, but not with UDAs."
http://www.mediawiki.org/wiki/Extension:Terminology

- TwitterFeed. Adds <twitterfeed> tag for displaying tweets.
http://www.mediawiki.org/wiki/Extension:TwitterFeed

- UML. Renders a UML model from text using MetaUML. A bit 2003 perhaps, but yeah.
http://www.mediawiki.org/wiki/Extension:UML

- UsenetSyntax. Allows simple Usenet highlighting such as *bold*, /italic/ and _underline_.
http://www.mediawiki.org/wiki/Extension:UsenetSyntax

- WhosOnline. Andrei and Walter can indulge in voyeurism.
http://www.mediawiki.org/wiki/Extension:WhosOnline

I also saw loads of spam-filters.

Full list at:
http://www.mediawiki.org/wiki/Extension_Matrix/AllExtensions


***

In my view, running a community should not be about what is the most convenient for a handful of authors, but what allows us to build the most useful and compelling community wiki. The wiki should not be a "handy notepad" easily accessible from the command-line, but a rich online information portal. Being able to present categorized and cross-linked information like upcoming events, latest Bugzilla bugs, DIPs with a threaded comment system, categories, table of contents, downloadable PDFs, approved tutorials, attached files, graphs, RSS-feeds etc., is very useful, if not now, then at least possibly at some point in time.

Heck, MediaWiki is rich enough that most of the dlang.org website could be run inside it. (Which is actually not an entirely bad idea imho. But I digress.)

MediaWiki (or something similar) for the win!

kind regards
/kraybourne

PS. Took a while to go through the Extensions. Re-checked the newsgroups now. Perhaps I'm already preaching to the choir at this point. Sorry for the noise in that case.

On Wed, Nov 14, 2012 at 12:51:45AM +0100, deadalnix wrote:
> Le 13/11/2012 20:13, Jonathan M Davis a écrit :
> >On Tuesday, November 13, 2012 09:45:17 H. S. Teoh wrote:
> >>Unfortunately, using ranges in their most general sense is looking like a pipe dream to me right now, and I'm ready to just move on.
> >
> >The reality of the matter is that there are limits to any abstraction. In order to make it take more use cases and situations into account, it must become increasingly complicated, and eventually the abstraction becomes complicated enough that it's hard to use for even basic cases.

In that case, I argue that the abstraction is a leaky one, and needs to be improved/replaced.

A successful abstraction, as deadalnix stated, is one that has a solid, consistent core, and which is extensible by user code to handle more complicated stuff. As the saying goes: "simple things should be simple, and hard things should be possible". When simple things are hard, and hard things are impossible, e.g., supporting transience is hard, or outright impossible, then you know something is fundamentally wrong with the design.

At this point it's probably futile, but I'll say it anyway: I think the *idea* of ranges is a very powerful one. It has the potential to be universally applicable to all linear access algorithms. The disappointment lies not in the idea, but in its implementation. The implementation failed to take into account the subtle difference between reference semantics and value semantics. This shortcoming is not something inherent in the idea of ranges itself, but rather in the range-based algorithms that failed to take this into account.

A truly generic algorithm will make no further assumptions than what is absolutely essential for its operation. For example, joiner does not *need* to assume the persistence of .front, yet the current implementation does. To me, this is sloppy programming. An algorithm that can be implemented without making such additional assumptions, shouldn't. OTOH, an algorithm that *does* require such an assumption needs to state it up front in some way, either by requiring something labelled as a non-transient range, or by an in-contract, or some such. Generic algorithms and unstated assumptions simply don't mix, because inevitably somebody will call it with the "wrong" range and things will break. Attempting to conflate the additional assumption (persistence of .front) with orthogonal properties of ranges is merely glossing over the real issue.

But since this isn't going to be fixed properly, then the only solution left is to arbitrarily declare transient ranges as not ranges (even though the concept of ranges itself has no such implication, and many algorithms don't even need such assumptions), and move on. We will just have to put up with an inferior implementation of std.algorithm and duplicate code when one *does* need to work with transient ranges. It is not a big loss anyway, since one can simply implement one's own library to deal with this issue properly.



> Let me disagree. As stated before, I never used moveXXX in my code. That doesn't mean it is useless, but that you can definitively work with an abstraction without messing around with all possible « extensions ».
> 
> I'd argue that this is the key to successful abstraction : a solid core, a possibility for extension and knowledge of such extension being optional.
[...]

+1.


T

-- 
Indifference will certainly be the downfall of mankind, but who cares? -- Miquel van Smoorenburg

On 11/14/12 7:29 AM, H. S. Teoh wrote:
> But since this isn't going to be fixed properly, then the only solution
> left is to arbitrarily declare transient ranges as not ranges (even
> though the concept of ranges itself has no such implication, and many
> algorithms don't even need such assumptions), and move on. We will just
> have to put up with an inferior implementation of std.algorithm and
> duplicate code when one*does*  need to work with transient ranges. It is
> not a big loss anyway, since one can simply implement one's own library
> to deal with this issue properly.

What is your answer to my solution?

transient elements == input range && not forward range && element type has mutable indirections.

This is testable by any interested clients, covers a whole lot of ground, and has a good intuition behind it.


Andrei