On Friday, 23 November 2012 at 11:56:58 UTC, tn wrote:
> Fix for the font size issue:
> http://dwiki.kimsufi.thecybershadow.net/User:Tmn/vector.css
>
> (Taken from here: http://en.wikipedia.org/wiki/MediaWiki:Common.css)

Applied, thanks.

On 2012-11-23 15:06, Vladimir Panteleev wrote:

> Applied, thanks.

Looks much better, thanks.

-- 
/Jacob Carlborg

On 11/23/12, Jacob Carlborg <doob@me.com> wrote:
> On 2012-11-23 15:06, Vladimir Panteleev wrote:
>
>> Applied, thanks.
>
> Looks much better, thanks.
>
> --
> /Jacob Carlborg
>

Looks perfect now. Thanks guys.

On Thursday, 22 November 2012 at 16:05:10 UTC, H. S. Teoh wrote:
> On Wed, Nov 21, 2012 at 10:10:51PM -0800, Jonathan M Davis wrote:
>> On Friday, November 16, 2012 18:09:44 H. S. Teoh wrote:
>> > On Fri, Nov 16, 2012 at 08:52:39PM -0500, Jonathan M Davis wrote:
> [...]
>> > > The problem is that supporting transience complicates ranges even
>> > > further, and they're already too complicated. And supporting every
>> > > possible use case is likely to require yet further modifications
>> > > to ranges, complicating them even further. We have to draw the
>> > > line somewhere.
>> > 
>> > Since that is the case, that really only leaves us with two choices:
>> > (1) declare transient ranges outright illegal, or (2) make all
>> > default ranges non-transient (e.g. ByLine, ByChunk), and let
>> > documentation warn the user that transient ranges may not work with
>> > every algorithm.
>> > 
>> > I'm leaning towards (2), because every other option brought up so
>> > far sucks one way or another. I know coding by convention is frowned
>> > upon here, but clearly, transience is an issue that requires human
>> > insight to solve on a case-by-case basis, and no simple enforceable
>> > solution exists. Thus, the only choice seems to be to leave it up to
>> > the programmer to do the right thing. The redeeming point is that we
>> > will make byLine and byChunk non-transient by default, so that users
>> > who don't want to care, don't need to care -- the code will just do
>> > the right thing by default. We can then provide byLineFast and
>> > byChunkFast for people who want the extra performance, and know how
>> > to deal with transience correctly.
>> > 
>> > This solution requires no further code changes beyond making byLine
>> > and byChunk non-transient by default, which is what you have been
>> > pushing for anyway. And it doesn't have any of the drawbacks of the
>> > other approaches.
> [...]
>> > If we agree on (2), then ranges will be no more complicated than
>> > they are today. The two Phobos offenders, byLine and byChunk, will
>> > be non-transient by default. The documentation will warn the user
>> > that transient ranges are to be "used at your own risk", just like
>> > casting void pointers and other risky language features that are
>> > nevertheless sometimes necessary.
>> 
>> I'd agree with #2, except that I don't know where we'd put warnings
>> about transience. On isInputRange? It certainly doesn't make sense to
>> put them on every function. At most, it would make sense to put them
>> where front or popFront is described.
> [...]
>
> I'd put it on isInputRange, since that's where .front is defined.
> Indicate that transient ranges are used "at your own risk" because some
> algorithms will not work correctly.
>
> And optionally, each algorithm that supports transience can be
> documented as such (the assumption being that if something isn't
> explicitly documented to support transience, it probably doesn't).
>
>
> T

What if we did it so that transient ranges would have to define transient property (as was previously proposed), and isInputRange, isForwardRange and others would get an additional parameter allowTransient. The default value of that argument would be false, so those templates would evaluate to false for transient ranges by default. Then algorithms that can work with transient ranges would use
...
if(isInputRange!(R, true))

instead of

if(isInputRange!R)

The algorithms that don't support transient ranges would not need to be changed.  Wrapper ranges such as map's result would define transient property if the wrapped range defines it.

> What if we did it so that transient ranges would have to define transient property (as was previously proposed), and isInputRange, isForwardRange and others would get an additional parameter allowTransient. The default value of that argument would be false, so those templates would evaluate to false for transient ranges by default. Then algorithms that can work with transient ranges would use
> ...
> if(isInputRange!(R, true))
>
> instead of
>
> if(isInputRange!R)
>
> The algorithms that don't support transient ranges would not need to be changed.  Wrapper ranges such as map's result would define transient property if the wrapped range defines it.

Just to clarify, by "transient ranges would have to define transient property" I meant just that this should be true for transient ranges: is(typeof(R.transient)). So transient could just be an enum. I didn't mean there would be a transient property that would return a transient version of the range.

On 11/23/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> Looks perfect now. Thanks guys.

I think maybe we should do another one of those logo contests (https://github.com/eegg/d-brand) to get a better looking logo for the wiki and dlang.org. I don't really like the current one (anyone else agrees?).

On Fri, Nov 23, 2012 at 05:19:34PM +0100, Andrej Mitrovic wrote:
> On 11/23/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> > Looks perfect now. Thanks guys.
> 
> I think maybe we should do another one of those logo contests (https://github.com/eegg/d-brand) to get a better looking logo for the wiki and dlang.org. I don't really like the current one (anyone else agrees?).

What about something based off my povray D-man model?

	https://github.com/quickfur/dmascot

:-)


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.

On Friday, 23 November 2012 at 17:24:30 UTC, H. S. Teoh wrote:
> What about something based off my povray D-man model?

D-man? Seriously? ;)

David

On Friday, November 23, 2012 16:34:51 jerro wrote:
> > What if we did it so that transient ranges would have to define
> > transient property (as was previously proposed), and
> > isInputRange, isForwardRange and others would get an additional
> > parameter allowTransient. The default value of that argument
> > would be false, so those templates would evaluate to false for
> > transient ranges by default. Then algorithms that can work with
> > transient ranges would use
> > ...
> > if(isInputRange!(R, true))
> > 
> > instead of
> > 
> > if(isInputRange!R)
> > 
> > The algorithms that don't support transient ranges would not need to be changed.  Wrapper ranges such as map's result would define transient property if the wrapped range defines it.
> 
> Just to clarify, by "transient ranges would have to define transient property" I meant just that this should be true for transient ranges: is(typeof(R.transient)). So transient could just be an enum. I didn't mean there would be a transient property that would return a transient version of the range.

It's not worth the extra complication. Every algorithm ever written then has to worry about it (though clearly many outside of Phobos wouldn't bother), and it's yet another thing that anyone writing a range-based function has to take into account. Any function which doesn't take it into account will then end up with wrong and bizarre behavior when it's given a range with a transient front. To be correct, most range-based functions would have to add template constraints to block ranges which mark themselves as transient.

We're talking about a rare use case here. I don't think that it even occurs to most people that it's possible to create a range with a transient front - certainly almost nothing in Phobos was written with that possibility in mind, and that's code written by the people who know ranges the best. Only two ranges in all of Phobos actually behave this way (ByLine and ByChunk), and people usually _complain_ about them working that way rather than being happy about it.

It's just not worth complicating ranges further by supporting ranges with a transient front. At most, supporting them under restricted circumstances might make sense (e.g. just input ranges), but not even that's worth it IMHO.

- Jonathan M Davis

On Friday, November 23, 2012 08:39:42 Jacob Carlborg wrote:
> The threading is not fine on some of your posts in Thunderbird for me.

Well, I have no idea what the problem is, and there's nothing that I can do about it. The inner workings of e-mail and newsgroup software are a mystery to me.

- Jonathan M Davis