www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - I'm back

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Hi all,


I'm back from a few long trips during which I got behind reading this 
group. I decided to mark everything as read and restart anew. If there 
are any topics that you believe have "extinguished" but need my 
attention, I'd be indebted if you mentioned them to me via private email 
or by replying to this.


Thanks,

Andrei
Nov 12 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 12-11-2012 20:42, Andrei Alexandrescu wrote:

 Hi all,


 I'm back from a few long trips during which I got behind reading this
 group. I decided to mark everything as read and restart anew. If there
 are any topics that you believe have "extinguished" but need my
 attention, I'd be indebted if you mentioned them to me via private email
 or by replying to this.


 Thanks,

 Andrei


The "Something needs to happen with shared, and soon." thread may be of 
interest to you, as well as any parts of "deprecate deprecated?" you may 
have missed.

Welcome back!

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Nov 12 2012
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 12/11/2012 20:42, Andrei Alexandrescu a écrit :

 Hi all,


 I'm back from a few long trips during which I got behind reading this
 group. I decided to mark everything as read and restart anew. If there
 are any topics that you believe have "extinguished" but need my
 attention, I'd be indebted if you mentioned them to me via private email
 or by replying to this.


 Thanks,

 Andrei


Topic on UDA obviously. Topic on range transience probably, as it is 
almost concluded.
Nov 12 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/12/12 11:45 AM, deadalnix wrote:

 Le 12/11/2012 20:42, Andrei Alexandrescu a écrit :

 Hi all,


 I'm back from a few long trips during which I got behind reading this
 group. I decided to mark everything as read and restart anew. If there
 are any topics that you believe have "extinguished" but need my
 attention, I'd be indebted if you mentioned them to me via private email
 or by replying to this.


 Thanks,

 Andrei


 Topic on UDA obviously.


Thanks! I did follow that and in brief my opinion is:

* The feature looks good

* The choice of syntax is mostly motivated by the question: do we want 
to integrate the existing " "-attributes with the user-defined ones? If 
so, the choice of the   syntax is a consequence.

* I saw very little focus for attribute testing, i.e. "does symbol xyz 
have attribute abc"? I don't think we should relegate that to a __traits.

* The execution of that feature (merging in the trunk along with a bunch 
of unrelated work) was extremely poor. We need to acquire a sense of 
urgency about fixing our process, lest this mom-and-pop-shop style of 
getting work done will end up alienating our user base.


 Topic on range transience probably, as it is
 almost concluded.


I'm leaning toward doing nothing about this.


Andrei
Nov 12 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-12 21:28, Andrei Alexandrescu wrote:


 * I saw very little focus for attribute testing, i.e. "does symbol xyz
 have attribute abc"? I don't think we should relegate that to a __traits.


The current implementation only has __traits(getAttributes), which will 
basically return a tuple of all the values attached to a symbol. On top 
of that we can build library functions for checking if an attribute 
exists for a symbol.


 * The execution of that feature (merging in the trunk along with a bunch
 of unrelated work) was extremely poor. We need to acquire a sense of
 urgency about fixing our process, lest this mom-and-pop-shop style of
 getting work done will end up alienating our user base.


Thank you for acknowledging this.

What's also being discussed in addition to your points are:

* Should built in types be allowed as attributes
* Should only types explicitly marked as an attribute (somehow) be 
allowed as attributes

-- 
/Jacob Carlborg
Nov 12 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/12/12 12:50 PM, Jacob Carlborg wrote:

 What's also being discussed in addition to your points are:

 * Should built in types be allowed as attributes
 * Should only types explicitly marked as an attribute (somehow) be
 allowed as attributes


Saw that too. I don't have an opinion about such, though the comparison 
with exception types is rather interesting.

Andrei
Nov 12 2012
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
On Mon, Nov 12, 2012 at 2:28 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 * The execution of that feature (merging in the trunk along with a bunch of
 unrelated work) was extremely poor. We need to acquire a sense of urgency
 about fixing our process, lest this mom-and-pop-shop style of getting work
 done will end up alienating our user base.

 Andrei


+1
Nov 12 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Nov 12, 2012 at 12:28:14PM -0800, Andrei Alexandrescu wrote:

 On 11/12/12 11:45 AM, deadalnix wrote:


[...]

Topic on range transience probably, as it is almost concluded.


 
 I'm leaning toward doing nothing about this.


[...]

Please don't. This is an issue that *needs* to be addressed, one way or
another. Even if it's just to declare that transient ranges are illegal,
and move on with no code changes. Leaving things the way they are
currently only introduces subtle bugs and indeterminate behaviour, and
is not acceptable.


T

-- 
"A one-question geek test. If you get the joke, you're a geek: Seen on a
California license plate on a VW Beetle: 'FEATURE'..." -- Joshua D. Wachs -
Natural Intelligence, Inc.
Nov 12 2012
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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).

- Jonathan M Davis
Nov 12 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.


Andrei
Nov 12 2012
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 13/11/2012 00:57, Andrei Alexandrescu a écrit :

 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.


I understand your point, so why not simply state that range MUST NOT be 
transient at all ? This is the solution that introduce nothing.
Nov 12 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, November 12, 2012 15:57:42 Andrei Alexandrescu wrote:

 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.


So basically, functions like std.array.array would require isInputRange!R && 
!hasTransientFront!R where hasTransientFront is false for forward ranges and 
is true for input ranges if front returns a mutable reference type or anything 
that might be a mutable reference type (since you can't always tell)?

We'd probably have to add some sort of property for it to check for so that a 
range could declare that it didn't have a transient front (e.g enum 
notTransient = true;) so that there would be fewer cases where a range's front 
would be determined to be transient when it actually wasn't, but that wouldn't 
be hard.

I think that that approach would be far more costly if it were not restricted 
to input ranges, but as so few ranges are not forward ranges and so many 
algorithms require forward ranges anyway, it wouldn't really complicate much, 
though it _is_ still another level of compliction to ranges.


 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.


It's not all bad in that in almost all cases, a free function peekFront could 
be used, making it so that almost no ranges would have to implement it. But I 
do tend to agree that it would be nice to not have to add more primitives. In 
fact, I'd actually like _reduce_ the number of primitives by gettting rid of 
moveFront and its brethren. They don't seem worth the extra complication to 
me. And even if the declarations for peekFront itself don't cost much, it 
_does_ mean that all ranges have to worry about whether they should use 
peekFront or front, which _does_ complicate things. So, I'm not completely 
enamoured with peekFront either. Then again, I quite like the approach of 
banning transient fronts altogether and insisting that anything which would 
have a transient front use opApply instead.

Certainly, of the two options that you give here, I think that I currently 
prefer the first.

- Jonathan M Davis
Nov 12 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 13/11/2012 01:57, Jonathan M Davis a écrit :

 On Monday, November 12, 2012 15:57:42 Andrei Alexandrescu wrote:

 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.


 So basically, functions like std.array.array would require isInputRange!R&&
 !hasTransientFront!R where hasTransientFront is false for forward ranges and
 is true for input ranges if front returns a mutable reference type or anything
 that might be a mutable reference type (since you can't always tell)?

 We'd probably have to add some sort of property for it to check for so that a
 range could declare that it didn't have a transient front (e.g enum
 notTransient = true;) so that there would be fewer cases where a range's front
 would be determined to be transient when it actually wasn't, but that wouldn't
 be hard.

 I think that that approach would be far more costly if it were not restricted
 to input ranges, but as so few ranges are not forward ranges and so many
 algorithms require forward ranges anyway, it wouldn't really complicate much,
 though it _is_ still another level of compliction to ranges.


 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.


 It's not all bad in that in almost all cases, a free function peekFront could
 be used, making it so that almost no ranges would have to implement it. But I
 do tend to agree that it would be nice to not have to add more primitives. In
 fact, I'd actually like _reduce_ the number of primitives by gettting rid of
 moveFront and its brethren. They don't seem worth the extra complication to
 me. And even if the declarations for peekFront itself don't cost much, it
 _does_ mean that all ranges have to worry about whether they should use
 peekFront or front, which _does_ complicate things. So, I'm not completely
 enamoured with peekFront either. Then again, I quite like the approach of
 banning transient fronts altogether and insisting that anything which would
 have a transient front use opApply instead.

 Certainly, of the two options that you give here, I think that I currently
 prefer the first.


I never used moveFront and alike.
Nov 12 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/12/12 5:40 PM, deadalnix wrote:

 I never used moveFront and alike.


They're used by algorithms that you might be using.

Andrei
Nov 12 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 13/11/2012 03:01, Andrei Alexandrescu a écrit :

 On 11/12/12 5:40 PM, deadalnix wrote:

 I never used moveFront and alike.


 They're used by algorithms that you might be using.

 Andrei


I'm not saying they are useless, or that I never used them under the hood.
Nov 12 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/12/12 6:29 PM, deadalnix wrote:

 Le 13/11/2012 03:01, Andrei Alexandrescu a écrit :

 On 11/12/12 5:40 PM, deadalnix wrote:

 I never used moveFront and alike.


 They're used by algorithms that you might be using.

 Andrei


 I'm not saying they are useless, or that I never used them under the hood.


Then what is it that you are saying? Honest question.

Andrei
Nov 12 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 13/11/2012 03:59, Andrei Alexandrescu a écrit :

 On 11/12/12 6:29 PM, deadalnix wrote:

 Le 13/11/2012 03:01, Andrei Alexandrescu a écrit :

 On 11/12/12 5:40 PM, deadalnix wrote:

 I never used moveFront and alike.


 They're used by algorithms that you might be using.

 Andrei


 I'm not saying they are useless, or that I never used them under the
 hood.


 Then what is it that you are saying? Honest question.

 Andrei


That mastering every range feature isn't required to work effectively 
with ranges.
Nov 13 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Nov 13 2012
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Nov 13 2012
parent reply deadalnix <deadalnix gmail.com> writes:
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.
Nov 13 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Nov 14 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 14 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/14/2012 06:43 PM, Andrei Alexandrescu wrote:

 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


That is a very imprecise approximation. I think it does not cover any 
ground: The day eg. 'array' will require this kind of non-transient 
element range is the day where I will write my own.
Nov 14 2012
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, November 14, 2012 20:18:26 Timon Gehr wrote:

 That is a very imprecise approximation. I think it does not cover any
 ground: The day eg. 'array' will require this kind of non-transient
 element range is the day where I will write my own.


std.array.array _cannot_ work with a transient front. It's stuffing the
elements 
into an array as iterates over them, and if each of those elements keeps 
changing on it, then it won't end up with the right result. I don't believe 
that there is any way around this, not without somehow duping front when 
necessary, but we have no way to do that generically, and even if we did, 
there's no way for std.array.array. to know whether front is actually 
transient or not, just whether it _might_ be - not without the range having a 
property of some kind which told you that its front was transient. So, 
automatically duping would just introduce inefficiencies, because it couldn't 
know when it actually needed to do it or not. Something like

auto arr = array(map!"a.dup"(file.byLine()));

would work, but as long as ByLine reuses its buffer, it will _never_ work with 
std.array.array. std.array.array is _precisely_ the sort of range that would 
require the restrictions that Andrei is talking about. We either need
restrictions
like that, to complicate ranges in general with extra traits and/or functions
which
support transience, or to make transient fronts outright invalid ranges.

- Jonathan M Davis
Nov 14 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/14/2012 08:32 PM, Jonathan M Davis wrote:

 On Wednesday, November 14, 2012 20:18:26 Timon Gehr wrote:

 That is a very imprecise approximation. I think it does not cover any
 ground: The day eg. 'array' will require this kind of non-transient
 element range is the day where I will write my own.


 std.array.array _cannot_ work with a transient front. ...


It can work if 'transient' is over-approximated like suggested in the 
parent post.
Nov 15 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, November 15, 2012 22:11:33 Timon Gehr wrote:

 On 11/14/2012 08:32 PM, Jonathan M Davis wrote:

 On Wednesday, November 14, 2012 20:18:26 Timon Gehr wrote:

 That is a very imprecise approximation. I think it does not cover any
 ground: The day eg. 'array' will require this kind of non-transient
 element range is the day where I will write my own.


 
 std.array.array _cannot_ work with a transient front. ...


 
 It can work if 'transient' is over-approximated like suggested in the
 parent post.


How so? std.array.array _needs_ copies when it creates its array. If front is 
transient, it will end up with all elements being the same. So, either 
transient fronts need to be illegal, or std.array.array needs to be able to 
put a check for them in its template constraint to prevent them from being 
used with it. In either case, no range with a transient front would work with 
std.array.array.

All that inferring transience from the type of front will do is make it so 
that std.array.array can prevent ranges with a transient front from compiling 
with it, and it would be forced to reject a bunch of ranges which were _not_ 
transient, because any mutable reference type would have to be treated as 
transient even if it wasn't. So, that doesn't make std.array.array work with 
ByLine or its ilk at all.

- Jonathan M Davis
Nov 15 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/16/2012 01:58 AM, Jonathan M Davis wrote:

 On Thursday, November 15, 2012 22:11:33 Timon Gehr wrote:

 On 11/14/2012 08:32 PM, Jonathan M Davis wrote:

 On Wednesday, November 14, 2012 20:18:26 Timon Gehr wrote:

 That is a very imprecise approximation. I think it does not cover any
 ground: The day eg. 'array' will require this kind of non-transient
 element range is the day where I will write my own.


 std.array.array _cannot_ work with a transient front. ...


 It can work if 'transient' is over-approximated like suggested in the
 parent post.


 How so? ...


The suggestion is to ban all potentially mutable indirections from 
'non-transient' ranges. (this redefines what 'transient' means.) It 
cannot be derived that popFront will invalidate stuff just from the fact 
that the type system does not explicitly exclude that any code ever 
modifies it.
Nov 16 2012
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, November 16, 2012 19:06:05 Timon Gehr wrote:

 The suggestion is to ban all potentially mutable indirections from
 'non-transient' ranges. (this redefines what 'transient' means.) It
 cannot be derived that popFront will invalidate stuff just from the fact
 that the type system does not explicitly exclude that any code ever
 modifies it.


The idea behind the suggestion is to attempt to determine transience based on 
the time and assume that it's non-transient if it's not definitively non-
transient. It's not redefining the term transience. It's just that it cannot 
definitively determine transience based on the type alone. By I guess that I
could see how you could think of that as redefining transience.

Regardless, std.array.array _cannot_ work on ranges with transient fronts. So, 
we have a few options:

1. Make transient fronts illegal, then std.array.array and its ilk never have 
to worry about it.

2. Make it so that all transient ranges must mark themselves as transient.

3. Introduce primitives like peekFront to enable ranges with transient fronts
to work in general while allowing code to assume that front is non-transient.

3. Attempt to infer transience from the type of front.


feasible, but it's going to get a lot of false positives, meaning that 
functions like std.array.array won't work with ranges that they should be

by transient fronts, but it means that ranges such as ByLine and ByChunk are 
illegal (as they currently stand anyway).

Personally, I favor making it so that ByLine and ByChunk overload opApply and 
reuse their buffers with it and then make their fronts non-transient. It pretty 
much avoids this whole issue while allowing the extra efficiency provided by a 
transient front in pretty much the only common use case that we have for such 
a range.

- Jonathan M Davis
Nov 16 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 16, 2012 at 10:32:22PM +0100, Jonathan M Davis wrote:
[...]

 Regardless, std.array.array _cannot_ work on ranges with transient
 fronts. So, we have a few options:
 
 1. Make transient fronts illegal, then std.array.array and its ilk
 never have to worry about it.
 
 2. Make it so that all transient ranges must mark themselves as
 transient.
 
 3. Introduce primitives like peekFront to enable ranges with transient
 fronts to work in general while allowing code to assume that front is
 non-transient.
 
 3. Attempt to infer transience from the type of front.
 

 feasible, but it's going to get a lot of false positives, meaning that 
 functions like std.array.array won't work with ranges that they should be

 by transient fronts, but it means that ranges such as ByLine and ByChunk are 
 illegal (as they currently stand anyway).


Regardless of how we solve it, ByLine and ByChunk need to be changed





 Personally, I favor making it so that ByLine and ByChunk overload
 opApply and reuse their buffers with it and then make their fronts
 non-transient. It pretty much avoids this whole issue while allowing
 the extra efficiency provided by a transient front in pretty much the
 only common use case that we have for such a range.


[...]


range functions are safe/unsafe to use with it. This option requires no
code changes, only documentation changes. It *is* mere coding by
convention, which is generally not desirable, but it does seem to be the
simplest way to allow people to use transient ranges if they know what
they're doing.


non-transient by default, and provide new transient versions of them for
those people who need to squeeze out every last bit of performance (who
also should know what they're doing so they can't complain if things
break). This way, things are safe by default, yet people can consciously
choose to work with transient ranges.

This may be another approach to balance the need for flexibility and yet
keep things on the safe side by default. I don't like the prospect of
having to duplicate parts of std.algorithm just because I have some code
that produces transient ranges -- I *know* I'm never going to need to
use algorithms on them that can't handle transience anyway. It's Not
Nice to be forced to duplicate code just because an arbitrary decision
was made to ban transience, or just because some leaky type inference
decided my range was transient when it's not, etc..


T

-- 
You have to expect the unexpected. -- RL
Nov 16 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/14/12 11:18 AM, Timon Gehr wrote:

 On 11/14/2012 06:43 PM, Andrei Alexandrescu wrote:

 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


 That is a very imprecise approximation. I think it does not cover any
 ground: The day eg. 'array' will require this kind of non-transient
 element range is the day where I will write my own.


What would be an example where array would have trouble with using this 
definition?

Andrei
Nov 14 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/14/2012 11:18 PM, Andrei Alexandrescu wrote:

 On 11/14/12 11:18 AM, Timon Gehr wrote:

 On 11/14/2012 06:43 PM, Andrei Alexandrescu wrote:

 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


 That is a very imprecise approximation. I think it does not cover any
 ground: The day eg. 'array' will require this kind of non-transient
 element range is the day where I will write my own.


 What would be an example where array would have trouble with using this
 definition?

 Andrei


import std.array, std.range, std.algorithm, std.stdio, std.conv;

class C{
     int	x;
     this(int x){ this.x = x; }
     string toString(){ return "C("~to!string(x)~")"; }
}

void main(){
     auto a = iota(0,100).map!(a=>new C(a)).array;
     writeln(a);
}
Nov 15 2012
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:k80l8p$397$1 digitalmars.com...

 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


Is it just me, or would this still refuse: 
array(map!"a.dup"(stdin.byLine())) ?
Nov 14 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/14/12 5:30 PM, Daniel Murphy wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:k80l8p$397$1 digitalmars.com...

 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


 Is it just me, or would this still refuse:
 array(map!"a.dup"(stdin.byLine())) ?


It would accept mapping to!string.

Andrei
Nov 14 2012
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:k81k6s$1qm7$1 digitalmars.com...

 On 11/14/12 5:30 PM, Daniel Murphy wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:k80l8p$397$1 digitalmars.com...

 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


 Is it just me, or would this still refuse:
 array(map!"a.dup"(stdin.byLine())) ?


 It would accept mapping to!string.

 Andrei


Is that really good enough?  Keeping ranges simple is important, but so is 
making the obvious solution 'just work'.
Nov 15 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, November 15, 2012 22:07:22 Daniel Murphy wrote:

 Is that really good enough?  Keeping ranges simple is important, but so is
 making the obvious solution 'just work'.


std.array.array will never work with ranges with a transient front unless it 
somehow knew when it was and wasn't appropriate to dup, which it's not going 
to know purely by looking at the type of front. The creator of the range would 
have to tell them somehow. And even then, it wouldn't work beyond the built-in 
types, because there's no generic way to dup stuff.

So, either std.array.array will not work directly with byLine or byChunk, or 
byLine and byChunk need to not have transient fronts. If them not working with 
std.array.array is too un-user-friendly, then they need to be changed so that 
they don't have transient fronts, and transient fronts should just be 
considered invalid ranges (though there's no way to actually test for them, so 
anyone who wrote them would still be able to try and use them - they just 
wouldn't work).

- Jonathan M Davis
Nov 15 2012
parent reply "jerro" <a a.com> writes:
 std.array.array will never work with ranges with a transient 
 front unless it
 somehow knew when it was and wasn't appropriate to dup, which 
 it's not going
 to know purely by looking at the type of front. The creator of 
 the range would
 have to tell them somehow. And even then, it wouldn't work 
 beyond the built-in
 types, because there's no generic way to dup stuff.


Daniel was actually talking about std.byLine.map!"a.dup", which 
is not a transient range, but would be considered transient if we 
did what Andrei suggests.
Nov 15 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, November 15, 2012 13:17:12 jerro wrote:

 std.array.array will never work with ranges with a transient
 front unless it
 somehow knew when it was and wasn't appropriate to dup, which
 it's not going
 to know purely by looking at the type of front. The creator of
 the range would
 have to tell them somehow. And even then, it wouldn't work
 beyond the built-in
 types, because there's no generic way to dup stuff.


 
 Daniel was actually talking about std.byLine.map!"a.dup", which
 is not a transient range, but would be considered transient if we
 did what Andrei suggests.


Well, there's no way around that as far as I can see. Even if all ranges had 
to be explicitly marked as transient or not, map would be in a bind here, 
because it knows nothing about what the function it was given is doing, so it 
has no way of knowing how it affects transience. At minimum, it would be forced 
to mark itself as transient if the original range was (even if the function 
used idup), or it would _always_ be forced to mark it as transient (I'm not 
sure which). The only way out would be if there were a way to tell map 
explicitly to mark the resultant range as having a non-transient front.

By using type deduction like Andrei is suggesting, then we can at least deduce 
that map!"a.idup" has a non-transient front, but the only way that we'd know 
that map!"a.dup" was non-transient was if map were told somehow, and it defined 
an enum that the hasTransientFront trait could examine (i.e. we're back in the 
boat we'd be in if all ranges had to declare whether they were transient or 
not). So, as long as we can have transient fronts, map!"a.dup" is screwed, 
which may or may not be a problem. It's arguably a lot like how we keep having 
to explain why functions don't work with narrow strings because of how narrow 
strings aren't random-access, don't have length, etc. And that's definitely 
annoying, but we can't really fix it.

It's looking like this comes down to either banning ranges with transient 
fronts entirely (and changing how ByLine and ByChunk work), or we're going to 
have to deal with quirks like array(map!"a.dup"(file.byLine())) not working 
whereas array(map!"a.idup"(file.byLine())) does work.

- Jonathan M Davis
Nov 15 2012
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 15 November 2012 at 12:57:24 UTC, Jonathan M Davis 
wrote:

 It's looking like this comes down to either banning ranges with 
 transient
 fronts entirely (and changing how ByLine and ByChunk work), or 
 we're going to
 have to deal with quirks like array(map!"a.dup"(file.byLine())) 
 not working
 whereas array(map!"a.idup"(file.byLine())) does work.

 - Jonathan M Davis


I still say this could be "simply" solved the same way we solved 
the "size_t" indexing problem: Only ranges that have 
non-transient elements are guaranteed supported by phobos 
algorithms/functions.

Everything else: Use at your own risk.
Nov 15 2012
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11/15/2012 5:20 PM, monarch_dodra пишет:

 On Thursday, 15 November 2012 at 12:57:24 UTC, Jonathan M Davis wrote:

 It's looking like this comes down to either banning ranges with transient
 fronts entirely (and changing how ByLine and ByChunk work), or we're
 going to
 have to deal with quirks like array(map!"a.dup"(file.byLine())) not
 working
 whereas array(map!"a.idup"(file.byLine())) does work.

 - Jonathan M Davis


 I still say this could be "simply" solved the same way we solved the
 "size_t" indexing problem: Only ranges that have non-transient elements
 are guaranteed supported by phobos algorithms/functions.

 Everything else: Use at your own risk.


Yeah! Let's introduce undefined behavior into the standard library!

Wrong type of index at least breaks at compile time.

-- 
Dmitry Olshansky
Nov 15 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 15, 2012 at 04:38:04AM -0800, Jonathan M Davis wrote:

 On Thursday, November 15, 2012 13:17:12 jerro wrote:

 std.array.array will never work with ranges with a transient front
 unless it somehow knew when it was and wasn't appropriate to dup,
 which it's not going to know purely by looking at the type of
 front. The creator of the range would have to tell them somehow.
 And even then, it wouldn't work beyond the built-in types, because
 there's no generic way to dup stuff.


 
 Daniel was actually talking about std.byLine.map!"a.dup", which is
 not a transient range, but would be considered transient if we did
 what Andrei suggests.


 
 Well, there's no way around that as far as I can see. Even if all
 ranges had to be explicitly marked as transient or not, map would be
 in a bind here, because it knows nothing about what the function it
 was given is doing, so it has no way of knowing how it affects
 transience. At minimum, it would be forced to mark itself as transient
 if the original range was (even if the function used idup), or it
 would _always_ be forced to mark it as transient (I'm not sure which).
 The only way out would be if there were a way to tell map explicitly
 to mark the resultant range as having a non-transient front.


OK, you've convinced me. The only way to take care of all these corner
cases is to make transient ranges illegal, period. Just the fact that
map!a and map!"a.dup" may be transient or not, shows that this isn't
going to be solved by any simple means. None of our proposals so far
even comes close to handling this one correctly.



 By using type deduction like Andrei is suggesting, then we can at
 least deduce that map!"a.idup" has a non-transient front,


Well, this at least gives us some semblance of workability for this
particular case, though it is very leaky around the edges.



 but the only way that we'd know that map!"a.dup" was non-transient was
 if map were told somehow, and it defined an enum that the
 hasTransientFront trait could examine (i.e. we're back in the boat
 we'd be in if all ranges had to declare whether they were transient or
 not). So, as long as we can have transient fronts, map!"a.dup" is
 screwed, which may or may not be a problem.


This is not good, because it relies on the user to declare whether or
not something is transient when they aren't even the implementor of the
delegate passed to map. It's one thing to require users to declare their
ranges transient or not, but it's quite another thing to require them to
tell map whether or not a.dup is transient (where a.dup can be
substituted with an arbitrarily complex delegate which may not even be
implemented by the user).


[...]

 It's looking like this comes down to either banning ranges with
 transient fronts entirely (and changing how ByLine and ByChunk work),


This is looking like the more attractive option right now.



 or we're going to have to deal with quirks like
 array(map!"a.dup"(file.byLine())) not working whereas
 array(map!"a.idup"(file.byLine())) does work.


[...]

This is ugly. I don't like it. But at least, it does give you a compile
time error when array requires a non-transient range, but gets a
transient one. Better than subtle runtime breakage, for sure.


T

-- 
It said to install Windows 2000 or better, so I installed Linux instead.
Nov 15 2012
prev sibling next sibling parent eskimo <jfanatiker gmx.at> writes:
On Wed, 2012-11-14 at 18:31 -0800, Andrei Alexandrescu wrote:

 array(map!"a.dup"(stdin.byLine()))




As it seems there is a good way of handling ranges with transient front
for algorithms that need a persistent front?

Why not simply document any transient range to be transient (should be
anyway) and add the little hint to map. Also note that some algorithms
might not work as expected with transient fronts. In addition, at least
the algorithms in phobos should state in their documentation whether
they rely on non transient front or not.

To me it seems that ranges and algorithms already offer a solution to
the problem.

The other way round it would of course be better (safe behaviour the
default, fast the option) but as a matter of fact there is no real
unsafe behaviour, it just might be unexpected if you don't know what you
are doing.

On the other hand if an algorithm depends unnecessarily on non transient
fronts it should be fixed. If there are many algorithms which can be
more efficient with the dependency on non transient front, we could
simply provide a second module, called std.transalgorithm (or something)
offering dedicated algorithms for transient fronts. (So people don't
have to role their own)

I think this is a very clean and straight forward solution. If you want
something that simply works you just use map!"a.dup" ( or whatever you
need to copy your elements) and don't care. If you want performance then
you would have to check what algorithms to use and have a look at
std.transalgorithm.

My apologies if someone else already suggested something like this, I
haven't read all the threads about this topic entirely.
Nov 15 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 15, 2012 at 02:14:15PM +0100, eskimo wrote:

 On Wed, 2012-11-14 at 18:31 -0800, Andrei Alexandrescu wrote:

 array(map!"a.dup"(stdin.byLine()))




 
 As it seems there is a good way of handling ranges with transient
 front for algorithms that need a persistent front?
 
 Why not simply document any transient range to be transient (should be
 anyway) and add the little hint to map. Also note that some algorithms
 might not work as expected with transient fronts. In addition, at
 least the algorithms in phobos should state in their documentation
 whether they rely on non transient front or not.


This is better than nothing, of course, but still, relying purely on
documentation is not desirable if we can do better. Though at this
point, it looks like we can't, so this may be the only option left.


[...]

 On the other hand if an algorithm depends unnecessarily on non
 transient fronts it should be fixed.


Definitely! I have a fix for std.algorithm.joiner already, and there are
a few others that can be fixed without too much effort (I hope).



 If there are many algorithms which can be more efficient with the
 dependency on non transient front, we could simply provide a second
 module, called std.transalgorithm (or something) offering dedicated
 algorithms for transient fronts. (So people don't have to role their
 own)


AFAIK, none of the algorithms will be more or less efficient depending
on whether non-transience can be assumed. It's just a matter of
reordering operations (don't call .popFront until .front is used); a bit
trickier to write the code, but doesn't change the asymptotic
complexity. The algorithms that *are* affected are those that can't work
with transient ranges anyway, so it doesn't really matter.



 I think this is a very clean and straight forward solution. If you
 want something that simply works you just use map!"a.dup" ( or
 whatever you need to copy your elements) and don't care. If you want
 performance then you would have to check what algorithms to use and
 have a look at std.transalgorithm.


[...]

I don't like duplicating a whole bunch of algorithms in transalgorithm.

However, there *may* be something to the idea of splitting up
std.algorithm so that those algorithms that aren't sensitive to
transience are in one module, and the fragile algorithms in another
module. Then one module can be clearly marked as usable with *all*
ranges, and the other as usable only with non-transient ranges.


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you
wish you hadn't.
Nov 15 2012
prev sibling parent eskimo <jfanatiker gmx.at> writes:
On Thu, 2012-11-15 at 10:56 -0800, H. S. Teoh wrote:

 I don't like duplicating a whole bunch of algorithms in
 transalgorithm.


If its true what you say, that usually there is no difference in
efficiency, than there is no need for any duplication. But it is
certainly better to offer an standard implementation (if needed) than
having every user do the duplication.

I know that coding by convention is discouraged, but some conventions
work pretty well. I would suggest for any new ranges that provide a
transient front to have them called something like byLineTransient,
byChunkTransient(). So it is obvious from reading the code what you deal
with. (I am not suggesting renaming the already existing methods, I just
picked the first examples I could think of)

I personally would be very happy, if all algorithms who can accept
transient fronts do and that mostly algorithms for which it is obvious
that they can not support them, don't support them. In conjunction with
documentation & maybe a naming convention, I think this is already
pretty good and at least in my very humble opinion, good enough.
Nov 15 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, November 14, 2012 07:29:34 H. S. Teoh wrote:

 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.


Most (all?) abstractions are leaky on some level. But the real problem is simply
that to make it so that you can do absolutely everything with complete control,
it becomes too complicated to be useable in the normal case. It's pretty much 
inevitable that you have to cut off some use cases or it's going to be too 
complicated. The trick is figuring out how to make it work with as many use 
cases as reasonably possible and still be quite useable in the average case, 
and that's not necessarily an easy balance to strike.

- Jonathan M Davis
Nov 14 2012
prev sibling next sibling parent reply "Rob T" <rob ucora.com> writes:
On Monday, 12 November 2012 at 19:42:14 UTC, Andrei Alexandrescu 
wrote:

 Hi all,


 I'm back from a few long trips during which I got behind 
 reading this group. I decided to mark everything as read and 
 restart anew. If there are any topics that you believe have 
 "extinguished" but need my attention, I'd be indebted if you 
 mentioned them to me via private email or by replying to this.


 Thanks,

 Andrei


Welcome back!

Long discussion on const ref,
http://forum.dlang.org/thread/yhnbcocwxnbutylfeoxi forum.dlang.org

here's the summary thread
http://forum.dlang.org/thread/zteryxwxyngvyqvukqkm forum.dlang.org

--rt
Nov 12 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, November 12, 2012 21:24:06 Rob T wrote:

 Long discussion on const ref,
 http://forum.dlang.org/thread/yhnbcocwxnbutylfeoxi forum.dlang.org
 
 here's the summary thread
 http://forum.dlang.org/thread/zteryxwxyngvyqvukqkm forum.dlang.org


Yeah. You have some very strong views and that issue which almost no one else 
actually understands, so a lot of people keep pushing for D's const ref to act 
like C++'s const&.

- Jonathan M Davis
Nov 12 2012
parent "martin" <kinke libero.it> writes:
On Monday, 12 November 2012 at 20:54:39 UTC, Jonathan M Davis 
wrote:

 On Monday, November 12, 2012 21:24:06 Rob T wrote:

 Long discussion on const ref,
 http://forum.dlang.org/thread/yhnbcocwxnbutylfeoxi forum.dlang.org
 
 here's the summary thread
 http://forum.dlang.org/thread/zteryxwxyngvyqvukqkm forum.dlang.org


 Yeah. You have some very strong views and that issue which 
 almost no one else actually understands, so a lot of people keep
 pushing for D's const ref to act like C++'s const&.


Yes, I'm one of these people (and a persistent one I might add 
:D) as this issue really bothers me. I'm convinced we can settle 
it, so I'd be glad if you took the time to look at the 2nd linked 
thread, Andrei.
Nov 12 2012
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

Welcome back.


 If there are any topics that you believe have "extinguished" 
 but need my attention, I'd be indebted if you mentioned them to 
 me via private email or by replying to this.


There are some threads I have opened, or where I have written 
some posts in:

In this thread
http://forum.dlang.org/thread/50A0EEA4.7010706 webdrake.net

Joseph Rushton Wakeling suggests code like this to compile:

struct Foo(_T) {
     alias _T T;
}
void bar(FooT)(FooT foo, FooT.T x) {
}
void main() {
     Foo!int foo;
     bar(foo, 1); // line 8
}



Here I have suggested to add a lenses-like function to Phobos:
http://forum.dlang.org/thread/dqvaohhgthbsygoctwmh forum.dlang.org


Here I have suggested a little refinement for D purity:
http://forum.dlang.org/thread/hqtgzpnfbpbvdiriogin forum.dlang.org


Here I have underlined a little design problem with opCast(bool):
http://forum.dlang.org/thread/eicpsjarvxvahknluqwu forum.dlang.org


In the middle of this long thread I have exchanged several 
messages with Walter:
http://forum.dlang.org/thread/k7afq6$2832$1 digitalmars.com?page=10

where I have suggested to disallow:

void main() {
     auto data = [0, 1, 2, 3];
     foreach (x; data)
         x++;
}

And replace it with this:

void main() {
     auto data = [0, 1, 2, 3];
     foreach ( copy x; data)
         writeln(++x);
}

You will find many more details in the thread, especially in this 
post of mine where I have tried to explain the situation as much 
clearly as possible:
http://forum.dlang.org/thread/k7afq6$2832$1 digitalmars.com?page=12#post-hqdihcnzzgnlfvznhqbc:40forum.dlang.org

Bye,
bearophile
Nov 12 2012
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 11/12/2012 11:09 PM, bearophile wrote:

 In this thread
 http://forum.dlang.org/thread/50A0EEA4.7010706 webdrake.net

 Joseph Rushton Wakeling suggests code like this to compile:

 struct Foo(_T) {
      alias _T T;
 }
 void bar(FooT)(FooT foo, FooT.T x) {
 }
 void main() {
      Foo!int foo;
      bar(foo, 1); // line 8
 }


I'm not actually suggesting that the particular syntax above necessarily ought 
to work, but I'd like an easy way to ensure that one template parameter can be 
determined from another.
Nov 13 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Joseph Rushton Wakeling:


 I'm not actually suggesting that the particular syntax above 
 necessarily ought to work, but I'd like an easy way to ensure 
 that one template parameter can be determined from another.


Right. But I think that syntax is the most natural one for that.

And Hara now thinks it's an idea worth considering:
http://d.puremagic.com/issues/show_bug.cgi?id=9004#c3

Bye,
bearophile
Nov 13 2012
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 11/13/2012 03:01 PM, bearophile wrote:

 Right. But I think that syntax is the most natural one for that.


Agree. :-)


 And Hara now thinks it's an idea worth considering:
 http://d.puremagic.com/issues/show_bug.cgi?id=9004#c3


Excellent!  Thank you so much for bringing it to notice like this.
Nov 13 2012
prev sibling next sibling parent reply Thomas Koch <thomas koch.ro> writes:
Buna Andrei,

I initiated a discussion[1] about the state of the D wiki[2].

[1] http://forum.dlang.org/thread/k6jak1$quh$1 digitalmars.com
[2] http://www.prowiki.org/wiki4d

There were three people agreeing that the current wiki engine might be a 
cause for the bad state of the content. Nobody wants to use this engine.

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

[3] https://github.com/github/gollum
[4] https://github.com/D-Programming-Language

Now we need a decision on this issue and probably somebody to turn on the 
github wiki.

Multumesc, Thomas Koch
Nov 13 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/13/12 3:23 AM, Thomas Koch wrote:

 Buna Andrei,

 I initiated a discussion[1] about the state of the D wiki[2].

 [1] http://forum.dlang.org/thread/k6jak1$quh$1 digitalmars.com
 [2] http://www.prowiki.org/wiki4d

 There were three people agreeing that the current wiki engine might be a
 cause for the bad state of the content. Nobody wants to use this engine.

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

 [3] https://github.com/github/gollum
 [4] https://github.com/D-Programming-Language

 Now we need a decision on this issue and probably somebody to turn on the
 github wiki.

 Multumesc, Thomas Koch


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.

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?


Andrei
Nov 13 2012
next sibling parent reply Thomas Koch <thomas koch.ro> writes:
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
Nov 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 13 2012
parent "David Nadlinger" <see klickverbot.at> writes:
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
Nov 13 2012
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
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
Nov 13 2012
next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
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.
Nov 13 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 13 2012
next sibling parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
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.
Nov 13 2012
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tuesday, 13 November 2012 at 21:45:50 UTC, Brad Roberts wrote:

 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.


I host a number of MediaWikis and have some experience running 
and maintaining them. The biggest one is http://worms2d.info/. I 
consider spam a solved problem, on that wiki at least.

I'd love to look into writing a wiki syntax converter to move all 
the content from ProWiki to a new MediaWiki instance (and a bot 
to replace the ProWiki pages with links to the new pages), but 
unfortunately I don't have the time to spare for such an 
endeavour at the moment. But if the D community is interested in 
just a MediaWiki setup on the same server as the D forum (with me 
taking care of maintenance), I could look into that.
Nov 14 2012
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/15/12, Vladimir Panteleev <vladimir thecybershadow.net> wrote:

 I'd love to look into writing a wiki syntax converter to move all
 the content from ProWiki to a new MediaWiki instance


Well even if we don't have that we will have an opportunity to review
and update outdated articles.
Nov 15 2012
parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Thursday, 15 November 2012 at 08:28:09 UTC, Andrej Mitrovic 
wrote:

 On 11/15/12, Vladimir Panteleev <vladimir thecybershadow.net> 
 wrote:

 I'd love to look into writing a wiki syntax converter to move 
 all
 the content from ProWiki to a new MediaWiki instance


 Well even if we don't have that we will have an opportunity to 
 review
 and update outdated articles.


We really should do that and remove everything not proven to be 
uptodate.
Nov 15 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/14/2012 11:33 PM, Vladimir Panteleev wrote:

 But if the D community is interested in
 just a MediaWiki setup on the same server as the D forum (with me taking care
of
 maintenance), I could look into that.


I don't know how much everyone else is interested in that, but I am.
Nov 15 2012
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/16/12, Walter Bright <newshound2 digitalmars.com> wrote:

 On 11/14/2012 11:33 PM, Vladimir Panteleev wrote:

 But if the D community is interested in
 just a MediaWiki setup on the same server as the D forum (with me taking
 care of
 maintenance), I could look into that.


 I don't know how much everyone else is interested in that, but I am.


We should give it a try and see if it works out.
Nov 21 2012
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 16 November 2012 at 03:01:46 UTC, Walter Bright wrote:

 On 11/14/2012 11:33 PM, Vladimir Panteleev wrote:

 But if the D community is interested in
 just a MediaWiki setup on the same server as the D forum (with 
 me taking care of
 maintenance), I could look into that.


 I don't know how much everyone else is interested in that, but 
 I am.


Oops, saw your reply only today.

Here's something to start with:

http://dwiki.kimsufi.thecybershadow.net/

Spam protection is currently minimal, but I'm subscribed to the 
edit feed and will apply more as needed (so as not to hamper 
initial contributors who will be moving most of the data).

If you point wiki.dlang.org to it, it should become accessible 
from that address as well.
Nov 21 2012
next sibling parent reply "r_m_r" <r_m_r mailinator.com> writes:
On Wednesday, 21 November 2012 at 22:22:02 UTC, Vladimir
Panteleev wrote:

 Here's something to start with:

 http://dwiki.kimsufi.thecybershadow.net/


Thank you. :)

MediaWiki seems pretty easy to use. I just modified the Main_Page
and added the WhySwitch page (content copied from the old wiki:
http://www.prowiki.org/wiki4d/wiki.cgi).

Regards,
RMR
Nov 21 2012
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/22/12, r_m_r <r_m_r mailinator.com> wrote:

 I just modified the Main_Page
 and added the WhySwitch page (content copied from the old wiki:
 http://www.prowiki.org/wiki4d/wiki.cgi).


Is it possible to increase the default font size for D syntax highlighting?

This is what it looks like, it's almost unreadable: http://i.imgur.com/B39nC.png
I would prefer this, which is 10pt in a standard code editor:
http://i.imgur.com/izGsJ.png
Nov 22 2012
next sibling parent reply "r_m_r" <r_m_r mailinator.com> writes:
On Thursday, 22 November 2012 at 10:41:33 UTC, Andrej Mitrovic 
wrote:

 Is it possible to increase the default font size for D syntax 
 highlighting?


I don't think I can change the font size directly.
The CSS style for that <pre> tag is generated by the 
SyntaxHighlight GeSHi extension as shown below (copied from the 
page source):

/**
  * GeSHi Dynamically Generated Stylesheet
  * --------------------------------------
  * Dynamically generated stylesheet for d
  * CSS class: source-d, CSS id:
  * GeSHi (C) 2004 - 2007 Nigel McNie, 2007 - 2008 Benny Baumann
  * (http://qbnz.com/highlighter/ and http://geshi.org/)
  * --------------------------------------
  */
.d.source-d .de1, .d.source-d .de2 {font: normal normal 1em/1.2em 
monospace; margin:0; padding:0; background:none; 
vertical-align:top;}
.d.source-d  {font-family:monospace;}

BTW The code displays fine on my browser. Maybe you can try 
changing the Minimum font size in your Browser preferences? I 
have mine set to a minimum of 12pt. Also, you can choose a 
different theme in the wiki preferences page: 
http://dwiki.kimsufi.thecybershadow.net/Special:Preferences#mw-htmlform-skin

Hope that helps.

Regards,
r_m_r
Nov 22 2012
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/22/12, r_m_r <r_m_r mailinator.com> wrote:

 I don't think I can change the font size directly.


Sorry, I should have quoted Vladimir, not you.

On 11/22/12, r_m_r <r_m_r mailinator.com> wrote:

 BTW The code displays fine on my browser.


Which browser? It displays the same for me on Firefox and Chrome.

On 11/22/12, r_m_r <r_m_r mailinator.com> wrote:

 Maybe you can try
 changing the Minimum font size in your Browser preferences?


That doesn't help until I increase it to a huge value which ends up
changing the way all the text on the page looks (including other
websites).


 Also, you can choose a
 different theme in the wiki preferences page:
 http://dwiki.kimsufi.thecybershadow.net/Special:Preferences#mw-htmlform-skin


I don't want to change the theme, I just want the code font size set
to a readable default for my OS (which is Courier New 10pt on win32).
Nov 22 2012
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 22 November 2012 at 10:41:33 UTC, Andrej Mitrovic 
wrote:

 On 11/22/12, r_m_r <r_m_r mailinator.com> wrote:

 I just modified the Main_Page
 and added the WhySwitch page (content copied from the old wiki:
 http://www.prowiki.org/wiki4d/wiki.cgi).


 Is it possible to increase the default font size for D syntax 
 highlighting?

 This is what it looks like, it's almost unreadable: 
 http://i.imgur.com/B39nC.png
 I would prefer this, which is 10pt in a standard code editor:
 http://i.imgur.com/izGsJ.png


That would be because your browser is using Courier New for the 
monospace CSS font family, which is notable for being smaller 
than other fonts at the same font sizes.

I've overridden the definition to use the same CSS as the forum 
(basically, try "Consolas" before falling back to "monospace"). 
Does it look better now?

If anyone would like to suggest a CSS change, you can try it out 
by adding CSS to 
http://dwiki.kimsufi.thecybershadow.net/Special:MyPage/vector.css. 
Only you will see the changes; once you're satisfied, let me know 
and I'll look into adding them to the main stylesheet.
Nov 22 2012
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/22/12, Vladimir Panteleev <vladimir thecybershadow.net> wrote:

 Does it look better now?


Nope, still the same.

On 11/22/12, Vladimir Panteleev <vladimir thecybershadow.net> wrote:

 That would be because your browser is using Courier New for the
 monospace CSS font family, which is notable for being smaller
 than other fonts at the same font sizes.


I see. I can change it to 16 and then it looks good, but then
dlang.org code samples look too large.

But I don't understand, why doesn't 10pt on the web mean 10pt like in
the editor?
Nov 22 2012
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 22 November 2012 at 15:18:24 UTC, Andrej Mitrovic 
wrote:

 On 11/22/12, Vladimir Panteleev <vladimir thecybershadow.net> 
 wrote:

 Does it look better now?


 Nope, still the same.


Can you try a force-refresh or clearing the browser cache?

What web browser and operating system do you use?
Nov 22 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-22 15:52, Vladimir Panteleev wrote:


 That would be because your browser is using Courier New for the
 monospace CSS font family, which is notable for being smaller than other
 fonts at the same font sizes.

 I've overridden the definition to use the same CSS as the forum
 (basically, try "Consolas" before falling back to "monospace"). Does it
 look better now?


It looks really small in Firefox on Mac OS X as well. It has the 
following style according to firebug:

1em/1.2em monospace

If I remove "1em/1.2em" it looks fine. It looks fine in Safari because 
there the developer tools just say "monospace".

-- 
/Jacob Carlborg
Nov 22 2012
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/22/12, Jacob Carlborg <doob me.com> wrote:

 It looks really small in Firefox on Mac OS X as well. It has the
 following style according to firebug:


On Chrome (on win32) it looks ok though.
Nov 22 2012
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 22 November 2012 at 18:13:10 UTC, Jacob Carlborg 
wrote:

 On 2012-11-22 15:52, Vladimir Panteleev wrote:


 That would be because your browser is using Courier New for the
 monospace CSS font family, which is notable for being smaller 
 than other
 fonts at the same font sizes.

 I've overridden the definition to use the same CSS as the forum
 (basically, try "Consolas" before falling back to 
 "monospace"). Does it
 look better now?


 It looks really small in Firefox on Mac OS X as well. It has 
 the following style according to firebug:

 1em/1.2em monospace

 If I remove "1em/1.2em" it looks fine. It looks fine in Safari 
 because there the developer tools just say "monospace".


Do code examples on Wikipedia look fine for you (e.g. 
http://en.wikipedia.org/wiki/D_(programming_language)#Metaprogramming 
)?
Nov 22 2012
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/22/12, Vladimir Panteleev <vladimir thecybershadow.net> wrote:

 Do code examples on Wikipedia look fine for you (e.g.
 http://en.wikipedia.org/wiki/D_(programming_language)#Metaprogramming
 )?


Those look great.

For dwiki FontFinder says:

Font
===============================
font-family (stack): Consolas,monospace
Font being rendered: monospace
font-size: 10.4px

And for wikipedia:

Font
===============================
font-family (stack): monospace,Courier
Font being rendered: monospace
font-size: 12.8px
Nov 22 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-22 20:35, Vladimir Panteleev wrote:


 Do code examples on Wikipedia look fine for you (e.g.
 http://en.wikipedia.org/wiki/D_(programming_language)#Metaprogramming )?


Yes, they do. I'm now looking at the "computed" font size in firebug. On 
wikipedia it says 12.8px. On the new D wiki page it says 10.4px.

-- 
/Jacob Carlborg
Nov 22 2012
prev sibling parent reply "tn" <no email.com> writes:
On Thursday, 22 November 2012 at 14:52:33 UTC, Vladimir Panteleev 
wrote:

 On Thursday, 22 November 2012 at 10:41:33 UTC, Andrej Mitrovic 
 wrote:

 On 11/22/12, r_m_r <r_m_r mailinator.com> wrote:

 I just modified the Main_Page
 and added the WhySwitch page (content copied from the old 
 wiki:
 http://www.prowiki.org/wiki4d/wiki.cgi).


 Is it possible to increase the default font size for D syntax 
 highlighting?

 This is what it looks like, it's almost unreadable: 
 http://i.imgur.com/B39nC.png
 I would prefer this, which is 10pt in a standard code editor:
 http://i.imgur.com/izGsJ.png


 That would be because your browser is using Courier New for the 
 monospace CSS font family, which is notable for being smaller 
 than other fonts at the same font sizes.

 I've overridden the definition to use the same CSS as the forum 
 (basically, try "Consolas" before falling back to "monospace"). 
 Does it look better now?

 If anyone would like to suggest a CSS change, you can try it 
 out by adding CSS to 
 http://dwiki.kimsufi.thecybershadow.net/Special:MyPage/vector.css. 
 Only you will see the changes; once you're satisfied, let me 
 know and I'll look into adding them to the main stylesheet.


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)
Nov 23 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-23 12:56, 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)


Looks good.

-- 
/Jacob Carlborg
Nov 23 2012
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.
Nov 23 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-23 15:06, Vladimir Panteleev wrote:


 Applied, thanks.


Looks much better, thanks.

-- 
/Jacob Carlborg
Nov 23 2012
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Nov 23 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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?).
Nov 23 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Nov 23 2012
parent reply "David Nadlinger" <see klickverbot.at> writes:
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
Nov 23 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 23, 2012 at 06:26:52PM +0100, David Nadlinger wrote:

 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? ;)


[...]

Why not? Java had Duke, so D has D-Man. :)


T

-- 
Caffeine underflow. Brain dumped.
Nov 23 2012
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 21 November 2012 at 22:22:02 UTC, Vladimir 
Panteleev wrote:

 Here's something to start with:

 http://dwiki.kimsufi.thecybershadow.net/


Could you please set up a robots.txt which disables indexing 
until this has become officially adopted, and moved to its final 
address?

Also, how »stable« can we expect that instance to be? Do you 
make backups? Does it already make sense to invest work into it?

David
Nov 22 2012
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 22 November 2012 at 10:16:53 UTC, David Nadlinger 
wrote:

 On Wednesday, 21 November 2012 at 22:22:02 UTC, Vladimir 
 Panteleev wrote:

 Here's something to start with:

 http://dwiki.kimsufi.thecybershadow.net/


 Could you please set up a robots.txt which disables indexing 
 until this has become officially adopted, and moved to its 
 final address?


Done.


 Also, how »stable« can we expect that instance to be?


As stable as forum.dlang.org.


 Do you make backups?


Automatic daily incremental offsite backups are performed, of the 
filesystem and the database.


 Does it already make sense to invest work into it?


I can think of no reason not to.
Nov 22 2012
parent "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 22 November 2012 at 13:15:30 UTC, Vladimir Panteleev 
wrote:

 On Thursday, 22 November 2012 at 10:16:53 UTC, David Nadlinger

 Also, how »stable« can we expect that instance to be?


 As stable as forum.dlang.org.


 Do you make backups?


 Automatic daily incremental offsite backups are performed, of 
 the filesystem and the database.


 Does it already make sense to invest work into it?


 I can think of no reason not to.


Great! I just wanted to make sure not to overwhelm you in case 
you would have just put this up for testing, but were not ready 
to commit to maintaining it.

David
Nov 22 2012
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/21/12, Vladimir Panteleev <vladimir thecybershadow.net> wrote:

 http://dwiki.kimsufi.thecybershadow.net/


Whoever added those icons, they look awesome! It's already much more
user-friendly than prowiki.
Nov 23 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 13 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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/
Nov 13 2012
prev sibling parent 1100110 <0b1100110 gmail.com> writes:
 I'd say, let's move to http://wiki.dlang.org/GuiLibraries, and then work  
 on keeping that.


+1
Nov 13 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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)?
Nov 13 2012
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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..).

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.
Nov 13 2012
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Nov 13 2012
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Nov 13 2012
next sibling parent reply "Aleksandar Ruzicic" <krckoorascic gmail.com> writes:
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.


Syntax highlighting is not a problem as highlight.js [1] can be 
easily added to any website (including any wiki engine) and it 
supports D syntax coloring (I'm provider and maintainer of that 
support code).

It can work on server too (trough node.js) if someone complains 
about it being a JavaScript tool.

[1] http://softwaremaniacs.org/soft/highlight/en/
Nov 13 2012
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/13/12, Aleksandar Ruzicic <krckoorascic gmail.com> wrote:

 Syntax highlighting is not a problem as highlight.js [1] can be
 easily added


It doesn't work in older browsers.
Nov 13 2012
prev sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
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
Nov 13 2012
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Nov 13 2012
prev sibling parent kraybourne <stdin kraybourne.com> writes:
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.
Nov 13 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, November 16, 2012 13:55:31 H. S. Teoh wrote:

 I don't like the prospect of
 having to duplicate parts of std.algorithm just because I have some code
 that produces transient ranges -- I *know* I'm never going to need to
 use algorithms on them that can't handle transience anyway. It's Not
 Nice to be forced to duplicate code just because an arbitrary decision
 was made to ban transience, or just because some leaky type inference
 decided my range was transient when it's not, etc..


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.

I have found reference type ranges to be very useful upon occasion to the 
point that not having them would be a major problem for some code, but if we 
were to start from scratch, I'd probably still argue against allowing them and 
just get rid of save entirely, because it's caused us a lot of problems. I 
really don't want to see ranges complicated even further.

- Jonathan M Davis
Nov 16 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 16, 2012 at 08:52:39PM -0500, Jonathan M Davis wrote:

 On Friday, November 16, 2012 13:55:31 H. S. Teoh wrote:

 I don't like the prospect of having to duplicate parts of
 std.algorithm just because I have some code that produces transient
 ranges -- I *know* I'm never going to need to use algorithms on them
 that can't handle transience anyway. It's Not Nice to be forced to
 duplicate code just because an arbitrary decision was made to ban
 transience, or just because some leaky type inference decided my
 range was transient when it's not, etc..


 
 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.



 I have found reference type ranges to be very useful upon occasion to
 the point that not having them would be a major problem for some code,
 but if we were to start from scratch, I'd probably still argue against
 allowing them and just get rid of save entirely, because it's caused
 us a lot of problems. I really don't want to see ranges complicated
 even further.


[...]

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.


T

-- 
IBM = I'll Buy Microsoft!
Nov 16 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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:

 On Friday, November 16, 2012 13:55:31 H. S. Teoh wrote:

 I don't like the prospect of having to duplicate parts of
 std.algorithm just because I have some code that produces transient
 ranges -- I *know* I'm never going to need to use algorithms on them
 that can't handle transience anyway. It's Not Nice to be forced to
 duplicate code just because an arbitrary decision was made to ban
 transience, or just because some leaky type inference decided my
 range was transient when it's not, etc..


 
 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.
 

 I have found reference type ranges to be very useful upon occasion to
 the point that not having them would be a major problem for some code,
 but if we were to start from scratch, I'd probably still argue against
 allowing them and just get rid of save entirely, because it's caused
 us a lot of problems. I really don't want to see ranges complicated
 even further.


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



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.

- Jonathan M Davis
Nov 21 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.


 

 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

-- 
If the comments and the code disagree, it's likely that *both* are wrong. --
Christopher
Nov 22 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/22/2012 8:07 AM, 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:




The way you an Jonathan are replying is breaking the message threading model. 
How are you doing it?
Nov 22 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, November 22, 2012 12:53:36 Walter Bright wrote:

 On 11/22/2012 8:07 AM, 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:







 The way you an Jonathan are replying is breaking the message threading
 model. How are you doing it?


It's threading just fine in my mail client. I do recall there being some issue 
with newsgroup vs mailing list threading though. Maybe what you're seeing is 
related to that.

- Jonathan M Davis
Nov 22 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-22 22:18, Jonathan M Davis wrote:


 It's threading just fine in my mail client. I do recall there being some issue
 with newsgroup vs mailing list threading though. Maybe what you're seeing is
 related to that.


The threading is not fine on some of your posts in Thunderbird for me.

-- 
/Jacob Carlborg
Nov 22 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Nov 23 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 22, 2012 at 12:53:36PM -0800, Walter Bright wrote:

 On 11/22/2012 8:07 AM, 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:




 
 The way you an Jonathan are replying is breaking the message
 threading model. How are you doing it?


The threading is fine in my MUA (mutt); I think somebody mentioned some
time ago that Mailman is inserting/substituting message IDs where it
shouldn't, which causes things to break. I'm not sure exactly what or
where, though.


T

-- 
In theory, software is implemented according to the design that has been
carefully worked out beforehand. In practice, design documents are
written after the fact to describe the sorry mess that has gone on
before.
Nov 22 2012
parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 11/22/2012 06:36 PM, H. S. Teoh wrote:

 The threading is fine in my MUA (mutt); I think somebody mentioned some
 time ago that Mailman is inserting/substituting message IDs where it
 shouldn't, which causes things to break. I'm not sure exactly what or
 where, though.


Yes, it is the "puremagic" mail-to-news gateway. Here's the explanation 
for the last time this problem was discussed:

http://forum.dlang.org/post/jo2c5s$f1$1 digitalmars.com

It's about time to "fix it or fuck it" with Mailman.
Nov 23 2012
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 23 November 2012 at 21:37:54 UTC, Jeff Nowakowski 
wrote:

 On 11/22/2012 06:36 PM, H. S. Teoh wrote:

 The threading is fine in my MUA (mutt); I think somebody 
 mentioned some
 time ago that Mailman is inserting/substituting message IDs 
 where it
 shouldn't, which causes things to break. I'm not sure exactly 
 what or
 where, though.


 Yes, it is the "puremagic" mail-to-news gateway. Here's the 
 explanation for the last time this problem was discussed:

 http://forum.dlang.org/post/jo2c5s$f1$1 digitalmars.com

 It's about time to "fix it or fuck it" with Mailman.


I know how to work around this problem (subscribe to both the 
mailing list and newsgroup, and store both Message-IDs). I just 
need to allocate some time to work on the forum again. Hopefully 
around the end of the month.
Nov 23 2012
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 23 November 2012 at 21:42:02 UTC, Vladimir Panteleev 
wrote:

 Yes, it is the "puremagic" mail-to-news gateway. Here's the 
 explanation for the last time this problem was discussed:

 http://forum.dlang.org/post/jo2c5s$f1$1 digitalmars.com

 It's about time to "fix it or fuck it" with Mailman.


 I know how to work around this problem (subscribe to both the 
 mailing list and newsgroup, and store both Message-IDs). I just 
 need to allocate some time to work on the forum again. 
 Hopefully around the end of the month.


Sorry, I assumed you were talking about the forum specifically :) 
Obviously the above applies only to forum users.
Nov 23 2012
parent Jeff Nowakowski <jeff dilacero.org> writes:
On 11/23/2012 04:46 PM, Vladimir Panteleev wrote:

 I know how to work around this problem (subscribe to both the mailing
 list and newsgroup, and store both Message-IDs). I just need to
 allocate some time to work on the forum again. Hopefully around the
 end of the month.


 Sorry, I assumed you were talking about the forum specifically :)
 Obviously the above applies only to forum users.


Right. The problem needs to be dealt with at the Mailman gateway for 
newsgroup users.
Nov 23 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, November 22, 2012 15:36:58 H. S. Teoh wrote:

 In theory, software is implemented according to the design that has been
 carefully worked out beforehand. In practice, design documents are
 written after the fact to describe the sorry mess that has gone on
 before.


Or even more likely, no design documentation gets written at all...

- Jonathan M Davis
Nov 22 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-23 00:43, Jonathan M Davis wrote:


 Or even more likely, no design documentation gets written at all...


Example, this post is not threaded correctly for me.

-- 
/Jacob Carlborg
Nov 22 2012
parent "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 23 Nov 2012 07:40:25 -0000, Jacob Carlborg <doob me.com> wrote:


 On 2012-11-23 00:43, Jonathan M Davis wrote:


 Or even more likely, no design documentation gets written at all...


 Example, this post is not threaded correctly for me.


Nor for me (Opera 12.11 Win32 Windows7).

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 23 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 22, 2012 at 03:43:24PM -0800, Jonathan M Davis wrote:

 On Thursday, November 22, 2012 15:36:58 H. S. Teoh wrote:

 In theory, software is implemented according to the design that has
 been carefully worked out beforehand. In practice, design documents
 are written after the fact to describe the sorry mess that has gone
 on before.


 
 Or even more likely, no design documentation gets written at all...


[...]

Or any documentation at all.

I recall, with a shudder, how one fine day a high-priority Javascript
project (high-priority as in, it was due the week before it was given to
me) was dumped on my lap, consisting of a non-trivial class hierarchy
and bunch of modules of at least 3-4 layers of abstraction, with
absolutely no documentation whatsoever. No design docs, no code
comments, nothing. It was "read the code, pray you'll understand it all
in 3 days, implement the new features of questionable feasibility, and
hope it doesn't break". Some of the code involved 4-5 levels of nested
closures accessing badly-named global variables. You can imagine the
hilarity that ensues when the guy who wrote the mess leaves and a new
person comes in having no idea what the code is supposed to do.


T

-- 
If it tastes good, it's probably bad for you.
Nov 22 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-23 05:07, H. S. Teoh wrote:


 Or any documentation at all.

 I recall, with a shudder, how one fine day a high-priority Javascript
 project (high-priority as in, it was due the week before it was given to
 me) was dumped on my lap, consisting of a non-trivial class hierarchy
 and bunch of modules of at least 3-4 layers of abstraction, with
 absolutely no documentation whatsoever. No design docs, no code
 comments, nothing. It was "read the code, pray you'll understand it all
 in 3 days, implement the new features of questionable feasibility, and
 hope it doesn't break". Some of the code involved 4-5 levels of nested
 closures accessing badly-named global variables. You can imagine the
 hilarity that ensues when the guy who wrote the mess leaves and a new
 person comes in having no idea what the code is supposed to do.


Example, this post is not threaded correctly for me in Thunderbird.

-- 
/Jacob Carlborg
Nov 22 2012
parent "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 23 Nov 2012 07:41:08 -0000, Jacob Carlborg <doob me.com> wrote:


 On 2012-11-23 05:07, H. S. Teoh wrote:


 Or any documentation at all.

 I recall, with a shudder, how one fine day a high-priority Javascript
 project (high-priority as in, it was due the week before it was given to
 me) was dumped on my lap, consisting of a non-trivial class hierarchy
 and bunch of modules of at least 3-4 layers of abstraction, with
 absolutely no documentation whatsoever. No design docs, no code
 comments, nothing. It was "read the code, pray you'll understand it all
 in 3 days, implement the new features of questionable feasibility, and
 hope it doesn't break". Some of the code involved 4-5 levels of nested
 closures accessing badly-named global variables. You can imagine the
 hilarity that ensues when the guy who wrote the mess leaves and a new
 person comes in having no idea what the code is supposed to do.


 Example, this post is not threaded correctly for me in Thunderbird.


Nor for me (Opera 12.11 Win32 Windows7).


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 23 2012
prev sibling parent reply "jerro" <a a.com> writes:
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.


 

 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.
Nov 23 2012
parent reply "jerro" <a a.com> writes:
 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.
Nov 23 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Nov 23 2012
parent reply "jerro" <a a.com> writes:
 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.


My proposal was that for example isInputRange!R wouldn't compile 
if R was transient. So as long as people used the existing 
is***Range templates, the code that called an algorithm that only 
works with non-transient ranges with a transient range wouldn't 
compile. The functions that do support transient ranges could 
check for isInputRange!(R, true) instead of checking for 
isInputRange!R.


 To be correct, most range-based functions would have to add 
 template
 constraints to block ranges which mark themselves as transient.


If they already use is***Range constraints, they wouldn't have to 
add anything.
Nov 23 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, November 23, 2012 22:13:17 jerro wrote:

 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.


 
 My proposal was that for example isInputRange!R wouldn't compile
 if R was transient. So as long as people used the existing
 is***Range templates, the code that called an algorithm that only
 works with non-transient ranges with a transient range wouldn't
 compile. The functions that do support transient ranges could
 check for isInputRange!(R, true) instead of checking for
 isInputRange!R.
 

 To be correct, most range-based functions would have to add
 template
 constraints to block ranges which mark themselves as transient.


 
 If they already use is***Range constraints, they wouldn't have to
 add anything.


So, isInputRange wouldn't compile with any range which declared an enum which 
marked it as transient? If a range doesn't pass isInputRange, then it isn't a 
range in the first place, and it's likely to cause problems if something passes 
isInputRange under some circumstances and not others. Not to mention, trying 
to add a second argument to isInputRange just complicates things.

And regardless of what kind of constraint is used or whether any needs to be 
added, the fact that such a range might exist complicates any and every range 
which is written. Every range must either ignore the possibility of a range 
being transient, or it has to code for it. If much of anything ignores 
transient ranges, then there was no point in having them in the first place. 
And anything which doesn't ignore them just got more complicated.

It's just not worth it.

- Jonathan M Davis
Nov 23 2012