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 Rnne 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
next sibling 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 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 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 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 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 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 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 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
prev sibling next sibling parent "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
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 "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
prev sibling next sibling 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 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 "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
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 "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
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 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 next sibling parent "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
prev 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 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 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
prev sibling next 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 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 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 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
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 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 next sibling parent 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
prev sibling next sibling parent "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
prev sibling parent "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
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 next 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
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 "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
prev sibling next sibling 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 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 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 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 next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling 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 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 next sibling parent "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
prev sibling 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 "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 "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling 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 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 next sibling parent "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
prev sibling 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 next sibling 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 next 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 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 next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling 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 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
prev sibling next sibling 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 next sibling parent 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
prev sibling next sibling parent "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
prev sibling next 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 "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
prev sibling 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. #2 and #3 are too distruptive IMHO and complicate everything. #4 is quite 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 able to work with just fine. #1 obviously solves all of the problems caused 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 next 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.
 
 #2 and #3 are too distruptive IMHO and complicate everything. #4 is quite 
 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
 able to work with just fine. #1 obviously solves all of the problems caused
 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 anyway. Except for #4, I suppose, but it's very leaky. I wouldn't go for #4 except as a last resort.
 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.

#5 is to document transience prominently and indicate clearly which 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. #5.1 is to document transience *and* make ByLine and ByChunk 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 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.

I'd agree with #2, except that I don't know where we'd put warnings about transience. On isInputRange? It certainly doesn't make sense to put them on every function. At most, it would make sense to put them where front or popFront is described. - Jonathan M Davis
Nov 21 2012
prev sibling next 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.

I'd agree with #2, except that I don't know where we'd put warnings about transience. On isInputRange? It certainly doesn't make sense to put them on every function. At most, it would make sense to put them where front or popFront is described.

I'd put it on isInputRange, since that's where .front is defined. Indicate that transient ranges are used "at your own risk" because some algorithms will not work correctly. And optionally, each algorithm that supports transience can be documented as such (the assumption being that if something isn't explicitly documented to support transience, it probably doesn't). T -- If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher
Nov 22 2012
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 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 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
prev sibling next 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 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
prev sibling next sibling parent 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
prev sibling next sibling 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 next sibling 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 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 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 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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.

I'd agree with #2, except that I don't know where we'd put warnings about transience. On isInputRange? It certainly doesn't make sense to put them on every function. At most, it would make sense to put them where front or popFront is described.

I'd put it on isInputRange, since that's where .front is defined. Indicate that transient ranges are used "at your own risk" because some algorithms will not work correctly. And optionally, each algorithm that supports transience can be documented as such (the assumption being that if something isn't explicitly documented to support transience, it probably doesn't). T

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