On Mon, Nov 12, 2012 at 03:57:42PM -0800, Andrei Alexandrescu wrote:
> On 11/12/12 3:14 PM, Jonathan M Davis wrote:
> >On Monday, November 12, 2012 12:28:14 Andrei Alexandrescu wrote:
> >>>Topic on range transience probably, as it is
> >>>almost concluded.
> >>
> >>I'm leaning toward doing nothing about this.
> >
> >As it stands, most everything assumes that front is not transient. But then we have ByLine and ByChunk. So, they just plain don't work as ranges for the most part, but they're in the standard library. Either they need to stop being transient or to stop being ranges (and use opApply), or we need to decide on a way to support them being transient as ranges.
> >
> >The best options at this point seem to be to either insist that all ranges have non-transient fronts (and adjust ByLine and ByChunk accordingly) or to go with the peekFront idea. The peekFront idea probably needs some examination though in order to work on the kinks (e.g. letting peekFront and front return different types might be useful in some circumstances, but in general, it's likely to cause a lot of problems if they don't both return ElementType!R).
> 
> Here are two thoughts:
> 
> 1. The notion of "this is an input range that is not a forward range, AND the element type has mutable indirections so it's not a proper value type" is a very close approximation of transiency. We could define that as a trait and have interested algorithms consult it.
> 
> 2. I'm reversing my attitude toward peekFront for the simple reason I've been there: moveFront, moveBack, and moveAt. And it's not a pretty place to be in. As soon as we're discussing peekFront there's the question of supporting peekBack and peekAt. I'm pretty sure people, if sufficiently motivated, will find examples of bidirectional and random-access transitory ranges that motivate such primitives.
[...]

You're right, introducing peekFront will lead to peekBack and peekAt, and it will add a lot of complications. I think the original .transient proposal is sounding more attractive at this point.

But anyway, it seems that this issue is going nowhere. At this point, I'm ready to just declare all transient ranges illegal and leave it at that.  I'll just duplicate std.algorithm where I need to work with transient ranges, as it's proving impossible to make any progress on this front. Short of defining a universal way of saying "I want to *duplicate* this value, not just get another reference to it", I don't see any way of solving this problem without introducing all sorts of complications. 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.

(I still wish Phobos algorithms would be written to not rely on the persistence of .front where possible, as I regard it as sloppy programming otherwise, but that's just IMAO, and in any case, it doesn't seem like anything is going to get done about it anyway, so let's just strike out transient ranges once for all and leave it at that.)


T

-- 
Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before.

On Tue, 13 Nov 2012 17:16:30 +0100
Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 11/13/12, Thomas Koch <thomas@koch.ro> wrote:
> > Now we need a decision on this issue
> 
> I think we need a proper discussion and a vote, not a decision yet. We should try and evaluate the wikis that are out there before settling for github right away. For one thing http://prowiki.org is pretty fast, whereas GitHub seems to be hosted in the States and is slower to access in Europe (it sure is slower to access for me compared to more popular websites, but that might not be true for others of course..).
> 

GitHub is just slow, period (I'm in the states). I don't think they care
about speed, only being Web 2.0 (even forward/back/bookmarking is
broken half the time, fuck I hate Web 2.0).

> And I think searchability is really important (prowiki sometimes sucks at this, but github is worse). The biggest problem I see with prowiki is the spamming issue.
> 
> Can gollum make nice colorized tables like this? http://prowiki.org/wiki4d/wiki.cgi?GuiLibraries Note also how the text reflows when you resize the window, I never see that happening with github wikis, they seem to be fixed in size.
> 
> It's too bad ProWiki is in Perl, if it was written in D we could contribute to it and modify it to our own needs.

What about pmwiki? It's fast, supports tables, has a sane layout that actually reflows like a proper page should, and in my limited experience ( http://semitwist.com/goldwiki ) spamming doesn't seem to be a big problem once you've enabled the auto-updated blacklists and a basic password.

Andrei Alexandrescu wrote:

> The only thing we need to worry about is preserving links lest Google search pagerank gets lost. Is it possible to keep the old link convention?

I don't agree that we have to worry about the pagerank of the existing
links. Content about D is not a competitive subject like shopping, porn or
news.
Once the wiki contains good content about D it should quickly be on the
first places on google. A few inlinks from our blogs, forums, twitter,
facebook and stackoverflow will suffice. It's astonishing how quickly google
lists you on the first page if you have specialized and good content.

Regards, Thomas Koch

On Tuesday, 13 November 2012 at 14:51:58 UTC, Andrei Alexandrescu wrote:
> On 11/13/12 3:23 AM, Thomas Koch wrote:
>> Tobias Pankrath proposed the github wiki engine (free software[3]) and I
>> agreed that it would be best to just enable the wiki in a new project at the
>> D github account[4].

In case you didn't catch the original thread, I also pointed out there that switching from ProWiki to Gollum might be a case of jumping from the frying pad into the fire. Gollum, the GitHub wiki software, supports none of the useful features of common Wiki software, such as search (!), comfortable history browsing, talk pages, wach lists, permission control, etc. There are also a couple of UI issues which make it less than ideal for larger installations, like the fact that you can accidentally change/break a page URL very easily by just editing the main title box.

I suggested using MediaWiki instead, the same wiki engine used by Wikipedia (familiarity bonus!) and many big open source communities (Arch/Fedora/Gentoo/Suse, KDE, OpenOffice, Haskell, …).


> I think that's a great idea. I'm not a frequent user of our Wiki, […]

You should be, just like all of us should. ;)  I feel that way too much of the fruits of our collective labor/discussions gets lost in the fairly impenetrable newsgroups archives (for the record, I'm only very infrequently contributing to the wiki as well, mostly because of the annoyances already discussed).


> The only thing we need to worry about is preserving links lest Google search pagerank gets lost. Is it possible to keep the old link convention?

Hardly, without owning prowiki.org. Also, I'm not even sure if URLs like http://prowiki.org/wiki4d/wiki.cgi?GuiLibraries would be a good candidate for keeping – I'd say, let's move to http://wiki.dlang.org/GuiLibraries, and then work on keeping that. Given that wiki4d never was immensely popular, I think we can bear that change. In fact, I think the much bigger problem compared to search engine ranking would be breaking links/bookmarks. Maybe, moving to wiki.dlang.org would even lead to a _better_ ranking on D-related topics.

Maybe Helmut Leitner would also be willing to set up to http://prowiki.org/wiki4d/ 301-redirect to a landing page on the new installation (which could in turn also redirect the user to the appropriate page, if there is a page with a matching name). This way, we could avoid both problems.

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

David

On Tuesday, 13 November 2012 at 16:20:38 UTC, Andrej Mitrovic wrote:
> On 11/13/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>> The biggest problem I see with prowiki
>> is the spamming issue.
>
> Another big issue is it's lack of syntax highlighting. gollum wins
> there, but other wikis might support D too. I'm not sure which do
> though.

The MediaWiki extension used by Wikipedia for syntax highlighting [1] also supports D.

David


[1] http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi

On 11/13/12 11:02 AM, Thomas Koch wrote:
> Andrei Alexandrescu wrote:
>
>> The only thing we need to worry about is preserving links lest Google
>> search pagerank gets lost. Is it possible to keep the old link convention?
>
> I don't agree that we have to worry about the pagerank of the existing
> links. Content about D is not a competitive subject like shopping, porn or
> news.

I was worried about people finding stale pages on Google.

Andrei

On Tuesday, 13 November 2012 at 19:36:37 UTC, Andrei Alexandrescu wrote:
> On 11/13/12 11:02 AM, Thomas Koch wrote:
>> I don't agree that we have to worry about the pagerank of the existing
>> links. Content about D is not a competitive subject like shopping, porn or
>> news.
>
> I was worried about people finding stale pages on Google.

Thus my suggestion of contacting the admin of prowiki.org regarding setting up a redirect. If this should not be possible, we could always replace all the pages with links to the new ones…

David

On 11/13/12, David Nadlinger <see@klickverbot.at> wrote:
> The MediaWiki extension used by Wikipedia for syntax highlighting also supports D.

Great. Considering MediaWiki is heavily used by millions of people, it wouldn't be a bad choice at all.

On Tuesday, 13 November 2012 at 19:26:55 UTC, David Nadlinger wrote:
> On Tuesday, 13 November 2012 at 14:51:58 UTC, Andrei Alexandrescu wrote:
>> On 11/13/12 3:23 AM, Thomas Koch wrote:
>>> Tobias Pankrath proposed the github wiki engine (free software[3]) and I
>>> agreed that it would be best to just enable the wiki in a new project at the
>>> D github account[4].
>
> In case you didn't catch the original thread, I also pointed out there that switching from ProWiki to Gollum might be a case of jumping from the frying pad into the fire. Gollum, the GitHub wiki software, supports none of the useful features of common Wiki software, such as search (!), comfortable history browsing, talk pages, wach lists, permission control, etc. There are also a couple of UI issues which make it less than ideal for larger installations, like the fact that you can accidentally change/break a page URL very easily by just editing the main title box.

I suggested gollum to avoid hosting problems, though I've never used it itensively. That said, I don't think, we can do anything wrong with a Mediawiki instance.

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

- Jonathan M Davis